idnits 2.17.1 draft-liang-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 : ---------------------------------------------------------------------------- ** There are 8 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 (September 27, 2014) is 3496 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) == Unused Reference: 'RFC4760' is defined on line 472, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4970 (Obsoleted by RFC 7770) ** Obsolete normative reference: RFC 5575 (Obsoleted by RFC 8955) Summary: 3 errors (**), 0 flaws (~~), 2 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 Huawei 5 Expires: March 31, 2015 September 27, 2014 7 OSPF Extensions for Flow Specification 8 draft-liang-ospf-flowspec-extensions-01 10 Abstract 12 This document discusses the use cases why OSPF (Open Shortest Path 13 First) distributing flow specification (FlowSpec) routes is 14 necessary. This document also defines a new OSPF FlowSpec Opaque 15 Link State Advertisement (LSA) encoding format that can be used to 16 distribute FlowSpec routes. 18 For the network only deploying IGP (Interior Gateway Protocol) (e.g. 19 OSPF), it is expected to extend IGP to distribute FlowSpec routes. 20 One advantage is to mitigate the impacts of Denial-of-Service (DoS) 21 attacks. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in [RFC2119]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on March 31, 2015. 46 Copyright Notice 48 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Use Cases for OSPF based FlowSpec Distribution . . . . . . . 3 66 3.1. BGP/MPLS VPN . . . . . . . . . . . . . . . . . . . . . . 3 67 3.1.1. Traffic Analyzer Deployed in Provider Network . . . . 4 68 3.1.2. Traffic Analyzer Deployed in Customer Network . . . . 4 69 3.2. OSPF Campus Network . . . . . . . . . . . . . . . . . . . 5 70 4. OSPF Extensions for FlowSpec Routes . . . . . . . . . . . . . 6 71 4.1. OSPF FlowSpec Filters TLV . . . . . . . . . . . . . . . . 8 72 4.2. OSPF FlowSpec Action TLV . . . . . . . . . . . . . . . . 8 73 4.3. Capability Advertisement . . . . . . . . . . . . . . . . 9 74 4.4. Import-policy Extended Community . . . . . . . . . . . . 9 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 76 6. Security considerations . . . . . . . . . . . . . . . . . . . 10 77 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 11 78 8. Normative References . . . . . . . . . . . . . . . . . . . . 11 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 81 1. Introduction 83 [RFC5575] defines a new Border Gateway Protocol Network Layer 84 Reachability Information (BGP NLRI) encoding format that can be used 85 to distribute traffic flow specifications. One application of that 86 encoding format is to automate inter-domain coordination of traffic 87 filtering, such as what is required in order to mitigate 88 (distributed) denial-of-service attacks. [RFC5575] allows flow 89 specifications received from an external autonomous system to be 90 forwarded to a given BGP peer. However, in order to block the attack 91 traffic more effectively, it is better to distribute the BGP FlowSpec 92 routes to the customer network, which is much closer to the attacker. 94 For the network only deploying IGP (e.g. OSPF), it is expected to 95 extend IGP to distribute FlowSpec routes. This document discusses 96 the use cases why OSPF distributing FlowSpec routes is necessary. 97 This document also defines a new OSPF FlowSpec Opaque Link State 98 Advertisement (LSA) [RFC5250] encoding format that can be used to 99 distribute FlowSpec routes to the edge routers in the customer 100 network. This mechanism can be used to mitigate the impacts of DoS 101 attacks. 103 2. Terminology 105 This section contains definitions for terms used frequently 106 throughout this document. However, many additional definitions can 107 be found in [RFC5250] and [RFC5575]. 109 Flow Specification (FlowSpec): A flow specification is an n-tuple 110 consisting of several matching criteria that can be applied to IP 111 traffic, including filters and actions. Each FlowSpec consists of 112 a set of filters and a set of actions. 114 3. Use Cases for OSPF based FlowSpec Distribution 116 For the network only deploying IGP (e.g. OSPF), it is expected to 117 extend IGP (OSPF in this document) to distribute FlowSpec routes, 118 because when the FlowSpec routes are installed in the customer 119 network, it would be closer to the attacker than when they are 120 installed in the provider network. Consequently, the attack traffic 121 could be blocked or the suspicious traffic could be limited to a low 122 rate as early as possible. 124 The following sub-sections discuss the use cases for OSPF based 125 FlowSpec routes distribution. 127 3.1. BGP/MPLS VPN 129 [RFC5575] defines a BGP NLRI encoding format to distribute traffic 130 flow specifications in BGP deployed network. However in the BGP/MPLS 131 VPN scenario, the IGP (e.g. IS-IS, OSPF) is used between PE 132 (Provider Edge) and CE (Customer Edge) for many deployments. In 133 order to distribute the FlowSpec routes to the customer network, the 134 IGP needs to support the FlowSpec route distribution. The FlowSpec 135 routes are usually generated by the traffic analyzer or the traffic 136 policy center in the network. Depending on the location of the 137 traffic analyzer deployment, two different distribution scenarios 138 will be discussed below. 140 3.1.1. Traffic Analyzer Deployed in Provider Network 142 The traffic analyzer (also acting as the traffic policy center) could 143 be deployed in the provider network as shown in Figure 1. If the 144 traffic analyzer detects attack traffic from the customer network 145 VPN1, it would generate the FlowSpec routes for preventing DoS 146 attacks. The FlowSpec routes with a route distinguisher information 147 corresponding to VPN1 are distributed from the traffic analyzer to 148 the PE1 which the traffic analyzer is the attached to. If the 149 traffic analyzer is also a BGP speaker, it can distribute the 150 FlowSpec routes based on the BGP [RFC5575]. Then the PE1 distributes 151 the FlowSpec routes further to the PE2. Finally, the FlowSpec routes 152 need to be distributed from the PE2 to the CE2 based on OSPF, i.e. to 153 the customer network VPN1. As the attacker is more likely in the 154 customer network, if the FlowSpec routes installed on the CE2, it 155 could mitigate the impacts of DoS attacks better. 157 +--------+ 158 |Traffic | 159 +---+Analyzer| ----------- 160 | +--------+ //- -\\ 161 | /// \\\ 162 |FlowSpec / \ 163 | // \\ 164 | | | 165 +--+--+ +-----+ | +-----+ +--------+ | 166 | PE1 +-------+ PE2 +-------+--+ CE2 +-------+Attacker| | 167 +-----+ +-----+ | +-----+ +--------+ | 168 | | 169 | | | | | | 170 | BGP FlowSpec | OSPF FlowSpec | Attack Traffic| | 171 | | \\ | | // 172 \ / 173 \\\ VPN1 /// 174 \\-- --// 175 --------- 177 Figure 1: Traffic Analyzer deployed in Provider Network 179 3.1.2. Traffic Analyzer Deployed in Customer Network 181 The traffic analyzer (also acting as the traffic policy center) could 182 be deployed in the customer network as shown in Figure 2. If the 183 traffic analyzer detects attack traffic, it would generate FlowSpec 184 routes for preventing DoS attacks. Then the FlowSpec routes would be 185 distributed from the traffic analyzer to the CE1 based on OSPF or 186 other policy protocol (e.g. RESTful API over HTTP). Further, the 187 FlowSpec routes need to be distributed through the provider network 188 via the PE1/PE2 to the CE2, i.e. to the remote customer network VPN1 189 Site1. If the FlowSpec routes installed on the CE2, it could block 190 the attack traffic as close to the source of the attack as possible. 192 +--------+ 193 |Traffic | 194 +---+Analyzer| 195 | +--------+ -------- 196 | //-- --\\ 197 |FlowSpec // \\ 198 | / \ 199 | // \\ 200 +--+--+ +-----+ +-----+ | +-----+ +--------+ | 201 | CE1 +--------+ PE1 +-------+ PE2 +--------+-+ CE2 +-------+Attacker| | 202 +-----+ +-----+ +-----+ | +-----+ +--------+ | 203 | | 204 | | | | | | | 205 | OSPF FlowSpec | BGP FlowSpec| OSPF FlowSpec | Attack Traffic | | 206 | | | | | | | 207 | | 208 \\ // 209 \ VPN1 Site1 / 210 \\ // 211 \\-- --// 212 -------- 214 Figure 2: Traffic Analyzer deployed in Customer Network 216 3.2. OSPF Campus Network 218 For the network not deploying BGP, for example, the campus network 219 using OSPF, it is expected to extend OSPF to distribute FlowSpec 220 routes as shown in Figure 3. In this kind of network, the traffic 221 analyzer could be deploy with a router, then the FlowSpec routes from 222 the traffic analyzer need to be distributed to the other routers in 223 this domain based on OSPF. 225 +--------+ 226 |Traffic | 227 +---+Analyzer| 228 | +--------+ 229 | 230 |FlowSpec 231 | 232 | 233 +--+-------+ +----------+ +--------+ 234 | Router A +-----------+ Router B +--------+Attacker| 235 +----------+ +----------+ +--------+ 237 | | | 238 | OSPF FlowSpec | Attack Traffic | 239 | | | 241 Figure 3: OSPF Campus Network 243 4. OSPF Extensions for FlowSpec Routes 245 This document defines a new OSPF flow specification Opaque Link State 246 Advertisement (LSA) encoding format that can be used to distribute 247 traffic flow specifications. This new OSPF FlowSpec Opaque LSA is 248 extended based on [RFC5250]. 250 The FlowSpec Opaque LSA is defined below in Figure 4: 252 0 1 2 3 253 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 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | LS age | Options | LS type | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Opaque Type | Opaque ID | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | Advertising Router | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | LS sequence number | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | LS checksum | length | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | | 266 + + 267 | TLVs | 268 + + 269 | ... | 271 Figure 4: FlowSpec Opaque LSA 273 LS age: the same as defined in [RFC2328]. 275 Options: the same as defined in [RFC2328]. 277 Link-State Type: A value of 11 denotes that the LSA is flooded 278 throughout the Autonomous System (e.g., has the same scope as 279 type-5 LSAs). Opaque LSAs with AS-wide scope MUST NOT be flooded 280 into stub areas or NSSAs (Not-So-Stubby Areas) [RFC5250]. 282 Opaque type: OSPF FlowSpec Opaque LSA (Type Code: TBD1). 284 Opaque ID: the same as defined in [RFC5250]. 286 Advertising Router: the same as defined in [RFC2328]. 288 LS sequence number: the same as defined in [RFC2328]. 290 LS checksum: the same as defined in [RFC2328]. 292 Length: the same as defined in [RFC2328]. 294 TLVs: one or more TLVs MAY be included in a FlowSpec Opaque LSA to 295 carry FlowSpec information. 297 The variable TLVs section consists of one or more nested Type/Length/ 298 Value (TLV) tuples. Nested TLVs are also referred to as sub-TLVs. 299 The format of each TLV is shown in Figure 5: 301 0 1 2 3 302 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 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Type | Length | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Values... | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 Figure 5: TLV Format 311 The Length field defines the length of the value portion in octets 312 (thus a TLV with no value portion would have a length of 0). The TLV 313 is padded to 4-octet alignment; padding is not included in the length 314 field (so a 3-octet value would have a length of 3, but the total 315 size of the TLV would be 8 octets). Nested TLVs are also 32-bit 316 aligned. For example, a 1-byte value would have the length field set 317 to 1, and 3 octets of padding would be added to the end of the value 318 portion of the TLV. 320 4.1. OSPF FlowSpec Filters TLV 322 The FlowSpec Opaque LSA carries one or more FlowSpec Filters TLVs and 323 corresponding FlowSpec Action TLVs. OSPF FlowSpec Filters TLV is 324 defined below in Figure 6. 326 0 1 2 3 327 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 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Type | Length | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Filters (variable) | 332 + + 333 | ... | 335 Figure 6: OSPF FlowSpec Filters TLV 337 Type: the TLV type (Type Code: TBD2) 339 Length: the size of the value field (typically in bytes) 341 Filters: the same as "flow-spec NLRI value" defined in [RFC5575]. 343 4.2. OSPF FlowSpec Action TLV 345 There are one or more FlowSpec Action TLVs associated with a FlowSpec 346 Filters TLV. Meanwhile, different FlowSpec Filters TLV could have 347 the same FlowSpec Action TLV/s. The following OSPF FlowSpec action 348 TLVs are the same as defined in [RFC5575]. 350 Table 1: Traffic Filtering Actions in [RFC5575] 352 +-------+-----------------+---------------------------+ 353 | type | FlowSpec Action | encoding | 354 +-------+-----------------+---------------------------+ 355 | 0x8006| traffic-rate | 2-byte as#, 4-byte float | 356 | | | | 357 | 0x8007| traffic-action | bitmask | 358 | | | | 359 | 0x8008| redirect | 6-byte Route Target | 360 | | | | 361 | 0x8009| traffic-marking | DSCP value | 362 +-------+-----------------+---------------------------+ 364 4.3. Capability Advertisement 366 OSPF routers may use Router Information (RI) LSA [RFC4970] for OSPF 367 features advertisement and discovery. The FlowSpec route requires an 368 additional capability for the OSPF router. This capability needs to 369 be advertised to other routers in an AS. This FlowSpec capability 370 could be advertised in a RI Opaque LSA [RFC4970]. 372 The format of the OSPF Router Informational Capabilities TLV within 373 the body of an RI LSA is defined as follows: 375 0 1 2 3 376 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 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Type | Length | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Informational Capabilities | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 Figure 4: OSPF RI Capabilities TLV 385 The following informational capability bits are assigned: 387 Bit Capabilities 388 ----------------------------------- 389 6 (TBD3) OSPF FlowSpec 390 7-31 Unassigned (Standards Action) 392 4.4. Import-policy Extended Community 394 When FlowSpec routes are from the BGP protocol, these FlowSpec routes 395 need to be imported to the IGP protocol. This document defines a new 396 filtering policy that it standardizes as a BGP extended community 397 value [RFC4360]. This extended community is used to specify a 398 particular action, i.e. importing the FlowSpec routes to the IGP 399 protocol. Thus a new extended community attribute, i.e. import- 400 policy (Type Code: TBD4) is defined as follows: 402 +--------+---------------------+---------------------+ 403 | type | extended community | encoding | 404 +--------+---------------------+---------------------+ 405 | TBD4 | import-policy | IGP target | 406 +--------+---------------------+---------------------+ 408 The format of the import-policy extended community is defined as 409 follows. 411 0 1 2 3 412 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 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Type (TBD4, import-policy) | Protocol | Reserved | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Metric | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 Figure 5: Import-policy Extended Community 421 This import-policy extended community is with Type Field composed of 422 2 octets and Value Field composed of 6 octets. The Value Field 423 consists of two sub-fields: 425 Protocol: 1 octet, this sub-field defines the IGP Type, e.g. 1 for 426 OSPF, 2 for ISIS. 428 Metric: 4 octets, this sub-field represents the aggregate IGP or 429 TE path cost. 431 If this import-policy extended community is not present, BGP FlowSpec 432 routes should not be imported to the IGP FlowSpec routing table. 434 5. IANA Considerations 436 This document defines a new OSPF Opaque LSA, i.e. FlowSpec Opaque 437 LSA (Type Code: TBD1), which is used to distribute traffic flow 438 specifications. 440 This document defines OSPF FlowSpec Filters TLV (Type Code: TBD2), 441 which is used to describe the filters. 443 This document defines a new FlowSpec capability which need to be 444 advertised in an RI Opaque LSA. A new informational capability bit 445 needs to be assigned for OSPF FlowSpec feature (FlowSpec Bit: TBD3). 447 This document defines a new BGP extended community attribute, i.e. 448 import-policy (Type Code: TBD4), which is used to indicate whether 449 importing the FlowSpec routes to the IGP protocol or not. 451 6. Security considerations 453 This extension to OSPF does not change the underlying security issues 454 inherent in the existing OSPF. Implementations must assure that 455 malformed TLV and Sub-TLV permutations do not result in errors which 456 cause hard OSPF failures. 458 7. Acknowledgement 460 TBD. 462 8. Normative References 464 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 465 Requirement Levels", BCP 14, RFC 2119, March 1997. 467 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 469 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 470 Communities Attribute", RFC 4360, February 2006. 472 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 473 "Multiprotocol Extensions for BGP-4", RFC 4760, January 474 2007. 476 [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. 477 Shaffer, "Extensions to OSPF for Advertising Optional 478 Router Capabilities", RFC 4970, July 2007. 480 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 481 OSPF Opaque LSA Option", RFC 5250, July 2008. 483 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 484 and D. McPherson, "Dissemination of Flow Specification 485 Rules", RFC 5575, August 2009. 487 Authors' Addresses 489 Qiandeng Liang 490 Huawei 491 101 Software Avenue, Yuhuatai District 492 Nanjing, 210012 493 China 495 Email: liuweihang@huawei.com 497 Jianjie You 498 Huawei 499 101 Software Avenue, Yuhuatai District 500 Nanjing, 210012 501 China 503 Email: youjianjie@huawei.com