idnits 2.17.1 draft-ietf-rohc-ipsec-extensions-hcoipsec-08.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 seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 15, 2010) is 5182 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '7' on line 497 ** Obsolete normative reference: RFC 4995 (ref. 'ROHC') (Obsoleted by RFC 5795) ** Obsolete normative reference: RFC 4306 (ref. 'IKEV2') (Obsoleted by RFC 5996) -- Possible downref: Non-RFC (?) normative reference: ref. 'IKEV2EXT' -- Obsolete informational reference (is this intentional?): RFC 4835 (ref. 'CRYPTO-ALG') (Obsoleted by RFC 7321) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Ertekin 3 Internet-Draft C. Christou 4 Intended status: Standards Track Booz Allen Hamilton 5 Expires: August 19, 2010 C. Bormann 6 Universitaet Bremen TZI 7 February 15, 2010 9 IPsec Extensions to Support Robust Header Compression over IPsec 10 draft-ietf-rohc-ipsec-extensions-hcoipsec-08 12 Abstract 14 Integrating Robust Header Compression (ROHC) with IPsec (ROHCoIPsec) 15 offers the combined benefits of IP security services and efficient 16 bandwidth utilization. However, in order to integrate ROHC with 17 IPsec, extensions to the SPD and SAD are required. This document 18 describes the IPsec extensions required to support ROHCoIPsec. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on August 19, 2010. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the BSD License. 58 This document may contain material from IETF Documents or IETF 59 Contributions published or made publicly available before November 60 10, 2008. The person(s) controlling the copyright in some of this 61 material may not have granted the IETF Trust the right to allow 62 modifications of such material outside the IETF Standards Process. 63 Without obtaining an adequate license from the person(s) controlling 64 the copyright in such materials, this document may not be modified 65 outside the IETF Standards Process, and derivative works of it may 66 not be created outside the IETF Standards Process, except to format 67 it for publication as an RFC or to translate it into languages other 68 than English. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 74 3. Extensions to IPsec Databases . . . . . . . . . . . . . . . . 3 75 3.1. Security Policy Database (SPD) . . . . . . . . . . . . . . 4 76 3.2. Security Association Database (SAD) . . . . . . . . . . . 5 77 4. Extensions to IPsec Processing . . . . . . . . . . . . . . . . 6 78 4.1. Identification of Header-Compressed Traffic . . . . . . . 6 79 4.2. Verifying the Integrity of Decompressed Packet Headers . . 6 80 4.2.1. ICV Computation and Integrity Verification . . . . . . 7 81 4.3. ROHC Segmentation and IPsec Tunnel MTU . . . . . . . . . . 8 82 4.4. Nested IPComp and ROHCoIPsec Processing . . . . . . . . . 9 83 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 85 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 86 Appendix A. ASN.1 representation for ROHCoIPsec . . . . . . . . . 11 87 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 88 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 89 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 92 1. Introduction 94 Using IPsec ([IPSEC]) protection offers various security services for 95 IP traffic. However, these benefits come at the cost of additional 96 packet headers, which increase packet overhead. By compressing the 97 inner headers of these packets, the integration of Robust Header 98 Compresion (ROHC, [ROHC]) with IPsec (ROHCoIPsec, [ROHCOIPSEC]) can 99 reduce the packet overhead associated with IPsec-protected flows. 101 IPsec-protected traffic is carried over Security Associations (SAs), 102 whose parameters are negotiated on a case-by-case basis. The 103 Security Policy Database (SPD) specifies the services that are to be 104 offered to IP datagrams, and the parameters associated with SAs that 105 have been established are stored in the Security Association Database 106 (SAD). For ROHCoIPsec, various extensions to the SPD and SAD that 107 incorporate ROHC-relevant parameters are required. 109 In addition, three extensions to IPsec processing are required. 110 First, a mechanism for identifying ROHC packets must be defined. 111 Second, a mechanism to ensure the integrity of the decompressed 112 packet is needed. Finally, the order of the inbound and outbound 113 processing must be enumerated when nesting IP Compression (IPComp 114 [IPCOMP]), ROHC, and IPsec processing. 116 2. Terminology 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in RFC 2119 [BRA97]. 122 3. Extensions to IPsec Databases 124 The following subsections specify extensions to the SPD and the SAD 125 that MUST be supported for ROHCoIPsec. The ROHCoIPsec fields in the 126 SPD are used to populate the ROHCoIPsec parameters in the SAD during 127 the initialization or rekey of a child SA. 129 It is noted that these extensions do not have any implications on 130 existing SPD fields or SAD parameters. Therefore, a ROHCoIPsec 131 implementation is backwards-compatible with an IPsec implementation 132 that does not support header compression. 134 Appendix A provides an example ASN.1 representation of a SPD that is 135 extended to support ROHC. 137 3.1. Security Policy Database (SPD) 139 In general, the SPD is responsible for specifying the security 140 services that are offered to IP datagrams. Entries in the SPD 141 specify how to derive the corresponding values for SAD entries. To 142 support ROHC, the SPD is extended to include per-channel ROHC 143 parameters. Together, the existing IPsec SPD parameters and the ROHC 144 parameters will dictate the security and header compression services 145 that are provided to packets. 147 The fields contained within each SPD entry are defined in RFC 4301 148 [IPSEC], Section 4.4.1.2. To support ROHC, several processing info 149 fields are added to the SPD; these fields contain information 150 regarding the ROHC profiles and channel parameters supported by the 151 local ROHC instance. 153 If the processing action associated with the selector sets is 154 PROTECT, then the processing info must be extended with the following 155 ROHC channel parameters: 157 MAX_CID: The field indicates the highest context ID that will be 158 decompressed by the local decompressor. MAX_CID MUST be at least 159 0 and at most 16383 (The value 0 implies having one context). 161 MRRU: The MRRU parameter indicates the size of the largest 162 reconstructed unit (in octets) that the local decompressor is 163 expected to reassemble from ROHC segments. This size includes the 164 CRC and the ROHC ICV. NOTE: Since in-order delivery of ROHC 165 packets cannot be guaranteed, the MRRU parameter SHOULD be set to 166 0 (as stated in Section 5.2.5.1 of RFC 4995 [ROHC] and Section 6.1 167 of RFC 5225 [ROHCV2]), which indicates that no segment headers are 168 allowed on the ROHCoIPsec channel. 170 PROFILES: This field is a list of ROHC profiles supported by the 171 local decompressor. Possible values for this list are contained 172 in the ROHC Profile Identifiers registry [ROHCPROF]. 174 In addition to these ROHC channel parameters, a ROHC Integrity 175 Algorithm and a ROHC ICV Length field MUST be included within the 176 SPD: 178 ROHC INTEGRITY ALGORITHM: This field is a list of integrity 179 algorithms supported by the ROHCoIPsec instance. This will be 180 used by the ROHC process to ensure that packet headers are 181 properly decompressed (see Section 4.2). Authentication 182 algorithms that MUST be supported are specified in the 183 "Authentication Algorithms" table in section 3.1.1 ("ESP 184 Encryption and Authentication Algorithms") of RFC 4835 [CRYPTO- 185 ALG] (or its successor). 187 ROHC ICV LENGTH: This field specifies the length of the ICV that 188 is used in conjunction with the ROHC Integrity Algorithm. 190 Several other ROHC channel parameters are omitted from the SPD, 191 because they are set implicitly. The omitted channel parameters are 192 LARGE_CIDS and FEEDBACK_FOR. The LARGE_CIDS channel parameter MUST 193 be set based on the value of MAX_CID (e.g. if MAX_CID is <= 15, 194 LARGE_CIDS is assumed to be 0). Finally, the ROHC FEEDBACK_FOR 195 channel parameter MUST be set to the ROHC channel associated with the 196 SA in the reverse direction. If an SA in the reverse direction does 197 not exist, the FEEDBACK_FOR channel parameter is not set, and ROHC 198 MUST NOT operate in bidirectional Mode. 200 3.2. Security Association Database (SAD) 202 Each entry within the SAD defines the parameters associated with each 203 established SA. Unless the "populate from packet" (PFP) flag is 204 asserted for a particular field, SAD entries are determined by the 205 corresponding SPD entries during the creation of the SA. 207 The data items contained within the SAD are defined in RFC 4301 208 [IPSEC], Section 4.4.2.1. To support ROHC, the SAD must include a 209 "ROHC Data Item"; this data item contains parameters used by ROHC 210 instance. The ROHC Data Item exists for both inbound and outbound 211 SAs. 213 The ROHC Data Item includes the ROHC channel parameters for the SA. 214 These channel parameters (i.e., MAX_CID, PROFILES, MRRU) are 215 enumerated above in Section 3.1. For inbound SAs, the ROHC Data Item 216 MUST specify the ROHC channel parameters that are used by the local 217 decompressor instance; conversely, for outbound SAs, the ROHC Data 218 Item MUST specify the ROHC channel parameters that are used by local 219 compressor instance. 221 In addition to these ROHC channel parameters, the ROHC Data Item for 222 both inbound and outbound SAs MUST include three additional 223 parameters. Specifically, these parameters store the integrity 224 algorithm, the algorithm's respective key, and the ICV length that is 225 used by the ROHC process (see Section 3.2). The integrity algorithm 226 and its associated key are used to calculate a ROHC ICV of the 227 specified length; this ICV is used to verify the packet headers post- 228 decompression. 230 Finally, for inbound SAs, the ROHC Data Item MUST include a 231 FEEDBACK_FOR parameter. The parameter is a reference to a ROHC 232 channel in the opposite direction (i.e., the outbound SA) between the 233 same compression endpoints. A ROHC channel associated with an 234 inbound SA and a ROHC channel associated with an outbound SA MAY be 235 coupled to form a Bi-directional ROHC channel as defined in Section 236 6.1 and Section 6.2 in RFC 3759 [ROHC-TERM]. 238 "ROHC Data Item" values MAY be initialized manually (i.e., 239 administratively configured for manual SAs), or initialized via a key 240 exchange protocol (e.g. IKEv2 [IKEV2]) that has been extended to 241 support the signaling of ROHC parameters [IKEV2EXT]. 243 4. Extensions to IPsec Processing 245 4.1. Identification of Header-Compressed Traffic 247 A "ROHC" protocol identifier is used to identify header-compressed 248 traffic on a ROHC-enabled SA. If an outbound packet has a compressed 249 header, the Next Header field of the security protocol header (e.g., 250 AH [AH], ESP [ESP]) MUST be set to the "ROHC" protocol identifier. 251 If the packet header has not been compressed by ROHC, the Next Header 252 field does not contain the "ROHC" protocol identifier. Conversely, 253 for an inbound packet, the value of the security protocol Next Header 254 field MUST be checked to determine if the packet includes a ROHC 255 header, in order to determine if it requires ROHC decompression. 257 Use of the "ROHC" protocol identifier for purposes other than 258 ROHCoIPsec is currently not defined. Future protocols that make use 259 of the allocation (e.g., other applications of ROHC in multi-hop 260 environments) require specification of the logical compression 261 channel between the ROHC compressor and decompressor. In addition, 262 these specifications will require the investigation of the security 263 considerations associated with use of the "ROHC" protocol identifier 264 outside the context of the next-header field of security protocol 265 headers. 267 4.2. Verifying the Integrity of Decompressed Packet Headers 269 As documented in Section 6.1.4 of [ROHCOIPSEC], ROHC is inherently a 270 lossy compression algorithm: the consequences of significant packet 271 reordering or loss between ROHC peers may include undetected 272 decompression failures, where erroneous packets are forwarded into 273 the protected domain. 275 To ensure that a decompressed header is identical to the original 276 header, ROHCoIPsec MAY use an additional Integrity Algorithm (and 277 respective key) to compute a second Integrity Check Value (ICV). 278 This ROHC ICV MUST be computed over the uncompressed IP header, as 279 well at the higher-layer headers and the packet payload. When 280 computed, the ICV is appended to the ROHC-compressed packet. At the 281 decompressor, the decompressed packet (including the uncompressed IP 282 header, higher-layer headers, and packet payload; but not including 283 the authentication data) will be used with the integrity algorithm 284 (and its respective key) to compute a value that will be compared to 285 the appended ICV. If these values are not identical, the 286 decompressed packet MUST be dropped. 288 Figure 1 illustrates the composition of a ROHCoIPsec-processed IPv4 289 packet. In the example, TCP/IP compression is applied, and the 290 packet is processed with tunnel mode ESP. 292 BEFORE COMPRESSION AND APPLICATION OF ESP 293 ---------------------------- 294 IPv4 |orig IP hdr | | | 295 |(any options)| TCP | Data | 296 ---------------------------- 298 AFTER ROHCOIPSEC COMPRESSION AND APPLICATION OF ESP 299 ------------------------------------------------------ 300 IPv4 | new IP hdr | | Cmpr. | | ROHC | ESP | ESP| 301 |(any options)| ESP | Hdr. |Data| ICV |Trailer| ICV| 302 ------------------------------------------------------ 304 Figure 1. Example of a ROHCoIPsec-processed packet. 306 Note: At the decompressor, the ROHC ICV field is not included in the 307 calculation of the ROHC ICV. 309 4.2.1. ICV Computation and Integrity Verification 311 In order to correctly verify the integrity of the decompressed 312 packets, the processing steps for ROHCoIPsec MUST be implemented in a 313 specific order, as given below. 315 For outbound packets that are processed by ROHC and IPsec-protected: 316 o Compute an ICV for the uncompressed packet with the negotiated 317 (ROHC) integrity algorithm and its respective key 318 o Compress the packet headers (as specified by the ROHC process) 319 o Append the ICV to the compressed packet 320 o Apply AH or ESP processing to the packet, as specified in the 321 appropriate SAD entry 323 For inbound packets that are to be decompressed by ROHC: 325 o Apply AH or ESP processing, as specified in the appropriate SAD 326 entry 327 o Remove the ICV from the packet 328 o Decompress the packet header(s) 329 o Compute an ICV for the decompressed packet with the negotiated 330 (ROHC) integrity algorithm and its respective key 331 o Compare the computed ICV to the original ICV calculated at the 332 compressor: if these two values differ, the packet MUST be 333 dropped; otherwise resume IPsec processing 335 4.3. ROHC Segmentation and IPsec Tunnel MTU 337 In certain scenarios, a ROHCoIPsec-processed packet may exceed the 338 size of the IPsec tunnel MTU. RFC 4301 [IPSEC] currently stipulates 339 the following for outbound traffic that exceeds the SA PMTU: 341 Case 1: Original (cleartext) packet is IPv4 and has the DF 342 bit set. The implementation should discard the packet 343 and send a PMTU ICMP message. 345 Case 2: Original (cleartext) packet is IPv4 and has the DF 346 bit clear. The implementation should fragment (before or 347 after encryption per its configuration) and then forward 348 the fragments. It should not send a PMTU ICMP message. 350 Case 3: Original (cleartext) packet is IPv6. The implementation 351 should discard the packet and send a PMTU ICMP message. 353 For the ROHCoIPsec processing model, there is one minor change to the 354 procedure stated above. This change applies to pre-encryption 355 fragmentation for Case 2. Since current ROHC compression profiles do 356 not support compression of IP packet fragments, pre-encryption 357 fragmentation MUST NOT occur before ROHC processing. 359 If the compressed packet exceeds the SA PMTU, and the MRRU is non- 360 zero, ROHC segmentation MAY be used to divide the packet, where each 361 segment conforms to the tunnel MTU. ROHC segmentation MUST occur 362 before AH or ESP processing. Because in-order delivery of ROHC 363 segments is not guaranteed, the use of ROHC segmentation is not 364 recommended. 366 If segmentation is applied, the process MUST account for the 367 additional overhead imposed by the IPsec process (e.g., AH or ESP 368 overhead, crypto synchronization data, the additional IP header, 369 etc.) such that the final IPsec-processed segments are less than the 370 tunnel MTU. After segmentation, each ROHC segment is consecutively 371 processed by the appropriate security protocol (e.g., AH, ESP) 372 instantiated on the ROHC-enabled SA. Since ROHC segments are 373 processed consecutively, the associated AH/ESP sequence number MUST 374 be incremented by one for each segment transmitted over the ROHC 375 channel. As such, after all ROHC segments receive AH/ESP processing, 376 these segments can be identified (at the remote IPsec implementation) 377 by a range of contiguous AH/ESP sequence numbers. 379 For channels where the MRRU is non-zero, the ROHCoIPsec decompressor 380 MUST re-assemble the ROHC segments that are received. To accomplish 381 this, the decompressor MUST identify the ROHC segments (as documented 382 in Section 5.2.6 of RFC 4995 [ROHC]), and attempt reconstruction 383 using the ROHC segmentation protocol (Section 5.2.5 of RFC 4995 384 [ROHC]). To assist the reconstruction process, the AH/ESP sequence 385 number SHOULD be used to identify segments that may have been subject 386 to reordering. If reconstruction fails, the packet MUST be 387 discarded. 389 As stated in Section 3.2.1, if the ROHC integrity algorithm is used 390 to verify the decompression of packet headers, this ICV is appended 391 to the compressed packet. If ROHC segmentation is performed, the 392 segmentation algorithm is executed on the compressed packet and the 393 appended ICV. Note that the ICV is not appended to each ROHC 394 segment. 396 Under certain circumstances, IPsec implementations will not process 397 (or receive) unprotected ICMP messages, or they will not have a Path 398 MTU estimate value. In these cases, the IPsec implementation SHOULD 399 NOT attempt to segment the ROHC-compressed packet, as it does not 400 have full insight into the path MTU in the unprotected domain. 402 4.4. Nested IPComp and ROHCoIPsec Processing 404 IPComp ([IPCOMP]) is another mechanism that can be implemented to 405 reduce the size of an IP datagram. If IPComp and ROHCoIPsec are 406 implemented in a nested fashion, the following steps MUST be followed 407 for outbound and inbound packets. 409 For outbound packets that are to be processed by IPcomp and ROHC: 410 o The ICV is computed for the uncompressed packet, and the 411 appropriate ROHC compression profile is applied to the packet 412 o IPComp is applied, and the packet is sent to the IPsec process 413 o The security protocol is applied to the packet 415 Conversely, for inbound packets that are to be both ROHC- and IPcomp- 416 decompressed: 417 o A packet received on a ROHC-enabled SA is IPsec-processed 418 o The datagram is decompressed based on the appropriate IPComp 419 algorithm 421 o The packet is sent to the ROHC module for header decompression and 422 integrity verification 424 5. Security Considerations 426 A ROHCoIPsec implementer should consider the strength of protection 427 provided by the integrity check algorithm used to verify decompressed 428 headers. Failure to implement a strong integrity check algorithm 429 increases the probability for an invalidly decompressed packet to be 430 forwarded by a ROHCoIPsec device into a protected domain. 432 The implementation of ROHCoIPsec may increase the susceptibility for 433 traffic flow analysis, where an attacker can identify new traffic 434 flows by monitoring the relative size of the encrypted packets (i.e. 435 a group of "long" packets, followed by a long series of "short" 436 packets may indicate a new flow for some ROHCoIPsec implementations). 437 To mitigate this concern, ROHC padding mechanisms may be used to 438 arbitrarily add padding to transmitted packets to randomize packet 439 sizes. This technique, however, reduces the overall efficiency 440 benefit offered by header compression. 442 6. IANA Considerations 444 IANA is requested to allocate one value within the "Protocol Numbers" 445 registry [PROTOCOL] for "ROHC". This value will be used to indicate 446 that the next level protocol header is a ROHC header. 448 7. Acknowledgments 450 The authors would like to thank Mr. Sean O'Keeffe, Mr. James Kohler, 451 Ms. Linda Noone of the Department of Defense, and Mr. A. Rich Espy of 452 OPnet for their contributions and support for developing this 453 document. 455 The authors would also like to thank Mr. Yoav Nir, and Mr. Robert A 456 Stangarone Jr.: both served as committed document reviewers for this 457 specification. 459 Finally, the authors would like to thank the following for their 460 numerous reviews and comments to this document: 462 o Mr. Magnus Westerlund 463 o Dr. Stephen Kent 464 o Mr. Lars-Erik Jonsson 465 o Mr. Carl Knutsson 466 o Mr. Pasi Eronen 467 o Dr. Jonah Pezeshki 468 o Mr. Tero Kivinen 469 o Dr. Joseph Touch 470 o Mr. Rohan Jasani 471 o Mr. Elwyn Davies 472 o Mr. Bert Wijnen 474 Appendix A. ASN.1 representation for ROHCoIPsec 476 This appendix is included as an additional way to describe the 477 ROHCoIPsec parameters that are included in the IPsec SPD. It uses 478 portions of the ASN.1 syntax provided in Appendix C of RFC 4301 479 [IPSEC]. In addition, several new structures are defined. 481 This syntax has been successfully compiled. However, it is merely 482 illustrative and need not be employed in an implementation to achieve 483 compliance. 485 The "Processing" data structure, defined in Appendix C of RFC 4301, 486 is augmented to include a ROHC parameters element as follows: 488 Processing ::= SEQUENCE { 489 extSeqNum BOOLEAN, -- TRUE 64 bit counter, FALSE 32 bit 490 seqOverflow BOOLEAN, -- TRUE rekey, FALSE terminate & audit 491 fragCheck BOOLEAN, -- TRUE stateful fragment checking, 492 -- FALSE no stateful fragment checking 493 lifetime SALifetime, 494 spi ManualSPI, 495 algorithms ProcessingAlgs, 496 tunnel TunnelOptions OPTIONAL, 497 rohc [7] RohcParams OPTIONAL 499 } 501 The following data structures describe these ROHC parameters: 503 RohcParams ::= SEQUENCE { 504 rohcEnabled BOOLEAN, -- TRUE, hdr compr. is enabled 505 -- FALSE, hdr compr. is disabled 506 maxCID INTEGER (0..16383), 507 mrru INTEGER, 508 profiles RohcProfiles, 509 rohcIntegAlg RohcIntegAlgs, 510 rohcIntegICVLength INTEGER 511 } 513 RohcProfiles ::= SET OF RohcProfile 515 RohcProfile ::= INTEGER { 516 rohcv1-rtp (1), 517 rohcv1-udp (2), 518 rohcv1-esp (3), 519 rohcv1-ip (4), 521 rohcv1-tcp (6), 522 rohcv1-rtp-udpLite (7), 523 rohcv1-udpLite (8), 525 rohcv2-rtp (257), 526 rohcv2-udp (258), 527 rohcv2-esp (259), 528 rohcv2-ip (260), 530 rohcv2-rtp-udpLite (263), 531 rohcv2-udpLite (264) 533 -- values taken from [ROHCPROF] 535 } 537 RohcIntegAlgs ::= SEQUENCE { 538 algorithm RohcIntegAlgType, 539 parameters ANY -- DEFINED BY algorithm -- OPTIONAL } 541 RohcIntegAlgType ::= INTEGER { 542 none (0), 543 auth-HMAC-MD5-96 (1), 544 auth-HMAC-SHA1-96 (2), 545 auth-DES-MAC (3), 546 auth-KPDK-MD5 (4), 547 auth-AES-XCBC-96 (5), 548 auth-HMAC-MD5-128 (6), 549 auth-HMAC-SHA1-160 (7), 550 auth-AES-CMAC-96 (8), 551 auth-AES-128-GMAC (9), 552 auth-AES-192-GMAC (10), 553 auth-AES-256-GMAC (11), 554 auth-HMAC-SHA2-256-128 (12), 555 auth-HMAC-SHA2-384-192 (13), 556 auth-HMAC-SHA2-512-256 (14) 557 -- tbd (15..65535) 558 -- values taken from "Transform Type 3 - Integrity 559 -- Algorithm Transform IDs" at [IKEV2-PARA] 561 } 563 8. References 565 8.1. Normative References 567 [IPSEC] Kent, S. and K. Seo, "Security Architecture for the 568 Internet Protocol", RFC 4301, December 2005. 570 [ROHC] Jonsson, L-E., Pelletier, G., and K. Sandlund, "The RObust 571 Header Compression (ROHC) Framework", RFC 4995, July 2007. 573 [IPCOMP] Shacham, A., Monsour, R., Pereira, and Thomas, "IP Payload 574 Compression Protocol (IPComp)", RFC 3173, September 2001. 576 [BRA97] Bradner, S., "Key words for use in RFCs to Indicate 577 Requirement Levels", RFC 2119, March 1997. 579 [ROHCV2] Pelletier, G. and K. Sandlund, "RObust Header Compression 580 Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and 581 UDP-Lite", RFC 5225. 583 [IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 584 RFC 4306, December 2005. 586 [IKEV2EXT] 587 Ertekin, et al., "IKEv2 Extensions to Support Robust 588 Header Compression over IPsec (ROHCoIPsec)", work in 589 progress , February 2010. 591 [AH] Kent, S., "IP Authentication Header", RFC 4302, 592 December 2005. 594 [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", 595 RFC 4303, December 2005. 597 8.2. Informative References 599 [ROHCOIPSEC] 600 Ertekin, E., Jasani, R., Christou, C., and C. Bormann, 601 "Integration of Header Compression over IPsec Security 602 Associations", work in progress , February 2010. 604 [ROHCPROF] 605 "RObust Header Compression (ROHC) Profile Identifiers", 606 www.iana.org/assignments/rohc-pro-ids , May 2008. 608 [CRYPTO-ALG] 609 Manral, V., "Cryptographic Algorithm Implementation 610 Requirements for Encapsulating Security Payload (ESP) and 611 Authentication Header (AH)", RFC 4835, April 2007. 613 [ROHC-TERM] 614 Jonsson, L-E., "Robust Header Compression (ROHC): 615 Terminology and Channel Mapping Examples", RFC 3759, 616 April 2004. 618 [PROTOCOL] 619 IANA, ""Assigned Internet Protocol Numbers", IANA registry 620 at: http://www.iana.org/assignments/protocol-numbers". 622 [IKEV2-PARA] 623 IANA, "IKEv2 Parameters, 624 http://www.iana.org/assignments/ikev2-parameters", 625 November 2009. 627 Authors' Addresses 629 Emre Ertekin 630 Booz Allen Hamilton 631 5220 Pacific Concourse Drive, Suite 200 632 Los Angeles, CA 90045 633 US 635 Email: ertekin_emre@bah.com 637 Chris Christou 638 Booz Allen Hamilton 639 13200 Woodland Park Dr. 640 Herndon, VA 20171 641 US 643 Email: christou_chris@bah.com 644 Carsten Bormann 645 Universitaet Bremen TZI 646 Postfach 330440 647 Bremen D-28334 648 Germany 650 Email: cabo@tzi.org