idnits 2.17.1 draft-ietf-idr-flow-spec-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 27, 2009) is 5508 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '137' on line 452 -- Looks like a reference, but probably isn't: '139' on line 452 ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Working Group P. Marques 3 Internet-Draft N. Sheth 4 Intended status: Standards Track R. Raszuk 5 Expires: September 28, 2009 B. Greene 6 Juniper Networks 7 J. Mauch 8 NTT/Verio 9 D. McPherson 10 Arbor Networks 11 March 27, 2009 13 Dissemination of flow specification rules 14 draft-ietf-idr-flow-spec-06 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on September 28, 2009. 39 Copyright Notice 41 Copyright (c) 2009 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents in effect on the date of 46 publication of this document (http://trustee.ietf.org/license-info). 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. 50 Abstract 52 This document defines a new BGP NLRI encoding format that can be used 53 to distribute traffic flow specifications. This allows the routing 54 system to propagate information regarding more-specific components of 55 the traffic aggregate defined by an IP destination prefix. 57 Additionally it defines two applications of that encoding format. 58 One that can be used to automate inter-domain coordination of traffic 59 filtering, such as what is required in order to mitigate 60 (distributed) denial of service attacks. And a second application to 61 traffic filtering in the context of a BGP/MPLS VPN service. 63 The information is carried via the Border Gateway Protocol (BGP), 64 thereby reusing protocol algorithms, operational experience and 65 administrative processes such as inter-provider peering agreements. 67 Table of Contents 69 1. Definitions of Terms Used in this Memo . . . . . . . . . . . . 4 70 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3. Flow specifications . . . . . . . . . . . . . . . . . . . . . 6 72 4. Dissemination of Information . . . . . . . . . . . . . . . . . 6 73 5. Traffic filtering . . . . . . . . . . . . . . . . . . . . . . 12 74 5.1. Order of traffic filtering rules . . . . . . . . . . . . . 13 75 6. Validation procedure . . . . . . . . . . . . . . . . . . . . . 14 76 7. Traffic Filtering Actions . . . . . . . . . . . . . . . . . . 15 77 8. Traffic filtering in RFC2547bis networks . . . . . . . . . . . 17 78 9. Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . 17 79 10. Security considerations . . . . . . . . . . . . . . . . . . . 18 80 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 81 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 82 13. Normative References . . . . . . . . . . . . . . . . . . . . . 20 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 85 1. Definitions of Terms Used in this Memo 87 NLRI - Network Layer Reachability Information 89 RIB - Routing Information Base 91 Loc-RIB - Local RIB 93 AS - Autonomous System Number 95 VRF - Virtual Routing and Forwarding instance 97 PE - Provider Edge router 99 2. Introduction 101 Modern IP routers contain both the capability to forward traffic 102 according to aggregate IP prefixes as well as to classify, shape, 103 limit filter or redirect packets based on administratively defined 104 policies. 106 While forwarding information is, typically, dynamically signaled 107 across the network via routing protocols, there is no agreed upon 108 mechanism to dynamically signal flows across autonomous-systems. 110 For several applications, it may be necessary to exchange control 111 information pertaining to aggregated traffic flow definitions which 112 cannot be expressed using destination address prefixes only. 114 An aggregated traffic flow is considered to be an n-tuple consisting 115 of several matching criteria such as source and destination address 116 prefixes, IP protocol and transport protocol port numbers. 118 The intention of this document is to define a general procedure to 119 encode such flow specification rules as a BGP [RFC4271] NLRI which 120 can be reused for several different control applications. 121 Additionally, we define the required mechanisms to utilize this 122 definition to the problem of immediate concern to the authors: intra 123 and inter provider distribution of traffic filtering rules to filter 124 (Distributed) Denial of Service (DoS) attacks. 126 By expanding routing information with flow specifications, the 127 routing system can take advantage of the ACL/firewall capabilities in 128 the router's forwarding path. Flow specifications can be seen as 129 more specific routing entries to an unicast prefix and are expected 130 to depend upon the existing unicast data information. 132 A flow specification received from a external autonomous-system will 133 need to be validated against unicast routing before being accepted. 134 If the aggregate traffic flow defined by the unicast destination 135 prefix is forwarded to a given BGP peer, then the local system can 136 safely install more specific flow rules which result in different 137 forwarding behavior, as requested by this system. 139 The choice of BGP as the carrier of this control information is also 140 justifiable by the fact that the key issues in terms of complexity 141 are problems which are common to unicast route distribution and have 142 already been solved in the current environment. 144 From an algorithmic perspective, the main problem that presents 145 itself is the loop-free distribution of pairs from 146 one originator to N ingresses. The key, in this particular instance, 147 being a flow specification. 149 From an operational perspective, the utilization of BGP as the 150 carrier for this information, allows a network service provider to 151 reuse both internal route distribution infrastructure (e.g.: route 152 reflector or confederation design) and existing external 153 relationships (e.g.: inter-domain BGP sessions to a customer 154 network). 156 While it is certainly possible to address this problem using other 157 mechanisms, the authors believe that this solution offers the 158 substantial advantage of being an incremental addition to deployed 159 mechanisms. 161 At the current deployments the information distributed by the flow- 162 spec extension is originated both manually as well as automatically 163 by systems which are able to detect malicious flows. When automated 164 systems are used care should be taken to their correctness and rate 165 of advertisement of flow routes. 167 This specification defines required protocol extensions to address 168 most common applications of IPv4 unicast and VPNv4 unicast filtering. 169 The same mechanism can be reused and new match criteria added to 170 address similar filtering needs for other BGP address families (for 171 example IPv6 unicast). Authors believe that those would be best to 172 be addressed in a separate document. 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 176 document are to be interpreted as described in RFC 2119 [RFC2119]. 178 3. Flow specifications 180 A flow specification is an n-tuple consisting on several matching 181 criteria that can be applied to IP traffic. A given IP packet is 182 said to match the defined flow if it matches all the specified 183 criteria. 185 A given flow may be associated with a set of attributes, depending on 186 the particular application, such attributes may or may not include 187 reachability information (i.e. NEXT_HOP). Well-known or AS-specific 188 community attributes can be used to encode a set of predetermined 189 actions. 191 A particular application is identified by a specific (AFI, SAFI) pair 192 [RFC4760] and corresponds to a distinct set of RIBs. Those RIBs 193 should be treated independently from each other in order to assure 194 non-interference between distinct applications. 196 BGP itself treats the NLRI as an opaque key to an entry in its 197 databases. Entries that are placed in the Loc-RIB are then 198 associated with a given set of semantics which is application 199 dependent. This is consistent with existing BGP applications. For 200 instance IP unicast routing (AFI=1, SAFI=1) and IP multicast reverse- 201 path information (AFI=1, SAFI=2) are handled by BGP without any 202 particular semantics being associated with them until installed in 203 the Loc-RIB. 205 Standard BGP policy mechanisms, such as UPDATE filtering by NLRI 206 prefix and community matching, SHOULD apply to the newly defined 207 NLRI-type. Network operators can also control propagation of such 208 routing updates by enabling or disabling the exchange of a particular 209 (AFI, SAFI) pair on a given BGP peering session. 211 4. Dissemination of Information 213 We define a "Flow Specification" NLRI type that may include several 214 components such as destination prefix, source prefix, protocol, 215 ports, etc. This NLRI is treated as an opaque bit string prefix by 216 BGP. Each bit string identifies a key to a database entry which a 217 set of attributes can be associated with. 219 This NLRI information is encoded using MP_REACH_NLRI and 220 MP_UNREACH_NLRI attributes as defined in RFC4760 [RFC4760]. Whenever 221 the corresponding application does not require Next Hop information, 222 this shall be encoded as a 0 octet length Next Hop in the 223 MP_REACH_NLRI attribute and ignored on receipt. 225 The NLRI field of the MP_REACH_NLRI and MP_UNREACH_NLRI is encoded as 226 a 1 or 2 octet NLRI length field followed by a variable length NLRI 227 value. The NLRI length is expressed in octets. 229 +------------------------------+ 230 | length (0xnn or 0xfn nn) | 231 +------------------------------+ 232 | NLRI value (variable) | 233 +------------------------------+ 235 flow-spec NLRI 237 If the NLRI length value is smaller than 240 (0xf0 hex), the length 238 field can be encoded as a single octet. Otherwise, it is encoded as 239 a extended length 2 octet value in which the most significant nibble 240 of the first byte is all ones. 242 The Flow Specification NLRI-type consists of several optional 243 subcomponents. A specific packet is considered to match the flow 244 specification when it matches the intersection (AND) of all the 245 components present in the specification. 247 The following component types are defined: 249 Type 1 - Destination Prefix 251 Encoding: 253 Defines the destination prefix to match. Prefixes are encoded 254 as in BGP UPDATE messages, a length in bits is followed by 255 enough octets to contain the prefix information. 257 Type 2 - Source Prefix 259 Encoding: 261 Defines the source prefix to match. 263 Type 3 - IP Protocol 265 Encoding: 267 Contains a set of {operator, value} pairs that are used to 268 match IP protocol value byte in IP packets. 270 The operator byte is encoded as: 272 0 1 2 3 4 5 6 7 273 +---+---+---+---+---+---+---+---+ 274 | e | a | len | 0 |lt |gt |eq | 275 +---+---+---+---+---+---+---+---+ 277 Numeric operator 279 * End of List bit. Set in the last {op, value} pair in the list. 281 * And bit. If unset the previous term is logically ORed with the 282 current one. If set the operation is a logical AND. It should 283 be unset in the first operator byte of a sequence. The AND 284 operator has higher priority than OR for the purposes of 285 evaluating logical expressions. 287 * The length of value field for this operand is given as (1 << 288 len). 290 * Lt - less than comparison between data and value. 292 * gt - greater than comparison between data and value. 294 * eq - equality between data and value. 296 * The bits lt, gt, and eq can be combined to produce "less or 297 equal", "greater or equal" and inequality values. 299 Type 4 - Port 301 Encoding: 303 Defines a list of {operation, value} pairs that matches source 304 OR destination TCP/UDP ports. This list is encoded using the 305 numeric operand format defined above. Values are encoded as 1 306 or 2 byte quantities. 308 Port, source port and destination port components evaluate to 309 FALSE if the IP protocol field of the packet has a value other 310 than TCP or UDP, if the packet is framented and this is not the 311 first fragment or if the system in unable to locate the 312 transport header. Different implementations may or may not be 313 able to decode the transport header in the presence of IP 314 options or ESP NULL [RFC4303] encryption. 316 Type 5 - Destination port 318 Encoding: 319 Defines a list of {operation, value} pairs used to match the 320 destination port of a TCP or UDP packet. Values are encoded as 321 1 or 2 byte quantities. 323 Type 6 - Source port 325 Encoding: 327 Defines a list of {operation, value} pairs used to match the 328 source port of a TCP or UDP packet. Values are encoded as 1 or 329 2 byte quantities. 331 Type 7 - ICMP type 333 Encoding: 335 Defines a list of {operation, value} pairs used to match the 336 type field of an icmp packet. Values are encoded using a 337 single byte. 339 The ICMP type and code specifiers evaluate to FALSE whenever 340 the protocol value is not ICMP 342 Type 8 - ICMP code 344 Encoding: 346 Defines a list of {operation, value} pairs used to match the 347 code field of an icmp packet. Values are encoded using a 348 single byte. 350 Type 9 - TCP flags 352 Encoding: 354 Bitmask values can be encoded as a one or two byte bitmask. 355 When a single byte is specified it matches byte 13 of the TCP 356 header [RFC0793] which contains (bits 8 though 15 of the 4th 357 32bit word). When a 2 byte encoding is used it matches bytes 358 12 and 13 of the TCP header with the data offset field having a 359 "don't care" value. 361 As with port specifiers, this component evaluates to FALSE for 362 packets that are not TCP packets. 364 This type uses the bitmask operand format, which differs from 365 the numeric operator format in the lower nibble. 367 0 1 2 3 4 5 6 7 368 +---+---+---+---+---+---+---+---+ 369 | e | a | len | 0 | 0 |not| m | 370 +---+---+---+---+---+---+---+---+ 372 * Most significant nibble: (End of List bit, And bit and Length 373 field), as defined for in the numeric operator format. 375 * Not bit. If set, logical negation of operation. 377 * Match bit. If set this is a bitwise match operation defined as 378 "(data & value) == value"; if unset (data & value) evaluates to 379 true if any of the bits in the value mask are set in the data. 381 Type 10 - Packet length 383 Encoding: 385 Match on the total IP packet length (excluding L2 but including 386 IP header). Values are encoded using as 1 or 2 byte 387 quantities. 389 Type 11 - DSCP 391 Encoding: 393 Defines a list of {operation, value} pairs used to match the 394 6-bit DSCP field. 396 Type 12 - Fragment 398 Encoding: 400 Uses bitmask operand format defined above. 402 0 1 2 3 4 5 6 7 403 +---+---+---+---+---+---+---+---+ 404 | Reserved |LF |FF |IsF|DF | 405 +---+---+---+---+---+---+---+---+ 407 Bitmask values: 409 + Bit 7 - Dont fragment 411 + Bit 6 - Is a fragment 413 + Bit 5 - First fragment 414 + Bit 4 - Last fragment 416 Flow specification components must follow strict type ordering. A 417 given component type may or may not be present in the specification, 418 but if present it MUST precede any component of higher numeric type 419 value. 421 If a given component type within a prefix in unknown, the prefix in 422 question cannot be used for traffic filtering purposes by the 423 receiver. Since a Flow Specification has the semantics of a logical 424 AND of all components, if a component is FALSE by definition it 425 cannot be applied. However for the purposes of BGP route propagation 426 this prefix should still be transmitted since BGP route distribution 427 is independent on NLRI semantics. 429 The encoding is chosen in order to account for future 430 extensibility. 432 An example of a Flow Specification encoding for: "all packets to 433 10.0.1/24 and TCP port 25". 435 +------------------+----------+----------+ 436 | destination | proto | port | 437 +------------------+----------+----------+ 438 | 0x01 18 0a 00 01 | 03 81 06 | 04 81 19 | 439 +------------------+----------+----------+ 441 Decode for protocol: 443 +-------+----------+------------------------------+ 444 | Value | | | 445 +-------+----------+------------------------------+ 446 | 0x03 | type | | 447 | 0x81 | operator | end-of-list, value size=1, = | 448 | 0x06 | value | | 449 +-------+----------+------------------------------+ 451 An example of a Flow Specification encoding for: "all packets to 452 10.0.1/24 from 192/8 and port {range [137, 139] or 8080}". 454 +------------------+----------+-------------------------+ 455 | destination | source | port | 456 +------------------+----------+-------------------------+ 457 | 0x01 18 0a 01 01 | 02 08 c0 | 04 03 89 45 8b 91 1f 90 | 458 +------------------+----------+-------------------------+ 459 Decode for port: 461 +--------+----------+------------------------------+ 462 | Value | | | 463 +--------+----------+------------------------------+ 464 | 0x04 | type | | 465 | 0x03 | operator | size=1, >= | 466 | 0x89 | value | 137 | 467 | 0x45 | operator | &, value size=1, <= | 468 | 0x8b | value | 139 | 469 | 0x91 | operator | end-of-list, value-size=2, = | 470 | 0x1f90 | value | 8080 | 471 +--------+----------+------------------------------+ 473 This constitutes a NLRI with an NLRI length of 16 octets. 475 Implementations wishing to exchange flow specification rules MUST use 476 BGP's Capability Advertisement facility to exchange the Multiprotocol 477 Extension Capability Code (Code 1) as defined in RFC4760 [RFC4760]. 478 The (AFI, SAFI) pair carried in the Multiprotocol Extension 479 capability MUST be the same as the one used to identify a particular 480 application that uses this NLRI-type. 482 5. Traffic filtering 484 Traffic filtering policies have been traditionally considered to be 485 relatively static. 487 The popularity of traffic-based denial of service (DoS) attacks, 488 which often requires the network operator to be able to use traffic 489 filters for detection and mitigation, brings with it requirements 490 that are not fully satisfied by existing tools. 492 Increasingly, DoS mitigation, requires coordination among several 493 Service Providers, in order to be able to identify traffic source(s) 494 and because the volumes of traffic may be such that they will 495 otherwise significantly affect the performance of the network. 497 Several techniques are currently used to control traffic filtering of 498 DoS attacks. Among those, one of the most common is to inject 499 unicast route advertisements corresponding to a destination prefix 500 being attacked. One variant of this technique marks such route 501 advertisements with a community that gets translated into a discard 502 next-hop by the receiving router. Other variants, attract traffic to 503 a particular node that serves as a deterministic drop point. 505 Using unicast routing advertisements to distribute traffic filtering 506 information has the advantage of using the existing infrastructure 507 and inter-as communication channels. This can allow, for instance, 508 for a service provider to accept filtering requests from customers 509 for address space they own. 511 There are several drawbacks, however. An issue that is immediately 512 apparent is the granularity of filtering control: only destination 513 prefixes may be specified. Another area of concern is the fact that 514 filtering information is intermingled with routing information. 516 The mechanism defined in this document is designed to address these 517 limitations. We use the flow specification NLRI defined above to 518 convey information about traffic filtering rules for traffic that 519 should be discarded. 521 This mechanism is designed to, primarily, allow an upstream 522 autonomous system to perform inbound filtering, in their ingress 523 routers of traffic that a given downstream AS wishes to drop. 525 In order to achieve that goal, we define an application specific NLRI 526 identifier (AFI=1, SAFI=133) along with specific semantic rules. 528 BGP routing updates containing this identifier use the flow 529 specification NLRI encoding to convey particular aggregated flows 530 that require special treatment. 532 Flow routing information received via this (afi, safi) pair is 533 subject to the validation procedure detailed below. 535 5.1. Order of traffic filtering rules 537 With traffic filtering rules, more than one rule may match a 538 particular traffic flow. Thus it is necessary to define the order at 539 which rules get matched and applied to a particular traffic flow. 540 This ordering function must be such that it must not depend on the 541 arrival order of the flow specifications rules and must be constant 542 in the network. 544 We choose to order traffic filtering rules such that the order of two 545 flow specifications is given by the comparison of NLRI key byte 546 strings as defined by the memcmp() function is the ISO C standard. 547 For strings of different lenghts, the common prefix is compared. If 548 equal the shorter string is considered to preceed the longer one. 550 Given the way that flow specifications are encoded this results in a 551 flow with a less-specific destination IP prefix being considered 552 less-than (and thus match before) a flow specification with a more- 553 specific destination IP prefix. 555 This matches an application model where the user may want to define a 556 restriction that affects an aggregate of traffic and a subsequent 557 rule that applies only to a subset of that. 559 A flow-specification without a destination IP prefix is considered to 560 match after all flow-specifications that contain an IP destination 561 prefix. 563 6. Validation procedure 565 Flow specifications received from a BGP peer and which are accepted 566 in the respective Adj-RIB-In are used as input to the route selection 567 process. Although the forwarding attributes of two routes for the 568 same Flow Specification prefix may be the same, BGP is still required 569 to perform its path selection algorithm in order to select the 570 correct set of attributes to advertise. 572 The first step of the BGP Route Selection procedure (section 9.1.2 of 573 [RFC4271]) is to exclude from the selection procedure routes that are 574 considered non-feasible. In the context of IP routing information 575 this step is used to validate that the NEXT_HOP attribute of a given 576 route is resolvable. 578 The concept can be extended, in the case of Flow Specification NLRI, 579 to allow other validation procedures. 581 A flow specification NLRI must be validated such that it is 582 considered feasible if and only if: 584 a) The originator of the flow specification matches the originator of 585 the best-match unicast route for the destination prefix embedded 586 in the flow specification. 588 b) There are no more-specific unicast routes, when compared with the 589 flow destination prefix, that have been received from a different 590 neighboring AS than the best-match unicast route, which has been 591 determined in step a). 593 By originator of a BGP route, we mean either the BGP originator path 594 attribute, as used by route reflection, or the transport address of 595 the BGP peer, if this path attribute is not present. 597 The underlying concept is that the neighboring AS that advertises the 598 best unicast route for a destination is allowed to advertise flow- 599 spec information that conveys a more or equally specific destination 600 prefix. Thus, as long as there are no more-specific unicast routes, 601 received from a different neighbor AS, which would be affected by 602 that filtering rule. 604 The neighboring AS is the immediate destination of the traffic 605 described by the Flow Specification. If it requests these flows to 606 be dropped that request can be honored without concern that it 607 represents a denial of service in itself. Supposedly, the traffic is 608 being dropped by the downstream autonomous-system and there is no 609 added value in carrying the traffic to it. 611 BGP implementations MUST also enforce that the AS_PATH attribute of a 612 route received via eBGP contains the neighboring AS in the left-most 613 position of the AS_PATH attribute. While this rule is optional in 614 the BGP specification, it becomes necessary to enforce it for 615 security reasons. 617 7. Traffic Filtering Actions 619 This specification defines a minimum set of filtering actions that it 620 standardizes as BGP extended community values [RFC4360]. This is not 621 meant to be an inclusive list of all the possible actions but only a 622 subset that can be interpreted consistently across the network. 624 Implementations should provide mechanisms that map an arbitrary BGP 625 community value (normal or extended) to filtering actions that 626 require different mappings in different systems in the network. For 627 instance, providing packets with a worse than best-effort per-hop 628 behavior is a functionality that is likely to be implemented 629 differently in different systems and for which no standard behavior 630 is currently known. Rather than attempting to define it here, this 631 can be accomplished by mapping a user defined community value to 632 platform / network specific behavior via user configuration. 634 The default action for a traffic filtering flow specification is to 635 accept IP traffic that matches that particular rule. 637 The following extended community values can be used to specify 638 particular actions. 640 +--------+--------------------+--------------------------+ 641 | type | extended community | encoding | 642 +--------+--------------------+--------------------------+ 643 | 0x8006 | traffic-rate | 2-byte as#, 4-byte float | 644 | 0x8007 | traffic-action | bitmask | 645 | 0x8008 | redirect | 6-byte Route Target | 646 | 0x8009 | traffic-marking | DSCP value | 647 +--------+--------------------+--------------------------+ 649 Traffic-rate The traffic-rate extended community is a non-transitive 650 extended community across the Autonomous system boundary and uses 651 following extended community encoding: 653 The first two octets carry the 2 octet id which can be assigned 654 from a 2 byte AS number. When 4 byte AS number is locally 655 present 2 least significant bytes of such AS number can be 656 used. This value is purely informational and should not be 657 interpreted by the implementation. 659 The remaining 4 octets carry the rate information in IEEE 660 floating point format , units being bytes per second. A 661 traffic-rate of 0 should result on all traffic for the 662 particular flow to be discarded. 664 Traffic-action The traffic-action extended community consists of 6 665 bytes of which only the 2 least significant bits of the 6th byte 666 (from left to right) are currently defined. 668 0 1 2 3 4 5 6 7 669 +---+---+---+---+---+---+---+---+ 670 | reserved | S | T | 671 +---+---+---+---+---+---+---+---+ 673 * Terminal action (bit 7). When this bit is set the traffic 674 filtering engine will apply any subsequent filtering rules (as 675 defined by the ordering procedure). If not set the evaluation 676 of the traffic filter stops when this rule is applied. 678 * Sample (bit 6). Enables traffic sampling and logging for this 679 flow specification. 681 Redirect The redirect extended community allows the traffic to be 682 redirected to a VRF routing instance that list the specified 683 route-target in its import policy. If several local instances 684 match this criteria, the choice between them is a local matter 685 (for example, the instance with the lowest Route Distinguisher 686 value can be elected). 688 Traffic Marking The traffic marking extended community instructs a 689 system to modify the DSCP bits of a transiting IP packet to the 690 corresponding value. This extended community is encoded as a 691 sequence of 5 zero bytes followed by the DSCP value. 693 8. Traffic filtering in RFC2547bis networks 695 Provider-based layer 3 VPN networks, such as the ones using an BGP/ 696 MPLS IP VPN [RFC4364] control plane, have different traffic filtering 697 requirements than internet service providers. 699 In these environments, the VPN customer network often has traffic 700 filtering capabilities towards their external network connections 701 (e.g. firewall facing public network connection). Less common is the 702 presence of traffic filtering capabilities between different VPN 703 attachment sites. In an any-to-any connectivity model, which is the 704 default, this means that site to site traffic is unfiltered. 706 In circumstances where a security threat does get propagated inside 707 the VPN customer network, there may not be readily available 708 mechanisms to provide mitigation via traffic filter. 710 This document proposes an additional BGP NLRI type (afi=1, safi=134) 711 value, which can be used to propagate traffic filtering information 712 in a BGP/MPLS VPN environment. 714 The NLRI format for this address family consists of a fixed length 715 Route Distinguisher field (8 bytes) followed by a flow specification, 716 following the encoded defined in this document. The NLRI length 717 field shall includes the both 8 bytes of the Route Distinguisher as 718 well as the subsequent flow specification. 720 Propagation of this NLRI is controlled by matching Route Target 721 extended communities associated with the BGP path advertisement with 722 the VRF import policy, using the same mechanism as described in "BGP/ 723 MPLS IP VPNs" [RFC4364] . 725 Flow specification rules received via this NLRI apply only to traffic 726 that belongs to the VRF(s) in which it is imported. By default, 727 traffic received from a remote PE is switched via an mpls forwarding 728 decision and is not subject to filtering. 730 Contrary to the behavior specified for the non-VPN NLRI, flow rules 731 are accepted by default, when received from remote PE routers. 733 9. Monitoring 735 Traffic filtering applications require monitoring and traffic 736 statistics facilities. While this is an implementation specific 737 choice, implementations SHOULD provide: 739 o A mechanism to log the packet header of filtered traffic, 741 o A mechanism to count the number of matches for a given Flow 742 Specification rule. 744 10. Security considerations 746 Inter-provider routing is based on a web of trust. Neighboring 747 autonomous-systems are trusted to advertise valid reachability 748 information. If this trust model is violated, a neighboring 749 autonomous system may cause a denial of service attack by advertising 750 reachability information for a given prefix for which it does not 751 provide service. 753 As long as traffic filtering rules are restricted to match the 754 corresponding unicast routing paths for the relevant prefixes, the 755 security characteristics of this proposal are equivalent to the 756 existing security properties of BGP unicast routing. 758 Where it not the case, this would open the door to further denial of 759 service attacks. 761 Enabling firewall like capabilities in routers without centralized 762 management could make certain failures harder to diagnose. For 763 example, with the extensions it is possible to allow TCP packets to 764 pass between a pair of addresses but not ICMP packets. It would also 765 be possible to permit packets smaller than 900 or greater than 1000 766 bytes to pass between a pair of addresses, but not packets whose 767 length is in the range 900-1000. The Internet has become 768 sufficiently aware of firewalls that such behavior is less likely to 769 be confusing than it was a few years ago and there are no new 770 capabilities introduced by these extensions, just an increased 771 likelihood that such capabilities will be used. 773 11. IANA Considerations 775 A flow specification consists of a sequence of flow components, which 776 are identified by a an 8-bit component type. Types must be assigned 777 and interpreted uniquely. The current specification defines types 1 778 though 12, with the value 0 being reserved. 780 For the purpose of this work IANA has allocated values for two SAFIs: 781 SAFI 133 for IPv4 and SAFI 134 for VPNv4 dissemination of flow 782 specification rules. 784 The following traffic filtering flow specification rules are to be 785 allocated by IANA from BGP Extended Communities Type - Experimental 786 Use registry. Authors recommend the following type values: 788 0x8006 - Flow spec traffic-rate 790 0x8007 - Flow spec traffic-action 792 0x8008 - Flow spec redirect 794 0x8009 - Flow spec traffic-remarking 796 Authors would like to ask IANA to create and maintain a new registry 797 entitled: "Flow Spec Component Type". Authors recommend to allocate 798 the following component types: 800 Type 1 - Destination Prefix 802 Type 2 - Source Prefix 804 Type 3 - IP Protocol 806 Type 4 - Port 808 Type 5 - Destination port 810 Type 6 - Source port 812 Type 7 - ICMP type 814 Type 8 - ICMP code 816 Type 9 - TCP flags 818 Type 10 - Packet length 820 Type 11 - DSCP 822 Type 12 - Fragment 824 In order to manage the limited number space and accommodate several 825 usages the following policies defined by RFC 5226 [RFC5226] are used: 827 +--------------+-------------------------------+ 828 | Range | Policy | 829 +--------------+-------------------------------+ 830 | 0 | Invalid value | 831 | [1 .. 12] | Defined by this specification | 832 | [13 .. 127] | Specification Required | 833 | [128 .. 255] | Private Use | 834 +--------------+-------------------------------+ 836 The specification of a particular "flow component type" must clearly 837 identify what is the criteria used to match packets forwarded by the 838 router. This criteria should be meaningful across router hops and 839 not depend on values that change hop-by-hop such as ttl or layer-2 840 encapsulation. 842 The "Traffic-action" extended community defined in this document has 843 6 unused bits which can be used to convey additional meaning. 844 Authors would like to ask IANA to create and maintain a new registry 845 entitled: "Traffic Action Fields". These values should be assigned 846 via IETF Review rules only. Authors recommend to allocate the 847 following traffic action fields: 849 0 Terminal Action 851 1 Sample 853 2-47 Unassigned 855 12. Acknowledgments 857 The authors would like to thank Yakov Rekhter, Dennis Ferguson, Chris 858 Morrow, Charlie Kaufman and David Smith for their comments. 860 Chaitanya Kodeboyina helped design the flow validation procedure. 862 Steven Lin and Jim Washburn ironed out all the details necessary to 863 produce a working implementation. 865 13. Normative References 867 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 868 RFC 793, September 1981. 870 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 871 Requirement Levels", BCP 14, RFC 2119, March 1997. 873 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 874 Protocol 4 (BGP-4)", RFC 4271, January 2006. 876 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 877 RFC 4303, December 2005. 879 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 880 Communities Attribute", RFC 4360, February 2006. 882 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 883 Networks (VPNs)", RFC 4364, February 2006. 885 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 886 "Multiprotocol Extensions for BGP-4", RFC 4760, 887 January 2007. 889 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 890 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 891 May 2008. 893 Authors' Addresses 895 Pedro Marques 896 Juniper Networks 897 1194 N. Mathilda Ave. 898 Sunnyvale, CA 94089 899 US 901 Email: roque@juniper.net 903 Nischal Sheth 904 Juniper Networks 905 1194 N. Mathilda Ave. 906 Sunnyvale, CA 94089 907 US 909 Email: nsheth@juniper.net 910 Robert Raszuk 911 Juniper Networks 912 1194 N. Mathilda Ave. 913 Sunnyvale, CA 94089 914 US 916 Email: raszuk@juniper.net 918 Barry Greene 919 Juniper Networks 920 1194 N. Mathilda Ave. 921 Sunnyvale, CA 94089 922 US 924 Email: bgreene@juniper.net 926 Jared Mauch 927 NTT/Verio 928 8285 Reese Lane 929 Ann Arbor, MI 48103-9753 930 US 932 Email: jared@puck.nether.net 934 Danny McPherson 935 Arbor Networks 937 Email: danny@arbor.net