Network Working Group T. Henderson Internet-Draft The Boeing Company Expires: August 14, 2005 February 13, 2005 Generalizing the HIP base protocol draft-henderson-hip-generalize-00 Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 14, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract The Host Identity Protocol and architecture (HIP) proposes to add a cryptographic name space for network stack names. This draft observes that HIP can be viewed as an instance of a more general migration towards decoupling identity from location in the Internet architecture, and shows how other proposals (mobile IP, multi6, mobike, and i3) fit into this framework. We argue that if the HIP base protocol were to be slightly generalized, it might be useful to Henderson Expires August 14, 2005 [Page 1] Internet-Draft Generalizing the HIP base protocol February 2005 other related efforts and might allow more experimental flexibility. Specifically, an extensible identifier TLV, the ability to define usage profiles for the HIP handshake, and a relaxation of the requirements that specific HIP messages carry specific parameters are the three changes suggested. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Taxonomy of Proposals . . . . . . . . . . . . . . . . . . . . 5 3.1 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.1 Mobile IP with Route Optimization . . . . . . . . . . 6 3.1.2 Host Identity Protocol . . . . . . . . . . . . . . . . 7 3.1.3 Multihoming L3 Shim . . . . . . . . . . . . . . . . . 7 3.1.4 i3 (Internet Indirection Infrastructure) . . . . . . . 8 3.2 Combinations and Syntheses . . . . . . . . . . . . . . . . 8 4. Implications for HIP work . . . . . . . . . . . . . . . . . . 9 4.1 Proposed changes to HIP . . . . . . . . . . . . . . . . . 9 4.1.1 Identifiers . . . . . . . . . . . . . . . . . . . . . 9 4.1.2 Handshake . . . . . . . . . . . . . . . . . . . . . . 10 4.1.3 Mandatory parameters . . . . . . . . . . . . . . . . . 10 4.1.4 Per-packet context . . . . . . . . . . . . . . . . . . 11 4.2 Example Uses . . . . . . . . . . . . . . . . . . . . . . . 11 4.2.1 Securing MIPv6 Binding Update . . . . . . . . . . . . 11 4.2.2 Site multiHoming by IPv6 interMediation (shim6) . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . 19 Henderson Expires August 14, 2005 [Page 2] Internet-Draft Generalizing the HIP base protocol February 2005 1. Introduction The Host Identity Protocol (HIP) [1] is an experimental effort in the IETF and IRTF to study a new public-key-based name space for use as host identifiers in Internet protocols. Taking a step back, HIP can be viewed as one instance of a large number of proposals for decoupling (network) name or identity from (network) location in the Internet architecture, managing more than one IP address for active communications flows, or providing an additional layer of indirection in the protocol stack, located at or slightly above the network layer. The topic of whether a new name space is needed for the Internet is controversial. The Name Space Research Group (NSRG) at the IRTF was not able to reach consensus on the issue, nor even to publish a final report. The IRTF HIP research group is tasked to evaluate the impact of deployment of a HIP or related name space in the Internet. Yet, there seems to be little disagreement that, for many scenarios, some level of indirection from network name to network location is essential or highly desirable to provide adequate service. Mobile IP [2] is one example (the first such Standards Track proposal), with particular deployment and security properties, that reuses an existing name space for host naming. Since mobile IP was finalized (and in a few cases, even around or before the time it was initially proposed [3]), many new variants to providing this indirection have been suggested. Most recently, there has been standardization and development efforts in the IETF and IRTF on multi6 protocols and HIP. In the research community, several related proposals have been explored, such as the Internet Indirection Infrastructure (i3) [4], IPNL [5], DataRouter [6], Network Pointers [7], FARA [8], and TRIAD [9]. The purpose of this draft is to outline the broad framework into which most of these examples fit, provide a way of categorizing the various proposals, and how they might be coherently combined, and discuss how the HIP base protocol [1] could be generalized to better support this broader framework. Henderson Expires August 14, 2005 [Page 3] Internet-Draft Generalizing the HIP base protocol February 2005 2. Motivation It is beyond the scope of this draft to discuss whether a network layer identifier is needed or preferred to identifiers at other layers, but some of the main reasons that are frequently cited in support of identifiers at this layer include generality, security, mobility, multihoming (both site and local multihoming), traversal of multiple addressing realms, and the enabling of network overlays. For more insight into the motivations of various proposals, see, e.g., [4], [10], [11], [12], and [8]. The purpose of this draft is to explore the common ground of a number of proposals to use location-independent identifiers as part of the network layer (or logically or explicitly wedged between the network and transport layer protocols), and to describe how a more general HIP protocol might be of more general use. Henderson Expires August 14, 2005 [Page 4] Internet-Draft Generalizing the HIP base protocol February 2005 3. Taxonomy of Proposals In this section, we attempt to categorize a number of proposals and show the overall commonality of the approach. As examples, we will describe how the multi6 shim [13], mobile IP [2], HIP [1], and i3 [4] map into this framework. The following figure, adapted from [13], depicts the architecture under consideration (although not all proposals map exactly to this architecture, the diagram is conceptual). It illustrates a placement of a (logical or real) shim below the IP endpoint sublayer and the IP routing sublayer. ----------------------- | Transport Protocols | ----------------------- ------ ------- -------------- ------------- IP endpoint | AH | | ESP | | Frag/reass | | Dest opts | sub-layer ------ ------- -------------- ------------- -------------- | Shim layer | -------------- ------ IP routing | IP | sub-layer ------ The following details are relevant to such an architecture and are different from traditional systems: Upper layer identifier: The 32- or 128-bit datum used by transport protocol or above (that may be different from the IP address or locator used at the IP routing sub-layer). Examples include special IP addresses (e.g., mobile IP home address, the identifier-address discussed in [13], and unique-local addresses [14]), and host identity tags (HITs) [1], which are non-routable by the existing IP infrastructure. A further distinction may be made between transport, session, and application-layer identifiers. Identifier resolution: If the upper layer identifier is not routable or is not the same as the outer IP addresses that will appear on the packet, it must be resolved to a routable locator. Proposals in this space are sometimes categorized as being "early binding" (e.g., HIT resolution on the end hosts, mobile IP with route optimization) or "late binding" (e.g., trigger resolution within the i3 infrastructure, mobile IP without route optimization). Henderson Expires August 14, 2005 [Page 5] Internet-Draft Generalizing the HIP base protocol February 2005 Context establishment: When upper layer identifiers are used that are different from the locators, some context establishment protocol is likely needed to signal the upper layer identifiers in use, and perhaps to establish context for flow demultiplexing and other purposes. The HIP base protocol is a clear example of this, serving to signal to the peer the upper layer HIT identifiers to use (and also to authenticate the host if needed), to derive keying material used within the protocol itself and for security associations, and, when ESP is used, to select SPIs. Other working groups (shim6 and mobike) are poised to define their own context establishment protocol. Per-packet context tag: When identifiers and locators are different, some kind of context tag is needed for receivers to locate the right identity context for the received packet. In HIP with ESP, the SPI serves as a compressed representation of the HITs; other tags may also be possible with HIP. Mobile IP with route optimization uses Routing Headers or Destination Options for this purpose. Another example is the M6 shim protocol of SIM [15]. Locator management: The techniques by which multiple locators are associated with the identifier, using some security technique for binding, and by which locators are selected for source and destination addresses when there are more than one to choose from. Proposals in this space include MAST [16], CELP [17], multi6 failure detection and locator selection [18], hash-based addresses [19], and HIP multihoming extensions [20]. 3.1 Examples Below are some examples of how specific proposals map into the above framework. 3.1.1 Mobile IP with Route Optimization Upper layer identifier: The home address serves as an upper layer identifier. Identifier resolution: Resolution is done at the endpoints, when the Care-of Address (COA) is appended (early binding). Context establishment: The Binding Update procedure is used to establish the tunneling context. Henderson Expires August 14, 2005 [Page 6] Internet-Draft Generalizing the HIP base protocol February 2005 Per-packet context tag: The home address is carried in each packet, in either the Home Address Destination Option or the Type 2 Routing Header. Locator management: New CoA locators are sent directly to the correspondent nodes via the Binding Update message. The Binding Update is authenticated via the key generated as part of the return routability procedure. 3.1.2 Host Identity Protocol Upper layer identifier: The Host Identity Tag, a 128-bit hash of the public key, is used as the upper layer identifier in transport protocols. Identifier resolution: Early-binding; either performed via DNS lookup, some to-be-developed resolution service, or opportunistically (when the Initiator does not know the Responder's identity, only the address). Context establishment: A four-packet handshake performs a Diffie-Hellman key exchange and, when used with ESP, sets up the context for the SA. Per-packet context tag: The SPI in the SA serves as a compressed representation of the HITs in every data packet. Locator management: Mobility extensions to the base protocol allow IP addresses associated with an ESP tunnel to be added, changed, and authenticated. 3.1.3 Multihoming L3 Shim Upper layer identifier: Some kind of IP address, although the exact semantics are still unsettled. Identifier resolution: Performed at the end-hosts (early binding). Context establishment: An as-yet unspecified protocol will be used to establish context when the upper layer identifiers in use start to diverge from the locators in use. Per-packet context tag: Options include using predefined relationships between identifier addresses and locator addresses, use of the flow label, or use of a new extension header. Henderson Expires August 14, 2005 [Page 7] Internet-Draft Generalizing the HIP base protocol February 2005 Locator management: Locators may be related to each other cryptographically, or may be authenticated via some as-yet unspecified protocol. 3.1.4 i3 (Internet Indirection Infrastructure) Upper layer identifier: The i3 tag. Identifier resolution: Performed in the i3 forwarding infrastructure, since the act of sending and receiving packets is decoupled (late binding). Context establishment: Directives for receiving packets sent to particular tags are explicitly inserted into the forwarding infrastructure by receiving hosts; no end-to-end context need be established. Per-packet context tag: Explicitly inserted in the IP packet: [IP | UDP | trigger stack | transport data]. Locator management: Locator management is handled by receivers and their interactions with the forwarding infrastructure. 3.2 Combinations and Syntheses Not surprisingly, a large number of variants and combinations of the above have been proposed, to aggregate the desirable properties of distinct proposals. For example, we have: o HIP/i3: The Host Identity Indirection Infrastructure (Hi3), advocated as a means of securing i3 with the HIP protocol [21]; o HIP/IKE: Proposal to use IKEv2 as the control plane for HIP [22]; o HIP/mobile IP: As presently defined, Mobile IP with Route Optimization resembles HIP mobility. It has been suggested that HIP could be used to secure the route optimization of mobile IPv6; o HIP/multi6: A lighter-weight variant of HIP was proposed, to address the concerns of HIP's requirement for public-key operations and the need to manage a new name space [23]; o MOBIKE: Working group defining mobility enhancements to IKEv2 that will allow SAs to persist across locator changes [24]; and o HIP Rendezvous Server (RVS): The HIP RVS is evolving to resemble a combination of a mobile IP home agent and a STUN [25] server. Our conjecture is that a generalized HIP protocol may make some of these combinations easier, as exemplified in Section 4.2 below. Henderson Expires August 14, 2005 [Page 8] Internet-Draft Generalizing the HIP base protocol February 2005 4. Implications for HIP work It seems wasteful to this author for so many experimental and early standardization efforts to be designing to similar goals yet arriving at slightly different protocol solutions. Given that HIP is an experimental effort, and that the overall acceptance of the architecture and its implications is still an open question, it is worth considering whether there are protocol or architectural elements of the above taxonomy that could be generalized in HIP, to allow a greater breadth of experimentation and future flexibility. If the HIP protocol elements were more modular, HIP-based protocols might be more useful to many of these efforts. In that sense, we should explore whether the currently proposed HIP protocol can be handled as a particular usage profile of a more general architecture. Note that recent decisions in the HIP working group to decouple ESP from the base protocol are an initial step in this direction. 4.1 Proposed changes to HIP The following changes would make HIP more flexible, at the expense of slightly more per-packet overhead in the protocol. The existing HIP could be mapped directly to the below as a specific usage profile. 4.1.1 Identifiers Allow the use of non-128-bit and non-HIT identifiers. For example, the initial locators might be used as the upper layer identifiers, or some other flat name (other than HIT). In addition, we should consider whether larger than 128-bit HITs may be needed in the future for HIP. If in the HIP header, a TLV were used instead of the bare 128-bit HITs, the context establishment protocol may be useful for other non-HIP uses. Thus, the HIP header would look like: Henderson Expires August 14, 2005 [Page 9] Internet-Draft Generalizing the HIP base protocol February 2005 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Payload Len | Type | VER. | RES. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Controls | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender's Upper Layer Identifier (e.g., HIT) | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver's Upper Layer Identifier | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.1.2 Handshake The existing HIP handshake (I1 through R2) is based on the SIGMA family of key-exchange protocols [26] and should continue to be the basis for the context handshake for the existing HIP usage profile, but there should also be other possibilities allowed, especially for impoverished devices that are willing to trade some security for less computation (public key signatures). The multi6 WIMP proposal based on hash chains [27] is one such alternative context-establishment handshake. One way to potentially support multiple protocol semantics would be to support a handshake-type parameter in the I1. The R1 could accept or reply with a list of handshake-types that it supports (i.e., similar to how the HIP- and ESP-TRANSFORM are negotiated today). An alternative to another TLV that saves bits but is less flexible is to use some of the HIP Control bits. The handshake could also potentially be delayed, such as in the multi6 shim proposals (in which one possible use case is to avoid performing any context handshake until a locator set has to change). 4.1.3 Mandatory parameters There should be very few mandatory parameters for a given HIP packet type, in general. However, for a specific usage profile, there will be mandatory parameters. For example, when using the current HIP Henderson Expires August 14, 2005 [Page 10] Internet-Draft Generalizing the HIP base protocol February 2005 profile, R1 MUST contain PUZZLE, but not necessarily when using another profile. The main mandatory parameters are the identifier TLVs discussed above in Section 4.1.1, which are always the first two parameters in the HIP header. The HIP base protocol specification should not include statements such as making ESP mandatory for a HIP implementation. 4.1.4 Per-packet context This step (towards more flexibility) has already been agreed upon by the working group, allowing ESP to be one of potentially other per-packet contexts used with HIP (including possibly SRTP [29] or another shim header such as the M6 header proposed in SIM [15]). 4.2 Example Uses Presently, the HIP drafts are being reworked and extended to cover NAT traversal and middlebox registration issues. The extensions will be based on established techniques including STUN [25], and MIDCOM and NSIS WG work. If a generalized HIP protocol were available and had solved all of these issues, they may apply more generally to other protocol efforts. For example, NAT traversal techniques could perhaps be common across multiple protocols. Likewise, there are probably techniques in use in other protocols that could be leveraged in the generalized HIP. For example, micromobility extensions to mobile IP could be folded into a general framework and made to apply to non-mobile-IP mobility as well. 4.2.1 Securing MIPv6 Binding Update One security aspect of Mobile IPv6 is that, while the mobile host can be assumed to have a security relationship (shared secret) with the home agent, it has no such assurance with an arbitrary correspondent node. This has made securing the mobile IPv6 route optimization mechanism more involved. Presently, a mobile host using Mobile IPv6 can elect to send a Binding Update to any correspondent node that implements the extensions. Prior to the binding update, a return routability check through the home network is needed to create a binding management key (Kbm). This binding management key does not have persistence across mobile node readdressing. An alternative may be to use the Diffie Hellman key exchange defined in the HIP base protocol to create keying material to authenticate binding updates, and to use the HIP mobility management technique (UPDATE/UPDATE ACK and address check) to authenticate via a keyed Henderson Expires August 14, 2005 [Page 11] Internet-Draft Generalizing the HIP base protocol February 2005 MAC. For example, the mobile node could initiate a "mobile IP-based" HIP exchange with the correspondent node using its home address as the source upper layer identifier, the correspondent node's IP address as the destination upper layer identifier, and some parameter or control bit to declare that the HIP I1 has "mobile IP" semantics. The client puzzle and nonce could be optionally included in the HIP R1, DIFFIE_HELLMAN would be mandatory, and signatures would be optional (variants could be defined that still used public keys for authentication if desired, and allowed their inclusion as additional HIP parameters). One possible benefit of the above is that it more closely aligns with the presently defined mobile IPv6-- the handshake can be deferred (initiated, perhaps, only before a mobile node is ready to move), and there is no reliance on public key operations, although there is a path forward to add such if so desired. Use of a home agent becomes optional (via HIP rendezvous server). The overall approach provides a possible migration path from an enhanced mobile-IP-based solution (which does not require new name space management) to public-key based extensions that may (HIP backed up by PKI or certificates) or may not (opportunistic HIP, or Purpose-Built Keys) involve strong identity authentication. 4.2.2 Site multiHoming by IPv6 interMediation (shim6) The shim6 WG is expected to be chartered to produce an IPv6 site multihoming solution based on a specific network layer shim architecture. The overall approach is discussed in a recent multi6 draft "Multihoming L3 Shim Approach" [13]. Some features of this solution have already been defined by the multi6 design team (e.g., hash-based addresses) [19], while other elements such as the context management protocol are still unspecified. Some goals stated in [13] are to use routable IP locators as the upper layer identifiers, and to permit context establishment to be deferred or to occur asynchronously with data packets. The multi6 functional decomposition [10] describes a number of functions that could potentially be met by a generalized HIP protocol that used routable IP addresses (or even centrally-assigned unique local addresses [28]) as upper layer identifiers. Specifically, the identified M6 host-pair establishment exchange: Henderson Expires August 14, 2005 [Page 12] Internet-Draft Generalizing the HIP base protocol February 2005 Initiator Receiver | P1 | |-------------------------->| | P2 | |<--------------------------| | P3 | |-------------------------->| | P4 | |<--------------------------| could be supported by a generalized HIP that allowed for non-HIT identifiers, and alternatives for shared secret generation (e.g., hash chains such as described in WIMP-F [27] could be defined for such a usage profile). Additionally, it seems that if locator set management techniques (Section 4 of [10]) are to be developed as part of the shim6 solution, such techniques should be reused and not reinvented by HIP. Henderson Expires August 14, 2005 [Page 13] Internet-Draft Generalizing the HIP base protocol February 2005 5. Security Considerations There are clearly security issues related to mixing and matching protocol elements, in terms of potentially weakening security properties of a given protocol such as HIP. However, we do not address the security properties of any particular usage profile supported by a more generalized protocol, but leave that instead for other drafts. Henderson Expires August 14, 2005 [Page 14] Internet-Draft Generalizing the HIP base protocol February 2005 6. IANA Considerations No specific proposals in this draft. Henderson Expires August 14, 2005 [Page 15] Internet-Draft Generalizing the HIP base protocol February 2005 7. Acknowledgments Jeff Ahrenholz, Pekka Nikander, and Jukka Ylitalo provided comments on an earlier version of this draft. 8 References [1] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-01 (work in progress), October 2004. [2] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [3] Castineyra, I., Chiappa, N. and M. Steenstrup, "The Nimrod Routing Architecture", RFC 1992, August 1996. [4] Stoica, I., Adkins, D., Zhuang, S., Shenker, S. and S. Surana, "Internet Indirection Infrastructure (i3)", Proceedings of ACM SIGCOMM, August 2002. [5] Francis, P. and R. Gummadi, "IPNL: A NAT-Extended Internet Architecture", Proceedings of ACM Sigcomm Conference, August 2001. [6] Touch, J. and V. Pingali, "DataRouter: A Network-Layer Service for Application-Layer Forwarding", Proceedings of International Workshop on Active Networks (IWAN), December 2003. [7] Tschudin, C. and R. Gold, "Network Pointers", ACM Computer Communications Review, January 2003. [8] Clark, D., Braden, R., Falk, A. and V. Pingali, "FARA: Reorganizing the Addressing Architecture", Proceedings of ACM SIGCOMM FDNA Workshop, August 2003. [9] Cheriton, D. and M. Gritter, "TRIAD: A New Next-Generation Internet Architecture", Unpublished, available at Citeseer, July 2000. [10] Bagnulo, M. and J. Arkko, "Functional decomposition of the M6 protocol", draft-ietf-multi6-functional-dec-00 (work in progress), December 2004. [11] Moskowitz, R., "Host Identity Protocol Architecture", draft-ietf-hip-arch-02 (work in progress), January 2005. [12] Balakrishnan, H., Lakshminarayanan, K., Ratnasamy, S., Shenker, Henderson Expires August 14, 2005 [Page 16] Internet-Draft Generalizing the HIP base protocol February 2005 S., Stoica, I. and M. Walfish, "A Layered Naming Architecture for the Internet", Proceedings of ACM SIGCOMM, August 2004. [13] Nordmark, E. and M. Bagnulo, "Multihoming L3 Shim Approach", draft-ietf-multi6-l3shim-00 (work in progress), January 2005. [14] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", draft-ietf-ipv6-unique-local-addr-09 (work in progress), January 2005. [15] Nordmark, E., "Strong Identity Multihoming using 128 bit Identifiers (SIM/CBID128)", draft-nordmark-multi6-sim-01 (work in progress), October 2003. [16] Crocker, D., "MULTIPLE ADDRESS SERVICE FOR TRANSPORT (MAST):AN EXTENDED PROPOSAL", draft-crocker-mast-proposal-01 (work in progress), September 2003. [17] Crocker, D., "Framework for Common Endpoint Locator Pools", draft-crocker-celp-00 (work in progress), February 2004. [18] Arkko, J., "Failure Detection and Locator Selection in Multi6", draft-arkko-multi6dt-failure-detection-00 (work in progress), October 2004. [19] Bagnulo, M., "Hash Based Addresses (HBA)", draft-ietf-multi6-hba-00 (work in progress), December 2004. [20] Nikander, P., "End-Host Mobility and Multi-Homing with Host Identity Protocol", draft-ietf-hip-mm-00 (work in progress), October 2004. [21] Nikander, P., "Host Identity Indirection Infrastructure (Hi3)", draft-nikander-hiprg-hi3-00 (work in progress), June 2004. [22] Yan, R., "A proposal to replace HIP base exchange with IKE-H method", draft-yan-hip-ike-h-00 (work in progress), November 2004. [23] Nikander, P., "Considerations on HIP based IPv6 multi-homing", draft-nikander-multi6-hip-01 (work in progress), July 2004. [24] Kivinen, T. and H. Tschofenig, "Design of the MOBIKE protocol", draft-ietf-mobike-design-01 (work in progress), January 2005. [25] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003. Henderson Expires August 14, 2005 [Page 17] Internet-Draft Generalizing the HIP base protocol February 2005 [26] Krawczyk, H., "The IKE-SIGMA Protocol", draft-krawczyk-ipsec-ike-sigma-00 (work in progress), November 2001. [27] Ylitalo, J., "Weak Identifier Multihoming Protocol (WIMP)", draft-ylitalo-multi6-wimp-01 (work in progress), July 2004. [28] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", draft-hinden-ipv6-global-local-addr-02 (work in progress), July 2003. [29] Baugher, M., McGrew, D., Naslund, M., Carrara, E. and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. Author's Address Tom Henderson The Boeing Company P.O. Box 3707 Seattle, WA USA EMail: thomas.r.henderson@boeing.com Henderson Expires August 14, 2005 [Page 18] Internet-Draft Generalizing the HIP base protocol February 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Henderson Expires August 14, 2005 [Page 19]