idnits 2.17.1 draft-ietf-ospf-prefix-hiding-03.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 24 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 13 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 1, 2012) is 4378 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'OSPFV3' is mentioned on line 384, but not defined == Unused Reference: 'NSSA' is defined on line 465, but no explicit reference was found in the text == Unused Reference: 'RFC5837' is defined on line 479, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OSPF Working Group Y. Yang 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track A. Retana 5 Expires: November 2, 2012 Hewlett-Packard Co. 6 A. Roy 7 Cisco Systems 8 May 1, 2012 10 Hiding Transit-only Networks in OSPF 11 13 Abstract 15 A transit-only network is defined as a network connecting routers 16 only. In OSPF, transit-only networks are usually configured with 17 routable IP addresses, which are advertised in Link State 18 Advertisements (LSAs) but not needed for data traffic. In addition, 19 remote attacks can be launched against routers by sending packets to 20 these transit-only networks. This document presents a mechanism to 21 hide transit-only networks to speed up network convergence and 22 minimize remote attack vulnerability. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on November 2, 2012. 41 Copyright Notice 43 Copyright (c) 2010 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Requirements notation . . . . . . . . . . . . . . . . . . . 3 60 2. Hiding IPv4 Transit-only Networks in OSPFv2 . . . . . . . . . . 4 61 2.1. Point-to-Point Networks . . . . . . . . . . . . . . . . . . 4 62 2.1.1. Advertising Point-to-Point Networks . . . . . . . . . 4 63 2.1.2. Hiding Point-to-Point Networks . . . . . . . . . . . . 5 64 2.2. Broadcast Networks . . . . . . . . . . . . . . . . . . . . 5 65 2.2.1. Advertising Broadcast Networks . . . . . . . . . . . . 5 66 2.2.2. Hiding Broadcast Networks . . . . . . . . . . . . . . 6 67 2.2.2.1. Sending Network-LSA . . . . . . . . . . . . . . . 6 68 2.2.2.2. Receiving Network-LSA . . . . . . . . . . . . . . 6 69 2.2.2.2.1. Backward Compatibility . . . . . . . . . . . 6 70 2.3. Non-Broadcast Networks . . . . . . . . . . . . . . . . . . 7 71 2.3.1. NBMA . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 2.3.2. Point-to-MultiPoint . . . . . . . . . . . . . . . . . 7 73 2.3.2.1. Advertising Point-to-MultiPoint Networks . . . . 8 74 2.3.2.2. Hiding Point-to-MultiPoint Networks . . . . . . . 8 75 3. Hiding IPv6 Transit-only Networks in OSPFv3 . . . . . . . . . . 9 76 4. Hiding AF Enabled Transit-only Networks in OSPFv3 . . . . . . . 9 77 5. Forwarding Address . . . . . . . . . . . . . . . . . . . . . . 10 78 6. Virtual Links . . . . . . . . . . . . . . . . . . . . . . . . 10 79 7. Operational Considerations . . . . . . . . . . . . . . . . . . 10 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 82 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 85 11.2. Informative References . . . . . . . . . . . . . . . . . 12 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 88 1. Introduction 90 A transit-only network is defined as a network connecting routers 91 only. In OSPF, transit-only networks are usually configured with 92 routable IP addresses, which are advertised in LSAs but not needed 93 for data traffic. In addition, remote attacks can be launched 94 against routers by sending packets to these transit-only networks. 95 This document presents a mechanism to hide transit-only networks to 96 speed up network convergence and minimize remote attack 97 vulnerability. 99 Hiding transit-only networks will not impact reachability to the end 100 hosts. 102 1.1. Requirements notation 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in [KEYWORD]. 107 2. Hiding IPv4 Transit-only Networks in OSPFv2 109 In [OSPFv2], networks are classified as point-to-point, broadcast, or 110 non-broadcast. In the following sections, we will review how these 111 OSPF networks are being advertised and discuss how to hide them 112 consequently. 114 2.1. Point-to-Point Networks 116 A point-to-point network joins a single pair of routers. Figure 1 117 shows a point-to-point network connecting routers RT1 and RT2. 119 +---+.1 10.1.1.0/30 .2+---+ 120 |RT1|---------------------------|RT2| 121 +---+ +---+ 123 Figure 1 Physical point-to-point network 125 2.1.1. Advertising Point-to-Point Networks 127 For each numbered point-to-point network, a router has 2 link 128 descriptions in its router-LSA, one Type 1 link (point-to-point) 129 regarding the neighboring router, and one Type 3 link (stub) 130 regarding the assigned IPv4 address. 132 An example of router-LSA originated by RT1 would look like 134 LS age = 0 ;newly (re)originated 135 LS type = 1 ;router-LSA 136 Link State ID = 1.1.1.1 ;RT1's Router ID 137 Advertising Router = 1.1.1.1 ;RT1's Router ID 138 #links = 2 139 Link ID = 2.2.2.2 ;RT2's Router ID 140 Link Data = 10.1.1.1 ;Interface IP address 141 Type = 1 ;connects to RT2 142 Metric = 10 144 Link ID= 10.1.1.0 ;IP network/subnet number 145 Link Data = 255.255.255.252 ;Subnet's mask 146 Type = 3 ;Connects to stub network 147 Metric = 10 149 The Type 1 link will be used for SPF calculation while the Type 3 150 link will be used for Routing Information Base (RIB) installation. 152 2.1.2. Hiding Point-to-Point Networks 154 To hide a transit-only point-to-point network, the Type 3 link MUST 155 be omitted from the router-LSA. 157 An example of router-LSA originated by RT1, hiding the point-to-point 158 network depicted in Figure 1, would look like 160 LS age = 0 ;newly (re)originated 161 LS type = 1 ;router-LSA 162 Link State ID = 1.1.1.1 ;RT1's Router ID 163 Advertising Router = 1.1.1.1 ;RT1's Router ID 164 #links = 1 165 Link ID = 2.2.2.2 ;RT2's Router ID 166 Link Data = 10.1.1.1 ;Interface IP address 167 Type = 1 ;connects to RT2 168 Metric = 10 170 2.2. Broadcast Networks 172 A broadcast networks joins many (more than two) routers, and supports 173 the capability to address a single physical message to all of the 174 attached routers. Figure 2 shows a broadcast network connecting 175 router RT3, RT4, and RT5. 177 +---+ +---+ 178 |RT3| |RT4| 179 +---+ +---+ 180 |.3 10.2.2.0/24 .4| 181 +---------------------------+ 182 |.5 183 +---+ 184 |RT5| 185 +---+ 187 Figure 2 Broadcast network 189 2.2.1. Advertising Broadcast Networks 191 For each broadcast network, a designated router (DR) describes it in 192 its network-LSA. Assuming RT3 is elected as the DR in Figure 2, an 193 example of the network-LSA originated by RT3 would look like 194 LS age = 0 ;newly (re)originated 195 LS type = 2 ;network-LSA 196 Link State ID = 10.2.2.3 ;IP address of the DR (RT3) 197 Advertising Router = 3.3.3.3 ;RT3's Router ID 198 Network Mask = 255.255.255.0 199 Attached Router = 3.3.3.3 ;Router ID 200 Attached Router = 4.4.4.4 ;Router ID 201 Attached Router = 5.5.5.5 ;Router ID 203 OSPF obtains the IP network number from the combination of the Link 204 State ID and the Network Mask. In addition, the Link State ID is 205 also being used for 2-way connectivity check. 207 2.2.2. Hiding Broadcast Networks 209 2.2.2.1. Sending Network-LSA 211 To hide a transit-only broadcast network, a special network mask 212 value 255.255.255.255 MUST be used in the network-LSA. While a 213 broadcast network connects more than routers, using 255.255.255.255 214 will not hide an access broadcast network accidentally. 216 As there is no change of the Link State ID, the 2-way connectivity 217 check would proceed normally. 219 An example of network-LSA originated by RT3, hiding the broadcast 220 network depicted in Figure 2, would look like 222 LS age = 0 ;newly (re)originated 223 LS type = 2 ;network-LSA 224 Link State ID = 10.2.2.3 ;IP address of the DR (RT3) 225 Advertising Router = 3.3.3.3 ;RT3's Router ID 226 Network Mask = 255.255.255.255 ;special subnet mask 227 Attached Router = 3.3.3.3 ;Router ID 228 Attached Router = 4.4.4.4 ;Router ID 229 Attached Router = 5.5.5.5 ;Router ID 231 2.2.2.2. Receiving Network-LSA 233 It's RECOMMENDED that all routers in an area be upgraded at the same 234 time to process the modified network-LSA correctly and consistently. 236 When a router receives a network-LSA, it MUST check the 2-way 237 connectivity as normal. However, if the network mask in the network- 238 LSA is 255.255.255.255, the router MUST NOT install the route in the 239 RIB. 241 2.2.2.2.1. Backward Compatibility 242 When a not-yet-upgraded router receives a modified network-LSA, as 243 specified in section 2.2.2.1, a host route to the originating DR will 244 be installed. This is not ideal but better than the current result, 245 which exposes the whole subnet. 247 In a partial deployment scenario, upgraded routers and not-yet- 248 upgraded routers may coexist. The former do not have the host routes 249 aforementioned, while the latter do have. Such inconsistencies 250 create routing black holes, which should normally be avoided. In 251 this case, however, as packets destined for the transit-only networks 252 are dropped somewhere in the network, the black holes actually help 253 DRs defend from the remote attacks. 255 In summary, the modification of the network-LSA, as specified in 256 section 2.2.2.1, is backward compatible with the current 257 specification of [OSPFv2], even in a partial deployment scenario. 259 2.3. Non-Broadcast Networks 261 A non-broadcast networks joins many (more than two) routers, but does 262 NOT support the capability to address a single physical message to 263 all of the attached routers. As mentioned in [OSPFv2], OSPF runs in 264 one of two modes over non-broadcast networks: Non-Broadcast Multi- 265 Access (NBMA) or Point-to-MultiPoint. 267 2.3.1. NBMA 269 In NBMA mode, OSPF emulates operation over a broadcast network: a 270 Designated Router is elected for the NBMA network, and the Designated 271 Router originates an LSA for the network. 273 To hide a NBMA transit-only network, OSPF adopts the same 274 modification over the broadcast transit-only network, as defined in 275 section 2.2.2. 277 2.3.2. Point-to-MultiPoint 279 In point-to-MultiPoint mode, OSPF treats the non-broadcast network as 280 a collection of point-to-point links. 282 Figure 3 shows a non-broadcast network connecting router RT6, RT7, 283 RT8, and RT9. In this network, all routers can communicate directly, 284 except for routers RT7 and RT8. 286 +---+ +---+ 287 |RT6| |RT7| 288 +---+ +---+ 289 |.6 10.3.3.0/24 .7| 290 +---------------------------+ 291 |.8 .9| 292 +---+ +---+ 293 |RT8| |RT9| 294 +---+ +---+ 296 Figure 3 Non-Broadcast network 298 2.3.2.1. Advertising Point-to-MultiPoint Networks 300 For a point-to-multipoint network, a router has multiple link 301 descriptions in its router-LSA, one Type 1 link (point-to-point) for 302 EACH directly communicable router, and one Type 3 link (stub) 303 advertising its interface IPv4 address with a subnet mask of 304 255.255.255.255. 306 An example of router-LSA originated by RT7 would look like 308 LS age = 0 ;newly (re)originated 309 LS type = 1 ;router-LSA 310 Link State ID = 7.7.7.7 ;RT7's Router ID 311 Advertising Router = 7.7.7.7 ;RT7's Router ID 312 #links = 3 313 Link ID = 6.6.6.6 ;RT6's Router ID 314 Link Data = 10.3.3.7 ;Interface IP address 315 Type = 1 ;connects to RT6 316 Metric = 10 318 Link ID = 9.9.9.9 ;RT9's Router ID 319 Link Data = 10.3.3.7 ;Interface IP address 320 Type = 1 ;connects to RT9 321 Metric = 10 323 Link ID= 10.3.3.7 ;Interface IP address 324 Link Data = 255.255.255.255 ;Subnet's mask 325 Type = 3 ;Connects to stub network 326 Metric = 0 328 2.3.2.2. Hiding Point-to-MultiPoint Networks 330 To hide a transit-only point-to-multipoint network, the Type 3 331 link MUST be omitted from the router-LSA. 333 An example of router-LSA originated by RT7, hiding the point-to- 334 point network depicted in Figure 3, would look like 336 LS age = 0 ;newly (re)originated 337 LS type = 1 ;router-LSA 338 Link State ID = 7.7.7.7 ;RT7's Router ID 339 Advertising Router = 7.7.7.7 ;RT7's Router ID 340 #links = 2 341 Link ID = 6.6.6.6 ;RT6's Router ID 342 Link Data = 10.3.3.7 ;Interface IP address 343 Type = 1 ;connects to RT6 344 Metric = 10 346 Link ID = 9.9.9.9 ;RT9's Router ID 347 Link Data = 10.3.3.7 ;Interface IP address 348 Type = 1 ;connects to RT9 349 Metric = 10 351 3. Hiding IPv6 Transit-only Networks in OSPFv3 353 In [OSPFv3], addressing semantics have been removed from the OSPF 354 protocol packets and the main LSA types, leaving a network-protocol- 355 independent core. 357 More specifically, router-LSAs and network-LSAs no longer contain 358 network addresses, but simply express topology information. Instead, 359 two new LSA types, link-LSA and intra-area-prefix-LSA, have been 360 introduced. A link-LSA associates a list of IPv6 address to a link 361 and has local-link flooding scope, and an intra-area-prefix-LSA 362 either associates a list of IPv6 address with a router by referencing 363 a router-LSA, or associates a list of IPv6 address with a 364 broadcast/NBMA network by referencing a network-LSA. In the latter 365 case, the prefixes in the link-LSAs from adjacent neighbors are 366 copied into the intra-area-prefix-LSA by the Designated Router. 368 To hide a transit-only network in [OSPFv3], the associated IPv6 369 address prefixes MUST be omitted from the link-LSA. Consequently, 370 when a Designated Router builds an intra-area-prefix-LSA referencing 371 a network-LSA, these IPv6 address prefixes will be omitted. 373 In addition, when a router builds an intra-area-prefix-LSA that is 374 referencing a router-LSA, the associated IPv6 address prefixes of the 375 transit-only network MUST also be omitted from the intra-area-prefix- 376 LSA. 378 4. Hiding AF Enabled Transit-only Networks in OSPFv3 380 [OSPF-AF] supports multiple Address Families (AFs) by mapping each AF 381 to a separate Instance ID and OSPFv3 instance. 383 In the meantime, each prefix advertised in OSPFv3 has a prefix Length 384 field [OSPFV3], which facilitates advertising prefixes of different 385 lengths in different AFs. The existing LSAs defined in OSPFv3 are 386 used for prefix advertising and there is no need to define new LSAs. 388 In other words, as link-LSAs and intra-area-prefix-LSAs are still 389 being used, same method as explained in section 3 can be used to hide 390 those AF enabled transit-only networks as well. 392 5. Forwarding Address 394 Non-zero forwarding address can be advertised in As-external-LSAs and 395 NSSA-LSAs to achieve optimal routing to AS external routes. The 396 matching routing table entry of the forwarding address must exist to 397 facilitate the SPF calculation. 399 In other words, when prefix-hiding is configured on the next-hop 400 interface, the next-hop interface address MUST NOT be used as 401 forwarding address. 403 Consequently, sub-optimal routing to these AS external routes may 404 exist when prefix-hiding is configured. 406 6. Virtual Links 408 Virtual links are used to connect physically separate components of 409 the backbone. The virtual link's viability is determined by the 410 existence of an intra-area path between two endpoints. The matching 411 routing table entries of the endpoints must exist to ensure the 412 virtual link's operation. 414 In other words, if prefix-hiding is configured on an interface, the 415 virtual link endpoint MUST NOT use that interface's IP address as the 416 virtual interface's IP address. 418 7. Operational Considerations 420 By eliminating the ability to reach transit-only networks, the 421 ability to manage these interfaces may be reduced. In order to not 422 reduce the functionality and capability of the overall network, it is 423 recommended that extensions such as RFC5837 be also implemented. 425 8. Security Considerations 427 One motivation for this document is to reduce remote attack 428 vulnerability by hiding transit-only networks. The result should 429 then be that fewer OSPF core networks will be exposed to un- 430 authorized access. 432 While the steps described in this document are meant to be applied to 433 transit-only networks ONLY, they could be used to hide other networks 434 as well. It is expected that the same care that users put on the 435 configuration of other routing protocol parameters is used in the 436 configuration of this extension. 438 9. IANA Considerations 440 No actions are required from IANA as result of the publication of 441 this document. 443 10. Acknowledgments 445 The draft text was produced using Stefan Santesson's NroffEdit 446 application. 448 The idea of using a special subnet mask to hide broadcast networks in 449 OSPF was originally introduced in the US patent "Apparatus and method 450 to hide transit only multi-access networks in OSPF" (patent number: 451 7,929,524), by Yi Yang, Alvaro Retana, James Ng, Abhay Roy, Alfred 452 Lindem, Sina Mirtorabi, Timothy Gage, and Khalid Raza. 454 The authors would like to thank Acee Lindem, Shraddha Hegde, Rajesh 455 Shetty, Marek Karasek, Michael Barnes, and Paull Wells, for their 456 feedback on the document. 458 11. References 460 11.1. Normative References 462 [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate 463 Requirement Levels", BCP 14, RFC 2119, March 1997. 465 [NSSA] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", 466 RFC 3101, January 2003. 468 [OSPFv2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 470 [OSPFv3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem , "OSPF 471 for IPv6", RFC 5340, July 2008. 473 [OSPF-AF] Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. 474 Aggarwal, "Support of Address Families in OSPFv3", 475 RFC5838, April 2010. 477 11.2. Informative References 479 [RFC5837] Atlas, A., Bonica, R., Pignataro, C., Shen, N., and JR. 480 Rivers, "Extending ICMP for Interface and Next-Hop 481 Identification", RFC5837, April 2010. 483 Authors' Addresses 485 Yi Yang 486 Cisco Systems 487 7025 Kit Creek Road 488 RTP, NC 27709 489 USA 491 Email: yiya@cisco.com 493 Alvaro Retana 494 Hewlett-Packard Co. 495 2610 Wycliff Road 496 Raleigh, NC 27607 497 USA 499 Email: alvaro.retana@hp.com 501 Abhay Roy 502 Cisco Systems 503 225 West Tasman Drive 504 San Jose, CA 95134 505 USA 507 Email: akr@cisco.com