idnits 2.17.1 draft-liang-ospf-flowspec-extensions-05.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5575]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 28, 2015) is 3255 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) == Missing Reference: 'I-D.ietf-ospf-rfc4970bis' is mentioned on line 667, but not defined ** Obsolete undefined reference: RFC 4970 (Obsoleted by RFC 7770) ** Obsolete normative reference: RFC 5575 (Obsoleted by RFC 8955) == Outdated reference: A later version (-15) exists of draft-ietf-idr-bgp-flowspec-oid-02 == Outdated reference: A later version (-22) exists of draft-ietf-idr-flow-spec-v6-06 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Ospf Working Group Q. Liang 3 Internet-Draft J. You 4 Intended status: Standards Track N. Wu 5 Expires: November 29, 2015 Huawei 6 P. Fan 7 China Mobile 8 K. Patel 9 A. Lindem 10 Cisco Systems 11 May 28, 2015 13 OSPF Extensions for Flow Specification 14 draft-liang-ospf-flowspec-extensions-05 16 Abstract 18 Dissemination of the Traffic flow information was first introduced in 19 the BGP protocol [RFC5575]. FlowSpec routes are used to distribute 20 traffic filtering rules that are used to filter Denial-of-Service 21 (DoS) attacks. For the networks that only deploy an IGP (Interior 22 Gateway Protocol) (e.g., OSPF), it is required that the IGP is 23 extended to distribute Flow Specification or FlowSpec routes. 25 This document discusses the use cases for distributing flow 26 specification (FlowSpec) routes using OSPF. Furthermore, this 27 document defines a OSPF FlowSpec Opaque Link State Advertisement 28 (LSA) encoding format that can be used to distribute FlowSpec routes, 29 its validation procedures for imposing the filtering information on 30 the routers, and a capability to indicate the support of FlowSpec 31 functionality. 33 Requirements Language 35 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 36 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 37 document are to be interpreted as described in [RFC2119]. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at http://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on November 29, 2015. 56 Copyright Notice 58 Copyright (c) 2015 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 75 3. Use Cases for OSPF based FlowSpec Distribution . . . . . . . 4 76 3.1. OSPF Campus Network . . . . . . . . . . . . . . . . . . . 4 77 3.2. BGP/MPLS VPN . . . . . . . . . . . . . . . . . . . . . . 4 78 3.2.1. Traffic Analyzer Deployed in Provider Network . . . . 5 79 3.2.2. Traffic Analyzer Deployed in Customer Network . . . . 6 80 3.2.3. Policy Configuration . . . . . . . . . . . . . . . . 6 81 4. OSPF Extensions for FlowSpec Rules . . . . . . . . . . . . . 7 82 4.1. FlowSpec LSA . . . . . . . . . . . . . . . . . . . . . . 7 83 4.1.1. OSPFv2 FlowSpec Opaque LSA . . . . . . . . . . . . . 7 84 4.1.2. OSPFv3 FlowSpec LSA . . . . . . . . . . . . . . . . . 9 85 4.2. OSPF FlowSpec Filters TLV . . . . . . . . . . . . . . . . 10 86 4.2.1. Order of Traffic Filtering Rules . . . . . . . . . . 11 87 4.2.2. Validation Procedure . . . . . . . . . . . . . . . . 12 88 4.3. OSPF FlowSpec Action TLV . . . . . . . . . . . . . . . . 12 89 4.3.1. Traffic-rate . . . . . . . . . . . . . . . . . . . . 13 90 4.3.2. Traffic-action . . . . . . . . . . . . . . . . . . . 13 91 4.3.3. Traffic-marking . . . . . . . . . . . . . . . . . . . 13 92 4.3.4. Redirect-to-IP . . . . . . . . . . . . . . . . . . . 14 93 4.4. Capability Advertisement . . . . . . . . . . . . . . . . 15 94 5. Redistribution of FlowSpec Routes . . . . . . . . . . . . . . 15 95 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 96 7. Security considerations . . . . . . . . . . . . . . . . . . . 16 97 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 16 98 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 99 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 100 9.2. Informative References . . . . . . . . . . . . . . . . . 17 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 103 1. Introduction 105 [RFC5575] defines Border Gateway Protocol protocol extensions that 106 can be used to distribute traffic flow specifications. One 107 application of this encoding format is to automate inter-domain 108 coordination of traffic filtering, such as what is required in order 109 to mitigate (distributed) denial-of-service attacks. [RFC5575] 110 allows flow specifications received from an external autonomous 111 system to be forwarded to a given BGP peer. However, in order to 112 block the attack traffic more effectively, it is better to distribute 113 the BGP FlowSpec routes to the customer network, which is much closer 114 to the attacker. 116 For the networks deploying only an IGP (e.g., OSPF), it is expected 117 to extend the IGP (OSPF in this document) to distribute FlowSpec 118 routes. This document discusses the use cases for distributing 119 FlowSpec routes using OSPF. Furthermore, this document also defines 120 a new OSPF FlowSpec Opaque Link State Advertisement (LSA) [RFC5250] 121 encoding format that can be used to distribute FlowSpec routes to the 122 edge routers in the customer network, its validation procedures for 123 imposing the filtering information on the routers, and a capability 124 to indicate the support of Flowspec functionality. 126 The semantic content of the FlowSpec extensions defined in this 127 document are identical to the corresponding extensions to BGP 128 ([RFC5575] and [I-D.ietf-idr-flow-spec-v6]). In order to avoid 129 repetition, this document only concentrates on those parts of 130 specification where OSPF is different from BGP. The OSPF flowspec 131 extensions defined in this document can be used to mitigate the 132 impacts of DoS attacks. 134 2. Terminology 136 This section contains definitions for terms used frequently 137 throughout this document. However, many additional definitions can 138 be found in [RFC5250] and [RFC5575]. 140 Flow Specification (FlowSpec): A flow specification is an n-tuple 141 consisting of several matching criteria that can be applied to IP 142 traffic, including filters and actions. Each FlowSpec consists of 143 a set of filters and a set of actions. 145 3. Use Cases for OSPF based FlowSpec Distribution 147 For the networks deploying only an IGP (e.g., OSPF), it is expected 148 to extend the IGP (OSPF in this document) to distribute FlowSpec 149 routes, because when the FlowSpec routes are installed in the 150 customer network, they are closer to the attacker than when they are 151 installed in the provider network. Consequently, the attack traffic 152 could be blocked or the suspicious traffic could be limited to a low 153 rate as early as possible. 155 The following sub-sections discuss the use cases for OSPF based 156 FlowSpec route distribution. 158 3.1. OSPF Campus Network 160 For networks not deploying BGP, for example, the campus network using 161 OSPF, it is expected to extend OSPF to distribute FlowSpec routes as 162 shown in Figure 3. In this kind of network, the traffic analyzer 163 could be deployed with a router, then the FlowSpec routes from the 164 traffic analyzer need to be distributed to the other routers in this 165 domain using OSPF. 167 +--------+ 168 |Traffic | 169 +---+Analyzer| 170 | +--------+ 171 | 172 |FlowSpec 173 | 174 | 175 +--+-------+ +----------+ +--------+ 176 | Router A +-----------+ Router B +--------+Attacker| 177 +----------+ +----------+ +--------+ 179 | | | 180 | OSPF FlowSpec | Attack Traffic | 181 | | | 183 Figure 3: OSPF Campus Network 185 3.2. BGP/MPLS VPN 187 [RFC5575] defines a BGP NLRI encoding format to distribute traffic 188 flow specifications in BGP deployed network. However, in the BGP/ 189 MPLS VPN scenario, the IGP (e.g., IS-IS, or OSPF) is used between the 190 PE (Provider Edge) and CE (Customer Edge) in many deployments. In 191 order to distribute the FlowSpec routes to the customer network, the 192 IGP needs to support FlowSpec route distribution. The FlowSpec 193 routes are usually generated by the traffic analyzer or the traffic 194 policy center in the network. Depending on the location of the 195 traffic analyzer deployment, two different distribution scenarios are 196 discussed below. 198 3.2.1. Traffic Analyzer Deployed in Provider Network 200 The traffic analyzer (also acting as the traffic policy center) could 201 be deployed in the provider network as shown in Figure 1. If the 202 traffic analyzer detects attack traffic from the customer network 203 VPN1, it would generate the FlowSpec routes for preventing DoS 204 attacks. FlowSpec routes with a Route Distinguisher (RD) in the 205 Network Layer Reachability information (NRLI) corresponding to VPN1 206 are distributed from the traffic analyzer to the PE1 to which the 207 traffic analyzer is attached. If the traffic analyzer is also a BGP 208 speaker, it can distribute the FlowSpec routes using BGP [RFC5575]. 209 Then the PE1 distributes the FlowSpec routes further to the PE2. 210 Finally, the FlowSpec routes need to be distributed from PE2 to the 211 CE2 using OSPF, i.e., to the customer network VPN1. As an attacker 212 is more likely in the customer network, FlowSpec routes installed 213 directly on CE2 could mitigate the impact of DoS attacks better. 215 +--------+ 216 |Traffic | 217 +---+Analyzer| ----------- 218 | +--------+ //- -\\ 219 | /// \\\ 220 |FlowSpec / \ 221 | // \\ 222 | | | 223 +--+--+ +-----+ | +-----+ +--------+ | 224 | PE1 +-------+ PE2 +-------+--+ CE2 +-------+Attacker| | 225 +-----+ +-----+ | +-----+ +--------+ | 226 | | 227 | | | | | | 228 | BGP FlowSpec | OSPF FlowSpec | Attack Traffic| | 229 | | \\ | | // 230 \ / 231 \\\ VPN1 /// 232 \\-- --// 233 --------- 235 Figure 1: Traffic Analyzer deployed in Provider Network 237 3.2.2. Traffic Analyzer Deployed in Customer Network 239 The traffic analyzer (also acting as the traffic policy center) could 240 be deployed in the customer network as shown in Figure 2. If the 241 traffic analyzer detects attack traffic, it would generate FlowSpec 242 routes to prevent associated DoS attacks. Then the FlowSpec routes 243 would be distributed from the traffic analyzer to the CE1 using OSPF 244 or another policy protocol (e.g., RESTful API over HTTP). 245 Furthermore, the FlowSpec routes need to be distributed throughout 246 the provider network via PE1/PE2 to CE2, i.e., to the remote customer 247 network VPN1 Site1. If the FlowSpec routes installed on the CE2, it 248 could block the attack traffic as close to the source of the attack 249 as possible. 251 +--------+ 252 |Traffic | 253 +---+Analyzer| 254 | +--------+ ------ 255 | //-- --\\ 256 |FlowSpec // \\ 257 | / \ 258 | // \\ 259 +--+--+ +-----+ +-----+ | +-----+ +--------+ | 260 | CE1 +--------+ PE1 +-------+ PE2 +----- +--+ CE2 +-----+Attacker| | 261 +-----+ +-----+ +-----+ | +-----+ +--------+ | 262 | | | | | | | 263 | OSPF FlowSpec | BGP FlowSpec| OSPF FlowSpec |Attack Traffic| | 264 | | | | | | | 265 | | 266 \\ // 267 \ VPN1 Site1 / 268 \\ // 269 \\-- --// 270 ----- 272 Figure 2: Traffic Analyzer deployed in Customer Network 274 3.2.3. Policy Configuration 276 The CE or PE could deploy local filtering policies to filter OSPF 277 FlowSpec rules, for example, deploying a filtering policy to filter 278 the incoming OSPF FlowSpec rules in order to prevent illegal or 279 invalid FlowSpec rules from being applied. 281 The PE should configure FlowSpec importing policies to control 282 importing action between the BGP IP/VPN FlowSpec RIB and the OSPF 283 Instance FlowSpec RIB. Otherwise, the PE couldn't transform a BGP 284 IP/VPN FlowSpec rule to an OSPF FlowSpec rule or transform an OSPF 285 FlowSpec rule to a BGP IP/VPN FlowSpec rule. 287 4. OSPF Extensions for FlowSpec Rules 289 4.1. FlowSpec LSA 291 4.1.1. OSPFv2 FlowSpec Opaque LSA 293 This document defines a new OSPFv2 flow specification Opaque Link 294 State Advertisement (LSA) encoding format that can be used to 295 distribute traffic flow specifications. This new OSPF FlowSpec 296 Opaque LSA is extended based on [RFC5250]. 298 The OSPFv2 FlowSpec Opaque LSA is defined below in Figure 4: 300 0 1 2 3 301 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 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | LS Age | Options | LS Type | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Opaque Type | Opaque ID | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Advertising Router | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | LS sequence number | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | LS checksum | Length | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | | 314 + + 315 | TLVs | 316 + + 317 | ... | 319 Figure 4: OSPFv2 FlowSpec Opaque LSA 321 LS age: the same as defined in [RFC2328]. 323 Options: the same as defined in [RFC2328]. 325 LS type: A type-11 or type-10 Opaque-LSA SHOULD be originated. 326 Since the type-11 LSA has the same flooding scope as a type-5 LSA 327 as stated in [RFC5250], it will not be flooded into stub areas or 328 NSSAs (Not-So-Stubby Areas). When stub or NSSA areas are 329 encountered in the scenario of flow spec, we may have to make our 330 choice, either making peace with it and filtering the DoS traffic 331 at ABRs or generating a new type-10 Opaque-LSA into stub/NSSA 332 areas, which may aggravate the burden of devices in that area. 334 Opaque type: OSPF FlowSpec Opaque LSA (Type Code: TBD1). 336 Opaque ID: the same as defined in [RFC5250]. 338 Advertising Router: the same as defined in [RFC2328]. 340 LS sequence number: the same as defined in [RFC2328]. 342 LS checksum: the same as defined in [RFC2328]. 344 Length: the same as defined in [RFC2328]. 346 TLVs: one or more TLVs MAY be included in a FlowSpec Opaque LSA to 347 carry FlowSpec information. 349 The variable TLVs section consists of one or more nested Type/Length/ 350 Value (TLV) tuples. Nested TLVs are also referred to as sub-TLVs. 351 The format of each TLV is shown in Figure 5: 353 0 1 2 3 354 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 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Type | Length | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Values... | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 Figure 5: TLV Format 363 The Length field defines the length of the value portion in octets 364 (thus a TLV with no value portion would have a length of 0). The TLV 365 is padded to 4-octet alignment; padding is not included in the length 366 field (so a 3-octet value would have a length of 3, but the total 367 size of the TLV would be 8 octets). Nested TLVs are also 32-bit 368 aligned. For example, a 1-octet value would have the length field 369 set to 1, and 3 octets of padding would be added to the end of the 370 value portion of the TLV. 372 If FlowSpec Opaque LSA is Type-11 Opaque LSA, it is not flooded into 373 Stub and NSSA areas. As the traffic accessing a network segment 374 outside Stub and NSSA areas would be aggregated to the ABR, FlowSpec 375 rules could be applied on the ABR instead of disseminating them into 376 Stub and NSSA areas. 378 4.1.2. OSPFv3 FlowSpec LSA 380 This document defines a new OSPFv3 flow specification LSA encoding 381 format that can be used to distribute traffic flow specifications. 382 This new OSPFv3 FlowSpec LSA is extended based on [RFC5340]. 384 The OSPFv3 FlowSpec LSA is defined below in Figure 6: 386 0 1 2 3 387 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 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | LS Age | LS Type | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Link State ID | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Advertising Router | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | LS sequence number | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | LS checksum | Length | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | | 400 + + 401 | TLVs | 402 + + 403 | ... | 405 Figure 6: OSPFv3 FlowSpec LSA 407 LS age: the same as defined in [RFC5340]. 409 LS type: the same as defined in [RFC5340]. The format of the LS 410 type is as follows: 412 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 413 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 414 |U |S2|S1| LSA Function Code | 415 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 417 Figure 7: LSA Type 419 In this document, the U bit should be set indicating that the 420 OSPFv3 FlowSpec LSA should be flooded even if it is not 421 understood. For the area scope, the S1 bit should be set and the 422 S2 should be clear. For the AS scope, the S1 bit should be clear 423 and the S2 bit should be set. A new LSA Function Code (TBD2) 424 needs to be defined for OSPFv3 FlowSpec LSA. To facilitate inter- 425 area reachability validation, any OSPFv3 router originating AS 426 scoped LSAs is considered an AS Boundary Router (ASBR). 428 Link State ID: the same as defined in [RFC5340]. 430 Advertising Router: the same as defined in [RFC5340]. 432 LS sequence number: the same as defined in [RFC5340]. 434 LS checksum: the same as defined in [RFC5340]. 436 Length: the same as defined in [RFC5340]. 438 TLVs: one or more TLVs MAY be included in a OSPFv3 FlowSpec LSA to 439 carry FlowSpec information. 441 4.2. OSPF FlowSpec Filters TLV 443 The FlowSpec Opaque LSA carries one or more FlowSpec Filters TLVs and 444 corresponding FlowSpec Action TLVs. The OSPF FlowSpec Filters TLV is 445 defined below in Figure 8. 447 0 1 2 3 448 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 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Type | Length | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Flags | Filters (variable) ~ 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 ~ Filters (variable) ~ 455 + + 456 | ... | 458 Figure 8: OSPF FlowSpec Filters TLV 460 Type: the TLV type (Type Code: TBD3) 462 Length: the size of the value field in octets 464 Flags: One octet Field identifying Flags. 466 0 1 2 3 4 5 6 7 467 +-+-+-+-+-+-+-+-+ 468 | Reserved |S| 469 +-+-+-+-+-+-+-+-+ 471 The least significant bit S is defined as a strict Filter check bit. 472 If set, Strict Validation rules outlined in the validation section 473 Section 4.2.2 need to be enforced. 475 Filters: the same as "flow-spec NLRI value" defined in [RFC5575] and 476 [I-D.ietf-idr-flow-spec-v6]. 478 Table 1: OSPF Supported FlowSpec Filters 479 +------+------------------------+------------------------------+ 480 | Type | Description | RFC/ WG draft | 481 +------+------------------------+------------------------------+ 482 | 1 | Destination IPv4 Prefix| RFC5575 | 483 | | Destination IPv6 Prefix| I-D.ietf-idr-flow-spec-v6 | 484 +------+------------------------+------------------------------+ 485 | 2 | Source IPv4 Prefix | RFC5575 | 486 | | Source IPv6 Prefix | I-D.ietf-idr-flow-spec-v6 | 487 +------+------------------------+------------------------------+ 488 | 3 | IP Protocol | RFC5575 | 489 | | Next Header | I-D.ietf-idr-flow-spec-v6 | 490 +------+------------------------+------------------------------+ 491 | 4 | Port | RFC5575 | 492 +------+------------------------+------------------------------+ 493 | 5 | Destination port | RFC5575 | 494 +------+------------------------+------------------------------+ 495 | 6 | Source port | RFC5575 | 496 +------+------------------------+------------------------------+ 497 | 7 | ICMP type | RFC5575 | 498 +------+------------------------+------------------------------+ 499 | 8 | ICMP code | RFC5575 | 500 +------+------------------------+------------------------------+ 501 | 9 | TCP flags | RFC5575 | 502 +------+------------------------+------------------------------+ 503 | 10 | Packet length | RFC5575 | 504 +------+------------------------+------------------------------+ 505 | 11 | DSCP | RFC5575 | 506 +------+------------------------+------------------------------+ 507 | 12 | Fragment | RFC5575 | 508 +------+------------------------+------------------------------+ 509 | 13 | Flow Label | I-D.ietf-idr-flow-spec-v6 | 510 +------+----------------------- ------------------------------+ 512 4.2.1. Order of Traffic Filtering Rules 514 With traffic filtering rules, more than one rule may match a 515 particular traffic flow. The order of applying the traffic filter 516 rules is the same as described in Section 5.1 of [RFC5575] and in 517 Section 3.1 of [I-D.ietf-idr-flow-spec-v6]. 519 4.2.2. Validation Procedure 521 [RFC5575] defines a validation procedure for BGP FlowSpec rules, and 522 [I-D.ietf-idr-bgp-flowspec-oid] describes a modification to the 523 validation procedure defined in [RFC5575] for the dissemination of 524 BGP flow specifications. The OSPF FlowSpec should support similar 525 features to mitigate the unnecessary application of traffic filter 526 rules. The OSPF FlowSpec validation procedure is described as 527 follows. 529 When a router receives a FlowSpec rule including a destination prefix 530 filter from its neighbor router, it should consider the prefix filter 531 as a valid filter unless the S bit in the flags field of Filter TLV 532 is set. If the S bit is set, then the FlowSpec rule is considered 533 valid if and only if: 535 The originator of the FlowSpec rule matches the originator of the 536 best-match unicast route for the destination prefix embedded in 537 the FlowSpec. 539 The former rule allows any centralized controller to originate the 540 prefix filter and advertise it within a given OSPF network. The 541 latter rule, also known as a Strict Validation rule, allows strict 542 checking and enforces that the originator of the FlowSpec filter is 543 also the originator of the destination prefix. 545 When multiple equal-cost paths exist in the routing table entry, each 546 path could end up having a separate set of FlowSpec rules. 548 When a router receives a FlowSpec rule not including a destination 549 prefix filter from its neighbor router, the validation procedure 550 described above is not applicable. 552 The FlowSpec filter validation state is used by a speaker when the 553 filter is considered for an installation in its FIB. An OSPF speaker 554 MUST flood OSPF FlowSpec LSA as per the rules defined in [RFC2328] 555 regardless of the validation state of the prefix filters. 557 4.3. OSPF FlowSpec Action TLV 559 There are one or more FlowSpec Action TLVs associated with a FlowSpec 560 Filters TLV. Different FlowSpec Filters TLV could have the same 561 FlowSpec Action TLVs. The following OSPF FlowSpec action TLVs, 562 except Redirect, are same as defined in [RFC5575]. 564 Redirect: IPv4 or IPv6 address. This IP address may correspond to a 565 tunnel, i.e., the redirect allows the traffic to be redirected to a 566 directly attached next-hop or a next-hop requiring a route lookup. 568 Table 2: Traffic Filtering Actions in [RFC5575], etc. 569 +-------+-----------------+---------------------------------------+ 570 | type | FlowSpec Action | RFC/WG draft | 571 +-------+-----------------+---------------------------------------+ 572 | 0x8006| traffic-rate | RFC5575 | 573 | | | | 574 | 0x8007| traffic-action | RFC5575 | 575 | | | | 576 | 0x8108| redirect-to-IPv4| I-D.ietf-idr-flowspec-redirect-rt-bis | 577 | | | 578 | 0x800b| redirect-to-IPv6| I-D.ietf-idr-flow-spec-v6 | 579 | | | | 580 | 0x8009| traffic-marking | RFC5575 | 581 +-------+-----------------+---------------------------------------+ 583 4.3.1. Traffic-rate 585 Traffic-rate TLV is encoded as: 587 0 1 2 3 588 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 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | TBD5,0x8006 suggested | 4 | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | Traffic-rate | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 Traffic-rate: the same as defined in [RFC5575]. 597 4.3.2. Traffic-action 599 Traffic-action TLV is encoded as: 601 0 1 2 3 602 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 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | TBD6, 0x8007 suggested | 2 | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | Reserved |S|T| | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 S flag and T flag: the same as defined in [RFC5575]. 611 4.3.3. Traffic-marking 613 Traffic-marking TLV is encoded as: 615 0 1 2 3 616 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 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | TBD7, 0x8009 suggested | 2 | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | Reserved | DSCP Value| | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 DSCP value: the same as defined in [RFC5575]. 625 4.3.4. Redirect-to-IP 627 Redirect-to-IPv4 is encoded as: 629 0 1 2 3 630 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 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 | TBD8, 0x8108 suggested | 6 | 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 | IPv4 Address | 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 | Reserved |C| | 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 Redirect to IPv6 TLV is encoded as (Only for OSPFv3): 641 0 1 2 3 642 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 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 | TBD9, 0x800b suggested | 18 | 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 | | 647 | IPv6 Address | 648 | | 649 | | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | Reserved |C| | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 IPv4/6 Address: the redirection target address. 656 'C' (or copy) bit: when the 'C' bit is set, the redirection applies 657 to copies of the matching packets and not to the original traffic 658 stream [I-D.ietf-idr-flowspec-redirect-ip]. 660 4.4. Capability Advertisement 662 This document defines a capability bit for OSPF Router-Information 663 LSA [I-D.ietf-ospf-rfc4970bis] as FlowSpec Capability Advertisement 664 bit. When set, the OSPF router indicates its ability to support the 665 FlowSpec functionality. The FlowSpec Capability Advertisement bit 666 has a value to be assigned by IANA from OSPF Router Functional 667 Capability Bits Registry [I-D.ietf-ospf-rfc4970bis]. 669 5. Redistribution of FlowSpec Routes 671 In certain scenarios, FlowSpec routes MAY get redistributed from one 672 protocol domain to another; specifically from BGP to OSPF and vice- 673 versa. When redistributed from BGP, the OSPF speaker SHOULD generate 674 an Opaque LSA for the redistributed routes and announce it within an 675 OSPF domain. An implementation MAY provide an option for an OSPF 676 speaker to announce a redistributed FlowSpec route within a OSPF 677 domain regardless of being installed in its local FIB. An 678 implementation MAY impose an upper bound on number of FlowSpec routes 679 that an OSPF router MAY advertise. 681 6. IANA Considerations 683 This document defines a new OSPFv2 Opaque LSA, i.e., OSPFv2 FlowSpec 684 Opaque LSA (Type Code: TBD1), which is used to distribute traffic 685 flow specifications. 687 This document defines a new OSPFv3 LSA, i.e., OSPFv3 FlowSpec LSA 688 (LSA Function Code: TBD2), which is used to distribute traffic flow 689 specifications. 691 This document defines OSPF FlowSpec Filters TLV (Type Code: TBD3), 692 which is used to describe the filters. 694 This document defines a new FlowSpec capability which need to be 695 advertised in an RI Opaque LSA. A new informational capability bit 696 needs to be assigned for OSPF FlowSpec feature (FlowSpec Bit: TBD4). 698 This document defines a new Router LSA bit known as a FlowSpec 699 Capability Advertisement bit. This document requests IANA to assign 700 a bit code type for FlowSpec Capability Advertisement bit from the 701 OSPF Router Functional Capability Bits registry. 703 Type 1 - Destination IPv4/IPv6 Prefix 704 Type 2 - Source IPv4/IPv6 Prefix 705 Type 3 - IP Protocol/Next Header 706 Type 4 - Port 707 Type 5 - Destination port 708 Type 6 - Source port 709 Type 7 - ICMP type 710 Type 8 - ICMP code 711 Type 9 - TCP flags 712 Type 10 - Packet length 713 Type 11 - DSCP 714 Type 12 - Fragment 715 Type 13 - Flow Label 717 This document defines a group of FlowSpec actions. The following TLV 718 types need to be assigned: 720 Type 0x8006(TBD5) - traffic-rate 721 Type 0x8007(TBD6) - traffic-action 722 Type 0x8009(TBD7) - traffic-marking 723 Type 0x8108(TBD8) - redirect to IPv4 724 Type 0x800b(TBD9) - redirect to IPv6 726 7. Security considerations 728 This extension to OSPF does not change the underlying security issues 729 inherent in the existing OSPF. Implementations must assure that 730 malformed TLV and Sub-TLV permutations do not result in errors which 731 cause hard OSPF failures. 733 8. Acknowledgement 735 The authors would also like to thank Burjiz Pithawala, Rashmi 736 Shrivastava and Mike Dubrovsky for their contribution to the original 737 version of the document. 739 9. References 741 9.1. Normative References 743 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 744 Requirement Levels", BCP 14, RFC 2119, March 1997. 746 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 748 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 749 OSPF Opaque LSA Option", RFC 5250, July 2008. 751 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 752 for IPv6", RFC 5340, July 2008. 754 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 755 and D. McPherson, "Dissemination of Flow Specification 756 Rules", RFC 5575, August 2009. 758 9.2. Informative References 760 [I-D.ietf-idr-bgp-flowspec-oid] 761 Uttaro, J., Filsfils, C., Smith, D., Alcaide, J., and P. 762 Mohapatra, "Revised Validation Procedure for BGP Flow 763 Specifications", draft-ietf-idr-bgp-flowspec-oid-02 (work 764 in progress), January 2014. 766 [I-D.ietf-idr-flow-spec-v6] 767 Raszuk, R., Pithawala, B., McPherson, D., and A. Andy, 768 "Dissemination of Flow Specification Rules for IPv6", 769 draft-ietf-idr-flow-spec-v6-06 (work in progress), 770 November 2014. 772 [I-D.ietf-idr-flowspec-redirect-ip] 773 Uttaro, J., Haas, J., Texier, M., Andy, A., Ray, S., 774 Simpson, A., and W. Henderickx, "BGP Flow-Spec Redirect to 775 IP Action", draft-ietf-idr-flowspec-redirect-ip-02 (work 776 in progress), February 2015. 778 Authors' Addresses 780 Qiandeng Liang 781 Huawei 782 101 Software Avenue, Yuhuatai District 783 Nanjing, 210012 784 China 786 Email: liuweihang@huawei.com 788 Jianjie You 789 Huawei 790 101 Software Avenue, Yuhuatai District 791 Nanjing, 210012 792 China 794 Email: youjianjie@huawei.com 795 Nan Wu 796 Huawei 798 Email: eric.wu@huawei.com 800 Peng Fan 801 China Mobile 803 Email: fanpeng@chinamobile.com 805 Keyur Patel 806 Cisco Systems 807 170 W. Tasman Drive 808 San Jose, CA 95124 95134 809 USA 811 Email: keyupate@cisco.com 813 Acee Lindem 814 Cisco Systems 815 170 W. Tasman Drive 816 San Jose, CA 95124 95134 817 USA 819 Email: acee@cisco.com