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
[] 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]