--- 1/draft-ietf-idr-rfc5575bis-01.txt 2017-06-29 07:13:23.296668165 -0700 +++ 2/draft-ietf-idr-rfc5575bis-02.txt 2017-06-29 07:13:23.380670165 -0700 @@ -1,25 +1,25 @@ IDR Working Group S. Hares Internet-Draft Huawei Obsoletes: 5575 (if approved) R. Raszuk Updates: 7674 (if approved) Bloomberg LP Intended status: Standards Track D. McPherson -Expires: September 27, 2017 Verisign +Expires: December 31, 2017 Verisign C. Loibl Next Layer Communications M. Bacher T-Mobile Austria - March 26, 2017 + June 29, 2017 Dissemination of Flow Specification Rules - draft-ietf-idr-rfc5575bis-01 + draft-ietf-idr-rfc5575bis-02 Abstract This document updates RFC5575 which defines a Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute traffic flow specifications. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix. This draft specifies IPv4 traffic flow specifications via a BGP NLRI which carries traffic flow @@ -51,21 +51,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -110,29 +110,29 @@ 7.6.1. Examples . . . . . . . . . . . . . . . . . . . . . . 21 8. Dissemination of Traffic Filtering in BGP/MPLS VPN Networks . 21 8.1. Validation Procedures for BGP/MPLS VPNs . . . . . . . . . 22 8.2. Traffic Actions Rules . . . . . . . . . . . . . . . . . . 22 9. Limitations of Previous Traffic Filtering Efforts . . . . . . 22 9.1. Limitations in Previous DDoS Traffic Filtering Efforts . 22 9.2. Limitations in Previous BGP/MPLS Traffic Filtering . . . 23 10. Traffic Monitoring . . . . . . . . . . . . . . . . . . . . . 24 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 11.1. AFI/SAFI Definitions . . . . . . . . . . . . . . . . . . 24 - 11.2. Flow Component definitions . . . . . . . . . . . . . . . 24 - 11.3. Extended Community Flow Specification Actions . . . . . 26 - 12. Security Considerations . . . . . . . . . . . . . . . . . . . 26 - 13. Original authors . . . . . . . . . . . . . . . . . . . . . . 27 - 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 - 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 - 15.1. Normative References . . . . . . . . . . . . . . . . . . 27 - 15.2. Informative References . . . . . . . . . . . . . . . . . 29 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 + 11.2. Flow Component Definitions . . . . . . . . . . . . . . . 24 + 11.3. Extended Community Flow Specification Actions . . . . . 25 + 12. Security Considerations . . . . . . . . . . . . . . . . . . . 28 + 13. Original authors . . . . . . . . . . . . . . . . . . . . . . 28 + 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 + 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 + 15.1. Normative References . . . . . . . . . . . . . . . . . . 29 + 15.2. Informative References . . . . . . . . . . . . . . . . . 31 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 1. Introduction Modern IP routers contain both the capability to forward traffic according to IP prefixes as well as to classify, shape, rate limit, filter, or redirect packets based on administratively defined policies. These traffic policy mechanisms allow the router to define match rules that operate on multiple fields of the packet header. Actions @@ -1088,128 +1088,189 @@ statistics facilities. While this is an implementation-specific choice, implementations SHOULD provide: o A mechanism to log the packet header of filtered traffic. o A mechanism to count the number of matches for a given flow specification rule. 11. IANA Considerations - This section complies with [RFC7153] + This section complies with [RFC7153]. 11.1. AFI/SAFI Definitions - For the purpose of this work, IANA has allocated values for two - SAFIs: SAFI 133 for IPv4 dissemination of flow specification rules - and SAFI 134 for VPNv4 dissemination of flow specification rules. + IANA maintains a registry entitled "SAFI Values". For the purpose of + this work, IANA updated the registry and allocated two additional + 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 - 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. + Table 3: Registry: SAFI Values - IANA created and maintains a new registry entitled: "Flow Spec - Component Types". The following component types have been - registered: +11.2. Flow Component Definitions - 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 - used: + +----------+--------------------------------------------+-----------+ + | Sub-Type | Name | Reference | + | 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) | | + +----------+--------------------------------------------+-----------+ - +--------------+-------------------------------+ - | Range | Policy | - +--------------+-------------------------------+ - | 0 | Invalid value | - | [1 .. 12] | Defined by this specification | - | [13 .. 127] | Specification Required | - | [128 .. 255] | First Come First Served | - +--------------+-------------------------------+ + Table 6: Registry: Generic Transitive Experimental Use Extended + Community Types - The specification of a particular "flow 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. + Note-1: This document replaces [RFC7674]. - The "traffic-action" extended community defined in this document has - 46 unused bits, which can be used to convey additional 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: + For the sub-type part of the extended community actions IANA + maintains and updated the following registries: - 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 - two parts: BGP Transitive Extended Community types and a set of sub- - types. + Table 8: Registry: Generic Transitive Experimental Use Extended + Community Part 2 Sub-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 - 1 (Sub-Types are defined in the "Generic Transitive Experimental - Extended Community Part 1 Sub-Types" Registry) + Table 9: Registry: Generic Transitive Experimental Use Extended + Community Part 3 Sub-Types - 0x81 - Generic Transitive Experimental Use Extended Community Part - 2 (Sub-Types are defined in the "Generic Transitive Experimental - Extended Community Part 2 Sub-Types" Registry) + Note-3: This document replaces [RFC7674], and becomes the only + reference for this table. - 0x82 - Generic Transitive Experimental Use Extended Community Part - 3 (Sub-Types are defined in the "Generic Transitive Experimental - Use Extended Community Part 3 Sub-Types" Registry) + The "traffic-action" extended community (Section 7.3) defined in this + document has 46 unused bits, which can be used to convey additional + 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 - 0xc0-0xff IETF Review + +-----+-----------------+-----------------+ + | Bit | Name | Reference | + +-----+-----------------+-----------------+ + | 47 | Terminal Action | [this document] | + | 46 | Sample | [this document] | + +-----+-----------------+-----------------+ - SUB-TYPE VALUE NAME REFERENCE - 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] + Table 10: Registry: Traffic Action Fields 12. Security Considerations Inter-provider routing is based on a web of trust. Neighboring autonomous systems are trusted to advertise valid reachability information. If this trust model is violated, a neighboring autonomous system may cause a denial-of-service attack by advertising reachability information for a given prefix for which it does not provide service. @@ -1293,20 +1354,25 @@ [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, . [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, . + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", RFC 5226, + DOI 10.17487/RFC5226, May 2008, + . + [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., and D. McPherson, "Dissemination of Flow Specification Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, . [RFC5668] Rekhter, Y., Sangli, S., and D. Tappan, "4-Octet AS Specific BGP Extended Community", RFC 5668, DOI 10.17487/RFC5668, October 2009, . @@ -1322,20 +1388,24 @@ [RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP Extended Communities", RFC 7153, DOI 10.17487/RFC7153, March 2014, . [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, August 2015, . + [RFC7674] Haas, J., Ed., "Clarification of the Flowspec Redirect + Extended Community", RFC 7674, DOI 10.17487/RFC7674, + October 2015, . + 15.2. Informative References [I-D.ietf-idr-flow-spec-v6] McPherson, D., Raszuk, R., Pithawala, B., akarch@cisco.com, a., and S. Hares, "Dissemination of Flow Specification Rules for IPv6", draft-ietf-idr-flow-spec- v6-08 (work in progress), March 2017. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005,