Network Working Group J. Laganier Internet-Draft DoCoMo Euro-Labs Expires: December 9, 2006 T. Koponen HIIT L. Eggert NEC June 7, 2006 Host Identity Protocol (HIP) Registration Extension draft-ietf-hip-registration-02 Status of this Memo 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 becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 December 9, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document specifies a registration mechanism for the Host Identity Protocol (HIP) that allows hosts to register with services, such as HIP rendezvous servers or middleboxes. Laganier, et al. Expires December 9, 2006 [Page 1] Internet-Draft HIP Registration Extension June 2006 1. Introduction This document specifies an extension to the Host Identity Protocol (HIP) [RFC4423]. The extension provides a generic means for a host to register with a service. The service may, for example, be a HIP rendezvous server [I-D.ietf-hip-rvs] or a middlebox [RFC3234]. This document makes no further assumptions about the exact type of service. Likewise, this document does not specify any mechanisms to discover the presence of specific services or means to interact with them after registration. Future documents may describe those operations. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Terminology This section defines terminology that is used throughout the remainder of this document. Please note that terminology shared with other documents is defined elsewhere [RFC4423]. Requester: a HIP node registering with a HIP registrar to request registration for a service. Registrar: a HIP node offering registration for one or more services. Service: a facility that provides requesters with new capabilities or functionalities operating at the HIP layer. Examples include firewalls that support HIP traversal or HIP rendezvous servers. Registration: shared state stored by a requester and a registrar, allowing the requester to benefit from one or more HIP services offered by the registrar. Each registration has an associated finite lifetime. Requesters can extend established registrations through re- registration (i.e., perform a refresh). Registration Type: an identifier for a given service in the registration protocol. For example, the rendezvous service is identified by a specific registration type. Laganier, et al. Expires December 9, 2006 [Page 2] Internet-Draft HIP Registration Extension June 2006 3. HIP Registration Extension Overview This document does not specify the means by which a requester discovers the availability of a service, or how a requester locates a registrar. After a requester has discovered a registrar, it either initiates HIP base exchange or uses an existing HIP association with the registrar. In both cases, registrars use additional parameters that the remainder of this document defines to announce their quality and grant or refuse registration. Requesters use corresponding parameters to register with the service. Both the registrar and the requester MAY also include in the messages exchanged additional HIP parameters specific to the registration type implicated. Other documents will define parameters and how they shall be used. The following sections describe the differences between this registration handshake and the standard HIP base exchange [I-D.ietf-hip-base] . 3.1. Registrar Announcing its Ability A host that is capable and willing to act as a registrar SHOULD include a REG_INFO parameter in the R1 packets it sends during all base exchanges. If it is currently unable to provide services due to transient conditions, it SHOULD include an empty REG_INFO, i.e., one with no services listed. If services can be provided later, it SHOULD send UPDATE packets indicating the current set of services available in a new REG_INFO parameter to all hosts it is associated with. 3.2. Requester Requesting Registration To request registration with a service, a requester constructs and includes a corresponding REG_REQUEST parameter in an I2 or UPDATE packet it sends to the registrar. If the requester has no HIP association established with the registrar, it SHOULD already send the REG_REQUEST in the I2 packet. This minimizes the number of packets that need to be exchanged with the registrar. A registrar MAY end a HIP association that does not carry a REG_REQUEST by including a NOTIFY with the type REG_REQUIRED in the R2. In this case, no HIP association is created between the hosts. The REG_REQUIRED notification error type is TBD. 3.3. Registrar Granting or Refusing Service(s) Registration Once registration has been requested, the registrar is able to authenticate the requester based on the host identity included in I2. It then verifies the host identity is authorized to register with the requested service(s), based on local policies. The details of this authorization procedure depend on the type of requested service(s) Laganier, et al. Expires December 9, 2006 [Page 3] Internet-Draft HIP Registration Extension June 2006 and on the local policies of the registrar, and are therefore not further specified in this document. After authorization, the registrar includes in its response (i.e., an R2 or an UPDATE, respectively, depending on whether the registration was requested during the base exchange, or using an existing association) a REG_RESPONSE parameter containing the service(s) type(s) for which it has authorized registration, and zero or more REG_FAILED parameter containing the service(s) type(s) for which it has not authorized registration or registration has failed for other reasons. In particular, REG_FAILED with a failure type of zero indicates the service(s) type(s) that require further credentials for registration. If the registrar requires further authorization and the requester has additional credentials available, the requester SHOULD try to again register with the service after the HIP association has been established. The precise means of establishing and verifying credentials are beyond the scope of this document and are expected to be defined in other documents. Successful processing of a REG_RESPONSE parameter creates registration state at the requester. In a similar manner, successful processing of a REG_REQUEST parameter creates registration state at the registrar and possibly at the service. Both the requester and registrar can cancel a registration before it expires, if the services afforded by a registration are no longer needed by the requester, or cannot be provided any longer by the registrar (for instance, because its configuration has changed). +-----+ I1 +-----+-----+ | |--------------------->| | S1 | | |<---------------------| | | | | R1(REG_INFO:S1,S2) | +-----+ | RQ | | R | S2 | | | I2(REG_REQ:S1) | | | | |--------------------->| +-----+ | |<---------------------| | S3 | | | R2(REG_RESP:S1) | | | +-----+ +-----+-----+ Laganier, et al. Expires December 9, 2006 [Page 4] Internet-Draft HIP Registration Extension June 2006 +-----+ +-----+-----+ | | UPDATE(REG_INFO:S) | | | | |<---------------------| | | | RQ |--------------------->| R | S | | | UPDATE(REG_REQ:S) | | | | | UPDATE(REG_RESP:S) | | | | |<---------------------| | | +-----+ +-----+-----+ 4. Parameter Formats and Processing This section describes the format and processing of the new parameters introduced by the HIP registration extension. 4.1. Encoding Registration Lifetimes with Exponents The HIP registration uses an exponential encoding of registration lifetimes. This allows compact encoding of 255 different lifetime values ranging from 4 ms to 178 days into an 8-bit integer field. The lifetime exponent field used throughout this document MUST be interpreted as representing the lifetime value 2^((lifetime - 64)/8) seconds. Laganier, et al. Expires December 9, 2006 [Page 5] Internet-Draft HIP Registration Extension June 2006 4.2. REG_INFO 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Min Lifetime | Max Lifetime | Reg Type #1 | Reg Type #2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | ... | Reg Type #n | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type [ TBD by IANA (930) ] Length Length in octets, excluding Type, Length, and Padding. Min Lifetime Minimum registration lifetime. Max Lifetime Maximum registration lifetime. Reg Type The registration types offered by the registrar. Other documents will define specific values for registration types. Reg Type Service -------- ------- 0-200 Reserved by IANA 201-255 Reserved by IANA for private use Registrars include the parameter in R1 packets in order to announce their registration capabilities. The registrar SHOULD include the parameter in UPDATE packets when its service offering has changed. HIP_SIGNATURE_2 protects the parameter within the R1 packets. Laganier, et al. Expires December 9, 2006 [Page 6] Internet-Draft HIP Registration Extension June 2006 4.3. REG_REQUEST 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | Reg Type #1 | Reg Type #2 | Reg Type #3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | ... | Reg Type #n | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type [ TBD by IANA (932) ] Length Length in octets, excluding Type, Length, and Padding. Lifetime Requested registration lifetime. Reg Type The preferred registration types in order of preference. Other documents will define specific values for registration types. Reg Type Service -------- ------- 0-200 Reserved by IANA 201-255 Reserved by IANA for private use A requester includes the REG_REQUEST parameter in I2 or UPDATE packets to register with a registrar's service(s). If the REG_REQUEST parameter is in an UPDATE packet, the registrar MUST NOT modify the registrations of registration types which are not listed in the parameter. Moreover, the requester MUST NOT include the parameter unless the registrar's R1 packet or latest received UPDATE packet has contained a REG_INFO parameter with the requested registration types. The requester MUST NOT include more than one REG_REQUEST parameter in its I2 or UPDATE packets, while the registrar MUST be able to process one or more REG_REQUEST parameters in received I2 or UPDATE packets. When the registrar is requested a registration which lifetime is either smaller or greater than the minimum or maximum lifetime, respectively, then it SHOULD grant the registration for the minimum or maximum lifetime, respectively. HIP_SIGNATURE protects the parameter within the I2 and UPDATE packets. Laganier, et al. Expires December 9, 2006 [Page 7] Internet-Draft HIP Registration Extension June 2006 4.4. REG_RESPONSE 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | Reg Type #1 | Reg Type #2 | Reg Type #3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | ... | Reg Type #n | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type [ TBD by IANA (934) ] Length Length in octets, excluding Type, Length, and Padding. Lifetime Granted registration lifetime. Reg Type The granted registration types in order of preference. Other documents will define specific values for registration types. Reg Type Service -------- ------- 0-200 Reserved by IANA 201-255 Reserved by IANA for private use The registrar SHOULD includes an REG_RESPONSE parameter in its R2 or UPDATE packet only if a registration has successfully completed. The registrar MUST NOT include more than one REG_RESPONSE parameter in its R2 or UPDATE packets, while the requester MUST be able to process one or more REG_RESPONSE parameters in received R2 or UPDATE packets. The requester MUST be prepared to receive any registration lifetime, included ones beyond the minimum and maximum lifetime indicated in the REG_INFO parameter. It MUST NOT expect that the returned lifetime will be the requested one, even in the case that the requested lifetime falls within the announced minimum and maximum. HIP_SIGNATURE protects the parameter within the R2 and UPDATE packets. Laganier, et al. Expires December 9, 2006 [Page 8] Internet-Draft HIP Registration Extension June 2006 4.5. REG_FAILED 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Failure Type | Reg Type #1 | Reg Type #2 | Reg Type #3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | ... | Reg Type #n | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type [ TBD by IANA (936) ] Length Length in octets, excluding Type, Length, and Padding. Failure Type Reason for failure. Reg Type The registration types that failed with the specified reason. Other documents will define specific values for registration types. Reg Type Service -------- ------- 0-200 Reserved by IANA 201-255 Reserved by IANA for private use Failure Type Reason ------------ -------------------------------------------- 0 Registration requires additional credentials 1 Registration type unavailable 2-200 Reserved by IANA 201-255 Reserved by IANA for private use A failure type of zero means a registrar requires additional credentials to authorize a requester to register with the registration types listed in the parameter. A failure type of one means that the requested service type is unavailable at the registrar. Other failure types than zero (0) and one (1) have not been defined. The registrar SHOULD include the REG_FAILED parameter in its R2 or UPDATE packet, if registration with the registration types listed has not completed successfully and a requester is asked to try again with additional credentials. HIP_SIGNATURE protects the parameter within the R2 and UPDATE packets. Laganier, et al. Expires December 9, 2006 [Page 9] Internet-Draft HIP Registration Extension June 2006 5. Establishing and Maintaining Registrations Establishing and/or maintaining a registration may require additional information not available in the transmitted REG_REQUEST or REG_RESPONSE parameters. Therefore, registration type definitions MAY define dependencies for HIP parameters that are not defined in this document. Their semantics are subject to the specific registration type specifications. The minimum lifetime both registrars and requesters MUST support is 10 seconds, while they SHOULD support a maximum lifetime of 120 seconds, at least. These values define a baseline for the specification of services based on the registration system. They were chosen to be neither to short nor too long, and to accommodate for existing timeouts of state established in middleboxes (e.g. NATs and firewalls.) A zero lifetime is reserved for canceling purposes. Requesting a zero lifetime for a registration type equals to canceling the registration of that type. A requester MAY cancel a registration before it expires by sending a REG_REQ to the registrar with a zero lifetime. A registrar SHOULD respond and grant a registration with a zero lifetime. A registrar (and an attached service) MAY cancel a registration before it expires, at its own discretion. However, if it does so, it SHOULD send a REG_RESPONSE with a zero lifetime to all registered requesters. 6. Security Considerations This section discusses the threats on the HIP registration protocol, and their implications on the overall security of HIP. In particular, it argues that the extensions described in this document do not introduce additional threats to HIP. The extensions described in this document rely on the HIP base exchange and do not modify its security characteristics, e.g., digital signatures or HMAC. Hence, the only threat introduced by these extensions are related to the creation of soft registration state at the registrar. Registrars act on a voluntary basis and are willing to accept to be a responder and to then create HIP associations with a number of previously unknown hosts. Because they have to store HIP association state anyway, adding a certain amount of time-limited HIP registration state should not introduce and serious additional threats, especially because HIP registrars may cancel registrations at any time at their own discretion, e.g., because of resource Laganier, et al. Expires December 9, 2006 [Page 10] Internet-Draft HIP Registration Extension June 2006 constraints during an attack. 7. IANA Considerations This section is to be interpreted according to [RFC2434]. This document updates the IANA Registry for HIP Parameters Types by assigning new HIP Parameter Types values for the new HIP Parameters defined in this document: o REG_INFO (defined in Section 4.2) o REG_REQUEST (defined in Section 4.3) o REG_RESPONSE (defined in Section 4.4) o REG_FAILED (defined in Section 4.5) IANA needs to open a new registry for registration types. This document does not define registration types but makes the following reservations: Reg Type Service -------- ------- 0-200 Reserved by IANA 201-255 Reserved by IANA for private use Adding a new type requires new IETF specifications. IANA needs to open a new registry for registration failure types. This document makes the following failure types definitions and reservations: Failure Type Reason ------------ -------------------------------------------- 0 Registration requires additional credentials 1 Registration type unavailable 2-200 Reserved by IANA 201-255 Reserved by IANA for private use Adding a new type requires new IETF specifications. 8. Acknowledgments The following people (in alphabetical order) have provided thoughtful and helpful discussions and/or suggestions that have helped to Laganier, et al. Expires December 9, 2006 [Page 11] Internet-Draft HIP Registration Extension June 2006 improve this document: Jeffrey Ahrenholz, Miriam Esteban, Mika Kousa, Pekka Nikander and Hannes Tschofenig. Julien Laganier and Lars Eggert are partly funded by Ambient Networks, a research project supported by the European Commission under its Sixth Framework Program. The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the Ambient Networks project or the European Commission. 9. References 9.1. Normative References [I-D.ietf-hip-base] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-05 (work in progress), March 2006. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 9.2. Informative References [I-D.ietf-hip-rvs] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Rendezvous Extension", draft-ietf-hip-rvs-04 (work in progress), October 2005. [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002. [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006. Laganier, et al. Expires December 9, 2006 [Page 12] Internet-Draft HIP Registration Extension June 2006 Authors' Addresses Julien Laganier DoCoMo Communications Laboratories Europe GmbH Landsberger Strasse 312 Munich 80687 Germany Phone: +49 89 56824 231 Email: julien.ietf@laposte.net URI: http://www.docomolab-euro.com/ Teemu Koponen Helsinki Institute for Information Technology Advanced Research Unit (ARU) P.O. Box 9800 Helsinki FIN-02015-HUT Finland Phone: +358 9 45 1 Email: teemu.koponen@hiit.fi URI: http://www.hiit.fi/ Lars Eggert NEC Network Laboratories Kurfuerstenanlage 36 Heidelberg 69115 Germany Phone: +49 6221 90511 43 Fax: +49 6221 90511 55 Email: lars.eggert@netlab.nec.de URI: http://www.netlab.nec.de/ Laganier, et al. Expires December 9, 2006 [Page 13] Internet-Draft HIP Registration Extension June 2006 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 (2006). 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. Laganier, et al. Expires December 9, 2006 [Page 14]