draft-ietf-idr-flow-spec-04.txt   draft-ietf-idr-flow-spec-05.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: July 22, 2009 B. Greene Expires: August 2, 2009 B. Greene
Juniper Networks Juniper Networks
J. Mauch J. Mauch
NTT/Verio NTT/Verio
D. McPherson D. McPherson
Arbor Networks Arbor Networks
January 18, 2009 January 29, 2009
Dissemination of flow specification rules Dissemination of flow specification rules
draft-ietf-idr-flow-spec-04 draft-ietf-idr-flow-spec-05
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 July 22, 2009. This Internet-Draft will expire on August 2, 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
(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 10, line 40 skipping to change at page 10, line 40
+ Bit 3 - Last fragment + Bit 3 - 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 as 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 Flow specification components are to be interpreted as a bit match at
a given packet offset. When more than one component in a flow a given packet offset. When more than one component in a flow
specification tests the same packet offset the behavior is specification tests the same packet offset the behavior is
undetermined. undetermined.
skipping to change at page 13, line 13 skipping to change at page 13, line 13
routers of traffic that a given downstream AS wishes to drop. routers of 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 that 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 bellow. subject to the validation procedure detailed below.
5.1. Order of traffic filtering rules 5.1. Order of traffic filtering rules
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.
skipping to change at page 14, line 30 skipping to change at page 14, line 30
neighboring AS than the best-match unicast route, which has been neighboring AS than the best-match unicast route, which has been
determined in step a). determined in step a).
By originator of a BGP route, we mean either the BGP originator path By originator of a BGP route, we mean either the BGP originator path
attribute, as used by route reflection, or the transport address of attribute, as used by route reflection, or the transport address of
the BGP peer, if this path attribute is not present. the BGP peer, if this path attribute is not present.
The underlying concept is that the neighboring AS that advertises the The underlying concept is that the neighboring AS that advertises the
best unicast route for a destination is allowed to advertise flow- best unicast route for a destination is allowed to advertise flow-
spec information that conveys a more or equally specific destination spec information that conveys a more or equally specific destination
prefix. This, as long as there are no more-specific unicast routes, prefix. Thus, as long as there are no more-specific unicast routes,
received from a different neighbor AS, which would be affected by received from a different neighbor AS, which would be affected by
that filtering rule. that filtering rule.
The neighboring AS is the immediate destination of the traffic The neighboring AS is the immediate destination of the traffic
described by the Flow Specification. If it requests these flows to described by the Flow Specification. If it requests these flows to
be dropped that request can be honored without concern that it be dropped that request can be honored without concern that it
represents a denial of service in itself. Supposedly, the traffic is represents a denial of service in itself. Supposedly, the traffic is
being dropped by the downstream autonomous-system and there is no being dropped by the downstream autonomous-system and there is no
added value in carrying the traffic to it. added value in carrying the traffic to it.
skipping to change at page 15, line 7 skipping to change at page 15, line 7
the BGP specification, it becomes necessary to enforce it for the BGP specification, it becomes necessary to enforce it for
security reasons. security reasons.
7. Traffic Filtering Actions 7. Traffic Filtering Actions
This specification defines a minimum set of filtering actions that it This specification defines a minimum set of filtering actions that it
standardizes as BGP extended community values [RFC4360]. This is not standardizes as BGP extended community values [RFC4360]. This is not
meant to be an inclusive list of all the possible actions but only a meant to be an inclusive list of all the possible actions but only a
subset that can be interpreted consistently across the network. subset that can be interpreted consistently across the network.
Implementations should provide mechanisms that map an arbitrary bgp Implementations should provide mechanisms that map an arbitrary BGP
community value (normal or extended) to filtering actions that community value (normal or extended) to filtering actions that
require different mappings in different systems in the network. For require different mappings in different systems in the network. For
instance, providing packets with a worse than best-effort per-hop instance, providing packets with a worse than best-effort per-hop
behavior is a functionality that is likely to be implemented behavior is a functionality that is likely to be implemented
differently in different systems and for which no standard behavior differently in different systems and for which no standard behavior
is currently known. Rather than attempting to define it here, this is currently known. Rather than attempting to define it here, this
can be accomplished by mapping a user defined community value to can be accomplished by mapping a user defined community value to
platform / network specific behavior via user configuration. platform / network specific behavior via user configuration.
The default action for a traffic filtering flow specification is to The default action for a traffic filtering flow specification is to
skipping to change at page 17, line 47 skipping to change at page 17, line 47
Where it not the case, this would open the door to further denial of Where it not the case, this would open the door to further denial of
service attacks. service attacks.
Enabling firewall like capabilities in routers without centralized Enabling firewall like capabilities in routers without centralized
management could make certain failures harder to diagnose. For management could make certain failures harder to diagnose. For
example, with the extensions it is possible to allow TCP packets to example, with the extensions it is possible to allow TCP packets to
pass between a pair of addresses but not ICMP packets. It would also pass between a pair of addresses but not ICMP packets. It would also
be possible to permit packets smaller than 900 or greater than 1000 be possible to permit packets smaller than 900 or greater than 1000
bytes to pass between a pair of addresses, but not packets whose bytes to pass between a pair of addresses, but not packets whose
length is in the range 900 &mdash 1000. The Internet has become length is in the range 900-1000. The Internet has become
sufficiently aware of firewalls that such behavior is less likely to sufficiently aware of firewalls that such behavior is less likely to
be confusing than it was a few years ago and there are no new be confusing than it was a few years ago and there are no new
capabilities introduced by these extensions, just an increased capabilities introduced by these extensions, just an increased
likelihood that such capabilities will be used. likelihood that such capabilities will be used.
11. IANA Considerations 11. IANA Considerations
A flow specification consists of a sequence of flow components, which A flow specification consists of a sequence of flow components, which
are identified by a an 8-bit component type. Types must be assigned are identified by a an 8-bit component type. Types must be assigned
and interpreted uniquely. The current specification defines types 1 and interpreted uniquely. The current specification defines types 1
skipping to change at page 19, line 30 skipping to change at page 19, line 30
The specification of a particular "flow component type" must clearly The specification of a particular "flow component type" must clearly
identify what is the criteria used to match packets forwarded by the identify what is the criteria used to match packets forwarded by the
router. This criteria should be meaningful across router hops and 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 not depend on values that change hop-by-hop such as ttl or layer-2
encapsulation. encapsulation.
The "Traffic-action" extended community defined in this document has The "Traffic-action" extended community defined in this document has
6 unused bits which can be used to convey additional meaning. 6 unused bits which can be used to convey additional meaning.
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: "Traffic Action Fields". These values should be assigned entitled: "Traffic Action Fields". These values should be assigned
via IETF Consensus rules only. Authors recommend to allocate the via IETF Review rules only. Authors recommend to allocate the
following traffic action fields: following traffic action fields:
0 Terminal Action 0 Terminal Action
1 Sample 1 Sample
2-47 Unassigned 2-47 Unassigned
12. Acknowledgments 12. Acknowledgments
The authors would like to thank Yakov Rekhter, Dennis Ferguson, Chris The authors would like to thank Yakov Rekhter, Dennis Ferguson, Chris
Morrow and Charlie Kaufman for their comments. Morrow, Charlie Kaufman and David Smith for their comments.
Chaitanya Kodeboyina helped design the flow validation procedure. Chaitanya Kodeboyina helped design the flow validation procedure.
Steven Lin and Jim Washburn ironed out all the details necessary to Steven Lin and Jim Washburn ironed out all the details necessary to
produce a working implementation. produce a working implementation.
13. Normative References 13. Normative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
 End of changes. 11 change blocks. 
11 lines changed or deleted 11 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/