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