idnits 2.17.1 draft-ietf-pppext-pppoversonet-update-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 1999) is 9133 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '0' is mentioned on line 209, but not defined == Missing Reference: '7' is mentioned on line 209, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PPP Extensions Working Group A. Malis 2 INTERNET DRAFT Ascend Communications, Inc. 3 Expires: October 1999 W. Simpson 4 DayDreamer 5 Obsoletes: RFC 1619 April 1999 7 PPP over SONET/SDH 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This document specifies an Internet standards track protocol for the 31 Internet community, and requests discussion and suggestions for 32 improvements. Please refer to the current edition of the "Internet 33 Official Protocol Standards" (STD 1) for the standardization state 34 and status of this protocol. Distribution of this memo is unlimited. 36 Abstract 38 The Point-to-Point Protocol (PPP) [1] provides a standard method for 39 transporting multi-protocol datagrams over point-to-point links. 40 This document describes the use of PPP over Synchronous Optical 41 Network (SONET) and Synchronous Digital Heirarchy (SDH) circuits. 43 This document replaces and obsoletes RFC 1619. See section 7 for a 44 summary of the changes from RFC 1619. 46 This document is the product of the Point-to-Point Protocol 47 Extensions Working Group of the Internet Engineering Task Force 48 (IETF). Comments should be submitted to the ietf-ppp@merit.edu 49 mailing list. 51 1. Introduction 53 PPP was designed as a standard method of communicating over point- 54 to-point links. Initial deployment has been over short local lines, 55 leased lines, and plain-old-telephone-service (POTS) using modems. 56 As new packet services and higher speed lines are introduced, PPP is 57 easily deployed in these environments as well. 59 This specification is primarily concerned with the use of the PPP 60 encapsulation over SONET/SDH links. Since SONET/SDH is by definition 61 a point-to-point circuit, PPP is well suited to use over these links. 63 Real differences between SONET and SDH (other than terminology) are 64 minor; for the purposes of encapsulation of PPP over SONET/SDH, they 65 are inconsequential or irrelevant. 67 For the convenience of the reader, we list the equivalent terms below: 69 SONET SDH 70 --------------------------------------------- 71 SPE VC 72 STS-SPE Higher Order VC (VC-3/4/4-Nc) 73 STS-1 frame STM-0 frame (rarely used) 74 STS-1-SPE VC-3 75 STS-1 payload C-3 76 STS-3c frame STM-1 frame, AU-4 77 STS-3c-SPE VC-4 78 STS-3c payload C-4 79 STS-12c/48c/192c frame STM-4/16/64 frame, AU-4-4c/16c/64c 80 STS-12c/48c/192c-SPE VC-4-4c/16c/64c 81 STS-12c/48c/192c payload C-4-4c/16c/64c 83 The only currently supported SONET/SDH SPE/VCs are the following: 85 SONET SDH 86 ---------------------------------------- 87 STS-3c-SPE VC-4 88 STS-12c-SPE VC-4-4c 89 STS-48c-SPE VC-4-16c 90 STS-192c-SPE VC-4-64c 92 The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED, 93 SHALL, SHALL NOT, SHOULD, and SHOULD NOT are to be interpreted as 94 defined in [6]. 96 2. Physical Layer Requirements 98 PPP treats SONET/SDH transport as octet oriented synchronous links. 99 SONET/SDH links are full-duplex by definition. 101 Interface Format 103 PPP in HDLC-like framing presents an octet interface to the 104 physical layer. There is no provision for sub-octets to be 105 supplied or accepted [3][5]. 107 The octet stream is mapped into the SONET STS-SPE/SDH Higher Order 108 VC, with the octet boundaries aligned with the SONET STS-SPE/SDH 109 Higher Order VC octet boundaries. 111 Scrambling is performed during insertion into the SONET STS- 112 SPE/SDH Higher Order VC to provide adequate transparency and 113 protect against potential security threats (see Section 6). For 114 backwards compatibility with RFC 1619 (STS-3c-SPE/VC-4 only), the 115 scrambler MAY have an on/off capability where the scrambler is 116 bypassed entirely when it is in the off mode. If this capability 117 is provided, the default MUST be set to scrambling enabled. 119 For PPP over SONET/SDH, the entire SONET/SDH payload (SONET STS- 120 SPE/SDH Higher Order VC minus the path overhead and any fixed 121 stuff) is scrambled using a self-synchronous scrambler of 122 polynomial X**43 + 1. See Section 4 for the description of the 123 scrambler. 125 The proper order of operation is: 127 When transmitting: 129 IP -> PPP -> FCS generation -> Byte stuffing -> Scrambling -> 130 SONET/SDH framing 132 When receiving: 134 SONET/SDH framing -> Descrambling -> Byte destuffing -> FCS 135 detection -> PPP -> IP 137 The Path Signal Label (C2) indicates the contents of the SONET 138 STS-SPE/SDH Higher Order VC. The value of 22 (16 hex) is used to 139 indicate PPP with X^43 + 1 scrambling [4]. 141 For compatibility with RFC 1619 (STS-3c-SPE/VC-4 only), if 142 scrambling has been configured to be off, then the value 207 (CF 143 hex) is used for the Path Signal Label to indicate PPP without 144 scrambling. 146 The Multiframe Indicator (H4) is unused, and MUST be zero. 148 Control Signals 150 PPP does not require the use of control signals. When available, 151 using such signals can allow greater functionality and 152 performance. Implications are discussed in [2]. 154 3. Framing 156 The framing for octet-synchronous links is described in "PPP in 157 HDLC-like Framing" [2]. 159 The PPP frames are located by row within the SONET STS-SPE/SDH Higher 160 Order VC payload. Because frames are variable in length, the frames 161 are allowed to cross SONET STS-SPE/SDH Higher Order VC boundaries. 163 4. X**43 + 1 Scrambler Description 165 The X**43 + 1 scrambler transmitter and receiver operation are as 166 follows: 168 Transmitter schematic: 170 Unscrambled Data 171 | 172 v 173 +-------------------------------------+ +---+ 174 +->| --> 43 bit shift register --> |--->|xor| 175 | +-------------------------------------+ +---+ 176 | | 177 +-----------------------------------------------+ 178 | 179 v 180 Scrambled Data 182 Receiver schematic: 184 Scrambled Data 185 | 186 +-----------------------------------------------+ 187 | | 188 | v 189 | +-------------------------------------+ +---+ 190 +->| --> 43 bit shift register --> |--->|xor| 191 +-------------------------------------+ +---+ 192 | 193 v 194 Unscrambled Data 196 Note: While the HDLC FCS is calculated least significant bit first as 197 shown: 199 <- <- <- <- 200 A B C D 202 (that is, the FCS calculator is fed as follows: A[0], A[1], ... A[7], 203 B[0], B[1], etc...), scrambling is done in the opposite manner, most 204 significant bit first, as shown: 206 -> -> -> -> 207 A B C D. 209 That is, the scrambler is fed as follows: A[7], A[6], ... A[0], B[7], 210 B[6], etc... 212 The scrambler operates continuously through the bytes of the SONET 213 STS-SPE/SDH Higher Order VC, bypassing bytes of SONET Path Overhead 214 and any fixed stuff (see Figure 20 of ANSI T1.105 [3] or Figure 10-17 215 of ITU G.707 [5]). The scrambling state at the beginning of a SONET 216 STS-SPE/SDH Higher Order VC is the state at the end of the previous 217 SONET STS-SPE/SDH Higher Order VC. Thus, the scrambler runs 218 continuously and is not reset per frame. The initial seed is randomly 219 chosen by transmitter to improve operational security (see Section 220 6). Consequently, the first 43 transmitted bits following startup or 221 reframe operation will not be descrambled correctly. 223 5. Configuration Details 225 Other than the FCS length (see below), the standard LCP sync 226 configuration defaults apply to SONET/SDH links. 228 The following Configuration Options are RECOMMENDED for STS-3c- 229 SPE/VC-4: 231 Magic Number 232 No Address and Control Field Compression 233 No Protocol Field Compression 235 For operation at STS-12c-SPE/VC-4-4c and above, Address and Control 236 Field Compression and Protocol Field Compression are NOT RECOMMENDED. 237 The Magic Number option remains RECOMMENDED. 239 Regarding the FCS length, with one exception, the 32-bit FCS MUST be 240 used for all SONET/SDH rates. For STS-3c-SPE/VC-4 only, the 16-bit 241 FCS MAY be used, although the 32-bit FCS is RECOMMENDED. The FCS 242 length is set by provisioning and is not negotiated. 244 6. Security Considerations 246 The major change from RFC 1619 is the addition of payload scrambling 247 when inserting the HDLC-like framed PPP packets into the SONET STS- 248 SPE/SDH Higher Order VC. RFC 1619 was operationally found to permit 249 malicious users to generate packets with bit patterns that could 250 create SONET/SDH-layer low-transition-density synchronization 251 problems, emulation of the SDH set-reset scrambler pattern, and 252 replication of the STM-N frame alignment word. 254 The use of the x^43 + 1 self-synchronous scrambler was introduced to 255 alleviate these potential security problems. Predicting the output 256 of the scrambler requires knowledge of the 43-bit state of the 257 transmitter as the scrambling of a known input is begun. This 258 requires knowledge of both the initial 43-bit state of the scrambler 259 when it started and every byte of data scrambled by the device since 260 it was started. The odds of guessing correctly are 1/2**43, with the 261 additional probability of 1/127 that a correct guess will leave the 262 frame properly aligned in the SONET/SDH payload, which results in a 263 probability of 9e-16 against being able to deliberately cause 264 SONET/SDH-layer problems. This seems reasonably secure for this 265 application. 267 This scrambler is also used when transmitting ATM over SONET/SDH, and 268 public network carriers have considerable experience with its use. 270 A known security issue is bandwidth reduction by intentional 271 transmission of characters or sequences requiring transparency 272 processing by including flag and/or escape characters in user data. A 273 user may cause up to a 100% increase in the bandwidth required for 274 transmitting his or her packets by filling the packet with flag 275 and/or escape characters. 277 7. Changes from RFC 1619 279 As mentioned in the previous section, the major change from RFC 1619 280 was the addition of payload scrambling when inserting the HDLC-like 281 framed PPP packets into the SONET STS-SPE/SDH Higher Order VC. Other 282 changes were: 284 The terminology was updated to better match that used by ANSI and 285 ITU-T. 287 The specification's applicability is now specifically restricted to: 289 SONET SDH 290 ---------------------------------------- 291 STS-3c-SPE VC-4 292 STS-12c-SPE VC-4-4c 293 STS-48c-SPE VC-4-16c 294 STS-192c-SPE VC-4-64c 296 The Path Signal Label (C2) is set to 22 (16 hex) when using X^43 + 1 297 scrambling. 299 The 32-bit FCS is required except for operation with STS-3c-SPE/VC-4, 300 in which case the 16-bit FCS is allowed (but the 32-bit FCS is still 301 recommended). 303 The Security Considerations section was added. 305 8. Intellectual Property 307 The IETF takes no position regarding the validity or scope of any 308 intellectual property or other rights that might be claimed to 309 pertain to the implementation or use of the technology described in 310 this document or the extent to which any license under such rights 311 might or might not be available; neither does it represent that it 312 has made any effort to identify any such rights. Information on the 313 IETF's procedures with respect to rights in standards-track and 314 standards-related documentation can be found in BCP-11. Copies of 315 claims of rights made available for publication and any assurances of 316 licenses to be made available, or the result of an attempt made to 317 obtain a general license or permission for the use of such 318 proprietary rights by implementors or users of this specification can 319 be obtained from the IETF Secretariat. 321 The IETF invites any interested party to bring to its attention any 322 copyrights, patents or patent applications, or other proprietary 323 rights which may cover technology that may be required to practice 324 this standard. Please address the information to the IETF Executive 325 Director. 327 9. Acknowledgments 329 The scrambler description was provided by J. Manchester, S. Davida, 330 B. Doshi, and J. Anderson of Lucent Technologies, R. Broberg of Cisco 331 Systems, and Peter Lothberg of Sprint Corporation. The security 332 analysis was provided by Iain Verigin of PMC-Sierra and Larry McAdams 333 of Cisco Systems. The authors would also like to thank the members 334 of the IETF's Point-to-Point Protocol Extensions Working Group for 335 their many suggestions and improvements to the text. 337 10. References 339 [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", RFC 340 1661, Daydreamer, July 1994. 342 [2] Simpson, W., Editor, "PPP in HDLC-like Framing", RFC 1662, 343 Daydreamer, July 1994. 345 [3] American National Standards Institute, "Synchronous Optical 346 Network (SONET) - Basic Description including Multiplex 347 Structure, Rates and Formats," ANSI T1.105-1995. 349 [4] American National Standards Institute, "Synchronous Optical 350 Network (SONET)--Payload Mappings," T1.105.02-1998. 352 [5] ITU Recommendation G.707, "Network Node Interface For The 353 Synchronous Digital Hierarchy", 1996. 355 [6] Bradner, S., "Key words for use in RFCs to indicate Requirement 356 Levels", BCP 14, RFC 2119, Harvard University, March 1997. 358 11. Authors' Addresses 360 Andrew G. Malis 361 Ascend Communications, Inc. 362 1 Robbins Road 363 Westford, MA 01810 USA 365 Phone: +1 978 952 7414 366 Email: malis@ascend.com 368 William Allen Simpson 369 DayDreamer 370 Computer Systems Consulting Services 371 1384 Fontaine 372 Madison Heights, Michigan 48071 374 Email: wsimpson@GreenDragon.com 376 12. Full Copyright Statement 378 Copyright (C) The Internet Society (1999). All Rights Reserved. 380 This document and translations of it may be copied and furnished to 381 others, and derivative works that comment on or otherwise explain it 382 or assist in its implementation may be prepared, copied, published 383 and distributed, in whole or in part, without restriction of any 384 kind, provided that the above copyright notice and this paragraph are 385 included on all such copies and derivative works. However, this 386 document itself may not be modified in any way, such as by removing 387 the copyright notice or references to the Internet Society or other 388 Internet organizations, except as needed for the purpose of 389 developing Internet standards in which case the procedures for 390 copyrights defined in the Internet Standards process must be 391 followed, or as required to translate it into languages other than 392 English. 394 The limited permissions granted above are perpetual and will not be 395 revoked by the Internet Society or its successors or assigns. 397 This document and the information contained herein is provided on an 398 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 399 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 400 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 401 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 402 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 404 Table of Contents 406 1. Introduction .......................................... 1 407 2. Physical Layer Requirements ........................... 2 408 3. Framing ............................................... 3 409 4. X**43 + 1 Scrambler Description ....................... 3 410 5. Configuration Details ................................. 4 411 6. Security Considerations ............................... 5 412 7. Changes from RFC 1619 ................................. 6 413 8. Intellectual Property ................................. 6 414 9. Acknowledgments ....................................... 7 415 10. References ............................................ 7 416 11. Authors' Addresses .................................... 8 417 12. Full Copyright Statement .............................. 8