RFC 8003

Host Identity Protocol (HIP) Registration Extension

📅 published October 2016, from ietf

RFC 8003: Host Identity Protocol (HIP) Registration Extension 🦋

Okay bestie, so this is RFC 8003, and the title is the Host Identity Protocol (HIP) Registration Extension 💖. It came out from the IETF in October 2016 as a Standards Track document ✨. The authors are J. Laganier from Luminate Wireless, Inc. and L. Eggert from NetApp 🫶. Its ISSN is 2070-1721. It obsoletes RFC 5203 (that's the big glow-up 👑), and the title page doesn't list anything it updates 🌸.

Abstract

This doc sets up a registration mechanism for HIP 🎀 so hosts can register with services, like HIP rendezvous servers or middleboxes. It also obsoletes RFC 5203 💅.

Status of This Memo

This is an Internet Standards Track document 🌈.

This document is a product of the Internet Engineering Task Force (IETF) 💜. It represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication ✨. If you want more info about Internet Standards, check Section 2 of RFC 7841 🍓.

Info about the current status of this document, any errata, and how to give feedback on it lives at http://www.rfc-editor.org/info/rfc8003 🦋.

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) as they stood on the publication date 📜. Please actually read these, because they spell out your rights and restrictions for this document 🙈. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 💀.

Table of Contents

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
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  . . . . . . . . . . . . . .   7
  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  . . . . . . . . . . . . . . . . . . . . . . .  10
5.  Establishing and Maintaining Registrations  . . . . . . . . .  11
6.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
  8.1.  Normative References  . . . . . . . . . . . . . . . . . .  13
  8.2.  Informative References  . . . . . . . . . . . . . . . . .  14
Appendix A.  Changes from RFC 5203  . . . . . . . . . . . . . . .  15
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  15
Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  15
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

1. Introduction ✨

This doc is an extension to the Host Identity Protocol (HIP) [RFC7401] 🌸. It gives hosts a generic way to register with a service 💖. That service could be a HIP rendezvous server [RFC8004] or a middlebox [RFC3234] 🧚.

The doc doesn't make any extra assumptions about what kind of service it is 💅. It also doesn't define any ways to discover that specific services exist, or how to talk to them after you register 🙈. Future docs might cover that stuff 🔮.

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 🎀

On top of the terms in the HIP Architecture [HIP-ARCH], the HIP specification [RFC7401], and the HIP Rendezvous Extension [RFC8004], this doc defines and uses these terms 💜:

  • Requester: a HIP node that registers with a HIP registrar to ask for registration for a service 🦋.
  • Registrar: a HIP node that offers registration for one or more services 🌈.
  • Service: a facility that gives requesters 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, which lets the requester benefit from one or more HIP services the registrar offers ✨. Each registration has a finite lifetime attached to it ⏳. Requesters can extend registrations by re-registering, which is basically a refresh 💅.
  • Registration Type: an 8-bit identifier for a given service in the registration protocol 🧚. For example, the rendezvous service is identified by its own specific registration type 🫶.

3. HIP Registration Extension Overview 🌸

This doc doesn't say how a requester finds out a service is available, or how it locates a registrar 🙈. Once a requester has found a registrar, it either starts a HIP base exchange or uses an existing HIP association with that registrar 💖. Either way, registrars use extra parameters (the rest of this doc defines them) to announce their quality and to grant or refuse registration 👑. Requesters send matching parameters to register with the service ✨. The registrar and the requester MAY also include other HIP parameters in the messages they swap, if they're specific to the registration type being requested 🦋. Other docs will define those parameters and how they shall be used 📜.

The HIP base exchange, including the HIP I1, R1, I2, and R2 packets, is defined in [RFC7401] 🌈. The next sections describe how this registration handshake differs from the standard HIP base exchange [RFC7401] 🎀.

3.1. Registrar Announcing Its Ability 📣

A host that can act as a registrar and wants to, for a specific requester, SHOULD include a REG_INFO parameter in the R1 packets it sends during all base exchanges with that requester 💅. If it can't provide services right now because of transient conditions, it SHOULD include an empty REG_INFO, meaning one with no services listed 🥺. If services become available later, the host SHOULD send UPDATE packets to all hosts it's associated with, and those packets should carry the current set of available services in a new REG_INFO parameter 🔥.

