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]
