idnits 2.17.1 draft-ietf-ospf-prefix-hiding-00.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 (June 1, 2011) is 4705 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 372, but not defined == Unused Reference: 'RFC5837' is defined on line 423, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 5 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: December 3, 2011 Hewlett-Packard Co. 6 A. Roy 7 Cisco Systems 8 June 1, 2011 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 LSAs but not needed 18 for data traffic. In addition, remote attacks can be launched 19 against routers by sending packets to these transit-only networks. 20 This document presents a mechanism to hide transit-only networks to 21 speed up network convergence and minimize remote attack 22 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 December 3, 2011. 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. Operational Considerations . . . . . . . . . . . . . . . . . . 10 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 81 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 82 8.2. Informative References . . . . . . . . . . . . . . . . . 10 83 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 11 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 86 1. Introduction 88 A transit-only network is defined as a network connecting routers 89 only. In OSPF, transit-only networks are usually configured with 90 routable IP addresses, which are advertised in LSAs but not needed 91 for data traffic. In addition, remote attacks can be launched 92 against routers by sending packets to these transit-only networks. 93 This document presents a mechanism to hide transit-only networks to 94 speed up network convergence and minimize remote attack 95 vulnerability. 97 Hiding transit-only networks will not impact reachability to the end 98 hosts. 100 1.1. Requirements notation 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [KEYWORD]. 106 2. Hiding IPv4 Transit-only Networks in OSPFv2 108 In [OSPFv2], networks are classified as point-to-point, broadcast, or 109 non-broadcast. In the following sections, we will review how these 110 OSPF networks are being advertised and discuss how to hide them 111 consequently. 113 2.1. Point-to-Point Networks 115 A point-to-point network joins a single pair of routers. Figure 1 116 shows a point-to-point network connecting routers RT1 and RT2. 118 +---+.1 10.1.1.0/30 .2+---+ 119 |RT1|---------------------------|RT2| 120 +---+ +---+ 122 Figure 1 Physical point-to-point network 124 2.1.1. Advertising Point-to-Point Networks 126 For each numbered point-to-point network, a router has 2 link 127 descriptions in its router LSA, one Type 1 link (point-to-point) 128 regarding the neighboring router, and one Type 3 link (stub) 129 regarding the assigned IPv4 address. 131 An example of router LSA originated by RT1 would look like 133 LS age = 0 ;newly (re)originated 134 LS type = 1 ;router-LSA 135 Link State ID = 1.1.1.1 ;RT1's Router ID 136 Advertising Router = 1.1.1.1 ;RT1's Router ID 137 #links = 2 138 Link ID = 2.2.2.2 ;RT2's Router ID 139 Link Data = 10.1.1.1 ;Interface IP address 140 Type = 1 ;connects to RT2 141 Metric = 10 143 Link ID= 10.1.1.0 ;Interface IP address 144 Link Data = 255.255.255.252 ;Subnet's mask 145 Type = 3 ;Connects to stub network 146 Metric = 10 148 The Type 1 link will be used for SPF calculation while the Type 3 149 link will be used for RIB installation. 151 2.1.2. Hiding Point-to-Point Networks 153 To hide a transit-only point-to-point network, the Type 3 link MUST 154 be removed from the router LSA. 156 An example of router LSA originated by RT1, hiding the point-to-point 157 network depicted in Figure 1, would look like 159 LS age = 0 ;newly (re)originated 160 LS type = 1 ;router-LSA 161 Link State ID = 1.1.1.1 ;RT1's Router ID 162 Advertising Router = 1.1.1.1 ;RT1's Router ID 163 #links = 1 164 Link ID = 2.2.2.2 ;RT2's Router ID 165 Link Data = 10.1.1.1 ;Interface IP address 166 Type = 1 ;connects to RT2 167 Metric = 10 169 2.2. Broadcast Networks 171 A broadcast networks joins many (more than two) routers, and supports 172 the capability to address a single physical message to all of the 173 attached routers. Figure 2 shows a broadcast network connecting 174 router RT3, RT4, and RT5. 176 +---+ +---+ 177 |RT3| |RT4| 178 +---+ +---+ 179 |.3 10.2.2.0/24 .4| 180 +---------------------------+ 181 |.5 182 +---+ 183 |RT5| 184 +---+ 186 Figure 2 Broadcast network 188 2.2.1. Advertising Broadcast Networks 190 For each broadcast network, a designated router (DR) describes it in 191 its network LSA. Assuming RT3 is elected as the DR in Figure 2, an 192 example of the network LSA originated by RT3 would look like 193 LS age = 0 ;newly (re)originated 194 LS type = 2 ;network-LSA 195 Link State ID = 10.2.2.3 ;IP address of the DR (RT3) 196 Advertising Router = 3.3.3.3 ;RT3's Router ID 197 Network Mask = 255.255.255.0 198 Attached Router = 3.3.3.3 ;Router ID 199 Attached Router = 4.4.4.4 ;Router ID 200 Attached Router = 5.5.5.5 ;Router ID 202 OSPF obtains the IP network number from the combination of the Link 203 State ID and the Network Mask. In addition, Link State ID is also 204 being used for 2-way connectivity check. 206 2.2.2. Hiding Broadcast Networks 208 2.2.2.1. Sending Network LSA 210 To hide a transit-only broadcast network, a special network mask 211 value 255.255.255.255 MUST be used in the network LSA. While a 212 broadcast network connects more than routers, using 255.255.255.255 213 will not hide an access broadcast network accidentally. 215 As there is no change of the Link State ID, the 2-way connectivity 216 check would proceed normally. 218 An example of network LSA originated by RT3, hiding the broadcast 219 network depicted in Figure 2, would look like 221 LS age = 0 ;newly (re)originated 222 LS type = 2 ;network-LSA 223 Link State ID = 10.2.2.3 ;IP address of the DR (RT3) 224 Advertising Router = 3.3.3.3 ;RT3's Router ID 225 Network Mask = 255.255.255.255 ;special subnet mask 226 Attached Router = 3.3.3.3 ;Router ID 227 Attached Router = 4.4.4.4 ;Router ID 228 Attached Router = 5.5.5.5 ;Router ID 230 2.2.2.2. Receiving Network LSA 232 It's RECOMMENDED that all routers in an area be upgraded as a whole 233 to process the modified network LSA correctly and consistently. 235 When a router receives a network LSA, it MUST check the 2-way 236 connectivity as normal. However, if the network mask in the network 237 LSA is 255.255.255.255, the router MUST NOT install the route in the 238 RIB. 240 2.2.2.2.1. Backward Compatibility 241 When a not-yet-upgraded router receives a modified network LSA, as 242 specified in section 2.2.2.1, a host route to the originating DR will 243 be installed. This is not ideal but better than the current result, 244 which exposes the whole subnet. 246 In a partial deployment scenario, upgraded routers and not-yet- 247 upgraded routers may mix up. The former do not have the host routes 248 aforementioned, while the latter do have. Such inconsistence creates 249 routing black holes, which should be avoided normally. In this case, 250 however, as packets destined for the transit-only networks are 251 dropped somewhere in the network, the black holes actually help DRs 252 defend from the remote attacks. 254 In summary, the modification of the network LSA, as specified in 255 section 2.2.2.1, is backward compatible with the current 256 specification of [OSPFv2], even in a partial deployment case. 258 2.3. Non-Broadcast Networks 260 A non-broadcast networks joins many (more than two) routers, but does 261 NOT support the capability to address a single physical message to 262 all of the attached routers. As mentioned in [OSPFv2], OSPF runs in 263 one of two modes over non-broadcast networks: NBMA or Point-to- 264 MultiPoint. 266 2.3.1. NBMA 268 In NBMA mode, OSPF emulates operation over a broadcast network: a 269 Designated Router is elected for the NBMA network, and the Designated 270 Router originates an LSA for the network. 272 To hide a NBMA transit-only network, OSPF adopts the same 273 modification over the broadcast transit-only network, as defined in 274 section 2.2.2. 276 2.3.2. Point-to-MultiPoint 278 In point-to-MultiPoint mode, OSPF treats the non-broadcast network as 279 a collection of point-to-point links. 281 Figure 3 shows a non-broadcast network connecting router RT6, RT7, 282 RT8, and RT9. In this network, all routers can communicate directly, 283 except for routers RT7 and RT8. 285 +---+ +---+ 286 |RT6| |RT7| 287 +---+ +---+ 288 |.6 10.3.3.0/24 .7| 289 +---------------------------+ 290 |.8 .9| 291 +---+ +---+ 292 |RT8| |RT9| 293 +---+ +---+ 295 Figure 3 Non-Broadcast network 297 2.3.2.1. Advertising Point-to-MultiPoint Networks 299 For a point-to-multipoint network, a router has multiple link 300 descriptions in its router LSA, one Type 1 link (point-to-point) for 301 EACH directly communicable router, and one Type 3 link (stub) 302 regarding the assigned IPv4 address. 304 An example of router LSA originated by RT7 would look like 306 LS age = 0 ;newly (re)originated 307 LS type = 1 ;router-LSA 308 Link State ID = 7.7.7.7 ;RT7's Router ID 309 Advertising Router = 7.7.7.7 ;RT7's Router ID 310 #links = 3 311 Link ID = 6.6.6.6 ;RT6's Router ID 312 Link Data = 10.3.3.7 ;Interface IP address 313 Type = 1 ;connects to RT6 314 Metric = 10 316 Link ID = 9.9.9.9 ;RT9's Router ID 317 Link Data = 10.3.3.7 ;Interface IP address 318 Type = 1 ;connects to RT9 319 Metric = 10 321 Link ID= 10.3.3.7 ;Interface IP address 322 Link Data = 255.255.255.255 ;Subnet's mask 323 Type = 3 ;Connects to stub network 324 Metric = 0 326 2.3.2.2. Hiding Point-to-MultiPoint Networks 328 To hide a transit-only point-to-multipoint network, the Type 3 329 link MUST be removed from the router LSA. 331 An example of router LSA originated by RT7, hiding the point-to- 332 point network depicted in Figure 3, would look like 334 LS age = 0 ;newly (re)originated 335 LS type = 1 ;router-LSA 336 Link State ID = 7.7.7.7 ;RT7's Router ID 337 Advertising Router = 7.7.7.7 ;RT7's Router ID 338 #links = 2 339 Link ID = 6.6.6.6 ;RT6's Router ID 340 Link Data = 10.3.3.7 ;Interface IP address 341 Type = 1 ;connects to RT6 342 Metric = 10 344 Link ID = 9.9.9.9 ;RT9's Router ID 345 Link Data = 10.3.3.7 ;Interface IP address 346 Type = 1 ;connects to RT9 347 Metric = 10 349 3. Hiding IPv6 Transit-only Networks in OSPFv3 351 In [OSPFv3], addressing semantics have been removed from the OSPF 352 protocol packets and the main LSA types, leaving a network-protocol- 353 independent core. 355 More specifically, Router-LSAs and network-LSAs no longer contain 356 network addresses, but simply express topology information. A new 357 LSA called the intra-area-prefix-LSA has been introduced. This LSA 358 carries all IPv6 prefix information that in [OSPFv2] is included in 359 router-LSAs and network-LSAs. 361 Such changes simplify the process to hide the IPv6 addresses of the 362 transit-only networks in [OSPFv3] -- simply removing the 363 correspondent IPv6 unicast prefixes from the intra-area-prefix-LSA 364 will do the trick. 366 4. Hiding AF Enabled Transit-only Networks in OSPFv3 368 [OSPF-AF] supports multiple address families (AFs) by by mapping each 369 AF to a separate Instance ID and OSPFv3 instance. 371 In the meantime, each prefix advertised in OSPFv3 has a prefix Length 372 field [OSPFV3], which facilitates advertising prefixes of different 373 lengths in different AFs. The existing LSAs defined in OSPFv3 are 374 used for prefix advertising and there is no need to define new LSAs. 376 In other words, intra-area-prefix-LSAs are still being used to 377 advertise the attached networks, and same method explained in section 378 3 can also be used to hide those AF enabled transit-only networks. 380 5. Operational Considerations 382 By eliminating the ability to reach transit-only networks, the 383 ability to manage these interfaces may be reduced. In order to not 384 reduce the functionality and capability of the overall network, it is 385 recommended that extensions such as RFC5837 be also implemented. 387 6. Security Considerations 389 One motivation for this document is to reduce remote attack 390 vulnerability by hiding transit-only networks. The result should 391 then be that fewer OSPF core networks will be exposed to un- 392 authorized access. 394 While the steps described in this document are meant to be applied to 395 transit-only networks ONLY, they could be used to hide other networks 396 as well. It is expected that the same care that users put on the 397 configuration of other routing protocol parameters is used in the 398 configuration of this extension. 400 7. IANA Considerations 402 No actions are required from IANA as result of the publication of 403 this document. 405 8. References 407 8.1. Normative References 409 [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate 410 Requirement Levels", BCP 14, RFC 2119, March 1997. 412 [OSPFv2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 414 [OSPFv3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem , "OSPF 415 for IPv6", RFC 5340, July 2008. 417 [OSPF-AF] Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. 418 Aggarwal, "Support of Address Families in OSPFv3", 419 RFC5838, April 2010. 421 8.2. Informative References 423 [RFC5837] Atlas, A., Bonica, R., Pignataro, C., Shen, N., and JR. 424 Rivers, "Extending ICMP for Interface and Next-Hop 425 Identification", RFC5837, April 2010. 427 Appendix A. Acknowledgments 429 The draft text was produced using Stefan Santesson's NroffEdit 430 application. 432 The idea of using a special subnet mask to hide broadcast networks in 433 OSPF was originally introduced in the US patent "Apparatus and method 434 to hide transit only multi-access networks in OSPF" (patent number: 435 7,929,524), by Yi Yang, Alvaro Retana, James Ng, Abhay Roy, Alfred 436 Lindem, Sina Mirtorabi, Timothy Gage, and Khalid Raza. 438 Authors' Addresses 440 Yi Yang 441 Cisco Systems 442 7025 Kit Creek Road 443 RTP, NC 27709 444 USA 446 Email: yiya@cisco.com 448 Alvaro Retana 449 Hewlett-Packard Co. 450 2610 Wycliff Road 451 Raleigh, NC 27607 452 USA 454 Email: alvaro.retana@hp.com 456 Abhay Roy 457 Cisco Systems 458 225 West Tasman Drive 459 San Jose, CA 95134 460 USA 462 Email: akr@cisco.com