idnits 2.17.1 draft-ietf-rohc-hcoipsec-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 522. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 533. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 540. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 546. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 1, 2007) is 6173 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'IPCOMP' is defined on line 463, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 4306 (ref. 'IKEV2') (Obsoleted by RFC 5996) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 8 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: Informational R. Jasani 5 Expires: December 3, 2007 Booz Allen Hamilton 6 June 1, 2007 8 Integration of Robust Header Compression (RoHC) over IPsec Security 9 Associations 10 draft-ietf-rohc-hcoipsec-05 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on December 3, 2007. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 IP Security (IPsec) provides various security services for IP 44 traffic. However, the benefits of IPsec come at the cost of 45 increased overhead. This document outlines a framework for 46 integrating Robust Header Compression (RoHC) over IPsec (RoHCoIPsec). 47 By compressing the inner headers of IP packets, RoHCoIPsec proposes 48 to reduce the amount of overhead associated with the transmission of 49 traffic over IPsec Security Associations (SAs). 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Audience . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Problem Statement: IPsec Packet Overhead . . . . . . . . . 4 57 5. Overview of the RoHCoIPsec Framework . . . . . . . . . . . 4 58 5.1. RoHCoIPsec Assumptions . . . . . . . . . . . . . . . . . . 5 59 5.2. Summary of the RoHCoIPsec Framework . . . . . . . . . . . 5 60 6. Details of the RoHCoIPsec Framework . . . . . . . . . . . 6 61 6.1. RoHC and IPsec Integration . . . . . . . . . . . . . . . . 6 62 6.1.1. Header Compression Protocol Considerations . . . . . . . . 8 63 6.1.2. Initialization and Negotiation of the RoHC Channel . . . . 9 64 6.1.3. Encapsulation and Identification of Header Compressed 65 Packets . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 6.2. RoHCoIPsec Framework Summary . . . . . . . . . . . . . . . 10 67 7. Security Considerations . . . . . . . . . . . . . . . . . 10 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . 10 69 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 10 70 10. Informative References . . . . . . . . . . . . . . . . . . 11 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 12 72 Intellectual Property and Copyright Statements . . . . . . 13 74 1. Introduction 76 This document outlines a framework for integrating RoHC [ROHC] over 77 IPsec [IPSEC] (RoHCoIPsec). The goal of RoHCoIPsec is to reduce the 78 protocol overhead associated with packets traversing between IPsec SA 79 endpoints. This can be achieved by compressing the transport layer 80 header (e.g., UDP, TCP, etc.) and inner IP header of packets at the 81 ingress of the IPsec tunnel, and decompressing these headers at the 82 egress. 84 For RoHCoIPsec, this document assumes that RoHC will be used to 85 compress the inner headers of IP packets traversing an IPsec tunnel. 86 However, since current specifications for RoHC detail its operation 87 on a hop-by-hop basis, it may require extensions to enable its 88 operation over IPsec SAs. This document outlines a framework for 89 extending the usage of RoHC to operate at IPsec SA endpoints. 91 RoHCoIPsec targets the application of RoHC to tunnel mode SAs. 92 Transport mode SAs only encrypt/authenticate the payload of an IP 93 packet, leaving the IP header untouched. Intermediate routers 94 subsequently use this IP header to route the packet to a decryption 95 device. Therefore, if RoHC is to operate over IPsec transport-mode 96 SAs, (de)compression functionality can only be applied to the 97 transport layer headers, and not to the IP header. Because current 98 RoHC specifications do not include support for the compression of 99 transport layer headers alone, the RoHCoIPsec framework outlined by 100 this document describes the application of RoHC to tunnel mode SAs. 102 2. Audience 104 The authors target members of both the RoHC and IPsec communities who 105 may consider extending the RoHC and IPsec protocols to meet the 106 requirements put forth in this document. In addition, this document 107 is directed towards vendors developing IPsec devices that will be 108 deployed in bandwidth-constrained IP networks. 110 3. Terminology 112 Terminology specific to RoHCoIPsec is introduced in this section. 114 Compressed Traffic 116 Traffic that is processed by a RoHC compressor. Packet headers 117 are compressed using a RoHC profile. 119 Uncompressed Traffic 120 Traffic that is not processed by the RoHC compressor. Instead, 121 this type of traffic bypasses the RoHC process. 123 RoHC Process 125 Generic reference to either the ROHC compressor or decompressor. 127 IPsec Process 129 Generic reference to the IPsec process defined in [IPSEC]. 131 Next Header 133 Refers to the Protocol (IPv4) or Next Header (IPv6, Extension) 134 field. 136 4. Problem Statement: IPsec Packet Overhead 138 IPsec mechanisms provide various security services for IP networks. 139 However, the benefits of IPsec come at the cost of increased per- 140 packet overhead. For example, traffic flow confidentiality 141 (generally leveraged at security gateways) requires the tunneling of 142 IP packets between IPsec implementations. Although these IPsec 143 tunnels will effectively mask the source-destination patterns that an 144 intruder can ascertain, tunneling comes at the cost of increased per- 145 packet overhead. Specifically, an ESP tunnel mode SA applied to an 146 IPv6 flow results in at least 50 bytes of additional overhead per 147 packet. This additional overhead may be undesirable for many 148 bandwidth-constrained wireless and/or satellite communications 149 networks, as these types of infrastructure are not overprovisioned. 150 RoHC applied on a per-hop basis over bandwidth-constrained links will 151 also suffer from reduced performance when encryption is used on the 152 tunneled header, since encrypted headers can not be compressed. 153 Consequently, the additional overhead incurred by an IPsec tunnel may 154 result in the inefficient utilization of bandwidth. 156 Packet overhead is particularly significant for traffic profiles 157 characterized by small packet payloads (e.g. various voice codecs). 158 In addition, if these small packets are afforded the security 159 services of an IPsec tunnel mode SA, the amount of per-packet 160 overhead is increased. Thus, a mechanism is needed to reduce the 161 overhead associated with such flows. 163 5. Overview of the RoHCoIPsec Framework 164 5.1. RoHCoIPsec Assumptions 166 The goal of RoHCoIPsec is to provide efficient transport of IP 167 packets between IPsec devices, without compromising the security 168 services offered by IPsec. As such, the RoHCoIPsec framework has 169 been developed based on the following assumptions: 170 o RoHC will be leveraged to reduce the amount of overhead associated 171 with packets traversing an IPsec SA 172 * Support for legacy HC algorithms (e.g. IPHC, CRTP, ECRTP) over 173 IPsec may be provided through the specification of new RoHC 174 profiles (e.g. [ROHC-CRTP]) 175 o RoHC will be instantiated at the IPsec SA endpoints, and will be 176 applied on a per-SA basis 178 5.2. Summary of the RoHCoIPsec Framework 180 RoHC reduces packet overhead in a network by exploiting intra- and 181 inter-packet redundancies of network and transport-layer header 182 fields of a flow. 184 Current RoHC protocol specifications compress packet headers on a 185 hop-by-hop basis. However, IPsec SAs are instantiated between two 186 IPsec implementations, with multiple hops between the IPsec 187 implementations. Therefore, various extensions to both RoHC and 188 IPsec may need to be defined to ensure its successful operation at 189 IPsec SA endpoints. 191 The migration of RoHC over IPsec SAs is straightforward, since SA 192 endpoints provide source/destination pairs where (de)compression 193 operations can take place. Compression in such a manner offers a 194 reduction of per-packet protocol overhead between the two SA 195 endpoints, and does not require compression and decompression cycles 196 at the intermediate hops between IPsec implementations. Since RoHC 197 will now essentially operate over multiple hops, it is imperative to 198 ensure that its performance will not be severely impacted due to 199 increased packet reordering and/or packet loss between the compressor 200 and decompressor. 202 In addition, RoHC can no longer rely on the underlying link layer for 203 RoHC parameter configuration and packet identification. The 204 RoHCoIPsec framework proposes that RoHC channel parameter 205 configuration is accomplished by an SA management protocol (e.g., 206 IKEv2 [IKEV2]), while identification of compressed header packets is 207 achieved through the Next Header field of the security protocol 208 (e.g., AH [AH], ESP [ESP]) header. 210 Using the RoHCoIPsec framework proposed below, outbound IP traffic 211 processing at an IPsec device is augmented to compress appropriate 212 packet headers, and subsequently encrypt and/or integrity-protect the 213 packet. For tunnel mode SAs, compression may be applied to the 214 transport layer protocol and the inner IP header. 216 Inbound IP traffic processing at an IPsec device is modified in a 217 similar fashion. For inbound packets, an IPsec device must first 218 decrypt and/or integrity-check the packet. Then, the IPsec device 219 determines if the packet was received on an RoHC-enabled SA (see 220 Section 6.1) and if the packet maintains compressed headers. If both 221 of these conditions are met, decompression of the inner packet 222 headers is performed. After decompression, the packet is checked 223 against the access controls imposed on all inbound traffic associated 224 with the SA (as specified in [IPSEC]). 226 Note: Compression of inner headers is independent from compression 227 of the security protocol (e.g., ESP) and outer IP headers. RoHC 228 is capable of compressing the security protocol and the outer IP 229 header on a hop-by-hop basis. 231 If IPsec NULL encryption is applied to packets, RoHC may still be 232 applied to the inner headers at the IPsec SA endpoints. Inbound and 233 outbound packets are still processed as was previously described. 235 6. Details of the RoHCoIPsec Framework 237 6.1. RoHC and IPsec Integration 239 Figure 1 illustrates the components required to integrate RoHC with 240 the IPsec process, i.e., RoHCoIPsec. 242 +-------------------------------+ 243 | RoHC Module | 244 | | 245 | | 246 +-----+ | +-----+ +---------+ | 247 | | | | | | RoHC | | 248 --| A |---------| B |-----| Process |------> Path 1 249 | | | | | | | | (RoHC-enabled SA) 250 +-----+ | +-----+ +---------+ | 251 | | | | 252 | | |-------------------------> Path 2 253 | | | (RoHC-enabled SA) 254 | +-------------------------------+ 255 | 256 | 257 | 258 | 259 +-----------------------------------------> Path 3 260 (RoHC-disabled SA) 262 Figure 1: Integration of RoHC with IPsec. 264 The process illustrated in Figure 1 augments the IPsec processing 265 model for outbound IP traffic (protected-to-unprotected). Initial 266 IPsec processing is consistent with [IPSEC] (Steps 1-2, Section 5.1). 267 The RoHC data item (part of the SA state information) retrieved from 268 the "relevant SAD entry" ([IPSEC], Section 5.1, Step3a) determines if 269 the traffic traversing the SA is handed to the RoHC module (Figure 1, 270 decision block A). Packets selected to a RoHC-disabled SA must 271 follow normal IPsec processing and must not be sent to the RoHC 272 module (Figure 1, Path 3). Conversely, packets selected to a RoHC- 273 enabled SA must be sent to the RoHC module. The decision at block B 274 then determines if the packet can be compressed. If it is determined 275 that the packet will be compressed, the Next Header field of the 276 security protocol header (e.g., ESP, AH) is populated with a "RoHC" 277 identifier, and packet headers are compressed (Figure 1, Path 1). 278 However, if it is determined that the packet will not be compressed 279 (e.g., due to one the reasons described in Section 6.1.3), the Next 280 Header field is populated with the appropriate value indicating the 281 next level protocol (Figure 1, Path 2). After the RoHC process 282 completes, IPsec processing resumes, as described in Section 5.1, 283 Step3a, of [IPSEC] (specifically, "IPsec processing is as previously 284 defined..."). 286 The process illustrated in Figure 1 also augments the IPsec 287 processing model for inbound IP traffic (unprotected-to-protected). 288 For inbound packets, IPsec processing is performed ([IPSEC], Section 289 5.2, Steps 1-3) followed by AH or ESP processing ([IPSEC], Section 290 5.2, Step 4) . After AH or ESP processing, the RoHC data item 291 retrieved from the SAD entry will indicate if traffic traversing the 292 SA is handed to the RoHC module ([IPSEC], Section 5.2, Step 3a). 293 Packets traversing an RoHC-disabled SA must follow normal IPsec 294 processing and must not be sent to the RoHC module. Conversely, 295 packets traversing an RoHC-enabled SA must be sent to the RoHC 296 module. The decision at block B is determined by the value of the 297 Next Header field of the security protocol header. If a RoHC header 298 is indicated, decompression is applied (Figure 1, Path 1). However, 299 if the Next Header field does not indicate a RoHC header, the 300 decompressor must not attempt decompression (Figure 1, Path 2). Once 301 the RoHC module completes processing, IPsec processing resumes, as 302 described in Section 5.2, Step 4 of [IPSEC] (specifically "Then match 303 the packet against the inbound selectors identified by the SAD ..."). 305 Note that to further reduce the size of an IPsec-protected packet, 306 RoHCoIPsec and IPcomp can be implemented in a nested fashion. For an 307 outbound packet, IPcomp is initially applied. Following the 308 application of IPcomp, the packet is sent to the RoHC module. Then, 309 the RoHC module may compress the headers (e.g., the IP header) of the 310 IPcomp-processed packet. After the RoHC process completes, IPsec 311 processing resumes. For inbound packets, these steps are reversed: 312 first, the packet is IPsec-processed; then, headers are decompressed; 313 last, the payload of the packet is decompressed based on the 314 appropriate IPcomp algorithm. 316 6.1.1. Header Compression Protocol Considerations 318 The initial specification of RoHC [ROHC] may need to be extended to 319 operate efficiently over IPsec SAs. Specifically, compressor and 320 decompressor implementations must account for increased tolerance to 321 packet reordering and packet loss, and should minimize the amount of 322 feedback sent from the decompressor to the compressor. To address 323 this need, RoHCv2 [ROHCV2] defines various mechanisms that provide 324 increased robustness during these scenarios. Furthermore, within the 325 context of IPsec, a RoHCv2 implementation can leverage additional 326 mechanisms to improve performance over channels characterized by 327 packet reordering/loss. For example, various security protocols are 328 equipped with a sequence number that may be used by the decompressor 329 to identify a packet as "sequentially late". This knowledge can be 330 utilized to increase the likelihood of successful decompression of a 331 reordered packet. 333 Additionally, RoHC implementations should minimize the amount of 334 feedback between decompressor and compressor. If a feedback channel 335 from the decompressor to the compressor is not used sparingly, the 336 overall gains from RoHCoIPsec can be significantly reduced. For 337 example, assume that RoHC is operating in bi-directional reliable 338 mode, and is instantiated over an IPsec tunnel mode SA. In this 339 scenario, any feedback sent from the decompressor to the compressor 340 must be tunneled. As such, the additional overhead incurred by 341 tunneling feedback will reduce the overall benefits of RoHC. 343 6.1.2. Initialization and Negotiation of the RoHC Channel 345 RoHC uses the underlying link layer (e.g., PPP) to negotiate RoHC 346 channel parameters. In the case of RoHCoIPsec, channel parameters 347 are negotiated by another mechanism. Specifically, initialization of 348 the RoHC channel is either achieved manually (i.e., administratively 349 configured for manual SAs), or is performed by IPsec SA establishment 350 protocols. The extensions required for IKEv2 to support RoHC 351 parameter negotiation are detailed in [IKE-ROHC]. 353 If the RoHC protocol requires bi-directional communications, two SAs 354 must be instantiated between the IPsec implementations. One of the 355 two SAs is used for carrying RoHC-traffic from the compressor to the 356 decompressor, while the other is used to communicate RoHC-feedback 357 from the decompressor to the compressor. Note that the requirement 358 for two SAs aligns with the operation of IKE, which creates SAs in 359 pairs. However, IPsec implementations will dictate how decompressor 360 feedback received on one SA is associated with a compressor on the 361 other SA. 363 6.1.3. Encapsulation and Identification of Header Compressed Packets 365 As indicated in Section 6.1, new state information (i.e., a new RoHC 366 data item) is defined for each SA. The RoHC data item is used by the 367 IPsec process to determine whether it sends all traffic traversing a 368 given SA to the RoHC module (RoHC-enabled) or bypasses the RoHC 369 module and sends the traffic through regular IPsec processing (RoHC- 370 disabled). 372 The Next Header field of the IPsec security protocol (e.g., AH or 373 ESP) header is used to demultiplex header-compressed traffic from 374 uncompressed traffic traversing an RoHC-enabled SA. This 375 functionality is needed in situations where packets traversing a 376 RoHC-enabled SA do not contain compressed headers. Such situations 377 may occur when, for example, a compressor supports strictly n 378 compressed flows and can not compress the n+1 flow that arrives. 379 Another example is when traffic (e.g., TCP/IP) is selected (by IPsec) 380 to a RoHC-enabled SA, but cannot be compressed by the RoHC process 381 (e.g., because the compressor does not support TCP/IP compression). 382 In these situations, the compressor must indicate that the packet 383 contains uncompressed headers. Similarly, the decompressor must be 384 able to identify packets with uncompressed headers and not attempt to 385 decompress them. The Next Header field is used to demultiplex these 386 header-compressed versus uncompressed packets, as a RoHC protocol 387 identifier will indicate the packet contains compressed headers. To 388 accomplish this, an official IANA allocation from the ProtocolID 389 registry [PROTOCOL] is required. 391 The RoHC Data Item, IANA ProtocolID allocation, and other IPsec 392 extensions to support RoHCoIPsec, are specified in [IPSEC-ROHC]. 394 6.2. RoHCoIPsec Framework Summary 396 To summarize, the following items are needed to achieve RoHCoIPsec: 397 o IKEv2 Extensions to Support RoHCoIPsec 398 o IPsec Extensions to Support RoHCoIPsec 400 7. Security Considerations 402 A malfunctioning RoHC compressor (i.e., the compressor located at the 403 ingress of the IPsec tunnel) has the ability to send packets to the 404 decompressor (i.e., the decompressor located at the egress of the 405 IPsec tunnel) that do not match the original packets emitted from the 406 end-hosts. Such a scenario will result in a decreased efficiency 407 between compressor and decompressor. Furthermore, this may result in 408 Denial of Service, as the decompression of a significant number of 409 invalid packets may drain the resources of an IPsec device. 411 8. IANA Considerations 413 None. 415 9. Acknowledgments 417 The authors would like to thank Mr. Sean O'Keeffe, Mr. James Kohler, 418 and Ms. Linda Noone of the Department of Defense, and well as Mr. 419 Rich Espy of OPnet for their contributions and support in the 420 development of this document. In addition, the authors would like to 421 thank the following for their numerous reviews and comments to this 422 document: 424 o Dr. Stephen Kent 425 o Dr. Carsten Bormann 426 o Mr. Tero Kivinen 427 o Mr. Lars-Erik Jonsson 428 o Mr. Jan Vilhuber 429 o Mr. Dan Wing 430 o Mr. Kristopher Sandlund 431 o Mr. Ghyslain Pelletier 433 Finally, the authors would also like to thank Mr. Tom Conkle, Ms. 434 Renee Esposito, Mr. Etzel Brower, Dr. Jonah Pezeshki, and Ms. Michele 435 Casey of Booz Allen Hamilton for their assistance in completing this 436 work. 438 10. Informative References 440 [ROHC] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 441 Hannu, H., Jonsson, L., Hakenberg, R., Koren, T., Le, K., 442 Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 443 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 444 Compression (RoHC): Framework and four profiles: RTP, UDP, 445 ESP, and uncompressed", RFC 3095, July 2001. 447 [IPSEC] Kent, S. and K. Seo, "Security Architecture for the 448 Internet Protocol", RFC 4301, December 2005. 450 [ROHC-CRTP] 451 Bormann, et al., "A RoHC Profile for CRTP (RoHC-CRTP)", 452 work in progress , February 2007. 454 [IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 455 RFC 4306, December 2005. 457 [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", 458 RFC 4303, December 2005. 460 [AH] Kent, S., "IP Authentication Header", RFC 4302, 461 December 2005. 463 [IPCOMP] Shacham, A., Monsour, R., Pereira, and Thomas, "IP Payload 464 Compression Protocol (IPComp)", RFC 3173, September 2001. 466 [ROHCV2] Pelletier, G. and K. Sandlund, "RObust Header Compression 467 Version 2 (RoHCv2): Profiles for RTP, UDP, IP, ESP, and 468 UDP-Lite", work in progress , May 2007. 470 [IKE-ROHC] 471 Pezeshki, et al., "IKEv2 Extensions to Support 472 RoHCoIPsec", work in progress , February 2007. 474 [PROTOCOL] 475 IANA, ""Assigned Internet Protocol Numbers", IANA registry 476 at: http://www.iana.org/assignments/protocol-numbers". 478 [IPSEC-ROHC] 479 Ertekin, et al., "IPsec Extensions to Support RoHCoIPsec", 480 work in progress , February 2007. 482 Authors' Addresses 484 Emre Ertekin 485 Booz Allen Hamilton 486 13200 Woodland Park Dr. 487 Herndon, VA 20171 488 US 490 Email: ertekin_emre@bah.com 492 Chris Christou 493 Booz Allen Hamilton 494 13200 Woodland Park Dr. 495 Herndon, VA 20171 496 US 498 Email: christou_chris@bah.com 500 Rohan Jasani 501 Booz Allen Hamilton 502 13200 Woodland Park Dr. 503 Herndon, VA 20171 504 US 506 Email: jasani_rohan@bah.com 508 Full Copyright Statement 510 Copyright (C) The IETF Trust (2007). 512 This document is subject to the rights, licenses and restrictions 513 contained in BCP 78, and except as set forth therein, the authors 514 retain all their rights. 516 This document and the information contained herein are provided on an 517 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 518 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 519 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 520 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 521 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 522 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 524 Intellectual Property 526 The IETF takes no position regarding the validity or scope of any 527 Intellectual Property Rights or other rights that might be claimed to 528 pertain to the implementation or use of the technology described in 529 this document or the extent to which any license under such rights 530 might or might not be available; nor does it represent that it has 531 made any independent effort to identify any such rights. Information 532 on the procedures with respect to rights in RFC documents can be 533 found in BCP 78 and BCP 79. 535 Copies of IPR disclosures made to the IETF Secretariat and any 536 assurances of licenses to be made available, or the result of an 537 attempt made to obtain a general license or permission for the use of 538 such proprietary rights by implementers or users of this 539 specification can be obtained from the IETF on-line IPR repository at 540 http://www.ietf.org/ipr. 542 The IETF invites any interested party to bring to its attention any 543 copyrights, patents or patent applications, or other proprietary 544 rights that may cover technology that may be required to implement 545 this standard. Please address the information to the IETF at 546 ietf-ipr@ietf.org. 548 Acknowledgment 550 Funding for the RFC Editor function is provided by the IETF 551 Administrative Support Activity (IASA).