idnits 2.17.1 draft-nikander-hip-hiccups-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 97: '...sport instead it SHOULD only be used t...' RFC 2119 keyword, line 99: '...s required hosts SHOULD run the HIP ba...' RFC 2119 keyword, line 246: '...n the future, an OPTIONAL upper-layer ...' RFC 2119 keyword, line 339: '...r indicates that the receiver MUST ACK...' RFC 2119 keyword, line 342: '... MUST NOT be ACKed....' (25 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 20, 2009) is 5357 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): 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 (==), 5 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: February 21, 2010 Ericsson 6 August 20, 2009 8 HIP (Host Identity Protocol) Immediate Carriage and Conveyance of Upper- 9 layer Protocol Signaling (HICCUPS) 10 draft-nikander-hip-hiccups-04 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on February 21, 2010. 35 Copyright Notice 37 Copyright (c) 2009 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 in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 This document defines a new HIP (Host Identity Protocol) packet type 49 called DATA. HIP DATA packets are used to securely and reliably 50 convey arbitrary protocol messages over the Internet and various 51 overlay networks. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Background on HIP . . . . . . . . . . . . . . . . . . . . . . 4 57 2.1. Message formats . . . . . . . . . . . . . . . . . . . . . 4 58 2.1.1. HIP fixed header . . . . . . . . . . . . . . . . . . . 4 59 2.1.2. HIP parameter format . . . . . . . . . . . . . . . . . 5 60 2.2. HIP Base Exchange, Updates, and State Removal . . . . . . 5 61 3. Definition of the HIP DATA Packet . . . . . . . . . . . . . . 7 62 3.1. Definition of the SEQ_DATA Parameter . . . . . . . . . . . 8 63 3.2. Definition of the ACK_DATA Parameter . . . . . . . . . . . 8 64 3.3. Definition of the PAYLOAD_MAC Parameter . . . . . . . . . 9 65 4. Generation and Reception of HIP DATA Packets . . . . . . . . . 10 66 4.1. Handling of SEQ_DATA and ACK_DATA . . . . . . . . . . . . 10 67 4.2. Generation of a HIP DATA packet . . . . . . . . . . . . . 10 68 4.3. Reception of a HIP DATA packet . . . . . . . . . . . . . . 11 69 4.3.1. Handling of SEQ_DATA in a Received HIP DATA packet . . 12 70 4.3.2. Handling of ACK_DATA in a Received HIP DATA packet . . 13 71 5. Use of the HIP DATA Packet . . . . . . . . . . . . . . . . . . 14 72 6. Security considerations . . . . . . . . . . . . . . . . . . . 15 73 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 16 74 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 75 9. Informative references . . . . . . . . . . . . . . . . . . . . 18 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 78 1. Introduction 80 Two hosts can use HIP [RFC5201] to establish a Security Association 81 (SA) between them in order to exchange arbitrary protocol messages 82 over that security association. The establishment of such a security 83 association involves a four-way handshake referred to as the HIP base 84 exchange. When handling communications between the hosts, HIP 85 supports mobility, multihoming, security, and NAT traversal. Some 86 applications require these features for their communications but 87 cannot accept the overhead involved in establishing a security 88 association (i.e., the HIP base exchange) before those communications 89 can start. 91 In this document, we define the HIP DATA packet, which can be used to 92 convey (in a secure and reliable way) protocol messages to a remote 93 host without running the HIP base exchange between them. We also 94 discuss the trade offs involved in using this packet (i.e., less 95 overhead but also less DoS protection) and the situations where it is 96 appropriate to use this packet. The HIP_DATA packet is not aimed to 97 be a replacement for ESP transport instead it SHOULD only be used to 98 exchange few packets between the peers. If a continuous 99 communication is required hosts SHOULD run the HIP base exchange to 100 set up ESP security association. 102 2. Background on HIP 104 The HIP protocol specification [RFC5201] defines a number of messages 105 and parameters. The parameters are encoded as TLVs, as shown in 106 Section 2.1.2. Furthermore, the HIP header carries a Next Header 107 field, allowing other arbitrary packets to be carried within HIP 108 packets. 110 2.1. Message formats 112 2.1.1. HIP fixed header 114 The HIP packet format consists of a fixed header followed by a 115 variable number of parameters. The parameter format is described in 116 Section 2.1.2. 118 The fixed header is defined in Section 5.1 of [RFC5201] and copied 119 below. 121 0 1 2 3 122 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 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | Next Header | Header Length |0| Packet Type | VER. | RES.|1| 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | Checksum | Controls | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | Sender's Host Identity Tag (HIT) | 129 | | 130 | | 131 | | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | Receiver's Host Identity Tag (HIT) | 134 | | 135 | | 136 | | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | | 139 / HIP Parameters / 140 / / 141 | | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 The HIP header is logically an IPv6 extension header. The HIP 145 protocol specification [RFC5201] defines handling only for Next 146 Header value decimal 59, IPPROTO_NONE, the IPv6 'no next header' 147 value. This document describes processing for Next Header values 148 other than decimal 59 which indicates that there is either more 149 extensions header or data following the HIP header. 151 2.1.2. HIP parameter format 153 The HIP parameter format is defined in Section 5.2.1 of [RFC5201], 154 and copied below. 156 0 1 2 3 157 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 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | Type |C| Length | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | | 162 / Contents / 163 / +-+-+-+-+-+-+-+-+ 164 | | Padding | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 Type Type code for the parameter 168 C Critical bit, part of the Type. 169 Length Length of the parameter, in bytes. 170 Contents Parameter specific, defined by Type. 171 Padding Padding, 0-7 bytes, added if needed. 173 2.2. HIP Base Exchange, Updates, and State Removal 175 The HIP base exchange is a four-message half-stateless authentication 176 and key exchange protocol that creates shared, mutually authenticated 177 keying material at the communicating parties. These keying 178 materials, together with associated public keys and IP addresses, 179 form a HIP Security Association (SA). The details of the protocol 180 are defined in the HIP base exchange specification [RFC5201]. 182 In addition to creating the HIP SA, the base exchange messages may 183 carry additional parameters that are used to create additional state. 184 For example, the HIP ESP specification [RFC5202] defines how HIP can 185 be used to create end-to-end, host-to-host IPsec ESP Security 186 Associations, used to carry data packets. However, it is important 187 to understand that the HIP base exchange is by no means bound to 188 IPsec; using IPsec ESP to carry data traffic forms just a baseline 189 and ensures interoperability between initial HIP implementations. 191 Once there is a HIP SA between two HIP-enabled hosts, they can 192 exchange further HIP control messages. Typically, UPDATE messages 193 are used. For example, the HIP mobility and multi-homing 194 specification [RFC5206] defines how to use UPDATE messages to change 195 the set of IP addresses associated with a HIP SA. 197 In addition to the base exchange and updates, the HIP base protocol 198 specification also defines how one can remove a HIP SA once it is no 199 longer needed. 201 3. Definition of the HIP DATA Packet 203 The HIP DATA packet can be used to convey protocol messages to a 204 remote host without running the HIP base exchange between them. HIP 205 DATA packets are transmitted reliably, as discussed in Section 4. 206 The payload of a HIP DATA packet is placed after the HIP header and 207 protected by a PAYLOAD_MAC parameter, which is defined in 208 Section 3.3. The following is the definition of the HIP DATA packet: 210 Header: 211 Packet Type = [ TBD by IANA: 32 ] 212 SRC HIT = Sender's HIT 213 DST HIT = Receiver's HIT 215 IP ( HIP ( [HOST_ID, ] SEQ_DATA, PAYLOAD_MAC, 216 HIP_SIGNATURE) PAYLOAD ) 218 IP ( HIP ( [HOST_ID, ] SEQ_DATA, ACK_DATA, PAYLOAD_MAC, 219 HIP_SIGNATURE) PAYLOAD ) 221 IP ( HIP ( [HOST_ID, ] ACK_DATA, HIP_SIGNATURE)) 223 The SEQ_DATA and ACK_DATA parameters are defined in Section 3.1 and 224 Section 3.2 respectively. They are used to provide a reliable 225 delivery of HIP DATA packets, as discussed in Section 4. 227 The HOST_ID parameter is defined in Section 5.2.8 of [RFC5201]. This 228 parameter is the sender's Host Identifier that is used to compute the 229 HIP DATA packet's signature and to verify it against the received 230 signature. 232 The PAYLOAD_MAC parameter is defined in Section 3.3. This parameter 233 contains the HMAC of the payload carried by the HIP DATA packet. The 234 PAYLOAD_MAC contains the checksum of the payload following after the 235 HIP DATA. The PAYLOAD_MAC is included in the signed part of the HIP 236 DATA packet giving integrity protection also for the payload carried 237 after HIP DATA packet. 239 The HIP_SIGNATURE parameter is defined in Section 5.2.11. of 240 [RFC5201]. It contains a signature over the contents of the HIP DATA 241 packet. The calculation and verification of the signature is defined 242 Section 6.4.2. of [RFC5201] 244 Section 5.3 of [RFC5201] states the following: 246 In the future, an OPTIONAL upper-layer payload MAY follow the HIP 247 header. The Next Header field in the header indicates if there is 248 additional data following the HIP header. 250 We have chosen to place the payload after the HIP extension header 251 and only to place an HMAC of the payload in to the HIP extension 252 header in a PAYLOAD_MAC parameter because that way the data is 253 protected by a public key signature with help of HMAC. The payload 254 that is protected by the PAYLOAD_MAC parameter has been linked to the 255 appropriate upper-layer protocol by storing the upper-layer protocol 256 number, 8 bytes of payload data, and by calculating an HMAC over the 257 data. The HMAC algorithm is same as the algorithm used to generate 258 the Host Identity Tag. 260 3.1. Definition of the SEQ_DATA Parameter 262 The following is the definition of the SEQ_DATA parameter: 264 0 1 2 3 265 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 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Type | Length | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Sequence number | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 Type [ TBD by IANA: 273 4481 = (2^12 + 2^8 + 2^7 + 1) ] 274 Length 4 275 Sequence number 32-bit sequence number 277 3.2. Definition of the ACK_DATA Parameter 279 The following is the definition of the ACK_DATA parameter: 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 | Acked Sequence number | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 Type [ TBD by IANA: 290 4545 = (2^12 + 2^8 + 2^7 + 2^6 + 1) ] 291 Length 4 292 Acked Sequence number 32-bit sequence number corresponding to 293 the sequence number being acknowledged 295 3.3. Definition of the PAYLOAD_MAC Parameter 297 The following is the definition of the PAYLOAD_MAC parameter: 299 0 1 2 3 300 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 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Type | Length | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Next header | Reserved | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Payload Data | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | | 309 / Payload HMAC / 310 / +-+-+-+-+-+-+-+-+ 311 | | Padding | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 Type [ TBD by IANA: 315 4577 = (2^12 + 2^8 + 2^7 + 2^6 + 2^5 + 1) ] 316 Length length in octets, excluding Type, Length, and 317 Padding 318 Next Header Identifies the data that protected by this HMAC. 319 The values for are defined by IANA "Assigned 320 Numbers". 321 Payload Data 8 last bytes of the payload data over which the 322 HMAC is calculated. This field is used to 323 uniquely identify the extension header, in case 324 there are multiple copies of same type. 325 Payload HMAC HMAC computed over the data to which the Next 326 Header and Payload Data points to. The size of 327 the HMAC is the natural size of the computation 328 output depending on the used function. 330 4. Generation and Reception of HIP DATA Packets 332 HIP DATA packets are transmitted reliably. Reliable delivery is 333 achieved through the use of retransmissions and of the SEQ_DATA and 334 ACK_DATA parameters. 336 4.1. Handling of SEQ_DATA and ACK_DATA 338 A HIP DATA packet contains zero or one SEQ_DATA parameter. The 339 presence of a SEQ_DATA parameter indicates that the receiver MUST ACK 340 the HIP DATA packet. A HIP DATA packet that does not contain a 341 SEQ_DATA parameter is simply an ACK of a previous HIP DATA packet and 342 MUST NOT be ACKed. 344 A HIP DATA packet contains zero or one ACK_DATA parameters. The ACK 345 parameter echoes the SEQ_DATA sequence number of the HIP DATA packet 346 packet being ACKed. 348 A HIP DATA packet may contain both a SEQ_DATA and an ACK_DATA 349 parameter. In this case, the ACK is being piggybacked on an outgoing 350 HIP DATA packet. In general, HIP DATA packets carrying SEQ_DATA 351 SHOULD be ACKed upon completion of the processing of the HIP DATA 352 packet. A host MAY choose to hold the HIP DATA packet carrying ACK 353 for a short period of time to allow for the possibility of 354 piggybacking the ACK parameter, in a manner similar to TCP delayed 355 acknowledgments. 357 4.2. Generation of a HIP DATA packet 359 When a host has upper-layer protocol data to send, it either runs the 360 HIP base exchange and sends the data over a SA, or sends the data 361 directly using a HIP DATA packet. Section 5 discusses when it is 362 appropriate to use each method. This section discusses the case when 363 the host chooses to use a HIP DATA packet to send the upper-layer 364 protocol data. 366 1. The host creates a HIP DATA packet that contains a SEQ_DATA 367 parameter. The host is free to choose any value for the SEQ_DATA 368 parameter in the first HIP DATA packet it sends to a destination. 369 After that first packet, the host MUST choose the value of the 370 SEQ_DATA parameter in subsequent HIP DATA packets to the same 371 destination so that no SEQ_DATA value is reused before the 372 receiver has closed the processing window for the previous packet 373 using the same SEQ_DATA value. Practically, giving the values of 374 the retransmission timers used with HIP DATA packets, this means 375 that hosts must wait the maximum likely lifetime of the packet 376 before reusing a given SEQ_DATA value towards a given 377 destination. However, it is not required for node to know the 378 maximum packet lifetime. Rather, it is assumed that the 379 requirement can be met by maintaining the value as a simple, 32- 380 bit, "wrap-around" counter, incremented each time a packet is 381 sent. It is an implementation choice whether to maintain a 382 single counter for the node or multiple counters (one for each 383 source HIT, destination HIT combination). 385 2. The host creates PAYLOAD_HMAC parameter. The HMAC is calculated 386 over the whole PAYLOAD which the Next Header field of 387 PAYLOAD_HMAC parameter indicates. The receiver MUST validate 388 this HMAC. For calculating the HMAC the host MUST use the same 389 hash algorithm as the one that has been used for generating the 390 host's HIT as defined in Section 3.2. of [RFC5201]. 392 3. The host creates HIP_SIGNATURE parameter. The signature is 393 calculated over the whole HIP envelope, excluding any parameters 394 after the HIP_SIGNATURE, as defined in Section 5.2.11. of 395 [RFC5201]. The receiver MUST validate this signature. It MAY 396 use either the HI in the packet or the HI acquired by some other 397 means. 399 4. The hosts sends the created HIP DATA packet and starts a DATA 400 timer. The default value for the timer is 2 * RTT estimate. If 401 multiple HIP DATA packets are outstanding, multiple timers are in 402 effect. 404 5. If the DATA timer expires, the HIP DATA packet is resent. The 405 HIP DATA packet can be resent DATA_RETRY_MAX times. The DATA 406 timer SHOULD be exponentially backed off for subsequent 407 retransmissions. If no acknowledgment is received from the peer 408 after DATA_RETRY_MAX times, the delivery of the HIP DATA packet 409 is considered unsuccessful and the application is notified about 410 the error. The DATA timer is canceled upon receiving an ACK from 411 the peer that acknowledges receipt of the HIP DATA packet. 413 4.3. Reception of a HIP DATA packet 415 A host receiving a HIP DATA packet to decide whether to process it or 416 not. If the host, following its local policy, suspects that this 417 packet could be part of a DoS attack. The host MAY respond with an 418 R1 packet to the HIP DATA packet, if the packet contained SEQ_DATA 419 and PAYLOAD_HMAC parameter, in order to run the HIP base exchange 420 with the originator of the HIP DATA packet. If the host chooses to 421 respond to the HIP DATA with an R1 packet, it creates a new R1 or 422 selects a precomputed R1 according to the format described in 423 [RFC5201] Section 5.3.2. The host SHOULD drop the received data 424 packet if it responded with a R1 packet to the HIP_DATA packet. The 425 sender of HIP_DATA packet is responsible of retransmission of the 426 upper-layer protocol data after successful completion of the HIP Base 427 Exchange. 429 If the host, following its local policy, decides to process the 430 incoming HIP DATA packet, it processes it according to the following 431 rules: 433 If the HIP DATA packet contains a SEQ_DATA parameter and no 434 ACK_DATA parameter, the HIP DATA packet is processed and replied 435 to as described in Section 4.3.1. 437 If the HIP DATA packet contains an ACK_DATA parameter and no 438 SEQ_DATA parameter, the HIP DATA packet is processed and replied 439 to as described in Section 4.3.2. 441 If the HIP DATA packet contains both a SEQ_DATA parameter and an 442 ACK_DATA parameter, the HIP DATA packet is processed first as 443 described in Section 4.3.2 and then the rest of the HIP DATA 444 packet is processed and replied to as described in Section 4.3.1. 446 4.3.1. Handling of SEQ_DATA in a Received HIP DATA packet 448 The following steps define the conceptual processing rules for 449 handling a SEQ_DATA parameter in a received HIP DATA packet. 451 If the value in the received SEQ_DATA corresponds to a HIP DATA 452 packet that has recently been processed, the packet is treated as a 453 retransmission. The SIGNATURE verification (next step) MUST NOT be 454 skipped. (A byte-by-byte comparison of the received and a stored 455 packet would be OK, though.) It is recommended that a host cache HIP 456 DATA packets sent with ACKs to avoid the cost of generating a new ACK 457 packet to respond to a retransmitted HIP DATA packet. The host MUST 458 acknowledge, again, such (apparent) HIP DATA packet retransmissions 459 but SHOULD also consider rate-limiting such retransmission responses 460 to guard against replay attacks. 462 The system MUST verify the SIGNATURE in the HIP DATA packet. If the 463 verification fails, the packet SHOULD be dropped and an error message 464 logged. 466 The system MUST verify the PAYLOAD_HMAC by calculating the HMAC over 467 the PAYLOAD which the Next Header field indicates. For calculating 468 the HMAC the host will use the same hash algorithm that has been used 469 to generate the sender's HIT as defined in Section 3.2. of [RFC5201]. 470 If the verification fails, the packet SHOULD be dropped and an error 471 message logged. 473 If a new SEQ parameter is being processed, the parameters in the HIP 474 DATA packet are then processed. 476 A HIP DATA packet with an ACK_DATA parameter is prepared and sent to 477 the peer. This ACK_DATA parameter may be included in a separate HIP 478 DATA packet or piggybacked in a HIP DATA packet with a SEQ_DATA 479 parameter. The ACK_DATA parameter MAY acknowledge more than one of 480 the peer's HIP DATA packets. 482 4.3.2. Handling of ACK_DATA in a Received HIP DATA packet 484 The following steps define the conceptual processing rules for 485 handling an ACK_DATA parameter in a received HIP DATA packet. 487 The sequence number reported in the ACK_DATA must match with an 488 earlier sent HIP DATA packet that has not already been acknowledged. 489 If no match is found or if the ACK_DATA does not acknowledge a new 490 HIP DATA packet, the packet MUST either be dropped if no SEQ_DATA 491 parameter is present, or the processing steps in Section 4.3.1 are 492 followed. 494 The system MUST verify the SIGNATURE in the HIP DATA packet. If the 495 verification fails, the packet SHOULD be dropped and an error message 496 logged. 498 The corresponding DATA timer is stopped so that the now acknowledged 499 HIP DATA packet is no longer retransmitted. If multiple HIP DATA 500 packets are newly acknowledged, multiple timers are stopped. 502 5. Use of the HIP DATA Packet 504 HIP currently requires always that the four-message base exchange is 505 executed at the first encounter of hosts that have not communicated 506 before. This may add additional RTTs (Round Trip Time) to protocols 507 based on a single message exchange. However, the four-message 508 exchange is essential to preserve the half-stateless DoS protection 509 nature of the base exchange. The use of the HIP DATA packet defined 510 in this document reduces the initial overhead in the communications 511 between two hosts at the expense of decreasing DoS protection. 512 Therefore, applications SHOULD NOT use HIP DATA packets in 513 environments where DoS attacks are believed to be an issue. For 514 example, a HIP-based overlay may have policies in place to control 515 which nodes can join the overlay. Any particular node in the overlay 516 may want to accept HIP DATA packets from other nodes in the overlay 517 given that those other were authorized to join the overlay. However, 518 the same node may not want to accept HIP DATA packets from random 519 nodes that are not part of the overlay. 521 The type of data to be sent is also relevant to whether the use of a 522 HIP DATA packet is appropriate. HIP itself does not support 523 fragmentation but relies on underlying IP-layer fragmentation. This 524 may lead to reliability problems in the case where a message cannot 525 be easily split over multiple HIP messages. Therefore, applications 526 in environments where fragmentation could be an issue SHOULD NOT 527 generate too large HIP DATA packets that may lead to fragmentation. 528 The implementation SHOULD check the MTU of the link before sending 529 the packet and if the packet size is larger than MTU it SHOULD signal 530 to the upper-layer protocol if the packet results in to a ICMP error 531 message. Note that there are environments where fragmentation is not 532 an issue. For example, in some HIP-based overlays, nodes can 533 exchange HIP DATA packets on top of TCP connections that provide 534 transport-level fragmentation and, thus, avoid IP-level 535 fragmentation. 537 HIP currently requires that all messages excluding I1s but including 538 HIP DATA packets are digitally signed. This adds to the packet size 539 and the processing capacity needed to send packets. However, in 540 applications where security is not paramount, it is possible to use 541 very short keys, thereby reducing resource consumption. 543 6. Security considerations 545 HIP is designed to provide secure authentication of hosts. HIP also 546 attempts to limit the exposure of the host to various denial-of- 547 service and man-in-the-middle (MitM) attacks. However, HIP DATA 548 packet, which can be sent without running the HIP base exchange 549 between hosts has a trade off that it does not provide the denial-of- 550 service protection that HIP generally provides. Thus, the host 551 should consider always situations where it is appropriate to send or 552 receive HIP DATA packet. If the communication consists more than few 553 round-trips of data or the data is highly sensitive in nature the 554 host SHOULD run the base exchange with the peer host. 556 7. IANA considerations 558 This document updates the IANA Registry for HIP Packet types by 559 introducing new packet type for the new HIP_DATA (Section 3) packet. 560 This document updates the IANA Registry for HIP Parameter Types by 561 introducing new parameter values for the SEQ_DATA (Section 3.1), 562 ACK_DATA (Section 3.2), and PAYLOAD_HMAC (Section 3.3) parameters. 564 8. Acknowledgments 566 In the usual IETF fashion, a large number of people have contributed 567 to the actual text or ideas. The list of these people include Miika 568 Komu, Tobias Heer, Ari Keraenen, Samu Varjonen, Thomas Henderson, and 569 Jukka Ylitalo. Our apologies to anyone whose name is missing. 571 9. Informative references 573 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 574 "Host Identity Protocol", RFC 5201, April 2008. 576 [RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the 577 Encapsulating Security Payload (ESP) Transport Format with 578 the Host Identity Protocol (HIP)", RFC 5202, April 2008. 580 [RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End- 581 Host Mobility and Multihoming with the Host Identity 582 Protocol", RFC 5206, April 2008. 584 Authors' Addresses 586 Pekka Nikander 587 Ericsson 588 Hirsalantie 11 589 Jorvas 02420 590 Finland 592 Email: Pekka.Nikander@ericsson.com 594 Gonzalo Camarillo 595 Ericsson 596 Hirsalantie 11 597 Jorvas 02420 598 Finland 600 Email: Gonzalo.Camarillo@ericsson.com 602 Jan Melen 603 Ericsson 604 Hirsalantie 11 605 Jorvas 02420 606 Finland 608 Email: Jan.Melen@ericsson.com