J. Laganier Internet-Draft LIP / Sun Microsystems Expires: August 12, 2005 T. Koponen HIIT L. Eggert NEC February 11, 2005 Host Identity Protocol (HIP) Registration Extension draft-koponen-hip-registration-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. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. 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 12, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document specifies a registration mechanism for the Host Identity Protocol that allows hosts to register with services. Laganier, et al. Expires August 12, 2005 [Page 1] Internet-Draft HIP Registration Extension February 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. HIP Registration Extension Overview . . . . . . . . . . . . . 4 4. Parameter Formats and Processing . . . . . . . . . . . . . . . 6 4.1 REG_INFO . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2 REG_REQUEST . . . . . . . . . . . . . . . . . . . . . . . 7 4.3 REG_RESPONSE . . . . . . . . . . . . . . . . . . . . . . . 8 4.4 REG_FAILED . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Establishing and Maintaining Registrations . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 10 9.2 Informative References . . . . . . . . . . . . . . . . . . . 11 Editorial Comments . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 A. Document Revision History . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . 13 Laganier, et al. Expires August 12, 2005 [Page 2] Internet-Draft HIP Registration Extension February 2005 1. Introduction This document specifies an extension to the Host Identity Protocol (HIP) [1]. The extension provides a generic means for a host to register with a service. The service may be, for example, a HIP rendezvous server [4] or a middlebox [5]. 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 RFC 2119 [2]. 2. Terminology This section defines terminology used throughout the reminder of this document. Please note that common terminology is defined elsewhere [1]. Requester: a host registering to a registrar and thus requesting access to a service. Registrar: an entity with which requesters register. A registrar is a logical part of a service, but it may also be an independent entity and shared by a number of services. Service: a facility that amends the HIP capabilities or functionalities of its requesters. Examples include firewalls that support HIP traversal or rendezvous servers. Registration: state stored by a requester, a registrar, and a service that indicates the relationship the requester and service have. A registration is soft state; it has an associated finite lifetime. Requesters can extend established registrations through refresh operations (re-registration). Registration Type: an identifier that is transformable to a definition of a service. For example, a rendezvous registration type transforms to a rendezvous service. The registration type provides the means for Laganier, et al. Expires August 12, 2005 [Page 3] Internet-Draft HIP Registration Extension February 2005 a registrar to inform requesters about the services it represents, whereas requesters use registration types to indicate the services they wish register with. 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 its 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, the additional parameters defined in the remainder of this document are used to register with the service. If registering begins with the HIP base exchange, the differences to the standard HIP base exchange [3] are as follows: 1. A host that is capable and willing to act as a registrar includes a REG_INFO parameter in the R1 packets it sends during base exchanges. 2. To request registration with a service, a requester constructs and includes a corresponding REG_REQUEST parameter in the I2 packet it sends back to the registrar. 3. At this point, the registrar tries to authenticate the requester based on currently available information. The details of this authentication procedure are not specified in this document. If the requester is authorized to register for the requested service(s), the registrar includes a corresponding REG_RESPONSE parameter in its R2 response. If the requester is not authorized, the registrar MUST NOT include the REG_RESPONSE parameter. However, if the registrar needs further authorization, it includes a REG_FAILED parameter with a failure type of zero in its R2 response instead of a REG_RESPONSE parameter. 4. If the registrar required further authorization and the requester has more credentials to pass, the requester tries to register with the service again after the HIP association has been established. If the requester reuses an existing HIP association with the registrar, registering with a service occurs as follows: 1. A host that is capable and willing to act as a registrar includes a REG_INFO parameter in the R1 packets it sends during base Laganier, et al. Expires August 12, 2005 [Page 4] Internet-Draft HIP Registration Extension February 2005 exchanges or later announces its capabilities by sending the parameter in an UPDATE packet. 2. A requester constructs and includes a corresponding REG_REQUEST in an UPDATE packet and sends it. 3. The registrar tries to to authenticate requester based on then available information, as above. If the requester is authorized to register for the requested service(s), the registrar includes a corresponding REG_RESPONSE parameter in its UPDATE response. If the registrar needs further authorization, the registrar includes a REG_FAILED parameter with a failure type of zero in its UPDATE response. 4. If the registrar required further authorization and the requester has more credentials to pass, the requester tries to register with the service again with the additional credentials. If the requester has no HIP association established with the registrar, it SHOULD send the REG_REQUEST already in the I2 packet. This is to minimize the number of packets exchanged with the registrar. A registrar MAY drop 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. 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 the created registration before its expiration. The requester may also register to new services and refresh existing registrations by re-registering with the services. These operations occur through a REG_REQUEST/REG_RESPONSE parameter exchange carried in a pair of UPDATE packets. Laganier, et al. Expires August 12, 2005 [Page 5] Internet-Draft HIP Registration Extension February 2005 +-----+ +-----+-----+ | | I1 | | | | |--------------------->| | | | |<---------------------| | S | | | R1(REG_INFO) | +-----+ | | | | | | RQ | | R | S | | | I2(REG_REQ) | | | | |--------------------->| +-----+ | |<---------------------| | | | | R2(REG_RESP) | | S | | | | | | +-----+ +-----+-----+ Figure 1: A requester (RQ) registers to a registrar (R) of services (S). 4. Parameter Formats and Processing 4.1 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reg Type #1 | Reg Type #2 | Reg Type #n | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 100 (for testing purposes until IANA assigns a number) Length Length in octets, excluding Type, Length, and Padding. Min Lifetime The minimum registration validity time (in seconds). Max Lifetime The maximum registration validity time (in seconds). Reg Type The registration types offered by the registrar. Other documents will define specific values for registration types. 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. Laganier, et al. Expires August 12, 2005 [Page 6] Internet-Draft HIP Registration Extension February 2005 Signature protects the parameter within the R1 packets. 4.2 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 #n | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 102 (for testing purposes until IANA assigns a number) Length Length in octets, excluding Type, Length, and Padding. Lifetime The registration validity time (in seconds). Reg Type The preferred registration types in order of preference. Other documents will define specific values for registration types. 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 SHOULD NOT modify the registrations of registration types which are not listed in the parameter. Moreover, the requester SHOULD NOT include the parameter unless the registrar's I1 packet or an earlier received UPDATE packet has contained a REG_INFO parameter with the requested registration types. The REG_REQUEST parameter in the I2 packet MUST be protected by a signature. The requester SHOULD support inclusion of multiple instances of the REG_REQUEST parameter in its I2 packets. Laganier, et al. Expires August 12, 2005 [Page 7] Internet-Draft HIP Registration Extension February 2005 4.3 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 #n | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 104 (for testing purposes until IANA assigns a number) Length Length in octets, excluding Type, Length, and Padding. Lifetime The granted registration validity time (in seconds). Reg Type The granted registration types in order of preference. Other documents will define specific values for registration types. 0-200 Reserved by IANA 201-255 Reserved by IANA for private use The registrar SHOULD include the REG_RESPONSE parameter in its R2 or UPDATE packet only if a registration has successfully completed. The registrar SHOULD be able to process and reply with separate REG_RESPONSE parameters to multiple instances of the REG_REQUEST parameters in incoming I2 and UPDATE packets. Laganier, et al. Expires August 12, 2005 [Page 8] Internet-Draft HIP Registration Extension February 2005 4.4 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 #n | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 106 (for testing purposes until IANA assigns a number) 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. 0-200 Reserved by IANA 201-255 Reserved by IANA for private use A failure type of zero means a registrar needs more credentials to authorize a requester to register with the registration types listed in the parameter. Other failure types than zero have not been defined. The registrar SHOULD include the REG_FAILED parameter in its R2 or UPDATE packet if registering with registration types listed has not completed successfully and a requester is asked to try again with additional credentials. 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 is subject to the specific registration type specification. The minimum lifetime both registrars and requesters MUST support is 10 seconds, while they SHOULD support a maximum lifetime of 120 seconds, at least. [Comment.1] A zero lifetime is reserved for cancelling purposes. Requesting a zero lifetime for a registration type equals to cancelling 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 Laganier, et al. Expires August 12, 2005 [Page 9] Internet-Draft HIP Registration Extension February 2005 lifetime. A registrar SHOULD respond and grant a registration with a zero lifetime. The requester SHOULD prepare itself to the cancelling as the registered service can cancel the registration before the requester receives and processes a REG_RESP parameter acknowlegding the cancellation. 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 The security aspects of the HIP registration protocol are currently being investigated. 7. IANA Considerations IANA has assigned the HIP parameter type numbers TBD to the registration parameter types and the notification error type number TBD to REG_REQUIRED notification error. IANA needs to open a new registry for registration types. No types are defined in this document. 8. Acknowledgments The following people have provided thoughtful and helpful discussions and/or suggestions that have improved this document: Pekka Nikander, Hannes Tschofenig, and Mika Kousa. Lars Eggert was supported by the Ambient Networks project, partially funded by the European Commission under its Sixth Framework Programme. This document is provided "as is" and without any express or implied warranties, including, without limitation, the implied warranties of fitness for a particular purpose. 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 [1] Moskowitz, R., "Host Identity Protocol Architecture", draft-ietf-hip-arch-00 (work in progress), October 2004. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Laganier, et al. Expires August 12, 2005 [Page 10] Internet-Draft HIP Registration Extension February 2005 [3] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-01 (work in progress), October 2004. 9.2 Informative References [4] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Rendezvous Extensions", draft-ietf-hip-rvs-00 (work in progress), October 2004. [5] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002. [6] Saltzer, J., "On the Naming and Binding of Network Destinations", RFC 1498, August 1993. [7] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [8] Klensin, J., "Role of the Domain Name System (DNS)", RFC 3467, February 2003. Editorial Comments [Comment.1] LE: Shouldn't we have a MUST and SHOULD for minimum lifetime and a separate MUST and SHOULD for maximum lifetime here? Authors' Addresses Julien Laganier Sun Labs (Sun Microsystems) & LIP (CNRS/INRIA/ENSL/UCBL) 180, Avenue de l'Europe Saint Ismier CEDEX 38334 FR Phone: +33 476 188 815 EMail: ju@sun.com URI: http://research.sun.com/ Laganier, et al. Expires August 12, 2005 [Page 11] Internet-Draft HIP Registration Extension February 2005 Teemu Koponen Helsinki Institute for Information Technology Advanced Research Unit (ARU) P.O. Box 9800 Helsinki FIN-02015-HUT FI Phone: +358 9 45 1 EMail: teemu.koponen@hiit.fi URI: http://www.hiit.fi/ Lars Eggert NEC Network Laboratories Kurfuerstenanlage 36 Heidelberg 69115 DE Phone: +49 6221 90511 43 Fax: +49 6221 90511 55 EMail: lars.eggert@netlab.nec.de URI: http://www.netlab.nec.de/ Appendix A. Document Revision History +-----------+-------------------------------------------------------+ | Revision | Comments | +-----------+-------------------------------------------------------+ | 00 | Initial version. | +-----------+-------------------------------------------------------+ Laganier, et al. Expires August 12, 2005 [Page 12] Internet-Draft HIP Registration Extension 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. Laganier, et al. Expires August 12, 2005 [Page 13]