Subject: On scrambling and transparency...

From: [email-masked]
Date: Mon, 01 Dec 1997 14:09:39 -0500

The attached ID hasn't been announced yet.  I figure it is caught in a
backlog as I was not able to submit until the afternoon of the 21st.
Anyway, I will be presenting the same material to T1X1.5 tomorrow.

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: [email-masked]

   S. Dravida
   Bell Laboratories, Lucent Technologies
   101 Crawfords Corner Rd
   Holmdel, NJ 07733
   USA

   Email: [email-masked]

   B. Doshi
   Bell Laboratories, Lucent Technologies
   101 Crawfords Corner Rd
   Holmdel, NJ 07733
   USA

   Email: [email-masked]

   J. Anderson
   Bell Laboratories, Lucent Technologies
   101 Crawfords Corner Rd
   Holmdel, NJ 07733
   USA

   Email: [email-masked]

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: [email-masked]

   Peter Lothberg
   Sprint
   12490 Sunrise Valley Dr,
   Reston, VA 20196
   USA

   Email: [email-masked]

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]