idnits 2.17.1 draft-irtf-nsrg-report-01.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 == Line 61 has weird spacing: '...ressing model...' == Line 62 has weird spacing: '...borrows an ad...' == Line 63 has weird spacing: '...time to time,...' -- 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 (January 2001) is 8473 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'PPP' is mentioned on line 58, but not defined == Missing Reference: 'NAT' is mentioned on line 760, but not defined == Missing Reference: 'INAT' is mentioned on line 794, but not defined == Unused Reference: 'BCP5' is defined on line 757, but no explicit reference was found in the text == Unused Reference: 'TRANSP' is defined on line 791, 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 (-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 January 2001 5 Expires: July 15, 2002 7 draft-irtf-nsrg-report-01.txt 8 What's In A Name: 9 Report from the Name Space Research Group 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? 44 ++ Although this document has a single author, the ideas 45 ++ described are those of many people both within and outside of the 46 ++ IRTF (see the References and Acknowledgements sections for more 47 ++ details). 49 1 Introduction 51 The Internet has gone through several metamorphoses, and how one 52 gets around on the Internet has changed over time. Even though the 53 IP packet has remained largely unchanged, the routing of that 54 packet has changed considerably. For many years, addressing of end 55 points was a somewhat trivial matter. One could name end points 56 either by IP address or by the mnemonic pointing to that address- a 57 domain name. The difference between name and address seemed 58 unimportant. However, with the advent of PPP[PPP] and DHCP[DHCP], 59 private network address space and network address translators 61 (NAT), the addressing model on the Internet has become one of 62 transients. One borrows an address from place to place, or from 63 time to time, when one needs to assert a location in the network 64 We are not the first to point out the differences between names, 65 addresses, and routes. That was done as early as 1978 in 66 IEN-119[Shoch]. The argument has been carried forth in a 67 discussion of routing and addressing in numerous academic 68 discussions, including [Saltzer92] and [Saltzer84]. However, we 69 are now faced with some logical outcomes earlier authors may well 70 have predicted. 72 Today we ask the question: given the ephemeral nature of IP 73 addresses, is something more than IP addresses and DNS needed to 74 resolve end points? What functionality would that something bring 75 to the table? 77 1.1 How Endpoints Communicate Today 79 While attempting not to burden the reader with a long review of how 80 IP works, we must consider the process of communication between end 81 points on the Internet in order to address the question we pose. 83 We consider three forms of communication: 85 Unicast Connection Oriented 87 A good example is classic TCP. In order for two ends to establish 88 a connection, one end resolves the address of the other, usually by 89 DNS lookup, and then the two exchange SYNs and ACKs, thereby 90 exchanging state.[TCP] A TCP connection may last for a brief 91 fraction of a second, or it may last for days. 93 We also consider connection oriented UDP services, such as SIP or 94 H.323. Again, state is exchanged, this time in an application 95 specific way. 97 Multicast 99 Because multicast is a one-to-many method of communication it is 100 for the most part connectionless, albeit not necessarily stateless. 101 When a host is to receive a multicast it declares its interest in 102 the communication via IGMP [MCAST] and the routing system then 103 arranges for that host to receive messages to a particular address. 105 Although most of our discussions will focus on unicast, we are 106 mindful of the impact any changes made may have on multicast. 108 Anycast 110 Finally, a form of communication that has of late become useful: 111 anycast. An anycast request is served the "nearest" computer 112 participating in that anycast service, for some value of "near". 113 Examples of anycast mechanisms include use of multiple DNS servers 114 answering on a single IP address. Modern anycast service requires 115 that either the requests consist of a single packet exchange or 116 that those endpoints sharing the name or address closely coordinate 117 so as not to break routing or other semantics. 119 1.1.1 Security Considerations 121 Communications today are secured through one of several means. For 122 strongest protocol security, the communication is encrypted and the 123 ends are identified with verifiable public keys. Several systems 124 are available today to do this, including SSH[SSH], the IPSEC 125 mechanisms of ESP[ESP] and IKE[IKE], and TLS[TLS]. 127 The absence of a namespace that uniquely named a host created 128 problems in the design of ESP/AH (so-called "IPsec"). ESP/AH 129 really want to bind security associations to a hostname distinct 130 from either DNS or IP address, because both the DNS entry and the 131 IP address can change when in fact the security association could 132 remain valid. This would occur in the case where a PC moves from 133 one point in a topology to another. In the absence of a persistent 134 name in the Internet Architecture, IP addresses are used for the 135 binding of Security Associations. This is an architectural 136 shortcoming, not a feature. Among other advantages, a real unique 137 namespace would mean that ESP/AH did not care about the 138 presence/absence of NAT/PAT devices. 140 At a different level, there is an expectation that the routing 141 system guides a packet toward the destination end point, as 142 indicated in the IP destination address. Until a few years ago, 143 this would not have been an unreasonable assumption. Today 144 there are exceptions, particularly transparent web proxies and 145 firewalls. 147 With some of the currently contemplated changes, the risk of 148 hijacking a connection changes from that of a continuous intercept 149 to the potential of a redirection through some form of spoofed 150 rebinding. 152 1.2 How Things Have Changed 154 As mentioned earlier, the nature of communications has changed. 155 When one transfers a web page to one's system it is quite likely 156 that the remote address and TCP port, as it appears to the web 157 server, will not bear much relation to what the client browsing 158 host stated. Furthermore, without great difficulty the client 159 cannot determine the address it is in fact using when speaking to a 160 server. And indeed it itself cannot become a server because 161 another end has no way to address it. This is the essence of NAT. 162 All the perils of NAT have been well documented by 163 In addition, computers are far more mobile than they were just a 164 few years ago. When one moves from one location to another, one's 165 address changes to reflect one's change in topology. Because TCP 166 bases its transport connection state on IP addresses, any 167 connections to the old address are lost (but see below). 169 This brings us to our question: what if we interpose an additional 170 layer with an additional name? Would it be possible to do that 171 which cannot be done with NAT? What impact would this have on 172 mobility? To answer these questions, we ask an additional 173 question: does wide adoption of IP version 6 restore the same 174 functionality without requiring an additional layer of indirection? 176 1.3 Strains 178 There are two resource strains we must now mention. The first 179 strain is on the addressing system. As the growth of the Internet 180 exploded so did address utilization. A combination of measures, 181 including the introduction of private address space, NATs, and a 182 tightening of policy by addressing registries reduced the risk of 183 the Internet running out of allocatable addresses until the 2010 184 time frame. 186 At the same time, Internet routing tables exploded in size. To 187 reduce routing tables routes, classless routing [BGP4] was developed 188 and deployed to aggregate routes on bit boundaries, rather than on 189 old classful boundaries. Next, the IANA discontinued its policy of 190 allocating addresses directly to end users and instead allocated 191 them hierarchically to providers, requiring providers to show 192 sufficient allocation and utilization to justify further 193 assignments. This retarded for a time the explosion in routing, 194 but did not eliminate growth. Work continues in this area. 196 There is a natural conflict between the above two policies. If one 197 allocates addresses in small chunks, more routing entries will 198 result. Periodically providers will renumber to get larger blocks, 199 at the inconvenience of all of their customers. 201 2 Related Work 203 Although the problem has been brewing for a few years, so have 204 several solutions. None of these solutions is perfect or complete, 205 but each addresses some subset of the problem. The first is 206 MOBILE-IP. 208 2.1 Mobile-IP 210 Mobile-IP addresses the problem of having a stable end point 211 identifier on mobile hosts. As hosts move through the topology 212 they update a home agent which acts as an ever-present anchor. 213 Mobile-IP provides a different solution depending on whether one is 214 using IPv4 or IPv6.[MobileIP,MobileIPv6] In IPv4 each packet is 215 encapsulated in a mobility packet. An end system uses its home 216 address to create transport connections. In addition it is routed 217 via a home agent and a remote agent, so that the end system's 218 address space is found in the routing system. In IPv4 the home 219 agent is separate from the other end of a transport connection, and 220 packets take a triangular route. In IPv6, Mobile-IP is required. 221 Therefore, once the mobile host and remote host establish 222 communications they can "short circuit" to remove the home agent. 223 This is key because while the remote agent is likely to be near the 224 mobile host, the home agent is unlikely to be near anybody. 226 _______ ________ 227 | |Care-of Address | | remote agent optionally 228 |Mobile |--------------------| Remote | forwards packets to mobile 229 | Host | | Agent | host 230 |_______| |________| 231 ::Home Address | 232 :: | home agent encapsulates and passes 233 :: | packets to the remote agent or 234 :: ___|____ directly to the mobile node 235 :: | | 236 :: | Home | 237 :: | Agent |\ remote host sends packets 238 :: |________| \ to home agent 239 :: \ 240 \\ \ 241 \\ \ 242 \\ \_____________ 243 \\ tunneled transport connection | | 244 =====================================|Correspondent| 245 | Node | 246 |_____________| 248 Figure 1: Mobile-IPv4 250 The way Mobile-IP succeeds is that it uses tunneling within the 251 topology to represent an address at one location when it is in fact 252 at another. However, a route to the address itself must be 253 available within the topology at all times. In an IPv4 world this 254 would be untenable because of constraints on both the addressing 255 and routing systems. With IPv6, the addressing pressures are off, 256 and so each host can have a unique end address. However, problems 257 remain with the routing system. In addition, there is a class of 258 devices for which there may be no "home". 260 2.2 Session Control Transport Protocol (SCTP) 262 Many of the problems raised have to do with the use of layer 3 263 information at higher layers, such as the pseudo-header in TCP. 264 A protocol that is considered an alternative to TCP has certain 265 potential benefits in the area of names and addresses. TCP 266 transport connection end points are named by IP addresses, and 267 there are precisely two end point addresses, one for each end. 268 SCTP allows for multiple transport addresses per end, nominally for 269 redundancy of applications that require high availability. 270 However, there may be a limited ability to move a transport 271 connection as a host moves from one location to another, or as its 272 address changes due to renumbering (for whatever purpose). 274 There are some limitations to this idea. For one, it only affects 275 those hosts that use SCTP. For another, there is no mechanism to 276 add transport end points to an SCTP connection dynamically today. 277 Finally, even if one could, one would need to communicate that 278 change of binding somehow to the other end, a problem not 279 contemplated by the SCTP authors. 281 2.3 Host Identity Payload 283 Host Identity Payload (HIP) is a new approach to the problem of 284 naming end points. It inserts an additional "name" between layer 3 285 and layer 4, thus becoming layer 3.5. The goal is to decouple the 286 transport layer from the Internet layer, so that changes in the 287 Internet layer do not impact the transport, and the benefit is 288 shared by all mechanisms atop transports that use HIP. 290 ______________________________________ 291 | | 292 | Application | 293 |______________________________________| 294 | | 295 | Transport | 296 |______________________________________| The Host Stack 297 | | 298 | HIP or ESP w/ HI as SPI | 299 |______________________________________| 300 | | 301 | IP Header | 302 |______________________________________| 304 Figure 2: Host Identity 306 HIP itself relies on a cryptographic host identity (HI) which is 307 represented in a Host Identity Tag (HIT) of various forms. One is 308 a hash of the public key host identity, another is an 309 administratively assigned value coupled with a smaller hash of the 310 public key host identity. Host identities can be public or 311 anonymous, the difference being whether or not they are published 312 in a directory. 314 Whereas today one binds the transport to an IP address, HIP 315 proposes that the transport binds to a host identity tag (HIT). 316 DNS is used to determine the HI and HIT, or to validate via reverse 317 lookup an HIT. Further, DNS continues to be used to get an 318 Internet address. 320 Whether one should want to decouple the transport layer from the 321 Internet layer is a controversial question. After all, that 322 coupling has for many years provided the barest bones of the 323 security of knowing that the packets that make up the transport 324 connection are following natural routing, as guided by routing 325 tables in Internet routers that are owned by people and 326 organizations whose intent is to get one's packets from source to 327 destination. 329 Additionally, HIP raises an issue regarding other uses for 330 aggregation of IP addresses. Today, they are not only aggregated 331 for purposes of reduced routing, but also for reduced 332 administration. A typical access list used on the Internet will 333 have some sort of a mask, indicating that a group of hosts from the 334 same subnet may access some resource. Because the value of a HIT 335 is a hash in part, only the administratively assigned value can be 336 aggregated, introducing an allocation problem similar to those of 337 addresses. 339 An alternative approach would be to aggregate based on DNS names, 340 rather than HI values. See [HIP-ARCH] for more details. 342 A key concern with HIP is whether or not it will work in a mobile 343 world. If the DNS is involved, or if any directory is involved, 344 will caching semantics eventually limit scalability, or are there 345 mobility mechanisms that can be employed make use of directories 346 feasible? 348 2.4 Purpose Built Keys 350 Purpose built keys (PBKs) are temporary end point identifiers that 351 are used to validate a given endpoint during a communication. PBKs 352 are similar to HIP.[PBK] Rather than attempting to build an 353 infrastructure to validate the end points, however, PBK's sole 354 purpose is to ensure that two hosts that originate a communication 355 may continue that communication with the knowledge that when 356 finished each end point will be the same end point it was at the 357 start. Thus, even if one's address changes for whatever reason it 358 is still possible to validate oneself to the other side of the 359 communication. 361 PBKs take the form of ad hoc public / private key pairs. When a 362 node wishes to validate itself to another node it signs a piece of 363 data with its private key that is validated by the other end with 364 the public key. The public key itself becomes an end point 365 identifier. 367 PBKs make no claim as to who the parties actually are. They make 368 no use of public key infrastructures. PBKs are themselves 369 ephemeral for the duration of a communication. 371 2.5 RSIP and MIDCOM 373 Two related efforts have been made to stitch together name spaces 374 that conflict. One is RSIP, which allows for the temporary 375 allocation of address space in one "realm" by a host in another 376 realm, not unlike the way an address is gotten via DHCP. The 377 benefit of RSIP is that it allows the end point to know what 378 address it is assigned, so that it may pass such information along 379 in the data path, if necessary. The problem with RSIP contemplated 380 implementations required tunneling of some form, making host 381 routing decisions highly complex. For instance, if an HTTP 382 connection was to be made, should RSIP be used or not? 384 MIDCOM is a similar approach. However, rather than tunneling 385 traffic, an agreement between an end point and its agent and a 386 "middle box" such as a NAT or a firewall is made so that the end 387 point understands what transformation will be made by the middle 388 ++ box. Thus, where a NAT or a web cache translates from one name 389 ++ space to another, MIDCOM enables end points to identify that 390 ++ translation. 392 MIDCOM is contemplated for use by specific applications, and thus 393 avoids the stack problems associated with RSIP. However, neither 394 MIDCOM nor RSIP resolve how to discover such middle boxes. Nor do 395 they provide a unique way for a host behind a NAT to identify 396 itself in an enduring way. 398 2.6 GSE or "8+8" 400 One proposal attempts to ease the conflict between end system 401 inconvenience of renumbering and address space and routing space 402 efficiency. Known as 8+8 or GSE, it would have split the IPv6 403 address into two parts: a globally managed portion that would be 404 assigned and managed by service service providers, and a locally 405 managed portion that would be assigned and managed by terminal 406 autonomous systems. Further, end hosts would not be aware, at 407 least initially, of their global portions. It was thus envisioned 408 that the renumbering of the global portion could be done as a 409 matter of signaling, with little administrative involvement from 410 the enterprise. Another goal of GSE was to eliminate additional 411 routing overhead caused by multihomed enterprises, whose 412 information must today be carried throughout the routing system. 413 By allowing end enterprises to have multiple global parts for 414 purposes of multihoming, the terminal ASes would become what are 415 today's last-hop ISPs. 417 2.7 Universal Resource Names 419 Universal resource names (URNs) do not provide us a mechanism to 420 resolve our naming concerns.[URN] Rather, they may provide us the 421 form of the name to use, and perhaps a framework for resolution. 422 For instance, an HI may conceivably be represented as a URN. URNs 423 further the notion of defining a binding and boundaries between the 424 name of an object and its location. 426 3. Discussion: Hosts and Stacks 428 ++ When one's computer moves from one location to another, or when a 429 ++ host receives a new address for whatever reason, the computer 430 ++ itself has largely remained the same, as has the person using it. 431 ++ The identity of that computer has not changed. That entity may 432 ++ well be in communication other computers and have access rights to 433 ++ network resources. Indeed multiple entities may be represented by 434 ++ a single computer. 436 Until recently it was generally assumed that a host identified 437 itself by an IP address or a group of IP addresses. With the 438 exception of such mechanisms as MX records [ESMTP], one connected 439 to an IP address, assuming there to be an 1:1 relationship between 440 IP address and host. This assumption is no longer valid for 441 reasons previously discussed. 443 Today, a host may represent multiple entities. This happens when a 444 service provider hosts a web site. Similarly, a single entity may 445 be represented by multiple hosts. Replicated web servers are just 446 such an example. We refer to these entities as stacks, 447 instantiations of the TCP/IP model, be they across one or many 448 ++ hosts. We define a stack or end point as one participant of an 449 ++ end-to-end communication. That participant may move, and may be 450 ++ represented by multiple hosts. 452 ** Each instance of a stack has a name, a "stack name". At an 453 ** architectural level the Name Space Research Group debated the value 454 ** of such names, and their associated costs. We see forms of this 455 name used in numerous places today. As previously mentioned, SSH 456 uses public/private key pairs to identify end points. An HTTP 457 cookie anonymously identifies one end of a communication, in such a 458 manner that both the transport connection and the IP address of the 459 other end point may change many times. 461 We thus are left with several questions as to the nature of stack 462 names. 464 3.1. What do stack names look like? 466 Names may be structured or unstructured. If they are structured, 467 what encoding do they use, and what is their scope? Is the length 468 of such a name fixed or variable? Are stack names unique across 469 the Internet? If so, are they guaranteed unique through some sort 470 of a registry or are they statistically unique? If it is a 471 registry, is it centralized or distributed, such as DNS? 473 There is no universal view on many of these questions. For one 474 thing, many are concerned that any new registry would bring 475 unwelcome and burdensome administrative costs to connecting to the 476 Internet, either as a service or a user. One could envision a very 477 large reverse lookup domain that contains all HIs, leaving little 478 room for decentralization. 480 ++ In particular we have seen two problems crop up with centralized 481 ++ name spaces. The first problem is that of domain squatting, where 482 ++ people buy a name simply for its usefulness to others. The second 483 ++ problems lies with IP addresses, which are allocated buy providers. 484 ++ Those providers may choose to make a "service" out of making 485 ++ addresses available to customers. Where at all possible, when 486 ++ designing a new name space, one should introduce no artificial 487 ++ scarcity. 489 One possibility is that stack names could be represented as 490 MOBILE-IP home addresses. The benefit of this idea is that one 491 might well derive a large benefit without having to incur any 492 additional protocol engineering, at least initially. On the other 493 hand, by representing stack names thusly the architectural 494 distinction between stack name and location is somewhat muddled. 495 On the one hand, a mobile IP address bears no relation to its 496 actual place in the network topology. Further, any stack name 497 proposal could be implemented incrementally by those who wish to 498 take advantage of it. On the other hand, the use of a mobile IP 499 address defines the size and structure of stack names, limiting 500 their potential. 502 ++ 3.1.1 Uniqueness 503 ++ 504 ++ Uniqueness offers certainty that a name represents exactly one 505 ++ object. DNS A records never were intended to have such uniqueness, 506 ++ and as we've discussed, IP addresses, particularly in a V4 507 ++ environment, no longer have uniqueness. By providing uniqueness 508 ++ people and programs may build operating assumptions. TCP was 509 ++ designed with such an assumption. Being uniquely identified also 510 ++ raises security concerns. What if you don't want to be uniquely 511 ++ identified by generators of SPAM? 512 ++ 513 ++ 3.1.2 Mapping 514 ++ 515 ++ This brings into question several related concerns with naming: 516 ++ what, if any, mapping mechanisms exist? Should stack names map to 517 ++ IP addresses, to domain names, or for that matter, to anything? 518 ++ Do domain names, X.509 distinguished names, or other names map to 519 ++ stack names? Each is a separate question. A name on its own is of 520 ++ very limited value. The mappings go to how the name will be used. 521 ++ Is a stack name just something that sits in a transport control 522 ++ block on a device? In effect purpose built keys could accomplish 523 ++ that task. 525 ++ 3.1.3 Anonymity 526 ++ 527 ++ Related to uniqueness is anonymity. Is it possible or even 528 ++ desirable to have anonymous names? That is, should my computer be 529 ++ able to establish a communication to your computer, such that you 530 ++ can be assured that you are communicating with the same entity who 531 ++ used a particular name, without actually knowing the underlying 532 ++ binding between the name and the object? A good example of 533 ++ anonymity exists in the Uniform Commercial Code of U.S. law in the 534 ++ form of agency law. Do we need such an analog for networking? 535 ++ 536 ++ 3.1.4 Statistical Uniqueness versus Universal Uniqueness 537 ++ 538 ++ The classic way we have ensured uniqueness of names and addresses 539 ++ on the Internet has been to have those names and addresses assigned 540 ++ by central authorities. While this guarantees uniqueness to the 541 ++ level of competence of those authorities, as we have discussed, 542 ++ such delegation introduces overhead and other problems. One way to 543 ++ avoid a new administrative overhead would be for individuals to be 544 ++ able to generate statistically unique names. Statistically unique 545 ++ names can easily be mapped TO, but they are less easily mapped 546 ++ FROM. [more needed here]. 548 There was a consensus that if we were to introduce a new name space 549 it should not be mnemonic in nature. DNS exists for that purpose 550 today, and while others have recently identified a need to revisit 551 DNS, that was not the purpose of this effort. 553 3.2 At what layer are stack names represented? 555 Where are stack names represented? Are they represented in every 556 packet, or are they represented in only those packets that the 557 underlying use requires? The benefit of not requiring stack names 558 to appear in every packet is some amount of efficiency. However, 559 the benefit of having them in every packet is that they can be used 560 by upper layers such as ESP. In addition, end points would be able 561 to distinguish flows of packets coming from the same host even if 562 the IP address changes, or if the remote stack migrates to another 563 piece of hardware. The PBK approach would alert an end point when 564 one side knows of such a change, but as we have seen, the IP 565 address one side sees, the other side may not, without a mechanism 566 such as MIDCOM or RSIP. HIP and ESP solve this problem by putting 567 an identifier (either the HIT or SPI) in every packet. 569 ______________________________ 570 | ______ ______ | 571 | /_____ /| /_____ /| | 572 | | APP |f| | APP |b| | 573 | |------|o| |------|a| | 574 | |TRANS |o| |TRANS |r| | 575 | | PORT |.| | PORT |.| | 576 | |------|c| |------|c| | 577 | | IP |o| | IP |o| | 578 | |______ m| |______ m| | 579 | | MAC |/ | MAC |/ | 580 | |______/ |______/ | 581 | | 582 | | 583 |______________________________| 585 Figure 3: One application: multiple stacks on a single device 587 If we had a stable Internet layer it might be possible to 588 represent stack names as IP addresses. Even if a host moved, a 589 stack name could be represented as a Mobile-IP "home" address. The 590 PBK proposal suggests that stack names be passed as necessary as 591 end to end options in IPv6 or simply as options in IPv4. 593 __________________ ________________________ 594 | | | | 595 | _______________| |____________________ | 596 | /_______________| |___________________ /| | 597 | | A P P L I| |C A T I O N |f| | 598 | |----------------| |-------------------|o| | 599 | | T R A N | | P O R T |o| | 600 | |----------------| |-------------------|.| | 601 | | I N T E| |R N E T |c| | 602 | |----------------| |-------------------|o| | 603 | | F R A M| | I N G |m| | 604 | |----------------| |-------------------| / | 605 | |________________| |___________________|/ | 606 | | | | 607 |__________________| |________________________| 609 Figure 4: Another application: single stack represented by 610 multiple hosts 612 If we do not assume a stable Internet layer, then stack names must 613 appear above it. If we insert a new mechanism between the Internet 614 and transport layers, all end points that wish to use the mechanism 615 would need to change. 617 ++ 3.2.1 A few words about transport mechanisms 618 ++ 619 ++ We may not wish to completely divorce the transport layer from the 620 ++ Internet layer, as currently implemented. The transport mechanisms 621 ++ today are responsible for congestion control. If one end point 622 ++ moves it is quite possible that the congestion characteristics of 623 ++ the links involve will change as well, and it thus might be 624 ++ desirable for mechanisms such as TCP Slow Start to be invoked. It 625 ++ is also possible that codecs may no longer be appropriate for the 626 ++ new path, based on its new characteristics. In as much as mobile 627 ++ hosts change their locations and bindings with MobileIPv4 today, 628 ++ this is already an issue. 630 3.3 Stack names and the routing system 632 It would seem a certainty that the routing system would want very 633 little to do with stack names. However, as previously mentioned, 634 when we break the binding between Internet and transport layers, we 635 now must take some care to not introduce new security problems, 636 such that a transport connection cannot be hijacked by another host 637 that pretends to be authorized on behalf of an end point. 639 One misguided way to do this would be to enforce that binding in 640 the routing system by monitoring binding changes. In order for the 641 routing system to monitor the binding, it realistically must be 642 done out in the open (i.e., not an encrypted exchange) and the 643 binding must appear at some standard point, such as an option or at 644 a predictable point in the packet (e.g., something akin to layer 645 3.5). 647 In other words, one would have gone all the way around from 648 attempting to break the binding between transport and Internet 649 layers to re-establishing the binding through the use of some sort 650 of authorization mechanism to bind stack names and Internet 651 addresses. 653 3.4 Is an architectural change needed? 655 The question of what level in the stack to solve the problem 656 eventually raises whether or not we contemplate architectural 657 changes or engineering enhancements. There can be little dispute 658 that the topic is architectural in nature. For one, there are now 659 numerous attempts to solve end point identification problems within 660 the engineering space. We've already mentioned but a few. The 661 real question is whether the existing architecture can cover the 662 space. Here there are two lines of thought. The first is that the 663 use of mobility mechanisms and MOBILE-IP will cover any perceived 664 need to provide stack names. Assuming that it can be widely and 665 securely deployed, MOBILE-IP certainly resolves many host mobility 666 concerns. However, it remains to be seen if it can address other 667 problems, such as those introduced by content delivery networks. 669 The other line of thought is that we should make the architectural 670 distinction between names, addresses, and routes more explicit 671 since there is otherwise an overloading of operators. Regardless 672 of whatever tactical benefit one might gain, the sheer 673 architectural separation should provide value in and of itself over 674 time. The risk of this argument is that we will having introduced 675 complexity without having actually solved any specific problem, 676 initially. 678 To resolve the differences between the two schools of thought 679 requires development of the latter idea to the point where it can 680 be properly defended, or for that matter, attacked. 682 4 Conclusions 684 The NSRG was not able to come to consensus as to whether an 685 architectural change is needed. In order to answer that question, 686 as just noted in the previous section, the notion of a stack name 687 should be further developed. 689 Specific questions that should be answered are the following: 691 1. How would a stack name improve the overall functionality of the 692 Internet? 693 2. What does a stack name look like? 694 3. Where does it live in the stack? 695 4. How is it used on the end points? 696 5. What administrative infrastructure is needed to support it? 698 Of the many existing efforts in this area, what efforts could such 699 a name help? For instance, would a stack name provide for a more 700 natural MIDCOM design? 702 This document raises more questions than answers. Further studies 703 will hopefully propose valid answers. 705 5 Further Studies 707 Various efforts continue independently. One outgrowth is the HIP 708 working group within the IETF. Although this work occurs in the 709 IETF, it should be noted that there is a risk to attempting to 710 standardize something about which we yet have the full benefit of 711 having explored in research. 713 Work on relieving stress between routing and addressing also 714 continues within the IETF in the MULTI6 and PTOMAIN working groups. 716 A separate effort proceeds elsewhere in the research community to 717 address what the Internet should look like ten years from now. 718 There-in we suspect that stack names to play a considerably larger 719 role. 721 It is possible that work will continue within the IRTF. However, 722 that work should be conducted by smaller teams until mature 723 proposals can be debated. Questions of "whether additional name 724 spaces should be introduced" can only be answered in such a manner. 726 6 Acknowledgments 728 This document is a description of a review done by the Name Space 729 Research Group of the Internet Research Task Force. The members of 730 that group include: J. Noel Chiappa, Scott Bradner, Henning 731 Schulzrinne, Brian Carpenter, Rob Austien, Karen Sollins, John 732 Wroclawski, Steve Bellovin, Steve Crocker, Keith Moore, Steve 733 Deering, Matt Holdredge, Randy Stewart, Leslie Daigle, John 734 Ioannidis, John Day, Thomas Narten, Bob Moskowitz, Ran Atkinson, 735 Gabriel Montenegro, and Lixia Xiang. 737 Particular thanks go to Noel Chiappa whose notions and continuing 738 ++ efforts on end points kicked off the stack name discussion. The 739 ++ definition of an endpoint is largely taken from Noel's unpublished 740 ** draft. Thanks also to Ran Atkinson and Bob Moskowitz whose 741 ** comments can be found (in some cases verbatim) in this document. 743 7. Author's Address 745 Eliot Lear 746 Cisco Systems, Inc. 747 170 West Tasman Dr. 748 San Jose, CA 95134 749 Phone: +1 408 527 4020 750 EMail: lear@cisco.com 752 8. References 754 [DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 755 March, 1997. 757 [BCP5] Rekhter, Y. et al, "Address Allocation for Private 758 Internets", BCP-5, February, 1996. 760 ** [NAT] Srisuresh, P., Holdrege, M., "IP Network Address Translator 761 ** (NAT) Terminology and Considerations", RFC 2663, August 1999. 763 [Shoch] Shoch, J., "Inter-Network Naming, Addressing and Routing", 764 Proceedings of IEEE Compcon, pp 72-97, Fall, 1978. 766 [Saltzer92] Saltzer, J., "On The Naming and Binding of Network 767 Destinations", RFC 1498, September, 1992 (as republished). 769 [Saltzer84] Saltzer, J, Reed, D., Clark, D., "End-To-End Arguments 770 in System Design", ACM Transactions on Computer Systems, Vol. 2, 771 No. 4, November, 1984. 773 [TCP] Postel, J., "Transmission Control Protocol", RFC 792, 774 September, 1981. 776 [MCAST] Deering, S.E., "Host Extensions for IP multicasting", 777 RFC 1112, August, 1989. 779 [SSH] Ylonen, T., et. al, "SSH Protocol Architecture", Work in 780 Progress, draft-ietf-secsh-architecture-09.txt, July, 2001. 782 [ESP] Kent, S., Atkinson, R., "IP Encapsulating Security Payload 783 (ESP)", RFC 2406, November, 1998. 785 [IKE] Harkins, D., Carrel, D., "Internet Key Exchange", RFC 2409, 786 November 1998. 788 [TLS] Dierks, T., Allen, C., "The TLS Protocol Version 1.0", 789 RFC 2246, January, 1999. 791 [TRANSP] Carpenter, B., "Internet Transparency", RFC 2775, 792 February, 2000. 794 ++ [INAT] Hain, T., "Architectural Implications of NAT", RFC 2993, 795 ++ November, 2000. 797 [BGP4] Rekhter, Y., Li, T., "Border Gateway Protocol 4 (BGP-4)", 798 RFC 1771, March, 1995. 800 [MobileIP] Perkins, C., "IP Mobility Support", RFC 2002, 801 October, 1996. 803 [MobileIPv6] Johnson, P., Perkins, C., "Mobility Support in IPv6", 804 Work in Progress, draft-ietf-mobileip-ipv6-14.txt, July, 2001. 806 [HIP-ARCH] Moskowitz, B., "Host Identity Payload Architecture", 807 Work in Progress, draft-moskowitz-hip-arch-02.txt, February, 2001. 809 [PBK] Bradner, S., Mankin, A., Schiller, J., "A framework for 810 Purpose Build Keys (PBK)", Work in Progress, 811 draft-bradner-pbk-frame-00.txt, February, 2001. 813 [URN] Sollins, K., "Architectural Principles of Universal Resource 814 Name Resolution", RFC 2276, January, 1998. 816 [ESMTP] Klensin, J. (Ed), "Simple Mail Transfer Protocol", 817 RFC 2821, April, 2001. 819 9. Intellectual Property Statement 821 The IETF takes no position regarding the validity or scope of any 822 intellectual property or other rights that might be claimed to 823 pertain to the implementation or use of the technology described in 824 this document or the extent to which any license under such rights 825 might or might not be available; neither does it represent that it 826 has made any effort to identify any such rights. Information on 827 the IETF's procedures with respect to rights in standards-track and 828 standards-related documentation can be found in BCP-11. Copies of 829 claims of rights made available for publication and any assurances 830 of licenses to be made available, or the result of an attempt made 831 to obtain a general license or permission for the use of such 832 proprietary rights by implementors or users of this specification 833 can be obtained from the IETF Secretariat. 835 The IETF invites any interested party to bring to its attention any 836 copyrights, patents or patent applications, or other proprietary 837 rights which may cover technology that may be required to practice 838 this standard. Please address the information to the IETF 839 Executive Director. 841 10. Full Copyright Statement 843 Copyright (C) The Internet Society (2000). All Rights Reserved. 845 This document and translations of it may be copied and furnished to 846 others, and derivative works that comment on or otherwise explain 847 it or assist in its implementation may be prepared, copied, 848 published and distributed, in whole or in part, without restriction 849 of any kind, provided that the above copyright notice and this 850 paragraph are included on all such copies and derivative works. 851 However, this document itself may not be modified in any way, such 852 as by removing the copyright notice or references to the Internet 853 Society or other Internet organizations, except as needed for the 854 purpose of developing Internet standards in which case the 855 procedures for copyrights defined in the Internet Standards process 856 must be followed, or as required to translate it into languages 857 other than English. The limited permissions granted above are 858 perpetual and will not be revoked by the Internet Society or its 859 successors or assigns. This document and the information contained 860 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND 861 THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, 862 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 863 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 864 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 865 PARTICULAR PURPOSE." 867 11. Expiration Date 869 This memo is filed as , and expires 870 July 15, 2002.