idnits 2.17.1 draft-moskowitz-hip-arch-04.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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.) == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 820 has weird spacing: '...ncement to th...' -- 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 (Sep 2003) is 7500 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 792, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2766 (ref. '2') (Obsoleted by RFC 4966) == Outdated reference: A later version (-09) exists of draft-moskowitz-hip-07 == Outdated reference: A later version (-12) exists of draft-ietf-ipseckey-rr-07 == Outdated reference: A later version (-02) exists of draft-nikander-mobileip-v6-ro-sec-01 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Moskowitz 3 Internet-Draft ICSAlabs, a Division of TruSecure 4 Expires: March 1, 2004 Corporation 5 P. Nikander 6 Ericsson Research Nomadic Lab 7 Sep 2003 9 Host Identity Protocol Architecture 10 draft-moskowitz-hip-arch-04 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at http:// 27 www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on March 1, 2004. 34 Copyright Notice 36 Copyright (C) The Internet Society (2003). All Rights Reserved. 38 Abstract 40 This memo describes the reasoning behind proposing a new namespace, 41 the Host Identity namespace, and a new layer, Host Identity Layer, 42 between the internetworking and transport layers. Herein are 43 presented the basics of the current namespaces, strengths and 44 weaknesses, and how a new namespace will add completeness to them. 45 The roles of this new namespace in the protocols are defined. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 2.1 A Desire for Namespace for Computing Platforms . . . . . . . . 5 52 3. Host Identity Namespace . . . . . . . . . . . . . . . . . . . 7 53 3.1 Host Identifiers . . . . . . . . . . . . . . . . . . . . . . . 7 54 3.2 Storing Host Identifiers in DNS . . . . . . . . . . . . . . . 8 55 3.3 Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . . . 8 56 3.4 Local Scope Identity (LSI) . . . . . . . . . . . . . . . . . . 9 57 4. The New Architecture . . . . . . . . . . . . . . . . . . . . . 10 58 4.1 Transport associations and endpoints . . . . . . . . . . . . . 10 59 5. End-Host Mobility and Multi-Homing via HIP . . . . . . . . . . 12 60 5.1 Rendezvous server . . . . . . . . . . . . . . . . . . . . . . 12 61 5.2 Protection against Flooding Attacks . . . . . . . . . . . . . 13 62 6. HIP and NATs . . . . . . . . . . . . . . . . . . . . . . . . . 14 63 6.1 HIP and TCP Checksum . . . . . . . . . . . . . . . . . . . . . 14 64 7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . . 15 65 8. Benefits of HIP . . . . . . . . . . . . . . . . . . . . . . . 16 66 8.1 HIP's Answers to NSRG questions . . . . . . . . . . . . . . . 17 67 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 68 9.1 HITs used in ACLs . . . . . . . . . . . . . . . . . . . . . . 20 69 9.2 Non-security Considerations . . . . . . . . . . . . . . . . . 21 70 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 71 References (informative) . . . . . . . . . . . . . . . . . . . 23 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23 73 Intellectual Property and Copyright Statements . . . . . . . . 25 75 1. Introduction 77 The Internet has created two global namespaces: Internet Protocol 78 (IP) addresses, and Domain Name Service (DNS) names. These two 79 namespaces have a set of features and abstractions that have powered 80 the Internet to what it is today. They also have a number of 81 weaknesses. Basically, since they are all we have, we try and do too 82 much with them. Semantic overloading and functionality extensions 83 have greatly complicated these namespaces. 85 The Host Identity namespace fills an important gap between the IP and 86 DNS namespaces. The Host Identity namespace consist of Host 87 Identifiers (HI). A Host Identifier is cryptographic in its nature; 88 it is the public key of an asymmetric key-pair. A HI is assigned to 89 each host, or technically its networking kernel or stack. Each host 90 will have at least one Host Identifier, which can either be public 91 (e.g. published in DNS), or anonymous. Client systems will tend to 92 have both public and anonymous HIs. 94 Although the Host Identity can be used in many authentication 95 systems, its design principle calls out for a new protocol and 96 exchange [5] that will support limited forms of trust between 97 systems, enhance mobility, multi-homing and dynamic IP renumbering, 98 aid in protocol translation / transition, and greatly reduce denial 99 of service (DoS) attacks. 101 2. Background 103 The Internet is built from three principle components: computing 104 platforms, packet transport (i.e. internetworking) infrastructure, 105 and services (applications). The Internet exists to service two 106 principal components: people and robotic processes (silicon based 107 people, if you will). All these components need to be named in order 108 to interact in a scalable manner. 110 There are two principal namespaces in use in the Internet for these 111 components: IP numbers, and Domain Names. Email, HTTP and SIP 112 addresses are really only an extension of Domain Names. 114 IP numbers are a confounding of two namespaces, the names of the 115 networking interfaces and the names of the locations ('confounding' 116 is a term used in statistics to discuss metrics that are merged into 117 one with a gain in indexing, but a loss in informational value). The 118 names of locations should be understood as denoting routing direction 119 vectors, i.e., information that is used to deliver packets to their 120 destinations. 122 IP numbers name networking interfaces, and typically only when the 123 interface is connected to the network. Originally IP numbers had 124 long-term significance. Today, the vast number of interfaces use 125 ephemeral and/or non-unique IP numbers. That is, every time an 126 interface is connected to the network, it is assigned an IP number. 128 In the current Internet, the transport layers are coupled to the IP 129 addresses. Neither can evolve separately from the other. IPng 130 deliberations were framed by concerns of requiring a TCPng effort as 131 well. 133 Domain Names provide hierarchically assigned names for some computing 134 platforms and some services. Each hierarchy is delegated from the 135 level above; there is no anonymity in Domain Names. 137 Email addresses provide naming for both humans and autonomous 138 applications. Email addresses are extensions of Domain Names, only 139 in so far as a named service is responsible for managing a person's 140 mail. There is some anonymity in Email addresses. 142 There are three critical deficiencies with the current namespaces. 143 Firstly, dynamic readdressing cannot be directly managed. Secondly, 144 anonymity is not provided in a consistent, trustable manner. 145 Finally, authentication for systems and datagrams is not provided. 146 All because computing platforms are not well named with the current 147 namespaces. 149 2.1 A Desire for Namespace for Computing Platforms 151 An independent namespace for computing platforms could be used in 152 end-to-end operations independent of the evolution of the 153 internetworking layer and across the many internetworking layers. 154 This could support rapid readdressing of the internetworking layer 155 either from mobility or renumbering. 157 If the namespace for computing platforms is cryptographically based, 158 it can also provide authentication services for IPsec. If this 159 namespace is locally created without requiring registration, it can 160 provide anonymity. 162 Such a namespace (for computing platforms) and the names in it should 163 have the following characteristics: 165 The namespace should be applied to the IP 'kernel'. The IP kernel 166 is the 'component' between services and the packet transport 167 infrastructure. 169 The namespace should fully decouple the internetworking layer from 170 the higher layers. The names should replace all occurrences of IP 171 addresses within applications (like in the TCB). This may require 172 changes to the current APIs. In the long run, it is probable that 173 some new APIs are needed. 175 The introduction of the namespace should not mandate any 176 administrative infrastructure. Deployment must come from the 177 bottom up, in a pairwise deployment. 179 The names should have a fixed length representation, for easy 180 inclusion in datagrams and programming interfaces (e.g the TCB). 182 Using the namespace should be affordable when used in protocols. 183 This is primarily a packet size issue. There is also a 184 computational concern in affordability. 186 The names must be statistically globally unique. 64 bits is 187 inadequate (1% chance of collision in a population of 640M); thus 188 approximately 100 or more bits should be used. 190 The names should have a localized abstraction so that it can be 191 used in existing protocols and APIs. 193 It must be possible to create names locally. This can provide 194 anonymity at the cost of making resolvability very difficult. 196 Sometimes the names may contain a delegation component. This is 197 the cost of resolvability. 199 The namespace should provide authentication services. This is a 200 preferred function. 202 The names should be long lived, but replaceable at any time. This 203 impacts access control lists; short lifetimes will tend to result 204 in tedious list maintenance or require a namespace infrastructure 205 for central control of access lists. 207 In this document, such a new namespace is called the Host Identity 208 namespace. Using Host Identities requires its own protocol layer 209 (the Host Identity Protocol), between the internetworking and 210 transport layers. The names are based on public key cryptography to 211 supply authentication services. Properly designed, it can deliver all 212 of the above stated requirements. 214 3. Host Identity Namespace 216 A name in the Host Identity namespace, a Host Identifier (HI), 217 represents a statistically globally unique name for naming any system 218 with an IP stack. This identity is normally associated, but not 219 limited to, an IP stack. A system can have multiple identities, some 220 'well known', some anonymous. A system may self assert its identity, 221 or may use a third-party authenticator like DNSSEC, PGP, or X.509 to 222 'notarize' the identity assertion. DNSSEC is a "SHOULD" implement 223 authenticator for the Host Identity namespace. 225 There is a subtle but important difference between Host Identities 226 and Host Identifiers. An Identity refers to the abstract entity that 227 is identified. An Identifier, on the other hand, refers to the 228 concrete bit pattern that is used in the identification process. 230 Although a Host Identifier could be any name that can claim 231 'statistically globally unique', a public key of a 'public key' pair 232 makes the best Host Identifiers. As documented in the Host Identity 233 Protocol (HIP) specification [5], a public key based HI can 234 authenticate the HIP packets and protect them for man-in-the-middle 235 attacks. And since authenticated datagrams are mandatory to provide 236 much of HIP's DoS protection, the Diffie-Hellman exchange in HIP has 237 to be authenticated. Thus, only public key HI and authenticated 238 datagrams are supported in practice. In this document, the 239 non-cryptographic forms of HI and HIP are presented to complete the 240 theory of HI, but should not be implemented as they could produce 241 worse DoS attacks than the Internet has without HI. 243 3.1 Host Identifiers 245 Host Identity adds two main features to Internet protocols. The first 246 is a decoupling of the internetworking and transport layers, see 247 Section 4. This decoupling will allow for independent evolution of 248 the two layers. Additionally, it can provide end-to-end services 249 over multiple internetworking realms. The second feature is host 250 authentication. Because the Host Identifier is a public key, this 251 key can be used to authenticate security protocols like IPsec. 253 The only completely defined structure of the Host Identity is that of 254 a public key pair. In this case, the Host Identity is referred to by 255 its public component, the public key. Thus, the name representing a 256 Host Identity in the Host Identity namespace, i.e. the Host 257 Identifier, is the public key. In a way, the possession of the 258 private key defines the Identity itself. It the private key is 259 possessed by more than one node, the Identity can be considered to be 260 a distributed one. 262 Architecturally, any other Internet naming convention might form a 263 usable base for Host Identifiers. However, non-cryptographic names 264 should only be used in situations of high trust - low risk. That is 265 any place where host authentication is not needed (no risk of host 266 spoofing) and no use of IPsec. The current HIP documents do not 267 specify how to use any other types of Host Identifiers but public 268 keys. 270 The actual Host Identities are never directly used in any Internet 271 protocols. The corresponding Host Identifiers (public keys) may be 272 stored in various DNS or LDAP directories as identified elsewhere in 273 this document, and they are passed in the HIP protocol. A Host 274 Identity Tag (HIT) is used in other protocols to represent the Host 275 Identities. Another representation of the Host Identities, the Local 276 Scope Identity (LSI), can also be used in protocols and APIs. LSI's 277 advantage over HIT is its size; its disadvantage is its local scope. 279 3.2 Storing Host Identifiers in DNS 281 The Host Identifiers should be stored in DNS. The exception to this 282 is anonymous identities. The HI is stored in a new RR type, to be 283 defined. This RR type is likely to be very similar to the IPSECKEY 284 RR [6]. 286 Alternatively, or in addition to storing Host Identifiers in the DNS, 287 they may be stored in various kinds of Public Key Infrastructure 288 (PKI). Such a practice may allow them to be used for purposes other 289 than pure host identification. 291 3.3 Host Identity Tag (HIT) 293 A Host Identity Tag is an 128 bit representation for a Host Identity. 294 It is created by taking a cryptographic hash over the corresponding 295 Host Identifier. There are two advantages of using a hash over using 296 the Host Identifier in protocols. Firstly, its fixed length makes for 297 easier protocol coding and also better manages the packet size cost 298 of this technology. Secondly, it presents a consistent format to the 299 protocol independent of the whatever underlying identity technology 300 is used. 302 In the HIP protocol, the HITs identify the sender and recipient of a 303 packet. Consequently, a HIT should be unique in the whole IP 304 universe. In the extremely rare case that a single HIT happens to 305 map to more than one Host Identities, the Host Identifiers (public 306 keys) will make the final difference. If there is more than one 307 public key for a given node, the HIT acts as a hint for the correct 308 public key to use. 310 3.4 Local Scope Identity (LSI) 312 An LSI is a 32 bit localized representation for a Host Identity. The 313 purpose of an LSI is to facilitate using Host Identity in existing 314 protocols and APIs. The generation of LSIs is defined in [5]. 316 Examples of how LSIs can be used include: as the address in a FTP 317 command and as the address in a socket call. Thus LSIs act as a 318 bridge for Host Identifier into old protocols and APIs. 320 4. The New Architecture 322 One way to characterize Host Identity is to compare the proposed new 323 architecture with the current one. As discussed above, the IP 324 addresses can be seen to be a confounding of routing direction 325 vectors and interface names. Using the terminology from the IRTF 326 Name Space Research Group Report [7] and, e.g., the unpublished 327 Internet-Draft Endpoints and Endpoint Names [9], currently the IP 328 addresses embody the dual role of locators and endpoint identifiers. 329 That is, each IP address names a topological location in the 330 Internet, thereby acting as a routing direction vector or locator. 331 At the same time, the IP address names the physical network interface 332 currently located at the point-of-attachment, thereby acting as a 333 endpoint name. 335 In the HIP Architecture, the endpoint names and locators are 336 separated from each other. IP addresses continue to act as locators. 337 The Host Identifiers take the role of endpoint identifiers. It is 338 important to understand that the endpoint names based on Host 339 Identities are slightly different from interface names; a Host 340 Identity can be simultaneously reachable through several interfaces. 342 The difference between the bindings of the logical entities are 343 illustrated in Figure 1. 345 Process ------ Socket Process ------ Socket 346 | | 347 | | 348 | | 349 | | 350 Endpoint | Endpoint --- Host Identity 351 \ | | 352 \ | | 353 \ | | 354 \ | | 355 Location --- IP address Location --- IP address 357 Figure 1 359 4.1 Transport associations and endpoints 361 Architecturally, HIP provides for a different binding of transport 362 layer protocols. That is, the transport layer associations, i.e., 363 TCP connections and UDP associations, are no more bound to IP 364 addresses but to Host Identities. 366 It is possible that a single physical computer hosts several logical 367 end-points. With HIP, each of these end-points would have a distinct 368 Host Identity. Furthermore, since the transport associations are 369 bound to Host Identities, HIP provides for process migration and 370 clustered servers. That is, if a Host Identity is moved from one 371 physical computer to another, it is also possible to simultaneously 372 move all the transport associations without breaking them. Similarly, 373 if it is possible to distribute the processing of a single Host 374 Identity over several physical computers, HIP provides for cluster 375 based services without any changes at the client end-point. 377 5. End-Host Mobility and Multi-Homing via HIP 379 As HIP decouples the transport from the internetworking layer, and 380 binds the transport associations to the Host Identifiers (through 381 actually either the HIT or LSI), HIP can provide for a degree of 382 internetworking mobility and multi-homing at a very low 383 infrastructure cost. HIP mobility includes IP address changes (via 384 any method) to either the initiator or responder. Thus, a system is 385 considered mobile if its IP address can change dynamically for any 386 reason like PPP, DHCP, IPv6 TLA reassignments, or a NAT device 387 remapping its translation. Likewise, a system is considered 388 multi-homed if it has more than one globally routable IP address at 389 the same time. HIP allows these IP addresses to be linked with each 390 other, and if one address becomes unusable (e.g. due a network 391 failure), existing transport associations can be easily moved to 392 another address. 394 When a node moves while communication is already on-going, address 395 changes are rather straightforward. The peer of the mobile node can 396 just accept a HIP or an ESP packet from any address and totally 397 ignore the source address. As discussed in Section 5.2 below, a 398 mobile node must send a HIP readdress packet to inform the peer of 399 the new address(es), and the peer must verify that the new mobile 400 node is reachable through these addresses. This is especially 401 helpful for those situations where the peer node is sending data 402 periodically to the mobile node (that is re-starting a connection 403 after the initial connection). 405 5.1 Rendezvous server 407 Making a contact to a mobile node is slightly more involved. The 408 initiator node has to know where the mobile node is to start the HIP 409 exchange. HIP need not rely on Dynamic DNS for this function, but 410 uses a rendezvous server. Instead of registering its current dynamic 411 address to the DNS server, the mobile node registers the address of 412 the rendezvous server. The mobile node keeps the rendezvous server 413 continuously updated with its current IP address(es). The rendezvous 414 server simply forwards the initial HIP packet from an initiator to 415 the mobile node at its current location. All further packets flow 416 between the initiator and the mobile node. There is typically very 417 little activity on the rendezvous server, address updates and initial 418 HIP packet forwarding, thus one server can support a large number of 419 potential mobile nodes. The mobile nodes must trust the rendezvous 420 server to properly maintain its HIT and IP address mapping. 422 The rendezvous server is also needed if both of the nodes are mobile 423 and happen to move at the same time. In that case the HIP readdress 424 packets will cross each other in the network and never reach the peer 425 node. To solve this situation, the nodes should remember the 426 rendezvous server address, and re-send the HIP readdress packet to 427 the rendezvous server if no reply is received. 429 The mobile node keeps its address current on the rendezvous server by 430 setting up a HIP based SA with the rendezvous server and sending it 431 HIP readdress packets. A rendezvous server will permit two mobile 432 systems to use HIP without any extraneous infrastructure (in addition 433 to the rendezvous server itself), including DNSSEC if they have a 434 method other than a DNS query to get each other's HI and HIT. 436 5.2 Protection against Flooding Attacks 438 While the idea of informing about address changes by simply sending 439 packets with a new source address appears appealing, it is not secure 440 enough. That is, while receiving packets in HIP does not rely on the 441 source address for anything, it appears to be necessary to check the 442 mobile node's reachability at the new address(es) before actually 443 sending any larger amounts of traffic to the address. 445 Blindly accepting new addresses would potentially lead to a flooding 446 Denial-of-Service attack against third parties [8]. In a distributed 447 flooding attack an attacker opens (anonymous) high volume HIP 448 connections with a large number of hosts, and then claims to all of 449 these hosts that it has moved to a target node's IP address. If the 450 peer hosts were to simply accept the move, the result would be a 451 packet flood to the target node's address. To close this attack, HIP 452 includes an address check mechanism where the reachability of the 453 node is separately checked at each address before actually using the 454 address for larger amounts of traffic. 456 Whenever HIP is used between two hosts that fully trust each other, 457 the hosts may optionally decide to skip the address tests. However, 458 such performance optimization must be restricted to be performed only 459 with peers that are known to be trustworthy and capable of protecting 460 themselves from malicious software. 462 6. HIP and NATs 464 Passing packets between different IP addressing realms requires 465 changing IP addresses in the packet header. This may happen, for 466 example, when a packet is passed between the public Internet and a 467 private address space, or between IPv4 and IPv6 networks. The 468 address translation is usually implemented as Network Address 469 Translation (NAT) [3] or NAT Protocol translation (NAT-PT) [2]. 471 In a network environment where the identification is based on the IP 472 address, identifying the communicating nodes is difficult when the 473 NAT is used. With HIP, the transport layer end-points are bound to 474 the HIT or LSI. Thus, a connection between two hosts can traverse 475 many addressing realm boundaries. The IP addresses are used only for 476 routing purposes; the IP addresses may be changed freely during 477 packet traversal. 479 For a HIP based flow, a NAT or NAT-PT system needs only track the 480 mapping of the HIT or SPI to an IP address. Many HITs can map to a 481 single IP address on a NAT, simplifying connections on address poor 482 NAT interfaces. The NAT can gain much of its knowledge from the HIP 483 packets themselves; however some NAT configuration may be necessary. 485 The NAT systems cannot touch the datagrams within the ESP envelope, 486 thus application specific address translation must be done in the end 487 systems. HIP provides for 'Distributed NAT', and uses the HIT or the 488 LSI as a place holder for embedded IP addresses. 490 6.1 HIP and TCP Checksum 492 There is no way for a host to know if any of the IP addresses in the 493 IP header are the addresses used to calculate the TCP checksum. That 494 is, it is not feasible to calculate the TCP checksum using the IP 495 addresses in the pseudo header; the addresses received in the 496 incoming packet are not necessarily the same as they were on the 497 sending host. Furthermore, it is not possible to recompute the upper 498 layer checksums in the NAT/NAT-PT system, since the traffic is IPsec 499 protected. Consequently, the TCP and UDP checksums are calculated 500 using the HIT in the place of the IP addresses in the pseudo header. 502 7. HIP Policies 504 There are a number of variables that will influence the HIP exchanges 505 that each host must support. All HIP implementations should support 506 at least 2 HIs, one to publish in DNS and one for anonymous usage. 507 Although anonymous HIs will be rarely used as responder HIs, they are 508 likely be common for initiators. Support for multiple HIs is 509 recommended. 511 Many initiators would want to use a different HI for different 512 responders. The implementations should provide for a policy of 513 initiator HIT to responder HIT. This policy should also include 514 preferred transform and local lifetimes. 516 Responders would need a similar policy, representing which hosts they 517 accept HIP exchanges, and the preferred transform and local 518 lifetimes. 520 8. Benefits of HIP 522 In the beginning, the network layer protocol (i.e. IP) had the 523 following four "classic" invariants: 525 Non-mutable: The address sent is the address received. 527 Non-mobile: The address doesn't change during the course of an 528 "association". 530 Reversible: A return header can always be formed by reversing the 531 source and destination addresses. 533 Omniscient: Each host knows what address a partner host can use to 534 send packets to it. 536 Actually, the fourth can be inferred from 1 and 3, but it is worth 537 mentioning for reasons that will be obvious soon if not already. 539 In the current "post-classic" world, we are trying intentionally to 540 get rid of the second invariant (both for mobility and for 541 multi-homing), and we have been forced to give up the first and the 542 fourth. Realm Specific IP [4] is an attempt to reinstate the fourth 543 invariant without the first invariant. IPv6 is an attempt to 544 reinstate the first invariant. 546 Few systems on the Internet have DNS names that are meaningful to 547 them. That is, if they have a Fully Qualified Domain Name (FQDN), 548 that typically belongs to a NAT device or a dial-up server, and does 549 not really identify the system itself but its current connectivity. 550 FQDN names (and their extensions as email names) are Application 551 Layer names; more frequently naming processes than a particular 552 system. This is why many systems on the internet are not registered 553 in DNS; they do not have processes of interest to other Internet 554 hosts. 556 DNS names are indirect references to IP addresses. This only 557 demonstrates the interrelationship of the networking and application 558 layers. DNS, as the Internet's only deployed, distributed, database 559 is also the repository of other namespaces, due in part to DNSSEC and 560 KEY records. Although each namespace can be stretched (IP with v6, 561 DNS with KEY records), neither can adequately provide for host 562 authentication or act as a separation between internetworking and 563 transport layers. 565 The Host Identity (HI) namespace fills an important gap between the 566 IP and DNS namespaces. An interesting thing about the HI is that it 567 actually allows one to give-up all but the 3rd Network Layer 568 invariant. That is to say, as long as the source and destination 569 addresses in the network layer protocol are reversible, then things 570 work ok because HIP takes care of host identification, and 571 reversibility allows one to get a packet back to one's partner host. 572 You don't care if the network layer address changes in transit 573 (mutable) and you don't care what network layer address the partner 574 is using (non-omniscient). 576 Since all systems can have a Host Identity, every system can have an 577 entry in the DNS. The mobility features in HIP make it attractive to 578 trusted 3rd parties to offer rendezvous servers. 580 8.1 HIP's Answers to NSRG questions 582 The IRTF Name Space Research Group has posed a number of evaluating 583 questions in their report [7]. In this section, we provide answers 584 to these questions. 586 1. How would a stack name improve the overall functionality of the 587 Internet? 589 The HIP Host Identifiers make end-host mobility and 590 multi-homing easier by separating the transport layer and 591 internetworking layer from each other. Among other things, 592 this allows mobility and multi-homing across the IPv4 and IPv6 593 internets. Host Identifiers also make network re-numbering 594 easier. At the conceptual level, they also make process 595 migration and clustered servers easier to implement. 596 Furthermore, being cryptographic in nature, they also provide 597 the basis for solving the security problems related to 598 end-host mobility and multi-homing. 600 2. What does a stack name look like? 602 A HIP Host Identifier is a cryptographic public key. However, 603 instead of using the keys directly, most protocols use a fixed 604 size hash of the public key. 606 3. What is its lifetime? 608 HIP provides both stable and temporary Host Identifiers. 609 Stable Host Identifiers are typically long lived, with a 610 lifetime of years or more. The lifetime of temporary Host 611 Identifiers depends on how long the upper layer connections 612 and applications need them, and can range from a few seconds 613 to years. 615 4. Where does it live in the stack? 617 The HIP Host Identifiers live between the transport and 618 internetworking layers. 620 5. How is it used on the end points 622 The HIP Host Identifiers, in the form of HITs or LSIs, are 623 used by legacy applications as if they were IP addresses. 624 Additionally, the Host Identifiers, as public keys, are used 625 in a built in key agreement protocol to authenticate the 626 Diffie-Hellman key exchange. 628 6. What administrative infrastructure is needed to support it? 630 It is possible to use HIP opportunistically, without any 631 infrastructure. However, to gain full benefit from HIP, the 632 Host Identifiers must be stored in the DNS, and a new 633 infrastructure of Rendezvous servers is needed. 635 7. If we add an additional layer would it make the address list in 636 SCTP unnecessary? 638 Yes 640 8. What additional security benefits would a new naming scheme 641 offer? 643 HIP reduces dependency on IP addresses, making the so called 644 address ownership problems easier to solve. In practice, HIP 645 provides security for end-host mobility and multi-homing. 646 Furthermore, since HIP Host Identifiers are public keys, 647 standard public key certificate infrastructures can be applied 648 on the top of HIP. 650 9. What would the resolution mechanisms be, or what characteristics 651 of a resolution mechanisms would be required? 653 For most purposes, an approach where DNS names are resolved 654 simultaneously to Host Identifiers and IP addresses is 655 sufficient. However, if it becomes necessary to resolve Host 656 Identifiers into IP addresses or back to DNS names, a flat, 657 hash based resolution infrastructure is needed. Such an 658 infrastructure could be based on the ideas of Distributed Hash 659 Tables, but would require significant new development and 660 deployment. 662 9. Security Considerations 664 HIP takes advantage of the new Host Identity paradigm to provide 665 secure authentication of hosts and provide a fast key exchange for 666 IPsec ESP. HIP also attempts to limit the exposure of the host to 667 various denial-of-service (DoS) and man-in-the-middle (MitM) attacks. 668 In so doing, HIP itself is subject to its own DoS and MitM attacks 669 that potentially could be more damaging to a host's ability to 670 conduct business as usual. 672 The Security Association for ESP is indexed by the SPI; the source 673 address is always ignored, and the destination address may be ignored 674 as well. Therefore, HIP enabled ESP is IP address independent. This 675 might seem to make it easier for an attacker, but ESP with replay 676 protection is already as well protected as possible, and the removal 677 of the IP address as a check should not increase the exposure of ESP 678 to DoS attacks. 680 Denial-of-service attacks take advantage of the cost of setting up a 681 state for a protocol on the responder compared to the 'cheapness' on 682 the initiator. HIP both allows to increase the cost of the start of 683 state on the initiator and makes an effort to reduce the cost to the 684 responder. This is done by having the responder start the 685 authenticated Diffie-Hellman protocol instead of the initiator, 686 making the HIP protocol 4 packets long. There are more details on 687 this process in the HIP protocol specification [5]. 689 HIP optionally supports opportunistic negotiation. That is, if a 690 host receives a start of transport without a HIP negotiation, it can 691 attempt to force a HIP exchange before accepting the connection. 692 This has the potential for DoS attacks against both hosts. If the 693 method to force the start of HIP is expensive on either host, the 694 attacker need only spoof a TCP SYN. This would put both systems into 695 the expensive operations. HIP avoids this attack by having the 696 responder send a simple HIP packet that it can pre-build. Since this 697 packet is fixed and easily spoofed, the initiator only reacts to it 698 if it has just started a connection to the responder. 700 Man-in-the-middle attacks are difficult to defend against, without 701 third-party authentication. A skillful MitM could easily handle all 702 parts of the HIP protocol, but HIP indirectly provides the following 703 protection from a MitM attack. If the responder's HI is retrieved 704 from a signed DNS zone or secured by some other means by the 705 initiator, the initiator can use this to validate the signed HIP 706 packets. 708 Likewise, if the initiator's HI is in a secure DNS zone, the 709 responder can retrieve it and validate the signed HIP packets. 711 However, since an initiator may choose to use an anonymous HI, it 712 knowingly risks a MitM attack. The responder may choose not to 713 accept a HIP exchange with an anonymous initiator. 715 Since not all hosts will ever support HIP, ICMP 'Destination Protocol 716 Unreachable' are to be expected and present a DoS attack. Against an 717 initiator, the attack would look like the responder does not support 718 HIP, but shortly after receiving the ICMP message, the initiator 719 would receive a valid HIP packet. Thus, to protect against this 720 attack, an initiator should not react to an ICMP message until a 721 reasonable delta time to get the real responder's HIP packet. A 722 similar attack against the responder is more involved. 724 Another MitM attack is simulating a responder's rejection of a HIP 725 initiation. This is a simple ICMP Protocol Unreachable, 726 Administratively Prohibited message. A HIP packet is not used 727 because it would either have to have unique content, and thus 728 difficult to generate, resulting in yet another DoS attack, or just 729 as spoofable as the ICMP message. The defense against this MitM 730 attack is for the responder to wait a reasonable time period to get a 731 valid HIP packet. If one does not come, then the Initiator has to 732 assume that the ICMP message is valid. Since this is the only point 733 in the HIP exchange where this ICMP message is appropriate, it can be 734 ignored at any other point in the exchange. 736 9.1 HITs used in ACLs 738 It is expected that HITs will be used in ACLs. Future firewalls can 739 use HITs to control egress and ingress to networks, with an assurance 740 difficult to achieve today. 742 There has been considerable bad experience with distributed ACLs that 743 contain public key related material, for example, with SSH. If the 744 owner of the key needs to revoke it for any reason, the task of 745 finding all locations where the key is held in an ACL may be 746 impossible. If the reason for the revocation is due to private key 747 theft, this could be a serious issue. 749 A host can keep track of all of its partners that might use its HIT 750 in an ACL by logging all remote HITs. It should only be necessary to 751 log responder hosts. With this information, the host can notify the 752 various hosts about the change to the HIT. There has been no attempt 753 here to develop a secure method (like in CMP and CMC) to issue the 754 HIT revocation notice. 756 NATs, however, are transparent to the HIP aware systems by design. 757 Thus, the host may find it difficult to notify any NAT that is using 758 a HIT in an ACL. Since most systems will know of the NATs for their 759 network, there should be a process by which they can notify these 760 NATs of the change of the HIT. This is mandatory for systems that 761 function as responders behind a NAT. In a similar vein, if a host is 762 notified of a change in a HIT of an initiator, it should notify its 763 NAT of the change. In this manner, NATs will get updated with the 764 HIT change. 766 9.2 Non-security Considerations 768 The definition of the Host Identifier states that the HI need not be 769 a public key. It implies that the HI could be any value; for example 770 an FQDN. This document does not describe how to support a 771 non-cryptographic HI. Such a HI would still offer the services of 772 the HIT or LSI for NAT traversal. It would carry the HITs or LSIs in 773 a HIP packets that had neither privacy nor authentication. Since 774 such a mode would offer so little additional functionality for so 775 much addition to the IP kernel, it has not been defined. Given how 776 little public key cryptography HIP requires, HIP should only be 777 implemented using public key Host Identities. 779 10. Acknowledgments 781 For the people historically involved in the early stages of HIP, see 782 the Acknowledgements section in [5]. 784 During the later stages of this document, when the editing baton was 785 transfered to Pekka Nikander, the comments from the early 786 implementors and others, including Jari Arkko, Tom Henderson, Petri 787 Jokela, Miika Komu, Mika Kousa, Andrew McGregor, Jan Melen, Tim 788 Shepard, Jukka Ylitalo, and Jorma Wall, were invaluable. 790 References (informative) 792 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 793 Levels", BCP 14, RFC 2119, March 1997. 795 [2] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - 796 Protocol Translation (NAT-PT)", RFC 2766, February 2000. 798 [3] Srisuresh, P. and K. Egevang, "Traditional IP Network Address 799 Translator (Traditional NAT)", RFC 3022, January 2001. 801 [4] Borella, M., Lo, J., Grabelsky, D. and G. Montenegro, "Realm 802 Specific IP: Framework", RFC 3102, October 2001. 804 [5] Moskowitz, R., Nikander, P. and P. Jokela, "Host Identity 805 Protocol", draft-moskowitz-hip-07 (work in progress), June 2003. 807 [6] Richardson, M., "A method for storing IPsec keying material in 808 DNS", draft-ietf-ipseckey-rr-07 (work in progress), September 809 2003. 811 [7] Lear, E. and R. Droms, "What's In A Name:Thoughts from the 812 NSRG", draft-irtf-nsrg-report-10 (work in progress), September 813 2003. 815 [8] Nikander, P., "Mobile IP version 6 Route Optimization Security 816 Design Background", draft-nikander-mobileip-v6-ro-sec-01 (work 817 in progress), July 2003. 819 [9] Chiappa, J., "Endpoints and Endpoint Names: A Proposed 820 Enhancement to the Internet Architecture", URL http:// 821 users.exis.net/~jnc/tech/endpoints.txt, 1999. 823 Authors' Addresses 825 Robert Moskowitz 826 ICSAlabs, a Division of TruSecure Corporation 827 1000 Bent Creek Blvd, Suite 200 828 Mechanicsburg, PA 829 USA 831 EMail: rgm@icsalabs.com 832 Pekka Nikander 833 Ericsson Research Nomadic Lab 835 JORVAS FIN-02420 836 FINLAND 838 Phone: +358 9 299 1 839 EMail: pekka.nikander@nomadiclab.com 841 Intellectual Property Statement 843 The IETF takes no position regarding the validity or scope of any 844 intellectual property or other rights that might be claimed to 845 pertain to the implementation or use of the technology described in 846 this document or the extent to which any license under such rights 847 might or might not be available; neither does it represent that it 848 has made any effort to identify any such rights. Information on the 849 IETF's procedures with respect to rights in standards-track and 850 standards-related documentation can be found in BCP-11. Copies of 851 claims of rights made available for publication and any assurances of 852 licenses to be made available, or the result of an attempt made to 853 obtain a general license or permission for the use of such 854 proprietary rights by implementors or users of this specification can 855 be obtained from the IETF Secretariat. 857 The IETF invites any interested party to bring to its attention any 858 copyrights, patents or patent applications, or other proprietary 859 rights which may cover technology that may be required to practice 860 this standard. Please address the information to the IETF Executive 861 Director. 863 Full Copyright Statement 865 Copyright (C) The Internet Society (2003). All Rights Reserved. 867 This document and translations of it may be copied and furnished to 868 others, and derivative works that comment on or otherwise explain it 869 or assist in its implementation may be prepared, copied, published 870 and distributed, in whole or in part, without restriction of any 871 kind, provided that the above copyright notice and this paragraph are 872 included on all such copies and derivative works. However, this 873 document itself may not be modified in any way, such as by removing 874 the copyright notice or references to the Internet Society or other 875 Internet organizations, except as needed for the purpose of 876 developing Internet standards in which case the procedures for 877 copyrights defined in the Internet Standards process must be 878 followed, or as required to translate it into languages other than 879 English. 881 The limited permissions granted above are perpetual and will not be 882 revoked by the Internet Society or its successors or assignees. 884 This document and the information contained herein is provided on an 885 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 886 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 887 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 888 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 889 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 891 Acknowledgement 893 Funding for the RFC Editor function is currently provided by the 894 Internet Society.