idnits 2.17.1 draft-ietf-grow-private-ip-sp-cores-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 16 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 291: '...cket, the router MUST drop the packet ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 7, 2012) is 4365 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '3' on line 259 -- Looks like a reference, but probably isn't: '1' on line 260 -- Looks like a reference, but probably isn't: '30' on line 261 -- Looks like a reference, but probably isn't: '33434' on line 262 == Missing Reference: 'AS 64497' is mentioned on line 271, but not defined == Missing Reference: 'RFC 5837' is mentioned on line 275, but not defined == Missing Reference: 'RFC 1918' is mentioned on line 346, but not defined == Missing Reference: 'RFC2827' is mentioned on line 414, but not defined == Unused Reference: 'RFC1191' is defined on line 583, but no explicit reference was found in the text == Unused Reference: 'RFC1393' is defined on line 586, but no explicit reference was found in the text == Unused Reference: 'RFC2728' is defined on line 592, but no explicit reference was found in the text == Unused Reference: 'RFC6304' is defined on line 599, but no explicit reference was found in the text == Unused Reference: 'RFC792' is defined on line 606, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1393 (Obsoleted by RFC 6814) ** Obsolete normative reference: RFC 6304 (Obsoleted by RFC 7534) Summary: 4 errors (**), 0 flaws (~~), 11 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Kirkham 3 Internet-Draft Palo Alto Networks 4 Obsoletes: None (if approved) May 7, 2012 5 Intended status: Informational 6 Expires: November 8, 2012 8 Issues with Private IP Addressing in the Internet 9 draft-ietf-grow-private-ip-sp-cores-03 11 Abstract 13 The purpose of this document is to provide a discussion of the 14 potential problems of using private, RFC1918, or non-globally- 15 routable addressing within the core of an SP network. The discussion 16 focuses on link addresses and to a small extent loopback addresses. 17 While many of the issues are well recognised within the ISP 18 community, there appears to be no document that collectively 19 describes the issues. 21 Legal 23 This documents and the information contained therein are provided on 24 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 25 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 26 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 27 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 28 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 29 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 30 FOR A PARTICULAR PURPOSE. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on November 8, 2012. 49 Copyright Notice 51 Copyright (c) 2012 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Conservation of Address Space . . . . . . . . . . . . . . . . 3 68 3. Effects on Traceroute . . . . . . . . . . . . . . . . . . . . 4 69 4. Effects on Path MTU Discovery . . . . . . . . . . . . . . . . 7 70 5. Unexpected interactions with some NAT implementations . . . . 8 71 6. Interactions with edge anti-spoofing techniques . . . . . . . 10 72 7. Peering using loopbacks . . . . . . . . . . . . . . . . . . . 10 73 8. DNS Interaction . . . . . . . . . . . . . . . . . . . . . . . 11 74 9. Operational and Troubleshooting issues . . . . . . . . . . . . 11 75 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 76 11. Alternate approaches to core network security . . . . . . . . 13 77 12. Normative References . . . . . . . . . . . . . . . . . . . . . 14 78 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 14 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 1. Introduction 83 In the mid to late 90's, some Internet Service Providers (ISPs) 84 adopted the practice of utilising private (or non-globally unique) IP 85 (i.e. RFC1918) addresses for the infrastructure links and in some 86 cases the loopback interfaces within their networks. The reasons for 87 this approach centered on conservation of address space (i.e. 88 scarcity of public IPv4 address space), and security of the core 89 network (also known as core hiding). 91 However, a number of technical and operational issues occurred as a 92 result of using private (or non-globally unique) IP addresses, and 93 virtually all these ISPs moved away from the practice. Tier 1 ISPs 94 are considered the benchmark of the industry and as of the time of 95 writing, there is no known tier 1 ISP that utilises the practice of 96 private addressing within their core network. 98 The following sections will discuss the various issues associated 99 with deploying private IP (i.e. RFC1918) addresses within ISP core 100 networks. 102 The intent of this document is not to suggest that private IP can not 103 be used with the core of an SP network as some providers use this 104 practice and operate successfully. The intent is to outline the 105 potential issues or effects of such a practice. 107 Note: The practice of ISPs using 'stolen' address space (also known 108 as 'squat' space) has many of the same issues (or effects) as that of 109 using private IP address space within core networks. The term 110 "stolen IP address space" refers to the practice of an ISP using 111 address space for its own infrastructure/core network addressing that 112 has been officially allocated by an RIR to another provider, but that 113 provider is not currently using or advertising within the Internet. 114 Stolen addressing is not discussed further in this document. It is 115 simply noted as an associated issue. 117 2. Conservation of Address Space 119 One of the original intents for the use of private IP addressing 120 within an ISP core was the conservation of IP address space. When an 121 ISP is allocated a block of public IP addresses (from a RIR), this 122 address block was traditionally split in order to dedicate some 123 portion for infrastructure use (i.e. for the core network), and the 124 other portion for customer (subscriber) or other address pool use. 125 Typically, the number of infrastructure addresses needed is 126 relatively small in comparison to the total address count. So unless 127 the ISP was only granted a small public block, dedicating some 128 portion to infrastructure links and loopback addresses (/32) is 129 rarely a large enough issue to outweigh the problems that are 130 potentially caused when private address space is used. 132 Additionally, specifications and equipment capability improvements 133 now allow for the use of /31 subnets [RFC3021] for link addresses in 134 place of the original /30 subnets - further minimising the impact of 135 dedicating public addresses to infrastructure links by only using two 136 (2) IP addresses per point to point link versus four (4) 137 respectively. 139 The use of private addressing as a conservation technique within an 140 Internet Service Provider (ISP) core can cause a number of technical 141 and operational issues or effects. The main effects are described 142 below. 144 3. Effects on Traceroute 146 The single biggest effect caused by the use of private (RFC1918) 147 addressing within an Internet core is the fact that it can disrupt 148 the operation of traceroute in some situations. This section 149 provides some examples of the issues that can occur. 151 A first example illustrates the situation where the traceroute 152 crosses an AS boundary and one of the networks has utilised private 153 addressing. The following simple network is used to show the 154 effects. 156 AS64496 EBGP AS64497 157 IBGP Mesh <---------------> IBGP Mesh 159 R1 Pool - R6 Pool - 160 203.0.113.0/26 203.0.113.64/26 162 198.51.100.8/30 163 198.51.100.4/30 164 10.1.1.0/30 10.1.1.4/30 198.51.100.0/30 165 .9 .10 166 .1 .2 .5 .6 ------------ .6 .5 .2 .1 167 R1-----------R2-----------R3--| |--R4----------R5----------R6 169 R1 Loopback: 10.1.1.101 R4 Loopback: 198.51.100.103 170 R2 Loopback: 10.1.1.102 R5 Loopback: 198.51.100.102 171 R3 Loopback: 10.1.1.103 R6 Loopback: 198.51.100.101 172 Using this example, performing the traceroute from AS64497 to 173 AS64496, we can see the private addresses of the infrastructure links 174 in AS64496 are returned. 176 R6#traceroute 203.0.113.1 177 Type escape sequence to abort. 178 Tracing the route to 203.0.113.1 180 1 198.51.100.2 40 msec 20 msec 32 msec 181 2 198.51.100.6 16 msec 20 msec 20 msec 182 3 198.51.100.9 20 msec 20 msec 32 msec 183 4 10.1.1.5 20 msec 20 msec 20 msec 184 5 10.1.1.1 20 msec 20 msec 20 msec 185 R6# 187 This effect in itself is often not a problem. However, if anti- 188 spoofing controls are applied at network perimeters, then responses 189 returned from hops with private IP addresses will be dropped. Anti- 190 spoofing refers to a security control where traffic with an invalid 191 source address is discarded. Anti-spoofing is further described in 192 [BCP 38]/[RFC 2827]. 194 The effects are illustrated in a second example below. The same 195 network as example 1 is used, but with the addition of anti-spoofing 196 deployed at the ingress of R4 on the R3-R4 interface (IP Address 197 198.51.100.10). 199 R6#traceroute 203.0.113.1 201 Type escape sequence to abort. 202 Tracing the route to 203.0.113.1 204 1 198.51.100.2 24 msec 20 msec 20 msec 205 2 198.51.100.6 20 msec 52 msec 44 msec 206 3 198.51.100.9 44 msec 20 msec 32 msec 207 4 * * * 208 5 * * * 209 6 * * * 210 7 * * * 211 8 * * * 212 9 * * * 213 10 * * * 214 11 * * * 215 12 * * * 217 In a third example, a similar effect is caused. If a traceroute is 218 initiated from a router with a private (source) IP address, located 219 in AS64496 and the destination is outside of the ISPs AS (AS64497), 220 then in this situation the traceroute will fail completely beyond the 221 AS boundary. 223 R1# traceroute 203.0.113.65 224 Type escape sequence to abort. 225 Tracing the route to 203.0.113.65 227 1 10.1.1.2 20 msec 20 msec 20 msec 228 2 10.1.1.6 52 msec 24 msec 40 msec 229 3 * * * 230 4 * * * 231 5 * * * 232 6 * * * 233 R1# 235 While it is completely unreasonable to expect a packet with a private 236 source address to be successfully returned in a typical SP 237 environment, the case is included to show the effect as it can have 238 implications for troubleshooting. This case will be referenced in a 239 later section. 241 In a complex topology, with multiple paths and exit points, the 242 provider will lose their ability to trace paths originating within 243 their own AS, through their network, to destinations within other 244 ASs. Such a situation could be a severe troubleshooting impediment. 246 For completeness, a fourth example is included to show that a 247 successful traceroute can be achieved by specifying a public source 248 address as the source address of the traceroute. Such an approach 249 can be used in many operational situations if the router initiating 250 the traceroute has at least one public address configured. However, 251 the approach is more cumbersome. 253 R1#traceroute 254 Protocol [ip]: 255 Target IP address: 203.0.113.65 256 Source address: 203.0.113.1 257 Numeric display [n]: 258 Timeout in seconds [3]: 259 Probe count [3]: 260 Minimum Time to Live [1]: 261 Maximum Time to Live [30]: 10 262 Port Number [33434]: 263 Loose, Strict, Record, Timestamp, Verbose[none]: 264 Type escape sequence to abort. 265 Tracing the route to 203.0.113.65 267 1 10.1.1.2 0 msec 4 msec 0 msec 268 2 10.1.1.6 0 msec 4 msec 0 msec 269 3 198.51.100.10 [AS 64497] 0 msec 4 msec 0 msec 270 4 198.51.100.5 [AS 64497] 0 msec 0 msec 4 msec 271 5 198.51.100.1 [AS 64497] 0 msec 0 msec 4 msec 272 R1# 274 It should be noted that some solutions to this problem have been 275 proposed in [RFC 5837] which provides extensions to ICMP to allow the 276 identification of interfaces and their components by any combination 277 of the following: ifIndex, IPv4 address, IPv6 address, name, and 278 MTU. However at the time of writing, little or no deployment was 279 known to be in place. 281 4. Effects on Path MTU Discovery 283 The Path MTU Discovery (PMTUD) process was designed to allow hosts to 284 make an accurate assessment of the maximum packet size that can be 285 sent across a path without fragmentation. Path MTU Discovery is 286 supported for TCP (and other protocols that support PMTUD such as GRE 287 and IPsec) and works as follows: 289 o When a router attempts to forward an IP datagram with the Do Not 290 Fragment (DF) bit set out a link that has a lower MTU than the size 291 of the packet, the router MUST drop the packet and return an Internet 292 Control Message Protocol (ICMP) 'destination unreachable - 293 fragmentation needed and DF set (type 3, code 4)' message to the 294 source of the IP datagram. This message includes the MTU of that 295 next-hop network. As a result, the source station which receives the 296 ICMP message, will lower the send Maximum Segment Size (MSS). 298 It is obviously desirable that packets be sent between two 299 communicating hosts without fragmentation as this process imposes 300 extra load on the fragmenting router (process of fragmentation), 301 intermediate routers (forwarding additional packets), as well as the 302 receiving host (reassembly of the fragmented packets). Additionally, 303 many applications, including some web servers, set the DF (Do Not 304 Fragment) bit causing undesirable interactions if the path MTU is 305 insufficient. Other TCP implementations may set an MTU size of 576 306 bytes if PMTUD is unavailable. In addition, IPsec and other 307 tunneling protocols will often require MTUs greater than 1500 bytes 308 and often rely on PMTUD. 310 While it is uncommon these days for core SP networks not to support 311 path MTUs in excess of 1500 bytes (with 4470 or greater being 312 common), the situation of 1500 byte path MTUs is still common in many 313 ethernet edge or aggregation networks. 315 The issue is as follows: 317 o When an ICMP Type 3 Code 4 message is issued from an infrastructure 318 link that uses a private (RFC1918) address, it must be routed back to 319 the originating host. As the originating host will typically be a 320 globally routable IP address, its source address is used as the 321 destination address of the returned ICMP Type 3 packet. At this 322 point there are normally no problems. 324 o As the returned packet will have an [RFC1918] source address, 325 problems can occur when the returned packet passes through an anti- 326 spoofing security control (such as Unicast RPF (uRPF)), other anti- 327 spoofing ACLs, or virtually any perimeter firewall. These devices 328 will typically drop packets with an [RFC1918] source address, 329 breaking the successful operation of PMTUD. 331 As a result, the potential for application level issues may be 332 created. 334 5. Unexpected interactions with some NAT implementations 336 Private addressing is legitimately used within many enterprise, 337 corporate or government networks for internal network addressing. 338 When users on the inside of the network require Internet access, they 339 will typically connect through a perimeter router, firewall, or 340 network proxy, that provides Network Address Translation (NAT) or 341 Network Address Port Translation (NAPT) services to a public 342 interface. 344 Scarcity of public IPv4 addresses, and the transition to IPv6, is 345 forcing many service providers to make use of NAT. CGN (Carrier 346 Grade NAT) will enable service providers to assign private [RFC 1918] 347 IPv4 addresses to their customers rather than public, globally unique 348 IPv4 addresses. NAT444 will make use of a double NAT process. 350 Unpredictable or confusing interactions could occur if traffic such 351 as traceroute, PMTUD and possibly other applications were launched 352 from the NAT IPv4 'inside address' and it passed over the same 353 address range in the public IP core. While such a situation would be 354 unlikely to occur if the NAT pools and the private infrastructure 355 addressing were under the same administration, such a situation could 356 occur in the more typical situation of a NAT'ed corporate network 357 connecting to an ISP. For example, say if 10.1.1.0/24 is used to 358 internally number the corporate network. A traceroute or PMTUD 359 request is initiated inside the corporate network from say 10.1.1.1. 360 The packet passes through a NAT (or NAPT) gateway, then over an ISP 361 core numbered from the same range. When the responses are delivered 362 back to the originator, the returned packets from the privately 363 addressed part of the ISP core could have an identical source and 364 destination address of 10.1.1.1. 366 NAT Pool - 367 203.0.113.0/24 369 10.1.1.0/30 10.1.1.0/30 198.51.100.0/30 370 198.51.100.12/30 198.51.100.4/30 372 .1 .2 .14 .13 .1 .2 .6 .5 .2 .1 373 R1-----------R2-----------R3---------------R4----------R5----------R6 374 NAT 375 R6 Loopback: 376 198.51.100.100 378 R1#traceroute 198.51.100.100 380 Type escape sequence to abort. 381 Tracing the route to 198.51.100.100 383 1 10.1.1.2 0 msec 0 msec 0 msec 384 2 198.51.100.13 0 msec 4 msec 0 msec 385 3 10.1.1.2 0 msec 4 msec 0 msec <<<< 386 4 198.51.100.5 4 msec 0 msec 4 msec 387 5 198.51.100.1 0 msec 0 msec 0 msec 388 R1# 390 This example has been included to illustrate an effect. Whether that 391 effect would be problematic would depend on both the deployment 392 scenario and the application in use. 394 Certainly a scenario where the same [RFC1918] address space becomes 395 utilised on both the inside and outside interfaces of a NAT/NAPT 396 device can be problematic. For example, the same private address 397 range is assigned by both the administrator of a corporate network 398 and their ISP. Some applications discover the outside address of 399 their local CPE to determine if that address is reserver for special 400 use. Application behavior may then be based on this determination. 401 [RFC6598] provides further analysis of this situation. 403 To address this scenario and others, [RFC6598] requests a dedicated 404 /10 address block for the purpose of Shared CGN (Carrier Grade NAT) 405 Address Space. The purpose of Shared CGN Address Space is to number 406 CPE (Customer Premise Equipment) interfaces that connect to CGN 407 devices. As explained in [RFC6598], [RFC1918] addressing has issues 408 when used in this deployment scenario. 410 6. Interactions with edge anti-spoofing techniques 412 Denial of Service Attacks (DOS) and Distributed Denial of Service 413 Attacks (DDoS) can make use of spoofed source IP addresses in an 414 attempt to obfuscate the source of an attack. [RFC2827] (Network 415 Ingress Filtering) strongly recommends that providers of Internet 416 connectivity implement filtering to prevent packets using source 417 addresses outside of their legitimately assigned and advertised 418 prefix ranges. Such filtering should also prevent packets with 419 private source addresses from egressing the AS. 421 Best security practices for ISPs also strongly recommend that packets 422 with illegitimate source addresses should be dropped at the AS 423 perimeter. Illegitimate source addresses includes private IP 424 (RFC1918) addresses, addresses within the provider's assigned prefix 425 ranges, and bogons (legitimate but unassigned IP addresses). 426 Additionally, packets with private IP destination addresses should 427 also be dropped at the AS perimeter. 429 If such filtering is properly deployed, then traffic either sourced 430 from, or destined for privately addressed portions of the network 431 should be dropped. Hence the negative consequences on traceroute, 432 PMTUD and regular ping type traffic. 434 7. Peering using loopbacks 436 Although not a common technique, some ISPs use the loopback addresses 437 of border routers (ASBRs) for peering, in particular where multiple 438 connections or exchange points exist between the two ISPs. Such a 439 technique is used by some ISPs as the foundation of fine grained 440 traffic engineering and load balancing through the combination of IGP 441 metrics and multi-hop BGP. When private or non-globally reachable 442 addresses are used as loopback addresses, this technique is either 443 not possible, or considerably more complex to implement. 445 8. DNS Interaction 447 Many ISPs utilise their DNS to perform both forward and reverse 448 resolution for the infrastructure devices and infrastructure 449 addresses. With a privately numbered core, the ISP itself will still 450 have the capability to perform name resolution of their own 451 infrastructure. However others outside of the autonomous system will 452 not have this capability. At best, they will get a number of 453 unidentified [RFC1918] IP addresses returned from a traceroute. 455 It is also worth noting that in some cases the reverse resolution 456 requests may leak outside of the AS. Such a situation can add load 457 to public DNS servers. Further information on this problem is 458 documented in the internet draft "AS112 Nameserver Operations". 460 9. Operational and Troubleshooting issues 462 Previous sections of the document have noted issues relating to 463 network operations and troubleshooting. In particular when private 464 IP addressing within an ISP core is used, the ability to easily 465 troubleshoot across the AS boundary may be limited. In some cases 466 this may be a serious troubleshooting impediment. In other cases, it 467 may be solved through the use of alternative troubleshooting 468 techniques. 470 The key point is that the flexibility of initiating an outbound ping 471 or traceroute from a privately numbered section of the network is 472 lost. In a complex topology, with multiple paths and exit points 473 from the AS, the provider may be restricted in their ability to trace 474 paths through the network to other ASs. Such a situation could be a 475 severe troubleshooting impediment. 477 For users outside of the AS, the loss of the ability to use a 478 traceroute for troubleshooting is very often a serious issue. As 479 soon as many of these people see a row of "* * *" in a traceroute 480 they often incorrectly assume that a large part of the network is 481 down or inaccessible (e.g. behind a firewall). Operational 482 experience in many large providers has shown that significant 483 confusion can result. 485 10. Security Considerations 487 One of the arguments often put forward for the use of private 488 addressing within an ISP is an improvement in the network security. 489 It has been argued that if private addressing is used within the 490 core, the network infrastructure becomes unreachable from outside the 491 providers autonomous system, hence protecting the infrastructure. 492 There is legitimacy to this argument. Certainly if the core is 493 privately numbered and unreachable, it potentially provides a level 494 of isolation in addition to what can be achieved with other 495 techniques, such as infrastructure ACLs, on their own. This is 496 especially true in the event of an ACL misconfiguration, something 497 that does commonly occur as the result of human error. 499 There are three key security gaps that exist in a privately addressed 500 IP core. 502 The approach does not protect against reflection attacks if edge 503 anti-spoofing is not deployed. For example, if a packet with 504 spoofed source address corresponding to the networks 505 infrastructure address range, is sent to a host (or other device) 506 attached to the network, that host will send its response directly 507 to the infrastructure address. If such an attack was performed 508 across a large number of hosts, then a successful large scale 509 denial of service attack on the infrastructure could be achieved. 510 This is not to say that a publicly numbered core will protect from 511 the same attack, it won't. The key point is that a reflection 512 attack does get around the apparent security offered in a 513 privately addressed core. 515 Even if anti-spoofing is deployed at the AS boundary, the border 516 routers will potentially carry routing information for the 517 privately addressed network infrastructure. This can mean that 518 packets with spoofed addresses, corresponding to the private 519 infrastructure addressing, may be considered legitimate by edge 520 anti-spoofing techniques such as Unicast Reverse Path Forwarding - 521 Loose Mode, and forwarded. To avoid this situation, an edge anti- 522 spoofing algorithm such as Unicast Reverse Path Forwarding - 523 Strict Mode, would be required. Strict approaches can be 524 problematic in some environments or where asymmetric traffic paths 525 exist. 527 The approach on its own does not protect the network 528 infrastructure from directly connected customers (i.e. within the 529 same AS). Unless other security controls, such as access control 530 lists (ACLs), are deployed at the ingress point of the network, 531 customer devices will normally be able to reach, and potentially 532 attack, both core and edge infrastructure devices. 534 11. Alternate approaches to core network security 536 Today, hardware-based ACLs, which have minimal to no performance 537 impact, are now widespread. Applying an ACL at the AS perimeter to 538 prevent access to the network core may be a far simpler approach and 539 provide comparable protection to using private addressing; such a 540 technique is known as an infrastructure ACL (iACL). 542 In concept, iACLs provide filtering at the edge network which allows 543 traffic to cross the network core, but not to terminate on 544 infrastructure addresses within the core. Proper iACL deployment 545 will normally allow required network management traffic to be passed, 546 such that traceroutes and PMTUD can still operate successfully. For 547 an iACL deployment to be practical, the core network needs to have 548 been addressed with a relatively small number of contiguous address 549 blocks. For this reason, the technique may or may not be practical. 551 A second approach to preventing external access to the core is IS-IS 552 core hiding. This technique makes use of a fundamental property of 553 the IS-IS protocol which allows link addresses to be removed from the 554 routing table while still allowing loopback addresses to be resolved 555 as next hops for BGP. The technique prevents parties outside the AS 556 from being able to route to infrastructure addresses, while still 557 allowing traceroutes to operate successfully. IS-IS core hiding does 558 not have the same practical requirement for the core to be addressed 559 from a small number of contiguous address blocks as with iACLs. From 560 an operational and troubleshooting perspective, care must be taken to 561 ensure that pings and traceroutes are using source and destination 562 addresses that exist in the routing tables of all routers in the 563 path. i.e. Not hidden link addresses. 565 A third approach is the use of either an MPLS based IP VPN, or an 566 MPLS based IP Core where the 'P' routers (or Label Switch Routers) do 567 not carry global routing information. As the core 'P' routers (or 568 Label Switch Routers) are only switching labeled traffic, they are 569 effectively not reachable from outside of the MPLS domain. The 'P' 570 routers can optionally be hidden such they do not appear in a 571 traceroute. While this approach isolates the 'P' routers from 572 directed attacks, it does not protect the edge routers - being either 573 a 'PE' router or a Label Edge Router (LER). Obviously there are 574 numerous other engineering considerations in such an approach, we 575 simply note it as an option. 577 These techniques may not be suitable for every network, however, 578 there are many circumstances where they can be used successfully 579 without the associated effects of a privately addressing the core. 581 12. Normative References 583 [RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", 584 November 1990. 586 [RFC1393] Malkin, G., "Traceroute Using an IP Option", January 1993. 588 [RFC1918] Rekhter , Y., Moskowitz, R., Karrenberg, D., Jan de Groot, 589 G., and E. Lear , "RFC1918 Address Allocation for Private 590 Internets, BCP 5", Febuary 1996. 592 [RFC2728] Ferguson, P. and D. Senie , "RFC 2827 Network Ingress 593 Filtering, BCP 38", May 2000. 595 [RFC3021] Retana, A., White, R., Fuller, V., and D. McPherson, 596 "Using 31-Bit Prefixes on IPv4 Point-to-Point Links", 597 December 2000. 599 [RFC6304] Abley, J. and W. Maton, "AS112 Nameserver Operations", 600 July 2011. 602 [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and 603 M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address 604 Space", April 2012. 606 [RFC792] Postel, J., "RFC792 Internet Control Message Protocol", 607 September 1981. 609 Appendix A. Acknowledgments 611 The author would like to thank the following people for their input 612 and review - Dan Wing (Cisco Systems), Roland Dobbins (Arbor 613 Networks), Philip Smith (APNIC), Barry Greene (ISC), Anton Ivanov 614 (kot-begemot.co.uk), Ryan Mcdowell (Cisco Systems), Russ White (Cisco 615 Systems), Gregg Schudel (Cisco Systems), Michael Behringer (Cisco 616 Systems), Stephan Millet (Cisco Systems), Tom Petch (BT Connect), Wes 617 George (Time Warner Cable). 619 The author would also like to acknowledge the use of a variety of 620 NANOG mail archives as references. 622 Author's Address 624 Anthony Kirkham 625 Palo Alto Networks 626 Level 32, 101 Miller St 627 North Sydney, New South Wales 2060 628 Australia 630 Phone: +61 7 33530902 631 Email: tkirkham@paloaltonetworks.com