One document matched: draft-ietf-hip-rfc5203-bis-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY RFC2434 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2434.xml'>
<!ENTITY RFC3234 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3234.xml'>
<!ENTITY RFC4423 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4423.xml'>
<!ENTITY % I-D.ietf-hip-rfc5201-bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-hip-rfc5201-bis.xml" >
<!ENTITY % I-D.ietf-hip-rfc5204-bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-hip-rfc5204-bis.xml" >
]>
<?rfc rfcedstyle="yes" ?>
<?rfc subcompact="no" ?>
<?rfc sortrefs="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc comments="yes" ?>
<?rfc toc="yes" ?>
<rfc category="std" obsoletes="5203" ipr="trust200902">
<front>
<title abbrev="HIP Registration Extension">
Host Identity Protocol (HIP) Registration Extension
</title>
<author initials="J." surname="Laganier" fullname="Julien Laganier">
<organization abbrev="Juniper Networks">
Juniper Networks
</organization>
<address> <postal>
<street>1094 North Mathilda Avenue
</street>
<city>San Diego</city>
<region>CA</region>
<code>94089</code>
<country>USA</country>
</postal>
<phone>+1 408 936 0385</phone>
<email>julien.ietf@gmail.com</email>
</address>
</author>
<author initials="T." surname="Koponen" fullname="Teemu Koponen">
<organization abbrev="HIIT">Helsinki Institute for Information Technology</organization>
<address>
<postal>
<street>Advanced Research Unit (ARU)</street>
<street>P.O. Box 9800</street>
<code>FIN-02015-HUT</code> <city>Helsinki</city>
<country>Finland</country>
</postal>
<phone>+358 9 45 1</phone>
<email>teemu.koponen@iki.fi</email>
<uri>http://www.hiit.fi/</uri>
</address>
</author>
<author initials="L." surname="Eggert" fullname="Lars Eggert">
<organization abbrev="Nokia">Nokia Research Center</organization>
<address>
<postal>
<street>P.O. Box 407</street>
<code>00045</code> <city>Nokia Group</city>
<country>Finland</country>
</postal>
<phone>+358 50 48 24461</phone>
<email>lars.eggert@nokia.com</email>
<uri>http://research.nokia.com/people/lars_eggert/</uri>
</address>
</author>
<date year="2011"/>
<area>Internet</area>
<workgroup> </workgroup>
<!-- [rfced] Please insert any additional keywords (beyond those that appear in
the title) for use on http://www.rfc-editor.org/rfcsearch.html. -->
<keyword>HIP</keyword>
<keyword>host identity protocol</keyword>
<keyword>host identity payload</keyword>
<keyword>registration</keyword>
<abstract>
<t>
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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
This document specifies an extension to the <xref target="I-D.ietf-hip-rfc5201-bis">Host Identity
Protocol (HIP)</xref>. The
extension provides a generic means for a host to register with a
service.
The service may, for example, be a HIP rendezvous server <xref
target="I-D.ietf-hip-rfc5204-bis"/> or a middlebox <xref
target="RFC3234"/>.
</t>
<t>
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.
</t>
<t>
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 <xref target="RFC2119"/>.
</t>
</section>
<section title="Terminology">
<t>
In addition to the terminology defined in the <xref target="RFC4423">HIP Architecture</xref>,
the <xref target="I-D.ietf-hip-rfc5201-bis">HIP specification</xref>,
and the <xref target="I-D.ietf-hip-rfc5204-bis">HIP Rendezvous Extension</xref>, this document
defines and uses the following terms:
</t>
<t>
<list style="hanging">
<t hangText="Requester:"><vspace blankLines="0"/>
a HIP node registering with a HIP registrar to request registration
for a service.
</t>
<t hangText="Registrar:"><vspace blankLines="0"/>
a HIP node offering registration for one or more services.
</t>
<t hangText="Service:"><vspace blankLines="0"/>
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.
</t>
<t hangText="Registration:"><vspace blankLines="0"/>
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).
</t>
<t hangText="Registration Type:"><vspace blankLines="0"/>
an identifier for a given
service in the registration protocol. For example, the rendezvous
service is identified by a specific registration type.
</t>
</list>
</t>
</section>
<section title="HIP Registration Extension Overview">
<t>
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, which 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
<xref target="I-D.ietf-hip-rfc5201-bis" />.
</t>
<section title="Registrar Announcing Its Ability">
<t>
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.
</t>
</section>
<section title="Requester Requesting Registration">
<t>
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.
</t>
<t>
If the requester has no HIP association established with the
registrar, it SHOULD send the REG_REQUEST at the earliest
possibility, i.e., 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 51.
</t>
</section>
<section title="Registrar Granting or Refusing Service(s) Registration">
<t>
Once registration has been requested, the registrar is able to authenticate
the requester
based on the host identity included in I2. It then
verifies that 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) and on the local
policies of the registrar, and are therefore not further specified in this document.
</t>
<t>
After authorization, the registrar includes a REG_RESPONSE parameter
in its response, which contains the service type(s) for which it has
authorized registration, and zero or more REG_FAILED parameters
containing the service type(s) for which it has not authorized
registration or registration has failed for other reasons. This
response can be either an R2 or an UPDATE message, respectively,
depending on whether the registration was requested during the base
exchange, or using an existing association. In particular, REG_FAILED
with a failure type of zero indicates the service(s) type(s) that
require further credentials for registration.
</t>
<t>
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.
</t>
<?rfc needLines="3" ?>
<t>
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).
</t>
<figure title="A requester (RQ) registers with a registrar (R) of services (S1) and (S2), with which it has no current HIP association.">
<artwork align="center">
+-----+ I1 +-----+-----+
| |--------------------->| | S1 |
| |<---------------------| | |
| | R1(REG_INFO:S1,S2) | +-----+
| RQ | | R | S2 |
| | I2(REG_REQ:S1) | | |
| |--------------------->| +-----+
| |<---------------------| | S3 |
| | R2(REG_RESP:S1) | | |
+-----+ +-----+-----+
</artwork>
</figure>
<figure title="A requester (RQ) registers with a registrar (R) of services (S), with which it currently has a HIP association established.">
<artwork align="center">
+-----+ +-----+-----+
| | UPDATE(REG_INFO:S) | | |
| |<---------------------| | |
| RQ |--------------------->| R | S |
| | UPDATE(REG_REQ:S) | | |
| | UPDATE(REG_RESP:S) | | |
| |<---------------------| | |
+-----+ +-----+-----+
</artwork>
</figure>
</section>
</section>
<section title="Parameter Formats and Processing">
<t>
This section describes the format and processing of
the new parameters introduced by the HIP registration extension.
</t>
<section title="Encoding Registration Lifetimes with Exponents">
<t>
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.
</t>
</section>
<section title="REG_INFO" anchor="info">
<figure>
<artwork>
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 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.
</artwork>
</figure>
<t>
Other documents will define specific values for registration types.
See <xref target="iana"/> for more information.
</t>
<t>
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.
</t>
</section>
<section title="REG_REQUEST" anchor="request">
<figure>
<artwork>
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 932
Length Length in octets, excluding Type, Length, and Padding.
Lifetime Requested registration lifetime.
Reg Type The preferred registration types in order of preference.
</artwork>
</figure>
<t>
Other documents will define specific values for registration types.
See <xref target="iana"/> for more information.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>HIP_SIGNATURE protects the parameter within the I2 and UPDATE
packets.
</t>
</section>
<section title="REG_RESPONSE" anchor="response">
<figure>
<artwork>
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 934
Length Length in octets, excluding Type, Length, and Padding.
Lifetime Granted registration lifetime.
Reg Type The granted registration types in order of preference.
</artwork>
</figure>
<t>
Other documents will define specific values for registration types.
See <xref target="iana"/> for more information.
</t>
<t>
The registrar SHOULD includes an REG_RESPONSE parameter in
its R2 or UPDATE packet only if a registration has
successfully completed.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>HIP_SIGNATURE protects the parameter within the R2 and UPDATE
packets.
</t>
</section>
<section title="REG_FAILED" anchor="failed">
<figure>
<artwork align="center">
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 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.
Failure Type Reason
------------ --------------------------------------------
0 Registration requires additional credentials
1 Registration type unavailable
2-200 Unassigned
201-255 Reserved by IANA for private use
</artwork>
</figure>
<t>
Other documents will define specific values for registration types.
See <xref target="iana"/> for more information.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>HIP_SIGNATURE protects the parameter within the R2 and UPDATE
packets.
</t>
</section>
</section>
<section title="Establishing and Maintaining Registrations">
<t>
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.
</t>
<t>
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 too short nor too long, and to
accommodate for existing timeouts of state established in middleboxes (e.g., NATs and
firewalls.)
</t>
<t>
A zero lifetime is reserved for canceling purposes.
Requesting a zero lifetime for a registration type
is equal 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.
</t>
</section>
<section title="Security Considerations">
<t>
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.
</t>
<t>
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 is related to the
creation of soft registration state at the registrar.
</t>
<t>
Registrars act on a voluntary basis and are willing to accept being a
responder and then to 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 any serious additional threats, especially
because HIP registrars may cancel registrations at any time at their
own discretion, e.g., because of resource constraints during an
attack.
</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>
This section is to be interpreted according to the <xref target="RFC2434">Guidelines for Writing an
IANA Considerations Section in RFCs</xref>.
</t>
<t>
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:<list style="symbols">
<t>REG_INFO (defined in <xref target="info"/>)</t>
<t>REG_REQUEST (defined in <xref target="request"/>)</t>
<t>REG_RESPONSE (defined in <xref target="response"/>)</t>
<t>REG_FAILED (defined in <xref target="failed"/>)</t>
</list>
</t>
<t>
IANA has allocated the Notify Message Type code 51 for the
REG_REQUIRED notification error type in the Notify Message Type
registry.
</t>
<t>
IANA has opened a new registry for registration types.
This document does not define registration types but makes the following reservations:
<figure>
<artwork>
Reg Type Service
-------- -------
0-200 Unassigned
201-255 Reserved by IANA for private use
</artwork>
</figure>
Adding a new type requires new IETF specifications.
</t>
<t>
IANA has opened a new registry for registration failure types.
This document makes the following failure type definitions and reservations:
<figure>
<artwork>
Failure Type Reason
------------ --------------------------------------------
0 Registration requires additional credentials
1 Registration type unavailable
2-200 Unassigned
201-255 Reserved by IANA for private use
</artwork>
</figure>
Adding a new type requires new IETF specifications.
</t>
</section>
<section title="Acknowledgments">
<t>
The following people (in alphabetical order) have provided thoughtful and helpful
discussions and/or suggestions that have helped to improve this document:
Jeffrey Ahrenholz, Miriam Esteban, Mika Kousa, Pekka Nikander, and Hannes Tschofenig.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC2434;
&I-D.ietf-hip-rfc5201-bis;
&I-D.ietf-hip-rfc5204-bis;
</references>
<references title="Informative References">
&RFC4423;
&RFC3234;
</references>
<section title="Changes from RFC 5203">
<list style="symbols">
<t>
Updated references to revised HIP specifications.
</t>
</list>
</section>
</back>
<vspace blankLines="50" />
<!-- force a page break before Authors' Addresses -->
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 20:53:21 |