idnits 2.17.1 draft-ietf-hip-rfc5203-bis-00.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC5203, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 20, 2010) is 4998 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) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 5201 (Obsoleted by RFC 7401) -- Obsolete informational reference (is this intentional?): RFC 4423 (Obsoleted by RFC 9063) -- Obsolete informational reference (is this intentional?): RFC 5204 (Obsoleted by RFC 8004) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Laganier 3 Internet-Draft QUALCOMM Inc. 4 Obsoletes: 5203 (if approved) T. Koponen 5 Intended status: Standards Track HIIT 6 Expires: February 21, 2011 L. Eggert 7 Nokia 8 August 20, 2010 10 Host Identity Protocol (HIP) Registration Extension 11 draft-ietf-hip-rfc5203-bis-00 13 Abstract 15 This document specifies a registration mechanism for the Host 16 Identity Protocol (HIP) that allows hosts to register with services, 17 such as HIP rendezvous servers or middleboxes. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on February 21, 2011. 36 Copyright Notice 38 Copyright (c) 2010 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 1. Introduction 53 This document specifies an extension to the Host Identity Protocol 54 (HIP) [RFC5201]. The extension provides a generic means for a host 55 to register with a service. The service may, for example, be a HIP 56 rendezvous server [RFC5204] or a middlebox [RFC3234]. 58 This document makes no further assumptions about the exact type of 59 service. Likewise, this document does not specify any mechanisms to 60 discover the presence of specific services or means to interact with 61 them after registration. Future documents may describe those 62 operations. 64 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 65 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 66 document are to be interpreted as described in RFC 2119 [RFC2119]. 68 2. Terminology 70 In addition to the terminology defined in the HIP Architecture 71 [RFC4423], the HIP specification [RFC5201], and the HIP Rendezvous 72 Extension [RFC5204], this document defines and uses the following 73 terms: 75 Requester: 76 a HIP node registering with a HIP registrar to request 77 registration for a service. 79 Registrar: 80 a HIP node offering registration for one or more services. 82 Service: 83 a facility that provides requesters with new capabilities or 84 functionalities operating at the HIP layer. Examples include 85 firewalls that support HIP traversal or HIP rendezvous servers. 87 Registration: 88 shared state stored by a requester and a registrar, allowing the 89 requester to benefit from one or more HIP services offered by the 90 registrar. Each registration has an associated finite lifetime. 91 Requesters can extend established registrations through re- 92 registration (i.e., perform a refresh). 94 Registration Type: 95 an identifier for a given service in the registration protocol. 96 For example, the rendezvous service is identified by a specific 97 registration type. 99 3. HIP Registration Extension Overview 101 This document does not specify the means by which a requester 102 discovers the availability of a service, or how a requester locates a 103 registrar. After a requester has discovered a registrar, it either 104 initiates HIP base exchange or uses an existing HIP association with 105 the registrar. In both cases, registrars use additional parameters, 106 which the remainder of this document defines, to announce their 107 quality and grant or refuse registration. Requesters use 108 corresponding parameters to register with the service. Both the 109 registrar and the requester MAY also include in the messages 110 exchanged additional HIP parameters specific to the registration type 111 implicated. Other documents will define parameters and how they 112 shall be used. The following sections describe the differences 113 between this registration handshake and the standard HIP base 114 exchange [RFC5201]. 116 3.1. Registrar Announcing Its Ability 118 A host that is capable and willing to act as a registrar SHOULD 119 include a REG_INFO parameter in the R1 packets it sends during all 120 base exchanges. If it is currently unable to provide services due to 121 transient conditions, it SHOULD include an empty REG_INFO, i.e., one 122 with no services listed. If services can be provided later, it 123 SHOULD send UPDATE packets indicating the current set of services 124 available in a new REG_INFO parameter to all hosts it is associated 125 with. 127 3.2. Requester Requesting Registration 129 To request registration with a service, a requester constructs and 130 includes a corresponding REG_REQUEST parameter in an I2 or UPDATE 131 packet it sends to the registrar. 133 If the requester has no HIP association established with the 134 registrar, it SHOULD send the REG_REQUEST at the earliest 135 possibility, i.e., in the I2 packet. This minimizes the number of 136 packets that need to be exchanged with the registrar. A registrar 137 MAY end a HIP association that does not carry a REG_REQUEST by 138 including a NOTIFY with the type REG_REQUIRED in the R2. In this 139 case, no HIP association is created between the hosts. The 140 REG_REQUIRED notification error type is 51. 142 3.3. Registrar Granting or Refusing Service(s) Registration 144 Once registration has been requested, the registrar is able to 145 authenticate the requester based on the host identity included in I2. 146 It then verifies that the host identity is authorized to register 147 with the requested service(s), based on local policies. The details 148 of this authorization procedure depend on the type of requested 149 service(s) and on the local policies of the registrar, and are 150 therefore not further specified in this document. 152 After authorization, the registrar includes a REG_RESPONSE parameter 153 in its response, which contains the service type(s) for which it has 154 authorized registration, and zero or more REG_FAILED parameters 155 containing the service type(s) for which it has not authorized 156 registration or registration has failed for other reasons. This 157 response can be either an R2 or an UPDATE message, respectively, 158 depending on whether the registration was requested during the base 159 exchange, or using an existing association. In particular, 160 REG_FAILED with a failure type of zero indicates the service(s) 161 type(s) that require further credentials for registration. 163 If the registrar requires further authorization and the requester has 164 additional credentials available, the requester SHOULD try to 165 register again with the service after the HIP association has been 166 established. The precise means of establishing and verifying 167 credentials are beyond the scope of this document and are expected to 168 be defined in other documents. 170 Successful processing of a REG_RESPONSE parameter creates 171 registration state at the requester. In a similar manner, successful 172 processing of a REG_REQUEST parameter creates registration state at 173 the registrar and possibly at the service. Both the requester and 174 registrar can cancel a registration before it expires, if the 175 services afforded by a registration are no longer needed by the 176 requester, or cannot be provided any longer by the registrar (for 177 instance, because its configuration has changed). 179 +-----+ I1 +-----+-----+ 180 | |--------------------->| | S1 | 181 | |<---------------------| | | 182 | | R1(REG_INFO:S1,S2) | +-----+ 183 | RQ | | R | S2 | 184 | | I2(REG_REQ:S1) | | | 185 | |--------------------->| +-----+ 186 | |<---------------------| | S3 | 187 | | R2(REG_RESP:S1) | | | 188 +-----+ +-----+-----+ 190 A requester (RQ) registers with a registrar (R) of services (S1) and 191 (S2), with which it has no current HIP association. 193 +-----+ +-----+-----+ 194 | | UPDATE(REG_INFO:S) | | | 195 | |<---------------------| | | 196 | RQ |--------------------->| R | S | 197 | | UPDATE(REG_REQ:S) | | | 198 | | UPDATE(REG_RESP:S) | | | 199 | |<---------------------| | | 200 +-----+ +-----+-----+ 202 A requester (RQ) registers with a registrar (R) of services (S), with 203 which it currently has a HIP association established. 205 4. Parameter Formats and Processing 207 This section describes the format and processing of the new 208 parameters introduced by the HIP registration extension. 210 4.1. Encoding Registration Lifetimes with Exponents 212 The HIP registration uses an exponential encoding of registration 213 lifetimes. This allows compact encoding of 255 different lifetime 214 values ranging from 4 ms to 178 days into an 8-bit integer field. 215 The lifetime exponent field used throughout this document MUST be 216 interpreted as representing the lifetime value 2^((lifetime - 64)/8) 217 seconds. 219 4.2. REG_INFO 221 0 1 2 3 222 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 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Type | Length | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Min Lifetime | Max Lifetime | Reg Type #1 | Reg Type #2 | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | ... | ... | Reg Type #n | | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding + 230 | | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 Type 930 234 Length Length in octets, excluding Type, Length, and Padding. 235 Min Lifetime Minimum registration lifetime. 236 Max Lifetime Maximum registration lifetime. 237 Reg Type The registration types offered by the registrar. 239 Other documents will define specific values for registration types. 240 See Section 7 for more information. 242 Registrars include the parameter in R1 packets in order to announce 243 their registration capabilities. The registrar SHOULD include the 244 parameter in UPDATE packets when its service offering has changed. 245 HIP_SIGNATURE_2 protects the parameter within the R1 packets. 247 4.3. REG_REQUEST 249 0 1 2 3 250 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 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Type | Length | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Lifetime | Reg Type #1 | Reg Type #2 | Reg Type #3 | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | ... | ... | Reg Type #n | | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding + 258 | | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 Type 932 262 Length Length in octets, excluding Type, Length, and Padding. 263 Lifetime Requested registration lifetime. 264 Reg Type The preferred registration types in order of preference. 266 Other documents will define specific values for registration types. 268 See Section 7 for more information. 270 A requester includes the REG_REQUEST parameter in I2 or UPDATE 271 packets to register with a registrar's service(s). If the 272 REG_REQUEST parameter is in an UPDATE packet, the registrar MUST NOT 273 modify the registrations of registration types that are not listed in 274 the parameter. Moreover, the requester MUST NOT include the 275 parameter unless the registrar's R1 packet or latest received UPDATE 276 packet has contained a REG_INFO parameter with the requested 277 registration types. 279 The requester MUST NOT include more than one REG_REQUEST parameter in 280 its I2 or UPDATE packets, while the registrar MUST be able to process 281 one or more REG_REQUEST parameters in received I2 or UPDATE packets. 283 When the registrar receives a registration with a lifetime that is 284 either smaller or greater than the minimum or maximum lifetime, 285 respectively, then it SHOULD grant the registration for the minimum 286 or maximum lifetime, respectively. 288 HIP_SIGNATURE protects the parameter within the I2 and UPDATE 289 packets. 291 4.4. REG_RESPONSE 293 0 1 2 3 294 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 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Type | Length | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Lifetime | Reg Type #1 | Reg Type #2 | Reg Type #3 | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | ... | ... | Reg Type #n | | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding + 302 | | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 Type 934 306 Length Length in octets, excluding Type, Length, and Padding. 307 Lifetime Granted registration lifetime. 308 Reg Type The granted registration types in order of preference. 310 Other documents will define specific values for registration types. 311 See Section 7 for more information. 313 The registrar SHOULD includes an REG_RESPONSE parameter in its R2 or 314 UPDATE packet only if a registration has successfully completed. 316 The registrar MUST NOT include more than one REG_RESPONSE parameter 317 in its R2 or UPDATE packets, while the requester MUST be able to 318 process one or more REG_RESPONSE parameters in received R2 or UPDATE 319 packets. 321 The requester MUST be prepared to receive any registration lifetime, 322 including ones beyond the minimum and maximum lifetime indicated in 323 the REG_INFO parameter. It MUST NOT expect that the returned 324 lifetime will be the requested one, even when the requested lifetime 325 falls within the announced minimum and maximum. 327 HIP_SIGNATURE protects the parameter within the R2 and UPDATE 328 packets. 330 4.5. REG_FAILED 332 0 1 2 3 333 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 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Type | Length | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Failure Type | Reg Type #1 | Reg Type #2 | Reg Type #3 | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | ... | ... | Reg Type #n | | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding + 341 | | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 Type 936 345 Length Length in octets, excluding Type, Length, and Padding. 346 Failure Type Reason for failure. 347 Reg Type The registration types that failed with the specified 348 reason. 350 Failure Type Reason 351 ------------ -------------------------------------------- 352 0 Registration requires additional credentials 353 1 Registration type unavailable 354 2-200 Unassigned 355 201-255 Reserved by IANA for private use 357 Other documents will define specific values for registration types. 358 See Section 7 for more information. 360 A failure type of zero means a registrar requires additional 361 credentials to authorize a requester to register with the 362 registration types listed in the parameter. A failure type of one 363 means that the requested service type is unavailable at the 364 registrar. Failure types other than zero (0) and one (1) have not 365 been defined. 367 The registrar SHOULD include the REG_FAILED parameter in its R2 or 368 UPDATE packet, if registration with the registration types listed has 369 not completed successfully and a requester is asked to try again with 370 additional credentials. 372 HIP_SIGNATURE protects the parameter within the R2 and UPDATE 373 packets. 375 5. Establishing and Maintaining Registrations 377 Establishing and/or maintaining a registration may require additional 378 information not available in the transmitted REG_REQUEST or 379 REG_RESPONSE parameters. Therefore, registration type definitions 380 MAY define dependencies for HIP parameters that are not defined in 381 this document. Their semantics are subject to the specific 382 registration type specifications. 384 The minimum lifetime both registrars and requesters MUST support is 385 10 seconds, while they SHOULD support a maximum lifetime of 120 386 seconds, at least. These values define a baseline for the 387 specification of services based on the registration system. They 388 were chosen to be neither too short nor too long, and to accommodate 389 for existing timeouts of state established in middleboxes (e.g., NATs 390 and firewalls.) 392 A zero lifetime is reserved for canceling purposes. Requesting a 393 zero lifetime for a registration type is equal to canceling the 394 registration of that type. A requester MAY cancel a registration 395 before it expires by sending a REG_REQ to the registrar with a zero 396 lifetime. A registrar SHOULD respond and grant a registration with a 397 zero lifetime. A registrar (and an attached service) MAY cancel a 398 registration before it expires, at its own discretion. However, if 399 it does so, it SHOULD send a REG_RESPONSE with a zero lifetime to all 400 registered requesters. 402 6. Security Considerations 404 This section discusses the threats on the HIP registration protocol, 405 and their implications on the overall security of HIP. In 406 particular, it argues that the extensions described in this document 407 do not introduce additional threats to HIP. 409 The extensions described in this document rely on the HIP base 410 exchange and do not modify its security characteristics, e.g., 411 digital signatures or HMAC. Hence, the only threat introduced by 412 these extensions is related to the creation of soft registration 413 state at the registrar. 415 Registrars act on a voluntary basis and are willing to accept being a 416 responder and then to create HIP associations with a number of 417 previously unknown hosts. Because they have to store HIP association 418 state anyway, adding a certain amount of time-limited HIP 419 registration state should not introduce any serious additional 420 threats, especially because HIP registrars may cancel registrations 421 at any time at their own discretion, e.g., because of resource 422 constraints during an attack. 424 7. IANA Considerations 426 This section is to be interpreted according to the Guidelines for 427 Writing an IANA Considerations Section in RFCs [RFC2434]. 429 This document updates the IANA Registry for HIP Parameter Types by 430 assigning new HIP Parameter Types values for the new HIP Parameters 431 defined in this document: 433 o REG_INFO (defined in Section 4.2) 435 o REG_REQUEST (defined in Section 4.3) 437 o REG_RESPONSE (defined in Section 4.4) 439 o REG_FAILED (defined in Section 4.5) 441 IANA has allocated the Notify Message Type code 51 for the 442 REG_REQUIRED notification error type in the Notify Message Type 443 registry. 445 IANA has opened a new registry for registration types. This document 446 does not define registration types but makes the following 447 reservations: 449 Reg Type Service 450 -------- ------- 451 0-200 Unassigned 452 201-255 Reserved by IANA for private use 454 Adding a new type requires new IETF specifications. 456 IANA has opened a new registry for registration failure types. This 457 document makes the following failure type definitions and 458 reservations: 460 Failure Type Reason 461 ------------ -------------------------------------------- 462 0 Registration requires additional credentials 463 1 Registration type unavailable 464 2-200 Unassigned 465 201-255 Reserved by IANA for private use 467 Adding a new type requires new IETF specifications. 469 8. Acknowledgments 471 The following people (in alphabetical order) have provided thoughtful 472 and helpful discussions and/or suggestions that have helped to 473 improve this document: Jeffrey Ahrenholz, Miriam Esteban, Mika Kousa, 474 Pekka Nikander, and Hannes Tschofenig. 476 9. References 478 9.1. Normative References 480 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 481 Requirement Levels", BCP 14, RFC 2119, March 1997. 483 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 484 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 485 October 1998. 487 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T. 488 Henderson, "Host Identity Protocol", RFC 5201, April 2008. 490 9.2. Informative References 492 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 493 Issues", RFC 3234, February 2002. 495 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 496 (HIP) Architecture", RFC 4423, May 2006. 498 [RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 499 Rendezvous Extension", RFC 5204, April 2008. 501 Authors' Addresses 503 Julien Laganier 504 QUALCOMM Incorporated 505 5775 Morehouse Drive 506 San Diego, CA 92121 507 USA 509 Phone: +1 858 858 3538 510 EMail: julienl@qualcomm.com 512 Teemu Koponen 513 Helsinki Institute for Information Technology 514 Advanced Research Unit (ARU) 515 P.O. Box 9800 516 Helsinki FIN-02015-HUT 517 Finland 519 Phone: +358 9 45 1 520 EMail: teemu.koponen@iki.fi 521 URI: http://www.hiit.fi/ 523 Lars Eggert 524 Nokia Research Center 525 P.O. Box 407 526 Nokia Group 00045 527 Finland 529 Phone: +358 50 48 24461 530 EMail: lars.eggert@nokia.com 531 URI: http://research.nokia.com/people/lars_eggert/