idnits 2.17.1 draft-ietf-hip-rfc5203-bis-07.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 (April 18, 2015) is 3294 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 537, but not defined == Missing Reference: 'TBD-IANA-Insufficient-resources' is mentioned on line 425, but not defined == Missing Reference: 'TBD-IANA-Invalid-Certificates' is mentioned on line 430, but not defined == Outdated reference: A later version (-08) exists of draft-ietf-hip-rfc5204-bis-05 == 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-08 == Outdated reference: A later version (-20) exists of draft-ietf-hip-rfc4423-bis-11 -- Obsolete informational reference (is this intentional?): RFC 5203 (Obsoleted by RFC 8003) Summary: 1 error (**), 0 flaws (~~), 8 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: October 20, 2015 April 18, 2015 8 Host Identity Protocol (HIP) Registration Extension 9 draft-ietf-hip-rfc5203-bis-07 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 October 20, 2015. 35 Copyright Notice 37 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . 11 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 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 75 1. Introduction 77 This document specifies an extension to the Host Identity Protocol 78 (HIP) [I-D.ietf-hip-rfc5201-bis]. The extension provides a generic 79 means for a host to register with a service. The service may, for 80 example, be a HIP rendezvous server [I-D.ietf-hip-rfc5204-bis] or a 81 middlebox [RFC3234]. 83 This document makes no further assumptions about the exact type of 84 service. Likewise, this document does not specify any mechanisms to 85 discover the presence of specific services or means to interact with 86 them after registration. Future documents may describe those 87 operations. 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in RFC 2119 [RFC2119]. 93 2. Terminology 95 In addition to the terminology defined in the HIP Architecture 96 [I-D.ietf-hip-rfc4423-bis], the HIP specification 97 [I-D.ietf-hip-rfc5201-bis], and the HIP Rendezvous Extension 99 [I-D.ietf-hip-rfc5204-bis], this document defines and uses the 100 following terms: 102 Requester: 103 a HIP node registering with a HIP registrar to request 104 registration for a service. 106 Registrar: 107 a HIP node offering registration for one or more services. 109 Service: 110 a facility that provides requesters with new capabilities or 111 functionalities operating at the HIP layer. Examples include 112 firewalls that support HIP traversal or HIP rendezvous servers. 114 Registration: 115 shared state stored by a requester and a registrar, allowing the 116 requester to benefit from one or more HIP services offered by the 117 registrar. Each registration has an associated finite lifetime. 118 Requesters can extend established registrations through re- 119 registration (i.e., perform a refresh). 121 Registration Type: 122 an identifier for a given service in the registration protocol. 123 For example, the rendezvous service is identified by a specific 124 registration type. 126 3. HIP Registration Extension Overview 128 This document does not specify the means by which a requester 129 discovers the availability of a service, or how a requester locates a 130 registrar. After a requester has discovered a registrar, it either 131 initiates HIP base exchange or uses an existing HIP association with 132 the registrar. In both cases, registrars use additional parameters, 133 which the remainder of this document defines, to announce their 134 quality and grant or refuse registration. Requesters use 135 corresponding parameters to register with the service. Both the 136 registrar and the requester MAY also include in the messages 137 exchanged additional HIP parameters specific to the registration type 138 implicated. Other documents will define parameters and how they 139 shall be used. The following sections describe the differences 140 between this registration handshake and the standard HIP base 141 exchange [I-D.ietf-hip-rfc5201-bis]. 143 3.1. Registrar Announcing Its Ability 145 A host that is capable and willing to act as a registrar SHOULD 146 include a REG_INFO parameter in the R1 packets it sends during all 147 base exchanges. If it is currently unable to provide services due to 148 transient conditions, it SHOULD include an empty REG_INFO, i.e., one 149 with no services listed. If services can be provided later, it 150 SHOULD send UPDATE packets indicating the current set of services 151 available in a new REG_INFO parameter to all hosts it is associated 152 with. 154 3.2. Requester Requesting Registration 156 To request registration with a service, a requester constructs and 157 includes a corresponding REG_REQUEST parameter in an I2 or UPDATE 158 packet it sends to the registrar. 160 If the requester has no HIP association established with the 161 registrar, it SHOULD send the REG_REQUEST at the earliest 162 possibility, i.e., in the I2 packet. This minimizes the number of 163 packets that need to be exchanged with the registrar. A registrar 164 MAY end a HIP association that does not carry a REG_REQUEST by 165 including a NOTIFY with the type REG_REQUIRED in the R2. In this 166 case, no HIP association is created between the hosts. The 167 REG_REQUIRED notification error type is 51. 169 3.3. Registrar Granting or Refusing Service(s) Registration 171 Once registration has been requested, the registrar is able to 172 authenticate the requester based on the host identity included in I2. 174 If the registrar knows the Host Identities (HIs) of all the hosts 175 that are allowed to register for service(s), it SHOULD reject 176 registrations from unknown hosts. However, since it may be 177 unfeasible to pre-configure the registrar with all the HIs, the 178 registrar SHOULD also support HIP certificates 179 [I-D.ietf-hip-rfc6253-bis] to allow for certificate based 180 authentication. 182 When a requester wants to register with a registrar, it SHOULD check 183 if it has a suitable certificate for authenticating with the 184 registrar. How the suitability is determined and how the 185 certificates are obtained is out of scope for this document. If the 186 requester has one or more suitable certificates, the host SHOULD 187 include them (or just the most suitable one) in a CERT parameter to 188 the HIP packet along with the REG_REQUEST parameter. If the 189 requester does not have any suitable certificates, it SHOULD send the 190 registration request without the CERT parameter to test whether the 191 registrar accepts the request based on the host's identity. 193 When a registrar receives a HIP packet with a REG_REQUEST parameter, 194 and it requires authentication for at least one of the Registration 195 Types listed in the REG_REQUEST parameter, it MUST first check 196 whether the HI of the requester is in the allowed list for all the 197 Registration Types in the REG_REQUEST parameter. If the requester is 198 in the allowed list (or the registrar does not require any 199 authentication), the registrar MUST proceed with the registration. 201 If the requester was not in the allowed list and the registrar 202 requires the requester to authenticate, the registrar MUST check 203 whether the packet also contains a CERT parameter. If the packet 204 does not contain a CERT parameter, the registrar MUST reject the 205 registrations requiring authentication with Failure Type 0 206 (Registration requires additional credentials). If the certificate 207 is valid and accepted (issued for the requester and signed by a 208 trusted issuer), the registrar MUST proceed with the registration. 209 If the certificate in the parameter is not accepted, the registrar 210 MUST reject the corresponding registrations with Failure Type [IANA 211 TBD] (Invalid certificate). 213 After successful authorization, the registrar includes a REG_RESPONSE 214 parameter in its response, which contains the service type(s) for 215 which it has authorized registration, and zero or more REG_FAILED 216 parameters containing the service type(s) for which it has not 217 authorized registration or registration has failed for other reasons. 218 This response can be either an R2 or an UPDATE message, respectively, 219 depending on whether the registration was requested during the base 220 exchange, or using an existing association. In particular, 221 REG_FAILED with a failure type of zero indicates the service(s) 222 type(s) that require further credentials for registration. 224 If the registrar requires further authorization and the requester has 225 additional credentials available, the requester SHOULD try to 226 register again with the service after the HIP association has been 227 established. 229 Successful processing of a REG_RESPONSE parameter creates 230 registration state at the requester. In a similar manner, successful 231 processing of a REG_REQUEST parameter creates registration state at 232 the registrar and possibly at the service. Both the requester and 233 registrar can cancel a registration before it expires, if the 234 services afforded by a registration are no longer needed by the 235 requester, or cannot be provided any longer by the registrar (for 236 instance, because its configuration has changed). 238 +-----+ I1 +-----+-----+ 239 | |--------------------->| | S1 | 240 | |<---------------------| | | 241 | | R1(REG_INFO:S1,S2,S3)| +-----+ 242 | RQ | | R | S2 | 243 | | I2(REG_REQ:S1) | | | 244 | |--------------------->| +-----+ 245 | |<---------------------| | S3 | 246 | | R2(REG_RESP:S1) | | | 247 +-----+ +-----+-----+ 249 A requester (RQ) registers for service (S1) with a registrar (R) of 250 services (S1), (S2), and (S3), with which it has no current HIP 251 association. 253 +-----+ +-----+-----+ 254 | | UPDATE(REG_INFO:S) | | | 255 | |<---------------------| | | 256 | RQ |--------------------->| R | S | 257 | | UPDATE(REG_REQ:S) | | | 258 | | UPDATE(REG_RESP:S) | | | 259 | |<---------------------| | | 260 +-----+ +-----+-----+ 262 A requester (RQ) registers for service (S) with a registrar (R) of 263 services (S), with which it currently has a HIP association 264 established. 266 4. Parameter Formats and Processing 268 This section describes the format and processing of the new 269 parameters introduced by the HIP registration extension. 271 4.1. Encoding Registration Lifetimes with Exponents 273 The HIP registration uses an exponential encoding of registration 274 lifetimes. This allows compact encoding of 255 different lifetime 275 values ranging from 4 ms to 178 days into an 8-bit integer field. 276 The lifetime exponent field used throughout this document MUST be 277 interpreted as representing the lifetime value 2^((lifetime - 64)/8) 278 seconds. 280 4.2. REG_INFO 281 0 1 2 3 282 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 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Type | Length | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Min Lifetime | Max Lifetime | Reg Type #1 | Reg Type #2 | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | ... | ... | Reg Type #n | | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding + 290 | | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 Type 930 294 Length Length in octets, excluding Type, Length, and Padding. 295 Min Lifetime Minimum registration lifetime. 296 Max Lifetime Maximum registration lifetime. 297 Reg Type The registration types offered by the registrar. 299 Other documents will define specific values for registration types. 300 See Section 7 for more information. 302 Registrars include the parameter in R1 packets in order to announce 303 their registration capabilities. The registrar SHOULD include the 304 parameter in UPDATE packets when its service offering has changed. 305 HIP_SIGNATURE_2 protects the parameter within the R1 packets. 307 4.3. REG_REQUEST 309 0 1 2 3 310 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 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Type | Length | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | Lifetime | Reg Type #1 | Reg Type #2 | Reg Type #3 | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | ... | ... | Reg Type #n | | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding + 318 | | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 Type 932 322 Length Length in octets, excluding Type, Length, and Padding. 323 Lifetime Requested registration lifetime. 324 Reg Type The preferred registration types in order of preference. 326 Other documents will define specific values for registration types. 327 See Section 7 for more information. 329 A requester includes the REG_REQUEST parameter in I2 or UPDATE 330 packets to register with a registrar's service(s). If the 331 REG_REQUEST parameter is in an UPDATE packet, the registrar MUST NOT 332 modify the registrations of registration types that are not listed in 333 the parameter. Moreover, the requester MUST NOT include the 334 parameter unless the registrar's R1 packet or latest received UPDATE 335 packet has contained a REG_INFO parameter with the requested 336 registration types. 338 The requester MUST NOT include more than one REG_REQUEST parameter in 339 its I2 or UPDATE packets, while the registrar MUST be able to process 340 one or more REG_REQUEST parameters in received I2 or UPDATE packets. 342 When the registrar receives a registration with a lifetime that is 343 either smaller or greater than the minimum or maximum lifetime, 344 respectively, then it SHOULD grant the registration for the minimum 345 or maximum lifetime, respectively. 347 HIP_SIGNATURE protects the parameter within the I2 and UPDATE 348 packets. 350 4.4. REG_RESPONSE 352 0 1 2 3 353 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 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Type | Length | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Lifetime | Reg Type #1 | Reg Type #2 | Reg Type #3 | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | ... | ... | Reg Type #n | | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding + 361 | | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 Type 934 365 Length Length in octets, excluding Type, Length, and Padding. 366 Lifetime Granted registration lifetime. 367 Reg Type The granted registration types in order of preference. 369 Other documents will define specific values for registration types. 370 See Section 7 for more information. 372 The registrar SHOULD includes an REG_RESPONSE parameter in its R2 or 373 UPDATE packet only if a registration has successfully completed. 375 The registrar MUST NOT include more than one REG_RESPONSE parameter 376 in its R2 or UPDATE packets, while the requester MUST be able to 377 process one or more REG_RESPONSE parameters in received R2 or UPDATE 378 packets. 380 The requester MUST be prepared to receive any registration lifetime, 381 including ones beyond the minimum and maximum lifetime indicated in 382 the REG_INFO parameter. It MUST NOT expect that the returned 383 lifetime will be the requested one, even when the requested lifetime 384 falls within the announced minimum and maximum. 386 HIP_SIGNATURE protects the parameter within the R2 and UPDATE 387 packets. 389 4.5. REG_FAILED 391 0 1 2 3 392 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 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Type | Length | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Failure Type | Reg Type #1 | Reg Type #2 | Reg Type #3 | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | ... | ... | Reg Type #n | | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding + 400 | | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 Type 936 404 Length Length in octets, excluding Type, Length, and Padding. 405 Failure Type Reason for failure. 406 Reg Type The registration types that failed with the specified 407 reason. 409 Failure Type Reason 410 ------------ -------------------------------------------- 411 0 Registration requires additional credentials 412 1 Registration type unavailable 413 [TBD-IANA] Insufficient resources 414 [TBD-IANA] Invalid certificate 415 [TBD-IANA]-200 Unassigned 416 201-255 Reserved by IANA for private use 418 Other documents will define specific values for registration types. 419 See Section 7 for more information. 421 Failure type zero (0) indicates that the registrar requires 422 additional credentials to authorize a requester to register with the 423 registration types listed in the parameter. Failure type one (1) 424 indicates that the requested service type is unavailable at the 425 registrar. Failure type ([TBD-IANA-Insufficient-resources]) 426 indicates that the registrar does not currently have enough resources 427 to register the requester for the service(s); when that is the case 428 the requester MUST NOT reattempt immediately to register for the same 429 service(s), and MAY attempt to contact another registrar to register 430 for these service(s). Failure type ([TBD-IANA-Invalid-Certificates]) 431 indicates that the registrar could not validate the certificate 432 provided by the requester to register for the service(s); when that 433 is the case the requester MUST NOT reattempt to register for the same 434 set of services while providing the same certificate, and MAY attempt 435 to register for the same set of service(s) with a different 436 certificate, or with a different set of service(s) with the same 437 certificate. 439 The registrar SHOULD include a REG_FAILED parameter in its R2 or 440 UPDATE packet, if registration with the registration types listed has 441 not completed successfully and a requester is asked to try again with 442 additional credentials. 444 HIP_SIGNATURE protects the parameter within the R2 and UPDATE 445 packets. 447 5. Establishing and Maintaining Registrations 449 Establishing and/or maintaining a registration may require additional 450 information not available in the transmitted REG_REQUEST or 451 REG_RESPONSE parameters. Therefore, registration type definitions 452 MAY define dependencies for HIP parameters that are not defined in 453 this document. Their semantics are subject to the specific 454 registration type specifications. 456 The minimum lifetime both registrars and requesters MUST support is 457 10 seconds, while they SHOULD support a maximum lifetime of 120 458 seconds, at least. These values define a baseline for the 459 specification of services based on the registration system. They 460 were chosen to be neither too short nor too long, and to accommodate 461 for existing timeouts of state established in middleboxes (e.g., NATs 462 and firewalls.) 464 A zero lifetime is reserved for canceling purposes. Requesting a 465 zero lifetime for a registration type is equal to canceling the 466 registration of that type. A requester MAY cancel a registration 467 before it expires by sending a REG_REQ to the registrar with a zero 468 lifetime. A registrar SHOULD respond and grant a registration with a 469 zero lifetime. A registrar (and an attached service) MAY cancel a 470 registration before it expires, at its own discretion. However, if 471 it does so, it SHOULD send a REG_RESPONSE with a zero lifetime to all 472 registered requesters. 474 6. Security Considerations 476 This section discusses the threats on the HIP registration protocol, 477 and their implications on the overall security of HIP. In 478 particular, it argues that the extensions described in this document 479 do not introduce additional threats to HIP. 481 The extensions described in this document rely on the HIP base 482 exchange and do not modify its security characteristics, e.g., 483 digital signatures or HMAC. Hence, the only threat introduced by 484 these extensions is related to the creation of soft registration 485 state at the registrar. 487 Registrars act on a voluntary basis and are willing to accept being a 488 responder and then to create HIP associations with a number of 489 potentially unknown hosts. Because they have to store HIP 490 association state anyway, adding a certain amount of time-limited HIP 491 registration state should not introduce any serious additional 492 threats, especially because HIP registrars may cancel registrations 493 at any time at their own discretion, e.g., because of resource 494 constraints during an attack. 496 7. IANA Considerations 498 This section is to be interpreted according to the Guidelines for 499 Writing an IANA Considerations Section in RFCs [RFC5226]. 501 This document updates the IANA Registry for HIP Parameter Types by 502 assigning new HIP Parameter Types values for the new HIP Parameters 503 defined in this document: 505 o REG_INFO (defined in Section 4.2) 507 o REG_REQUEST (defined in Section 4.3) 509 o REG_RESPONSE (defined in Section 4.4) 511 o REG_FAILED (defined in Section 4.5) 513 IANA has allocated the Notify Message Type code 51 for the 514 REG_REQUIRED notification error type in the Notify Message Type 515 registry. 517 IANA has opened a new registry for registration types. This document 518 does not define registration types but makes the following 519 reservations: 521 Reg Type Service 522 -------- ------- 523 0-200 Unassigned 524 201-255 Reserved by IANA for private use 526 Adding a new type requires new IETF specifications. 528 IANA has opened a new registry for registration failure types. This 529 document makes the following failure type definitions and 530 reservations: 532 Failure Type Reason 533 ------------ -------------------------------------------- 534 0 Registration requires additional credentials 535 1 Registration type unavailable 536 [TBD-IANA] Insufficient resources 537 [TBD-IANA] Invalid certificate 538 [TBD-IANA]-200 Unassigned 539 201-255 Reserved by IANA for private use 541 Adding a new type requires new IETF specifications. 543 8. Contributors 545 Teemu Koponen co-authored an earlier, experimental version of this 546 specification [RFC5203]. 548 9. Acknowledgments 550 The following people (in alphabetical order) have provided thoughtful 551 and helpful discussions and/or suggestions that have helped to 552 improve this document: Jeffrey Ahrenholz, Miriam Esteban, Ari 553 Keranen, Mika Kousa, Pekka Nikander, and Hannes Tschofenig. 555 Ari Keranen suggested inclusion of the text specifying requester 556 authorization based on certificates as a direct adaption of text 557 found in HIP native NAT traversal specification 558 [I-D.ietf-hip-native-nat-traversal]. 560 10. References 562 10.1. Normative References 564 [I-D.ietf-hip-rfc5201-bis] 565 Moskowitz, R., Heer, T., Jokela, P., and T. Henderson, 566 "Host Identity Protocol Version 2 (HIPv2)", draft-ietf- 567 hip-rfc5201-bis-20 (work in progress), October 2014. 569 [I-D.ietf-hip-rfc5204-bis] 570 Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 571 Rendezvous Extension", draft-ietf-hip-rfc5204-bis-05 (work 572 in progress), December 2014. 574 [I-D.ietf-hip-rfc6253-bis] 575 Heer, T. and S. Varjonen, "Host Identity Protocol 576 Certificates", draft-ietf-hip-rfc6253-bis-01 (work in 577 progress), October 2013. 579 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 580 Requirement Levels", BCP 14, RFC 2119, March 1997. 582 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 583 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 584 May 2008. 586 10.2. Informative References 588 [I-D.ietf-hip-native-nat-traversal] 589 Keranen, A. and J. Melen, "Native NAT Traversal Mode for 590 the Host Identity Protocol", draft-ietf-hip-native-nat- 591 traversal-08 (work in progress), January 2015. 593 [I-D.ietf-hip-rfc4423-bis] 594 Moskowitz, R. and M. Komu, "Host Identity Protocol 595 Architecture", draft-ietf-hip-rfc4423-bis-11 (work in 596 progress), April 2015. 598 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 599 Issues", RFC 3234, February 2002. 601 [RFC5203] Laganier, J., Koponen, T., and L. Eggert, "Host Identity 602 Protocol (HIP) Registration Extension", RFC 5203, April 603 2008. 605 Appendix A. Changes from RFC 5203 607 o Updated references to revised HIP specifications. 609 o Added a new registration failure type for use in case of 610 insufficient resources available at the HIP registrar. 612 o Added requester authorization based on certificates, and new 613 registration failure type for invalid certificate. 615 Authors' Addresses 617 Julien Laganier 618 Luminate Wireless, Inc. 619 Cupertino, CA 620 USA 622 EMail: julien.ietf@gmail.com 624 Lars Eggert 625 NetApp 626 Sonnenallee 1 627 Kirchheim 85551 628 Germany 630 Phone: +49 151 12055791 631 EMail: lars@netapp.com 632 URI: http://eggert.org