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