prototypes borrowed from other drafts
This commit is contained in:
commit
7114ee4aed
2 changed files with 207 additions and 0 deletions
19
Makefile
Normal file
19
Makefile
Normal file
|
|
@ -0,0 +1,19 @@
|
|||
#
|
||||
# Makefile for I-D's and RFCs
|
||||
# $Id: Makefile,v 1.1.1.1 2002-11-11 05:11:48 randy Exp $
|
||||
#
|
||||
|
||||
# Your nroff document is called foo.txt. Change below as appropiate.
|
||||
NAME=draft-ymbk-bgp-discovery-layers
|
||||
DEST=psg.com:public_html
|
||||
RSY=rsync --rsh ssh -v -a -l -H -p -t -x --delete
|
||||
|
||||
all: $(NAME).xml
|
||||
xml2rfc $(NAME).xml --html --text
|
||||
|
||||
rsy:
|
||||
$(RSY) $(NAME).html $(DEST)
|
||||
$(RSY) $(NAME).txt $(DEST)
|
||||
|
||||
clean:
|
||||
rm -f *.html *.txt
|
||||
188
draft-ymbk-bgp-discovery-layers.yml
Normal file
188
draft-ymbk-bgp-discovery-layers.yml
Normal file
|
|
@ -0,0 +1,188 @@
|
|||
<?xml version="1.0"?>
|
||||
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
|
||||
<?rfc comments="yes"?>
|
||||
<?rfc compact="yes"?>
|
||||
<?rfc inline="yes"?>
|
||||
<?rfc sortrefs="yes"?>
|
||||
<?rfc subcompact="yes"?>
|
||||
<?rfc symrefs="yes"?>
|
||||
<?rfc toc="no"?>
|
||||
<?rfc tocdepth="3"?>
|
||||
<?rfc tocindent="yes"?>
|
||||
<?rfc tocompact="yes"?>
|
||||
|
||||
<rfc category="std" docName="draft-ietf-sidrops-ov-egress-00" updates="6811" ipr="trust200902">
|
||||
|
||||
<front>
|
||||
<title>BGP RPKI-Based Origin Validation on Export</title>
|
||||
|
||||
<author fullname="Randy Bush" initials="R." surname="Bush">
|
||||
<organization>Internet Initiative Japan & Arrcus</organization>
|
||||
<address>
|
||||
<postal>
|
||||
<street>5147 Crystal Springs</street>
|
||||
<city>Bainbridge Island</city>
|
||||
<region>Washington</region>
|
||||
<code>98110</code>
|
||||
<country>US</country>
|
||||
</postal>
|
||||
<email>randy@psg.com</email>
|
||||
</address>
|
||||
</author>
|
||||
|
||||
<author fullname="Rüdiger Volk" initials="R." surname="Volk">
|
||||
<organization>Deutsche Telekom</organization>
|
||||
</author>
|
||||
|
||||
<author fullname="Jakob Heitz" initials="J. " surname="Heitz">
|
||||
<organization>Cisco</organization>
|
||||
<address>
|
||||
<postal>
|
||||
<street>170 West Tasman Drive</street>
|
||||
<city>San Jose</city>
|
||||
<region>CA</region>
|
||||
<code>95134</code>
|
||||
<country>USA</country>
|
||||
</postal>
|
||||
<email>jheitz@cisco.com</email>
|
||||
</address>
|
||||
</author>
|
||||
|
||||
<date />
|
||||
|
||||
<abstract>
|
||||
|
||||
<t>A BGP speaker may perform RPKI origin validation not only on
|
||||
routes received from BGP neighbors and routes that are redistributed
|
||||
from other routing protocols, but also on routes it sends to BGP
|
||||
neighbors. For egress policy, it is important that the
|
||||
classification uses the effective origin AS of the processed route,
|
||||
which may specifically be altered by the commonly available knobs
|
||||
such as removing private ASs, confederation handling, and other
|
||||
modifications of the origin AS.</t>
|
||||
|
||||
</abstract>
|
||||
|
||||
<note title="Requirements Language">
|
||||
|
||||
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
|
||||
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
|
||||
are to be interpreted as described in <xref target="RFC2119"/> only
|
||||
when they appear in all upper case. They may also appear in lower
|
||||
or mixed case as English words, without normative meaning.</t>
|
||||
|
||||
</note>
|
||||
|
||||
</front>
|
||||
|
||||
<middle>
|
||||
|
||||
<section anchor="intro" title="Introduction">
|
||||
|
||||
<t>This document does not change the protocol or semantics of <xref
|
||||
target="RFC6811"/> of RPKI-based origin validation. It highlights
|
||||
an important use case of origin validation in eBGP egress policies,
|
||||
explaining specifics of correct implementation in this context.</t>
|
||||
|
||||
<t>As the origin AS may be modified by outbound policy, policy
|
||||
semantics based on RPKI Origin Validation state MUST be able to be
|
||||
applied separately on distribution into BGP and on egress.</t>
|
||||
|
||||
<t>When applied to egress policy, the effective origin AS MUST be
|
||||
used to determine the Origin Validation state. The effective origin
|
||||
AS is that which will actually be the origin AS in the announcement.
|
||||
It might be affected by removal of private AS(s), confederation, AS
|
||||
migration, etc. If there are any AS_PATH modifications resulting in
|
||||
origin AS change, then these MUST be taken into account.</t>
|
||||
|
||||
</section>
|
||||
|
||||
<section anchor="reading" title="Suggested Reading">
|
||||
|
||||
<t>It is assumed that the reader understands BGP, <xref
|
||||
target="RFC4271"/>, the RPKI, <xref target="RFC6480"/>, Route Origin
|
||||
Authorizations (ROAs), <xref target="RFC6482"/>, RPKI-based
|
||||
Prefix Validation, <xref target="RFC6811"/>, and Origin Validation
|
||||
Clarifications, <xref target="RFC8481"/>.</t>
|
||||
|
||||
</section>
|
||||
|
||||
<section anchor="all" title="Egress Processing">
|
||||
|
||||
<t>BGP implementations supporting RPKI-based origin validation
|
||||
SHOULD provide the same policy configuration primitives for
|
||||
decisions based on validation state available for use in ingress,
|
||||
redistribution, and egress policies. When applied to egress policy,
|
||||
validation state MUST be determined using the effective origin AS of
|
||||
the route as it will (or would) be announced to the peer. The
|
||||
effective origin AS may differ from that of the route in the RIB due
|
||||
to commonly available knobs such as: removal of private ASs, AS path
|
||||
manipulation, confederation handling, etc.</t>
|
||||
|
||||
<t>Egress policy handling can provide more robust protection for
|
||||
outbound eBGP than relying solely on ingress (iBGP, eBGP, connected,
|
||||
static, etc.) redistribution being configured and working correctly
|
||||
- better support for the robustness principle.</t>
|
||||
|
||||
</section>
|
||||
|
||||
<section anchor="impl" title="Operational Considerations">
|
||||
|
||||
<t>Configurations may have complex policy where the final announced
|
||||
origin AS may not be easily predicted before all policies have been
|
||||
run. Therefore it SHOULD be possible to specify an origin
|
||||
validation policy which MUST BE run after such non-deterministic
|
||||
policies.</t>
|
||||
|
||||
<t>An operator SHOULD be able to list what announcements are not
|
||||
sent to a peer because they were marked Invalid, as long as the
|
||||
router still has them in memory.</t>
|
||||
|
||||
</section>
|
||||
|
||||
<section anchor="seccons" title="Security Considerations">
|
||||
|
||||
<t>This document does not create security considerations beyond
|
||||
those of <xref target="RFC6811"/> and <xref target="RFC8481"/>.</t>
|
||||
|
||||
</section>
|
||||
|
||||
<section anchor="iana" title="IANA Considerations">
|
||||
|
||||
<t>This document has no IANA Considerations.</t>
|
||||
|
||||
<!--
|
||||
<t>Note to RFC Editor: this section may be replaced on publication
|
||||
as an RFC.</t>
|
||||
-->
|
||||
</section>
|
||||
|
||||
<!--
|
||||
<section anchor="acks" title="Acknowledgments">
|
||||
|
||||
<t>Many thanks to John Scudder who had the patience to give
|
||||
constructive review multiple times, and to Keyur Patel who noted
|
||||
that the AS might have to be specified.</t>
|
||||
|
||||
</section>
|
||||
-->
|
||||
|
||||
</middle>
|
||||
|
||||
<back>
|
||||
|
||||
<references title="Normative References">
|
||||
<?rfc include="reference.RFC.2119"?>
|
||||
<?rfc include="reference.RFC.6482"?>
|
||||
<?rfc include="reference.RFC.6811"?>
|
||||
<?rfc include="reference.RFC.8481"?>
|
||||
</references>
|
||||
|
||||
<references title="Informative References">
|
||||
<?rfc include="reference.RFC.4271"?>
|
||||
<?rfc include="reference.RFC.6480"?>
|
||||
</references>
|
||||
|
||||
</back>
|
||||
|
||||
</rfc>
|
||||
Loading…
Add table
Add a link
Reference in a new issue