draft-ietf-hip-rfc5203-bis-07.txt   draft-ietf-hip-rfc5203-bis-08.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: October 20, 2015 April 18, 2015 Expires: December 12, 2015 June 10, 2015
Host Identity Protocol (HIP) Registration Extension Host Identity Protocol (HIP) Registration Extension
draft-ietf-hip-rfc5203-bis-07 draft-ietf-hip-rfc5203-bis-08
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 October 20, 2015. This Internet-Draft will expire on December 12, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 19 skipping to change at page 2, line 19
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 . . . . . 6
4.2. REG_INFO . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. REG_INFO . . . . . . . . . . . . . . . . . . . . . . . . 6
4.3. REG_REQUEST . . . . . . . . . . . . . . . . . . . . . . . 7 4.3. REG_REQUEST . . . . . . . . . . . . . . . . . . . . . . . 7
4.4. REG_RESPONSE . . . . . . . . . . . . . . . . . . . . . . 8 4.4. REG_RESPONSE . . . . . . . . . . . . . . . . . . . . . . 8
4.5. REG_FAILED . . . . . . . . . . . . . . . . . . . . . . . 9 4.5. REG_FAILED . . . . . . . . . . . . . . . . . . . . . . . 9
5. Establishing and Maintaining Registrations . . . . . . . . . 10 5. Establishing and Maintaining Registrations . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Changes from RFC 5203 . . . . . . . . . . . . . . . 14 Appendix A. Changes from RFC 5203 . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
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
skipping to change at page 3, line 44 skipping to change at page 3, line 44
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
implicated. Other documents will define parameters and how they requested. Other documents will define parameters and how they shall
shall be used. The following sections describe the differences be used. The following sections describe the differences between
between this registration handshake and the standard HIP base this registration handshake and the standard HIP base exchange
exchange [I-D.ietf-hip-rfc5201-bis]. [I-D.ietf-hip-rfc5201-bis].
3.1. Registrar Announcing Its Ability 3.1. Registrar Announcing Its Ability
A host that is capable and willing to act as a registrar SHOULD A host that is capable and willing to act as a registrar vis-a-vis a
include a REG_INFO parameter in the R1 packets it sends during all specific requester SHOULD include a REG_INFO parameter in the R1
base exchanges. If it is currently unable to provide services due to packets it sends during all base exchanges with that requester. If
transient conditions, it SHOULD include an empty REG_INFO, i.e., one it is currently unable to provide services due to transient
with no services listed. If services can be provided later, it conditions, it SHOULD include an empty REG_INFO, i.e., one with no
SHOULD send UPDATE packets indicating the current set of services services listed. If services can be provided later, it SHOULD send
available in a new REG_INFO parameter to all hosts it is associated UPDATE packets indicating the current set of services available in a
with. new REG_INFO parameter to all hosts it is associated with.
3.2. Requester Requesting Registration 3.2. Requester Requesting Registration
To request registration with a service, a requester constructs and To request registration with a service, a requester constructs and
includes a corresponding REG_REQUEST parameter in an I2 or UPDATE includes a corresponding REG_REQUEST parameter in an I2 or UPDATE
packet it sends to the registrar. packet it sends to the registrar.
If the requester has no HIP association established with the If the requester has no HIP association established with the
registrar, it SHOULD send the REG_REQUEST at the earliest registrar, it SHOULD send the REG_REQUEST at the earliest
possibility, i.e., in the I2 packet. This minimizes the number of possibility, i.e., in the I2 packet. This minimizes the number of
skipping to change at page 4, line 39 skipping to change at page 4, line 39
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
unfeasible to pre-configure the registrar with all the HIs, the infeasible to pre-configure the registrar with all the HIs, the
registrar SHOULD also support HIP certificates registrar SHOULD also support HIP certificates
[I-D.ietf-hip-rfc6253-bis] to allow for certificate based [I-D.ietf-hip-rfc6253-bis] to allow for 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
skipping to change at page 7, line 30 skipping to change at page 7, line 30
Reg Type The registration types offered by the registrar. Reg Type The registration types offered by the registrar.
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.
4.3. REG_REQUEST The registrar indicates the minimum and maximum registration lifetime
that it is willing to offer to a requester. A requester SHOULD NOT
request registration with lifetime greater than the maximum
registration lifetime or smaller than the minimum registration
lifetime.
4.3. REG_REQUEST
0 1 2 3 0 1 2 3
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime | Reg Type #1 | Reg Type #2 | Reg Type #3 | | Lifetime | Reg Type #1 | Reg Type #2 | Reg Type #3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | ... | Reg Type #n | | | ... | ... | Reg Type #n | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding +
| | | |
skipping to change at page 11, line 32 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].
This document updates the IANA Registry for HIP Parameter Types by This document updates the IANA Registry for HIP Parameters Types by
assigning new HIP Parameter Types values for the new HIP Parameters replacing references to [RFC5203] by references to this document.
defined in this document:
o REG_INFO (defined in Section 4.2)
o REG_REQUEST (defined in Section 4.3)
o REG_RESPONSE (defined in Section 4.4)
o REG_FAILED (defined in Section 4.5)
IANA has allocated the Notify Message Type code 51 for the
REG_REQUIRED notification error type in the Notify Message Type
registry.
IANA has opened a new registry for registration types. This document
does not define registration types but makes the following
reservations:
Reg Type Service
-------- -------
0-200 Unassigned
201-255 Reserved by IANA for private use
Adding a new type requires new IETF specifications.
IANA has opened a new registry for registration failure types. This This document also updates the registry for registration failure
document makes the following failure type definitions and types by making the following failure type definitions and
reservations: reservations:
Failure Type Reason Failure Type Reason
------------ -------------------------------------------- ------------ --------------------------------------------
0 Registration requires additional credentials
1 Registration type unavailable
[TBD-IANA] Insufficient resources [TBD-IANA] Insufficient resources
[TBD-IANA] Invalid certificate [TBD-IANA] Invalid certificate
[TBD-IANA]-200 Unassigned
201-255 Reserved by IANA for private use
Adding a new type requires new IETF specifications.
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
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.
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 Ari Keranen suggested inclusion of the text specifying requester
authorization based on certificates as a direct adaption of text authorization based on certificates as a direct adaption of text
found in HIP native NAT traversal specification found in HIP native NAT traversal specification
[I-D.ietf-hip-native-nat-traversal]. [I-D.ietf-hip-native-nat-traversal].
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-hip-rfc5201-bis] [I-D.ietf-hip-rfc5201-bis]
 End of changes. 16 change blocks. 
55 lines changed or deleted 36 lines changed or added

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