diff options
Diffstat (limited to 'doc/rfc/rfc8003.txt')
| -rw-r--r-- | doc/rfc/rfc8003.txt | 899 |
1 files changed, 899 insertions, 0 deletions
diff --git a/doc/rfc/rfc8003.txt b/doc/rfc/rfc8003.txt new file mode 100644 index 0000000..6032e6b --- /dev/null +++ b/doc/rfc/rfc8003.txt @@ -0,0 +1,899 @@ + + + + + + +Internet Engineering Task Force (IETF) J. Laganier +Request for Comments: 8003 Luminate Wireless, Inc. +Obsoletes: 5203 L. Eggert +Category: Standards Track NetApp +ISSN: 2070-1721 October 2016 + + + Host Identity Protocol (HIP) Registration Extension + +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 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 has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc8003. + +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 Standards Track [Page 1] + +RFC 8003 HIP Registration Extension October 2016 + + +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 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 [RFC8004] 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]. + + + + + + + + + + +Laganier & Eggert Standards Track [Page 2] + +RFC 8003 HIP Registration Extension October 2016 + + +2. Terminology + + In addition to the terminology defined in the HIP Architecture + [HIP-ARCH], the HIP specification [RFC7401], and the HIP Rendezvous + Extension [RFC8004], 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. + + + + + + +Laganier & Eggert Standards Track [Page 3] + +RFC 8003 HIP Registration Extension October 2016 + + + The HIP base exchange, including the definition of the HIP I1, R1, + I2, and R2 packets, is defined in [RFC7401]. The following sections + describe the differences between this registration handshake and the + standard HIP base exchange [RFC7401]. + +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 preconfigure the registrar with all the HIs, 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 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 + + + +Laganier & Eggert Standards Track [Page 4] + +RFC 8003 HIP Registration Extension October 2016 + + + 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 + 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 (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, 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 + + + + +Laganier & Eggert Standards Track [Page 5] + +RFC 8003 HIP Registration Extension October 2016 + + + exchange or using an existing association. In particular, REG_FAILED + with a Failure Type of zero indicates the service type(s) that + requires 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 + + + + + +Laganier & Eggert Standards Track [Page 6] + +RFC 8003 HIP Registration Extension October 2016 + + +4. Parameter Formats and Processing + + This section 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 + 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. + + + + +Laganier & Eggert Standards Track [Page 7] + +RFC 8003 HIP Registration Extension October 2016 + + + 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 is 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 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. + + + + + + +Laganier & Eggert Standards Track [Page 8] + +RFC 8003 HIP Registration Extension October 2016 + + + 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 + + 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. + + 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. + + + + + +Laganier & Eggert Standards Track [Page 9] + +RFC 8003 HIP Registration Extension October 2016 + + +4.5. REG_FAILED + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Failure Type | Reg Type #1 | Reg Type #2 | Reg Type #3 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ... | ... | Reg Type #n | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + 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) indicates that the registrar requires + additional credentials to authorize a requester to register with the + registration types listed in the parameter. Failure Type 1 (one) + indicates that the requested service type is unavailable at the + registrar. Failure Type 2 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 the service(s). Failure + Type 3 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 services with a different + certificate, or with a different set of services with the same + certificate. + + + +Laganier & Eggert Standards Track [Page 10] + +RFC 8003 HIP Registration Extension October 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 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. + + + + +Laganier & Eggert Standards Track [Page 11] + +RFC 8003 HIP Registration Extension October 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 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. + +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: + + + +Laganier & Eggert Standards Track [Page 12] + +RFC 8003 HIP Registration Extension October 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. + + 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 + + [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>. + + [RFC8002] Heer, T. and S. Varjonen, "Host Identity Protocol + Certificates", RFC 8002, DOI 10.17487/RFC8002, October + 2016, <http://www.rfc-editor.org/info/rfc8002>. + + + + + +Laganier & Eggert Standards Track [Page 13] + +RFC 8003 HIP Registration Extension October 2016 + + + [RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) + Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004, + October 2016, <http://www.rfc-editor.org/info/rfc8004>. + +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>. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Laganier & Eggert Standards Track [Page 14] + +RFC 8003 HIP Registration Extension October 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 certificates. + +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 the HIP native NAT traversal specification [HIP-NAT]. + + 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]. + + + + + + + + + + + + + + + + + +Laganier & Eggert Standards Track [Page 15] + +RFC 8003 HIP Registration Extension October 2016 + + +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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Laganier & Eggert Standards Track [Page 16] + |