idnits 2.17.1 draft-irtf-nsrg-report-02.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 (February 2001) is 8471 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: 'ADDIP' is mentioned on line 866, but not defined == Unused Reference: 'BCP5' is defined on line 817, but no explicit reference was found in the text == Unused Reference: 'NAT' is defined on line 820, but no explicit reference was found in the text == Unused Reference: 'TRANSP' is defined on line 851, but no explicit reference was found in the text == Unused Reference: 'INAT' is defined on line 854, 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 (~~), 14 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 February 2001 5 Expires: August 14, 2002 7 draft-irtf-nsrg-report-02.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. In IPv6, mobile hosts make use 216 ** of end host options. An end system uses its home address to create 217 ** transport connections and communicate with the other end, one or 218 ** more correspondent nodes. IPV4 mobile hosts are routed via a home 219 ** agent and optionally a remote agent, so that the end system's 220 ** address space is found in the routing system without additional 221 global routing overhead. In IPv4 the home agent is separate from 222 the other end of a transport connection, and packets take a 223 ** triangular route. In IPv6, support of mobility is required. 224 Therefore, once the mobile host and remote host establish 225 communications they can "short circuit" to remove the home agent. 226 This is key because while the remote agent is likely to be near the 227 mobile host, the home agent is unlikely to be near anybody. 229 _______ ________ 230 | |Care-of Address | | remote agent optionally 231 |Mobile |--------------------| Remote | forwards packets to mobile 232 | Host | | Agent | host 233 |_______| |________| 234 ::Home Address | 235 :: | home agent encapsulates and passes 236 :: | packets to the remote agent or 237 :: ___|____ directly to the mobile node 238 :: | | 239 :: | Home | 240 :: | Agent |\ remote host sends packets 241 :: |________| \ to home agent 242 :: \ 243 \\ \ 244 \\ \ 245 \\ \_____________ 246 \\ tunneled transport connection | | 247 =====================================|Correspondent| 248 | Node | 249 |_____________| 251 Figure 1: Mobile-IPv4 253 The way Mobile-IP succeeds is that it uses tunneling within the 254 topology to represent an address at one location when it is in fact 255 at another. However, a route to the address itself must be 256 available within the topology at all times. In an IPv4 world this 257 would be untenable because of constraints on both the addressing 258 and routing systems. With IPv6, the addressing pressures are off, 259 and so each host can have a unique end address. However, problems 260 ** remain with the routing system. In addition, there is a class of 261 ** devices for which there may be no "home", such as devices in 262 ++ airplanes, mobile homes, or constant travellers. Additionally, 263 ++ there is a desire within some of the mobility community to have 264 ++ "micromobility" mechanisms that enable faster movement than 265 ++ envisioned by Mobile-IP. The Routing Research Group (rrg) is 266 ++ currently investigating this area. 268 ** 2.2 Stream Control Transport Protocol (SCTP) 270 Many of the problems raised have to do with the use of layer 3 271 information at higher layers, such as the pseudo-header in TCP. 272 A protocol that is considered an alternative to TCP has certain 273 potential benefits in the area of names and addresses. TCP 274 transport connection end points are named by IP addresses, and 275 there are precisely two end point addresses, one for each end. 276 SCTP allows for multiple transport addresses per end, nominally for 277 redundancy of applications that require high availability. 278 ** However, it is possible to move a transport connection as a host 279 ** moves from one location to another, or as its address changes due 280 ** to renumbering (for whatever purpose). Work has progressed within 281 ++ the IETF to introduce a new capability to SCTP, that allows 282 ++ connection end points to change the set of IP addresses used for a 283 ++ transport connection.[ADDIP] 285 ** There are three limitations to this idea. For one, it only affects 286 ** those hosts that use SCTP, and so long as there exist other 287 ++ transports that are considered more appropriate for specific tasks, 288 ++ solving an Internet naming problem within SCTP will be susceptable 289 ++ to the charge that the solution is not sufficiently general. 291 ++ The second problem is that as contemplated in the draft the risk of 292 ++ an attacker highjacking a connection is elevated. This same 293 ++ problem exists within MobileIP, and may similarly be mitigated by 294 ++ purpose built keys (see below). 296 Finally, even if one could, one would need to communicate that 297 change of binding somehow to the other end, a problem not 298 ++ contemplated by the draft authors. Mobile-IP partially solves the 299 ++ problem by introducing a static rendevous point, the home agent. 301 2.3 Host Identity Payload 303 Host Identity Payload (HIP) is a new approach to the problem of 304 naming end points. It inserts an additional "name" between layer 3 305 and layer 4, thus becoming layer 3.5.[HIP-ARCH] The goal is to 306 decouple the transport layer from the Internet layer, so that 307 changes in the Internet layer do not impact the transport, and the 308 benefit is shared by all mechanisms atop transports that use HIP. 310 ______________________________________ 311 | | 312 | Application | 313 |______________________________________| 314 | | 315 | Transport | 316 |______________________________________| The Host Stack 317 | | 318 | HIP or ESP w/ HI as SPI | 319 |______________________________________| 320 | | 321 | IP Header | 322 |______________________________________| 324 Figure 2: Host Identity 326 HIP itself relies on a cryptographic host identity (HI) which is 327 represented in a Host Identity Tag (HIT) of various forms. One is 328 a hash of the public key host identity, another is an 329 administratively assigned value coupled with a smaller hash of the 330 public key host identity. Host identities can be public or 331 anonymous, the difference being whether or not they are published 332 in a directory. 334 Whereas today one binds the transport to an IP address, HIP 335 proposes that the transport binds to a host identity tag (HIT). 336 DNS is used to determine the HI and HIT, or to validate via reverse 337 lookup an HIT. Further, DNS continues to be used to get an 338 Internet address. 340 Whether one should want to decouple the transport layer from the 341 Internet layer is a controversial question. After all, that 342 ** coupling has for many years provided the barest bones of the 343 ** security of knowing that the packets that make up the transport 344 ** connection are being guided through the network by routing 345 tables in Internet routers that are owned by people and 346 organizations whose intent is to get one's packets from source to 347 ** destination. If we divorce the transport from the Internet layer, 348 ++ we introduce another way for an attacker to potentially hijack 349 ++ connections. 351 Additionally, HIP raises an issue regarding other uses for 352 aggregation of IP addresses. Today, they are not only aggregated 353 for purposes of reduced routing, but also for reduced 354 administration. A typical access list used on the Internet will 355 have some sort of a mask, indicating that a group of hosts from the 356 same subnet may access some resource. Because the value of a HIT 357 is a hash in part, only the administratively assigned value can be 358 aggregated, introducing an allocation problem similar to those of 359 addresses. 361 An alternative approach would be to aggregate based on DNS names, 362 rather than HI values. See [HIP-ARCH] for more details. 364 A key concern with HIP is whether or not it will work in a mobile 365 world. If the DNS is involved, or if any directory is involved, 366 will caching semantics eventually limit scalability, or are there 367 mobility mechanisms that can be employed make use of directories 368 feasible? 370 2.4 Purpose Built Keys 372 Purpose built keys (PBKs) are temporary end point identifiers that 373 are used to validate a given endpoint during a communication. PBKs 374 are similar to HIP.[PBK] Rather than attempting to build an 375 infrastructure to validate the end points, however, PBK's sole 376 purpose is to ensure that two hosts that originate a communication 377 may continue that communication with the knowledge that when 378 finished each end point will be the same end point it was at the 379 start. Thus, even if one's address changes for whatever reason it 380 is still possible to validate oneself to the other side of the 381 communication. 383 PBKs take the form of ad hoc public / private key pairs. When a 384 node wishes to validate itself to another node it signs a piece of 385 data with its private key that is validated by the other end with 386 the public key. The public key itself becomes an end point 387 identifier. 389 PBKs make no claim as to who the parties actually are. They make 390 no use of public key infrastructures. PBKs are themselves 391 ephemeral for the duration of a communication. 393 2.5 RSIP and MIDCOM 395 Two related efforts have been made to stitch together name spaces 396 that conflict. One is RSIP, which allows for the temporary 397 allocation of address space in one "realm" by a host in another 398 realm, not unlike the way an address is gotten via DHCP. The 399 benefit of RSIP is that it allows the end point to know what 400 address it is assigned, so that it may pass such information along 401 ** in the data path, if necessary. The problem with RSIP is that 402 ** host routing decisions within the stack are very complex. The host 403 ++ makes decisions based on destination address (a process that a fair 404 ++ amount of configuration, and lacked certainty as it was based on 405 ++ potentially non-unique IP addresses). Because RSIP borrows public 406 ++ addresses it must relinquish them as quickly as possible, or the 407 ++ point of NAT is negated. In order to accomplish such a task, RSIP 408 ++ implementations would need to route not just on destination 409 ++ address, but on application information as well. 411 MIDCOM is a similar approach. However, rather than tunneling 412 traffic, an agreement between an end point and its agent and a 413 "middle box" such as a NAT or a firewall is made so that the end 414 point understands what transformation will be made by the middle 415 box. Thus, where a NAT or a web cache translates from one name 416 space to another, MIDCOM enables end points to identify that 417 translation. 419 MIDCOM is contemplated for use by specific applications, and thus 420 avoids the stack problems associated with RSIP. However, neither 421 MIDCOM nor RSIP resolve how to discover such middle boxes. Nor do 422 they provide a unique way for a host behind a NAT to identify 423 itself in an enduring way. 425 2.6 GSE or "8+8" 427 One proposal attempts to ease the conflict between end system 428 inconvenience of renumbering and address space and routing space 429 efficiency. Known as 8+8 or GSE, it would have split the IPv6 430 address into two parts: a globally managed portion that would be 431 assigned and managed by service providers, and a locally managed 432 portion that would be assigned and managed by terminal autonomous 433 systems. Further, end hosts would not be aware, at least 434 initially, of their global portions. It was thus envisioned that 435 the renumbering of the global portion could be done as a matter of 436 signaling, with little administrative involvement from the 437 enterprise. Another goal of GSE was to eliminate additional 438 routing overhead caused by multihomed enterprises, whose 439 information must today be carried throughout the routing system. 440 By allowing end enterprises to have multiple global parts for 441 purposes of multihoming, the terminal ASes would become what are 442 ** today's last-hop ISPs. There are a number of challenges that GSE 443 ++ would have to overcome. For one, how does one glue together the 444 ++ provider portion of an address with more local part? In 445 ++ particular, how would one accomplish the task securely? Would 446 ++ doing so eliminate the need or interest in adding other additional 447 ++ name spaces? 449 2.7 Universal Resource Names 451 Universal resource names (URNs) do not provide us a mechanism to 452 resolve our naming concerns.[URN] Rather, they may provide us the 453 form of the name to use, and perhaps a framework for resolution. 454 For instance, an HI may conceivably be represented as a URN. URNs 455 further the notion of defining a binding and boundaries between the 456 name of an object and its location. 458 3. Discussion: Hosts and Stacks 460 When one's computer moves from one location to another, or when a 461 host receives a new address for whatever reason, the computer 462 itself has largely remained the same, as has the person using it. 463 The identity of that computer has not changed. That entity may 464 well be in communication other computers and have access rights to 465 network resources. Indeed multiple entities may be represented by 466 a single computer. 468 Until recently it was generally assumed that a host identified 469 itself by an IP address or a group of IP addresses. With the 470 exception of such mechanisms as MX records [ESMTP], one connected 471 to an IP address, assuming there to be an 1:1 relationship between 472 IP address and host. This assumption is no longer valid for 473 reasons previously discussed. 475 ** Today, a host may represent multiple entities. This happens when a 476 ** service provider hosts many web sites on one server. Similarly, a 477 single entity may be represented by multiple hosts. Replicated web 478 servers are just such an example. We refer to these entities as 479 stacks, instantiations of the TCP/IP model, be they across one or 480 many hosts. We define a stack or end point as one participant of 481 an end-to-end communication. That participant may move, and may be 482 represented by multiple hosts. 484 Each instance of a stack has a name, a "stack name". At an 485 architectural level the Name Space Research Group debated the value 486 of such names, and their associated costs. We see forms of this 487 name used in numerous places today. As previously mentioned, SSH 488 uses public/private key pairs to identify end points. An HTTP 489 cookie anonymously identifies one end of a communication, in such a 490 manner that both the transport connection and the IP address of the 491 other end point may change many times. 493 We thus are left with several questions as to the nature of stack 494 names. 496 3.1. What do stack names look like? 498 Names may be structured or unstructured. If they are structured, 499 what encoding do they use, and what is their scope? Is the length 500 of such a name fixed or variable? Are stack names unique across 501 the Internet? If so, are they guaranteed unique through some sort 502 of a registry or are they statistically unique? If it is a 503 registry, is it centralized or distributed, such as DNS? 505 There is no universal view on many of these questions. For one 506 thing, many are concerned that any new registry would bring 507 unwelcome and burdensome administrative costs to connecting to the 508 Internet, either as a service or a user. One could envision a very 509 large reverse lookup domain that contains all HIs, leaving little 510 room for decentralization. 512 In particular we have seen two problems crop up with centralized 513 name spaces. The first problem is that of domain squatting, where 514 people buy a name simply for its usefulness to others. The second 515 problems lies with IP addresses, which are allocated buy providers. 516 Those providers may choose to make a "service" out of making 517 problems lies with IP addresses, which are allocated buy providers. 518 Those providers may choose to make a "service" out of making 519 addresses available to customers. Where at all possible, when 520 designing a new name space, one should introduce no artificial 521 scarcity. 523 One possibility is that stack names could be represented as 524 MOBILE-IP home addresses. The benefit of this idea is that one 525 might well derive a large benefit without having to incur any 526 additional protocol engineering, at least initially. On the other 527 hand, by representing stack names thusly the architectural 528 distinction between stack name and location is somewhat muddled. 529 On the one hand, a mobile IP address bears no relation to its 530 actual place in the network topology. Further, any stack name 531 proposal could be implemented incrementally by those who wish to 532 take advantage of it. On the other hand, the use of a mobile IP 533 address defines the size and structure of stack names, limiting 534 their potential. 536 3.1.1 Uniqueness 538 Uniqueness offers certainty that a name represents exactly one 539 object. DNS A records never were intended to have such uniqueness, 540 and as we've discussed, IP addresses, particularly in a V4 541 environment, no longer have uniqueness. By providing uniqueness 542 people and programs may build operating assumptions. TCP was 543 designed with such an assumption. Being uniquely identified also 544 raises security concerns. What if you don't want to be uniquely 545 identified by generators of SPAM? 547 3.1.2 Mapping 549 This brings into question several related concerns with naming: 550 what, if any, mapping mechanisms exist? Should stack names map to 551 IP addresses, to domain names, or for that matter, to anything? 552 Do domain names, X.509 distinguished names, or other names map to 553 stack names? Each is a separate question. A name on its own is of 554 very limited value. The mappings go to how the name will be used. 555 Is a stack name just something that sits in a transport control 556 block on a device? In effect purpose built keys could accomplish 557 that task. 559 3.1.3 Anonymity 561 Related to uniqueness is anonymity. Is it possible or even 562 desirable to have anonymous names? That is, should my computer be 563 able to establish a communication to your computer, such that you 564 can be assured that you are communicating with the same entity who 565 used a particular name, without actually knowing the underlying 566 binding between the name and the object? A good example of 567 anonymity exists in the Uniform Commercial Code of U.S. law in the 568 form of agency law. Do we need such an analog for networking? 569 3.1.4 Statistical Uniqueness versus Universal Uniqueness 571 The classic way we have ensured uniqueness of names and addresses 572 on the Internet has been to have those names and addresses assigned 573 by central authorities. While this guarantees uniqueness to the 574 level of competence of those authorities, as we have discussed, 575 such delegation introduces overhead and other problems. One way to 576 avoid a new administrative overhead would be for individuals to be 577 able to generate statistically unique names. Statistically unique 578 names can easily be mapped TO, but they are less easily mapped 579 ** FROM. This is because it is difficult to establish trust 580 ++ relationships necessary to make changes to the mapping. For 581 ++ instance, if a central authority controls the name space, there 582 ++ must be some sort of authentication and authorization model in 583 ++ place for the change to be allowed. If such a mechanism is in 584 ++ place, one has to wonder (a) why the names used for that 585 ++ infrastructure are not used and thus (b) why statistically unique 586 ++ names would be of any advantage. 588 There was a consensus that if we were to introduce a new name space 589 it should not be mnemonic in nature. DNS exists for that purpose 590 today, and while others have recently identified a need to revisit 591 DNS, that was not the purpose of this effort. 593 3.1.5 Fixed versus variable length names 594 ++ 595 ++ Once the nature of the name is decided one must decide whether the 596 ++ name should be of fixed length or whether it is variable length. 597 ++ Traditionally those fields which are found in every packet tend to 598 ++ be fixed length for performance reasons, as other fields beyond 599 ++ them are easily indexed. However, the form the name takes will 600 ++ have some relevance on this decision. If the name appears along 601 ++ the lines of an X.509 distinguished name, it must be variable. If 602 ++ the name is otherwise fixed and supposed to be universally unique, 603 ++ the field must allow for large enough numbers to not require a 604 ++ protocol change anytime soon. Similarly, if the name is 605 ++ statistically unique, the field must be large enough so that the 606 ++ odds of a collision are acceptably low so that the protocol needn't 607 ++ change anytime soon. We leave it to engineers to determine what 608 ++ "anytime soon" and "acceptably low" are. 610 3.2 At what layer are stack names represented? 612 Where are stack names represented? Are they represented in every 613 packet, or are they represented in only those packets that the 614 underlying use requires? The benefit of not requiring stack names 615 to appear in every packet is some amount of efficiency. However, 616 the benefit of having them in every packet is that they can be used 617 by upper layers such as ESP. In addition, end points would be able 618 to distinguish flows of packets coming from the same host even if 619 the IP address changes, or if the remote stack migrates to another 620 piece of hardware. The PBK approach would alert an end point when 621 one side knows of such a change, but as we have seen, the IP 622 address one side sees, the other side may not, without a mechanism 623 such as MIDCOM or RSIP. HIP and ESP solve this problem by putting 624 an identifier (either the HIT or SPI) in every packet. 626 ______________________________ 627 | ______ ______ | 628 | /_____ /| /_____ /| | 629 | | APP |f| | APP |b| | 630 | |------|o| |------|a| | 631 | |TRANS |o| |TRANS |r| | 632 | | PORT |.| | PORT |.| | 633 | |------|c| |------|c| | 634 | | IP |o| | IP |o| | 635 | |______ m| |______ m| | 636 | | MAC |/ | MAC |/ | 637 | |______/ |______/ | 638 | | 639 | | 640 |______________________________| 642 Figure 3: One application: multiple stacks on a single device 644 If we had a stable Internet layer it might be possible to 645 represent stack names as IP addresses. Even if a host moved, a 646 stack name could be represented as a Mobile-IP "home" address. The 647 PBK proposal suggests that stack names be passed as necessary as 648 end to end options in IPv6 or simply as options in IPv4. 650 __________________ ________________________ 651 | | | | 652 | _______________| |____________________ | 653 | /_______________| |___________________ /| | 654 | | A P P L I| |C A T I O N |f| | 655 | |----------------| |-------------------|o| | 656 | | T R A N | | P O R T |o| | 657 | |----------------| |-------------------|.| | 658 | | I N T E| |R N E T |c| | 659 | |----------------| |-------------------|o| | 660 | | F R A M| | I N G |m| | 661 | |----------------| |-------------------| / | 662 | |________________| |___________________|/ | 663 | | | | 664 |__________________| |________________________| 666 Figure 4: Another application: single stack represented by 667 multiple hosts 669 If we do not assume a stable Internet layer, then stack names must 670 appear above it. If we insert a new mechanism between the Internet 671 and transport layers, all end points that wish to use the mechanism 672 would need to change. 674 3.2.1 A few words about transport mechanisms 676 We may not wish to completely divorce the transport layer from the 677 Internet layer, as currently implemented. The transport mechanisms 678 today are responsible for congestion control. If one end point 679 moves it is quite possible that the congestion characteristics of 680 the links involve will change as well, and it thus might be 681 desirable for mechanisms such as TCP Slow Start to be invoked. It 682 is also possible that codecs may no longer be appropriate for the 683 new path, based on its new characteristics. In as much as mobile 684 hosts change their locations and bindings with MobileIPv4 today, 685 this is already an issue. 687 3.3 Stack names and the routing system 689 It would seem a certainty that the routing system would want very 690 little to do with stack names. However, as previously mentioned, 691 when we break the binding between Internet and transport layers, we 692 now must take some care to not introduce new security problems, 693 such that a transport connection cannot be hijacked by another host 694 that pretends to be authorized on behalf of an end point. 696 One misguided way to do this would be to enforce that binding in 697 the routing system by monitoring binding changes. In order for the 698 routing system to monitor the binding, it realistically must be 699 done out in the open (i.e., not an encrypted exchange) and the 700 binding must appear at some standard point, such as an option or at 701 a predictable point in the packet (e.g., something akin to layer 702 3.5). 704 In other words, one would have gone all the way around from 705 attempting to break the binding between transport and Internet 706 layers to re-establishing the binding through the use of some sort 707 of authorization mechanism to bind stack names and Internet 708 addresses. 710 3.4 Is an architectural change needed? 712 The question of what level in the stack to solve the problem 713 eventually raises whether or not we contemplate architectural 714 changes or engineering enhancements. There can be little dispute 715 that the topic is architectural in nature. For one, there are now 716 numerous attempts to solve end point identification problems within 717 the engineering space. We've already mentioned but a few. The 718 real question is whether the existing architecture can cover the 719 space. Here there are two lines of thought. The first is that the 720 use of mobility mechanisms and MOBILE-IP will cover any perceived 721 need to provide stack names. Assuming that it can be widely and 722 securely deployed, MOBILE-IP certainly resolves many host mobility 723 concerns. However, it remains to be seen if it can address other 724 problems, such as those introduced by content delivery networks. 726 The other line of thought is that we should make the architectural 727 distinction between names, addresses, and routes more explicit 728 since there is otherwise an overloading of operators. Regardless 729 of whatever tactical benefit one might gain, the sheer 730 architectural separation should provide value in and of itself over 731 time. The risk of this argument is that we will have introduced 732 complexity without having actually solved any specific problem, 733 initially. 735 To resolve the differences between the two schools of thought 736 requires development of the latter idea to the point where it can 737 be properly defended, or for that matter, attacked. 739 4 Conclusions 741 The NSRG was not able to come to consensus as to whether an 742 architectural change is needed. In order to answer that question, 743 as just noted in the previous section, the notion of a stack name 744 should be further developed. 746 Specific questions that should be answered are the following: 748 1. How would a stack name improve the overall functionality of the 749 Internet? 750 2. What does a stack name look like? 751 3. Where does it live in the stack? 752 4. How is it used on the end points? 753 5. What administrative infrastructure is needed to support it? 755 Of the many existing efforts in this area, what efforts could such 756 a name help? For instance, would a stack name provide for a more 757 natural MIDCOM design? 759 This document raises more questions than answers. Further studies 760 will hopefully propose valid answers. 762 5 Further Studies 764 Various efforts continue independently. One outgrowth is the HIP 765 working group within the IETF. Although this work occurs in the 766 IETF, it should be noted that there is a risk to attempting to 767 standardize something about which we yet have the full benefit of 768 having explored in research. 770 Work on relieving stress between routing and addressing also 771 continues within the IETF in the MULTI6 and PTOMAIN working groups. 773 A separate effort proceeds elsewhere in the research community to 774 address what the Internet should look like ten years from now. 775 There-in we suspect that stack names will play a considerably 776 larger role. 778 It is possible that work will continue within the IRTF. However, 779 that work should be conducted by smaller teams until mature 780 proposals can be debated. Questions of "whether additional name 781 spaces should be introduced" can only be answered in such a manner. 783 6 Acknowledgments 785 This document is a description of a review done by the Name Space 786 Research Group of the Internet Research Task Force. The members of 787 that group include: J. Noel Chiappa, Scott Bradner, Henning 788 Schulzrinne, Brian Carpenter, Rob Austien, Karen Sollins, John 789 Wroclawski, Steve Bellovin, Steve Crocker, Keith Moore, Steve 790 Deering, Matt Holdredge, Randy Stewart, Leslie Daigle, John 791 Ioannidis, John Day, Thomas Narten, Bob Moskowitz, Ran Atkinson, 792 Gabriel Montenegro, and Lixia Xiang. 794 Particular thanks go to Noel Chiappa whose notions and continuing 795 efforts on end points kicked off the stack name discussion. The 796 definition of an endpoint is largely taken from Noel's unpublished 797 draft. Thanks also to Ran Atkinson and Bob Moskowitz whose 798 comments can be found (in some cases verbatim) in this document. 800 ++ The idea of GSE or 8+8 was originally developed by Mike O'Dell. 801 ++ The documents in which GSE is described are not published as RFCs. 803 7. Author's Address 805 Eliot Lear 806 Cisco Systems, Inc. 807 170 West Tasman Dr. 808 San Jose, CA 95134 809 Phone: +1 408 527 4020 810 EMail: lear@cisco.com 812 8. References 814 [DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 815 March, 1997. 817 [BCP5] Rekhter, Y. et al, "Address Allocation for Private 818 Internets", BCP-5, February, 1996. 820 [NAT] Srisuresh, P., Holdrege, M., "IP Network Address Translator 821 (NAT) Terminology and Considerations", RFC 2663, August 1999. 823 [Shoch] Shoch, J., "Inter-Network Naming, Addressing and Routing", 824 Proceedings of IEEE Compcon, pp 72-97, Fall, 1978. 826 [Saltzer92] Saltzer, J., "On The Naming and Binding of Network 827 Destinations", RFC 1498, September, 1992 (as republished). 829 [Saltzer84] Saltzer, J, Reed, D., Clark, D., "End-To-End Arguments 830 in System Design", ACM Transactions on Computer Systems, Vol. 2, 831 No. 4, November, 1984. 833 [TCP] Postel, J., "Transmission Control Protocol", RFC 792, 834 September, 1981. 836 [MCAST] Deering, S.E., "Host Extensions for IP multicasting", 837 RFC 1112, August, 1989. 839 [SSH] Ylonen, T., et. al, "SSH Protocol Architecture", Work in 840 Progress, draft-ietf-secsh-architecture-09.txt, July, 2001. 842 [ESP] Kent, S., Atkinson, R., "IP Encapsulating Security Payload 843 (ESP)", RFC 2406, November, 1998. 845 [IKE] Harkins, D., Carrel, D., "Internet Key Exchange", RFC 2409, 846 November 1998. 848 [TLS] Dierks, T., Allen, C., "The TLS Protocol Version 1.0", 849 RFC 2246, January, 1999. 851 [TRANSP] Carpenter, B., "Internet Transparency", RFC 2775, 852 February, 2000. 854 [INAT] Hain, T., "Architectural Implications of NAT", RFC 2993, 855 November, 2000. 857 [BGP4] Rekhter, Y., Li, T., "Border Gateway Protocol 4 (BGP-4)", 858 RFC 1771, March, 1995. 860 [MobileIP] Perkins, C., "IP Mobility Support", RFC 2002, 861 October, 1996. 863 [MobileIPv6] Johnson, P., Perkins, C., "Mobility Support in IPv6", 864 Work in Progress, draft-ietf-mobileip-ipv6-14.txt, July, 2001. 866 ++ [ADDIP] Stewart, et. al., "SCTP Extensions for Dynamic 867 ++ Reconfiguration of IP Addresses", Work in Progress, 868 ++ draft-ietf-tsvwg-addip-sctp-03.txt, November, 2001. 870 [HIP-ARCH] Moskowitz, B., "Host Identity Payload Architecture", 871 Work in Progress, draft-moskowitz-hip-arch-02.txt, February, 2001. 873 [PBK] Bradner, S., Mankin, A., Schiller, J., "A framework for 874 Purpose Build Keys (PBK)", Work in Progress, 875 draft-bradner-pbk-frame-00.txt, February, 2001. 877 [URN] Sollins, K., "Architectural Principles of Universal Resource 878 Name Resolution", RFC 2276, January, 1998. 880 [ESMTP] Klensin, J. (Ed), "Simple Mail Transfer Protocol", 881 RFC 2821, April, 2001. 883 9. Intellectual Property Statement 885 The IETF takes no position regarding the validity or scope of any 886 intellectual property or other rights that might be claimed to 887 pertain to the implementation or use of the technology described in 888 this document or the extent to which any license under such rights 889 might or might not be available; neither does it represent that it 890 has made any effort to identify any such rights. Information on 891 the IETF's procedures with respect to rights in standards-track and 892 standards-related documentation can be found in BCP-11. Copies of 893 claims of rights made available for publication and any assurances 894 of licenses to be made available, or the result of an attempt made 895 to obtain a general license or permission for the use of such 896 proprietary rights by implementors or users of this specification 897 can be obtained from the IETF Secretariat. 899 The IETF invites any interested party to bring to its attention any 900 copyrights, patents or patent applications, or other proprietary 901 rights which may cover technology that may be required to practice 902 this standard. Please address the information to the IETF 903 Executive Director. 905 10. Full Copyright Statement 907 Copyright (C) The Internet Society (2000). All Rights Reserved. 909 This document and translations of it may be copied and furnished to 910 others, and derivative works that comment on or otherwise explain 911 it or assist in its implementation may be prepared, copied, 912 published and distributed, in whole or in part, without restriction 913 of any kind, provided that the above copyright notice and this 914 paragraph are included on all such copies and derivative works. 915 However, this document itself may not be modified in any way, such 916 as by removing the copyright notice or references to the Internet 917 Society or other Internet organizations, except as needed for the 918 purpose of developing Internet standards in which case the 919 procedures for copyrights defined in the Internet Standards process 920 must be followed, or as required to translate it into languages 921 other than English. The limited permissions granted above are 922 perpetual and will not be revoked by the Internet Society or its 923 successors or assigns. This document and the information contained 924 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND 925 THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, 926 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 927 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 928 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 929 PARTICULAR PURPOSE." 931 11. Expiration Date 933 This memo is filed as , and expires 934 August 14, 2002.