--- 1/draft-ietf-grow-private-ip-sp-cores-02.txt 2012-05-07 13:13:57.707004990 +0200 +++ 2/draft-ietf-grow-private-ip-sp-cores-03.txt 2012-05-07 13:13:57.735004299 +0200 @@ -1,19 +1,19 @@ Network Working Group A. Kirkham Internet-Draft Palo Alto Networks -Obsoletes: None (if approved) April 25, 2012 +Obsoletes: None (if approved) May 7, 2012 Intended status: Informational -Expires: October 27, 2012 +Expires: November 8, 2012 Issues with Private IP Addressing in the Internet - draft-ietf-grow-private-ip-sp-cores-02 + draft-ietf-grow-private-ip-sp-cores-03 Abstract The purpose of this document is to provide a discussion of the potential problems of using private, RFC1918, or non-globally- routable addressing within the core of an SP network. The discussion focuses on link addresses and to a small extent loopback addresses. While many of the issues are well recognised within the ISP community, there appears to be no document that collectively describes the issues. @@ -37,21 +37,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on October 27, 2012. + This Internet-Draft will expire on November 8, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -69,22 +69,21 @@ 4. Effects on Path MTU Discovery . . . . . . . . . . . . . . . . 7 5. Unexpected interactions with some NAT implementations . . . . 8 6. Interactions with edge anti-spoofing techniques . . . . . . . 10 7. Peering using loopbacks . . . . . . . . . . . . . . . . . . . 10 8. DNS Interaction . . . . . . . . . . . . . . . . . . . . . . . 11 9. Operational and Troubleshooting issues . . . . . . . . . . . . 11 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 11. Alternate approaches to core network security . . . . . . . . 13 12. Normative References . . . . . . . . . . . . . . . . . . . . . 14 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 14 - Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction In the mid to late 90's, some Internet Service Providers (ISPs) adopted the practice of utilising private (or non-globally unique) IP (i.e. RFC1918) addresses for the infrastructure links and in some cases the loopback interfaces within their networks. The reasons for this approach centered on conservation of address space (i.e. scarcity of public IPv4 address space), and security of the core network (also known as core hiding). @@ -183,21 +182,21 @@ 3 198.51.100.9 20 msec 20 msec 32 msec 4 10.1.1.5 20 msec 20 msec 20 msec 5 10.1.1.1 20 msec 20 msec 20 msec R6# This effect in itself is often not a problem. However, if anti- spoofing controls are applied at network perimeters, then responses returned from hops with private IP addresses will be dropped. Anti- spoofing refers to a security control where traffic with an invalid source address is discarded. Anti-spoofing is further described in - BCP 38/RFC 2827. + [BCP 38]/[RFC 2827]. The effects are illustrated in a second example below. The same network as example 1 is used, but with the addition of anti-spoofing deployed at the ingress of R4 on the R3-R4 interface (IP Address 198.51.100.10). R6#traceroute 203.0.113.1 Type escape sequence to abort. Tracing the route to 203.0.113.1 @@ -266,21 +265,21 @@ Tracing the route to 203.0.113.65 1 10.1.1.2 0 msec 4 msec 0 msec 2 10.1.1.6 0 msec 4 msec 0 msec 3 198.51.100.10 [AS 64497] 0 msec 4 msec 0 msec 4 198.51.100.5 [AS 64497] 0 msec 0 msec 4 msec 5 198.51.100.1 [AS 64497] 0 msec 0 msec 4 msec R1# It should be noted that some solutions to this problem have been - proposed in RFC 5837 which provides extensions to ICMP to allow the + proposed in [RFC 5837] which provides extensions to ICMP to allow the identification of interfaces and their components by any combination of the following: ifIndex, IPv4 address, IPv6 address, name, and MTU. However at the time of writing, little or no deployment was known to be in place. 4. Effects on Path MTU Discovery The Path MTU Discovery (PMTUD) process was designed to allow hosts to make an accurate assessment of the maximum packet size that can be sent across a path without fragmentation. Path MTU Discovery is @@ -315,43 +314,43 @@ The issue is as follows: o When an ICMP Type 3 Code 4 message is issued from an infrastructure link that uses a private (RFC1918) address, it must be routed back to the originating host. As the originating host will typically be a globally routable IP address, its source address is used as the destination address of the returned ICMP Type 3 packet. At this point there are normally no problems. - o As the returned packet will have an RFC1918 source address, + o As the returned packet will have an [RFC1918] source address, problems can occur when the returned packet passes through an anti- spoofing security control (such as Unicast RPF (uRPF)), other anti- spoofing ACLs, or virtually any perimeter firewall. These devices - will typically drop packets with an RFC1918 source address, breaking - the successful operation of PMTUD. + will typically drop packets with an [RFC1918] source address, + breaking the successful operation of PMTUD. As a result, the potential for application level issues may be created. 5. Unexpected interactions with some NAT implementations Private addressing is legitimately used within many enterprise, corporate or government networks for internal network addressing. When users on the inside of the network require Internet access, they will typically connect through a perimeter router, firewall, or network proxy, that provides Network Address Translation (NAT) or Network Address Port Translation (NAPT) services to a public interface. Scarcity of public IPv4 addresses, and the transition to IPv6, is forcing many service providers to make use of NAT. CGN (Carrier - Grade NAT) will enable service providers to assign private RFC 1918 + Grade NAT) will enable service providers to assign private [RFC 1918] IPv4 addresses to their customers rather than public, globally unique IPv4 addresses. NAT444 will make use of a double NAT process. Unpredictable or confusing interactions could occur if traffic such as traceroute, PMTUD and possibly other applications were launched from the NAT IPv4 'inside address' and it passed over the same address range in the public IP core. While such a situation would be unlikely to occur if the NAT pools and the private infrastructure addressing were under the same administration, such a situation could occur in the more typical situation of a NAT'ed corporate network @@ -385,41 +384,41 @@ 2 198.51.100.13 0 msec 4 msec 0 msec 3 10.1.1.2 0 msec 4 msec 0 msec <<<< 4 198.51.100.5 4 msec 0 msec 4 msec 5 198.51.100.1 0 msec 0 msec 0 msec R1# This example has been included to illustrate an effect. Whether that effect would be problematic would depend on both the deployment scenario and the application in use. - Certainly a scenario where the same RFC1918 address space becomes + Certainly a scenario where the same [RFC1918] address space becomes utilised on both the inside and outside interfaces of a NAT/NAPT device can be problematic. For example, the same private address range is assigned by both the administrator of a corporate network and their ISP. Some applications discover the outside address of their local CPE to determine if that address is reserver for special use. Application behavior may then be based on this determination. - RFC6598 provides further analysis of this situation. + [RFC6598] provides further analysis of this situation. - To address this scenario and others, RFC6598 requests a dedicated /10 - address block for the purpose of Shared CGN (Carrier Grade NAT) + To address this scenario and others, [RFC6598] requests a dedicated + /10 address block for the purpose of Shared CGN (Carrier Grade NAT) Address Space. The purpose of Shared CGN Address Space is to number CPE (Customer Premise Equipment) interfaces that connect to CGN - devices. As explained in RFC6598, RFC1918 addressing has issues when - used in this deployment scenario. + devices. As explained in [RFC6598], [RFC1918] addressing has issues + when used in this deployment scenario. 6. Interactions with edge anti-spoofing techniques Denial of Service Attacks (DOS) and Distributed Denial of Service Attacks (DDoS) can make use of spoofed source IP addresses in an - attempt to obfuscate the source of an attack. RFC2827 (Network + attempt to obfuscate the source of an attack. [RFC2827] (Network Ingress Filtering) strongly recommends that providers of Internet connectivity implement filtering to prevent packets using source addresses outside of their legitimately assigned and advertised prefix ranges. Such filtering should also prevent packets with private source addresses from egressing the AS. Best security practices for ISPs also strongly recommend that packets with illegitimate source addresses should be dropped at the AS perimeter. Illegitimate source addresses includes private IP (RFC1918) addresses, addresses within the provider's assigned prefix @@ -444,21 +443,21 @@ not possible, or considerably more complex to implement. 8. DNS Interaction Many ISPs utilise their DNS to perform both forward and reverse resolution for the infrastructure devices and infrastructure addresses. With a privately numbered core, the ISP itself will still have the capability to perform name resolution of their own infrastructure. However others outside of the autonomous system will not have this capability. At best, they will get a number of - unidentified RFC1918 IP addresses returned from a traceroute. + unidentified [RFC1918] IP addresses returned from a traceroute. It is also worth noting that in some cases the reverse resolution requests may leak outside of the AS. Such a situation can add load to public DNS servers. Further information on this problem is documented in the internet draft "AS112 Nameserver Operations". 9. Operational and Troubleshooting issues Previous sections of the document have noted issues relating to network operations and troubleshooting. In particular when private @@ -613,26 +612,20 @@ and review - Dan Wing (Cisco Systems), Roland Dobbins (Arbor Networks), Philip Smith (APNIC), Barry Greene (ISC), Anton Ivanov (kot-begemot.co.uk), Ryan Mcdowell (Cisco Systems), Russ White (Cisco Systems), Gregg Schudel (Cisco Systems), Michael Behringer (Cisco Systems), Stephan Millet (Cisco Systems), Tom Petch (BT Connect), Wes George (Time Warner Cable). The author would also like to acknowledge the use of a variety of NANOG mail archives as references. -Index - - H - http://tools.ietf.org/html/draft-ietf-dnsop-as112-ops-08 11 - http://tools.ietf.org/html/rfc2827 5 - Author's Address Anthony Kirkham Palo Alto Networks Level 32, 101 Miller St North Sydney, New South Wales 2060 Australia Phone: +61 7 33530902 Email: tkirkham@paloaltonetworks.com