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