Internet-Draft J. Manchester
S. Dravida
B. Doshi
J. Anderson
Lucent Technologies
R. Broberg
Cisco Systems
Peter Lothberg
Sprint Corporation
November 21st, 1997
Enabling Transparency for the PPP over SONET/SDH Mapping
<draft-manchester-pppext-transper-00.txt>
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working 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 inappropriate to use Internet- Drafts as reference
material or to cite them other than as ``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),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
Abstract
Recent Internet Draft submissions and discussion on the PPP
Extensions Working Group email list have highlighted a transparency
deficiency with the PPP over SONET/SDH mapping described in IETF RFC
1619. This ID proposes that a 1+x**43 scrambler be used to overcome
the transparency deficiency of IETF RFC 1619.
Manchester, et al Expires May 21st, 1998 [Page 1]
Internet Draft <draft-manchester-pppext-transper-00.txt> Nov.21, 1997
1. Introduction
Reference [1] describes a deficiency with the IETF RFC 1619 [2] PPP
over SONET/SDH mapping that allows a user to gain control of a
significant portion of the SONET/SDH SPE by emulating the SONET/SDH
scrambler. It has been known since 1988 that data mappings should be
scrambled before they are mapped into the SONET/SDH payload; hence a
1+x**43 self-synchronous scrambler is used to scramble the ATM
payload before ATM cells are mapped into the SONET/SDH payload. The
ATM scrambler is easy to implement and its characteristics are well
known. The use of the ATM scrambler would thus be a convenient fix
for RFC 1619.
References [3] and [4] provide an analysis of the ATM scrambler with
the PPP over SONET/SDH mapping. The studies show that the error
multiplication due to the self-synchronous nature of the scrambler
does not result in appreciable degradation in the error detection
capability of the 16 bit HDLC FCS used in the mapping. Since this
mapping does not use FEC in the protocol overhead or in the payload,
other impacts of error multiplication are not an issue. The ATM
scrambler is also shown to be effective in avoiding zero transition
density. For a detailed analysis of the issues see [4].
It is also important to recognize the following points with regard to
this issue:
1. The IETF RFC process is in place to stimulate and challenge
thereby bringing about open discussion. The past month has shown
that it works and can lead to good multi-vendor solutions. The past
month's dialogue has been dealing with normal issues generated by
Requests For Comment; IETF RFC 1619 is not yet an IETF standard.
2. The discussions of the past month have pointed out a deficiency in
RFC 1619 that must be corrected before it is adopted as a standard.
3. Wide area, multi-carrier point-to-point links based on RFC 1619
have been in operation for over a year now with and without
scrambling. While it is impossible to trace and determine whether
transient operational problems can be attributed to the payload
transparency problem, we should consider ourselves quite lucky that
this problem has surfaced early in the standardization process.
4. Doubts (presented in [3]) regarding error multiplication and
HDLC?s 16 bit FCS (the HDLC FCS is described in [5]) have not been
seen operationally. There are several factors involved here. First,
burst errors, when they occur, often result in packet truncation.
When this occurs the truncated packet, if it passes the 16 bit FCS
Manchester, et al Expires May 21st, 1998 [Page 2]
Internet Draft <draft-manchester-pppext-transper-00.txt> Nov.21, 1997
will be tossed by length checks of the IP header. Subsequent
remnants, if they pass, will be discarded via IP header validation.
Passing the 16 bit FCS and IP header validation is considered highly
unlikely.
5. Error multiplication may have an impact on the ability to perform
FEC on the protocol overhead bytes and on the payload. Since PPP over
SONET mapping does not use FEC anywhere, this is not a concern for
the current PPP over SONET mapping. The scrambler issue should be
revisited when a different mapping and/or FEC capabilities are
considered.
2. Recommendations
It is recommended that the following text be added to an appendix of
IETF RFC 1619.
For adequate transparency, data signals mapped directly into
SONET/SDH payloads should be scrambled. For backwards compatibility,
the scrambler should have an on/off capability where the scrambler is
bypassed entirely when it is in the off mode. Scrambling provides
security against emulation of the SONET/SDH scrambler pattern causing
negative operational situations in SONET networks.
For PPP over SONET/SDH, the entire SONET/SDH payload (SPE minus the
path overhead and any fixed stuff) shall be scrambled using a self
synchronous scrambler of polynomial 1+X**43. The transmitter and
receiver operation are depicted below [3]:
Transmitter schematic:
Unscrambled Data
|
v
+-------------------------------------+ +---+
+->| --> 43 bit shift register --> |--->|xor|
| +-------------------------------------+ +---+
| |
+-----------------------------------------------+
|
v
Scrambled Data
Manchester, et al Expires May 21st, 1998 [Page 3]
Internet Draft <draft-manchester-pppext-transper-00.txt> Nov.21, 1997
Receiver schematic:
Scrambled Data
|
+-----------------------------------------------+
| |
| v
| +-------------------------------------+ +---+
+->| --> 43 bit shift register --> |--->|xor|
+-------------------------------------+ +---+
|
v
Unscrambled Data
The HDLC FCS is calculated least significant bit first as shown:
<- <- <- <-
A B C D,
That is, the FCS calculator is fed as follows: A[0], A[1], ... A[7],
B[0], B[1], etc... Scrambling is done in the opposite manner, most
significant bit first, as shown:
-> -> -> ->
A B C D.
That is, the scrambler is fed as follows: A[7], A[6], ... A[0], B[7],
B[6], etc...
The scrambler shall operate continuously through the bytes of the
SPE, bypassing bytes of SONET Path Overhead. The scrambling state at
the beginning of a SPE shall be the state at the end of the previous
SPE. Thus, the scrambler runs continuously and is not reset per
frame. An initial seed is unspecified. Consequently, the first 43
transmitted bits following startup or reframe operation will not be
descrambled correctly.
Security Consideration
This Internet Draft presents a proposed solution to specific security
vulnerabilities associated with the PPP over SONET/SDH mapping of RFC
1619. Note this consideration is from the viewpoint of the SONET
network.
Acknowledgments
Manchester, et al Expires May 21st, 1998 [Page 4]
Internet Draft <draft-manchester-pppext-transper-00.txt> Nov.21, 1997
The members of the Manchester Pub are greatly thanked for their
philosophical inspiration.
Author Addresses
J. Manchester
Bell Laboratories, Lucent Technologies
101 Crawfords Corner Rd
Holmdel, NJ 07733
USA
Email: manchester@bell-labs.com
S. Dravida
Bell Laboratories, Lucent Technologies
101 Crawfords Corner Rd
Holmdel, NJ 07733
USA
Email: dravida@bell-labs.com
B. Doshi
Bell Laboratories, Lucent Technologies
101 Crawfords Corner Rd
Holmdel, NJ 07733
USA
Email: bdoshi@bell-labs.com
J. Anderson
Bell Laboratories, Lucent Technologies
101 Crawfords Corner Rd
Holmdel, NJ 07733
USA
Email: jonanderson@bell-labs.com
Manchester, et al Expires May 21st, 1998 [Page 5]
Internet Draft <draft-manchester-pppext-transper-00.txt> Nov.21, 1997
R. Broberg
Cisco Systems
170 West Tasman Drive
San Jose, CA 94513
USA
Email: rbroberg@cisco.com
Peter Lothberg
Sprint
12490 Sunrise Valley Dr,
Reston, VA 20196
USA
Email: roll@sprint.net
References
[1] J. Manchester, et al., "PPP over SONET/SDH," <draft-ietf-pppext-
pppsonet-scrambler-00.txt>, work in progress.
[2] W. Simpson, "PPP over SONET/SDH," RFC 1619, May 1994.
[3] D. Ferguson and R. Cherukuri, "Self-Synchronous Scramblers For
PPP Over Sonet/SDH: Some Analysis," <draft-ferguson-pppsonet-
selfsync-00.txt>, work in progress.
[3] B. Doshi, et al., "Scramblers for PPP over SONET/SDH:
Performance Considerations and Analysis,"to be published.
[5] W. Simpson, "PPP in HDLC-like Framing," RFC 1662, July 1994.
Manchester, et al Expires May 21st, 1998 [Page 6]