idnits 2.17.1 draft-moskowitz-hip-arch-05.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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 513: '...imes a HIP implementation MUST support...' RFC 2119 keyword, line 516: '... Implementations MAY support lifetimes...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 895 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 7529 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) -- Obsolete informational reference (is this intentional?): RFC 2766 (ref. '1') (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-hip-mm-00 == Outdated reference: A later version (-02) exists of draft-nikander-mobileip-v6-ro-sec-01 Summary: 3 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-05 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 a proposed new namespace, 41 the Host Identity namespace, and a new protocol layer, the Host 42 Identity Protocol, between the internetworking and transport layers. 43 Herein are presented the basics of the current namespaces, strengths 44 and weaknesses, and how a new namespace will add completeness to 45 them. 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 a 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 Identifier (LSI) . . . . . . . . . . . . . . . . 9 57 4. New Stack Architecture . . . . . . . . . . . . . . . . . . . 10 58 4.1 Transport associations and endpoints . . . . . . . . . . . . 10 59 5. End-Host Mobility and Multi-Homing . . . . . . . . . . . . . 12 60 5.1 Rendezvous server . . . . . . . . . . . . . . . . . . . . . 12 61 5.2 Protection against Flooding Attacks . . . . . . . . . . . . 13 62 6. HIP and IPsec . . . . . . . . . . . . . . . . . . . . . . . 14 63 7. HIP and NATs . . . . . . . . . . . . . . . . . . . . . . . . 15 64 7.1 HIP and TCP Checksum . . . . . . . . . . . . . . . . . . . . 15 65 8. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 16 66 9. Benefits of HIP . . . . . . . . . . . . . . . . . . . . . . 17 67 9.1 HIP's Answers to NSRG questions . . . . . . . . . . . . . . 18 68 10. Security Considerations . . . . . . . . . . . . . . . . . . 20 69 10.1 HITs used in ACLs . . . . . . . . . . . . . . . . . . . . . 21 70 10.2 Non-security Considerations . . . . . . . . . . . . . . . . 22 71 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 23 72 References (informative) . . . . . . . . . . . . . . . . . . 24 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 24 74 Intellectual Property and Copyright Statements . . . . . . . 26 76 1. Introduction 78 The Internet has created two global namespaces: Internet Protocol 79 (IP) addresses and Domain Name Service (DNS) names. These two 80 namespaces have a set of features and abstractions that have powered 81 the Internet to what it is today. They also have a number of 82 weaknesses. Basically, since they are all we have, we try and do too 83 much with them. Semantic overloading and functionality extensions 84 have greatly complicated these namespaces. 86 The Host Identity namespace fills an important gap between the IP and 87 DNS namespaces. The Host Identity namespace consist of Host 88 Identifiers (HI). A Host Identifier is cryptographic in its nature; 89 it is the public key of an asymmetric key-pair. A Host Identity is 90 assigned to each host, or technically its networking kernel or stack. 91 Each host will have at least one Host Identity and a corresponding 92 Host Identifier, which can either be public (e.g. published in DNS), 93 or anonymous. Client systems will tend to have both public and 94 anonymous Identities. 96 Although the Host Identities could be used in many authentication 97 systems, the presented architecture introduces a new protocol, called 98 the Host Identity Protocol (HIP), and a cryptographic exchange, 99 called the HIP base exchange [4]. The new protocol provides for 100 limited forms of trust between systems. It enhances mobility, 101 multi-homing and dynamic IP renumbering [7], aids in protocol 102 translation / transition [4], and reduces certain types of 103 denial-of-service (DoS) attacks [4]. 105 When HIP is used, the actual payload traffic between two HIP hosts is 106 typically protected with IPsec. The Host Identities are used to 107 create the needed IPsec Security Associations (SA) and to 108 authenticate the hosts. The actual payload IP packets do not differ 109 in any way from standard IPsec protected IP packets. 111 2. Background 113 The Internet is built from three principle components: computing 114 platforms, packet transport (i.e. internetworking) infrastructure, 115 and services (applications). The Internet exists to service two 116 principal components: people and robotic processes (silicon based 117 people, if you will). All these components need to be named in order 118 to interact in a scalable manner. 120 There are two principal namespaces in use in the Internet for these 121 components: IP numbers, and Domain Names. Email, HTTP and SIP 122 addresses are really only extensions of Domain Names. 124 IP numbers are a confounding of two namespaces, the names of the 125 networking interfaces and the names of the locations ('confounding' 126 is a term used in statistics to discuss metrics that are merged into 127 one with a gain in indexing, but a loss in informational value). The 128 names of locations should be understood as denoting routing direction 129 vectors, i.e., information that is used to deliver packets to their 130 destinations. 132 IP numbers name networking interfaces, and typically only when the 133 interface is connected to the network. Originally IP numbers had 134 long-term significance. Today, the vast number of interfaces use 135 ephemeral and/or non-unique IP numbers. That is, every time an 136 interface is connected to the network, it is assigned an IP number. 138 In the current Internet, the transport layers are coupled to the IP 139 addresses. Neither can evolve separately from the other. IPng 140 deliberations were framed by concerns of requiring a TCPng effort as 141 well. 143 Domain Names provide hierarchically assigned names for some computing 144 platforms and some services. Each hierarchy is delegated from the 145 level above; there is no anonymity in Domain Names. 147 Email addresses provide naming for both humans and autonomous 148 applications. Email addresses are extensions of Domain Names, only 149 in so far as a named service is responsible for managing a person's 150 mail. There is some anonymity in Email addresses. 152 There are three critical deficiencies with the current namespaces. 153 Firstly, dynamic readdressing cannot be directly managed. Secondly, 154 anonymity is not provided in a consistent, trustable manner. 155 Finally, authentication for systems and datagrams is not provided. 156 All because computing platforms are not well named with the current 157 namespaces. 159 2.1 A Desire for a Namespace for Computing Platforms 161 An independent namespace for computing platforms could be used in 162 end-to-end operations independent of the evolution of the 163 internetworking layer and across the many internetworking layers. 164 This could support rapid readdressing of the internetworking layer 165 either from mobility or renumbering. 167 If the namespace for computing platforms is cryptographically based, 168 it can also provide authentication services. If this namespace is 169 locally created without requiring registration, it can provide 170 anonymity. 172 Such a namespace (for computing platforms) and the names in it should 173 have the following characteristics: 175 The namespace should be applied to the IP 'kernel'. The IP kernel 176 is the 'component' between services and the packet transport 177 infrastructure. 179 The namespace should fully decouple the internetworking layer from 180 the higher layers. The names should replace all occurrences of IP 181 addresses within applications (like in the TCB). This may require 182 changes to the current APIs. In the long run, it is probable that 183 some new APIs are needed. 185 The introduction of the namespace should not mandate any 186 administrative infrastructure. Deployment must come from the 187 bottom up, in a pairwise deployment. 189 The names should have a fixed length representation, for easy 190 inclusion in datagrams and programming interfaces (e.g the TCB). 192 Using the namespace should be affordable when used in protocols. 193 This is primarily a packet size issue. There is also a 194 computational concern in affordability. 196 The names must be statistically globally unique. 64 bits is 197 inadequate (1% chance of collision in a population of 640M); thus 198 approximately 100 or more bits should be used. 200 The names should have a localized abstraction so that it can be 201 used in existing protocols and APIs. 203 It must be possible to create names locally. This can provide 204 anonymity at the cost of making resolvability very difficult. 206 Sometimes the names may contain a delegation component. This is 207 the cost of resolvability. 209 The namespace should provide authentication services. This is a 210 preferred function. 212 The names should be long lived, but replaceable at any time. This 213 impacts access control lists; short lifetimes will tend to result 214 in tedious list maintenance or require a namespace infrastructure 215 for central control of access lists. 217 In this document, such a new namespace is called the Host Identity 218 namespace. Using Host Identities requires its own protocol layer, 219 the Host Identity Protocol, between the internetworking and transport 220 layers. The names are based on public key cryptography to supply 221 authentication services. Properly designed, it can deliver all of the 222 above stated requirements. 224 3. Host Identity Namespace 226 A name in the Host Identity namespace, a Host Identifier (HI), 227 represents a statistically globally unique name for naming any system 228 with an IP stack. This identity is normally associated, but not 229 limited to, an IP stack. A system can have multiple identities, some 230 'well known', some anonymous. A system may self assert its identity, 231 or may use a third-party authenticator like DNSSEC, PGP, or X.509 to 232 'notarize' the identity assertion. It is expected that the Host 233 Identifiers will initially be authenticated with DNSSEC and that all 234 implementations will support DNSSEC as a minimal baseline. 236 There is a subtle but important difference between Host Identities 237 and Host Identifiers. An Identity refers to the abstract entity that 238 is identified. An Identifier, on the other hand, refers to the 239 concrete bit pattern that is used in the identification process. 241 In theory, any name that can claim to be 'statistically globally 242 unique' may serve as a Host Identifier. However, in the authors' 243 opinion, a public key of a 'public key pair' makes the best Host 244 Identifiers. As documented in the Host Identity Protocol 245 specification [4], a public key based HI can authenticate the HIP 246 packets and protect them for man-in-the-middle attacks. Since 247 authenticated datagrams are mandatory to provide much of HIP's 248 denial-of-service protection, the Diffie-Hellman exchange in HIP has 249 to be authenticated. Thus, only public key HI and authenticated HIP 250 messages are supported in practice. In this document, the 251 non-cryptographic forms of HI and HIP are presented to complete the 252 theory of HI, but they should not be implemented as they could 253 produce worse denial-of-service attacks than the Internet has without 254 Host Identity. 256 3.1 Host Identifiers 258 Host Identity adds two main features to Internet protocols. The first 259 is a decoupling of the internetworking and transport layers; see 260 Section 4. This decoupling will allow for independent evolution of 261 the two layers. Additionally, it can provide end-to-end services 262 over multiple internetworking realms. The second feature is host 263 authentication. Because the Host Identifier is a public key, this 264 key can be used to authenticate security protocols like IPsec. 266 The only completely defined structure of the Host Identity is that of 267 a public key pair. In this case, the Host Identity is referred to by 268 its public component, the public key. Thus, the name representing a 269 Host Identity in the Host Identity namespace, i.e. the Host 270 Identifier, is the public key. In a way, the possession of the 271 private key defines the Identity itself. If the private key is 272 possessed by more than one node, the Identity can be considered to be 273 a distributed one. 275 Architecturally, any other Internet naming convention might form a 276 usable base for Host Identifiers. However, non-cryptographic names 277 should only be used in situations of high trust - low risk. That is 278 any place where host authentication is not needed (no risk of host 279 spoofing) and no use of IPsec. The current HIP documents do not 280 specify how to use any other types of Host Identifiers but public 281 keys. 283 The actual Host Identities are never directly used in any Internet 284 protocols. The corresponding Host Identifiers (public keys) may be 285 stored in various DNS or LDAP directories as identified elsewhere in 286 this document, and they are passed in the HIP base exchange. A Host 287 Identity Tag (HIT) is used in other protocols to represent the Host 288 Identities. Another representation of the Host Identities, the Local 289 Scope Identifier (LSI), can also be used in protocols and APIs. 291 3.2 Storing Host Identifiers in DNS 293 The Host Identifiers should be stored in DNS. The exception to this 294 is anonymous identities. The HI is stored in a new RR type, to be 295 defined. This RR type is likely to be quite similar to the IPSECKEY 296 RR [5]. 298 Alternatively, or in addition to storing Host Identifiers in the DNS, 299 they may be stored in various kinds of Public Key Infrastructure 300 (PKI). Such a practice may allow them to be used for purposes other 301 than pure host identification. 303 3.3 Host Identity Tag (HIT) 305 A Host Identity Tag is an 128-bit representation for a Host Identity. 306 It is created by taking a cryptographic hash over the corresponding 307 Host Identifier. There are two advantages of using a hash over using 308 the Host Identifier in protocols. Firstly, its fixed length makes for 309 easier protocol coding and also better manages the packet size cost 310 of this technology. Secondly, it presents the identity in a 311 consistent format to the protocol independent of the whatever 312 underlying technology is used. 314 In the HIP packets, the HITs identify the sender and recipient of a 315 packet. Consequently, a HIT should be unique in the whole IP 316 universe. In the extremely rare case that a single HIT happens to 317 map to more than one Host Identities, the Host Identifiers (public 318 keys) will make the final difference. If there is more than one 319 public key for a given node, the HIT acts as a hint for the correct 320 public key to use. 322 3.4 Local Scope Identifier (LSI) 324 An LSI is a 32-bit localized representation for a Host Identity. The 325 purpose of an LSI is to facilitate using Host Identities in existing 326 protocols and APIs. LSI's advantage over HIT is its size; its 327 disadvantage is its local scope. The generation of LSIs is defined in 328 the Host Identity Protocol specification [4]. 330 Examples of how LSIs can be used include: as the address in a FTP 331 command and as the address in a socket call. Thus, LSIs act as a 332 bridge for Host Identities into old protocols and APIs. 334 4. New Stack Architecture 336 One way to characterize Host Identity is to compare the proposed new 337 architecture with the current one. As discussed above, the IP 338 addresses can be seen to be a confounding of routing direction 339 vectors and interface names. Using the terminology from the IRTF 340 Name Space Research Group Report [6] and, e.g., the unpublished 341 Internet-Draft Endpoints and Endpoint Names [9] by Noel Chiappa, the 342 IP addresses currently embody the dual role of locators and endpoint 343 identifiers. That is, each IP address names a topological location 344 in the Internet, thereby acting as a routing direction vector, or 345 locator. At the same time, the IP address names the physical network 346 interface currently located at the point-of-attachment, thereby 347 acting as a endpoint name. 349 In the HIP architecture, the endpoint names and locators are 350 separated from each other. IP addresses continue to act as locators. 351 The Host Identifiers take the role of endpoint identifiers. It is 352 important to understand that the endpoint names based on Host 353 Identities are slightly different from interface names; a Host 354 Identity can be simultaneously reachable through several interfaces. 356 The difference between the bindings of the logical entities are 357 illustrated in Figure 1. 359 Process ------ Socket Process ------ Socket 360 | | 361 | | 362 | | 363 | | 364 Endpoint | Endpoint --- Host Identity 365 \ | | 366 \ | | 367 \ | | 368 \ | | 369 Location --- IP address Location --- IP address 371 Figure 1 373 4.1 Transport associations and endpoints 375 Architecturally, HIP provides for a different binding of transport 376 layer protocols. That is, the transport layer associations, i.e., 377 TCP connections and UDP associations, are no more bound to IP 378 addresses but to Host Identities. 380 It is possible that a single physical computer hosts several logical 381 endpoints. With HIP, each of these endpoints would have a distinct 382 Host Identity. Furthermore, since the transport associations are 383 bound to Host Identities, HIP provides for process migration and 384 clustered servers. That is, if a Host Identity is moved from one 385 physical computer to another, it is also possible to simultaneously 386 move all the transport associations without breaking them. Similarly, 387 if it is possible to distribute the processing of a single Host 388 Identity over several physical computers, HIP provides for cluster 389 based services without any changes at the client endpoint. 391 5. End-Host Mobility and Multi-Homing 393 HIP decouples the transport from the internetworking layer, and binds 394 the transport associations to the Host Identities (through actually 395 either the HIT or LSI). Consequently, HIP can provide for a degree 396 of internetworking mobility and multi-homing at a very low 397 infrastructure cost. HIP mobility includes IP address changes (via 398 any method) to either party. Thus, a system is considered mobile if 399 its IP address can change dynamically for any reason like PPP, DHCP, 400 IPv6 prefix reassignments, or a NAT device remapping its translation. 401 Likewise, a system is considered multi-homed if it has more than one 402 globally routable IP address at the same time. HIP allows these IP 403 addresses to be linked with each other, and if one address becomes 404 unusable (e.g. due to a network failure), existing transport 405 associations can be easily moved to another address. 407 When a node moves while communication is already on-going, address 408 changes are rather straightforward. The peer of the mobile node can 409 just accept a HIP or an integrity protected IPsec packet from any 410 address and totally ignore the source address. However, as discussed 411 in Section 5.2 below, a mobile node must send a HIP readdress packet 412 to inform the peer of the new address(es), and the peer must verify 413 that the mobile node is reachable through these addresses. This is 414 especially helpful for those situations where the peer node is 415 sending data periodically to the mobile node (that is re-starting a 416 connection after the initial connection). 418 5.1 Rendezvous server 420 Making a contact to a mobile node is slightly more involved. In 421 order to start the HIP exchange, the initiator node has to know how 422 to reach the mobile node. Although Dynamic DNS could be used for 423 this function for infrequently moving nodes, an alternative to using 424 DNS in this fashion is to use a piece of new static infrastructure 425 called a HIP rendezvous server. Instead of registering its current 426 dynamic address to the DNS server, the mobile node registers the 427 address(es) of its rendezvous server(s). The mobile node keeps the 428 rendezvous server(s) continuously updated with its current IP 429 address(es). A rendezvous server simply forwards the initial HIP 430 packet from an initiator to the mobile node at its current location. 431 All further packets flow between the initiator and the mobile node. 432 There is typically very little activity on a rendezvous server, 433 address updates and initial HIP packet forwarding. Thus, one server 434 can support a large number of potential mobile nodes. The mobile 435 nodes must trust the rendezvous server to properly maintain their HIT 436 and IP address mappings. 438 The rendezvous server is also needed if both of the nodes are mobile 439 and happen to move at the same time. In that case, the HIP readdress 440 packets will cross each other in the network and never reach the peer 441 node. To solve this situation, the nodes should remember the 442 rendezvous server address, and re-send the HIP readdress packet to 443 the rendezvous server if no reply is received. 445 The mobile node keeps its address current on the rendezvous server by 446 setting up a HIP association with the rendezvous server and sending 447 HIP readdress packets to it. A rendezvous server will permit two 448 mobile systems to use HIP without any extraneous infrastructure (in 449 addition to the rendezvous server itself), including DNS if they have 450 a method other than a DNS query to get each other's HI and HIT. 452 5.2 Protection against Flooding Attacks 454 While the idea of informing about address changes by simply sending 455 packets with a new source address appears appealing, it is not secure 456 enough. That is, even if HIP does not rely on the source address for 457 anything (once the base exchange has been completed), it appears to 458 be necessary to check a mobile node's reachability at the new address 459 before actually sending any larger amounts of traffic to the new 460 address. 462 Blindly accepting new addresses would potentially lead to flooding 463 Denial-of-Service attacks against third parties [8]. In a 464 distributed flooding attack an attacker opens (anonymous) high volume 465 HIP connections with a large number of hosts, and then claims to all 466 of these hosts that it has moved to a target node's IP address. If 467 the peer hosts were to simply accept the move, the result would be a 468 packet flood to the target node's address. To close this attack, HIP 469 includes an address check mechanism where the reachability of a node 470 is separately checked at each address before using the address for 471 larger amounts of traffic. 473 Whenever HIP is used between two hosts that fully trust each other, 474 the hosts may optionally decide to skip the address tests. However, 475 such performance optimization must be restricted to peers that are 476 known to be trustworthy and capable of protecting themselves from 477 malicious software. 479 6. HIP and IPsec 481 The preferred way of implementing HIP is to use IPsec to carry the 482 actual data traffic. As of today, the only completely defined method 483 is to use IPsec Encapsulated Security Payload (ESP) to carry the data 484 packets. In the future, other ways of transporting payload data may 485 be developed, including ones that do not use cryptographic 486 protection. 488 In practise, the HIP base exchange uses the cryptographic Host 489 Identifiers to set up a pair of ESP Security Associations (SAs) to 490 enable ESP in an end-to-end manner. This is implemented in a way 491 that can span addressing realms. 493 From a conceptual point of view, the IPsec Security Parameter Index 494 (SPI) in ESP provides a simple compression of the HITs. This does 495 require per-HIT-pair SAs (and SPIs), and a decrease of policy 496 granularity over other Key Management Protocols, such as IKE and 497 IKEv2. Future HIP extensions may provide for more granularity and 498 creation of several ESP SAs between a pair of HITs 500 Since HIP is designed for host usage, not for gateways, only ESP 501 transport mode is supported. An ESP SA pair is indexed by the SPIs 502 and the two HITs (both HITs since a system can have more than one 503 HIT). The SAs need not to be bound to IP addresses; all internal 504 control of the SA is by the HITs. Thus, a host can easily change its 505 address using Mobile IP, DHCP, PPP, or IPv6 readdressing and still 506 maintain the SAs. Since the transports are bound to the SA (via an 507 LSI or a HIT), any active transport is also maintained. Thus, real 508 world conditions like loss of a PPP connection and its 509 re-establishment or a mobile handover will not require a HIP 510 negotiation or disruption of transport services. 512 Since HIP does not negotiate any SA lifetimes, all lifetimes are 513 local policy. The only lifetimes a HIP implementation MUST support 514 are sequence number rollover (for replay protection), and SA timeout. 515 An SA times out if no packets are received using that SA. 516 Implementations MAY support lifetimes for the various ESP transforms. 518 7. HIP and NATs 520 Passing packets between different IP addressing realms requires 521 changing IP addresses in the packet header. This may happen, for 522 example, when a packet is passed between the public Internet and a 523 private address space, or between IPv4 and IPv6 networks. The 524 address translation is usually implemented as Network Address 525 Translation (NAT) [2] or NAT Protocol translation (NAT-PT) [1]. 527 In a network environment where the identification is based on the IP 528 addresses, identifying the communicating nodes is difficult when NAT 529 is used. With HIP, the transport layer endpoints are bound to the 530 Host Identities. Thus, a connection between two hosts can traverse 531 many addressing realm boundaries. The IP addresses are used only for 532 routing purposes; the IP addresses may be changed freely during 533 packet traversal. 535 For a HIP based flow, a NAT or NAT-PT system tracks the mapping of 536 HITs and the corresponding IPsec SPIs to an IP address. Many HITs 537 can map to a single IP address on a NAT, simplifying connections on 538 address poor NAT interfaces. The NAT can gain much of its knowledge 539 from the HIP packets themselves; however, some NAT configuration may 540 be necessary. 542 The NAT systems cannot touch the datagrams within the IPsec envelope, 543 thus application specific address translation must be done in the end 544 systems. HIP provides for 'Distributed NAT', and uses the HIT or the 545 LSI as a place holder for embedded IP addresses. 547 7.1 HIP and TCP Checksum 549 There is no way for a host to know if any of the IP addresses in the 550 IP header are the addresses used to calculate the TCP checksum. That 551 is, it is not feasible to calculate the TCP checksum using the actual 552 IP addresses in the pseudo header; the addresses received in the 553 incoming packet are not necessarily the same as they were on the 554 sending host. Furthermore, it is not possible to recompute the upper 555 layer checksums in the NAT/NAT-PT system, since the traffic is IPsec 556 protected. Consequently, the TCP and UDP checksums are calculated 557 using the HITs in the place of the IP addresses in the pseudo header. 558 Furthermore, only the IPv6 pseudo header format is used. This 559 provides for IPv4 / IPv6 protocol translation. 561 8. HIP Policies 563 There are a number of variables that will influence the HIP exchanges 564 that each host must support. All HIP implementations should support 565 at least 2 HIs, one to publish in DNS and one for anonymous usage. 566 Although anonymous HIs will be rarely used as responder HIs, they are 567 likely be common for initiators. Support for multiple HIs is 568 recommended. 570 Many initiators would want to use a different HI for different 571 responders. The implementations should provide for a policy of 572 initiator HIT to responder HIT. This policy should also include 573 preferred transforms and local lifetimes. 575 Responders would need a similar policy, representing which hosts they 576 accept HIP exchanges, and the preferred transforms and local 577 lifetimes. 579 9. Benefits of HIP 581 In the beginning, the network layer protocol (i.e. IP) had the 582 following four "classic" invariants: 584 Non-mutable: The address sent is the address received. 586 Non-mobile: The address doesn't change during the course of an 587 "association". 589 Reversible: A return header can always be formed by reversing the 590 source and destination addresses. 592 Omniscient: Each host knows what address a partner host can use to 593 send packets to it. 595 Actually, the fourth can be inferred from 1 and 3, but it is worth 596 mentioning for reasons that will be obvious soon if not already. 598 In the current "post-classic" world, we are trying intentionally to 599 get rid of the second invariant (both for mobility and for 600 multi-homing), and we have been forced to give up the first and the 601 fourth. Realm Specific IP [3] is an attempt to reinstate the fourth 602 invariant without the first invariant. IPv6 is an attempt to 603 reinstate the first invariant. 605 Few systems on the Internet have DNS names that are meaningful to 606 them. That is, if they have a Fully Qualified Domain Name (FQDN), 607 that typically belongs to a NAT device or a dial-up server, and does 608 not really identify the system itself but its current connectivity. 609 FQDN names (and their extensions as email names) are Application 610 Layer names; more frequently naming processes than a particular 611 system. This is why many systems on the internet are not registered 612 in DNS; they do not have processes of interest to other Internet 613 hosts. 615 DNS names are indirect references to IP addresses. This only 616 demonstrates the interrelationship of the networking and application 617 layers. DNS, as the Internet's only deployed, distributed, database 618 is also the repository of other namespaces, due in part to DNSSEC and 619 application specific key records. Although each namespace can be 620 stretched (IP with v6, DNS with KEY records), neither can adequately 621 provide for host authentication or act as a separation between 622 internetworking and transport layers. 624 The Host Identity (HI) namespace fills an important gap between the 625 IP and DNS namespaces. An interesting thing about the HI is that it 626 actually allows one to give-up all but the 3rd Network Layer 627 invariant. That is to say, as long as the source and destination 628 addresses in the network layer protocol are reversible, then things 629 work ok because HIP takes care of host identification, and 630 reversibility allows one to get a packet back to one's partner host. 631 You don't care if the network layer address changes in transit 632 (mutable) and you don't care what network layer address the partner 633 is using (non-omniscient). 635 Since all systems can have a Host Identity, every system can have an 636 entry in the DNS. The mobility features in HIP make it attractive to 637 trusted 3rd parties to offer rendezvous servers. 639 9.1 HIP's Answers to NSRG questions 641 The IRTF Name Space Research Group has posed a number of evaluating 642 questions in their report [6]. In this section, we provide answers 643 to these questions. 645 1. How would a stack name improve the overall functionality of the 646 Internet? 648 At the fundamental level, HI decouples the internetworking 649 layer from the transport layer, allowing each to evolve 650 separately. At the same time, the decoupling makes end-host 651 mobility and multi-homing easier. It also allows mobility and 652 multi-homing across the IPv4 and IPv6 networks. HIs make 653 network renumbering easier. At the conceptual level, they 654 also make process migration and clustered servers easier to 655 implement. Furthermore, being cryptographic in nature, they 656 provide the basis for solving the security problems related to 657 end-host mobility and multi-homing. 659 2. What does a stack name look like? 661 A HI is a cryptographic public key. However, instead of using 662 the keys directly, most protocols use a fixed size hash of the 663 public key. 665 3. What is its lifetime? 667 HIP provides both stable and temporary Host Identifiers. 668 Stable HIs are typically long lived, with a lifetime of years 669 or more. The lifetime of temporary HIs depends on how long 670 the upper layer connections and applications need them, and 671 can range from a few seconds to years. 673 4. Where does it live in the stack? 674 The HIs live between the transport and internetworking layers. 676 5. How is it used on the end points 678 The Host Identifiers, in the form of HITs or LSIs, are used by 679 legacy applications as if they were IP addresses. 680 Additionally, the Host Identifiers, as public keys, are used 681 in the built in key agreement protocol, called the HIP base 682 exchange, to authenticate the hosts to each other. 684 6. What administrative infrastructure is needed to support it? 686 It is possible to use HIP opportunistically, without any 687 infrastructure. However, to gain full benefit from HIP, the 688 HIs must be stored in the DNS or a PKI, and a new 689 infrastructure of rendezvous servers is needed. 691 7. If we add an additional layer would it make the address list in 692 SCTP unnecessary? 694 Yes 696 8. What additional security benefits would a new naming scheme 697 offer? 699 HIP reduces dependency on IP addresses, making the so called 700 address ownership problems easier to solve. In practice, HIP 701 provides security for end-host mobility and multi-homing. 702 Furthermore, since HIP Host Identifiers are public keys, 703 standard public key certificate infrastructures can be applied 704 on the top of HIP. 706 9. What would the resolution mechanisms be, or what characteristics 707 of a resolution mechanisms would be required? 709 For most purposes, an approach where DNS names are resolved 710 simultaneously to HIs and IP addresses is sufficient. 711 However, if it becomes necessary to resolve HIs into IP 712 addresses or back to DNS names, a flat, hash based resolution 713 infrastructure is needed. Such an infrastructure could be 714 based on the ideas of Distributed Hash Tables, but would 715 require significant new development and deployment. 717 10. Security Considerations 719 HIP takes advantage of the new Host Identity paradigm to provide 720 secure authentication of hosts and to provide a fast key exchange for 721 IPsec. HIP also attempts to limit the exposure of the host to 722 various denial-of-service (DoS) and man-in-the-middle (MitM) attacks. 723 In so doing, HIP itself is subject to its own DoS and MitM attacks 724 that potentially could be more damaging to a host's ability to 725 conduct business as usual. 727 Resource exhausting Denial-of-service attacks take advantage of the 728 cost of setting up a state for a protocol on the responder compared 729 to the 'cheapness' on the initiator. HIP allows a responder to 730 increase the cost of the start of state on the initiator and makes an 731 effort to reduce the cost to the responder. This is done by having 732 the responder start the authenticated Diffie-Hellman exchange instead 733 of the initiator, making the HIP base exchange 4 packets long. There 734 are more details on this process in the Host Identity Protocol 735 specification [4]. 737 HIP optionally supports opportunistic negotiation. That is, if a 738 host receives a start of transport without a HIP negotiation, it can 739 attempt to force a HIP exchange before accepting the connection. 740 This has the potential for DoS attacks against both hosts. If the 741 method to force the start of HIP is expensive on either host, the 742 attacker need only spoof a TCP SYN. This would put both systems into 743 the expensive operations. HIP avoids this attack by having the 744 responder send a simple HIP packet that it can pre-build. Since this 745 packet is fixed and easily replayed, the initiator only reacts to it 746 if it has just started a connection to the responder. 748 Man-in-the-middle attacks are difficult to defend against, without 749 third-party authentication. A skillful MitM could easily handle all 750 parts of the HIP base exchange, but HIP indirectly provides the 751 following protection from a MitM attack. If the responder's HI is 752 retrieved from a signed DNS zone or secured by some other means, the 753 initiator can use this to authenticate the signed HIP packets. 754 Likewise, if the initiator's HI is in a secure DNS zone, the 755 responder can retrieve it and validate the signed HIP packets. 756 However, since an initiator may choose to use an anonymous HI, it 757 knowingly risks a MitM attack. The responder may choose not to 758 accept a HIP exchange with an anonymous initiator. 760 In HIP, the Security Association for IPsec is indexed by the SPI; the 761 source address is always ignored, and the destination address may be 762 ignored as well. Therefore, HIP enabled IPsec Encapsulated Security 763 Payload (ESP) is IP address independent. This might seem to make it 764 easier for an attacker, but ESP with replay protection is already as 765 well protected as possible, and the removal of the IP address as a 766 check should not increase the exposure of IPsec ESP to DoS attacks. 768 Since not all hosts will ever support HIP, ICMPv4 'Destination 769 Unreachable, Protocol Unreachable' and ICMPv6 'Parameter Problem, 770 Unrecognized Next Header' messages are to be expected and present a 771 DoS attack. Against an initiator, the attack would look like the 772 responder does not support HIP, but shortly after receiving the ICMP 773 message, the initiator would receive a valid HIP packet. Thus, to 774 protect against this attack, an initiator should not react to an ICMP 775 message until a reasonable time has passed, allowing it to get the 776 real responder's HIP packet. A similar attack against the responder 777 is more involved. 779 Another MitM attack is simulating a responder's administrative 780 rejection of a HIP initiation. This is a simple ICMP 'Destination 781 Unreachable, Administratively Prohibited' message. A HIP packet is 782 not used because it would either have to have unique content, and 783 thus difficult to generate, resulting in yet another DoS attack, or 784 just as spoofable as the ICMP message. Like in the previous case, 785 the defense against this attack is for the initiator to wait a 786 reasonable time period to get a valid HIP packet. If one does not 787 come, then the initiator has to assume that the ICMP message is 788 valid. Since this is the only point in the HIP base exchange where 789 this ICMP message is appropriate, it can be ignored at any other 790 point in the exchange. 792 10.1 HITs used in ACLs 794 It is expected that HITs will be used in ACLs. Future firewalls can 795 use HITs to control egress and ingress to networks, with an assurance 796 level difficult to achieve today. As discussed above in Section 6, 797 once a HIP session has been established, the SPI value in an IPsec 798 packet may be used as an index, indicating the HITs. In practise, 799 the firewalls can inspect the HIP packets to learn of the bindings 800 between HITs, SPI values, and IP addresses. They can even explicitly 801 control IPsec usage, dynamically opening IPsec ESP only for specific 802 SPI values and IP addresses. The signatures in the HIP packets allow 803 a capable firewall to make sure that the HIP exchange is indeed 804 happening between two known hosts. This may increase firewall 805 security. 807 There has been considerable bad experience with distributed ACLs that 808 contain public key related material, for example, with SSH. If the 809 owner of the key needs to revoke it for any reason, the task of 810 finding all locations where the key is held in an ACL may be 811 impossible. If the reason for the revocation is due to private key 812 theft, this could be a serious issue. 814 A host can keep track of all of its partners that might use its HIT 815 in an ACL by logging all remote HITs. It should only be necessary to 816 log responder hosts. With this information, the host can notify the 817 various hosts about the change to the HIT. There has been no attempt 818 to develop a secure method (like in CMP and CMC) to issue the HIT 819 revocation notice. 821 NATs, however, are transparent to the HIP aware systems by design. 822 Thus, the host may find it difficult to notify any NAT that is using 823 a HIT in an ACL. Since most systems will know of the NATs for their 824 network, there should be a process by which they can notify these 825 NATs of the change of the HIT. This is mandatory for systems that 826 function as responders behind a NAT. In a similar vein, if a host is 827 notified of a change in a HIT of an initiator, it should notify its 828 NAT of the change. In this manner, NATs will get updated with the 829 HIT change. 831 10.2 Non-security Considerations 833 The definition of the Host Identifier states that the HI need not be 834 a public key. It implies that the HI could be any value; for example 835 an FQDN. This document does not describe how to support such a 836 non-cryptographic HI. A non-cryptographic HI would still offer the 837 services of the HIT or LSI for NAT traversal. It would be possible 838 carry the HITs in HIP packets that had neither privacy nor 839 authentication. Since such a mode would offer so little additional 840 functionality for so much addition to the IP kernel, it has not been 841 defined. Given how little public key cryptography HIP requires, HIP 842 should only be implemented using public key Host Identities. 844 If it is desirable to use HIP in a low security situation where 845 public key computations are considered expensive, HIP can be used 846 with very short Diffie-Hellman and Host Identity keys. Such use 847 makes the participating hosts vulnerable to MitM and connection 848 hijacking attacks. However, it does not cause flooding dangers, 849 since the address check mechanism relies on the routing system and 850 not on cryptographic strength. 852 11. Acknowledgments 854 For the people historically involved in the early stages of HIP, see 855 the Acknowledgements section in the Host Identity Protocol 856 specification [4]. 858 During the later stages of this document, when the editing baton was 859 transfered to Pekka Nikander, the comments from the early 860 implementors and others, including Jari Arkko, Tom Henderson, Petri 861 Jokela, Miika Komu, Mika Kousa, Andrew McGregor, Jan Melen, Tim 862 Shepard, Jukka Ylitalo, and Jorma Wall, were invaluable. 864 References (informative) 866 [1] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - 867 Protocol Translation (NAT-PT)", RFC 2766, February 2000. 869 [2] Srisuresh, P. and K. Egevang, "Traditional IP Network Address 870 Translator (Traditional NAT)", RFC 3022, January 2001. 872 [3] Borella, M., Lo, J., Grabelsky, D. and G. Montenegro, "Realm 873 Specific IP: Framework", RFC 3102, October 2001. 875 [4] Moskowitz, R., Nikander, P. and P. Jokela, "Host Identity 876 Protocol", draft-moskowitz-hip-07 (work in progress), June 2003. 878 [5] Richardson, M., "A method for storing IPsec keying material in 879 DNS", draft-ietf-ipseckey-rr-07 (work in progress), September 880 2003. 882 [6] Lear, E. and R. Droms, "What's In A Name:Thoughts from the 883 NSRG", draft-irtf-nsrg-report-10 (work in progress), September 884 2003. 886 [7] Nikander, P., "End-Host Mobility and Multi-Homing with Host 887 Identity Protocol", draft-nikander-hip-mm-00 (work in progress), 888 June 2003. 890 [8] Nikander, P., "Mobile IP version 6 Route Optimization Security 891 Design Background", draft-nikander-mobileip-v6-ro-sec-01 (work 892 in progress), July 2003. 894 [9] Chiappa, J., "Endpoints and Endpoint Names: A Proposed 895 Enhancement to the Internet Architecture", URL http:// 896 users.exis.net/~jnc/tech/endpoints.txt, 1999. 898 Authors' Addresses 900 Robert Moskowitz 901 ICSAlabs, a Division of TruSecure Corporation 902 1000 Bent Creek Blvd, Suite 200 903 Mechanicsburg, PA 904 USA 906 EMail: rgm@icsalabs.com 907 Pekka Nikander 908 Ericsson Research Nomadic Lab 910 JORVAS FIN-02420 911 FINLAND 913 Phone: +358 9 299 1 914 EMail: pekka.nikander@nomadiclab.com 916 Intellectual Property Statement 918 The IETF takes no position regarding the validity or scope of any 919 intellectual property or other rights that might be claimed to 920 pertain to the implementation or use of the technology described in 921 this document or the extent to which any license under such rights 922 might or might not be available; neither does it represent that it 923 has made any effort to identify any such rights. Information on the 924 IETF's procedures with respect to rights in standards-track and 925 standards-related documentation can be found in BCP-11. Copies of 926 claims of rights made available for publication and any assurances of 927 licenses to be made available, or the result of an attempt made to 928 obtain a general license or permission for the use of such 929 proprietary rights by implementors or users of this specification can 930 be obtained from the IETF Secretariat. 932 The IETF invites any interested party to bring to its attention any 933 copyrights, patents or patent applications, or other proprietary 934 rights which may cover technology that may be required to practice 935 this standard. Please address the information to the IETF Executive 936 Director. 938 Full Copyright Statement 940 Copyright (C) The Internet Society (2003). All Rights Reserved. 942 This document and translations of it may be copied and furnished to 943 others, and derivative works that comment on or otherwise explain it 944 or assist in its implementation may be prepared, copied, published 945 and distributed, in whole or in part, without restriction of any 946 kind, provided that the above copyright notice and this paragraph are 947 included on all such copies and derivative works. However, this 948 document itself may not be modified in any way, such as by removing 949 the copyright notice or references to the Internet Society or other 950 Internet organizations, except as needed for the purpose of 951 developing Internet standards in which case the procedures for 952 copyrights defined in the Internet Standards process must be 953 followed, or as required to translate it into languages other than 954 English. 956 The limited permissions granted above are perpetual and will not be 957 revoked by the Internet Society or its successors or assignees. 959 This document and the information contained herein is provided on an 960 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 961 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 962 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 963 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 964 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 966 Acknowledgement 968 Funding for the RFC Editor function is currently provided by the 969 Internet Society.