One document matched: draft-ietf-pppext-padding-ds-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-22 14:42:04 |