From owner-ietf-ppp@merit.edu Wed Oct 1 00:33:32 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id AAA11443; Wed, 1 Oct 1997 00:32:04 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 1 Oct 1997 00:31:45 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id AAA11422 for ietf-ppp-outgoing; Wed, 1 Oct 1997 00:31:44 -0400 (EDT) Received: from ns.trancell.stph.net (podila@ns.trancell.stph.net [196.12.55.2]) by merit.edu (8.8.7/8.8.5) with ESMTP id AAA11411 for ; Wed, 1 Oct 1997 00:31:19 -0400 (EDT) Received: from trancell.stph.net (podila@localhost) by ns.trancell.stph.net (8.7.3/8.7.3) id KAA10393; Wed, 1 Oct 1997 10:46:09 +0530 (IST) Date: Wed, 1 Oct 1997 10:46:06 +0530 (IST) From: "Swamy P.H.V.S" To: Kelly McGrew cc: ietf-ppp@merit.edu Subject: Re: PPP Implementations In-Reply-To: <34313571.5639@sprynet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu On Tue, 30 Sep 1997, Kelly McGrew wrote: > A request for information about various PPP implementations: > > I'm looking for PPP implementations that are fully compliant with the > standards. From what I've read here and elsewhere Microsoft's RAS > service isn't fully compliant with the PPP standard(s). I want to scope > some connections and compare the traces to illustrate to a class I'm > teaching differing levels of compliance. Some questions: > > 1. Is it true Microsoft's implementation isn't fully complaint? Yes, its not "fully" compliant. > > 2. What specific types of config requests can I make to illustrate > differences between Microsoft implementation and an implementation which > is in complaince with the RFC's? > For example, 95/NT clients come with "Callback option" default set to operation "6", which is not stadard (refer to LCP extensions RFC), but MS's own protocol CBCP. If we NAK option 13 with operation set to 0, the 95/NT client still comes with "6" only and finally if negotiations not converging, 95/NT client just sends Conf. Req. without callback option! Linux is probably written with proper stack, which can be considered for dialing into using win95. (Note: Linux also added code for supporting non-standard, but popular options like CBCP of MS!). So, even if win95 comes up with non standard options, Linux honours them! Swamy - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Oct 1 01:54:18 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id BAA12397; Wed, 1 Oct 1997 01:52:47 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 1 Oct 1997 01:52:26 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id BAA12379 for ietf-ppp-outgoing; Wed, 1 Oct 1997 01:52:25 -0400 (EDT) Received: from stpn.soft.net (stpn.soft.net [204.143.127.2]) by merit.edu (8.8.7/8.8.5) with SMTP id BAA12375 for ; Wed, 1 Oct 1997 01:52:19 -0400 (EDT) Received: from shilpa.pcl.stpn.soft.net (unverified [204.143.116.98]) by stpn.soft.net (EMWAC SMTPRS 0.83) with SMTP id ; Wed, 01 Oct 1997 11:25:10 +0530 Received: from [192.168.200.142] by shilpa.pcl.stpn.soft.net id aa09015; 1 Oct 97 11:18 IST Message-ID: <3431E5E4.44AC@pcl.stpn.soft.net> Date: Wed, 01 Oct 1997 11:25:49 +0530 From: "Vimal K. Khanna" Organization: Mindware X-Mailer: Mozilla 3.0 (WinNT; I) MIME-Version: 1.0 To: ietf-ppp@merit.edu Subject: Re: Requesting comments on draft-rfced-info-khana-00.txt References: <42fd8b80@rdl.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Jonathan Goodchild wrote: > I think that maybe a standard Call User Data string would be useful to > identify the fact that a call carries octet-oriented PPP. But I'm not > sure that 01 00 00 00 00 00 00 01 (including the X.29 PID) is the best > choice. Maybe 01 00 00 00 CF would be better (as the CUD for RFC 1598 > calls is 0xCF, but without the 01 00 00 00 in front of it). > > There may also be some problems with using an unrestricted response Fast > Select call - there may be some X.25 networks which don't support them. > Thanks for your suggestion - this is a practical issue pointed to by others also. I would update the draft so that it uses simple PAD mechanisms available with equipments of all vendors ( may be CUD option, as you have suggested ). > > Maybe RFC 1598 needs to be updated to include a description of the > operation of octet-oriented PPP over X.25. "Another" member on the list has suggested ( using an extraordinarily long mail to convey this point ) the use of RFC 1662. I shall go thru it and see if it solves the problem, and get back. Regards. Vimal - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Oct 1 02:17:46 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id CAA12807; Wed, 1 Oct 1997 02:16:21 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 1 Oct 1997 02:16:05 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id CAA12782 for ietf-ppp-outgoing; Wed, 1 Oct 1997 02:16:04 -0400 (EDT) Received: from stpn.soft.net (stpn.soft.net [204.143.127.2]) by merit.edu (8.8.7/8.8.5) with SMTP id CAA12774 for ; Wed, 1 Oct 1997 02:15:56 -0400 (EDT) Received: from shilpa.pcl.stpn.soft.net (unverified [204.143.116.98]) by stpn.soft.net (EMWAC SMTPRS 0.83) with SMTP id ; Wed, 01 Oct 1997 11:49:25 +0530 Received: from [192.168.200.142] by shilpa.pcl.stpn.soft.net id aa10256; 1 Oct 97 11:42 IST Message-ID: <3431EB96.6123@pcl.stpn.soft.net> Date: Wed, 01 Oct 1997 11:50:06 +0530 From: "Vimal K. Khanna" Organization: Mindware X-Mailer: Mozilla 3.0 (WinNT; I) MIME-Version: 1.0 To: William Allen Simpson CC: ietf-ppp@merit.edu Subject: Re: [Fwd: [Fwd: Requesting comments on my draft]] References: <6595.wsimpson@greendragon.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu William Allen Simpson wrote: > Actually, he sent me several messages, and Karl several messages, and > the WG list a couple as well. > Interesting. Though, I am still going thru the technical contents of your mail, I decided to comment on this part. Only a "SINGLE" message has been sent directly to you after the draft has appeared. If my requests to the list and individual members ( like Fred, who were expected to be interested in this work ) for suggestions/comments on my work, have been forwarded to you by these individuals, all the fault lies with you - for having authored ALL the PPP related RFCs. Regards. Vimal - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Oct 1 09:20:00 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id JAA15927; Wed, 1 Oct 1997 09:17:20 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 1 Oct 1997 09:13:38 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id JAA15818 for ietf-ppp-outgoing; Wed, 1 Oct 1997 09:13:38 -0400 (EDT) Received: from lms03.us.ibm.com (lms03.ny.us.ibm.com [198.133.22.39]) by merit.edu (8.8.7/8.8.5) with ESMTP id JAA15814 for ; Wed, 1 Oct 1997 09:13:34 -0400 (EDT) Received: from US.IBM.COM (d01lms04.pok.ibm.com [9.117.30.25]) by lms03.us.ibm.com (8.8.7/8.8.7) with SMTP id JAA21826 for ; Wed, 1 Oct 1997 09:11:37 -0500 Received: by US.IBM.COM (Soft-Switch LMS 2.0) with snapi via D01AU002 id 5010400011710890; Wed, 1 Oct 1997 09:16:51 -0400 From: John Martz To: Subject: Re: PPP Implementations Message-ID: <5010400011710890000002L002*@MHS> Date: Wed, 1 Oct 1997 09:16:51 -0400 MIME-Version: 1.0 Content-Type: text/plain Sender: owner-ietf-ppp@merit.edu Swamy, >> Linux is probably written with proper stack, which can be considered for >> dialing into using win95. Which Linux??? Which PPP for Linux??? I'm not saying your wrong, I'm just saying that in my admittedly very limited understanding of Linux, there seems to be a lot of diversity out there. The one publically available version of PPP that I looked at was supposedly a Linux PPP (among other platforms). It defaults the receiving ACCM to 0 or whatever was previously negotiated, which is non-compliant. My speculation/guess is that Windows NT/'95 also based their implementation on this code because they appear to also default the receive ACCM to 0. I'm looking forward to the clarification/followup on this from Gurdeep Singh Pall to find out if my guess is correct or not. At any rate, I'd be careful about assuming that a given Linux implementation is totally compliant. -john - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Oct 1 09:30:40 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id JAA16303; Wed, 1 Oct 1997 09:29:17 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 1 Oct 1997 09:28:32 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id JAA16231 for ietf-ppp-outgoing; Wed, 1 Oct 1997 09:28:31 -0400 (EDT) Received: from ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.7/8.8.5) with ESMTP id JAA16225 for ; Wed, 1 Oct 1997 09:28:26 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id JAA03074; Wed, 1 Oct 1997 09:28:23 -0400 (EDT) Message-Id: <199710011328.JAA03074@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-aal5-02.txt Date: Wed, 01 Oct 1997 09:28:23 -0400 Sender: owner-ietf-ppp@merit.edu --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : PPP over AAL5 Author(s) : M. Kaycee, A. Malis, A. Lin, J. Stephens, G. Gross Filename : draft-ietf-pppext-aal5-02.txt Pages : 10 Date : 30-Sep-97 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document describes the use of ATM Adaptation Layer 5 (AAL5) for framing PPP encapsulated packets. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-aal5-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-aal5-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-aal5-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970930133925.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-aal5-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-aal5-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970930133925.I-D@ietf.org> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Oct 1 09:30:40 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id JAA16301; Wed, 1 Oct 1997 09:29:17 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 1 Oct 1997 09:28:41 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id JAA16247 for ietf-ppp-outgoing; Wed, 1 Oct 1997 09:28:40 -0400 (EDT) Received: from ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.7/8.8.5) with ESMTP id JAA16239 for ; Wed, 1 Oct 1997 09:28:32 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id JAA03098; Wed, 1 Oct 1997 09:28:29 -0400 (EDT) Message-Id: <199710011328.JAA03098@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-funi-02.txt Date: Wed, 01 Oct 1997 09:28:28 -0400 Sender: owner-ietf-ppp@merit.edu --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : PPP Over FUNI Author(s) : M. Kaycee, A. Malis, A. Lin, J. Stephens, G. Gross Filename : draft-ietf-pppext-funi-02.txt Pages : 10 Date : 30-Sep-97 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document describes the use of ATM Frame User Network Interface (FUNI) for framing PPP encapsulated packets. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-funi-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-funi-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-funi-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970930134213.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-funi-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-funi-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970930134213.I-D@ietf.org> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Oct 1 12:03:29 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id MAA19584; Wed, 1 Oct 1997 12:02:04 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 1 Oct 1997 12:01:30 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id MAA19561 for ietf-ppp-outgoing; Wed, 1 Oct 1997 12:01:30 -0400 (EDT) Received: from elmer.wrq.com (elmer.wrq.com [150.215.17.1]) by merit.edu (8.8.7/8.8.5) with ESMTP id MAA19557 for ; Wed, 1 Oct 1997 12:01:25 -0400 (EDT) Received: from ursula.wrq.com by elmer.wrq.com with ESMTP (1.37.109.20/15.6) id AA228981684; Wed, 1 Oct 1997 09:01:24 -0700 Received: from aurora.wrq.com ([150.215.81.206]) by ursula.wrq.com with ESMTP (8.7.6/8.7.3) id IAA01787; Wed, 1 Oct 1997 08:57:08 -0700 (PDT) Message-Id: <199710011557.IAA01787@ursula.wrq.com> From: "Aaron Hanson" To: , Subject: Re: ISDN and RFC-1618 and deprecation Date: Wed, 1 Oct 1997 08:55:07 -0700 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1161 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu On the subject of a new draft for RFC-1618, could something be added to address PPP over non-clear channel ISDN? For example, 56k services where bit seven can't be used due to bit-robbing for trunk signaling? I believe there is a de-facto standard of using a V.110 bit-synchronous HDLC mode. -Aaron Hanson aaronh@wrq.com ---------- > From: wsimpson@greendragon.com > To: ietf-ppp@merit.edu > Subject: Re: ISDN and RFC-1618 and deprecation > Date: Tuesday, September 30, 1997 10:51 AM > > > From: John Shriver > > I think we need to make "PPP over ISDN" admit all the disgusting > > things people want to do. Certainly, it should point out that the > > native encapsulation is best for many reasons. Perhaps it should even > > point out what a PPP-conscious ISDN TA should do. (Maybe that > > deserves a "best practices" RFC?) Sort of, here's the preferred > > method, but if you're perverse, see the appendices. Then, a set of > > appendices: > > > OK, what you say makes a lot of sense. I'll put together a draft in the > next few days. Thanks, John. > > WSimpson@UMich.edu > Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 > BSimpson@MorningStar.com > Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Oct 1 14:07:43 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id OAA22139; Wed, 1 Oct 1997 14:04:47 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 1 Oct 1997 14:04:18 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA22112 for ietf-ppp-outgoing; Wed, 1 Oct 1997 14:04:18 -0400 (EDT) Received: from alpha.shiva.com (eagle-ext.shiva.com [192.80.57.28]) by merit.edu (8.8.7/8.8.5) with ESMTP id OAA22108 for ; Wed, 1 Oct 1997 14:04:12 -0400 (EDT) Received: from brill.shiva.com (brill.shiva.com [140.248.193.94]) by alpha.shiva.com (8.8.6/8.8.6) with SMTP id OAA05328; Wed, 1 Oct 1997 14:02:56 -0400 (EDT) Received: by brill.shiva.com (SMI-8.6/SMI-SVR4) id OAA13272; Wed, 1 Oct 1997 14:04:06 -0400 Date: Wed, 1 Oct 1997 14:04:06 -0400 Message-Id: <199710011804.OAA13272@brill.shiva.com> From: John Shriver To: aaronh@wrq.com CC: wsimpson@greendragon.com, ietf-ppp@merit.edu In-reply-to: <199710011557.IAA01787@ursula.wrq.com> (aaronh@wrq.com) Subject: Re: ISDN and RFC-1618 and deprecation Sender: owner-ietf-ppp@merit.edu I think that's very conventional, in Bearer Capability IE if "information transfer capability" is "restricted digital information" and "information transfer rate" is 64 kbit/s, then it's 56k. Those octets of the Bearer IE darned well be universal. But are we standardizing PPP over ISDN, or are we teaching people about ISDN? I suppose would could say that PPP over ISDN must support operation over both unrestricted/64k and restricted/64k. We would point out that restricted 64k implies V.110 in 56k sync mode, which is just robbed bit 0. (For the people doing Data Over Voice to cheat the US ISDN tarrifs, we could say MAY operate over speech/64k as if unrestricted/64k "by advance arrangement".) But it does bring up the issue that we might want to note that this is also the way to place a PPP call over the US "Switched 56" service, which was the pre-ISDN digital call in the US. If you do that, you interoperate with ISDN. (There are ISP's who save money by getting a T1 of Switched 56, and offer "ISDN" service over that. Saves them money, costs the customer 8k off the top.) - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Oct 1 14:36:51 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id OAA22725; Wed, 1 Oct 1997 14:35:29 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 1 Oct 1997 14:35:16 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA22701 for ietf-ppp-outgoing; Wed, 1 Oct 1997 14:35:16 -0400 (EDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm002-14.dialip.mich.net [141.211.7.150]) by merit.edu (8.8.7/8.8.5) with SMTP id OAA22688 for ; Wed, 1 Oct 1997 14:35:11 -0400 (EDT) Date: Wed, 1 Oct 97 17:19:15 GMT From: "William Allen Simpson" Message-ID: <6611.wsimpson@greendragon.com> To: ietf-ppp@merit.edu Subject: Re: ISDN and RFC-1618 and deprecation Sender: owner-ietf-ppp@merit.edu Actually, normal RFC-1618 already gives you this. That's why bit-sync was chosen over octet-sync. No octets. > From: "Aaron Hanson" > On the subject of a new draft for RFC-1618, could something be added to > address PPP over non-clear channel ISDN? For example, 56k services where > bit seven can't be used due to bit-robbing for trunk signaling? I believe > there is a de-facto standard of using a V.110 bit-synchronous HDLC mode. > WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Oct 1 20:27:11 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id UAA28396; Wed, 1 Oct 1997 20:25:38 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 1 Oct 1997 20:25:19 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id UAA28378 for ietf-ppp-outgoing; Wed, 1 Oct 1997 20:25:19 -0400 (EDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm066-10.dialip.mich.net [141.211.5.140]) by merit.edu (8.8.7/8.8.5) with SMTP id UAA28373 for ; Wed, 1 Oct 1997 20:25:14 -0400 (EDT) Date: Thu, 2 Oct 97 00:02:50 GMT From: "William Allen Simpson" Message-ID: <6614.wsimpson@greendragon.com> To: ietf-ppp@merit.edu Subject: ISDN call for experience Sender: owner-ietf-ppp@merit.edu When going from Proposed to Draft Standard, we need to document experience with the various options. This is a call for experience with PPP over ISDN. Please indicate (privately or on the list) which option combinations that you support, and I will prepare a public summary. B-Channel 56Kbps bit-synchronous HDLC NRZ B-Channel 56Kbps bit-synchronous HDLC NRZI B-Channel 64Kbps bit-synchronous HDLC NRZ B-Channel 64Kbps bit-synchronous HDLC NRZI B-Channel 64Kbps octet-synchronous HDLC (NRZ-only) B-Channel PPP in X.25 (NRZ-only) B-Channel PPP in Frame Relay (NRZ-only) D-Channel PPP in X.25 (NRZ-only) D-Channel PPP in Frame Relay (NRZ-only) Please note: we need interoperability demonstrated between 2 or more vendors for each option. Any option not demonstrating interoperability at this stage in the IETF process must be deprecated. Over 3 years is far more than the minimum 6 months required for advancement. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Oct 1 21:49:02 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id VAA29512; Wed, 1 Oct 1997 21:47:34 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 1 Oct 1997 21:47:01 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id VAA29490 for ietf-ppp-outgoing; Wed, 1 Oct 1997 21:47:01 -0400 (EDT) Received: from avago.anu.edu.au (paulus@avago.anu.edu.au [150.203.162.34]) by merit.edu (8.8.7/8.8.5) with SMTP id VAA29486 for ; Wed, 1 Oct 1997 21:46:51 -0400 (EDT) Received: (from paulus@localhost) by avago.anu.edu.au (8.6.12/8.6.9) id LAA00530; Thu, 2 Oct 1997 11:46:37 +1000 Date: Thu, 2 Oct 1997 11:46:37 +1000 Message-Id: <199710020146.LAA00530@avago.anu.edu.au> From: Paul Mackerras To: ietf-ppp@merit.edu In-reply-to: <5010400011710890000002L002*@MHS> (message from John Martz on Wed, 1 Oct 1997 09:16:51 -0400) Subject: Re: PPP Implementations Reply-to: Paul.Mackerras@cs.anu.edu.au Sender: owner-ietf-ppp@merit.edu John Martz wrote: > >> Linux is probably written with proper stack, which can be considered for > >> dialing into using win95. > > Which Linux??? Which PPP for Linux??? I'm not saying your wrong, I'm just > saying that in my admittedly very limited understanding of Linux, there seems > to be a lot of diversity out there. The one publically available version of PPP > that I looked at was supposedly a Linux PPP (among other platforms). It > defaults the receiving ACCM to 0 or whatever was previously negotiated, which > is non-compliant. That's probably mine, and yes, it defaults the receiving ACCM to 0 at the start of negotiations, which is wrong, and I'll change it. It's been that way since 1994, when I put in the receiving ACCM stuff (the code base I started with didn't have a receiving ACCM). Interestingly, having it that way doesn't seem to have caused any noticeable problems (not that that is an argument for leaving it that way). Back then, I also put in code to set the receiving ACCM to ffffffff if the peer didn't negotiate the ACCM. I got requests to "put it back the way it was" (i.e. set the receiving ACCM to 0 if it wasn't negotiated) because apparently at that stage Annex terminal servers didn't include an ACCM in their conf-req, but then didn't escape any control characters in non-LCP packets. No doubt Annex have fixed this by now. At the time, I considered that this came under the category of being generous in what you accept and strict in what you sent. Paul. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Oct 2 12:48:11 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id MAA10328; Thu, 2 Oct 1997 12:46:16 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 2 Oct 1997 12:41:59 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id MAA10249 for ietf-ppp-outgoing; Thu, 2 Oct 1997 12:41:59 -0400 (EDT) Received: from directors.rdl.co.uk (directors.rdl.co.uk [193.119.77.2]) by merit.edu (8.8.7/8.8.5) with ESMTP id MAA10245 for ; Thu, 2 Oct 1997 12:41:52 -0400 (EDT) Received: from imaccgw.rdl.co.uk (imaccgw.rdl.co.uk [193.240.106.205]) by directors.rdl.co.uk (8.7.3/8.7.3) with SMTP id RAA01916 for ; Thu, 2 Oct 1997 17:41:50 +0100 (BST) Received: from ccMail by imaccgw.rdl.co.uk (IMA Internet Exchange 1.04b) id 433cceb0; Thu, 2 Oct 97 17:33:47 +0100 Mime-Version: 1.0 Date: Thu, 2 Oct 1997 17:19:05 +0100 Message-ID: <433cceb0@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re: Using default receive ACCM of 0 for LCP negotiation To: ietf-ppp@merit.edu Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: owner-ietf-ppp@merit.edu (Sorry to bore everyone with this again, but I feel compelled to reply to Bill's observations) Bill Simpson writes: > PPP was carefully designed to start with non-optimal performance, and > negotiate towards improved performance. By definition, in this less > optimal state, every packet gets thru successfully. It was deemed > that it is better to have _some_ performance than _no_ performance. Yes, I understand that (and agree with it wholeheartedly). In fact I appreciate it well enough to be able to point out one part of PPP which doesn't follow that rule, namely Self-Describing Padding (especially as applied in the original DESE spec). >> If a device is configured to attempt to negotiate the Rx ACCM to zero, >> then if that configuration is correct, there will be no problems if >> the ACCM is applied immediately instead of once LCP is open. >> ... If the local device isn't >> discarding these control characters then it may never receive the >> Nak, but with sufficient retries this is unlikely, unless something >> injects characters into every single frame. ... > If the assumption is _incorrect_, then the peers never successfully > negotiate. And thus, zero performance. A built-in failure mode! Well, obviously. But either one peer or the other has to be configured with the correct ACCM if it's to be negotiated down from 0xffffffff, and the usual place to it is the receiving peer. So if the receiving peer is configured correctly and applies its ACCM early, then there won't be any problems. Yes, that "if" is an assumption, but in real life people seem to able make it and get away with it - I'm just trying to explain how come it is that those who have implemented it this way may never have noticed that they've done it wrong. > And of course, the second byte of a PPP header just happens to be > 0x03, ETX, which just happens to hang up some modems. Every time. > Retries don't help. What's that got to do with it ? We're talking about what happens when characters are received from the modem, not sent to it. >> > If this were a bit-stuffed ISDN sync interface, then of course, the >> > ACCM is zero (0). See RFC-1662 page 14. >> >> As I've said before, saying that the ACCM for bit-stuffed ISDN is >> zero is misleading. The ACCM simply doesn't apply to bit-stuffed >> ISDN. >> >Fascinating. Repetition somehow makes this statement correct? Ah, I've used the wrong technique to try to get my message across. Maybe I should've tried rudeness instead. Seriously, though, maybe I didn't explain myself very well. When I said that the ACCM doesn't apply, I meant that it has nothing to do with the format of the frames on the ISDN link. > And how exactly does _your_ sync code work without handling the ACCM? It does handle the ACCM negotiation - and it ignores it once it's been negotiated. > When was the last time _you_ tested against an async-sync converter? Quite recently, actually, and with several different (market leading) devices. No problems at all ! >> If you have a sync/async converting TA at one end of the ISDN link, then >> the value that the async peer has to use as its TX ACCM could be >> anything at all, and, depending upon the TA, it is this value that the >> ISDN peer is negotiating as its RX ACCM. >> >No, it is not "anything at all". It is 0xffffffff, up to and until >something else is negotiated. Well, how come you said it was "zero (0)" ? It can't be both 0 and 0xffffffff. Clearly, I don't understand what you mean about the ACCM being 0 for bit-sync ISDN, so please educate me. Are you saying that ISDN peers are required to request an ACCM value of zero in their configure requests ? Or that the sync/async converter has to use a value of zero for its RX ACCM (once LCP is open) if the ACCM is not negotiated explicitly ? Anyway, what I meant by the value of the ACCM was the value to which it is negotiated (i.e. the value it takes after negotiation is complete) - and this value can be "anything at all". >I am only interested in 100% reliability. I certainly do not design >protocols that have built-in failure modes! I agree, protocols have to be 100% reliable. >With this attitude, no wonder the lawyers are trying to change the >Uniform Commercial Code so that they have no liability for software >failure.... I don't have that attitude - I want my software to be 100% reliable just as much you want yours to be. But I'm not going to condemn other people for whom it's more important that their products interwork with some broken peers than to work 100% reliably in conjunction with all types of modems, etc. (In any case, if they specify the circumstances in which the product won't work, I wouldn't have thought that the lawyers need be involved). >... > Some folks "just don't get it". It's all very well for you to preach from your ivory tower, but if the company that pays my salary ever demands that I produce an implementation which interoperates with a certain broken peer, and the only way I can do this is by producing a non-compliant implementation myself, what am I supposed to do ? Say that I can't do it for the reason that I have a religious duty to attempt to enforce standards compliance? So I don't condemn anyone who's been in a similar situation and had to produce a non-compliant implementation (of course, if they did it out of ignorance, it's their own fault and I have no sympathy). Paul Mackerras writes: ] > The one publically available version of PPP that I looked at was ] > supposedly a Linux PPP (among other platforms). It ] > defaults the receiving ACCM to 0 or whatever was previously ] > negotiated, which is non-compliant. ] That's probably mine, and yes, it defaults the receiving ACCM to 0 ] at the start of negotiations, which is wrong, and I'll change it. ] It's been that way since 1994, when I put in the receiving ACCM ] stuff (the code base I started with didn't have a receiving ACCM). ] Interestingly, having it that way doesn't seem to have caused any ] noticeable problems (not that that is an argument for leaving it ] that way). Which nicely summarises what I've been trying to say all along... --- Jonathan Goodchild - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Oct 2 14:16:11 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id OAA11954; Thu, 2 Oct 1997 14:14:38 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 2 Oct 1997 14:14:05 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA11929 for ietf-ppp-outgoing; Thu, 2 Oct 1997 14:14:04 -0400 (EDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by merit.edu (8.8.7/8.8.5) with ESMTP id OAA11924 for ; Thu, 2 Oct 1997 14:14:00 -0400 (EDT) Received: from skank.juniper.net (skank.juniper.net [208.197.169.216]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id LAA26467; Thu, 2 Oct 1997 11:13:28 -0700 (PDT) Received: from skank.juniper.net (localhost.juniper.net [127.0.0.1]) by skank.juniper.net (8.8.4/8.7.3) with ESMTP id LAA29411; Thu, 2 Oct 1997 11:17:58 -0700 (PDT) Message-Id: <199710021817.LAA29411@skank.juniper.net> X-Mailer: exmh version 1.6.9 8/22/96 To: gmgross@lucent.com, mjk@nj.paradyne.com, alin@cisco.com, malis@casc.com, john@cayman.com cc: ietf-ppp@merit.edu Subject: PPP over ATM LCP option restrictions Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 02 Oct 1997 11:17:49 -0700 From: Dennis Ferguson Sender: owner-ietf-ppp@merit.edu Hello, I'd like to understand why both the PPP over AAL5 and PPP over FUNI drafts have an absolute restriction against accepting an ACFC or FCS option request from a neighbour. Both these options do appear to be meaningless in the context of a purely ATM connection (much like the ACCM option is meaningless if you aren't attached to an async circuit). It is possible, however, that the ATM-attached station is actually talking to its peer through a box which reframes the ATM frames onto a bit-synchronous HDLC circuit, and that the converter box may be quite happy to do ACFC and/or an alternative FCS on the HDLC circuit. In this case the prohibition against the ATM station accepting these options prevents one from doing something that seems quite reasonable to want to do. Would it not, then, be less constraining to simply state that neither of these options have any effect on the ATM connection, but to leave whether they are accepted or not when a peer requests them up to the ATM implementation's configuration? Or is there some damage that can occur if one of these options is accepted? Dennis Ferguson - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Oct 2 15:10:35 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id PAA12871; Thu, 2 Oct 1997 15:09:13 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 2 Oct 1997 15:08:57 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id PAA12839 for ietf-ppp-outgoing; Thu, 2 Oct 1997 15:08:56 -0400 (EDT) Received: from SantaClara01.pop.internex.net (santaclara01.pop.InterNex.Net [205.158.3.18]) by merit.edu (8.8.7/8.8.5) with ESMTP id PAA12831 for ; Thu, 2 Oct 1997 15:08:51 -0400 (EDT) Received: from flowpoint.com ([192.84.210.69]) by SantaClara01.pop.internex.net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-34792U7500L7500S0) with ESMTP id AAA12795; Thu, 2 Oct 1997 12:08:37 -0700 Received: from localhost (pmr@localhost) by flowpoint.com (8.8.4/8.8.4) with SMTP id MAA23632; Thu, 2 Oct 1997 12:07:32 -0700 Date: Thu, 2 Oct 1997 12:07:32 -0700 (PDT) From: Philip Rakity X-Sender: pmr@flowpnt To: Dennis Ferguson cc: gmgross@lucent.com, mjk@nj.paradyne.com, alin@cisco.com, malis@casc.com, john@cayman.com, ietf-ppp@merit.edu Subject: Re: PPP over ATM LCP option restrictions In-Reply-To: <199710021817.LAA29411@skank.juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Dennis, I believe the reason is that that the PPP link is between two devices over AAL5 (eg point to point). It is not a tunnel. regards, Philip On Thu, 2 Oct 1997, Dennis Ferguson wrote: > Hello, > > I'd like to understand why both the PPP over AAL5 and PPP over FUNI drafts > have an absolute restriction against accepting an ACFC or FCS option request > from a neighbour. > > Both these options do appear to be meaningless in the context of a purely > ATM connection (much like the ACCM option is meaningless if you aren't > attached to an async circuit). It is possible, however, that the > ATM-attached station is actually talking to its peer through a box which > reframes the ATM frames onto a bit-synchronous HDLC circuit, and that the > converter box may be quite happy to do ACFC and/or an alternative FCS on > the HDLC circuit. In this case the prohibition against the ATM station > accepting these options prevents one from doing something that seems quite > reasonable to want to do. > > Would it not, then, be less constraining to simply state that neither of > these options have any effect on the ATM connection, but to leave whether > they are accepted or not when a peer requests them up to the ATM > implementation's configuration? Or is there some damage that can occur > if one of these options is accepted? > > Dennis Ferguson > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Oct 2 16:23:53 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id QAA14120; Thu, 2 Oct 1997 16:22:18 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 2 Oct 1997 16:21:54 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id QAA14102 for ietf-ppp-outgoing; Thu, 2 Oct 1997 16:21:53 -0400 (EDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by merit.edu (8.8.7/8.8.5) with ESMTP id QAA14098 for ; Thu, 2 Oct 1997 16:21:47 -0400 (EDT) Received: from skank.juniper.net (skank.juniper.net [208.197.169.216]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id NAA28651; Thu, 2 Oct 1997 13:21:03 -0700 (PDT) Received: from skank.juniper.net (localhost.juniper.net [127.0.0.1]) by skank.juniper.net (8.8.4/8.7.3) with ESMTP id NAA00632; Thu, 2 Oct 1997 13:25:34 -0700 (PDT) Message-Id: <199710022025.NAA00632@skank.juniper.net> X-Mailer: exmh version 1.6.9 8/22/96 To: Philip Rakity cc: gmgross@lucent.com, mjk@nj.paradyne.com, alin@cisco.com, malis@casc.com, john@cayman.com, ietf-ppp@merit.edu Subject: Re: PPP over ATM LCP option restrictions In-reply-to: Your message of "Thu, 02 Oct 1997 12:07:32 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 02 Oct 1997 13:25:33 -0700 From: Dennis Ferguson Sender: owner-ietf-ppp@merit.edu Philip, > I believe the reason is that that the PPP link is between two devices over > AAL5 (eg point to point). It is not a tunnel. This doesn't seem right. Note that ACCM is explicitly allowed, and must be acknowleged when received, even though ACCM is just as meaningless as ACFC and alternate FCS if both PPP end points are connected solely by ATM. The same end-point which would benefit from the negotiation of a new ACCM might also benefit from being able to similarly negotiate ACFC, and perhaps even alternate FCS, so it seems inconsistent to explicitly allow one but explicitly disallow the others. It seems to me just defining ACFC as being acceptable if one is configured to allow it, but constraining ACFC from having any effect on the ATM framing when negotiated, maximizes flexibility in accomodating odd configurations while having no effect on interoperability if both ends do happen to be ATM-attached. I don't see a problem, so I'm wondering what I'm missing. Dennis Ferguson - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Oct 2 16:35:42 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id QAA14325; Thu, 2 Oct 1997 16:34:20 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 2 Oct 1997 16:34:13 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id QAA14307 for ietf-ppp-outgoing; Thu, 2 Oct 1997 16:34:12 -0400 (EDT) Received: from SantaClara01.pop.internex.net (santaclara01.pop.InterNex.Net [205.158.3.18]) by merit.edu (8.8.7/8.8.5) with ESMTP id QAA14303 for ; Thu, 2 Oct 1997 16:34:08 -0400 (EDT) Received: from flowpoint.com ([192.84.210.69]) by SantaClara01.pop.internex.net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-34792U7500L7500S0) with ESMTP id AAA17501; Thu, 2 Oct 1997 13:33:58 -0700 Received: from localhost (pmr@localhost) by flowpoint.com (8.8.4/8.8.4) with SMTP id NAA04217; Thu, 2 Oct 1997 13:32:53 -0700 Date: Thu, 2 Oct 1997 13:32:53 -0700 (PDT) From: Philip Rakity X-Sender: pmr@flowpnt To: Dennis Ferguson cc: gmgross@lucent.com, mjk@nj.paradyne.com, alin@cisco.com, malis@casc.com, john@cayman.com, ietf-ppp@merit.edu Subject: Re: PPP over ATM LCP option restrictions In-Reply-To: <199710022025.NAA00632@skank.juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Denis, ACFC is meaningless in the context of VC multiplexing using AAL5. The OxFF03 is never there even in LCP packets. Similarly, it is not there in LLC multiplexed packets. Philip On Thu, 2 Oct 1997, Dennis Ferguson wrote: > Philip, > > > I believe the reason is that that the PPP link is between two devices over > > AAL5 (eg point to point). It is not a tunnel. > > This doesn't seem right. Note that ACCM is explicitly allowed, and must > be acknowleged when received, even though ACCM is just as meaningless as ACFC > and alternate FCS if both PPP end points are connected solely by ATM. The > same end-point which would benefit from the negotiation of a new ACCM might > also benefit from being able to similarly negotiate ACFC, and perhaps even > alternate FCS, so it seems inconsistent to explicitly allow one but explicitly > disallow the others. > > It seems to me just defining ACFC as being acceptable if one is configured > to allow it, but constraining ACFC from having any effect on the > ATM framing when negotiated, maximizes flexibility in accomodating odd > configurations while having no effect on interoperability if both ends > do happen to be ATM-attached. I don't see a problem, so I'm wondering > what I'm missing. > > Dennis Ferguson > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Oct 2 17:14:02 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id RAA15022; Thu, 2 Oct 1997 17:12:41 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 2 Oct 1997 17:12:32 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id RAA15001 for ietf-ppp-outgoing; Thu, 2 Oct 1997 17:12:31 -0400 (EDT) Received: from cbgw2.lucent.com (cbgw2.lucent.com [207.24.196.52]) by merit.edu (8.8.7/8.8.5) with SMTP id RAA14997 for ; Thu, 2 Oct 1997 17:12:27 -0400 (EDT) Cc: gmgross@lucent.com, mjk@nj.paradyne.com, alin@cisco.com, malis@casc.com, john@cayman.com, ietf-ppp@merit.edu Received: from garage.lucent.com by cbig2.firewall.lucent.com (SMI-8.6/EMS-L sol2) id RAA22297; Thu, 2 Oct 1997 17:11:22 -0400 Received: by garage.lucent.com (5.0/EMS-L sol2) id AA25626; Thu, 2 Oct 1997 17:09:33 -0400 Date: Thu, 2 Oct 1997 17:09:33 -0400 Message-Id: <9710022109.AA25626@garage.lucent.com> From: gmg@garage.lucent.com (garage!gmg) To: Philip Rakity , Dennis Ferguson Original-Cc: gmgross@lucent.com, mjk@nj.paradyne.com, alin@cisco.com, malis@casc.com, john@cayman.com, ietf-ppp@merit.edu Subject: Re: PPP over ATM LCP option restrictions Content-Type: text Sender: owner-ietf-ppp@merit.edu Hi, I had floated E-mail to the list on this topic last week, and had not heard anything from anybody until now. In that E-mail I inquired if people would be okay with adding a paragraph on "async to AAL5 conversion" in the LCP configuration section. One could a imagine a hypothetical TA-like device that has an async connection to a PC, and ATM AAL5 on the WAN side (i.e. xDSL). In this context, allowing async framing negotiation might make sense if the AAL5 end points ignored them. The TA gadget would do ACCM, FCS alternatives, what ever. My point of view is flexible on this topic, I put out the ID v2 saying that ACCM option negotiation is okay, and is ignored by the AAL5 end points, analogous to what is said in RFC1662 section 6. If allowing all the LCP framing options would also make sense, I'll revise the ID's text. However, I'd like to hear others chime in (i.e. rough consensus)... George Gross Lucent Technologies (908) 580-4589 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Oct 2 17:13:19 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id RAA14989; Thu, 2 Oct 1997 17:11:55 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 2 Oct 1997 17:11:30 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id RAA14967 for ietf-ppp-outgoing; Thu, 2 Oct 1997 17:11:30 -0400 (EDT) Received: from coppermountain.com (bromo.coppermountain.com [206.71.190.2]) by merit.edu (8.8.7/8.8.5) with ESMTP id RAA14963 for ; Thu, 2 Oct 1997 17:11:25 -0400 (EDT) Received: by coppermountain.com from localhost (router,SLMail V2.5); Thu, 02 Oct 1997 14:11:47 -0800 Received: by coppermountain.com from eric (206.71.190.13::mail daemon; unverified,SLMail V2.5); Thu, 02 Oct 1997 14:11:46 -0800 Message-Id: <2.2.32.19971002211221.00307440@coppermountain.com> X-Sender: "Eric Michelsen" X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 02 Oct 1997 14:12:21 -0700 To: ietf-ppp@merit.edu From: "Eric L. Michelsen" Subject: Re: Using default receive ACCM of 0 for LCP negotiation Sender: owner-ietf-ppp@merit.edu I think we can clarify this whole mess by noticing the change in communications equipment that has occurred since ACCM was invented, and today. Once upon a time, there was async communication equipment that would introduce spurious characters into the data stream, typically stuff like XON and XOFF. Secondly, there was communication equipment that would croak if you sent certain characters, stuff like XON/XOFF and ETX. ACCM had 2 separate functions: (1) allow you to discard spurious characters introduced by the comm equipment, and (2) allow you to send arbitrary data without croaking your comm link. Now in those days, you *had* to discard the ACCM characters from your Rx stream, because they were not sent by your peer, they were introduced by the comm equipment. If you didn't discard them, you'd get CRC errors. There was nothing "generous" about keeping them; in fact, it was detrimental. And of course, you had to escape your outbound characters, to keep your link up. Times changed. Today, there is very little equipment that introduces spurious characters. If you Rx a character, it is because your peer sent it to you. The change in comm equipment allowed a bug to creep into ACCM implementations: they stopped discarding Rx ACCM characters. The key point here is that this bug interoperates with compliant peers. Compliant peers never send ACCM chars, so (with new comm equipment) buggy Rx implementations never receive them. And the bug goes unknown. Like a virus, the bug spread. This first bug then allowed another bug to appear: some implementations stopped escaping the Tx'd ACCM chars (or equivalently, got their ACCM mask wrong). But these buggy senders would interoperate with buggy receivers. However, they *won't* interoperate with *compliant* receivers. Weak testing allowed the Tx bug to become pervasive. Which brings us to today: compliant ACCM implementations will work with (now non-existent) comm equipment that introduces spurious chars, but *won't* work with Tx-bug peers. So vendors (with real sales and support to worry about) are in an awkward position: do I make a compliant product for non-existent equipment, or do I make a non-compliant product for maximum interoperability? I won't make a recommendation. But I *really* like the idea of an independent testing lab that certifies that an implementation is compliant or not. Having that little sticker "michelsen certified PPP compliant" would soon become a marketing requirement, if "michelsen labs" had some credibility. And it would greatly speed bug-fixing and compliance. -- Eric L. Michelsen, Copper Mountain Networks, Inc. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Oct 2 18:17:32 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id SAA16247; Thu, 2 Oct 1997 18:16:02 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 2 Oct 1997 18:15:45 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id SAA16229 for ietf-ppp-outgoing; Thu, 2 Oct 1997 18:15:44 -0400 (EDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by merit.edu (8.8.7/8.8.5) with ESMTP id SAA16225 for ; Thu, 2 Oct 1997 18:15:38 -0400 (EDT) Received: from skank.juniper.net (skank.juniper.net [208.197.169.216]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id PAA00696; Thu, 2 Oct 1997 15:15:06 -0700 (PDT) Received: from skank.juniper.net (localhost.juniper.net [127.0.0.1]) by skank.juniper.net (8.8.4/8.7.3) with ESMTP id PAA01575; Thu, 2 Oct 1997 15:19:37 -0700 (PDT) Message-Id: <199710022219.PAA01575@skank.juniper.net> X-Mailer: exmh version 1.6.9 8/22/96 To: Philip Rakity cc: gmgross@lucent.com, mjk@nj.paradyne.com, alin@cisco.com, malis@casc.com, john@cayman.com, ietf-ppp@merit.edu Subject: Re: PPP over ATM LCP option restrictions In-reply-to: Your message of "Thu, 02 Oct 1997 13:32:53 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 02 Oct 1997 15:19:32 -0700 From: Dennis Ferguson Sender: owner-ietf-ppp@merit.edu Philip, > ACFC is meaningless in the context of VC multiplexing using AAL5. The > OxFF03 is never there even in LCP packets. Similarly, it is not there in > LLC multiplexed packets. I think I pointed that out. I also think I pointed out that ACCM is similarly meaningless in the ATM context because no escaping of control characters is done, but specifying accept-but-ignore behaviour for ACCM doesn't seem to break anything. So the question, again, is why unconditional rejection of the options was chosen over possibly-accept-but-always-ignore. Both of these alternatives have identical consequences for the ATM network framing (i.e. none at all), but the latter allows additional flexibility on networks where framing converters might be present. I note that the always-reject-ACFC behaviour may have been inherited from RFC 1973. Accept-but-ignore would appear to work equally well (or poorly) there too. Dennis Ferguson - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Oct 2 18:44:24 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id SAA16720; Thu, 2 Oct 1997 18:42:56 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 2 Oct 1997 18:42:36 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id SAA16698 for ietf-ppp-outgoing; Thu, 2 Oct 1997 18:42:35 -0400 (EDT) Received: from SantaClara01.pop.internex.net (santaclara01.pop.InterNex.Net [205.158.3.18]) by merit.edu (8.8.7/8.8.5) with ESMTP id SAA16694 for ; Thu, 2 Oct 1997 18:42:31 -0400 (EDT) Received: from flowpoint.com ([192.84.210.69]) by SantaClara01.pop.internex.net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-34792U7500L7500S0) with ESMTP id AAA25103; Thu, 2 Oct 1997 15:42:26 -0700 Received: from localhost (pmr@localhost) by flowpoint.com (8.8.4/8.8.4) with SMTP id PAA06898; Thu, 2 Oct 1997 15:41:22 -0700 Date: Thu, 2 Oct 1997 15:41:22 -0700 (PDT) From: Philip Rakity X-Sender: pmr@flowpnt Reply-To: Philip Rakity To: Dennis Ferguson cc: gmgross@lucent.com, mjk@nj.paradyne.com, alin@cisco.com, malis@casc.com, john@cayman.com, ietf-ppp@merit.edu Subject: Re: PPP over ATM LCP option restrictions In-Reply-To: <199710022219.PAA01575@skank.juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Dennis, I think there is a bigger issue here and I need everyone's help in understanding what the correct thing to do is. The situation as you point out is as follows TA End System ---- TA/AAL5 Convertor ----- AAL5 End System The PPP link from the TA's point of view is between both End Systems. The question is what actions is the TA/AAL5 convertor responsible for. I was answering you note from the point of view that the TA/AAL5 convertor did the work and thus made the AAL5 to TA/AAL5 link look like pure AAL5. There is another point of view that says that the LCP session is not logically hop by hop, but end to end. What is confusing me, is that I have not read an RFC about what actions an end system takes on receiving options that have no meaning. Eg AFPC, FCS. The convertor must remove the FF03 sent by the TA before forwarding the frame. Similarly, it must leave the FF03 on the LCP packets being sent by the AAL5 system. So, if it is smart enough to do all of this, then it must be smart enough to modify the negotation rules for FCS or AFPC. I am not saying what I have previously said if right; but I am at a loss to see where the consistent actions are defined for a PPP/AAL5 End Point which receives options which are meaningless. (I am assuming that the AAL5 End Point does NOT request FCS a new FCS if it was proposed !!) Philip Rakity FlowPoint On Thu, 2 Oct 1997, Dennis Ferguson wrote: > Philip, > > > ACFC is meaningless in the context of VC multiplexing using AAL5. The > > OxFF03 is never there even in LCP packets. Similarly, it is not there in > > LLC multiplexed packets. > > I think I pointed that out. I also think I pointed out that ACCM is > similarly meaningless in the ATM context because no escaping of control > characters is done, but specifying accept-but-ignore behaviour for ACCM > doesn't seem to break anything. > > So the question, again, is why unconditional rejection of the options was > chosen over possibly-accept-but-always-ignore. Both of these alternatives > have identical consequences for the ATM network framing (i.e. none at > all), but the latter allows additional flexibility on networks where > framing converters might be present. > > I note that the always-reject-ACFC behaviour may have been inherited > from RFC 1973. Accept-but-ignore would appear to work equally well > (or poorly) there too. > > Dennis Ferguson > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Oct 2 22:21:05 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id WAA19766; Thu, 2 Oct 1997 22:18:01 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 2 Oct 1997 22:17:19 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id WAA19748 for ietf-ppp-outgoing; Thu, 2 Oct 1997 22:17:18 -0400 (EDT) Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.8.7/8.8.5) with SMTP id WAA19744 for ; Thu, 2 Oct 1997 22:17:05 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id TAA10491 for <@sgi.engr.sgi.com:ietf-ppp@merit.edu>; Thu, 2 Oct 1997 19:16:57 -0700 env-from (vjs@mica.denver.sgi.com) Received: from mica.denver.sgi.com (mica.denver.sgi.com [169.238.67.6]) by cthulhu.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id PAA29247 for <@sgi.engr.sgi.com:ietf-ppp@merit.edu>; Thu, 2 Oct 1997 15:07:03 -0700 Received: (from vjs@localhost) by mica.denver.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA07141 for ietf-ppp@merit.edu; Thu, 2 Oct 1997 16:06:52 -0600 Date: Thu, 2 Oct 1997 16:06:52 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199710022206.QAA07141@mica.denver.sgi.com> To: ietf-ppp@merit.edu Subject: ACCM and testing labs Sender: owner-ietf-ppp@merit.edu > From: "Eric L. Michelsen" > ... > Which brings us to today: compliant ACCM implementations will work with (now > non-existent) comm equipment that introduces spurious chars, but *won't* > work with Tx-bug peers. So vendors (with real sales and support to worry That sounds like a good description of the situation. > ... > > I won't make a recommendation. But I *really* like the idea of an > independent testing lab that certifies that an implementation is compliant > or not. Having that little sticker "michelsen certified PPP compliant" > would soon become a marketing requirement, if "michelsen labs" had some > credibility. And it would greatly speed bug-fixing and compliance. There speaks someone who has not dealt with testing labs from the vendor's perspective, or at least has not been able to compare certified and uncertified brands of a single product. First, there is already a pretty good test suite for PPP. Just buy the Midnight Networks product (they may have change their name). Second, "you can't test the quality in." For example, I watched FDDI in the early days. At first there was one FDDI test lab that issued certificates. Later there were two. Thanks to the InterOp FDDI demos, I was able to compare all of the major FDDI implementations both on the show floor and in the "hot stagings" which had to be passed if you wanted to be on the show ring. For many years, the worst FDDI junk bore certificates, while the best did not. If there was trouble on the ring, the box at fault was probably officially Certified and Tested by one or both labs. It was not that the test labs were dishonest (they were honest people trying hard) or the tests useless (they caught plenty of bugs). It was simply that you "can't test the quality in." Everyone was busy. Maybe those who spent the substantial time to do the certification dance should have spent a little more time worrying about power supply noise or fans in their boxes, or reading and understanding the draft ANSI standards. Those little "certified" stickers on any product mean one of two things: 1. the product is junk, but with a lot of work and sweat the vendor managed to squeeze through the tests. The bugs that the tests did not look for are still there. Bugs in the test (there always are some) are also present in the product. 2. the product was fine before it was tested, and got the certificate mostly for marketing reasons. The test may have found a few bugs, but they were only minor bugs that users would probably never have found. Certifications rarely find significant bugs in real life. People who care enough to produce good products (and are able to, including being given the time by the bosses and havinve the necessary skills) do not go to the tests until they are confident they have no big bugs. They write good code to start and test it widely before paying for the tests. They actually read the RFCs instead of hacking based on what others thought they read in the trade press. People who produce junk (regardless of whether because they are incompetant, don't care, or don't have the time) just hack a little garbage based on rumors of the standards, rush off to the next bake-off and hope to get other attendees to help them "debug" (i.e. code), hit a test-lab on the way back, and "shipit." Then there is the inevitable problem of bugs in the test suite. In the case of PPP, if the developers and participants in the WG can't get the ACCM right, how can the programmers at the certification lab? They are usually not particularly interested in the product under test. They are given a pile of standards and a textbook, and told to write a test suite. All software, including test suites, has bugs, and because of its genesis, test software always has more bugs than non-junk versions of the product under test. How many people test the test suite compared to the product? What are the commercial consequences of a bug in the product and a bug in the test suite? In every certification dance I've attended, at least half of the supposed bugs in my stuff were in fact bugs in the tests. The business of a test lab is to issue certificates, not to ship good product. The customers of a test lab are not users of the product, but vendors. Think about the implications. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Oct 3 05:39:23 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id FAA23378; Fri, 3 Oct 1997 05:37:13 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 3 Oct 1997 05:33:57 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id FAA23343 for ietf-ppp-outgoing; Fri, 3 Oct 1997 05:33:56 -0400 (EDT) Received: from directors.rdl.co.uk (directors.rdl.co.uk [193.119.77.2]) by merit.edu (8.8.7/8.8.5) with ESMTP id FAA23333 for ; Fri, 3 Oct 1997 05:32:59 -0400 (EDT) Received: from imaccgw.rdl.co.uk (imaccgw.rdl.co.uk [193.240.106.205]) by directors.rdl.co.uk (8.7.3/8.7.3) with SMTP id KAA11286 for ; Fri, 3 Oct 1997 10:32:56 +0100 (BST) Received: from ccMail by imaccgw.rdl.co.uk (IMA Internet Exchange 1.04b) id 434ba410; Fri, 3 Oct 97 10:26:25 +0100 Mime-Version: 1.0 Date: Fri, 3 Oct 1997 10:31:00 +0100 Message-ID: <434ba410@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re: PPP over ATM LCP option restrictions To: ietf-ppp@merit.edu Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: owner-ietf-ppp@merit.edu Dennis Ferguson writes: >> ACFC is meaningless in the context of VC multiplexing using AAL5. The >> OxFF03 is never there even in LCP packets. Similarly, it is not there >> in LLC multiplexed packets. > > I think I pointed that out. I also think I pointed out that ACCM is > similarly meaningless in the ATM context because no escaping of control > characters is done, but specifying accept-but-ignore behaviour for ACCM > doesn't seem to break anything. > > So the question, again, is why unconditional rejection of the options > was chosen over possibly-accept-but-always-ignore. Both of these > alternatives have identical consequences for the ATM network framing > (i.e. none at all), but the latter allows additional flexibility on > networks where framing converters might be present. Exactly; I made the same point about RFC 1598 earlier in the week. > I note that the always-reject-ACFC behaviour may have been > inherited from RFC 1973. And that was inherited from RFC 1598. > Accept-but-ignore would appear to work equally well (or poorly) > there too. Quite. Philip Rakity writes: ] I think there is a bigger issue here and I need everyone's help ] in understanding what the correct thing to do is. ] ] The situation as you point out is as follows ] ] TA End System ---- TA/AAL5 Convertor ----- AAL5 End System ] ] The PPP link from the TA's point of view is between both End ] Systems. ] ] The question is what actions is the TA/AAL5 convertor ] responsible for. ] ] I was answering you note from the point of view that the ] TA/AAL5 convertor did the work and thus made the AAL5 to ] TA/AAL5 link look like pure AAL5. There is another point of ] view that says that the LCP session is not logically hop by ] hop, but end to end. The LCP session has to be end-to-end, otherwise end-to-end authentication is not possible (each hop would have to be authenticated separately - an administrative nightmare). ] What is confusing me, is that I have not read an RFC about ] what actions an end system takes on receiving options that ] have no meaning. Eg AFPC, FCS. The convertor must remove the ] FF03 sent by the TA before forwarding the frame. Similarly, ] it must leave the FF03 on the LCP packets being sent by the ] AAL5 system. (Actually, I think you meant "insert", not "leave".) ] So, if it is smart enough to do all of this, then it must be ] smart enough to modify the negotation rules for FCS or AFPC. Inserting or removing FF03 is trivial; interfering in the LCP negotiation is not. ] I am not saying what I have previously said if right; but I am ] at a loss to see where the consistent actions are defined for a ] PPP/AAL5 End Point which receives options which are ] meaningless. (I am assuming that the AAL5 End Point does NOT ] request FCS a new FCS if it was proposed !!) As Dennis as pointed out, the precedent for this is the requirement of a sync PPP system to negotiate and then ignore the ACCM. So the same should apply to ACFC as well. What happens when you have framing converters at both ends of the link? End System -- Converter ---(AAL5)--- Converter -- End System Neither End System knows antyhing about the AAL5 encapsulation rules, and so would have no reason to reject ACFC, so the only way to be compliant is for the converters to interfere with the LCP negotiation. Accept-but-ignore has got to be preferable. --- Jonathan Goodchild - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Oct 3 09:35:16 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id JAA25406; Fri, 3 Oct 1997 09:33:40 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 3 Oct 1997 09:33:19 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id JAA25378 for ietf-ppp-outgoing; Fri, 3 Oct 1997 09:33:18 -0400 (EDT) Received: from ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.7/8.8.5) with ESMTP id JAA25374 for ; Fri, 3 Oct 1997 09:33:14 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id JAA02861; Fri, 3 Oct 1997 09:33:03 -0400 (EDT) Message-Id: <199710031333.JAA02861@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-l2f-04.txt Date: Fri, 03 Oct 1997 09:33:03 -0400 Sender: owner-ietf-ppp@merit.edu --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : Layer Two Forwarding (Protocol) 'L2F' Author(s) : T. Kolar, M. Littlewood, A. Valencia Filename : draft-ietf-pppext-l2f-04.txt Pages : 28 Date : 02-Oct-97 Virtual dial-up allows many separate and autonomous protocol domains to share common access infrastructure including modems, Access Servers, and ISDN routers. Previous RFCs have specified protocols for supporting IP dial-up via SLIP [1] and multiprotocol dial-up via PPP [2]. This document describes the Layer Two Forwarding protocol (L2F) which permits the tunneling of the link layer (i.e., HDLC, async HDLC, or SLIP frames) of higher level protocols. Using such tunnels, it is possible to divorce the location of the initial dial- up server from the location at which the dial-up protocol connection is terminated and access to the network provided. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-l2f-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-l2f-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-l2f-04.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971002155835.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-l2f-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-l2f-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971002155835.I-D@ietf.org> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Oct 3 12:35:45 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id MAA29062; Fri, 3 Oct 1997 12:33:59 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 3 Oct 1997 12:33:29 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id MAA29030 for ietf-ppp-outgoing; Fri, 3 Oct 1997 12:33:28 -0400 (EDT) Received: from SantaClara01.pop.internex.net (santaclara01.pop.InterNex.Net [205.158.3.18]) by merit.edu (8.8.7/8.8.5) with ESMTP id MAA29021 for ; Fri, 3 Oct 1997 12:33:22 -0400 (EDT) Received: from flowpoint.com ([192.84.210.69]) by SantaClara01.pop.internex.net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-34792U7500L7500S0) with ESMTP id AAA13130; Fri, 3 Oct 1997 09:33:19 -0700 Received: from localhost (pmr@localhost) by flowpoint.com (8.8.4/8.8.4) with SMTP id JAA24143; Fri, 3 Oct 1997 09:32:13 -0700 Date: Fri, 3 Oct 1997 09:32:12 -0700 (PDT) From: Philip Rakity X-Sender: pmr@flowpnt Reply-To: Philip Rakity To: Jonathan Goodchild cc: ietf-ppp@merit.edu Subject: Re: PPP over ATM LCP option restrictions In-Reply-To: <434ba410@rdl.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu I understand the rationale for not making it illegal to send options. If the receiving side does not like the option it is free to NAK or REJECT it. I do not understand what behavior the receiver of the option is supposed to do. For APFC there are no choices. 1. Accept it since the equipment is doing it anyway 2. Reject it since I do not support the option to negotiate its use (since it is always present). Clearly 1) makes sense. For changing the FCS, the remote is asking my system to send an FCS which it is incapable of transmitting. What should happen? Philip Rakity On Fri, 3 Oct 1997, Jonathan Goodchild wrote: > Dennis Ferguson writes: > > >> ACFC is meaningless in the context of VC multiplexing using AAL5. The > >> OxFF03 is never there even in LCP packets. Similarly, it is not there > >> in LLC multiplexed packets. > > > > I think I pointed that out. I also think I pointed out that ACCM is > > similarly meaningless in the ATM context because no escaping of control > > characters is done, but specifying accept-but-ignore behaviour for ACCM > > doesn't seem to break anything. > > > > So the question, again, is why unconditional rejection of the options > > was chosen over possibly-accept-but-always-ignore. Both of these > > alternatives have identical consequences for the ATM network framing > > (i.e. none at all), but the latter allows additional flexibility on > > networks where framing converters might be present. > > Exactly; I made the same point about RFC 1598 earlier in the week. > > > I note that the always-reject-ACFC behaviour may have been > > inherited from RFC 1973. > > And that was inherited from RFC 1598. > > > Accept-but-ignore would appear to work equally well (or poorly) > > there too. > > Quite. > > Philip Rakity writes: > > ] I think there is a bigger issue here and I need everyone's help > ] in understanding what the correct thing to do is. > ] > ] The situation as you point out is as follows > ] > ] TA End System ---- TA/AAL5 Convertor ----- AAL5 End System > ] > ] The PPP link from the TA's point of view is between both End > ] Systems. > ] > ] The question is what actions is the TA/AAL5 convertor > ] responsible for. > ] > ] I was answering you note from the point of view that the > ] TA/AAL5 convertor did the work and thus made the AAL5 to > ] TA/AAL5 link look like pure AAL5. There is another point of > ] view that says that the LCP session is not logically hop by > ] hop, but end to end. > > The LCP session has to be end-to-end, otherwise end-to-end > authentication is not possible (each hop would have to be > authenticated separately - an administrative nightmare). > > ] What is confusing me, is that I have not read an RFC about > ] what actions an end system takes on receiving options that > ] have no meaning. Eg AFPC, FCS. The convertor must remove the > ] FF03 sent by the TA before forwarding the frame. Similarly, > ] it must leave the FF03 on the LCP packets being sent by the > ] AAL5 system. > > (Actually, I think you meant "insert", not "leave".) > > ] So, if it is smart enough to do all of this, then it must be > ] smart enough to modify the negotation rules for FCS or AFPC. > > Inserting or removing FF03 is trivial; interfering in the LCP > negotiation is not. > > ] I am not saying what I have previously said if right; but I am > ] at a loss to see where the consistent actions are defined for a > ] PPP/AAL5 End Point which receives options which are > ] meaningless. (I am assuming that the AAL5 End Point does NOT > ] request FCS a new FCS if it was proposed !!) > > As Dennis as pointed out, the precedent for this is the > requirement of a sync PPP system to negotiate and then ignore the > ACCM. So the same should apply to ACFC as well. > > What happens when you have framing converters at both ends of the > link? > > End System -- Converter ---(AAL5)--- Converter -- End System > > Neither End System knows antyhing about the AAL5 encapsulation rules, > and so would have no reason to reject ACFC, so the only way to be > compliant is for the converters to interfere with the LCP negotiation. > > Accept-but-ignore has got to be preferable. > > --- > Jonathan Goodchild > > > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Oct 3 14:06:33 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id OAA00878; Fri, 3 Oct 1997 14:05:07 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 3 Oct 1997 14:04:42 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA00843 for ietf-ppp-outgoing; Fri, 3 Oct 1997 14:04:42 -0400 (EDT) Received: from coppermountain.com (bromo.coppermountain.com [206.71.190.2]) by merit.edu (8.8.7/8.8.5) with ESMTP id OAA00836 for ; Fri, 3 Oct 1997 14:04:36 -0400 (EDT) Received: by coppermountain.com from localhost (router,SLMail V2.5); Fri, 03 Oct 1997 11:04:55 -0800 Received: by coppermountain.com from eric (206.71.190.13::mail daemon; unverified,SLMail V2.5); Fri, 03 Oct 1997 11:04:54 -0800 Message-Id: <2.2.32.19971003180533.00301248@coppermountain.com> X-Sender: "Eric Michelsen" X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 03 Oct 1997 11:05:33 -0700 To: ietf-ppp@merit.edu From: "Eric L. Michelsen" Subject: Re: PPP over ATM LCP option restrictions Sender: owner-ietf-ppp@merit.edu At 09:32 AM 10/3/97 -0700, Philip Rakity wrote: > >I understand the rationale for not making it illegal to send options. If >the receiving side does not like the option it is free to NAK or REJECT >it. > >I do not understand what behavior the receiver of the option is supposed >to do. > >For APFC there are no choices. > >1. Accept it since the equipment is doing it anyway >2. Reject it since I do not support the option to negotiate its use >(since it is always present). > Clearly 1) makes sense. > >For changing the FCS, the remote is asking my system to send an FCS which >it is incapable of transmitting. What should happen? Essentially, LCP allows negotiation of options which are specific to some underlying framing layers. ACCM, ACFC, FCS are all examples of this. They should all be handled consistently, and as documented for ACCM in RFC 1662. If an implementation has no use for a parameter, then accept it, and let other conversion boxes that may exist deal with the consequences. Anybody doing conversion is responsible for making sure their end(s) negotiate appropriately. Note that PFC is very different from ACFC. PFC has meaning in all framing methods. By the way, I thought the alternate FCS for HDLC-like framing option was withdrawn. Is it still real? -- Eric L. Michelsen, Copper Mountain Networks, Inc. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Oct 3 14:30:58 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id OAA01316; Fri, 3 Oct 1997 14:29:36 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 3 Oct 1997 14:29:24 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA01291 for ietf-ppp-outgoing; Fri, 3 Oct 1997 14:29:23 -0400 (EDT) Received: from coppermountain.com (bromo.coppermountain.com [206.71.190.2]) by merit.edu (8.8.7/8.8.5) with ESMTP id OAA01285 for ; Fri, 3 Oct 1997 14:29:18 -0400 (EDT) Received: by coppermountain.com from localhost (router,SLMail V2.5); Fri, 03 Oct 1997 11:29:33 -0800 Received: by coppermountain.com from eric (206.71.190.13::mail daemon; unverified,SLMail V2.5); Fri, 03 Oct 1997 11:29:32 -0800 Message-Id: <2.2.32.19971003183010.003057d0@coppermountain.com> X-Sender: "Eric Michelsen" X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 03 Oct 1997 11:30:10 -0700 To: ietf-ppp@merit.edu From: "Eric L. Michelsen" Subject: Re: ACCM and testing labs Sender: owner-ietf-ppp@merit.edu At 04:06 PM 10/2/97 -0600, Vernon Schryver wrote: ... >> I won't make a recommendation. But I *really* like the idea of an >> independent testing lab that certifies that an implementation is compliant >> or not. Having that little sticker "michelsen certified PPP compliant" >> would soon become a marketing requirement, if "michelsen labs" had some >> credibility. And it would greatly speed bug-fixing and compliance. > >There speaks someone who has not dealt with testing labs from the >vendor's perspective, or at least has not been able to compare >certified and uncertified brands of a single product. Actually, I have dealt with testing labs, and I share many of your concerns about them. A key issue is credibility of the lab, and in this case, I think participation in the PPP mailing list is a must. But perhaps I *am* too idealistic. > >First, there is already a pretty good test suite for PPP. Just buy the >Midnight Networks product (they may have change their name). If this is a good suite, compliant vendors should boast about having passed it. This would pressure other vendors into claiming the same. I assume this suite catches the obvious problems with ACCM, CHAP re-challenges, etc. that are well known to this list. >Second, "you can't test the quality in." I agree. But you *can* test common and obvious failure modes *out*. >.... It was not that the test labs were dishonest (they >were honest people trying hard) or the tests useless (they caught >plenty of bugs). That's my goal. >...The bugs that the tests did not look for are still there. Well, sure. But it's no worse than the situation today, where *all* the bugs are still in the products. > Bugs in the test (there > always are some) are also present in the product. Perhaps this list could offer consensus on which test suites are reliable. And feedback to the testers on bugs in the test suites. If the industry wants interoperability, concensus on testing would surely help. Do other folks out there have recommendations for test suites? Note that we've already seen how unreliable interoperability testing can be. Tx-bug ACCM products interoperate with Rx-bug ACCM products, but both are non-compliant. >... > 2. the product was fine before it was tested, and got the certificate > mostly for marketing reasons. The test may have found a few > bugs, but they were only minor bugs that users would probably > never have found. Seems like ACCM bugs are being found by users, and trivial for a test suite to catch. > >Certifications rarely find significant bugs in real life. I don't agree, but... > People who >care enough to produce good products (and are able to, including being >given the time by the bosses and havinve the necessary skills) do not >go to the tests until they are confident they have no big bugs. They >write good code to start and test it widely before paying for the >tests. They actually read the RFCs instead of hacking based on what >others thought they read in the trade press. I do agree, and... > >People who produce junk (regardless of whether because they are >incompetant, don't care, or don't have the time) just hack a little >garbage based on rumors of the standards, rush off to the next bake-off >and hope to get other attendees to help them "debug" (i.e. code), hit a >test-lab on the way back, and "shipit." And these are the kinds of implementations that test suites help weed out. > >Then there is the inevitable problem of bugs in the test suite. In the >case of PPP, if the developers and participants in the WG can't get the >ACCM right, how can the programmers at the certification lab? By participating in the mailing list. Any PPP test vendor who doesn't has no credibility. >... -- Eric L. Michelsen, Copper Mountain Networks, Inc. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Oct 3 16:10:49 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id QAA03418; Fri, 3 Oct 1997 16:09:10 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 3 Oct 1997 16:07:55 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id QAA03375 for ietf-ppp-outgoing; Fri, 3 Oct 1997 16:07:54 -0400 (EDT) Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.8.7/8.8.5) with SMTP id QAA03309 for ; Fri, 3 Oct 1997 16:03:52 -0400 (EDT) Received: from mica.denver.sgi.com (mica.denver.sgi.com [169.238.67.6]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id NAA27812 for <@sgi.engr.sgi.com:ietf-ppp@merit.edu>; Fri, 3 Oct 1997 13:03:04 -0700 env-from (vjs@mica.denver.sgi.com) Received: (from vjs@localhost) by mica.denver.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA10428 for ietf-ppp@merit.edu; Fri, 3 Oct 1997 14:02:55 -0600 Date: Fri, 3 Oct 1997 14:02:55 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199710032002.OAA10428@mica.denver.sgi.com> To: ietf-ppp@merit.edu Subject: testing and certifications Sender: owner-ietf-ppp@merit.edu > From: "Eric L. Michelsen" > ... > > Bugs in the test (there > > always are some) are also present in the product. It seems I was not clear. Bugs in test suites tend to get forced into the products that are certified to have passed the test suite, even if the bugs were not originally present. Anyone competent who has been dealing with the POSIX test suites in the last few years has some eloquent testimony to that effect. There were some serious bugs in the initial version of the first FDDI suite. Several vendors added those bugs to their systems so they could pass the test, and that caused significant grief in the InterOp "Hot-stagings". (Those were several 1-week efforts where we got together to see how things worked in the months before the shows.) > Perhaps this list could offer consensus on which test suites are reliable. > And feedback to the testers on bugs in the test suites. If the industry > wants interoperability, concensus on testing would surely help. Do other > folks out there have recommendations for test suites? > > Note that we've already seen how unreliable interoperability testing can be. > Tx-bug ACCM products interoperate with Rx-bug ACCM products, but both are > non-compliant. Down that path lies delegating authority for the nature of PPP to the authors of the test suite. People will be forced to build to the test instead of the RFCs. We already have your certifying test suite. I consists of "it must work with X, Y, and Z." By your own analysis, you say that bugs in the de facto test suite have propagated into the field. Giving the imprimatur of the working group to that or any other test suite would make that progression worse. > ... > >People who produce junk (regardless of whether because they are > >incompetant, don't care, or don't have the time) just hack a little > >garbage based on rumors of the standards, rush off to the next bake-off > >and hope to get other attendees to help them "debug" (i.e. code), hit a > >test-lab on the way back, and "shipit." > > And these are the kinds of implementations that test suites help weed out. That is directly contrary to my experience. Please re-read what I wrote about the history of FDDI ceritifications. Any weeding-out was in favor of the junk that got the labels and against the good stuff from those didn't bother. > > > >Then there is the inevitable problem of bugs in the test suite. In the > >case of PPP, if the developers and participants in the WG can't get the > >ACCM right, how can the programmers at the certification lab? > > By participating in the mailing list. Any PPP test vendor who doesn't has > no credibility. Formal credibility in a test suite is not irrelevant, but catastrophic. Credibility in a test suite is a very strong authority for the definition of the thing being tested. You are essentially proposing that the "credible testing lab" would have final say over problems like the ACCM business. That someone writing code, whether a PPP implementation or a test suite, comes to the mailing list does not imply that their code is good or junk. We have represented here both good PPP implementations and junk. There are also both good and junk implementations whose authors are never heard here. (Please don't ask me for my lists.) That an organization or an individual has spent time on the mailing list or the working group implies absolutely nothing about their competance or the value of their products. Suggestions to the contrary are merely familiar standards committee go-er hooey, like the recent suggestions in POISED that IETF WGs should "coordinate" and "liaise" their activities with the ITU. Sheesh--just comtemplate the notion that a compliant implementation or test cannot be built refering only to the standards, that schmoozing here is somehow necessary. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Oct 3 17:24:20 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id RAA04621; Fri, 3 Oct 1997 17:22:55 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 3 Oct 1997 17:22:18 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id RAA04586 for ietf-ppp-outgoing; Fri, 3 Oct 1997 17:22:17 -0400 (EDT) Received: from manny.ops.sprintisp.net (host238.dev.sprintisp.com [205.137.205.238]) by merit.edu (8.8.7/8.8.5) with SMTP id RAA04579 for ; Fri, 3 Oct 1997 17:22:13 -0400 (EDT) Received: by manny.ops.sprintisp.net (SMI-8.6/SMI-SVR4) id OAA14329; Fri, 3 Oct 1997 14:21:41 -0700 Reply-to: msp@corp.sprintmail.com (Mark Petrovic) Message-ID: <19971003162140.15527@corp.sprintmail.com> Date: Fri, 3 Oct 1997 16:21:41 -0500 From: Mark Petrovic To: PPP Working Group Subject: Reproducible bad FCS's into a Cisco 2511 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Mailer: Mutt 0.81 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by merit.edu id RAA04581 Sender: owner-ietf-ppp@merit.edu The following represents the first few frames of a typical data set obtained with a PPP protocol anaylyzer during Win95 PPP negotiation with a Cisco 2511 IOS 11.0(11) terminal server. Quite reproducibly, I obtain an Invalid FCS in Record #5 after the 2nd LCP request from the client. Note that (EQ) indicates frames issued by the Win95 client, while (LN) indicates the incoming frames from the terminal server. Anyone seen this sort of thing before? I've included a few good frames as a follow up, from which point the negotiation is successfully executed. Summary of: Record #1 (LN) Captured on 10.03.97 at 14:48:58.0000000 Leads Status: RTS: On DTR: On CTS: On DSR: On CD: Off Details of: Record #1 (LN) Captured on 10.03.97 at 14:48:58.0000000 Leads Status: RTS: On DTR: On CTS: On DSR: On CD: Off (No displayable hex data) Summary of: Record #2 (LN) Captured on 10.03.97 at 14:49:13.6721161 Leads Status: RTS: On DTR: On CTS: On DSR: On CD: On Details of: Record #2 (LN) Captured on 10.03.97 at 14:49:13.6721161 Leads Status: RTS: On DTR: On CTS: On DSR: On CD: On (No displayable hex data) Summary of: Record #3 (EQ) Captured on 10.03.97 at 14:49:13.7570181 HDLC: Addr = 255; Type = UI; PF = Poll; FCS = Good PPP: Protocol = LCP LCP: Code = CfgReq; ID = 001 Details of: Record #3 (EQ) Captured on 10.03.97 at 14:49:13.7570181 HDLC: Address = 255 Frame Type = 0x03 (UI) Poll/Final = 0 (Poll) FCS = 0x60-27 (Good) PPP: Protocol ID = 0xc021 (Link Control Protocol) LCP: Code = 0x01 (Configure Request) Identifier = 001 Length = 00023 --- Configuration Options --- Char Control Map = 0x00-0a-00-00 Magic Number = 0x01-3e-ce-1f Protocol Compress = On Addr-Ctrl Compress = On Callback Message = 6 (Location by CBCP negotiation) Hex Data of: Record #3 (EQ) Captured on 10.03.97 at 14:49:13.7570181 (length = 29 bytes) ff 03 c0 21 01 01 00 17 02 06 00 0a 00 00 05 06 ÿÀ!   01 3e ce 1f 07 02 08 02 0d 03 06 60 27 >Î `' Summary of: Record #4 (EQ) Captured on 10.03.97 at 14:49:16.7576289 HDLC: Addr = 255; Type = UI; PF = Poll; FCS = Good PPP: Protocol = LCP LCP: Code = CfgReq; ID = 002 Details of: Record #4 (EQ) Captured on 10.03.97 at 14:49:16.7576289 HDLC: Address = 255 Frame Type = 0x03 (UI) Poll/Final = 0 (Poll) FCS = 0x96-d4 (Good) PPP: Protocol ID = 0xc021 (Link Control Protocol) LCP: Code = 0x01 (Configure Request) Identifier = 002 Length = 00023 --- Configuration Options --- Char Control Map = 0x00-0a-00-00 Magic Number = 0x01-3e-ce-1f Protocol Compress = On Addr-Ctrl Compress = On Callback Message = 6 (Location by CBCP negotiation) Hex Data of: Record #4 (EQ) Captured on 10.03.97 at 14:49:16.7576289 (length = 29 bytes) ff 03 c0 21 01 02 00 17 02 06 00 0a 00 00 05 06 ÿÀ!   01 3e ce 1f 07 02 08 02 0d 03 06 96 d4 >Î –Ô Summary of: Record #5 (LN) Captured on 10.03.97 at 14:49:16.8710959 HDLC: (Address and Control Field Compressed); FCS = Bad HDLC: >>> ERROR >>> Invalid FCS Details of: Record #5 (LN) Captured on 10.03.97 at 14:49:16.8710959 HDLC: (Address and Control Field Compressed) FCS = 0x0d-0a (Bad) HDLC: >>> ERROR >>> Invalid FCS Hex Data of: Record #5 (LN) Captured on 10.03.97 at 14:49:16.8710959 (length = 235 bytes) 08 20 08 0d 0a 25 20 45 72 72 6f 72 20 69 6e 20   % E rror in 61 75 74 68 65 6e 74 69 63 61 74 69 6f 6e 2e 0d authenti cation. 0a 0d 0a 0d 0a 0d 0a 57 65 6c 63 6f 6d 65 20 74 W elcome t 6f 20 53 70 72 69 6e 74 2d 69 70 0d 0a 0d 0a 45 o Sprint -ip E 6e 74 65 72 69 6e 67 20 50 50 50 20 6d 6f 64 65 ntering PPP mode 2e 0d 0a 41 73 79 6e 63 20 69 6e 74 65 72 66 61 . Async interfa 63 65 20 61 64 64 72 65 73 73 20 69 73 20 75 6e ce addre ss is un 6e 75 6d 62 65 72 65 64 20 28 45 74 68 65 72 6e numbered (Ethern 65 74 30 29 0d 0a 59 6f 75 72 20 49 50 20 61 64 et0) Yo ur IP ad 64 72 65 73 73 20 69 73 20 32 30 36 2e 31 33 33 dress is 206.133 2e 31 36 31 2e 32 30 35 2e 20 4d 54 55 20 69 73 .161.205 . MTU is 20 31 35 30 30 20 62 79 74 65 73 0d 0a 48 65 61 1500 by tes Hea 64 65 72 20 63 6f 6d 70 72 65 73 73 69 6f 6e 20 der comp ression 77 69 6c 6c 20 6d 61 74 63 68 20 79 6f 75 72 20 will mat ch your 73 79 73 74 65 6d 2e 0d 0a 0d 0a system. Summary of: Record #6 (EQ) Captured on 10.03.97 at 14:49:19.7649985 HDLC: Addr = 255; Type = UI; PF = Poll; FCS = Good PPP: Protocol = LCP LCP: Code = CfgReq; ID = 003 Details of: Record #6 (EQ) Captured on 10.03.97 at 14:49:19.7649985 HDLC: Address = 255 Frame Type = 0x03 (UI) Poll/Final = 0 (Poll) FCS = 0xcb-7d (Good) PPP: Protocol ID = 0xc021 (Link Control Protocol) LCP: Code = 0x01 (Configure Request) Identifier = 003 Length = 00023 --- Configuration Options --- Char Control Map = 0x00-0a-00-00 Magic Number = 0x01-3e-ce-1f Protocol Compress = On Addr-Ctrl Compress = On Callback Message = 6 (Location by CBCP negotiation) Hex Data of: Record #6 (EQ) Captured on 10.03.97 at 14:49:19.7649985 (length = 29 bytes) ff 03 c0 21 01 03 00 17 02 06 00 0a 00 00 05 06 ÿÀ!   01 3e ce 1f 07 02 08 02 0d 03 06 cb 7d >Î Ë} Summary of: Record #7 (LN) Captured on 10.03.97 at 14:49:21.4614840 HDLC: Addr = 255; Type = UI; PF = Poll; FCS = Good PPP: Protocol = LCP LCP: Code = CfgReq; ID = 181 Details of: Record #7 (LN) Captured on 10.03.97 at 14:49:21.4614840 HDLC: Address = 255 Frame Type = 0x03 (UI) Poll/Final = 0 (Poll) FCS = 0x60-93 (Good) PPP: Protocol ID = 0xc021 (Link Control Protocol) LCP: Code = 0x01 (Configure Request) Identifier = 181 Length = 00025 --- Configuration Options --- Char Control Map = 0x00-0a-00-00 Authentication Prot = 0xc223 (Challenge Handshake) Magic Number = 0x02-2e-4d-e6 Protocol Compress = On Addr-Ctrl Compress = On Hex Data of: Record #7 (LN) Captured on 10.03.97 at 14:49:21.4614840 (length = 31 bytes) ff 03 c0 21 01 b5 00 19 02 06 00 0a 00 00 03 05 ÿÀ!µ   c2 23 05 05 06 02 2e 4d e6 07 02 08 02 60 93 Â#.M æ`“ Summary of: Record #8 (EQ) Captured on 10.03.97 at 14:49:21.4684024 HDLC: Addr = 255; Type = UI; PF = Poll; FCS = Good PPP: Protocol = LCP LCP: Code = CfgAck; ID = 181 Details of: Record #8 (EQ) Captured on 10.03.97 at 14:49:21.4684024 HDLC: Address = 255 Frame Type = 0x03 (UI) Poll/Final = 0 (Poll) FCS = 0xed-9f (Good) PPP: Protocol ID = 0xc021 (Link Control Protocol) LCP: Code = 0x02 (Configure Ack) Identifier = 181 Length = 00025 --- Configuration Options --- Char Control Map = 0x00-0a-00-00 Authentication Prot = 0xc223 (Challenge Handshake) Magic Number = 0x02-2e-4d-e6 Protocol Compress = On Addr-Ctrl Compress = On Hex Data of: Record #8 (EQ) Captured on 10.03.97 at 14:49:21.4684024 (length = 31 bytes) ff 03 c0 21 02 b5 00 19 02 06 00 0a 00 00 03 05 ÿÀ!µ   c2 23 05 05 06 02 2e 4d e6 07 02 08 02 ed 9f Â#.M æíŸ .... -- Mark S. Petrovic v 816 854-3152 Technical Lead, Operations f 816 854-4351 Sprint Internet Access Services p 800 724-3508 Kansas City, MO PIN 3856972 msp@corp.sprintmail.com or msp-page@corp.sprintmail.com -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzOCAuAAAAEEANZgUFhsyHKJQdtV0bqU6p8FwjK7SIWVskPCgPKLSyOuAvN1 0Ei6QxZJ5T4p233VGsQDdJg/yEHU2uaUWKzyI2R9YVSO0vrGAbN9RmMPWljuRZRG gnnlmLDtqKzkXc98K28SPwjIJo5jb0O4J6xmqYHgEJnj0LI43J+kePX7HCuxAAUR tCpNYXJrIFMuIFBldHJvdmljIDxtc3BAY29ycC5zcHJpbnRtYWlsLmNvbT6JAJUD BRAzhbgZn6R49fscK7EBAfEDA/wMQ+zYZ7MgFtuvO6gAG150gylhsdnmLx57vTmh pv0UYg4jAGtrm0/vTmxrvxXf2+x62Tf1wXhVbVazesI1GSiqrEGwMHZacMcJLCi4 FgX3O7/sXrzb7mj2b4CPIoQ1WsBAmbVAGeLdrQVaZJ9kLTSkm4fh3124hZhywjGT CLF7Fg== =D7wB -----END PGP PUBLIC KEY BLOCK----- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Oct 3 20:09:36 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id UAA06385; Fri, 3 Oct 1997 20:08:09 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 3 Oct 1997 20:07:19 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id UAA06364 for ietf-ppp-outgoing; Fri, 3 Oct 1997 20:07:18 -0400 (EDT) Received: from flipper.cisco.com (flipper.cisco.com [171.69.63.10]) by merit.edu (8.8.7/8.8.5) with ESMTP id UAA06359 for ; Fri, 3 Oct 1997 20:07:14 -0400 (EDT) Received: from flipper.cisco.com (flipper.cisco.com [171.69.63.10]) by flipper.cisco.com (8.8.4-Cisco.1/8.6.5) with SMTP id RAA05183; Fri, 3 Oct 1997 17:06:42 -0700 (PDT) Date: Fri, 3 Oct 1997 17:06:42 -0700 (PDT) From: John Bray To: Mark Petrovic cc: PPP Working Group Subject: Re: Reproducible bad FCS's into a Cisco 2511 In-Reply-To: <19971003162140.15527@corp.sprintmail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by merit.edu id UAA06360 Sender: owner-ietf-ppp@merit.edu Um...did you happen to take a look at the contents of the "packet" that caused the analyzer to report an "FCS error"? If you look closely, you'll notice that it isn't a packet. It's displayable text, intended to be displayed on the screen of a dial-in user. The protocol analyzer, naturally, doesn't understand that. John Bray On Fri, 3 Oct 1997, Mark Petrovic wrote: > The following represents the first few frames of a typical data set > obtained with a PPP protocol anaylyzer during Win95 PPP negotiation > with a Cisco 2511 IOS 11.0(11) terminal server. Quite reproducibly, I > obtain an Invalid FCS in Record #5 after the 2nd LCP request from the > client. Note that (EQ) indicates frames issued by the Win95 client, > while (LN) indicates the incoming frames from the terminal server. > Anyone seen this sort of thing before? I've included a few good frames > as a follow up, from which point the negotiation is successfully executed. > > Summary of: Record #1 (LN) Captured on 10.03.97 at 14:48:58.0000000 > Leads Status: RTS: On DTR: On CTS: On DSR: On CD: Off > Details of: Record #1 (LN) Captured on 10.03.97 at 14:48:58.0000000 > Leads Status: RTS: On DTR: On CTS: On DSR: On CD: Off > (No displayable hex data) > > Summary of: Record #2 (LN) Captured on 10.03.97 at 14:49:13.6721161 > Leads Status: RTS: On DTR: On CTS: On DSR: On CD: On > Details of: Record #2 (LN) Captured on 10.03.97 at 14:49:13.6721161 > Leads Status: RTS: On DTR: On CTS: On DSR: On CD: On > (No displayable hex data) > > Summary of: Record #3 (EQ) Captured on 10.03.97 at 14:49:13.7570181 > HDLC: Addr = 255; Type = UI; PF = Poll; FCS = Good > PPP: Protocol = LCP > LCP: Code = CfgReq; ID = 001 > Details of: Record #3 (EQ) Captured on 10.03.97 at 14:49:13.7570181 > HDLC: > Address = 255 > Frame Type = 0x03 (UI) > Poll/Final = 0 (Poll) > FCS = 0x60-27 (Good) > PPP: > Protocol ID = 0xc021 (Link Control Protocol) > LCP: > Code = 0x01 (Configure Request) > Identifier = 001 > Length = 00023 > --- Configuration Options --- > Char Control Map = 0x00-0a-00-00 > Magic Number = 0x01-3e-ce-1f > Protocol Compress = On > Addr-Ctrl Compress = On > Callback Message = 6 (Location by CBCP negotiation) > Hex Data of: Record #3 (EQ) Captured on 10.03.97 at 14:49:13.7570181 > (length = 29 bytes) > ff 03 c0 21 01 01 00 17 02 06 00 0a 00 00 05 06 ÿÀ!  >  > 01 3e ce 1f 07 02 08 02 0d 03 06 60 27 >Î `' > > Summary of: Record #4 (EQ) Captured on 10.03.97 at 14:49:16.7576289 > HDLC: Addr = 255; Type = UI; PF = Poll; FCS = Good > PPP: Protocol = LCP > LCP: Code = CfgReq; ID = 002 > Details of: Record #4 (EQ) Captured on 10.03.97 at 14:49:16.7576289 > HDLC: > Address = 255 > Frame Type = 0x03 (UI) > Poll/Final = 0 (Poll) > FCS = 0x96-d4 (Good) > PPP: > Protocol ID = 0xc021 (Link Control Protocol) > LCP: > Code = 0x01 (Configure Request) > Identifier = 002 > Length = 00023 > --- Configuration Options --- > Char Control Map = 0x00-0a-00-00 > Magic Number = 0x01-3e-ce-1f > Protocol Compress = On > Addr-Ctrl Compress = On > Callback Message = 6 (Location by CBCP negotiation) > Hex Data of: Record #4 (EQ) Captured on 10.03.97 at 14:49:16.7576289 > (length = 29 bytes) > ff 03 c0 21 01 02 00 17 02 06 00 0a 00 00 05 06 ÿÀ!  >  > 01 3e ce 1f 07 02 08 02 0d 03 06 96 d4 >Î –Ô > > Summary of: Record #5 (LN) Captured on 10.03.97 at 14:49:16.8710959 > HDLC: (Address and Control Field Compressed); FCS = Bad > HDLC: >>> ERROR >>> Invalid FCS > Details of: Record #5 (LN) Captured on 10.03.97 at 14:49:16.8710959 > HDLC: > (Address and Control Field Compressed) > FCS = 0x0d-0a (Bad) > HDLC: >>> ERROR >>> Invalid FCS > Hex Data of: Record #5 (LN) Captured on 10.03.97 at 14:49:16.8710959 > (length = 235 bytes) > 08 20 08 0d 0a 25 20 45 72 72 6f 72 20 69 6e 20   > % E rror in > 61 75 74 68 65 6e 74 69 63 61 74 69 6f 6e 2e 0d authenti cation. > 0a 0d 0a 0d 0a 0d 0a 57 65 6c 63 6f 6d 65 20 74 > > > > W elcome t > 6f 20 53 70 72 69 6e 74 2d 69 70 0d 0a 0d 0a 45 o Sprint -ip > > E > 6e 74 65 72 69 6e 67 20 50 50 50 20 6d 6f 64 65 ntering PPP mode > 2e 0d 0a 41 73 79 6e 63 20 69 6e 74 65 72 66 61 . > Async interfa > 63 65 20 61 64 64 72 65 73 73 20 69 73 20 75 6e ce addre ss is un > 6e 75 6d 62 65 72 65 64 20 28 45 74 68 65 72 6e numbered (Ethern > 65 74 30 29 0d 0a 59 6f 75 72 20 49 50 20 61 64 et0) > Yo ur IP ad > 64 72 65 73 73 20 69 73 20 32 30 36 2e 31 33 33 dress is 206.133 > 2e 31 36 31 2e 32 30 35 2e 20 4d 54 55 20 69 73 .161.205 . MTU is > 20 31 35 30 30 20 62 79 74 65 73 0d 0a 48 65 61 1500 by tes > Hea > 64 65 72 20 63 6f 6d 70 72 65 73 73 69 6f 6e 20 der comp ression > 77 69 6c 6c 20 6d 61 74 63 68 20 79 6f 75 72 20 will mat ch your > 73 79 73 74 65 6d 2e 0d 0a 0d 0a system. > > > > Summary of: Record #6 (EQ) Captured on 10.03.97 at 14:49:19.7649985 > HDLC: Addr = 255; Type = UI; PF = Poll; FCS = Good > PPP: Protocol = LCP > LCP: Code = CfgReq; ID = 003 > Details of: Record #6 (EQ) Captured on 10.03.97 at 14:49:19.7649985 > HDLC: > Address = 255 > Frame Type = 0x03 (UI) > Poll/Final = 0 (Poll) > FCS = 0xcb-7d (Good) > PPP: > Protocol ID = 0xc021 (Link Control Protocol) > LCP: > Code = 0x01 (Configure Request) > Identifier = 003 > Length = 00023 > --- Configuration Options --- > Char Control Map = 0x00-0a-00-00 > Magic Number = 0x01-3e-ce-1f > Protocol Compress = On > Addr-Ctrl Compress = On > Callback Message = 6 (Location by CBCP negotiation) > Hex Data of: Record #6 (EQ) Captured on 10.03.97 at 14:49:19.7649985 > (length = 29 bytes) > ff 03 c0 21 01 03 00 17 02 06 00 0a 00 00 05 06 ÿÀ!  >  > 01 3e ce 1f 07 02 08 02 0d 03 06 cb 7d >Î Ë} > > Summary of: Record #7 (LN) Captured on 10.03.97 at 14:49:21.4614840 > HDLC: Addr = 255; Type = UI; PF = Poll; FCS = Good > PPP: Protocol = LCP > LCP: Code = CfgReq; ID = 181 > Details of: Record #7 (LN) Captured on 10.03.97 at 14:49:21.4614840 > HDLC: > Address = 255 > Frame Type = 0x03 (UI) > Poll/Final = 0 (Poll) > FCS = 0x60-93 (Good) > PPP: > Protocol ID = 0xc021 (Link Control Protocol) > LCP: > Code = 0x01 (Configure Request) > Identifier = 181 > Length = 00025 > --- Configuration Options --- > Char Control Map = 0x00-0a-00-00 > Authentication Prot = 0xc223 (Challenge Handshake) > Magic Number = 0x02-2e-4d-e6 > Protocol Compress = On > Addr-Ctrl Compress = On > Hex Data of: Record #7 (LN) Captured on 10.03.97 at 14:49:21.4614840 > (length = 31 bytes) > ff 03 c0 21 01 b5 00 19 02 06 00 0a 00 00 03 05 ÿÀ!µ  >  > c2 23 05 05 06 02 2e 4d e6 07 02 08 02 60 93 Â#.M æ`“ > > Summary of: Record #8 (EQ) Captured on 10.03.97 at 14:49:21.4684024 > HDLC: Addr = 255; Type = UI; PF = Poll; FCS = Good > PPP: Protocol = LCP > LCP: Code = CfgAck; ID = 181 > Details of: Record #8 (EQ) Captured on 10.03.97 at 14:49:21.4684024 > HDLC: > Address = 255 > Frame Type = 0x03 (UI) > Poll/Final = 0 (Poll) > FCS = 0xed-9f (Good) > PPP: > Protocol ID = 0xc021 (Link Control Protocol) > LCP: > Code = 0x02 (Configure Ack) > Identifier = 181 > Length = 00025 > --- Configuration Options --- > Char Control Map = 0x00-0a-00-00 > Authentication Prot = 0xc223 (Challenge Handshake) > Magic Number = 0x02-2e-4d-e6 > Protocol Compress = On > Addr-Ctrl Compress = On > Hex Data of: Record #8 (EQ) Captured on 10.03.97 at 14:49:21.4684024 > (length = 31 bytes) > ff 03 c0 21 02 b5 00 19 02 06 00 0a 00 00 03 05 ÿÀ!µ  >  > c2 23 05 05 06 02 2e 4d e6 07 02 08 02 ed 9f Â#.M æíŸ > > > .... > > -- > Mark S. Petrovic v 816 854-3152 > Technical Lead, Operations f 816 854-4351 > Sprint Internet Access Services p 800 724-3508 > Kansas City, MO PIN 3856972 > msp@corp.sprintmail.com or msp-page@corp.sprintmail.com > > > -----BEGIN PGP PUBLIC KEY BLOCK----- > Version: 2.6.2 > > mQCNAzOCAuAAAAEEANZgUFhsyHKJQdtV0bqU6p8FwjK7SIWVskPCgPKLSyOuAvN1 > 0Ei6QxZJ5T4p233VGsQDdJg/yEHU2uaUWKzyI2R9YVSO0vrGAbN9RmMPWljuRZRG > gnnlmLDtqKzkXc98K28SPwjIJo5jb0O4J6xmqYHgEJnj0LI43J+kePX7HCuxAAUR > tCpNYXJrIFMuIFBldHJvdmljIDxtc3BAY29ycC5zcHJpbnRtYWlsLmNvbT6JAJUD > BRAzhbgZn6R49fscK7EBAfEDA/wMQ+zYZ7MgFtuvO6gAG150gylhsdnmLx57vTmh > pv0UYg4jAGtrm0/vTmxrvxXf2+x62Tf1wXhVbVazesI1GSiqrEGwMHZacMcJLCi4 > FgX3O7/sXrzb7mj2b4CPIoQ1WsBAmbVAGeLdrQVaZJ9kLTSkm4fh3124hZhywjGT > CLF7Fg== > =D7wB > -----END PGP PUBLIC KEY BLOCK----- > > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Oct 3 21:04:45 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id VAA07030; Fri, 3 Oct 1997 21:03:22 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 3 Oct 1997 21:03:04 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id VAA07010 for ietf-ppp-outgoing; Fri, 3 Oct 1997 21:03:03 -0400 (EDT) Received: from manny.ops.sprintisp.net (host234.dev.sprintisp.com [205.137.205.234] (may be forged)) by merit.edu (8.8.7/8.8.5) with SMTP id VAA07006 for ; Fri, 3 Oct 1997 21:02:59 -0400 (EDT) Received: by manny.ops.sprintisp.net (SMI-8.6/SMI-SVR4) id SAA14503; Fri, 3 Oct 1997 18:02:03 -0700 Reply-to: msp@corp.sprintmail.com (Mark Petrovic) Message-ID: <19971003200203.29596@corp.sprintmail.com> Date: Fri, 3 Oct 1997 20:02:03 -0500 From: Mark Petrovic To: bray@cisco.com Cc: PPP Working Group Subject: Re: Reproducible bad FCS's into a Cisco 2511 References: <19971003162140.15527@corp.sprintmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Mailer: Mutt 0.81 In-Reply-To: ; from John Bray on Fri, Oct 03, 1997 at 05:06:42PM -0700 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by merit.edu id VAA07007 Sender: owner-ietf-ppp@merit.edu Yes, I noticed that. However, I had assumed that when the NAS hears the first LCP packet from the client, there is no need for the NAS to send content intended for human consumption. Subject: Re: Reproducible bad FCS's into a Cisco 2511 Date: 3Oct Quoting John Bray (bray@cisco.com): > Um...did you happen to take a look at the contents of the "packet" > that caused the analyzer to report an "FCS error"? If you look > closely, you'll notice that it isn't a packet. It's displayable text, > intended to be displayed on the screen of a dial-in user. The protocol > analyzer, naturally, doesn't understand that. > > John Bray > > On Fri, 3 Oct 1997, Mark Petrovic wrote: > > > The following represents the first few frames of a typical data set > > obtained with a PPP protocol anaylyzer during Win95 PPP negotiation > > with a Cisco 2511 IOS 11.0(11) terminal server. Quite reproducibly, I > > obtain an Invalid FCS in Record #5 after the 2nd LCP request from the > > client. Note that (EQ) indicates frames issued by the Win95 client, > > while (LN) indicates the incoming frames from the terminal server. > > Anyone seen this sort of thing before? I've included a few good frames > > as a follow up, from which point the negotiation is successfully executed. > > > > Summary of: Record #1 (LN) Captured on 10.03.97 at 14:48:58.0000000 > > Leads Status: RTS: On DTR: On CTS: On DSR: On CD: Off > > Details of: Record #1 (LN) Captured on 10.03.97 at 14:48:58.0000000 > > Leads Status: RTS: On DTR: On CTS: On DSR: On CD: Off > > (No displayable hex data) > > > > Summary of: Record #2 (LN) Captured on 10.03.97 at 14:49:13.6721161 > > Leads Status: RTS: On DTR: On CTS: On DSR: On CD: On > > Details of: Record #2 (LN) Captured on 10.03.97 at 14:49:13.6721161 > > Leads Status: RTS: On DTR: On CTS: On DSR: On CD: On > > (No displayable hex data) > > > > Summary of: Record #3 (EQ) Captured on 10.03.97 at 14:49:13.7570181 > > HDLC: Addr = 255; Type = UI; PF = Poll; FCS = Good > > PPP: Protocol = LCP > > LCP: Code = CfgReq; ID = 001 > > Details of: Record #3 (EQ) Captured on 10.03.97 at 14:49:13.7570181 > > HDLC: > > Address = 255 > > Frame Type = 0x03 (UI) > > Poll/Final = 0 (Poll) > > FCS = 0x60-27 (Good) > > PPP: > > Protocol ID = 0xc021 (Link Control Protocol) > > LCP: > > Code = 0x01 (Configure Request) > > Identifier = 001 > > Length = 00023 > > --- Configuration Options --- > > Char Control Map = 0x00-0a-00-00 > > Magic Number = 0x01-3e-ce-1f > > Protocol Compress = On > > Addr-Ctrl Compress = On > > Callback Message = 6 (Location by CBCP negotiation) > > Hex Data of: Record #3 (EQ) Captured on 10.03.97 at 14:49:13.7570181 > > (length = 29 bytes) > > ff 03 c0 21 01 01 00 17 02 06 00 0a 00 00 05 06 ÿÀ!  > >  > > 01 3e ce 1f 07 02 08 02 0d 03 06 60 27 >Î `' > > > > Summary of: Record #4 (EQ) Captured on 10.03.97 at 14:49:16.7576289 > > HDLC: Addr = 255; Type = UI; PF = Poll; FCS = Good > > PPP: Protocol = LCP > > LCP: Code = CfgReq; ID = 002 > > Details of: Record #4 (EQ) Captured on 10.03.97 at 14:49:16.7576289 > > HDLC: > > Address = 255 > > Frame Type = 0x03 (UI) > > Poll/Final = 0 (Poll) > > FCS = 0x96-d4 (Good) > > PPP: > > Protocol ID = 0xc021 (Link Control Protocol) > > LCP: > > Code = 0x01 (Configure Request) > > Identifier = 002 > > Length = 00023 > > --- Configuration Options --- > > Char Control Map = 0x00-0a-00-00 > > Magic Number = 0x01-3e-ce-1f > > Protocol Compress = On > > Addr-Ctrl Compress = On > > Callback Message = 6 (Location by CBCP negotiation) > > Hex Data of: Record #4 (EQ) Captured on 10.03.97 at 14:49:16.7576289 > > (length = 29 bytes) > > ff 03 c0 21 01 02 00 17 02 06 00 0a 00 00 05 06 ÿÀ!  > >  > > 01 3e ce 1f 07 02 08 02 0d 03 06 96 d4 >Î –Ô > > > > Summary of: Record #5 (LN) Captured on 10.03.97 at 14:49:16.8710959 > > HDLC: (Address and Control Field Compressed); FCS = Bad > > HDLC: >>> ERROR >>> Invalid FCS > > Details of: Record #5 (LN) Captured on 10.03.97 at 14:49:16.8710959 > > HDLC: > > (Address and Control Field Compressed) > > FCS = 0x0d-0a (Bad) > > HDLC: >>> ERROR >>> Invalid FCS > > Hex Data of: Record #5 (LN) Captured on 10.03.97 at 14:49:16.8710959 > > (length = 235 bytes) > > 08 20 08 0d 0a 25 20 45 72 72 6f 72 20 69 6e 20   > > % E rror in > > 61 75 74 68 65 6e 74 69 63 61 74 69 6f 6e 2e 0d authenti cation. > > 0a 0d 0a 0d 0a 0d 0a 57 65 6c 63 6f 6d 65 20 74 > > > > > > > > W elcome t > > 6f 20 53 70 72 69 6e 74 2d 69 70 0d 0a 0d 0a 45 o Sprint -ip > > > > E > > 6e 74 65 72 69 6e 67 20 50 50 50 20 6d 6f 64 65 ntering PPP mode > > 2e 0d 0a 41 73 79 6e 63 20 69 6e 74 65 72 66 61 . > > Async interfa > > 63 65 20 61 64 64 72 65 73 73 20 69 73 20 75 6e ce addre ss is un > > 6e 75 6d 62 65 72 65 64 20 28 45 74 68 65 72 6e numbered (Ethern > > 65 74 30 29 0d 0a 59 6f 75 72 20 49 50 20 61 64 et0) > > Yo ur IP ad > > 64 72 65 73 73 20 69 73 20 32 30 36 2e 31 33 33 dress is 206.133 > > 2e 31 36 31 2e 32 30 35 2e 20 4d 54 55 20 69 73 .161.205 . MTU is > > 20 31 35 30 30 20 62 79 74 65 73 0d 0a 48 65 61 1500 by tes > > Hea > > 64 65 72 20 63 6f 6d 70 72 65 73 73 69 6f 6e 20 der comp ression > > 77 69 6c 6c 20 6d 61 74 63 68 20 79 6f 75 72 20 will mat ch your > > 73 79 73 74 65 6d 2e 0d 0a 0d 0a system. > > > > > > > > Summary of: Record #6 (EQ) Captured on 10.03.97 at 14:49:19.7649985 > > HDLC: Addr = 255; Type = UI; PF = Poll; FCS = Good > > PPP: Protocol = LCP > > LCP: Code = CfgReq; ID = 003 > > Details of: Record #6 (EQ) Captured on 10.03.97 at 14:49:19.7649985 > > HDLC: > > Address = 255 > > Frame Type = 0x03 (UI) > > Poll/Final = 0 (Poll) > > FCS = 0xcb-7d (Good) > > PPP: > > Protocol ID = 0xc021 (Link Control Protocol) > > LCP: > > Code = 0x01 (Configure Request) > > Identifier = 003 > > Length = 00023 > > --- Configuration Options --- > > Char Control Map = 0x00-0a-00-00 > > Magic Number = 0x01-3e-ce-1f > > Protocol Compress = On > > Addr-Ctrl Compress = On > > Callback Message = 6 (Location by CBCP negotiation) > > Hex Data of: Record #6 (EQ) Captured on 10.03.97 at 14:49:19.7649985 > > (length = 29 bytes) > > ff 03 c0 21 01 03 00 17 02 06 00 0a 00 00 05 06 ÿÀ!  > >  > > 01 3e ce 1f 07 02 08 02 0d 03 06 cb 7d >Î Ë} > > > > Summary of: Record #7 (LN) Captured on 10.03.97 at 14:49:21.4614840 > > HDLC: Addr = 255; Type = UI; PF = Poll; FCS = Good > > PPP: Protocol = LCP > > LCP: Code = CfgReq; ID = 181 > > Details of: Record #7 (LN) Captured on 10.03.97 at 14:49:21.4614840 > > HDLC: > > Address = 255 > > Frame Type = 0x03 (UI) > > Poll/Final = 0 (Poll) > > FCS = 0x60-93 (Good) > > PPP: > > Protocol ID = 0xc021 (Link Control Protocol) > > LCP: > > Code = 0x01 (Configure Request) > > Identifier = 181 > > Length = 00025 > > --- Configuration Options --- > > Char Control Map = 0x00-0a-00-00 > > Authentication Prot = 0xc223 (Challenge Handshake) > > Magic Number = 0x02-2e-4d-e6 > > Protocol Compress = On > > Addr-Ctrl Compress = On > > Hex Data of: Record #7 (LN) Captured on 10.03.97 at 14:49:21.4614840 > > (length = 31 bytes) > > ff 03 c0 21 01 b5 00 19 02 06 00 0a 00 00 03 05 ÿÀ!µ  > >  > > c2 23 05 05 06 02 2e 4d e6 07 02 08 02 60 93 Â#.M æ`“ > > > > Summary of: Record #8 (EQ) Captured on 10.03.97 at 14:49:21.4684024 > > HDLC: Addr = 255; Type = UI; PF = Poll; FCS = Good > > PPP: Protocol = LCP > > LCP: Code = CfgAck; ID = 181 > > Details of: Record #8 (EQ) Captured on 10.03.97 at 14:49:21.4684024 > > HDLC: > > Address = 255 > > Frame Type = 0x03 (UI) > > Poll/Final = 0 (Poll) > > FCS = 0xed-9f (Good) > > PPP: > > Protocol ID = 0xc021 (Link Control Protocol) > > LCP: > > Code = 0x02 (Configure Ack) > > Identifier = 181 > > Length = 00025 > > --- Configuration Options --- > > Char Control Map = 0x00-0a-00-00 > > Authentication Prot = 0xc223 (Challenge Handshake) > > Magic Number = 0x02-2e-4d-e6 > > Protocol Compress = On > > Addr-Ctrl Compress = On > > Hex Data of: Record #8 (EQ) Captured on 10.03.97 at 14:49:21.4684024 > > (length = 31 bytes) > > ff 03 c0 21 02 b5 00 19 02 06 00 0a 00 00 03 05 ÿÀ!µ  > >  > > c2 23 05 05 06 02 2e 4d e6 07 02 08 02 ed 9f Â#.M æíŸ > > > > > > .... > > > > -- > > Mark S. Petrovic v 816 854-3152 > > Technical Lead, Operations f 816 854-4351 > > Sprint Internet Access Services p 800 724-3508 > > Kansas City, MO PIN 3856972 > > msp@corp.sprintmail.com or msp-page@corp.sprintmail.com > > > > > > -----BEGIN PGP PUBLIC KEY BLOCK----- > > Version: 2.6.2 > > > > mQCNAzOCAuAAAAEEANZgUFhsyHKJQdtV0bqU6p8FwjK7SIWVskPCgPKLSyOuAvN1 > > 0Ei6QxZJ5T4p233VGsQDdJg/yEHU2uaUWKzyI2R9YVSO0vrGAbN9RmMPWljuRZRG > > gnnlmLDtqKzkXc98K28SPwjIJo5jb0O4J6xmqYHgEJnj0LI43J+kePX7HCuxAAUR > > tCpNYXJrIFMuIFBldHJvdmljIDxtc3BAY29ycC5zcHJpbnRtYWlsLmNvbT6JAJUD > > BRAzhbgZn6R49fscK7EBAfEDA/wMQ+zYZ7MgFtuvO6gAG150gylhsdnmLx57vTmh > > pv0UYg4jAGtrm0/vTmxrvxXf2+x62Tf1wXhVbVazesI1GSiqrEGwMHZacMcJLCi4 > > FgX3O7/sXrzb7mj2b4CPIoQ1WsBAmbVAGeLdrQVaZJ9kLTSkm4fh3124hZhywjGT > > CLF7Fg== > > =D7wB > > -----END PGP PUBLIC KEY BLOCK----- > > > > > -- Mark S. Petrovic v 816 854-3152 Technical Lead, Operations f 816 854-4351 Sprint Internet Access Services p 800 724-3508 Kansas City, MO PIN 3856972 msp@corp.sprintmail.com or msp-page@corp.sprintmail.com -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzOCAuAAAAEEANZgUFhsyHKJQdtV0bqU6p8FwjK7SIWVskPCgPKLSyOuAvN1 0Ei6QxZJ5T4p233VGsQDdJg/yEHU2uaUWKzyI2R9YVSO0vrGAbN9RmMPWljuRZRG gnnlmLDtqKzkXc98K28SPwjIJo5jb0O4J6xmqYHgEJnj0LI43J+kePX7HCuxAAUR tCpNYXJrIFMuIFBldHJvdmljIDxtc3BAY29ycC5zcHJpbnRtYWlsLmNvbT6JAJUD BRAzhbgZn6R49fscK7EBAfEDA/wMQ+zYZ7MgFtuvO6gAG150gylhsdnmLx57vTmh pv0UYg4jAGtrm0/vTmxrvxXf2+x62Tf1wXhVbVazesI1GSiqrEGwMHZacMcJLCi4 FgX3O7/sXrzb7mj2b4CPIoQ1WsBAmbVAGeLdrQVaZJ9kLTSkm4fh3124hZhywjGT CLF7Fg== =D7wB -----END PGP PUBLIC KEY BLOCK----- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Sat Oct 4 09:38:28 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id JAA11035; Sat, 4 Oct 1997 09:35:40 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Sat, 4 Oct 1997 09:31:15 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id JAA10999 for ietf-ppp-outgoing; Sat, 4 Oct 1997 09:31:14 -0400 (EDT) Received: from out1.ibm.net (out1.ibm.net [165.87.194.252]) by merit.edu (8.8.7/8.8.5) with ESMTP id JAA10995 for ; Sat, 4 Oct 1997 09:31:10 -0400 (EDT) Received: from jrmhtp.endicott.ibm.com (slip129-37-221-168.ny.us.ibm.net [129.37.221.168]) by out1.ibm.net (8.8.5/8.6.9) with SMTP id NAA102946; Sat, 4 Oct 1997 13:31:06 GMT Message-Id: <3.0.3.32.19971004092525.0083a420@pop01.ny.us.ibm.net> X-Sender: jrmartz@pop01.ny.us.ibm.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Sat, 04 Oct 1997 09:25:25 -0400 To: PPP Work Group , John Martz , johnm@vnet.ibm.com, Mark Bullock From: "John R. Martz" Subject: Re: Reproducible bad FCS's into a Cisco 2511 Cc: Mark Petrovic Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu From John Bray: >Um...did you happen to take a look at the contents of the "packet" >that caused the analyzer to report an "FCS error"? If you look >closely, you'll notice that it isn't a packet. It's displayable text, >intended to be displayed on the screen of a dial-in user. From Mark Petrovic: >Yes, I noticed that. However, I had assumed that when the NAS hears >the first LCP packet from the client, there is no need for the NAS to >send content intended for human consumption. Why on earth would you assume that??? I also thought the trace in your note showed a "working as designed" scenario. It's looks like the CISCO router is just doing what it's owner (Sprint) has asked it to do. Certainly it's possible in the AS/400 implementation for a customer to set things up so that a "login message" is sent out before the actual PPP packets from the peer will even be recognized. If the peer is not configured to expect the login script text and somehow mistakes the text for an HDLC frame then the peer will toss the inbound "packet" with a bad FCS. This is a good thing, isn't it? It's why PPP/HDLC checks for an FCS, no? In the AS/400's implementation, when we're doing script processing that's ALL we can be doing and we're not at all flexible about this either. We have no way to somehow recognize that the peer is sending us a PPP packet and switch out of our script processing mode. I don't think our hardware could detect this. We're either expecting HDLC frames or we aren't. If we're not expecting HDLC (script mode), then the hardware doesn't try to "autodetect" it. Is this "special"? No, of course not. OTOH, it has never made sense to us to enhance our script processing function either. We view it as a legacy from our SLIP support that should only be used in a few very exceptional cases when the intent is to ultimately use PPP to connect two peer's. If you do not want to see the bad FCS in the trace, then change the configuration of the CISCO so that it stops sending out the "welcome" text. While I'm not familiar with CISCO systems, I'd guess that this can be done. I'd find it very surprising if CISCO systems were hard coded to send "Welcome to Sprint -ip" to all remote peers. -john martz IBM AS/400 TCP/IP - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Sat Oct 4 09:54:40 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id JAA11163; Sat, 4 Oct 1997 09:53:09 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Sat, 4 Oct 1997 09:53:00 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id JAA11144 for ietf-ppp-outgoing; Sat, 4 Oct 1997 09:52:59 -0400 (EDT) Received: from manny.ops.sprintisp.net (host229.dev.sprintisp.com [205.137.205.229]) by merit.edu (8.8.7/8.8.5) with SMTP id JAA11140 for ; Sat, 4 Oct 1997 09:52:55 -0400 (EDT) Received: by manny.ops.sprintisp.net (SMI-8.6/SMI-SVR4) id GAA14973; Sat, 4 Oct 1997 06:52:23 -0700 Reply-to: msp@corp.sprintmail.com (Mark Petrovic) Message-ID: <19971004085222.64331@corp.sprintmail.com> Date: Sat, 4 Oct 1997 08:52:22 -0500 From: Mark Petrovic To: jrmartz@ibm.net Cc: PPP Working Group Subject: Re: Reproducible bad FCS's into a Cisco 2511 References: <3.0.3.32.19971004092525.0083a420@pop01.ny.us.ibm.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81 In-Reply-To: <3.0.3.32.19971004092525.0083a420@pop01.ny.us.ibm.net>; from John R. Martz on Sat, Oct 04, 1997 at 09:25:25AM -0400 Sender: owner-ietf-ppp@merit.edu Subject: Re: Reproducible bad FCS's into a Cisco 2511 Date: 4Oct Quoting John R. Martz (jrmartz@ibm.net): > From John Bray: > >Um...did you happen to take a look at the contents of the "packet" > >that caused the analyzer to report an "FCS error"? If you look > >closely, you'll notice that it isn't a packet. It's displayable text, > >intended to be displayed on the screen of a dial-in user. > > From Mark Petrovic: > >Yes, I noticed that. However, I had assumed that when the NAS hears > >the first LCP packet from the client, there is no need for the NAS to > >send content intended for human consumption. > > Why on earth would you assume that??? I also thought the trace in your note Easy does it. > showed a "working as designed" scenario. It's looks like the CISCO router > is just doing what it's owner (Sprint) has asked it to do. > > Certainly it's possible in the AS/400 implementation for a customer to set > things up so that a "login message" is sent out before the actual PPP > packets from the peer will even be recognized. If the peer is not > configured to expect the login script text and somehow mistakes the text > for an HDLC frame then the peer will toss the inbound "packet" with a bad > FCS. This is a good thing, isn't it? It's why PPP/HDLC checks for an FCS, no? > > In the AS/400's implementation, when we're doing script processing that's > ALL we can be doing and we're not at all flexible about this either. We > have no way to somehow recognize that the peer is sending us a PPP packet > and switch out of our script processing mode. I don't think our hardware > could detect this. We're either expecting HDLC frames or we aren't. If > we're not expecting HDLC (script mode), then the hardware doesn't try to > "autodetect" it. > > Is this "special"? No, of course not. OTOH, it has never made sense to us > to enhance our script processing function either. We view it as a legacy > from our SLIP support that should only be used in a few very exceptional > cases when the intent is to ultimately use PPP to connect two peer's. > > If you do not want to see the bad FCS in the trace, then change the > configuration of the CISCO so that it stops sending out the "welcome" text. > While I'm not familiar with CISCO systems, I'd guess that this can be done. > I'd find it very surprising if CISCO systems were hard coded to send > "Welcome to Sprint -ip" to all remote peers. Your points are well taken, and I have a better understanding of the interaction. Thank you. > -john martz > IBM AS/400 TCP/IP -- Mark S. Petrovic v 816 854-3152 Technical Lead, Operations f 816 854-4351 Sprint Internet Access Services p 800 724-3508 Kansas City, MO PIN 3856972 msp@corp.sprintmail.com or msp-page@corp.sprintmail.com -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzOCAuAAAAEEANZgUFhsyHKJQdtV0bqU6p8FwjK7SIWVskPCgPKLSyOuAvN1 0Ei6QxZJ5T4p233VGsQDdJg/yEHU2uaUWKzyI2R9YVSO0vrGAbN9RmMPWljuRZRG gnnlmLDtqKzkXc98K28SPwjIJo5jb0O4J6xmqYHgEJnj0LI43J+kePX7HCuxAAUR tCpNYXJrIFMuIFBldHJvdmljIDxtc3BAY29ycC5zcHJpbnRtYWlsLmNvbT6JAJUD BRAzhbgZn6R49fscK7EBAfEDA/wMQ+zYZ7MgFtuvO6gAG150gylhsdnmLx57vTmh pv0UYg4jAGtrm0/vTmxrvxXf2+x62Tf1wXhVbVazesI1GSiqrEGwMHZacMcJLCi4 FgX3O7/sXrzb7mj2b4CPIoQ1WsBAmbVAGeLdrQVaZJ9kLTSkm4fh3124hZhywjGT CLF7Fg== =D7wB -----END PGP PUBLIC KEY BLOCK----- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Sat Oct 4 10:46:48 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id KAA11529; Sat, 4 Oct 1997 10:45:08 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Sat, 4 Oct 1997 10:44:44 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA11506 for ietf-ppp-outgoing; Sat, 4 Oct 1997 10:44:43 -0400 (EDT) Received: from linux.klos.com (klos@klos.com [192.80.49.1]) by merit.edu (8.8.7/8.8.5) with SMTP id KAA11502 for ; Sat, 4 Oct 1997 10:44:39 -0400 (EDT) Received: (from klos@localhost) by linux.klos.com (8.6.12/8.6.9) id KAA31266; Sat, 4 Oct 1997 10:49:01 -0400 Date: Sat, 4 Oct 1997 10:49:01 -0400 From: Patrick Klos Message-Id: <199710041449.KAA31266@linux.klos.com> To: msp@corp.sprintmail.com Subject: Re: Reproducible bad FCS's into a Cisco 2511 Cc: ietf-ppp@merit.edu Sender: owner-ietf-ppp@merit.edu >Your points are well taken, and I have a better understanding of the >interaction. Thank you. May I ask which protocol analyzer you're using? Did you see any error stats on the Cisco that made you look into this, or was it because of the FCS error reported by the protocol analyzer?? It's possible the only error was the interpretation of the text as a packet by the protocol analyzer. Picture this scenario: Both sides modem's connect (CONNECT message or CD or both [on each side]). The Cisco sends out it's normal "human interface" prompt: "Welcome to , etc." followed by it's command prompt. A second or two passes. The Win95 peer sends a few LCP packets. The Cisco sends it's first LCP packet (which will start with an HDLC flag character 0x7e). At this point, the protocol analyzer has all that text sent from the Cisco a few seconds earlier still sitting in it's "packet" buffer. It sees the flag and assumes it's the end of a packet, so the protocol analyzer processes the data in it's buffer as a packet and reports the FCS error. (note that the timestamps on the packets most likely denote the time that the LAST BYTE was received - the packet could have taken seconds to be received) Even if the Cisco did recognize the LCP packets from it's peer and take itself out of "human interface" mode before sending it's LCP packet, the protocol analyzer already had collected up the text from several seconds before and was just waiting for an end of packet flag. Does this sound like a possibility? ============================================================================ Patrick Klos Email: klos@klos.com Klos Technologies, Inc. Voice: (603) 424-8300 604 Daniel Webster Highway FAX: (603) 424-9300 Merrimack, New Hampshire 03054 Web: http://www.klos.com/ ============================================================================ - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Sat Oct 4 11:04:51 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id LAA11655; Sat, 4 Oct 1997 11:03:30 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Sat, 4 Oct 1997 11:03:19 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id LAA11635 for ietf-ppp-outgoing; Sat, 4 Oct 1997 11:03:18 -0400 (EDT) Received: from out1.ibm.net (out1.ibm.net [165.87.194.252]) by merit.edu (8.8.7/8.8.5) with ESMTP id LAA11629 for ; Sat, 4 Oct 1997 11:03:15 -0400 (EDT) Received: from jrmhtp.endicott.ibm.com (slip129-37-221-97.ny.us.ibm.net [129.37.221.97]) by out1.ibm.net (8.8.5/8.6.9) with SMTP id PAA17224 for ; Sat, 4 Oct 1997 15:03:13 GMT Message-Id: <3.0.3.32.19971004105946.007ca780@pop01.ny.us.ibm.net> X-Sender: jrmartz@pop01.ny.us.ibm.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Sat, 04 Oct 1997 10:59:46 -0400 To: PPP Work Group From: "John R. Martz" Subject: Clarification on AS/400 PPP status Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Folks, I suppose I shouldn't send out notes on a Saturday AM until AFTER I've had two cups of caffeine. It occurred to me that in my previous note I definitely misrepresented the status of PPP implementation on the AS/400. I will NOT take the chance that I may have conveyed incorrect information to any of our AS/400 customers either directly or indirectly. Consequently, I decided to send this clarification note. "Just in case ..." The IBM AS/400 does NOT, I repeat NOT, provide support at this time for TCP/IP PPP in any of the outstanding and generally available releases of OS/400. When I referred in my previous notes to the "AS/400 PPP implementation" I was referring to ongoing development work. This development work may .. or may NOT ... someday be available as part of some future but as yet unannounced (and therefore uncommitted) release of the OS/400 operating system. But it currently is NOT generally available nor to my knowledge committed to be made available to IBM AS/400 customers. The remainder of this note is personal commentary. I've noticed that my attitude towards discussion of ongoing development work in a public forum differs from many of my IBM co-workers. They feel they should never say ANYTHING about ongoing development work in public until after the work has been officially announced. I quite frankly view that as absurd and counter-productive. If you can't talk, you can't learn. How does that benefit your employer? The approach I have taken and will continue to take towards this matter was best expressed in Scott Adam's Dilbert comic strip about a week or so ago. "... about this document marked proprietary'. If I spent my entire life searching, do you think I could find ANYONE who would care about this?" Certainly, one should filter what one says in public, but that filtering should be rational. As an IBM employee I am obligated to protect valuable proprietary IBM information and (more importantly) to not mislead our customers or misinform them. I apologize if I've done this in any of my earlier notes and I sincerely hope I've corrected any mistaken impression I may have left. Again, my apologies for not choosing my words better in my earlier notes. -john martz IBM AS/400 PPP - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Sat Oct 4 13:11:45 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id NAA12453; Sat, 4 Oct 1997 13:10:20 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Sat, 4 Oct 1997 13:10:00 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id NAA12429 for ietf-ppp-outgoing; Sat, 4 Oct 1997 13:09:59 -0400 (EDT) Received: from manny.ops.sprintisp.net (host224.dev.sprintisp.com [205.137.205.224] (may be forged)) by merit.edu (8.8.7/8.8.5) with SMTP id NAA12425 for ; Sat, 4 Oct 1997 13:09:55 -0400 (EDT) Received: by manny.ops.sprintisp.net (SMI-8.6/SMI-SVR4) id KAA15107; Sat, 4 Oct 1997 10:09:13 -0700 Reply-to: msp@corp.sprintmail.com (Mark Petrovic) Message-ID: <19971004120913.57225@corp.sprintmail.com> Date: Sat, 4 Oct 1997 12:09:13 -0500 From: Mark Petrovic To: klos@klos.com Cc: PPP Working Group Subject: Re: Reproducible bad FCS's into a Cisco 2511 References: <199710041449.KAA31266@linux.klos.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81 In-Reply-To: <199710041449.KAA31266@linux.klos.com>; from Patrick Klos on Sat, Oct 04, 1997 at 10:49:01AM -0400 Sender: owner-ietf-ppp@merit.edu Subject: Re: Reproducible bad FCS's into a Cisco 2511 Date: 4Oct Quoting Patrick Klos (klos@klos.com): > >Your points are well taken, and I have a better understanding of the > >interaction. Thank you. > > May I ask which protocol analyzer you're using? Did you see any error HP J2300 series Internet Advisor. > stats on the Cisco that made you look into this, or was it because of > the FCS error reported by the protocol analyzer?? It's possible the The latter, the bad FCS error. It is the case that our Cisco's are configured to support scripted logins. > only error was the interpretation of the text as a packet by the > protocol analyzer. Picture this scenario: > > Both sides modem's connect (CONNECT message or CD or both [on each side]). > > The Cisco sends out it's normal "human interface" prompt: "Welcome to > , etc." followed by it's command prompt. > > A second or two passes. > > The Win95 peer sends a few LCP packets. > > The Cisco sends it's first LCP packet (which will start with an HDLC > flag character 0x7e). > > At this point, the protocol analyzer has all that text sent from the > Cisco a few seconds earlier still sitting in it's "packet" buffer. > It sees the flag and assumes it's the end of a packet, so the protocol > analyzer processes the data in it's buffer as a packet and reports the > FCS error. (note that the timestamps on the packets most likely > denote the time that the LAST BYTE was received - the packet could > have taken seconds to be received) > > Even if the Cisco did recognize the LCP packets from it's peer and take > itself out of "human interface" mode before sending it's LCP packet, the > protocol analyzer already had collected up the text from several seconds > before and was just waiting for an end of packet flag. > > Does this sound like a possibility? It sounds like precisely what is happening. A subtlety that I earlier missed. > ============================================================================ > Patrick Klos Email: klos@klos.com > Klos Technologies, Inc. Voice: (603) 424-8300 > 604 Daniel Webster Highway FAX: (603) 424-9300 > Merrimack, New Hampshire 03054 Web: http://www.klos.com/ > ============================================================================ -- Mark S. Petrovic v 816 854-3152 Technical Lead, Operations f 816 854-4351 Sprint Internet Access Services p 800 724-3508 Kansas City, MO PIN 3856972 msp@corp.sprintmail.com or msp-page@corp.sprintmail.com -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzOCAuAAAAEEANZgUFhsyHKJQdtV0bqU6p8FwjK7SIWVskPCgPKLSyOuAvN1 0Ei6QxZJ5T4p233VGsQDdJg/yEHU2uaUWKzyI2R9YVSO0vrGAbN9RmMPWljuRZRG gnnlmLDtqKzkXc98K28SPwjIJo5jb0O4J6xmqYHgEJnj0LI43J+kePX7HCuxAAUR tCpNYXJrIFMuIFBldHJvdmljIDxtc3BAY29ycC5zcHJpbnRtYWlsLmNvbT6JAJUD BRAzhbgZn6R49fscK7EBAfEDA/wMQ+zYZ7MgFtuvO6gAG150gylhsdnmLx57vTmh pv0UYg4jAGtrm0/vTmxrvxXf2+x62Tf1wXhVbVazesI1GSiqrEGwMHZacMcJLCi4 FgX3O7/sXrzb7mj2b4CPIoQ1WsBAmbVAGeLdrQVaZJ9kLTSkm4fh3124hZhywjGT CLF7Fg== =D7wB -----END PGP PUBLIC KEY BLOCK----- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Sun Oct 5 14:14:25 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id OAA20427; Sun, 5 Oct 1997 14:09:13 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Sun, 5 Oct 1997 13:58:53 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id NAA20315 for ietf-ppp-outgoing; Sun, 5 Oct 1997 13:58:52 -0400 (EDT) Received: from lms03.us.ibm.com (lms03.ny.us.ibm.com [198.133.22.39]) by merit.edu (8.8.7/8.8.5) with ESMTP id NAA20311 for ; Sun, 5 Oct 1997 13:58:49 -0400 (EDT) Received: from US.IBM.COM (d01lms04.pok.ibm.com [9.117.30.25]) by lms03.us.ibm.com (8.8.7/8.8.7) with SMTP id NAA30452 for ; Sun, 5 Oct 1997 13:56:46 -0500 Received: by US.IBM.COM (Soft-Switch LMS 2.0) with snapi via D01AU002 id 5010400011928056; Sun, 5 Oct 1997 14:02:22 -0400 From: John Martz To: Subject: ACCM and T/A's and rate adaption Message-ID: <5010400011928056000002L062*@MHS> Date: Sun, 5 Oct 1997 14:02:22 -0400 MIME-Version: 1.0 Content-Type: text/plain Sender: owner-ietf-ppp@merit.edu Folks, Some "FYI, if any" comments. Re: Defaulting the receive ACCM for an asynchronous line to 0. Our default receive/transmit ACCM's will remain as 0xFFFFFFFF as specified by the RFC. But it also seems prudent to leave in an undocumented hook that will allow us to force the default receive ACCM to 0. This could be useful for field problem determination and problem work-around. This is what I plan to do. Re: US Robotics I-modem unescaped FCS bytes. We're in the process of reporting this and waiting for USR to provide us with an update to the flash ROM for the I-modem that fixes the problem. The current version of the USR T/A is quite aware that the default transmit ACCM is 0xFFFFFFFF because all the bytes prior to the FCS in any PPP packet it sends us are correctly escaped. It's only the two FCS bytes that seem to be overlooked. So I don't expect problems getting this fixed. I'm not sure how quickly it will be fixed, but I have no reason to doubt that USR will provide a fix. Re: T/A's and V.120, V.110 et cetera For our use of the US Robotics I-modem, I don't think these protocols apply. I'm told that the USR T/A is not using a rate adaption protocol such as V.120. It can be set up to do this, but that's not the mode in which we are using it. Rather the ISDN side of the link from the T/A to the ISP we're testing with is synchronous PPP. How the T/A does the conversion from asynch to synch PPP I don't know or understand. But supposedly the rate adaption protocols are not involved. In addition, the T/A has it's own internal PPP implementation. Our system negotiates an (asynchronous) PPP connection to the T/A and the T/A then negotiates it's own (synchronous) PPP connection to the host/ISP we actually want to talk to over the ISDN line. The T/A supports PPP multi-link so it can negotiate a multi-link connection joining the two B channels "internally". This is (mostly) transparent to our system. The T/A just looks like a very fast modem that we've got an asynchronous serial (RS232/V.24) connection to. We live in interesting times, no? Thanks again for your continuing tolerance and helpful feedback. -john martz IBM AS/400 TCP/IP "uncommitted" PPP development - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Oct 6 07:12:21 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id HAA29492; Mon, 6 Oct 1997 07:09:48 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 6 Oct 1997 07:06:13 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id HAA29432 for ietf-ppp-outgoing; Mon, 6 Oct 1997 07:06:13 -0400 (EDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm012-09.dialip.mich.net [141.211.7.177]) by merit.edu (8.8.7/8.8.5) with SMTP id HAA29412 for ; Mon, 6 Oct 1997 07:06:05 -0400 (EDT) Date: Mon, 6 Oct 97 10:25:17 GMT From: "William Allen Simpson" Message-ID: <6630.wsimpson@greendragon.com> To: ietf-ppp@merit.edu Subject: Re: PPP over ATM LCP option restrictions Sender: owner-ietf-ppp@merit.edu Sometimes, I really wish folks would be self-consistent in their writing. May I suggest that one way to achieve this is to proof-read and edit your message after you have finished the first pass.... And clean up 200 line quoted messages. > From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) > The LCP session has to be end-to-end, otherwise end-to-end > authentication is not possible (each hop would have to be > authenticated separately - an administrative nightmare). > > Philip Rakity writes: > ] I am not saying what I have previously said if right; but I am > ] at a loss to see where the consistent actions are defined for a > ] PPP/AAL5 End Point which receives options which are > ] meaningless. (I am assuming that the AAL5 End Point does NOT > ] request FCS a new FCS if it was proposed !!) > > As Dennis as pointed out, the precedent for this is the > requirement of a sync PPP system to negotiate and then ignore the > ACCM. So the same should apply to ACFC as well. > Actually, the "precedent" is that ACCM is special-cased. The "consistent" action is to REJECT it [RFC-1661]: 5.4. Configure-Reject Description If some Configuration Options received in a Configure-Request are not recognizable or are not acceptable for negotiation (as configured by a network administrator), then the implementation MUST transmit a Configure-Reject. > What happens when you have framing converters at both ends of the > link? > > End System -- Converter ---(AAL5)--- Converter -- End System > > Neither End System knows antyhing about the AAL5 encapsulation rules, > and so would have no reason to reject ACFC, so the only way to be > compliant is for the converters to interfere with the LCP negotiation. > > Accept-but-ignore has got to be preferable. > This is inconsistent with your earlier statement that PPP negotiation has to be end-to-end (which is correct). The AAL5 "converter" is not involved in the PPP negotiation. The AAL5 would not be doing ACFC anyway. If the "converter" cannot recognize ACFC, but the end-points accept the ACFC option, and then send compressed headers, the link will never work. IMnsHO, that would be bad! And, as far as I can tell, the PPP in AAL5 draft does not allow "conversion". It assumes that AAL5 is end-to-end. Perhaps it needs a section on converters, just as we have in RFC-1662. Perhaps it needs to outlaw them. Finally, this is an implementors list, not a general speculation list. It would be of great assistance should those writers indicate that they are actually implementing a PPP/AAL5 to something "converter", or merely hand-waving. Thanks in advance. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Oct 6 07:12:22 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id HAA29500; Mon, 6 Oct 1997 07:09:51 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 6 Oct 1997 07:06:12 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id HAA29425 for ietf-ppp-outgoing; Mon, 6 Oct 1997 07:06:11 -0400 (EDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm012-09.dialip.mich.net [141.211.7.177]) by merit.edu (8.8.7/8.8.5) with SMTP id HAA29408 for ; Mon, 6 Oct 1997 07:06:03 -0400 (EDT) Date: Mon, 6 Oct 97 10:18:04 GMT From: "William Allen Simpson" Message-ID: <6629.wsimpson@greendragon.com> To: ietf-ppp@merit.edu Subject: Re: ACCM and T/A's and rate adaption Sender: owner-ietf-ppp@merit.edu > From: John Martz > In addition, the T/A has it's own internal PPP implementation. Our system > negotiates an (asynchronous) PPP connection to the T/A and the T/A then > negotiates it's own (synchronous) PPP connection to the host/ISP we actually > want to talk to over the ISDN line. The T/A supports PPP multi-link so it can > negotiate a multi-link connection joining the two B channels "internally". > This is (mostly) transparent to our system. The T/A just looks like a very > fast modem that we've got an asynchronous serial (RS232/V.24) connection to. > Actually, this T/A looks like a very simple _router_ that you are connected to directly. I am of the routing religion, and have long favored the ubiquitous router model over the bridge/converter model. Sounds like someone did the right thing! WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Oct 6 07:12:21 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id HAA29498; Mon, 6 Oct 1997 07:09:50 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 6 Oct 1997 07:06:10 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id HAA29418 for ietf-ppp-outgoing; Mon, 6 Oct 1997 07:06:09 -0400 (EDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm012-09.dialip.mich.net [141.211.7.177]) by merit.edu (8.8.7/8.8.5) with SMTP id HAA29406 for ; Mon, 6 Oct 1997 07:06:02 -0400 (EDT) Date: Mon, 6 Oct 97 09:49:19 GMT From: "William Allen Simpson" Message-ID: <6628.wsimpson@greendragon.com> To: ietf-ppp@merit.edu Subject: on rejecting LCP ACFC but not ACCM Sender: owner-ietf-ppp@merit.edu > From: "Eric L. Michelsen" > Subject: Re: PPP over ATM LCP option restrictions > At 09:32 AM 10/3/97 -0700, Philip Rakity wrote: > >1. Accept it since the equipment is doing it anyway > >2. Reject it since I do not support the option to negotiate its use > >(since it is always present). > > Clearly 1) makes sense. > > > >For changing the FCS, the remote is asking my system to send an FCS which > >it is incapable of transmitting. What should happen? > > Essentially, LCP allows negotiation of options which are specific to some > underlying framing layers. ACCM, ACFC, FCS are all examples of this. They > should all be handled consistently, and as documented for ACCM in RFC 1662. > If an implementation has no use for a parameter, then accept it, and let > other conversion boxes that may exist deal with the consequences. Anybody > doing conversion is responsible for making sure their end(s) negotiate > appropriately. > Actually, by definition, these "options" are "optional". ACFC and FCS are _enhancements_ to the basic framing. The framing will still work without them, albeit not optimally. Therefore, contrary to Michelson and Rakity, the long standing basic design assumption is when "an implementation has no use for a parameter," then REJECT it. Special cases like ACCM are specially handled. I believe that this principle applies to ATM framing as well. The special description of ACCM in RFC-1662 is because of the discontinuity in an async/sync converter for the escaping mechanism. The sync side will never handle async octet-escaping. That is, the escaping will not work in the presence of an option, and thus needed special text to handle the "sniffing" converter in the middle. The requirement that ACFC not be negotiated in RFC-1598 and RFC-1973 (which were written at the same time, but due to internal IESG politics were published at widely different times) is due to the problem experienced when X.25 feeds into Frame-Relay (X.25 on one endpoint, Frame-Relay on the other end). It would be impossible to find the PPP Protocol field reliably. > By the way, I thought the alternate FCS for HDLC-like framing option was > withdrawn. Is it still real? Yes, it is designed for high speed links. At least one of the PPP/SONET implementations uses it. Unfortunately, SONET-SDH has not been deployed as rapidly as we originally expected; mostly because telcos refuse to sell the circuits to ISPs. When we have multiple interoperable implementations, then alternate FCS will go forward on its own. That's how the IETF process is supposed to work. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Oct 6 09:27:10 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id JAA01355; Mon, 6 Oct 1997 09:25:42 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 6 Oct 1997 09:25:17 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id JAA01334 for ietf-ppp-outgoing; Mon, 6 Oct 1997 09:25:16 -0400 (EDT) Received: from lms03.us.ibm.com (lms03.ny.us.ibm.com [198.133.22.39]) by merit.edu (8.8.7/8.8.5) with ESMTP id JAA01330 for ; Mon, 6 Oct 1997 09:25:13 -0400 (EDT) Received: from US.IBM.COM (d01lms04.pok.ibm.com [9.117.30.25]) by lms03.us.ibm.com (8.8.7/8.8.7) with SMTP id JAA113074 for ; Mon, 6 Oct 1997 09:23:09 -0500 Received: by US.IBM.COM (Soft-Switch LMS 2.0) with snapi via D01AU002 id 5010400011952549; Mon, 6 Oct 1997 09:28:43 -0400 From: John Martz To: Subject: Re: ACCM and T/A's and rate adaption Message-ID: <5010400011952549000002L092*@MHS> Date: Mon, 6 Oct 1997 09:28:43 -0400 MIME-Version: 1.0 Content-Type: text/plain Sender: owner-ietf-ppp@merit.edu > Actually, this T/A looks like a very simple _router_ that you are > connected to directly. Yes, perhaps that is a better way to look at it. Of course, it is US Robotic's/3COM's product, not ours. Frankly I'm very uncomfortable speaking about it. The best I can do is speculate on what it is doing based on my (limited) understanding of the I-modem's external interface. I hope that someone who works on the Courier I-modem is following this list and will post clarifications. But then I also still hope to hear back from Gurdeep Singh (or anyone else at MicroSoft) with something more substantial than a more articulate paraphrase of "You talking to me, punk?!?" I guess I'm just a midwestern, pollyanna optimist and always will be. -john martz IBM AS/400 TCP/IP "uncommitted" PPP development - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Oct 6 12:21:37 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id MAA04782; Mon, 6 Oct 1997 12:18:46 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 6 Oct 1997 12:16:41 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id MAA04701 for ietf-ppp-outgoing; Mon, 6 Oct 1997 12:16:40 -0400 (EDT) Received: from directors.rdl.co.uk (directors.rdl.co.uk [193.119.77.2]) by merit.edu (8.8.7/8.8.5) with ESMTP id MAA04692 for ; Mon, 6 Oct 1997 12:16:27 -0400 (EDT) Received: from imaccgw.rdl.co.uk (imaccgw.rdl.co.uk [193.240.106.205]) by directors.rdl.co.uk (8.7.3/8.7.3) with SMTP id RAA27943 for ; Mon, 6 Oct 1997 17:16:21 +0100 (BST) Received: from ccMail by imaccgw.rdl.co.uk (IMA Internet Exchange 1.04b) id 4390c8e0; Mon, 6 Oct 97 17:06:38 +0100 Mime-Version: 1.0 Date: Mon, 6 Oct 1997 17:09:16 +0100 Message-ID: <4390c8e0@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re: PPP over ATM LCP option restrictions To: ietf-ppp@merit.edu Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: owner-ietf-ppp@merit.edu William Allen Simpson writes: >> What happens when you have framing converters at both ends of the >> link? >> >> End System -- Converter ---(AAL5)--- Converter -- End System >> >> Neither End System knows anything about the AAL5 encapsulation rules, >> and so would have no reason to reject ACFC, so the only way to be >> compliant is for the converters to interfere with the LCP negotiation. >> >... > The AAL5 would not be doing ACFC anyway. If the "converter" cannot > recognize ACFC, but the end-points accept the ACFC option, and then send > compressed headers, the link will never work. Ah, I think we're finally getting somewhere. This is the reason why an AAL5 implementation MUST NOT include the ACFC option in its Configure Requests. (The same applies to X.25 and Frame relay - I now realise that the text I submitted for revising section 3 of RFC 1598 was incorrect on this point - I'll submit another version separately). But this is no reason to Reject the ACFC in received configure requests. If it is present, then the peer can't be an AAL5 implementation, so there must be a converter in the path to the peer. What harm can accepting the option do? It doesn't affect the AAL5 encapsulation, and the converter is under no obligation to compress the address and control fields in the frames it forwards to the non-AAL5 peer anyway. --- Jonathan Goodchild - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Oct 6 12:26:20 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id MAA04984; Mon, 6 Oct 1997 12:23:38 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 6 Oct 1997 12:22:03 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id MAA04903 for ietf-ppp-outgoing; Mon, 6 Oct 1997 12:22:02 -0400 (EDT) Received: from directors.rdl.co.uk (directors.rdl.co.uk [193.119.77.2]) by merit.edu (8.8.7/8.8.5) with ESMTP id MAA04874 for ; Mon, 6 Oct 1997 12:21:08 -0400 (EDT) Received: from imaccgw.rdl.co.uk (imaccgw.rdl.co.uk [193.240.106.205]) by directors.rdl.co.uk (8.7.3/8.7.3) with SMTP id RAA28029 for ; Mon, 6 Oct 1997 17:20:44 +0100 (BST) Received: from ccMail by imaccgw.rdl.co.uk (IMA Internet Exchange 1.04b) id 4390e120; Mon, 6 Oct 97 17:13:06 +0100 Mime-Version: 1.0 Date: Mon, 6 Oct 1997 17:18:37 +0100 Message-ID: <4390e120@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re: on rejecting LCP ACFC but not ACCM To: ietf-ppp@merit.edu Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: owner-ietf-ppp@merit.edu William Allen Simpson writes: > The requirement that ACFC not be negotiated in RFC-1598 and RFC-1973 > is due to the problem experienced when X.25 feeds into Frame-Relay > (X.25 on one endpoint, Frame-Relay on the other end). It would be > impossible to find the PPP Protocol field reliably. This statement is inconsistent with the reason given in the text in RFCs 1598 and 1973: ] Address-and-Control-Field-Compression ] ] Because the Address and Control field values are not constant, and ] are modified as the frame is transported by the network switching ] fabric, Address-and-Control-Field-Compression MUST NOT be ] negotiated. This text in the RFCs is the thing that I really object to - the PPP Address and Control fields have absolutely nothing to do with the X.25 frame address and control fields. Besides, surely the problem of locating the PPP Protocol field is actually the reason why the X.25 and Frame Relay encapsulation formats are as they are (i.e. fixed without the 0xff 0x030) - this is not the same thing as the reason why ACFC negotiation is not allowed. The X.25 and Frame Relay formats simply mean that Address and Control Field compression is not applicable - once you've decided it's not applicable, what does it matter whether the ACFC option is actually negotiated or not? (Apart from the problem of converters, of course). Having said that, the possibility of converters mean that the ACFC option must not be included in Configure Requests, so in the interests of simplicity I'll drop my objection to the requirement to Reject the ACFC option as well. --- Jonathan Goodchild - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Oct 6 12:26:43 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id MAA05052; Mon, 6 Oct 1997 12:25:21 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 6 Oct 1997 12:23:41 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id MAA04986 for ietf-ppp-outgoing; Mon, 6 Oct 1997 12:23:40 -0400 (EDT) Received: from directors.rdl.co.uk (directors.rdl.co.uk [193.119.77.2]) by merit.edu (8.8.7/8.8.5) with ESMTP id MAA04974 for ; Mon, 6 Oct 1997 12:23:33 -0400 (EDT) Received: from imaccgw.rdl.co.uk (imaccgw.rdl.co.uk [193.240.106.205]) by directors.rdl.co.uk (8.7.3/8.7.3) with SMTP id RAA28044 for ; Mon, 6 Oct 1997 17:23:31 +0100 (BST) Received: from ccMail by imaccgw.rdl.co.uk (IMA Internet Exchange 1.04b) id 4390ef50; Mon, 6 Oct 97 17:16:53 +0100 Mime-Version: 1.0 Date: Mon, 6 Oct 1997 17:20:11 +0100 Message-ID: <4390ef50@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re: PPP and X.25 To: ietf-ppp@merit.edu Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: owner-ietf-ppp@merit.edu Here is my revised suggested text for section 3 of RFC 1598. --- Jonathan Goodchild 3. The Data Link Layer This specification uses the principles, terminology, and frame structure described in "Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode" [4]. The purpose of this specification is not to document what is already standardized in [4]. Instead, this document attempts to give a concise summary and point out specific options and features used by PPP. 3.1. PPP in X.25 Encapsulation Format The PPP Encapsulation [as described in RFC 1661 section 2], otherwise known as the "PPP Payload" or PDU, is delivered to the X.25 stack as a "complete packet sequence" [see ITU-T X.25 clause 4.3.5 for a definition]. The X.25 layer may divide this up into a number of packets, but the PDU will be delivered as a complete packet sequence to the remote peer. For a PPP packet that fits into a single X.25 data packet, the format is as follows: +--------------+--------------+-------------+---------+----------+ | X.25 header | PPP Protocol | Information | Padding | X.25 FCS | | 5/6/7 octets | 8/16 bits | | * | 2 octets | +--------------+--------------+-------------+---------+----------+ The PPP Protocol field and the following Information and Padding fields are described in the Point-to-Point Protocol Encapsulation [1]. The X.25 header may be 5, 6 or 7 octets in length, depending upon whether modulo-8 or modulo-128 sequence numbers are used at layer 2 and layer 3. 3.2. Modification of the Encapsulation Format The Link Control Protocol can negotiate modifications to the basic encapsulation structure. Address-and-Control-Field-Compression The PPP Address and Control fields (which are completely unrelated to the X.25 Address and Control fields) are not present in this encapsulation format; the Address-and-Control-Field-Compression option MUST NOT be included in LCP Configure Requests sent to the peer. Protocol-Field-Compression Note that unlike the HDLC framing, the X.25 framing does not necessarily align the Information field on a 32-bit boundary, because the X.25 header (not including the flag) may be 5, 6 or 7 octets in length. Alignment to a 16-bit boundary is therefore highly implementation dependent; when it improves throughput, Protocol-Field-Compression SHOULD be negotiated. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Oct 6 16:02:00 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id QAA09339; Mon, 6 Oct 1997 16:00:23 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 6 Oct 1997 15:59:47 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id PAA09312 for ietf-ppp-outgoing; Mon, 6 Oct 1997 15:59:47 -0400 (EDT) Received: from ns.newbridge.com (ns.newbridge.com [192.75.23.67]) by merit.edu (8.8.7/8.8.5) with SMTP id PAA09308 for ; Mon, 6 Oct 1997 15:59:42 -0400 (EDT) Received: (from smap@localhost) by ns.newbridge.com (8.6.12/8.6.12) id PAA05933 for ; Mon, 6 Oct 1997 15:59:42 -0400 Received: from kanata-gw1(192.75.23.72) by ns via smap (V1.3) id sma005901; Mon Oct 6 15:59:12 1997 Received: from kanmaster.ca.newbridge.com by kanata-gw1.ca.newbridge.com via smtpd (for ns.newbridge.com [192.75.23.67]) with SMTP; 6 Oct 1997 19:59:12 UT Received: from sid (sid.ca.newbridge.com [138.120.56.62]) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) with SMTP id PAA09864 for ; Mon, 6 Oct 1997 15:59:11 -0400 Date: Mon, 6 Oct 1997 16:01:04 -0400 (EDT) From: Ian Duncan X-Sender: iduncan@sid Reply-To: Ian Duncan To: ietf-ppp@merit.edu Subject: Re: PPP over ATM LCP option restrictions In-Reply-To: <6630.wsimpson@greendragon.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu On Mon, 6 Oct 1997, William Allen Simpson wrote: > > What happens when you have framing converters at both ends of the > > link? > > > > End System -- Converter ---(AAL5)--- Converter -- End System > > > > Neither End System knows antyhing about the AAL5 encapsulation rules, > > and so would have no reason to reject ACFC, so the only way to be > > compliant is for the converters to interfere with the LCP negotiation. > > > > Accept-but-ignore has got to be preferable. > > > > This is inconsistent with your earlier statement that PPP negotiation > has to be end-to-end (which is correct). > > The AAL5 "converter" is not involved in the PPP negotiation. > > The AAL5 would not be doing ACFC anyway. If the "converter" cannot > recognize ACFC, but the end-points accept the ACFC option, and then send > compressed headers, the link will never work. IMnsHO, that would be > bad! > > And, as far as I can tell, the PPP in AAL5 draft does not allow > "conversion". It assumes that AAL5 is end-to-end. Perhaps it needs a > section on converters, just as we have in RFC-1662. Perhaps it needs to > outlaw them. With respect Bill, this can't be solved by legislating it away any more than the hassles with V.120 could. The statement that PPP LCP negotiation must be end-to-end is misleading. The negotiation must converge end-to-end but various options can be handled independently for each segment on a multi-hop path. What's necessary here is understand that conversion (lower-layer interworking) is important to many PPP implementors and then to recognize that for at least some flavours of conversion: * the converter(s) must be involved in PPP; or * a converter and one of the end-points must be configured and controlled so they are bound together. It seems to me the PPP AAL5 draft is silent on conversion (and not completely so at that), which is probably good. What we need is a PPP lower-layer interworking document that deals with the general issues and directly addresses the popular cases. It would hopefully deal with: * the authentication issues the TA developers have; * how to safely indicate that conversion is occuring along the path; * how bad-FCS and other error counts get propogated; and * the LCP lower-layer adaptation options (ACCM, ACFC, FCS, etc.) > It would be of great assistance should those writers indicate that they > are actually implementing a PPP/AAL5 to something "converter", or merely > hand-waving. Thanks in advance. I'll give it a try ... On Thu, 2 Oct 1997, Dennis Ferguson wrote: > Hello, > > I'd like to understand why both the PPP over AAL5 and PPP over FUNI drafts > have an absolute restriction against accepting an ACFC or FCS option request > from a neighbour. > [...] > > Would it not, then, be less constraining to simply state that neither of > these options have any effect on the ATM connection, but to leave whether > they are accepted or not when a peer requests them up to the ATM > implementation's configuration? Or is there some damage that can occur > if one of these options is accepted? Shouldn't be too much hassle with administrative control on spoofing ACFC negotiation. It's either transparent to the H/W or likely won't pass at all. However, given the existing protocol definition in RFC1570 for FCS negotiation: "The negotiated FCS values take effect only during Authentication and Network-Layer Protocol phases. Frames sent during any other phase MUST contain the default FCS." and referencing this model: [ peer-A ]<---PPP/AAL5--->[ PPP IWU ]<---PPP/HDLC--->[ peer-B ] If the PPP/AAL5 default is Null FCS and the PPP/HDLC default (for a specific link configuration) is CRC32 there should be no need for FCS negotiation so don't do it. If the goal is interworking with PPP devices that default to CRC16 but can step up to CRC32 then FCS negotiation is necessary and the IWU is probably directly involved at least in generating the different FCS'. This would imply either running a light-weight LCP on the IWU which handles specific bits of link negotiation or having some out-of-band control over the IWU from peer-A. In short term, I'd encourage the approach of administrative controls on the default FCS at either end of HDLC segments which require it. But if we want this to work for the generic full-blown switched access SAK PPP we either need to push L2TP under PPP or build some new LCP extensions. I'm in favour of the latter. -- Ian Duncan Big Internetworking Group Newbridge Networks Corp. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Oct 7 00:38:40 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id AAA16232; Tue, 7 Oct 1997 00:37:10 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 7 Oct 1997 00:36:37 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id AAA16205 for ietf-ppp-outgoing; Tue, 7 Oct 1997 00:36:36 -0400 (EDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by merit.edu (8.8.7/8.8.5) with ESMTP id AAA16201 for ; Tue, 7 Oct 1997 00:36:32 -0400 (EDT) Received: from skank.juniper.net (skank.juniper.net [208.197.169.216]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id VAA23791; Mon, 6 Oct 1997 21:36:01 -0700 (PDT) Received: from skank.juniper.net (localhost.juniper.net [127.0.0.1]) by skank.juniper.net (8.8.4/8.7.3) with ESMTP id VAA28222; Mon, 6 Oct 1997 21:40:36 -0700 (PDT) Message-Id: <199710070440.VAA28222@skank.juniper.net> X-Mailer: exmh version 1.6.9 8/22/96 To: wsimpson@greendragon.com (William Allen Simpson) cc: ietf-ppp@merit.edu Subject: Re: PPP over ATM LCP option restrictions In-reply-to: Your message of "06 Oct 1997 10:25:17 GMT." <6630.wsimpson@greendragon.com> Mime-Version: 1.0 Content-Type: text/plain Date: Mon, 06 Oct 1997 21:40:35 -0700 From: Dennis Ferguson Sender: owner-ietf-ppp@merit.edu > The "consistent" action is to REJECT it [RFC-1661]: > > 5.4. Configure-Reject > > Description > > If some Configuration Options received in a Configure-Request are > not recognizable or are not acceptable for negotiation (as > configured by a network administrator), then the implementation > MUST transmit a Configure-Reject. Actually, a specification that was "consistent" with the above would do what it says and leave the choice of what to do up to the implementation and its configuration. The AAL5 draft, and RFC 1973, are not consistent since they unconditionally require that ACFC not be negotiated, independent of the implementation and its configuration. I think both specifications could be made consistent with the above while accomplishing the purpose apparently served by not allowing ACFC to be negotiated by instead specifying that the negotiation of ACFC does not effect the AAL5/frame relay framing, but otherwise leaving the handling of ACFC up to the implementation and its configuration. > And, as far as I can tell, the PPP in AAL5 draft does not allow > "conversion". It assumes that AAL5 is end-to-end. Perhaps it needs a > section on converters, just as we have in RFC-1662. Perhaps it needs to > outlaw them. I see nothing that disallows "conversion" in the PPP in AAL5 draft, it appears to say nothing about it at all. Perhaps you could point out the what you are referring to? Not addressing converters one way or the other seems like a fine course of action when one has never seen a converter and doesn't have a clear idea of how one might work. In this respect the draft seems fine. My only objection is that a severe restriction (don't negotiate ACFC) has been imposed in the draft when a lesser restriction (don't do anything different if ACFC is negotiated) would appear to achieve the same end just as well. > Finally, this is an implementors list, not a general speculation list. > It would be of great assistance should those writers indicate that they > are actually implementing a PPP/AAL5 to something "converter", or merely > hand-waving. I have one. It receives bit-synchronous HDLC from T1-rate interfaces and reframes them onto an ATM interface (it will also support a frame relay over SONET interface as an alternatve to the ATM, but this isn't done yet). The converter is smart enough not to try to remove an ff 03 from an HDLC frame which isn't preceded by ff 03, and knows enough about PPP to send non-LCP frames out a T1 circuit without the ff 03 if the last Configure-Ack it sent out that way (which it forwarded from the ATM side of the circuit) contained an ACFC option. The ATM-attached endpoint has been configured to offer an ACFC option to anyone who is connected, and to accept an ACFC option when offered (but knows nothing else about the converter), both in blatant violation of the current AAL5 draft. This appears to work fine. It also successfully interoperates with other ATM-attached routers, whether they're configured to negotiate ACFC or not. That the arrangement violates the draft (and will violate 1973) appears to be its only defect as far as I can tell. I think the constraint in the draft (and in 1973) is needless. > Thanks in advance. You're welcome. Dennis Ferguson - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Oct 7 05:03:07 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id FAA18165; Tue, 7 Oct 1997 05:01:27 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 7 Oct 1997 05:01:00 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id FAA18144 for ietf-ppp-outgoing; Tue, 7 Oct 1997 05:00:59 -0400 (EDT) Received: from directors.rdl.co.uk (directors.rdl.co.uk [193.119.77.2]) by merit.edu (8.8.7/8.8.5) with ESMTP id FAA18137 for ; Tue, 7 Oct 1997 05:00:53 -0400 (EDT) Received: from imaccgw.rdl.co.uk (imaccgw.rdl.co.uk [193.240.106.205]) by directors.rdl.co.uk (8.7.3/8.7.3) with SMTP id KAA05147 for ; Tue, 7 Oct 1997 10:00:52 +0100 (BST) Received: from ccMail by imaccgw.rdl.co.uk (IMA Internet Exchange 1.04b) id 439f8ac0; Tue, 7 Oct 97 09:54:04 +0100 Mime-Version: 1.0 Date: Tue, 7 Oct 1997 09:59:14 +0100 Message-ID: <439f8ac0@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: X.25 feeding into Frame Relay To: ietf-ppp@merit.edu Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: owner-ietf-ppp@merit.edu I think the statement below from Bill Simpson needs some further clarification: > The requirement that ACFC not be negotiated in RFC-1598 and RFC-1973 > is due to the problem experienced when X.25 feeds into Frame-Relay > (X.25 on one endpoint, Frame-Relay on the other end). It would be > impossible to find the PPP Protocol field reliably. Exactly what does happen when X.25 feeds into Frame Relay? If the network doesn't somehow magically convert the RFC 1598 format into the RFC 1973 format, then a new frame format must result, and this needs to be documented somewhere, either in the PPP in X.25 RFC, or in the PPP in Frame relay RFC, or both. (I assume that we're not talking about Annex F or Annex G here, because, as far as PPP is concerned, they're the same as X.25, and the RFC 1598 encapsulation rules apply) --- Jonathan Goodchild - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Oct 7 06:17:30 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id GAA18663; Tue, 7 Oct 1997 06:14:05 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 7 Oct 1997 06:11:18 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id GAA18595 for ietf-ppp-outgoing; Tue, 7 Oct 1997 06:11:17 -0400 (EDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm002-02.dialip.mich.net [141.211.7.138]) by merit.edu (8.8.7/8.8.5) with SMTP id GAA18578 for ; Tue, 7 Oct 1997 06:11:09 -0400 (EDT) Date: Tue, 7 Oct 97 09:43:11 GMT From: "William Allen Simpson" Message-ID: <6639.wsimpson@greendragon.com> To: ietf-ppp@merit.edu Subject: Re: PPP over ATM LCP option restrictions Sender: owner-ietf-ppp@merit.edu > From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) > William Allen Simpson writes: > > The AAL5 would not be doing ACFC anyway. If the "converter" cannot > > recognize ACFC, but the end-points accept the ACFC option, and then send > > compressed headers, the link will never work. > > Ah, I think we're finally getting somewhere. This is the reason why > an AAL5 implementation MUST NOT include the ACFC option in its > Configure Requests. > > (The same applies to X.25 and Frame relay - I now realise that the text > I submitted for revising section 3 of RFC 1598 was incorrect on this > point - I'll submit another version separately). > I'm glad that you are catching up. Pardon the sarcasm, but at least some of us arrived here a long time ago. > But this is no reason to Reject the ACFC in received configure requests. > If it is present, then the peer can't be an AAL5 implementation, so > there must be a converter in the path to the peer. What harm can > accepting the option do? It doesn't affect the AAL5 encapsulation, and > the converter is under no obligation to compress the address and control > fields in the frames it forwards to the non-AAL5 peer anyway. > Please visualize more than one "converter" in the stream. Converters are non-optimal. There is no reason to hyper-optimize every converter interaction. They must be defined to work when no options are negotiated, and then carefully extended. KISS. Folks, this converter speculation is getting way beyond the pale. We started with good solid questions from a vendor doing an implemention. I beg of you, please keep the discussion to converters that are actually implemented. It will help focus on relevant issues. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Oct 7 06:17:28 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id GAA18671; Tue, 7 Oct 1997 06:14:08 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 7 Oct 1997 06:11:18 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id GAA18596 for ietf-ppp-outgoing; Tue, 7 Oct 1997 06:11:17 -0400 (EDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm002-02.dialip.mich.net [141.211.7.138]) by merit.edu (8.8.7/8.8.5) with SMTP id GAA18582 for ; Tue, 7 Oct 1997 06:11:10 -0400 (EDT) Date: Tue, 7 Oct 97 09:57:34 GMT From: "William Allen Simpson" Message-ID: <6640.wsimpson@greendragon.com> To: ietf-ppp@merit.edu Subject: Re: MS ACCM considered harmful Sender: owner-ietf-ppp@merit.edu > From: John Martz > But then I also still hope to hear back from Gurdeep Singh (or anyone else at > MicroSoft) with something more substantial than a more articulate paraphrase of > "You talking to me, punk?!?" I guess I'm just a midwestern, pollyanna optimist > and always will be. > This reminds me, I have not had a public answer to my questions. I'll give him a another few days before I ask the same questions in an interrogatory in a more formal venue. Here are a few questions that I expect Gurdeep to answer in public here on this list: (1) Does the transmit ACCM in 95 and NT4 default to 0xffffffff? (2) Does the receive ACCM in 95 and NT4 default to 0xffffffff? (3) Does the ACCM get reset to default on every LCP packet? (4) Exactly which modem models was the regression tested against? (5) Who is your immediate supervisor at MicroSoft? WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Oct 7 06:17:30 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id GAA18666; Tue, 7 Oct 1997 06:14:06 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 7 Oct 1997 06:11:15 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id GAA18588 for ietf-ppp-outgoing; Tue, 7 Oct 1997 06:11:14 -0400 (EDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm002-02.dialip.mich.net [141.211.7.138]) by merit.edu (8.8.7/8.8.5) with SMTP id GAA18576 for ; Tue, 7 Oct 1997 06:11:07 -0400 (EDT) Date: Tue, 7 Oct 97 09:29:52 GMT From: "William Allen Simpson" Message-ID: <6638.wsimpson@greendragon.com> To: ietf-ppp@merit.edu Subject: Re: on rejecting LCP ACFC but not ACCM Sender: owner-ietf-ppp@merit.edu > From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) > ] Address-and-Control-Field-Compression > ] > ] Because the Address and Control field values are not constant, and > ] are modified as the frame is transported by the network switching > ] fabric, Address-and-Control-Field-Compression MUST NOT be > ] negotiated. > > This text in the RFCs is the thing that I really object to - the PPP > Address and Control fields have absolutely nothing to do with the X.25 > frame address and control fields. > PPP does not have Address and Control fields. Apparently, as I have mentioned in private messages to you in the past, you do not understand the differentiation between PPP encapsulation fields (Protocol, Information, Padding), and HDLC, Frame-Relay, and X.25 framing. Please go back and re-read RFC-1661 and the relevant framing RFCs. Understanding this basic paradigm will clear up the other misconceptions in your recent postings. I think that this is my last post on this topic for awhile. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Oct 7 09:02:56 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id JAA20505; Tue, 7 Oct 1997 09:01:32 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 7 Oct 1997 09:00:50 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id JAA20486 for ietf-ppp-outgoing; Tue, 7 Oct 1997 09:00:49 -0400 (EDT) Received: from directors.rdl.co.uk (directors.rdl.co.uk [193.119.77.2]) by merit.edu (8.8.7/8.8.5) with ESMTP id JAA20482 for ; Tue, 7 Oct 1997 09:00:44 -0400 (EDT) Received: from imaccgw.rdl.co.uk (imaccgw.rdl.co.uk [193.240.106.205]) by directors.rdl.co.uk (8.7.3/8.7.3) with SMTP id OAA13999 for ; Tue, 7 Oct 1997 14:00:43 +0100 (BST) Received: from ccMail by imaccgw.rdl.co.uk (IMA Internet Exchange 1.04b) id 43a30e30; Tue, 7 Oct 97 13:53:55 +0100 Mime-Version: 1.0 Date: Tue, 7 Oct 1997 13:56:29 +0100 Message-ID: <43a30e30@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re: on rejecting LCP ACFC but not ACCM To: ietf-ppp@merit.edu Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: owner-ietf-ppp@merit.edu (Sorry, folks, but I can't let this go unanswered again). Bill Simpson writes: > PPP does not have Address and Control fields. I should have said that the X.25 Frame Address and Control fields are absolutely nothing to do with the PPP in HDLC-like framing Address and Control Fields (but I thought it was obvious that it was what I meant). > Apparently, as I have mentioned in private messages to you in the past, > you do not understand the differentiation between PPP encapsulation > fields (Protocol, Information, Padding), and HDLC, Frame-Relay, and > X.25 framing. Oh, I understand the differences all right. What concerns me is that apparently *you* don't seem to understand the distinction between HDLC-like framing and other services which are already framed, such as X.25, otherwise you wouldn't use terms such as "X.25 framing". PPP simply makes use of the (frame-based) service provided by X.25 - X.25 layer 2 does the actual framing, and PPP in X.25 doesn't need to know exactly how it does it. If you understood X.25 properly you would realise that your diagram of X.25 framing in RFC 1598 section 3.1 is less than helpful - not only does it fail to take into account modulo-8 and modulo-128 sequence numbers, but it also doesn't consider alternative X.25 encapsulations such as X.25 on the ISDN D-channel, and Annex F and Annex G of Frame Relay. The point is that none of these things affects the operation of PPP in X.25 (apart from the issue of alignment). > I think that this is my last post on this topic for awhile. Ok, I shall not post on this topic again either. It's fortunate that PPP in X.25 trivial to implement, and so interoperability problems are unlikely to result from the unhelpful text in RFC 1598. I only brought the matter up because you said it was time to update RFC 1598. --- Jonathan Goodchild - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Oct 7 10:53:12 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id KAA22740; Tue, 7 Oct 1997 10:51:41 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 7 Oct 1997 10:51:06 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA22697 for ietf-ppp-outgoing; Tue, 7 Oct 1997 10:51:04 -0400 (EDT) Received: from dogwood-fddi.cisco.com (dogwood-fddi.cisco.com [171.68.122.80]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA22693 for ; Tue, 7 Oct 1997 10:50:57 -0400 (EDT) Received: from chsharp-pc.cisco.com (chsharp-isdn1.cisco.com [171.68.116.222]) by dogwood-fddi.cisco.com (8.8.5/CISCO.SERVER.1.2) with SMTP id KAA28657; Tue, 7 Oct 1997 10:49:53 -0400 (EDT) Message-ID: <343A4B9F.3C4@cisco.com> Date: Tue, 07 Oct 1997 10:47:59 -0400 From: Chip Sharp Reply-To: chsharp@cisco.com Organization: Cisco Systems X-Mailer: Mozilla 3.0C-CISCOENG (Win95; I) MIME-Version: 1.0 To: kmcgrew@sprynet.com CC: ietf-ppp@merit.edu Subject: Re: PPP Implementations References: <34313571.5639@sprynet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Kelly McGrew wrote: > ...snip... > I have Windows 95, Windows NT, and Macintosh (MacPPP) clients I can use > for the client. Do these clients implement the standards correctly? You might want to look for a compliant client while you look for a complient NAS (although MacPPP might be). In your class, please differentiate the difference between an RFC and a "standard". A RFC is NOT a standard. Only STDs are standards. Anyone can write and publish an RFC. A STD must go through a series of approvals. As of my latest list, STD 51 is the only IETF standard for PPP. There are many RFCs that are in the Draft or Proposed Standard stage. BTW, there are no "compliance" tests to prove that any client or NAS is "compliant". These specifications are for building interoperable implementations, not compliant implementations. Let's hope there won't be any compliance testing, I can just see having to fill out a PICS for PPP for a CE Mark. Blech! Hascall H. ("Chip") Sharp voice: +1 (919) 851-2085 Cisco Systems email: chsharp@cisco.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Oct 7 17:01:14 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id QAA01330; Tue, 7 Oct 1997 16:59:43 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 7 Oct 1997 16:58:42 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id QAA01290 for ietf-ppp-outgoing; Tue, 7 Oct 1997 16:58:41 -0400 (EDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.23]) by merit.edu (8.8.7/8.8.5) with ESMTP id QAA01286 for ; Tue, 7 Oct 1997 16:58:37 -0400 (EDT) Received: by mail3.microsoft.com with Internet Mail Service (5.0.1459.27) id <4L01KSFF>; Tue, 7 Oct 1997 13:59:37 -0700 Message-ID: From: Gurdeep Singh Pall To: "'jmartz@us.ibm.com'" , "'ietf-ppp@merit.edu'" Subject: ACCM Date: Tue, 7 Oct 1997 13:58:34 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1459.27) Sender: owner-ietf-ppp@merit.edu | From: John Martz | | But then I also still hope to hear back from Gurdeep Singh (or anyone else at | MicroSoft) John, sorry for the radio silence. Win9x/NT both use 0xffffffff as the transmit ACCM. They both also use 0x00000000 as the receive ACCM. I'm told (as Karl correctly surmised) that this deviation came from series of interop problems experienced in the field. We havent heard of any problems caused by using 0x00000000 as the receive ACCM (interoperating with a non-conformant transmitter doesnt register as a problem). The current count of types of modems supported on the Windows platforms is 2764 (this list grows everyday - earlier releases may have fewer). I dont have a count of how many of these have been tested with PPP but its not a stretch to assume that most of these types are being used with Windows PPP implementation. Drop me a note if you think our default receive ACCM of 0x00000000 breaks any implementation/deployment out there. Cheers, Gurdeep ====== - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Oct 7 18:56:18 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id SAA03389; Tue, 7 Oct 1997 18:54:52 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 7 Oct 1997 18:54:04 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id SAA03364 for ietf-ppp-outgoing; Tue, 7 Oct 1997 18:54:03 -0400 (EDT) Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.8.7/8.8.5) with SMTP id SAA03357 for ; Tue, 7 Oct 1997 18:53:58 -0400 (EDT) Received: from mica.denver.sgi.com (mica.denver.sgi.com [169.238.67.6]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id PAA17245 for <@sgi.engr.sgi.com:ietf-ppp@merit.edu>; Tue, 7 Oct 1997 15:53:55 -0700 env-from (vjs@mica.denver.sgi.com) Received: (from vjs@localhost) by mica.denver.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA21120 for ietf-ppp@merit.edu; Tue, 7 Oct 1997 16:53:49 -0600 Date: Tue, 7 Oct 1997 16:53:49 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199710072253.QAA21120@mica.denver.sgi.com> To: ietf-ppp@merit.edu Subject: re: ACCM Sender: owner-ietf-ppp@merit.edu >From: Gurdeep Singh Pall > ... >Win9x/NT both use 0xffffffff as the transmit ACCM. They both also use >0x00000000 as the receive ACCM. I'm told (as Karl correctly surmised) >that this deviation came from series of interop problems experienced in >the field. We havent heard of any problems caused by using 0x00000000 as >the receive ACCM (interoperating with a non-conformant transmitter >doesnt register as a problem). The current count of types of modems >supported on the Windows platforms is 2764 (this list grows everyday - >earlier releases may have fewer). I dont have a count of how many of >these have been tested with PPP but its not a stretch to assume that >most of these types are being used with Windows PPP implementation. > ... I wonder if people at Microsoft have looked at enough of their own packet traces. A few years ago, my code had a similar bug of using 0x0 for the initial receive ACCM. I didn't know that it caused problems until investigated some presistent glitches in packet traces. Those problems were no more than a failure to respond to the peer at the first Configure-Requests. Of course, if you don't care how fast you connect, such bugs might not bother you. What my code does now is to start with a receive ACCM of 0xffffffff but before sending even the first Configure-Ack, comply with whatever the peer says in its first Configure-Request (modulo the local configuration information that sets the requested TX ACCM). Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Oct 7 19:49:26 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id TAA04029; Tue, 7 Oct 1997 19:48:02 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 7 Oct 1997 19:47:53 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id TAA04011 for ietf-ppp-outgoing; Tue, 7 Oct 1997 19:47:52 -0400 (EDT) Received: from linux.klos.com (root@klos.com [192.80.49.1]) by merit.edu (8.8.7/8.8.5) with SMTP id TAA04007 for ; Tue, 7 Oct 1997 19:47:47 -0400 (EDT) Received: from 586-100 (1Cust124.max8.new-york.ny.ms.uu.net [153.35.3.252]) by linux.klos.com (8.6.12/8.6.9) with SMTP id TAA09364; Tue, 7 Oct 1997 19:51:33 -0400 Message-ID: <343AF428.1A56@klos.com> Date: Tue, 07 Oct 1997 19:47:04 -0700 From: Michael Klos Organization: Klos Technologies, Inc. X-Mailer: Mozilla 2.0 (Win16; U) MIME-Version: 1.0 To: Vernon Schryver CC: ietf-ppp@merit.edu Subject: Re: ACCM References: <199710072253.QAA21120@mica.denver.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Vernon Schryver wrote: > > >From: Gurdeep Singh Pall > > > ... > >Win9x/NT both use 0xffffffff as the transmit ACCM. They both also use > >0x00000000 as the receive ACCM. I'm told (as Karl correctly surmised) > >that this deviation came from series of interop problems experienced in > >the field. We havent heard of any problems caused by using 0x00000000 as > >the receive ACCM (interoperating with a non-conformant transmitter > >doesnt register as a problem). The current count of types of modems > >supported on the Windows platforms is 2764 (this list grows everyday - > >earlier releases may have fewer). I dont have a count of how many of > >these have been tested with PPP but its not a stretch to assume that > >most of these types are being used with Windows PPP implementation. > > ... > > I wonder if people at Microsoft have looked at enough of their own > packet traces. A few years ago, my code had a similar bug of using 0x0 > for the initial receive ACCM. I didn't know that it caused problems > until investigated some presistent glitches in packet traces. Those > problems were no more than a failure to respond to the peer at the > first Configure-Requests. > > Of course, if you don't care how fast you connect, such bugs might > not bother you. > > What my code does now is to start with a receive ACCM of 0xffffffff but > before sending even the first Configure-Ack, comply with whatever the > peer says in its first Configure-Request (modulo the local > configuration information that sets the requested TX ACCM). > > Vernon Schryver, vjs@sgi.com WRONG! ACCM is 0xffffffff for ALL LCP packets, ALL the time. Why is there so much being said about this? Just do it per spec. and leave it at that!!!!! Mike -- ======================================================================= Michael Klos Email: mike@klos.com Klos, Inc. Voice: (607) 753-0568 12 Jewett FAX: (607) 753-6621 Cortland, NY 13045-2057 Web: http://web.klos.com/ ======================================================================= - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Oct 7 20:25:34 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id UAA04432; Tue, 7 Oct 1997 20:24:02 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 7 Oct 1997 20:23:49 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id UAA04405 for ietf-ppp-outgoing; Tue, 7 Oct 1997 20:23:48 -0400 (EDT) Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.8.7/8.8.5) with SMTP id UAA04401 for ; Tue, 7 Oct 1997 20:23:42 -0400 (EDT) Received: from mica.denver.sgi.com (mica.denver.sgi.com [169.238.67.6]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id RAA21061 for <@sgi.engr.sgi.com:ietf-ppp@merit.edu>; Tue, 7 Oct 1997 17:23:39 -0700 env-from (vjs@mica.denver.sgi.com) Received: (from vjs@localhost) by mica.denver.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA21426 for ietf-ppp@merit.edu; Tue, 7 Oct 1997 18:23:32 -0600 Date: Tue, 7 Oct 1997 18:23:32 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199710080023.SAA21426@mica.denver.sgi.com> To: ietf-ppp@merit.edu Subject: Re: ACCM References: <199710072253.QAA21120@mica.denver.sgi.com> Sender: owner-ietf-ppp@merit.edu > From: Michael Klos > ... > > What my code does now is to start with a receive ACCM of 0xffffffff but > > before sending even the first Configure-Ack, comply with whatever the > > peer says in its first Configure-Request (modulo the local > > configuration information that sets the requested TX ACCM). > WRONG! ACCM is 0xffffffff for ALL LCP packets, ALL the time. Why > is there so much being said about this? Just do it per spec. and leave > it at that!!!!! Why? Well, my religion values working more than obediance to scripture. It is one thing to always send with ACCM=0xffffffff. It is something else to discard incoming bytes when you have a clear indication from the peer that it will not be escaping, for example, 0x11? Moreover, I think you are overstating the words in RFC 1662 and 1661. RFC 1661 says that you must always reset all options to their defaults when you go back to Establish Phase, but where does any RFC say that you "MUST NOT" start using any options requested by the peer before going to Authenticate Phase or until after sending the Configure-Ack? As long as you are going to religously quote "spec.", please point to the chapter and verse. In fact, you may have a significant performance bug if you always receive with ACCM=0xffffffff while your system is in Establish Phase. The trouble is that while your system is in Establish, the peer often will have already advanced and be using ACCM=0. Consider receiving the final LCP Config-Ack immediately followed by an IPCP COnfig-Request. Does your code always set ACCM=0 during the stop and start bits between the two packets, or at least before dealing with the ACCM and FCS of incoming packets? If not, if you delay processing the LCP Config-Ack even a little while, you will be receiving the IPCP Config-Request with ACCM=0xfff, and you will discard any control characters in the IPCP COnfig-Request, and so you will get a bad FCS, and so you will for a timeout and retransmission by the peer. Of course, simplistic, single-thread busy-wait-loop implementations such as might be used on a PC can effectively deal with the ACCM between the two packets, by stopping everything else in the system. Higher performance implementations do not have the luxury of stopping everything. vjs - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Oct 7 20:20:24 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id UAA04355; Tue, 7 Oct 1997 20:19:00 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 7 Oct 1997 20:18:39 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id UAA04335 for ietf-ppp-outgoing; Tue, 7 Oct 1997 20:18:38 -0400 (EDT) Received: from gvmail.globalvillage.com ([198.93.137.253]) by merit.edu (8.8.7/8.8.5) with SMTP id UAA04331 for ; Tue, 7 Oct 1997 20:18:33 -0400 (EDT) Received: from sleet.globalvillage.com [198.93.138.50] by gvmail.globalvillage.com (SMTPD32-4.02) id A146BB008A; Tue, 07 Oct 1997 17:18:14 PDT Received: from ianp by sleet.globalvillage.com (SMI-8.6/SMI-SVR4) id RAA13416; Tue, 7 Oct 1997 17:18:02 -0700 From: "Ian Puleston" To: Subject: Re: PPP over ATM LCP option restrictions Date: Tue, 7 Oct 1997 17:19:52 -0700 Message-ID: <01bcd37f$e5cf32c0$8abf8acf@ianp.globalvillage.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.0103.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.0103.0 Sender: owner-ietf-ppp@merit.edu I am currently implementing a device which runs over AAL5, but sits under an existing PPP stack (which was designed to be running over ISDN). This device therefore falls into the category of a converter. The device can quite easily monitor the LCP negotiations of ACFC, and then strip the 0xFF, 0x03 from outgoing frames, and insert it on incoming frames, if ACFC has not been negotiated on. However, insisting that, quote, "an implementation MUST NOT request" ACFC and "MUST reject a request for such an option" would mean that if it is to comply to the letter of the RFC, my "converter" would need to actively alter the LCP negotiations, since I have no control over the PPP stack above. That would be messy, and would not really achieve anything. -----Original Message----- From: William Allen Simpson To: ietf-ppp@merit.edu Date: Monday, October 06, 1997 4:10 AM Subject: Re: PPP over ATM LCP option restrictions >Finally, this is an implementors list, not a general speculation list. >It would be of great assistance should those writers indicate that they >are actually implementing a PPP/AAL5 to something "converter", or merely >hand-waving. Thanks in advance. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Oct 8 00:03:39 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id AAA08606; Wed, 8 Oct 1997 00:01:24 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 7 Oct 1997 23:34:18 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id XAA08044 for ietf-ppp-outgoing; Tue, 7 Oct 1997 23:34:12 -0400 (EDT) Received: from linux.klos.com (klos@klos.com [192.80.49.1]) by merit.edu (8.8.7/8.8.5) with SMTP id XAA08028 for ; Tue, 7 Oct 1997 23:33:40 -0400 (EDT) Received: (from klos@localhost) by linux.klos.com (8.6.12/8.6.9) id XAA10378; Tue, 7 Oct 1997 23:37:43 -0400 Date: Tue, 7 Oct 1997 23:37:43 -0400 From: Patrick Klos Message-Id: <199710080337.XAA10378@linux.klos.com> To: ietf-ppp@merit.edu, vjs@mica.denver.sgi.com Subject: Re: ACCM Sender: owner-ietf-ppp@merit.edu >> From: Michael Klos >> > What my code does now is to start with a receive ACCM of 0xffffffff but >> > before sending even the first Configure-Ack, comply with whatever the >> > peer says in its first Configure-Request (modulo the local >> > configuration information that sets the requested TX ACCM). (how does this help you receive LCP packets with unescaped control characters?? by "complying with whatever the peer says", you should only be modifying your transmit ACCM, not touching the receive ACCM!) >> WRONG! ACCM is 0xffffffff for ALL LCP packets, ALL the time. Why >> is there so much being said about this? Just do it per spec. and leave >> it at that!!!!! > >Why? Well, my religion values working more than obediance to scripture. I appreciate Mike's desire to adhere to the standard, but I also understand that it's impossible to follow the standard to the letter and expect interoperability. It's especially hard when we decide on this list that certain things should be done certain ways, but don't think those things are important enough to be added to the standard, even if only as an "Implementation Option". (case in point: accepting packets after sending Terminate-Request while waiting for Terminate-Ack) >It is one thing to always send with ACCM=0xffffffff. It is something >else to discard incoming bytes when you have a clear indication from >the peer that it will not be escaping, for example, 0x11? From RFC1661, page 39, section 6: >>> Unless otherwise specified, all Configuration Options apply in a >>> half-duplex fashion; typically, in the receive direction of the link >>> from the point of view of the Configure-Request sender. From RFC1662, page 15: >>> ... The [ACCM] >>> Configuration Option is used to inform the peer which control >>> characters MUST remain mapped when the peer sends them. When peer B sends a Configuration-Request with a non-default ACCM to peer A, why would peer A modify it's RECEIVE ACCM?!? Peer B's ACCM would be reflected in peer A's TRANSMIT ACCM! What if peer B is broken and sending peer A LCP packets with unescaped control codes that peer A has set in it's own ACCM - then you'd have to say that peer B is broken, wouldn't you?!? So why build a crutch for broken implementations when your own crutch would force you to break the spec?? >Moreover, I think you are overstating the words in RFC 1662 and 1661. >RFC 1661 says that you must always reset all options to their defaults >when you go back to Establish Phase, but where does any RFC say that >you "MUST NOT" start using any options requested by the peer before >going to Authenticate Phase or until after sending the Configure-Ack? >As long as you are going to religously quote "spec.", please point to >the chapter and verse. The spec is quite explicit about the construction of LCP packets, indicating that they should always be sent as if no configuration options were negotiated. From RFC1661, page 26, section 5. >>> Regardless of which Configuration Options are enabled, all LCP Link >>> Configuration, Link Termination, and Code-Reject packets (codes 1 >>> through 7) are always sent as if no Configuration Options were >>> negotiated. In particular, each Configuration Option specifies a >>> default value. This ensures that such LCP packets are always >>> recognizable, even when one end of the link mistakenly believes the >>> link to be open. This has always been part of the spec, and the purpose of this requirement is to ensure that LCP packets will ALWAYS be unambiguous in thier reception and interpretation. This section is explicit that ALL LCP packets should conform to this notion, not just the first LCP Configure-Request! Not LCP packets AFTER a peer receives an acceptable LCP Configure-Request! ALL LCP PACKETS (codes 1 thru 7) AT ALL TIMES! Tell me how else to read this?? >In fact, you may have a significant performance bug if you always >receive with ACCM=0xffffffff while your system is in Establish Phase. >The trouble is that while your system is in Establish, the peer often >will have already advanced and be using ACCM=0. Consider receiving the >final LCP Config-Ack immediately followed by an IPCP COnfig-Request. >Does your code always set ACCM=0 during the stop and start bits between >the two packets, or at least before dealing with the ACCM and FCS of >incoming packets? If not, if you delay processing the LCP Config-Ack >even a little while, you will be receiving the IPCP Config-Request with >ACCM=0xfff, and you will discard any control characters in the IPCP >COnfig-Request, and so you will get a bad FCS, and so you will for a >timeout and retransmission by the peer. There are several aspects of your argument that are a bit weak. First off, at 115200 baud, we have 173 microseconds to process the frame before the possibility that a received octet below 0x20 might be received (all NCP or authentication protocol number consist of 2 octets in the range so as not to require escaping - the time to receive 2 octets at 115200 baud is 86.8 microseconds times 2 or 173.6 microseconds). Can't your system respond withing that time frame? Factor into this the fact that most high speed UARTs have at least 16 byte FIFOs and now you're looking at up to 1.388 milliseconds before you run the risk of misinterpreting what you're receiving. I'm sure your fancy systems can respond in that kind of timeframe, no? >Of course, simplistic, single-thread busy-wait-loop implementations >such as might be used on a PC can effectively deal with the ACCM >between the two packets, by stopping everything else in the system. >Higher performance implementations do not have the luxury of stopping >everything. Here we go again. Knocking PC implementations when they don't even have the kludges and flaws you admit to in your own implementation. What a bigot! When was the last time you actually saw a PC implementation? How much time did you spend with it before deciding it was junk? My guess is you're just speculating about platforms you've never really even seen! (at least not for a long time... things change, you know?) As far as "higher performance implementations" go, if your hardware has no FIFOs for you to use (let alone fancier UARTs that will let you specify flag characters, etc), I'd recommend everyone keep away from your products until you can catch up with the rest of us! ============================================================================ Patrick Klos Email: klos@klos.com Klos Technologies, Inc. Voice: (603) 424-8300 604 Daniel Webster Highway FAX: (603) 424-9300 Merrimack, New Hampshire 03054 Web: http://www.klos.com/ ============================================================================ - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Oct 8 07:31:24 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id HAA13760; Wed, 8 Oct 1997 07:28:55 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 8 Oct 1997 07:25:05 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id HAA13726 for ietf-ppp-outgoing; Wed, 8 Oct 1997 07:25:04 -0400 (EDT) Received: from linux.klos.com (klos@klos.com [192.80.49.1]) by merit.edu (8.8.7/8.8.5) with SMTP id HAA13722 for ; Wed, 8 Oct 1997 07:24:59 -0400 (EDT) Received: (from klos@localhost) by linux.klos.com (8.6.12/8.6.9) id HAA12227; Wed, 8 Oct 1997 07:29:25 -0400 Date: Wed, 8 Oct 1997 07:29:25 -0400 From: Patrick Klos Message-Id: <199710081129.HAA12227@linux.klos.com> To: ietf-ppp@merit.edu, Jonathan.Goodchild@rdl.co.uk Subject: Re: Undocumented implementation options Sender: owner-ietf-ppp@merit.edu >> It's especially hard when we decide on this list that certain things >> should be done certain ways, but don't think those things are >> important enough to be added to the standard, even if only as an >> "Implementation Option". (case in point: accepting packets after >> sending Terminate-Request while waiting for Terminate-Ack) > >Actually, I don't think the example is a good one - the fact that this >particular case remains undocumented in the standard is more to do with >Bill Simpson taking an irrational dislike to it than anything else. Which is my point exactly. The people on the list are willing to allow him that control. If the people on the list were concerned about it, they'd formally ask for the change, or someone else could make the change themselves and submit it. Is Bill Simpson the only RFC editor around? ============================================================================ Patrick Klos Email: klos@klos.com Klos Technologies, Inc. Voice: (603) 424-8300 604 Daniel Webster Highway FAX: (603) 424-9300 Merrimack, New Hampshire 03054 Web: http://www.klos.com/ ============================================================================ - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Oct 8 09:08:14 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id JAA14844; Wed, 8 Oct 1997 09:06:41 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 8 Oct 1997 09:06:21 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id JAA14826 for ietf-ppp-outgoing; Wed, 8 Oct 1997 09:06:21 -0400 (EDT) Received: from lms02.us1.ibm.com (lms02.ny.us.ibm.com [198.133.22.25]) by merit.edu (8.8.7/8.8.5) with SMTP id JAA14817 for ; Wed, 8 Oct 1997 09:06:16 -0400 (EDT) Received: from d01lms04.pok.ibm.com by lms02.us1.ibm.com (AIX 4.1/UCB 5.64/4.03) id AB18310; Wed, 8 Oct 1997 13:09:33 GMT Received: by US.IBM.COM (Soft-Switch LMS 2.0) with snapi via D01AU002 id 5010400012108142; Wed, 8 Oct 1997 09:09:35 -0400 From: John Martz To: Subject: recent notes on ACCM Message-Id: <5010400012108142000002L022*@MHS> Date: Wed, 8 Oct 1997 09:09:35 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: owner-ietf-ppp@merit.edu > Win9x/NT both use 0xffffffff as the transmit ACCM. They both also use > 0x00000000 as the receive ACCM. I'm told (as Karl correctly surmised) > that this deviation came from series of interop problems experienced in > the field. Gurdeep, thank you very much for responding and clarifying the behavior of the current Win95/NT PPP implementations. I appreciate being able to get external confirmation on how an implementation functions so I don't have to depend on speculation. > Drop me a note if you think our default receive ACCM of 0x00000000 > breaks any implementation/deployment out there. Correct me if I'm wrong, but I don't think there is any disagreement that if ... for whatever reason ... the 0x00-0x1F control codes were injected into the data stream delivered to Win95/NT then a customer would be unable to connect to your implementation. When the receive ACCM is 0x00000000 the unescaped control codes would not be filtered out of the packet and would result in a bad FCS. The packets would be discarded. The question of course is whether or not anyone gives (or should give) a gosh darn about this. I wish I had something useful to add to this part of the discussion. I don't. All I can say is that for our implementation ... if it is ever released to customers in some currently unspecified and uncommitted bright, sunny future day ... I'll go with the default as specified in the RFCs and only override it if we run into problems in the field due to errors in the peer's tx ACCM implementation. I think it's quite unlikely that some IBM customers will expect their existing "legacy" equipment to interoperate correctly with our system. In order to be sure we could do this, we'd need to keep open the option of being able to filter out interjected control codes via a non-0 receive ACCM. (Not that long ago we were contacted by a customer who had an "ancient" IBM 2400 baud modem that they wanted to use with our current SLIP implementation. The customer didn't care that s/he could drastically improve their throughput and get rid of all configuration problems by purchasing/using any of the newer V.34 modems for a pittance. They'd paid a LOT of money for that 2400 baud paper weight and they INSISTED that they should still be able to use it). Reflecting on the notes over the last few days on this subject I had a recollection from an American history class years ago. When Congress over-rode Andrew Jackson's veto of a bill he strongly disagreed with his response was (I think), 'Congress has passed their law. Now let us see if they can enforce it.'. There is definitely a large aspect of "pushing on a string" to this whole discussion. We can debate, flame, persuade all we want in this mailing list, but the individual implementors will still do what they choose to do for the reasons they choose to do it. Thanks again for the feedback. As I say, I appreciate getting the facts. -john martz IBM AS/400 TCP/IP PPP development - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Oct 8 10:27:27 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id KAA16411; Wed, 8 Oct 1997 10:25:53 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 8 Oct 1997 10:25:16 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA16372 for ietf-ppp-outgoing; Wed, 8 Oct 1997 10:25:15 -0400 (EDT) Received: from atlas.xylogics.com (atlas.xylogics.com [132.245.33.7]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA16364 for ; Wed, 8 Oct 1997 10:25:09 -0400 (EDT) Received: from gmg.xylogics.com (gmg-pc.xylogics.com [132.245.33.214]) by atlas.xylogics.com (8.7.3/8.7.3) with SMTP id KAA18540 for ; Wed, 8 Oct 1997 10:22:39 -0400 (EDT) Received: by localhost with Microsoft MAPI; Wed, 8 Oct 1997 10:21:29 -0400 Message-ID: <01BCD3D3.F1462EC0.gmg@baynetworks.com> From: "Gary M. Greenberg" Reply-To: "gmg@baynetworks.com" To: "'ietf-ppp'" Subject: LCP Callback Operation Options Date: Wed, 8 Oct 1997 10:21:26 -0400 Organization: Bay Networks - Remote Access Server Division X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Can anyone explain to me the difference between LCP Callback Operation Options 1 and 3? They both appear to be the same, and effectively DNIS. Is this correct? Thanks, Gary -- Gary M. Greenberg Principal Software Engineer email: gmg@baynetworks.com Bay Networks, Inc vox: (508)916-4241 Remote Access Server Division fax: (508)916-4789 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Oct 8 10:42:14 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id KAA16709; Wed, 8 Oct 1997 10:40:52 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 8 Oct 1997 10:40:44 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA16687 for ietf-ppp-outgoing; Wed, 8 Oct 1997 10:40:43 -0400 (EDT) Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.8.7/8.8.5) with SMTP id KAA16683 for ; Wed, 8 Oct 1997 10:40:39 -0400 (EDT) Received: from mica.denver.sgi.com (mica.denver.sgi.com [169.238.67.6]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id HAA28643 for <@sgi.engr.sgi.com:ietf-ppp@merit.edu>; Wed, 8 Oct 1997 07:40:36 -0700 env-from (vjs@mica.denver.sgi.com) Received: (from vjs@localhost) by mica.denver.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA22786 for ietf-ppp@merit.edu; Wed, 8 Oct 1997 08:40:30 -0600 Date: Wed, 8 Oct 1997 08:40:30 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199710081440.IAA22786@mica.denver.sgi.com> To: ietf-ppp@merit.edu Subject: Re: ACCM Sender: owner-ietf-ppp@merit.edu > From: Patrick Klos > ... > >It is one thing to always send with ACCM=0xffffffff. It is something > >else to discard incoming bytes when you have a clear indication from > >the peer that it will not be escaping, for example, 0x11? > > >From RFC1661, page 39, section 6: > >>> Unless otherwise specified, all Configuration Options apply in a > >>> half-duplex fashion; typically, in the receive direction of the link > >>> from the point of view of the Configure-Request sender. > > >From RFC1662, page 15: > >>> ... The [ACCM] > >>> Configuration Option is used to inform the peer which control > >>> characters MUST remain mapped when the peer sends them. > > When peer B sends a Configuration-Request with a non-default ACCM to > peer A, why would peer A modify it's RECEIVE ACCM?!? Peer B's ACCM > would be reflected in peer A's TRANSMIT ACCM! What if peer B is > broken and sending peer A LCP packets with unescaped control codes > that peer A has set in it's own ACCM - then you'd have to say that > peer B is broken, wouldn't you?!? So why build a crutch for broken > implementations when your own crutch would force you to break the spec?? > > >Moreover, I think you are overstating the words in RFC 1662 and 1661. > >RFC 1661 says that you must always reset all options to their defaults > >when you go back to Establish Phase, but where does any RFC say that > >you "MUST NOT" start using any options requested by the peer before > >going to Authenticate Phase or until after sending the Configure-Ack? > >As long as you are going to religously quote "spec.", please point to > >the chapter and verse. > > The spec is quite explicit about the construction of LCP packets, indicating > that they should always be sent as if no configuration options were > negotiated. Yes, but as you say, that applies to the transmit ACCM. As you say, the standards are explicit about the <> of LCP packets. We are talking about the receive ACCM, or about the interpretation of received packets. Where are the words in which RFC that say when you switch change the ACCM, and in particular, where are the words that say you use a received ACCM on LCP packets? > >From RFC1661, page 26, section 5. > >>> Regardless of which Configuration Options are enabled, all LCP Link > >>> Configuration, Link Termination, and Code-Reject packets (codes 1 > >>> through 7) are always sent as if no Configuration Options were > >>> negotiated. In particular, each Configuration Option specifies a > >>> default value. This ensures that such LCP packets are always > >>> recognizable, even when one end of the link mistakenly believes the > >>> link to be open. > > This has always been part of the spec, and the purpose of this requirement > is to ensure that LCP packets will ALWAYS be unambiguous in thier reception > and interpretation. This section is explicit that ALL LCP packets should > conform to this notion, not just the first LCP Configure-Request! Not > LCP packets AFTER a peer receives an acceptable LCP Configure-Request! > ALL LCP PACKETS (codes 1 thru 7) AT ALL TIMES! Tell me how else to > read this?? As you say, the words are about the transmit ACCM. We all agree (I think) that about which <> ACCM to use and when. However, we are talking about the <> ACCM. You do use two completely different and largely independent ACCMs in your code, don't you? How do you know when you are receiving a packet whether it is an LCP packet? What if you have been receiving data packets for a long time, and the peer is just now deciding to re-negotiate LCP? Or have you not fixed your implementation to allow LCP to be renegotiated, and so have not needed to confront that issue? What happens when your code decides to renegotiated LCP? Of course you change the transmit ACCM, but when do you start applying a receive ACCM of 0xffffffff? > >In fact, you may have a significant performance bug if you always > >receive with ACCM=0xffffffff while your system is in Establish Phase. > ... > There are several aspects of your argument that are a bit weak. First off, > at 115200 baud, we have 173 microseconds to process the frame before the > possibility that a received octet below 0x20 might be received (all NCP > or authentication protocol number consist of 2 octets in the range so as > not to require escaping - the time to receive 2 octets at 115200 baud is > 86.8 microseconds times 2 or 173.6 microseconds). Can't your system > respond withing that time frame? Factor into this the fact that most > high speed UARTs have at least 16 byte FIFOs and now you're looking at > up to 1.388 milliseconds before you run the risk of misinterpreting what > you're receiving. I'm sure your fancy systems can respond in that kind > of timeframe, no? Are you not imagining that all of the world canuse a single thread on a single CPU not only handles the UART, but also the ACCM, FCS, IP, TCP, and the application? Say you do not use the too-familiar PC busy-wait loop. (Not that busy wait loops are bad in their place. About 3 years ago that I made an 8 UART, 8088-based board 12 times faster by dumping interrupts in favor of pure busy-waiting). Can you think of reasons not to run your PPP state machine at (the equivalent of) high interrupt priority even when you have several 1000 MIPS available? Say that besides using interrupts, you do not put the PPP state machines into your interrupt. Say you also run at more than a mere 128 kbit/sec, say 1.54 Mbit/sec. Maybe you support more than one T1 simultaneously, while also running some async channels. Can you think of any good reasons in such an implementation to not to use a single thread of control for everything? I think I can. Say that you separate the machinery that deals with the FIFOs and/or DMA machines (you know, of course, that some systems use DMA, not just 16t50's and busy-loops) of the USARTs (not necessarily UARTs) from the thread of code that deals with low priority stuff such as the PPP state machines. Now, while what do you do that minimizes involve global locks and hazardous system-wide synchronization points (since they put you back into the single-thread regime)? > >Of course, simplistic, single-thread busy-wait-loop implementations > >such as might be used on a PC can effectively deal with the ACCM > >between the two packets, by stopping everything else in the system. > >Higher performance implementations do not have the luxury of stopping > >everything. > > Here we go again. Knocking PC implementations when they don't even have > the kludges and flaws you admit to in your own implementation. What a > bigot! When was the last time you actually saw a PC implementation? How > much time did you spend with it before deciding it was junk? My guess is > you're just speculating about platforms you've never really even > seen! (at least not for a long time... things change, you know?) > > > As far as "higher performance implementations" go, if your hardware has > no FIFOs for you to use (let alone fancier UARTs that will let you > specify flag characters, etc), I'd recommend everyone keep away from > your products until you can catch up with the rest of us! > I have seen some PC PPP code working, and daily have the (so called) pleasure using Win95, albeit not with PPP. I don't know for certain that it turns off interrupts every little whipstitch, but it appears to. Much (but not all) PC code is known as junk among people who've seen more than one or two systems is not only because of jealous prejudice. I've been known to observe that those involved with the most popular PC system are often more provincial than the worst IBM partisans from the bad old days of 20 years ago. There are other ways to do things than in DOS, although it is dangerous to try to make some people understand that. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Oct 8 11:24:13 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id LAA17702; Wed, 8 Oct 1997 11:22:34 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 8 Oct 1997 11:22:05 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id LAA17661 for ietf-ppp-outgoing; Wed, 8 Oct 1997 11:22:05 -0400 (EDT) Received: from relay1.smtp.psi.net (relay1.smtp.psi.net [38.8.14.2]) by merit.edu (8.8.7/8.8.5) with ESMTP id LAA17651 for ; Wed, 8 Oct 1997 11:22:00 -0400 (EDT) Received: from wacko.aptis.com by relay1.smtp.psi.net (8.8.5/SMI-5.4-PSI) id LAA08522; Wed, 8 Oct 1997 11:21:59 -0400 (EDT) Received: by wacko.aptis.com with Internet Mail Service (5.0.1457.3) id <4M632JCH>; Wed, 8 Oct 1997 11:23:33 -0400 Message-ID: From: Marty Del Vecchio To: ietf-ppp@merit.edu Subject: RE: recent notes on ACCM Date: Wed, 8 Oct 1997 11:23:32 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Sender: owner-ietf-ppp@merit.edu When Congress over-rode Andrew Jackson's veto of a bill he strongly disagreed with his response was (I think), 'Congress has passed their law. Now let us see if they can enforce it.'. Forget this ACCM business--I thought that Congress passed laws, and the executive branch enforced them. Where does Jackson get off grandstanding like this? This is outrageous! I guess that's what happens when you try to rule by law, instead of by rough consensus. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Oct 8 11:29:09 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id LAA17872; Wed, 8 Oct 1997 11:27:47 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 8 Oct 1997 11:27:29 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id LAA17835 for ietf-ppp-outgoing; Wed, 8 Oct 1997 11:27:28 -0400 (EDT) Received: from relay1.smtp.psi.net (relay1.smtp.psi.net [38.8.14.2]) by merit.edu (8.8.7/8.8.5) with ESMTP id LAA17823 for ; Wed, 8 Oct 1997 11:27:20 -0400 (EDT) Received: from wacko.aptis.com by relay1.smtp.psi.net (8.8.5/SMI-5.4-PSI) id LAA10191; Wed, 8 Oct 1997 11:27:18 -0400 (EDT) Received: by wacko.aptis.com with Internet Mail Service (5.0.1457.3) id <4M632JCK>; Wed, 8 Oct 1997 11:28:53 -0400 Message-ID: From: Marty Del Vecchio To: ietf-ppp@merit.edu Subject: RE: ACCM Date: Wed, 8 Oct 1997 11:28:51 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Sender: owner-ietf-ppp@merit.edu Much (but not all) PC code is known as junk among people who've seen more than one or two systems is not only because of jealous prejudice. This must be because all good programmers work on embedded systems and all bad programmers work on PCs. Or maybe it's the "I liked that cool band before they sold out and became popular" phenomenon. Since PC software makes so much $$, it must be as crass and commercial as Mariah Carey. Lighten up, Francis! - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Oct 8 11:29:00 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id LAA17859; Wed, 8 Oct 1997 11:27:35 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 8 Oct 1997 11:27:20 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id LAA17815 for ietf-ppp-outgoing; Wed, 8 Oct 1997 11:27:19 -0400 (EDT) Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.8.7/8.8.5) with SMTP id LAA17811 for ; Wed, 8 Oct 1997 11:27:13 -0400 (EDT) Received: from mica.denver.sgi.com (mica.denver.sgi.com [169.238.67.6]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id IAA11816 for <@sgi.engr.sgi.com:ietf-ppp@merit.edu>; Wed, 8 Oct 1997 08:27:04 -0700 env-from (vjs@mica.denver.sgi.com) Received: (from vjs@localhost) by mica.denver.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA22964 for ietf-ppp@merit.edu; Wed, 8 Oct 1997 09:26:57 -0600 Date: Wed, 8 Oct 1997 09:26:57 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199710081526.JAA22964@mica.denver.sgi.com> To: ietf-ppp@merit.edu Subject: Re: ACCM Sender: owner-ietf-ppp@merit.edu > From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) (I hope I won't offend by answering publically.) > > >>> > What my code does now is to start with a receive ACCM of 0xffffffff but > >>> > before sending even the first Configure-Ack, comply with whatever the > >>> > peer says in its first Configure-Request (modulo the local > >>> > configuration information that sets the requested TX ACCM). > > > (how does this help you receive LCP packets with unescaped control > > characters?? by "complying with whatever the peer says", you should > > only be modifying your transmit ACCM, not touching the receive > > ACCM!) > What you said does look a bit confused - did you mean that you start > with a TX ACCM of 0xffffffff, and then use whatever the peer sends in > its config request? That looks like it won't work if the peer sticks > to an RX ACCM of 0xffffffff until after LCP is open. You should send all LCP packets with a transmitt of 0xffffffff. THe problem is not with the transmit ACCM. When in doubt, you can always use 0xffffffff without loss of anything except speed. The problem is with the received ACCM. If you use too small a receive ACCM, you risk paying attention to junk and so risk having a bad FCS and so losing data. If you use too large an ACCM, you risk losing data. The received ACCM must be exactly right, or you will lose data. > Or did you mean that you start with an RX ACCM of 0xffffffff, and > then, when you receive an ACK (or a NAK) from the peer, you adjust > the RX ACCM from that point? That certainly ought to work (even if > it isn't strictly compliant). As soon as I hear a Configure-Request from the peer, I use an RX ACCM that is combination of my statically configured received ACCM and the peer's requested receive (or my future transmit) ACCM. Please show me the words that say that is or is not compliant. The receive ACCM is an unavoidable, unfixable mess. For example, consider what must happen when either peer decides to renegotiate LCP. Of course, it can start using a transmit ACCM of 0xffffffff, but what about the receive ACCM? If it goes from the negotiated 0x0 to 0xffffffff, then it can expect to lose data. That is a Bad Thing. On the other hand, if a peer is somehow confident that the path does not involve spurious injected bytes, as when its statically configured received ACCM is 0 and the peer has requested 0, then continuing to use a receive ACCM of 0 is a Good Thing that avoid loss of data. Now apply the same reasoning to the situation 3 packets through the 4-packet LCP dance. This situation is similar to continuinging to receive data after sending Terminate-Request, except that the the standards do not address this situation at all. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Oct 8 11:43:47 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id LAA18238; Wed, 8 Oct 1997 11:42:09 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 8 Oct 1997 11:41:30 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id LAA18197 for ietf-ppp-outgoing; Wed, 8 Oct 1997 11:41:29 -0400 (EDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by merit.edu (8.8.7/8.8.5) with ESMTP id LAA18193 for ; Wed, 8 Oct 1997 11:41:25 -0400 (EDT) Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id LAA21256; Wed, 8 Oct 1997 11:14:06 -0400 (EDT) Received: from marvin.zk3.dec.com by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA14201; Wed, 8 Oct 1997 11:13:56 -0400 Message-Id: <343BA333.167E@zk3.dec.com> Date: Wed, 08 Oct 1997 11:13:55 -0400 From: "Farrell T. Woods - Base OS Networking" Organization: Digital Equipment Corporation X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 T4.0 alpha) Mime-Version: 1.0 To: ietf-ppp@merit.edu Cc: audrey@vanb.com, bglover@zk3.dec.com Subject: Connectathon '98, call for participation Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Hello folks, For two years now, PPP interoperability has been tested at Connectathon. I've been invited to coordinate PPP interoperability testing for Connectathon '98. There are of course a number of interesting technologies that we could test at this event. Please respond directly to me if you would like to participate in testing any of the following technologies: o Async PPP over dial-up connections. Yes, yes: old stuff. But given the recent discussions surrounding the effects of the default receive and transmit ACCM, this could be interesting. Also good for testing stuff like callback, etc. We have telephone switch simulators to create the phone "network". o PPP over ISDN, via another switch simulator. o PPP over ATM. The test network does include ATM, so this technology could be tested as well. o Various NP's and other options: IP obviously, IPv6, perhaps IPX, authentication, encryption, compression, multilink... Please contact me directly if you have an interest in participating. Connectathon '98 runs from March 4 through March 12, 1998 (inclusive of one day of setup and one day of teardown.) The event will likely return to San Jose, CA for 1998 (it's almost always been in San Jose, but last year we ended up in San Francisco.) If I didn't mention a particular PPP-related technology that you would like to test then please let me know. I will roll up the responses and start getting stuff sorted out. What I need to know from you when you respond is your name, your company, and what PPP-related technologies you would like to test. For those who are unfamiliar with the Connectathon events: Connectathon provides a vendor-neutral environment in which interoperability of our implementations of various protocol suites are tested. Originally it was for NFS and NFS continues to be the dominant technology that is tested. But in recent years the event has expanded to include a number of other protocols. The past two events have included PPP. Some folks draw anologies between Connectathon and what Interop used to be before it turned into a suit show. The people who participate in Connectathon are all us techies. No suits are allowed, however there is a "press day" at the end of the event. It is frequently the case that we will bring with us source code to do active development and debugging. There is a spirit of cooperation in this event which allows for us help one another debug things. Connectathon runs 24 hours each day, and during "normal business hours" there are specific scheduled tests for different technologies and also a smattering of technical presentations on various topics. It's a unique opportunity to touch base with colleagues, hash things out face-to-face outside of formal settings (e.g. the IETF), put our assertions and code to the test, and have some fun. For an idea of what goes on at Connectathon, the web page for the '97 event is still up: http://www.sun.com/software/connectathon/ At some point I expect this page will be updated to reflect happenings at the '98 event as things gel a bit. -- -- Farrell - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Oct 8 11:46:45 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id LAA18378; Wed, 8 Oct 1997 11:45:23 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 8 Oct 1997 11:44:54 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id LAA18353 for ietf-ppp-outgoing; Wed, 8 Oct 1997 11:44:53 -0400 (EDT) Received: from linux.klos.com (klos@klos.com [192.80.49.1]) by merit.edu (8.8.7/8.8.5) with SMTP id LAA18347 for ; Wed, 8 Oct 1997 11:44:43 -0400 (EDT) Received: (from klos@localhost) by linux.klos.com (8.6.12/8.6.9) id LAA13588; Wed, 8 Oct 1997 11:49:09 -0400 Date: Wed, 8 Oct 1997 11:49:09 -0400 From: Patrick Klos Message-Id: <199710081549.LAA13588@linux.klos.com> To: ietf-ppp@merit.edu, vjs@mica.denver.sgi.com Subject: Re: ACCM Sender: owner-ietf-ppp@merit.edu >> The spec is quite explicit about the construction of LCP packets, indicating >> that they should always be sent as if no configuration options were >> negotiated. > >Yes, but as you say, that applies to the transmit ACCM. As you say, >the standards are explicit about the <> of LCP packets. >We are talking about the receive ACCM, or about the interpretation of >received packets. Why are you making excuses for someone elses incorrectly constructed LCP packets?!? Like Mike said, this should be a non-discussion! We should not build a crutch for broken implementations that don't follow the standard reasonably. It's not a hard thing to do! >Where are the words in which RFC that say when you switch change the >ACCM, and in particular, where are the words that say you use a >received ACCM on LCP packets? There are no words, but most reasonable people agree (I think) that negotiated options are applied upon entering the Opened state. Sure you have a possible problem if you don't process the options before the next packet reception starts, but it's not such a big deal! You don't bring up your IP layer before IPCP reaches the Opened state, do you? Oh no! What if you receive a (short) IP packet before you get the IP layer fully up? You'll have to toss that packet! Now what do we do? Same deal. It's an unreliable link - that kind of thing happens! >As you say, the words are about the transmit ACCM. We all agree (I >think) that about which <> ACCM to use and when. However, we >are talking about the <> ACCM. You do use two completely >different and largely independent ACCMs in your code, don't you? Not during LCP negotiations, we don't! >How do you know when you are receiving a packet whether it is an LCP >packet? You don't know if the packet you're receiving is LCP, but that doesn't make it alright to send an LCP packet that doesn't conform to the standard! >What if you have been receiving data packets for a long time, >and the peer is just now deciding to re-negotiate LCP? A properly formatted LCP packet will ALWAYS be receivable regardless of your current Receive ACCM. >Or have you not >fixed your implementation to allow LCP to be renegotiated, and so have >not needed to confront that issue? Apparently, you have never used our PPP implementation. We have supported LCP renegotiation from day 1! (you see, when software is designed properly, it runs well on ANY platform) >What happens when your code decides to renegotiated LCP? Of course you >change the transmit ACCM, but when do you start applying a receive ACCM >of 0xffffffff? At any time that LCP is NOT in the Opened state, the transmit and receive ACCMs are 0xffffffff. The standard encourages that, if it doesn't explicitly state that! >Are you not imagining that all of the world canuse a single thread on a >single CPU not only handles the UART, but also the ACCM, FCS, IP, TCP, >and the application? Of course, I am NOT imagining that. Don't be so simple minded! >Say you do not use the too-familiar PC busy-wait loop. We don't. >Can you think of reasons not to run your PPP >state machine at (the equivalent of) high interrupt priority even when >you have several 1000 MIPS available? Say that besides using >interrupts, you do not put the PPP state machines into your interrupt. We don't. >Say you also run at more than a mere 128 kbit/sec, say 1.54 Mbit/sec. If you're stupid enough to do 1.54 Mbit/sec but have to deal with each byte one at a time (your original premise that got us here), then I've given you too much credit! ;^) [otherwise, you're trying to compare apples to oranges] >Maybe you support more than one T1 simultaneously, while also running >some async channels. Yes. So there will be times when the possibility exists that ACCMs are not updated exactly when they need to be. That's the nature of the beast. If you're really worried about the async bytes having problems, I'm sure you could come up with a clean way to process the bytes at a time when all appropriate options have been processed. (come on, Vern, use your imagination) >Can you think of any good reasons in such an implementation to not to >use a single thread of control for everything? I think I can. Why do you keep talking about this obviously poor design? Is this how your PPP is done? Do you know of an implementation that does it this way?? I don't! >I have seen some PC PPP code working, and daily have the (so called) >pleasure using Win95, albeit not with PPP. I don't know for certain >that it turns off interrupts every little whipstitch, but it appears >to. Much (but not all) PC code is known as junk among people who've >seen more than one or two systems is not only because of jealous >prejudice. In your case, it wouldn't be "jealous prejudice", but simply "blind prejudice"! There's nothing to be jealous about that I know of? >I've been known to observe that those involved with the most popular PC >system are often more provincial than the worst IBM partisans from the >bad old days of 20 years ago. There are other ways to do things than >in DOS, although it is dangerous to try to make some people understand >that. Yeah, I dislike those people too. Just as much as I dislike anyone who will put down anything they don't like or don't understand. Some people just aren't willing to try! ============================================================================ Patrick Klos Email: klos@klos.com Klos Technologies, Inc. Voice: (603) 424-8300 604 Daniel Webster Highway FAX: (603) 424-9300 Merrimack, New Hampshire 03054 Web: http://www.klos.com/ ============================================================================ - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Oct 8 12:09:01 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id MAA19084; Wed, 8 Oct 1997 12:07:39 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 8 Oct 1997 12:07:09 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id MAA19047 for ietf-ppp-outgoing; Wed, 8 Oct 1997 12:07:08 -0400 (EDT) Received: from databus.databus.com (databus.databus.com [198.186.154.34]) by merit.edu (8.8.7/8.8.5) with SMTP id MAA19043 for ; Wed, 8 Oct 1997 12:07:03 -0400 (EDT) From: Barney Wolff To: ietf-ppp@merit.edu Date: Wed, 8 Oct 1997 11:55 EDT Subject: Re: ACCM Content-Type: text/plain Message-ID: <343bafa40.3a32@databus.databus.com> Sender: owner-ietf-ppp@merit.edu > Date: Wed, 8 Oct 1997 09:26:57 -0600 > From: vjs@mica.denver.sgi.com (Vernon Schryver) > > The receive ACCM is an unavoidable, unfixable mess. I'm sure I'm just dense, but I don't see what the problem is, in the real world, even when one side starts to renegotiate LCP after a long happy period of exchanging IP with ACCM not ffffffff. The peer receiving that LCP frame, unless it does really fancy lookahead, will not realize it's LCP until it's already processed the control field, which should be escaped. But a conformant peer will always escape the control field, and that works no matter what the other side uses as its receive ACCM. If there is something in the path that inserts control chars, the ACCM that was negotiated the first time had better have reflected that, or communication would not have been established. So using the old non- default receive ACCM won't hurt, because it was correct for the path. The only way I can see that *when* you switch the receive ACCM could matter is if the nature of the path changes, and that's why the other side is renegotiating LCP. Can anybody point to a realistic scenario where this happens? Barney Wolff - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Oct 8 12:12:28 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id MAA19163; Wed, 8 Oct 1997 12:11:06 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 8 Oct 1997 12:10:53 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id MAA19142 for ietf-ppp-outgoing; Wed, 8 Oct 1997 12:10:52 -0400 (EDT) Received: from relay1.smtp.psi.net (relay1.smtp.psi.net [38.8.14.2]) by merit.edu (8.8.7/8.8.5) with ESMTP id MAA19137 for ; Wed, 8 Oct 1997 12:10:46 -0400 (EDT) Received: from wacko.aptis.com by relay1.smtp.psi.net (8.8.5/SMI-5.4-PSI) id MAA00087; Wed, 8 Oct 1997 12:10:46 -0400 (EDT) Received: by wacko.aptis.com with Internet Mail Service (5.0.1457.3) id <4M632JDC>; Wed, 8 Oct 1997 12:12:20 -0400 Message-ID: From: Marty Del Vecchio To: ietf-ppp@merit.edu Subject: RE: ACCM Date: Wed, 8 Oct 1997 12:12:08 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Sender: owner-ietf-ppp@merit.edu >Patrick Klos [klos@klos.com] said: >Why are you making excuses for someone elses incorrectly constructed LCP > >packets?!? Like Mike said, this should be a non-discussion! We > should > >not build a crutch for broken implementations that don't follow the > >standard reasonably. It's not a hard thing to do! > > Except that interoperability is the overriding concern for a > commercial > product. Hypothetically, if you are building a "fully-compliant" RAS > server, > and you test it against the Win95/WinNT client, and it has a bug that > causes packets not to get through, what do you do? > > Do you say, "I'm right, they're wrong, and our customers will just > have to > yell at Microsoft for them to fix their code?" Of course not--it > takes a large > company like Microsoft too long to release updates for this to be a > legitimate > strategy. So you put a hack in to interoperate with that code, and > hopefully > inform someone at Microsoft of the problem, which will eventually get > fixed. > > Of course, if everybody wrote a fully-compliant implementation of PPP, > then we wouldn't have any such interoperability problems. But for > some > reason, despite the best efforts of people on this list, it hasn't > happened > that way. > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Oct 8 12:15:02 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id MAA19243; Wed, 8 Oct 1997 12:13:40 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 8 Oct 1997 12:13:19 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id MAA19214 for ietf-ppp-outgoing; Wed, 8 Oct 1997 12:13:19 -0400 (EDT) Received: from rnd-gate.rad.co.il (rnd-gate.rad.co.il [207.232.32.14]) by merit.edu (8.8.7/8.8.5) with ESMTP id MAA19202 for ; Wed, 8 Oct 1997 12:13:08 -0400 (EDT) Received: from smtp-gateway.rad.co.il ([176.189.111.1]) by rnd-gate.rad.co.il (8.7.3/8.7.3) with SMTP id SAA27483 for ; Wed, 8 Oct 1997 18:00:12 +0200 (IST) Received: by smtp-gateway.rad.co.il with Microsoft Mail id <343BB180@smtp-gateway.rad.co.il>; Wed, 08 Oct 97 18:14:56 EST From: Michael Liwerant To: "'ietf_ppp'" Subject: Chap Challenge Name Date: Wed, 08 Oct 97 18:12:00 EST Message-ID: <343BB180@smtp-gateway.rad.co.il> X-Mailer: Microsoft Mail V3.0 Sender: owner-ietf-ppp@merit.edu Hi Guys, We are using Chap authentication protocol whose parameters are configured by the user ONLY according to the relevant Managed Object (RFC 1472). Our question is what NAME should be used by the Authenticator when sending the Challenge message ? We are considering the following options: 1) If we should use the NAME which is configured in the Local-to-Remote field (of the relevant entry in the pppSecuritySecretsTable) then it means that the user must configure a valid Local-to-Remote entry even if there is NO intention to use the router as a "peer". 2) Is there any significance at all to the NAME sent in the challenge transmission (by the Authenticator) ? why not just send an empty NAME field (single zero or a dummy value) ? after all the peer will use ITS Local-to-Remote name when sending the response... I'll appreciate your help - Michael L. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Oct 8 13:22:30 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id NAA20766; Wed, 8 Oct 1997 13:21:08 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 8 Oct 1997 13:20:53 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id NAA20728 for ietf-ppp-outgoing; Wed, 8 Oct 1997 13:20:53 -0400 (EDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm035-28.dialip.mich.net [141.211.7.39]) by merit.edu (8.8.7/8.8.5) with SMTP id NAA20711 for ; Wed, 8 Oct 1997 13:20:43 -0400 (EDT) Date: Wed, 8 Oct 97 16:57:01 GMT From: "William Allen Simpson" Message-ID: <6647.wsimpson@greendragon.com> To: ietf-ppp@merit.edu Subject: Re: Undocumented implementation options Sender: owner-ietf-ppp@merit.edu Hmmm, I did not receive the quoted personal attack on the list. > From: Patrick Klos > Message-Id: <199710081129.HAA12227@linux.klos.com> > To: ietf-ppp@merit.edu, Jonathan.Goodchild@rdl.co.uk > >> It's especially hard when we decide on this list that certain things > >> should be done certain ways, but don't think those things are > >> important enough to be added to the standard, even if only as an > >> "Implementation Option". (case in point: accepting packets after > >> sending Terminate-Request while waiting for Terminate-Ack) The requirement is neither undocumented, nor a permitted option. RFC-1661 clearly says: 3.7. Link Termination Phase ... Any non-LCP packets received during this phase MUST be silently discarded. > >Actually, I don't think the example is a good one - the fact that this > >particular case remains undocumented in the standard is more to do with > >Bill Simpson taking an irrational dislike to it than anything else. > > Which is my point exactly. The people on the list are willing to allow > him that control. If the people on the list were concerned about it, > they'd formally ask for the change, or someone else could make the > change themselves and submit it. Is Bill Simpson the only RFC editor > around? Not by a long shot. However, in this case, the RFC is at "Full Standard". And it must not change, which could cause interoperability problems for folks that followed the Standard. If you want a new protocol, write one, just don't call it PPP. Nor is the dislike "irrational". The carefully written text on Terminate arises from interoperability testing between Cisco and Telebit and a few others in '90 and '91. We made things work.... As I've said before, if you want a new "temporary half closing" message, then you should write one, probably as part of BACP. But it cannot be LCP Terminate-Request and Terminate-Ack, which already have very clear semantics defined. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Oct 8 13:22:27 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id NAA20761; Wed, 8 Oct 1997 13:21:06 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 8 Oct 1997 13:20:50 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id NAA20717 for ietf-ppp-outgoing; Wed, 8 Oct 1997 13:20:50 -0400 (EDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm035-28.dialip.mich.net [141.211.7.39]) by merit.edu (8.8.7/8.8.5) with SMTP id NAA20709 for ; Wed, 8 Oct 1997 13:20:42 -0400 (EDT) Date: Wed, 8 Oct 97 16:43:16 GMT From: "William Allen Simpson" Message-ID: <6646.wsimpson@greendragon.com> To: ietf-ppp@merit.edu Subject: Re: LCP Callback Operation Options Sender: owner-ietf-ppp@merit.edu > From: "Gary M. Greenberg" > Can anyone explain to me the difference between LCP Callback Operation Options > 1 and 3? They both appear to be the same, and effectively DNIS. Is this > correct? > For (1), the string is in ASCII or its equivalent, and knowledge about the specific device is needed -- PBX, timing, and such. Commas, semi-colons, hyphens, etc, are treated "as is" by the dialer. For (3), the E.164 number is fully specified, but whatever extra escapes and timing and PBX codes and such are added by the dialing code. And (my fuzzy recollection) isn't E.164 a form of unpacked decimal, not ASCII? I remember having to massage it for the Rockwell PRI in '92. And will you need E.165 for international ISDN? ... 1 Dialing string, the format and contents of which assumes configuration knowledge of the specific device that is making the callback. A North American example might be: 10222,,,(800)555-1212. This method is commonly supported, but suffers from fre- quent configuration error. ... 3 E.164 number. The implementation converts this to an appropriate signalling sequence. ... 5 E.165 number. The implementation converts this to an appropriate signalling sequence. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Oct 8 13:19:07 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id NAA20603; Wed, 8 Oct 1997 13:16:54 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 8 Oct 1997 13:16:16 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id NAA20566 for ietf-ppp-outgoing; Wed, 8 Oct 1997 13:16:15 -0400 (EDT) Received: from ns.frigate.com (ns.frigate.com [209.81.17.6]) by merit.edu (8.8.7/8.8.5) with ESMTP id NAA20562 for ; Wed, 8 Oct 1997 13:16:10 -0400 (EDT) Received: from localhost (mthorn@localhost) by ns.frigate.com (8.8.5/8.7.1) with SMTP id KAA29020; Wed, 8 Oct 1997 10:15:26 -0700 (PDT) Date: Wed, 8 Oct 1997 10:15:26 -0700 (PDT) From: Mike Thornburg To: Michael Liwerant cc: "'ietf_ppp'" Subject: Re: Chap Challenge Name In-Reply-To: <343BB180@smtp-gateway.rad.co.il> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu On Wed, 8 Oct 1997, Michael Liwerant wrote: > > We are using Chap authentication protocol whose parameters are configured > by the user ONLY according to the relevant Managed Object (RFC 1472). > > Our question is what NAME should be used by the Authenticator when > sending the Challenge message ? > > We are considering the following options: > > 1) If we should use the NAME which is configured in the Local-to-Remote > field (of the relevant entry in the pppSecuritySecretsTable) then it > means that the user must configure a valid Local-to-Remote entry even if > there is NO intention to use the router as a "peer". > If all the entries in the Authenticator's pppSecuritySecretsTable are Remote-to-Local, then I believe you should use the hostname of the Authenticator as the NAME in the challenge. Even if there are Local-to-Remote entries in the pppSecuritySecretsTable I think you still want to use the hostname as the NAME in the challenge message. RFC 1472 specifies that local-to-remote means "the local PPP entity will use the ID/Secret pair when attempting to authenticate the local PPP entity to the remote PPP entity." ie, this entry is to be used in forming the proper response to a Challenge, not in forming a Challenge (which is part of the remote authenticating itself to the local). Consider the problem of a link such as a phone line that accepts incoming connections from any one of several sites but does not provide you with the phone number of the calling party. When you construct the Challenge you may not know which site has called you, so that even if you have a special NAME configured in a Local-to-Remote entry that you are supposed to use with that site when you authenticate yourself to it, you have no way of picking out that particular entry from the other Local-to-Remote entries in the table. > 2) Is there any significance at all to the NAME sent in the challenge > transmission (by the Authenticator) ? why not just send an empty NAME > field (single zero or a dummy value) ? after all the peer will use ITS > Local-to-Remote name when sending the response... > Some systems use the NAME sent in the challenge as a key into a table of shared secrets in order to determine which shared secret to use to answer the challenge. As in, "I just got a challenge from marty. Let's see what secret I share with marty." so the NAME must be meaningful to the system that will receive the challenge. Thanks, Mike -------------- Mike Thornburg frigate networks 650.903.2266 mthorn@frigate.com http://www.frigate.com/ - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Oct 8 13:35:41 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id NAA21019; Wed, 8 Oct 1997 13:34:19 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 8 Oct 1997 13:33:59 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id NAA20995 for ietf-ppp-outgoing; Wed, 8 Oct 1997 13:33:59 -0400 (EDT) Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.8.7/8.8.5) with SMTP id NAA20991 for ; Wed, 8 Oct 1997 13:33:50 -0400 (EDT) Received: from mica.denver.sgi.com (mica.denver.sgi.com [169.238.67.6]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id KAA23089 for <@sgi.engr.sgi.com:ietf-ppp@merit.edu>; Wed, 8 Oct 1997 10:33:48 -0700 env-from (vjs@mica.denver.sgi.com) Received: (from vjs@localhost) by mica.denver.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA23360 for ietf-ppp@merit.edu; Wed, 8 Oct 1997 11:33:41 -0600 Date: Wed, 8 Oct 1997 11:33:41 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199710081733.LAA23360@mica.denver.sgi.com> To: ietf-ppp@merit.edu Subject: Re: ACCM Sender: owner-ietf-ppp@merit.edu > From: Patrick Klos > ... > >As you say, the words are about the transmit ACCM. We all agree (I > >think) that about which <> ACCM to use and when. However, we > >are talking about the <> ACCM. You do use two completely > >different and largely independent ACCMs in your code, don't you? > > Not during LCP negotiations, we don't! Then you will lose data and report perfectly good packets as having bad FCS. > >How do you know when you are receiving a packet whether it is an LCP > >packet? > > You don't know if the packet you're receiving is LCP, but that doesn't make > it alright to send an LCP packet that doesn't conform to the standard! You two keep talking about transmitting LCP packets with something other than ACCM=0xffffffff. Why? No one else is talking about that. Are you sure you have two ACCM's? > >What if you have been receiving data packets for a long time, > >and the peer is just now deciding to re-negotiate LCP? > > A properly formatted LCP packet will ALWAYS be receivable regardless of > your current Receive ACCM. That is true, but irrelevant. How is the peer supposed to switch its TX ACCM to 0xffffffff half an RTT before you switch your receive ACCM so that when your LCP state machine leaves Opened and you switch to a receive ACCM of 0xffffffff, you do not lose packets? > >Or have you not > >fixed your implementation to allow LCP to be renegotiated, and so have > >not needed to confront that issue? > > Apparently, you have never used our PPP implementation. We have supported > LCP renegotiation from day 1! That's news to me, since I thought the Klos implementation was among the systems that failed to answer unexpected LCP Configure-Requests. However, I must obviously take your word for it. > (you see, when software is designed properly, > it runs well on ANY platform) That is nonsense, unless you restrict "ANY platform" ridiculously, to a PC, a super computer or close to any other design point. Things that makes sense when you are running a single PPP pipe on a single CPU with limited or no thread scheduling are silly elsewhere in the spectrum. For example, there are plenty of currently shipping, medium cost (not to mention expensive) multi-CPU systems where the worst case inter-CPU communication time is a lot of microseconds. > >What happens when your code decides to renegotiated LCP? Of course you > >change the transmit ACCM, but when do you start applying a receive ACCM > >of 0xffffffff? > > At any time that LCP is NOT in the Opened state, the transmit and receive > ACCMs are 0xffffffff. The standard encourages that, if it doesn't > explicitly state that! So none of the PPP RFC's explicitly state that you "MUST" lose data? We are making progress! If you decide to renegotiate LCP, and if the link is active, then you will probably lose the next packet. Maybe that won't matter if you are religous about discarding all non-LCP packets when LCP is not in Opened. Still, you will be reporting bogus FCS errors and failing to log whatever the packet was. > ... > Yes. So there will be times when the possibility exists that ACCMs are not > updated exactly when they need to be. That's the nature of the beast. > If you're really worried about the async bytes having problems, I'm sure > you could come up with a clean way to process the bytes at a time when > all appropriate options have been processed. (come on, Vern, use your > imagination) > ... The trouble is that if the receive ACCM is wrong, you will lose data. If you always set the receive ACCM to 0xffffffff, then you must necessarily sometimes set it to what you know is the wrong value. Thus, if you always set the receive ACCM to 0xffffffff, then you must necessarily sometimes lose data. Here is another case when you will lose data. Say the fourth LCP packet, the LCP Config-Ack from the peer arrives with a bad FCS, but would have finished negotating all ACCMs=0. The peer will have switched its transmit ACCM to 0. You will be receiving packets (typically IPCP or authentication) with receive ACCM=0xffffffff. Consequently, you will lose them as having bad FCS. Yes, in this case, your LCP state machine won't care because you should discard the packets as being not in the Network Phase. However, good systems try hard to log the right errors, and your system will be reporting bogus FCS errors. Can't bogus FCS errors have bad effects if you do anything based on LQM reports? > ... > >Can you think of any good reasons in such an implementation to not to > >use a single thread of control for everything? I think I can. > > Why do you keep talking about this obviously poor design? Is this > how your PPP is done? Do you know of an implementation that does it > this way?? I don't! I know of more than one vendor's implementaiton that does not use a single thread for all of a single PPP bundle. As far as I know, none run on DOS, NT, Win3, or Win95, although I think some do run on commodity PC hardware. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Oct 8 15:05:46 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id PAA23583; Wed, 8 Oct 1997 15:03:01 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 8 Oct 1997 15:02:29 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id PAA23558 for ietf-ppp-outgoing; Wed, 8 Oct 1997 15:02:28 -0400 (EDT) Received: from linux.klos.com (klos@klos.com [192.80.49.1]) by merit.edu (8.8.7/8.8.5) with SMTP id PAA23554 for ; Wed, 8 Oct 1997 15:02:20 -0400 (EDT) Received: (from klos@localhost) by linux.klos.com (8.6.12/8.6.9) id PAA14594; Wed, 8 Oct 1997 15:06:07 -0400 Date: Wed, 8 Oct 1997 15:06:07 -0400 From: Patrick Klos Message-Id: <199710081906.PAA14594@linux.klos.com> To: ietf-ppp@merit.edu, vjs@mica.denver.sgi.com Subject: Re: ACCM Sender: owner-ietf-ppp@merit.edu >> >As you say, the words are about the transmit ACCM. We all agree (I >> >think) that about which <> ACCM to use and when. However, we >> >are talking about the <> ACCM. You do use two completely >> >different and largely independent ACCMs in your code, don't you? >> >> Not during LCP negotiations, we don't! > >Then you will lose data and report perfectly good packets as having >bad FCS. What are we going to lose? I still haven't seen it. Are we going to lose some of the non-LCP packets that the peer had in it's queue when we sent the new LCP packet? If so, we can discard them since we no longer have LCP in the Opened state (so by definition must discard all non-LCP packets). Given that we don't care about non-LCP packets at this point, we won't have problems with properly escaped LCP packets, so we won't lose them. What do we lose? >> >How do you know when you are receiving a packet whether it is an LCP >> >packet? >> >> You don't know if the packet you're receiving is LCP, but that doesn't make >> it alright to send an LCP packet that doesn't conform to the standard! > >You two keep talking about transmitting LCP packets with something >other than ACCM=0xffffffff. Why? No one else is talking about that. >Are you sure you have two ACCM's? By saying that you want to modify your receive ACCM prior to LCP being Opened, you are assuming that your peer (the other side) is transmitting an LCP packet without all control characters escaped. That's the "transmit" I'm talking about - the other side of the link. That peer is the one that isn't conforming to the standard. >> >What if you have been receiving data packets for a long time, >> >and the peer is just now deciding to re-negotiate LCP? >> >> A properly formatted LCP packet will ALWAYS be receivable regardless of >> your current Receive ACCM. > >That is true, but irrelevant. Irrelevant?!? That's exactly the case in point! Otherwise you wouldn't have to worry about the changing your receive ACCM before LCP negotiations are completed. >How is the peer supposed to switch its TX ACCM to 0xffffffff half an >RTT before you switch your receive ACCM so that when your LCP state >machine leaves Opened and you switch to a receive ACCM of 0xffffffff, >you do not lose packets? You still haven't told me what packets I could lose here. (see above) >> >Or have you not >> >fixed your implementation to allow LCP to be renegotiated, and so have >> >not needed to confront that issue? >> >> Apparently, you have never used our PPP implementation. We have supported >> LCP renegotiation from day 1! > >That's news to me, since I thought the Klos implementation was among >the systems that failed to answer unexpected LCP Configure-Requests. >However, I must obviously take your word for it. You thought? Well stop thinking, you might hurt yourself! I don't know where you get your information from, but most people collect up some of the facts before making such degrading remarks! >> >What happens when your code decides to renegotiated LCP? Of course you >> >change the transmit ACCM, but when do you start applying a receive ACCM >> >of 0xffffffff? >> >> At any time that LCP is NOT in the Opened state, the transmit and receive >> ACCMs are 0xffffffff. The standard encourages that, if it doesn't >> explicitly state that! > >So none of the PPP RFC's explicitly state that you "MUST" lose data? >We are making progress! What are you talking about? You're losing us. >If you decide to renegotiate LCP, and if the link is active, then you >will probably lose the next packet. Maybe that won't matter if you >are religous about discarding all non-LCP packets when LCP is not >in Opened. Still, you will be reporting bogus FCS errors and failing >to log whatever the packet was. Now you're beginning to understand. There is absolutely NOTHING WRONG with an implementation that does what the standard says: discard all non-LCP packets when LCP is not Opened. Plain english - easy concept - I'm sure you'll catch on. (and nothing prevents you from logging the data from the packet that had the bad FCS) >The trouble is that if the receive ACCM is wrong, you will lose data. Here we go again. What data? If LCP is not Opened, it's alright to lose non-LCP packets. How often is this gonna happen?? >If you always set the receive ACCM to 0xffffffff, then you must >necessarily sometimes set it to what you know is the wrong value. >Thus, if you always set the receive ACCM to 0xffffffff, then you >must necessarily sometimes lose data. Gibberish! >Here is another case when you will lose data. Say the fourth LCP >packet, the LCP Config-Ack from the peer arrives with a bad FCS, but >would have finished negotating all ACCMs=0. The peer will have >switched its transmit ACCM to 0. If my peer sent me a (final) Configure-Ack, but it had bad FCS and I discarded it, I don't care about the following IPCP or authentication packet since my LCP is not Opened yet. That's the definition of PPP. I'd have thought you figured this part out by now? >You will be receiving packets >(typically IPCP or authentication) with receive ACCM=0xffffffff. >Consequently, you will lose them as having bad FCS. Yes, in this case, >your LCP state machine won't care because you should discard the >packets as being not in the Network Phase. However, good systems try >hard to log the right errors, and your system will be reporting bogus >FCS errors. Oh, excuse me for not building a "good system"! >Can't bogus FCS errors have bad effects if you do anything based on >LQM reports? I guess it all depends on how often you go through this exercise? "Good systems" don't need to go through this very often! ;^) >I know of more than one vendor's implementaiton that does not use a >single thread for all of a single PPP bundle. As far as I know, none >run on DOS, NT, Win3, or Win95, although I think some do run on >commodity PC hardware. So you admit you know nothing about the implementations that do run on DOS, NT, Win3 or Win95? So stop speculating about something you don't know about! ============================================================================ Patrick Klos Email: klos@klos.com Klos Technologies, Inc. Voice: (603) 424-8300 604 Daniel Webster Highway FAX: (603) 424-9300 Merrimack, New Hampshire 03054 Web: http://www.klos.com/ ============================================================================ - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Oct 8 15:50:44 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id PAA24776; Wed, 8 Oct 1997 15:49:20 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 8 Oct 1997 15:48:53 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id PAA24745 for ietf-ppp-outgoing; Wed, 8 Oct 1997 15:48:53 -0400 (EDT) Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.8.7/8.8.5) with SMTP id PAA24738 for ; Wed, 8 Oct 1997 15:48:46 -0400 (EDT) Received: from mica.denver.sgi.com (mica.denver.sgi.com [169.238.67.6]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id MAA21730 for <@sgi.engr.sgi.com:ietf-ppp@merit.edu>; Wed, 8 Oct 1997 12:48:44 -0700 env-from (vjs@mica.denver.sgi.com) Received: (from vjs@localhost) by mica.denver.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA23778 for ietf-ppp@merit.edu; Wed, 8 Oct 1997 13:48:37 -0600 Date: Wed, 8 Oct 1997 13:48:37 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199710081948.NAA23778@mica.denver.sgi.com> To: ietf-ppp@merit.edu Subject: Re: ACCM Sender: owner-ietf-ppp@merit.edu > From: Barney Wolff > > The receive ACCM is an unavoidable, unfixable mess. > > I'm sure I'm just dense, but I don't see what the problem is, in the > real world, even when one side starts to renegotiate LCP after a long > happy period of exchanging IP with ACCM not ffffffff. The peer > receiving that LCP frame, unless it does really fancy lookahead, will > not realize it's LCP until it's already processed the control field, > which should be escaped. But a conformant peer will always escape > the control field, and that works no matter what the other side uses > as its receive ACCM. That is all true, but only about LCP packets. It says nothing about non-LCP packets. At both the entrance and the exit from the LCP Openned state are races between the peer changing its transmit ACCM from 0xffffffff to something smaller and your system changing its received ACCM from 0xffffffff to the same value. The races are made worse by transmission delays between the peers. If your system uses a smaller receive ACCM (but still prudent--0xffffffff until the peer says otherwise), nothing bad will happen. If your system waits as some advise, then you will trash good packets. > If there is something in the path that inserts control chars, the ACCM > that was negotiated the first time had better have reflected that, or > communication would not have been established. So using the old non- > default receive ACCM won't hurt, because it was correct for the path. > > The only way I can see that *when* you switch the receive ACCM could > matter is if the nature of the path changes, and that's why the other > side is renegotiating LCP. Can anybody point to a realistic scenario > where this happens? If you do as some suggest, and always make your receive ACCM the maximum possible value whenever you set your transmit ACCM to the value required by the standard, then you will sometimes lose packets. If you do as I suggest, and use the smallest prudent receive ACCM (0xffffffff until you know what the peer likes), then you will not lose packets, but if the path ever does change to insert control characters, and if the peer is broken and uses an invalid LCP transmit ACCM, then you will lose LCP packets. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Oct 8 16:42:02 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id QAA26113; Wed, 8 Oct 1997 16:39:17 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 8 Oct 1997 16:37:28 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id QAA26057 for ietf-ppp-outgoing; Wed, 8 Oct 1997 16:37:27 -0400 (EDT) Received: from relay1.smtp.psi.net (relay1.smtp.psi.net [38.8.14.2]) by merit.edu (8.8.7/8.8.5) with ESMTP id QAA26053 for ; Wed, 8 Oct 1997 16:37:23 -0400 (EDT) Received: from wacko.aptis.com by relay1.smtp.psi.net (8.8.5/SMI-5.4-PSI) id QAA15799; Wed, 8 Oct 1997 16:37:21 -0400 (EDT) Received: by wacko.aptis.com with Internet Mail Service (5.0.1457.3) id <4M632JJB>; Wed, 8 Oct 1997 16:38:57 -0400 Message-ID: From: Marty Del Vecchio To: ietf-ppp@merit.edu Subject: RE: ACCM Date: Wed, 8 Oct 1997 16:38:55 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Everyone, can we please limit these personal attacks and insults to private mail? Reading this mailing list is beginning to turn my stomach. Thanks. > -----Original Message----- > From: Patrick Klos [SMTP:klos@klos.com] > Sent: Wednesday, October 08, 1997 3:06 PM > To: ietf-ppp@merit.edu; vjs@mica.denver.sgi.com > Subject: Re: ACCM > > >> >As you say, the words are about the transmit ACCM. We all agree > (I > >> >think) that about which <> ACCM to use and when. > However, we > >> >are talking about the <> ACCM. You do use two completely > >> >different and largely independent ACCMs in your code, don't you? > >> > >> Not during LCP negotiations, we don't! > > > >Then you will lose data and report perfectly good packets as having > >bad FCS. > > What are we going to lose? I still haven't seen it. Are we going to > lose > some of the non-LCP packets that the peer had in it's queue when we > sent the new LCP packet? If so, we can discard them since we no > longer have LCP in the Opened state (so by definition must discard > all non-LCP packets). Given that we don't care about non-LCP packets > at this point, we won't have problems with properly escaped LCP > packets, > so we won't lose them. What do we lose? > > >> >How do you know when you are receiving a packet whether it is an > LCP > >> >packet? > >> > >> You don't know if the packet you're receiving is LCP, but that > doesn't make > >> it alright to send an LCP packet that doesn't conform to the > standard! > > > >You two keep talking about transmitting LCP packets with something > >other than ACCM=0xffffffff. Why? No one else is talking about that. > >Are you sure you have two ACCM's? > > By saying that you want to modify your receive ACCM prior to LCP being > Opened, you are assuming that your peer (the other side) is > transmitting > an LCP packet without all control characters escaped. That's the > "transmit" I'm talking about - the other side of the link. That peer > is the one that isn't conforming to the standard. > > >> >What if you have been receiving data packets for a long time, > >> >and the peer is just now deciding to re-negotiate LCP? > >> > >> A properly formatted LCP packet will ALWAYS be receivable > regardless of > >> your current Receive ACCM. > > > >That is true, but irrelevant. > > Irrelevant?!? That's exactly the case in point! Otherwise you > wouldn't > have to worry about the changing your receive ACCM before LCP > negotiations > are completed. > > >How is the peer supposed to switch its TX ACCM to 0xffffffff half an > >RTT before you switch your receive ACCM so that when your LCP state > >machine leaves Opened and you switch to a receive ACCM of 0xffffffff, > >you do not lose packets? > > You still haven't told me what packets I could lose here. (see above) > > >> >Or have you not > >> >fixed your implementation to allow LCP to be renegotiated, and so > have > >> >not needed to confront that issue? > >> > >> Apparently, you have never used our PPP implementation. We have > supported > >> LCP renegotiation from day 1! > > > >That's news to me, since I thought the Klos implementation was among > >the systems that failed to answer unexpected LCP Configure-Requests. > >However, I must obviously take your word for it. > > You thought? Well stop thinking, you might hurt yourself! I don't > know > where you get your information from, but most people collect up some > of > the facts before making such degrading remarks! > > >> >What happens when your code decides to renegotiated LCP? Of > course you > >> >change the transmit ACCM, but when do you start applying a receive > ACCM > >> >of 0xffffffff? > >> > >> At any time that LCP is NOT in the Opened state, the transmit and > receive > >> ACCMs are 0xffffffff. The standard encourages that, if it doesn't > >> explicitly state that! > > > >So none of the PPP RFC's explicitly state that you "MUST" lose data? > >We are making progress! > > What are you talking about? You're losing us. > > >If you decide to renegotiate LCP, and if the link is active, then you > >will probably lose the next packet. Maybe that won't matter if you > >are religous about discarding all non-LCP packets when LCP is not > >in Opened. Still, you will be reporting bogus FCS errors and failing > >to log whatever the packet was. > > Now you're beginning to understand. There is absolutely NOTHING WRONG > with an implementation that does what the standard says: discard all > non-LCP packets when LCP is not Opened. Plain english - easy concept > - > I'm sure you'll catch on. (and nothing prevents you from logging the > data from the packet that had the bad FCS) > > >The trouble is that if the receive ACCM is wrong, you will lose data. > > Here we go again. What data? If LCP is not Opened, it's alright to > lose > non-LCP packets. How often is this gonna happen?? > > >If you always set the receive ACCM to 0xffffffff, then you must > >necessarily sometimes set it to what you know is the wrong value. > >Thus, if you always set the receive ACCM to 0xffffffff, then you > >must necessarily sometimes lose data. > > Gibberish! > > >Here is another case when you will lose data. Say the fourth LCP > >packet, the LCP Config-Ack from the peer arrives with a bad FCS, but > >would have finished negotating all ACCMs=0. The peer will have > >switched its transmit ACCM to 0. > > If my peer sent me a (final) Configure-Ack, but it had bad FCS and I > discarded it, I don't care about the following IPCP or authentication > packet since my LCP is not Opened yet. That's the definition of PPP. > I'd have thought you figured this part out by now? > > >You will be receiving packets > >(typically IPCP or authentication) with receive ACCM=0xffffffff. > >Consequently, you will lose them as having bad FCS. Yes, in this > case, > >your LCP state machine won't care because you should discard the > >packets as being not in the Network Phase. However, good systems try > >hard to log the right errors, and your system will be reporting bogus > >FCS errors. > > Oh, excuse me for not building a "good system"! > > >Can't bogus FCS errors have bad effects if you do anything based on > >LQM reports? > > I guess it all depends on how often you go through this exercise? > "Good > systems" don't need to go through this very often! ;^) > > >I know of more than one vendor's implementaiton that does not use a > >single thread for all of a single PPP bundle. As far as I know, none > >run on DOS, NT, Win3, or Win95, although I think some do run on > >commodity PC hardware. > > So you admit you know nothing about the implementations that do run on > DOS, NT, Win3 or Win95? So stop speculating about something you don't > know about! > ====================================================================== > ====== > Patrick Klos Email: klos@klos.com > Klos Technologies, Inc. Voice: (603) 424-8300 > 604 Daniel Webster Highway FAX: (603) 424-9300 > Merrimack, New Hampshire 03054 Web: http://www.klos.com/ > ====================================================================== > ====== - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Oct 8 16:49:43 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id QAA26361; Wed, 8 Oct 1997 16:47:01 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 8 Oct 1997 16:44:52 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id QAA26260 for ietf-ppp-outgoing; Wed, 8 Oct 1997 16:44:51 -0400 (EDT) Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.8.7/8.8.5) with SMTP id QAA26247 for ; Wed, 8 Oct 1997 16:44:45 -0400 (EDT) Received: from mica.denver.sgi.com (mica.denver.sgi.com [169.238.67.6]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id NAA19769 for <@sgi.engr.sgi.com:ietf-ppp@merit.edu>; Wed, 8 Oct 1997 13:44:35 -0700 env-from (vjs@mica.denver.sgi.com) Received: (from vjs@localhost) by mica.denver.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA24061 for ietf-ppp@merit.edu; Wed, 8 Oct 1997 14:44:28 -0600 Date: Wed, 8 Oct 1997 14:44:28 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199710082044.OAA24061@mica.denver.sgi.com> To: ietf-ppp@merit.edu Subject: Re: ACCM Sender: owner-ietf-ppp@merit.edu > From: Patrick Klos > ... > >Then you will lose data and report perfectly good packets as having > >bad FCS. > > What are we going to lose? I still haven't seen it. Are we going to lose > some of the non-LCP packets that the peer had in it's queue when we > sent the new LCP packet? If so, we can discard them since we no > longer have LCP in the Opened state (so by definition must discard > all non-LCP packets). Given that we don't care about non-LCP packets > at this point, we won't have problems with properly escaped LCP packets, > so we won't lose them. What do we lose? If your system always switches its receive ACCM to 0xffffffff whenever it is about send an LCP Config-Request, then how do you avoid counting perfectly valid packets from the peer as having bad FCS's? Yes, you would discard most such packets, but don't you think it is better to count them as received-out-of-Network-Phase instead of as bad-FCS? Don't you think it is easier to understand packet traces if you record all packets, and correctly log what your system thought of them? I don't remember and haven't checked, but are LCP Identification, Echo-Request, Echo-Response, and Time-Remaining always sent with ACCM=0xffffffff? I think some of them are sent with the prevailing transmit ACCM, and should be at least logged if received while LCP is not in Opened. If you always switch your receive ACCM to 0xffffffff, then you will lose those packets, or at least fail to log them correctly. > ... > By saying that you want to modify your receive ACCM prior to LCP being > Opened, you are assuming that your peer (the other side) is transmitting > an LCP packet without all control characters escaped. ... No, I am assuming no such thing. I am assuming that the peer might change its transmit ACCM and start sending packets without all control characters escaped before I can get around to deal with the ACCM. There is race between one peer setting its transmit ACCM and the other peer setting its receive ACCM. That race cannot be fixed, if only because of the transmission delay between the peers. All you can do pick a least harmful policy to deal with the race. > ... > >> A properly formatted LCP packet will ALWAYS be receivable regardless of > >> your current Receive ACCM. > > > >That is true, but irrelevant. > > Irrelevant?!? That's exactly the case in point! Otherwise you wouldn't > have to worry about the changing your receive ACCM before LCP negotiations > are completed. You are making the incorrect assumption that both peers simultaneously complete LCP negotiations. Just as in relativistic physics, the mere notion of two events being simultaneous is in general nonsense. (In PPP, transmission delays correspond to the speed of light.) > >How is the peer supposed to switch its TX ACCM to 0xffffffff half an > >RTT before you switch your receive ACCM so that when your LCP state > >machine leaves Opened and you switch to a receive ACCM of 0xffffffff, > >you do not lose packets? > > You still haven't told me what packets I could lose here. (see above) Won't you lose any non-LCP or LCP above type 7 packets sent by the peer when its LCP statement is in Opened but yours is not? > ... > >That's news to me, since I thought the Klos implementation was among > >the systems that failed to answer unexpected LCP Configure-Requests. > >However, I must obviously take your word for it. > > You thought? Well stop thinking, you might hurt yourself! I don't know > where you get your information from, but most people collect up some of > the facts before making such degrading remarks! Degrading? Is it not the case that many PC implementations do not handle unexpected LCP Configure-Requests? I would have said that you guys had said in this mailing list that your system didn't renegotiate, but I was evidently wrong. You two would get more respect if you did not habitually use what I've called Michigan Rhetoric, in honor of one of your neighbors. > ... > >If you decide to renegotiate LCP, and if the link is active, then you > >will probably lose the next packet. Maybe that won't matter if you > >are religous about discarding all non-LCP packets when LCP is not > >in Opened. Still, you will be reporting bogus FCS errors and failing > >to log whatever the packet was. > > Now you're beginning to understand. There is absolutely NOTHING WRONG > with an implementation that does what the standard says: discard all > non-LCP packets when LCP is not Opened. Plain english - easy concept - > I'm sure you'll catch on. (and nothing prevents you from logging the > data from the packet that had the bad FCS) What if it is one of the LCP packets that many implementors prefer to log correctly, such as an Identification packet? Trashing the packet by using the wrong ACCM (i.e. not what the peer used) means you do not log such packets correctly. > >The trouble is that if the receive ACCM is wrong, you will lose data. > > Here we go again. What data? If LCP is not Opened, it's alright to lose > non-LCP packets. How often is this gonna happen?? If your code sees many bad FCS's, do you tell people to check hardware? Maybe check that the modem is configured to use hardware flow control? Don't you think that practically any bad FCS's on a modem line using V.42 indicates that something on one peer or the other is broken? Doesn't your code count and report bad FCS as something signifcant and bad? > ... > >Here is another case when you will lose data. Say the fourth LCP > >packet, the LCP Config-Ack from the peer arrives with a bad FCS, but > >would have finished negotating all ACCMs=0. The peer will have > >switched its transmit ACCM to 0. > > If my peer sent me a (final) Configure-Ack, but it had bad FCS and I > discarded it, I don't care about the following IPCP or authentication > packet since my LCP is not Opened yet. That's the definition of PPP. > I'd have thought you figured this part out by now? What if the packet after the bad Ack is one you should have logged correctly? Part of the Michican Rhetoric involves insults intended to make the opponent yield the point by default. I think it is a poor tactic. > ... > >Can't bogus FCS errors have bad effects if you do anything based on > >LQM reports? > > I guess it all depends on how often you go through this exercise? "Good > systems" don't need to go through this very often! ;^) > > >I know of more than one vendor's implementaiton that does not use a > >single thread for all of a single PPP bundle. As far as I know, none > >run on DOS, NT, Win3, or Win95, although I think some do run on > >commodity PC hardware. > > So you admit you know nothing about the implementations that do run on > DOS, NT, Win3 or Win95? So stop speculating about something you don't > know about! I did not admit that. However, a little speculating can be good. It broadens the mind and reduces provincialism. By the way, please ask your associate to keep his flames public. ] From: Michael Klos ] ... ] Vern, why don't you just grow up. The standard is a standard. It is ] not going to be changed for you whether you like your implementation ] better or not. If you wish to be non-compliant, fine. But grow up ] and realize that this discussion should have occured YEARS ago and ] is not relevant now. ] ] It's too bad with all of you high and mighty performance that you ] can't simply program to meet the standards. ] ] Even a fool looks wise if he keeps his mouth shut. It would help ] your cause a lot if you shut yours (figuratively). Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Oct 8 17:16:25 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id RAA27071; Wed, 8 Oct 1997 17:15:01 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 8 Oct 1997 17:14:44 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id RAA27047 for ietf-ppp-outgoing; Wed, 8 Oct 1997 17:14:43 -0400 (EDT) Received: from gvmail.globalvillage.com ([198.93.137.253]) by merit.edu (8.8.7/8.8.5) with SMTP id RAA27033 for ; Wed, 8 Oct 1997 17:14:32 -0400 (EDT) Received: from sleet.globalvillage.com [198.93.138.50] by gvmail.globalvillage.com (SMTPD32-4.02) id A7AD10860094; Wed, 08 Oct 1997 14:14:21 PDT Received: from ianp by sleet.globalvillage.com (SMI-8.6/SMI-SVR4) id OAA20577; Wed, 8 Oct 1997 14:13:00 -0700 From: "Ian Puleston" To: Subject: Re: PPP over ATM LCP option restrictions Date: Wed, 8 Oct 1997 14:14:45 -0700 Message-ID: <01bcd42f$33af2900$46bf8acf@ianp.globalvillage.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.0103.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.0103.0 Sender: owner-ietf-ppp@merit.edu This subject seems to have dried up with no real concensus reached. I am currently trying to do an implementation which will be directly affected, and so need a resolution to the problem. My view is: 1. ACFC is no big issue. The peer is indicating his ability to receive compressed frames, not asking for compressed frames to be sent. Therefore there is no reason to reject the option. 2. FCS alternatives are more difficult to deal with since a converter would need the hardware to deal with 32-bit FCS. However, since the designer of the converter has no control over the PPP stacks at the end-points, and both ends may be non-ATM implementations with converters, the converter must be designed to work with FCS alternatives if they are negotiated on. How will such a converter work if new types of FCS are added to the standard in future ? That's an implementation problem for its designer. Therefore, can I suggest that the wording in the RFC be changed from: An implementation MUST NOT request any of the following options, and MUST reject a request for such an option: Field Check Sequence (FCS) Alternatives, Address-and-Control-Field-Compression (ACFC), to something like: Field Check Sequence (FCS) Alternatives, and Address-and-Control-Field-Compression (ACFC) are not applicable in the case of PPP over AAL5 (since the framing format is pre-defined by the ATM standards). However, an implementation should allow for the case where the ATM network may not be end-to-end, and the remote peer may be connected over a medium where RFC-1662 HDLC-like framing is used. In that case these options may be desirable for optimal performance, and hence an implementation MAY request and accept these LCP options, if it so chooses. Implementation note: A converter between ATM and a link running RFC-1662 MUST have knowledge of PPP framing, and be capable of working when ACFC and FCS alternatives are negotiated for use on the latter. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Oct 8 18:01:07 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id RAA28103; Wed, 8 Oct 1997 17:57:49 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 8 Oct 1997 17:57:00 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id RAA28070 for ietf-ppp-outgoing; Wed, 8 Oct 1997 17:56:59 -0400 (EDT) Received: from usr.com (mailgate.usr.com [149.112.20.2]) by merit.edu (8.8.7/8.8.5) with ESMTP id RAA28040 for ; Wed, 8 Oct 1997 17:56:41 -0400 (EDT) From: smaurya@usr.com Received: from robogate2.usr.com by usr.com (8.7.5/3.1.090690-US Robotics) id QAA06318; Wed, 8 Oct 1997 16:43:00 -0500 (CDT) Received: from ccMail by robogate2.usr.com (IMA Internet Exchange 2.02 Enterprise) id 43BFF770; Wed, 8 Oct 97 16:47:35 -0500 Mime-Version: 1.0 Date: Wed, 8 Oct 1997 16:17:46 -0500 Message-ID: <43BFF770.3000@usr.com> To: "'ietf-ppp@merit.edu'" , Gurdeep Singh Pall Subject: win95 and ACCM Content-Type: multipart/mixed; boundary="IMA.Boundary.452743678" Sender: owner-ietf-ppp@merit.edu --IMA.Boundary.452743678 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part I have hardware flow control on my dialup-networking. Dialup-networking sends me an ACCM of 00 0A 00 00. Modem send ACCM of 00 00 00 00 to dial-up networking. Then win95 escapes following bytes in data packets(non-LCP packets). 0x13, 0x11, 0x93, and 0x91. Any ideas why win95 is doing this. Actually win95 should not escape any byte. Well I can understand 0x13 and 0x11 byte. But why 0x93 and 0x91? -Sanjiv --IMA.Boundary.452743678 Content-Type: text/plain; charset=US-ASCII; name="RFC822 message headers" Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Content-Disposition: attachment; filename="RFC822 message headers" Received: from usr.com (mailgate.usr.com) by robogate2.usr.com with SMTP (IMA Internet Exchange 2.02 Enterprise) id 43AA61A0; Tue, 7 Oct 97 16:14:02 -0500 Received: from merit.edu by usr.com (8.7.5/3.1.090690-US Robotics) id PAA12199; Tue, 7 Oct 1997 15:49:46 -0500 (CDT) Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id QAA01319; Tue, 7 Oct 1997 16:59:23 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 7 Oct 1997 16:58:42 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id QAA01290 for ietf-ppp-outgoing; Tue, 7 Oct 1997 16:58:41 -0400 (EDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.23]) by merit.edu (8.8.7/8.8.5) with ESMTP id QAA01286 for ; Tue, 7 Oct 1997 16:58:37 -0400 (EDT) Received: by mail3.microsoft.com with Internet Mail Service (5.0.1459.27) id <4L01KSFF>; Tue, 7 Oct 1997 13:59:37 -0700 Message-ID: From: Gurdeep Singh Pall To: "'jmartz@us.ibm.com'" , "'ietf-ppp@merit.edu'" Subject: ACCM Date: Tue, 7 Oct 1997 13:58:34 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1459.27) Sender: owner-ietf-ppp@merit.edu --IMA.Boundary.452743678-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Oct 8 21:00:19 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id UAA01499; Wed, 8 Oct 1997 20:58:58 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 8 Oct 1997 20:58:48 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id UAA01475 for ietf-ppp-outgoing; Wed, 8 Oct 1997 20:58:47 -0400 (EDT) Received: from linux.klos.com (klos@klos.com [192.80.49.1]) by merit.edu (8.8.7/8.8.5) with SMTP id UAA01469 for ; Wed, 8 Oct 1997 20:58:41 -0400 (EDT) Received: (from klos@localhost) by linux.klos.com (8.6.12/8.6.9) id VAA16200; Wed, 8 Oct 1997 21:03:11 -0400 Date: Wed, 8 Oct 1997 21:03:11 -0400 From: Patrick Klos Message-Id: <199710090103.VAA16200@linux.klos.com> To: ietf-ppp@merit.edu, vjs@mica.denver.sgi.com Subject: Re: ACCM Sender: owner-ietf-ppp@merit.edu >If your system always switches its receive ACCM to 0xffffffff whenever >it is about send an LCP Config-Request, then how do you avoid counting >perfectly valid packets from the peer as having bad FCS's? Forget it Vern, you're making such a stink over something that happens less than one-tenth of one percent of the time! It's useless to try to discuss it with you (and certainly not worth the bandwidth we've wasted on this list!). I'm dropping the issue. >By the way, please ask your associate to keep his flames public. Why should he keep his flames public?!? And didn't anyone tell you it's not good manners to post something publicly that you received privately (unless you ask permission first)?? Maybe he wanted to keep his comment private so as to reduce your embarassment?? Besides, this mailing list is not here for flaming; it's here for debating technical issues relating to PPP. Oh, and I don't control my associate. You'll have to deal with him yourself! >] Even a fool looks wise if he keeps his mouth shut. It's true what he says about fools. ============================================================================ Patrick Klos Email: klos@klos.com Klos Technologies, Inc. Voice: (603) 424-8300 604 Daniel Webster Highway FAX: (603) 424-9300 Merrimack, New Hampshire 03054 Web: http://www.klos.com/ ============================================================================ - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Oct 8 20:45:08 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id UAA01097; Wed, 8 Oct 1997 20:43:27 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 8 Oct 1997 20:42:38 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id UAA01076 for ietf-ppp-outgoing; Wed, 8 Oct 1997 20:42:38 -0400 (EDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.29]) by merit.edu (8.8.7/8.8.5) with ESMTP id UAA01071 for ; Wed, 8 Oct 1997 20:42:34 -0400 (EDT) Received: by mail4.microsoft.com with Internet Mail Service (5.5.1664.3) id <4PAF5BKY>; Wed, 8 Oct 1997 17:44:15 -0700 Message-ID: From: Gurdeep Singh Pall To: "'smaurya@usr.com'" , "'ietf-ppp@merit.edu'" Subject: RE: win95 and ACCM Date: Wed, 8 Oct 1997 17:42:27 -0700 X-Mailer: Internet Mail Service (5.5.1664.3) Sender: owner-ietf-ppp@merit.edu Please discuss this offline with bjohnson@microsoft.com. thx > -----Original Message----- > From: smaurya@usr.com [SMTP:smaurya@usr.com] > Sent: Wednesday, October 08, 1997 2:18 PM > To: 'ietf-ppp@merit.edu'; Gurdeep Singh Pall > Subject: win95 and ACCM > > > > I have hardware flow control on my dialup-networking. > Dialup-networking sends me > an ACCM of 00 0A 00 00. > Modem send ACCM of 00 00 00 00 to dial-up networking. > > Then win95 escapes following bytes in data packets(non-LCP packets). > 0x13, 0x11, 0x93, and 0x91. > > Any ideas why win95 is doing this. > > Actually win95 should not escape any byte. Well I can understand 0x13 > and 0x11 > byte. But why 0x93 and 0x91? > > -Sanjiv << File: cc:Mail note part >> - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Oct 8 21:23:19 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id VAA01899; Wed, 8 Oct 1997 21:21:48 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 8 Oct 1997 21:21:07 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id VAA01868 for ietf-ppp-outgoing; Wed, 8 Oct 1997 21:21:06 -0400 (EDT) Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.8.7/8.8.5) with SMTP id VAA01864 for ; Wed, 8 Oct 1997 21:21:01 -0400 (EDT) Received: from mica.denver.sgi.com (mica.denver.sgi.com [169.238.67.6]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id SAA12007 for <@sgi.engr.sgi.com:ietf-ppp@Merit.edu>; Wed, 8 Oct 1997 18:20:58 -0700 env-from (vjs@mica.denver.sgi.com) Received: (from vjs@localhost) by mica.denver.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA24987 for ietf-ppp@Merit.edu; Wed, 8 Oct 1997 19:20:52 -0600 Date: Wed, 8 Oct 1997 19:20:52 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199710090120.TAA24987@mica.denver.sgi.com> To: ietf-ppp@merit.edu Subject: Terminate-request etc. Sender: owner-ietf-ppp@merit.edu ] From: Patrick Klos ] .. ] Which is my point exactly. The people on the list are willing to allow ] him that control. If the people on the list were concerned about it, ] they'd formally ask for the change, or someone else could make the ] change themselves and submit it. Is Bill Simpson the only RFC editor ] around? In point of fact, Mr. Simpson is not in control of the PPP standard nor is he currently the RFC Editor for the IETF PPP working group. The announcement of that change in office was made some time ago, I think by the previous chair. Mr. Simpson does have considerable legitimate influence, and is certainly entitled to voice his opinion, even if most or all of the rest of us dissagree with it. > From: "William Allen Simpson" > ... > However, in this case, the RFC is at "Full Standard". And it must not > change, which could cause interoperability problems for folks that > followed the Standard. If you want a new protocol, write one, just > don't call it PPP. That is false. Of course we can change the protocol, whether Full Standard or not. Of course we should not change it lightly. Of course it is best if any changes are upward compatible. > Nor is the dislike "irrational". The carefully written text on > Terminate arises from interoperability testing between Cisco and Telebit > and a few others in '90 and '91. We made things work.... That is very nice. Howver, it seems beside the point. What bad things can happen if you accept network packets after sending a Terminate-Request? To the best of my recollection, no one has ever described a real or theoretical problem with continuing to accept good data packets while waiting for the Terminate-Ack. > As I've said before, if you want a new "temporary half closing" message, > then you should write one, probably as part of BACP. But it cannot be > LCP Terminate-Request and Terminate-Ack, which already have very clear > semantics defined. That is an inaccurate description of the controversy. For one thing, no one wants a ""temporary half closing" message. For another, plenty of shipping systems are accepting valid data after sending Terminate-Requests, and without known problems. For a third, whether or not the current sememantics are clearly described is separate controversy, and largely irrelevant to what the semantics should be. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Oct 8 23:39:27 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id XAA04369; Wed, 8 Oct 1997 23:37:47 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 8 Oct 1997 23:36:12 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id XAA04326 for ietf-ppp-outgoing; Wed, 8 Oct 1997 23:36:10 -0400 (EDT) Received: from SantaClara01.pop.internex.net (santaclara01.pop.InterNex.Net [205.158.3.18]) by merit.edu (8.8.7/8.8.5) with ESMTP id XAA04320 for ; Wed, 8 Oct 1997 23:35:58 -0400 (EDT) Received: from flowpoint.com ([192.84.210.69]) by SantaClara01.pop.internex.net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-34792U7500L7500S0) with ESMTP id AAA29964; Wed, 8 Oct 1997 20:35:54 -0700 Received: from localhost (pmr@localhost) by flowpoint.com (8.8.4/8.8.4) with SMTP id UAA30814; Wed, 8 Oct 1997 20:34:30 -0700 Date: Wed, 8 Oct 1997 20:34:30 -0700 (PDT) From: Philip Rakity X-Sender: pmr@flowpnt To: Ian Puleston cc: ietf-ppp@merit.edu Subject: Re: PPP over ATM LCP option restrictions In-Reply-To: <01bcd42f$33af2900$46bf8acf@ianp.globalvillage.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Ian, If the convertor has the knowledge about the framing formats, why can;t it simply change the Reject to an AK and manage each of its "LCP Hops" independently? The restriction could then be removed on requesting the option, and the convertor has to manage the responses and change them accordingly. I will be aware of 3 weeks so I am looking forward to see what changes I have to make to both my VC and LLC multiplexed PPP implementation. regards, Philip Rakity FlowPoint On Wed, 8 Oct 1997, Ian Puleston wrote: > This subject seems to have dried up with no real concensus reached. I am > currently trying to do an implementation which will be directly affected, > and so need a resolution to the problem. My view is: > > 1. ACFC is no big issue. The peer is indicating his ability to receive > compressed frames, not asking for compressed frames to be sent. Therefore > there is no reason to reject the option. > > 2. FCS alternatives are more difficult to deal with since a converter would > need the hardware to deal with 32-bit FCS. However, since the designer of > the converter has no control over the PPP stacks at the end-points, and both > ends may be non-ATM implementations with converters, the converter must be > designed to work with FCS alternatives if they are negotiated on. > > How will such a converter work if new types of FCS are added to the standard > in future ? That's an implementation problem for its designer. > > Therefore, can I suggest that the wording in the RFC be changed from: > > An implementation MUST NOT request any of the following options, and MUST > reject a request for such an option: > Field Check Sequence (FCS) Alternatives, > Address-and-Control-Field-Compression (ACFC), > > to something like: > > Field Check Sequence (FCS) Alternatives, and > Address-and-Control-Field-Compression (ACFC) are not applicable in the case > of PPP over AAL5 (since the framing format is pre-defined by the ATM > standards). However, an implementation should allow for the case where the > ATM network may not be end-to-end, and the remote peer may be connected over > a medium where RFC-1662 HDLC-like framing is used. In that case these > options may be desirable for optimal performance, and hence an > implementation MAY request and accept these LCP options, if it so chooses. > > Implementation note: A converter between ATM and a link running RFC-1662 > MUST have knowledge of PPP framing, and be capable of working when ACFC and > FCS alternatives are negotiated for use on the latter. > > > > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Oct 9 01:24:53 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id BAA06030; Thu, 9 Oct 1997 01:23:26 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 9 Oct 1997 01:23:04 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id BAA06012 for ietf-ppp-outgoing; Thu, 9 Oct 1997 01:23:04 -0400 (EDT) Received: from fsnt.future.futsoft.com ([38.242.192.5]) by merit.edu (8.8.7/8.8.5) with ESMTP id BAA06008 for ; Thu, 9 Oct 1997 01:22:55 -0400 (EDT) Received: from kailash.future.futsoft.com (unverified [38.242.192.4]) by fsnt.future.futsoft.com (Integralis SMTPRS 2.04) with ESMTP id ; Thu, 09 Oct 1997 10:57:48 +0530 Received: from msgate.future.futsoft.com (msgate.future.futsoft.com [10.0.8.4]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id KAA05786 for ; Thu, 9 Oct 1997 10:25:04 +0530 Received: by msgate.future.futsoft.com with Microsoft Mail id <343D169A@msgate.future.futsoft.com>; Thu, 09 Oct 97 10:38:34 PDT From: shenoyh To: PPPMailing-List Subject: Naking BAP packets Date: Thu, 09 Oct 97 10:38:00 PDT Message-Id: <343D169A@msgate.future.futsoft.com> X-Mailer: Microsoft Mail V3.0 Sender: owner-ietf-ppp@merit.edu This is about a doubt in the PPP BAP rfc. rfc 2125 does not say much on naking BAP packets. Is the BAP Nak similar to the PPP Config-Nak ? Can we nak the BAP options like link type or phone numbers ? Should the Nak response contain only ReasonString option and should any other options received in a Nak packet be ignored or the packet discarded ? What exactly is the scenario in which a Response code of Nak can be used in a BAP response packet ? Kindly clarify. Thanks in advance, Regards, Shenoy.H & Sandeep.S Future Software Pvt. Ltd. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Oct 9 06:16:07 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id GAA08193; Thu, 9 Oct 1997 06:13:50 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 9 Oct 1997 06:05:07 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id GAA08118 for ietf-ppp-outgoing; Thu, 9 Oct 1997 06:05:06 -0400 (EDT) Received: from directors.rdl.co.uk (directors.rdl.co.uk [193.119.77.2]) by merit.edu (8.8.7/8.8.5) with ESMTP id GAA08114 for ; Thu, 9 Oct 1997 06:04:57 -0400 (EDT) Received: from imaccgw.rdl.co.uk (imaccgw.rdl.co.uk [193.240.106.205]) by directors.rdl.co.uk (8.7.3/8.7.3) with SMTP id LAA24222 for ; Thu, 9 Oct 1997 11:04:50 +0100 (BST) Received: from ccMail by imaccgw.rdl.co.uk (IMA Internet Exchange 1.04b) id 43caaa40; Thu, 9 Oct 97 10:57:56 +0100 Mime-Version: 1.0 Date: Thu, 9 Oct 1997 10:51:53 +0100 Message-ID: <43caaa40@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re: Undocumented implementation options To: ietf-ppp@merit.edu Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: owner-ietf-ppp@merit.edu William Allen Simpson writes: > The requirement is neither undocumented, nor a permitted option. True, the requirement isn't undocumented, but it IS permitted. From RFC 2125 (page 7) ] 5.1. Link Management ] ] ... ] ] After an LCP Terminate-Request is sent an implementation SHOULD stop ] transmitting data packets on that link, but still continue to receive ] and process data packets normally until receipt of a Terminate-Ack ] from the peer. (Mind you, that's not the way I'd have put it; better would be: After an LCP Terminate-Request is sent an implementation MUST stop transmitting data packets on that link, but SHOULD still continue to receive and process data packets normally until receipt of a Terminate-Ack from the peer. The receiver of an LCP Terminate-Request MUST stop transmitting packets before issuing the Terminate-Ack. This procedure will ensure that no data is lost in either direction. but I digress.) > ... > However, in this case, the RFC is at "Full Standard". And it must > not change, which could cause interoperability problems for folks > that followed the Standard. But there shouldn't be a problem changing a standard if the change doesn't cause any interoperability problems for compliant implementations. And implementations which continue to process received data packets after sending the Terminate Request and before receiving the Terminate Ack are completely interoperable with those which follow the letter of RFC 1661 (as has been proved many times). > Nor is the dislike "irrational". Ok then. What other term would be more appropriate for a complete disregard of the facts? > The carefully written text on Terminate arises from interoperability > testing between Cisco and Telebit and a few others in '90 and '91. We > made things work.... Sure, but making things work one way doesn't prove that they don't also work another.... Bill, as you've said to me - this is an implementors list. Clearly, you've never implemented this feature, and, according to your own reasoning, this would seem to disqualify you from having a valid opinion upon it. --- Jonathan Goodchild - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Oct 9 08:35:58 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id IAA09539; Thu, 9 Oct 1997 08:34:25 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 9 Oct 1997 08:34:10 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id IAA09515 for ietf-ppp-outgoing; Thu, 9 Oct 1997 08:34:09 -0400 (EDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm012-09.dialip.mich.net [141.211.7.177]) by merit.edu (8.8.7/8.8.5) with SMTP id IAA09511 for ; Thu, 9 Oct 1997 08:34:04 -0400 (EDT) Date: Thu, 9 Oct 97 01:59:43 GMT From: "William Allen Simpson" Message-ID: <6648.wsimpson@greendragon.com> To: ietf-ppp@merit.edu Subject: PPP in X.25/F-R/ATM LCP option restrictions Sender: owner-ietf-ppp@merit.edu > From: Dennis Ferguson >... I think both specifications > could be made consistent with the above while accomplishing the purpose > apparently served by not allowing ACFC to be negotiated by instead > specifying that the negotiation of ACFC does not effect the AAL5/frame > relay framing, but otherwise leaving the handling of ACFC up to the > implementation and its configuration. >... > I think the constraint in the draft (and in 1973) is needless. > I just had a 2 hour long talk with Dennis on this, and we fairly well covered our difference in philosophy. It centers around the concept of allowing frame modifying options WHEN SPECIALLY CONFIGURED. - I am opposed to adding configuration, which confuses users, and am willing to always have a somewhat reduced thruput that will always work. - He desires the ability to add knobs to tweak performance when all the equipment in between is known and understood, although it might fail when equipment is changed later. My interpretation (and I'm sure he'll correct me) is this comes from his earlier background. Telcos frequently require large amounts of configuration. They just add more training. Witness ISDN. I now see how this configuration _could_ be optionally added to PPP in X.25, F-R, and ATM. It would default off, will be backward compatible, and thus have no effect on advancing to Draft Standard. The default would continue to be to never negotiate ("not send" and "always reject") ACFC, and Alternative-FCS, and SDP, and Compound-Frames, and any future such options. By prior configuration, the implementation could C-Ack these options, even though they have no effect on the actual framing. This would allow tweaks to get better performance out of converter boxen. The converter would sniff the LCP packets, and note that the option had been Ack'd. There is still the problem where a pair of converters back to back (or a previously tweaked combination) could pass LCP framing options that they do not understand. Then, traffic will fail after LCP completes. It appears to be solvable only by having the converter sniff the LCP packets, and send a C-Reject for any option that it does not understand, refusing to pass the C-Request. Since it is already sniffing the LCP packets, this should not be a problem. And then there is the issue that he wants F-R in octet-sync mode over SONET (as he mentioned below), which is not yet addressed anywhere. It works, and I know that NetStar nee Ascend is doing this, too. Clear as mud? I'll try writing up a revision to RFC-1973 (since he is more concerned about F-R than X.25) over the weekend, so that we have some concrete text to discuss. If we can come to agreement, the same kind of text could be added to X.25 and ATM, although it may vary in subtle detail. > > It would be of great assistance should those writers indicate that they > > are actually implementing a PPP/AAL5 to something "converter", or merely > > hand-waving. > > I have one. It receives bit-synchronous HDLC from T1-rate interfaces > and reframes them onto an ATM interface (it will also support a frame > relay over SONET interface as an alternatve to the ATM, but this isn't > done yet). See, talking with actual implementors is far more convincing than mere speculation.... Thanks again, Dennis! WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Oct 9 10:47:18 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id KAA12341; Thu, 9 Oct 1997 10:45:46 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 9 Oct 1997 10:44:34 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA12297 for ietf-ppp-outgoing; Thu, 9 Oct 1997 10:44:33 -0400 (EDT) Received: from relay1.smtp.psi.net (relay1.smtp.psi.net [38.8.14.2]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA12291 for ; Thu, 9 Oct 1997 10:44:25 -0400 (EDT) Received: from wacko.aptis.com by relay1.smtp.psi.net (8.8.5/SMI-5.4-PSI) id KAA26072; Thu, 9 Oct 1997 10:44:04 -0400 (EDT) Received: by wacko.aptis.com with Internet Mail Service (5.0.1457.3) id <4M632JTQ>; Thu, 9 Oct 1997 10:45:39 -0400 Message-ID: From: Marty Del Vecchio To: "'ietf-ppp@merit.edu'" Subject: RE: win95 and ACCM Date: Thu, 9 Oct 1997 10:45:37 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Sender: owner-ietf-ppp@merit.edu >>Sanjiv wrote: I have hardware flow control on my dialup-networking. Dialup-networking sends me an ACCM of 00 0A 00 00. Modem send ACCM of 00 00 00 00 to dial-up networking. Then win95 escapes following bytes in data packets(non-LCP packets). 0x13, 0x11, 0x93, and 0x91. Any ideas why win95 is doing this. Actually win95 should not escape any byte. Well I can understand 0x13 and 0x11 byte. But why 0x93 and 0x91? ==== Win95 is being smart here. It's escaping XON and XOFF, just in case its local modem is configured for software flow control. It is doing this despite the null ACCM you sent it, because you can't possibly know what its modem is configured for. The 0x93 and 0x91 are XON and XOFF with the high bit set. I ran into some modems in the early days that would strip the high bit off, then check for XON/XOFF. They did this even though the port was configured for 8 bits no parity. The only way to work around this was to escape the high-bit versions of XON and XOFF also. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Oct 9 11:21:48 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id LAA13210; Thu, 9 Oct 1997 11:20:24 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 9 Oct 1997 11:19:45 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id LAA13174 for ietf-ppp-outgoing; Thu, 9 Oct 1997 11:19:44 -0400 (EDT) Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.8.7/8.8.5) with SMTP id LAA13168 for ; Thu, 9 Oct 1997 11:19:40 -0400 (EDT) Received: from mica.denver.sgi.com (mica.denver.sgi.com [169.238.67.6]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id IAA28177 for <@sgi.engr.sgi.com:ietf-ppp@merit.edu>; Thu, 9 Oct 1997 08:19:37 -0700 env-from (vjs@mica.denver.sgi.com) Received: (from vjs@localhost) by mica.denver.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA26516 for ietf-ppp@merit.edu; Thu, 9 Oct 1997 09:19:31 -0600 Date: Thu, 9 Oct 1997 09:19:31 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199710091519.JAA26516@mica.denver.sgi.com> To: ietf-ppp@merit.edu Subject: Re: ACCM Sender: owner-ietf-ppp@merit.edu > From: Patrick Klos > > >If your system always switches its receive ACCM to 0xffffffff whenever > >it is about send an LCP Config-Request, then how do you avoid counting > >perfectly valid packets from the peer as having bad FCS's? > > Forget it Vern, you're making such a stink over something that happens > less than one-tenth of one percent of the time! It's useless to try > to discuss it with you (and certainly not worth the bandwidth we've > wasted on this list!). I'm dropping the issue. At the start, it was said that I'm totally wrong and violating the standards. Then it was agreed by at least some that the standards don't say explicitly when you should switch receive ACCMs. Now it is a modest quality-of-implementation issue. With the caveat that I've seen the syndrome significantly more often that 0.1%, I think we now agree on the primary technical issue. > >By the way, please ask your associate to keep his flames public. > > Why should he keep his flames public?!? And didn't anyone tell you > it's not good manners to post something publicly that you received > privately (unless you ask permission first)?? Maybe he wanted to > keep his comment private so as to reduce your embarassment?? Please tell what I can do to get people at klos.com to stop sending me abusive email. I have refrained from publishing the most recent message that I received this morning. If not to you, do I need to complaint to MCI or mainstream.net to get your associate to stop? Or some other authority? I do try to keep email private. However, like many other people, I consider email intended to insult or harass not shielded by that polite convention. I understand too well being embarrassed by my own words, but I cannot imagine being embarrassed by anything you or the other Mr. Klos might say. (Of course, libel or slander would be something else, and not strictly embarrassment.) As for why I would rather receive flames in public, I reserve private communications for those with whom I share a minimal mutual regard and trust. If insults can't stand public scrutiny, then what are they? At best, I doubt don't see how they can be effective. At worst, ... It is possible that what I consider insults and abuse (such as the previous sample) are only normal communication in your part of the world, and would not be what your courts call "fighting words." Even so, it would be best (and appreciated by me) for klos.com to stop sending me private love letters. > Besides, > this mailing list is not here for flaming; it's here for debating > technical issues relating to PPP. > > Oh, and I don't control my associate. You'll have to deal with him > yourself! > > >] Even a fool looks wise if he keeps his mouth shut. > > It's true what he says about fools. Please explain to this fool the "technical issue relating to PPP" which you are debating. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Oct 9 15:47:49 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id PAA19334; Thu, 9 Oct 1997 15:46:12 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 9 Oct 1997 15:45:10 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id PAA19287 for ietf-ppp-outgoing; Thu, 9 Oct 1997 15:45:10 -0400 (EDT) Received: from coppermountain.com (bromo.coppermountain.com [206.71.190.2]) by merit.edu (8.8.7/8.8.5) with ESMTP id PAA19283 for ; Thu, 9 Oct 1997 15:45:03 -0400 (EDT) Received: by coppermountain.com from localhost (router,SLMail V2.5); Thu, 09 Oct 1997 12:43:08 -0800 Received: by coppermountain.com from eric (206.71.190.13::mail daemon; unverified,SLMail V2.5); Thu, 09 Oct 1997 12:43:07 -0800 Message-Id: <2.2.32.19971009194600.002feec4@coppermountain.com> X-Sender: "Eric Michelsen" X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 09 Oct 1997 12:46:00 -0700 To: ietf-ppp@merit.edu From: "Eric L. Michelsen" Subject: Re: on rejecting LCP ACFC but not ACCM Sender: owner-ietf-ppp@merit.edu At 09:49 AM 10/6/97 GMT, William Allen Simpson wrote: >> From: "Eric L. Michelsen" ... >> Essentially, LCP allows negotiation of options which are specific to some >> underlying framing layers. ACCM, ACFC, FCS are all examples of this. They >> should all be handled consistently, and as documented for ACCM in RFC 1662. >> If an implementation has no use for a parameter, then accept it, and let >> other conversion boxes that may exist deal with the consequences. Anybody >> doing conversion is responsible for making sure their end(s) negotiate >> appropriately. I should have been more clear in my intent. I was *proposing* that we make new standards as above. I didn't mean to say that the above paragraph was my interpretation of existing standards. Now that I think about it, I'd rather have the standard say that implementations can accept or reject non-applicable framing options as they choose. But the key issue is that the burden of compatibility (IMHO) belongs with the converter boxes. Maybe they sniff LCP, and do the right thing. Or auto-detect framing, and do the right thing. Or have control over one or both PPP endpoints to force negotations the way they want, and do the right thing. -- Eric L. Michelsen, Copper Mountain Networks, Inc. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Oct 10 02:47:44 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id CAA26656; Fri, 10 Oct 1997 02:46:03 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 10 Oct 1997 02:45:36 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id CAA26638 for ietf-ppp-outgoing; Fri, 10 Oct 1997 02:45:34 -0400 (EDT) Received: from djwhome.demon.co.uk (root@djwhome.demon.co.uk [158.152.19.5]) by merit.edu (8.8.7/8.8.5) with ESMTP id CAA26634 for ; Fri, 10 Oct 1997 02:45:25 -0400 (EDT) Received: (from david@localhost) by djwhome.demon.co.uk (8.8.6/8.7.3) id IAA29989; Thu, 9 Oct 1997 08:03:39 +0100 From: David Woolley Message-Id: <199710090703.IAA29989@djwhome.demon.co.uk> Subject: Re: Chap Challenge Name To: MichaelL@RND.RNDMAIL.rad.co.il (Michael Liwerant) Date: Thu, 9 Oct 1997 08:03:34 +0100 (BST) Cc: ietf-ppp@merit.edu In-Reply-To: <343BB180@smtp-gateway.rad.co.il> from "Michael Liwerant" at Oct 8, 97 06:12:00 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu > > 1) If we should use the NAME which is configured in the Local-to-Remote > field (of the relevant entry in the pppSecuritySecretsTable) then it > means that the user must configure a valid Local-to-Remote entry even if > there is NO intention to use the router as a "peer". PPP is a peer protocol, not a master to slave protocol, in spite of the fact that one major market player implements it assymetrically. Good security practice requires that authentication should be done in both directions, and you should trust the "server" as little as the it trusts the "client". Note that a full implementation assumes that a link can be compromised after call setup and repeatedly re-challenges (I've had to deliberately disable this feature when talking to Microsoft implementations). > > 2) Is there any significance at all to the NAME sent in the challenge > transmission (by the Authenticator) ? why not just send an empty NAME > field (single zero or a dummy value) ? after all the peer will use ITS > Local-to-Remote name when sending the response... The secret can be a function of both names. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Oct 10 10:40:29 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id KAA00713; Fri, 10 Oct 1997 10:38:07 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 10 Oct 1997 10:31:53 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA00608 for ietf-ppp-outgoing; Fri, 10 Oct 1997 10:31:52 -0400 (EDT) Received: from ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA00604 for ; Fri, 10 Oct 1997 10:31:48 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id KAA05547; Fri, 10 Oct 1997 10:31:38 -0400 (EDT) Message-Id: <199710101431.KAA05547@ietf.org> To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: The IESG SUBJECT: Last Call: Mobile-IPv4 Configuration Option for PPP IPCP to Proposed Standard Reply-to: iesg@ietf.org Date: Fri, 10 Oct 1997 10:31:38 -0400 Sender: owner-ietf-ppp@merit.edu The IESG has received a request from the Point-to-Point Protocol Extensions Working Group to consider Mobile-IPv4 Configuration Option for PPP IPCP as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by October 23, 1997. Files can be obtained via ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-ipcp-mip-02.txt - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Oct 10 14:42:31 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id OAA04966; Fri, 10 Oct 1997 14:41:07 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 10 Oct 1997 14:37:39 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA04872 for ietf-ppp-outgoing; Fri, 10 Oct 1997 14:37:38 -0400 (EDT) Received: from carmina.web.compuserve.com (carmina.web.compuserve.com [149.174.70.9]) by merit.edu (8.8.7/8.8.5) with SMTP id OAA04866 for ; Fri, 10 Oct 1997 14:37:34 -0400 (EDT) Received: by carmina.web.compuserve.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <01BCD589.EE0593B0@carmina.web.compuserve.com>; Fri, 10 Oct 1997 14:36:44 -0400 Message-ID: From: Mark Beadles To: "'l2tp@zendo.com'" , "'ietf-ppp'" Subject: RE: cross LNS MP Date: Fri, 10 Oct 1997 14:36:37 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu From: Paul Raison [SMTP:raison@xylogics.com] >If a customer wants to use multiple tunnel endpoints in their site, then >there is a possibility that different links of an MP bundle could terminate >on different LNSs (actually, the links could originate on different RACs >as well). This is especially true if that customer is going to load >balance across the multiple LNSs. > >Before going to RFC, do we need to identify a solution for bundling MP links >that are tunneled to different LNS's ? Speaking as a service provider who has a strong need for any LNS deployed to support multi-chassis multilink: Obviously it appears that this is beyond the scope of L2TP proper. It is also true _to some extent_ that this can be handled by each vendor in their own way, so that interoperability between LNS's is indeed not required. However: interoperability with other parts of the network IS required. This includes LAC's, RADIUS servers/proxies/clients, network management & monitoring tools. In any real network, these will come from a variety of vendors. So it becomes useful indeed to have a common interface, if not protocol, for using multi-chassis multilink in a real network. Situations like the present one, where some vendors require new RADIUS attributes, some vendors do everything by conspiracy among the LNS's, some vendors do it some other way, and where everyone has a slightly different idea about what load balancing really is, cause some serious headaches for folks integrating networks. Short version: We would be very interested in a standard method for doing multi-chassis multilink. (Cross-posted to the main ietf-ppp list) + Mark Anthony Beadles CompuServe Network Product Engineering + + 5000 Britton, Hilliard OH 43026 Voice (614)723-1941 + + mbeadles@web.compuserve.com http://www.compuserve.net/ + - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Oct 10 19:23:37 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id TAA08965; Fri, 10 Oct 1997 19:22:07 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 10 Oct 1997 19:20:22 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id TAA08943 for ietf-ppp-outgoing; Fri, 10 Oct 1997 19:20:21 -0400 (EDT) Received: from img.outgoing.com ([204.137.220.51]) by merit.edu (8.8.7/8.8.5) with ESMTP id TAA08905 for ; Fri, 10 Oct 1997 19:16:24 -0400 (EDT) Message-Id: <199710102316.TAA08905@merit.edu> Date: Fri, 10 Oct 1997 19:17:07 -0400 (EDT) X-1: Visit http://www.iemmc.org for name removal information. From: Did-It@img.outgoing.com To: ietf-ppp@merit.edu Subject: Are You Listed? Sender: owner-ietf-ppp@merit.edu Site traffic is so critically important, and as the web contact for your domains, we wondered if you could forward this to the person in charge of site marketing and traffic building. As a webmaster or webmarketer, you know that getting traffic from the search engines and directories is absolutely crucial to the success of your (or your client's) site. You have probably heard of submission services, and some of them area really great service .... but, as you may be aware, the search engines don't always process the submissions, and they also drop many sites that used to be listed out of the directories to keep the size of their database down, so you never can be sure if you have an active listing, till now. So, we have launched a new service called did-it.com at http://www.did-it.com. The did-it.com Detective will check any URL to see if the URL is listed in the search engines, as well as the RANK for a particular key word. It then e-mails you a status report FREE OF CHARGE. If you find you're not listed, you can utilize our Did-it submission and monitoring service. What is unique about this service is that it will monitor the status of your site on all the popular search engines and automatically resubmit you wherever you're not listed. Today, that's the ONLY way you can be sure you get listed and stay listed, automatically. Come take a look... http://www.did-it.com and use our detective service FREE! BTW, If you like our service you can also become a did-it.com Partner. In exchange for putting a small icon next to a link to us, you will become eligible for did-it.com Partner benefits. Check out the partner program at: http://www.did-it.com/ click on the partner icon. Thanks so much. Regards, The did-it.com team. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Oct 13 09:44:27 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id JAA03276; Mon, 13 Oct 1997 09:42:20 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 13 Oct 1997 09:38:18 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id JAA03224 for ietf-ppp-outgoing; Mon, 13 Oct 1997 09:38:17 -0400 (EDT) Received: from ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.7/8.8.5) with ESMTP id JAA03216 for ; Mon, 13 Oct 1997 09:38:13 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id JAA19212; Mon, 13 Oct 1997 09:38:08 -0400 (EDT) Message-Id: <199710131338.JAA19212@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-l2tp-mib-00.txt Date: Mon, 13 Oct 1997 09:38:07 -0400 Sender: owner-ietf-ppp@merit.edu --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : Layer Two Tunneling Protocol 'L2TP' Management Information Base Author(s) : P. Calhoun, R. Wheeler, G. Reddy, B. Vroman Filename : draft-ietf-pppext-l2tp-mib-00.txt Pages : 34 Date : 10-Oct-97 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing networks using Layer 2 Tunneling Protocol. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-l2tp-mib-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-l2tp-mib-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-l2tp-mib-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971010120330.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-l2tp-mib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-l2tp-mib-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971010120330.I-D@ietf.org> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Oct 13 09:44:32 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id JAA03278; Mon, 13 Oct 1997 09:42:20 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 13 Oct 1997 09:38:09 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id JAA03208 for ietf-ppp-outgoing; Mon, 13 Oct 1997 09:38:09 -0400 (EDT) Received: from ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.7/8.8.5) with ESMTP id JAA03204 for ; Mon, 13 Oct 1997 09:38:05 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id JAA19182; Mon, 13 Oct 1997 09:38:01 -0400 (EDT) Message-Id: <199710131338.JAA19182@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-l2tp-sec-02.txt Date: Mon, 13 Oct 1997 09:38:00 -0400 Sender: owner-ietf-ppp@merit.edu --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : Layer Two Tunneling Protocol 'L2TP' Security Extensions for Non-IP networks Author(s) : P. Calhoun, W. Townsley Filename : draft-ietf-pppext-l2tp-sec-02.txt Pages : 11 Date : 10-Oct-97 The L2TP document [1] defines the base protocol which describes the method of tunneling PPP [2] data. The L2TP document states that the security mechanism used over an IP network is to use the IETF's IPSEC protocols. L2TP was designed in such a way as to be able to run over any underlying layer (i.e. Frame Relay, ATM, etc.). This document specifies extensions to the L2TP protocol in order to provide authentication and integrity of individual packets in a tunneled session over a network where IPSEC or another suitable security protocol is not available. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-l2tp-sec-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-l2tp-sec-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-l2tp-sec-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971010114220.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-l2tp-sec-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-l2tp-sec-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971010114220.I-D@ietf.org> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Oct 14 14:14:45 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id OAA24270; Tue, 14 Oct 1997 14:11:41 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 14 Oct 1997 14:07:39 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA24171 for ietf-ppp-outgoing; Tue, 14 Oct 1997 14:07:38 -0400 (EDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm035-19.dialip.mich.net [141.211.7.30]) by merit.edu (8.8.7/8.8.5) with SMTP id OAA24163 for ; Tue, 14 Oct 1997 14:07:32 -0400 (EDT) Date: Tue, 14 Oct 97 17:49:09 GMT From: "William Allen Simpson" Message-ID: <6677.wsimpson@greendragon.com> To: ietf-ppp@merit.edu Subject: Framing Conversion Sender: owner-ietf-ppp@merit.edu I have spent far more time than I had planned, reading messages going back several years, to cover the problems introduced by framing conversion. Actually, problems with so-called "multi-media bridging" go back many years, and I wish that we had had the foresight to anticipate that the same problems would plague PPP. I have concluded that it would be better to have a new BCP updating RFC-1662, rather than adding the same text to every framing document. Here is my condensation of the findings: DRAFT PPP Framing Conversion October 1997 1. Introduction Some forms of bridging convert PPP encapsulated packets between dif- ferent framing formats. It is the responsibility of the bridge to do all stuffing and framing conversions. At one time, it was expected that such conversions would be rela- tively rare, and would only occur between asynchronous and syn- chronous links [RFC-1662]. Unfortunately, external converters have since appeared that bridge PPP from bit-synchronous HDLC to bit- synchronous X.25, bit-synchronous X.25 to bit-synchronous Frame Relay, bit-synchronous to octet-synchronous HDLC and Frame Relay, and that are daisy-chained together in sundry combinations. Also, the interpretation of "high speed" has changed over time. When the PPP specifications were originally written, high speed generally began at 57.6Kbps, and was assumed for most synchronous links. Since then, implementors have applied the [RFC-1662] low speed recommenda- tions to link speeds of up to 622Mbps, squeezing out the last small percentage of performance. This ambiguity has resulted in unantici- pated proliferation of options. Furthermore, some implementors have interpreted the term "recogniz- able" to mean that the implementation merely supports negotiation of an option, although that option has no effect on the interface. This misinterpretation has resulted in undesirable interaction of options. Moreover, the (committee designed) multi-link specification [RFC-1990] introduced many LCP options, and the bandwidth allocation protocol(s) [RFC-2025] introduced link management complexity, that are not compatible with the conversion requirements of [RFC-1662]. This specification describes the current practices necessary for avoiding the failure modes of this ensuing cacaphony of options, and numerous interoperability problems that have been identified with bridging converters. 1.1. Terminology In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [RFC-2119]. Simpson expires in six months [Page 1] DRAFT PPP Framing Conversion October 1997 2. Passive Converters A "passive" converter relies on outside PPP peers to conduct all LCP negotiation. The converter inspects any LCP Configure-Acks passing through it, and dynamically updates its configuration accordingly. For "Asynchronous to Synchronous Conversion" [RFC-1662], this tech- nique works with only a minimum of implementation effort. However, when more than one conversion is attempted, or when options might be legitimately negotiated by the PPP peers that are not recog- nized by intermediate converters, passive conversion can inexplicably fail. The link will successfully pass Link Establishment phase, but appear to be disfunctional to the user. This does not meet PPP requirements [RFC-1547]. For example, two converters might be placed back-to-back: async --- converter --- sync --- converter --- async The async implementations could negotiate LCP framing-related options (such as Address-and-Control-Field-Compression, FCS-Alternatives, or another vendor specific option), without any guarantee that the intervening converters can successfully receive the resulting modi- fied frames. Because LCP is extensible, there can be no requirement that any converter recognize and interpret all current and future options. This problem also applies to a single converter, where the "high speed" sync implementation requests "low speed" options that mimic an async implementation. But, there is no guarantee that the interven- ing converter will recognize the option and can successfully receive the resulting modified frames. Therefore, the use of passive converters is deprecated. For backward compatibility, bit-synchronous and octet-synchronous implementations SHOULD respond to the LCP Async-Control-Character-Map (ACCM) Configu- ration Option with a Configure-Ack, but MUST NOT include the ACCM in a Configure-Request. 3. Active Converters An "active" converter intercepts LCP configuration negotiation, while allowing other PPP traffic to pass unimpeded. The converter becomes the PPP LCP peer on each interface, examining all LCP Link Configura- tion packets (Configure-Request, Configure-Ack, Configure-Nak, and Configure-Reject). Simpson expires in six months [Page 2] DRAFT PPP Framing Conversion October 1997 Inappropriate or ineffectual options that arrive in LCP Configure- Requests (such as ACCM from synchronous links or ACFC from variable- framed links) indicate that another (passive) converter is present in the path. Separate LCP negotiation on each interface prevents these options from propagating incorrect configuration information. However, when explicitly configured on a per option basis, an imple- mentation MAY negotiate ineffectual options seen in a Configure-Nak, and MAY respond to such requested options with a Configure-Ack. 4. Multi-Link Conversion Framing conversion requires that each link be paired with another single link. Multi-link negotiation is not compatible with active or passive converters. Instead, all PPP multi-link capable devices MUST terminate all PPP traffic on each interface. That is, multi-link devices are consid- ered routers, and MUST conform to the requirements for routers. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Oct 15 09:55:44 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id JAA06812; Wed, 15 Oct 1997 09:53:42 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 15 Oct 1997 09:49:30 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id JAA06747 for ietf-ppp-outgoing; Wed, 15 Oct 1997 09:49:29 -0400 (EDT) Received: from ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.7/8.8.5) with ESMTP id JAA06743 for ; Wed, 15 Oct 1997 09:49:23 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id JAA27759; Wed, 15 Oct 1997 09:49:00 -0400 (EDT) Message-Id: <199710151349.JAA27759@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-eaptls-00.txt Date: Wed, 15 Oct 1997 09:48:59 -0400 Sender: owner-ietf-ppp@merit.edu --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : PPP EAP TLS Authentication Protocol Author(s) : B. Aboba, D. Simon Filename : draft-ietf-pppext-eaptls-00.txt Pages : 19 Date : 14-Oct-97 The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol (LCP), which can be used to negotiate authentication methods, as well as an Encryption Control Protocol (ECP), used to negotiate data encryption over PPP links, and a Compression Control Protocol (CCP), used to negotiate compression methods. The Extensible Authentication Protocol (EAP) is a PPP extension that provides support for additional authentication methods within PPP. Transport Level Security (TLS) provides for mutual authentication, ciphersuite negotiation and key exchange between two endpoints. This document describes how these TLS mechanisms may be used within EAP. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-eaptls-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-eaptls-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-eaptls-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971014114459.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-eaptls-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-eaptls-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971014114459.I-D@ietf.org> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Oct 15 15:47:02 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id PAA12674; Wed, 15 Oct 1997 15:45:30 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 15 Oct 1997 15:45:20 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id PAA12656 for ietf-ppp-outgoing; Wed, 15 Oct 1997 15:45:20 -0400 (EDT) Received: from atlas.xylogics.com ([132.245.33.7]) by merit.edu (8.8.7/8.8.5) with ESMTP id PAA12649 for ; Wed, 15 Oct 1997 15:45:14 -0400 (EDT) Received: from gmg.xylogics.com (gmg-pc.xylogics.com [132.245.33.214]) by atlas.xylogics.com (8.7.3/8.7.3) with SMTP id PAA29479 for ; Wed, 15 Oct 1997 15:42:38 -0400 (EDT) Message-ID: <34451C17.3FDD@baynetworks.com> Date: Wed, 15 Oct 1997 15:40:07 -0400 From: Gary Greenberg Reply-To: gmg@baynetworks.com Organization: Bay Networks - Remote Access Server Division X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: ietf-ppp@merit.edu Subject: Callback I-Draft Status References: <6677.wsimpson@greendragon.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Can anybody comment on the status of the PPP LCP CallBack Internet Draft, draft-ietf-pppext-callback-ds-01.txt? Thanks, Gary -- Gary M. Greenberg vox: (508) 916-4241 Principal Software Engineer (800) 225-3317 Bay Networks - ITBG fax: (508) 916-4782 8 Federal Street m/s: BL08-05 Billerica, MA 01821 email: gmg@baynetworks.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Oct 15 15:26:45 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id PAA12188; Wed, 15 Oct 1997 15:23:44 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 15 Oct 1997 15:23:13 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id PAA12168 for ietf-ppp-outgoing; Wed, 15 Oct 1997 15:23:13 -0400 (EDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by merit.edu (8.8.7/8.8.5) with ESMTP id PAA12164 for ; Wed, 15 Oct 1997 15:23:09 -0400 (EDT) Received: from reohub2.reo.dec.com (reohub2.reo.dec.com [16.37.21.19]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id PAA28812 for ; Wed, 15 Oct 1997 15:10:39 -0400 (EDT) Received: by reohub2.reo.dec.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.996.35) id <01BCD9A6.5B04C8D0@reohub2.reo.dec.com>; Wed, 15 Oct 1997 20:10:17 +0100 Message-ID: From: Stephen Waters To: "'ietf-ppp@merit.edu'" Subject: re : draft-ietf-pppext-l2tp-06.txt L2TP and charged ISP access Date: Wed, 15 Oct 1997 18:18:42 +0100 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.996.35 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu I have a comment on L2TP regarding its use the backward parts of the world that still have call charges for local call access to ISPs. If the remote User disconnects the ISDN call, does the LAC drop the tunnel slot? What I would like to do is : 1) Connect to ISP, set up a tunnel to central office. 2) Do some work 3) Go have a short rest - my router/TA/PC card spots I'm 'idle' and disconnects the call. 4) Come back and start working - my router see the data, sets up call to ISP.... On 4, I don't want to have to redo any manual tunnel connecting - it should happen automatically. For this to work, the LAC may need to allow me to reconnect to the same L2TP tunnel slot (Call ID). The LNS may need to reauthenticate, but I want the same LNS-offered IP address back so that any TCP sessions I had connected (e.g. telenet sessions into my Intranet) to continue working. The fact that ISPs pool IP addresses means that other tunnel software that uses TCP connections to establish the tunnel will break once the dial circuit is disconnected. Regards, Steve. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Oct 15 16:17:22 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id QAA13293; Wed, 15 Oct 1997 16:15:55 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 15 Oct 1997 16:15:37 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id QAA13271 for ietf-ppp-outgoing; Wed, 15 Oct 1997 16:15:36 -0400 (EDT) Received: from janus.3com.com (janus.3com.com [129.213.128.99]) by merit.edu (8.8.7/8.8.5) with ESMTP id QAA13267 for ; Wed, 15 Oct 1997 16:15:31 -0400 (EDT) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by janus.3com.com (8.8.2/8.8.5) with ESMTP id NAA10662 for ; Wed, 15 Oct 1997 13:15:00 -0700 (PDT) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.2/8.8.5) with ESMTP id MAA23776 for ; Wed, 15 Oct 1997 12:58:28 -0700 (PDT) Received: from phecda.nsd.3com.com (phecda.nsd.3com.com [129.213.48.6]) by chicago.nsd.3com.com (8.8.2/8.8.5) with ESMTP id NAA21035 for ; Wed, 15 Oct 1997 13:12:57 -0700 (PDT) From: Chun Ye Received: (from cye@localhost) by phecda.nsd.3com.com (8.8.2/8.8.5) id NAA11997 for ietf-ppp@merit.edu; Wed, 15 Oct 1997 13:15:09 -0700 (PDT) Message-Id: <199710152015.NAA11997@phecda.nsd.3com.com> Subject: re : draft-ietf-pppext-l2tp-06.txt L2TP and charged ISP access (fwd) To: ietf-ppp@merit.edu Date: Wed, 15 Oct 1997 13:15:09 -0700 (PDT) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Steve, Sounds like you assume the tunnel ip address is the same as the one for your session. This is not true. The tunnel ip address is the one to connect to ISP, which can be assigned dynamically. You session ip address should/can be different and it can be statically assigned by your corporate, if you don't want it to be changed. --Chun -- ------------------------------------------------------------ Chun Ye cye@3com.com phone:(408)764-5094 fax:(408)764-5002 3Com Corporation, 5400 Bayfront Plaza, Santa Clara, CA 95052 > I have a comment on L2TP regarding its use the backward parts of the > world that still have call charges for local call access to ISPs. > > If the remote User disconnects the ISDN call, does the LAC drop the > tunnel slot? > > What I would like to do is : > > 1) Connect to ISP, set up a tunnel to central office. > 2) Do some work > 3) Go have a short rest - my router/TA/PC card spots I'm 'idle' and > disconnects the call. > 4) Come back and start working - my router see the data, sets up call > to ISP.... > > On 4, I don't want to have to redo any manual tunnel connecting - it > should happen automatically. > For this to work, the LAC may need to allow me to reconnect to the > same L2TP tunnel slot > (Call ID). The LNS may need to reauthenticate, but I want the same > LNS-offered IP address back > so that any TCP sessions I had connected (e.g. telenet sessions into my > Intranet) to continue > working. > > The fact that ISPs pool IP addresses means that other tunnel software > that uses TCP connections > to establish the tunnel will break once the dial circuit is > disconnected. > > Regards, Steve. > > > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Oct 15 17:47:44 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id RAA14582; Wed, 15 Oct 1997 17:45:44 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 15 Oct 1997 17:45:31 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id RAA14559 for ietf-ppp-outgoing; Wed, 15 Oct 1997 17:45:30 -0400 (EDT) Received: from adtrn722.adtran.com ([204.199.143.33]) by merit.edu (8.8.7/8.8.5) with SMTP id RAA14549 for ; Wed, 15 Oct 1997 17:45:25 -0400 (EDT) Message-Id: <199710152145.RAA14549@merit.edu> Received: by adtrn722.adtran.com (1.37.109.4/16.2) id AA10658; Wed, 15 Oct 97 16:17:13 -0500 From: Stuart Venters Subject: PPP over Sonet ACCM applicability To: ietf-ppp@merit.edu Date: Wed, 15 Oct 97 16:17:12 CDT Mailer: Elm [revision: 70.85] Sender: owner-ietf-ppp@merit.edu Hello all, In looking at RFC 1662 and 1619 it looks like the plan for PPP over Sonet is to take the Sonet concatenated payload byte stream and do octet synchronous hdlc-like framing with it. From reading Rfc1662, this looks to me like it implys using a tx and rx ACCM just like over an async modem circuit. Is this what the spec means? It seems to me that the reason for the ACCM is to accomodate modems. Perhaps the ACCM data stream processing is a legacy requirement which we don't need for PPP over SONET? Perhaps it is early enough so that there is no equipment out there which is comitted to doing ACCM with PPP over sonet? IF the answer to the above three questions is yes THEN It seems to me that the reason to do octet synchronous framing instead of bit synchronous framing for PPP over Sonet is to make the hardware simple because of the high speeds involved. Removing the ACCM processing seems a logical step in the simple/fast direction. I propose that we do this. Comments? Stuart Venters Adtran sventers@adtran.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Oct 15 18:41:23 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id SAA15216; Wed, 15 Oct 1997 18:39:46 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 15 Oct 1997 18:39:37 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id SAA15198 for ietf-ppp-outgoing; Wed, 15 Oct 1997 18:39:37 -0400 (EDT) Received: from zippy.virtualmotion.com ([206.169.117.130]) by merit.edu (8.8.7/8.8.5) with SMTP id SAA15194 for ; Wed, 15 Oct 1997 18:39:32 -0400 (EDT) Received: by zippy.virtualmotion.com with SMTP via Internet MailBridge Version 1.06.164 id MSG10151997-153859-255.DAT; Wed, 15 Oct 1997 15:38:59 -0700 Received: by DUALITY with Microsoft Mail id <01BCD980.74BBB070@DUALITY>; Wed, 15 Oct 1997 15:38:59 -0700 Message-ID: <01BCD980.74BBB070@DUALITY> From: Clark Huang To: "'ietf-ppp@merit.edu'" Subject: PPP EAP RSA Public Key Authentication Protocol Date: Wed, 15 Oct 1997 15:38:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu This comment is regarding draft-ietf-pppext-eaprsa-04.txt. The response packet that the client sends back containing the certificate, response, challenge, and signature can potentially be well over 2000 bytes, as X.509 certificates can be up to 2048 bytes by itself. Most PPP implementations have a packet size of 1500 bytes. Does the EAP ESA Public Key protocol specify a standard to fragment the response packet? Clark Huang | clark@virtualmotion.com Virtual Motion | San Francisco - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Oct 15 18:52:39 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id SAA15336; Wed, 15 Oct 1997 18:51:07 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 15 Oct 1997 18:50:27 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id SAA15308 for ietf-ppp-outgoing; Wed, 15 Oct 1997 18:50:26 -0400 (EDT) Received: from cbgw1.lucent.com (cbgw1.lucent.com [207.24.196.51]) by merit.edu (8.8.7/8.8.5) with SMTP id SAA15304 for ; Wed, 15 Oct 1997 18:50:23 -0400 (EDT) Received: from hotair.hobl.lucent.com by cbig1.firewall.lucent.com (SMI-8.6/EMS-L sol2) id SAA21936; Wed, 15 Oct 1997 18:40:52 -0400 Received: from hotair (hotair.hobl.lucent.com) by hotair.hobl.lucent.com (4.1/EMS-L SunOS) id AA04077; Wed, 15 Oct 97 18:50:10 EDT Message-Id: <9710152250.AA04077@hotair.hobl.lucent.com> To: ietf-ppp@merit.edu Subject: ID - PPP over SONET/SDH Date: Wed, 15 Oct 1997 18:50:10 -0400 From: kris Sender: owner-ietf-ppp@merit.edu I have submitted an Internet Draft that addresses the PPP/SONET interface defined in the RFC 1619. From the Abstract: "This Internet Draft addresses the PPP/SONET interface defined in the IETF RFC 1619 and its application in public Internet backbone networks. By experimental analysis it is found that this SONET interface specification is deficient in providing payload transparency. This deficiency leads to deleterious effects in providing reliable network operations. A simple SONET payload scrambler enhancement is proposed to overcome this deficiency. This work has been brought to the ANSI T1X1.5 as an action item for the addition of the RFC 1619 mapping to T1.105 with a scrambler to be determined by T1X1. We are submitting the same proposal to IETF now with the interest to enhance RFC-1619 accordingly and achieve alignment with ANSI T1 standards. To facilitate this alignment, we have recommended that T1X1 establish a formal liaison with IETF in regard to IP/SONET interface standards and associated IP transmission standards development." Murali Krishnaswamy Lucent Technologies murali@bell-labs.com (732) 949 3611 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Oct 16 08:19:08 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id IAA22364; Thu, 16 Oct 1997 08:15:28 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 16 Oct 1997 08:11:40 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id IAA22252 for ietf-ppp-outgoing; Thu, 16 Oct 1997 08:11:39 -0400 (EDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm012-03.dialip.mich.net [141.211.7.171]) by merit.edu (8.8.7/8.8.5) with SMTP id IAA22238 for ; Thu, 16 Oct 1997 08:11:32 -0400 (EDT) Date: Thu, 16 Oct 97 11:41:25 GMT From: "William Allen Simpson" Message-ID: <6687.wsimpson@greendragon.com> To: ietf-ppp@merit.edu Subject: Re: PPP over Sonet ACCM applicability Sender: owner-ietf-ppp@merit.edu > From: Stuart Venters > In looking at RFC 1662 and 1619 it looks like the plan for PPP over Sonet is > to take the Sonet concatenated payload byte stream and do octet synchronous > hdlc-like framing with it. From reading Rfc1662, this looks to me like it > implys using a tx and rx ACCM just like over an async modem circuit. > > Is this what the spec means? > No. SONET is octet-synchronous (by definition). The default ACCM is 0 (both directions), as there is no need for mapping. Now, of course, you _could_ add a non-default ACCM, if you really want to, but none of the 3 other implementations that I am aware of has done that.... ;-) And besides, I thought Adtran finished their implementation last year? Who have you tested against? RFC-1916: 2. Physical Layer Requirements PPP treats SONET/SDH transport as octet oriented synchronous links. 3. Framing The framing for octet-synchronous links is described in "PPP in HDLC Framing" [2]. RFC-1662: 4.2. Transparency An octet stuffing procedure is used. The Control Escape octet is defined as binary 01111101 (hexadecimal 0x7d), most significant bit first. As a minimum, sending implementations MUST escape the Flag Sequence and Control Escape octets. ... Receiving implementations MUST correctly process all Control Escape sequences. 7.1. Async-Control-Character-Map (ACCM) For asynchronous links, the default receiving ACCM is 0xffffffff. The default sending ACCM is 0xffffffff, plus the Control Escape and Flag Sequence characters themselves, plus whatever other outgoing characters are flagged (by prior configuration) as likely to be intercepted. For other types of links, the default value is 0, since there is no need for mapping. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Oct 16 08:19:04 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id IAA22358; Thu, 16 Oct 1997 08:15:25 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 16 Oct 1997 08:11:42 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id IAA22261 for ietf-ppp-outgoing; Thu, 16 Oct 1997 08:11:41 -0400 (EDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm012-03.dialip.mich.net [141.211.7.171]) by merit.edu (8.8.7/8.8.5) with SMTP id IAA22240 for ; Thu, 16 Oct 1997 08:11:34 -0400 (EDT) Date: Thu, 16 Oct 97 11:54:16 GMT From: "William Allen Simpson" Message-ID: <6688.wsimpson@greendragon.com> To: ietf-ppp@merit.edu Cc: kris Cc: iesg@ietf.org Subject: Re: ID - PPP over SONET/SDH Sender: owner-ietf-ppp@merit.edu > From: kris > A simple SONET payload scrambler enhancement is proposed > to overcome this deficiency. This work has been brought to the > ANSI T1X1.5 as an action item for the addition of the RFC 1619 mapping > to T1.105 with a scrambler to be determined by T1X1. > > We are submitting the same proposal to IETF now with the interest to > enhance RFC-1619 accordingly and achieve alignment with ANSI T1 standards. > To facilitate this alignment, we have recommended that T1X1 establish a > formal liaison with IETF in regard to IP/SONET interface standards > and associated IP transmission standards development." > Gosh, we discussed scrambling 3 years ago, and learned that it didn't solve any problems. The only problem I know of is that there was an error in the Bellcore specification that allowed clocks to get out of sync at speeds less than OC-48. (The clock LOS time is badly specified.) But folks with stable clocks don't have any problems. Is there some new information that was not raised on the PPPSDH list? We have several interoperable implementations already. Why would we change the specification at this late date? And why would an IETF specification be re-specified at ANSI? WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Oct 16 09:41:21 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id JAA23619; Thu, 16 Oct 1997 09:40:00 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 16 Oct 1997 09:39:49 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id JAA23599 for ietf-ppp-outgoing; Thu, 16 Oct 1997 09:39:48 -0400 (EDT) Received: from cbgw1.lucent.com (cbgw1.lucent.com [207.24.196.51]) by merit.edu (8.8.7/8.8.5) with SMTP id JAA23595 for ; Thu, 16 Oct 1997 09:39:44 -0400 (EDT) Received: from hotair.hobl.lucent.com by cbig1.firewall.lucent.com (SMI-8.6/EMS-L sol2) id JAA06169; Thu, 16 Oct 1997 09:30:11 -0400 Received: from hotair (hotair.hobl.lucent.com) by hotair.hobl.lucent.com (4.1/EMS-L SunOS) id AA19648; Thu, 16 Oct 97 09:39:27 EDT Message-Id: <9710161339.AA19648@hotair.hobl.lucent.com> To: "William Allen Simpson" Cc: ietf-ppp@merit.edu, iesg@ietf.org Subject: Re: ID - PPP over SONET/SDH In-Reply-To: Your message of "Thu, 16 Oct 1997 11:54:16 GMT." <6689.wsimpson@greendragon.com> Date: Thu, 16 Oct 1997 09:39:26 -0400 From: kris Sender: owner-ietf-ppp@merit.edu In message <6689.wsimpson@greendragon.com>you write: >> From: kris >> A simple SONET payload scrambler enhancement is proposed >> to overcome this deficiency. This work has been brought to the >> ANSI T1X1.5 as an action item for the addition of the RFC 1619 mapping >> to T1.105 with a scrambler to be determined by T1X1. >> >> We are submitting the same proposal to IETF now with the interest to >> enhance RFC-1619 accordingly and achieve alignment with ANSI T1 standards. >> To facilitate this alignment, we have recommended that T1X1 establish a >> formal liaison with IETF in regard to IP/SONET interface standards >> and associated IP transmission standards development." >> >Gosh, we discussed scrambling 3 years ago, and learned that it didn't >solve any problems. The only problem I know of is that there was an >error in the Bellcore specification that allowed clocks to get out of >sync at speeds less than OC-48. (The clock LOS time is badly specified.) >But folks with stable clocks don't have any problems. > >Is there some new information that was not raised on the PPPSDH list? > >We have several interoperable implementations already. Why would we >change the specification at this late date? > >And why would an IETF specification be re-specified at ANSI? > >WSimpson@UMich.edu > Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 > The reason for our ID is that we verfied by experiment that a PPP over SONET/SDH implementation that merely conforms to RFC 1619 (no scrambling) severely compromises the security of the SONET/SDH layer. In fact the malicious datagrams can be transmitted from anywhere in the Internet. The user need not be directly connected to the SONET network. T1X1.5 has already specified "Payload Mapping Guidelines" and T1S1 have worked earlier on ATM cell mapping and scrambling. Hence we felt that T1X1.5 is the right forum to take up this work. We have requested them to establish a formal liasion with the IETF in this regard. You can find a copy of our Internet Draft at: ftp://redants.lucent.com/pub/ietf/draft-pppsonet-scrambler-1 Murali Krishnaswamy murali@lucent.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Oct 16 09:40:30 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id JAA23582; Thu, 16 Oct 1997 09:39:03 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 16 Oct 1997 09:38:42 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id JAA23563 for ietf-ppp-outgoing; Thu, 16 Oct 1997 09:38:41 -0400 (EDT) Received: from hursley.ibm.com (mersey.hursley.ibm.com [194.196.110.10]) by merit.edu (8.8.7/8.8.5) with SMTP id JAA23559 for ; Thu, 16 Oct 1997 09:38:37 -0400 (EDT) Received: by hursley.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA12424; Thu, 16 Oct 1997 14:38:04 +0100 Date: Thu, 16 Oct 1997 14:38:04 +0100 Message-Id: <9710161338.AA12424@hursley.ibm.com> From: "(Brian E Carpenter)" Subject: Re: ID - PPP over SONET/SDH To: wsimpson@greendragon.com (William Allen Simpson) Cc: ietf-ppp@merit.edu, kris@hotair.hobl.lucent.com, iesg@ietf.org In-Reply-To: <6690.wsimpson@greendragon.com> from "William Allen Simpson" at Oct 16, 97 11:54:16 am Reply-To: brian@hursley.ibm.com X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ietf-ppp@merit.edu ANSI being a national standards body, and the IETF being international, it is highly unlikely that you will see a formal liaison. As far as I know the international standard in this area is SDH and its owner is ITU-T. Does 1619 work over SDH and is there a scrambling issue for SDH? Brian Carpenter >- William Allen Simpson said: > > > From: kris > > A simple SONET payload scrambler enhancement is proposed > > to overcome this deficiency. This work has been brought to the > > ANSI T1X1.5 as an action item for the addition of the RFC 1619 mapping > > to T1.105 with a scrambler to be determined by T1X1. > > > > We are submitting the same proposal to IETF now with the interest to > > enhance RFC-1619 accordingly and achieve alignment with ANSI T1 standards. > > To facilitate this alignment, we have recommended that T1X1 establish a > > formal liaison with IETF in regard to IP/SONET interface standards > > and associated IP transmission standards development." > > > Gosh, we discussed scrambling 3 years ago, and learned that it didn't > solve any problems. The only problem I know of is that there was an > error in the Bellcore specification that allowed clocks to get out of > sync at speeds less than OC-48. (The clock LOS time is badly specified.) > But folks with stable clocks don't have any problems. > > Is there some new information that was not raised on the PPPSDH list? > > We have several interoperable implementations already. Why would we > change the specification at this late date? > > And why would an IETF specification be re-specified at ANSI? > > WSimpson@UMich.edu > Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Oct 16 11:31:14 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id LAA25484; Thu, 16 Oct 1997 11:29:41 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 16 Oct 1997 11:29:16 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id LAA25466 for ietf-ppp-outgoing; Thu, 16 Oct 1997 11:29:15 -0400 (EDT) Received: from coppermountain.com (tibet.coppermountain.com [206.71.190.2]) by merit.edu (8.8.7/8.8.5) with ESMTP id LAA25462 for ; Thu, 16 Oct 1997 11:29:11 -0400 (EDT) Received: by coppermountain.com from localhost (router,SLMail V2.5); Thu, 16 Oct 1997 08:27:00 -0800 Received: by coppermountain.com from eric (206.71.190.13::mail daemon; unverified,SLMail V2.5); Thu, 16 Oct 1997 08:26:59 -0800 Message-Id: <2.2.32.19971016153004.0030b82c@coppermountain.com> X-Sender: "Eric Michelsen" X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 16 Oct 1997 08:30:04 -0700 To: ietf-ppp@merit.edu From: "Eric L. Michelsen" Subject: Re: ID - PPP over SONET/SDH Sender: owner-ietf-ppp@merit.edu At 02:38 PM 10/16/97 +0100, (Brian E Carpenter) wrote: >ANSI being a national standards body, and the IETF being >international, it is highly unlikely that you will see >a formal liaison. Gee, the ADSL Forum is an international organization, and we have formal liasons to ANSI all the time. -- Eric L. Michelsen, Copper Mountain Networks, Inc. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Oct 16 11:46:57 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id LAA25781; Thu, 16 Oct 1997 11:45:35 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 16 Oct 1997 11:45:26 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id LAA25758 for ietf-ppp-outgoing; Thu, 16 Oct 1997 11:45:26 -0400 (EDT) Received: from cbgw1.lucent.com (cbgw1.lucent.com [207.24.196.51]) by merit.edu (8.8.7/8.8.5) with SMTP id LAA25744 for ; Thu, 16 Oct 1997 11:45:20 -0400 (EDT) Cc: William Allen Simpson , ietf-ppp@merit.edu, kris@hotair.hobl.lucent.com, iesg@ietf.org Received: from hotair.hobl.lucent.com by cbig1.firewall.lucent.com (SMI-8.6/EMS-L sol2) id LAA18781; Thu, 16 Oct 1997 11:35:43 -0400 Received: from lucent.com (vermont.hobl.lucent.com) by hotair.hobl.lucent.com (4.1/EMS-L SunOS) id AA26629; Thu, 16 Oct 97 11:44:57 EDT Message-Id: <344636FE.AE64A4AC@lucent.com> Date: Thu, 16 Oct 1997 11:47:11 -0400 From: James Manchester Organization: Advanced Networking Technologies & Standards X-Mailer: Mozilla 4.02 [en] (X11; I; IRIX 6.3 IP32) Mime-Version: 1.0 To: brian@hursley.ibm.com Original-Cc: William Allen Simpson , ietf-ppp@merit.edu, kris@hotair.hobl.lucent.com, iesg@ietf.org Subject: Re: ID - PPP over SONET/SDH References: <9710161338.AA12424@hursley.ibm.com> Content-Type: multipart/alternative; boundary="------------5FF2D4F8F1DB683C72A57C73" Sender: owner-ietf-ppp@merit.edu --------------5FF2D4F8F1DB683C72A57C73 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Brian, The scrambling problem is exactly the same for SDH, and ANSI T1 will be working with ITU-T to take on this issue in the context of aligning T1.105 with ITU-T Recommendation G.707. The problem with ignoring ANSI is that the IETF has a specification on SONET and SONET is the responsibility of ANSI. SONET represents a multi-billion dollar infrastructure in the US that cannot be ignored. The IETF PPP over SONET specification opens up a major security hole in the SONET public network. We have been in contact with the network operators that we believe are impacted, have demonstrated this problem to them, and have been working with them to close up the holes in their network. BTW, this has nothing to do with Bellcore Generic Requirements or clock specifications as implied by Bill Simpson (in fact, I want to make sure that everyone is clear on this - this is not a problem with SONET or SDH standards). I would appreciate specific citations to the Bellcore work that is believed to be in err if possible. I also do not know what clock LOS is? LOS in the SONET world is loss of signal and is independent of the clock. Regards, James Manchester PS - Brian, George Newsome passes on his regards. ------ James Sterling Manchester Remember the MetroBus! manchester@bell-labs.com (Brian E Carpenter) wrote: > ANSI being a national standards body, and the IETF being > international, it is highly unlikely that you will see > a formal liaison. As far as I know the international standard > in this area is SDH and its owner is ITU-T. Does 1619 work over > SDH and is there a scrambling issue for SDH? > > Brian Carpenter > > >- William Allen Simpson said: > > > > > From: kris > > > A simple SONET payload scrambler enhancement is proposed > > > to overcome this deficiency. This work has been brought to the > > > ANSI T1X1.5 as an action item for the addition of the RFC 1619 mapping > > > to T1.105 with a scrambler to be determined by T1X1. > > > > > > We are submitting the same proposal to IETF now with the interest to > > > enhance RFC-1619 accordingly and achieve alignment with ANSI T1 standards. > > > To facilitate this alignment, we have recommended that T1X1 establish a > > > formal liaison with IETF in regard to IP/SONET interface standards > > > and associated IP transmission standards development." > > > > > Gosh, we discussed scrambling 3 years ago, and learned that it didn't > > solve any problems. The only problem I know of is that there was an > > error in the Bellcore specification that allowed clocks to get out of > > sync at speeds less than OC-48. (The clock LOS time is badly specified.) > > But folks with stable clocks don't have any problems. > > > > Is there some new information that was not raised on the PPPSDH list? > > > > We have several interoperable implementations already. Why would we > > change the specification at this late date? > > > > And why would an IETF specification be re-specified at ANSI? > > > > WSimpson@UMich.edu > > Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 > > --------------5FF2D4F8F1DB683C72A57C73 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Brian,

The scrambling problem is exactly the same for SDH, and ANSI T1 will be working with ITU-T to take on this issue in the context of aligning T1.105 with ITU-T Recommendation G.707.

The problem with ignoring ANSI is that the IETF has a specification on SONET and SONET is the responsibility of ANSI.  SONET represents a multi-billion dollar infrastructure in the US that cannot be ignored.  The IETF PPP over SONET specification opens up a major security hole in the SONET public network.  We have been in contact with the network operators that we believe are impacted, have demonstrated this problem to them, and have been working with them to close up the holes in their network.

BTW, this has nothing to do with Bellcore Generic Requirements or clock specifications as implied by Bill Simpson (in fact, I want to make sure that everyone is clear on this - this is not a problem with SONET or SDH standards).  I would appreciate specific citations to the Bellcore work that is believed to be in err if possible.  I also do not know what clock LOS is?  LOS in the SONET world is loss of signal and is independent of the clock.

Regards,

James Manchester

PS - Brian, George Newsome passes on his regards.

------
James Sterling Manchester
Remember the MetroBus!
manchester@bell-labs.com
 
 

(Brian E Carpenter) wrote:

ANSI being a national standards body, and the IETF being
international, it is highly unlikely that you will see
a formal liaison. As far as I know the international standard
in this area is SDH and its owner is ITU-T. Does 1619 work over
SDH and is there a scrambling issue for SDH?

  Brian Carpenter

>- William Allen Simpson said:
>
> > From: kris <kris@hotair.hobl.lucent.com>
> > A simple SONET payload scrambler enhancement is proposed
> > to overcome this deficiency. This work has been brought to the
> > ANSI T1X1.5 as an action item for the addition of the RFC 1619 mapping
> > to T1.105 with a scrambler to be determined by T1X1.
> >
> > We are submitting the same proposal to IETF now with the interest to
> > enhance RFC-1619 accordingly and achieve alignment with ANSI T1 standards.
> > To facilitate this alignment, we have recommended that T1X1 establish a
> > formal liaison with IETF in regard to IP/SONET interface standards
> > and associated IP transmission standards development."
> >
> Gosh, we discussed scrambling 3 years ago, and learned that it didn't
> solve any problems.  The only problem I know of is that there was an
> error in the Bellcore specification that allowed clocks to get out of
> sync at speeds less than OC-48.  (The clock LOS time is badly specified.)
> But folks with stable clocks don't have any problems.
>
> Is there some new information that was not raised on the PPPSDH list?
>
> We have several interoperable implementations already.  Why would we
> change the specification at this late date?
>
> And why would an IETF specification be re-specified at ANSI?
>
> WSimpson@UMich.edu
>     Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
>


 

--------------5FF2D4F8F1DB683C72A57C73--

- - - - - - - - - - - - - - - - -

From owner-ietf-ppp@merit.edu  Thu Oct 16 12:00:32 1997
Received: from localhost (daemon@localhost)
	by merit.edu (8.8.7/8.8.5) with SMTP id LAA26026;
	Thu, 16 Oct 1997 11:59:09 -0400 (EDT)
Received: by merit.edu (bulk_mailer v1.5); Thu, 16 Oct 1997 11:59:01 -0400
Received: (from majordom@localhost)
	by merit.edu (8.8.7/8.8.5) id LAA26005
	for ietf-ppp-outgoing; Thu, 16 Oct 1997 11:59:00 -0400 (EDT)
Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10])
	by merit.edu (8.8.7/8.8.5) with ESMTP id LAA26001
	for ; Thu, 16 Oct 1997 11:58:56 -0400 (EDT)
Received: from donna.txc.com (txc.com [198.138.94.6])
	by mail.ntplx.net (8.8.7/NETPLEX) with SMTP id LAA10491;
	Thu, 16 Oct 1997 11:58:50 -0400 (EDT)
Received: from jade.txc.com.txc.com by donna.txc.com (4.1/SMI-4.1)
	id AA14282; Thu, 16 Oct 97 11:58:25 EDT
Received: from coral.txc.com.txc-taicom by jade.txc.com.txc.com (4.1/SMI-4.1)
	id AA02560; Thu, 16 Oct 97 11:58:24 EDT
Received: from coral (localhost) by coral.txc.com.txc-taicom (4.1/SMI-4.1)
	id AA02987; Thu, 16 Oct 97 11:58:02 EDT
Message-Id: <34463989.4DAA423A@txc.com>
Date: Thu, 16 Oct 1997 11:58:01 -0400
From: Subhash Roy 
X-Mailer: Mozilla 3.0 (X11; I; SunOS 4.1.3_U1 sun4m)
Mime-Version: 1.0
To: kris 
Cc: ietf-ppp@merit.edu, iesg@ietf.org
Subject: Re: ID - PPP over SONET/SDH
References: <9710161339.AA19648@hotair.hobl.lucent.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-ppp@merit.edu

kris wrote:
> The reason for our ID is that we verfied by experiment that a
> PPP over SONET/SDH implementation that merely conforms to RFC 1619
> (no scrambling) severely compromises the security of the SONET/SDH layer.
> In fact the malicious datagrams can be transmitted from anywhere in
> the Internet. The user need not be directly connected to the SONET
> network.
> 
> T1X1.5 has already specified "Payload Mapping Guidelines"
> and T1S1 have worked earlier on ATM cell mapping and scrambling.
> Hence we felt that T1X1.5 is the right forum to take up this work.
> We have requested them to establish a formal liasion with the IETF
> in this regard.
> 
> You can find a copy of our Internet Draft at:
> ftp://redants.lucent.com/pub/ietf/draft-pppsonet-scrambler-1
> 
> Murali Krishnaswamy
> murali@lucent.com

Just a question why was the ATM over SONET/SDH scrambler X^43 + 1 not
proposed
for PPP over SONET/SDH?

Wouldn't this make this implementation simpler for devices
that need to support both mappings?

-- 
Subhash Roy, Principal Engineer	Phone: (203) 929-8810 x295
TranSwitch Corporation 		Fax:   (203) 926-9453
8 Progress Drive		mailto:roy@txc.com
Shelton, CT 06484
- - - - - - - - - - - - - - - - -

From owner-ietf-ppp@merit.edu  Thu Oct 16 12:17:03 1997
Received: from localhost (daemon@localhost)
	by merit.edu (8.8.7/8.8.5) with SMTP id MAA26407;
	Thu, 16 Oct 1997 12:15:42 -0400 (EDT)
Received: by merit.edu (bulk_mailer v1.5); Thu, 16 Oct 1997 12:15:25 -0400
Received: (from majordom@localhost)
	by merit.edu (8.8.7/8.8.5) id MAA26389
	for ietf-ppp-outgoing; Thu, 16 Oct 1997 12:15:24 -0400 (EDT)
Received: from hursley.ibm.com (mersey.hursley.ibm.com [194.196.110.10])
	by merit.edu (8.8.7/8.8.5) with SMTP id MAA26381
	for ; Thu, 16 Oct 1997 12:15:19 -0400 (EDT)
Received: by hursley.ibm.com (AIX 3.2/UCB 5.64/4.03)
          id AA89624; Thu, 16 Oct 1997 17:14:47 +0100
Date: Thu, 16 Oct 1997 17:14:47 +0100
Message-Id: <9710161614.AA89624@hursley.ibm.com>
From: "(Brian E Carpenter)" 
Subject: Re: ID - PPP over SONET/SDH
To: manchester@lucent.com (James Manchester)
Cc: wsimpson@greendragon.com, ietf-ppp@merit.edu, kris@hotair.hobl.lucent.com,
        iesg@ietf.org, brian@hursley.ibm.com
In-Reply-To: <344636FE.AE64A4AC@lucent.com> from "James Manchester" at Oct 16, 97 11:47:11 am
Reply-To: brian@hursley.ibm.com
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-ietf-ppp@merit.edu

James,

I didn't mean we should *ignore* T1; that would be foolish.
But we don't need a formal liaison in order to talk. 

  Brian Carpenter

>- James Manchester said:
> 
> 
> --------------5FF2D4F8F1DB683C72A57C73
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> 
> Brian,
> 
> The scrambling problem is exactly the same for SDH, and ANSI T1 will be working
> with ITU-T to take on this issue in the context of aligning T1.105 with ITU-T
> Recommendation G.707.
> 
> The problem with ignoring ANSI is that the IETF has a specification on SONET and
> SONET is the responsibility of ANSI.  SONET represents a multi-billion dollar
> infrastructure in the US that cannot be ignored.  The IETF PPP over
> SONET specification opens up a major security hole in the SONET public network.
> We have been in contact with the network operators that we believe are impacted,
> have demonstrated this problem to them, and have been working with them to close
> up the holes in their network.
> 
> BTW, this has nothing to do with Bellcore Generic Requirements or clock
> specifications as implied by Bill Simpson (in fact, I want to make sure that
> everyone is clear on this - this is not a problem with SONET or SDH standards).
> I would appreciate specific citations to the Bellcore work that is believed to be
> in err if possible.  I also do not know what clock LOS is?  LOS in the SONET
> world is loss of signal and is independent of the clock.
> 
> Regards,
> 
> James Manchester
> 
> PS - Brian, George Newsome passes on his regards.
> 
> ------
> James Sterling Manchester
> Remember the MetroBus!
> manchester@bell-labs.com
> 
> 
> 
> (Brian E Carpenter) wrote:
> 
> > ANSI being a national standards body, and the IETF being
> > international, it is highly unlikely that you will see
> > a formal liaison. As far as I know the international standard
> > in this area is SDH and its owner is ITU-T. Does 1619 work over
> > SDH and is there a scrambling issue for SDH?
> >
> >   Brian Carpenter
> >
> > >- William Allen Simpson said:
> > >
> > > > From: kris 
> > > > A simple SONET payload scrambler enhancement is proposed
> > > > to overcome this deficiency. This work has been brought to the
> > > > ANSI T1X1.5 as an action item for the addition of the RFC 1619 mapping
> > > > to T1.105 with a scrambler to be determined by T1X1.
> > > >
> > > > We are submitting the same proposal to IETF now with the interest to
> > > > enhance RFC-1619 accordingly and achieve alignment with ANSI T1 standards.
> > > > To facilitate this alignment, we have recommended that T1X1 establish a
> > > > formal liaison with IETF in regard to IP/SONET interface standards
> > > > and associated IP transmission standards development."
> > > >
> > > Gosh, we discussed scrambling 3 years ago, and learned that it didn't
> > > solve any problems.  The only problem I know of is that there was an
> > > error in the Bellcore specification that allowed clocks to get out of
> > > sync at speeds less than OC-48.  (The clock LOS time is badly specified.)
> > > But folks with stable clocks don't have any problems.
> > >
> > > Is there some new information that was not raised on the PPPSDH list?
> > >
> > > We have several interoperable implementations already.  Why would we
> > > change the specification at this late date?
> > >
> > > And why would an IETF specification be re-specified at ANSI?
> > >
> > > WSimpson@UMich.edu
> > >     Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
> > >
> 
> 
> 
> --------------5FF2D4F8F1DB683C72A57C73
> Content-Type: text/html; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> 
> 
> Brian,
> 
> 

The scrambling problem is exactly the same for SDH, and ANSI T1 > will be working with ITU-T to take on this issue in the context of aligning > T1.105 with ITU-T Recommendation G.707. > >

The problem with ignoring ANSI is that the IETF has a specification > on SONET and SONET is the responsibility of ANSI.  SONET represents > a multi-billion dollar infrastructure in the US that cannot be ignored.  > The IETF PPP over SONET specification opens up a major security > hole in the SONET public network.  We have been in contact with > the network operators that we believe are impacted, have demonstrated this > problem to them, and have been working with them to close up the holes > in their network. > >

BTW, this has nothing to do with Bellcore Generic Requirements or clock > specifications as implied by Bill Simpson (in fact, I want to make > sure that everyone is clear on this - this is not a problem with SONET > or SDH standards).  I would appreciate specific citations to > the Bellcore work that is believed to be in err if possible.  I also > do not know what clock LOS is?  LOS in the SONET world is loss > of signal and is independent of the clock. > >

Regards, > >

James Manchester > >

PS - Brian, George Newsome passes on his regards. > >

------ >
James Sterling Manchester >
Remember the MetroBus! >
manchester@bell-labs.com >
  >
  > >

(Brian E Carpenter) wrote: >

ANSI being a national standards body, and the IETF > being >
international, it is highly unlikely that you will see >
a formal liaison. As far as I know the international standard >
in this area is SDH and its owner is ITU-T. Does 1619 work over >
SDH and is there a scrambling issue for SDH? > >

  Brian Carpenter > >

>- William Allen Simpson said: >
> >
> > From: kris <kris@hotair.hobl.lucent.com> >
> > A simple SONET payload scrambler enhancement is proposed >
> > to overcome this deficiency. This work has been brought to the >
> > ANSI T1X1.5 as an action item for the addition of the RFC 1619 > mapping >
> > to T1.105 with a scrambler to be determined by T1X1. >
> > >
> > We are submitting the same proposal to IETF now with the interest > to >
> > enhance RFC-1619 accordingly and achieve alignment with ANSI T1 > standards. >
> > To facilitate this alignment, we have recommended that T1X1 establish > a >
> > formal liaison with IETF in regard to IP/SONET interface standards >
> > and associated IP transmission standards development." >
> > >
> Gosh, we discussed scrambling 3 years ago, and learned that it didn't >
> solve any problems.  The only problem I know of is that there > was an >
> error in the Bellcore specification that allowed clocks to get out > of >
> sync at speeds less than OC-48.  (The clock LOS time is badly > specified.) >
> But folks with stable clocks don't have any problems. >
> >
> Is there some new information that was not raised on the PPPSDH list? >
> >
> We have several interoperable implementations already.  Why > would we >
> change the specification at this late date? >
> >
> And why would an IETF specification be re-specified at ANSI? >
> >
> WSimpson@UMich.edu >
>     Key fingerprint =  17 40 5E 67 15 6F > 31 26  DD 0D B9 9B 6A 15 2C 32 >
>

> >

>  
> 
> --------------5FF2D4F8F1DB683C72A57C73--
> 
> 

- - - - - - - - - - - - - - - - -

From owner-ietf-ppp@merit.edu  Thu Oct 16 12:14:41 1997
Received: from localhost (daemon@localhost)
	by merit.edu (8.8.7/8.8.5) with SMTP id MAA26332;
	Thu, 16 Oct 1997 12:13:19 -0400 (EDT)
Received: by merit.edu (bulk_mailer v1.5); Thu, 16 Oct 1997 12:13:05 -0400
Received: (from majordom@localhost)
	by merit.edu (8.8.7/8.8.5) id MAA26304
	for ietf-ppp-outgoing; Thu, 16 Oct 1997 12:13:05 -0400 (EDT)
Received: from gvmail.globalvillage.com ([198.93.137.253])
	by merit.edu (8.8.7/8.8.5) with SMTP id MAA26299
	for ; Thu, 16 Oct 1997 12:13:00 -0400 (EDT)
Received: from sleet.globalvillage.com [198.93.138.50] by gvmail.globalvillage.com
  (SMTPD32-4.02c) id AD05136B0110; Thu, 16 Oct 1997 09:12:53 PDT
Received: from ianp by sleet.globalvillage.com (SMI-8.6/SMI-SVR4)
	id JAA09949; Thu, 16 Oct 1997 09:12:40 -0700
From: "Ian Puleston" 
To: , "Eric L. Michelsen" 
Subject: Re: ID - PPP over SONET/SDH
Date: Thu, 16 Oct 1997 09:12:22 -0700
Message-ID: <01bcda4e$492fb9a0$46bf8acf@ianp.globalvillage.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2002.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2002.0
Sender: owner-ietf-ppp@merit.edu

>At 02:38 PM 10/16/97 +0100, (Brian E Carpenter) wrote:
>>ANSI being a national standards body, and the IETF being
>>international, it is highly unlikely that you will see
>>a formal liaison.
>
>Gee, the ADSL Forum is an international organization, and we have formal
>liasons to ANSI all the time.
>--
>Eric L. Michelsen, Copper Mountain Networks, Inc.


If you ever try to bring a telephone, television, ISDN card, or anything
which operates on mains electricity from Europe to the USA you'll see the
results of American standards bodies not liasing with their international
counterparts !


- - - - - - - - - - - - - - - - -

From owner-ietf-ppp@merit.edu  Thu Oct 16 12:59:22 1997
Received: from localhost (daemon@localhost)
	by merit.edu (8.8.7/8.8.5) with SMTP id MAA27100;
	Thu, 16 Oct 1997 12:57:20 -0400 (EDT)
Received: by merit.edu (bulk_mailer v1.5); Thu, 16 Oct 1997 12:56:56 -0400
Received: (from majordom@localhost)
	by merit.edu (8.8.7/8.8.5) id MAA27078
	for ietf-ppp-outgoing; Thu, 16 Oct 1997 12:56:55 -0400 (EDT)
Received: from ietf.org (ietf.org [132.151.1.19])
	by merit.edu (8.8.7/8.8.5) with ESMTP id MAA27074
	for ; Thu, 16 Oct 1997 12:56:51 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.8.7/8.8.7a) with ESMTP id MAA20783;
	Thu, 16 Oct 1997 12:55:56 -0400 (EDT)
Message-Id: <199710161655.MAA20783@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce@ietf.org
Cc: ietf-ppp@merit.edu
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-pppext-eaptls-01.txt
Date: Thu, 16 Oct 1997 12:55:56 -0400
Sender: owner-ietf-ppp@merit.edu

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF.

	Title		: PPP EAP TLS Authentication Protocol
	Author(s)	: B. Aboba, D. Simon
	Filename	: draft-ietf-pppext-eaptls-01.txt
	Pages		: 19
	Date		: 15-Oct-97
	
The  Point-to-Point  Protocol  (PPP)  provides  a  standard method for
     transporting multi-protocol datagrams over point-to-point links.   PPP
     also  defines  an extensible Link Control Protocol (LCP), which can be
     used to negotiate authentication methods, as  well  as  an  Encryption
     Control  Protocol  (ECP),  used  to negotiate data encryption over PPP
     links, and a Compression Control Protocol  (CCP),  used  to  negotiate
     compression  methods.  The Extensible Authentication Protocol (EAP) is
     a PPP extension that provides support  for  additional  authentication
     methods within PPP.
 
     Transport  Level  Security  (TLS)  provides for mutual authentication,
     ciphersuite negotiation and key exchange between two endpoints.   This
     document describes how these TLS mechanisms may be used within EAP.

Internet-Drafts are available by anonymous FTP.  Login wih the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pppext-eaptls-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-eaptls-01.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	mailserv@ds.internic.net.  In the body type:
	"FILE /internet-drafts/draft-ietf-pppext-eaptls-01.txt".
	
NOTE:	The mail server at ds.internic.net can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ds.internic.net"

Content-Type: text/plain
Content-ID:	<19971015115458.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-pppext-eaptls-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pppext-eaptls-01.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19971015115458.I-D@ietf.org>

--OtherAccess--

--NextPart--


- - - - - - - - - - - - - - - - -

From owner-ietf-ppp@merit.edu  Thu Oct 16 14:12:10 1997
Received: from localhost (daemon@localhost)
	by merit.edu (8.8.7/8.8.5) with SMTP id OAA28398;
	Thu, 16 Oct 1997 14:10:45 -0400 (EDT)
Received: by merit.edu (bulk_mailer v1.5); Thu, 16 Oct 1997 14:10:21 -0400
Received: (from majordom@localhost)
	by merit.edu (8.8.7/8.8.5) id OAA28360
	for ietf-ppp-outgoing; Thu, 16 Oct 1997 14:10:20 -0400 (EDT)
Received: from cbgw1.lucent.com (cbgw1.lucent.com [207.24.196.51])
	by merit.edu (8.8.7/8.8.5) with SMTP id OAA28356
	for ; Thu, 16 Oct 1997 14:10:16 -0400 (EDT)
Received: from hotair.hobl.lucent.com by cbig1.firewall.lucent.com (SMI-8.6/EMS-L sol2)
	id OAA15003; Thu, 16 Oct 1997 14:00:34 -0400
Received: from hotair (hotair.hobl.lucent.com) by hotair.hobl.lucent.com (4.1/EMS-L SunOS)
	id AA03502; Thu, 16 Oct 97 14:09:51 EDT
Message-Id: <9710161809.AA03502@hotair.hobl.lucent.com>
To: ietf-ppp@merit.edu, iesg@ietf.org
Subject: Re: ID - PPP over SONET/SDH 
In-Reply-To: Your message of "Thu, 16 Oct 1997 17:14:47 BST."
             <9710161614.AA89624@hursley.ibm.com> 
Date: Thu, 16 Oct 1997 14:09:50 -0400
From: kris 
Sender: owner-ietf-ppp@merit.edu


I noticed that there was a typo in the Internet Draft that I submitted
to the IETF. I have resubmitted the draft to IETF. The corrected copy
can be found at: ftp://redants.lucent.com/pub/ietf/draft-pppsonet-scrambler-1.

The typo was in the bit allocation in Fig 3.
Fig 3 should be:

    .______________________________________________________.
    |SN|Predicted State|SN|Predicted State|RSVD|SN|RSVD|CRC|
    |__|_______________|__|_______________|____|__|____|___|
     2        22        2        18         4   2   2    20  Bits

    <---------------------- 9 Bytes ----------------------->



           Fig. 3    Format of Predicted State



Murali Krishnaswamy
murali@bell-labs.com
- - - - - - - - - - - - - - - - -

From owner-ietf-ppp@merit.edu  Thu Oct 16 15:09:27 1997
Received: from localhost (daemon@localhost)
	by merit.edu (8.8.7/8.8.5) with SMTP id PAA29487;
	Thu, 16 Oct 1997 15:08:00 -0400 (EDT)
Received: by merit.edu (bulk_mailer v1.5); Thu, 16 Oct 1997 15:07:37 -0400
Received: (from majordom@localhost)
	by merit.edu (8.8.7/8.8.5) id PAA29460
	for ietf-ppp-outgoing; Thu, 16 Oct 1997 15:07:37 -0400 (EDT)
Received: from adtrn722.adtran.com ([204.199.143.33])
	by merit.edu (8.8.7/8.8.5) with SMTP id PAA29456
	for ; Thu, 16 Oct 1997 15:07:32 -0400 (EDT)
Message-Id: <199710161907.PAA29456@merit.edu>
Received: by adtrn722.adtran.com
	(1.37.109.4/16.2) id AA10865; Thu, 16 Oct 97 13:39:16 -0500
From: Stuart Venters 
Subject: Re: ID - PPP over SONET/SDH 
To: kris@hotair.hobl.lucent.com (kris)
Date: Thu, 16 Oct 97 13:39:15 CDT
Cc: ietf-ppp@merit.edu
In-Reply-To: <9710161809.AA03502@hotair.hobl.lucent.com>; from "kris" at Oct 16, 97 2:09 pm
Mailer: Elm [revision: 70.85]
Sender: owner-ietf-ppp@merit.edu



Greetings,

IMHO, the proposal in draft-pppsonet-scrambler-1 seems complex enough to
lead to interoperability problems in itself.

How about a simple self synchronizing scrambler over the SPE bytes?
(Slower resync and easier but still not interoperable.)

How about having the current 1619 transmitter look for the nasty sequence
and sprinkle in extra escape sequences as required to keep Sonet happy? (Medium
complexity but interoperable.)


Stuart Venters
(Not at Adtran on this)
sventers@adtran.com


- - - - - - - - - - - - - - - - -

From owner-ietf-ppp@merit.edu  Thu Oct 16 15:33:40 1997
Received: from localhost (daemon@localhost)
	by merit.edu (8.8.7/8.8.5) with SMTP id PAA29983;
	Thu, 16 Oct 1997 15:32:18 -0400 (EDT)
Received: by merit.edu (bulk_mailer v1.5); Thu, 16 Oct 1997 15:32:10 -0400
Received: (from majordom@localhost)
	by merit.edu (8.8.7/8.8.5) id PAA29964
	for ietf-ppp-outgoing; Thu, 16 Oct 1997 15:32:10 -0400 (EDT)
Received: from pitbull.cisco.com (pitbull.cisco.com [171.69.223.73])
	by merit.edu (8.8.7/8.8.5) with SMTP id PAA29952
	for ; Thu, 16 Oct 1997 15:32:03 -0400 (EDT)
Received: from fred-axel-fr.cisco.com (fred-axel-fr.cisco.com [171.69.128.115]) by pitbull.cisco.com (8.6.12/8.6.5) with ESMTP id MAA01703; Thu, 16 Oct 1997 12:30:47 -0700
Received: from [171.69.128.118] (fred-hm-dhcp3.cisco.com [171.69.128.118]) by fred-axel-fr.cisco.com (8.6.8+c/CISCO.WS.1.1) with ESMTP id MAA05819; Thu, 16 Oct 1997 12:30:38 -0700
X-Sender: fred@stilton.cisco.com
Message-Id: 
In-Reply-To: <9710161338.AA09400@hursley.ibm.com>
References: <6690.wsimpson@greendragon.com> from "William Allen Simpson"
 at Oct 16, 97 11:54:16 am
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 16 Oct 1997 12:00:29 -0700
To: brian@hursley.ibm.com
From: Fred Baker 
Subject: Re: ID - PPP over SONET/SDH
Cc: wsimpson@greendragon.com (William Allen Simpson), ietf-ppp@merit.edu,
        kris@hotair.hobl.lucent.com, iesg@ietf.org
Sender: owner-ietf-ppp@merit.edu

At 2:38 PM +0100 10/16/97, (Brian E Carpenter) wrote:
>ANSI being a national standards body, and the IETF being
>international, it is highly unlikely that you will see
>a formal liaison.

The point here is IMHO moot - ANSI feeds documents to ITU-T, who owns SDH,
and we have a liaison with ITU-T. So what?

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  "A beautiful idea has a much greater chance of being a correct idea
   than an ugly one."
                     -- Roger Penrose, "The Emperor's New Mind", 1989


- - - - - - - - - - - - - - - - -

From owner-ietf-ppp@merit.edu  Thu Oct 16 15:28:23 1997
Received: from localhost (daemon@localhost)
	by merit.edu (8.8.7/8.8.5) with SMTP id PAA29847;
	Thu, 16 Oct 1997 15:26:58 -0400 (EDT)
Received: by merit.edu (bulk_mailer v1.5); Thu, 16 Oct 1997 15:26:40 -0400
Received: (from majordom@localhost)
	by merit.edu (8.8.7/8.8.5) id PAA29829
	for ietf-ppp-outgoing; Thu, 16 Oct 1997 15:26:40 -0400 (EDT)
Received: from Bill.Simpson.DialUp.Mich.Net (pm066-26.dialip.mich.net [141.211.5.156])
	by merit.edu (8.8.7/8.8.5) with SMTP id PAA29818;
	Thu, 16 Oct 1997 15:26:30 -0400 (EDT)
Date: Thu, 16 Oct 97 16:16:09 GMT
From: "William Allen Simpson" 
Message-ID: <6693.wsimpson@greendragon.com>
To: ietf-ppp@merit.edu
Cc: iesg@ietf.org
Subject: Re: ID - PPP over SONET/SDH
Sender: owner-ietf-ppp@merit.edu

> From: James Manchester 
> The scrambling problem is exactly the same for SDH, and ANSI T1 will be working
> with ITU-T to take on this issue in the context of aligning T1.105 with ITU-T
> Recommendation G.707.
>
Yes, SONET and SDH are almost the same thing -- Synchronous Digital
Heirachy is ITU-speak for SONET (Synchronous Optical Network), although
ITU-T changed a few things on the way, as per usual.

Actually, I think the ITU term SDH is a little better than SONET, as it
is more descriptive, and both SONET and SDH will run over non-optical
links.   But they are just used as acronyms, so it really does not
matter....

G.707 must be new.


> The problem with ignoring ANSI is that the IETF has a specification on SONET and
> SONET is the responsibility of ANSI.  SONET represents a multi-billion dollar
> infrastructure in the US that cannot be ignored.

The IETF has IP over Ethernet, and Ethernet is the responsibility of
IEEE, and represents a multi-billion infrastructure, etc.  IETF still
handles its own protocols over Ethernet.

Sounds like a turf battle heating up....


> The IETF PPP over
> SONET specification opens up a major security hole in the SONET public network.
> We have been in contact with the network operators that we believe are impacted,
> have demonstrated this problem to them, and have been working with them to close
> up the holes in their network.
>
That's interesting, but I wonder why the IETF equipment vendors were not
notified as well?  Hey, and maybe the RFC author and the WG?  (Maybe
this was your notification?)


> BTW, this has nothing to do with Bellcore Generic Requirements or clock
> specifications as implied by Bill Simpson (in fact, I want to make sure that
> everyone is clear on this - this is not a problem with SONET or SDH standards).

Ahh, then this must be a new problem.  I wish you would tell us what it is?


> I would appreciate specific citations to the Bellcore work that is believed to be
> in err if possible.  I also do not know what clock LOS is?  LOS in the SONET
> world is loss of signal and is independent of the clock.
>
Hmmm, seems to me that LOS is directly related to clocks.  I remember
discussing the LOS problem when you were at Bellcore a few years back.
Perhaps you have forgotten.  I'll do a quick reprise, off the top of my
head.

SONET-SDH is synchronous, and thus requires a clock to keep track of the
bits as they go by.  Clocks are not perfect, so they need to be (1)
stimulated by changing edge conditions, and (2) corrected for drift
every once in awhile.

Failure to detect enough changing bits is Loss of Signal (LOS).  The
drift correction uses a special 16-bit frame marker (called A1 and A2)
with a clever bit sequence in it.  LOS that is not quickly recovered by
the special frame markers causes Loss of Frame (LOF).

The SONET specification (my latest copy is TR-NWT-000253, December 1991)
provides that the special A1A2 frame marker shows up every 6,480 bits
(810 bytes), no matter what the link speed.  That guarantees a series of
changing bits, and corrects the clock drift.

The SONET specification requires Loss of Signal when too many
consecutive zero bits appear between the frame markers.

 - Why not one bits, too?  Unknown, probably a mistake in the
   specification.

 - How many bits?  Well, it doesn't actually specify; instead, it gives
   a time range.  LOS occurs after 2.3 to 100 microseconds.

 - Using a time means that the number of bits varies depending on the
   speed of the link.  That leads to non-interoperability between
   vendors of different speed links.

 - Why a range?  Presumably the committee could not agree.  That's the
   most serious mistake, as it leads to non-interoperability of vendors
   with the same speed links.

 - For OC48-STM16 (2.5 gigabits per second), the range is 17,170 to
   248,832 bits.  That's a lot!

 - For OC3-STM1 (155 megabits per second), the range is only 358 to
   15,552 bits.  On the low end, that's nowhere near enough!

 - Worse, early testing showed that at least one SONET chip vendor's
   clock stalled at only 70 bits!  Much too short!

Since the A1A2 recovers from LOS, it would have made a lot more sense to
have a required clock stability of a fixed 6,480 bits, which would be
about 40 microseconds at OC3-STM1, the slowest speed we run PPP over
SONET-SDH.  Clocks this stable are not hard....

All of this was reported to Bellcore (the keeper of the SONET spec at
the time) about 5 years ago.  They were pushing ATM for data, and having
enough non-zero bits is not really a problem for voice.  Apparently,
they didn't fix the spec.

Meanwhile, we talk about this every few years, and recommend that
vendors buy from chip vendors with stable clocks.

For vendors with bad clocks and too short LOS, there is a handy 127 byte
sequence that you can put in a PPP data packet, and drop their link for
every one in 3,240 packets (on average, if I remember correctly).  Still
not very much, but enough to be annoying.

Of course, that attack requires that you be the only user of the link.
For real routers and real backbones and SONET OC3 links that are part of
an OC48 network, the problem is vanishingly small.

WSimpson@UMich.edu
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
- - - - - - - - - - - - - - - - -

From owner-ietf-ppp@merit.edu  Thu Oct 16 15:37:37 1997
Received: from localhost (daemon@localhost)
	by merit.edu (8.8.7/8.8.5) with SMTP id PAA00220;
	Thu, 16 Oct 1997 15:36:16 -0400 (EDT)
Received: by merit.edu (bulk_mailer v1.5); Thu, 16 Oct 1997 15:36:03 -0400
Received: (from majordom@localhost)
	by merit.edu (8.8.7/8.8.5) id PAA00199
	for ietf-ppp-outgoing; Thu, 16 Oct 1997 15:36:02 -0400 (EDT)
Received: from red.juniper.net (red.juniper.net [208.197.169.254])
	by merit.edu (8.8.7/8.8.5) with ESMTP id PAA00194
	for ; Thu, 16 Oct 1997 15:35:57 -0400 (EDT)
Received: from shark.juniper.net (shark.juniper.net [208.197.169.201])
	by red.juniper.net (8.8.5/8.8.5) with ESMTP id MAA02384;
	Thu, 16 Oct 1997 12:35:25 -0700 (PDT)
Received: (from skibo@localhost) by shark.juniper.net (8.7.6/8.7.3) id MAA04144; Thu, 16 Oct 1997 12:35:25 -0700 (PDT)
Date: Thu, 16 Oct 1997 12:35:25 -0700 (PDT)
From: Thomas Skibo 
Message-Id: <199710161935.MAA04144@shark.juniper.net>
To: kris@hotair.hobl.lucent.com
Subject: Re: ID - PPP over SONET/SDH
Newsgroups: jnx.ext.ietf.ppp
In-Reply-To: <9710152250.AA04077@hotair.hobl.lucent.com>
Organization: Juniper Networks, Inc.
Cc: ietf-ppp@merit.edu
Sender: owner-ietf-ppp@merit.edu

In article <9710152250.AA04077@hotair.hobl.lucent.com> you write:
>
>I have submitted an Internet Draft  that
>addresses the PPP/SONET interface defined in the RFC 1619.
>

I'd be curious to know if the X^43+1 self-synchronizing polynomial
used for ATM cell payload scrambling was considered.  It's much
simpler and wouldn't require mucking about with the path overhead
bytes.  It also syncs up a lot quicker than your proposal (6 bytes
instead of several SONET frames).


-- 
Thomas Skibo		Juniper Networks, Inc.
- - - - - - - - - - - - - - - - -

From owner-ietf-ppp@merit.edu  Thu Oct 16 15:33:55 1997
Received: from localhost (daemon@localhost)
	by merit.edu (8.8.7/8.8.5) with SMTP id PAA00101;
	Thu, 16 Oct 1997 15:32:32 -0400 (EDT)
Received: by merit.edu (bulk_mailer v1.5); Thu, 16 Oct 1997 15:32:07 -0400
Received: (from majordom@localhost)
	by merit.edu (8.8.7/8.8.5) id PAA29957
	for ietf-ppp-outgoing; Thu, 16 Oct 1997 15:32:07 -0400 (EDT)
Received: from rhodes.cisco.com (rhodes.cisco.com [171.69.1.169])
	by merit.edu (8.8.7/8.8.5) with SMTP id PAA29947
	for ; Thu, 16 Oct 1997 15:31:59 -0400 (EDT)
Received: from fred-axel-fr.cisco.com (fred-axel-fr.cisco.com [171.69.128.115]) by rhodes.cisco.com (8.6.12/CISCO.SERVER.1.1) with ESMTP id MAA18662; Thu, 16 Oct 1997 12:30:48 -0700
Received: from [171.69.128.118] (fred-hm-dhcp3.cisco.com [171.69.128.118]) by fred-axel-fr.cisco.com (8.6.8+c/CISCO.WS.1.1) with ESMTP id MAA05822; Thu, 16 Oct 1997 12:30:42 -0700
X-Sender: fred@stilton.cisco.com
Message-Id: 
In-Reply-To: <9710161339.AA19648@hotair.hobl.lucent.com>
References: Your message of "Thu, 16 Oct 1997 11:54:16 GMT."            
 <6689.wsimpson@greendragon.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 16 Oct 1997 12:03:06 -0700
To: kris 
From: Fred Baker 
Subject: Re: ID - PPP over SONET/SDH
Cc: ietf-ppp@merit.edu, iesg@ietf.org, gfraser@cisco.com, gepps@cisco.com
Sender: owner-ietf-ppp@merit.edu

At 9:39 AM -0400 10/16/97, kris wrote:
>The reason for our ID is that we verfied by experiment that a
>PPP over SONET/SDH implementation that merely conforms to RFC 1619
>(no scrambling) severely compromises the security of the SONET/SDH layer.
>In fact the malicious datagrams can be transmitted from anywhere in
>the Internet. The user need not be directly connected to the SONET
>network.

I'd be interested to know the specifics of the experiment. What do these
"malicous datagrams" look like? What is their effect on the link? What is
the security implication?


- - - - - - - - - - - - - - - - -

From owner-ietf-ppp@merit.edu  Thu Oct 16 16:34:46 1997
Received: from localhost (daemon@localhost)
	by merit.edu (8.8.7/8.8.5) with SMTP id QAA01315;
	Thu, 16 Oct 1997 16:31:41 -0400 (EDT)
Received: by merit.edu (bulk_mailer v1.5); Thu, 16 Oct 1997 16:30:05 -0400
Received: (from majordom@localhost)
	by merit.edu (8.8.7/8.8.5) id QAA01257
	for ietf-ppp-outgoing; Thu, 16 Oct 1997 16:30:05 -0400 (EDT)
Received: from ihgw2.lucent.com (ihgw2.lucent.com [207.19.48.2])
	by merit.edu (8.8.7/8.8.5) with SMTP id QAA01252
	for ; Thu, 16 Oct 1997 16:30:01 -0400 (EDT)
Received: from mvjok.mv.lucent.com by ihig2.firewall.lucent.com (SMI-8.6/EMS-L sol2)
	id PAA24286; Thu, 16 Oct 1997 15:21:21 -0500
Received: by mvjok.mv.lucent.com (5.x/EMS-L sol2)
	id AA29872; Thu, 16 Oct 1997 16:29:35 -0400
Received: from ewg.nh.ultranet.com (sonppp-d2) by mvjok.mv.lucent.com (5.x/EMS-L sol2)
	id AA29778; Thu, 16 Oct 1997 16:29:22 -0400
Message-Id: <3446782F.6CBA@lucent.com>
Date: Thu, 16 Oct 1997 16:25:19 -0400
From: Eric W Gray 
Reply-To: ewgray@lucent.com
X-Mailer: Mozilla 3.01Gold (Win95; I)
Mime-Version: 1.0
To: William Allen Simpson 
Cc: ietf-ppp@merit.edu
Subject: Re: ID - PPP over SONET/SDH
References: <6693.wsimpson@greendragon.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-ppp@merit.edu

Bill,

You wrote:
> 
...
> >
> That's interesting, but I wonder why the IETF equipment vendors were
> not notified as well?  Hey, and maybe the RFC author and the WG?  
> (Maybe this was your notification?)
> 
...

My involvement in this discussion is somewhat peripheral.  However, I
believe many of our colleagues might find your insinuations of other 
than entirely above-board behavior on our part somewhat indiscreet.

We are a fairly large corporation with a variety of interests - some
of which involve supplying parts to the IETF equipment vendors you
speak of.  It's entirely possible that they have been notified by us
- perhaps you would like to ask?

In any case, what would you suggest?  Should we perhaps have waited
until the next round of standards meetings in order to ensure that a
sufficient amount of time has passed for everyone to have been more
discreetly notified?   

-- 
Eric Gray
EMail at either mailto:ewgray@lucent.com (work)
     or mailto:eric.gray@nh.ultranet.com (home)
Phone (508) 960-6162 or (603) 659-6859
FAX (508) 960-6095 or (603) 659-6859

- - - - - - - - - - - - - - - - -

From owner-ietf-ppp@merit.edu  Thu Oct 16 16:49:49 1997
Received: from localhost (daemon@localhost)
	by merit.edu (8.8.7/8.8.5) with SMTP id QAA01631;
	Thu, 16 Oct 1997 16:47:08 -0400 (EDT)
Received: by merit.edu (bulk_mailer v1.5); Thu, 16 Oct 1997 16:46:39 -0400
Received: (from majordom@localhost)
	by merit.edu (8.8.7/8.8.5) id QAA01607
	for ietf-ppp-outgoing; Thu, 16 Oct 1997 16:46:38 -0400 (EDT)
Received: from doberman.cisco.com (doberman.cisco.com [171.69.1.178])
	by merit.edu (8.8.7/8.8.5) with SMTP id QAA01602
	for ; Thu, 16 Oct 1997 16:46:34 -0400 (EDT)
Received: from fred-axel-fr.cisco.com (fred-axel-fr.cisco.com [171.69.128.115]) by doberman.cisco.com (8.6.12/8.6.5) with ESMTP id NAA22938; Thu, 16 Oct 1997 13:46:03 -0700
Received: from [171.69.128.118] (fred-hm-dhcp3.cisco.com [171.69.128.118]) by fred-axel-fr.cisco.com (8.6.8+c/CISCO.WS.1.1) with ESMTP id NAA05913; Thu, 16 Oct 1997 13:45:54 -0700
X-Sender: fred@stilton.cisco.com
Message-Id: 
In-Reply-To: <6595.wsimpson@greendragon.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 16 Oct 1997 13:18:36 -0700
To: "William Allen Simpson" 
From: Fred Baker 
Subject: Re: [Fwd: [Fwd: Requesting comments on my draft]]
Cc: ietf-ppp@merit.edu
Sender: owner-ietf-ppp@merit.edu

At 2:30 PM +0000 9/30/97, William Allen Simpson wrote:
>But do we really need yet another incompatible way of doing the same
>thing we've been doing for years?

That's up to the working group (of which you are a member) to decide.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  "A beautiful idea has a much greater chance of being a correct idea
   than an ugly one."
                     -- Roger Penrose, "The Emperor's New Mind", 1989


- - - - - - - - - - - - - - - - -

From owner-ietf-ppp@merit.edu  Thu Oct 16 18:24:12 1997
Received: from localhost (daemon@localhost)
	by merit.edu (8.8.7/8.8.5) with SMTP id SAA03042;
	Thu, 16 Oct 1997 18:22:42 -0400 (EDT)
Received: by merit.edu (bulk_mailer v1.5); Thu, 16 Oct 1997 18:22:32 -0400
Received: (from majordom@localhost)
	by merit.edu (8.8.7/8.8.5) id SAA03024
	for ietf-ppp-outgoing; Thu, 16 Oct 1997 18:22:31 -0400 (EDT)
Received: from cbgw1.lucent.com (cbgw1.lucent.com [207.24.196.51])
	by merit.edu (8.8.7/8.8.5) with SMTP id SAA03020
	for ; Thu, 16 Oct 1997 18:22:27 -0400 (EDT)
Cc: kris , ietf-ppp@merit.edu, iesg@ietf.org,
        gfraser@cisco.com, gepps@cisco.com
Received: from hotair.hobl.lucent.com by cbig1.firewall.lucent.com (SMI-8.6/EMS-L sol2)
	id SAA00983; Thu, 16 Oct 1997 18:12:55 -0400
Received: from camus.hobl.lucent.com ([199.118.135.96]) by hotair.hobl.lucent.com (4.1/EMS-L SunOS)
	id AA17360; Thu, 16 Oct 97 18:22:11 EDT
Message-Id: <3446918D.C72321A2@lucent.com>
Date: Thu, 16 Oct 1997 18:13:33 -0400
From: James Manchester 
Reply-To: manchester@lucent.com
Organization: Advanced Networking Technologies
X-Mailer: Mozilla 4.0 [en] (Win95; I)
Mime-Version: 1.0
To: Fred Baker 
Original-Cc: kris , ietf-ppp@merit.edu, iesg@ietf.org,
        gfraser@cisco.com, gepps@cisco.com
Subject: Re: ID - PPP over SONET/SDH
X-Priority: 3 (Normal)
References: Your message of "Thu, 16 Oct 1997 11:54:16 GMT."            
	 <6689.wsimpson@greendragon.com> 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-ppp@merit.edu

Fred,

All of your questions will be answered by reading the Internet Draft.
If you require proof of our hypotheses, I invite you to Holmdel for a
demonstration.

James

-------
James Sterling Manchester
Remember the MetroBus!
manchester@bell-labs.com


Fred Baker wrote:

> At 9:39 AM -0400 10/16/97, kris wrote:
> >The reason for our ID is that we verfied by experiment that a
> >PPP over SONET/SDH implementation that merely conforms to RFC 1619
> >(no scrambling) severely compromises the security of the SONET/SDH
> layer.
> >In fact the malicious datagrams can be transmitted from anywhere in
> >the Internet. The user need not be directly connected to the SONET
> >network.
>
> I'd be interested to know the specifics of the experiment. What do
> these
> "malicous datagrams" look like? What is their effect on the link? What
> is
> the security implication?



- - - - - - - - - - - - - - - - -

From owner-ietf-ppp@merit.edu  Thu Oct 16 19:00:56 1997
Received: from localhost (daemon@localhost)
	by merit.edu (8.8.7/8.8.5) with SMTP id SAA03546;
	Thu, 16 Oct 1997 18:59:34 -0400 (EDT)
Received: by merit.edu (bulk_mailer v1.5); Thu, 16 Oct 1997 18:59:22 -0400
Received: (from majordom@localhost)
	by merit.edu (8.8.7/8.8.5) id SAA03528
	for ietf-ppp-outgoing; Thu, 16 Oct 1997 18:59:22 -0400 (EDT)
Received: from cbgw1.lucent.com (cbgw1.lucent.com [207.24.196.51])
	by merit.edu (8.8.7/8.8.5) with SMTP id SAA03524
	for ; Thu, 16 Oct 1997 18:59:18 -0400 (EDT)
Received: from hotair.hobl.lucent.com by cbig1.firewall.lucent.com (SMI-8.6/EMS-L sol2)
	id SAA02850; Thu, 16 Oct 1997 18:49:46 -0400
Received: from camus.hobl.lucent.com ([199.118.135.96]) by hotair.hobl.lucent.com (4.1/EMS-L SunOS)
	id AA17953; Thu, 16 Oct 97 18:59:01 EDT
Message-Id: <34469A2F.F306735E@lucent.com>
Date: Thu, 16 Oct 1997 18:50:23 -0400
From: James Manchester 
Reply-To: manchester@lucent.com
Organization: Advanced Networking Technologies
X-Mailer: Mozilla 4.0 [en] (Win95; I)
Mime-Version: 1.0
To: Fred Baker 
Cc: William Allen Simpson , ietf-ppp@merit.edu
Subject: Re: [Fwd: [Fwd: Requesting comments on my draft]]
X-Priority: 3 (Normal)
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-ppp@merit.edu

Fred,

Before anyone dismisses this, or fails to give it due consideration, I
suggest you examine it very carefully.  I would also extend an
invitation to all to come to Holmdel Bell-Labs and we will provide you
proof of everything that is in the Internet Draft.  Please call ahead
first though as my wife is due any day now and I may be away from the
office for a few days.

Since I am also a member of the working group now, I suggest you should
read what we were proposing to the IETF in the Internet Draft.  T1 is
going to fix the problem by defining a generic scrambler for data
mappings (including PPP over SONET) to the SONET SPE.  They will be
holding a special session in the first week of December to finish the
specification of this as this is a very very serious issue.
Unfortunately, just about everything that Bill Simpson wrote about SONET
is wrong.  Every single person I know of that works on SONET, has been
able to point out upon their first reading of the RFC, that the RFC has
a problem by not requiring the scrambling of the PPP delineated IP
datagrams.

I will address his Bill Simpson's points specifically in an email later;
however, this brings up another issue - what to do with the RFC in the
interim.  At the very least, there needs to a statement placed in
RFC1619 that there is a problem with the mapping.  This should be done
to minimize liability.  For the most part, the public SONET network is
regulated by local governments.  When an RFC 1619 compliant interface is
connected to a public SONET interface, the hole in the RFC can cause
operational situations (e.g., protection switching, SESs, etc) which are
regulated by tariffs that are approved by local US governments.  When
these operational situations occur, the reliability of the public
network diminishes and operators are forced to offer rebates to
customers.

I understand that this issue may have been discussed in the past.  If it
was, then the wrong decision was made with regard to the issue.  For me
to have knowledge of this problem and not immediately begin working with
service providers (whose networks are open to attack by vendor
compliance to RFC 1619) and standards (this problem can be fixed with a
payload scrambler but the payload scrambler must be standardized for
interoperability purposes) to fix it as soon as possible would be wrong.

I appreciate all the suggestions folks have made for solving the problem
(e.g., using the ATM self synchronous scrambler and using some form of
escaping).  I encourage those folks to submit their ideas as
contributions to T1X1.5.

cheerio,

James

-------
James Sterling Manchester
Remember the MetroBus!
manchester@bell-labs.com

"It is futile to be amazed by the apparent paradox that leads thought to
its own negation by the opposite paths of humiliated reason and
triumphal reason."  -Albert Camus, "The Myth of Sisyphus," 1955.


Fred Baker wrote:

> At 2:30 PM +0000 9/30/97, William Allen Simpson wrote:
> >But do we really need yet another incompatible way of doing the same
> >thing we've been doing for years?
>
> That's up to the working group (of which you are a member) to decide.
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> =-=-=
>   "A beautiful idea has a much greater chance of being a correct idea
>    than an ugly one."
>                      -- Roger Penrose, "The Emperor's New Mind", 1989



- - - - - - - - - - - - - - - - -

From owner-ietf-ppp@merit.edu  Fri Oct 17 01:23:52 1997
Received: from localhost (daemon@localhost)
	by merit.edu (8.8.7/8.8.5) with SMTP id BAA07157;
	Fri, 17 Oct 1997 01:22:21 -0400 (EDT)
Received: by merit.edu (bulk_mailer v1.5); Fri, 17 Oct 1997 01:21:55 -0400
Received: (from majordom@localhost)
	by merit.edu (8.8.7/8.8.5) id BAA07137
	for ietf-ppp-outgoing; Fri, 17 Oct 1997 01:21:54 -0400 (EDT)
Received: from stpn.soft.net (stpn.soft.net [204.143.127.2])
	by merit.edu (8.8.7/8.8.5) with SMTP id BAA07131
	for ; Fri, 17 Oct 1997 01:21:43 -0400 (EDT)
Received: from shilpa.pcl.stpn.soft.net (unverified [204.143.116.98]) by stpn.soft.net
 (EMWAC SMTPRS 0.83) with SMTP id ;
 Fri, 17 Oct 1997 10:54:36 +0530
Received: from [192.168.200.142] by shilpa.pcl.stpn.soft.net id aa04902;
          17 Oct 97 10:47 IST
Message-ID: <3446F5C2.739C@pcl.stpn.soft.net>
Date: Fri, 17 Oct 1997 10:51:06 +0530
From: Vimal Khanna 
Organization: Mindware
X-Mailer: Mozilla 3.04Gold (WinNT; I)
MIME-Version: 1.0
To: Fred Baker 
CC: Jonathan.Goodchild@rdl.co.uk, vandys@cisco.com, karl@ascend.com,
        William Allen Simpson , ietf-ppp@merit.edu
Subject: Re: [Fwd: [Fwd: Requesting comments on my draft]]
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-ppp@merit.edu

Fred Baker wrote:
> 
> At 2:30 PM +0000 9/30/97, William Allen Simpson wrote:
> >But do we really need yet another incompatible way of doing the same
> >thing we've been doing for years?
> 
> That's up to the working group (of which you are a member) to decide.
> 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>   "A beautiful idea has a much greater chance of being a correct idea
>    than an ugly one."
>                      -- Roger Penrose, "The Emperor's New Mind", 1989
> 
> 
> 

The proposed draft has been revised as per the suggestions of the WG.
The draft "PPP for Asynchronous PAD to Synchronous X.25 access" is now
available as 

"draft-rfced-info-khana-01.txt".

The draft makes a comparison with the existing solution given in a
related RFC. The existing solution is based on comparison of data
received on a VC *after* a VC has been established, while the draft
suggests a method for deciding the presence of a PPP carrying VC at the
time of call establishment itself, using CUD. 

It should be noted that the commonly available X.25 host software
products are based on CUD based applications invokation. Also, a data
pattern matching based application invokation has some practical
problems due to the general tendency of the vendors of invoking standard
pseudo-tty drivers on receiving PAD calls. This issue has also been
discussed in the draft.

We believe the method given in the draft will be more acceptable to the
vendors offering X.25 hosts based software for implementing PPP in such
interconnection scenarios. This could result in more hosts based
solutions rather than the methods being used currently for this
scenario, like async-sync converters/protocol translators, which involve
additional equipments cost.

More suggestions and comments from the WG members are welcome.

Regards.

Vimal
- - - - - - - - - - - - - - - - -

From owner-ietf-ppp@merit.edu  Fri Oct 17 05:08:12 1997
Received: from localhost (daemon@localhost)
	by merit.edu (8.8.7/8.8.5) with SMTP id FAA08864;
	Fri, 17 Oct 1997 05:06:28 -0400 (EDT)
Received: by merit.edu (bulk_mailer v1.5); Fri, 17 Oct 1997 05:05:58 -0400
Received: (from majordom@localhost)
	by merit.edu (8.8.7/8.8.5) id FAA08842
	for ietf-ppp-outgoing; Fri, 17 Oct 1997 05:05:58 -0400 (EDT)
Received: from hursley.ibm.com (mersey.hursley.ibm.com [194.196.110.10])
	by merit.edu (8.8.7/8.8.5) with SMTP id FAA08838
	for ; Fri, 17 Oct 1997 05:05:54 -0400 (EDT)
Received: by hursley.ibm.com (AIX 3.2/UCB 5.64/4.03)
          id AA95730; Fri, 17 Oct 1997 10:05:21 +0100
Date: Fri, 17 Oct 1997 10:05:21 +0100
Message-Id: <9710170905.AA95730@hursley.ibm.com>
From: "(Brian E Carpenter)" 
Subject: Re: ID - PPP over SONET/SDH
To: fred@cisco.com (Fred Baker)
Cc: brian@hursley.ibm.com, wsimpson@greendragon.com, ietf-ppp@merit.edu,
        kris@hotair.hobl.lucent.com, iesg@ietf.org
In-Reply-To:  from "Fred Baker" at Oct 16, 97 12:00:29 pm
Reply-To: brian@hursley.ibm.com
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-ietf-ppp@merit.edu

Fred, you and I are in violent agreement here.
Technical dialogue does not require formal liaison.

  Brian

>- Fred Baker said:
> 
> At 2:38 PM +0100 10/16/97, (Brian E Carpenter) wrote:
> >ANSI being a national standards body, and the IETF being
> >international, it is highly unlikely that you will see
> >a formal liaison.
> 
> The point here is IMHO moot - ANSI feeds documents to ITU-T, who owns SDH,
> and we have a liaison with ITU-T. So what?
> 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>   "A beautiful idea has a much greater chance of being a correct idea
>    than an ugly one."
>                      -- Roger Penrose, "The Emperor's New Mind", 1989
> 
> 
> 

- - - - - - - - - - - - - - - - -

From owner-ietf-ppp@merit.edu  Fri Oct 17 06:20:15 1997
Received: from localhost (daemon@localhost)
	by merit.edu (8.8.7/8.8.5) with SMTP id GAA09275;
	Fri, 17 Oct 1997 06:17:55 -0400 (EDT)
Received: by merit.edu (bulk_mailer v1.5); Fri, 17 Oct 1997 06:14:25 -0400
Received: (from majordom@localhost)
	by merit.edu (8.8.7/8.8.5) id GAA09249
	for ietf-ppp-outgoing; Fri, 17 Oct 1997 06:14:25 -0400 (EDT)
Received: from aun.uninett.no (aun.uninett.no [129.241.1.99])
	by merit.edu (8.8.7/8.8.5) with ESMTP id GAA09245
	for ; Fri, 17 Oct 1997 06:14:17 -0400 (EDT)
Received: from dale.uninett.no by aun.uninett.no with SMTP (PP);
          Fri, 17 Oct 1997 12:13:58 +0200
Received: from dale.uninett.no (localhost [127.0.0.1]) 
          by dale.uninett.no (8.6.9/8.6.12) with ESMTP id MAA02588;
          Fri, 17 Oct 1997 12:13:56 +0200
X-Mailer: exmh version 1.6.9 8/22/96
From: Harald.T.Alvestrand@uninett.no
To: kris 
cc: ietf-ppp@merit.edu, iesg@ietf.org
Subject: Re: ID - PPP over SONET/SDH
In-reply-to: Your message of "Thu, 16 Oct 1997 14:09:50 EDT." <9710161809.AA03502@hotair.hobl.lucent.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 17 Oct 1997 12:13:55 +0200
Message-ID: <2585.877083235@dale.uninett.no>
Sender: owner-ietf-ppp@merit.edu

The essential part of this seems to be the statement from the
(not-yet-published) I-D:

> This long string of zeros is, in the worst case, 
> 2080 bits or 13 microsec for the STS-3c mapping.  This is well within 
> the specification for SONET LOS (Loss Of Signal) and depending on the 
> type of clock and clock recovery circuit may also cause framing and 
> synchronization problems.

The claim is that SONET equipment not able to transmit 2080 bits of
all zeroes is vulnerable to a denial-of-service attack.
I *think* the 2080 bits is related to the Ethernet frame size, so
that the problem might be even more severe on large-MTU paths.

My deviousness-type brain seems to indicate also that the use of XOR
shift registers rather than simple bit insertion was a design mistake
in the SONET specification; inserting 2 flag bits every 2000 bits would
have solved the problem completely, for all time, and for all possible
payloads, at a cost of exactly 0.1% of the carrying capacity.

Depending on the payload to provide transitions is a vulnerability, and
will keep on being a vulnerability.

But this is probably too late to change.

If this was to be fixed at the PPP layer, I would advocate simply
inserting a "noise" byte for every 250 bytes of PPP packet data, for
an overhead of 0.25%.

Keep It Simple.

But it's not my call.

                   Harald Tveit Alvestrand
             who was educated as a telco engineer, strangely



- - - - - - - - - - - - - - - - -

From owner-ietf-ppp@merit.edu  Fri Oct 17 06:36:29 1997
Received: from localhost (daemon@localhost)
	by merit.edu (8.8.7/8.8.5) with SMTP id GAA09425;
	Fri, 17 Oct 1997 06:35:07 -0400 (EDT)
Received: by merit.edu (bulk_mailer v1.5); Fri, 17 Oct 1997 06:35:00 -0400
Received: (from majordom@localhost)
	by merit.edu (8.8.7/8.8.5) id GAA09405
	for ietf-ppp-outgoing; Fri, 17 Oct 1997 06:35:00 -0400 (EDT)
Received: from hursley.ibm.com (mersey.hursley.ibm.com [194.196.110.10])
	by merit.edu (8.8.7/8.8.5) with SMTP id GAA09401
	for ; Fri, 17 Oct 1997 06:34:55 -0400 (EDT)
Received: by hursley.ibm.com (AIX 3.2/UCB 5.64/4.03)
          id AA62546; Fri, 17 Oct 1997 11:34:23 +0100
Date: Fri, 17 Oct 1997 11:34:23 +0100
Message-Id: <9710171034.AA62546@hursley.ibm.com>
From: "(Brian E Carpenter)" 
Subject: Re: ID - PPP over SONET/SDH
To: Harald.T.Alvestrand@uninett.no
Cc: kris@hotair.hobl.lucent.com, ietf-ppp@merit.edu, iesg@ietf.org
In-Reply-To: <2585.877083235@dale.uninett.no> from "Harald.T.Alvestrand@uninett.no" at Oct 17, 97 12:13:55 pm
Reply-To: brian@hursley.ibm.com
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-ietf-ppp@merit.edu

Seems totally absurd to fix a hardware design bug other than
by fixing the hardware. Good grief, even the HDLC designers
understood this one.

  Brian

>- Harald.T.Alvestrand@uninett.no said:
> 
> The essential part of this seems to be the statement from the
> (not-yet-published) I-D:
> 
> > This long string of zeros is, in the worst case, 
> > 2080 bits or 13 microsec for the STS-3c mapping.  This is well within 
> > the specification for SONET LOS (Loss Of Signal) and depending on the 
> > type of clock and clock recovery circuit may also cause framing and 
> > synchronization problems.
> 
> The claim is that SONET equipment not able to transmit 2080 bits of
> all zeroes is vulnerable to a denial-of-service attack.
> I *think* the 2080 bits is related to the Ethernet frame size, so
> that the problem might be even more severe on large-MTU paths.
> 
> My deviousness-type brain seems to indicate also that the use of XOR
> shift registers rather than simple bit insertion was a design mistake
> in the SONET specification; inserting 2 flag bits every 2000 bits would
> have solved the problem completely, for all time, and for all possible
> payloads, at a cost of exactly 0.1% of the carrying capacity.
> 
> Depending on the payload to provide transitions is a vulnerability, and
> will keep on being a vulnerability.
> 
> But this is probably too late to change.
> 
> If this was to be fixed at the PPP layer, I would advocate simply
> inserting a "noise" byte for every 250 bytes of PPP packet data, for
> an overhead of 0.25%.
> 
> Keep It Simple.
> 
> But it's not my call.
> 
>                    Harald Tveit Alvestrand
>              who was educated as a telco engineer, strangely
> 
> 
> 
> 

- - - - - - - - - - - - - - - - -

From owner-ietf-ppp@merit.edu  Fri Oct 17 09:10:43 1997
Received: from localhost (daemon@localhost)
	by merit.edu (8.8.7/8.8.5) with SMTP id JAA11014;
	Fri, 17 Oct 1997 09:08:56 -0400 (EDT)
Received: by merit.edu (bulk_mailer v1.5); Fri, 17 Oct 1997 09:08:23 -0400
Received: (from majordom@localhost)
	by merit.edu (8.8.7/8.8.5) id JAA10987
	for ietf-ppp-outgoing; Fri, 17 Oct 1997 09:08:22 -0400 (EDT)
Received: from relay2.UU.NET (relay2.UU.NET [192.48.96.7])
	by merit.edu (8.8.7/8.8.5) with ESMTP id JAA10982
	for ; Fri, 17 Oct 1997 09:08:18 -0400 (EDT)
Received: from rodan.UU.NET by relay2.UU.NET with ESMTP 
	(peer crosschecked as: rodan.UU.NET [153.39.130.10])
	id QQdlqq26074; Fri, 17 Oct 1997 09:08:10 -0400 (EDT)
Received: from localhost by rodan.UU.NET with SMTP 
	(peer crosschecked as: mo@localhost)
	id QQdlqq28627; Fri, 17 Oct 1997 09:08:01 -0400 (EDT)
Message-Id: 
To: brian@hursley.ibm.com
cc: Harald.T.Alvestrand@uninett.no, kris@hotair.hobl.lucent.com,
        ietf-ppp@merit.edu, iesg@ietf.org, mo@UU.NET
Subject: Re: ID - PPP over SONET/SDH 
In-reply-to: Your message of "Fri, 17 Oct 1997 11:34:16 BST."
             <9710171034.AA87330@hursley.ibm.com> 
Date: Fri, 17 Oct 1997 09:08:01 -0400
From: "Mike O'Dell" 
Sender: owner-ietf-ppp@merit.edu

there is no inherent problem with scrambling per se, and it
is much easier to do than bit-stuffing at these speeds.

however....

the problem is that the normal SONET scrambling polynomial is shorter than
the MTU of POS packets.  this means that if you send a large enough packet
whose payload happens to be the scrambler pattern repeated several times,
because the scramblers are self-inverting and auto-synchronizing, the
outgoing scrambler promptly converts the packet payload to a running
strings of all 0s (or all 1s - don't remember which) and you fail the
transition density assumption of the clock recovery design at the recieve
end. presto - circuit suffers LOS and goes into red alarm.

this happens only in concanenated mode because when sub-multiplexed, (like
data on a VT1.5) the per-subcarrier SONET overhead bytes cause enough
transitions.  it doesn't happen with ATM because of SONET ATM framing and
the known max length of an ATM cell ensure sufficient transitions.

if we want to run a longer MTU, we need a longer polynomial.  

Note that I don't think this requires changing the SONET spec.

it only requires that the POS spec specify that the POS data stream
(byte-stuffed HDLC, actually) is scrambled with another polynomial
before being presented to the SONET framer.

	-mo
- - - - - - - - - - - - - - - - -

From owner-ietf-ppp@merit.edu  Fri Oct 17 09:44:14 1997
Received: from localhost (daemon@localhost)
	by merit.edu (8.8.7/8.8.5) with SMTP id JAA11547;
	Fri, 17 Oct 1997 09:42:52 -0400 (EDT)
Received: by merit.edu (bulk_mailer v1.5); Fri, 17 Oct 1997 09:42:03 -0400
Received: (from majordom@localhost)
	by merit.edu (8.8.7/8.8.5) id JAA11520
	for ietf-ppp-outgoing; Fri, 17 Oct 1997 09:42:02 -0400 (EDT)
Received: from ietf.org (ietf.org [132.151.1.19])
	by merit.edu (8.8.7/8.8.5) with ESMTP id JAA11510
	for ; Fri, 17 Oct 1997 09:41:57 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.8.7/8.8.7a) with ESMTP id JAA08245;
	Fri, 17 Oct 1997 09:41:36 -0400 (EDT)
Message-Id: <199710171341.JAA08245@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce@ietf.org
Cc: ietf-ppp@merit.edu
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-pppext-pppsonet-scrambler-00.txt
Date: Fri, 17 Oct 1997 09:41:35 -0400
Sender: owner-ietf-ppp@merit.edu

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF.

	Title		: PPP over SONET/SDH
	Author(s)	: J. Manchester, M. Krishnaswamy, 
                          S. Dravida, J. Anderson, B. Doshi,
                          E. Hernandez-Valencia, W. L. Edwards,
                          B. Bharucha, K. Fendick, G. Wetzel
	Filename	: draft-ietf-pppext-pppsonet-scrambler-00.txt
	Pages		: 14
	Date		: 16-Oct-97
	
This Internet Draft addresses the PPP/SONET interface defined
in the IETF RFC 1619 and its application in public Internet backbone
networks. By experimental analysis it is found that this SONET interface
specification is deficient in providing payload transparency. This
deficiency leads to deleterious effects in providing reliable network
operations. A simple SONET payload scrambler enhancement is proposed to overcome this deficiency. This work has been brought to the
ANSI T1X1.5 as an action item for the addition of the RFC 1619 mapping
to T1.105 with a scrambler to be determined by T1X1.
 
We are submitting the same proposal to IETF now with the interest to
enhance RFC-1619 accordingly and achieve alignment with ANSI T1 standards.
To facilitate this alignment, we have recommended that T1X1 establish a
formal liaison with IETF in regard to IP/SONET interface standards
and associated IP transmission standards development.

Internet-Drafts are available by anonymous FTP.  Login wih the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pppext-pppsonet-scrambler-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-pppsonet-scrambler-00.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	mailserv@ds.internic.net.  In the body type:
	"FILE /internet-drafts/draft-ietf-pppext-pppsonet-scrambler-00.txt".
	
NOTE:	The mail server at ds.internic.net can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ds.internic.net"

Content-Type: text/plain
Content-ID:	<19971016171356.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-pppext-pppsonet-scrambler-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pppext-pppsonet-scrambler-00.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19971016171356.I-D@ietf.org>

--OtherAccess--

--NextPart--


- - - - - - - - - - - - - - - - -

From owner-ietf-ppp@merit.edu  Fri Oct 17 10:18:28 1997
Received: from localhost (daemon@localhost)
	by merit.edu (8.8.7/8.8.5) with SMTP id KAA12237;
	Fri, 17 Oct 1997 10:17:06 -0400 (EDT)
Received: by merit.edu (bulk_mailer v1.5); Fri, 17 Oct 1997 10:16:58 -0400
Received: (from majordom@localhost)
	by merit.edu (8.8.7/8.8.5) id KAA12219
	for ietf-ppp-outgoing; Fri, 17 Oct 1997 10:16:58 -0400 (EDT)
Received: from algw1.lucent.com (algw1.lucent.com [205.147.213.1])
	by merit.edu (8.8.7/8.8.5) with SMTP id KAA12215
	for ; Fri, 17 Oct 1997 10:16:53 -0400 (EDT)
Cc: brian@hursley.ibm.com, Harald.T.Alvestrand@uninett.no,
        kris@hotair.hobl.lucent.com, ietf-ppp@merit.edu, iesg@ietf.org
Received: from hotair.hobl.lucent.com by alig1.firewall.lucent.com (SMI-8.6/EMS-L sol2)
	id KAA06662; Fri, 17 Oct 1997 10:23:09 -0400
Received: from lucent.com (vermont.hobl.lucent.com) by hotair.hobl.lucent.com (4.1/EMS-L SunOS)
	id AA07327; Fri, 17 Oct 97 10:16:36 EDT
Message-Id: <344773CA.11D4EF49@lucent.com>
Date: Fri, 17 Oct 1997 10:18:50 -0400
From: James Manchester 
Organization: Advanced Networking Technologies & Standards
X-Mailer: Mozilla 4.02 [en] (X11; I; IRIX 6.3 IP32)
Mime-Version: 1.0
To: "Mike O'Dell" 
Original-Cc: brian@hursley.ibm.com, Harald.T.Alvestrand@uninett.no,
        kris@hotair.hobl.lucent.com, ietf-ppp@merit.edu, iesg@ietf.org
Subject: Re: ID - PPP over SONET/SDH
References: 
Content-Type: multipart/alternative; boundary="------------1DC505FC4542CF8957C88F90"
Sender: owner-ietf-ppp@merit.edu


--------------1DC505FC4542CF8957C88F90
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Mike O'Dell wrote:

> there is no inherent problem with scrambling per se, and it
> is much easier to do than bit-stuffing at these speeds.
>
> however....
>
> the problem is that the normal SONET scrambling polynomial is shorter than
> the MTU of POS packets.  this means that if you send a large enough packet
> whose payload happens to be the scrambler pattern repeated several times,
> because the scramblers are self-inverting and auto-synchronizing, the
> outgoing scrambler promptly converts the packet payload to a running
> strings of all 0s (or all 1s - don't remember which) and you fail the
> transition density assumption of the clock recovery design at the recieve
> end. presto - circuit suffers LOS and goes into red alarm.

You are absolutely correct, except for one problem.  LOS has nothing to do
with the clock.  Clock problems and LOS are two completely different
operational problems.  Please see R6-52 of GR-253-CORE Issue 2.  LOS involves
monitoring the line for null bit transitions so one can accurately predict
whether or not a failure has occured that requires restoration.  The
LOS needs to be as fast as possible and independent of the bit rate because
the SONET (and the transport network in general) network, independent of
bit-rate, has to restore failures before they impact the service layer;
otherwise, massive network congestion will occur as all services try to
reestrablish themselves at the same time (and the network operator is likely
to have to report the outage to the FCC).

> this happens only in concanenated mode because when sub-multiplexed, (like
> data on a VT1.5) the per-subcarrier SONET overhead bytes cause enough
> transitions.  it doesn't happen with ATM because of SONET ATM framing and
> the known max length of an ATM cell ensure sufficient transitions.
>
> if we want to run a longer MTU, we need a longer polynomial.
>
> Note that I don't think this requires changing the SONET spec.
>
> it only requires that the POS spec specify that the POS data stream
> (byte-stuffed HDLC, actually) is scrambled with another polynomial
> before being presented to the SONET framer.
>

This is exactly what we are proposing.

>         -mo

Regards,

James

-------
James Sterling Manchester
Remember the MetroBus!
manchester@bell-labs.com

"It is futile to be amazed by the apparent paradox that leads thought to
its own negation by the opposite paths of humiliated reason and
triumphal reason."  -Albert Camus, "The Myth of Sisyphus," 1955.



--------------1DC505FC4542CF8957C88F90
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit


Mike O'Dell wrote:
there is no inherent problem with scrambling per se, and it
is much easier to do than bit-stuffing at these speeds.

however....

the problem is that the normal SONET scrambling polynomial is shorter than
the MTU of POS packets.  this means that if you send a large enough packet
whose payload happens to be the scrambler pattern repeated several times,
because the scramblers are self-inverting and auto-synchronizing, the
outgoing scrambler promptly converts the packet payload to a running
strings of all 0s (or all 1s - don't remember which) and you fail the
transition density assumption of the clock recovery design at the recieve
end. presto - circuit suffers LOS and goes into red alarm.

You are absolutely correct, except for one problem.  LOS has nothing to do with the clock.  Clock problems and LOS are two completely different operational problems.  Please see R6-52 of GR-253-CORE Issue 2.  LOS involves monitoring the line for null bit transitions so one can accurately predict whether or not a failure has occured that requires restoration.  The LOS needs to be as fast as possible and independent of the bit rate because the SONET (and the transport network in general) network, independent of bit-rate, has to restore failures before they impact the service layer; otherwise, massive network congestion will occur as all services try to reestrablish themselves at the same time (and the network operator is likely to have to report the outage to the FCC). 

this happens only in concanenated mode because when sub-multiplexed, (like
data on a VT1.5) the per-subcarrier SONET overhead bytes cause enough
transitions.  it doesn't happen with ATM because of SONET ATM framing and
the known max length of an ATM cell ensure sufficient transitions.

if we want to run a longer MTU, we need a longer polynomial.

Note that I don't think this requires changing the SONET spec.

it only requires that the POS spec specify that the POS data stream
(byte-stuffed HDLC, actually) is scrambled with another polynomial
before being presented to the SONET framer.
 

This is exactly what we are proposing. 

        -mo

Regards,

James

-------
James Sterling Manchester
Remember the MetroBus!
manchester@bell-labs.com

"It is futile to be amazed by the apparent paradox that leads thought to
its own negation by the opposite paths of humiliated reason and
triumphal reason."  -Albert Camus, "The Myth of Sisyphus," 1955.
  --------------1DC505FC4542CF8957C88F90-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Oct 17 10:12:44 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id KAA12132; Fri, 17 Oct 1997 10:11:15 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 17 Oct 1997 10:10:45 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA12114 for ietf-ppp-outgoing; Fri, 17 Oct 1997 10:10:44 -0400 (EDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm035-01.dialip.mich.net [141.211.7.12]) by merit.edu (8.8.7/8.8.5) with SMTP id KAA12103; Fri, 17 Oct 1997 10:10:31 -0400 (EDT) Date: Fri, 17 Oct 97 12:53:26 GMT From: "William Allen Simpson" Message-ID: <6696.wsimpson@greendragon.com> To: ietf-ppp@merit.edu Subject: scrambling PPP over SONET/SDH Sender: owner-ietf-ppp@merit.edu I've Bcc'd IESG from this series, as the steering liaison request is moot, but some seem interested in details. I combined several messages. > From: "(Brian E Carpenter)" > Seems totally absurd to fix a hardware design bug other than > by fixing the hardware. Good grief, even the HDLC designers > understood this one. > ! From: Harald.T.Alvestrand@uninett.no ! My deviousness-type brain seems to indicate also that the use of XOR ! shift registers rather than simple bit insertion was a design mistake ! in the SONET specification; inserting 2 flag bits every 2000 bits would ! have solved the problem completely, for all time, and for all possible ! payloads, at a cost of exactly 0.1% of the carrying capacity. ! ! Depending on the payload to provide transitions is a vulnerability, and ! will keep on being a vulnerability. ! ! But this is probably too late to change. ! Yes, the SONET specification is overly complicated, with variable everything and many unused fields, and it suffers from some pretty bad design choices. The "scrambler" that does not scramble is one of them. It always starts at 0xff on every section boundary, and increments in a predictable pattern. It does not check its output to see whether it is creating a string of zero bits. The (unpublished) internet-draft does NOT appear to fix this. But, it is too complicated to verify on a quick read. A true output dependent scrambler at the hardware level would have been a better idea. As you say, it is probably too late. Implementing the IETF suggested change 4-5 years ago would have fixed the problem, too, but they chose to ignore us. But, we could design a "simple subset" of SONET (as SSDH) with bug fixes, and deploy that in our routers. Anyone providing dark glass will not have a problem upgrading. All we want them for is their glass, not their switches. ! If this was to be fixed at the PPP layer, I would advocate simply ! inserting a "noise" byte for every 250 bytes of PPP packet data, for ! an overhead of 0.25%. ! @ From: Stuart Venters @ IMHO, the proposal in draft-pppsonet-scrambler-1 seems complex enough to @ lead to interoperability problems in itself. @ @ How about having the current 1619 transmitter look for the nasty sequence @ and sprinkle in extra escape sequences as required to keep Sonet happy? (Medium @ complexity but interoperable.) @ Yes, you and Harald have a similar idea. HDLC octet-stuffing allows an escape to be inserted at any time. The escape would be blindly inserted every 6 bytes, though, because of the bad chip with 70-bit failure. Better yet, the post scrambling output can be tested for 64 consecutive zero bits (very easy to test in hardware), and add an escape at that time. This is the solution that we arrived at on the PPPSDH list several years ago. I believe that this smart insertion was deployed by NetStar nee Ascend to successfully interoperate with Cisco (when Cisco used the bad chip with 70-bit failure). @ How about a simple self synchronizing scrambler over the SPE bytes? @ (Slower resync and easier but still not interoperable.) @ # From: Subhash Roy # Just a question why was the ATM over SONET/SDH scrambler X^43 + 1 not # proposed for PPP over SONET/SDH? # # Wouldn't this make this implementation simpler for devices # that need to support both mappings? # $ From: Thomas Skibo $ I'd be curious to know if the X^43+1 self-synchronizing polynomial $ used for ATM cell payload scrambling was considered. It's much $ simpler and wouldn't require mucking about with the path overhead $ bytes. It also syncs up a lot quicker than your proposal (6 bytes $ instead of several SONET frames). $ X**43 was good enough for the ATM cell because it starts on every cell, the cells do not align at any particular timing with the SPE (so the interaction with the section scrambler is unknown) and the cell data is only 48 bytes long. But x**43 still isn't perfect even for ATM, and _could_ allow a hit, just not as often. The problem is the "self-synchronizing" nature of the current section "scrambler". It does not really scramble anything, but is merely "security through obscurity". All of us in the security arena know this is a bad policy. Adding x**43 just modifies the well-known sequence, but does not change the problem for PPP payloads, which can be up to 1500 bytes long (by default). Anybody can figure out the new sequence, which will give you a hit every few thousand SPEs, the same as without it. Here's the current "killer" sequence. You will note that it is not a valid PPP HDLC frame, but that just reduces the hit rate by a small amount. I have not tested it, and recommend that you test it in your labs, but not over a Sprint backbone ;-) FE 04 18 51 E4 59 D4 FA 1C 49 B5 BD 8D 2E E6 55; FC 08 30 A3 C8 B3 A9 F4 38 93 6B 7B 1A 5D CC AB; F8 10 61 47 91 67 53 E8 71 26 D6 F6 34 BB 99 57; F0 20 C2 8F 22 CE A7 D0 E2 4D AD EC 69 77 32 AF; E0 41 85 1E 45 9D 4F A1 C4 9B 5B D8 D2 EE 65 5F; C0 83 0A 3C 8B 3A 9F 43 89 36 B7 B1 A5 DC CA BF; 81 06 14 79 16 75 3E 87 12 6D 6F 63 4B B9 95 7F; 02 0C 28 F2 2C EA 7D 0E 24 DA DE C6 97 73 2A; Presumably, the ones counterpart is: 01 FB E7 AE 1B A6 2B 05 E3 B6 4A 42 72 D1 19 AA; 03 F7 CF 5C 37 4C 56 0B C7 6C 94 84 E5 A2 33 54; 07 EF 9E B8 6E 98 AC 17 8E D9 29 09 CB 44 66 A8; 0F DF 3D 70 DD 31 58 2F 1D B2 52 13 96 88 CD 50; 1F BE 7A E1 BA 62 B0 5E 3B 64 A4 27 2D 11 9A A0; 3F 7C F5 C3 74 C5 60 BC 76 C9 48 4E 5A 23 35 40; 7E F9 EB 86 E9 8A C1 78 ED 92 90 9C B4 46 6A 80; FD F3 D7 0D D3 15 82 F1 DB 25 21 39 68 8C D5; WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Oct 17 10:39:36 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id KAA12675; Fri, 17 Oct 1997 10:38:07 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 17 Oct 1997 10:37:44 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA12641 for ietf-ppp-outgoing; Fri, 17 Oct 1997 10:37:43 -0400 (EDT) Received: from algw1.lucent.com (algw1.lucent.com [205.147.213.1]) by merit.edu (8.8.7/8.8.5) with SMTP id KAA12623 for ; Fri, 17 Oct 1997 10:37:37 -0400 (EDT) Cc: Fred Baker , wsimpson@greendragon.com, ietf-ppp@merit.edu, kris@hotair.hobl.lucent.com, iesg@ietf.org Received: from hotair.hobl.lucent.com by alig1.firewall.lucent.com (SMI-8.6/EMS-L sol2) id KAA26161; Fri, 17 Oct 1997 10:43:45 -0400 Received: from lucent.com (vermont.hobl.lucent.com) by hotair.hobl.lucent.com (4.1/EMS-L SunOS) id AA09515; Fri, 17 Oct 97 10:37:15 EDT Message-Id: <344778A1.46C12E35@lucent.com> Date: Fri, 17 Oct 1997 10:39:30 -0400 From: James Manchester Organization: Advanced Networking Technologies & Standards X-Mailer: Mozilla 4.02 [en] (X11; I; IRIX 6.3 IP32) Mime-Version: 1.0 To: brian@hursley.ibm.com Original-Cc: Fred Baker , wsimpson@greendragon.com, ietf-ppp@merit.edu, kris@hotair.hobl.lucent.com, iesg@ietf.org Subject: Re: ID - PPP over SONET/SDH References: <9710170905.AA95730@hursley.ibm.com> Content-Type: multipart/alternative; boundary="------------0C6648C396357D4E5891D794" Sender: owner-ietf-ppp@merit.edu --------------0C6648C396357D4E5891D794 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Brian, Fred, It was only a recommendation. Both of you are absolutely right, we can begin dialogue without formal liaisons. Regards, James ----- James Sterling Manchester Remember the MetroBus! manchester@bell-labs.com (Brian E Carpenter) wrote: > Fred, you and I are in violent agreement here. > Technical dialogue does not require formal liaison. > > Brian > > >- Fred Baker said: > > > > At 2:38 PM +0100 10/16/97, (Brian E Carpenter) wrote: > > >ANSI being a national standards body, and the IETF being > > >international, it is highly unlikely that you will see > > >a formal liaison. > > > > The point here is IMHO moot - ANSI feeds documents to ITU-T, who owns SDH, > > and we have a liaison with ITU-T. So what? > > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > "A beautiful idea has a much greater chance of being a correct idea > > than an ugly one." > > -- Roger Penrose, "The Emperor's New Mind", 1989 > > > > > > --------------0C6648C396357D4E5891D794 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Brian, Fred,

It was only a recommendation.  Both of you are absolutely right, we can begin dialogue without formal liaisons.

Regards,

James
 

-----
James Sterling Manchester
Remember the MetroBus!
manchester@bell-labs.com
 
 

(Brian E Carpenter) wrote:

Fred, you and I are in violent agreement here.
Technical dialogue does not require formal liaison.

  Brian

>- Fred Baker said:
>
> At 2:38 PM +0100 10/16/97, (Brian E Carpenter) wrote:
> >ANSI being a national standards body, and the IETF being
> >international, it is highly unlikely that you will see
> >a formal liaison.
>
> The point here is IMHO moot - ANSI feeds documents to ITU-T, who owns SDH,
> and we have a liaison with ITU-T. So what?
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>   "A beautiful idea has a much greater chance of being a correct idea
>    than an ugly one."
>                      -- Roger Penrose, "The Emperor's New Mind", 1989
>
>
>

 
  --------------0C6648C396357D4E5891D794-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Oct 17 11:50:07 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id LAA14043; Fri, 17 Oct 1997 11:48:46 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 17 Oct 1997 11:48:22 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id LAA14022 for ietf-ppp-outgoing; Fri, 17 Oct 1997 11:48:22 -0400 (EDT) Received: from cbgw1.lucent.com (cbgw1.lucent.com [207.24.196.51]) by merit.edu (8.8.7/8.8.5) with SMTP id LAA14018 for ; Fri, 17 Oct 1997 11:48:18 -0400 (EDT) Received: from hoserve.ho.lucent.com by cbig1.firewall.lucent.com (SMI-8.6/EMS-L sol2) id LAA29496; Fri, 17 Oct 1997 11:38:44 -0400 Received: by hoserve.ho.lucent.com (4.1/EMS-L SunOS) id AA09000; Fri, 17 Oct 97 11:41:08 EDT From: dravida@lucent.com (Subra Dravida) Received: from hopaw31.qcs (hopaw31.ho.lucent.com) by hoserve.ho.lucent.com (4.1/EMS-L SunOS) id AA08996; Fri, 17 Oct 97 11:41:06 EDT Received: by hopaw31.qcs (SMI-8.6/SMI-SVR4) id LAA13781; Fri, 17 Oct 1997 11:51:56 -0400 Date: Fri, 17 Oct 1997 11:51:56 -0400 Message-Id: <199710171551.LAA13781@hopaw31.qcs> Original-From: dravida@hoserve.ho.lucent.com (Subra Dravida) To: ietf-ppp@merit.edu Subject: re. scrambler Content-Type: text Sender: owner-ietf-ppp@merit.edu The general issues with self-synchronizing scramblers are that they create error multiplication. The 1+x**43 scrambler creates a correlated error 43 bits away from the original physical layer error. There are a number of reasons why error multiplication needs to be avoided. 1. Error multiplications messes up correction. Real time services like voice/video benefit from correction and error multiplication screws up correction. Error correction is also important for self-delineating protocols. The 1+x**43 was picked for ATM to avoid correlated errors in the ATM cell header (40 bits long) and then for reasons of self-delineation (acquiring packet boundaries based on header CRC) it was decided not to scramble the header - only the payloads are scrambled. 2. Error multiplication also meeses up detection - parity checks can become useless, the detection power of arithmetic checksums and CRCs is also reduced. 3. Different applications will have different protocol and header sizes - there is no point in being linked to the 1+x**43 created for ATM and this scrambler affects even ATM performance. There was a suggestion to introduce stuffing bits or bytes at the physical layer whenever a run of zeros or ones is observed (somewhat like byte stuffing/destuffing). In addition to implementational issues as we move from OC3 to OC12, OC48 and beyond, this introduces extra bits and bytes at the physical layer at random. The SONET payload envelope size keeps changing randomly (SPE has a fixed number of bytes per 125 microseconds) and is not a viable option. Subra Dravida dravida @lucent.com ------------------------------------------------- In article <9710152250.AA04077@hotair.hobl.lucent.com> you write: > >I have submitted an Internet Draft that >addresses the PPP/SONET interface defined in the RFC 1619. > I'd be curious to know if the X^43+1 self-synchronizing polynomial used for ATM cell payload scrambling was considered. It's much simpler and wouldn't require mucking about with the path overhead bytes. It also syncs up a lot quicker than your proposal (6 bytes instead of several SONET frames). -- Thomas Skibo Juniper Networks, Inc. --------------B2D906F58A0D4B6D538D3169-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Oct 17 11:40:14 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id LAA13876; Fri, 17 Oct 1997 11:38:27 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 17 Oct 1997 11:37:58 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id LAA13851 for ietf-ppp-outgoing; Fri, 17 Oct 1997 11:37:57 -0400 (EDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm054-16.dialip.mich.net [141.211.6.154]) by merit.edu (8.8.7/8.8.5) with SMTP id LAA13845; Fri, 17 Oct 1997 11:37:39 -0400 (EDT) Date: Fri, 17 Oct 97 14:55:50 GMT From: "William Allen Simpson" Message-ID: <6697.wsimpson@greendragon.com> To: ietf-ppp@merit.edu Cc: iesg@ietf.org Subject: liaison of IETF PPP over SONET/SDH Sender: owner-ietf-ppp@merit.edu > From: Fred Baker > At 2:38 PM +0100 10/16/97, (Brian E Carpenter) wrote: > >ANSI being a national standards body, and the IETF being > >international, it is highly unlikely that you will see > >a formal liaison. > > The point here is IMHO moot - ANSI feeds documents to ITU-T, who owns SDH, > and we have a liaison with ITU-T. So what? > Yes, I got a bit of a laugh out of this, too. Apparently, the reason that Bellcore ignored this problem when we raised it in March, 1993, was that IETF was not (in the written words of T1X1): "approved by a recognized standard setting organization." And the reason that this is all coming to the fore at this moment is that T1X1 had their quarterly meeting this week. And the Internet is suddenly an important source of money. T1X1 wants to have an interim meeting in December. I think this is a good idea. In fact, we are already having a meeting in December. So, we should invite T1X1 to come to our meeting for a joint BOF on this issue. Perhaps there is some time left on Friday morning? ==== On the "standards politics" side, the rumor is that a certain Very Large Vendor's chips could not meet the minimum clock recovery for Loss of Signal of 358 bits at OC3. Instead of fixing their chips, they "fixed" the standard to allow fewer bits.... And a certain Very Large Carrier wants to offer direct SONET as a tariffed option, at a higher tariff rate for an "enhanced service". But, they bought equipment from the Very Large Vendor, and it might reflect poorly on their performance. So, they'd rather get everyone else to change.... Our testing never detected this problem in the field, because: - we have such a large mix of packets on the backbone that it is almost impossible for this attack to succeed; - our circuits are mostly dedicated fiber between routers (they don't fall over to another circuit when attacked, and recover with loss of only 1 or 2 packets); - or our circuits are muxed into a Virtual Tributory (VT, a bit more than a VC) which is byte interleaved with other (voice) signals, and thus does not demonstrate the problem. As far as I can determine (I spent several hours on the phone yesterday), this attack is entirely theoretical. Nobody has demonstrated it on an inter-exchange carrier trunk. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Oct 17 11:54:06 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id LAA14133; Fri, 17 Oct 1997 11:52:45 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 17 Oct 1997 11:52:32 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id LAA14112 for ietf-ppp-outgoing; Fri, 17 Oct 1997 11:52:32 -0400 (EDT) Received: from adtrn722.adtran.com ([204.199.143.33]) by merit.edu (8.8.7/8.8.5) with SMTP id LAA14108 for ; Fri, 17 Oct 1997 11:52:28 -0400 (EDT) Message-Id: <199710171552.LAA14108@merit.edu> Received: by adtrn722.adtran.com (1.37.109.4/16.2) id AA11099; Fri, 17 Oct 97 10:24:24 -0500 From: Stuart Venters Subject: Re: ID - PPP over SONET/SDH To: ietf-ppp@merit.edu Date: Fri, 17 Oct 97 10:24:24 CDT Mailer: Elm [revision: 70.85] Sender: owner-ietf-ppp@merit.edu Greetings, I have been thinking about the failure mode overnight. There are two ways to upset the SONET channel. One is a shortage of transitions which leads to loss of bit sync and also loss of signal detection. The second is to send a sequence which causes a long term DC offset. Another thing is that the relative phase of the sonet scrambler to the payload cannot be known by the RFC-1619 encoder. This is because as the SPE travels through the network, the phase of the SPE can change with respect to the Sonet frame sync and hence the scrambler. For these reasons, I now think building a pattern detector to look for bad sequences would be more trouble than would be worth. This leaves at least three alternatives, a randon insertion of escape bytes, an externally synchronized SPE scrambler (the ID), and a self-synchronized SPE scrambler (like ATM perhaps with more bits). Assuming a scrambler is the best way to go, what is the advantage of choosing a scrambler which is externally synchronized instead of self-synchronized? Stuart Venters - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Oct 17 12:09:00 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id MAA14487; Fri, 17 Oct 1997 12:07:39 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 17 Oct 1997 12:07:30 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id MAA14465 for ietf-ppp-outgoing; Fri, 17 Oct 1997 12:07:29 -0400 (EDT) Received: from algw1.lucent.com (algw1.lucent.com [205.147.213.1]) by merit.edu (8.8.7/8.8.5) with SMTP id MAA14461 for ; Fri, 17 Oct 1997 12:07:25 -0400 (EDT) To: William Allen Simpson , ietf-ppp@merit.edu, iesg@ietf.org Received: from hotair.hobl.lucent.com by alig1.firewall.lucent.com (SMI-8.6/EMS-L sol2) id MAA18276; Fri, 17 Oct 1997 12:13:38 -0400 Received: from lucent.com (vermont.hobl.lucent.com) by hotair.hobl.lucent.com (4.1/EMS-L SunOS) id AA15436; Fri, 17 Oct 97 12:07:11 EDT Message-Id: <34478DB5.520C0EC0@lucent.com> Date: Fri, 17 Oct 1997 12:09:26 -0400 From: James Manchester Organization: Advanced Networking Technologies & Standards X-Mailer: Mozilla 4.02 [en] (X11; I; IRIX 6.3 IP32) Mime-Version: 1.0 Original-To: William Allen Simpson , ietf-ppp@merit.edu, iesg@ietf.org Subject: Re: liaison of IETF PPP over SONET/SDH References: <6697.wsimpson@greendragon.com> Content-Type: multipart/alternative; boundary="------------2697510F94F448A45C9C2543" Sender: owner-ietf-ppp@merit.edu --------------2697510F94F448A45C9C2543 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bill, We don't work on rumor and insinuation at Bell-Labs. Every single statement you made is false. Full stop. As Oscar Wilde said, "If you can't attack my arguments, consider calling me names." James ------ James Sterling Manchester Remember the MetroBus! manchester@bell-labs.com "It is futile to be amazed by the apparent paradox that leads thought to its own negation by the opposite paths of humiliated reason and triumphal reason." -Albert Camus, "The Myth of Sisyphus," 1955. William Allen Simpson wrote: > > From: Fred Baker > > At 2:38 PM +0100 10/16/97, (Brian E Carpenter) wrote: > > >ANSI being a national standards body, and the IETF being > > >international, it is highly unlikely that you will see > > >a formal liaison. > > > > The point here is IMHO moot - ANSI feeds documents to ITU-T, who owns SDH, > > and we have a liaison with ITU-T. So what? > > > Yes, I got a bit of a laugh out of this, too. > > Apparently, the reason that Bellcore ignored this problem when we raised > it in March, 1993, was that IETF was not (in the written words of T1X1): > "approved by a recognized standard setting organization." > > And the reason that this is all coming to the fore at this moment is > that T1X1 had their quarterly meeting this week. And the Internet is > suddenly an important source of money. > > T1X1 wants to have an interim meeting in December. I think this is a > good idea. In fact, we are already having a meeting in December. So, > we should invite T1X1 to come to our meeting for a joint BOF on this > issue. Perhaps there is some time left on Friday morning? > > ==== > > On the "standards politics" side, the rumor is that a certain Very Large > Vendor's chips could not meet the minimum clock recovery for Loss of > Signal of 358 bits at OC3. Instead of fixing their chips, they "fixed" > the standard to allow fewer bits.... > > And a certain Very Large Carrier wants to offer direct SONET as a > tariffed option, at a higher tariff rate for an "enhanced service". > But, they bought equipment from the Very Large Vendor, and it might > reflect poorly on their performance. So, they'd rather get everyone > else to change.... > > Our testing never detected this problem in the field, because: > > - we have such a large mix of packets on the backbone that it is almost > impossible for this attack to succeed; > > - our circuits are mostly dedicated fiber between routers (they don't > fall over to another circuit when attacked, and recover with loss of > only 1 or 2 packets); > > - or our circuits are muxed into a Virtual Tributory (VT, a bit more > than a VC) which is byte interleaved with other (voice) signals, and > thus does not demonstrate the problem. > > As far as I can determine (I spent several hours on the phone yesterday), > this attack is entirely theoretical. Nobody has demonstrated it on an > inter-exchange carrier trunk. > > WSimpson@UMich.edu > Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 -- James Sterling Manchester manchester@lucent.com --------------2697510F94F448A45C9C2543 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Bill,

We don't work on rumor and insinuation at Bell-Labs.  Every single statement you made is false.  Full stop.

As Oscar Wilde said, "If you can't attack my arguments, consider calling me names."

James
 

------
James Sterling Manchester
Remember the MetroBus!
manchester@bell-labs.com

"It is futile to be amazed by the apparent paradox that leads thought to
its own negation by the opposite paths of humiliated reason and
triumphal reason."  -Albert Camus, "The Myth of Sisyphus," 1955.

William Allen Simpson wrote:

> From: Fred Baker <fred@cisco.com>
> At 2:38 PM +0100 10/16/97, (Brian E Carpenter) wrote:
> >ANSI being a national standards body, and the IETF being
> >international, it is highly unlikely that you will see
> >a formal liaison.
>
> The point here is IMHO moot - ANSI feeds documents to ITU-T, who owns SDH,
> and we have a liaison with ITU-T. So what?
>
Yes, I got a bit of a laugh out of this, too.

Apparently, the reason that Bellcore ignored this problem when we raised
it in March, 1993, was that IETF was not (in the written words of T1X1):
"approved by a recognized standard setting organization."

And the reason that this is all coming to the fore at this moment is
that T1X1 had their quarterly meeting this week.  And the Internet is
suddenly an important source of money.

T1X1 wants to have an interim meeting in December.  I think this is a
good idea.  In fact, we are already having a meeting in December.  So,
we should invite T1X1 to come to our meeting for a joint BOF on this
issue.  Perhaps there is some time left on Friday morning?

                                ====

On the "standards politics" side, the rumor is that a certain Very Large
Vendor's chips could not meet the minimum clock recovery for Loss of
Signal of 358 bits at OC3.  Instead of fixing their chips, they "fixed"
the standard to allow fewer bits....

And a certain Very Large Carrier wants to offer direct SONET as a
tariffed option, at a higher tariff rate for an "enhanced service".
But, they bought equipment from the Very Large Vendor, and it might
reflect poorly on their performance.  So, they'd rather get everyone
else to change....

Our testing never detected this problem in the field, because:

 - we have such a large mix of packets on the backbone that it is almost
   impossible for this attack to succeed;

 - our circuits are mostly dedicated fiber between routers (they don't
   fall over to another circuit when attacked, and recover with loss of
   only 1 or 2 packets);

 - or our circuits are muxed into a Virtual Tributory (VT, a bit more
   than a VC) which is byte interleaved with other (voice) signals, and
   thus does not demonstrate the problem.

As far as I can determine (I spent several hours on the phone yesterday),
this attack is entirely theoretical.  Nobody has demonstrated it on an
inter-exchange carrier trunk.

WSimpson@UMich.edu
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32

 
-- 
James Sterling Manchester
manchester@lucent.com
  --------------2697510F94F448A45C9C2543-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Oct 17 12:02:09 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id MAA14334; Fri, 17 Oct 1997 12:00:46 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 17 Oct 1997 11:59:53 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id LAA14293 for ietf-ppp-outgoing; Fri, 17 Oct 1997 11:59:53 -0400 (EDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm002-26.dialip.mich.net [141.211.7.162]) by merit.edu (8.8.7/8.8.5) with SMTP id LAA14281; Fri, 17 Oct 1997 11:59:33 -0400 (EDT) Date: Fri, 17 Oct 97 15:44:58 GMT From: "William Allen Simpson" Message-ID: <6698.wsimpson@greendragon.com> To: ietf-ppp@merit.edu Subject: Re: scrambling PPP over SONET/SDH Sender: owner-ietf-ppp@merit.edu This is probably horribly cheeky of me, but I just went and checked my copy of SONET. The run of zero bits is only a problem when "line timing" is used; that is, the timing is derived from the incoming OC-N signal. But the requirements clearly state (5.4.2.1) "... external timing from a BITS clock is the preferred mode of synchronizing SONET NEs." So, the theoretical problem is that some folks didn't follow the SONET recommendation. Why should we design around bad implementations? WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Oct 17 12:32:09 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id MAA14962; Fri, 17 Oct 1997 12:30:45 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 17 Oct 1997 12:30:29 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id MAA14938 for ietf-ppp-outgoing; Fri, 17 Oct 1997 12:30:28 -0400 (EDT) Received: from doberman.cisco.com (doberman.cisco.com [171.69.1.178]) by merit.edu (8.8.7/8.8.5) with SMTP id MAA14934 for ; Fri, 17 Oct 1997 12:30:24 -0400 (EDT) Received: from fred-axel-fr.cisco.com (fred-axel-fr.cisco.com [171.69.128.115]) by doberman.cisco.com (8.6.12/8.6.5) with ESMTP id JAA18260; Fri, 17 Oct 1997 09:29:53 -0700 Received: from [171.69.128.118] (fred-hm-dhcp3.cisco.com [171.69.128.118]) by fred-axel-fr.cisco.com (8.6.8+c/CISCO.WS.1.1) with ESMTP id JAA06118; Fri, 17 Oct 1997 09:29:51 -0700 X-Sender: fred@stilton.cisco.com Message-Id: In-Reply-To: <6696.wsimpson@greendragon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 17 Oct 1997 09:06:34 -0700 To: "William Allen Simpson" From: Fred Baker Subject: Re: scrambling PPP over SONET/SDH Cc: ietf-ppp@merit.edu Sender: owner-ietf-ppp@merit.edu >But, we could design a "simple subset" of SONET (as SSDH) with bug >fixes, and deploy that in our routers. Anyone providing dark glass will >not have a problem upgrading. All we want them for is their glass, not >their switches. unfortunately, that's not entirely true. What happens when we==them? In Lucent's case, they would perhaps like to provide both peices of equipment. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "A beautiful idea has a much greater chance of being a correct idea than an ugly one." -- Roger Penrose, "The Emperor's New Mind", 1989 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Oct 17 12:32:26 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id MAA14992; Fri, 17 Oct 1997 12:31:05 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 17 Oct 1997 12:30:52 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id MAA14971 for ietf-ppp-outgoing; Fri, 17 Oct 1997 12:30:51 -0400 (EDT) Received: from pitbull.cisco.com (pitbull.cisco.com [171.69.223.73]) by merit.edu (8.8.7/8.8.5) with SMTP id MAA14965 for ; Fri, 17 Oct 1997 12:30:46 -0400 (EDT) Received: from fred-axel-fr.cisco.com (fred-axel-fr.cisco.com [171.69.128.115]) by pitbull.cisco.com (8.6.12/8.6.5) with ESMTP id JAA25201; Fri, 17 Oct 1997 09:29:43 -0700 Received: from [171.69.128.118] (fred-hm-dhcp3.cisco.com [171.69.128.118]) by fred-axel-fr.cisco.com (8.6.8+c/CISCO.WS.1.1) with ESMTP id JAA06115; Fri, 17 Oct 1997 09:29:41 -0700 X-Sender: fred@stilton.cisco.com Message-Id: In-Reply-To: <2585.877083235@dale.uninett.no> References: Your message of "Thu, 16 Oct 1997 14:09:50 EDT." <9710161809.AA03502@hotair.hobl.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 17 Oct 1997 09:00:08 -0700 To: Harald.T.Alvestrand@uninett.no From: Fred Baker Subject: Re: ID - PPP over SONET/SDH Cc: kris , ietf-ppp@merit.edu, iesg@ietf.org Sender: owner-ietf-ppp@merit.edu At 12:13 PM +0200 10/17/97, Harald.T.Alvestrand@uninett.no wrote: >If this was to be fixed at the PPP layer, I would advocate simply >inserting a "noise" byte for every 250 bytes of PPP packet data, for >an overhead of 0.25%. that's a very interesting suggestion. I suspect the SONET folks figured a predictable XOR took less bits away from the payload than a predictable insertion. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "A beautiful idea has a much greater chance of being a correct idea than an ugly one." -- Roger Penrose, "The Emperor's New Mind", 1989 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Oct 17 13:13:07 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id NAA15750; Fri, 17 Oct 1997 13:11:45 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 17 Oct 1997 13:11:37 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id NAA15732 for ietf-ppp-outgoing; Fri, 17 Oct 1997 13:11:37 -0400 (EDT) Received: from cbgw1.lucent.com (cbgw1.lucent.com [207.24.196.51]) by merit.edu (8.8.7/8.8.5) with SMTP id NAA15728 for ; Fri, 17 Oct 1997 13:11:33 -0400 (EDT) Received: from hoserve.ho.lucent.com by cbig1.firewall.lucent.com (SMI-8.6/EMS-L sol2) id NAA06229; Fri, 17 Oct 1997 13:02:00 -0400 Received: by hoserve.ho.lucent.com (4.1/EMS-L SunOS) id AA10509; Fri, 17 Oct 97 13:04:24 EDT From: dravida@lucent.com (Subra Dravida) Received: from hopaw31.qcs (hopaw31.ho.lucent.com) by hoserve.ho.lucent.com (4.1/EMS-L SunOS) id AA10505; Fri, 17 Oct 97 13:04:22 EDT Received: by hopaw31.qcs (SMI-8.6/SMI-SVR4) id NAA13894; Fri, 17 Oct 1997 13:15:13 -0400 Date: Fri, 17 Oct 1997 13:15:13 -0400 Message-Id: <199710171715.NAA13894@hopaw31.qcs> Original-From: dravida@hoserve.ho.lucent.com (Subra Dravida) To: ietf-ppp@merit.edu Subject: re. scrambler Content-Type: text Sender: owner-ietf-ppp@merit.edu The general issues with self-synchronizing scramblers are that they create error multiplication. The 1+x**43 scrambler creates a correlated error 43 bits away from the original physical layer error. There are a number of reasons why error multiplication needs to be avoided. 1. Error multiplications messes up correction. Real time services like voice/video benefit from correction and error multiplication screws up correction. Error correction is also important for self-delineating protocols. The 1+x**43 was picked for ATM to avoid correlated errors in the ATM cell header (40 bits long) and then for reasons of self-delineation (acquiring packet boundaries based on header CRC) it was decided not to scramble the header - only the payloads are scrambled. 2. Error multiplication also meeses up detection - parity checks can become useless, the detection power of arithmetic checksums and CRCs is also reduced. 3. Different applications will have different protocol and header sizes - there is no point in being linked to the 1+x**43 created for ATM and this scrambler affects even ATM performance. There was a suggestion to introduce stuffing bits or bytes at the physical layer whenever a run of zeros or ones is observed (somewhat like byte stuffing/destuffing). In addition to implementational issues as we move from OC3 to OC12, OC48 and beyond, this introduces extra bits and bytes at the physical layer at random. The SONET payload envelope size keeps changing randomly (SPE has a fixed number of bytes per 125 microseconds) and is not a viable option. Subra Dravida dravida @lucent.com ------------------------------------------------- In article <9710152250.AA04077@hotair.hobl.lucent.com> you write: > >I have submitted an Internet Draft that >addresses the PPP/SONET interface defined in the RFC 1619. > I'd be curious to know if the X^43+1 self-synchronizing polynomial used for ATM cell payload scrambling was considered. It's much simpler and wouldn't require mucking about with the path overhead bytes. It also syncs up a lot quicker than your proposal (6 bytes instead of several SONET frames). -- Thomas Skibo Juniper Networks, Inc. --------------B2D906F58A0D4B6D538D3169-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Oct 17 12:12:09 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id MAA14578; Fri, 17 Oct 1997 12:10:47 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 17 Oct 1997 12:10:28 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id MAA14552 for ietf-ppp-outgoing; Fri, 17 Oct 1997 12:10:28 -0400 (EDT) Received: from algw1.lucent.com (algw1.lucent.com [205.147.213.1]) by merit.edu (8.8.7/8.8.5) with SMTP id MAA14548 for ; Fri, 17 Oct 1997 12:10:23 -0400 (EDT) To: "iesg@ietf.org" , "ietf-ppp@merit.edu" Received: from hotair.hobl.lucent.com by alig1.firewall.lucent.com (SMI-8.6/EMS-L sol2) id MAA20708; Fri, 17 Oct 1997 12:16:35 -0400 Received: from lucent.com (vermont.hobl.lucent.com) by hotair.hobl.lucent.com (4.1/EMS-L SunOS) id AA15597; Fri, 17 Oct 97 12:10:05 EDT Message-Id: <34478E63.69262F76@lucent.com> Date: Fri, 17 Oct 1997 12:12:19 -0400 From: James Manchester Organization: Advanced Networking Technologies & Standards X-Mailer: Mozilla 4.02 [en] (X11; I; IRIX 6.3 IP32) Mime-Version: 1.0 Original-To: "iesg@ietf.org" , "ietf-ppp@merit.edu" Subject: [Fwd: scrambling PPP over SONET/SDH] Content-Type: multipart/mixed; boundary="------------716EA5E1D5654A4F8B925925" Sender: owner-ietf-ppp@merit.edu This is a multi-part message in MIME format. --------------716EA5E1D5654A4F8B925925 Content-Type: multipart/alternative; boundary="------------EB7587A6BEFE419F5673C2A5" --------------EB7587A6BEFE419F5673C2A5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------EB7587A6BEFE419F5673C2A5 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

 

--------------EB7587A6BEFE419F5673C2A5--

--------------716EA5E1D5654A4F8B925925
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Return-Path: 
Received: by hotair.hobl.lucent.com (4.1/EMS-L SunOS)
	id AA12705; Fri, 17 Oct 97 11:21:43 EDT
Received: from lucent.com (vermont.hobl.lucent.com) by hotair.hobl.lucent.com (4.1/EMS-L SunOS)
	id AA12693; Fri, 17 Oct 97 11:21:38 EDT
Sender: sterling@lucent.com
Message-Id: <34478308.FEBEA912@lucent.com>
Date: Fri, 17 Oct 1997 11:23:53 -0400
From: James Manchester 
Organization: Advanced Networking Technologies & Standards
X-Mailer: Mozilla 4.02 [en] (X11; I; IRIX 6.3 IP32)
Mime-Version: 1.0
To: William Allen Simpson 
Subject: Re: scrambling PPP over SONET/SDH
References: <6696.wsimpson@greendragon.com>
Content-Type: multipart/alternative; boundary="------------95E2E4B018F23C02EDD7FF24"


--------------95E2E4B018F23C02EDD7FF24
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bill,

No wonder you couldn't validate the problem, that is not the right sequence.  Which
just goes to show that you really don't understand SONET.  Anyone who wants to, can
come to Holmdel and we will show you our code.

All of the stuff you are putting out on SONET is complete crap.

The internet draft. which is published now, is a easy read if you understand SONET.
BTW, if you spent five minutes reading the ID, you would already know that you put
out the wrong code.

You still fail to show proof that the IETF contacted anyone handling SONET standards
about this problem.  In addition, what you have talked about, using an enhanced
clock, does nothing to solve the problem.  Stop trying to turn this into a turf
battle.

BTW, G.707, G.708, and G.709 defined SDH and were approved in 1988.  The latest
issue of GR-253-CORE is Issue 2, 1995.  The latest issues of the T1.105 series came
out in 1995 also.  You edited a SONET specification without understanding SONET and
without the SONET specifications.  That is quite obvious and quite irresponsible on
your part.  Everyone knows, and has known in the SONET world that data mappings to
concatenated signals require scrambling.  This was known as early as 1988.  Perhaps
you would like to talk to Bill Edwards (texas@sprintcorp.com) at Sprint and tell him
who is going to be responsible for cleaning up their network.  You already admitted
that you knew that there might be a problem but your lack of SONET expertise
prevented you from verifying it so you went ahead anyway.  This despite the
knowledge by the rest of the industry that data mappings to concatenated interfaces
require scrambling.  The SONET scrambler was designed meticulously for optical
transmission of binary signals.  It works very well.  What about the vendor's that
implemented the flawed mapping.  No supplier should be held responsible for
complying with standards and in fact in many countries, compliance with a
specification (be it RFC or otherwise) is required by law.  What recourse does a
supplier have for lost development?  A mistake like you made in this situation can
easily have caused a small supplier to go out of business.

This is not about other vendor's.  This is not about SONET.  This is about a poorly
specified specification.


Sua Sponte,

James

------
James Sterling Manchester
Remember the MetroBus!
manchester@bell-labs.com

"It is futile to be amazed by the apparent paradox that leads thought to
its own negation by the opposite paths of humiliated reason and
triumphal reason."  -Albert Camus, "The Myth of Sisyphus," 1955.



William Allen Simpson wrote:

> I've Bcc'd IESG from this series, as the steering liaison request is moot,
> but some seem interested in details.  I combined several messages.
>
> > From: "(Brian E Carpenter)" 
> > Seems totally absurd to fix a hardware design bug other than
> > by fixing the hardware. Good grief, even the HDLC designers
> > understood this one.
> >
> ! From: Harald.T.Alvestrand@uninett.no
> ! My deviousness-type brain seems to indicate also that the use of XOR
> ! shift registers rather than simple bit insertion was a design mistake
> ! in the SONET specification; inserting 2 flag bits every 2000 bits would
> ! have solved the problem completely, for all time, and for all possible
> ! payloads, at a cost of exactly 0.1% of the carrying capacity.
> !
> ! Depending on the payload to provide transitions is a vulnerability, and
> ! will keep on being a vulnerability.
> !
> ! But this is probably too late to change.
> !
> Yes, the SONET specification is overly complicated, with variable
> everything and many unused fields, and it suffers from some pretty bad
> design choices.
>
> The "scrambler" that does not scramble is one of them.  It always starts
> at 0xff on every section boundary, and increments in a predictable
> pattern.  It does not check its output to see whether it is creating a
> string of zero bits.
>
> The (unpublished) internet-draft does NOT appear to fix this.  But, it
> is too complicated to verify on a quick read.
>
> A true output dependent scrambler at the hardware level would have been
> a better idea.  As you say, it is probably too late.
>
> Implementing the IETF suggested change 4-5 years ago would have fixed
> the problem, too, but they chose to ignore us.
>
> But, we could design a "simple subset" of SONET (as SSDH) with bug
> fixes, and deploy that in our routers.  Anyone providing dark glass will
> not have a problem upgrading.  All we want them for is their glass, not
> their switches.
>
> ! If this was to be fixed at the PPP layer, I would advocate simply
> ! inserting a "noise" byte for every 250 bytes of PPP packet data, for
> ! an overhead of 0.25%.
> !
> @ From: Stuart Venters 
> @ IMHO, the proposal in draft-pppsonet-scrambler-1 seems complex enough to
> @ lead to interoperability problems in itself.
> @
> @ How about having the current 1619 transmitter look for the nasty sequence
> @ and sprinkle in extra escape sequences as required to keep Sonet happy? (Medium
> @ complexity but interoperable.)
> @
> Yes, you and Harald have a similar idea.  HDLC octet-stuffing allows an
> escape to be inserted at any time.  The escape would be blindly inserted
> every 6 bytes, though, because of the bad chip with 70-bit failure.
>
> Better yet, the post scrambling output can be tested for 64 consecutive
> zero bits (very easy to test in hardware), and add an escape at that
> time.  This is the solution that we arrived at on the PPPSDH list
> several years ago.
>
> I believe that this smart insertion was deployed by NetStar nee Ascend
> to successfully interoperate with Cisco (when Cisco used the bad chip
> with 70-bit failure).
>
> @ How about a simple self synchronizing scrambler over the SPE bytes?
> @ (Slower resync and easier but still not interoperable.)
> @
> # From: Subhash Roy 
> # Just a question why was the ATM over SONET/SDH scrambler X^43 + 1 not
> # proposed for PPP over SONET/SDH?
> #
> # Wouldn't this make this implementation simpler for devices
> # that need to support both mappings?
> #
> $ From: Thomas Skibo 
> $ I'd be curious to know if the X^43+1 self-synchronizing polynomial
> $ used for ATM cell payload scrambling was considered.  It's much
> $ simpler and wouldn't require mucking about with the path overhead
> $ bytes.  It also syncs up a lot quicker than your proposal (6 bytes
> $ instead of several SONET frames).
> $
> X**43 was good enough for the ATM cell because it starts on every cell,
> the cells do not align at any particular timing with the SPE (so the
> interaction with the section scrambler is unknown) and the cell data is
> only 48 bytes long.  But x**43 still isn't perfect even for ATM, and
> _could_ allow a hit, just not as often.
>
> The problem is the "self-synchronizing" nature of the current section
> "scrambler".  It does not really scramble anything, but is merely
> "security through obscurity".  All of us in the security arena know this
> is a bad policy.
>
> Adding x**43 just modifies the well-known sequence, but does not change
> the problem for PPP payloads, which can be up to 1500 bytes long (by
> default).  Anybody can figure out the new sequence, which will give you
> a hit every few thousand SPEs, the same as without it.
>
> Here's the current "killer" sequence.  You will note that it is not a
> valid PPP HDLC frame, but that just reduces the hit rate by a small
> amount.  I have not tested it, and recommend that you test it in your
> labs, but not over a Sprint backbone ;-)
>
>     FE 04 18 51 E4 59 D4 FA 1C 49 B5 BD 8D 2E E6 55;
>     FC 08 30 A3 C8 B3 A9 F4 38 93 6B 7B 1A 5D CC AB;
>     F8 10 61 47 91 67 53 E8 71 26 D6 F6 34 BB 99 57;
>     F0 20 C2 8F 22 CE A7 D0 E2 4D AD EC 69 77 32 AF;
>     E0 41 85 1E 45 9D 4F A1 C4 9B 5B D8 D2 EE 65 5F;
>     C0 83 0A 3C 8B 3A 9F 43 89 36 B7 B1 A5 DC CA BF;
>     81 06 14 79 16 75 3E 87 12 6D 6F 63 4B B9 95 7F;
>     02 0C 28 F2 2C EA 7D 0E 24 DA DE C6 97 73 2A;
>
> Presumably, the ones counterpart is:
>
>     01 FB E7 AE 1B A6 2B 05 E3 B6 4A 42 72 D1 19 AA;
>     03 F7 CF 5C 37 4C 56 0B C7 6C 94 84 E5 A2 33 54;
>     07 EF 9E B8 6E 98 AC 17 8E D9 29 09 CB 44 66 A8;
>     0F DF 3D 70 DD 31 58 2F 1D B2 52 13 96 88 CD 50;
>     1F BE 7A E1 BA 62 B0 5E 3B 64 A4 27 2D 11 9A A0;
>     3F 7C F5 C3 74 C5 60 BC 76 C9 48 4E 5A 23 35 40;
>     7E F9 EB 86 E9 8A C1 78 ED 92 90 9C B4 46 6A 80;
>     FD F3 D7 0D D3 15 82 F1 DB 25 21 39 68 8C D5;
>
> WSimpson@UMich.edu
>     Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32



--------------95E2E4B018F23C02EDD7FF24
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit


Bill,

No wonder you couldn't validate the problem, that is not the right sequence.  Which just goes to show that you really don't understand SONET.  Anyone who wants to, can come to Holmdel and we will show you our code.

All of the stuff you are putting out on SONET is complete crap.

The internet draft. which is published now, is a easy read if you understand SONET.  BTW, if you spent five minutes reading the ID, you would already know that you put out the wrong code.

You still fail to show proof that the IETF contacted anyone handling SONET standards about this problem.  In addition, what you have talked about, using an enhanced clock, does nothing to solve the problem.  Stop trying to turn this into a turf battle.

BTW, G.707, G.708, and G.709 defined SDH and were approved in 1988.  The latest issue of GR-253-CORE is Issue 2, 1995.  The latest issues of the T1.105 series came out in 1995 also.  You edited a SONET specification without understanding SONET and without the SONET specifications.  That is quite obvious and quite irresponsible on your part.  Everyone knows, and has known in the SONET world that data mappings to concatenated signals require scrambling.  This was known as early as 1988.  Perhaps you would like to talk to Bill Edwards (texas@sprintcorp.com) at Sprint and tell him who is going to be responsible for cleaning up their network.  You already admitted that you knew that there might be a problem but your lack of SONET expertise prevented you from verifying it so you went ahead anyway.  This despite the knowledge by the rest of the industry that data mappings to concatenated interfaces require scrambling.  The SONET scrambler was designed meticulously for optical transmission of binary signals.  It works very well.  What about the vendor's that implemented the flawed mapping.  No supplier should be held responsible for complying with standards and in fact in many countries, compliance with a specification (be it RFC or otherwise) is required by law.  What recourse does a supplier have for lost development?  A mistake like you made in this situation can easily have caused a small supplier to go out of business.

This is not about other vendor's.  This is not about SONET.  This is about a poorly specified specification.
 

Sua Sponte,

James

------
James Sterling Manchester
Remember the MetroBus!
manchester@bell-labs.com

"It is futile to be amazed by the apparent paradox that leads thought to
its own negation by the opposite paths of humiliated reason and
triumphal reason."  -Albert Camus, "The Myth of Sisyphus," 1955.
 
 

William Allen Simpson wrote:

I've Bcc'd IESG from this series, as the steering liaison request is moot,
but some seem interested in details.  I combined several messages.

> From: "(Brian E Carpenter)" <brian@hursley.ibm.com>
> Seems totally absurd to fix a hardware design bug other than
> by fixing the hardware. Good grief, even the HDLC designers
> understood this one.
>
! From: Harald.T.Alvestrand@uninett.no
! My deviousness-type brain seems to indicate also that the use of XOR
! shift registers rather than simple bit insertion was a design mistake
! in the SONET specification; inserting 2 flag bits every 2000 bits would
! have solved the problem completely, for all time, and for all possible
! payloads, at a cost of exactly 0.1% of the carrying capacity.
!
! Depending on the payload to provide transitions is a vulnerability, and
! will keep on being a vulnerability.
!
! But this is probably too late to change.
!
Yes, the SONET specification is overly complicated, with variable
everything and many unused fields, and it suffers from some pretty bad
design choices.

The "scrambler" that does not scramble is one of them.  It always starts
at 0xff on every section boundary, and increments in a predictable
pattern.  It does not check its output to see whether it is creating a
string of zero bits.

The (unpublished) internet-draft does NOT appear to fix this.  But, it
is too complicated to verify on a quick read.

A true output dependent scrambler at the hardware level would have been
a better idea.  As you say, it is probably too late.

Implementing the IETF suggested change 4-5 years ago would have fixed
the problem, too, but they chose to ignore us.

But, we could design a "simple subset" of SONET (as SSDH) with bug
fixes, and deploy that in our routers.  Anyone providing dark glass will
not have a problem upgrading.  All we want them for is their glass, not
their switches.

! If this was to be fixed at the PPP layer, I would advocate simply
! inserting a "noise" byte for every 250 bytes of PPP packet data, for
! an overhead of 0.25%.
!
@ From: Stuart Venters <sventers@adtran.com>
@ IMHO, the proposal in draft-pppsonet-scrambler-1 seems complex enough to
@ lead to interoperability problems in itself.
@
@ How about having the current 1619 transmitter look for the nasty sequence
@ and sprinkle in extra escape sequences as required to keep Sonet happy? (Medium
@ complexity but interoperable.)
@
Yes, you and Harald have a similar idea.  HDLC octet-stuffing allows an
escape to be inserted at any time.  The escape would be blindly inserted
every 6 bytes, though, because of the bad chip with 70-bit failure.

Better yet, the post scrambling output can be tested for 64 consecutive
zero bits (very easy to test in hardware), and add an escape at that
time.  This is the solution that we arrived at on the PPPSDH list
several years ago.

I believe that this smart insertion was deployed by NetStar nee Ascend
to successfully interoperate with Cisco (when Cisco used the bad chip
with 70-bit failure).

@ How about a simple self synchronizing scrambler over the SPE bytes?
@ (Slower resync and easier but still not interoperable.)
@
# From: Subhash Roy <roy@txc.com>
# Just a question why was the ATM over SONET/SDH scrambler X^43 + 1 not
# proposed for PPP over SONET/SDH?
#
# Wouldn't this make this implementation simpler for devices
# that need to support both mappings?
#
$ From: Thomas Skibo <skibo@juniper.net>
$ I'd be curious to know if the X^43+1 self-synchronizing polynomial
$ used for ATM cell payload scrambling was considered.  It's much
$ simpler and wouldn't require mucking about with the path overhead
$ bytes.  It also syncs up a lot quicker than your proposal (6 bytes
$ instead of several SONET frames).
$
X**43 was good enough for the ATM cell because it starts on every cell,
the cells do not align at any particular timing with the SPE (so the
interaction with the section scrambler is unknown) and the cell data is
only 48 bytes long.  But x**43 still isn't perfect even for ATM, and
_could_ allow a hit, just not as often.

The problem is the "self-synchronizing" nature of the current section
"scrambler".  It does not really scramble anything, but is merely
"security through obscurity".  All of us in the security arena know this
is a bad policy.

Adding x**43 just modifies the well-known sequence, but does not change
the problem for PPP payloads, which can be up to 1500 bytes long (by
default).  Anybody can figure out the new sequence, which will give you
a hit every few thousand SPEs, the same as without it.

Here's the current "killer" sequence.  You will note that it is not a
valid PPP HDLC frame, but that just reduces the hit rate by a small
amount.  I have not tested it, and recommend that you test it in your
labs, but not over a Sprint backbone ;-)

    FE 04 18 51 E4 59 D4 FA 1C 49 B5 BD 8D 2E E6 55;
    FC 08 30 A3 C8 B3 A9 F4 38 93 6B 7B 1A 5D CC AB;
    F8 10 61 47 91 67 53 E8 71 26 D6 F6 34 BB 99 57;
    F0 20 C2 8F 22 CE A7 D0 E2 4D AD EC 69 77 32 AF;
    E0 41 85 1E 45 9D 4F A1 C4 9B 5B D8 D2 EE 65 5F;
    C0 83 0A 3C 8B 3A 9F 43 89 36 B7 B1 A5 DC CA BF;
    81 06 14 79 16 75 3E 87 12 6D 6F 63 4B B9 95 7F;
    02 0C 28 F2 2C EA 7D 0E 24 DA DE C6 97 73 2A;

Presumably, the ones counterpart is:

    01 FB E7 AE 1B A6 2B 05 E3 B6 4A 42 72 D1 19 AA;
    03 F7 CF 5C 37 4C 56 0B C7 6C 94 84 E5 A2 33 54;
    07 EF 9E B8 6E 98 AC 17 8E D9 29 09 CB 44 66 A8;
    0F DF 3D 70 DD 31 58 2F 1D B2 52 13 96 88 CD 50;
    1F BE 7A E1 BA 62 B0 5E 3B 64 A4 27 2D 11 9A A0;
    3F 7C F5 C3 74 C5 60 BC 76 C9 48 4E 5A 23 35 40;
    7E F9 EB 86 E9 8A C1 78 ED 92 90 9C B4 46 6A 80;
    FD F3 D7 0D D3 15 82 F1 DB 25 21 39 68 8C D5;

WSimpson@UMich.edu
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32


 

--------------95E2E4B018F23C02EDD7FF24--


--------------716EA5E1D5654A4F8B925925--

- - - - - - - - - - - - - - - - -

From owner-ietf-ppp@merit.edu  Fri Oct 17 13:42:12 1997
Received: from localhost (daemon@localhost)
	by merit.edu (8.8.7/8.8.5) with SMTP id NAA16336;
	Fri, 17 Oct 1997 13:40:49 -0400 (EDT)
Received: by merit.edu (bulk_mailer v1.5); Fri, 17 Oct 1997 13:40:33 -0400
Received: (from majordom@localhost)
	by merit.edu (8.8.7/8.8.5) id NAA16318
	for ietf-ppp-outgoing; Fri, 17 Oct 1997 13:40:32 -0400 (EDT)
Received: from relay1.UU.NET (relay1.UU.NET [192.48.96.5])
	by merit.edu (8.8.7/8.8.5) with ESMTP id NAA16314
	for ; Fri, 17 Oct 1997 13:40:28 -0400 (EDT)
Received: from rodan.UU.NET by relay1.UU.NET with ESMTP 
	(peer crosschecked as: rodan.UU.NET [153.39.130.10])
	id QQdlri03113; Fri, 17 Oct 1997 13:40:38 -0400 (EDT)
Received: from localhost by rodan.UU.NET with SMTP 
	(peer crosschecked as: mo@localhost)
	id QQdlri13179; Fri, 17 Oct 1997 13:40:26 -0400 (EDT)
Message-Id: 
To: "William Allen Simpson" 
cc: ietf-ppp@merit.edu
Subject: Re: scrambling PPP over SONET/SDH 
In-reply-to: Your message of "Fri, 17 Oct 1997 15:44:58 GMT."
             <6698.wsimpson@greendragon.com> 
Date: Fri, 17 Oct 1997 13:40:25 -0400
From: "Mike O'Dell" 
Sender: owner-ietf-ppp@merit.edu


No, Bill, it is not because people did the wrong thing.

it is very important to be able to run things from the transmission-system
clocking which arrives impressed in the incoming bit stream.

for example, when running SONET point-to-point on dark glass across the
room, there may well be no "house clock" to use and the transmit sources
at each end have no choice but to free-run, and that means the receivers
MUST sync to the incoming clock.

and this also applies when interfacing with transmission systems.
standard practice is that they do not bring over clock independently
of the data streams.

	-mo
- - - - - - - - - - - - - - - - -

From owner-ietf-ppp@merit.edu  Fri Oct 17 13:08:32 1997
Received: from localhost (daemon@localhost)
	by merit.edu (8.8.7/8.8.5) with SMTP id NAA15638;
	Fri, 17 Oct 1997 13:07:11 -0400 (EDT)
Received: by merit.edu (bulk_mailer v1.5); Fri, 17 Oct 1997 13:07:02 -0400
Received: (from majordom@localhost)
	by merit.edu (8.8.7/8.8.5) id NAA15616
	for ietf-ppp-outgoing; Fri, 17 Oct 1997 13:07:01 -0400 (EDT)
Received: from algw1.lucent.com (algw1.lucent.com [205.147.213.1])
	by merit.edu (8.8.7/8.8.5) with SMTP id NAA15612
	for ; Fri, 17 Oct 1997 13:06:57 -0400 (EDT)
To: "ietf-ppp@merit.edu" , "iesg@ietf.org" 
Received: from hotair.hobl.lucent.com by alig1.firewall.lucent.com (SMI-8.6/EMS-L sol2)
	id NAA10059; Fri, 17 Oct 1997 13:13:16 -0400
Received: from lucent.com (vermont.hobl.lucent.com) by hotair.hobl.lucent.com (4.1/EMS-L SunOS)
	id AA18913; Fri, 17 Oct 97 13:06:50 EDT
Message-Id: <34479BB1.1C6EE54A@lucent.com>
Date: Fri, 17 Oct 1997 13:09:05 -0400
From: James Manchester 
Organization: Advanced Networking Technologies & Standards
X-Mailer: Mozilla 4.02 [en] (X11; I; IRIX 6.3 IP32)
Mime-Version: 1.0
Original-To: "ietf-ppp@merit.edu" , "iesg@ietf.org" 
Subject: Timing/Synchronization in SONET networks
Content-Type: multipart/mixed; boundary="------------F951133B36690ABFCFACC7ED"
Sender: owner-ietf-ppp@merit.edu

This is a multi-part message in MIME format.
--------------F951133B36690ABFCFACC7ED
Content-Type: multipart/alternative; boundary="------------76743ADCAEAD983C04BF92C4"


--------------76743ADCAEAD983C04BF92C4
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



--------------76743ADCAEAD983C04BF92C4
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit




 

--------------76743ADCAEAD983C04BF92C4--

--------------F951133B36690ABFCFACC7ED
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Return-Path: 
Received: from sync1.hobl.lucent.com by hotair.hobl.lucent.com (4.1/EMS-L SunOS)
	id AA18768; Fri, 17 Oct 97 13:04:01 EDT
Received: by sync1.hobl.lucent.com (SMI-8.6/EMS-L sol2)
	id NAA01557; Fri, 17 Oct 1997 13:03:59 -0400
Date: Fri, 17 Oct 1997 13:03:59 -0400
From: gmg@hotair.hobl.lucent.com
Message-Id: <199710171703.NAA01557@sync1.hobl.lucent.com>
To: sterling@hotair.hobl.lucent.com
X-Sun-Charset: US-ASCII

This is in response to email from William Simpson of October 16 and October 17.
The discussion in the October 16 email seems to confuse the notion of
"timing recovery" or "clock recovery" with the SONET Network Element Internal
clock.  The October 17 email seems to misunderstand how timing is distributed
to BITS clocks via SONET facilities.  Since I am not certain if you are
familiar with timing and synchronization in SONET networks, I have provided
some background information that is attached.  Since this is email,
it obviously must be limited in scope; a very good review paper on
synchronization in digital networks by John Bellamy appeared in the April,
1995 (I think that is the date) issue of IEEE Communications Magazine.

I strongly urge you to read the background material first, before reading my
response to your email and the problems it is seems to be trying to address.

Your October 17 email states:

> This is probably horribly cheeky of me, but I just went and checked my
> copy of SONET.  The run of zero bits is only a problem when "line
> timing" is used; that is, the timing is derived from the incoming OC-N
> signal.
> 
> But the requirements clearly state (5.4.2.1) "... external timing from
> a BITS clock is the preferred mode of synchronizing SONET NEs."
> 
> So, the theoretical problem is that some folks didn't follow the SONET
> recommendation.  Why should we design around bad implementations?
> 
> WSimpson@UMich.edu
>     Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32

As I have indicated in the background material below, even if external timing
is used, the SONET NE must still produce a derived DS1.  It does this by
recovering timing from the incoming OC-N SONET facility on which timing is
distributed.  If we are distributing timing in a SONET Network, we must
obtain the timing from the SONET facilities.  The only way to avoid this
would be to use asynchronous DS1s distributed via PDH facilities.  However,
with the deployment of SONET, there are fewer of these available.  If this
approach were used in the long-run, it would be necessary for service
providers to maintain a separate PDH network with DS1s on which to distribute
timing.  

Regarding your October 16 email, the reason for having a sufficient number of
transitions on the incoming OC-N line signal is to enable us to derive an input
timing signal (via a wideband filter) -- either a derived DS1 to
be sent to the BITS clock or an input timing signal directly for the SONET NE
clock. The Oct. 16 email says, in part, that

> SONET-SDH is synchronous, and thus requires a clock to keep track of the
> bits as they go by.  Clocks are not perfect, so they need to be (1)
> stimulated by changing edge conditions, and (2) corrected for drift
> every once in awhile.
> 
> Failure to detect enough changing bits is Loss of Signal (LOS).  The
> drift correction uses a special 16-bit frame marker (called A1 and A2)
> with a clever bit sequence in it.  LOS that is not quickly recovered by
> the special frame markers causes Loss of Frame (LOF).
> 
> The SONET specification (my latest copy is TR-NWT-000253, December 1991)
> provides that the special A1A2 frame marker shows up every 6,480 bits
> (810 bytes), no matter what the link speed.  That guarantees a series of
> changing bits, and corrects the clock drift.

First, SONET-SDH does not require a clock to "keep track of the bits as
they go by."  Synchronization is required so that the PAYLOAD bits enter a
SONET NE and leave the SONET NE at nominally the same rates, to avoid
excessive pointer adjustments (which result in jitter) and excessive payload
wander.  Second, in saying that the clock must be "(1) stimulated by
changing edge conditions, and (2) corrected for drift every once in awhile"
I presume it is meant that the input signal must have "significant timing
instants" (these are the edges), and the PLL operates in a closed-loop
manner when it is locked to the input.  But this is precisely the point --
a timing signal must have "significant timing instants" that are detectable,
and these are the edges.  A long string of zeros does not have significant
instants that are detectable.  Finally, in saying that the changing bits
corrects the clock drift, I presume it is meant that the recovered timing signal
is input to the PLL and the SONET NE clock output frequency does not drift as
it would if it were in holdover.

William Simpson's October 16 email also says, in part, that


> Meanwhile, we talk about this every few years, and recommend that
> vendors buy from chip vendors with stable clocks.
> 
> For vendors with bad clocks and too short LOS, there is a handy 127 byte
> sequence that you can put in a PPP data packet, and drop their link for
> every one in 3,240 packets (on average, if I remember correctly).  Still
> not very much, but enough to be annoying.

The first sentence, recommending that vendors buy from chip vendors with
stable clocks, misses the entire problem.  The issue here is the input to
the SONET NE clock, and whether the incoming OC-N has a sufficient number of
transitions (detectable significant instants) such that an INPUT to the clock
can be derived.  A more stable SONET NE clock will do nothing to correct this.
The fact that "... there is a handy 127 byte sequence that you can put is a PPP
data packet, and drop their link for every one in 3,240 packets ..." has
nothing to do with the clock in the SONET NE.

I hope the above has provided clarification.  The Bellamy paper I mentioned
at the beginning provides much more background, and I highly recommend it for
additional information.

Geoff Garner
gmgarner@lucent.com



Background information on timing and synchronization in SONET networks:

The SONET Network Element Clock is just what the name implies -- the clock
unit that is physically inside the SONET Network Element.  This clock is
a piece of hardware.  The central component of this clock is a phase-locked
loop.  The SONET network element receives timing from another clock -- usually
either a BITS clock colocated with the SONET NE or another SONET NE.  The
former case (timing from a BITS) is referred to a external timing; the latter
is referred to as line timing (there is also a mode called "through timing,"
but that is not important for this discussion).

The purpose of the SONET NE clock is to provide the timing for the outgoing
lines (i.e., the outgoing OC-Ns).  It does this by taking the incoming timing
signal from the BITS clock or from an upstream SONET NE, filtering it to
remove jitter and wander, and outputing a timing signal.  It is the phase-locked
loop (PLL) in the clock that does this.  The PLL consists of a phase detector,
voltage-controlled oscillator, and loop filter, and some amplification or gain
(which can be a separate amplifier or can be embedded in the phase detector or
loop filter.  Briefly, the phase detector compares the incoming timing signal
(from either the BITS or upstream SONET NE) with the output signal produced
by the PLL, amplifies and filters this difference, and adjusts the voltage
input to the voltage-controlled oscillator based on this amplified filtered
difference.  The very long-term average frequency output of the PLL matches that
of the input.  However, the shorter-term variations in phase and frequency for
the ideal phase and frequency desired are less in the output compared to the
input; this is the effect of the filtering.

If the input signal to the PLL (i.e., to the SONET NE clock) is lost, and there
is no alternate available, the clock enters holdover.  When this happens, its
output timing signal is produced by the voltage controlled oscillator (VCO),
based on recent inputs to the VCO just prior to entering holdover.  If the
PLL remains in holdover, its frequency will begin to vary more from the ideal
desired frequency; this is referred to as "frequency drift."  In addition,
the output frequency may change slightly when the clock enters holdover; this
is referred to as "initial frequency offset."  If the clock remains in holdover
for a sufficiently long time, it reaches a state called free-run; in this state,
the output frequency accuracy matches that of the oscillator specification.

The BITS clock itself will receive timing from another source -- either a
BITS clock in another office (that has possibly passed through one SONET NE
clock if the timing is distributed via SONET facilities; see below), or a
colocated primary reference source (PRS).  The PRS is a highly accurate
timing source; the specified frequency accuracy for a PRS is 1e-11 (i.e.
the time error of a PRS would be at most 1e-11 seconds after it has been running
for 1 second; or, alternatively, if we synchronized 2 PRSs and let them run
for 1 second, their time readings would differ by at most 2e-11 seconds).
The SONET NE clock is much less accurate.  In free-run, its accuracy is
specified as 20 ppm (i.e., 20e-6).  However, in normal operation, when there
is an incoming timing signal, the SONET NE clock would be locked to an
incoming signal coming from another clock, that eventually was traceable to a
PRS, so the frequency accuracy of the output would still be 1e-11.  If the
SONET NE enters holdover, the frequency accuracy of the output timing signal
(timing the OC-N outputs) can change by 0.05 ppm (5e-8).  The frequency can
then drift at a rate of 5.8e-6 ppm/second (which is about 0.5 ppm over one
day, or 5e-7 over one day).  Therefore, it would take a number of days for
the output timing frequency accuracy to reach that corresponding to free-run
(20 ppm).  There are also holdover specifications for BITS clocks; in
North America, these are the Stratum clocks.  The PRS is Stratum 1, we also
have Stratum 2, 3E, 3 (there are also 4 and 4E, but these are less important
for this discussion).  These have much better free-run and holdover performance
than the SONET NE clock.

(In addition to considerations of holdover and free-run, the noise performance
for these clocks is specified; note that all PLLs add noise.  This is referred
to as noise generation, and there are specifications that limit how much is
allowed).

The specs for the SONET NE clock are  in ANSI T1.105.09; they are also contained
in ITU-T Rec. G.813, Option 2.  Bellcore GR-253-CORE has requirements for the
SONET NE clock that is consistent with these 2 documents.  In T1.105.09, the
clock is referred to as the "SONET Minimum Clock", or SMC.  In G.813, it is
the SDH Equipment Clock (SEC), Option 2.

So far, I have not said much on the timing input to the SONET NE clock.  As
mentioned above, the timing can be supplied externally from a BITS, or can
come from one of the input OC-N lines.  If the timing is supplied externally,
it is input to the SONET NE via a DS1 interface.  That is because BITS
clocks in North America have traditionally had DS1 interfaces (this is
because they were used in the PDH networks prior to the development of
SONET).  You may then ask, if we have only SONET and a BITS requires a DS1
input for its input timing signal, where does this DS1 come from?  The answer
to this is that the input timing to the BITS comes from another office
over SONET facilities (i.e., over an OC-N).  At this office, the SONET
NE that the OC-N terminates uses the OC-N to produce a non-traffic DS1.  This
is a signal that is in DS1 format but contains no traffic; its sole purpose
is to provide the input timing signal that the BITS clock needs.  This DS1 is
referred to as a derived DS1.  The process of producing this derived DS1
from the incoming OC-N is an example of "timing recovery" or "clock recovery."
The most important thing to note here is that the SONET NE produces the derived
DS1 from the incoming OC-N via a wide=band filtering operation; the internal
SONET NE CLOCK is not involved.  A DS1 output from the BITS clock is then
input to the SONET NE, and this DS1 output is input to the SONET NE clock.
Indeed, if the SONET NE clock itself produced the derived DS1 and was then
timed by the BITS clock that was timed by this derived DS1, we would have a
timing loop.

If the SONET NE is line-timed, then the timing input to the SONET NE clock
is derived directly from the incoming OC-N line.  While this is an internal
operation (and there need not be a derived DS1), the SONET NE must still
recover a timing signal from the incoming OC-N line that can be input to
the SONET NE clock PLL.  As with the derived DS1 above, this is a wide-band
filtering operation; the SONET NE clock is not involved in this at all.

--------------F951133B36690ABFCFACC7ED--

- - - - - - - - - - - - - - - - -

From owner-ietf-ppp@merit.edu  Fri Oct 17 12:58:29 1997
Received: from localhost (daemon@localhost)
	by merit.edu (8.8.7/8.8.5) with SMTP id MAA15464;
	Fri, 17 Oct 1997 12:57:04 -0400 (EDT)
Received: by merit.edu (bulk_mailer v1.5); Fri, 17 Oct 1997 12:56:40 -0400
Received: (from majordom@localhost)
	by merit.edu (8.8.7/8.8.5) id MAA15428
	for ietf-ppp-outgoing; Fri, 17 Oct 1997 12:56:39 -0400 (EDT)
Received: from algw1.lucent.com (algw1.lucent.com [205.147.213.1])
	by merit.edu (8.8.7/8.8.5) with SMTP id MAA15424
	for ; Fri, 17 Oct 1997 12:56:34 -0400 (EDT)
From: gmg@hotair.hobl.lucent.com
Received: from hotair.hobl.lucent.com by alig1.firewall.lucent.com (SMI-8.6/EMS-L sol2)
	id NAA01463; Fri, 17 Oct 1997 13:02:51 -0400
Received: from sync1.hobl.lucent.com by hotair.hobl.lucent.com (4.1/EMS-L SunOS)
	id AA18123; Fri, 17 Oct 97 12:56:19 EDT
Received: by sync1.hobl.lucent.com (SMI-8.6/EMS-L sol2)
	id MAA01535; Fri, 17 Oct 1997 12:56:17 -0400
Date: Fri, 17 Oct 1997 12:56:17 -0400
Message-Id: <199710171656.MAA01535@sync1.hobl.lucent.com>
To: ietf-ppp@merit.edu, iesg@ietf.org
Subject: Re: PPP over SONET/SDH
Cc: gmgarner@lucent.com
X-Sun-Charset: US-ASCII
Sender: owner-ietf-ppp@merit.edu

This is in response to email from William Simpson of October 16 and October 17.
The discussion in the October 16 email seems to confuse the notion of
"timing recovery" or "clock recovery" with the SONET Network Element Internal
clock.  The October 17 email seems to misunderstand how timing is distributed
to BITS clocks via SONET facilities.  Since I am not certain if you are
familiar with timing and synchronization in SONET networks, I have provided
some background information that is attached.  Since this is email,
it obviously must be limited in scope; a very good review paper on
synchronization in digital networks by John Bellamy appeared in the April,
1995 (I think that is the date) issue of IEEE Communications Magazine.

I strongly urge you to read the background material first, before reading my
response to your email and the problems it is seems to be trying to address.

Your October 17 email states:

> This is probably horribly cheeky of me, but I just went and checked my
> copy of SONET.  The run of zero bits is only a problem when "line
> timing" is used; that is, the timing is derived from the incoming OC-N
> signal.
> 
> But the requirements clearly state (5.4.2.1) "... external timing from
> a BITS clock is the preferred mode of synchronizing SONET NEs."
> 
> So, the theoretical problem is that some folks didn't follow the SONET
> recommendation.  Why should we design around bad implementations?
> 
> WSimpson@UMich.edu
>     Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32

As I have indicated in the background material below, even if external timing
is used, the SONET NE must still produce a derived DS1.  It does this by
recovering timing from the incoming OC-N SONET facility on which timing is
distributed.  If we are distributing timing in a SONET Network, we must
obtain the timing from the SONET facilities.  The only way to avoid this
would be to use asynchronous DS1s distributed via PDH facilities.  However,
with the deployment of SONET, there are fewer of these available.  If this
approach were used in the long-run, it would be necessary for service
providers to maintain a separate PDH network with DS1s on which to distribute
timing.  

Regarding your October 16 email, the reason for having a sufficient number of
transitions on the incoming OC-N line signal is to enable us to derive an input
timing signal (via a wideband filter) -- either a derived DS1 to
be sent to the BITS clock or an input timing signal directly for the SONET NE
clock. The Oct. 16 email says, in part, that

> SONET-SDH is synchronous, and thus requires a clock to keep track of the
> bits as they go by.  Clocks are not perfect, so they need to be (1)
> stimulated by changing edge conditions, and (2) corrected for drift
> every once in awhile.
> 
> Failure to detect enough changing bits is Loss of Signal (LOS).  The
> drift correction uses a special 16-bit frame marker (called A1 and A2)
> with a clever bit sequence in it.  LOS that is not quickly recovered by
> the special frame markers causes Loss of Frame (LOF).
> 
> The SONET specification (my latest copy is TR-NWT-000253, December 1991)
> provides that the special A1A2 frame marker shows up every 6,480 bits
> (810 bytes), no matter what the link speed.  That guarantees a series of
> changing bits, and corrects the clock drift.

First, SONET-SDH does not require a clock to "keep track of the bits as
they go by."  Synchronization is required so that the PAYLOAD bits enter a
SONET NE and leave the SONET NE at nominally the same rates, to avoid
excessive pointer adjustments (which result in jitter) and excessive payload
wander.  Second, in saying that the clock must be "(1) stimulated by
changing edge conditions, and (2) corrected for drift every once in awhile"
I presume it is meant that the input signal must have "significant timing
instants" (these are the edges), and the PLL operates in a closed-loop
manner when it is locked to the input.  But this is precisely the point --
a timing signal must have "significant timing instants" that are detectable,
and these are the edges.  A long string of zeros does not have significant
instants that are detectable.  Finally, in saying that the changing bits
corrects the clock drift, I presume it is meant that the recovered timing signal
is input to the PLL and the SONET NE clock output frequency does not drift as
it would if it were in holdover.

William Simpson's October 16 email also says, in part, that


> Meanwhile, we talk about this every few years, and recommend that
> vendors buy from chip vendors with stable clocks.
> 
> For vendors with bad clocks and too short LOS, there is a handy 127 byte
> sequence that you can put in a PPP data packet, and drop their link for
> every one in 3,240 packets (on average, if I remember correctly).  Still
> not very much, but enough to be annoying.

The first sentence, recommending that vendors buy from chip vendors with
stable clocks, misses the entire problem.  The issue here is the input to
the SONET NE clock, and whether the incoming OC-N has a sufficient number of
transitions (detectable significant instants) such that an INPUT to the clock
can be derived.  A more stable SONET NE clock will do nothing to correct this.
The fact that "... there is a handy 127 byte sequence that you can put is a PPP
data packet, and drop their link for every one in 3,240 packets ..." has
nothing to do with the clock in the SONET NE.

I hope the above has provided clarification.  The Bellamy paper I mentioned
at the beginning provides much more background, and I highly recommend it for
additional information.

Geoff Garner
gmgarner@lucent.com



Background information on timing and synchronization in SONET networks:

The SONET Network Element Clock is just what the name implies -- the clock
unit that is physically inside the SONET Network Element.  This clock is
a piece of hardware.  The central component of this clock is a phase-locked
loop.  The SONET network element receives timing from another clock -- usually
either a BITS clock colocated with the SONET NE or another SONET NE.  The
former case (timing from a BITS) is referred to a external timing; the latter
is referred to as line timing (there is also a mode called "through timing,"
but that is not important for this discussion).

The purpose of the SONET NE clock is to provide the timing for the outgoing
lines (i.e., the outgoing OC-Ns).  It does this by taking the incoming timing
signal from the BITS clock or from an upstream SONET NE, filtering it to
remove jitter and wander, and outputing a timing signal.  It is the phase-locked
loop (PLL) in the clock that does this.  The PLL consists of a phase detector,
voltage-controlled oscillator, and loop filter, and some amplification or gain
(which can be a separate amplifier or can be embedded in the phase detector or
loop filter.  Briefly, the phase detector compares the incoming timing signal
(from either the BITS or upstream SONET NE) with the output signal produced
by the PLL, amplifies and filters this difference, and adjusts the voltage
input to the voltage-controlled oscillator based on this amplified filtered
difference.  The very long-term average frequency output of the PLL matches that
of the input.  However, the shorter-term variations in phase and frequency for
the ideal phase and frequency desired are less in the output compared to the
input; this is the effect of the filtering.

If the input signal to the PLL (i.e., to the SONET NE clock) is lost, and there
is no alternate available, the clock enters holdover.  When this happens, its
output timing signal is produced by the voltage controlled oscillator (VCO),
based on recent inputs to the VCO just prior to entering holdover.  If the
PLL remains in holdover, its frequency will begin to vary more from the ideal
desired frequency; this is referred to as "frequency drift."  In addition,
the output frequency may change slightly when the clock enters holdover; this
is referred to as "initial frequency offset."  If the clock remains in holdover
for a sufficiently long time, it reaches a state called free-run; in this state,
the output frequency accuracy matches that of the oscillator specification.

The BITS clock itself will receive timing from another source -- either a
BITS clock in another office (that has possibly passed through one SONET NE
clock if the timing is distributed via SONET facilities; see below), or a
colocated primary reference source (PRS).  The PRS is a highly accurate
timing source; the specified frequency accuracy for a PRS is 1e-11 (i.e.
the time error of a PRS would be at most 1e-11 seconds after it has been running
for 1 second; or, alternatively, if we synchronized 2 PRSs and let them run
for 1 second, their time readings would differ by at most 2e-11 seconds).
The SONET NE clock is much less accurate.  In free-run, its accuracy is
specified as 20 ppm (i.e., 20e-6).  However, in normal operation, when there
is an incoming timing signal, the SONET NE clock would be locked to an
incoming signal coming from another clock, that eventually was traceable to a
PRS, so the frequency accuracy of the output would still be 1e-11.  If the
SONET NE enters holdover, the frequency accuracy of the output timing signal
(timing the OC-N outputs) can change by 0.05 ppm (5e-8).  The frequency can
then drift at a rate of 5.8e-6 ppm/second (which is about 0.5 ppm over one
day, or 5e-7 over one day).  Therefore, it would take a number of days for
the output timing frequency accuracy to reach that corresponding to free-run
(20 ppm).  There are also holdover specifications for BITS clocks; in
North America, these are the Stratum clocks.  The PRS is Stratum 1, we also
have Stratum 2, 3E, 3 (there are also 4 and 4E, but these are less important
for this discussion).  These have much better free-run and holdover performance
than the SONET NE clock.

(In addition to considerations of holdover and free-run, the noise performance
for these clocks is specified; note that all PLLs add noise.  This is referred
to as noise generation, and there are specifications that limit how much is
allowed).

The specs for the SONET NE clock are  in ANSI T1.105.09; they are also contained
in ITU-T Rec. G.813, Option 2.  Bellcore GR-253-CORE has requirements for the
SONET NE clock that is consistent with these 2 documents.  In T1.105.09, the
clock is referred to as the "SONET Minimum Clock", or SMC.  In G.813, it is
the SDH Equipment Clock (SEC), Option 2.

So far, I have not said much on the timing input to the SONET NE clock.  As
mentioned above, the timing can be supplied externally from a BITS, or can
come from one of the input OC-N lines.  If the timing is supplied externally,
it is input to the SONET NE via a DS1 interface.  That is because BITS
clocks in North America have traditionally had DS1 interfaces (this is
because they were used in the PDH networks prior to the development of
SONET).  You may then ask, if we have only SONET and a BITS requires a DS1
input for its input timing signal, where does this DS1 come from?  The answer
to this is that the input timing to the BITS comes from another office
over SONET facilities (i.e., over an OC-N).  At this office, the SONET
NE that the OC-N terminates uses the OC-N to produce a non-traffic DS1.  This
is a signal that is in DS1 format but contains no traffic; its sole purpose
is to provide the input timing signal that the BITS clock needs.  This DS1 is
referred to as a derived DS1.  The process of producing this derived DS1
from the incoming OC-N is an example of "timing recovery" or "clock recovery."
The most important thing to note here is that the SONET NE produces the derived
DS1 from the incoming OC-N via a wide=band filtering operation; the internal
SONET NE CLOCK is not involved.  A DS1 output from the BITS clock is then
input to the SONET NE, and this DS1 output is input to the SONET NE clock.
Indeed, if the SONET NE clock itself produced the derived DS1 and was then
timed by the BITS clock that was timed by this derived DS1, we would have a
timing loop.

If the SONET NE is line-timed, then the timing input to the SONET NE clock
is derived directly from the incoming OC-N line.  While this is an internal
operation (and there need not be a derived DS1), the SONET NE must still
recover a timing signal from the incoming OC-N line that can be input to
the SONET NE clock PLL.  As with the derived DS1 above, this is a wide-band
filtering operation; the SONET NE clock is not involved in this at all.
- - - - - - - - - - - - - - - - -

From owner-ietf-ppp@merit.edu  Fri Oct 17 14:32:11 1997
Received: from localhost (daemon@localhost)
	by merit.edu (8.8.7/8.8.5) with SMTP id OAA17118;
	Fri, 17 Oct 1997 14:30:33 -0400 (EDT)
Received: by merit.edu (bulk_mailer v1.5); Fri, 17 Oct 1997 14:29:02 -0400
Received: (from majordom@localhost)
	by merit.edu (8.8.7/8.8.5) id OAA17067
	for ietf-ppp-outgoing; Fri, 17 Oct 1997 14:29:02 -0400 (EDT)
Received: from algw1.lucent.com (algw1.lucent.com [205.147.213.1])
	by merit.edu (8.8.7/8.8.5) with SMTP id OAA17062
	for ; Fri, 17 Oct 1997 14:28:58 -0400 (EDT)
Received: from hotair.hobl.lucent.com by alig1.firewall.lucent.com (SMI-8.6/EMS-L sol2)
	id OAA20833; Fri, 17 Oct 1997 14:35:16 -0400
Received: from hotair (hotair.hobl.lucent.com) by hotair.hobl.lucent.com (4.1/EMS-L SunOS)
	id AA24547; Fri, 17 Oct 97 14:28:51 EDT
Message-Id: <9710171828.AA24547@hotair.hobl.lucent.com>
To: ietf-ppp@merit.edu
Cc: iesg@ietf.org
Subject: New ID - PPP Over SONET Mapping
Date: Fri, 17 Oct 1997 14:28:50 -0400
From: kris 
Sender: owner-ietf-ppp@merit.edu


We have submitted a new ID  that
addresses PPP Over SONET Mapping. It is an official ANSI I1X1 liaison.

The ID is enclosed herewith.

Murali Krishnaswamy
murali@bell-labs.com

---------------------------------------------------------------------------


							B. Allen
							Chairman - ANSI T1X1.5
Internet Draft						Cambrian Systems
Point-to-Point Protocol Extensions WG		
							J. Anderson
Expire in six months					Lucent Technologies
					
							D. Kostas
							GTE

							B. Wang
							AT&T
						
							A. White
							Sprint Corporation

	



			PPP Over SONET 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

This Internet Draft addresses the PPP/SONET interface defined
in the IETF RFC 1619 and the standards work underway in T1X1 on 
SONET.  



Allen, Anderson, et al. 					[Page 1]

PPP over SONET Mapping						October 1997

ANSI accredited T1 Technical Subcommittee T1X1 is responsible for
SONET standards development documented in ANSI T1.105. This development
includes SONET rates, formats and payload mappings specifications. 
It has recently been brought to T1X1's attention the existence of 
IETF RFC 1619 that defines a mapping for IP/PPP onto SONET. Results 
from technical analyses and laboratory tests of the RFC 1619 mapping 
have led T1X1 to conclude that RFC 1619, under certain conditions, is 
not capable of providing payload transparency in SONET transport 
networks. This technical flaw is a major concern to network operators 
for it can lead to unexpected SONET transport system behavior and 
failures. These results are documented in contribution T1X1.5/97-105 
(URL ftp://ftp.t1.org/pub/t1x1/x1.5/7x151050.pdf).

As such, T1X1 is urgently developing a solution to the above noted 
technical flaw and intends to publish the IP/PPP mapping for SONET 
signals in ANSI T1.105. The target time frame for reaching technical 
consensus on this work is April 1998. 

With the intent of establishing global standards for SDH, T1X1 is also 
pursuing specification of the IP/PPP mapping for SDH signals in ITU-T 
Recommendation G.707. The target time frame for completing the G.707 
enhancement is not yet determined, but is anticipated to be as early 
as October 1998.

A T1X1.5 ad hoc meeting is scheduled for the first week in December 
(exact dates TBD) in Kansas City for addressing IP/PPP over SONET 
mapping requirements and possible solutions. IETF input is invited and 
participants can attend to submit their proposals to this meeting and 
subsequent T1X1.5 meetings. Please contact Brent Allen or Al White 
(contact information given below) for further information.


Authors' Address

Brent Allen
E-mail: ballen@cambriansys.com
Telephone: +1-613-599-6060 (ext. 4899)
Fax: +1-613-591-2035

Cambrian Systems
555 Legget Drive
Kanata, Ontario
K2K 2X3
CANADA

Jon Anderson
E-mail: jonanderson@lucent.com
Telephone: +1-732-949-0634
Fax: +1-732-949-3210





Allen, Anderson, et al. 					[Page 2]

PPP over SONET Mapping						October 1997

Lucent Technologies - Bell Laboratories
Room 2G-538
101 Crawfords Corner Road
Holmdel, NJ 07733-3030
USA

Demos Kostas
E-mail: demos.kostas@telops.gte.com
Telephone: +1 972 718 6291
Fax:+1 972 718 4393
 
Al White
E-mail: al.white@mail.sprint.com
Telephone: +1-816-854-5266
Fax: +1-816-854-5189

Sprint Corporation
901 East 104th St.
Mailstop MOKCMD0808
Kansas City, MO 64131
USA

































Allen, Anderson, et al. 					[Page 3]
- - - - - - - - - - - - - - - - -

From owner-ietf-ppp@merit.edu  Fri Oct 17 14:52:04 1997
Received: from localhost (daemon@localhost)
	by merit.edu (8.8.7/8.8.5) with SMTP id OAA17408;
	Fri, 17 Oct 1997 14:50:40 -0400 (EDT)
Received: by merit.edu (bulk_mailer v1.5); Fri, 17 Oct 1997 14:50:28 -0400
Received: (from majordom@localhost)
	by merit.edu (8.8.7/8.8.5) id OAA17387
	for ietf-ppp-outgoing; Fri, 17 Oct 1997 14:50:28 -0400 (EDT)
Received: from relay3.UU.NET (relay3.UU.NET [192.48.96.8])
	by merit.edu (8.8.7/8.8.5) with ESMTP id OAA17383
	for ; Fri, 17 Oct 1997 14:50:24 -0400 (EDT)
Received: from rodan.UU.NET by relay3.UU.NET with ESMTP 
	(peer crosschecked as: rodan.UU.NET [153.39.130.10])
	id QQdlrn26563; Fri, 17 Oct 1997 14:50:29 -0400 (EDT)
Received: from localhost by rodan.UU.NET with SMTP 
	(peer crosschecked as: mo@localhost)
	id QQdlrn24304; Fri, 17 Oct 1997 14:50:16 -0400 (EDT)
Message-Id: 
To: kris 
cc: ietf-ppp@merit.edu, iesg@ietf.org
Subject: Re: New ID - PPP Over SONET Mapping 
In-reply-to: Your message of "Fri, 17 Oct 1997 14:28:50 EDT."
             <9710171828.AA24547@hotair.hobl.lucent.com> 
Date: Fri, 17 Oct 1997 14:50:16 -0400
From: "Mike O'Dell" 
Sender: owner-ietf-ppp@merit.edu


excuse me, but the IETF will publish any revised IP-over-SONET spec.

I don't remember ceding change control to anyone.

	-mo
- - - - - - - - - - - - - - - - -

From owner-ietf-ppp@merit.edu  Fri Oct 17 15:20:10 1997
Received: from localhost (daemon@localhost)
	by merit.edu (8.8.7/8.8.5) with SMTP id PAA18164;
	Fri, 17 Oct 1997 15:18:47 -0400 (EDT)
Received: by merit.edu (bulk_mailer v1.5); Fri, 17 Oct 1997 15:18:37 -0400
Received: (from majordom@localhost)
	by merit.edu (8.8.7/8.8.5) id PAA18142
	for ietf-ppp-outgoing; Fri, 17 Oct 1997 15:18:36 -0400 (EDT)
Received: from algw1.lucent.com (algw1.lucent.com [205.147.213.1])
	by merit.edu (8.8.7/8.8.5) with SMTP id PAA18132
	for ; Fri, 17 Oct 1997 15:18:31 -0400 (EDT)
Received: from hotair.hobl.lucent.com by alig1.firewall.lucent.com (SMI-8.6/EMS-L sol2)
	id PAA02825; Fri, 17 Oct 1997 15:24:52 -0400
Received: from lucent.com ([199.118.135.92]) by hotair.hobl.lucent.com (4.1/EMS-L SunOS)
	id AA27026; Fri, 17 Oct 97 15:18:25 EDT
Message-Id: <3447B901.B840D85C@lucent.com>
Date: Fri, 17 Oct 1997 15:14:09 -0400
From: "Paul A. Bonenfant" 
Reply-To: pbonenfant@lucent.com
Organization: Advanced Networking Technologies
X-Mailer: Mozilla 4.03 [en] (Win95; U)
Mime-Version: 1.0
To: ietf-ppp 
Subject: SONET/SDH payload mappings [was Re: liaison of IETF PPP over SONET/SDH]
References: <6697.wsimpson@greendragon.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-ppp@merit.edu

A few comments re the history of SONET/SDH, in particular,
the specification of SONET/SDH payload mappings...

As formal liaison with ANSI is effectively scoffed at 
(below), I'll focus on ITU-T (formerly CCITT) standards, 
as this is the international standards body with which
the IETF has established formal liaison.

Contrary to an earlier quip, G.707 is not new.  In fact
G.707 (along with G.708 and G.709, which [combined] described 
the multiplexing structure, scrambling, payload mappings, etc.
for SDH, i.e., the SDH NNI) was originally approved by 
CCITT Study Group XVIII in 1988.  It has since undergone two 
revisions (1993, 1996).  The most recent version of G.707 (1996) 
incorporates the former G.708 and G.709, and is entitled "Network
node interface for the synchronous digital hierarchy (SDH)" (see
ITU-T COM 15-R 39-E, December 1995)...but enough of history.

Note that G.707-1996 neither recognizes a signal label for the
PPP-over-SDH mapping (see Table 7/G.707, "C2 byte coding"), 
nor describes a PPP-over-SDH mapping (see Section 10/G.707, 
"Mapping of tributaries into VC-n").

This fact alone renders one to immediately recognize that vendors
implementing PPP-over-SONET/SDH, irrespective of the ID (Manchester 
et al), have done so (albeit unknowingly) at their own peril.

Note that G.707 specifies a signal label (13 hex) (again, see 
Table 7/G.707) and a payload mapping for ATM (Section 10.2/G.707, 
"Mapping of ATM cells"). Included is the requirement that "the ATM 
cell information field (48 bytes) shall be scrambled before mapping 
into the VC-x or VC-x-mc...[followed by a description of the 
self-synchronizing scrambler with generating polynomial (x^43 + 1)]..." 

To motivate the need for payload scrambling in the case of PPP-over-SDH, 
I suggest that the interested reader see the list of references cited in 
the ID (Manchester et al).  Pouring over this historical paper trail
will undoubtedly result in an informed discussion of the issue(s).

Paul Bonenfant
pbonenfant@lucent.com

William Allen Simpson wrote:
> 
> > From: Fred Baker 
> > At 2:38 PM +0100 10/16/97, (Brian E Carpenter) wrote:
> > >ANSI being a national standards body, and the IETF being
> > >international, it is highly unlikely that you will see
> > >a formal liaison.
> >
> > The point here is IMHO moot - ANSI feeds documents to ITU-T, who owns SDH,
> > and we have a liaison with ITU-T. So what?
> >
> Yes, I got a bit of a laugh out of this, too.
> 
> Apparently, the reason that Bellcore ignored this problem when we raised
> it in March, 1993, was that IETF was not (in the written words of T1X1):
> "approved by a recognized standard setting organization."
> 
> And the reason that this is all coming to the fore at this moment is
> that T1X1 had their quarterly meeting this week.  And the Internet is
> suddenly an important source of money.
> 
> T1X1 wants to have an interim meeting in December.  I think this is a
> good idea.  In fact, we are already having a meeting in December.  So,
> we should invite T1X1 to come to our meeting for a joint BOF on this
> issue.  Perhaps there is some time left on Friday morning?
> 
>                                 ====
> 
> On the "standards politics" side, the rumor is that a certain Very Large
> Vendor's chips could not meet the minimum clock recovery for Loss of
> Signal of 358 bits at OC3.  Instead of fixing their chips, they "fixed"
> the standard to allow fewer bits....
> 
> And a certain Very Large Carrier wants to offer direct SONET as a
> tariffed option, at a higher tariff rate for an "enhanced service".
> But, they bought equipment from the Very Large Vendor, and it might
> reflect poorly on their performance.  So, they'd rather get everyone
> else to change....
> 
> Our testing never detected this problem in the field, because:
> 
>  - we have such a large mix of packets on the backbone that it is almost
>    impossible for this attack to succeed;
> 
>  - our circuits are mostly dedicated fiber between routers (they don't
>    fall over to another circuit when attacked, and recover with loss of
>    only 1 or 2 packets);
> 
>  - or our circuits are muxed into a Virtual Tributory (VT, a bit more
>    than a VC) which is byte interleaved with other (voice) signals, and
>    thus does not demonstrate the problem.
> 
> As far as I can determine (I spent several hours on the phone yesterday),
> this attack is entirely theoretical.  Nobody has demonstrated it on an
> inter-exchange carrier trunk.
> 
> WSimpson@UMich.edu
>     Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
- - - - - - - - - - - - - - - - -

From owner-ietf-ppp@merit.edu  Fri Oct 17 15:54:38 1997
Received: from localhost (daemon@localhost)
	by merit.edu (8.8.7/8.8.5) with SMTP id PAA18785;
	Fri, 17 Oct 1997 15:52:59 -0400 (EDT)
Received: by merit.edu (bulk_mailer v1.5); Fri, 17 Oct 1997 15:52:21 -0400
Received: (from majordom@localhost)
	by merit.edu (8.8.7/8.8.5) id PAA18748
	for ietf-ppp-outgoing; Fri, 17 Oct 1997 15:52:20 -0400 (EDT)
Received: from algw1.lucent.com (algw1.lucent.com [205.147.213.1])
	by merit.edu (8.8.7/8.8.5) with SMTP id PAA18744
	for ; Fri, 17 Oct 1997 15:52:15 -0400 (EDT)
Received: from hotair.hobl.lucent.com by alig1.firewall.lucent.com (SMI-8.6/EMS-L sol2)
	id PAA01837; Fri, 17 Oct 1997 15:58:31 -0400
Received: from lucent.com ([199.118.135.124]) by hotair.hobl.lucent.com (4.1/EMS-L SunOS)
	id AA29040; Fri, 17 Oct 97 15:52:01 EDT
Message-Id: <3447C1D8.8A262CA4@lucent.com>
Date: Fri, 17 Oct 1997 15:51:52 -0400
From: Eve Varma 
Organization: Lucent Technologies
X-Mailer: Mozilla 4.03 [en] (Win95; U)
Mime-Version: 1.0
To: "Mike O'Dell" 
Cc: kris , ietf-ppp@merit.edu, iesg@ietf.org
Subject: Re: New ID - PPP Over SONET Mapping
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-ppp@merit.edu

I would suggest you re-read the unofficial T1X1 liaison regarding their
recognized scope of responsibility.   In any event, at this point I
would think our concerns and actions
should be on mitigating the negative impacts that may be experienced by
vendors and network providers because of this specification.  The IP
over SONET mapping failed to consider the SONET mapping criteria
established in 1988, and it is becoming increasingly clear that
SONET/SDH transport networking expertise was not adequately coupled into
its generation. The internet and transport networking worlds have come
together - let's
have it be more of a marriage than a collision please.
                                       Eve Varma


Mike O'Dell wrote:

> excuse me, but the IETF will publish any revised IP-over-SONET spec.
>
> I don't remember ceding change control to anyone.
>
>         -mo



- - - - - - - - - - - - - - - - -

From owner-ietf-ppp@merit.edu  Fri Oct 17 17:37:55 1997
Received: from localhost (daemon@localhost)
	by merit.edu (8.8.7/8.8.5) with SMTP id RAA20328;
	Fri, 17 Oct 1997 17:36:15 -0400 (EDT)
Received: by merit.edu (bulk_mailer v1.5); Fri, 17 Oct 1997 17:35:40 -0400
Received: (from majordom@localhost)
	by merit.edu (8.8.7/8.8.5) id RAA20300
	for ietf-ppp-outgoing; Fri, 17 Oct 1997 17:35:39 -0400 (EDT)
Received: from Bill.Simpson.DialUp.Mich.Net (pm051-05.dialip.mich.net [141.211.6.112])
	by merit.edu (8.8.7/8.8.5) with SMTP id RAA20296;
	Fri, 17 Oct 1997 17:35:34 -0400 (EDT)
Date: Fri, 17 Oct 97 20:55:49 GMT
From: "William Allen Simpson" 
Message-ID: <6701.wsimpson@greendragon.com>
To: ietf-ppp@merit.edu
Subject: Re: scrambler
Sender: owner-ietf-ppp@merit.edu

Thank you for the nice description of the problems with self-synchronous
scramblers.  As noted earlier to the list, we decided several years ago
not to use X**43 for PPP.  For long packets, it merely shifts the
scrambling a few bits, yielding a slightly modified sequence, but does
not fix the theoretical "killer packet" problem.

To correct a minor misconception, the byte-stuffing (actually
implemented) is all done at the HDLC framing level, and does not shift
or affect the Synchronous Payload Envelope physical layer.


> From: dravida@lucent.com (Subra Dravida)
> The general issues  with self-synchronizing scramblers
> are that they create error multiplication.
> The 1+x**43 scrambler creates a correlated error 43 bits away from
> the original physical layer error.
> ...
> There was a suggestion to introduce stuffing bits or bytes
> at the physical layer whenever a run of zeros or ones is
> observed (somewhat like byte stuffing/destuffing).
> In addition to implementational issues as we move from OC3
> to OC12, OC48 and beyond,
> this introduces extra bits and bytes at the physical layer at
> random.
> The SONET payload envelope size keeps changing randomly
> (SPE has a fixed number of bytes per 125 microseconds) and is not a viable
> option.
>

WSimpson@UMich.edu
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
- - - - - - - - - - - - - - - - -

From owner-ietf-ppp@merit.edu  Fri Oct 17 18:25:53 1997
Received: from localhost (daemon@localhost)
	by merit.edu (8.8.7/8.8.5) with SMTP id SAA21146;
	Fri, 17 Oct 1997 18:24:29 -0400 (EDT)
Received: by merit.edu (bulk_mailer v1.5); Fri, 17 Oct 1997 18:24:13 -0400
Received: (from majordom@localhost)
	by merit.edu (8.8.7/8.8.5) id SAA21119
	for ietf-ppp-outgoing; Fri, 17 Oct 1997 18:24:12 -0400 (EDT)
Received: from Bill.Simpson.DialUp.Mich.Net (pm054-15.dialip.mich.net [141.211.6.153])
	by merit.edu (8.8.7/8.8.5) with SMTP id SAA21108;
	Fri, 17 Oct 1997 18:24:03 -0400 (EDT)
Date: Fri, 17 Oct 97 21:46:25 GMT
From: "William Allen Simpson" 
Message-ID: <6703.wsimpson@greendragon.com>
To: ietf-ppp@merit.edu
Subject: SONET/SDH payload mappings [was Re: liaison of IETF PPP over SONET/SDH]
Sender: owner-ietf-ppp@merit.edu

> From: "Paul A. Bonenfant" 
> A few comments re the history of SONET/SDH, in particular,
> the specification of SONET/SDH payload mappings...
>
> As formal liaison with ANSI is effectively scoffed at
> (below), I'll focus on ITU-T (formerly CCITT) standards,
> as this is the international standards body with which
> the IETF has established formal liaison.
>
> Contrary to an earlier quip, G.707 is not new.  In fact
> G.707 (along with G.708 and G.709, which [combined] described
> the multiplexing structure, scrambling, payload mappings, etc.
> for SDH, i.e., the SDH NNI) was originally approved by
> CCITT Study Group XVIII in 1988.  It has since undergone two
> revisions (1993, 1996).  The most recent version of G.707 (1996)
> incorporates the former G.708 and G.709, and is entitled "Network
> node interface for the synchronous digital hierarchy (SDH)" (see
> ITU-T COM 15-R 39-E, December 1995)...but enough of history.
>
As you admit, the G.707 specification _is_ new -- 1996.  We are not used
to specifications radically changing and reorganizing without changing
numbers.  Horribly confusing.

For comparison, the IETF history is as follows:

At the Fall '92 meeting, we first proposed PPP over SONET.  We had
actually been talking about it for awhile before that, in the research
wing of the Internet (the IRTF).  Tracy Brown of Bellcore was doing
SONET MIBs at the time.

At the Spring '93 meeting, we formalized the PPP over SONET
specification.  Publication was delayed for about a year at IESG
request for implementation experience.

RFC-1619 was published May '94.  There have since been multiple
interoperable implementations.

The RFC, and all the drafts that went before it, were all available
on-line to all interested parties.


> Note that G.707-1996 neither recognizes a signal label for the
> PPP-over-SDH mapping (see Table 7/G.707, "C2 byte coding"),
> nor describes a PPP-over-SDH mapping (see Section 10/G.707,
> "Mapping of tributaries into VC-n").
>
In addition to direct contact with several of the persons involved, the
IETF submitted its information through a fellow named "Lyman Chapin",
who was active in both ANSI T1 and IETF.  He was a chair of our IAB.

As I noted previously:
> > ... in March, 1993, was that IETF was not (in the written words of T1X1):
> > "approved by a recognized standard setting organization."


> This fact alone renders one to immediately recognize that vendors
> implementing PPP-over-SONET/SDH, irrespective of the ID (Manchester
> et al), have done so (albeit unknowingly) at their own peril.
>
Or, to turn the comment on its head, the professional standards
committee goers failed to recognized the IETF contributions "at their
own peril."

Where is G.707 on-line?

Thank you for your enlightening commentary.


> Table 7/G.707) and a payload mapping for ATM (Section 10.2/G.707,
> "Mapping of ATM cells"). Included is the requirement that "the ATM
> cell information field (48 bytes) shall be scrambled before mapping
> into the VC-x or VC-x-mc...[followed by a description of the
> self-synchronizing scrambler with generating polynomial (x^43 + 1)]..."
>
> To motivate the need for payload scrambling in the case of PPP-over-SDH,
> I suggest that the interested reader see the list of references cited in
> the ID (Manchester et al).  Pouring over this historical paper trail
> will undoubtedly result in an informed discussion of the issue(s).
>
> Paul Bonenfant
> pbonenfant@lucent.com
>

WSimpson@UMich.edu
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
- - - - - - - - - - - - - - - - -

From owner-ietf-ppp@merit.edu  Fri Oct 17 20:17:28 1997
Received: from localhost (daemon@localhost)
	by merit.edu (8.8.7/8.8.5) with SMTP id UAA22175;
	Fri, 17 Oct 1997 20:16:01 -0400 (EDT)
Received: by merit.edu (bulk_mailer v1.5); Fri, 17 Oct 1997 20:15:35 -0400
Received: (from majordom@localhost)
	by merit.edu (8.8.7/8.8.5) id UAA22157
	for ietf-ppp-outgoing; Fri, 17 Oct 1997 20:15:34 -0400 (EDT)
Received: from rhodes.cisco.com (rhodes.cisco.com [171.69.1.169])
	by merit.edu (8.8.7/8.8.5) with SMTP id UAA22152
	for ; Fri, 17 Oct 1997 20:15:30 -0400 (EDT)
Received: from fred-axel-fr.cisco.com (fred-axel-fr.cisco.com [171.69.128.115]) by rhodes.cisco.com (8.6.12/CISCO.SERVER.1.1) with ESMTP id RAA23766; Fri, 17 Oct 1997 17:14:02 -0700
Received: from [171.69.128.118] (fred-hm-dhcp3.cisco.com [171.69.128.118]) by fred-axel-fr.cisco.com (8.6.8+c/CISCO.WS.1.1) with ESMTP id RAA00476; Fri, 17 Oct 1997 17:13:56 -0700
X-Sender: fred@stilton.cisco.com
Message-Id: 
In-Reply-To: <3446F5C2.739C@pcl.stpn.soft.net>
References: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 17 Oct 1997 17:06:31 -0700
To: Steve Coya 
From: Fred Baker 
Subject: Re: [Fwd: [Fwd: Requesting comments on my draft]]
Cc: Vimal Khanna ,
        Thomas Narten ,
        Jeffrey Burgan , Jonathan.Goodchild@rdl.co.uk,
        vandys@cisco.com, karl@ascend.com,
        William Allen Simpson , ietf-ppp@merit.edu
Sender: owner-ietf-ppp@merit.edu

At 10:51 AM +0530 10/17/97, Vimal Khanna wrote:
>The proposed draft has been revised as per the suggestions of the WG.
>The draft "PPP for Asynchronous PAD to Synchronous X.25 access" is now
>available as
>
>"draft-rfced-info-khana-01.txt".

Steve:

would you be so kind as to rename this draft

	draft-ietf-ppp-khana-x25-00.txt

reflecting the fact that it is an individual submission to a working group?
It is a matter for the PPP working group to consider and make a
recommendation on.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  "A beautiful idea has a much greater chance of being a correct idea
   than an ugly one."
                     -- Roger Penrose, "The Emperor's New Mind", 1989


- - - - - - - - - - - - - - - - -

From owner-ietf-ppp@merit.edu  Fri Oct 17 20:20:01 1997
Received: from localhost (daemon@localhost)
	by merit.edu (8.8.7/8.8.5) with SMTP id UAA22224;
	Fri, 17 Oct 1997 20:18:40 -0400 (EDT)
Received: by merit.edu (bulk_mailer v1.5); Fri, 17 Oct 1997 20:18:33 -0400
Received: (from majordom@localhost)
	by merit.edu (8.8.7/8.8.5) id UAA22206
	for ietf-ppp-outgoing; Fri, 17 Oct 1997 20:18:32 -0400 (EDT)
Received: from Bill.Simpson.DialUp.Mich.Net (pm035-09.dialip.mich.net [141.211.7.20])
	by merit.edu (8.8.7/8.8.5) with SMTP id UAA22202;
	Fri, 17 Oct 1997 20:18:26 -0400 (EDT)
Date: Fri, 17 Oct 97 23:00:45 GMT
From: "William Allen Simpson" 
Message-ID: <6704.wsimpson@greendragon.com>
To: ietf-ppp@merit.edu
Subject: stable SONET/SDH clocks and timing
Sender: owner-ietf-ppp@merit.edu

> From: gmg@hotair.hobl.lucent.com
> As I have indicated in the background material below, even if external timing
> is used, the SONET NE must still produce a derived DS1.  It does this by
> recovering timing from the incoming OC-N SONET facility on which timing is
> distributed.  If we are distributing timing in a SONET Network, we must
> obtain the timing from the SONET facilities.

As far as I can tell, there seems to be some confusion in your messages
between distributing the "DS1" (125 microsecond) timing of the start of
frames in a SONET-SDH network, and the clocks recovering timing of the
bits on the link (measured in nanoseconds and picoseconds).

The DS1 frame timing is really irrelevant to PPP or the payload
contents or the scrambling.  IP routers buffer packets.  SONET frame
alignment between multiple routers is not an issue.

You cannot distribute the bit timing, the intervals are too small, and
different paths would yield different results, speed of light problem.

The rest of the message seems to play semantic ISO-ese language games.
A correspondence to the name of your host?


> First, SONET-SDH does not require a clock to "keep track of the bits as
> they go by."

A clock is a clock is a clock, even when the implementation is a
Phase-Locked-Loop (PLL in your message).  You cannot recover the bits
without the timing of a clock.

> Second, in saying that the clock must be "(1) stimulated by
> changing edge conditions, and (2) corrected for drift every once in awhile"
> I presume it is meant that the input signal must have "significant timing
> instants" (these are the edges), and the PLL operates in a closed-loop
> manner when it is locked to the input.

Pardon my trying to speak in a language that the software engineers on
this list might understand.  Quite frankly, my old Electrical
Engineering professor would have laughed at "significant timing
instants".  Try repeating that tongue twister out loud.  I'll admit it,
I laughed at it, too.

To be picky, your phrase is not as descriptive.  Are there
"insignificant" timing instants?  Significant "non-instantiated" timing?

But the gist of the rest of your message is that you agree with me that
the clock is stimulated by the edge conditions of bit transitions, and
drift is corrected by the magic bits 11110110 00101000 in the "section
overhead" A1A2 bytes.  You just like fancy wording.

A stable signal recovery clock (of which a PLL is one possible
implementation, but a good old fashioned crystal would work) will
survive longer without bit transitions.  All it needs to do is be stable
enough that it lasts until the next A1A2.

There are SONET chip vendors that have nice stable PLLs, staying in time
during zero bit runs of upwards of 2000 bits, compared to 80 bits cited
in the draft.  Indeed, I understand that one of them is used in a Lucent
product, instead of from their own Lucent chip division....

WSimpson@UMich.edu
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
- - - - - - - - - - - - - - - - -

From owner-ietf-ppp@merit.edu  Fri Oct 17 20:47:12 1997
Received: from localhost (daemon@localhost)
	by merit.edu (8.8.7/8.8.5) with SMTP id UAA22614;
	Fri, 17 Oct 1997 20:45:45 -0400 (EDT)
Received: by merit.edu (bulk_mailer v1.5); Fri, 17 Oct 1997 20:45:29 -0400
Received: (from majordom@localhost)
	by merit.edu (8.8.7/8.8.5) id UAA22590
	for ietf-ppp-outgoing; Fri, 17 Oct 1997 20:45:28 -0400 (EDT)
Received: from algw1.lucent.com (algw1.lucent.com [205.147.213.1])
	by merit.edu (8.8.7/8.8.5) with SMTP id UAA22585
	for ; Fri, 17 Oct 1997 20:45:24 -0400 (EDT)
Received: from hotair.hobl.lucent.com by alig1.firewall.lucent.com (SMI-8.6/EMS-L sol2)
	id UAA25320; Fri, 17 Oct 1997 20:51:44 -0400
Received: from hotair.lucent.com ([199.118.135.76]) by hotair.hobl.lucent.com (4.1/EMS-L SunOS)
	id AA08091; Fri, 17 Oct 97 20:45:17 EDT
Message-Id: <34480779.ADA55C3@hotair.lucent.com>
Date: Fri, 17 Oct 1997 20:48:57 -0400
From: Eve Varma 
Organization: JC0C01010
X-Mailer: Mozilla 4.03 [en] (Win95; U)
Mime-Version: 1.0
To: William Allen Simpson 
Cc: ietf-ppp@merit.edu
Subject: Re: stable SONET/SDH clocks and timing
References: <6704.wsimpson@greendragon.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-ppp@merit.edu

Bill,
I'm quite astounded that you did not carefully read the message
provided, at some pains, by my colleague.  You have continued
to miss the point, while managing to be rude at the same time.
The language used by my colleague is common for any expert in
the clock and synchronization domain, and he is well recognized
as such. I will repeat the message: SONET clocks have nothing to
do with the problem cited.  Full stop.
                       Eve Varma


William Allen Simpson wrote:
> 
> > From: gmg@hotair.hobl.lucent.com
> > As I have indicated in the background material below, even if external timing
> > is used, the SONET NE must still produce a derived DS1.  It does this by
> > recovering timing from the incoming OC-N SONET facility on which timing is
> > distributed.  If we are distributing timing in a SONET Network, we must
> > obtain the timing from the SONET facilities.
> 
> As far as I can tell, there seems to be some confusion in your messages
> between distributing the "DS1" (125 microsecond) timing of the start of
> frames in a SONET-SDH network, and the clocks recovering timing of the
> bits on the link (measured in nanoseconds and picoseconds).
> 
> The DS1 frame timing is really irrelevant to PPP or the payload
> contents or the scrambling.  IP routers buffer packets.  SONET frame
> alignment between multiple routers is not an issue.
> 
> You cannot distribute the bit timing, the intervals are too small, and
> different paths would yield different results, speed of light problem.
> 
> The rest of the message seems to play semantic ISO-ese language games.
> A correspondence to the name of your host?
> 
> > First, SONET-SDH does not require a clock to "keep track of the bits as
> > they go by."
> 
> A clock is a clock is a clock, even when the implementation is a
> Phase-Locked-Loop (PLL in your message).  You cannot recover the bits
> without the timing of a clock.
> 
> > Second, in saying that the clock must be "(1) stimulated by
> > changing edge conditions, and (2) corrected for drift every once in awhile"
> > I presume it is meant that the input signal must have "significant timing
> > instants" (these are the edges), and the PLL operates in a closed-loop
> > manner when it is locked to the input.
> 
> Pardon my trying to speak in a language that the software engineers on
> this list might understand.  Quite frankly, my old Electrical
> Engineering professor would have laughed at "significant timing
> instants".  Try repeating that tongue twister out loud.  I'll admit it,
> I laughed at it, too.
> 
> To be picky, your phrase is not as descriptive.  Are there
> "insignificant" timing instants?  Significant "non-instantiated" timing?
> 
> But the gist of the rest of your message is that you agree with me that
> the clock is stimulated by the edge conditions of bit transitions, and
> drift is corrected by the magic bits 11110110 00101000 in the "section
> overhead" A1A2 bytes.  You just like fancy wording.
> 
> A stable signal recovery clock (of which a PLL is one possible
> implementation, but a good old fashioned crystal would work) will
> survive longer without bit transitions.  All it needs to do is be stable
> enough that it lasts until the next A1A2.
> 
> There are SONET chip vendors that have nice stable PLLs, staying in time
> during zero bit runs of upwards of 2000 bits, compared to 80 bits cited
> in the draft.  Indeed, I understand that one of them is used in a Lucent
> product, instead of from their own Lucent chip division....
> 
> WSimpson@UMich.edu
>     Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
- - - - - - - - - - - - - - - - -

From owner-ietf-ppp@merit.edu  Fri Oct 17 21:00:59 1997
Received: from localhost (daemon@localhost)
	by merit.edu (8.8.7/8.8.5) with SMTP id UAA22798;
	Fri, 17 Oct 1997 20:59:38 -0400 (EDT)
Received: by merit.edu (bulk_mailer v1.5); Fri, 17 Oct 1997 20:59:25 -0400
Received: (from majordom@localhost)
	by merit.edu (8.8.7/8.8.5) id UAA22777
	for ietf-ppp-outgoing; Fri, 17 Oct 1997 20:59:25 -0400 (EDT)
Received: from Bill.Simpson.DialUp.Mich.Net (pm002-17.dialip.mich.net [141.211.7.153])
	by merit.edu (8.8.7/8.8.5) with SMTP id UAA22767;
	Fri, 17 Oct 1997 20:59:06 -0400 (EDT)
Date: Sat, 18 Oct 97 00:18:40 GMT
From: "William Allen Simpson" 
Message-ID: <6705.wsimpson@greendragon.com>
To: ietf-ppp@merit.edu
Cc: iesg@ietf.org
Subject: Re: liaison of IETF PPP over SONET/SDH
Sender: owner-ietf-ppp@merit.edu

I've finally worked back to this message.  It seems to me that this is
an "ad hominem" personal attack.

Coupled with another message that he first sent to me, and forwarded to
the list when I did not reply, I apparently stand accused of lying and
incompetence.

These messages appear both libelous and slanderous.


> Date: Fri, 17 Oct 1997 12:09:26 -0400
> From: James Manchester 
> We don't work on rumor and insinuation at Bell-Labs.  Every single statement
> you made is false.  Full stop.
>
> As Oscar Wilde said, "If you can't attack my arguments, consider calling me
> names."
>
OK, we'll take this one statement at a time, for the record:


> William Allen Simpson wrote:
> > > From: Fred Baker 
> > > At 2:38 PM +0100 10/16/97, (Brian E Carpenter) wrote:
> > > >ANSI being a national standards body, and the IETF being
> > > >international, it is highly unlikely that you will see
> > > >a formal liaison.
> > >
> > > The point here is IMHO moot - ANSI feeds documents to ITU-T, who owns SDH,
> > > and we have a liaison with ITU-T. So what?
> > >
> > Yes, I got a bit of a laugh out of this, too.
> >
Please prove that I did not get a laugh out of this, too?


> > Apparently, the reason that Bellcore ignored this problem when we raised
> > it in March, 1993, was that IETF was not (in the written words of T1X1):
> > "approved by a recognized standard setting organization."
> >
Please indicate the Bellcore initiated SONET changes based on the report?
 - specific documents would be appreciated.
 - I'll give you a hint, I got the SONET spec directly from Bellcore.
 - I'll give you another hint, another person already posted that PPP
   was not included in the new G.707.

Please indicate whether you were in the Bellcore network survivability
group when I spoke to you on this problem?
 - I'll give you a hint, I still have all the phone records.

I expect that it will be a little hard to disavow the quote from your
own document....


> > And the reason that this is all coming to the fore at this moment is
> > that T1X1 had their quarterly meeting this week.  And the Internet is
> > suddenly an important source of money.
> >
Please prove that T1X1 did not meet this week?

Please prove that the Internet is not an important source of money?


> > T1X1 wants to have an interim meeting in December.  I think this is a
> > good idea.  In fact, we are already having a meeting in December.  So,
> > we should invite T1X1 to come to our meeting for a joint BOF on this
> > issue.  Perhaps there is some time left on Friday morning?
> >
Please prove that T1X1 does not want to have an interim meeting in December?

Please prove that I do not think this is a good idea?

Please prove that we are not already having a meeting in December?

The remaining two sentences in this paragraph are not statements subject
to proof, as they are mere conjecture and rhetorical.

And I'm tired, so I'm not going to do all the rest of the paragraphs
here or in the other message at this time.  I think I've made my point.

And I spent all day yesterday working on this topic, and a large part of
today, pro bono.  And I have a Sixth Circuit appellate brief to prepare
by the 24th, so I really didn't have time.  I thought that I was being
helpful and that this was important.

Rest assured, after that, when I have a little more time, the Lucent
attorneys are going to be having a little chat with me and my
attorneys on this issue.

WSimpson@UMich.edu
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
- - - - - - - - - - - - - - - - -

From owner-ietf-ppp@merit.edu  Fri Oct 17 22:55:05 1997
Received: from localhost (daemon@localhost)
	by merit.edu (8.8.7/8.8.5) with SMTP id WAA23702;
	Fri, 17 Oct 1997 22:53:31 -0400 (EDT)
Received: by merit.edu (bulk_mailer v1.5); Fri, 17 Oct 1997 22:53:10 -0400
Received: (from majordom@localhost)
	by merit.edu (8.8.7/8.8.5) id WAA23684
	for ietf-ppp-outgoing; Fri, 17 Oct 1997 22:53:10 -0400 (EDT)
Received: from Bill.Simpson.DialUp.Mich.Net (pm056-27.dialip.mich.net [141.211.6.227])
	by merit.edu (8.8.7/8.8.5) with SMTP id WAA23677
	for ; Fri, 17 Oct 1997 22:53:04 -0400 (EDT)
Date: Sat, 18 Oct 97 02:02:57 GMT
From: "William Allen Simpson" 
Message-ID: <6706.wsimpson@greendragon.com>
To: ietf-ppp@merit.edu
Cc: iesg@ietf.org
Subject: Re: [Fwd: scrambling PPP over SONET/SDH]
Sender: owner-ietf-ppp@merit.edu

Out of morbid curiousity, I took a look at the Lucent draft text on the
section scrambler, and compared that to the SONET spec in hand.  The
scrambler seems identical, although the older spec says it begins after
the C1 field, whereas the draft says J0/Z0.  There is no J0/Z0 in the
original specification.

So, I looked at the sequence that pmc-sierra supplied for discussion on
the PPPSDH list (that I posted this morning), and for comparison hand
computed the first few bytes from the scrambler diagram.

Let's see, in most significant bit order, we start with 7 one bits:

  1111 111

The xor of the first two bits gives a zero, and this occurs 6 times:

          0  0000 0

The adjacent "10" makes a one bit; the successive zero bits all yield:

                   100  000

The lonely "1" gives 2 ones (left and right xor), followed by 4 zeros:

                           1 1000  0

A pair of ones makes "101", and then 3 more zeros:

                                    101 000

And so on:
                                           1  1110 0100  0101 1001

In summary:

  1111 1110  0000 0100  0001 1000  0101 0001  1110 0100  0101 1001

And the test sequence was:

  FE         04         18         51         E4         59

I'd hate to have to hand check all the bytes, it taken at least 46
minutes to write this up so far, but it seems OK!  The folks at Lucent
must know something that the folks at pmc-sierra and the rest of us
don't know....

But since he swears that this is not the right sequence, I think I'll
just modify my ping to send these bytes out as payload, and see what
happens....


> Date: Fri, 17 Oct 1997 12:12:19 -0400
> From: James Manchester 
> Date: Fri, 17 Oct 1997 11:23:53 -0400
> From: James Manchester 
>
> No wonder you couldn't validate the problem, that is not the right sequence.  Which
> just goes to show that you really don't understand SONET.  Anyone who wants to, can
> come to Holmdel and we will show you our code.
>
> All of the stuff you are putting out on SONET is complete crap.
>
> The internet draft. which is published now, is a easy read if you understand SONET.
> BTW, if you spent five minutes reading the ID, you would already know that you put
> out the wrong code.
>
And such a fine mailer, too....

Is there any particular reason we need every message twice?

With strange unreadable codes stuck in the second time?

> 

    FE 04 18 51 E4 59 D4 FA 1C 49 B5 BD 8D 2E E6 55; >
    FC 08 30 A3 C8 B3 A9 F4 38 93 6B 7B 1A 5D CC AB; >
    F8 10 61 47 91 67 53 E8 71 26 D6 F6 34 BB 99 57; >
    F0 20 C2 8F 22 CE A7 D0 E2 4D AD EC 69 77 32 AF; >
    E0 41 85 1E 45 9D 4F A1 C4 9B 5B D8 D2 EE 65 5F; >
    C0 83 0A 3C 8B 3A 9F 43 89 36 B7 B1 A5 DC CA BF; >
    81 06 14 79 16 75 3E 87 12 6D 6F 63 4B B9 95 7F; >
    02 0C 28 F2 2C EA 7D 0E 24 DA DE C6 97 73 2A; > >

Presumably, the ones counterpart is: > >

    01 FB E7 AE 1B A6 2B 05 E3 B6 4A 42 72 D1 19 AA; >
    03 F7 CF 5C 37 4C 56 0B C7 6C 94 84 E5 A2 33 54; >
    07 EF 9E B8 6E 98 AC 17 8E D9 29 09 CB 44 66 A8; >
    0F DF 3D 70 DD 31 58 2F 1D B2 52 13 96 88 CD 50; >
    1F BE 7A E1 BA 62 B0 5E 3B 64 A4 27 2D 11 9A A0; >
    3F 7C F5 C3 74 C5 60 BC 76 C9 48 4E 5A 23 35 40; >
    7E F9 EB 86 E9 8A C1 78 ED 92 90 9C B4 46 6A 80; >
    FD F3 D7 0D D3 15 82 F1 DB 25 21 39 68 8C D5; > >


>  

WSimpson@UMich.edu
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
- - - - - - - - - - - - - - - - -

From owner-ietf-ppp@merit.edu  Sat Oct 18 01:42:02 1997
Received: from localhost (daemon@localhost)
	by merit.edu (8.8.7/8.8.5) with SMTP id BAA24967;
	Sat, 18 Oct 1997 01:40:31 -0400 (EDT)
Received: by merit.edu (bulk_mailer v1.5); Sat, 18 Oct 1997 01:40:16 -0400
Received: (from majordom@localhost)
	by merit.edu (8.8.7/8.8.5) id BAA24949
	for ietf-ppp-outgoing; Sat, 18 Oct 1997 01:40:16 -0400 (EDT)
Received: from red.juniper.net (red.juniper.net [208.197.169.254])
	by merit.edu (8.8.7/8.8.5) with ESMTP id BAA24945
	for ; Sat, 18 Oct 1997 01:40:12 -0400 (EDT)
Received: from skank.juniper.net (skank.juniper.net [208.197.169.216])
	by red.juniper.net (8.8.5/8.8.5) with ESMTP id WAA09003;
	Fri, 17 Oct 1997 22:39:40 -0700 (PDT)
Received: from skank.juniper.net (localhost.juniper.net [127.0.0.1]) by skank.juniper.net (8.8.4/8.7.3) with ESMTP id WAA26836; Fri, 17 Oct 1997 22:44:24 -0700 (PDT)
Message-Id: <199710180544.WAA26836@skank.juniper.net>
X-Mailer: exmh version 1.6.9 8/22/96
To: dravida@lucent.com (Subra Dravida)
cc: ietf-ppp@merit.edu
Subject: Re: re. scrambler 
In-reply-to: Your message of "17 Oct 1997 15:51:56 GMT."
             <199710171551.LAA13781@hopaw31.qcs> 
Mime-Version: 1.0
Content-Type: text/plain
Date: Fri, 17 Oct 1997 22:44:24 -0700
From: Dennis Ferguson 
Sender: owner-ietf-ppp@merit.edu

Subra,

> The general issues  with self-synchronizing scramblers
> are that they create error multiplication.
> The 1+x**43 scrambler creates a correlated error 43 bits away from
> the original physical layer error.
> There are a number of reasons why error multiplication needs
> to be avoided.

I would note that while I agree with your assertions in general, I also
don't think most of them are particularly relevant to the topic at hand,
which is what to do about octet-synchronous HDLC over SONET/SDH, particularly
if achieving generality requires substantial additional complexity when
the characteristics of the particular problem being solved might yield a
simpler solution.  In particular:

> 1. Error multiplications messes up correction.

This is true, but PPP over SONET does not, and should not, attempt to do
error correction so this does not seem relevant.

> 2. Error multiplication also meeses up detection - parity checks
> can become useless, the detection power of arithmetic checksums 
> and CRCs is also reduced.

This is also true, but note that in fact it is only the effect on CRC
error detection that is relevant to PPP over SONET/SDH since PPP over
SONET/SDH uses a CRC for error detection.

It is true that the self-synchronous scrambler may be expected to weaken
the HDLC CRC, certainly in a theoretical sense, since it effectively turns
n-bit burst errors into n+43-bit burst errors.  The more interesting question,
however, is whether this matters at all in practice?  To estimate this
I'd personally much rather leverage the results of existing practice
that has proved satisfactory then to make up something entirely new,
with its own set of as-yet-unknown practical difficulties.

In particular, it seems to me that the impact of the 1+x^43 scrambler
on the effectiveness of the HDLC CRC will be identical to its impact
on the effectiveness of the ATM AAL5 CRC since the same CRC's are (or can
be) used and the effect of the scrambler on the frame data covered by
the CRC is pretty much identical.  This suggests to me that if the 1+x^43
scrambler `messes up detection' too much for practical use for HDLC over
SONET/SDH it would also be `messing up detection' in an identical fashion
for AAL5.  Yet we have a fairly substantial quantity of ATM equipment
deployed and in use, and while I've heard bad things about ATM the quality
of AAL5 error detection has not been one of them.

> 3. Different applications will have different protocol
> and header sizes - there is no point in being
> linked to the 1+x**43 created for ATM and this scrambler affects 
> even ATM performance.

The possible impact of a self-synchronous scrambler on the effectiveness
of the PPP frame check sequence is the (only) defect of the scheme you've
identified related to its use for PPP over SONET/SDH.  This is a concern.
But I've also got a pretty substantial existance proof that the 1+x^43
scrambler in particular can be implemented in a way which is both robust
and interoperable, and usage experience on frames protected by a standard
32-bit CRC which suggests that concerns about the impact on CRC error
detection performance are unfounded in practice.  I would much rather
leverage successful existing practice than try to invent something entirely
new whose practical defects can only be discovered after a substantial
investment in new implementation.  The fact that 43 is a weird number
doesn't mean it's broken, and if it isn't broken I see no reason to
attempt to fix it.

As for the `performance' comment, to keep this directed to the issue at
hand I'd invite you consider the complexities of implementing an
octet-stuffing HDLC framer at speeds where byte-at-a-time processing is
not an option.  I can assure you that the 1+x^43 scrambler (or just about
any other scrambler you care to chose) won't even come close to being a
factor which gates the upward scalability of HDLC over SONET, and I see no
purpose in over-optimizing something which isn't likely to matter anyway.

In any case, the basic issue again is that we have an existing payload
scrambler for which there is substantial implementation and deployment
experience which appears to work as well (or poorly) for HDLC over SONET
as it does for (AAL5 over) ATM where it is used already.  Given this,
I would have expected to see some explanation of problems the scrambler
has been shown to cause in the ATM environment, or perhaps an indication
of why the scrambler would be less effective for HDLC over SONET than for
AAL5 over ATM, before running off and inventing something entirely new
for which there is no existing implementation nor deployment experience.
While I might be sympathetic to using something else for other applications,
where some of the defects you pointed out above might be actually be of
concern I personally don't think that HDLC over SONET, which is already
in production use, should be the guinea pig for debugging the Grand
Unified Data Scrambler when it would appear to be quite well served
by an existing scheme with which there is substantial practical
experience.

Dennis Ferguson


- - - - - - - - - - - - - - - - -

From owner-ietf-ppp@merit.edu  Sat Oct 18 03:19:08 1997
Received: from localhost (daemon@localhost)
	by merit.edu (8.8.7/8.8.5) with SMTP id DAA25568;
	Sat, 18 Oct 1997 03:17:40 -0400 (EDT)
Received: by merit.edu (bulk_mailer v1.5); Sat, 18 Oct 1997 03:17:10 -0400
Received: (from majordom@localhost)
	by merit.edu (8.8.7/8.8.5) id DAA25549
	for ietf-ppp-outgoing; Sat, 18 Oct 1997 03:17:09 -0400 (EDT)
Received: from red.juniper.net (red.juniper.net [208.197.169.254])
	by merit.edu (8.8.7/8.8.5) with ESMTP id DAA25545
	for ; Sat, 18 Oct 1997 03:17:05 -0400 (EDT)
Received: from skank.juniper.net (skank.juniper.net [208.197.169.216])
	by red.juniper.net (8.8.5/8.8.5) with ESMTP id AAA26246;
	Sat, 18 Oct 1997 00:16:35 -0700 (PDT)
Received: from skank.juniper.net (localhost.juniper.net [127.0.0.1]) by skank.juniper.net (8.8.4/8.7.3) with ESMTP id AAA27649; Sat, 18 Oct 1997 00:21:19 -0700 (PDT)
Message-Id: <199710180721.AAA27649@skank.juniper.net>
X-Mailer: exmh version 1.6.9 8/22/96
To: wsimpson@greendragon.com (William Allen Simpson)
cc: ietf-ppp@merit.edu
Subject: Re: scrambling PPP over SONET/SDH 
In-reply-to: Your message of "17 Oct 1997 12:53:26 GMT."
             <6696.wsimpson@greendragon.com> 
Mime-Version: 1.0
Content-Type: text/plain
Date: Sat, 18 Oct 1997 00:21:19 -0700
From: Dennis Ferguson 
Sender: owner-ietf-ppp@merit.edu

Bill,

> X**43 was good enough for the ATM cell because it starts on every cell,
> the cells do not align at any particular timing with the SPE (so the
> interaction with the section scrambler is unknown) and the cell data is
> only 48 bytes long.  But x**43 still isn't perfect even for ATM, and
> _could_ allow a hit, just not as often.

You are right that the ATM scrambler _could_ allow a `hit', but the
important issue is that the probability of getting an 80-zero-bit `hit'
(assuming you're not directly attached to the circuit and can't wiretap the
scrambled data) is unchanged whether you actively try to send something
to make the circuit burp or you just send random data (i.e. the probability
of getting it just right is probably close to 2**-80 in either case).

> The problem is the "self-synchronizing" nature of the current section
> "scrambler".  It does not really scramble anything, but is merely
> "security through obscurity".  All of us in the security arena know this
> is a bad policy.
> 
> Adding x**43 just modifies the well-known sequence, but does not change
> the problem for PPP payloads, which can be up to 1500 bytes long (by
> default).  Anybody can figure out the new sequence, which will give you
> a hit every few thousand SPEs, the same as without it.

The reference to the SONET section scrambler as `self-synchronizing'
suggests to me that you are misunderstanding exactly how the ATM
1+x^43 feedback scrambler works, and how it is used.  The ATM scrambler
is a payload scrambler, and has no `well-known sequence' at all, at least
to anyone not in a position to monitor the data in scrambled form.

The theoretical defect of the ATM scrambler has nothing to do with its
security but, as was pointed out in the message from Subra Dravida, is
instead that it could weaken the HDLC CRC error detection a bit.  
Since it has (or appears to have) exactly the same theoretical effect
on the ATM AAL5 CRC, but no one I know has observed any problem with its
use for ATM, I'm not sure the defect is worth worrying about.

> Presumably, the ones counterpart is:

? There is no `ones counterpart'.  SONET's on-the-wire encoding is kind of
like an AMI T1 (the latter need to see a 1-bit following no more than 14
zeros, if I remember correctly.  Constraints on payload aren't new
inventions...).  One's give you transitions and zero's don't, so what you
worry about is one's density in the data.

This is a problem that does need to be fixed.  It isn't possible to buy
off-the-shelf SONET clock recovery circuits that perform as you suggest
they should (perhaps indicating that it isn't possible to build them,
either), so demanding that equipment be built this way is equivalent to
demanding that it not be built at all.  That wouldn't be good.

Dennis Ferguson
- - - - - - - - - - - - - - - - -

From owner-ietf-ppp@merit.edu  Sat Oct 18 06:23:16 1997
Received: from localhost (daemon@localhost)
	by merit.edu (8.8.7/8.8.5) with SMTP id GAA26447;
	Sat, 18 Oct 1997 06:19:38 -0400 (EDT)
Received: by merit.edu (bulk_mailer v1.5); Sat, 18 Oct 1997 06:16:32 -0400
Received: (from majordom@localhost)
	by merit.edu (8.8.7/8.8.5) id GAA26423
	for ietf-ppp-outgoing; Sat, 18 Oct 1997 06:16:31 -0400 (EDT)
Received: from Bill.Simpson.DialUp.Mich.Net (pm002-29.dialip.mich.net [141.211.7.165])
	by merit.edu (8.8.7/8.8.5) with SMTP id GAA26416;
	Sat, 18 Oct 1997 06:16:17 -0400 (EDT)
Date: Sat, 18 Oct 97 09:09:29 GMT
From: "William Allen Simpson" 
Message-ID: <6714.wsimpson@greendragon.com>
To: Dennis Ferguson 
Cc: ietf-ppp@merit.edu
Subject: Re: scrambling PPP over SONET/SDH
Sender: owner-ietf-ppp@merit.edu

> From: Dennis Ferguson 
> You are right that the ATM scrambler _could_ allow a `hit', but the
> important issue is that the probability of getting an 80-zero-bit `hit'
> (assuming you're not directly attached to the circuit and can't wiretap the
> scrambled data) is unchanged whether you actively try to send something
> to make the circuit burp or you just send random data (i.e. the probability
> of getting it just right is probably close to 2**-80 in either case).
>
There is a bit of argument about the probability.  My point is that the
octet-stuffing method we agreed upon a few years ago has _zero_
probability.  I have a preference for the perfect solution that is
completely forward and backward compatible over the probable solution.


> The reference to the SONET section scrambler as `self-synchronizing'
> suggests to me that you are misunderstanding exactly how the ATM
> 1+x^43 feedback scrambler works, and how it is used.  The ATM scrambler
> is a payload scrambler, and has no `well-known sequence' at all, at least
> to anyone not in a position to monitor the data in scrambled form.
>
You are correct that I am not familiar with the ATM scrambler.  I was
going by the 1991 Bellcore SONET spec, which says: "A self-synchronous
scrambler with generator polynomial [1+x**43] shall be used.  The
scrambler shall operate for the duration of the 48-byte cell payload."

Perhaps the definition has changed since then?


> ? There is no `ones counterpart'.  SONET's on-the-wire encoding is kind of
> like an AMI T1 (the latter need to see a 1-bit following no more than 14
> zeros, if I remember correctly.  Constraints on payload aren't new
> inventions...).  One's give you transitions and zero's don't, so what you
> worry about is one's density in the data.
>
Ahhh, that explains why they were only interested in zeroes for Loss of
Signal (LOS).

Certainly a lot must have changed since we wrote RFC-1619 -- the 1991
specification available at that time was a zero gave _two_ transitions,
while a one gave only one transition.  There is a whole chapter on it.

I have enough background to understand the B3ZS and CMI electrical line
coding in the specification.  I make no pretense of understanding the
optical work in that chapter, although I did spend my own personal funds
to take the Fotec optical testing course so that I could at least
understand the technology and manage cable installers.


> This is a problem that does need to be fixed.  It isn't possible to buy
> off-the-shelf SONET clock recovery circuits that perform as you suggest
> they should (perhaps indicating that it isn't possible to build them,
> either), so demanding that equipment be built this way is equivalent to
> demanding that it not be built at all.  That wouldn't be good.
>
First of all, I agree that it is a real problem.

When it first cropped up, we assumed it was just an early chip bug, that
we could overcome with software, in a completely transparent and
backwardly compatible manner.  It is a problem that in this field, it is
rather expensive to implement and test before writing the specification.

The entire SONET specification was written without testing, and they
have since revised it several times.  That the IETF insisted on
implementation experience for RFC-1619 was regarded as a novelty.

I beg to differ on buying off-the-shelf SONET clock recovery circuits
with a better PLL.

I will reveal that the _first_ PPP over SONET implementation used an
early TranSwitch SYN155C with SOT-3.  Their PLL was claimed to holdover
2000+ bits, with a good external clock source.  The LOS for the signal
was 26 microseconds.  There were other problems, as this was an early
chip, but we had very nice support from them.  Unfortunately, they were
seduced by the promise of ATM, and are only now coming back to PPP over
SONET.  Very freindly folks (and provided the evaluation chips to us at
no cost).  Talk to them.

And while I'm naming names, it was the earlier PMC-Sierra ATM chip that
Cisco was using that had the 70-bit holdover problem, but their
engineers (and management) assured me that the problem was fixed.

And I have no idea about the ATT nee Lucent chips, because when we were
looking around in 1992-93, ATT refused to even give us the specs on
their chips.  Perhaps they are more open now....

WSimpson@UMich.edu
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
- - - - - - - - - - - - - - - - -

From owner-ietf-ppp@merit.edu  Mon Oct 20 00:41:59 1997
Received: from localhost (daemon@localhost)
	by merit.edu (8.8.7/8.8.5) with SMTP id AAA10897;
	Mon, 20 Oct 1997 00:40:41 -0400 (EDT)
Received: by merit.edu (bulk_mailer v1.5); Mon, 20 Oct 1997 00:37:18 -0400
Received: (from majordom@localhost)
	by merit.edu (8.8.7/8.8.5) id AAA10868
	for ietf-ppp-outgoing; Mon, 20 Oct 1997 00:37:17 -0400 (EDT)
Received: from Bill.Simpson.DialUp.Mich.Net (pm054-03.dialip.mich.net [141.211.6.141])
	by merit.edu (8.8.7/8.8.5) with SMTP id AAA10861;
	Mon, 20 Oct 1997 00:37:09 -0400 (EDT)
Date: Mon, 20 Oct 97 03:51:04 GMT
From: "William Allen Simpson" 
Message-ID: <6726.wsimpson@greendragon.com>
To: ietf-ppp@merit.edu
Subject: Re: ID - PPP over SONET/SDH
Sender: owner-ietf-ppp@merit.edu

Last week, a spurious complaint was sent to the IETF-PPP list, and the
IESG, stating that experiments had revealed a compromise of the
"security" of the SONET/SDH portions of the Internet.  A large number of
conflicting messages ensued, and a great deal of engineering time was
wasted.

After several days of investigation, I have not been able to discover any
incident report from any NSP using PPP over SONET/SDH (sometimes called
POS) that the "security" of the Internet has been compromised with
regard to POS.
    **                                                             **
    **         THERE IS NO URGENT OPERATIONAL PROBLEM.             **
    **                                                             **
Rather than further burdening the IETF-PPP list with this discussion,
interested parties are invited to the existing PPPSDH@greendragon.com
list.  Send the usual "subscribe pppsdh" message body to pppsdh-REQUEST,
or .

After giving folks time to join, the discussion will begin at 15:00 EDT
Monday on the topic: "the current explanation of Loss Of Signal (LOS)".
By having a daily topic, I hope to cover all the important issues in the
next 2 weeks, without all the distractions and hyperbole.  Thank you for
your indulgence.

I have asked to chair a BOF on this topic at the next meeting of the
IETF in December, but I expect most issues to be easily resolved once
all parties are using the same definitions and any relevant changes in
the SONET/SDH specification over the past 3 years are well understood.


> Date: Thu, 16 Oct 1997 09:39:26 -0400
> From: kris 
> The reason for our ID is that we verfied by experiment that a
> PPP over SONET/SDH implementation that merely conforms to RFC 1619
> (no scrambling) severely compromises the security of the SONET/SDH layer.
> In fact the malicious datagrams can be transmitted from anywhere in
> the Internet. The user need not be directly connected to the SONET
> network.
>...
> Murali Krishnaswamy
> murali@lucent.com
>

WSimpson@UMich.edu
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
- - - - - - - - - - - - - - - - -

From owner-ietf-ppp@merit.edu  Mon Oct 20 03:32:45 1997
Received: from localhost (daemon@localhost)
	by merit.edu (8.8.7/8.8.5) with SMTP id DAA12280;
	Mon, 20 Oct 1997 03:31:18 -0400 (EDT)
Received: by merit.edu (bulk_mailer v1.5); Mon, 20 Oct 1997 03:30:27 -0400
Received: (from majordom@localhost)
	by merit.edu (8.8.7/8.8.5) id DAA12255
	for ietf-ppp-outgoing; Mon, 20 Oct 1997 03:30:26 -0400 (EDT)
Received: from rnd-gate.rad.co.il (rnd-gate.rad.co.il [207.232.32.14])
	by merit.edu (8.8.7/8.8.5) with ESMTP id DAA12251
	for ; Mon, 20 Oct 1997 03:30:16 -0400 (EDT)
Received: from messenger.rad.co.il ([176.192.111.45]) by rnd-gate.rad.co.il (8.7.3/8.7.3) with ESMTP id JAA01732 for ; Mon, 20 Oct 1997 09:17:33 +0200 (IST)
Received: by MESSENGER with Internet Mail Service (5.0.1458.49)
	id ; Mon, 20 Oct 1997 09:31:51 +0200
Message-ID: <0124851EDBF3D011AAA300008370C8670A7C05@MESSENGER>
From: Zohar Agrest 
To: ietf-ppp@merit.edu
Subject: Microsoft CHAP
Date: Mon, 20 Oct 1997 09:31:49 +0200
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: owner-ietf-ppp@merit.edu

Hi All,

We implemented CHAP according to the RFC standard,it's works fine with
CISCO,
now we are heading towards checking with MS_CHAP.
From few e_mail that we mange to see in this list,we understood that
MS_CHAP
is not standard.

We would like to know in what ways MS_CHAP is not according to the
standard ?

TIA Zohar.
- - - - - - - - - - - - - - - - -

From owner-ietf-ppp@merit.edu  Mon Oct 20 03:53:25 1997
Received: from localhost (daemon@localhost)
	by merit.edu (8.8.7/8.8.5) with SMTP id DAA12447;
	Mon, 20 Oct 1997 03:53:17 -0400 (EDT)
Received: by merit.edu (bulk_mailer v1.5); Mon, 20 Oct 1997 03:53:10 -0400
Received: (from majordom@localhost)
	by merit.edu (8.8.7/8.8.5) id DAA12429
	for ietf-ppp-outgoing; Mon, 20 Oct 1997 03:53:10 -0400 (EDT)
Received: from hursley.ibm.com (mersey.hursley.ibm.com [194.196.110.10])
	by merit.edu (8.8.7/8.8.5) with SMTP id DAA12425
	for ; Mon, 20 Oct 1997 03:53:02 -0400 (EDT)
Received: by hursley.ibm.com (AIX 3.2/UCB 5.64/4.03)
          id AA35064; Mon, 20 Oct 1997 08:52:30 +0100
Date: Mon, 20 Oct 1997 08:52:30 +0100
Message-Id: <9710200752.AA35064@hursley.ibm.com>
From: "(Brian E Carpenter)" 
Subject: Re: New ID - PPP Over SONET Mapping
To: kris@hotair.hobl.lucent.com (kris)
Cc: ietf-ppp@merit.edu, iesg@ietf.org
In-Reply-To: <9710171828.AA24547@hotair.hobl.lucent.com> from "kris" at Oct 17, 97 02:28:50 pm
Reply-To: brian@hursley.ibm.com
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-ietf-ppp@merit.edu

> 
> Murali Krishnaswamy
> murali@bell-labs.com
> 
....
> 
> As such, T1X1 is urgently developing a solution to the above noted 
> technical flaw and intends to publish the IP/PPP mapping for SONET 
> signals in ANSI T1.105. 

This is not an available option. IP and PPP mappings are
standardised by the IETF, not by ANSI. 

  Brian E Carpenter (IAB Chair)           brian@hursley.ibm.com
  IBM United Kingdom Laboratories         http://www.hursley.ibm.com/~bc/
  MP 185                                  phone: +44 1962 816833
  Hursley Park                            fax:   +44 1962 818101
  Winchester
  Hampshire SO21 2JN, UK
- - - - - - - - - - - - - - - - -

From owner-ietf-ppp@merit.edu  Mon Oct 20 04:02:48 1997
Received: from localhost (daemon@localhost)
	by merit.edu (8.8.7/8.8.5) with SMTP id EAA12528;
	Mon, 20 Oct 1997 04:02:42 -0400 (EDT)
Received: by merit.edu (bulk_mailer v1.5); Mon, 20 Oct 1997 04:02:31 -0400
Received: (from majordom@localhost)
	by merit.edu (8.8.7/8.8.5) id EAA12505
	for ietf-ppp-outgoing; Mon, 20 Oct 1997 04:02:31 -0400 (EDT)
Received: from hursley.ibm.com (mersey.hursley.ibm.com [194.196.110.10])
	by merit.edu (8.8.7/8.8.5) with SMTP id EAA12501
	for ; Mon, 20 Oct 1997 04:02:27 -0400 (EDT)
Received: by hursley.ibm.com (AIX 3.2/UCB 5.64/4.03)
          id AA13233; Mon, 20 Oct 1997 09:01:55 +0100
Date: Mon, 20 Oct 1997 09:01:55 +0100
Message-Id: <9710200801.AA13233@hursley.ibm.com>
From: "(Brian E Carpenter)" 
Subject: Re: New ID - PPP Over SONET Mapping
To: evarma@lucent.com (Eve Varma)
Cc: mo@UU.NET, kris@hotair.hobl.lucent.com, ietf-ppp@merit.edu, iesg@ietf.org
In-Reply-To: <3447C1D8.8A262CA4@lucent.com> from "Eve Varma" at Oct 17, 97 03:51:52 pm
Reply-To: brian@hursley.ibm.com
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-ietf-ppp@merit.edu

Eve,

Marriage is easy if the people who have identified a possible technical
issue in an IETF document use the well established IETF mechanisms
to address that issue. Anything else *by definition* creates a
collision. The IETF isn't creating an issue here; ANSI is.

  Brian Carpenter

>- Eve Varma said:
> 
> I would suggest you re-read the unofficial T1X1 liaison regarding their
> recognized scope of responsibility.   In any event, at this point I
> would think our concerns and actions
> should be on mitigating the negative impacts that may be experienced by
> vendors and network providers because of this specification.  The IP
> over SONET mapping failed to consider the SONET mapping criteria
> established in 1988, and it is becoming increasingly clear that
> SONET/SDH transport networking expertise was not adequately coupled into
> its generation. The internet and transport networking worlds have come
> together - let's
> have it be more of a marriage than a collision please.
>                                        Eve Varma
> 
> 
> Mike O'Dell wrote:
> 
> > excuse me, but the IETF will publish any revised IP-over-SONET spec.
> >
> > I don't remember ceding change control to anyone.
> >
> >         -mo
> 
> 
> 
> 

- - - - - - - - - - - - - - - - -

From owner-ietf-ppp@merit.edu  Mon Oct 20 08:47:14 1997
Received: from localhost (daemon@localhost)
	by merit.edu (8.8.7/8.8.5) with SMTP id IAA14538;
	Mon, 20 Oct 1997 08:45:59 -0400 (EDT)
Received: by merit.edu (bulk_mailer v1.5); Mon, 20 Oct 1997 08:41:14 -0400
Received: (from majordom@localhost)
	by merit.edu (8.8.7/8.8.5) id IAA14413
	for ietf-ppp-outgoing; Mon, 20 Oct 1997 08:41:13 -0400 (EDT)
Received: from mail12.digital.com (mail12.digital.com [192.208.46.20])
	by merit.edu (8.8.7/8.8.5) with ESMTP id IAA14409
	for ; Mon, 20 Oct 1997 08:41:09 -0400 (EDT)
Received: from wasted.zk3.dec.com (bwasted.zk3.dec.com [16.140.128.41])
	by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id IAA16558;
	Mon, 20 Oct 1997 08:31:13 -0400 (EDT)
Received: from marvin.zk3.dec.com by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM)
	id AA01388; Mon, 20 Oct 1997 08:31:11 -0400
Message-Id: <344B4F0F.59E2@zk3.dec.com>
Date: Mon, 20 Oct 1997 08:31:11 -0400
From: "Farrell T. Woods - UNIX Networking" 
Organization: Digital Equipment Corporation
X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 T4.0 alpha)
Mime-Version: 1.0
To: ietf-ppp@merit.edu
Cc: audrey@vanb.com
Subject: [Fwd: Announcing Connectathon 98!]
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-ppp@merit.edu

Hello folks,

This is the official announcement for Connectathon 98.  Please contact
me directly if you wish to participate in PPP interoperability
testing (and debugging!)  Thanks!

	-- Farrell

    ---------------------------------------------------------------

Subject: Announcing Connectathon 98!
Date: Sun, 12 Oct 1997 15:54:24 -0700
From: Audrey Van Belleghem 
Organization: Van Belleghem Corporation
To: audrey@vanb.com

Plans for Connectathon 98 are already under way!  The 12th annual
Connectathon event, an interoperability testing event for engineers
only, will be held March 4-12, 1998, in San Jose, California.
Connectathon, sponsored by Sun Microsystems, Inc., hosts over 30
companies annually in an effort to test and debug source code which
utilize the following technologies and protocols:

NFS and WebNFS
PPP
DHCP
Service Location Protocol
NIS/NIS+
TI-RPC
Automounter

Based on demand, in addition we are considering to offer:
 
IPv6
LDAP
HTTP

If you are interested in testing IPv6, LDAP or HTTP, please send a note
to Cthon@Sun.COM and we'll gauge interest.  Or if you have a suggestion
for another technology, feel free to contact us as well.
 
Testing continues 24 hours per day.  Technology testing coordinators
will organize testing procedures and test suite material.  In addition,
there will be seminars with speakers addressing various topics.
 
The registration deadline is February 1, 1998.  For a registration
packet, please send complete address and fax number to Cthon@Sun.COM, or
 
if you have any questions, please feel free to contact Audrey Van
Belleghem at (408) 358-9598.  For more information about Connectathon,
we will be updating our web site continually at
http://www.sun.com/sunsoft/connectathon.
 
We look forward to seeing you at the 12th annual Connectathon event!

Audrey Van Belleghem
Connectathon Manager
- - - - - - - - - - - - - - - - -

From owner-ietf-ppp@merit.edu  Mon Oct 20 09:28:18 1997
Received: from localhost (daemon@localhost)
	by merit.edu (8.8.7/8.8.5) with SMTP id JAA15129;
	Mon, 20 Oct 1997 09:28:15 -0400 (EDT)
Received: by merit.edu (bulk_mailer v1.5); Mon, 20 Oct 1997 09:27:55 -0400
Received: (from majordom@localhost)
	by merit.edu (8.8.7/8.8.5) id JAA15107
	for ietf-ppp-outgoing; Mon, 20 Oct 1997 09:27:54 -0400 (EDT)
Received: from cbgw1.lucent.com (cbgw1.lucent.com [207.24.196.51])
	by merit.edu (8.8.7/8.8.5) with SMTP id JAA15103
	for ; Mon, 20 Oct 1997 09:27:50 -0400 (EDT)
From: gmg@hotair.hobl.lucent.com
Received: from hotair.hobl.lucent.com by cbig1.firewall.lucent.com (SMI-8.6/EMS-L sol2)
	id JAA29446; Mon, 20 Oct 1997 09:18:16 -0400
Received: from sync1.hobl.lucent.com by hotair.hobl.lucent.com (4.1/EMS-L SunOS)
	id AA22086; Mon, 20 Oct 97 09:27:36 EDT
Received: by sync1.hobl.lucent.com (SMI-8.6/EMS-L sol2)
	id JAA03165; Mon, 20 Oct 1997 09:27:23 -0400
Date: Mon, 20 Oct 1997 09:27:23 -0400
Message-Id: <199710201327.JAA03165@sync1.hobl.lucent.com>
To: ietf-ppp@merit.edu
Subject: Re: stable SONET/SDH clocks and timing
X-Sun-Charset: US-ASCII
Sender: owner-ietf-ppp@merit.edu


This is in response to William Simpson's email of Friday evening, 10/17:

> > From: gmg@hotair.hobl.lucent.com
> > As I have indicated in the background material below, even if external timing
> > is used, the SONET NE must still produce a derived DS1.  It does this by
> > recovering timing from the incoming OC-N SONET facility on which timing is
> > distributed.  If we are distributing timing in a SONET Network, we must
> > obtain the timing from the SONET facilities.
> 
> As far as I can tell, there seems to be some confusion in your messages
> between distributing the "DS1" (125 microsecond) timing of the start of
> frames in a SONET-SDH network, and the clocks recovering timing of the
> bits on the link (measured in nanoseconds and picoseconds).

> The DS1 frame timing is really irrelevant to PPP or the payload
> contents or the scrambling.  IP routers buffer packets.  SONET frame
> alignment between multiple routers is not an issue.
> 
> You cannot distribute the bit timing, the intervals are too small, and
> different paths would yield different results, speed of light problem.

There is no confusing in my message; I was simply responding to your message
of 10/17, which I reproduce here:

> This is probably horribly cheeky of me, but I just went and checked my
> copy of SONET.  The run of zero bits is only a problem when "line
> timing" is used; that is, the timing is derived from the incoming OC-N
> signal.
> 
> But the requirements clearly state (5.4.2.1) "... external timing from
> a BITS clock is the preferred mode of synchronizing SONET NEs."
> 
> So, the theoretical problem is that some folks didn't follow the SONET
> recommendation.  Why should we design around bad implementations?

As you can see, your email brought up line timing and external timing
in SONET networks,  and cited the recommendation in GR-253
that "...external timing from a BITS clock is the preferred mode of
synchronizing SONET NEs." I was merely pointing out that, when external timing
is done, the timing input to the BITS clock is usually still derived from the
line.  I probably should have stated more explicitly that, regardless of how
synchronization is distributed in the SONET network, timing recovery on the
incoming line must be performed to obtain the incoming data.  I will repeat
what Eve Varma said in her response:  SONET clocks have nothing to do with
the problem cited.  At least you do seem to agree with this now, in saying that
"You cannot distribute the bit timing, the intervals are too small, and
different paths would yield different results, speed of light problem."  That
is precisely the point; you cannot distribute the bit timing, but must recover
it from the line.  The internal SONET Network Element Clock has nothing to
do with this.

Regarding the terminology I have used, it is standard in the
area of timing and synchronization (which I have been involved in),
especially in telecommunications applications.  The terms are used (and defined)
in many of the standards; they are also described in the article that I
referred to in my earlier email (John Bellamy, "Digital Network
Synchronization," IEEE Communications Magazine, April, 1995).  

Geoff Garner
gmgarner@lucent.com
- - - - - - - - - - - - - - - - -

From owner-ietf-ppp@merit.edu  Mon Oct 20 12:34:08 1997
Received: from localhost (daemon@localhost)
	by merit.edu (8.8.7/8.8.5) with SMTP id MAA18798;
	Mon, 20 Oct 1997 12:33:54 -0400 (EDT)
Received: by merit.edu (bulk_mailer v1.5); Mon, 20 Oct 1997 12:33:08 -0400
Received: (from majordom@localhost)
	by merit.edu (8.8.7/8.8.5) id MAA18704
	for ietf-ppp-outgoing; Mon, 20 Oct 1997 12:33:07 -0400 (EDT)
Received: from poptart.corp.home.net (poptart.svr.home.net [24.0.26.24])
	by merit.edu (8.8.7/8.8.5) with ESMTP id MAA18699;
	Mon, 20 Oct 1997 12:33:01 -0400 (EDT)
Received: from borg.eos.home.net ([24.0.16.111]) by poptart.corp.home.net
          (Netscape Mail Server v2.02) with ESMTP id AAA14037;
          Mon, 20 Oct 1997 09:32:43 -0700
Received: (from rja@localhost)
	by borg.eos.home.net (8.8.5/8.8.5) id JAA03527;
	Mon, 20 Oct 1997 09:32:55 -0700 (PDT)
From: rja@corp.home.net (Ran Atkinson)
Message-Id: <971020093254.ZM3525@borg.eos.home.net>
Date: Mon, 20 Oct 1997 09:32:54 -0700
In-Reply-To: "William Allen Simpson" 
        "Packet over SONet/SDH (POS) experience?" (Oct 19,  8:12)
References: <6720.wsimpson@greendragon.com>
X-Mailer: Z-Mail (4.0.1 13Jan97)
To: nanog@merit.edu, ietf-ppp@merit.edu
Subject: Re: Packet over SONet/SDH (POS) experience?
Cc: wsimpson@greendragon.com, pppsdh@greendragon.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ietf-ppp@merit.edu

On Oct 19  8:12, William Allen Simpson wrote:

% There has been a recent bit of scare mongering from Lucent about PPP
% over SONet/SDH over on the IETF-PPP list.

% Has anyone (that has deployed) been having incident reports?
>-- End of excerpt from William Allen Simpson

Bill,

	There are known operational incidents where an adversary sent
an IP packet designed to set the SONET scrambling algorithm ["f(x)"]
to all zeros.  This caused the SONET device to lose communications
syncronisation and the circuit to go down, requiring a manual reset.
Truly an ugly situation.

I've known about this issue ever since the PPP/SONET spec was
published, but have withheld public comment until someone else
mentioned the issue on a public list.

Cisco originally was going to implement a scrambler in its PPP/SONET
implementation (IOS folks like gmc definitely understood the issue),
but the cisco hardware types would not accept free clue and didn't
include the scrambler.  Basically all the PPP/SONET implementations
I know about can be taken out with a single well-known (and
easily calculated) IP datagram.

Sigh.

I have not seen the Lucent proposal myself, so I'm not sure what
it looks like.

From time to time I've talked with a couple of folks at a small
networking startup in Mountain View about this issue.  My suggestions
to them have been of the form below:

	Add a scrambler algorithm to the PPP/SONET spec.
A reasonable approach to that scrambler might be something of
the general form:
	X^^A + X^^B + C

Where:
	^^ is the exponentiation operator
	A,B are prime numbers with O(10) or larger.
	(A > B)
	C is a prime number other than 1.

Adding additional exponential terms might generally strengthen
the algorithm, but intuitively I believe that the above form
is a reasonable tradeoff between implementation complexity and
strength.  It is crucial that the selected algorithm be checked
against the SONET scrambler.  An early proposal for ATM-layer
scrambling (since fixed) had the property that it fought with the
SONET-layer scrambler.

At this point, an implementation would want to retain backward
compatibility with the deployed systems.  Hence, I'd suggest
that implementers put in a knob letting administrators select
either "no PPP scrambling" or "PPP scrambling".  Clearly *I* don't
want to buy products that have the vulnerability noted at the top.

Ran
rja@home.net

PS: I'm not on the PPP or PPPSDH lists, so if folks on those lists
  want me to see any followups, those folks will need to Cc: me
  directly.

PPS:  The followups list definitely will need trimming.  Please
  edit appropriately if you followup...





- - - - - - - - - - - - - - - - -

From owner-ietf-ppp@merit.edu  Mon Oct 20 15:52:40 1997
Received: from localhost (daemon@localhost)
	by merit.edu (8.8.7/8.8.5) with SMTP id PAA23791;
	Mon, 20 Oct 1997 15:52:12 -0400 (EDT)
Received: by merit.edu (bulk_mailer v1.5); Mon, 20 Oct 1997 15:51:35 -0400
Received: (from majordom@localhost)
	by merit.edu (8.8.7/8.8.5) id PAA23756
	for ietf-ppp-outgoing; Mon, 20 Oct 1997 15:51:34 -0400 (EDT)
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by merit.edu (8.8.7/8.8.5) with ESMTP id PAA23750
	for ; Mon, 20 Oct 1997 15:51:24 -0400 (EDT)
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (AIX4.2/UCB 8.7/8.7RTP-FW1.1) with ESMTP id PAA18478; Mon, 20 Oct 1997 15:50:44 -0400 (EDT)
Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.83.123])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id PAA35830;
	Mon, 20 Oct 1997 15:50:46 -0400
Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA20902; Mon, 20 Oct 1997 15:50:48 -0400
Message-Id: <9710201950.AA20902@cichlid.raleigh.ibm.com>
To: "William Allen Simpson" 
Cc: ietf-ppp@merit.edu
Subject: Re: ID - PPP over SONET/SDH 
In-Reply-To: Your message of "Mon, 20 Oct 1997 03:51:04 GMT."
             <6726.wsimpson@greendragon.com> 
Date: Mon, 20 Oct 1997 15:50:44 -0400
From: Thomas Narten 
Sender: owner-ietf-ppp@merit.edu

Bill,

> Rather than further burdening the IETF-PPP list with this discussion,
> interested parties are invited to the existing PPPSDH@greendragon.com
> list.  Send the usual "subscribe pppsdh" message body to pppsdh-REQUEST,
> or .

We think this is an appropriate discussion for the PPP mailing list
and the entire community benefits from the interaction. Also, since
RFC1619 is a Proposed Standard, having this discussion take place on
the ppp mailing is appropriate.

> I have asked to chair a BOF on this topic at the next meeting of the
> IETF in December

Your informal request has been noted. Since this relates to work that
had been done in a WG that is still active, we would first like to
discuss further work items with the WG chair. Whether discussion on
this topic should continue on the ppp list or migrate to a new one
would be considered at that time.  

Jeffrey Burgan
Thomas Narten
IETF Area Directors for the Internet Area
- - - - - - - - - - - - - - - - -

From owner-ietf-ppp@merit.edu  Wed Oct 22 09:35:55 1997
Received: from localhost (daemon@localhost)
	by merit.edu (8.8.7/8.8.5) with SMTP id JAA26384;
	Wed, 22 Oct 1997 09:34:53 -0400 (EDT)
Received: by merit.edu (bulk_mailer v1.5); Wed, 22 Oct 1997 09:32:15 -0400
Received: (from majordom@localhost)
	by merit.edu (8.8.7/8.8.5) id JAA26316
	for ietf-ppp-outgoing; Wed, 22 Oct 1997 09:32:14 -0400 (EDT)
Received: from ietf.org (ietf.org [132.151.1.19])
	by merit.edu (8.8.7/8.8.5) with ESMTP id JAA26300
	for ; Wed, 22 Oct 1997 09:32:05 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.8.7/8.8.7a) with ESMTP id JAA23086;
	Wed, 22 Oct 1997 09:31:39 -0400 (EDT)
Message-Id: <199710221331.JAA23086@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce@ietf.org
Cc: ietf-ppp@merit.edu, l2tp@zendo.com
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-pppext-l2tp-07.txt
Date: Wed, 22 Oct 1997 09:31:35 -0400
Sender: owner-ietf-ppp@merit.edu

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF.

	Title		: Layer Two Tunneling Protocol 'L2TP'
	Author(s)	: W. Palter, T. Kolar, G. Pall, A. Rubens
                          M. Littlewood, A. Valencia, K. Hamzeh, 
                          W. Verthein, J. Taarud, W. Townsley
	Filename	: draft-ietf-pppext-l2tp-07.txt
	Pages		: 87
	Date		: 21-Oct-97
	
   Virtual dial-up allows many separate and autonomous protocol domains
   to share common access infrastructure including modems, Access
   Servers, and ISDN routers.  RFC1661 specifies multiprotocol dial-up
   via PPP [1].  This document describes the Layer Two Tunneling
   Protocol (L2TP) which permits the tunneling of the link layer (i.e.,
   HDLC, async HDLC) of PPP.  Using such tunnels, it is possible to
   divorce the location of the initial dial-up server from the location
   at which the dial-up protocol connection is terminated and access to
   the network provided.

Internet-Drafts are available by anonymous FTP.  Login wih the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pppext-l2tp-07.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-l2tp-07.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	mailserv@ds.internic.net.  In the body type:
	"FILE /internet-drafts/draft-ietf-pppext-l2tp-07.txt".
	
NOTE:	The mail server at ds.internic.net can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ds.internic.net"

Content-Type: text/plain
Content-ID:	<19971021110929.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-pppext-l2tp-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pppext-l2tp-07.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19971021110929.I-D@ietf.org>

--OtherAccess--

--NextPart--


- - - - - - - - - - - - - - - - -

From owner-ietf-ppp@merit.edu  Wed Oct 22 09:35:55 1997
Received: from localhost (daemon@localhost)
	by merit.edu (8.8.7/8.8.5) with SMTP id JAA26380;
	Wed, 22 Oct 1997 09:34:52 -0400 (EDT)
Received: by merit.edu (bulk_mailer v1.5); Wed, 22 Oct 1997 09:32:17 -0400
Received: (from majordom@localhost)
	by merit.edu (8.8.7/8.8.5) id JAA26323
	for ietf-ppp-outgoing; Wed, 22 Oct 1997 09:32:16 -0400 (EDT)
Received: from ietf.org (ietf.org [132.151.1.19])
	by merit.edu (8.8.7/8.8.5) with ESMTP id JAA26301
	for ; Wed, 22 Oct 1997 09:32:05 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.8.7/8.8.7a) with ESMTP id JAA23134;
	Wed, 22 Oct 1997 09:31:45 -0400 (EDT)
Message-Id: <199710221331.JAA23134@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce@ietf.org
Cc: ietf-ppp@merit.edu
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-pppext-eaptls-02.txt
Date: Wed, 22 Oct 1997 09:31:45 -0400
Sender: owner-ietf-ppp@merit.edu

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF.

	Title		: PPP EAP TLS Authentication Protocol
	Author(s)	: B. Aboba, D. Simon
	Filename	: draft-ietf-pppext-eaptls-02.txt
	Pages		: 22
	Date		: 21-Oct-97
	
The  Point-to-Point  Protocol  (PPP)  provides  a  standard method for
     transporting multi-protocol datagrams over point-to-point links.   PPP
     also  defines  an extensible Link Control Protocol (LCP), which can be
     used to negotiate authentication methods, as  well  as  an  Encryption
     Control  Protocol  (ECP),  used  to negotiate data encryption over PPP
     links, and a Compression Control Protocol  (CCP),  used  to  negotiate
     compression  methods.  The Extensible Authentication Protocol (EAP) is
     a PPP extension that provides support  for  additional  authentication
     methods within PPP.
 
     Transport  Level  Security  (TLS)  provides for mutual authentication,
     integrity-protected ciphersuite negotiation and key  exchange  between
     two  endpoints.   This  document describes how EAP-TLS, which includes
     support for fragmentation and reassembly, provides for these TLS mech-
     anisms within EAP.

Internet-Drafts are available by anonymous FTP.  Login wih the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pppext-eaptls-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-eaptls-02.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	mailserv@ds.internic.net.  In the body type:
	"FILE /internet-drafts/draft-ietf-pppext-eaptls-02.txt".
	
NOTE:	The mail server at ds.internic.net can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ds.internic.net"

Content-Type: text/plain
Content-ID:	<19971021130715.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-pppext-eaptls-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pppext-eaptls-02.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19971021130715.I-D@ietf.org>

--OtherAccess--

--NextPart--


- - - - - - - - - - - - - - - - -