rfc8893xml2.original.xml   rfc8893.xml 
<?xml version="1.0"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc comments="yes"?>
<?rfc compact="yes"?>
<?rfc inline="yes"?>
<?rfc sortrefs="yes"?>
<?rfc subcompact="yes"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc tocompact="yes"?>
<rfc category="std" docName="draft-ietf-sidrops-ov-egress-04" updates="6811" ipr
="trust200902">
<front> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std"
<title>BGP RPKI-Based Origin Validation on Export</title> docName="draft-ietf-sidrops-ov-egress-04" number="8893" updates="6811"
ipr="trust200902" obsoletes="" submissionType="IETF" xml:lang="en"
sortRefs="true" symRefs="true" tocInclude="true" tocDepth="3"
version="3" consensus="true">
<!-- xml2rfc v2v3 conversion 2.44.0 -->
<front>
<title abbrev="RPKI Origin Validation for BGP Export">Resource Public Key In
frastructure (RPKI) Origin Validation for BGP Export</title>
<author fullname="Randy Bush" initials="R." surname="Bush"> <seriesInfo name="RFC" value="8893"/>
<organization>Internet Initiative Japan &amp; Arrcus</organization> <author fullname="Randy Bush" initials="R." surname="Bush">
<address> <organization>Internet Initiative Japan &amp; Arrcus</organization>
<postal> <address>
<street>5147 Crystal Springs</street> <postal>
<city>Bainbridge Island</city> <street>5147 Crystal Springs</street>
<region>Washington</region> <city>Bainbridge Island</city>
<code>98110</code> <region>WA</region>
<country>US</country> <code>98110</code>
<country>United States of America</country>
</postal> </postal>
<email>randy@psg.com</email> <email>randy@psg.com</email>
</address> </address>
</author> </author>
<author fullname="Rüdiger Volk" initials="R." surname="Volk">
<author fullname="Rüdiger Volk" initials="R." surname="Volk"> <organization></organization>
<organization>Deutsche Telekom</organization>
<address> <address>
<email>rv@nic.dtag.de</email> <email>ietf@rewvolk.de</email>
</address> </address>
</author> </author>
<author fullname="Jakob Heitz" initials="J. " surname="Heitz">
<author fullname="Jakob Heitz" initials="J. " surname="Heitz"> <organization>Cisco</organization>
<organization>Cisco</organization>
<address> <address>
<postal> <postal>
<street>170 West Tasman Drive</street> <street>170 West Tasman Drive</street>
<city>San Jose</city> <city>San Jose</city>
<region>CA</region> <region>CA</region>
<code>95134</code> <code>95134</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>jheitz@cisco.com</email> <email>jheitz@cisco.com</email>
</address> </address>
</author> </author>
<date month="September" year="2020"/>
<date /> <keyword>routing</keyword>
<keyword>security</keyword>
<abstract> <keyword>RPKI</keyword>
<t>A BGP speaker may perform RPKI origin validation not only on <abstract>
<t>A BGP speaker may perform Resource Public Key Infrastructure (RPKI)
origin validation not only on
routes received from BGP neighbors and routes that are redistributed routes received from BGP neighbors and routes that are redistributed
from other routing protocols, but also on routes it sends to BGP from other routing protocols, but also on routes it sends to BGP
neighbors. For egress policy, it is important that the neighbors. For egress policy, it is important that the
classification uses the 'effective origin AS' of the processed classification use the 'effective origin AS' of the processed
route, which may specifically be altered by the commonly available route, which may specifically be altered by the commonly available
knobs such as removing private ASs, confederation handling, and knobs, such as removing private ASes, confederation handling, and
other modifications of the origin AS. This document updates <xref other modifications of the origin AS. This document updates RFC 6811.</t>
target="RFC6811"/>.</t>
</abstract> </abstract>
<note title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals,
as shown here.</t>
</note>
</front> </front>
<middle>
<middle> <section anchor="intro" numbered="true" toc="default">
<name>Introduction</name>
<section anchor="intro" title="Introduction"> <t>This document does not change the protocol or semantics of <xref target
="RFC6811" format="default"/>, BGP prefix origin validation. It highlights an
<t>This document does not change the protocol or semantics of <xref important use case of origin validation in external BGP (eBGP) egress polici
target="RFC6811"/>, BGP prefix origin validation. It highlights an es,
important use case of origin validation in eBGP egress policies,
explaining specifics of correct implementation in this context.</t> explaining specifics of correct implementation in this context.</t>
<t>The term 'effective origin AS' as used in this document refers to
<t>The term 'effective origin AS' as used in this document refers to the Route Origin Autonomous System Number (ASN) <xref target="RFC6811"
the Route Origin ASN <xref target="RFC6811"/> of the UPDATE to be format="default"/> of the UPDATE to be
sent to neighboring BGP speakers.</t> sent to neighboring BGP speakers.</t>
<t>The effective origin AS of a BGP UPDATE is decided by
<t>The effective origin AS of a BGP UPDATE is decided by
configuration and outbound policy of the BGP speaker. A validating configuration and outbound policy of the BGP speaker. A validating
BGP speaker MUST apply Route Origin Validation policy semantics (see BGP speaker <bcp14>MUST</bcp14> apply Route Origin Validation policy semanti
<xref target="RFC6811"/> Sec 2 and <xref target="RFC8481"/> Sec 4) cs (see
<xref target="RFC6811" sectionFormat="of" section="2"/> and <xref
target="RFC8481" sectionFormat="of" section="4"/>)
after applying any egress configuration and policy.</t> after applying any egress configuration and policy.</t>
<t>This effective origin AS of the announcement might be affected by
<t>This effective origin AS of the announcement might be affected by removal of private ASes, confederation <xref target="RFC5065" format="defaul
removal of private ASs, confederation <xref target="RFC5065"/>, t"/>,
migration <xref target="RFC7705"/>, etc. Any AS_PATH modifications migration <xref target="RFC7705" format="default"/>, etc. Any AS_PATH modif
resulting in effective origin AS change MUST be taken into ications
resulting in effective origin AS change <bcp14>MUST</bcp14> be taken into
account.</t> account.</t>
<t>This document updates <xref target="RFC6811" format="default"/> by clar
<t>This document updates <xref target="RFC6811"/> by clarifying that ifying that
implementations must use the effective origin AS to determine the implementations must use the effective origin AS to determine the
Origin Validation state when applying egress policy.</t> Origin Validation state when applying egress policy.</t>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
to be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
<section anchor="reading" title="Suggested Reading"> <section anchor="reading" numbered="true" toc="default">
<name>Suggested Reading</name>
<t>It is assumed that the reader understands BGP, <xref <t>It is assumed that the reader understands BGP <xref target="RFC4271"
target="RFC4271"/>, the RPKI, <xref target="RFC6480"/>, Route Origin format="default"/>, the RPKI <xref target="RFC6480" format="default"/>,
Authorizations (ROAs), <xref target="RFC6482"/>, RPKI-based Route Origin Authorizations (ROAs) <xref target="RFC6482"
Prefix Validation, <xref target="RFC6811"/>, and Origin Validation format="default"/>, RPKI-based Prefix Validation <xref target="RFC6811"
Clarifications, <xref target="RFC8481"/>.</t> format="default"/>, and Origin Validation
Clarifications <xref target="RFC8481" format="default"/>.</t>
</section> </section>
<section anchor="all" title="Egress Processing"> <section anchor="all" numbered="true" toc="default">
<name>Egress Processing</name>
<t>BGP implementations supporting RPKI-based origin validation MUST <t>BGP implementations supporting RPKI-based origin validation <bcp14>MUST
</bcp14>
provide the same policy configuration primitives for decisions based provide the same policy configuration primitives for decisions based
on validation state available for use in ingress, redistribution, on the validation state available for use in ingress, redistribution,
and egress policies. When applied to egress policy, validation and egress policies. When applied to egress policy, validation
state MUST be determined using the effective origin AS of the route state <bcp14>MUST</bcp14> be determined using the effective origin AS of
the route
as it will (or would) be announced to the peer. The effective 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 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 commonly available knobs, such as removal of private ASes, AS path
manipulation, confederation handling, etc.</t> manipulation, confederation handling, etc.</t>
<t>Egress policy handling can provide more robust protection for <t>Egress policy handling can provide more robust protection for
outbound eBGP than relying solely on ingress (iBGP, eBGP, connected, outbound eBGP than relying solely on ingress (iBGP, eBGP, connected,
static, etc.) redistribution being configured and working correctly static, etc.) redistribution being configured and working correctly
- better support for the robustness principle.</t> -- i.e., better support for the robustness principle.</t>
</section> </section>
<section anchor="impl" numbered="true" toc="default">
<section anchor="impl" title="Operational Considerations"> <name>Operational Considerations</name>
<t>Configurations may have a complex policy where the effective
<t>Configurations may have complex policy where the effective
origin AS may not be easily determined before the outbound policies origin AS may not be easily determined before the outbound policies
have been run. It SHOULD be possible to specify a selective origin have been run. It <bcp14>SHOULD</bcp14> be possible to specify a selective origin
validation policy to be applied after any existing non-validating validation policy to be applied after any existing non-validating
outbound policies.</t> outbound policies.</t>
<t>An implementation <bcp14>SHOULD</bcp14> be able to list announcements t
<t>An implementation SHOULD be able to list announcements that were hat were
not sent to a peer, e.g., because they were marked Invalid, as long not sent to a peer, e.g., because they were marked Invalid, as long
as the router still has them in memory.</t> as the router still has them in memory.</t>
</section> </section>
<section anchor="seccons" numbered="true" toc="default">
<section anchor="seccons" title="Security Considerations"> <name>Security Considerations</name>
<t>This document does not create security considerations beyond
<t>This document does not create security considerations beyond those of <xref target="RFC6811" format="default"/> and <xref
those of <xref target="RFC6811"/> and <xref target="RFC8481"/>. By target="RFC8481" format="default"/>. By
facilitating more correct validation, it attempts to improve BGP facilitating more correct validation, it attempts to improve BGP
reliability.</t> reliability.</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>
<section anchor="iana" numbered="true" toc="default">
<section anchor="acks" title="Acknowledgments"> <name>IANA Considerations</name>
<t>This document has no IANA actions.</t>
<t>Thanks to reviews and comments from Linda Dunbar, Nick Hilliard,
Benjamin Kaduk, Chris Morrow, Keyur Patel, Alvaro Retana, Alvaro
Retana, Job Snijders, Robert Sparks, and Robert Wilton.</t>
</section> </section>
</middle> </middle>
<back>
<back> <references>
<name>References</name>
<references title="Normative References"> <references>
<?rfc include="reference.RFC.2119"?> <name>Normative References</name>
<?rfc include="reference.RFC.4271"?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<?rfc include="reference.RFC.5065"?> ence.RFC.2119.xml"/>
<?rfc include="reference.RFC.6482"?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<?rfc include="reference.RFC.6811"?> ence.RFC.4271.xml"/>
<?rfc include="reference.RFC.7705"?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<?rfc include="reference.RFC.8174"?> ence.RFC.5065.xml"/>
<?rfc include="reference.RFC.8481"?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
</references> ence.RFC.6482.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<references title="Informative References"> ence.RFC.6811.xml"/>
<?rfc include="reference.RFC.6480"?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7705.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8481.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6480.xml"/>
</references>
</references> </references>
<section anchor="acks" numbered="false" toc="default">
<name>Acknowledgments</name>
<t>Thanks to reviews and comments from <contact fullname="Linda
Dunbar"/>, <contact fullname="Nick Hilliard"/>,
<contact fullname="Benjamin Kaduk"/>, <contact fullname="Chris Morrow"/>,
<contact fullname="Keyur Patel"/>,
<contact fullname="Alvaro Retana"/>, <contact fullname="Job Snijders"/>,
<contact fullname="Robert Sparks"/>, and <contact fullname="Robert
Wilton"/>.</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 40 change blocks. 
152 lines changed or deleted 146 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/