From 7114ee4aede17e1fde64af9ec0918c7279fe11dd Mon Sep 17 00:00:00 2001 From: Randy Bush Date: Mon, 25 May 2020 11:24:25 -0700 Subject: [PATCH] prototypes borrowed from other drafts --- Makefile | 19 +++ draft-ymbk-bgp-discovery-layers.yml | 188 ++++++++++++++++++++++++++++ 2 files changed, 207 insertions(+) create mode 100644 Makefile create mode 100644 draft-ymbk-bgp-discovery-layers.yml diff --git a/Makefile b/Makefile new file mode 100644 index 0000000..65211a0 --- /dev/null +++ b/Makefile @@ -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 diff --git a/draft-ymbk-bgp-discovery-layers.yml b/draft-ymbk-bgp-discovery-layers.yml new file mode 100644 index 0000000..aa451d9 --- /dev/null +++ b/draft-ymbk-bgp-discovery-layers.yml @@ -0,0 +1,188 @@ + + + + + + + + + + + + + + + + + BGP RPKI-Based Origin Validation on Export + + + Internet Initiative Japan & Arrcus +
+ + 5147 Crystal Springs + Bainbridge Island + Washington + 98110 + US + + randy@psg.com +
+ + + + Deutsche Telekom + + + + Cisco +
+ + 170 West Tasman Drive + San Jose + CA + 95134 + USA + + jheitz@cisco.com +
+ + + + + + + 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. + + + + + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL + NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" + are to be interpreted as described in only + when they appear in all upper case. They may also appear in lower + or mixed case as English words, without normative meaning. + + + + + + + +
+ + This document does not change the protocol or semantics of 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. + + 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. + + 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. + +
+ +
+ + It is assumed that the reader understands BGP, , the RPKI, , Route Origin + Authorizations (ROAs), , RPKI-based + Prefix Validation, , and Origin Validation + Clarifications, . + +
+ +
+ + 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. + + 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. + +
+ +
+ + 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. + + 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. + +
+ +
+ + This document does not create security considerations beyond + those of and . + +
+ +
+ + This document has no IANA Considerations. + + +
+ + + + + + + + + + + + + + + + + + + + + +