idnits 2.17.1 draft-ietf-ospf-flowspec-extensions-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 : ---------------------------------------------------------------------------- ** 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 (April 14, 2016) is 2927 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 710, 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-03 == Outdated reference: A later version (-22) exists of draft-ietf-idr-flow-spec-v6-07 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: October 16, 2016 Huawei 6 P. Fan 7 Independent 8 K. Patel 9 A. Lindem 10 Cisco Systems 11 April 14, 2016 13 OSPF Extensions for Flow Specification 14 draft-ietf-ospf-flowspec-extensions-01 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 October 16, 2016. 56 Copyright Notice 58 Copyright (c) 2016 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. Interface-Set TLV . . . . . . . . . . . . . . . . . . 11 87 4.2.2. Order of Traffic Filtering Rules . . . . . . . . . . 12 88 4.2.3. Validation Procedure . . . . . . . . . . . . . . . . 12 89 4.3. OSPF FlowSpec Action TLV . . . . . . . . . . . . . . . . 13 90 4.3.1. Traffic-rate . . . . . . . . . . . . . . . . . . . . 14 91 4.3.2. Traffic-action . . . . . . . . . . . . . . . . . . . 14 92 4.3.3. Traffic-marking . . . . . . . . . . . . . . . . . . . 14 93 4.3.4. Redirect-to-IP . . . . . . . . . . . . . . . . . . . 15 94 4.4. Capability Advertisement . . . . . . . . . . . . . . . . 16 95 5. Redistribution of FlowSpec Routes . . . . . . . . . . . . . . 16 96 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 97 7. Security considerations . . . . . . . . . . . . . . . . . . . 17 98 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 17 99 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 100 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 101 9.2. Informative References . . . . . . . . . . . . . . . . . 18 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 104 1. Introduction 106 [RFC5575] defines Border Gateway Protocol protocol extensions that 107 can be used to distribute traffic flow specifications. One 108 application of this encoding format is to automate inter-domain 109 coordination of traffic filtering, such as what is required in order 110 to mitigate (distributed) denial-of-service attacks. [RFC5575] 111 allows flow specifications received from an external autonomous 112 system to be forwarded to a given BGP peer. However, in order to 113 block the attack traffic more effectively, it is better to distribute 114 the BGP FlowSpec routes to the customer network, which is much closer 115 to the attacker. 117 For the networks deploying only an IGP (e.g., OSPF), it is expected 118 to extend the IGP (OSPF in this document) to distribute FlowSpec 119 routes. This document discusses the use cases for distributing 120 FlowSpec routes using OSPF. Furthermore, this document also defines 121 a new OSPF FlowSpec Opaque Link State Advertisement (LSA) [RFC5250] 122 encoding format that can be used to distribute FlowSpec routes to the 123 edge routers in the customer network, its validation procedures for 124 imposing the filtering information on the routers, and a capability 125 to indicate the support of Flowspec functionality. 127 The semantic content of the FlowSpec extensions defined in this 128 document are identical to the corresponding extensions to BGP 129 ([RFC5575] and [I-D.ietf-idr-flow-spec-v6]). In order to avoid 130 repetition, this document only concentrates on those parts of 131 specification where OSPF is different from BGP. The OSPF flowspec 132 extensions defined in this document can be used to mitigate the 133 impacts of DoS attacks. 135 2. Terminology 137 This section contains definitions for terms used frequently 138 throughout this document. However, many additional definitions can 139 be found in [RFC5250] and [RFC5575]. 141 Flow Specification (FlowSpec): A flow specification is an n-tuple 142 consisting of several matching criteria that can be applied to IP 143 traffic, including filters and actions. Each FlowSpec consists of 144 a set of filters and a set of actions. 146 3. Use Cases for OSPF based FlowSpec Distribution 148 For the networks deploying only an IGP (e.g., OSPF), it is expected 149 to extend the IGP (OSPF in this document) to distribute FlowSpec 150 routes, because when the FlowSpec routes are installed in the 151 customer network, they are closer to the attacker than when they are 152 installed in the provider network. Consequently, the attack traffic 153 could be blocked or the suspicious traffic could be limited to a low 154 rate as early as possible. 156 The following sub-sections discuss the use cases for OSPF based 157 FlowSpec route distribution. 159 3.1. OSPF Campus Network 161 For networks not deploying BGP, for example, the campus network using 162 OSPF, it is expected to extend OSPF to distribute FlowSpec routes as 163 shown in Figure 3. In this kind of network, the traffic analyzer 164 could be deployed with a router, then the FlowSpec routes from the 165 traffic analyzer need to be distributed to the other routers in this 166 domain using OSPF. 168 +--------+ 169 |Traffic | 170 +---+Analyzer| 171 | +--------+ 172 | 173 |FlowSpec 174 | 175 | 176 +--+-------+ +----------+ +--------+ 177 | Router A +-----------+ Router B +--------+Attacker| 178 +----------+ +----------+ +--------+ 180 | | | 181 | OSPF FlowSpec | Attack Traffic | 182 | | | 184 Figure 3: OSPF Campus Network 186 3.2. BGP/MPLS VPN 188 [RFC5575] defines a BGP NLRI encoding format to distribute traffic 189 flow specifications in BGP deployed network. However, in the BGP/ 190 MPLS VPN scenario, the IGP (e.g., IS-IS, or OSPF) is used between the 191 PE (Provider Edge) and CE (Customer Edge) in many deployments. In 192 order to distribute the FlowSpec routes to the customer network, the 193 IGP needs to support FlowSpec route distribution. The FlowSpec 194 routes are usually generated by the traffic analyzer or the traffic 195 policy center in the network. Depending on the location of the 196 traffic analyzer deployment, two different distribution scenarios are 197 discussed below. 199 3.2.1. Traffic Analyzer Deployed in Provider Network 201 The traffic analyzer (also acting as the traffic policy center) could 202 be deployed in the provider network as shown in Figure 1. If the 203 traffic analyzer detects attack traffic from the customer network 204 VPN1, it would generate the FlowSpec routes for preventing DoS 205 attacks. FlowSpec routes with a Route Distinguisher (RD) in the 206 Network Layer Reachability information (NRLI) corresponding to VPN1 207 are distributed from the traffic analyzer to the PE1 to which the 208 traffic analyzer is attached. If the traffic analyzer is also a BGP 209 speaker, it can distribute the FlowSpec routes using BGP [RFC5575]. 210 Then the PE1 distributes the FlowSpec routes further to the PE2. 211 Finally, the FlowSpec routes need to be distributed from PE2 to the 212 CE2 using OSPF, i.e., to the customer network VPN1. As an attacker 213 is more likely in the customer network, FlowSpec routes installed 214 directly on CE2 could mitigate the impact of DoS attacks better. 216 +--------+ 217 |Traffic | 218 +---+Analyzer| ----------- 219 | +--------+ //- -\\ 220 | /// \\\ 221 |FlowSpec / \ 222 | // \\ 223 | | | 224 +--+--+ +-----+ | +-----+ +--------+ | 225 | PE1 +-------+ PE2 +-------+--+ CE2 +-------+Attacker| | 226 +-----+ +-----+ | +-----+ +--------+ | 227 | | 228 | | | | | | 229 | BGP FlowSpec | OSPF FlowSpec | Attack Traffic| | 230 | | \\ | | // 231 \ / 232 \\\ VPN1 /// 233 \\-- --// 234 --------- 236 Figure 1: Traffic Analyzer deployed in Provider Network 238 3.2.2. Traffic Analyzer Deployed in Customer Network 240 The traffic analyzer (also acting as the traffic policy center) could 241 be deployed in the customer network as shown in Figure 2. If the 242 traffic analyzer detects attack traffic, it would generate FlowSpec 243 routes to prevent associated DoS attacks. Then the FlowSpec routes 244 would be distributed from the traffic analyzer to the CE1 using OSPF 245 or another policy protocol (e.g., RESTful API over HTTP). 246 Furthermore, the FlowSpec routes need to be distributed throughout 247 the provider network via PE1/PE2 to CE2, i.e., to the remote customer 248 network VPN1 Site1. If the FlowSpec routes installed on the CE2, it 249 could block the attack traffic as close to the source of the attack 250 as possible. 252 +--------+ 253 |Traffic | 254 +---+Analyzer| 255 | +--------+ -------- 256 | //-- --\\ 257 |FlowSpec // \\ 258 | / \ 259 | // \\ 260 +--+--+ +-----+ +-----+ | +-----+ +--------+ 261 | CE1 +--------+ PE1 +-------+ PE2 +--------+-+ CE2 +------+Attacker| 262 +-----+ +-----+ +-----+ | +-----+ +--------+ 263 | | 264 | | | | | | 265 | OSPF FlowSpec | BGP FlowSpec| OSPF FlowSpec | Attack Traffic | 266 | | | | | | 267 | | 268 \\ // 269 \ VPN1 Site1 / 270 \\ // 271 \\-- --// 272 -------- 274 Figure 2: Traffic Analyzer deployed in Customer Network 276 3.2.3. Policy Configuration 278 The CE or PE could deploy local filtering policies to filter OSPF 279 FlowSpec rules, for example, deploying a filtering policy to filter 280 the incoming OSPF FlowSpec rules in order to prevent illegal or 281 invalid FlowSpec rules from being applied. 283 The PE should configure FlowSpec importing policies to control 284 importing action between the BGP IP/VPN FlowSpec RIB and the OSPF 285 Instance FlowSpec RIB. Otherwise, the PE couldn't transform a BGP 286 IP/VPN FlowSpec rule to an OSPF FlowSpec rule or transform an OSPF 287 FlowSpec rule to a BGP IP/VPN FlowSpec rule. 289 4. OSPF Extensions for FlowSpec Rules 291 4.1. FlowSpec LSA 293 4.1.1. OSPFv2 FlowSpec Opaque LSA 295 This document defines a new OSPFv2 flow specification Opaque Link 296 State Advertisement (LSA) encoding format that can be used to 297 distribute traffic flow specifications. This new OSPF FlowSpec 298 Opaque LSA is extended based on [RFC5250]. 300 The OSPFv2 FlowSpec Opaque LSA is defined below in Figure 4: 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 | LS Age | Options | LS Type | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Opaque Type | Opaque ID | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Advertising Router | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | LS sequence number | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | LS checksum | Length | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | | 316 + + 317 | TLVs | 318 + + 319 | ... | 321 Figure 4: OSPFv2 FlowSpec Opaque LSA 323 LS age: the same as defined in [RFC2328]. 325 Options: the same as defined in [RFC2328]. 327 LS type: A type-11 or type-10 Opaque-LSA SHOULD be originated. 328 Since the type-11 LSA has the same flooding scope as a type-5 LSA 329 as stated in [RFC5250], it will not be flooded into stub areas or 330 NSSAs (Not-So-Stubby Areas). When stub or NSSA areas are 331 encountered in the scenario of flow spec, we may have to make our 332 choice, either making peace with it and filtering the DoS traffic 333 at ABRs or generating a new type-10 Opaque-LSA into stub/NSSA 334 areas, which may aggravate the burden of devices in that area. 336 Opaque type: OSPF FlowSpec Opaque LSA (Type Code: TBD1). 338 Opaque ID: the same as defined in [RFC5250]. 340 Advertising Router: the same as defined in [RFC2328]. 342 LS sequence number: the same as defined in [RFC2328]. 344 LS checksum: the same as defined in [RFC2328]. 346 Length: the same as defined in [RFC2328]. 348 TLVs: one or more TLVs MAY be included in a FlowSpec Opaque LSA to 349 carry FlowSpec information. 351 The variable TLVs section consists of one or more nested Type/Length/ 352 Value (TLV) tuples. Nested TLVs are also referred to as sub-TLVs. 353 The format of each TLV is shown in Figure 5: 355 0 1 2 3 356 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 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Type | Length | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Values... | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 Figure 5: TLV Format 365 The Length field defines the length of the value portion in octets 366 (thus a TLV with no value portion would have a length of 0). The TLV 367 is padded to 4-octet alignment; padding is not included in the length 368 field (so a 3-octet value would have a length of 3, but the total 369 size of the TLV would be 8 octets). Nested TLVs are also 32-bit 370 aligned. For example, a 1-octet value would have the length field 371 set to 1, and 3 octets of padding would be added to the end of the 372 value portion of the TLV. 374 If FlowSpec Opaque LSA is Type-11 Opaque LSA, it is not flooded into 375 Stub and NSSA areas. As the traffic accessing a network segment 376 outside Stub and NSSA areas would be aggregated to the ABR, FlowSpec 377 rules could be applied on the ABR instead of disseminating them into 378 Stub and NSSA areas. 380 4.1.2. OSPFv3 FlowSpec LSA 382 This document defines a new OSPFv3 flow specification LSA encoding 383 format that can be used to distribute traffic flow specifications. 384 This new OSPFv3 FlowSpec LSA is extended based on [RFC5340]. 386 The OSPFv3 FlowSpec LSA is defined below in Figure 6: 388 0 1 2 3 389 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 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | LS Age | LS Type | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Link State ID | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | Advertising Router | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | LS sequence number | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | LS checksum | Length | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | | 402 + + 403 | TLVs | 404 + + 405 | ... | 407 Figure 6: OSPFv3 FlowSpec LSA 409 LS age: the same as defined in [RFC5340]. 411 LS type: the same as defined in [RFC5340]. The format of the LS 412 type is as follows: 414 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 415 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 416 |U |S2|S1| LSA Function Code | 417 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 419 Figure 7: LSA Type 421 In this document, the U bit should be set indicating that the 422 OSPFv3 FlowSpec LSA should be flooded even if it is not 423 understood. For the area scope, the S1 bit should be set and the 424 S2 should be clear. For the AS scope, the S1 bit should be clear 425 and the S2 bit should be set. A new LSA Function Code (TBD2) 426 needs to be defined for OSPFv3 FlowSpec LSA. To facilitate inter- 427 area reachability validation, any OSPFv3 router originating AS 428 scoped LSAs is considered an AS Boundary Router (ASBR). 430 Link State ID: the same as defined in [RFC5340]. 432 Advertising Router: the same as defined in [RFC5340]. 434 LS sequence number: the same as defined in [RFC5340]. 436 LS checksum: the same as defined in [RFC5340]. 438 Length: the same as defined in [RFC5340]. 440 TLVs: one or more TLVs MAY be included in a OSPFv3 FlowSpec LSA to 441 carry FlowSpec information. 443 4.2. OSPF FlowSpec Filters TLV 445 The FlowSpec Opaque LSA carries one or more FlowSpec Filters TLVs and 446 corresponding FlowSpec Action TLVs. The OSPF FlowSpec Filters TLV is 447 defined below in Figure 8. 449 0 1 2 3 450 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 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Type | Length | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Flags | Filters (variable) ~ 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 ~ Filters (variable) ~ 457 + + 458 | ... | 460 Figure 8: OSPF FlowSpec Filters TLV 462 Type: the TLV type (Type Code: TBD3) 464 Length: the size of the value field in octets 466 Flags: One octet Field identifying Flags. 468 0 1 2 3 4 5 6 7 469 +-+-+-+-+-+-+-+-+ 470 | Reserved |S| 471 +-+-+-+-+-+-+-+-+ 473 The least significant bit S is defined as a strict Filter check bit. 474 If set, Strict Validation rules outlined in the validation 475 Section 4.2.2 need to be enforced. 477 Filters: the same as "flow-spec NLRI value" defined in [RFC5575] and 478 [I-D.ietf-idr-flow-spec-v6]. 480 Table 1: OSPF Supported FlowSpec Filters 481 +------+------------------------+------------------------------+ 482 | Type | Description | RFC/ WG draft | 483 +------+------------------------+------------------------------+ 484 | 1 | Destination IPv4 Prefix| RFC5575 | 485 | | Destination IPv6 Prefix| I-D.ietf-idr-flow-spec-v6 | 486 +------+------------------------+------------------------------+ 487 | 2 | Source IPv4 Prefix | RFC5575 | 488 | | Source IPv6 Prefix | I-D.ietf-idr-flow-spec-v6 | 489 +------+------------------------+------------------------------+ 490 | 3 | IP Protocol | RFC5575 | 491 | | Next Header | I-D.ietf-idr-flow-spec-v6 | 492 +------+------------------------+------------------------------+ 493 | 4 | Port | RFC5575 | 494 +------+------------------------+------------------------------+ 495 | 5 | Destination port | RFC5575 | 496 +------+------------------------+------------------------------+ 497 | 6 | Source port | RFC5575 | 498 +------+------------------------+------------------------------+ 499 | 7 | ICMP type | RFC5575 | 500 +------+------------------------+------------------------------+ 501 | 8 | ICMP code | RFC5575 | 502 +------+------------------------+------------------------------+ 503 | 9 | TCP flags | RFC5575 | 504 +------+------------------------+------------------------------+ 505 | 10 | Packet length | RFC5575 | 506 +------+------------------------+------------------------------+ 507 | 11 | DSCP | RFC5575 | 508 +------+------------------------+------------------------------+ 509 | 12 | Fragment | RFC5575 | 510 +------+------------------------+------------------------------+ 511 | 13 | Flow Label | I-D.ietf-idr-flow-spec-v6 | 512 +------+------------------------+------------------------------+ 513 | 14 | Interface-Set | Described Below | 514 +------+------------------------+------------------------------+ 516 4.2.1. Interface-Set TLV 518 The Interface-Set TLV is used to limit the FlowSpec rules to a set of 519 interfaces configured locally with the specified Group ID. The 520 Interface-Set TLV was inspired by 522 [I-D.litkowski-idr-flowspec-interfaceset] and uses similar encodings. 523 The Autonomous System (AS) number is not required since OSPF usage is 524 within a single AS. 526 The Interface-Set TLV is encoded as: 528 0 1 2 3 529 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 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | TBD, 14 Suggested | 4 | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 |O|I| Flags | Group ID | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 O : if set, the flow specification rule MUST be applied in outbound 537 direction to the interface set referenced by the specified Group ID. 539 I : if set, the flow specification rule MUST be applied in input 540 direction to the interface set referenced by the specified Group ID 542 Both flags can be set at the same time in the interface-set extended 543 community leading to flow rule to be applied in both directions. An 544 interface-set TLV with both flags set to zero MUST be treated as an 545 error and as consequence, the FlowSpec update MUST be ignore and an 546 error should be logged. 548 The Group Identifier is coded as a 16-bit number (values goes from 0 549 to 65535). 551 Multiple instances of the interface-set community may be present in a 552 Flow-Spec rule. This may appear if the flow rule need to be applied 553 to multiple set of interfaces. 555 4.2.2. Order of Traffic Filtering Rules 557 With traffic filtering rules, more than one rule may match a 558 particular traffic flow. The order of applying the traffic filter 559 rules is the same as described in Section 5.1 of [RFC5575] and in 560 Section 3.1 of [I-D.ietf-idr-flow-spec-v6]. 562 4.2.3. Validation Procedure 564 [RFC5575] defines a validation procedure for BGP FlowSpec rules, and 565 [I-D.ietf-idr-bgp-flowspec-oid] describes a modification to the 566 validation procedure defined in [RFC5575] for the dissemination of 567 BGP flow specifications. The OSPF FlowSpec should support similar 568 features to mitigate the unnecessary application of traffic filter 569 rules. The OSPF FlowSpec validation procedure is described as 570 follows. 572 When a router receives a FlowSpec rule including a destination prefix 573 filter from its neighbor router, it should consider the prefix filter 574 as a valid filter unless the S bit in the flags field of Filter TLV 575 is set. If the S bit is set, then the FlowSpec rule is considered 576 valid if and only if: 578 The originator of the FlowSpec rule matches the originator of the 579 best-match unicast route for the destination prefix embedded in 580 the FlowSpec. 582 The former rule allows any centralized controller to originate the 583 prefix filter and advertise it within a given OSPF network. The 584 latter rule, also known as a Strict Validation rule, allows strict 585 checking and enforces that the originator of the FlowSpec filter is 586 also the originator of the destination prefix. 588 When multiple equal-cost paths exist in the routing table entry, each 589 path could end up having a separate set of FlowSpec rules. 591 When a router receives a FlowSpec rule not including a destination 592 prefix filter from its neighbor router, the validation procedure 593 described above is not applicable. 595 The FlowSpec filter validation state is used by a speaker when the 596 filter is considered for an installation in its FIB. An OSPF speaker 597 MUST flood OSPF FlowSpec LSA as per the rules defined in [RFC2328] 598 regardless of the validation state of the prefix filters. 600 4.3. OSPF FlowSpec Action TLV 602 There are one or more FlowSpec Action TLVs associated with a FlowSpec 603 Filters TLV. Different FlowSpec Filters TLV could have the same 604 FlowSpec Action TLVs. The following OSPF FlowSpec action TLVs, 605 except Redirect, are same as defined in [RFC5575]. 607 Redirect: IPv4 or IPv6 address. This IP address may correspond to a 608 tunnel, i.e., the redirect allows the traffic to be redirected to a 609 directly attached next-hop or a next-hop requiring a route lookup. 611 Table 2: Traffic Filtering Actions in [RFC5575], etc. 612 +-------+-----------------+---------------------------------------+ 613 | type | FlowSpec Action | RFC/WG draft | 614 +-------+-----------------+---------------------------------------+ 615 | 0x8006| traffic-rate | RFC5575 | 616 | | | | 617 | 0x8007| traffic-action | RFC5575 | 618 | | | | 619 | 0x8108| redirect-to-IPv4| I-D.ietf-idr-flowspec-redirect-rt-bis | 620 | | | 621 | 0x800b| redirect-to-IPv6| I-D.ietf-idr-flow-spec-v6 | 622 | | | | 623 | 0x8009| traffic-marking | RFC5575 | 624 +-------+-----------------+---------------------------------------+ 626 4.3.1. Traffic-rate 628 Traffic-rate TLV is encoded as: 630 0 1 2 3 631 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 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 | TBD5,0x8006 suggested | 4 | 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 | Traffic-rate | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 Traffic-rate: the same as defined in [RFC5575]. 640 4.3.2. Traffic-action 642 Traffic-action TLV is encoded as: 644 0 1 2 3 645 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 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | TBD6, 0x8007 suggested | 2 | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | Reserved |S|T| | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 S flag and T flag: the same as defined in [RFC5575]. 654 4.3.3. Traffic-marking 656 Traffic-marking TLV is encoded as: 658 0 1 2 3 659 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 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | TBD7, 0x8009 suggested | 2 | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | Reserved | DSCP Value| | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 DSCP value: the same as defined in [RFC5575]. 668 4.3.4. Redirect-to-IP 670 Redirect-to-IPv4 is encoded as: 672 0 1 2 3 673 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 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 | TBD8, 0x8108 suggested | 6 | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | IPv4 Address | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | Reserved |C| | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 Redirect to IPv6 TLV is encoded as (Only for OSPFv3): 684 0 1 2 3 685 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 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | TBD9, 0x800b suggested | 18 | 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | | 690 | IPv6 Address | 691 | | 692 | | 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 | Reserved |C| | 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 IPv4/6 Address: the redirection target address. 699 'C' (or copy) bit: when the 'C' bit is set, the redirection applies 700 to copies of the matching packets and not to the original traffic 701 stream [I-D.ietf-idr-flowspec-redirect-ip]. 703 4.4. Capability Advertisement 705 This document defines a capability bit for OSPF Router-Information 706 LSA [RFC7770] as FlowSpec Capability Advertisement bit. When set, 707 the OSPF router indicates its ability to support the FlowSpec 708 functionality. The FlowSpec Capability Advertisement bit has a value 709 to be assigned by IANA from OSPF Router Functional Capability Bits 710 Registry [I-D.ietf-ospf-rfc4970bis]. 712 5. Redistribution of FlowSpec Routes 714 In certain scenarios, FlowSpec routes MAY get redistributed from one 715 protocol domain to another; specifically from BGP to OSPF and vice- 716 versa. When redistributed from BGP, the OSPF speaker SHOULD generate 717 an Opaque LSA for the redistributed routes and announce it within an 718 OSPF domain. An implementation MAY provide an option for an OSPF 719 speaker to announce a redistributed FlowSpec route within a OSPF 720 domain regardless of being installed in its local FIB. An 721 implementation MAY impose an upper bound on number of FlowSpec routes 722 that an OSPF router MAY advertise. 724 6. IANA Considerations 726 This document defines a new OSPFv2 Opaque LSA, i.e., OSPFv2 FlowSpec 727 Opaque LSA (Type Code: TBD1), which is used to distribute traffic 728 flow specifications. 730 This document defines a new OSPFv3 LSA, i.e., OSPFv3 FlowSpec LSA 731 (LSA Function Code: TBD2), which is used to distribute traffic flow 732 specifications. 734 This document defines OSPF FlowSpec Filters TLV (Type Code: TBD3), 735 which is used to describe the filters. 737 This document defines a new FlowSpec capability which need to be 738 advertised in an RI Opaque LSA. A new informational capability bit 739 needs to be assigned for OSPF FlowSpec feature (FlowSpec Bit: TBD4). 741 This document defines a new Router LSA bit known as a FlowSpec 742 Capability Advertisement bit. This document requests IANA to assign 743 a bit code type for FlowSpec Capability Advertisement bit from the 744 OSPF Router Functional Capability Bits registry. 746 Type 1 - Destination IPv4/IPv6 Prefix 747 Type 2 - Source IPv4/IPv6 Prefix 748 Type 3 - IP Protocol/Next Header 749 Type 4 - Port 750 Type 5 - Destination port 751 Type 6 - Source port 752 Type 7 - ICMP type 753 Type 8 - ICMP code 754 Type 9 - TCP flags 755 Type 10 - Packet length 756 Type 11 - DSCP 757 Type 12 - Fragment 758 Type 13 - Flow Label 759 Type 14 - Interface-Set 761 This document defines a group of FlowSpec actions. The following TLV 762 types need to be assigned: 764 Type 0x8006(TBD5) - traffic-rate 765 Type 0x8007(TBD6) - traffic-action 766 Type 0x8009(TBD7) - traffic-marking 767 Type 0x8108(TBD8) - redirect to IPv4 768 Type 0x800b(TBD9) - redirect to IPv6 770 7. Security considerations 772 This extension to OSPF does not change the underlying security issues 773 inherent in the existing OSPF. Implementations must assure that 774 malformed TLV and Sub-TLV permutations do not result in errors which 775 cause hard OSPF failures. 777 8. Acknowledgement 779 The authors would also like to thank Burjiz Pithawala, Rashmi 780 Shrivastava and Mike Dubrovsky for their contribution to the original 781 version of the document. 783 9. References 785 9.1. Normative References 787 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 788 Requirement Levels", BCP 14, RFC 2119, 789 DOI 10.17487/RFC2119, March 1997, 790 . 792 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 793 DOI 10.17487/RFC2328, April 1998, 794 . 796 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 797 OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250, 798 July 2008, . 800 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 801 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 802 . 804 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 805 and D. McPherson, "Dissemination of Flow Specification 806 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 807 . 809 9.2. Informative References 811 [I-D.ietf-idr-bgp-flowspec-oid] 812 Uttaro, J., Filsfils, C., Smith, D., Alcaide, J., and P. 813 Mohapatra, "Revised Validation Procedure for BGP Flow 814 Specifications", draft-ietf-idr-bgp-flowspec-oid-03 (work 815 in progress), March 2016. 817 [I-D.ietf-idr-flow-spec-v6] 818 McPherson, D., Raszuk, R., Pithawala, B., Andy, A., and S. 819 Hares, "Dissemination of Flow Specification Rules for 820 IPv6", draft-ietf-idr-flow-spec-v6-07 (work in progress), 821 March 2016. 823 [I-D.ietf-idr-flowspec-redirect-ip] 824 Uttaro, J., Haas, J., Texier, M., Andy, A., Ray, S., 825 Simpson, A., and W. Henderickx, "BGP Flow-Spec Redirect to 826 IP Action", draft-ietf-idr-flowspec-redirect-ip-02 (work 827 in progress), February 2015. 829 [I-D.litkowski-idr-flowspec-interfaceset] 830 Litkowski, S., Simpson, A., Patel, K., and J. Haas, 831 "Applying BGP flowspec rules on a specific interface set", 832 draft-litkowski-idr-flowspec-interfaceset-03 (work in 833 progress), December 2015. 835 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 836 S. Shaffer, "Extensions to OSPF for Advertising Optional 837 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 838 February 2016, . 840 Authors' Addresses 842 Qiandeng Liang 843 Huawei 844 101 Software Avenue, Yuhuatai District 845 Nanjing, 210012 846 China 848 Email: liangqiandeng@huawei.com 850 Jianjie You 851 Huawei 852 101 Software Avenue, Yuhuatai District 853 Nanjing, 210012 854 China 856 Email: youjianjie@huawei.com 858 Nan Wu 859 Huawei 861 Email: eric.wu@huawei.com 863 Peng Fan 864 Independent 866 Email: peng.fan@139.com 868 Keyur Patel 869 Cisco Systems 870 170 W. Tasman Drive 871 San Jose, CA 95134 872 USA 874 Email: keyupate@cisco.com 876 Acee Lindem 877 Cisco Systems 878 301 Midenhall Way 879 Cary, NC 27519 880 USA 882 Email: acee@cisco.com