<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
    which is available here: http://xml.resource.org. --> encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
    There has to be one entity for each item to be referenced.
    An alternate method (rfc include) is described in the references. -->

]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
    please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
    (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
    (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions --> "rfc2629-xhtml.ent">

<rfc category="std" xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-idr-bgp-flowspec-oid-15" number="9117" ipr="trust200902" updates="8955">
 <!-- category values: std, bcp, info, exp, and historic
    ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
       or pre5378Trust200902
    you can add the attributes updates="NNNN" and obsoletes="NNNN"
    they will automatically be output with "(if approved)" -->

 <!-- ***** FRONT MATTER ***** --> updates="8955" obsoletes="" submissionType="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">

 <front>
   <!-- The abbreviated title is used in the page header - it is only necessary if the
        full title is longer than 39 characters -->

   <title abbrev="Revised Flowspec Validation Procedure">Revised Validation Procedure for BGP Flow Specifications</title>

   <!-- add 'role="editor"' below for the editors if appropriate -->

   <!-- Another author who claims to be an editor -->
   <seriesInfo name="RFC" value="9117"/>

   <author fullname="James Uttaro" initials="J.U." initials="J" surname="Uttaro">
      <organization>AT&amp;T</organization>
      <address>
        <postal>
          <street>200 S. Laurel Ave</street>

         <!-- Reorder these if your country does things differently -->

         <city>Middletown</city>
          <region>NJ</region>
          <code>07748</code>

         <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>ju1738@att.com</email>

       <!-- uri and facsimile elements may also be added -->

     </address>
    </author>

    <author fullname="Juan Alcaide" initials="J.A." initials="J" surname="Alcaide">
      <organization>Cisco</organization>
      <address>
        <postal>
          <street>7100 Kit Creek Road</street>

         <!-- Reorder these if your country does things differently -->

         <city>Research

         <extaddr>Research Triangle Park</city> Park</extaddr>
	 <city>Morrisville</city>
          <region>NC</region>
          <code>27709</code>

         <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>jalcaide@cisco.com</email>

       <!-- uri and facsimile elements may also be added -->

     </address>
    </author>
    <author fullname="Clarence Filsfils" initials="C.F." initials="C" surname="Filsfils">
      <organization>Cisco</organization>
      <address>
        <email>cf@cisco.com</email>

       <!-- uri and facsimile elements may also be added -->

     </address>
    </author>
    <author fullname="David Smith" initials="D.S." initials="D" surname="Smith">
      <organization>Cisco</organization>
      <address>
        <postal>
          <street>111 Wood Ave South</street>

         <!-- Reorder these if your country does things differently -->

         <city>Iselin</city>
          <region>NJ</region>
          <code>08830</code>

         <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>djsmith@cisco.com</email>

       <!-- uri and facsimile elements may also be added -->

     </address>
    </author>
    <author fullname="Pradosh Mohapatra" initials="P.M." initials="P" surname="Mohapatra">
      <organization>Sproute Networks</organization>
      <address>
        <email>mpradosh@yahoo.com</email>

       <!-- uri and facsimile elements may also be added -->

     </address>
    </author>
    <date month="August" year="2021" />

   <!-- If the month and year are both specified and are the current ones, xml2rfc will fill
        in the current day for you. If only the current year is specified, xml2rfc will fill
	 in the current day and month for you. If the year is not the current one, it is
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to
	 specify just the year. -->

   <!-- Meta-data Declarations -->

   <area>General</area>
    <workgroup>Network Working Group</workgroup>

   <!-- WG name at the upperleft corner of the doc,
        IETF is fine for individual submissions.
	 If this element is not present, the default is "Network Working Group",
        which is used by the RFC Editor as a nod to the history of the IETF. -->

   <keyword>BGP flowspec</keyword>

   <!-- Keywords will be incorporated into HTML output
        files in a meta tag but they have no effect on text or nroff
        output. If you submit your draft to the RFC Editor, the
        keywords will be used for the search engine. -->

   <abstract>
      <t>
   This document describes a modification to the validation procedure defined
   for the dissemination of BGP Flow Specifications.  The dissemination of BGP
   Flow Specifications as specified in <xref target="RFC8955" /> RFC 8955 requires that the originator
   of the Flow Specification matches match the originator of the best-match unicast
   route for the destination prefix embedded in the Flow Specification. For an iBGP
   Internal Border Gateway Protocol (iBGP) received route, the originator is
   typically a border router within the same autonomous system. system (AS).  The
   objective is to allow only BGP speakers within the data forwarding path to
   originate BGP Flow Specifications.  Sometimes it is desirable to originate
   the BGP Flow Specification from any place within the autonomous system
   itself, for example, from a centralized BGP route controller.  However, the RFC 8955
   validation procedure described in RFC 8955 will fail in this scenario.  The modification
   proposed herein relaxes the validation rule to enable Flow Specifications
   to be originated within the same autonomous system as the BGP speaker
   performing the validation.  Additionally, this document revises the AS_PATH
   validation rules so Flow Specifications received from an eBGP External Border
   Gateway Protocol (eBGP) peer can be validated when such a peer is a BGP
   route server.

      </t>
      <t>
	 This document updates the validation procedure in <xref target="RFC8955" />. RFC 8955.
      </t>
    </abstract>
  </front>
  <middle>

    <section 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>
   </section>
   <section title="Terminology">
   <t>
	Local Domain: the local AS or the local confederation of ASes <xref target="RFC5065" />.
	</t>
	<t>
	eBGP: BGP peering to a router not within the Local Domain.
	</t>
	<t>
	iBGP: BGP peering not eBGP as defined above (i.e. both classic iBGP and any form of eBGP peering with a router within the same confederation).
	</t>
   </section>
   <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>

      <t>
	 <xref target="RFC8955" /> format="default"/> defines a BGP NLRI Network Layer
	 Reachability Information (NLRI) <xref target="RFC4760" />
	 format="default"/> that can be used to distribute traffic Flow
	 Specifications amongst BGP speakers in support of traffic
	 filtering. The primary intention of <xref target="RFC8955" />
	 format="default"/> is to enable downstream autonomous systems to
	 signal traffic filtering policies to upstream autonomous systems.  In
	 this way, traffic is filtered closer to the source and the upstream
	 autonomous system(s) systems avoid carrying the traffic to the downstream
	 autonomous system systems only to be discarded.  <xref target="RFC8955" />
	 format="default"/> also enables more granular traffic filtering based
	 upon
	 upper layer upper-layer protocol information (e.g., protocol or port
	 numbers) as opposed to coarse IP destination prefix-based filtering.
	 Flow Specification NLRIs received from a BGP peer are is subject to
	 validity checks before being considered feasible and subsequently
	 installed within the respective Adj-RIB-In.
      </t>
      <t>
	  The validation procedure defined within <xref target="RFC8955" />
	  format="default"/> requires that the originator of the Flow
	  Specification NLRI matches match the originator of the best-match unicast
	  route for the destination prefix embedded in the Flow Specification.
	  The aim is to make sure that only speakers on the forwarding path
	  can originate the Flow Specification.  Let's consider the particular
	  case where the Flow Specification is originated in any location
	  within the same Local Domain as the speaker performing the
	  validation (for example example, by a centralized BGP route controller), and
	  the best-match unicast route is originated in another Local Domain.
	  In order for the validation to succeed for a Flow Specification
	  received from an iBGP peer, it would be necessary to disseminate
	  such Flow Specification NLRI directly from the specific border
	  router (within the Local Domain) that is advertising the
	  corresponding best-match unicast route to the Local Domain.  Those
	  border routers would be acting as de facto route controllers.  This
	  approach would be, however, operationally cumbersome in a Local
	  Domain with numerous border routers having complex BGP policies.
      </t>
      <t>
	   Figure 1
	   <xref target="fig_1"/> illustrates this principle.  R1 (the upstream router) and
	   RR (a route reflector) need to validate the Flow Specification
	   whose embedded destination prefix has a best-match unicast route
	   (dest-route) originated by ASBR2.  ASBR2 could originate the Flow
	   Specification, and it would be validated when received by RR and R1
	   (from their point of view, the originator of both the FLow Flow
	   Specification and the best-match unicast route will be ASBR1).
	   Sometimes the Flow Specification needs to be originated within AS1.
	   ASBR1 could originate it, and the Flow Specification would still be
	   validated.  In both cases, the Flow Specification is originated by
	   a router in the same forwarding path as the dest-route.  For the
	   case where AS1 has thousands of ASBRs, it becomes impractical to
	   originate different Flow Specification rules on each ASBR in AS1
	   based on which ASBR each dest-route is learned from.  To make the
	   situation more tenable, the objective is to advertise all the Flow
	   Specifications from the same route-controller. route controller.
      </t>
	 <t>
	 <?rfc needLines="37" ?>
      <figure align="center" anchor="fig_1">
        <artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![CDATA[
        R1(AS1) --- RR(AS1) --- ASBR1(AS1) --- ASBR2(AS2)
                     |
             route-controller(AS1)
             route controller(AS1)
	 ]]></artwork>
      </figure>
	  </t>
      <t> This document describes a modification to the validation procedure described in <xref target="RFC8955" /> validation
	  procedure,
      format="default"/>, by allowing Flow Specification
      NLRIs to be originated from a centralized BGP route controller located
      within the Local Domain and not necessarily in the data forwarding data-forwarding path.
      While the proposed modification cannot be used for inter-domain
      coordination of traffic filtering, it greatly simplifies distribution of
      intra-domain traffic filtering policies within a Local Domain which that has
      numerous border routers having complex BGP policies.  By relaxing the
      validation procedure for iBGP, the proposed modification allows Flow
      Specifications to be distributed in a standard and scalable manner
      throughout the Local Domain.
      </t>
      <t>

		Throughout this document, some references are made to
		AS_CONFED_SEQUENCE segments; see Sections 4.1 <xref
		target="REV_ROUTE" format="counter"/> and 5. <xref
		target="topology" format="counter"/>.  If AS_CONFED_SET
		segments are also present in the AS_PATH, the same
		considerations apply to them.  Note, however, that the use of
		AS_CONFED_SET segments is not recommended <xref
		target="RFC6472" />. format="default"/>.  Refer to <xref
		target="I-D.ietf-idr-deprecate-as-set-confed-set" />
		format="default"/> as well.
      </t>

    </section>

    <section title="Motivation"> numbered="true" toc="default">
      <name>Definitions of Terms Used in This Memo</name>

<dl>

<dt>Local Domain:
</dt>
<dd>the local AS or the local confederation of ASes <xref target="RFC5065"
format="default"/>.
</dd>

<dt>eBGP:
</dt>
<dd>BGP peering to a router not within the Local Domain.</dd>

<dt>iBGP:
</dt>
<dd>Both classic iBGP and any form of eBGP peering with a router within the
same confederation (i.e., iBGP peering is a peering that is not eBGP as
defined above).
</dd>

</dl>

        <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 numbered="true" toc="default">
      <name>Motivation</name>
      <t>Step (b) of the validation procedure in Section 6 of <xref sectionFormat="of"
      section="6" target="RFC8955" /> format="default"/> is defined with the
      underlying assumption that the Flow Specification NLRI traverses the
      same path, in the inter-domain and intra-domain route distribution
      graph, as that of the longest-match unicast route for the destination
      prefix embedded in the Flow Specification.
      </t>
      <t>
     In the case of inter-domain traffic filtering, the Flow Specification
     originator at the egress border routers of an AS (e.g. (e.g., RTR-D and RTR-E
     of AS1 in Figure 2) <xref target="fig_2"/>) matches the eBGP neighbor that
     advertised the longest match destination prefix (see RTR-F and RTR-G respectively RTR-G,
     respectively, in Figure 2). <xref target="fig_2"/>).
      </t>
      <t>
	 Similarly, at the upstream routers of an AS (see RTR-A and RTR-B of
	 AS1 in Figure 2), <xref target="fig_2"/>), the Flow Specification originator
	 matches the egress iBGP border routers that had advertised the
	 unicast route for the best-match destination prefix (see RTR-D and RTR-E respectively
	 RTR-E, respectively, in Figure 2). <xref target="fig_2"/>).  This is true even
	 when upstream routers select paths from different egress border
	 routers as the best route based upon IGP distance.  For example, in Figure 2:
	 <list>
	 <t>RTR-A <xref
	 target="fig_2"/>:
      </t>
      <ul empty="true" spacing="normal">
        <li>RTR-A chooses RTR-D as the best route
	 </t>
	 <t>RTR-B
	 </li>
        <li>RTR-B chooses RTR-E as the best route
	 </t>
	 </list>
	 </t>
	 <t>
     <?rfc needLines="37" ?>
	 </li>
      </ul>
      <figure align="center" anchor="fig_2">
        <artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![CDATA[
                  / - - - - - - - - - - - - -  -
                  |            AS1              |
                    +-------+        +-------+
                  | |       |        |       |  |
                    | RTR-A |        | RTR-B |
                  | |       |        |       |  |
                    +-------+        +-------+
                  |       \           /         |
                     iBGP  \         / iBGP
                  |         \       /           |
                            +-------+
                  |         |       |           |
                            | RTR-C |
                  |         |  RC   |           |
                            +-------+
                  |           /   \             |
                             /     \
                  |   iBGP  /       \ iBGP      |
                    +-------+        +-------+
                  | | RTR-D |        | RTR-E |  |
                    |       |        |       |
                  | |       |        |       |  |
                    +-------+        +-------+
                  |     |                 |     |
                   - - -|- - - - - - - - -|- - -/
                        | eBGP       eBGP |
                   - - -|- - - - - - - - -|- - -/
                  |     |                 |     |
                    +-------+        +-------+
                  | |       |        |       |  |
                    | RTR-F |        | RTR-G |
                  | |       |        |       |  |
                    +-------+        +-------+
                  |            AS2              |
                  / - - - - - - - - - - - - -  -
	 ]]></artwork>
      </figure>
   </t>
      <t>It is highly desirable that mechanisms exist to protect each AS independently
   from network security attacks using the BGP Flow Specification NLRI for
   intra-AS purposes only. Network operators often deploy a dedicated
   Security Operations Center (SOC) within their AS to monitor and detect such security attacks.
   To mitigate attacks within an AS, operators require
   the ability to originate intra-AS Flow Specification NLRIs from a
   central BGP route controller that is not within the data forwarding plane.
   In this way, operators can direct border routers within their AS with
   specific attack mitigation attack-mitigation actions (drop the traffic, forward to a pipe-cleaning location, etc.).
      </t>
      <t>
   In addition, an operator may extend the requirements above for a group of
   ASes via policy.  This is described below in Section (b.2.3) <xref target="REV_ROUTE"/> (<xref target="b.2.3"
   format="none">b.2.3</xref>) of the validation procedure.
      </t>
      <t>
   A central BGP route controller that originates a Flow Specification
   NLRI should be able to avoid the complexity of having to determine
   the egress border router whose path was chosen as the best for each
   of its neighbors.

   When a central BGP route controller originates a Flow Specification NLRI, the rest of the speakers
   within the AS will see the BGP route controller as the originator of the Flow Specification in terms
   of the validation procedure rules. Thus, it is necessary to modify step (b) of the <xref target="RFC8955" /> validation procedure described in <xref target="RFC8955" format="default"/>
   such that an iBGP peer that is not within the data forwarding plane
   may originate Flow Specification NLRIs.
      </t>

    </section>
    <section title="Revised numbered="true" toc="default">
      <name>Revised Validation Procedure"> Procedure</name>
      <section title="Revision anchor="REV_ROUTE" numbered="true" toc="default">
        <name>Revision of Route Feasibility"> Feasibility</name>
        <t>Step (b) of the validation procedure specified in Section 6 of <xref
        target="RFC8955" /> sectionFormat="of" section="6" format="default"/> is
        redefined as follows:
     <list style="hanging" hangIndent="3">
         <t hangText="b)">One
        </t>
