idnits 2.17.1 draft-irtf-nsrg-report-05.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 is 1 instance of too long lines in the document, the longest one being 2 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 (May 2002) is 8017 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'PPP' is mentioned on line 61, but not defined == Missing Reference: 'HTTP11' is mentioned on line 70, but not defined == Missing Reference: 'PGP' is mentioned on line 140, but not defined == Unused Reference: 'TRANSP' is defined on line 974, but no explicit reference was found in the text == Unused Reference: 'INAT' is defined on line 977, but no explicit reference was found in the text == Unused Reference: 'NATCOMP' is defined on line 980, 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: 12 errors (**), 0 flaws (~~), 13 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 2002 5 Expires: November 30, 2002 7 draft-irtf-nsrg-report-05.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 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. 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. 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] to ease address 62 management, private network address space and network address 63 translators (NAT), the overall addressing model on the Internet has 64 become one of transients. One borrows an address from place to 65 place, or from time to time, when one needs to assert a location in 66 the network topology.[BCP5,NAT] In addition, a single IP address 67 can now be shared by multiple servers to represent a single logical 68 end point. The converse is also true- a single server can 69 represent multiple logical end points, and not even have to use 70 multiple 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. 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 a 163 transport connection being hijacked changes. Instead of having to 164 intercept every packet, an attacker may only need to forge a 165 rebinding message to one end or the other of a connection. 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] 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. 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 borrowed IP addresses without 202 compromising security? 204 1.3 Stresses 206 The most important change the Internet has undergone is spectacular 207 growth. The result of the growth has been shortages in address 208 space and routing resources. 210 As the growth of the Internet exploded so did address space 211 utilization. A combination of measures, including the introduction 212 of private address space, NATs, and a tightening of policy by 213 addressing registries reduced the risk of the Internet running out 214 of allocatable addresses until the 2010 time frame (or later). As 215 a result, however, the unique identification of an end point and 216 the universal ability to reach it was lost. 218 At the same time, Internet routing tables exploded in size. To 219 reduce routing tables routes, classless routing [BGP4] was 220 developed and deployed to aggregate routes on bit boundaries, 221 rather than on old classful boundaries. Next, the IANA 222 discontinued its policy of allocating addresses directly to end 223 users and instead allocated them hierarchically to providers, 224 requiring providers to show sufficient allocation and utilization 225 to justify further assignments. This retarded for a time the 226 explosion in routing, but did not eliminate growth. While work 227 continues in this area, it is important to understand that as of 228 this writing the aggregation of routes through CIDR is the most 229 efficient way to route Internet traffic, given its current design 230 goals. 232 There is a natural conflict between the above two policies. If one 233 allocates addresses in small chunks, more routing entries will 234 result. Periodically providers will renumber to get larger blocks, 235 at the inconvenience of all of their customers. 237 In summary, the Internet has exploded in size, NATs are now widely 238 present, and the use of mechanisms such as PPP and DHCP are widely 239 deployed. In addition, services are now as much or more of 240 interest than are individual hosts. Given all of these changes, is 241 it possible to add a new name space that will make connectivity 242 more stable and allow us to establish some new operating 243 assumptions, such as the ones that these complications broke? 245 2 Related Work 247 There exists a large body of work on name spaces and their 248 bindings. The work we discuss below primarily relates to the 249 binding of stacks to IP addresses, with an eye toward mobility or 250 transience. The first mechanism is Mobile-IP. 252 2.1 Mobile-IP 254 Mobile-IP addresses the problem of having a stable end point 255 identifier on mobile hosts. As hosts move through the topology 256 they update a home agent which acts as an ever-present anchor. 257 Mobile-IP provides a different solution depending on whether one is 258 using IPv4 or IPv6.[MobileIP,MobileIPv6]. In IPv4, Mobile-IP is a 259 tunneling mechanism. In IPv6, mobile hosts make use of destination 260 options. An end system uses its home address to create transport 261 connections and communicate with the other end, one or more 262 correspondent nodes. IPV4 mobile hosts are tunneled through a home 263 agent and optionally a foreign agent, so that the end system's 264 address space is found in the routing system without additional 265 global routing overhead. In IPv4 the home agent is separate from 266 the other end of a transport connection, and packets take a 267 triangular route. In IPv6, support of mobility is required, and 268 the likely non-mobile host, the correspondent node, is aware that 269 the other end is mobile. Therefore, once the mobile host and 270 remote host establish communications they can "short circuit" to 271 remove the home agent. This is key because while the foreign agent 272 is likely to be near the mobile host, the home agent is unlikely to 273 be near anybody. 275 _______ ________ 276 | |Care-of Address | | foreign agent optionally 277 |Mobile |--------------------| Remote | forwards packets to mobile 278 | Host | | Agent | host 279 |_______| |________| 280 ::Home Address | 281 :: | home agent encapsulates and passes 282 :: | packets to the remote agent or 283 :: ___|____ directly to the mobile node 284 :: | | 285 :: | Home | 286 :: | Agent |\ remote host sends packets 287 :: |________| \ to home agent 288 :: \ 289 \\ \ 290 \\ \ 291 \\ \_____________ 292 \\ tunneled transport connection | | 293 =====================================|Correspondent| 294 | Node | 295 |_____________| 297 Figure 1: Mobile-IPv4 299 In effect, Mobile-IP turns the mobile node's IP address into a host 300 identifier, where the "care of" address is the host's current 301 location. The way Mobile-IP succeeds is that it uses tunneling 302 within the topology to represent an address at one location when it 303 is in fact at another. However, a route to the mobile node's 304 address itself must be available within the topology at all times. 305 In an IPv4 world this would be untenable because of constraints on 306 both the addressing system. With IPv6, the addressing pressures 307 are off, and so each host can have a unique end address. However, 308 problems remain with the routing system. In addition, there is a 309 class of devices for which there may be no "home", such as devices 310 in airplanes, mobile homes, or constant travelers. Additionally, 311 there is a desire within some of the mobility community to have 312 "micromobility" mechanisms that enable faster movement than 313 envisioned by Mobile-IP. The Routing Research Group (rrg) is 314 currently investigating this area. 316 Most importantly, mobile devices can't withstand the loss of the 317 home agent, even if they are still online somewhere. With the home 318 agent offline, no incoming connections can get to them, and 319 long-lived communications cannot be re-established. If the 320 rendezvous point location/identity wasn't overloaded on the home 321 address (which is, of necessity, a place in the network, and might 322 go offline, not a distributed database), it might be possible to 323 work around that for those entities that cared about that failure 324 mode. 326 2.2 Stream Control Transport Protocol (SCTP) 328 Many of the problems raised have to do with the use of layer 3 329 information at higher layers, such as the pseudo-header in TCP. 330 A protocol that is considered an alternative to TCP has certain 331 potential benefits in the area of names and addresses. TCP 332 transport connection end points are named by IP addresses, and 333 there are precisely two end point addresses, one for each end. 334 SCTP allows for multiple transport addresses per end, nominally for 335 redundancy of applications that require high availability. 336 However, it is possible to move a transport connection as a host 337 moves from one location to another, or as its address changes due 338 to renumbering (for whatever purpose). Work has progressed within 339 the IETF to introduce a new capability to SCTP, that allows 340 connection end points to change the set of IP addresses used for a 341 transport connection.[ADDIP] 343 There are three limitations to this idea. For one, it only affects 344 those hosts that use SCTP, and so long as there exist other 345 transports that are considered more appropriate for specific tasks, 346 solving an Internet naming problem within SCTP will be susceptible 347 to the charge that the solution is not sufficiently general. 349 The second problem is that as contemplated in the draft the risk of 350 an attacker hijacking a connection is elevated. This same 351 problem exists within MobileIP, and may similarly be mitigated by 352 purpose built keys (see below). 354 Finally, because SCTP does not have a home agent, SCTP does not 355 handle what some would argue is a corner case, when two nodes 356 change their location at the same time. 358 2.3 Host Identity Payload 360 Host Identity Payload (HIP) is a new approach to the problem of 361 naming end points. It inserts an additional "name" between layer 3 362 and layer 4, thus becoming layer 3.5.[HIP-ARCH] The goal is to 363 decouple the transport layer from the Internet layer, so that 364 changes in the Internet layer do not impact the transport, and the 365 benefit is shared by all mechanisms atop transports that use HIP. 367 ______________________________________ 368 | | 369 | Application | 370 |______________________________________| 371 | | 372 | Transport | 373 |______________________________________| The Host Stack 374 | | 375 | HIP or ESP w/ HI as SPI | 376 |______________________________________| 377 | | 378 | IP Header | 379 |______________________________________| 381 Figure 2: Host Identity 383 HIP itself relies on a cryptographic host identity (HI) that is 384 represented in a Host Identity Tag (HIT) of various forms. One is 385 a hash of the public key host identity, another is an 386 administratively assigned value coupled with a smaller hash of the 387 public key host identity. Host identities can be public or 388 anonymous, the difference being whether or not they are published 389 in a directory. 391 Whereas today one binds the transport to an IP address, HIP 392 proposes that the transport binds to a host identity tag (HIT). 393 DNS is used to determine the HI and HIT, or to validate via reverse 394 lookup an HIT. Further, DNS continues to be used to get an 395 Internet address. 397 Whether one should want to decouple the transport layer from the 398 Internet layer is a controversial question. After all, that 399 coupling has for many years provided the barest bones of the 400 security of knowing that the packets that make up the transport 401 connection are being guided through the network by routing 402 tables in Internet routers that are owned by people and 403 organizations whose intent is to get one's packets from source to 404 destination. If we divorce the transport from the Internet layer, 405 we introduce another way for an attacker to potentially hijack 406 connections. HIP attempts to address this through the use of 407 public key verification. 409 Additionally, HIP raises an issue regarding other uses for 410 aggregation of IP addresses. Today, they are not only aggregated 411 for purposes of reduced routing, but also for reduced 412 administration. A typical access list used on the Internet will 413 have some sort of a mask, indicating that a group of hosts from the 414 same subnet may access some resource. Because the value of a HIT 415 is a hash in part, only the administratively assigned value can be 416 aggregated, introducing an allocation limitation and authorization 417 concerns. 419 On the other hand, there is the old computer science saying, any 420 problem can be fixed by an additional layer of indirection 421 (arguably what we're talking about). It should be possible to 422 administratively aggregate on groupings that are made at higher 423 layers. 425 An alternative approach would be to aggregate based on DNS names, 426 rather than HI values. See [HIP-ARCH] for more details. 428 A key concern with HIP is whether or not it will work in a mobile 429 world. If the DNS is involved, or if any directory is involved, 430 will caching semantics eventually limit scalability, or are there 431 mobility mechanisms that can be employed make use of directories 432 feasible? 434 2.4 Purpose Built Keys 436 Purpose built keys (PBKs) are temporary end point identifiers that 437 are used to validate a given endpoint during a communication. PBKs 438 are similar to HIP.[PBK] Rather than attempting to build an 439 infrastructure to validate the end points, however, PBK's sole 440 purpose is to ensure that two hosts that originate a communication 441 may continue that communication with the knowledge that when 442 finished each end point will be the same end point it was at the 443 start. Thus, even if one's address changes for whatever reason it 444 is still possible to validate oneself to the other side of the 445 communication. 447 PBKs take the form of ad hoc public / private key pairs. When a 448 node wishes to validate itself to another node it signs a piece of 449 data with its private key that is validated by the other end with 450 the public key. The public key itself becomes an end point 451 identifier. 453 PBKs make no claim as to who the parties actually are. They make 454 no use of public key infrastructures. PBKs are themselves 455 ephemeral for the duration of a communication. 457 2.5 RSIP and MIDCOM 459 Two related efforts have been made to stitch together name spaces 460 that conflict. One is RSIP, which allows for the temporary 461 allocation of address space in one "realm" by a host in another 462 realm, not unlike the way an address is gotten via DHCP. The 463 benefit of RSIP is that it allows the end point to know what 464 address it is assigned, so that it may pass such information along 465 in the data path, if necessary. The problem with RSIP is that host 466 routing decisions within the stack are very complex. The host 467 makes decisions based on destination address (a process that a fair 468 amount of configuration, and lacked certainty as it was based on 469 potentially non-unique IP addresses). Because RSIP borrows public 470 addresses it must relinquish them as quickly as possible, or the 471 point of NAT is negated. In order to make better use of the scarce 472 public resource, RSIP implementations would need to route not just 473 on destination address, but on application information as well. 474 For example, internal hosts would probably not need external 475 addresses merely to browse the web. 477 MIDCOM is a similar approach. However, rather than tunneling 478 traffic, an agreement between an end point and its agent and a 479 "middle box" such as a NAT or a firewall is made so that the end 480 point understands what transformation will be made by the middle 481 box. Where a NAT or a web cache translates from one name 482 space to another, MIDCOM enables end points to identify that 483 translation. 485 MIDCOM is contemplated for use by specific applications, and thus 486 avoids the stack problems associated with RSIP. However, neither 487 MIDCOM nor RSIP resolve how to discover such middle boxes. Nor do 488 they provide a unique way for a host behind a NAT to identify 489 itself in an enduring way. Finally, they both run into problems 490 when multiple NATs are introduced in a path. 492 2.6 GSE or "8+8" 494 One proposal attempts to ease the conflict between the desire of 495 end systems to have a fixed name for themselves, and the needs of 496 the routing systems for address assignments which minimize the 497 overhead of routing calculations. The clash between these two 498 desires produces either the inconvenience (for the end systems) of 499 renumbering, or routing inefficiency and potentially poor address 500 space utilization as well; the latter caused by the difficulty of 501 renumbering to allows effective use of address space. 503 Known as 8+8 or GSE, it would have split the IPv6 address into two 504 parts: a routing system portion that would be assigned and managed 505 by service providers that would change based on routing system 506 requirements, and a locally managed portion that would be assigned 507 and managed by terminal autonomous systems.[GSE] While each portion 508 is globally unique, there are in effect two addresses, one to get a 509 packet to an autonomous system and another to get to the host. 510 Further, end hosts might not be aware, at least initially, of their 511 routing portions. It was envisioned that the renumbering of 512 the routing portion could be done as a matter of signaling, with 513 little administrative involvement from the end point. Another goal 514 of GSE was to eliminate additional routing overhead caused by 515 multihomed end systems, whose information must today be carried 516 throughout the routing system. By allowing end enterprises to have 517 multiple global parts for purposes of multihoming, the terminal 518 ASes would become what are today's last-hop ISPs. There are a 519 number of challenges that GSE would have to overcome. For one, how 520 does one glue together the provider portion of an address with the 521 more local part, and how would one accomplish the task securely? 522 Would doing so eliminate the need or interest in adding other 523 additional name spaces? 525 2.7 Universal Resource Names 527 Universal resource names (URNs) do not provide us a mechanism to 528 resolve our naming concerns.[URN] Rather, they may provide us the 529 form of the name to use, and perhaps a framework for resolution. 530 For instance, an HI may conceivably be represented as a URN. URNs 531 further the notion of defining a binding and boundaries between the 532 name of an object and its location. 534 3. Discussion: Hosts and Stacks 536 When one's computer moves from one location to another, or when a 537 host receives a new address for whatever reason, the computer 538 itself has largely remained the same, as has the person using it. 539 The identity of that computer has not changed. That entity may 540 well be in communication with other computers and have access 541 rights to network resources. Indeed multiple entities may be 542 represented by a single computer. 544 Until recently it was generally assumed that a host identified 545 itself by an IP address or a group of IP addresses. With the 546 exception of such mechanisms as MX records [ESMTP], one connected 547 to an IP address, assuming there to be an 1:1 relationship between 548 IP address and host. This operating assumption no longer holds, 549 for reasons previously discussed. 551 Today, a host may represent multiple entities. This happens when a 552 service provider hosts many web sites on one server. Similarly, a 553 single entity may be represented by multiple hosts. Replicated web 554 servers are just such an example. We refer to these entities as 555 stacks, instantiations of the TCP/IP model, be they across one or 556 many hosts. We define a stack or end point as one participant or 557 the process on one side of an end-to-end communication. That 558 participant may move, and may be represented by multiple hosts. 560 When two devices represent a single end point they must share state 561 in order to keep the other end from becoming confused (to say the 562 very least). When doing so, such stacks may indeed consist of 563 multiple processes on each end. One view is that such processes 564 can theoretically be named independently of the Internet layer, 565 allowing for sessions to migrate at the behest of applications. 566 However, it is not possible to standardize migration independent of 567 applications, who retain state in all manner of places, from 568 configuration files to memory. Additional names of such processes 569 serve only to identify those who are authorized somehow to 570 represent the end point, and do not themselves alleviate effort 571 required to ensure application consistency. 573 Such an addition may be useful enough to identify mobile nodes, 574 devices behind NATs, and participants of a content delivery or 575 overlay network. 577 We use the word "sessions" above, a mechanism that the current IP 578 stack does not formally provide. If we were to have a session 579 layer in the classic sense it might sit above the transport layer, 580 and a session could consist of more than a single transport 581 connection. If we view the session at below the transport layer, 582 then transport connections can be bound to an identifier of some 583 form other than that of the IP address, and transport connections 584 could persist across IP address changes. It is unlikely, however, 585 that anything that the transport layer binds to would entirely 586 obviate the need for sessions above the transport layer. 588 Each instance of a stack has a name, a "stack name". At an 589 architectural level the Name Space Research Group debated the value 590 of such names, and their associated costs. We see forms of this 591 name used in numerous places today. As previously mentioned, SSH 592 uses public/private key pairs to identify end points. An HTTP 593 cookie anonymously identifies one end of a communication, in such a 594 manner that both the transport connection and the IP address of the 595 other end point may change many times. 597 We now are left with several questions as to the nature of stack 598 names. 600 3.1. What do stack names look like? 602 Names may be structured or unstructured. If they are structured, 603 what encoding do they use, and what is their scope? Is the length 604 of such a name fixed or variable? Are stack names unique across 605 the Internet? If so, are they guaranteed unique through some sort 606 of a registry or are they statistically unique? If it is a 607 registry, is it centralized or distributed, such as DNS? 609 There is no universal view on many of these questions. For one 610 thing, many are concerned that any new registry would bring 611 unwelcome and burdensome administrative costs to connecting to the 612 Internet, either as a service or a user. One could envision a very 613 large reverse lookup domain that contains all HIs, leaving little 614 room for decentralization. 616 In particular we have seen two problems crop up with centralized 617 name spaces. The first problem is that of domain squatting, where 618 people buy a name simply for its usefulness to others. The second 619 problem lies with IP addresses, which are allocated and sold by 620 providers. Those providers may choose to make a "service" out of 621 making addresses available to customers. When designing a new name 622 space, one should introduce no artificial scarcity. 624 As we have seen, one possibility is that stack names could be 625 represented as MOBILE-IP home addresses. The benefit of this idea 626 is that one might well derive a large benefit without having to 627 incur any additional protocol engineering, at least initially. By 628 representing stack names in this way the architectural distinction 629 between stack name and location is somewhat muddled. A difficulty 630 worthy of further debate is whether such incremental approaches 631 actually help us in the long run. Still, the larger the leap, the 632 less the likelihood of deployment success. 634 3.1.1 Uniqueness 636 This document would not exist were uniqueness not desirable, since 637 we could live on in with the current state of affairs (and we may 638 yet). Uniqueness offers certainty that a name represents exactly 639 one object. DNS A records never were intended to have uniqueness. 640 and as we've discussed, IP addresses, particularly in a V4 641 environment, no longer have uniqueness. Uniqueness allows for 642 people and programs to build operating assumptions the other end of 643 a communication. TCP was designed with such an assumption. Being 644 uniquely identified also raises security concerns. What if you 645 don't want to be uniquely identified by generators of SPAM or by 646 powerful entities such as governments? Note that we refer to the 647 uniqueness of the object referenced by the name. An object itself 648 might have multiple names. 650 3.1.2 Mapping 652 This brings into question several related concerns with naming: 653 what, if any, mapping mechanisms exist? Should stack names map to 654 IP addresses, to domain names, or for that matter, to anything? 655 Do domain names, X.509 distinguished names, or other names map to 656 stack names? Each is a separate question. A name on its own is of 657 very limited value. The mappings go to how the name will be used. 658 Is a stack name just something that sits in a transport control 659 block on a device? In effect purpose built keys could accomplish 660 that task. 662 3.1.3 Anonymity 664 Related to uniqueness and mapping is anonymity. Is it possible or 665 even desirable to have anonymous names? That is, should my 666 computer be able to establish a communication to your computer, 667 such that you can be assured that you are communicating with the 668 same entity who used a particular name, without actually knowing 669 the underlying binding between the name and the object? 671 3.1.4 Statistical Uniqueness versus Universal Uniqueness 673 The classic way we have ensured uniqueness of names and addresses 674 on the Internet has been to have those names and addresses assigned 675 through a distributed tree-structured database by central 676 authorities. While this guarantees uniqueness to the level of 677 competence of those authorities, such delegation introduces 678 overhead, artificial markets, trademark concerns, and other 679 problems. One way to avoid a new administrative overhead would be 680 for individuals to be able to generate statistically unique names. 681 Statistically unique names can easily be mapped TO, but they are 682 less easily mapped FROM. This is because it is difficult to 683 establish trust relationships necessary to make changes to the 684 mapping. For instance, if a central authority controls the name 685 space, there must be some sort of authentication and authorization 686 model in place for the change to be allowed. If such a mechanism 687 is in place, one has to wonder (a) why the names used for that 688 infrastructure are not used and therefore (b) why statistically 689 unique names would be of any advantage. 691 There was a consensus that if we were to introduce a new name space 692 it should not be mnemonic in nature. DNS exists for that purpose 693 today, and while others have recently identified a need to revisit 694 DNS, that was not the purpose of this effort. 696 3.1.5 Fixed versus variable length names 698 When the nature of the name is decided one must decide whether the 699 name should be of fixed length or whether it is variable length. 700 Traditionally those fields which are found in every packet tend to 701 be fixed length for performance reasons, as other fields beyond 702 them are easily indexed. The form the name takes will have some 703 relevance on this decision. If the name appears along the lines of 704 an X.509 distinguished name, it must be variable. If the name is 705 otherwise fixed length and supposed to be universally unique, the 706 field must allow for large enough numbers to not require a protocol 707 change anytime soon. Similarly, if the name is statistically 708 unique, the field must be large enough so that the odds of a 709 collision are acceptably low so that the protocol needn't change 710 anytime soon. We leave it to engineers to determine what "anytime 711 soon" and "acceptably low" are. 713 A convenient feature of a variable-length name is that it allows 714 for ease of organizational delegation. If one provides a 715 hierarchical model such as DNS, one can decentralize authority to 716 get a new name or to change a name. By the same token, such 717 structure requires a root authority from which distribution 718 occurs. So long as the name itself is not a pneumonic, perhaps it 719 is possible to limit problems such as domain squatting. 721 Ultimately, if the name is to be other than statistically unique, 722 there will be some sort of central root service. 724 3.2 At what layer are stack names represented? 726 Where are stack names represented? Are they represented in every 727 packet, or are they represented in only those packets that the 728 underlying use requires? The benefit of not requiring stack names 729 to appear in every packet is some amount of efficiency. However, 730 the benefit of having them in every packet is that they can be used 731 by upper layers such as ESP. In addition, end points would be able 732 to distinguish flows of packets coming from the same host even if 733 the IP address changes, or if the remote stack migrates to another 734 piece of hardware. The PBK approach would alert an end point when 735 one side knows of such a change, but as we have seen, the IP 736 address one side sees, the other side may not, without a mechanism 737 such as MIDCOM or RSIP. HIP and ESP solve this problem by putting 738 an identifier (either the HIT or SPI) in every packet. 740 ______________________________ 741 | ______ ______ | 742 | /_____ /| /_____ /| | 743 | | APP |f| | APP |b| | 744 | |------|o| |------|a| | 745 | |TRANS |o| |TRANS |r| | 746 | | PORT |.| | PORT |.| | 747 | |------|c| |------|c| | 748 | | IP |o| | IP |o| | 749 | |______ m| |______ m| | 750 | | MAC |/ | MAC |/ | 751 | |______/ |______/ | 752 | | 753 | | 754 |______________________________| 756 Figure 3: One application: multiple stacks on a single device 758 If we had a stable Internet layer it might be possible to 759 represent stack names as IP addresses. Even if a host moved, a 760 stack name could be represented as a Mobile-IP "home" address. The 761 PBK proposal suggests that stack names be passed as necessary as 762 end to end options in IPv6 or simply as options in IPv4. 764 __________________ ________________________ 765 | | | | 766 | _______________| |____________________ | 767 | /_______________| |___________________ /| | 768 | | A P P L I| |C A T I O N |f| | 769 | |----------------| |-------------------|o| | 770 | | T R A N | | P O R T |o| | 771 | |----------------| |-------------------|.| | 772 | | I N T E| |R N E T |c| | 773 | |----------------| |-------------------|o| | 774 | | F R A M| | I N G |m| | 775 | |----------------| |-------------------| / | 776 | |________________| |___________________|/ | 777 | | | | 778 |__________________| |________________________| 780 Figure 4: Another application: single stack represented by 781 multiple hosts 782 If we do not assume a stable Internet layer, then stack names must 783 appear above it. If we insert a new mechanism between the Internet 784 and transport layers, all end points that wish to use the mechanism 785 would need to change. 787 3.2.1 A few words about transport mechanisms 789 We may not wish to completely divorce the transport layer from the 790 Internet layer, as currently implemented. The transport mechanisms 791 today are largely responsible for congestion control. If one end 792 point moves it is quite possible that the congestion 793 characteristics of the links involve will change as well, and it 794 thus might be desirable for mechanisms such as TCP Slow Start to be 795 invoked. It is also possible that codecs may no longer be 796 appropriate for the new path, based on its new characteristics. In 797 as much as mobile hosts change their locations and bindings with 798 MOBILE-IP today, this is already an issue. 800 3.3 Stack names and the routing system 802 It would seem a certainty that the routing system would want very 803 little to do with stack names. However, as previously mentioned, 804 when we break the binding between Internet and transport layers, we 805 now must take some care to not introduce new security problems, 806 such that a transport connection cannot be hijacked by another host 807 that pretends to be authorized on behalf of an end point. 809 One misguided way to do this would be to enforce that binding in 810 the routing system by monitoring binding changes. In order for the 811 routing system to monitor the binding, it realistically must be 812 done out in the open (i.e., not an encrypted exchange) and the 813 binding must appear at some standard point, such as an option or at 814 a predictable point in the packet (e.g., something akin to layer 815 3.5). 817 In other words, one would have gone all the way around from 818 attempting to break the binding between transport and Internet 819 layers to re-establishing the binding through the use of some sort 820 of authorization mechanism to bind stack names and Internet 821 addresses. 823 3.4 Is an architectural change needed? 825 The question of what level in the stack to solve the problem 826 eventually raises whether or not we contemplate architectural 827 changes or engineering enhancements. There can be little dispute 828 that the topic is architectural in nature. For one, there are now 829 numerous attempts to solve end point identification problems within 830 the engineering space. We've already mentioned but a few. The 831 real question is whether the existing architecture can cover the 832 space. Here there are two lines of thought. The first is that the 833 use of mobility mechanisms and MOBILE-IP will cover any perceived 834 need to provide stack names. Assuming that it can be widely and 835 securely deployed, MOBILE-IP certainly resolves many host mobility 836 concerns. However, it remains to be seen if it can address other 837 problems, such as those introduced by content delivery networks. 839 The other line of thought is that we should make the architectural 840 distinction between names, addresses, and routes more explicit 841 since there is otherwise an overloading of operators. Regardless 842 of whatever tactical benefit one might gain, the sheer 843 architectural separation should provide value in and of itself over 844 time. The risk of this argument is that we will have introduced 845 complexity without having actually solved any specific problem, 846 initially. 848 To resolve the differences between the two schools of thought 849 requires development of the latter idea to the point where it can 850 be properly defended, or for that matter, attacked. 852 4 Conclusions or Questions 854 The NSRG was not able to come to unanimity as to whether an 855 architectural change is needed. In order to answer that question, 856 as just noted in the previous section, the notion of a stack name 857 should be further developed. 859 Specific questions that should be answered are the following: 861 1. How would a stack name improve the overall functionality of the 862 Internet? 863 2. What does a stack name look like? 864 3. What is its lifetime? 865 4. Where does it live in the stack? 866 5. How is it used on the end points? 867 6. What administrative infrastructure is needed to support it? 868 7. If we add an additional layer would it make the address list in 869 SCTP unnecessary? 870 8. What additional security benefits would a new naming scheme 871 offer? 872 9. What would the resolution mechanisms be, or what 873 characteristics of a resolution mechanisms would be required? 875 Of the many existing efforts in this area, what efforts could such 876 a name help? For instance, would a stack name provide for a more 877 natural MIDCOM design? 879 This document raises more questions than answers. Further studies 880 will hopefully propose valid answers. 882 5 Further Studies 884 Various efforts continue independently. One outgrowth is the HIP 885 working group within the IETF. Although this work occurs in the 886 IETF, it should be noted that there is a risk to attempting to 887 standardize something about which we yet have the full benefit of 888 having explored in research. 890 Work on relieving stress between routing and addressing also 891 continues within the IETF in the MULTI6 and PTOMAIN working groups. 893 A separate effort proceeds elsewhere in the research community to 894 address what the Internet should look like ten years from now. 895 There-in we suspect that stack names will play a considerably 896 larger role. 898 It is possible that work will continue within the IRTF. However, 899 that work should be conducted by smaller teams until mature 900 proposals can be debated. Questions of "whether additional name 901 spaces should be introduced" can only be answered in such a manner. 903 6 Acknowledgments 905 This document is a description of a review done by the Name Space 906 Research Group of the Internet Research Task Force. The members of 907 that group include: J. Noel Chiappa, Scott Bradner, Henning 908 Schulzrinne, Brian Carpenter, Rob Austien, Karen Sollins, John 909 Wroclawski, Steve Bellovin, Steve Crocker, Keith Moore, Steve 910 Deering, Matt Holdrege, Randy Stewart, Leslie Daigle, John 911 Ioannidis, John Day, Thomas Narten, Bob Moskowitz, Ran Atkinson, 912 Gabriel Montenegro, and Lixia Xiang. 914 Particular thanks go to Noel Chiappa whose notions and continuing 915 efforts on end points kicked off the stack name discussion. The 916 definition of an endpoint is largely taken from Noel's unpublished 917 draft. Thanks also to Ran Atkinson and Bob Moskowitz whose 918 comments can be found (in some cases verbatim) in this document. 920 The idea of GSE or 8+8 was originally developed by Mike O'Dell. 921 The documents in which GSE is described are not published as RFCs. 923 7. Author's Address 925 Eliot Lear 926 Cisco Systems, Inc. 927 170 West Tasman Dr. 928 San Jose, CA 95134 929 Phone: +1 408 527 4020 930 EMail: lear@cisco.com 932 8. References 934 [DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 935 March, 1997. 937 [BCP5] Rekhter, Y. et al, "Address Allocation for Private 938 Internets", BCP-5, February, 1996. 940 [NAT] Srisuresh, P., Holdrege, M., "IP Network Address Translator 941 (NAT) Terminology and Considerations", RFC 2663, August 1999. 943 [Shoch] Shoch, J., "Inter-Network Naming, Addressing and Routing", 944 Proceedings of IEEE Compcon, pp 72-97, Fall, 1978. 946 [GSE] O'Dell, M., "GSE - an alternate addressing architecture for 947 IPv6", draft-ietf-ipngwg-gseaddr-00.txt, 1997. 949 [Saltzer92] Saltzer, J., "On The Naming and Binding of Network 950 Destinations", RFC 1498, September, 1992 (as republished). 952 [Saltzer84] Saltzer, J, Reed, D., Clark, D., "End-To-End Arguments 953 in System Design", ACM Transactions on Computer Systems, Vol. 2, 954 No. 4, November, 1984. 956 [TCP] Postel, J., "Transmission Control Protocol", RFC 792, 957 September, 1981. 959 [MCAST] Deering, S.E., "Host Extensions for IP multicasting", 960 RFC 1112, August, 1989. 962 [SSH] Ylonen, T., et. al, "SSH Protocol Architecture", Work in 963 Progress, draft-ietf-secsh-architecture-09.txt, July, 2001. 965 [ESP] Kent, S., Atkinson, R., "IP Encapsulating Security Payload 966 (ESP)", RFC 2406, November, 1998. 968 [IKE] Harkins, D., Carrel, D., "Internet Key Exchange", RFC 2409, 969 November 1998. 971 [TLS] Dierks, T., Allen, C., "The TLS Protocol Version 1.0", 972 RFC 2246, January, 1999. 974 [TRANSP] Carpenter, B., "Internet Transparency", RFC 2775, 975 February, 2000. 977 [INAT] Hain, T., "Architectural Implications of NAT", RFC 2993, 978 November, 2000. 980 [NATCOMP] Holdrege, M., Srisuresh, P., "Protocol Complications 981 with the IP Network Address Translator", RFC 3027, January, 2001. 983 [BGP4] Rekhter, Y., Li, T., "Border Gateway Protocol 4 (BGP-4)", 984 RFC 1771, March, 1995. 986 [MobileIP] Perkins, C., "IP Mobility Support", RFC 2002, 987 October, 1996. 989 [MobileIPv6] Johnson, P., Perkins, C., "Mobility Support in IPv6", 990 Work in Progress, draft-ietf-mobileip-ipv6-14.txt, July, 2001. 992 [ADDIP] Stewart, et. al., "SCTP Extensions for Dynamic 993 Reconfiguration of IP Addresses", Work in Progress, 994 draft-ietf-tsvwg-addip-sctp-03.txt, November, 2001. 996 [HIP-ARCH] Moskowitz, B., "Host Identity Payload Architecture", 997 Work in Progress, draft-moskowitz-hip-arch-02.txt, February, 2001. 999 [PBK] Bradner, S., Mankin, A., Schiller, J., "A framework for 1000 Purpose Build Keys (PBK)", Work in Progress, 1001 draft-bradner-pbk-frame-00.txt, February, 2001. 1003 [URN] Sollins, K., "Architectural Principles of Universal Resource 1004 Name Resolution", RFC 2276, January, 1998. 1006 [ESMTP] Klensin, J. (Ed), "Simple Mail Transfer Protocol", 1007 RFC 2821, April, 2001. 1009 9. Intellectual Property Statement 1011 The IETF takes no position regarding the validity or scope of any 1012 intellectual property or other rights that might be claimed to 1013 pertain to the implementation or use of the technology described in 1014 this document or the extent to which any license under such rights 1015 might or might not be available; neither does it represent that it 1016 has made any effort to identify any such rights. Information on 1017 the IETF's procedures with respect to rights in standards-track and 1018 standards-related documentation can be found in BCP-11. Copies of 1019 claims of rights made available for publication and any assurances 1020 of licenses to be made available, or the result of an attempt made 1021 to obtain a general license or permission for the use of such 1022 proprietary rights by implementors or users of this specification 1023 can be obtained from the IETF Secretariat. 1025 The IETF invites any interested party to bring to its attention any 1026 copyrights, patents or patent applications, or other proprietary 1027 rights which may cover technology that may be required to practice 1028 this standard. Please address the information to the IETF 1029 Executive Director. 1031 10. Full Copyright Statement 1033 Copyright (C) The Internet Society (2000). All Rights Reserved. 1035 This document and translations of it may be copied and furnished to 1036 others, and derivative works that comment on or otherwise explain 1037 it or assist in its implementation may be prepared, copied, 1038 published and distributed, in whole or in part, without restriction 1039 of any kind, provided that the above copyright notice and this 1040 paragraph are included on all such copies and derivative works. 1041 However, this document itself may not be modified in any way, such 1042 as by removing the copyright notice or references to the Internet 1043 Society or other Internet organizations, except as needed for the 1044 purpose of developing Internet standards in which case the 1045 procedures for copyrights defined in the Internet Standards process 1046 must be followed, or as required to translate it into languages 1047 other than English. The limited permissions granted above are 1048 perpetual and will not be revoked by the Internet Society or its 1049 successors or assigns. This document and the information contained 1050 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND 1051 THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, 1052 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 1053 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 1054 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1055 PARTICULAR PURPOSE." 1057 11. Expiration Date 1059 This memo is filed as , and expires 1060 November 30, 2002.