[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 RFC 8003

Network Working Group                                        J. Laganier
Internet-Draft                                   Luminate Wireless, Inc.
Obsoletes: 5203 (if approved)                                  L. Eggert
Intended status: Standards Track                                  NetApp
Expires: February 5, 2017                                 August 4, 2016


          Host Identity Protocol (HIP) Registration Extension
                     draft-ietf-hip-rfc5203-bis-11

Abstract

   This document specifies a registration mechanism for the Host
   Identity Protocol (HIP) that allows hosts to register with services,
   such as HIP rendezvous servers or middleboxes.  This document
   obsoletes RFC5203.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   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
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on February 5, 2017.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.



Laganier & Eggert       Expires February 5, 2017                [Page 1]


Internet-Draft         HIP Registration Extension            August 2016


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  HIP Registration Extension Overview . . . . . . . . . . . . .   3
     3.1.  Registrar Announcing Its Ability  . . . . . . . . . . . .   4
     3.2.  Requester Requesting Registration . . . . . . . . . . . .   4
     3.3.  Registrar Granting or Refusing Service(s) Registration  .   4
   4.  Parameter Formats and Processing  . . . . . . . . . . . . . .   6
     4.1.  Encoding Registration Lifetimes with Exponents  . . . . .   7
     4.2.  REG_INFO  . . . . . . . . . . . . . . . . . . . . . . . .   7
     4.3.  REG_REQUEST . . . . . . . . . . . . . . . . . . . . . . .   8
     4.4.  REG_RESPONSE  . . . . . . . . . . . . . . . . . . . . . .   9
     4.5.  REG_FAILED  . . . . . . . . . . . . . . . . . . . . . . .   9
   5.  Establishing and Maintaining Registrations  . . . . . . . . .  11
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   8.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  13
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  13
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  14
     10.2.  Informative References . . . . . . . . . . . . . . . . .  14
   Appendix A.  Changes from RFC 5203  . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

   This document specifies an extension to the Host Identity Protocol
   (HIP) [RFC7401].  The extension provides a generic 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 middlebox
   [RFC3234].

   This document makes no further assumptions about the exact type of
   service.  Likewise, this document does not specify any mechanisms to
   discover the presence of specific services or means to interact with
   them after registration.  Future documents may describe those
   operations.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

2.  Terminology

   In addition to the terminology defined in the HIP Architecture
   [I-D.ietf-hip-rfc4423-bis], the HIP specification [RFC7401], and the




Laganier & Eggert       Expires February 5, 2017                [Page 2]


Internet-Draft         HIP Registration Extension            August 2016


   HIP Rendezvous Extension [I-D.ietf-hip-rfc5204-bis], this document
   defines and uses the following terms:

   Requester:
      a HIP node registering with a HIP registrar to request
      registration for a service.

   Registrar:
      a HIP node offering registration for one or more services.

   Service:
      a facility that provides requesters with new capabilities or
      functionalities operating at the HIP layer.  Examples include
      firewalls that support HIP traversal or HIP rendezvous servers.

   Registration:
      shared state stored by a requester and a registrar, allowing the
      requester to benefit from one or more HIP services offered by the
      registrar.  Each registration has an associated finite lifetime.
      Requesters can extend established registrations through re-
      registration (i.e., perform a refresh).

   Registration Type:
      an 8-bit identifier for a given service in the registration
      protocol.  For example, the rendezvous service is identified by a
      specific registration type.

3.  HIP Registration Extension Overview

   This document does not specify the means by which a requester
   discovers the availability of a service, or how a requester locates a
   registrar.  After a requester has discovered a registrar, it either
   initiates HIP base exchange or uses an existing HIP association with
   the registrar.  In both cases, registrars use additional parameters,
   which the remainder of this document defines, to announce their
   quality and grant or refuse registration.  Requesters use
   corresponding parameters to register with the service.  Both the
   registrar and the requester MAY also include in the messages
   exchanged additional HIP parameters specific to the registration type
   requested.  Other documents will define parameters and how they shall
   be used.

   The HIP base exchange, including the definition of the HIP I1, R1,
   I2, and R2 packets, is defined in RFC7401 [RFC7401].  The following
   sections describe the differences between this registration handshake
   and the standard HIP base exchange [RFC7401].





Laganier & Eggert       Expires February 5, 2017                [Page 3]


Internet-Draft         HIP Registration Extension            August 2016


3.1.  Registrar Announcing Its Ability

   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
   packets it sends during all base exchanges with that requester.  If
   it is currently unable to provide services due to transient
   conditions, it SHOULD include an empty REG_INFO, i.e., one with no
   services listed.  If services can be provided later, it SHOULD send
   UPDATE packets indicating the current set of services available in a
   new REG_INFO parameter to all hosts it is associated with.

3.2.  Requester Requesting Registration

   To request registration with a service, a requester constructs and
   includes a corresponding REG_REQUEST parameter in an I2 or UPDATE
   packet it sends to the registrar.

   If the requester has no HIP association established with the
   registrar, it SHOULD send the REG_REQUEST at the earliest
   possibility, i.e., in the I2 packet.  This minimizes the number of
   packets that need to be exchanged with the registrar.  A registrar
   MAY end a HIP association that does not carry a REG_REQUEST by
   including a NOTIFY with the type REG_REQUIRED in the R2.  In this
   case, no HIP association is created between the hosts.  The
   REG_REQUIRED notification error type is 51.

3.3.  Registrar Granting or Refusing Service(s) Registration

   Once registration has been requested, the registrar is able to
   authenticate the requester based on the host identity included in I2.

   If the registrar knows the Host Identities (HIs) of all the hosts
   that are allowed to register for service(s), it SHOULD reject
   registrations from unknown hosts.  However, since it may be
   infeasible to pre-configure the registrar with all the HIs, the
   registrar SHOULD also support HIP certificates
   [I-D.ietf-hip-rfc6253-bis] to allow for certificate based
   authentication.

   When a requester wants to register with a registrar, it SHOULD check
   if it has a suitable certificate for authenticating with the
   registrar.  How the suitability is determined and how the
   certificates are obtained is out of scope for this document.  If the
   requester has one or more suitable certificates, the host SHOULD
   include them (or just the most suitable one) in a CERT parameter to
   the HIP packet along with the REG_REQUEST parameter.  If the
   requester does not have any suitable certificates, it SHOULD send the




Laganier & Eggert       Expires February 5, 2017                [Page 4]


Internet-Draft         HIP Registration Extension            August 2016


   registration request without the CERT parameter to test whether the
   registrar accepts the request based on the host's identity.

   When a registrar receives a HIP packet with a REG_REQUEST parameter,
   and it requires authentication for at least one of the Registration
   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
   Registration Types in the REG_REQUEST parameter.  If the requester is
   in the allowed list (or the registrar does not require any
   authentication), the registrar MUST proceed with the registration.

   If the requester was not in the allowed list and the registrar
   requires the requester to authenticate, the registrar MUST check
   whether the packet also contains a CERT parameter.  If the packet
   does not contain a CERT parameter, the registrar MUST reject the
   registrations requiring authentication with Failure Type 0
   (Registration requires additional credentials).  If the certificate
   is valid and accepted (issued for the requester and signed by a
   trusted issuer), the registrar MUST proceed with the registration.
   If the certificate in the parameter is not accepted, the registrar
   MUST reject the corresponding registrations with the appropriate
   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
   parameter in its response, which contains the service type(s) for
   which it has authorized registration, and zero or more REG_FAILED
   parameters containing the service type(s) for which it has not
   authorized registration or registration has failed for other reasons.
   This response can be either an R2 or an UPDATE message, respectively,
   depending on whether the registration was requested during the base
   exchange, or using an existing association.  In particular,
   REG_FAILED with a failure type of zero indicates the service(s)
   type(s) that require further credentials for registration.



Laganier & Eggert       Expires February 5, 2017                [Page 5]


Internet-Draft         HIP Registration Extension            August 2016


   If the registrar requires further authorization and the requester has
   additional credentials available, the requester SHOULD try to
   register again with the service after the HIP association has been
   established.

   Successful processing of a REG_RESPONSE parameter creates
   registration state at the requester.  In a similar manner, successful
   processing of a REG_REQUEST parameter creates registration state at
   the registrar and possibly at the service.  Both the requester and
   registrar can cancel a registration before it expires, if the
   services afforded by a registration are no longer needed by the
   requester, or cannot be provided any longer by the registrar (for
   instance, because its configuration has changed).

                +-----+          I1          +-----+-----+
                |     |--------------------->|     |  S1 |
                |     |<---------------------|     |     |
                |     | R1(REG_INFO:S1,S2,S3)|     +-----+
                | RQ  |                      |  R  |  S2 |
                |     |    I2(REG_REQ:S1)    |     |     |
                |     |--------------------->|     +-----+
                |     |<---------------------|     |  S3 |
                |     |    R2(REG_RESP:S1)   |     |     |
                +-----+                      +-----+-----+

    A requester (RQ) registers for service (S1) with a registrar (R) of
      services (S1), (S2), and (S3), with which it has no current HIP
                               association.


                +-----+                      +-----+-----+
                |     |  UPDATE(REG_INFO:S)  |     |     |
                |     |<---------------------|     |     |
                | RQ  |--------------------->|  R  |  S  |
                |     |  UPDATE(REG_REQ:S)   |     |     |
                |     |  UPDATE(REG_RESP:S)  |     |     |
                |     |<---------------------|     |     |
                +-----+                      +-----+-----+

    A requester (RQ) registers for service (S) with a registrar (R) of
        services (S), with which it currently has a HIP association
                               established.

4.  Parameter Formats and Processing

   This section describes the format and processing of the new
   parameters introduced by the HIP registration extension.  The




Laganier & Eggert       Expires February 5, 2017                [Page 6]


Internet-Draft         HIP Registration Extension            August 2016


   encoding of these new parameters is conforms to the HIPv2 TLV format
   described in section 5.2.1 of RFC7401 [RFC7401].

4.1.  Encoding Registration Lifetimes with Exponents

   The HIP registration uses an exponential encoding of registration
   lifetimes.

   The special value 0 (zero) of the lifetime field MUST be interpreted
   as representing a special lifetime duration of 0 (zero) seconds, and
   is used to request and grant cancellation of a registration.

   The non-zero values of the lifetime field used throughout this
   document MUST be interpreted as an exponent value representing a
   lifetime duration of 2^((lifetime - 64)/8) seconds.

   This allows a compact encoding of 255 different lifetime durations
   (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
   (i.e., ~178 days) into an 8-bit integer field.

4.2.  REG_INFO

    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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Min Lifetime  | Max Lifetime  |  Reg Type #1  |  Reg Type #2  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      ...      |     ...       |  Reg Type #n  |               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    Padding    +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type           930
   Length         Length in octets, excluding Type, Length, and Padding.
   Min Lifetime   Minimum registration lifetime.
   Max Lifetime   Maximum registration lifetime.
   Reg Type       The registration types offered by the registrar.

   Other documents will define specific values for registration types.
   See Section 7 for more information.

   Registrars include the parameter in R1 packets in order to announce
   their registration capabilities.  The registrar SHOULD include the
   parameter in UPDATE packets when its service offering has changed.
   HIP_SIGNATURE_2 protects the parameter within the R1 packets.



Laganier & Eggert       Expires February 5, 2017                [Page 7]


Internet-Draft         HIP Registration Extension            August 2016


   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 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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Lifetime    |  Reg Type #1  |  Reg Type #2  |  Reg Type #3  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      ...      |     ...       |  Reg Type #n  |               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    Padding    +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type        932
   Length      Length in octets, excluding Type, Length, and Padding.
   Lifetime    Requested registration lifetime.
   Reg Type    The preferred registration types in order of preference.

   Other documents will define specific values for registration types.
   See Section 7 for more information.

   A requester includes the REG_REQUEST parameter in I2 or UPDATE
   packets to register with a registrar's service(s).  If the
   REG_REQUEST parameter is in an UPDATE packet, the registrar MUST NOT
   modify the registrations of registration types that are not listed in
   the parameter.  Moreover, the requester MUST NOT include the
   parameter unless the registrar's R1 packet or latest received UPDATE
   packet has contained a REG_INFO parameter with the requested
   registration types.

   The requester MUST NOT include more than one REG_REQUEST parameter in
   its I2 or UPDATE packets, while the registrar MUST be able to process
   one or more REG_REQUEST parameters in received I2 or UPDATE packets.

   When the registrar receives a registration with a lifetime that is
   either smaller or greater than the minimum or maximum lifetime,
   respectively, then it SHOULD grant the registration for the minimum
   or maximum lifetime, respectively.

   HIP_SIGNATURE protects the parameter within the I2 and UPDATE
   packets.



Laganier & Eggert       Expires February 5, 2017                [Page 8]


Internet-Draft         HIP Registration Extension            August 2016


4.4.  REG_RESPONSE

    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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Lifetime    |  Reg Type #1  |  Reg Type #2  |  Reg Type #3  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      ...      |     ...       |  Reg Type #n  |               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    Padding    +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type        934
   Length      Length in octets, excluding Type, Length, and Padding.
   Lifetime    Granted registration lifetime.
   Reg Type    The granted registration types in order of preference.

   Other documents will define specific values for registration types.
   See Section 7 for more information.

   The registrar SHOULD includes an REG_RESPONSE parameter in its R2 or
   UPDATE packet only if a registration has successfully completed.

   The registrar MUST NOT include more than one REG_RESPONSE parameter
   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
   packets.

   The requester MUST be prepared to receive any registration lifetime,
   including ones beyond the minimum and maximum lifetime indicated in
   the REG_INFO parameter.  It MUST NOT expect that the returned
   lifetime will be the requested one, even when the requested lifetime
   falls within the announced minimum and maximum.

   HIP_SIGNATURE protects the parameter within the R2 and UPDATE
   packets.

4.5.  REG_FAILED











Laganier & Eggert       Expires February 5, 2017                [Page 9]


Internet-Draft         HIP Registration Extension            August 2016


    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    +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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
   ------------    --------------------------------------------
   0               Registration requires additional credentials
   1               Registration type unavailable
   [TBD-IANA]      Insufficient resources
   [TBD-IANA]      Invalid certificate
   [TBD-IANA]-200  Unassigned
   201-255         Reserved by IANA for private use

   Other documents will define specific values for registration types.
   See Section 7 for more information.

   Failure type zero (0) indicates that the registrar requires
   additional credentials to authorize a requester to register with the
   registration types listed in the parameter.  Failure type one (1)
   indicates that the requested service type is unavailable at the
   registrar.  Failure type ([TBD-IANA-Insufficient-resources])
   indicates that the registrar does not 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).  Failure type ([TBD-IANA-Invalid-Certificates])
   indicates that the registrar could not validate the certificate
   provided by the requester to register for the service(s); when that
   is the case the requester MUST NOT reattempt to register for the same
   set of services while providing the same certificate, and MAY attempt
   to register for the same set of service(s) with a different
   certificate, or with a different set of service(s) with the same
   certificate.




Laganier & Eggert       Expires February 5, 2017               [Page 10]


Internet-Draft         HIP Registration Extension            August 2016


   The registrar SHOULD include a REG_FAILED parameter in its R2 or
   UPDATE packet, if registration with the registration types listed has
   not completed successfully and a requester is asked to try again with
   additional credentials.

   HIP_SIGNATURE protects the parameter within the R2 and UPDATE
   packets.

5.  Establishing and Maintaining Registrations

   Establishing and/or maintaining a registration may require additional
   information not available in the transmitted REG_REQUEST or
   REG_RESPONSE parameters.  Therefore, registration type definitions
   MAY define dependencies for HIP parameters that are not defined in
   this document.  Their semantics are subject to the specific
   registration type specifications.

   The minimum lifetime both registrars and requesters MUST support is
   10 seconds, while they SHOULD support a maximum lifetime of 120
   seconds, at least.  These values define a baseline for the
   specification of services based on the registration system.  They
   were chosen to be neither too short nor too long, and to accommodate
   for existing timeouts of state established in middleboxes (e.g., NATs
   and firewalls.)

   A zero lifetime is reserved for canceling purposes.  Requesting a
   zero lifetime for a registration type is equal to canceling the
   registration of that type.  A requester MAY cancel a registration
   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
   zero lifetime.  A registrar (and an attached service) MAY cancel a
   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
   registered requesters.

6.  Security Considerations

   This section discusses the threats on the HIP registration protocol,
   and their implications on the overall security of HIP.  In
   particular, it argues that the extensions described in this document
   do not introduce additional threats to HIP.

   The extensions described in this document rely on the HIP base
   exchange and do not modify its security characteristics, e.g.,
   digital signatures or HMAC.  Hence, the only threat introduced by
   these extensions is related to the creation of soft registration
   state at the registrar.




Laganier & Eggert       Expires February 5, 2017               [Page 11]


Internet-Draft         HIP Registration Extension            August 2016


   Registrars act on a voluntary basis and are willing to accept being a
   responder and then to create HIP associations with a number of
   potentially unknown hosts.  Because they have to store HIP
   association state anyway, adding a certain amount of time-limited HIP
   registration state should not introduce any serious additional
   threats, especially because HIP registrars may cancel registrations
   at any time at their own discretion, e.g., because of resource
   constraints during an attack.

7.  IANA Considerations

   This section is to be interpreted according to the Guidelines for
   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
   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 Types, defined no registration
   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:




Laganier & Eggert       Expires February 5, 2017               [Page 12]


Internet-Draft         HIP Registration Extension            August 2016


   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
   ------------    --------------------------------------------
   [TBD-IANA]      Insufficient resources
   [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

   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.



Laganier & Eggert       Expires February 5, 2017               [Page 13]


Internet-Draft         HIP Registration Extension            August 2016


10.  References

10.1.  Normative References

   [I-D.ietf-hip-rfc5204-bis]
              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]
              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
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <http://www.rfc-editor.org/info/rfc5226>.

   [RFC7401]  Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
              Henderson, "Host Identity Protocol Version 2 (HIPv2)",
              RFC 7401, DOI 10.17487/RFC7401, April 2015,
              <http://www.rfc-editor.org/info/rfc7401>.

10.2.  Informative References

   [I-D.ietf-hip-native-nat-traversal]
              Keranen, A., Melen, J., and M. Komu, "Native NAT Traversal
              Mode for the Host Identity Protocol", draft-ietf-hip-
              native-nat-traversal-13 (work in progress), July 2016.

   [I-D.ietf-hip-rfc4423-bis]
              Moskowitz, R. and M. Komu, "Host Identity Protocol
              Architecture", draft-ietf-hip-rfc4423-bis-14 (work in
              progress), June 2016.

   [RFC3234]  Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
              Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002,
              <http://www.rfc-editor.org/info/rfc3234>.







Laganier & Eggert       Expires February 5, 2017               [Page 14]


Internet-Draft         HIP Registration Extension            August 2016


   [RFC5203]  Laganier, J., Koponen, T., and L. Eggert, "Host Identity
              Protocol (HIP) Registration Extension", RFC 5203,
              DOI 10.17487/RFC5203, April 2008,
              <http://www.rfc-editor.org/info/rfc5203>.















































Laganier & Eggert       Expires February 5, 2017               [Page 15]


Internet-Draft         HIP Registration Extension            August 2016


Appendix A.  Changes from RFC 5203

   o  Updated references to revised HIP specifications.

   o  Added a new registration failure type for use in case of
      insufficient resources available at the HIP registrar.

   o  Added requester authorization based on certificates, and new
      registration failure types for invalid certificate.

Authors' Addresses

   Julien Laganier
   Luminate Wireless, Inc.
   Cupertino, CA
   USA

   EMail: julien.ietf@gmail.com


   Lars Eggert
   NetApp
   Sonnenallee 1
   Kirchheim  85551
   Germany

   Phone: +49 151 12055791
   EMail: lars@netapp.com
   URI:   http://eggert.org






















Laganier & Eggert       Expires February 5, 2017               [Page 16]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/