<blockquote>
        <dl newline="false" spacing="normal" indent="3">
          <dt>b)</dt>
          <dd>
            <t>One of the following conditions MUST <bcp14>MUST</bcp14> hold true:
         <list style="numbers">
            <t>The
            </t>
            <ol anchor="step_b" spacing="normal" type="1">
	      <li anchor="b.1">The originator of the Flow Specification matches the
	      originator of the best-match unicast route for the destination
	      prefix embedded in the Flow Specification (this is the unicast
	      route with the longest possible prefix length covering the
	      destination prefix embedded in the Flow Specification).
			</t>
			</li>
              <li anchor="b.2">
                <t>The AS_PATH attribute of the Flow Specification is empty or
                contains only an AS_CONFED_SEQUENCE segment <xref
                target="RFC5065" />.
			 <list style="numbers">
			 <t>This format="default"/>.
                </t>
                <ol spacing="normal">
		  <li anchor="b.1.1">This condition SHOULD <bcp14>SHOULD</bcp14> be
		  enabled by default.
			 </t>
			 <t>This
			 </li>
                  <li anchor="b.2.2">This condition MAY <bcp14>MAY</bcp14> be disabled by
                  explicit configuration on a BGP speaker.
			 </t>
			 <t>As
			 </li>
                  <li anchor="b.2.3">As an extension to this rule, a given non-empty AS_PATH
                  (besides AS_CONFED_SEQUENCE segments) MAY <bcp14>MAY</bcp14> be
                  permitted by policy.
			</t>
			 </list>
			 </t>
          </list>
		  </t>

        </list>
