idnits 2.17.00 (12 Aug 2021) /tmp/idnits65534/draft-shrivastava-ospf-flow-spec-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- ** There are 76 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 17, 2013) is 3314 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) ** Obsolete normative reference: RFC 5575 (ref. 'BGP-FLOWSPEC') (Obsoleted by RFC 8955) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Shrivastava 3 Internet-Draft M. Dubrovsky 4 Intended status: Standards Track K. Patel 5 Expires: October 19, 2013 B. Pithawala 6 Cisco Systems 7 April 17, 2013 9 Flow Specification Extensions to OSPF Protocol 10 draft-shrivastava-ospf-flow-spec-01 12 Abstract 14 This document describes the extensions to the OSPF protocol to 15 distribute the traffic flow specification rules and associated 16 actions. The notion and principles of operation of the mechanism 17 were initially introduced into the BGP protocol. The IPv4 part of 18 specification was published in RFC5575 and later the specification 19 was enhanced for IPv6 via draft-raszuk-idr-flow-spec-v6. The 20 mechanism allows the routing protocol to distribute information about 21 the traffic flows and associated actions such as packet filtering 22 with it. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on October 19, 2013. 47 Copyright Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. The Flow Specification Operation Description . . . . . . . . 4 65 2.1. The Flow Specification Origins . . . . . . . . . . . . . 4 66 2.2. Flow-specification-LSA scope and re-origination . . . . . 4 67 2.3. IPv4 and IPv6 rules . . . . . . . . . . . . . . . . . . . 4 68 3. OSPFv2 Flow-specification-LSA . . . . . . . . . . . . . . . . 5 69 3.1. Link-State ID format . . . . . . . . . . . . . . . . . . 5 70 4. OSPFv3 Flow-specification-LSA . . . . . . . . . . . . . . . . 5 71 5. Flow-specification-LSA payload . . . . . . . . . . . . . . . 6 72 6. IPv4 Flow Specification . . . . . . . . . . . . . . . . . . . 6 73 6.1. Destination Prefix TLV . . . . . . . . . . . . . . . . . 7 74 6.2. Source Prefix TLV . . . . . . . . . . . . . . . . . . . . 7 75 6.3. IP Protocol . . . . . . . . . . . . . . . . . . . . . . . 7 76 6.4. Port . . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 6.5. Destination port . . . . . . . . . . . . . . . . . . . . 7 78 6.6. Source port . . . . . . . . . . . . . . . . . . . . . . . 8 79 6.7. ICMP Type . . . . . . . . . . . . . . . . . . . . . . . . 8 80 6.8. ICMP code . . . . . . . . . . . . . . . . . . . . . . . . 8 81 6.9. TCP flags . . . . . . . . . . . . . . . . . . . . . . . . 8 82 6.10. Packet length . . . . . . . . . . . . . . . . . . . . . . 8 83 6.11. DSCP (Diffserv Code Point) . . . . . . . . . . . . . . . 8 84 6.12. Fragment . . . . . . . . . . . . . . . . . . . . . . . . 8 85 7. IPv6 Flow Specification . . . . . . . . . . . . . . . . . . . 9 86 7.1. Destination IPv6 Prefix TLV . . . . . . . . . . . . . . . 9 87 7.2. Source IPv6 Prefix TLV . . . . . . . . . . . . . . . . . 10 88 7.3. Traffic Class . . . . . . . . . . . . . . . . . . . . . . 10 89 7.4. Flow Label . . . . . . . . . . . . . . . . . . . . . . . 10 90 8. IPv4 Traffic Filtering Actions . . . . . . . . . . . . . . . 10 91 8.1. Traffic-rate . . . . . . . . . . . . . . . . . . . . . . 11 92 8.2. Traffic-action . . . . . . . . . . . . . . . . . . . . . 11 93 8.3. Redirect . . . . . . . . . . . . . . . . . . . . . . . . 11 94 8.4. Traffic-marking . . . . . . . . . . . . . . . . . . . . . 11 95 9. IPv6 Traffic Filtering Actions . . . . . . . . . . . . . . . 12 96 9.1. Traffic-marking . . . . . . . . . . . . . . . . . . . . . 12 97 10. Order of Traffic Filtering Rules . . . . . . . . . . . . . . 12 98 11. Validation Procedure . . . . . . . . . . . . . . . . . . . . 12 99 12. Security Considerations . . . . . . . . . . . . . . . . . . . 13 100 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 101 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 102 15. Normative References . . . . . . . . . . . . . . . . . . . . 15 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 105 1. Introduction 107 This document describes a method of adding capability to distribute 108 traffic flow specification rules into OSPF. 110 The semantic content of the extensions is identical to the 111 corresponding extensions to BGP ([BGP-FLOWSPEC] and 112 [draft-raszuk-idr-flow-spec-v6]). In order to avoid repetition, this 113 document only concentrates on those parts of specification where OSPF 114 is different from BGP. 116 Each flow specification rules is encapsulated into the flow- 117 specification-LSA and then flooded along with the prefix reachability 118 information across an area or the entire OSPF routing domain. When a 119 router receives the LSA from its neighbor, it decodes the data, 120 validates the information and applies the filtering rules as defined. 122 Some OSPF routers can be configured to originate flow specification 123 rules with associated actions. Other routers can be configured to 124 apply these rules from specific sets of OSPF Router IDs. 126 The use cases for the traffic policy mechanism are different from the 127 BGP. Let's look at some examples. 129 Example : Installation of a new voice gateway in the enterprise 130 network. 132 The router, which is directly connected to the new voice gateway, 133 originates flow specification rules that describe voice traffic and 134 set QoS marking action. Routers on the other side of the WAN links 135 are configured to act on this information. 137 Another example: temporarily contractors. 139 The contractor company, which is connected to the enterprise network 140 via the WAN link, should have limited access to certain servers. The 141 routers directly connected to the corporate data center can originate 142 rules describing services accessibility for contractors. The edge 143 routers with WAN links to the contractor's equipment install those 144 rules to block the undesirable traffic. 146 Last example: Service provider MPLS VPN hub-and-spoke solution for 147 the enterprise customer. 149 The spokes are connected to the MPLS VPN backbone with T1 lines and 150 the hub with OC3. OSPF CE spoke router generates flow spec with 151 rate-limit restrictions for spoke aggregated ip prefix. The flow 152 specification is then transmitted over the MPLS VPN core. OSPF CE 153 hub router uses the rule to limit the traffic towards the spoke. 155 This document does not address optimizations in storage of flow- 156 specification-LSAs in the intermediate routers or auto-discovery of 157 flow specification capable routers. 159 2. The Flow Specification Operation Description 161 2.1. The Flow Specification Origins 163 Flow specification rules can be either originated by the same router 164 that originates the corresponding destination prefix. For example, 165 in case of an OSPFv2 network-LSA, the Designated Router will also 166 advertise the corresponding flow specification rules that apply to 167 the prefix advertised in the network-LSA. 169 Each flow specification rule is encapsulated into a separate flow- 170 specification-LSA that is described below in Section 3 and Section 4. 172 The receiving routers first validate and then install flow 173 specification rules into the flow routing table. 175 2.2. Flow-specification-LSA scope and re-origination 177 Because of the validation restrictions described in Section 11 the 178 flow-specification-LSA MUST have the same scope as the scope of the 179 corresponding LSA that caries the destination prefix information of 180 the flow. When the LSA describing the destination prefix is 181 translated by the ABR router, this router SHOULD also re-originate 182 the corresponding flow-specification-LSAs with the same scope as the 183 LSA carrying the translated prefix. 185 2.3. IPv4 and IPv6 rules 186 Currently the OSPFv2 specification [OSPFV2] supports only IPv4 187 addresses and can therefore only carry IPv4 flow specification rules. 188 OSPFv3 [OSPFV3-AF] supports both IPv4 and IPv6 address families but 189 in separate instances. Therefore a particular OSPFv3 instance can 190 carry either IPv6 or IPv4 flow specification rules. 192 3. OSPFv2 Flow-specification-LSA 194 This extension makes use of the Opaque LSA [OPAQUE] to carry the flow 195 specification rules. This proposal uses type 10 for area scope and 196 type 11 for AS scope. 198 3.1. Link-State ID format 200 The link-state ID of the Opaque LSA is divided into an Opaque Type 201 field (the first 8 bits) and an Opaque ID (the remaining 24 bits). 202 The Flow-specification-LSA uses type TBD. The Opaque ID is an 203 arbitrary value used to maintain multiple flow specification rules, 204 which originate from a single router. 206 0 1 2 3 207 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | TBD | Opaque ID | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 Flow-specification-LSA LSA ID format 214 4. OSPFv3 Flow-specification-LSA 216 The OSPFv3 Flow specification information will be carried in the LSA 217 with function code TBD. The U bit will be set indicating that the 218 OSPFv3 flow-specification-LSA should be flooded even if it is not 219 understood. For the area scope flow-specification-LSA S1 bit should 220 be set and S2 should be 0. For the AS scope, the S1 bit should be 221 cleared and S2 bit should be set. Like the OSPFv2 Opaque ID field, 222 the Link State ID is an arbitrary value used to maintain multiple 223 flow specification rules originating from a single router. 225 0 1 2 3 226 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | LS age |1|S12| TDB | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Link State ID | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Advertising Router | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | LS sequence number | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | LS checksum | Length | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | | 239 +- TLVs -+ 240 | ... | 242 OSPFv3 Flow-specification-LSA 244 5. Flow-specification-LSA payload 246 The LSA payload consists of one or more nested Type/Length/Value 247 (TLV) triplets as described in Section 2.3.2 of [MPLS-TE]. 249 Each rule consists of one or more specification component types that 250 identify the flow followed by optional flow specification filtering 251 action types. 253 6. IPv4 Flow Specification 255 [BGP-FLOWSPEC] defines 12 flow specification component types: 257 Type Description 258 ---- ------------------ 259 1 Destination Prefix 260 2 Source Prefix 261 3 IP Protocol 262 4 Port 263 5 Destination Port 264 6 Source Port 265 7 ICMP type 266 8 ICMP code 267 9 TCP flags 268 10 Packet length 269 11 DSCP 270 12 Fragment 272 Each of the flow specification component types is defined in a 273 separate TLV. 275 The flow specification component type is stored in the lower 8 bits 276 of the 16-bit type field. 278 The format of each flow specification component type TLV is outlined 279 below. 281 6.1. Destination Prefix TLV 283 Defines the destination prefix to match. 285 0 1 2 3 286 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | 0 | 1 | 5 | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | IPv4 Prefix | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Prefix Length | Must Be Zero | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 6.2. Source Prefix TLV 297 The encoding is similar to the destination prefix TLV. The ype field 298 is set to 2. 300 6.3. IP Protocol 302 0 1 2 3 303 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | | 3 | Length | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Operator | Value | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | ... | 311 The Value field has a variable length and the length is determined by 312 the two bits len field in the operator byte. 314 6.4. Port 316 The same encoding as for component type IP Protocol. The TLV Type 317 field is set to 4. 319 6.5. Destination port 320 The same encoding as for component type IP Protocol. The TLV type 321 field is set to 5. 323 6.6. Source port 325 The same encoding as for component type IP Protocol. The TLV type 326 field is set to 6. 328 6.7. ICMP Type 330 The same encoding as for component type IP Protocol. The TLV Type 331 field is set to 7. 333 6.8. ICMP code 335 The same encoding as for component type IP Protocol. The TLV Type 336 field is set to 8. 338 6.9. TCP flags 340 0 1 2 3 341 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | | 9 | Length | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Operator | Bitmask | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | ... | 349 The Bitmask field is of varying length and determined by the two bits 350 len field in the operator byte. 352 6.10. Packet length 354 The same encoding as for component type IP Protocol. The TLV Type 355 field is set to 10. 357 6.11. DSCP (Diffserv Code Point) 359 The same encoding as for component type P Protocol. The TLV Type 360 field is set to 11. 362 6.12. Fragment 363 0 1 2 3 364 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | | 12 | Length | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Operator | Bitmask | ... | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | ... | 372 7. IPv6 Flow Specification 374 [draft-raszuk-idr-flow-spec-v6] defines the 12 flow specification 375 component types for IPv6. 377 Type Description 378 ---- ------------------ 379 1 Destination IPv6 Prefix 380 2 Source IPv6 Prefix 381 3 Next Header 382 4 Port 383 5 Destination port 384 6 Source port 385 7 ICMP type 386 8 ICMP code 387 9 TCP flags 388 10 Packet length 389 11 Traffic Class 390 12 Reserved 391 13 Flow Label 393 Component Types 395 Each of the flow specification component types is defined in a 396 separate TLV. 398 The flow specification component type is stored in the lower 8 bits 399 of the 16-bit type field. 401 The format of IPv6 flow specification component type TLV that are 402 different from the IPv4 outlined below. 404 7.1. Destination IPv6 Prefix TLV 406 Defines the destination prefix to match. 408 0 1 2 3 409 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | 0 | 1 | Length | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Prefix Length | Prefix Offset | | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 415 | IPv6 Prefix | 416 + + 418 The IPv6 Prefix field has variable length. The length of the field 419 is calculated from the TLV Length field. 421 7.2. Source IPv6 Prefix TLV 423 The encoding is similar to the component type Destination IPv6 Prefix 424 TLV. The Type field is set to 2. 426 7.3. Traffic Class 428 The same encoding as for component type IP Protocol. The TLV Type 429 field is set to 11. 431 7.4. Flow Label 433 The same encoding as for component type IP Protocol. The TLV Type 434 field is set to 13. 436 8. IPv4 Traffic Filtering Actions 438 In the [BGP-FLOWSPEC], the IPv4 filtering action types are 439 standardized as BGP extended community attributes. In the OSPF, the 440 filtering actions are carried in the TLVs of the flow-specification- 441 LSA. The TLV type values are the same as the BGP extended community 442 types for the filtering actions: 444 Type Description 445 ---- ------------------ 446 8006 Traffic-rate 447 8007 Traffic-action 448 8009 Traffic-marking 450 A filtering action TLV should precede the flow specification 451 component TLV. A filtering action TLV may or may not be present in a 452 flow-specification-LSA. If not present, the default action is to 453 accept the traffic that matches that particular rule. 455 The most significant bit of the 16-byte type field is set to 1, 456 distinguishing this TLV from the flow specification component TLV. 458 Below are the formats of encodeding for different IPv4 action types. 460 8.1. Traffic-rate 462 0 1 2 3 463 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | 0x80 | 6 | 4 | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | Traffic-rate | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 8.2. Traffic-action 472 0 1 2 3 473 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | 0x80 | 7 | 1 | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | |S|T| | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 The traffic-action is encoded in the 2 least significant bits of the 481 octet. 483 8.3. Redirect 485 The Redirect as defined in [BGP-FLOWSPEC] is not applicable to the 486 OSPF. 488 8.4. Traffic-marking 490 0 1 2 3 491 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | 0x80 | 9 | 1 | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | |DSCP Value | | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 The DSCP value encoded in the 6 least significant bits of the octet. 500 9. IPv6 Traffic Filtering Actions 502 [draft-raszuk-idr-flow-spec-v6] defines 3 flow specification action 503 types. Those types are standardized as BGP extended community 504 attributes. In OSPF, the IPv6 filtering actions are defined in TLVs. 505 The type values are the same as the BGP extended community types for 506 the filtering actions. 508 Type Description 509 ---- ------------------ 510 8006 Traffic-rate 511 8007 Traffic-action 512 8009 Traffic-marking 514 The flow specification filtering action type uses the full 16 bits 515 with the highest bit set to 1. 517 The format of IPv6 filtering action types TLV that are different from 518 the IPv4 outlined below. 520 9.1. Traffic-marking 522 0 1 2 3 523 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | 0x80 | 9 | 1 | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | Traffic Class | | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 10. Order of Traffic Filtering Rules 532 With traffic filtering rules, more than one rule may match a 533 particular traffic flow. The order of applying the rules is the same 534 as described in Section 5.1 of [BGP-FLOWSPEC]. 536 11. Validation Procedure 537 When a router receives the flow-specification-LSA from its 538 neighboring router, it validates the information before accepting the 539 filtering rule. A flow specification rule is considered valid if and 540 only if: 542 a) The originator of the flow specification rule matches the 543 originator of the best-match unicast route for the destination prefix 544 embedded in the flow specification. 546 The flow specification originator is identified by the Router ID of 547 the flow-specification-LSA. 549 To identify the originator of an OSPF route, look into the 550 corresponded OSPF routing table entry: 552 - for intra-area paths, the Link State Origin field of the path 553 structure is compared 555 - for inter-area and external paths, the Advertising router field of 556 the path structure is compared. 558 When multiple equal-cost paths exist in the routing table entry, each 559 path could end up having a separate set of flow specification rules. 561 b) The routing table does not have more specific unicast routes, when 562 compared with the flow destination prefix, that have been received 563 from a different router than the best-match unicast route, which has 564 been determined in step a). 566 Under certain scenarios the validation step can be bypassed. This is 567 outside of the scope of this document. 569 12. Security Considerations 571 As long as traffic filtering rules are restricted to match the 572 corresponding unicast routing paths for the relevant prefixes, the 573 security characteristics of this proposal are equivalent to the 574 existing security properties of OSPF routing. 576 Where it is not the case, this would open the door to further denial- 577 of-service attacks. 579 13. IANA Considerations 581 The following IANA assignment was made from an existing registry: 583 The OSPFv2 opaque LSA type TBD has been reserved for the OSPFv2 flow- 584 specification-LSA. 586 The OSPFv3 LSA function code TDB has been reserved for the OSPFv3 587 flow-specification-LSA. 589 For the purpose of this work, IANA has created a new registry 590 entitled: "OSPF IPv4 Flow Spec Component Types". The following 591 component types have been registered: 593 Type 1 - Destination Prefix 595 Type 2 - Source Prefix 597 Type 3 - IP Protocol 599 Type 4 - Port 601 Type 5 - Destination port 603 Type 6 - Source port 605 Type 7 - ICMP type 607 Type 8 - ICMP code 609 Type 9 - TCP flags 611 Type 10 - Packet length 613 Type 11 - DSCP 615 Type 12 - Fragment 617 For the purpose of this work, IANA has created a new registry 618 entitled: "OSPF IPv6 Flow Spec Component Types". The following 619 component types have been registered: 621 Type 1 - Destination IPv6 Prefix 623 Type 2 - Source IPv6 Prefix 625 Type 3 - Next Header 627 Type 4 - Port 629 Type 5 - Destination port 631 Type 6 - Source port 633 Type 7 - ICMP type 634 Type 8 - ICMP code 636 Type 9 - TCP flags 638 Type 10 - Packet length 640 Type 11 - Traffic Class 642 Type 12 - Reserved 644 Type 13 - Flow Label 646 For the purpose of this work, IANA has created a new registry 647 entitled: "OSPF IPv4 Flow Specification Action Types". The following 648 component types have been registered: 650 Type 0x8006 - Flow spec traffic-rate 652 Type 0x8007 - Flow spec traffic-action 654 Type 0x8009 - Flow spec traffic-remarking 656 For the purpose of this work, IANA has created a new registry 657 entitled: "OSPF IPv6 Flow Specification Action Types". The following 658 component types have been registered: 660 Type 0x8006 - Flow spec traffic-rate 662 Type 0x8007 - Flow spec traffic-action 664 Type 0x8009 - Flow spec traffic-remarking 666 14. Acknowledgements 668 15. Normative References 670 [BGP-FLOWSPEC] 671 Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 672 and D. McPherson, "Dissemination of Flow Specification 673 Rules", RFC 5575, August 2009. 675 [MPLS-TE] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 676 (TE) Extensions to OSPF Version 2", RFC 3630, September 677 2003. 679 [OPAQUE] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 680 OSPF Opaque LSA Option", RFC 5250, July 2008. 682 [OSPFV2] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 684 [OSPFV3-AF] 685 Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. 686 Aggarwal, "Support of Address Families in OSPFv3", RFC 687 5838, April 2010. 689 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 690 Requirement Levels", BCP 14, RFC 2119, March 1997. 692 [draft-raszuk-idr-flow-spec-v6] 693 Raszuk, R., "Dissemination of Flow Specification Rules for 694 IPv6", March 2012. 696 Authors' Addresses 698 Rashmi Shrivastava 699 Cisco Systems 700 170 West Tasman Drive 701 San Jose, CA 95134 702 US 704 Email: rashi@cisco.com 706 Mike Dubrovsky 707 Cisco Systems 708 170 West Tasman Drive 709 San Jose, CA 95134 710 US 712 Email: mdubrovs@cisco.com 714 Keyur Patel 715 Cisco Systems 716 170 West Tasman Drive 717 San Jose, CA 95134 718 US 720 Email: keyupate@cisco.com 721 Burjiz Pithawala 722 Cisco Systems 723 170 West Tasman Drive 724 San Jose, CA 95134 725 US 727 Email: bpithaw@cisco.com