draft-ietf-idr-bgp-flowspec-oid-12.txt   draft-ietf-idr-bgp-flowspec-oid-13.txt 
Network Working Group J. Uttaro Network Working Group J. Uttaro
Internet-Draft AT&T Internet-Draft AT&T
Updates: 5575bis (if approved) J. Alcaide Updates: 8955 (if approved) J. Alcaide
Intended status: Standards Track C. Filsfils Intended status: Standards Track C. Filsfils
Expires: January 9, 2021 D. Smith Expires: October 14, 2021 D. Smith
Cisco Cisco
P. Mohapatra P. Mohapatra
Sproute Networks Sproute Networks
July 8, 2020 April 12, 2021
Revised Validation Procedure for BGP Flow Specifications Revised Validation Procedure for BGP Flow Specifications
draft-ietf-idr-bgp-flowspec-oid-12 draft-ietf-idr-bgp-flowspec-oid-13
Abstract Abstract
This document describes a modification to the validation procedure This document describes a modification to the validation procedure
defined for the dissemination of BGP Flow Specifications. The defined for the dissemination of BGP Flow Specifications. The
dissemination of BGP Flow Specifications requires that the originator dissemination of BGP Flow Specifications requires that the originator
of the Flow Specification matches the originator of the best-match of the Flow Specification matches the originator of the best-match
unicast route for the destination prefix embedded in the Flow unicast route for the destination prefix embedded in the Flow
Specification. This allows only BGP speakers within the data Specification. For an iBGP received route, the originator is
forwarding path (such as autonomous system border routers) to typically a border router within the same autonomous system. The
originate BGP Flow Specifications. Though it is possible to objective is to allow only BGP speakers within the data forwarding
disseminate such Flow Specifications directly from border routers, it path to originate BGP Flow Specifications. Sometimes it is desirable
may be operationally cumbersome in an autonomous system with a large to originate the BGP Flow Specification any place within the
number of border routers having complex BGP policies. The autonomous system itself, for example, from a centralized BGP route
modification proposed herein enables Flow Specifications to be controller. However, the validation procedure will fail in this
originated from a centralized BGP route controller. 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 AS_PATH validation rules so Flow
Specifications received from an eBGP peer can be validated when such
peer is a BGP route server.
This document updates RFC5575bis. This document updates the validation procedure in RFC8955.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 9, 2021. This Internet-Draft will expire on October 14, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Revised Validation Procedure . . . . . . . . . . . . . . . . 5 4. Revised Validation Procedure . . . . . . . . . . . . . . . . 6
4.1. Revision of Route Feasibility . . . . . . . . . . . . . . 5 4.1. Revision of Route Feasibility . . . . . . . . . . . . . . 6
4.2. Revision of AS_PATH Validation . . . . . . . . . . . . . 6 4.2. Revision of AS_PATH Validation . . . . . . . . . . . . . 7
5. Other RFC5575bis Considerations . . . . . . . . . . . . . . . 7 5. Topology Considerations . . . . . . . . . . . . . . . . . . . 8
6. Topology Considerations . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 9. Normative References . . . . . . . . . . . . . . . . . . . . 11
10. Normative References . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Requirements Language 1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Introduction 2. Introduction
[I-D.ietf-idr-rfc5575bis] defined a new BGP [RFC4271] capability that [RFC8955] defines a BGP NLRI [RFC4271] that can be used to distribute
can be used to distribute traffic Flow Specifications amongst BGP traffic Flow Specifications amongst BGP speakers in support of
speakers in support of traffic filtering. The primary intention of traffic filtering. The primary intention of [RFC8955] is to enable
[I-D.ietf-idr-rfc5575bis] is to enable downstream autonomous systems downstream autonomous systems to signal traffic filtering policies to
to signal traffic filtering policies to upstream autonomous systems. upstream autonomous systems. In this way, traffic is filtered closer
In this way, traffic is filtered closer to the source and the to the source and the upstream autonomous system(s) avoid carrying
upstream autonomous system(s) avoid carrying the traffic to the the traffic to the downstream autonomous system only to be discarded.
downstream autonomous system only to be discarded. [I-D.ietf-idr- [RFC8955] also enables more granular traffic filtering based upon
rfc5575bis] also enables more granular traffic filtering based upon
upper layer protocol information (e.g., protocol port numbers) as upper layer protocol information (e.g., protocol port numbers) as
opposed to coarse IP destination prefix-based filtering. Flow opposed to coarse IP destination prefix-based filtering. Flow
specification NLRIs received from a BGP peer are subject to validity specification NLRIs received from a BGP peer are subject to validity
checks before being considered feasible and subsequently installed checks before being considered feasible and subsequently installed
within the respective Adj-RIB-In. within the respective Adj-RIB-In.
The validation procedure defined within [I-D.ietf-idr-rfc5575bis] The validation procedure defined within [RFC8955] requires that the
requires that the originator of the Flow Specification NLRI matches originator of the Flow Specification NLRI matches the originator of
the originator of the best-match unicast route for the destination the best-match unicast route for the destination prefix embedded in
prefix embedded in the Flow Specification. This allows only BGP the Flow Specification. The aim is making sure that only speakers on
speakers within the data forwarding path (such as autonomous system the forwarding path can originate the Flow Specification. Let's
border routers) to originate BGP Flow Specification NLRIs. Though it consider the particular case where the Flow Specification is
is possible to disseminate such Flow Specification NLRIs directly originated in any location within the same autonomous system than the
from border routers, it may be operationally cumbersome in an speaker performing the validation (for example by a centralized BGP
autonomous system with a large number of border routers having route controller), and the best-match unicast route is originated in
complex BGP policies. another autonomous system. In order for validation to succeed for a
Flow Specification received from an iBGP peer, it could be possible
to disseminate such Flow Specification NLRIs directly from the
specific border router (within the local autonomous system) that is
advertising the corresponding best-match unicast route to the local
autonomous system. This approach would be, however, operationally
cumbersome in an autonomous system with a large number of border
routers having complex BGP policies.
This document describes a modification to the [I-D.ietf-idr- Figure 1 illustrates this principle. R1 (the upstream router) and RR
rfc5575bis] validation procedure allowing Flow Specification NLRIs to need to validate the Flow Specification whose embedded destination
be originated from a centralized BGP route controller within the prefix has a best-match unicast route (dest-route) originated by
local autonomous system that is not in the data forwarding path. ASBR2. ASBR2 could originate the Flow Specification, and it would be
While the proposed modification cannot be used for inter-domain validated when received by RR and R1. Sometimes the Flow
coordination of traffic filtering, it greatly simplifies distribution Specification needs to be originated on AS1. ASBR1 could originate
of intra-domain traffic filtering policies within an autonomous it, and Flow Specification would still be validated. In both cases,
system which has a large number of border routers having complex BGP the Flow Specification is originated by a router in the same
policies. By relaxing the validation procedure for iBGP, the forwarding path as the dest-route. For the case where AS1 has
proposed modification allows Flow Specifications to be distributed in thousands of ASBRs, it becomes impractical to originate different
a standard and scalable manner throughout an autonomous system. rules on each ASBR in AS1 based on which ASBR each dest- route is
learned from. The objective is to advertise all the Flow
Specifications from the same route-controller.
R1(AS1) --- RR(AS1) --- ASBR1(AS1) --- ASBR2(AS2)
|
route-controller(AS1)
Figure 1
This document describes a modification to the [RFC8955] validation
procedure allowing Flow Specification NLRIs to be originated from a
centralized BGP route controller within the local autonomous system
that is not 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 an autonomous system which has a large
number of 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 an autonomous system.
3. Motivation 3. Motivation
Step (b) of the validation procedure in [I-D.ietf-idr-rfc5575bis], Step (b) of the validation procedure in [RFC8955], section 6 is
section 6 is defined with the underlying assumption that the Flow defined with the underlying assumption that the Flow Specification
Specification NLRI traverses the same path, in the inter-domain and NLRI traverses the same path, in the inter-domain and intra-domain
intra-domain route distribution graph, as that of the longest-match route distribution graph, as that of the longest-match unicast route
unicast route for the destination prefix embedded in the Flow for the destination prefix embedded in the Flow Specification.
Specification.
In the case of inter-domain traffic filtering, the Flow Specification In the case of inter-domain traffic filtering, the Flow Specification
originator at the egress border routers of an AS (e.g. RTR-D and originator at the egress border routers of an AS (e.g. RTR-D and
RTR-E of ASN1 in figure 1) matches the eBGP neighbor that advertised RTR-E of AS1 in Figure 2) matches the eBGP neighbor that advertised
the longest match destination prefix (see RTR-F and RTR-G the longest match destination prefix (see RTR-F and RTR-G
respectively in figure 1). Similarly, at the ingress border routers respectively in Figure 2).
of ASN (see RTR-A and RTR-B of ASN1 in figure 1), 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 in figure 1). This is true
even when ingress border routers select paths from different egress
border routers as best path based upon IGP distance. For example, in
figure 1:
RTR-A chooses RTR-D's path as best Similarly, at the upstream routers of an AS (see RTR-A and RTR-B of
AS1 in Figure 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
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:
RTR-B chooses RTR-E as the best path RTR-A chooses RTR-D as the best route
RTR-B chooses RTR-E as the best route
/ - - - - - - - - - - - - - - / - - - - - - - - - - - - - -
| ASN1 | | AS1 |
+-------+ +-------+ +-------+ +-------+
| | | | | | | | | | | |
| RTR-A | | RTR-B | | RTR-A | | RTR-B |
| | | | | | | | | | | |
+-------+ +-------+ +-------+ +-------+
| \ / | | \ / |
iBGP \ / iBGP iBGP \ / iBGP
| \ / | | \ / |
+-------+ +-------+
| | | | | | | |
skipping to change at page 4, line 44 skipping to change at page 5, line 37
| | | | | | | |
- - -|- - - - - - - - -|- - -/ - - -|- - - - - - - - -|- - -/
| eBGP eBGP | | eBGP eBGP |
- - -|- - - - - - - - -|- - -/ - - -|- - - - - - - - -|- - -/
| | | | | | | |
+-------+ +-------+ +-------+ +-------+
| | | | | | | | | | | |
| RTR-F | | RTR-G | | RTR-F | | RTR-G |
| | | | | | | | | | | |
+-------+ +-------+ +-------+ +-------+
| ASN2 | | AS2 |
/ - - - - - - - - - - - - - - / - - - - - - - - - - - - - -
Figure 1 Figure 2
It is highly desirable that the mechanisms exist to protect each ASN It is highly desirable that mechanisms exist to protect each AS
independently from network security attacks using the BGP Flow independently from network security attacks using the BGP Flow
Specification NLRI for intra-domain purposes only. Network operators Specification NLRI for intra-AS purposes only. Network operators
often deploy a dedicated Security Operations Center (SOC) within often deploy a dedicated Security Operations Center (SOC) within
their ASN to monitor and detect such security attacks. To mitigate their AS to monitor and detect such security attacks. To mitigate
attacks within a domain (AS or group of ASes), operators require the attacks within an AS, operators require the ability to originate
ability to originate intra-domain Flow Specification NLRIs from a intra-AS Flow Specification NLRIs from a central BGP route controller
central BGP route controller that is not within the data forwarding that is not within the data forwarding plane. In this way, operators
plane. In this way, operators can direct border routers within their can direct border routers within their AS with specific attack
ASN with specific attack mitigation actions (drop the traffic, mitigation actions (drop the traffic, forward to a clean-pipe center,
forward to a clean-pipe center, etc.). etc.).
To originate a Flow Specification NLRI, a central BGP route In addition, an operator MAY extend the requirements above for a
controller must set itself as the originator in the Flow group of ASes via policy. This is described in section (b.2.3) of
Specification NLRI. This is necessary given the route controller is the validation procedure.
originating the Flow Specification rather than reflecting it, and to
avoid the complexity of having to determine the egress border router A central BGP route controller that originates a Flow Specification
whose path was chosen as the best in each of the ingress border NLRI should be able to avoid the complexity of having to determine
routers. Thus, it is necessary to modify step (b) of the [I-D.ietf- the egress border router whose path was chosen as the best for each
idr-rfc5575bis] validation procedure such that an iBGP peer that is of its neighbors. When a central BGP route controller originates a
not within the data forwarding plane may originate Flow Specification Flow Specification NLRI, the rest of the speakers within the AS will
NLRIs. see the BGP 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 [RFC8955] validation procedure such that an
iBGP peer that is not within the data forwarding plane may originate
Flow Specification NLRIs.
4. Revised Validation Procedure 4. Revised Validation Procedure
4.1. Revision of Route Feasibility 4.1. Revision of Route Feasibility
Step (b) of the validation procedure specified in [I-D.ietf-idr- Step (b) of the validation procedure specified in [RFC8955], section
rfc5575bis], section 6 is redefined as follows: 6 is redefined as follows:
b) One of the following conditions MUST hold true: b) One of the following conditions MUST hold true:
1. The originator of the Flow Specification matches the 1. The originator of the Flow Specification matches the
originator of the best-match unicast route for the destination originator of the best-match unicast route for the destination
prefix embedded in the Flow Specification (This is the unicast prefix embedded in the Flow Specification (this is the unicast
route with the longest possible prefix length covering the route with the longest possible prefix length covering the
destination prefix embedded in the Flow Specification). destination prefix embedded in the Flow Specification).
2. The AS_PATH attribute of the Flow Specification does not 2. The AS_PATH attribute of the Flow Specification is empty or
contain AS_SET and/or AS_SEQUENCE segments. contains only AS_CONFED_SEQUENCE and/or AS_CONFED_SET segments
[RFC5065].
1. This condition SHOULD be enabled by default. This default 1. This condition SHOULD be enabled by default (it may be
behavior should validate an empty AS_PATH. disabled by explicit configuration as described on the
next list item (b.2.1)).. an empty AS_PATH.
2. This condition MAY be disabled by configuration on a BGP 2. This condition MAY be disabled by explicit configuration
speaker. on a BGP speaker. A possible case would be if we know for
a fact that only the right egress border routers (i.e.
those that are also egress border routers for the best
routes) are originating a Flow Specification NLRI.
3. As an exception to this rule, a given AS_PATH with AS_SET 3. As an extension to this rule, a given non-empty AS_PATHs
and/or AS_SEQUENCE segments MAY be validated by policy. (or AS_PATHS containing only AS_CONFED_SEQUENCE and/or
AS_CONFED_SET segments), MAY be validated by policy. A
possible case would be if the AS_SEQUENCE and AS_SET
contained only ASes that are known to belong to our own
administrative domain.
Explanation: Explanation:
In this context, an empty AS_PATH means that it does not have In this context, a local domain includes the local AS or the local
AS_SET and/or AS_SEQUENCE segments, and local domain means the confederation [RFC5065]. Receiving either an empty AS_PATH or one
local AS [RFC4271] or the local confederation of ASes (in the case with only AS_CONFED_SEQUENCE and/or AS_CONFED_SET segments
that the local AS belongs to a confederation of ASes [RFC5065]).
Thus, receiving a Flow Specification with an empty AS_PATH
indicates that the Flow Specification was originated inside the indicates that the Flow Specification was originated inside the
local domain. local domain.
With the above modification to the [I-D.ietf-idr-rfc5575bis] With the above modification to the [RFC8955] validation procedure,
validation procedure, a BGP peer within the local domain that is a BGP peer within the local domain that is not within the data
not within the data forwarding path can originate a Flow forwarding path can originate a Flow Specification.
Specification.
Disabling the new condition above (b.2.2) may be a good practice Disabling the new condition above (b.2.2) may be a good practice
when the operator knows with certainty that there is not a Flow when the operator knows with certainty that a Flow Specification
Specification originated inside the local domain. will not be originated inside the local domain.
Also, policy may be useful to validate a specific set of non-empty Also, policy may be useful to validate a specific set of non-empty
AS_PATHs (b.2.3). For example, it could validate a Flow AS_PATHs (b.2.3). For example, it could validate a Flow
Specification whose AS_PATH contains only an AS_SEQUENCE with ASes Specification whose AS_PATH contains only an AS_SEQUENCE with ASes
that are all known to belong to the same administrative domain. that are all known to belong to the same administrative domain.
4.2. Revision of AS_PATH Validation 4.2. Revision of AS_PATH Validation
[I-D.ietf-idr-rfc5575bis] states: [RFC8955] states:
o BGP implementations MUST also enforce that the AS_PATH attribute BGP implementations MUST also enforce that the AS_PATH attribute of a
of a route received via the External Border Gateway Protocol route received via the External Border Gateway Protocol (eBGP)
(eBGP) contains the neighboring AS in the left-most position of contains the neighboring AS in the left-most position of the AS_PATH
the AS_PATH attribute. attribute.
This rule prevents the exchange of BGP Flow Specification NLRIs at This rule prevents the exchange of BGP Flow Specification NLRIs at
Internet exchanges with BGP route servers. Therefore, this document Internet exchanges with BGP route servers [RFC7947]. Therefore, this
also redefines the [I-D.ietf-idr-rfc5575bis] AS_PATH validation document also redefines the [RFC8955] AS_PATH validation procedure
procedure referenced above as follows: referenced above as follows:
o BGP Flow Specification implementations MUST enforce that the AS in BGP Flow Specification implementations MUST enforce that the AS in
the left-most position of the AS_PATH attribute of a Flow the left-most position of the AS_PATH attribute of a Flow
Specification route received via the External Border Gateway Specification route received via the External Border Gateway Protocol
Protocol (eBGP) matches the AS in the left-most position of the (eBGP) matches the AS in the left-most position of the AS_PATH
AS_PATH attribute of the best-match unicast route for the attribute of the best-match unicast route for the destination prefix
destination prefix embedded in the Flow Specification NLRI. embedded in the Flow Specification NLRI.
Explanation: Explanation:
For clarity, the AS in the left-most position of the AS_PATH means For clarity, the AS in the left-most position of the AS_PATH means
the AS that was last added to the AS_SEQUENCE. the AS that was last added to the AS_SEQUENCE.
This proposed modification enables the exchange of BGP Flow This proposed modification enables the exchange of BGP Flow
Specification NLRIs at Internet exchanges with BGP route servers Specification NLRIs at Internet exchanges with BGP route servers
while at the same time, for security reasons, prevents an eBGP while at the same time, for security reasons, prevents an eBGP
peer from advertising an inter-domain Flow Specification for a peer from advertising an inter-domain Flow Specification for a
skipping to change at page 7, line 20 skipping to change at page 8, line 25
information for. information for.
Comparing only the last ASes added is sufficient for eBGP learned Comparing only the last ASes added is sufficient for eBGP learned
Flow Specification NLRIs. Requiring a full AS_PATH match would Flow Specification NLRIs. Requiring a full AS_PATH match would
limit origination of inter-domain Flow Specifications to the limit origination of inter-domain Flow Specifications to the
origin AS of the best-match unicast route for the destination origin AS of the best-match unicast route for the destination
prefix embedded in the Flow Specification only. As such, a full prefix embedded in the Flow Specification only. As such, a full
AS_PATH validity check may prevent transit ASes from originating AS_PATH validity check may prevent transit ASes from originating
inter-domain Flow Specifications, which is not desirable. inter-domain Flow Specifications, which is not desirable.
Redefinition of this AS_PATH validation rule for a Flow Note, however, that not checking the full AS_PATH allows any rogue
Specification does not mean that the original rule in [I-D.ietf- or misconfigured AS the ability to originate undesired Flow
idr-rfc5575bis] cannot be enforced as well. Its enforcement Specifications. This is a security BGP threat, but out of the
remains optional per [RFC4271] section 6.3. That is, we can scope of this document.
enforce the first AS in the AS_PATH to be the same as the neighbor
AS for any address-family route (including a Flow Specification).
Using the new rule to validate a Flow Specification received from Redefinition of this AS_PATH validation rule for a Flow
an Internal Border Gateway Protocol (iBGP) peer is out of the Specification does not mean that the original rule in [RFC8955]
scope of this document. Note that in most scenarios such cannot be enforced as well. Its enforcement remains optional per
validation would be redundant. [RFC4271] section 6.3. That is, a BGP speaker can enforce the
first AS in the AS_PATH to be the same as the neighbor AS for any
address-family route (including a Flow Specification).
Using the new rule to validate a Flow Specification route received Using the new rule to validate a Flow Specification route received
from an External Border Gateway Protocol (eBGP) peer belonging to from an External Border Gateway Protocol (eBGP) peer belonging to
the same local domain (in the case that the local AS belongs to a the same local domain (in the case of a confederation) is out of
confederation of ASes) is out of the scope of this document. Note the scope of this document. Note that although it's possible, its
that although it's possible, its utility is dubious. utility is dubious. Although it is conceivable that an router in
the same local domain (both iBGP and eBGP within the same local
5. Other RFC5575bis Considerations domain) could send a rogue update, only eBGP (outside the local
domain) risk is considered within this document (in the same
This section clarifies some of the terminology and rules referenced spirit of the mentioned beforehand AS_PATH validation in
in [I-D.ietf-idr-rfc5575bis]. Namely: [RFC4271]).
o In the context of this document and [I-D.ietf-idr-rfc5575bis],
AS_PATH attribute is defined as the reconstructed AS path
information (by combining AS_PATH and AS4_PATH attributes, if the
BGP speaker is a NEW speaker and receives the route from an OLD
speaker), according to section 4.2.3 of [RFC6793].
o Support for two-octet AS only implementations is out of the scope
of this document (i.e. it's assumed that the BGP speaker supports
[RFC6793]).
6. Topology Considerations 5. Topology Considerations
[I-D.ietf-idr-rfc5575bis] indicates that the originator may refer to [RFC8955] indicates that the originator may refer to the originator
the originator path attribute (ORIGINATOR_ID) or (if the attribute is path attribute (ORIGINATOR_ID) or (if the attribute is not present)
not present) the transport address of the peer from which we received the transport address of the peer from which the BGP speaker received
the update. If the latter applies, a network should be designed so the update. If the latter applies, a network should be designed so
it has a congruent topology. it has a congruent topology amongst ipv4 unicast routes and Flow
Specification routes. By congruent topology, it is understood that
for the two equivalent routes (i.e. the Flow Specification route and
its best-match unicast route) are learned from the same peer accross
the AS. That would likely not be true, for instance, if some peers
only negotiated one type of address-family or if each address-family
had a different set of policies.
With the additional second condition (b.2) in the validation With the additional second condition (b.2) in the validation
procedure, non-congruent topologies are supported within the local procedure, non-congruent topologies are supported within the local
domain if the Flow Specification is originated within the local domain if the Flow Specification is originated within the local
domain. domain.
Explanation: Explanation:
Consider the following scenarios without the second condition Consider the validation procedure preceding this document. The
(b.2) being added to the validation procedure: second condition (b.2) does not exist. The two following
scenarios have a non-congruent topology:
1. Consider a topology with two BGP speakers with two peering 1. Consider a topology with two BGP speakers with two peering
sessions between them, one for unicast and one for Flow sessions between them, one for unicast and one for Flow
Specification. This is a non-congruent topology. Let's Specification. This is a non-congruent topology. Let's
assume that the ORIGINATOR_ID attribute was not received (e.g. assume that the ORIGINATOR_ID attribute was not received (e.g.
a route reflector receiving routes from its clients). In this a route reflector receiving routes from its clients). In this
case, the Flow Specification validation procedure will fail case, the Flow Specification validation procedure will fail
because of the first condition (b.1). because of the first condition (b.1).
2. Consider a topology with a BGP speaker within a confederation 2. Consider a topology with a BGP speaker within a confederation
of ASes, inside local AS X. ORIGINATOR_ID attribute is not of ASes, inside local AS X. The ORIGINATOR_ID attribute is
advertised within the local domain. Let's assume the Flow not advertised within the local domain. Let's assume the Flow
Specification route is received from peer A and the best-match Specification route is received from peer A and the best-match
unicast route is received from peer B. Both peers belong in unicast route is received from peer B. Both peers belong to
local AS Y. Both AS X and AS Y belong to the same local local AS Y. Both AS X and AS Y belong to the same local
domain. The Flow Specification validation procedure will also domain. The Flow Specification validation procedure will also
fail because of the first condition (b.1). fail because of the first condition (b.1).
In the examples above, if Flow Specifications are originated in In the scenarios above, if Flow Specifications are originated in
the same local domain, AS_PATH will not contain AS_SET and/or the same local domain, the AS_PATH will be empty or contain just
AS_SEQUENCE segments. When the second condition (b.2) in the AS_CONFED_SEQUENCE and/or AS_CONFED_SET segments. Condition (b.2)
validation procedure is used, the validation procedure will pass. evaluates to true. Therefore, using the second condition (b.2),
Thus, non-congruent topologies are supported if the Flow as defined by this document, guarantees that the overall
Specification is originated in the same local domain. validation procedure will pass. Thus, non-congruent topologies
are supported if the Flow Specification is originated in the same
local domain.
Even when the second condition (b.2) is used in the validation Flow Specification originated in a different local domain needs a
procedure, a Flow Specification originated in a different local congruent topology. The reason is that the second condition (b.2)
domain needs a congruent topology. AS_SEQUENCE is not empty and evaluates to false and only the first condition (b.1) is
the first condition (b.1) in the validation procedure needs to be evaluated.
evaluated. Because transport addresses for Flow Specification and
unicast routes are different, the validation procedure will fail.
This is true both across domains and within domains. Consider 6. IANA Considerations
both cases:
* Consider the first example. If the Flow Specification route is This memo includes no request to IANA.
originated in another AS, the validation procedure will fail
because the topology is non-congruent within the domain.
* Consider the second example and modify it so AS X and AS Y 7. Security Considerations
belong to different local domains (no confederation of ASes
exists). The validation procedure will fail because the
topology is non-congruent across domains.
7. IANA Considerations 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 in [rfc8955] and
thus maintain security characteristics equivalent to the existing
security properties of BGP unicast routing.
This memo includes no request to IANA. The security considerations discussed in [RFC8955] apply to this
specification as well.
8. Security Considerations The original AS_PATH validation rule ([RFC4271] section 6.3) becomes
hereby optional (section 4.2). If that original rule is actually not
enforced it may introduce some security risks. A peer (or a client
of a route server peer) in AS X 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). This risk
is impossible to prevent if the Flow Specification route is received
from a route server peer. If that peer is known for a fact not to be
a route server, that optional rule SHOULD be enforced for Flow
Specification routes.
No new security issues are introduced by relaxing the validation BGP updates learned from iBGP peers are considered trusted, so the
procedure for IBGP learned Flow Specifications. With this proposal, Traffic Flow Specifications contained in BGP updates are also
the security characteristics of BGP Flow Specifications remain considered trusted. Therefore it is not required to validate that
equivalent to the existing security properties of BGP unicast the originator of an intra-domain Traffic Flow Specification matches
routing. the originator of the best-match unicast route for the flow
destination prefix. Note that this trustworthy consideration is not
absolute and the new possibility than an iBGP speaker could send a
rouge Flow Specification is introduced.
BGP updates learned from iBGP peers are trusted so the Traffic Flow The changes in Section 4.1 don't affect the validation procedures for
Specifications contained in BGP updates are trusted. Therefore it is eBGP-learned routes.
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 flow destination prefix. This proposal
continues to enforce the validation Procedure for eBGP learned
Traffic Flow Specifications, as per [I-D.ietf-idr-rfc5575bis] rules.
In this way, the security properties of [I-D.ietf-idr-rfc5575bis] are
maintained such that an EBGP peer cannot cause a denial-of-service
attack by advertising an inter-domain Flow Specification for a
destination prefix that it does not provide reachability information
for.
9. Acknowledgements 8. Acknowledgements
The authors would like to thank Han Nguyen for his direction on this 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 work as well as Waqas Alam, Keyur Patel, Robert Raszuk, Eric Rosen
and Shyam Sethuram for their review comments. and Shyam Sethuram for their review comments.
10. Normative References 9. Normative References
[I-D.ietf-idr-rfc5575bis]
Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M.
Bacher, "Dissemination of Flow Specification Rules",
draft-ietf-idr-rfc5575bis-25 (work in progress), May 2020.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006, DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>. <https://www.rfc-editor.org/info/rfc4271>.
skipping to change at page 10, line 30 skipping to change at page 11, line 27
[RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous
System Confederations for BGP", RFC 5065, System Confederations for BGP", RFC 5065,
DOI 10.17487/RFC5065, August 2007, DOI 10.17487/RFC5065, August 2007,
<https://www.rfc-editor.org/info/rfc5065>. <https://www.rfc-editor.org/info/rfc5065>.
[RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet
Autonomous System (AS) Number Space", RFC 6793, Autonomous System (AS) Number Space", RFC 6793,
DOI 10.17487/RFC6793, December 2012, DOI 10.17487/RFC6793, December 2012,
<https://www.rfc-editor.org/info/rfc6793>. <https://www.rfc-editor.org/info/rfc6793>.
[RFC7947] Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker,
"Internet Exchange BGP Route Server", RFC 7947,
DOI 10.17487/RFC7947, September 2016,
<https://www.rfc-editor.org/info/rfc7947>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8955] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M.
Bacher, "Dissemination of Flow Specification Rules",
RFC 8955, DOI 10.17487/RFC8955, December 2020,
<https://www.rfc-editor.org/info/rfc8955>.
Authors' Addresses Authors' Addresses
James Uttaro James Uttaro
AT&T AT&T
200 S. Laurel Ave 200 S. Laurel Ave
Middletown, NJ 07748 Middletown, NJ 07748
USA USA
Email: ju1738@att.com Email: ju1738@att.com
Juan Alcaide Juan Alcaide
Cisco Cisco
7100 Kit Creek Road 7100 Kit Creek Road
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
USA USA
Email: jalcaide@cisco.com Email: jalcaide@cisco.com
Clarence Filsfils Clarence Filsfils
Cisco Cisco
Email: cf@cisco.com Email: cf@cisco.com
David Smith David Smith
Cisco Cisco
111 Wood Ave South 111 Wood Ave South
Iselin, NJ 08830 Iselin, NJ 08830
USA USA
 End of changes. 63 change blocks. 
221 lines changed or deleted 269 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/