draft-ietf-grow-private-ip-sp-cores-01.txt   draft-ietf-grow-private-ip-sp-cores-02.txt 
Network Working Group A. Kirkham Network Working Group A. Kirkham
Internet-Draft Palo Alto Networks Internet-Draft Palo Alto Networks
Obsoletes: None (if approved) April 10, 2012 Obsoletes: None (if approved) April 25, 2012
Intended status: Informational Intended status: Informational
Expires: October 12, 2012 Expires: October 27, 2012
Issues with Private IP Addressing in the Internet 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 Abstract
The purpose of this document is to provide a discussion of the The purpose of this document is to provide a discussion of the
potential problems of using private, RFC1918, or non-globally- potential problems of using private, RFC1918, or non-globally-
routable addressing within the core of an SP network. The discussion routable addressing within the core of an SP network. The discussion
focuses on link addresses and to a small extent loopback addresses. focuses on link addresses and to a small extent loopback addresses.
While many of the issues are well recognised within the ISP While many of the issues are well recognised within the ISP
community, there appears to be no document that collectively community, there appears to be no document that collectively
describes the issues. describes the issues.
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 28 skipping to change at page 2, line 28
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conservation of Address Space . . . . . . . . . . . . . . . . 3 2. Conservation of Address Space . . . . . . . . . . . . . . . . 3
3. Effects on Traceroute . . . . . . . . . . . . . . . . . . . . 4 3. Effects on Traceroute . . . . . . . . . . . . . . . . . . . . 4
4. Effects on Path MTU Discovery . . . . . . . . . . . . . . . . 7 4. Effects on Path MTU Discovery . . . . . . . . . . . . . . . . 7
5. Unexpected interactions with some NAT implementations . . . . 8 5. Unexpected interactions with some NAT implementations . . . . 8
6. Interactions with edge anti-spoofing techniques . . . . . . . 10 6. Interactions with edge anti-spoofing techniques . . . . . . . 10
7. Peering using loopbacks . . . . . . . . . . . . . . . . . . . 11 7. Peering using loopbacks . . . . . . . . . . . . . . . . . . . 10
8. DNS Interaction . . . . . . . . . . . . . . . . . . . . . . . 11 8. DNS Interaction . . . . . . . . . . . . . . . . . . . . . . . 11
9. Operational and Troubleshooting issues . . . . . . . . . . . . 11 9. Operational and Troubleshooting issues . . . . . . . . . . . . 11
10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12
11. Alternate approaches to core network security . . . . . . . . 13 11. Alternate approaches to core network security . . . . . . . . 13
12. Normative References . . . . . . . . . . . . . . . . . . . . . 14 12. Normative References . . . . . . . . . . . . . . . . . . . . . 14
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 14 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 14
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
In the mid to late 90's, some Internet Service Providers (ISPs) In the mid to late 90's, some Internet Service Providers (ISPs)
adopted the practice of utilising private (or non-globally unique) IP adopted the practice of utilising private (or non-globally unique) IP
(i.e. RFC1918) addresses for the infrastructure links and in some (i.e. RFC1918) addresses for the infrastructure links and in some
cases the loopback interfaces within their networks. The reasons for cases the loopback interfaces within their networks. The reasons for
this approach centered on conservation of address space (i.e. this approach centered on conservation of address space (i.e.
scarcity of public IPv4 address space), and security of the core scarcity of public IPv4 address space), and security of the core
skipping to change at page 5, line 28 skipping to change at page 5, line 28
This effect in itself is often not a problem. However, if anti- This effect in itself is often not a problem. However, if anti-
spoofing controls are applied at network perimeters, then responses spoofing controls are applied at network perimeters, then responses
returned from hops with private IP addresses will be dropped. Anti- returned from hops with private IP addresses will be dropped. Anti-
spoofing refers to a security control where traffic with an invalid spoofing refers to a security control where traffic with an invalid
source address is discarded. Anti-spoofing is further described in 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 The effects are illustrated in a second example below. The same
network as example 1 is used, but with the addition of anti-spoofing 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). 198.51.100.10).
R6#traceroute 203.0.113.1 R6#traceroute 203.0.113.1
Type escape sequence to abort. Type escape sequence to abort.
Tracing the route to 203.0.113.1 Tracing the route to 203.0.113.1
1 198.51.100.2 24 msec 20 msec 20 msec 1 198.51.100.2 24 msec 20 msec 20 msec
2 198.51.100.6 20 msec 52 msec 44 msec 2 198.51.100.6 20 msec 52 msec 44 msec
3 198.51.100.9 44 msec 20 msec 32 msec 3 198.51.100.9 44 msec 20 msec 32 msec
skipping to change at page 8, line 7 skipping to change at page 8, line 7
fragmentation needed and DF set (type 3, code 4)' message to the fragmentation needed and DF set (type 3, code 4)' message to the
source of the IP datagram. This message includes the MTU of that source of the IP datagram. This message includes the MTU of that
next-hop network. As a result, the source station which receives the next-hop network. As a result, the source station which receives the
ICMP message, will lower the send Maximum Segment Size (MSS). ICMP message, will lower the send Maximum Segment Size (MSS).
It is obviously desirable that packets be sent between two It is obviously desirable that packets be sent between two
communicating hosts without fragmentation as this process imposes communicating hosts without fragmentation as this process imposes
extra load on the fragmenting router (process of fragmentation), extra load on the fragmenting router (process of fragmentation),
intermediate routers (forwarding additional packets), as well as the intermediate routers (forwarding additional packets), as well as the
receiving host (reassembly of the fragmented packets). Additionally, receiving host (reassembly of the fragmented packets). Additionally,
many applications, including some web servers, set the DF (do not many applications, including some web servers, set the DF (Do Not
fragment) bit causing undesirable interactions if the path MTU is Fragment) bit causing undesirable interactions if the path MTU is
insufficient. Other TCP implementations may set an MTU size of 576 insufficient. Other TCP implementations may set an MTU size of 576
bytes if PMTUD is unavailable. In addition, IPsec and other bytes if PMTUD is unavailable. In addition, IPsec and other
tunneling protocols will often require MTUs greater than 1500 bytes tunneling protocols will often require MTUs greater than 1500 bytes
and often rely on PMTUD. and often rely on PMTUD.
While it is uncommon these days for core SP networks not to support 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 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 common), the situation of 1500 byte path MTUs is still common in many
ethernet edge or aggregation networks. ethernet edge or aggregation networks.
skipping to change at page 10, line 13 skipping to change at page 10, line 13
effect would be problematic would depend on both the deployment effect would be problematic would depend on both the deployment
scenario and the application in use. 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 utilised on both the inside and outside interfaces of a NAT/NAPT
device can be problematic. For example, the same private address device can be problematic. For example, the same private address
range is assigned by both the administrator of a corporate network range is assigned by both the administrator of a corporate network
and their ISP. Some applications discover the outside address of and their ISP. Some applications discover the outside address of
their local CPE to determine if that address is reserver for special their local CPE to determine if that address is reserver for special
use. Application behavior may then be based on this determination. use. Application behavior may then be based on this determination.
[weil-shared-transition-space-request] provides further analysis of RFC6598 provides further analysis of this situation.
this situation.
To address this scenario and others, at the time of writing, work was To address this scenario and others, RFC6598 requests a dedicated /10
in progress to obtain a dedicated /10 address block for the purpose address block for the purpose of Shared CGN (Carrier Grade NAT)
of Shared CGN (Carrier Grade NAT) Address Space. Please refer to Address Space. The purpose of Shared CGN Address Space is to number
[weil-shared-transition-space-request] for details. The purpose of CPE (Customer Premise Equipment) interfaces that connect to CGN
Shared CGN Address Space is to number CPE (Customer Premise devices. As explained in RFC6598, RFC1918 addressing has issues when
Equipment) interfaces that connect to CGN devices. As explained in used in this deployment scenario.
[weil-shared-transition-space-request], RFC1918 addressing has issues
when used in this deployment scenario.
6. Interactions with edge anti-spoofing techniques 6. Interactions with edge anti-spoofing techniques
Denial of service attacks and distributed denial of attacks can make Denial of Service Attacks (DOS) and Distributed Denial of Service
use of spoofed source IP addresses in an attempt to obfuscate the Attacks (DDoS) can make use of spoofed source IP addresses in an
source of an attack. RFC2827 (Network Ingress Filtering) strongly attempt to obfuscate the source of an attack. RFC2827 (Network
recommends that providers of Internet connectivity implement Ingress Filtering) strongly recommends that providers of Internet
filtering to prevent packets using source addresses outside of their connectivity implement filtering to prevent packets using source
legitimately assigned and advertised prefix ranges. Such filtering addresses outside of their legitimately assigned and advertised
should also prevent packets with private source addresses from prefix ranges. Such filtering should also prevent packets with
egressing the AS. private source addresses from egressing the AS.
Best security practices for ISPs also strongly recommend that packets Best security practices for ISPs also strongly recommend that packets
with illegitimate source addresses should be dropped at the AS with illegitimate source addresses should be dropped at the AS
perimeter. Illegitimate source addresses includes private IP perimeter. Illegitimate source addresses includes private IP
(RFC1918) addresses, addresses within the provider's assigned prefix (RFC1918) addresses, addresses within the provider's assigned prefix
ranges, and bogons (legitimate but unassigned IP addresses). ranges, and bogons (legitimate but unassigned IP addresses).
Additionally, packets with private IP destination addresses should Additionally, packets with private IP destination addresses should
also be dropped at the AS perimeter. also be dropped at the AS perimeter.
If such filtering is properly deployed, then traffic either sourced If such filtering is properly deployed, then traffic either sourced
skipping to change at page 13, line 17 skipping to change at page 13, line 10
same AS). Unless other security controls, such as access control same AS). Unless other security controls, such as access control
lists (ACLs), are deployed at the ingress point of the network, lists (ACLs), are deployed at the ingress point of the network,
customer devices will normally be able to reach, and potentially customer devices will normally be able to reach, and potentially
attack, both core and edge infrastructure devices. attack, both core and edge infrastructure devices.
11. Alternate approaches to core network security 11. Alternate approaches to core network security
Today, hardware-based ACLs, which have minimal to no performance Today, hardware-based ACLs, which have minimal to no performance
impact, are now widespread. Applying an ACL at the AS perimeter to 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 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). technique is known as an infrastructure ACL (iACL).
In concept, iACLs provide filtering at the edge network which allows In concept, iACLs provide filtering at the edge network which allows
traffic to cross the network core, but not to terminate on traffic to cross the network core, but not to terminate on
infrastructure addresses within the core. Proper iACL deployment infrastructure addresses within the core. Proper iACL deployment
will normally allow required network management traffic to be passed, will normally allow required network management traffic to be passed,
such that traceroutes and PMTUD can still operate successfully. For such that traceroutes and PMTUD can still operate successfully. For
an iACL deployment to be practical, the core network needs to have an iACL deployment to be practical, the core network needs to have
been addressed with a relatively small number of contiguous address been addressed with a relatively small number of contiguous address
blocks. For this reason, the technique may or may not be practical. blocks. For this reason, the technique may or may not be practical.
skipping to change at page 14, line 32 skipping to change at page 14, line 26
[RFC2728] Ferguson, P. and D. Senie , "RFC 2827 Network Ingress [RFC2728] Ferguson, P. and D. Senie , "RFC 2827 Network Ingress
Filtering, BCP 38", May 2000. Filtering, BCP 38", May 2000.
[RFC3021] Retana, A., White, R., Fuller, V., and D. McPherson, [RFC3021] Retana, A., White, R., Fuller, V., and D. McPherson,
"Using 31-Bit Prefixes on IPv4 Point-to-Point Links", "Using 31-Bit Prefixes on IPv4 Point-to-Point Links",
December 2000. December 2000.
[RFC6304] Abley, J. and W. Maton, "AS112 Nameserver Operations", [RFC6304] Abley, J. and W. Maton, "AS112 Nameserver Operations",
July 2011. 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", [RFC792] Postel, J., "RFC792 Internet Control Message Protocol",
September 1981. 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 Appendix A. Acknowledgments
The author would like to thank the following people for their input The author would like to thank the following people for their input
and review - Dan Wing (Cisco Systems), Roland Dobbins (Arbor and review - Dan Wing (Cisco Systems), Roland Dobbins (Arbor
Networks), Philip Smith (APNIC), Barry Greene (ISC), Anton Ivanov Networks), Philip Smith (APNIC), Barry Greene (ISC), Anton Ivanov
(kot-begemot.co.uk), Ryan Mcdowell (Cisco Systems), Russ White (Cisco (kot-begemot.co.uk), Ryan Mcdowell (Cisco Systems), Russ White (Cisco
Systems), Gregg Schudel (Cisco Systems), Michael Behringer (Cisco Systems), Gregg Schudel (Cisco Systems), Michael Behringer (Cisco
Systems), Stephan Millet (Cisco Systems), Tom Petch (BT Connect), Wes Systems), Stephan Millet (Cisco Systems), Tom Petch (BT Connect), Wes
George (Time Warner Cable). George (Time Warner Cable).
 End of changes. 14 change blocks. 
33 lines changed or deleted 29 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/