[Docs] [txt|pdf] [Tracker] [Email] [Nits]
Versions: 00
Network Working Group D. Thaler
Internet-Draft Microsoft
Expires: September 1, 2010 February 28, 2010
Issues With Port-Restricted IP Addresses
draft-thaler-port-restricted-ip-issues-00.txt
Abstract
This document discusses issues with assigning an IP address to a host
interface such that the IP address may only be used with a restricted
set of ports. This concept is referred to herein as a port-
restricted IP address. A number of issues with this concept are
documented, and the issues are contrasted with other approaches to
dealing with IPv4 address exhaustion.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 1, 2010.
Copyright Notice
Copyright (c) 2010 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
Thaler Expires September 1, 2010 [Page 1]
Internet-Draft Issues With Port-Restricted IP Addresses February 2010
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. IP Model Issues . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Host Implementation Issues . . . . . . . . . . . . . . . . . . 5
4. Application/Protocol Issues . . . . . . . . . . . . . . . . . . 6
5. Management Issues . . . . . . . . . . . . . . . . . . . . . . . 6
6. Personnel Issues . . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
Thaler Expires September 1, 2010 [Page 2]
Internet-Draft Issues With Port-Restricted IP Addresses February 2010
1. Introduction
In this document we use the term "port-restricted IP address" to mean
an address assigned to an interface of some device, where that
address can only be used with a restricted set of port numbers in
TCP, UDP, and/or other transport protocols.
Port-restricted IP addresses have been proposed as one mechanism to
allow address re-use (using disjoint sets of port numbers) among many
nodes, which is motivated by IPv4 address scarcity.
A port-restricted IP address differs from other types of shared
addresses, such as resulting from a classic Network Address
Translator (NAT) in that a port-restricted IP address is actually
assigned to an interface of some device. In contrast, in a typical
network address translation deployment, a public IPv4 address is
shared among many hosts by being assigned to an external interface of
the NAT device (where it is usable with all protocols and ports, and
hence is not port-restricted). Each host on the private side of the
NAT uses a separate, private IPv4 address assigned to its own
interface, and the private IPv4 address is usable on the private
subnet with all protocols and ports.
There are three types of issues with the concept of port-restricted
IP addresses:
a. Issues inherent in any type of address sharing, including Network
Address Translation (NAT). These issues are discussed in
[I-D.ford-shared-addressing-issues] and hence are outside the
scope of this document.
b. Issues that exist in other types of address sharing such as NATs,
but which are made worse in some way with port-restricted IP
addresses.
c. Issues unique to port-restricted IP addresses.
This document covers the latter two types of issue.
2. IP Model Issues
A "unicast address" is defined (e.g., in [RFC4291]) as an identifier
for a single interface. A packet sent to a unicast address is
delivered to the interface identified by that address. Many
protocols, including ARP [RFC0826] [RFC5227] rely on this fact.
Creating a port-restricted unicast IP address would require a change
to the above definition so that it could be assigned to multiple
interfaces (on different hosts) within the address's scope.
Thaler Expires September 1, 2010 [Page 3]
Internet-Draft Issues With Port-Restricted IP Addresses February 2010
This change to the IP model would be as big as, but quite different
from, the introduction of NAT. This issue is unique to port-
restricted IP addresses, since in classic NAT, each IP address is
only assigned to a single interface.
The closest concept that exists today is that of an "anycast" address
[RFC1546] [RFC4291]. An anycast address is defined as an identifier
for a set of interfaces, where a packet sent to an anycast address is
delivered to the "nearest" interface according to the routing
protocols' measure of distance. For additional discussion of anycast
considerations, see [I-D.iab-anycast-arch-implications]. An anycast
address differs from a port-restricted IP address in that an anycast
address may still be used with any protocol or port, and all
interfaces with the same anycast address are considered equivalent.
It is also worth noting the distinction between a port-restricted IP
address, and an address/port obtained from a NAT by an application
using a protocol such as UPnP or NAT-PMP. In the UPnP/NAT-PMP model,
the address is still assigned to the NAT's public interface, not an
interface of the host on which the application is running. As such,
UPnP/NAT-PMP-unaware applications that see addresses of the local
machine via local APIs (e.g., getsockaddr) will never see such an
address, and hence no API contract is affected. Thus, applications
opt in to use addresses obtained via UPnP or NAT-PMP by writing to
specific APIs for those protocols.
A discussion of considerations around changes to the IP model can be
found in [I-D.iab-ip-model-evolution]. It concludes that any changes
to the IP model need to be done with extreme care. Extensions that
merely add additional optional functionality without impact any
existing applications (as in the approach UPnP and NAT-PMP took) are
much safer.
We must also consider the long-term impact of any change to the IP
model. We have learned by experience that there is a consistent
demand for any IPv4 hacks to also show up in IPv6. Typically the
rationale is that once administrators and support personnel are used
to something, they want to continue to use it, and specifically they
want it to work the same way in IPv6. For example, whereas it was
originally expected that NAT would only ever be deployed for IPv4
since IPv6 had plenty of address space. However, recently there has
been some vocal demand for NAT in IPv6 so that it can work the same
way. Hence the key learning is that simply declaring "this hack is
only for IPv4" does not work.
Thaler Expires September 1, 2010 [Page 4]
Internet-Draft Issues With Port-Restricted IP Addresses February 2010
3. Host Implementation Issues
To actually apply a port restriction, host stack implementations
would need to change. Without such a change, a host may naturally
attempt to use the IP address with arbitrary protocols and ports,
which would be akin to address spoofing in a port-restricted IP
address model.
Even with a modified host stack implementation, applications
expecting to bind to a specific port number (such as an application
with an IANA=assigned port number) would fail. One difference from a
classic NAT is that in a typical NAT deployment, if an application
sees that an interface has a global IP address on it, the application
has no reason to believe there is any restriction on its use.
One mitigation that has been proposed is to implement a NAT in the
host kernel. However, this means that an application cannot
communicate even with other nodes on the same physical subnet without
going through the host NAT. As a result, intra-link communication
that depends on broadcast, multicast, TTL=1, or transparency (e.g.,
because of payloads embedding IP addresses) would fail. In contrast,
in a classic NAT deployment, communication between two nodes on the
private side can occur normally. Hence this issue is specific to
port-restricted IP addresses.
Another potential issue with introducing a NAT in the host kernel is
that if the NAT is done in a way that introduces another hop, the
topology is thus modified in a way that a user would not expect. So
applications and utilities that expose the topology to the user in
some way will result in user confusion.
Another host issue with port-restricted IP addresses arises whenever
multiple interfaces exist that have port-restricted IP addresses with
disjoint ports. For example, if an application binds to IN_ADDR_ANY
for on-link communication, the host stack must pick a port that is
independent of interface or address. However, in this case, there is
no such port, and hence the bind would fail.
Finally, consider a host roaming between two networks, one of which
is a typical network today, and the other uses a port-restricted IP
address. In this case, an application may have already issued a bind
(e.g., for UDP) before roaming, and been assigned a port. After
roaming, the port would be invalid and there may be no way to inform
an existing application. Hence introducing port-restricted IP
addresses would require changes to many applications, not just host
stacks.
Thaler Expires September 1, 2010 [Page 5]
Internet-Draft Issues With Port-Restricted IP Addresses February 2010
4. Application/Protocol Issues
One limitation of a port-restricted IP address is that non-port-based
protocols cannot work. This is more severe than a classic NAT, since
with a port-restricted IP address, they cannot be used even within
the same link, whereas with a classic NAT, private IP addresses can
still be used with non-port-based protocols between hosts on the
private side of the NAT.
In some scenarios, a port-restricted IP address might be designed to
be assigned to the public side of a classic NAT device. However,
this would still result in two issues. First, the NAT device itself
would lose the ability to use non-port-based protocols (e.g., the
ability to respond to IPv4 pings, the ability to support 6to4
[RFC3056], etc.). Second, if an end host is connected to the network
instead of the expected NAT device, unexpected failures would occur.
5. Management Issues
ICMP messages that don't embed a packet have no port numbers. As
such, they could not be used with port-restricted IP addresses. With
some effort, ICMP messages initiated from a port-restricted IP
address could be made to work, but not ICMP messages (that have no
embedded packet) destined to such an address.
Hence there would be no way for a service provider technician to ping
such an address. If a port-restricted IPv4 address were used
alongside a normal IPv6 address, the IPv6 address could be pinged,
but such a ping would provide no liveness indication of the IPv4
stack on the destination. In contrast, ping, traceroute, and similar
mechanisms today work fine within the area behind a classic NAT.
Hence this issue is specific to port-restricted IP addresses.
In addition, the existing IP MIB [RFC4293] surfaces the existing IP
Model to management applications, and cannot express port-restricted
IP addresses. Introducing this concept would require new MIB and
management tool work.
Another aspect of management is provisioning. In order to configure
an interface with a port-restricted IP address, the network's
provisioning system would need to evolve. For example, this may
involve changes to DHCP, databases, management tools, auditing/
accounting systems, etc. These systems are often complex and hence
their evolution is costly and takes time.
This issue could be compounded by stateful dynamic port range
allocation. In addition, there would be fairness issues resulting
Thaler Expires September 1, 2010 [Page 6]
Internet-Draft Issues With Port-Restricted IP Addresses February 2010
from the fact that not all port ranges are of equal value. For
example, system ports are often considered more valuable than user
ports, and ports IANA has assigned to popular protocols/applications
are more valuable than other ports.
6. Personnel Issues
Introducing such a far-reaching change would require retraining
personnel, such as developers, technical support personnel,
consultants, and enterprise IT pros. This training is in addition to
anything already inherent in address sharing.
We already understand what fails with NATs and double NATs (since
many homes are already double NAT-ed today). Port-restricted IP
addresses introduce significant complexity with new and hence unknown
(to existing personnel) failure modes. This would likely increase
costs significantly compared to multiple levels of NAT.
7. Security Considerations
One mitigation for security attacks against TCP is port randomization
[I-D.ietf-tsvwg-port-randomization]. Reducing the port space
available to host thus reduces its ability to randomize ports, and
hence has negative security implications. This issue would be made
worse if there were any port sub-delegation (where sub-ranges are
allocated out of larger ranges), since each hierarchy level would
introduce some wasted ports.
8. IANA Considerations
This document has no actions for IANA.
9. Conclusion
The notion of port-restricted IP addresses would be a drastic change
to the IP model with far-reaching impact. The impact would include
lots of complexity, with many problems known (as enumerated herein)
and probably more. In any new and complex change, some people/
implementations would likely get it wrong or incomplete the first
time.
In conclusion, all things considered, the impact of port-restricted
IP addresses is believed to be worse overall than the impact of
multiple layers of NAT. The primary cause of the issues unique to
Thaler Expires September 1, 2010 [Page 7]
Internet-Draft Issues With Port-Restricted IP Addresses February 2010
port-restricted IP addresses comes from assigning such an address to
a device's interface. This concept does not occur in classic NAT,
even when used with protocols such as UPnP or NAT-PMP. It is
possible that the same state benefits motivating the concept of port-
restricted IP addresses may be possible in other approaches that do
not involve assigning a port-restricted IP address to an interface,
but this investigation is left to other documents.
10. References
10.1. Normative References
[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or
converting network protocol addresses to 48.bit Ethernet
address for transmission on Ethernet hardware", STD 37,
RFC 826, November 1982.
[RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host
Anycasting Service", RFC 1546, November 1993.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4293] Routhier, S., "Management Information Base for the
Internet Protocol (IP)", RFC 4293, April 2006.
[RFC5227] Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227,
July 2008.
10.2. Informative References
[I-D.ford-shared-addressing-issues]
Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
Roberts, "Issues with IP Address Sharing",
draft-ford-shared-addressing-issues-01 (work in progress),
October 2009.
[I-D.iab-anycast-arch-implications]
McPherson, D. and D. Oran, "Architectural Considerations
of IP Anycast", draft-iab-anycast-arch-implications-00
(work in progress), February 2010.
[I-D.iab-ip-model-evolution]
Thaler, D., "Evolution of the IP Model",
Thaler Expires September 1, 2010 [Page 8]
Internet-Draft Issues With Port-Restricted IP Addresses February 2010
draft-iab-ip-model-evolution-01 (work in progress),
November 2008.
[I-D.ietf-tsvwg-port-randomization]
Larsen, M. and F. Gont, "Transport Protocol Port
Randomization Recommendations",
draft-ietf-tsvwg-port-randomization-06 (work in progress),
February 2010.
Author's Address
Dave Thaler
Microsoft
One Microsoft Way
Redmond, WA 98052
USA
Phone: +1 425 703 8835
Email: dthaler@microsoft.com
Thaler Expires September 1, 2010 [Page 9]
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/