Host Identity Protocol (HIP) Registration Extension
draft-ietf-hip-rfc5203-bis-09

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. This document obsoletes RFC5203.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

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."

This Internet-Draft will expire on January 1, 2016.

Copyright Notice

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Terminology
• 3. HIP Registration Extension Overview
• 3.1. Registrar Announcing Its Ability
• 3.2. Requester Requesting Registration
• 3.3. Registrar Granting or Refusing Service(s) Registration
• 4. Parameter Formats and Processing
• 4.1. Encoding Registration Lifetimes with Exponents
• 4.2. REG_INFO
• 4.3. REG_REQUEST
• 4.4. REG_RESPONSE
• 4.5. REG_FAILED
• 5. Establishing and Maintaining Registrations
• 6. Security Considerations
• 7. IANA Considerations
• 8. Contributors
• 9. Acknowledgments
• 10. References
• 10.1. Normative References
• 10.2. Informative References
• Appendix A. Changes from RFC 5203
• Authors' Addresses

1. Introduction

This document specifies an extension to the Host Identity Protocol (HIP) [RFC7401]. 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-rfc5204-bis] 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].

2. Terminology

In addition to the terminology defined in the HIP Architecture [I-D.ietf-hip-rfc4423-bis], the HIP specification [RFC7401], and the HIP Rendezvous Extension [I-D.ietf-hip-rfc5204-bis], 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.

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, 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 requested. 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 [RFC7401].

3.1. Registrar Announcing Its Ability

A host that is capable and willing to act as a registrar vis-a-vis a specific requester SHOULD include a REG_INFO parameter in the R1 packets it sends during all base exchanges with that requester. 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 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.

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.

If the registrar knows the Host Identities (HIs) of all the hosts that are allowed to register for service(s), it SHOULD reject registrations from unknown hosts. However, since it may be infeasible to pre-configure the registrar with all the HIs, the registrar SHOULD also support HIP certificates [I-D.ietf-hip-rfc6253-bis] to allow for certificate based authentication.

When a requester wants to register with a registrar, it SHOULD check if it has a suitable certificate for authenticating with the registrar. How the suitability is determined and how the certificates are obtained is out of scope for this document. If the requester has one or more suitable certificates, the host SHOULD include them (or just the most suitable one) in a CERT parameter to the HIP packet along with the REG_REQUEST parameter. If the requester does not have any suitable certificates, it SHOULD send the registration request without the CERT parameter to test whether the registrar accepts the request based on the host's identity.

When a registrar receives a HIP packet with a REG_REQUEST parameter, and it requires authentication for at least one of the Registration Types listed in the REG_REQUEST parameter, it MUST first check whether the HI of the requester is in the allowed list for all the Registration Types in the REG_REQUEST parameter. If the requester is in the allowed list (or the registrar does not require any authentication), the registrar MUST proceed with the registration.

If the requester was not in the allowed list and the registrar requires the requester to authenticate, the registrar MUST check whether the packet also contains a CERT parameter. If the packet does not contain a CERT parameter, the registrar MUST reject the registrations requiring authentication with Failure Type 0 (Registration requires additional credentials). If the certificate is valid and accepted (issued for the requester and signed by a trusted issuer), the registrar MUST proceed with the registration. If the certificate in the parameter is not accepted, the registrar MUST reject the corresponding registrations with Failure Type [IANA TBD] (Invalid certificate).

After successful 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.

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.

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,S3)|     +-----+
| RQ  |                      |  R  |  S2 |
|     |    I2(REG_REQ:S1)    |     |     |
|     |--------------------->|     +-----+
|     |<---------------------|     |  S3 |
|     |    R2(REG_RESP:S1)   |     |     |
+-----+                      +-----+-----+

A requester (RQ) registers for service (S1) with a registrar (R) of services (S1), (S2), and (S3), 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 for service (S) with a registrar (R) of services (S), with which it currently has a HIP association established.

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.

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           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. See 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.

The registrar indicates the minimum and maximum registration lifetime that it is willing to offer to a requester. A requester SHOULD NOT request registration with lifetime greater than the maximum registration lifetime or smaller than the minimum registration lifetime.

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        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. See 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.

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        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. See 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.

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          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
[TBD-IANA]      Insufficient resources
[TBD-IANA]      Invalid certificate
[TBD-IANA]-200  Unassigned
201-255         Reserved by IANA for private use

Other documents will define specific values for registration types. See Section 7 for more information.

Failure type zero (0) indicates that the registrar requires additional credentials to authorize a requester to register with the registration types listed in the parameter. Failure type one (1) indicates that the requested service type is unavailable at the registrar. Failure type ([TBD-IANA-Insufficient-resources]) indicates that the registrar does not currently have enough resources to register the requester for the service(s); when that is the case the requester MUST NOT reattempt immediately to register for the same service(s), and MAY attempt to contact another registrar to register for these service(s). Failure type ([TBD-IANA-Invalid-Certificates]) indicates that the registrar could not validate the certificate provided by the requester to register for the service(s); when that is the case the requester MUST NOT reattempt to register for the same set of services while providing the same certificate, and MAY attempt to register for the same set of service(s) with a different certificate, or with a different set of service(s) with the same certificate.

The registrar SHOULD include a 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.

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 too 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 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.

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 is related to the creation of soft registration state at the registrar.

Registrars act on a voluntary basis and are willing to accept being a responder and then to create HIP associations with a number of potentially 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.

7. IANA Considerations

This section is to be interpreted according to the Guidelines for Writing an IANA Considerations Section in RFCs [RFC5226].

This document updates the IANA Registry for HIP Parameters Types by replacing references to [RFC5203] by references to this document.

Failure Type    Reason
------------    --------------------------------------------
[TBD-IANA]      Insufficient resources
[TBD-IANA]      Invalid certificate

This document also updates the registry for registration failure types by making the following failure type definitions and reservations:

8. Contributors

Teemu Koponen co-authored an earlier, experimental version of this specification [RFC5203].

9. Acknowledgments

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, Ari Keranen, Mika Kousa, Pekka Nikander, and Hannes Tschofenig.

Lars Eggert has received funding from the European Union's Horizon 2020 research and innovation program 2014-2018 under grant agreement No. 644866 ("SSICLOPS"). This document reflects only the authors' views and the European Commission is not responsible for any use that may be made of the information it contains.

Ari Keranen suggested inclusion of the text specifying requester authorization based on certificates as a direct adaption of text found in HIP native NAT traversal specification [I-D.ietf-hip-native-nat-traversal].

10. References

10.1. Normative References

10.2. Informative References

Appendix A. Changes from RFC 5203

• Updated references to revised HIP specifications.
• Added a new registration failure type for use in case of insufficient resources available at the HIP registrar.
• Added requester authorization based on certificates, and new registration failure type for invalid certificate.

Authors' Addresses