draft-ietf-idr-rfc5575bis-08.txt   draft-ietf-idr-rfc5575bis-09.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: December 23, 2018 R. Raszuk Expires: April 20, 2019 R. Raszuk
Bloomberg LP Bloomberg LP
D. McPherson D. McPherson
Verisign Verisign
M. Bacher M. Bacher
T-Mobile Austria T-Mobile Austria
June 21, 2018 October 17, 2018
Dissemination of Flow Specification Rules Dissemination of Flow Specification Rules
draft-ietf-idr-rfc5575bis-08 draft-ietf-idr-rfc5575bis-09
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 December 23, 2018. This Internet-Draft will expire on April 20, 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 42 skipping to change at page 2, line 42
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. 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 . . . . 6 4. Dissemination of IPv4 FLow Specification Information . . . . 7
4.1. Length Encoding . . . . . . . . . . . . . . . . . . . . . 7 4.1. Length Encoding . . . . . . . . . . . . . . . . . . . . . 7
4.2. NLRI Value Encoding . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . 8 4.2.3. Type 3 - IP Protocol . . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . 12 4.3. Examples of Encodings . . . . . . . . . . . . . . . . . . 13
5. Traffic Filtering . . . . . . . . . . . . . . . . . . . . . . 13 5. Traffic Filtering . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Ordering of Traffic Filtering Rules . . . . . . . . . . . 14 5.1. Ordering of Traffic Filtering Rules . . . . . . . . . . . 15
6. Validation Procedure . . . . . . . . . . . . . . . . . . . . 16 6. Validation Procedure . . . . . . . . . . . . . . . . . . . . 17
7. Traffic Filtering Actions . . . . . . . . . . . . . . . . . . 17 7. Traffic Filtering Actions . . . . . . . . . . . . . . . . . . 18
7.1. Traffic Rate in Bytes (traffic-rate-bytes) sub-type 0x06 19 7.1. Traffic Rate in Bytes (traffic-rate-bytes) sub-type 0x06 19
7.2. Traffic Rate in Packets (traffic-rate-packets) sub-type 7.2. Traffic Rate in Packets (traffic-rate-packets) sub-type
TBD . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 TBD . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.3. Traffic-action (traffic-action) sub-type 0x07 . . . . . . 19 7.3. Traffic-action (traffic-action) sub-type 0x07 . . . . . . 20
7.4. RT Redirect (rt-redirect) sub-type 0x08 . . . . . . . . . 20 7.4. RT Redirect (rt-redirect) sub-type 0x08 . . . . . . . . . 21
7.5. Traffic Marking (traffic-marking) sub-type 0x09 . . . . . 20 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 . . . . . . . . . . . . . . . . . . . . . . 21 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 . 23 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 . . . . . . . . . . . . . . . . . . . . . 24 10. Traffic Monitoring . . . . . . . . . . . . . . . . . . . . . 25
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
11.1. AFI/SAFI Definitions . . . . . . . . . . . . . . . . . . 24 11.1. AFI/SAFI Definitions . . . . . . . . . . . . . . . . . . 25
11.2. Flow Component Definitions . . . . . . . . . . . . . . . 25 11.2. Flow Component Definitions . . . . . . . . . . . . . . . 26
11.3. Extended Community Flow Specification Actions . . . . . 26 11.3. Extended Community Flow Specification Actions . . . . . 27
12. Security Considerations . . . . . . . . . . . . . . . . . . . 28 12. Security Considerations . . . . . . . . . . . . . . . . . . . 29
13. Original authors . . . . . . . . . . . . . . . . . . . . . . 29 13. Operational Security Considerations . . . . . . . . . . . . . 30
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 14. Original authors . . . . . . . . . . . . . . . . . . . . . . 30
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
15.1. Normative References . . . . . . . . . . . . . . . . . . 29 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
15.2. Informative References . . . . . . . . . . . . . . . . . 31 16.1. Normative References . . . . . . . . . . . . . . . . . . 30
15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 31 16.2. Informative References . . . . . . . . . . . . . . . . . 32
16.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Appendix A. Comparison with RFC 5575 . . . . . . . . . . . . . . 32 Appendix A. Comparison with RFC 5575 . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
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 4, line 29 skipping to change at page 4, line 33
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
unicast prefix and are expected to depend upon the existing unicast unicast prefix and are expected to depend upon the existing unicast
data information. data information.
A Flow Specification received from an external autonomous system will A Flow Specification received from an external autonomous system will
need to be validated against unicast routing before being accepted. need to be validated against unicast routing before being accepted.
If the aggregate traffic flow defined by the unicast destination If the aggregate traffic flow defined by the unicast destination
prefix is forwarded to a given BGP peer, then the local system can prefix is forwarded to a given BGP peer, then the local system can
safely install more specific flow rules that may result in different install more specific flow rules that may result in different
forwarding behavior, as requested by this system. forwarding behavior, as requested by this system.
The key technology components required to address the class of The key technology components required to address the class of
problems targeted by this document are: problems targeted by this document are:
1. Efficient point-to-multipoint distribution of control plane 1. Efficient point-to-multipoint distribution of control plane
information. information.
2. Inter-domain capabilities and routing policy support. 2. Inter-domain capabilities and routing policy support.
skipping to change at page 5, line 8 skipping to change at page 5, line 13
choice of BGP as the carrier of Flow Specification information. choice of BGP as the carrier of Flow Specification information.
As with previous extensions to BGP, this specification makes it As with previous extensions to BGP, this specification makes it
possible to add additional information to Internet routers. These possible to add additional information to Internet routers. These
are limited in terms of the maximum number of data elements they can are limited in terms of the maximum number of data elements they can
hold as well as the number of events they are able to process in a hold as well as the number of events they are able to process in a
given unit of time. The authors believe that, as with previous given unit of time. The authors believe that, as with previous
extensions, service providers will be careful to keep information extensions, service providers will be careful to keep information
levels below the maximum capacity of their devices. levels below the maximum capacity of their devices.
In many deployments of BGP Flow Specification, the Flow Specification
information has replace existing host length route advertisements.
Experience with previous BGP extensions has also shown that the Experience with previous BGP extensions has also shown that the
maximum capacity of BGP speakers has been gradually increased maximum capacity of BGP speakers has been gradually increased
according to expected loads. Taking into account Internet unicast according to expected loads. For example Internet unicast routing as
routing as well as additional applications as they gain popularity. well as other BGP applications increased their maximum capacity as
they gain popularity.
From an operational perspective, the utilization of BGP as the From an operational perspective, the utilization of BGP as the
carrier for this information allows a network service provider to carrier for this information allows a network service provider to
reuse both internal route distribution infrastructure (e.g., route reuse both internal route distribution infrastructure (e.g., route
reflector or confederation design) and existing external reflector or confederation design) and existing external
relationships (e.g., inter-domain BGP sessions to a customer relationships (e.g., inter-domain BGP sessions to a customer
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
skipping to change at page 9, line 16 skipping to change at page 9, line 25
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| e | a | len | 0 |lt |gt |eq | | e | a | len | 0 |lt |gt |eq |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
Numeric operator Numeric operator
e - end-of-list bit. Set in the last {op, value} pair in the e - end-of-list bit. Set in the last {op, value} pair in the
list. list.
a - AND bit. If unset, the previous term is logically ORed with a - AND bit. If unset, the previous term is logically ORed with
the current one. If set, the operation is a logical AND. It the current one. If set, the operation is a logical AND. In the
should be unset in the first operator byte of a sequence. The AND first operator byte of a sequence it SHOULD be encoded as unset
and and MUST be treated as always unset on decoding. The AND
operator has higher priority than OR for the purposes of operator has higher priority than OR for the purposes of
evaluating logical expressions. evaluating logical expressions.
len - length of the value field for this operand encodes 1 (00) - len - length of the value field for this operand encodes 1 (00) -
4 (11) bytes. Type 3 flow component values are always encoded as 4 (11) bytes. Type 3 flow component values SHOULD be encoded as
single byte (len = 00). single byte (len = 00).
0 - SHOULD be set to 0 on NLRI encoding, and MUST be ignored
during decoding
lt - less than comparison between data and value. lt - less than comparison between data and value.
gt - greater than comparison between data and value. gt - greater than comparison between data and value.
eq - equality between data and value. eq - equality between data and value.
The bits lt, gt, and eq can be combined to produce common relational The bits lt, gt, and eq can be combined to produce common relational
operators such as "less or equal", "greater or equal", and "not equal operators such as "less or equal", "greater or equal", and "not equal
to". to".
skipping to change at page 10, line 11 skipping to change at page 10, line 26
+----+----+----+----------------------------------+ +----+----+----+----------------------------------+
Table 1: Comparison operation combinations Table 1: Comparison operation combinations
4.2.4. Type 4 - Port 4.2.4. Type 4 - Port
Encoding:<type (1 octet), [op, value]+> Encoding:<type (1 octet), [op, value]+>
Defines a list of {operator, value} pairs that matches source OR Defines a list of {operator, value} pairs that matches source OR
destination TCP/UDP ports. This list is encoded using the numeric destination TCP/UDP ports. This list is encoded using the numeric
operator format defined in Section 4.2.3. Values are encoded as operator format defined in Section 4.2.3. Values SHOULD be
1- or 2-byte quantities. encoded as 1- or 2-byte quantities.
Port, source port, and destination port components evaluate to Port, source port, and destination port components evaluate to
FALSE if the IP protocol field of the packet has a value other FALSE if the IP protocol field of the packet has a value other
than TCP or UDP, if the packet is fragmented and this is not the than TCP or UDP, if the packet is fragmented and this is not the
first fragment, or if the system in unable to locate the transport first fragment, or if the system in unable to locate the transport
header. Different implementations may or may not be able to header. Different implementations may or may not be able to
decode the transport header in the presence of IP options or decode the transport header in the presence of IP options or
Encapsulating Security Payload (ESP) NULL [RFC4303] encryption. Encapsulating Security Payload (ESP) NULL [RFC4303] encryption.
4.2.5. Type 5 - Destination Port 4.2.5. Type 5 - Destination Port
Encoding:<type (1 octet), [op, value]+> Encoding:<type (1 octet), [op, value]+>
Defines a list of {operator, value} pairs used to match the Defines a list of {operator, value} pairs used to match the
destination port of a TCP or UDP packet. This list is encoded destination port of a TCP or UDP packet. This list is encoded
using the numeric operator format defined in Section 4.2.3. using the numeric operator format defined in Section 4.2.3.
Values are encoded as 1- or 2-byte quantities. Values SHOULD be encoded as 1- or 2-byte quantities.
4.2.6. Type 6 - Source Port 4.2.6. Type 6 - Source Port
Encoding:<type (1 octet), [op, value]+> Encoding:<type (1 octet), [op, value]+>
Defines a list of {operator, value} pairs used to match the source Defines a list of {operator, value} pairs used to match the source
port of a TCP or UDP packet. This list is encoded using the port of a TCP or UDP packet. This list is encoded using the
numeric operator format defined in Section 4.2.3. Values are numeric operator format defined in Section 4.2.3. Values SHOULD
encoded as 1- or 2-byte quantities. be encoded as 1- or 2-byte quantities.
4.2.7. Type 7 - ICMP type 4.2.7. Type 7 - ICMP type
Encoding:<type (1 octet), [op, value]+> Encoding:<type (1 octet), [op, value]+>
Defines a list of {operator, value} pairs used to match the type Defines a list of {operator, value} pairs used to match the type
field of an ICMP packet. This list is encoded using the numeric field of an ICMP packet. This list is encoded using the numeric
operator format defined in Section 4.2.3. Values are encoded operator format defined in Section 4.2.3. Values SHOULD be
using a single byte. encoded using a single byte.
The ICMP type specifiers evaluate to FALSE whenever the protocol The ICMP type specifiers evaluate to FALSE whenever the protocol
value is not ICMP. value is not ICMP.
4.2.8. Type 8 - ICMP code 4.2.8. Type 8 - ICMP code
Encoding:<type (1 octet), [op, value]+> Encoding:<type (1 octet), [op, value]+>
Defines a list of {operator, value} pairs used to match the code Defines a list of {operator, value} pairs used to match the code
field of an ICMP packet. This list is encoded using the numeric field of an ICMP packet. This list is encoded using the numeric
operator format defined in Section 4.2.3. Values are encoded operator format defined in Section 4.2.3. Values SHOULD be
using a single byte. encoded using a single byte.
The ICMP code specifiers evaluate to FALSE whenever the protocol The ICMP code specifiers evaluate to FALSE whenever the protocol
value is not ICMP. value is not ICMP.
4.2.9. Type 9 - TCP flags 4.2.9. Type 9 - TCP flags
Encoding:<type (1 octet), [op, bitmask]+> Encoding:<type (1 octet), [op, bitmask]+>
Bitmask values can be encoded as a 1- or 2-byte bitmask. When a Bitmask values can be encoded as a 1- or 2-byte bitmask. When a
single byte is specified, it matches byte 13 of the TCP header single byte is specified, it matches byte 13 of the TCP header
skipping to change at page 12, line 5 skipping to change at page 12, line 23
length field), as defined for in the numeric operator format in length field), as defined for in the numeric operator format in
Section 4.2.3. Section 4.2.3.
not - NOT bit. If set, logical negation of operation. not - NOT bit. If set, logical negation of operation.
m - Match bit. If set, this is a bitwise match operation defined m - Match bit. If set, this is a bitwise match operation defined
as "(data AND value) == value"; if unset, (data AND value) as "(data AND value) == value"; if unset, (data AND value)
evaluates to TRUE if any of the bits in the value mask are set in evaluates to TRUE if any of the bits in the value mask are set in
the data the data
0 - all 0 bits SHOULD be set to 0 on NLRI encoding, and MUST be
ignored during decoding
4.2.10. Type 10 - Packet length 4.2.10. Type 10 - Packet length
Encoding:<type (1 octet), [op, bitmask]+> Encoding:<type (1 octet), [op, bitmask]+>
Defines a list of {operator, value} pairs used to match on the Defines a list of {operator, value} pairs used to match on the
total IP packet length (excluding Layer 2 but including IP total IP packet length (excluding Layer 2 but including IP
header). This list is encoded using the numeric operator format header). This list is encoded using the numeric operator format
defined in Section 4.2.3. Values are encoded using 1- or 2-byte defined in Section 4.2.3. Values SHOULD be encoded using 1- or
quantities. 2-byte quantities.
4.2.11. Type 11 - DSCP (Diffserv Code Point) 4.2.11. Type 11 - DSCP (Diffserv Code Point)
Encoding:<type (1 octet), [op, value]+> Encoding:<type (1 octet), [op, value]+>
Defines a list of {operator, value} pairs used to match the 6-bit Defines a list of {operator, value} pairs used to match the 6-bit
DSCP field [RFC2474]. This list is encoded using the numeric DSCP field [RFC2474]. This list is encoded using the numeric
operator format defined in Section 4.2.3. Values are encoded operator format defined in Section 4.2.3. Values SHOULD be
using a single byte. The two most significant bits are zero and encoded using a single byte. The six least significant bits
the six least significant bits contain the DSCP value. contain the DSCP value. All other bits SHOULD be encoded as zero
and ignored on decoding.
4.2.12. Type 12 - Fragment 4.2.12. Type 12 - Fragment
Encoding:<type (1 octet), [op, bitmask]+> Encoding:<type (1 octet), [op, bitmask]+>
Uses bitmask operand format defined in Section 4.2.9. Uses bitmask operand format defined in Section 4.2.9.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| Reserved |LF |FF |IsF|DF | | 0 | 0 | 0 | 0 |LF |FF |IsF|DF |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
Bitmask values: Bitmask values:
Bit 7 - Don't fragment (DF) Bit 7 - Don't fragment (DF)
Bit 6 - Is a fragment (IsF) Bit 6 - Is a fragment (IsF)
Bit 5 - First fragment (FF) Bit 5 - First fragment (FF)
Bit 4 - Last fragment (LF) Bit 4 - Last fragment (LF)
Bit 0-3 - SHOULD be set to 0 on NLRI encoding, and MUST be
ignored during decoding
4.3. Examples of Encodings 4.3. Examples of Encodings
An example of a Flow Specification encoding for: "all packets to An example of a Flow Specification encoding for: "all packets to
10.0.1/24 and TCP port 25". 10.0.1/24 and TCP port 25".
+------------------+----------+----------+ +------------------+----------+----------+
| destination | proto | port | | destination | proto | port |
+------------------+----------+----------+ +------------------+----------+----------+
| 0x01 18 0a 00 01 | 03 81 06 | 04 81 19 | | 0x01 18 0a 00 01 | 03 81 06 | 04 81 19 |
+------------------+----------+----------+ +------------------+----------+----------+
skipping to change at page 14, line 8 skipping to change at page 14, line 31
5. Traffic Filtering 5. Traffic Filtering
Traffic filtering policies have been traditionally considered to be Traffic filtering policies have been traditionally considered to be
relatively static. Limitations of the static mechanisms caused this relatively static. Limitations of the static mechanisms caused this
mechanism to be designed for the three new applications of traffic mechanism to be designed for the three new applications of traffic
filtering (prevention of traffic-based, denial-of-service (DOS) filtering (prevention of traffic-based, denial-of-service (DOS)
attacks, traffic filtering in the context of BGP/MPLS VPN service, attacks, traffic filtering in the context of BGP/MPLS VPN service,
and centralized traffic control for SDN/NFV networks) requires and centralized traffic control for SDN/NFV networks) requires
coordination among service providers and/or coordination among the AS coordination among service providers and/or coordination among the AS
within a service provider. Section 8 has details on the limitation within a service provider. Section 8 has details on the limitation
of previous mechanisms and why BGP Flow Specification version 1 of previous mechanisms and why BGP Flow Specification provides a
provides a solution for to prevent DOS and aid BGP/MPLS VPN filtering solution for to prevent DOS and aid BGP/MPLS VPN filtering rules.
rules.
This Flow Specification NLRI defined above to convey information This Flow Specification NLRI defined above to convey 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 manner specified by a set of pre-defined actions (which handled in 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 draft specifies two application In order to achieve this goal, this draft specifies two application
skipping to change at page 19, line 18 skipping to change at page 19, line 47
Communities. 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
The traffic-rate-bytes extended community uses the following extended The traffic-rate-bytes extended community uses the following extended
community encoding: community encoding:
The first two octets carry the 2-octet id, which can be assigned from The first two octets carry the 2-octet id, which can be assigned from
a 2-byte AS number. When a 4-byte AS number is locally present, the a 2-byte AS number. When a 4-byte AS number is locally present, the
2 least significant bytes of such an AS number can be used. This 2 least significant bytes of such an AS number can be used. This
value is purely informational and should not be interpreted by the value is purely informational and SHOULD NOT be interpreted by the
implementation. 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. flow to be discarded. On encoding the traffic-rate MUST NOT be
negative. On decoding negative values MUST be treated as zero
(discard all traffic).
Interferes with: No other BGP Flow Specification traffic action in Interferes with: No other BGP Flow Specification traffic action in
this document. this document.
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. flow to be discarded. On encoding the traffic-rate-packets MUST NOT
be negative. On decoding negative values MUST be treated as zero
(discard all traffic).
Interferes with: No other BGP Flow Specification traffic action in Interferes with: No other BGP Flow Specification traffic action in
this document. this document.
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 bytes of which The traffic-action extended community consists of 6 bytes of which
only the 2 least significant bits of the 6th byte (from left to only the 2 least significant bits of the 6th byte (from left to
right) are currently defined. right) are currently defined.
skipping to change at page 24, line 28 skipping to change at page 25, line 17
default, this means that site-to-site traffic is unfiltered. default, this means that site-to-site traffic is unfiltered.
In circumstances where a security threat does get propagated inside In circumstances where a security threat does get propagated inside
the VPN customer network, there may not be readily available the VPN customer network, there may not be readily available
mechanisms to provide mitigation via traffic filter. mechanisms to provide mitigation via traffic filter.
But also Internet service providers may use those VPNs for scenarios But also Internet service providers may use those VPNs for scenarios
like having the Internet routing table in a VRF. Therefore, like having the Internet routing table in a VRF. Therefore,
limitations described in Section 9.1 also apply to this section. limitations described in Section 9.1 also apply to this section.
The BGP Flow Specification version 1 addresses these limitations. The BGP Flow Specification addresses these limitations.
10. Traffic Monitoring 10. Traffic Monitoring
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
skipping to change at page 29, line 11 skipping to change at page 29, line 33
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. existing security properties of BGP unicast routing. However, this
document also specifies traffic filtering actions that may need
custom additional verification on the receiver side. See Section 13.
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. Original authors 13. Operational Security Considerations
Barry Greene, MuPedro Marques, Jared Mauch, Danny McPherson, and While the general verification of the traffic filter NLRI is
specified in this document (Section 6) the traffic filtering actions
received by a third party may need custom verification or filtering.
In particular all non traffic-rate actions may allow a third party to
modify packet forwarding properties and potentially gain access to
other routing-tables/VPNs or undesired queues. This can be avoided
by proper filtering of action communities at network borders and by
mapping user-defined communities (see Section 7) to expose certain
forwarding properties to third parties.
Since verfication of the traffic filtering NLRI is tied to the
announcement of the best unicast route, a unfiltered address space
hijack (e.g. advertisement of a more specific route) may cause this
verification to fail and consequently prevent Flow Specification
filters from being accepted by a peer.
14. Original authors
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.
14. Acknowledgements 15. 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 and Job Snijders for their comments and review. Nicolas Fevrier, Job Snijders and Jeffrey Haas for their comments and
review.
15. References 16. References
15.1. Normative References 16.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 31, line 33 skipping to change at page 32, line 28
[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>.
15.2. Informative References 16.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>.
15.3. URIs 16.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 4.2.3 defines a numeric operator and comparison bit Section 4.2.3 defines a numeric operator and comparison bit
 End of changes. 44 change blocks. 
72 lines changed or deleted 106 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/