idnits 2.17.1 draft-ietf-hip-hiccups-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 (January 26, 2010) is 5204 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5201 (Obsoleted by RFC 7401) -- Obsolete informational reference (is this intentional?): RFC 5202 (Obsoleted by RFC 7402) -- Obsolete informational reference (is this intentional?): RFC 5206 (Obsoleted by RFC 8046) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HIP Working Group P. Nikander 3 Internet-Draft G. Camarillo 4 Intended status: Experimental J. Melen 5 Expires: July 30, 2010 Ericsson 6 January 26, 2010 8 HIP (Host Identity Protocol) Immediate Carriage and Conveyance of Upper- 9 layer Protocol Signaling (HICCUPS) 10 draft-ietf-hip-hiccups-01 12 Abstract 14 This document defines a new HIP (Host Identity Protocol) packet type 15 called DATA. HIP DATA packets are used to securely and reliably 16 convey arbitrary protocol messages over the Internet and various 17 overlay networks. 19 Status of this Memo 21 This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 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 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on July 30, 2010. 42 Copyright Notice 44 Copyright (c) 2010 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Background on HIP . . . . . . . . . . . . . . . . . . . . . . 3 62 3.1. Message formats . . . . . . . . . . . . . . . . . . . . . 3 63 3.1.1. HIP fixed header . . . . . . . . . . . . . . . . . . . 3 64 3.1.2. HIP parameter format . . . . . . . . . . . . . . . . . 4 65 3.2. HIP Base Exchange, Updates, and State Removal . . . . . . 5 66 4. Definition of the HIP DATA Packet . . . . . . . . . . . . . . 6 67 4.1. Definition of the SEQ_DATA Parameter . . . . . . . . . . . 7 68 4.2. Definition of the ACK_DATA Parameter . . . . . . . . . . . 7 69 4.3. Definition of the PAYLOAD_MAC Parameter . . . . . . . . . 8 70 4.4. Definition of the TRANSACTION_ID Parameter . . . . . . . . 9 71 5. Generation and Reception of HIP DATA Packets . . . . . . . . . 9 72 5.1. Handling of SEQ_DATA and ACK_DATA . . . . . . . . . . . . 9 73 5.2. Generation of a HIP DATA packet . . . . . . . . . . . . . 10 74 5.3. Reception of a HIP DATA packet . . . . . . . . . . . . . . 11 75 5.3.1. Handling of SEQ_DATA in a Received HIP DATA packet . . 11 76 5.3.2. Handling of ACK_DATA in a Received HIP DATA packet . . 12 77 6. Use of the HIP DATA Packet . . . . . . . . . . . . . . . . . . 12 78 7. Security considerations . . . . . . . . . . . . . . . . . . . 13 79 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 14 80 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 82 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 83 10.2. Informative references . . . . . . . . . . . . . . . . . . 14 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 86 1. Introduction 88 Two hosts can use HIP [RFC5201] to establish a Security Association 89 (SA) between them in order to exchange arbitrary protocol messages 90 over that security association. The establishment of such a security 91 association involves a four-way handshake referred to as the HIP base 92 exchange. When handling communications between the hosts, HIP 93 supports mobility, multihoming, security, and NAT traversal. Some 94 applications require these features for their communications but 95 cannot accept the overhead involved in establishing a security 96 association (i.e., the HIP base exchange) before those communications 97 can start. 99 In this document, we define the HIP DATA packet, which can be used to 100 convey (in a secure and reliable way) protocol messages to a remote 101 host without running the HIP base exchange between them. We also 102 discuss the trade offs involved in using this packet (i.e., less 103 overhead but also less DoS protection) and the situations where it is 104 appropriate to use this packet. The HIP_DATA packet is not aimed to 105 be a replacement for ESP transport instead it SHOULD only be used to 106 exchange few packets between the peers. If a continuous 107 communication is required hosts SHOULD run the HIP base exchange to 108 set up ESP security association. 110 2. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC 2119 [RFC2119]. 116 3. Background on HIP 118 The HIP protocol specification [RFC5201] defines a number of messages 119 and parameters. The parameters are encoded as TLVs, as shown in 120 Section 3.1.2. Furthermore, the HIP header carries a Next Header 121 field, allowing other arbitrary packets to be carried within HIP 122 packets. 124 3.1. Message formats 126 3.1.1. HIP fixed header 128 The HIP packet format consists of a fixed header followed by a 129 variable number of parameters. The parameter format is described in 130 Section 3.1.2. 132 The fixed header is defined in Section 5.1 of [RFC5201] and copied 133 below. 135 0 1 2 3 136 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 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | Next Header | Header Length |0| Packet Type | VER. | RES.|1| 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | Checksum | Controls | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | Sender's Host Identity Tag (HIT) | 143 | | 144 | | 145 | | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | Receiver's Host Identity Tag (HIT) | 148 | | 149 | | 150 | | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | | 153 / HIP Parameters / 154 / / 155 | | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 The HIP header is logically an IPv6 extension header. The HIP 159 protocol specification [RFC5201] defines handling only for Next 160 Header value decimal 59, IPPROTO_NONE, the IPv6 'no next header' 161 value. This document describes processing for Next Header values 162 other than decimal 59 which indicates that there is either more 163 extensions header or data following the HIP header. 165 3.1.2. HIP parameter format 167 The HIP parameter format is defined in Section 5.2.1 of [RFC5201], 168 and copied below. 170 0 1 2 3 171 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 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Type |C| Length | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | | 176 / Contents / 177 / +-+-+-+-+-+-+-+-+ 178 | | Padding | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 Type Type code for the parameter 182 C Critical bit, part of the Type. 183 Length Length of the parameter, in bytes. 184 Contents Parameter specific, defined by Type. 185 Padding Padding, 0-7 bytes, added if needed. 187 3.2. HIP Base Exchange, Updates, and State Removal 189 The HIP base exchange is a four-message half-stateless authentication 190 and key exchange protocol that creates shared, mutually authenticated 191 keying material at the communicating parties. These keying 192 materials, together with associated public keys and IP addresses, 193 form a HIP Security Association (SA). The details of the protocol 194 are defined in the HIP base exchange specification [RFC5201]. 196 In addition to creating the HIP SA, the base exchange messages may 197 carry additional parameters that are used to create additional state. 198 For example, the HIP ESP specification [RFC5202] defines how HIP can 199 be used to create end-to-end, host-to-host IPsec ESP Security 200 Associations, used to carry data packets. However, it is important 201 to understand that the HIP base exchange is by no means bound to 202 IPsec; using IPsec ESP to carry data traffic forms just a baseline 203 and ensures interoperability between initial HIP implementations. 205 Once there is a HIP SA between two HIP-enabled hosts, they can 206 exchange further HIP control messages. Typically, UPDATE messages 207 are used. For example, the HIP mobility and multihoming 208 specification [RFC5206] defines how to use UPDATE messages to change 209 the set of IP addresses associated with a HIP SA. 211 In addition to the base exchange and updates, the HIP base protocol 212 specification also defines how one can remove a HIP SA once it is no 213 longer needed. 215 4. Definition of the HIP DATA Packet 217 The HIP DATA packet can be used to convey protocol messages to a 218 remote host without running the HIP base exchange between them. HIP 219 DATA packets are transmitted reliably, as discussed in Section 5. 220 The payload of a HIP DATA packet is placed after the HIP header and 221 protected by a PAYLOAD_MAC parameter, which is defined in 222 Section 4.3. The following is the definition of the HIP DATA packet: 224 Header: 225 Packet Type = [ TBD by IANA: 32 ] 226 SRC HIT = Sender's HIT 227 DST HIT = Receiver's HIT 229 IP ( HIP ( [HOST_ID, ] SEQ_DATA, PAYLOAD_MAC, 230 HIP_SIGNATURE) PAYLOAD ) 232 IP ( HIP ( [HOST_ID, ] SEQ_DATA, ACK_DATA, PAYLOAD_MAC, 233 HIP_SIGNATURE) PAYLOAD ) 235 IP ( HIP ( [HOST_ID, ] ACK_DATA, HIP_SIGNATURE)) 237 The SEQ_DATA and ACK_DATA parameters are defined in Section 4.1 and 238 Section 4.2 respectively. They are used to provide a reliable 239 delivery of HIP DATA packets, as discussed in Section 5. 241 The HOST_ID parameter is defined in Section 5.2.8 of [RFC5201]. This 242 parameter is the sender's Host Identifier that is used to compute the 243 HIP DATA packet's signature and to verify it against the received 244 signature. 246 The PAYLOAD_MAC parameter is defined in Section 4.3. This parameter 247 contains the HMAC of the payload carried by the HIP DATA packet. The 248 PAYLOAD_MAC contains the checksum of the payload following after the 249 HIP DATA. The PAYLOAD_MAC is included in the signed part of the HIP 250 DATA packet giving integrity protection also for the payload carried 251 after HIP DATA packet. 253 The HIP_SIGNATURE parameter is defined in Section 5.2.11. of 254 [RFC5201]. It contains a signature over the contents of the HIP DATA 255 packet. The calculation and verification of the signature is defined 256 Section 6.4.2. of [RFC5201] 258 Section 5.3 of [RFC5201] states the following: 260 In the future, an OPTIONAL upper-layer payload MAY follow the HIP 261 header. The Next Header field in the header indicates if there is 262 additional data following the HIP header. 264 We have chosen to place the payload after the HIP extension header 265 and only to place an HMAC of the payload in to the HIP extension 266 header in a PAYLOAD_MAC parameter because that way the data is 267 protected by a public key signature with help of HMAC. The payload 268 that is protected by the PAYLOAD_MAC parameter has been linked to the 269 appropriate upper-layer protocol by storing the upper-layer protocol 270 number, 8 bytes of payload data, and by calculating an HMAC over the 271 data. The HMAC algorithm is same as the algorithm used to generate 272 the Host Identity Tag. 274 Upper-layer protocol messages, such as overlay network control 275 traffic, sent in HIP DATA messages may need to be matched to 276 different transactions. For this purpose, a DATA message MAY also 277 contain a TRANSACTION_ID parameter. The identifier value is a number 278 that is unique for each transaction. A response to a request uses 279 the same identifier value allowing receiver to match requests to 280 responses. 282 4.1. Definition of the SEQ_DATA Parameter 284 The following is the definition of the SEQ_DATA parameter: 286 0 1 2 3 287 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 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Type | Length | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Sequence number | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 Type [ TBD by IANA: 295 4481 = (2^12 + 2^8 + 2^7 + 1) ] 296 Length 4 297 Sequence number 32-bit sequence number 299 4.2. Definition of the ACK_DATA Parameter 301 The following is the definition of the ACK_DATA parameter: 303 0 1 2 3 304 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 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Type | Length | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Acked Sequence number | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 Type [ TBD by IANA: 312 4545 = (2^12 + 2^8 + 2^7 + 2^6 + 1) ] 313 Length 4 314 Acked Sequence number 32-bit sequence number corresponding to 315 the sequence number being acknowledged 317 4.3. Definition of the PAYLOAD_MAC Parameter 319 The following is the definition of the PAYLOAD_MAC parameter: 321 0 1 2 3 322 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 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Type | Length | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Next header | Reserved | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Payload Data | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | | 331 / Payload HMAC / 332 / +-+-+-+-+-+-+-+-+ 333 | | Padding | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 Type [ TBD by IANA: 337 4577 = (2^12 + 2^8 + 2^7 + 2^6 + 2^5 + 1) ] 338 Length length in octets, excluding Type, Length, and 339 Padding 340 Next Header Identifies the data that protected by this HMAC. 341 The values for are defined by IANA "Assigned 342 Numbers". 343 Payload Data 8 last bytes of the payload data over which the 344 HMAC is calculated. This field is used to 345 uniquely identify the extension header, in case 346 there are multiple copies of same type. 347 Payload HMAC HMAC computed over the data to which the Next 348 Header and Payload Data points to. The size of 349 the HMAC is the natural size of the computation 350 output depending on the used function. 352 4.4. Definition of the TRANSACTION_ID Parameter 354 The following is the definition of the TRANSACTION_ID parameter: 356 0 1 2 3 357 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 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Type | Length | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Identifier / 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 / | Padding | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 Type [ TBD by IANA; 982 ] 367 Length Length of the Identifier in octets 368 Identifier The identifier value 369 Padding 0-7 bytes of padding if needed 371 Figure 1: Format of the TRANSACTION_ID parameter 373 5. Generation and Reception of HIP DATA Packets 375 HIP DATA packets are transmitted reliably. Reliable delivery is 376 achieved through the use of retransmissions and of the SEQ_DATA and 377 ACK_DATA parameters. 379 5.1. Handling of SEQ_DATA and ACK_DATA 381 A HIP DATA packet contains zero or one SEQ_DATA parameter. The 382 presence of a SEQ_DATA parameter indicates that the receiver MUST ACK 383 the HIP DATA packet. A HIP DATA packet that does not contain a 384 SEQ_DATA parameter is simply an ACK of a previous HIP DATA packet and 385 MUST NOT be ACKed. 387 A HIP DATA packet contains zero or one ACK_DATA parameters. The ACK 388 parameter echoes the SEQ_DATA sequence number of the HIP DATA packet 389 packet being ACKed. 391 A HIP DATA packet may contain both a SEQ_DATA and an ACK_DATA 392 parameter. In this case, the ACK is being piggybacked on an outgoing 393 HIP DATA packet. In general, HIP DATA packets carrying SEQ_DATA 394 SHOULD be ACKed upon completion of the processing of the HIP DATA 395 packet. A host MAY choose to hold the HIP DATA packet carrying ACK 396 for a short period of time to allow for the possibility of 397 piggybacking the ACK parameter, in a manner similar to TCP delayed 398 acknowledgments. 400 5.2. Generation of a HIP DATA packet 402 When a host has upper-layer protocol data to send, it either runs the 403 HIP base exchange and sends the data over a SA, or sends the data 404 directly using a HIP DATA packet. Section 6 discusses when it is 405 appropriate to use each method. This section discusses the case when 406 the host chooses to use a HIP DATA packet to send the upper-layer 407 protocol data. 409 1. The host creates a HIP DATA packet that contains a SEQ_DATA 410 parameter. The host is free to choose any value for the SEQ_DATA 411 parameter in the first HIP DATA packet it sends to a destination. 412 After that first packet, the host MUST choose the value of the 413 SEQ_DATA parameter in subsequent HIP DATA packets to the same 414 destination so that no SEQ_DATA value is reused before the 415 receiver has closed the processing window for the previous packet 416 using the same SEQ_DATA value. Practically, giving the values of 417 the retransmission timers used with HIP DATA packets, this means 418 that hosts must wait the maximum likely lifetime of the packet 419 before reusing a given SEQ_DATA value towards a given 420 destination. However, it is not required for node to know the 421 maximum packet lifetime. Rather, it is assumed that the 422 requirement can be met by maintaining the value as a simple, 32- 423 bit, "wrap-around" counter, incremented each time a packet is 424 sent. It is an implementation choice whether to maintain a 425 single counter for the node or multiple counters (one for each 426 source HIT, destination HIT combination). 427 2. The host creates PAYLOAD_HMAC parameter. The HMAC is calculated 428 over the whole PAYLOAD which the Next Header field of 429 PAYLOAD_HMAC parameter indicates. The receiver MUST validate 430 this HMAC. For calculating the HMAC the host MUST use the same 431 hash algorithm as the one that has been used for generating the 432 host's HIT as defined in Section 3.2. of [RFC5201]. 433 3. The host creates HIP_SIGNATURE parameter. The signature is 434 calculated over the whole HIP envelope, excluding any parameters 435 after the HIP_SIGNATURE, as defined in Section 5.2.11. of 436 [RFC5201]. The receiver MUST validate this signature. It MAY 437 use either the HI in the packet or the HI acquired by some other 438 means. 439 4. The hosts sends the created HIP DATA packet and starts a DATA 440 timer. The default value for the timer is 2 * RTT estimate. If 441 multiple HIP DATA packets are outstanding, multiple timers are in 442 effect. 443 5. If the DATA timer expires, the HIP DATA packet is resent. The 444 HIP DATA packet can be resent DATA_RETRY_MAX times. The DATA 445 timer SHOULD be exponentially backed off for subsequent 446 retransmissions. If no acknowledgment is received from the peer 447 after DATA_RETRY_MAX times, the delivery of the HIP DATA packet 448 is considered unsuccessful and the application is notified about 449 the error. The DATA timer is canceled upon receiving an ACK from 450 the peer that acknowledges receipt of the HIP DATA packet. 452 5.3. Reception of a HIP DATA packet 454 A host receiving a HIP DATA packet to decide whether to process it or 455 not. If the host, following its local policy, suspects that this 456 packet could be part of a DoS attack. The host MAY respond with an 457 R1 packet to the HIP DATA packet, if the packet contained SEQ_DATA 458 and PAYLOAD_HMAC parameter, in order to run the HIP base exchange 459 with the originator of the HIP DATA packet. If the host chooses to 460 respond to the HIP DATA with an R1 packet, it creates a new R1 or 461 selects a precomputed R1 according to the format described in 462 [RFC5201] Section 5.3.2. The host SHOULD drop the received data 463 packet if it responded with a R1 packet to the HIP_DATA packet. The 464 sender of HIP_DATA packet is responsible of retransmission of the 465 upper-layer protocol data after successful completion of the HIP Base 466 Exchange. 468 If the host, following its local policy, decides to process the 469 incoming HIP DATA packet, it processes it according to the following 470 rules: 472 If the HIP DATA packet contains a SEQ_DATA parameter and no 473 ACK_DATA parameter, the HIP DATA packet is processed and replied 474 to as described in Section 5.3.1. 475 If the HIP DATA packet contains an ACK_DATA parameter and no 476 SEQ_DATA parameter, the HIP DATA packet is processed and replied 477 to as described in Section 5.3.2. 478 If the HIP DATA packet contains both a SEQ_DATA parameter and an 479 ACK_DATA parameter, the HIP DATA packet is processed first as 480 described in Section 5.3.2 and then the rest of the HIP DATA 481 packet is processed and replied to as described in Section 5.3.1. 483 5.3.1. Handling of SEQ_DATA in a Received HIP DATA packet 485 The following steps define the conceptual processing rules for 486 handling a SEQ_DATA parameter in a received HIP DATA packet. 488 If the value in the received SEQ_DATA corresponds to a HIP DATA 489 packet that has recently been processed, the packet is treated as a 490 retransmission. The SIGNATURE verification (next step) MUST NOT be 491 skipped. (A byte-by-byte comparison of the received and a stored 492 packet would be OK, though.) It is recommended that a host cache HIP 493 DATA packets sent with ACKs to avoid the cost of generating a new ACK 494 packet to respond to a retransmitted HIP DATA packet. The host MUST 495 acknowledge, again, such (apparent) HIP DATA packet retransmissions 496 but SHOULD also consider rate-limiting such retransmission responses 497 to guard against replay attacks. 499 The system MUST verify the SIGNATURE in the HIP DATA packet. If the 500 verification fails, the packet SHOULD be dropped and an error message 501 logged. 503 The system MUST verify the PAYLOAD_HMAC by calculating the HMAC over 504 the PAYLOAD which the Next Header field indicates. For calculating 505 the HMAC the host will use the same hash algorithm that has been used 506 to generate the sender's HIT as defined in Section 3.2. of [RFC5201]. 507 If the verification fails, the packet SHOULD be dropped and an error 508 message logged. 510 If a new SEQ parameter is being processed, the parameters in the HIP 511 DATA packet are then processed. 513 A HIP DATA packet with an ACK_DATA parameter is prepared and sent to 514 the peer. This ACK_DATA parameter may be included in a separate HIP 515 DATA packet or piggybacked in a HIP DATA packet with a SEQ_DATA 516 parameter. The ACK_DATA parameter MAY acknowledge more than one of 517 the peer's HIP DATA packets. 519 5.3.2. Handling of ACK_DATA in a Received HIP DATA packet 521 The following steps define the conceptual processing rules for 522 handling an ACK_DATA parameter in a received HIP DATA packet. 524 The sequence number reported in the ACK_DATA must match with an 525 earlier sent HIP DATA packet that has not already been acknowledged. 526 If no match is found or if the ACK_DATA does not acknowledge a new 527 HIP DATA packet, the packet MUST either be dropped if no SEQ_DATA 528 parameter is present, or the processing steps in Section 5.3.1 are 529 followed. 531 The system MUST verify the SIGNATURE in the HIP DATA packet. If the 532 verification fails, the packet SHOULD be dropped and an error message 533 logged. 535 The corresponding DATA timer is stopped so that the now acknowledged 536 HIP DATA packet is no longer retransmitted. If multiple HIP DATA 537 packets are newly acknowledged, multiple timers are stopped. 539 6. Use of the HIP DATA Packet 541 HIP currently requires always that the four-message base exchange is 542 executed at the first encounter of hosts that have not communicated 543 before. This may add additional RTTs (Round Trip Time) to protocols 544 based on a single message exchange. However, the four-message 545 exchange is essential to preserve the half-stateless DoS protection 546 nature of the base exchange. The use of the HIP DATA packet defined 547 in this document reduces the initial overhead in the communications 548 between two hosts at the expense of decreasing DoS protection. 549 Therefore, applications SHOULD NOT use HIP DATA packets in 550 environments where DoS attacks are believed to be an issue. For 551 example, a HIP-based overlay may have policies in place to control 552 which nodes can join the overlay. Any particular node in the overlay 553 may want to accept HIP DATA packets from other nodes in the overlay 554 given that those other were authorized to join the overlay. However, 555 the same node may not want to accept HIP DATA packets from random 556 nodes that are not part of the overlay. 558 The type of data to be sent is also relevant to whether the use of a 559 HIP DATA packet is appropriate. HIP itself does not support 560 fragmentation but relies on underlying IP-layer fragmentation. This 561 may lead to reliability problems in the case where a message cannot 562 be easily split over multiple HIP messages. Therefore, applications 563 in environments where fragmentation could be an issue SHOULD NOT 564 generate too large HIP DATA packets that may lead to fragmentation. 565 The implementation SHOULD check the MTU of the link before sending 566 the packet and if the packet size is larger than MTU it SHOULD signal 567 to the upper-layer protocol if the packet results in to a ICMP error 568 message. Note that there are environments where fragmentation is not 569 an issue. For example, in some HIP-based overlays, nodes can 570 exchange HIP DATA packets on top of TCP connections that provide 571 transport-level fragmentation and, thus, avoid IP-level 572 fragmentation. 574 HIP currently requires that all messages excluding I1s but including 575 HIP DATA packets are digitally signed. This adds to the packet size 576 and the processing capacity needed to send packets. However, in 577 applications where security is not paramount, it is possible to use 578 very short keys, thereby reducing resource consumption. 580 7. Security considerations 582 HIP is designed to provide secure authentication of hosts. HIP also 583 attempts to limit the exposure of the host to various denial-of- 584 service and man-in-the-middle (MitM) attacks. However, HIP DATA 585 packet, which can be sent without running the HIP base exchange 586 between hosts has a trade off that it does not provide the denial-of- 587 service protection that HIP generally provides. Thus, the host 588 should consider always situations where it is appropriate to send or 589 receive HIP DATA packet. If the communication consists more than few 590 round-trips of data or the data is highly sensitive in nature the 591 host SHOULD run the base exchange with the peer host. 593 8. IANA considerations 595 This document updates the IANA Registry for HIP Packet types by 596 introducing new packet type for the new HIP_DATA (Section 4) packet. 597 This document updates the IANA Registry for HIP Parameter Types by 598 introducing new parameter values for the SEQ_DATA (Section 4.1), 599 ACK_DATA (Section 4.2), and PAYLOAD_HMAC (Section 4.3) parameters. 601 9. Acknowledgments 603 In the usual IETF fashion, a large number of people have contributed 604 to the actual text or ideas. The list of these people include Miika 605 Komu, Tobias Heer, Ari Keranen, Samu Varjonen, Thomas Henderson, and 606 Jukka Ylitalo. Our apologies to anyone whose name is missing. 608 10. References 610 10.1. Normative References 612 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 613 Requirement Levels", BCP 14, RFC 2119, March 1997. 615 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 616 "Host Identity Protocol", RFC 5201, April 2008. 618 10.2. Informative references 620 [RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the 621 Encapsulating Security Payload (ESP) Transport Format with 622 the Host Identity Protocol (HIP)", RFC 5202, April 2008. 624 [RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End- 625 Host Mobility and Multihoming with the Host Identity 626 Protocol", RFC 5206, April 2008. 628 Authors' Addresses 630 Pekka Nikander 631 Ericsson 632 Hirsalantie 11 633 Jorvas 02420 634 Finland 636 Email: Pekka.Nikander@ericsson.com 638 Gonzalo Camarillo 639 Ericsson 640 Hirsalantie 11 641 Jorvas 02420 642 Finland 644 Email: Gonzalo.Camarillo@ericsson.com 646 Jan Melen 647 Ericsson 648 Hirsalantie 11 649 Jorvas 02420 650 Finland 652 Email: Jan.Melen@ericsson.com