idnits 2.17.1 draft-ietf-grow-private-ip-sp-cores-01.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 292: '...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 (April 10, 2012) is 4389 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '3' on line 260 -- Looks like a reference, but probably isn't: '1' on line 261 -- Looks like a reference, but probably isn't: '30' on line 262 -- Looks like a reference, but probably isn't: '33434' on line 263 == Missing Reference: 'AS 64497' is mentioned on line 272, but not defined == Unused Reference: 'RFC1191' is defined on line 587, but no explicit reference was found in the text == Unused Reference: 'RFC1393' is defined on line 590, but no explicit reference was found in the text == Unused Reference: 'RFC1918' is defined on line 592, but no explicit reference was found in the text == Unused Reference: 'RFC2728' is defined on line 596, but no explicit reference was found in the text == Unused Reference: 'RFC6304' is defined on line 603, 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 (~~), 9 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) April 10, 2012 5 Intended status: Informational 6 Expires: October 12, 2012 8 Issues with Private IP Addressing in the Internet 9 draft-ietf-grow-private-ip-sp-cores-01 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 October 12, 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 . . . . . . . . . . . . . . . . . . . 11 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 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 1. Introduction 84 In the mid to late 90's, some Internet Service Providers (ISPs) 85 adopted the practice of utilising private (or non-globally unique) IP 86 (i.e. RFC1918) addresses for the infrastructure links and in some 87 cases the loopback interfaces within their networks. The reasons for 88 this approach centered on conservation of address space (i.e. 89 scarcity of public IPv4 address space), and security of the core 90 network (also known as core hiding). 92 However, a number of technical and operational issues occurred as a 93 result of using private (or non-globally unique) IP addresses, and 94 virtually all these ISPs moved away from the practice. Tier 1 ISPs 95 are considered the benchmark of the industry and as of the time of 96 writing, there is no known tier 1 ISP that utilises the practice of 97 private addressing within their core network. 99 The following sections will discuss the various issues associated 100 with deploying private IP (i.e. RFC1918) addresses within ISP core 101 networks. 103 The intent of this document is not to suggest that private IP can not 104 be used with the core of an SP network as some providers use this 105 practice and operate successfully. The intent is to outline the 106 potential issues or effects of such a practice. 108 Note: The practice of ISPs using 'stolen' address space (also known 109 as 'squat' space) has many of the same issues (or effects) as that of 110 using private IP address space within core networks. The term 111 "stolen IP address space" refers to the practice of an ISP using 112 address space for its own infrastructure/core network addressing that 113 has been officially allocated by an RIR to another provider, but that 114 provider is not currently using or advertising within the Internet. 115 Stolen addressing is not discussed further in this document. It is 116 simply noted as an associated issue. 118 2. Conservation of Address Space 120 One of the original intents for the use of private IP addressing 121 within an ISP core was the conservation of IP address space. When an 122 ISP is allocated a block of public IP addresses (from a RIR), this 123 address block was traditionally split in order to dedicate some 124 portion for infrastructure use (i.e. for the core network), and the 125 other portion for customer (subscriber) or other address pool use. 126 Typically, the number of infrastructure addresses needed is 127 relatively small in comparison to the total address count. So unless 128 the ISP was only granted a small public block, dedicating some 129 portion to infrastructure links and loopback addresses (/32) is 130 rarely a large enough issue to outweigh the problems that are 131 potentially caused when private address space is used. 133 Additionally, specifications and equipment capability improvements 134 now allow for the use of /31 subnets [RFC3021] for link addresses in 135 place of the original /30 subnets - further minimising the impact of 136 dedicating public addresses to infrastructure links by only using two 137 (2) IP addresses per point to point link versus four (4) 138 respectively. 140 The use of private addressing as a conservation technique within an 141 Internet Service Provider (ISP) core can cause a number of technical 142 and operational issues or effects. The main effects are described 143 below. 145 3. Effects on Traceroute 147 The single biggest effect caused by the use of private (RFC1918) 148 addressing within an Internet core is the fact that it can disrupt 149 the operation of traceroute in some situations. This section 150 provides some examples of the issues that can occur. 152 A first example illustrates the situation where the traceroute 153 crosses an AS boundary and one of the networks has utilised private 154 addressing. The following simple network is used to show the 155 effects. 157 AS64496 EBGP AS64497 158 IBGP Mesh <---------------> IBGP Mesh 160 R1 Pool - R6 Pool - 161 203.0.113.0/26 203.0.113.64/26 163 198.51.100.8/30 164 198.51.100.4/30 165 10.1.1.0/30 10.1.1.4/30 198.51.100.0/30 166 .9 .10 167 .1 .2 .5 .6 ------------ .6 .5 .2 .1 168 R1-----------R2-----------R3--| |--R4----------R5----------R6 170 R1 Loopback: 10.1.1.101 R4 Loopback: 198.51.100.103 171 R2 Loopback: 10.1.1.102 R5 Loopback: 198.51.100.102 172 R3 Loopback: 10.1.1.103 R6 Loopback: 198.51.100.101 173 Using this example, performing the traceroute from AS64497 to 174 AS64496, we can see the private addresses of the infrastructure links 175 in AS64496 are returned. 177 R6#traceroute 203.0.113.1 178 Type escape sequence to abort. 179 Tracing the route to 203.0.113.1 181 1 198.51.100.2 40 msec 20 msec 32 msec 182 2 198.51.100.6 16 msec 20 msec 20 msec 183 3 198.51.100.9 20 msec 20 msec 32 msec 184 4 10.1.1.5 20 msec 20 msec 20 msec 185 5 10.1.1.1 20 msec 20 msec 20 msec 186 R6# 188 This effect in itself is often not a problem. However, if anti- 189 spoofing controls are applied at network perimeters, then responses 190 returned from hops with private IP addresses will be dropped. Anti- 191 spoofing refers to a security control where traffic with an invalid 192 source address is discarded. Anti-spoofing is further described in 193 BCP 38/RFC 2827. 195 The effects are illustrated in a second example below. The same 196 network as example 1 is used, but with the addition of anti-spoofing 197 deployed at the ingress of R4 on the R3-R4 interface (ip address 198 198.51.100.10). 200 R6#traceroute 203.0.113.1 202 Type escape sequence to abort. 203 Tracing the route to 203.0.113.1 205 1 198.51.100.2 24 msec 20 msec 20 msec 206 2 198.51.100.6 20 msec 52 msec 44 msec 207 3 198.51.100.9 44 msec 20 msec 32 msec 208 4 * * * 209 5 * * * 210 6 * * * 211 7 * * * 212 8 * * * 213 9 * * * 214 10 * * * 215 11 * * * 216 12 * * * 218 In a third example, a similar effect is caused. If a traceroute is 219 initiated from a router with a private (source) IP address, located 220 in AS64496 and the destination is outside of the ISPs AS (AS64497), 221 then in this situation the traceroute will fail completely beyond the 222 AS boundary. 224 R1# traceroute 203.0.113.65 225 Type escape sequence to abort. 226 Tracing the route to 203.0.113.65 228 1 10.1.1.2 20 msec 20 msec 20 msec 229 2 10.1.1.6 52 msec 24 msec 40 msec 230 3 * * * 231 4 * * * 232 5 * * * 233 6 * * * 234 R1# 236 While it is completely unreasonable to expect a packet with a private 237 source address to be successfully returned in a typical SP 238 environment, the case is included to show the effect as it can have 239 implications for troubleshooting. This case will be referenced in a 240 later section. 242 In a complex topology, with multiple paths and exit points, the 243 provider will lose their ability to trace paths originating within 244 their own AS, through their network, to destinations within other 245 ASs. Such a situation could be a severe troubleshooting impediment. 247 For completeness, a fourth example is included to show that a 248 successful traceroute can be achieved by specifying a public source 249 address as the source address of the traceroute. Such an approach 250 can be used in many operational situations if the router initiating 251 the traceroute has at least one public address configured. However, 252 the approach is more cumbersome. 254 R1#traceroute 255 Protocol [ip]: 256 Target IP address: 203.0.113.65 257 Source address: 203.0.113.1 258 Numeric display [n]: 259 Timeout in seconds [3]: 260 Probe count [3]: 261 Minimum Time to Live [1]: 262 Maximum Time to Live [30]: 10 263 Port Number [33434]: 264 Loose, Strict, Record, Timestamp, Verbose[none]: 265 Type escape sequence to abort. 266 Tracing the route to 203.0.113.65 268 1 10.1.1.2 0 msec 4 msec 0 msec 269 2 10.1.1.6 0 msec 4 msec 0 msec 270 3 198.51.100.10 [AS 64497] 0 msec 4 msec 0 msec 271 4 198.51.100.5 [AS 64497] 0 msec 0 msec 4 msec 272 5 198.51.100.1 [AS 64497] 0 msec 0 msec 4 msec 273 R1# 275 It should be noted that some solutions to this problem have been 276 proposed in RFC 5837 which provides extensions to ICMP to allow the 277 identification of interfaces and their components by any combination 278 of the following: ifIndex, IPv4 address, IPv6 address, name, and 279 MTU. However at the time of writing, little or no deployment was 280 known to be in place. 282 4. Effects on Path MTU Discovery 284 The Path MTU Discovery (PMTUD) process was designed to allow hosts to 285 make an accurate assessment of the maximum packet size that can be 286 sent across a path without fragmentation. Path MTU Discovery is 287 supported for TCP (and other protocols that support PMTUD such as GRE 288 and IPsec) and works as follows: 290 o When a router attempts to forward an IP datagram with the Do Not 291 Fragment (DF) bit set out a link that has a lower MTU than the size 292 of the packet, the router MUST drop the packet and return an Internet 293 Control Message Protocol (ICMP) 'destination unreachable - 294 fragmentation needed and DF set (type 3, code 4)' message to the 295 source of the IP datagram. This message includes the MTU of that 296 next-hop network. As a result, the source station which receives the 297 ICMP message, will lower the send Maximum Segment Size (MSS). 299 It is obviously desirable that packets be sent between two 300 communicating hosts without fragmentation as this process imposes 301 extra load on the fragmenting router (process of fragmentation), 302 intermediate routers (forwarding additional packets), as well as the 303 receiving host (reassembly of the fragmented packets). Additionally, 304 many applications, including some web servers, set the DF (do not 305 fragment) bit causing undesirable interactions if the path MTU is 306 insufficient. Other TCP implementations may set an MTU size of 576 307 bytes if PMTUD is unavailable. In addition, IPsec and other 308 tunneling protocols will often require MTUs greater than 1500 bytes 309 and often rely on PMTUD. 311 While it is uncommon these days for core SP networks not to support 312 path MTUs in excess of 1500 bytes (with 4470 or greater being 313 common), the situation of 1500 byte path MTUs is still common in many 314 ethernet edge or aggregation networks. 316 The issue is as follows: 318 o When an ICMP Type 3 Code 4 message is issued from an infrastructure 319 link that uses a private (RFC1918) address, it must be routed back to 320 the originating host. As the originating host will typically be a 321 globally routable IP address, its source address is used as the 322 destination address of the returned ICMP Type 3 packet. At this 323 point there are normally no problems. 325 o As the returned packet will have an RFC1918 source address, 326 problems can occur when the returned packet passes through an anti- 327 spoofing security control (such as Unicast RPF (uRPF)), other anti- 328 spoofing ACLs, or virtually any perimeter firewall. These devices 329 will typically drop packets with an RFC1918 source address, breaking 330 the successful operation of PMTUD. 332 As a result, the potential for application level issues may be 333 created. 335 5. Unexpected interactions with some NAT implementations 337 Private addressing is legitimately used within many enterprise, 338 corporate or government networks for internal network addressing. 339 When users on the inside of the network require Internet access, they 340 will typically connect through a perimeter router, firewall, or 341 network proxy, that provides Network Address Translation (NAT) or 342 Network Address Port Translation (NAPT) services to a public 343 interface. 345 Scarcity of public IPv4 addresses, and the transition to IPv6, is 346 forcing many service providers to make use of NAT. CGN (Carrier 347 Grade NAT) will enable service providers to assign private RFC 1918 348 IPv4 addresses to their customers rather than public, globally unique 349 IPv4 addresses. NAT444 will make use of a double NAT process. 351 Unpredictable or confusing interactions could occur if traffic such 352 as traceroute, PMTUD and possibly other applications were launched 353 from the NAT IPv4 'inside address' and it passed over the same 354 address range in the public IP core. While such a situation would be 355 unlikely to occur if the NAT pools and the private infrastructure 356 addressing were under the same administration, such a situation could 357 occur in the more typical situation of a NAT'ed corporate network 358 connecting to an ISP. For example, say if 10.1.1.0/24 is used to 359 internally number the corporate network. A traceroute or PMTUD 360 request is initiated inside the corporate network from say 10.1.1.1. 361 The packet passes through a NAT (or NAPT) gateway, then over an ISP 362 core numbered from the same range. When the responses are delivered 363 back to the originator, the returned packets from the privately 364 addressed part of the ISP core could have an identical source and 365 destination address of 10.1.1.1. 367 NAT Pool - 368 203.0.113.0/24 370 10.1.1.0/30 10.1.1.0/30 198.51.100.0/30 371 198.51.100.12/30 198.51.100.4/30 373 .1 .2 .14 .13 .1 .2 .6 .5 .2 .1 374 R1-----------R2-----------R3---------------R4----------R5----------R6 375 NAT 376 R6 Loopback: 377 198.51.100.100 379 R1#traceroute 198.51.100.100 381 Type escape sequence to abort. 382 Tracing the route to 198.51.100.100 384 1 10.1.1.2 0 msec 0 msec 0 msec 385 2 198.51.100.13 0 msec 4 msec 0 msec 386 3 10.1.1.2 0 msec 4 msec 0 msec <<<< 387 4 198.51.100.5 4 msec 0 msec 4 msec 388 5 198.51.100.1 0 msec 0 msec 0 msec 389 R1# 391 This example has been included to illustrate an effect. Whether that 392 effect would be problematic would depend on both the deployment 393 scenario and the application in use. 395 Certainly a scenario where the same RFC1918 address space becomes 396 utilised on both the inside and outside interfaces of a NAT/NAPT 397 device can be problematic. For example, the same private address 398 range is assigned by both the administrator of a corporate network 399 and their ISP. Some applications discover the outside address of 400 their local CPE to determine if that address is reserver for special 401 use. Application behavior may then be based on this determination. 402 [weil-shared-transition-space-request] provides further analysis of 403 this situation. 405 To address this scenario and others, at the time of writing, work was 406 in progress to obtain a dedicated /10 address block for the purpose 407 of Shared CGN (Carrier Grade NAT) Address Space. Please refer to 408 [weil-shared-transition-space-request] for details. The purpose of 409 Shared CGN Address Space is to number CPE (Customer Premise 410 Equipment) interfaces that connect to CGN devices. As explained in 411 [weil-shared-transition-space-request], RFC1918 addressing has issues 412 when used in this deployment scenario. 414 6. Interactions with edge anti-spoofing techniques 416 Denial of service attacks and distributed denial of attacks can make 417 use of spoofed source IP addresses in an attempt to obfuscate the 418 source of an attack. RFC2827 (Network Ingress Filtering) strongly 419 recommends that providers of Internet connectivity implement 420 filtering to prevent packets using source addresses outside of their 421 legitimately assigned and advertised prefix ranges. Such filtering 422 should also prevent packets with private source addresses from 423 egressing the AS. 425 Best security practices for ISPs also strongly recommend that packets 426 with illegitimate source addresses should be dropped at the AS 427 perimeter. Illegitimate source addresses includes private IP 428 (RFC1918) addresses, addresses within the provider's assigned prefix 429 ranges, and bogons (legitimate but unassigned IP addresses). 430 Additionally, packets with private IP destination addresses should 431 also be dropped at the AS perimeter. 433 If such filtering is properly deployed, then traffic either sourced 434 from, or destined for privately addressed portions of the network 435 should be dropped. Hence the negative consequences on traceroute, 436 PMTUD and regular ping type traffic. 438 7. Peering using loopbacks 440 Although not a common technique, some ISPs use the loopback addresses 441 of border routers (ASBRs) for peering, in particular where multiple 442 connections or exchange points exist between the two ISPs. Such a 443 technique is used by some ISPs as the foundation of fine grained 444 traffic engineering and load balancing through the combination of IGP 445 metrics and multi-hop BGP. When private or non-globally reachable 446 addresses are used as loopback addresses, this technique is either 447 not possible, or considerably more complex to implement. 449 8. DNS Interaction 451 Many ISPs utilise their DNS to perform both forward and reverse 452 resolution for the infrastructure devices and infrastructure 453 addresses. With a privately numbered core, the ISP itself will still 454 have the capability to perform name resolution of their own 455 infrastructure. However others outside of the autonomous system will 456 not have this capability. At best, they will get a number of 457 unidentified RFC1918 IP addresses returned from a traceroute. 459 It is also worth noting that in some cases the reverse resolution 460 requests may leak outside of the AS. Such a situation can add load 461 to public DNS servers. Further information on this problem is 462 documented in the internet draft "AS112 Nameserver Operations". 464 9. Operational and Troubleshooting issues 466 Previous sections of the document have noted issues relating to 467 network operations and troubleshooting. In particular when private 468 IP addressing within an ISP core is used, the ability to easily 469 troubleshoot across the AS boundary may be limited. In some cases 470 this may be a serious troubleshooting impediment. In other cases, it 471 may be solved through the use of alternative troubleshooting 472 techniques. 474 The key point is that the flexibility of initiating an outbound ping 475 or traceroute from a privately numbered section of the network is 476 lost. In a complex topology, with multiple paths and exit points 477 from the AS, the provider may be restricted in their ability to trace 478 paths through the network to other ASs. Such a situation could be a 479 severe troubleshooting impediment. 481 For users outside of the AS, the loss of the ability to use a 482 traceroute for troubleshooting is very often a serious issue. As 483 soon as many of these people see a row of "* * *" in a traceroute 484 they often incorrectly assume that a large part of the network is 485 down or inaccessible (e.g. behind a firewall). Operational 486 experience in many large providers has shown that significant 487 confusion can result. 489 10. Security Considerations 491 One of the arguments often put forward for the use of private 492 addressing within an ISP is an improvement in the network security. 493 It has been argued that if private addressing is used within the 494 core, the network infrastructure becomes unreachable from outside the 495 providers autonomous system, hence protecting the infrastructure. 496 There is legitimacy to this argument. Certainly if the core is 497 privately numbered and unreachable, it potentially provides a level 498 of isolation in addition to what can be achieved with other 499 techniques, such as infrastructure ACLs, on their own. This is 500 especially true in the event of an ACL misconfiguration, something 501 that does commonly occur as the result of human error. 503 There are three key security gaps that exist in a privately addressed 504 IP core. 506 The approach does not protect against reflection attacks if edge 507 anti-spoofing is not deployed. For example, if a packet with 508 spoofed source address corresponding to the networks 509 infrastructure address range, is sent to a host (or other device) 510 attached to the network, that host will send its response directly 511 to the infrastructure address. If such an attack was performed 512 across a large number of hosts, then a successful large scale 513 denial of service attack on the infrastructure could be achieved. 514 This is not to say that a publicly numbered core will protect from 515 the same attack, it won't. The key point is that a reflection 516 attack does get around the apparent security offered in a 517 privately addressed core. 519 Even if anti-spoofing is deployed at the AS boundary, the border 520 routers will potentially carry routing information for the 521 privately addressed network infrastructure. This can mean that 522 packets with spoofed addresses, corresponding to the private 523 infrastructure addressing, may be considered legitimate by edge 524 anti-spoofing techniques such as Unicast Reverse Path Forwarding - 525 Loose Mode, and forwarded. To avoid this situation, an edge anti- 526 spoofing algorithm such as Unicast Reverse Path Forwarding - 527 Strict Mode, would be required. Strict approaches can be 528 problematic in some environments or where asymmetric traffic paths 529 exist. 531 The approach on its own does not protect the network 532 infrastructure from directly connected customers (i.e. within the 533 same AS). Unless other security controls, such as access control 534 lists (ACLs), are deployed at the ingress point of the network, 535 customer devices will normally be able to reach, and potentially 536 attack, both core and edge infrastructure devices. 538 11. Alternate approaches to core network security 540 Today, hardware-based ACLs, which have minimal to no performance 541 impact, are now widespread. Applying an ACL at the AS perimeter to 542 prevent access to the network core may be a far simpler approach and 543 provide comparable protection to using private addressing, Such a 544 technique is known as an infrastructure ACL (iACL). 546 In concept, iACLs provide filtering at the edge network which allows 547 traffic to cross the network core, but not to terminate on 548 infrastructure addresses within the core. Proper iACL deployment 549 will normally allow required network management traffic to be passed, 550 such that traceroutes and PMTUD can still operate successfully. For 551 an iACL deployment to be practical, the core network needs to have 552 been addressed with a relatively small number of contiguous address 553 blocks. For this reason, the technique may or may not be practical. 555 A second approach to preventing external access to the core is IS-IS 556 core hiding. This technique makes use of a fundamental property of 557 the IS-IS protocol which allows link addresses to be removed from the 558 routing table while still allowing loopback addresses to be resolved 559 as next hops for BGP. The technique prevents parties outside the AS 560 from being able to route to infrastructure addresses, while still 561 allowing traceroutes to operate successfully. IS-IS core hiding does 562 not have the same practical requirement for the core to be addressed 563 from a small number of contiguous address blocks as with iACLs. From 564 an operational and troubleshooting perspective, care must be taken to 565 ensure that pings and traceroutes are using source and destination 566 addresses that exist in the routing tables of all routers in the 567 path. i.e. Not hidden link addresses. 569 A third approach is the use of either an MPLS based IP VPN, or an 570 MPLS based IP Core where the 'P' routers (or Label Switch Routers) do 571 not carry global routing information. As the core 'P' routers (or 572 Label Switch Routers) are only switching labeled traffic, they are 573 effectively not reachable from outside of the MPLS domain. The 'P' 574 routers can optionally be hidden such they do not appear in a 575 traceroute. While this approach isolates the 'P' routers from 576 directed attacks, it does not protect the edge routers - being either 577 a 'PE' router or a Label Edge Router (LER). Obviously there are 578 numerous other engineering considerations in such an approach, we 579 simply note it as an option. 581 These techniques may not be suitable for every network, however, 582 there are many circumstances where they can be used successfully 583 without the associated effects of a privately addressing the core. 585 12. Normative References 587 [RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", 588 November 1990. 590 [RFC1393] Malkin, G., "Traceroute Using an IP Option", January 1993. 592 [RFC1918] Rekhter , Y., Moskowitz, R., Karrenberg, D., Jan de Groot, 593 G., and E. Lear , "RFC1918 Address Allocation for Private 594 Internets, BCP 5", Febuary 1996. 596 [RFC2728] Ferguson, P. and D. Senie , "RFC 2827 Network Ingress 597 Filtering, BCP 38", May 2000. 599 [RFC3021] Retana, A., White, R., Fuller, V., and D. McPherson, 600 "Using 31-Bit Prefixes on IPv4 Point-to-Point Links", 601 December 2000. 603 [RFC6304] Abley, J. and W. Maton, "AS112 Nameserver Operations", 604 July 2011. 606 [RFC792] Postel, J., "RFC792 Internet Control Message Protocol", 607 September 1981. 609 [weil-shared-transition-space-request] 610 Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and 611 M. Azinger, "IANA Reserved IPv4 Prefix for Shared CGN 612 Space". 614 Appendix A. Acknowledgments 616 The author would like to thank the following people for their input 617 and review - Dan Wing (Cisco Systems), Roland Dobbins (Arbor 618 Networks), Philip Smith (APNIC), Barry Greene (ISC), Anton Ivanov 619 (kot-begemot.co.uk), Ryan Mcdowell (Cisco Systems), Russ White (Cisco 620 Systems), Gregg Schudel (Cisco Systems), Michael Behringer (Cisco 621 Systems), Stephan Millet (Cisco Systems), Tom Petch (BT Connect), Wes 622 George (Time Warner Cable). 624 The author would also like to acknowledge the use of a variety of 625 NANOG mail archives as references. 627 Index 629 H 630 http://tools.ietf.org/html/draft-ietf-dnsop-as112-ops-08 11 631 http://tools.ietf.org/html/rfc2827 5 633 Author's Address 635 Anthony Kirkham 636 Palo Alto Networks 637 Level 32, 101 Miller St 638 North Sydney, New South Wales 2060 639 Australia 641 Phone: +61 7 33530902 642 Email: tkirkham@paloaltonetworks.com