idnits 2.17.1 draft-ietf-pppext-padding-ds-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 42 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([RFC-1661]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (August 1998) is 9386 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: 'DayDreamer' is mentioned on line 1, but not defined ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) Summary: 12 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group W A Simpson [DayDreamer] 2 Internet Draft 3 expires in six months August 1998 5 PPP LCP Self Describing Padding - 6 draft-ietf-pppext-padding-ds-01.txt | 8 Status of this Memo 10 This document is an Internet-Draft. Internet Drafts are working doc- - 11 uments of the Internet Engineering Task Force (IETF), its Areas, and 12 its Working Groups. Note that other groups may also distribute work- 13 ing documents as Internet Drafts. 15 Internet Drafts are draft documents valid for a maximum of six 16 months, and may be updated, replaced, or obsoleted by other documents 17 at any time. It is not appropriate to use Internet Drafts as refer- 18 ence material, or to cite them other than as a ``working draft'' or 19 ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow 23 Directories on: 25 ftp.is.co.za (Africa) 26 nic.nordu.net (Northern Europe) | 27 ftp.nis.garr.it (Southern Europe) | 28 ftp.ietf.org (Eastern USA) | 29 ftp.isi.edu (Western USA) | 30 munnari.oz.au (Pacific Rim) 32 Distribution of this memo is unlimited. 34 Copyright Notice 36 Copyright (C) William Allen Simpson (1992-1994, 1996-1998). All 37 Rights Reserved. 39 Abstract 41 The Point-to-Point Protocol (PPP) [RFC-1661] provides a standard | 42 method for transporting multi-protocol datagrams over point-to-point 43 links. PPP defines an extensible Link Control Protocol (LCP) for 44 establishing, configuring, and testing the data-link connection. | 45 This document defines the Self-Describing-Padding option. 47 1. Introduction 49 Each octet of padding contains the index of that octet. The first 50 pad octet contains the value one (1). The final pad octet indicates 51 the number of pad octets to remove. For example, three pad octets 52 would contain the values 1, 2, and 3. 54 On receipt, when any of the pad octets contain an incorrect index 55 value, the entire frame SHOULD be silently discarded. 57 Rationale: 59 The first octet value of one (1) indicates the PPP Padding Proto- 60 col to the LCP Compound-Frames option (specified elsewhere). 62 After removing the PPP FCS, the remaining final octet will indi- 63 cate the correct number of octets to remove. Together with check- 64 ing the pad values, this is intended to prevent confusion when 65 used with the LCP FCS-Alternatives option (specified elsewhere). 67 1.1. Terminology 69 In this document, the key words "MAY", "MUST", "MUST NOT", and + 70 "SHOULD", are to be interpreted as described in [RFC-2119]. + 72 2. Additional LCP Configuration Options 74 The Configuration Option format and basic options are already defined 75 for LCP [RFC-1661]. | 77 Up-to-date values of the LCP Option Type field are specified in the | 78 most recent "Assigned Numbers" [RFC-1700]. This document concerns 79 the following values: 81 10 Self-Describing-Padding 83 2.1. Self-Describing-Padding - 85 Description 87 This Configuration Option provides a method for an implementation 88 to indicate to the peer that it understands self-describing pads 89 when padding is added at the end of the PPP Information field. 91 This option is most likely to be used when some protocols, such as 92 network-layer or compression protocols, are configured that 93 require detection and removal of any trailing padding. Such spe- 94 cial protocols are identified in their respective documents. 96 Nota Bene: 98 This does not mean that Self-Describing-Padding is mentioned in 99 the protocol documents. A length dependency requiring detec- 100 tion and removal of trailing padding is specified in such pro- 101 tocol documents. It is the responsibility of each protocol to 102 distinguish padding octets from real information [RFC-1661 page | 103 5]. 105 By design, the receiver need not check padding for those proto- 106 cols that do not need the padding removed. 108 If the option is Configure-Reject'd, the peer MUST NOT add any 109 padding to any identified special protocols, but MAY add padding 110 to other protocols. 112 If the option is Ack'd, the peer MUST follow the procedures for 113 adding self-describing pads, but only to the specifically identi- 114 fied protocols. The peer is not required to add any padding to 115 other protocols. 117 Rationale: 119 This is defined so that the Configure-Reject handles either 120 case where the peer does not generate self-describing pads. 121 When the peer never generates padding, it may safely Configure- 122 Reject the option. When the peer does not understand the 123 option, it also will not successfully configure a special pro- 124 tocol which requires elimination of padding. 126 Some senders might only be capable of either adding padding to 127 every protocol or not adding padding to any protocol. Any 128 implementation that generates padding, and has a protocol con- 129 figured which requires the padding to be detected, SHOULD 130 include this Option in its Configure-Request, and SHOULD Con- 131 figure-Nak with this Option when it is not present in the 132 peer's Configure-Request. 134 The Maximum-Pad-Value (MPV) is also negotiated. Only the values | 135 one (1) through MPV are used for padding. 137 When no padding would otherwise be required, but the final octet 138 of the PPP Information field contains the value 1 through MPV, at 139 least one self-describing pad octet MUST be added to the frame. 141 If the final octet is zero (0), or is greater than MPV, no addi- 142 tional padding is required. 144 Rationale: 146 Since this option is intended to support compression protocols, 147 the Maximum-Pad-Value is specified to limit the likelihood that 148 a frame might actually become longer. 150 A summary of the Self-Describing-Padding Configuration Option format 151 is shown below. The fields are transmitted from left to right. 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - 154 | Type | Length | Maximum | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 Type 159 10 161 Length 163 3 165 Maximum 167 This field specifies the largest number of padding octets that may 168 be added to the frame. The value may range from 0 to 255. 170 The value 0 indicates that Self-Defining-Padding is understood, 171 but no padding is expected. A peer that needs to send padding 172 SHOULD Configure-Nak with an appropriate value. 174 Values of 2, 4, or 8 are most likely. 176 Security Considerations 178 When used with encryption protocols, checking the pad values provides 179 a simple integrity facility, and avoids a possible covert channel. 180 This small amount of known plaintext does not create any problems for 181 modern ciphers. 183 Changes from RFC-1570 + 185 LCP Configuration Options were removed to separate documents. + 187 Minor reorganization. Abbreviations have been expanded. Additional + 188 Rationale has been added. + 190 Acknowledgements 192 Self-Describing-Padding was suggested and named by Fred Baker. 194 Special thanks to Ascend Communications for providing computing 195 resources and network access support for writing this specification. 197 References 199 [RFC-1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", 200 STD-51, DayDreamer, July 1994. | 202 [RFC-1700] Reynolds, J.K., Postel, J.B., "Assigned Numbers", STD-2, | 203 USC/Information Sciences Institute, October 1994. | 205 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 206 Requirement Levels", BCP-14, Harvard University, March | 207 1997. 209 Contacts 211 Comments about this document should be discussed on the ietf- 212 ppp@merit.edu mailing list. 214 This document was reviewed by the Point-to-Point Protocol Working | 215 Group of the Internet Engineering Task Force (IETF). The working 216 group can be contacted via the current chair: 218 Karl Fox 219 Ascend Communications 220 3518 Riverside Drive Suite 101 221 Columbus, Ohio 43221 223 karl@Ascend.com - 225 Questions about this document can also be directed to: 227 William Allen Simpson 228 DayDreamer 229 Computer Systems Consulting Services 230 1384 Fontaine 231 Madison Heights, Michigan 48071 233 wsimpson@UMich.edu 234 wsimpson@GreenDragon.com (preferred) 236 Full Copyright Statement + 238 Copyright (C) William Allen Simpson (1992-1994, 1996-1998). All + 239 Rights Reserved. + 241 This document and translations of it may be copied and furnished to + 242 others, and derivative works that comment on or otherwise explain it + 243 or assist in its implementation may be prepared, copied, published + 244 and distributed, in whole or in part, without restriction of any + 245 kind, provided that the above copyright notice and this paragraph are + 246 included on all such copies and derivative works. However, this doc- + 247 ument itself may not be modified in any way, except as required to + 248 translate it into languages other than English. + 250 This document and the information contained herein is provided on an + 251 "AS IS" basis and the author(s) DISCLAIM ALL WARRANTIES, EXPRESS OR + 252 IMPLIED, INCLUDING (BUT NOT LIMITED TO) ANY WARRANTY THAT THE USE OF + 253 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + 254 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.