draft-ietf-idr-flow-spec-08.txt   draft-ietf-idr-flow-spec-09.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: October 23, 2009 B. Greene Expires: November 27, 2009 B. Greene
Juniper Networks Juniper Networks
J. Mauch J. Mauch
NTT/Verio NTT America
D. McPherson D. McPherson
Arbor Networks Arbor Networks
April 21, 2009 May 26, 2009
Dissemination of flow specification rules Dissemination of flow specification rules
draft-ietf-idr-flow-spec-08 draft-ietf-idr-flow-spec-09
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 October 23, 2009. This Internet-Draft will expire on November 27, 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 4, line 22 skipping to change at page 4, line 22
AS - Autonomous System Number AS - Autonomous System Number
VRF - Virtual Routing and Forwarding instance VRF - Virtual Routing and Forwarding instance
PE - Provider Edge router PE - Provider Edge router
2. Introduction 2. Introduction
Modern IP routers contain both the capability to forward traffic Modern IP routers contain both the capability to forward traffic
according to aggregate IP prefixes as well as to classify, shape, according to IP prefixes as well as to classify, shape, rate limit,
rate limit, filter or redirect packets based on administratively filter or redirect packets based on administratively defined
defined policies. policies.
While forwarding information is, typically, dynamically signaled
across the network via routing protocols, there is no agreed upon
mechanism to dynamically signal flow information across autonomous-
systems.
For several applications, it may be necessary to exchange control These traffic policy mechanisms allow the router to define match
information pertaining to aggregated traffic flow definitions which rules that operate on multiple fields of the packet header. Actions
cannot be expressed using destination address prefixes only. such as the ones described above can be associated with each rule.
An aggregated traffic flow is considered to be an n-tuple consisting The n-tuple consisting of the matching criteria defines an aggregate
of several matching criteria such as source and destination address traffic flow specification. The matching criteria can include
prefixes, IP protocol and transport protocol port numbers. elements such as source and destination address prefixes, IP protocol
and transport protocol port numbers.
The intention of this document is to define a general procedure to This document defines a general procedure to encode flow
encode such flow specification rules as a BGP [RFC4271] NLRI which specification rules for aggregated traffic flows so that they can be
can be reused for several different control applications. distributed as a BGP [RFC4271] NLRI. Additionally, we define the
Additionally, we define the required mechanisms to utilize this required mechanisms to utilize this definition to the problem of
definition to the problem of immediate concern to the authors: intra immediate concern to the authors: intra and inter provider
and inter provider distribution of traffic filtering rules to filter distribution of traffic filtering rules to filter (Distributed)
(Distributed) Denial of Service (DoS) attacks. Denial of Service (DoS) attacks.
By expanding routing information with flow specifications, the By expanding routing information with flow specifications, the
routing system can take advantage of the ACL/firewall capabilities in routing system can take advantage of the ACL/firewall capabilities in
the router's forwarding path. Flow specifications can be seen as the router's forwarding path. Flow specifications can be seen as
more specific routing entries to an unicast prefix and are expected more specific routing entries to an unicast prefix and are expected
to depend upon the existing unicast data information. to depend upon the existing unicast data information.
A flow specification received from a 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 which may result in different safely install more specific flow rules which 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 multi-point distribution of control plane 1. Efficient point to multi-point distribution of control plane
skipping to change at page 5, line 47 skipping to change at page 5, line 43
It is also expected that in many initial deployments flow It is also expected that in many initial deployments flow
specification information will replace existing host length route specification information will replace existing host length route
advertisements rather than add additional information. advertisements rather than add additional information.
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. Taking into account Internet unicast
routing as well as additional applications as they gain popularity. routing as well as additional applications 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, the authors believe that this solution offers the mechanisms, the authors believe that this solution offers the
substantial advantage of being an incremental addition to already substantial advantage of being an incremental addition to already
deployed mechanisms. deployed mechanisms.
In current deployments, the information distributed by the flow-spec In current deployments, the information distributed by the flow-spec
extension is originated both manually as well as automatically. The extension is originated both manually as well as automatically. The
latter by systems which are able to detect malicious flows. When latter by systems which are able to detect malicious flows. When
automated systems are used care should be taken to ensure their automated systems are used care should be taken to ensure their
correctness as well as to limit the advertisement rate of flow correctness as well as to limit the number and advertisement rate of
routes. flow routes.
This specification defines required protocol extensions to address This specification defines required protocol extensions to address
most common applications of IPv4 unicast and VPNv4 unicast filtering. most common applications of IPv4 unicast and VPNv4 unicast filtering.
The same mechanism can be reused and new match criteria added to The same mechanism can be reused and new match criteria added to
address similar filtering needs for other BGP address families (for address similar filtering needs for other BGP address families (for
example IPv6 unicast). Authors believe that those would be best to example IPv6 unicast). Authors believe that those would be best to
be addressed in a separate document. be addressed in a separate document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
skipping to change at page 10, line 18 skipping to change at page 10, line 14
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 can be encoded as a one or two byte bitmask. Bitmask values can be encoded as a one or two byte bitmask.
When a single byte is specified it matches byte 13 of the TCP When a single byte is specified it matches byte 13 of the TCP
header [RFC0793] which contains (bits 8 though 15 of the 4th header [RFC0793] which contains bits 8 though 15 of the 4th
32bit word). When a 2 byte encoding is used it matches bytes 32bit word. When a 2 byte encoding is used it matches bytes 12
12 and 13 of the TCP header with the data offset field having a and 13 of the TCP header with the data offset field having a
"don't care" value. "don't care" value.
As with port specifiers, this component evaluates to FALSE for As with port specifiers, this component evaluates to FALSE for
packets that are not TCP packets. 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.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
skipping to change at page 13, line 46 skipping to change at page 13, line 46
There are several drawbacks, however. An issue that is immediately There are several drawbacks, however. An issue that is immediately
apparent is the granularity of filtering control: only destination apparent is the granularity of filtering control: only destination
prefixes may be specified. Another area of concern is the fact that prefixes may be specified. Another area of concern is the fact that
filtering information is intermingled with routing information. filtering information is intermingled with routing information.
The mechanism defined in this document is designed to address these The mechanism defined in this document is designed to address these
limitations. We use the flow specification NLRI defined above to limitations. We use the flow specification NLRI defined above to
convey information about traffic filtering rules for traffic that convey information about traffic filtering rules for traffic that
should be discarded. should be discarded.
This mechanism is designed to, primarily, allow an upstream This mechanism is primarily designed to allow an upstream autonomous
autonomous system to perform inbound filtering, in their ingress system to perform inbound filtering, in their ingress routers of
routers of traffic that a given downstream AS wishes to drop. traffic that a given downstream AS wishes to drop.
In order to achieve that goal, we define an application specific NLRI In order to achieve this goal, we define an application specific NLRI
identifier (AFI=1, SAFI=133) along with specific semantic rules. identifier (AFI=1, SAFI=133) along with specific semantic rules.
BGP routing updates containing this identifier use the flow BGP routing updates containing this identifier use the flow
specification NLRI encoding to convey particular aggregated flows specification NLRI encoding to convey particular aggregated flows
that require special treatment. that require special treatment.
Flow routing information received via this (afi, safi) pair is Flow routing information received via this (afi, safi) pair is
subject to the validation procedure detailed below. subject to the validation procedure detailed below.
5.1. Order of traffic filtering rules 5.1. Order of traffic filtering rules
skipping to change at page 14, line 36 skipping to change at page 14, line 36
(and thus will match before) the rule that doesn't contain that (and thus will match before) the rule that doesn't contain that
component type. If the component types are the same, then a type component type. If the component types are the same, then a type
specific comparison is performed. specific comparison is performed.
For IP prefix values (IP destination and source prefix) precedence is For IP prefix values (IP destination and source prefix) precedence is
given to lowest IP value of the common prefix length; if the common given to lowest IP value of the common prefix length; if the common
prefix is equal then the most specific prefix has precedence. prefix is equal then the most specific prefix has precedence.
For all other component types, unless otherwise specified, the For all other component types, unless otherwise specified, the
comparison is performed by comparing the component data as a binary comparison is performed by comparing the component data as a binary
string using the the memcmp() function as defined by the ISO C string using the memcmp() function as defined by the ISO C standard.
standard. For strings of different lengths, the common prefix is For strings of different lengths, the common prefix is compared. If
compared. If equal the longest string is considered to have higher equal the longest string is considered to have higher precedence than
precedence than the shorter one. the shorter one.
Pseudocode: Pseudocode:
flow_rule_cmp (a, b) flow_rule_cmp (a, b)
{ {
comp1 = next_component(a); comp1 = next_component(a);
comp2 = next_component(b); comp2 = next_component(b);
while (comp1 || comp2) { while (comp1 || comp2) {
// component_type returns infinity on end-of-list // component_type returns infinity on end-of-list
if (component_type(comp1) < compnent_type(comp2)) { if (component_type(comp1) < compnent_type(comp2)) {
skipping to change at page 23, line 40 skipping to change at page 23, line 40
Barry Greene Barry Greene
Juniper Networks Juniper Networks
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
US US
Email: bgreene@juniper.net Email: bgreene@juniper.net
Jared Mauch Jared Mauch
NTT/Verio NTT America
8285 Reese Lane 101 Park Ave
Ann Arbor, MI 48103-9753 41st Floor
New York, NY 10178
US US
Email: jared@puck.nether.net Email: jared@us.ntt.net
Danny McPherson Danny McPherson
Arbor Networks Arbor Networks
Email: danny@arbor.net Email: danny@arbor.net
 End of changes. 18 change blocks. 
45 lines changed or deleted 42 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/