draft-ietf-hip-rfc5203-bis-02.txt   draft-ietf-hip-rfc5203-bis-03.txt 
Network Working Group J. Laganier Network Working Group J. Laganier
Internet-Draft Juniper Networks 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: March 26, 2013 September 22, 2012 Expires: June 14, 2014 December 11, 2013
Host Identity Protocol (HIP) Registration Extension Host Identity Protocol (HIP) Registration Extension
draft-ietf-hip-rfc5203-bis-02 draft-ietf-hip-rfc5203-bis-03
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. such as HIP rendezvous servers or middleboxes. This document
obsoletes RFC5203.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 March 26, 2013. This Internet-Draft will expire on June 14, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. HIP Registration Extension Overview . . . . . . . . . . . . . 4 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 . . 5 3.3. Registrar Granting or Refusing Service(s) Registration . 4
4. Parameter Formats and Processing . . . . . . . . . . . . . . . 6 4. Parameter Formats and Processing . . . . . . . . . . . . . . 6
4.1. Encoding Registration Lifetimes with Exponents . . . . . . 6 4.1. Encoding Registration Lifetimes with Exponents . . . . . 6
4.2. REG_INFO . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. REG_INFO . . . . . . . . . . . . . . . . . . . . . . . . 6
4.3. REG_REQUEST . . . . . . . . . . . . . . . . . . . . . . . 7 4.3. REG_REQUEST . . . . . . . . . . . . . . . . . . . . . . . 6
4.4. REG_RESPONSE . . . . . . . . . . . . . . . . . . . . . . . 8 4.4. REG_RESPONSE . . . . . . . . . . . . . . . . . . . . . . 7
4.5. REG_FAILED . . . . . . . . . . . . . . . . . . . . . . . . 9 4.5. REG_FAILED . . . . . . . . . . . . . . . . . . . . . . . 8
5. Establishing and Maintaining Registrations . . . . . . . . . . 10 5. Establishing and Maintaining Registrations . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Changes from RFC 5203 . . . . . . . . . . . . . . . . 13 Appendix A. Changes from RFC 5203 . . . . . . . . . . . . . . . 12
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) [I-D.ietf-hip-rfc5201-bis]. The extension provides a generic (HIP) [I-D.ietf-hip-rfc5201-bis]. The extension provides a generic
means for a host to register with a service. The service may, for 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 example, be a HIP rendezvous server [I-D.ietf-hip-rfc5204-bis] or a
middlebox [RFC3234]. middlebox [RFC3234].
This document makes no further assumptions about the exact type of This document makes no further assumptions about the exact type of
skipping to change at page 5, line 42 skipping to change at page 5, line 21
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) | +-----+ | | R1(REG_INFO:S1,S2) | +-----+
| 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 with a registrar (R) of services (S1) and
(S2), with which it has no current HIP association. (S2), 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 with a registrar (R) of services (S), with
which it currently has a HIP association established. 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
skipping to change at page 9, line 20 skipping to change at page 9, line 4
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
lifetime will be the requested one, even when the requested lifetime lifetime will be the requested one, even when the requested lifetime
falls within the announced minimum and maximum. falls within the announced minimum and maximum.
HIP_SIGNATURE protects the parameter within the R2 and UPDATE HIP_SIGNATURE protects the parameter within the R2 and UPDATE
packets. packets.
4.5. REG_FAILED 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 +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 Type 936
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 Length Length in octets, excluding Type, Length, and Padding.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Failure Type Reason for failure.
| Type | Length | Reg Type The registration types that failed with the specified
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ reason.
| 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 Failure Type Reason
------------ -------------------------------------------- ------------ --------------------------------------------
0 Registration requires additional credentials 0 Registration requires additional credentials
1 Registration type unavailable 1 Registration type unavailable
3 Insufficient resources 3 Insufficient resources
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 A failure type of zero means a registrar requires additional
credentials to authorize a requester to register with the 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. A failure type of one
means that the requested service type is unavailable at the means that the requested service type is unavailable at the
registrar. Failure types other than zero (0) and one (1) have not registrar. Failure types other than zero (0) and one (1) have not
been defined. been defined.
skipping to change at page 11, line 18 skipping to change at page 11, line 4
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 previously unknown hosts. Because they have to store HIP association
state anyway, adding a certain amount of time-limited HIP 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 [RFC2434]. Writing an IANA Considerations Section in RFCs [RFC5226].
This document updates the IANA Registry for HIP Parameter Types by This document updates the IANA Registry for HIP Parameter Types by
assigning new HIP Parameter Types values for the new HIP Parameters assigning new HIP Parameter Types values for the new HIP Parameters
defined in this document: defined in this document:
o REG_INFO (defined in Section 4.2) o REG_INFO (defined in Section 4.2)
o REG_REQUEST (defined in Section 4.3) o REG_REQUEST (defined in Section 4.3)
o REG_RESPONSE (defined in Section 4.4) o REG_RESPONSE (defined in Section 4.4)
skipping to change at page 12, line 31 skipping to change at page 12, line 16
The following people (in alphabetical order) have provided thoughtful The following people (in alphabetical order) have provided thoughtful
and helpful discussions and/or suggestions that have helped to and helpful discussions and/or suggestions that have helped to
improve this document: Jeffrey Ahrenholz, Miriam Esteban, Ari improve this document: Jeffrey Ahrenholz, Miriam Esteban, Ari
Keranen, Mika Kousa, Pekka Nikander, and Hannes Tschofenig. Keranen, Mika Kousa, Pekka Nikander, and Hannes Tschofenig.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-hip-rfc5201-bis] Moskowitz, R., Heer, T., Jokela, P., and [I-D.ietf-hip-rfc5201-bis]
T. Henderson, "Host Identity Protocol Moskowitz, R., Heer, T., Jokela, P., and T. Henderson,
Version 2 (HIPv2)", "Host Identity Protocol Version 2 (HIPv2)", draft-ietf-
draft-ietf-hip-rfc5201-bis-09 (work in hip-rfc5201-bis-14 (work in progress), October 2013.
progress), July 2012.
[I-D.ietf-hip-rfc5204-bis] Laganier, J. and L. Eggert, "Host [I-D.ietf-hip-rfc5204-bis]
Identity Protocol (HIP) Rendezvous Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Extension", draft-ietf-hip-rfc5204-bis-01 Rendezvous Extension", draft-ietf-hip-rfc5204-bis-02 (work
(work in progress), March 2011. in progress), September 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
to Indicate Requirement Levels", BCP 14, Requirement Levels", BCP 14, RFC 2119, March 1997.
RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
for Writing an IANA Considerations IANA Considerations Section in RFCs", BCP 26, RFC 5226,
Section in RFCs", BCP 26, RFC 2434, May 2008.
October 1998.
10.2. Informative References 10.2. Informative References
[I-D.ietf-hip-rfc4423-bis] Moskowitz, R., "Host Identity Protocol [I-D.ietf-hip-rfc4423-bis]
Architecture", Moskowitz, R. and M. Komu, "Host Identity Protocol
draft-ietf-hip-rfc4423-bis-04 (work in Architecture", draft-ietf-hip-rfc4423-bis-06 (work in
progress), July 2012. progress), November 2013.
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
Taxonomy and Issues", RFC 3234, Issues", RFC 3234, February 2002.
February 2002.
[RFC5203] Laganier, J., Koponen, T., and L. Eggert, [RFC5203] Laganier, J., Koponen, T., and L. Eggert, "Host Identity
"Host Identity Protocol (HIP) Protocol (HIP) Registration Extension", RFC 5203, April
Registration Extension", RFC 5203, 2008.
April 2008.
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.
Authors' Addresses Authors' Addresses
Julien Laganier Julien Laganier
Juniper Networks Luminate Wireless, Inc.
1094 North Mathilda Avenue Cupertino, CA
Sunnyvale, CA 94089
USA USA
Phone: +1 408 936 0385
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
 End of changes. 23 change blocks. 
102 lines changed or deleted 94 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/