draft-ietf-idr-rfc5575bis-09.txt   draft-ietf-idr-rfc5575bis-10.txt 
IDR Working Group S. Hares IDR Working Group S. Hares
Internet-Draft Huawei Internet-Draft Huawei
Obsoletes: 5575,7674 (if approved) C. Loibl Obsoletes: 5575,7674 (if approved) C. Loibl
Intended status: Standards Track Next Layer Communications Intended status: Standards Track Next Layer Communications
Expires: April 20, 2019 R. Raszuk Expires: May 18, 2019 R. Raszuk
Bloomberg LP Bloomberg LP
D. McPherson D. McPherson
Verisign Verisign
M. Bacher M. Bacher
T-Mobile Austria T-Mobile Austria
October 17, 2018 November 14, 2018
Dissemination of Flow Specification Rules Dissemination of Flow Specification Rules
draft-ietf-idr-rfc5575bis-09 draft-ietf-idr-rfc5575bis-10
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 specifies IPv4 traffic Flow Specifications via a BGP NLRI which It specifies IPv4 traffic Flow Specifications via a BGP NLRI which
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 April 20, 2019. This Internet-Draft will expire on May 18, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 47 skipping to change at page 2, line 47
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions of Terms Used in This Memo . . . . . . . . . . . 5 2. Definitions of Terms Used in This Memo . . . . . . . . . . . 5
3. Flow Specifications . . . . . . . . . . . . . . . . . . . . . 6 3. Flow Specifications . . . . . . . . . . . . . . . . . . . . . 6
4. Dissemination of IPv4 FLow Specification Information . . . . 7 4. Dissemination of IPv4 FLow Specification Information . . . . 7
4.1. Length Encoding . . . . . . . . . . . . . . . . . . . . . 7 4.1. Length Encoding . . . . . . . . . . . . . . . . . . . . . 7
4.2. NLRI Value Encoding . . . . . . . . . . . . . . . . . . . 8 4.2. NLRI Value Encoding . . . . . . . . . . . . . . . . . . . 8
4.2.1. Type 1 - Destination Prefix . . . . . . . . . . . . . 8 4.2.1. Type 1 - Destination Prefix . . . . . . . . . . . . . 8
4.2.2. Type 2 - Source Prefix . . . . . . . . . . . . . . . 8 4.2.2. Type 2 - Source Prefix . . . . . . . . . . . . . . . 8
4.2.3. Type 3 - IP Protocol . . . . . . . . . . . . . . . . 9 4.2.3. Type 3 - IP Protocol . . . . . . . . . . . . . . . . 8
4.2.4. Type 4 - Port . . . . . . . . . . . . . . . . . . . . 10 4.2.4. Type 4 - Port . . . . . . . . . . . . . . . . . . . . 10
4.2.5. Type 5 - Destination Port . . . . . . . . . . . . . . 10 4.2.5. Type 5 - Destination Port . . . . . . . . . . . . . . 10
4.2.6. Type 6 - Source Port . . . . . . . . . . . . . . . . 10 4.2.6. Type 6 - Source Port . . . . . . . . . . . . . . . . 10
4.2.7. Type 7 - ICMP type . . . . . . . . . . . . . . . . . 11 4.2.7. Type 7 - ICMP type . . . . . . . . . . . . . . . . . 11
4.2.8. Type 8 - ICMP code . . . . . . . . . . . . . . . . . 11 4.2.8. Type 8 - ICMP code . . . . . . . . . . . . . . . . . 11
4.2.9. Type 9 - TCP flags . . . . . . . . . . . . . . . . . 11 4.2.9. Type 9 - TCP flags . . . . . . . . . . . . . . . . . 11
4.2.10. Type 10 - Packet length . . . . . . . . . . . . . . . 12 4.2.10. Type 10 - Packet length . . . . . . . . . . . . . . . 12
4.2.11. Type 11 - DSCP (Diffserv Code Point) . . . . . . . . 12 4.2.11. Type 11 - DSCP (Diffserv Code Point) . . . . . . . . 12
4.2.12. Type 12 - Fragment . . . . . . . . . . . . . . . . . 12 4.2.12. Type 12 - Fragment . . . . . . . . . . . . . . . . . 12
4.3. Examples of Encodings . . . . . . . . . . . . . . . . . . 13 4.3. Examples of Encodings . . . . . . . . . . . . . . . . . . 13
skipping to change at page 3, line 28 skipping to change at page 3, line 28
7.5. Traffic Marking (traffic-marking) sub-type 0x09 . . . . . 21 7.5. Traffic Marking (traffic-marking) sub-type 0x09 . . . . . 21
7.6. Rules on Traffic Action Interference . . . . . . . . . . 21 7.6. Rules on Traffic Action Interference . . . . . . . . . . 21
7.6.1. Examples . . . . . . . . . . . . . . . . . . . . . . 22 7.6.1. Examples . . . . . . . . . . . . . . . . . . . . . . 22
8. Dissemination of Traffic Filtering in BGP/MPLS VPN Networks . 22 8. Dissemination of Traffic Filtering in BGP/MPLS VPN Networks . 22
8.1. Validation Procedures for BGP/MPLS VPNs . . . . . . . . . 23 8.1. Validation Procedures for BGP/MPLS VPNs . . . . . . . . . 23
8.2. Traffic Actions Rules . . . . . . . . . . . . . . . . . . 23 8.2. Traffic Actions Rules . . . . . . . . . . . . . . . . . . 23
9. Limitations of Previous Traffic Filtering Efforts . . . . . . 23 9. Limitations of Previous Traffic Filtering Efforts . . . . . . 23
9.1. Limitations in Previous DDoS Traffic Filtering Efforts . 24 9.1. Limitations in Previous DDoS Traffic Filtering Efforts . 24
9.2. Limitations in Previous BGP/MPLS Traffic Filtering . . . 24 9.2. Limitations in Previous BGP/MPLS Traffic Filtering . . . 24
10. Traffic Monitoring . . . . . . . . . . . . . . . . . . . . . 25 10. Traffic Monitoring . . . . . . . . . . . . . . . . . . . . . 25
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 11. Error-Handling and Future NLRI Extensions . . . . . . . . . . 25
11.1. AFI/SAFI Definitions . . . . . . . . . . . . . . . . . . 25 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
11.2. Flow Component Definitions . . . . . . . . . . . . . . . 26 12.1. AFI/SAFI Definitions . . . . . . . . . . . . . . . . . . 26
11.3. Extended Community Flow Specification Actions . . . . . 27 12.2. Flow Component Definitions . . . . . . . . . . . . . . . 26
12. Security Considerations . . . . . . . . . . . . . . . . . . . 29 12.3. Extended Community Flow Specification Actions . . . . . 27
13. Operational Security Considerations . . . . . . . . . . . . . 30 13. Security Considerations . . . . . . . . . . . . . . . . . . . 29
14. Original authors . . . . . . . . . . . . . . . . . . . . . . 30 14. Operational Security Considerations . . . . . . . . . . . . . 30
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 15. Original authors . . . . . . . . . . . . . . . . . . . . . . 30
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
16.1. Normative References . . . . . . . . . . . . . . . . . . 30 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
16.2. Informative References . . . . . . . . . . . . . . . . . 32 17.1. Normative References . . . . . . . . . . . . . . . . . . 31
16.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 32 17.2. Informative References . . . . . . . . . . . . . . . . . 33
Appendix A. Comparison with RFC 5575 . . . . . . . . . . . . . . 32 17.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 Appendix A. Comparison with RFC 5575 . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction 1. Introduction
Modern IP routers contain both the capability to forward traffic Modern IP routers contain both the capability to forward traffic
according to IP prefixes as well as to classify, shape, rate limit, according to IP prefixes as well as to classify, shape, rate limit,
filter, or redirect packets based on administratively defined filter, or redirect packets based on administratively defined
policies. policies.
These traffic policy mechanisms allow the router to define match These traffic policy mechanisms allow the router to define match
rules that operate on multiple fields of the packet header. Actions rules that operate on multiple fields of the packet header. Actions
skipping to change at page 6, line 20 skipping to change at page 6, line 20
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Flow Specifications 3. Flow Specifications
A Flow Specification is an n-tuple consisting of several matching A Flow Specification is an n-tuple consisting of several matching
criteria that can be applied to IP traffic. A given IP packet is criteria that can be applied to IP traffic. A given IP packet is
said to match the defined flow if it matches all the specified said to match the defined flow if it matches all the specified
criteria. criteria. This n-tuple is encoded into a BGP NLRI defined below.
A given flow may be associated with a set of attributes, depending on A given flow may be associated with a set of attributes, depending on
the particular application; such attributes may or may not include the particular application; such attributes may or may not include
reachability information (i.e., NEXT_HOP). Well-known or AS-specific reachability information (i.e., NEXT_HOP). Well-known or AS-specific
community attributes can be used to encode a set of predetermined community attributes can be used to encode a set of predetermined
actions. actions.
A particular application is identified by a specific (Address Family A particular application is identified by a specific (Address Family
Identifier, Subsequent Address Family Identifier (AFI, SAFI)) pair Identifier, Subsequent Address Family Identifier (AFI, SAFI)) pair
[RFC4760] and corresponds to a distinct set of RIBs. Those RIBs [RFC4760] and corresponds to a distinct set of RIBs. Those RIBs
should be treated independently from each other in order to assure should be treated independently from each other in order to assure
non-interference between distinct applications. non-interference between distinct applications.
BGP itself treats the NLRI as an opaque key to an entry in its BGP itself treats the NLRI as an key to an entry in its databases.
databases. Entries that are placed in the Loc-RIB are then Entries that are placed in the Loc-RIB are then associated with a
associated with a given set of semantics, which is application given set of semantics, which is application dependent. This is
dependent. This is consistent with existing BGP applications. For consistent with existing BGP applications. For instance, IP unicast
instance, IP unicast routing (AFI=1, SAFI=1) and IP multicast routing (AFI=1, SAFI=1) and IP multicast reverse-path information
reverse-path information (AFI=1, SAFI=2) are handled by BGP without (AFI=1, SAFI=2) are handled by BGP without any particular semantics
any particular semantics being associated with them until installed being associated with them until installed in the Loc-RIB.
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 manipulation, MUST apply to
the Flow Specification defined NLRI-type, especially in an inter- the Flow Specification defined NLRI-type, especially in an inter-
domain environment. Network operators can also control propagation domain environment. Network operators can also control propagation
of such routing updates by enabling or disabling the exchange of a of such routing updates by enabling or disabling the exchange of a
particular (AFI, SAFI) pair on a given BGP peering session. particular (AFI, SAFI) pair on a given BGP peering session.
4. Dissemination of IPv4 FLow Specification Information 4. Dissemination of IPv4 FLow Specification Information
We define a "Flow Specification" NLRI type (Figure 1) that may We define a "Flow Specification" NLRI type (Figure 1) that may
include several components such as destination prefix, source prefix, include several components such as destination prefix, source prefix,
protocol, ports, and others (see Section 4.2 below). This NLRI is protocol, ports, and others (see Section 4.2 below).
treated as an opaque bit string prefix by BGP. Each bit string
identifies a key to a database entry with which a set of attributes
can be associated.
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]. Whenever the MP_UNREACH_NLRI attributes as defined in [RFC4760]. Whenever the
corresponding application does not require Next-Hop information, this corresponding application does not require Next-Hop information, this
shall be encoded as a 0-octet length Next Hop in the MP_REACH_NLRI shall be encoded as a 0-octet length Next Hop in the MP_REACH_NLRI
attribute and ignored on receipt. attribute and ignored on receipt.
The NLRI field of the MP_REACH_NLRI and MP_UNREACH_NLRI is encoded as The NLRI field of the MP_REACH_NLRI and MP_UNREACH_NLRI is encoded as
a 1- or 2-octet NLRI length field followed by a variable-length NLRI a 1- or 2-octet NLRI length field followed by a variable-length NLRI
value. The NLRI length is expressed in octets. value. The NLRI length is expressed in octets.
skipping to change at page 8, line 33 skipping to change at page 8, line 33
All combinations of component types within a single NLRI are allowed, All combinations of component types within a single NLRI are allowed,
even if the combination makes no sense from a semantical perspective. even if the combination makes no sense from a semantical perspective.
If a given component type within a prefix in unknown, the prefix in If a given component type within a prefix in unknown, the prefix in
question cannot be used for traffic filtering purposes by the question cannot be used for traffic filtering purposes by the
receiver. Since a Flow Specification has the semantics of a logical receiver. Since a Flow Specification has the semantics of a logical
AND of all components, if a component is FALSE, by definition it AND of all components, if a component is FALSE, by definition it
cannot be applied. However, for the purposes of BGP route cannot be applied. However, for the purposes of BGP route
propagation, this prefix should still be transmitted since BGP route propagation, this prefix should still be transmitted since BGP route
distribution is independent on NLRI semantics. distribution is independent on NLRI semantics.
The <type, value> encoding is chosen in order to allow for future
extensibility.
4.2.1. Type 1 - Destination Prefix 4.2.1. Type 1 - Destination Prefix
Encoding: <type (1 octet), prefix length (1 octet), prefix> Encoding: <type (1 octet), prefix length (1 octet), prefix>
Defines: the destination prefix to match. Prefixes are encoded as Defines: the destination prefix to match. Prefixes are encoded as
in BGP UPDATE messages, a length in bits is followed by enough in BGP UPDATE messages, a length in bits is followed by enough
octets to contain the prefix information. octets to contain the prefix information.
4.2.2. Type 2 - Source Prefix 4.2.2. Type 2 - Source Prefix
skipping to change at page 25, line 30 skipping to change at page 25, line 30
Traffic filtering applications require monitoring and traffic Traffic filtering applications require monitoring and traffic
statistics facilities. While this is an implementation-specific statistics facilities. While this is an implementation-specific
choice, implementations SHOULD provide: choice, implementations SHOULD provide:
o A mechanism to log the packet header of filtered traffic. o A mechanism to log the packet header of filtered traffic.
o A mechanism to count the number of matches for a given flow o A mechanism to count the number of matches for a given flow
specification rule. specification rule.
11. IANA Considerations 11. Error-Handling and Future NLRI Extensions
In case BGP encounters an error in a Flow Specification UPDATE
message it SHOULD treat this message as Treat-as-withdraw according
to [RFC7606] Section 2.
Possible reasons for an error are (for more reasons see also
[RFC7606]):
o Incorrect implementation of this specification - the encoding/
decoding of the NLRI or traffic action extended-communities do not
comply with this specification.
o Unknown Flow Specification extensions - The sending party has
implemented a Flow Specification NLRI extension unknown to the
receiving party.
In order to facilitate future extensions of the Flow Specification
NLRI, such extensions SHOULD specify a way to encode a "always-true"
match condition within the newly introduced components. This match
condition can be used to propagate (and apply) certain filters only
if a specific extension is known to the implemenation.
12. IANA Considerations
This section complies with [RFC7153]. This section complies with [RFC7153].
11.1. AFI/SAFI Definitions 12.1. AFI/SAFI Definitions
IANA maintains a registry entitled "SAFI Values". For the purpose of IANA maintains a registry entitled "SAFI Values". For the purpose of
this work, IANA updated the registry and allocated two additional this work, IANA updated the registry and allocated two additional
SAFIs: SAFIs:
+-------+------------------------------------------+----------------+ +-------+------------------------------------------+----------------+
| Value | Name | Reference | | Value | Name | Reference |
+-------+------------------------------------------+----------------+ +-------+------------------------------------------+----------------+
| 133 | IPv4 dissemination of Flow Specification | [this | | 133 | IPv4 dissemination of Flow Specification | [this |
| | rules | document] | | | rules | document] |
| 134 | VPNv4 dissemination of Flow | [this | | 134 | VPNv4 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 12.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 a an 8-bit component type. IANA has created and
maintains a registry entitled "Flow Spec Component Types". This maintains a registry entitled "Flow Spec Component Types". This
document defines the following Component Type Codes: document defines the following Component Type Codes:
+-------+--------------------+-----------------+ +-------+--------------------+-----------------+
| Value | Name | Reference | | Value | Name | Reference |
+-------+--------------------+-----------------+ +-------+--------------------+-----------------+
| 1 | Destination Prefix | [this document] | | 1 | Destination Prefix | [this document] |
skipping to change at page 27, line 5 skipping to change at page 27, line 25
+--------------+-------------------------------+ +--------------+-------------------------------+
Table 5: Flow Spec Component Types Policies Table 5: Flow Spec Component Types Policies
The specification of a particular "Flow Spec Component Type" must The specification of a particular "Flow Spec Component Type" must
clearly identify what the criteria used to match packets forwarded by clearly identify what the criteria used to match packets forwarded by
the router is. This criteria should be meaningful across router hops the router is. This criteria should be meaningful across router hops
and not depend on values that change hop-by-hop such as TTL or Layer and not depend on values that change hop-by-hop such as TTL or Layer
2 encapsulation. 2 encapsulation.
11.3. Extended Community Flow Specification Actions 12.3. Extended Community Flow Specification Actions
The Extended Community Flow Specification Action types defined in The Extended Community Flow Specification Action types defined in
this document consist of two parts: this document consist of two parts:
Type (BGP Transitive Extended Community Type) Type (BGP Transitive Extended Community Type)
Sub-Type Sub-Type
For the type-part, IANA maintains a registry entitled "BGP Transitive For the type-part, IANA maintains a registry entitled "BGP Transitive
Extended Community Types". For the purpose of this work (Section 7), Extended Community Types". For the purpose of this work (Section 7),
skipping to change at page 29, line 21 skipping to change at page 29, line 48
+-----+-----------------+-----------------+ +-----+-----------------+-----------------+
| Bit | Name | Reference | | Bit | Name | Reference |
+-----+-----------------+-----------------+ +-----+-----------------+-----------------+
| 47 | Terminal Action | [this document] | | 47 | Terminal Action | [this document] |
| 46 | Sample | [this document] | | 46 | Sample | [this document] |
+-----+-----------------+-----------------+ +-----+-----------------+-----------------+
Table 10: Registry: Traffic Action Fields Table 10: Registry: Traffic Action Fields
12. Security Considerations 13. Security Considerations
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. provide service.
As long as traffic filtering rules are restricted to match the As long as traffic filtering rules are restricted to match the
corresponding unicast routing paths for the relevant prefixes, the corresponding unicast routing paths for the relevant prefixes, the
security characteristics of this proposal are equivalent to the security characteristics of this proposal are equivalent to the
existing security properties of BGP unicast routing. However, this existing security properties of BGP unicast routing. However, this
document also specifies traffic filtering actions that may need document also specifies traffic filtering actions that may need
custom additional verification on the receiver side. See Section 13. custom additional verification on the receiver side. See Section 14.
Where it is not the case, this would open the door to further denial- Where it is not the case, this would open the door to further denial-
of-service attacks. of-service attacks.
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
example, it is possible to allow TCP packets to pass between a pair example, it is possible to allow TCP packets to pass between a pair
of addresses but not ICMP packets. It is also possible to permit of addresses but not ICMP packets. It is also possible to permit
packets smaller than 900 or greater than 1000 bytes to pass between a packets smaller than 900 or greater than 1000 bytes to pass between a
pair of addresses, but not packets whose length is in the range 900- pair of addresses, but not packets whose length is in the range 900-
1000. Such behavior may be confusing and these capabilities should 1000. Such behavior may be confusing and these capabilities should
be used with care whether manually configured or coordinated through be used with care whether manually configured or coordinated through
the protocol extensions described in this document. the protocol extensions described in this document.
13. Operational Security Considerations 14. Operational Security Considerations
While the general verification of the traffic filter NLRI is While the general verification of the traffic filter 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 of action communities at network borders and by by proper filtering of action communities at network borders and by
mapping user-defined communities (see Section 7) to expose certain mapping user-defined communities (see Section 7) to expose certain
forwarding properties to third parties. forwarding properties to third parties.
Since verfication of the traffic filtering NLRI is tied to the Since verfication of the traffic filtering NLRI is tied to the
announcement of the best unicast route, a unfiltered address space announcement of the best unicast route, a unfiltered address space
hijack (e.g. advertisement of a more specific route) may cause this hijack (e.g. advertisement of a more specific route) may cause this
verification to fail and consequently prevent Flow Specification verification to fail and consequently prevent Flow Specification
filters from being accepted by a peer. filters from being accepted by a peer.
14. Original authors 15. Original authors
Barry Greene, Pedro Marques, Jared Mauch, Danny McPherson, and Barry Greene, Pedro Marques, Jared Mauch, Danny McPherson, and
Nischal Sheth were authors on RFC5575, and therefore are contributing Nischal Sheth were authors on RFC5575, and therefore are contributing
authors on this document. authors on this document.
15. Acknowledgements 16. Acknowledgements
The authors would like to thank Yakov Rekhter, Dennis Ferguson, Chris The authors would like to thank Yakov Rekhter, Dennis Ferguson, Chris
Morrow, Charlie Kaufman, and David Smith for their comments for the Morrow, Charlie Kaufman, and David Smith for their comments for the
comments on the original RFC5575. Chaitanya Kodeboyina helped design comments on the original RFC5575. Chaitanya Kodeboyina helped design
the flow validation procedure; and Steven Lin and Jim Washburn ironed the flow validation procedure; and Steven Lin and Jim Washburn ironed
out all the details necessary to produce a working implementation in out all the details necessary to produce a working implementation in
the original RFC5575. the original RFC5575.
Additional the authors would like to thank Alexander Mayrhofer, Additional the authors would like to thank Alexander Mayrhofer,
Nicolas Fevrier, Job Snijders and Jeffrey Haas for their comments and Nicolas Fevrier, Job Snijders and Jeffrey Haas for their comments and
review. review.
16. References 17. References
16.1. Normative References 17.1. Normative References
[IEEE.754.1985] [IEEE.754.1985]
IEEE, "Standard for Binary Floating-Point Arithmetic", IEEE, "Standard for Binary Floating-Point Arithmetic",
IEEE 754-1985, August 1985. IEEE 754-1985, August 1985.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>. <https://www.rfc-editor.org/info/rfc793>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 32, line 28 skipping to change at page 33, line 5
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
16.2. Informative References 17.2. Informative References
[I-D.ietf-idr-flow-spec-v6] [I-D.ietf-idr-flow-spec-v6]
McPherson, D., Raszuk, R., Pithawala, B., McPherson, D., Raszuk, R., Pithawala, B.,
akarch@cisco.com, a., and S. Hares, "Dissemination of Flow akarch@cisco.com, a., and S. Hares, "Dissemination of Flow
Specification Rules for IPv6", draft-ietf-idr-flow-spec- Specification Rules for IPv6", draft-ietf-idr-flow-spec-
v6-09 (work in progress), November 2017. v6-09 (work in progress), November 2017.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005, RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>. <https://www.rfc-editor.org/info/rfc4303>.
16.3. URIs 17.3. URIs
[1] https://github.com/stoffi92/flowspec-cmp [1] https://github.com/stoffi92/flowspec-cmp
Appendix A. Comparison with RFC 5575 Appendix A. Comparison with RFC 5575
This document includes numerous editorial changes to RFC5575. It is This document includes numerous editorial changes to RFC5575. It is
recommended to read the entire document. The authors, however want recommended to read the entire document. The authors, however want
to point out the following technical changes to RFC5575: to point out the following technical changes to RFC5575:
Section 1 introduces the Flow Specification NLRI. In RFC5575 this
NLRI was defined as an opaque-key in BGPs database. This
specification has removed all references to a opaque-key property.
BGP is able understand the NLRI encoding. This change also
resulted in a new section regarding error-handling and
extensibility (Section 11).
Section 4.2.3 defines a numeric operator and comparison bit Section 4.2.3 defines a numeric operator and comparison bit
combinations. In RFC5575 the meaning of those bit combination was combinations. In RFC5575 the meaning of those bit combination was
not explicitly defined and left open to the reader. not explicitly defined and left open to the reader.
Section 4.2.3 - Section 4.2.8, Section 4.2.10, Section 4.2.11 make Section 4.2.3 - Section 4.2.8, Section 4.2.10, Section 4.2.11 make
use of the above numeric operator. The allowed length of the use of the above numeric operator. The allowed length of the
comparison value was not consistently defined in RFC5575. comparison value was not consistently defined in RFC5575.
Section 7 defines all traffic action extended communities as Section 7 defines all traffic action extended communities as
transitive extended communities. RFC5575 defined the traffic-rate transitive extended communities. RFC5575 defined the traffic-rate
 End of changes. 24 change blocks. 
48 lines changed or deleted 72 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/