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