draft-ietf-idr-flow-spec-05.txt   draft-ietf-idr-flow-spec-06.txt 
IDR Working Group P. Marques IDR Working Group P. Marques
Internet-Draft N. Sheth Internet-Draft N. Sheth
Intended status: Standards Track R. Raszuk Intended status: Standards Track R. Raszuk
Expires: August 2, 2009 B. Greene Expires: September 28, 2009 B. Greene
Juniper Networks Juniper Networks
J. Mauch J. Mauch
NTT/Verio NTT/Verio
D. McPherson D. McPherson
Arbor Networks Arbor Networks
January 29, 2009 March 27, 2009
Dissemination of flow specification rules Dissemination of flow specification rules
draft-ietf-idr-flow-spec-05 draft-ietf-idr-flow-spec-06
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 2, 2009. This Internet-Draft will expire on September 28, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
to this document.
Abstract Abstract
This document defines a new BGP NLRI encoding format that can be used This document defines a new 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.
Additionally it defines two applications of that encoding format. Additionally it defines two applications of that encoding format.
One that can be used to automate inter-domain coordination of traffic One that can be used to automate inter-domain coordination of traffic
skipping to change at page 3, line 13 skipping to change at page 3, line 13
administrative processes such as inter-provider peering agreements. administrative processes such as inter-provider peering agreements.
Table of Contents Table of Contents
1. Definitions of Terms Used in this Memo . . . . . . . . . . . . 4 1. Definitions of Terms Used in this Memo . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Flow specifications . . . . . . . . . . . . . . . . . . . . . 6 3. Flow specifications . . . . . . . . . . . . . . . . . . . . . 6
4. Dissemination of Information . . . . . . . . . . . . . . . . . 6 4. Dissemination of Information . . . . . . . . . . . . . . . . . 6
5. Traffic filtering . . . . . . . . . . . . . . . . . . . . . . 12 5. Traffic filtering . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Order of traffic filtering rules . . . . . . . . . . . . . 13 5.1. Order of traffic filtering rules . . . . . . . . . . . . . 13
6. Validation procedure . . . . . . . . . . . . . . . . . . . . . 13 6. Validation procedure . . . . . . . . . . . . . . . . . . . . . 14
7. Traffic Filtering Actions . . . . . . . . . . . . . . . . . . 14 7. Traffic Filtering Actions . . . . . . . . . . . . . . . . . . 15
8. Traffic filtering in RFC2547bis networks . . . . . . . . . . . 16 8. Traffic filtering in RFC2547bis networks . . . . . . . . . . . 17
9. Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10. Security considerations . . . . . . . . . . . . . . . . . . . 17 10. Security considerations . . . . . . . . . . . . . . . . . . . 18
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
13. Normative References . . . . . . . . . . . . . . . . . . . . . 20 13. Normative References . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Definitions of Terms Used in this Memo 1. Definitions of Terms Used in this Memo
NLRI - Network Layer Reachability Information NLRI - Network Layer Reachability Information
RIB - Routing Information Base RIB - Routing Information Base
Loc-RIB - Local RIB Loc-RIB - Local RIB
AS - Autonomous System Number AS - Autonomous System Number
skipping to change at page 8, line 5 skipping to change at page 8, line 5
Type 3 - IP Protocol Type 3 - IP Protocol
Encoding: <type (1 octet), [op, value]+> Encoding: <type (1 octet), [op, value]+>
Contains a set of {operator, value} pairs that are used to Contains a set of {operator, value} pairs that are used to
match IP protocol value byte in IP packets. match IP protocol value byte in IP packets.
The operator byte is encoded as: The operator byte is encoded as:
7 6 5 4 3 2 1 0 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| e | a | len | 0 |lt |gt |eq | | e | a | len | 0 |lt |gt |eq |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
Numeric operator Numeric operator
* End of List bit. Set in the last {op, value} pair in the list. * End of List bit. Set in the last {op, value} pair in the list.
* And bit. If unset the previous term is logically ORed with the * And bit. If unset the previous term is logically ORed with the
current one. If set the operation is a logical AND. It should current one. If set the operation is a logical AND. It should
skipping to change at page 8, line 41 skipping to change at page 8, line 41
Type 4 - Port Type 4 - Port
Encoding: <type (1 octet), [op, value]+> Encoding: <type (1 octet), [op, value]+>
Defines a list of {operation, value} pairs that matches source Defines a list of {operation, value} pairs that matches source
OR destination TCP/UDP ports. This list is encoded using the OR destination TCP/UDP ports. This list is encoded using the
numeric operand format defined above. Values are encoded as 1 numeric operand format defined above. Values are encoded as 1
or 2 byte quantities. or 2 byte quantities.
Port, source port and destination port components evaluate to
FALSE if the IP protocol field of the packet has a value other
than TCP or UDP, if the packet is framented and this is not the
first fragment or if the system in unable to locate the
transport header. Different implementations may or may not be
able to decode the transport header in the presence of IP
options or ESP NULL [RFC4303] encryption.
Type 5 - Destination port Type 5 - Destination port
Encoding: <type (1 octet), [op, value]+> Encoding: <type (1 octet), [op, value]+>
Defines a list of {operation, value} pairs used to match the Defines a list of {operation, value} pairs used to match the
destination port of a TCP or UDP packet. Values are encoded as destination port of a TCP or UDP packet. Values are encoded as
1 or 2 byte quantities. 1 or 2 byte quantities.
Type 6 - Source port Type 6 - Source port
Encoding: <type (1 octet), [op, value]+> Encoding: <type (1 octet), [op, value]+>
Defines a list of {operation, value} pairs used to match the Defines a list of {operation, value} pairs used to match the
source port of a TCP or UDP packet. Values are encoded as 1 or source port of a TCP or UDP packet. Values are encoded as 1 or
2 byte quantities. 2 byte quantities.
Type 7 - ICMP type Type 7 - ICMP type
Encoding: <type (1 octet), [op, value]+> Encoding: <type (1 octet), [op, value]+>
Defines a list of {operation, value} pairs used to match the Defines a list of {operation, value} pairs used to match the
type field of an icmp packet. Values are encoded using a type field of an icmp packet. Values are encoded using a
skipping to change at page 9, line 16 skipping to change at page 9, line 24
2 byte quantities. 2 byte quantities.
Type 7 - ICMP type Type 7 - ICMP type
Encoding: <type (1 octet), [op, value]+> Encoding: <type (1 octet), [op, value]+>
Defines a list of {operation, value} pairs used to match the Defines a list of {operation, value} pairs used to match the
type field of an icmp packet. Values are encoded using a type field of an icmp packet. Values are encoded using a
single byte. single byte.
The ICMP type and code specifiers evaluate to FALSE whenever
the protocol value is not ICMP
Type 8 - ICMP code Type 8 - ICMP code
Encoding: <type (1 octet), [op, value]+> Encoding: <type (1 octet), [op, value]+>
Defines a list of {operation, value} pairs used to match the Defines a list of {operation, value} pairs used to match the
code field of an icmp packet. Values are encoded using a code field of an icmp packet. Values are encoded using a
single byte. single byte.
Type 9 - TCP flags Type 9 - TCP flags
Encoding: <type (1 octet), [op, bitmask]+> Encoding: <type (1 octet), [op, bitmask]+>
Bitmask values are encoded using a single byte, using the bit Bitmask values can be encoded as a one or two byte bitmask.
definitions specified in the TCP header format [RFC0793]. When a single byte is specified it matches byte 13 of the TCP
header [RFC0793] which contains (bits 8 though 15 of the 4th
32bit word). When a 2 byte encoding is used it matches bytes
12 and 13 of the TCP header with the data offset field having a
"don't care" value.
As with port specifiers, this component evaluates to FALSE for
packets that are not TCP packets.
This type uses the bitmask operand format, which differs from This type uses the bitmask operand format, which differs from
the numeric operator format in the lower nibble. the numeric operator format in the lower nibble.
7 6 5 4 3 2 1 0 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| e | a | len | 0 | 0 |not| m | | e | a | len | 0 | 0 |not| m |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
* Top nibble: (End of List bit, And bit and Length field), as * Most significant nibble: (End of List bit, And bit and Length
defined for in the numeric operator format. field), as defined for in the numeric operator format.
* Not bit. If set, logical negation of operation. * Not bit. If set, logical negation of operation.
* Match bit. If set this is a bitwise match operation defined as * Match bit. If set this is a bitwise match operation defined as
"(data & value) == value"; if unset (data & value) evaluates to "(data & value) == value"; if unset (data & value) evaluates to
true if any of the bits in the value mask are set in the data. true if any of the bits in the value mask are set in the data.
Type 10 - Packet length Type 10 - Packet length
Encoding: <type (1 octet), [op, value]+> Encoding: <type (1 octet), [op, value]+>
Match on the total IP packet length (excluding L2 but including Match on the total IP packet length (excluding L2 but including
IP header). Values are encoded using as 1 or 2 byte IP header). Values are encoded using as 1 or 2 byte
quantities. quantities.
Type 11 - DSCP Type 11 - DSCP
Encoding: <type (1 octet), [op, value]+> Encoding: <type (1 octet), [op, value]+>
skipping to change at page 10, line 14 skipping to change at page 10, line 31
Encoding: <type (1 octet), [op, value]+> Encoding: <type (1 octet), [op, value]+>
Match on the total IP packet length (excluding L2 but including Match on the total IP packet length (excluding L2 but including
IP header). Values are encoded using as 1 or 2 byte IP header). Values are encoded using as 1 or 2 byte
quantities. quantities.
Type 11 - DSCP Type 11 - DSCP
Encoding: <type (1 octet), [op, value]+> Encoding: <type (1 octet), [op, value]+>
Defines a list of {operation, value} pairs used to match the IP Defines a list of {operation, value} pairs used to match the
TOS octet. 6-bit DSCP field.
Type 12 - Fragment Type 12 - Fragment
Encoding: <type (1 octet), [op, bitmask]+> Encoding: <type (1 octet), [op, bitmask]+>
Uses bitmask operand format defined above. Uses bitmask operand format defined above.
Bitmask values: 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| Reserved |LF |FF |IsF|DF |
+---+---+---+---+---+---+---+---+
+ Bit 0 - Dont fragment Bitmask values:
+ Bit 1 - Is a fragment + Bit 7 - Dont fragment
+ Bit 2 - First fragment + Bit 6 - Is a fragment
+ Bit 3 - Last fragment + Bit 5 - First fragment
+ Bit 4 - Last fragment
Flow specification components must follow strict type ordering. A Flow specification components must follow strict type ordering. A
given component type may or may not be present in the specification, given component type may or may not be present in the specification,
but if present it MUST precede any component of higher numeric type but if present it MUST precede any component of higher numeric type
value. value.
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 propagation cannot be applied. However for the purposes of BGP route propagation
this prefix should still be transmitted since BGP route distribution this prefix should still be transmitted since BGP route distribution
is independent on NLRI semantics. is independent on NLRI semantics.
Flow specification components are to be interpreted as a bit match at
a given packet offset. When more than one component in a flow
specification tests the same packet offset the behavior is
undetermined.
The <type, value> encoding is chosen in order to account for future The <type, value> encoding is chosen in order to account for future
extensibility. extensibility.
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 13, line 27 skipping to change at page 13, line 45
With traffic filtering rules, more than one rule may match a With traffic filtering rules, more than one rule may match a
particular traffic flow. Thus it is necessary to define the order at particular traffic flow. Thus it is necessary to define the order at
which rules get matched and applied to a particular traffic flow. which rules get matched and applied to a particular traffic flow.
This ordering function must be such that it must not depend on the This ordering function must be such that it must not depend on the
arrival order of the flow specifications rules and must be constant arrival order of the flow specifications rules and must be constant
in the network. in the network.
We choose to order traffic filtering rules such that the order of two We choose to order traffic filtering rules such that the order of two
flow specifications is given by the comparison of NLRI key byte flow specifications is given by the comparison of NLRI key byte
strings as defined by the memcmp() function is the ISO C standard. strings as defined by the memcmp() function is the ISO C standard.
For strings of different lenghts, the common prefix is compared. If
equal the shorter string is considered to preceed the longer one.
Given the way that flow specifications are encoded this results in a Given the way that flow specifications are encoded this results in a
flow with a less-specific destination IP prefix being considered flow with a less-specific destination IP prefix being considered
less-than (and thus match before) a flow specification with a more- less-than (and thus match before) a flow specification with a more-
specific destination IP prefix. specific destination IP prefix.
This matches an application model where the user may want to define a This matches an application model where the user may want to define a
restriction that affects an aggregate of traffic and a subsequent restriction that affects an aggregate of traffic and a subsequent
rule that applies only to a subset of that. rule that applies only to a subset of that.
skipping to change at page 15, line 29 skipping to change at page 15, line 48
The following extended community values can be used to specify The following extended community values can be used to specify
particular actions. particular actions.
+--------+--------------------+--------------------------+ +--------+--------------------+--------------------------+
| type | extended community | encoding | | type | extended community | encoding |
+--------+--------------------+--------------------------+ +--------+--------------------+--------------------------+
| 0x8006 | traffic-rate | 2-byte as#, 4-byte float | | 0x8006 | traffic-rate | 2-byte as#, 4-byte float |
| 0x8007 | traffic-action | bitmask | | 0x8007 | traffic-action | bitmask |
| 0x8008 | redirect | 6-byte Route Target | | 0x8008 | redirect | 6-byte Route Target |
| 0x8009 | traffic-marking | DSCP value |
+--------+--------------------+--------------------------+ +--------+--------------------+--------------------------+
Traffic-rate The traffic-rate extended community is a non-transitive Traffic-rate The traffic-rate extended community is a non-transitive
extended community across the Autonomous system boundary and uses extended community across the Autonomous system boundary and uses
following extended community encoding: following extended community encoding:
The first two octets carry the 2 octet id which can be assigned The first two octets carry the 2 octet id which can be assigned
from a 2 byte AS number. When 4 byte AS number is locally from a 2 byte AS number. When 4 byte AS number is locally
present 2 least significant bytes of such AS number can be present 2 least significant bytes of such AS number can be
used. used. This value is purely informational and should not be
interpreted by the implementation.
The remaining 4 octets carry the rate information in IEEE The remaining 4 octets carry the rate information in IEEE
floating point format, units being bytes per second. A floating point format, units being bytes per second. A
traffic-rate of 0 should result on all traffic for the traffic-rate of 0 should result on all traffic for the
particular flow to be discarded. particular flow to be discarded.
Traffic-action The traffic-action extended community consists of 6 Traffic-action The traffic-action extended community consists of 6
bytes of which only the 2 least significant bits of the 6th byte bytes of which only the 2 least significant bits of the 6th byte
(from left to right) are currently defined. (from left to right) are currently defined.
* Terminal action (bit 0). When this bit is set the traffic 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| reserved | S | T |
+---+---+---+---+---+---+---+---+
* Terminal action (bit 7). When this bit is set the traffic
filtering engine will apply any subsequent filtering rules (as filtering engine will apply any subsequent filtering rules (as
defined by the ordering procedure). If not set the evaluation defined by the ordering procedure). If not set the evaluation
of the traffic filter stops when this rule is applied. of the traffic filter stops when this rule is applied.
* Sample (bit 1). Enables traffic sampling and logging for this * Sample (bit 6). Enables traffic sampling and logging for this
flow specification. flow specification.
Redirect The redirect extended community allows the traffic to be Redirect The redirect extended community allows the traffic to be
redirected to a VRF routing instance that list the specified redirected to a VRF routing instance that list the specified
route-target in its import policy. If several local instances route-target in its import policy. If several local instances
match this criteria, the choice between them is a local matter match this criteria, the choice between them is a local matter
(for example, the instance with the lowest Route Distinguisher (for example, the instance with the lowest Route Distinguisher
value can be elected). The traffic marking extended community value can be elected).
instruct a system to modify the DSCP bits of a transiting IP
packet to the corresponding value. This extended community is Traffic Marking The traffic marking extended community instructs a
encoded as a sequence of 5 zero bytes followed by the DSCP value. system to modify the DSCP bits of a transiting IP packet to the
corresponding value. This extended community is encoded as a
sequence of 5 zero bytes followed by the DSCP value.
8. Traffic filtering in RFC2547bis networks 8. Traffic filtering in RFC2547bis networks
Provider-based layer 3 VPN networks, such as the ones using an BGP/ Provider-based layer 3 VPN networks, such as the ones using an BGP/
MPLS IP VPN [RFC4364] control plane, have different traffic filtering MPLS IP VPN [RFC4364] control plane, have different traffic filtering
requirements than internet service providers. requirements than internet service providers.
In these environments, the VPN customer network often has traffic In these environments, the VPN customer network often has traffic
filtering capabilities towards their external network connections filtering capabilities towards their external network connections
(e.g. firewall facing public network connection). Less common is the (e.g. firewall facing public network connection). Less common is the
skipping to change at page 18, line 27 skipping to change at page 19, line 13
The following traffic filtering flow specification rules are to be The following traffic filtering flow specification rules are to be
allocated by IANA from BGP Extended Communities Type - Experimental allocated by IANA from BGP Extended Communities Type - Experimental
Use registry. Authors recommend the following type values: Use registry. Authors recommend the following type values:
0x8006 - Flow spec traffic-rate 0x8006 - Flow spec traffic-rate
0x8007 - Flow spec traffic-action 0x8007 - Flow spec traffic-action
0x8008 - Flow spec redirect 0x8008 - Flow spec redirect
0x8009 - Flow spec traffic-remarking
Authors would like to ask IANA to create and maintain a new registry Authors would like to ask IANA to create and maintain a new registry
entitled: "Flow Spec Component Type". Authors recommend to allocate entitled: "Flow Spec Component Type". Authors recommend to allocate
the following component types: the following component types:
Type 1 - Destination Prefix Type 1 - Destination Prefix
Type 2 - Source Prefix Type 2 - Source Prefix
Type 3 - IP Protocol Type 3 - IP Protocol
skipping to change at page 20, line 16 skipping to change at page 21, line 8
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, February 2006. Communities Attribute", RFC 4360, February 2006.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006. Networks (VPNs)", RFC 4364, February 2006.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760, "Multiprotocol Extensions for BGP-4", RFC 4760,
January 2007. January 2007.
 End of changes. 34 change blocks. 
42 lines changed or deleted 74 lines changed or added

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