3.2. Requester Requesting Registration 🙋‍♀️

To request registration with a service, a requester builds a matching REG_REQUEST parameter and puts it in an I2 or UPDATE packet it sends to the registrar 💖.

If the requester has no HIP association with the registrar yet, it SHOULD send the REG_REQUEST as early as possible, which means in the I2 packet 🏃‍♀️. That keeps the number of packets exchanged with the registrar as low as it can be 🫶. A registrar MAY end a HIP association that doesn't carry a REG_REQUEST, by including a NOTIFY with the type REG_REQUIRED in the R2 🙈. In that case, no HIP association gets created between the two hosts 💀. The REG_REQUIRED notification error type is 51 👑.

3.3. Registrar Granting or Refusing Service(s) Registration ✨

okay so once a requester has asked to register, the registrar can actually authenticate them using the host identity that came along in I2 🫶

If the registrar already knows the Host Identities (HIs) of every host that's allowed to register for service(s), it SHOULD reject registrations from unknown hosts 🙅‍♀️. But bestie, it can be infeasible to preconfigure the registrar with all the HIs 😭, so the registrar SHOULD also support HIP certificates [RFC8002] 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 suitability gets determined and how the certificates get 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 doesn't have any suitable certificates, it SHOULD send the 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 doesn't 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 doesn't contain a CERT parameter, the registrar MUST reject the registrations requiring authentication with Failure Type 0 (zero) (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:

  • 4 (Bad certificate): The certificate is corrupt, contains invalid signatures, etc.
  • 5 (Unsupported certificate): The certificate is of an unsupported type.
  • 6 (Certificate expired): The certificate is no longer valid.
  • 7 (Certificate other): The certificate could not be validated for some unspecified reason.
  • 8 (Unknown CA): The issuing certification authority (CA) certificate could not be located or is not trusted.

After successful authorization, the registrar includes a REG_RESPONSE parameter in its response 🎉. That parameter contains the service type(s) it has authorized for registration, plus zero or more REG_FAILED parameters containing the service type(s) it has not authorized, or where registration 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 🔄. And REG_FAILED with a Failure Type of zero is the one that tells you which service type(s) need further credentials for registration 💅.

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 🎀

okay this section is the nitty-gritty 🤓 It describes the format and processing of the new parameters introduced by the HIP Registration Extension. The encoding of these new parameters 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 it's 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 🤯 so so clean.

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 🔐.

The registrar indicates the minimum and maximum registration lifetime that it's willing to offer to a requester ⏰. A requester SHOULD NOT request registration with a 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 aren't 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 🔏.

4.4. REG_RESPONSE 🎀

okay bestie, this is the registrar's big "you're in!" message 💖 It rides in the R2 or UPDATE packet, and it tells you what you actually got. Here's the shape:

    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 include a REG_RESPONSE parameter in its R2 or UPDATE packet only if a registration has successfully completed. So no REG_RESPONSE unless you actually got in 💅

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. So the registrar keeps it to one, but you have to be ready to handle a whole stack 🫶

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. Translation: you asked for a lifetime, but the registrar gets the final say, and you do NOT get to be shocked by it 😭🙈

HIP_SIGNATURE protects the parameter within the R2 and UPDATE packets. So it's sealed up tight 🔒🦋

4.5. REG_FAILED 💀

Now the not-so-fun twin. REG_FAILED is what the registrar sends when things didn't work out ✨

    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.

     Value       Registration Failure Type
   ----------    --------------------------------------------
      0          Registration requires additional credentials
      1          Registration type unavailable
      2          Insufficient resources
      3          Invalid certificate
      9-200      Unassigned
    201-255      Reserved for Private Use

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

Failure Type 0 (zero) means the registrar wants extra credentials before it'll authorize you for the registration types listed in the parameter. Failure Type 1 (one) means the service type you asked for is unavailable at this registrar. Failure Type 2 means the registrar doesn't have enough resources right now to register you for those services. When that's 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 the service(s). Failure Type 3 means the registrar couldn't validate the certificate you sent for those services. When that happens, 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 services with a different certificate, or with a different set of services with the same certificate. 🌸 Basically, don't keep knocking with the same thing that got rejected. Switch it up!

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 ✨

Setting up and keeping up a registration can need extra info that isn't in the REG_REQUEST or REG_RESPONSE parameters. So 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 are a baseline for the specification of services based on the registration system. They were picked to be neither too short nor too long, and to accommodate existing timeouts of state established in middleboxes (e.g., NATs and firewalls.) 🦋

A zero lifetime is reserved for canceling. Requesting a zero lifetime for a registration type is the same as 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. Serious business, bestie 🧐

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

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 states 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. So even if someone tries to flood them, the registrar can just drop registrations to breathe 😮‍💨💜

7. IANA Considerations 📚

This section is to be interpreted according to "Guidelines for Writing an IANA Considerations Section in RFCs" [RFC5226].

[RFC5203], obsoleted by this document, made the following definitions and reservations in the "Parameter Types" subregistry under "Host Identity Protocol (HIP) Parameters":

   Value   Parameter Type  Length
   -----   --------------  --------
   930     REG_INFO        variable
   932     REG_REQUEST     variable
   934     REG_RESPONSE    variable
   936     REG_FAILED      variable

In the "Parameter Types" subregistry under "Host Identity Protocol (HIP) Parameters", the references to the obsoleted [RFC5203] have been replaced with references to this document. 🔄

[RFC5203], obsoleted by this document, requested the opening of the "Registration Types" subregistry under "Host Identity Protocol (HIP) Parameters", defined no registration types, but made the following reservations in that subregistry:

   Reg Type        Service
   --------        --------------------------------
   201-255         Reserved by IANA for private use

Adding a new type requires new IETF specifications. 📝

In the "Registration Types" subregistry under "Host Identity Protocol (HIP) Parameters", references to the obsoleted [RFC5203] have been replaced with references to this document. 🔄

[RFC5203], obsoleted by this document, requested the opening of the "Registration Failure Types" subregistry under "Host Identity Protocol (HIP) Parameters" and made the following definitions and reservations in that subregistry:

   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. 📝

In the "Registration Failure Types" subregistry under "Host Identity Protocol (HIP) Parameters", references to the obsoleted [RFC5203] have been replaced with references to this document, and the following HIP Registration Failure Types have been added:

      Value        Registration Failure Type
   ------------    --------------------------------------------
        2          Insufficient resources
        3          Invalid certificate
        4          Bad certificate
        5          Unsupported certificate
        6          Certificate expired
        7          Certificate other
        8          Unknown CA
     201-255       Reserved for Private Use

8. References 📖

8.1. Normative References

8.2. Informative References

  • [HIP-ARCH] Moskowitz, R. and M. Komu, "Host Identity Protocol Architecture", Work in Progress, draft-ietf-hip-rfc4423-bis-14, June 2016.
  • [HIP-NAT] Keranen, A., Melen, J., and M. Komu, "Native NAT Traversal Mode for the Host Identity Protocol", Work in Progress, draft-ietf-hip-native-nat-traversal-13, July 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.
  • [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.

Appendix A. Changes from RFC 5203 🎀

okay so this appendix is basically the glow-up tea ☕ compared to RFC 5203:

  • Updated references to revised HIP specifications. 💅 the HIP specs got revised, so the references got updated to match.
  • Added a new registration Failure Type for use in case of insufficient resources available at the HIP registrar. 🔥 there's a new Failure Type for when the HIP registrar is running low on resources.
  • Added requester authorization based on certificates and new registration Failure Types for invalid certificates. 🔐 requesters can now be authorized with certificates, plus new Failure Types for invalid certs. iconic 👑

Acknowledgments 🫶

bestie, these people (listed in alphabetical order 📝) gave thoughtful and helpful discussions and/or suggestions that made this doc way better: Jeffrey Ahrenholz, Miriam Esteban, Ari Keranen, Mika Kousa, Pekka Nikander, and Hannes Tschofenig 💖

Lars Eggert 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 the HIP native NAT traversal specification [HIP-NAT]. 🧚 that's a full-on "adapted from the best" moment.

Thanks to Joel M. Halpern for performing the Gen-ART review of this document as part of the publication process. 🌸

Contributors 🌈

Teemu Koponen coauthored an earlier, experimental version of this specification [RFC5203]. ✨ the OG version, respect 🫡

Authors' Addresses 🦋

Julien Laganier
Luminate Wireless, Inc.
Cupertino, CA
United States of America

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
📦 where this page comes from