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