</t>
			</li>
</ol>
              </li>
            </ol>
          </dd>
        </dl>
</blockquote>
        <t>Explanation:
<list>
<t>
</t>
        <ul empty="true" spacing="normal">
          <li>
Receiving either an empty AS_PATH or one
with only an AS_CONFED_SEQUENCE segment indicates that the Flow Specification was
originated inside the Local Domain.
</t>
<t>
</li>
          <li>
With the above modification to the <xref target="RFC8955" /> format="default"/> validation procedure, a BGP peer within the Local Domain
that is not within the data forwarding data-forwarding path can originate a Flow Specification.
</t>
<t>
</li>
          <li>
Disabling the new condition above (b.2.2) (see <xref target="b.2.2" format="none">step
b.2.2</xref> in <xref target="REV_ROUTE"/>) could be a good practice if the
operator knew with certainty that a Flow Specification would not be originated
inside the Local Domain. An additional case would be if it was known for a
fact that only the right egress border routers (i.e. (i.e., those that were also
egress border routers for the best routes) were originating a Flow Specification
NLRI.
</t>
<t>
</li>
          <li>
Also, policy may be useful to permit a specific set of non-empty AS_PATHs (b.2.3). (see
<xref target="b.2.3" format="none">step b.2.3</xref> in <xref
target="REV_ROUTE"/>). For example, it could validate a Flow Specification
whose AS_PATH contained only an AS_SEQUENCE segment with ASes that were all
known to belong to the same administrative domain.
</t>
</list>
</t>
</li>
        </ul>
      </section>

      <section title="Revision  anchor="AS_PATH" numbered="true" toc="default">
        <name >Revision of AS_PATH Validation"> Validation</name>
        <t>
Section 6 of
<xref target="RFC8955" /> sectionFormat="of" section="6" format="default"/>
states:
</t>
<t>
<list>
<t>
        <ul empty="true" spacing="normal">
          <li>

<blockquote>
BGP implementations MUST <bcp14>MUST</bcp14> also enforce that the
AS_PATH attribute of a route received via the External Border Gateway Protocol (eBGP)
contains the neighboring AS in the left-most position of the AS_PATH attribute. While this rule is optional in the BGP specification, it
   becomes necessary to enforce it here for security reasons.
</t>
</list>
</t>
</blockquote>
</li>
        </ul>
        <t>
This rule prevents the exchange of BGP Flow Specification NLRIs at Internet
exchanges with BGP route servers, which by design don't insert their own AS
number into the AS_PATH  (Section 2.2.2.1 of <xref (<xref target="RFC7947" />). sectionFormat="of"
section="2.2.2.1" format="default"/>).  Therefore, this document also
redefines the <xref target="RFC8955" /> format="default"/> AS_PATH validation
procedure referenced above as follows:
</t>
<t>
<list>
<t>
<ul empty="true" spacing="normal">
<li>
<blockquote>
BGP Flow Specification implementations MUST <bcp14>MUST</bcp14> enforce that the AS in the left-most position of the AS_PATH attribute of a Flow Specification route
received via the External Border Gateway Protocol (eBGP) matches the AS in the left-most position of the AS_PATH attribute of the best-match unicast route for the destination prefix
embedded in the Flow Specification NLRI.
</t>
</list>
</t>
</blockquote>
</li>
</ul>
        <t>
Explanation:
<list>
<t>
For
</t>

<ul empty="true" spacing="normal">
<li>For clarity, the AS in the left-most position of the AS_PATH means the AS that was last added to an AS_SEQUENCE.
</t>
<t>This
</li>
          <li>This proposed modification enables the exchange of
BGP Flow Specification NLRIs at Internet exchanges with
BGP route servers while at the same time, for security reasons,
prevents an eBGP peer from advertising an inter-domain
Flow Specification for a destination prefix that it does
not provide reachability information for.
</t>
<t>
</li>
          <li>
Comparing only the left-most AS in the AS-PATH for eBGP learned eBGP-learned Flow Specification NLRIs is
roughly equivalent to checking the neighboring AS.
If the peer is a route server, security is necessarily weakened for the Flow Specification NLRI, as it is for any unicast route advertised from a route server. An example is discussed in the Security Considerations Section.
</t>
<t> <xref target="Security" format="none">Security Considerations</xref> section.
</li>
          <li>
Redefinition of this AS_PATH validation rule for a Flow Specification does not
mean that the original rule in <xref target="RFC8955" /> format="default"/>
cannot be enforced as well.  Its enforcement remains optional per Section 6.3 of <xref
target="RFC4271" />. sectionFormat="of" section="6.3" format="default"/>.  That
is, a BGP speaker can enforce the first AS in the AS_PATH to be the same as
the neighbor AS for a route belonging to any Address Family (including Flow
Specification Address Family).  If the BGP speaker peer is not a route server,
when enforcing this optional rule, the security characteristics are exactly
equivalent to those specified in <xref target="RFC8955" />.
</t>
<t> format="default"/>.
</li>
          <li>
Alternatively, enforcing this optional rule for unicast routes (even if not enforced on Flow Specification NLRIs) achieves exactly the same security characteristics.
The reason is that, after all validations, the neighboring AS will be the same as the left-most AS in the AS-PATH for the unicast route, and the left-most AS in the AS_PATH for the unicast route
will be the same as the left-most AS in the AS_PATH for the Flow Specification NLRI. Therefore, the neighboring AS will be the same as the left-most AS in the AS_PATH for the Flow Specification NLRI (as the original
AS_PATH validation rule in <xref target="RFC8955" /> format="default"/> states).
</t>
<t>
</li>
          <li>
Note, however, that not checking the full AS_PATH allows any rogue or
misconfigured AS the ability to originate undesired Flow Specifications. This
is a BGP security threat, already present on in <xref target="RFC8955" />,
format="default"/>, but out of the scope of this document.
</t>
<t>
</li>
          <li>
Using the new rule to validate a Flow Specification route received from a peer belonging to the same Local Domain
is out of the scope of this document. Note that although it's possible, its utility is dubious.
Although it is conceivable that a router in the same Local Domain could send a rogue update, only eBGP risk is considered within this document
(in the same spirit as the aforementioned AS_PATH validation in <xref target="RFC4271" />).
</t>
</list>
</t> format="default"/>).
</li>
</ul>
      </section>
    </section>
    <section title="Topology Considerations"> numbered="true" toc="default" anchor="topology">
      <name>Topology Considerations</name>
      <t>
