draft-ietf-hip-rfc5203-bis-11.txt   rfc8003.txt 
Network Working Group J. Laganier Internet Engineering Task Force (IETF) J. Laganier
Internet-Draft Luminate Wireless, Inc. Request for Comments: 8003 Luminate Wireless, Inc.
Obsoletes: 5203 (if approved) L. Eggert Obsoletes: 5203 L. Eggert
Intended status: Standards Track NetApp Category: Standards Track NetApp
Expires: February 5, 2017 August 4, 2016 ISSN: 2070-1721 October 2016
Host Identity Protocol (HIP) Registration Extension Host Identity Protocol (HIP) Registration Extension
draft-ietf-hip-rfc5203-bis-11
Abstract Abstract
This document specifies a registration mechanism for the Host This document specifies a registration mechanism for the Host
Identity Protocol (HIP) that allows hosts to register with services, Identity Protocol (HIP) that allows hosts to register with services,
such as HIP rendezvous servers or middleboxes. This document such as HIP rendezvous servers or middleboxes. This document
obsoletes RFC5203. obsoletes RFC 5203.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on February 5, 2017. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc8003.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. HIP Registration Extension Overview . . . . . . . . . . . . . 3 3. HIP Registration Extension Overview . . . . . . . . . . . . . 3
3.1. Registrar Announcing Its Ability . . . . . . . . . . . . 4 3.1. Registrar Announcing Its Ability . . . . . . . . . . . . 4
3.2. Requester Requesting Registration . . . . . . . . . . . . 4 3.2. Requester Requesting Registration . . . . . . . . . . . . 4
3.3. Registrar Granting or Refusing Service(s) Registration . 4 3.3. Registrar Granting or Refusing Service(s) Registration . 4
4. Parameter Formats and Processing . . . . . . . . . . . . . . 6 4. Parameter Formats and Processing . . . . . . . . . . . . . . 7
4.1. Encoding Registration Lifetimes with Exponents . . . . . 7 4.1. Encoding Registration Lifetimes with Exponents . . . . . 7
4.2. REG_INFO . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. REG_INFO . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. REG_REQUEST . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. REG_REQUEST . . . . . . . . . . . . . . . . . . . . . . . 8
4.4. REG_RESPONSE . . . . . . . . . . . . . . . . . . . . . . 9 4.4. REG_RESPONSE . . . . . . . . . . . . . . . . . . . . . . 9
4.5. REG_FAILED . . . . . . . . . . . . . . . . . . . . . . . 9 4.5. REG_FAILED . . . . . . . . . . . . . . . . . . . . . . . 10
5. Establishing and Maintaining Registrations . . . . . . . . . 11 5. Establishing and Maintaining Registrations . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . 14 Appendix A. Changes from RFC 5203 . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . 14 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15
Appendix A. Changes from RFC 5203 . . . . . . . . . . . . . . . 16 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
This document specifies an extension to the Host Identity Protocol This document specifies an extension to the Host Identity Protocol
(HIP) [RFC7401]. The extension provides a generic means for a host (HIP) [RFC7401]. The extension provides a generic means for a host
to register with a service. The service may, for example, be a HIP to register with a service. The service may, for example, be a HIP
rendezvous server [I-D.ietf-hip-rfc5204-bis] or a middlebox rendezvous server [RFC8004] or a middlebox [RFC3234].
[RFC3234].
This document makes no further assumptions about the exact type of This document makes no further assumptions about the exact type of
service. Likewise, this document does not specify any mechanisms to service. Likewise, this document does not specify any mechanisms to
discover the presence of specific services or means to interact with discover the presence of specific services or means to interact with
them after registration. Future documents may describe those them after registration. Future documents may describe those
operations. operations.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Terminology 2. Terminology
In addition to the terminology defined in the HIP Architecture In addition to the terminology defined in the HIP Architecture
[I-D.ietf-hip-rfc4423-bis], the HIP specification [RFC7401], and the [HIP-ARCH], the HIP specification [RFC7401], and the HIP Rendezvous
HIP Rendezvous Extension [I-D.ietf-hip-rfc5204-bis], this document Extension [RFC8004], this document defines and uses the following
defines and uses the following terms: terms:
Requester: Requester:
a HIP node registering with a HIP registrar to request a HIP node registering with a HIP registrar to request
registration for a service. registration for a service.
Registrar: Registrar:
a HIP node offering registration for one or more services. a HIP node offering registration for one or more services.
Service: Service:
a facility that provides requesters with new capabilities or a facility that provides requesters with new capabilities or
functionalities operating at the HIP layer. Examples include functionalities operating at the HIP layer. Examples include
firewalls that support HIP traversal or HIP rendezvous servers. firewalls that support HIP traversal or HIP rendezvous servers.
Registration: Registration:
shared state stored by a requester and a registrar, allowing the shared state stored by a requester and a registrar, allowing the
requester to benefit from one or more HIP services offered by the requester to benefit from one or more HIP services offered by the
registrar. Each registration has an associated finite lifetime. registrar. Each registration has an associated finite lifetime.
Requesters can extend established registrations through re- Requesters can extend established registrations through
registration (i.e., perform a refresh). re-registration (i.e., perform a refresh).
Registration Type: Registration Type:
an 8-bit identifier for a given service in the registration an 8-bit identifier for a given service in the registration
protocol. For example, the rendezvous service is identified by a protocol. For example, the rendezvous service is identified by a
specific registration type. specific registration type.
3. HIP Registration Extension Overview 3. HIP Registration Extension Overview
This document does not specify the means by which a requester This document does not specify the means by which a requester
discovers the availability of a service, or how a requester locates a discovers the availability of a service or how a requester locates a
registrar. After a requester has discovered a registrar, it either registrar. After a requester has discovered a registrar, it either
initiates HIP base exchange or uses an existing HIP association with initiates HIP base exchange or uses an existing HIP association with
the registrar. In both cases, registrars use additional parameters, the registrar. In both cases, registrars use additional parameters,
which the remainder of this document defines, to announce their which the remainder of this document defines, to announce their
quality and grant or refuse registration. Requesters use quality and grant or refuse registration. Requesters use
corresponding parameters to register with the service. Both the corresponding parameters to register with the service. Both the
registrar and the requester MAY also include in the messages registrar and the requester MAY also include in the messages
exchanged additional HIP parameters specific to the registration type exchanged additional HIP parameters specific to the registration type
requested. Other documents will define parameters and how they shall requested. Other documents will define parameters and how they shall
be used. be used.
The HIP base exchange, including the definition of the HIP I1, R1, The HIP base exchange, including the definition of the HIP I1, R1,
I2, and R2 packets, is defined in RFC7401 [RFC7401]. The following I2, and R2 packets, is defined in [RFC7401]. The following sections
sections describe the differences between this registration handshake describe the differences between this registration handshake and the
and the standard HIP base exchange [RFC7401]. standard HIP base exchange [RFC7401].
3.1. Registrar Announcing Its Ability 3.1. Registrar Announcing Its Ability
A host that is capable and willing to act as a registrar vis-a-vis a 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 specific requester SHOULD include a REG_INFO parameter in the R1
packets it sends during all base exchanges with that requester. If packets it sends during all base exchanges with that requester. If
it is currently unable to provide services due to transient it is currently unable to provide services due to transient
conditions, it SHOULD include an empty REG_INFO, i.e., one with no conditions, it SHOULD include an empty REG_INFO, i.e., one with no
services listed. If services can be provided later, it SHOULD send services listed. If services can be provided later, it SHOULD send
UPDATE packets indicating the current set of services available in a UPDATE packets indicating the current set of services available in a
skipping to change at page 4, line 39 skipping to change at page 4, line 44
REG_REQUIRED notification error type is 51. REG_REQUIRED notification error type is 51.
3.3. Registrar Granting or Refusing Service(s) Registration 3.3. Registrar Granting or Refusing Service(s) Registration
Once registration has been requested, the registrar is able to Once registration has been requested, the registrar is able to
authenticate the requester based on the host identity included in I2. authenticate the requester based on the host identity included in I2.
If the registrar knows the Host Identities (HIs) of all the hosts If the registrar knows the Host Identities (HIs) of all the hosts
that are allowed to register for service(s), it SHOULD reject that are allowed to register for service(s), it SHOULD reject
registrations from unknown hosts. However, since it may be registrations from unknown hosts. However, since it may be
infeasible to pre-configure the registrar with all the HIs, the infeasible to preconfigure the registrar with all the HIs, the
registrar SHOULD also support HIP certificates registrar SHOULD also support HIP certificates [RFC8002] to allow for
[I-D.ietf-hip-rfc6253-bis] to allow for certificate based certificate-based authentication.
authentication.
When a requester wants to register with a registrar, it SHOULD check When a requester wants to register with a registrar, it SHOULD check
if it has a suitable certificate for authenticating with the if it has a suitable certificate for authenticating with the
registrar. How the suitability is determined and how the registrar. How the suitability is determined and how the
certificates are obtained is out of scope for this document. If the certificates are obtained is out of scope for this document. If the
requester has one or more suitable certificates, the host SHOULD requester has one or more suitable certificates, the host SHOULD
include them (or just the most suitable one) in a CERT parameter to include them (or just the most suitable one) in a CERT parameter to
the HIP packet along with the REG_REQUEST parameter. If the the HIP packet along with the REG_REQUEST parameter. If the
requester does not have any suitable certificates, it SHOULD send the requester does not have any suitable certificates, it SHOULD send the
registration request without the CERT parameter to test whether the registration request without the CERT parameter to test whether the
registrar accepts the request based on the host's identity. registrar accepts the request based on the host's identity.
When a registrar receives a HIP packet with a REG_REQUEST parameter, When a registrar receives a HIP packet with a REG_REQUEST parameter,
and it requires authentication for at least one of the Registration and it requires authentication for at least one of the registration
Types listed in the REG_REQUEST parameter, it MUST first check 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 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 registration types in the REG_REQUEST parameter. If the requester is
in the allowed list (or the registrar does not require any in the allowed list (or the registrar does not require any
authentication), the registrar MUST proceed with the registration. authentication), the registrar MUST proceed with the registration.
If the requester was not in the allowed list and the registrar If the requester was not in the allowed list and the registrar
requires the requester to authenticate, the registrar MUST check requires the requester to authenticate, the registrar MUST check
whether the packet also contains a CERT parameter. If the packet whether the packet also contains a CERT parameter. If the packet
does not contain a CERT parameter, the registrar MUST reject the does not contain a CERT parameter, the registrar MUST reject the
registrations requiring authentication with Failure Type 0 registrations requiring authentication with Failure Type 0 (zero)
(Registration requires additional credentials). If the certificate (registration requires additional credentials). If the certificate
is valid and accepted (issued for the requester and signed by a is valid and accepted (issued for the requester and signed by a
trusted issuer), the registrar MUST proceed with the registration. trusted issuer), the registrar MUST proceed with the registration.
If the certificate in the parameter is not accepted, the registrar If the certificate in the parameter is not accepted, the registrar
MUST reject the corresponding registrations with the appropriate MUST reject the corresponding registrations with the appropriate
Failure Type: Failure Type:
[IANA TBD] (Bad certificate): The certificate is corrupt, contains 4 (Bad certificate): The certificate is corrupt, contains invalid
invalid signatures, etc. signatures, etc.
[IANA TBD] (Unsupported certificate): The certificate is of an 5 (Unsupported certificate): The certificate is of an unsupported
unsupported type. type.
[IANA TBD] (Certificate expired): The certificate is no longer 6 (Certificate expired): The certificate is no longer valid.
valid.
[IANA TBD] (Certificate other): The certificate could not be 7 (Certificate other): The certificate could not be validated for
validated for some unspecified reason. some unspecified reason.
[IANA TBD] (Unknown CA): The issuing CA certificate could not be 8 (Unknown CA): The issuing certification authority (CA) certificate
located or is not trusted. could not be located or is not trusted.
After successful authorization, the registrar includes a REG_RESPONSE After successful authorization, the registrar includes a REG_RESPONSE
parameter in its response, which contains the service type(s) for parameter in its response, which contains the service type(s) for
which it has authorized registration, and zero or more REG_FAILED which it has authorized registration, and zero or more REG_FAILED
parameters containing the service type(s) for which it has not parameters containing the service type(s) for which it has not
authorized registration or registration has failed for other reasons. authorized registration or registration has failed for other reasons.
This response can be either an R2 or an UPDATE message, respectively, This response can be either an R2 or an UPDATE message, respectively,
depending on whether the registration was requested during the base depending on whether the registration was requested during the base
exchange, or using an existing association. In particular, exchange or using an existing association. In particular, REG_FAILED
REG_FAILED with a failure type of zero indicates the service(s) with a Failure Type of zero indicates the service type(s) that
type(s) that require further credentials for registration. requires further credentials for registration.
If the registrar requires further authorization and the requester has If the registrar requires further authorization and the requester has
additional credentials available, the requester SHOULD try to additional credentials available, the requester SHOULD try to
register again with the service after the HIP association has been register again with the service after the HIP association has been
established. established.
Successful processing of a REG_RESPONSE parameter creates Successful processing of a REG_RESPONSE parameter creates
registration state at the requester. In a similar manner, successful registration state at the requester. In a similar manner, successful
processing of a REG_REQUEST parameter creates registration state at processing of a REG_REQUEST parameter creates registration state at
the registrar and possibly at the service. Both the requester and the registrar and possibly at the service. Both the requester and
registrar can cancel a registration before it expires, if the registrar can cancel a registration before it expires, if the
services afforded by a registration are no longer needed by the services afforded by a registration are no longer needed by the
requester, or cannot be provided any longer by the registrar (for requester or cannot be provided any longer by the registrar (for
instance, because its configuration has changed). instance, because its configuration has changed).
+-----+ I1 +-----+-----+ +-----+ I1 +-----+-----+
| |--------------------->| | S1 | | |--------------------->| | S1 |
| |<---------------------| | | | |<---------------------| | |
| | R1(REG_INFO:S1,S2,S3)| +-----+ | | R1(REG_INFO:S1,S2,S3)| +-----+
| RQ | | R | S2 | | RQ | | R | S2 |
| | I2(REG_REQ:S1) | | | | | I2(REG_REQ:S1) | | |
| |--------------------->| +-----+ | |--------------------->| +-----+
| |<---------------------| | S3 | | |<---------------------| | S3 |
| | R2(REG_RESP:S1) | | | | | R2(REG_RESP:S1) | | |
+-----+ +-----+-----+ +-----+ +-----+-----+
A requester (RQ) registers for service (S1) with a registrar (R) of A requester (RQ) registers for service (S1) with a registrar (R) of
services (S1), (S2), and (S3), with which it has no current HIP services (S1), (S2), and (S3) with which it has no current HIP
association. association
+-----+ +-----+-----+ +-----+ +-----+-----+
| | UPDATE(REG_INFO:S) | | | | | UPDATE(REG_INFO:S) | | |
| |<---------------------| | | | |<---------------------| | |
| RQ |--------------------->| R | S | | RQ |--------------------->| R | S |
| | UPDATE(REG_REQ:S) | | | | | UPDATE(REG_REQ:S) | | |
| | UPDATE(REG_RESP:S) | | | | | UPDATE(REG_RESP:S) | | |
| |<---------------------| | | | |<---------------------| | |
+-----+ +-----+-----+ +-----+ +-----+-----+
A requester (RQ) registers for service (S) with a registrar (R) of A requester (RQ) registers for service (S) with a registrar (R) of
services (S), with which it currently has a HIP association services (S) with which it currently has a HIP association
established. established
4. Parameter Formats and Processing 4. Parameter Formats and Processing
This section describes the format and processing of the new This section describes the format and processing of the new
parameters introduced by the HIP registration extension. The parameters introduced by the HIP Registration Extension. The
encoding of these new parameters is conforms to the HIPv2 TLV format encoding of these new parameters conforms to the HIPv2 TLV format
described in section 5.2.1 of RFC7401 [RFC7401]. described in Section 5.2.1 of RFC7401 [RFC7401].
4.1. Encoding Registration Lifetimes with Exponents 4.1. Encoding Registration Lifetimes with Exponents
The HIP registration uses an exponential encoding of registration The HIP registration uses an exponential encoding of registration
lifetimes. lifetimes.
The special value 0 (zero) of the lifetime field MUST be interpreted The special value 0 (zero) of the lifetime field MUST be interpreted
as representing a special lifetime duration of 0 (zero) seconds, and as representing a special lifetime duration of 0 (zero) seconds and
is used to request and grant cancellation of a registration. is used to request and grant cancellation of a registration.
The non-zero values of the lifetime field used throughout this The non-zero values of the lifetime field used throughout this
document MUST be interpreted as an exponent value representing a document MUST be interpreted as an exponent value representing a
lifetime duration of 2^((lifetime - 64)/8) seconds. lifetime duration of 2^((lifetime - 64)/8) seconds.
This allows a compact encoding of 255 different lifetime durations This allows a compact encoding of 255 different lifetime durations
(in addition to the special lifetime duration of zero seconds) (in addition to the special lifetime duration of zero seconds)
ranging from 2^(63/8) seconds (i.e., ~4 ms) to 2^(191/8) seconds ranging from 2^(63/8) seconds (i.e., ~4 ms) to 2^(191/8) seconds
(i.e., ~178 days) into an 8-bit integer field. (i.e., ~178 days) into an 8-bit integer field.
skipping to change at page 8, line 7 skipping to change at page 8, line 12
Other documents will define specific values for registration types. Other documents will define specific values for registration types.
See Section 7 for more information. See Section 7 for more information.
Registrars include the parameter in R1 packets in order to announce Registrars include the parameter in R1 packets in order to announce
their registration capabilities. The registrar SHOULD include the their registration capabilities. The registrar SHOULD include the
parameter in UPDATE packets when its service offering has changed. parameter in UPDATE packets when its service offering has changed.
HIP_SIGNATURE_2 protects the parameter within the R1 packets. HIP_SIGNATURE_2 protects the parameter within the R1 packets.
The registrar indicates the minimum and maximum registration lifetime The registrar indicates the minimum and maximum registration lifetime
that it is willing to offer to a requester. A requester SHOULD NOT that it is willing to offer to a requester. A requester SHOULD NOT
request registration with lifetime greater than the maximum request registration with a lifetime greater than the maximum
registration lifetime or smaller than the minimum registration registration lifetime or smaller than the minimum registration
lifetime. lifetime.
4.3. REG_REQUEST 4.3. REG_REQUEST
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 9, line 27 skipping to change at page 9, line 35
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 934 Type 934
Length Length in octets, excluding Type, Length, and Padding. Length Length in octets, excluding Type, Length, and Padding.
Lifetime Granted registration lifetime. Lifetime Granted registration lifetime.
Reg Type The granted registration types in order of preference. Reg Type The granted registration types in order of preference.
Other documents will define specific values for registration types. Other documents will define specific values for registration types.
See Section 7 for more information. See Section 7 for more information.
The registrar SHOULD includes an REG_RESPONSE parameter in its R2 or The registrar SHOULD include a REG_RESPONSE parameter in its R2 or
UPDATE packet only if a registration has successfully completed. UPDATE packet only if a registration has successfully completed.
The registrar MUST NOT include more than one REG_RESPONSE parameter The registrar MUST NOT include more than one REG_RESPONSE parameter
in its R2 or UPDATE packets, while the requester MUST be able to 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 process one or more REG_RESPONSE parameters in received R2 or UPDATE
packets. packets.
The requester MUST be prepared to receive any registration lifetime, The requester MUST be prepared to receive any registration lifetime,
including ones beyond the minimum and maximum lifetime indicated in including ones beyond the minimum and maximum lifetime indicated in
the REG_INFO parameter. It MUST NOT expect that the returned the REG_INFO parameter. It MUST NOT expect that the returned
skipping to change at page 10, line 22 skipping to change at page 10, line 25
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 936 Type 936
Length Length in octets, excluding Type, Length, and Padding. Length Length in octets, excluding Type, Length, and Padding.
Failure Type Reason for failure. Failure Type Reason for failure.
Reg Type The registration types that failed with the specified Reg Type The registration types that failed with the specified
reason. reason.
Failure Type Reason Value Registration Failure Type
------------ -------------------------------------------- ---------- --------------------------------------------
0 Registration requires additional credentials 0 Registration requires additional credentials
1 Registration type unavailable 1 Registration type unavailable
[TBD-IANA] Insufficient resources 2 Insufficient resources
[TBD-IANA] Invalid certificate 3 Invalid certificate
[TBD-IANA]-200 Unassigned 9-200 Unassigned
201-255 Reserved by IANA for private use 201-255 Reserved for Private Use
Other documents will define specific values for registration types. Other documents will define specific values for registration types.
See Section 7 for more information. See Section 7 for more information.
Failure type zero (0) indicates that the registrar requires Failure Type 0 (zero) indicates that the registrar requires
additional credentials to authorize a requester to register with the additional credentials to authorize a requester to register with the
registration types listed in the parameter. Failure type one (1) registration types listed in the parameter. Failure Type 1 (one)
indicates that the requested service type is unavailable at the indicates that the requested service type is unavailable at the
registrar. Failure type ([TBD-IANA-Insufficient-resources]) registrar. Failure Type 2 indicates that the registrar does not
indicates that the registrar does not currently have enough resources currently have enough resources to register the requester for the
to register the requester for the service(s); when that is the case service(s); when that is the case, the requester MUST NOT reattempt
the requester MUST NOT reattempt immediately to register for the same immediately to register for the same service(s) and MAY attempt to
service(s), and MAY attempt to contact another registrar to register contact another registrar to register for the service(s). Failure
for these service(s). Failure type ([TBD-IANA-Invalid-Certificates]) Type 3 indicates that the registrar could not validate the
indicates that the registrar could not validate the certificate certificate provided by the requester to register for the service(s);
provided by the requester to register for the service(s); when that when that is the case, the requester MUST NOT reattempt to register
is the case the requester MUST NOT reattempt to register for the same for the same set of services while providing the same certificate and
set of services while providing the same certificate, and MAY attempt MAY attempt to register for the same set of services with a different
to register for the same set of service(s) with a different certificate, or with a different set of services with the same
certificate, or with a different set of service(s) with the same
certificate. certificate.
The registrar SHOULD include a REG_FAILED parameter in its R2 or The registrar SHOULD include a REG_FAILED parameter in its R2 or
UPDATE packet, if registration with the registration types listed has UPDATE packet, if registration with the registration types listed has
not completed successfully and a requester is asked to try again with not completed successfully, and a requester is asked to try again
additional credentials. with additional credentials.
HIP_SIGNATURE protects the parameter within the R2 and UPDATE HIP_SIGNATURE protects the parameter within the R2 and UPDATE
packets. packets.
5. Establishing and Maintaining Registrations 5. Establishing and Maintaining Registrations
Establishing and/or maintaining a registration may require additional Establishing and/or maintaining a registration may require additional
information not available in the transmitted REG_REQUEST or information not available in the transmitted REG_REQUEST or
REG_RESPONSE parameters. Therefore, registration type definitions REG_RESPONSE parameters. Therefore, registration type definitions
MAY define dependencies for HIP parameters that are not defined in MAY define dependencies for HIP parameters that are not defined in
skipping to change at page 11, line 42 skipping to change at page 11, line 42
registration of that type. A requester MAY cancel a registration registration of that type. A requester MAY cancel a registration
before it expires by sending a REG_REQ to the registrar with a zero 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 lifetime. A registrar SHOULD respond and grant a registration with a
zero lifetime. A registrar (and an attached service) MAY cancel a zero lifetime. A registrar (and an attached service) MAY cancel a
registration before it expires, at its own discretion. However, if 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 it does so, it SHOULD send a REG_RESPONSE with a zero lifetime to all
registered requesters. registered requesters.
6. Security Considerations 6. Security Considerations
This section discusses the threats on the HIP registration protocol, This section discusses the threats on the HIP registration protocol
and their implications on the overall security of HIP. In and their implications on the overall security of HIP. In
particular, it argues that the extensions described in this document particular, it argues that the extensions described in this document
do not introduce additional threats to HIP. do not introduce additional threats to HIP.
The extensions described in this document rely on the HIP base The extensions described in this document rely on the HIP base
exchange and do not modify its security characteristics, e.g., exchange and do not modify its security characteristics, e.g.,
digital signatures or HMAC. Hence, the only threat introduced by digital signatures or Hashed Message Authentication Code (HMAC).
these extensions is related to the creation of soft registration Hence, the only threat introduced by these extensions is related to
state at the registrar. the creation of soft registration state at the registrar.
Registrars act on a voluntary basis and are willing to accept being a Registrars act on a voluntary basis and are willing to accept being a
responder and then to create HIP associations with a number of Responder and then to create HIP associations with a number of
potentially unknown hosts. Because they have to store HIP potentially unknown hosts. Because they have to store HIP
association state anyway, adding a certain amount of time-limited HIP association state anyway, adding a certain amount of time-limited HIP
registration state should not introduce any serious additional registration states should not introduce any serious additional
threats, especially because HIP registrars may cancel registrations threats, especially because HIP registrars may cancel registrations
at any time at their own discretion, e.g., because of resource at any time at their own discretion, e.g., because of resource
constraints during an attack. constraints during an attack.
7. IANA Considerations 7. IANA Considerations
This section is to be interpreted according to the Guidelines for This section is to be interpreted according to "Guidelines for
Writing an IANA Considerations Section in RFCs [RFC5226]. Writing an IANA Considerations Section in RFCs" [RFC5226].
[RFC5203], obsoleted by this document, made the following definitions [RFC5203], obsoleted by this document, made the following definitions
and reservations in the IANA Registry for HIP Parameters Types: and reservations in the "Parameter Types" subregistry under "Host
Identity Protocol (HIP) Parameters":
Value Parameter Type Length Value Parameter Type Length
----- -------------- -------- ----- -------------- --------
930 REG_INFO variable 930 REG_INFO variable
932 REG_REQUEST variable 932 REG_REQUEST variable
934 REG_RESPONSE variable 934 REG_RESPONSE variable
936 REG_FAILED variable 936 REG_FAILED variable
This document updates the IANA Registry for HIP Parameters Types by In the "Parameter Types" subregistry under "Host Identity Protocol
replacing references to the obsoleted [RFC5203] by references to this (HIP) Parameters", the references to the obsoleted [RFC5203] have
document. been replaced with references to this document.
[RFC5203], obsoleted by this document, requested the opening of an [RFC5203], obsoleted by this document, requested the opening of the
IANA Registry for HIP Registration Types, defined no registration "Registration Types" subregistry under "Host Identity Protocol (HIP)
types, but made the following reservations in the IANA Registry for Parameters", defined no registration types, but made the following
HIP Registration Types: reservations in that subregistry:
Reg Type Service Reg Type Service
-------- -------------------------------- -------- --------------------------------
201-255 Reserved by IANA for private use 201-255 Reserved by IANA for private use
Adding a new type requires new IETF specifications. Adding a new type requires new IETF specifications.
This document updates the IANA Registry for HIP Registration Types by In the "Registration Types" subregistry under "Host Identity Protocol
replacing references to the obsoleted [RFC5203] by references to this (HIP) Parameters", references to the obsoleted [RFC5203] have been
document. replaced with references to this document.
[RFC5203], obsoleted by this document, requested the opening of an [RFC5203], obsoleted by this document, requested the opening of the
IANA Registry for HIP Registration Failure Types, and made the "Registration Failure Types" subregistry under "Host Identity
following definitions and reservations in the IANA Registry for HIP Protocol (HIP) Parameters" and made the following definitions and
Registration Failure Types: reservations in that subregistry:
Failure Type Reason Failure Type Reason
------------ -------------------------------------------- ------------ --------------------------------------------
0 Registration requires additional credentials 0 Registration requires additional credentials
1 Registration type unavailable 1 Registration type unavailable
201-255 Reserved by IANA for private use 201-255 Reserved by IANA for private use
Adding a new type requires new IETF specifications. Adding a new type requires new IETF specifications.
This document updates the IANA Registry for HIP Registration Failure In the "Registration Failure Types" subregistry under "Host Identity
Types by replacing references to the obsoleted [RFC5203] by Protocol (HIP) Parameters", references to the obsoleted [RFC5203]
references to this document, and making the following additional HIP have been replaced with references to this document, and the
Registration Failure Types definition and reservation: following HIP Registration Failure Types have been added:
Failure Type Reason Value Registration Failure Type
------------ -------------------------------------------- ------------ --------------------------------------------
[TBD-IANA] Insufficient resources 2 Insufficient resources
[TBD-IANA] Invalid certificate 3 Invalid certificate
[TBD-IANA] Bad certificate 4 Bad certificate
[TBD-IANA] Unsupported certificate 5 Unsupported certificate
[TBD-IANA] Certificate expired 6 Certificate expired
[TBD-IANA] Certificate other 7 Certificate other
[TBD-IANA] Unknown CA 8 Unknown CA
201-255 Reserved for Private Use
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. 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].
Thanks to Joel M. Halpern for performing the Gen-ART review of this
document as part of the publication process.
10. References
10.1. Normative References
[I-D.ietf-hip-rfc5204-bis] 8. References
Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extension", draft-ietf-hip-rfc5204-bis-07 (work
in progress), December 2015.
[I-D.ietf-hip-rfc6253-bis] 8.1. Normative References
Heer, T. and S. Varjonen, "Host Identity Protocol
Certificates", draft-ietf-hip-rfc6253-bis-09 (work in
progress), July 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <http://www.rfc-editor.org/info/rfc5226>.
[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
Henderson, "Host Identity Protocol Version 2 (HIPv2)", Henderson, "Host Identity Protocol Version 2 (HIPv2)",
RFC 7401, DOI 10.17487/RFC7401, April 2015, RFC 7401, DOI 10.17487/RFC7401, April 2015,
<http://www.rfc-editor.org/info/rfc7401>. <http://www.rfc-editor.org/info/rfc7401>.
10.2. Informative References [RFC8002] Heer, T. and S. Varjonen, "Host Identity Protocol
Certificates", RFC 8002, DOI 10.17487/RFC8002, October
2016, <http://www.rfc-editor.org/info/rfc8002>.
[I-D.ietf-hip-native-nat-traversal] [RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Keranen, A., Melen, J., and M. Komu, "Native NAT Traversal Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004,
Mode for the Host Identity Protocol", draft-ietf-hip- October 2016, <http://www.rfc-editor.org/info/rfc8004>.
native-nat-traversal-13 (work in progress), July 2016.
[I-D.ietf-hip-rfc4423-bis] 8.2. Informative References
[HIP-ARCH]
Moskowitz, R. and M. Komu, "Host Identity Protocol Moskowitz, R. and M. Komu, "Host Identity Protocol
Architecture", draft-ietf-hip-rfc4423-bis-14 (work in Architecture", Work in Progress, draft-ietf-hip-rfc4423-
progress), June 2016. bis-14, June 2016.
[HIP-NAT] Keranen, A., Melen, J., and M. Komu, "Native NAT Traversal
Mode for the Host Identity Protocol", Work in Progress,
draft-ietf-hip-native-nat-traversal-13, July 2016.
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002,
<http://www.rfc-editor.org/info/rfc3234>. <http://www.rfc-editor.org/info/rfc3234>.
[RFC5203] Laganier, J., Koponen, T., and L. Eggert, "Host Identity [RFC5203] Laganier, J., Koponen, T., and L. Eggert, "Host Identity
Protocol (HIP) Registration Extension", RFC 5203, Protocol (HIP) Registration Extension", RFC 5203,
DOI 10.17487/RFC5203, April 2008, DOI 10.17487/RFC5203, April 2008,
<http://www.rfc-editor.org/info/rfc5203>. <http://www.rfc-editor.org/info/rfc5203>.
Appendix A. Changes from RFC 5203 Appendix A. Changes from RFC 5203
o Updated references to revised HIP specifications. o Updated references to revised HIP specifications.
o Added a new registration failure type for use in case of o Added a new registration Failure Type for use in case of
insufficient resources available at the HIP registrar. insufficient resources available at the HIP registrar.
o Added requester authorization based on certificates, and new o Added requester authorization based on certificates and new
registration failure types for invalid certificate. registration Failure Types for invalid certificates.
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. 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 the HIP native NAT traversal specification [HIP-NAT].
Thanks to Joel M. Halpern for performing the Gen-ART review of this
document as part of the publication process.
Contributors
Teemu Koponen coauthored an earlier, experimental version of this
specification [RFC5203].
Authors' Addresses Authors' Addresses
Julien Laganier Julien Laganier
Luminate Wireless, Inc. Luminate Wireless, Inc.
Cupertino, CA Cupertino, CA
USA United States of America
EMail: julien.ietf@gmail.com Email: julien.ietf@gmail.com
Lars Eggert Lars Eggert
NetApp NetApp
Sonnenallee 1 Sonnenallee 1
Kirchheim 85551 Kirchheim 85551
Germany Germany
Phone: +49 151 12055791 Phone: +49 151 12055791
EMail: lars@netapp.com Email: lars@netapp.com
URI: http://eggert.org URI: http://eggert.org
 End of changes. 61 change blocks. 
183 lines changed or deleted 173 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/