draft-ietf-hip-rfc5203-bis-10.txt   draft-ietf-hip-rfc5203-bis-11.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: August 3, 2016 January 31, 2016 Expires: February 5, 2017 August 4, 2016
Host Identity Protocol (HIP) Registration Extension Host Identity Protocol (HIP) Registration Extension
draft-ietf-hip-rfc5203-bis-10 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 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 August 3, 2016. This Internet-Draft will expire on February 5, 2017.
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
skipping to change at page 2, line 14 skipping to change at page 2, line 14
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
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 . . . . . . . . . . . . . . 6
4.1. Encoding Registration Lifetimes with Exponents . . . . . 6 4.1. Encoding Registration Lifetimes with Exponents . . . . . 7
4.2. REG_INFO . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. REG_INFO . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. REG_REQUEST . . . . . . . . . . . . . . . . . . . . . . . 7 4.3. REG_REQUEST . . . . . . . . . . . . . . . . . . . . . . . 8
4.4. REG_RESPONSE . . . . . . . . . . . . . . . . . . . . . . 8 4.4. REG_RESPONSE . . . . . . . . . . . . . . . . . . . . . . 9
4.5. REG_FAILED . . . . . . . . . . . . . . . . . . . . . . . 9 4.5. REG_FAILED . . . . . . . . . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . . . . . . . . 12 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Changes from RFC 5203 . . . . . . . . . . . . . . . 15 Appendix A. Changes from RFC 5203 . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 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 [I-D.ietf-hip-rfc5204-bis] 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
skipping to change at page 3, line 27 skipping to change at page 3, line 27
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 re-
registration (i.e., perform a refresh). registration (i.e., perform a refresh).
Registration Type: Registration Type:
an identifier for a given service in the registration protocol. an 8-bit identifier for a given service in the registration
For example, the rendezvous service is identified by a specific protocol. For example, the rendezvous service is identified by a
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
skipping to change at page 5, line 24 skipping to change at page 5, line 24
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
(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 Failure Type [IANA MUST reject the corresponding registrations with the appropriate
TBD] (Invalid certificate). Failure Type:
[IANA TBD] (Bad certificate): The certificate is corrupt, contains
invalid signatures, etc.
[IANA TBD] (Unsupported certificate): The certificate is of an
unsupported type.
[IANA TBD] (Certificate expired): The certificate is no longer
valid.
[IANA TBD] (Certificate other): The certificate could not be
validated for some unspecified reason.
[IANA TBD] (Unknown CA): The issuing CA certificate 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 with a failure type of zero indicates the service(s) REG_FAILED with a failure type of zero indicates the service(s)
skipping to change at page 12, line 19 skipping to change at page 12, line 19
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].
[RFC5203], obsoleted by this document, made the following definitions
and reservations in the IANA Registry for HIP Parameters Types:
Value Parameter Type Length
----- -------------- --------
930 REG_INFO variable
932 REG_REQUEST variable
934 REG_RESPONSE variable
936 REG_FAILED variable
This document updates the IANA Registry for HIP Parameters Types by This document updates the IANA Registry for HIP Parameters Types by
replacing references to [RFC5203] by references to this document. replacing references to the obsoleted [RFC5203] by references to this
document.
This document also updates the registry for registration failure [RFC5203], obsoleted by this document, requested the opening of an
types by making the following failure type definitions and IANA Registry for HIP Registration Types, defined no registration
reservations: types, but made the following reservations in the IANA Registry for
HIP Registration Types:
Reg Type Service
-------- --------------------------------
201-255 Reserved by IANA for private use
Adding a new type requires new IETF specifications.
This document updates the IANA Registry for HIP Registration Types by
replacing references to the obsoleted [RFC5203] by references to this
document.
[RFC5203], obsoleted by this document, requested the opening of an
IANA Registry for HIP Registration Failure Types, and made the
following definitions and reservations in the IANA Registry for HIP
Registration Failure Types:
Failure Type Reason
------------ --------------------------------------------
0 Registration requires additional credentials
1 Registration type unavailable
201-255 Reserved by IANA for private use
Adding a new type requires new IETF specifications.
This document updates the IANA Registry for HIP Registration Failure
Types by replacing references to the obsoleted [RFC5203] by
references to this document, and making the following additional HIP
Registration Failure Types definition and reservation:
Failure Type Reason Failure Type Reason
------------ -------------------------------------------- ------------ --------------------------------------------
[TBD-IANA] Insufficient resources [TBD-IANA] Insufficient resources
[TBD-IANA] Invalid certificate [TBD-IANA] Invalid certificate
[TBD-IANA] Bad certificate
[TBD-IANA] Unsupported certificate
[TBD-IANA] Certificate expired
[TBD-IANA] Certificate other
[TBD-IANA] Unknown CA
8. Contributors 8. Contributors
Teemu Koponen co-authored an earlier, experimental version of this Teemu Koponen co-authored an earlier, experimental version of this
specification [RFC5203]. specification [RFC5203].
9. Acknowledgments 9. Acknowledgments
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
skipping to change at page 13, line 19 skipping to change at page 14, line 16
10.1. Normative References 10.1. Normative References
[I-D.ietf-hip-rfc5204-bis] [I-D.ietf-hip-rfc5204-bis]
Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extension", draft-ietf-hip-rfc5204-bis-07 (work Rendezvous Extension", draft-ietf-hip-rfc5204-bis-07 (work
in progress), December 2015. in progress), December 2015.
[I-D.ietf-hip-rfc6253-bis] [I-D.ietf-hip-rfc6253-bis]
Heer, T. and S. Varjonen, "Host Identity Protocol Heer, T. and S. Varjonen, "Host Identity Protocol
Certificates", draft-ietf-hip-rfc6253-bis-06 (work in Certificates", draft-ietf-hip-rfc6253-bis-09 (work in
progress), December 2015. 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 10.2. Informative References
[I-D.ietf-hip-native-nat-traversal] [I-D.ietf-hip-native-nat-traversal]
Keranen, A. and J. Melen, "Native NAT Traversal Mode for Keranen, A., Melen, J., and M. Komu, "Native NAT Traversal
the Host Identity Protocol", draft-ietf-hip-native-nat- Mode for the Host Identity Protocol", draft-ietf-hip-
traversal-10 (work in progress), January 2016. native-nat-traversal-13 (work in progress), July 2016.
[I-D.ietf-hip-rfc4423-bis] [I-D.ietf-hip-rfc4423-bis]
Moskowitz, R. and M. Komu, "Host Identity Protocol Moskowitz, R. and M. Komu, "Host Identity Protocol
Architecture", draft-ietf-hip-rfc4423-bis-13 (work in Architecture", draft-ietf-hip-rfc4423-bis-14 (work in
progress), December 2015. progress), June 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 type for invalid certificate. registration failure types for invalid certificate.
Authors' Addresses Authors' Addresses
Julien Laganier Julien Laganier
Luminate Wireless, Inc. Luminate Wireless, Inc.
Cupertino, CA Cupertino, CA
USA USA
EMail: julien.ietf@gmail.com EMail: julien.ietf@gmail.com
 End of changes. 16 change blocks. 
30 lines changed or deleted 90 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/