<xref target="RFC8955" /> format="default"/> indicates that the originator may
refer to the originator path attribute (ORIGINATOR_ID) or (if the attribute is
not present) the transport address of the peer from which the BGP speaker
received the update.  If the latter applies, a network should be designed so
it has a congruent topology amongst unicast routes and Flow Specification
routes.  By congruent topology, it is understood that the two routes (i.e. (i.e.,
the Flow Specification route and its best-match unicast route) are learned
from the same peer across the AS.  That would likely not be true, for
instance, if some peers only negotiated one Address Family or if each Address
Family peering had a different set of policies. Failing to have a congruent
topology would result in step (b.1) (<xref format="none" target="b.1">b.1</xref>) of the
validation procedure to fail.
</t>
      <t>
With the additional second condition (b.2) (<xref target="b.2" format="none">b.2</xref>) in the validation procedure, non-congruent topologies are supported within the Local Domain if the Flow Specification
is originated within the Local Domain.
</t>
      <t>
Explanation:
<list>
<t>
Consider
</t>
          <ul empty="true">
<li><t>Consider the following scenarios of a non-congruent topology without the second condition (b.2) (<xref target="b.2" format="none">b.2</xref>) being added to the validation procedure:
<list style="numbers">
<t>Consider procedure:</t>

          <ol spacing="normal" type="1"><li>Consider a topology with two BGP
          speakers with two iBGP peering sessions between them, one for
          unicast and one for Flow Specification. This is a non-congruent
          topology. Let's assume that the ORIGINATOR_ID attribute was not
          received (e.g. (e.g., a route reflector receiving routes from its
          clients). In this case, the Flow Specification validation procedure
          will fail because of the first condition (b.1).
</t>
<t>Consider (<xref
          target="b.1" format="none">b.1</xref>).
</li>
            <li>Consider a confederation of ASes with local AS X and local AS Y (both belonging to the same Local Domain), and a given BGP speaker X1 inside local AS X.
The ORIGINATOR_ID attribute is not advertised when propagating routes across local ASes.
Let's assume the Flow Specification route is received from peer Y1 and the best-match unicast route
is received from peer Y2. Both peers belong to local AS Y.
The Flow Specification validation procedure will also fail because of the first condition (b.1).
</t>
</list>
</t>
<t> (<xref target="b.1" format="none">b.1</xref>).
</li>
          </ol>
	  </li>
        <li>
Consider now that the second conditon (b.2) condition (<xref target="b.2" format="none">b.2</xref>) is
added to the validation procedure. In the scenarios above, if Flow
Specifications are originated in the same Local Domain, the AS_PATH will be
empty or contain only an AS_CONFED_SEQUENCE segment.  Condition (b.2) (<xref
target="b.2" format="none">b.2</xref>) will evaluate to true. Therefore, using the second
condition (b.2), (<xref target="b.2" format="none">b.2</xref>), as defined by this document,
guarantees that the overall validation procedure will pass.  Thus,
non-congruent topologies are supported if the Flow Specification is originated
in the same Local Domain.
</t>
<t>
</li>
        <li>
Flow Specifications originated in a different Local Domain sill need a
congruent topology. The reason is that in a non-congruent topology topology, the second
condition
(b.2) (<xref target="b.2" format="none">b.2</xref>) evaluates to false and
only the first condition (b.1) (<xref target="b.1" format="none">b.1</xref>) is
evaluated.
</t>
</list>
</t>
</li>
      </ul>
    </section>
    <section anchor="IANA" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document includes has no request to IANA.</t> IANA actions.</t>
    </section>
    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>

      <t>
    This document updates the route feasibility validation procedures for Flow
    Specifications learned from iBGP peers and through route servers.  This
    change is in line with the procedures described in <xref target="RFC8955" />
    format="default"/> and, thus, security characteristics remain essentially
    equivalent to the existing security properties of BGP unicast routing,
    except as detailed below.
      </t>
      <t>
    The security considerations discussed in <xref target="RFC8955" /> format="default"/> apply to this
    specification as well.
      </t>
      <t>
   This document makes the original AS_PATH validation rule (Section 6.3 of <xref (<xref
   target="RFC4271" />) sectionFormat="of" section="6.3" format="default"/>) again OPTIONAL
   (Section 5.2)
   <bcp14>OPTIONAL</bcp14> (<xref target="AS_PATH"/>) for Flow Specification Address Family (the rule is no longer
   mandatory as had been specified by [RFC8955]). <xref target="RFC8955"/>).  If that original rule is
   not enforced for Flow Specification Specification, it may introduce some new security
   risks.  A speaker in AS X peering with a route server could advertise a
   rogue Flow Specification route whose first AS in AS_PATH was Y. Assume Y is
   the first AS in the AS_PATH of the best-match unicast route.  When the
   route server advertises the Flow Specification to a speaker in AS Z, it
   will be validated by that speaker.  This risk is impossible to prevent if
   the Flow Specification route is received from a route server peer.  If
   configuration (or other means beyond the scope of this document) indicates
   that the peer is not a route server, that optional rule
SHOULD
   <bcp14>SHOULD</bcp14> be enforced, enforced for unicast and/or for Flow
   Specification routes (as discussed in the <xref target="AS_PATH" format="none">Revision of AS_PATH Validation Section, Validation</xref> section, just
   enforcing it in one of those Addres Address Families is enough).  If the indication
   is that the peer is not a route server or there is no conclusive
   indication, that optional rule SHOULD NOT <bcp14>SHOULD NOT</bcp14> be enforced.
      </t>
      <t>
   A route server itself may be in a good position to enforce the AS_PATH validation rule described
   in the previous paragraph. If it is known that a route server is not peering with any other route server,
   it can enforce the AS_PATH validation rule across all its peers.
</t>
      <t>
	BGP updates learned from iBGP peers are considered
    trusted, so the Traffic Flow Specifications contained in BGP updates
    are also considered trusted.  Therefore, it is not required to
    validate that the originator of an intra-domain Traffic Flow
    Specification matches the originator of the best-match unicast route
	for the destination prefix embedded in that Flow Specification.  Note that this trustworthiness consideration is not
    absolute and the new possibility that an iBGP speaker could send a rogue Flow Specification is introduced.
      </t>
      <t>
	 The changes in Section 5.1 <xref target="REV_ROUTE"/> don't affect the validation
	 procedures for eBGP-learned routes.
      </t>
      <t>
	It's worth mentioning that allowing (or making operationally feasible) to originate
	Flow Specifications to originate within the Local Domain makes
	the network overall more secure. Flow Specifications can be originated
	more readily during attacks and improve the stability and security of
	the network.
      </t>
    </section>

  </middle>

 <back>

<displayreference target="I-D.ietf-idr-deprecate-as-set-confed-set" to="CONFED-SET"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8955.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4271.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4760.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5065.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7947.xml"/>
      </references>
      <references>
        <name>Informative References</name>

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-idr-deprecate-as-set-confed-set.xml"/>

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6472.xml"/>
      </references>
    </references>
    <section anchor="Acknowledgements" title="Acknowledgements"> numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>The authors would like to thank Han Nguyen <contact fullname="Han Nguyen"/> for
      his direction on this work as well as Waqas Alam, Keyur Patel, Robert Raszuk, Eric Rosen,
	 Shyam Sethuram, Susan Hares, Alvaro Retana and John Scudder <contact fullname="Waqas Alam"/>,
      <contact fullname="Keyur Patel"/>, <contact fullname="Robert Raszuk"/>,
      <contact fullname="Eric Rosen"/>, <contact fullname="Shyam Sethuram"/>,
      <contact fullname="Susan Hares"/>, <contact fullname="Alvaro Retana"/>,
      and <contact fullname="John Scudder"/> for their review and comments.
      </t>
    </section>
 </middle>

 <!--  *****BACK MATTER ***** -->

 <back>

   <references title="Normative References">
	 <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8955.xml">?>

	 <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>

	 <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml"?>

     <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4271.xml"?>

	 <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4760.xml"?>

     <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5065.xml"?>

	 <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.7947.xml"?>

   </references>

    <references title="Informative References">
	 <?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-idr-deprecate-as-set-confed-set.xml"?>
	 	 <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6472.xml"?>
	</references>

  </back>
</rfc>