idnits 2.17.1 draft-moskowitz-hip-arch-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 803 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 (April 2003) is 7681 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 773, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 785, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2766 (ref. '2') (Obsoleted by RFC 4966) ** Downref: Normative reference to an Informational RFC: RFC 3022 (ref. '3') ** Downref: Normative reference to an Experimental RFC: RFC 3102 (ref. '4') -- Possible downref: Normative reference to a draft: ref. '5' == Outdated reference: A later version (-09) exists of draft-moskowitz-hip-05 -- Possible downref: Normative reference to a draft: ref. '6' == Outdated reference: A later version (-12) exists of draft-ietf-ipseckey-rr-01 == Outdated reference: A later version (-10) exists of draft-irtf-nsrg-report-09 ** Downref: Normative reference to an Informational draft: draft-irtf-nsrg-report (ref. '8') == Outdated reference: A later version (-02) exists of draft-nikander-mobileip-v6-ro-sec-00 -- Possible downref: Normative reference to a draft: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' Summary: 7 errors (**), 0 flaws (~~), 9 warnings (==), 6 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: September 30, 2003 Corporation 5 P. Nikander 6 Ericsson Research Nomadic Lab 7 April 2003 9 Host Identity Protocol Architecture 10 draft-moskowitz-hip-arch-03 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 September 30, 2003. 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 This new namespace's roles 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) . . . . . . . . . . . . . . . . . . 8 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 References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 72 Intellectual Property and Copyright Statements . . . . . . . . 24 74 1. Introduction 76 The Internet has created two global namespaces: Internet Protocol 77 (IP) addresses, and Domain Name Services (DNS) names. These two 78 namespaces have a set of features and abstractions that have powered 79 the Internet to what it is today. They also have a number of 80 weaknesses. Basically, since they are all we have, we try and do too 81 much with them. Semantic overloading and functionality extensions 82 have greatly complicated these namespaces. 84 The Host Identity namespace fills an important gap between the IP and 85 DNS namespaces. The Host Identity namespace consist of Host 86 Identifiers (HI). A Host Identifier is cryptographic in its nature; 87 it is the public key of an asymmetric key-pair. A HI is assigned to 88 each host, or technically it's networking kernel or stack. Each host 89 will have at least one Host Identifier, which can either be public 90 (e.g. published in DNS), or anonymous. Client systems will tend to 91 have both public and anonymous HIs. 93 Although the Host Identity can be used in many authentication 94 systems, its design principle calls out for a new protocol and 95 exchange [6] that will support limited forms of trust between 96 systems, enhance mobility, multi-homing and dynamic IP renumbering, 97 aid in protocol translation / transition, and greatly reduce denial 98 of service (DoS) attacks. 100 2. Background 102 The Internet is built from three principle components: computing 103 platforms, packet transport (i.e. internetworking) infrastructure, 104 and services (applications). The Internet exists to service two 105 principal components: people and robotic processes (silicon based 106 people, if you will). All these components need to be named in order 107 to interact in a scalable manner. 109 There are two principal namespaces in use in the Internet for these 110 components: IP numbers, and Domain Names. Email and SIP addresses 111 are really only an extension of Domain Names. 113 IP numbers are a confounding of two namespaces, the names of the 114 networking interfaces and the names of the locations ('confounding' 115 is a term used in statistics to discuss metrics that are merged into 116 one with a gain in indexing, but a loss in informational value). The 117 names of locations should be understood as denoting routing direction 118 vectors, i.e., information that is used to deliver packets to their 119 destinations. 121 IP numbers name networking interfaces, and typically only when the 122 interface is connected to the network. Originally IP numbers had 123 long-term significance. Today, the vast number of interfaces use 124 ephemeral and/or non-unique IP numbers. That is, every time an 125 interface is connected to the network, it is assigned an IP number. 127 In the current Internet, the transport layers are coupled to the IP 128 addresses. Neither can evolve separately from the other. IPng 129 deliberations were framed by concerns of requiring a TCPng effort as 130 well. 132 Domain Names provide hierarchically assigned names for some computing 133 platforms and some services. Each hierarchy is delegated from the 134 level above; there is no anonymity in Domain Names. 136 Email addresses provide naming for both carbon and silicon based 137 people. Email addresses are extensions of Domain Names, only in so 138 far as a named service is responsible for managing a person's mail. 139 There is some anonymity in Email addresses. 141 There are three critical deficiencies with the current namespaces. 142 Dynamic readdressing cannot be directly managed. Anonymity is not 143 provided in a consistent, trustable manner. And authentication for 144 systems and datagrams is not provided. All because computing 145 platforms are not well named with the current namespaces. 147 2.1 A Desire for Namespace for Computing Platforms 149 An independent namespace for computing platforms could be used in 150 end-to-end operations independent of the evolution of the 151 internetworking layer and across the many internetworking layers. 152 This could support rapid readdressing of the internetworking layer 153 either from mobility or renumbering. 155 If the namespace for computing platforms is cryptographically based, 156 it can also provide authentication services for IPsec. If this 157 namespace is locally created without requiring registration, it can 158 provide anonymity. 160 Such a namespace (for computing platforms) and the names in it should 161 have the following characteristics: 163 The namespace should be applied to the IP 'kernel'. The IP kernel 164 is the 'component' between services and the packet transport 165 infrastructure. 167 The namespace should fully decouple the internetworking layer from 168 the higher layers. The names should replace all occurrences of IP 169 addresses within applications (like in the TCB). This may require 170 changes to the current APIs. In the long run, it is probable that 171 some new APIs are needed. 173 The introduction of the namespace should not mandate any 174 administrative infrastructure. Deployment must come from the 175 bottom up, in a pairwise deployment. 177 The names should have a fixed length representation, for easy 178 inclusion in datagrams and programming interfaces (e.g the TCB). 180 Using the namespace should be affordable when used in protocols. 181 This is primarily a packet size issue. There is also a 182 computational concern in affordability. 184 The names must be statistically globally unique. 64 bits is 185 inadequate (1% chance of collision in a population of 640M); thus 186 approximately 100 or more bits should be used. 188 The names should have a localized abstraction so that it can be 189 used in existing protocols and APIs. 191 It must be possible to create names locally. This can provide 192 anonymity at the cost of making resolvability very difficult. 194 Sometimes the names may contain a delegation component. This is 195 the cost of resolvability. 197 The namespace should provide authentication services. This is a 198 preferred function. 200 The names should be long lived, but replaceable at any time. This 201 impacts access control lists; short lifetimes will tend to result 202 in tedious list maintenance or require a namespace infrastructure 203 for central control of access lists. 205 In this document, such a new namespace is called the Host Identity 206 namespace. Using Host Identities requires its own protocol layer 207 (the Host Identity Protocol), between the internetworking and 208 transport layers. The names are based on Public Key Cryptography to 209 supply authentication services. Properly designed, it can deliver all 210 of the above stated requirements. 212 3. Host Identity Namespace 214 A name in the Host Identity namespace, a Host Identifier (HI), 215 represents a statistically globally unique name for naming any system 216 with an IP stack. This identity is normally associated, but not 217 limited to, an IP stack. A system can have multiple identities, some 218 'well known', some anonymous. A system may self assert its identity, 219 or may use a third-party authenticator like DNSSEC, PGP, or X.509 to 220 'notarize' the identity assertion. DNSSEC is a "SHOULD" implement 221 authenticator for the Host Identity namespace. 223 There is a subtle but important difference between Host Identities 224 and Host Identifiers. An Identity refers to the abstract entity that 225 is identified. An Identifier, on the other hand, refers to the 226 concrete bit pattern that is used in the identification process. 228 Although a Host Identifier can be any name that can claim 229 'statistically globally unique', a public key of a 'public key' pair 230 makes the best Host Identifiers. As documented in the Host Identity 231 Protocol (HIP) specification [6], a public key based HI can 232 authenticate the HIP packets and protect them for man-in-the-middle 233 attacks. And since authenticated datagrams are mandatory to provide 234 much of HIP's DoS protection, the Diffie-Hellman exchange in HIP has 235 to be authenticated. Thus, only public key HI and authenticated 236 datagrams are supported in practice. The non-cryptographic forms of 237 HI and HIP are presented to complete the theory of HI, but should not 238 be implemented as they could produce worse DoS attacks than the 239 Internet has without HI. 241 3.1 Host Identifiers 243 Host Identity adds two main features to Internet protocols. The 244 first is a decoupling of the internetworking and transport layers, 245 see Section 4. This decoupling will allow for independent evolution 246 of the two layers. Additionally, it can provide end-to-end services 247 over multiple internetworking realms. The second feature is host 248 authentication. Whenever the Host Identifier is a public key, this 249 key can be used to authenticate security protocols like IPsec. 251 The preferred structure of the Host Identity is that of a public key 252 pair. In that case the Host Identity is referred to by its public 253 component, the public key. Thus, the name representing the Host 254 Identity in the Host Identity namespace, i.e. the Host Identifier, is 255 the public key. In a way, the possession of the private key defines 256 the Identity itself. It the private key is possessed by more than 257 one node, the Identity can be considered to be a distributed one. 259 Any other Internet naming convention may be used for the Host 260 Identifiers. However, these should only be used in situations of 261 high trust - low risk. That is any place where host authentication 262 is not needed (no risk of host spoofing) and no use of IPsec. 264 The actual Host Identities are never directly used in any Internet 265 protocols. The corresponding Host Identifiers (public keys) may be 266 stored in various DNS or LDAP directories as identified elsewhere in 267 this document, and they are passed in the HIP protocol. A Host 268 Identity Tag (HIT) is used in other protocols to represent the Host 269 Identities. Another representation of the Host Identities, the Local 270 Scope Identity (LSI), can also be used in protocols and APIs. LSI's 271 advantage over HIT is its size; its disadvantage is its local scope. 273 3.2 Storing Host Identifiers in DNS 275 The Host Identifiers should be stored in DNS. The exception to this 276 is anonymous identities. The HI is stored in a new RR type, to be 277 defined. This RR type is likely to be very similar to the IPSECKEY 278 RR [7]. 280 Alternatively, or in addition to storing Host Identifiers in the DNS, 281 they may be stored in various kinds of Public Key Infrastructure 282 (PKI). Such a practice may allow them to be used for purposes other 283 than pure host identification. 285 3.3 Host Identity Tag (HIT) 287 A Host Identity Tag is an 128 bit representation for a Host Identity. 288 It is created by taking a cryptographic hash over the corresponding 289 Host Identifier. There are two advantages of using a hash over using 290 the Host Identifier in protocols. Firstly, its fixed length makes 291 for easier protocol coding and also better manages the packet size 292 cost of this technology. Secondly, it presents a consistent format 293 to the protocol independent of the whatever underlying identity 294 technology is used. 296 When the Host Identity is a public key pair, HIT functions much like 297 the SPI does in IPsec. However, instead of being an arbitrary 32-bit 298 value used to identify the Security Association for a datagram, a HIT 299 identifies the public key pair that can validate the packet 300 authentication. HIT should be unique in the whole IP universe. In 301 the rare case that a single HIT happens to map to more than one Host 302 Identities, the Host Identifiers (public keys) will make the final 303 difference. If there is more than one public key for a given node, 304 the HIT acts as a hint for the correct public key to use. 306 3.4 Local Scope Identity (LSI) 307 An LSI is a 32 bit localized representation for a Host Identity. The 308 purpose of an LSI is to facilitate using Host Identity in existing 309 protocols and APIs. The generation of LSI is to be determined; two 310 candidate solutions are to let the peer pick its incoming LSI (like 311 IPsec SPI) or to use a 32-bit subset of the HIT. 313 Examples of how LSIs can be used include: as the address in a FTP 314 command and as the address in a socket call. Thus LSIs act as a 315 bridge for Host Identifier into old protocols and APIs. 317 4. The New Architecture 319 One way to characterize Host Identity is to compare the proposed new 320 architecture with the current one. As discussed above, the IP 321 addresses can be seen to be a confounding of routing direction 322 vectors and interface names. Using the terminology from the IRTF 323 Name Space Research Group Report [8] and, e.g., the unpublished 324 Internet-Draft Endpoints and Endpoint Names [10], currently the IP 325 addresses embody the dual role of locators and endpoint identifiers. 326 That is, each IP address names a topological location in the 327 Internet, thereby acting as a routing direction vector or locator. 328 At the same time, the IP address names the physical network interface 329 currently located at the point-of-attachment, thereby acting as a 330 endpoint name. 332 In the HIP Architecture, the endpoint names and locators are 333 separated from each other. IP addresses continue to act as locators. 334 The Host Identities take the role of endpoint identifiers. It is 335 important to understand that the endpoint names based on Host 336 Identities are slightly different from interface names; a Host 337 Identity can be simultaneously reachable through several interfaces. 339 The difference between the bindings of the logical entities are 340 illustrated in Figure 1. 342 Process ------ Socket Process ------ Socket 343 | | 344 | | 345 | | 346 | | 347 Endpoint | Endpoint --- Host Identity 348 \ | | 349 \ | | 350 \ | | 351 \ | | 352 Location --- IP address Location --- IP address 354 Figure 1 356 4.1 Transport associations and endpoints 358 Architecturally, HIP provides for a different binding of transport 359 layer protocols. That is, the transport layer associations, i.e., 360 TCP connections and UDP associations, are no more bound to IP 361 addresses but to Host Identities. 363 It is possible that a single physical computer hosts several logical 364 end-points. With HIP, each of these end-points would have a distinct 365 Host Identity. Furthermore, since the transport associations are 366 bound to Host Identities, HIP provides for process migration and 367 clustered servers. That is, if a Host Identity is moved from one 368 physical computer to another, it is also possible to simultaneously 369 move all the transport associations without breaking them. 370 Similarly, if it is possible to distribute the processing of a single 371 Host Identity over several physical computers, HIP provides for 372 cluster based services without any changes at the client end-point. 374 5. End-Host Mobility and Multi-Homing via HIP 376 As HIP decouples the transport from the internetworking layer, and 377 binds the transport associations to the Host Identifiers (through 378 actually either the HIT or LSI), HIP can provide for a degree of 379 internetworking mobility and multi-homing at a very low 380 infrastructure cost. HIP internetworking mobility includes IP 381 address changes (via any method) to either the initiator or 382 responder. Thus, a system is considered mobile if its IP address can 383 change dynamically for any reason like PPP, DHCP, IPv6 TLA 384 reassignments, or a NAT remapping its translation. Likewise, a 385 system is considered multi-homed if it has more than one globally 386 routable IP address at the same time. HIP allows these IP addresses 387 to be linked with each other, and if one address becomes unusable 388 (e.g. due a network failure), existing transport associations can be 389 easily moved to another address. 391 When a node moves while communication is already on-going, address 392 changes are rather straightforward. The peer of the mobile node can 393 just accept a HIP or an ESP packet from any address and totally 394 ignore the source address for anything more than transmitting return 395 packets. However, as discussed in Section 5.2 below, the mobile node 396 must send a HIP readdress packet to inform the peer of the new 397 address(es) of the mobile node, and the peer must verify that the new 398 addresses are reachable. This is especially helpful for those 399 situations where the peer node is sending data periodically to the 400 mobile node (that is re-starting a connection after the initial 401 connection). 403 5.1 Rendezvous server 405 Making a contact to a mobile node is slightly more involved. The 406 initiator node has to know where the mobile node is to start the HIP 407 exchange. HIP need not rely on Dynamic DNS for this function, but 408 uses a rendezvous server. Instead of registering its current dynamic 409 address to the DNS server, the mobile node registers the address of 410 the rendezvous server. The mobile node keeps the rendezvous server 411 continuously updated with its current IP address(es). The rendezvous 412 server simply forwards the initial HIP packet from an initiator to 413 the mobile node at its current location. All further packets flow 414 between the initiator and the mobile node. There is typically very 415 little activity on the rendezvous server, address updates and initial 416 HIP packet forwarding, thus one server can support a large number of 417 potential mobile nodes. The mobile nodes must trust the rendezvous 418 server to properly maintain its HIT and IP address mapping. 420 The rendezvous server is also needed if both of the nodes are mobile 421 and happen to move at the same time. In that case the HIP readdress 422 packets will cross each other in the network and never reach the peer 423 node. To solve this situation, the nodes should remember the 424 rendezvous server address, and re-send the HIP readdress packet to 425 the rendezvous server if no reply is received. 427 The mobile node keeps its address current on the rendezvous server by 428 setting up a HIP based SA with the rendezvous server and sending it 429 HIP readdress packets. A rendezvous server will permit two mobile 430 systems to use HIP without any extraneous infrastructure, including 431 DNSSEC if they have a method other than a DNS query to get each 432 other's HI and HIT. 434 5.2 Protection against Flooding Attacks 436 In an earlier version of this document the nodes were permitted to 437 inform about address changes by simply sending packets with a new 438 source address. While receiving packets in HIP still does not rely 439 on the source address for anything, it appears to be necessary to 440 check the mobile node's reachability at the new address(es) before 441 actually sending any larger amounts of traffic to the address. 443 Blindly accepting new addresses would potentially lead to a flooding 444 Denial-of-Service attack against third parties [9]. In a distributed 445 flooding attack an attacker opens (anonymous) high volume HIP 446 connections with a large number of hosts, and then claims to all of 447 these hosts that it has moved to a target node's IP address. If the 448 peer hosts were to simply accept the move, the result would be a 449 packet flood to the target node's address. To close this attack, HIP 450 includes an address check mechanism where the reachability of the 451 node is separately checked at each address before actually using the 452 address for larger amounts of traffic. 454 Whenever HIP is used between two hosts that fully trust each other, 455 the hosts may optionally decide to skip the address tests. However, 456 such performance optimization must be restricted to be performed only 457 with peers that are known to be trustworthy and capable of protecting 458 themselves from malicious software. 460 6. HIP and NATs 462 Passing packets between different IP addressing realms requires 463 changing IP addresses in the packet header. This may happen, for 464 example, when a packet is passed between the public Internet and a 465 private address space, or between IPv4 and IPv6 networks. The 466 address translation is usually implemented as Network Address 467 Translation (NAT) [3] or NAT Protocol translation (NAT-PT) [2]. 469 In a network environment where the identification is based on the IP 470 address, identifying the communicating nodes is difficult when the 471 NAT is used. With HIP, the transport layer end-points are bound to 472 the HIT or LSI. Thus, a connection between two hosts can traverse 473 many addressing realm boundaries. The IP addresses are used only for 474 routing purposes; the IP addresses may be changed freely during 475 packet traversal. 477 For a HIP based flow, a NAT or NAT-PT system needs only track the 478 mapping of the HIT or SPI to an IP address. Many HITs can map to a 479 single IP address on a NAT, simplifying connections on address poor 480 NAT interfaces. The NAT can gain much of its knowledge from the HIP 481 packets themselves; however some NAT configuration may be necessary. 483 The NAT systems cannot touch the datagrams within the ESP envelope, 484 thus application specific address translation must be done in the end 485 systems. HIP provides for 'Distributed NAT', and uses the HIT or the 486 LSI as a place holder for embedded IP addresses. 488 6.1 HIP and TCP Checksum 490 There is no way for a host to know if any of the IP addresses in the 491 IP header are the addresses used to calculate the TCP Checksum. That 492 is, it is not feasible to calculate the TCP checksum using the IP 493 addresses in the pseudo header; the addresses received in the 494 incoming packet are not necessarily the same as they were on the 495 sending host. Furthermore, it is not possible to recompute the upper 496 layer checksums in the NAT/NAT-PT system, since the traffic is IPsec 497 protected. Consequently, the TCP and UDP checksums are calculated 498 using the HIT (or some other representation of the HI) in the place 499 of the IP addresses in the pseudo header. 501 7. HIP Policies 503 There are a number of variables that will influence the HIP exchanges 504 that each host must support. All HIP implementations should support 505 at least 2 HIs, one to publish in DNS and one for anonymous usage. 506 Although anonymous HIs will be rarely used as responder HIs, they are 507 likely be common for initiators. Support for multiple HIs is 508 recommended. 510 Many initiators would want to use a different HI for different 511 responders. The implementations should provide for a policy of 512 initiator HIT to responder HIT. This policy should also include 513 preferred transform and local lifetimes. 515 Responders would need a similar policy, representing which hosts they 516 accept HIP exchanges, and the preferred transform and local 517 lifetimes. 519 8. Benefits of HIP 521 In the beginning, the network layer protocol (i.e. IP) had the 522 following four "classic" invariants: 524 Non-mutable: The address sent is the address received. 526 Non-mobile: The address doesn't change during the course of an 527 "association". 529 Reversible: A return header can always be formed by reversing the 530 source and destination addresses. 532 Omniscient: Each host knows what address a partner host can use to 533 send packets to it. 535 Actually, the fourth can be inferred from 1 and 3, but it is worth 536 mentioning for reasons that will be obvious soon if not already. 538 In the current "post-classic" world, we are trying intentionally to 539 get rid of the second invariant (both for mobility and for 540 multi-homing), and we have been forced to give up the first and the 541 fourth. Realm Specific IP [4] is an attempt to reinstate the fourth 542 invariant without the first invariant. IPv6 is an attempt to 543 reinstate the first invariant. 545 Few systems on the Internet have DNS names, or more specifically, 546 Fully Qualified Domain Names (FQDN). FQDN names (and their 547 extensions as email names) are Application Layer names; more 548 frequently naming processes than a particular system. This is why 549 most systems on the internet are not registered in DNS; they do not 550 have processes of interest to other Internet hosts. 552 DNS names are indirect references to IP addresses. This only 553 demonstrates the interrelationship of the networking and application 554 layers. DNS, as the Internet's only deployed, distributed, database 555 is also the repository of other namespaces, due in part to DNSSEC and 556 KEY records. Although each namespace can be stretched (IP with v6, 557 DNS with KEY records), neither can adequately provide for host 558 authentication or act as a separation between internetworking and 559 transport layers. 561 The Host Identity (HI) namespace fills an important gap between the 562 IP and DNS namespaces. An interesting thing about the HI is that it 563 actually allows one to give-up all but the 3rd Network Layer 564 invariant. That is to say, as long as the source and destination 565 addresses in the network layer protocol are reversible, then things 566 work ok because HIP takes care of host identification, and 567 reversibility allows one to get a packet back to one's partner host. 568 You don't care if the NLP changes in transit (mutable) and you don't 569 care what NLP the partner is using (non-omniscient). 571 Since all systems can have a Host Identity, every system can have an 572 entry in the DNS. The mobility features in HIP make it attractive to 573 trusted 3rd parties to offer rendezvous servers. 575 8.1 HIP's Answers to NSRG questions 577 The IRTF Name Space Research Group has posed a number of evaluating 578 questions in their report [8]. In this section, we provide answers 579 to these questions. 581 1. How would a stack name improve the overall functionality of the 582 Internet? 584 The HIP Host Identifiers make end-host mobility and 585 multi-homing easier by separating the transport layer and 586 internetworking layer from each other. Among other things, 587 this allows mobility and multi-homing accross the IPv4 and 588 IPv6 internets. They also make network re-numbering easier. 589 At the conceptual level, they also make process migration and 590 clustered servers easier to implement. Furthermore, being 591 cryptographic in nature, they also provide the basis for 592 solving the security problems related to end-host mobility and 593 multi-homing. 595 2. What does a stack name look like? 597 A HIP Host Identifier is a cryptographic public key. However, 598 instead of using the keys directly, most protocols use a fixed 599 size hash of the public key. 601 3. What is its lifetime? 603 HIP provides both stable and temporary Host Identifiers. 604 Stable Host Identifiers are typically long lived, with a 605 lifetime of years of more. The lifetime of temporary Host 606 Identifiers depends on how long the upper layer connections 607 and applications need them, and can range from a few seconds 608 to years. 610 4. Where does it live in the stack? 612 The HIP Host Identifiers live between the transport and 613 internetworking layers. 615 5. How is it used on the end points 617 The HIP Host Identifiers, in the form of HITs or LSIs, are 618 used by legacy applications as if they were IP addresses. 619 Additionally, the Host Identifiers, as public keys, are used 620 in a built in key agreement protocol to authenticate the 621 Diffie-Hellman key exchange. 623 6. What administrative infrastructure is needed to support it? 625 It is possible to use HIP opportunistically, without any 626 infrastructure. However, the gain full benefit from HIP, the 627 Host Identifiers must be stored in the DNS, and a new 628 infrastructure of Rendezvous servers is needed. 630 7. If we add an additional layer would it make the address list in 631 SCTP unnecessary? 633 Yes 635 8. What additional security benefits would a new naming scheme 636 offer? 638 HIP reduces dependency on IP addresses, making the so called 639 address ownership problems easier to solve. In practice, HIP 640 provides security for end-host mobility and multi-homing. 641 Furthermore, since HIP Host Identifiers are public keys, 642 standard public key certificate infrastructures can be applied 643 on the top of HIP. 645 9. What would the resolution mechanisms be, or what characteristics 646 of a resolution mechanisms would be required? 648 For most purposes, an approach where DNS names are resolved 649 simultaneously to Host Identifiers and IP addresses is 650 sufficient. However, if it becomes necessary to resolve Host 651 Identifiers into IP addresses or back to DNS names, a flat, 652 hash based resolution infrastructure is needed. Such an 653 infrastructure could be based on the ideas of Distributed Hash 654 Tables, but would require significant new development and 655 deployment. 657 9. Security Considerations 659 HIP takes advantage of the new Host Identity paradigm to provide 660 secure authentication of hosts and provide a fast key exchange for 661 IPsec ESP. HIP also attempts to limit the exposure of the host to 662 various denial-of-service (DoS) and man-in-the-middle (MitM) attacks. 663 In so doing, HIP itself is subject to its own DoS and MitM attacks 664 that potentially could be more damaging to a host's ability to 665 conduct business as usual. 667 The Security Association for ESP is indexed by the SPI or HIT, not 668 the SPI and IP address. HIP enabled ESP is IP address independent. 669 This might seem to make it easier for an attacker, but ESP with 670 replay protection is already as well protected as possible, and the 671 removal of the IP address as a check should not increase the exposure 672 of ESP to DoS attacks. 674 Denial-of-service attacks take advantage of the cost of start of 675 state for a protocol on the responder compared to the 'cheapness' on 676 the initiator. HIP both allows to increase the cost of the start of 677 state on the initiator and makes an effort to reduce the cost to the 678 responder. This is done by having the responder start the 3-way 679 cookie exchange instead of the initiator, making the HIP protocol 4 680 packets long. There are more details on this process in the HIP 681 protocol document [6]. 683 HIP optionally supports opportunistic negotiation. That is, if a 684 host receives a start of transport without a HIP negotiation, it can 685 attempt to force a HIP exchange before accepting the connection. This 686 has the potential for DoS attacks against both hosts. If the method 687 to force the start of HIP is expensive on either host, the attacker 688 need only spoof a TCP SYN. This would put both systems into the 689 expensive operations. HIP avoids this attack by having the responder 690 send a simple HIP packet that it can pre-build. Since this packet is 691 fixed and easily spoofed, the initiator only reacts to it if it has 692 just started a connection to the responder. 694 Man-in-the-middle attacks are difficult to defend against, without 695 third-party authentication. A skillful MitM could easily handle all 696 parts of HIP; but HIP indirectly provides the following protection 697 from a MitM attack. If the responder's HI is retrieved from a signed 698 DNS zone by the initiator, the initiator can use this to validate the 699 signed HIP packets. 701 Likewise, if the initiator's HI is in a secure DNS zone, the 702 responder can retrieve it and validate the signed HIP packets. 703 However, since an initiator may choose to use an anonymous HI, it 704 knowingly risks a MitM attack. The responder may choose not to 705 accept a HIP exchange with an anonymous initiator. 707 Since not all hosts will ever support HIP, ICMP 'Destination Protocol 708 Unreachable' are to be expected and present a DoS attack. Against an 709 initiator, the attack would look like the responder does not support 710 HIP, but shortly after receiving the ICMP message, the initiator 711 would receive a valid HIP packet. Thus, to protect against this 712 attack, an initiator should not react to an ICMP message until a 713 reasonable delta time to get the real responder's HIP packet. A 714 similar attack against the responder is more involved. 716 Another MitM attack is simulating a responder's rejection of a HIP 717 initiation. This is a simple ICMP Protocol Unreachable, 718 Administratively Prohibited message. A HIP packet is not used 719 because it would either have to have unique content, and thus 720 difficult to generate, resulting in yet another DoS attack, or just 721 as spoofable as the ICMP message. The defense against this MitM 722 attack is for the responder to wait a reasonable time period to get a 723 valid HIP packet. If one does not come, then the Initiator has to 724 assume that the ICMP message is valid. Since this is the only point 725 in the HIP exchange where this ICMP message is appropriate, it can be 726 ignored at any other point in the exchange. 728 9.1 HITs used in ACLs 730 It is expected that HITs will be used in ACLs. Firewalls will use 731 HITs to control egress and ingress to networks, with an assurance 732 difficult to achieve today. 734 There has been considerable bad experience with distributed ACLs that 735 contain public key related material, for example, with SSH. If the 736 owner of the key needs to revoke it for any reason, the task of 737 finding all locations where the key is held in an ACL may be 738 impossible. If the reason for the revocation is due to private key 739 theft, this could be a serious issue. 741 A host can keep track of all of its partners that might use its HIT 742 in an ACL by logging all remote HITs. It should only be necessary to 743 log responder hosts. With this information, the host can notify the 744 various hosts about the change to the HIT. There has been no attempt 745 here to develop a secure method (like in CMP and CMC) to issue the 746 HIT revocation notice. 748 NATs, however, are transparent to the HIP aware systems by design. 749 Thus, the host many find it difficult to notify any NAT that is using 750 a HIT in an ACL. Since most systems will know of the NATs for their 751 network, there should be a process by which they can notify these 752 NATs of the change of the HIT. This is mandatory for systems that 753 function as responders behind a NAT. In a similar vein, if a host is 754 notified of a change in a HIT of an initiator, it should notify its 755 NAT of the change. In this manner, NATs will get updated with the 756 HIT change. 758 9.2 Non-security Considerations 760 The definition of the Host Identifier states that the HI need not be 761 a public key. That the HI could be any value; for example an FQDN. 762 This document does not describe how to support a non-cryptographic 763 HI. Such a HI would still offer the services of the HIT or LSI for 764 NAT traversal. It would carry the HITs or LSIs in a HIP packets that 765 had neither privacy nor authentication. Since this mode of HIP would 766 offer so little additional functionality for so much addition to the 767 IP kernel, it has not been defined in this document. Given how 768 little public key cryptography HIP requires, HIP should only be 769 implemented using public key Host Identities. 771 References 773 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 774 Levels", BCP 14, RFC 2119, March 1997. 776 [2] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - 777 Protocol Translation (NAT-PT)", RFC 2766, February 2000. 779 [3] Srisuresh, P. and K. Egevang, "Traditional IP Network Address 780 Translator (Traditional NAT)", RFC 3022, January 2001. 782 [4] Borella, M., Lo, J., Grabelsky, D. and G. Montenegro, "Realm 783 Specific IP: Framework", RFC 3102, October 2001. 785 [5] Jokela, P., "Optimized Packet Structure for HIP", 786 draft-jokela-hip-packets-01 (work in progress), November 2002. 788 [6] Moskowitz, R., "The Host Identity Payload", 789 draft-moskowitz-hip-05 (work in progress), November 2001. 791 [7] Richardson, M., "A method for storing IPsec keying material in 792 DNS", draft-ietf-ipseckey-rr-01 (work in progress), April 2003. 794 [8] Lear, E. and R. Droms, "What's In A Name:Thoughts from the 795 NSRG", draft-irtf-nsrg-report-09 (work in progress), March 796 2003. 798 [9] Nikander, P., "Mobile IP version 6 Route Optimization Security 799 Design Background", draft-nikander-mobileip-v6-ro-sec-00 (work 800 in progress), April 2003. 802 [10] Chiappa, J., "Endpoints and Endpoint Names: A Proposed 803 Enhancement to the Internet Architecture", URL http:// 804 users.exis.net/~jnc/tech/endpoints.txt, 1999. 806 Authors' Addresses 808 Robert Moskowitz 809 ICSAlabs, a Division of TruSecure Corporation 810 1000 Betn Creek Blvd, Suite 200 811 Mechanicsburg, PA 812 US 814 EMail: rgm@icsalabs.net 815 Pekka Nikander 816 Ericsson Research Nomadic Lab 818 JORVAS FIN-02420 819 FINLAND 821 Phone: +358 9 299 1 822 EMail: pekka.nikander@nomadiclab.com 824 Intellectual Property Statement 826 The IETF takes no position regarding the validity or scope of any 827 intellectual property or other rights that might be claimed to 828 pertain to the implementation or use of the technology described in 829 this document or the extent to which any license under such rights 830 might or might not be available; neither does it represent that it 831 has made any effort to identify any such rights. Information on the 832 IETF's procedures with respect to rights in standards-track and 833 standards-related documentation can be found in BCP-11. Copies of 834 claims of rights made available for publication and any assurances of 835 licenses to be made available, or the result of an attempt made to 836 obtain a general license or permission for the use of such 837 proprietary rights by implementors or users of this specification can 838 be obtained from the IETF Secretariat. 840 The IETF invites any interested party to bring to its attention any 841 copyrights, patents or patent applications, or other proprietary 842 rights which may cover technology that may be required to practice 843 this standard. Please address the information to the IETF Executive 844 Director. 846 Full Copyright Statement 848 Copyright (C) The Internet Society (2003). All Rights Reserved. 850 This document and translations of it may be copied and furnished to 851 others, and derivative works that comment on or otherwise explain it 852 or assist in its implementation may be prepared, copied, published 853 and distributed, in whole or in part, without restriction of any 854 kind, provided that the above copyright notice and this paragraph are 855 included on all such copies and derivative works. However, this 856 document itself may not be modified in any way, such as by removing 857 the copyright notice or references to the Internet Society or other 858 Internet organizations, except as needed for the purpose of 859 developing Internet standards in which case the procedures for 860 copyrights defined in the Internet Standards process must be 861 followed, or as required to translate it into languages other than 862 English. 864 The limited permissions granted above are perpetual and will not be 865 revoked by the Internet Society or its successors or assignees. 867 This document and the information contained herein is provided on an 868 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 869 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 870 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 871 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 872 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 874 Acknowledgement 876 Funding for the RFC Editor function is currently provided by the 877 Internet Society.