idnits 2.17.1 draft-irtf-nmrg-snmp-compression-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (20 June 1999) is 9070 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) == Missing Reference: '42' is mentioned on line 163, but not defined ** Obsolete normative reference: RFC 2393 (ref. '2') (Obsoleted by RFC 3173) ** Obsolete normative reference: RFC 2572 (ref. '3') (Obsoleted by RFC 3412) ** Downref: Normative reference to an Historic RFC: RFC 1157 (ref. '4') Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. Schoenwaelder, Editor 2 Internet-Draft TU Braunschweig 3 Expires December 1999 20 June 1999 5 SNMP Payload Compression 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC 2026. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html 28 Distribution of this document is unlimited. Please send comments to 29 the Network Management Research Group . 31 Copyright Notice 33 Copyright (C) The Internet Society (1999). All Rights Reserved. 35 Abstract 37 This memo defines a mechanism for lossless compression of SNMP 38 payloads. Compression is especially useful when retrieving large 39 amounts of data or when SNMP encryption is used. 41 Table of Contents 43 1 Introduction ................................................. 3 44 2 Requirements and Alternatives ................................ 3 45 2.1 Compression as an SNMPv3 Encryption Algorithm .............. 3 46 2.2 Indicating Compression in the msgFlags ..................... 4 47 2.3 Compression as a new PDU type .............................. 4 48 3 Acknowledgments .............................................. 6 49 4 References ................................................... 6 50 5 Editor's Address ............................................. 6 51 6 Full Copyright Statement ..................................... 7 53 1. Introduction 55 This memo defines a mechanism for lossless compression of SNMP 56 payloads. Compression is useful when retrieving large amounts of 57 management data since the BER encoding used by SNMP is not very space 58 efficient and the data tends to have a high degree of redundancy. 60 SNMP payload compression is especially useful when SNMP encryption is 61 used. Encrypting the SNMP payload causes the data to be random in 62 nature, rendering compression at lower protocol layers (e.g., IP 63 Payload Compression Protocol [2]) ineffective. If both compression 64 and encryption are required, compression MUST be applied before 65 encryption. 67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 68 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 69 document are to be interpreted as described in RFC 2119 [1]. 71 2. Requirements and Alternatives 73 A solution for SNMP payload compression has to satisfy the following 74 requirements: 76 - Compression must happen before encryption if compression is used 77 together with encryption. Compression is most useful if there are 78 regular pattern in the data. It is the nature of encryption 79 algorithms to destroy any regular pattern and hence encrypted data 80 does not compress very well. 82 - SNMP payload compression should support multiple compression 83 algorithms. This means that communicating SNMP engines must be able 84 to find agreement on the compression algorithm they are using. 85 Instead of carrying compression algorithm identifier in every 86 protocol message, it seems more effective to indicate compression 87 algorithms in a MIB module (similar to authentication or encryption 88 algorithms in SNMPv3). 90 2.1. Compression as an SNMPv3 Encryption Algorithm 92 The basic idea behind the first alternative is to treat compression 93 as an SNMPv3 encryption algorithm. This has the following advantages 94 / disadvantages: 96 + No change required to the SNMPv3 specifications. 98 - Support of N encryption algorithms and M compression algorithms 99 leads to N*M possible combinations. 101 - Compression requires authentication since there is no noAuthPriv 102 security level. 104 + Compression of the complete ScopedPDU. 106 - Does not work with older versions of SNMP (SNMPv1, SNMPv2c). 108 2.2. Indicating Compression in the msgFlags 110 To avoid some of the drawbacks of the previous approach, one can 111 treat compression independent of encryption by allocating an unused 112 bit in the msgFlags [3] to indicate whether compression is used or 113 not. However, RFC 2572 [3] says in section 6.4: 115 The remaining bits in msgFlags are reserved, and MUST be set to 116 zero when sending a message and SHOULD be ignored when receiving 117 a message. 119 Similarly, RFC 2572 [3] specifies in section 7.1 step 7) and in 120 section 7.2 step 5) that other bits msgFlags are set to zero or 121 ignored. This means that this alternative can not be supported by an 122 implementation which is compliant to RFC 2572 [3]. 124 In summary, this approach has the following advantages / 125 disadvantages: 127 - Not strictly compliant to the current SNMPv3 specifications. 129 + Combination of M compression and N encryption algorithms possible 130 without having to define N*M algorithms. 132 + Compression can be used with or without encryption or 133 authentication. 135 + Compression of the complete ScopedPDU. 137 - Does not work with older versions of SNMP (SNMPv1, SNMPv2c). 139 2.3. Compression as a new PDU type 141 The third alternative is to restrict compression to PDUs rather than 142 ScopedPDUs and to introduce a new PDU type for compressed payloads. 143 RFC 1157 [4] defines the SNMPv1 message header as follows: 145 Message ::= SEQUENCE { 146 version INTEGER { version-1(0) }, 147 community OCTET STRING, 148 data ANY -- e.g., PDUs if trivial authentication 149 -- is being used 150 } 152 Similarly, RFC 2572 [3] defines the ScopedPDU as follows: 154 ScopedPDU ::= SEQUENCE { 155 contextEngineID OCTET STRING, 156 contextName OCTET STRING, 157 data ANY -- e.g., PDUs as defined in RFC 1905 158 } 160 This means that a new PDU could be defined which holds the compressed 161 version of a PDU: 163 CompressedPDU ::= [42] IMPLICIT OCTET STRING 164 -- contains a compressed PDU 166 Its important to analyze how a compliant SNMP implementation behaves 167 when it receives an unknown PDU type. From a formal point of view, 168 any PDU which is a valid BER serialization of an ASN.1 type must be 169 accepted since the data portion is of the ASN.1 type ANY. In 170 practice, most SNMP implementations will only recognize the PDU types 171 defined in the SNMP specifications. 173 The SNMPv3 message processing model [3] defines in section 7.2 step 174 7) that parse errors while decoding the ScopedPDU cause the packet to 175 be discarded after incrementing snmpInASNParseErrs. Even an 176 implementation which is capable to decode arbitrary PDUs will have 177 problems to determine the pduType as defined in section 7.2 step 9). 178 This basically means that a compliant SNMPv3 engine will simply 179 discard compressed PDUs. 181 The SNMPv1 specification [4] defines in section 4.1 second step (4) 182 that parse errors while decoding the PDU will cause the SNMP engine 183 to drop the PDU. Hence, it can be expected that most implementations 184 will simply drop a compressed PDU. 186 In summary, this approach has the following advantages / 187 disadvantages: 189 - Not strictly compliant to the current SNMPv3 specifications. 191 + Combination of M compression and N encryption algorithms possible 192 without having to define N*M algorithms. 194 + Compression can be used with or without encryption or 195 authentication. 197 - Compression of the PDU rather than the ScopedPDU. 199 + Works with every version of SNMP. 201 3. Acknowledgments 203 This document is the result of discussions of the Network Management 204 Research Group (NMRG). Special thanks go to the following 205 participants for their comments and contributions: 207 Luca Deri, Jean-Philippe Martin-Flatin, Aiko Pras, Ron Sprenkels, 208 Bert Wijnen. 210 4. References 212 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 213 Levels", BCP 14, RFC 2119, March 1997. 215 [2] Shacham, A., Monsour, R., Pereira, R. and M. Thomas, "IP Payload 216 Compression Protocol (IPComp)", RFC 2393, December 1998. 218 [3] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, "Message 219 Processing and Dispatching for the Simple Network Management 220 Protocol (SNMP)", RFC 2572, April 1999. 222 [4] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "A Simple 223 Network Management Protocol (SNMP)", RFC 1157, May 1990. 225 5. Editor's Address 227 Juergen Schoenwaelder 228 TU Braunschweig 229 Bueltenweg 74/75 230 38106 Braunschweig 231 Germany 233 Phone: +49 531 391-3283 234 EMail: schoenw@ibr.cs.tu-bs.de 236 6. Full Copyright Statement 238 Copyright (C) The Internet Society (1999). All Rights Reserved. 240 This document and translations of it may be copied and furnished to 241 others, and derivative works that comment on or otherwise explain it 242 or assist in its implementation may be prepared, copied, published 243 and distributed, in whole or in part, without restriction of any 244 kind, provided that the above copyright notice and this paragraph are 245 included on all such copies and derivative works. However, this 246 document itself may not be modified in any way, such as by removing 247 the copyright notice or references to the Internet Society or other 248 Internet organizations, except as needed for the purpose of 249 developing Internet standards in which case the procedures for 250 copyrights defined in the Internet Standards process must be 251 followed, or as required to translate it into languages other than 252 English. 254 The limited permissions granted above are perpetual and will not be 255 revoked by the Internet Society or its successors or assigns. 257 This document and the information contained herein is provided on an 258 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 259 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 260 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 261 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 262 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.