idnits 2.17.1 draft-ietf-hip-rfc5203-bis-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 1, 2014) is 3496 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBD-IANA' is mentioned on line 413, but not defined == Outdated reference: A later version (-20) exists of draft-ietf-hip-rfc5201-bis-16 == Outdated reference: A later version (-08) exists of draft-ietf-hip-rfc5204-bis-04 == Outdated reference: A later version (-09) exists of draft-ietf-hip-rfc6253-bis-01 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-33) exists of draft-ietf-hip-native-nat-traversal-07 == Outdated reference: A later version (-20) exists of draft-ietf-hip-rfc4423-bis-08 -- Obsolete informational reference (is this intentional?): RFC 5203 (Obsoleted by RFC 8003) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Laganier 3 Internet-Draft Luminate Wireless, Inc. 4 Obsoletes: 5203 (if approved) L. Eggert 5 Intended status: Standards Track NetApp 6 Expires: March 5, 2015 September 1, 2014 8 Host Identity Protocol (HIP) Registration Extension 9 draft-ietf-hip-rfc5203-bis-06 11 Abstract 13 This document specifies a registration mechanism for the Host 14 Identity Protocol (HIP) that allows hosts to register with services, 15 such as HIP rendezvous servers or middleboxes. This document 16 obsoletes RFC5203. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on March 5, 2015. 35 Copyright Notice 37 Copyright (c) 2014 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 3. HIP Registration Extension Overview . . . . . . . . . . . . . 3 55 3.1. Registrar Announcing Its Ability . . . . . . . . . . . . 4 56 3.2. Requester Requesting Registration . . . . . . . . . . . . 4 57 3.3. Registrar Granting or Refusing Service(s) Registration . 4 58 4. Parameter Formats and Processing . . . . . . . . . . . . . . 6 59 4.1. Encoding Registration Lifetimes with Exponents . . . . . 6 60 4.2. REG_INFO . . . . . . . . . . . . . . . . . . . . . . . . 6 61 4.3. REG_REQUEST . . . . . . . . . . . . . . . . . . . . . . . 7 62 4.4. REG_RESPONSE . . . . . . . . . . . . . . . . . . . . . . 8 63 4.5. REG_FAILED . . . . . . . . . . . . . . . . . . . . . . . 9 64 5. Establishing and Maintaining Registrations . . . . . . . . . 10 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 67 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 68 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 69 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 71 10.2. Informative References . . . . . . . . . . . . . . . . . 13 72 Appendix A. Changes from RFC 5203 . . . . . . . . . . . . . . . 14 74 1. Introduction 76 This document specifies an extension to the Host Identity Protocol 77 (HIP) [I-D.ietf-hip-rfc5201-bis]. The extension provides a generic 78 means for a host to register with a service. The service may, for 79 example, be a HIP rendezvous server [I-D.ietf-hip-rfc5204-bis] or a 80 middlebox [RFC3234]. 82 This document makes no further assumptions about the exact type of 83 service. Likewise, this document does not specify any mechanisms to 84 discover the presence of specific services or means to interact with 85 them after registration. Future documents may describe those 86 operations. 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in RFC 2119 [RFC2119]. 92 2. Terminology 94 In addition to the terminology defined in the HIP Architecture 95 [I-D.ietf-hip-rfc4423-bis], the HIP specification 96 [I-D.ietf-hip-rfc5201-bis], and the HIP Rendezvous Extension 98 [I-D.ietf-hip-rfc5204-bis], this document defines and uses the 99 following terms: 101 Requester: 102 a HIP node registering with a HIP registrar to request 103 registration for a service. 105 Registrar: 106 a HIP node offering registration for one or more services. 108 Service: 109 a facility that provides requesters with new capabilities or 110 functionalities operating at the HIP layer. Examples include 111 firewalls that support HIP traversal or HIP rendezvous servers. 113 Registration: 114 shared state stored by a requester and a registrar, allowing the 115 requester to benefit from one or more HIP services offered by the 116 registrar. Each registration has an associated finite lifetime. 117 Requesters can extend established registrations through re- 118 registration (i.e., perform a refresh). 120 Registration Type: 121 an identifier for a given service in the registration protocol. 122 For example, the rendezvous service is identified by a specific 123 registration type. 125 3. HIP Registration Extension Overview 127 This document does not specify the means by which a requester 128 discovers the availability of a service, or how a requester locates a 129 registrar. After a requester has discovered a registrar, it either 130 initiates HIP base exchange or uses an existing HIP association with 131 the registrar. In both cases, registrars use additional parameters, 132 which the remainder of this document defines, to announce their 133 quality and grant or refuse registration. Requesters use 134 corresponding parameters to register with the service. Both the 135 registrar and the requester MAY also include in the messages 136 exchanged additional HIP parameters specific to the registration type 137 implicated. Other documents will define parameters and how they 138 shall be used. The following sections describe the differences 139 between this registration handshake and the standard HIP base 140 exchange [I-D.ietf-hip-rfc5201-bis]. 142 3.1. Registrar Announcing Its Ability 144 A host that is capable and willing to act as a registrar SHOULD 145 include a REG_INFO parameter in the R1 packets it sends during all 146 base exchanges. If it is currently unable to provide services due to 147 transient conditions, it SHOULD include an empty REG_INFO, i.e., one 148 with no services listed. If services can be provided later, it 149 SHOULD send UPDATE packets indicating the current set of services 150 available in a new REG_INFO parameter to all hosts it is associated 151 with. 153 3.2. Requester Requesting Registration 155 To request registration with a service, a requester constructs and 156 includes a corresponding REG_REQUEST parameter in an I2 or UPDATE 157 packet it sends to the registrar. 159 If the requester has no HIP association established with the 160 registrar, it SHOULD send the REG_REQUEST at the earliest 161 possibility, i.e., in the I2 packet. This minimizes the number of 162 packets that need to be exchanged with the registrar. A registrar 163 MAY end a HIP association that does not carry a REG_REQUEST by 164 including a NOTIFY with the type REG_REQUIRED in the R2. In this 165 case, no HIP association is created between the hosts. The 166 REG_REQUIRED notification error type is 51. 168 3.3. Registrar Granting or Refusing Service(s) Registration 170 Once registration has been requested, the registrar is able to 171 authenticate the requester based on the host identity included in I2. 173 If the registrar knows the Host Identities (HIs) of all the hosts 174 that are allowed to register for service(s), it SHOULD reject 175 registrations from unknown hosts. However, since it may be 176 unfeasible to pre-configure the registrar with all the HIs, the 177 registrar SHOULD also support HIP certificates 178 [I-D.ietf-hip-rfc6253-bis] to allow for certificate based 179 authentication. 181 When a requester wants to register with a registrar, it SHOULD check 182 if it has a suitable certificate for authenticating with the 183 registrar. How the suitability is determined and how the 184 certificates are obtained is out of scope for this document. If the 185 requester has one or more suitable certificates, the host SHOULD 186 include them (or just the most suitable one) in a CERT parameter to 187 the HIP packet along with the REG_REQUEST parameter. If the 188 requester does not have any suitable certificates, it SHOULD send the 189 registration request without the CERT parameter to test whether the 190 registrar accepts the request based on the host's identity. 192 When a registrar receives a HIP packet with a REG_REQUEST parameter, 193 and it requires authentication for at least one of the Registration 194 Types listed in the REG_REQUEST parameter, it MUST first check 195 whether the HI of the requester is in the allowed list for all the 196 Registration Types in the REG_REQUEST parameter. If the requester is 197 in the allowed list (or the registrar does not require any 198 authentication), the registrar MUST proceed with the registration. 200 If the requester was not in the allowed list and the registrar 201 requires the requester to authenticate, the registrar MUST check 202 whether the packet also contains a CERT parameter. If the packet 203 does not contain a CERT parameter, the registrar MUST reject the 204 registrations requiring authentication with Failure Type 0 205 (Registration requires additional credentials). If the certificate 206 is valid and accepted (issued for the requester and signed by a 207 trusted issuer), the registrar MUST proceed with the registration. 208 If the certificate in the parameter is not accepted, the registrar 209 MUST reject the corresponding registrations with Failure Type [IANA 210 TBD] (Invalid certificate). 212 After successful authorization, the registrar includes a REG_RESPONSE 213 parameter in its response, which contains the service type(s) for 214 which it has authorized registration, and zero or more REG_FAILED 215 parameters containing the service type(s) for which it has not 216 authorized registration or registration has failed for other reasons. 217 This response can be either an R2 or an UPDATE message, respectively, 218 depending on whether the registration was requested during the base 219 exchange, or using an existing association. In particular, 220 REG_FAILED with a failure type of zero indicates the service(s) 221 type(s) that require further credentials for registration. 223 If the registrar requires further authorization and the requester has 224 additional credentials available, the requester SHOULD try to 225 register again with the service after the HIP association has been 226 established. 228 Successful processing of a REG_RESPONSE parameter creates 229 registration state at the requester. In a similar manner, successful 230 processing of a REG_REQUEST parameter creates registration state at 231 the registrar and possibly at the service. Both the requester and 232 registrar can cancel a registration before it expires, if the 233 services afforded by a registration are no longer needed by the 234 requester, or cannot be provided any longer by the registrar (for 235 instance, because its configuration has changed). 237 +-----+ I1 +-----+-----+ 238 | |--------------------->| | S1 | 239 | |<---------------------| | | 240 | | R1(REG_INFO:S1,S2,S3)| +-----+ 241 | RQ | | R | S2 | 242 | | I2(REG_REQ:S1) | | | 243 | |--------------------->| +-----+ 244 | |<---------------------| | S3 | 245 | | R2(REG_RESP:S1) | | | 246 +-----+ +-----+-----+ 248 A requester (RQ) registers for service (S1) with a registrar (R) of 249 services (S1), (S2), and (S3), with which it has no current HIP 250 association. 252 +-----+ +-----+-----+ 253 | | UPDATE(REG_INFO:S) | | | 254 | |<---------------------| | | 255 | RQ |--------------------->| R | S | 256 | | UPDATE(REG_REQ:S) | | | 257 | | UPDATE(REG_RESP:S) | | | 258 | |<---------------------| | | 259 +-----+ +-----+-----+ 261 A requester (RQ) registers for service (S) with a registrar (R) of 262 services (S), with which it currently has a HIP association 263 established. 265 4. Parameter Formats and Processing 267 This section describes the format and processing of the new 268 parameters introduced by the HIP registration extension. 270 4.1. Encoding Registration Lifetimes with Exponents 272 The HIP registration uses an exponential encoding of registration 273 lifetimes. This allows compact encoding of 255 different lifetime 274 values ranging from 4 ms to 178 days into an 8-bit integer field. 275 The lifetime exponent field used throughout this document MUST be 276 interpreted as representing the lifetime value 2^((lifetime - 64)/8) 277 seconds. 279 4.2. REG_INFO 280 0 1 2 3 281 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 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Type | Length | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Min Lifetime | Max Lifetime | Reg Type #1 | Reg Type #2 | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | ... | ... | Reg Type #n | | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding + 289 | | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 Type 930 293 Length Length in octets, excluding Type, Length, and Padding. 294 Min Lifetime Minimum registration lifetime. 295 Max Lifetime Maximum registration lifetime. 296 Reg Type The registration types offered by the registrar. 298 Other documents will define specific values for registration types. 299 See Section 7 for more information. 301 Registrars include the parameter in R1 packets in order to announce 302 their registration capabilities. The registrar SHOULD include the 303 parameter in UPDATE packets when its service offering has changed. 304 HIP_SIGNATURE_2 protects the parameter within the R1 packets. 306 4.3. REG_REQUEST 308 0 1 2 3 309 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 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Type | Length | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Lifetime | Reg Type #1 | Reg Type #2 | Reg Type #3 | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | ... | ... | Reg Type #n | | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding + 317 | | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 Type 932 321 Length Length in octets, excluding Type, Length, and Padding. 322 Lifetime Requested registration lifetime. 323 Reg Type The preferred registration types in order of preference. 325 Other documents will define specific values for registration types. 326 See Section 7 for more information. 328 A requester includes the REG_REQUEST parameter in I2 or UPDATE 329 packets to register with a registrar's service(s). If the 330 REG_REQUEST parameter is in an UPDATE packet, the registrar MUST NOT 331 modify the registrations of registration types that are not listed in 332 the parameter. Moreover, the requester MUST NOT include the 333 parameter unless the registrar's R1 packet or latest received UPDATE 334 packet has contained a REG_INFO parameter with the requested 335 registration types. 337 The requester MUST NOT include more than one REG_REQUEST parameter in 338 its I2 or UPDATE packets, while the registrar MUST be able to process 339 one or more REG_REQUEST parameters in received I2 or UPDATE packets. 341 When the registrar receives a registration with a lifetime that is 342 either smaller or greater than the minimum or maximum lifetime, 343 respectively, then it SHOULD grant the registration for the minimum 344 or maximum lifetime, respectively. 346 HIP_SIGNATURE protects the parameter within the I2 and UPDATE 347 packets. 349 4.4. REG_RESPONSE 351 0 1 2 3 352 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 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | Type | Length | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Lifetime | Reg Type #1 | Reg Type #2 | Reg Type #3 | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | ... | ... | Reg Type #n | | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding + 360 | | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 Type 934 364 Length Length in octets, excluding Type, Length, and Padding. 365 Lifetime Granted registration lifetime. 366 Reg Type The granted registration types in order of preference. 368 Other documents will define specific values for registration types. 369 See Section 7 for more information. 371 The registrar SHOULD includes an REG_RESPONSE parameter in its R2 or 372 UPDATE packet only if a registration has successfully completed. 374 The registrar MUST NOT include more than one REG_RESPONSE parameter 375 in its R2 or UPDATE packets, while the requester MUST be able to 376 process one or more REG_RESPONSE parameters in received R2 or UPDATE 377 packets. 379 The requester MUST be prepared to receive any registration lifetime, 380 including ones beyond the minimum and maximum lifetime indicated in 381 the REG_INFO parameter. It MUST NOT expect that the returned 382 lifetime will be the requested one, even when the requested lifetime 383 falls within the announced minimum and maximum. 385 HIP_SIGNATURE protects the parameter within the R2 and UPDATE 386 packets. 388 4.5. REG_FAILED 390 0 1 2 3 391 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 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Type | Length | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | Failure Type | Reg Type #1 | Reg Type #2 | Reg Type #3 | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | ... | ... | Reg Type #n | | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding + 399 | | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 Type 936 403 Length Length in octets, excluding Type, Length, and Padding. 404 Failure Type Reason for failure. 405 Reg Type The registration types that failed with the specified 406 reason. 408 Failure Type Reason 409 ------------ -------------------------------------------- 410 0 Registration requires additional credentials 411 1 Registration type unavailable 412 2 Insufficient resources 413 [TBD-IANA] Invalid certificate 414 3-200 Unassigned 415 201-255 Reserved by IANA for private use 417 Other documents will define specific values for registration types. 418 See Section 7 for more information. 420 Failure type zero (0) indicates that the registrar requires 421 additional credentials to authorize a requester to register with the 422 registration types listed in the parameter. Failure type one (1) 423 indicates that the requested service type is unavailable at the 424 registrar. Failure type (2) indicates that the registrar does not 425 currently have enough resources to register the requester for the 426 service(s); when that is the case the requester MUST NOT reattempt 427 immediately to register for the same service(s), and MAY attempt to 428 contact another registrar to register for these service(s). 430 The registrar SHOULD include a REG_FAILED parameter in its R2 or 431 UPDATE packet, if registration with the registration types listed has 432 not completed successfully and a requester is asked to try again with 433 additional credentials. 435 HIP_SIGNATURE protects the parameter within the R2 and UPDATE 436 packets. 438 5. Establishing and Maintaining Registrations 440 Establishing and/or maintaining a registration may require additional 441 information not available in the transmitted REG_REQUEST or 442 REG_RESPONSE parameters. Therefore, registration type definitions 443 MAY define dependencies for HIP parameters that are not defined in 444 this document. Their semantics are subject to the specific 445 registration type specifications. 447 The minimum lifetime both registrars and requesters MUST support is 448 10 seconds, while they SHOULD support a maximum lifetime of 120 449 seconds, at least. These values define a baseline for the 450 specification of services based on the registration system. They 451 were chosen to be neither too short nor too long, and to accommodate 452 for existing timeouts of state established in middleboxes (e.g., NATs 453 and firewalls.) 455 A zero lifetime is reserved for canceling purposes. Requesting a 456 zero lifetime for a registration type is equal to canceling the 457 registration of that type. A requester MAY cancel a registration 458 before it expires by sending a REG_REQ to the registrar with a zero 459 lifetime. A registrar SHOULD respond and grant a registration with a 460 zero lifetime. A registrar (and an attached service) MAY cancel a 461 registration before it expires, at its own discretion. However, if 462 it does so, it SHOULD send a REG_RESPONSE with a zero lifetime to all 463 registered requesters. 465 6. Security Considerations 467 This section discusses the threats on the HIP registration protocol, 468 and their implications on the overall security of HIP. In 469 particular, it argues that the extensions described in this document 470 do not introduce additional threats to HIP. 472 The extensions described in this document rely on the HIP base 473 exchange and do not modify its security characteristics, e.g., 474 digital signatures or HMAC. Hence, the only threat introduced by 475 these extensions is related to the creation of soft registration 476 state at the registrar. 478 Registrars act on a voluntary basis and are willing to accept being a 479 responder and then to create HIP associations with a number of 480 potentially unknown hosts. Because they have to store HIP 481 association state anyway, adding a certain amount of time-limited HIP 482 registration state should not introduce any serious additional 483 threats, especially because HIP registrars may cancel registrations 484 at any time at their own discretion, e.g., because of resource 485 constraints during an attack. 487 7. IANA Considerations 489 This section is to be interpreted according to the Guidelines for 490 Writing an IANA Considerations Section in RFCs [RFC5226]. 492 This document updates the IANA Registry for HIP Parameter Types by 493 assigning new HIP Parameter Types values for the new HIP Parameters 494 defined in this document: 496 o REG_INFO (defined in Section 4.2) 498 o REG_REQUEST (defined in Section 4.3) 500 o REG_RESPONSE (defined in Section 4.4) 502 o REG_FAILED (defined in Section 4.5) 504 IANA has allocated the Notify Message Type code 51 for the 505 REG_REQUIRED notification error type in the Notify Message Type 506 registry. 508 IANA has opened a new registry for registration types. This document 509 does not define registration types but makes the following 510 reservations: 512 Reg Type Service 513 -------- ------- 514 0-200 Unassigned 515 201-255 Reserved by IANA for private use 517 Adding a new type requires new IETF specifications. 519 IANA has opened a new registry for registration failure types. This 520 document makes the following failure type definitions and 521 reservations: 523 Failure Type Reason 524 ------------ -------------------------------------------- 525 0 Registration requires additional credentials 526 1 Registration type unavailable 527 3 Insufficient resources 528 2-200 Unassigned 529 201-255 Reserved by IANA for private use 531 Adding a new type requires new IETF specifications. 533 8. Contributors 535 Teemu Koponen co-authored an earlier, experimental version of this 536 specification [RFC5203]. 538 9. Acknowledgments 540 The following people (in alphabetical order) have provided thoughtful 541 and helpful discussions and/or suggestions that have helped to 542 improve this document: Jeffrey Ahrenholz, Miriam Esteban, Ari 543 Keranen, Mika Kousa, Pekka Nikander, and Hannes Tschofenig. 545 Ari Keranen suggested inclusion of the text specifying requester 546 authorization based on certificates as a direct adaption of text 547 found in HIP native NAT traversal specification 548 [I-D.ietf-hip-native-nat-traversal]. 550 10. References 552 10.1. Normative References 554 [I-D.ietf-hip-rfc5201-bis] 555 Moskowitz, R., Heer, T., Jokela, P., and T. Henderson, 556 "Host Identity Protocol Version 2 (HIPv2)", draft-ietf- 557 hip-rfc5201-bis-16 (work in progress), August 2014. 559 [I-D.ietf-hip-rfc5204-bis] 560 Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 561 Rendezvous Extension", draft-ietf-hip-rfc5204-bis-04 (work 562 in progress), June 2014. 564 [I-D.ietf-hip-rfc6253-bis] 565 Heer, T. and S. Varjonen, "Host Identity Protocol 566 Certificates", draft-ietf-hip-rfc6253-bis-01 (work in 567 progress), October 2013. 569 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 570 Requirement Levels", BCP 14, RFC 2119, March 1997. 572 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 573 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 574 May 2008. 576 10.2. Informative References 578 [I-D.ietf-hip-native-nat-traversal] 579 Keranen, A. and J. Melen, "Native NAT Traversal Mode for 580 the Host Identity Protocol", draft-ietf-hip-native-nat- 581 traversal-07 (work in progress), June 2014. 583 [I-D.ietf-hip-rfc4423-bis] 584 Moskowitz, R. and M. Komu, "Host Identity Protocol 585 Architecture", draft-ietf-hip-rfc4423-bis-08 (work in 586 progress), April 2014. 588 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 589 Issues", RFC 3234, February 2002. 591 [RFC5203] Laganier, J., Koponen, T., and L. Eggert, "Host Identity 592 Protocol (HIP) Registration Extension", RFC 5203, April 593 2008. 595 Appendix A. Changes from RFC 5203 597 o Updated references to revised HIP specifications. 599 o Added a new registration failure type for use in case of 600 insufficient resources available at the HIP registrar. 602 o Added requester authorization based on certificates, and new 603 registration failure type for invalid certificate. 605 Authors' Addresses 607 Julien Laganier 608 Luminate Wireless, Inc. 609 Cupertino, CA 610 USA 612 EMail: julien.ietf@gmail.com 614 Lars Eggert 615 NetApp 616 Sonnenallee 1 617 Kirchheim 85551 618 Germany 620 Phone: +49 151 12055791 621 EMail: lars@netapp.com 622 URI: http://eggert.org