--- 1/draft-ietf-idr-flow-spec-02.txt 2008-11-21 07:12:08.000000000 +0100 +++ 2/draft-ietf-idr-flow-spec-03.txt 2008-11-21 07:12:08.000000000 +0100 @@ -1,24 +1,24 @@ IDR Working Group P. Marques Internet-Draft N. Sheth -Expires: March 7, 2009 R. Raszuk +Expires: May 24, 2009 R. Raszuk B. Greene Juniper Networks J. Mauch NTT/Verio D. McPherson Arbor Networks - September 3, 2008 + November 20, 2008 Dissemination of flow specification rules - draft-ietf-idr-flow-spec-02 + draft-ietf-idr-flow-spec-03 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -29,21 +29,21 @@ 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on March 7, 2009. + This Internet-Draft will expire on May 24, 2009. Abstract This document defines a new 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. Additionally it defines two applications of that encoding format. One that can be used to automate inter-domain coordination of traffic @@ -61,24 +61,24 @@ 2. Flow specifications . . . . . . . . . . . . . . . . . . . . . 6 3. Dissemination of Information . . . . . . . . . . . . . . . . . 7 4. Traffic filtering . . . . . . . . . . . . . . . . . . . . . . 13 4.1. Order of traffic filtering rules . . . . . . . . . . . . . 14 5. Validation procedure . . . . . . . . . . . . . . . . . . . . . 15 6. Traffic Filtering Actions . . . . . . . . . . . . . . . . . . 17 7. Traffic filtering in RFC2547bis networks . . . . . . . . . . . 19 8. Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . 20 9. Security considerations . . . . . . . . . . . . . . . . . . . 21 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 - 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 - 12. Normative References . . . . . . . . . . . . . . . . . . . . . 24 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 - Intellectual Property and Copyright Statements . . . . . . . . . . 27 + 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 + 12. Normative References . . . . . . . . . . . . . . . . . . . . . 25 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 + Intellectual Property and Copyright Statements . . . . . . . . . . 28 1. Introduction Modern IP routers contain both the capability to forward traffic according to aggregate IP prefixes as well as to classify, shape, limit filter or redirect packets based on administratively defined policies. While forwarding information is, typically, dynamically signaled across the network via routing protocols, there is no agreed upon @@ -595,25 +595,31 @@ +--------+--------------------+--------------------------+ | type | extended community | encoding | +--------+--------------------+--------------------------+ | 0x8006 | traffic-rate | 2-byte as#, 4-byte float | | | | | | 0x8007 | traffic-action | bitmask | | | | | | 0x8008 | redirect | 6-byte Route Target | +--------+--------------------+--------------------------+ - Traffic-rate The traffic-rate extended community uses the same - encoding as the "Link Bandwidth" [RFC4360] extended community. - The rate is is expressed as 4 octets in IEEE floating point - format, units being bytes per second. A traffic-rate of 0 should - result on all traffic for the particular flow to be discarded. + Traffic-rate The traffic-rate extended community is a non-transitive + extended community across the Autonomous system boundary and uses + following extended community encoding: + + The first two octets carry the 2 octet id which can be assigned + from a 2 byte AS number + + The remaining 4 octets carry the rate information in IEEE + floating point format, units being bytes per second. A + traffic-rate of 0 should result on all traffic for the + particular flow to be discarded. Traffic-action The traffic-action extended community consists of 6 bytes of which only the 2 least significant bits of the 6th byte (from left to right) are currently defined. * Terminal action (bit 0). When this bit is set the traffic filtering engine will apply any subsequent filtering rules (as defined by the ordering procedure). If not set the evaluation of the traffic filter stops when this rule is applied. @@ -698,20 +704,61 @@ Where it not the case, this would open the door to further denial of service attacks. 10. IANA Considerations 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. + For the purpose of this work IANA has allocated values for two SAFIs: + SAFI 133 for IPv4 and SAFI 134 for VPNv4 dissemination of flow + specification rules. + + The following traffic filtering flow specification rules are to be + allocated by IANA from BGP Extended Communities Type - Experimental + Use registry. Authors recommend the following type values: + + 0x8006 - Flow spec traffic-rate + + 0x8007 - Flow spec traffic-action + + 0x8008 - Flow spec redirect + + Authors would like to ask IANA to create and maintain a new registry + entitled: "Flow Spec Component Type". Authors recommend to allocate + the following component types: + + Type 1 - Destination Prefix + + Type 2 - Source Prefix + + Type 3 - IP Protocol + + Type 4 - Port + + Type 5 - Destination port + + Type 6 - Source port + + Type 7 - ICMP type + + Type 8 - ICMP code + + Type 9 - TCP flags + + Type 10 - Packet length + + Type 11 - DSCP + Type 12 - Fragment + In order to manage the limited number space and accommodate several usages the following policies defined by RFC 5226 [RFC5226] are used: +--------------+-------------------------------+ | Range | Policy | +--------------+-------------------------------+ | 0 | Invalid value | | | | | [1 .. 12] | Defined by this specification | | | | @@ -723,20 +770,25 @@ The specification of a particular "flow component type" must clearly identify what is the criteria used to match packets forwarded by the router. 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 6 unused bits which can be used to convey additional meaning. These values should be assigned via IETF Consensus rules only. + Future assignment are to be made using either the Standards Action + process defined in [RFC2434], the Early IANA Allocation process + defined in [RFC4020], or the "First Come First Served" policy defined + in [RFC2434]. + 11. Acknowledgments The authors would like to thank Yakov Rekhter, Dennis Ferguson and Chris Morrow for their comments. Chaitanya Kodeboyina helped design the flow validation procedure. Steven Lin and Jim Washburn ironed out all the details necessary to produce a working implementation.