idnits 2.17.1 draft-ietf-grow-private-ip-sp-cores-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 16, 2012) is 4329 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '3' on line 263 -- Looks like a reference, but probably isn't: '1' on line 264 -- Looks like a reference, but probably isn't: '30' on line 265 -- Looks like a reference, but probably isn't: '33434' on line 266 == Missing Reference: 'AS 64497' is mentioned on line 275, but not defined == Unused Reference: 'BCP38' is defined on line 556, but no explicit reference was found in the text == Unused Reference: 'BCP84' is defined on line 560, but no explicit reference was found in the text == Unused Reference: 'RFC1393' is defined on line 566, but no explicit reference was found in the text == Unused Reference: 'RFC3704' is defined on line 578, but no explicit reference was found in the text == Unused Reference: 'RFC792' is defined on line 598, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1393 (Obsoleted by RFC 6814) ** Obsolete normative reference: RFC 1981 (Obsoleted by RFC 8201) -- Obsolete informational reference (is this intentional?): RFC 6304 (Obsoleted by RFC 7534) Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 6 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) June 16, 2012 5 Intended status: Informational 6 Expires: December 18, 2012 8 Issues with Private IP Addressing in the Internet 9 draft-ietf-grow-private-ip-sp-cores-05 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 December 18, 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 . . . . . . . 9 72 7. Peering using loopbacks . . . . . . . . . . . . . . . . . . . 10 73 8. DNS Interaction . . . . . . . . . . . . . . . . . . . . . . . 10 74 9. Operational and Troubleshooting issues . . . . . . . . . . . . 10 75 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 76 11. Alternate approaches to core network security . . . . . . . . 12 77 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 12.1. Normative References . . . . . . . . . . . . . . . . . . 13 79 12.2. Informative References . . . . . . . . . . . . . . . . . 14 80 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 14 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 1. Introduction 85 In the mid to late 90's, some Internet Service Providers (ISPs) 86 adopted the practice of utilising private (or non-globally unique) 87 [RFC1918] IP addresses for the infrastructure links and in some cases 88 the loopback interfaces within their networks. The reasons for this 89 approach centered on conservation of address space (i.e. scarcity of 90 public IPv4 address space), and security of the core network (also 91 known as core hiding). 93 However, a number of technical and operational issues occurred as a 94 result of using private (or non-globally unique) IP addresses, and 95 virtually all these ISPs moved away from the practice. Tier 1 ISPs 96 are considered the benchmark of the industry and as of the time of 97 writing, there is no known tier 1 ISP that utilises the practice of 98 private addressing within their core network. 100 The following sections will discuss the various issues associated 101 with deploying private [RFC1918] IP addresses within ISP core 102 networks. 104 The intent of this document is not to suggest that private IP can not 105 be used with the core of an SP network as some providers use this 106 practice and operate successfully. The intent is to outline the 107 potential issues or effects of such a practice. 109 Note: The practice of ISPs using 'stolen' address space (also known 110 as 'squat' space) has many of the same, plus some additional issues 111 (or effects) as that of using private IP address space within core 112 networks. The term "stolen IP address space" refers to the practice 113 of an ISP using address space for its own infrastructure/core network 114 addressing that has been officially allocated by an RIR to another 115 provider, but that provider is not currently using or advertising 116 within the Internet. Stolen addressing is not discussed further in 117 this document. It is simply noted as an associated issue. 119 2. Conservation of Address Space 121 One of the original intents for the use of private IP addressing 122 within an ISP core was the conservation of IP address space. When an 123 ISP is allocated a block of public IP addresses (from a RIR), this 124 address block was traditionally split in order to dedicate some 125 portion for infrastructure use (i.e. for the core network), and the 126 other portion for customer (subscriber) or other address pool use. 127 Typically, the number of infrastructure addresses needed is 128 relatively small in comparison to the total address count. So unless 129 the ISP was only granted a small public block, dedicating some 130 portion to infrastructure links and loopback addresses (/32) is 131 rarely a large enough issue to outweigh the problems that are 132 potentially caused when private address space is used. 134 Additionally, specifications and equipment capability improvements 135 now allow for the use of /31 subnets [RFC3021] for link addresses in 136 place of the original /30 subnets - further minimising the impact of 137 dedicating public addresses to infrastructure links by only using two 138 (2) IP addresses per point to point link versus four (4) 139 respectively. 141 The use of private addressing as a conservation technique within an 142 Internet Service Provider (ISP) core can cause a number of technical 143 and operational issues or effects. The main effects are described 144 below. 146 3. Effects on Traceroute 148 The single biggest effect caused by the use of private [RFC1918] 149 addressing within an Internet core is the fact that it can disrupt 150 the operation of traceroute in some situations. This section 151 provides some examples of the issues that can occur. 153 A first example illustrates the situation where the traceroute 154 crosses an AS boundary and one of the networks has utilised private 155 addressing. The following simple network is used to show the 156 effects. 158 AS64496 EBGP AS64497 159 IBGP Mesh <---------------> IBGP Mesh 161 R1 Pool - R6 Pool - 162 203.0.113.0/26 203.0.113.64/26 164 198.51.100.8/30 165 198.51.100.4/30 166 10.1.1.0/30 10.1.1.4/30 198.51.100.0/30 167 .9 .10 168 .1 .2 .5 .6 ------------ .6 .5 .2 .1 169 R1-----------R2-----------R3--| |--R4----------R5----------R6 171 R1 Loopback: 10.1.1.101 R4 Loopback: 198.51.100.103 172 R2 Loopback: 10.1.1.102 R5 Loopback: 198.51.100.102 173 R3 Loopback: 10.1.1.103 R6 Loopback: 198.51.100.101 174 Using this example, performing the traceroute from AS64497 to 175 AS64496, we can see the private addresses of the infrastructure links 176 in AS64496 are returned. 178 R6#traceroute 203.0.113.1 179 Type escape sequence to abort. 180 Tracing the route to 203.0.113.1 182 1 198.51.100.2 40 msec 20 msec 32 msec 183 2 198.51.100.6 16 msec 20 msec 20 msec 184 3 198.51.100.9 20 msec 20 msec 32 msec 185 4 10.1.1.5 20 msec 20 msec 20 msec 186 5 10.1.1.1 20 msec 20 msec 20 msec 187 R6# 189 This effect in itself is often not a problem. However, if anti- 190 spoofing controls are applied at network perimeters, then responses 191 returned from hops with private IP addresses will be dropped. Anti- 192 spoofing refers to a security control where traffic with an invalid 193 source address is discarded. Anti-spoofing is further described in 194 [BCP38]/[RFC2827]and[BCP84]/[RFC3704]. Additionally any RFC1918 195 filtering mechanism, such as those employed in most firewalls and 196 many other network devices can cause the same effect. 198 The effects are illustrated in a second example below. The same 199 network as example 1 is used, but with the addition of anti-spoofing 200 deployed at the ingress of R4 on the R3-R4 interface (IP Address 201 198.51.100.10). 203 R6#traceroute 203.0.113.1 205 Type escape sequence to abort. 206 Tracing the route to 203.0.113.1 208 1 198.51.100.2 24 msec 20 msec 20 msec 209 2 198.51.100.6 20 msec 52 msec 44 msec 210 3 198.51.100.9 44 msec 20 msec 32 msec 211 4 * * * 212 5 * * * 213 6 * * * 214 7 * * * 215 8 * * * 216 9 * * * 217 10 * * * 218 11 * * * 219 12 * * * 221 In a third example, a similar effect is caused. If a traceroute is 222 initiated from a router with a private (source) IP address, located 223 in AS64496 and the destination is outside of the ISPs AS (AS64497), 224 then in this situation the traceroute will fail completely beyond the 225 AS boundary. 227 R1# traceroute 203.0.113.65 228 Type escape sequence to abort. 229 Tracing the route to 203.0.113.65 231 1 10.1.1.2 20 msec 20 msec 20 msec 232 2 10.1.1.6 52 msec 24 msec 40 msec 233 3 * * * 234 4 * * * 235 5 * * * 236 6 * * * 237 R1# 239 While it is completely unreasonable to expect a packet with a private 240 source address to be successfully returned in a typical SP 241 environment, the case is included to show the effect as it can have 242 implications for troubleshooting. This case will be referenced in a 243 later section. 245 In a complex topology, with multiple paths and exit points, the 246 provider will lose their ability to trace paths originating within 247 their own AS, through their network, to destinations within other 248 ASs. Such a situation could be a severe troubleshooting impediment. 250 For completeness, a fourth example is included to show that a 251 successful traceroute can be achieved by specifying a public source 252 address as the source address of the traceroute. Such an approach 253 can be used in many operational situations if the router initiating 254 the traceroute has at least one public address configured. However, 255 the approach is more cumbersome. 257 R1#traceroute 258 Protocol [ip]: 259 Target IP address: 203.0.113.65 260 Source address: 203.0.113.1 261 Numeric display [n]: 262 Timeout in seconds [3]: 263 Probe count [3]: 264 Minimum Time to Live [1]: 265 Maximum Time to Live [30]: 10 266 Port Number [33434]: 267 Loose, Strict, Record, Timestamp, Verbose[none]: 268 Type escape sequence to abort. 269 Tracing the route to 203.0.113.65 271 1 10.1.1.2 0 msec 4 msec 0 msec 272 2 10.1.1.6 0 msec 4 msec 0 msec 273 3 198.51.100.10 [AS 64497] 0 msec 4 msec 0 msec 274 4 198.51.100.5 [AS 64497] 0 msec 0 msec 4 msec 275 5 198.51.100.1 [AS 64497] 0 msec 0 msec 4 msec 276 R1# 278 It should be noted that some solutions to this problem have been 279 proposed in [RFC5837] which provides extensions to ICMP to allow the 280 identification of interfaces and their components by any combination 281 of the following: ifIndex, IPv4 address, IPv6 address, name, and 282 MTU. However at the time of writing, little or no deployment was 283 known to be in place. 285 4. Effects on Path MTU Discovery 287 The Path MTU Discovery (PMTUD) process was designed to allow hosts to 288 make an accurate assessment of the maximum packet size that can be 289 sent across a path without fragmentation. Path MTU Discovery is 290 supported by TCP over IPv4 [RFC1191], TCP over IPv6 [RFC1981] and 291 some tunneling protocols such as GRE and IPSEC. 293 The PMTUD mechanism requires that an intermediate router can reply to 294 the source address of an IP packet with an ICMP reply which uses the 295 router's interface address. If the router's interface address is a 296 private IP address, then this ICMP reply packet may be discarded due 297 to uRPF or ingress filtering, thereby causing the PMTUD mechanism to 298 fail. If the PMTUD mechanism fails, this will cause transmission of 299 data between the two hosts to fail silently due to the traffic being 300 black-holed. As a result, the potential for application level issues 301 may be created. 303 5. Unexpected interactions with some NAT implementations 305 Private addressing is legitimately used within many enterprise, 306 corporate or government networks for internal network addressing. 307 When users on the inside of the network require Internet access, they 308 will typically connect through a perimeter router, firewall, or 309 network proxy, that provides Network Address Translation (NAT) or 310 Network Address Port Translation (NAPT) services to a public 311 interface. 313 Scarcity of public IPv4 addresses, and the transition to IPv6, is 314 forcing many service providers to make use of NAT. CGN (Carrier 315 Grade NAT) will enable service providers to assign private [RFC1918] 316 IPv4 addresses to their customers rather than public, globally unique 317 IPv4 addresses. NAT444 will make use of a double NAT process. 319 Unpredictable or confusing interactions could occur if traffic such 320 as traceroute, PMTUD and possibly other applications were launched 321 from the NAT IPv4 'inside address' and it passed over the same 322 address range in the public IP core. While such a situation would be 323 unlikely to occur if the NAT pools and the private infrastructure 324 addressing were under the same administration, such a situation could 325 occur in the more typical situation of a NAT'ed corporate network 326 connecting to an ISP. For example, say if 10.1.1.0/24 is used to 327 internally number the corporate network. A traceroute or PMTUD 328 request is initiated inside the corporate network from say 10.1.1.1. 329 The packet passes through a NAT (or NAPT) gateway, then over an ISP 330 core numbered from the same range. When the responses are delivered 331 back to the originator, the returned packets from the privately 332 addressed part of the ISP core could have an identical source and 333 destination address of 10.1.1.1. 335 NAT Pool - 336 203.0.113.0/24 338 10.1.1.0/30 10.1.1.0/30 198.51.100.0/30 339 198.51.100.12/30 198.51.100.4/30 341 .1 .2 .14 .13 .1 .2 .6 .5 .2 .1 342 R1-----------R2-----------R3---------------R4----------R5----------R6 343 NAT 344 R6 Loopback: 345 198.51.100.100 347 R1#traceroute 198.51.100.100 349 Type escape sequence to abort. 350 Tracing the route to 198.51.100.100 352 1 10.1.1.2 0 msec 0 msec 0 msec 353 2 198.51.100.13 0 msec 4 msec 0 msec 354 3 10.1.1.2 0 msec 4 msec 0 msec <<<< 355 4 198.51.100.5 4 msec 0 msec 4 msec 356 5 198.51.100.1 0 msec 0 msec 0 msec 357 R1# 359 This duplicate address space scenario has the potential to cause 360 confusion among operational staff, thereby making it more difficult 361 to successfully debug networking problems. 363 Certainly a scenario where the same [RFC1918] address space becomes 364 utilised on both the inside and outside interfaces of a NAT/NAPT 365 device can be problematic. For example, the same private address 366 range is assigned by both the administrator of a corporate network 367 and their ISP. Some applications discover the outside address of 368 their local CPE to determine if that address is reserved for special 369 use. Application behavior may then be based on this determination. 370 "IANA-Reserved IPv4 Prefix for Shared Address Space" [RFC6598] 371 provides further analysis of this situation. 373 To address this scenario and others, "IANA-Reserved IPv4 Prefix for 374 Shared Address Space" [RFC6598] requests a dedicated /10 address 375 block for the purpose of Shared CGN (Carrier Grade NAT) Address 376 Space. The purpose of Shared CGN Address Space is to number CPE 377 (Customer Premise Equipment) interfaces that connect to CGN devices. 378 As explained in [RFC6598], [RFC1918] addressing has issues when used 379 in this deployment scenario. 381 6. Interactions with edge anti-spoofing techniques 383 Denial of Service Attacks (DOS) and Distributed Denial of Service 384 Attacks (DDoS) can make use of spoofed source IP addresses in an 385 attempt to obfuscate the source of an attack. Network Ingress 386 Filtering [RFC2827] strongly recommends that providers of Internet 387 connectivity implement filtering to prevent packets using source 388 addresses outside of their legitimately assigned and advertised 389 prefix ranges. Such filtering should also prevent packets with 390 private source addresses from egressing the AS. 392 Best security practices for ISPs also strongly recommend that packets 393 with illegitimate source addresses should be dropped at the AS 394 perimeter. Illegitimate source addresses includes private 395 [RFC1918]IP addresses, addresses within the provider's assigned 396 prefix ranges, and bogons (legitimate but unassigned IP addresses). 397 Additionally, packets with private IP destination addresses should 398 also be dropped at the AS perimeter. 400 If such filtering is properly deployed, then traffic either sourced 401 from, or destined for privately addressed portions of the network 402 should be dropped. Hence the negative consequences on traceroute, 403 PMTUD and regular ping type traffic. 405 7. Peering using loopbacks 407 Although not a common technique, some ISPs use the loopback addresses 408 of border routers (ASBRs) for peering, in particular where multiple 409 connections or exchange points exist between the two ISPs. Such a 410 technique is used by some ISPs as the foundation of fine grained 411 traffic engineering and load balancing through the combination of IGP 412 metrics and multi-hop BGP. When private or non-globally reachable 413 addresses are used as loopback addresses, this technique is either 414 not possible, or considerably more complex to implement. 416 8. DNS Interaction 418 Many ISPs utilise their DNS to perform both forward and reverse 419 resolution for the infrastructure devices and infrastructure 420 addresses. With a privately numbered core, the ISP itself will still 421 have the capability to perform name resolution of their own 422 infrastructure. However others outside of the autonomous system will 423 not have this capability. At best, they will get a number of 424 unidentified [RFC1918] IP addresses returned from a traceroute. 426 It is also worth noting that in some cases the reverse resolution 427 requests may leak outside of the AS. Such a situation can add load 428 to public DNS servers. Further information on this problem is 429 documented in "AS112 Nameserver Operations" [RFC6304]. 431 9. Operational and Troubleshooting issues 433 Previous sections of the document have noted issues relating to 434 network operations and troubleshooting. In particular when private 435 IP addressing within an ISP core is used, the ability to easily 436 troubleshoot across the AS boundary may be limited. In some cases 437 this may be a serious troubleshooting impediment. In other cases, it 438 may be solved through the use of alternative troubleshooting 439 techniques. 441 The key point is that the flexibility of initiating an outbound ping 442 or traceroute from a privately numbered section of the network is 443 lost. In a complex topology, with multiple paths and exit points 444 from the AS, the provider may be restricted in their ability to trace 445 paths through the network to other ASs. Such a situation could be a 446 severe troubleshooting impediment. 448 For users outside of the AS, the loss of the ability to use a 449 traceroute for troubleshooting is very often a serious issue. As 450 soon as many of these people see a row of "* * *" in a traceroute 451 they often incorrectly assume that a large part of the network is 452 down or inaccessible (e.g. behind a firewall). Operational 453 experience in many large providers has shown that significant 454 confusion can result. 456 10. Security Considerations 458 One of the arguments often put forward for the use of private 459 addressing within an ISP is an improvement in the network security. 460 It has been argued that if private addressing is used within the 461 core, the network infrastructure becomes unreachable from outside the 462 providers autonomous system, hence protecting the infrastructure. 463 There is legitimacy to this argument. Certainly if the core is 464 privately numbered and unreachable, it potentially provides a level 465 of isolation in addition to what can be achieved with other 466 techniques, such as infrastructure ACLs, on their own. This is 467 especially true in the event of an ACL misconfiguration, something 468 that does commonly occur as the result of human error. 470 There are three key security gaps that exist in a privately addressed 471 IP core. 473 The approach does not protect against reflection attacks if edge 474 anti-spoofing is not deployed. For example, if a packet with 475 spoofed source address corresponding to the networks 476 infrastructure address range, is sent to a host (or other device) 477 attached to the network, that host will send its response directly 478 to the infrastructure address. If such an attack was performed 479 across a large number of hosts, then a successful large scale 480 denial of service attack on the infrastructure could be achieved. 481 This is not to say that a publicly numbered core will protect from 482 the same attack, it won't. The key point is that a reflection 483 attack does get around the apparent security offered in a 484 privately addressed core. 486 Even if anti-spoofing is deployed at the AS boundary, the border 487 routers will potentially carry routing information for the 488 privately addressed network infrastructure. This can mean that 489 packets with spoofed addresses, corresponding to the private 490 infrastructure addressing, may be considered legitimate by edge 491 anti-spoofing techniques such as Unicast Reverse Path Forwarding - 492 Loose Mode, and forwarded. To avoid this situation, an edge anti- 493 spoofing algorithm such as Unicast Reverse Path Forwarding - 494 Strict Mode, would be required. Strict approaches can be 495 problematic in some environments or where asymmetric traffic paths 496 exist. 498 The approach on its own does not protect the network 499 infrastructure from directly connected customers (i.e. within the 500 same AS). Unless other security controls, such as access control 501 lists (ACLs), are deployed at the ingress point of the network, 502 customer devices will normally be able to reach, and potentially 503 attack, both core and edge infrastructure devices. 505 11. Alternate approaches to core network security 507 Today, hardware-based ACLs, which have minimal to no performance 508 impact, are now widespread. Applying an ACL at the AS perimeter to 509 prevent access to the network core may be a far simpler approach and 510 provide comparable protection to using private addressing; such a 511 technique is known as an infrastructure ACL (iACL). 513 In concept, iACLs provide filtering at the edge network which allows 514 traffic to cross the network core, but not to terminate on 515 infrastructure addresses within the core. Proper iACL deployment 516 will normally allow required network management traffic to be passed, 517 such that traceroutes and PMTUD can still operate successfully. For 518 an iACL deployment to be practical, the core network needs to have 519 been addressed with a relatively small number of contiguous address 520 blocks. For this reason, the technique may or may not be practical. 522 A second approach to preventing external access to the core is IS-IS 523 core hiding. This technique makes use of a fundamental property of 524 the IS-IS protocol which allows link addresses to be removed from the 525 routing table while still allowing loopback addresses to be resolved 526 as next hops for BGP. The technique prevents parties outside the AS 527 from being able to route to infrastructure addresses, while still 528 allowing traceroutes to operate successfully. IS-IS core hiding does 529 not have the same practical requirement for the core to be addressed 530 from a small number of contiguous address blocks as with iACLs. From 531 an operational and troubleshooting perspective, care must be taken to 532 ensure that pings and traceroutes are using source and destination 533 addresses that exist in the routing tables of all routers in the 534 path. i.e. Not hidden link addresses. 536 A third approach is the use of either an MPLS based IP VPN, or an 537 MPLS based IP Core where the 'P' routers (or Label Switch Routers) do 538 not carry global routing information. As the core 'P' routers (or 539 Label Switch Routers) are only switching labeled traffic, they are 540 effectively not reachable from outside of the MPLS domain. The 'P' 541 routers can optionally be hidden such they do not appear in a 542 traceroute. While this approach isolates the 'P' routers from 543 directed attacks, it does not protect the edge routers - being either 544 a 'PE' router or a Label Edge Router (LER). Obviously there are 545 numerous other engineering considerations in such an approach, we 546 simply note it as an option. 548 These techniques may not be suitable for every network, however, 549 there are many circumstances where they can be used successfully 550 without the associated effects of a privately addressing the core. 552 12. References 554 12.1. Normative References 556 [BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering: 557 Defeating Denial of Service Attacks which employ IP Source 558 Address Spoofing", May 2000. 560 [BCP84] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 561 Networks", March 2004. 563 [RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", 564 November 1990. 566 [RFC1393] Malkin, G., "Traceroute Using an IP Option", January 1993. 568 [RFC1918] Rekhter , Y., Moskowitz, R., Karrenberg, D., Jan de Groot, 569 G., and E. Lear , "RFC1918 Address Allocation for Private 570 Internets, BCP 5", Febuary 1996. 572 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 573 for IP version 6", August 1996. 575 [RFC2827] Ferguson, P. and D. Senie , "RFC 2827 Network Ingress 576 Filtering, BCP 38", May 2000. 578 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 579 Networks", March 2004. 581 12.2. Informative References 583 [RFC3021] Retana, A., White, R., Fuller, V., and D. McPherson, 584 "Using 31-Bit Prefixes on IPv4 Point-to-Point Links", 585 December 2000. 587 [RFC5837] Atlas, A., Bonica, Pignataro, C., Shen, N., and Rivers, 588 JR., "Extending ICMP for Interface and Next-Hop 589 Identification", April 2010. 591 [RFC6304] Abley, J. and W. Maton, "AS112 Nameserver Operations", 592 July 2011. 594 [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and 595 M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address 596 Space", April 2012. 598 [RFC792] Postel, J., "RFC792 Internet Control Message Protocol", 599 September 1981. 601 Appendix A. Acknowledgments 603 The author would like to thank the following people for their input 604 and review - Dan Wing (Cisco Systems), Roland Dobbins (Arbor 605 Networks), Philip Smith (APNIC), Barry Greene (ISC), Anton Ivanov 606 (kot-begemot.co.uk), Ryan Mcdowell (Cisco Systems), Russ White (Cisco 607 Systems), Gregg Schudel (Cisco Systems), Michael Behringer (Cisco 608 Systems), Stephan Millet (Cisco Systems), Tom Petch (BT Connect), Wes 609 George (Time Warner Cable), Nick Hilliard (INEX). 611 The author would also like to acknowledge the use of a variety of 612 NANOG mail archives as references. 614 Author's Address 616 Anthony Kirkham 617 Palo Alto Networks 618 Level 32, 101 Miller St 619 North Sydney, New South Wales 2060 620 Australia 622 Phone: +61 7 33530902 623 Email: tkirkham@paloaltonetworks.com