idnits 2.17.1 draft-ietf-hip-rfc5203-bis-11.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 (August 4, 2016) is 2822 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: 'IANA TBD' is mentioned on line 226, but not defined == Missing Reference: 'TBD-IANA' is mentioned on line 589, but not defined == Missing Reference: 'TBD-IANA-Insufficient-resources' is mentioned on line 458, but not defined == Missing Reference: 'TBD-IANA-Invalid-Certificates' is mentioned on line 463, but not defined == Outdated reference: A later version (-08) exists of draft-ietf-hip-rfc5204-bis-07 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-33) exists of draft-ietf-hip-native-nat-traversal-13 == Outdated reference: A later version (-20) exists of draft-ietf-hip-rfc4423-bis-14 -- 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: February 5, 2017 August 4, 2016 8 Host Identity Protocol (HIP) Registration Extension 9 draft-ietf-hip-rfc5203-bis-11 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 February 5, 2017. 35 Copyright Notice 37 Copyright (c) 2016 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 . . . . . 7 60 4.2. REG_INFO . . . . . . . . . . . . . . . . . . . . . . . . 7 61 4.3. REG_REQUEST . . . . . . . . . . . . . . . . . . . . . . . 8 62 4.4. REG_RESPONSE . . . . . . . . . . . . . . . . . . . . . . 9 63 4.5. REG_FAILED . . . . . . . . . . . . . . . . . . . . . . . 9 64 5. Establishing and Maintaining Registrations . . . . . . . . . 11 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 67 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 68 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 69 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 71 10.2. Informative References . . . . . . . . . . . . . . . . . 14 72 Appendix A. Changes from RFC 5203 . . . . . . . . . . . . . . . 16 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 75 1. Introduction 77 This document specifies an extension to the Host Identity Protocol 78 (HIP) [RFC7401]. The extension provides a generic means for a host 79 to register with a service. The service may, for example, be a HIP 80 rendezvous server [I-D.ietf-hip-rfc5204-bis] or a middlebox 81 [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 [RFC7401], and the 97 HIP Rendezvous Extension [I-D.ietf-hip-rfc5204-bis], this document 98 defines and uses the following terms: 100 Requester: 101 a HIP node registering with a HIP registrar to request 102 registration for a service. 104 Registrar: 105 a HIP node offering registration for one or more services. 107 Service: 108 a facility that provides requesters with new capabilities or 109 functionalities operating at the HIP layer. Examples include 110 firewalls that support HIP traversal or HIP rendezvous servers. 112 Registration: 113 shared state stored by a requester and a registrar, allowing the 114 requester to benefit from one or more HIP services offered by the 115 registrar. Each registration has an associated finite lifetime. 116 Requesters can extend established registrations through re- 117 registration (i.e., perform a refresh). 119 Registration Type: 120 an 8-bit identifier for a given service in the registration 121 protocol. For example, the rendezvous service is identified by a 122 specific registration type. 124 3. HIP Registration Extension Overview 126 This document does not specify the means by which a requester 127 discovers the availability of a service, or how a requester locates a 128 registrar. After a requester has discovered a registrar, it either 129 initiates HIP base exchange or uses an existing HIP association with 130 the registrar. In both cases, registrars use additional parameters, 131 which the remainder of this document defines, to announce their 132 quality and grant or refuse registration. Requesters use 133 corresponding parameters to register with the service. Both the 134 registrar and the requester MAY also include in the messages 135 exchanged additional HIP parameters specific to the registration type 136 requested. Other documents will define parameters and how they shall 137 be used. 139 The HIP base exchange, including the definition of the HIP I1, R1, 140 I2, and R2 packets, is defined in RFC7401 [RFC7401]. The following 141 sections describe the differences between this registration handshake 142 and the standard HIP base exchange [RFC7401]. 144 3.1. Registrar Announcing Its Ability 146 A host that is capable and willing to act as a registrar vis-a-vis a 147 specific requester SHOULD include a REG_INFO parameter in the R1 148 packets it sends during all base exchanges with that requester. If 149 it is currently unable to provide services due to transient 150 conditions, it SHOULD include an empty REG_INFO, i.e., one with no 151 services listed. If services can be provided later, it SHOULD send 152 UPDATE packets indicating the current set of services available in a 153 new REG_INFO parameter to all hosts it is associated with. 155 3.2. Requester Requesting Registration 157 To request registration with a service, a requester constructs and 158 includes a corresponding REG_REQUEST parameter in an I2 or UPDATE 159 packet it sends to the registrar. 161 If the requester has no HIP association established with the 162 registrar, it SHOULD send the REG_REQUEST at the earliest 163 possibility, i.e., in the I2 packet. This minimizes the number of 164 packets that need to be exchanged with the registrar. A registrar 165 MAY end a HIP association that does not carry a REG_REQUEST by 166 including a NOTIFY with the type REG_REQUIRED in the R2. In this 167 case, no HIP association is created between the hosts. The 168 REG_REQUIRED notification error type is 51. 170 3.3. Registrar Granting or Refusing Service(s) Registration 172 Once registration has been requested, the registrar is able to 173 authenticate the requester based on the host identity included in I2. 175 If the registrar knows the Host Identities (HIs) of all the hosts 176 that are allowed to register for service(s), it SHOULD reject 177 registrations from unknown hosts. However, since it may be 178 infeasible to pre-configure the registrar with all the HIs, the 179 registrar SHOULD also support HIP certificates 180 [I-D.ietf-hip-rfc6253-bis] to allow for certificate based 181 authentication. 183 When a requester wants to register with a registrar, it SHOULD check 184 if it has a suitable certificate for authenticating with the 185 registrar. How the suitability is determined and how the 186 certificates are obtained is out of scope for this document. If the 187 requester has one or more suitable certificates, the host SHOULD 188 include them (or just the most suitable one) in a CERT parameter to 189 the HIP packet along with the REG_REQUEST parameter. If the 190 requester does not have any suitable certificates, it SHOULD send the 191 registration request without the CERT parameter to test whether the 192 registrar accepts the request based on the host's identity. 194 When a registrar receives a HIP packet with a REG_REQUEST parameter, 195 and it requires authentication for at least one of the Registration 196 Types listed in the REG_REQUEST parameter, it MUST first check 197 whether the HI of the requester is in the allowed list for all the 198 Registration Types in the REG_REQUEST parameter. If the requester is 199 in the allowed list (or the registrar does not require any 200 authentication), the registrar MUST proceed with the registration. 202 If the requester was not in the allowed list and the registrar 203 requires the requester to authenticate, the registrar MUST check 204 whether the packet also contains a CERT parameter. If the packet 205 does not contain a CERT parameter, the registrar MUST reject the 206 registrations requiring authentication with Failure Type 0 207 (Registration requires additional credentials). If the certificate 208 is valid and accepted (issued for the requester and signed by a 209 trusted issuer), the registrar MUST proceed with the registration. 210 If the certificate in the parameter is not accepted, the registrar 211 MUST reject the corresponding registrations with the appropriate 212 Failure Type: 214 [IANA TBD] (Bad certificate): The certificate is corrupt, contains 215 invalid signatures, etc. 217 [IANA TBD] (Unsupported certificate): The certificate is of an 218 unsupported type. 220 [IANA TBD] (Certificate expired): The certificate is no longer 221 valid. 223 [IANA TBD] (Certificate other): The certificate could not be 224 validated for some unspecified reason. 226 [IANA TBD] (Unknown CA): The issuing CA certificate could not be 227 located or is not trusted. 229 After successful authorization, the registrar includes a REG_RESPONSE 230 parameter in its response, which contains the service type(s) for 231 which it has authorized registration, and zero or more REG_FAILED 232 parameters containing the service type(s) for which it has not 233 authorized registration or registration has failed for other reasons. 234 This response can be either an R2 or an UPDATE message, respectively, 235 depending on whether the registration was requested during the base 236 exchange, or using an existing association. In particular, 237 REG_FAILED with a failure type of zero indicates the service(s) 238 type(s) that require further credentials for registration. 240 If the registrar requires further authorization and the requester has 241 additional credentials available, the requester SHOULD try to 242 register again with the service after the HIP association has been 243 established. 245 Successful processing of a REG_RESPONSE parameter creates 246 registration state at the requester. In a similar manner, successful 247 processing of a REG_REQUEST parameter creates registration state at 248 the registrar and possibly at the service. Both the requester and 249 registrar can cancel a registration before it expires, if the 250 services afforded by a registration are no longer needed by the 251 requester, or cannot be provided any longer by the registrar (for 252 instance, because its configuration has changed). 254 +-----+ I1 +-----+-----+ 255 | |--------------------->| | S1 | 256 | |<---------------------| | | 257 | | R1(REG_INFO:S1,S2,S3)| +-----+ 258 | RQ | | R | S2 | 259 | | I2(REG_REQ:S1) | | | 260 | |--------------------->| +-----+ 261 | |<---------------------| | S3 | 262 | | R2(REG_RESP:S1) | | | 263 +-----+ +-----+-----+ 265 A requester (RQ) registers for service (S1) with a registrar (R) of 266 services (S1), (S2), and (S3), with which it has no current HIP 267 association. 269 +-----+ +-----+-----+ 270 | | UPDATE(REG_INFO:S) | | | 271 | |<---------------------| | | 272 | RQ |--------------------->| R | S | 273 | | UPDATE(REG_REQ:S) | | | 274 | | UPDATE(REG_RESP:S) | | | 275 | |<---------------------| | | 276 +-----+ +-----+-----+ 278 A requester (RQ) registers for service (S) with a registrar (R) of 279 services (S), with which it currently has a HIP association 280 established. 282 4. Parameter Formats and Processing 284 This section describes the format and processing of the new 285 parameters introduced by the HIP registration extension. The 286 encoding of these new parameters is conforms to the HIPv2 TLV format 287 described in section 5.2.1 of RFC7401 [RFC7401]. 289 4.1. Encoding Registration Lifetimes with Exponents 291 The HIP registration uses an exponential encoding of registration 292 lifetimes. 294 The special value 0 (zero) of the lifetime field MUST be interpreted 295 as representing a special lifetime duration of 0 (zero) seconds, and 296 is used to request and grant cancellation of a registration. 298 The non-zero values of the lifetime field used throughout this 299 document MUST be interpreted as an exponent value representing a 300 lifetime duration of 2^((lifetime - 64)/8) seconds. 302 This allows a compact encoding of 255 different lifetime durations 303 (in addition to the special lifetime duration of zero seconds) 304 ranging from 2^(63/8) seconds (i.e., ~4 ms) to 2^(191/8) seconds 305 (i.e., ~178 days) into an 8-bit integer field. 307 4.2. REG_INFO 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 | Min Lifetime | Max Lifetime | Reg Type #1 | Reg Type #2 | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | ... | ... | Reg Type #n | | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding + 318 | | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 Type 930 322 Length Length in octets, excluding Type, Length, and Padding. 323 Min Lifetime Minimum registration lifetime. 324 Max Lifetime Maximum registration lifetime. 325 Reg Type The registration types offered by the registrar. 327 Other documents will define specific values for registration types. 328 See Section 7 for more information. 330 Registrars include the parameter in R1 packets in order to announce 331 their registration capabilities. The registrar SHOULD include the 332 parameter in UPDATE packets when its service offering has changed. 333 HIP_SIGNATURE_2 protects the parameter within the R1 packets. 335 The registrar indicates the minimum and maximum registration lifetime 336 that it is willing to offer to a requester. A requester SHOULD NOT 337 request registration with lifetime greater than the maximum 338 registration lifetime or smaller than the minimum registration 339 lifetime. 341 4.3. REG_REQUEST 343 0 1 2 3 344 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 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Type | Length | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | Lifetime | Reg Type #1 | Reg Type #2 | Reg Type #3 | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | ... | ... | Reg Type #n | | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding + 352 | | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 Type 932 356 Length Length in octets, excluding Type, Length, and Padding. 357 Lifetime Requested registration lifetime. 358 Reg Type The preferred registration types in order of preference. 360 Other documents will define specific values for registration types. 361 See Section 7 for more information. 363 A requester includes the REG_REQUEST parameter in I2 or UPDATE 364 packets to register with a registrar's service(s). If the 365 REG_REQUEST parameter is in an UPDATE packet, the registrar MUST NOT 366 modify the registrations of registration types that are not listed in 367 the parameter. Moreover, the requester MUST NOT include the 368 parameter unless the registrar's R1 packet or latest received UPDATE 369 packet has contained a REG_INFO parameter with the requested 370 registration types. 372 The requester MUST NOT include more than one REG_REQUEST parameter in 373 its I2 or UPDATE packets, while the registrar MUST be able to process 374 one or more REG_REQUEST parameters in received I2 or UPDATE packets. 376 When the registrar receives a registration with a lifetime that is 377 either smaller or greater than the minimum or maximum lifetime, 378 respectively, then it SHOULD grant the registration for the minimum 379 or maximum lifetime, respectively. 381 HIP_SIGNATURE protects the parameter within the I2 and UPDATE 382 packets. 384 4.4. REG_RESPONSE 386 0 1 2 3 387 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 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Type | Length | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Lifetime | Reg Type #1 | Reg Type #2 | Reg Type #3 | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | ... | ... | Reg Type #n | | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding + 395 | | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 Type 934 399 Length Length in octets, excluding Type, Length, and Padding. 400 Lifetime Granted registration lifetime. 401 Reg Type The granted registration types in order of preference. 403 Other documents will define specific values for registration types. 404 See Section 7 for more information. 406 The registrar SHOULD includes an REG_RESPONSE parameter in its R2 or 407 UPDATE packet only if a registration has successfully completed. 409 The registrar MUST NOT include more than one REG_RESPONSE parameter 410 in its R2 or UPDATE packets, while the requester MUST be able to 411 process one or more REG_RESPONSE parameters in received R2 or UPDATE 412 packets. 414 The requester MUST be prepared to receive any registration lifetime, 415 including ones beyond the minimum and maximum lifetime indicated in 416 the REG_INFO parameter. It MUST NOT expect that the returned 417 lifetime will be the requested one, even when the requested lifetime 418 falls within the announced minimum and maximum. 420 HIP_SIGNATURE protects the parameter within the R2 and UPDATE 421 packets. 423 4.5. REG_FAILED 424 0 1 2 3 425 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 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | Type | Length | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | Failure Type | Reg Type #1 | Reg Type #2 | Reg Type #3 | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | ... | ... | Reg Type #n | | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding + 433 | | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 Type 936 437 Length Length in octets, excluding Type, Length, and Padding. 438 Failure Type Reason for failure. 439 Reg Type The registration types that failed with the specified 440 reason. 442 Failure Type Reason 443 ------------ -------------------------------------------- 444 0 Registration requires additional credentials 445 1 Registration type unavailable 446 [TBD-IANA] Insufficient resources 447 [TBD-IANA] Invalid certificate 448 [TBD-IANA]-200 Unassigned 449 201-255 Reserved by IANA for private use 451 Other documents will define specific values for registration types. 452 See Section 7 for more information. 454 Failure type zero (0) indicates that the registrar requires 455 additional credentials to authorize a requester to register with the 456 registration types listed in the parameter. Failure type one (1) 457 indicates that the requested service type is unavailable at the 458 registrar. Failure type ([TBD-IANA-Insufficient-resources]) 459 indicates that the registrar does not currently have enough resources 460 to register the requester for the service(s); when that is the case 461 the requester MUST NOT reattempt immediately to register for the same 462 service(s), and MAY attempt to contact another registrar to register 463 for these service(s). Failure type ([TBD-IANA-Invalid-Certificates]) 464 indicates that the registrar could not validate the certificate 465 provided by the requester to register for the service(s); when that 466 is the case the requester MUST NOT reattempt to register for the same 467 set of services while providing the same certificate, and MAY attempt 468 to register for the same set of service(s) with a different 469 certificate, or with a different set of service(s) with the same 470 certificate. 472 The registrar SHOULD include a REG_FAILED parameter in its R2 or 473 UPDATE packet, if registration with the registration types listed has 474 not completed successfully and a requester is asked to try again with 475 additional credentials. 477 HIP_SIGNATURE protects the parameter within the R2 and UPDATE 478 packets. 480 5. Establishing and Maintaining Registrations 482 Establishing and/or maintaining a registration may require additional 483 information not available in the transmitted REG_REQUEST or 484 REG_RESPONSE parameters. Therefore, registration type definitions 485 MAY define dependencies for HIP parameters that are not defined in 486 this document. Their semantics are subject to the specific 487 registration type specifications. 489 The minimum lifetime both registrars and requesters MUST support is 490 10 seconds, while they SHOULD support a maximum lifetime of 120 491 seconds, at least. These values define a baseline for the 492 specification of services based on the registration system. They 493 were chosen to be neither too short nor too long, and to accommodate 494 for existing timeouts of state established in middleboxes (e.g., NATs 495 and firewalls.) 497 A zero lifetime is reserved for canceling purposes. Requesting a 498 zero lifetime for a registration type is equal to canceling the 499 registration of that type. A requester MAY cancel a registration 500 before it expires by sending a REG_REQ to the registrar with a zero 501 lifetime. A registrar SHOULD respond and grant a registration with a 502 zero lifetime. A registrar (and an attached service) MAY cancel a 503 registration before it expires, at its own discretion. However, if 504 it does so, it SHOULD send a REG_RESPONSE with a zero lifetime to all 505 registered requesters. 507 6. Security Considerations 509 This section discusses the threats on the HIP registration protocol, 510 and their implications on the overall security of HIP. In 511 particular, it argues that the extensions described in this document 512 do not introduce additional threats to HIP. 514 The extensions described in this document rely on the HIP base 515 exchange and do not modify its security characteristics, e.g., 516 digital signatures or HMAC. Hence, the only threat introduced by 517 these extensions is related to the creation of soft registration 518 state at the registrar. 520 Registrars act on a voluntary basis and are willing to accept being a 521 responder and then to create HIP associations with a number of 522 potentially unknown hosts. Because they have to store HIP 523 association state anyway, adding a certain amount of time-limited HIP 524 registration state should not introduce any serious additional 525 threats, especially because HIP registrars may cancel registrations 526 at any time at their own discretion, e.g., because of resource 527 constraints during an attack. 529 7. IANA Considerations 531 This section is to be interpreted according to the Guidelines for 532 Writing an IANA Considerations Section in RFCs [RFC5226]. 534 [RFC5203], obsoleted by this document, made the following definitions 535 and reservations in the IANA Registry for HIP Parameters Types: 537 Value Parameter Type Length 538 ----- -------------- -------- 539 930 REG_INFO variable 540 932 REG_REQUEST variable 541 934 REG_RESPONSE variable 542 936 REG_FAILED variable 544 This document updates the IANA Registry for HIP Parameters Types by 545 replacing references to the obsoleted [RFC5203] by references to this 546 document. 548 [RFC5203], obsoleted by this document, requested the opening of an 549 IANA Registry for HIP Registration Types, defined no registration 550 types, but made the following reservations in the IANA Registry for 551 HIP Registration Types: 553 Reg Type Service 554 -------- -------------------------------- 555 201-255 Reserved by IANA for private use 557 Adding a new type requires new IETF specifications. 559 This document updates the IANA Registry for HIP Registration Types by 560 replacing references to the obsoleted [RFC5203] by references to this 561 document. 563 [RFC5203], obsoleted by this document, requested the opening of an 564 IANA Registry for HIP Registration Failure Types, and made the 565 following definitions and reservations in the IANA Registry for HIP 566 Registration Failure Types: 568 Failure Type Reason 569 ------------ -------------------------------------------- 570 0 Registration requires additional credentials 571 1 Registration type unavailable 572 201-255 Reserved by IANA for private use 574 Adding a new type requires new IETF specifications. 576 This document updates the IANA Registry for HIP Registration Failure 577 Types by replacing references to the obsoleted [RFC5203] by 578 references to this document, and making the following additional HIP 579 Registration Failure Types definition and reservation: 581 Failure Type Reason 582 ------------ -------------------------------------------- 583 [TBD-IANA] Insufficient resources 584 [TBD-IANA] Invalid certificate 585 [TBD-IANA] Bad certificate 586 [TBD-IANA] Unsupported certificate 587 [TBD-IANA] Certificate expired 588 [TBD-IANA] Certificate other 589 [TBD-IANA] Unknown CA 591 8. Contributors 593 Teemu Koponen co-authored an earlier, experimental version of this 594 specification [RFC5203]. 596 9. Acknowledgments 598 The following people (in alphabetical order) have provided thoughtful 599 and helpful discussions and/or suggestions that have helped to 600 improve this document: Jeffrey Ahrenholz, Miriam Esteban, Ari 601 Keranen, Mika Kousa, Pekka Nikander, and Hannes Tschofenig. 603 Lars Eggert has received funding from the European Union's Horizon 604 2020 research and innovation program 2014-2018 under grant agreement 605 No. 644866. This document reflects only the authors' views and the 606 European Commission is not responsible for any use that may be made 607 of the information it contains. 609 Ari Keranen suggested inclusion of the text specifying requester 610 authorization based on certificates as a direct adaption of text 611 found in HIP native NAT traversal specification 612 [I-D.ietf-hip-native-nat-traversal]. 614 Thanks to Joel M. Halpern for performing the Gen-ART review of this 615 document as part of the publication process. 617 10. References 619 10.1. Normative References 621 [I-D.ietf-hip-rfc5204-bis] 622 Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 623 Rendezvous Extension", draft-ietf-hip-rfc5204-bis-07 (work 624 in progress), December 2015. 626 [I-D.ietf-hip-rfc6253-bis] 627 Heer, T. and S. Varjonen, "Host Identity Protocol 628 Certificates", draft-ietf-hip-rfc6253-bis-09 (work in 629 progress), July 2016. 631 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 632 Requirement Levels", BCP 14, RFC 2119, 633 DOI 10.17487/RFC2119, March 1997, 634 . 636 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 637 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 638 DOI 10.17487/RFC5226, May 2008, 639 . 641 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 642 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 643 RFC 7401, DOI 10.17487/RFC7401, April 2015, 644 . 646 10.2. Informative References 648 [I-D.ietf-hip-native-nat-traversal] 649 Keranen, A., Melen, J., and M. Komu, "Native NAT Traversal 650 Mode for the Host Identity Protocol", draft-ietf-hip- 651 native-nat-traversal-13 (work in progress), July 2016. 653 [I-D.ietf-hip-rfc4423-bis] 654 Moskowitz, R. and M. Komu, "Host Identity Protocol 655 Architecture", draft-ietf-hip-rfc4423-bis-14 (work in 656 progress), June 2016. 658 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 659 Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, 660 . 662 [RFC5203] Laganier, J., Koponen, T., and L. Eggert, "Host Identity 663 Protocol (HIP) Registration Extension", RFC 5203, 664 DOI 10.17487/RFC5203, April 2008, 665 . 667 Appendix A. Changes from RFC 5203 669 o Updated references to revised HIP specifications. 671 o Added a new registration failure type for use in case of 672 insufficient resources available at the HIP registrar. 674 o Added requester authorization based on certificates, and new 675 registration failure types for invalid certificate. 677 Authors' Addresses 679 Julien Laganier 680 Luminate Wireless, Inc. 681 Cupertino, CA 682 USA 684 EMail: julien.ietf@gmail.com 686 Lars Eggert 687 NetApp 688 Sonnenallee 1 689 Kirchheim 85551 690 Germany 692 Phone: +49 151 12055791 693 EMail: lars@netapp.com 694 URI: http://eggert.org