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 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 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 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 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 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 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," , 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," , 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]