idnits 2.17.1 draft-ietf-ospf-prefix-hiding-02.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 (February 2, 2012) is 4464 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 373, but not defined == Unused Reference: 'RFC5837' is defined on line 424, 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: August 5, 2012 Hewlett-Packard Co. 6 A. Roy 7 Cisco Systems 8 February 2, 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 August 5, 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. 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 . . . . . . . . . . . . . . . . . 11 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 Routing Information Base (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 omitted 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, the Link State ID is 204 also 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 at the same 233 time 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 coexist. The former do not have the host routes 248 aforementioned, while the latter do have. Such inconsistencies 249 create routing black holes, which should normally be avoided. In 250 this case, however, as packets destined for the transit-only networks 251 are dropped somewhere in the network, the black holes actually help 252 DRs 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 scenario. 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: Non-Broadcast Multi- 264 Access (NBMA) or Point-to-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 advertising its interface IPv4 address with a subnet mask of 303 255.255.255.255. 305 An example of router-LSA originated by RT7 would look like 307 LS age = 0 ;newly (re)originated 308 LS type = 1 ;router-LSA 309 Link State ID = 7.7.7.7 ;RT7's Router ID 310 Advertising Router = 7.7.7.7 ;RT7's Router ID 311 #links = 3 312 Link ID = 6.6.6.6 ;RT6's Router ID 313 Link Data = 10.3.3.7 ;Interface IP address 314 Type = 1 ;connects to RT6 315 Metric = 10 317 Link ID = 9.9.9.9 ;RT9's Router ID 318 Link Data = 10.3.3.7 ;Interface IP address 319 Type = 1 ;connects to RT9 320 Metric = 10 322 Link ID= 10.3.3.7 ;Interface IP address 323 Link Data = 255.255.255.255 ;Subnet's mask 324 Type = 3 ;Connects to stub network 325 Metric = 0 327 2.3.2.2. Hiding Point-to-MultiPoint Networks 329 To hide a transit-only point-to-multipoint network, the Type 3 330 link MUST be omitted from the router-LSA. 332 An example of router-LSA originated by RT7, hiding the point-to- 333 point network depicted in Figure 3, would look like 335 LS age = 0 ;newly (re)originated 336 LS type = 1 ;router-LSA 337 Link State ID = 7.7.7.7 ;RT7's Router ID 338 Advertising Router = 7.7.7.7 ;RT7's Router ID 339 #links = 2 340 Link ID = 6.6.6.6 ;RT6's Router ID 341 Link Data = 10.3.3.7 ;Interface IP address 342 Type = 1 ;connects to RT6 343 Metric = 10 345 Link ID = 9.9.9.9 ;RT9's Router ID 346 Link Data = 10.3.3.7 ;Interface IP address 347 Type = 1 ;connects to RT9 348 Metric = 10 350 3. Hiding IPv6 Transit-only Networks in OSPFv3 352 In [OSPFv3], addressing semantics have been removed from the OSPF 353 protocol packets and the main LSA types, leaving a network-protocol- 354 independent core. 356 More specifically, router-LSAs and network-LSAs no longer contain 357 network addresses, but simply express topology information. A new 358 LSA called the intra-area-prefix-LSA has been introduced. This LSA 359 carries all IPv6 prefix information that in [OSPFv2] is included in 360 router-LSAs and network-LSAs. 362 Such changes simplify the process to hide the IPv6 addresses of the 363 transit-only networks in [OSPFv3] -- simply omitting the 364 correspondent IPv6 unicast prefixes from the intra-area-prefix-LSA 365 will hide these prefixes. 367 4. Hiding AF Enabled Transit-only Networks in OSPFv3 369 [OSPF-AF] supports multiple Address Families (AFs) by mapping each AF 370 to a separate Instance ID and OSPFv3 instance. 372 In the meantime, each prefix advertised in OSPFv3 has a prefix Length 373 field [OSPFV3], which facilitates advertising prefixes of different 374 lengths in different AFs. The existing LSAs defined in OSPFv3 are 375 used for prefix advertising and there is no need to define new LSAs. 377 In other words, intra-area-prefix-LSAs are still being used to 378 advertise the attached networks, and same method explained in section 379 3 can also be used to hide those AF enabled transit-only networks. 381 5. Operational Considerations 383 By eliminating the ability to reach transit-only networks, the 384 ability to manage these interfaces may be reduced. In order to not 385 reduce the functionality and capability of the overall network, it is 386 recommended that extensions such as RFC5837 be also implemented. 388 6. Security Considerations 390 One motivation for this document is to reduce remote attack 391 vulnerability by hiding transit-only networks. The result should 392 then be that fewer OSPF core networks will be exposed to un- 393 authorized access. 395 While the steps described in this document are meant to be applied to 396 transit-only networks ONLY, they could be used to hide other networks 397 as well. It is expected that the same care that users put on the 398 configuration of other routing protocol parameters is used in the 399 configuration of this extension. 401 7. IANA Considerations 403 No actions are required from IANA as result of the publication of 404 this document. 406 8. References 408 8.1. Normative References 410 [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate 411 Requirement Levels", BCP 14, RFC 2119, March 1997. 413 [OSPFv2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 415 [OSPFv3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem , "OSPF 416 for IPv6", RFC 5340, July 2008. 418 [OSPF-AF] Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. 419 Aggarwal, "Support of Address Families in OSPFv3", 420 RFC5838, April 2010. 422 8.2. Informative References 424 [RFC5837] Atlas, A., Bonica, R., Pignataro, C., Shen, N., and JR. 425 Rivers, "Extending ICMP for Interface and Next-Hop 426 Identification", RFC5837, April 2010. 428 Appendix A. Acknowledgments 430 The draft text was produced using Stefan Santesson's NroffEdit 431 application. 433 The idea of using a special subnet mask to hide broadcast networks in 434 OSPF was originally introduced in the US patent "Apparatus and method 435 to hide transit only multi-access networks in OSPF" (patent number: 436 7,929,524), by Yi Yang, Alvaro Retana, James Ng, Abhay Roy, Alfred 437 Lindem, Sina Mirtorabi, Timothy Gage, and Khalid Raza. 439 The authors would like to thank Acee Lindem for his feedback on the 440 document. 442 Authors' Addresses 444 Yi Yang 445 Cisco Systems 446 7025 Kit Creek Road 447 RTP, NC 27709 448 USA 450 Email: yiya@cisco.com 452 Alvaro Retana 453 Hewlett-Packard Co. 454 2610 Wycliff Road 455 Raleigh, NC 27607 456 USA 458 Email: alvaro.retana@hp.com 460 Abhay Roy 461 Cisco Systems 462 225 West Tasman Drive 463 San Jose, CA 95134 464 USA 465 Email: akr@cisco.com