draft-ietf-grow-private-ip-sp-cores-02.txt		draft-ietf-grow-private-ip-sp-cores-03.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 25, 2012		Obsoletes: None (if approved) May 7, 2012
	Intended status: Informational		Intended status: Informational
	Expires: October 27, 2012		Expires: November 8, 2012
	Issues with Private IP Addressing in the Internet		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		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 27, 2012.		This Internet-Draft will expire on November 8, 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 35		skipping to change at page 2, line 35
	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 . . . . . . . . . . . . . . . . . . . 10		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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
	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
	network (also known as core hiding).		network (also known as core hiding).
	skipping to change at page 5, line 24		skipping to change at page 5, line 24
	3 198.51.100.9 20 msec 20 msec 32 msec		3 198.51.100.9 20 msec 20 msec 32 msec
	4 10.1.1.5 20 msec 20 msec 20 msec		4 10.1.1.5 20 msec 20 msec 20 msec
	5 10.1.1.1 20 msec 20 msec 20 msec		5 10.1.1.1 20 msec 20 msec 20 msec
	R6#		R6#
	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
	skipping to change at page 7, line 27		skipping to change at page 7, line 27
	Tracing the route to 203.0.113.65		Tracing the route to 203.0.113.65
	1 10.1.1.2 0 msec 4 msec 0 msec		1 10.1.1.2 0 msec 4 msec 0 msec
	2 10.1.1.6 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		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		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		5 198.51.100.1 [AS 64497] 0 msec 0 msec 4 msec
	R1#		R1#
	It should be noted that some solutions to this problem have been		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		identification of interfaces and their components by any combination
	of the following: ifIndex, IPv4 address, IPv6 address, name, and		of the following: ifIndex, IPv4 address, IPv6 address, name, and
	MTU. However at the time of writing, little or no deployment was		MTU. However at the time of writing, little or no deployment was
	known to be in place.		known to be in place.
	4. Effects on Path MTU Discovery		4. Effects on Path MTU Discovery
	The Path MTU Discovery (PMTUD) process was designed to allow hosts to		The Path MTU Discovery (PMTUD) process was designed to allow hosts to
	make an accurate assessment of the maximum packet size that can be		make an accurate assessment of the maximum packet size that can be
	sent across a path without fragmentation. Path MTU Discovery is		sent across a path without fragmentation. Path MTU Discovery is
	skipping to change at page 8, line 28		skipping to change at page 8, line 28
	The issue is as follows:		The issue is as follows:
	o When an ICMP Type 3 Code 4 message is issued from an infrastructure		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		link that uses a private (RFC1918) address, it must be routed back to
	the originating host. As the originating host will typically be a		the originating host. As the originating host will typically be a
	globally routable IP address, its source address is used as the		globally routable IP address, its source address is used as the
	destination address of the returned ICMP Type 3 packet. At this		destination address of the returned ICMP Type 3 packet. At this
	point there are normally no problems.		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-		problems can occur when the returned packet passes through an anti-
	spoofing security control (such as Unicast RPF (uRPF)), other anti-		spoofing security control (such as Unicast RPF (uRPF)), other anti-
	spoofing ACLs, or virtually any perimeter firewall. These devices		spoofing ACLs, or virtually any perimeter firewall. These devices
	will typically drop packets with an RFC1918 source address, breaking		will typically drop packets with an [RFC1918] source address,
	the successful operation of PMTUD.		breaking the successful operation of PMTUD.
	As a result, the potential for application level issues may be		As a result, the potential for application level issues may be
	created.		created.
	5. Unexpected interactions with some NAT implementations		5. Unexpected interactions with some NAT implementations
	Private addressing is legitimately used within many enterprise,		Private addressing is legitimately used within many enterprise,
	corporate or government networks for internal network addressing.		corporate or government networks for internal network addressing.
	When users on the inside of the network require Internet access, they		When users on the inside of the network require Internet access, they
	will typically connect through a perimeter router, firewall, or		will typically connect through a perimeter router, firewall, or
	network proxy, that provides Network Address Translation (NAT) or		network proxy, that provides Network Address Translation (NAT) or
	Network Address Port Translation (NAPT) services to a public		Network Address Port Translation (NAPT) services to a public
	interface.		interface.
	Scarcity of public IPv4 addresses, and the transition to IPv6, is		Scarcity of public IPv4 addresses, and the transition to IPv6, is
	forcing many service providers to make use of NAT. CGN (Carrier		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 to their customers rather than public, globally unique
	IPv4 addresses. NAT444 will make use of a double NAT process.		IPv4 addresses. NAT444 will make use of a double NAT process.
	Unpredictable or confusing interactions could occur if traffic such		Unpredictable or confusing interactions could occur if traffic such
	as traceroute, PMTUD and possibly other applications were launched		as traceroute, PMTUD and possibly other applications were launched
	from the NAT IPv4 'inside address' and it passed over the same		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		address range in the public IP core. While such a situation would be
	unlikely to occur if the NAT pools and the private infrastructure		unlikely to occur if the NAT pools and the private infrastructure
	addressing were under the same administration, such a situation could		addressing were under the same administration, such a situation could
	occur in the more typical situation of a NAT'ed corporate network		occur in the more typical situation of a NAT'ed corporate network
	skipping to change at page 10, line 6		skipping to change at page 10, line 6
	2 198.51.100.13 0 msec 4 msec 0 msec		2 198.51.100.13 0 msec 4 msec 0 msec
	3 10.1.1.2 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		4 198.51.100.5 4 msec 0 msec 4 msec
	5 198.51.100.1 0 msec 0 msec 0 msec		5 198.51.100.1 0 msec 0 msec 0 msec
	R1#		R1#
	This example has been included to illustrate an effect. Whether that		This example has been included to illustrate an effect. Whether that
	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.
	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		To address this scenario and others, [RFC6598] requests a dedicated
	address block for the purpose of Shared CGN (Carrier Grade NAT)		/10 address block for the purpose of Shared CGN (Carrier Grade NAT)
	Address Space. The purpose of Shared CGN Address Space is to number		Address Space. The purpose of Shared CGN Address Space is to number
	CPE (Customer Premise Equipment) interfaces that connect to CGN		CPE (Customer Premise Equipment) interfaces that connect to CGN
	devices. As explained in RFC6598, RFC1918 addressing has issues when		devices. As explained in [RFC6598], [RFC1918] addressing has issues
	used in this deployment scenario.		when used in this deployment scenario.
	6. Interactions with edge anti-spoofing techniques		6. Interactions with edge anti-spoofing techniques
	Denial of Service Attacks (DOS) and Distributed Denial of Service		Denial of Service Attacks (DOS) and Distributed Denial of Service
	Attacks (DDoS) can make use of spoofed source IP addresses in an		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		Ingress Filtering) strongly recommends that providers of Internet
	connectivity implement filtering to prevent packets using source		connectivity implement filtering to prevent packets using source
	addresses outside of their legitimately assigned and advertised		addresses outside of their legitimately assigned and advertised
	prefix ranges. Such filtering should also prevent packets with		prefix ranges. Such filtering should also prevent packets with
	private source addresses from 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
	skipping to change at page 11, line 19		skipping to change at page 11, line 19
	not possible, or considerably more complex to implement.		not possible, or considerably more complex to implement.
	8. DNS Interaction		8. DNS Interaction
	Many ISPs utilise their DNS to perform both forward and reverse		Many ISPs utilise their DNS to perform both forward and reverse
	resolution for the infrastructure devices and infrastructure		resolution for the infrastructure devices and infrastructure
	addresses. With a privately numbered core, the ISP itself will still		addresses. With a privately numbered core, the ISP itself will still
	have the capability to perform name resolution of their own		have the capability to perform name resolution of their own
	infrastructure. However others outside of the autonomous system will		infrastructure. However others outside of the autonomous system will
	not have this capability. At best, they will get a number of		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		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		requests may leak outside of the AS. Such a situation can add load
	to public DNS servers. Further information on this problem is		to public DNS servers. Further information on this problem is
	documented in the internet draft "AS112 Nameserver Operations".		documented in the internet draft "AS112 Nameserver Operations".
	9. Operational and Troubleshooting issues		9. Operational and Troubleshooting issues
	Previous sections of the document have noted issues relating to		Previous sections of the document have noted issues relating to
	network operations and troubleshooting. In particular when private		network operations and troubleshooting. In particular when private
	skipping to change at page 14, line 46		skipping to change at page 15, line 5
	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).
	The author would also like to acknowledge the use of a variety of		The author would also like to acknowledge the use of a variety of
	NANOG mail archives as references.		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		Author's Address
	Anthony Kirkham		Anthony Kirkham
	Palo Alto Networks		Palo Alto Networks
	Level 32, 101 Miller St		Level 32, 101 Miller St
	North Sydney, New South Wales 2060		North Sydney, New South Wales 2060
	Australia		Australia
	Phone: +61 7 33530902		Phone: +61 7 33530902
	Email: tkirkham@paloaltonetworks.com		Email: tkirkham@paloaltonetworks.com
End of changes. 17 change blocks.
	26 lines changed or deleted		19 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/