Network Working Group W. Simpson Internet Draft DayDreamer expires in six months July 1997 PPP LCP Self Describing Padding draft-ietf-pppext-padding-ds-00.txt Status of this Memo Distribution of this memo is unlimited. 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 (Europe) ds.internic.net (US East Coast) ftp.isi.edu (US West Coast) munnari.oz.au (Pacific Rim) Abstract The Point-to-Point Protocol (PPP) [1] 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 July 1997 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). 2. Additional LCP Configuration Options The Configuration Option format and basic options are already defined for LCP [1]. Up-to-date values of the LCP Option Type field are specified in the most recent "Assigned Numbers" [2]. This document concerns the fol- lowing values: 10 Self-Describing-Padding In this document, the key words "MAY", "MUST", "MUST NOT", "required", and "SHOULD", are to be interpreted as described in [3]. 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 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. Simpson expires in six months [Page 1] DRAFT PPP SDP July 1997 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 [1 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. If the final octet is zero (0), or is greater than MPV, no addi- tional padding is required. Simpson expires in six months [Page 2] DRAFT PPP SDP July 1997 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. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 July 1997 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 [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD-51, RFC-1661, December 1993. [2] Reynolds, J.K., Postel, J.B., "Assigned Numbers", RFC-1700, July 1992. [3] 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 July 1997 Contacts Comments about this document should be discussed on the ietf-ppp@merit.edu mailing list. This document is a submission to 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@MorningStar.com 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) bsimpson@MorningStar.com Simpson expires in six months [Page 5]