draft-ietf-idr-rfc5575bis-01.txt   draft-ietf-idr-rfc5575bis-02.txt 
IDR Working Group S. Hares IDR Working Group S. Hares
Internet-Draft Huawei Internet-Draft Huawei
Obsoletes: 5575 (if approved) R. Raszuk Obsoletes: 5575 (if approved) R. Raszuk
Updates: 7674 (if approved) Bloomberg LP Updates: 7674 (if approved) Bloomberg LP
Intended status: Standards Track D. McPherson Intended status: Standards Track D. McPherson
Expires: September 27, 2017 Verisign Expires: December 31, 2017 Verisign
C. Loibl C. Loibl
Next Layer Communications Next Layer Communications
M. Bacher M. Bacher
T-Mobile Austria T-Mobile Austria
March 26, 2017 June 29, 2017
Dissemination of Flow Specification Rules Dissemination of Flow Specification Rules
draft-ietf-idr-rfc5575bis-01 draft-ietf-idr-rfc5575bis-02
Abstract Abstract
This document updates RFC5575 which defines a Border Gateway Protocol This document updates RFC5575 which defines a Border Gateway Protocol
Network Layer Reachability Information (BGP NLRI) encoding format Network Layer Reachability Information (BGP NLRI) encoding format
that can be used to distribute traffic flow specifications. This that can be used to distribute traffic flow specifications. This
allows the routing system to propagate information regarding more allows the routing system to propagate information regarding more
specific components of the traffic aggregate defined by an IP specific components of the traffic aggregate defined by an IP
destination prefix. This draft specifies IPv4 traffic flow destination prefix. This draft specifies IPv4 traffic flow
specifications via a BGP NLRI which carries traffic flow specifications via a BGP NLRI which carries traffic flow
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 September 27, 2017. This Internet-Draft will expire on December 31, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 3, line 30 skipping to change at page 3, line 30
7.6.1. Examples . . . . . . . . . . . . . . . . . . . . . . 21 7.6.1. Examples . . . . . . . . . . . . . . . . . . . . . . 21
8. Dissemination of Traffic Filtering in BGP/MPLS VPN Networks . 21 8. Dissemination of Traffic Filtering in BGP/MPLS VPN Networks . 21
8.1. Validation Procedures for BGP/MPLS VPNs . . . . . . . . . 22 8.1. Validation Procedures for BGP/MPLS VPNs . . . . . . . . . 22
8.2. Traffic Actions Rules . . . . . . . . . . . . . . . . . . 22 8.2. Traffic Actions Rules . . . . . . . . . . . . . . . . . . 22
9. Limitations of Previous Traffic Filtering Efforts . . . . . . 22 9. Limitations of Previous Traffic Filtering Efforts . . . . . . 22
9.1. Limitations in Previous DDoS Traffic Filtering Efforts . 22 9.1. Limitations in Previous DDoS Traffic Filtering Efforts . 22
9.2. Limitations in Previous BGP/MPLS Traffic Filtering . . . 23 9.2. Limitations in Previous BGP/MPLS Traffic Filtering . . . 23
10. Traffic Monitoring . . . . . . . . . . . . . . . . . . . . . 24 10. Traffic Monitoring . . . . . . . . . . . . . . . . . . . . . 24
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
11.1. AFI/SAFI Definitions . . . . . . . . . . . . . . . . . . 24 11.1. AFI/SAFI Definitions . . . . . . . . . . . . . . . . . . 24
11.2. Flow Component definitions . . . . . . . . . . . . . . . 24 11.2. Flow Component Definitions . . . . . . . . . . . . . . . 24
11.3. Extended Community Flow Specification Actions . . . . . 26 11.3. Extended Community Flow Specification Actions . . . . . 25
12. Security Considerations . . . . . . . . . . . . . . . . . . . 26 12. Security Considerations . . . . . . . . . . . . . . . . . . . 28
13. Original authors . . . . . . . . . . . . . . . . . . . . . . 27 13. Original authors . . . . . . . . . . . . . . . . . . . . . . 28
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
15.1. Normative References . . . . . . . . . . . . . . . . . . 27 15.1. Normative References . . . . . . . . . . . . . . . . . . 29
15.2. Informative References . . . . . . . . . . . . . . . . . 29 15.2. Informative References . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
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 24, line 24 skipping to change at page 24, line 24
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. IANA Considerations
This section complies with [RFC7153] This section complies with [RFC7153].
11.1. AFI/SAFI Definitions 11.1. AFI/SAFI Definitions
For the purpose of this work, IANA has allocated values for two IANA maintains a registry entitled "SAFI Values". For the purpose of
SAFIs: SAFI 133 for IPv4 dissemination of flow specification rules this work, IANA updated the registry and allocated two additional
and SAFI 134 for VPNv4 dissemination of flow specification rules. SAFIs:
11.2. Flow Component definitions +-------+------------------------------------------+----------------+
| Value | Name | Reference |
+-------+------------------------------------------+----------------+
| 133 | IPv4 dissemination of flow specification | [this |
| | rules | document] |
| 134 | VPNv4 dissemination of flow | [this |
| | specification rules | document] |
+-------+------------------------------------------+----------------+
A flow specification consists of a sequence of flow components, which Table 3: Registry: SAFI Values
are identified by a an 8-bit component type. Types must be assigned
and interpreted uniquely. The current specification defines types 1
though 12, with the value 0 being reserved.
IANA created and maintains a new registry entitled: "Flow Spec 11.2. Flow Component Definitions
Component Types". The following component types have been
registered:
Type 1 - Destination Prefix A flow specification consists of a sequence of flow components, which
are identified by a an 8-bit component type. IANA has created and
maintains a registry entitled "Flow Spec Component Types". This
document defines the following Component Type Codes:
Type 2 - Source Prefix +-------+--------------------+-----------------+
| Value | Name | Reference |
+-------+--------------------+-----------------+
| 1 | Destination Prefix | [this document] |
| 2 | Source Prefix | [this document] |
| 3 | IP Protocol | [this document] |
| 4 | Port | [this document] |
| 5 | Destination port | [this document] |
| 6 | Source port | [this document] |
| 7 | ICMP type | [this document] |
| 8 | ICMP code | [this document] |
| 9 | TCP flags | [this document] |
| 10 | Packet length | [this document] |
| 11 | DSCP | [this document] |
| 12 | Fragment | [this document] |
+-------+--------------------+-----------------+
Type 3 - IP Protocol Table 4: Registry: Flow Spec Component Types
Type 4 - Port In order to manage the limited number space and accommodate several
usages, the following policies defined by [RFC5226] used:
Type 5 - Destination port +--------------+-------------------------------+
Type 6 - Source port | Range | Policy |
+--------------+-------------------------------+
| 0 | Invalid value |
| [1 .. 12] | Defined by this specification |
| [13 .. 127] | Specification required |
| [128 .. 255] | First Come First Served |
+--------------+-------------------------------+
Type 7 - ICMP type Table 5: Flow Spec Component Types Policies
Type 8 - ICMP code The specification of a particular "Flow Spec Component Type" must
clearly identify what the criteria used to match packets forwarded by
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
2 encapsulation.
Type 9 - TCP flags 11.3. Extended Community Flow Specification Actions
Type 10 - Packet length The Extended Community Flow Specification Action types defined in
this document consist of two parts:
Type 11 - DSCP Type (BGP Transitive Extended Community Type)
Type 12 - Fragment Sub-Type
Type 13 - Bit Mask filter For the type-part, IANA maintains a registry entitled "BGP Transitive
Extended Community Types". For the purpose of this work (Section 7),
IANA updated the registry to contain the values listed below:
In order to manage the limited number space and accommodate several +----------+--------------------------------------------+-----------+
usages, the following policies defined by RFC 5226 [RFC5226] are | Sub-Type | Name | Reference |
used: | Value | | |
+----------+--------------------------------------------+-----------+
| 0x80 | Generic Transitive Experimental Use | [RFC7153] |
| | Extended Community (Sub-Types are defined | |
| | in the "Generic Transitive Experimental | |
| | Use Extended Community Sub-Types" | |
| | registry) | |
| 0x81 | Generic Transitive Experimental Use | [this |
| | Extended Community Part 2 (Sub-Types are | document] |
| | defined in the "Generic Transitive | [See |
| | Experimental Use Extended Community Part 2 | Note-1] |
| | Sub-Types" Registry) | |
| 0x82 | Generic Transitive Experimental Use | [this |
| | Extended Community Part 3 (Sub-Types are | document] |
| | defined in the "Generic Transitive | [See |
| | Experimental Use Extended Community Part 3 | Note-1] |
| | Sub-Types" Registry) | |
+----------+--------------------------------------------+-----------+
+--------------+-------------------------------+ Table 6: Registry: Generic Transitive Experimental Use Extended
| Range | Policy | Community Types
+--------------+-------------------------------+
| 0 | Invalid value |
| [1 .. 12] | Defined by this specification |
| [13 .. 127] | Specification Required |
| [128 .. 255] | First Come First Served |
+--------------+-------------------------------+
The specification of a particular "flow component type" must clearly Note-1: This document replaces [RFC7674].
identify what the criteria used to match packets forwarded by 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 2
encapsulation.
The "traffic-action" extended community defined in this document has For the sub-type part of the extended community actions IANA
46 unused bits, which can be used to convey additional meaning. IANA maintains and updated the following registries:
created and maintains a new registry entitled: "Traffic Action
Fields". These values should be assigned via IETF Review rules only.
The following traffic-action fields have been allocated:
47 Terminal Action +----------+------------------------------------------+-------------+
| Sub-Type | Name | Reference |
| Value | | |
+----------+------------------------------------------+-------------+
| 0x06 | Flow spec traffic-rate-bytes | [this |
| | | document] |
| TBD | Flow spec traffic-rate-packets | [this |
| | | document] |
| 0x07 | Flow spec traffic-action (Use of the | [this |
| | "Value" field is defined in the "Traffic | document]. |
| | Action Fields" registry) | [Note-2] |
| 0x08 | Flow spec rt-redirect AS-2byte format | [this |
| | | document] |
| 0x09 | Flow spec traffic-remarking | [this |
| | | document] |
+----------+------------------------------------------+-------------+
46 Sample Table 7: Registry: Generic Transitive Experimental Use Extended
Community Sub-Types
0-45 Unassigned Note-2: This document replaces both [RFC7674] and [RFC5575].
11.3. Extended Community Flow Specification Actions +-------------+---------------------------+-------------------------+
| Sub-Type | Name | Reference |
| Value | | |
+-------------+---------------------------+-------------------------+
| 0x08 | Flow spec rt-redirect | [this document] [See |
| | IPv4 format | Note-3] |
+-------------+---------------------------+-------------------------+
The Extended Community FLow Specification Action types consists of Table 8: Registry: Generic Transitive Experimental Use Extended
two parts: BGP Transitive Extended Community types and a set of sub- Community Part 2 Sub-Types
types.
IANA has updated the following "BGP Transitive Extended Community +-------------+----------------------------+------------------------+
Types" registries to contain the values listed below: | Sub-Type | Name | Reference |
| Value | | |
+-------------+----------------------------+------------------------+
| 0x08 | Flow spec rt-redirect AS- | [this document] [See |
| | 4byte format | Note-3] |
+-------------+----------------------------+------------------------+
0x80 - Generic Transitive Experimental Use Extended Community Part Table 9: Registry: Generic Transitive Experimental Use Extended
1 (Sub-Types are defined in the "Generic Transitive Experimental Community Part 3 Sub-Types
Extended Community Part 1 Sub-Types" Registry)
0x81 - Generic Transitive Experimental Use Extended Community Part Note-3: This document replaces [RFC7674], and becomes the only
2 (Sub-Types are defined in the "Generic Transitive Experimental reference for this table.
Extended Community Part 2 Sub-Types" Registry)
0x82 - Generic Transitive Experimental Use Extended Community Part The "traffic-action" extended community (Section 7.3) defined in this
3 (Sub-Types are defined in the "Generic Transitive Experimental document has 46 unused bits, which can be used to convey additional
Use Extended Community Part 3 Sub-Types" Registry) meaning. IANA created and maintains a new registry entitled:
"Traffic Action Fields". These values should be assigned via IETF
Review rules only. The following traffic-action fields have been
allocated:
RANGE REGISTRATION PROCEDURE +-----+-----------------+-----------------+
0x00-0xbf First Come First Served | Bit | Name | Reference |
0xc0-0xff IETF Review +-----+-----------------+-----------------+
| 47 | Terminal Action | [this document] |
| 46 | Sample | [this document] |
+-----+-----------------+-----------------+
SUB-TYPE VALUE NAME REFERENCE Table 10: Registry: Traffic Action Fields
0x00-0x05 unassigned
0x06 traffic-rate [this document]
0x07 traffic-action [this document]
0x08 Flow spec redirect IPv4 [RFC5575] [RFC7674]
[this document]
0x09 traffic-marking [this document]
0x0a-0xff Unassigned [this document]
12. Security Considerations 12. 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.
skipping to change at page 28, line 39 skipping to change at page 30, line 20
[RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private
LAN Service (VPLS) Using BGP for Auto-Discovery and LAN Service (VPLS) Using BGP for Auto-Discovery and
Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007,
<http://www.rfc-editor.org/info/rfc4761>. <http://www.rfc-editor.org/info/rfc4761>.
[RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private
LAN Service (VPLS) Using Label Distribution Protocol (LDP) LAN Service (VPLS) Using Label Distribution Protocol (LDP)
Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007,
<http://www.rfc-editor.org/info/rfc4762>. <http://www.rfc-editor.org/info/rfc4762>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J.,
and D. McPherson, "Dissemination of Flow Specification and D. McPherson, "Dissemination of Flow Specification
Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009,
<http://www.rfc-editor.org/info/rfc5575>. <http://www.rfc-editor.org/info/rfc5575>.
[RFC5668] Rekhter, Y., Sangli, S., and D. Tappan, "4-Octet AS [RFC5668] Rekhter, Y., Sangli, S., and D. Tappan, "4-Octet AS
Specific BGP Extended Community", RFC 5668, Specific BGP Extended Community", RFC 5668,
DOI 10.17487/RFC5668, October 2009, DOI 10.17487/RFC5668, October 2009,
<http://www.rfc-editor.org/info/rfc5668>. <http://www.rfc-editor.org/info/rfc5668>.
skipping to change at page 29, line 19 skipping to change at page 31, line 5
[RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP [RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP
Extended Communities", RFC 7153, DOI 10.17487/RFC7153, Extended Communities", RFC 7153, DOI 10.17487/RFC7153,
March 2014, <http://www.rfc-editor.org/info/rfc7153>. March 2014, <http://www.rfc-editor.org/info/rfc7153>.
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
Patel, "Revised Error Handling for BGP UPDATE Messages", Patel, "Revised Error Handling for BGP UPDATE Messages",
RFC 7606, DOI 10.17487/RFC7606, August 2015, RFC 7606, DOI 10.17487/RFC7606, August 2015,
<http://www.rfc-editor.org/info/rfc7606>. <http://www.rfc-editor.org/info/rfc7606>.
[RFC7674] Haas, J., Ed., "Clarification of the Flowspec Redirect
Extended Community", RFC 7674, DOI 10.17487/RFC7674,
October 2015, <http://www.rfc-editor.org/info/rfc7674>.
15.2. Informative References 15.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-08 (work in progress), March 2017. v6-08 (work in progress), March 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,
 End of changes. 39 change blocks. 
88 lines changed or deleted 158 lines changed or added

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