idnits 2.17.1 draft-ietf-hip-hiccups-03.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 (July 7, 2010) is 5035 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: January 8, 2011 July 7, 2010 7 HIP (Host Identity Protocol) Immediate Carriage and Conveyance of Upper- 8 layer Protocol Signaling (HICCUPS) 9 draft-ietf-hip-hiccups-03 11 Abstract 13 This document defines a new HIP (Host Identity Protocol) packet type 14 called DATA. HIP DATA packets are used to reliably convey 15 authenticated arbitrary protocol messages over various overlay 16 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 January 8, 2011. 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 . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . 8 68 4.3. Definition of the PAYLOAD_MIC Parameter . . . . . . . . . 9 69 4.4. Definition of the TRANSACTION_ID Parameter . . . . . . . . 10 70 5. Generation and Reception of HIP DATA Packets . . . . . . . . . 10 71 5.1. Handling of SEQ_DATA and ACK_DATA . . . . . . . . . . . . 10 72 5.2. Generation of a HIP DATA packet . . . . . . . . . . . . . 11 73 5.3. Reception of a HIP DATA packet . . . . . . . . . . . . . . 12 74 5.3.1. Handling of SEQ_DATA in a Received HIP DATA packet . . 13 75 5.3.2. Handling of ACK_DATA in a Received HIP DATA packet . . 13 76 6. Use of the HIP DATA Packet . . . . . . . . . . . . . . . . . . 14 77 7. Security considerations . . . . . . . . . . . . . . . . . . . 15 78 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 16 79 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 81 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 82 10.2. Informative references . . . . . . . . . . . . . . . . . . 16 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 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 authenticated and reliable way) protocol messages to a 100 remote host without running the HIP base exchange between them. The 101 HIP DATA packet has following semantics: unordered, duplicate free, 102 reliable, and authenticated message-based delivery service. We also 103 discuss the trade offs involved in using this packet (i.e., less 104 overhead but also less DoS protection) and the situations where it is 105 appropriate to use this packet. The HIP_DATA packet is not intended 106 to be a replacement for the Encapsulating Security Payload (ESP) 107 transport instead it SHOULD NOT be used to exchange more than a few 108 packets between the peers. If a continuous communication is required 109 or communication that requires confidentiality protection then hosts 110 MUST run the HIP base exchange to set up ESP security association. 111 Additionally APIs to higher-level protocols that might use this 112 service are outside of the scope of this document. 114 2. Terminology 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in RFC 2119 [RFC2119]. 119 In addition this document uses the terms defined in [RFC5201]. 121 Message Integrity Code (MIC) is a collision-resistant hash sum 122 calculated over the message which is being integrity protected. 123 The MIC does not use secret keys and thus it needs additional 124 means to ensure that it has not been tampered with during 125 transmission. Essentially MIC is same as Message Authentication 126 Code (MAC) with the distinction that MIC does not use secret key. 127 MIC is also often referred as Integrity Check Value (ICV), 128 fingerprint, or unkeyed MAC. 130 3. Background on HIP 132 The HIP protocol specification [RFC5201] defines a number of messages 133 and parameters. The parameters are encoded as TLVs, as shown in 134 Section 3.1.2. Furthermore, the HIP header carries a Next Header 135 field, allowing other arbitrary packets to be carried within HIP 136 packets. 138 3.1. Message formats 140 3.1.1. HIP fixed header 142 The HIP packet format consists of a fixed header followed by a 143 variable number of parameters. The parameter format is described in 144 Section 3.1.2. 146 The fixed header is defined in Section 5.1 of [RFC5201] and copied 147 below. 149 0 1 2 3 150 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 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | Next Header | Header Length |0| Packet Type | VER. | RES.|1| 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Checksum | Controls | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Sender's Host Identity Tag (HIT) | 157 | | 158 | | 159 | | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Receiver's Host Identity Tag (HIT) | 162 | | 163 | | 164 | | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | | 167 / HIP Parameters / 168 / / 169 | | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 The HIP header is logically an IPv6 extension header. The HIP 173 protocol specification [RFC5201] defines handling only for Next 174 Header value decimal 59, IPPROTO_NONE [PROTOCOL-NUMBERS], the IPv6 175 'no next header' value. This document describes processing for Next 176 Header values other than decimal 59 which indicates that there are 177 either more extensions header and/or data following the HIP header. 179 3.1.2. HIP parameter format 181 The HIP parameter format is defined in Section 5.2.1 of [RFC5201], 182 and copied below. 184 0 1 2 3 185 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 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Type |C| Length | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | | 190 / Contents / 191 / +-+-+-+-+-+-+-+-+ 192 | | Padding | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 Type Type code for the parameter. 16 bits long, C-bit 196 being part of the Type code. 197 C Critical. One if this parameter is critical, and 198 MUST be recognized by the recipient, zero otherwise. 199 The C bit is considered to be a part of the Type 200 field. Consequently, critical parameters are always 201 odd and non-critical ones have an even value. 202 Length Length of the Contents, in octets. 203 Contents Parameter specific, defined by Type. 204 Padding Padding, 0-7 octets, added if needed. 206 3.2. HIP Base Exchange, Updates, and State Removal 208 The HIP base exchange is a four-message authentication and key 209 exchange protocol that creates shared, mutually authenticated keying 210 material at the communicating parties. These keying materials, 211 together with associated public keys and IP addresses, form a HIP 212 Security Association (SA). The details of the protocol are defined 213 in the HIP base exchange specification [RFC5201]. 215 In addition to creating the HIP SA, the base exchange messages may 216 carry additional parameters that are used to create additional state. 217 For example, the HIP ESP specification [RFC5202] defines how HIP can 218 be used to create end-to-end, host-to-host IPsec ESP Security 219 Associations, used to carry data packets. However, it is important 220 to understand that the HIP base exchange is by no means bound to 221 IPsec; using IPsec ESP to carry data traffic forms just a baseline 222 and ensures interoperability between initial HIP implementations. 224 Once there is a HIP SA between two HIP-enabled hosts, they can 225 exchange further HIP control messages. Typically, UPDATE messages 226 are used. For example, the HIP mobility and multihoming 227 specification [RFC5206] defines how to use UPDATE messages to change 228 the set of IP addresses associated with a HIP SA. 230 In addition to the base exchange and updates, the HIP base protocol 231 specification also defines how one can remove a HIP SA once it is no 232 longer needed. 234 4. Definition of the HIP DATA Packet 236 The HIP DATA packet can be used to convey protocol messages to a 237 remote host without running the HIP base exchange between them. HIP 238 DATA packets are transmitted reliably, as discussed in Section 5. 239 The payload of a HIP DATA packet is placed after the HIP header and 240 protected by a PAYLOAD_MIC parameter, which is defined in 241 Section 4.3. The following is the definition of the HIP DATA packet 242 (see definition of notation in [RFC5201] section 2.2): 244 Header: 245 Packet Type = [ TBD by IANA: 32 ] 246 SRC HIT = Sender's HIT 247 DST HIT = Receiver's HIT 249 IP ( HIP ( [HOST_ID, ] SEQ_DATA, PAYLOAD_MIC, [ PAYLOAD_MIC, ..., ] 250 HIP_SIGNATURE) PAYLOAD ) 252 IP ( HIP ( [HOST_ID, ] SEQ_DATA, ACK_DATA, PAYLOAD_MIC, 253 [ PAYLOAD_MIC, ..., ] HIP_SIGNATURE) PAYLOAD ) 255 IP ( HIP ( [HOST_ID, ] ACK_DATA, HIP_SIGNATURE)) 257 The SEQ_DATA and ACK_DATA parameters are defined in Section 4.1 and 258 Section 4.2 respectively. They are used to provide a reliable 259 delivery of HIP DATA packets, as discussed in Section 5. 261 The HOST_ID parameter is defined in Section 5.2.8 of [RFC5201]. This 262 parameter is the sender's Host Identifier that is used to compute the 263 HIP DATA packet's signature and to verify it against the received 264 signature. The HOST_ID parameter is optional as it MAY have been 265 delivered using out-of-band mechanism to the receiver. If host 266 doesn't have reliable information that the corresponding node has its 267 HOST_ID it MUST always include it in to the packet. If the receiver 268 is unable to verify the SIGNATURE then the packet MUST be dropped and 269 appropriate NOTIFY packet SHOULD be sent to the sender indicating 270 AUTHENTICATION_FAILED as described in [RFC5201] section 5.2.16. 272 The PAYLOAD_MIC parameter is defined in Section 4.3. This parameter 273 contains the MIC of the payload carried by the HIP DATA packet. The 274 PAYLOAD_MIC contains the collision-resistant hash of the payload 275 following after the HIP DATA. The PAYLOAD_MIC is included in the 276 signed part of the HIP DATA packet giving integrity protection also 277 for the payload carried after HIP DATA packet. 279 The HIP_SIGNATURE parameter is defined in Section 5.2.11. of 280 [RFC5201]. It contains a signature over the contents of the HIP DATA 281 packet. The calculation and verification of the signature is defined 282 Section 6.4.2. of [RFC5201] 284 Section 5.3 of [RFC5201] states the following: 286 In the future, an OPTIONAL upper-layer payload MAY follow the HIP 287 header. The Next Header field in the header indicates if there is 288 additional data following the HIP header. 290 We have chosen to place the payload after the HIP extension header 291 and only to place an MIC of the payload in to the HIP extension 292 header in a PAYLOAD_MIC parameter because that way the data integrity 293 is protected by a public key signature with the help of MIC. The 294 payload that is protected by the PAYLOAD_MIC parameter has been 295 linked to the appropriate upper-layer protocol by storing the upper- 296 layer protocol number, 8 octets of payload data, and by calculating a 297 hash sum (MIC) over the data. The HIP DATA packet MAY contain one or 298 more PAYLOAD_MIC parameters each bound to different next header type. 299 The hash algorithm used to generate MIC is same as the algorithm used 300 to generate the Host Identity Tag [RFC5201]. 302 Upper-layer protocol messages, such as overlay network control 303 traffic, sent in HIP DATA messages may need to be matched to 304 different transactions. For this purpose, a DATA message MAY also 305 contain a TRANSACTION_ID parameter. The identifier value is a 64-bit 306 unsigned integer in network-byte-order that is unique for each 307 transaction. A response to a request uses the same identifier value 308 allowing the receiver to match requests to responses. 310 4.1. Definition of the SEQ_DATA Parameter 312 The following is the definition of the SEQ_DATA parameter: 314 0 1 2 3 315 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 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Type | Length | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Sequence number | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 Type [ TBD by IANA: 323 4481 = (2^12 + 2^8 + 2^7 + 1) ] 324 Length 4 325 Sequence number 32-bit unsigned integer in network byte order which 326 MUST NOT reused before it has been acknowledged by 327 the receiver. 329 This parameter has critical bit set and if it is not supported by the 330 receiver packet MUST be dropped and appropriate NOTIFY packet SHOULD 331 be sent to the sender indicating UNSUPPORTED_CRITICAL_PARAMETER_TYPE 332 as described in [RFC5201] section 5.2.16. 334 4.2. Definition of the ACK_DATA Parameter 336 The following is the definition of the ACK_DATA parameter: 338 0 1 2 3 339 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 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Type | Length | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Acked Sequence number / 344 / / 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 Type [ TBD by IANA: 348 4545 = (2^12 + 2^8 + 2^7 + 2^6 + 1) ] 349 Length variable (multiple of 4) 350 Acked Sequence number A sequence of 32-bit unsigned integers in 351 network byte order corresponding to the 352 sequence numbers being acknowledged 354 This parameter has critical bit set and if it is not supported by the 355 receiver packet MUST be dropped and appropriate NOTIFY packet SHOULD 356 be sent to the sender indicating UNSUPPORTED_CRITICAL_PARAMETER_TYPE 357 as described in [RFC5201] section 5.2.16. 359 4.3. Definition of the PAYLOAD_MIC Parameter 361 The following is the definition of the PAYLOAD_MIC parameter: 363 0 1 2 3 364 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 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Type | Length | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Next header | Reserved | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Payload Data | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | | 373 / MIC Value / 374 / +-+-+-+-+-+-+-+-+ 375 | | Padding | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 Type [ TBD by IANA: 379 4577 = (2^12 + 2^8 + 2^7 + 2^6 + 2^5 + 1) ] 380 Length length in octets, excluding Type, Length, and 381 Padding. 382 Next Header Identifies the data that is protected by this MIC. 383 The values for this field are defined by IANA 384 "Protocol Numbers" [PROTOCOL-NUMBERS] 385 Payload Data 8 last octets of the payload data over which the 386 MIC is calculated. This field is used to 387 uniquely bind PAYLOAD_MIC parameter to next header, 388 in case there are multiple copies of same type. 389 MIC Value MIC computed over the data to which the Next 390 Header and Payload Data points. The size of 391 the MIC is the natural size of the computation 392 output depending on the function used. 394 This parameter has critical bit set and if it is not supported by the 395 receiver packet MUST be dropped and appropriate NOTIFY packet SHOULD 396 be sent to the sender indicating UNSUPPORTED_CRITICAL_PARAMETER_TYPE 397 as described in [RFC5201] section 5.2.16. 399 There is a theoretical possibility that when generating multiple 400 PAYLOAD_MIC parameters that will be carried in a single packet would 401 have identical Next Header and Payload Data fields thus it is 402 required that PAYLOAD_MIC parameters MUST follow the natural order of 403 extensions headers in the packet making it possible to bind 404 PAYLOD_MICs to correct payload data. In case the receiving host is 405 still unable to identify the payloads, it MUST drop the packet and 406 SHOULD send a NOTIFY packet to the sender indicating INVALID_SYNTAX 407 as described in [RFC5201] section 5.2.16. 409 4.4. Definition of the TRANSACTION_ID Parameter 411 The following is the definition of the TRANSACTION_ID parameter: 413 0 1 2 3 414 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 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Type | Length | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Identifier / 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 / | Padding | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 Type [ TBD by IANA; 424 4580 = (2^12 + 2^8 + 2^7 + 2^6 + 2^5 + 2^2 ) ] 425 Length Length of the Identifier in octets 426 Identifier The identifier value 427 Padding 0-7 octets of padding if needed 429 Figure 1: Format of the TRANSACTION_ID parameter 431 5. Generation and Reception of HIP DATA Packets 433 HIP DATA packets are transmitted reliably. Reliable delivery is 434 achieved through the use of retransmissions and of the SEQ_DATA and 435 ACK_DATA parameters. 437 5.1. Handling of SEQ_DATA and ACK_DATA 439 A HIP DATA packet MUST contain at least one of a SEQ_DATA or an 440 ACK_DATA parameter; if both parameters are missing, then packet MUST 441 be dropped as invalid. 443 A HIP DATA packet containing SEQ_DATA parameter MUST contain one or 444 more PAYLOAD_MIC parameter or otherwise packet MUST be dropped. The 445 presence of a SEQ_DATA parameter indicates that the receiver MUST ACK 446 the HIP DATA packet. A HIP DATA packet that does not contain a 447 SEQ_DATA parameter is simply an ACK of a previous HIP DATA packet and 448 MUST NOT be ACKed. 450 A HIP DATA packet containing ACK_DATA parameter echoes the SEQ_DATA 451 sequence numbers of the HIP DATA packet packets being acknowledged. 452 ACK_DATA parameter MUST acknowledge at least one SEQ_DATA sequence 453 number and MAY acknowledge multiple SEQ_DATA sequence numbers by 454 adding all of them to the ACK_DATA parameter 456 A HIP DATA packet MAY contain both a SEQ_DATA and an ACK_DATA 457 parameter. In this case, the ACK is being piggybacked on an outgoing 458 HIP DATA packet. In general, HIP DATA packets carrying SEQ_DATA 459 SHOULD be ACKed upon completion of the processing of the HIP DATA 460 packet. A host MAY choose to hold the HIP DATA packet carrying ACK 461 for a short period of time to allow for the possibility of 462 piggybacking the ACK parameter, in a manner similar to TCP delayed 463 acknowledgments. 465 5.2. Generation of a HIP DATA packet 467 When a host has upper-layer protocol data to send, it either runs the 468 HIP base exchange and sends the data over a SA, or sends the data 469 directly using a HIP DATA packet. Section 6 discusses when it is 470 appropriate to use each method. This section discusses the case when 471 the host chooses to use a HIP DATA packet to send the upper-layer 472 protocol data. 474 1. The host creates a HIP DATA packet that contains a SEQ_DATA 475 parameter. The host is free to choose any value for the SEQ_DATA 476 sequence number in the first HIP DATA packet it sends to a 477 destination. After that first packet, the host MUST choose the 478 value of the SEQ_DATA sequence number in subsequent HIP DATA 479 packets to the same destination so that no SEQ_DATA sequence 480 number is reused before the receiver has closed the processing 481 window for the previous packet using the same SEQ_DATA sequence 482 number. Practically, giving the values of the retransmission 483 timers used with HIP DATA packets, this means that hosts must 484 wait the maximum likely lifetime of the packet before reusing a 485 given SEQ_DATA sequence number towards a given destination. 486 However, it is not required for node to know the maximum packet 487 lifetime. Rather, it is assumed that the requirement can be met 488 by maintaining the value as a simple, 32-bit, "wrap-around" 489 counter, incremented each time a packet is sent. It is an 490 implementation choice whether to maintain a single counter for 491 the node or multiple counters (one for each source HIT, 492 destination HIT combination). 493 2. The host creates PAYLOAD_MIC parameter. MIC is a hash calculated 494 over the whole PAYLOAD which the Next Header field of PAYLOAD_MIC 495 parameter indicates. If there is multiple next header types 496 which the host wants to protect it SHOULD create separate 497 PAYLOAD_MIC parameter for each of these. The receiver MUST 498 validate all these MICs as described in Section 5.3.1. For 499 calculating MIC the host MUST use the same hash algorithm as the 500 one that has been used for generating the host's HIT as defined 501 in Section 3.2. of [RFC5201]. 503 3. The host creates HIP_SIGNATURE parameter. The signature is 504 calculated over the whole HIP envelope, excluding any parameters 505 after the HIP_SIGNATURE, as defined in Section 5.2.11. of 506 [RFC5201]. The receiver MUST validate this signature. It MAY 507 use either the HI in the packet or the HI acquired by some other 508 means. 509 4. The hosts sends the created HIP DATA packet and starts a DATA 510 timer. The default value for the timer is 3 seconds. If 511 multiple HIP DATA packets are outstanding, multiple timers are in 512 effect. 513 5. If the DATA timer expires, the HIP DATA packet is resent. The 514 HIP DATA packet can be resent DATA_RETRY_MAX times. The DATA 515 timer MUST be exponentially backed off for subsequent 516 retransmissions. If no acknowledgment is received from the peer 517 after DATA_RETRY_MAX times, the delivery of the HIP DATA packet 518 is considered unsuccessful and the application is notified about 519 the error. The DATA timer is canceled upon receiving an ACK from 520 the peer that acknowledges receipt of the HIP DATA packet. The 521 default value for DATA_RETRY_MAX SHOULD be 5 retries, but it MAY 522 be changed through local policy. 524 5.3. Reception of a HIP DATA packet 526 A host receiving a HIP DATA packet makes a decision whether to 527 process the packet or not. If the host, following its local policy, 528 suspects that this packet could be part of a DoS attack. The host 529 MAY respond with an R1 packet to the HIP DATA packet, if the packet 530 contained SEQ_DATA and PAYLOAD_MIC parameter, in order to indicate 531 that HIP base exchange MUST be completed before accepting payload 532 packets from the originator of the HIP DATA packet. If the host 533 chooses to respond to the HIP DATA with an R1 packet, it creates a 534 new R1 or selects a precomputed R1 according to the format described 535 in [RFC5201] Section 5.3.2. The host SHOULD drop the received data 536 packet if it responded with a R1 packet to the HIP_DATA packet. The 537 sender of HIP_DATA packet is responsible for retransmission of the 538 upper-layer protocol data after successful completion of the HIP Base 539 Exchange. 541 If the host, following its local policy, decides to process the 542 incoming HIP DATA packet, it processes it according to the following 543 rules: 545 1. If the HIP DATA packet contains a SEQ_DATA parameter and no 546 ACK_DATA parameter, the HIP DATA packet is processed and replied 547 to as described in Section 5.3.1. 548 2. If the HIP DATA packet contains an ACK_DATA parameter and no 549 SEQ_DATA parameter, the HIP DATA packet is processed as described 550 in Section 5.3.2. 552 3. If the HIP DATA packet contains both a SEQ_DATA parameter and an 553 ACK_DATA parameter, the HIP DATA packet is processed first as 554 described in Section 5.3.2 and then the rest of the HIP DATA 555 packet is processed and replied to as described in Section 5.3.1. 557 5.3.1. Handling of SEQ_DATA in a Received HIP DATA packet 559 The following steps define the conceptual processing rules for 560 handling a SEQ_DATA parameter in a received HIP DATA packet. 562 The system MUST verify the SIGNATURE in the HIP DATA packet. If the 563 verification fail, the packet SHOULD be dropped and an error message 564 logged. 566 If the value in the received SEQ_DATA and MIC value received 567 PAYLOAD_MIC corresponds to a HIP DATA packet that has recently been 568 processed, the packet is treated as a retransmission. The SIGNATURE 569 verification (next step) MUST NOT be skipped. (A byte-by-byte 570 comparison of the received and a stored packet would be adequate, 571 though.) It is recommended that a host cache HIP DATA packets sent 572 with ACKs to avoid the cost of generating a new ACK packet to respond 573 to a retransmitted HIP DATA packet. The host MUST acknowledge, 574 again, such (apparent) HIP DATA packet retransmissions but SHOULD 575 also consider rate-limiting such retransmission responses to guard 576 against replay attacks. 578 The system MUST verify the PAYLOAD_MIC by calculating MIC over the 579 PAYLOAD which the Next Header field indicates. For calculating the 580 MIC the host will use the same hash algorithm that has been used to 581 generate the sender's HIT as defined in Section 3.2. of [RFC5201]. 582 If the packet carried multiple PAYLOAD_MIC parameters each of them 583 are verified as described above. If one or more of the verification 584 fails, the packet SHOULD be dropped and an error message logged. 586 If a new SEQ parameter is being processed, the parameters in the HIP 587 DATA packet are then processed. 589 A HIP DATA packet with an ACK_DATA parameter is prepared and sent to 590 the peer. This ACK_DATA parameter may be included in a separate HIP 591 DATA packet or piggybacked in a HIP DATA packet with a SEQ_DATA 592 parameter. The ACK_DATA parameter MAY acknowledge more than one of 593 the peer's HIP DATA packets. 595 5.3.2. Handling of ACK_DATA in a Received HIP DATA packet 597 The following steps define the conceptual processing rules for 598 handling an ACK_DATA parameter in a received HIP DATA packet. 600 The system MUST verify the SIGNATURE in the HIP DATA packet. If the 601 verification fails, the packet SHOULD be dropped and an error message 602 logged. 604 The sequence numbers reported in the ACK_DATA must match with an 605 previously sent HIP DATA packet containing SEQ_DATA that has not 606 already been acknowledged. If no match is found or if the ACK_DATA 607 does not acknowledge a new HIP DATA packets, the packet MUST either 608 be dropped if no SEQ_DATA parameter is present, or the processing 609 steps in Section 5.3.1 are followed. 611 The corresponding DATA timer is stopped so that the now acknowledged 612 HIP DATA packet is no longer retransmitted. If multiple HIP DATA 613 packets are newly acknowledged, multiple timers are stopped. 615 6. Use of the HIP DATA Packet 617 HIP currently requires that the four-message base exchange is 618 executed at the first encounter of hosts that have not communicated 619 before. This may add additional RTTs (Round Trip Time) to protocols 620 based on a single message exchange. However, the four-message 621 exchange is essential to preserve the DoS protection nature of the 622 base exchange. The use of the HIP DATA packet defined in this 623 document reduces the initial overhead in the communications between 624 two hosts. However, the HIP DATA packet itself does not provide any 625 protection against DoS attacks. Therefore, the HIP DATA packet MUST 626 only be used in environment whose policies provide protection against 627 DoS attacks. For example, a HIP-based overlay may have policies in 628 place to control which nodes can join the overlay. Any particular 629 node in the overlay may want to accept HIP DATA packets from other 630 nodes in the overlay given that those other nodes were authorized to 631 join the overlay. However, the same node will not accept HIP DATA 632 packets from random nodes that are not part of the overlay. 633 Additionally, the HIP DATA packet itself does not provide 634 confidentiality for its payload. Therefore, the HIP DATA packet MUST 635 only be used in environments that provide a level of confidentiality 636 that is appropriate for the data to be transferred. For example, a 637 HIP-based overlay may only send HIP DATA packets over encrypted 638 connections between overlay nodes. 640 The type of data to be sent is also relevant to whether the use of a 641 HIP DATA packet is appropriate. HIP itself does not support 642 fragmentation but relies on underlying IP-layer fragmentation. This 643 may lead to reliability problems in the case where a message cannot 644 be easily split over multiple HIP messages. Therefore, applications 645 in environments where fragmentation could be an issue SHOULD NOT 646 generate too large HIP DATA packets that may lead to fragmentation. 648 The implementation SHOULD check the MTU of the link before sending 649 the packet and if the packet size is larger than MTU it SHOULD signal 650 to the upper-layer protocol if the packet results in to a ICMP error 651 message. Note that there are environments where fragmentation is not 652 an issue. For example, in some HIP-based overlays, nodes can 653 exchange HIP DATA packets on top of TCP connections that provide 654 transport-level fragmentation and, thus, avoid IP-level 655 fragmentation. 657 HIP currently requires that all messages excluding I1s but including 658 HIP DATA packets are digitally signed. This adds to the packet size 659 and the processing capacity needed to send packets. However, in 660 applications where security is not paramount, it is possible to use 661 very short keys, thereby reducing resource consumption. 663 7. Security considerations 665 HIP is designed to provide secure authentication of hosts. HIP also 666 attempts to limit the exposure of the host to various denial-of- 667 service and man-in-the-middle (MitM) attacks. However, HIP DATA 668 packet, which can be sent without running the HIP base exchange 669 between hosts has a trade off that it does not provide the denial-of- 670 service protection or confidentiality protection that HIP generally 671 provides. Thus, the host should consider always situations where it 672 is appropriate to send or receive HIP DATA packet. If the 673 communication consists more than few round-trips of data or the data 674 is highly sensitive in nature the host SHOULD run the base exchange 675 with the peer host. 677 HIP DATA packet is designed to protect hosts from second preimage 678 attacks allowing receiving host to be able to detect, if the message 679 was tampered during the transport. This property is also know as 680 weak-collision-resistance. If a host tries to generate a second 681 preimage it would need to generate such second image where 8 last 682 octets are matching with original message. 684 When handling the PAYLOAD_MIC parameter in the receiving host, using 685 the 8-last octets to identify the upper layer protocol doesn't give 686 any guarantee that the MIC would be correct thus an attacker could 687 send packets where the next header and last 8-octets matches to the 688 values carried by PAYLOAD_MIC parameter and thus it is always 689 mandatory to verify the MIC value by calculating the hash over the 690 payload. 692 8. IANA considerations 694 This document updates the IANA Registry for HIP Packet types by 695 introducing new packet type for the new HIP_DATA (Section 4) packet. 696 This document updates the IANA Registry for HIP Parameter Types by 697 introducing new parameter values for the SEQ_DATA (Section 4.1), 698 ACK_DATA (Section 4.2), PAYLOAD_MIC (Section 4.3), and TRANSACTION_ID 699 (Section 4.4) parameters. 701 9. Acknowledgments 703 Pekka Nikander was one of the original authors of the draft. Also, 704 in the usual IETF fashion, a large number of people have contributed 705 to the actual text or ideas. The list of these people include Miika 706 Komu, Tobias Heer, Ari Keranen, Samu Varjonen, Thomas Henderson, and 707 Jukka Ylitalo. Our apologies to anyone whose name is missing. 709 10. References 711 10.1. Normative References 713 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 714 Requirement Levels", BCP 14, RFC 2119, March 1997. 716 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 717 "Host Identity Protocol", RFC 5201, April 2008. 719 [PROTOCOL-NUMBERS] 720 IANA, "Protocol Numbers", 721 . 723 10.2. Informative references 725 [RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the 726 Encapsulating Security Payload (ESP) Transport Format with 727 the Host Identity Protocol (HIP)", RFC 5202, April 2008. 729 [RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End- 730 Host Mobility and Multihoming with the Host Identity 731 Protocol", RFC 5206, April 2008. 733 Authors' Addresses 735 Gonzalo Camarillo 736 Ericsson 737 Hirsalantie 11 738 Jorvas 02420 739 Finland 741 Email: Gonzalo.Camarillo@ericsson.com 743 Jan Melen 744 Ericsson 745 Hirsalantie 11 746 Jorvas 02420 747 Finland 749 Email: Jan.Melen@ericsson.com