From ietf-ppp-request@MERIT.EDU Fri Mar 1 11:08:47 1996 Received: (from slist@localhost) by merit.edu (8.7.3/merit-2.0) id LAA21565; Fri, 1 Mar 1996 11:08:47 -0500 (EST) Resent-Date: Fri, 1 Mar 1996 11:08:47 -0500 (EST) Date: Fri, 1 Mar 96 10:02:48 CST Message-Id: <9603011602.AA04852@adtrn-ws01.adtran.com> X-Sender: kfrnswrt@mail Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ietf-ppp@MERIT.EDU From: kfarnsworth@adtran.com (Kyle Farnsworth) Subject: RE: Extended Mode in stacker-06 Cc: ietf-ppp@MERIT.EDU X-Mailer: Resent-Message-ID: <"dkXwK3.0.bG5.q2oDn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1275 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > >> > Bit C in the Extended Mode Packet header is defined to be set when the >> > packet contains compressed data and reset when the packet contains >> > uncompressed data. >> > If uncompressed data is sent in with Bit C = 0 does that mean that it still >> > could contain History table information and has to go though the >> > decompressor? > >> No. Extended mode follows the convention of Option 17: when C=0 that means >> the data expanded and the compressor's history is reset (so Bit-A will be >> set and bit-C will be cleared in this case). The receiver will not update >> the decompressor's history when bit C is cleared. >> >> > Also, does all uncompressed data HAVE to be transmitted in this manner? Why >> > not send it in it's original PPP packet? > >> Either way should work. > vjs@mica.denver.sgi.com (Vernon Schryver) wrote: > >If the transmitter started out with a 1500 byte (or whatever the MTU) >packet, then how is it going to be able to add a LZS header to the >packet to contain the C=0 bit? > >The only and rather unlikely case this might make sense is when the >original packet was less than the MTU, and it expend by enough to be >more than the MTU. A tinygram that expanded but still fits within the >MTU should be sent compressed to train the dictionaries so that future >packets will compress instead of expand. > Yes one should send the "tinygram" that expanded to train the rx dictionaries but in that case the C bit should be 1 forcing it to be sent through the Decompressor. It appears to me that if the one receives a packet with the C bit = 0 then it is the original PPP packet with no compression information and therefore should never be sent through the stac decompressor. Right Rob? Maybe someone from Microsoft can verify this for us since it's their check mode. -------------------------------------------------------- Kyle Farnsworth ADTRAN Inc. (205)971-8583 kfarnsworth@adtran.com -------------------------------------------------------- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Mar 4 13:17:01 1996 Received: (from slist@localhost) by merit.edu (8.7.3/merit-2.0) id NAA22090; Mon, 4 Mar 1996 13:17:01 -0500 (EST) Resent-Date: Mon, 4 Mar 1996 13:17:01 -0500 (EST) From: Rob Friend To: IETF-PPP Subject: RE: Extended Mode in stacker-06 Date: Mon, 04 Mar 96 10:13:00 PST Message-Id: <313B32EC@smtpgateway.stac.com> Encoding: 69 TEXT X-Mailer: Microsoft Mail V3.0 Resent-Message-ID: <"l7GPl.0.bO5.HDpEn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1276 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU On Friday, March 01, 1996 10:02AM kfarnsworth@adtran.com (Kyle Farnsworth) wrote: > ---------------------------------------------------------------------------- -- > > > >> > Bit C in the Extended Mode Packet header is defined to be set when the > >> > packet contains compressed data and reset when the packet contains > >> > uncompressed data. > >> > If uncompressed data is sent in with Bit C = 0 does that mean that it > still > >> > could contain History table information and has to go though the > >> > decompressor? > > > >> No. Extended mode follows the convention of Option 17: when C=0 that > means > >> the data expanded and the compressor's history is reset (so Bit-A will be > >> set and bit-C will be cleared in this case). The receiver will not update > >> the decompressor's history when bit C is cleared. > >> > >> > Also, does all uncompressed data HAVE to be transmitted in this manner? > Why > >> > not send it in it's original PPP packet? > > > >> Either way should work. > > > vjs@mica.denver.sgi.com (Vernon Schryver) wrote: > > > >If the transmitter started out with a 1500 byte (or whatever the MTU) > >packet, then how is it going to be able to add a LZS header to the > >packet to contain the C=0 bit? > > > >The only and rather unlikely case this might make sense is when the > >original packet was less than the MTU, and it expend by enough to be > >more than the MTU. A tinygram that expanded but still fits within the > >MTU should be sent compressed to train the dictionaries so that future > >packets will compress instead of expand. > > > Yes one should send the "tinygram" that expanded to train the rx > dictionaries but in that case the C bit should be 1 forcing it to be sent > through the Decompressor. It appears to me that if the one receives a > packet with the C bit = 0 then it is the original PPP packet with no > compression information and therefore should never be sent through the stac > decompressor. Right Rob? Sending the expanded "tinygram" will preserve future bandwidth at the cost of current bandwidth. In this case the C bit should be set to 1 to run it through the decompressor. Yes, if the C bit is 0 then the CCP packet contains raw data and should not be sent through the decompressor. However, Win95 does not do that. If there is expansion, then their transmitter will clear the C bit, set the A bit, reset the compression history, and send the raw data. > Maybe someone from Microsoft can verify this for us since it's their check > mode. Been there; done that. Regards, Robert C. Friend Stac Electronics Applications Engineering 12636 High Bluff Dr (619)794-4542 (voice) San Diego, CA 92130 (619)794-4577 (FAX) Email:rfriend@stac.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Mar 4 22:58:17 1996 Received: (from slist@localhost) by merit.edu (8.7.4/merit-2.0) id WAA07584; Mon, 4 Mar 1996 22:58:17 -0500 (EST) Resent-Date: Mon, 4 Mar 1996 22:58:17 -0500 (EST) X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 4 Mar 1996 19:57:29 -0800 To: ietf-ppp@MERIT.EDU From: fred@cisco.com (Fred Baker) Subject: Request for CHAP Experience Resent-Message-ID: <"cJD8p3.0.Hs1.ElxEn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1277 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU We are attempting to take CHAP to Draft Standard. Would everyone who has an implementation, please drop me a note indicating: that they have an implementation who they have tested with and found interoperable if they have found non-interoperable implementations, what needs to be changed in the rfc. Tell me also if you have implemented the MIB, what portions you did not implement, and what recommendations you have concerning it. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= It has recently been discovered that research causes cancer in rats. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Mar 4 22:59:22 1996 Received: (from slist@localhost) by merit.edu (8.7.4/merit-2.0) id WAA07678; Mon, 4 Mar 1996 22:59:22 -0500 (EST) Resent-Date: Mon, 4 Mar 1996 22:59:22 -0500 (EST) X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 4 Mar 1996 19:58:10 -0800 To: ietf-ppp@MERIT.EDU From: fred@cisco.com (Fred Baker) Subject: PPP SNA Control Protocol - Working Group Last Call Resent-Message-ID: <"TfVY8.0.Yt1.GmxEn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1279 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU This is last call. I will advise the area director that we want to take the PPP SNA Control Protocol to Proposed Standard on March 18, unless there is substantive comment raised on the list. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= It has recently been discovered that research causes cancer in rats. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Mar 4 22:59:27 1996 Received: (from slist@localhost) by merit.edu (8.7.4/merit-2.0) id WAA07689; Mon, 4 Mar 1996 22:59:27 -0500 (EST) Resent-Date: Mon, 4 Mar 1996 22:59:27 -0500 (EST) X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 4 Mar 1996 19:58:29 -0800 To: ietf-ppp@MERIT.EDU From: fred@cisco.com (Fred Baker) Subject: Request for Multilink Experience Resent-Message-ID: <"LPB7j1.0.lt1.KmxEn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1280 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU We are attempting to take Multilink to Draft Standard; we have completed a working group last call and I need to mail it in. Would everyone who has an implementation, please drop me a note indicating: that they have an implementation who they have tested with and found interoperable =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= It has recently been discovered that research causes cancer in rats. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Mar 4 22:58:35 1996 Received: (from slist@localhost) by merit.edu (8.7.4/merit-2.0) id WAA07617; Mon, 4 Mar 1996 22:58:35 -0500 (EST) Resent-Date: Mon, 4 Mar 1996 22:58:35 -0500 (EST) X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 4 Mar 1996 19:57:52 -0800 To: ietf-ppp@MERIT.EDU From: fred@cisco.com (Fred Baker) Subject: Request for LQM Experience Resent-Message-ID: <"byRj83.0.is1.blxEn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1278 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU We are attempting to take LQM to Draft Standard. Would everyone who has an implementation, please drop me a note indicating: that they have an implementation who they have tested with and found interoperable if they have found non-interoperable implementations, what needs to be changed in the rfc. Tell me also if you have implemented the MIB, what portions you did not implement, and what recommendations you have concerning it. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= It has recently been discovered that research causes cancer in rats. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Mar 5 12:44:51 1996 Received: (from slist@localhost) by merit.edu (8.7.4/merit-2.0) id MAA29676; Tue, 5 Mar 1996 12:44:51 -0500 (EST) Resent-Date: Tue, 5 Mar 1996 12:44:51 -0500 (EST) X-Mailer: Novell GroupWise 4.1 Date: Tue, 5 Mar 1996 12:47:42 -0500 From: Katherin Zebrose To: rfriend@stac.com Cc: ietf-ppp@MERIT.EDU Subject: Performance Enhancement for PPP Stac LZS Compression Message-Id: <96Mar5.123741est.77191@firewall.telco.com> Resent-Message-ID: <"4J-4g1.0.IF7.Gr7Fn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1281 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Protocol Bob, Regarding your recent draft of the 'PPP Stac LZS Compression Protocol: Your earlier LZS-DCP draft specification for DSU/CSUs includes an option to transmit uncompressed data and have this included in the history. This capability is specifically excluded in your latest draft for PPP links: Specifically, in the PPP draft version, the section 'Data Expansion' requires that the transmitter reset the history if the data expands beyond the MRU. The ability to transmit uncompressed data without clearing history provides significant performance advantages. When history is cleared, the compression ratio achieved on a link drops precipitously. In many scenarios, the penalty for clearing history due to periodic packet expansion far exceeds the 12.5% expansion which can occur as a result of sending expanded packets. If the MRU is adjusted to be 12.5% greater than the largest packet size compressed, resetting history can be avoided, but again at the expense of link performance. In this case, periodic packet expansion occurs. In your recent comments, you indicate that this feature was deleted because it is not supported in the Stac 9706, a popular compression chip. The ability to provide support for "loading history" with an uncompressed packet should not be excluded simply because it is not available in the Stac 9706. It can for example be implemented today using software compression, and will be generally available shortly in the new compression server chip recently developed by IBM Micro-electronics. Certainly Stac can easily add this feature to future versions of the 9706 with minimal effort. Thank you for your attention in this matter. Respectfully, Kate Zebrose Telco Systems klz@magna.telco.com (617) 255-5247 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Mar 5 18:08:12 1996 Received: (from slist@localhost) by merit.edu (8.7.4/merit-2.0) id SAA09984; Tue, 5 Mar 1996 18:08:12 -0500 (EST) Resent-Date: Tue, 5 Mar 1996 18:08:12 -0500 (EST) From: Rob Friend To: IETF-PPP Subject: RE: Performance Enhancement for PPP Stac LZS Compression Date: Tue, 05 Mar 96 15:06:00 PST Message-Id: <313CC948@smtpgateway.stac.com> Encoding: 54 TEXT X-Mailer: Microsoft Mail V3.0 Resent-Message-ID: <"EMRGv.0.hR2.LbCFn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1282 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU On Tuesday, March 05, 1996 12:47 PM Katherin Zebrose wrote: > Regarding your recent draft of the 'PPP Stac LZS Compression Protocol: > > Your earlier LZS-DCP draft specification for DSU/CSUs includes an > option to transmit uncompressed data and have this included in the > history. This capability is specifically excluded in your latest draft for > PPP links: Actually, there are 2 LZS compression drafts in the PPP extensions comittee. Option 23 is the LZS-DCP encapsulation protocol that is identical to the standards from the TIA and Frame Relay committees. Option 23 supports the capability of the receiver to update the decompressor's history. > Specifically, in the PPP draft version, the section 'Data Expansion' > requires that the transmitter reset the history if the data expands beyond > the MRU. Option 17 is the other LZS PPP compression draft. It has never supported the capability of the receiver to update the decompressor's history. I recommended to the PPP-EXT working group that we add anti-expansion support to Option 17; however it was the decision of the working group to relegate the implementor to using Option 23 if they had to have this feature. This decision was made to simplify the Option 17 implemetation. > The ability to transmit uncompressed data without clearing history > provides significant performance advantages. When history is cleared, > the compression ratio achieved on a link drops precipitously. In many > scenarios, the penalty for clearing history due to periodic packet > expansion far exceeds the 12.5% expansion which can occur as a > result of sending expanded packets. > > If the MRU is adjusted to be 12.5% greater than the largest packet size > compressed, resetting history can be avoided, but again at the expense > of link performance. In this case, periodic packet expansion occurs. I whole-heartedly agree. I added text to explain this in the Option 23 specifiction in sections 2.4.and 3.4. where data expansion is discussed. > In your recent comments, you indicate that this feature was deleted > because it is not supported in the Stac 9706, a popular compression > chip. Which recent comments are your refering to? I don't ever remember mixing our hardware support with supporting anti-expansion features. In fact, Stac is about to sample a chip that compresses significantly faster than the Stac 9706 and also supports the anti-expansion feature. Regards, Robert C. Friend Stac Electronics Applications Engineering 12636 High Bluff Dr (619)794-4542 (voice) San Diego, CA 92130 (619)794-4577 (FAX) Email:rfriend@stac.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 6 16:14:13 1996 Received: (from slist@localhost) by merit.edu (8.7.4/merit-2.0) id QAA12167; Wed, 6 Mar 1996 16:14:13 -0500 (EST) Resent-Date: Wed, 6 Mar 1996 16:14:13 -0500 (EST) Message-Id: <199603062113.QAA12135@merit.edu> Date: Wed, 6 Mar 96 16:11:14 EST From: "Andrew M. Fuqua ((919) 254-9810)" To: fred@cisco.com, ietf-ppp@MERIT.EDU cc: welch@VNET.IBM.COM, DANNINGR@RALVM12.VNET.IBM.COM, mgaubrey@VNET.IBM.COM, davemoore@VNET.IBM.COM Subject: Request for LQM Experience Resent-Message-ID: <"pW5ZH1.0.kz2.t_VFn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1283 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Fred Baker wrote: > We are attempting to take LQM to Draft Standard. Would everyone who has an > implementation, please drop me a note indicating: > > that they have an implementation > > who they have tested with and found interoperable > > if they have found non-interoperable implementations, > what needs to be changed in the rfc. > > Tell me also if you have implemented the MIB, what portions you did not > implement, and what recommendations you have concerning it. The IBM 6611 has implemented RFC 1333 LQM. We tested LQM (very successfully) with Morning Star Technologies at the 4/94 PPP consortium. Everything worked like a charm. I remember being surprised that all of our counters were identical; I was expecting that one of us (me) would miscount the flag or something. We tested LQM with early implementations from 3 other companies but those implementations weren't ready. We found several code bugs that the other companies said they would fix. Even so, it looks promising. (None of them were problems with the draft.) I have an interoperability guy who has done testing since then and could tell us if things have improved but he is out of the office for a few days. I'll ask him to reply when he gets back. andrew - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 6 16:38:57 1996 Received: (from slist@localhost) by merit.edu (8.7.4/merit-2.0) id QAA13190; Wed, 6 Mar 1996 16:38:57 -0500 (EST) Resent-Date: Wed, 6 Mar 1996 16:38:57 -0500 (EST) Message-Id: <199603062138.QAA13158@merit.edu> Date: Wed, 6 Mar 96 16:38:33 EST From: "Andrew M. Fuqua ((919) 254-9810)" To: fred@cisco.com, ietf-ppp@MERIT.EDU cc: mgaubrey@VNET.IBM.COM Subject: Request for LQM Experience Resent-Message-ID: <"0Q6Yl.0.pD3.iNWFn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1284 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Fred Baker wrote: > Tell me also if you have implemented the MIB, what portions you did not > implement, and what recommendations you have concerning it. P.S., IBM did not implement the LQM mib. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Mar 7 03:47:26 1996 Received: (from slist@localhost) by merit.edu (8.7.4/merit-2.0) id DAA28219; Thu, 7 Mar 1996 03:47:26 -0500 (EST) Resent-Date: Thu, 7 Mar 1996 03:47:26 -0500 (EST) X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 7 Mar 1996 00:46:10 -0800 To: inads@research.ftp.com From: fred@cisco.com (Fred Baker) Subject: Advancement of CHAP to Draft Standard Cc: Steve Coya , ietf-ppp@MERIT.EDU Resent-Message-ID: <"vAifL3.0.iu6.KAgFn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1285 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Frank: The PPP Working Group recommends that the current CHAP internet draft be advanced to draft standard. The edits in the draft are minor and editorial in nature. Implementation and interoperability experience reports (minorly edited) follow in this note. Fred Baker PPP Working Group Chair >From: Craig Fox >Subject: Re: Request for CHAP Experience >To: fred@cisco.com (Fred Baker) >Date: Mon, 4 Mar 96 20:08:50 PST >Cc: misko@cisco.com (Bill Miskovetz) > >Cisco has CHAP. > >Tested with lots and lots of vendors. We have problems with [someone], >but we work well with FTP software among others. > >One problem with [said party] occurs because if we call them they refuse >to authenticate. Another problem, and I am not sure who has this >problem, occurs with a misunderstanding as to how to interpret the >host/username field. >From: Karl Fox >Date: Tue, 5 Mar 96 01:12:05 -0500 >To: fred@cisco.com (Fred Baker) >Subject: Request for CHAP Experience >Organization: Morning Star Technologies, Inc. > >Our CHAP has interoperated with Cisco and Livingston. The only >non-interoperable implementations we have seen have since been >corrected, and their confusion was due to ambiguity in the RFC that >has been adequately addressed in the latest CHAP draft. >Date: Mon, 04 Mar 1996 08:27:45 -0500 >To: fred@cisco.com (Fred Baker) >From: ken@funk.com (Ken Culbert) >Subject: Re: Request for CHAP Experience > >We've implemented CHAP and found that it interoperates very well with >other implementations, such as Sun, Cisco, and Xylogics. We haven't had >any problems regarding interoperability. >Date: Tue, 5 Mar 1996 09:14 -0500 >From: SHIBUYA@PROCESS.COM (Hiroto Shibuya) >To: fred@cisco.com >Subject: RE: Request for CHAP Experience > >Process Software Corporation's implementation of PPP on our >TCPware Product (TCP/IP stack/applications for VMS) version >5.1 (currently in Beta testing) implement CHAP. > >Attended Connectathon last week and tested successfully against >Digital Unix and IBM AIX. Not surprising since their implementation >is based on the same CMU origin code which I based mine on. >Date: Tue, 5 Mar 1996 09:54:44 -0500 (EST) >From: Connie Leblanc >Subject: Re: Request for CHAP Experience >To: Fred Baker >Cc: Sukhvinder Parmar , > rod yaehne > >We have implemented CHAP on a few of our products. They have been tested >at various PPP bakeoffs (CIUG, JAPAN approvals, ...). We have found that >we are interoperable with the following other CHAP implementations: > >3Com Netbuilder Remote Office 427 >3Com AccessBuilder >Ascend >Cisco 2503 >Combinet Everywhere >Digiboard Datafire and PCIMAC >Flowpoint 200 >Netmanage Chameleon (the version they had at the CIUG workshop in > September which I believe to be 4.5.2) >ISC Securlink Adapter >KNX ISIS Workstation >Network Express NEISDN Interhub >Novell Mpr >Rockwell RNS Netholler >SGI Workstation >Skyline Technology Veloce & Avanta >Stagecoach >Telesoft Intl TSLink3 >Trumpet >Yamaha RT100i >Bay Networks WellFleet Access Node >BUG Route One/EtherX >Seiko Instruments Industry NS2280 >Mitsubishi Electric MELNET R2000 >Furukawa Infonet 3740N-PX >Seiko System MP-8050 >Nisshin Electric LanBase IR64S > >We have not seen any problems with the CHAP MD5 implementations that we >have run into. Most implementations we come across now are compliant to >the RFC Draft. >Date: Tue, 5 Mar 1996 07:37:15 -0700 (MST) >From: Vernon Schryver >To: fred@cisco.com >Subject: Re: Request for CHAP Experience > >> From: fred@cisco.com (Fred Baker) > >> We are attempting to take CHAP to Draft Standard. Would everyone who has an >> implementation, please drop me a note indicating: >> >> that they have an implementation >> >> who they have tested with and found interoperable > >Lots. > >> if they have found non-interoperable implementations, >> what needs to be changed in the rfc. > >Many outfits have trouble deciding between PAP and CHAP. >From: Robert Gerrits >Date: Wed, 06 Mar 1996 15:34:08 cst >Subject: Re: Request for CHAP Experience >To: fred@cisco.com (Fred Baker) >Reply-To: Bob@FrontierTech.COM > >We have tested with Morning Star Technologies and Microsoft NT. >Note- our SuperTCP product is put in many different environments. The fact >that we have not been hearing about any problems would indicate that it is >working with other implementations as well. I would have no way of knowing >which ones though. > >The RFCs seems clear. RFC1321 and RFC1334. >We have not found a non-interoperable implementation. >To: Fred Baker >From: Robert Myhill/Shiva Corporation > >Date: 5 Mar 96 16:19:38 >Subject: Shiva's CHAP Experience > >From our experience at the past two multilink PPP (MLP) bakeoffs, I've >compiled the following list of vendors who Shiva successfully >interoperated with for CHAP. > >Robert > > Digi > Farallon > Motorola (bitsurfer) > Rockwell. > >I'm sure we did CHAP with other vendors also, but the notes weren't that >detailed about which authentication protocols we used. > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= It has recently been discovered that research causes cancer in rats. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Mar 7 03:52:29 1996 Received: (from slist@localhost) by merit.edu (8.7.4/merit-2.0) id DAA28597; Thu, 7 Mar 1996 03:52:29 -0500 (EST) Resent-Date: Thu, 7 Mar 1996 03:52:29 -0500 (EST) X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 7 Mar 1996 00:51:46 -0800 To: inads@research.ftp.com From: fred@cisco.com (Fred Baker) Subject: Advancement of Multilink to Draft Standard Cc: Steve Coya , ietf-ppp@MERIT.EDU Resent-Message-ID: <"Qwm_m3.0.c-6.9FgFn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1286 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Frank: The PPP Working Group recommends that the current Multilink internet draft be advanced to draft standard. The edits in the draft are minor and editorial in nature. Implementation and interoperability experience reports (minorly edited) follow in this note. Fred Baker PPP Working Group Chair >Subject: Re: Request for Multilink Experience >To: fred@cisco.com (Fred Baker) >Date: Tue, 5 Mar 1996 08:56:19 +0100 (MET) >From: Oliver Korfmacher > >> >> We are attempting to take Multilink to Draft Standard; we have completed a >> working group last call and I need to mail it in. Would everyone who has an >> implementation, please drop me a note indicating: >> >> that they have an implementation >One in europe, at least: NetCS. > >> >> who they have tested with and found interoperable >SGI (transcontinental!), Netmanage, more or less all of the participants of >the CIUG PPP/MP interop events. >Date: Tue, 5 Mar 1996 10:00:30 -0500 (EST) >From: Connie Leblanc >Subject: Re: Request for Multilink Experience >To: Fred Baker >Cc: Sukhvinder Parmar , > rod yaehne > >We have implemented ML on all our products that support PPP. The >implementations that we have been interoperable with are: > >3Com Impact >3Com AccessBuilder >Ascend >Combinet EveryWhere 2000 >Digi Intl. DataFire and Pcimac >Eicon/Diehl DIVA Solo Conneck >Flowpoint 200 >IBM WaveRunner >ISC Securelink Adapter >ISDN'TEK Commuter/u CY123.2099/WinISDN 127 >Motorola BitSurfer Pro >Network Express NEISDN InterHub >Novell Mpr >Rockwell RNS Nethopper >SGI Indy Workstation >Telesoft Intl TSLink3 >Xyplex Network 9000 >Date: Tue, 5 Mar 1996 07:35:44 -0700 (MST) >From: Vernon Schryver >To: fred@cisco.com >Subject: Re: Request for Multilink Experience > >> From: fred@cisco.com (Fred Baker) > >> We are attempting to take Multilink to Draft Standard; we have completed a >> working group last call and I need to mail it in. Would everyone who has an >> implementation, please drop me a note indicating: >> >> that they have an implementation >> >> who they have tested with and found interoperable > >Ascend, Gandalf, Combinet, Digi International, >Microsoft (WindowsNT), NetworkExpress, Xyplex > >I thought we've also seen Cisco work, but I don't see it in >Cisco listed in http://www.sgi.com/Technology/Indy_ISDN.html#interop >From: Chris Vanciu >To: "'Fred Baker'" >Subject: RE: Request for Multilink Experience >Date: Tue, 5 Mar 1996 16:45:26 -0600 > > Digi International does have 2 implementations (different product lines) >that I am aware of. Additionally, you may want to check the last "CIUG >Attendee List" and make sure you get specific responses. >To: Fred Baker >From: Daniel Brennan/US/3Com > >Date: 5 Mar 96 11:18:00 EDT >Subject: Re: Request for Multilink Experience >Mime-Version: 1.0 >Status: U > >Hi Fred, > >3Com Impact has an MP implementation. We have interoperated successfully with: >Ascend, cisco, 3Com (other groups), USR, Motorola, Shiva, SGI, Microsoft, >Network Express, and others. >From: Dana Blair >Subject: Re: Request for Multilink Experience >To: fox@cisco.com (Craig Fox) >Date: Wed, 6 Mar 96 7:31:07 PST >Cc: fred@cisco.com, dblair@cisco.com > >> >> > >> > We are attempting to take Multilink to Draft Standard; we have completed a >> > working group last call and I need to mail it in. Would everyone who has an >> > implementation, please drop me a note indicating: >> > >> > that they have an implementation >> > >> Cisco does. >> >> > who they have tested with and found interoperable >> > >> I have the list somewhere, but I will defer to Dana. > >You want the short or long list? > >The short list is combinet, Ascend, Motorola, Network Express, >3COM. >To: Fred Baker >From: Robert Myhill/Shiva Corporation > >Date: 5 Mar 96 16:19:38 >Subject: Shiva's CHAP and Multilink Experience > >From our experience at the past two multilink PPP (MLP) bakeoffs, I've >compiled the following list of vendors who Shiva successfully >interoperated with for both MLP and CHAP. > > Ascend > Cisco > Cosystems > Combinet > Digi > ISC > IBM (waverunner) > NetManage > Rockwell > Skyline > Xyplex =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= It has recently been discovered that research causes cancer in rats. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Mar 8 06:32:06 1996 Received: (from slist@localhost) by merit.edu (8.7.4/merit-2.0) id GAA05716; Fri, 8 Mar 1996 06:32:06 -0500 (EST) Resent-Date: Fri, 8 Mar 1996 06:32:06 -0500 (EST) Message-ID: <01BB0CE3.48F8E040@romulus.knx.co.uk> From: IAN PULESTON To: "'Jim Stabile'" Cc: "'IETF PPP Mailing List'" Subject: RE: Quick questions about PSCP Date: Fri, 8 Mar 1996 11:34:58 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Resent-Message-ID: <"8arRx3.0.0P1.Dg1Gn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1287 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > 1. In section 3.1, the draft mentions that there is a new value > to be defined for the Call Reference Number. I was > wondering if a value has been choosen yet? No. We are waiting to gauge the reaction to PSCP first. If it looks like = people are generally enthusiastic then we will apply for the relevant = values and go ahead with it. > 2. From reading the draft, I understand that the PSCP > protocol packets are sent/received before any authentication > packets are sent/received. Is this correct? The call reference number is negotiated by LCP before authentication, = but the rest of PSCP is negotiated as any other NCP (i.e. after = authentication). - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Mar 8 09:57:34 1996 Received: (from slist@localhost) by merit.edu (8.7.4/merit-2.0) id JAA10365; Fri, 8 Mar 1996 09:57:34 -0500 (EST) Resent-Date: Fri, 8 Mar 1996 09:57:34 -0500 (EST) Date: Fri, 8 Mar 96 08:52:48 CST Message-Id: <9603081452.AA11369@adtrn-ws01.adtran.com> X-Sender: kfrnswrt@mail Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ian_puleston@globalvillage.co.uk From: kfarnsworth@adtran.com (Kyle Farnsworth) Subject: RE: Quick questions about PSCP Cc: ietf-ppp@MERIT.EDU X-Mailer: Resent-Message-ID: <"f33hj3.0.eX2.Oh4Gn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1288 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >> 2. From reading the draft, I understand that the PSCP >> protocol packets are sent/received before any authentication >> packets are sent/received. Is this correct? > >The call reference number is negotiated by LCP before authentication, but the rest of PSCP is negotiated as any other NCP (i.e. after authentication). > I couldn't understand why it was necessary for the call reference number to be negotiated during LCP. If you are always going to negotate the same reference number for every LCP link you put into the multilink bundle why not let the multilink do it's thing and then let PSCP negotiate the reference number afterwards. In your spoofed protocol support, you don't mention IP RIP. I can see a need to spoof that so that the IP routes don't get poisoned every time the line goes idle. -------------------------------------------------------- Kyle Farnsworth ADTRAN Inc. (205)971-8583 kfarnsworth@adtran.com -------------------------------------------------------- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Mar 8 10:12:49 1996 Received: (from slist@localhost) by merit.edu (8.7.4/merit-2.0) id KAA11320; Fri, 8 Mar 1996 10:12:49 -0500 (EST) Resent-Date: Fri, 8 Mar 1996 10:12:49 -0500 (EST) Message-ID: <01BB0D02.317D1FC0@romulus.knx.co.uk> From: IAN PULESTON To: "ian_puleston@globalvillage.co.uk" , "'Kyle Farnsworth'" Cc: "ietf-ppp@merit.edu" Subject: RE: Quick questions about PSCP Date: Fri, 8 Mar 1996 15:16:13 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Resent-Message-ID: <"aJiO42.0.fm2.kv4Gn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1289 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU The point is that each end must know whether a new call is a totally new = connection or a re-connection before any NCPs start up. This information = is derived from the call reference, and hence the call reference cannot = be negotiated by PSCP (which does not complete before other NCPs).=20 Multilink will tell you who is calling, but it will not tell you whether = he (or she) is making a totally new connection or a re-connection. ---------- From: Kyle Farnsworth[SMTP:kfarnsworth@adtran.com] Sent: 08 March 1996 14:52 To: ian_puleston@globalvillage.co.uk Cc: ietf-ppp@merit.edu Subject: RE: Quick questions about PSCP >> 2. From reading the draft, I understand that the PSCP >> protocol packets are sent/received before any authentication >> packets are sent/received. Is this correct? > >The call reference number is negotiated by LCP before authentication, = but=20 the rest of PSCP is negotiated as any other NCP (i.e. after = authentication). > I couldn't understand why it was necessary for the call reference number = to=20 be negotiated during LCP. If you are always going to negotate the same= reference number for every LCP link you put into the multilink bundle = why=20 not let the multilink do it's thing and then let PSCP negotiate the=20 reference number afterwards. In your spoofed protocol support, you don't mention IP RIP. I can see a = need to spoof that so that the IP routes don't get poisoned every time = the=20 line goes idle. -------------------------------------------------------- Kyle Farnsworth ADTRAN Inc. (205)971-8583 kfarnsworth@adtran.com -------------------------------------------------------- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Mar 8 11:00:47 1996 Received: (from slist@localhost) by merit.edu (8.7.4/merit-2.0) id LAA13130; Fri, 8 Mar 1996 11:00:47 -0500 (EST) Resent-Date: Fri, 8 Mar 1996 11:00:47 -0500 (EST) Date: Fri, 8 Mar 96 09:56:04 CST Message-Id: <9603081556.AA11988@adtrn-ws01.adtran.com> X-Sender: kfrnswrt@mail Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: IAN PULESTON From: kfarnsworth@adtran.com (Kyle Farnsworth) Subject: RE: Quick questions about PSCP Cc: ietf-ppp@MERIT.EDU X-Mailer: Resent-Message-ID: <"laE6r1.0.vC3.hc5Gn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1290 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >The point is that each end must know whether a new call is a totally new >connection or a re-connection before any NCPs start up. This information is >derived from the call reference, and hence the call reference cannot be >negotiated by PSCP (which does not complete before other NCPs). > Is it not a fact that the re-connecting caller will only negotate the NCP's that it originally negotated with the same peer before the link went idle? The called device may not know who is calling right away but will know soon enough. I still don't understand your reasoning behind knowing if this is a re-connection before the NCP's have started. You didn't answer my question on adding a spoofed protocol support IP RIP spoofing. Did you not put that in there for a reason? -------------------------------------------------------- Kyle Farnsworth ADTRAN Inc. (205)971-8583 kfarnsworth@adtran.com -------------------------------------------------------- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Mar 8 12:33:32 1996 Received: (from slist@localhost) by merit.edu (8.7.4/merit-2.0) id MAA16163; Fri, 8 Mar 1996 12:33:32 -0500 (EST) Resent-Date: Fri, 8 Mar 1996 12:33:32 -0500 (EST) Date: Fri, 8 Mar 1996 10:32:43 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199603081732.KAA03122@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: RE: Quick questions about PSCP Resent-Message-ID: <"kAZpP1.0.Ky3.Zz6Gn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1291 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: kfarnsworth@adtran.com (Kyle Farnsworth) > ... > In your spoofed protocol support, you don't mention IP RIP. I can see a > need to spoof that so that the IP routes don't get poisoned every time the > line goes idle. Common IP RIP implementations make such spoofing unnecessary or undesirable. `Routed` spoofs default routes just fine. `Gated` can spoof any route you want. Having the routing daemon do the spoofing means that RIP packets need never go over the PPP link. If I weren't using `gated` to spoof-advertise routes to the networks here in my office to the reset of the SGI network, when my PPP link is up it would be carrying about 2400 bit/sec of RIP packets. (About 450 of the about 1200 routes in the net are not aggregated at any given location.) I'm pushing a rewrite of `routed` that might appear in FreeBSD, BSDI, IRIX, etc, that does a bunch of things including aggregation, RIPv2, IRDP, and optionally turns off the timers on routes that come over demand dialed point-to-point links while the point-to-point link is quiet. Spoofing IP RIP can be undesirable for the reasons that in general make spoofing routing protocols undesirable. When you haven't heard a RIP advertisement in a long time, it could be because the route is no longer valid, which means that you need to stop spoofing when you haven't heard, but that is exactly when you need to keep spoofing. There is also the RFC for IP RIP over switched circuits which seems to me should make spoofing IP RIP entirely unnecessary and undesirable. (I would have supported it in the new `routed`, but it seemed too complicated, with too many timers, too many new packet types, and too many new state machines.) Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Mar 8 13:30:21 1996 Received: (from slist@localhost) by merit.edu (8.7.4/merit-2.0) id NAA18078; Fri, 8 Mar 1996 13:30:21 -0500 (EST) Resent-Date: Fri, 8 Mar 1996 13:30:21 -0500 (EST) Date: Fri, 8 Mar 96 12:25:46 CST Message-Id: <9603081825.AA14934@adtrn-ws01.adtran.com> X-Sender: kfrnswrt@mail Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ietf-ppp@MERIT.EDU From: kfarnsworth@adtran.com (Kyle Farnsworth) Subject: RE: Quick questions about PSCP X-Mailer: Resent-Message-ID: <"6RkbS2.0.DQ4.uo7Gn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1292 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I don't want to turn this into a RIP discussion since this is the PPP list but I have questions which I hope have a straight answers: > vjs@mica.denver.sgi.com (Vernon Schryver) writes: >There is also the RFC for IP RIP over switched circuits which seems to >me should make spoofing IP RIP entirely unnecessary and undesirable. > How is this communicated over the PPP link that IP RIP is being spoofed? Is it an extension to the RIP protocol itself? What if both ends are running Version 1? In this case, can't PSCP be used so both ends can agree on spoofing the routes learned on that PPP link? -------------------------------------------------------- Kyle Farnsworth ADTRAN Inc. (205)971-8583 kfarnsworth@adtran.com -------------------------------------------------------- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Mar 8 14:44:42 1996 Received: (from slist@localhost) by merit.edu (8.7.4/merit-2.0) id OAA20446; Fri, 8 Mar 1996 14:44:42 -0500 (EST) Resent-Date: Fri, 8 Mar 1996 14:44:42 -0500 (EST) Date: Fri, 8 Mar 1996 12:42:12 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199603081942.MAA03341@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: RE: Quick questions about PSCP Resent-Message-ID: <"VAT5B1.0.x-4.Wt8Gn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1293 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: kfarnsworth@adtran.com (Kyle Farnsworth) > > I don't want to turn this into a RIP discussion since this is the PPP list > but I have questions which I hope have a straight answers: As far as I understand it, PSCP is mostly about routing. That suggests that it would not be wise to be strict about not talking about routing. > > vjs@mica.denver.sgi.com (Vernon Schryver) writes: > >There is also the RFC for IP RIP over switched circuits which seems to > >me should make spoofing IP RIP entirely unnecessary and undesirable. > > > How is this communicated over the PPP link that IP RIP is being spoofed? > > Is it an extension to the RIP protocol itself? > > What if both ends are running Version 1? In this case, can't PSCP be used > so both ends can agree on spoofing the routes learned on that PPP link? As I understand them, the "Demand RIP" extensions are independent of RIPv2. RIPv2 is only RIPv1 with explicit netmasks, optional next-hops, and authentication, and that RIPv2 packets were intended to be interpretable by RIPv1 routers and hosts. There are some caveats on that interoperability, but there are choices that can be made by default that work. If you implement the extensions to RIP described in RFC 1581 and RFC 1582, I think all notions of RIP spoofing by PPP are irrelevant and wrong. However, as I wrote before, I'm daunted by the complexity and limitations of RFC 1582 (e.g. words in RFC 1581 section 5 about 0.0.0.0), particularly when compared to the standard practices involving `gated` and `routed`. I don't know what to think about the references to IPX RIP in RFC 1581. I do not see how anything done inside PPP (presumably including PSCP) can correctly, not to mention usefully, be involved in "both ends [agreeing] on spoofing the routes learned on that PPP link." PPP is not and should not try to be a routing protocol. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Mar 8 15:04:08 1996 Received: (from slist@localhost) by merit.edu (8.7.4/merit-2.0) id PAA21341; Fri, 8 Mar 1996 15:04:08 -0500 (EST) Resent-Date: Fri, 8 Mar 1996 15:04:08 -0500 (EST) Message-ID: <01BB0D00.BBF9EC20@merlin.arrisnet.com> From: Mark Garti To: "'ietf-ppp@MERIT.EDU'" Subject: PPP Compression Types Date: Fri, 8 Mar 1996 15:05:47 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Resent-Message-ID: <"a-07e.0.BD5.qA9Gn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1294 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Couple of simple questions: 1. Where does one locate "The PPP Compression Control Protocol (CCP)", by Rand? 2. The PPP STAC LZS spec states that the Configuration Option should specifiy 17 for STAC compression. Is there an enumerated list of other compression types a PPP implementation might see? 3. Is V42bis a commonly used PPP compression type? Since both V42bis and STAC are both LZ based, does one have any advantage over the other? Mark Garti mgarti@arrisnet.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Mar 8 15:25:27 1996 Received: (from slist@localhost) by merit.edu (8.7.4/merit-2.0) id PAA22576; Fri, 8 Mar 1996 15:25:27 -0500 (EST) Resent-Date: Fri, 8 Mar 1996 15:25:27 -0500 (EST) Date: Fri, 8 Mar 96 14:20:57 CST Message-Id: <9603082020.AA17953@adtrn-ws01.adtran.com> X-Sender: kfrnswrt@mail Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ietf-ppp@MERIT.EDU From: kfarnsworth@adtran.com (Kyle Farnsworth) Subject: RE: Quick questions about PSCP X-Mailer: Resent-Message-ID: <"poYOP2.0.XW5.qU9Gn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1295 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >> From: kfarnsworth@adtran.com (Kyle Farnsworth) >> >> I don't want to turn this into a RIP discussion since this is the PPP list >> but I have questions which I hope have a straight answers: > >As far as I understand it, PSCP is mostly about routing. That suggests >that it would not be wise to be strict about not talking about routing. > > >> > vjs@mica.denver.sgi.com (Vernon Schryver) writes: >> >There is also the RFC for IP RIP over switched circuits which seems to >> >me should make spoofing IP RIP entirely unnecessary and undesirable. >> > >> How is this communicated over the PPP link that IP RIP is being spoofed? >> >> Is it an extension to the RIP protocol itself? >> >> What if both ends are running Version 1? In this case, can't PSCP be used >> so both ends can agree on spoofing the routes learned on that PPP link? > >As I understand them, the "Demand RIP" extensions are independent of >RIPv2. RIPv2 is only RIPv1 with explicit netmasks, optional next-hops, >and authentication, and that RIPv2 packets were intended to be >interpretable by RIPv1 routers and hosts. There are some caveats on >that interoperability, but there are choices that can be made by >default that work. > >If you implement the extensions to RIP described in RFC 1581 and RFC >1582, I think all notions of RIP spoofing by PPP are irrelevant and >wrong. However, as I wrote before, I'm daunted by the complexity and >limitations of RFC 1582 (e.g. words in RFC 1581 section 5 about >0.0.0.0), particularly when compared to the standard practices >involving `gated` and `routed`. > >I don't know what to think about the references to IPX RIP in RFC 1581. > >I do not see how anything done inside PPP (presumably including PSCP) >can correctly, not to mention usefully, be involved in "both ends >[agreeing] on spoofing the routes learned on that PPP link." PPP is >not and should not try to be a routing protocol. > Isn't the purpose of PSCP to agree on a protocol to be spoofed and not to actually do the spoofing or routing? Let's take the case of RIPv1 running on two PPP routers: router A calls device B and IPCP is brought up, router A and B are exchanging RIP packets but are not reseting the idle timer router A's idle timer times out and it term-req's the call router A know's the line has been dropped because of an idle timeout and it will "spoof" the routes it learned from the router B and not turn them into zombies router B does not know if the link went down because of an idle timeout OR because of a "user hang-up". Therefore device B will not "spoof" the routes it learned form route A. Wouldn't PSCP be a way of router A to tell router B that it is bringing down the links because of a idle time-out? -------------------------------------------------------- Kyle Farnsworth ADTRAN Inc. (205)971-8583 kfarnsworth@adtran.com -------------------------------------------------------- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Mar 8 19:18:45 1996 Received: (from slist@localhost) by merit.edu (8.7.4/merit-2.0) id TAA28914; Fri, 8 Mar 1996 19:18:45 -0500 (EST) Resent-Date: Fri, 8 Mar 1996 19:18:45 -0500 (EST) Date: Fri, 8 Mar 1996 16:42:39 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199603082342.QAA03668@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: RE: Quick questions about PSCP Resent-Message-ID: <"Uj9fO2.0.Z37.WvCGn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1296 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: kfarnsworth@adtran.com (Kyle Farnsworth) > ... > Isn't the purpose of PSCP to agree on a protocol to be spoofed and not to > actually do the spoofing or routing? > ... > Wouldn't PSCP be a way of router A to tell router B that it is bringing down > the links because of a idle time-out? That sounds like a nice thing. However, I'm affraid there the following two cases cover the universe: 1. the routes involved are trivial. For example, one of the "routers" is an isolated PPP host, or a full PPP router but connected to a small internet of only a handfull of IP networks, like the 2 FDDI rings and 1 Ethernet on my side of the PPP link to the rest of the SGI network. 2. the routes involved are non-trivial, for example, including other WAN links that come and go. Case #1 is easily handled with static configuration stuff, such as static routes or entries in /etc/gated.conf for the `gated` daemon. You can assume that even if you don't hear from the other router for weeks, all of the routes are all still good. Even with PSCP, I suspect you need enough static configuring to turn on PSCP, and that it wouldn't be any easier than the "-p" flag I've added to the `routed` daemon, and not much easier than a few lines in /etc/gated.conf. Case #2 seems to need something like RFC 1582. You need timers on the individual routes, bringing up the link just to refresh the routes, and so forth. Maybe I'm wrong. This sort of thing very much wants some prototype implementations in the field and to either discover it is a bad idea or to design a protocol that will work. Otherwise, you end up with the wonderfullness of overhead-projector engineering. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Mar 8 19:20:13 1996 Received: (from slist@localhost) by merit.edu (8.7.4/merit-2.0) id TAA29076; Fri, 8 Mar 1996 19:20:13 -0500 (EST) Resent-Date: Fri, 8 Mar 1996 19:20:13 -0500 (EST) Content-Type: text/plain Message-ID: X-Mailer: Novell GroupWise 4.1 Date: Fri, 08 Mar 1996 16:19:12 -0800 From: JIM_STABILE@novell.com (Jim Stabile) To: ietf-ppp@MERIT.EDU Subject: Add to general discussion Resent-Message-ID: <"0Tunx1.0.567.wwCGn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1297 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Please add my name to the generate discussion mail list for PPP. Jim Stabile jstabile@novell.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Mar 8 19:31:34 1996 Received: (from slist@localhost) by merit.edu (8.7.4/merit-2.0) id TAA29862; Fri, 8 Mar 1996 19:31:34 -0500 (EST) Resent-Date: Fri, 8 Mar 1996 19:31:34 -0500 (EST) Date: Fri, 8 Mar 96 16:30:07 From: Tmima Koren To: ietf-ppp@MERIT.EDU X-Priority: 3 (Normal) X-Mailer: Chameleon 5.0, TCP/IP for Windows, NetManage Inc. Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Resent-Message-ID: <"rjnrw.0.II7.Y5DGn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU Subject: Unidentified subject! X-Mailing-List: archive/latest/1298 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU lists - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Sat Mar 9 01:45:44 1996 Received: (from slist@localhost) by merit.edu (8.7.4/merit-2.0) id BAA07971; Sat, 9 Mar 1996 01:45:44 -0500 (EST) Resent-Date: Sat, 9 Mar 1996 01:45:44 -0500 (EST) X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 8 Mar 1996 22:45:00 -0800 To: ietf-ppp@MERIT.EDU From: fred@cisco.com (Fred Baker) Subject: Working Group Last Call - PPP SNA Control Protocol Resent-Message-ID: <"O3e8X.0.Ky1.FaIGn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1299 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Speak now... Is there any reason not to advance this document to Proposed Standard? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= It has recently been discovered that research causes cancer in rats. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Sat Mar 9 02:24:57 1996 Received: (from slist@localhost) by merit.edu (8.7.4/merit-2.0) id CAA09084; Sat, 9 Mar 1996 02:24:57 -0500 (EST) Resent-Date: Sat, 9 Mar 1996 02:24:57 -0500 (EST) X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 8 Mar 1996 23:24:17 -0800 To: ietf-ppp@MERIT.EDU From: fred@cisco.com (Fred Baker) Subject: PPP Minutes - LA-IETF Cc: minutes@ietf.cnri.reston.va.us Resent-Message-ID: <"Bb5w4.0.jD2.59JGn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1300 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Baiju Patel: IPCP Mobility Extensions Messages are sent originally to the mobile user's home machine, which forwards the message to a 'care of' address. The care-of address can change from time to time as the mobile user moves. The mobile user might reply directly or via the home system, depending on the needs of the transport protocol implementation. Data is forwarded in an IP-in-IP tunnel when going between the mobile user and his home system. The problem is that Mobile IP needs to be able to identify a foreign agent on a dial connection. The proposal is to define an IPCP option, which negotiates whether the peer is willing to be a foreign agent. Draft needs to be updated to, instead of shutting down when the option is refused, to be able to use a co-located agent in the requesting system. Consensus is to continue this work; seems like a reasonable proposal. Ed Allen - IP6 CP The authors propose a new control protocol for IP6 than IP4. This reflects the features of the IP4 CP in IP6 concepts and formats. two options: interface option - negotiate IP6 link addresses compression protocol - negotiate the use of VJ compression The question arose why the authors didn't just "embed the PPP Magic Number as part of the IP6 link-layer address instead of negotiating a separate option for it". Charles Perkins will determine whether a mobility option is required. The working group feels that this is a reasonable (though not the only possible) approach for IP6. Rob Friend - Stac Compression OPtion 17: Objectives with respect to draft 4: - add anti-expansion bit to check mode? - no - add bit to check mode field to put check value after data? - no - add combination bit? no - add bit to utilize Option 23 (DCP) format/protocol? - no - clarify multiple histories? yes Draft 5 sought to do these, improve clarity, and mandate support of default values. It also adds a Windows '95 option. Issues not addressed in draft 5: - sending uncompressed packets - anti-expansion bit - moving the LCB field - 0x4021 is still there to send Stac datagrams with certain defaults, rather than CCP. It conflicts with history count = 1 and no history synchronization requirement. If it is unused, it should be pulled. Rob is going to drop a note to the PPP list asking who is using 0x4021. If it is not, the value will be pulled. Draft 6 addresses a backwards compatibility issue in draft 5, restores the 0x00 deletion and insertion, and defines the extended (Windows '95) mode. Windows '95 uses option 4 in a different way than the draft describes, and uses a different data format. The question arises whether it is appropriate to include in the draft. Draft 6 has five options for check mode, all of which (except extended mode) seem to be widely implemented. The question was raised if we could select one or two and make all others historical. The resolution, after some discussion, was to require implementation ("MUST IMPLEMENT") of option 3 - sequence number check mode - with at least one history. The other four check modes are to be documented and made optional to implement. The LCB and CRC configuration options were viewed as redundant with FCS. This implies that the implementation "MUST IMPLEMENT" the use of the CCP RESET/RESPONSE mechanism, or reliable mode, or both. Other issues include clearly specifying the above paragraph in the current text, defining transmitter & receiver processes in extended mode, deleting the reference to mandating the same number history number bytes in both directions, and other minor editorial updates. Option 18: Called "LZM" technology Used in Windows NT and Windows 95 Windows NT only supports Option 18; Windows 95 supports both OPtion 17 and 18 Called "MPPC" inside Microsoft S/W libraries available from Stac Option 23: Removing 0x00 deletion/insertion and padding discussed, because h/w does not support this. Orthogonality with Frame Relay and TIA superceded this decision. The draft remained unchanged. Stac will support these options in hardware. Andy Valencia - Level Two Forwarding (Protocol) "L2F" The Level 2 Forwarding Protocol is proposed as a way to enable a private network to be extended through a firewall to service providers which handle Async or ISDN dial-in. The expectation is that these endpoints would tunnel the connection through an internet (perhaps using IPSEC protocols) and yet enable them to appear to be within the home network from an addressing perspective. This enables companies to be able to use ISPs rather than deploy world-wide telephone networks. PPP, in this case, is terminated in the "home gateway" or firewall. The ISP essentially virtual-circuit switches the connection to the home gateway, where NCPs and authentication are negotiated. These virtual circuits might be X.25, Frame Relay, UDP, or others. Craig Richards/Kevin Smith [who was not present] BACP Purpose of BAP/BACP: - multiple servers on a huntgroup - interoperable bandwidth on demand - reduce end user configuration burden Bandwidth on Demand: - Resource BOD allows an implementation to unilaterally make decisions - Throughput BOD depends on traffic transmitted. New draft coming out. Bake-off at Pac Bell May 20th 2 days of multilink testing 2 days of CCP testing 1 day BACP testing up to 56 vendors can be accomodated. There will be 40 analog links 98 BRI links 4 PRI links (92 B channels) The sense in the room was that the protocol is too complex; that a sufficient subset of its features can be implemented with a much simpler protocol. Specifically, rather than enumerating link types, it was suggested that one might request certain amount of bandwidth as an integer, potentially with a link type of V.110, V.120, ISDN Sync, or standard Async. It was also suggested that the bundle drop and available link messages are unnecessary. Craig is to develop a feature set proposal and discuss the matter further on the list. Andrew M. Fuqua - PPP SNA Control Protocol This draft documents existing SNA/PPP and APPN/PPP implementations, with the intent of enabling the development of interoperable implementations. The decision was to take this to Proposed Standard after a working group last call. Bill Simpson - CHAP, LQM, and LCP Extensions We need a list of CHAP implementations that have been tested and known to interoperate, and a list of known defects in the protocol. This is to be requested from the list. We need a list of LQM implementations that have been tested and known to interoperate, and a list of known defects in the protocol. This is to be requested from the list. LCP Extensions: it was felt that keeping both the LCP Callback and the BAP "Call me" message s reasonable, as they have different demantics and different purposes. LCP Callback is used for security callback, where BAP Callback is used for negotiating additional bandwidth. The current draft describes only those options that had a constituency the last time we asked. Bill will post an updated draft, and we will then issue a working group last call. Bill Whelan - EAP RSA Authentication The new draft defines an ISO-509 certificate and BER encoding, and tightens some language. The recommendation was made to make sure that this draft conforms to the DER encoding in use in the IPSEC community. Bill will talk with Bob Baldwin at RSA to assure this. Given an updated draft or a statement from Bill that no update is required to align with IPSEC, we will entertain a working group last call on this and EAP. Bill will also inquire about fair and reasonable licnesing arrangements, asking RSADSI to amke the statements requested by the current POISED-95 draft available to the IESG Executive Secretary Ian Puleston - Protocol Spoofing Ian was not present to lead a discussion; we will discuss this on the list. Glenn McGregor - IPCP Glenn will post an updated draft, and we will post a working group last call. The issues: unnumbered links and an ACK of 0.0.0.0. The consensus on unnumbered links was that a system using numbered links SHOULD use option 3 to state or negotiate its address. A system that does not state its address is one which either has a configured address or is willing to run an unnumbered link. The consensus on ACK 0.0.0.0 was that this is not a protocol error, but an implementation note to the effect that keying on this to send IP datagrams with a source address of 0.0.0.0 violates RFC 1122 and is frowned upon mightily. A working group last call was held regarding PPP Multilink; this draft is recommended to advance to Draft Standard. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= It has recently been discovered that research causes cancer in rats. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Mar 11 05:50:33 1996 Received: (from slist@localhost) by merit.edu (8.7.4/merit-2.0) id FAA04422; Mon, 11 Mar 1996 05:50:33 -0500 (EST) Resent-Date: Mon, 11 Mar 1996 05:50:33 -0500 (EST) Message-ID: <01BB0F38.FD88B240@romulus.knx.co.uk> From: IAN PULESTON To: "'Robert Myhill/Shiva Corporation'" Cc: "'IETF PPP Mailing List'" Subject: RE: Comments on PSCP draft Date: Mon, 11 Mar 1996 10:53:30 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Resent-Message-ID: <"-2IQu3.0.z21.ML0Hn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1301 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Thanks for the comments. > Section 3, first paragraph: So are you assuming that after a call is > re-connected, the NCPs will be re-negotiated? I can't think of a situation > where any of the NCP's would negotiate different values on re-connect from the > first connection. Why not just say that NCP's should not be re-negotiated upon > reconnection? Keeping the NCPs open whilst the connection is suspended is a possibility. I can't think of any arguments against it. Anyone else got any comments ? > Section 3.1.1, fifth paragraph: Should the fourth word of this paragraph be > "called" rather than "calling," or am I not understanding. Yes, it should be "called". Well spotted. > Section 4.2: Is it assumed that the PSCP Terminate Request/Terminate Ack will > be followed by LCP Terminate Request/Terminate Ack? Is so, that should > probably be mentioned. Also, should the NCP's be terminated at that time? > Personally, I think the NCP's should be kept up (as I mentioned above). In any > case the expected or required actions by LCP and the NCP's should be mentioned > here. Yes it is assumed that the PSCP Terminate Request/Terminate Ack will be followed by LCP Terminate Request/Terminate Ack. See above for comments on NCPs. > Section 6.2: I think IP RIP should be included in the list of protocols. You are the second person to suggest IP-RIP be added. The list of Spoofed Protocols in the first draft is not meant to be exhaustive. It is based on those which our own product supports. Further protocols such as IP RIP can be added to it. Note the discussions which have been going on over the last few days about whether IP-RIP spoofing is needed. > Also, what is the correlation between these protocols and the NCP's that are > negotiated on the connection? Is it ok to negotiate an NCP but not do the > spoofing? I would think not, except in a couple of cases. For example, I > don't think that not supporting TCP Keep Alive spoofing should preclude doing > IP on the connection, since a lot of TCP implementations don't do TCP Keep > Alives, and those that do often have a Keep Alive interval of 2 hours. Section 4.2 states that a link should only be suspended if there are no sessions running over the link using protocols whose spoofing has been negotiated off. It should probably be changed to say: If there are sessions running over the link using protocols whose spoofing has been negotiated off, then it is up to the caller to decide whether to suspend it. > Also, it might seem legitimate for one end of the connection to spoof IP Pings > and other end not to spoof IP Pings, so maybe it should not be required that > spoofing be bidirectional. Some applications routinely send IP Pings as > keepalives, but if that application is only running on one side of the > connection, then you might only want to spoof on one side. Actually, maybe > this is getting a tad contrived. It should not a requirement that spoofing be bi-directional. However, it should be a requirement that PSCP can be used to suspend a call, even when unilateral spoofing is possible. The reasoning for this is that some implementations may want to keep a channel available for a suspended connection to re-connect on. Our product does this (it is particularly important with protocols such as Novell where, in practice, failure to re-connect often means re-boot time at the client end). These implementations therefore require that both ends know that a connection is suspended, even if both ends do not take part in spoofing. It should be possible to suspend a call in the case of unilateral spoofing, or even if neither end is doing any spoofing. Using PSCP allows the various things like "Maximum Call Suspension Time", "Call Back Number/Name" etc. to be used. PSCP is about two separate, but closely related things - Link Suspension and Protocol Spoofing. Maybe a better name would be "SSCP" - the "Suspension and Spoofing Control Protocol". ---------- From: Robert Myhill/Shiva Corporation[SMTP:rmyhill@shiva.com] Sent: 07 March 1996 12:35 To: ian_puleston; Cc: Robert Myhill/Shiva Corporation; Subject: Comments on PSCP draft Hi Ian, I have a few comments/questions on your draft of the PSCP protocol. Overall I like it. It seems to cover the issues involved with suspend/resume. Section 3, first paragraph: So are you assuming that after a call is re-connected, the NCPs will be re-negotiated? I can't think of a situation where any of the NCP's would negotiate different values on re-connect from the first connection. Why not just say that NCP's should not be re-negotiated upon reconnection? Section 3.1.1, fifth paragraph: Should the fourth word of this paragraph be "called" rather than "calling," or am I not understanding. Also, there's a typo on this line "is is." Section 4: The last character of this section should be a "." not ",". Section 4.2: Is it assumed that the PSCP Terminate Request/Terminate Ack will be followed by LCP Terminate Request/Terminate Ack? Is so, that should probably be mentioned. Also, should the NCP's be terminated at that time? Personally, I think the NCP's should be kept up (as I mentioned above). In any case the expected or required actions by LCP and the NCP's should be mentioned here. Section 6.2: I think IP RIP should be included in the list of protocols. Also, what is the correlation between these protocols and the NCP's that are negotiated on the connection? Is it ok to negotiate an NCP but not do the spoofing? I would think not, except in a couple of cases. For example, I don't think that not supporting TCP Keep Alive spoofing should preclude doing IP on the connection, since a lot of TCP implementations don't do TCP Keep Alives, and those that do often have a Keep Alive interval of 2 hours. Also, it might seem legitimate for one end of the connection to spoof IP Pings and other end not to spoof IP Pings, so maybe it should not be required that spoofing be bidirectional. Some applications routinely send IP Pings as keepalives, but if that application is only running on one side of the connection, then you might only want to spoof on one side. Actually, maybe this is getting a tad contrived. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Mar 11 08:05:54 1996 Received: (from slist@localhost) by merit.edu (8.7.4/merit-2.0) id IAA07214; Mon, 11 Mar 1996 08:05:54 -0500 (EST) Resent-Date: Mon, 11 Mar 1996 08:05:54 -0500 (EST) Message-ID: <01BB0F4B.F61A4060@romulus.knx.co.uk> From: IAN PULESTON To: "'Kyle Farnsworth'" Cc: "'IETF PPP Mailing List'" Subject: RE: Quick questions about PSCP Date: Mon, 11 Mar 1996 13:09:19 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Resent-Message-ID: <"DradJ.0.Um1.hK2Hn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1302 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > The called device may not know who is calling right away but will know soon > enough. I still don't understand your reasoning behind knowing if this is a > re-connection before the NCP's have started. Take this example. If I call the PSI Internet service they allocate me an IP address using IPCP. I configure my TCP/IP stack to use this. If I drop the connection for a while and then re-make it, they allocate me a different IP address. I then need to re-configure my TCP/IP stack. That is not practical if the dropping of the call is being done automatically by the low level comms equipment (in the case of the Microsoft TCP/IP stack, re-configuring it can mean re-starting Windows). If PSCP was used, then when the connection was resumed after being suspended, the Internet provider could give me the same IP address again, so long as he knows which connection is being resumed BEFORE the IPCP negotiations take place. > You didn't answer my question on adding a spoofed protocol support IP RIP > spoofing. Did you not put that in there for a reason? Sorry I just forgot about it. The list of Spoofed Protocols in the first draft is not meant to be exhaustive. It is based on those which our own product supports. Further protocols such as IP RIP can be added to it. This has provoked some discussion over the last few days about whether IP-RIP spoofing is needed. My view is that is not really relevant. As soon as this draft went out, two separate people immediately said "what about IP-RIP". If more than one vendor decides to implement IP-RIP spoofing, even if it arguably may not be needed, then it should be included in the list to let them inter-operate. ---------- From: Kyle Farnsworth[SMTP:kfarnsworth@adtran.com] Sent: 08 March 1996 15:56 To: IAN PULESTON; Cc: ietf-ppp@merit.edu; Subject: RE: Quick questions about PSCP Is it not a fact that the re-connecting caller will only negotate the NCP's that it originally negotated with the same peer before the link went idle? The called device may not know who is calling right away but will know soon enough. I still don't understand your reasoning behind knowing if this is a re-connection before the NCP's have started. You didn't answer my question on adding a spoofed protocol support IP RIP spoofing. Did you not put that in there for a reason? -------------------------------------------------------- Kyle Farnsworth ADTRAN Inc. (205)971-8583 kfarnsworth@adtran.com -------------------------------------------------------- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Mar 11 09:47:25 1996 Received: (from slist@localhost) by merit.edu (8.7.4/merit-2.0) id JAA10069; Mon, 11 Mar 1996 09:47:25 -0500 (EST) Resent-Date: Mon, 11 Mar 1996 09:47:25 -0500 (EST) Date: Mon, 11 Mar 96 08:42:37 CST Message-Id: <9603111442.AA27596@adtrn-ws01.adtran.com> X-Sender: kfrnswrt@mail Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: IAN PULESTON From: kfarnsworth@adtran.com (Kyle Farnsworth) Subject: RE: Quick questions about PSCP Cc: ietf-ppp@MERIT.EDU X-Mailer: Resent-Message-ID: <"JGPWZ2.0.4T2.vp3Hn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1303 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >> Is it not a fact that the re-connecting caller will only negotate the NCP's >> that it originally negotated with the same peer before the link went idle? >> The called device may not know who is calling right away but will know soon >> enough. I still don't understand your reasoning behind knowing if this is a >> re-connection before the NCP's have started. > >Take this example. If I call the PSI Internet service they allocate me an IP address >using IPCP. I configure my TCP/IP stack to use this. If I drop the connection for >a while and then re-make it, they allocate me a different IP address. I then need to >re-configure my TCP/IP stack. That is not practical if the dropping of the call is >being done automatically by the low level comms equipment (in the case of the >Microsoft TCP/IP stack, re-configuring it can mean re-starting Windows). > >If PSCP was used, then when the connection was resumed after being >suspended, the Internet provider could give me the same IP address again, >so long as he knows which connection is being resumed BEFORE the >IPCP negotiations take place. > I now understand why you did this. Thanks. >> You didn't answer my question on adding a spoofed protocol support IP RIP >> spoofing. Did you not put that in there for a reason? > >Sorry I just forgot about it. The list of Spoofed Protocols in the first draft is not >meant to be exhaustive. It is based on those which our own product supports. >Further protocols such as IP RIP can be added to it. > >This has provoked some discussion over the last few days about whether >IP-RIP spoofing is needed. My view is that is not really relevant. As soon as >this draft went out, two separate people immediately said "what about IP-RIP". >If more than one vendor decides to implement IP-RIP spoofing, even if it arguably >may not be needed, then it should be included in the list to let them inter-operate. > I think it should added for now since it will only take another bit and could be used. -------------------------------------------------------- Kyle Farnsworth ADTRAN Inc. (205)971-8583 kfarnsworth@adtran.com -------------------------------------------------------- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Mar 11 17:21:45 1996 Received: (from slist@localhost) by merit.edu (8.7.4/merit-2.0) id RAA26283; Mon, 11 Mar 1996 17:21:45 -0500 (EST) Resent-Date: Mon, 11 Mar 1996 17:21:45 -0500 (EST) Content-Type: text/plain Message-ID: X-Mailer: Novell GroupWise 4.1 Date: Mon, 11 Mar 1996 14:22:10 -0800 From: RUTH_TSAI@novell.com (Ruth Tsai) To: ian_puleston@globalvillage.co.uk, rmyhill@shiva.com Cc: ietf-ppp@MERIT.EDU Subject: RE: Comments on PSCP draft -Reply Resent-Message-ID: <"3A6EK1.0.KQ6.HTAHn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1304 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >>> IAN PULESTON 03/11/96 02:49am >>> Thanks for the comments. > Section 3, first paragraph: So are you assuming that after a call is > re-connected, the NCPs will be re-negotiated? I can't think of a situation > where any of the NCP's would negotiate different values on re-connect from the > first connection. Why not just say that NCP's should not be re-negotiated upon > reconnection? >>Keeping the NCPs open whilst the connection is suspended is a possibility. >>I can't think of any arguments against it. Anyone else got any comments ? The re-connect may not connect to the same link as the original connection. Some implementations tie the LCP and NCPs to the link structure very closely. If NCPs are left open and the re-connect LCP is coming from a different link as the original NCP, we have a problem. It is preferred that the NCPs and LCP are closed when a call is temporarily disconnected. Ruth rtsai@novell.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Mar 11 21:05:29 1996 Received: (from slist@localhost) by merit.edu (8.7.4/merit-2.0) id VAA02607; Mon, 11 Mar 1996 21:05:29 -0500 (EST) Resent-Date: Mon, 11 Mar 1996 21:05:29 -0500 (EST) Message-Id: <9603120206.AA3428@hqsmtp.ops.3com.com> To: Ruth Tsai Cc: ian_puleston , rmyhill , ietf-ppp From: Allen Rochkind/HQ/3Com Date: 11 Mar 96 17:30:44 EDT Subject: RE: Comments on PSCP draft -Reply Mime-Version: 1.0 Content-Type: Text/Plain Resent-Message-ID: <"RL3KJ.0.Se.YlDHn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1305 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I think this is the crux of the issue on the NCPs for demand dialing: why should the NCPs be tied closely to the LCPs? Architecturally it seems to me that the NCP negotiation should not be tied to the LCP negotiation of specific links. I believe that within PPP there are really 3 architectural "layers" of functionality: 1. At the bottom is the LCP layer. This involves the negotiation of parameters for a specific link (e.g. the MRU for a link) and the operation of a specific link (e.g. LQM or echos). 2. In the middle is a "bundle" layer. This involves the specification of attributes of a "bundle" of links. This layer is not made explicit (via a separate set of protocols) within the current set of PPP specifications. However, this layer is implicitly present and we are seeing more and more the need to isolate out this layer. For example MLP provides an encapsulation that is essentially link independent. I.e. a MLP fragment can be sent on any of the links in the bundle, but its semantic content (i.e. of the MLP header) is not about that link, but about the architectural entity above the link called the "bundle". The proposed BAP/BACP protocol is really a protocol that deals with the "bundle" layer. It deals with the question of how many and what types of links will be constituted in a bundle. I believe the proposed spoofing protocol is similarly a "bundle" layer type protocol. We are talking about suspending a bundle when there is no traffic over the bundle for an idle time. We are talking about bringing up one or more links in the bundle when there is traffic. Since the current proposal talks about using the same reference number over any link in the bundle, the crucial entity being resumed is the bundle since any one of the links having the common reference number of the bundle effectively resumes bandwidth in that bundle. 3. The third and top most layer is the NCP layer. This is a type of PPP "application" layer. My understanding of RFC1717 is that NCPs run fairly transparently over the bundle. For example, RFC1717 says, "All packets received over links identified as belonging to the multilink arrangement are presented to the same network-layer protocol processing machine...." The examples and Figure 1 of RFC1717 point to the NCP's operating like "applications" over the NCP bundle. The encapsulation of fragments of NCP packets (and also of the higher level network protocols) into MLP headers supports this idea that the NCP is in a "layer" above the bundle layer. So what this means is that if an NCP gets negotiated, it get negotiated over a bundle (whether that bundle consists of only one link or a set of multiple links). That negotiation takes place regardless of the characteristics of the bundle. Therefore there should not be interaction between the LCP of specific links (the first layer above) and the NCP (the third layer above). This architecture argues for the idea that a NCP "session" (i.e. the period of time in which a NCP negotiation or connection remains in effect) should remain in effect as long as the bundle is not "terminated". In the current spoofing proposal, "suspending" the links in a bundle does not terminate the bundle. Therefore the NCP session should continue to remain in effect. In fact the suspension of the links in a bundle should be transparent to the NCP layer as per the architectural layering principles detailed above. Therefore suspending a LCP connection should leave the NCP's intact. Only "termination" (in the sense defined in the spoofing proposal) should bring down the NCPs. If the principle of keeping the NCPs up with the underlying bundle links suspended is accepted, then the proposed spoofing protocol would clean up: we would not need to have a data link reference number negotiated at the LCP level. The problem about having potentially different NCP characteristics after the suspension and resumption of the links would not arise. If the "bundle" layer described above were made explicit in the PPP architecture, then this spoofing protocol (along with BAP) would be a bundle level protocol (rather than a NCP level protocol). This is a fine distinction. We could still preserve the explicit PPP 2 layer (NCP/LCP) architecture by thinking of these protocols as NCPs that pertain to the characteristics of the underlying bundle rather than to characteristics of network layer protocols (like IP or IPX). It should be noted that because the original PPP RFCs were developed prior to the discussions of bundles and protocols that concern themselves with bundle atttributes, the main model of those RFCs is the single link. For example, it appears that RFC1661 mandates that the losing of an LCP implicitly closes all NCPs (see Section3.7): "The closing of the link by LCP is sufficient. There is no need for each NCP to send a flurry of Terminate packets." Literally this statement is insufficient for a multilink bundle, because I am sure that RFC1717 never intends for all NCPs to implicitly close if a single LCP link is closed. The implied sense is that the NCPs close when all of the links of the bundle close. However, as pointed out above, even this implicit understanding seems inadequate for demand dialing, discussed in the current spoofing proposal. The current proposal says that an LCP "close" could either be a "termination" or a "suspension". This distinction was never envisaged in RFC 1661. So if the idea of leaving NCPs up on suspension of underlying LCPs is accepted, the original RFC1661 will need an amendment and further clarification about the state of NCPs when LCPs "close". ----- Previous Message ---------------------------------------------------- To: ian_puleston @ globalvillage.co.uk @ UGATE rmyhill @ shiva.com @ UGATE cc: ietf-ppp @ MERIT.EDU @ UGATE From: RUTH_TSAI @ novell.com (Ruth Tsai) @ UGATE Date: Monday March 11, 1996 02:22 PM Subject: RE: Comments on PSCP draft -Reply ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >>> IAN PULESTON 03/11/96 02:49am >>> Thanks for the comments. > Section 3, first paragraph: So are you assuming that after a call is > re-connected, the NCPs will be re-negotiated? I can't think of a situation > where any of the NCP's would negotiate different values on re-connect from the > first connection. Why not just say that NCP's should not be re-negotiated upon > reconnection? >>Keeping the NCPs open whilst the connection is suspended is a possibility. >>I can't think of any arguments against it. Anyone else got any comments ? The re-connect may not connect to the same link as the original connection. Some implementations tie the LCP and NCPs to the link structure very closely. If NCPs are left open and the re-connect LCP is coming from a different link as the original NCP, we have a problem. It is preferred that the NCPs and LCP are closed when a call is temporarily disconnected. Ruth rtsai@novell.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Mar 11 21:31:50 1996 Received: (from slist@localhost) by merit.edu (8.7.4/merit-2.0) id VAA03704; Mon, 11 Mar 1996 21:31:50 -0500 (EST) Resent-Date: Mon, 11 Mar 1996 21:31:50 -0500 (EST) Date: Mon, 11 Mar 1996 18:30:43 -0800 (PST) From: Keith Sklower Message-Id: <199603120230.SAA09958@vangogh.CS.Berkeley.EDU> To: ietf-ppp@MERIT.EDU Subject: edge condition for PPP Multilink/BACP Resent-Message-ID: <"ehZP4.0.Qv.k7EHn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1306 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU In a discussion that occured after the PPP working group meeting, in which we talked about the posibilty of removing some of the packet types from BACP, one of the framers said that the reason for the link-drop-request was that according to his understanding of PPP when system A sends a terminate-request packet to its peer, that it is required to throw any non-LCP packets it receives on the floor. This of course, is not my understanding of the "spirit of the law", and would make section 7 (Closing Member links) in the current multilink draft illegal, but I volunteered to bring this up on the mailing list for public comment. When asked about this at the meeting, Bill Simpson said that his implementation actually does continue to process incoming non-LCP packets until it receive an LCP terminate-ack or terminate-request. ("Be generous in what you accept .... ") My section 7 states: 7. Closing Member links Member links may be terminated according to normal PPP LCP procedures using LCP Terminate-Request and Terminate-Ack packets on that member link. Since it is assumed that member links usually do not reorder packets, receipt of a terminate ack is sufficient to assume that any multilink protocol packets ahead of it are at no special risk of loss. Receipt of an LCP Terminate-Request on one link does not conclude the procedure on the remaining links. (two irrelevant paragraphs deleted ...) - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Mar 12 08:11:26 1996 Received: (from slist@localhost) by merit.edu (8.7.4/merit-2.0) id IAA17207; Tue, 12 Mar 1996 08:11:26 -0500 (EST) Resent-Date: Tue, 12 Mar 1996 08:11:26 -0500 (EST) X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 12 Mar 1996 05:10:03 -0800 To: inads@research.ftp.com From: fred@cisco.com (Fred Baker) Subject: Advancement of LQM to Draft Standard Cc: Steve Coya , ietf-ppp@MERIT.EDU Resent-Message-ID: <"ntbRT.0.RC4.UVNHn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1307 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Frank: The PPP Working Group recommends that the current LQM internet draft be advanced to draft standard. The edits in the draft are minor and editorial in nature. Implementation and interoperability experience reports (minorly edited) follow in this note. In asking for hands, I can say that there are a number of LQM implementations: the following few replied to my request for implementation experience. Fred Baker PPP Working Group Chair >From: Craig Fox >Subject: Re: Request for LQM Experience >To: fred@cisco.com (Fred Baker) >Date: Mon, 4 Mar 96 20:11:50 PST >Cc: misko@cisco.com (Bill Miskovetz) >> >> We are attempting to take LQM to Draft Standard. Would everyone who has an >> implementation, please drop me a note indicating: >> >> that they have an implementation >> >We do. > >> who they have tested with and found interoperable >> >Network Systems for one. > >> if they have found non-interoperable implementations, >> what needs to be changed in the rfc. >> >Not that I am aware of. >From: Karl Fox >Date: Tue, 5 Mar 96 01:08:17 -0500 >To: fred@cisco.com (Fred Baker) >Subject: Request for LQM Experience >Organization: Morning Star Technologies, Inc. > >We have tested LQM successfully with Cisco, but I don't know what the >Cisco firmware version was. I am not aware of any non-interoperable >implementations. > >We have implemented the LQM portion of the PPP MIB. >Date: Wed, 6 Mar 96 16:11:14 EST >From: "Andrew M. Fuqua ((919) 254-9810)" >To: fred@cisco.com, ietf-ppp@merit.edu >Cc: welch@VNET.IBM.COM, DANNINGR@RALVM12.VNET.IBM.COM, mgaubrey@VNET.IBM.COM, > davemoore@VNET.IBM.COM >Subject: Request for LQM Experience > >Fred Baker wrote: >> We are attempting to take LQM to Draft Standard. Would everyone who has an >> implementation, please drop me a note indicating: >> >> that they have an implementation >> >> who they have tested with and found interoperable >> >> if they have found non-interoperable implementations, >> what needs to be changed in the rfc. >> >> Tell me also if you have implemented the MIB, what portions you did not >> implement, and what recommendations you have concerning it. > >The IBM 6611 has implemented RFC 1333 LQM. > >We tested LQM (very successfully) with Morning Star Technologies at >the 4/94 PPP consortium. Everything worked like a charm. I remember >being surprised that all of our counters were identical; I was >expecting that one of us (me) would miscount the flag or something. > >We tested LQM with early implementations from 3 other companies but >those implementations weren't ready. We found several code bugs >that the other companies said they would fix. Even so, it looks >promising. (None of them were problems with the draft.) > >I have an interoperability guy who has done testing since then >and could tell us if things have improved but he is out of the >office for a few days. I'll ask him to reply when he gets back. > >andrew =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= It has recently been discovered that research causes cancer in rats. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Mar 12 11:41:20 1996 Received: (from slist@localhost) by merit.edu (8.7.4/merit-2.0) id LAA23630; Tue, 12 Mar 1996 11:41:20 -0500 (EST) Resent-Date: Tue, 12 Mar 1996 11:41:20 -0500 (EST) Date: Tue, 12 Mar 96 09:37:00 EST From: hhs@teleoscom.com (Chip Sharp X-6424) Message-Id: <9603121437.AA16855@teleoscom.com> To: sklower@vangogh.CS.Berkeley.EDU Cc: ietf-ppp@MERIT.EDU In-Reply-To: Keith Sklower's message of Mon, 11 Mar 1996 18:30:43 -0800 (PST) <199603120230.SAA09958@vangogh.CS.Berkeley.EDU> Subject: edge condition for PPP Multilink/BACP Resent-Message-ID: <"OPjyf2.0.xm5.gaQHn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1308 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >From: Keith Sklower >...link-drop-request was that according to his understanding of PPP >when system A sends a terminate-request packet to its peer, that >it is required to throw any non-LCP packets it receives on the >floor. ....stuff deleted... The confusion probably comes from RFC 1661. In Section 3.7 "Link Termination Phase", the fourth paragraph consists of the following sentence: "Any non-LCP packets received during this phase MUST be silently discarded." The assumption is that the "phase" begins when a Terminate-Request is transmitted. This should be modified (at least for multilink) as follows: A multilink implementation SHOULD be able to receive non-LCP packets after transmitting a Terminate-Request and before receiving a Terminate-ACK. A multilink implementation MUST drop non-LCP packets received after receiving a Terminate-Request or Terminate-ACK. A multilink implementation MUST not transmit non-LCP packets after transmitting a Terminate-Request or Terminate-ACK. Chip Sharp P.S. Due to a change of jobs, I will not be at this address after Friday, 3/15. Hopefully, I'll be able to pick up any responses after 4/1. ======================================================================= After 3/15 (the Ides of March), the following info will be obsolete (except my name :-) ) Hascall H. ("Chip") Sharp Madge Networks SMTS WAN Access Products voice: +1 908 544 6424 2 Meridian Road fax: +1 908 544-6460 Eatontown, NJ 07724 USA email: csharp@madge.com ======================================================================== - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Mar 12 12:17:22 1996 Received: (from slist@localhost) by merit.edu (8.7.4/merit-2.0) id MAA25027; Tue, 12 Mar 1996 12:17:22 -0500 (EST) Resent-Date: Tue, 12 Mar 1996 12:17:22 -0500 (EST) Date: Tue, 12 Mar 1996 10:16:53 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199603121716.KAA10251@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: RE: Comments on PSCP draft -Reply Resent-Message-ID: <"UPcT81.0.q66.V6RHn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1309 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > To: Ruth Tsai > ... > If the principle of keeping the NCPs up with the underlying bundle links >suspended is accepted, then the proposed spoofing protocol would clean up: we > would not need to have a data link reference number negotiated at the LCP > level. The problem about having potentially different NCP characteristics > after the suspension and resumption of the links would not arise. > > If the "bundle" layer described above were made explicit in the PPP > architecture, then this spoofing protocol (along with BAP) would be a bundle > level protocol (rather than a NCP level protocol). This is a fine > distinction. We could still preserve the explicit PPP 2 layer (NCP/LCP) > architecture by thinking of these protocols as NCPs that pertain to the > characteristics of the underlying bundle rather than to characteristics of > network layer protocols (like IP or IPX). > > It should be noted that because the original PPP RFCs were developed prior to > the discussions of bundles and protocols that concern themselves with bundle >atttributes, the main model of those RFCs is the single link. ... Ok, that sounds reasonable. But why is all of this needed? Is it something distintive about IPX? There are many, very mature commercial implementations of fully demand-dialing, bandwidth-on-demand, RFC 1717 multilink PPP in the field. They seem to work fine without PCSP. Consider my personal installation. It is a symmetric demand-dialing PPP link (i.e. either peer calls as traffic dictates). On both sides of the link are more than one IP network. Hosts on either side use RIP, RIPv2, OSPF, IGRP, and BGP4 and do not know that this particular link is special, other than it is slow all of the time and incredibly slow some of the time (when it must be restored). As a user, what would I get from all of this? I don't use IPX; is there something about IP that avoids problem seen with IPX and demand-dialing? The Silicon Graphics demand-dialing scheme leaves the UNIX "network interface" alive, but lets the IP NCP(s) come and go as necessary. It relies on common sense to ensure that when the NCP is re-instantiated, it is sufficiently similar to the previous incarnation (and sanity checks just in case). There is nothing in LCP or IPCP that needs to be the same from instantiation to instantiation except the IP addresses, the MTUs, and whether RFC 1717 MP is allowed. Everything else can change. The greatest defect in PPP in general is its bloat and general complexity. Will BACP and PSCP contribute enough to justify their cost in complexity? Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Mar 12 12:31:14 1996 Received: (from slist@localhost) by merit.edu (8.7.4/merit-2.0) id MAA26054; Tue, 12 Mar 1996 12:31:14 -0500 (EST) Resent-Date: Tue, 12 Mar 1996 12:31:14 -0500 (EST) Date: Tue, 12 Mar 1996 10:30:55 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199603121730.KAA10328@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: edge condition for PPP Multilink/BACP Resent-Message-ID: <"frRaW3.0.tM6.VJRHn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1310 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Keith Sklower > In a discussion that occured after the PPP working group meeting, > in which we talked about the posibilty of removing some of the packet > types from BACP, one of the framers said that the reason for the > link-drop-request was that according to his understanding of PPP > when system A sends a terminate-request packet to its peer, that > it is required to throw any non-LCP packets it receives on the > floor. > ... > When asked about this at the meeting, Bill Simpson said that his > implementation actually does continue to process incoming non-LCP > packets until it receive an LCP terminate-ack or terminate-request. > ("Be generous in what you accept .... ") Are you saying that some implementations discard received non-LCP packets just because they have <> a Terminate-Request? That seems at best undesirable unless the Terminate-Request is really a white flag indicating impending unilateral disconnection regardless of whether a Terminate-Ack is received. Why not continue to process all traffic until a suitable Terminate-Ack, the peer's own Terminate-Request, or loss of carrier (or ISDN cause code, etc) is received? What is the harm? If a system is going to discard everything except for the Terminate-Ack, then why bother waiting for the Terminate-Ack, while paying money to the telco for the sport? If a system is going to ignore everything received, it should instead pull the plug immediately after sending the Terminate-Request. Or not bother sending the Terminate-Request and just pull the plug. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Mar 12 14:25:26 1996 Received: (from slist@localhost) by merit.edu (8.7.4/merit-2.0) id OAA29906; Tue, 12 Mar 1996 14:25:26 -0500 (EST) Resent-Date: Tue, 12 Mar 1996 14:25:26 -0500 (EST) Date: Tue, 12 Mar 1996 11:22:44 -0800 From: kevin@smith.ascend.com (Kevin Smith) Message-Id: <9603121922.AA11117@smith.ascend.com.ascend.com> To: ietf-ppp@MERIT.EDU, fred@cisco.com Subject: Re: PPP Minutes - LA-IETF Cc: crichards@shiva.com X-Sun-Charset: US-ASCII Resent-Message-ID: <"0wFyW1.0.3J7.Y-SHn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1311 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: fred@cisco.com (Fred Baker) > > Craig Richards/Kevin Smith [who was not present] BACP Due to extraneous circumstances (someone's gonna get sued! :) > Purpose of BAP/BACP: > - multiple servers on a huntgroup > - interoperable bandwidth on demand > - reduce end user configuration burden > > Bandwidth on Demand: > - Resource BOD allows an implementation to unilaterally make decisions > - Throughput BOD depends on traffic transmitted. > > New draft coming out. > > Bake-off at Pac Bell May 20th > 2 days of multilink testing > 2 days of CCP testing > 1 day BACP testing BASED ON WHICH VERSION ? > up to 56 vendors can be accomodated. There will be > 40 analog links > 98 BRI links > 4 PRI links (92 B channels) > > The sense in the room was that the protocol is too complex; that a > sufficient subset of its features can be implemented with a much simpler > protocol. Specifically, rather than enumerating link types, it was > suggested that one might request certain amount of bandwidth as an > integer, potentially with a link type of V.110, V.120, ISDN Sync, or > standard Async. It was also suggested that the bundle drop and available > link messages are unnecessary. > > Craig is to develop a feature set proposal and discuss the matter further > on the list. So, the BACP bake-off will be based on features in the existing draft, or the modified draft ? What was the deadline set for the modified draft ? Kevin - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Mar 12 14:32:47 1996 Received: (from slist@localhost) by merit.edu (8.7.4/merit-2.0) id OAA00522; Tue, 12 Mar 1996 14:32:47 -0500 (EST) Resent-Date: Tue, 12 Mar 1996 14:32:47 -0500 (EST) Date: Tue, 12 Mar 1996 14:36:25 -0500 From: Patrick Klos Message-Id: <199603121936.OAA04456@linux.klos.com> To: ietf-ppp@MERIT.EDU Subject: Re: edge condition for PPP Multilink/BACP Resent-Message-ID: <"q17lS3.0.v7.R5THn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1312 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >> In a discussion that occured after the PPP working group meeting, >> in which we talked about the posibilty of removing some of the packet >> types from BACP, one of the framers said that the reason for the >> link-drop-request was that according to his understanding of PPP >> when system A sends a terminate-request packet to its peer, that >> it is required to throw any non-LCP packets it receives on the >> floor. >> ... >> When asked about this at the meeting, Bill Simpson said that his >> implementation actually does continue to process incoming non-LCP >> packets until it receive an LCP terminate-ack or terminate-request. >> ("Be generous in what you accept .... ") Are we talking about an LCP Terminate-Request? It sounds like we are. If so, here's what it says in RFC1661 page 9: ==> 3.7. Link Termination Phase ==> ==> PPP can terminate the link at any time. This might happen because of ==> the loss of carrier, authentication failure, link quality failure, ==> the expiration of an idle-period timer, or the administrative closing ==> of the link. ==> ==> LCP is used to close the link through an exchange of Terminate ==> packets. When the link is closing, PPP informs the network-layer ==> protocols so that they may take appropriate action. ==> ==> After the exchange of Terminate packets, the implementation SHOULD ==> signal the physical-layer to disconnect in order to enforce the ==> termination of the link, particularly in the case of an ==> authentication failure. The sender of the Terminate-Request SHOULD ==> disconnect after receiving a Terminate-Ack, or after the Restart ==> counter expires. The receiver of a Terminate-Request SHOULD wait for ==> the peer to disconnect, and MUST NOT disconnect until at least one ==> Restart time has passed after sending a Terminate-Ack. PPP SHOULD ==> proceed to the Link Dead phase. ==> ==> Any non-LCP packets received during this phase MUST be silently ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ From this, it seems quite obvious that any non-LCP packets received after sending an LCP Terminate-Request MUST be discarded. Even without the explicit actions defined here, whenever a Terminate-Request is sent, the state-machine LEAVES the Opened state. By definition, all non-LCP packets received while LCP is NOT open should be silently discarded. >Are you saying that some implementations discard received non-LCP >packets just because they have <> a Terminate-Request? That >seems at best undesirable unless the Terminate-Request is really a >white flag indicating impending unilateral disconnection regardless of >whether a Terminate-Ack is received. Like I said, maybe I missed something earlier, but why else would you send an LCP Terminate-Request if you weren't about to terminate a link? >Why not continue to process all traffic until a suitable Terminate-Ack, >the peer's own Terminate-Request, or loss of carrier (or ISDN cause >code, etc) is received? What is the harm? This conflicts with the definition of LCP and it's state machine. >If a system is going to discard everything except for the Terminate-Ack, >then why bother waiting for the Terminate-Ack, while paying money to >the telco for the sport? If a system is going to ignore everything >received, it should instead pull the plug immediately after sending the >Terminate-Request. Or not bother sending the Terminate-Request and >just pull the plug. I'm not sure exactly why it was designed this way, but if you read RFC1661, this is how it says things should work. Of course, if this discussion is not referring to LCP Terminate-Requests, then I'm putting my foot in it, so please ignore what I've said. ============================================================================ 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 ietf-ppp-request@MERIT.EDU Tue Mar 12 16:22:45 1996 Received: (from slist@localhost) by merit.edu (8.7.4/merit-2.0) id QAA04044; Tue, 12 Mar 1996 16:22:45 -0500 (EST) Resent-Date: Tue, 12 Mar 1996 16:22:45 -0500 (EST) Date: Tue, 12 Mar 1996 14:22:02 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199603122122.OAA10804@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: edge condition for PPP Multilink/BACP Resent-Message-ID: <"1Fggh.0.z-.RiUHn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1313 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Patrick Klos > ==> 3.7. Link Termination Phase > ==> > ==> PPP can terminate the link at any time. This might happen because of > ==> the loss of carrier, authentication failure, link quality failure, > ==> the expiration of an idle-period timer, or the administrative closing > ==> of the link. > ==> > ==> LCP is used to close the link through an exchange of Terminate > ==> packets. When the link is closing, PPP informs the network-layer > ==> protocols so that they may take appropriate action. > ==> > ==> After the exchange of Terminate packets, the implementation SHOULD > ==> signal the physical-layer to disconnect in order to enforce the > ==> termination of the link, particularly in the case of an > ==> authentication failure. The sender of the Terminate-Request SHOULD > ==> disconnect after receiving a Terminate-Ack, or after the Restart > ==> counter expires. The receiver of a Terminate-Request SHOULD wait for > ==> the peer to disconnect, and MUST NOT disconnect until at least one > ==> Restart time has passed after sending a Terminate-Ack. PPP SHOULD > ==> proceed to the Link Dead phase. > ==> > ==> Any non-LCP packets received during this phase MUST be silently > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > >From this, it seems quite obvious that any non-LCP packets received after > sending an LCP Terminate-Request MUST be discarded. Even without the explicit > actions defined here, whenever a Terminate-Request is sent, the state-machine >LEAVES the Opened state. By definition, all non-LCP packets received while LCP > is NOT open should be silently discarded. I don't think any of the phases are so crisply defined as to support such an argument, including this case. However, the rule about not doing any NCP stuff out of Opened seems relevant. So I'm wrong. > >Are you saying that some implementations discard received non-LCP > >packets just because they have <> a Terminate-Request? That > >seems at best undesirable unless the Terminate-Request is really a > >white flag indicating impending unilateral disconnection regardless of > >whether a Terminate-Ack is received. > > :I'm not sure exactly why it was designed this way, but if you read RFC1661, > this is how it says things should work. > ... Until Multilink, a system would not send a Terminate-Request unless it is shutting down and not expecting to receive more network packets. So it made little difference whether you accepted non-LCP packets after sending an LCP Terminate-Request. With Multilink, it matters, albeit not too much. The peer cannot know to stop using a link within a bundle until it receives your Terminate-Request, and so you must continue to accept its network packets until it answers with an LCP Terminate-Ack. This must have been obvious to whomever wrote the rules for the first multilink at PacBell's San Ramon facility in early 1995, since those tests said something about adding and removing links to a bundle without losing any network packets. Let's NOT add another protocol and state machine just for this. Instead, let's just modify RFC 1661 and/or RFC 1717 to make clear what was obvious to most of us, although in a sense wrong. That is clearly the most upward-compatible, interoperable solution. Also consider the worst possible harm from doing nothing, and losing a few packets while removing a link from a bundle. It's not desirable, but neither is it serious. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Mar 12 16:44:27 1996 Received: (from slist@localhost) by merit.edu (8.7.4/merit-2.0) id QAA04740; Tue, 12 Mar 1996 16:44:27 -0500 (EST) Resent-Date: Tue, 12 Mar 1996 16:44:27 -0500 (EST) From: Karl Fox Date: Tue, 12 Mar 96 16:42:29 -0500 Message-Id: <9603122142.AA11609@gefilte.MorningStar.Com> To: vjs@mica.denver.sgi.com (Vernon Schryver) Cc: ietf-ppp@MERIT.EDU Subject: Re: edge condition for PPP Multilink/BACP In-Reply-To: <199603122122.OAA10804@mica.denver.sgi.com> References: <199603122122.OAA10804@mica.denver.sgi.com> Reply-To: Karl Fox Organization: Morning Star Technologies, Inc. Resent-Message-ID: <"rqlXG2.0.k91.q0VHn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1314 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Vernon Schryver writes: > Let's NOT add another protocol and state machine just for this. > Instead, let's just modify RFC 1661 and/or RFC 1717 to make clear what > was obvious to most of us, although in a sense wrong. That is clearly > the most upward-compatible, interoperable solution. > > Also consider the worst possible harm from doing nothing, and losing > a few packets while removing a link from a bundle. It's not desirable, > but neither is it serious. This is a wonderful idea. I strongly support it. -- Karl Fox, servant of God, employee of Morning Star Technologies 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 451 1883 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Mar 12 18:49:27 1996 Received: (from slist@localhost) by merit.edu (8.7.4/merit-2.0) id SAA08345; Tue, 12 Mar 1996 18:49:27 -0500 (EST) Resent-Date: Tue, 12 Mar 1996 18:49:27 -0500 (EST) X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 12 Mar 1996 15:47:13 -0800 To: kevin@smith.ascend.com (Kevin Smith) From: fred@cisco.com (Fred Baker) Subject: Re: PPP Minutes - LA-IETF Cc: ietf-ppp@MERIT.EDU, crichards@shiva.com Resent-Message-ID: <"9oLUU3.0.A22.0sWHn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1315 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU At 11:22 AM 3/12/96, Kevin Smith wrote: >So, the BACP bake-off will be based on features in the existing draft, or the >modified draft ? What was the deadline set for the modified draft ? It would have to be on the updated draft; no-one present planned to implement the initial draft. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= It has recently been discovered that research causes cancer in rats. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Mar 12 19:04:48 1996 Received: (from slist@localhost) by merit.edu (8.7.4/merit-2.0) id TAA09149; Tue, 12 Mar 1996 19:04:48 -0500 (EST) Resent-Date: Tue, 12 Mar 1996 19:04:48 -0500 (EST) From: Rob Friend To: IETF-PPP Subject: CCP Status Date: Tue, 12 Mar 96 16:02:00 PST Message-Id: <314610C7@smtpgateway.stac.com> Encoding: 13 TEXT X-Mailer: Microsoft Mail V3.0 Resent-Message-ID: <"x-CNh3.0.kE2.R4XHn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1316 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Hi Fred, I saw some mail about BACP and other drafts heading towards rfc. I am still wondering about the status of CCP. What going on? When will it become an rfc? What about the compression specs, when will they advance to FYI-rfc? Regards, Robert C. Friend Stac Electronics Applications Engineering 12636 High Bluff Dr (619)794-4542 (voice) San Diego, CA 92130 (619)794-4577 (FAX) Email:rfriend@stac.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Mar 12 19:15:22 1996 Received: (from slist@localhost) by merit.edu (8.7.4/merit-2.0) id TAA09705; Tue, 12 Mar 1996 19:15:22 -0500 (EST) Resent-Date: Tue, 12 Mar 1996 19:15:22 -0500 (EST) Message-Id: <9603130016.AA6064@shivaportal.shiva.com> To: Kevin Smith Cc: ietf-ppp From: Craig Richards/Shiva Corporation Date: 12 Mar 96 18:59:38 Subject: Re: PPP Minutes - LA-IETF Mime-Version: 1.0 Content-Type: Text/Plain Resent-Message-ID: <"-tsno3.0.HN2.fDXHn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1317 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU From kevin @ smith.ascend.com (Kevin Smith) >So, the BACP bake-off will be based on features in the existing draft, or the >modified draft ? What was the deadline set for the modified draft ? The modified draft will for the most part be a sub-set of draft-bacp-01.txt. I am planning on making some changes to the way the Link-Type is negotiated, otherwise most of the changes have to do with removing things. I will be submitting draft-bacp-02.txt to internet drafts sometime this week, and I will notify the list when I do. I'm assuming that the bake-off will be based on the most recent draft at the time it is held. Craig - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Mar 12 20:12:57 1996 Received: (from slist@localhost) by merit.edu (8.7.4/merit-2.0) id UAA11479; Tue, 12 Mar 1996 20:12:57 -0500 (EST) Resent-Date: Tue, 12 Mar 1996 20:12:57 -0500 (EST) Date: Tue, 12 Mar 1996 17:10:48 -0800 From: kevin@smith.ascend.com (Kevin Smith) Message-Id: <9603130110.AA11890@smith.ascend.com.ascend.com> To: crichards@shiva.com Subject: Re: PPP Minutes - LA-IETF Cc: ietf-ppp@MERIT.EDU X-Sun-Charset: US-ASCII Resent-Message-ID: <"jEbRZ2.0.6p2.B4YHn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1318 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Craig Richards/Shiva Corporation > > > From kevin @ smith.ascend.com (Kevin Smith) > > >So, the BACP bake-off will be based on features in the existing draft, or the > >modified draft ? What was the deadline set for the modified draft ? > > The modified draft will for the most part be a sub-set of draft-bacp-01.txt. > I am planning on making some changes to the way the Link-Type is negotiated, > otherwise most of the changes have to do with removing things. I will be > submitting draft-bacp-02.txt to internet drafts sometime this week, and I will > notify the list when I do. > > I'm assuming that the bake-off will be based on the most recent draft at the > time it is held. Oh, the proverbial moving target ? Kevin - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 13 03:51:15 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id DAA22301; Wed, 13 Mar 1996 03:51:15 -0500 (EST) Resent-Date: Wed, 13 Mar 1996 03:51:15 -0500 (EST) From: gerry@spider.co.uk (CN=Gerry Meyer/OU=Eng/OU=EDI/O=Shiva) To: kevin@smith.ascend.com, ietf-ppp@MERIT.EDU Message-ID: <1996Mar13.074726.1281.147188@eurohub.spider.co.uk> X-Conversion-ID: X-Mailer: Lotus Notes via PostalUnion/SMTP for Windows NT Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Wed, 13 Mar 1996 08:48:27 GMT Subject: Re: PPP Minutes - LA-IETF Resent-Message-ID: <"A0bK02.0.ES5._neHn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1320 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >At 11:22 AM 3/12/96, Kevin Smith wrote: >>So, the BACP bake-off will be based on features in the existing draft, or the >>modified draft ? What was the deadline set for the modified draft ? >It would have to be on the updated draft; no-one present planned to >implement the initial draft. It think the word 'fully' is missing from Fred's sentence. There had been concern expressed in the PPP meeting about the size of the protocol (and the document) - and the effect that would have on its acceptability. At the end of the PPP meeting over a dozen people stayed behind for a productive discussion focusing on the essential core features of BACP and determining those features which were nice, but not essential. The -02 draft which Craig intends to bring out this week will reflect these discussions and will result in a smaller protocol which people will have time to implement for the bake-off. Gerry - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 13 03:49:57 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id DAA22143; Wed, 13 Mar 1996 03:49:57 -0500 (EST) Resent-Date: Wed, 13 Mar 1996 03:49:57 -0500 (EST) From: gerry@spider.co.uk (CN=Gerry Meyer/OU=Eng/OU=EDI/O=Shiva) To: fred@cisco.com (Fred Baker) Cc: kevin@smith.ascend.com (Kevin Smith), ietf-ppp@MERIT.EDU (ietf-ppp), crichards@shiva.com (crichards) Message-ID: <1996Mar13.074526.1281.147185@eurohub.spider.co.uk> X-Conversion-ID: X-Mailer: Lotus Notes via PostalUnion/SMTP for Windows NT Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Wed, 13 Mar 1996 08:46:47 GMT Subject: Re: PPP Minutes - LA-IETF Resent-Message-ID: <"hagZs2.0.lP5.gmeHn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1319 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >At 11:22 AM 3/12/96, Kevin Smith wrote: >>So, the BACP bake-off will be based on features in the existing draft, or the >>modified draft ? What was the deadline set for the modified draft ? >It would have to be on the updated draft; no-one present planned to >implement the initial draft. It think the word 'fully' is missing from that sentence. There had been concern expressed in the PPP meeting about the size of the protocol (and the document) - and the effect that would have on its acceptability. At the end of the PPP meeting over a dozen people stayed behind for a productive discussion focusing on the essential core features of BACP and determining those features which were nice, but not essential. The -02 draft which Craig intends to bring out this week will reflect these discussions and will result in a smaller protocol which people will have time to implement for the bake-off. Gerry - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 13 10:17:53 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id KAA00719; Wed, 13 Mar 1996 10:17:53 -0500 (EST) Resent-Date: Wed, 13 Mar 1996 10:17:53 -0500 (EST) Date: Wed, 13 Mar 1996 10:16:43 -0500 Message-Id: <9603131516.AA25220@MAILSERV-D.FTP.COM> To: ietf-ppp@MERIT.EDU Subject: status of CCP From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Sender: kasten@mailserv-d.ftp.com Repository: mailserv-d.ftp.com, [message accepted at Wed Mar 13 10:16:39 1996] Originating-Client: d-cell.ftp.com Resent-Message-ID: <"uEkus3.0.u9.6RkHn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1321 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > I saw some mail about BACP and other drafts heading towards rfc. I am still > wondering about the status of CCP. What going on? When will it become an > rfc? What about the compression specs, when will they advance to FYI-rfc? CCP is on the IESG's list of things to do. IESG ballots have been sent out. The IESG has had some personel changes since the ballots went out. This means that some new folks need to acquaint themselves with it. Of course, the new chair of the IESG is Fred Baker. -- Frank Kastenholz - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 13 13:40:00 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id NAA09409; Wed, 13 Mar 1996 13:40:00 -0500 (EST) Resent-Date: Wed, 13 Mar 1996 13:40:00 -0500 (EST) Message-Id: <9603131801.AA8958@hqsmtp.ops.3com.com> To: Vernon Schryver Cc: ietf-ppp From: Daniel Brennan/US/3Com Date: 13 Mar 96 9:15:51 EDT Subject: Re: edge condition for PPP Multilink/BACP Mime-Version: 1.0 Content-Type: Text/Plain Resent-Message-ID: <"H2dnF.0.kI2.uPnHn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1322 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >Let's NOT add another protocol and state machine just for this. >Instead, let's just modify RFC 1661 and/or RFC 1717 to make clear what >was obvious to most of us, although in a sense wrong. That is clearly >the most upward-compatible, interoperable solution. > >Also consider the worst possible harm from doing nothing, and losing >a few packets while removing a link from a bundle. It's not desirable, >but neither is it serious. > > >Vernon Schryver, vjs@sgi.com I agree with Vernon. Most of us provide the flexibility to continue receiving after sending a TERM_REQ. Let's remove the dreaded IETF *MUST* from the RFC and move forward. Alright Vernon! I can't believe I agree 100% with you bro'. Dan Brennan 3Com Access Products - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 13 15:01:13 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id PAA12602; Wed, 13 Mar 1996 15:01:13 -0500 (EST) Resent-Date: Wed, 13 Mar 1996 15:01:13 -0500 (EST) Date: Wed, 13 Mar 1996 15:04:42 -0500 From: Patrick Klos Message-Id: <199603132004.PAA06033@linux.klos.com> To: Daniel_Brennan@3mail.3Com.COM, vjs@mica.denver.sgi.com Subject: Re: edge condition for PPP Multilink/BACP Cc: ietf-ppp@MERIT.EDU Resent-Message-ID: <"QuTKr.0.W43._boHn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1323 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >>Let's NOT add another protocol and state machine just for this. >>Instead, let's just modify RFC 1661 and/or RFC 1717 to make clear what >>was obvious to most of us, although in a sense wrong. That is clearly >>the most upward-compatible, interoperable solution. >> >>Also consider the worst possible harm from doing nothing, and losing >>a few packets while removing a link from a bundle. It's not desirable, >>but neither is it serious. >> >> >>Vernon Schryver, vjs@sgi.com > >I agree with Vernon. Most of us provide the flexibility to continue receiving >after >sending a TERM_REQ. Let's remove the dreaded IETF *MUST* from the RFC >and move forward. Alright Vernon! I can't believe I agree 100% with you bro'. I'm sorry, Dan, but I don't agree. Both the state machine and the RFC specifically indicate that non-LCP packets are NOT to be processed when LCP is not in the Opened state (i.e. after the Terminate-Request is sent). This is the way it's been for several years now! You don't just go change something at such a BASIC LEVEL because it'll make Multi-Link a little better. I'd go along with a Multi-Link Control Protocol (outside of LCP) with which an indication could be made that a link should not be considered part of a bundle any longer, where received packets were still processed until the Request to drop from a bundle is Acked. I don't agree with changing the fundamentals of LCP. Patrick ============================================================================ 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 ietf-ppp-request@MERIT.EDU Wed Mar 13 15:14:45 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id PAA13455; Wed, 13 Mar 1996 15:14:45 -0500 (EST) Resent-Date: Wed, 13 Mar 1996 15:14:45 -0500 (EST) Date: Wed, 13 Mar 1996 15:18:29 -0500 From: Patrick Klos Message-Id: <199603132018.PAA06046@linux.klos.com> To: ietf-ppp@MERIT.EDU, vjs@mica.denver.sgi.com Subject: Re: edge condition for PPP Multilink/BACP Resent-Message-ID: <"q8iG33.0.xH3.mooHn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1324 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >> By definition, all non-LCP packets received while LCP >> is NOT open should be silently discarded. > >I don't think any of the phases are so crisply defined as to support >such an argument, including this case. Actually, the word "MUST" has a VERY CRISP definition in the context of RFCs! >However, the rule about not doing any NCP stuff out of Opened seems relevant. > >So I'm wrong. The two arguments go hand-in-hand. >Until Multilink, a system would not send a Terminate-Request unless it >is shutting down and not expecting to receive more network packets. So >it made little difference whether you accepted non-LCP packets after >sending an LCP Terminate-Request. With Multilink, it matters, albeit >not too much. The peer cannot know to stop using a link within a >bundle until it receives your Terminate-Request, and so you must >continue to accept its network packets until it answers with an LCP >Terminate-Ack. I'm sure we all understand the problem being addressed. It's just that the solution needs to be thought out a little more. As with many other features people have wanted to add over the years, the problem isn't in LCP, so why change it?!? Let's fix the problem properly, and not hack at the state machine because some vendors have already broken PPP to suite thier needs. >Let's NOT add another protocol and state machine just for this. >Instead, let's just modify RFC 1661 and/or RFC 1717 to make clear what >was obvious to most of us, although in a sense wrong. That is clearly >the most upward-compatible, interoperable solution. I say leave RFC1661 alone and fix RFC1717 (somehow). >Also consider the worst possible harm from doing nothing, and losing >a few packets while removing a link from a bundle. It's not desirable, >but neither is it serious. Quite true. Patrick ============================================================================ 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 ietf-ppp-request@MERIT.EDU Wed Mar 13 15:19:03 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id PAA13702; Wed, 13 Mar 1996 15:19:03 -0500 (EST) Resent-Date: Wed, 13 Mar 1996 15:19:03 -0500 (EST) Date: Wed, 13 Mar 1996 13:17:10 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199603132017.NAA14624@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: edge condition for PPP Multilink/BACP Resent-Message-ID: <"n2gat1.0.PK3.lroHn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1325 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Patrick Klos > >.. > I'm sorry, Dan, but I don't agree. Both the state machine and the RFC > specifically indicate that non-LCP packets are NOT to be processed when LCP is > not in the Opened state (i.e. after the Terminate-Request is sent). This is > the way it's been for several years now! You don't just go change something > at such a BASIC LEVEL because it'll make Multi-Link a little better. > > I'd go along with a Multi-Link Control Protocol (outside of LCP) with which > an indication could be made that a link should not be considered part of a > bundle any longer, where received packets were still processed until the > Request to drop from a bundle is Acked. I don't agree with changing the > fundamentals of LCP. What is so fundamental about whether you listen to packets after sending a Terminate-Request? Asking the rest of us to change our code to obey the injunction is overall a far bigger and more fundamental change than allowing the few implementations that currently obey it to relax. To have such MP signalling outside LCP requires involves a whole new packet type or protocol, since MP is currently based purely on LCP Configure-Request options. That would be far more substantial and fundamental than changing RFC 1661 to say something like: An implementation MAY continue to accept NCP packets after sending an LCP Terminate-Request until it receives a matching Terminate-Ack. It MUST NOT originate any NCP packets after sending an LCP Terminate-Request. (I think that last sentence is the entire point of the current prohibition during the Terminate Phase.) At the worst, if you don't change, you might lose a packet or two when removing a link from a bundle. But remember that you generally remove links only when things are fairly idle, which reduces the chances of such losses. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 13 15:28:30 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id PAA14564; Wed, 13 Mar 1996 15:28:30 -0500 (EST) Resent-Date: Wed, 13 Mar 1996 15:28:30 -0500 (EST) To: IETF-Announce:; cc: ietf-ppp@MERIT.EDU From: The IESG Subject: Last Call: The PPP Multilink Protocol (MP) to Draft Standard Date: Wed, 13 Mar 96 15:16:59 -0500 Sender: scoya@CNRI.Reston.VA.US Message-ID: <9603131517.aa21949@IETF.CNRI.Reston.VA.US> Resent-Message-ID: <"SLRRU.0.IZ3.f_oHn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1326 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU The IESG has received a request from the Point-to-Point Protocol Extensions Working Group to consider "The PPP Multilink Protocol (MP)" for the status of Draft Standard. This is an update to RFC1717, currently 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@cnri.reston.va.us or ietf@cnri.reston.va.us mailing lists by March 27, 1996. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 13 16:01:50 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id QAA16857; Wed, 13 Mar 1996 16:01:50 -0500 (EST) Resent-Date: Wed, 13 Mar 1996 16:01:50 -0500 (EST) To: IETF-Announce:; cc: ietf-ppp@MERIT.EDU From: The IESG Subject: Last Call: PPP Link Quality Monitoring to Draft Standard Date: Wed, 13 Mar 96 15:25:02 -0500 Sender: scoya@CNRI.Reston.VA.US Message-ID: <9603131525.aa22234@IETF.CNRI.Reston.VA.US> Resent-Message-ID: <"ioA5i1.0.474.sUpHn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1327 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU The IESG has received a request from the Point-to-Point Protocol Extensions Working Group to consider "PPP Link Quality Monitoring" for the status of Draft Standard. This is an update to RFC1333, currently 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@cnri.reston.va.us or ietf@cnri.reston.va.us mailing lists by March 27, 1996. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 13 16:13:54 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id QAA17755; Wed, 13 Mar 1996 16:13:54 -0500 (EST) Resent-Date: Wed, 13 Mar 1996 16:13:54 -0500 (EST) Date: Wed, 13 Mar 96 16:13:12 EST From: eallen@BayNetworks.com (Ed Allen) Message-Id: <9603132113.AA27263@pobox.BayNetworks.com> To: ietf-ppp@MERIT.EDU Subject: edge condition for PPP Multilink/BACP Resent-Message-ID: <"yFKIs3.0.-K4.BgpHn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1328 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Vernon Schryver writes: > Let's NOT add another protocol and state machine just for this. > Instead, let's just modify RFC 1661 and/or RFC 1717 to make clear what > was obvious to most of us, although in a sense wrong. That is clearly > the most upward-compatible, interoperable solution. > Also consider the worst possible harm from doing nothing, and losing > a few packets while removing a link from a bundle. It's not desirable, > but neither is it serious. So to summarize this discussion, our proposal is to: 1. modify RFC 1661 to explicitly allow something which is outlawed in section 3.7 (that is, accepting non-LCP packets in the ? state) but which has in fact been implemented by interoperable implementations. Perhaps 4th paragraph should now read "Any non-LCP packets received during this phase MAY be silently discarded" or use the phrasing proposed by Vernon in a later message. The MAY is a MUST in 1661. 2. continue to consider systems (for purposes of interoperability testing) which send a Term-Req and then toss received NCP packets to be "compliant with RFC 1661, and its successors." This happens via the replacement of MUST by MAY. If you toss received NCP packets, nobody faults you in interoperability tests, such as the one cited earlier in mail by V. Shryver. This protects the implementations which followed the letter of the law. 3. Section 17 in RFC 1717 can be left alone, there is now no harm in the implication that a system will receive packets after sending a Term-Req. 4. We can proceed with BACP with the assumption that a Link-Drop-Request/Response is not necessary (unless it is needed for some reason other than the one cited in the discussion which followed the LA WG meeting). - Ed Allen, Bay Networks - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 13 16:17:07 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id QAA17936; Wed, 13 Mar 1996 16:17:07 -0500 (EST) Resent-Date: Wed, 13 Mar 1996 16:17:07 -0500 (EST) To: IETF-Announce:; cc: ietf-ppp@MERIT.EDU From: The IESG Subject: Last Call: PPP Challenge Handshake Authentication Protocol (CHAP) to Draft Standard Date: Wed, 13 Mar 96 15:32:35 -0500 Sender: scoya@CNRI.Reston.VA.US Message-ID: <9603131532.aa22570@IETF.CNRI.Reston.VA.US> Resent-Message-ID: <"YIzaj1.0.xN4.AjpHn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1329 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU The IESG has received a request from the Point-to-Point Protocol Extensions Working Group to consider "PPP Challenge Handshake Authentication Protocol (CHAP)" for the status of Draft Standard. This is an update to RFC1334, currently 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@cnri.reston.va.us or ietf@cnri.reston.va.us mailing lists by March 27, 1996. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 13 16:44:33 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id QAA19899; Wed, 13 Mar 1996 16:44:33 -0500 (EST) Resent-Date: Wed, 13 Mar 1996 16:44:33 -0500 (EST) Date: Wed, 13 Mar 1996 16:48:12 -0500 From: Patrick Klos Message-Id: <199603132148.QAA06254@linux.klos.com> To: ietf-ppp@MERIT.EDU, vjs@mica.denver.sgi.com Subject: Re: edge condition for PPP Multilink/BACP Resent-Message-ID: <"rSDn51.0.ds4.w6qHn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1330 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >> I'd go along with a Multi-Link Control Protocol (outside of LCP) with which >> an indication could be made that a link should not be considered part of a >> bundle any longer, where received packets were still processed until the >> Request to drop from a bundle is Acked. I don't agree with changing the >> fundamentals of LCP. > > >What is so fundamental about whether you listen to packets after >sending a Terminate-Request? Asking the rest of us to change our code >to obey the injunction is overall a far bigger and more fundamental >change than allowing the few implementations that currently obey it to >relax. What's so fundamental?!? Read the RFC (1661). The text about processing non-LCP packets when LCP is not Opened hasn't changed since who knows when! The Opened state defines explicitly what can be done when, and now you want to change it?!? I'm sorry if you feel I'm asking "the rest of you" to change your code to "obey the injunction", but the injunction HAS ALWAYS BEEN THERE; you just choose to ignore it! >To have such MP signalling outside LCP requires involves a whole new >packet type or protocol, since MP is currently based purely on LCP >Configure-Request options. Just because MP was originally designed to piggy back LCP doesn't mean that now LCP must bear the brunt of any shortcomings that MP might have caused! I don't recall why MP was piggy backed in the first place, rather than negotiated as a seperate control protocol, but that point is moot right now. >That would be far more substantial and >fundamental than changing RFC 1661 to say something like: > > An implementation MAY continue to accept NCP packets after sending > an LCP Terminate-Request until it receives a matching Terminate-Ack. > It MUST NOT originate any NCP packets after sending an LCP > Terminate-Request. No. This breaks the state machine. Any non-LCP packet received while LCP is not in the Opened state MUST be silently discarded! > (I think that last sentence is the entire point of the current > prohibition during the Terminate Phase.) I disagree. No network traffic should occur unless LCP is Opened. >At the worst, if you don't change, you might lose a packet or two when >removing a link from a bundle. But remember that you generally remove >links only when things are fairly idle, which reduces the chances of >such losses. Exactly! So why fix LCP when it aint broke?? If someone REALLY REALLY wants to not drop packets when shutting down a link, then they should address the issue in Multi-Link, NOT LCP! Patrick ============================================================================ 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 ietf-ppp-request@MERIT.EDU Wed Mar 13 17:25:45 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id RAA21589; Wed, 13 Mar 1996 17:25:45 -0500 (EST) Resent-Date: Wed, 13 Mar 1996 17:25:45 -0500 (EST) Date: Wed, 13 Mar 1996 15:25:01 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199603132225.PAA15426@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: edge condition for PPP Multilink/BACP Resent-Message-ID: <"AcW1O1.0.3H5.XjqHn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1331 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Patrick Klos > ... > >To have such MP signalling outside LCP requires involves a whole new > >packet type or protocol, since MP is currently based purely on LCP > >Configure-Request options. > > Just because MP was originally designed to piggy back LCP doesn't mean that > now LCP must bear the brunt of any shortcomings that MP might have caused! > I don't recall why MP was piggy backed in the first place, rather than > negotiated as a seperate control protocol, but that point is moot right > now. You have an different notion of what is fundamental, at least outside of outfits like the OSI (no insult to you or the OSI intended; just a statement of fact; different strokes and all that). Around here, we claim to modify the documents to reflect the "working code", instead of the other way around. > >That would be far more substantial and > >fundamental than changing RFC 1661 to say something like: > > > > An implementation MAY continue to accept NCP packets after sending > > an LCP Terminate-Request until it receives a matching Terminate-Ack. > > It MUST NOT originate any NCP packets after sending an LCP > > Terminate-Request. > > No. This breaks the state machine. Any non-LCP packet received while > LCP is not in the Opened state MUST be silently discarded! Please say how that "breaks the state machine." As I see understand the concept, a broken state machine must make a wrong transition or fail to make a necessary transition or execute a wrong action. And "wrong" is defined only in concrete terms expressable in lost or corrupted or delayed data. That some documents somewhere are violated is absolutely irrelevant in the face of code that works better for having violated the documents. Or so the IETF still claims. > > (I think that last sentence is the entire point of the current > > prohibition during the Terminate Phase.) > > I disagree. No network traffic should occur unless LCP is Opened. No network traffic should occur until LCP has been OPENED, for obvious reasons. What happens after LCP has been OPENED is a different issue. > >At the worst, if you don't change, you might lose a packet or two when > >removing a link from a bundle. But remember that you generally remove > >links only when things are fairly idle, which reduces the chances of > >such losses. > > Exactly! So why fix LCP when it aint broke?? If someone REALLY REALLY > wants to not drop packets when shutting down a link, then they should > address the issue in Multi-Link, NOT LCP! Only in the OSI and perhaps the IEEE and ANSI are such arguments based on sub-layer document turf wars admissable. Here we at least claim to care about what works best more than exactly which layer or document owns which problem. So exactly what would break if the Terminate Phase were defined to start at the reception of a Terminate-Ack or Terminate-Request? (Of course, with the additional restriction that you don't originate NCP traffic after sending a Terminate-Request.) Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 13 17:30:19 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id RAA21836; Wed, 13 Mar 1996 17:30:19 -0500 (EST) Resent-Date: Wed, 13 Mar 1996 17:30:19 -0500 (EST) Date: Wed, 13 Mar 1996 15:09:13 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199603132209.PAA15348@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: edge condition for PPP Multilink/BACP Resent-Message-ID: <"nx5Ob1.0.wI5.bnqHn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1332 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Patrick Klos > ... > >I don't think any of the phases are so crisply defined as to support > >such an argument, including this case. > > Actually, the word "MUST" has a VERY CRISP definition in the context of RFCs! On the contrary, while the word "MUST" may be crisp, the definition of all of the PPP phases is very mushy. It's obvious most of phases do not correspond to any of the states of the LCP state machine. Some of the phases transitions may occur on some of the LCP state transitions, but at most some of the time. For example, on which transitions in and out of OPENED is there a Phase transition? In this case, does the Terminate Phase start on the transmission of a Terminate-Request or the reception of the Terminate-Ack? Except for the general no-NCP-out-of-Opened rule, you could say the Terminate Phase must wait until the Terminate-Ack, since many of the other phases start or end at an Ack, not sending a Request. > ... > I'm sure we all understand the problem being addressed. It's just that the > solution needs to be thought out a little more. As with many other features > people have wanted to add over the years, the problem isn't in LCP, so why > change it?!? Let's fix the problem properly, and not hack at the state > machine because some vendors have already broken PPP to suite thier needs. A good case can be made that you are demanding a change in LCP, by demanding a novel (to most of us) and legalistic interpretation of the old words. We all know that any standard is what implementations do more than what any particular glob of words happens to claim. Reading a standard through common-sense-colored glasses hardly qualifies as having "broken PPP." Out here in the real world, we all know that absolutely all standards documents are incorrect and imperfect, and that what matters absolutely above any considersations of what the standard says is what works. Instead of arguing that RFC 1661 is somehow devine, involiate writ that cannot ever be changed, please say in concrete and practical terms how and why a new protocol, a new packet type, or a new LCP Configure-Request option is better than simply relaxing a restriction that most of us knew better than to even realize existed. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 13 17:43:10 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id RAA22861; Wed, 13 Mar 1996 17:43:10 -0500 (EST) Resent-Date: Wed, 13 Mar 1996 17:43:10 -0500 (EST) Date: Wed, 13 Mar 1996 14:39:18 -0800 From: kevin@smith.ascend.com (Kevin Smith) Message-Id: <9603132239.AA13339@smith.ascend.com.ascend.com> To: ietf-ppp@MERIT.EDU, gerry@spider.co.uk Subject: Re: PPP Minutes - LA-IETF X-Sun-Charset: US-ASCII Resent-Message-ID: <"vjVDN2.0.ta5.ozqHn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1333 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: gerry@spider.co.uk (CN=Gerry Meyer/OU=Eng/OU=EDI/O=Shiva) > > >At 11:22 AM 3/12/96, Kevin Smith wrote: > >>So, the BACP bake-off will be based on features in the existing draft, or the > >>modified draft ? What was the deadline set for the modified draft ? > > >It would have to be on the updated draft; no-one present planned to > >implement the initial draft. > > It think the word 'fully' is missing from Fred's sentence. There had been > concern > expressed in the PPP meeting about the size of the protocol (and the document) > - > and the effect that would have on its acceptability. Concern had been raised numerous times on this mailing list too. It was not a new concern raised at the meeting. For that reason, I wonder if the revised draft will be any better received just because it's "better" than the original. I suspect at least another round of comments would be appropriate before the draft is "frozen" to such a state that we can all go away and complete the implementation...? > At the end of the PPP meeting over a dozen people stayed behind for a productive > discussion focusing on the essential core features of BACP and determining those > features which were nice, but not essential. The -02 draft which Craig intends to > bring out this week will reflect these discussions and will result in a smaller protocol > which people will have time to implement for the bake-off. Assuming wide agreement that it is now implementable....or will changes continue to be made upto the date of the bake-off ? That's my reason for asking *if* there was a target deadline for agreement on the modified draft. Kevin - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 13 18:33:58 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id SAA25055; Wed, 13 Mar 1996 18:33:58 -0500 (EST) Resent-Date: Wed, 13 Mar 1996 18:33:58 -0500 (EST) Message-Id: <9603132336.AA1938@shivaportal.shiva.com> To: ietf-ppp From: Craig Richards/Shiva Corporation Date: 13 Mar 96 18:31:30 Subject: draft-ietf-pppext-bacp-02.txt Mime-Version: 1.0 Content-Type: Text/Plain Resent-Message-ID: <"q9p8u1.0.876.LjrHn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1334 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU A new version of the BACP draft reflecting comments received at the ietf meeting in LA has been submitted to internet-drafts. It can be found at ftp://ftp.shiva.com/ietf-drafts/draft-ietf-pppext-bacp-02.txt. Here's a list of changes made from the previous draft: Removed Link-Drop-Request, Bundle-Drop-Request, Link-Type-Request, Available-Link-Indication and associated Response datagrams. Changed Call-Failure-Indication to Call-Status-Indication, and made it mandatory for each call attempted. Removed Link-Types and Time-Until-Retry options. Replaced Call-Add-Code, Nak-Code and Drop-Code options with new Reason option. Replaced Call-Failure-Code option with Call-Status option. Removed National Destination Code and Country Code Phone Number sub-options. Removed Base Phone Number and Datagrams-Supported Configuration Options. Changed the Link-Type option format. Made Link-Discriminator mandatory. Added Request-Rej and Request-Full-Nak Response Codes. Updated descriptions to reflect the new changes. Added language to point out the LCP Terminate-Request edge condition. Other editorial changes. Craig - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 13 20:27:48 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id UAA28749; Wed, 13 Mar 1996 20:27:48 -0500 (EST) Resent-Date: Wed, 13 Mar 1996 20:27:48 -0500 (EST) Date: Wed, 13 Mar 1996 20:31:20 -0500 From: Patrick Klos Message-Id: <199603140131.UAA06410@linux.klos.com> To: ietf-ppp@MERIT.EDU Subject: Re: Don't change LCP! Resent-Message-ID: <"1c7-t.0.s07.5OtHn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1335 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >> Just because MP was originally designed to piggy back LCP doesn't mean that >> now LCP must bear the brunt of any shortcomings that MP might have caused! >> I don't recall why MP was piggy backed in the first place, rather than >> negotiated as a seperate control protocol, but that point is moot right >> now. > >You have an different notion of what is fundamental, at least outside >of outfits like the OSI (no insult to you or the OSI intended; just a >statement of fact; different strokes and all that). Around here, we >claim to modify the documents to reflect the "working code", instead of >the other way around. Well, excuse me! There's tons of working code out there, but I haven't heard one person say "I accept non-LCP packets after an LCP Terminate- Request, and I don't do MultiLink", so this kludge you so fondly refer to as "working code" is JUST a Multilink issue, and as such, should be fixed by Multilink, NOT LCP! It's funny how you seem to defend the documents when convenient, and working code when it's your code that diverges from the spec. >> No. This breaks the state machine. Any non-LCP packet received while >> LCP is not in the Opened state MUST be silently discarded! > >Please say how that "breaks the state machine." As I see understand >the concept, a broken state machine must make a wrong transition or >fail to make a necessary transition or execute a wrong action. The state machine is not just a state transition table, but the rules that go along with that table. You've already agreed that non-LCP stuff shouldn't happen when LCP is not Opened, and now you're backing down? >And "wrong" is defined only in concrete terms expressable in lost >or corrupted or delayed data. That some documents somewhere are >violated is absolutely irrelevant in the face of code that works >better for having violated the documents. Or so the IETF still >claims. I'll have to remember some of these arguments when you start pushing someone around claiming bloat and unnecessary functionality when they want to add something useful. Usually, if you don't personally have a use for something, you call it excessive bloat and unnecessary. But when you like something, even if it is non-standard, you don't stop till you get it! >> I disagree. No network traffic should occur unless LCP is Opened. > >No network traffic should occur until LCP has been OPENED, for obvious >reasons. What happens after LCP has been OPENED is a different issue. Oh, now we have to add a state to the state machine, call "WAS OPENED"?!? Please! Stop mincing words. Put me in touch with ONE PERSON who's not doing Multilink, but explicitly allows non-LCP packets after sending an LCP Terminate-Request for some good reason. >> >At the worst, if you don't change, you might lose a packet or two when >> >removing a link from a bundle. But remember that you generally remove >> >links only when things are fairly idle, which reduces the chances of >> >such losses. >> >> Exactly! So why fix LCP when it aint broke?? If someone REALLY REALLY >> wants to not drop packets when shutting down a link, then they should >> address the issue in Multi-Link, NOT LCP! > >Only in the OSI and perhaps the IEEE and ANSI are such arguments based >on sub-layer document turf wars admissable. Here we at least claim >to care about what works best more than exactly which layer or document >owns which problem. I thought what we cared about was INTEROPERABILITY! Independent developers can only reach interoperability by following the same specs. That's what makes things work! Not this ad hoc attitude of "mine's better, so screw the spec!". >So exactly what would break if the Terminate Phase were defined to >start at the reception of a Terminate-Ack or Terminate-Request? >(Of course, with the additional restriction that you don't originate >NCP traffic after sending a Terminate-Request.) What would break if we added an option to LCP to negotiate a link level compression protocol?? Nothing! But that's not where it belongs, so let's put things where they belong! >> >I don't think any of the phases are so crisply defined as to support >> >such an argument, including this case. >> >> Actually, the word "MUST" has a VERY CRISP definition in the context of RFCs! > >On the contrary, while the word "MUST" may be crisp, the definition of >all of the PPP phases is very mushy. It's obvious most of phases do >not correspond to any of the states of the LCP state machine. Some of >the phases transitions may occur on some of the LCP state transitions, >but at most some of the time. For example, on which transitions >in and out of OPENED is there a Phase transition? We're not talking about phases! The OPENED state is VERY WELL DEFINED, and you're trying to distract us with PHASES? When LCP is NOT OPENED, non-LCP packets ARE NOT PERMITTED! How many times do you have to hear it before it sinks in?? Even in RFC1134 (Nov. '89), the state machine clearly shows a transition OUT OF OPENED state whenever we send a Terminate-Request. So you want to take a standard that evolved over 6 1/2 years by concensus of this mailing list and others and say you know a better way? >In this case, does the Terminate Phase start on the transmission >of a Terminate-Request or the reception of the Terminate-Ack? It's obvious to anyone who doesn't have a broken implementation that the Terminate Phase starts when you send the Terminate-Request, and NOT when you receive the Terminate-Ack. >Except for the general no-NCP-out-of-Opened rule, you could >say the Terminate Phase must wait until the Terminate-Ack, since many >of the other phases start or end at an Ack, not sending a Request. I don't know anyone else who reads it that way. >A good case can be made that you are demanding a change in LCP, by >demanding a novel (to most of us) and legalistic interpretation of the >old words. Please enumerate "most of us", then divide that list by those that are working on Multilink, and those that aren't. I think you'll see a pattern there. >We all know that any standard is what implementations do more than what >any particular glob of words happens to claim. Reading a standard >through common-sense-colored glasses hardly qualifies as having "broken >PPP." Out here in the real world, we all know that absolutely all >standards documents are incorrect and imperfect, and that what matters >absolutely above any considersations of what the standard says is what >works. "Out here in the real world?" Are you implying that I'm not "out there" with you in the real world?? Well, I beg to differ. I have been making quite a decent living in the "real world" by licensing our PPP code to software vendors such as NEC and Simware. I am very much a part of the real world. I know that standards documents are not always perfect, but I also know that the PPP RFCs (up through 1661) have been editted and re-editted many times to come as close to a realistic spec as possible. There have been too many debates and too many man hours that have gone into RFC1661 for you to dismiss it as "just another draft spec that we don't have to conform to". >Instead of arguing that RFC 1661 is somehow devine, involiate writ that >cannot ever be changed, please say in concrete and practical terms how >and why a new protocol, a new packet type, or a new LCP >Configure-Request option is better than simply relaxing a restriction >that most of us knew better than to even realize existed. Well, Bill Simpson may not fully agree with your desire to just relax concepts of PPP that have been around for almost 7 years. The general concensus on this list has always been to stay away from changing things that work, and to put functionality WHERE IT BELONGS, and not on the backs of other things (especially LCP)! Patrick ============================================================================ 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 ietf-ppp-request@MERIT.EDU Thu Mar 14 01:39:23 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id BAA07102; Thu, 14 Mar 1996 01:39:23 -0500 (EST) Resent-Date: Thu, 14 Mar 1996 01:39:23 -0500 (EST) Date: Wed, 13 Mar 1996 23:38:33 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199603140638.XAA17628@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Resent-Message-ID: <"F_Adp2.0.ik1.AyxHn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU Subject: Unidentified subject! X-Mailing-List: archive/latest/1336 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Patrick Klos > Well, excuse me! There's tons of working code out there, but I haven't > heard one person say "I accept non-LCP packets after an LCP Terminate- > Request, and I don't do MultiLink", The Silicon Graphics PPP implementation was in the field before RFC 1717 was written, and I think it had this characteristic. So now you have heard one such person. I must admit that the only "good reason" (that you demanded later) for such a violation "of the rules" is the old "generous in what you accept" dogma. In my pre-MP code, it just worked out easiest (as well as more generous) to continue to accept data packets after receiving an Terminate-Request but to drop non-LCP-*CP packets. My code (mostly) deals with data packets in the kernel and *CP packets in the deamon. It's easy to turn on data at the right time and turn data off late, while being more crisp with LCP etc. > so this kludge you so fondly refer > to as "working code" is JUST a Multilink issue, and as such, should be > fixed by Multilink, NOT LCP! On the contrary. It should be fixed in the technically best place to fix it, regardless of what the documents currently say. Since fixing it by relaxing the LCP rule has, by your assertion, no effect except on MP implementations, non-MP implementations are irrelevant. Or by your reasoning, since all of MP is currently part of LCP, the problem should be fixed in LCP. > It's funny how you seem to defend the documents when convenient, and > working code when it's your code that diverges from the spec. Name a single case where I have advocated whatever the documents say instead of the best technical solution, consistent with minimizing changes to existing, interoperable implementations. > >> No. This breaks the state machine. Any non-LCP packet received while > >> LCP is not in the Opened state MUST be silently discarded! > > > >Please say how that "breaks the state machine." As I see understand > >the concept, a broken state machine must make a wrong transition or > >fail to make a necessary transition or execute a wrong action. > > The state machine is not just a state transition table, but the rules that > go along with that table. You've already agreed that non-LCP stuff > shouldn't happen when LCP is not Opened, and now you're backing down? Yes, of course, the state machine is not just the matrix. That's how we all understand the notion. What is the point? No, I'm not "backing down" on anything. I have said that non-LCP should not happen <> LCP is OPENED. After is something else. There are obvious practical reasons for such a mixed view. Accepting non-LCP packets early leads to problems (e.g. lack of authentication or wrong Endpoint Discriminator). Accepting dribble non-LCP packets does not. > >And "wrong" is defined only in concrete terms expressable in lost > >or corrupted or delayed data. That some documents somewhere are > >violated is absolutely irrelevant in the face of code that works > >better for having violated the documents. Or so the IETF still > >claims. > > I'll have to remember some of these arguments when you start pushing someone > around claiming bloat and unnecessary functionality when they want to add > something useful. Usually, if you don't personally have a use for something, > you call it excessive bloat and unnecessary. But when you like something, > even if it is non-standard, you don't stop till you get it! Who is pushing to get what around here? Many, probably most implementations have done things differently than your reading of RFC 1661. That (mis)reading produced working, interoperable MP and non-MP systems with less code than the alternatives you have (only!) implicitly suggested. A dislike of bloat is a good reason why RFC 1661 should be relaxed instead of adding more states or packet types elsewhere. As I see the obvious code, it's far cheaper to accept network packets after sending a Terminate-Request than to deal with new packet types. As for when I stop, well, I am guilty of persistance. And yes, I'm unconvinced of the need for BACP or PSCP, but that does not mean that I think people should not implement and try them. My guess (as a mostly client author) is that neither will get the required critical mass of client implementations, but let's wait and see. > ... > I thought what we cared about was INTEROPERABILITY! Independent developers > can only reach interoperability by following the same specs. That's what > makes things work! Not this ad hoc attitude of "mine's better, so screw > the spec!". Yes, we care only about working code and "INTEROPERABILITY!". We do say "screw the spec" if that produces a better result. What could be more "ad hoc" than "working code and rough concensus"? Please say what would break or be more bloated or less interoperable if we simply relax RFC 1661 to be consistent with the consensus. Since you evidently are not working on multilink, please say how you would be inconvenienced. You can continue to drop all packets except Terminate-Acks after sending a Terminate-Request. What is the problem?--other than your sense of esthetics and document turf? > ... > >Instead of arguing that RFC 1661 is somehow devine, involiate writ that > >cannot ever be changed, please say in concrete and practical terms how > >and why a new protocol, a new packet type, or a new LCP > >Configure-Request option is better than simply relaxing a restriction > >that most of us knew better than to even realize existed. > > Well, Bill Simpson may not fully agree with your desire to just relax > concepts of PPP that have been around for almost 7 years. You seem to be under the mistaken impression that Mr. Simpson was the author of the LCP protocol, an early implementor, or the most important contributor. He was none of those, although he has been a major contributor. Even if he were all of those, his opinion would count for no more than yours or mine. Arguments by appeal to human authority are as subservient to working code and rough concensus as appeals to the authority of documents. Sheesh! As someone on the PPP mailing list since before it was formed by the forced marriage of the two working groups, if you appeal to authority based on seniority, you might find yourself appealing to me. > The general > concensus on this list has always been to stay away from changing things > that work, and to put functionality WHERE IT BELONGS, and not on the backs > of other things (especially LCP)! > ... The only demand to put anything on any back or to change things that work is your insistance that everyone else change their code. What is the big deal? What would be broken? Since you evidently are not working on MP and seem to agree it is a non-issue without MP, why do you care? If you are working on MP, what is your concrete alternative to dealing with the problem, minor as you agree that it is? Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Mar 14 03:20:17 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id DAA10314; Thu, 14 Mar 1996 03:20:17 -0500 (EST) Resent-Date: Thu, 14 Mar 1996 03:20:17 -0500 (EST) Date: Thu, 14 Mar 96 08:15:39 GMT From: georgew@spider.co.uk (George Wilkie) Message-Id: <9603140815.AA21927@queenbee.spider.co.uk> X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: ietf-ppp@MERIT.EDU Subject: BACP draft 02 comments Resent-Message-ID: <"4F-r43.0.uW2.uQzHn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1337 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU The action taken following receipt of a Link-Drop-Query-Response is inconsistent: P4, sec 4.1, para 3 says "should then issue an LCP Terminate-Request" whereas P11, sec 4.5.5 says "MUST initiate tear down". I prefer "SHOULD" as this allows an implementation the flexibility to change its mind based on up-to-date transmit knowledge. I think Race Conditions needs more clarification (P7, sec 4.4). According to RFC 1717 sec 5.1.3, the endpoint discriminator and authenication are both optional. How about modifing so that endpoint discriminators are compared if usernames are equal OR remote username not known and if endpoint discriminators are equal (is this possible?) OR not known then favour the system which made the call to add the first link to the bundle. P9 "Identifier". I find the text "as well as which links are added or removed" confusing. Remove it. P12 Call-Status-Indication and Response. I don't think these are necessary to fulfil the protocol's goals. Remove them or make transmission of Call-Status-Indication optional (as is transmission of Link-Drop-Query-Request). P14 "Link Type" Perhaps this should be clarified with "at least one bit MUST be set". P16 "Phone Number Sub-Options". Both the Unique Digits and Subscriber Number are "required". Only the sub address is optional. How about simplifying Phone-Number option to contain: Type | Length | Unique Digits | Subscriber Length | Subscriber Number | Sub Length | Sub Address - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Mar 14 10:19:18 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id KAA19478; Thu, 14 Mar 1996 10:19:18 -0500 (EST) Resent-Date: Thu, 14 Mar 1996 10:19:18 -0500 (EST) Message-Id: <9603141519.AA8037@hqsmtp.ops.3com.com> To: Patrick Klos Cc: ietf-ppp , vjs From: Daniel Brennan/US/3Com Date: 14 Mar 96 10:04:35 EDT Subject: Re: edge condition for PPP Multilink/BACP Mime-Version: 1.0 Content-Type: Text/Plain Resent-Message-ID: <"CgJrA.0.hl4.XY3In"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1338 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >Exactly! So why fix LCP when it aint broke?? If someone REALLY REALLY >wants to not drop packets when shutting down a link, then they should >address the issue in Multi-Link, NOT LCP! > >Patrick We're not fixing it because it is not broken! We're just being flexible. Dan - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Mar 14 12:50:19 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id MAA25197; Thu, 14 Mar 1996 12:50:19 -0500 (EST) Resent-Date: Thu, 14 Mar 1996 12:50:19 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; cc: ietf-ppp@MERIT.EDU From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-pppext-snacp-01.txt Date: Thu, 14 Mar 96 10:29:07 -0500 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9603141029.aa16379@IETF.CNRI.Reston.VA.US> Resent-Message-ID: <"c7QRb2.0.G76.zm5In"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1339 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --NextPart A Revised 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 : The PPP SNA Control Protocol (SNACP) Author(s) : A. Fuqua Filename : draft-ietf-pppext-snacp-01.txt Pages : 8 Date : 03/13/1996 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols for establishing and configuring different network-layer protocols. This document defines the Network Control Protocols for establishing and configuring Systems Network Architecture (SNA) over PPP and SNA over LLC 802.2 over PPP. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-snacp-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-snacp-01.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (193.205.245.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) 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-snacp-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. For questions, please mail to Internet-Drafts@cnri.reston.va.us. 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: <19960313141106.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-snacp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-snacp-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960313141106.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Mar 14 13:34:21 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id NAA26978; Thu, 14 Mar 1996 13:34:21 -0500 (EST) Resent-Date: Thu, 14 Mar 1996 13:34:21 -0500 (EST) From: Rob Friend To: IETF-PPP Subject: LCP Configure Request Date: Thu, 14 Mar 96 10:31:00 PST Message-Id: <31486692@smtpgateway.stac.com> Encoding: 42 TEXT X-Mailer: Microsoft Mail V3.0 Resent-Message-ID: <"BA8RW.0.Cb6.XQ6In"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1340 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU There seems to be some confusion regarding whether configuration request options specify how the sender wants its transmitter configured, or how the sender wants its receiver configured. On page 39, Section 6 of rfc1661, "LCP Configuration Options", the 4th paragraph says: 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. Is this paragraph saying that the sender of the configuration request is stating what he wants to receive or what he wants to transmit? This paragraph has been taken from Dave Rand's CCP Draft. Configuration Options, in this protocol, indicate algorithms that the receiver is willing or able to use to decompress data sent by the sender. As a result, it is to be expected that systems will offer to accept several algorithms, and negotiate a single one that will be used. Is this paragraph from CCP to reinforcing the paragraph from PPP? That is, is this paragraph saying that the sender of a configuration request is configuring his receiver or his transmitter? Right now we have a disagreement among (LZS) CCP implementors as to whether the configuration request is configuring the transmitter or receiver. I must believe that this issue is with all LCP configuration requests, not just for compresssion. What are people implementing? Specifically, how are people implementing CCP options 17 and 23? There must be a "standard" way to negotiate? Please respond. Thanks, Robert C. Friend Stac Electronics Applications Engineering 12636 High Bluff Dr (619)794-4542 (voice) San Diego, CA 92130 (619)794-4577 (FAX) Email:rfriend@stac.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Mar 14 13:47:59 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id NAA27706; Thu, 14 Mar 1996 13:47:59 -0500 (EST) Resent-Date: Thu, 14 Mar 1996 13:47:59 -0500 (EST) Message-Id: <9603141846.AA07747@azure.rns.com> X-Sender: ken@azure.rns.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 14 Mar 1996 10:45:11 -0800 To: ietf-ppp@MERIT.EDU From: ken@RNS.COM (Ken Mueller) Subject: Re: Don't change LCP! X-Mailer: Resent-Message-ID: <"xPZuH3.0.6m6.Kc6In"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1341 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >>> Just because MP was originally designed to piggy back LCP doesn't mean that >>> now LCP must bear the brunt of any shortcomings that MP might have caused! >>> I don't recall why MP was piggy backed in the first place, rather than >>> negotiated as a seperate control protocol, but that point is moot right >>> now. >> >>You have an different notion of what is fundamental, at least outside >>of outfits like the OSI (no insult to you or the OSI intended; just a >>statement of fact; different strokes and all that). Around here, we >>claim to modify the documents to reflect the "working code", instead of >>the other way around. > >Well, excuse me! There's tons of working code out there, but I haven't >heard one person say "I accept non-LCP packets after an LCP Terminate- >Request, and I don't do MultiLink", so this kludge you so fondly refer >to as "working code" is JUST a Multilink issue, and as such, should be >fixed by Multilink, NOT LCP! > most people haven't said anything because they have better things to do than waste their time discussing a non-issue. our implementation accepts non-lcp packets until the term-ack comes in. why shouldn't it? it doesn't affect interoperability with other implementation one iota. and it has the advantage of not unnecessarily throwing away data. this is a big plus for paying customers! >It's funny how you seem to defend the documents when convenient, and >working code when it's your code that diverges from the spec. > the idea of specs are to foster interoperability. in no way does accepting non-lcp packets after sending a term-req affect interoperability. most of us are paid to use our brains to make better products, not to blindly follow our interpretation of a spec. >>> No. This breaks the state machine. Any non-LCP packet received while >>> LCP is not in the Opened state MUST be silently discarded! >> >>Please say how that "breaks the state machine." As I see understand >>the concept, a broken state machine must make a wrong transition or >>fail to make a necessary transition or execute a wrong action. > >The state machine is not just a state transition table, but the rules that >go along with that table. You've already agreed that non-LCP stuff >shouldn't happen when LCP is not Opened, and now you're backing down? > so what, if interoperabillity is unaffected, who cares. there are no ietf police and even if there were, they would not be able to tell if an implementation is accepting NCP packets after sending a term-req. >>And "wrong" is defined only in concrete terms expressable in lost >>or corrupted or delayed data. That some documents somewhere are >>violated is absolutely irrelevant in the face of code that works >>better for having violated the documents. Or so the IETF still >>claims. > >I'll have to remember some of these arguments when you start pushing someone >around claiming bloat and unnecessary functionality when they want to add >something useful. Usually, if you don't personally have a use for something, >you call it excessive bloat and unnecessary. But when you like something, >even if it is non-standard, you don't stop till you get it! > i agree with vernon here. we have a perfectly good solution now for dealing with the exit of links from a bundle without losing data. why invent another method? >>> I disagree. No network traffic should occur unless LCP is Opened. >> >>No network traffic should occur until LCP has been OPENED, for obvious >>reasons. What happens after LCP has been OPENED is a different issue. > >Oh, now we have to add a state to the state machine, call "WAS OPENED"?!? >Please! Stop mincing words. Put me in touch with ONE PERSON who's not >doing Multilink, but explicitly allows non-LCP packets after sending an >LCP Terminate-Request for some good reason. > it's unimportant whether they are allowing it or not. interoperability is unaffected. lots more of this deleted ... please, let's not waste anymore bandwidth on such a non-issue. there are enough real things going on in PPP than to spend time on this! >Patrick >============================================================================ > 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/ >============================================================================ > > ken - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Mar 14 13:50:40 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id NAA28051; Thu, 14 Mar 1996 13:50:40 -0500 (EST) Resent-Date: Thu, 14 Mar 1996 13:50:40 -0500 (EST) Date: Thu, 14 Mar 96 12:45:47 CST Message-Id: <9603141845.AA14021@adtrn-ws01.adtran.com> X-Sender: kfrnswrt@mail Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Rob Friend From: kfarnsworth@adtran.com (Kyle Farnsworth) Subject: Re: LCP Configure Request Cc: ietf-ppp@MERIT.EDU X-Mailer: Resent-Message-ID: <"23fpl.0.up6.of6In"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1342 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >Is this paragraph saying that the sender of the configuration request is >stating what he wants to receive or what he wants to transmit? > What he wants to receive. >This paragraph has been taken from Dave Rand's CCP Draft. > > Configuration Options, in this protocol, indicate algorithms that the > receiver is willing or able to use to decompress data sent by the > sender. As a result, it is to be expected that systems will offer to > accept several algorithms, and negotiate a single one that will be > used. > >Is this paragraph from CCP to reinforcing the paragraph from PPP? That is, >is this paragraph saying that the sender of a configuration request is >configuring his receiver or his transmitter? > That paragraph is correctly stated. The sender of the conf-req is sending options for configuring his receiver. -------------------------------------------------------- Kyle Farnsworth ADTRAN Inc. (205)971-8583 kfarnsworth@adtran.com -------------------------------------------------------- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Mar 14 13:55:28 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id NAA28453; Thu, 14 Mar 1996 13:55:28 -0500 (EST) Resent-Date: Thu, 14 Mar 1996 13:55:28 -0500 (EST) From: Karl Fox Date: Thu, 14 Mar 96 13:54:43 -0500 Message-Id: <9603141854.AA04389@gefilte.MorningStar.Com> To: Rob Friend Cc: IETF-PPP Subject: LCP Configure Request In-Reply-To: <31486692@smtpgateway.stac.com> References: <31486692@smtpgateway.stac.com> Reply-To: Karl Fox Organization: Morning Star Technologies, Inc. Resent-Message-ID: <"D5PPi1.0.Hy6.Rk6In"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1343 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Rob Friend writes: > On page 39, Section 6 of rfc1661, "LCP Configuration Options", the 4th > paragraph says: > > 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. > > Is this paragraph saying that the sender of the configuration request is > stating what he wants to receive or what he wants to transmit? The Configuration-Request defines what the sender of the Configuration-Request is willing to receive. > This paragraph has been taken from Dave Rand's CCP Draft. > > Configuration Options, in this protocol, indicate algorithms that the > receiver is willing or able to use to decompress data sent by the > sender. As a result, it is to be expected that systems will offer to > accept several algorithms, and negotiate a single one that will be > used. > > Is this paragraph from CCP to reinforcing the paragraph from PPP? Yes, they agree. > That is, is this paragraph saying that the sender of a configuration > request is configuring his receiver or his transmitter? His receiver. > Right now we have a disagreement among (LZS) CCP implementors as to whether > the configuration request is configuring the transmitter or receiver. I > must believe that this issue is with all LCP configuration requests, not > just for compresssion. You are correct; RFC 1661 says this generally applies to all Configure-Requests. It shouldn't be too painful for those who misunderstood to deal with, however, since I'd think conflicts don't usually arise. The vast majority of CCP connections I see are symmetrical, thus avoiding (and masking) the problem. -- Karl Fox, servant of God, employee of Morning Star Technologies 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 451 1883 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Mar 14 14:44:21 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id OAA00760; Thu, 14 Mar 1996 14:44:21 -0500 (EST) Resent-Date: Thu, 14 Mar 1996 14:44:21 -0500 (EST) From: Bill Miskovetz Message-Id: <199603141943.LAA17924@stilton.cisco.com> Subject: Re: LCP Configure Request To: karl@morningstar.com Date: Thu, 14 Mar 96 11:43:25 PST Cc: RFRIEND@stac.com, ietf-ppp@MERIT.EDU In-Reply-To: <9603141854.AA04389@gefilte.MorningStar.Com>; from "Karl Fox" at Mar 14, 96 1:54 pm X-Mailer: ELM [version 2.3 PL11] Resent-Message-ID: <"tAZhF1.0.EB.AS7In"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1344 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > > Rob Friend writes: > > On page 39, Section 6 of rfc1661, "LCP Configuration Options", the 4th > > paragraph says: > > > > 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. > > > > Is this paragraph saying that the sender of the configuration request is > > stating what he wants to receive or what he wants to transmit? > > The Configuration-Request defines what the sender of the > Configuration-Request is willing to receive. How does one then negotiate a link, where I want to send compressed packets, but the other side does not want to send them, but is willing to receive them? It means that the side that is willing to receive, but not transmit compressed data must include the option in their config request? > > > This paragraph has been taken from Dave Rand's CCP Draft. > > > > Configuration Options, in this protocol, indicate algorithms that the > > receiver is willing or able to use to decompress data sent by the > > sender. As a result, it is to be expected that systems will offer to > > accept several algorithms, and negotiate a single one that will be > > used. > > > > Is this paragraph from CCP to reinforcing the paragraph from PPP? > > Yes, they agree. The above paragraph is very vague. Where it says 'receiver' is it talking about the receiver of data packets (compressed in this case), or the receiver of a config request? It really could be written much clearer. > > > That is, is this paragraph saying that the sender of a configuration > > request is configuring his receiver or his transmitter? > > His receiver. Seems like it should then state that the sender of the config request is indicating the algorithms they are capable of receiving. It makes no statement that they will transmit compressed packets, or the format that those compressed packets may be in. > > > Right now we have a disagreement among (LZS) CCP implementors as to whether > > the configuration request is configuring the transmitter or receiver. I > > must believe that this issue is with all LCP configuration requests, not > > just for compresssion. > > You are correct; RFC 1661 says this generally applies to all > Configure-Requests. It shouldn't be too painful for those who > misunderstood to deal with, however, since I'd think conflicts don't > usually arise. The vast majority of CCP connections I see are > symmetrical, thus avoiding (and masking) the problem. Unfortunately, with something like compression, it is easier to receive than to give sometimes, just because to give may require a lot of CPU... > -- > Karl Fox, servant of God, employee of Morning Star Technologies > 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 451 1883 > > - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Mar 14 15:16:17 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id PAA02248; Thu, 14 Mar 1996 15:16:17 -0500 (EST) Resent-Date: Thu, 14 Mar 1996 15:16:17 -0500 (EST) From: Karl Fox Date: Thu, 14 Mar 96 15:15:33 -0500 Message-Id: <9603142015.AA06460@gefilte.MorningStar.Com> To: Bill Miskovetz Cc: RFRIEND@stac.com, ietf-ppp@MERIT.EDU Subject: Re: LCP Configure Request In-Reply-To: <199603141943.LAA17924@stilton.cisco.com> References: <9603141854.AA04389@gefilte.MorningStar.Com> <199603141943.LAA17924@stilton.cisco.com> Reply-To: Karl Fox Organization: Morning Star Technologies, Inc. Resent-Message-ID: <"ouRX_3.0.sY.Cw7In"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1345 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Bill Miskovetz writes: > How does one then negotiate a link, where I want to send compressed > packets, but the other side does not want to send them, but is > willing to receive them? It means that the side that is willing to > receive, but not transmit compressed data must include the option in > their config request? Correct. > > > This paragraph has been taken from Dave Rand's CCP Draft. > > > > > > Configuration Options, in this protocol, indicate algorithms that the > > > receiver is willing or able to use to decompress data sent by the > > > sender. As a result, it is to be expected that systems will offer to > > > accept several algorithms, and negotiate a single one that will be > > > used. > > > > > > Is this paragraph from CCP to reinforcing the paragraph from PPP? > > > > Yes, they agree. > > The above paragraph is very vague. Where it says 'receiver' is it talking > about the receiver of data packets (compressed in this case), or the > receiver of a config request? It really could be written much clearer. Hmm, I see your point. Yes, it should be rewritten to be unambiguous. > > > That is, is this paragraph saying that the sender of a configuration > > > request is configuring his receiver or his transmitter? > > > > His receiver. > > Seems like it should then state that the sender of the config request is > indicating the algorithms they are capable of receiving. It makes no > statement that they will transmit compressed packets, or the format that > those compressed packets may be in. Correct. > Unfortunately, with something like compression, it is easier to receive > than to give sometimes, just because to give may require a lot of CPU... That's also correct. As far as I'm aware, however, you're under no obligation to Ack the request or even to compress packets if you do Ack send a Configure-Ack. -- Karl Fox, servant of God, employee of Morning Star Technologies 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 451 1883 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Mar 14 15:30:18 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id PAA03067; Thu, 14 Mar 1996 15:30:18 -0500 (EST) Resent-Date: Thu, 14 Mar 1996 15:30:18 -0500 (EST) From: Scott Jackson Message-Id: <199603142029.MAA10067@puli.cisco.com> Subject: Re: BACP draft 02 comments To: ietf-ppp@MERIT.EDU Date: Thu, 14 Mar 1996 12:29:05 -0800 (PST) In-Reply-To: <9603140815.AA21927@queenbee.spider.co.uk> from "George Wilkie" at Mar 14, 96 08:15:39 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"D30D_3.0.fl.K78In"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1346 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU George Wilkie [georgew@spider.co.uk]: > The action taken following receipt of a Link-Drop-Query-Response is > inconsistent: P4, sec 4.1, para 3 says "should then issue an LCP > Terminate-Request" whereas P11, sec 4.5.5 says "MUST initiate tear down". > I prefer "SHOULD" as this allows an implementation the flexibility to change > its mind based on up-to-date transmit knowledge. If an implementation decides to opt out of dropping a link after agreement with it's peer, then a notification should be sent to inform the peer of the action taken, and possibly the reason. > P12 Call-Status-Indication and Response. > I don't think these are necessary to fulfil the protocol's goals. > Remove them or make transmission of Call-Status-Indication optional With respect to the above, one could change the Call-Status-Indication to a Link-Status-Indication which is only required to be sent upon a call failure (as previously) or the opting out of an agreed link drop. The transmission of the Call-Status-Indication for a successful addition of a link to a bundle is somewhat redundant given that the link should already be part of the bundle (assuming that the link added has been negotiated through the use of BAP). > I think Race Conditions needs more clarification (P7, sec 4.4). > According to RFC 1717 sec 5.1.3, the endpoint discriminator and authenication > are both optional. How about modifing so that endpoint discriminators > are compared if usernames are equal OR remote username not known > and if endpoint discriminators are equal (is this possible?) OR not known > then favour the system which made the call to add the first link to the bundle. Now that the Link-Discriminator is mandatory it can also be used to determine the favoured system, since each implementation negotiates independent values. > P16 "Phone Number Sub-Options". Does the Subscriber Number also contain the digits that would be used in conjunction with the "original phone number dialed" - a comment should indicate this, should that be the case. Also, there is no requirement that an implementation have knowledge of an "original phone number dialed". There could possibly be a situation whereby a Callback-Request is transmitted to a peer containing unique digits only for an implementation not to have a previously dialed number to use. Also, if the Subscriber Number contains the National Destination and Country Codes, how are they distinguishable from the rest of the ASCII string? Scott sjackson@cisco.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Mar 14 19:28:40 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id TAA10276; Thu, 14 Mar 1996 19:28:40 -0500 (EST) Resent-Date: Thu, 14 Mar 1996 19:28:40 -0500 (EST) Message-Id: From: dlr@daver.bungi.com (Dave Rand) Date: Thu, 14 Mar 1996 12:17:25 PST In-Reply-To: Bill Miskovetz's message on Mar 14, 11:43. X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: Bill Miskovetz Subject: Re: LCP Configure Request Sender: misko@cisco.com Resent-Message-ID: <"Ez6za3.0.IW2.lcBIn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1347 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU [In the message entitled "Re: LCP Configure Request" on Mar 14, 11:43, Bill Miskovetz writes:] > > > > > > The Configuration-Request defines what the sender of the > > Configuration-Request is willing to receive. > > How does one then negotiate a link, where I want to send compressed packets, > but the other side does not want to send them, but is willing to receive them? > It means that the side that is willing to receive, but not transmit compressed > data must include the option in their config request? You have no ability, whatsoever, to do *anything* with the 'sending' side. You can only control yourself - which means that if you want to receive compressed packets, you must indicate the protocols that you are willing to decompress. If the remote site does not support your algorithm(s), then you don't open compressed. Conversly, you REJ all the options that the remote offers you, if you don't want to compress. > > > > > > This paragraph has been taken from Dave Rand's CCP Draft. > > > > > > Configuration Options, in this protocol, indicate algorithms that the > > > receiver is willing or able to use to decompress data sent by the > > > sender. As a result, it is to be expected that systems will offer to > > > accept several algorithms, and negotiate a single one that will be > > > used. > > > > > > Is this paragraph from CCP to reinforcing the paragraph from PPP? > > > > Yes, they agree. > > The above paragraph is very vague. Where it says 'receiver' is it talking > about the receiver of data packets (compressed in this case), or the > receiver of a config request? It really could be written much clearer. Sorry. We went through this multiple times a couple of years ago. I think it is pretty clear - the side sending the configuration options indicates its desire to *DECOMPRESS* data sent by the sender. If you have better text that you feel removes more abiguity, please let me know... > > > > > > That is, is this paragraph saying that the sender of a configuration > > > request is configuring his receiver or his transmitter? > > > > His receiver. > > Seems like it should then state that the sender of the config request is > indicating the algorithms they are capable of receiving. It makes no > statement that they will transmit compressed packets, or the format that > those compressed packets may be in. Correct - and that's exactly what the previous ccp-quoted paragraph explains. > > Unfortunately, with something like compression, it is easier to receive > than to give sometimes, just because to give may require a lot of CPU... > Correct, which is why we let the sender (compressor) pick which of the algorithms *he* wants to use - the receiver (decompressor) indicates his *willingness* to decompress the algorithms stated. If it were done in the reverse direction, it would be possible for the receiver to pick a very aggressive algorithm that would be 'hard' for the sender to deal with... I think it is done correctly! -- Dave Rand Internet: dlr@daver.bungi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Mar 15 01:31:29 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id BAA19029; Fri, 15 Mar 1996 01:31:29 -0500 (EST) Resent-Date: Fri, 15 Mar 1996 01:31:29 -0500 (EST) Message-Id: <9603141519.AA8072@hqsmtp.ops.3com.com> To: Patrick Klos Cc: Daniel_Brennan , vjs , ietf-ppp From: Daniel Brennan/US/3Com Date: 14 Mar 96 9:58:31 EDT Subject: Re: edge condition for PPP Multilink/BACP Mime-Version: 1.0 Content-Type: Text/Plain Resent-Message-ID: <"Vtuyz1.0.-e4.swGIn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1348 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >I'm sorry, Dan, but I don't agree. Both the state machine and the RFC >specifically indicate that non-LCP packets are NOT to be processed when LCP is >not in the Opened state (i.e. after the Terminate-Request is sent). This is >the way it's been for several years now! You don't just go change something >at such a BASIC LEVEL because it'll make Multi-Link a little better. I agree it is a protocol violation according to the RFC. However, implementors of MP have observed that the added flexibility improves performance slightly. Following the RFC strictly can (and usually does) cause dropped MP fragments. We have just bent the rules slightly by accepting additional frames on the link. I'm sure those of us who do this allow frames as long as the channel is up. >I don't agree with changing the fundamentals of LCP. >Patrick Once again, we are not changing the fundamentals of LCP. It is up to the implementor. We *MAY* (no *MUST* here) change LCP by replacing the *MUST* to *MAY* or *SHOULD* (IETFese), but it is not necessary. Who cares if I decide to continue to receive frames! It shouldn't affect the peer's implementation. Dan - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Mar 15 05:08:35 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id FAA28209; Fri, 15 Mar 1996 05:08:35 -0500 (EST) Resent-Date: Fri, 15 Mar 1996 05:08:35 -0500 (EST) Sender: okorf@netcs.com Message-Id: <31494268.2AD@netcs.com> Date: Fri, 15 Mar 1996 11:11:52 +0100 From: Oliver Korfmacher Organization: NetCS Informationstechnik GmbH X-Mailer: Mozilla 2.0 (X11; I; SunOS 5.5 sun4m) Mime-Version: 1.0 To: ietf-ppp@MERIT.EDU Subject: E.164 & BAP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"o9GJy2.0.Vu6.R6KIn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1349 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU page 16, "Phone Number" Please please add the E.164 format as an option for the phone number. It exactly renders the (georgew@spider.co.uk (George Wilkie)) requirement: > P16 "Phone Number Sub-Options". > Both the Unique Digits and Subscriber Number are "required". Only the > sub address is optional. > How about simplifying Phone-Number option to contain: > > Type | Length | Unique Digits | Subscriber Length | Subscriber Number >| Sub Length | Sub Address ie lets define a string "+countrycode.areacode.subscribernumber[-ext]" eg "+1.708/1235234" "+49.6021/3095-77" Every peer can simply calculate the number it has to dial locally, using only locally known & significant PBX prefixes, national/international needed escapes and so on. For advanced needs, a regexp variant (with ?,*,[range]) may be appropriate. Gruesse, Oliver Korfmacher (okorf@netcs.com, whois OK11 URL: http://www.netcs.com/PEOPLE/okorf.html) - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Mar 15 06:28:12 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id GAA29854; Fri, 15 Mar 1996 06:28:12 -0500 (EST) Resent-Date: Fri, 15 Mar 1996 06:28:12 -0500 (EST) Message-ID: <01BB1262.ED6784E0@romulus.knx.co.uk> From: IAN PULESTON To: "'Vernon Schryver'" Cc: "'IETF PPP Mailing List'" Subject: =?iso-8859-1?Q?RE=3A_=01=05RE=3A_Comments_on_PSCP_draft_=2DRep?= =?iso-8859-1?Q?ly?= Date: Fri, 15 Mar 1996 11:31:16 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Resent-Message-ID: <"f6kP31.0.7I7.gGLIn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1350 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Vernon Schryver wrote: > OK, that sounds reasonable. But why is all of this needed? Is it > something distinctive about IPX? There are many, very mature commercial > implementations of fully demand-dialing, bandwidth-on-demand, RFC 1717 > multilink PPP in the field. They seem to work fine without PCSP. > Consider my personal installation. It is a symmetric demand-dialing > PPP link (i.e. either peer calls as traffic dictates). On both sides > of the link are more than one IP network. Hosts on either side use > RIP, RIPv2, OSPF, IGRP, and BGP4 and do not know that this particular > link is special, other than it is slow all of the time and incredibly > slow some of the time (when it must be restored). As a user, what > would I get from all of this? I don't use IPX; is there something > about IP that avoids problem seen with IPX and demand-dialing? > The Silicon Graphics demand-dialing scheme leaves the UNIX "network > interface" alive, but lets the IP NCP(s) come and go as necessary. It > relies on common sense to ensure that when the NCP is re-instantiated, > it is sufficiently similar to the previous incarnation (and sanity > checks just in case). There is nothing in LCP or IPCP that needs to be > the same from instantiation to instantiation except the IP addresses, > the MTUs, and whether RFC 1717 MP is allowed. Everything else can change. OK, so you personally may be able to live without spoofing. That is not an argument against going ahead with it. I don't know anything about your upper-layer protocols, but you appear to live in a TCP/IP environment, which is generally the "easy" end of the spectrum for demand-dialled LAN access. The other (difficult) end of the spectrum is Novell IPX. IPX transfers "keep alive" messages between the server and clients about every 30 seconds. This means that any demand-dialled link will be permanently connected (hence expensive) unless the IPX keep alives can be spoofed. Also, if the call cannot be made (like if all channels at the other end are busy) then IPX doesn't usually end the login-session gracefully. It usually hangs up the PC, which then needs re-booting. Take a look at my personal installation, for instance. We work on PCs running MS Windows, and my company has a mix of Novell File Servers and Windows NT servers. I sometimes work at home, dialing in over ISDN and using IPX to access the Novell Servers, NetBIOS to access the NT servers or other PCs, and TCP/IP to access the Internet. I generally keep a logical connection up all day, with a physical ISDN call being made automatically as and when required. We need IPX spoofing for the reasons outlined above. If I access any of the Microsoft PCs then NetBIOS starts polling the Microsoft network about once a minute, so we also need to spoof the NetBIOS messages. We also have Novell File Servers at an office in Australia, and these appear to be permanently connected to our local network in the UK, hence anyone can access them by simply clicking an Icon on the Windows network. In fact, they are not physically connected, and an access server is spoofing the Novell RIPs and SAPs 24-hours a day, 7 days a week while they are not being accessed. Image the phone bill for the calls to Australia if the RIPs and SAPs were not being spoofed ! I don't need spoofing to access the Internet. However, we have an account with the PSI Internet provider in the USA, and they use automatic IP address allocation via IPCP. This means that I cannot us a demand-dialed connection to the Internet via PSI because each time I re-connect they would give me a different IP address. The concept of "suspending" a call introduced by PSCP would solve this. I would suggest that the mix of protocols which I use is probably more the norm nowadays than your pure TCP/IP based installation. > The greatest defect in PPP in general is its bloat and general > complexity. Will BACP and PSCP contribute enough to justify their cost > in complexity? Various vendors have put a considerable amount of time, effort and money into developing BACP, and the same goes for the various proprietary spoofing systems which currently exist. They have done so because there is sufficient justification for it (i.e. there are customers out there who want - and are willing to pay for - these things). ========================================== Ian Puleston, Global Village Communication (UK) Ltd. ian_puleston@globalvillage.co.uk ========================================== - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Mar 15 10:21:06 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id KAA05750; Fri, 15 Mar 1996 10:21:06 -0500 (EST) Resent-Date: Fri, 15 Mar 1996 10:21:06 -0500 (EST) Date: Fri, 15 Mar 1996 08:20:21 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199603151520.IAA21975@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Re: comments_on_PSCP_draft_ Resent-Message-ID: <"xcavr.0.aP1.RhOIn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU Subject: Unidentified subject! X-Mailing-List: archive/latest/1351 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: IAN PULESTON > Subject: =?iso-8859-1?Q?RE=3A_=01=05RE=3A_Comments_on_PSCP_draft_=2DRep?= (that's an unusual Subject: line.) > OK, so you personally may be able to live without spoofing. No. I use IP RIP spoofing, but I don't need a PPP protocol to control it. > That is not an > argument against going ahead with it. I don't know anything about your > upper-layer protocols, but you appear to live in a TCP/IP environment, which > is generally the "easy" end of the spectrum for demand-dialled LAN access. Understood. > The other (difficult) end of the spectrum is Novell IPX. IPX transfers "keep alive" > messages between the server and clients about every 30 seconds. This means > that any demand-dialled link will be permanently connected (hence expensive) > unless the IPX keep alives can be spoofed. Also, if the call cannot be made > (like if all channels at the other end are busy) then IPX doesn't usually end the > login-session gracefully. It usually hangs up the PC, which then needs re-booting. So I've recently been told. But aren't there many commercial IPX/PPP implementations that support NCP, SAP, and IPX RIP spoofing without support from PPP? > Take a look at my personal installation ... > We need IPX spoofing for the reasons outlined above. If I access any of the > Microsoft PCs then NetBIOS starts polling the Microsoft network about once > a minute, so we also need to spoof the NetBIOS messages. > ... Doesn't Microsoft support NetBIOS demand dialing for their many employees? Without PSCP? > ... Image the phone bill for the calls to Australia if the RIPs and SAPs > were not being spoofed ! Yes, but aren't there current commerical PPP products that spoof IPX? Are they lame? > I don't need spoofing to access the Internet. However, we have an account with > the PSI Internet provider in the USA, and they use automatic IP address > allocation via IPCP. This means that I cannot us a demand-dialed connection > to the Internet via PSI because each time I re-connect they would give me a > different IP address. The concept of "suspending" a call introduced by PSCP > would solve this. Not so. No Internet Provider will use PSCP to restore IP links with dynamically assigned IP addresses. Even if it did make sense for PSI to let you use your old IP addresse, PSCP is irrelevant. IPCP works just fine for such things. It is easy to use IPCP to suggest IP addresses, but let the peer have its way. Your client could suggest to PSI the IP address it used before. Second, the only reason any Internet Provider uses dynamic IP addressing is because they have more clients than IP addresses. The only way PSCP can allow a suspended IP call is if the IP address is never used by some other customer while the call is suspended. If the IP address is transiently used by some other client of the ISP and then reused by the original customer, then it is likely that the other client will have sent RST's in response to things like TCP keepalives, killing the first client's TCP sessions and making it a waste of time for the all concerned to restore the connection. If the Internet Provider has so many IP addresses or so few customers that it never uses a single IP address with more than one customer, then it does not need PSCP to restore the old IP address. > I would suggest that the mix of protocols which I use is probably more the > norm nowadays than your pure TCP/IP based installation. In private networks, perhaps, but judging from what I can see, most PPP installations are now pure IP from personal computers (Mac's and IBM) to Internet Service Providers, and they don't need even as little spoofing as I use, and so need no control for spoofing. Of course, that implies little about the need for PSCP; it could still be important for IPX installations. > Various vendors have put a considerable amount of time, effort and money into > developing BACP, and the same goes for the various proprietary spoofing > systems which currently exist. They have done so because there is sufficient > justification for it (i.e. there are customers out there who want - and are willing > to pay for - these things). I have never heard a customer ask for something like PSCP. Still, for the little I know of IPX and NetBIOS, the commercially available spoofing implementations could be very lame because IPX or NetBIOS spoofing is much harder than IP spoofing, and so PSCP is needed for IPX or NetBIOS spoofing. I don't know. As far as I can see, there has been little effort put into BACP yet outside 3 or 4 organizations. I don't mean to denigrate the efforts of those people working on it, but it is important to be honest and realistic, to not confuse expressions of interest and sales organization efforts with what the IETF should consider effort. I have heard end-user demand for BACP, but it has all been repetitions of entirely false and bogus claims from sales organizations that bandwidth on demand is impossible without MPPP/MP+/BACP. Separately, there is clearly ISDN server customer (e.g. Internet Providers) demand and need for something to solve the problems of having more than one box in a telephone number hunt group. For both PSCP and BACP, I recall hearing expressions of implementor interest almost solely from PPP server vendors. Unless server vendors convince enough of the client implmentors (including freeware) to implement, the protocols will be used only between servers. There is a substantial market for such server-to-server installations (e.g. connecting company networks), but the enormous size of the personal computer-to-server market means that server vendors will also have to solve the problems that PSCP and BACP hope to solve, but without PSCP or BACP, unless you get enough client implementations. Except possibly for PSCP and IPX, the problems that BACP solve can be solved purely in servers. That has obvious and important implications. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Mar 15 11:28:31 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id LAA07991; Fri, 15 Mar 1996 11:28:31 -0500 (EST) Resent-Date: Fri, 15 Mar 1996 11:28:31 -0500 (EST) Date: Fri, 15 Mar 1996 08:22:26 -0800 (PST) From: Erik Olson Cc: ietf-ppp@MERIT.EDU Subject: Re-assignment of IP addresses, PSCP In-Reply-To: <199603151520.IAA21975@mica.denver.sgi.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"k9KMu3.0.Yy1.agPIn"@merit.edu> To: ietf-ppp@MERIT.EDU Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1352 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU On Fri, 15 Mar 1996, Vernon Schryver wrote: > > From: IAN PULESTON > > > I don't need spoofing to access the Internet. However, we have an account with > > the PSI Internet provider in the USA, and they use automatic IP address > > allocation via IPCP. This means that I cannot us a demand-dialed connection > > to the Internet via PSI because each time I re-connect they would give me a > > different IP address. The concept of "suspending" a call introduced by PSCP > > would solve this. > > Not so. No Internet Provider will use PSCP to restore IP links with > dynamically assigned IP addresses. > > Even if it did make sense for PSI to let you use your old IP addresse, > PSCP is irrelevant. IPCP works just fine for such things. It is > easy to use IPCP to suggest IP addresses, but let the peer have its > way. Your client could suggest to PSI the IP address it used before. I agree here. The issue I've heard is one of "security", namely that if your connection drops, another customer could then ask for "your" IP address and tack on to your interrupted sessions. But I think this can be overcome with IPCP and CHAP/PAP simply by the server keeping a database of recently assigned IP numbers, the authenticated username/host they were associated with, and the time that the connection finished/broke. When the remote reconnects, the server will accept its previous IP number AFTER the customer has authenticated, by comparing to the database. If the username doesn't match the one recently tied to that IP address, the remote would send a NAK for the IP address, suggesting one from the pool instead. This theoretical server would also assign from its pool of IP addresses in a least-recently-used fashion (as opposed to the first available numerically, which is what I think many do) to avoid re-assigning the address to someone else right away (which I think is more of a security problem anyway.. I have noticed when tracing sessions from commercial providers such as PSI or Compuserve that I get retransmitted packets bound for some poor disconnected customer who was reading news). I think for this to be effective, the pool of IP addresses needs to be a bit larger than the number of phone lines. - Erik --- Erik D. Olson amazingly, at home eriko@wrq.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Mar 15 14:47:19 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id OAA14548; Fri, 15 Mar 1996 14:47:19 -0500 (EST) Resent-Date: Fri, 15 Mar 1996 14:47:19 -0500 (EST) Date: Fri, 15 Mar 96 14:46:29 EST From: eallen@BayNetworks.com (Ed Allen) Message-Id: <9603151946.AA29589@pobox.BayNetworks.com> To: ietf-ppp@MERIT.EDU Cc: eallen@BayNetworks.com Subject: IPv6 CP Protocol Numbers Resent-Message-ID: <"2oGOx3.0.1Z3.1bSIn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1354 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Hi all, For your information IANA has assigned the needed protocol numbers for IPv6 CP. They are: 0057 = IPv6 over PPP 8057 = IPv6 PPP Control Protocol - Ed Return-Path: Date: Mon, 11 Mar 96 09:30:39 EST From: dhaskin (Dimitry Haskin) To: eallen Subject: Re: Request for PPP DLL Protocol Numbers ----- Begin Included Message ----- >From postel@ISI.EDU Mon Mar 11 02:07:55 1996 Date: Sun, 10 Mar 1996 22:05:36 -0800 From: postel@ISI.EDU (Jon Postel) To: hinden@ipsilon.com Subject: Re: Request for PPP DLL Protocol Numbers Cc: iana@ISI.EDU, dhaskin@BayNetworks.com, deering@parc.xerox.com, sob@harvard.eud, mankin@ISI.EDU Content-Length: 907 Bob: Ok. 0057 = IPv6 over PPP 8057 = IPv6 PPP Control Protocol --jon. From hinden@ipsilon.com Tue Mar 5 21:00:59 1996 Date: Tue, 5 Mar 1996 21:03:32 -0800 To: iana@ISI.EDU From: hinden@ipsilon.com (Bob Hinden) Subject: Request for PPP DLL Protocol Numbers Cc: dhaskin@baynetworks.com, hinden@ipsilon.com, deering@parc.xerox.com, sob@harvard.eud, mankin@ISI.EDU Dear IANA, Please assign PPP DLL Protocol Numbers for IPv6 over PPP and IPv6 PPP Control Protocol These are defined in the internet draft Title : IP Version 6 over PPP Author(s) : D. Haskin, E. Allen Filename : draft-ietf-ipngwg-pppext-ipv6cp-01.txt which the IPng working group plans to submit in the near future into the IETF standards track. Thank you, Bob Hinden / IPng Co-Chair ----- End Included Message ----- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Mar 15 14:37:24 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id OAA13900; Fri, 15 Mar 1996 14:37:24 -0500 (EST) Resent-Date: Fri, 15 Mar 1996 14:37:24 -0500 (EST) Date: Fri, 15 Mar 1996 12:15:32 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199603151915.MAA23967@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re-assignment of IP addresses, PSCP Resent-Message-ID: <"fO4Cx1.0.uO3.cRSIn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1353 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Erik Olson > ... > > easy to use IPCP to suggest IP addresses, but let the peer have its > > way. Your client could suggest to PSI the IP address it used before. > > I agree here. The issue I've heard is one of "security", namely that if > your connection drops, another customer could then ask for "your" IP > address and tack on to your interrupted sessions. But I think this can be > overcome with IPCP and CHAP/PAP simply by the server keeping a database of > recently assigned IP numbers, the authenticated username/host they were > associated with, and the time that the connection finished/broke. When > the remote reconnects, the server will accept its previous IP number AFTER > the customer has authenticated, by comparing to the database. If the > username doesn't match the one recently tied to that IP address, the > remote would send a NAK for the IP address, suggesting one from the pool > instead. ... What happens if when the client calls back and identifies its session with PSCP, the IP address is in use by another client? Any such security concerns are just as valid with PSCP. With PSCP, you would still want IPCP to behave as described above. The server would need exactly the same database of authenticated peers and IP addresses, possibly with "session" added to the relation. PSCP would not convey any information in this case. It could only say after authentication and before IPCP "we're going to try to use the old IP addresses when we get to IPCP". Then there is the problem of doing PSCP after authentication but before IPCP. We already have a solid mechanism for delaying IPCP until after authentication. I suppose it would also apply to PSCP, but how would you ensure that PSCP precedes IPCP, including cases involving lost PSCP Configure-Acks? Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Sun Mar 17 00:19:44 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id AAA24790; Sun, 17 Mar 1996 00:19:44 -0500 (EST) Resent-Date: Sun, 17 Mar 1996 00:19:44 -0500 (EST) Date: Sun, 17 Mar 1996 07:16:58 +0200 (IST) From: "Gilad Keinan (1209)" X-Sender: gilad@neptune To: ietf-ppp@MERIT.EDU Subject: How I can stop being member of this group ? Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"u3Ka33.0.036.03wIn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1355 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Hi there ! I would like to stop receiving automatic Mails from this interest group but I don't know how to do it. Please help !!! Regards Gilad - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Sun Mar 17 18:00:07 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id SAA13946; Sun, 17 Mar 1996 18:00:07 -0500 (EST) Resent-Date: Sun, 17 Mar 1996 18:00:07 -0500 (EST) Message-Id: <2.2.32.19960317225517.00322d8c@SanFrancisco01.pop.internex.net> X-Sender: larribeau-2@SanFrancisco01.pop.internex.net X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 17 Mar 1996 14:55:17 -0800 To: ietf-ppp@MERIT.EDU From: bob@larribeau.com (Bob Larribeau) Subject: PPP MP Interperability Workshop Cc: alfreem@PacBell.COM (Anita Freeman - Pacific Bell), bob@larribeau.com Resent-Message-ID: <"HAN9w3.0.cN3.ra9Jn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1356 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU California ISDN Users' Group PPP MP Interperability Workshop Applications to participate in the California Users' Group PPP MP Interoperability Workshop. If you have a product that you would like to join the testing, send email to be at <> requesting an application. This event will test PPP MP, PPP CCP, and PPP BACP. It is open to any company with products ready to test. Send me email if you have any questions about the event. Bob Larribeau California ISDN Users' Group ----------------------------------------------------------- Bob Larribeau bob@larribeau.com ISDN Consultant San Francisco - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Sun Mar 17 22:58:13 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id WAA20175; Sun, 17 Mar 1996 22:58:13 -0500 (EST) Resent-Date: Sun, 17 Mar 1996 22:58:13 -0500 (EST) Message-Id: <9603180354.AA9222@CServe-Hub4.inhouse.compuserve.com> To: ietf-asid , internet-drafts , ietf-ppp , the iesg , steve coya , "\~\J" <~J@notes2.compuserve.com> From: "peter.a.thelander" Date: 18 Mar 96 14:34:23 Subject: SEND HELP Mime-Version: 1.0 Content-Type: Text/Plain Resent-Message-ID: <"k44-S2.0.zw4.FzDJn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1357 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU SEND HELP Sorry if this message was sent to the wrong place, but I want to stop being a part of this mailing list. Can anyone tell me how to do this? Thanks in advance - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Mar 18 08:58:21 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id IAA01255; Mon, 18 Mar 1996 08:58:21 -0500 (EST) Resent-Date: Mon, 18 Mar 1996 08:58:21 -0500 (EST) Date: Mon, 18 Mar 1996 09:01:42 -0500 From: Patrick Klos Message-Id: <199603181401.JAA09364@linux.klos.com> To: ietf-ppp@MERIT.EDU, ken@rns.com Subject: Re: Don't change LCP! Resent-Message-ID: <"IKc2J.0.FJ.4lMJn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1358 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >most people haven't said anything because they have better things to do than >waste their time discussing a non-issue. our implementation accepts non-lcp >packets until the term-ack comes in. why shouldn't it? it doesn't affect >interoperability with other implementation one iota. and it has the >advantage of not unnecessarily throwing away data. this is a big plus for >paying customers! If so many vendors have decided to implement LCP NOT in accordance with the standard, then why hasn't anyone suggested to make this behaviour a part of the standard? The latest version of the PPP spec was updated in July of 1994. Has everyone diverged from the standard since then, or noone thought to let the standards commitee know that the spec should be changed?!? >the idea of specs are to foster interoperability. in no way does accepting >non-lcp packets after sending a term-req affect interoperability. most of >us are paid to use our brains to make better products, not to blindly follow >our interpretation of a spec. No kidding! But the rule on this mailing list has primarily been "fix the thing that's broke, not something else just because it's easier"! All of a sudden, LCP is the target of a change because noone had enough foresight when Multi-link was being designed! >so what, if interoperabillity is unaffected, who cares. there are no ietf >police and even if there were, they would not be able to tell if an >implementation is accepting NCP packets after sending a term-req. No IETF Police? You wouldn't know that from subscribing to this list! >i agree with vernon here. we have a perfectly good solution now for dealing >with the exit of links from a bundle without losing data. why invent >another method? Why not just change the philosophy of these standards from "methodical, well thought out, modular designs" to "let's just throw this in here because it's easier"? I'll tell you what: Why don't you propose change the PPP state machine to make this change you want official? Let's see how that flies? >it's unimportant whether they are allowing it or not. interoperability is >unaffected. Then why do we even write this stuff down if it's not that important?!? Or at least, make the proposal to change the spec. Having a bunch of vendors just go off and implement PPP their own way is not what interoperability is all about. >please, let's not waste anymore bandwidth on such a non-issue. there are >enough real things going on in PPP than to spend time on this! O.K. I'll concede that it's a non-issue when the PPP RFC changes to reflect the technical non-issue. Patrick ============================================================================ 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 ietf-ppp-request@MERIT.EDU Mon Mar 18 09:00:54 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id JAA01440; Mon, 18 Mar 1996 09:00:54 -0500 (EST) Resent-Date: Mon, 18 Mar 1996 09:00:54 -0500 (EST) X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 18 Mar 1996 06:00:04 -0800 To: inads@research.ftp.com From: fred@cisco.com (Fred Baker) Subject: PPP SNA Control Protocol Cc: Steve Coya , ietf-ppp@MERIT.EDU Resent-Message-ID: <"ual0_.0.AM.HoMJn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1359 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU The PPP Working Group has completed a wrking group last call on the PPP SNA Control Protocol draft and commends it to the IESG for advancement to Proposed Standard. It documents existing implementations that have been deployed for about a year. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= It has recently been discovered that research causes cancer in rats. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Mar 18 09:08:48 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id JAA01729; Mon, 18 Mar 1996 09:08:48 -0500 (EST) Resent-Date: Mon, 18 Mar 1996 09:08:48 -0500 (EST) Date: Mon, 18 Mar 1996 09:13:05 -0500 From: Patrick Klos Message-Id: <199603181413.JAA09429@linux.klos.com> To: ietf-ppp@MERIT.EDU Subject: Re: Don't change LCP! Resent-Message-ID: <"np6Ml.0.lQ.ivMJn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1360 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >>I'm sorry, Dan, but I don't agree. Both the state machine and the RFC >>specifically indicate that non-LCP packets are NOT to be processed when LCP is >>not in the Opened state (i.e. after the Terminate-Request is sent). This is >>the way it's been for several years now! You don't just go change something >>at such a BASIC LEVEL because it'll make Multi-Link a little better. > >I agree it is a protocol violation according to the RFC. However, implementors >of MP >have observed that the added flexibility improves performance slightly. >Following >the RFC strictly can (and usually does) cause dropped MP fragments. We have just >bent the rules slightly by accepting additional frames on the link. I'm sure >those of >us who do this allow frames as long as the channel is up. Fine. I understand the issue at hand. My primary objection is that the solution requires non-adherence to the current definition of LCP. If you Multi-link people (and I am one of them) want to change LCP, that's not too big a deal either, but it should be changed properly, not with just a few words in the discussion of the Termination Phase, but in the state machine as well. >Once again, we are not changing the fundamentals of LCP. It is up to the >implementor. >We *MAY* (no *MUST* here) change LCP by replacing the *MUST* to *MAY* or >*SHOULD* (IETFese), but it is not necessary. Who cares if I decide to continue >to >receive frames! It shouldn't affect the peer's implementation. I understand that the "flexibility" does not necessarily affect interoperability. I'm being so "bull-headed" on principle (and because I like to get Vern's goat at least once a year ;^). So why doesn't someone propose the change to the state machine AND the wording, and let's get on with it? Patrick ============================================================================ 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 ietf-ppp-request@MERIT.EDU Mon Mar 18 10:17:10 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id KAA04293; Mon, 18 Mar 1996 10:17:10 -0500 (EST) Resent-Date: Mon, 18 Mar 1996 10:17:10 -0500 (EST) Date: Mon, 18 Mar 1996 10:21:19 -0500 From: Patrick Klos Message-Id: <199603181521.KAA09534@linux.klos.com> To: ietf-ppp@MERIT.EDU Subject: Re: PSCP questions/issues... Resent-Message-ID: <"q-I7o1.0.m21.gvNJn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1361 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >> The other (difficult) end of the spectrum is Novell IPX. IPX transfers "keep alive" >> messages between the server and clients about every 30 seconds. This means >> that any demand-dialled link will be permanently connected (hence expensive) >> unless the IPX keep alives can be spoofed. Also, if the call cannot be made >> (like if all channels at the other end are busy) then IPX doesn't usually end the >> login-session gracefully. It usually hangs up the PC, which then needs re-booting. > >So I've recently been told. But aren't there many commercial IPX/PPP >implementations that support NCP, SAP, and IPX RIP spoofing without >support from PPP? There may be multiple commercial IPX/PPP implementations with spoofing, but do they IN-TER-OP-ER-ATE? I'm sure this is what PSCP is all about. IP's RIP spoofing was probably done before PPP was even thought of, so obviously, it won't REQUIRE PPP. >> We need IPX spoofing for the reasons outlined above. If I access any of the >> Microsoft PCs then NetBIOS starts polling the Microsoft network about once >> a minute, so we also need to spoof the NetBIOS messages. >> ... > >Doesn't Microsoft support NetBIOS demand dialing for their many employees? >Without PSCP? Ditto (above). Is this method defined to promote interoperability? >> ... Image the phone bill for the calls to Australia if the RIPs and SAPs >> were not being spoofed ! > >Yes, but aren't there current commerical PPP products that spoof IPX? >Are they lame? Are the interoperable? >Second, the only reason any Internet Provider uses dynamic IP >addressing is because they have more clients than IP addresses. The >only way PSCP can allow a suspended IP call is if the IP address is >never used by some other customer while the call is suspended. If the >IP address is transiently used by some other client of the ISP and then >reused by the original customer, then it is likely that the other >client will have sent RST's in response to things like TCP keepalives, >killing the first client's TCP sessions and making it a waste of time >for the all concerned to restore the connection. It would appear in this case that the dynamic IP address assigned when the initial link was established (with PSCP) would have to be "locked" until the PSCP timeout expires or the client terminates the PSCP link. This is (of course) a factor the ISP must consider when giving out accounts that have PSCP rights. >> I would suggest that the mix of protocols which I use is probably more the >> norm nowadays than your pure TCP/IP based installation. > >In private networks, perhaps, but judging from what I can see, most PPP >installations are now pure IP from personal computers (Mac's and IBM) >to Internet Service Providers, and they don't need even as little >spoofing as I use, and so need no control for spoofing. Of course, >that implies little about the need for PSCP; it could still be >important for IPX installations. As usual, you think the rest of the world can do things just the same way you can. But the rest of the world is moving on, and there are issues with these newer protocols that you don't quite comprehend. Maybe right now, the majority of ISP's only support IP, but I've been hearing more and more ISP's that provide IPX as well (for gamers). >> Various vendors have put a considerable amount of time, effort and money into >> developing BACP, and the same goes for the various proprietary spoofing >> systems which currently exist. They have done so because there is sufficient >> justification for it (i.e. there are customers out there who want - and are willing >> to pay for - these things). > >I have never heard a customer ask for something like PSCP. Still, for >the little I know of IPX and NetBIOS, the commercially available >spoofing implementations could be very lame because IPX or NetBIOS >spoofing is much harder than IP spoofing, and so PSCP is needed for IPX >or NetBIOS spoofing. I don't know. That's right - you don't know. So why don't you let the folks who do know what is involved in IPX and/or NetBIOS spoofing debate the issues rather than you trying to tell those people how you don't need it for IP, so it must not be useful?!? >As far as I can see, there has been little effort put into BACP yet >outside 3 or 4 organizations. I don't mean to denigrate the efforts of >those people working on it, but it is important to be honest and >realistic, to not confuse expressions of interest and sales organization >efforts with what the IETF should consider effort. All good things start from the efforts of just a few people. This doesn't make them less valuable. And if it involves PPP, shouldn't other members of the PPP community be invited to contribute rather than wait until those 3 or 4 vendors come up with something proprietary that noone else supports?? >For both PSCP and BACP, I recall hearing expressions of implementor >interest almost solely from PPP server vendors. Unless server vendors >convince enough of the client implmentors (including freeware) to >implement, the protocols will be used only between servers. There is a >substantial market for such server-to-server installations (e.g. >connecting company networks), but the enormous size of the personal >computer-to-server market means that server vendors will also have to >solve the problems that PSCP and BACP hope to solve, but without PSCP >or BACP, unless you get enough client implementations. Except possibly >for PSCP and IPX, the problems that BACP solve can be solved purely in >servers. That has obvious and important implications. As a client implementor, I can tell you that I am working on a multi-link implementation for the client. As far as PSCP goes, minimal changes would be required for our client to support PSCP. You see, a Netware client cares little about receiving NCP Watchdog packets, and so won't miss them when they don't come it. I don't have all the details on SPX, but I expect the amount of support code to provide "keep-alive" responses for SPX to be just as minimal. And even if the scope of these efforts was limited to server implementations, does that mean the effort to standardize is a waste? In this day and age, server interoperability is probably even more important than server/client interoperabilty! Patrick ============================================================================ 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 ietf-ppp-request@MERIT.EDU Mon Mar 18 13:51:57 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id NAA11628; Mon, 18 Mar 1996 13:51:57 -0500 (EST) Resent-Date: Mon, 18 Mar 1996 13:51:57 -0500 (EST) X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 18 Mar 1996 10:51:06 -0800 To: ietf-ppp@MERIT.EDU From: fred@cisco.com (Fred Baker) Subject: CIUG PPP MP Workshop Application Resent-Message-ID: <"y_ndJ2.0.Er2.43RJn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1363 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >X-Sender: larribeau-2@SanFrancisco01.pop.internex.net >Mime-Version: 1.0 >Date: Sun, 17 Mar 1996 14:52:43 -0800 >To: pgenovese@global.net, rajesh@cosystems.com, peterc@acc.com, > ken@anik.skylinetech.com, dlh@jrl.com, sjfang@scci.com, > b.schofield@northern.co.uk, kthomas@adtran.com, crich@shiva.com, > robert@shiva.com, leemay_yen@3mail.3com.com, jsteinb@charm.gandalf.ca, > Doug.Bleich@develcon.com, es@NetCS.COM (Elmar Saenger), mph@ftp.com, > "FRANCIS O'HALLORA" <75202.3407@compuserve.com>, > pdebeasi@pcmail.casc.com, lp@acc.com, EricX_Ciprian@ccm.jf.intel.com, > huy@montreal.hp.com, Rick.Kuhlbars@NetCS.COM, > RANDY WHITE , sergey@radmail.rad.co.il, > zytrax@interlink.net, wray_west@prirate.com, pdebeasi@casc.com, > es@NetCS.COM, mrobidas@dnbf01.bram.cdx.mot.com, PAULC@diamondmm.com, > nareng@microsoft.com, hxl@NSD.3Com.COM, Cheng_Chen@3mail.3com.com, > tcnguyen@cisco.com, gerry@spider.co.uk, raghu@trancell.com, > danb@alpo.casc.com, mpt@farallon.com, binh@sbei.com, > guru@westworld.com, orozco@ctron.com, mbrooks@zyxel.com, > JasonHwang@acer.com.tw, arnold@fet.com, jzarkowe@baynetworks.com, > sjustus@baynetworks.com, michaelf@eicon.com, stevek@digi.com, > sheri.mayhew@develcon.com, naka@inf.furukawa.co.jp, fred@cisco.com, > davidl@big-island.com, joe_moran-u3358@email.mot.com, dave@chaser.com, > chuck@flowpoint.com, todd@netx.nei.com, wwagner@shiva.com, > asokan@hicom.hitachi.com, dsanford@usr.com, EdwardD@fbcs.fujitsu.com, > hollie@midnight.com, > alfreem@PacBell.COM (Anita Freeman - Pacific Bell), bob@larribeau.com >From: bob@larribeau.com (Bob Larribeau) >Subject: CIUG PPP MP Workshop Application > >To ISDN Networking Product Developers: > >The third California ISDN Users' Group (CIUG) ISDN PPP Interoperability >Workshop will be held Monday, May 20 through Friday, May 24 at Pacific >Bell's San Ramon Headquarters. This Workshop will be open to companies with >ISDN products implementing PPP Multilink Protocol (PPP MP), PPP Compression >Control Protocol (PPP CCP), and/or PPP Bandwidth Allocation Protocol (PPP >BACP). It will provide an opportunity to test the interoperability of your >products against products from the other companies attending. > >The only requirement for attending this Workshop is that you bring a product >implementing PPP MP, PPP CCP, and/or a PPP BACP with you test. For PPP MP >products should be at beta or near beta level of operation. For PPP CCP and >PPP BACP engineering prototypes are appropriate. This is not an appropriate >place to test basic ISDN network connection issues. > >This Workshop will be open to only the participants. This is a >participatory not a spectator event; it is not open to observers. Some >participants will be working with unreleased products and others are >expected to respect their privacy. > >There is a charge of $100 per person to participate in this workshop to >cover the cost of food. This fee covers the entire week. Each person >attending must pay the full amount. There will be no provision for a daily >rate for those not attending the entire week. > >Participants will be responsible for bringing their own workstations and >ISDN equipment. Pacific Bell will provide one BRI with either a U or an S/T >interface for each participant. A limited number of PRI lines will also be >available on request. The PRI lines will be shared among all participants. > >Each company will be provided a six foot table, 10 amps of power, and one >power strip. Bring additional power strips if you need them. > >We will focus the testing on PPP MP on Monday and Tuesday. Wednesday and >Thursday will be for testing PPP CCP. Friday will be for testing PPP BACP. > >This will be a "self organizing" event. It will be your responsibility to >develop your own test plan and to find your own testing partners. This has >worked well in the past and we believe that it provides the most productive >environment for testing. > >Fill out the attached form and email it to me at to >register. Our last Workshop was attended by 35 companies. They found it to >be invaluable in moving the interoperability of their products forward. We >are expecting more attendees this time and may very well run out of space. >Get your reservation in early to assure yourself a place. > >There are a number of hotels in the San Ramon area. The San Ramon Marriott >is conveniently located to Pacific Bell. Pacific Bell is at 2600 Camino >Ramon in San Ramon. Camino Ramon is parallel to and just east of the 680 >Freeway between the Bollinger Canyon and the Crow Canyon turn offs. > >You can ship your equipment to: > > Brent Reid > Pacific Bell > Room 1S200OO > 2600 Camino Ramon > San Ramon, CA 94583 > >Please mark "For PPP MP Testing". Schedule your equipment to arrive on May >16 or 17. The testing rooms will be open from Noon to 5:00 PM on Sunday May >19 for set up. Plan to come in on Sunday to set your equipment up so we can >start the testing promptly at 9:00 AM. There will be no testing available >on Sunday. > >Send me email or call me if you have any questions. > > Bob Larribeau > bob@larribeau.com > 415-241-9920 > >Return the following application by email immediately to reserve your place. >Make sure you include the names of all attendees so Pacific Bell's security >will have a complete list of attendees. Send check for $100 for each >participant to: > >California ISDN Users' Group >P.O. Box 27901-318 >San Francisco, CA 94127 > >Only checks will be accepted. Cash or credit card payments are not >available. Payment must be received in advance. All attendees must pay in >full. A reduced rate is not available for those not attending all five days. > > >------------------------------------------------------------------------------ > >Primary Contact Name: > >Names of other Participants: > >How many tables will you need: We have provided large companies with >multiple divisions and/or multiple product lines more than one table in the >past. We will do our best to accommodate requests for multiple tables as >well as to have as many different companies attend as possible. > >Company: > >Address: > >Phone & Fax: > >email address: > >Describe Product: > >PPP options to be tested: (Filling out this section accurately is >important. We will use this to put together a matrix that you can use to >find testing partners. We will also have two separate rooms for testing and >we will use this information to group vendors in each room.) > > NCP (BCP, IPCP, IPXCP, etc.): > > Authorization (PAP, CHAP): > > PPP MP (Yes or No): > > PPP CCP (Yes or No): > > Uses LAPB (Yes/No) > > Uses RESET/RESET ACK (Yes/No) > > Other (explain) > > Compression Used (STAC, V.42bis, ...) > > PPP BACP (Yes or No): > > >The following lines will needed: > > Full time access to BRI (Yes or No): > > How many BRI lines do you need? > > Do you want a U or an S/T interface? > > Part time access to PRI (Yes or No): > > Number of analog phone lines desired? > >ISDN BRI and PRI service will be provided by a Nortel DMS-100 switch. > > >Other comments or requirements: > > > >----------------------------------------------------------- > Bob Larribeau bob@larribeau.com > ISDN Consultant San Francisco > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= It has recently been discovered that research causes cancer in rats. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Mar 18 13:52:01 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id NAA11631; Mon, 18 Mar 1996 13:52:01 -0500 (EST) Resent-Date: Mon, 18 Mar 1996 13:52:01 -0500 (EST) X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 18 Mar 1996 10:51:10 -0800 To: ietf-ppp@MERIT.EDU From: fred@cisco.com (Fred Baker) Subject: Re: How I can stop being member of this group ? Resent-Message-ID: <"cCm4D.0.0r2.13RJn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1362 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU This is what I got when I forwarded the recent message about unsubscribing to ietf-ppp-request@merit.edu. Plase make a note of it... General info ------------ Subcription/unsubscription/info requests should always be sent to the -request address of a mailinglist. If a mailinglist for example is called "thelist@some.domain", then the -request address can be inferred from this to be: "thelist-request@some.domain". To subscribe to a mailinglist, simply send a message with the word "subscribe" in the Subject: field to the -request address of that list. To unsubscribe from a mailinglist, simply send a message with the word (you guessed it :-) "unsubscribe" in the Subject: field to the -request address of that list. In the event of an address change, it would probably be the wisest to first send an unsubscribe for the old address (this can be done from the new address), and then a new subscribe to the new address (the order is important). Most (un)subscription requests are processed automatically without human intervention. Do not send multiple (un)subscription or info requests in one mail. Only one will be processed per message. NOTE: The -request server usually does quite a good job in discriminating between (un)subscribe requests and messages intended for the maintainer. If you'd like to make sure a human reads your message, make it look like a reply (i.e. the first word in the Subject: field should be "Re:", without the quotes of course); the -request server does not react to replies. The archive server ------------------ Every submission sent to this list is archived. The size of the archive depends on the limits set by the list maintainer (it is very well possible that only, say, the last two messages sent to the list are still archived, the rest might have expired). You can look at the header of every message coming from this list to see under what name it has been archived. The X-Mailing-List: field contains the mailaddress of the list and the file in which this submission was archived. If you want to access this archive, you have to send a message to the -request address with the word "archive" as the first word of your Subject:. To get you started try sending a message to the -request address with the following: Subject: archive help -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= It has recently been discovered that research causes cancer in rats. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Mar 18 15:17:09 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id PAA14729; Mon, 18 Mar 1996 15:17:09 -0500 (EST) Resent-Date: Mon, 18 Mar 1996 15:17:09 -0500 (EST) Message-Id: <199603182016.VAA29684@mail.tel.fmv.se> X-Sender: malie@mail.tel.fmv.se X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Mar 1996 21:16:12 +0000 To: ietf-ppp@MERIT.EDU From: Mats Lindhe Subject: Suggested BAP/BACP addition Resent-Message-ID: <"3VSBX3.0.pb3.-ISJn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1364 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Not being an expert, I may be overlooking something, but it seems to me that one code point is missing in the proposed Link Type coding (items 5.1-5.2 in draft-ietf-pppext-bacp-01.txt).=20 Link type "Switched 64" should be added, according to my proposal. It would be similar to the "Switched 56 ..." now allocated Bit 48, but beeing transparent 64k. Such cicuits/links are common in pre-ISDN digital networks such as the Swedish PSTN as well as the Swedish nationwide defence network. They should not be regarded as equivalent to an ISDN link as far as I can understand. Regards, Mats Lindh=E9 FMV:TelekomS, S-115 88 Stockholm, Sweden =20 Desk phone +46 8 782 40 31 Personal phone +46 70 577 40 31 Fax +46 8 782 55 41 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Mar 19 09:29:42 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id JAA10953; Tue, 19 Mar 1996 09:29:42 -0500 (EST) Resent-Date: Tue, 19 Mar 1996 09:29:42 -0500 (EST) Message-ID: <01BB1576.B3DAB640@merlin.arrisnet.com> From: Mark Garti To: "'ietf-ppp@MERIT.EDU'" Subject: BACP - Call Status Indication Date: Tue, 19 Mar 1996 09:30:22 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Resent-Message-ID: <"sFmtJ.0.qg2.ZIiJn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1365 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU What is the intended use of the Call Status Indication message in the BAP? Mark Garti Arris Networks, Inc. Westford, MA 01886 mgarti@arrisnet.com 508-392-8700 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Mar 19 13:46:41 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id NAA19024; Tue, 19 Mar 1996 13:46:41 -0500 (EST) Resent-Date: Tue, 19 Mar 1996 13:46:41 -0500 (EST) From: michel@priacc.com Date: Tue, 19 Mar 96 10:42:41 PST Message-Id: <9602198272.AA827261116@smtplink.priacc.com> To: ietf-ppp@MERIT.EDU Cc: cobb@priacc.com, jd@priacc.com, johnson@priacc.com, petry@priacc.com, john@priacc.com, jtaarud@priacc.com, trumbo@priacc.com, worrells@priacc.com Subject: BACP-02.TXT Resent-Message-ID: <"CuU4_3.0.re4.w3mJn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1366 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Section 4.2, "Bandwidth Management": ------------------------------------ Given the concern about document length expressed at the LA meeting, I think we should delete everything from the last sentence of the 1st paragraph through the 6th paragraph. This whole page of text distracts from the protocol itself. We should replace the last paragraph with this: A BAP implementation may monitor its transmit traffic, both transmit and receive traffic, or choose not to monitor traffic in either direction. An implementation MUST NOT base its response to a Link-Drop-Query-Request on its receive traffic, because the initiator of the request clearly knows more about its future transmit traffic than the responder can know. Server systems SHOULD implement bi-directional monitoring and single-user dialin clients MAY implement any type of monitoring. This will allow client BAP implementations that require minimal end- user configuration. Section 5.1:, "Link Type" field: -------------------------------- We should say that an implementation MAY leave all bits cleared. With the current definitions, and something like switched 56, I must either lie, or be allowed to leave all bits cleared. Leaving them all cleared also allows for future call types not yet defined in the protocol. Also, I think "Bit 0 of the Link Type field corresponds to bit 32..." should say "Bit 0 of the Link Type field corresponds to bit 7...." Section 5.2, "Phone-number", "Description": ---------------------------- The sentence The Phone-Number option MUST appear in a Callback-Request if the Response Code is set to Request-Ack. should say The Phone-Number option MUST appear in a Callback-Request. Section 5.2.1, Subscriber Number: --------------------------------- I still don't see how an implementation can make sense of a phone number whose format is not specified. From discussions at the meeting, I understand a wish to allow a pre-configured number to be sent, where the receiver simply dials it without question. (This is because some areas now have confusing dialing rules. For example, in some areas, some exchanges *in your own area code* require you to dial the area code+number, whereas other exchanges in your area code do NOT allow you to dial the area code. This is very difficult to automate, but fairly easy to manually configure.) But the solution to this dilemma is NOT to say the format of a Subscriber Number is unspecified (i.e., unusable in some cases). One solution is to simply have 2 suboption choices: one is a "pre-configured number," where the receiver is not to interpret it in any way. The other suboption is a canonical form: E.164, which allows an implementation to know its own dialing rules, and dial appropriately. Section 5.6, "Action" description: ---------------------------------- There are currently 3 actions: no retry, retry same number, retry "next number in list." Why do we want to be so specific about what number we will retry? One reason for allowing multiple phone numbers is that a certain caller may not have access to some phone numbers. So while an implementation may want to try a different number, it may not be the "next number in list." It could be another number. How about if we reduce the actions to 2: no retry, and retry? Mechanical changes ------------------ Section 4.1, par. 3, sentences 2 & 3: "Drop-Link-..." should be "Link-Drop-...". - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 20 09:11:11 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id JAA17748; Wed, 20 Mar 1996 09:11:11 -0500 (EST) Resent-Date: Wed, 20 Mar 1996 09:11:11 -0500 (EST) Message-Id: <9603201412.AA0300@shivaportal.shiva.com> To: Patrick Klos Cc: ietf-ppp From: Robert Myhill/Shiva Corporation Date: 20 Mar 96 9:08:47 Subject: Re: PSCP questions/issues... Mime-Version: 1.0 Content-Type: Text/Plain Resent-Message-ID: <"p65w11.0.pI4.k61Kn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1367 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >>Second, the only reason any Internet Provider uses dynamic IP >>addressing is because they have more clients than IP addresses. The >>only way PSCP can allow a suspended IP call is if the IP address is >>never used by some other customer while the call is suspended. If the >>IP address is transiently used by some other client of the ISP and then >>reused by the original customer, then it is likely that the other >>client will have sent RST's in response to things like TCP keepalives, >>killing the first client's TCP sessions and making it a waste of time >>for the all concerned to restore the connection. >It would appear in this case that the dynamic IP address assigned when the >initial link was established (with PSCP) would have to be "locked" until >the PSCP timeout expires or the client terminates the PSCP link. This is >(of course) a factor the ISP must consider when giving out accounts that >have PSCP rights. Yes, and a sensible way of "locking" an IP address would be to keep the NCP's in the Opened state when a connection is suspended. This is suitable for other protocols, too. A PC client that has been assigned an IPX address isn't going to behave well if its IPX address is changed when the connection is resumed. The idea of keeping open the NCP's when a connection is suspended was mentioned on this mailing list, but not really discussed. It seems that it should at least be an option of PSCP to keep the NCP's open on a suspended connection. It probably shouldn't be mandatory, though, since there are plenty of implementations out there doing dial-on-demand that bring down the NCP's when suspending a connection. These are (exclusively?) LAN-to-LAN, where addressing tends to be more static. But single-user dialin won't work as well (or at all) when addresses change. Robert - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 20 10:20:20 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id KAA19798; Wed, 20 Mar 1996 10:20:20 -0500 (EST) Resent-Date: Wed, 20 Mar 1996 10:20:20 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; cc: ietf-ppp@MERIT.EDU From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-pppext-bacp-02.txt Date: Wed, 20 Mar 96 09:23:34 -0500 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9603200923.aa11187@IETF.CNRI.Reston.VA.US> Resent-Message-ID: <"4ros33.0.-q4.k82Kn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1368 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --NextPart A Revised 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 : The PPP Bandwidth Allocation Protocol (BAP) The PPP Bandwidth Allocation Control Protocol (BACP) Author(s) : C. Richards, K. Smith Filename : draft-ietf-pppext-bacp-02.txt Pages : 21 Date : 03/18/1996 This document proposes a method to manage the dynamic bandwidth allocation of implementations supporting the PPP multilink protocol [2]. This is done by defining the Bandwidth Allocation Protocol (BAP), as well as its associated control protocol, the Bandwidth Allocation Control Protocol (BACP). BAP can be used to manage the number of links in a multilink bundle. BAP defines datagrams to coordinate adding and removing individual links in a multilink bundle, as well as specifying which peer is responsible for which decisions regarding managing bandwidth during a multilink connection. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-bacp-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-bacp-02.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (193.205.245.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) 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-bacp-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. For questions, please mail to Internet-Drafts@cnri.reston.va.us. 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: <19960318155234.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-bacp-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-bacp-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960318155234.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 20 10:53:21 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id KAA21091; Wed, 20 Mar 1996 10:53:21 -0500 (EST) Resent-Date: Wed, 20 Mar 1996 10:53:21 -0500 (EST) Date: Wed, 20 Mar 96 10:52:43 EST From: jgardner@BayNetworks.com (Jim Gardner) Message-Id: <9603201552.AA21993@pobox.BayNetworks.com> To: ietf-ppp@MERIT.EDU Subject: BACP-02.TXT Resent-Message-ID: <"qU8Mx.0.H95.jd2Kn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1369 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Comments on draft-ietf-pppext-bacp-02.txt: 1. Why must the Link Discriminator be mandatory? Is it so a peer who receives a Link-Drop-Query-Request can stop transmitting over a certain line, before its peer sends an LCP Terminate-Request? I thought this was solved in Sec 4.1 Link Management? 2. If it is necessary to indeed have the Link Discriminator option, it should be longer than 16 bits. Here's why: Some vendors use the Authentication Protocol, CHAP or PAP, to identify which circuit a line belongs to on the incoming side of a call. As you know, Authentication happens after negotiation of LCP options, so it is impossible to know which circuit a line will end up belonging to. It would be possible to use a boxwide unique line number for each PPP line configured in a box, however 32 bits or more may be required to do this. 3. Section 4.4 is too complex and too vague. What exactly is the username? Is it a peer's Chap Name or PAP ID? Recognizing as George Wilkie stated: "the endpoint discriminator and authentication are both optional." You can't rely on of the values being present for comparison. Scott Jackson had replied: "Now that the Link-Discriminator is mandatory it can also be used to determine the favoured system, since each implementation negotiates independent values." But Sec 2.1 p.2 Link-Discriminator says: "The discriminator is independent for each peer, so each link may have 2 different LCP Link-Discriminator values, one for each peer." This seems to indicate each peer could come up with the SAME Link-Discriminator, therefore breaking the comparison. I like George Wilkie's idea of favoring the initializer of the first link, which is reliable,(nothing to compare and no requirement of Link-Discriminator). 4. Why is the Response Code, Request-Rej, of Sec 4.5 p. 9 necessary? On the previous page the second paragraph reads: "All of the BAP datagrams MUST be supported by an implementation." This indicates that all Request commands must be implemented... 5. In a Call-Request Sec 4.5.1 p. 10, it is stated: "The options field must include the Link-Type option." Shouldn't this also be the case for a Callback-Request Sec 4.5.3 p. 11? Sec 5.1 p. 13, says it MUST be included in Call- or Callback-Request. Also, Appendix lists Link-Type as a mandatory option for Callback Request. 6. Is it necessary for an implementation to send a Call-Status-Indication, Sec 4.5.7 p. 12, even when a call is successful? Why? It seems like redundant information. 7. If multiple Phone-Number options Sec 5.2 p 15, appear in a Response, should any preference be placed upon them? IE: should the first one be tried first, etc? 8. Appendix p. 20, should list Phone-Number as a mandatory field for Callback- Request. 9. There is a risk of thrashing when one side is monitoring Transmit and its peer is monitoring Receive. The Receive's side monitoring may consider the bundle to be congested, while the Transmit's side does not. So the Receive monitoring side sends a Call-Request to the peer. Unless the peer Naks the request based upon its Transmit monitoring, a new line will be added to the bundle. The next second, the side monitoring Transmit, believing congestion is not occurring, sends a Link-Drop-Query-Request. The peer receives it and because it "MUST base its response on its transmit heuristics", it agrees to drop the link...Then it starts over again. It should be stated that an implementation which receives a Call- Callback Request should Nak the Request if its Transmit monitoring (transmit heuristics), indicates the bundle is uncongested. 10. I realize an attempt is being made to slim the content of BACP but I wanted to throw this out anyway... It would be nice for each end of the bundle to know what type of monitoring its peer was performing: Transmit, Receive, both, or neither. It would also be nice to know the maximum/minimum number of links either peer wishes to be included in the bundle. If a peer knew it was the only side monitoring, and the number of links was greater than the number its peer required, it could choose to skip sending a Link-Drop-Query-Request when removing link(s). If the monitoring side knew its peer could have a maximum of 2 links for a particular circuit, it could know not to bother sending a Call- Callback Request under congested conditions. If a peer knew that both sides were monitoring Transmit and Receive, one side, perhaps a CPU bound piece of hardware, could negotiate to not monitor at all. Or both sides could opt to monitor Transmit only. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 20 14:29:31 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id OAA28174; Wed, 20 Mar 1996 14:29:31 -0500 (EST) Resent-Date: Wed, 20 Mar 1996 14:29:31 -0500 (EST) Message-ID: <31505CBB.1C14@ed.nce.sita.int> Date: Wed, 20 Mar 1996 20:30:03 +0100 From: Cathal Fitzgerald Organization: ed.nce.sita.int X-Mailer: Mozilla 2.0GoldB1 (Win95; I) MIME-Version: 1.0 To: ietf-ppp@MERIT.EDU Subject: Re: Don't change LCP! References: <199603181413.JAA09429@linux.klos.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"Phbe03.0.xt6.8o5Kn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1370 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU As an end-user (non-code writing person) I'd like to add my bit, for what it's worth. I have the task of evaluating PPP implementations, both client and server. With the little experience I have gained in debugging interoperability, I have frequently had to resort to quoting RFCs (admittedly not always correctly) and attaching a trace of PPP negotiations to convince a provider of where the problem lay. Several of these were on Beta trials, but others were cases where the provider wouldn't admit that it was their problem until it was spelled out in clear text. If the RFCs don't reflect what is actually being done it will make beta trials and interoperability testing more difficult. The more difficult this becomes, the less inclined I, for one, become to test new products. I believe that the closer implementations are to the RFCs the better, and if this means updating existing RFCs I'm all for it. Patrick Klos wrote: > > >>I'm sorry, Dan, but I don't agree. Both the state machine and the RFC > >>specifically indicate that non-LCP packets are NOT to be processed when LCP is > >>not in the Opened state (i.e. after the Terminate-Request is sent). This is > >>the way it's been for several years now! You don't just go change something > >>at such a BASIC LEVEL because it'll make Multi-Link a little better. > > > >I agree it is a protocol violation according to the RFC. However, implementors > >of MP > >have observed that the added flexibility improves performance slightly. > >Following > >the RFC strictly can (and usually does) cause dropped MP fragments. We have just > >bent the rules slightly by accepting additional frames on the link. I'm sure > >those of > >us who do this allow frames as long as the channel is up. > > Fine. I understand the issue at hand. My primary objection is that the > solution requires non-adherence to the current definition of LCP. If you > Multi-link people (and I am one of them) want to change LCP, that's not too > big a deal either, but it should be changed properly, not with just a few > words in the discussion of the Termination Phase, but in the state machine > as well. > > >Once again, we are not changing the fundamentals of LCP. It is up to the > >implementor. > >We *MAY* (no *MUST* here) change LCP by replacing the *MUST* to *MAY* or > >*SHOULD* (IETFese), but it is not necessary. Who cares if I decide to continue > >to > >receive frames! It shouldn't affect the peer's implementation. > > I understand that the "flexibility" does not necessarily affect > interoperability. I'm being so "bull-headed" on principle (and because > I like to get Vern's goat at least once a year ;^). So why doesn't > someone propose the change to the state machine AND the wording, and > let's get on with it? > > Patrick > ============================================================================ > 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 ietf-ppp-request@MERIT.EDU Wed Mar 20 18:06:46 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id SAA05208; Wed, 20 Mar 1996 18:06:46 -0500 (EST) Resent-Date: Wed, 20 Mar 1996 18:06:46 -0500 (EST) Message-ID: <01BB1688.36D34780@merlin.arrisnet.com> From: Mark Garti To: "'ietf-ppp@MERIT.EDU'" Subject: PPP vs CISCO Raw HDLC Date: Wed, 20 Mar 1996 18:08:15 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Resent-Message-ID: <"LRTYU3.0.5H1.tz8Kn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1371 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Since almost every router runs PPP these days, is there any signifigance to cisco raw hdlc? Does it provide some feature that PPP lacks? OR has PPP overwhealmed it? If this is the wrong forum for this question, please suggest the correct one. Thank you. Mark Garti mgarti@arrisnet.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Mar 22 16:49:50 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id QAA19116; Fri, 22 Mar 1996 16:49:50 -0500 (EST) Resent-Date: Fri, 22 Mar 1996 16:49:50 -0500 (EST) Message-Id: <9603222148.AA20980@chickadee.watson.ibm.com> X-Mailer: exmh version 1.6.5 12/11/95 To: ietf-ppp@MERIT.EDU Subject: Mobility agent discovery Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 22 Mar 1996 16:48:01 -0500 From: Baiju Patel Resent-Message-ID: <"49DiZ1.0.yf4.M0oKn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1372 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU During the IETF meeting in LA some questions were raised as to the need for such an option. This is our take on why such option is desirable. Under current specification of IPCP, when a dial-in host sends its own address, the server may accept that address or send an alternate address to be used by the dial-in host (can also send REJECT, in which case we know what to do). Thus, if a mobile-IP host, when in a foreign subnet, send out its own address as part of the IPCP negotiation to the dial-in server the server will send a configure NACK with an alternate address (since it has no way of knowing that the dial-in host is a mobile IP host or not. At this point, mobile-IP host may send a foreign agent solicitation. If the dial-in host send out an advertisement in reply, the mobile host will ignore the address supplied by the foreign agent and register using its own IP address. Thus, mobile IP will work. The problem is that the dial-in server has allocated an alternate address to the dial-in host which is not used. If the dial-in server did not allocate the address, and sent a reject, it will imply that the non-mobie IP hosts will not get an address from the dial-in server, and thus, will couse problem. In summary, the Mobile IP will work with current IPCP specification, however, will have inefficient use of IP addresses in certain cases. It will also involve an extra step. The proposed option attempts to remedy this problem and offer a clean solution. I hope this helps. Baiju - - -- =============================================================================== Baiju V. Patel (external): http://www.research.ibm.com/people/b/baiju (internal): http://w3.watson.ibm.com/~baiju/baiju.html IBM T. J. Watson Research Center, H3-D36 30 Saw Mill River Road, Hawthorne, NY 10532 =============================================================================== - ------- End of Forwarded Message ------- End of Forwarded Message - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Mar 22 18:55:27 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id SAA23164; Fri, 22 Mar 1996 18:55:27 -0500 (EST) Resent-Date: Fri, 22 Mar 1996 18:55:27 -0500 (EST) From: michel@priacc.com Date: Fri, 22 Mar 96 15:51:47 PST Message-Id: <9602228275.AA827538916@smtplink.priacc.com> To: ietf-ppp@MERIT.EDU Subject: L2F Resent-Message-ID: <"jc4Pr2.0.gf5.atpKn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1373 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU At the LA meeting, the L2F description of CHAP handling said that the answering agent for a mobile caller would challenge the caller, and then send the challenge and the response to the Home Agent for authentication. It seems to me this completely defeats the purpose of a challenge authentication. If the host doesn't get to pick the challenge, what prevents a bad guy from using a previously used, known good, challenge and response? For example: I'm a bad guy, and I'm snooping traffic to the Home Agent. A legitimate user calls in, and I see his challenge and his response get authenticated by the Home Agent. Now I can present myself to the Home Agent as a Foreign Agent, and I send the previously snooped challenge and its response. It doesn't seem like much of a challenge if an attacker gets to pick his own challenge. Am I understanding this correctly? -eric - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Mar 22 20:00:57 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id UAA25121; Fri, 22 Mar 1996 20:00:57 -0500 (EST) Resent-Date: Fri, 22 Mar 1996 20:00:57 -0500 (EST) X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 22 Mar 1996 17:00:46 -0800 To: ietf-ppp@MERIT.EDU From: fred@cisco.com (Fred Baker) Subject: New PPP Chair Cc: karl@morningstar.com, steve coya , inads@research.ftp.com Resent-Message-ID: <"952W03.0.D86.3rqKn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1374 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU As I have found a new way to while away the hours, I am finding it necessary to no longer chair the PPP Working Group. Karl Fox of Morningstar Technologies (now Ascend Communications, I'm told) will take over that responsibility, and hopefully do a better job than I. However, I won't be leaving the PPP community... Cheers =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= It has recently been discovered that research causes cancer in rats. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Mar 22 20:39:53 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id UAA26168; Fri, 22 Mar 1996 20:39:53 -0500 (EST) Resent-Date: Fri, 22 Mar 1996 20:39:53 -0500 (EST) Date: Fri, 22 Mar 1996 17:39:34 -0800 From: Tim Kolar Message-Id: <199603230139.RAA03297@greatdane.cisco.com> To: michel@priacc.com Subject: Re: L2F Organization: cisco Systems, Inc., Menlo Park, Ca. Cc: ietf-ppp@MERIT.EDU Resent-Message-ID: <"8YZKX.0.cO6.aPrKn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1375 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU In article <9602228275.AA827538916@smtplink.priacc.com> you write: > At the LA meeting, the L2F description of CHAP handling said that the > answering agent for a mobile caller would challenge the caller, and then > send the challenge and the response to the Home Agent for authentication. > > It seems to me this completely defeats the purpose of a challenge > authentication. If the host doesn't get to pick the challenge, what > prevents a bad guy from using a previously used, known good, challenge > and response? For example: > > I'm a bad guy, and I'm snooping traffic to the Home Agent. A > legitimate user calls in, and I see his challenge and his response get > authenticated by the Home Agent. Now I can present myself to the Home > Agent as a Foreign Agent, and I send the previously snooped challenge and > its response. I follow you right up through "Now I can present myself to the Home Agent as a Foreign Agent..." > It doesn't seem like much of a challenge if an attacker gets to pick > his own challenge. Am I understanding this correctly? -eric If you can create a tunnel management connection (or hijack one) you are correct, a CHAP playback attack is trivial. But the tunnel itself requires a chap-style authentication to bring up, and no MID management packets are to be received until tunnel authentication is complete. Your best bet is to hijack an existing tunnel. We've considered ways to deal with this, but even the best (signing each packet with the original key) starts to eat CPU far too quickly for comfort. Depending on the interest of the WG we may have to revisit this. -Tim Kolar cisco systems - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Mar 22 22:30:15 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id WAA28809; Fri, 22 Mar 1996 22:30:15 -0500 (EST) Resent-Date: Fri, 22 Mar 1996 22:30:15 -0500 (EST) Date: Fri, 22 Mar 1996 19:28:52 -0800 (PST) From: Andy Valencia Message-Id: <199603230328.TAA14431@vandys-lap.cisco.com> To: michel@priacc.com Cc: ietf-ppp@MERIT.EDU Subject: Re: L2F Newsgroups: cisco.external.ietf.ppp References: <9602228275.AA827538916@smtplink.priacc.com> X-Newsreader: NN version 6.5.0 #1 (NOV) Resent-Message-ID: <"8WZK41.0.v_6.O0tKn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1376 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU In cisco.external.ietf.ppp you write: > I'm a bad guy, and I'm snooping traffic to the Home Agent. To this point, the L2F protocol has not tried to protect against this. Even if we sign each packet--or encrypt it--the client is still at substantial risk. Once you accept snooping in the network infrastructure, you will quickly realize that taking over the NAS itself is a short step away (for instance, courtesy of a stolen admin TCP connection, even if said connection's authentication itself was protected against snooping, like K5). Although we saw that it was easy enough to add signatures and encryption to L2F, we also saw the scalability issues (as mentioned by my esteemed colleague). Since it didn't really solve the problem, we left it out. The only strong protection against this issue is end-to-end encryption, which many companies either offer now or will do so in the near future. If the modest increment in protection is of interest to the group, we'd be happy to look at adding it as an option. Regards, Andy Valencia - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Mar 25 06:26:57 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id GAA29723; Mon, 25 Mar 1996 06:26:57 -0500 (EST) Resent-Date: Mon, 25 Mar 1996 06:26:57 -0500 (EST) From: Ron Cohen To: ppp , "'Rob Friend'" Subject: LZS compression Date: Mon, 25 Mar 96 14:25:00 EST Message-ID: <31569132@smtp-gateway.rad.co.il> Encoding: 21 TEXT X-Mailer: Microsoft Mail V3.0 Resent-Message-ID: <"ZIm_S1.0.8G7.yAeLn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1377 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Hi I am new to this mailing list so I hope I don't ask a previously answered question: 'PPP Stac LZS Compression Protocol draft-ietf-pppext-stacker-06.txt' says: > When CCP has not successfully reached the Opened state, or LZS is not > the primary compression algorithm, exactly one LZS datagram is > encapsulated in the PPP Information field, where the PPP Protocol > field indicates type hex 4021 (Stac LZS). > Note that in the latter case, use of LZS is terminated by the PPP > LCP Protocol-Reject. Why is this special packet needed any how, if it is already known that LZS compression is not activated or is terminated on that link ? Thanks Ron ron@develop.rndmail.rad.co.il - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Mar 25 10:06:59 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id KAA05399; Mon, 25 Mar 1996 10:06:59 -0500 (EST) Resent-Date: Mon, 25 Mar 1996 10:06:59 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; cc: ietf-ppp@MERIT.EDU From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-pppext-netbios-fcp-07.txt Date: Mon, 25 Mar 96 09:54:12 -0500 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9603250954.aa15399@IETF.CNRI.Reston.VA.US> Resent-Message-ID: <"g5_gi1.0.0K1.BQhLn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1378 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --NextPart A Revised 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 : The PPP NetBIOS Frames Control Protocol (NBFCP) Author(s) : G. Pall Filename : draft-ietf-pppext-netbios-fcp-07.txt Pages : 14 Date : 03/22/1996 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols for establishing and configuring different network-layer protocols. The NBF protocol [3] was originally called the NetBEUI protocol. This document defines the Network Control Protocol for establishing and configuring the NBF protocol over PPP. The NBFCP protocol is only applicable for an end system to connect to a peer system or the LAN that peer system is connected to. It is not applicable for connecting two LANs together due to NetBIOS name limitations and NetBIOS name defense mechanisms. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-netbios-fcp-07.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-netbios-fcp-07.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (193.205.245.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) 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-netbios-fcp-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. For questions, please mail to Internet-Drafts@cnri.reston.va.us. 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: <19960322131024.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-netbios-fcp-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-netbios-fcp-07.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960322131024.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Mar 25 13:31:46 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id NAA12106; Mon, 25 Mar 1996 13:31:46 -0500 (EST) Resent-Date: Mon, 25 Mar 1996 13:31:46 -0500 (EST) Date: Mon, 25 Mar 1996 13:29:23 -0500 (EST) From: Ian Duncan X-Sender: iduncan@magnus2 To: Andy Valencia Cc: ietf-ppp@MERIT.EDU Subject: Re: L2F In-Reply-To: <199603230328.TAA14431@vandys-lap.cisco.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"ASLxb2.0.Yy2.oOkLn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1379 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU On Fri, 22 Mar 1996, Andy Valencia wrote: > To this point, the L2F protocol has not tried to protect against this. Even > if we sign each packet--or encrypt it--the client is still at substantial > Once you accept snooping in the network infrastructure, you will > quickly realize that taking over the NAS itself is a short step away (for > instance, courtesy of a stolen admin TCP connection, even if said > connection's authentication itself was protected against snooping, like K5). For moment let's imagine that the only permitted terminal access to the NAS is on a console port and generally admin is handled via SNMPv2u (or some other similar thing) and therefore securing the tunnel would raise the bar significantly. > If the modest increment in protection is of interest to the group, we'd be > happy to look at adding it as an option. If it doesn't bury other important goals in the noise I think it'd be a good idea. -- Ian Duncan Access Products Development Newbridge Networks Corp. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Mar 26 07:42:56 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id HAA08340; Tue, 26 Mar 1996 07:42:56 -0500 (EST) Resent-Date: Tue, 26 Mar 1996 07:42:56 -0500 (EST) Message-Id: <9603261245.AA0508@shivaportal.shiva.com> To: "'ietf-ppp@MERIT.EDU'" From: Craig Richards/Shiva Corporation Date: 25 Mar 96 13:37:14 Subject: Re: BACP - Call Status Indication Mime-Version: 1.0 Content-Type: Text/Plain Resent-Message-ID: <"JwAEM1.0.u12.BP-Ln"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1382 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU mgarti @ arrisnet.com (Mark Garti) @ SMTPMAIL writes: >What is the intended use of the Call Status Indication >message in the BAP? I see it having 2 uses. First of all, it makes the Call- and Callback-Requests start a transaction, and that transaction ends when the Call-Status-Indication is acknowledged (if the Call- or Callback-Response is an Ack). This will help in implementing BACP, so an implementation knows when some requested bandwidth was actually added, or if the peer has stopped trying to make a call. Also, I think it is a good thing to report call failures to the peer because it could be very useful for debugging phone line problems. Craig - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Mar 26 07:43:10 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id HAA08396; Tue, 26 Mar 1996 07:43:10 -0500 (EST) Resent-Date: Tue, 26 Mar 1996 07:43:10 -0500 (EST) Message-Id: <9603261245.AA0512@shivaportal.shiva.com> To: ietf-ppp From: Craig Richards/Shiva Corporation Date: 25 Mar 96 13:37:04 Subject: Re: E.164 & BAP Mime-Version: 1.0 Content-Type: Text/Plain Resent-Message-ID: <"5Drfk1.0.a22.LP-Ln"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1383 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU okorf @ netcs.com (Oliver Korfmacher) @ SMTPMAIL writes: >page 16, "Phone Number" >Please please add the E.164 format as an option for the phone number. >It exactly renders the (georgew@spider.co.uk (George Wilkie)) >requirement: >> P16 "Phone Number Sub-Options". >> Both the Unique Digits and Subscriber Number are "required". Only the >> sub address is optional. >> How about simplifying Phone-Number option to contain: >> >> Type | Length | Unique Digits | Subscriber Length | Subscriber Number >| Sub Length | Sub Address >ie lets define a string > "+countrycode.areacode.subscribernumber[-ext]" >eg > "+1.708/1235234" > "+49.6021/3095-77" >Every peer can simply calculate the number it has to dial >locally, using only locally known & significant PBX prefixes, >national/international needed escapes and so on. >For advanced needs, a regexp variant (with ?,*,[range]) may >be appropriate. >Gruesse, > Oliver Korfmacher (okorf@netcs.com, whois OK11 > URL: http://www.netcs.com/PEOPLE/okorf.html) I've been thinking about the phone number format. My current thoughts are that the phone number option is only meant to give the peer the unique digits that must be dialed in order to complete this call. How the original number (that the unique digits modify) is determined is outside the scope of BACP. Usually it will be the original number dialed, but it may also be determined from caller ID, from a callback protocol, pre-configured or determined in some other manner. No matter how the phone number is formatted, there will be issues about coming up with the correct number to be dialed. Although starting with an E.164 compliant phone number in Germany may easily translate into the correct number to be dialed, this is not always the case in the US. Since one link has already been established in order for BACP to be negotiated, then one side of the connection already knows the basic format of the phone number, and can just apply the changed digits to get the new phone number to dial. This is the approach used in the ISDN bonding spec, and I think it is the best approach to use in BAP, too. What does the list think of this approach? Craig - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Mar 26 07:42:55 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id HAA08334; Tue, 26 Mar 1996 07:42:55 -0500 (EST) Resent-Date: Tue, 26 Mar 1996 07:42:55 -0500 (EST) Message-Id: <9603261244.AA0486@shivaportal.shiva.com> To: ietf-ppp From: Craig Richards/Shiva Corporation Date: 25 Mar 96 13:38:17 Subject: Re: BACP-02.TXT Mime-Version: 1.0 Content-Type: Text/Plain Resent-Message-ID: <"ccyLD2.0.512.SO-Ln"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1380 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU jgardner @ BayNetworks.com (Jim Gardner) @ SMTPMAIL writes: >Comments on draft-ietf-pppext-bacp-02.txt: >1. Why must the Link Discriminator be mandatory? Is it so a peer >who receives a Link-Drop-Query-Request can stop transmitting over >a certain line, before its peer sends an LCP Terminate-Request? >I thought this was solved in Sec 4.1 Link Management? One reason is that the various links in a bundle may not have the same bandwidth, so it would be necessary to identify the specific link that would be dropped so the peer knows how much bandwidth would be removed from the bundle. Another reason is to prevent conflicts if another link is simultaneously removing a link from the bundle for other reasons. >2. If it is necessary to indeed have the Link Discriminator option, >it should be longer than 16 bits. Here's why: Some vendors use the >Authentication Protocol, CHAP or PAP, to identify which circuit a >line belongs to on the incoming side of a call. As you know, >Authentication happens after negotiation of LCP options, so it is >impossible to know which circuit a line will end up belonging to. >It would be possible to use a boxwide unique line number for each PPP line >configured in a box, however 32 bits or more may be required to do this. So you're saying you have more than 65000 ports on one box? >3. Section 4.4 is too complex and too vague. What exactly is the username? >Is it a peer's Chap Name or PAP ID? Recognizing as George Wilkie stated: >"the endpoint discriminator and authentication are both optional." You can't >rely on of the values being present for comparison. >Scott Jackson had replied: >"Now that the Link-Discriminator is mandatory it can also be used to determine >the favoured system, since each implementation negotiates independent values." >But Sec 2.1 p.2 Link-Discriminator says: >"The discriminator is independent for each peer, so each link may have 2 >different LCP Link-Discriminator values, one for each peer." >This seems to indicate each peer could come up with the SAME Link-Discriminator, >therefore breaking the comparison. >I like George Wilkie's idea of favoring the initializer of the first link, >which is reliable,(nothing to compare and no requirement of Link-Discriminator). Unfortunately, this is not 100% reliable, as both peers may initiate a call at the same time, resulting in 2 links in the bundle. Are there really that many implementations that don't implement either authentication or endpoint discriminator? >4. Why is the Response Code, Request-Rej, of Sec 4.5 p. 9 necessary? On the >previous page the second paragraph reads: >"All of the BAP datagrams MUST be supported by an implementation." >This indicates that all Request commands must be implemented... That doesn't mean that an implementation needs to support the underlying functionality. For example, an implementation may not implement callback functionality. >5. In a Call-Request Sec 4.5.1 p. 10, it is stated: "The options field must >include the Link-Type option." Shouldn't this also be the case for a >Callback-Request Sec 4.5.3 p. 11? > Sec 5.1 p. 13, says it MUST be included in Call- or Callback-Request. > Also, Appendix lists Link-Type as a mandatory option for Callback Request. Thanks for pointing this out - it MUST be included for Callback-Request. >6. Is it necessary for an implementation to send a Call-Status-Indication, >Sec 4.5.7 p. 12, even when a call is successful? Why? It seems like redundant >information. Will implementations be able to figure out which incoming call matches which Call or Callback-Request? This might not be so easy if there are multiple Call-Requests outstanding, as well as multiple phone numbers on each Call-Request. The Call-Status-Indication makes a one to one mapping between a Call-Request and a successful call. >7. If multiple Phone-Number options Sec 5.2 p 15, appear in a Response, >should any preference be placed upon them? IE: should the first one be >tried first, etc? I see no reason to make this a requirement. >8. Appendix p. 20, should list Phone-Number as a mandatory field for Callback- >Request. Yes, you're right. >9. There is a risk of thrashing when one side is monitoring Transmit and >its peer is monitoring Receive. The Receive's side monitoring may consider >the bundle to be congested, while the Transmit's side does not. So the >Receive monitoring side sends a Call-Request to the peer. Unless the peer >Naks the request based upon its Transmit monitoring, a new line will be added >to the bundle. The next second, the side monitoring Transmit, believing >congestion is not occurring, sends a Link-Drop-Query-Request. The peer >receives it and because it "MUST base its response on its transmit heuristics", >it agrees to drop the link...Then it starts over again. >It should be stated that an implementation which receives a Call- Callback >Request should Nak the Request if its Transmit monitoring (transmit heuristics), >indicates the bundle is uncongested. An implementation that only monitors Receive traffic is not BACP compliant. I don't think any changes are needed in this area, although I'm sure some of the descriptions and explanations could be improved. >10. I realize an attempt is being made to slim the content of BACP but I >wanted to throw this out anyway... >It would be nice for each end of the bundle to know what type of monitoring >its peer was performing: Transmit, Receive, both, or neither. >It would also be nice to know the maximum/minimum number of links either >peer wishes to be included in the bundle. >If a peer knew it was the only side monitoring, and the number of >links was greater than the number its peer required, it could choose to skip >sending a Link-Drop-Query-Request when removing link(s). >If the monitoring side knew its peer could have a maximum of 2 links for a >particular circuit, it could know not to bother sending a Call- Callback >Request under congested conditions. >If a peer knew that both sides were monitoring Transmit and Receive, one side, >perhaps a CPU bound piece of hardware, could negotiate to not monitor at all. >Or both sides could opt to monitor Transmit only. This kind of information could be sent as a configuration option during BACP negotiation. Can anyone on the list make a convincing argument for adding this kind of information? Craig - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Mar 26 07:43:15 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id HAA08412; Tue, 26 Mar 1996 07:43:15 -0500 (EST) Resent-Date: Tue, 26 Mar 1996 07:43:15 -0500 (EST) Message-Id: <9603261245.AA0514@shivaportal.shiva.com> To: ietf-ppp From: Craig Richards/Shiva Corporation Date: 25 Mar 96 13:36:41 Subject: Re: BACP draft 02 comments Mime-Version: 1.0 Content-Type: Text/Plain Resent-Message-ID: <"quufW3.0.-22.RP-Ln"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1384 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU received from: georgew @ spider.co.uk (George Wilkie) @ SMTPMAIL >The action taken following receipt of a Link-Drop-Query-Response is >inconsistent: P4, sec 4.1, para 3 says "should then issue an LCP >Terminate-Request" whereas P11, sec 4.5.5 says "MUST initiate tear down". >I prefer "SHOULD" as this allows an implementation the flexibility to change >its mind based on up-to-date transmit knowledge. I think this must be "MUST", otherwise there will be confusion by the other peer about why the link wasn't removed. If we make this "SHOULD", how can the other peer be informed that an implementation changed its mind? >I think Race Conditions needs more clarification (P7, sec 4.4). >According to RFC 1717 sec 5.1.3, the endpoint discriminator and authenication >are both optional. How about modifing so that endpoint discriminators >are compared if usernames are equal OR remote username not known >and if endpoint discriminators are equal (is this possible?) OR not known >then favour the system which made the call to add the first link to the bundle. The problem with using the initiator of the first link of the bundle, is that it isn't completely deterministic. It is possible that both sides called each other at the same time, bringing up 2 links of a multilink bundle simultaneously. >P9 "Identifier". I find the text "as well as which links are added or removed" >confusing. Remove it. OK, will do. >P12 Call-Status-Indication and Response. >I don't think these are necessary to fulfil the protocol's goals. >Remove them or make transmission of Call-Status-Indication optional >(as is transmission of Link-Drop-Query-Request). Although I agree that Call-Status-Indication is not absolutely necessary, I think it is a good thing. First of all, it makes the Call- and Callback-Requests start a transaction, and that transaction ends when the Call-Status-Indication is acknowledged. Also, I think it is a good thing to report call failures to the peer, it could be very useful for debugging phone line problems. >P14 "Link Type" >Perhaps this should be clarified with "at least one bit MUST be set". Except when using a phone type that is not in the list. >P16 "Phone Number Sub-Options". >Both the Unique Digits and Subscriber Number are "required". Only the >sub address is optional. >How about simplifying Phone-Number option to contain: >Type | Length | Unique Digits | Subscriber Length | Subscriber Number | >Sub Length | Sub Address This is a possibility, but I'd rather not spec it out like this until consensus has been reached that the current fields are the right ones to have in the ph one number option. Craig - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Mar 26 07:42:54 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id HAA08328; Tue, 26 Mar 1996 07:42:54 -0500 (EST) Resent-Date: Tue, 26 Mar 1996 07:42:54 -0500 (EST) Message-Id: <9603261244.AA0490@shivaportal.shiva.com> To: ietf-ppp Cc: cobb , jd , johnson , petry , john , jtaarud , trumbo , worrells From: Craig Richards/Shiva Corporation Date: 25 Mar 96 13:37:56 Subject: -No Subject- Mime-Version: 1.0 Content-Type: Text/Plain Resent-Message-ID: <"yZYSp3.0.O12.oO-Ln"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1381 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU michel @ priacc.com @ SMTPMAIL writes: >Section 4.2, "Bandwidth Management": >------------------------------------ >Given the concern about document length expressed at the LA meeting, I >think we should delete everything from the last sentence of the 1st >paragraph through the 6th paragraph. This whole page of text distracts from >the protocol itself. We should replace the last paragraph with this: > A BAP implementation may monitor its transmit traffic, both transmit > and receive traffic, or choose not to monitor traffic in either > direction. An implementation MUST NOT base its response to a > Link-Drop-Query-Request on its receive traffic, because the initiator > of the request clearly knows more about its future transmit traffic > than the responder can know. Server systems SHOULD implement > bi-directional monitoring and single-user dialin clients MAY > implement any type of monitoring. This will allow client BAP > implementations that require minimal end- user configuration. I agree this section should be shortened. I'll take this into consideration for the next draft. >Section 5.1:, "Link Type" field: >-------------------------------- >We should say that an implementation MAY leave all bits cleared. With >the current definitions, and something like switched 56, I must >either lie, or be allowed to leave all bits cleared. Leaving them all >cleared also allows for future call types not yet defined in the protocol. Do you want a bit for switched digital (non-ISDN)? If so, how should it be documented? >Also, I think "Bit 0 of the Link Type field corresponds to bit 32..." should say >"Bit 0 of the Link Type field corresponds to bit 7...." Thanks for pointing this out. >Section 5.2, "Phone-number", "Description": >---------------------------- >The sentence > The Phone-Number option MUST appear in a Callback-Request if the > Response Code is set to Request-Ack. >should say > The Phone-Number option MUST appear in a Callback-Request. Yes. >Section 5.2.1, Subscriber Number: >--------------------------------- >I still don't see how an implementation can make sense of a phone >number whose format is not specified. From discussions at the >meeting, I understand a wish to allow a pre-configured number to be >sent, where the receiver simply dials it without question. (This is >because some areas now have confusing dialing rules. For example, in >some areas, some exchanges *in your own area code* require you to >dial the area code+number, whereas other exchanges in your area code >do NOT allow you to dial the area code. This is very difficult to >automate, but fairly easy to manually configure.) But the solution to >this dilemma is NOT to say the format of a Subscriber Number is >unspecified (i.e., unusable in some cases). >One solution is to simply have 2 suboption choices: one is a "pre-configured >number," where the receiver is not to interpret it in any way. The other >suboption is a canonical form: E.164, which allows an implementation to know >its own dialing rules, and dial appropriately. I've talked about the phone number option in another e-mail. What do you think? >Section 5.6, "Action" description: >---------------------------------- >There are currently 3 actions: no retry, retry same number, retry >"next number in list." Why do we want to be so specific about what number >we will retry? One reason for allowing multiple phone numbers is that a >certain caller may not have access to some phone numbers. So while an >implementation may want to try a different number, it may not be the >"next number in list." It could be another number. How about if we >reduce the actions to 2: no retry, and retry? I don't have a problem with this. >Mechanical changes >------------------ >Section 4.1, par. 3, sentences 2 & 3: "Drop-Link-..." should be >"Link-Drop-...". Thanks for pointing this out. Craig - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Mar 26 08:08:59 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id IAA10685; Tue, 26 Mar 1996 08:08:59 -0500 (EST) Resent-Date: Tue, 26 Mar 1996 08:08:59 -0500 (EST) Message-Id: <9603261304.AA03132@queenbee.spider.co.uk> From: angusg@spider.co.uk (Angus Grossart) Date: Tue, 26 Mar 1996 13:04:11 +0000 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: ietf-ppp@MERIT.EDU Subject: L2F Standard Resent-Message-ID: <"mJW3v1.0.hc2.cn-Ln"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1385 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Hello all, I am concerned about the interoperability issues associated with the L2F specification as it stands. As specified, LCP and authentication is not performed end to end across the tunnel, instead the ISP's PPP state machine is effectively shunted to the home gateway. Page 6, sect 2.3, para 9 states "copy of LCP CONFACKs.....the home gateway may use this information to intialize its own PPP state". I think initialising the home gateways PPP state machine based on the remote user and ISP negotiation will cause problems. For example, what if the initial remote user and ISP dialog results in a user option(eg compression ) being rejected. Even if the home gateway supports this option, the LCP will never be renegociated and the option never used. "or it may choose to initiate a new LCP CONFREQ exchange" should be changed to "MUST initiate a new LCP CONFREQ exchange" and the above is resolved. Having true end to end negociation fits the PPP model better. Regards Angus -- Angus Grossart, Shiva Edinburgh, Stanwell Street Edinburgh, Scotland, EH6 5NG Email: angusg@europe.shiva.com Telephone: +44-0131-555-5166 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Mar 26 08:40:34 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id IAA12082; Tue, 26 Mar 1996 08:40:34 -0500 (EST) Resent-Date: Tue, 26 Mar 1996 08:40:34 -0500 (EST) Sender: okorf@netcs.com Message-Id: <3157F487.2A77@netcs.com> Date: Tue, 26 Mar 1996 14:43:35 +0100 From: Oliver Korfmacher Organization: NetCS Informationstechnik GmbH X-Mailer: Mozilla 2.0 (X11; I; SunOS 5.5 sun4m) Mime-Version: 1.0 To: Craig Richards/Shiva Corporation Cc: ietf-ppp Subject: Re: BACP-02.TXT References: <9603261244.AA0486@shivaportal.shiva.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"stEuW1.0.Wy2.EF_Ln"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1386 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Craig, perhaps my comment about page 16, "Phone numbers" didn't get thru? Again: --------------------------------------------- page 16, "Phone Number" Please please add the E.164 format as an option for the phone number. It exactly renders the (georgew@spider.co.uk (George Wilkie)) requirement: > P16 "Phone Number Sub-Options". > Both the Unique Digits and Subscriber Number are "required". Only the > sub address is optional. > How about simplifying Phone-Number option to contain: > > Type | Length | Unique Digits | Subscriber Length | Subscriber Number >| Sub Length | Sub Address ie lets define a string "+countrycode.areacode.subscribernumber[-ext]" eg "+1.708/1235234" "+49.6021/3095-77" Every peer can simply calculate the number it has to dial locally, using only locally known & significant PBX prefixes, national/international needed escapes and so on. For advanced needs, a regexp variant (with ?,*,[range]) may be appropriate. Gruesse, Oliver Korfmacher (okorf@netcs.com, whois OK11 URL: http://www.netcs.com/PEOPLE/okorf.html) - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Mar 26 10:00:18 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id KAA14831; Tue, 26 Mar 1996 10:00:18 -0500 (EST) Resent-Date: Tue, 26 Mar 1996 10:00:18 -0500 (EST) Date: Tue, 26 Mar 1996 09:48:46 -0500 (EST) From: John Shriver Message-Id: <199603261448.JAA27418@shiva-dev.shiva.com> To: okorf@netcs.com CC: crichards@shiva.com, ietf-ppp@MERIT.EDU In-reply-to: <3157F487.2A77@netcs.com> (message from Oliver Korfmacher on Tue, 26 Mar 1996 14:43:35 +0100) Subject: Re: BACP-02.TXT Resent-Message-ID: <"Ha2AS1.0.Rd3.yP0Mn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1387 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Date: Tue, 26 Mar 1996 14:43:35 +0100 From: Oliver Korfmacher [...] ie lets define a string "+countrycode.areacode.subscribernumber[-ext]" eg "+1.708/1235234" "+49.6021/3095-77" Every peer can simply calculate the number it has to dial locally, using only locally known & significant PBX prefixes, national/international needed escapes and so on. In Europe, what you say probably does apply. In the US, it most definitely doesn't. The "rules" for how to dial vary on a state by state basis, as dialing rules are (most unfortunately) set by 50 state Public Utilities Commissions, who regulate the US phone companies. In some states (or cities), if a call would be billed as a toll (non-local) call, the caller must dial 1 (our long distance prefix) first. This is so little old widows won't bankrupt themselves by making a "long distance" phone call and not knowing that they are doing so. (The state PUC's are generally obsessed with protecting little old widows. Some states also have enormous cross-subsidies to offer them very low cost basic phone service.) This dial 1 first for long-distance will apply even when the called number is in the same area code. However, whether the area code goes between the 1 and the subscriber number varies by state, or even by city. There are many other forms of dialing madness in the US phone system. Moreover, if you dial non-required prefixes, your call will NOT go through. Adding the long distance prefix 1 when not required will get you a reorder, as will adding the area code when not required. The US would be MUCH better off if Bellcore were in charge of dialing rules, and there was one set of them for the US. (Forget about the ITU-T, an organ of the United Nations, ever being allowed to do such a thing!) Also, in your E.164 format, how would you present the two area codes in France, 1 and "nil"? Just run the ./ together in the "nil" case? - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Mar 26 10:22:51 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id KAA15566; Tue, 26 Mar 1996 10:22:51 -0500 (EST) Resent-Date: Tue, 26 Mar 1996 10:22:51 -0500 (EST) From: Karl Fox Date: Tue, 26 Mar 96 10:22:02 -0500 Message-Id: <9603261522.AA00242@gefilte.MorningStar.Com> To: ietf-ppp@MERIT.EDU Subject: NetBIOS Frames Control Protocol (NBFCP) - Working Group Last Call Reply-To: Karl Fox Organization: Ascend Communications Resent-Message-ID: <"K8SzP3.0.uo3.7l0Mn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1388 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU This is last call. I will advise the area director that we want to take the NetBIOS Frames Control Protocol to Proposed Standard on April 9, unless there is substantive comment raised on the list. -- Karl Fox, servant of God, employee of Ascend Communications +1 614 451 1883 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 800 558 7827 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Mar 26 10:39:38 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id KAA16239; Tue, 26 Mar 1996 10:39:38 -0500 (EST) Resent-Date: Tue, 26 Mar 1996 10:39:38 -0500 (EST) Date: Tue, 26 Mar 1996 07:39:23 -0800 (PST) From: Andy Valencia Message-Id: <199603261539.HAA23123@vandys-lap.cisco.com> To: angusg@spider.co.uk Cc: ietf-ppp@MERIT.EDU Subject: Re: L2F Standard Newsgroups: cisco.external.ietf.ppp References: <9603261304.AA03132@queenbee.spider.co.uk> X-Newsreader: NN version 6.5.0 #1 (NOV) Resent-Message-ID: <"ufro61.0.Sz3.r-0Mn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1389 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU In cisco.external.ietf.ppp you write: >I am concerned about the interoperability issues associated with the L2F >specification as it stands. Your subject line says "L2F Standard". Note that this is a *draft*. The IETF secretary is very strict about this. :-) >As specified, LCP and authentication is not performed end to end across the >tunnel, instead the ISP's PPP state machine is effectively shunted to the >home gateway. Yes. >Page 6, sect 2.3, para 9 states "copy of LCP CONFACKs.....the home gateway may >use this information to intialize its own PPP state". >I think initialising the home gateways PPP state machine based on the remote >user and ISP negotiation will cause problems. For example, what if the >initial remote user and ISP dialog results in a user option(eg compression ) >being rejected. Even if the home gateway supports this option, the LCP will >never be renegociated and the option never used. We're talking AC and P compression (CCP runs above, not an issue)? Well, this *could* happen, but it's pretty far-fetched. The ISP is in the business of providing bandwidth, after all. The other way around is also questionable--it'd be hard to find a surviving access server vendor who didn't do this basic level of compression. >"or it may choose to >initiate a new LCP CONFREQ exchange" should be changed to "MUST initiate a >new LCP CONFREQ exchange" and the above is resolved. One of the primary goals of L2F was to establish the tunnel transparently. I wanted to leave open the "more rounds of LCP" simply to handle very simple terminal servers on the front end (who didn't have what it took to capture and forward the CONFACKs), and simple Home Gateways (which didn't have code to handle replay). The enormous majority of access servers will negotiate the same set of relatively efficient options. Why penalize everybody for the fraction remaining? Instead, we allow the intrusive mode for the minority. >Having true end to end negociation fits the PPP model better. Having a single round of negotiation is safer. Providers are pretty skeptical of these techniques, but when you sit them in front of a line analyzer and ask them to tell you which time was L2F and which time was a local login--and they can't--they start to believe. Access servers have gotten pretty good, but there are still lots of clients out there who don't do the right thing when faced with additional rounds of CHAP or LCP. So the L2F burdens the access server in order to minimize the demands on the clients. Now, if you can capture PPP LCP negotiation from a major ISP, and show me a part of it which wouldn't work when projected onto a Home Gateway configured in a "reasonable" manner (i.e., allow compression if requested, I don't know what other options you worry about), then I'll be very interested. But our own homework has shown us that it's going to work quite well with monotonous regularity. Regards, Andy Valencia - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Mar 26 10:47:45 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id KAA16613; Tue, 26 Mar 1996 10:47:45 -0500 (EST) Resent-Date: Tue, 26 Mar 1996 10:47:45 -0500 (EST) Date: Tue, 26 Mar 1996 10:47:00 -0500 (EST) From: John Gregg Message-Id: <199603261547.KAA10126@shiva-dev.shiva.com> To: ietf-ppp@MERIT.EDU, karl@ascend.com Subject: Re: NetBIOS Frames Control Protocol (NBFCP) - Working Group Last Call Resent-Message-ID: <"ofj8U1.0.I34.S61Mn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1390 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Looking at draft 07, I note that section 2.3 (NetBIOS Name Defense) is drastically shorter now. It just says: 2.3 NetBIOS Name Defense In order to guarantee uniqueness of NetBIOS Names on the network, NBFCP requires that peers negotiate the Name-Projection configuration option. This seems to imply that both sides must negotiate Name-Projection, even though really only the end system should, at least as far as I understand. Is this correct? -John Gregg Shiva Corp. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Mar 26 10:59:43 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id KAA17519; Tue, 26 Mar 1996 10:59:43 -0500 (EST) Resent-Date: Tue, 26 Mar 1996 10:59:43 -0500 (EST) Message-ID: <01BB1B03.482D49C0@pon-mi3-22.ix.netcom.com> From: Brad Wilson To: "'ietf-ppp@merit.edu'" Subject: US Dialing rules (was Re: BACP-02.TXT) Date: Tue, 26 Mar 1996 10:58:04 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Resent-Message-ID: <"tJ86r1.0.MH4.gH1Mn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1391 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >> In some states (or cities), if a call would be billed as a toll >> (non-local) call, the caller must dial 1 (our long distance prefix) >> first. True. Here in MI we have "zone" calls, which are calls which are direct dialed (no 1, no area code), yet are billed as long distance calls. >> This dial 1 first for long-distance will apply even when the called >> number is in the same area code. However, whether the area code goes >> between the 1 and the subscriber number varies by state, or even by >> city. This used to be true, but I am under the impression that we've pretty much standardized, due to the fact that we now have area codes that don't "look" like area code (ie, with a 0 or 1 in the middle digit). >> Moreover, if you dial non-required prefixes, your call will NOT go >> through. Adding the long distance prefix 1 when not required will get >> you a reorder, as will adding the area code when not required. I also think this has changed a lot. Here, if you _don't_ dial the 1 when it's necessary, you'll definitely incur a recording. However, I can dial 1+AC+number with local numbers and it will go through, and it will not be billed as a long distance. -- Brad Wilson, Crucial Software crucial@ix.netcom.com +1 (810) 620-9803 Custom software engineering services for Microsoft Windows NT and Windows 95 "Sometimes hate and love serve exactly the same purpose." - Lestat - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Mar 26 11:23:34 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id LAA18969; Tue, 26 Mar 1996 11:23:34 -0500 (EST) Resent-Date: Tue, 26 Mar 1996 11:23:34 -0500 (EST) X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 26 Mar 1996 08:23:00 -0800 To: ietf-ppp@MERIT.EDU From: fred@cisco.com (Fred Baker) Subject: Re: NetBIOS Frames Control Protocol (NBFCP) - Working Group Last Call Resent-Message-ID: <"gjS053.0.0e4.vd1Mn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1392 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU At 10:22 AM 3/26/96, Karl Fox wrote: >This is last call. I will advise the area director that we want to >take the NetBIOS Frames Control Protocol to Proposed Standard on April >9, unless there is substantive comment raised on the list. For those that may not recall, yours truly let this one slip through a crack somewhere. It should have gone to the IESG (in fact, I think it did and slipped through a crack there as well) more than a year ago; it has aged out and been restored. Currently, as I recall, there are at least two interoperable implementations: Microsoft's and Shiva's. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= It has recently been discovered that research causes cancer in rats. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Mar 26 11:37:08 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id LAA19617; Tue, 26 Mar 1996 11:37:08 -0500 (EST) Resent-Date: Tue, 26 Mar 1996 11:37:08 -0500 (EST) Sender: okorf@netcs.com Message-Id: <315817F5.2D01@netcs.com> Date: Tue, 26 Mar 1996 17:14:46 +0100 From: Oliver Korfmacher Organization: NetCS Informationstechnik GmbH X-Mailer: Mozilla 2.0 (X11; I; SunOS 5.5 sun4m) Mime-Version: 1.0 To: ietf-ppp@MERIT.EDU Subject: Re: E.164 & BAP References: <9603261245.AA0512@shivaportal.shiva.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"NX02P.0.Fo4.lq1Mn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1393 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Thanks to Craig & Johns comments, the the american way of dialing is clear to me:-) Weird. So what do all of you think of: Option a) the original delta method of Craig or b), a fully specified E.164 string (clearly distinguishable as it always starts with a '+'). In Europe, the E.164 approach is really reasonable, in my opinion. Craig Richards/Shiva Corporation wrote: > > I've been thinking about the phone number format. My current thoughts are that > the phone number option is only meant to give the peer the unique digits that > must be dialed in order to complete this call. How the original number (that > the unique digits modify) is determined is outside the scope of BACP. Usually > it will be the original number dialed, but it may also be determined from > caller ID, from a callback protocol, pre-configured or determined in some other > manner. > > No matter how the phone number is formatted, there will be issues about coming > up with the correct number to be dialed. Although starting with an E.164 > compliant phone number in Germany may easily translate into the correct number > to be dialed, this is not always the case in the US. Since one link has > already been established in order for BACP to be negotiated, then one side of > the connection already knows the basic format of the phone number, and can just > apply the changed digits to get the new phone number to dial. This is the > approach used in the ISDN bonding spec, and I think it is the best approach to > use in BAP, too. > > What does the list think of this approach? > > Craig > and John Shriver wrote: > > Date: Tue, 26 Mar 1996 14:43:35 +0100 > From: Oliver Korfmacher > > [...] > > ie lets define a string > > "+countrycode.areacode/subscribernumber[-ext]" (. -> /) > eg > "+1.708/1235234" > "+49.6021/3095-77" > > Every peer can simply calculate the number it has to dial > locally, using only locally known & significant PBX prefixes, > national/international needed escapes and so on. > > In Europe, what you say probably does apply. In the US, it most > definitely doesn't. The "rules" for how to dial vary on a state by > state basis, as dialing rules are (most unfortunately) set by 50 state > Public Utilities Commissions, who regulate the US phone companies. > > In some states (or cities), if a call would be billed as a toll > (non-local) call, the caller must dial 1 (our long distance prefix) > first. This is so little old widows won't bankrupt themselves by > making a "long distance" phone call and not knowing that they are > doing so. (The state PUC's are generally obsessed with protecting > little old widows. Some states also have enormous cross-subsidies to > offer them very low cost basic phone service.) > > This dial 1 first for long-distance will apply even when the called > number is in the same area code. However, whether the area code goes > between the 1 and the subscriber number varies by state, or even by > city. > > There are many other forms of dialing madness in the US phone system. > > Moreover, if you dial non-required prefixes, your call will NOT go > through. Adding the long distance prefix 1 when not required will get > you a reorder, as will adding the area code when not required. > > The US would be MUCH better off if Bellcore were in charge of dialing > rules, and there was one set of them for the US. (Forget about the > ITU-T, an organ of the United Nations, ever being allowed to do such a > thing!) > > Also, in your E.164 format, how would you present the two area codes > in France, 1 and "nil"? Just run the ./ together in the "nil" case? Yes. And as in Hongkong, for example, w/o area code. Oliver - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Mar 26 12:30:49 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id MAA21405; Tue, 26 Mar 1996 12:30:49 -0500 (EST) Resent-Date: Tue, 26 Mar 1996 12:30:49 -0500 (EST) Date: Tue, 26 Mar 96 17:24:39 GMT Message-Id: <9603261724.AA04989@queenbee.spider.co.uk> From: Malcolm Campbell Subject: Re: L2F Standard To: Andy Valencia In-Reply-To: Andy Valencia's message of Tue, 26 Mar 1996 07:39:23 -0800 (PST) X-Mailer: Sendmail/Ream v5.1.23 (Vorsprung Dourish Technik) Phone: +44 131 554 9424 (Work) Cc: ietf-ppp@MERIT.EDU Resent-Message-ID: <"KkXs1.0.AC5.yb2Mn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1394 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > We're talking AC and P compression (CCP runs above, not an issue)? I think he was talking about CCP, but I dont think this was the main issue. > Now, if you can capture PPP LCP negotiation from a major ISP, and show me a > part of it which wouldn't work when projected onto a Home Gateway configured > in a "reasonable" manner (i.e., allow compression if requested, I don't know > what other options you worry about), then I'll be very interested. But our > own homework has shown us that it's going to work quite well with monotonous > regularity. The basic model is something like this (excuse the awful ASCII graphics): |------| |-----| |--------------| | User | ..... PPP ..... | ISP |..... tunnel .... | home gateway | |------| |-----| |--------------| And the sequence is something like: User connects to ISP, negotiates LCP, and authenticates to ISP. ISP uses the Users Name/Peerid to figure out where to set the tunnel up to ISP sets up the tunnel, and sends over the ACK's and Authentication data. Home gateway brings up PPP as if the ACKS/Authentication happened with it. NCP's etc are brought up between User and Home Gateway. This causes several problems.. 1) The user authenticates to the ISP. So either the home gateway has to accept whatever authentication the ISP does as secure enough (and live with those values being sent over the tunnel). The alternative is to re-authenticate. Since you may not wish to use the same authentication protocol the ISP negotiated, the best way to do so is to re-negotiate LCP - using the values in the CFAK's as hints as to what will be accepted. 2) The user wants to negotiate some LCP option with the gateway that the ISP doesnt support, or doesnt want to offer. They negotiate with the ISP, but the ISP wont accept the option. The connection comes up without it. There is no way for the user to force a renegotiation with the home gateway - unless they do something weird like wait for an NCP packet, then renegotiate LCP... There shouldnt need to be any special code in the user, the simple solution is for the home gateway to use those Acks as hints, and renegotiate LCP. Note that if the home gateway doesnt want to re-authenticate, it doesnt have to - it just renegotiates LCP without authentication this time. If Im misunderstanding something - please enlighten me. The draft uses vague language in places and Im unsure what is intended. --- Malcolm - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Mar 26 12:42:51 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id MAA21995; Tue, 26 Mar 1996 12:42:51 -0500 (EST) Resent-Date: Tue, 26 Mar 1996 12:42:51 -0500 (EST) To: ietf-ppp Subject: Re: E.164 & BAP In-Reply-To: Your message of "25 Mar 1996 13:37:04." <9603261245.AA0512@shivaportal.shiva.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 26 Mar 1996 09:41:57 -0800 Message-Id: <20403.827862117@dumbcat.sf.ca.us> From: Marco S Hyman Resent-Message-ID: <"vLNDn3.0.PN5.Mo2Mn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1395 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Craig Richards/Shiva Corporation writes: > to be dialed, this is not always the case in the US. Since one link has > already been established in order for BACP to be negotiated, then one side > of the connection already knows the basic format of the phone number, > and can just > apply the changed digits to get the new phone number to dial. This is the > approach used in the ISDN bonding spec, and I think it is the best approach > to use in BAP, too. > > What does the list think of this approach? I believe it to be the correct approach. You may want to consider changing the name "Phone Number" to "Phone Delta" or something to help convey the intended use. // marc - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Mar 26 12:53:59 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id MAA22659; Tue, 26 Mar 1996 12:53:59 -0500 (EST) Resent-Date: Tue, 26 Mar 1996 12:53:59 -0500 (EST) From: michel@priacc.com Date: Tue, 26 Mar 96 09:49:48 PST Message-Id: <9602268278.AA827862763@smtplink.priacc.com> To: ietf-ppp@MERIT.EDU Cc: cobb@priacc.com, jd@priacc.com, johnson@priacc.com, petry@priacc.com, john@priacc.com, jtaarud@priacc.com, trumbo@priacc.com, worrells@priacc.com Subject: Re: US Dialing rules (was Re: BACP-02.TXT) Resent-Message-ID: <"DU8R21.0.mX5.oy2Mn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1396 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU The unique digits phone number option only works if there exists same "basis number" on which to apply it. This is true for the original caller, but not the answerer. If we wish to keep the symmetric nature of BAP, we need some way for an answerer to originate a call, i.e., for an entity with no basis number to be able to dial. I think having an option for an implementation to send its peer a "preconfigured" phone number meets the needs of many of the wierd dialing cases. Such a number would be interpreted as an installation dependent format, likely configured by hand by system operators. Beyond that, all we do is also allow a canonical E.164 number, and let's all petition our PUCs to make the telephone system accept canonical North American numbers in all cases, even if its a local number. -Eric L. Michelsen, 3Com Primary Access - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Mar 26 13:24:28 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id NAA23965; Tue, 26 Mar 1996 13:24:28 -0500 (EST) Resent-Date: Tue, 26 Mar 1996 13:24:28 -0500 (EST) Date: Tue, 26 Mar 1996 10:24:04 -0800 From: Tim Kolar Message-Id: <199603261824.KAA12926@greatdane.cisco.com> To: malcolmc@spider.co.uk Subject: Re: L2F Standard Organization: cisco Systems, Inc., Menlo Park, Ca. Cc: ietf-ppp@MERIT.EDU Resent-Message-ID: <"cTXUm2.0.Bs5.NP3Mn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1397 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Hello Malcolm, A few minor comments... In article <9603261724.AA04989@queenbee.spider.co.uk> you write: > > [snip snip] > >User connects to ISP, negotiates LCP, and authenticates to ISP. This is more of a nit than anything, but there is no requirement that actual authentication be done at the ISP. The authentication information is sent from the client at this point mainly so that we can use the username to direct the tunnel to the correct destination. The ISP doesn't need to verify the password. Then, since we have the information anyways, it seems cleanest to pass it along rather than having the Home Gateway force a second authentication. Specifically we have in mind people who are using Smart Cards or other non-fixed passwords who may have to generate a second password if they are prompted again. However, if the client can handle a second authentication, there's no reason to necessarily pass the information to the gateway. As you note below, the Home Gateway is free to renegotiate the LCP completely, including reauthentication. Missing from the draft is an authentication type of "NONE" for MIDs. This should appear in the next version. You can do it implicitly now by specifying any of the authentication types and sending null data, but I think this needs to be more explicit. >ISP uses the Users Name/Peerid to figure out where to set the tunnel up to >ISP sets up the tunnel, and sends over the ACK's and Authentication data. >Home gateway brings up PPP as if the ACKS/Authentication happened with it. >NCP's etc are brought up between User and Home Gateway. Yes, this is intended sequence. >This causes several problems.. >1) The user authenticates to the ISP. So either the home gateway has to >accept whatever authentication the ISP does as secure enough (and live with >those values being sent over the tunnel). > >The alternative is to re-authenticate. Since you may not wish to use the same >authentication protocol the ISP negotiated, the best way to do so is to >re-negotiate LCP - using the values in the CFAK's as hints as to what will be >accepted. This was our intention, with the problems of smart cards noted above. > >2) The user wants to negotiate some LCP option with the gateway that >the ISP doesnt support, or doesnt want to offer. They negotiate with the >ISP, but the ISP wont accept the option. The connection comes up without it. >There is no way for the user to force a renegotiation with the home >gateway - unless they do something weird like wait for an NCP packet, then >renegotiate LCP... > >There shouldnt need to be any special code in the user, the simple solution >is for the home gateway to use those Acks as hints, and renegotiate LCP. > >Note that if the home gateway doesnt want to re-authenticate, it doesnt have >to - it just renegotiates LCP without authentication this time. This was also our intention, although I'd like to note that I'm with Andy on wanting to find a real case of this happening. Our experience with PPP has been that the negotiated LCP options are pretty standard in the ISP environment. >If Im misunderstanding something - please enlighten me. The draft uses vague >language in places and Im unsure what is intended. Unless I'm misunderstanding you in turn, you've read our intentions correctly. If you can point out parts of the RFC that you think need clearing up, we'd be most grateful. -Tim - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Mar 26 13:32:32 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id NAA24398; Tue, 26 Mar 1996 13:32:32 -0500 (EST) Resent-Date: Tue, 26 Mar 1996 13:32:32 -0500 (EST) Message-ID: From: Gurdeep Singh Pall To: "'ietf-ppp@MERIT.EDU'" , "'karl@ascend.com'" , "'John Gregg'" Subject: RE: NetBIOS Frames Control Protocol (NBFCP) - Working Group Last Call Date: Tue, 26 Mar 1996 10:31:59 -0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Resent-Message-ID: <"C6-fm3.0.qy5.oW3Mn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1398 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Good eye. It should say "... NBFCP requires end-system implementations to negotiate Name-Projection configuration option.". I'll update. Gurdeep >---------- >From: John Gregg[SMTP:jgregg@shiva.com] > >2.3 NetBIOS Name Defense > > In order to guarantee uniqueness of NetBIOS Names on the network, > NBFCP requires that peers negotiate the Name-Projection >configuration > option. > > This seems to imply that both sides must negotiate Name-Projection, >even though really only the end system should, at least as far as I >understand. Is this correct? > > > - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Mar 26 13:37:13 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id NAA24665; Tue, 26 Mar 1996 13:37:13 -0500 (EST) Resent-Date: Tue, 26 Mar 1996 13:37:13 -0500 (EST) To: ietf-ppp@MERIT.EDU Subject: Re: US Dialing rules (was Re: BACP-02.TXT) In-Reply-To: Your message of "Tue, 26 Mar 1996 09:49:48 PST." <9602268278.AA827862763@smtplink.priacc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 26 Mar 1996 10:36:11 -0800 Message-Id: <20623.827865371@dumbcat.sf.ca.us> From: Marco S Hyman Resent-Message-ID: <"2HWzq1.0.A16.Jb3Mn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1399 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU michel@priacc.com writes: > The unique digits phone number option only works if there exists same > "basis number" on which to apply it. This is true for the original > caller, but not the answerer. If we wish to keep the symmetric nature of > BAP, we need some way for an answerer to originate a call, i.e., for an > entity with no basis number to be able to dial. Experience says that you will be soundly beaten around the head and shoulders by customers if billing is not 100% deterministic. That is one of the reasons that the "initial caller places all calls" rule exists in the imux protocols. Forgetting about that... is the answerer supposed to have the entire world's dial plan encoded? Otherwise, how does the answerer know what is long distance access, country code, area code, etc., given the 50 different ways phone numbers can be coded within the US. How about things like PBX access, additional billing codes, and devices on private networks. That last one can be tricky -- sometimes it is impossible for the answerer to call in the other direction. Most of these problems go away if you follow the "initial caller places all calls" rule. // marc - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Mar 26 13:56:34 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id NAA25771; Tue, 26 Mar 1996 13:56:34 -0500 (EST) Resent-Date: Tue, 26 Mar 1996 13:56:34 -0500 (EST) Date: Tue, 26 Mar 1996 13:55:15 -0500 (EST) From: Ian Duncan X-Sender: iduncan@magnus2 To: Craig Richards/Shiva Corporation Cc: ietf-ppp Subject: Re: E.164 & BAP In-Reply-To: <9603261245.AA0512@shivaportal.shiva.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"6dSu6.0.SI6.Tt3Mn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1400 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU On 25 Mar 1996, Craig Richards/Shiva Corporation wrote: > I've been thinking about the phone number format. [...] > What does the list think of this approach? When subject came up at one of the sessions in LA (and in somewhat related discussion in a RADIUS WG session) it was pointed out that there was an LCP callback option that might provide a base model. To save on keystrokes, etc. -- the following is the relevant text from the current draft (draft-ietf-pppext-lcpext-ds-00.txt): || 2.2. Callback || || Description || || This Configuration Option provides a method for an implementation || to request a dial-up peer to call back. This option might be used || for many diverse purposes, such as savings on toll charges. [...] || A summary of the Callback Option format is shown below. The fields || are transmitted from left to right. || || 0 1 2 3 || 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 || +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ || | Type | Length | Operation | Message ... || +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ || || Type || || 13 || || Length || || >= 3 || || Operation || || The Operation field is one octet and indicates the contents of the || Message field. || || 0 location is determined by user authentication || || 1 Dialing string, the format and contents of which assumes || configuration knowledge of the specific device which is || making the callback. || || 2 Location identifier, which may or may not be human read- || able, to be used together with the authentication informa- || tion for a database lookup to determine the callback loca- || tion. || || 3 E.164 number. || || 4 Distinguished name. || || Message || || The Message field is zero or more octets, and its general contents || are determined by the Operation field. The actual format of the || information is site or application specific, and a robust imple- || mentation SHOULD support the field as undistinguished octets. The || size is determined from the Length field. || || It is intended that only an authorized user will have correct site || specific information to make use of the Callback. The codifica- || tion of the range of allowed usage of this field is outside the || scope of this specification. I can't imagine what's motivating the presence of the DN but other than that it seems to cover the territory. I've only recently restarted tracking the PPPEXT WG and don't know how extensively this LCP option has been beaten on. The basic question I have is, what's wrong with the way it's done in LCP callback and can we simply adopt this and move on? I seems to me that we only need/want one way to do this. -- Ian Duncan Access Products Development Newbridge Networks Corp. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Mar 26 14:13:40 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id OAA26767; Tue, 26 Mar 1996 14:13:40 -0500 (EST) Resent-Date: Tue, 26 Mar 1996 14:13:40 -0500 (EST) Message-Id: <199603261900.OAA03792@funk.com> X-Sender: ken@funk1.funk.com X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 26 Mar 1996 14:05:46 -0500 To: ietf-ppp@MERIT.EDU From: ken@funk.com (Ken Culbert) Subject: Re: E.164 & BAP Resent-Message-ID: <"1wSpo3.0.vX6.V74Mn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1402 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU 3, somewhat disjointed, comments: I think both the delta and E.164 approaches should be permitted. E.164 is the most open way to handle dialing. All that is required is for an implementation to have a dialing database of country codes, area codes, and exchanges which it uses to determine how to call the specified E.164 number. The database need not be too extensive, perhaps limited to local exchanges, area code and country code; but this approach is extensible, permitting, for example, different or alternate carriers to be specified for country and area codes. Delta dialing is the easier to implement. A somewhat new weirdness in American dialing is that there now may be multiple area codes _for the same city_. If a peer doesn't know its number (it may be on a rotary, for example), how can it specify a delta? Oliver Korfmacher wrote: >So what do all of you think of: > >Option a) the original delta method of Craig > >or b), a fully specified E.164 string (clearly distinguishable as it always >starts with a '+'). ============================================ Ken Culbert ken@funk.com Funk Software, Inc. voice: +1 617 497-6339 222 Third Street fax: +1 617 547-1031 Cambridge, MA 02142 http://www.funk.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Mar 26 14:00:34 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id OAA26069; Tue, 26 Mar 1996 14:00:34 -0500 (EST) Resent-Date: Tue, 26 Mar 1996 14:00:34 -0500 (EST) Message-Id: <199603261853.NAA03765@funk.com> X-Sender: ken@funk1.funk.com X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 26 Mar 1996 13:58:59 -0500 To: ietf-ppp@MERIT.EDU From: ken@funk.com (Ken Culbert) Subject: RE: NetBIOS Frames Control Protocol (NBFCP) - Working Group Last Call Resent-Message-ID: <"qwN4S3.0.3N6.Cx3Mn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1401 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Does this mean that the link must be terminated if the option isn't negotiated? If this is the case, it should read 'end-system implementations MUST negotiate the Name-Projection configuration option.' At 10:31 AM 3/26/96 -0800, Gurdeep Singh Pall wrote: >Good eye. It should say "... NBFCP requires end-system implementations >to negotiate Name-Projection configuration option.". > >I'll update. >Gurdeep >>---------- >>From: John Gregg[SMTP:jgregg@shiva.com] >> >>2.3 NetBIOS Name Defense >> >> In order to guarantee uniqueness of NetBIOS Names on the network, >> NBFCP requires that peers negotiate the Name-Projection >>configuration >> option. >> >> This seems to imply that both sides must negotiate Name-Projection, >>even though really only the end system should, at least as far as I >>understand. Is this correct? ============================================ Ken Culbert ken@funk.com Funk Software, Inc. voice: +1 617 497-6339 222 Third Street fax: +1 617 547-1031 Cambridge, MA 02142 http://www.funk.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Mar 26 14:46:28 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id OAA28513; Tue, 26 Mar 1996 14:46:28 -0500 (EST) Resent-Date: Tue, 26 Mar 1996 14:46:28 -0500 (EST) Message-Id: <199603261930.OAA03900@funk.com> X-Sender: ken@funk1.funk.com X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 26 Mar 1996 14:35:17 -0500 To: ietf-ppp From: ken@funk.com (Ken Culbert) Subject: Re: E.164 & BAP Cc: ietf-ppp Resent-Message-ID: <"5wzQF1.0.Hz6.Ec4Mn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1403 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU At 01:55 PM 3/26/96 -0500, Ian Duncan wrote: >When subject came up at one of the sessions in LA (and in somewhat >related discussion in a RADIUS WG session) it was pointed out that >there was an LCP callback option that might provide a base model. [...] >The basic question I have is, what's wrong with the way it's done in LCP >callback and can we simply adopt this and move on? I seems to me that we only >need/want one way to do this. The callback option is flawed because there is no way to know who the user is, and so to validate the user's callback request. Microsoft proposed a CallBack Control Protocol some time ago and has implemented it in NT, but the proposal expired. I'd like to see CBCP looked at again (Gurdeep?), but in any case, BACP uses callback for a different purpose: 'An implementation that wants its peer to originate another link to add to the multilink bundle MUST transmit a Callback-Request packet to its peer. This will inform the peer of the request to add another link to the bundle and will also inform the peer of the number to be called.' ============================================ Ken Culbert ken@funk.com Funk Software, Inc. voice: +1 617 497-6339 222 Third Street fax: +1 617 547-1031 Cambridge, MA 02142 http://www.funk.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Mar 26 19:02:04 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id TAA06618; Tue, 26 Mar 1996 19:02:04 -0500 (EST) Resent-Date: Tue, 26 Mar 1996 19:02:04 -0500 (EST) Message-ID: <01BB1B46.837898C0@pon-mi3-10.ix.netcom.com> From: Brad Wilson To: "ietf-ppp@MERIT.EDU" , "'Ken Culbert'" Subject: RE: E.164 & BAP Date: Tue, 26 Mar 1996 18:56:22 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Resent-Message-ID: <"x8PB81.0.wc1.8L8Mn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1404 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >> A somewhat new weirdness in American dialing is that there now may be >> multiple area codes _for the same city_. >> >> If a peer doesn't know its number (it may be on a rotary, for example), how >> can it specify a delta? I would hope that an IS department would thoroughtly thrash any local access carrier that gave rotary numbers in multiple area codes. I would, anyway. :-) -- Brad Wilson, Crucial Software crucial@ix.netcom.com +1 (810) 620-9803 Custom software engineering services for Microsoft Windows NT and Windows 95 "Sometimes hate and love serve exactly the same purpose." - Lestat - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 27 00:11:48 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id AAA13857; Wed, 27 Mar 1996 00:11:48 -0500 (EST) Resent-Date: Wed, 27 Mar 1996 00:11:48 -0500 (EST) To: "ietf-ppp@MERIT.EDU" Subject: Re: E.164 & BAP In-Reply-To: Your message of "Tue, 26 Mar 1996 18:56:22 EST." <01BB1B46.837898C0@pon-mi3-10.ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 26 Mar 1996 21:10:54 -0800 Message-Id: <26158.827903454@dumbcat.sf.ca.us> From: Marco S Hyman Resent-Message-ID: <"3qHu21.0.IO3.utCMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1405 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Brad Wilson writes: > >> A somewhat new weirdness in American dialing is that there now may be > >> multiple area codes _for the same city_. > >> > >> If a peer doesn't know its number (it may be on a rotary, for example), h > ow > >> can it specify a delta? > > I would hope that an IS department would thoroughtly thrash any > local access carrier that gave rotary numbers in multiple area > codes. I would, anyway. :-) True. But in any case a delta of "no digits" is perfectly acceptable in many cases. The caller in that case does not modify his initial dial number and winds up dialing the same number again. It is the simplest (and probably most common) way to set up a T1/PRI box. // marc - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 27 01:13:04 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id BAA15394; Wed, 27 Mar 1996 01:13:04 -0500 (EST) Resent-Date: Wed, 27 Mar 1996 01:13:04 -0500 (EST) From: stevek@dgii.com Date: Wed, 27 Mar 1996 06:11:42 GMT Message-Id: <199603270611.GAA23949@dgii.com> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Subject: Re: E.164 & BAP To: ken@funk.com (Ken Culbert), ietf-ppp In-Reply-To: <199603261930.OAA03900@funk.com> X-Mailer: SPRY Mail Version: 04.00.06.14 Resent-Message-ID: <"RW9RJ1.0.Gm3.fnDMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1406 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU On Tue, 26 Mar 1996, ken@funk.com (Ken Culbert) wrote: >The callback option is flawed because there is no way to know who the user >is, and so to validate the user's callback request. Microsoft proposed a >CallBack Control Protocol some time ago and has implemented it in NT, but >the proposal expired. I'd like to see CBCP looked at again (Gurdeep?), but >in any case, BACP uses callback for a different purpose: As I understand it, the CBCP standardization effort was dropped because the Danvers PPP WG felt it superflous -- you can simply negotiate LCP (w/o the callback option), authenticate, find out who's calling, then re-negotiate LCP, this time specifying callback. Renegotiating LCP is allowed at any time, but there are apparently a number of implementations that don't particularly like it. CBCP does have a negotiated option for the callback-delay, ie, how long does it take to turn your modem around. A value of 15 seconds or something works for most modems, but is torturous if you've got ISDN. At the Dallas WG, when we talked of advancing RFC1570 or portions of it, and came to the callback option, we discussed adding an option or additional field that could be used for callback-delay, but nothing further has been done. ------------------------------------------------------------------------ Steven A. Klein Digi International Voice: (310) 328-9700 stevek@dgii.com 2730 Monterey St. Suite 105 Fax: (310) 328-9696 Torrance, CA 90503 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 27 04:23:34 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id EAA19572; Wed, 27 Mar 1996 04:23:34 -0500 (EST) Resent-Date: Wed, 27 Mar 1996 04:23:34 -0500 (EST) Date: Wed, 27 Mar 96 09:18:19 GMT From: georgew@spider.co.uk (George Wilkie) Message-Id: <9603270918.AA06475@queenbee.spider.co.uk> In-Reply-To: Craig Richards/Shiva Corporation "Re: BACP draft 02 comments" (Mar 26, 1:02pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Craig Richards/Shiva Corporation Subject: Re: BACP draft 02 comments Cc: ietf-ppp@MERIT.EDU Resent-Message-ID: <"wNicc.0.Xn4.iZGMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1407 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Craig, > >The action taken following receipt of a Link-Drop-Query-Response is > >inconsistent: P4, sec 4.1, para 3 says "should then issue an LCP > >Terminate-Request" whereas P11, sec 4.5.5 says "MUST initiate tear down". > >I prefer "SHOULD" as this allows an implementation the flexibility to change > >its mind based on up-to-date transmit knowledge. > I think this must be "MUST", otherwise there will be confusion by the other > peer about why the link wasn't removed. If we make this "SHOULD", how can the > other peer be informed that an implementation changed its mind? The peer could assume so if the link wasn't dropped within a certain time. However, I'm happy with MUST. > > >I think Race Conditions needs more clarification (P7, sec 4.4). > >According to RFC 1717 sec 5.1.3, the endpoint discriminator and authenication > >are both optional. How about modifing so that endpoint discriminators > >are compared if usernames are equal OR remote username not known > >and if endpoint discriminators are equal (is this possible?) OR not known > >then favour the system which made the call to add the first link to the bundle. > The problem with using the initiator of the first link of the bundle, is that > it isn't completely deterministic. It is possible that both sides called each > other at the same time, bringing up 2 links of a multilink bundle > simultaneously. Would one of these initial links not be rejected by call-collision? If not, we need some way to make it deterministic. Maybe enough to clarify the call-collision section to say that implementations must be configured such at least one of username and/or endpoint discriminitor is known and different. > >P12 Call-Status-Indication and Response. > >I don't think these are necessary to fulfil the protocol's goals. > >Remove them or make transmission of Call-Status-Indication optional > >(as is transmission of Link-Drop-Query-Request). > Although I agree that Call-Status-Indication is not absolutely necessary, I > think it is a good thing. First of all, it makes the Call- and > Callback-Requests start a transaction, and that transaction ends when the > Call-Status-Indication is acknowledged. Also, I think it is a good thing to > report call failures to the peer, it could be very useful for debugging phone > line problems. > Ok, I can accept that failure indications could be useful for debugging. In fact, I misread the draft - I thought they were only used for failures :-) Could you clarify 4.5.7 Call-Status-Indication to add "whether or the call succeeded or failed" at the end of the 1st sentence and also modify the 2nd paragraph to say "Upon reception of a Call-Status-Indication packet which indicates a call failure, an implementation MAY log the status code, ..."? I'm still not sure though about the need for successful indications. It seems to add a lot of complications. Isn't the fact that a call gets established enough? When you say "transaction", does this mean that the link should not be used until the indication is received? What happens if the indication gets lost and the peer times out sending it? It seems to be easier if the call transaction completes when the call gets established or a call failure indication is received. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 27 04:44:53 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id EAA20094; Wed, 27 Mar 1996 04:44:53 -0500 (EST) Resent-Date: Wed, 27 Mar 1996 04:44:53 -0500 (EST) Date: Wed, 27 Mar 96 09:40:26 GMT From: georgew@spider.co.uk (George Wilkie) Message-Id: <9603270940.AA06527@queenbee.spider.co.uk> In-Reply-To: Craig Richards/Shiva Corporation "Re: E.164 & BAP" (Mar 26, 1:04pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Craig Richards/Shiva Corporation Subject: Re: E.164 & BAP Cc: ietf-ppp@MERIT.EDU Resent-Message-ID: <"iREM11.0.gv4.IuGMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1408 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Craig, > I've been thinking about the phone number format. My current thoughts are that > the phone number option is only meant to give the peer the unique digits that > must be dialed in order to complete this call. How the original number (that > the unique digits modify) is determined is outside the scope of BACP. Usually > it will be the original number dialed, but it may also be determined from > caller ID, from a callback protocol, pre-configured or determined in some other > manner. > This makes things much clearer for me. My worry with unique digits was that they may not be suitable to apply to the original number dialed when the new link was over a different circuit (e.g. dialup via ISDN). However applying the unique digits to a pre-configured circuit-specific number is straightforward. Perhaps you could re-word the 2nd paragraph in 5.2.1 Phone-Number Sub-Options to reflect what you say above rather than only mentioning the original number dialed? > What does the list think of this approach? > I think this is the simplest approach. It is easier to configure base phone number(s) than US dialing rules :-) - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 27 05:27:02 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id FAA21002; Wed, 27 Mar 1996 05:27:02 -0500 (EST) Resent-Date: Wed, 27 Mar 1996 05:27:02 -0500 (EST) Date: Wed, 27 Mar 1996 10:20:57 GMT From: Gerry Meyer Message-Id: <199603271020.KAA10899@orbweb.spider.co.uk> To: ietf-ppp@MERIT.EDU Subject: Re: E.164 & BAP Resent-Message-ID: <"ISexG2.0.w75.TVHMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1409 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU E164 Address? BAP does NOT need them. I've always thought that the phone number option's complexity is because it is trying to do two distinct things (which since I like short email message I won't bore anyone with here). The complexity ALL disappears if: - The end which made the first call, ALWAYS makes subsequent calls - because it DOES have a pretty fair idea of the number dialed. (and whichever end requires more bandwith makes an appropriate call- or callback- request). And it makes sense for billing. Then all that remains to sort is whether the called party is on a hunt group or not - which can be handled by a unique digits like option consisting of a length plus the actual unique digits. Length is zero if on a hunt group. Makeing this mandatory in the response packet allows us to get rid of the No-Phone-Number option (which was always a strangely inverted option). Gerry - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 27 08:17:20 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id IAA24725; Wed, 27 Mar 1996 08:17:20 -0500 (EST) Resent-Date: Wed, 27 Mar 1996 08:17:20 -0500 (EST) From: Ron Cohen To: ppp Subject: BAP Date: Wed, 27 Mar 96 16:16:00 EST Message-ID: <31594E5E@smtp-gateway.rad.co.il> Encoding: 16 TEXT X-Mailer: Microsoft Mail V3.0 Resent-Message-ID: <"Kc_g11.0.626.T_JMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1410 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Hi There is something basic which is not clear to me. . There are cases in which BA(C)P can be used without any regard to MP. For example when only one link is used in an on-demand basis between two devices, were each of the device may initiate the call according to some pre-configured traffic triggers. In this case there is sense sending Link-Drop-Query-Request before actualy hanging. My question is - can I use BA(C)P without MP as It seems unreasonable to negotiate MP on one link just for using BA(C)P. Ron ron@rndmail.rad.co.il - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 27 08:46:52 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id IAA25940; Wed, 27 Mar 1996 08:46:52 -0500 (EST) Resent-Date: Wed, 27 Mar 1996 08:46:52 -0500 (EST) Date: Wed, 27 Mar 96 13:42:15 GMT Message-Id: <9603271342.AA19223@queenbee.spider.co.uk> From: Malcolm Campbell Subject: Re: L2F Standard To: Tim Kolar In-Reply-To: Tim Kolar's message of Tue, 26 Mar 1996 10:24:04 -0800 X-Mailer: Sendmail/Ream v5.1.23 (Vorsprung Dourish Technik) Phone: +44 131 554 9424 (Work) Cc: ietf-ppp@MERIT.EDU Resent-Message-ID: <"CRMhu.0.1L6.9RKMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1411 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > >User connects to ISP, negotiates LCP, and authenticates to ISP. > > This is more of a nit than anything, but there is no requirement that > actual authentication be done at the ISP. The authentication information > is sent from the client at this point mainly so that we can use the username > to direct the tunnel to the correct destination. The ISP doesn't need > to verify the password. Are you suggesting that the authentication actually be done at the home gateway? Ie, with CHAP, a sequence like... User ISP Home Gateway <- Challenge Response -> (..... tunnel setup ...) (Challenge/Response pair) -> <--------------------------------- Success or Failure That way, the ISP gets the name, but the Home Gateway does the actual authentication. I think that method, if its what you were suggesting, resolves my concerns with Authentication - although the pair is still send over the network. A similar method could be used with PAP. > This was also our intention, although I'd like to note that I'm with > Andy on wanting to find a real case of this happening. Our experience with > PPP has been that the negotiated LCP options are pretty standard in the > ISP environment. Yes, but the end user doesnt want to talk PPP to the ISP, he wants to talk PPP to the Home Gateway. I can think of several options that MIGHT cause problems - let me give one example... The end user is using a Shiva client that wants to use SPAP to the home gateway. The ISP doesnt know anything about SPAP. So, the negotiation falls back to CHAP, or PAP. The tunnel is set up - then the home gateway (which can do SPAP - has no idea that end user wants it) - so the functionality that the user would expect to get from this, is unavailable. (Someone who knows SPAP might want to comment on this).. There may be other proprietary options.. Someone suggested to me there may be a problem with Endpoint Discriminator too, but again, this isnt something I know too well.. In any case, there may be proprietary options, less common options, or options to be added in the future - which the ISP may not support or wish to negotiate - that the Home Gateway wishes. The client _must_, in my opinion, be given the chance to request those from the home gateway. I can see two ways of doing this (another popped into my head last night): 1) Have the Home Gateway always renegotiate LCP. 2) Have the ISP forward the users initial configure request to the Home Gateway, as well as the ACKs. That allows the Home Gateway to see options that the user requested, but the ISP refused - so it can decide whether or not to renegotiate LCP. > If you can point out parts of the RFC that you think need clearing up, > we'd be most grateful. I'll do, along with some other people at Shiva Europe, in the next few days. (im working from home at the moment) --- Malcolm ------------------------- malcolmc@europe.shiva.com ------------------------- Malcolm Campbell, Project Consultant | Spider Software, Shiva Europe Ltd., Tel: +44 131 555 5166 | Shiva Park, Stanwell Street Fax: +44 131 555 0664 | Edinburgh, EH6 5NG, Scotland - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 27 09:52:54 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id JAA28045; Wed, 27 Mar 1996 09:52:54 -0500 (EST) Resent-Date: Wed, 27 Mar 1996 09:52:54 -0500 (EST) Date: Wed, 27 Mar 1996 09:51:34 -0500 (EST) From: Ian Duncan X-Sender: iduncan@magnus2 To: Ken Culbert Cc: ietf-ppp Subject: Re: E.164 & BAP In-Reply-To: <199603261930.OAA03900@funk.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"5nVOG1.0.Rr6.0OLMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1412 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU On Tue, 26 Mar 1996, Ken Culbert wrote: > At 01:55 PM 3/26/96 -0500, Ian Duncan wrote: > > >The basic question I have is, what's wrong with the way it's done in LCP > >callback and can we simply adopt this and move on? I seems to me that we only > >need/want one way to do this. > > The callback option is flawed [...] > in any case, BACP uses callback for a different purpose: It seems I was a bit unclear. The issue being discussed is how to represent the value(s) of a callback token. The LCP callback provides a particular model that's extensible along with a reasonable enumeration of options. Ignoring the larger discussion of LCP callback, what's wrong with the model and more particularly the specific representation including the assigned enumeration? -- Ian Duncan Access Products Development Newbridge Networks Corp. PS: Have you looked at the full text on Callback in the current draft WRT to the lack of user identity? - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 27 10:29:06 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id KAA29284; Wed, 27 Mar 1996 10:29:06 -0500 (EST) Resent-Date: Wed, 27 Mar 1996 10:29:06 -0500 (EST) Message-ID: <01BB1BF2.14601F60@romulus.knx.co.uk> From: Ian Puleston To: "'IETF PPP Mailing List'" Subject: A query on BCP Date: Wed, 27 Mar 1996 15:28:40 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Resent-Message-ID: <"gE0bH.0.K97.-wLMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1413 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I have just had an interoperability problem between our equipment and a = Xyplex router when using PPP BCP. The problem seems to have come about = because we have both interpreted RFC 1638 differently in the area of = stripping trailing zeros from LAN frames. In our BCP Configure Request we indicated Tinygram Compress =3D = Disabled, and he Rejected this option. His Configure Request did not = include it. This means that neither of us use Tinygram Compression. We then received bridged frames which were 46 bytes long, and had the = "Z" (Zero Compression) flag set and the "F" (LAN-FCS) flag unset. Our = implementation assumed that if Tinygram compression was not used, then = padding bytes should not be stripped from the LAN frame, and hence = frames of less than 60 bytes were invalid. The description of Tinygram compression in Section 3.3 of RFC 1638 only = covers the case where the LAN FCS is present, and in this case there was = no LAN FCS. I have now changed our implementation to accept and pad out short frames = from a BCP connection. However, I think that the following points need = to be clarified in the RFC: 1. Is it valid to send LAN frames of less than 60 bytes to a peer who = has not negotiated Tinygram Compression as enabled if there is no LAN = FCS. If the answer is yes, then the RFC should say so. 2. If the answer to 1. is yes, then should frames of less than 60 bytes = have the "Z" (Zero Compression) flag set. The name of this flag (given = in Appendix A) implies that it is specifically for use with Tinygram = Compression. I would also like to get our implementation to strip off trailing zeros = in outgoing frames, but I am worried that this may cause = interoperability problems. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 27 11:05:46 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id LAA01089; Wed, 27 Mar 1996 11:05:46 -0500 (EST) Resent-Date: Wed, 27 Mar 1996 11:05:46 -0500 (EST) Date: Wed, 27 Mar 1996 08:41:13 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199603271541.IAA01351@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: E.164 & BAP Resent-Message-ID: <"j11kp3.0.jG.NTMMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1414 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Marco S Hyman > ... > True. But in any case a delta of "no digits" is perfectly acceptable in > many cases. The caller in that case does not modify his initial dial > number and winds up dialing the same number again. It is the simplest > (and probably most common) way to set up a T1/PRI box. In that case, why spend the network bandwidth or peer CPU memory and cycles on BA(C)P? What are you getting out of BACP in such a situation? The thousands of Motorola Bitsurfer Pro's currently in bandwidth-on- demand service might suggest an answer. With sync lines such as ISDN, both ends know equally well whether more or less bandwidth is needed. ] From: Gerry Meyer ] ] E164 Address? BAP does NOT need them. ] ... ] - The end which made the first call, ALWAYS makes subsequent calls - because ] it DOES have a pretty fair idea of the number dialed. ] (and whichever end requires more bandwith makes an appropriate ] call- or callback- request). And it makes sense for billing. That rule is inevitable in real life for a bunch of reasons. ] Then all that remains to sort is whether the called party is on a hunt ] group or not - which can be handled by a unique digits like option ] consisting of a length plus the actual unique digits. Length is zero ] if on a hunt group. ] ] Makeing this mandatory in the response packet allows us to get rid of ] the No-Phone-Number option (which was always a strangely inverted option). If the caller already knows the phone number, then what is gained by spending bandwidth, memory and cycles on BACP? Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 27 11:10:31 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id LAA01294; Wed, 27 Mar 1996 11:10:31 -0500 (EST) Resent-Date: Wed, 27 Mar 1996 11:10:31 -0500 (EST) Date: Wed, 27 Mar 1996 09:09:55 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199603271609.JAA01427@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: L2F Standard Resent-Message-ID: <"ricUq2.0._J.qXMMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1415 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Malcolm Campbell > > >User connects to ISP, negotiates LCP, and authenticates to ISP. > > > > This is more of a nit than anything, but there is no requirement that > > actual authentication be done at the ISP. The authentication information > > is sent from the client at this point mainly so that we can use the username > > to direct the tunnel to the correct destination. The ISP doesn't need > > to verify the password. > > Are you suggesting that the authentication actually be done at the home > gateway? Ie, with CHAP, a sequence like... > > User ISP Home Gateway > <- Challenge > Response -> > (..... tunnel setup ...) > (Challenge/Response pair) -> > <--------------------------------- Success or Failure > > That way, the ISP gets the name, but the Home Gateway does the actual > authentication. > > I think that method, if its what you were suggesting, resolves my concerns > with Authentication - although the pair is still send over the network. Sending a CHAP pair over the network is not a security risk, since no CHAP Challenge or Response is ever supposed to be used a second time (at least, not predictably). However, if I understand the diagram above, it is catastrophically flawed, since it allows at least replay attacks. Consider the following slightly modified version of the above, formed by having a bad guy pretend to be both the User and the ISP: Bad Guy Home Gateway (Open IP link/tunnel to target Home Gateway) (Challenge/Response pair) ----------------------------> <------------------------------------- Success How can the Home Gateway respond with anything other Success in this case if it responded with Success in the first, desirable case? Each and every Challenge that matters MUST come from the Home Gateway. As in the following, which seems to use the original idea: User ISP Home Gateway <----------- Challenge Response -------------> (ISP sets up tunnel using name in Response) (ISP discards 1st Response) <---------------------------------------------- new Challenge new Response ----------------------------------------> <--------------------------------------- Success or Failure Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 27 11:29:13 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id LAA02142; Wed, 27 Mar 1996 11:29:13 -0500 (EST) Resent-Date: Wed, 27 Mar 1996 11:29:13 -0500 (EST) From: ssenum@sntc.com (Steve Senum) To: ietf-ppp@MERIT.EDU ('IETF PPP Mailing List') Message-ID: <1996Mar27.101900.1487.6738@eagle.sntc.com> X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Wed, 27 Mar 1996 10:31:11 -0600 Subject: RE: A query on BCP Resent-Message-ID: <"gE2MK.0.FX.LpMMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1416 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Ian Puleston > > I have just had an interoperability problem between our equipment and a > Xyplex router when using PPP BCP. The problem seems to have come about > because we have both interpreted RFC 1638 differently in the area of > stripping trailing zeros from LAN frames. > > In our BCP Configure Request we indicated Tinygram Compress = > Disabled, and he Rejected this option. His Configure Request did not > include it. This means that neither of us use Tinygram Compression. > > We then received bridged frames which were 46 bytes long, and had the > "Z" (Zero Compression) flag set and the "F" (LAN-FCS) flag unset. Our > implementation assumed that if Tinygram compression was not used, then > padding bytes should not be stripped from the LAN frame, and hence > frames of less than 60 bytes were invalid. This sounds like a bug in the Xyplex router to me. If it has not accepted your option, it should not be sending frames with the "Z" bit set, or padding removed. Steve Senum, ssenum@sntc.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 27 11:44:49 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id LAA03245; Wed, 27 Mar 1996 11:44:49 -0500 (EST) Resent-Date: Wed, 27 Mar 1996 11:44:49 -0500 (EST) Message-Id: <199603271642.LAA06208@funk.com> X-Sender: ken@funk1.funk.com X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 27 Mar 1996 11:47:54 -0500 To: ietf-ppp From: ken@funk.com (Ken Culbert) Subject: Reason codes in BACP Resent-Message-ID: <"BxgAc3.0.Uo.-1NMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1417 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Does anyone else feel that there should be defined numeric reason codes instead of ASCII? ============================================ Ken Culbert ken@funk.com Funk Software, Inc. voice: +1 617 497-6339 222 Third Street fax: +1 617 547-1031 Cambridge, MA 02142 http://www.funk.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 27 11:46:23 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id LAA03329; Wed, 27 Mar 1996 11:46:23 -0500 (EST) Resent-Date: Wed, 27 Mar 1996 11:46:23 -0500 (EST) Message-Id: <199603271639.LAA06189@funk.com> X-Sender: ken@funk1.funk.com X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 27 Mar 1996 11:44:47 -0500 To: ietf-ppp From: ken@funk.com (Ken Culbert) Subject: Re: E.164 & BAP Resent-Message-ID: <"UimLL3.0.kp.R3NMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1418 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU At 09:51 AM 3/27/96 -0500, Ian Duncan wrote: >It seems I was a bit unclear. The issue being discussed is how to represent >the value(s) of a callback token. The LCP callback provides a particular >model that's extensible along with a reasonable enumeration of options. >Ignoring the larger discussion of LCP callback, what's wrong with the model >and more particularly the specific representation including the assigned >enumeration? I see your point and concur. [...] >PS: Have you looked at the full text on Callback in the current draft WRT to >the lack of user identity? The draft assumes that authentication has occurred and uses it to resolve race conditions. An implementation could make decisions on callback based on authentication, or lack thereof. ============================================ Ken Culbert ken@funk.com Funk Software, Inc. voice: +1 617 497-6339 222 Third Street fax: +1 617 547-1031 Cambridge, MA 02142 http://www.funk.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 27 12:02:52 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id MAA04529; Wed, 27 Mar 1996 12:02:52 -0500 (EST) Resent-Date: Wed, 27 Mar 1996 12:02:52 -0500 (EST) Message-Id: <9603271707.AA22993@flowpoint.com> Date: Wed, 27 Mar 96 09:01:01 -0800 From: Philippe Roger Mime-Version: 1.0 To: Gerry Meyer , ietf-ppp@MERIT.EDU Subject: RE: E.164 & BAP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"0NNqB1.0.X61.vINMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1419 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I am inclined to disagree here, as a host system may be better off calling back its dial-up users, not only for security reasons but because of $$$ involved. Many enterprises can work out a better plan with their phone companies than their individual users (even if they pay the phone bills of their telecommuting employees...) Philippe Roger ---------- From: Gerry Meyer Sent: Wednesday, March 27, 1996 10:20 AM To: ietf-ppp@MERIT.EDU Subject: Re: E.164 & BAP E164 Address? BAP does NOT need them. I've always thought that the phone number option's complexity is because it is trying to do two distinct things (which since I like short email message I won't bore anyone with here). The complexity ALL disappears if: - The end which made the first call, ALWAYS makes subsequent calls - because it DOES have a pretty fair idea of the number dialed. (and whichever end requires more bandwith makes an appropriate call- or callback- request). And it makes sense for billing. Then all that remains to sort is whether the called party is on a hunt group or not - which can be handled by a unique digits like option consisting of a length plus the actual unique digits. Length is zero if on a hunt group. Makeing this mandatory in the response packet allows us to get rid of the No-Phone-Number option (which was always a strangely inverted option). Gerry - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 27 12:19:01 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id MAA05459; Wed, 27 Mar 1996 12:19:01 -0500 (EST) Resent-Date: Wed, 27 Mar 1996 12:19:01 -0500 (EST) Date: Wed, 27 Mar 1996 09:18:43 -0800 From: Tim Kolar Message-Id: <199603271718.JAA09599@greatdane.cisco.com> To: vjs@mica.denver.sgi.com Subject: Re: L2F Standard Newsgroups: cisco.external.ietf.ppp In-Reply-To: <199603271609.JAA01427@mica.denver.sgi.com> Organization: cisco Systems, Inc., Menlo Park, Ca. Cc: ietf-ppp@MERIT.EDU Resent-Message-ID: <"3xH8N2.0.2L1.1YNMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1420 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Hello Vernon, In article <199603271609.JAA01427@mica.denver.sgi.com> you write: > snip snip > >Sending a CHAP pair over the network is not a security risk, since >no CHAP Challenge or Response is ever supposed to be used a second >time (at least, not predictably). However, if I understand the diagram >above, it is catastrophically flawed, since it allows at least replay >attacks. > Please see my and Andy Valencia's posts from a few days ago on this topic for a full discussion, but to summarize: 1) If you can pretend to be the NAS, a replay attack is trivial. 2) Pretending to be the NAS requires either having the tunnel secret, or hijacking an existing tunnel. 3) If you have sufficient access to the network to hijack an existing tunnel, L2F doesn't even pretend to defend against you. There is some question about what should be done with number 3. Our feeling is that if you are serious about this kind of thing, then you need to be protecting your network a lower level (IP encryption, etc.) There has been some thought that L2F should protect itself. As for having the chap request initiate from the gateway, this can be done and is supported in the current L2F, but has the undesirable side effect of the client receiving two requests for authentication. Users with token cards will not accept this easily. -Tim - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 27 12:37:27 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id MAA06274; Wed, 27 Mar 1996 12:37:27 -0500 (EST) Resent-Date: Wed, 27 Mar 1996 12:37:27 -0500 (EST) From: gerry@spider.co.uk (CN=Gerry Meyer/OU=Eng/OU=EDI/O=Shiva) To: roger@flowpoint.com Cc: ietf-ppp@MERIT.EDU Message-ID: <1996Mar27.163339.1281.157080@eurohub.spider.co.uk> X-Conversion-ID: X-Mailer: Lotus Notes via PostalUnion/SMTP for Windows NT Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Wed, 27 Mar 1996 17:34:47 GMT Subject: RE: E.164 & BAP Resent-Message-ID: <"FLNBJ1.0.nX1.IpNMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1421 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Philippe, >I am inclined to disagree here, as a host system may be better off calling >back its dial-up users, not only for security reasons but because of $$$ >involved. Many enterprises can work out a better plan with their phone >companies than their individual users (even if they pay the phone bills of >their telecommuting employees...) BACP/BAP is not intended to be used for negotiating callback on the first call. There are already mechanisms for that (LCP callback; SPAP (if Shiva); others?) The first time a dial up user makes a conection and requests callback (without data transfer). The call is dropped, Your host system calls back and then data transfer proceeds. Thereafter the host system is regarded as the 'first' caller and makes any additional calls (based on BAP negotiation). Moving away from callback: Before anyone asks, if there is a collision during the first call then both ends may think they made the first call but both have all the information they need to make/request calls without needing to know E164 addresses. Gerry ---------- From: Gerry Meyer Sent: Wednesday, March 27, 1996 10:20 AM To: ietf-ppp@MERIT.EDU Subject: Re: E.164 & BAP E164 Address? BAP does NOT need them. I've always thought that the phone number option's complexity is because it is trying to do two distinct things (which since I like short email message I won't bore anyone with here). The complexity ALL disappears if: - The end which made the first call, ALWAYS makes subsequent calls - because it DOES have a pretty fair idea of the number dialed. (and whichever end requires more bandwith makes an appropriate call- or callback- request). And it makes sense for billing. Then all that remains to sort is whether the called party is on a hunt group or not - which can be handled by a unique digits like option consisting of a length plus the actual unique digits. Length is zero if on a hunt group. Makeing this mandatory in the response packet allows us to get rid of the No-Phone-Number option (which was always a strangely inverted option). Gerry ------ Message Header Follows ------ Received: from lynx.spider.co.uk by eurohub.spider.co.uk (PostalUnion/SMTP(tm) v2.1.7 for Windows NT(tm)) id AA-1996Mar27.170056.1281.86664; Wed, 27 Mar 1996 17:00:56 GMT Received: from SantaClara01.pop.internex.net (SantaClara01.POP.InterNex.Net [205.158.3.18]) by lynx.spider.co.uk (8.6.12/8.6.12) with ESMTP id RAA09833 for ; Wed, 27 Mar 1996 17:00:11 GMT Received: from flowpoint.com ([192.84.210.69]) by SantaClara01.pop.internex.net (post.office MTA v1.9.3 ID# 0-11030) with SMTP id AAA18793; Wed, 27 Mar 1996 09:02:31 -0700 Received: from philippe.flowpoint.com by flowpoint.com (4.1/SMI-4.1) id AA22993; Wed, 27 Mar 96 09:07:41 PST Message-Id: <9603271707.AA22993@flowpoint.com> Date: Wed, 27 Mar 96 09:01:01 -0800 From: Philippe Roger Mime-Version: 1.0 To: Gerry Meyer , ietf-ppp@MERIT.EDU Subject: RE: E.164 & BAP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 27 12:41:43 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id MAA06632; Wed, 27 Mar 1996 12:41:43 -0500 (EST) Resent-Date: Wed, 27 Mar 1996 12:41:43 -0500 (EST) From: Tim Kolar Message-Id: <199603271741.JAA10479@greatdane.cisco.com> Subject: Re: L2F Standard To: malcolmc@spider.co.uk (Malcolm Campbell) Date: Wed, 27 Mar 1996 09:41:25 -0800 (PST) Cc: tkolar@cisco.com, ietf-ppp@MERIT.EDU In-Reply-To: <9603271342.AA19223@queenbee.spider.co.uk> from "Malcolm Campbell" at Mar 27, 96 01:42:15 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"XlY-3.0.Kd1.JtNMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1422 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Hello again, Malcolm... > > Are you suggesting that the authentication actually be done at the home > gateway? Ie, with CHAP, a sequence like... > > User ISP Home Gateway > <- Challenge > Response -> > (..... tunnel setup ...) > (Challenge/Response pair) -> > <--------------------------------- Success or Failure > > That way, the ISP gets the name, but the Home Gateway does the actual > authentication. > > I think that method, if its what you were suggesting, resolves my concerns > with Authentication - although the pair is still send over the network. > > A similar method could be used with PAP. Yes, this is what we had in mind. In fact, our implementation allows exactly this configuration. > > > This was also our intention, although I'd like to note that I'm with > > Andy on wanting to find a real case of this happening. Our experience with > > PPP has been that the negotiated LCP options are pretty standard in the > > ISP environment. > > Yes, but the end user doesnt want to talk PPP to the ISP, he wants to talk > PPP to the Home Gateway. I can think of several options that MIGHT cause > problems - let me give one example... > > The end user is using a Shiva client that wants to use SPAP to the home > gateway. The ISP doesnt know anything about SPAP. So, the negotiation falls > back to CHAP, or PAP. The tunnel is set up - then the home gateway (which > can do SPAP - has no idea that end user wants it) - so the functionality > that the user would expect to get from this, is unavailable. > (Someone who knows SPAP might want to comment on this).. > > There may be other proprietary options.. Someone suggested to me there may > be a problem with Endpoint Discriminator too, but again, this isnt something > I know too well.. > > In any case, there may be proprietary options, less common options, or > options to be added in the future - which the ISP may not support or wish > to negotiate - that the Home Gateway wishes. The client _must_, in my > opinion, be given the chance to request those from the home gateway. Okay, point taken. > > I can see two ways of doing this (another popped into my head last night): > 1) Have the Home Gateway always renegotiate LCP. > 2) Have the ISP forward the users initial configure request to the Home > Gateway, as well as the ACKs. That allows the Home Gateway to see options > that the user requested, but the ISP refused - so it can decide whether or > not to renegotiate LCP. Number two seems better to me. Without saying that this is necessarily what we should do, let me rough it out here so that I make sure I understand you: We add a new optional field to the L2F_OPEN request for a MID. This field is in the same format as the L2F_ACK_LCP1 and L2F_ACK_LCP2 fields, and will be called L2F_LCP_REQ. The field will consist of the first LCP_REQ received from the client. This field is not intended to be used as an actual LCP request on the home gateway, but rather is used as a hint for the home gateway to decide if it should renegotiate LCP. Is this what you had in mind? > > > If you can point out parts of the RFC that you think need clearing up, > > we'd be most grateful. > > I'll do, along with some other people at Shiva Europe, in the next few days. > (im working from home at the moment) Great, we're looking forward to it. There have been some significant changes in tunnel negotiation, and we'd like to get the new draft out as soon as possible. -Tim - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 27 12:53:28 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id MAA07230; Wed, 27 Mar 1996 12:53:28 -0500 (EST) Resent-Date: Wed, 27 Mar 1996 12:53:28 -0500 (EST) Date: Wed, 27 Mar 96 17:48:51 GMT Message-Id: <9603271748.AA23381@queenbee.spider.co.uk> From: Malcolm Campbell Subject: Re: L2F Standard To: Tim Kolar In-Reply-To: Tim Kolar's message of Wed, 27 Mar 1996 09:41:25 -0800 (PST) X-Mailer: Sendmail/Ream v5.1.23 (Vorsprung Dourish Technik) Phone: +44 131 554 9424 (Work) Cc: ietf-ppp@MERIT.EDU Resent-Message-ID: <"TDzCn1.0.lm1.K2OMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1423 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > > I can see two ways of doing this (another popped into my head last night): > > 1) Have the Home Gateway always renegotiate LCP. > > 2) Have the ISP forward the users initial configure request to the Home > > Gateway, as well as the ACKs. That allows the Home Gateway to see options > > that the user requested, but the ISP refused - so it can decide whether or > > not to renegotiate LCP. > > Number two seems better to me. Without saying that this is necessarily > what we should do, let me rough it out here so that I make sure I understand > you: > > We add a new optional field to the L2F_OPEN request for a MID. > This field is in the same format as the L2F_ACK_LCP1 and > L2F_ACK_LCP2 fields, and will be called L2F_LCP_REQ. > The field will consist of the first LCP_REQ received from the client. > This field is not intended to be used as an actual LCP request on > the home gateway, but rather is used as a hint for the home gateway > to decide if it should renegotiate LCP. > > Is this what you had in mind? Exactly what I meant. --- Malcolm - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 27 12:58:13 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id MAA07440; Wed, 27 Mar 1996 12:58:13 -0500 (EST) Resent-Date: Wed, 27 Mar 1996 12:58:13 -0500 (EST) Message-Id: <9603271803.AA23075@flowpoint.com> Date: Wed, 27 Mar 96 09:56:24 -0800 From: Philippe Roger Mime-Version: 1.0 To: gerry@spider.co.uk Cc: ietf-ppp@MERIT.EDU Subject: RE: E.164 & BAP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"pDru71.0.wp1.m6OMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1424 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Gerry, I see your point and once it is clearly understood what the "first" call is, I think you are right to assume that the first caller should dial any other calls. This transfers the complexity of supplying phone numbers from BAP to the callback protocol. This is not a trivial task since the answerer of a call has practically no way of knowing how the originator of a first call should dial another number other than telling him the delta with the previous call: there are too many parameters that the answerer does not know anything about, like outside line prefix, long distance/international prefixes, calling cards numbers and a zillion other things that only the initial caller is aware of. Is there any momentum on this list to promote a standard callback protocol ? Philippe Roger ---------- From: gerry@spider.co.uk (CN=Gerry Meyer/OU=Eng/OU=EDI/O=Shiva) Sent: Wednesday, March 27, 1996 5:34 PM To: roger@flowpoint.com Cc: ietf-ppp@MERIT.EDU Subject: RE: E.164 & BAP Philippe, >I am inclined to disagree here, as a host system may be better off calling >back its dial-up users, not only for security reasons but because of $$$ >involved. Many enterprises can work out a better plan with their phone >companies than their individual users (even if they pay the phone bills of >their telecommuting employees...) BACP/BAP is not intended to be used for negotiating callback on the first call. There are already mechanisms for that (LCP callback; SPAP (if Shiva); others?) The first time a dial up user makes a conection and requests callback (without data transfer). The call is dropped, Your host system calls back and then data transfer proceeds. Thereafter the host system is regarded as the 'first' caller and makes any additional calls (based on BAP negotiation). Moving away from callback: Before anyone asks, if there is a collision during the first call then both ends may think they made the first call but both have all the information they need to make/request calls without needing to know E164 addresses. Gerry - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 27 13:04:51 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id NAA07888; Wed, 27 Mar 1996 13:04:51 -0500 (EST) Resent-Date: Wed, 27 Mar 1996 13:04:51 -0500 (EST) To: Philippe Roger Cc: Gerry Meyer , ietf-ppp@MERIT.EDU Subject: Re: E.164 & BAP In-Reply-To: Your message of "Wed, 27 Mar 1996 09:01:01 PST." <9603271707.AA22993@flowpoint.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 27 Mar 1996 10:04:20 -0800 Message-Id: <1775.827949860@dumbcat.sf.ca.us> From: Marco S Hyman Resent-Message-ID: <"-v5Dt2.0.1x1._COMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1426 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Philippe Roger writes: > I am inclined to disagree here, as a host system may be better off calling > back its dial-up users, not only for security reasons but because of $$$ > involved. Many enterprises can work out a better plan with their phone > companies than their individual users (even if they pay the phone bills of > their telecommuting employees...) Apples and oranges. The "caller places all calls" rule still works with callback. User dials into hub. User/Hub agree on callback. Initial call is cleared. End of session. A new session is immediately started when hub calls user back. All bandwidth changes from this point on can be initiated by either end, but the hub would always place the call. // marc - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 27 13:09:40 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id NAA08270; Wed, 27 Mar 1996 13:09:40 -0500 (EST) Resent-Date: Wed, 27 Mar 1996 13:09:40 -0500 (EST) From: Barney Wolff To: ietf-ppp@MERIT.EDU Date: Wed, 27 Mar 1996 12:44 EST Subject: Re: L2F Standard Content-Type: text/plain Message-ID: <315984420.10b7@databus.databus.com> Resent-Message-ID: <"eavC31.0.-02.VHOMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1427 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU While I understand and sympathize with the desire to make it all transparent to the caller, I wonder if we're working too hard to keep it all within PPP. Most callers, perhaps even all, can fire off a string before starting PPP, and that should be sufficient for the NAS to establish a tunnel. Then the entire PPP dialog is end-to-end, with one authentication cycle and the right set of options. I know this works fine for async. I'm not sure I know how it would work for ISDN, and would appreciate anybody's thoughts on the matter. Preparing to be flam^H^H^H^Hshown the error of my ways, Barney Wolff - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 27 13:01:46 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id NAA07705; Wed, 27 Mar 1996 13:01:46 -0500 (EST) Resent-Date: Wed, 27 Mar 1996 13:01:46 -0500 (EST) Message-Id: <199603271801.KAA25991@vandys-lap.cisco.com> X-Authentication-Warning: vandys-lap.cisco.com: Host localhost.cisco.com [127.0.0.1] didn't use HELO protocol To: Ian Duncan cc: ietf-ppp@MERIT.EDU Subject: Re: L2F In-reply-to: Your message of "Mon, 25 Mar 1996 13:29:23 EST." Date: Wed, 27 Mar 1996 10:01:17 -0800 From: Andy Valencia Resent-Message-ID: <"b_BGn3.0.Au1.5AOMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1425 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU [Ian Duncan writes:] > [encryption of L2F tunnels] >For moment let's imagine that the only permitted terminal access to the NAS >is on a console port and generally admin is handled via SNMPv2u (or some >other similar thing) and therefore securing the tunnel would raise the bar >significantly. >> If the modest increment in protection is of interest to the group, we'd be >> happy to look at adding it as an option. >If it doesn't bury other important goals in the noise I think it'd be a >good idea. I've been off doing some homework, and the big issue is scalability. We could do something like use the shared secret and a seed to create an MD5 hash pattern, and XOR that onto the data. This has some unknown security attributes (ref, the RADIUS discussion on such a technique), but let's say we use it, or something similar but stronger. Whatever we choose, it's either going to line up with IPsec, or there's not likely to be a hardware solution for it. Without hardware, it's not going to scale very well. But if it's going to line up with IPsec, we could just assume that the IP endpoints establish encryption at the IP level, and our tunnel is secured already. Then we also inherit all the security algorithms, and a bunch of key management stuff as well. IPsec would work equally well if the NAS and the Home Gateway were the endpoints for the encryption, or the client and the Home Gateway (or the client and his home network router, for that matter). I guess this would make sense if a vendor had no plans to do anything along the IPsec lines, but still wanted to encrypt the tunnel. If a vendor or two will step forward here, I'll write the text. I'll need input from such vendors on what they want for encryption, and what's desired for key management. Regards, Andy Valencia - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 27 13:46:07 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id NAA10835; Wed, 27 Mar 1996 13:46:07 -0500 (EST) Resent-Date: Wed, 27 Mar 1996 13:46:07 -0500 (EST) Date: Wed, 27 Mar 1996 11:45:39 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199603271845.LAA01660@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: L2F Standard Resent-Message-ID: <"-c3uO2.0.se2.cpOMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1428 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Tim Kolar > Hello Vernon Howdy. > ... > Please see my and Andy Valencia's posts from a few days ago on this topic > for a full discussion, but to summarize: > > 1) If you can pretend to be the NAS, a replay attack is trivial. How can there ever be a replay attack against properly implemented CHAP? > 2) Pretending to be the NAS requires either having the tunnel > secret, or hijacking an existing tunnel. > 3) If you have sufficient access to the network to hijack an > existing tunnel, L2F doesn't even pretend to defend against > you. > > There is some question about what should be done with number 3. Our feeling > is that if you are serious about this kind of thing, then you need to be > protecting your network a lower level (IP encryption, etc.) There has been > some thought that L2F should protect itself. In other words, you're delegating many or most security concerns to end-to-end encyption, either in applications or IP. That's a position I've long supported. It seems to me that Malcolm Campbell's words are clearly true: ] ... ] > This was also our intention, although I'd like to note that I'm with ] > Andy on wanting to find a real case of this happening. Our experience with ] > PPP has been that the negotiated LCP options are pretty standard in the ] > ISP environment. ] ] Yes, but the end user doesnt want to talk PPP to the ISP, he wants to talk ] PPP to the Home Gateway. I can think of several options that MIGHT cause ] problems - let me give one example... ] ] The end user is using a Shiva client that wants to use SPAP to the home ] ... Given all of that, what is the purpose of L2F? Why wouldn't a user prefer to use a combination of 1. standard, minimally (e.g. PAP or none) to authenticate PPP to the local ISP 2. Mobile IP to get home 3. end-to-end, IP encryption for security 4. familiar, old fashioned IP tunneling of anything that isn't IP What is provided by a new protocol like L2F that is not already present with those protocols, all of which are far more advanced than L2F? Why is L2F not an example of "if you have a hammer (PPP standards committee), then everything looks like a nail (yet another NCP)." There must be something I haven't heard about L2F that is generating the interest in it. > As for having the chap request initiate from the gateway, this can be done > and is supported in the current L2F, but has the undesirable side effect > of the client receiving two requests for authentication. Users with > token cards will not accept this easily. Agreed, provide a human is stuck in the loop between the token card and the computer. If the mobile computer has a socket (e.g. PCMIA) for the token card, then extra rounds of CHAP are no problem. In my view, that is a fatal flaw in using token cards with PPP. Token card security that requires humans to read token card LCD windows is essentially useless for PPP. Having humans in the loop cannot be made to work tolerably with demand- dialing (a.k.a. Bandwidth on Demand). It also violates a fundamental and required feature of CHAP that allows a peer to demand a new round of authentication at any time. Consider how many modems are configured to keep DCD true all of the time, and the consequent wide spread security problems. If you care about PPP security, you must at least talk about doing gratuitous CHAP, say after any long pause. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 27 13:58:03 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id NAA11403; Wed, 27 Mar 1996 13:58:03 -0500 (EST) Resent-Date: Wed, 27 Mar 1996 13:58:03 -0500 (EST) Date: Wed, 27 Mar 96 13:47:27 EST From: Rich_Bowen@NetEdge.COM (Rich_Bowen) Message-Id: <9603271847.AA08546@NetEdge.COM> To: ian_puleston@globalvillage.co.uk Subject: Re: A query on BCP Cc: ietf-ppp@MERIT.EDU Resent-Message-ID: <"DNgjI.0.nn2.hzOMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1429 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Ian Puleston writes: > > I have just had an interoperability problem between our equipment and a = > Xyplex router when using PPP BCP. The problem seems to have come about = > because we have both interpreted RFC 1638 differently in the area of = > stripping trailing zeros from LAN frames. > > In our BCP Configure Request we indicated Tinygram Compress =3D = > Disabled, and he Rejected this option. His Configure Request did not = > include it. This means that neither of us use Tinygram Compression. > > We then received bridged frames which were 46 bytes long, and had the = > "Z" (Zero Compression) flag set and the "F" (LAN-FCS) flag unset. Our = > implementation assumed that if Tinygram compression was not used, then = > padding bytes should not be stripped from the LAN frame, and hence = > frames of less than 60 bytes were invalid. > This interpretation is valid since the RFC says that you "should never receive a compressed packet" if Tinygram compression is disabled. > The description of Tinygram compression in Section 3.3 of RFC 1638 only = > covers the case where the LAN FCS is present, and in this case there was = > no LAN FCS. > I agree that the text in Section 3.3 is unclear. However, it does reference the code in Appendix A which covers both cases. > I have now changed our implementation to accept and pad out short frames = > from a BCP connection. However, I think that the following points need = > to be clarified in the RFC: > > 1. Is it valid to send LAN frames of less than 60 bytes to a peer who = > has not negotiated Tinygram Compression as enabled if there is no LAN = > FCS. If the answer is yes, then the RFC should say so. > Yes. This case is allowed because there are PPP-connected end stations that transmit directly onto the PPP link and therefore have no need to pad the frame. I agree that it would be helpful for the RFC to say so. > 2. If the answer to 1. is yes, then should frames of less than 60 bytes = > have the "Z" (Zero Compression) flag set. The name of this flag (given = > in Appendix A) implies that it is specifically for use with Tinygram = > Compression. > No. Setting the Z flag specifically indicates that the frame must be zero filled. If the Z flag is not set then you may pad the frame in whatever way you choose. The Z flag should only be set on transmit if the peer has indicated that it has Tinygram compression enabled. I will start keeping a list of comments on RFC 1638 for the next time it comes up for review. If there are others, let me know. Regards, Rich - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 27 14:05:06 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id OAA11922; Wed, 27 Mar 1996 14:05:06 -0500 (EST) Resent-Date: Wed, 27 Mar 1996 14:05:06 -0500 (EST) Date: Wed, 27 Mar 1996 11:03:59 -0800 (PST) From: Andy Valencia Message-Id: <199603271903.LAA26272@vandys-lap.cisco.com> To: vjs@mica.denver.sgi.com Cc: ietf-ppp@MERIT.EDU Subject: Re: L2F draft Newsgroups: cisco.external.ietf.ppp References: <199603271609.JAA01427@mica.denver.sgi.com> X-Newsreader: NN version 6.5.0 #1 (NOV) Resent-Message-ID: <"4m-gW3.0._v2.R5PMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1430 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU In cisco.external.ietf.ppp you write: > However, if I understand the diagram >above, it is catastrophically flawed, since it allows at least replay >attacks. Tim's right, we haven't designed the protocol to protect against this. The Home Gateway authenticates the NAS, and then trusts him to generate "good enough" random challenge values. If you're *really* concerned about replay attacks, note that your auth server will want to record and defend against previously used values in any case. A 128-bit challenge is only as good as the algorithms used to create that challenge; we've seen some access servers which are a little more deterministic than would be ideal for security. Regards, Andy Valencia - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 27 14:13:58 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id OAA12393; Wed, 27 Mar 1996 14:13:58 -0500 (EST) Resent-Date: Wed, 27 Mar 1996 14:13:58 -0500 (EST) Date: Wed, 27 Mar 1996 11:13:23 -0800 From: Tim Kolar Message-Id: <199603271913.LAA15961@greatdane.cisco.com> To: barney@databus.com Subject: Re: L2F Standard Organization: cisco Systems, Inc., Menlo Park, Ca. Cc: ietf-ppp@MERIT.EDU Resent-Message-ID: <"ZMKF2.0.P13.nDPMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1431 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Hello Barney, No flamage, just our experience: We have a feature in the field now that does exactly what you suggest. Essentially it's just support for PPP on VTYs instead of TTYs. Users dial into the NAS, do a stream telnet into the Home Gateway, and start PPP from a script. It's hard to say whether we get more complaints about the performance or the scripting requirement. However, there seems to be some tolerance on the part of the administrators for the performance problems, while they keep offering us their first-born children if we'll get rid of the scripting. :-) The administrators we've dealt with want to say to their users: "Go buy XXX package, install it on your PC, enter your username and password, and dial this phone number." The seemingly tiny extra step of asking the user to configure a script seems to cause a lot of grief -- and to be honest, my own user support experience is about the same. Policy questions aside, I'm with you in drawing a blank on how this could be done cleanly for sync ISDN or sync serial. -Tim In article <315984420.10b7@databus.databus.com> you write: >While I understand and sympathize with the desire to make it all >transparent to the caller, I wonder if we're working too hard to keep it >all within PPP. Most callers, perhaps even all, can fire off a string >before starting PPP, and that should be sufficient for the NAS to >establish a tunnel. Then the entire PPP dialog is end-to-end, with one >authentication cycle and the right set of options. > >I know this works fine for async. I'm not sure I know how it would work >for ISDN, and would appreciate anybody's thoughts on the matter. > >Preparing to be flam^H^H^H^Hshown the error of my ways, > >Barney Wolff > - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 27 14:29:46 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id OAA13258; Wed, 27 Mar 1996 14:29:46 -0500 (EST) Resent-Date: Wed, 27 Mar 1996 14:29:46 -0500 (EST) Message-Id: <199603271923.OAA06833@funk.com> X-Sender: ken@funk1.funk.com X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 27 Mar 1996 14:28:50 -0500 To: ietf-ppp@MERIT.EDU From: ken@funk.com (Ken Culbert) Subject: Callback (was RE: E.164 & BAP) Resent-Message-ID: <"9Zqho.0.pE3.bSPMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1432 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU At 09:56 AM 3/27/96 -0800, Philippe Roger wrote: >Is there any momentum on this list to promote a standard callback protocol ? I'd like to see Microsoft float their CBCP again. We've implemented it, so there's at least two implementations. ============================================ Ken Culbert ken@funk.com Funk Software, Inc. voice: +1 617 497-6339 222 Third Street fax: +1 617 547-1031 Cambridge, MA 02142 http://www.funk.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 27 14:47:17 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id OAA14632; Wed, 27 Mar 1996 14:47:17 -0500 (EST) Resent-Date: Wed, 27 Mar 1996 14:47:17 -0500 (EST) Message-Id: <9603271950.AA2251@hqsmtp.ops.3com.com> To: Barney Wolff Cc: ietf-ppp From: Cheng Chen/US/3Com Date: 27 Mar 96 11:13:57 EDT Subject: Re: L2F Standard Mime-Version: 1.0 Content-Type: Text/Plain Resent-Message-ID: <"VKkPc.0.Pa3.-iPMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1433 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU This will not work too well for ISDN. Most ISDN equipment, perhaps even all, connects the B-channel to HDLC controller as soon as the ISDN call is answered. ASCII strings prior to PPP need to be encapsulated in some HDLC frames - the obvious choice is LCP frames. That means, we need to define another lcpext to do this. Cheng ----- Previous Message ---------------------------------------------------- To: ietf-ppp @ MERIT.EDU @ UGATE cc: From: barney @ databus.com (Barney Wolff) @ UGATE Date: Wednesday March 27, 1996 01:19 PM Subject: Re: L2F Standard ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- While I understand and sympathize with the desire to make it all transparent to the caller, I wonder if we're working too hard to keep it all within PPP. Most callers, perhaps even all, can fire off a string before starting PPP, and that should be sufficient for the NAS to establish a tunnel. Then the entire PPP dialog is end-to-end, with one authentication cycle and the right set of options. I know this works fine for async. I'm not sure I know how it would work for ISDN, and would appreciate anybody's thoughts on the matter. Preparing to be flam^H^H^H^Hshown the error of my ways, Barney Wolff - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 27 15:00:14 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id PAA15225; Wed, 27 Mar 1996 15:00:14 -0500 (EST) Resent-Date: Wed, 27 Mar 1996 15:00:14 -0500 (EST) Date: Wed, 27 Mar 1996 14:59:34 -0500 (EST) From: Ian Duncan X-Sender: iduncan@magnus2 To: Ken Culbert Cc: ietf-ppp@MERIT.EDU Subject: Re: Callback (was RE: E.164 & BAP) In-Reply-To: <199603271923.OAA06833@funk.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"rwE5B3.0.Ei3.3vPMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1434 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU On Wed, 27 Mar 1996, Ken Culbert wrote: > I'd like to see Microsoft float their CBCP again. We've implemented it, so > there's at least two implementations. Given that the current LCP Callback requires authentication to complete, capturing the user's identity, and then terminate to reconnect what more is needed? -- Ian Duncan Access Products Development Newbridge Networks Corp. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 27 15:01:25 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id PAA15289; Wed, 27 Mar 1996 15:01:25 -0500 (EST) Resent-Date: Wed, 27 Mar 1996 15:01:25 -0500 (EST) Date: Wed, 27 Mar 1996 12:01:08 -0800 From: Tim Kolar Message-Id: <199603272001.MAA18681@greatdane.cisco.com> To: vjs@mica.denver.sgi.com Subject: Re: L2F Standard Cc: ietf-ppp@MERIT.EDU Resent-Message-ID: <"mvfiJ.0.fk3.HwPMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1435 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Hello again Vernon, In article <199603271845.LAA01660@mica.denver.sgi.com> you write: >> ... >> Please see my and Andy Valencia's posts from a few days ago on this topic >> for a full discussion, but to summarize: >> >> 1) If you can pretend to be the NAS, a replay attack is trivial. > >How can there ever be a replay attack against properly implemented CHAP? "Properly implemented CHAP" does not allow a third party to generate the challenge number. You pay for what you get in L2F -- a well understood security problem versus a single round of authentication. For my thoughts on why the trade is worth it, see below. Also, be aware that we are talking about one possible way of using L2F. Passing CHAP information in this fashion is an option, not a requirment, and it is used to support today's clients. > > [snip snip] > >Given all of that, what is the purpose of L2F? Why wouldn't a user >prefer to use a combination of > > 1. standard, minimally (e.g. PAP or none) to authenticate PPP to the > local ISP > 2. Mobile IP to get home > 3. end-to-end, IP encryption for security > 4. familiar, old fashioned IP tunneling of anything that isn't IP > >What is provided by a new protocol like L2F that is not already >present with those protocols, all of which are far more advanced than >L2F? Why is L2F not an example of "if you have a hammer (PPP standards >committee), then everything looks like a nail (yet another NCP)." Well, if you're thinking that L2F is an NCP then you may have missed quite a bit in the specification. We'll assume you're not. > >There must be something I haven't heard about L2F that is generating >the interest in it. Your example above assumes that L2F runs only over IP, which is not the case. Frame-relay and X.25 are also possibilities mentioned in the RFC, and undoubtedly there will be more. Of course you could argue that you could just run IP over these lower layers, then your scheme above over IP. Unfortunately at that point your performance has dropped on the floor. As far as tunneling other protocols is concerned, you have two options: One, you tunnel them from the gateway all the way through to the client. This is completely inefficient -- there's a reason why most NCPs supply protocol compression. Two, you tunnel them to the NAS, then convert them into a PPP stream to the client -- this still causes bandwidth problems between the GW and NAS, and worse it forces the NAS to understand any and all protocols that you might want to pass through it. The point of this is that the NAS is supposed to be a pretty simple peice of hardware. So in short, while you could make the scheme above work, it would result in a lot of unnecessary bytes being passed around. For the environment L2F was designed for, bytes cost money. >> As for having the chap request initiate from the gateway, this can be done >> and is supported in the current L2F, but has the undesirable side effect >> of the client receiving two requests for authentication. Users with >> token cards will not accept this easily. > >Agreed, provide a human is stuck in the loop between the token card and >the computer. If the mobile computer has a socket (e.g. PCMIA) for the >token card, then extra rounds of CHAP are no problem. > >In my view, that is a fatal flaw in using token cards with PPP. Token >card security that requires humans to read token card LCD windows is >essentially useless for PPP. Having humans in the loop cannot be made >to work tolerably with demand- dialing (a.k.a. Bandwidth on Demand). >It also violates a fundamental and required feature of CHAP that allows >a peer to demand a new round of authentication at any time. Consider >how many modems are configured to keep DCD true all of the time, and >the consequent wide spread security problems. If you care about PPP >security, you must at least talk about doing gratuitous CHAP, say after >any long pause. I agree with all of the above from a policy standpoint, and if I was designing a dial-in network I would accept these as guidelines. And L2F absolutely must support a configuration of this type. However, if this is to be a successful protocol there must be some recognition of how people are using PPP today. We're seeing token cards being used in this fashion, and we're getting complaints about second CHAP requests being sent. As such, we want to make sure that we at least have the option of supporting these people over L2F. Regards, -Tim - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 27 15:48:36 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id PAA17394; Wed, 27 Mar 1996 15:48:36 -0500 (EST) Resent-Date: Wed, 27 Mar 1996 15:48:36 -0500 (EST) From: jgardner@BayNetworks.com (Jim Gardner) Message-Id: <9603272047.AA09781@pobox.BayNetworks.com> Subject: Re: BACP-02.TXT To: crichards@shiva.com (Craig Richards/Shiva Corporation) Date: Wed, 27 Mar 1996 15:57:30 -0500 (EST) Cc: ietf-ppp@MERIT.EDU In-Reply-To: <9603261244.AA0486@shivaportal.shiva.com> from "Craig Richards/Shiva Corporation" at Mar 25, 96 01:38:17 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Resent-Message-ID: <"Eaq-F3.0.ZF4.VcQMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1436 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >Comments on draft-ietf-pppext-bacp-02.txt: >1. Why must the Link Discriminator be mandatory? Is it so a peer >who receives a Link-Drop-Query-Request can stop transmitting over >a certain line, before its peer sends an LCP Terminate-Request? >I thought this was solved in Sec 4.1 Link Management? >>One reason is that the various links in a bundle may not have the same >>bandwidth,so it would be necessary to identify the specific link that would be >>dropped so the peer knows how much bandwidth would be removed from the bundle. Is the peer going to have the logic to subtract the bandwidth of the the link in question from the total bandwidth...then decide it will need more if the link is removed? If so, couldn't the bandwidth of the link to be removed be included in the Link-Drop-Query-Request? >>Another reason is to prevent conflicts if another link is simultaneously >>removing a link from the bundle for other reasons. Isn't this why we have Link-Drop-Query-Request? Shouldn't each link being removed be blessed with an Ack in a Link-Drop-Query-Response? Or, if side A had planned to drop a link without sending a Link-Drop-Query-Request, and side B was requesting a link be dropped, couldn't side A Nak side B's request, while going ahead with it's dropping of a link? The net result is only one link gets dropped. >2. If it is necessary to indeed have the Link Discriminator option, >it should be longer than 16 bits. Here's why: Some vendors use the >Authentication Protocol, CHAP or PAP, to identify which circuit a >line belongs to on the incoming side of a call. As you know, >Authentication happens after negotiation of LCP options, so it is >impossible to know which circuit a line will end up belonging to. >It would be possible to use a boxwide unique line number for each PPP line >configured in a box, however 32 bits or more may be required to do this. >>So you're saying you have more than 65000 ports on one box? No, I'm saying there is a method of describing a PPP line Number in a decimal number that represents SLOT/CONNECTOR/LINE_NUMBER/LINE_NUMBER_INDEX. >3. Section 4.4 is too complex and too vague. What exactly is the username? >Is it a peer's Chap Name or PAP ID? Recognizing as George Wilkie stated: >"the endpoint discriminator and authentication are both optional." You can't >rely on of the values being present for comparison. >Scott Jackson had replied: >"Now that the Link-Discriminator is mandatory it can also be used to determine >the favoured system, since each implementation negotiates independent values." >But Sec 2.1 p.2 Link-Discriminator says: >"The discriminator is independent for each peer, so each link may have 2 >different LCP Link-Discriminator values, one for each peer." >This seems to indicate each peer could come up with the SAME Link-Discriminator, >therefore breaking the comparison. >I like George Wilkie's idea of favoring the initializer of the first link, >which is reliable,(nothing to compare and no requirement of Link-Discriminator). >>Unfortunately, this is not 100% reliable, as both peers may initiate a call at >>the same time, resulting in 2 links in the bundle. Are there really that many >>implementations that don't implement either authentication or endpoint >>discriminator? You're right, probably most, if not all, implementations will support one or the other, but it would be nice to have one deterministic method that works in all cases. >6. Is it necessary for an implementation to send a Call-Status-Indication, >Sec 4.5.7 p. 12, even when a call is successful? Why? It seems like redundant >information. >>Will implementations be able to figure out which incoming call matches which >>Call or Callback-Request? This might not be so easy if there are multiple >>Call-Requests outstanding, as well as multiple phone numbers on each >>Call-Request. The Call-Status-Indication makes a one to one mapping between a >>Call-Request and a successful call. Is this really likely, to have multiple Call-Requests outstanding? Even so, couldn't the Identifier of the corresponding Call-Request be part of the Call-Status-Indication...Still allowing the Call-Status-Indication only to be sent in failed cases. >9. There is a risk of thrashing when one side is monitoring Transmit and >its peer is monitoring Receive. The Receive's side monitoring may consider >the bundle to be congested, while the Transmit's side does not. So the >Receive monitoring side sends a Call-Request to the peer. Unless the peer >Naks the request based upon its Transmit monitoring, a new line will be added >to the bundle. The next second, the side monitoring Transmit, believing >congestion is not occurring, sends a Link-Drop-Query-Request. The peer >receives it and because it "MUST base its response on its transmit heuristics", >it agrees to drop the link...Then it starts over again. >It should be stated that an implementation which receives a Call- Callback >Request should Nak the Request if its Transmit monitoring (transmit heuristics), >indicates the bundle is uncongested. >>An implementation that only monitors Receive traffic is not BACP compliant. I >>don't think any changes are needed in this area, although I'm sure some of the >>descriptions and explanations could be improved. I guess, I should have said its peer is monitoring BOTH Transmit and Receive, in which case the thrashing could occur. My point is the Receive's congestion logic or thresholds may differ than the peer's Transmit congestion logic or thresholds, causing a disagreement of whether or not congestion is truly occurring. Jim - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 27 16:06:22 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id QAA18081; Wed, 27 Mar 1996 16:06:22 -0500 (EST) Resent-Date: Wed, 27 Mar 1996 16:06:22 -0500 (EST) Date: Wed, 27 Mar 1996 14:05:06 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199603272105.OAA02279@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: L2F Standard Resent-Message-ID: <"lXQ-U.0.DQ4.8tQMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1437 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Cheng Chen/US/3Com > This will not work too well for ISDN. Most ISDN equipment, perhaps even all, > connects the B-channel to HDLC controller as soon as the ISDN call is > answered. ASCII strings prior to PPP need to be encapsulated in some HDLC > frames - the obvious choice is LCP frames. That means, we need to define > another lcpext to do this. Or get creative about using an existing one, such as Endpoint Discriminators. Notice how much simpler, easier, and more secure L2F as well as other PPP things would be if authentication were part of LCP instead of separate. If you do propose yet another new lcpext, how about making it involve some authentication? Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 27 16:34:07 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id QAA19337; Wed, 27 Mar 1996 16:34:07 -0500 (EST) Resent-Date: Wed, 27 Mar 1996 16:34:07 -0500 (EST) Message-Id: <199603272133.NAA02109@stilton.cisco.com> To: vjs@mica.denver.sgi.com (Vernon Schryver) Cc: ietf-ppp@MERIT.EDU Subject: Re: L2F Standard Date: Wed, 27 Mar 1996 13:33:14 -0800 From: Jim Forster Resent-Message-ID: <"f6gOJ2.0.pj4.AHRMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1438 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > Given all of that, what is the purpose of L2F? Why wouldn't a user > prefer to use a combination of > > 1. standard, minimally (e.g. PAP or none) to authenticate PPP to the > local ISP > 2. Mobile IP to get home > 3. end-to-end, IP encryption for security > 4. familiar, old fashioned IP tunneling of anything that isn't IP > > What is provided by a new protocol like L2F that is not already > present with those protocols, all of which are far more advanced than > L2F? Why is L2F not an example of "if you have a hammer (PPP standards > committee), then everything looks like a nail (yet another NCP)." > > There must be something I haven't heard about L2F that is generating > the interest in it. Vernon, I think the critical point is that L2F will work without changes to the zillions of pc's out there. If you remove that constraint another solution may well become preferable. There seems to be huge market that has the constraint. -- Jim - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 27 16:39:33 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id QAA19563; Wed, 27 Mar 1996 16:39:33 -0500 (EST) Resent-Date: Wed, 27 Mar 1996 16:39:33 -0500 (EST) Date: Wed, 27 Mar 1996 13:38:51 -0800 (PST) From: Andy Valencia Message-Id: <199603272138.NAA26842@vandys-lap.cisco.com> To: vjs@mica.denver.sgi.com Cc: ietf-ppp@MERIT.EDU Subject: Re: L2F Standard Newsgroups: cisco.external.ietf.ppp References: <199603271845.LAA01660@mica.denver.sgi.com> X-Newsreader: NN version 6.5.0 #1 (NOV) Resent-Message-ID: <"IWVoc3.0.Pn4.HMRMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1439 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU vjs@mica.denver.sgi.com (Vernon Schryver) writes: > 1. standard, minimally (e.g. PAP or none) to authenticate PPP to the > local ISP > 2. Mobile IP to get home > 3. end-to-end, IP encryption for security > 4. familiar, old fashioned IP tunneling of anything that isn't IP >What is provided by a new protocol like L2F that is not already >present with those protocols, all of which are far more advanced than >L2F? Our goal was to have the user appear in his home network as an *access* client. Which is to say, he appears to have dialed into a box at his home network at which point of entry he gets to do all the stuff which PPP has made available over the past years. This includes the home part of authentication, plus authorization, accounting, and all the optimizations which may be negotiated on the NCP's. Since I leverage what PPP provides once he's tunneled to his home network, I would, in fact, claim that what you get is PPP, which is far more advanced than what multi-protocol mobility currently offers (at least as of the paper I was handed at the last IETF). Andy Valencia - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 27 17:44:10 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id RAA21906; Wed, 27 Mar 1996 17:44:10 -0500 (EST) Resent-Date: Wed, 27 Mar 1996 17:44:10 -0500 (EST) Date: Wed, 27 Mar 1996 15:43:17 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199603272243.PAA02421@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: L2F Standard Cc: forster@cisco.com Resent-Message-ID: <"M6mZ7.0.3M5.lISMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1440 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Jim Forster > I think the critical point is that L2F will work without changes to the > zillions of pc's out there. If you remove that constraint another solution > may well become preferable. There seems to be huge market that has the > constraint. That is a very interesting and provocative thought. Is it fair to describe the L2F protocol as a scheme providing remote/proxy PPP presense? Something that allows the home system to have itself represented by a distant Internet Service Provider over the Internet to its clients in such a way that its clients think that they are talking directly to the home system? Without any change to the client hardware or software? If that's a fair description, then the talk about double CHAPs, unrecognized LCP options at the NAS and so forth must be misplaced. If you set out to build a remote-proxy-PPP mechanism, you'd surely arrange things so that odd PPP bits are handled just like the familiar bits, by the real, home PPP peer and not by the remote proxy. Notice that such a mechanism also makes BA(C)P redundant. If L2F can work over the Internet between a NAS proxy and the home PPP system, including as has been said, handling CCP, then it can also work over an Ethernet or FDDI ring connecting ISDN servers, handling MP. Any complaints about efficiency or double-trips that are not worrisome over the Internet are completely irrelevant over a LAN. No doubt you'll want to allow 128Kbit/sec, dual B-channel L2F connections, which means that you've already considered MP above L2F. You must be going to support bundling links through different Internet Service Providers into a single MP bundle. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 27 18:13:13 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id SAA23241; Wed, 27 Mar 1996 18:13:13 -0500 (EST) Resent-Date: Wed, 27 Mar 1996 18:13:13 -0500 (EST) Date: Wed, 27 Mar 1996 16:12:19 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199603272312.QAA02508@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: L2F Standard Resent-Message-ID: <"jcSSn3.0.sg5.2kSMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1442 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Tim Kolar > ... > > 1. standard, minimally (e.g. PAP or none) to authenticate PPP to the > > local ISP > > 2. Mobile IP to get home > > 3. end-to-end, IP encryption for security > > 4. familiar, old fashioned IP tunneling of anything that isn't IP > ... > your example above assumes that L2F runs only over IP, which is not the > case. Frame-relay and X.25 are also possibilities mentioned in the RFC, > and undoubtedly there will be more. Of course you could argue that you > could just run IP over these lower layers, then your scheme above over IP. > Unfortunately at that point your performance has dropped on the floor. > > As far as tunneling other protocols is concerned, you have two options: One, > you tunnel them from the gateway all the way through to the client. This > is completely inefficient -- there's a reason why most NCPs supply > protocol compression. Two, you tunnel them to the NAS, then convert > them into a PPP stream to the client -- this still causes bandwidth problems > between the GW and NAS, and worse it forces the NAS to understand any and > all protocols that you might want to pass through it. The point of this > is that the NAS is supposed to be a pretty simple peice of hardware. > > So in short, while you could make the scheme above work, it would result > in a lot of unnecessary bytes being passed around. For the environment > L2F was designed for, bytes cost money. > ... Not so: - it is false that IP over Frame-Relay has significantly different "performance" than raw Frame-Relay. Simply tacking 20 bytes of IP, 28 bytes of UDP/IP, or 40 to 48 bytes of TCP/IP header on the front of packets does not make the data bits go slow, unless the FR or x.25 links are already too slow to be of interest. - the PPP working group is a part of the Internet Engineering Task Force. Applications of raw Frame Relay or x.25 packets are standardized in other standards committees. - the only case where I can see using FR or x.25 for remote PPP proxies is for private PPP networks. There are more obvious, simple, and commercially established schemes for providing remote PPP points of presence than L2F. - any "bandwidth problems between the GW and NAS" using one scheme are necessarily present with any other scheme. - any compression that can be done in one mobility scheme can be done in any other. - the only "unnecssary bytes being passed around" using the current standards would be some header bytes, and it is not clear to me that if you count all of the bits on the wire that L2F does not spend just as many bits on headers. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 27 18:05:56 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id SAA22724; Wed, 27 Mar 1996 18:05:56 -0500 (EST) Resent-Date: Wed, 27 Mar 1996 18:05:56 -0500 (EST) Message-Id: <199603272257.RAA07709@funk.com> X-Sender: ken@funk1.funk.com X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 27 Mar 1996 18:02:47 -0500 To: ietf-ppp@MERIT.EDU From: ken@funk.com (Ken Culbert) Subject: Re: Callback (was RE: E.164 & BAP) Resent-Message-ID: <"ZkUQj.0.jY5.RcSMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1441 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU At 02:59 PM 3/27/96 -0500, Ian Duncan wrote: >Given that the current LCP Callback requires authentication to complete, >capturing the user's identity, and then terminate to reconnect what more >is needed? Well, it's a bit cumbersome. Also, the original CBCP provided some additional features such as using pre-specified numbers or calling from a list of numbers and callback delay. The LCP Callback option provides more flexibility as far as types of numbers ("operations"). The authentication issue might be solved by adding a Username option to LCP. ============================================ Ken Culbert ken@funk.com Funk Software, Inc. voice: +1 617 497-6339 222 Third Street fax: +1 617 547-1031 Cambridge, MA 02142 http://www.funk.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Mar 27 21:47:03 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id VAA28282; Wed, 27 Mar 1996 21:47:03 -0500 (EST) Resent-Date: Wed, 27 Mar 1996 21:47:03 -0500 (EST) From: Rob Friend To: ppp Subject: RE: LZS compression Date: Wed, 27 Mar 96 18:45:00 PST Message-Id: <3159FD86@smtpgateway.stac.com> Encoding: 37 TEXT X-Mailer: Microsoft Mail V3.0 Resent-Message-ID: <"wty7K1.0.hv6.MsVMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1443 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU On Mon, 25 Mar 1996 06:25:49 -0500 Ron Cohen wrote: > I am new to this mailing list so I hope I don't ask a previously answered > question: > > 'PPP Stac LZS Compression Protocol draft-ietf-pppext-stacker-06.txt' says: > > > When CCP has not successfully reached the Opened state, or LZS is not > > the primary compression algorithm, exactly one LZS datagram is > > encapsulated in the PPP Information field, where the PPP Protocol > > field indicates type hex 4021 (Stac LZS). > > Note that in the latter case, use of LZS is terminated by the PPP > > LCP Protocol-Reject. > > Why is this special packet needed any how, if it is already known that LZS > compression is not activated or is terminated on that link ? 0x4021 was going to be a way to send LZS packets without first negotiating CCP. However, I doubt anyone actually uses this PID, so it may be dropped in stac-07.txt. Here is my action item from the minutes of the last (Los Angeles, CA) IETF meeting. > Rob is going to drop a note to the PPP list asking who is using 0x4021. If > it is not, the value will be pulled. So, anyone on this mailing list using 0x4021 PID? Does anyone know anyone who plans to use 0x4021 PID? Regards, Robert C. Friend Stac Electronics Applications Engineering 12636 High Bluff Dr (619)794-4542 (voice) San Diego, CA 92130 (619)794-4577 (FAX) Email:rfriend@stac.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Mar 28 09:49:20 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id JAA13268; Thu, 28 Mar 1996 09:49:20 -0500 (EST) Resent-Date: Thu, 28 Mar 1996 09:49:20 -0500 (EST) Date: Thu, 28 Mar 1996 09:47:39 -0500 (EST) From: Ian Duncan X-Sender: iduncan@magnus2 To: Vernon Schryver Cc: ietf-ppp@MERIT.EDU Subject: Re: L2F Standard In-Reply-To: <199603272243.PAA02421@mica.denver.sgi.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"1jGOg1.0.yE3.nQgMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1444 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU On Wed, 27 Mar 1996, Vernon Schryver wrote: > That is a very interesting and provocative thought. > > > Is it fair to describe the L2F protocol as a scheme providing > remote/proxy PPP presense? Something that allows the home system to > have itself represented by a distant Internet Service Provider over the > Internet to its clients in such a way that its clients think that they > are talking directly to the home system? Without any change to the > client hardware or software? Pretty much exactly. Except I'd refrain from calling the remote an ISP, that's what the home system does. The thing out at the edge is a dialup service provider. > If you set out to build a remote-proxy-PPP mechanism, you'd surely arrange > things so that odd PPP bits are handled just like the familiar bits, by > the real, home PPP peer and not by the remote proxy. You'd try but the design would undoubtably rapidly converge on something that looks like L2F. You need to capture and handle some subset of PPP at the NAS. Getting some form of inband identifier (the authentication identity turns out to be the only thing currently present) makes it possible to land a sequence of clients on multiple tunnel destinations from a particular dialup port. It turns out that to do this using CHAP you have to generate the challenge at the NAS and some clients don't (can't??) cope well with a second round. > Notice that such a mechanism also makes BA(C)P redundant. You lost me from here on. I'm all for simplification but you'll need to be a bit more expansive and clear if you want wipe out proactive link control signalling for MP with L2F. -- Ian Duncan Access Products Development Newbridge Networks Corp. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Mar 28 10:03:34 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id KAA13939; Thu, 28 Mar 1996 10:03:34 -0500 (EST) Resent-Date: Thu, 28 Mar 1996 10:03:34 -0500 (EST) Message-ID: <315AAA46.7FDC@ed.nce.sita.int> Date: Thu, 28 Mar 1996 16:03:34 +0100 From: Cathal Fitzgerald Organization: ed.nce.sita.int X-Mailer: Mozilla 2.0GoldB1 (Win95; I) MIME-Version: 1.0 To: ietf-ppp@MERIT.EDU, Vernon Schryver Subject: Re: L2F Standard References: <199603271845.LAA01660@mica.denver.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"LRl1y3.0.aP3.3fgMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1445 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Vernon Schryver wrote: >[snip] > Given all of that, what is the purpose of L2F? Why wouldn't a user > prefer to use a combination of > > 1. standard, minimally (e.g. PAP or none) to authenticate PPP to the > local ISP > 2. Mobile IP to get home > 3. end-to-end, IP encryption for security > 4. familiar, old fashioned IP tunneling of anything that isn't IP No. > > What is provided by a new protocol like L2F that is not already > present with those protocols, all of which are far more advanced than > L2F? Why is L2F not an example of "if you have a hammer (PPP standards > committee), then everything looks like a nail (yet another NCP)." > > There must be something I haven't heard about L2F that is generating > the interest in it. >[snip] > Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Mar 28 11:17:45 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id LAA16489; Thu, 28 Mar 1996 11:17:45 -0500 (EST) Resent-Date: Thu, 28 Mar 1996 11:17:45 -0500 (EST) Message-Id: <9603281617.AA21746@chickadee.watson.ibm.com> X-Mailer: exmh version 1.6.5 12/11/95 To: ietf-ppp@MERIT.EDU Subject: L2F and PPTP security. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 28 Mar 1996 11:17:27 -0500 From: Baiju Patel Resent-Message-ID: <"I9R5v2.0.L14.bkhMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1446 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU There has been lots of discussion on security for L2F. Here is my two cents worth (and it is possibly applicable to PPTP as well - any comments?) L2F (and PPTP) involve three entities: client, NAS and home gateway (HG). - All the three entities may authenticate each other prior to establishing a link between the client and home gateway. o the NAS may want to authenticate the client. o the home gateway may want to authenticate NAS. o the home gateway may want to authenticate client. In principle, all these authentications may take place based on different protocols and keys. o The home gateway may want to authenticate NAS: In many cases, as an added security measure, the home gateway may want to authenticate NAS before establishing a tunnel. This would require that there is a prior agreement between NAS and the home gateway. This authentication should be strictly optional because it can be fairly restrictive and can cause administrative nightmares. Consider following: A hotel wants to provide Internet access to the corporate traveler, whereby, the guest is charged based on the usage for Internet access. For such a scheme to work, having hotel to be able to authenticate itself with large number of corporations is not practical. If same is to be done for a hotel chain, there will lots of locations which will know of the password for the home gateway. This can be a serious security risk. Assuming that the authentication for the tunnel is optional, the overall authentication protocol must be robust in absence of tunnel authentication. If the NAS issues the challenge and forwards both challenge and response to the home gateway, tunnel authentication is almost a requirement for any acceptable level of security. o The NAS needs to authenticate the client, so that it can prevent unauthorized use and figure out whom to send the bill. Similarly, home gateway needs to authenticate client as well. In many cases, a corporation uses one authentication server to authenticate a user for dia-in and local workstation access. Therefore, the corporation will be reluctant to share the password information the all the NASes in the world. Therefore, both the NAS and home gateway should be able to authenticate the client independently (this should be the normal mode of operation and not exception). o It is believed to be fairly easy to break in to public Internet, and therefore, many corporations use firewalls. The authentication mechanism proposed in L2F seems to assume that Internet is fairly secure. That assumption to me is very weak. It will cause security problems for many users. =============================================================================== Baiju V. Patel http://www.research.ibm.com/people/b/baiju baiju@watson.ibm.com IBM T. J. Watson Research Center, H3-D36 30 Saw Mill River Road, Hawthorne, NY 10532 =============================================================================== - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Mar 28 11:59:06 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id LAA18229; Thu, 28 Mar 1996 11:59:06 -0500 (EST) Resent-Date: Thu, 28 Mar 1996 11:59:06 -0500 (EST) Message-Id: <9603281658.AA21580@chickadee.watson.ibm.com> X-Mailer: exmh version 1.6.5 12/11/95 To: ietf-ppp@MERIT.EDU Subject: L2F - Three point problem. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 28 Mar 1996 11:58:58 -0500 From: Baiju Patel Resent-Message-ID: <"hCLpX.0.YS4.MLiMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1448 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU PPP is nice because it involves only two points (two peers or client and server), With both L2F and PPTP now there is a third point into the equation: This leads to what I would like to call three point problem. Let me give an example (consider L2F for the time being and then we will try to see if same holds for PPTP - someone from that group may be able to tell us): It is my understanding from the presentation in LA and discussions on this mailing list that most of the negotiations go on between the home gateway and client (the NAS is basically a forwarding point). A user has account with NAS and uses ISDN to connect to the NAS form different locations. Naturally, this user would like to use multi-link PPP protocol. Now, should MLP run between NAS and client or NAS and home gateway: 1. Run MLP between NAS and client. This seems to be the logical choice but we have already agreed that NAS is just a forwarding point. Let us assume that we will negotiate and run MLP between NAS and client regardless of our earlier decision (somehow we can do that). Now, as the load increases, the user would like to add a link. He uses BACP to notify NAS that he am going to add a link (so now BACP has to run between NAS and client). NAS determines that it has spare lines available, and since the user is willing to pay for it, its tunneling protocol is not really loaded, so why not. Let the poor user go ahead and add a link. It so happens that the home-gateway is loaded because everyone is dialing in (due to a snow storm) and it would not be able to handle added bandwidth requirement due to the added lines. However, now it does not have any say it it. Therefore, clearly, the user pays for additional capacity on the line but the packets are dropped at the home gateway, which leads to lots of retransmissions, possibly going back to slow start for TCP and so on. And thus, the client takes a big performance hit, while expecting a performance gain and yet pays for it. This is not the case when the user directly dials into the home network because the point of congestion is involved in the BACP negotiations. 2. Run MLP between the home gateway and client. In this case, clients will have to take a unilateral decision (without consulting NAS) about adding and removing lines. If this would make sense, we would not need protocols such as BACP. My primary concern is that unless we look at each and every protocol that is part of the PPP protocol suit to determine between which two of the tree points should this protocol be run, we cannot be sure that communication will take place as expected! =============================================================================== Baiju V. Patel (external): http://www.research.ibm.com/people/b/baiju (internal): http://w3.watson.ibm.com/~baiju/baiju.html IBM T. J. Watson Research Center, H3-D36 30 Saw Mill River Road, Hawthorne, NY 10532 =============================================================================== - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Mar 28 11:58:47 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id LAA18192; Thu, 28 Mar 1996 11:58:47 -0500 (EST) Resent-Date: Thu, 28 Mar 1996 11:58:47 -0500 (EST) Date: Thu, 28 Mar 96 16:54:08 GMT Message-Id: <9603281654.AA03311@queenbee.spider.co.uk> From: Malcolm Campbell Subject: L2F Draft To: ietf-ppp@MERIT.EDU X-Mailer: Sendmail/Ream v5.1.23 (Vorsprung Dourish Technik) Phone: +44 131 554 9424 (Work) Resent-Message-ID: <"R_lfm1.0.1S4.1LiMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1447 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Phew, what a lot of L2F mail - I leave my deak for a day, and come back to all that... Ive digested my comments into one message.. --- Malcolm Tim Kolar > Number two seems better to me. Without saying that this is necessarily > what we should do, let me rough it out here so that I make sure I understand > you: > > We add a new optional field to the L2F_OPEN request for a MID. > This field is in the same format as the L2F_ACK_LCP1 and > L2F_ACK_LCP2 fields, and will be called L2F_LCP_REQ. > The field will consist of the first LCP_REQ received from the client. > This field is not intended to be used as an actual LCP request on > the home gateway, but rather is used as a hint for the home gateway > to decide if it should renegotiate LCP. The only option this 'cheats' the client of is something it requests in a second round of negotiation - but if it was important, it'd be in the first CFRQ, right? I think this resolves my concerns with negotiation in general. vjs@mica.denver.sgi.com (Vernon Schryver): > In my view, that is a fatal flaw in using token cards with PPP. Token > card security that requires humans to read token card LCD windows is > essentially useless for PPP. Having humans in the loop cannot be made > to work tolerably with demand- dialing (a.k.a. Bandwidth on Demand). > It also violates a fundamental and required feature of CHAP that allows > a peer to demand a new round of authentication at any time. I agree entirely. CHAP _requires_ that you are able to demand re-authentication at any time - if these token cards dont allow that, they shouldnt use CHAP - or we need to define a new CHAP option that says "you cant rechallenge me - Im broken". I dont think we should encourage broken behaviour by working around it in a new draft. The Home Gateway should be able to send CHAP challenges again whenever it likes. Tim Kolar : > However, if this is to be a successful protocol there must be some > recognition of how people are using PPP today. We're seeing token cards > being used in this fashion, and we're getting complaints about second > CHAP requests being sent. As such, we want to make sure that we at least > have the option of supporting these people over L2F. I think this is a problem that needs to be fixed in CHAP, not in L2F. ------------------------- malcolmc@europe.shiva.com ------------------------- Malcolm Campbell, Project Consultant | Spider Software, Shiva Europe Ltd., Tel: +44 131 555 5166 | Shiva Park, Stanwell Street Fax: +44 131 555 0664 | Edinburgh, EH6 5NG, Scotland - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Mar 28 12:31:16 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id MAA19925; Thu, 28 Mar 1996 12:31:16 -0500 (EST) Resent-Date: Thu, 28 Mar 1996 12:31:16 -0500 (EST) Message-ID: <315ACCAA.75AB@ed.nce.sita.int> Date: Thu, 28 Mar 1996 18:30:18 +0100 From: Cathal Fitzgerald Organization: ed.nce.sita.int X-Mailer: Mozilla 2.0GoldB1 (Win95; I) MIME-Version: 1.0 To: ietf-ppp@MERIT.EDU, "C. Harald Koch" Subject: Re: L2F Standard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"9sVaL1.0.6t4.WpiMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1449 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU C. Harald Koch wrote: > > In message <315AAA46.7FDC@ed.nce.sita.int>, Cathal Fitzgerald writes: > > > > Vernon Schryver wrote: > > >[snip] > > > Given all of that, what is the purpose of L2F? Why wouldn't a user > > > prefer to use a combination of > > > > > > 1. standard, minimally (e.g. PAP or none) to authenticate PPP to the > > > local ISP > > > 2. Mobile IP to get home > > > 3. end-to-end, IP encryption for security > > > 4. familiar, old fashioned IP tunneling of anything that isn't IP > > > > No. > > That was wonderfully enlightening... Care to say *why*?:)Leaving authentication to the ISPs is a pill that most companies who are serious about security won't easily swallow. If "anything that isn't IP" is tunnelled in IP which is then encrypted, which standard software would be used to do this? (I'm assuming that end-to-end means dial-up client to home gateway.) End-to-end PPP allows the home network to make all the decissions about who to let in. It also means that any standard PPP client can be used with all the protocols valid on the home network, and with the home network's addressing scheme. > > -- > C. Harald Koch | Border Network Technologies Inc. > chk@border.com | Senior System Developer > +1 416 368 7157 (voice) | 20 Toronto Street, Suite 400, Toronto ON M5C 2B8 > +1 416 368 7789 (fax) | Tary: a unit of intelligence; As in "military". - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Mar 28 13:33:29 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id NAA22902; Thu, 28 Mar 1996 13:33:29 -0500 (EST) Resent-Date: Thu, 28 Mar 1996 13:33:29 -0500 (EST) Date: Thu, 28 Mar 1996 10:32:40 -0800 (PST) From: Andy Valencia Message-Id: <199603281832.KAA29360@vandys-lap.cisco.com> To: baiju@watson.ibm.com Cc: ietf-ppp@MERIT.EDU Subject: Re: L2F and PPTP security. Newsgroups: cisco.external.ietf.ppp References: <9603281617.AA21746@chickadee.watson.ibm.com> X-Newsreader: NN version 6.5.0 #1 (NOV) Resent-Message-ID: <"kfLHL.0.bb5.qjjMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1452 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU In cisco.external.ietf.ppp you write: > Assuming that the authentication for the tunnel is optional, > the overall authentication protocol must be robust in absence > of tunnel authentication. If the NAS issues the challenge and > forwards both challenge and response to the home gateway, > tunnel authentication is almost a requirement for any > acceptable level of security. Have your Home security server record challenge/ID values, and fail authentication if it sees a replay. This wouldn't be a bad thing to do with a local dial-in pool, really. > o The NAS needs to authenticate the client, so that it can > prevent unauthorized use and figure out whom to send the bill. Which is why the L2F_OPEN forwards the auth information he gathered and can receive an L2F_CLOSE. This means the Home said "nope, he isn't mine--don't give me the connection, and don't bill me, either". > Similarly, home gateway needs to authenticate client as > well. In many cases, a corporation uses one > authentication server to authenticate a user for dia-in and > local workstation access. > Therefore, the corporation will be reluctant to share > the password information the all the NASes in the world. And this is not required in L2F. > Therefore, both the NAS and home gateway should be able to > authenticate the client independently (this should be the > normal mode of operation and not exception). No. The NAS needs only to be able to ask the Home Gateway for the client's *claimed* name. Sparing the NAS of requiring an a priori authentication database for this class of clients was highly desirable. > o It is believed to be fairly easy to break in to public > Internet, and therefore, many corporations use > firewalls. I question this. It is easy to launch attacks from an Internet connection. If you mean that the backbone is violated (presumably to install packet snooping), please provide facts on its frequency. >The authentication mechanism proposed in L2F seems > to assume that Internet is fairly secure. That assumption > to me is very weak. It will cause security problems for many > users. Well, you have to state very clearly where you think the weak links are. As I said earlier, if you don't trust the ISP, then securing the tunnel doesn't buy you anything--you need to run IPsec from client to Home Gateway. If you trust the ISP but not the backbone, then I guess L2F could help. Is this, really, enough security to make it worth specifying the encryption? There aren't that many backbone entities, and they're run pretty tightly--please provide data if you think they're a particular security risk. Regards, Andy Valencia - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Mar 28 13:25:49 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id NAA22151; Thu, 28 Mar 1996 13:25:49 -0500 (EST) Resent-Date: Thu, 28 Mar 1996 13:25:49 -0500 (EST) Message-Id: <9603281825.AA20264@chickadee.watson.ibm.com> X-Mailer: exmh version 1.6.5 12/11/95 To: Cathal Fitzgerald Cc: ietf-ppp@MERIT.EDU Subject: Re: L2F Standard In-Reply-To: Your message of Thu, 28 Mar 1996 18:30:18 +0100. <315ACCAA.75AB@ed.nce.sita.int> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 28 Mar 1996 13:25:41 -0500 From: Baiju Patel Resent-Message-ID: <"4FIE21.0.uP5.gcjMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1451 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > C. Harald Koch wrote: > > > > In message <315AAA46.7FDC@ed.nce.sita.int>, Cathal Fitzgerald writes: > > > > > > Vernon Schryver wrote: > > > >[snip] > > > > Given all of that, what is the purpose of L2F? Why wouldn't a user > > > > prefer to use a combination of > > > > > > > > 1. standard, minimally (e.g. PAP or none) to authenticate PPP to the > > > > local ISP > > > > 2. Mobile IP to get home > > > > 3. end-to-end, IP encryption for security > > > > 4. familiar, old fashioned IP tunneling of anything that isn't IP > > > > > > No. > > > > That was wonderfully enlightening... Care to say *why*?:)Leaving authentication to the ISPs is a pill that most companies who are serious about > security won't easily swallow. > I would not worry about that. Mobile IP has its own authentication. The mobile client will be authenticated by the home agent (aka home gateway). Baiju -- =============================================================================== Baiju V. Patel http://www.research.ibm.com/people/b/baiju IBM T. J. Watson Research Center, H3-D36 30 Saw Mill River Road, Hawthorne, NY 10532 =============================================================================== - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Mar 28 13:24:21 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id NAA22089; Thu, 28 Mar 1996 13:24:21 -0500 (EST) Resent-Date: Thu, 28 Mar 1996 13:24:21 -0500 (EST) Date: Thu, 28 Mar 1996 11:23:35 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199603281823.LAA05233@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: L2F Standard Resent-Message-ID: <"VbaOV1.0.uO5.GbjMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1450 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Ian Duncan > ... > > If you set out to build a remote-proxy-PPP mechanism, you'd surely arrange > > things so that odd PPP bits are handled just like the familiar bits, by > > the real, home PPP peer and not by the remote proxy. > > You'd try but the design would undoubtably rapidly converge on something that > looks like L2F. You need to capture and handle some subset of PPP at the NAS. > Getting some form of inband identifier (the authentication identity turns out > to be the only thing currently present) makes it possible to land a sequence > of clients on multiple tunnel destinations from a particular dialup port. It > turns out that to do this using CHAP you have to generate the challenge at > the NAS and some clients don't (can't??) cope well with a second round. Except for the bugs in some implementations or installations that croak at extra rounds of authentication, we almost agree. Having the proxy fake and/or infer things from ordinary LCP bits strikes me as within the standard rules for implementing standards. The first rule is "if you can't prove I'm violating the standard by watching only the bits on the wire, then I'm not violating it, no matter what I'm really doing." I'm agree with you and others who have said that the NAS can do as the Motorola Bitsurfer and other sync-async PPP boxes do, and pass most PPP packets transparently, but fiddle with some others. This is the same idea as in the necessarily "translating" or "translucent" and not "transperent" FDDI-Ethernet bridges. The Motorola Bitsurfer Pro fiddles with LCP packets enough to translate between an ISDN PPP server running MP on two B channels and a personal computer using a single 115 kbit/sec async PPP link. The personal computer thinks it is talking to a Hayes compatible modem, and does not imagine how its LCP and other PPP packets look to the ISDN PPP server. And conversely, the ISDN PPP server has no idea that the client is really a cheap or freeware async PPP implementation. I don't know, but I assume that a Bitsurfer Pro allows CCP, BCP, and all other PPP packets and LCP options unknown to it simply by passing them through unchanged. > > Notice that such a mechanism also makes BA(C)P redundant. > > You lost me from here on. I'm all for simplification but you'll need to > be a bit more expansive and clear if you want wipe out proactive link > control signalling for MP with L2F. What is "proactive link control signalling"? It sounds like the subject of a "Dilbert" comic strip. As far as I know, BACP meets only the following two needs: 1. preventing "thrashing" I've asked many times and in several places, but no one has offered a scenario when this thrashing happpens. As far as I can tell, the only thrashing that BACP prevents is when things have been misconfigured, in which case BACP will also prove ineffective. People are just too inventive. 2. providing a phone number for a second link in an MP bundle. In real life, there are only the following cases: - the phone number for the second link is fixed and constant, and needs no chitchat with BACP for it to be known. The second phone number is often the same as the first, with all ports of the server in a hunt group. This is the situation with the zillions of bandwidth-on-demand MP installations in current, active, commercial use. - the phone number for the second link varies unpredictably. This situation apparently only occurs when there are two or more PPP boxes sharing a single hunt group, and it is necessary for 2nd MP links to find the same chassis as the first MP link. The idea is to use BACP to tell the PPP client a phone number not in the hunt group for a port on the box that got the first call. I think there is a fatal error in this scenario, since it assumes that it makes sense to reserve about 50% of the ports on each PPP box just in case clients want to do MP. What Internet Service Provider is going to keep 50% of its ports out of its main hunt group? Still, consider solving #2 with L2F instead of BACP. You give clients a single phone number. Thanks to L2F, all of their PPP links are connected to a single PPP system that reassembles MP fragments, regardless of how many different physical boxes are involved. You do not need to reserve any of those expensive server ports; they can all be in your single hunt group. Assuming that L2F really is transparent to everything it does not understand, then MP works just fine above L2F. I cannot see any problem with MP with L2F. Notice also that using L2F to solve BACP's target problems avoids another large problem with BACP. For BACP to be useful, you must get clients to implement it. If you do not expect clients to handle authentication as required since the beginning (multiple rounds), how in the world can you expect them to add code to do BACP? Look in the mailing list archives and notice that those who are working on BACP have addresses at ISDN PPP server vendors, not client vendors. On the other hand, L2F seems intended to be invisible to clients, and not require them to change. There are other major advantages. You can give clients an 800 number, and use telco routing so that when your local Point Of Presence is busy, crashed, or whatever, your customers are automagically connected with some other POP. Your customers would be able to freely use MP, without them even knowing all of your local ports are busy. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Mar 28 13:43:14 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id NAA23189; Thu, 28 Mar 1996 13:43:14 -0500 (EST) Resent-Date: Thu, 28 Mar 1996 13:43:14 -0500 (EST) Date: Thu, 28 Mar 96 18:38:36 GMT Message-Id: <9603281838.AA04396@queenbee.spider.co.uk> From: Malcolm Campbell Subject: Re: L2F Draft To: Andy Valencia In-Reply-To: Andy Valencia's message of Thu, 28 Mar 1996 10:37:29 -0800 (PST) X-Mailer: Sendmail/Ream v5.1.23 (Vorsprung Dourish Technik) Phone: +44 131 554 9424 (Work) Cc: ietf-ppp@MERIT.EDU Resent-Message-ID: <"FsZge2.0.6g5.ysjMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1453 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > >I think this is a problem that needs to be fixed in CHAP, not in L2F. > > Encourage may be too strong a word, but "accomodate" is a requirement. If > L2F breaks even 1% of the clients out there, it's dead in the water WRT the > current market. Scummy old engineer, I'll abandon the high ground in favor > of bucks every time. :-) Sure, I understand what you're saying w.r.t L2F - but this doesnt fix the problem with CHAP anyway - the Home gateway may still re-challenge at some point, and the client is still unable to respond.. (Ok, I havent actually ever seen a CHAP implementation re-challenge, but they perhaps should) --- Malcolm - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Mar 28 14:01:42 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id OAA24353; Thu, 28 Mar 1996 14:01:42 -0500 (EST) Resent-Date: Thu, 28 Mar 1996 14:01:42 -0500 (EST) Message-Id: <9603281900.AA20420@chickadee.watson.ibm.com> X-Mailer: exmh version 1.6.5 12/11/95 To: Andy Valencia Cc: ietf-ppp@MERIT.EDU, "Baiju V. Patel" Subject: Re: L2F and PPTP security. In-Reply-To: Your message of Thu, 28 Mar 1996 10:32:40 PST. <199603281832.KAA29360@vandys-lap.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 28 Mar 1996 14:00:42 -0500 From: Baiju Patel Resent-Message-ID: <"TgPKy.0.wx5.V7kMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1454 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > In cisco.external.ietf.ppp you write: > > > Assuming that the authentication for the tunnel is optional, > > the overall authentication protocol must be robust in absence > > of tunnel authentication. If the NAS issues the challenge and > > forwards both challenge and response to the home gateway, > > tunnel authentication is almost a requirement for any > > acceptable level of security. > > Have your Home security server record challenge/ID values, and fail > authentication if it sees a replay. This wouldn't be a bad thing to do > with a local dial-in pool, really. I guess this could work (with minor irritation, say you are travelling and dial-in from different locaitons, the challange may be same - in that case you may just have to retry). Do you think this is implementation issue or it needs to be spec somewhere? > > > o The NAS needs to authenticate the client, so that it can > > prevent unauthorized use and figure out whom to send the bill. > > Which is why the L2F_OPEN forwards the auth information he gathered and can > receive an L2F_CLOSE. This means the Home said "nope, he isn't mine--don't > give me the connection, and don't bill me, either". > > > Similarly, home gateway needs to authenticate client as > > well. In many cases, a corporation uses one > > authentication server to authenticate a user for dia-in and > > local workstation access. > > Therefore, the corporation will be reluctant to share > > the password information the all the NASes in the world. > > And this is not required in L2F. > > > Therefore, both the NAS and home gateway should be able to > > authenticate the client independently (this should be the > > normal mode of operation and not exception). > > No. The NAS needs only to be able to ask the Home Gateway for the client's > *claimed* name. Sparing the NAS of requiring an a priori authentication > database for this class of clients was highly desirable. > If I understand correctly from above three comments, the NAS does not care to authenticate you. All it wants to do is to talk to the home gateway and determine that you are a authorised used for the home gateway and home gateway is responsible for your charges and will be billed. At our site, I make the PPP calls, and pay the bills and then IBM reemburses me for the expense. With current scheme (as in L2F, IBM will not have that choice). Am I right? This also restrict use of L2F to the hotel example I have in my original note where the hotel can charge me for internet use and the charges will appear in my hotel bill for which I can get re-embursed. > > o It is believed to be fairly easy to break in to public > > Internet, and therefore, many corporations use > > firewalls. > > I question this. It is easy to launch attacks from an Internet connection. > If you mean that the backbone is violated (presumably to install packet > snooping), please provide facts on its frequency. > I wish I could but I don't have any. > >The authentication mechanism proposed in L2F seems > > to assume that Internet is fairly secure. That assumption > > to me is very weak. It will cause security problems for many > > users. > > Well, you have to state very clearly where you think the weak links are. As > I said earlier, if you don't trust the ISP, then securing the tunnel doesn't > buy you anything--you need to run IPsec from client to Home Gateway. If you > trust the ISP but not the backbone, then I guess L2F could help. Is this, > really, enough security to make it worth specifying the encryption? There > aren't that many backbone entities, and they're run pretty tightly--please > provide data if you think they're a particular security risk. > I guess IPsec is an option that is independent of L2F. It is entirely up to the users to determine if they want to pay the cost. However, I do have a concern with having to trust ISPs. There are lots of small and big ISPs. The corporations have to determine which ISPs are to be trusted, and work out an arrangement with them for billing and authentication. That seems like problem to be. If one can somehow take authenticating ISPs out of the loop, that may make life simple. Once again, I do not have any data on what kinds of attacks are frequent on internet. Thanks for the response. Baiju > Regards, > Andy Valencia - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Mar 28 14:07:20 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id OAA24798; Thu, 28 Mar 1996 14:07:20 -0500 (EST) Resent-Date: Thu, 28 Mar 1996 14:07:20 -0500 (EST) Date: Thu, 28 Mar 1996 11:51:38 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199603281851.LAA05366@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: L2F Standard Resent-Message-ID: <"KrKeh1.0.F36.aDkMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1455 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU From: Cathal Fitzgerald > > > 1. standard, minimally (e.g. PAP or none) to authenticate PPP to the > > > local ISP > > > 2. Mobile IP to get home > > > 3. end-to-end, IP encryption for security > > > 4. familiar, old fashioned IP tunneling of anything that isn't IP > ... (reformated for legibility) >> Leaving authentication to the ISPs is a pill that most companies who >> are serious about security won't easily swallow. That's an understatment. > If "anything that isn't IP" is tunnelled in IP which is then encrypted, > which standard software would be used to do this? (I'm assuming that > end-to-end means dial-up client to home gateway.) I was specifically thinking of the results of the current IETF working group on IP encryption, but the other, older schemes would also work. The IETF IP encryption group has gotten as far as RFC's, not just initial versions of drafts. Do they have interoperable implementations yet? In any case, there will be "standard software" that does that trick. We all no doubt know that there have already been mobile-IP 'bake-offs' of existing implementations. I noticed announcements of at least two. > End-to-end PPP allows the home network to make all the decissions about > who to let in. It also means that any standard PPP client can be used > with all the protocols valid on the home network, and with the home > network's addressing scheme. The same things apply to mobile IP. That is the purpose of mobile IP. (With "standard" understood to mean "compliant" instead of "old junk.") As far as I can tell, L2F and mobile IP are distinguished by: - mobile-IP is a from-scratch effort to solve the the entire problem that assumes new software on all three systems, home gateway, remote, and forwarder. - L2F is a hack that assumes new software on the home gateway and forwarder (NAS), but works with old, junk software on the remote. (I do not consider "hack" prejorative.) - L2F does not attempt to solve all of the problems addressed by mobile-IP. (That is both good and bad.) - L2F is also intended to address situations completely irrelevant, uninteresting, and inadmissable in this venue, such as raw x.25 and frame relay links between the GW and NAS. I think L2F has promise as a temporary solution for mobile-IP until real mobile-IP software is commercially available and the problems in mobile-IP have found and fixed in the field. I think L2F is also very interesting as a cleaner 'back-end' solution to the multiple-ISDN-server- box problem that BACP is to solve. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Mar 28 15:39:24 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id PAA27896; Thu, 28 Mar 1996 15:39:24 -0500 (EST) Resent-Date: Thu, 28 Mar 1996 15:39:24 -0500 (EST) Message-ID: <315AF903.5586@ed.nce.sita.int> Date: Thu, 28 Mar 1996 21:39:31 +0100 From: Cathal Fitzgerald Organization: ed.nce.sita.int X-Mailer: Mozilla 2.0GoldB1 (Win95; I) MIME-Version: 1.0 To: ietf-ppp@MERIT.EDU Subject: Authentication in L2F/PPTP type tunneling. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"ElpD31.0.fp6.jZlMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1456 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU For the sake of argument, lets say that we're using PPP from end-to-end. The NAS uses CHAP and the home gateway is allowed to renegotiate LCP and reauthenticate using CHAP which the client copes with. Under normal circumstances the service provider only sees the username field and a hash value in response to its challenge. If the service provider sets the NAS to negotiate PAP instead of CHAP (maliciously), I think most client software implementations will accept this (is this accurate?). They will then gladly hand over the username and password in clear. If the service provider wanted to complete the facade it could issue itself with a CHAP challenge and compute the response and communicate this info to the home gateway. No one is any the wiser unless the remote user checks a log file to see what was actually negotiate and the service provider now has a valid password for the customers VPN. What I'm getting at is not that service providers would actually do this, but how do you convince customers that they're using a secure service? Using a script as with the X.28 service is a possible way arround this, but as Tim Kolar points out ISDN???? Another way around this would be setting the client to only agree to CHAP, but do any implementations actually support this? Regards, Cathal. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Mar 28 15:51:28 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id PAA28315; Thu, 28 Mar 1996 15:51:28 -0500 (EST) Resent-Date: Thu, 28 Mar 1996 15:51:28 -0500 (EST) Message-ID: <315AFBF1.3475@ed.nce.sita.int> Date: Thu, 28 Mar 1996 21:52:02 +0100 From: Cathal Fitzgerald Organization: ed.nce.sita.int X-Mailer: Mozilla 2.0GoldB1 (Win95; I) MIME-Version: 1.0 To: Vernon Schryver CC: ietf-ppp@MERIT.EDU Subject: Re: L2F Standard References: <199603281851.LAA05366@mica.denver.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"9b8Oy2.0.Bw6.BllMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1457 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Vernon Schryver wrote: >[snip] > > > End-to-end PPP allows the home network to make all the decissions about > > who to let in. It also means that any standard PPP client can be used > > with all the protocols valid on the home network, and with the home > > network's addressing scheme. > > The same things apply to mobile IP. That is the purpose of mobile IP. > (With "standard" understood to mean "compliant" instead of "old junk.") I didn't know there was any provision in the IP mobility draft for other protocols such as IPX, Decnet, Netbios,... to be encapsulated by the mobile IP agent. Is this the case? Regards, Cathal. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Mar 28 20:07:20 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id UAA05332; Thu, 28 Mar 1996 20:07:20 -0500 (EST) Resent-Date: Thu, 28 Mar 1996 20:07:20 -0500 (EST) Date: Thu, 28 Mar 1996 18:06:16 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199603290106.SAA06233@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: L2F and PPTP security. Resent-Message-ID: <"0lpyw1.0.yI1.TUpMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1458 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I appologize for jabbering so much so often in a single day. > From: Andy Valencia > ... > Have your Home security server record challenge/ID values, and fail > authentication if it sees a replay. This wouldn't be a bad thing to do > with a local dial-in pool, really. On a local dial-in pool? Not for L2F? Why? If you don't reuse challenges since you generate them properly, then replay attacks are practically impossible, and it would be a waste to record the random numbers. Worse, if your random challenge generator has a flaw you don't know, then the existence of the list is a security problem. > ... > > o It is believed to be fairly easy to break in to public > > Internet, and therefore, many corporations use > > firewalls. > > I question this. It is easy to launch attacks from an Internet connection. > If you mean that the backbone is violated (presumably to install packet > snooping), please provide facts on its frequency. It's not only a technical but also a marketing issue. Among those who stop and think about real life (eg. poorly paid clerks, dumpster diving, telephone catalog sales, or the last 5 bogus charges on your credit card), who is particularly concerned about whether their credit card number goes over the Internet in the clear? Still, the internet-commmerce market requires good encryption. > >The authentication mechanism proposed in L2F seems > > to assume that Internet is fairly secure. That assumption > > to me is very weak. It will cause security problems for many > > users. > > Well, you have to state very clearly where you think the weak links are. As > I said earlier, if you don't trust the ISP, then securing the tunnel doesn't > buy you anything--you need to run IPsec from client to Home Gateway. If you > trust the ISP but not the backbone, then I guess L2F could help. Is this, > really, enough security to make it worth specifying the encryption? There > aren't that many backbone entities, and they're run pretty tightly--please > provide data if you think they're a particular security risk. Within the last week, I saw a current, official CERT warning of "many" recent attacks involving installing sniffers on corrupted systems to get passwords to break into other systems. I tend to discount CERT's hysteria, but you must know about the famous installation of sniffers "on the backbone" in the Bay Area, and the resulting break-ins last year (or the year before?). I thought L2F was to be installed in hotels. How many hotels are "on the backbone"? Do you trust the security of hotel networks? If you were one of those storied corporate spies, wouldn't it be smart to consider hotels along highway 101 between San Jose and San Francisco? We all know operators of Internet Service Providers that are, well, not exactly world class experts on computers. Arguments based on trusting the wires between the NAS and GW or of the NAS itself are weak. ] From: Cathal Fitzgerald (reformated for 80-column legibility) ] ... ] If the service provider sets the NAS to negotiate PAP instead of CHAP ] (maliciously), I think most client software implementations will accept ] this (is this accurate?). They will then gladly hand over the username ] and password in clear. If the service provider wanted to complete the ] facade it could issue itself with a CHAP challenge and compute the ] response and communicate this info to the home gateway.... Whose (client) implementation requires the same (username,password) pair for PAP authentication as for CHAP? I'd hope none, but ... I think many ISP's configure their servers to use the same secret for PAP and CHAP, but that speaks only to how much you should trust ISP security in general and NAS's in particular. ] What I'm getting at is not that service providers would actually do ] this, but how do you convince customers that they're using a secure ] service? ... I agree it's a marketing issue. The best response is technical, to not require trusting third parties such as hotels and ISP's. | From: Cathal Fitzgerald | > > End-to-end PPP allows the home network to make all the decissions about | > > who to let in. It also means that any standard PPP client can be used | > > with all the protocols valid on the home network, and with the home | > > network's addressing scheme. | > | > The same things apply to mobile IP. That is the purpose of mobile IP. | > (With "standard" understood to mean "compliant" instead of "old junk.") | | I didn't know there was any provision in the IP mobility draft for other |protocols such as IPX, Decnet, Netbios,... to be encapsulated by the mobile IP | agent. Is this the case? The IP mobility draft need not say anything more about tunneling IPX, DECnet, NetBIOS, or NetBUI than it says about rcp, rlogin, telnet, or NFS. I suspect some of those will not be common candidates for either L2F or mobile IP, but that's a different discussion. Again, if the issue is something like "how do you run DECnet over Frame Relay," let me raise a point of order. This is an <> Engineering Task Force Working Group mailing list, and while such questions may be interesting, they are not and must not be major issues here. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Mar 28 22:25:04 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id WAA08595; Thu, 28 Mar 1996 22:25:04 -0500 (EST) Resent-Date: Thu, 28 Mar 1996 22:25:04 -0500 (EST) Date: Wed, 27 Mar 1996 08:27:14 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199603271527.IAA01261@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: BACP without MP Resent-Message-ID: <"RBdw41.0.262.BWrMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1460 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Ron Cohen > > There is something basic which is not clear to me. > > There are cases in which BA(C)P can be used without any regard to MP. > For example when only one link is used in an on-demand basis between two > devices, were each of the device may initiate the call according to some > pre-configured traffic triggers. In this case there is sense sending > Link-Drop-Query-Request before actualy hanging. > ... What good is sending the Link-Drop-Query-Request before actualy hanging? Why not just send a Terminate-Request? I've been running a symmetric demand-dialed PPP link for years, and have never needed more than Terminate-Requests. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Mar 28 22:23:12 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id WAA08555; Thu, 28 Mar 1996 22:23:12 -0500 (EST) Resent-Date: Thu, 28 Mar 1996 22:23:12 -0500 (EST) Date: Thu, 28 Mar 1996 19:22:27 -0800 From: Tim Kolar Message-Id: <199603290322.TAA17381@greatdane.cisco.com> To: vjs@mica.denver.sgi.com Subject: Re: L2F Standard Cc: ietf-ppp@MERIT.EDU Resent-Message-ID: <"1rE0w2.0.R52.LUrMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1459 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Hello Vernon, I'm afraid I disagree with you on several points. In article <199603272312.QAA02508@mica.denver.sgi.com> you write: > > - it is false that IP over Frame-Relay has significantly different > "performance" than raw Frame-Relay. Simply tacking 20 bytes of > IP, 28 bytes of UDP/IP, or 40 to 48 bytes of TCP/IP header on > the front of packets does not make the data bits go slow, unless > the FR or x.25 links are already too slow to be of interest. > We are interested, and our customers are interested, in running this protocol over what you would call slow links. Many of our customers on other continents do not have access to what you seem to feel is a minimal link speed to be of interest. A 56 Kbaud frame-relay connection with 16 port NAS hanging off it needs all the help it can get. This means everything from knocking bytes off of packet headers to removing the need to run broadcast intensive protcols across the wire. > - the PPP working group is a part of the Internet Engineering Task > Force. Applications of raw Frame Relay or x.25 packets > are standardized in other standards committees. You mention this in another message, and I'm afraid I'm quite baffled by this attitude. To my knowledge the IETF is not in competition with these other standards committees, and there is nothing to be gained by making sure that IETF protocols will not successfully interact with theirs. True, IETF protocol development cannot be driven by the existence of outside protocols -- but neither can it ignore them. > > - the only case where I can see using FR or x.25 for remote PPP > proxies is for private PPP networks. There are more obvious, > simple, and commercially established schemes for providing > remote PPP points of presence than L2F. We at Cisco are in the business of providing remote PPP points of presences, for commercial companies, and it is a need to provide satisfactory solutions to our customers that is driving this RFC. As individuals, the authors of this RFC feel that the best way for this solution to happen is with a public and agreed upon standard -- and as a commercial entity, Cisco is following our lead. This RFC would not exist if we felt that a succesful commercially established scheme existed, or was possible with the existing standards. > > - any "bandwidth problems between the GW and NAS" using one scheme > are necessarily present with any other scheme. If you accept the idea that an extra 20 to 48 bytes per packet, plus running all of your protocols out to the NAS (Appletalk -- yech) does not present a bandwidth problem, then this would be true. I don't accept this. In fact, I would not even attempt to present it to a customer. > > - any compression that can be done in one mobility scheme can be > done in any other. If and only if you add a tremendous amount of complexity to the NAS, which is not acceptable to many of our customers. At a distance the idea looks good, but the details of the client, NAS, and GW responsibilties make the idea unfeasible. > > - the only "unnecssary bytes being passed around" using the current > standards would be some header bytes, and it is not clear to me > that if you count all of the bits on the wire that L2F does not > spend just as many bits on headers. Once again, if you consider 20 to 48 bytes per packet as trivial, then this would be true. I will say again, in the environment for which L2F was designed, bytes cost money. The IETF has traditionally supported these environments (how many bytes does PPP header compression save?) and to my knowledge nothing has changed in that regard. Respectfully, -Tim - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Mar 29 05:40:39 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id FAA17613; Fri, 29 Mar 1996 05:40:39 -0500 (EST) Resent-Date: Fri, 29 Mar 1996 05:40:39 -0500 (EST) Date: Fri, 29 Mar 96 10:35:31 GMT Message-Id: <9603291035.AA08536@queenbee.spider.co.uk> From: Malcolm Campbell Subject: Re: Authentication in L2F/PPTP type tunneling. To: Cathal Fitzgerald In-Reply-To: Cathal Fitzgerald's message of Thu, 28 Mar 1996 21:39:31 +0100 X-Mailer: Sendmail/Ream v5.1.23 (Vorsprung Dourish Technik) Phone: +44 131 554 9424 (Work) Cc: ietf-ppp@MERIT.EDU Resent-Message-ID: <"91CUA3.0.3H4.0uxMn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1461 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > If the service provider sets the NAS to negotiate PAP instead of CHAP > (maliciously), I think most client software implementations will accept > this (is this accurate?). They will then gladly hand over the username and > password in clear. If the service provider wanted to complete the facade > it could issue itself with a CHAP challenge and compute the response and > communicate this info to the home gateway. Anyone who's interested in strict security who lets you do this, is, IMHO, out of their mind.. If you want to be able to do CHAP, but fall back to PAP, having the PAP password match the CHAP secret defeats the whole point of using CHAP at all.. You might as well just do PAP only. Transmitting your CHAP secret in plaintext over a link is daft. > Another way around this would be setting the client to only agree to CHAP, > but do any implementations actually support this? If you want to do CHAP, you do CHAP, and refuse to fall back to PAP. Everything Ive been involved in implementing supports this - and, from memory, just about everything Ive tested against does too. Theres very little point implementing CHAP if you cant insist on doing it. --- Malcolm - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Mar 29 08:14:43 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id IAA20967; Fri, 29 Mar 1996 08:14:43 -0500 (EST) Resent-Date: Fri, 29 Mar 1996 08:14:43 -0500 (EST) Message-ID: <01BB1D47.DFE17980@pon-mi1-02.ix.netcom.com> From: Brad Wilson To: "'ietf-ppp@merit.edu'" Subject: RE: Authentication in L2F/PPTP type tunneling. Date: Fri, 29 Mar 1996 08:15:13 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Resent-Message-ID: <"BbvjI2.0.K75._8-Mn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1462 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > Another way around this would be setting the client to only agree to CHAP, > but do any implementations actually support this? Microsoft's implementations in Windows 95 and Windows NT do. -- Brad Wilson, Crucial Software crucial@ix.netcom.com +1 (810) 620-9803 Custom software engineering services for Microsoft Windows NT and Windows 95 "Sometimes hate and love serve exactly the same purpose." - Lestat - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Mar 29 09:06:39 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id JAA22567; Fri, 29 Mar 1996 09:06:39 -0500 (EST) Resent-Date: Fri, 29 Mar 1996 09:06:39 -0500 (EST) From: lasat-lh@inet.uni-c.dk Date: Fri, 29 Mar 1996 15:02:58 +0100 Message-Id: <199603291402.PAA06327@inet.uni-c.dk> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Subject: PPP handling in asynch. Terminal Adapters To: ietf-PPP@MERIT.EDU X-Mailer: SPRY Mail Version: 04.00.06.17 Resent-Message-ID: <"rqU852.0.OW5.iv-Mn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1463 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I have a question regarding, where the PPP handling and negotiation is supposed to be handled. Is the PPP handled, only on the PC by the running application program or do the Terminal Adapter allso have to do any negotiation? Has I understand the protocol rigth, when I say that the protocol is generated and handled by the application program running on the PC and the Terminal Adapter is only making the Asynch-Synch conversion and visa versa? If I have not understand it right how much negotiation is necessary for the Terminal adapter. Kind regards Lars Hansen <---- End Forwarded Message ----> - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Mar 29 11:14:54 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id LAA26259; Fri, 29 Mar 1996 11:14:54 -0500 (EST) Resent-Date: Fri, 29 Mar 1996 11:14:54 -0500 (EST) Message-ID: <315C0C81.4A54@ed.nce.sita.int> Date: Fri, 29 Mar 1996 17:14:57 +0100 From: Cathal Fitzgerald Organization: ed.nce.sita.int X-Mailer: Mozilla 2.0GoldB1 (Win95; I) MIME-Version: 1.0 To: ietf-ppp@MERIT.EDU Subject: Re: Authentication in L2F/PPTP type tunneling. References: <315AF903.5586@ed.nce.sita.int> <199603282234.OAA00418@vandys-lap.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"BdERf3.0.fP6.vm0Nn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1464 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU John Shriver wrote: > > The client can also demand authentication. Could help.Yes, but one password might still be leaked (see below). Andy Valencia wrote: > > In cisco.external.ietf.ppp you write: > > >If the service provider sets the NAS to negotiate PAP instead of CHAP (maliciously), I > >think most client software implementations will accept this (is this accurate?) > > Cisco's won't--it would be hard to configure it to fall prey to such But alas, Cisco don't make PCs. > behavior. Remember that one of the points of CHAP was that it wouldn't hand > out clear passwords--providing such a simple way around this would require > careless programming! Hopefully some client vendors will answer and you can > get a feel for how much exposure. My guess? Very little. I'm also not > sure how the malicious provider got you to dial them in the first place. > > Regards, > Andy Valencia Malcolm Campbell wrote: > > > If the service provider sets the NAS to negotiate PAP instead of CHAP > > (maliciously), I think most client software implementations will accept > > this (is this accurate?). They will then gladly hand over the username and > > password in clear. If the service provider wanted to complete the facade > > it could issue itself with a CHAP challenge and compute the response and > > communicate this info to the home gateway. > > Anyone who's interested in strict security who lets you do this, is, IMHO, > out of their mind.. or doing so with malicious intent. > If you want to be able to do CHAP, but fall back to PAP, > having the PAP password match the CHAP secret defeats the whole point of > using CHAP at all.. You might as well just do PAP only. > > Transmitting your CHAP secret in plaintext over a link is daft. - as a bottle of crisps. > > > Another way around this would be setting the client to only agree to CHAP, > > but do any implementations actually support this? > > If you want to do CHAP, you do CHAP, and refuse to fall back to PAP. > > Everything Ive been involved in implementing supports this - and, from > memory, just about everything Ive tested against does too. Theres very > little point implementing CHAP if you cant insist on doing it. Have you ever been involved in implementing PC drivers of any flavour for PPP? > > --- Malcolm Try this out with your favourite PC software. Configure it to dial-up your NAS and tell it to use CHAP. Then configure your NAS to only require PAP. When you start a connection you are normally asked to verify the phone number, username and password to be used. You enter these expecting to be authenticated via CHAP, the call connects, negotiates PAP and before you know it your password has just been transmitted in clear text. With traditional PPP access, the NAS decides on the minimum level of authentication required as the home LAN is considered sovereign territory. With a proxy NAS this is not the case. It makes no sense to rely on the service provider's NAS to state the minimum level of security required. So the solution is to tell your PC not to accept PAP during LCP negotiation. But how many PC implementations can do this? Thanks to Brad Wilson I now know of 3, but I know more that can't insist on CHAP - most will fall back quite happily to PAP if asked. Regards, Cathal. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Mar 29 20:53:40 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id UAA11018; Fri, 29 Mar 1996 20:53:40 -0500 (EST) Resent-Date: Fri, 29 Mar 1996 20:53:40 -0500 (EST) Content-Type: text/plain Message-ID: X-Mailer: Novell GroupWise 4.1 Date: Fri, 29 Mar 1996 17:52:08 -0800 From: RSALES@novell.com (Randy Sales) To: ietf-ppp@MERIT.EDU Subject: Couple of simple PSCP questions Resent-Message-ID: <"hnrte3.0.th2.wF9Nn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1465 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Hi, I have a couple short questions about PSCP: 1) Short hold ------------- At what level does short hold really occur? Does the NCP need to remain open(ie. network protocol is oblivious of short hold), or is maintaining (suspended) state information the responsibility of the network protocol (network protocol (temporarily) terminates connection, NCP closed, CRNs managed by PSCP)? Is this not an interoperability issue? 2) Use with PPP Multilink (Section 4.5, paragraph 2) ---------------------------------------------------- Can someone provide an example where a *new* link would be added to a suspended bundle? If the bundle is to be brought out of suspension, why not just use one of the links in the suspended bundle? Thanks for any replies. Randy Sales, Novell, Inc. rsales@novell.com 408.577.8912 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Sun Mar 31 00:22:42 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id AAA10256; Sun, 31 Mar 1996 00:22:42 -0500 (EST) Resent-Date: Sun, 31 Mar 1996 00:22:42 -0500 (EST) From: Ron Cohen To: "'vernon-ppp'" Cc: ppp Subject: RE:BA(C)P without MP Date: Sun, 31 Mar 96 09:19:00 EST Message-ID: <315E251F@smtp-gateway.rad.co.il> Encoding: 29 TEXT X-Mailer: Microsoft Mail V3.0 Resent-Message-ID: <"eAODk.0.uV2.oPXNn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1466 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Vernon > What good is sending the Link-Drop-Query-Request before actually hanging? >Why not just send a Terminate-Request? >I've been running a symmetric demand-dialed PPP link for years, and >have never needed more than Terminate-Requests. We have a customer which uses Video monitoring. Most of the traffic runs uni-directional from the remote site (the camera) to the center. When the camera detects an event that needs to be informed to the center it triggers the line by sending frames to the center. But it may happen that the manager from the center wishes to see what is going on in the branch, and triggers the line from the center to the branch. After the line is triggered, once more the traffic runs mostly from the branch to the center (no Acks). Our algorithm to decide when to disconnect the line is by examining the traffic sent on the line, not the traffic received. Therefore, when the line is triggered from the center, we may decide to terminate the connection while traffic is still being sent from the branch. In this case, a Link-Drip-Query-Request would help. In any case, suppose I want to use MP + BA(C)P but I begin with one link, and may want to use a second link on demand. Should I negotiate MP on this single line before using BA(C)P or only after the second line is up? Thanks Ron ron@develop.rndmail.rad.co.il - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Sun Mar 31 00:45:13 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id AAA10911; Sun, 31 Mar 1996 00:45:13 -0500 (EST) Resent-Date: Sun, 31 Mar 1996 00:45:13 -0500 (EST) From: Ron Cohen To: ppp Subject: MP and ifmib Date: Sun, 31 Mar 96 09:42:00 EST Message-ID: <315E2AA3@smtp-gateway.rad.co.il> Encoding: 17 TEXT X-Mailer: Microsoft Mail V3.0 Resent-Message-ID: <"IiWy72.0.Gg2.dlXNn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1467 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Hi How does a MP connection looks in terms of the Ifmib? A MP interface may have several different PPP interfaces below it in the stack table. Shouldn t there be a different iftype for a PPP interface and a MP interface? How are the protocol layers connected - only to MP sub-layer or to both PPP sub-layer and to MP sub-layer? Is there a recommended representation? Thanks very much Ron ron@develop.rndmail.rad.co.il - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Sun Mar 31 19:42:33 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id TAA00181; Sun, 31 Mar 1996 19:42:33 -0500 (EST) Resent-Date: Sun, 31 Mar 1996 19:42:33 -0500 (EST) From: mrenkosi@psl.attmail.com Date: Sun, 31 Mar 1996 19:41:13 +0000 Subject: Proposal for callback controll protocol. To: ietf-ppp@MERIT.EDU Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: Resent-Message-ID: <"ZrCPL.0.N2.4PoNn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1468 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Could you please tell me what the is the current status of the CBCP proposal. Thank you, Moti Renkosinski Perle Systems Limited. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Sun Mar 31 20:32:15 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id UAA01458; Sun, 31 Mar 1996 20:32:15 -0500 (EST) Resent-Date: Sun, 31 Mar 1996 20:32:15 -0500 (EST) Date: Sun, 31 Mar 1996 20:30:51 -0500 (EST) From: John Shriver Message-Id: <199604010130.UAA23909@shiva-dev.shiva.com> To: Ron@DEVELOP.RNDMAIL.rad.co.il CC: ietf-ppp@MERIT.EDU In-reply-to: <315E2AA3@smtp-gateway.rad.co.il> (message from Ron Cohen on Sun, 31 Mar 96 09:42:00 EST) Subject: Re: MP and ifmib Resent-Message-ID: <"S6fxf1.0.ZM.S8pNn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1469 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I've modeled the multilink "bundle" interface as another ifEntry stacked (via ifStackTable) on top of all the individual links. It would be nice if there were an appropriate ifType value. For now I use PPP. Keeping all the counters right is a pain in the butt. I cheated, and have the multilink ifEntry there even if multilink isn't in use, too painful to eliminate it. In turn, the routing table MIB entries point to the bundle PPP ifEntry. I asked the list about it when I started working on it, and got resounding silence. (Let's just say that SNMP isn't foremost in the hearts and minds of much of the PPP extensions working group...) - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Sun Mar 31 21:17:40 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id VAA02596; Sun, 31 Mar 1996 21:17:40 -0500 (EST) Resent-Date: Sun, 31 Mar 1996 21:17:40 -0500 (EST) From: James Watt Message-Id: <199604010216.VAA29089@thor.ca.newbridge.com> Subject: Re: MP and ifmib To: jas@shiva.com (John Shriver) Date: Sun, 31 Mar 1996 21:16:01 -0500 (EST) Cc: Ron@DEVELOP.RNDMAIL.rad.co.il, ietf-ppp@MERIT.EDU In-Reply-To: <199604010130.UAA23909@shiva-dev.shiva.com> from "John Shriver" at Mar 31, 96 08:30:51 pm X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"EAcHl1.0.Le._opNn"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1470 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU John Shriver writes: +-------- |I've modeled the multilink "bundle" interface as another ifEntry |stacked (via ifStackTable) on top of all the individual links. It |would be nice if there were an appropriate ifType value. For now I |use PPP. +------- Using ifType of propMultiplexor would help distinguish it from "regular" ppp links... It wouldn't be that hard for you to get a value allocated for pppMultiLinkBundle and it would perhaps provide a little bit more information about what is going on inside a box... Regards, -james ____________________________________________________________________________ James W. Watt, james@newbridge.com Ph: +1 613 591-3600 Newbridge Networks 600 March Rd Kanata ON Canada K2K 2E6 FAX:+1 613 591-3680 - - - - - - - - - - - - - - - - -