<?xml version="1.0"?> version='1.0' encoding='utf-8'?>
<!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="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc tocompact="yes"?> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std"
     docName="draft-ietf-sidrops-ov-egress-04" number="8893" updates="6811" ipr="trust200902">
     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>BGP RPKI-Based
    <title abbrev="RPKI Origin Validation on for BGP Export">Resource Public Key Infrastructure (RPKI) Origin Validation for BGP Export</title>

    <seriesInfo name="RFC" value="8893"/>
    <author fullname="Randy Bush" initials="R." surname="Bush">
      <organization>Internet Initiative Japan &amp; Arrcus</organization>
      <address>
        <postal>
          <street>5147 Crystal Springs</street>
          <city>Bainbridge Island</city>
        <region>Washington</region>
          <region>WA</region>
          <code>98110</code>
        <country>US</country>
          <country>United States of America</country>
        </postal>
        <email>randy@psg.com</email>
      </address>
    </author>
    <author fullname="Rüdiger Volk" initials="R." surname="Volk">
    <organization>Deutsche Telekom</organization>
      <organization></organization>
      <address>
        <email>rv@nic.dtag.de</email>
        <email>ietf@rewvolk.de</email>
      </address>
    </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>
          <country>United States of America</country>
        </postal>
        <email>jheitz@cisco.com</email>
      </address>
    </author>
    <date /> month="September" year="2020"/>

<keyword>routing</keyword>
<keyword>security</keyword>
<keyword>RPKI</keyword>

    <abstract>
      <t>A BGP speaker may perform RPKI Resource Public Key Infrastructure (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 use the 'effective origin AS' of the processed
    route, which may specifically be altered by the commonly available
    knobs
    knobs, such as removing private ASs, ASes, confederation handling, and
    other modifications of the origin AS.  This document updates <xref
    target="RFC6811"/>.</t> RFC 6811.</t>
    </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>
  <middle>
    <section anchor="intro" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>This document does not change the protocol or semantics of <xref
    target="RFC6811"/>, target="RFC6811" format="default"/>, BGP prefix origin validation.  It highlights an
    important use case of origin validation in eBGP external BGP (eBGP) egress policies,
    explaining specifics of correct implementation in this context.</t>
      <t>The term 'effective origin AS' as used in this document refers to
    the Route Origin ASN Autonomous System Number (ASN) <xref target="RFC6811"/> target="RFC6811"
    format="default"/> of the UPDATE to be
    sent to neighboring BGP speakers.</t>
      <t>The effective origin AS of a BGP UPDATE is decided by
    configuration and outbound policy of the BGP speaker.  A validating
    BGP speaker MUST <bcp14>MUST</bcp14> apply Route Origin Validation policy semantics (see
    <xref target="RFC6811"/> Sec 2 target="RFC6811" sectionFormat="of" section="2"/> and <xref target="RFC8481"/> Sec 4)
    target="RFC8481" sectionFormat="of" section="4"/>)
    after applying any egress configuration and policy.</t>
      <t>This effective origin AS of the announcement might be affected by
    removal of private ASs, ASes, confederation <xref target="RFC5065"/>, target="RFC5065" format="default"/>,
    migration <xref target="RFC7705"/>, target="RFC7705" format="default"/>, etc.  Any AS_PATH modifications
    resulting in effective origin AS change MUST <bcp14>MUST</bcp14> be taken into
    account.</t>
      <t>This document updates <xref target="RFC6811"/> target="RFC6811" format="default"/> by clarifying that
    implementations must use the effective origin AS to determine the
    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 anchor="reading" title="Suggested Reading"> numbered="true" toc="default">
      <name>Suggested Reading</name>
      <t>It is assumed that the reader understands BGP, BGP <xref
    target="RFC4271"/>, target="RFC4271"
      format="default"/>, the RPKI, RPKI <xref target="RFC6480"/>, target="RFC6480" format="default"/>,
      Route Origin Authorizations (ROAs), (ROAs) <xref target="RFC6482"/>, target="RFC6482"
      format="default"/>, RPKI-based Prefix Validation, Validation <xref target="RFC6811"/>, target="RFC6811"
      format="default"/>, and Origin Validation
    Clarifications,
    Clarifications <xref target="RFC8481"/>.</t> target="RFC8481" format="default"/>.</t>
    </section>

    <section anchor="all" title="Egress Processing"> numbered="true" toc="default">
      <name>Egress Processing</name>
      <t>BGP implementations supporting RPKI-based origin validation MUST <bcp14>MUST</bcp14>
    provide the same policy configuration primitives for decisions based
    on the validation state available for use in ingress, redistribution,
    and egress policies.  When applied to egress policy, validation
    state MUST <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
    origin AS may differ from that of the route in the RIB due to
    commonly available knobs knobs, such as: as removal of private ASs, ASes, 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
    -
    -- i.e., better support for the robustness principle.</t>
    </section>
    <section anchor="impl" title="Operational Considerations"> numbered="true" toc="default">
      <name>Operational Considerations</name>
      <t>Configurations may have a complex policy where the effective
    origin AS may not be easily determined before the outbound policies
    have been run.  It SHOULD <bcp14>SHOULD</bcp14> be possible to specify a selective origin
    validation policy to be applied after any existing non-validating
    outbound policies.</t>
      <t>An implementation SHOULD <bcp14>SHOULD</bcp14> be able to list announcements that were
    not sent to a peer, e.g., because they were marked Invalid, as long
    as the router still has them in memory.</t>
    </section>
    <section anchor="seccons" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>This document does not create security considerations beyond
    those of <xref target="RFC6811"/> target="RFC6811" format="default"/> and <xref target="RFC8481"/>.
    target="RFC8481" format="default"/>.  By
    facilitating more correct validation, it attempts to improve BGP
    reliability.</t>
    </section>
    <section anchor="iana" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document has no IANA Considerations.</t>

    <!--
    <t>Note to RFC Editor: this section may be replaced on publication
    as an RFC.</t>
    --> actions.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4271.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5065.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6482.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6811.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7705.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8481.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6480.xml"/>
      </references>
    </references>
    <section anchor="acks" title="Acknowledgments"> numbered="false" toc="default">
      <name>Acknowledgments</name>
      <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> <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>

  </middle>

<back>

  <references title="Normative References">
    <?rfc include="reference.RFC.2119"?>
    <?rfc include="reference.RFC.4271"?>
    <?rfc include="reference.RFC.5065"?>
    <?rfc include="reference.RFC.6482"?>
    <?rfc include="reference.RFC.6811"?>
    <?rfc include="reference.RFC.7705"?>
    <?rfc include="reference.RFC.8174"?>
    <?rfc include="reference.RFC.8481"?>
    </references>

  <references title="Informative References">
    <?rfc include="reference.RFC.6480"?>
    </references>
  </back>
</rfc>