rfc9117xml2.original.xml   rfc9117.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!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. -->
]> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?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 -->
<rfc category="std" docName="draft-ietf-idr-bgp-flowspec-oid-15" ipr="trust20090
2" 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 ***** --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-idr-bgp-flow spec-oid-15" number="9117" ipr="trust200902" updates="8955" obsoletes="" submiss ionType="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" t ocDepth="4" symRefs="true" sortRefs="true" version="3">
<front> <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 Proc edure for BGP Flow Specifications</title> <title abbrev="Revised Flowspec Validation Procedure">Revised Validation Proc edure for BGP Flow Specifications</title>
<seriesInfo name="RFC" value="9117"/>
<!-- add 'role="editor"' below for the editors if appropriate --> <author fullname="James Uttaro" initials="J" surname="Uttaro">
<organization>AT&amp;T</organization>
<!-- Another author who claims to be an editor --> <address>
<postal>
<author fullname="James Uttaro" initials="J.U." surname="Uttaro"> <street>200 S. Laurel Ave</street>
<organization>AT&amp;T</organization>
<address>
<postal>
<street>200 S. Laurel Ave</street>
<!-- Reorder these if your country does things differently -->
<city>Middletown</city> <city>Middletown</city>
<region>NJ</region>
<code>07748</code>
<country>United States of America</country>
</postal>
<email>ju1738@att.com</email>
<region>NJ</region>
<code>07748</code>
<country>USA</country>
</postal>
<email>ju1738@att.com</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<author fullname="Juan Alcaide" initials="J.A." surname="Alcaide">
<organization>Cisco</organization>
<address>
<postal>
<street>7100 Kit Creek Road</street>
<!-- Reorder these if your country does things differently -->
<city>Research Triangle Park</city>
<region>NC</region>
<code>27709</code>
<country>USA</country> <author fullname="Juan Alcaide" initials="J" surname="Alcaide">
</postal> <organization>Cisco</organization>
<address>
<postal>
<street>7100 Kit Creek Road</street>
<email>jalcaide@cisco.com</email> <extaddr>Research Triangle Park</extaddr>
<city>Morrisville</city>
<region>NC</region>
<code>27709</code>
<country>United States of America</country>
</postal>
<email>jalcaide@cisco.com</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<author fullname="Clarence Filsfils" initials="C" surname="Filsfils">
<author fullname="Clarence Filsfils" initials="C.F." surname="Filsfils"> <organization>Cisco</organization>
<organization>Cisco</organization> <address>
<email>cf@cisco.com</email>
<address>
<email>cf@cisco.com</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<author fullname="David Smith" initials="D" surname="Smith">
<author fullname="David Smith" initials="D.S." surname="Smith"> <organization>Cisco</organization>
<organization>Cisco</organization> <address>
<postal>
<address> <street>111 Wood Ave South</street>
<postal>
<street>111 Wood Ave South</street>
<!-- Reorder these if your country does things differently -->
<city>Iselin</city> <city>Iselin</city>
<region>NJ</region>
<code>08830</code>
<country>United States of America</country>
</postal>
<email>djsmith@cisco.com</email>
<region>NJ</region> </address>
</author>
<author fullname="Pradosh Mohapatra" initials="P" surname="Mohapatra">
<organization>Sproute Networks</organization>
<address>
<email>mpradosh@yahoo.com</email>
<code>08830</code> </address>
</author>
<date month="August" year="2021" />
<country>USA</country> <area>General</area>
</postal> <workgroup>Network Working Group</workgroup>
<email>djsmith@cisco.com</email> <keyword>BGP flowspec</keyword>
<!-- uri and facsimile elements may also be added --> <abstract>
</address> <t>
</author> 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 RFC 8955 requires that the originator
of the Flow Specification match the originator of the best-match unicast
route for the destination prefix embedded in the Flow Specification. For an
Internal Border Gateway Protocol (iBGP) received route, the originator is
typically a border router within the same autonomous 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
validation procedure described in RFC 8955 will fail in this scenario. The m
odification
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 External Border
Gateway Protocol (eBGP) peer can be validated when such a peer is a BGP
route server.
<author fullname="Pradosh Mohapatra" initials="P.M." surname="Mohapatra"> </t>
<organization>Sproute Networks</organization> <t>
This document updates the validation procedure in RFC 8955.
</t>
</abstract>
</front>
<middle>
<address> <section numbered="true" toc="default">
<email>mpradosh@yahoo.com</email> <name>Introduction</name>
<!-- uri and facsimile elements may also be added --> <t>
</address> <xref target="RFC8955" format="default"/> defines BGP Network Layer
</author> 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 systems avoid carrying the traffic to the downstream
autonomous systems only to be discarded. <xref target="RFC8955"
format="default"/> also enables more granular traffic filtering based
upon 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 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 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, 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>
<xref target="fig_1"/> illustrates this principle. R1 (the upstream r
outer) 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
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.
</t>
<figure anchor="fig_1">
<artwork align="left" name="" type="" alt=""><![CDATA[
R1(AS1) --- RR(AS1) --- ASBR1(AS1) --- ASBR2(AS2)
|
route controller(AS1)
]]></artwork>
</figure>
<t> This document describes a modification to the validation procedure des
cribed in <xref target="RFC8955"
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 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 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>
<date year="2021" /> Throughout this document, some references are made to
AS_CONFED_SEQUENCE segments; see Sections <xref
target="REV_ROUTE" format="counter"/> and <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>
<!-- If the month and year are both specified and are the current ones, xml2r </section>
fc will fill
in the current day for you. If only the current year is specified, xml2r
fc 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 sp
ecified for the
purpose of calculating the expiry date). With drafts it is normally suf
ficient to
specify just the year. -->
<!-- Meta-data Declarations --> <section numbered="true" toc="default">
<name>Definitions of Terms Used in This Memo</name>
<area>General</area> <dl>
<workgroup>Network Working Group</workgroup> <dt>Local Domain:
</dt>
<dd>the local AS or the local confederation of ASes <xref target="RFC5065"
format="default"/>.
</dd>
<!-- WG name at the upperleft corner of the doc, <dt>eBGP:
IETF is fine for individual submissions. </dt>
If this element is not present, the default is "Network Working Group", <dd>BGP peering to a router not within the Local Domain.</dd>
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>BGP flowspec</keyword> <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>
<!-- Keywords will be incorporated into HTML output </dl>
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>
<t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
This document describes a modification to the validation procedure IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
defined for the dissemination of BGP Flow Specifications. The NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
dissemination of BGP Flow Specifications as specified in <xref target="RFC895 RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
5" /> requires that the originator "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
of the Flow Specification matches the originator of the best-match be interpreted as
unicast route for the destination prefix embedded in the Flow described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
Specification. For an iBGP received route, the originator is typically when, and only when, they appear in all capitals, as shown here.
a border router within the same autonomous system. The </t>
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 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 peer can be validated when such
peer is a BGP route server.
</t> </section>
<t>
This document updates the validation procedure in <xref target="RFC8955"
/>.
</t>
</abstract>
</front>
<middle> <section numbered="true" toc="default">
<section title="Requirements Language"> <name>Motivation</name>
<t> <t>Step (b) of the validation procedure in <xref sectionFormat="of"
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL section="6" target="RFC8955" format="default"/> is defined with the
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", underlying assumption that the Flow Specification NLRI traverses the
"MAY", and "OPTIONAL" in this document are to be interpreted as same path, in the inter-domain and intra-domain route distribution
described in BCP 14 <xref target="RFC2119" /> <xref target="RFC8174" /> wh graph, as that of the longest-match unicast route for the destination
en, and only when, they prefix embedded in the Flow Specification.
appear in all capitals, as shown here. </t>
</t> <t>
</section> In the case of inter-domain traffic filtering, the Flow Specification
<section title="Terminology"> originator at the egress border routers of an AS (e.g., RTR-D and RTR-E
<t> of AS1 in <xref target="fig_2"/>) matches the eBGP neighbor that
Local Domain: the local AS or the local confederation of ASes <xref targe advertised the longest match destination prefix (see RTR-F and RTR-G,
t="RFC5065" />. respectively, in <xref target="fig_2"/>).
</t> </t>
<t> <t>
eBGP: BGP peering to a router not within the Local Domain. Similarly, at the upstream routers of an AS (see RTR-A and RTR-B of
</t> AS1 in <xref target="fig_2"/>), the Flow Specification originator
<t> matches the egress iBGP border routers that had advertised the
iBGP: BGP peering not eBGP as defined above (i.e. both classic iBGP and a unicast route for the best-match destination prefix (see RTR-D and
ny form of eBGP peering with a router within the same confederation). RTR-E, respectively, in <xref target="fig_2"/>). This is true even
</t> when upstream routers select paths from different egress border
</section> routers as the best route based upon IGP distance. For example, in <xre
<section title="Introduction"> f
<t> target="fig_2"/>:
<xref target="RFC8955" /> defines a BGP NLRI <xref target="RFC4760" /> t </t>
hat can be used to distribute <ul empty="true" spacing="normal">
traffic Flow Specifications amongst BGP speakers in support of traffic <li>RTR-A chooses RTR-D as the best route
filtering. The primary intention of <xref target="RFC8955" /> is to </li>
enable downstream autonomous systems to signal traffic filtering policie <li>RTR-B chooses RTR-E as the best route
s </li>
to upstream autonomous systems. In this way, traffic is filtered closer </ul>
to the source and the upstream autonomous system(s) avoid carrying the t <figure anchor="fig_2">
raffic <artwork align="left" name="" type="" alt=""><![CDATA[
to the downstream autonomous system only to be discarded.
<xref target="RFC8955" /> also enables more granular traffic filtering b
ased upon
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 subject to validi
ty
checks before being considered feasible and subsequently installed with
in the respective Adj-RIB-In.
</t>
<t>
The validation procedure defined within <xref target="RFC8955" /> requi
res that the
originator of the Flow Specification NLRI matches 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 fo
rwarding 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 by a centralized BGP ro
ute 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-m
atch 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 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 recei
ved by RR and R1 (from their point of view, the originator of both the FLow Spec
ification 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 woul
d
still be validated. In both cases, the Flow Specification is originat
ed 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.
</t>
<t>
<?rfc needLines="37" ?>
<figure align="center" anchor="fig_1">
<artwork align="left"><![CDATA[
R1(AS1) --- RR(AS1) --- ASBR1(AS1) --- ASBR2(AS2)
|
route-controller(AS1)
]]></artwork>
</figure>
</t>
<t> This document describes a modification to the <xref target="RFC8955
" /> validation
procedure, 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 path. While the proposed mo
dification
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 has numerous border rout
ers having complex BGP policies.
By relaxing the validation procedure for iBGP, the proposed modificatio
n
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_S
EQUENCE
segments; see Sections 4.1 and 5. 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 targ
et="RFC6472" />.
Refer to <xref target="I-D.ietf-idr-deprecate-as-set-confed-set" /> as well.
</t>
</section>
<section title="Motivation">
<t>Step (b) of the validation procedure in Section 6 of <xref target="RFC89
55" /> 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 origi
nator
at the egress border routers of an AS (e.g. RTR-D and RTR-E of AS1 in Figur
e 2) matches
the eBGP neighbor that advertised the longest match destination prefix
(see RTR-F and RTR-G respectively in Figure 2).
</t>
<t>
Similarly, at the upstream routers of an AS
(see RTR-A and RTR-B of AS1 in Figure 2), the Flow Specification origina
tor 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
in Figure 2).
This is true even when upstream routers select paths from different
egress border routers as best route based upon IGP distance.
For example, in Figure 2:
<list>
<t>RTR-A chooses RTR-D as the best route
</t>
<t>RTR-B chooses RTR-E as the best route
</t>
</list>
</t>
<t>
<?rfc needLines="37" ?>
<figure align="center" anchor="fig_2">
<artwork align="left"><![CDATA[
/ - - - - - - - - - - - - - - / - - - - - - - - - - - - - -
| AS1 | | AS1 |
+-------+ +-------+ +-------+ +-------+
| | | | | | | | | | | |
| RTR-A | | RTR-B | | RTR-A | | RTR-B |
| | | | | | | | | | | |
+-------+ +-------+ +-------+ +-------+
| \ / | | \ / |
iBGP \ / iBGP iBGP \ / iBGP
| \ / | | \ / |
skipping to change at line 363 skipping to change at line 307
- - -|- - - - - - - - -|- - -/ - - -|- - - - - - - - -|- - -/
| | | | | | | |
+-------+ +-------+ +-------+ +-------+
| | | | | | | | | | | |
| RTR-F | | RTR-G | | RTR-F | | RTR-G |
| | | | | | | | | | | |
+-------+ +-------+ +-------+ +-------+
| AS2 | | AS2 |
/ - - - - - - - - - - - - - - / - - - - - - - - - - - - - -
]]></artwork> ]]></artwork>
</figure> </figure>
</t> <t>It is highly desirable that mechanisms exist to protect each AS indepen
<t>It is highly desirable that mechanisms exist to protect each AS independen dently
tly
from network security attacks using the BGP Flow Specification NLRI for from network security attacks using the BGP Flow Specification NLRI for
intra-AS purposes only. Network operators often deploy a dedicated intra-AS purposes only. Network operators often deploy a dedicated
Security Operations Center (SOC) within their AS to monitor and detect such s ecurity attacks. Security Operations Center (SOC) within their AS to monitor and detect such s ecurity attacks.
To mitigate attacks within an AS, operators require To mitigate attacks within an AS, operators require
the ability to originate intra-AS Flow Specification NLRIs from a the ability to originate intra-AS Flow Specification NLRIs from a
central BGP route controller that is not within the data forwarding plane. central BGP route controller that is not within the data forwarding plane.
In this way, operators can direct border routers within their AS with In this way, operators can direct border routers within their AS with
specific attack mitigation actions (drop the traffic, forward to a pipe-clean specific attack-mitigation actions (drop the traffic, forward to a pipe-clean
ing location, etc.). ing location, etc.).
</t> </t>
<t> <t>
In addition, an operator may extend the requirements above for a group of ASe In addition, an operator may extend the requirements above for a group of
s via policy. ASes via policy. This is described in <xref target="REV_ROUTE"/> (<xref targ
This is described below in Section (b.2.3) of the validation procedure. et="b.2.3"
</t> format="none">b.2.3</xref>) of the validation procedure.
<t> </t>
A central BGP route controller that originates a Flow Specification <t>
A central BGP route controller that originates Flow Specification
NLRI should be able to avoid the complexity of having to determine 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 the egress border router whose path was chosen as the best for each
of its neighbors. of its neighbors.
When a central BGP route controller originates a Flow Specification NLRI, the rest of the speakers When a central BGP route controller originates Flow Specification NLRI, the r est of the speakers
within the AS will see the BGP route controller as the originator of the Flow Specification in terms 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) o of the validation procedure rules. Thus, it is necessary to modify step (b) o
f the <xref target="RFC8955" /> f the validation procedure described in <xref target="RFC8955" format="default"/
validation procedure such that an iBGP peer that is not within the data forwa >
rding plane such that an iBGP peer that is not within the data forwarding plane
may originate Flow Specification NLRIs. may originate Flow Specification NLRIs.
</t> </t>
</section>
<section title="Revised Validation Procedure">
<section title="Revision of Route Feasibility">
<t>Step (b) of the validation procedure specified in Section 6 of <xref target="
RFC8955" /> is redefined as follows:
<list style="hanging" hangIndent="3">
<t hangText="b)">One of the following conditions MUST hold true:
<list style="numbers">
<t>The originator of the Flow Specification matches the originator o
f the best-match
unicast route for the destination prefix embedded in the
Flow Specification (this
is the unicast route with the longest possible prefix len
gth covering the destination prefix
embedded in the Flow Specification).
</t>
<t>The AS_PATH attribute of the Flow Specification is empty or conta
ins only an AS_CONFED_SEQUENCE segment <xref target="RFC5065" />.
<list style="numbers">
<t>This condition SHOULD be enabled by default.
</t>
<t>This condition MAY be disabled by explicit configurat
ion on a BGP speaker.
</t>
<t>As an extension to this rule, a given non-empty AS_PA
TH (besides AS_CONFED_SEQUENCE segments) MAY be
permitted by policy.
</t>
</list>
</t>
</list>
</t>
</list> </section>
<section numbered="true" toc="default">
<name>Revised Validation Procedure</name>
<section anchor="REV_ROUTE" numbered="true" toc="default">
<name>Revision of Route Feasibility</name>
<t>Step (b) of the validation procedure specified in <xref
target="RFC8955" sectionFormat="of" section="6" format="default"/> is
redefined as follows:
</t>
<blockquote>
<dl newline="false" spacing="normal" indent="3">
<dt>b)</dt>
<dd>
<t>One of the following conditions <bcp14>MUST</bcp14> hold true:
</t>
<ol anchor="step_b" spacing="normal" type="1">
<li anchor="b.1">The originator of the Flow Specification matches t
he
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).
</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" format="default"/>.
</t>
<ol spacing="normal">
<li anchor="b.1.1">This condition <bcp14>SHOULD</bcp14> be
enabled by default.
</li>
<li anchor="b.2.2">This condition <bcp14>MAY</bcp14> be disabl
ed by
explicit configuration on a BGP speaker.
</li>
<li anchor="b.2.3">As an extension to this rule, a given non-e
mpty AS_PATH
(besides AS_CONFED_SEQUENCE segments) <bcp14>MAY</bcp14> be
permitted by policy.
</li>
</ol>
</li>
</ol>
</dd>
</dl>
</blockquote>
<t>Explanation:
</t> </t>
<t>Explanation: <ul empty="true" spacing="normal">
<list> <li>
<t>
Receiving either an empty AS_PATH or one Receiving either an empty AS_PATH or one
with only an AS_CONFED_SEQUENCE segment indicates that the Flow Specification wa s with only an AS_CONFED_SEQUENCE segment indicates that the Flow Specification wa s
originated inside the Local Domain. originated inside the Local Domain.
</t> </li>
<t> <li>
With the above modification to the <xref target="RFC8955" /> validation procedur With the above modification to the <xref target="RFC8955" format="default"/> val
e, a BGP peer within the Local Domain idation procedure, a BGP peer within the Local Domain
that is not within the data forwarding path can originate a Flow Specification. that is not within the data-forwarding path can originate a Flow Specification.
</t> </li>
<t> <li>
Disabling the new condition above (b.2.2) could be a good practice if the operat Disabling the new condition above (see <xref target="b.2.2" format="none">step
or knew with b.2.2</xref> in <xref target="REV_ROUTE"/>) could be a good practice if the
certainty that a Flow Specification would not be originated inside the Local Dom operator knew with certainty that a Flow Specification would not be originated
ain. An additional case would be if it was known for a fact that only inside the Local Domain. An additional case would be if it was known for a
the right egress border routers (i.e. those that were also egress border routers fact that only the right egress border routers (i.e., those that were also
for the best routes) egress border routers for the best routes) were originating Flow Specification
were originating a Flow Specification NLRI. NLRI.
</t> </li>
<t> <li>
Also, policy may be useful to permit a specific set of non-empty AS_PATHs (b.2.3 Also, policy may be useful to permit a specific set of non-empty AS_PATHs (see
). For example, <xref target="b.2.3" format="none">step b.2.3</xref> in <xref
it could validate a Flow Specification whose AS_PATH contained only an AS_SEQUEN target="REV_ROUTE"/>). For example, it could validate a Flow Specification
CE segment with ASes that were all known whose AS_PATH contained only an AS_SEQUENCE segment with ASes that were all
to belong to the same administrative domain. known to belong to the same administrative domain.
</t> </li>
</list> </ul>
</t> </section>
</section>
<section title="Revision of AS_PATH Validation"> <section anchor="AS_PATH" numbered="true" toc="default">
<t> <name >Revision of AS_PATH Validation</name>
Section 6 of <xref target="RFC8955" /> states: <t>
<xref target="RFC8955" sectionFormat="of" section="6" format="default"/>
states:
</t> </t>
<t> <ul empty="true" spacing="normal">
<list> <li>
<t>
BGP implementations MUST also enforce that the <blockquote>
BGP implementations <bcp14>MUST</bcp14> also enforce that the
AS_PATH attribute of a route received via the External Border Gateway Protocol ( eBGP) 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 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. becomes necessary to enforce it here for security reasons.
</t> </blockquote>
</list> </li>
</t> </ul>
<t> <t>
This rule prevents the exchange of BGP Flow Specification NLRIs at This rule prevents the exchange of BGP Flow Specification NLRIs at Internet
Internet exchanges with BGP route servers, which by design don't insert exchanges with BGP route servers, which by design don't insert their own AS
their own AS number into the AS_PATH (Section 2.2.2.1 of <xref target="RFC7947" number into the AS_PATH (<xref target="RFC7947" sectionFormat="of"
/>). section="2.2.2.1" format="default"/>). Therefore, this document also
Therefore, this document also redefines the <xref target="RFC8955" /> AS_PATH va redefines the <xref target="RFC8955" format="default"/> AS_PATH validation
lidation
procedure referenced above as follows: procedure referenced above as follows:
</t> </t>
<t> <ul empty="true" spacing="normal">
<list> <li>
<t> <blockquote>
BGP Flow Specification implementations MUST enforce that the AS in the left-most BGP Flow Specification implementations <bcp14>MUST</bcp14> enforce that the AS i
position of the AS_PATH attribute of a Flow Specification route n 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 l eft-most position of the AS_PATH attribute of the best-match unicast route for t he destination prefix received via the External Border Gateway Protocol (eBGP) matches the AS in the l eft-most position of the AS_PATH attribute of the best-match unicast route for t he destination prefix
embedded in the Flow Specification NLRI. embedded in the Flow Specification NLRI.
</t> </blockquote>
</list> </li>
</t> </ul>
<t> <t>
Explanation: Explanation:
<list>
<t>
For clarity, the AS in the left-most position of the AS_PATH means the AS that w
as last added to an AS_SEQUENCE.
</t> </t>
<t>This proposed modification enables the exchange of
<ul empty="true" spacing="normal">
<li>For clarity, the AS in the left-most position of the AS_PATH means the AS th
at was last added to an AS_SEQUENCE.
</li>
<li>This proposed modification enables the exchange of
BGP Flow Specification NLRIs at Internet exchanges with BGP Flow Specification NLRIs at Internet exchanges with
BGP route servers while at the same time, for security reasons, BGP route servers while at the same time, for security reasons,
prevents an eBGP peer from advertising an inter-domain prevents an eBGP peer from advertising an inter-domain
Flow Specification for a destination prefix that it does Flow Specification for a destination prefix that it does
not provide reachability information for. not provide reachability information for.
</t> </li>
<t> <li>
Comparing only the left-most AS in the AS-PATH for eBGP learned Flow Specificati Comparing only the left-most AS in the AS-PATH for eBGP-learned Flow Specificati
on NLRIs is on NLRIs is
roughly equivalent to checking the neighboring AS. roughly equivalent to checking the neighboring AS.
If the peer is a route server, security is necessarily weakened for the Flow Spe If the peer is a route server, security is necessarily weakened for the Flow Spe
cification NLRI, as it is for any unicast route advertised from a route server. cification NLRI, as it is for any unicast route advertised from a route server.
An example is discussed in the Security Considerations Section. An example is discussed in the <xref target="Security" format="none">Security Co
</t> nsiderations</xref> section.
<t> </li>
Redefinition of this AS_PATH validation rule for a Flow Specification does not m <li>
ean that the original rule in <xref target="RFC8955" /> cannot be enforced as we Redefinition of this AS_PATH validation rule for a Flow Specification does not
ll. mean that the original rule in <xref target="RFC8955" format="default"/>
Its enforcement remains optional per Section 6.3 of <xref target="RFC4271" />. cannot be enforced as well. Its enforcement remains optional per <xref
That is, a BGP speaker can enforce the first AS in the AS_PATH to be the same as target="RFC4271" sectionFormat="of" section="6.3" format="default"/>. That
the neighbor AS for a route belonging to any Address Family (including Flow Spe is, a BGP speaker can enforce the first AS in the AS_PATH to be the same as
cification Address Family). the neighbor AS for a route belonging to any Address Family (including Flow
If the BGP speaker peer is not a route server, when enforcing this optional rule Specification Address Family). If the BGP speaker peer is not a route server,
, the security characteristics are exactly equivalent to those specified in <xre when enforcing this optional rule, the security characteristics are exactly
f target="RFC8955" />. equivalent to those specified in <xref target="RFC8955" format="default"/>.
</t> </li>
<t> <li>
Alternatively, enforcing this optional rule for unicast routes (even if not enfo rced on Flow Specification NLRIs) achieves exactly the same security characteris tics. Alternatively, enforcing this optional rule for unicast routes (even if not enfo rced on Flow Specification NLRIs) achieves exactly the same security characteris tics.
The reason is that, after all validations, the neighboring AS will be the same a s 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 The reason is that, after all validations, the neighboring AS will be the same a s 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 N LRI. Therefore, the neighboring AS will be the same as the left-most AS in the A S_PATH for the Flow Specification NLRI (as the original will be the same as the left-most AS in the AS_PATH for the Flow Specification N LRI. Therefore, the neighboring AS will be the same as the left-most AS in the A S_PATH for the Flow Specification NLRI (as the original
AS_PATH validation rule in <xref target="RFC8955" /> states). AS_PATH validation rule in <xref target="RFC8955" format="default"/> states).
</t> </li>
<t> <li>
Note, however, that not checking the full AS_PATH allows any rogue or misconfigu Note, however, that not checking the full AS_PATH allows any rogue or
red AS the ability to originate undesired misconfigured AS the ability to originate undesired Flow Specifications. This
Flow Specifications. This is a BGP security threat, already present on <xref tar is a BGP security threat, already present in <xref target="RFC8955"
get="RFC8955" />, but out of the scope of this document. format="default"/>, but out of the scope of this document.
</t> </li>
<t> <li>
Using the new rule to validate a Flow Specification route received from a peer b elonging to the same Local Domain Using the new rule to validate a Flow Specification route received from a peer b elonging to the same Local Domain
is out of the scope of this document. Note that although it's possible, its util ity is dubious. is out of the scope of this document. Note that although it's possible, its util ity is dubious.
Although it is conceivable that a router in the same Local Domain could send a r ogue update, only eBGP risk is considered within this document Although it is conceivable that a router in the same Local Domain could send a r ogue update, only eBGP risk is considered within this document
(in the same spirit as the aforementioned AS_PATH validation in <xref target="RF (in the same spirit as the aforementioned AS_PATH validation in <xref target="RF
C4271" />). C4271" format="default"/>).
</t> </li>
</list> </ul>
</t> </section>
</section> </section>
</section> <section numbered="true" toc="default" anchor="topology">
<section title="Topology Considerations"> <name>Topology Considerations</name>
<t> <t>
<xref target="RFC8955" /> indicates that the originator may refer to the origina <xref target="RFC8955" format="default"/> indicates that the originator may
tor path attribute (ORIGINATOR_ID) refer to the originator path attribute (ORIGINATOR_ID) or (if the attribute is
or (if the attribute is not present) the transport address of the peer from whic not present) the transport address of the peer from which the BGP speaker
h the BGP speaker received the update. received the update. If the latter applies, a network should be designed so
If the latter applies, a network should be designed so it has a congruent topolo it has a congruent topology amongst unicast routes and Flow Specification
gy amongst unicast routes and Flow Specification routes. routes. By congruent topology, it is understood that the two routes (i.e.,
By congruent topology, it is understood that the two routes (i.e. the Flow Speci the Flow Specification route and its best-match unicast route) are learned
fication route and its best-match unicast route) are learned from the same peer from the same peer across the AS. That would likely not be true, for
across the AS. instance, if some peers only negotiated one Address Family or if each Address
That would likely not be true, for instance, if some peers only negotiated one A Family peering had a different set of policies. Failing to have a congruent
ddress Family or if each Address Family peering had a different set of policies. topology would result in step (<xref format="none" target="b.1">b.1</xref>) of t
Failing to have a congruent topology he
would result in step (b.1) of the validation procedure to fail. validation procedure to fail.
</t> </t>
<t> <t>
With the additional second condition (b.2) in the validation procedure, non-cong With the additional second condition (<xref target="b.2" format="none">b.2</xref
ruent topologies are supported within the Local Domain if the Flow Specification >) in the validation procedure, non-congruent topologies are supported within th
e Local Domain if the Flow Specification
is originated within the Local Domain. is originated within the Local Domain.
</t> </t>
<t> <t>
Explanation: Explanation:
<list>
<t>
Consider the following scenarios of a non-congruent topology without the second
condition (b.2) being added to the validation procedure:
<list style="numbers">
<t>Consider a topology with two BGP speakers with two iBGP peering sessions betw
een 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. a route
reflector receiving routes from its clients). In this case, the Flow Specificati
on validation procedure will fail because of the first condition (b.1).
</t> </t>
<t>Consider a confederation of ASes with local AS X and local AS Y (both belongi <ul empty="true">
ng to the same Local Domain), and a given BGP speaker X1 inside local AS X. <li><t>Consider the following scenarios of a non-congruent topology without the
second condition (<xref target="b.2" format="none">b.2</xref>) being added to th
e validation 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., a route reflector receiving routes from its
clients). In this case, the Flow Specification validation procedure
will fail because of the first condition (<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 loc
al AS X.
The ORIGINATOR_ID attribute is not advertised when propagating routes across loc al ASes. The ORIGINATOR_ID attribute is not advertised when propagating routes across loc al ASes.
Let's assume the Flow Specification route is received from peer Y1 and the best- match unicast route 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. is received from peer Y2. Both peers belong to local AS Y.
The Flow Specification validation procedure will also fail because of the first The Flow Specification validation procedure will also fail because of the first
condition (b.1). condition (<xref target="b.1" format="none">b.1</xref>).
</t> </li>
</list> </ol>
</t> </li>
<t> <li>
Consider now that the second conditon (b.2) is added to the validation procedure Consider now that the second condition (<xref target="b.2" format="none">b.2</xr
. In the scenarios above, if Flow Specifications are originated in ef>) is
the same Local Domain, the AS_PATH will be empty or contain only added to the validation procedure. In the scenarios above, if Flow
an AS_CONFED_SEQUENCE segment. Condition (b.2) will evaluate to true. Therefore Specifications are originated in the same Local Domain, the AS_PATH will be
, using the empty or contain only an AS_CONFED_SEQUENCE segment. Condition (<xref
second condition (b.2), as defined by this document, guarantees that the overall target="b.2" format="none">b.2</xref>) will evaluate to true. Therefore, using t
validation procedure will pass. Thus, non-congruent topologies he second
are supported if the Flow Specification is originated in the same condition (<xref target="b.2" format="none">b.2</xref>), as defined by this docu
Local Domain. ment,
</t> guarantees that the overall validation procedure will pass. Thus,
<t> non-congruent topologies are supported if the Flow Specification is originated
Flow Specifications originated in a different Local in the same Local Domain.
Domain sill need a congruent topology. The reason is that in a non-congruent top </li>
ology the second condition <li>
(b.2) evaluates to false and only the first condition (b.1) is evaluated. Flow Specifications originated in a different Local Domain sill need a
</t> congruent topology. The reason is that in a non-congruent topology, the second
</list> condition (<xref target="b.2" format="none">b.2</xref>) evaluates to false and
</t> only the first condition (<xref target="b.1" format="none">b.1</xref>) is
</section> evaluated.
<section anchor="IANA" title="IANA Considerations"> </li>
<t>This document includes no request to IANA.</t> </ul>
</section>
</section> <section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name>
<section anchor="Security" title="Security Considerations"> <t>This document has no IANA actions.</t>
</section>
<section anchor="Security" numbered="true" toc="default">
<name>Security Considerations</name>
<t> <t>
This document updates the route feasibility validation procedures for Flow S This document updates the route feasibility validation procedures for Flow
pecifications Specifications learned from iBGP peers and through route servers. This
learned from iBGP peers and through route servers. This change is in change is in line with the procedures described in <xref target="RFC8955"
line with the procedures described in <xref target="RFC8955" /> and, thus, s format="default"/> and, thus, security characteristics remain essentially
ecurity equivalent to the existing security properties of BGP unicast routing,
characteristics remain essentially equivalent to the existing security prope except as detailed below.
rties of BGP </t>
unicast routing, except as detailed below. <t>
</t> The security considerations discussed in <xref target="RFC8955" format="defa
<t> ult"/> apply to this
The security considerations discussed in <xref target="RFC8955" /> apply to
this
specification as well. specification as well.
</t> </t>
<t>
<t> This document makes the original AS_PATH validation rule (<xref
This document makes the original AS_PATH validation rule (Section 6.3 of <xre target="RFC4271" sectionFormat="of" section="6.3" format="default"/>) again
f target="RFC4271" />) again OPTIONAL <bcp14>OPTIONAL</bcp14> (<xref target="AS_PATH"/>) for Flow Specification Add
(Section 5.2) for Flow Specification Address Family (the rule is no longer ma ress Family (the rule is no longer
ndatory as had been specified by [RFC8955]). mandatory as had been specified by <xref target="RFC8955"/>). If that origin
If that original rule is not enforced for Flow Specification it may introduce al rule is
some new security risks. not enforced for Flow Specification, it may introduce some new security
A speaker in AS X peering with a route server could advertise a rogue Flow risks. A speaker in AS X peering with a route server could advertise a
Specification route whose first AS in AS_PATH was Y. Assume Y is the first AS rogue Flow Specification route whose first AS in AS_PATH was Y. Assume Y is
in the AS_PATH of the best-match unicast route. the first AS in the AS_PATH of the best-match unicast route. When the
When the route server advertises the Flow Specification to a speaker in AS Z, route server advertises the Flow Specification to a speaker in AS Z, it
it will be validated by that speaker. will be validated by that speaker. This risk is impossible to prevent if
This risk is impossible to prevent if the Flow Specification route is receive the Flow Specification route is received from a route server peer. If
d configuration (or other means beyond the scope of this document) indicates
from a route server peer. that the peer is not a route server, that optional rule
If configuration (or other means beyond the scope of this document) <bcp14>SHOULD</bcp14> be enforced for unicast and/or for Flow
indicates that the peer is not a route server, that optional rule Specification routes (as discussed in the <xref target="AS_PATH" format="none
SHOULD be enforced, for unicast and/or for Flow Specification routes ">Revision of AS_PATH Validation</xref> section, just
(as discussed in the AS_PATH Validation Section, just enforcing it in one of tho enforcing it in one of those Address Families is enough). If the indication
se Addres Families is enough). is that the peer is not a route server or there is no conclusive
If the indication is that the peer is not a route server or there is no conclusi indication, that optional rule <bcp14>SHOULD NOT</bcp14> be enforced.
ve indication, that optional rule SHOULD NOT be enforced. </t>
</t> <t>
<t>
A route server itself may be in a good position to enforce the AS_PATH valida tion rule described A route server itself may be in a good position to enforce the AS_PATH valida tion rule described
in the previous paragraph. If it is known that a route server is not peering with any other route server, 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. it can enforce the AS_PATH validation rule across all its peers.
</t> </t>
<t> <t>
BGP updates learned from iBGP peers are considered BGP updates learned from iBGP peers are considered
trusted, so the Traffic Flow Specifications contained in BGP updates trusted, so the Traffic Flow Specifications contained in BGP updates
are also considered trusted. Therefore, it is not required to are also considered trusted. Therefore, it is not required to
validate that the originator of an intra-domain Traffic Flow validate that the originator of an intra-domain Traffic Flow
Specification matches the originator of the best-match unicast route Specification matches the originator of the best-match unicast route
for the destination prefix embedded in that Flow Specification. Note tha t this trustworthiness consideration is not for the destination prefix embedded in that Flow Specification. Note tha t this trustworthiness consideration is not
absolute and the new possibility that an iBGP speaker could send a rogue Flo w Specification is introduced. absolute and the new possibility that an iBGP speaker could send a rogue Flo w Specification is introduced.
</t> </t>
<t> <t>
The changes in Section 5.1 don't affect the validation procedures for eB The changes in <xref target="REV_ROUTE"/> don't affect the validation
GP-learned routes. procedures for eBGP-learned routes.
</t> </t>
<t> <t>
It's worth mentioning that allowing (or making operationally feasible) to It's worth mentioning that allowing (or making operationally feasible)
originate Flow Specifications within the Local Domain makes the network Flow Specifications to originate within the Local Domain makes
overall more secure. Flow Specifications can be originated more readily d the network overall more secure. Flow Specifications can be originated
uring attacks and improve the stability and security of the network. more readily during attacks and improve the stability and security of
</t> the network.
</section> </t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to thank 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 for their re
view comments.
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** --> </middle>
<back> <back>
<references title="Normative References"> <displayreference target="I-D.ietf-idr-deprecate-as-set-confed-set" to="CONFED-S
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8 ET"/>
955.xml">?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2
119.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8
174.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.4
760.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.7 <references>
947.xml"?> <name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8955.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4271.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4760.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5065.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7947.xml"/>
</references>
<references>
<name>Informative References</name>
</references> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D .ietf-idr-deprecate-as-set-confed-set.xml"/>
<references title="Informative References"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml-ids/refe FC.6472.xml"/>
rence.I-D.ietf-idr-deprecate-as-set-confed-set.xml"?> </references>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/referen </references>
ce.RFC.6472.xml"?> <section anchor="Acknowledgements" numbered="false" toc="default">
</references> <name>Acknowledgements</name>
<t>The authors would like to thank <contact fullname="Han Nguyen"/> for
his direction on this work as well as <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>
</back> </back>
</rfc> </rfc>
 End of changes. 69 change blocks. 
636 lines changed or deleted 565 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/