Network Working Group J. Laganier Request for Comments: 5203 DoCoMo Euro-Labs Category: Experimental T. Koponen HIIT L. Eggert Nokia April 2008 Host Identity Protocol (HIP) Registration Extension Status of This Memo This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
AbstractThis 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. RFC5201]. The extension provides a generic means for a host to register with a service. The service may, for example, be a HIP rendezvous server [RFC5204] 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 RFC 2119 [RFC2119].
RFC4423], the HIP specification [RFC5201], and the HIP Rendezvous Extension [RFC5204], this document defines and uses the following terms: 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. RFC5201].
If the registrar requires further authorization and the requester has additional credentials available, the requester SHOULD try to register again 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) | | | +-----+ +-----+-----+ A requester (RQ) registers with a registrar (R) of services (S1) and (S2), with which it has no current HIP association. +-----+ +-----+-----+ | | UPDATE(REG_INFO:S) | | | | |<---------------------| | | | RQ |--------------------->| R | S | | | UPDATE(REG_REQ:S) | | | | | UPDATE(REG_RESP:S) | | | | |<---------------------| | | +-----+ +-----+-----+ A requester (RQ) registers with a registrar (R) of services (S), with which it currently has a HIP association established.
Section 7 for more information. 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.
Section 7 for more information. 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 that 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 receives a registration with a lifetime that 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.
Section 7 for more information. 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, including 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 when the requested lifetime falls within the announced minimum and maximum. HIP_SIGNATURE protects the parameter within the R2 and UPDATE packets.
Section 7 for more information. 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. Failure types other 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.
RFC2434]. This document updates the IANA Registry for HIP Parameter 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 has allocated the Notify Message Type code 51 for the REG_REQUIRED notification error type in the Notify Message Type registry. IANA has opened a new registry for registration types. This document does not define registration types but makes the following reservations: Reg Type Service -------- ------- 0-200 Unassigned 201-255 Reserved by IANA for private use Adding a new type requires new IETF specifications. IANA has opened a new registry for registration failure types. This document makes the following failure type definitions and reservations: Failure Type Reason ------------ -------------------------------------------- 0 Registration requires additional credentials 1 Registration type unavailable 2-200 Unassigned 201-255 Reserved by IANA for private use Adding a new type requires new IETF specifications.
[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. [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008. [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. [RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Rendezvous Extension", RFC 5204, April 2008.
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: firstname.lastname@example.org URI: http://www.hiit.fi/ Lars Eggert Nokia Research Center P.O. Box 407 Nokia Group 00045 Finland Phone: +358 50 48 24461 EMail: email@example.com URI: http://research.nokia.com/people/lars_eggert/
Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. 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, THE IETF TRUST 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. Intellectual Property 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 firstname.lastname@example.org.