idnits 2.17.1 draft-thaler-port-restricted-ip-issues-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 28, 2010) is 5170 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 1546 == Outdated reference: A later version (-02) exists of draft-ford-shared-addressing-issues-01 == Outdated reference: A later version (-12) exists of draft-iab-anycast-arch-implications-00 == Outdated reference: A later version (-04) exists of draft-iab-ip-model-evolution-01 == Outdated reference: A later version (-09) exists of draft-ietf-tsvwg-port-randomization-06 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Thaler 3 Internet-Draft Microsoft 4 Expires: September 1, 2010 February 28, 2010 6 Issues With Port-Restricted IP Addresses 7 draft-thaler-port-restricted-ip-issues-00.txt 9 Abstract 11 This document discusses issues with assigning an IP address to a host 12 interface such that the IP address may only be used with a restricted 13 set of ports. This concept is referred to herein as a port- 14 restricted IP address. A number of issues with this concept are 15 documented, and the issues are contrasted with other approaches to 16 dealing with IPv4 address exhaustion. 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on September 1, 2010. 41 Copyright Notice 43 Copyright (c) 2010 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. IP Model Issues . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Host Implementation Issues . . . . . . . . . . . . . . . . . . 5 61 4. Application/Protocol Issues . . . . . . . . . . . . . . . . . . 6 62 5. Management Issues . . . . . . . . . . . . . . . . . . . . . . . 6 63 6. Personnel Issues . . . . . . . . . . . . . . . . . . . . . . . 7 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 66 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 10.1. Normative References . . . . . . . . . . . . . . . . . . . 8 69 10.2. Informative References . . . . . . . . . . . . . . . . . . 8 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 1. Introduction 74 In this document we use the term "port-restricted IP address" to mean 75 an address assigned to an interface of some device, where that 76 address can only be used with a restricted set of port numbers in 77 TCP, UDP, and/or other transport protocols. 79 Port-restricted IP addresses have been proposed as one mechanism to 80 allow address re-use (using disjoint sets of port numbers) among many 81 nodes, which is motivated by IPv4 address scarcity. 83 A port-restricted IP address differs from other types of shared 84 addresses, such as resulting from a classic Network Address 85 Translator (NAT) in that a port-restricted IP address is actually 86 assigned to an interface of some device. In contrast, in a typical 87 network address translation deployment, a public IPv4 address is 88 shared among many hosts by being assigned to an external interface of 89 the NAT device (where it is usable with all protocols and ports, and 90 hence is not port-restricted). Each host on the private side of the 91 NAT uses a separate, private IPv4 address assigned to its own 92 interface, and the private IPv4 address is usable on the private 93 subnet with all protocols and ports. 95 There are three types of issues with the concept of port-restricted 96 IP addresses: 97 a. Issues inherent in any type of address sharing, including Network 98 Address Translation (NAT). These issues are discussed in 99 [I-D.ford-shared-addressing-issues] and hence are outside the 100 scope of this document. 101 b. Issues that exist in other types of address sharing such as NATs, 102 but which are made worse in some way with port-restricted IP 103 addresses. 104 c. Issues unique to port-restricted IP addresses. 106 This document covers the latter two types of issue. 108 2. IP Model Issues 110 A "unicast address" is defined (e.g., in [RFC4291]) as an identifier 111 for a single interface. A packet sent to a unicast address is 112 delivered to the interface identified by that address. Many 113 protocols, including ARP [RFC0826] [RFC5227] rely on this fact. 115 Creating a port-restricted unicast IP address would require a change 116 to the above definition so that it could be assigned to multiple 117 interfaces (on different hosts) within the address's scope. 119 This change to the IP model would be as big as, but quite different 120 from, the introduction of NAT. This issue is unique to port- 121 restricted IP addresses, since in classic NAT, each IP address is 122 only assigned to a single interface. 124 The closest concept that exists today is that of an "anycast" address 125 [RFC1546] [RFC4291]. An anycast address is defined as an identifier 126 for a set of interfaces, where a packet sent to an anycast address is 127 delivered to the "nearest" interface according to the routing 128 protocols' measure of distance. For additional discussion of anycast 129 considerations, see [I-D.iab-anycast-arch-implications]. An anycast 130 address differs from a port-restricted IP address in that an anycast 131 address may still be used with any protocol or port, and all 132 interfaces with the same anycast address are considered equivalent. 134 It is also worth noting the distinction between a port-restricted IP 135 address, and an address/port obtained from a NAT by an application 136 using a protocol such as UPnP or NAT-PMP. In the UPnP/NAT-PMP model, 137 the address is still assigned to the NAT's public interface, not an 138 interface of the host on which the application is running. As such, 139 UPnP/NAT-PMP-unaware applications that see addresses of the local 140 machine via local APIs (e.g., getsockaddr) will never see such an 141 address, and hence no API contract is affected. Thus, applications 142 opt in to use addresses obtained via UPnP or NAT-PMP by writing to 143 specific APIs for those protocols. 145 A discussion of considerations around changes to the IP model can be 146 found in [I-D.iab-ip-model-evolution]. It concludes that any changes 147 to the IP model need to be done with extreme care. Extensions that 148 merely add additional optional functionality without impact any 149 existing applications (as in the approach UPnP and NAT-PMP took) are 150 much safer. 152 We must also consider the long-term impact of any change to the IP 153 model. We have learned by experience that there is a consistent 154 demand for any IPv4 hacks to also show up in IPv6. Typically the 155 rationale is that once administrators and support personnel are used 156 to something, they want to continue to use it, and specifically they 157 want it to work the same way in IPv6. For example, whereas it was 158 originally expected that NAT would only ever be deployed for IPv4 159 since IPv6 had plenty of address space. However, recently there has 160 been some vocal demand for NAT in IPv6 so that it can work the same 161 way. Hence the key learning is that simply declaring "this hack is 162 only for IPv4" does not work. 164 3. Host Implementation Issues 166 To actually apply a port restriction, host stack implementations 167 would need to change. Without such a change, a host may naturally 168 attempt to use the IP address with arbitrary protocols and ports, 169 which would be akin to address spoofing in a port-restricted IP 170 address model. 172 Even with a modified host stack implementation, applications 173 expecting to bind to a specific port number (such as an application 174 with an IANA=assigned port number) would fail. One difference from a 175 classic NAT is that in a typical NAT deployment, if an application 176 sees that an interface has a global IP address on it, the application 177 has no reason to believe there is any restriction on its use. 179 One mitigation that has been proposed is to implement a NAT in the 180 host kernel. However, this means that an application cannot 181 communicate even with other nodes on the same physical subnet without 182 going through the host NAT. As a result, intra-link communication 183 that depends on broadcast, multicast, TTL=1, or transparency (e.g., 184 because of payloads embedding IP addresses) would fail. In contrast, 185 in a classic NAT deployment, communication between two nodes on the 186 private side can occur normally. Hence this issue is specific to 187 port-restricted IP addresses. 189 Another potential issue with introducing a NAT in the host kernel is 190 that if the NAT is done in a way that introduces another hop, the 191 topology is thus modified in a way that a user would not expect. So 192 applications and utilities that expose the topology to the user in 193 some way will result in user confusion. 195 Another host issue with port-restricted IP addresses arises whenever 196 multiple interfaces exist that have port-restricted IP addresses with 197 disjoint ports. For example, if an application binds to IN_ADDR_ANY 198 for on-link communication, the host stack must pick a port that is 199 independent of interface or address. However, in this case, there is 200 no such port, and hence the bind would fail. 202 Finally, consider a host roaming between two networks, one of which 203 is a typical network today, and the other uses a port-restricted IP 204 address. In this case, an application may have already issued a bind 205 (e.g., for UDP) before roaming, and been assigned a port. After 206 roaming, the port would be invalid and there may be no way to inform 207 an existing application. Hence introducing port-restricted IP 208 addresses would require changes to many applications, not just host 209 stacks. 211 4. Application/Protocol Issues 213 One limitation of a port-restricted IP address is that non-port-based 214 protocols cannot work. This is more severe than a classic NAT, since 215 with a port-restricted IP address, they cannot be used even within 216 the same link, whereas with a classic NAT, private IP addresses can 217 still be used with non-port-based protocols between hosts on the 218 private side of the NAT. 220 In some scenarios, a port-restricted IP address might be designed to 221 be assigned to the public side of a classic NAT device. However, 222 this would still result in two issues. First, the NAT device itself 223 would lose the ability to use non-port-based protocols (e.g., the 224 ability to respond to IPv4 pings, the ability to support 6to4 225 [RFC3056], etc.). Second, if an end host is connected to the network 226 instead of the expected NAT device, unexpected failures would occur. 228 5. Management Issues 230 ICMP messages that don't embed a packet have no port numbers. As 231 such, they could not be used with port-restricted IP addresses. With 232 some effort, ICMP messages initiated from a port-restricted IP 233 address could be made to work, but not ICMP messages (that have no 234 embedded packet) destined to such an address. 236 Hence there would be no way for a service provider technician to ping 237 such an address. If a port-restricted IPv4 address were used 238 alongside a normal IPv6 address, the IPv6 address could be pinged, 239 but such a ping would provide no liveness indication of the IPv4 240 stack on the destination. In contrast, ping, traceroute, and similar 241 mechanisms today work fine within the area behind a classic NAT. 242 Hence this issue is specific to port-restricted IP addresses. 244 In addition, the existing IP MIB [RFC4293] surfaces the existing IP 245 Model to management applications, and cannot express port-restricted 246 IP addresses. Introducing this concept would require new MIB and 247 management tool work. 249 Another aspect of management is provisioning. In order to configure 250 an interface with a port-restricted IP address, the network's 251 provisioning system would need to evolve. For example, this may 252 involve changes to DHCP, databases, management tools, auditing/ 253 accounting systems, etc. These systems are often complex and hence 254 their evolution is costly and takes time. 256 This issue could be compounded by stateful dynamic port range 257 allocation. In addition, there would be fairness issues resulting 258 from the fact that not all port ranges are of equal value. For 259 example, system ports are often considered more valuable than user 260 ports, and ports IANA has assigned to popular protocols/applications 261 are more valuable than other ports. 263 6. Personnel Issues 265 Introducing such a far-reaching change would require retraining 266 personnel, such as developers, technical support personnel, 267 consultants, and enterprise IT pros. This training is in addition to 268 anything already inherent in address sharing. 270 We already understand what fails with NATs and double NATs (since 271 many homes are already double NAT-ed today). Port-restricted IP 272 addresses introduce significant complexity with new and hence unknown 273 (to existing personnel) failure modes. This would likely increase 274 costs significantly compared to multiple levels of NAT. 276 7. Security Considerations 278 One mitigation for security attacks against TCP is port randomization 279 [I-D.ietf-tsvwg-port-randomization]. Reducing the port space 280 available to host thus reduces its ability to randomize ports, and 281 hence has negative security implications. This issue would be made 282 worse if there were any port sub-delegation (where sub-ranges are 283 allocated out of larger ranges), since each hierarchy level would 284 introduce some wasted ports. 286 8. IANA Considerations 288 This document has no actions for IANA. 290 9. Conclusion 292 The notion of port-restricted IP addresses would be a drastic change 293 to the IP model with far-reaching impact. The impact would include 294 lots of complexity, with many problems known (as enumerated herein) 295 and probably more. In any new and complex change, some people/ 296 implementations would likely get it wrong or incomplete the first 297 time. 299 In conclusion, all things considered, the impact of port-restricted 300 IP addresses is believed to be worse overall than the impact of 301 multiple layers of NAT. The primary cause of the issues unique to 302 port-restricted IP addresses comes from assigning such an address to 303 a device's interface. This concept does not occur in classic NAT, 304 even when used with protocols such as UPnP or NAT-PMP. It is 305 possible that the same state benefits motivating the concept of port- 306 restricted IP addresses may be possible in other approaches that do 307 not involve assigning a port-restricted IP address to an interface, 308 but this investigation is left to other documents. 310 10. References 312 10.1. Normative References 314 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 315 converting network protocol addresses to 48.bit Ethernet 316 address for transmission on Ethernet hardware", STD 37, 317 RFC 826, November 1982. 319 [RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host 320 Anycasting Service", RFC 1546, November 1993. 322 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 323 via IPv4 Clouds", RFC 3056, February 2001. 325 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 326 Architecture", RFC 4291, February 2006. 328 [RFC4293] Routhier, S., "Management Information Base for the 329 Internet Protocol (IP)", RFC 4293, April 2006. 331 [RFC5227] Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227, 332 July 2008. 334 10.2. Informative References 336 [I-D.ford-shared-addressing-issues] 337 Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 338 Roberts, "Issues with IP Address Sharing", 339 draft-ford-shared-addressing-issues-01 (work in progress), 340 October 2009. 342 [I-D.iab-anycast-arch-implications] 343 McPherson, D. and D. Oran, "Architectural Considerations 344 of IP Anycast", draft-iab-anycast-arch-implications-00 345 (work in progress), February 2010. 347 [I-D.iab-ip-model-evolution] 348 Thaler, D., "Evolution of the IP Model", 349 draft-iab-ip-model-evolution-01 (work in progress), 350 November 2008. 352 [I-D.ietf-tsvwg-port-randomization] 353 Larsen, M. and F. Gont, "Transport Protocol Port 354 Randomization Recommendations", 355 draft-ietf-tsvwg-port-randomization-06 (work in progress), 356 February 2010. 358 Author's Address 360 Dave Thaler 361 Microsoft 362 One Microsoft Way 363 Redmond, WA 98052 364 USA 366 Phone: +1 425 703 8835 367 Email: dthaler@microsoft.com