idnits 2.17.1 draft-irtf-nsrg-report-04.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 seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == It seems as if not all pages are separated by form feeds - found 20 form feeds but 22 pages 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 4 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([XXX5], [XXX7]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'XXX 5' is mentioned on line 35, but not defined == Missing Reference: 'XXX 7' is mentioned on line 39, but not defined == Missing Reference: 'PPP' is mentioned on line 61, but not defined == Missing Reference: 'HTTP11' is mentioned on line 70, but not defined == Missing Reference: 'XXX 13' is mentioned on line 80, but not defined == Missing Reference: 'PGP' is mentioned on line 140, but not defined == Missing Reference: 'XXX 18' is mentioned on line 178, but not defined == Missing Reference: 'MATT' is mentioned on line 178, but not defined == Missing Reference: 'XXX 10' is mentioned on line 197, but not defined == Missing Reference: 'XXX 21' is mentioned on line 201, but not defined == Missing Reference: 'XXX 22' is mentioned on line 215, but not defined == Missing Reference: 'XXX 23' is mentioned on line 242, but not defined == Unused Reference: 'TRANSP' is defined on line 968, but no explicit reference was found in the text == Unused Reference: 'INAT' is defined on line 971, but no explicit reference was found in the text == Unused Reference: 'NATCOMP' is defined on line 974, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-ietf-secsh-architecture-09 ** Obsolete normative reference: RFC 2406 (ref. 'ESP') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2409 (ref. 'IKE') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 1771 (ref. 'BGP4') (Obsoleted by RFC 4271) ** Obsolete normative reference: RFC 2002 (ref. 'MobileIP') (Obsoleted by RFC 3220) == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-14 == Outdated reference: A later version (-22) exists of draft-ietf-tsvwg-addip-sctp-03 == Outdated reference: A later version (-06) exists of draft-moskowitz-hip-arch-02 == Outdated reference: A later version (-06) exists of draft-bradner-pbk-frame-00 ** Obsolete normative reference: RFC 2821 (ref. 'ESMTP') (Obsoleted by RFC 5321) Summary: 13 errors (**), 0 flaws (~~), 22 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IRTF E. Lear 2 Internet Draft Name Space Research Group 3 Category: Informational 4 May 22 2002 5 Expires: November 22, 2002 7 draft-irtf-nsrg-report-04.txt 8 What's In A Name: 9 Thoughts from the NSRG 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet- Drafts 24 as reference material or to cite them other than as "work in 25 progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 Over the last few years, the character of Internet connectivity has [XXX 5] 36 changed dramatically. A research group in the IRTF has been 37 chartered to review these changes, and make recommendations on 38 whether or not remediation within the protocol stack is necessary. 39 This document discusses the outcome of some of those discussions. [XXX 7] 40 The key question we will consider is this: does the stack need an 41 additional level of naming above layer 3 but below the application 42 layer? While we do not conclude an answer at this point, we flush 43 out the question a bit more, talk about existing work, and discuss 44 additional questions, such as the structure and use of such names. 46 Although this document has a single author, the ideas 47 described are those of many people both within and outside of the 48 IRTF (see the References and Acknowledgements sections for more 49 details). However, others within the NSRG hold views that differ 50 from those presented in this document. [XXX Ran/Keith/Brian] 52 1 Introduction 53 The Internet has gone through several metamorphoses, and how one 54 gets around on the Internet has changed over time. Even though the 55 IP packet has remained largely unchanged, the routing of that 56 packet has changed considerably. For many years, addressing of end 57 points was a somewhat trivial matter. One could name end points, 58 the computers intended to send and receive communications, either 59 by IP address or by the mnemonic pointing to that address- a domain 60 name. The difference between name and address seemed unimportant. 61 However, with the advent of PPP[PPP] and DHCP[DHCP], private 62 network address space and network address translators (NAT), the 63 overall addressing model on the Internet has become one of 64 transients. One borrows an address from place to place, or from 65 time to time, when one needs to assert a location in the network 66 topology.[BCP5,NAT] In addition, a single IP address can now be 67 shared by multiple servers to represent a single logical end point. 68 The converse is also true- a single server can represent multiple 69 logical end points, and not even have to use multiple 70 addresses.[HTTP11] 72 We are not the first to point out the differences between names, 73 addresses, and routes. That was done as early as 1978 in 74 IEN-119[Shoch]. The argument has been sharpened and carried forth 75 in a number of discussions, including [Saltzer92] and [Saltzer84]. 76 However, we are now faced with some logical outcomes earlier 77 authors may well have predicted. In short, today the function of 78 IP addresses is overloaded to serve the function of a location in 79 the network, an interface, a host name, and a portion of that which 80 identifies a TCP connection.[XXX 13] 82 Today we ask the question: given the changing nature of end points 83 on the network, is something more than IP addresses and DNS needed 84 to resolve end points? What functionality would that something 85 bring to the table? 87 1.1 How Endpoints Communicate Today 89 While attempting not to burden the reader with a long review of how 90 IP works, we must consider the process of communication between end 91 points on the Internet in order to address the question we pose. 93 We consider three forms of communication: 95 Unicast Connection Oriented 97 A good example is classic TCP. In order for two ends to establish 98 a connection, one end resolves the address of the other, usually by 99 DNS lookup, and then the two exchange SYNs and ACKs, thereby 100 exchanging state.[TCP] A TCP connection may last for a brief 101 fraction of a second, or it may last for days. 103 We also consider connection oriented UDP services, such as SIP or 104 H.323. Again, state is exchanged, this time in an application 105 specific way. 107 Multicast 109 Unicast communications are by-and-large connection-oriented, 110 meaning that there is an explicit beginning, middle, and end of a 111 two way communication, involving multiple exchanges. Because 112 multicast is a one-to-many method of communication it is for the 113 most part connectionless, albeit not necessarily stateless. When a 114 host is to receive a multicast it declares its interest in the 115 communication via IGMP [MCAST] and the routing system then arranges 116 for that host to receive messages to a particular address. 117 Although most of our discussions will focus on unicast, we are 118 mindful of the impact any changes made may have on multicast. 120 Anycast 122 Finally, a form of communication that has of late become useful: 123 anycast. An anycast request is served the "nearest" computer 124 participating in that anycast service, for some value of "near". 125 Examples of anycast mechanisms include use of multiple DNS servers 126 answering on a single IP address. Modern anycast service requires 127 that either the requests consist of a single packet exchange or 128 that those endpoints sharing the name or address closely coordinate 129 so as not to break routing or other semantics. 131 1.1.1 Security Considerations 133 In this document we address the notion of identity, which is a key 134 component of security, and key to privacy. 136 Communications today are secured through one of several means. For 137 strongest protocol security, the communication is encrypted and the 138 ends are identified with verifiable public keys. Several systems 139 are available today to do this, including SSH[SSH], the IPSEC 140 mechanisms of ESP[ESP] and IKE[IKE], TLS[TLS], and PGP[PGP]. 142 The absence of a name space that uniquely named a host created 143 problems in the design of ESP/AH (so-called "IPsec"). ESP/AH 144 really want to bind security associations to a hostname distinct 145 from either DNS or IP address, because both the DNS entry and the 146 IP address can change when in fact the security association could 147 remain valid. This could occur in the case where a PC moves from 148 one point in a topology to another. In the absence of a persistent 149 name in the Internet Architecture, IP addresses are used for the 150 binding of Security Associations. This is an architectural 151 shortcoming, not a feature. Among other advantages, a real unique 152 name space would mean that ESP/AH did not care about the 153 presence/absence of NAT devices. 155 At a different level, there is an expectation that the routing 156 system guides a packet toward the destination end point, as 157 indicated in the IP destination address. Until a few years ago, 158 this would not have been an unreasonable assumption. Today 159 there are exceptions, particularly transparent web proxies and 160 firewalls. 162 With some of the currently contemplated changes, the risk of 163 hijacking a connection changes from that of a continuous intercept 164 to the potential of a redirection through some form of spoofed 165 rebinding. 167 1.2 How Things Have Changed 169 As mentioned earlier, the nature of communications has changed. 170 When one transfers a web page to one's system it is quite likely 171 that the remote address and TCP port, as it appears to the web 172 server, will not bear much relation to what the client browsing 173 host stated. Furthermore, without great difficulty the client 174 cannot determine the address it is in fact using when speaking to a 175 server. And indeed it itself cannot become a server because 176 another end has no way to address it. This is the essence of NAT. 177 The perils of NAT have been well documented by others. [TRANSP, 178 INAT,NATCOMP][XXX 18,MATT] 180 In addition, computers are far more mobile than they were just a 181 few years ago. When one moves from one location to another, one's 182 address changes to reflect one's change in topology. Because TCP 183 bases its transport connection state on IP addresses, any 184 connections to the old address are lost (but see below). 186 One of the largest changes in the character of Internet usage 187 involves the resources we access and how we access them. Whereas 188 in the past we intended to access a particular host with a 189 particular IP address, today we are likely more interested in 190 accessing a service, such as a news service, or a banking service, 191 and we are less interested in the host upon which the service sits. 192 An industry has built up around the notion these so-called content 193 delivery or overlay networks. The IP address of the web server 194 matters only in as much as it will serve the necessary web pages. 195 In particular with secure services, what matters most to the user 196 is that a particular trusted company has verifiably provided the 197 service. [XXX 10] 199 This brings us to our question: would a new name space enable new 200 functionality or return to us old capabilities in the face of NAT, 201 DHCP, PPP, and other forms of mobility? [XXX 21] 203 1.3 Stresses 205 The most important change the Internet has undergone is spectacular 206 growth. The result of the growth has been shortages in address 207 space and routing resources. 209 As the growth of the Internet exploded so did address space 210 utilization. A combination of measures, including the introduction 211 of private address space, NATs, and a tightening of policy by 212 addressing registries reduced the risk of the Internet running out 213 of allocatable addresses until the 2010 time frame. As a result, 214 however, the unique identification of an end point and the 215 universal ability to reach it was lost. [XXX 22] 217 At the same time, Internet routing tables exploded in size. To 218 reduce routing tables routes, classless routing [BGP4] was 219 developed and deployed to aggregate routes on bit boundaries, 220 rather than on old classful boundaries. Next, the IANA 221 discontinued its policy of allocating addresses directly to end 222 users and instead allocated them hierarchically to providers, 223 requiring providers to show sufficient allocation and utilization 224 to justify further assignments. This retarded for a time the 225 explosion in routing, but did not eliminate growth. While work 226 continues in this area, it is important to understand that as of 227 this writing the aggregation of routes through CIDR is the most 228 efficient way to route Internet traffic, given its current design 229 goals. 231 There is a natural conflict between the above two policies. If one 232 allocates addresses in small chunks, more routing entries will 233 result. Periodically providers will renumber to get larger blocks, 234 at the inconvenience of all of their customers. 236 In summary, the Internet has exploded in size, NATs are now widely 237 present, and the use of mechanisms such as PPP and DHCP are widely 238 deployed. In addition, services are now as much or more of 239 interest than are individual hosts. Given all of these changes, is 240 it possible to add a new name space that will make connectivity 241 more stable and allow us to establish some new operating 242 assumptions, such as the ones that these complications broke? [XXX 23] 244 2 Related Work 246 There exists a large body of work on name spaces and their 247 bindings. The work we discuss below primarily relates to the 248 binding of stacks to IP addresses, with an eye toward mobility or 249 transience. The first mechanism is Mobile-IP. 251 2.1 Mobile-IP 253 Mobile-IP addresses the problem of having a stable end point 254 identifier on mobile hosts. As hosts move through the topology 255 they update a home agent which acts as an ever-present anchor. 256 Mobile-IP provides a different solution depending on whether one is 257 using IPv4 or IPv6.[MobileIP,MobileIPv6]. In IPv4, Mobile-IP is a 258 tunneling mechanism. In IPv6, mobile hosts make use of end host 259 options. An end system uses its home address to create transport 260 connections and communicate with the other end, one or more 261 correspondent nodes. IPV4 mobile hosts are tunneled through a home 262 agent and optionally a foreign agent, so that the end system's 263 address space is found in the routing system without additional 264 global routing overhead. In IPv4 the home agent is separate from 265 the other end of a transport connection, and packets take a 266 triangular route. In IPv6, support of mobility is required, and 267 the likely non-mobile host, the correspondent node, is aware that 268 the other end is mobile. Therefore, once the mobile host and 269 remote host establish communications they can "short circuit" to 270 remove the home agent. This is key because while the foreign agent 271 is likely to be near the mobile host, the home agent is unlikely to 272 be near anybody. 274 _______ ________ 275 | |Care-of Address | | foreign agent optionally 276 |Mobile |--------------------| Remote | forwards packets to mobile 277 | Host | | Agent | host 278 |_______| |________| 279 ::Home Address | 280 :: | home agent encapsulates and passes 281 :: | packets to the remote agent or 282 :: ___|____ directly to the mobile node 283 :: | | 284 :: | Home | 285 :: | Agent |\ remote host sends packets 286 :: |________| \ to home agent 287 :: \ 288 \\ \ 289 \\ \ 290 \\ \_____________ 291 \\ tunneled transport connection | | 292 =====================================|Correspondent| 293 | Node | 294 |_____________| 296 Figure 1: Mobile-IPv4 298 In effect, Mobile-IP turns the mobile node's IP address into a host 299 identifier, where the "care of" address is the host's current 300 location. The way Mobile-IP succeeds is that it uses tunneling 301 within the topology to represent an address at one location when it 302 is in fact at another. However, a route to the mobile node's 303 address itself must be available within the topology at all times. 304 In an IPv4 world this would be untenable because of constraints on 305 both the addressing system. With IPv6, the addressing pressures 306 are off, and so each host can have a unique end address. However, 307 problems remain with the routing system. In addition, there is a 308 class of devices for which there may be no "home", such as devices 309 in airplanes, mobile homes, or constant travelers. Additionally, 310 there is a desire within some of the mobility community to have 311 "micromobility" mechanisms that enable faster movement than 312 envisioned by Mobile-IP. The Routing Research Group (rrg) is 313 currently investigating this area. 315 Most importantly, mobile devices can't withstand the loss of the 316 home agent, even if they are still online somewhere. With the home 317 agent offline, no incoming connections can get to them, and 318 long-lived communications cannot be re-established. If the 319 rendezvous point location/identity wasn't overloaded on the home 320 address (which is, of necessity, a place in the network, and might 321 go offline, not a distributed database), it might be possible to 322 work around that for those entities that cared about that failure 323 mode. 325 2.2 Stream Control Transport Protocol (SCTP) 327 Many of the problems raised have to do with the use of layer 3 328 information at higher layers, such as the pseudo-header in TCP. 329 A protocol that is considered an alternative to TCP has certain 330 potential benefits in the area of names and addresses. TCP 331 transport connection end points are named by IP addresses, and 332 there are precisely two end point addresses, one for each end. 333 SCTP allows for multiple transport addresses per end, nominally for 334 redundancy of applications that require high availability. 335 However, it is possible to move a transport connection as a host 336 moves from one location to another, or as its address changes due 337 to renumbering (for whatever purpose). Work has progressed within 338 the IETF to introduce a new capability to SCTP, that allows 339 connection end points to change the set of IP addresses used for a 340 transport connection.[ADDIP] 342 There are two limitations to this idea. For one, it only affects 343 those hosts that use SCTP, and so long as there exist other 344 transports that are considered more appropriate for specific tasks, 345 solving an Internet naming problem within SCTP will be susceptible 346 to the charge that the solution is not sufficiently general. 348 The second problem is that as contemplated in the draft the risk of 349 an attacker hijacking a connection is elevated. This same 350 problem exists within MobileIP, and may similarly be mitigated by 351 purpose built keys (see below). 353 2.3 Host Identity Payload 355 Host Identity Payload (HIP) is a new approach to the problem of 356 naming end points. It inserts an additional "name" between layer 3 357 and layer 4, thus becoming layer 3.5.[HIP-ARCH] The goal is to 358 decouple the transport layer from the Internet layer, so that 359 changes in the Internet layer do not impact the transport, and the 360 benefit is shared by all mechanisms atop transports that use HIP. 362 ______________________________________ 363 | | 364 | Application | 365 |______________________________________| 366 | | 367 | Transport | 368 |______________________________________| The Host Stack 369 | | 370 | HIP or ESP w/ HI as SPI | 371 |______________________________________| 372 | | 373 | IP Header | 374 |______________________________________| 376 Figure 2: Host Identity 378 HIP itself relies on a cryptographic host identity (HI) that is 379 represented in a Host Identity Tag (HIT) of various forms. One is 380 a hash of the public key host identity, another is an 381 administratively assigned value coupled with a smaller hash of the 382 public key host identity. Host identities can be public or 383 anonymous, the difference being whether or not they are published 384 in a directory. 386 Whereas today one binds the transport to an IP address, HIP 387 proposes that the transport binds to a host identity tag (HIT). 388 DNS is used to determine the HI and HIT, or to validate via reverse 389 lookup an HIT. Further, DNS continues to be used to get an 390 Internet address. 392 Whether one should want to decouple the transport layer from the 393 Internet layer is a controversial question. After all, that 394 coupling has for many years provided the barest bones of the 395 security of knowing that the packets that make up the transport 396 connection are being guided through the network by routing 397 tables in Internet routers that are owned by people and 398 organizations whose intent is to get one's packets from source to 399 destination. If we divorce the transport from the Internet layer, 400 we introduce another way for an attacker to potentially hijack 401 connections. HIP attempts to address this through the use of 402 public key verification. 404 Additionally, HIP raises an issue regarding other uses for 405 aggregation of IP addresses. Today, they are not only aggregated 406 for purposes of reduced routing, but also for reduced 407 administration. A typical access list used on the Internet will 408 have some sort of a mask, indicating that a group of hosts from the 409 same subnet may access some resource. Because the value of a HIT 410 is a hash in part, only the administratively assigned value can be 411 aggregated, introducing an allocation limitation and authorization 412 concerns. 414 On the other hand, there is the old computer science saying, any 415 problem can be fixed by an additional layer of indirection 416 (arguably what we're talking about). It should be possible to 417 administratively aggregate on groupings that are made at higher 418 layers. 420 An alternative approach would be to aggregate based on DNS names, 421 rather than HI values. See [HIP-ARCH] for more details. 423 A key concern with HIP is whether or not it will work in a mobile 424 world. If the DNS is involved, or if any directory is involved, 425 will caching semantics eventually limit scalability, or are there 426 mobility mechanisms that can be employed make use of directories 427 feasible? 429 2.4 Purpose Built Keys 431 Purpose built keys (PBKs) are temporary end point identifiers that 432 are used to validate a given endpoint during a communication. PBKs 433 are similar to HIP.[PBK] Rather than attempting to build an 434 infrastructure to validate the end points, however, PBK's sole 435 purpose is to ensure that two hosts that originate a communication 436 may continue that communication with the knowledge that when 437 finished each end point will be the same end point it was at the 438 start. Thus, even if one's address changes for whatever reason it 439 is still possible to validate oneself to the other side of the 440 communication. 442 PBKs take the form of ad hoc public / private key pairs. When a 443 node wishes to validate itself to another node it signs a piece of 444 data with its private key that is validated by the other end with 445 the public key. The public key itself becomes an end point 446 identifier. 448 PBKs make no claim as to who the parties actually are. They make 449 no use of public key infrastructures. PBKs are themselves 450 ephemeral for the duration of a communication. 452 2.5 RSIP and MIDCOM 454 Two related efforts have been made to stitch together name spaces 455 that conflict. One is RSIP, which allows for the temporary 456 allocation of address space in one "realm" by a host in another 457 realm, not unlike the way an address is gotten via DHCP. The 458 benefit of RSIP is that it allows the end point to know what 459 address it is assigned, so that it may pass such information along 460 in the data path, if necessary. The problem with RSIP is that host 461 routing decisions within the stack are very complex. The host 462 makes decisions based on destination address (a process that a fair 463 amount of configuration, and lacked certainty as it was based on 464 potentially non-unique IP addresses). Because RSIP borrows public 465 addresses it must relinquish them as quickly as possible, or the 466 point of NAT is negated. In order to make better use of the scarce 467 public resource, RSIP implementations would need to route not just 468 on destination address, but on application information as well. 469 For example, internal hosts would probably not need external 470 addresses merely to browse the web. 472 MIDCOM is a similar approach. However, rather than tunneling 473 traffic, an agreement between an end point and its agent and a 474 "middle box" such as a NAT or a firewall is made so that the end 475 point understands what transformation will be made by the middle 476 box. Where a NAT or a web cache translates from one name 477 space to another, MIDCOM enables end points to identify that 478 translation. 480 MIDCOM is contemplated for use by specific applications, and thus 481 avoids the stack problems associated with RSIP. However, neither 482 MIDCOM nor RSIP resolve how to discover such middle boxes. Nor do 483 they provide a unique way for a host behind a NAT to identify 484 itself in an enduring way. Finally, they both run into problems 485 when multiple NATs are introduced in a path. 487 2.6 GSE or "8+8" 489 One proposal attempts to ease the conflict between the desire of 490 end systems to have a fixed name for themselves, and the needs of 491 the routing systems for address assignments which minimize the 492 overhead of routing calculations. The clash between these two 493 desires produces either the inconvenience (for the end systems) of 494 renumbering, or routing inefficiency and potentially poor address 495 space utilization as well; the latter caused by the difficulty of 496 renumbering to allows effective use of address space. 498 Known as 8+8 or GSE, it would have split the IPv6 address into two 499 parts: a routing system portion that would be assigned and managed 500 by service providers that would change based on routing system 501 requirements, and a locally managed portion that would be assigned 502 and managed by terminal autonomous systems.[GSE] While each portion 503 is globally unique, there are in effect two addresses, one to get a 504 packet to an autonomous system and another to get to the host. 505 Further, end hosts might not be aware, at least initially, of their 506 routing portions. It was envisioned that the renumbering of 507 the routing portion could be done as a matter of signaling, with 508 little administrative involvement from the end point. Another goal 509 of GSE was to eliminate additional routing overhead caused by 510 multihomed end systems, whose information must today be carried 511 throughout the routing system. By allowing end enterprises to have 512 multiple global parts for purposes of multihoming, the terminal 513 ASes would become what are today's last-hop ISPs. There are a 514 number of challenges that GSE would have to overcome. For one, how 515 does one glue together the provider portion of an address with the 516 more local part, and how would one accomplish the task securely? 517 Would doing so eliminate the need or interest in adding other 518 additional name spaces? 520 2.7 Universal Resource Names 522 Universal resource names (URNs) do not provide us a mechanism to 523 resolve our naming concerns.[URN] Rather, they may provide us the 524 form of the name to use, and perhaps a framework for resolution. 525 For instance, an HI may conceivably be represented as a URN. URNs 526 further the notion of defining a binding and boundaries between the 527 name of an object and its location. 529 3. Discussion: Hosts and Stacks 531 When one's computer moves from one location to another, or when a 532 host receives a new address for whatever reason, the computer 533 itself has largely remained the same, as has the person using it. 534 The identity of that computer has not changed. That entity may 535 well be in communication other computers and have access rights to 536 network resources. Indeed multiple entities may be represented by 537 a single computer. 539 Until recently it was generally assumed that a host identified 540 itself by an IP address or a group of IP addresses. With the 541 exception of such mechanisms as MX records [ESMTP], one connected 542 to an IP address, assuming there to be an 1:1 relationship between 543 IP address and host. This operating assumption no longer holds, 544 for reasons previously discussed. 546 Today, a host may represent multiple entities. This happens when a 547 service provider hosts many web sites on one server. Similarly, a 548 single entity may be represented by multiple hosts. Replicated web 549 servers are just such an example. We refer to these entities as 550 stacks, instantiations of the TCP/IP model, be they across one or 551 many hosts. We define a stack or end point as one participant or 552 the process on one side of an end-to-end communication. That 553 participant may move, and may be represented by multiple hosts. 555 When two devices represent a single end point they must share state 556 in order to keep the other end from becoming confused (to say the 557 very least). When doing so, such stacks may indeed consist of 558 multiple processes on each end. One view is that such processes 559 can theoretically be named independently of the Internet layer, 560 allowing for sessions to migrate at the behest of applications. 561 However, it is not possible to standardize migration independent of 562 applications, who retain state in all manner of places, from 563 configuration files to memory. Additional names of such processes 564 serve only to identify those who are authorized somehow to 565 represent the end point, and do not themselves alleviate effort 566 required to ensure application consistency. 568 Such an addition may be useful enough, however, to identify mobile 569 nodes, devices behind NATs, and participants of a content delivery 570 or overlay network. 572 We use the word "sessions" above, a mechanism that the current IP 573 stack does not formally provide. If we were to have a session 574 layer in the classic sense it might sit above the transport layer, 575 and a session could consist of more than a single transport 576 connection. If we view the session at below the transport layer, 577 then transport connections can be bound to an identifier of some 578 form other than that of the IP address, and transport connections 579 could persist across IP address changes. It is unlikely, however, 580 that anything that the transport layer binds to would entirely 581 obviate the need for sessions above the transport layer. 583 Each instance of a stack has a name, a "stack name". At an 584 architectural level the Name Space Research Group debated the value 585 of such names, and their associated costs. We see forms of this 586 name used in numerous places today. As previously mentioned, SSH 587 uses public/private key pairs to identify end points. An HTTP 588 cookie anonymously identifies one end of a communication, in such a 589 manner that both the transport connection and the IP address of the 590 other end point may change many times. 592 We now are left with several questions as to the nature of stack 593 names. 595 3.1. What do stack names look like? 597 Names may be structured or unstructured. If they are structured, 598 what encoding do they use, and what is their scope? Is the length 599 of such a name fixed or variable? Are stack names unique across 600 the Internet? If so, are they guaranteed unique through some sort 601 of a registry or are they statistically unique? If it is a 602 registry, is it centralized or distributed, such as DNS? 604 There is no universal view on many of these questions. For one 605 thing, many are concerned that any new registry would bring 606 unwelcome and burdensome administrative costs to connecting to the 607 Internet, either as a service or a user. One could envision a very 608 large reverse lookup domain that contains all HIs, leaving little 609 room for decentralization. 611 In particular we have seen two problems crop up with centralized 612 name spaces. The first problem is that of domain squatting, where 613 people buy a name simply for its usefulness to others. The second 614 problem lies with IP addresses, which are allocated and sold by 615 providers. Those providers may choose to make a "service" out of 616 making addresses available to customers. When designing a new name 617 space, one should introduce no artificial scarcity. 619 As we have seen, one possibility is that stack names could be 620 represented as MOBILE-IP home addresses. The benefit of this idea 621 is that one might well derive a large benefit without having to 622 incur any additional protocol engineering, at least initially. By 623 representing stack names in this way the architectural distinction 624 between stack name and location is somewhat muddled. A difficulty 625 worthy of further debate is whether such incremental approaches 626 actually help us in the long run. Still, the larger the leap, the 627 less the likelihood of deployment success. 629 3.1.1 Uniqueness 631 This document would not exist were uniqueness not desirable, since 632 we could live on in with the current state of affairs (and we may 633 yet). Uniqueness offers certainty that a name represents exactly 634 one object. DNS A records never were intended to have uniqueness. 635 and as we've discussed, IP addresses, particularly in a V4 636 environment, no longer have uniqueness. Uniqueness allows for 637 people and programs to build operating assumptions the other end of 638 a communication. TCP was designed with such an assumption. Being 639 uniquely identified also raises security concerns. What if you 640 don't want to be uniquely identified by generators of SPAM or by 641 powerful entities such as governments? Note that we refer to the 642 uniqueness of the object referenced by the name. An object itself 643 might have multiple names. 645 3.1.2 Mapping 647 This brings into question several related concerns with naming: 648 what, if any, mapping mechanisms exist? Should stack names map to 649 IP addresses, to domain names, or for that matter, to anything? 650 Do domain names, X.509 distinguished names, or other names map to 651 stack names? Each is a separate question. A name on its own is of 652 very limited value. The mappings go to how the name will be used. 653 Is a stack name just something that sits in a transport control 654 block on a device? In effect purpose built keys could accomplish 655 that task. 657 3.1.3 Anonymity 659 Related to uniqueness and mapping is anonymity. Is it possible or 660 even desirable to have anonymous names? That is, should my 661 computer be able to establish a communication to your computer, 662 such that you can be assured that you are communicating with the 663 same entity who used a particular name, without actually knowing 664 the underlying binding between the name and the object? 666 3.1.4 Statistical Uniqueness versus Universal Uniqueness 668 The classic way we have ensured uniqueness of names and addresses 669 on the Internet has been to have those names and addresses assigned 670 through a distributed tree-structured database by central 671 authorities. While this guarantees uniqueness to the level of 672 competence of those authorities, such delegation introduces 673 overhead, artificial markets, trademark concerns, and other 674 problems. One way to avoid a new administrative overhead would be 675 for individuals to be able to generate statistically unique names. 676 Statistically unique names can easily be mapped TO, but they are 677 less easily mapped FROM. This is because it is difficult to 678 establish trust relationships necessary to make changes to the 679 mapping. For instance, if a central authority controls the name 680 space, there must be some sort of authentication and authorization 681 model in place for the change to be allowed. If such a mechanism 682 is in place, one has to wonder (a) why the names used for that 683 infrastructure are not used and therefore (b) why statistically 684 unique names would be of any advantage. 686 There was a consensus that if we were to introduce a new name space 687 it should not be mnemonic in nature. DNS exists for that purpose 688 today, and while others have recently identified a need to revisit 689 DNS, that was not the purpose of this effort. 691 3.1.5 Fixed versus variable length names 693 When the nature of the name is decided one must decide whether the 694 name should be of fixed length or whether it is variable length. 695 Traditionally those fields which are found in every packet tend to 696 be fixed length for performance reasons, as other fields beyond 697 them are easily indexed. The form the name takes will have some 698 relevance on this decision. If the name appears along the lines of 699 an X.509 distinguished name, it must be variable. If the name is 700 otherwise fixed length and supposed to be universally unique, the 701 field must allow for large enough numbers to not require a protocol 702 change anytime soon. Similarly, if the name is statistically 703 unique, the field must be large enough so that the odds of a 704 collision are acceptably low so that the protocol needn't change 705 anytime soon. We leave it to engineers to determine what "anytime 706 soon" and "acceptably low" are. 708 A convenient feature of a variable-length name is that it allows 709 for ease of organizational delegation. If one provides a 710 hierarchical model such as DNS, one can decentralize authority to 711 get a new name or to change a name. By the same token, such 712 structure requires a root authority from which distribution 713 occurs. So long as the name itself is not a pneumonic, perhaps it 714 is possible to limit problems such as domain squatting. 716 Ultimately, if the name is to be other than statistically unique, 717 there will be some sort of central root service. 719 3.2 At what layer are stack names represented? 721 Where are stack names represented? Are they represented in every 722 packet, or are they represented in only those packets that the 723 underlying use requires? The benefit of not requiring stack names 724 to appear in every packet is some amount of efficiency. However, 725 the benefit of having them in every packet is that they can be used 726 by upper layers such as ESP. In addition, end points would be able 727 to distinguish flows of packets coming from the same host even if 728 the IP address changes, or if the remote stack migrates to another 729 piece of hardware. The PBK approach would alert an end point when 730 one side knows of such a change, but as we have seen, the IP 731 address one side sees, the other side may not, without a mechanism 732 such as MIDCOM or RSIP. HIP and ESP solve this problem by putting 733 an identifier (either the HIT or SPI) in every packet. 735 ______________________________ 736 | ______ ______ | 737 | /_____ /| /_____ /| | 738 | | APP |f| | APP |b| | 739 | |------|o| |------|a| | 740 | |TRANS |o| |TRANS |r| | 741 | | PORT |.| | PORT |.| | 742 | |------|c| |------|c| | 743 | | IP |o| | IP |o| | 744 | |______ m| |______ m| | 745 | | MAC |/ | MAC |/ | 746 | |______/ |______/ | 747 | | 748 | | 749 |______________________________| 751 Figure 3: One application: multiple stacks on a single device 753 If we had a stable Internet layer it might be possible to 754 represent stack names as IP addresses. Even if a host moved, a 755 stack name could be represented as a Mobile-IP "home" address. The 756 PBK proposal suggests that stack names be passed as necessary as 757 end to end options in IPv6 or simply as options in IPv4. 759 __________________ ________________________ 760 | | | | 761 | _______________| |____________________ | 762 | /_______________| |___________________ /| | 763 | | A P P L I| |C A T I O N |f| | 764 | |----------------| |-------------------|o| | 765 | | T R A N | | P O R T |o| | 766 | |----------------| |-------------------|.| | 767 | | I N T E| |R N E T |c| | 768 | |----------------| |-------------------|o| | 769 | | F R A M| | I N G |m| | 770 | |----------------| |-------------------| / | 771 | |________________| |___________________|/ | 772 | | | | 773 |__________________| |________________________| 775 Figure 4: Another application: single stack represented by 776 multiple hosts 777 If we do not assume a stable Internet layer, then stack names must 778 appear above it. If we insert a new mechanism between the Internet 779 and transport layers, all end points that wish to use the mechanism 780 would need to change. 782 3.2.1 A few words about transport mechanisms 784 We may not wish to completely divorce the transport layer from the 785 Internet layer, as currently implemented. The transport mechanisms 786 today are responsible for congestion control. If one end point 787 moves it is quite possible that the congestion characteristics of 788 the links involve will change as well, and it thus might be 789 desirable for mechanisms such as TCP Slow Start to be invoked. It 790 is also possible that codecs may no longer be appropriate for the 791 new path, based on its new characteristics. In as much as mobile 792 hosts change their locations and bindings with MOBILE-IP today, 793 this is already an issue. 795 3.3 Stack names and the routing system 797 It would seem a certainty that the routing system would want very 798 little to do with stack names. However, as previously mentioned, 799 when we break the binding between Internet and transport layers, we 800 now must take some care to not introduce new security problems, 801 such that a transport connection cannot be hijacked by another host 802 that pretends to be authorized on behalf of an end point. 804 One misguided way to do this would be to enforce that binding in 805 the routing system by monitoring binding changes. In order for the 806 routing system to monitor the binding, it realistically must be 807 done out in the open (i.e., not an encrypted exchange) and the 808 binding must appear at some standard point, such as an option or at 809 a predictable point in the packet (e.g., something akin to layer 810 3.5). 812 In other words, one would have gone all the way around from 813 attempting to break the binding between transport and Internet 814 layers to re-establishing the binding through the use of some sort 815 of authorization mechanism to bind stack names and Internet 816 addresses. 818 3.4 Is an architectural change needed? 820 The question of what level in the stack to solve the problem 821 eventually raises whether or not we contemplate architectural 822 changes or engineering enhancements. There can be little dispute 823 that the topic is architectural in nature. For one, there are now 824 numerous attempts to solve end point identification problems within 825 the engineering space. We've already mentioned but a few. The 826 real question is whether the existing architecture can cover the 827 space. Here there are two lines of thought. The first is that the 828 use of mobility mechanisms and MOBILE-IP will cover any perceived 829 need to provide stack names. Assuming that it can be widely and 830 securely deployed, MOBILE-IP certainly resolves many host mobility 831 concerns. However, it remains to be seen if it can address other 832 problems, such as those introduced by content delivery networks. 834 The other line of thought is that we should make the architectural 835 distinction between names, addresses, and routes more explicit 836 since there is otherwise an overloading of operators. Regardless 837 of whatever tactical benefit one might gain, the sheer 838 architectural separation should provide value in and of itself over 839 time. The risk of this argument is that we will have introduced 840 complexity without having actually solved any specific problem, 841 initially. 843 To resolve the differences between the two schools of thought 844 requires development of the latter idea to the point where it can 845 be properly defended, or for that matter, attacked. 847 4 Conclusions or Questions 849 The NSRG was not able to come to unanimity as to whether an 850 architectural change is needed. In order to answer that question, 851 as just noted in the previous section, the notion of a stack name 852 should be further developed. 854 Specific questions that should be answered are the following: 856 1. How would a stack name improve the overall functionality of the 857 Internet? 858 2. What does a stack name look like? 859 3. Where does it live in the stack? 860 4. How is it used on the end points? 861 5. What administrative infrastructure is needed to support it? 862 6. If we add an additional layer would it make the address list in 863 SCTP unnecessary? 864 7. What additional security benefits would a new naming scheme 865 offer? 866 8. What would the resolution mechanisms be, or what 867 characteristics of a resolution mechanisms would be required? 869 Of the many existing efforts in this area, what efforts could such 870 a name help? For instance, would a stack name provide for a more 871 natural MIDCOM design? 873 This document raises more questions than answers. Further studies 874 will hopefully propose valid answers. 876 5 Further Studies 878 Various efforts continue independently. One outgrowth is the HIP 879 working group within the IETF. Although this work occurs in the 880 IETF, it should be noted that there is a risk to attempting to 881 standardize something about which we yet have the full benefit of 882 having explored in research. 884 Work on relieving stress between routing and addressing also 885 continues within the IETF in the MULTI6 and PTOMAIN working groups. 887 A separate effort proceeds elsewhere in the research community to 888 address what the Internet should look like ten years from now. 889 There-in we suspect that stack names will play a considerably 890 larger role. 892 It is possible that work will continue within the IRTF. However, 893 that work should be conducted by smaller teams until mature 894 proposals can be debated. Questions of "whether additional name 895 spaces should be introduced" can only be answered in such a manner. 897 6 Acknowledgments 899 This document is a description of a review done by the Name Space 900 Research Group of the Internet Research Task Force. The members of 901 that group include: J. Noel Chiappa, Scott Bradner, Henning 902 Schulzrinne, Brian Carpenter, Rob Austien, Karen Sollins, John 903 Wroclawski, Steve Bellovin, Steve Crocker, Keith Moore, Steve 904 Deering, Matt Holdrege, Randy Stewart, Leslie Daigle, John 905 Ioannidis, John Day, Thomas Narten, Bob Moskowitz, Ran Atkinson, 906 Gabriel Montenegro, and Lixia Xiang. 908 Particular thanks go to Noel Chiappa whose notions and continuing 909 efforts on end points kicked off the stack name discussion. The 910 definition of an endpoint is largely taken from Noel's unpublished 911 draft. Thanks also to Ran Atkinson and Bob Moskowitz whose 912 comments can be found (in some cases verbatim) in this document. 914 The idea of GSE or 8+8 was originally developed by Mike O'Dell. 915 The documents in which GSE is described are not published as RFCs. 917 7. Author's Address 919 Eliot Lear 920 Cisco Systems, Inc. 921 170 West Tasman Dr. 922 San Jose, CA 95134 923 Phone: +1 408 527 4020 924 EMail: lear@cisco.com 926 8. References 928 [DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 929 March, 1997. 931 [BCP5] Rekhter, Y. et al, "Address Allocation for Private 932 Internets", BCP-5, February, 1996. 934 [NAT] Srisuresh, P., Holdrege, M., "IP Network Address Translator 935 (NAT) Terminology and Considerations", RFC 2663, August 1999. 937 [Shoch] Shoch, J., "Inter-Network Naming, Addressing and Routing", 938 Proceedings of IEEE Compcon, pp 72-97, Fall, 1978. 940 [GSE] O'Dell, M., "GSE - an alternate addressing architecture for 941 IPv6", draft-ietf-ipngwg-gseaddr-00.txt, 1997. 943 [Saltzer92] Saltzer, J., "On The Naming and Binding of Network 944 Destinations", RFC 1498, September, 1992 (as republished). 946 [Saltzer84] Saltzer, J, Reed, D., Clark, D., "End-To-End Arguments 947 in System Design", ACM Transactions on Computer Systems, Vol. 2, 948 No. 4, November, 1984. 950 [TCP] Postel, J., "Transmission Control Protocol", RFC 792, 951 September, 1981. 953 [MCAST] Deering, S.E., "Host Extensions for IP multicasting", 954 RFC 1112, August, 1989. 956 [SSH] Ylonen, T., et. al, "SSH Protocol Architecture", Work in 957 Progress, draft-ietf-secsh-architecture-09.txt, July, 2001. 959 [ESP] Kent, S., Atkinson, R., "IP Encapsulating Security Payload 960 (ESP)", RFC 2406, November, 1998. 962 [IKE] Harkins, D., Carrel, D., "Internet Key Exchange", RFC 2409, 963 November 1998. 965 [TLS] Dierks, T., Allen, C., "The TLS Protocol Version 1.0", 966 RFC 2246, January, 1999. 968 [TRANSP] Carpenter, B., "Internet Transparency", RFC 2775, 969 February, 2000. 971 [INAT] Hain, T., "Architectural Implications of NAT", RFC 2993, 972 November, 2000. 974 [NATCOMP] Holdrege, M., Srisuresh, P., "Protocol Complications 975 with the IP Network Address Translator", RFC 3027, January, 2001. 977 [BGP4] Rekhter, Y., Li, T., "Border Gateway Protocol 4 (BGP-4)", 978 RFC 1771, March, 1995. 980 [MobileIP] Perkins, C., "IP Mobility Support", RFC 2002, 981 October, 1996. 983 [MobileIPv6] Johnson, P., Perkins, C., "Mobility Support in IPv6", 984 Work in Progress, draft-ietf-mobileip-ipv6-14.txt, July, 2001. 986 [ADDIP] Stewart, et. al., "SCTP Extensions for Dynamic 987 Reconfiguration of IP Addresses", Work in Progress, 988 draft-ietf-tsvwg-addip-sctp-03.txt, November, 2001. 990 [HIP-ARCH] Moskowitz, B., "Host Identity Payload Architecture", 991 Work in Progress, draft-moskowitz-hip-arch-02.txt, February, 2001. 993 [PBK] Bradner, S., Mankin, A., Schiller, J., "A framework for 994 Purpose Build Keys (PBK)", Work in Progress, 995 draft-bradner-pbk-frame-00.txt, February, 2001. 997 [URN] Sollins, K., "Architectural Principles of Universal Resource 998 Name Resolution", RFC 2276, January, 1998. 1000 [ESMTP] Klensin, J. (Ed), "Simple Mail Transfer Protocol", 1001 RFC 2821, April, 2001. 1003 9. Intellectual Property Statement 1005 The IETF takes no position regarding the validity or scope of any 1006 intellectual property or other rights that might be claimed to 1007 pertain to the implementation or use of the technology described in 1008 this document or the extent to which any license under such rights 1009 might or might not be available; neither does it represent that it 1010 has made any effort to identify any such rights. Information on 1011 the IETF's procedures with respect to rights in standards-track and 1012 standards-related documentation can be found in BCP-11. Copies of 1013 claims of rights made available for publication and any assurances 1014 of licenses to be made available, or the result of an attempt made 1015 to obtain a general license or permission for the use of such 1016 proprietary rights by implementors or users of this specification 1017 can be obtained from the IETF Secretariat. 1019 The IETF invites any interested party to bring to its attention any 1020 copyrights, patents or patent applications, or other proprietary 1021 rights which may cover technology that may be required to practice 1022 this standard. Please address the information to the IETF 1023 Executive Director. 1025 10. Full Copyright Statement 1027 Copyright (C) The Internet Society (2000). All Rights Reserved. 1029 This document and translations of it may be copied and furnished to 1030 others, and derivative works that comment on or otherwise explain 1031 it or assist in its implementation may be prepared, copied, 1032 published and distributed, in whole or in part, without restriction 1033 of any kind, provided that the above copyright notice and this 1034 paragraph are included on all such copies and derivative works. 1035 However, this document itself may not be modified in any way, such 1036 as by removing the copyright notice or references to the Internet 1037 Society or other Internet organizations, except as needed for the 1038 purpose of developing Internet standards in which case the 1039 procedures for copyrights defined in the Internet Standards process 1040 must be followed, or as required to translate it into languages 1041 other than English. The limited permissions granted above are 1042 perpetual and will not be revoked by the Internet Society or its 1043 successors or assigns. This document and the information contained 1044 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND 1045 THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, 1046 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 1047 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 1048 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1049 PARTICULAR PURPOSE." 1051 11. Expiration Date 1053 This memo is filed as , and expires 1054 November 21, 2002.