idnits 2.17.1 draft-ietf-ospf-prefix-hiding-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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2328, updated by this document, for RFC5378 checks: 1997-11-05) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 16, 2012) is 4302 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 4 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 Updates: 2328, 5340 (if approved) A. Retana 5 Intended status: Standards Track Hewlett-Packard Co. 6 Expires: January 17, 2013 A. Roy 7 Cisco Systems 8 July 16, 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 This document updates RFC 2328 and RFC 5340. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 17, 2013. 43 Copyright Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Requirements notation . . . . . . . . . . . . . . . . . . . 3 62 2. Hiding IPv4 Transit-only Networks in OSPFv2 . . . . . . . . . . 4 63 2.1. Point-to-Point Networks . . . . . . . . . . . . . . . . . . 4 64 2.1.1. Advertising Point-to-Point Networks . . . . . . . . . 4 65 2.1.2. Hiding Point-to-Point Networks . . . . . . . . . . . . 5 66 2.2. Broadcast Networks . . . . . . . . . . . . . . . . . . . . 5 67 2.2.1. Advertising Broadcast Networks . . . . . . . . . . . . 5 68 2.2.2. Hiding Broadcast Networks . . . . . . . . . . . . . . 6 69 2.2.2.1. Sending Network-LSA . . . . . . . . . . . . . . . 6 70 2.2.2.2. Receiving Network-LSA . . . . . . . . . . . . . . 6 71 2.2.2.2.1. Backward Compatibility . . . . . . . . . . . 6 72 2.3. Non-Broadcast Networks . . . . . . . . . . . . . . . . . . 7 73 2.3.1. NBMA . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 2.3.2. Point-to-MultiPoint . . . . . . . . . . . . . . . . . 7 75 2.3.2.1. Advertising Point-to-MultiPoint Networks . . . . 8 76 2.3.2.2. Hiding Point-to-MultiPoint Networks . . . . . . . 8 77 3. Hiding IPv6 Transit-only Networks in OSPFv3 . . . . . . . . . . 9 78 4. Hiding AF Enabled Transit-only Networks in OSPFv3 . . . . . . . 9 79 5. Forwarding Address . . . . . . . . . . . . . . . . . . . . . . 10 80 6. Virtual Links . . . . . . . . . . . . . . . . . . . . . . . . 10 81 7. Operational Considerations . . . . . . . . . . . . . . . . . . 10 82 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 83 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 84 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 85 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 86 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 87 11.2. Informative References . . . . . . . . . . . . . . . . . 12 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 90 1. Introduction 92 A transit-only network is defined as a network connecting routers 93 only. In OSPF, transit-only networks are usually configured with 94 routable IP addresses, which are advertised in LSAs but not needed 95 for data traffic. In addition, remote attacks can be launched 96 against routers by sending packets to these transit-only networks. 97 This document presents a mechanism to hide transit-only networks to 98 speed up network convergence and minimize remote attack 99 vulnerability. 101 Hiding transit-only networks will not impact reachability to the end 102 hosts. 104 1.1. Requirements notation 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [KEYWORD]. 109 2. Hiding IPv4 Transit-only Networks in OSPFv2 111 In [OSPFv2], networks are classified as point-to-point, broadcast, or 112 non-broadcast. In the following sections, we will review how these 113 OSPF networks are being advertised and discuss how to hide them. 115 2.1. Point-to-Point Networks 117 A point-to-point network joins a single pair of routers. Figure 1 118 shows a point-to-point network connecting routers RT1 and RT2. 120 +---+.1 198.51.100.0/30 .2+---+ 121 |RT1|---------------------------|RT2| 122 +---+ +---+ 124 Figure 1 Physical point-to-point network 126 2.1.1. Advertising Point-to-Point Networks 128 For each numbered point-to-point network, a router has 2 link 129 descriptions in its router-LSA, one Type 1 link (point-to-point) 130 describing the neighboring router, and one Type 3 link (stub) 131 describing the assigned IPv4 subnet. 133 An example of router-LSA originated by RT1 would look like 135 LS age = 0 ;newly (re)originated 136 LS type = 1 ;router-LSA 137 Link State ID = 192.0.2.1 ;RT1's Router ID 138 Advertising Router = 192.0.2.1 ;RT1's Router ID 139 #links = 2 140 Link ID = 192.0.2.2 ;RT2's Router ID 141 Link Data = 198.51.100.1 ;Interface IP address 142 Type = 1 ;connects to RT2 143 Metric = 10 145 Link ID= 198.51.100.0 ;IP network/subnet number 146 Link Data = 255.255.255.252 ;Subnet's mask 147 Type = 3 ;Connects to stub network 148 Metric = 10 150 The Type 1 link will be used for SPF calculation while the Type 3 151 link will be used to install a route to the corresponding subnet in 152 the Routing Information Base (RIB). 154 2.1.2. Hiding Point-to-Point Networks 156 To hide a transit-only point-to-point network, the Type 3 link MUST 157 be omitted from the router-LSA. 159 An example of router-LSA originated by RT1, hiding the point-to-point 160 network depicted in Figure 1, would look like 162 LS age = 0 ;newly (re)originated 163 LS type = 1 ;router-LSA 164 Link State ID = 192.0.2.1 ;RT1's Router ID 165 Advertising Router = 192.0.2.1 ;RT1's Router ID 166 #links = 1 167 Link ID = 192.0.2.2 ;RT2's Router ID 168 Link Data = 198.51.100.1 ;Interface IP address 169 Type = 1 ;connects to RT2 170 Metric = 10 172 2.2. Broadcast Networks 174 A broadcast network joins many (more than two) routers, and supports 175 the capability to address a single physical message to all of the 176 attached routers. Figure 2 shows a broadcast network connecting 177 router RT3, RT4, and RT5. 179 +---+ +---+ 180 |RT3| |RT4| 181 +---+ +---+ 182 |.3 198.51.100.0/24 .4| 183 +-----------------------------+ 184 |.5 185 +---+ 186 |RT5| 187 +---+ 189 Figure 2 Broadcast network 191 2.2.1. Advertising Broadcast Networks 193 For each broadcast network, a designated router (DR) describes it in 194 its network-LSA. Assuming RT3 is elected as the DR in Figure 2, an 195 example of the network-LSA originated by RT3 would look like 196 LS age = 0 ;newly (re)originated 197 LS type = 2 ;network-LSA 198 Link State ID = 198.51.100.3 ;IP address of the DR (RT3) 199 Advertising Router = 192.0.2.3 ;RT3's Router ID 200 Network Mask = 255.255.255.0 201 Attached Router = 192.0.2.3 ;RT3's Router ID 202 Attached Router = 192.0.2.4 ;RT4's Router ID 203 Attached Router = 192.0.2.5 ;RT5's Router ID 205 OSPF obtains the IP network number from the combination of the Link 206 State ID and the Network Mask. In addition, the Link State ID is 207 also being used for 2-way connectivity check. 209 2.2.2. Hiding Broadcast Networks 211 2.2.2.1. Sending Network-LSA 213 To hide a transit-only broadcast network, a special network mask 214 value 255.255.255.255 MUST be used in the network-LSA. While a 215 broadcast network connects more than routers, using 255.255.255.255 216 will not hide an access broadcast network accidentally. 218 As there is no change of the Link State ID, the 2-way connectivity 219 check would proceed normally. 221 An example of network-LSA originated by RT3, hiding the broadcast 222 network depicted in Figure 2, would look like 224 LS age = 0 ;newly (re)originated 225 LS type = 2 ;network-LSA 226 Link State ID = 198.51.100.3 ;IP address of the DR (RT3) 227 Advertising Router = 192.0.2.3 ;RT3's Router ID 228 Network Mask = 255.255.255.255 ;special subnet mask 229 Attached Router = 192.0.2.3 ;RT3's Router ID 230 Attached Router = 192.0.2.4 ;RT4's Router ID 231 Attached Router = 192.0.2.5 ;RT5's Router ID 233 2.2.2.2. Receiving Network-LSA 235 It's RECOMMENDED that all routers in an area be upgraded at the same 236 time to process the modified network-LSA correctly and consistently. 238 When a router receives a network-LSA, it MUST check the 2-way 239 connectivity as normal. However, if the network mask in the network- 240 LSA is 255.255.255.255, the router MUST NOT install the route in the 241 RIB. 243 2.2.2.2.1. Backward Compatibility 244 When a not-yet-upgraded router receives a modified network-LSA, as 245 specified in section 2.2.2.1, a host route to the originating DR will 246 be installed. This is not ideal but better than the current result, 247 which exposes the whole subnet. 249 In a partial deployment scenario, upgraded routers and not-yet- 250 upgraded routers may coexist. The former do not install the host 251 route to the DR's interface, while the latter install it. Such 252 inconsistencies create routing black holes, which should normally be 253 avoided. In this case, however, as packets destined for the transit- 254 only networks are dropped somewhere in the network, the black holes 255 actually help the DRs defend themselves from the remote attacks. 257 In summary, the modification of the network-LSA, as specified in 258 section 2.2.2.1, is backward compatible with the current 259 specification of [OSPFv2], even in a partial deployment scenario. 261 2.3. Non-Broadcast Networks 263 A non-broadcast networks joins many (more than two) routers, but does 264 NOT support the capability to address a single physical message to 265 all of the attached routers. As mentioned in [OSPFv2], OSPF runs in 266 one of two modes over non-broadcast networks: Non-Broadcast Multi- 267 Access (NBMA) or Point-to-MultiPoint. 269 2.3.1. NBMA 271 In NBMA mode, OSPF emulates operation over a broadcast network: a 272 Designated Router is elected for the NBMA network, and the Designated 273 Router originates an LSA for the network. 275 To hide a NBMA transit-only network, OSPF adopts the same 276 modification over the broadcast transit-only network, as defined in 277 section 2.2.2. 279 2.3.2. Point-to-MultiPoint 281 In point-to-MultiPoint mode, OSPF treats the non-broadcast network as 282 a collection of point-to-point links. 284 Figure 3 shows a non-broadcast network connecting router RT6, RT7, 285 RT8, and RT9. In this network, all routers can communicate directly, 286 except for routers RT7 and RT8. 288 +---+ +---+ 289 |RT6| |RT7| 290 +---+ +---+ 291 |.6 198.51.100.0/24 .7| 292 +----------------------------+ 293 |.8 .9| 294 +---+ +---+ 295 |RT8| |RT9| 296 +---+ +---+ 298 Figure 3 Non-Broadcast network 300 2.3.2.1. Advertising Point-to-MultiPoint Networks 302 For a point-to-multipoint network, a router has multiple link 303 descriptions in its router-LSA, one Type 1 link (point-to-point) for 304 EACH directly communicable router, and one Type 3 link (stub) 305 advertising its interface IPv4 address with a subnet mask of 306 255.255.255.255. 308 An example of router-LSA originated by RT7 would look like 310 LS age = 0 ;newly (re)originated 311 LS type = 1 ;router-LSA 312 Link State ID = 192.0.2.7 ;RT7's Router ID 313 Advertising Router = 192.0.2.7 ;RT7's Router ID 314 #links = 3 315 Link ID = 192.0.2.6 ;RT6's Router ID 316 Link Data = 198.51.100.7 ;Interface IP address 317 Type = 1 ;connects to RT6 318 Metric = 10 320 Link ID = 192.0.2.9 ;RT9's Router ID 321 Link Data = 198.51.100.7 ;Interface IP address 322 Type = 1 ;connects to RT9 323 Metric = 10 325 Link ID= 198.51.100.7 ;Interface IP address 326 Link Data = 255.255.255.255 ;Subnet's mask 327 Type = 3 ;Connects to stub network 328 Metric = 0 330 2.3.2.2. Hiding Point-to-MultiPoint Networks 332 To hide a transit-only point-to-multipoint network, the Type 3 333 link MUST be omitted from the router-LSA. 335 An example of router-LSA originated by RT7, hiding the point-to- 336 point network depicted in Figure 3, would look like 338 LS age = 0 ;newly (re)originated 339 LS type = 1 ;router-LSA 340 Link State ID = 192.0.2.7 ;RT7's Router ID 341 Advertising Router = 192.0.2.7 ;RT7's Router ID 342 #links = 2 343 Link ID = 192.0.2.6 ;RT6's Router ID 344 Link Data = 198.51.100.7 ;Interface IP address 345 Type = 1 ;connects to RT6 346 Metric = 10 348 Link ID = 192.0.2.9 ;RT9's Router ID 349 Link Data = 198.51.100.7 ;Interface IP address 350 Type = 1 ;connects to RT9 351 Metric = 10 353 3. Hiding IPv6 Transit-only Networks in OSPFv3 355 In [OSPFv3], addressing semantics have been removed from the OSPF 356 protocol packets and the main LSA types, leaving a network-protocol- 357 independent core. 359 More specifically, router-LSAs and network-LSAs no longer contain 360 network addresses, but simply express topology information. Instead, 361 two new LSA types, link-LSA and intra-area-prefix-LSA, have been 362 introduced. A link-LSA associates a list of IPv6 address to a link 363 and has local-link flooding scope, and an intra-area-prefix-LSA 364 either associates a list of IPv6 addresses with a router by 365 referencing a router-LSA, or associates a list of IPv6 addresses with 366 a broadcast/NBMA network by referencing a network-LSA. In the latter 367 case, the prefixes in the link-LSAs from adjacent neighbors are 368 copied into the intra-area-prefix-LSA by the Designated Router. 370 To hide a transit-only network in [OSPFv3], the associated IPv6 371 address prefixes MUST be omitted from the link-LSA. Consequently, 372 when a Designated Router builds an intra-area-prefix-LSA referencing 373 a network-LSA, these IPv6 address prefixes will be omitted. 375 In addition, when a router builds an intra-area-prefix-LSA that is 376 referencing a router-LSA, the associated IPv6 address prefixes from 377 the transit-only network MUST also be omitted from the intra-area- 378 prefix-LSA. 380 4. Hiding AF Enabled Transit-only Networks in OSPFv3 382 [OSPF-AF] supports multiple Address Families (AFs) by mapping each AF 383 to a separate Instance ID and OSPFv3 instance. 385 In the meantime, each prefix advertised in OSPFv3 has a prefix Length 386 field [OSPFv3], which facilitates advertising prefixes of different 387 lengths in different AFs. The existing LSAs defined in [OSPFv3] are 388 used for prefix advertising and there is no need to define new LSAs. 390 In other words, as link-LSAs and intra-area-prefix-LSAs are still 391 being used, the same mechanism explained in section 3 can be used to 392 hide those AF enabled transit-only networks as well. 394 5. Forwarding Address 396 A non-zero forwarding address can be advertised in AS-external-LSAs 397 and NSSA-LSAs [NSSA] to achieve optimal routing to AS external 398 routes. The matching routing table entry for the forwarding address 399 must exist to facilitate the SPF calculation. 401 In other words, when prefix-hiding is configured on the next-hop 402 interface, the next-hop address MUST NOT be advertised as a 403 forwarding address. 405 Consequently, sub-optimal routing to these AS external routes may 406 exist when prefix-hiding is configured. 408 6. Virtual Links 410 Virtual links are used to connect physically separate components of 411 the backbone. The virtual link's viability is determined by the 412 existence of an intra-area path between two endpoints. The matching 413 routing table entries of the endpoints must exist to ensure the 414 virtual link's operation. 416 In other words, if prefix-hiding is configured on an interface, the 417 virtual link endpoint MUST NOT use that interface's IP address as the 418 virtual interface's IP address. 420 7. Operational Considerations 422 By eliminating the ability to reach transit-only networks, the 423 ability to manage these interfaces may be reduced. In order to not 424 reduce the functionality and capability of the overall network, it is 425 recommended that extensions such as [RFC5837] be also implemented. 427 8. Security Considerations 429 One motivation for this document is to reduce remote attack 430 vulnerability by hiding transit-only networks. The result should 431 then be that fewer OSPF core networks will be exposed to un- 432 authorized access. 434 The mechanisms described above result in reachability information 435 from transit-only networks not being installed in the routers' 436 forwarding tables. The effect is that even if the address of a 437 transit-only network is known, the forwarding information is not 438 present in the routers to reach the destination. Also, in some cases 439 the address information is completely omitted from the LSA. 441 Some information in the LSA (such as the OSPF Router ID) cannot be 442 omitted. Even though the Router ID may be taken from an IPv4 address 443 on the router, the configuration can be easily changed. Note again 444 that having an address doesn't guarantee reachability if the 445 information is hidden from the forwarding tables. 447 While the steps described in this document are meant to be applied to 448 transit-only networks ONLY, they could be used to hide other networks 449 as well. It is expected that the same care that users put on the 450 configuration of other routing protocol parameters is used in the 451 configuration of this extension. 453 9. IANA Considerations 455 No actions are required from IANA as result of the publication of 456 this document. 458 10. Acknowledgments 460 The draft text was produced using Stefan Santesson's NroffEdit 461 application. 463 The idea of using a special subnet mask to hide broadcast networks in 464 OSPF was originally introduced in the US patent "Apparatus and method 465 to hide transit only multi-access networks in OSPF" (patent number: 466 7,929,524), by Yi Yang, Alvaro Retana, James Ng, Abhay Roy, Alfred 467 Lindem, Sina Mirtorabi, Timothy Gage, and Khalid Raza. 469 The authors would like to thank Acee Lindem, Shraddha Hegde, Rajesh 470 Shetty, Marek Karasek, Michael Barnes, and Paul Wells, for their 471 feedback on the document. 473 11. References 475 11.1. Normative References 477 [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate 478 Requirement Levels", BCP 14, RFC 2119, March 1997. 480 [NSSA] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", 481 RFC 3101, January 2003. 483 [OSPFv2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 485 [OSPFv3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem , "OSPF 486 for IPv6", RFC 5340, July 2008. 488 [OSPF-AF] Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. 489 Aggarwal, "Support of Address Families in OSPFv3", 490 RFC5838, April 2010. 492 11.2. Informative References 494 [RFC5837] Atlas, A., Bonica, R., Pignataro, C., Shen, N., and JR. 495 Rivers, "Extending ICMP for Interface and Next-Hop 496 Identification", RFC 5837, April 2010. 498 Authors' Addresses 500 Yi Yang 501 Cisco Systems 502 7025 Kit Creek Road 503 RTP, NC 27709 504 USA 506 Email: yiya@cisco.com 508 Alvaro Retana 509 Hewlett-Packard Co. 510 2610 Wycliff Road 511 Raleigh, NC 27607 512 USA 514 Email: alvaro.retana@hp.com 516 Abhay Roy 517 Cisco Systems 518 225 West Tasman Drive 519 San Jose, CA 95134 520 USA 522 Email: akr@cisco.com