idnits 2.17.1 draft-irtf-nsrg-report-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 20, 2003) is 7701 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 3022 (ref. '3') ** Obsolete normative reference: RFC 2616 (ref. '4') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' == Outdated reference: A later version (-22) exists of draft-ietf-secsh-architecture-13 ** Obsolete normative reference: RFC 2406 (ref. '9') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2409 (ref. '10') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2246 (ref. '11') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2440 (ref. '12') (Obsoleted by RFC 4880) ** Downref: Normative reference to an Informational RFC: RFC 2775 (ref. '13') ** Downref: Normative reference to an Informational RFC: RFC 2993 (ref. '14') ** Downref: Normative reference to an Informational RFC: RFC 3027 (ref. '15') ** Obsolete normative reference: RFC 1771 (ref. '16') (Obsoleted by RFC 4271) ** Obsolete normative reference: RFC 2002 (ref. '17') (Obsoleted by RFC 3220) == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-18 ** Obsolete normative reference: RFC 2960 (ref. '19') (Obsoleted by RFC 4960) == Outdated reference: A later version (-22) exists of draft-ietf-tsvwg-addip-sctp-07 == Outdated reference: A later version (-06) exists of draft-moskowitz-hip-arch-02 -- Possible downref: Normative reference to a draft: ref. '21' == Outdated reference: A later version (-06) exists of draft-bradner-pbk-frame-04 ** Downref: Normative reference to an Informational draft: draft-bradner-pbk-frame (ref. '22') ** Downref: Normative reference to an Experimental RFC: RFC 3102 (ref. '23') ** Downref: Normative reference to an Informational RFC: RFC 3303 (ref. '24') -- Possible downref: Normative reference to a draft: ref. '25' ** Downref: Normative reference to an Historic RFC: RFC 2776 (ref. '26') Summary: 21 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Lear 3 Internet-Draft R. Droms 4 Expires: September 18, 2003 Cisco Systems, Inc. 5 March 20, 2003 7 What's In A Name: Thoughts from the NSRG 8 draft-irtf-nsrg-report-09.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on September 18, 2003. 33 Copyright Notice 35 Copyright (C) The Internet Society (2003). All Rights Reserved. 37 Abstract 39 Over the last few years, the use of IP addresses for Internet 40 connectivity has changed dramatically. The Name Space Research Group 41 (NSRG) has been chartered by the IRTF to review these changes, and 42 make recommendations on whether or not remediation within the 43 protocol stack is necessary. This document reports the outcome of 44 some of the discussions within the research group. 46 One of the questiones addressed by the NSRG is: Does the TCP/IP 47 protocol suite need an additional level of naming above layer 3 but 48 below the application layer? This document reviews the motivation 49 for an additional naming mechanism, reviews related work, proposes a 50 straw man "stack name" and discusses the structure and use of stack 51 names. 53 1. Introduction 55 The use of IP addresses in the Internet has changed over time. While 56 routing of IP packets has remained largely unchanged, the use and 57 assignment of IP addresses has changed considerably. 59 For many years, hosts participating in an exchange of IP datagrams 60 could be named either by IP address or by a mnemonic domain name that 61 could be resolved to that address. The static binding between name 62 and address allowed the interchangeable use of either to identify a 63 host. 65 However, several new developments have changed the nature of 66 addressing in the Internet: 68 o dynamic IP addressing, as provided, for example, through PPP [1] 69 and DHCP [2] 71 o private network address space and network address translators 72 (NAT) [3] 74 o virtual hosts, where one host is assigned multiple IP addresses 76 o load sharing or load balancing, where one IP address is shared by 77 multiple hosts, so the services at that address can be provided by 78 multiple hosts 80 The overall addressing model on the Internet has shifted to one of 81 dynamic binding between a host and its address. A host is assigned 82 an address from place to place, or from time to time, when the host 83 needs to assert a location in the network topology. In addition, a 84 single IP address can now be shared by multiple servers to represent 85 a single logical end point. The converse is also true - a single 86 server can represent multiple logical endpoints, and not even have to 87 use multiple addresses [4]. 89 This is not the first document to point out the differences between 90 names, addresses, and routes. Shoch delineated those differences as 91 early as 1978 [5]. Saltzer, et al., have also written about the 92 nature of naming and addressing [6][7]. Research into the nature of 93 names, addresses and routes can help provide insight into the current 94 situation, in which the function of IP addresses is overloaded to 95 serve the function of a location in the network, an interface, a host 96 name, and a portion of that which identifies a TCP connection. 98 Given the changing nature of the use of IP addresses for end point 99 identification on the network, is something more than IP addresses 100 and domain names needed to identify hosts? What functionality would 101 that something bring to the table? 103 1.1 Security Considerations 105 Communications today are secured through one of several means. For 106 strongest protocol security, the communication is encrypted and the 107 ends are identified with verifiable public keys. Several systems are 108 available today to do this, including SSH [8], the IPSEC mechanisms 109 of ESP [9] and IKE [10], TLS [11], and PGP [12]. 111 The absence of a name space that uniquely identifies a host has 112 created problems in the design of ESP and AH (IPsec). ESP and AH 113 should bind security associations to a name for a host that is 114 distinct from either a domain name or an IP address, because both 115 the DNS entry and the IP address can change, for example when a 116 host moves form one point in a network to another, while the 117 security association could remain valid. Another advantage to a 118 name space that is independent of the network topology is that ESP 119 and AH could use such names for security associations that traverse 120 NAT devices. In the absence of a persistent name in the Internet 121 Architecture, IP addresses are used for the binding of security 122 associations. This is an architectural shortcoming, not a feature. 124 At a different level, there is an expectation that the routing system 125 guides a packet toward the destination end point indicated in the IP 126 destination address. Until a few years ago, this would not have been 127 an unreasonable assumption. Today there are exceptions, particularly 128 transparent web proxies and firewalls. 130 With some of the currently contemplated changes, the risk of a 131 transport connection being hijacked changes. Instead of having to 132 intercept every packet, an attacker may only need to forge a 133 rebinding message to one end or the other of a connection. 135 1.2 How Things Have Changed 137 As mentioned earlier, the nature of addressing in the Internet has 138 changed. One important change in the Internet addressing model comes 139 from the use of NAT [13][14][15]. When a web client contacts a 140 server to request a web page, it is quite likely that the remote 141 address and TCP port, as it appears to the web server, will not be 142 the same as the host's source address and port used by the web 143 client. Furthermore, it is likely to be difficult for the web client 144 to determine the address received by the server as the client's 145 address. And, a host that has a NAT device between it and the 146 Internet cannot become a server because other clients have no way to 147 address it. 149 Another change to the addressing model in the Internet is that 150 computers are far more mobile than they were just a few years ago. 151 When a host moves from one location to another, its address changes 152 to reflect the change in its point of attachment to the Internet. 153 Because TCP bases its transport connection state on IP addresses, any 154 connections to the old address are lost (but see below). 156 One of the largest changes in the character of Internet usage 157 involves the resources people access and how they access them. 158 Whereas in the past one intended to access a particular host with a 159 particular IP address, today one is likely more interested in 160 accessing a service, such as a news service, or a banking service, 161 and one is less interested in the host upon which the service sits. 162 An industry has built up around the notion these so-called content 163 delivery or overlay networks. The IP address of the web server 164 provides an ephemeral point of contact for a particular web page. In 165 particular with secure services, what matters most to the user is 166 that a particular trusted company has verifiably provided the 167 service. 169 1.3 Why Things Have Changed 171 The most important change the Internet has undergone is spectacular 172 growth. The result of the growth has been shortages in address space 173 and routing resources. 175 As the growth of the Internet exploded so did address space 176 utilization. A combination of measures, including the introduction 177 of private address space, NATs, and a tightening of policy by 178 addressing registries reduced the risk of the Internet running out of 179 allocatable addresses until the 2010 time frame (or later). As a 180 result, however, the unique identification of a host and the 181 universal ability to reach it was lost. 183 At the same time, Internet routing tables exploded in size. To 184 reduce routing tables routes, classless routing [16] was developed 185 and deployed to aggregate routes on bit boundaries, rather than on 186 old classful boundaries. Next, the IANA discontinued its policy of 187 allocating addresses directly to end users and instead allocated them 188 hierarchically to providers, requiring providers to show sufficient 189 allocation and utilization to justify further assignments. This 190 retarded for a time the explosion in routing, but it did not 191 eliminate growth. While work continues in this area, it is important 192 to understand that as of this writing the aggregation of routes 193 through CIDR is the most efficient way to route Internet traffic, 194 given its current design goals. 196 There is a natural conflict between the above two policies. If one 197 allocates addresses in small chunks, more routing entries will 198 result. Periodically providers will renumber to get larger blocks, 199 at the inconvenience of all of their customers. 201 In summary, the Internet has exploded in size, NATs are now widely 202 present, and the use of mechanisms such as PPP and DHCP are widely 203 deployed. In addition, services are now as much or more of interest 204 than are individual hosts. Given all of these changes, is it 205 possible to add a new name space that will make connectivity more 206 stable and allow us to establish some new operating assumptions, such 207 as the ones that these complications broke? 209 2. Related Work 211 There exists a large body of work on name spaces and their bindings. 212 The work discussed below primarily relates to the binding of stacks 213 to IP addresses, with an eye toward mobility or transience. 215 2.1 Mobile IP 217 Mobile IP addresses the problem of having a stable host identifier on 218 mobile hosts. As a host changes its connection point to the network, 219 it updateds a home agent with the mobile host's new address. The 220 home agent represents a static point through packets can be exchanged 221 with the mobile host. Mobile IP provides a different solutions for 222 IPv4 [17] and IPv6 [18]. In IPv4, Mobile IP is a tunneling 223 mechanism. In IPv6, mobile hosts make use of destination options. A 224 mobile host uses its home address to create transport connections and 225 communicate with other hosts. Datagrams exchanged with an IPv4 226 mobile host are tunneled through a home agent and optionally a 227 foreign agent, so that the mobile host's can be found in the routing 228 system without additional global routing overhead. In IPv4 the home 229 agent is separate from the other end of a transport connection, and 230 packets take a triangular route. In IPv6, support of mobility is 231 required, and the likely non-mobile host, the correspondent node, is 232 aware that the other end is mobile. Therefore, once the mobile host 233 and remote host establish communications they can "short circuit" to 234 remove the home agent. This is key because, while the foreign agent 235 is likely to be near the mobile host, the home agent is unlikely to 236 be near anybody. 238 _______ ________ 239 | |Care-of Address | | foreign agent optionally 240 |Mobile |--------------------| Remote | forwards packets to mobile 241 | Host | | Agent | host 242 |_______| |________| 243 ::Home Address | 244 :: | home agent encapsulates and passes 245 :: | packets to the remote agent or 246 :: ___|____ directly to the mobile node 247 :: | | 248 :: | Home | 249 :: | Agent |\ remote host sends packets 250 :: |________| \ to home agent 251 :: \ 252 \\ \ 253 \\ \ 254 \\ \_____________ 255 \\ tunneled transport connection | | 256 =====================================|Correspondent| 257 | Node | 258 |_____________| 260 Figure 1: Mobile IPv4 262 In effect, Mobile IP turns the mobile node's IP address into a host 263 identifier, where the "care of" address is the host's current 264 location. The way Mobile IP succeeds is that it uses tunneling 265 within the topology to represent an address at one location when it 266 is in fact at another. However, a route to the mobile node's address 267 itself must be available within the topology at all times. In an 268 IPv4 world this would be untenable because of constraints on both the 269 addressing and routing systems. With IPv6, the addressing pressures 270 are off, and so each host can have a unique end address. However, 271 problems remain with the routing system. In addition, there is a 272 class of devices for which there may be no "home", such as devices in 273 airplanes, mobile homes, or constant travelers. Additionally, there 274 is a desire within some of the mobility community to have 275 "micromobility" mechanisms that enable faster movement than 276 envisioned by Mobile IP. The Routing Research Group (rrg) is 277 currently investigating this area. 279 Most importantly, a mobile device can't withstand the loss of the 280 home agent, even if the mobile device is still connected to the 281 network. With the home agent offline, no incoming connections can 282 get to them, and long-lived communications cannot be re-established. 283 If the identity wasn't overloaded on the home address, it might be 284 possible to work around such a failure. 286 2.2 Stream Control Transport Protocol (SCTP) 288 Many of the problems raised have to do with the use of layer 3 289 information at higher layers, such as the use of a layer 3 address as 290 the end point identifier for a TCP connection and the use of layer 3 291 addresses in the pseudo-header in TCP. SCTP [19], an alternative to 292 TCP, uses IP addresses in a more dynamic way as the identifiers for 293 connection end points. TCP transport connection end points are named 294 by IP addresses, and there are precisely two end point addresses, one 295 for each end. SCTP allows multiple addresses per end, nominally for 296 redundancy of applications that require high availability. However, 297 it is possible to move a connection as a host moves from one location 298 to another, or as its address changes due to renumbering (for 299 whatever purpose). Work has progressed within the IETF to introduce 300 a new capability to SCTP, that allows connection end points to change 301 the set of IP addresses used for a connection [20]. 303 There are three limitations to this idea. For one, it only affects 304 those hosts that use SCTP, and therefore the idea is not sufficiently 305 general. 307 The second problem is that, as contemplated in the draft, the risk of 308 an attacker hijacking a connection is elevated. This same problem 309 exists within Mobile IP, and may similarly be mitigated by purpose 310 built keys (see below). 312 Finally, because SCTP does not have a home agent, SCTP does not 313 handle the case when two nodes change their location at the same 314 time, a case some would argue is a corner case. 316 2.3 Host Identity Payload (HIP) 318 Host Identity Payload (HIP) is a new approach to the problem of 319 naming end points [21]. It inserts an additional "name" between 320 layer 3 and layer 4, thus becoming layer 3.5. The goal is to 321 decouple the transport layer from the Internet layer, so that changes 322 in the Internet layer do not impact the transport layer, and the 323 benefit is shared by all mechanisms atop transport protocols that use 324 HIP. 326 ______________________________________ 327 | | 328 | Application | 329 |______________________________________| 330 | | 331 | Transport | 332 |______________________________________| The Host Stack 333 | | 334 | HIP or ESP w/ HI as SPI | 335 |______________________________________| 336 | | 337 | Internet | 338 |______________________________________| 340 Figure 2: Host Identity 342 HIP itself relies on a cryptographic host identity (HI) that is 343 represented in a Host Identity Tag (HIT) of various forms. One is a 344 hash of the public key host identity, another is an administratively 345 assigned value coupled with a smaller hash of the public key host 346 identity. Host identities can be public or anonymous, the difference 347 being whether or not they are published in a directory. 349 Whereas today one binds the transport layer to an IP address, HIP 350 proposes that the transport layer binds to a host identity tag (HIT). 351 The DNS is used to determine the HI and HIT, or to validate via 352 reverse lookup an HIT. Further, the DNS continues to be used to get 353 an Internet address. 355 Whether one should want to decouple the transport layer from the 356 Internet layer is a controversial question. After all, that coupling 357 has for many years provided the barest bones of the security of 358 knowing that the packets that make up the connection are being guided 359 through the network by routing tables in Internet routers that are 360 owned by people and organizations whose intent is to get one's 361 packets from source to destination. If we divorce the transport 362 layer from the Internet layer, we introduce another way for an 363 attacker to potentially hijack connections. HIP attempts to address 364 this through the use of public key verification. 366 Additionally, HIP raises an issue regarding other uses for 367 aggregation of IP addresses. Today, they are not only aggregated for 368 purposes of reduced routing, but also for reduced administration. A 369 typical access list used on the Internet will have some sort of a 370 mask, indicating that a group of hosts from the same subnet may 371 access some resource. Because the value of a HIT is a hash in part, 372 only the administratively assigned value can be aggregated, 373 introducing an allocation limitation and authorization concerns. 375 On the other hand, there is the old computer science saying, any 376 problem can be fixed by an additional layer of indirection It should 377 be possible to administratively aggregate on groupings that are made 378 at higher layers. 380 An alternative approach would be to aggregate based on domain names, 381 rather than HI values. draft-moskowitz-hip-arch-02.txt [21] 382 describes this approach in more detail. 384 A key concern with HIP is whether or not it will work in a mobile 385 world. If the DNS is involved, or if any directory is involved, will 386 caching semantics eventually limit scalability, or are there mobility 387 mechanisms that can be employed to make use of directories feasible? 389 2.4 Purpose Built Keys 391 Purpose built keys (PBKs) are temporary end point identifiers that 392 are used to validate a given endpoint during a communication [22]. 393 PBKs are similar to HIP. Rather than attempting to build an 394 infrastructure to validate the end points, however, PBK's sole 395 purpose is to ensure that two hosts that originate a communication 396 may continue that communication with the knowledge that at its 397 conclusion each end point will be the same end point it was at the 398 start. Thus, even if one's address changes it is still possible to 399 validate oneself to the other side of the communication. 401 PBKs make no claim as to who the parties actually are. They make no 402 use of public key infrastructures. PBKs are themselves ephemeral for 403 the duration of a communication. 405 PBKs take the form of ad hoc public/private key pairs. When a node 406 wishes to validate itself to another node it signs a piece of data 407 with its private key that is validated by the other end with the 408 public key. The public key itself becomes an end point identifier. 410 PBKs might be instantiated in several different places in the stack; 411 for example, they may be carried in an IPv6 header extension or used 412 by an application protocol. 414 2.5 RSIP and MIDCOM 416 Two related efforts have been made to stitch together name spaces 417 that conflict. One is Realm Specific IP (RSIP) [23], which allows 418 the temporary allocation of address space in one "realm" by a host in 419 another realm, not unlike the way an address is gotten via DHCP. The 420 benefit of RSIP is that it allows the end point to know what address 421 it is assigned, so that it may pass such information along in the 422 data path, if necessary. The problem with RSIP is that host routing 423 decisions within the stack are very complex. The host makes 424 decisions based on destination, a process that requires a fair amount 425 of configuration, and lacks certainty as it is based on a non-unique 426 IP addresses. Because RSIP borrows public addresses it must 427 relinquish them as quickly as possible, or the point of NAT is 428 negated. In order to make better use of the scarce public resource, 429 RSIP implementations would need to route not just on destination 430 address, but on application information as well. For example, 431 internal hosts would probably not need external addresses merely to 432 browse the web. 434 MIDCOM, an architecture for middlebox communication, is a similar 435 approach [24]. However, rather than tunneling traffic, an agreement 436 between an end point and its agent and a "middle box" such as a NAT 437 or a firewall is made so that the end point understands what 438 transformation will be made by the middle box. Where a NAT or a web 439 cache translates from one name space to another, MIDCOM enables end 440 points to identify that translation. 442 MIDCOM is contemplated for use by specific applications, and thus it 443 avoids the stack problems associated with RSIP. However, neither 444 MIDCOM nor RSIP resolve how to discover such middle boxes. Nor do 445 they provide a unique way for a host behind a NAT to identify itself 446 in an enduring way. Finally, they both run into problems when 447 multiple NATs are introduced in a path. 449 2.6 GSE or "8+8" 451 One proposal attempts to ease the conflict between the end systems' 452 need to have a fixed name for themselves, and the routing systems' 453 need for address assignments that minimize the overhead of routing 454 calculations [25]. The clash between these two needs produces either 455 the inconvenience (for the end systems) of renumbering, or routing 456 inefficiency and potentially poor address space utilization as well. 458 Known as 8+8, Global Site End system (GSE) would have split the 459 IPv6 address into two parts: a routing system portion that would be 460 assigned and managed by service providers that would change based 461 on routing system requirements, and a locally managed portion that 462 would be assigned and managed by terminal autonomous systems. 463 While each portion is globally unique, there are in effect two 464 addresses, one to get a packet to an autonomous system and another 465 to get to the host. Further, end hosts might not be aware, at 466 least initially, of their routing portions. It was envisioned that 467 the renumbering of the routing portion could be done as a matter of 468 signaling, with little 469 administrative involvement from the end point. Another goal of GSE 470 was to eliminate additional routing overhead caused by multihomed end 471 systems, whose information must today be carried throughout the 472 routing system. By allowing end enterprises to have multiple global 473 parts for purposes of multihoming, the terminal ASes would become 474 what are today's last-hop ISPs. 476 Separation of transport names and internet names could also occur by 477 having transports only use the local portion of the IP address in 478 their pseudo-header calculatioons. There are a number of challenges 479 that GSE would have to overcome. For one, how does one glue together 480 the provider portion of an address with the more local part, and how 481 would one accomplish the task securely? Would doing so eliminate the 482 need or interest in adding other additional name spaces? 484 2.7 Universal Resource Names 486 Universal resource names (URNs) do not provide us a mechanism to 487 resolve our naming concerns [26]. Rather, they may provide us the 488 form of the name to use, and perhaps a framework for resolution. For 489 instance, a host identity may conceivably be represented as a URN. 490 URNs further the notion of defining a binding and boundaries between 491 the name of an object and its location. 493 3. Discussion: Users, Hosts, Entities and Stacks 495 The original addressing architecture of IP and TCP assumed that there 496 is a one-to-one relationship between an IP address and a 497 communicating "entity." By "entity," we mean an identifiable 498 participant in an Internet communication. Examples of an entity 499 include a host, a user, a client program or a service. This one-to- 500 one relationship between IP address and entity was assumed to exist 501 throughout the duration of a "session" (usually a TCP connection); 502 that is, all of the IP datagrams exchanged during a session would 503 share the same endpoint identifiers, and the endpoint identifiers in 504 those datagrams would not be altered as the datagrams traversed the 505 Internet. 507 There is also an assumption that the binding between an entity and an 508 IP address would vary only infrequently over time. The DNS allows 509 the binding between a domain name for a host and its IP address to 510 vary over time, but changes in those bindings may propagate slowly 511 and do not accommodate frequent changes. 513 As explained in section 1, the underlying addressing architecture of 514 the Internet has changed, leading to the need for new naming 515 mechanisms that function with host mobility, the instantiation of 516 multiple entities on a single host and the instantiation of a single 517 entity across multiple hosts, and that can provide security 518 independent of IP addressing. 520 When a host moves from one location to another, or when a host 521 receives a new address for some other reason, its identity has not 522 changed, nor has that of the person using it. That entity may well 523 be in communication with other computers and have access rights to 524 network resources. Indeed, multiple entities may be represented by a 525 single computer. 527 ______________________________ 528 | ______ ______ | 529 | /_____ /| /_____ /| | 530 | | APP |f| | APP |b| | 531 | |------|o| |------|a| | 532 | |TRANS |o| |TRANS |r| | 533 | | PORT |.| | PORT |.| | 534 | |------|c| |------|c| | 535 | | IP |o| | IP |o| | 536 | |______ m| |______ m| | 537 | | MAC |/ | MAC |/ | 538 | |______/ |______/ | 539 | | 540 | | 541 |______________________________| 543 Figure 3: One application: multiple stacks on a single device 545 Today, a host may represent multiple entities. This happens when a 546 service provider hosts many web sites on one server. Similarly, a 547 single entity may be represented by multiple hosts. Replicated web 548 servers are just such an example. These entities are "stacks", 549 instantiations of the TCP/IP model, be they across one or many hosts. 550 A stack is defined as one participant or the process on one side of 551 an end-to-end communication. That participant may move and may be 552 represented by multiple hosts. 554 __________________ ________________________ 555 | | | | 556 | _______________| |____________________ | 557 | /_______________| |___________________ /| | 558 | | A P P L I| |C A T I O N |f| | 559 | |----------------| |-------------------|o| | 560 | | T R A N | | P O R T |o| | 561 | |----------------| |-------------------|.| | 562 | | I N T E| |R N E T |c| | 563 | |----------------| |-------------------|o| | 564 | | F R A M| | I N G |m| | 565 | |----------------| |-------------------| / | 566 | |________________| |___________________|/ | 567 | | | | 568 |__________________| |________________________| 570 Figure 4: Another application: single stack represented by multiple 571 hosts 573 Each instance of a stack has a name, a "stack name". At an 574 architectural level the Name Space Research Group debated the value 575 of such names, and their associated costs. Forms of this name are 576 used in numerous places today. SSH uses public/private key pairs to 577 identify end points. An HTTP cookie anonymously identifies one end 578 of a communication, in such a manner that both the connection and the 579 IP address of the other end point may change many times. Stack names 580 are intended to identify mobile nodes, devices behind NATs, and 581 participants in a content delivery or overlay network. 583 When two devices represent a single end point they must share state 584 in order to keep the other end from becoming confused (to say the 585 very least). When doing so, such stacks may indeed consist of 586 multiple processes on each end. One view is that such processes can 587 theoretically be named independently of the Internet layer, allowing 588 for sessions to migrate at the behest of applications. However, it 589 is not possible to standardize migration independent of applications 590 that retain state in all manner of places, from configuration files 591 to memory. Additional names of such processes serve only to identify 592 those who are authorized somehow to represent the end point, and do 593 not themselves alleviate effort required to ensure application 594 consistency. 596 As used above, "sessions" are a mechanism that the current IP stack 597 does not formally provide. If a session layer existed in the classic 598 sense it might sit above the transport layer, and a session could 599 consist of more than a single transport layer connection. If the 600 session layer appears below the transport layer, then transport layer 601 connections can be bound to a name, such as a session identifier, 602 something other than that of the IP address, and transport layer 603 connections could persist across IP address changes. 605 3.1 Requirements, desirable features and design decisions 607 Stack names are defined to be a new naming structure integrated into 608 Internet addressing, which provide a solution to several problems in 609 the current addressing architecture. We have identified several 610 requirements for this naming structure. Stack names will allow 611 continuation of sessions independent of host mobility or other host 612 renumbering. A stack that spans several hosts is identified by a 613 single stack name, and multiple stacks on a single host are 614 unambiguously identified by separate stack names. Stack names allow 615 authentication of stack identity, authentication of the origin and 616 contents of messages and privacy for message contents. Finally, the 617 stack name architecture will interoperate with existing Internet 618 infrastructure, including existing host implementations and core 619 routing, for backward compatibility. 621 Stack names are intended to address as many of the problems in the 622 current Internet addressesing as possible, including: NAT, mobility, 623 renumbering, multiple entities on one host and entities that span 624 multiple hosts. Stack names should be globally unique, so that state 625 about stack names, such as mapping information, need not be kept in 626 the network. Stack names should also provide anonymity, so that 627 users or other entities cannot be easily identified through a stack 628 name. 630 These requirements and features lead to several design decisions: 632 o Internal structure: opaque/structured, fixed-length/variable- 633 length, universally-unique/random-unique 635 o Position in stack 637 o Mapping to mnemonic name (are stack names ever visible to humans?) 639 o Relationship between stack names and routing system 641 3.2 What do stack names look like? 643 Names may be structured or unstructured. If they are structured, 644 what encoding do they use, and what is their scope? Is the length of 645 such a name fixed or variable? Are stack names unique across the 646 Internet? If so, are they guaranteed unique through some sort of a 647 registry or are they statistically unique? If it is a registry, is 648 it centralized or distributed, such as the DNS? The remainder of 649 this section summarizes the discussion within the NSRG on these 650 questions. 652 Again, one possibility is that stack names could be represented as 653 Mobile IP home addresses. The benefit of this idea is that one might 654 well derive a large benefit without having to incur any additional 655 protocol engineering, at least initially. By representing stack 656 names in this way the architectural distinction between stack name 657 and location is somewhat muddled. If the goal is to separate 658 location and entities, where an IP address represents location, a 659 Mobile IPv6 answer doesn't get us to the goal. 661 3.2.1 Uniqueness 663 The reason this document exists is that uniqueness is desirable. 664 Uniqueness offers certainty that a name represents exactly one 665 object. A records from the DNS never were intended to have 666 uniqueness. IP addresses, particularly in a V4 environment, no 667 longer have uniqueness. Uniqueness allows people and programs to 668 build operating assumptions about the other end of a communication. 669 TCP was designed with such an assumption. 671 Being uniquely identified also raises security concerns. What if you 672 don't want to be uniquely identified by generators of SPAM or by 673 powerful entities such as governments? Note that we refer to the 674 uniqueness of the object referenced by the identifier. An object 675 itself might have multiple names. 677 3.2.2 Statistical uniqueness versus universal uniqueness 679 The classic way the model ensured uniqueness of names and addresses 680 on the Internet was to have those names and addresses assigned by 681 central authorities through a distributed tree-structured database. 682 The overhead for name assignment may be distributed through 683 delegation of authority. While this mechanism for name assignment 684 guarantees uniqueness to the level of competence of those 685 authorities, such delegation introduces overhead, artificial markets, 686 trademark concerns, and other problems. 688 Some members of the NSRG are concerned that any new registry for 689 stack names would bring unwelcome and burdensome administrative costs 690 to connecting to the Internet, either as a service or a user. One 691 could envision a very large reverse lookup domain that contains all 692 host identities, leaving little room for decentralization. 694 In particular two problems have cropped up with centralized name 695 spaces. The first is that of domain squatting, where people buy a 696 name simply for its usefulness to others. The second problem lies 697 with IP addresses, that are allocated and sold by providers. Those 698 providers may choose to make a "service" out of making addresses 699 available to customers. When designing a new name space, one should 700 introduce no artificial scarcity. 702 One way to avoid a new administrative overhead would be for 703 individuals to be able to generate statistically unique names. 704 However, statistically unique names can easily be mapped TO, but they 705 are less easily mapped FROM. This is because it is difficult to 706 establish trust relationships necessary to make changes to the 707 mapping. For instance, if a central authority controls the name 708 space, there must be some sort of authentication and authorization 709 model in place for the change to be allowed. If such a mechanism is 710 in place, one has to wonder (a) why the names used for that 711 infrastructure are not used and therefore (b) why statistically 712 unique names would be of any advantage. 714 There was a consensus that if we were to introduce a new name space 715 it should not be mnemonic in nature. The DNS exists for that purpose 716 today, and while others have recently identified a need to revisit 717 the DNS, that was not the purpose of this effort. 719 3.2.3 Mapping 721 This brings into question several related concerns with naming: what, 722 if any, mapping mechanisms exist? Should stack names map to IP 723 addresses, to domain names, or for that matter, to anything? Do 724 domain names, X.509 distinguished names, or other names map to stack 725 names? Each is a separate question. A name on its own is of very 726 limited value. The mappings infer how the name will be used. Is a 727 stack name just something that sits in a transport control block on a 728 device? In effect purpose built keys could accomplish that task. 730 3.2.4 Anonymity 732 Related to uniqueness and mapping is anonymity. Is it possible or 733 even desirable to have anonymous names? That is, should my computer 734 be able to establish a communication to your computer, such that you 735 can be assured that you are communicating with the same entity who 736 used a particular name, without actually knowing the underlying 737 binding between the name and the object? 739 3.2.5 Fixed versus variable length names 741 When the nature of the name is decided one must decide whether the 742 name should be of fixed or variable length. Traditionally those 743 fields which are found in every packet tend to be fixed length for 744 performance reasons, as other fields beyond them are easily indexed. 745 The form the name takes will have some relevance to this decision. 746 If the name appears along the lines of an X.509 distinguished name, 747 it must be variable. If the name is otherwise fixed length and 748 supposed to be universally unique, the field must allow for large 749 enough numbers to not require a protocol change anytime soon. 750 Similarly, if the name is statistically unique, the field must be 751 large enough so that the odds of a collision are acceptably low so 752 that the protocol needn't change anytime soon. We leave it to 753 engineers to determine what "anytime soon" and "acceptably low" are. 755 A convenient feature of a variable-length name is that it allows for 756 ease of organizational delegation. If one provides a hierarchical 757 model such as the DNS, one can decentralize authority to get a new 758 name or to change a name. By the same token, such structure requires 759 a root authority from which distribution occurs. So long as the name 760 itself is not a mnemonic, perhaps it is possible to limit problems 761 such as domain squatting. 763 Ultimately, if the name is to be other than statistically unique, 764 there will be some sort of central root service. 766 3.3 At what layer are stack names represented? 768 Where are stack names represented? Are they represented in every 769 packet, or are they represented in only those packets that the 770 underlying use requires? The benefit of not requiring stack names to 771 appear in every packet is some amount of efficiency. However, the 772 benefit of having them in every packet is that they can be used by 773 upper layers such as ESP. In addition, end points would be able to 774 distinguish flows of packets coming from the same host even if the IP 775 address changes, or if the remote stack migrates to another piece of 776 hardware. The PBK approach would alert an end point when one side 777 knows of such a change, but as we have seen, the IP address one side 778 sees, the other side may not, without a mechanism such as MIDCOM or 779 RSIP. HIP and ESP solve this problem by putting an identifier 780 (either the HIT or SPI) in every packet. 782 If a stable Internet layer existed it might be possible to represent 783 stack names as IP addresses. Even if a host moved, a stack name 784 could be represented as a Mobile IP "home" address. The PBK proposal 785 suggests that stack names be passed as necessary as end to end 786 options in IPv6 or simply as options in IPv4. 788 If a stable Internet layer doesn't exist, then stack names must 789 appear above it. If a new mechanism were inserted between the 790 Internet and transport layers, all end points that wish to use the 791 mechanism would need to change. 793 3.3.1 A few words about transport layer mechanisms 795 One may not wish to completely divorce the transport layer from the 796 Internet layer, as currently implemented. The transport layer 797 mechanisms today are largely responsible for congestion control. If 798 one end point moves it is quite possible that the congestion 799 characteristics of the links involve will change as well, and it thus 800 might be desirable for mechanisms such as TCP Slow Start to be 801 invoked. It is also possible that codecs may no longer be 802 appropriate for the new path, based on its new characteristics. In 803 as much as mobile hosts change their locations and bindings with 804 Mobile IP today, this is already an issue. 806 3.4 Stack names and the routing system 808 It would seem a certainty that the routing system would want very 809 little to do with stack names. However, as previously mentioned, 810 when the binding between Internet and transport layers is broken, 811 some care must be taken to not introduce new security problems, such 812 that a connection cannot be hijacked by another host that pretends to 813 be authorized on behalf of an end point. 815 One misguided way to do this would be to enforce that binding in the 816 routing system by monitoring binding changes. In order for the 817 routing system to monitor the binding, it realistically must be done 818 out in the open (i.e., not an encrypted exchange) and the binding 819 must appear at some standard point, such as an option or at a 820 predictable point in the packet (e.g., something akin to layer 3.5). 822 In other words, one would have gone all the way around from 823 attempting to break the binding between transport and Internet layers 824 to re-establishing the binding through the use of some sort of 825 authorization mechanism to bind stack names and Internet addresses. 827 3.5 Is an architectural change needed? 829 The question of what level in the stack to solve the problem 830 eventually raises whether or not we contemplate architectural changes 831 or engineering enhancements. There can be little dispute that the 832 topic is architectural in nature. For one, there are now numerous 833 attempts to solve end point identification problems within the 834 engineering space. We've already mentioned but a few. The real 835 question is whether the existing architecture can cover the space. 836 Here there are two lines of thought. The first is that the use of 837 mobility mechanisms and Mobile IP will cover any perceived need to 838 provide stack names. Assuming that it can be widely and securely 839 deployed, Mobile IP certainly resolves many host mobility concerns. 840 However, it remains to be seen if it can address other problems, such 841 as those introduced by content delivery networks. 843 The other line of thought is that there is an architectural 844 distinction between names, addresses, and routes more explicit since 845 there is otherwise an overloading of operators. Regardless of 846 whatever tactical benefit one might gain, architectural separation 847 should provide value in and of itself over time. The risk of this 848 argument is that we will have introduced complexity without having 849 actually solved any specific problem, initially. 851 To resolve the differences between the two schools of thought 852 requires development of the second school of thought to the point 853 where it can be properly defended, or for that matter, attacked. 855 4. Conclusions or Questions 857 The NSRG was not able to come to unanimity as to whether an 858 architectural change is needed. In order to answer that question, as 859 just noted in the previous section, the notion of a stack name should 860 be further developed. 862 Specific questions that should be answered are the following: 864 1. How would a stack name improve the overall functionality of the 865 Internet? 867 2. What does a stack name look like? 869 3. What is its lifetime? 871 4. What is its lifetime? 873 5. Where does it live in the stack? 875 6. How is it used on the end points 877 7. What administrative infrastructure is needed to support it? 879 8. If we add an additional layer would it make the address list in 880 SCTP unnecessary? 882 9. What additional security benefits would a new naming scheme 883 offer? 885 10. What would the resolution mechanisms be, or what characteristics 886 of a resolution mechanisms would be required? 888 Of the many existing efforts in this area, what efforts could such a 889 name help? For instance, would a stack name provide for a more 890 natural MIDCOM design? 892 This document raises more questions than answers. Further studies 893 will hopefully propose valid answers. 895 5. Further Studies 897 Various efforts continue independently. One outgrowth is the 898 possibility of a HIP working group within the IETF. Although this 899 work might occur within the IETF, it should be noted that there is a 900 risk to attempting to standardize something about which we yet have 901 the full benefit of having explored in research. 903 Work on relieving stress between routing and addressing also 904 continues within IETF working groups. 906 A separate effort proceeds elsewhere in the research community to 907 address what the Internet should look like ten years from now. That 908 work may further conclude that stack names will play a considerably 909 larger role. 911 It is possible that work will continue within the IRTF. However, 912 that work should be conducted by smaller teams until mature proposals 913 can be debated. Questions of "whether additional name spaces should 914 be introduced" can only be answered in such a manner. 916 6. Acknowledgments 918 This document is a description of a review done by the Name Space 919 Research Group of the Internet Research Task Force. The members of 920 that group include: J. Noel Chiappa, Scott Bradner, Henning 921 Schulzrinne, Brian Carpenter, Rob Austien, Karen Sollins, John 922 Wroclawski, Steve Bellovin, Steve Crocker, Keith Moore, Steve 923 Deering, Matt Holdrege, Randy Stewart, Leslie Daigle, John Ioannidis, 924 John Day, Thomas Narten, Bob Moskowitz, Ran Atkinson, Gabriel 925 Montenegro, and Lixia Xiang. 927 Particular thanks go to Noel Chiappa whose notions and continuing 928 efforts on end points kicked off the stack name discussion. The 929 definition of an endpoint is largely taken from Noel's unpublished 930 draft. Thanks also to Ran Atkinson and Bob Moskowitz whose comments 931 can be found (in some cases verbatim) in this document. 933 The idea of GSE or 8+8 was originally developed by Mike O'Dell. The 934 documents in which GSE is described are not published as RFCs. 936 References 938 [1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 939 1661, July 1994. 941 [2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 942 March 1997. 944 [3] Srisuresh, P. and K. Egevang, "Traditional IP Network Address 945 Translator (Traditional NAT)", RFC 3022, January 2001. 947 [4] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., 948 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 949 HTTP/1.1", RFC 2616, June 1999. 951 [5] Shoch, J., "Inter-Network Naming, Addressing and Routing", 952 Proceedings of IEEE Compcon, pp72-97, Fall 1978. 954 [6] Saltzer, J., "On The Naming and Binding of Network 955 Destinations", September 1992. 957 [7] Saltzer, J., Reed, D. and D. Clark, "End-To-End Arguments in 958 System Design", ACM Transactions on Computer Systems Vol. 2, 959 No. 4, November 1984. 961 [8] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S. 962 Lehtinen, "SSH Protocol Architecture", draft-ietf-secsh- 963 architecture-13.txt (work in progress), September 2002. 965 [9] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload 966 (ESP)", RFC 2406, November 1998. 968 [10] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 969 RFC 2409, November 1998. 971 [11] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and 972 P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 973 1999. 975 [12] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP 976 Message Format", RFC 2440, November 1998. 978 [13] Carpenter, B., "Internet Transparency", RFC 2775, February 979 2000. 981 [14] Hain, T., "Architectural Implications of NAT", RFC 2993, 982 November 2000. 984 [15] Holdrege, M. and P. Srisuresh, "Protocol Complications with the 985 IP Network Address Translator", RFC 3027, January 2001. 987 [16] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", 988 RFC 1771, March 1995. 990 [17] Perkins, C., "IP Mobility Support", RFC 2002, October 1996. 992 [18] Johnson, P. and C. Perkins, "", draft-ietf-mobileip-ipv6-18.txt 993 (work in progress), June 2002. 995 [19] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 996 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, 997 "Stream Control Transmission Protocol", RFC 2960, October 2000. 999 [20] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., Rytina, I., 1000 Belinchon, M. and P. Conrad, "Stream Control Transmission 1001 Protocol (SCTP) Dynamic Address Reconfiguration", draft-ietf- 1002 tsvwg-addip-sctp-07.txt (work in progress), February 2003. 1004 [21] Moskowitz, B., "Host Identity Payload Architecture", draft- 1005 moskowitz-hip-arch-02.txt (work in progress), February 2001. 1007 [22] Bradner, S., Mankin, A. and J. Schiller, "A Framework for 1008 Purpose Built Keys (PBK)", draft-bradner-pbk-frame-04.txt (work 1009 in progress), January 2003. 1011 [23] Borella, M., Lo, J., Grabelsky, D. and G. Montenegro, "Realm 1012 Specific IP: Framework", RFC 3102, October 2001. 1014 [24] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A. 1015 Rayhan, "Middlebox communication architecture and framework", 1016 RFC 3303, August 2002. 1018 [25] O'Dell, M., "GSE - an alternate addressing architecture for 1019 IPv6", draft-ietf-ipngwg-gseaddr-00.txt (work in progress), 1020 1997. 1022 [26] Handley, M., Thaler, D. and R. Kermode, "Multicast-Scope Zone 1023 Announcement Protocol (MZAP)", RFC 2776, February 2000. 1025 Authors' Addresses 1027 Eliot Lear 1028 Cisco Systems, Inc. 1029 170 West Tasman Dr. 1030 San Jose, CA 95134 1032 Phone: +1 408 527 4020 1033 EMail: lear@cisco.com 1034 Ralph Droms 1035 Cisco Systems, Inc. 1036 300 Apollo Drive 1037 Westford, MA 01824 1039 Phone: +1 978 497 4733 1040 EMail: rdroms@cisco.com 1042 Full Copyright Statement 1044 Copyright (C) The Internet Society (2003). All Rights Reserved. 1046 This document and translations of it may be copied and furnished to 1047 others, and derivative works that comment on or otherwise explain it 1048 or assist in its implementation may be prepared, copied, published 1049 and distributed, in whole or in part, without restriction of any 1050 kind, provided that the above copyright notice and this paragraph are 1051 included on all such copies and derivative works. However, this 1052 document itself may not be modified in any way, such as by removing 1053 the copyright notice or references to the Internet Society or other 1054 Internet organizations, except as needed for the purpose of 1055 developing Internet standards in which case the procedures for 1056 copyrights defined in the Internet Standards process must be 1057 followed, or as required to translate it into languages other than 1058 English. 1060 The limited permissions granted above are perpetual and will not be 1061 revoked by the Internet Society or its successors or assigns. 1063 This document and the information contained herein is provided on an 1064 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1065 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1066 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1067 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1068 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1070 Acknowledgement 1072 Funding for the RFC Editor function is currently provided by the 1073 Internet Society.