--- 1/draft-ietf-grow-private-ip-sp-cores-01.txt 2012-04-25 04:15:25.334671187 +0200 +++ 2/draft-ietf-grow-private-ip-sp-cores-02.txt 2012-04-25 04:15:25.370671226 +0200 @@ -1,19 +1,19 @@ Network Working Group A. Kirkham Internet-Draft Palo Alto Networks -Obsoletes: None (if approved) April 10, 2012 +Obsoletes: None (if approved) April 25, 2012 Intended status: Informational -Expires: October 12, 2012 +Expires: October 27, 2012 Issues with Private IP Addressing in the Internet - draft-ietf-grow-private-ip-sp-cores-01 + draft-ietf-grow-private-ip-sp-cores-02 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 12, 2012. + This Internet-Draft will expire on October 27, 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 @@ -62,28 +62,28 @@ described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conservation of Address Space . . . . . . . . . . . . . . . . 3 3. Effects on Traceroute . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . 11 + 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 + Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 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 @@ -187,21 +187,21 @@ 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. 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 + 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 1 198.51.100.2 24 msec 20 msec 20 msec 2 198.51.100.6 20 msec 52 msec 44 msec 3 198.51.100.9 44 msec 20 msec 32 msec @@ -294,22 +294,22 @@ fragmentation needed and DF set (type 3, code 4)' message to the source of the IP datagram. This message includes the MTU of that next-hop network. As a result, the source station which receives the ICMP message, will lower the send Maximum Segment Size (MSS). It is obviously desirable that packets be sent between two communicating hosts without fragmentation as this process imposes extra load on the fragmenting router (process of fragmentation), intermediate routers (forwarding additional packets), as well as the receiving host (reassembly of the fragmented packets). Additionally, - many applications, including some web servers, set the DF (do not - fragment) bit causing undesirable interactions if the path MTU is + many applications, including some web servers, set the DF (Do Not + Fragment) bit causing undesirable interactions if the path MTU is insufficient. Other TCP implementations may set an MTU size of 576 bytes if PMTUD is unavailable. In addition, IPsec and other tunneling protocols will often require MTUs greater than 1500 bytes and often rely on PMTUD. While it is uncommon these days for core SP networks not to support path MTUs in excess of 1500 bytes (with 4470 or greater being common), the situation of 1500 byte path MTUs is still common in many ethernet edge or aggregation networks. @@ -392,42 +392,39 @@ 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 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. - [weil-shared-transition-space-request] provides further analysis of - this situation. + RFC6598 provides further analysis of this situation. - To address this scenario and others, at the time of writing, work was - in progress to obtain a dedicated /10 address block for the purpose - of Shared CGN (Carrier Grade NAT) Address Space. Please refer to - [weil-shared-transition-space-request] for details. The purpose of - Shared CGN Address Space is to number CPE (Customer Premise - Equipment) interfaces that connect to CGN devices. As explained in - [weil-shared-transition-space-request], RFC1918 addressing has issues - when used in this deployment scenario. + 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. 6. Interactions with edge anti-spoofing techniques - Denial of service attacks and distributed denial of attacks can make - use of spoofed source IP addresses in an 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. + 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 + 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 ranges, and bogons (legitimate but unassigned IP addresses). Additionally, packets with private IP destination addresses should also be dropped at the AS perimeter. If such filtering is properly deployed, then traffic either sourced @@ -533,21 +530,21 @@ same AS). Unless other security controls, such as access control lists (ACLs), are deployed at the ingress point of the network, customer devices will normally be able to reach, and potentially attack, both core and edge infrastructure devices. 11. Alternate approaches to core network security Today, hardware-based ACLs, which have minimal to no performance impact, are now widespread. Applying an ACL at the AS perimeter to prevent access to the network core may be a far simpler approach and - provide comparable protection to using private addressing, Such a + provide comparable protection to using private addressing; such a technique is known as an infrastructure ACL (iACL). In concept, iACLs provide filtering at the edge network which allows traffic to cross the network core, but not to terminate on infrastructure addresses within the core. Proper iACL deployment will normally allow required network management traffic to be passed, such that traceroutes and PMTUD can still operate successfully. For an iACL deployment to be practical, the core network needs to have been addressed with a relatively small number of contiguous address blocks. For this reason, the technique may or may not be practical. @@ -596,28 +593,27 @@ [RFC2728] Ferguson, P. and D. Senie , "RFC 2827 Network Ingress Filtering, BCP 38", May 2000. [RFC3021] Retana, A., White, R., Fuller, V., and D. McPherson, "Using 31-Bit Prefixes on IPv4 Point-to-Point Links", December 2000. [RFC6304] Abley, J. and W. Maton, "AS112 Nameserver Operations", July 2011. + [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and + M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address + Space", April 2012. + [RFC792] Postel, J., "RFC792 Internet Control Message Protocol", September 1981. - [weil-shared-transition-space-request] - Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and - M. Azinger, "IANA Reserved IPv4 Prefix for Shared CGN - Space". - Appendix A. Acknowledgments The author would like to thank the following people for their input 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).