draft-ietf-hip-rfc5203-bis-04.txt   draft-ietf-hip-rfc5203-bis-05.txt 
Network Working Group J. Laganier Network Working Group J. Laganier
Internet-Draft Luminate Wireless, Inc. Internet-Draft Luminate Wireless, Inc.
Obsoletes: 5203 (if approved) L. Eggert Obsoletes: 5203 (if approved) L. Eggert
Intended status: Standards Track NetApp Intended status: Standards Track NetApp
Expires: July 19, 2014 January 15, 2014 Expires: September 11, 2014 March 10, 2014
Host Identity Protocol (HIP) Registration Extension Host Identity Protocol (HIP) Registration Extension
draft-ietf-hip-rfc5203-bis-04 draft-ietf-hip-rfc5203-bis-05
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 RFC5203.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 19, 2014. This Internet-Draft will expire on September 11, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
skipping to change at page 4, line 37 skipping to change at page 4, line 37
including a NOTIFY with the type REG_REQUIRED in the R2. In this including a NOTIFY with the type REG_REQUIRED in the R2. In this
case, no HIP association is created between the hosts. The case, no HIP association is created between the hosts. The
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 use the relaying service, 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
unfeasible to pre-configure the relay with all the HIs, the relay unfeasible to pre-configure the registrar with all the HIs, the
SHOULD also support HIP certificates [I-D.ietf-hip-rfc6253-bis] to registrar SHOULD also support HIP certificates
allow for certificate based authentication. [I-D.ietf-hip-rfc6253-bis] to allow for certificate based
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
skipping to change at page 6, line 8 skipping to change at page 6, line 8
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) | +-----+ | | 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 with a registrar (R) of services (S1) and A requester (RQ) registers for service (S1) with a registrar (R) of
(S2), with which it has no current HIP association. services (S1), (S2), and (S3), with which it has no current HIP
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 with a registrar (R) of services (S), with A requester (RQ) registers for service (S) with a registrar (R) of
which it currently has a HIP association established. services (S), with which it currently has a HIP association
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. parameters introduced by the HIP registration extension.
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. This allows compact encoding of 255 different lifetime lifetimes. This allows compact encoding of 255 different lifetime
skipping to change at page 9, line 40 skipping to change at page 9, line 40
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 Failure Type Reason
------------ -------------------------------------------- ------------ --------------------------------------------
0 Registration requires additional credentials 0 Registration requires additional credentials
1 Registration type unavailable 1 Registration type unavailable
3 Insufficient resources 2 Insufficient resources
[TBD-IANA] Invalid certificate [TBD-IANA] Invalid certificate
3-200 Unassigned 3-200 Unassigned
201-255 Reserved by IANA for private use 201-255 Reserved by IANA 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.
A failure type of zero means a registrar requires additional Failure type zero (0) indicates that the registrar requires
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. A failure type of one registration types listed in the parameter. Failure type one (1)
means that the requested service type is unavailable at the indicates that the requested service type is unavailable at the
registrar. Failure types other than zero (0) and one (1) have not registrar. Failure type (2) indicates that the registrar does not
been defined. 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).
The registrar SHOULD include the 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 with
additional credentials. 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
skipping to change at page 11, line 9 skipping to change at page 11, line 13
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 HMAC. Hence, the only threat introduced by
these extensions is related to the creation of soft registration these extensions is related to the creation of soft registration
state at the registrar. 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
previously unknown hosts. Because they have to store HIP association potentially unknown hosts. Because they have to store HIP
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 state 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 the Guidelines for
Writing an IANA Considerations Section in RFCs [RFC5226]. Writing an IANA Considerations Section in RFCs [RFC5226].
 End of changes. 12 change blocks. 
22 lines changed or deleted 28 lines changed or added

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