idnits 2.17.1 draft-moskowitz-gpcomp-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 (June 27, 2017) is 2466 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) == Outdated reference: A later version (-24) exists of draft-ietf-hip-dex-05 == Outdated reference: A later version (-05) exists of draft-moskowitz-sse-04 == Outdated reference: A later version (-02) exists of draft-moskowitz-ssls-hip-01 -- Obsolete informational reference (is this intentional?): RFC 6536 (Obsoleted by RFC 8341) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Moskowitz 3 Internet-Draft S. Hares 4 Intended status: Standards Track Huawei 5 Expires: December 29, 2017 I. Faynberg 6 Stargazers Consulting, LLC 7 H. Lu 8 Retired 9 P. Giacomin 10 FreeLance 11 June 27, 2017 13 GPCOMP 14 draft-moskowitz-gpcomp-02.txt 16 Abstract 18 This document describes a protocol intended to provide lossless 19 compression for use within any datagram. It is particularly intended 20 for use in encrypted datagrams where lower-level compression is 21 ineffective. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on December 29, 2017. 40 Copyright Notice 42 Copyright (c) 2017 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 3 59 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 3 60 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Compression Process . . . . . . . . . . . . . . . . . . . . . 3 62 3.1. Compressed Payload . . . . . . . . . . . . . . . . . . . 3 63 3.2. Uncompressing Conundrum . . . . . . . . . . . . . . . . . 4 64 3.3. Non-Expansion Policy . . . . . . . . . . . . . . . . . . 4 65 4. Compressed Datagram Structure . . . . . . . . . . . . . . . . 5 66 4.1. Implied Structure . . . . . . . . . . . . . . . . . . . . 5 67 4.2. GPComp header for Explicit Structure . . . . . . . . . . 5 68 5. Negotiating GPComp . . . . . . . . . . . . . . . . . . . . . 5 69 5.1. The GPCA . . . . . . . . . . . . . . . . . . . . . . . . 6 70 5.2. Using IKEv2 . . . . . . . . . . . . . . . . . . . . . . . 6 71 5.3. Using HIP . . . . . . . . . . . . . . . . . . . . . . . . 6 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 74 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 77 9.2. Informative References . . . . . . . . . . . . . . . . . 7 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 80 1. Introduction 82 Generic payload compression is a protocol to reduce the size of most 83 datagrams. This protocol will increase the overall communication 84 performance by compressing the datagrams, provided the participating 85 devices have sufficient computation power, through either CPU 86 capacity or a compression coprocessor, and the communication is over 87 constrained links. 89 Generic payload compression is especially useful when encryption is 90 applied to datagrams. Encrypting a datagram causes the data to be 91 random in nature, rendering compression at lower protocol layers 92 ineffective. 94 This document defines the Generic payload compression protocol 95 (GPComp), a GPComp packet structure, the GPComp Association (GPCA), 96 and several methods to negotiate the GPCA. 98 Other documents shall specify how a specific compression algorithm 99 can be used with the Generic payload compression protocol. Such 100 algorithms are beyond the scope of this document. 102 This document draws heavily on IPCOMP [RFC3173]. 104 2. Terms and Definitions 106 2.1. Requirements Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC 2119 [RFC2119]. 112 2.2. Definitions 114 GPCA: The Generic Payload Compression Protocol Association. This is 115 the collection of attributes and values that define how GPComp 116 operates. 118 3. Compression Process 120 The compression processing has two phases: compressing of outbound 121 datagrams ("compression") and decompressing of inbound datagrams 122 ("decompression"). The compression processing MUST be lossless, 123 ensuring that the datagram, after being compressed and decompressed, 124 is identical to the original datagram. 126 Each datagram is compressed and decompressed by itself without any 127 relation to other datagrams ("stateless compression"), as datagrams 128 may arrive out of order or not arrive at all. 130 Processing of inbound datagrams MUST support both compressed and non- 131 compressed datagrams, in order to meet the non-expansion policy 132 requirements, as defined in Section 3.3. 134 3.1. Compressed Payload 136 Compression is applied to a single datagram. The size of a 137 compressed payload, generated by the compression algorithm, MUST be 138 in whole octet units. 140 As compression is optional for each datagram associated within the 141 GPCA, an identification mechanism is REQUIRED for each datagram. 142 Minimally this can be a single option bit within the datagram's 143 header (if it has one). Alternatively, the GPComp header, defined in 144 Section 4.2, is inserted immediately preceding the compressed 145 payload. The receiving side MUST be able to distinguish between 146 compressed and uncompressed payloads. 148 3.2. Uncompressing Conundrum 150 The receiver MUST be able to recognize the condition of no 151 compression for the case where there is no datagram header option 152 flag for compression and only the presense of the GPComp header 153 indicates a compressed payload. In this case, the payload itself has 154 no indication that GPComp is enabled for the payload, but there is 155 nothing to decompress. The receiving process has to be able to 156 identify the payload as lacking the GPComp header and act 157 appropriately. Thus it is best if there is a datagram header 158 compression flag (for example in SSE [I-D.moskowitz-sse]) and the 159 GPComp header is not even used. 161 3.3. Non-Expansion Policy 163 If the total size of a compressed payload and the GPComp header (if 164 present) is not smaller than the size of the original payload, the 165 datagram MUST be sent in the original non-compressed form. To 166 clarify: If an datagram is sent non-compressed, no GPComp header is 167 added to the datagram. This policy ensures saving the decompression 168 processing cycles and avoiding incurring datagram fragmentation if 169 the expanded datagram is larger than the MTU. It does present a 170 potential conundrum Section 3.2 to the receiver. 172 Small datagrams are likely to expand as a result of compression. 173 Therefore, a numeric threshold should be applied before compression, 174 where datagrams of size smaller than the threshold are sent in the 175 original form without attempting compression. The numeric threshold 176 is implementation dependent. 178 A datagram payload with compressed content tends not to compress any 179 further. The previously compressed payload may be the result of 180 external processes, such as compression applied by an upper layer in 181 the communication stack, or by an off-line compression utility. An 182 adaptive algorithm should be implemented to avoid the performance 183 hit. For example, if the compression of i consecutive IP datagrams 184 of an GPCA fails, the next several datagrams, say k, are sent without 185 attempting compression. If then the next j datagrams also fail to 186 compress, a larger number of datagrams, say k+n, are sent without 187 attempting compression. Once a datagram is compressed successfully, 188 the normal process of IPComp restarts. Such an adaptive algorithm, 189 including all the related thresholds, is implementation dependent. 191 During the processing of the payload, the compression algorithm MAY 192 periodically apply a test to determine the compressibility of the 193 processed data, similar to the requirements of [V42BIS]. The nature 194 of the test is algorithm dependent. Once the compression algorithm 195 detects that the data is non-compressible, the algorithm SHOULD stop 196 processing the data, and the payload is sent in the original non- 197 compressed form. 199 4. Compressed Datagram Structure 201 The compressed datagram structure for GPComp can be implied or 202 explicit. The implied structure is used with datagrams that have a 203 header field with option flags and a length field or end-of-datagram 204 identifier. The explicit structure uses the GPComp header. 206 4.1. Implied Structure 208 The implied structure takes one option flag bit in the datagram 209 header. This bit is ONE if that datagram is compressed or ZERO if 210 not compressed. The compression algorithm is specified within the 211 GPCA. The implied structure can be used within SSE. 213 4.2. GPComp header for Explicit Structure 215 The GPComp header is used for datagrams that do not have a defined 216 header with an options field, or do not have an available bit in the 217 header to flag compression status. IPFIX [RFC7011] and NETCONF 218 [RFC6536] use such a datagram. 220 The GPComp header is identical to the IPComp header [RFC3173]. This 221 is for done for simplicity sake. Although it is possible to design a 222 GPComp header of only 2 bytes, this would break the typical 32 bit 223 word alignment in Internet Protocol headers. In many uses, the Next 224 Header field will be NULL; this is set by the GPCA. 226 5. Negotiating GPComp 228 The use of GPComp and its options (e.g. compression algorithm) should 229 be part of the communication start up process. Although GPComp can 230 be manually set up, this may result in a lack of agility in 231 compression algorithm selection. That is, only one algorithm is used 232 and cannot easily be changed. Thus manual set up for GPComp should 233 be limited to testing needs. 235 An application may use any internal set up mechanism for negotiating 236 GPComp. However, as compression is frequently used in conjunction 237 with encryption, the application may call a Key Management Protocol 238 (KMP) and request that the KMP set up GPComp. 240 5.1. The GPCA 242 The GPCA is a data structure that controls the operation of GPComp. 243 The content of the GPCA is application dependent but it will always 244 include the Compression Parameter Index (CPI) as defined in IPCOMP. 246 5.2. Using IKEv2 248 At set up, and application may call IKEv2 [RFC7296]. This may be to 249 enable ESP in Transport Mode [RFC4303] or SSE for secure 250 communications. It the same time, IKE may be instructed to negotiate 251 IPCOMP, but the application will use the negotiated IPCOMP CPI for 252 GPComp. 254 5.3. Using HIP 256 At set up, and application may call HIPv2 [RFC7401] or HIP-DEX 257 [I-D.ietf-hip-dex]. This may be to enable ESP in BEET Mode [RFC7402] 258 or SSE for secure communications. 260 HIP does not currently include a negotiation for compression. A 261 GPCOMP_INFO parameter is proposed in [I-D.moskowitz-ssls-hip]. It is 262 unclear at this time if this could also be used for IPCOMP, or if a 263 separate parameter is needed for it. 265 6. IANA Considerations 267 In [I-D.moskowitz-ssls-hip], IANA is requested to assign a HIP 268 parameter value for the Compression Transform. 270 7. Security Considerations 272 TBD 274 8. Contributors 276 TBD 278 9. References 280 9.1. Normative References 282 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 283 Requirement Levels", BCP 14, RFC 2119, 284 DOI 10.17487/RFC2119, March 1997, 285 . 287 [RFC3173] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP 288 Payload Compression Protocol (IPComp)", RFC 3173, 289 DOI 10.17487/RFC3173, September 2001, 290 . 292 9.2. Informative References 294 [I-D.ietf-hip-dex] 295 Moskowitz, R. and R. Hummen, "HIP Diet EXchange (DEX)", 296 draft-ietf-hip-dex-05 (work in progress), February 2017. 298 [I-D.moskowitz-sse] 299 Moskowitz, R., Faynberg, I., Lu, H., Hares, S., and P. 300 Giacomin, "Session Security Envelope", draft-moskowitz- 301 sse-04 (work in progress), October 2016. 303 [I-D.moskowitz-ssls-hip] 304 Moskowitz, R., Xia, L., Faynberg, I., Hares, S., and P. 305 Giacomin, "Secure Session Layer Services KMP via HIP", 306 draft-moskowitz-ssls-hip-01 (work in progress), October 307 2016. 309 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 310 RFC 4303, DOI 10.17487/RFC4303, December 2005, 311 . 313 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 314 Protocol (NETCONF) Access Control Model", RFC 6536, 315 DOI 10.17487/RFC6536, March 2012, 316 . 318 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 319 "Specification of the IP Flow Information Export (IPFIX) 320 Protocol for the Exchange of Flow Information", STD 77, 321 RFC 7011, DOI 10.17487/RFC7011, September 2013, 322 . 324 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 325 Kivinen, "Internet Key Exchange Protocol Version 2 326 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 327 2014, . 329 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 330 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 331 RFC 7401, DOI 10.17487/RFC7401, April 2015, 332 . 334 [RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the 335 Encapsulating Security Payload (ESP) Transport Format with 336 the Host Identity Protocol (HIP)", RFC 7402, 337 DOI 10.17487/RFC7402, April 2015, 338 . 340 [V42BIS] CCITT, "Data Compression Procedures for Data Circuit 341 Terminating Equipment (DCE) Using Error Correction 342 Procedures", Recommendation V.42 bis, January 1990. 344 Authors' Addresses 346 Robert Moskowitz 347 Huawei 348 Oak Park, MI 48237 350 Email: rgm@labs.htt-consult.com 352 Susan Hares 353 Huawei 354 7453 Hickory Hill 355 Saline, MI 48176 356 USA 358 Email: shares@ndzh.com 360 Igor Faynberg 361 Stargazers Consulting, LLC 362 East Brunswick, NJ 08816 363 USA 365 Email: igorfaynberg@gmail.com 367 Huilan Lu 368 Retired 370 Email: huilanlu2@gmail.com 372 Pierpaolo Giacomin 373 FreeLance 375 Email: yrz@anche.no