draft-ietf-idr-rfc5575bis-22.txt   draft-ietf-idr-rfc5575bis-23.txt 
IDR Working Group C. Loibl IDR Working Group C. Loibl
Internet-Draft next layer Telekom GmbH Internet-Draft next layer Telekom GmbH
Obsoletes: 5575,7674 (if approved) S. Hares Obsoletes: 5575,7674 (if approved) S. Hares
Intended status: Standards Track Huawei Intended status: Standards Track Huawei
Expires: October 19, 2020 R. Raszuk Expires: October 25, 2020 R. Raszuk
Bloomberg LP Bloomberg LP
D. McPherson D. McPherson
Verisign Verisign
M. Bacher M. Bacher
T-Mobile Austria T-Mobile Austria
April 17, 2020 April 23, 2020
Dissemination of Flow Specification Rules Dissemination of Flow Specification Rules
draft-ietf-idr-rfc5575bis-22 draft-ietf-idr-rfc5575bis-23
Abstract Abstract
This document defines a Border Gateway Protocol Network Layer This document defines a Border Gateway Protocol Network Layer
Reachability Information (BGP NLRI) encoding format that can be used Reachability Information (BGP NLRI) encoding format that can be used
to distribute traffic Flow Specifications. This allows the routing to distribute traffic Flow Specifications. This allows the routing
system to propagate information regarding more specific components of system to propagate information regarding more specific components of
the traffic aggregate defined by an IP destination prefix. the traffic aggregate defined by an IP destination prefix.
It also specifies BGP Extended Community encoding formats, that can It also specifies BGP Extended Community encoding formats, that can
be used to propagate Traffic Filtering Actions along with the Flow be used to propagate Traffic Filtering Actions along with the Flow
Specification NLRI. Those Traffic Filtering Actions encode actions a Specification NLRI. Those Traffic Filtering Actions encode actions a
routing system can take if the packet matches the Flow Specification. routing system can take if the packet matches the Flow Specification.
Additionally, it defines two applications of that encoding format: Additionally, it defines two applications of that encoding format:
one that can be used to automate inter-domain coordination of traffic one that can be used to automate inter-domain coordination of traffic
filtering, such as what is required in order to mitigate filtering, such as what is required in order to mitigate
(distributed) denial-of-service attacks, and a second application to (distributed) denial-of-service attacks, and a second application to
provide traffic filtering in the context of a BGP/MPLS VPN service. provide traffic filtering in the context of a BGP/MPLS VPN service.
Other applications (ie. centralized control of traffic in a SDN or Other applications (e.g. centralized control of traffic in a SDN or
NFV context) are also possible. Other documents may specify Flow NFV context) are also possible. Other documents may specify Flow
Specification extensions. Specification extensions.
The information is carried via BGP, thereby reusing protocol The information is carried via BGP, thereby reusing protocol
algorithms, operational experience, and administrative processes such algorithms, operational experience, and administrative processes such
as inter-provider peering agreements. as inter-provider peering agreements.
This document obsoletes both RFC5575 and RFC7674. This document obsoletes both RFC5575 and RFC7674.
Status of This Memo Status of This Memo
skipping to change at page 2, line 20 skipping to change at page 2, line 20
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 October 19, 2020. This Internet-Draft will expire on October 25, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
skipping to change at page 2, line 52 skipping to change at page 2, line 52
4. Dissemination of IPv4 Flow Specification Information . . . . 6 4. Dissemination of IPv4 Flow Specification Information . . . . 6
4.1. Length Encoding . . . . . . . . . . . . . . . . . . . . . 7 4.1. Length Encoding . . . . . . . . . . . . . . . . . . . . . 7
4.2. NLRI Value Encoding . . . . . . . . . . . . . . . . . . . 7 4.2. NLRI Value Encoding . . . . . . . . . . . . . . . . . . . 7
4.2.1. Operators . . . . . . . . . . . . . . . . . . . . . . 7 4.2.1. Operators . . . . . . . . . . . . . . . . . . . . . . 7
4.2.2. Components . . . . . . . . . . . . . . . . . . . . . 9 4.2.2. Components . . . . . . . . . . . . . . . . . . . . . 9
4.3. Examples of Encodings . . . . . . . . . . . . . . . . . . 14 4.3. Examples of Encodings . . . . . . . . . . . . . . . . . . 14
5. Traffic Filtering . . . . . . . . . . . . . . . . . . . . . . 16 5. Traffic Filtering . . . . . . . . . . . . . . . . . . . . . . 16
5.1. Ordering of Flow Specifications . . . . . . . . . . . . . 17 5.1. Ordering of Flow Specifications . . . . . . . . . . . . . 17
6. Validation Procedure . . . . . . . . . . . . . . . . . . . . 18 6. Validation Procedure . . . . . . . . . . . . . . . . . . . . 18
7. Traffic Filtering Actions . . . . . . . . . . . . . . . . . . 19 7. Traffic Filtering Actions . . . . . . . . . . . . . . . . . . 19
7.1. Traffic Rate in Bytes (traffic-rate-bytes) sub-type 0x06 20 7.1. Traffic Rate in Bytes (traffic-rate-bytes) sub-type 0x06 21
7.2. Traffic Rate in Packets (traffic-rate-packets) sub-type 7.2. Traffic Rate in Packets (traffic-rate-packets) sub-type
TBD . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 TBD . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.3. Traffic-action (traffic-action) sub-type 0x07 . . . . . . 21 7.3. Traffic-action (traffic-action) sub-type 0x07 . . . . . . 21
7.4. RT Redirect (rt-redirect) sub-type 0x08 . . . . . . . . . 22 7.4. RT Redirect (rt-redirect) sub-type 0x08 . . . . . . . . . 22
7.5. Traffic Marking (traffic-marking) sub-type 0x09 . . . . . 22 7.5. Traffic Marking (traffic-marking) sub-type 0x09 . . . . . 23
7.6. Interaction with other Filtering Mechanisms in Routers . 23 7.6. Interaction with other Filtering Mechanisms in Routers . 23
7.7. Considerations on Traffic Filtering Action Interference . 23 7.7. Considerations on Traffic Filtering Action Interference . 24
8. Dissemination of Traffic Filtering in BGP/MPLS VPN Networks . 24 8. Dissemination of Traffic Filtering in BGP/MPLS VPN Networks . 24
9. Traffic Monitoring . . . . . . . . . . . . . . . . . . . . . 25 9. Traffic Monitoring . . . . . . . . . . . . . . . . . . . . . 25
10. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 25 10. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 25
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
11.1. AFI/SAFI Definitions . . . . . . . . . . . . . . . . . . 25 11.1. AFI/SAFI Definitions . . . . . . . . . . . . . . . . . . 25
11.2. Flow Component Definitions . . . . . . . . . . . . . . . 26 11.2. Flow Component Definitions . . . . . . . . . . . . . . . 26
11.3. Extended Community Flow Specification Actions . . . . . 27 11.3. Extended Community Flow Specification Actions . . . . . 27
12. Security Considerations . . . . . . . . . . . . . . . . . . . 29 12. Security Considerations . . . . . . . . . . . . . . . . . . . 29
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
skipping to change at page 3, line 32 skipping to change at page 3, line 32
15.1. Normative References . . . . . . . . . . . . . . . . . . 31 15.1. Normative References . . . . . . . . . . . . . . . . . . 31
15.2. Informative References . . . . . . . . . . . . . . . . . 33 15.2. Informative References . . . . . . . . . . . . . . . . . 33
15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 34 15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Appendix A. Python code: flow_rule_cmp . . . . . . . . . . . . . 34 Appendix A. Python code: flow_rule_cmp . . . . . . . . . . . . . 34
Appendix B. Comparison with RFC 5575 . . . . . . . . . . . . . . 35 Appendix B. Comparison with RFC 5575 . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction 1. Introduction
This document obsoletes "Dissemination of Flow Specification Rules" This document obsoletes "Dissemination of Flow Specification Rules"
[RFC5575], the differences can be found in Appendix B. This document [RFC5575] (see Appendix B for the differences). This document also
also obsoletes obsoletes "Clarification of the Flowspec Redirect Extended Community"
"Clarification of the Flowspec Redirect Extended Community" [RFC7674] [RFC7674] since it incorporates the encoding of the BGP Flow
since it incorporates the encoding of the BGP Flow Specification Specification Redirect Extended Community in Section 7.4.
Redirect Extended Community in Section 7.4.
Modern IP routers contain both the capability to forward traffic Modern IP routers have the capability to forward traffic and to
according to IP prefixes as well as to classify, shape, rate limit, classify, shape, rate limit, filter, or redirect packets based on
filter, or redirect packets based on administratively defined administratively defined policies. These traffic policy mechanisms
policies. These traffic policy mechanisms allow the operator to allow the operator to define match rules that operate on multiple
define match rules that operate on multiple fields of the packet fields of the packet header. Actions such as the ones described
header. Actions such as the ones described above can be associated above can be associated with each rule.
with each rule.
The n-tuple consisting of the matching criteria defines an aggregate The n-tuple consisting of the matching criteria defines an aggregate
traffic Flow Specification. The matching criteria can include traffic Flow Specification. The matching criteria can include
elements such as source and destination address prefixes, IP elements such as source and destination address prefixes, IP
protocol, and transport protocol port numbers. protocol, and transport protocol port numbers.
Section 4 of this document defines a general procedure to encode Flow Section 4 of this document defines a general procedure to encode Flow
Specification for aggregated traffic flows so that they can be Specifications for aggregated traffic flows so that they can be
distributed as a BGP [RFC4271] NLRI. Additionally, Section 7 of this distributed as a BGP [RFC4271] NLRI. Additionally, Section 7 of this
document defines the required Traffic Filtering Actions BGP Extended document defines the required Traffic Filtering Actions BGP Extended
Communities and mechanisms to use BGP for intra- and inter-provider Communities and mechanisms to use BGP for intra- and inter-provider
distribution of traffic filtering rules to filter (distributed) distribution of traffic filtering rules to filter (distributed)
denial-of-service (DoS) attacks. denial-of-service (DoS) attacks.
By expanding routing information with Flow Specifications, the By expanding routing information with Flow Specifications, the
routing system can take advantage of the ACL (Access Control List) or routing system can take advantage of the ACL (Access Control List) or
firewall capabilities in the router's forwarding path. Flow firewall capabilities in the router's forwarding path. Flow
Specifications can be seen as more specific routing entries to a Specifications can be seen as more specific routing entries to a
skipping to change at page 4, line 46 skipping to change at page 4, line 42
network). network).
While it is certainly possible to address this problem using other While it is certainly possible to address this problem using other
mechanisms, this solution has been utilized in deployments because of mechanisms, this solution has been utilized in deployments because of
the substantial advantage of being an incremental addition to already the substantial advantage of being an incremental addition to already
deployed mechanisms. deployed mechanisms.
In current deployments, the information distributed by this extension In current deployments, the information distributed by this extension
is originated both manually as well as automatically, the latter by is originated both manually as well as automatically, the latter by
systems that are able to detect malicious traffic flows. When systems that are able to detect malicious traffic flows. When
automated systems are used, care should be taken to ensure their automated systems are used, care should be taken to ensure the
correctness as well as the limitations of the systems that receive correctness of the automated system. The the limitations of the
and process the advertised Flow Specifications (see also Section 12). receiving systems that need to process these automated Flow
Specifications need to be taken in consideration as well (see also
Section 12).
This specification defines required protocol extensions to address This specification defines required protocol extensions to address
most common applications of IPv4 unicast and VPNv4 unicast filtering. most common applications of IPv4 unicast and VPNv4 unicast filtering.
The same mechanism can be reused and new match criteria added to The same mechanism can be reused and new match criteria added to
address similar filtering needs for other BGP address families such address similar filtering needs for other BGP address families such
as IPv6 families [I-D.ietf-idr-flow-spec-v6]. as IPv6 families [I-D.ietf-idr-flow-spec-v6].
2. Definitions of Terms Used in This Memo 2. Definitions of Terms Used in This Memo
AFI - Address Family Identifier. AFI - Address Family Identifier.
skipping to change at page 6, line 14 skipping to change at page 6, line 14
BGP itself treats the NLRI as a key to an entry in its databases. BGP itself treats the NLRI as a key to an entry in its databases.
Entries that are placed in the Loc-RIB are then associated with a Entries that are placed in the Loc-RIB are then associated with a
given set of semantics, which is application dependent. This is given set of semantics, which is application dependent. This is
consistent with existing BGP applications. For instance, IP unicast consistent with existing BGP applications. For instance, IP unicast
routing (AFI=1, SAFI=1) and IP multicast reverse-path information routing (AFI=1, SAFI=1) and IP multicast reverse-path information
(AFI=1, SAFI=2) are handled by BGP without any particular semantics (AFI=1, SAFI=2) are handled by BGP without any particular semantics
being associated with them until installed in the Loc-RIB. being associated with them until installed in the Loc-RIB.
Standard BGP policy mechanisms, such as UPDATE filtering by NLRI Standard BGP policy mechanisms, such as UPDATE filtering by NLRI
prefix as well as community matching and manipulation, must apply to prefix as well as community matching and must apply to the Flow
the Flow Specification defined NLRI-type, especially in an inter- specification defined NLRI-type. Network operators can also control
domain environment. Network operators can also control propagation propagation of such routing updates by enabling or disabling the
of such routing updates by enabling or disabling the exchange of a exchange of a particular (AFI, SAFI) pair on a given BGP peering
particular (AFI, SAFI) pair on a given BGP peering session. session.
4. Dissemination of IPv4 Flow Specification Information 4. Dissemination of IPv4 Flow Specification Information
This document defines a Flow Specification NLRI type (Figure 1) that This document defines a Flow Specification NLRI type (Figure 1) that
may include several components such as destination prefix, source may include several components such as destination prefix, source
prefix, protocol, ports, and others (see Section 4.2 below). prefix, protocol, ports, and others (see Section 4.2 below).
This NLRI information is encoded using MP_REACH_NLRI and This NLRI information is encoded using MP_REACH_NLRI and
MP_UNREACH_NLRI attributes as defined in [RFC4760]. When advertising MP_UNREACH_NLRI attributes as defined in [RFC4760]. When advertising
Flow Specifications, the Length of Next Hop Network Address SHOULD be Flow Specifications, the Length of Next Hop Network Address SHOULD be
skipping to change at page 16, line 47 skipping to change at page 16, line 47
The Flow Specification NLRI defined in Section 4 conveys information The Flow Specification NLRI defined in Section 4 conveys information
about traffic filtering rules for traffic that should be discarded or about traffic filtering rules for traffic that should be discarded or
handled in a manner specified by a set of pre-defined actions (which handled in a manner specified by a set of pre-defined actions (which
are defined in BGP Extended Communities). This mechanism is are defined in BGP Extended Communities). This mechanism is
primarily designed to allow an upstream autonomous system to perform primarily designed to allow an upstream autonomous system to perform
inbound filtering in their ingress routers of traffic that a given inbound filtering in their ingress routers of traffic that a given
downstream AS wishes to drop. downstream AS wishes to drop.
In order to achieve this goal, this document specifies two In order to achieve this goal, this document specifies two
application specific NLRI identifiers that provide traffic filters, application-specific NLRI identifiers that provide traffic filters,
and a set of actions encoding in BGP Extended Communities. The two and a set of actions encoding in BGP Extended Communities. The two
application specific NLRI identifiers are: application-specific NLRI identifiers are:
o IPv4 Flow Specification identifier (AFI=1, SAFI=133) along with o IPv4 Flow Specification identifier (AFI=1, SAFI=133) along with
specific semantic rules for IPv4 routes, and specific semantic rules for IPv4 routes, and
o VPNv4 Flow Specification identifier (AFI=1, SAFI=134) value, which o VPNv4 Flow Specification identifier (AFI=1, SAFI=134) value, which
can be used to propagate traffic filtering information in a BGP/ can be used to propagate traffic filtering information in a BGP/
MPLS VPN environment. MPLS VPN environment.
Encoding of the NLRI is described in Section 4 for IPv4 Flow Encoding of the NLRI is described in Section 4 for IPv4 Flow
Specification and in Section 8 for VPNv4 Flow Specification. The Specification and in Section 8 for VPNv4 Flow Specification. The
skipping to change at page 17, line 29 skipping to change at page 17, line 29
on the arrival order of the Flow Specification via BGP and thus is on the arrival order of the Flow Specification via BGP and thus is
consistent in the network. consistent in the network.
The relative order of two Flow Specifications is determined by The relative order of two Flow Specifications is determined by
comparing their respective components. The algorithm starts by comparing their respective components. The algorithm starts by
comparing the left-most components (lowest component type value) of comparing the left-most components (lowest component type value) of
the Flow Specifications. If the types differ, the Flow Specification the Flow Specifications. If the types differ, the Flow Specification
with lowest numeric type value has higher precedence (and thus will with lowest numeric type value has higher precedence (and thus will
match before) than the Flow Specification that doesn't contain that match before) than the Flow Specification that doesn't contain that
component type. If the component types are the same, then a type- component type. If the component types are the same, then a type-
specific comparison is performed (see below) if the types are equal specific comparison is performed (see below). If the types are equal
the algorithm continues with the next component. the algorithm continues with the next component.
For IP prefix values (IP destination or source prefix): If one of the For IP prefix values (IP destination or source prefix): If one of the
two prefixes to compare is a more specific prefix of the other, the two prefixes to compare is a more specific prefix of the other, the
more specific prefix has higher precedence. Otherwise the one with more specific prefix has higher precedence. Otherwise the one with
the lowest IP value has higher precedence. the lowest IP value has higher precedence.
For all other component types, unless otherwise specified, the For all other component types, unless otherwise specified, the
comparison is performed by comparing the component data as a binary comparison is performed by comparing the component data as a binary
string using the memcmp() function as defined by [ISO_IEC_9899]. For string using the memcmp() function as defined by [ISO_IEC_9899]. For
skipping to change at page 18, line 33 skipping to change at page 18, line 33
The validation process described below validates Flow Specifications The validation process described below validates Flow Specifications
against unicast routes received over the same AFI but the associated against unicast routes received over the same AFI but the associated
unicast routing information SAFI: unicast routing information SAFI:
Flow Specification received over SAFI=133 will be validated Flow Specification received over SAFI=133 will be validated
against routes received over SAFI=1 against routes received over SAFI=1
Flow Specification received over SAFI=134 will be validated Flow Specification received over SAFI=134 will be validated
against routes received over SAFI=128 against routes received over SAFI=128
By default a Flow Specification NLRI MUST be validated such that it In the absence of explicit configuration a Flow Specification NLRI
is considered feasible if and only if all of the below is true: MUST be validated such that it is considered feasible if and only if
all of the conditions below are true:
a) A destination prefix component is embedded in the Flow a) A destination prefix component is embedded in the Flow
Specification. Specification.
b) The originator of the Flow Specification matches the originator b) The originator of the Flow Specification matches the originator
of the best-match unicast route for the destination prefix of the best-match unicast route for the destination prefix
embedded in the Flow Specification (this is the unicast route with embedded in the Flow Specification (this is the unicast route with
the longest possible prefix length covering the destination prefix the longest possible prefix length covering the destination prefix
embedded in the Flow Specification). embedded in the Flow Specification).
c) There are no more specific unicast routes, when compared with c) There are no "more-specific" unicast routes, when compared with
the flow destination prefix, that have been received from a the flow destination prefix, that have been received from a
different neighboring AS than the best-match unicast route, which different neighboring AS than the best-match unicast route, which
has been determined in rule b). has been determined in rule b).
However, rule a) MAY be relaxed by explicit configuration, permitting However, rule a) MAY be relaxed by explicit configuration, permitting
Flow Specifications that include no destination prefix component. If Flow Specifications that include no destination prefix component. If
such is the case, rules b) and c) are moot and MUST be disregarded. such is the case, rules b) and c) are moot and MUST be disregarded.
By originator of a BGP route, we mean either the address of the By "originator" of a BGP route, we mean either the address of the
originator in the ORIGINATOR_ID Attribute [RFC4456], or the source IP originator in the ORIGINATOR_ID Attribute [RFC4456], or the source IP
address of the BGP peer, if this path attribute is not present. address of the BGP peer, if this path attribute is not present.
BGP implementations MUST also enforce that the AS_PATH attribute of a BGP implementations MUST also enforce that the AS_PATH attribute of a
route received via the External Border Gateway Protocol (eBGP) route received via the External Border Gateway Protocol (eBGP)
contains the neighboring AS in the left-most position of the AS_PATH contains the neighboring AS in the left-most position of the AS_PATH
attribute. While this rule is optional in the BGP specification, it attribute. While this rule is optional in the BGP specification, it
becomes necessary to enforce it for security reasons. becomes necessary to enforce it here for security reasons.
The best-match unicast route may change over the time independently The best-match unicast route may change over the time independently
of the Flow Specification NLRI. Therefore, a revalidation of the of the Flow Specification NLRI. Therefore, a revalidation of the
Flow Specification NLRI MUST be performed whenever unicast routes Flow Specification NLRI MUST be performed whenever unicast routes
change. Revalidation is defined as retesting that clause a and change. Revalidation is defined as retesting rules a) to c) as
clause b above are true. described above.
Explanation: Explanation:
The underlying concept is that the neighboring AS that advertises the The underlying concept is that the neighboring AS that advertises the
best unicast route for a destination is allowed to advertise Flow best unicast route for a destination is allowed to advertise Flow
Specification information that conveys a more or equally specific Specification information that conveys a destination prefix that is
destination prefix. Thus, as long as there are no more specific more or equally specific. Thus, as long as there are no "more-
unicast routes, received from a different neighboring AS, which would specific" unicast routes, received from a different neighboring AS,
be affected by that Flow Specification. which would be affected by that Flow Specification, the Flow
Specification is validated successfully.
The neighboring AS is the immediate destination of the traffic The neighboring AS is the immediate destination of the traffic
described by the Flow Specification. If it requests these flows to described by the Flow Specification. If it requests these flows to
be dropped, that request can be honored without concern that it be dropped, that request can be honored without concern that it
represents a denial of service in itself. Supposedly, the traffic is represents a denial of service in itself. The reasoning is that this
being dropped by the downstream autonomous system, and there is no is as if the traffic is being dropped by the downstream autonomous
added value in carrying the traffic to it. system, and there is no added value in carrying the traffic to it.
7. Traffic Filtering Actions 7. Traffic Filtering Actions
This document defines a minimum set of Traffic Filtering Actions that This document defines a minimum set of Traffic Filtering Actions that
it standardizes as BGP extended communities [RFC4360]. This is not it standardizes as BGP extended communities [RFC4360]. This is not
meant to be an inclusive list of all the possible actions, but only a meant to be an inclusive list of all the possible actions, but only a
subset that can be interpreted consistently across the network. subset that can be interpreted consistently across the network.
Additional actions can be defined as either requiring standards or as Additional actions can be defined as either requiring standards or as
vendor specific. vendor specific.
skipping to change at page 20, line 11 skipping to change at page 20, line 18
This document defines the following extended communities values shown This document defines the following extended communities values shown
in Table 2 in the form 0xttss where tt indicates the type and ss in Table 2 in the form 0xttss where tt indicates the type and ss
indicates the sub-type of the extended community. Encodings for indicates the sub-type of the extended community. Encodings for
these extended communities are described below. these extended communities are described below.
+-------------+---------------------------+-------------------------+ +-------------+---------------------------+-------------------------+
| community | action | encoding | | community | action | encoding |
| 0xttss | | | | 0xttss | | |
+-------------+---------------------------+-------------------------+ +-------------+---------------------------+-------------------------+
| 0x8006 | traffic-rate-bytes | 2-octet ASN, 4-octet | | 0x8006 | traffic-rate-bytes | 2-octet AS, 4-octet |
| | (Section 7.1) | float | | | (Section 7.1) | float |
| TBD | traffic-rate-packets | 2-octet ASN, 4-octet | | TBD | traffic-rate-packets | 2-octet AS, 4-octet |
| | (Section 7.1) | float | | | (Section 7.1) | float |
| 0x8007 | traffic-action | bitmask | | 0x8007 | traffic-action | bitmask |
| | (Section 7.3) | | | | (Section 7.3) | |
| 0x8008 | rt-redirect AS-2octet | 2-octet AS, 4-octet | | 0x8008 | rt-redirect AS-2octet | 2-octet AS, 4-octet |
| | (Section 7.4) | value | | | (Section 7.4) | value |
| 0x8108 | rt-redirect IPv4 | 4-octet IPv4 address, | | 0x8108 | rt-redirect IPv4 | 4-octet IPv4 address, |
| | (Section 7.4) | 2-octet value | | | (Section 7.4) | 2-octet value |
| 0x8208 | rt-redirect AS-4octet | 4-octet AS, 2-octet | | 0x8208 | rt-redirect AS-4octet | 4-octet AS, 2-octet |
| | (Section 7.4) | value | | | (Section 7.4) | value |
| 0x8009 | traffic-marking | DSCP value | | 0x8009 | traffic-marking | DSCP value |
| | (Section 7.5) | | | | (Section 7.5) | |
+-------------+---------------------------+-------------------------+ +-------------+---------------------------+-------------------------+
Table 2: Traffic Filtering Action Extended Communities Table 2: Traffic Filtering Action Extended Communities
Multiple Traffic Filtering Actions defined in this document may be Multiple Traffic Filtering Actions defined in this document may be
present for a single Flow Specification and SHOULD be applied to the present for a single Flow Specification and SHOULD be applied to the
traffic flow (for example traffic-rate-bytes and rt-redirect can be traffic flow (for example traffic-rate-bytes and rt-redirect can be
applied to packets at the same time). If not all of the Traffic applied to packets at the same time). If not all of the Traffic
Filtering Actions can be applied to a traffic flow they should be Filtering Actions can be applied to a traffic flow they should be
treated as interfering Traffic filtering actions (see below). treated as interfering Traffic Filtering Actions (see below).
Some Traffic Filtering Actions may interfere with each other even Some Traffic Filtering Actions may interfere with each other or even
contradict. Section 7.7 of this document provides general contradict. Section 7.7 of this document provides general
considerations on such Traffic Filtering Action interference. Any considerations on such Traffic Filtering Action interference. Any
additional definition of Traffic Filtering Actions SHOULD specify the additional definition of Traffic Filtering Actions SHOULD specify the
action to take if those Traffic Filtering Actions interfere (also action to take if those Traffic Filtering Actions interfere (also
with existing Traffic Filtering Actions). with existing Traffic Filtering Actions).
All Traffic Filtering Actions are specified as transitive BGP All Traffic Filtering Actions are specified as transitive BGP
Extended Communities. Extended Communities.
7.1. Traffic Rate in Bytes (traffic-rate-bytes) sub-type 0x06 7.1. Traffic Rate in Bytes (traffic-rate-bytes) sub-type 0x06
skipping to change at page 21, line 18 skipping to change at page 21, line 23
This value is purely informational and SHOULD NOT be interpreted by This value is purely informational and SHOULD NOT be interpreted by
the implementation. the implementation.
The remaining 4 octets carry the maximum rate information in IEEE The remaining 4 octets carry the maximum rate information in IEEE
floating point [IEEE.754.1985] format, units being bytes per second. floating point [IEEE.754.1985] format, units being bytes per second.
A traffic-rate of 0 should result on all traffic for the particular A traffic-rate of 0 should result on all traffic for the particular
flow to be discarded. On encoding the traffic-rate MUST NOT be flow to be discarded. On encoding the traffic-rate MUST NOT be
negative. On decoding negative values MUST be treated as zero negative. On decoding negative values MUST be treated as zero
(discard all traffic). (discard all traffic).
Interferes with: No other BGP Flow Specification Traffic Filtering Interferes with: May interfere with the traffic-rate-packets (see
Action in this document. Section 7.2). A policy may allow both filtering by traffic-rate-
packets and traffic-rate-bytes. If the policy does not allow this,
these two actions will conflict.
7.2. Traffic Rate in Packets (traffic-rate-packets) sub-type TBD 7.2. Traffic Rate in Packets (traffic-rate-packets) sub-type TBD
The traffic-rate-packets extended community uses the same encoding as The traffic-rate-packets extended community uses the same encoding as
the traffic-rate-bytes extended community. The floating point value the traffic-rate-bytes extended community. The floating point value
carries the maximum packet rate in packets per second. A traffic- carries the maximum packet rate in packets per second. A traffic-
rate-packets of 0 should result in all traffic for the particular rate-packets of 0 should result in all traffic for the particular
flow to be discarded. On encoding the traffic-rate-packets MUST NOT flow to be discarded. On encoding the traffic-rate-packets MUST NOT
be negative. On decoding negative values MUST be treated as zero be negative. On decoding negative values MUST be treated as zero
(discard all traffic). (discard all traffic).
Interferes with: No other BGP Flow Specification Traffic Filtering Interferes with: May interfere with the traffic-rate-bytes (see
Action in this document. Section 7.1). A policy may allow both filtering by traffic-rate-
packets and traffic-rate-bytes. If the policy does not allow this,
these two actions will conflict.
7.3. Traffic-action (traffic-action) sub-type 0x07 7.3. Traffic-action (traffic-action) sub-type 0x07
The traffic-action extended community consists of 6 octets of which The traffic-action extended community consists of 6 octets of which
only the 2 least significant bits of the 6th octet (from left to only the 2 least significant bits of the 6th octet (from left to
right) are defined by this document as shown in Figure 5. right) are defined by this document as shown in Figure 5.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 23, line 31 skipping to change at page 23, line 43
o reserved, r.: SHOULD be set to 0 on encoding, and MUST be ignored o reserved, r.: SHOULD be set to 0 on encoding, and MUST be ignored
during decoding. during decoding.
Interferes with: No other BGP Flow Specification Traffic Filtering Interferes with: No other BGP Flow Specification Traffic Filtering
Action in this document. Action in this document.
7.6. Interaction with other Filtering Mechanisms in Routers 7.6. Interaction with other Filtering Mechanisms in Routers
Implementations should provide mechanisms that map an arbitrary BGP Implementations should provide mechanisms that map an arbitrary BGP
community value (normal or extended) to Traffic Filtering Actions community value (normal or extended) to Traffic Filtering Actions
that require different mappings in different systems in the network. that require different mappings on different systems in the network.
For instance, providing packets with a worse-than-best-effort, per- For instance, providing packets with a worse-than-best-effort per-hop
hop behavior is a functionality that is likely to be implemented behavior is a functionality that is likely to be implemented
differently in different systems and for which no standard behavior differently in different systems and for which no standard behavior
is currently known. Rather than attempting to define it here, this is currently known. Rather than attempting to define it here, this
can be accomplished by mapping a user-defined community value to can be accomplished by mapping a user-defined community value to
platform-/network-specific behavior via user configuration. platform-/network-specific behavior via user configuration.
7.7. Considerations on Traffic Filtering Action Interference 7.7. Considerations on Traffic Filtering Action Interference
Since Traffic Filtering Actions are represented as BGP extended Since Traffic Filtering Actions are represented as BGP extended
community values, Traffic Filtering Actions may interfere with each community values, Traffic Filtering Actions may interfere with each
other (e.g. there may be more than one conflicting traffic-rate-bytes other (e.g. there may be more than one conflicting traffic-rate-bytes
skipping to change at page 24, line 9 skipping to change at page 24, line 23
propagated according to policies). propagated according to policies).
If a Flow Specification associated with interfering Traffic Filtering If a Flow Specification associated with interfering Traffic Filtering
Actions is selected for packet forwarding, it is an implementation Actions is selected for packet forwarding, it is an implementation
decision which of the interfering Traffic Filtering Actions are decision which of the interfering Traffic Filtering Actions are
selected. Implementors of this specification SHOULD document the selected. Implementors of this specification SHOULD document the
behaviour of their implementation in such cases. behaviour of their implementation in such cases.
Operators are encouraged to make use of the BGP policy framework Operators are encouraged to make use of the BGP policy framework
supported by their implementation in order to achieve a predictable supported by their implementation in order to achieve a predictable
behaviour (ie. match - replace - delete communities on administrative behaviour. See also Section 12.
boundaries). See also Section 12.
8. Dissemination of Traffic Filtering in BGP/MPLS VPN Networks 8. Dissemination of Traffic Filtering in BGP/MPLS VPN Networks
Provider-based Layer 3 VPN networks, such as the ones using a BGP/ Provider-based Layer 3 VPN networks, such as the ones using a BGP/
MPLS IP VPN [RFC4364] control plane, may have different traffic MPLS IP VPN [RFC4364] control plane, may have different traffic
filtering requirements than Internet service providers. But also filtering requirements than Internet service providers. But also
Internet service providers may use those VPNs for scenarios like Internet service providers may use those VPNs for scenarios like
having the Internet routing table in a VRF, resulting in the same having the Internet routing table in a VRF, resulting in the same
traffic filtering requirements as defined for the global routing traffic filtering requirements as defined for the global routing
table environment within this document. This document defines an table environment within this document. This document defines an
skipping to change at page 26, line 19 skipping to change at page 26, line 21
| | rules | document] | | | rules | document] |
| 134 | L3VPN Dissemination of Flow | [this | | 134 | L3VPN Dissemination of Flow | [this |
| | Specification rules | document] | | | Specification rules | document] |
+-------+------------------------------------------+----------------+ +-------+------------------------------------------+----------------+
Table 3: Registry: SAFI Values Table 3: Registry: SAFI Values
11.2. Flow Component Definitions 11.2. Flow Component Definitions
A Flow Specification consists of a sequence of flow components, which A Flow Specification consists of a sequence of flow components, which
are identified by a an 8-bit component type. IANA has created and are identified by an 8-bit component type. IANA has created and
maintains a registry entitled "Flow Spec Component Types". IANA is maintains a registry entitled "Flow Spec Component Types". IANA is
requested to update the reference for this registry to [this requested to update the reference for this registry to [this
document]. Furthermore the references to the values should be document]. Furthermore the references to the values should be
updated according to the table below (Note: This document obsoletes updated according to the table below (Note: This document obsoletes
both RFC7674 and RFC5575 and all references to those documents should both RFC7674 and RFC5575 and all references to those documents should
be deleted from the registry below). be deleted from the registry below).
+-------+--------------------+-----------------+ +-------+--------------------+-----------------+
| Value | Name | Reference | | Value | Name | Reference |
+-------+--------------------+-----------------+ +-------+--------------------+-----------------+
skipping to change at page 29, line 44 skipping to change at page 29, line 44
equivalent to the existing security properties of BGP unicast equivalent to the existing security properties of BGP unicast
routing. Any relaxation of the validation procedure described in routing. Any relaxation of the validation procedure described in
Section 6 may allow unwanted Flow Specifications to be propagated and Section 6 may allow unwanted Flow Specifications to be propagated and
thus unwanted Traffic Filtering Actions may be applied to flows. thus unwanted Traffic Filtering Actions may be applied to flows.
Where the above mechanisms are not in place, this could open the door Where the above mechanisms are not in place, this could open the door
to further denial-of-service attacks such as unwanted traffic to further denial-of-service attacks such as unwanted traffic
filtering, remarking or redirection. filtering, remarking or redirection.
Deployment of specific relaxations of the validation within an Deployment of specific relaxations of the validation within an
administrative boundary of a network, defined by an AS or an AS- administrative boundary of a network are useful in some networks for
Confederation boundary, may be useful in some networks for quickly quickly distributing filters to prevent denial-of-service attacks.
distributing filters to prevent denial-of-service attacks. For a For a network to utilize this relaxation, the BGP policies must
network to utilize this relaxation, the BGP policies must support support additional filtering since the origin AS field is empty.
additional filtering since the origin AS field is empty.
Specifications relaxing the validation restrictions MUST contain Specifications relaxing the validation restrictions MUST contain
security considerations that provide details on the required security considerations that provide details on the required
additional filtering. For example, the use of [RFC6811] to enhance additional filtering. For example, the use of Origin validation can
filtering within an AS confederation. provide enhanced filtering within an AS confederation.
Inter-provider routing is based on a web of trust. Neighboring Inter-provider routing is based on a web of trust. Neighboring
autonomous systems are trusted to advertise valid reachability autonomous systems are trusted to advertise valid reachability
information. If this trust model is violated, a neighboring information. If this trust model is violated, a neighboring
autonomous system may cause a denial-of-service attack by advertising autonomous system may cause a denial-of-service attack by advertising
reachability information for a given prefix for which it does not reachability information for a given prefix for which it does not
provide service (unfiltered address space hijack). Since validation provide service (unfiltered address space hijack). Since validation
of the Flow Specification is tied to the announcement of the best of the Flow Specification is tied to the announcement of the best
unicast route, this may also cause this validation to fail and unicast route, the failure in the validation of best path route may
consequently prevent Flow Specifications from being accepted by a prevent the Flow Specificaiton from being used by a local router.
peer. Possible mitigations are [RFC6811] and [RFC8205]. Possible mitigations are [RFC6811] and [RFC8205].
On IXPs routes are often exchanged via route servers which do not On IXPs routes are often exchanged via route servers which do not
extend the AS_PATH. In such cases it is not possible to enforce the extend the AS_PATH. In such cases it is not possible to enforce the
left-most AS in the AS_PATH to be the neighbor AS (the AS of the left-most AS in the AS_PATH to be the neighbor AS (the AS of the
route server). Since the validation of Flow Specification route server). Since the validation of Flow Specification
(Section 6) depends on this, additional care must be taken. It is (Section 6) depends on this, additional care must be taken. It is
advised to use a strict inbound route policy in such scenarios. advised to use a strict inbound route policy in such scenarios.
Enabling firewall-like capabilities in routers without centralized Enabling firewall-like capabilities in routers without centralized
management could make certain failures harder to diagnose. For management could make certain failures harder to diagnose. For
skipping to change at page 30, line 38 skipping to change at page 30, line 38
a pair of addresses, but not packets whose length is in the range a pair of addresses, but not packets whose length is in the range
900- 1000. Such behavior may be confusing and these capabilities 900- 1000. Such behavior may be confusing and these capabilities
should be used with care whether manually configured or coordinated should be used with care whether manually configured or coordinated
through the protocol extensions described in this document. through the protocol extensions described in this document.
Flow Specification BGP speakers (e.g. automated DDoS controllers) not Flow Specification BGP speakers (e.g. automated DDoS controllers) not
properly programmed, algorithms that are not performing as expected, properly programmed, algorithms that are not performing as expected,
or simply rogue systems may announce unintended Flow Specifications, or simply rogue systems may announce unintended Flow Specifications,
send updates at a high rate or generate a high number of Flow send updates at a high rate or generate a high number of Flow
Specifications. This may stress the receiving systems, exceed their Specifications. This may stress the receiving systems, exceed their
maximum capacity or may lead to unwanted Traffic Filtering Actions capacity, or lead to unwanted Traffic Filtering Actions being applied
being applied to flows. to flows.
While the general verification of the Flow Specification NLRI is While the general verification of the Flow Specification NLRI is
specified in this document (Section 6) the Traffic Filtering Actions specified in this document (Section 6) the Traffic Filtering Actions
received by a third party may need custom verification or filtering. received by a third party may need custom verification or filtering.
In particular all non traffic-rate actions may allow a third party to In particular all non traffic-rate actions may allow a third party to
modify packet forwarding properties and potentially gain access to modify packet forwarding properties and potentially gain access to
other routing-tables/VPNs or undesired queues. This can be avoided other routing-tables/VPNs or undesired queues. This can be avoided
by proper filtering/screening of the Traffic Filtering Action by proper filtering/screening of the Traffic Filtering Action
communities at network borders and only exposing a predefined subset communities at network borders and only exposing a predefined subset
of Traffic Filtering Actions (see Section 7) to third parties. One of Traffic Filtering Actions (see Section 7) to third parties. One
skipping to change at page 35, line 43 skipping to change at page 35, line 43
Appendix B. Comparison with RFC 5575 Appendix B. Comparison with RFC 5575
This document includes numerous editorial changes to [RFC5575]. It This document includes numerous editorial changes to [RFC5575]. It
also completely incorporates the redirect action clarification also completely incorporates the redirect action clarification
document [RFC7674]. It is recommended to read the entire document. document [RFC7674]. It is recommended to read the entire document.
The authors, however want to point out the following technical The authors, however want to point out the following technical
changes to [RFC5575]: changes to [RFC5575]:
Section 1 introduces the Flow Specification NLRI. In [RFC5575] Section 1 introduces the Flow Specification NLRI. In [RFC5575]
this NLRI was defined as an opaque-key in BGPs database. This this NLRI was defined as an opaque-key in BGPs database. This
specification has removed all references to a opaque-key property. specification has removed all references to an opaque-key
BGP is able to understand the NLRI encoding. property. BGP implementations are able to understand the NLRI
encoding.
Section 4.2.1.1 defines a numeric operator and comparison bit Section 4.2.1.1 defines a numeric operator and comparison bit
combinations. In [RFC5575] the meaning of those bit combination combinations. In [RFC5575] the meaning of those bit combination
was not explicitly defined and left open to the reader. was not explicitly defined and left open to the reader.
Section 4.2.2.3 - Section 4.2.2.8, Section 4.2.2.10, Section 4.2.2.3 - Section 4.2.2.8, Section 4.2.2.10,
Section 4.2.2.11 make use of the above numeric operator. The Section 4.2.2.11 make use of the above numeric operator. The
allowed length of the comparison value was not consistently allowed length of the comparison value was not consistently
defined in [RFC5575]. defined in [RFC5575].
 End of changes. 37 change blocks. 
74 lines changed or deleted 79 lines changed or added

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