Network Working Group W A Simpson [DayDreamer] Internet Draft expires in six months August 1998 PPP LCP Self Describing Padding - draft-ietf-pppext-padding-ds-01.txt | Status of this Memo This document is an Internet-Draft. Internet Drafts are working doc- - uments of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute work- ing documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months, and may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as refer- ence material, or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow Directories on: ftp.is.co.za (Africa) nic.nordu.net (Northern Europe) | ftp.nis.garr.it (Southern Europe) | ftp.ietf.org (Eastern USA) | ftp.isi.edu (Western USA) | munnari.oz.au (Pacific Rim) Distribution of this memo is unlimited. Copyright Notice Copyright (C) William Allen Simpson (1992-1994, 1996-1998). All Rights Reserved. Abstract The Point-to-Point Protocol (PPP) [RFC-1661] provides a standard | method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection. | This document defines the Self-Describing-Padding option. Simpson expires in six months [Page i] DRAFT PPP SDP August 1998 1. Introduction Each octet of padding contains the index of that octet. The first pad octet contains the value one (1). The final pad octet indicates the number of pad octets to remove. For example, three pad octets would contain the values 1, 2, and 3. On receipt, when any of the pad octets contain an incorrect index value, the entire frame SHOULD be silently discarded. Rationale: The first octet value of one (1) indicates the PPP Padding Proto- col to the LCP Compound-Frames option (specified elsewhere). After removing the PPP FCS, the remaining final octet will indi- cate the correct number of octets to remove. Together with check- ing the pad values, this is intended to prevent confusion when used with the LCP FCS-Alternatives option (specified elsewhere). 1.1. Terminology In this document, the key words "MAY", "MUST", "MUST NOT", and + "SHOULD", are to be interpreted as described in [RFC-2119]. + 2. Additional LCP Configuration Options The Configuration Option format and basic options are already defined for LCP [RFC-1661]. | Up-to-date values of the LCP Option Type field are specified in the | most recent "Assigned Numbers" [RFC-1700]. This document concerns the following values: 10 Self-Describing-Padding 2.1. Self-Describing-Padding - Description This Configuration Option provides a method for an implementation to indicate to the peer that it understands self-describing pads when padding is added at the end of the PPP Information field. This option is most likely to be used when some protocols, such as Simpson expires in six months [Page 1] DRAFT PPP SDP August 1998 network-layer or compression protocols, are configured that require detection and removal of any trailing padding. Such spe- cial protocols are identified in their respective documents. Nota Bene: This does not mean that Self-Describing-Padding is mentioned in the protocol documents. A length dependency requiring detec- tion and removal of trailing padding is specified in such pro- tocol documents. It is the responsibility of each protocol to distinguish padding octets from real information [RFC-1661 page | 5]. By design, the receiver need not check padding for those proto- cols that do not need the padding removed. If the option is Configure-Reject'd, the peer MUST NOT add any padding to any identified special protocols, but MAY add padding to other protocols. If the option is Ack'd, the peer MUST follow the procedures for adding self-describing pads, but only to the specifically identi- fied protocols. The peer is not required to add any padding to other protocols. Rationale: This is defined so that the Configure-Reject handles either case where the peer does not generate self-describing pads. When the peer never generates padding, it may safely Configure- Reject the option. When the peer does not understand the option, it also will not successfully configure a special pro- tocol which requires elimination of padding. Some senders might only be capable of either adding padding to every protocol or not adding padding to any protocol. Any implementation that generates padding, and has a protocol con- figured which requires the padding to be detected, SHOULD include this Option in its Configure-Request, and SHOULD Con- figure-Nak with this Option when it is not present in the peer's Configure-Request. The Maximum-Pad-Value (MPV) is also negotiated. Only the values | one (1) through MPV are used for padding. When no padding would otherwise be required, but the final octet of the PPP Information field contains the value 1 through MPV, at least one self-describing pad octet MUST be added to the frame. Simpson expires in six months [Page 2] DRAFT PPP SDP August 1998 If the final octet is zero (0), or is greater than MPV, no addi- tional padding is required. Rationale: Since this option is intended to support compression protocols, the Maximum-Pad-Value is specified to limit the likelihood that a frame might actually become longer. A summary of the Self-Describing-Padding Configuration Option format is shown below. The fields are transmitted from left to right. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type | Length | Maximum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 10 Length 3 Maximum This field specifies the largest number of padding octets that may be added to the frame. The value may range from 0 to 255. The value 0 indicates that Self-Defining-Padding is understood, but no padding is expected. A peer that needs to send padding SHOULD Configure-Nak with an appropriate value. Values of 2, 4, or 8 are most likely. Security Considerations When used with encryption protocols, checking the pad values provides a simple integrity facility, and avoids a possible covert channel. This small amount of known plaintext does not create any problems for modern ciphers. Simpson expires in six months [Page 3] DRAFT PPP SDP August 1998 Changes from RFC-1570 + LCP Configuration Options were removed to separate documents. + Minor reorganization. Abbreviations have been expanded. Additional + Rationale has been added. + Acknowledgements Self-Describing-Padding was suggested and named by Fred Baker. Special thanks to Ascend Communications for providing computing resources and network access support for writing this specification. References [RFC-1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD-51, DayDreamer, July 1994. | [RFC-1700] Reynolds, J.K., Postel, J.B., "Assigned Numbers", STD-2, | USC/Information Sciences Institute, October 1994. | [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP-14, Harvard University, March | 1997. Simpson expires in six months [Page 4] DRAFT PPP SDP August 1998 Contacts Comments about this document should be discussed on the ietf- ppp@merit.edu mailing list. This document was reviewed by the Point-to-Point Protocol Working | Group of the Internet Engineering Task Force (IETF). The working group can be contacted via the current chair: Karl Fox Ascend Communications 3518 Riverside Drive Suite 101 Columbus, Ohio 43221 karl@Ascend.com - Questions about this document can also be directed to: William Allen Simpson DayDreamer Computer Systems Consulting Services 1384 Fontaine Madison Heights, Michigan 48071 wsimpson@UMich.edu wsimpson@GreenDragon.com (preferred) Simpson expires in six months [Page 5] DRAFT PPP SDP August 1998 Full Copyright Statement + Copyright (C) William Allen Simpson (1992-1994, 1996-1998). All + Rights Reserved. + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this doc- + ument itself may not be modified in any way, except as required to + translate it into languages other than English. + This document and the information contained herein is provided on an + "AS IS" basis and the author(s) DISCLAIM ALL WARRANTIES, EXPRESS OR + IMPLIED, INCLUDING (BUT NOT LIMITED TO) ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Simpson expires in six months [Page 6]