From owner-ietf-ppp@merit.edu Wed Jul 2 10:53:42 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id KAA20855; Wed, 2 Jul 1997 10:51:48 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 2 Jul 1997 10:43:15 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id KAA20484 for ietf-ppp-outgoing; Wed, 2 Jul 1997 10:43:14 -0400 (EDT) Received: from tor.securecomputing.com (tor.securecomputing.com [199.71.190.98]) by merit.edu (8.8.5/8.8.5) with ESMTP id KAA20480 for ; Wed, 2 Jul 1997 10:43:05 -0400 (EDT) Received: by janus.tor.securecomputing.com id <11650>; Wed, 2 Jul 1997 10:38:00 -0400 Message-Id: <97Jul2.103800edt.11650@janus.tor.securecomputing.com> To: paulmart@microsoft.com Subject: draft-rfced-info-martin-00.txt Cc: ietf-ppp@merit.edu From: "C. Harald Koch" Date: Wed, 2 Jul 1997 10:42:57 -0400 Sender: owner-ietf-ppp@merit.edu (PPP/IPCP Extension for Word Alignment of IP Datagrams) I do not believe that this extension is necessary. This problem can be solved without resorting to protocol modifications. Once you've negotiated the various compressions (Address/Control, Protocol, VJ, etc) you know exactly how many bytes of header you're going to receive from a (sane) peer. You can simply align your data input buffers so that the IP header will fall on a word boundary: 1. Protocol Field Compression 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FF | 03 | 21 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Datagram +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2. Protocol & Address/Control Field Compression 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 +-+-+-+-+-+-+-+-+ | 21 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Datagram +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3. Van-Jacobson Compression 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FF | 03 | 00 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2D | VJ Compressed TCP/IP Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TCP Payload... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I note that many high-speed router manufacturers already do this in their hardware. -- Harald Koch - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jul 2 15:08:38 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id PAA27297; Wed, 2 Jul 1997 15:07:06 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 2 Jul 1997 15:06:34 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id PAA27268 for ietf-ppp-outgoing; Wed, 2 Jul 1997 15:06:33 -0400 (EDT) Received: from usr.com (mailgate.usr.com [149.112.20.2]) by merit.edu (8.8.5/8.8.5) with ESMTP id PAA27261 for ; Wed, 2 Jul 1997 15:06:27 -0400 (EDT) From: bdolnik@usr.com Received: from robogate2.usr.com by usr.com (8.7.5/3.1.090690-US Robotics) id NAA06013; Wed, 2 Jul 1997 13:55:53 -0500 (CDT) Received: from ccMail by robogate2.usr.com (IMA Internet Exchange 2.02 Enterprise) id 3BAA9230; Wed, 2 Jul 97 14:16:51 -0500 Mime-Version: 1.0 Date: Wed, 2 Jul 1997 13:57:31 -0500 Message-ID: <3BAA9230.3000@usr.com> Subject: comment to draft-ietf-pppext-eap-auth-02 To: ietf-ppp@merit.edu Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: owner-ietf-ppp@merit.edu Problem: There is a situation when server doesn't perform multilink itself and some proxy device added to perform multilink on the network side and single link on the application side. This proxy device could be modem, multi-BRI terminal adapter etc. In this situation there is a problem to authenticate secondary connections, that are managed by the proxy device. Some mechanism is needed to force the server (authenticator) to send additional authentication requests when proxy opens secondary connection. _____ multilink| | _________ ______ ~~~ |proxy| single link | NAS | LAN | | ~~~ | |~~~~~~~~~~~~~| |~~~~~~|RADIUS| ~~~ | | |_________| |______| |_____| Proposal: The additional message Access-Request ( EAP code 5 ) is added to EAP protocol. This message is sent by proxy to NAS and will cause NAS to sent authentication request to proxy. Proxy device will forward this request to the peer to authenticate secondary link connection. The EAP type should be the same as negotiated for the primary link. Benjamin Dolnik 3Com e-mail bdolnik@usr.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jul 2 16:22:56 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id QAA29425; Wed, 2 Jul 1997 16:22:44 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 2 Jul 1997 16:22:04 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id QAA29394 for ietf-ppp-outgoing; Wed, 2 Jul 1997 16:22:03 -0400 (EDT) Received: from usr.com (mailgate.usr.com [149.112.20.2]) by merit.edu (8.8.5/8.8.5) with ESMTP id QAA29384 for ; Wed, 2 Jul 1997 16:21:56 -0400 (EDT) From: jhaag@usr.com Received: from robogate2.usr.com by usr.com (8.7.5/3.1.090690-US Robotics) id PAA09875; Wed, 2 Jul 1997 15:10:32 -0500 (CDT) Received: from ccMail by robogate2.usr.com (IMA Internet Exchange 2.02 Enterprise) id 3BABACF0; Wed, 2 Jul 97 15:32:15 -0500 Mime-Version: 1.0 Date: Wed, 2 Jul 1997 16:16:55 -0500 Message-ID: <3BABACF0.3000@usr.com> Subject: EAP Interoperability To: ietf-ppp@merit.edu, ietf-radius@livingston.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: owner-ietf-ppp@merit.edu I am looking for vendors that would be interested in testing EAP and EAP in RADIUS. Interoperability testing is scheduled for the next CIUG bakeoff, but that is not until 1998. So, if any vendors would like to test interoperability currently, please contact me via private email. I will collate a list of vendors and functions, and distribute. Please send the applicable information 1) what your product is (client, NAS, RADIUS server, ...) 2) whether you support both sides of EAP authentication (authenticator/authenticatee) 3) whether you support EAP in RADIUS 4) what types of authentication you do (MD5, SKEY, Token Card, ...) 5) what you would like to test 6) when you would like to test Thanks, ====================================================================== Jeff Haag email: jhaag@usr.com Total Control Hub Development voice: (919) 676-9971 3Com Carrier Systems Division fax: (919) 676-9971 ====================================================================== - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jul 2 17:13:50 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id RAA00809; Wed, 2 Jul 1997 17:13:48 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 2 Jul 1997 17:13:35 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id RAA00786 for ietf-ppp-outgoing; Wed, 2 Jul 1997 17:13:34 -0400 (EDT) Received: from coppermountain.com (cmcnt.coppermountain.com [206.71.190.2]) by merit.edu (8.8.5/8.8.5) with ESMTP id RAA00782 for ; Wed, 2 Jul 1997 17:13:27 -0400 (EDT) Received: by coppermountain.com from localhost (router,SLMail V2.5); Wed, 02 Jul 1997 14:13:51 -0800 Received: by coppermountain.com from eric (206.71.190.13::mail daemon; unverified,SLMail V2.5); Wed, 02 Jul 1997 14:13:50 -0800 Message-Id: <2.2.32.19970702211420.0031b100@coppermountain.com> X-Sender: "Eric Michelsen" X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 02 Jul 1997 14:14:20 -0700 To: ietf-ppp@merit.edu From: "Eric L. Michelsen" Subject: Re: fsm questions Sender: owner-ietf-ppp@merit.edu Sorry for the delay. I've been away. At 02:21 PM 6/13/97 GMT, William Allen Simpson wrote: >Also, I have a comment on an earlier message: ># From: "Eric L. Michelsen" ># At 01:39 AM 6/5/97 GMT, William Allen Simpson wrote: ># ... ># >Just follow the state machine. That's what "wiser" folks do.... It's ># >already been debugged by dozens of folks. ># ># On the other hand, during the MP discussion on this list, many people found ># that it's wiser to modify the state machine slightly, by continuing to ># accept packets after a Terminate-Request is sent, but before the Terminate-Ack. ># >Actually, there was rather a lot of blather in such a vein, but it was >not to be taken seriously. I thought I heard you say at IETF in LA that your own implementation worked this way. Perhaps I misunderstood. ... >Lots of folks don't understand why there are both Up/Down and >Open/Close, but educating them for free at this late date is not my >problem.... The best way to insure interoperability, and to educate people at no peronsal cost, is to include some of the reasoning in the standard itself, much like RFC 1812 (and 1122 before it). -- Eric L. Michelsen, Copper Mountain Networks, Inc. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jul 3 07:06:57 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id HAA11056; Thu, 3 Jul 1997 07:05:08 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 3 Jul 1997 06:59:33 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id GAA11008 for ietf-ppp-outgoing; Thu, 3 Jul 1997 06:59:33 -0400 (EDT) Received: from directors.rdl.co.uk (directors.rdl.co.uk [193.119.77.2]) by merit.edu (8.8.5/8.8.5) with ESMTP id GAA11004 for ; Thu, 3 Jul 1997 06:59:24 -0400 (EDT) Received: from imaccgw.rdl.co.uk (imaccgw.rdl.co.uk [193.240.106.205]) by directors.rdl.co.uk (8.7.3/8.7.3) with SMTP id LAA07125 for ; Thu, 3 Jul 1997 11:59:18 +0100 (BST) Received: from ccMail by imaccgw.rdl.co.uk (IMA Internet Exchange 1.04b) id 3bb85d90; Thu, 3 Jul 97 11:58:33 +0100 Mime-Version: 1.0 Date: Thu, 3 Jul 1997 11:49:55 +0100 Message-ID: <3bb85d90@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Strange Authentication Protocol (0xC123) To: ietf-ppp@merit.edu Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: owner-ietf-ppp@merit.edu I've just been testing against another peer (I won't mention any names!) and the authentication negotiation proceeds as follows (leaving out irrelevant options, and the requests in the other direction) --> Cfg-Req 03 05 c2 23 80 <-- Cfg-Nak 03 05 c2 23 05 --> Cfg-Req 03 04 c0 27 <-- Cfg-Nak 03 05 c2 23 05 --> Cfg-Req 03 04 c1 23 (a number of repetitions) <-- Cfg-Rej 03 04 c1 23 Has anyone got any idea what this authentication "protocol" C123 is ? Thanks Jonathan Goodchild Racal-Datacom - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jul 3 08:25:11 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id IAA11926; Thu, 3 Jul 1997 08:23:34 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 3 Jul 1997 08:23:19 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id IAA11901 for ietf-ppp-outgoing; Thu, 3 Jul 1997 08:23:18 -0400 (EDT) Received: from gatekeeper.ctron.com (ctron.com [134.141.197.25]) by merit.edu (8.8.5/8.8.5) with SMTP id IAA11893 for ; Thu, 3 Jul 1997 08:23:14 -0400 (EDT) Received: (from news@localhost) by gatekeeper.ctron.com (8.6.12/8.6.9) id IAA20319 for ; Thu, 3 Jul 1997 08:23:12 -0400 Received: from stealth.ctron.com(134.141.5.107) by gatekeeper.ctron.com via smap (12) id xma020299; Thu, 3 Jul 97 08:22:55 -0400 Received: from olympus.ctron.com by stealth.ctron.com (4.1/SMI-4.1) id AA01100; Thu, 3 Jul 97 08:22:55 EDT Received: from jbloom.ctron (jbloom.ctron.com [134.141.12.26]) by olympus.ctron.com (8.6.12/8.6.9) with SMTP id IAA15955 for ; Thu, 3 Jul 1997 08:22:54 -0400 Date: Thu, 3 Jul 1997 08:22:54 -0400 From: Jeff Bloom Message-Id: <199707031222.IAA15955@olympus.ctron.com> To: ietf-ppp@merit.edu Subject: Re: Strange Authentication Protocol (0xC123) Sender: owner-ietf-ppp@merit.edu Jonathan, The most important question is why the Authenticator is sending an invalid Cfg-Req( 03 05 c2 23 80). The only algoritym I am aware of is MD5 with Chap. Below contains the Configuration Option for Chap: Configuration Option Format A summary of the Authentication-Protocol Configuration Option format to negotiate the Challenge-Handshake Authentication Protocol is shown below. The fields are transmitted from left to right. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Authentication-Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Algorithm | +-+-+-+-+-+-+-+-+ Type 3 Length 5 Authentication-Protocol c223 (hex) for Challenge-Handshake Authentication Protocol. Algorithm The Algorithm field is one octet and indicates the authentication method to be used. Up-to-date values are specified in the most recent "Assigned Numbers" [2]. One value is required to be implemented: 5 CHAP with MD5 [3] Also I see that the Peer is acting properly, Sending a NAK 03 05 c2 23 05 asking the Authenticator to correct the Config Request & resend with the MD5 Algorithm. I have no idea what an authentication protocol of c123 is? I hope this helped. Jeff Bloom > From owner-ietf-ppp@merit.edu Thu Jul 3 07:32:33 1997 > Mime-Version: 1.0 > Date: Thu, 3 Jul 1997 11:49:55 +0100 > From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) > Subject: Strange Authentication Protocol (0xC123) > To: ietf-ppp@merit.edu > Content-Type> : > text/plain> ; > charset=US-ASCII> > Content-Transfer-Encoding: 7bit > Content-Description: cc:Mail note part > Sender: owner-ietf-ppp@merit.edu > Content-Length: 520 > > I've just been testing against another peer (I won't mention any names!) > and the authentication negotiation proceeds as follows (leaving out > irrelevant options, and the requests in the other direction) > > --> Cfg-Req 03 05 c2 23 80 > <-- Cfg-Nak 03 05 c2 23 05 > --> Cfg-Req 03 04 c0 27 > <-- Cfg-Nak 03 05 c2 23 05 > --> Cfg-Req 03 04 c1 23 > (a number of repetitions) > <-- Cfg-Rej 03 04 c1 23 > > Has anyone got any idea what this authentication "protocol" C123 is ? > > Thanks > > Jonathan Goodchild > Racal-Datacom > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jul 3 08:42:35 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id IAA12160; Thu, 3 Jul 1997 08:41:14 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 3 Jul 1997 08:40:57 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id IAA12141 for ietf-ppp-outgoing; Thu, 3 Jul 1997 08:40:56 -0400 (EDT) Received: from ns.trancell.stph.net ([196.12.55.2]) by merit.edu (8.8.5/8.8.5) with ESMTP id IAA12118 for ; Thu, 3 Jul 1997 08:40:13 -0400 (EDT) Received: from prasanna.trancell.stph.net (kasturi.trancell.stph.net [196.12.55.7]) by ns.trancell.stph.net (8.7.3/8.7.3) with SMTP id SAA02424; Thu, 3 Jul 1997 18:27:22 +0530 (IST) Received: by prasanna.trancell.stph.net with Microsoft Mail id <01BC87DC.B7E93480@prasanna.trancell.stph.net>; Thu, 3 Jul 1997 18:12:50 -0700 Message-ID: <01BC87DC.B7E93480@prasanna.trancell.stph.net> From: "Ravindra C.P" To: "ietf-ppp@merit.edu" , "'Jeff Bloom'" Subject: RE: Strange Authentication Protocol (0xC123) Date: Thu, 3 Jul 1997 18:12:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Hi , The cfg req is a valid one. The code 0x80 is for the DES-MD4 algorithm used by MS_CHAP(CHAP implementation for NT RAS). By the way which authentication protocol does 0xc027 represent. Thanks Ravi ---------- From: Jeff Bloom[SMTP:jbloom@ctron.com] Sent: Thursday, July 03, 1997 5:22 AM To: ietf-ppp@merit.edu Subject: Re: Strange Authentication Protocol (0xC123) Jonathan, The most important question is why the Authenticator is sending an invalid Cfg-Req( 03 05 c2 23 80). The only algoritym I am aware of is MD5 with Chap. Below contains the Configuration Option for Chap: Configuration Option Format A summary of the Authentication-Protocol Configuration Option format to negotiate the Challenge-Handshake Authentication Protocol is shown below. The fields are transmitted from left to right. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Authentication-Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Algorithm | +-+-+-+-+-+-+-+-+ Type 3 Length 5 Authentication-Protocol c223 (hex) for Challenge-Handshake Authentication Protocol. Algorithm The Algorithm field is one octet and indicates the authentication method to be used. Up-to-date values are specified in the most recent "Assigned Numbers" [2]. One value is required to be implemented: 5 CHAP with MD5 [3] Also I see that the Peer is acting properly, Sending a NAK 03 05 c2 23 05 asking the Authenticator to correct the Config Request & resend with the MD5 Algorithm. I have no idea what an authentication protocol of c123 is? I hope this helped. Jeff Bloom > From owner-ietf-ppp@merit.edu Thu Jul 3 07:32:33 1997 > Mime-Version: 1.0 > Date: Thu, 3 Jul 1997 11:49:55 +0100 > From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) > Subject: Strange Authentication Protocol (0xC123) > To: ietf-ppp@merit.edu > Content-Type> : > text/plain> ; > charset=US-ASCII> > Content-Transfer-Encoding: 7bit > Content-Description: cc:Mail note part > Sender: owner-ietf-ppp@merit.edu > Content-Length: 520 > > I've just been testing against another peer (I won't mention any names!) > and the authentication negotiation proceeds as follows (leaving out > irrelevant options, and the requests in the other direction) > > --> Cfg-Req 03 05 c2 23 80 > <-- Cfg-Nak 03 05 c2 23 05 > --> Cfg-Req 03 04 c0 27 > <-- Cfg-Nak 03 05 c2 23 05 > --> Cfg-Req 03 04 c1 23 > (a number of repetitions) > <-- Cfg-Rej 03 04 c1 23 > > Has anyone got any idea what this authentication "protocol" C123 is ? > > Thanks > > Jonathan Goodchild > Racal-Datacom > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jul 3 08:45:41 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id IAA12223; Thu, 3 Jul 1997 08:44:19 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 3 Jul 1997 08:44:04 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id IAA12203 for ietf-ppp-outgoing; Thu, 3 Jul 1997 08:44:03 -0400 (EDT) Received: from linux.klos.com (klos@klos.com [192.80.49.1]) by merit.edu (8.8.5/8.8.5) with SMTP id IAA12199 for ; Thu, 3 Jul 1997 08:43:58 -0400 (EDT) Received: (from klos@localhost) by linux.klos.com (8.6.12/8.6.9) id IAA17118; Thu, 3 Jul 1997 08:44:19 -0400 Date: Thu, 3 Jul 1997 08:44:19 -0400 From: Patrick Klos Message-Id: <199707031244.IAA17118@linux.klos.com> To: ietf-ppp@merit.edu, Jonathan.Goodchild@rdl.co.uk Subject: Re: Strange Authentication Protocol (0xC123) Cc: jbloom@ctron.com Sender: owner-ietf-ppp@merit.edu >I've just been testing against another peer (I won't mention any names!) >and the authentication negotiation proceeds as follows (leaving out >irrelevant options, and the requests in the other direction) > >--> Cfg-Req 03 05 c2 23 80 This is asking for "MS-CHAP" (Microsoft's version of CHAP). ><-- Cfg-Nak 03 05 c2 23 05 This is saying "No, how about regular (MD5) CHAP?". >--> Cfg-Req 03 04 c0 27 Now the peer is asking for SPAP (one of Shiva's flavors of PAP). ><-- Cfg-Nak 03 05 c2 23 05 With a reply "No thanks. How about regular CHAP?". >--> Cfg-Req 03 04 c1 23 Now the peer is asking for an older form of SPAP (an older flavor of Shiva's PAP). > (a number of repetitions) ><-- Cfg-Rej 03 04 c1 23 Obviously, the two peers can't agree and go thier seperate ways... >Has anyone got any idea what this authentication "protocol" C123 is ? This is Shiva's (I think original) proprietary PAP. Note that the protocol value isn't even valid in the context of PPP. It would appear you are attempting to connect to a Microsoft or Shiva product that doesn't have regular PAP or CHAP enabled. ============================================================================ 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://web.klos.com/ ============================================================================ - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jul 3 08:56:59 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id IAA12358; Thu, 3 Jul 1997 08:55:37 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 3 Jul 1997 08:55:28 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id IAA12338 for ietf-ppp-outgoing; Thu, 3 Jul 1997 08:55:27 -0400 (EDT) Received: from greatdane.cisco.com (greatdane.cisco.com [171.69.1.141]) by merit.edu (8.8.5/8.8.5) with SMTP id IAA12334 for ; Thu, 3 Jul 1997 08:55:23 -0400 (EDT) Received: (fox@localhost) by greatdane.cisco.com (8.6.12/8.6.5) id FAA28728; Thu, 3 Jul 1997 05:54:51 -0700 From: Craig Fox Message-Id: <199707031254.FAA28728@greatdane.cisco.com> Subject: Re: Strange Authentication Protocol (0xC123) To: jbloom@ctron.com (Jeff Bloom) Date: Thu, 3 Jul 97 5:54:51 PDT Cc: ietf-ppp@merit.edu In-Reply-To: <199707031222.IAA15955@olympus.ctron.com>; from "Jeff Bloom" at Jul 3, 97 8:22 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ietf-ppp@merit.edu > > Jonathan, > > The most important question is why the Authenticator is sending an invalid > Cfg-Req( 03 05 c2 23 80). The only algoritym I am aware of is MD5 with Chap. This is Microsoft CHAP (ms-chap) as described in an informational draft available at 'ftp://ftp.microsoft.com/developr/rfc/chapexts.txt'. > Below contains the Configuration Option for Chap: > > Configuration Option Format > > A summary of the Authentication-Protocol Configuration Option format > to negotiate the Challenge-Handshake Authentication Protocol is shown > below. The fields are transmitted from left to right. > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Authentication-Protocol | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Algorithm | > +-+-+-+-+-+-+-+-+ > > Type > > 3 > > Length > > 5 > > Authentication-Protocol > > c223 (hex) for Challenge-Handshake Authentication Protocol. > > Algorithm > > The Algorithm field is one octet and indicates the authentication > method to be used. Up-to-date values are specified in the most > recent "Assigned Numbers" [2]. One value is required to be > implemented: > > 5 CHAP with MD5 [3] > > Also I see that the Peer is acting properly, Sending a NAK 03 05 c2 23 05 > asking the Authenticator to correct the Config Request & resend with the MD5 > Algorithm. I have no idea what an authentication protocol of c123 is? This is Shiva PAP which is undocumented (publicly) by Shiva. Looks like you are talking to a Win95 peer. Craig > I hope this helped. > > Jeff Bloom > > > > > From owner-ietf-ppp@merit.edu Thu Jul 3 07:32:33 1997 > > Mime-Version: 1.0 > > Date: Thu, 3 Jul 1997 11:49:55 +0100 > > From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) > > Subject: Strange Authentication Protocol (0xC123) > > To: ietf-ppp@merit.edu > > Content-Type> : > text/plain> ; > charset=US-ASCII> > > Content-Transfer-Encoding: 7bit > > Content-Description: cc:Mail note part > > Sender: owner-ietf-ppp@merit.edu > > Content-Length: 520 > > > > I've just been testing against another peer (I won't mention any names!) > > and the authentication negotiation proceeds as follows (leaving out > > irrelevant options, and the requests in the other direction) > > > > --> Cfg-Req 03 05 c2 23 80 > > <-- Cfg-Nak 03 05 c2 23 05 > > --> Cfg-Req 03 04 c0 27 > > <-- Cfg-Nak 03 05 c2 23 05 > > --> Cfg-Req 03 04 c1 23 > > (a number of repetitions) > > <-- Cfg-Rej 03 04 c1 23 > > > > Has anyone got any idea what this authentication "protocol" C123 is ? > > > > Thanks > > > > Jonathan Goodchild > > Racal-Datacom > > > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jul 3 09:07:12 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id JAA12595; Thu, 3 Jul 1997 09:05:50 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 3 Jul 1997 09:05:36 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id JAA12574 for ietf-ppp-outgoing; Thu, 3 Jul 1997 09:05:35 -0400 (EDT) Received: from ftp.com (wd40.ftp.com [128.127.2.122]) by merit.edu (8.8.5/8.8.5) with SMTP id JAA12569 for ; Thu, 3 Jul 1997 09:05:29 -0400 (EDT) Received: from ftp.com by ftp.com ; Thu, 3 Jul 1997 09:04:58 -0400 Received: from mailserv-2high.ftp.com by ftp.com ; Thu, 3 Jul 1997 09:04:58 -0400 Received: from bray-2.ftp.com by MAILSERV-2HIGH.FTP.COM (SMI-8.6/SMI-SVR4) id JAA13403; Thu, 3 Jul 1997 09:01:00 -0400 Message-Id: <199707031301.JAA13403@MAILSERV-2HIGH.FTP.COM> X-Mapi-Messageclass: IPM To: jbloom@ctron.com, ietf-ppp@merit.edu X-Mailer: FTP Software Internet Mail 2.0 Mime-Version: 1.0 From: John Bray Subject: RE: Strange Authentication Protocol (0xC123) Date: Thu, 03 Jul 1997 09:04:58 -0400 Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu >>Reply to message from Jeff Bloom (jbloom@ctron.com) dated 7/3/97 8:44 AM > > Jonathan, > > The most important question is why the Authenticator is > sending an invalid > Cfg-Req( 03 05 c2 23 80). The only algoritym I am > aware of is MD5 with Chap. > Below contains the Configuration Option for Chap: > > Configuration Option Format > > A summary of the Authentication-Protocol > Configuration Option format > to negotiate the Challenge-Handshake Authentication > Protocol is shown > below. The fields are transmitted from left to right. > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Authentication-Protocol | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Algorithm | > +-+-+-+-+-+-+-+-+ > > Type > > 3 > > Length > > 5 > > Authentication-Protocol > > c223 (hex) for Challenge-Handshake Authentication > Protocol. > > Algorithm > > The Algorithm field is one octet and indicates the > authentication > method to be used. Up-to-date values are specified > in the most > recent "Assigned Numbers" [2]. One value is > required to be > implemented: > > 5 CHAP with MD5 [3] Algorithm type 0x80 is MS-CHAP (Microsoft). _________________________________________________ John Bray Senior Staff Engineer FTP Software, Inc. 2 High St. North Andover, MA 01845 E-mail: bray@ftp.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jul 3 09:17:16 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id JAA12784; Thu, 3 Jul 1997 09:15:53 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 3 Jul 1997 09:15:45 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id JAA12764 for ietf-ppp-outgoing; Thu, 3 Jul 1997 09:15:44 -0400 (EDT) Received: from greatdane.cisco.com (greatdane.cisco.com [171.69.1.141]) by merit.edu (8.8.5/8.8.5) with SMTP id JAA12760 for ; Thu, 3 Jul 1997 09:15:39 -0400 (EDT) Received: (fox@localhost) by greatdane.cisco.com (8.6.12/8.6.5) id GAA29057; Thu, 3 Jul 1997 06:13:33 -0700 From: Craig Fox Message-Id: <199707031313.GAA29057@greatdane.cisco.com> Subject: RE: Strange Authentication Protocol (0xC123) To: ravi@trancell.stph.net (Ravindra C.P) Date: Thu, 3 Jul 97 6:13:33 PDT Cc: ietf-ppp@merit.edu, "'Jeff, Bloom'"@cisco.com, jbloom@ctron.com In-Reply-To: <01BC87DC.B7E93480@prasanna.trancell.stph.net>; from "Ravindra C.P" at Jul 3, 97 6:12 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ietf-ppp@merit.edu > > Hi , > The cfg req is a valid one. The code 0x80 is for the DES-MD4 > algorithm used by MS_CHAP(CHAP implementation for NT RAS). > By the way which authentication protocol does 0xc027 represent. > Sigh, I was wrong in my previous message. C027 is Shiva PAP. C123 is the old Shiva PAP protocol. Note that it is not registered with IANA because it is an illegal protocol value as the first byte is not even (see RFC 1661). Craig > Thanks > Ravi > > ---------- > From: Jeff Bloom[SMTP:jbloom@ctron.com] > Sent: Thursday, July 03, 1997 5:22 AM > To: ietf-ppp@merit.edu > Subject: Re: Strange Authentication Protocol (0xC123) > > Jonathan, > > The most important question is why the Authenticator is sending an invalid > Cfg-Req( 03 05 c2 23 80). The only algoritym I am aware of is MD5 with Chap. > Below contains the Configuration Option for Chap: > > Configuration Option Format > > A summary of the Authentication-Protocol Configuration Option format > to negotiate the Challenge-Handshake Authentication Protocol is shown > below. The fields are transmitted from left to right. > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Authentication-Protocol | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Algorithm | > +-+-+-+-+-+-+-+-+ > > Type > > 3 > > Length > > 5 > > Authentication-Protocol > > c223 (hex) for Challenge-Handshake Authentication Protocol. > > Algorithm > > The Algorithm field is one octet and indicates the authentication > method to be used. Up-to-date values are specified in the most > recent "Assigned Numbers" [2]. One value is required to be > implemented: > > 5 CHAP with MD5 [3] > > Also I see that the Peer is acting properly, Sending a NAK 03 05 c2 23 05 > asking the Authenticator to correct the Config Request & resend with the MD5 > Algorithm. I have no idea what an authentication protocol of c123 is? > I hope this helped. > > Jeff Bloom > > > > > From owner-ietf-ppp@merit.edu Thu Jul 3 07:32:33 1997 > > Mime-Version: 1.0 > > Date: Thu, 3 Jul 1997 11:49:55 +0100 > > From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) > > Subject: Strange Authentication Protocol (0xC123) > > To: ietf-ppp@merit.edu > > Content-Type> : > text/plain> ; > charset=US-ASCII> > > Content-Transfer-Encoding: 7bit > > Content-Description: cc:Mail note part > > Sender: owner-ietf-ppp@merit.edu > > Content-Length: 520 > > > > I've just been testing against another peer (I won't mention any names!) > > and the authentication negotiation proceeds as follows (leaving out > > irrelevant options, and the requests in the other direction) > > > > --> Cfg-Req 03 05 c2 23 80 > > <-- Cfg-Nak 03 05 c2 23 05 > > --> Cfg-Req 03 04 c0 27 > > <-- Cfg-Nak 03 05 c2 23 05 > > --> Cfg-Req 03 04 c1 23 > > (a number of repetitions) > > <-- Cfg-Rej 03 04 c1 23 > > > > Has anyone got any idea what this authentication "protocol" C123 is ? > > > > Thanks > > > > Jonathan Goodchild > > Racal-Datacom > > > > > > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jul 3 11:46:57 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id LAA15743; Thu, 3 Jul 1997 11:46:51 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 3 Jul 1997 11:46:19 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id LAA15702 for ietf-ppp-outgoing; Thu, 3 Jul 1997 11:46:18 -0400 (EDT) Received: from ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.5/8.8.5) with SMTP id LAA15685 for ; Thu, 3 Jul 1997 11:46:10 -0400 (EDT) Received: from ietf.ietf.org by ietf.org id aa08428; 3 Jul 97 10:39 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org cc: ietf-ppp@merit.edu, mobile-ip@smallworks.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-ipcp-mip-02.txt Date: Thu, 03 Jul 1997 10:38:47 -0400 Message-ID: <9707031039.aa08428@ietf.org> Sender: owner-ietf-ppp@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 : Mobile-IPv4 Configuration Option for PPP IPCP Author(s) : J. Solomon, S. Glass Filename : draft-ietf-pppext-ipcp-mip-02.txt Pages : 18 Date : 07/02/1997 Mobile IP [RFC 2002] defines media-independent procedures by which a Mobile Node can maintain existing transport and application-layer connections despite changing its point-of-attachment to the Internet and without changing its IP address. PPP [RFC 1661] provides a standard method for transporting multi-protocol packets over point-to-point links. As currently specified, Mobile IP Foreign Agents which support Mobile Node connections via PPP can do so only by first assigning unique addresses to those Mobile Nodes, defeating one of the primary advantages of Foreign Agents. This documents corrects this problem by defining the Mobile-IPv4 Configuration Option to the Internet Protocol Control Protocol (IPCP) [RFC 1332]. Using this option, two peers can communicate their support for Mobile IP during the IPCP phase of PPP. Familiarity with Mobile IP [RFC 2002], IPCP [RFC 1332], and PPP [RFC 1661] is assumed. 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-ipcp-mip-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-ipcp-mip-02.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-ipcp-mip-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970702162052.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-ipcp-mip-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-ipcp-mip-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970702162052.I-D@ietf.org> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jul 3 11:46:57 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id LAA15747; Thu, 3 Jul 1997 11:46:54 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 3 Jul 1997 11:46:16 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id LAA15695 for ietf-ppp-outgoing; Thu, 3 Jul 1997 11:46:16 -0400 (EDT) Received: from ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.5/8.8.5) with SMTP id LAA15681 for ; Thu, 3 Jul 1997 11:46:03 -0400 (EDT) Received: from ietf.ietf.org by ietf.org id aa08412; 3 Jul 97 10:39 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-l2tp-sec-01.txt Date: Thu, 03 Jul 1997 10:39:06 -0400 Message-ID: <9707031039.aa08412@ietf.org> Sender: owner-ietf-ppp@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 : Layer Two Tunneling Protocol "L2TP" Security Extensions for Non-IPSEC networks Author(s) : Pat Calhoun, W. Mark Townsley Filename : draft-ietf-pppext-l2tp-sec-01.txt Pages : 13 Date : 07/02/1997 The L2TP document [1] defines the base protocol which describes the method of tunneling PPP [2] data. The L2TP document states that the security mechanism used over an IP network is to use the IETF's IPSEC protocols. L2TP was designed in such a way as to be able to run over any underlying layer (i.e. Frame Relay, ATM, etc.). This document specifies extensions to the L2TP protocol in order to provide authentication and integrity of individual packets in a tunneled session over a network where IPSEC or another suitable security protocol is not available. Internet-Drafts are available by anonymous FTP. Login 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-l2tp-sec-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-l2tp-sec-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-l2tp-sec-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970702163644.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-l2tp-sec-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-l2tp-sec-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970702163644.I-D@ietf.org> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jul 3 11:53:08 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id LAA15877; Thu, 3 Jul 1997 11:53:07 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 3 Jul 1997 11:52:59 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id LAA15859 for ietf-ppp-outgoing; Thu, 3 Jul 1997 11:52:58 -0400 (EDT) Received: from POSTAL.CSELT.STET.IT (postal.cselt.it [163.162.4.5]) by merit.edu (8.8.5/8.8.5) with ESMTP id LAA15854 for ; Thu, 3 Jul 1997 11:52:51 -0400 (EDT) Received: from [163.162.15.36] (fantolino.cselt.stet.it) by POSTAL.CSELT.STET.IT (PMDF V4.2-15 #4385) id <01IKT4IX1SF4000QMJ@POSTAL.CSELT.STET.IT>; Thu, 3 Jul 1997 17:51:12 MET Date: Thu, 03 Jul 1997 17:53:40 +0100 From: luca.fantolino@CSELT.IT (Luca Fantolino) Subject: PPP over Ethernet To: ietf-ppp@merit.edu Message-id: X-Envelope-to: ietf-ppp@merit.edu MIME-version: 1.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: 7BIT X-Sender: FANTOLIN_EUD@POSTAL.CSELT.IT Sender: owner-ietf-ppp@merit.edu I looked through the IETF archives searching a solution to let a LAN (e.g. Ethernet) attached PC to initiate a PPP session. This may be usefull in order to perform dynamic IP-address assignement, autentication, etc. The configuration I have in mind is depicted in the figure below. In that case PPP over Ethernet (or other LAN tecnology) is required, but as far as I know this protocol does not exist. PC Server ----- +-----+ | | PPP Session | | | | <=-=-=-=-=-=-=-=-> | | ----- | | +---------+ | | +---------+ +-----+ # # # # ================================== LAN (Ethernet) A more complex configuration, depicted in figure below, is the case in which the PPP link is extended over a WAN (e.g. Frame Relay) using L2TP. Also in that case it is needed PPP over Ethernet. This scenario may be interesting to provide services to Small Offices or Home Offices (SOHO) in which Ethernet may be a cost-effective solution to connect one or few PCs, but no permanent connection to Internet is required. PC LNS ----- +-----+ | | PPP Session | | | | <=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-> | | ----- | | +---------+ +------------+ L2TP Session | | +---------+ | LAC | <=-=-=-=-=-=-=-> | | # +------------+ +-----+ # # \ / ============================= \_____________________/ LAN (Ethernet) WAN (Frame Relay) Is there anybody who knows of any solution (standard o proprietary)? Thank you Luca _______________________________________________________________________ Luca Fantolino CSELT (a STET Company) Tel: +39 11 228 7543 via G. Reiss Romoli, 274 Fax: +39 11 228 5069 10148 Torino - ITALY E-Mail: Luca.Fantolino@Cselt.It _______________________________________________________________________ - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jul 3 12:26:03 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id MAA16552; Thu, 3 Jul 1997 12:26:02 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 3 Jul 1997 12:25:52 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id MAA16526 for ietf-ppp-outgoing; Thu, 3 Jul 1997 12:25:51 -0400 (EDT) Received: from mx12.netvision.net.il (mx12.NetVision.net.il [194.90.1.50]) by merit.edu (8.8.5/8.8.5) with SMTP id MAA16518 for ; Thu, 3 Jul 1997 12:25:46 -0400 (EDT) Received: (qmail 2797 invoked from network); 3 Jul 1997 16:25:39 -0000 Received: from radmail.rad.co.il (207.232.32.10) by mx12.netvision.net.il with SMTP; 3 Jul 1997 16:25:39 -0000 Received: from suri.rad.co.il ([192.115.244.81]) by radmail.rad.co.il (post.office MTA v2.0 0813 ID# 0-12126) with SMTP id AAA6272; Thu, 3 Jul 1997 19:21:01 +0300 Message-Id: <3.0.32.19970703191814.006a28c8@radmail.rad.co.il> X-Sender: suri@radmail.rad.co.il X-Mailer: Windows Eudora Pro Version 3.0 Demo (32) Date: Thu, 03 Jul 1997 19:18:16 +0300 To: luca.fantolino@CSELT.IT (Luca Fantolino), ietf-ppp@merit.edu From: Uri Shabi Subject: Re: PPP over Ethernet Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Hi, There are some protocols: L2F from Cisco PPTP from microsoft and L2TP from the IETF As you can understand Windows NT supports PPTP, Routers (cisco) supports L2F and in the future all vendors (hopefully) will support L2TP. L2TP is currently a draft in the IETF PPP Group. You may find some more information in the IETF web: http://www.ietf.org. There is an additional L2TP specific site: http://www.masinter.net/~l2tp/ Hope this help, Uri. At 05:53 PM 03-07-97 +0100, Luca Fantolino wrote: >I looked through the IETF archives searching a solution to let a LAN (e.g. >Ethernet) attached PC to initiate a PPP session. This may be usefull in >order to perform dynamic IP-address assignement, autentication, etc. >The configuration I have in mind is depicted in the figure below. In that >case PPP over Ethernet (or other LAN tecnology) is required, but as far as >I know this protocol does not exist. > > > PC Server > ----- +-----+ > | | PPP Session | | > | | <=-=-=-=-=-=-=-=-> | | > ----- | | > +---------+ | | > +---------+ +-----+ > # # > # # > ================================== > LAN (Ethernet) > > >A more complex configuration, depicted in figure below, is the case in >which the PPP link is extended over a WAN (e.g. Frame Relay) using L2TP. >Also in that case it is needed PPP over Ethernet. >This scenario may be interesting to provide services to Small Offices or >Home Offices (SOHO) in which Ethernet may be a cost-effective solution to >connect one or few PCs, but no permanent connection to Internet is >required. > > > PC LNS > ----- +-----+ > | | PPP Session | | > | | <=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-> | | > ----- | | > +---------+ +------------+ L2TP Session | | > +---------+ | LAC | <=-=-=-=-=-=-=-> | | > # +------------+ +-----+ > # # \ / > ============================= \_____________________/ > LAN (Ethernet) WAN (Frame Relay) > > >Is there anybody who knows of any solution (standard o proprietary)? >Thank you >Luca > > > _______________________________________________________________________ > > Luca Fantolino > CSELT (a STET Company) Tel: +39 11 228 7543 > via G. Reiss Romoli, 274 Fax: +39 11 228 5069 > 10148 Torino - ITALY E-Mail: Luca.Fantolino@Cselt.It > _______________________________________________________________________ > > > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jul 3 12:19:19 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id MAA16398; Thu, 3 Jul 1997 12:19:17 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 3 Jul 1997 12:19:09 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id MAA16380 for ietf-ppp-outgoing; Thu, 3 Jul 1997 12:19:08 -0400 (EDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.29]) by merit.edu (8.8.5/8.8.5) with ESMTP id MAA16376 for ; Thu, 3 Jul 1997 12:19:02 -0400 (EDT) Received: by mail4.microsoft.com with Internet Mail Service (5.0.1458.49) id ; Thu, 3 Jul 1997 09:20:15 -0700 Message-ID: From: Gurdeep Singh Pall To: "'luca.fantolino@CSELT.IT'" , ietf-ppp@merit.edu Subject: RE: PPP over Ethernet Date: Thu, 3 Jul 1997 09:18:44 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Sender: owner-ietf-ppp@merit.edu L2TP and PPTP support the first scenario you describe. You can use Windows NT 4.0 on the PC to connect to a Windows NT 4.0 Server using PPTP today. This support is in beta for Win95 (available from www.microsoft.com). Other companies (NTS at www.nts.com for example) also have Windows 3.1 and MAC clients that connect to Windows NT4.0 Server using PPTP. The second scenario you describe can be achieved with multiple PPTP tunnels initiating at the PC. You try this out with Windows NT 4.0. Gurdeep > -----Original Message----- > From: luca.fantolino@CSELT.IT [SMTP:luca.fantolino@CSELT.IT] > Sent: Thursday, July 03, 1997 9:54 AM > To: ietf-ppp@merit.edu > Subject: PPP over Ethernet > > I looked through the IETF archives searching a solution to let a LAN > (e.g. > Ethernet) attached PC to initiate a PPP session. This may be usefull > in > order to perform dynamic IP-address assignement, autentication, etc. > The configuration I have in mind is depicted in the figure below. In > that > case PPP over Ethernet (or other LAN tecnology) is required, but as > far as > I know this protocol does not exist. > > > PC Server > ----- +-----+ > | | PPP Session | | > | | <=-=-=-=-=-=-=-=-> | | > ----- | | > +---------+ | | > +---------+ +-----+ > # # > # # > ================================== > LAN (Ethernet) > > > A more complex configuration, depicted in figure below, is the case in > which the PPP link is extended over a WAN (e.g. Frame Relay) using > L2TP. > Also in that case it is needed PPP over Ethernet. > This scenario may be interesting to provide services to Small Offices > or > Home Offices (SOHO) in which Ethernet may be a cost-effective solution > to > connect one or few PCs, but no permanent connection to Internet is > required. > > > PC LNS > ----- +-----+ > | | PPP Session | | > | | <=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-> | | > ----- | | > +---------+ +------------+ L2TP Session | | > +---------+ | LAC | <=-=-=-=-=-=-=-> | | > # +------------+ +-----+ > # # \ / > ============================= \_____________________/ > LAN (Ethernet) WAN (Frame Relay) > > > Is there anybody who knows of any solution (standard o proprietary)? > Thank you > Luca > > > > ______________________________________________________________________ > _ > > Luca Fantolino > CSELT (a STET Company) Tel: +39 11 228 7543 > via G. Reiss Romoli, 274 Fax: +39 11 228 5069 > 10148 Torino - ITALY E-Mail: > Luca.Fantolino@Cselt.It > > ______________________________________________________________________ > _ > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jul 3 12:36:09 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id MAA16834; Thu, 3 Jul 1997 12:36:08 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 3 Jul 1997 12:35:51 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id MAA16811 for ietf-ppp-outgoing; Thu, 3 Jul 1997 12:35:50 -0400 (EDT) Received: from ns.trancell.stph.net (root@[196.12.55.2]) by merit.edu (8.8.5/8.8.5) with ESMTP id MAA16799 for ; Thu, 3 Jul 1997 12:35:38 -0400 (EDT) Received: from prasanna.trancell.stph.net (kasturi.trancell.stph.net [196.12.55.7]) by ns.trancell.stph.net (8.7.3/8.7.3) with SMTP id WAA03857 for ; Thu, 3 Jul 1997 22:23:27 +0530 (IST) Received: by prasanna.trancell.stph.net with Microsoft Mail id <01BC87FD.B1ACD1A0@prasanna.trancell.stph.net>; Thu, 3 Jul 1997 22:08:53 -0700 Message-ID: <01BC87FD.B1ACD1A0@prasanna.trancell.stph.net> From: "Ravindra C.P" To: "'ietf-ppp@merit.edu'" Subject: DNS address through IPCP ? Date: Thu, 3 Jul 1997 22:08:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Hi, Is there any way by which we can obtain the DNS server address through the PPP negotiations. I know we can dynamically obtain an IP address by IPCP negotiations. Can anybody give me pointers to find out if there are any extended options in IPCP to obtain the DNS address and the domain name. I have seen in win95 where you can specify to obtain the DNS address from the server to whom we dial in to. Any sort of help will be very much appreciated. Thanks Ravi - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jul 3 12:53:37 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id MAA17600; Thu, 3 Jul 1997 12:53:35 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 3 Jul 1997 12:52:58 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id MAA17548 for ietf-ppp-outgoing; Thu, 3 Jul 1997 12:52:57 -0400 (EDT) Received: from jaba.rampnet.com (link-rampnet.rampnet.com [206.14.182.236]) by merit.edu (8.8.5/8.8.5) with ESMTP id MAA17540 for ; Thu, 3 Jul 1997 12:52:52 -0400 (EDT) Received: from panda.rampnet.com ([205.158.93.169]) by jaba.rampnet.com (post.office MTA v2.0 0813 ID# 0-18176U100) with SMTP id AAA206; Thu, 3 Jul 1997 09:55:09 -0700 Received: by panda.rampnet.com (SMI-8.6/SMI-SVR4) id JAA06778; Thu, 3 Jul 1997 09:54:30 -0700 Date: Thu, 3 Jul 1997 09:54:30 -0700 From: ashok@rampnet.com (Ashok Ramachandra) Message-Id: <199707031654.JAA06778@panda.rampnet.com> To: ietf-ppp@merit.edu, luca.fantolino@CSELT.IT Subject: Re: PPP over Ethernet X-Sun-Charset: US-ASCII Sender: owner-ietf-ppp@merit.edu Hi, The first scenario can be easily done thru PPTP or L2TP. The second one can also done in a slightly different way if the aim is to only provide cost effective Internet access for the SOHO segment. We can have the immediate router for the SOHO LAN to be the PAC/LAC who will initiate the tunnel activities on behalf of PC's on LAN. Even the PPP session will also be done by the immediate router itself. For each of the different PC's we can multiple sessions from the PAC/LAC. Does that sound right?? Thanks, R.Ashok > > I looked through the IETF archives searching a solution to let a LAN (e.g. > Ethernet) attached PC to initiate a PPP session. This may be usefull in > order to perform dynamic IP-address assignement, autentication, etc. > The configuration I have in mind is depicted in the figure below. In that > case PPP over Ethernet (or other LAN tecnology) is required, but as far as > I know this protocol does not exist. > > > PC Server > ----- +-----+ > | | PPP Session | | > | | <=-=-=-=-=-=-=-=-> | | > ----- | | > +---------+ | | > +---------+ +-----+ > # # > # # > ================================== > LAN (Ethernet) > > > A more complex configuration, depicted in figure below, is the case in > which the PPP link is extended over a WAN (e.g. Frame Relay) using L2TP. > Also in that case it is needed PPP over Ethernet. > This scenario may be interesting to provide services to Small Offices or > Home Offices (SOHO) in which Ethernet may be a cost-effective solution to > connect one or few PCs, but no permanent connection to Internet is > required. > > > PC LNS > ----- +-----+ > | | PPP Session | | > | | <=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-> | | > ----- | | > +---------+ +------------+ L2TP Session | | > +---------+ | LAC | <=-=-=-=-=-=-=-> | | > # +------------+ +-----+ > # # \ / > ============================= \_____________________/ > LAN (Ethernet) WAN (Frame Relay) > > > Is there anybody who knows of any solution (standard o proprietary)? > Thank you > Luca > > > _______________________________________________________________________ > > Luca Fantolino > CSELT (a STET Company) Tel: +39 11 228 7543 > via G. Reiss Romoli, 274 Fax: +39 11 228 5069 > 10148 Torino - ITALY E-Mail: Luca.Fantolino@Cselt.It > _______________________________________________________________________ > > > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jul 3 13:11:49 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id NAA18425; Thu, 3 Jul 1997 13:11:48 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 3 Jul 1997 13:11:39 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id NAA18407 for ietf-ppp-outgoing; Thu, 3 Jul 1997 13:11:38 -0400 (EDT) Received: from wjao002-IN.sita.int (corp-miscpx.sita.int [57.250.224.19]) by merit.edu (8.8.5/8.8.5) with ESMTP id NAA18389 for ; Thu, 3 Jul 1997 13:11:31 -0400 (EDT) Received: by wjao002-IN.sita.int; Sendmail 1.40.112.8 (26AUG93-fma/mjr/gauntlet) id AA017929859; Thu, 3 Jul 1997 17:10:59 GMT Received: from ncept.pt.nce.sita.int(57.4.169.130) by wjao002 via smap (3.2) id xma001778; Thu, 3 Jul 97 17:10:46 GMT Received: from pc-ptel.pt.nce.sita.int by ncept.pt.nce.sita.int (8.8.5/SitaNet-1.4) id TAA20036; Thu, 3 Jul 1997 19:13:35 +0200 (MET DST) Message-Id: <199707031713.TAA20036@ncept.pt.nce.sita.int> From: "Eric LEVEAU" To: , Subject: Fw: DNS address through IPCP ? Date: Thu, 3 Jul 1997 19:10:38 +0200 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1161 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Sorry it's not RFC 1915 but RFC 1877 by Cobb S. ---------- > From: Eric LEVEAU > To: Ravindra C.P ; 'ietf-ppp@merit.edu' > Subject: Re: DNS address through IPCP ? > Date: Thursday 3 July 1997 19:07 PM > > There is an extension for IPCP called PPP IPCP Extensions for Name Server > Addreses (RFC 1915) that describes the DNS server address through the PPP > negotiations. > > Hope this help, > Eric. > > ---------- > > From: Ravindra C.P > > To: 'ietf-ppp@merit.edu' > > Subject: DNS address through IPCP ? > > Date: Friday 4 July 1997 7:08 AM > > > > Hi, > > Is there any way by which we can obtain the DNS server address > > through the PPP negotiations. I know we can dynamically obtain an IP > address > > by IPCP negotiations. Can anybody give me pointers to find out if there > are > > any extended options in IPCP to obtain the DNS address and the domain > > name. I have seen in win95 where you can specify to obtain the DNS > address > > from the server to whom we dial in to. Any sort of help will be very much > > > appreciated. > > > > Thanks > > Ravi > > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jul 3 13:08:43 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id NAA18276; Thu, 3 Jul 1997 13:08:38 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 3 Jul 1997 13:08:26 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id NAA18248 for ietf-ppp-outgoing; Thu, 3 Jul 1997 13:08:26 -0400 (EDT) Received: from VNET.IBM.COM (vnet.ibm.com [204.146.168.194]) by merit.edu (8.8.5/8.8.5) with SMTP id NAA18244 for ; Thu, 3 Jul 1997 13:08:17 -0400 (EDT) Received: from ATLVMES0.VNET.IBM.COM by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 2004; Thu, 03 Jul 97 13:08:14 EDT Message-Id: <19970703.130736.CHANDU@RALVM29> Date: 3 Jul 1997 13:07:36 EDT From: To: Sender: owner-ietf-ppp@merit.edu From: chandru ( Chandrasekhar buduguru ) Subject: DNS address through IPCP ? .ddn trancell.stph.net(ravi) see RFC 1877, extensions to IPCP for DNS Chandu * * chandu@teil.soft.net chandu@vnet.ibm.com * *** Reply to note of 07/03/97 12:58 ========================================================================= Received: from merit.edu by VNET.IBM.COM (IBM VM SMTP V2R3) with TCP; Thu, 03 Jul 97 12:59:24 EDT Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id MAA16823; Thu, 3 Jul 1997 12:35:55 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 3 Jul 1997 12:35:51 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id MAA16811 for ietf-ppp-outgoing; Thu, 3 Jul 1997 12:35:50 -0400 (EDT) Received: from ns.trancell.stph.net (root@[196.12.55.2]) by merit.edu (8.8.5/8.8.5) with ESMTP id MAA16799 for ; Thu, 3 Jul 1997 12:35:38 -0400 (EDT) Received: from prasanna.trancell.stph.net (kasturi.trancell.stph.net [196.12.55.7]) by ns.trancell.stph.net (8.7.3/8.7.3) with SMTP id WAA03857 for ; Thu, 3 Jul 1997 22:23:27 +0530 (IST) Received: by prasanna.trancell.stph.net with Microsoft Mail id <01BC87FD.B1ACD1A0@prasanna.trancell.stph.net>; Thu, 3 Jul 1997 22:08:53 -0700 Message-ID: <01BC87FD.B1ACD1A0@prasanna.trancell.stph.net> From: "Ravindra C.P" To: "'ietf-ppp@merit.edu'" Subject: DNS address through IPCP ? Date: Thu, 3 Jul 1997 22:08:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Hi, Is there any way by which we can obtain the DNS server address through the PPP negotiations. I know we can dynamically obtain an IP address by IPCP negotiations. Can anybody give me pointers to find out if there are any extended options in IPCP to obtain the DNS address and the domain name. I have seen in win95 where you can specify to obtain the DNS address from the server to whom we dial in to. Any sort of help will be very much appreciated. Thanks Ravi - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jul 3 13:18:38 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id NAA18673; Thu, 3 Jul 1997 13:18:37 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 3 Jul 1997 13:18:20 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id NAA18629 for ietf-ppp-outgoing; Thu, 3 Jul 1997 13:18:19 -0400 (EDT) Received: from jaba.rampnet.com (link-rampnet.rampnet.com [206.14.182.236]) by merit.edu (8.8.5/8.8.5) with ESMTP id NAA18621 for ; Thu, 3 Jul 1997 13:18:11 -0400 (EDT) Received: from panda.rampnet.com ([205.158.93.169]) by jaba.rampnet.com (post.office MTA v2.0 0813 ID# 0-18176U100) with SMTP id AAA149; Thu, 3 Jul 1997 10:20:27 -0700 Received: by panda.rampnet.com (SMI-8.6/SMI-SVR4) id KAA06832; Thu, 3 Jul 1997 10:19:51 -0700 Date: Thu, 3 Jul 1997 10:19:51 -0700 From: ashok@rampnet.com (Ashok Ramachandra) Message-Id: <199707031719.KAA06832@panda.rampnet.com> To: ietf-ppp@merit.edu, vjs@mica.denver.sgi.com, ashok@rampnet.com Subject: re: DNS address through IPCP ? X-Sun-Charset: US-ASCII Sender: owner-ietf-ppp@merit.edu > From ashok@rampnet.com Thu Jul 3 10:16:04 1997 > Date: Thu, 3 Jul 1997 10:13:55 -0700 > From: ashok@rampnet.com (Ashok Ramachandra) > To: ietf-ppp@merit.edu, vjs@mica.denver.sgi.com > Subject: re: DNS address through IPCP ? > X-Sun-Charset: US-ASCII > Sender: owner-ietf-ppp@merit.edu > Content-Length: 1412 > > > > From vjs@mica.denver.sgi.com Thu Jul 3 10:08:56 1997 > > Date: Thu, 3 Jul 1997 11:04:17 -0600 > > From: vjs@mica.denver.sgi.com (Vernon Schryver) > > To: ietf-ppp@merit.edu > > Subject: re: DNS address through IPCP ? > > Sender: owner-ietf-ppp@merit.edu > > Content-Length: 772 > > > > >From: "Ravindra C.P" > > > > > Is there any way by which we can obtain the DNS server address > > > through the PPP negotiations. I know we can dynamically obtain an IP address > > > by IPCP negotiations. Can anybody give me pointers to find out if there are > > > any extended options in IPCP to obtain the DNS address and the domain > > > name. I have seen in win95 where you can specify to obtain the DNS address > > > from the server to whom we dial in to. Any sort of help will be very much > > > appreciated. > > > > Why not send a request to port 53 at the IP address you obtained for > > the IPCP peer? > > > There are very less chances that DNS server of the DHCP server > will be listening on the IP address abtained by the peer. If not > server I also suspect any forwarding agents too present on the > DIAL IN routers. > > Instead I presume there are extended LCP options thru which we > can negotiate the DNS server's addresses. > They are Extended IPCP negotiations. > > Or why not send a DHCP request? > > > > > > Most of the IETF PPP working group is opposed to dragging > > more upper layer protocols down into PPP. > > > > > > Vernon Schryver, vjs@sgi.com > > > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jul 3 13:05:00 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id NAA18176; Thu, 3 Jul 1997 13:04:59 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 3 Jul 1997 13:04:35 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id NAA18149 for ietf-ppp-outgoing; Thu, 3 Jul 1997 13:04:34 -0400 (EDT) Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.8.5/8.8.5) with SMTP id NAA18145 for ; Thu, 3 Jul 1997 13:04:29 -0400 (EDT) Received: from mica.denver.sgi.com (mica.denver.sgi.com [169.238.67.6]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id KAA22660; Thu, 3 Jul 1997 10:04:24 -0700 env-from (vjs@mica.denver.sgi.com) Received: (from vjs@localhost) by mica.denver.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA08262; Thu, 3 Jul 1997 11:04:17 -0600 Date: Thu, 3 Jul 1997 11:04:17 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199707031704.LAA08262@mica.denver.sgi.com> To: ietf-ppp@merit.edu Subject: re: DNS address through IPCP ? Sender: owner-ietf-ppp@merit.edu >From: "Ravindra C.P" > Is there any way by which we can obtain the DNS server address > through the PPP negotiations. I know we can dynamically obtain an IP address > by IPCP negotiations. Can anybody give me pointers to find out if there are > any extended options in IPCP to obtain the DNS address and the domain > name. I have seen in win95 where you can specify to obtain the DNS address > from the server to whom we dial in to. Any sort of help will be very much > appreciated. Why not send a request to port 53 at the IP address you obtained for the IPCP peer? Or why not send a DHCP request? Most of the IETF PPP working group is opposed to dragging more upper layer protocols down into PPP. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jul 3 13:09:25 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id NAA18325; Thu, 3 Jul 1997 13:09:23 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 3 Jul 1997 13:09:09 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id NAA18294 for ietf-ppp-outgoing; Thu, 3 Jul 1997 13:09:08 -0400 (EDT) Received: from wjao002-IN.sita.int (wjao002.sita.int [57.250.224.19]) by merit.edu (8.8.5/8.8.5) with ESMTP id NAA18261 for ; Thu, 3 Jul 1997 13:09:03 -0400 (EDT) Received: by wjao002-IN.sita.int; Sendmail 1.40.112.8 (26AUG93-fma/mjr/gauntlet) id AA014889708; Thu, 3 Jul 1997 17:08:28 GMT Received: from ncept.pt.nce.sita.int(57.4.169.130) by wjao002 via smap (3.2) id xma001464; Thu, 3 Jul 97 17:08:19 GMT Received: from pc-ptel.pt.nce.sita.int by ncept.pt.nce.sita.int (8.8.5/SitaNet-1.4) id TAA20020; Thu, 3 Jul 1997 19:10:45 +0200 (MET DST) Message-Id: <199707031710.TAA20020@ncept.pt.nce.sita.int> From: "Eric LEVEAU" To: "Ravindra C.P" , "'ietf-ppp@merit.edu'" Subject: Re: DNS address through IPCP ? Date: Thu, 3 Jul 1997 19:07:48 +0200 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1161 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu There is an extension for IPCP called PPP IPCP Extensions for Name Server Addreses (RFC 1915) that describes the DNS server address through the PPP negotiations. Hope this help, Eric. ---------- > From: Ravindra C.P > To: 'ietf-ppp@merit.edu' > Subject: DNS address through IPCP ? > Date: Friday 4 July 1997 7:08 AM > > Hi, > Is there any way by which we can obtain the DNS server address > through the PPP negotiations. I know we can dynamically obtain an IP address > by IPCP negotiations. Can anybody give me pointers to find out if there are > any extended options in IPCP to obtain the DNS address and the domain > name. I have seen in win95 where you can specify to obtain the DNS address > from the server to whom we dial in to. Any sort of help will be very much > appreciated. > > Thanks > Ravi > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jul 3 13:12:37 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id NAA18479; Thu, 3 Jul 1997 13:12:36 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 3 Jul 1997 13:12:24 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id NAA18451 for ietf-ppp-outgoing; Thu, 3 Jul 1997 13:12:24 -0400 (EDT) Received: from jaba.rampnet.com (link-rampnet.rampnet.com [206.14.182.236]) by merit.edu (8.8.5/8.8.5) with ESMTP id NAA18447 for ; Thu, 3 Jul 1997 13:12:18 -0400 (EDT) Received: from panda.rampnet.com ([205.158.93.169]) by jaba.rampnet.com (post.office MTA v2.0 0813 ID# 0-18176U100) with SMTP id AAA325; Thu, 3 Jul 1997 10:14:30 -0700 Received: by panda.rampnet.com (SMI-8.6/SMI-SVR4) id KAA06820; Thu, 3 Jul 1997 10:13:55 -0700 Date: Thu, 3 Jul 1997 10:13:55 -0700 From: ashok@rampnet.com (Ashok Ramachandra) Message-Id: <199707031713.KAA06820@panda.rampnet.com> To: ietf-ppp@merit.edu, vjs@mica.denver.sgi.com Subject: re: DNS address through IPCP ? X-Sun-Charset: US-ASCII Sender: owner-ietf-ppp@merit.edu > From vjs@mica.denver.sgi.com Thu Jul 3 10:08:56 1997 > Date: Thu, 3 Jul 1997 11:04:17 -0600 > From: vjs@mica.denver.sgi.com (Vernon Schryver) > To: ietf-ppp@merit.edu > Subject: re: DNS address through IPCP ? > Sender: owner-ietf-ppp@merit.edu > Content-Length: 772 > > >From: "Ravindra C.P" > > > Is there any way by which we can obtain the DNS server address > > through the PPP negotiations. I know we can dynamically obtain an IP address > > by IPCP negotiations. Can anybody give me pointers to find out if there are > > any extended options in IPCP to obtain the DNS address and the domain > > name. I have seen in win95 where you can specify to obtain the DNS address > > from the server to whom we dial in to. Any sort of help will be very much > > appreciated. > > Why not send a request to port 53 at the IP address you obtained for > the IPCP peer? > There are very less chances that DNS server of the DHCP server will be listening on the IP address abtained by the peer. If not server I also suspect any forwarding agents too present on the DIAL IN routers. Instead I presume there are extended LCP options thru which we can negotiate the DNS server's addresses. > Or why not send a DHCP request? > > > Most of the IETF PPP working group is opposed to dragging > more upper layer protocols down into PPP. > > > Vernon Schryver, vjs@sgi.com > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jul 3 13:27:51 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id NAA19137; Thu, 3 Jul 1997 13:27:49 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 3 Jul 1997 13:27:31 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id NAA19114 for ietf-ppp-outgoing; Thu, 3 Jul 1997 13:27:30 -0400 (EDT) Received: from greatdane.cisco.com (greatdane.cisco.com [171.69.1.141]) by merit.edu (8.8.5/8.8.5) with SMTP id NAA19110 for ; Thu, 3 Jul 1997 13:27:24 -0400 (EDT) Received: (fox@localhost) by greatdane.cisco.com (8.6.12/8.6.5) id KAA05791; Thu, 3 Jul 1997 10:15:46 -0700 From: Craig Fox Message-Id: <199707031715.KAA05791@greatdane.cisco.com> Subject: Re: DNS address through IPCP ? To: ravi@trancell.stph.net (Ravindra C.P) Date: Thu, 3 Jul 97 10:15:46 PDT Cc: ietf-ppp@merit.edu In-Reply-To: <01BC87FD.B1ACD1A0@prasanna.trancell.stph.net>; from "Ravindra C.P" at Jul 3, 97 10:08 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ietf-ppp@merit.edu > > Hi, > Is there any way by which we can obtain the DNS server address > through the PPP negotiations. I know we can dynamically obtain an IP address > by IPCP negotiations. Can anybody give me pointers to find out if there are > any extended options in IPCP to obtain the DNS address and the domain > name. I have seen in win95 where you can specify to obtain the DNS address > from the server to whom we dial in to. Any sort of help will be very much > appreciated. > Take a look at RFC 1877. Craig > Thanks > Ravi > > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jul 3 13:33:00 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id NAA19407; Thu, 3 Jul 1997 13:32:57 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 3 Jul 1997 13:32:21 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id NAA19345 for ietf-ppp-outgoing; Thu, 3 Jul 1997 13:32:20 -0400 (EDT) Received: from fennel.acc.com (fennel.acc.com [129.192.64.25]) by merit.edu (8.8.5/8.8.5) with SMTP id NAA19323 for ; Thu, 3 Jul 1997 13:32:05 -0400 (EDT) Received: from clover.acc.com.acc.com by fennel.acc.com (4.1/SMI-4.1) id AA13383; Thu, 3 Jul 97 10:31:46 PDT From: evan@acc.com (Evan Caves) Message-Id: <9707031731.AA13383@fennel.acc.com> Subject: Re: DNS address through IPCP ? To: ravi@trancell.stph.net (Ravindra C.P) Date: Thu, 3 Jul 1997 10:31:49 -0700 (PDT) Cc: ietf-ppp@merit.edu In-Reply-To: <01BC87FD.B1ACD1A0@prasanna.trancell.stph.net> from "Ravindra C.P" at Jul 3, 97 10:08:40 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu I believe rfc1877 addresses this. evan - > > Hi, > Is there any way by which we can obtain the DNS server address > through the PPP negotiations. I know we can dynamically obtain an IP address > by IPCP negotiations. Can anybody give me pointers to find out if there are > any extended options in IPCP to obtain the DNS address and the domain > name. I have seen in win95 where you can specify to obtain the DNS address > from the server to whom we dial in to. Any sort of help will be very much > appreciated. > > Thanks > Ravi > > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jul 3 13:37:01 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id NAA19695; Thu, 3 Jul 1997 13:36:57 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 3 Jul 1997 13:36:19 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id NAA19644 for ietf-ppp-outgoing; Thu, 3 Jul 1997 13:36:18 -0400 (EDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.23]) by merit.edu (8.8.5/8.8.5) with ESMTP id NAA19618 for ; Thu, 3 Jul 1997 13:35:58 -0400 (EDT) Received: by mail3.microsoft.com with Internet Mail Service (5.0.1458.49) id ; Thu, 3 Jul 1997 10:38:32 -0700 Message-ID: From: Gurdeep Singh Pall To: "'Ravindra C.P'" , "'ietf-ppp@merit.edu'" Subject: RE: DNS address through IPCP ? Date: Thu, 3 Jul 1997 10:35:29 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Sender: owner-ietf-ppp@merit.edu Windows 95 and Windows NT use IPCP options to request DNS and WINS addresses from the peer. This behavior is specified in an informational document - RFC1877. It was agreed at Dallas '95 IETF that implementions should use the new DHCP-INFORM packet (a stateless configuration request sent after IPCP is up) to get DNS address and other configuration options. It was also agreed that this information should be included in the new IPCP i-ds. Gurdeep PS: Note that the DHCP-INFORM allows just the configuration options to be retrieved without the IP address. > -----Original Message----- > From: Ravindra C.P [SMTP:ravi@trancell.stph.net] > Sent: Thursday, July 03, 1997 10:09 PM > To: 'ietf-ppp@merit.edu' > Subject: DNS address through IPCP ? > > Hi, > Is there any way by which we can obtain the DNS server address > through the PPP negotiations. I know we can dynamically obtain an IP > address > by IPCP negotiations. Can anybody give me pointers to find out if > there are > any extended options in IPCP to obtain the DNS address and the domain > name. I have seen in win95 where you can specify to obtain the DNS > address > from the server to whom we dial in to. Any sort of help will be very > much > appreciated. > > Thanks > Ravi - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jul 3 13:41:32 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id NAA19937; Thu, 3 Jul 1997 13:41:28 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 3 Jul 1997 13:41:12 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id NAA19909 for ietf-ppp-outgoing; Thu, 3 Jul 1997 13:41:10 -0400 (EDT) Received: from ftp.com (wd40.ftp.com [128.127.2.122]) by merit.edu (8.8.5/8.8.5) with SMTP id NAA19903 for ; Thu, 3 Jul 1997 13:41:03 -0400 (EDT) Received: from ftp.com by ftp.com ; Thu, 3 Jul 1997 13:40:31 -0400 Received: from mailserv-2high.ftp.com by ftp.com ; Thu, 3 Jul 1997 13:40:31 -0400 Received: from bray-2.ftp.com by MAILSERV-2HIGH.FTP.COM (SMI-8.6/SMI-SVR4) id NAA05653; Thu, 3 Jul 1997 13:36:34 -0400 Message-Id: <199707031736.NAA05653@MAILSERV-2HIGH.FTP.COM> X-Mapi-Messageclass: IPM To: ravi@trancell.stph.net, ietf-ppp@merit.edu X-Mailer: FTP Software Internet Mail 2.0 Mime-Version: 1.0 From: John Bray Subject: RE: DNS address through IPCP ? Date: Thu, 03 Jul 1997 13:40:30 -0400 Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu >>Reply to message from Ravindra C.P (ravi@trancell.stph.net) dated 7/3/97 1:11 PM > Hi, > Is there any way by which we can obtain the > DNS server address > through the PPP negotiations. I know we can > dynamically obtain an IP address > by IPCP negotiations. Can anybody give me pointers to > find out if there are > any extended options in IPCP to obtain the DNS > address and the domain > name. I have seen in win95 where you can specify to > obtain the DNS address > from the server to whom we dial in to. Any sort of help > will be very much > appreciated. > > Thanks > Ravi > > >>End of message RFC1877 describes a Microsoft extension to IPCP to obtain name server addresses (DNS and NetBIOS), but not all implementations support it (it's not a standard). _________________________________________________ John Bray Senior Staff Engineer FTP Software, Inc. 2 High St. North Andover, MA 01845 E-mail: bray@ftp.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jul 3 13:44:55 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id NAA20072; Thu, 3 Jul 1997 13:44:53 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 3 Jul 1997 13:44:41 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id NAA20054 for ietf-ppp-outgoing; Thu, 3 Jul 1997 13:44:40 -0400 (EDT) Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.8.5/8.8.5) with SMTP id NAA20040 for ; Thu, 3 Jul 1997 13:44:29 -0400 (EDT) Received: from mica.denver.sgi.com (mica.denver.sgi.com [169.238.67.6]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id KAA07626 for <@sgi.engr.sgi.com:ietf-ppp@merit.edu>; Thu, 3 Jul 1997 10:44:26 -0700 env-from (vjs@mica.denver.sgi.com) Received: (from vjs@localhost) by mica.denver.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA08404 for ietf-ppp@merit.edu; Thu, 3 Jul 1997 11:44:20 -0600 Date: Thu, 3 Jul 1997 11:44:20 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199707031744.LAA08404@mica.denver.sgi.com> To: ietf-ppp@merit.edu Subject: re: DNS address through IPCP ? Sender: owner-ietf-ppp@merit.edu > > There are very less chances that DNS server of the DHCP server > > will be listening on the IP address abtained by the peer. If not > > server I also suspect any forwarding agents too present on the > > DIAL IN routers. So change the system that owns the peer's IP address to run at least a forwarding DNS server. If you are using bridges, that is obviously not a problem. If you are using routers that admit their own IP address, then chances are they wil forward DHCP if they don't serve it themselves. > > Instead I presume there are extended LCP options thru which we > > can negotiate the DNS server's addresses. > > > They are Extended IPCP negotiations. What is the difference between configuring the peer to know the IP address of a third party DNS server and configuring the peer to be a caching/forwarding DNS server? Except that the second choice is obviously far better? If you are only using your own and Microsoft boxes, you can use that mechanism. Otherwise, a more de facto standard approach is likely to work better. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jul 3 16:14:37 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id QAA24804; Thu, 3 Jul 1997 16:14:26 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 3 Jul 1997 16:13:50 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id QAA24768 for ietf-ppp-outgoing; Thu, 3 Jul 1997 16:13:49 -0400 (EDT) Received: from coppermountain.com (cmcnt.coppermountain.com [206.71.190.2]) by merit.edu (8.8.5/8.8.5) with ESMTP id QAA24761 for ; Thu, 3 Jul 1997 16:13:44 -0400 (EDT) Received: by coppermountain.com from localhost (router,SLMail V2.5); Thu, 03 Jul 1997 13:14:16 -0800 Received: by coppermountain.com from eric (206.71.190.13::mail daemon; unverified,SLMail V2.5); Thu, 03 Jul 1997 13:14:16 -0800 Message-Id: <2.2.32.19970703201434.00301550@coppermountain.com> X-Sender: "Eric Michelsen" X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 03 Jul 1997 13:14:34 -0700 To: ietf-ppp@merit.edu From: "Eric L. Michelsen" Subject: re: DNS address through IPCP ? Sender: owner-ietf-ppp@merit.edu At 11:04 AM 7/3/97 -0600, Vernon Schryver wrote: >>From: "Ravindra C.P" > >> Is there any way by which we can obtain the DNS server address >> through the PPP negotiations. I know we can dynamically obtain an IP address >> by IPCP negotiations. Can anybody give me pointers to find out if there are >> any extended options in IPCP to obtain the DNS address and the domain >> name. I have seen in win95 where you can specify to obtain the DNS address >> from the server to whom we dial in to. Any sort of help will be very much >> appreciated. > >Why not send a request to port 53 at the IP address you obtained for >the IPCP peer? > >Or why not send a DHCP request? > > >Most of the IETF PPP working group is opposed to dragging >more upper layer protocols down into PPP. > > >Vernon Schryver, vjs@sgi.com This is an interesting point. I've often wondered if anyone used DHCP over IP/PPP, instead of the IP address option in IPCP. There are some scenarios where this method has benefits, including the one described above. Does anyone have knowledge of systems using DHCP over IP/PPP? If so, is the PPP peer closest to the DHCP requestor configured as a DHCP relay agent? -- Eric L. Michelsen, Copper Mountain Networks, Inc. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Jul 4 16:38:56 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id QAA08846; Fri, 4 Jul 1997 16:38:42 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 4 Jul 1997 16:35:25 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id QAA08812 for ietf-ppp-outgoing; Fri, 4 Jul 1997 16:35:24 -0400 (EDT) Received: from ns.newbridge.com (ns.newbridge.com [192.75.23.67]) by merit.edu (8.8.5/8.8.5) with SMTP id QAA08808 for ; Fri, 4 Jul 1997 16:35:20 -0400 (EDT) Received: (from smap@localhost) by ns.newbridge.com (8.6.12/8.6.12) id QAA03969; Fri, 4 Jul 1997 16:35:13 -0400 Received: from kanata-gw1(192.75.23.72) by ns via smap (V1.3) id sma003949; Fri Jul 4 16:34:52 1997 Received: from kanmaster.ca.newbridge.com by kanata-gw1.ca.newbridge.com via smtpd (for ns.newbridge.com [192.75.23.67]) with SMTP; 4 Jul 1997 20:34:52 UT Received: (from smap@localhost) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) id QAA18914; Fri, 4 Jul 1997 16:34:51 -0400 Received: from sid.ca.newbridge.com(138.120.144.49) by kanmaster.ca.newbridge.com via smap (V1.3) id sma018820; Fri Jul 4 16:32:25 1997 Date: Fri, 4 Jul 1997 16:35:17 -0400 (EDT) From: Ian Duncan X-Sender: iduncan@sid Reply-To: Ian Duncan To: Luca Fantolino cc: ietf-ppp@merit.edu Subject: Re: PPP over Ethernet In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu On Thu, 3 Jul 1997, Luca Fantolino wrote: > I looked through the IETF archives searching a solution to let a LAN (e.g. > Ethernet) attached PC to initiate a PPP session. This may be usefull in > order to perform dynamic IP-address assignement, autentication, etc. Accepting certain constraints, you could do this without any additional standards activity by using current documents and existing code points in SNAP and the NLPID space. But it's a bit unclear what exactly you want to achieve. There's a fairly well developed mechanism for dynamic configuration (DHCP) and hope that IPSEC does authentication. The PPP style of authentication isn't real useful on NBMA nets in any case. -- Ian Duncan Newbridge Networks Corp. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 8 04:40:15 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id EAA29302; Tue, 8 Jul 1997 04:39:30 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 8 Jul 1997 04:32:58 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id EAA29259 for ietf-ppp-outgoing; Tue, 8 Jul 1997 04:32:57 -0400 (EDT) Received: from fsnt.future.futsoft.com ([38.242.192.5]) by merit.edu (8.8.5/8.8.5) with ESMTP id EAA29247 for ; Tue, 8 Jul 1997 04:32:37 -0400 (EDT) Received: from kailash.future.futsoft.com (38.242.192.4) by fsnt.future.futsoft.com (Integralis SMTPRS 1.51) with ESMTP id ; Mon, 07 Jul 1997 14:06:31 +0530 Received: from msgate.future.futsoft.com (msgate.future.futsoft.com [10.0.8.4]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id NAA04709 for ; Tue, 8 Jul 1997 13:46:15 +0530 Received: by msgate.future.futsoft.com with Microsoft Mail id <33C2A98A@msgate.future.futsoft.com>; Tue, 08 Jul 97 13:56:42 PDT From: shenoyh To: PPPMailing-List Subject: RFC 1990 cud put the PPP negotiation into a loop !!! Date: Tue, 08 Jul 97 13:56:00 PDT Message-Id: <33C2A98A@msgate.future.futsoft.com> X-Mailer: Microsoft Mail V3.0 Sender: owner-ietf-ppp@merit.edu Hi, RFC 1990 cud put the PPP negotiation into a loop !!! Consider the following scenario : Two multi-link bundles exist between two peers - bundle b1 has the link e1 and bundle b2 has the link e2. (All are rfc 1990 compliant) ----- e1 ----- (x)b1 | |--------------------------| |b1 (x) | P1 | | P2 | (y)b2 | |--------------------------| |b2 (y) ----- e2 ----- Suppose seperate end-point discriminators x and y are negotiated on both the bundles b1 and b2 respectively. If, on the side of P1, if link e1 is taken out of bundle b1 and added to bundle b2, then a configure request will be sent on e1 with the End point descriminator value y. Now according to rfc 1990, P2 has to match this end-point descriminator with the bundle containing that value of End-point descriminator. So, y will match with b2's negotiated end-point descriminator and e1 will be added to b2. But even before that, a config-request with end-point descriminator value x will be sent on e1 ( from P2 to P1 ), since at the time of reception of the Config-request, e1 is still a part of b1. At P1, once again, the matching will take place and since x is the end point descriminator configured for b1, e1 will be added back to b1. The same process repeats again. So how is this deadlock solved ? Regards, Harischandra Shenoy R., Bala S.R. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 8 09:35:55 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id JAA01826; Tue, 8 Jul 1997 09:33:42 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 8 Jul 1997 09:29:31 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id JAA01760 for ietf-ppp-outgoing; Tue, 8 Jul 1997 09:29:30 -0400 (EDT) Received: from ftp.com (ftp.com [128.127.2.122]) by merit.edu (8.8.5/8.8.5) with SMTP id JAA01756 for ; Tue, 8 Jul 1997 09:29:25 -0400 (EDT) Received: from ftp.com by ftp.com ; Tue, 8 Jul 1997 09:28:55 -0400 Received: from mailserv-2high.ftp.com by ftp.com ; Tue, 8 Jul 1997 09:28:55 -0400 Received: from bray-2.ftp.com by MAILSERV-2HIGH.FTP.COM (SMI-8.6/SMI-SVR4) id JAA10698; Tue, 8 Jul 1997 09:24:55 -0400 Message-Id: <199707081324.JAA10698@MAILSERV-2HIGH.FTP.COM> X-Mapi-Messageclass: IPM To: shenoyh@future.futsoft.com, ietf-ppp@merit.edu X-Mailer: FTP Software Internet Mail 2.0 Mime-Version: 1.0 From: John Bray Subject: RE: RFC 1990 cud put the PPP negotiation into a loop !!! Date: Tue, 08 Jul 1997 09:28:54 -0400 Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu >>Reply to message from shenoyh (shenoyh@future.futsoft.com) dated 7/8/97 5:01 AM > > > Hi, > RFC 1990 cud put the PPP negotiation into a loop !!! > Consider the following scenario : > Two multi-link bundles exist between two peers - > bundle b1 has the > link > e1 and bundle b2 has the link e2. (All are rfc 1990 > compliant) Why would you want to do this? The purpose of multilink is to allow multiple links between two peers to be bundled together as a single virtual link. What you have described (multiple bundles between two peers) defeats the purpose. > > ----- e1 ----- > (x)b1 | |--------------------------| |b1 (x) > | P1 | | P2 | > (y)b2 | |--------------------------| |b2 (y) > ----- e2 ----- > > > Suppose seperate end-point discriminators x and y > are negotiated on > both > the bundles b1 and b2 respectively. The endpoint discriminator is intended to uniquely identify the two peers, not the bundle(s). A more accurate picture would be: ----- e1 ----- (EPD=x) | |--------------------------| | (EPD=y) | P1 | | P2 | (EPD=x) | |--------------------------| | (EPD=y) ----- e2 ----- Each side selects its own EPD (which is hopefully globally unique), and uses that EPD in its Configure-Requests on each link. When P1 sees a Configure-Request on e2 with an EPD (y) that matches the one it received on e1, it knows e2 is connected to the same peer (P2) and joins it to the bundle (unless there is an authentication mismatch). I suggest you carefully reread section 5.1.3, especially the very first sentence: "The Endpoint Discriminator Option represents identification of the *system* transmitting the packet." (emphasis mine). _________________________________________________ John Bray Senior Staff Engineer FTP Software, Inc. 2 High St. North Andover, MA 01845 E-mail: bray@ftp.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 8 09:44:43 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id JAA02035; Tue, 8 Jul 1997 09:44:41 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 8 Jul 1997 09:44:33 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id JAA02017 for ietf-ppp-outgoing; Tue, 8 Jul 1997 09:44:32 -0400 (EDT) Received: from directors.rdl.co.uk (directors.rdl.co.uk [193.119.77.2]) by merit.edu (8.8.5/8.8.5) with ESMTP id JAA02007 for ; Tue, 8 Jul 1997 09:44:21 -0400 (EDT) Received: from imaccgw.rdl.co.uk (imaccgw.rdl.co.uk [193.240.106.205]) by directors.rdl.co.uk (8.7.3/8.7.3) with SMTP id OAA05855; Tue, 8 Jul 1997 14:44:14 +0100 (BST) Received: from ccMail by imaccgw.rdl.co.uk (IMA Internet Exchange 1.04b) id 3c243e90; Tue, 8 Jul 97 14:43:05 +0100 Mime-Version: 1.0 Date: Tue, 8 Jul 1997 14:34:56 +0100 Message-ID: <3c243e90@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re: RFC 1990 cud put the PPP negotiation into a loop !!! To: ietf-ppp@merit.edu, shenoyh Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: owner-ietf-ppp@merit.edu Harischandra Shenoy writes: >Two multi-link bundles exist between two peers - bundle b1 has the >link e1 and bundle b2 has the link e2. (All are rfc 1990 compliant) > > ---- e1 ----- >(x)b1 | |--------------------------| |b1 (x) > | P1 | | P2 | >(y)b2 | |--------------------------| |b2 (y) > ---- e2 ----- > >Suppose seperate end-point discriminators x and y are negotiated on >both the bundles b1 and b2 respectively. I'm not quite sure how to put this tactfully, but it seems to me that you've completely misunderstood the use of end-point discriminators (which I'll refer to as "EPD" hereafter). Each peer has its own EPD, thus the diagram should be more like: ---- e1 ----- (x)b1 | |--------------------------| |b1 (u) | P1 | | P2 | (y)b2 | |--------------------------| |b2 (v) ---- e2 ----- (But even that is abnormal. Peers don't normally want to have 2 separate bundles to each other - if you want both links to be part of the same bundle then x==y and u==v. Much more typical is: ---- e1 ----- | |--------------------------| | (z) | P1 | | P2 | (w) | |--------------------------| | ---- e2 ----- with a single bundle linking to two peers, P1 has EPD z and P2 has EPD w.) But back to the rather obscure scenario you described... >On the side of P1, if link e1 is taken out of bundle b1 and added >to bundle b2, Actually, you can't add the link to bundle b2 until after LCP is renegotiated, so the sentence should read: if link e1 is taken out of bundle b1 with the intention of adding it to bundle b2... >then a configure request will be sent on e1 with the >End point descriminator value y. >Now according to rfc 1990, P2 has to match this end-point >descriminator with the bundle containing that value of End-point >descriminator. There is no such requirement. When sending a configure request, P2 uses its own EPD (u or v). Once LCP negotiation is complete, it compares the peer's EPD for the new link with the peer's EPD already negotiated on the bundle - if they don't match then the link can't be added to the bundle. >So, y will match with b2's negotiated end-point descriminator and e1 >will be added to b2. Only if u==v. >But even before that, a config-request with end-point descriminator >value x will be sent on e1 ( from P2 to P1 ), since at the time of >reception of the Config-request, e1 is still a part of b1. Sorry, this is completely wrong. If P2 is clever enough to realise that P1 wishes to add both links to bundle b2, then it would send EPD v instead of u in its Configure-Request (after all, it has already received the Configure-Request from P1). Of course, normally P2 would always use end-point discriminator (u) on link e1. If u==v, then the link is added to bundle b2. If u|=v, then it isn't. >At P1, once again, the matching will take place and since x is the end >point descriminator configured for b1, e1 will be added back to b1. >The same process repeats again. No it doesn't. If you have a schizophrenic device which is sometimes two end-points and sometimes only a single end-point, then both the local and remote EPDs must match for a link to be added to an existing bundle. >So how is this deadlock solved ? It doesn't need to be because it never happens. --- Jonathan Goodchild Racal-Datacom - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 8 12:52:36 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id MAA05356; Tue, 8 Jul 1997 12:52:27 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 8 Jul 1997 12:51:22 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id MAA05295 for ietf-ppp-outgoing; Tue, 8 Jul 1997 12:51:21 -0400 (EDT) Received: from dub-img-4.compuserve.com (dub-img-4.compuserve.com [149.174.206.134]) by merit.edu (8.8.5/8.8.5) with ESMTP id MAA05291 for ; Tue, 8 Jul 1997 12:51:14 -0400 (EDT) Received: (from mailgate@localhost) by dub-img-4.compuserve.com (8.8.6/8.8.6/2.1) id MAA26334; Tue, 8 Jul 1997 12:50:42 -0400 (EDT) Date: Tue, 8 Jul 1997 12:50:22 -0400 From: Tom Coradetti <70761.1664@compuserve.com> Subject: RFC 1990 cud put the PPP negotiation into a loop !!! To: shenoyh Cc: ppp Message-ID: <199707081250_MC2-1A6F-A814@compuserve.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by merit.edu id MAA05292 Sender: owner-ietf-ppp@merit.edu > >Hi, > RFC 1990 cud (could) put the PPP negotiation into a loop !!! Not! > Consider the following scenario : > Two multi-link bundles exist between two peers - bundle b1 has the >link >e1 and bundle b2 has the link e2. (All are rfc 1990 compliant) > > ----- e1 ----- >(x1)b1 | |--------------------------| |b1 (x2) > | P1 | | P2 | >(y1)b2 | |--------------------------| |b2 (y2) > ----- e2 ----- > > > Suppose seperate end-point discriminators x and y are negotiated on >both the bundles b1 and b2 respectively. Endpoint Discriminators are not negotiated. Each side of each link transmits its internally defined and unchangeable discriminator. I have relabeled x and y from your original diagram to x1, y1, x2, and y2 to reflect the independence of these four nominally unique identifiers. Further, at each device P1 and P2, the endpoint discriminator is conventionally associated with the device, P1 or P2, not links within the device. In the conventional case x1=y1 and x2=y2. If either or both of these devices has chosen to deviate from convention, and offer x != y on different links, it has gone beyond RFC 1990. If either P1 or P2 do not consistently offer the same discriminator on every link, you will have to explain why. In RFC 1990 terms you either have 2 devices ( P1 and P2 ), 3 devices (P1-x1, P1-y1, and P2; or P1, P2-x2, P2-y2), or 4 devices (P1-x1, P1-y1, P2-x2, P2-y2). With those static configurations, if you split either P1 or P2 from a two link device into two one link devices, the discriminators associate with the devices, not the links. Once you split one of the sides, you can't have any more two link bundles. Your example shows both sides split, so there are effectively 4 devices, and two bundles with one link each are possible, as shown. >If, on the side of P1, if link e1 is taken >out of bundle b1 and added to bundle b2, You will have to explain why. You have just merged two devices into one at P1. If P1 does that it is blatantly violating RFC 1990 and is broken. Since P1 can see that x2 != y2 (by your definition, not by convention), RFC 1990 forbids P1 from assingning both links to the same bundle. If P1 'takes out' e1 from a bundle, it can't add e1 to any bundle until it has received a config request from P2 containing x2 or y2. >then a configure request will be >sent on e1 with the End point descriminator value y. P1 will send x1 or y1, P2 will send x2 or y2. If P1 suddenly decides to start sending y1 on e1, when it had previously been sending x1, P1 must have some non-1990 reason for doing so, and better have a non-1990 way of expressing that to P2, which P2 will understand. >Now according to rfc 1990, P2 >has to match this end-point descriminator with the bundle containing that >value of End-point descriminator. Actually, P2 does NOT have to match any link with an existing bundle. Only the converse is true. P2 MUST NOT match a link with an existing bundle if the remotely offered discriminators do NOT match. >So, y (y1, from P1) will match with b2's negotiated end-point >descriminator and e1 will be added to b2. If P2 sees an incoming config request containing y1, it must remove e1 from all bundles until LCP finishes again, so it can't add e1 to any bundle yet. It can chose to send x2 or y2 on link e1 (you have not explained why it using two discriminators yet). >But even before that, a config-request with end-point descriminator >value x (x2, from P2) will >be sent on e1 ( from P2 to P1 ), since at the time of reception of the >Config-request, e1 is still a part of b1. From P2's perspective, e1 stops being part of b1 or b2 the instant it gets the config request. If a link is exchanging LCP config requests, it is not part of any bundle. > At P1, once again, the matching will take place and since x is the end >point >descriminator configured for b1, e1 will be added back to b1. If P2 choses to continue to send x2, P1 MUST NOT add e1 to b2 since it is getting y2 in on link e2. >The same process repeats again. By that I assume you mean that P1 repeatedly choses IN VIOLATION OF RFC 1990, to associate e1 with bundle b2, even though it keeps getting different discriminators in from P2 on each link. > > So how is this deadlock solved ? > Turn off P1. It is broken. If statically, P1 wants to always send y1 on both links, and P2 always wants to send x2 on e1 and y2 on e2, then you have three RFC 1990 devices. P1 should never allow e1 and e2 into the same bundle. P1 must eventually terminate one of the links, since neither of the devices at P2 will see any problem. This is the very 3 legged problem discriminators are meant to detect. If either P1 or P2 want to send different discrimators on the same link at different times, they are not RFC 1990 devices. They can still do that only if they have a mutually understood mechanism for sorting it out, but RFC 1990 alone will not be enough. >Regards, >Harischandra Shenoy R., >Bala S.R. > > > -------------------------------------------------------- Tom Coradetti Sidewalk Software Phone: (612) 490 7856 1190 Josephine Road Email: 70761.1664@compuserve.com Roseville, MN 55113 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 8 13:14:35 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id NAA05856; Tue, 8 Jul 1997 13:14:33 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 8 Jul 1997 13:14:12 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id NAA05826 for ietf-ppp-outgoing; Tue, 8 Jul 1997 13:14:11 -0400 (EDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.29]) by merit.edu (8.8.5/8.8.5) with ESMTP id NAA05819 for ; Tue, 8 Jul 1997 13:14:05 -0400 (EDT) Received: by mail4.microsoft.com with Internet Mail Service (5.0.1458.49) id <33W00XZV>; Tue, 8 Jul 1997 10:14:04 -0700 Message-ID: <114DB67712DCD011A63500805F385DB20E5B6C@RED-38-MSG.dns.microsoft.com> From: Paul Martin To: ietf-ppp@merit.edu Subject: draft-rfced-info-martin-00.txt Date: Tue, 8 Jul 1997 10:13:36 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Sender: owner-ietf-ppp@merit.edu I am looking for comments on the above proposed informational RFC. Bear in mind that this RFC is NOT intended for the large number of PC users in the home. It is intended for the Consumer Electronics Market where memory and processing speed is very limited. Any and all comments are welcome. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 8 14:19:17 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id OAA07130; Tue, 8 Jul 1997 14:19:09 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 8 Jul 1997 14:18:40 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id OAA07108 for ietf-ppp-outgoing; Tue, 8 Jul 1997 14:18:39 -0400 (EDT) Received: from tor.securecomputing.com (tor.securecomputing.com [199.71.190.98]) by merit.edu (8.8.5/8.8.5) with ESMTP id OAA07104 for ; Tue, 8 Jul 1997 14:18:35 -0400 (EDT) Received: by janus.tor.securecomputing.com id <11650>; Tue, 8 Jul 1997 14:12:43 -0400 Message-Id: <97Jul8.141243edt.11650@janus.tor.securecomputing.com> To: Paul Martin cc: ietf-ppp@merit.edu Subject: Re: draft-rfced-info-martin-00.txt References: <114DB67712DCD011A63500805F385DB20E5B6C@RED-38-MSG.dns.microsoft.com> In-reply-to: Your message of "Tue, 08 Jul 1997 13:13:36 -0400". <114DB67712DCD011A63500805F385DB20E5B6C@RED-38-MSG.dns.microsoft.com> From: "C. Harald Koch" Date: Tue, 8 Jul 1997 14:17:57 -0400 Sender: owner-ietf-ppp@merit.edu In message <114DB67712DCD011A63500805F385DB20E5B6C@RED-38-MSG.dns.microsoft.com>, Paul Martin writes: > I am looking for comments on the above proposed informational RFC. > > Bear in mind that this RFC is NOT intended for the large number of PC > users in the home. It is intended for the Consumer Electronics Market > where memory and processing speed is very limited. I've already commented once, but I'll ask anyway: Why are these products even running PPP, if they're so memory/processor limited? It still sounds to me like you have a solution looking for a problem. -- Harald - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 8 14:26:38 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id OAA07286; Tue, 8 Jul 1997 14:26:36 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 8 Jul 1997 14:26:23 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id OAA07265 for ietf-ppp-outgoing; Tue, 8 Jul 1997 14:26:23 -0400 (EDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.29]) by merit.edu (8.8.5/8.8.5) with ESMTP id OAA07257 for ; Tue, 8 Jul 1997 14:26:18 -0400 (EDT) Received: by mail4.microsoft.com with Internet Mail Service (5.0.1458.49) id <33W007L8>; Tue, 8 Jul 1997 11:26:42 -0700 Message-ID: <114DB67712DCD011A63500805F385DB20E5B70@RED-38-MSG.dns.microsoft.com> From: Paul Martin To: "'C. Harald Koch'" Cc: ietf-ppp@merit.edu Subject: RE: draft-rfced-info-martin-00.txt Date: Tue, 8 Jul 1997 11:24:46 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Sender: owner-ietf-ppp@merit.edu -----Original Message----- From: C. Harald Koch [SMTP:chk@tor.securecomputing.com] Sent: Tuesday, July 08, 1997 11:18 AM To: Paul Martin Cc: ietf-ppp@merit.edu Subject: Re: draft-rfced-info-martin-00.txt In message <114DB67712DCD011A63500805F385DB20E5B6C@RED-38-MSG.dns.microsoft.com>, Paul Martin writes: > I am looking for comments on the above proposed informational RFC. > > Bear in mind that this RFC is NOT intended for the large number of PC > users in the home. It is intended for the Consumer Electronics Market > where memory and processing speed is very limited. I've already commented once, but I'll ask anyway: Why are these products even running PPP, if they're so memory/processor limited? Web Surfing, and email to name a couple of things. It still sounds to me like you have a solution looking for a problem. -- Harald - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 8 15:00:31 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id PAA07967; Tue, 8 Jul 1997 15:00:30 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 8 Jul 1997 15:00:07 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id PAA07938 for ietf-ppp-outgoing; Tue, 8 Jul 1997 15:00:06 -0400 (EDT) Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.8.5/8.8.5) with SMTP id OAA07934 for ; Tue, 8 Jul 1997 14:59:57 -0400 (EDT) Received: from mica.denver.sgi.com (mica.denver.sgi.com [169.238.67.6]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id LAA08268 for <@sgi.engr.sgi.com:ietf-ppp@merit.edu>; Tue, 8 Jul 1997 11:59:49 -0700 env-from (vjs@mica.denver.sgi.com) Received: (from vjs@localhost) by mica.denver.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA01618 for ietf-ppp@merit.edu; Tue, 8 Jul 1997 12:58:44 -0600 Date: Tue, 8 Jul 1997 12:58:44 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199707081858.MAA01618@mica.denver.sgi.com> To: ietf-ppp@merit.edu Subject: RE: draft-rfced-info-martin-00.txt Sender: owner-ietf-ppp@merit.edu Why are these products even running PPP, if they're so memory/processor limited? Web Surfing, and email to name a couple of things. What does "Web Surfing" have to do with PPP? As I keep saying, most people now using PPP to talk to big Internet Service Providers would be better served by some kind of smart terminal protocol instead of a peer-to-peer link-layer network protocol. Such a terminal protocol would cost the terminals far less (whether Personal Computers or "NC's") and would perform better than PPP. A specialized protocol could compress "web surfing" data far better than PPP. It is silly to allocate IP addresses, deal with IP headers, and so forth and so on when one of the machines does less file transfering that people used to do with Kermit. The only reason PPP is so popular is that PPP is so popular. People simple do not (or cannot) think about their actual goals. Why? Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 8 15:16:26 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id PAA08387; Tue, 8 Jul 1997 15:16:25 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 8 Jul 1997 15:16:07 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id PAA08363 for ietf-ppp-outgoing; Tue, 8 Jul 1997 15:16:06 -0400 (EDT) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by merit.edu (8.8.5/8.8.5) with SMTP id PAA08359 for ; Tue, 8 Jul 1997 15:16:01 -0400 (EDT) Received: from spud.ascend.com (fw-ext.ascend.com [198.4.92.5]) by drawbridge.ascend.com (8.6.12/8.6.12) with ESMTP id MAA08483; Tue, 8 Jul 1997 12:15:53 -0700 Received: from ascend.com by ascend.com with ESMTP id MAA24601; Tue, 8 Jul 1997 12:15:49 -0700 Received: from gump.eng.ascend.com (gump.eng.ascend.com [206.65.212.67]) by wopr.eng.ascend.com (8.6.12/8.6.12) with ESMTP id MAA19093; Tue, 8 Jul 1997 12:15:18 -0700 Received: from carp.morningstar.com.ascend.com (karl@carp.MorningStar.Com [137.175.81.4]) by gump.eng.ascend.com (8.6.12/8.6.12) with SMTP id MAA17078; Tue, 8 Jul 1997 12:15:16 -0700 Date: Tue, 8 Jul 1997 12:15:16 -0700 Message-Id: <199707081915.MAA17078@gump.eng.ascend.com> From: Karl Fox To: Paul Martin Cc: ietf-ppp@merit.edu Subject: draft-rfced-info-martin-00.txt In-Reply-To: <114DB67712DCD011A63500805F385DB20E5B6C@RED-38-MSG.dns.microsoft.com> References: <114DB67712DCD011A63500805F385DB20E5B6C@RED-38-MSG.dns.microsoft.com> Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ietf-ppp@merit.edu Paul Martin writes: > I am looking for comments on the above proposed informational RFC. > > Bear in mind that this RFC is NOT intended for the large number of PC > users in the home. It is intended for the Consumer Electronics Market > where memory and processing speed is very limited. > > Any and all comments are welcome. Would you care to respond to the comments that were brought up earlier? In particular, can't you simply align your receive buffers so that the appropriate fields are aligned as you wish? -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 8 15:25:48 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id PAA08598; Tue, 8 Jul 1997 15:25:41 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 8 Jul 1997 15:25:09 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id PAA08571 for ietf-ppp-outgoing; Tue, 8 Jul 1997 15:25:08 -0400 (EDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.42]) by merit.edu (8.8.5/8.8.5) with ESMTP id PAA08566 for ; Tue, 8 Jul 1997 15:24:57 -0400 (EDT) Received: by INET-02-IMC with Internet Mail Service (5.0.1458.49) id <3P2VK69H>; Tue, 8 Jul 1997 12:24:58 -0700 Message-ID: <114DB67712DCD011A63500805F385DB20E5B72@RED-38-MSG.dns.microsoft.com> From: Paul Martin To: "'Karl Fox'" Cc: ietf-ppp@merit.edu Subject: RE: draft-rfced-info-martin-00.txt Date: Tue, 8 Jul 1997 12:24:26 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Sender: owner-ietf-ppp@merit.edu -----Original Message----- From: Karl Fox [SMTP:karl@ascend.com] Sent: Tuesday, July 08, 1997 12:15 PM To: Paul Martin Cc: ietf-ppp@merit.edu Subject: draft-rfced-info-martin-00.txt Paul Martin writes: > I am looking for comments on the above proposed informational RFC. > > Bear in mind that this RFC is NOT intended for the large number of PC > users in the home. It is intended for the Consumer Electronics Market > where memory and processing speed is very limited. > > Any and all comments are welcome. Would you care to respond to the comments that were brought up earlier? In particular, can't you simply align your receive buffers so that the appropriate fields are aligned as you wish? This is the response I sent Harald. >> BEGIN OF INSERTION <<< I agree the just for protocol and address/control field compression, this is not needed as the fields are fixed in length. However, VJ compressed headers are variable (either 3 or 5 octets). So one must parse the header while the data is coming in, internally pad the frame, then copy the VJ compressed header so it can be run through the decompression phase. Bare in mind, routers have two things that are not in common with Consumer Electronics devices. A fast processor, and lots of ram/rom. The asynchronous byte unstuffing is more than enough to load small processors, without the extra burden of parsing the VJ header to align the frame. Also Consumer Electronics devices do NOT use a dedicated processor for the communications as this drives up the cost, so the processor, along with PPP my be running several other time critical applications. Think of being able to retrieve email with your answering machine. The DSP is normally very busy with encoding and decoding voice. So we are faced with three choices, 1) Have a state machine just to parse and realign the frame after receiving it The states being: a) Protocol field compression on/off b) Address/control field compression on/off c) VJ compressed TCP header being 3 or 5 bytes (Giving us eight possibilities without looking at uncompressed TCP or IP frames) 2) Copy the frame twice (once for asynchronous byte stuffing and the other for alignment) 3) Pad the frame by a few bytes. I would opt for less code/processing over three extra bytes in the datagram. Look at the modem speeds today as compared to when Van Jacobson wrote RFC1144. I am also looking to the future with cable modems and satellite boxes receiving PPP frames. The forward channel in coming in on satellite at 56mbits/sec with the back-channel being just 14.4kbits/sec. The receiver must process the frames VERY quickly. As you can see from the above scenario, the extra processing is a very big hit. I am not saying that one must always pad, but I would like to have the option for special cases. Thank you for your comments. I am of course open to suggestions that show how to accomplish the same thing in code without a performance impact. >> END OF INSERTION <<< -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 8 15:39:02 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id PAA08944; Tue, 8 Jul 1997 15:39:01 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 8 Jul 1997 15:38:48 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id PAA08923 for ietf-ppp-outgoing; Tue, 8 Jul 1997 15:38:47 -0400 (EDT) Received: from ns.frigate.com (ns.frigate.com [206.14.208.6]) by merit.edu (8.8.5/8.8.5) with ESMTP id PAA08917 for ; Tue, 8 Jul 1997 15:38:41 -0400 (EDT) Received: from localhost (mthorn@localhost) by ns.frigate.com (8.8.5/8.7.1) with SMTP id MAA07498; Tue, 8 Jul 1997 12:39:02 -0700 (PDT) Date: Tue, 8 Jul 1997 12:39:02 -0700 (PDT) From: Mike Thornburg To: Paul Martin cc: ietf-ppp@merit.edu Subject: Re: draft-rfced-info-martin-00.txt In-Reply-To: <114DB67712DCD011A63500805F385DB20E5B6C@RED-38-MSG.dns.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu On Tue, 8 Jul 1997, Paul Martin wrote: > > I am looking for comments on the above proposed informational RFC. > > Bear in mind that this RFC is NOT intended for the large number of PC > users in the home. It is intended for the Consumer Electronics Market > where memory and processing speed is very limited. > > Any and all comments are welcome. > First, for 16-bit and 32-bit alignment, you can refuse one or both of protocol field compression and address and control field compression and achieve the exact same thing you are trying to do here with these extra bytes of padding. You may have to refuse VJ header compression as well, but leaving VJ compression out of your implementation will make the code size smaller, will use up less RAM for data structures, will save processing time, and will result in no significant perceived slowdown of the link at the sort of speeds modems are capable of today. Where is the necessity for this IPCP word alignment option? Thanks, Mike -------------- Mike Thornburg frigate networks 415.903.2266 mthorn@frigate.com http://www.frigate.com/ - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 8 15:59:47 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id PAA09344; Tue, 8 Jul 1997 15:59:46 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 8 Jul 1997 15:59:28 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id PAA09322 for ietf-ppp-outgoing; Tue, 8 Jul 1997 15:59:28 -0400 (EDT) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by merit.edu (8.8.5/8.8.5) with SMTP id PAA09318 for ; Tue, 8 Jul 1997 15:59:22 -0400 (EDT) Received: from spud.ascend.com (fw-ext.ascend.com [198.4.92.5]) by drawbridge.ascend.com (8.6.12/8.6.12) with ESMTP id MAA10589; Tue, 8 Jul 1997 12:59:14 -0700 Received: from ascend.com by ascend.com with ESMTP id MAA27497; Tue, 8 Jul 1997 12:59:12 -0700 Received: from gump.eng.ascend.com (gump.eng.ascend.com [206.65.212.67]) by wopr.eng.ascend.com (8.6.12/8.6.12) with ESMTP id MAA22181; Tue, 8 Jul 1997 12:58:41 -0700 Received: from carp.morningstar.com.ascend.com (karl@carp.MorningStar.Com [137.175.81.4]) by gump.eng.ascend.com (8.6.12/8.6.12) with SMTP id MAA17240; Tue, 8 Jul 1997 12:58:39 -0700 Date: Tue, 8 Jul 1997 12:58:39 -0700 Message-Id: <199707081958.MAA17240@gump.eng.ascend.com> From: Karl Fox To: Paul Martin Cc: "'Karl Fox'" , ietf-ppp@merit.edu Subject: RE: draft-rfced-info-martin-00.txt In-Reply-To: <114DB67712DCD011A63500805F385DB20E5B72@RED-38-MSG.dns.microsoft.com> References: <114DB67712DCD011A63500805F385DB20E5B72@RED-38-MSG.dns.microsoft.com> Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ietf-ppp@merit.edu First off, parsing the pfc and acfc in real time is trivial if you are already pulling the bytes out of the receiver one-by-one, avoiding one of the copies you mentioned and leaving VJ as the only real issue worth considering. It seems to me that uncompressing a VJ-compressed TCP packet is much more complex than you imply. How do you figure 3- or 5-byte headers every time? What about all the different change bits in the first octet of the compressed packet? I don't see how you can avoid either doing one post-VJ copy or doing all or part of the VJ-uncompress at character-suck time. You know, I'll bet a smart programmer could come up with a really slick state-machine-driven VJ-uncompressor that would 1) operate with very low overhead in your character-at-a-time environment, 2) use no more total CPU than you'd use with your proposed scheme, 3) avoid the wasted pad bytes on the wire, and 4) maintain compatibility with the rest of the world. -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 8 16:13:31 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id QAA09677; Tue, 8 Jul 1997 16:13:26 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 8 Jul 1997 16:13:14 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id QAA09654 for ietf-ppp-outgoing; Tue, 8 Jul 1997 16:13:13 -0400 (EDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.42]) by merit.edu (8.8.5/8.8.5) with ESMTP id QAA09644 for ; Tue, 8 Jul 1997 16:13:07 -0400 (EDT) Received: by INET-02-IMC with Internet Mail Service (5.0.1458.49) id <3P2VK9NB>; Tue, 8 Jul 1997 13:13:00 -0700 Message-ID: <114DB67712DCD011A63500805F385DB20E5B75@RED-38-MSG.dns.microsoft.com> From: Paul Martin To: "'Karl Fox'" Cc: ietf-ppp@merit.edu Subject: RE: draft-rfced-info-martin-00.txt Date: Tue, 8 Jul 1997 13:12:49 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Sender: owner-ietf-ppp@merit.edu -----Original Message----- From: Karl Fox [SMTP:karl@ascend.com] Sent: Tuesday, July 08, 1997 12:59 PM To: Paul Martin Cc: 'Karl Fox'; ietf-ppp@merit.edu Subject: RE: draft-rfced-info-martin-00.txt First off, parsing the pfc and acfc in real time is trivial if you are already pulling the bytes out of the receiver one-by-one, avoiding one of the copies you mentioned and leaving VJ as the only real issue worth considering. Yes I agree. I put it in as a simple example. It seems to me that uncompressing a VJ-compressed TCP packet is much more complex than you imply. How do you figure 3- or 5-byte headers every time? What about all the different change bits in the first octet of the compressed packet? I don't see how you can avoid either doing one post-VJ copy or doing all or part of the VJ-uncompress at character-suck time. I agree, it is much more complex. The pad character eliminates the post VJ copy. You know, I'll bet a smart programmer could come up with a really slick state-machine-driven VJ-uncompressor that would 1) operate with very low overhead in your character-at-a-time environment, 2) use no more total CPU than you'd use with your proposed scheme, 3) avoid the wasted pad bytes on the wire, and 4) maintain compatibility with the rest of the world. Are you that slick/smart programmer? I have written PPP for embedded systems from scratch (Not steal it from the public domain), and I don't see a way without adding a bunch of code and processing But hey, maybe I am not that smart. -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 8 16:07:49 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id QAA09530; Tue, 8 Jul 1997 16:07:47 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 8 Jul 1997 16:07:34 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id QAA09512 for ietf-ppp-outgoing; Tue, 8 Jul 1997 16:07:33 -0400 (EDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.42]) by merit.edu (8.8.5/8.8.5) with ESMTP id QAA09508 for ; Tue, 8 Jul 1997 16:07:28 -0400 (EDT) Received: by INET-02-IMC with Internet Mail Service (5.0.1458.49) id <3P2VK9CP>; Tue, 8 Jul 1997 13:07:29 -0700 Message-ID: <114DB67712DCD011A63500805F385DB20E5B74@RED-38-MSG.dns.microsoft.com> From: Paul Martin To: ietf-ppp@merit.edu Subject: Re: draft-rfced-info-martin-00.txt Date: Tue, 8 Jul 1997 13:07:25 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Sender: owner-ietf-ppp@merit.edu Yes, very interesting, and I thought of that. However, the perception by the OEM's who put PPP into their box is that they need these compression techniques. By adding the simple pad character we can still get most of the benefit of VJ compression and be compatible with a wider range of PPP implementations. You would be amazed of how many ISP's will simply reject the connection entirely because it does not support VJ compression. It is easy to make an argument against anything. For example: "What do we need PPP for, SLIP is smaller, faster, and works just fine!". Remember that one? What I am looking for is constructive comments. I would also like to hear from people who have implemented PPP in the Consumer Electronics industry. -----Original Message----- From: Mike Thornburg [SMTP:mthorn@frigate.com] Sent: Tuesday, July 08, 1997 12:39 PM To: Paul Martin Cc: ietf-ppp@merit.edu Subject: Re: draft-rfced-info-martin-00.txt On Tue, 8 Jul 1997, Paul Martin wrote: > > I am looking for comments on the above proposed informational RFC. > > Bear in mind that this RFC is NOT intended for the large number of PC > users in the home. It is intended for the Consumer Electronics Market > where memory and processing speed is very limited. > > Any and all comments are welcome. > First, for 16-bit and 32-bit alignment, you can refuse one or both of protocol field compression and address and control field compression and achieve the exact same thing you are trying to do here with these extra bytes of padding. You may have to refuse VJ header compression as well, but leaving VJ compression out of your implementation will make the code size smaller, will use up less RAM for data structures, will save processing time, and will result in no significant perceived slowdown of the link at the sort of speeds modems are capable of today. Where is the necessity for this IPCP word alignment option? Thanks, Mike -------------- Mike Thornburg frigate networks 415.903.2266 mthorn@frigate.com http://www.frigate.com/ - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 8 16:24:37 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id QAA09972; Tue, 8 Jul 1997 16:24:30 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 8 Jul 1997 16:24:13 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id QAA09945 for ietf-ppp-outgoing; Tue, 8 Jul 1997 16:24:13 -0400 (EDT) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by merit.edu (8.8.5/8.8.5) with SMTP id QAA09940 for ; Tue, 8 Jul 1997 16:24:07 -0400 (EDT) Received: from spud.ascend.com (fw-ext.ascend.com [198.4.92.5]) by drawbridge.ascend.com (8.6.12/8.6.12) with ESMTP id NAA12194; Tue, 8 Jul 1997 13:23:59 -0700 Received: from ascend.com by ascend.com with ESMTP id NAA29551; Tue, 8 Jul 1997 13:23:58 -0700 Received: from gump.eng.ascend.com (gump.eng.ascend.com [206.65.212.67]) by wopr.eng.ascend.com (8.6.12/8.6.12) with ESMTP id NAA24414; Tue, 8 Jul 1997 13:23:27 -0700 Received: from carp.morningstar.com.ascend.com (karl@carp.MorningStar.Com [137.175.81.4]) by gump.eng.ascend.com (8.6.12/8.6.12) with SMTP id NAA17432; Tue, 8 Jul 1997 13:23:25 -0700 Date: Tue, 8 Jul 1997 13:23:25 -0700 Message-Id: <199707082023.NAA17432@gump.eng.ascend.com> From: Karl Fox To: Paul Martin Cc: "'Karl Fox'" , ietf-ppp@merit.edu Subject: RE: draft-rfced-info-martin-00.txt In-Reply-To: <114DB67712DCD011A63500805F385DB20E5B75@RED-38-MSG.dns.microsoft.com> References: <114DB67712DCD011A63500805F385DB20E5B75@RED-38-MSG.dns.microsoft.com> Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ietf-ppp@merit.edu I wrote: > You know, I'll bet a smart programmer could come up with a really > slick state-machine-driven VJ-uncompressor that would 1) operate > with very low overhead in your character-at-a-time environment, 2) > use no more total CPU than you'd use with your proposed scheme, 3) > avoid the wasted pad bytes on the wire, and 4) maintain > compatibility with the rest of the world. Paul Martin replied: > Are you that slick/smart programmer? I have written PPP for > embedded systems from scratch (Not steal it from the public domain), and > I don't see a way without adding a bunch of code and processing But > hey, maybe I am not that smart. I apologize if you thought I intended to insult you; I assure you that was not my goal. Neither am I looking for a job, but yes, I have also written PPP for embedded systems from scratch, at least the parts we're talking about here. I know of at least half a dozen people on this mailing list who could fairly easily do the job I described in the first paragraph above. -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 8 16:53:40 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id QAA10677; Tue, 8 Jul 1997 16:53:39 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 8 Jul 1997 16:53:30 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id QAA10659 for ietf-ppp-outgoing; Tue, 8 Jul 1997 16:53:30 -0400 (EDT) Received: from tor.securecomputing.com (border.com [199.71.190.98]) by merit.edu (8.8.5/8.8.5) with ESMTP id QAA10652 for ; Tue, 8 Jul 1997 16:53:22 -0400 (EDT) Received: by janus.tor.securecomputing.com id <11650>; Tue, 8 Jul 1997 16:47:41 -0400 Message-Id: <97Jul8.164741edt.11650@janus.tor.securecomputing.com> To: Paul Martin cc: ietf-ppp@merit.edu Subject: Re: draft-rfced-info-martin-00.txt References: <114DB67712DCD011A63500805F385DB20E5B74@RED-38-MSG.dns.microsoft.com> In-reply-to: Your message of "Tue, 08 Jul 1997 16:07:25 -0400". <114DB67712DCD011A63500805F385DB20E5B74@RED-38-MSG.dns.microsoft.com> From: "C. Harald Koch" Date: Tue, 8 Jul 1997 16:52:56 -0400 Sender: owner-ietf-ppp@merit.edu In message <114DB67712DCD011A63500805F385DB20E5B74@RED-38-MSG.dns.microsoft.com>, Paul Martin writes: > Yes, very interesting, and I thought of that. However, the perception > by the OEM's who put PPP into their box is that they need these > compression techniques. By adding the simple pad character we can still > get most of the benefit of VJ compression and be compatible with a wider > range of PPP implementations. Only once everyone implements it. To echo a comment I just made over in L2TP: By the time you get this protocol defined, accepted, and most importantly *deployed*, it will no longer be necessary; hardware will have advanced to the point where the problem no longer exists. -- Harald - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 8 16:50:43 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id QAA10586; Tue, 8 Jul 1997 16:50:36 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 8 Jul 1997 16:49:41 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id QAA10557 for ietf-ppp-outgoing; Tue, 8 Jul 1997 16:49:40 -0400 (EDT) Received: from tor.securecomputing.com (border.com [199.71.190.98]) by merit.edu (8.8.5/8.8.5) with ESMTP id QAA10547 for ; Tue, 8 Jul 1997 16:49:29 -0400 (EDT) Received: by janus.tor.securecomputing.com id <11649>; Tue, 8 Jul 1997 16:43:56 -0400 Message-Id: <97Jul8.164356edt.11649@janus.tor.securecomputing.com> To: Paul Martin cc: ietf-ppp@merit.edu Subject: Re: draft-rfced-info-martin-00.txt References: <114DB67712DCD011A63500805F385DB20E5B74@RED-38-MSG.dns.microsoft.com> In-reply-to: Your message of "Tue, 08 Jul 1997 16:07:25 -0400". <114DB67712DCD011A63500805F385DB20E5B74@RED-38-MSG.dns.microsoft.com> From: "C. Harald Koch" Date: Tue, 8 Jul 1997 16:49:11 -0400 Sender: owner-ietf-ppp@merit.edu > I would also like to hear from people who have implemented PPP in the > Consumer Electronics industry. US Robotics' Palm Computing Division has a couple of products that do PPP, TCP/IP and e-mail on a $300 hand-held computer. Does that qualify as "Consumer Electronics"? -- Harald - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 8 17:14:27 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id RAA11136; Tue, 8 Jul 1997 17:14:24 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 8 Jul 1997 17:14:14 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id RAA11118 for ietf-ppp-outgoing; Tue, 8 Jul 1997 17:14:14 -0400 (EDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.29]) by merit.edu (8.8.5/8.8.5) with ESMTP id RAA11114 for ; Tue, 8 Jul 1997 17:14:10 -0400 (EDT) Received: by mail4.microsoft.com with Internet Mail Service (5.0.1458.49) id <33XAAF1J>; Tue, 8 Jul 1997 14:14:31 -0700 Message-ID: <114DB67712DCD011A63500805F385DB20E5B76@RED-38-MSG.dns.microsoft.com> From: Paul Martin To: "'C. Harald Koch'" , Paul Martin Cc: ietf-ppp@merit.edu Subject: RE: draft-rfced-info-martin-00.txt Date: Tue, 8 Jul 1997 14:14:02 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Sender: owner-ietf-ppp@merit.edu -----Original Message----- From: C. Harald Koch [SMTP:chk@utcc.utoronto.ca] Sent: Tuesday, July 08, 1997 1:49 PM To: Paul Martin Cc: ietf-ppp@merit.edu Subject: Re: draft-rfced-info-martin-00.txt > I would also like to hear from people who have implemented PPP in the > Consumer Electronics industry. US Robotics' Palm Computing Division has a couple of products that do PPP, TCP/IP and e-mail on a $300 hand-held computer. Does that qualify as "Consumer Electronics"? High end consumer electronics. -- Harald - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 8 17:21:04 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id RAA11300; Tue, 8 Jul 1997 17:21:03 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 8 Jul 1997 17:20:54 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id RAA11274 for ietf-ppp-outgoing; Tue, 8 Jul 1997 17:20:53 -0400 (EDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.31]) by merit.edu (8.8.5/8.8.5) with ESMTP id RAA11269 for ; Tue, 8 Jul 1997 17:20:47 -0400 (EDT) Received: by mail5.microsoft.com with Internet Mail Service (5.0.1458.49) id <3RBKCKKH>; Tue, 8 Jul 1997 14:22:34 -0700 Message-ID: <114DB67712DCD011A63500805F385DB20E5B78@RED-38-MSG.dns.microsoft.com> From: Paul Martin To: "'Karl Fox'" Cc: ietf-ppp@merit.edu Subject: RE: draft-rfced-info-martin-00.txt Date: Tue, 8 Jul 1997 14:20:43 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Sender: owner-ietf-ppp@merit.edu -----Original Message----- From: Karl Fox [SMTP:karl@ascend.com] Sent: Tuesday, July 08, 1997 1:23 PM To: Paul Martin Cc: 'Karl Fox'; ietf-ppp@merit.edu Subject: RE: draft-rfced-info-martin-00.txt I wrote: > You know, I'll bet a smart programmer could come up with a really > slick state-machine-driven VJ-uncompressor that would 1) operate > with very low overhead in your character-at-a-time environment, 2) > use no more total CPU than you'd use with your proposed scheme, 3) > avoid the wasted pad bytes on the wire, and 4) maintain > compatibility with the rest of the world. Paul Martin replied: > Are you that slick/smart programmer? I have written PPP for > embedded systems from scratch (Not steal it from the public domain), and > I don't see a way without adding a bunch of code and processing But > hey, maybe I am not that smart. I apologize if you thought I intended to insult you; I assure you that was not my goal. Neither am I looking for a job, but yes, I have also written PPP for embedded systems from scratch, at least the parts we're talking about here. I know of at least half a dozen people on this mailing list who could fairly easily do the job I described in the first paragraph above. I have yet to see such code. It sounds simpler than it is. FWI: I did not just write a piece of the PPP code, I wrote the whole protocol from the ground up. I do know a little bit out PPP and how it is used in the real world in over 100 different embedded applications. I would be very interested in seeing the code you described. -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 8 17:15:56 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id RAA11189; Tue, 8 Jul 1997 17:15:55 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 8 Jul 1997 17:15:45 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id RAA11169 for ietf-ppp-outgoing; Tue, 8 Jul 1997 17:15:44 -0400 (EDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.29]) by merit.edu (8.8.5/8.8.5) with ESMTP id RAA11165 for ; Tue, 8 Jul 1997 17:15:40 -0400 (EDT) Received: by mail4.microsoft.com with Internet Mail Service (5.0.1458.49) id <33XAAFHJ>; Tue, 8 Jul 1997 14:16:08 -0700 Message-ID: <114DB67712DCD011A63500805F385DB20E5B77@RED-38-MSG.dns.microsoft.com> From: Paul Martin To: "'C. Harald Koch'" Cc: ietf-ppp@merit.edu Subject: RE: draft-rfced-info-martin-00.txt Date: Tue, 8 Jul 1997 14:15:39 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Sender: owner-ietf-ppp@merit.edu Trust me, the OEM's will push it. -----Original Message----- From: C. Harald Koch [SMTP:chk@utcc.utoronto.ca] Sent: Tuesday, July 08, 1997 1:53 PM To: Paul Martin Cc: ietf-ppp@merit.edu Subject: Re: draft-rfced-info-martin-00.txt In message <114DB67712DCD011A63500805F385DB20E5B74@RED-38-MSG.dns.microsoft.com>, Paul Martin writes: > Yes, very interesting, and I thought of that. However, the perception > by the OEM's who put PPP into their box is that they need these > compression techniques. By adding the simple pad character we can still > get most of the benefit of VJ compression and be compatible with a wider > range of PPP implementations. Only once everyone implements it. To echo a comment I just made over in L2TP: By the time you get this protocol defined, accepted, and most importantly *deployed*, it will no longer be necessary; hardware will have advanced to the point where the problem no longer exists. -- Harald - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 8 17:55:26 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id RAA11998; Tue, 8 Jul 1997 17:55:25 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 8 Jul 1997 17:55:17 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id RAA11980 for ietf-ppp-outgoing; Tue, 8 Jul 1997 17:55:16 -0400 (EDT) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by merit.edu (8.8.5/8.8.5) with SMTP id RAA11976 for ; Tue, 8 Jul 1997 17:55:12 -0400 (EDT) Received: from spud.ascend.com (fw-ext.ascend.com [198.4.92.5]) by drawbridge.ascend.com (8.6.12/8.6.12) with ESMTP id OAA16541; Tue, 8 Jul 1997 14:55:04 -0700 Received: from ascend.com by ascend.com with ESMTP id OAA05802; Tue, 8 Jul 1997 14:55:03 -0700 Received: from gump.eng.ascend.com (gump.eng.ascend.com [206.65.212.67]) by wopr.eng.ascend.com (8.6.12/8.6.12) with ESMTP id OAA00744; Tue, 8 Jul 1997 14:54:32 -0700 Received: from carp.morningstar.com.ascend.com (karl@carp.MorningStar.Com [137.175.81.4]) by gump.eng.ascend.com (8.6.12/8.6.12) with SMTP id OAA18031; Tue, 8 Jul 1997 14:54:29 -0700 Date: Tue, 8 Jul 1997 14:54:29 -0700 Message-Id: <199707082154.OAA18031@gump.eng.ascend.com> From: Karl Fox To: Paul Martin Cc: "'C. Harald Koch'" , ietf-ppp@merit.edu Subject: RE: draft-rfced-info-martin-00.txt In-Reply-To: <114DB67712DCD011A63500805F385DB20E5B77@RED-38-MSG.dns.microsoft.com> References: <114DB67712DCD011A63500805F385DB20E5B77@RED-38-MSG.dns.microsoft.com> Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ietf-ppp@merit.edu Paul Martin writes: > Trust me, the OEM's will push it. Trust me, once they understand that it's unnecessary, they won't. -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 8 17:46:26 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id RAA11771; Tue, 8 Jul 1997 17:46:24 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 8 Jul 1997 17:46:04 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id RAA11742 for ietf-ppp-outgoing; Tue, 8 Jul 1997 17:46:03 -0400 (EDT) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by merit.edu (8.8.5/8.8.5) with SMTP id RAA11735 for ; Tue, 8 Jul 1997 17:45:58 -0400 (EDT) Received: from spud.ascend.com (fw-ext.ascend.com [198.4.92.5]) by drawbridge.ascend.com (8.6.12/8.6.12) with ESMTP id OAA16079; Tue, 8 Jul 1997 14:45:57 -0700 Received: from ascend.com by ascend.com with ESMTP id OAA05046; Tue, 8 Jul 1997 14:45:54 -0700 Received: from gump.eng.ascend.com (gump.eng.ascend.com [206.65.212.67]) by wopr.eng.ascend.com (8.6.12/8.6.12) with ESMTP id OAA00119; Tue, 8 Jul 1997 14:45:16 -0700 Received: from carp.morningstar.com.ascend.com (karl@carp.MorningStar.Com [137.175.81.4]) by gump.eng.ascend.com (8.6.12/8.6.12) with SMTP id OAA17990; Tue, 8 Jul 1997 14:45:14 -0700 Date: Tue, 8 Jul 1997 14:45:14 -0700 Message-Id: <199707082145.OAA17990@gump.eng.ascend.com> From: Karl Fox To: Paul Martin Cc: ietf-ppp@merit.edu Subject: Re: draft-rfced-info-martin-00.txt In-Reply-To: <114DB67712DCD011A63500805F385DB20E5B74@RED-38-MSG.dns.microsoft.com> References: <114DB67712DCD011A63500805F385DB20E5B74@RED-38-MSG.dns.microsoft.com> Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ietf-ppp@merit.edu Paul Martin writes: > Yes, very interesting, and I thought of that. However, the perception > by the OEM's who put PPP into their box is that they need these > compression techniques. By adding the simple pad character we can still > get most of the benefit of VJ compression and be compatible with a wider > range of PPP implementations. How will you be compatible with all existing PPP implementations that don't support your option? Will you have two versions of packet parsing code, one to be used when your option is negotiated and one to be used when it is rejected? If so, won't your code size then end up being larger than any of the heretofore discussed suggestions? > You would be amazed of how many ISP's will simply reject the > connection entirely because it does not support VJ compression. Yes, I would be amazed if this were true. -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 8 17:53:43 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id RAA11925; Tue, 8 Jul 1997 17:53:41 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 8 Jul 1997 17:52:49 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id RAA11896 for ietf-ppp-outgoing; Tue, 8 Jul 1997 17:52:48 -0400 (EDT) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by merit.edu (8.8.5/8.8.5) with SMTP id RAA11890 for ; Tue, 8 Jul 1997 17:52:43 -0400 (EDT) Received: from spud.ascend.com (fw-ext.ascend.com [198.4.92.5]) by drawbridge.ascend.com (8.6.12/8.6.12) with ESMTP id OAA16410; Tue, 8 Jul 1997 14:52:41 -0700 Received: from ascend.com by ascend.com with ESMTP id OAA05678; Tue, 8 Jul 1997 14:52:38 -0700 Received: from gump.eng.ascend.com (gump.eng.ascend.com [206.65.212.67]) by wopr.eng.ascend.com (8.6.12/8.6.12) with ESMTP id OAA00599; Tue, 8 Jul 1997 14:52:06 -0700 Received: from carp.morningstar.com.ascend.com (karl@carp.MorningStar.Com [137.175.81.4]) by gump.eng.ascend.com (8.6.12/8.6.12) with SMTP id OAA18019; Tue, 8 Jul 1997 14:52:03 -0700 Date: Tue, 8 Jul 1997 14:52:03 -0700 Message-Id: <199707082152.OAA18019@gump.eng.ascend.com> From: Karl Fox To: Paul Martin Cc: "'Karl Fox'" , ietf-ppp@merit.edu Subject: RE: draft-rfced-info-martin-00.txt In-Reply-To: <114DB67712DCD011A63500805F385DB20E5B78@RED-38-MSG.dns.microsoft.com> References: <114DB67712DCD011A63500805F385DB20E5B78@RED-38-MSG.dns.microsoft.com> Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ietf-ppp@merit.edu Paul Martin writes: > I have yet to see such code. It sounds simpler than it is. > FWI: I did not just write a piece of the PPP code, I wrote the whole > protocol from the ground up. I do know a little bit out PPP and how it > is used in the real world in over 100 different embedded applications. > > I would be very interested in seeing the code you described. No doubt. If you'll go back and read what I wrote, you'll see that I was proposing a technique that would solve your problem, plus I said that there were several people on this mailing list who would be able to implement it without difficulty. I never said it already existed. -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 8 17:59:58 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id RAA12115; Tue, 8 Jul 1997 17:59:52 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 8 Jul 1997 17:59:44 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id RAA12097 for ietf-ppp-outgoing; Tue, 8 Jul 1997 17:59:43 -0400 (EDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.29]) by merit.edu (8.8.5/8.8.5) with ESMTP id RAA12092 for ; Tue, 8 Jul 1997 17:59:39 -0400 (EDT) Received: by mail4.microsoft.com with Internet Mail Service (5.0.1458.49) id <33XAAHVA>; Tue, 8 Jul 1997 15:00:07 -0700 Message-ID: <114DB67712DCD011A63500805F385DB20E5B7A@RED-38-MSG.dns.microsoft.com> From: Paul Martin To: "'Karl Fox'" Cc: ietf-ppp@merit.edu Subject: RE: draft-rfced-info-martin-00.txt Date: Tue, 8 Jul 1997 14:59:37 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Sender: owner-ietf-ppp@merit.edu -----Original Message----- From: Karl Fox [SMTP:karl@ascend.com] Sent: Tuesday, July 08, 1997 2:52 PM To: Paul Martin Cc: 'Karl Fox'; ietf-ppp@merit.edu Subject: RE: draft-rfced-info-martin-00.txt Paul Martin writes: > I have yet to see such code. It sounds simpler than it is. > FWI: I did not just write a piece of the PPP code, I wrote the whole > protocol from the ground up. I do know a little bit out PPP and how it > is used in the real world in over 100 different embedded applications. > > I would be very interested in seeing the code you described. No doubt. If you'll go back and read what I wrote, you'll see that I was proposing a technique that would solve your problem, plus I said that there were several people on this mailing list who would be able to implement it without difficulty. I don't understand how you can come to the conclusion that people on The mailing list could implement your suggestion "without difficulty" when nobody to date has done it. You would think that if several people in this mailing list alone, could do it, then someone would have already done it. Maybe nobody has seen the need to align IP datagrams, but a SPARC processor requires it as well as an ARM, and Motorola's CPU32 core processor and EC Core processor. With all those processors, seems like someone would have done it. I never said it already existed. -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 8 17:57:34 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id RAA12061; Tue, 8 Jul 1997 17:57:32 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 8 Jul 1997 17:57:23 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id RAA12038 for ietf-ppp-outgoing; Tue, 8 Jul 1997 17:57:22 -0400 (EDT) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by merit.edu (8.8.5/8.8.5) with SMTP id RAA12034 for ; Tue, 8 Jul 1997 17:57:17 -0400 (EDT) Received: from spud.ascend.com (fw-ext.ascend.com [198.4.92.5]) by drawbridge.ascend.com (8.6.12/8.6.12) with ESMTP id OAA16612; Tue, 8 Jul 1997 14:57:16 -0700 Received: from ascend.com by ascend.com with ESMTP id OAA06012; Tue, 8 Jul 1997 14:57:11 -0700 Received: from gump.eng.ascend.com (gump.eng.ascend.com [206.65.212.67]) by wopr.eng.ascend.com (8.6.12/8.6.12) with ESMTP id OAA00851; Tue, 8 Jul 1997 14:56:39 -0700 Received: from carp.morningstar.com.ascend.com (karl@carp.MorningStar.Com [137.175.81.4]) by gump.eng.ascend.com (8.6.12/8.6.12) with SMTP id OAA18038; Tue, 8 Jul 1997 14:56:37 -0700 Date: Tue, 8 Jul 1997 14:56:37 -0700 Message-Id: <199707082156.OAA18038@gump.eng.ascend.com> From: Karl Fox To: Paul Martin Cc: "'Karl Fox'" , ietf-ppp@merit.edu Subject: RE: draft-rfced-info-martin-00.txt In-Reply-To: <114DB67712DCD011A63500805F385DB20E5B79@RED-38-MSG.dns.microsoft.com> References: <114DB67712DCD011A63500805F385DB20E5B79@RED-38-MSG.dns.microsoft.com> Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ietf-ppp@merit.edu Paul Martin writes: > BTW Karl, I sent you some email on this subject some months ago > and never received any response. In that email I asked for your > opinions and comments on the idea of a pad character. The RFC editor > did the same and got no response. Not true; I delayed, but did eventually respond to both you and the RFC editor. The conclusion I offered was that the option was unnecessary and could be solved better with existing protocols. After today's discussion, I am even more certain of it. > Thank you for taking the time now to review and comment. You're welcome. -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 8 17:54:17 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id RAA11960; Tue, 8 Jul 1997 17:54:16 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 8 Jul 1997 17:54:02 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id RAA11933 for ietf-ppp-outgoing; Tue, 8 Jul 1997 17:54:01 -0400 (EDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.42]) by merit.edu (8.8.5/8.8.5) with ESMTP id RAA11929 for ; Tue, 8 Jul 1997 17:53:57 -0400 (EDT) Received: by INET-02-IMC with Internet Mail Service (5.0.1458.49) id <3P2VLD5A>; Tue, 8 Jul 1997 14:53:57 -0700 Message-ID: <114DB67712DCD011A63500805F385DB20E5B79@RED-38-MSG.dns.microsoft.com> From: Paul Martin To: "'Karl Fox'" Cc: ietf-ppp@merit.edu Subject: RE: draft-rfced-info-martin-00.txt Date: Tue, 8 Jul 1997 14:53:37 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Sender: owner-ietf-ppp@merit.edu -----Original Message----- From: Karl Fox [SMTP:karl@ascend.com] Sent: Tuesday, July 08, 1997 2:45 PM To: Paul Martin Cc: ietf-ppp@merit.edu Subject: Re: draft-rfced-info-martin-00.txt Paul Martin writes: > Yes, very interesting, and I thought of that. However, the perception > by the OEM's who put PPP into their box is that they need these > compression techniques. By adding the simple pad character we can still > get most of the benefit of VJ compression and be compatible with a wider > range of PPP implementations. How will you be compatible with all existing PPP implementations that don't support your option? Will you have two versions of packet parsing code, one to be used when your option is negotiated and one to be used when it is rejected? If so, won't your code size then end up being larger than any of the heretofore discussed suggestions? Current implementations tend to copy the frame to realign, post VJ. I expect they will still do this as a backup. One additional option is very minimal code to add. > You would be amazed of how many ISP's will simply reject the > connection entirely because it does not support VJ compression. Yes, I would be amazed if this were true. I have tested my PPP code all over the world and I have seen some strange incarnations of PPP. BTW Karl, I sent you some email on this subject some months ago and never received any response. In that email I asked for your opinions and comments on the idea of a pad character. The RFC editor did the same and got no response. Thank you for taking the time now to review and comment. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 8 18:12:41 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id SAA12423; Tue, 8 Jul 1997 18:12:39 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 8 Jul 1997 18:12:27 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id SAA12403 for ietf-ppp-outgoing; Tue, 8 Jul 1997 18:12:26 -0400 (EDT) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by merit.edu (8.8.5/8.8.5) with SMTP id SAA12398 for ; Tue, 8 Jul 1997 18:12:21 -0400 (EDT) Received: from spud.ascend.com (fw-ext.ascend.com [198.4.92.5]) by drawbridge.ascend.com (8.6.12/8.6.12) with ESMTP id PAA17856; Tue, 8 Jul 1997 15:12:19 -0700 Received: from ascend.com by ascend.com with ESMTP id PAA07084; Tue, 8 Jul 1997 15:12:19 -0700 Received: from gump.eng.ascend.com (gump.eng.ascend.com [206.65.212.67]) by wopr.eng.ascend.com (8.6.12/8.6.12) with ESMTP id PAA01973; Tue, 8 Jul 1997 15:11:48 -0700 Received: from carp.morningstar.com.ascend.com (karl@carp.MorningStar.Com [137.175.81.4]) by gump.eng.ascend.com (8.6.12/8.6.12) with SMTP id PAA18108; Tue, 8 Jul 1997 15:11:46 -0700 Date: Tue, 8 Jul 1997 15:11:46 -0700 Message-Id: <199707082211.PAA18108@gump.eng.ascend.com> From: Karl Fox To: Paul Martin Cc: "'Karl Fox'" , ietf-ppp@merit.edu Subject: RE: draft-rfced-info-martin-00.txt In-Reply-To: <114DB67712DCD011A63500805F385DB20E5B7A@RED-38-MSG.dns.microsoft.com> References: <114DB67712DCD011A63500805F385DB20E5B7A@RED-38-MSG.dns.microsoft.com> Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ietf-ppp@merit.edu Paul Martin writes: > I don't understand how you can come to the conclusion that people on > The mailing list could implement your suggestion "without > difficulty" when nobody to date has done it. Your logic escapes me here. Most programmers make time estimates before they embark on a coding project. > You would think that if several people in this mailing list alone, > could do it, then someone would have already done it. You yourself said that your hardware had so few capabilities that traditional techniques wouldn't work. Perhaps that's why nobody has bothered to implement anything like this yet. Or perhaps they have; I can't know how everybody's implementations work. > Maybe nobody has seen the need to align IP datagrams, but a SPARC > processor requires it as well as an ARM, and Motorola's CPU32 core > processor and EC Core processor. > > With all those processors, seems like someone would have done it. Not that I'm aware of, and I've implemented PPP on most of them. > I never said it already existed. Sorry; I misunderstood you when you said "I would be very interested in seeing the code you described." -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 8 19:22:46 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id TAA13565; Tue, 8 Jul 1997 19:22:44 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 8 Jul 1997 19:22:29 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id TAA13546 for ietf-ppp-outgoing; Tue, 8 Jul 1997 19:22:29 -0400 (EDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.41]) by merit.edu (8.8.5/8.8.5) with ESMTP id TAA13540 for ; Tue, 8 Jul 1997 19:22:25 -0400 (EDT) Received: by INET-01-IMC with Internet Mail Service (5.0.1458.49) id <32KFJGMW>; Tue, 8 Jul 1997 16:22:26 -0700 Message-ID: <114DB67712DCD011A63500805F385DB20E5B7B@RED-38-MSG.dns.microsoft.com> From: Paul Martin To: "'Karl Fox'" Cc: ietf-ppp@merit.edu Subject: RE: draft-rfced-info-martin-00.txt Date: Tue, 8 Jul 1997 16:20:11 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Sender: owner-ietf-ppp@merit.edu -----Original Message----- From: Karl Fox [SMTP:karl@ascend.com] Sent: Tuesday, July 08, 1997 3:12 PM To: Paul Martin Cc: 'Karl Fox'; ietf-ppp@merit.edu Subject: RE: draft-rfced-info-martin-00.txt Paul Martin writes: > I don't understand how you can come to the conclusion that people on > The mailing list could implement your suggestion "without > difficulty" when nobody to date has done it. Your logic escapes me here. Most programmers make time estimates before they embark on a coding project. I know that they do, but I would hesitate to make an estimate for someone else as you have done here without reviewing their work and talking to them first. > You would think that if several people in this mailing list alone, > could do it, then someone would have already done it. You yourself said that your hardware had so few capabilities that traditional techniques wouldn't work. Perhaps that's why nobody has bothered to implement anything like this yet. Or perhaps they have; I can't know how everybody's implementations work. I didn't say this was for a particular hardware platform. I said it is simpler And more efficient to do add the pad rather than building in a complex state machine. > Maybe nobody has seen the need to align IP datagrams, but a SPARC > processor requires it as well as an ARM, and Motorola's CPU32 core > processor and EC Core processor. > > With all those processors, seems like someone would have done it. Not that I'm aware of, and I've implemented PPP on most of them. That is my point. Why didn't you do it? Why not eliminate a copy in the processing of a packet if it is so simple. Wow, I never expected to be hit with such a barrage of non constructive comments when I asked for comments and suggestions. I really wish you would have not "delayed" your response to my email of some months ago. It seems that it is some religious thing to not supplement the protocol in any way. Even though in practice, the protocol can be inefficient. You are truly a devout defender of the PPP protocol. Maybe I should take one person's advice and invent a whole new protocol to replace PPP. Let me ask one question. What is the harm in adding this as an option them implementers can add on their own? Does it somehow damage the PPP protocol? I was not suggesting to make it a requirement. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 8 19:34:35 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id TAA13785; Tue, 8 Jul 1997 19:34:34 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 8 Jul 1997 19:34:25 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id TAA13762 for ietf-ppp-outgoing; Tue, 8 Jul 1997 19:34:25 -0400 (EDT) Received: from tor.securecomputing.com (border.com [199.71.190.98]) by merit.edu (8.8.5/8.8.5) with ESMTP id TAA13758 for ; Tue, 8 Jul 1997 19:34:17 -0400 (EDT) Received: by janus.tor.securecomputing.com id <11651>; Tue, 8 Jul 1997 19:28:41 -0400 Message-Id: <97Jul8.192841edt.11651@janus.tor.securecomputing.com> To: Paul Martin cc: "'Karl Fox'" , ietf-ppp@merit.edu Subject: Re: draft-rfced-info-martin-00.txt References: <114DB67712DCD011A63500805F385DB20E5B7B@RED-38-MSG.dns.microsoft.com> In-reply-to: paulmart's message of "Tue, 08 Jul 1997 19:20:11 -0400". <114DB67712DCD011A63500805F385DB20E5B7B@RED-38-MSG.dns.microsoft.com> From: "C. Harald Koch" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <25878.868404835.1@rafael.tornd.securecomputing.com> Date: Tue, 8 Jul 1997 19:33:55 -0400 Sender: owner-ietf-ppp@merit.edu In message <114DB67712DCD011A63500805F385DB20E5B7B@RED-38-MSG.dns.microsoft.com>, Paul Martin writes: > > Let me ask one question. What is the harm in adding this as an > option them implementers > can add on their own? Does it somehow damage the PPP protocol? > I was not suggesting > to make it a requirement. Adding options to a protocol reduces interoperability and increases code complexity. If the problem can be handled without adding a new option, this is the preferred route. FWIW, this is unofficial IETF doctrine; it's not written down anywhere. -- Harald - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 8 19:32:51 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id TAA13720; Tue, 8 Jul 1997 19:32:50 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 8 Jul 1997 19:32:42 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id TAA13701 for ietf-ppp-outgoing; Tue, 8 Jul 1997 19:32:42 -0400 (EDT) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by merit.edu (8.8.5/8.8.5) with SMTP id TAA13697 for ; Tue, 8 Jul 1997 19:32:37 -0400 (EDT) Received: from spud.ascend.com (fw-ext.ascend.com [198.4.92.5]) by drawbridge.ascend.com (8.6.12/8.6.12) with ESMTP id QAA21322; Tue, 8 Jul 1997 16:32:36 -0700 Received: from ascend.com by ascend.com with ESMTP id QAA12292; Tue, 8 Jul 1997 16:32:31 -0700 Received: from gump.eng.ascend.com (gump.eng.ascend.com [206.65.212.67]) by wopr.eng.ascend.com (8.6.12/8.6.12) with ESMTP id QAA08376; Tue, 8 Jul 1997 16:32:00 -0700 Received: from carp.morningstar.com.ascend.com (karl@carp.MorningStar.Com [137.175.81.4]) by gump.eng.ascend.com (8.6.12/8.6.12) with SMTP id QAA18469; Tue, 8 Jul 1997 16:31:58 -0700 Date: Tue, 8 Jul 1997 16:31:58 -0700 Message-Id: <199707082331.QAA18469@gump.eng.ascend.com> From: Karl Fox To: Paul Martin Cc: "'Karl Fox'" , ietf-ppp@merit.edu Subject: RE: draft-rfced-info-martin-00.txt In-Reply-To: <114DB67712DCD011A63500805F385DB20E5B7B@RED-38-MSG.dns.microsoft.com> References: <114DB67712DCD011A63500805F385DB20E5B7B@RED-38-MSG.dns.microsoft.com> Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ietf-ppp@merit.edu Paul Martin writes: > It seems that it is some religious thing to not supplement the > protocol in any way. It's not religion, it's one of the rules the IETF abides by. To summarize: "Don't invent unnecessary crap." It's a good rule, too. -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 8 19:42:48 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id TAA13924; Tue, 8 Jul 1997 19:42:47 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 8 Jul 1997 19:42:39 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id TAA13906 for ietf-ppp-outgoing; Tue, 8 Jul 1997 19:42:39 -0400 (EDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.31]) by merit.edu (8.8.5/8.8.5) with ESMTP id TAA13899 for ; Tue, 8 Jul 1997 19:42:34 -0400 (EDT) Received: by mail5.microsoft.com with Internet Mail Service (5.0.1458.49) id <3RBKCRL0>; Tue, 8 Jul 1997 16:44:23 -0700 Message-ID: <114DB67712DCD011A63500805F385DB20E5B7D@RED-38-MSG.dns.microsoft.com> From: Paul Martin To: "'ietf-ppp@merit.edu'" Subject: RE: draft-rfced-info-martin-00.txt Date: Tue, 8 Jul 1997 16:42:34 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Sender: owner-ietf-ppp@merit.edu -----Original Message----- From: Karl Fox [SMTP:karl@ascend.com] Sent: Tuesday, July 08, 1997 4:32 PM To: Paul Martin Cc: 'Karl Fox'; ietf-ppp@merit.edu Subject: RE: draft-rfced-info-martin-00.txt Paul Martin writes: > It seems that it is some religious thing to not supplement the > protocol in any way. It's not religion, it's one of the rules the IETF abides by. To summarize: "Don't invent unnecessary crap." It's a good rule, too. Unnecessary is your opinion, not mine. It seems that we need more people discussing this to have a true consensus. Of course I don't know how necessary it was to have protocol field compression. How necessary is it to have an address field or control field in PPP? As you can see, people often have different opinions. I see that we differ in ours and will probably never agree. I do agree that in most cases, the pad character is not needed. But for a few cases, it would sure be nice. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 8 21:28:55 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id VAA15471; Tue, 8 Jul 1997 21:28:53 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 8 Jul 1997 21:28:15 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id VAA15443 for ietf-ppp-outgoing; Tue, 8 Jul 1997 21:28:15 -0400 (EDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm002-05.dialip.mich.net [141.211.7.141]) by merit.edu (8.8.5/8.8.5) with SMTP id VAA15437 for ; Tue, 8 Jul 1997 21:28:10 -0400 (EDT) Date: Wed, 9 Jul 97 01:06:31 GMT From: "William Allen Simpson" Message-ID: <6206.wsimpson@greendragon.com> To: Paul Martin Cc: ietf-ppp@merit.edu Subject: Re: draft-rfced-info-martin-00.txt Sender: owner-ietf-ppp@merit.edu > From: Paul Martin > Are you that slick/smart programmer? I have written PPP for > embedded systems from scratch (Not steal it from the public domain), and > I don't see a way without adding a bunch of code and processing But > hey, maybe I am not that smart. > I, too, have written PPP for consumer products, routers, and embedded systems. Had you done your research, you may have noticed that Karl Fox wrote another PPP -- the widely used public domain version for Unix.... That said, I've ported my PPP code into cellular phones with a mere 186 embedded in a fancy ASIC for Viterbi decoding. Very small memory. Extremely processor limited. Kinda the ultimate "handheld consumer electronics device". I had no problems with header alignment. I did not do the VJ expansion on the fly. I had no problems with the VJ data copy, as I used a very simple mbuf structure that pointed into the VJ header buffers and chained the remainder of the data. Oh, yeah, and I did it on both sides of the handheld phone -- on/off the air, and in/out the serial cable -- independently. No problem, just a couple of months of design, and another couple of months of careful coding, and another couple of months of testing and tweeking.... WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 8 21:52:10 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id VAA15745; Tue, 8 Jul 1997 21:52:08 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 8 Jul 1997 21:51:52 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id VAA15727 for ietf-ppp-outgoing; Tue, 8 Jul 1997 21:51:52 -0400 (EDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm059-09.dialip.mich.net [141.211.5.77]) by merit.edu (8.8.5/8.8.5) with SMTP id VAA15723 for ; Tue, 8 Jul 1997 21:51:48 -0400 (EDT) Date: Wed, 9 Jul 97 01:27:58 GMT From: "William Allen Simpson" Message-ID: <6208.wsimpson@greendragon.com> To: Paul Martin Cc: ietf-ppp@merit.edu Subject: Re: draft-rfced-info-martin-00.txt Sender: owner-ietf-ppp@merit.edu This one got my dander up; I should have read them all before replying the first time: > From: Paul Martin > You would be amazed of how many ISP's > will simply reject the connection entirely because it does not support > VJ compression. > Speaking as the owner of an ISP, I don't understand how the ISP takes a position to "reject a connection" on any other grounds than failed authentication. This must be a specific vendor problem. I have not encountered this problem with any of the equipment I have used in the past 7 years -- primarily (in alphabetical order) Ascend, Livingston, and Telebit, but also some smaller vendors. Before you send any other reply, could you please name one specific ISP and their equipment vendors? I'd like to verify. Any implementation that does not function without the VJ compression is non-conformant. It is a _fundamental_ principle of PPP negotiation that these are _options_. We named them that for a reason. Support is optional. > What I am looking for is constructive comments. > > I would also like to hear from people who have implemented PPP in the > Consumer Electronics industry. > I already posted a moment ago. My constructive comment is that you resubmit the draft with proper PPP headers indicating that this is a vendor specific option. See RFC-2153. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jul 9 11:09:41 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id LAA26086; Wed, 9 Jul 1997 11:09:07 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 9 Jul 1997 11:03:08 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id LAA25923 for ietf-ppp-outgoing; Wed, 9 Jul 1997 11:03:08 -0400 (EDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.29]) by merit.edu (8.8.5/8.8.5) with ESMTP id LAA25919 for ; Wed, 9 Jul 1997 11:03:04 -0400 (EDT) Received: by mail4.microsoft.com with Internet Mail Service (5.0.1458.49) id <3S416XZH>; Wed, 9 Jul 1997 08:03:37 -0700 Message-ID: <114DB67712DCD011A63500805F385DB22CF8B7@RED-38-MSG.dns.microsoft.com> From: Paul Martin To: John Shriver Cc: ietf-ppp@merit.edu Subject: RE: draft-rfced-info-martin-00.txt Date: Wed, 9 Jul 1997 08:01:17 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Sender: owner-ietf-ppp@merit.edu Thanks for the reply. It is very helpful. Thanks William for your comments as well. I never intended it to be put into a standards track. I knew the flack I was going to get. I also published this while I was at another company (Pacific Softworks, Makers of TCP/IP for embedded systems). This is not a Microsoft proposed RFC. It took Karl Fox 2 months just to get an email back to me. This was only after the RFC Editor had sent him 2 requests to look at it. I specifically asked Karl for suggestions before putting together the RFC. Then again I sent it to Karl for review and didn't receive a response. I am truly disappointed in the response time from Karl. It seems that since I have solicited comments, he seems to have all the time in the world to bash me. This kind of behavior makes one not want to participate in the discussions at hand. Do I need to know some secret handshake? As an Informational RFC, I intended for people to test the waters to see if it was interesting. I also wanted to see if people had implemented PPP on processors with STRICT word Alignment, such as the TI-TMS320C32 and a CPU32 (not the plus) core from Motorola. If they had implemented it, I was curious to find out if they ran into the same disgusting prospect of having to copy the datagram post VJ or if they had built complex state machines to process on the fly. -----Original Message----- From: John Shriver [SMTP:jas@shiva.com] Sent: Wednesday, July 09, 1997 7:30 AM To: Paul Martin Subject: RE: draft-rfced-info-martin-00.txt I think that the reality is that you're not going to find many peers interested in implementing it. There is no compelling advantadge to their doing so. (Why should they help a competitor, anyways?) You can't assume your option will be available, so you have to code both ways. By adding it, you're only making more code, but I assume that your PROM/FLASH budget is not as tight as your data/MIPS budget. You also have to test both ways -- there's more QA cost and time. The intent of the original PPP architecture was to choose a set of defaults that everyone's hardware could cope with at the time. The good old "least common denominator." They did that. (Otherwise there would still be no PPP, there would still be Cisco, Proteon, Bridge Communications, and ACC proprietary formats.) The assumption was that the hardware to run PPP on would get more capable, not less capable. Then there were LCP options to **OPTIMIZE** some things on the wire, but these optimizations that would not be feasible with some people's hardware. (Some used an old Motorola X.25 controller that required the address and protocol fields. The allowance for padding is because Proteon and ACC had hardware that padded on transmit.) That's why they were options, to improve performance if the hardware supported. But there were no options to backoff for less capable hardware, only to be more agressive for more capable hardware. You are looking for the former, that's not in the spirit of PPP. I agree with Bill Simpson. You are free to use LCP option 0 with your OUI, and have a proprietary option that only Microsoft servers, and your client, use. Then, publish as an Informational RFC. I think in the end, that's the same result you would wind up with if you got your ID onto the PPP standards track -- nobody else would implement it. But, even if you do succeed in standards-tacking this option, that is no guaruntee that there will be any more implementations than the "two interoperable" required to stay on the standards track. It is an OPTION. Even if it comes from Microsoft. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jul 9 12:12:52 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id MAA27809; Wed, 9 Jul 1997 12:12:51 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 9 Jul 1997 12:12:43 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id MAA27791 for ietf-ppp-outgoing; Wed, 9 Jul 1997 12:12:42 -0400 (EDT) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by merit.edu (8.8.5/8.8.5) with SMTP id MAA27784 for ; Wed, 9 Jul 1997 12:12:36 -0400 (EDT) Received: from spud.ascend.com (fw-ext.ascend.com [198.4.92.5]) by drawbridge.ascend.com (8.6.12/8.6.12) with ESMTP id JAA19691 for ; Wed, 9 Jul 1997 09:12:35 -0700 Received: from ascend.com by ascend.com with ESMTP id JAA22354 for ; Wed, 9 Jul 1997 09:12:32 -0700 Received: from gump.eng.ascend.com (gump.eng.ascend.com [206.65.212.67]) by wopr.eng.ascend.com (8.6.12/8.6.12) with ESMTP id JAA03230 for ; Wed, 9 Jul 1997 09:12:01 -0700 Received: from carp.morningstar.com.ascend.com (karl@carp.MorningStar.Com [137.175.81.4]) by gump.eng.ascend.com (8.6.12/8.6.12) with SMTP id JAA20998 for ; Wed, 9 Jul 1997 09:11:59 -0700 Date: Wed, 9 Jul 1997 09:11:59 -0700 Message-Id: <199707091611.JAA20998@gump.eng.ascend.com> From: Karl Fox To: ietf-ppp@merit.edu Subject: Mobile-IPv4 Configuration Option for PPP IPCP - Working Group Last Call Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ietf-ppp@merit.edu This is last call. I will advise the area directors that we want to take Mobile-IPv4 Configuration Option for PPP IPCP (draft-ietf-pppext-ipcp-mip-02.txt) to Proposed Standard on July 23 unless there is substantive comment raised on the list. -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jul 9 12:12:04 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id MAA27776; Wed, 9 Jul 1997 12:11:47 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 9 Jul 1997 12:11:24 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id MAA27756 for ietf-ppp-outgoing; Wed, 9 Jul 1997 12:11:23 -0400 (EDT) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by merit.edu (8.8.5/8.8.5) with SMTP id MAA27749 for ; Wed, 9 Jul 1997 12:11:18 -0400 (EDT) Received: from spud.ascend.com (fw-ext.ascend.com [198.4.92.5]) by drawbridge.ascend.com (8.6.12/8.6.12) with ESMTP id JAA19622; Wed, 9 Jul 1997 09:11:16 -0700 Received: from ascend.com by ascend.com with ESMTP id JAA22278; Wed, 9 Jul 1997 09:11:13 -0700 Received: from gump.eng.ascend.com (gump.eng.ascend.com [206.65.212.67]) by wopr.eng.ascend.com (8.6.12/8.6.12) with ESMTP id JAA03156; Wed, 9 Jul 1997 09:10:42 -0700 Received: from carp.morningstar.com.ascend.com (karl@carp.MorningStar.Com [137.175.81.4]) by gump.eng.ascend.com (8.6.12/8.6.12) with SMTP id JAA20993; Wed, 9 Jul 1997 09:10:40 -0700 Date: Wed, 9 Jul 1997 09:10:40 -0700 Message-Id: <199707091610.JAA20993@gump.eng.ascend.com> From: Karl Fox To: Paul Martin Cc: ietf-ppp@merit.edu Subject: RE: draft-rfced-info-martin-00.txt In-Reply-To: <114DB67712DCD011A63500805F385DB22CF8B7@RED-38-MSG.dns.microsoft.com> References: <114DB67712DCD011A63500805F385DB22CF8B7@RED-38-MSG.dns.microsoft.com> Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ietf-ppp@merit.edu Paul Martin writes: > I am truly disappointed in the response time from Karl. It seems > that since I have solicited comments, he seems to have all the time > in the world to bash me. This kind of behavior makes one not want > to participate in the discussions at hand. Do I need to know some > secret handshake? Again, I apologize for the delay. At the time, I was traveling a fair amount, plus I was under some significant pressures at work. Since no summary or explanation was given me I chose not to read the draft to find out what it was about, so I put it in a mailbox with a few hundred other requests I didn't have time to process. As anyone who gets a lot of e-mail knows, once you've stuck something on the back burner, it's hard to get back to it. Paul, I don't think I have bashed you at all. I and others have tried to explain to you why your proposal isn't needed, and have even given you design ideas that would allow you to accomplish your stated goals without having to risk incompatibility or waste bytes on the wire. The only secret handshake required in this forum is to be able to accept constructive criticism of your ideas. I thought it was all given in a positive light. -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jul 9 12:55:32 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id MAA29026; Wed, 9 Jul 1997 12:55:30 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 9 Jul 1997 12:55:19 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id MAA29001 for ietf-ppp-outgoing; Wed, 9 Jul 1997 12:55:19 -0400 (EDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.41]) by merit.edu (8.8.5/8.8.5) with ESMTP id MAA28992 for ; Wed, 9 Jul 1997 12:55:11 -0400 (EDT) Received: by INET-01-IMC with Internet Mail Service (5.0.1458.49) id <3SS51QNX>; Wed, 9 Jul 1997 09:55:13 -0700 Message-ID: <114DB67712DCD011A63500805F385DB20E5B7E@RED-38-MSG.dns.microsoft.com> From: Paul Martin To: "'Karl Fox'" Cc: ietf-ppp@merit.edu Subject: RE: draft-rfced-info-martin-00.txt Date: Wed, 9 Jul 1997 09:55:10 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Sender: owner-ietf-ppp@merit.edu I am sorry, but to me saying that a "Smart Programmer" would be able to do what I want to do is implying that I am somewhat less than smart. That my friend is not constructive criticism in my book. Do you still think it was all given in a positive light? I accept the fact that what I want to accomplish can be done in code, but there are times when this may not be preferable, and that is what I wanted to address. It seems silly to me that the IP datagram was designed to be word aligned, and (no offense William), PPP tossed it all out the window. The company I worked for (Pacific Softworks), sells more TCP/IP and PPP for embedded systems than any other company. I have seen more applications of TCP/IP and PPP in use than most people. The PPP I wrote is in use in so many devices, that I have a wider range of experience than the average person in this mailing list. That is not to say that I am any smarter, just more experienced. I also know things like MS-CHAP which are not in the standards track, will be in all kinds of Non Microsoft implementations over the next couple of years. I wonder if you were against it as well. At Pacific Softworks, we were being asked for it at least once a week from different OEM customers. I would venture to say that you thought it to be unnecessary as well. Well It seems things have changed. As for the time it took to get a response: I not only sent you the RFC but I explicitly asked for suggestions before writing it. I followed up with another email asking you if you had received it. I didn't think you existed for the longest time. After not receiving any response, I then wrote the draft you have before you. All this email could have been avoided, had you at least responded In response to Williams question about which ISP's do not support option negotiations (like VJ), to be truthful, I really don't know. I would get a call from a customer, and they would give me a phone number to try our PPP on, because they were having problems. I have seen all kinds of incarnations of PPP, some good and some bad. Just because it is written in the PPP spec does not mean that everyone conforms to it. This was over two years ago, and things have improved since then, but I know there are still PPP implementations which do not follow the specs. I am not going to name names here, but they know who they are. -----Original Message----- From: Karl Fox [SMTP:karl@ascend.com] Sent: Wednesday, July 09, 1997 9:11 AM To: Paul Martin Cc: ietf-ppp@merit.edu Subject: RE: draft-rfced-info-martin-00.txt The only secret handshake required in this forum is to be able to accept constructive criticism of your ideas. I thought it was all given in a positive light. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jul 9 13:05:12 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id NAA29305; Wed, 9 Jul 1997 13:05:11 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 9 Jul 1997 13:05:01 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id NAA29276 for ietf-ppp-outgoing; Wed, 9 Jul 1997 13:05:00 -0400 (EDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.41]) by merit.edu (8.8.5/8.8.5) with ESMTP id NAA29272 for ; Wed, 9 Jul 1997 13:04:56 -0400 (EDT) Received: by INET-01-IMC with Internet Mail Service (5.0.1458.49) id <3SS51RG9>; Wed, 9 Jul 1997 10:04:55 -0700 Message-ID: <114DB67712DCD011A63500805F385DB20E5B80@RED-38-MSG.dns.microsoft.com> From: Paul Martin To: "'William Allen Simpson'" Cc: ietf-ppp@merit.edu Subject: RE: draft-rfced-info-martin-00.txt Date: Wed, 9 Jul 1997 10:04:50 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Sender: owner-ietf-ppp@merit.edu -----Original Message----- From: William Allen Simpson [SMTP:wsimpson@greendragon.com] Sent: Tuesday, July 08, 1997 6:28 PM To: Paul Martin Cc: ietf-ppp@merit.edu Subject: Re: draft-rfced-info-martin-00.txt My constructive comment is that you resubmit the draft with proper PPP headers indicating that this is a vendor specific option. See RFC-2153. I agree and will do. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jul 9 13:31:50 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id NAA29910; Wed, 9 Jul 1997 13:30:23 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 9 Jul 1997 13:29:31 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id NAA29885 for ietf-ppp-outgoing; Wed, 9 Jul 1997 13:29:30 -0400 (EDT) Received: from ns.frigate.com (ns.frigate.com [206.14.208.6]) by merit.edu (8.8.5/8.8.5) with ESMTP id NAA29881 for ; Wed, 9 Jul 1997 13:29:24 -0400 (EDT) Received: from localhost (mthorn@localhost) by ns.frigate.com (8.8.5/8.7.1) with SMTP id KAA09269; Wed, 9 Jul 1997 10:29:41 -0700 (PDT) Date: Wed, 9 Jul 1997 10:29:40 -0700 (PDT) From: Mike Thornburg To: Paul Martin cc: "'Karl Fox'" , ietf-ppp@merit.edu Subject: RE: draft-rfced-info-martin-00.txt In-Reply-To: <114DB67712DCD011A63500805F385DB20E5B7E@RED-38-MSG.dns.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu On Wed, 9 Jul 1997, Paul Martin wrote: > > I accept the fact that what I want to accomplish can be done in code, > but there are times when this > may not be preferable, and that is what I wanted to address. It seems > silly to me that the IP datagram > was designed to be word aligned, and (no offense William), PPP tossed it > all out the window. > I just want to respond to this one point. The basic PPP implementation did pay attention to word alignment issues, and provides a way (by refusing to accept protocol field compression and address and control field compression) to preserve it if it is important. VJ header compression does not pay attention to alignment issues because that is one of the fundamental tradeoffs in designing a compression scheme: processor resources vs. bytes on the wire. The designer of that compression scheme assumed that it was more important to save a byte than to force word alignment. Similarly, the designers of the STAC algorithm assumed that it was more important to save a bit than to force byte alignment. I don't think you are justified in saying that PPP took a word-aligned IP datagram and "tossed it all out the window". One of the major design goals of VJ header compression was to put as few bytes on the wire as possible, and consequently that particular compression scheme discarded word alignment for TCP packets as being incompatible with that design goal. Thanks, Mike -------------- Mike Thornburg frigate networks 415.903.2266 mthorn@frigate.com http://www.frigate.com/ - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jul 9 14:34:55 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id OAA01585; Wed, 9 Jul 1997 14:34:40 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 9 Jul 1997 14:34:08 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id OAA01555 for ietf-ppp-outgoing; Wed, 9 Jul 1997 14:34:08 -0400 (EDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.42]) by merit.edu (8.8.5/8.8.5) with ESMTP id OAA01545 for ; Wed, 9 Jul 1997 14:34:00 -0400 (EDT) Received: by INET-02-IMC with Internet Mail Service (5.0.1458.49) id <3TB5G29W>; Wed, 9 Jul 1997 11:33:59 -0700 Message-ID: <114DB67712DCD011A63500805F385DB20E5B83@RED-38-MSG.dns.microsoft.com> From: Paul Martin To: "'Mike Thornburg'" Cc: "'Karl Fox'" , ietf-ppp@merit.edu Subject: RE: draft-rfced-info-martin-00.txt Date: Wed, 9 Jul 1997 10:41:26 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Sender: owner-ietf-ppp@merit.edu I take the view that the few bytes saved on the wire (or wireless), is not worth destroying the word alignment. The problem is in practice. Everybody wants every option. Even if it is bad. So we present VJ Compression, and it must be used. Address/Control Field Compression and again it must me used. Protocol Field Compression, again must be used. OEM's want it all. So every implementation must support it if it is to remain competitive and make the score card. This the way the world works. If you present an option, you can be guaranteed that nearly every implementation will have it. Those that don't will not survive. I understand what William was trying to accomplish by making it an option. However, in practice, word alignment in PPP is non-existent. -----Original Message----- From: Mike Thornburg [SMTP:mthorn@frigate.com] Sent: Wednesday, July 09, 1997 10:30 AM To: Paul Martin Cc: 'Karl Fox'; ietf-ppp@merit.edu Subject: RE: draft-rfced-info-martin-00.txt On Wed, 9 Jul 1997, Paul Martin wrote: > > I accept the fact that what I want to accomplish can be done in code, > but there are times when this > may not be preferable, and that is what I wanted to address. It seems > silly to me that the IP datagram > was designed to be word aligned, and (no offense William), PPP tossed it > all out the window. > I just want to respond to this one point. The basic PPP implementation did pay attention to word alignment issues, and provides a way (by refusing to accept protocol field compression and address and control field compression) to preserve it if it is important. VJ header compression does not pay attention to alignment issues because that is one of the fundamental tradeoffs in designing a compression scheme: processor resources vs. bytes on the wire. The designer of that compression scheme assumed that it was more important to save a byte than to force word alignment. Similarly, the designers of the STAC algorithm assumed that it was more important to save a bit than to force byte alignment. I don't think you are justified in saying that PPP took a word-aligned IP datagram and "tossed it all out the window". One of the major design goals of VJ header compression was to put as few bytes on the wire as possible, and consequently that particular compression scheme discarded word alignment for TCP packets as being incompatible with that design goal. Thanks, Mike -------------- Mike Thornburg frigate networks 415.903.2266 mthorn@frigate.com http://www.frigate.com/ - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jul 9 14:42:26 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id OAA01822; Wed, 9 Jul 1997 14:42:24 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 9 Jul 1997 14:42:10 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id OAA01801 for ietf-ppp-outgoing; Wed, 9 Jul 1997 14:42:09 -0400 (EDT) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by merit.edu (8.8.5/8.8.5) with SMTP id OAA01797 for ; Wed, 9 Jul 1997 14:42:03 -0400 (EDT) Received: from spud.ascend.com (fw-ext.ascend.com [198.4.92.5]) by drawbridge.ascend.com (8.6.12/8.6.12) with ESMTP id LAA28556; Wed, 9 Jul 1997 11:42:01 -0700 Received: from ascend.com by ascend.com with ESMTP id LAA03835; Wed, 9 Jul 1997 11:42:00 -0700 Received: from gump.eng.ascend.com (gump.eng.ascend.com [206.65.212.67]) by wopr.eng.ascend.com (8.6.12/8.6.12) with ESMTP id LAA13353; Wed, 9 Jul 1997 11:41:29 -0700 Received: from carp.morningstar.com.ascend.com (karl@carp.MorningStar.Com [137.175.81.4]) by gump.eng.ascend.com (8.6.12/8.6.12) with SMTP id LAA21838; Wed, 9 Jul 1997 11:41:27 -0700 Date: Wed, 9 Jul 1997 11:41:27 -0700 Message-Id: <199707091841.LAA21838@gump.eng.ascend.com> From: Karl Fox To: Paul Martin Cc: "'Karl Fox'" , ietf-ppp@merit.edu Subject: RE: draft-rfced-info-martin-00.txt In-Reply-To: <114DB67712DCD011A63500805F385DB20E5B7E@RED-38-MSG.dns.microsoft.com> References: <114DB67712DCD011A63500805F385DB20E5B7E@RED-38-MSG.dns.microsoft.com> Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ietf-ppp@merit.edu This will be my last message on this subject, which has dragged on far too long and has degenerated into ad hominem attacks. Please folks, let's move this discussion to personal e-mail. Paul Martin writes: > I am sorry, but to me saying that a "Smart Programmer" would be able > to do what I want to do is implying that I am somewhat less than > smart. That my friend is not constructive criticism in my book. Do > you still think it was all given in a positive light? Ah, now I understand why you got angry. I was trying to distinguish between the majority of programmers out there and the minority who understand how to design a FSM into a product. I have no knowledge about your abilities; I had never even heard of you before your draft (which is no indictment; I'm sure I've never met most of the PPP programmers in the world), and I certainly didn't intend to imply you were in the less able group. I was just saying that there are a number of people on this mailing list who I do know are in the more favored class. -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jul 9 14:47:20 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id OAA01996; Wed, 9 Jul 1997 14:47:18 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 9 Jul 1997 14:47:08 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id OAA01975 for ietf-ppp-outgoing; Wed, 9 Jul 1997 14:47:07 -0400 (EDT) Received: from ns.frigate.com (ns.frigate.com [206.14.208.6]) by merit.edu (8.8.5/8.8.5) with ESMTP id OAA01965 for ; Wed, 9 Jul 1997 14:46:56 -0400 (EDT) Received: from localhost (mthorn@localhost) by ns.frigate.com (8.8.5/8.7.1) with SMTP id LAA09410; Wed, 9 Jul 1997 11:47:20 -0700 (PDT) Date: Wed, 9 Jul 1997 11:47:20 -0700 (PDT) From: Mike Thornburg To: Paul Martin cc: "'Karl Fox'" , ietf-ppp@merit.edu Subject: RE: draft-rfced-info-martin-00.txt In-Reply-To: <114DB67712DCD011A63500805F385DB20E5B83@RED-38-MSG.dns.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu On Wed, 9 Jul 1997, Paul Martin wrote: > I take the view that the few bytes saved on the wire (or wireless), is > not worth destroying the > word alignment. The problem is in practice. Everybody wants every > option. Even if it is bad. > So we present VJ Compression, and it must be used. Address/Control > Field Compression > and again it must me used. Protocol Field Compression, again must be > used. OEM's > want it all. So every implementation must support it if it is to remain > competitive and make > the score card. This the way the world works. If you present an > option, you can be > guaranteed that nearly every implementation will have it. Those that > don't will not survive. > I'm sorry, am I hearing you correctly? You want to force word alignment, so to do this you negotiate address and control field compression and protocol field compression to save 3 bytes from the header, then use your special IPCP option to add 3 bytes into a different place in the PPP frame (after the protocol field and before the IP packet actually begins) in order to make the IP packet word aligned. I usually try to be polite, but frankly, this is absurd. Thanks, Mike -------------- Mike Thornburg frigate networks 415.903.2266 mthorn@frigate.com http://www.frigate.com/ - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jul 9 14:44:51 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id OAA01920; Wed, 9 Jul 1997 14:44:49 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 9 Jul 1997 14:44:39 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id OAA01900 for ietf-ppp-outgoing; Wed, 9 Jul 1997 14:44:38 -0400 (EDT) Received: from tor.securecomputing.com (tor.securecomputing.com [199.71.190.98]) by merit.edu (8.8.5/8.8.5) with ESMTP id OAA01891 for ; Wed, 9 Jul 1997 14:44:30 -0400 (EDT) Received: by janus.tor.securecomputing.com id <11649>; Wed, 9 Jul 1997 14:39:00 -0400 Message-Id: <97Jul9.143900edt.11649@janus.tor.securecomputing.com> To: Paul Martin cc: "'Mike Thornburg'" , "'Karl Fox'" , ietf-ppp@merit.edu Subject: Re: draft-rfced-info-martin-00.txt References: <114DB67712DCD011A63500805F385DB20E5B83@RED-38-MSG.dns.microsoft.com> In-reply-to: paulmart's message of "Wed, 09 Jul 1997 13:41:26 -0400". <114DB67712DCD011A63500805F385DB20E5B83@RED-38-MSG.dns.microsoft.com> From: "C. Harald Koch" Date: Wed, 9 Jul 1997 14:44:12 -0400 Sender: owner-ietf-ppp@merit.edu In message <114DB67712DCD011A63500805F385DB20E5B83@RED-38-MSG.dns.microsoft.com>, Paul Martin writes: > I take the view that the few bytes saved on the wire (or wireless), is > not worth destroying the word alignment. You've never used PPP without VJ compression on a 9600bps link, have you? > I understand what William was trying to accomplish by making it an > option. However, in practice, word alignment in PPP is non-existent. That's because, as I said the first time, people have written *code* to handle the alignment problem, instead of trying to tweak the standard with bizarre padding options. We're arguing in circles here. -- Harald - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jul 9 15:25:40 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id PAA03190; Wed, 9 Jul 1997 15:25:37 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 9 Jul 1997 15:23:53 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id PAA03105 for ietf-ppp-outgoing; Wed, 9 Jul 1997 15:23:52 -0400 (EDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.41]) by merit.edu (8.8.5/8.8.5) with ESMTP id PAA03100 for ; Wed, 9 Jul 1997 15:23:47 -0400 (EDT) Received: by INET-01-IMC with Internet Mail Service (5.0.1458.49) id <3SS515MM>; Wed, 9 Jul 1997 12:23:44 -0700 Message-ID: <114DB67712DCD011A63500805F385DB20E5B88@RED-38-MSG.dns.microsoft.com> From: Paul Martin To: "'Mike Thornburg'" Cc: ietf-ppp@merit.edu Subject: RE: draft-rfced-info-martin-00.txt Date: Wed, 9 Jul 1997 12:23:35 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Sender: owner-ietf-ppp@merit.edu When taken with VJ compressed packets, you just don't put back what you took away. Look at the big picture. I agree it is absurd for just address/control and protocol field compression. It is also absurd to copy the frame just to align it on fast links. -----Original Message----- From: Mike Thornburg [SMTP:mthorn@frigate.com] Sent: Wednesday, July 09, 1997 11:47 AM To: Paul Martin Cc: 'Karl Fox'; ietf-ppp@merit.edu Subject: RE: draft-rfced-info-martin-00.txt On Wed, 9 Jul 1997, Paul Martin wrote: > I take the view that the few bytes saved on the wire (or wireless), is > not worth destroying the > word alignment. The problem is in practice. Everybody wants every > option. Even if it is bad. > So we present VJ Compression, and it must be used. Address/Control > Field Compression > and again it must me used. Protocol Field Compression, again must be > used. OEM's > want it all. So every implementation must support it if it is to remain > competitive and make > the score card. This the way the world works. If you present an > option, you can be > guaranteed that nearly every implementation will have it. Those that > don't will not survive. > I'm sorry, am I hearing you correctly? You want to force word alignment, so to do this you negotiate address and control field compression and protocol field compression to save 3 bytes from the header, then use your special IPCP option to add 3 bytes into a different place in the PPP frame (after the protocol field and before the IP packet actually begins) in order to make the IP packet word aligned. I usually try to be polite, but frankly, this is absurd. Thanks, Mike -------------- Mike Thornburg frigate networks 415.903.2266 mthorn@frigate.com http://www.frigate.com/ - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jul 9 15:36:34 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id PAA03489; Wed, 9 Jul 1997 15:36:24 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 9 Jul 1997 15:35:31 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id PAA03439 for ietf-ppp-outgoing; Wed, 9 Jul 1997 15:35:30 -0400 (EDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.42]) by merit.edu (8.8.5/8.8.5) with ESMTP id PAA03431 for ; Wed, 9 Jul 1997 15:35:23 -0400 (EDT) Received: by INET-02-IMC with Internet Mail Service (5.0.1458.49) id <3TB5GNPL>; Wed, 9 Jul 1997 12:35:17 -0700 Message-ID: <114DB67712DCD011A63500805F385DB20E5B87@RED-38-MSG.dns.microsoft.com> From: Paul Martin To: "'C. Harald Koch'" , Paul Martin Cc: "'Mike Thornburg'" , "'Karl Fox'" , ietf-ppp@merit.edu Subject: RE: draft-rfced-info-martin-00.txt Date: Wed, 9 Jul 1997 12:20:55 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Sender: owner-ietf-ppp@merit.edu -----Original Message----- From: C. Harald Koch [SMTP:chk@utcc.utoronto.ca] Sent: Wednesday, July 09, 1997 11:44 AM To: Paul Martin Cc: 'Mike Thornburg'; 'Karl Fox'; ietf-ppp@merit.edu Subject: Re: draft-rfced-info-martin-00.txt In message <114DB67712DCD011A63500805F385DB20E5B83@RED-38-MSG.dns.microsoft.com>, Paul Martin writes: > I take the view that the few bytes saved on the wire (or wireless), is > not worth destroying the word alignment. You've never used PPP without VJ compression on a 9600bps link, have you? Yes and on 1mbps links. For slow links padding does not make sense, but for fast links the memcpy and malloc are too expensive in CPU. Doesn't it make sense to you for these fast links? > I understand what William was trying to accomplish by making it an > option. However, in practice, word alignment in PPP is non-existent. That's because, as I said the first time, people have written *code* to handle the alignment problem, instead of trying to tweak the standard with bizarre padding options. I am sorry you feel it is bizarre. Is this the first time you have ever seen padding in a protocol? I have written code to copy the frame for realignment. I know it is inefficient on fast links. Don't you agree? We're arguing in circles here. Agreed. You have made your point that any changes to the protocol are bad because everything has been thought of already and I disagree on that point. So let's say we agree to disagree. -- Harald - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jul 9 16:09:08 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id QAA04665; Wed, 9 Jul 1997 16:09:06 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 9 Jul 1997 16:08:34 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id QAA04636 for ietf-ppp-outgoing; Wed, 9 Jul 1997 16:08:33 -0400 (EDT) Received: from relay3.smtp.psi.net (relay3.smtp.psi.net [38.8.210.2]) by merit.edu (8.8.5/8.8.5) with ESMTP id QAA04629 for ; Wed, 9 Jul 1997 16:08:23 -0400 (EDT) Received: from wacko.aptis.com by relay3.smtp.psi.net (8.8.3/SMI-5.4-PSI) id QAA27593; Wed, 9 Jul 1997 16:06:40 -0400 (EDT) Received: by aptis.com with Internet Mail Service (5.0.1457.3) id ; Wed, 9 Jul 1997 16:06:31 -0400 Message-ID: From: Marty Del Vecchio To: ietf-ppp@merit.edu Subject: RE: draft-rfced-info-martin-00.txt Date: Wed, 9 Jul 1997 16:06:30 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Sender: owner-ietf-ppp@merit.edu I also have implemented PPP in many... Ah, never mind. > -----Original Message----- > From: William Allen Simpson [SMTP:wsimpson@greendragon.com] > Sent: Tuesday, July 08, 1997 9:07 PM > To: Paul Martin > Cc: ietf-ppp@merit.edu > Subject: Re: draft-rfced-info-martin-00.txt > > > From: Paul Martin > > Are you that slick/smart programmer? I have written PPP for > > embedded systems from scratch (Not steal it from the public domain), > and > > I don't see a way without adding a bunch of code and processing But > > hey, maybe I am not that smart. > > > I, too, have written PPP for consumer products, routers, and embedded > systems. > > Had you done your research, you may have noticed that Karl Fox wrote > another PPP -- the widely used public domain version for Unix.... > > That said, I've ported my PPP code into cellular phones with a mere > 186 > embedded in a fancy ASIC for Viterbi decoding. Very small memory. > Extremely processor limited. Kinda the ultimate "handheld consumer > electronics device". > > I had no problems with header alignment. > > I did not do the VJ expansion on the fly. > > I had no problems with the VJ data copy, as I used a very simple mbuf > structure that pointed into the VJ header buffers and chained the > remainder of the data. > > Oh, yeah, and I did it on both sides of the handheld phone -- on/off > the > air, and in/out the serial cable -- independently. No problem, just a > couple of months of design, and another couple of months of careful > coding, and another couple of months of testing and tweeking.... > > WSimpson@UMich.edu > Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C > 32 > BSimpson@MorningStar.com > Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 > A2 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jul 9 16:09:54 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id QAA04702; Wed, 9 Jul 1997 16:09:51 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 9 Jul 1997 16:09:40 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id QAA04683 for ietf-ppp-outgoing; Wed, 9 Jul 1997 16:09:39 -0400 (EDT) Received: from ns.frigate.com (ns.frigate.com [206.14.208.6]) by merit.edu (8.8.5/8.8.5) with ESMTP id QAA04676 for ; Wed, 9 Jul 1997 16:09:32 -0400 (EDT) Received: from localhost (mthorn@localhost) by ns.frigate.com (8.8.5/8.7.1) with SMTP id NAA09553; Wed, 9 Jul 1997 13:09:34 -0700 (PDT) Date: Wed, 9 Jul 1997 13:09:34 -0700 (PDT) From: Mike Thornburg To: Paul Martin cc: ietf-ppp@merit.edu Subject: RE: draft-rfced-info-martin-00.txt In-Reply-To: <114DB67712DCD011A63500805F385DB20E5B87@RED-38-MSG.dns.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu On Wed, 9 Jul 1997, Paul Martin wrote: > > -----Original Message----- > From: C. Harald Koch [SMTP:chk@utcc.utoronto.ca] > Sent: Wednesday, July 09, 1997 11:44 AM > To: Paul Martin > Cc: 'Mike Thornburg'; 'Karl Fox'; ietf-ppp@merit.edu > Subject: Re: draft-rfced-info-martin-00.txt > > In message > <114DB67712DCD011A63500805F385DB20E5B83@RED-38-MSG.dns.microsoft.com>, > Paul Martin writes: > > I take the view that the few bytes saved on the wire (or > wireless), is > > not worth destroying the word alignment. > > You've never used PPP without VJ compression on a 9600bps link, > have you? > > Yes and on 1mbps links. For slow links padding does not make > sense, but for fast links > the memcpy and malloc are too expensive in CPU. Doesn't it make > sense to you for > these fast links? > Let me understand this: the sole purpose for this new IPCP option you are proposing is so that you can run VJ header compression on a 1mbps link rather than being limited to running VJ on slow links, such as 9600bps? What is the line speed at which it becomes too expensive to run VJ header compression using the sort of equipment you are talking about? Thanks, Mike -------------- Mike Thornburg frigate networks 415.903.2266 mthorn@frigate.com http://www.frigate.com/ - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jul 9 16:12:15 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id QAA04793; Wed, 9 Jul 1997 16:12:13 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 9 Jul 1997 16:11:57 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id QAA04770 for ietf-ppp-outgoing; Wed, 9 Jul 1997 16:11:56 -0400 (EDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.29]) by merit.edu (8.8.5/8.8.5) with ESMTP id QAA04766 for ; Wed, 9 Jul 1997 16:11:50 -0400 (EDT) Received: by mail4.microsoft.com with Internet Mail Service (5.0.1458.49) id <3S417LNL>; Wed, 9 Jul 1997 13:12:23 -0700 Message-ID: <114DB67712DCD011A63500805F385DB20E5B8B@RED-38-MSG.dns.microsoft.com> From: Paul Martin To: "'Mike Thornburg'" , Paul Martin Cc: ietf-ppp@merit.edu Subject: RE: draft-rfced-info-martin-00.txt Date: Wed, 9 Jul 1997 13:11:45 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Sender: owner-ietf-ppp@merit.edu It depends on the CPU, but a single "B" channel on ISDN my be enough on some CPUs. -----Original Message----- From: Mike Thornburg [SMTP:mthorn@frigate.com] Sent: Wednesday, July 09, 1997 1:10 PM To: Paul Martin Cc: ietf-ppp@merit.edu Subject: RE: draft-rfced-info-martin-00.txt On Wed, 9 Jul 1997, Paul Martin wrote: > > -----Original Message----- > From: C. Harald Koch [SMTP:chk@utcc.utoronto.ca] > Sent: Wednesday, July 09, 1997 11:44 AM > To: Paul Martin > Cc: 'Mike Thornburg'; 'Karl Fox'; ietf-ppp@merit.edu > Subject: Re: draft-rfced-info-martin-00.txt > > In message > <114DB67712DCD011A63500805F385DB20E5B83@RED-38-MSG.dns.microsoft.com>, > Paul Martin writes: > > I take the view that the few bytes saved on the wire (or > wireless), is > > not worth destroying the word alignment. > > You've never used PPP without VJ compression on a 9600bps link, > have you? > > Yes and on 1mbps links. For slow links padding does not make > sense, but for fast links > the memcpy and malloc are too expensive in CPU. Doesn't it make > sense to you for > these fast links? > Let me understand this: the sole purpose for this new IPCP option you are proposing is so that you can run VJ header compression on a 1mbps link rather than being limited to running VJ on slow links, such as 9600bps? What is the line speed at which it becomes too expensive to run VJ header compression using the sort of equipment you are talking about? Thanks, Mike -------------- Mike Thornburg frigate networks 415.903.2266 mthorn@frigate.com http://www.frigate.com/ - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jul 9 17:22:12 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id RAA06726; Wed, 9 Jul 1997 17:22:00 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 9 Jul 1997 17:21:21 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id RAA06702 for ietf-ppp-outgoing; Wed, 9 Jul 1997 17:21:21 -0400 (EDT) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by merit.edu (8.8.5/8.8.5) with SMTP id RAA06698 for ; Wed, 9 Jul 1997 17:21:16 -0400 (EDT) Received: from spud.ascend.com (fw-ext.ascend.com [198.4.92.5]) by drawbridge.ascend.com (8.6.12/8.6.12) with ESMTP id OAA07233; Wed, 9 Jul 1997 14:21:12 -0700 Received: from ascend.com by ascend.com with ESMTP id OAA15616; Wed, 9 Jul 1997 14:21:07 -0700 Received: from gump.eng.ascend.com (gump.eng.ascend.com [206.65.212.67]) by wopr.eng.ascend.com (8.6.12/8.6.12) with ESMTP id OAA24252; Wed, 9 Jul 1997 14:20:36 -0700 Received: from carp.morningstar.com.ascend.com (karl@carp.MorningStar.Com [137.175.81.4]) by gump.eng.ascend.com (8.6.12/8.6.12) with SMTP id OAA23006; Wed, 9 Jul 1997 14:20:33 -0700 Date: Wed, 9 Jul 1997 14:20:33 -0700 Message-Id: <199707092120.OAA23006@gump.eng.ascend.com> From: Karl Fox To: Paul Martin Cc: "'Mike Thornburg'" , ietf-ppp@merit.edu Subject: RE: draft-rfced-info-martin-00.txt In-Reply-To: <114DB67712DCD011A63500805F385DB20E5B8B@RED-38-MSG.dns.microsoft.com> References: <114DB67712DCD011A63500805F385DB20E5B8B@RED-38-MSG.dns.microsoft.com> Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ietf-ppp@merit.edu Paul Martin writes: > From: Mike Thornburg [SMTP:mthorn@frigate.com] > Sent: Wednesday, July 09, 1997 1:10 PM > To: Paul Martin > Cc: ietf-ppp@merit.edu > Subject: RE: draft-rfced-info-martin-00.txt ... > Let me understand this: the sole purpose for this new IPCP option > you are proposing is so that you can run VJ header compression on a > 1mbps link rather than being limited to running VJ on slow links, > such as 9600bps? Hmm. Paul, I recommend you go study the VJ compression code and see if you can figure out a way to make it intentionally generate suboptimal packets that always (or almost always) have the data field longword aligned. I suspect it wouldn't be all that hard, plus it would be backward compatible with 100% of existing VJ receivers. -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jul 9 17:28:35 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id RAA06977; Wed, 9 Jul 1997 17:28:28 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 9 Jul 1997 17:28:02 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id RAA06939 for ietf-ppp-outgoing; Wed, 9 Jul 1997 17:28:01 -0400 (EDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.29]) by merit.edu (8.8.5/8.8.5) with ESMTP id RAA06935 for ; Wed, 9 Jul 1997 17:27:55 -0400 (EDT) Received: by mail4.microsoft.com with Internet Mail Service (5.0.1458.49) id <3S417PY6>; Wed, 9 Jul 1997 14:28:32 -0700 Message-ID: <114DB67712DCD011A63500805F385DB20E5B91@RED-38-MSG.dns.microsoft.com> From: Paul Martin To: "'Karl Fox'" , Paul Martin Cc: "'Mike Thornburg'" , ietf-ppp@merit.edu Subject: RE: draft-rfced-info-martin-00.txt Date: Wed, 9 Jul 1997 14:27:49 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Sender: owner-ietf-ppp@merit.edu Now that is an interesting proposal. I will look into it. > -----Original Message----- > From: Karl Fox [SMTP:karl@ascend.com] > Sent: Wednesday, July 09, 1997 2:21 PM > To: Paul Martin > Cc: 'Mike Thornburg'; ietf-ppp@merit.edu > Subject: RE: draft-rfced-info-martin-00.txt > > Paul Martin writes: > > From: Mike Thornburg [SMTP:mthorn@frigate.com] > > Sent: Wednesday, July 09, 1997 1:10 PM > > To: Paul Martin > > Cc: ietf-ppp@merit.edu > > Subject: RE: draft-rfced-info-martin-00.txt > ... > > Let me understand this: the sole purpose for this new IPCP option > > you are proposing is so that you can run VJ header compression on a > > 1mbps link rather than being limited to running VJ on slow links, > > such as 9600bps? > > Hmm. Paul, I recommend you go study the VJ compression code and see > if you can figure out a way to make it intentionally generate > suboptimal packets that always (or almost always) have the data field > longword aligned. I suspect it wouldn't be all that hard, plus it > would be backward compatible with 100% of existing VJ receivers. > -- > Karl Fox, servant of God, employee of Ascend Communications > 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 > 4041 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jul 9 17:39:46 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id RAA07349; Wed, 9 Jul 1997 17:39:44 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 9 Jul 1997 17:39:23 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id RAA07331 for ietf-ppp-outgoing; Wed, 9 Jul 1997 17:39:21 -0400 (EDT) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by merit.edu (8.8.5/8.8.5) with SMTP id RAA07326 for ; Wed, 9 Jul 1997 17:39:14 -0400 (EDT) Received: from spud.ascend.com (fw-ext.ascend.com [198.4.92.5]) by drawbridge.ascend.com (8.6.12/8.6.12) with ESMTP id OAA08159 for ; Wed, 9 Jul 1997 14:39:12 -0700 Received: from ascend.com by ascend.com with ESMTP id OAA16781 for ; Wed, 9 Jul 1997 14:39:07 -0700 Received: from gump.eng.ascend.com (gump.eng.ascend.com [206.65.212.67]) by wopr.eng.ascend.com (8.6.12/8.6.12) with ESMTP id OAA25461 for ; Wed, 9 Jul 1997 14:38:35 -0700 Received: from carp.morningstar.com.ascend.com (karl@carp.MorningStar.Com [137.175.81.4]) by gump.eng.ascend.com (8.6.12/8.6.12) with SMTP id OAA23115 for ; Wed, 9 Jul 1997 14:38:33 -0700 Date: Wed, 9 Jul 1997 14:38:33 -0700 Message-Id: <199707092138.OAA23115@gump.eng.ascend.com> From: Karl Fox To: ietf-ppp@merit.edu Subject: DESE padding implementation poll Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ietf-ppp@merit.edu If you have a DESE implementation, please write to me (karl@ascend.com) and tell me what you do with padding on received packets. Thanks! -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jul 9 18:53:17 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id SAA08714; Wed, 9 Jul 1997 18:53:14 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 9 Jul 1997 18:52:49 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id SAA08694 for ietf-ppp-outgoing; Wed, 9 Jul 1997 18:52:48 -0400 (EDT) Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.8.5/8.8.5) with SMTP id SAA08690 for ; Wed, 9 Jul 1997 18:52:42 -0400 (EDT) Received: from mica.denver.sgi.com (mica.denver.sgi.com [169.238.67.6]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id PAA29234 for <@sgi.engr.sgi.com:ietf-ppp@merit.edu>; Wed, 9 Jul 1997 15:52:40 -0700 env-from (vjs@mica.denver.sgi.com) Received: (from vjs@localhost) by mica.denver.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA05288 for ietf-ppp@merit.edu; Wed, 9 Jul 1997 16:52:37 -0600 Date: Wed, 9 Jul 1997 16:52:37 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199707092252.QAA05288@mica.denver.sgi.com> To: ietf-ppp@merit.edu Subject: RE: draft-rfced-info-martin-00.txt Sender: owner-ietf-ppp@merit.edu > From: Karl Fox > ... > Hmm. Paul, I recommend you go study the VJ compression code and see > if you can figure out a way to make it intentionally generate > suboptimal packets that always (or almost always) have the data field > longword aligned. I suspect it wouldn't be all that hard, plus it > would be backward compatible with 100% of existing VJ receivers. No, that would not help. The whole point of the padding proposal is to force the PPP peer to spend that which it considers precious, bandwidth, so that the requester can save that which almost everyone considers practically free, CPU cycles. Since PPP runs at KHz while CPUs run at MHZ, CPU cycles are free compared to bandwidth. (Yes, except for SONET, ATM, and FR.) The reason people care about VJ compression, protocol and address/control field compression, and the various data compression schemes is that they consider CPU cycles free compared to bandwidth. Mr. Martin is arguing worse than the opposite. He wants to spend the peer's bandwidth to save his CPU cycles. Everyone, please stop treating Mr. Martin with kid golves. His proposal makes neither business nor technical sense. Contrary to his claims, the mere existence of a PPP option guarantees nothing. Most PPP options are not supported by most systems. The literally millions of installed modem and ISDN ports mean that every "consumer" system that implements his proposal will have to be prepared to do things the old way, which means that his proposal will not save even his systems any code. Never mind the unreality of the claim that most ISP's allow, not to mention require, VJ header compression. Never mind that if you are really short of memory and CPU cycles, you would not be passing buffers around, but would collapse and combine the PPP, IP, and TCP state machines. There are many less radical technical solutions to his alignment problem than that, and that do not require changes to protocols. For example, Mr. Simpson's suggestion of using two buffers, one for the {TCP,UDP}/IP headers and the other for the payload solves the alignment problem of the TCP/IP headers far better than Mr. Martin's proposal. Never mind that Mr. Martin's proposal does not address the far more significant alignment problems in real systems, those of data in the TCP payload. Mr. Martin should have taken the hint implicit in the lack of support from the rest of us. He had no business pressuring you or the AD to provide free consulting. The chair is not in charge of what we like. Should I be whining and pounding the table because some of my ideas have not been advanced?--No, of course not, not even notions such as doing authentication in the Establish Phase that has had some (but not enough) multi-vendor support. The purpose of the IETF PPP WG is not to be a vanity press, to pad resumes, or to improve consulting businesses by putting people's names on RFC's. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jul 9 20:00:59 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id UAA10154; Wed, 9 Jul 1997 20:00:52 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 9 Jul 1997 20:00:01 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id UAA10101 for ietf-ppp-outgoing; Wed, 9 Jul 1997 20:00:00 -0400 (EDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.42]) by merit.edu (8.8.5/8.8.5) with ESMTP id TAA10088 for ; Wed, 9 Jul 1997 19:59:50 -0400 (EDT) Received: by INET-02-IMC with Internet Mail Service (5.0.1458.49) id <3TB5G633>; Wed, 9 Jul 1997 16:59:50 -0700 Message-ID: <114DB67712DCD011A63500805F385DB20E5B93@RED-38-MSG.dns.microsoft.com> From: Paul Martin To: "'vjs@mica.denver.sgi.com'" , ietf-ppp@merit.edu Subject: RE: draft-rfced-info-martin-00.txt Date: Wed, 9 Jul 1997 16:59:13 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Sender: owner-ietf-ppp@merit.edu In recent messages, I have tried to tone down a bit, but messages like the one that follows really don't offer any constructive criticism, so here I go again. Sorry Karl. Would you mind filling me in on your background in embedded systems? FWI a workstation is not an embedded system. You make a lot of assumptions which from my extensive embedded experience are not valid. CPU cycles are not free. When a cpu cost you $10.00/unit more and you ship 1 million units a year, well that is $10,000,000.00 /year. In consumer electronics, 1 million units a year in not unreasonable. CPU cycles are nearly free on systems that cost the end user $1000.00 or more because typically the CPU is such a small part of the price. How much are your workstations at SGI? Did you every stop and think to consider that people put CPUs in devices that cost less than $100.00 to build? Simple math tells you that CPU cycles are not free and sometimes are more costly than the bandwidth. If I need to buy a faster processor when I am willing for my embedded platform to give a little bandwidth to save potentially millions of dollars, what side do you think most embedded manufacturers will come down on. I am not asking for consulting services nor do I wish to pad my resume. My resume does not need any padding. If you would like to see it, I will be glad to send it to you. By the way, It is true PPP runs a kHz and CPUs run at MHz but the cost of the nearly the same no matter how much data is squeezed onto it. There are of course exceptions, like CDPD and T1. If I have to use a faster CPU to make my product work, then the cost goes up. Most consumer devices use POTS, which by most accounts are flat rate. Does the phone company charge you by the bit or by the minute? Mine charges by the minute (actually at my house both the analog and ISDN are flat rate except for long distance). If bandwidth is so important to you, the why are you not yelling for the Microsoft compression protocol for PPP be put into a standards track instead of an informational RFC. Before you go off the deep end again, you might do a little research. > -----Original Message----- > From: vjs@mica.denver.sgi.com [SMTP:vjs@mica.denver.sgi.com] > Sent: Wednesday, July 09, 1997 3:53 PM > To: ietf-ppp@merit.edu > Subject: RE: draft-rfced-info-martin-00.txt > > > From: Karl Fox > > > ... > > Hmm. Paul, I recommend you go study the VJ compression code and see > > if you can figure out a way to make it intentionally generate > > suboptimal packets that always (or almost always) have the data > field > > longword aligned. I suspect it wouldn't be all that hard, plus it > > would be backward compatible with 100% of existing VJ receivers. > > No, that would not help. The whole point of the padding proposal is > to > force the PPP peer to spend that which it considers precious, > bandwidth, > so that the requester can save that which almost everyone considers > practically free, CPU cycles. Since PPP runs at KHz while CPUs run at > MHZ, CPU cycles are free compared to bandwidth. (Yes, except for > SONET, ATM, and FR.) The reason people care about VJ compression, > protocol and address/control field compression, and the various data > compression schemes is that they consider CPU cycles free compared to > bandwidth. Mr. Martin is arguing worse than the opposite. He wants > to > spend the peer's bandwidth to save his CPU cycles. > > Everyone, please stop treating Mr. Martin with kid golves. His > proposal makes neither business nor technical sense. Contrary to his > claims, the mere existence of a PPP option guarantees nothing. Most > PPP options are not supported by most systems. The literally millions > of installed modem and ISDN ports mean that every "consumer" system > that > implements his proposal will have to be prepared to do things the old > way, which means that his proposal will not save even his systems any > code. > > Never mind the unreality of the claim that most ISP's allow, not to > mention require, VJ header compression. > > Never mind that if you are really short of memory and CPU cycles, > you would not be passing buffers around, but would collapse and > combine > the PPP, IP, and TCP state machines. There are many less radical > technical solutions to his alignment problem than that, and that do > not > require changes to protocols. For example, Mr. Simpson's suggestion > of > using two buffers, one for the {TCP,UDP}/IP headers and the other for > the payload solves the alignment problem of the TCP/IP headers far > better than Mr. Martin's proposal. Never mind that Mr. Martin's > proposal does not address the far more significant alignment problems > in real systems, those of data in the TCP payload. > > Mr. Martin should have taken the hint implicit in the lack of support > from the rest of us. He had no business pressuring you or the AD to > provide free consulting. The chair is not in charge of what we like. > Should I be whining and pounding the table because some of my ideas > have not been advanced?--No, of course not, not even notions such as > doing authentication in the Establish Phase that has had some (but not > enough) multi-vendor support. > > The purpose of the IETF PPP WG is not to be a vanity press, to pad > resumes, or to improve consulting businesses by putting people's names > on RFC's. > > > Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jul 9 21:26:39 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id VAA11883; Wed, 9 Jul 1997 21:26:36 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 9 Jul 1997 21:25:37 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id VAA11832 for ietf-ppp-outgoing; Wed, 9 Jul 1997 21:25:37 -0400 (EDT) Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.8.5/8.8.5) with SMTP id VAA11828 for ; Wed, 9 Jul 1997 21:25:32 -0400 (EDT) Received: from mica.denver.sgi.com (mica.denver.sgi.com [169.238.67.6]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id SAA22307 for <@sgi.engr.sgi.com:ietf-ppp@merit.edu>; Wed, 9 Jul 1997 18:24:10 -0700 env-from (vjs@mica.denver.sgi.com) Received: (from vjs@localhost) by mica.denver.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA05930 for ietf-ppp@merit.edu; Wed, 9 Jul 1997 19:24:04 -0600 Date: Wed, 9 Jul 1997 19:24:04 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199707100124.TAA05930@mica.denver.sgi.com> To: ietf-ppp@merit.edu Subject: RE: draft-rfced-info-martin-00.txt Sender: owner-ietf-ppp@merit.edu > From: Paul Martin > In recent messages, I have tried to tone down a bit, but messages like > the one that follows really don't offer any constructive criticism, so > here > I go again. Sorry Karl. So why didn't you include even one technical point among repetitions of your claims to expertise and unsupported assertions about costs of CPUs and RBOC tariffs? > Would you mind filling me in on your background in embedded systems? Comparing resumes is irrelevant. However, since you asked, I've been earning a living as a programmer since the 1960's, when computers were a little smaller. My first computer used accoustic delay lines, and its big blocks of memory consisted of seventeen (17) lines each of 256 22 bit words. I suspect that PB-250 with the "extra memory option," was far slower (3.012 millisecond cycle time) and far smaller (logically but not physically) than anything you have encountered. By coincidence, much of my code for that computer involved moving data over phone lines. It was slower than the 8051/etc's I used years later for other projects. I suspect the first mainframes for which I wrote code in the old days had slower CPU cycle times and less RAM than your embedded systems. Never mind the multi-user, multi-processing operating system I did for large (128 KByte) microprocessor based business systems. In recent years, I've done things such as write code that lived purely inside an AMD 29K 8K on-chip cache and treated the 192 registers as memory--I suspect a more stringent limitation than your embedded PPP systems. Another effort of mine in the early 1970's was a full, 2-pass assembler that could assemble itself, including producing a listing, using 1024 12-bit words for both program and data, and the only external storage was for the source, output, and listing (i.e. no overlays). I also wrote SGI's PPP code from scratch, without reading much more than the copyright notices on the freeware, because of those notices and other considerations. (Contrary to your statement, as far as I know, there is no "public domain" PPP code, although there is some freeware.) > FWI a workstation is not an embedded system. That is true, but as irrelevant as the fact that an SGI/Cray supercomputer is also not an embedded system. Well, maybe not. Did you ever code for CPUs like as the PP's on CDC 6000's? I bet your embedded systems are 100 times larger and faster. > You make a lot of assumptions which from my extensive embedded > experience > are not valid. CPU cycles are not free. When a cpu cost you > $10.00/unit more > and you ship 1 million units a year, well that is $10,000,000.00 /year. > In consumer > electronics, 1 million units a year in not unreasonable. I did not say CPU cycles are free, but that they are free compared to bandwidth. Note also Silicon Graphics also ships more than enough units of some kinds of computers to make $10/unit an issue that can significantly affect your reputation inside the company. You repeatedly claim to have "extensive embedded experience," but continue to make statements that in my experience (about which I try to make few claims) are not valid. > ... > workstations at SGI? Did you every stop and think to consider that > people put > CPUs in devices that cost less than $100.00 to build? Yes, as have many of the rest of us. What does that have to do with which technical or business considerations driving protocol design? > ... > Simple math tells you that CPU cycles are not free and sometimes are > more costly than the bandwidth. Maybe in your particular case that is true. I doubt it, but for the sake of argument will agree based on the assumption that you know more about your design target than I. In any case, your proposal involves requiring other systems to spend their CPU cycles and bandwidth so that you can avoid spending CPU cycles or properly understanding your programming problem. Instead of telling us how much more you know than anyone else, please say why Mr. Simpson's solution does not work. If you did not understand it, or my point about collapsing the state machines (which is actually a variation on Mr. Fox's theme), feel free to ask for clarification. I've found that claiming ignorance wins more respect than assertions of omniscience. > ... > I am not asking for consulting services On the contrary, your demand that that AD force Mr. Fox to review your proposal was a demand for a free technical evaluation and free consulting. Instead of commenting on your proposal, Mr. Fox should simply have asked for a second from other than Microsoft, and then let it die for lack of a second. > nor do I wish to pad my resume. > My resume does not need any padding. If you would like to see it, I > will > be glad to send it to you. As I said above, resume battles are irrelevant. You have repeatedly claimed that you are vastly more experienced and knowledgable than the rest of us. However, every time you make a technical or business statement, you say things that sound false to me. > By the way, It is true PPP runs a kHz and CPUs run at MHz but the cost > of the nearly the same no matter how much data is squeezed onto it. I cannot make any sense of that sentence, particularly in light of your other comments about the cost of CPU cycles. > There > are of course exceptions, like CDPD and T1. If I have to use a faster > CPU > to make my product work, then the cost goes up. Most consumer devices > use POTS, which by most accounts are flat rate. > > Does the phone company charge you by the bit or by the minute? Mine > charges by the minute (actually at my house both the analog and ISDN are > flat rate except for long distance). Phone company tarriffs have practically infinitely variations. My PPP code is run in places that charge per call and/or per minute and/or various forms of flat/rate. So what? The costs the phone companies charge have nothing to do with the sense of "bandwidth is precious." In this context, RBOC and PTT pricing is irrelevant. > If bandwidth is so important to you, the why are you not yelling for the > Microsoft compression protocol for PPP be put into a standards track > instead of an informational RFC. Why would I advocate such a silly thing like that? My name is already on a compression RFC that compresses significantly better than MicroSoft's strange varient of LZS. If I were to pick LZS instead of LZW or LZ77, despite the worse performance of LZW (e.g. perhaps because I wanted to use STAC's silicon or wanted to interoperate with some vendors that do only LZS), I'd go with a standard version of LZS. > Before you go off the deep end again, you might do a little research. That is good advice. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jul 9 22:57:06 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id WAA13641; Wed, 9 Jul 1997 22:56:49 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 9 Jul 1997 22:56:16 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id WAA13620 for ietf-ppp-outgoing; Wed, 9 Jul 1997 22:56:15 -0400 (EDT) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by merit.edu (8.8.5/8.8.5) with SMTP id WAA13613 for ; Wed, 9 Jul 1997 22:56:08 -0400 (EDT) Received: from spud.ascend.com (fw-ext.ascend.com [198.4.92.5]) by drawbridge.ascend.com (8.6.12/8.6.12) with ESMTP id TAA21389; Wed, 9 Jul 1997 19:56:07 -0700 Received: from ascend.com by ascend.com with ESMTP id TAA27105; Wed, 9 Jul 1997 19:56:06 -0700 Received: from gump.eng.ascend.com (gump.eng.ascend.com [206.65.212.67]) by wopr.eng.ascend.com (8.6.12/8.6.12) with ESMTP id TAA18236; Wed, 9 Jul 1997 19:55:35 -0700 Received: from carp.morningstar.com.ascend.com (karl@carp.MorningStar.Com [137.175.81.4]) by gump.eng.ascend.com (8.6.12/8.6.12) with SMTP id TAA25295; Wed, 9 Jul 1997 19:55:33 -0700 Date: Wed, 9 Jul 1997 19:55:33 -0700 Message-Id: <199707100255.TAA25295@gump.eng.ascend.com> From: Karl Fox To: ietf-ppp@merit.edu Subject: Re: DESE padding implementation poll Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ietf-ppp@merit.edu Someone asked me: > If you mean SDP? or do you mean what happens to the SDP padding after it > is stripped. Eg passed up to the user or cleared? I mean do you expect it to be SDP, or do you ignore it, or what? Do you look at the protocol to decide what to do? Generally, what do you do with respect to padding after you've decrypted a packet? > On Wed, 9 Jul 1997, Karl Fox wrote: > > > If you have a DESE implementation, please write to me > > (karl@ascend.com) and tell me what you do with padding on received > > packets. Thanks! > > -- > > Karl Fox, servant of God, employee of Ascend Communications > > 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jul 9 23:25:38 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id XAA14443; Wed, 9 Jul 1997 23:25:36 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 9 Jul 1997 23:25:15 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id XAA14410 for ietf-ppp-outgoing; Wed, 9 Jul 1997 23:25:14 -0400 (EDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.29]) by merit.edu (8.8.5/8.8.5) with ESMTP id XAA14395 for ; Wed, 9 Jul 1997 23:25:09 -0400 (EDT) Received: by mail4.microsoft.com with Internet Mail Service (5.0.1458.49) id <3S418AK3>; Wed, 9 Jul 1997 20:25:43 -0700 Message-ID: <114DB67712DCD011A63500805F385DB20E5B9B@RED-38-MSG.dns.microsoft.com> From: Paul Martin To: vjs@mica.denver.sgi.com, ietf-ppp@merit.edu Subject: RE: draft-rfced-info-martin-00.txt Date: Wed, 9 Jul 1997 20:25:01 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Sender: owner-ietf-ppp@merit.edu You know I was tempted beyond belief to respond to this, but I am not going to dignify this series of personal attacks with a response. As Karl said, this is getting a little personal. I would like to point out again, I asked for comments, not passionate flames. If you wish to flame me, do by email, and I will respond by email. Save some bandwidth in this group. I am sure everyone is growing tired of these personal attack threads. If however you would like to join in a true discussion, lets do it here as this is the place for it. Thanks to all those who support my idea, but do not wish to present it here because of these attacks. I will continue to respond via email. > -----Original Message----- > From: vjs@mica.denver.sgi.com [SMTP:vjs@mica.denver.sgi.com] > Sent: Wednesday, July 09, 1997 6:24 PM > To: ietf-ppp@merit.edu > Subject: RE: draft-rfced-info-martin-00.txt > > So why didn't you include even one technical point among repetitions > of your claims to expertise and unsupported assertions about costs > of CPUs and RBOC tariffs? > [Paul Martin] Rest excluded for saving space - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jul 10 08:36:52 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id IAA19991; Thu, 10 Jul 1997 08:35:46 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 10 Jul 1997 08:30:18 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id IAA19905 for ietf-ppp-outgoing; Thu, 10 Jul 1997 08:30:18 -0400 (EDT) Received: from rnd-gate.rad.co.il (rnd-gate.rad.co.il [207.232.32.14]) by merit.edu (8.8.5/8.8.5) with ESMTP id IAA19900 for ; Thu, 10 Jul 1997 08:30:07 -0400 (EDT) Received: from smtp-gateway.rad.co.il ([176.189.111.1]) by rnd-gate.rad.co.il (8.7.3/8.7.3) with SMTP id PAA08182 for ; Thu, 10 Jul 1997 15:18:43 +0300 (IDT) Received: by smtp-gateway.rad.co.il with Microsoft Mail id <33C4E4CB@smtp-gateway.rad.co.il>; Thu, 10 Jul 97 15:34:03 EST From: Michael Liwerant To: "'ietf_ppp'" Subject: CHAP MD5 outside USA Date: Thu, 10 Jul 97 15:23:00 EST Message-ID: <33C4E4CB@smtp-gateway.rad.co.il> X-Mailer: Microsoft Mail V3.0 Sender: owner-ietf-ppp@merit.edu Hi Guys Can somone provide me with information whether the MD5 algorithm (used also by the PPP CHAP authentication protocol) is implemented in devices which are operated outside USA ? Thank you for helping - Michael Liwerant. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jul 10 09:32:45 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id JAA21004; Thu, 10 Jul 1997 09:32:44 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 10 Jul 1997 09:31:11 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id JAA20975 for ietf-ppp-outgoing; Thu, 10 Jul 1997 09:31:10 -0400 (EDT) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by merit.edu (8.8.5/8.8.5) with SMTP id JAA20965 for ; Thu, 10 Jul 1997 09:31:05 -0400 (EDT) Received: from spud.ascend.com (fw-ext.ascend.com [198.4.92.5]) by drawbridge.ascend.com (8.6.12/8.6.12) with ESMTP id GAA03178; Thu, 10 Jul 1997 06:30:49 -0700 Received: from ascend.com by ascend.com with ESMTP id GAA16097; Thu, 10 Jul 1997 06:30:47 -0700 Received: from gump.eng.ascend.com (gump.eng.ascend.com [206.65.212.67]) by wopr.eng.ascend.com (8.6.12/8.6.12) with ESMTP id GAA18560; Thu, 10 Jul 1997 06:30:17 -0700 Received: from carp.morningstar.com.ascend.com (karl@carp.MorningStar.Com [137.175.81.4]) by gump.eng.ascend.com (8.6.12/8.6.12) with SMTP id GAA26720; Thu, 10 Jul 1997 06:30:15 -0700 Date: Thu, 10 Jul 1997 06:30:15 -0700 Message-Id: <199707101330.GAA26720@gump.eng.ascend.com> From: Karl Fox To: Michael Liwerant Cc: "'ietf_ppp'" Subject: CHAP MD5 outside USA In-Reply-To: <33C4E4CB@smtp-gateway.rad.co.il> References: <33C4E4CB@smtp-gateway.rad.co.il> Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ietf-ppp@merit.edu Michael Liwerant writes: > Can somone provide me with information whether the MD5 algorithm (used > also by the PPP CHAP authentication protocol) is implemented in devices > which are operated outside USA ? The company I used to work for got an export license without difficulty for a PPP product that spoke CHAP with MD5. Our exports were unrestricted except for the 7 "taboo" countries (North Korea, Libya, etc.). -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jul 10 09:52:19 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id JAA21296; Thu, 10 Jul 1997 09:52:17 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 10 Jul 1997 09:51:57 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id JAA21275 for ietf-ppp-outgoing; Thu, 10 Jul 1997 09:51:57 -0400 (EDT) Received: from databus.databus.com (databus.databus.com [198.186.154.34]) by merit.edu (8.8.5/8.8.5) with SMTP id JAA21268 for ; Thu, 10 Jul 1997 09:51:49 -0400 (EDT) From: Barney Wolff To: Date: Thu, 10 Jul 1997 09:49 EDT Subject: Re: CHAP MD5 outside USA Content-Type: text/plain Message-ID: <33c4e8f20.629b@databus.databus.com> Sender: owner-ietf-ppp@merit.edu C code for MD5 is contained in RFC1321, which is not export-restricted. > Date: Thu, 10 Jul 1997 06:30:15 -0700 > From: Karl Fox > To: Michael Liwerant > Cc: "'ietf_ppp'" > Subject: CHAP MD5 outside USA > Reply-To: Karl Fox > Content-Length: 562 > > Michael Liwerant writes: > > Can somone provide me with information whether the MD5 algorithm (used > > also by the PPP CHAP authentication protocol) is implemented in devices > > which are operated outside USA ? > > The company I used to work for got an export license without > difficulty for a PPP product that spoke CHAP with MD5. Our exports > were unrestricted except for the 7 "taboo" countries (North Korea, > Libya, etc.). > -- > Karl Fox, servant of God, employee of Ascend Communications > 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 > > Barney Wolff - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jul 10 11:53:10 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id LAA24839; Thu, 10 Jul 1997 11:52:57 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 10 Jul 1997 11:52:41 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id LAA24818 for ietf-ppp-outgoing; Thu, 10 Jul 1997 11:52:40 -0400 (EDT) Received: from janus.3com.com (janus.3com.com [129.213.128.99]) by merit.edu (8.8.5/8.8.5) with ESMTP id LAA24814 for ; Thu, 10 Jul 1997 11:52:35 -0400 (EDT) From: Paul_Douglas@3com.com Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by janus.3com.com (8.8.2/8.8.5) with ESMTP id IAA28228 for ; Thu, 10 Jul 1997 08:52:03 -0700 (PDT) Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104]) by new-york.3com.com (8.8.2/8.8.5) with SMTP id IAA11560 for ; Thu, 10 Jul 1997 08:51:05 -0700 (PDT) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v1.1 (385.6 5-6-1997)) id 082564D0.005C2742 ; Thu, 10 Jul 1997 08:46:33 -0800 X-Lotus-FromDomain: 3COM To: ietf-ppp@merit.edu Message-ID: <852564D0.005B83AB.00@hqoutbound.ops.3com.com> Date: Thu, 10 Jul 1997 12:48:50 -0400 Subject: BAP/BACP Testing Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-ppp@merit.edu Hello.. I'm in the process of testing our new BAP/BACP software and I'm wondering if anyone is interested in a bit of interoperability testing? If you are please send mail to Paul_Douglas@3com.com or give me a call at 732-332-2044. Thanks much, Paul - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jul 10 13:31:22 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id NAA27045; Thu, 10 Jul 1997 13:31:06 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 10 Jul 1997 13:30:37 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id NAA27019 for ietf-ppp-outgoing; Thu, 10 Jul 1997 13:30:36 -0400 (EDT) Received: from hank.questra.com (questra.com [208.133.210.22]) by merit.edu (8.8.5/8.8.5) with ESMTP id NAA27015 for ; Thu, 10 Jul 1997 13:30:32 -0400 (EDT) Received: from redsox.roc.questra.com ([208.133.210.76]) by hank.questra.com (8.8.5/8.8.5) with ESMTP id NAA01817; Thu, 10 Jul 1997 13:28:08 -0400 (EDT) Received: from niobe ([10.25.5.1]) by redsox.roc.questra.com (8.8.5/8.8.5) with ESMTP id NAA24761; Thu, 10 Jul 1997 13:27:13 -0400 (EDT) Message-Id: <199707101727.NAA24761@redsox.roc.questra.com> From: "Matthew S Sacks" To: Cc: , Matthew.Sacks@redsox.roc.questra.com Subject: Fw: Hello, question about RFC 1661 Date: Thu, 10 Jul 1997 13:30:53 -0700 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu In section 1 of RFC 1661, it specifies that PPP for a "sumultaneous" bidirectional full-duplex link. In an older version, RFC1331, it was even for explicity stated that a "FULL-DUPLEX" is required. It is rather obvious that a simplex line won't work. But what about what the textbooks used to call (at least when I went to school) a half-duplex line. This simply means that at a low level, the communications is alternating in direction; bidirectional but not simultaneous. Would this break PPP somehow? Or does full-duplex, for these purposes, simply mean bidirectional? Matthew Sacks ---------- > From: William Allen Simpson > To: Matthew S Sacks > Subject: Re: Hello, question about RFC 1661 > Date: Thursday, July 10, 1997 9:12 AM > > Try ietf-ppp@merit.edu for general questions from implementors. Try > your local ISP for user support. > > WSimpson@UMich.edu > Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 > BSimpson@MorningStar.com > Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jul 10 13:39:39 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id NAA27204; Thu, 10 Jul 1997 13:39:38 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 10 Jul 1997 13:39:28 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id NAA27183 for ietf-ppp-outgoing; Thu, 10 Jul 1997 13:39:28 -0400 (EDT) Received: from hank.questra.com (hank.questra.com [208.133.210.22]) by merit.edu (8.8.5/8.8.5) with ESMTP id NAA27177 for ; Thu, 10 Jul 1997 13:39:23 -0400 (EDT) Received: from redsox.roc.questra.com ([208.133.210.76]) by hank.questra.com (8.8.5/8.8.5) with ESMTP id NAA01881; Thu, 10 Jul 1997 13:37:09 -0400 (EDT) Received: from niobe ([10.25.5.1]) by redsox.roc.questra.com (8.8.5/8.8.5) with ESMTP id NAA24789; Thu, 10 Jul 1997 13:36:15 -0400 (EDT) Message-Id: <199707101736.NAA24789@redsox.roc.questra.com> From: "Matthew S Sacks" To: Cc: Subject: Fw: Hello, question about RFC 1661 Date: Thu, 10 Jul 1997 13:39:52 -0700 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu ---------- > From: Matthew S Sacks > To: ietf-ppp@merit.edu > Cc: wsimpson@greendragon.com; Matthew.Sacks@redsox.roc.questra.com > Subject: Fw: Hello, question about RFC 1661 > Date: Thursday, July 10, 1997 1:30 PM > > > In section 1 of RFC 1661, it specifies that PPP for a "sumultaneous" > bidirectional full-duplex link. In an older version, RFC1331, it was even > for explicity stated that a "FULL-DUPLEX" is required. It is rather > obvious that a simplex line won't work. But what about what the textbooks > used to call (at least when I went to school) a half-duplex line. This > simply means that at a low level, the communications is alternating in > direction; bidirectional but not simultaneous. Would this break PPP > somehow? > > Or does full-duplex, for these purposes, simply mean bidirectional? > > Matthew Sacks > > ---------- > > From: William Allen Simpson > > To: Matthew S Sacks > > Subject: Re: Hello, question about RFC 1661 > > Date: Thursday, July 10, 1997 9:12 AM > > > > Try ietf-ppp@merit.edu for general questions from implementors. Try > > your local ISP for user support. > > > > WSimpson@UMich.edu > > Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 > > BSimpson@MorningStar.com > > Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jul 10 13:44:21 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id NAA27322; Thu, 10 Jul 1997 13:44:20 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 10 Jul 1997 13:44:01 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id NAA27296 for ietf-ppp-outgoing; Thu, 10 Jul 1997 13:44:00 -0400 (EDT) Received: from SantaClara01.pop.internex.net (santaclara01.pop.InterNex.Net [205.158.3.18]) by merit.edu (8.8.5/8.8.5) with ESMTP id NAA27292 for ; Thu, 10 Jul 1997 13:43:51 -0400 (EDT) Received: from flowpnt.flowpoint.com ([192.84.210.69]) by SantaClara01.pop.internex.net (post.office MTA v1.9.3 ID# 0-11030) with SMTP id AAA23829; Thu, 10 Jul 1997 10:43:44 -0700 Received: from zeus.flowpoint.com (ws67.flowpoint.com) by flowpnt.flowpoint.com (4.1/SMI-4.1) id AA02540; Thu, 10 Jul 97 10:05:37 PDT Received: by zeus.flowpoint.com (4.1/SMI-4.1) id AA01404; Thu, 10 Jul 97 10:05:37 PDT Date: Thu, 10 Jul 1997 10:05:37 -0700 (PDT) From: Philip Rakity X-Sender: pmr@zeus To: Karl Fox Cc: ietf-ppp@merit.edu Subject: Re: DESE padding implementation poll In-Reply-To: <199707100255.TAA25295@gump.eng.ascend.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Karl, We look for SDP. regards, Philip Rakity FlowPoint On Wed, 9 Jul 1997, Karl Fox wrote: > Someone asked me: > > If you mean SDP? or do you mean what happens to the SDP padding after it > > is stripped. Eg passed up to the user or cleared? > > I mean do you expect it to be SDP, or do you ignore it, or what? Do > you look at the protocol to decide what to do? Generally, what do you > do with respect to padding after you've decrypted a packet? > > > On Wed, 9 Jul 1997, Karl Fox wrote: > > > > > If you have a DESE implementation, please write to me > > > (karl@ascend.com) and tell me what you do with padding on received > > > packets. Thanks! > > > -- > > > Karl Fox, servant of God, employee of Ascend Communications > > > 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 > -- > Karl Fox, servant of God, employee of Ascend Communications > 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 > > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jul 10 14:22:38 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id OAA28315; Thu, 10 Jul 1997 14:22:36 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 10 Jul 1997 14:22:14 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id OAA28281 for ietf-ppp-outgoing; Thu, 10 Jul 1997 14:22:13 -0400 (EDT) Received: from shiva-dev.shiva.com (shiva.shiva.com [192.80.57.1]) by merit.edu (8.8.5/8.8.5) with ESMTP id OAA28274 for ; Thu, 10 Jul 1997 14:22:08 -0400 (EDT) Received: (jas@localhost) by shiva-dev.shiva.com (8.7.6/8.6.4) id OAA14410; Thu, 10 Jul 1997 14:15:30 -0400 (EDT) Date: Thu, 10 Jul 1997 14:15:30 -0400 (EDT) From: John Shriver Message-Id: <199707101815.OAA14410@shiva-dev.shiva.com> To: msacks@questra.com CC: ietf-ppp@merit.edu In-reply-to: <199707101727.NAA24761@redsox.roc.questra.com> (msacks@questra.com) Subject: Re: Fw: Hello, question about RFC 1661 Sender: owner-ietf-ppp@merit.edu Many modems these days are half-duplex on the wire, but full-duplex at the user interface (RS-232 port). From the point of view of PPP, they are all full-duplex. So long as they are smart enough to never wedge, PPP is happy. The true half-duplex modems are absolutely obsolete. (Bell 202, 208, 209, etc.) They were nearly obsolete when we started designing PPP, everyone was using AT&T DDS 56 Kb. There is no protocol support in PPP for deciding when to tell those dumb half-duplex modems to turn around. This is what made PPP simple enough for the original 3-4 hardware vendors (who committed to implement PPP ~10 years ago) to be willing to support it. (None of their existing proprietary protocols supported half-duplex either. It was not a complication they needed.) I could be cheeky and suggest you look into SNA if you want to use half-duplex modems. (It is still a fundementally half-duplex protocol.) Communications textbooks tend to be very dated. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jul 10 14:32:16 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id OAA28640; Thu, 10 Jul 1997 14:32:09 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 10 Jul 1997 14:31:23 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id OAA28585 for ietf-ppp-outgoing; Thu, 10 Jul 1997 14:31:23 -0400 (EDT) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by merit.edu (8.8.5/8.8.5) with SMTP id OAA28581 for ; Thu, 10 Jul 1997 14:31:18 -0400 (EDT) Received: from spud.ascend.com (fw-ext.ascend.com [198.4.92.5]) by drawbridge.ascend.com (8.6.12/8.6.12) with ESMTP id LAA17991; Thu, 10 Jul 1997 11:31:08 -0700 Received: from ascend.com by ascend.com with ESMTP id LAA02838; Thu, 10 Jul 1997 11:31:03 -0700 Received: from gump.eng.ascend.com (gump.eng.ascend.com [206.65.212.67]) by wopr.eng.ascend.com (8.6.12/8.6.12) with ESMTP id LAA05857; Thu, 10 Jul 1997 11:30:32 -0700 Received: from carp.morningstar.com.ascend.com (karl@carp.MorningStar.Com [137.175.81.4]) by gump.eng.ascend.com (8.6.12/8.6.12) with SMTP id LAA28056; Thu, 10 Jul 1997 11:30:30 -0700 Date: Thu, 10 Jul 1997 11:30:30 -0700 Message-Id: <199707101830.LAA28056@gump.eng.ascend.com> From: Karl Fox To: "Matthew S Sacks" Cc: Subject: Fw: Hello, question about RFC 1661 In-Reply-To: <199707101727.NAA24761@redsox.roc.questra.com> References: <199707101727.NAA24761@redsox.roc.questra.com> Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ietf-ppp@merit.edu The half duplex protocols that I worked with long ago all had mechanisms built in that they used to decide when to turn the line around. PPP doesn't have any such mechanism. You can't simply alternate packets, because you're not guaranteed to have a packet to send. You can't just send until your queue is empty, because your queue might never empty. You'd have to come up with some new mechanism to handle the modem turnaround. Matthew S. Sacks writes: > In section 1 of RFC 1661, it specifies that PPP for a "sumultaneous" > bidirectional full-duplex link. In an older version, RFC1331, it was even > for explicity stated that a "FULL-DUPLEX" is required. It is rather > obvious that a simplex line won't work. But what about what the textbooks > used to call (at least when I went to school) a half-duplex line. This > simply means that at a low level, the communications is alternating in > direction; bidirectional but not simultaneous. Would this break PPP > somehow? > > Or does full-duplex, for these purposes, simply mean bidirectional? > > Matthew Sacks > > ---------- > > From: William Allen Simpson > > To: Matthew S Sacks > > Subject: Re: Hello, question about RFC 1661 > > Date: Thursday, July 10, 1997 9:12 AM > > > > Try ietf-ppp@merit.edu for general questions from implementors. Try > > your local ISP for user support. > > > > WSimpson@UMich.edu > > Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 > > BSimpson@MorningStar.com > > Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jul 10 14:54:49 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id OAA29224; Thu, 10 Jul 1997 14:54:48 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 10 Jul 1997 14:54:35 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id OAA29204 for ietf-ppp-outgoing; Thu, 10 Jul 1997 14:54:34 -0400 (EDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.42]) by merit.edu (8.8.5/8.8.5) with ESMTP id OAA29200 for ; Thu, 10 Jul 1997 14:54:28 -0400 (EDT) Received: by INET-02-IMC with Internet Mail Service (5.0.1458.49) id <3VDLQTQ5>; Thu, 10 Jul 1997 11:54:29 -0700 Message-ID: <114DB67712DCD011A63500805F385DB20E5BA3@RED-38-MSG.dns.microsoft.com> From: Paul Martin To: "'Matthew S Sacks'" Cc: ietf-ppp@merit.edu Subject: RE: Hello, question about RFC 1661 Date: Thu, 10 Jul 1997 11:35:25 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Sender: owner-ietf-ppp@merit.edu The only restraint for using a half-duplex medium is that you are forced to determine when to transmit and when to receive. This is not in the protocol. However, having said that, there is no real restriction on the medium being half or full duplex. It won't break the protocol. I expect that you have some underlying protocol that will do the half duplex "funny stuff" and that PPP will be completely unaware of the medium. If this is true, then the only thing that will be affected is performance. > -----Original Message----- > From: Matthew S Sacks [SMTP:msacks@questra.com] > Sent: Thursday, July 10, 1997 1:31 PM > To: ietf-ppp@merit.edu > Cc: wsimpson@greendragon.com; Matthew.Sacks@redsox.roc.questra.com > Subject: Fw: Hello, question about RFC 1661 > > > In section 1 of RFC 1661, it specifies that PPP for a "sumultaneous" > bidirectional full-duplex link. In an older version, RFC1331, it was > even > for explicity stated that a "FULL-DUPLEX" is required. It is rather > obvious that a simplex line won't work. But what about what the > textbooks > used to call (at least when I went to school) a half-duplex line. > This > simply means that at a low level, the communications is alternating in > direction; bidirectional but not simultaneous. Would this break PPP > somehow? > > Or does full-duplex, for these purposes, simply mean bidirectional? > > Matthew Sacks > > ---------- > > From: William Allen Simpson > > To: Matthew S Sacks > > Subject: Re: Hello, question about RFC 1661 > > Date: Thursday, July 10, 1997 9:12 AM > > > > Try ietf-ppp@merit.edu for general questions from implementors. Try > > your local ISP for user support. > > > > WSimpson@UMich.edu > > Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C > 32 > > BSimpson@MorningStar.com > > Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 > A2 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jul 10 16:45:20 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id QAA01941; Thu, 10 Jul 1997 16:45:13 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 10 Jul 1997 16:44:12 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id QAA01901 for ietf-ppp-outgoing; Thu, 10 Jul 1997 16:44:11 -0400 (EDT) Received: from SantaClara01.pop.internex.net (santaclara01.pop.InterNex.Net [205.158.3.18]) by merit.edu (8.8.5/8.8.5) with ESMTP id QAA01897 for ; Thu, 10 Jul 1997 16:44:05 -0400 (EDT) Received: from flowpnt.flowpoint.com ([192.84.210.69]) by SantaClara01.pop.internex.net (post.office MTA v1.9.3 ID# 0-11030) with SMTP id AAA6135; Thu, 10 Jul 1997 13:43:50 -0700 Received: from Roger (ws107.flowpoint.com) by flowpnt.flowpoint.com (4.1/SMI-4.1) id AA02818; Thu, 10 Jul 97 12:59:32 PDT Received: by Roger with Microsoft Mail id <01BC8D2F.CD1954E0@Roger>; Thu, 10 Jul 1997 12:50:10 -0700 Message-Id: <01BC8D2F.CD1954E0@Roger> From: Philippe Roger To: Matthew S Sacks Cc: "ietf-ppp@merit.edu" Subject: RE: Hello, question about RFC 1661 Date: Thu, 10 Jul 1997 12:50:09 -0700 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu There is a an X.25 variant that implements a half-duplex protocol entirely below the LAPB layer (the layer 2 of the X.25 stack): this is defined in X.32. I don't recall that the method used by X.32 to turn around the modem (i.e. when and for how long) was X.25 specific so you might want to take a look. Philippe Roger ---------- From: Karl Fox[SMTP:karl@ascend.com] Sent: Thursday, July 10, 1997 11:30 AM To: Matthew S Sacks Cc: ietf-ppp@merit.edu Subject: Fw: Hello, question about RFC 1661 The half duplex protocols that I worked with long ago all had mechanisms built in that they used to decide when to turn the line around. PPP doesn't have any such mechanism. You can't simply alternate packets, because you're not guaranteed to have a packet to send. You can't just send until your queue is empty, because your queue might never empty. You'd have to come up with some new mechanism to handle the modem turnaround. Matthew S. Sacks writes: > In section 1 of RFC 1661, it specifies that PPP for a "sumultaneous" > bidirectional full-duplex link. In an older version, RFC1331, it was even > for explicity stated that a "FULL-DUPLEX" is required. It is rather > obvious that a simplex line won't work. But what about what the textbooks > used to call (at least when I went to school) a half-duplex line. This > simply means that at a low level, the communications is alternating in > direction; bidirectional but not simultaneous. Would this break PPP > somehow? > > Or does full-duplex, for these purposes, simply mean bidirectional? > > Matthew Sacks > > ---------- > > From: William Allen Simpson > > To: Matthew S Sacks > > Subject: Re: Hello, question about RFC 1661 > > Date: Thursday, July 10, 1997 9:12 AM > > > > Try ietf-ppp@merit.edu for general questions from implementors. Try > > your local ISP for user support. > > > > WSimpson@UMich.edu > > Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 > > BSimpson@MorningStar.com > > Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jul 10 17:26:21 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id RAA03125; Thu, 10 Jul 1997 17:26:20 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 10 Jul 1997 17:25:55 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id RAA03091 for ietf-ppp-outgoing; Thu, 10 Jul 1997 17:25:54 -0400 (EDT) Received: from vangogh.CS.Berkeley.EDU (vangogh.CS.Berkeley.EDU [128.32.33.5]) by merit.edu (8.8.5/8.8.5) with ESMTP id RAA03087 for ; Thu, 10 Jul 1997 17:25:49 -0400 (EDT) Received: (from sklower@localhost) by vangogh.CS.Berkeley.EDU (8.7.Beta.2/8.7.Beta.2) id OAA17241; Thu, 10 Jul 1997 14:24:42 -0700 (PDT) Date: Thu, 10 Jul 1997 14:24:42 -0700 (PDT) From: Keith Sklower Message-Id: <199707102124.OAA17241@vangogh.CS.Berkeley.EDU> To: karl@ascend.com, pmr@flowpoint.com Subject: Re: DESE padding implementation poll Cc: ietf-ppp@merit.edu Sender: owner-ietf-ppp@merit.edu Without meaning to throw gasoline on some still glowing embers, I believe the reason why Karl is asking the question is the following: He nudged Gerry or me to revise RFC1969 according to the consensus and submit it as a draft (soon), and I agreed to do so, but suggested that it might be good to assign a different PPP-encryption-protocol number for this as I believe there might have been people who implemented according to the (confusing) letter of RFC1969, and consequently would not interoperate with people who obeyed the new rules. Karl didn't say as much, but I suspect his position is "if all *existing* implementations always pad, and always strip, then we don't need a new number." (Those are my words, and a conjecture on my part). My own position is, most people probably don't give a damn anyway, that it will take considerable arm-twisting on his part to get any meaningful response to his query, that there probably aren't going to be in excess of 253 different encryption protocols, and it would make me feel better about having botched it the first time around, so what's the big deal about wasting one number as insurance, even if we probably won't need it? Here is an (admittedly low-probably) non-interoperable event: System A transmits an optionless TCP packet with the 6 data bytes 6, 5, 4, 3, 2, 1 (in that order). After prepending the initial 0021, the packet is now 48 bytes long, so it doesn't need any padding to be a multiple of 8 bytes, so that's just fed to the encryption machinery. (When I wrote the initial draft, I did not regard regular (non-VJ-compressed) IP as an "identified special protocol" in the language of RFC1570, so what system A does here is consistent with my original intent). System B receives the packet, decrypts it and according to the new rules, notices according to the method of SDP, it should prune off the last byte of the 48 byte clear text. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jul 10 21:59:03 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id VAA07033; Thu, 10 Jul 1997 21:58:55 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 10 Jul 1997 21:57:53 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id VAA07001 for ietf-ppp-outgoing; Thu, 10 Jul 1997 21:57:52 -0400 (EDT) Received: from lmux02.ssc.siemens.com (ssc.siemens.com [192.132.51.1]) by merit.edu (8.8.5/8.8.5) with SMTP id VAA06994 for ; Thu, 10 Jul 1997 21:57:47 -0400 (EDT) From: George.King@ssc.siemens.com Received: by lmux02.ssc.siemens.com (5.65/DEC-Ultrix/4.3) id AA00955; Thu, 10 Jul 1997 21:58:53 -0400 Received: (from root@localhost) by x400sco.boca.ssc.siemens.com (8.6.8.1/8.6.12) id BAA13447; Fri, 11 Jul 1997 01:55:38 GMT X400-Received: by /PRMD=scn/ADMD=mci/C=us; Relayed; 10 Jul 97 21:56:24 -0400 Date: 10 Jul 97 21:56:24 -0400 Delivery-Date: 10 Jul 97 21:55:37 -0400 Message-Type: Multiple Part X400-Originator: George.King@ssc.siemens.com X400-Mts-Identifier: [/PRMD=scn/ADMD=mci/C=us;XGW-970710215717-0400-01229] X400-Recipients: non-disclosure Original-Encoded-Information-Types: IA5-Text X400-Content-Type: P2-1984 Message-Id: <0711015717-Re: Fw: Hello, question about RFC 1661*/G=George/S=King/O=ssc/OU=boc4/PRMD=scn/ADMD=mci/C=us/@MHS> Importance: normal Subject: Re: Fw: Hello, question about RFC 1661 Autoforwarded: FALSE To: msacks@questra.com Cc: ietf-ppp@merit.edu Conversion: Allowed Conversion-With-Loss: Allowed Alternate-Recipient: Prohibited Content-Identifier: Re: Fw: Hello, q Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit Sender: owner-ietf-ppp@merit.edu Matthew: I do not know if this question is only related to DTE/DCE flow control? It would seem like Ethernet's CSMA/CD mechanism would qualify for being Half Duplex, with the only Request to Send, being Data to ship from Layer Three ? I would be interesting in receiving E-mail comments about anyone's experiences using FDSE (Full Duplex Switched Ethernet). G.K. >In section 1 of RFC 1661, it specifies that PPP for a "sumultaneous" >bidirectional full-duplex link. In an older version, RFC1331, it was even >for explicity stated that a "FULL-DUPLEX" is required. It is rather >obvious that a simplex line won't work. But what about what the textbooks >used to call (at least when I went to school) a half-duplex line. This >simply means that at a low level, the communications is alternating in >direction; bidirectional but not simultaneous. Would this break PPP >somehow? >Or does full-duplex, for these purposes, simply mean bidirectional? >Matthew Sacks - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jul 10 22:35:19 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id WAA07450; Thu, 10 Jul 1997 22:35:18 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 10 Jul 1997 22:35:02 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id WAA07431 for ietf-ppp-outgoing; Thu, 10 Jul 1997 22:35:01 -0400 (EDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm002-23.dialip.mich.net [141.211.7.159]) by merit.edu (8.8.5/8.8.5) with SMTP id WAA07427 for ; Thu, 10 Jul 1997 22:34:52 -0400 (EDT) Date: Fri, 11 Jul 97 02:08:23 GMT From: "William Allen Simpson" Message-ID: <6235.wsimpson@greendragon.com> To: ietf-ppp@merit.edu Subject: Re: DESE padding implementation poll Sender: owner-ietf-ppp@merit.edu As folks may recall, I was not happy with the editting of the DESE RFC (I didn't even like calling it DESE), but it was published anyway. All well and good, we can change technical issues, it's just an Informational RFC, right? Nope, not easily :-( Anybody who already implemented should not be penalized. A new protocol number would penalize them. The simple solution is that the _receiver_ should decide whether or not to check for the padding, and the check should default to off. The best way to handle this is to add a little section at the end on Operational Considerations (which I'm inclined to have in every protocol in these days, just to remind folks that they need to consider the poor operators). Here's the kind of thing I added in the IPSec world: Operational Considerations The specification provides only a few manually configurable parame- ters: Pad Values New implementations use verifiable values. However, some earlier implementations used pseudo-random values. This check must only be used with those peers that have implemented this feature. Also, some operations desire additional padding to inhibit traffic analysis. Default: 0 (checking off). Range: 7 to 255. Key The 56-bit key is configured as a 64-bit quantity, with parity included as appropriate. > From: Keith Sklower > Here is an (admittedly low-probably) non-interoperable event: > System A transmits an optionless TCP packet with the 6 data > bytes 6, 5, 4, 3, 2, 1 (in that order). After prepending > the initial 0021, the packet is now 48 bytes long, so it > doesn't need any padding to be a multiple of 8 bytes, > so that's just fed to the encryption machinery. > > (When I wrote the initial draft, I did not regard regular (non-VJ-compressed) > IP as an "identified special protocol" in the language of > RFC1570, so what system A does here is consistent with my original intent). > Yes, that's correct. IP has a length. It is not a special protocol. > System B receives the packet, decrypts it and according to the > new rules, notices according to the method of SDP, it should > prune off the last byte of the 48 byte clear text. > What?!?! Then you better change the "new rules". To quote RFC-1570: This option is most likely to be used when some protocols, such as network-layer or compression protocols, are configured which require detection and removal of any trailing padding. Such spe- cial protocols are identified in their respective documents. If the option is Rejected, the peer MUST NOT add any padding to any identified special protocols, but MAY add padding to other protocols. IP does not "require detection and removal of any trailing padding." You MAY add padding to IP at any time with impunity! You DO NOT remove the trailing padding! The normal IP processing will simply ignore the trailing padding, just as it does with an Ethernet tinygram. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Jul 11 03:44:27 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id DAA10523; Fri, 11 Jul 1997 03:44:20 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 11 Jul 1997 03:43:58 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id DAA10504 for ietf-ppp-outgoing; Fri, 11 Jul 1997 03:43:57 -0400 (EDT) Received: from SantaClara01.pop.internex.net (santaclara01.pop.InterNex.Net [205.158.3.18]) by merit.edu (8.8.5/8.8.5) with ESMTP id DAA10498 for ; Fri, 11 Jul 1997 03:43:52 -0400 (EDT) Received: from flowpnt.flowpoint.com ([192.84.210.69]) by SantaClara01.pop.internex.net (post.office MTA v1.9.3 ID# 0-11030) with SMTP id AAA5590; Fri, 11 Jul 1997 00:43:50 -0700 Received: from zeus.flowpoint.com (ws67.flowpoint.com) by flowpnt.flowpoint.com (4.1/SMI-4.1) id AA03551; Fri, 11 Jul 97 00:21:29 PDT Received: by zeus.flowpoint.com (4.1/SMI-4.1) id AA01727; Fri, 11 Jul 97 00:21:28 PDT Date: Fri, 11 Jul 1997 00:21:27 -0700 (PDT) From: Philip Rakity X-Sender: pmr@zeus To: William Allen Simpson Cc: ietf-ppp@merit.edu Subject: Re: DESE padding implementation poll In-Reply-To: <6235.wsimpson@greendragon.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Bill, The protocol does NOT work if VJ compression is negotiated. Lets change the RFC numbers, and fix the protocol. Since ECP is negotiated in parallel or even before IPNCP it is unclear what to do. I have tested with about 5 or 6 companies and ALL of them have implemented SDP. The problem that we have encountered using DESE is no different than that with early drafts of PPP or any other protocol that has had more than one RFC number assigned. A problem has been found, so we fix the problem and issue a new number. Philip Rakity FlowPoint Corporation On Fri, 11 Jul 1997, William Allen Simpson wrote: > As folks may recall, I was not happy with the editting of the DESE RFC > (I didn't even like calling it DESE), but it was published anyway. All > well and good, we can change technical issues, it's just an > Informational RFC, right? Nope, not easily :-( > > Anybody who already implemented should not be penalized. A new protocol > number would penalize them. > > The simple solution is that the _receiver_ should decide whether or not > to check for the padding, and the check should default to off. > > The best way to handle this is to add a little section at the end on > Operational Considerations (which I'm inclined to have in every protocol > in these days, just to remind folks that they need to consider the poor > operators). Here's the kind of thing I added in the IPSec world: > > Operational Considerations > > The specification provides only a few manually configurable parame- > ters: > > Pad Values > New implementations use verifiable values. However, some earlier > implementations used pseudo-random values. This check must only > be used with those peers that have implemented this feature. > > Also, some operations desire additional padding to inhibit traffic > analysis. > > Default: 0 (checking off). Range: 7 to 255. > > Key > The 56-bit key is configured as a 64-bit quantity, with parity > included as appropriate. > > > > From: Keith Sklower > > Here is an (admittedly low-probably) non-interoperable event: > > System A transmits an optionless TCP packet with the 6 data > > bytes 6, 5, 4, 3, 2, 1 (in that order). After prepending > > the initial 0021, the packet is now 48 bytes long, so it > > doesn't need any padding to be a multiple of 8 bytes, > > so that's just fed to the encryption machinery. > > > > (When I wrote the initial draft, I did not regard regular (non-VJ-compressed) > > IP as an "identified special protocol" in the language of > > RFC1570, so what system A does here is consistent with my original intent). > > > Yes, that's correct. IP has a length. It is not a special protocol. > > > > System B receives the packet, decrypts it and according to the > > new rules, notices according to the method of SDP, it should > > prune off the last byte of the 48 byte clear text. > > > What?!?! Then you better change the "new rules". To quote RFC-1570: > > This option is most likely to be used when some protocols, such as > network-layer or compression protocols, are configured which > require detection and removal of any trailing padding. Such spe- > cial protocols are identified in their respective documents. > > If the option is Rejected, the peer MUST NOT add any padding to > any identified special protocols, but MAY add padding to other > protocols. > > IP does not "require detection and removal of any trailing padding." > You MAY add padding to IP at any time with impunity! You DO NOT remove > the trailing padding! The normal IP processing will simply ignore the > trailing padding, just as it does with an Ethernet tinygram. > > WSimpson@UMich.edu > Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 > BSimpson@MorningStar.com > Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Jul 11 04:41:33 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id EAA11184; Fri, 11 Jul 1997 04:41:31 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 11 Jul 1997 04:41:09 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id EAA11166 for ietf-ppp-outgoing; Fri, 11 Jul 1997 04:41:08 -0400 (EDT) Received: from mx11.netvision.net.il (mx11.NetVision.net.il [194.90.1.52]) by merit.edu (8.8.5/8.8.5) with SMTP id EAA11162 for ; Fri, 11 Jul 1997 04:41:04 -0400 (EDT) From: rongil@radmail.rad.co.il Received: (qmail 3363 invoked from network); 11 Jul 1997 08:41:02 -0000 Received: from radmail.rad.co.il (207.232.32.10) by mx11.netvision.net.il with SMTP; 11 Jul 1997 08:41:02 -0000 Received: from rongil.rad.co.il ([192.114.29.202]) by radmail.rad.co.il (post.office MTA v2.0 0813 ID# 0-12126) with SMTP id AAA23003 for ; Fri, 11 Jul 1997 11:42:12 +0300 Message-Id: <3.0.2.32.19970711113924.0072c5a8@radmail.rad.co.il> X-Sender: rongil@radmail.rad.co.il X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.2 b5 (32) Date: Fri, 11 Jul 1997 11:39:24 +0200 To: ietf-ppp@merit.edu Subject: MLPPP on links with different bandwidth Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Hi, Does anyone uses MLPPP over links with different bandwidth and not just over 64k B channels? I am using a bundle which is a mixture of ISDN and FR links in order to transfer FR over MLPPP (Called Multilink Frame Relay -MFR). Using links of different rate require that the fragmentation will be according to the link rate. Since RFC 1990 does not handle with this issue I have implemented a proprietary fragmentation algorithm. I would like to know if there is anyone who deals with MLPPP over links with different rate or who transfer FR over MLPPP. Ron. =================================================================== | Ron Gilaad | FAX: 972-3-6475924 | | RAD data communications ltd. | PHONE: 972-3-6455758 (Office) | | 31 Habarzel St. | 972-3-6490064 (Home) | | Tel-Aviv 69710 | E-mail: rongil@radmail.rad.co.il | | Israel | | =================================================================== - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Jul 11 05:40:06 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id FAA11611; Fri, 11 Jul 1997 05:39:32 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 11 Jul 1997 05:36:24 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id FAA11555 for ietf-ppp-outgoing; Fri, 11 Jul 1997 05:36:24 -0400 (EDT) Received: from fsnt.future.futsoft.com ([38.242.192.5]) by merit.edu (8.8.5/8.8.5) with ESMTP id FAA11550 for ; Fri, 11 Jul 1997 05:36:00 -0400 (EDT) Received: from kailash.future.futsoft.com (38.242.192.4) by fsnt.future.futsoft.com (Integralis SMTPRS 1.51) with ESMTP id ; Thu, 10 Jul 1997 15:09:44 +0530 Received: from msgate.future.futsoft.com (msgate.future.futsoft.com [10.0.8.4]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id OAA06974; Fri, 11 Jul 1997 14:50:36 +0530 Received: by msgate.future.futsoft.com with Microsoft Mail id <33C6ACCE@msgate.future.futsoft.com>; Fri, 11 Jul 97 14:59:42 PDT From: shenoyh To: ietf-ppp , "Jonathan.Goodchild" Subject: Re: RFC 1990 cud put the PPP negotiation into a loop !!! Date: Fri, 11 Jul 97 14:59:00 PDT Message-Id: <33C6ACCE@msgate.future.futsoft.com> X-Mailer: Microsoft Mail V3.0 Sender: owner-ietf-ppp@merit.edu In replyto my query on PPP going into a loop, nobody seems to have considered para 3, section 8, page 20 of rfc 1990 which states : " Although explicitly discouraged above, if there were several member links connecting two implementations, and independent sequencing of two protocol sets were desired, but blocking of one by the other was not, one could describe two multilink procedures by *assigning multiple endpoint identifiers to a given system.* Each member link, however, would only belong to one bundle. One could think of a physical router as housing two logically separate implementations, each of which is independently configured." and the second para of setion 1.2, page 3 of rfc 1990 which states thus : " Only under exceptional conditions would a given pair of systems require the operation of more than one bundle connecting them." Also, I know of at least two famous vendors who support multiple bundles between two peers. Well, it is true that such a scenario is quiet rare and that the end-point descriminator for most purposes is used for identifying systems rather than bundles. But then as I have quoted above, the rfc does put forward such a scenario. I should also apologize for the not-so clear definition of the problem. I thank Mr. Jonathan.Goodchild for the clearer diagram. >Each peer has its own EPD, thus the diagram should be more like: > > ---- e1 ----- >(x)b1 | |--------------------------| |b1 (u) > | P1 | | P2 | >(y)b2 | |--------------------------| |b2 (v) > ---- e2 ----- However the following statements by Mr. Jonathan.Goodchild seem to contradict each other and the problem of PPP going into a loop will be clear if they are studied better : >There is no such requirement. When sending a configure request, P2 uses >its own EPD (u or v). Once LCP negotiation is complete, it compares the >peer's EPD for the new link with the peer's EPD already negotiated on >the bundle - if they don't match then the link can't be added to the >bundle. >So, y will match with b2's negotiated end-point descriminator and e1 >will be added to b2. >Sorry, this is completely wrong. If P2 is clever enough to realise that >P1 wishes to add both links to bundle b2, then it would send EPD v >instead of u in its Configure-Request (after all, it has already >received the Configure-Request from P1). - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Jul 11 10:42:29 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id KAA15315; Fri, 11 Jul 1997 10:42:20 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 11 Jul 1997 10:41:29 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id KAA15274 for ietf-ppp-outgoing; Fri, 11 Jul 1997 10:41:28 -0400 (EDT) Received: from Fe3.rust.net (Fe3.rust.net [204.157.12.254]) by merit.edu (8.8.5/8.8.5) with ESMTP id KAA15265 for ; Fri, 11 Jul 1997 10:41:21 -0400 (EDT) Received: from netx.nei.com (netx.nei.com [209.69.28.17]) by Fe3.rust.net (8.8.5/8.8.5) with SMTP id KAA12639; Fri, 11 Jul 1997 10:41:12 -0400 (EDT) Received: from cc:Mail by netx.nei.com id AA868642723; Fri, 11 Jul 97 10:38:58 EST Date: Fri, 11 Jul 97 10:38:58 EST From: "Whelan, Bill" Message-Id: <9706118686.AA868642723@netx.nei.com> To: ietf-ppp@merit.edu, Karl Fox Subject: Re[2]: DESE padding implementation poll Sender: owner-ietf-ppp@merit.edu If the last byte is n <= 8 AND The immediately preceding bytes decrease to 1 THEN I strip them off OTHERWISE I leave them alone This interoperates correctly with all I've tested with. Bill Whelan Cabletron Systems - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Jul 11 10:55:07 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id KAA15783; Fri, 11 Jul 1997 10:55:04 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 11 Jul 1997 10:54:37 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id KAA15742 for ietf-ppp-outgoing; Fri, 11 Jul 1997 10:54:36 -0400 (EDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm012-08.dialip.mich.net [141.211.7.176]) by merit.edu (8.8.5/8.8.5) with SMTP id KAA15715 for ; Fri, 11 Jul 1997 10:54:20 -0400 (EDT) Date: Fri, 11 Jul 97 12:02:47 GMT From: "William Allen Simpson" Message-ID: <6237.wsimpson@greendragon.com> To: ietf-ppp@merit.edu Subject: Re: DESE padding implementation poll Sender: owner-ietf-ppp@merit.edu > From: Philip Rakity > The protocol does NOT work if VJ compression is negotiated. Lets change > the RFC numbers, and fix the protocol. Since ECP is negotiated in > parallel or even before IPNCP it is unclear what to do. I have tested > with about 5 or 6 companies and ALL of them have implemented SDP. > > The problem that we have encountered using DESE is no different than that > with early drafts of PPP or any other protocol that has had more than one > RFC number assigned. A problem has been found, so we fix the problem and > issue a new number. > Pardon? I think you missed the point. I am all _for_ assigning a new RFC number, just not new PPP Protocol numbers. If something doesn't work, then assigning a new PPP Protocol number will not change that non-working behaviour. If something already doesn't work, then keeping the same PPP Protocol will not affect the old non-working implementations (they still won't work), but will assist the working ones. The old ones will continue not to work until they are upgraded. Same operational hassle. The real issue, as far as I can see it, is that some folks didn't follow the strict letter of RFC-1969 (which IMHO rambled a bit), and added "random trailing garbage" when the protocol did not have the length field needed to remove it. We all agreed that the new specification will be: SDP needs to be added to all packets, no random padding. The only issue is whether that padding needs to be _removed_ from all packets. That answer is: not for Protocols that have their own length, otherwise, yes. In that fashion, only the vendors that wrote buggy code will be affected. I don't think we should design protocols around folks that wrote bad code. We should make the specification more clear, and should ensure that folks with well-written code are still happy. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Jul 11 11:35:43 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id LAA17174; Fri, 11 Jul 1997 11:35:41 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 11 Jul 1997 11:35:16 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id LAA17150 for ietf-ppp-outgoing; Fri, 11 Jul 1997 11:35:15 -0400 (EDT) Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.8.5/8.8.5) with SMTP id LAA17142 for ; Fri, 11 Jul 1997 11:35:07 -0400 (EDT) Received: from mica.denver.sgi.com (mica.denver.sgi.com [169.238.67.6]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id IAA13882 for <@sgi.engr.sgi.com:ietf-ppp@merit.edu>; Fri, 11 Jul 1997 08:35:04 -0700 env-from (vjs@mica.denver.sgi.com) Received: (from vjs@localhost) by mica.denver.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA10094 for ietf-ppp@merit.edu; Fri, 11 Jul 1997 09:35:02 -0600 Date: Fri, 11 Jul 1997 09:35:02 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199707111535.JAA10094@mica.denver.sgi.com> To: ietf-ppp@merit.edu Subject: Re[2]: DESE padding implementation poll Sender: owner-ietf-ppp@merit.edu > From: "Whelan, Bill" > To: ietf-ppp@merit.edu, Karl Fox > > If the last byte is n <= 8 > AND > The immediately preceding bytes decrease to 1 > > THEN > I strip them off > > OTHERWISE > I leave them alone > > This interoperates correctly with all I've tested with. Doesn't that assume that SDP is always present? Isn't it the definition of SDP? What if the cypher text happened to end with such a increasing sequence? Or do you permanently stop expecting SDP if you ever see a single packet without it? (I'm not expressing an opinion on whether SDP is a good or bad assumption or consistent with any RFC's or drafts. It just sounds like an answer that is not congruent with the question asked or other recent statements.) Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Jul 11 13:12:32 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id MAA18992; Fri, 11 Jul 1997 12:14:28 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 11 Jul 1997 12:12:10 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id MAA18845 for ietf-ppp-outgoing; Fri, 11 Jul 1997 12:12:08 -0400 (EDT) Received: from luna.dev.wrq.com ([150.215.23.215]) by merit.edu (8.8.5/8.8.5) with SMTP id MAA18837 for ; Fri, 11 Jul 1997 12:11:52 -0400 (EDT) Received: from localhost (eriko@localhost) by luna.dev.wrq.com (8.6.12/8.6.10) with SMTP id JAA17925; Fri, 11 Jul 1997 09:11:44 -0700 Date: Fri, 11 Jul 1997 09:11:44 -0700 (PDT) From: Erik Olson To: ietf-ppp@merit.edu cc: aaronh@elmer.wrq.com Subject: Multilink Network Protocol Interoperability Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Hi, I was wondering if I could get some insight into a problem we're having developing our multilink PPP code. As I understand RFC 1990: The state machines for LCP and other LINK-based protocols (>= C000h) such as CHAP or CBCP are negotiated for each link in the bundle, but NETWORK-based protocols (< C000h) such as IPCP and IP come in ONE per BUNDLE. If we get an IPCP configure request on multiple links (either the virtual link or the real links), we treat it as if it came as multiple requests on the same IPCP state machine. Now, we're observing that when connecting to a particular router, it seems to be keeping TWO SEPARATE IPCP state machines on each of our two links in the bundle, and this in turn causes us some grief (specifically, in failure to converge on an IPCP negotiation) if we haven't dialed both links at precisely the same time. Questions: 1. Is this vendor breaking RFC? 2. Should we config-reject IPCP on the second link? (Then WE'd be breaking RFC.) Should we treat the other link like a separate state machine and just ignore it for purposes of transmitting packets? 3. What have other vendors done to get around these implementations? Thanks in advance for your insight. - Erik --- Erik Olson eriko@wrq.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Jul 11 13:16:22 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id NAA21525; Fri, 11 Jul 1997 13:16:20 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 11 Jul 1997 13:15:51 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id NAA21499 for ietf-ppp-outgoing; Fri, 11 Jul 1997 13:15:50 -0400 (EDT) Received: from stilton.cisco.com (stilton.cisco.com [171.69.1.161]) by merit.edu (8.8.5/8.8.5) with SMTP id NAA21494 for ; Fri, 11 Jul 1997 13:15:43 -0400 (EDT) Received: (dblair@localhost) by stilton.cisco.com (8.6.12/8.6.5) id KAA07367; Fri, 11 Jul 1997 10:15:11 -0700 From: Dana Blair Message-Id: <199707111715.KAA07367@stilton.cisco.com> Subject: Re: Multilink Network Protocol Interoperability To: eriko@wrq.com (Erik Olson) Date: Fri, 11 Jul 1997 10:15:11 -0700 (PDT) Cc: ietf-ppp@merit.edu, aaronh@elmer.wrq.com In-Reply-To: from "Erik Olson" at Jul 11, 97 09:11:44 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu > > Hi, I was wondering if I could get some insight into a problem we're > having developing our multilink PPP code. As I understand RFC 1990: > > The state machines for LCP and other LINK-based protocols (>= C000h) such > as CHAP or CBCP are negotiated for each link in the bundle, but > NETWORK-based protocols (< C000h) such as IPCP and IP come in ONE per > BUNDLE. If we get an IPCP configure request on multiple links (either the > virtual link or the real links), we treat it as if it came as multiple > requests on the same IPCP state machine. Now, we're observing that when > connecting to a particular router, it seems to be keeping TWO SEPARATE > IPCP state machines on each of our two links in the bundle, and this in > turn causes us some grief (specifically, in failure to converge on an IPCP > negotiation) if we haven't dialed both links at precisely the same time. > Questions: Don't do anything to accomodate 2 IPCP state machines over the same bundle. The vendor needs to get rid of one of them. > > 1. Is this vendor breaking RFC? 1. The vendor could be broken. 2. The vendor could be misconfigured. 3. Your device may have sent a different Endpoint discriminator on each link. 4. Your device may have sent a different username on each link when authenticating. > > 2. Should we config-reject IPCP on the second link? (Then WE'd be > breaking RFC.) Should we treat the other link like a separate state > machine and just ignore it for purposes of transmitting packets? no. and no. You must assume that all IPCP messages received over a bundle originate from the same IPCP state machine since the standard requires that there be no more than 1. > > 3. What have other vendors done to get around these implementations? Get the remote vendors box to work properly. Dana > > Thanks in advance for your insight. > > - Erik > > --- > Erik Olson > eriko@wrq.com > > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Jul 11 13:21:10 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id NAA21721; Fri, 11 Jul 1997 13:21:08 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 11 Jul 1997 13:20:49 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id NAA21690 for ietf-ppp-outgoing; Fri, 11 Jul 1997 13:20:48 -0400 (EDT) Received: from ns.frigate.com (ns.frigate.com [206.14.208.6]) by merit.edu (8.8.5/8.8.5) with ESMTP id NAA21685 for ; Fri, 11 Jul 1997 13:20:42 -0400 (EDT) Received: from localhost (mthorn@localhost) by ns.frigate.com (8.8.5/8.7.1) with SMTP id KAA14837; Fri, 11 Jul 1997 10:18:32 -0700 (PDT) Date: Fri, 11 Jul 1997 10:18:31 -0700 (PDT) From: Mike Thornburg To: Erik Olson cc: ietf-ppp@merit.edu, aaronh@elmer.wrq.com Subject: Re: Multilink Network Protocol Interoperability In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu On Fri, 11 Jul 1997, Erik Olson wrote: > > Hi, I was wondering if I could get some insight into a problem we're > having developing our multilink PPP code. As I understand RFC 1990: > > The state machines for LCP and other LINK-based protocols (>= C000h) such > as CHAP or CBCP are negotiated for each link in the bundle, but > NETWORK-based protocols (< C000h) such as IPCP and IP come in ONE per > BUNDLE. If we get an IPCP configure request on multiple links (either the > virtual link or the real links), we treat it as if it came as multiple > requests on the same IPCP state machine. Now, we're observing that when > connecting to a particular router, it seems to be keeping TWO SEPARATE > IPCP state machines on each of our two links in the bundle, and this in > turn causes us some grief (specifically, in failure to converge on an IPCP > negotiation) if we haven't dialed both links at precisely the same time. > Questions: > > 1. Is this vendor breaking RFC? > All IPCP requests received on any link in the bundle, whether encapsulated in multilink headers or sent bare, without any multilink encapsulation, belong to the same IPCP state machine. There is only one IPCP state machine for the bundle. If the situation is really as you have described it, this vendor is breaking the RFC. > 2. Should we config-reject IPCP on the second link? (Then WE'd be > breaking RFC.) Should we treat the other link like a separate state > machine and just ignore it for purposes of transmitting packets? > I don't know what you could possibly do to interoperate with this vendor and still be able to interopererate with other, compliant implementations that could in theory send IPCP packets unencapsulated in multilink headers and distributed over all links in the bundle. The only thing you could do that has any hope of working is to simply ignore IPCP packets from one of the links and hope that eventually you can complete the config-request, config-ack exchanges in both directions using only one of the links. I don't think I would do this: the other vendor is badly broken, he should be the one to fix his code. Thanks, Mike -------------- Mike Thornburg frigate networks 415.903.2266 mthorn@frigate.com http://www.frigate.com/ - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Jul 11 13:25:12 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id LAA18009; Fri, 11 Jul 1997 11:55:39 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 11 Jul 1997 11:55:08 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id LAA17975 for ietf-ppp-outgoing; Fri, 11 Jul 1997 11:55:07 -0400 (EDT) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by merit.edu (8.8.5/8.8.5) with SMTP id LAA17968 for ; Fri, 11 Jul 1997 11:54:57 -0400 (EDT) Received: from spud.ascend.com (fw-ext.ascend.com [198.4.92.5]) by drawbridge.ascend.com (8.6.12/8.6.12) with ESMTP id IAA27660; Fri, 11 Jul 1997 08:54:47 -0700 Received: from ascend.com by ascend.com with ESMTP id IAA27316; Fri, 11 Jul 1997 08:54:43 -0700 Received: from gump.eng.ascend.com (gump.eng.ascend.com [206.65.212.67]) by wopr.eng.ascend.com (8.6.12/8.6.12) with ESMTP id IAA15955; Fri, 11 Jul 1997 08:54:12 -0700 Received: from carp.morningstar.com.ascend.com (karl@carp.MorningStar.Com [137.175.81.4]) by gump.eng.ascend.com (8.6.12/8.6.12) with SMTP id IAA03544; Fri, 11 Jul 1997 08:54:10 -0700 Date: Fri, 11 Jul 1997 08:54:10 -0700 Message-Id: <199707111554.IAA03544@gump.eng.ascend.com> From: Karl Fox To: rongil@radmail.rad.co.il Cc: ietf-ppp@merit.edu Subject: MLPPP on links with different bandwidth In-Reply-To: <3.0.2.32.19970711113924.0072c5a8@radmail.rad.co.il> References: <3.0.2.32.19970711113924.0072c5a8@radmail.rad.co.il> Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ietf-ppp@merit.edu Ron Gilaad writes: > Using links of different rate require that the fragmentation will be > according to the link rate. Since RFC 1990 does not handle with this issue > I have implemented a proprietary fragmentation algorithm. I think these sentences from section 3 address that issue: Network Protocol packets are first encapsulated (but not framed) according to normal PPP procedures, and large packets are broken up into multiple segments sized appropriately for the multiple physical links. ... A possible strategy for contending with member links of differing transmission rates would be to divide the packets into segments proportion to the transmission rates. Another strategy might be to divide them into many equal fragments and distribute multiple fragments per link, the numbers being proportional to the relative speeds of the links. -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Jul 11 14:05:26 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id OAA23385; Fri, 11 Jul 1997 14:05:25 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 11 Jul 1997 14:05:13 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id OAA23367 for ietf-ppp-outgoing; Fri, 11 Jul 1997 14:05:12 -0400 (EDT) Received: from jaba.rampnet.com (link-rampnet.rampnet.com [206.14.182.236]) by merit.edu (8.8.5/8.8.5) with ESMTP id OAA23353 for ; Fri, 11 Jul 1997 14:04:56 -0400 (EDT) Received: from panda.rampnet.com ([205.158.93.169]) by jaba.rampnet.com (post.office MTA v2.0 0813 ID# 0-18176U100) with SMTP id AAA197; Fri, 11 Jul 1997 11:06:46 -0700 Received: by panda.rampnet.com (SMI-8.6/SMI-SVR4) id LAA12962; Fri, 11 Jul 1997 11:06:31 -0700 Date: Fri, 11 Jul 1997 11:06:31 -0700 From: ashok@rampnet.com (Ashok Ramachandra) Message-Id: <199707111806.LAA12962@panda.rampnet.com> To: eriko@wrq.com, mthorn@frigate.com Subject: Re: Multilink Network Protocol Interoperability Cc: ietf-ppp@merit.edu, aaronh@elmer.wrq.com X-Sun-Charset: US-ASCII Sender: owner-ietf-ppp@merit.edu > From mthorn@frigate.com Fri Jul 11 10:25:10 1997 > Date: Fri, 11 Jul 1997 10:18:31 -0700 (PDT) > From: Mike Thornburg > To: Erik Olson > cc: ietf-ppp@merit.edu, aaronh@elmer.wrq.com > Subject: Re: Multilink Network Protocol Interoperability > MIME-Version: 1.0 > Sender: owner-ietf-ppp@merit.edu > > On Fri, 11 Jul 1997, Erik Olson wrote: > > > > > Hi, I was wondering if I could get some insight into a problem we're > > having developing our multilink PPP code. As I understand RFC 1990: > > > > The state machines for LCP and other LINK-based protocols (>= C000h) such > > as CHAP or CBCP are negotiated for each link in the bundle, but > > NETWORK-based protocols (< C000h) such as IPCP and IP come in ONE per > > BUNDLE. If we get an IPCP configure request on multiple links (either the > > virtual link or the real links), we treat it as if it came as multiple > > requests on the same IPCP state machine. Now, we're observing that when > > connecting to a particular router, it seems to be keeping TWO SEPARATE > > IPCP state machines on each of our two links in the bundle, and this in > > turn causes us some grief (specifically, in failure to converge on an IPCP > > negotiation) if we haven't dialed both links at precisely the same time. > > Questions: > > > > 1. Is this vendor breaking RFC? > > > > All IPCP requests received on any link in the bundle, whether encapsulated > in multilink headers or sent bare, without any multilink encapsulation, > belong to the same IPCP state machine. There is only one IPCP state > machine for the bundle. > > If the situation is really as you have described it, this vendor is > breaking the RFC. > > > 2. Should we config-reject IPCP on the second link? (Then WE'd be > > breaking RFC.) Should we treat the other link like a separate state > > machine and just ignore it for purposes of transmitting packets? > > > > I don't know what you could possibly do to interoperate with this vendor > and still be able to interopererate with other, compliant implementations > that could in theory send IPCP packets unencapsulated in multilink > headers and distributed over all links in the bundle. > > The only thing you could do that has any hope of working is to simply > ignore IPCP packets from one of the links and hope that eventually you > can complete the config-request, config-ack exchanges in both directions > using only one of the links. I don't think I would do this: the other > vendor is badly broken, he should be the one to fix his code. > Even I am facing the same problem with one of the most popular vendors, although it is something different in my case. I got one channel completely UP, and then when I want the second one he comes back with the IPCP-CONF-REQ after the authentication phase. I cannot respond to him, because I will be breaking the RFC and if I don't he thinks I am dead. So I decided to do a CONF-REJ to him (breaking the RFC though) thinking that I won't get 2 channels, but at this point he brings down both of them. How do I interoperate with him???? > Thanks, > Mike > -------------- > Mike Thornburg frigate networks 415.903.2266 > mthorn@frigate.com http://www.frigate.com/ > > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Jul 11 14:11:40 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id OAA23565; Fri, 11 Jul 1997 14:11:39 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 11 Jul 1997 14:11:29 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id OAA23546 for ietf-ppp-outgoing; Fri, 11 Jul 1997 14:11:28 -0400 (EDT) Received: from Fe3.rust.net (Fe3.rust.net [204.157.12.254]) by merit.edu (8.8.5/8.8.5) with ESMTP id OAA23542 for ; Fri, 11 Jul 1997 14:11:24 -0400 (EDT) Received: from netx.nei.com (netx.nei.com [209.69.28.17]) by Fe3.rust.net (8.8.5/8.8.5) with SMTP id OAA16671; Fri, 11 Jul 1997 14:11:22 -0400 (EDT) Received: from cc:Mail by netx.nei.com id AA868655333; Fri, 11 Jul 97 14:08:44 EST Date: Fri, 11 Jul 97 14:08:44 EST From: "Whelan, Bill" Message-Id: <9706118686.AA868655333@netx.nei.com> To: ietf-ppp@merit.edu, vjs@mica.denver.sgi.com (Vernon Schryver) Subject: Re[3]: DESE padding implementation poll Sender: owner-ietf-ppp@merit.edu No, I don't believe it assumes SDP is always present. If the last byte is greater than 8, then it is not SDP. And yes, I do believe this is the definition of SDP. Perhaps I should have also described my transmit logic, but Karl asked only about the receive side. The answer I provided described my treatment of the PLAIN text after decryption; I believe that was the intent of the question (Karl?). On the transmit side, if the PLAIN text ends with a byte <= 8 or if the plain text is NOT a multiple of eight bytes, then I pad it before encrypting. If I pad, I append as many bytes from the sequence 01 02 03 04 05 06 07 08 as are need to reach the next multiple of eight bytes. All this is done regardless of whether SDP has been explicitly negotiated. I consider the question of whether CYPHER text ends with such a sequence to be an issue independent of PLAIN text padding. CYPHER text padding is connected with SDP negotiation. Bill ______________________________ Reply Separator _________________________________ Subject: Re[2]: DESE padding implementation poll Author: vjs@mica.denver.sgi.com (Vernon Schryver) at internet-mail Date: 7/11/97 11:41 AM > From: "Whelan, Bill" > To: ietf-ppp@merit.edu, Karl Fox > > If the last byte is n <= 8 > AND > The immediately preceding bytes decrease to 1 > > THEN > I strip them off > > OTHERWISE > I leave them alone > > This interoperates correctly with all I've tested with. Doesn't that assume that SDP is always present? Isn't it the definition of SDP? What if the cypher text happened to end with such a increasing sequence? Or do you permanently stop expecting SDP if you ever see a single packet without it? (I'm not expressing an opinion on whether SDP is a good or bad assumption or consistent with any RFC's or drafts. It just sounds like an answer that is not congruent with the question asked or other recent statements.) Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Jul 11 14:10:54 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id OAA23526; Fri, 11 Jul 1997 14:10:52 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 11 Jul 1997 14:10:37 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id OAA23500 for ietf-ppp-outgoing; Fri, 11 Jul 1997 14:10:36 -0400 (EDT) Received: from luna.dev.wrq.com ([150.215.23.215]) by merit.edu (8.8.5/8.8.5) with SMTP id OAA23489 for ; Fri, 11 Jul 1997 14:10:29 -0400 (EDT) Received: from localhost (eriko@localhost) by luna.dev.wrq.com (8.6.12/8.6.10) with SMTP id LAA18346; Fri, 11 Jul 1997 11:10:21 -0700 Date: Fri, 11 Jul 1997 11:10:21 -0700 (PDT) From: Erik Olson To: Ashok Ramachandra cc: ietf-ppp@merit.edu, aaronh@elmer.wrq.com Subject: Re: Multilink Network Protocol Interoperability In-Reply-To: <199707111806.LAA12962@panda.rampnet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu On Fri, 11 Jul 1997, Ashok Ramachandra wrote: ... > > > > The only thing you could do that has any hope of working is to simply > > ignore IPCP packets from one of the links and hope that eventually you > > can complete the config-request, config-ack exchanges in both directions > > using only one of the links. I don't think I would do this: the other > > vendor is badly broken, he should be the one to fix his code. > > > Even I am facing the same problem with one of the most popular > vendors, although it is something different in my case. I got one > channel completely UP, and then when I want the second one he > comes back with the IPCP-CONF-REQ after the authentication phase. > I cannot respond to him, because I will be breaking the RFC and if > I don't he thinks I am dead. So I decided to do a CONF-REJ to him > (breaking the RFC though) thinking that I won't get 2 channels, but > at this point he brings down both of them. This is exactly the same problem we are seeing. Technically, the RFC says that YES, you respond with him because you can always reconfigure IPCP. Unfortunately, that means taking IPCP down for the whole bundle and reconfiguring. Does your peer vendor start with an "L"? - Erik --- Erik Olson eriko@wrq.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Jul 11 14:25:31 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id OAA23957; Fri, 11 Jul 1997 14:25:20 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 11 Jul 1997 14:24:50 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id OAA23932 for ietf-ppp-outgoing; Fri, 11 Jul 1997 14:24:49 -0400 (EDT) Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.8.5/8.8.5) with SMTP id OAA23928 for ; Fri, 11 Jul 1997 14:24:43 -0400 (EDT) Received: from mica.denver.sgi.com (mica.denver.sgi.com [169.238.67.6]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id LAA10247 for <@sgi.engr.sgi.com:ietf-ppp@merit.edu>; Fri, 11 Jul 1997 11:24:41 -0700 env-from (vjs@mica.denver.sgi.com) Received: (from vjs@localhost) by mica.denver.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA10443 for ietf-ppp@merit.edu; Fri, 11 Jul 1997 12:24:36 -0600 Date: Fri, 11 Jul 1997 12:24:36 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199707111824.MAA10443@mica.denver.sgi.com> To: ietf-ppp@merit.edu Subject: Re: Re[3]: DESE padding implementation poll Sender: owner-ietf-ppp@merit.edu > From: "Whelan, Bill" > To: ietf-ppp@merit.edu, vjs (Vernon Schryver) > > No, I don't believe it assumes SDP is always present. If the last > byte is greater than 8, then it is not SDP. What happens if you get a packet that does not have SDP but does end with the plaintext data "0x1 0x2 0x3 0x4 0x5 0x6 0x7 0x8"? Won't your code the wrong thing? > And yes, I do believe this is the definition of SDP. > > Perhaps I should have also described my transmit logic, but Karl asked > only about the receive side. The answer I provided described my > treatment of the PLAIN text after decryption; I believe that was the > intent of the question (Karl?). > ... What happens if you receive an encrypted TCP/IP packet with plaintext that was VJ header compressed and with TCP payload ending with "0x1 0x2 0x3 0x4 0x5 0x6 0x7 0x8"? How do you avoid discarding the last 8 bytes, wrecking the VJ decompression state, and subsequently injecting bogus data into the TCP stream? Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Jul 11 15:06:32 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id PAA25202; Fri, 11 Jul 1997 15:06:30 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 11 Jul 1997 15:05:57 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id PAA25160 for ietf-ppp-outgoing; Fri, 11 Jul 1997 15:05:56 -0400 (EDT) Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.8.5/8.8.5) with SMTP id PAA25155 for ; Fri, 11 Jul 1997 15:05:50 -0400 (EDT) Received: from mica.denver.sgi.com (mica.denver.sgi.com [169.238.67.6]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id MAA26702 for <@sgi.engr.sgi.com:ietf-ppp@merit.edu>; Fri, 11 Jul 1997 12:05:47 -0700 env-from (vjs@mica.denver.sgi.com) Received: (from vjs@localhost) by mica.denver.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA10602 for ietf-ppp@merit.edu; Fri, 11 Jul 1997 13:05:41 -0600 Date: Fri, 11 Jul 1997 13:05:41 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199707111905.NAA10602@mica.denver.sgi.com> To: ietf-ppp@merit.edu Subject: Re: Multilink Network Protocol Interoperability Sender: owner-ietf-ppp@merit.edu > From: Dana Blair > ... > > 1. Is this vendor breaking RFC? > > 1. The vendor could be broken. > 2. The vendor could be misconfigured. > 3. Your device may have sent a different Endpoint discriminator on > each link. > 4. Your device may have sent a different username on each link > when authenticating. 5. The vendor might not be doing RFC 1990 MP at all, but what is variously called "load balancing", "round robin", or "BF&I multilink." ...................... ]From: ashok@rampnet.com (Ashok Ramachandra) ] ... ] Even I am facing the same problem with one of the most popular ] vendors, although it is something different in my case. I got one ] channel completely UP, and then when I want the second one he ] comes back with the IPCP-CONF-REQ after the authentication phase. ] I cannot respond to him, because I will be breaking the RFC and if ] I don't he thinks I am dead. So I decided to do a CONF-REJ to him ] (breaking the RFC though) thinking that I won't get 2 channels, but ] at this point he brings down both of them. Which RFC do you think prohibits sending IPCP Configure-Requests at any time? The other vendor is doing nothing illegal, although it may be less than optimal. It is always legal to send a Configure-Request and renegotiate. Maybe your popular other vendor just wants to make sure that your system has a consistent view of IP. ] How do I interoperate with him???? By fixing your system to be legal, and to respond correctly to unsolicited Configure-Requests. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Jul 11 15:43:24 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id PAA26271; Fri, 11 Jul 1997 15:43:19 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 11 Jul 1997 15:42:52 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id PAA26240 for ietf-ppp-outgoing; Fri, 11 Jul 1997 15:42:51 -0400 (EDT) Received: from Fe3.rust.net (Fe3.rust.net [204.157.12.254]) by merit.edu (8.8.5/8.8.5) with ESMTP id PAA26227 for ; Fri, 11 Jul 1997 15:42:43 -0400 (EDT) Received: from netx.nei.com (netx.nei.com [209.69.28.17]) by Fe3.rust.net (8.8.5/8.8.5) with SMTP id PAA06651; Fri, 11 Jul 1997 15:42:29 -0400 (EDT) Received: from cc:Mail by netx.nei.com id AA868660799; Fri, 11 Jul 97 15:40:08 EST Date: Fri, 11 Jul 97 15:40:08 EST From: "Whelan, Bill" Message-Id: <9706118686.AA868660799@netx.nei.com> To: ietf-ppp@merit.edu, vjs@mica.denver.sgi.com (Vernon Schryver) Subject: Re[5]: DESE padding implementation poll Sender: owner-ietf-ppp@merit.edu Comments below. ______________________________ Reply Separator _________________________________ Subject: Re: Re[3]: DESE padding implementation poll Author: vjs@mica.denver.sgi.com (Vernon Schryver) at internet-mail Date: 7/11/97 2:29 PM > From: "Whelan, Bill" > To: ietf-ppp@merit.edu, vjs (Vernon Schryver) > > No, I don't believe it assumes SDP is always present. If the last > byte is greater than 8, then it is not SDP. What happens if you get a packet that does not have SDP but does end with the plaintext data "0x1 0x2 0x3 0x4 0x5 0x6 0x7 0x8"? Won't your code the wrong thing? If the plain text ended as you described, the transmitter should have padded to comply with the proposed updated text to replace RFC 1969. You are correct in saying that if it did not do so, my implementation would not play with them. > And yes, I do believe this is the definition of SDP. > > Perhaps I should have also described my transmit logic, but Karl asked > only about the receive side. The answer I provided described my > treatment of the PLAIN text after decryption; I believe that was the > intent of the question (Karl?). > ... What happens if you receive an encrypted TCP/IP packet with plaintext that was VJ header compressed and with TCP payload ending with "0x1 0x2 0x3 0x4 0x5 0x6 0x7 0x8"? How do you avoid discarding the last 8 bytes, wrecking the VJ decompression state, and subsequently injecting bogus data into the TCP stream? Same as above Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Jul 11 17:12:54 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id RAA28619; Fri, 11 Jul 1997 17:12:52 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 11 Jul 1997 17:12:33 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id RAA28588 for ietf-ppp-outgoing; Fri, 11 Jul 1997 17:12:32 -0400 (EDT) Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.8.5/8.8.5) with SMTP id RAA28580 for ; Fri, 11 Jul 1997 17:12:25 -0400 (EDT) Received: from mica.denver.sgi.com (mica.denver.sgi.com [169.238.67.6]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id OAA17061 for <@sgi.engr.sgi.com:ietf-ppp@merit.edu>; Fri, 11 Jul 1997 14:12:21 -0700 env-from (vjs@mica.denver.sgi.com) Received: (from vjs@localhost) by mica.denver.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA10795 for ietf-ppp@merit.edu; Fri, 11 Jul 1997 15:12:12 -0600 Date: Fri, 11 Jul 1997 15:12:12 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199707112112.PAA10795@mica.denver.sgi.com> To: ietf-ppp@merit.edu Subject: Re: Multilink Network Protocol Interoperability Sender: owner-ietf-ppp@merit.edu > From: Erik Olson > > 5. The vendor might not be doing RFC 1990 MP at all, but what is > > variously called "load balancing", "round robin", or "BF&I multilink." > > Would they be negotiating MRRU and Endpoint descriminators in that case? > This vendor is exchanging MRRU/EID's with us, so I think it's supposed to > be RFC 1990 MP. I agree that if it claims to be doing MP, then it's supposed to be doing MP. > .... > > ] Even I am facing the same problem with one of the most popular > > ] vendors, although it is something different in my case. I got one > > ] channel completely UP, and then when I want the second one he > > ] comes back with the IPCP-CONF-REQ after the authentication phase. > ... > I don't think that's a full solution. Our state machine does try to > renegotiate IPCP in this case, and it's fine as long as the two connection > processes are temporally separated by enough time that the first link has > completely brought up IPCP before the second starts to come up; at that > time, link 2 gets an IPCP config request from the peer, and takes IPCP > down in a renegotiation. When the negotiation on the second link > succeeds, IPCP comes back up. > > HOWEVER, If both links are coming up simultaneously, then the spurious > IPCP config request on the second line resets the negotiation process in > progress on link 1, causing non-convergence of IPCP on our end. I am assuming that the other guys unilaterally go recycle their singular IPCP state machine whenever another link is added to the bundle, even when the second link is added nearly simultaneously with the first. If that is a valid assumption, then it sounds to me that you have a bug in your system. The peer can send you an IPCP Configure-Request at any time (except when IP is completely turned off). If they are running two independent IPCP state machines, then they are hopelessly broken, and I do not see how you can validly converge except out of random, rather improbably luck. One way to check which is broken might be to respond to their extra IPCP Configure-Requests on the other link in the bundle. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Jul 11 17:04:30 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id RAA28189; Fri, 11 Jul 1997 17:04:27 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 11 Jul 1997 17:04:09 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id RAA28151 for ietf-ppp-outgoing; Fri, 11 Jul 1997 17:04:08 -0400 (EDT) Received: from luna.dev.wrq.com ([150.215.23.215]) by merit.edu (8.8.5/8.8.5) with SMTP id RAA28147 for ; Fri, 11 Jul 1997 17:04:04 -0400 (EDT) Received: from localhost (eriko@localhost) by luna.dev.wrq.com (8.6.12/8.6.10) with SMTP id OAA18910; Fri, 11 Jul 1997 14:03:55 -0700 Date: Fri, 11 Jul 1997 14:03:55 -0700 (PDT) From: Erik Olson To: Vernon Schryver cc: ietf-ppp@merit.edu Subject: Re: Multilink Network Protocol Interoperability In-Reply-To: <199707111905.NAA10602@mica.denver.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu On Fri, 11 Jul 1997, Vernon Schryver wrote: > > 5. The vendor might not be doing RFC 1990 MP at all, but what is > variously called "load balancing", "round robin", or "BF&I multilink." Would they be negotiating MRRU and Endpoint descriminators in that case? This vendor is exchanging MRRU/EID's with us, so I think it's supposed to be RFC 1990 MP. And with regards to this: > > ]From: ashok@rampnet.com (Ashok Ramachandra) > > ] ... > ] Even I am facing the same problem with one of the most popular > ] vendors, although it is something different in my case. I got one > ] channel completely UP, and then when I want the second one he > ] comes back with the IPCP-CONF-REQ after the authentication phase. > ] I cannot respond to him, because I will be breaking the RFC and if > ] I don't he thinks I am dead. So I decided to do a CONF-REJ to him > ] (breaking the RFC though) thinking that I won't get 2 channels, but > ] at this point he brings down both of them. > > Which RFC do you think prohibits sending IPCP Configure-Requests at any > time? The other vendor is doing nothing illegal, although it may be > less than optimal. It is always legal to send a Configure-Request and > renegotiate. Maybe your popular other vendor just wants to make sure > that your system has a consistent view of IP. > ] How do I interoperate with him???? > > By fixing your system to be legal, and to respond correctly to unsolicited > Configure-Requests. I don't think that's a full solution. Our state machine does try to renegotiate IPCP in this case, and it's fine as long as the two connection processes are temporally separated by enough time that the first link has completely brought up IPCP before the second starts to come up; at that time, link 2 gets an IPCP config request from the peer, and takes IPCP down in a renegotiation. When the negotiation on the second link succeeds, IPCP comes back up. HOWEVER, If both links are coming up simultaneously, then the spurious IPCP config request on the second line resets the negotiation process in progress on link 1, causing non-convergence of IPCP on our end. - Erik --- Erik Olson eriko@wrq.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Jul 11 17:28:53 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id RAA29123; Fri, 11 Jul 1997 17:28:50 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 11 Jul 1997 17:28:36 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id RAA29098 for ietf-ppp-outgoing; Fri, 11 Jul 1997 17:28:35 -0400 (EDT) Received: from vangogh.CS.Berkeley.EDU (vangogh.CS.Berkeley.EDU [128.32.33.5]) by merit.edu (8.8.5/8.8.5) with ESMTP id RAA29089 for ; Fri, 11 Jul 1997 17:28:25 -0400 (EDT) Received: (from sklower@localhost) by vangogh.CS.Berkeley.EDU (8.7.Beta.2/8.7.Beta.2) id OAA24587 for ietf-ppp@merit.edu; Fri, 11 Jul 1997 14:27:20 -0700 (PDT) Date: Fri, 11 Jul 1997 14:27:20 -0700 (PDT) From: Keith Sklower Message-Id: <199707112127.OAA24587@vangogh.CS.Berkeley.EDU> To: ietf-ppp@merit.edu Subject: Re[6]: DESE padding implementation poll; proposed language Sender: owner-ietf-ppp@merit.edu Bill Whelan recently wrote: If the plain text ended as you described, the transmitter should have padded to comply with the proposed updated text to replace RFC 1969. You are correct in saying that if it did not do so, my implementation would not play with them. Gerry and I have batted some text back and forth, and the last version I sent to him (which he approved in a phone call this afternoon, but I'ld like to give him the courtesy of reflecting on in a more leisurely way) contains the following two relevant sections, which I hope will clarify the discussion of which numbers and when to pad: 4. DESE Configuration Option for ECP Description The ECP DESE Configuration Option indicates that the issuing implementation is offering to employ this specification for decrypting communications on the link, and may be thought of as a request for its peer to encrypt packets in this manner. The ECP DESE Configuration Option has the following fields, which are transmitted from left to right: Figure 1: ECP DESE Configuration Option 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 | Initial Nonce ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type , to indicate the DESE-bis protocol. The former value 1 indicating the previous DESE specification is deprecated. [snip] 6.1. Padding Considerations Since the DES algorithm operates on blocks of 8 octets, plain text packets which are of length not a multiple of 8 octets must be padded. This can be injurious to the interpretation of some protocols which do not contain an explicit length field in their protocol headers. Since there is no standard directory of protocols which are susceptible to corruption through padding, this can lead to confusion over which protocols should be protected against padding-induced corruption. Consequently, this specification requires that ALL plain text packets not already a multiple of eight octets in length MUST be padded using the unambiguous technique described below. The method of padding is based on that described for the LCP Self- Describing-Padding (SDP) option (as defined in RFC 1570[4]), but differs in two respects: first, maximum-pad value is fixed to be 8, and second, the method is to be applied to ALL packets, not just "specifically identified protcols". Plain text which is not a multiple of 8 octets long MUST be padded prior to encrypting the plain text with sufficient octets in the sequence of octets 1, 2, 3 ... 7 to make the plain text a multiple of 8 octets. Plain text which is already a multiple of 8 octets may require padding with a further 8 octets (1, 2, 3 ... 8). These additional octets MUST be appended prior to encrypting the plain text if the last octet of the plain text has a value of 8 or less. After the peer has decrypted the cipher text, it strips off the Self- Describing-Padding octets, to recreate the original plain text. Note that after decrypting, only the content of the last octet need be examined to determine the presence or absence of a Self Described Pad. However, the peer SHOULD discard the frame if all the octets forming the padding do not match the scheme just described. The padding operation described above is performed independently of whether or not the LCP Self-Describing-Padding (SDP) option has been negotiated. If it has, SDP would be applied to the packet as a whole after it had been ciphered and after the Encryption Protocol Identifiers had been prepended. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Jul 11 19:25:58 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id TAA01776; Fri, 11 Jul 1997 19:24:32 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 11 Jul 1997 19:23:43 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id TAA01745 for ietf-ppp-outgoing; Fri, 11 Jul 1997 19:23:42 -0400 (EDT) Received: from luna.dev.wrq.com ([150.215.23.215]) by merit.edu (8.8.5/8.8.5) with SMTP id TAA01740 for ; Fri, 11 Jul 1997 19:23:36 -0400 (EDT) Received: from localhost (eriko@localhost) by luna.dev.wrq.com (8.6.12/8.6.10) with SMTP id QAA19434; Fri, 11 Jul 1997 16:23:30 -0700 Date: Fri, 11 Jul 1997 16:23:30 -0700 (PDT) From: Erik Olson Reply-To: Erik Olson To: Vernon Schryver cc: ietf-ppp@merit.edu Subject: Re: Multilink Network Protocol Interoperability In-Reply-To: <199707112112.PAA10795@mica.denver.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu On Fri, 11 Jul 1997, Vernon Schryver wrote: > I am assuming that the other guys unilaterally go recycle their > singular IPCP state machine whenever another link is added to the > bundle, even when the second link is added nearly simultaneously with > the first. If that is a valid assumption, then it sounds to me that > you have a bug in your system. The peer can send you an IPCP > Configure-Request at any time (except when IP is completely turned off). > > If they are running two independent IPCP state machines, then they are > hopelessly broken, and I do not see how you can validly converge except > out of random, rather improbably luck. > > One way to check which is broken might be to respond to their extra > IPCP Configure-Requests on the other link in the bundle. Our code has some logic in it to send IPCP on whatever link the last IPCP packet was received. Because of this, we end up sending our responses (single state machine) on different links at different times. They are DEFINITELY running two separate state machines. A look at the packet log revealed this to me immediately. The ID's on the config-requests are independent on the 2 links, and they make sense assuming they are 2 state machines, while they do not if assuming one state machine. The other evidence of this is that our code DID interoperate with this peer when our code was itself broken and using separate state machines for each link. :) We're going to play with this stuff for another day or so and then try and get in touch with the vendor and see what's up. - Erik --- Erik Olson eriko@wrq.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Jul 11 21:47:56 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id VAA02397; Fri, 11 Jul 1997 21:47:50 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 11 Jul 1997 21:47:17 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id VAA02348 for ietf-ppp-outgoing; Fri, 11 Jul 1997 21:47:17 -0400 (EDT) Received: from jaba.rampnet.com (link-rampnet.rampnet.com [206.14.182.236]) by merit.edu (8.8.5/8.8.5) with ESMTP id VAA02339 for ; Fri, 11 Jul 1997 21:47:12 -0400 (EDT) Received: from panda.rampnet.com ([205.158.93.169]) by jaba.rampnet.com (post.office MTA v2.0 0813 ID# 0-18176U100) with SMTP id AAA313; Fri, 11 Jul 1997 16:45:58 -0700 Received: by panda.rampnet.com (SMI-8.6/SMI-SVR4) id QAA13284; Fri, 11 Jul 1997 16:46:17 -0700 Date: Fri, 11 Jul 1997 16:46:17 -0700 From: ashok@rampnet.com (Ashok Ramachandra) Message-Id: <199707112346.QAA13284@panda.rampnet.com> To: ietf-ppp@merit.edu, vjs@mica.denver.sgi.com Subject: Re: Multilink Network Protocol Interoperability X-Sun-Charset: US-ASCII Sender: owner-ietf-ppp@merit.edu > From vjs@mica.denver.sgi.com Fri Jul 11 14:17:31 1997 > Date: Fri, 11 Jul 1997 15:12:12 -0600 > From: vjs@mica.denver.sgi.com (Vernon Schryver) > To: ietf-ppp@merit.edu > Subject: Re: Multilink Network Protocol Interoperability > Sender: owner-ietf-ppp@merit.edu > Content-Length: 2198 > > > From: Erik Olson > > > > > 5. The vendor might not be doing RFC 1990 MP at all, but what is > > > variously called "load balancing", "round robin", or "BF&I multilink." > > > > Would they be negotiating MRRU and Endpoint descriminators in that case? > > This vendor is exchanging MRRU/EID's with us, so I think it's supposed to > > be RFC 1990 MP. > > I agree that if it claims to be doing MP, then it's supposed to be doing MP. > > > > .... > > > ] Even I am facing the same problem with one of the most popular > > > ] vendors, although it is something different in my case. I got one > > > ] channel completely UP, and then when I want the second one he > > > ] comes back with the IPCP-CONF-REQ after the authentication phase. > > > ... > > I don't think that's a full solution. Our state machine does try to > > renegotiate IPCP in this case, and it's fine as long as the two connection > > processes are temporally separated by enough time that the first link has > > completely brought up IPCP before the second starts to come up; at that > > time, link 2 gets an IPCP config request from the peer, and takes IPCP > > down in a renegotiation. When the negotiation on the second link > > succeeds, IPCP comes back up. > > > > HOWEVER, If both links are coming up simultaneously, then the spurious > > IPCP config request on the second line resets the negotiation process in > > progress on link 1, causing non-convergence of IPCP on our end. > > I am assuming that the other guys unilaterally go recycle their > singular IPCP state machine whenever another link is added to the > bundle, even when the second link is added nearly simultaneously with > the first. If that is a valid assumption, then it sounds to me that > you have a bug in your system. The peer can send you an IPCP > Configure-Request at any time (except when IP is completely turned off). > Why should one try to recycle their singular IPCP state machine when it is clearly stated in the RFC -1990 that In the common case, LCP, and the Authentication Control Protocol would be negotiated over each member link. " The Network Protocols themselves and associated control exchanges would normally have been conducted once, on the bundle." If they do it for interoperability the where does the RFC's stand?? R.Ashok > If they are running two independent IPCP state machines, then they are > hopelessly broken, and I do not see how you can validly converge except > out of random, rather improbably luck. > > One way to check which is broken might be to respond to their extra > IPCP Configure-Requests on the other link in the bundle. > > > Vernon Schryver, vjs@sgi.com > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Jul 11 21:52:24 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id VAA02668; Fri, 11 Jul 1997 21:52:22 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 11 Jul 1997 21:52:10 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id VAA02637 for ietf-ppp-outgoing; Fri, 11 Jul 1997 21:52:09 -0400 (EDT) Received: from coppermountain.com (cmcnt.coppermountain.com [206.71.190.2]) by merit.edu (8.8.5/8.8.5) with ESMTP id VAA02628 for ; Fri, 11 Jul 1997 21:52:03 -0400 (EDT) Received: by coppermountain.com from localhost (router,SLMail V2.5); Fri, 11 Jul 1997 16:46:04 -0800 Received: by coppermountain.com from eric (206.71.190.13::mail daemon; unverified,SLMail V2.5); Fri, 11 Jul 1997 16:46:04 -0800 Message-Id: <2.2.32.19970711234636.0032408c@coppermountain.com> X-Sender: "Eric Michelsen" X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 11 Jul 1997 16:46:36 -0700 To: ietf-ppp@merit.edu From: "Eric L. Michelsen" Subject: Re[6]: DESE padding implementation poll; proposed language Sender: owner-ietf-ppp@merit.edu At 02:27 PM 7/11/97 -0700, Keith Sklower wrote: ... >Gerry and I have batted some text back and forth, ... >6.1. Padding Considerations > > Since the DES algorithm operates on blocks of 8 octets, plain text > packets which are of length not a multiple of 8 octets must be > padded. This can be injurious to the interpretation of some > protocols which do not contain an explicit length field in their > protocol headers. > > Since there is no standard directory of protocols which are > susceptible to corruption through padding, this can lead to confusion > over which protocols should be protected against padding-induced > corruption. Consequently, this specification requires that ALL plain > text packets not already a multiple of eight octets in length MUST be > padded using the unambiguous technique described below. This is good. It cuts right to the heart of the issue. >... -- Eric L. Michelsen, Copper Mountain Networks, Inc. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Jul 11 21:48:48 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id VAA02464; Fri, 11 Jul 1997 21:48:44 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 11 Jul 1997 21:48:29 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id VAA02438 for ietf-ppp-outgoing; Fri, 11 Jul 1997 21:48:28 -0400 (EDT) Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.8.5/8.8.5) with SMTP id VAA02434 for ; Fri, 11 Jul 1997 21:48:23 -0400 (EDT) Received: from mica.denver.sgi.com (mica.denver.sgi.com [169.238.67.6]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id QAA07600 for <@sgi.engr.sgi.com:ietf-ppp@merit.edu>; Fri, 11 Jul 1997 16:58:26 -0700 env-from (vjs@mica.denver.sgi.com) Received: (from vjs@localhost) by mica.denver.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA11233 for ietf-ppp@merit.edu; Fri, 11 Jul 1997 17:58:24 -0600 Date: Fri, 11 Jul 1997 17:58:24 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199707112358.RAA11233@mica.denver.sgi.com> To: ietf-ppp@merit.edu Subject: Re: Multilink Network Protocol Interoperability Sender: owner-ietf-ppp@merit.edu > From: ashok@rampnet.com (Ashok Ramachandra) > ... > Why should one try to recycle their singular IPCP state machine > when it is clearly stated in the RFC -1990 that > > In the common case, LCP, and the Authentication Control Protocol > would be negotiated over each member link. " The Network Protocols > themselves and associated control exchanges would normally have been > conducted once, on the bundle." > > If they do it for interoperability the where does the RFC's > stand?? There is no conflict among the RFC's, at least on this issue. The common and convenient case is not the only case you are required to handle. It is a basic fact of PPP that the peer is free to send Configure-Requests at any time. You are required to deal with them gracefully. The primary axiom, "be generous in what you accept and conservative in what you send" as well as the relevant PPP RFC's require you to handle unexpected Configure-Requests. If you receive an LCP Configure-Request and are not using MP or have a single link in the MP bundle, you might be forced to send Configure-Requests of your own for all (previously) open NCP's. That is a pain, but you must nevertheless tolerate unexpected LCP Configure-Requests. A reasonable implementation that receives a spontaneous IPCP Configure-Request will queue at least some IP packets, making the upper layers above PPP think that the link is still alive and not forcing timouts and retransmissions of TCP/IP packets. Who knows why the peer might want to recycle their singular IPCP state machine? Who are you and I to second guess them? We can agree it sounds unlikely to be efficient and likely to be the result of an error. However, maybe they are being paranoid and checking to see that you have only one IPCP state machine. Yes, it seems that in at the precise case at hand, the other system is broken and has two IPCP state machines. Nevertheless, it is a common and eggregious mistake that has cause many interoperability problems to assume that once you reach OPEN, you can never get another Configure-Request. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Sat Jul 12 08:34:19 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id IAA09353; Sat, 12 Jul 1997 08:33:41 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Sat, 12 Jul 1997 08:30:09 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id IAA09318 for ietf-ppp-outgoing; Sat, 12 Jul 1997 08:30:09 -0400 (EDT) Received: from djwhome.demon.co.uk (root@djwhome.demon.co.uk [158.152.19.5]) by merit.edu (8.8.5/8.8.5) with ESMTP id IAA09310 for ; Sat, 12 Jul 1997 08:30:03 -0400 (EDT) Received: (from david@localhost) by djwhome.demon.co.uk (8.7.5/8.7.3) id IAA30403; Fri, 11 Jul 1997 08:08:17 +0100 From: David Woolley Message-Id: <199707110708.IAA30403@djwhome.demon.co.uk> Subject: Re: CHAP MD5 outside USA To: MichaelL@RND.RNDMAIL.rad.co.il (Michael Liwerant) Date: Fri, 11 Jul 1997 08:08:16 +0100 (BST) Cc: ietf-ppp@merit.edu In-Reply-To: <33C4E4CB@smtp-gateway.rad.co.il> from "Michael Liwerant" at Jul 10, 97 03:23:00 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu > > Can somone provide me with information whether the MD5 algorithm (used > also by the PPP CHAP authentication protocol) is implemented in devices > which are operated outside USA ? It is implemented by millions of NTs and Windows '95s. Authentication code is immune from encryption export restrictions. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Sat Jul 12 09:14:40 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id JAA09834; Sat, 12 Jul 1997 09:14:39 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Sat, 12 Jul 1997 09:14:26 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id JAA09799 for ietf-ppp-outgoing; Sat, 12 Jul 1997 09:14:25 -0400 (EDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm012-20.dialip.mich.net [141.211.7.188]) by merit.edu (8.8.5/8.8.5) with SMTP id JAA09788 for ; Sat, 12 Jul 1997 09:14:18 -0400 (EDT) Date: Sat, 12 Jul 97 12:21:23 GMT From: "William Allen Simpson" Message-ID: <6248.wsimpson@greendragon.com> To: ietf-ppp@merit.edu Subject: Re: DESE padding proposed language Sender: owner-ietf-ppp@merit.edu I like this text much better, although it looks like it breaks every implementation. The part that I think is screwy is the "standard directory". None was ever needed. Either the protocol already has a length field, or it does not.... How hard can it be? > From: Keith Sklower > Since the DES algorithm operates on blocks of 8 octets, plain text > packets which are of length not a multiple of 8 octets must be > padded. This can be injurious to the interpretation of some > protocols which do not contain an explicit length field in their > protocol headers. > > Since there is no standard directory of protocols which are > susceptible to corruption through padding, this can lead to confusion > over which protocols should be protected against padding-induced > corruption. Consequently, this specification requires that ALL plain > text packets not already a multiple of eight octets in length MUST be > padded using the unambiguous technique described below. > Never-the-less, if everyone agrees that this is how it should be done, then assigning a new Encyption option number for DESE makes sense. But, if you are doing that, I have another suggestion to make: When encrypting the first packet to be transmitted in the opened state let C[0] be the result of applying E[k] to the Initial Nonce received in the peer's ECP DESE option; otherwise let C[0] be the final block of the previously transmitted packet. The encryption of the initial nonce is rather silly when all the rest of the chaining is done with values in the clear. After all, it only buys you protection on the very first block. Cryptographically unnecessary. Normally, the reason for doing this would be to protect against a nonce that changes in the same fashion as the corresponding bits in the first block, such as using a Sequence Number and TCP. But that only matters when you are generating a new IV for every packet. Here, you are not. It doesn't hurt much, computationally. But I've been asked about repeatedly, and it seems to confuse folks who actually think about it.... And, just to make matters worse, you also have a sequence number, which is not used. I don't see any reason for it. PPP is already serial (it cannot be anything else), and multilink will handle packet resequencing. Why have a sequence number at all? Start the ciphertext on a nice 32-bit boundary, for goodness sake. Oh, yeah, and while I'm thinking about it, your chaining rationale is not quite correct. Go read my latest *ipsec-cbc* draft. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Sat Jul 12 17:44:28 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id RAA15223; Sat, 12 Jul 1997 17:44:25 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Sat, 12 Jul 1997 17:43:58 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id RAA15205 for ietf-ppp-outgoing; Sat, 12 Jul 1997 17:43:58 -0400 (EDT) Received: from SantaClara01.pop.internex.net (santaclara01.pop.InterNex.Net [205.158.3.18]) by merit.edu (8.8.5/8.8.5) with ESMTP id RAA15201 for ; Sat, 12 Jul 1997 17:43:53 -0400 (EDT) Received: from flowpnt.flowpoint.com ([192.84.210.69]) by SantaClara01.pop.internex.net (post.office MTA v1.9.3 ID# 0-11030) with SMTP id AAA23093; Sat, 12 Jul 1997 14:43:50 -0700 Received: from zeus.flowpoint.com (ws67.flowpoint.com) by flowpnt.flowpoint.com (4.1/SMI-4.1) id AA05459; Sat, 12 Jul 97 14:19:29 PDT Received: by zeus.flowpoint.com (4.1/SMI-4.1) id AA02615; Sat, 12 Jul 97 14:19:29 PDT Date: Sat, 12 Jul 1997 14:19:28 -0700 (PDT) From: Philip Rakity X-Sender: pmr@zeus To: Keith Sklower Cc: karl@ascend.com, ietf-ppp@merit.edu Subject: Re: DESE padding implementation poll proposed Language In-Reply-To: <199707102124.OAA17241@vangogh.CS.Berkeley.EDU> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Keith, Three comments on the proposed text. Section 4 -------- Type to indicated ..... It is necessary to change the type. This just creates an incompatibility against all of the working implementations. I am not aware of any implementations that do not support SDP. Section 6.1 2nd Paragraph ------------------------- Change: Consequently, this specification requires that ALL plain text packets not already a multiple of eight octets in length must be padded using ... To: Consequently, this specification requires that ALL plain text packets must be padded using Justification: The padding rules must be applied even if the text is eight bytes long since the last byte may be in the SDP range, thus the original text is contradictory to what is required. 5th Paragraph last sentence --------------------------- Change: ... plain text if the last octet of the plain text has a vaule of less than 8. to: ... plain text is the last octet of the plain text has a vaule between 1 and 8 inclusive. Justification: 0 in the last byte requires no padding; but it is less the 8! kind regards, Philip Rakity FlowPoint - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Sat Jul 12 20:37:40 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id UAA16912; Sat, 12 Jul 1997 20:37:33 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Sat, 12 Jul 1997 20:37:06 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id UAA16894 for ietf-ppp-outgoing; Sat, 12 Jul 1997 20:37:05 -0400 (EDT) Received: from vangogh.CS.Berkeley.EDU (vangogh.CS.Berkeley.EDU [128.32.33.5]) by merit.edu (8.8.5/8.8.5) with ESMTP id UAA16890 for ; Sat, 12 Jul 1997 20:37:01 -0400 (EDT) Received: (from sklower@localhost) by vangogh.CS.Berkeley.EDU (8.7.Beta.2/8.7.Beta.2) id RAA01803; Sat, 12 Jul 1997 17:35:56 -0700 (PDT) Date: Sat, 12 Jul 1997 17:35:56 -0700 (PDT) From: Keith Sklower Message-Id: <199707130035.RAA01803@vangogh.CS.Berkeley.EDU> To: pmr@flowpoint.com, sklower@cs.berkeley.edu Subject: Re: DESE padding implementation poll proposed Language Cc: ietf-ppp@merit.edu, karl@ascend.com Sender: owner-ietf-ppp@merit.edu Philip, Thank you for taking the trouble to read carefully and think about the proposed language. I certainly agree with your last change (to make it clear that packets already a multiple of 8 bytes in length that end in 0 require no additional padding), but I don't agree with your second statement, and don't understand the first one. It is just as wrong to say that ALL packets must be padded, because there are a small class of packets that do not require it (those already a multiple of 8 bytes, and whose last byte of plain text is outside of the range 1 though 8, inclusive, as you yourself point out). Section 4 -------- Type to indicated ..... It is necessary to change the type. This just creates an incompatibility against all of the working implementations. I am not aware of any implementations that do not support SDP. Concerning your first point, might it be possible that you meant to say "it is *NOT* necessary" instead of "it is necessary"? And also do you really mean to say all implementation suuport SDP (or could you have meant "everybody who has already implemented DESE according to the common interpretation of RFC1959)? But even if that is what you mean, I still disagree in the most emphatic and strongest terms. The issue is not whether all existing implementations support SDP, but whether somebody in the future might read RFC1969 and ignore the one that obsoletes it, and implement DESE according to an interpretation that I proposed on the mailing list a couple of days ago (i.e. the one I intended when I wrote the original draft) and thereby fail to interoperate. The number we are changing is not the PPP protocol number, not the LCP option number, but the ECP encryption category number. I'm digging in my heels on this one, and although Bill Simpson and I have disagreed on many things in the past, even he agrees that it is not a bad idea to up the encryption category number. Do we *really, really, really* have to submit this one to another ballot and harangue? Could you please cut me some slack? - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Sat Jul 12 20:58:15 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id UAA17119; Sat, 12 Jul 1997 20:58:14 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Sat, 12 Jul 1997 20:58:04 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id UAA17101 for ietf-ppp-outgoing; Sat, 12 Jul 1997 20:58:03 -0400 (EDT) Received: from vangogh.CS.Berkeley.EDU (vangogh.CS.Berkeley.EDU [128.32.33.5]) by merit.edu (8.8.5/8.8.5) with ESMTP id UAA17097 for ; Sat, 12 Jul 1997 20:57:59 -0400 (EDT) Received: (from sklower@localhost) by vangogh.CS.Berkeley.EDU (8.7.Beta.2/8.7.Beta.2) id RAA01859; Sat, 12 Jul 1997 17:56:54 -0700 (PDT) Date: Sat, 12 Jul 1997 17:56:54 -0700 (PDT) From: Keith Sklower Message-Id: <199707130056.RAA01859@vangogh.CS.Berkeley.EDU> To: ietf-ppp@merit.edu, wsimpson@greendragon.com Subject: Re: sequence numbers in DESE-bis Sender: owner-ietf-ppp@merit.edu From owner-ietf-ppp@merit.edu Sat Jul 12 06:20:45 1997 From: "William Allen Simpson" I like this text much better, although it looks like it breaks every implementation. The part that I think is screwy is the "standard directory". None was ever needed. Either the protocol already has a length field, or it does not.... How hard can it be? We are in violent agreement on this one; unfotunately I was overruled. > From: Keith Sklower > Since the DES algorithm operates on blocks of 8 octets, plain text > packets which are of length not a multiple of 8 octets must be > padded. This can be injurious to the interpretation of some > protocols which do not contain an explicit length field in their > protocol headers. > > Since there is no standard directory of protocols which are > susceptible to corruption through padding, this can lead to confusion > over which protocols should be protected against padding-induced > corruption. Consequently, this specification requires that ALL plain > text packets not already a multiple of eight octets in length MUST be > padded using the unambiguous technique described below. > Never-the-less, if everyone agrees that this is how it should be done, then assigning a new Encyption option number for DESE makes sense. But, if you are doing that, I have another suggestion to make: When encrypting the first packet to be transmitted in the opened state let C[0] be the result of applying E[k] to the Initial Nonce received in the peer's ECP DESE option; otherwise let C[0] be the final block of the previously transmitted packet. [explanation deleted] It doesn't hurt much, computationally. But I've been asked about repeatedly, and it seems to confuse folks who actually think about it.... Other people have asked for this change. Since most current implementators of RFC1969 already are using the new rules, the only change required for the language I proposed would be in the ECP negotiation and to check for some new value besides one. The change you propose would require only another few lines of code change, but wouldn't be very great, and something I would be agreable to changeing if a majority of current implementors agree. And, just to make matters worse, you also have a sequence number, which is not used. I don't see any reason for it. PPP is already serial (it cannot be anything else), and multilink will handle packet resequencing. Why have a sequence number at all? Gerry originally proposed this. He did it for the case where you are encrypting multilink headers and you drop a couple of packets (I think). Motorola has a patent concerning using explicit resets of an encrypted link when the decrypted packets no longer make sense, and we wanted to avoid it. (also). Oh, yeah, and while I'm thinking about it, your chaining rationale is not quite correct. Go read my latest *ipsec-cbc* draft. I'll read it on monday. Would you advise holding up submitting the new draft until after I understand and incorporate it? - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Sun Jul 13 13:49:05 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id NAA24620; Sun, 13 Jul 1997 13:48:44 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Sun, 13 Jul 1997 13:44:00 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id NAA24563 for ietf-ppp-outgoing; Sun, 13 Jul 1997 13:43:59 -0400 (EDT) Received: from SantaClara01.pop.internex.net (santaclara01.pop.InterNex.Net [205.158.3.18]) by merit.edu (8.8.5/8.8.5) with ESMTP id NAA24559 for ; Sun, 13 Jul 1997 13:43:54 -0400 (EDT) Received: from flowpnt.flowpoint.com ([192.84.210.69]) by SantaClara01.pop.internex.net (post.office MTA v1.9.3 ID# 0-11030) with SMTP id AAA18280; Sun, 13 Jul 1997 10:43:51 -0700 Received: from zeus.flowpoint.com (ws67.flowpoint.com) by flowpnt.flowpoint.com (4.1/SMI-4.1) id AA06110; Sun, 13 Jul 97 10:49:56 PDT Received: by zeus.flowpoint.com (4.1/SMI-4.1) id AA03475; Sun, 13 Jul 97 10:49:55 PDT Date: Sun, 13 Jul 1997 10:49:54 -0700 (PDT) From: Philip Rakity X-Sender: pmr@zeus To: Keith Sklower Cc: ietf-ppp@merit.edu Subject: Re: Re[6]: DESE padding implementation poll; proposed language In-Reply-To: <199707112127.OAA24587@vangogh.CS.Berkeley.EDU> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Keith, I understand your point concerning the protocol number; but do not understand how assigning a new number helps. Old implementations, like mine will still continue to do SDP and thus will not work with new implementations of the OLD RFC that do not do SDP. Adding a new type makes it clearer what is supposed to happen, but does not fix the problem of folks implementating the obselete RFC. I suggest that the words as follows be changed from Since there is no standard directory of protocols which are susceptible to corruption through padding, this can lead to confusion over which protocols should be protected against padding-induced corruption. Consequently, this specification requires that ALL plain text packets not already a multiple of eight octets in length MUST be padded using the unambiguous technique described below. To; Since there is no standard directory of protocols which are susceptible to corruption through padding, this can lead to confusion over which protocols should be protected against padding-induced corruption. Consequently, this specification requires that ALL packets be processed using the unambiguous technique described below. Justification: It is the technique that must be applied to determine if padding is needed. kind regards, Philip Rakity - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Jul 14 03:56:42 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id DAA03791; Mon, 14 Jul 1997 03:56:25 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 14 Jul 1997 03:55:44 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id DAA03768 for ietf-ppp-outgoing; Mon, 14 Jul 1997 03:55:43 -0400 (EDT) Received: from vangogh.CS.Berkeley.EDU (vangogh.CS.Berkeley.EDU [128.32.33.5]) by merit.edu (8.8.5/8.8.5) with ESMTP id DAA03762 for ; Mon, 14 Jul 1997 03:55:36 -0400 (EDT) Received: (from sklower@localhost) by vangogh.CS.Berkeley.EDU (8.7.Beta.2/8.7.Beta.2) id AAA08863; Mon, 14 Jul 1997 00:54:30 -0700 (PDT) Date: Mon, 14 Jul 1997 00:54:30 -0700 (PDT) From: Keith Sklower Message-Id: <199707140754.AAA08863@vangogh.CS.Berkeley.EDU> To: pmr@flowpoint.com, sklower@cs.berkeley.edu Subject: Re: Re[6]: DESE padding implementation poll; proposed language Cc: ietf-ppp@merit.edu Sender: owner-ietf-ppp@merit.edu From pmr@flowpoint.com Sun Jul 13 10:42:55 1997 Keith, I understand your point concerning the protocol number; but do not understand how assigning a new number helps. Old implementations, like mine will still continue to do SDP and thus will not work with new implementations of the OLD RFC that do not do SDP. Adding a new type makes it clearer what is supposed to happen, but does not fix the problem of folks implementating the obselete RFC. I guess I didn't make the language clear enough. Implementations adhereing to the new rules should reject the old protocol number (1), and only agree to do the new number. Although there is still an interoperability problem between systems implementing "1", there won't be a problem between systems implementing "new" and when somebody thinks that they've implemented "1" ignoring the fact that RFC1969 has been obsoleted, when they go to test they will discover that none of the major players will talk to them. I suggest that the words as follows be changed from Since there is no standard directory of protocols which are susceptible to corruption through padding, this can lead to confusion over which protocols should be protected against padding-induced corruption. Consequently, this specification requires that ALL plain text packets not already a multiple of eight octets in length MUST be padded using the unambiguous technique described below. To; Since there is no standard directory of protocols which are susceptible to corruption through padding, this can lead to confusion over which protocols should be protected against padding-induced corruption. Consequently, this specification requires that ALL packets be processed using the unambiguous technique described below. Justification: It is the technique that must be applied to determine if padding is needed. I'll split the difference. Gerry really wanted to emphasize the fact that it was the plain text that was being padded. Also, the MUST was a special RFC word, although the ALL was only capitalized to emphasize the difference with the previous spec. If you want to make it clear that the technique must be applied to all packets (even if it doesn't change some of them), then we should put it that way: "Consquently, this specification requires that the following unambiguous technique MUST be applied to ALL plain text packets." kind regards, Philip Rakity Respectfully (albeit argumentatively) yours, Keith Sklower - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Jul 14 05:40:35 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id FAA04662; Mon, 14 Jul 1997 05:39:32 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 14 Jul 1997 05:35:34 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id FAA04626 for ietf-ppp-outgoing; Mon, 14 Jul 1997 05:35:33 -0400 (EDT) Received: from directors.rdl.co.uk (directors.rdl.co.uk [193.119.77.2]) by merit.edu (8.8.5/8.8.5) with ESMTP id FAA04620 for ; Mon, 14 Jul 1997 05:35:19 -0400 (EDT) Received: from imaccgw.rdl.co.uk (imaccgw.rdl.co.uk [193.240.106.205]) by directors.rdl.co.uk (8.7.3/8.7.3) with SMTP id KAA24449; Mon, 14 Jul 1997 10:35:12 +0100 (BST) Received: from ccMail by imaccgw.rdl.co.uk (IMA Internet Exchange 1.04b) id 3c9f27b0; Mon, 14 Jul 97 10:33:47 +0100 Mime-Version: 1.0 Date: Mon, 14 Jul 1997 10:25:20 +0100 Message-ID: <3c9f27b0@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re: RFC 1990 cud put the PPP negotiation into a loop !!! To: ietf-ppp@merit.edu, shenoyh Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: owner-ietf-ppp@merit.edu >In reply to my query on PPP going into a loop, nobody seems to have >considered para 3, section 8, page 20 of rfc 1990 ...... Well, I can't speak for John Bray and Tom Coradetti, but I did consider it (although I may not have explained myself very well). >However the following statements by Mr. Jonathan.Goodchild seem to >contradict each other and the problem of PPP going into a loop will be >clear if they are studied better : > >>There is no such requirement. When sending a configure request, P2 uses >>its own EPD (u or v). Once LCP negotiation is complete, it compares the >>peer's EPD for the new link with the peer's EPD already negotiated on >>the bundle - if they don't match then the link can't be added to the >>bundle. So, y will match with b2's negotiated end-point descriminator >>and e1 will be added to b2. > >>Sorry, this is completely wrong. If P2 is clever enough to realise >that P1 wishes to add both links to bundle b2, then it would send EPD v >>instead of u in its Configure-Request (after all, it has already >>received the Configure-Request from P1). I can see no contradiction - maybe I didn't word the statements clearly. Let me try again. ---- e1 ----- (x)b1 | |--------------------------| |b1 (u) | P1 | | P2 | (y)b2 | |--------------------------| |b2 (v) ---- e2 ----- There are 4 possibilities when the links are started. Case 1: x==y, u==v i.e. normal multilink First, link e1 is started. P1 sends EPD x, and P2 sends EPD u, establishing bundle b1. Then link e2 is started. P1 sends EPD y (but y==x), and P2 sends EPD v but (v==u). P2 sees that x==y so adds e2 to bundle b1, and P1 sees that u==v and also adds e2 to the bundle. Case 2: x!=y, u!=v Link e1 establishes bundle b1. When e2 is started, P1 sees that EPD u != v, so has to starte a new bundle b2 for e2. Similarly P2 sees that x != y, and puts e2 into b2. Case 3: x==y, u!=v Again, link e1 established bundle b1. When e2 is started, P1 sends EPD x again (as y==x), and P2 sends EPD v. P1 sees that u|=v, and so has to establish a new bundle b2. P2 knows that it is 2 endpoints, and therefore has to put e2 into bundle b2. Case 4: x!=y, u==v. This is the same as case 3, only reversed. P1 sends EPD y on e2, and x!=y, so 2 bundles are established. Now, let's consider your scenario. There are 2 possible starting points, case 2 and case 4. Starting from case 4, (because it is simpler) two separate bundles are established. P1 decides to try to combine the two bundles, and so renegotiates LCP on link e1, and sends EPD y this time. P2 sends EPD v again (as u==v). Now P2 sees that the EPD on e1 is now the same as the EPD on e2, and therefore adds the link to the bundle. Similarly, P1 sees that the EPD (i.e. u) on e1 is the same as that for e2, and adds e1 to b2. No problems there, then. The sitution you seem to be concerned about starts from Case 2, (i.e. x!=y, u!=v). P1 decides to try to combine the two bundles. P1 must be aware that its attempt may not succeed, as I explain below. Anyway, P1 renegotiates LCP on e1 by sending a Configure-Request with EPD y. P2 receives the Conf-Req, and knows it also has to renegotiate LCP on e1. Now there are 2 possibilities: a) P2 insists on having two separate bundles, and so sends a Configure-Request with EPD u again. We end up with 2 bundles, as this is the same as case 3 above. P1 must realise at this point that any further attempt to combine the bundles will be fruitless, unless it is initiated by P2. b) P2 is clever, and realises that P1 is trying to combine the 2 bundles, and therefore sends EPD v in its Configure-Request. Now we have the situation that the EPDs are the same at both end, so e1 can be added to bundle b2. So where are the loops ? --- Jonathan Goodchild - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Jul 14 07:26:55 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id HAA05385; Mon, 14 Jul 1997 07:26:43 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 14 Jul 1997 07:26:27 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id HAA05363 for ietf-ppp-outgoing; Mon, 14 Jul 1997 07:26:26 -0400 (EDT) Received: from atlas.xylogics.com (atlas.xylogics.com [132.245.33.7]) by merit.edu (8.8.5/8.8.5) with ESMTP id HAA05359 for ; Mon, 14 Jul 1997 07:26:21 -0400 (EDT) Received: from vulcan.xylogics.com (vulcan.xylogics.com [132.245.33.8]) by atlas.xylogics.com (8.7.3/8.7.3) with SMTP id HAA20383; Mon, 14 Jul 1997 07:25:09 -0400 (EDT) Received: from localhost by vulcan.xylogics.com id AA03972 (4.1/UK-doug-951219); Mon, 14 Jul 97 07:25:09 EDT Message-Id: <3972.9707141125@vulcan.xylogics.com> To: Chun Ye Cc: ietf-ppp@merit.edu Subject: Re: MLPPP on links with different bandwidth In-Reply-To: Your message of "Fri, 11 Jul 1997 09:34:32 PDT." <199707111634.AA24422@phecda.nsd.3com.com> Date: Mon, 14 Jul 1997 07:25:08 -0400 From: James Carlson Sender: owner-ietf-ppp@merit.edu In message <199707111634.AA24422@phecda.nsd.3com.com>, Chun Ye writes: > [Ron Gilaad:] > > Using links of different rate require that the fragmentation will be > > according to the link rate. Since RFC 1990 does not handle with this issue > > I have implemented a proprietary fragmentation algorithm. > > > > I would like to know if there is anyone who deals with MLPPP over links > > with different rate or who transfer FR over MLPPP. > > Yes, 3Com's NetBuilder flatforms support MLPPP over a total number of 8 > links of any bandwidth. As do our products. (Hmm. How'd you arrive at 8? It sure seems easier to place no limits at all ...) Actually, the interesting part is not the link speed. It's the delay across the link multiplied by the speed. In general, as long as the delay across the various links is well-controlled (or at least well-known), then buffering and delay in MP will both be (or can be made to be) small. Otherwise, both will be large. (Fragmentation and transmission should be done in a manner which minimizes the buffering at the remote end. I can't say that I know of a general algorithm for doing this. It might make an interesting research topic.) In particular, bundling a link using error control (such as a modem link) with one which does not (such as a raw synchronous channel) will require extensive buffering or will suffer from terrible performance as buffers are lost (assuming that the receiver has a limit on its MP receive queue). Even bundling just two modem links together can be problematic when one link goes into rate renegotiation or (worse) retrain. Since FR doesn't do error control, I wouldn't be as worried about it. The latency across the FR link should be fairly well bounded and should not cause buffering problems unless the speeds involved in the non-FR link(s) are extraordinary. --- James Carlson , Prin Engr Tel: +1 508 916 4351 Bay Networks - Annex I/F Develop. / 8 Federal ST +1 800 225 3317 Mail Stop BL08-05 / Billerica MA 01821-3548 Fax: +1 508 916 4789 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Jul 14 11:30:39 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id LAA10300; Mon, 14 Jul 1997 11:30:21 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 14 Jul 1997 11:29:12 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id LAA10250 for ietf-ppp-outgoing; Mon, 14 Jul 1997 11:29:05 -0400 (EDT) Received: from lynx.europe.shiva.com (lynx.europe.shiva.com [134.191.64.5]) by merit.edu (8.8.5/8.8.5) with ESMTP id LAA10232 for ; Mon, 14 Jul 1997 11:28:05 -0400 (EDT) Received: from eurohub.europe.shiva.com (eurohub.europe.shiva.com [134.191.64.200]) by lynx.europe.shiva.com (8.8.5/8.8.5) with ESMTP id QAA25466; Mon, 14 Jul 1997 16:26:31 +0100 (BST) Received: from Lotus Notes (PU Serial #1281) by eurohub.europe.shiva.com (PostalUnion/SMTP(tm) v2.1.7 for Windows NT(tm)) id AA-1997Jul14.152149.1281.533091; Mon, 14 Jul 1997 16:23:37 +0100 From: gerry@europe.shiva.com (CN=Gerry Meyer/OU=Eng/OU=EDI/O=Shiva) To: sklower@cs.berkeley.edu (Keith Sklower) Cc: Ietf-Ppp@merit.edu (Ietf-Ppp), Wsimpson@Greendragon.Com (Wsimpson) Message-ID: <1997Jul14.152149.1281.533091@eurohub.europe.shiva.com> X-Conversion-ID: X-Mailer: Lotus Notes via PostalUnion/SMTP for Windows NT Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Organization: Shiva Europe Ltd Date: Mon, 14 Jul 1997 16:23:37 +0100 Subject: Re: sequence numbers in DESE-bis Sender: owner-ietf-ppp@merit.edu Keith Sklower 13/07/97 02:11 To: ietf-ppp @ EUROGATE, wsimpson @ EUROGATE cc: Subject: Re: sequence numbers in DESE-bis Bill simpson wrote : > And, just to make matters worse, you also have a sequence number, which > is not used. I don't see any reason for it. PPP is already serial (it > cannot be anything else), and multilink will handle packet resequencing. > Why have a sequence number at all? Keith Sklower responded: >Gerry originally proposed this. He did it for the case where you are >encrypting multilink headers and you drop a couple of packets (I think). >Motorola has a patent concerning using explicit resets of an encrypted >link when the decrypted packets no longer make sense, and we wanted to avoid >it. The sequence numbers are used to detect and correct for packet loss. While multilink sequence numbers could be used with bundle encryption, they would not work with link encryption. Also you would have to negotiate multilink when you did not otherwise require it for a single link. Gerry - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Jul 14 12:43:58 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id MAA19562; Fri, 11 Jul 1997 12:28:18 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 11 Jul 1997 12:27:57 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id MAA19539 for ietf-ppp-outgoing; Fri, 11 Jul 1997 12:27:55 -0400 (EDT) Received: from janus.3com.com (janus.3com.com [129.213.128.99]) by merit.edu (8.8.5/8.8.5) with ESMTP id MAA19530 for ; Fri, 11 Jul 1997 12:27:43 -0400 (EDT) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by janus.3com.com (8.8.2/8.8.5) with ESMTP id JAA15076; Fri, 11 Jul 1997 09:26:34 -0700 (PDT) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.2/8.8.5) with ESMTP id JAA01601; Fri, 11 Jul 1997 09:25:41 -0700 (PDT) Received: from bridge2.nsd.3com.com (bridge2.NSD.3Com.COM [129.213.96.3]) by chicago.nsd.3com.com (8.8.2/8.8.5) with ESMTP id JAA02518; Fri, 11 Jul 1997 09:24:38 -0700 (PDT) Received: from phecda.nsd.3com.com (phecda.nsd.3com.com [129.213.48.6]) by bridge2.nsd.3com.com (8.8.2/8.8.2) with SMTP id JAA04836; Fri, 11 Jul 1997 09:26:31 -0700 (PDT) Received: by phecda.nsd.3com.com id AA24422 (5.65c/IDA-1.4.4-910730); Fri, 11 Jul 1997 09:34:33 -0700 From: Chun Ye Message-Id: <199707111634.AA24422@phecda.nsd.3com.com> Subject: Re: MLPPP on links with different bandwidth To: rongil@radmail.rad.co.il Date: Fri, 11 Jul 1997 09:34:32 -0700 (PDT) Cc: ietf-ppp@merit.edu In-Reply-To: <3.0.2.32.19970711113924.0072c5a8@radmail.rad.co.il> from "rongil@radmail.rad.co.il" at Jul 11, 97 11:39:24 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu > > Hi, > > Does anyone uses MLPPP over links with different bandwidth and not just > over 64k B channels? I am using a bundle which is a mixture of ISDN and FR > links in order to transfer FR over MLPPP (Called Multilink Frame Relay -MFR). > > Using links of different rate require that the fragmentation will be > according to the link rate. Since RFC 1990 does not handle with this issue > I have implemented a proprietary fragmentation algorithm. > > I would like to know if there is anyone who deals with MLPPP over links > with different rate or who transfer FR over MLPPP. > > Ron. > > =================================================================== > | Ron Gilaad | FAX: 972-3-6475924 | > | RAD data communications ltd. | PHONE: 972-3-6455758 (Office) | > | 31 Habarzel St. | 972-3-6490064 (Home) | > | Tel-Aviv 69710 | E-mail: rongil@radmail.rad.co.il | > | Israel | | > =================================================================== > Yes, 3Com's NetBuilder flatforms support MLPPP over a total number of 8 links of any bandwidth. --Chun -- +----------------------------------------------+ | Chun Ye | | 3Com Corporation Phone: (408) 764-5094 | | 5400 Bayfront Plaza Fax: (408) 764-5002 | | Santa Clara, CA 95052 Email: cye@3com.com | +----------------------------------------------+ - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Jul 14 13:44:55 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id NAA14403; Mon, 14 Jul 1997 13:44:46 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 14 Jul 1997 13:44:14 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id NAA14371 for ietf-ppp-outgoing; Mon, 14 Jul 1997 13:44:13 -0400 (EDT) Received: from SantaClara01.pop.internex.net (santaclara01.pop.InterNex.Net [205.158.3.18]) by merit.edu (8.8.5/8.8.5) with ESMTP id NAA14351 for ; Mon, 14 Jul 1997 13:44:00 -0400 (EDT) Received: from flowpnt.flowpoint.com ([192.84.210.69]) by SantaClara01.pop.internex.net (post.office MTA v1.9.3 ID# 0-11030) with SMTP id AAA5591; Mon, 14 Jul 1997 10:43:55 -0700 Received: from zeus.flowpoint.com (ws67.flowpoint.com) by flowpnt.flowpoint.com (4.1/SMI-4.1) id AA06913; Mon, 14 Jul 97 09:59:32 PDT Received: by zeus.flowpoint.com (4.1/SMI-4.1) id AA03770; Mon, 14 Jul 97 09:59:32 PDT Date: Mon, 14 Jul 1997 09:59:31 -0700 (PDT) From: Philip Rakity X-Sender: pmr@zeus To: Keith Sklower Cc: sklower@cs.berkeley.edu, ietf-ppp@merit.edu Subject: Re: Re[6]: DESE padding implementation poll; proposed language In-Reply-To: <199707140754.AAA08863@vangogh.CS.Berkeley.EDU> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Keith, The proposed changes are fine. Philip On Mon, 14 Jul 1997, Keith Sklower wrote: > From pmr@flowpoint.com Sun Jul 13 10:42:55 1997 > > Keith, > > I understand your point concerning the protocol number; but do not > understand how assigning a new number helps. > > Old implementations, like > mine will still continue to do SDP and thus will not work with new > implementations of the OLD RFC that do not do SDP. Adding a new type > makes it clearer what is supposed to happen, but does not fix the problem > of folks implementating the obselete RFC. > > I guess I didn't make the language clear enough. Implementations adhereing > to the new rules should reject the old protocol number (1), and only > agree to do the new number. Although there is still an interoperability > problem between systems implementing "1", there won't be a problem between > systems implementing "new" and when somebody thinks that they've implemented > "1" ignoring the fact that RFC1969 has been obsoleted, when they go to test > they will discover that none of the major players will talk to them. > > I suggest that the words as follows be changed from > > Since there is no standard directory of protocols which are > susceptible to corruption through padding, this can lead to confusion > over which protocols should be protected against padding-induced > corruption. Consequently, this specification requires that ALL plain > text packets not already a multiple of eight octets in length MUST be > padded using the unambiguous technique described below. > > > To; > > Since there is no standard directory of protocols which are > susceptible to corruption through padding, this can lead to confusion > over which protocols should be protected against padding-induced > corruption. Consequently, this specification requires that ALL packets > be processed using the unambiguous technique described below. > > > Justification: > > It is the technique that must be applied to determine if padding is > needed. > > > I'll split the difference. Gerry really wanted to emphasize the fact > that it was the plain text that was being padded. Also, the MUST was > a special RFC word, although the ALL was only capitalized to emphasize > the difference with the previous spec. If you want to make > it clear that the technique must be applied to all packets (even if it > doesn't change some of them), then we should put it that way: > > "Consquently, this specification requires that the following unambiguous > technique MUST be applied to ALL plain text packets." > > kind regards, > Philip Rakity > > Respectfully (albeit argumentatively) yours, > Keith Sklower > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Jul 14 13:07:08 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id NAA13063; Mon, 14 Jul 1997 13:06:53 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 14 Jul 1997 13:05:52 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id NAA13012 for ietf-ppp-outgoing; Mon, 14 Jul 1997 13:05:51 -0400 (EDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm012-24.dialip.mich.net [141.211.7.192]) by merit.edu (8.8.5/8.8.5) with SMTP id NAA13004 for ; Mon, 14 Jul 1997 13:05:43 -0400 (EDT) Date: Mon, 14 Jul 97 16:51:16 GMT From: "William Allen Simpson" Message-ID: <6266.wsimpson@greendragon.com> To: ietf-ppp@merit.edu Subject: Re: sequence numbers in DESE-bis Sender: owner-ietf-ppp@merit.edu > From: gerry@europe.shiva.com (CN=Gerry Meyer/OU=Eng/OU=EDI/O=Shiva) > The sequence numbers are used to detect and correct for packet loss. > > While multilink sequence numbers could be used with bundle encryption, they > would not work with link encryption. Also you would have to negotiate > multilink > when you did not otherwise require it for a single link. > I beg to differ. The sequence numbers neither detect nor correct for packet loss. What is the detection algorithm? What is the correction algorithm? PPP is a serial link protocol. Packets cannot be "lost". They can however fail the FCS test. The PPP implementation already is required to know about and count these events. The SN will not enhance this test. Indeed, the only "correction" I see is to ignore a couple of packets, because they will be hopelessly garbled. The SN will not correct the garbage. The SN is not included in any calculation. Remove it. This will also align the fields on nice 32-bit boundaries. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Jul 14 16:53:36 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id QAA26575; Mon, 14 Jul 1997 16:53:25 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 14 Jul 1997 16:52:00 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id QAA26315 for ietf-ppp-outgoing; Mon, 14 Jul 1997 16:51:59 -0400 (EDT) Received: from vangogh.CS.Berkeley.EDU (vangogh.CS.Berkeley.EDU [128.32.33.5]) by merit.edu (8.8.5/8.8.5) with ESMTP id QAA26232 for ; Mon, 14 Jul 1997 16:51:36 -0400 (EDT) Received: (from sklower@localhost) by vangogh.CS.Berkeley.EDU (8.7.Beta.2/8.7.Beta.2) id NAA14729; Mon, 14 Jul 1997 13:49:57 -0700 (PDT) Date: Mon, 14 Jul 1997 13:49:57 -0700 (PDT) From: Keith Sklower Message-Id: <199707142049.NAA14729@vangogh.CS.Berkeley.EDU> To: gerry@europe.shiva.com, sklower@cs.berkeley.edu Subject: Re: sequence numbers in DESE-bis Cc: Ietf-Ppp@merit.edu, Wsimpson@Greendragon.Com Sender: owner-ietf-ppp@merit.edu I have mailed the following document to internet-drafts. Bill Simpson has made two proposals which I agree are worthy of consideration (that the interpretation of the nonce be changed and that the sequence numbers be omitted), and I even agree that from a logical point of view one can recover from dropped packets (due to line noise or bad FCS) in either the dese-over-multilink or multilink-over-dese case. However, this draft incorporates neither change, because it would require a much greater change to existing implementations than merely certifying what the asserted majority of folks already are doing with their currently implmenetations of DESE. If a consensus on the mailing list emerges to make both of those changes I will be happy to submit draft-ietf-pppext-des-encrypt-03.txt . . . PPP Working Group K. Sklower INTERNET-DRAFT University of California, Berkeley Obsoletes: RFC-1969 G. Meyer Category: Informational Shiva Date: July 14, 1997 The PPP DES Encryption Protocol, Version 2 (DESE-bis) draft-ietf-pppext-des-encrypt-02.txt Status of This Memo This document is a submission to the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ietf-ppp@merit.edu mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. The PPP Encryption Control Protocol (ECP) [2] provides a method to negotiate and utilize encryption protocols over PPP encapsulated links. This document provides specific details for the use of the DES standard [5, 6] for encrypting PPP encapsulated packets. Sklower & Meyer Expires January 14th, 1998 [Page 1] INTERNET-DRAFT PPP DES Encryption v2 July 1997 Acknowledgements The authors extend hearty thanks to Fred Baker of Cisco, Philip Rakity of Flowpoint, and William Simpson of Daydreamer for helpful improvements to the clarity and correctness of the document. Table of Contents 1. Introduction ................................................ 2 1.1. Motivation ................................................ 2 1.2. Conventions ............................................... 3 2. General Overview ............................................ 3 3. Structure of This Specification ............................. 4 4. DESE Configuration Option for ECP ........................... 4 5. Packet Format for DESE ...................................... 5 6. Encryption .................................................. 6 6.1. Padding Considerations .................................... 7 6.2. Generation of the Ciphertext .............................. 8 6.3. Retrieval of the Plaintext ................................ 8 6.4. Recovery after Packet Loss ................................ 9 7. MRU Considerations .......................................... 9 8. Security Considerations ..................................... 9 9. References .................................................. 10 10. Authors' Addresses ......................................... 10 11. Expiration Date of this Draft .............................. 11 1. Introduction 1.1. Motivation The purpose of this draft is two-fold: to show how one specifies the necessary details of a "data" or "bearer" protocol given the context of the generic PPP Encryption Control Protocol, and also to provide at least one commonly-understood means of secure data transmission between PPP implementations. The DES encryption algorithm is a well studied, understood and widely implemented encryption algorithm. The DES cipher was designed for efficient implementation in hardware, and consequently may be relatively expensive to implement in software. However, its pervasiveness makes it seem like a reasonable choice for a "model" encryption protocol. Source code implementing DES in the "Electronic Code Book Mode" can be found in [7]. US export laws forbid the inclusion of compilation- ready source code in this document. Sklower & Meyer Expires January 14th, 1998 [Page 2] INTERNET-DRAFT PPP DES Encryption v2 July 1997 1.2. Conventions The following language conventions are used in the items of specification in this document: o MUST, SHALL or MANDATORY -- the item is an absolute requirement of the specification. o SHOULD or RECOMMENDED -- the item should generally be followed for all but exceptional circumstances. o MAY or OPTIONAL -- the item is truly optional and may be followed or ignored according to the needs of the implementor. 2. General Overview The purpose of encrypting packets exchanged between two PPP implementations is to attempt to insure the privacy of communication conducted via the two implementations. The encryption process depends on the specification of an encryption algorithm and a shared secret (usually involving at least a key) between the sender and receiver. Generally, the encryptor will take a PPP packet including the protocol field, apply the chosen encryption algorithm, place the resulting cipher text (and in this specification, an explicit sequence number) in the information field of another PPP packet. The decryptor will apply the inverse algorithm and interpret the resulting plain text as if it were a PPP packet which had arrived directly on the interface. The means by which the secret becomes known to both communicating elements is beyond the scope of this document; usually some form of manual configuration is involved. Implementations might make use of PPP authentication, or the EndPoint Identifier Option described in PPP Multilink [3], as factors in selecting the shared secret. If the secret can be deduced by analysis of the communication between the two parties, then no privacy is guaranteed. While the US Data Encryption Standard (DES) algorithm [5, 6] provides multiple modes of use, this specification selects the use of only one mode in conjunction with the PPP Encryption Control Protol (ECP): the Cipher Block Chaining (CBC) mode. In addition to the US Government publications cited above, the CBC mode is also discussed in [7], although no C source code is provided for it per se. The initialization vector for this mode is deduced from an explicit 64-bit nonce, which is exchanged in the clear during the negotiation Sklower & Meyer Expires January 14th, 1998 [Page 3] INTERNET-DRAFT PPP DES Encryption v2 July 1997 phase. The 56-bit key required by all DES modes is established as a shared secret between the implementations. One reason for choosing the chaining mode is that it is generally thought to require more computation resources to deduce a 64 bit key used for DES encryption by analysis of the encrypted communication stream when chaining mode is used, compared with the situation where each block is encrypted separately with no chaining. Certainly, identical sequences of plaintext will produce different ciphers when chaining mode is in effect, thus complicating analysis. However, if chaining is to extend beyond packet boundaries, both the sender and receiver must agree on the order the packets were encrypted. Thus, this specification provides for an explicit 16 bit sequence number to sequence decryption of the packets. This mode of operation even allows recovery from occasional packet loss; details are also given below. 3. Structure of This Specification The PPP Encryption Control Protocol (ECP), provides a framework for negotiating parameters associated with encryption, such as choosing the algorithm. It specifies the assigned numbers to be used as PPP protocol numbers for the "data packets" to be carried as the associated "data protocol", and describes the state machine. Thus, a specification for use in that matrix need only describe any additional configuration options required to specify a particular algorithm, and the process by which one encrypts/decrypts the information once the Opened state has been achieved. 4. DESE Configuration Option for ECP Description The ECP DESE Configuration Option indicates that the issuing implementation is offering to employ this specification for decrypting communications on the link, and may be thought of as a request for its peer to encrypt packets in this manner. The ECP DESE Configuration Option has the following fields, which are transmitted from left to right: Sklower & Meyer Expires January 14th, 1998 [Page 4] INTERNET-DRAFT PPP DES Encryption v2 July 1997 Figure 1: ECP DESE Configuration Option 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 | Initial Nonce ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type , to indicate the DESE-bis protocol. The former value 1 indicating the previous DESE specification is deprecated, i.e. systems implementing this specification MUST NOT offer the former value 1 in a configure-request and MUST configure-reject the former value on receipt of a configure-request containing it. Length 10 Initial Nonce This field is an 8 byte quantity which is used by the peer implementation to encrypt the first packet transmitted after the sender reaches the opened state. To guard against replay attacks, the implementation SHOULD offer a different value during each ECP negotiation. An example might be to use the number of seconds since Jan 1st, 1970 (GMT/UT) in the upper 32 bits, and the current number of nanoseconds relative to the last second mark in the lower 32 bits. Its formulaic role is described in the Encryption section below. 5. Packet Format for DESE Description The DESE packets themselves have the following fields: Sklower & Meyer Expires January 14th, 1998 [Page 5] INTERNET-DRAFT PPP DES Encryption v2 July 1997 Figure 2: DES Encryption Protocol Packet Format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address | Control | 0000 | Protocol ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Seq. No. High | Seq. No. Low | Ciphertext ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address and Control These fields MUST be present unless the PPP Address and Control Field Compression option (ACFC) has been negotiated. Protocol ID The value of this field is 0x53 or 0x55; the latter indicates that ciphertext includes headers for the Multilink Protocol, and REQUIRES that the Individual Link Encryption Control Protocol has reached the opened state. The leading zero MAY be absent if the PPP Protocol Field Compression option (PFC) has been negotiated. Sequence Number These 16-bit numbers are assigned by the encryptor sequentially starting with 0 (for the first packet transmitted once ECP has reached the opened state. Ciphertext The generation of this data is described in the next section. 6. Encryption Once the ECP has reached the Opened state, the sender MUST NOT apply the encryption procedure to LCP packets nor ECP packets. If the async control character map option has been negotiated on the link, the sender applies mapping after the encryption algorithm has been run. Sklower & Meyer Expires January 14th, 1998 [Page 6] INTERNET-DRAFT PPP DES Encryption v2 July 1997 The encryption algorithm is generally to pad the Protocol and Information fields of a PPP packet to some multiple of 8 bytes, and apply DES in Chaining Block Cipher mode with a 56-bit key K. There are a lot of details concerning what constitutes the Protocol and Information fields, in the presence or non-presence of Multilink, and whether the ACFC and PFC options have been negotiated, and the sort of padding chosen. Regardless of whether ACFC has been negotiated on the link, the sender applies the encryption procedure to only that portion of the packet excluding the address and control field. If the Multilink Protocol has been negotiated and encryption is to be construed as being applied to each link separately, then the encryption procedure is to be applied to the (possibly extended) protocol and information fields of the packet in the Multilink Protocol. If the Multilink Protocol has been negotiated and encryption is to be construed as being applied to the bundle, then the multilink procedure is to be applied to the resulting DESE packets. 6.1. Padding Considerations Since the DES algorithm operates on blocks of 8 octets, plain text packets which are of length not a multiple of 8 octets must be padded. This can be injurious to the interpretation of some protocols which do not contain an explicit length field in their protocol headers. Since there is no standard directory of protocols which are susceptible to corruption through padding, this can lead to confusion over which protocols should be protected against padding-induced corruption. Consequently, this specification requires that the unambiguous technique described below MUST be applied to ALL plain text packets. The method of padding is based on that described for the LCP Self- Describing-Padding (SDP) option (as defined in RFC 1570[4]), but differs in two respects: first, maximum-pad value is fixed to be 8, and second, the method is to be applied to ALL packets, not just "specifically identified protcols". Plain text which is not a multiple of 8 octets long MUST be padded prior to encrypting the plain text with sufficient octets in the sequence of octets 1, 2, 3 ... 7 to make the plain text a multiple of 8 octets. Sklower & Meyer Expires January 14th, 1998 [Page 7] INTERNET-DRAFT PPP DES Encryption v2 July 1997 Plain text which is already a multiple of 8 octets may require padding with a further 8 octets (1, 2, 3 ... 8). These additional octets MUST be appended prior to encrypting the plain text if the last octet of the plain text has a value of 8 or less. After the peer has decrypted the cipher text, it strips off the Self- Describing-Padding octets, to recreate the original plain text. Note that after decrypting, only the content of the last octet need be examined to determine the presence or absence of a Self Described Pad. However, the peer SHOULD discard the frame if all the octets forming the padding do not match the scheme just described. The padding operation described above is performed independently of whether or not the LCP Self-Describing-Padding (SDP) option has been negotiated. If it has, SDP would be applied to the packet as a whole after it had been ciphered and after the Encryption Protocol Identifiers had been prepended. 6.2. Generation of the Ciphertext In this discussion, E[k] will denote the basic DES cipher determined by a 56-bit key k acting on 64 bit blocks. and D[k] will denote the corresponding decryption mechanism. The padded plaintext described in the previous section then becomes a sequence of 64 bit blocks P[i] (where i ranges from 1 to n). The circumflex character (^) represents the bit-wise exclusive-or operation applied to 64-bit blocks. When encrypting the first packet to be transmitted in the opened state let C[0] be the result of applying E[k] to the Initial Nonce received in the peer's ECP DESE option; otherwise let C[0] be the final block of the previously transmitted packet. The ciphertext for the packet is generated by the iterative process C[i] = E[k](P[i] ^ C[i-1]) for i running between 1 and n. 6.3. Retrieval of the Plaintext When decrypting the first packet received in the opened state, let C[0] be the result of applying E[k] to the Initial Nonce transmitted in the ECP DESE option. The first packet will have sequence number zero. For subsequent packets, let C[0] be the final block of the previous packet in sequence space. Decryption is then accomplished by Sklower & Meyer Expires January 14th, 1998 [Page 8] INTERNET-DRAFT PPP DES Encryption v2 July 1997 P[i] = C[i-1] ^ D[k](C[i]), for i running between 1 and n. 6.4. Recovery after Packet Loss Packet loss is detected when there is a discontinuity in the sequence numbers of consecutive packets. Suppose packet number N - 1 has an unrecoverable error or is otherwise lost, but packets N and N + 1 are received correctly. Since the algorithm in the previous section requires C[0] for packet N to be C[last] for packet N - 1, it will be impossible to decode packet N. However, all packets N + 1 and following can be decoded in the usual way, since all that is required is the last block of ciphertext of the previous packet (in this case packet N, which WAS received). 7. MRU Considerations Because padding can occur, and because there is an additional protocol field in effect, implementations should take into account the growth of the packets. As an example, if PFC had been negotiated, and if the MRU before had been exactly a multiple of 8, then the plaintext resulting combining a full sized data packets with a one byte protocol field would require an additional 7 bytes of padding, and the sequence number would be an additional 2 bytes so that the information field in the DESE protocol is now 10 bytes larger than that in the original packet. Because the convention is that PPP options are independent of each other, negotiation of DESE does not, by itself, automatically increase the MRU value. 8. Security Considerations Security issues are the primary subject of this draft. This proposal relies on exterior and unspecified methods for authentication and retrieval of shared secrets. It proposes no new technology for privacy, but merely describes a convention for the application of the DES cipher to data transmission between PPP implementation. Any methodology for the protection and retrieval of shared secrets, and any limitations of the DES cipher are relevant to the use described here. Sklower & Meyer Expires January 14th, 1998 [Page 9] INTERNET-DRAFT PPP DES Encryption v2 July 1997 9. References [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, Daydreamer, July 1994. [2] Meyer, G., "The PPP Encryption Protocol (ECP)", RFC 1968, Spider Systems. June 1996 [3] Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T. Corradeti, "The PPP Multilink Protocol (MP)", RFC 1990, UC Berkeley, August, 1996. [4] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, Daydreamer, January 1994. [5] National Bureau of Standards, "Data Encryption Standard", FIPS PUB 46 (January 1977). [6] National Bureau of Standards, "DES Modes of Operation", FIPS PUB 81 (December 1980). [7] Schneier, B., "Applied Cryptography - Protocols Algorithms, and source code in C", John Wiley & Sons, Inc. 1994. There is an errata associated with the book, and people can get a copy by sending e-mail to schneier@counterpane.com. 10. Authors' Addresses Keith Sklower Computer Science Department 384 Soda Hall, Mail Stop 1776 University of California Berkeley, CA 94720-1776 Phone: (510) 642-9587 EMail: sklower@CS.Berkeley.EDU Gerry M. Meyer Shiva Europe Ltd. Stanwell Street Edinburgh EH6 5NG Scotland, UK Phone: (UK) 131 561 4223 Fax: (UK) 131 561 4083 Email: gerry@europe.shiva.com Sklower & Meyer Expires January 14th, 1998 [Page 10] INTERNET-DRAFT PPP DES Encryption v2 July 1997 11. Expiration Date of this Draft January 14th, 1998 Sklower & Meyer Expires January 14th, 1998 [Page 11] - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Jul 14 17:17:31 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id RAA29693; Mon, 14 Jul 1997 17:17:29 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 14 Jul 1997 17:16:51 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id RAA29610 for ietf-ppp-outgoing; Mon, 14 Jul 1997 17:16:50 -0400 (EDT) Received: from norway.it.earthlink.net (norway-c.it.earthlink.net [204.119.177.49]) by merit.edu (8.8.5/8.8.5) with ESMTP id RAA29597 for ; Mon, 14 Jul 1997 17:16:43 -0400 (EDT) Received: from papa (pool033.max1.montebello.ca.us.dynip.earthlink.net [206.85.113.33]) by norway.it.earthlink.net (8.8.5/8.8.5) with SMTP id OAA12047; Mon, 14 Jul 1997 14:16:07 -0700 (PDT) Message-Id: <3.0.32.19970714141407.00aa88f0@earthlink.net> X-Sender: rmonsour@earthlink.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 14 Jul 1997 14:14:13 -0700 To: Keith Sklower From: Bob Monsour Subject: Re: sequence numbers in DESE-bis Cc: gerry@europe.shiva.com, sklower@cs.berkeley.edu, Ietf-Ppp@merit.edu, Wsimpson@Greendragon.Com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu I have a question regarding the padding mechanism (repeated below). Would an implementation be considered non-conformant to this spec if it adds 8 bytes of padding regardless of whether the last octet of the plain text has a value of 8 or less? I know it's certainly less bandwidth efficient, but would such a frame be discarded on receipt by another implementation? We are developing a chip implementation, but it does not support this padding nuance. Thanks. -Bob > Plain text which is already a multiple of 8 octets may require > padding with a further 8 octets (1, 2, 3 ... 8). These additional > octets MUST be appended prior to encrypting the plain text if the > last octet of the plain text has a value of 8 or less. > > After the peer has decrypted the cipher text, it strips off the Self- > Describing-Padding octets, to recreate the original plain text. > > Note that after decrypting, only the content of the last octet need > be examined to determine the presence or absence of a Self Described > Pad. However, the peer SHOULD discard the frame if all the octets > forming the padding do not match the scheme just described. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Jul 14 17:27:58 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id RAA01169; Mon, 14 Jul 1997 17:27:48 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 14 Jul 1997 17:27:16 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id RAA01068 for ietf-ppp-outgoing; Mon, 14 Jul 1997 17:27:15 -0400 (EDT) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by merit.edu (8.8.5/8.8.5) with SMTP id RAA01059 for ; Mon, 14 Jul 1997 17:27:08 -0400 (EDT) Received: from spud.ascend.com (fw-ext.ascend.com [198.4.92.5]) by drawbridge.ascend.com (8.6.12/8.6.12) with ESMTP id OAA02406 for ; Mon, 14 Jul 1997 14:27:07 -0700 Received: from ascend.com by ascend.com with ESMTP id OAA22568 for ; Mon, 14 Jul 1997 14:27:05 -0700 Received: from gump.eng.ascend.com (gump.eng.ascend.com [206.65.212.67]) by wopr.eng.ascend.com (8.6.12/8.6.12) with ESMTP id OAA12149 for ; Mon, 14 Jul 1997 14:26:34 -0700 Received: from carp.morningstar.com.ascend.com (karl@carp.MorningStar.Com [137.175.81.4]) by gump.eng.ascend.com (8.6.12/8.6.12) with SMTP id OAA17388 for ; Mon, 14 Jul 1997 14:26:33 -0700 Date: Mon, 14 Jul 1997 14:26:33 -0700 Message-Id: <199707142126.OAA17388@gump.eng.ascend.com> From: Karl Fox To: ietf-ppp@merit.edu Subject: New DESE number needed? Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ietf-ppp@merit.edu Do we need a new DESE option number for the updated version? Please make your opinions known; let's come to a consensus. -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 15 01:28:35 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id BAA10882; Tue, 15 Jul 1997 01:28:19 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 15 Jul 1997 01:27:28 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id BAA10841 for ietf-ppp-outgoing; Tue, 15 Jul 1997 01:27:28 -0400 (EDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm002-18.dialip.mich.net [141.211.7.154]) by merit.edu (8.8.5/8.8.5) with SMTP id BAA10828 for ; Tue, 15 Jul 1997 01:27:18 -0400 (EDT) Date: Tue, 15 Jul 97 05:21:15 GMT From: "William Allen Simpson" Message-ID: <6271.wsimpson@greendragon.com> To: ietf-ppp@merit.edu Subject: Re: New DESE number needed? Sender: owner-ietf-ppp@merit.edu I had hoped that no number was needed, but based on the comments and the draft text, have been convinced that a new number is needed. The current draft is sufficiently incompatible with the PS that it really is necessary. > From: Karl Fox > Do we need a new DESE option number for the updated version? Please > make your opinions known; let's come to a consensus. > WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 15 01:28:33 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id BAA10878; Tue, 15 Jul 1997 01:28:18 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 15 Jul 1997 01:27:23 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id BAA10834 for ietf-ppp-outgoing; Tue, 15 Jul 1997 01:27:22 -0400 (EDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm002-18.dialip.mich.net [141.211.7.154]) by merit.edu (8.8.5/8.8.5) with SMTP id BAA10826 for ; Tue, 15 Jul 1997 01:27:16 -0400 (EDT) Date: Tue, 15 Jul 97 05:16:57 GMT From: "William Allen Simpson" Message-ID: <6270.wsimpson@greendragon.com> To: ietf-ppp@merit.edu Subject: stripping padding Sender: owner-ietf-ppp@merit.edu Bob, it sure looks like no implementation could tell that you had added the padding on every packet, without going back one extra byte. There's nothing about going back an extra byte. It only looks at the _last_ byte to determine whether padding is present, so I think you are safe. Bandwidth inefficient, but safe. > From: Bob Monsour > I have a question regarding the padding mechanism (repeated below). Would > an implementation be considered non-conformant to this spec if it adds 8 > bytes of padding regardless of whether the last octet of the plain text has > a value of 8 or less? I know it's certainly less bandwidth efficient, but > would such a frame be discarded on receipt by another implementation? We > are developing a chip implementation, but it does not support this padding > nuance. > > > Plain text which is already a multiple of 8 octets may require > > padding with a further 8 octets (1, 2, 3 ... 8). These additional > > octets MUST be appended prior to encrypting the plain text if the > > last octet of the plain text has a value of 8 or less. > > > > After the peer has decrypted the cipher text, it strips off the Self- > > Describing-Padding octets, to recreate the original plain text. > > > > Note that after decrypting, only the content of the last octet need > > be examined to determine the presence or absence of a Self Described > > Pad. However, the peer SHOULD discard the frame if all the octets > > forming the padding do not match the scheme just described. > WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 15 03:42:56 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id DAA12033; Tue, 15 Jul 1997 03:42:53 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 15 Jul 1997 03:42:39 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id DAA12015 for ietf-ppp-outgoing; Tue, 15 Jul 1997 03:42:39 -0400 (EDT) Received: from lynx.europe.shiva.com (lynx.europe.shiva.com [134.191.64.5]) by merit.edu (8.8.5/8.8.5) with ESMTP id DAA12011 for ; Tue, 15 Jul 1997 03:42:34 -0400 (EDT) Received: from eurohub.europe.shiva.com (eurohub.europe.shiva.com [134.191.64.200]) by lynx.europe.shiva.com (8.8.5/8.8.5) with ESMTP id IAA09738; Tue, 15 Jul 1997 08:41:54 +0100 (BST) Received: from Lotus Notes (PU Serial #1281) by eurohub.europe.shiva.com (PostalUnion/SMTP(tm) v2.1.7 for Windows NT(tm)) id AA-1997Jul15.073825.1281.533464; Tue, 15 Jul 1997 08:38:54 +0100 From: gerry@europe.shiva.com (CN=Gerry Meyer/OU=Eng/OU=EDI/O=Shiva) To: wsimpson@greendragon.com (William Allen Simpson) Cc: ietf-ppp@merit.edu (ietf-ppp) Message-ID: <1997Jul15.073825.1281.533464@eurohub.europe.shiva.com> X-Conversion-ID: X-Mailer: Lotus Notes via PostalUnion/SMTP for Windows NT Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Organization: Shiva Europe Ltd Date: Tue, 15 Jul 1997 08:38:54 +0100 Subject: Re: sequence numbers in DESE-bis Sender: owner-ietf-ppp@merit.edu In todays world of running PPP on Frame Relay or with VPNs, packets can and will be lost and there will be no indication through FCS. The sequence number is used to trap the first packet after packet loss. This packet will be garbled - and you don't want to feed it into your state machine demultiplexer causing it to issue spurious code or protocol rejects - or worse. Gerry William Allen Simpson on 14/07/97 18:38:54 To: ietf-ppp @ EUROGATE cc: Subject: Re: sequence numbers in DESE-bis > From: gerry@europe.shiva.com (CN=Gerry Meyer/OU=Eng/OU=EDI/O=Shiva) > The sequence numbers are used to detect and correct for packet loss. > > While multilink sequence numbers could be used with bundle encryption, they > would not work with link encryption. Also you would have to negotiate > multilink > when you did not otherwise require it for a single link. > I beg to differ. The sequence numbers neither detect nor correct for packet loss. What is the detection algorithm? What is the correction algorithm? PPP is a serial link protocol. Packets cannot be "lost". They can however fail the FCS test. The PPP implementation already is required to know about and count these events. The SN will not enhance this test. Indeed, the only "correction" I see is to ignore a couple of packets, because they will be hopelessly garbled. The SN will not correct the garbage. The SN is not included in any calculation. Remove it. This will also align the fields on nice 32-bit boundaries. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 ------ Message Header Follows ------ Received: from lynx.europe.shiva.com by eurohub.europe.shiva.com (PostalUnion/SMTP(tm) v2.1.7 for Windows NT(tm)) id AA-1997Jul14.183809.1281.294931; Mon, 14 Jul 1997 18:38:09 +0100 Received: from merit.edu (merit.edu [198.108.1.42]) by lynx.europe.shiva.com (8.8.5/8.8.5) with ESMTP id SAA29521 for ; Mon, 14 Jul 1997 18:41:06 +0100 (BST) Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id NAA13018; Mon, 14 Jul 1997 13:05:52 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 14 Jul 1997 13:05:52 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id NAA13012 for ietf-ppp-outgoing; Mon, 14 Jul 1997 13:05:51 -0400 (EDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm012-24.dialip.mich.net [141.211.7.192]) by merit.edu (8.8.5/8.8.5) with SMTP id NAA13004 for ; Mon, 14 Jul 1997 13:05:43 -0400 (EDT) Date: Mon, 14 Jul 97 16:51:16 GMT From: "William Allen Simpson" Message-ID: <6266.wsimpson@greendragon.com> To: ietf-ppp@merit.edu Subject: Re: sequence numbers in DESE-bis Sender: owner-ietf-ppp@merit.edu - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 15 04:20:41 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id EAA12274; Tue, 15 Jul 1997 04:20:39 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 15 Jul 1997 04:20:26 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id EAA12256 for ietf-ppp-outgoing; Tue, 15 Jul 1997 04:20:26 -0400 (EDT) Received: from directors.rdl.co.uk (directors.rdl.co.uk [193.119.77.2]) by merit.edu (8.8.5/8.8.5) with ESMTP id EAA12252 for ; Tue, 15 Jul 1997 04:20:18 -0400 (EDT) Received: from imaccgw.rdl.co.uk (imaccgw.rdl.co.uk [193.240.106.205]) by directors.rdl.co.uk (8.7.3/8.7.3) with SMTP id JAA16088 for ; Tue, 15 Jul 1997 09:20:15 +0100 (BST) Received: from ccMail by imaccgw.rdl.co.uk (IMA Internet Exchange 1.04b) id 3cb32670; Tue, 15 Jul 97 09:18:47 +0100 Mime-Version: 1.0 Date: Tue, 15 Jul 1997 09:10:03 +0100 Message-ID: <3cb32670@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re: sequence numbers in DESE-bis To: ietf-ppp@merit.edu Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: owner-ietf-ppp@merit.edu From: William Allen Simpson >> The sequence numbers are used to detect and correct for packet >> loss. >> >> While multilink sequence numbers could be used with bundle encryption, >> they would not work with link encryption. Also you would have to >> negotiate multilink when you did not otherwise require it for a >> single link. > >I beg to differ. The sequence numbers neither detect nor correct for >packet loss. What is the detection algorithm? What is the correction >algorithm? > >PPP is a serial link protocol. Packets cannot be "lost". What about when PPP is run over Frame Relay or L2TP ? Can't packets be "lost" then ? >They can however fail the FCS test. The PPP implementation already is >required to know about and count these events. The SN will not >enhance this test. But it is required if packets can be lost. --- Jonathan Goodchild Racal Datacom - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 15 10:50:33 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id KAA16645; Tue, 15 Jul 1997 10:49:24 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 15 Jul 1997 10:41:23 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id KAA16449 for ietf-ppp-outgoing; Tue, 15 Jul 1997 10:41:22 -0400 (EDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm035-01.dialip.mich.net [141.211.7.12]) by merit.edu (8.8.5/8.8.5) with SMTP id KAA16445 for ; Tue, 15 Jul 1997 10:41:17 -0400 (EDT) Date: Tue, 15 Jul 97 14:16:39 GMT From: "William Allen Simpson" Message-ID: <6273.wsimpson@greendragon.com> To: ietf-ppp@merit.edu Subject: Re: New DESE number needed? Sender: owner-ietf-ppp@merit.edu I have been asked privately to expand upon my previous message. Better that I do it publically. The only valid reason why a new number is needed with the current draft is that a good implementer of the previously published RFC could follow it exactly, and not be compatible with the new draft. Specifically, the required use of and removal of padding on IP (which has an integral length) is different in the new draft. Please remember, I am not concerned with bad implementations that did not follow the RFC exactly. Good implementations should not be punished for the sins of the bad. As a matter of deployment and operations, we either need a draft that is merely a clarification of the PS RFC to retain the same number, or must use a new number to reflect the non-interoperability of this new draft. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 15 11:58:25 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id LAA18372; Tue, 15 Jul 1997 11:58:18 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 15 Jul 1997 11:56:22 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id LAA18316 for ietf-ppp-outgoing; Tue, 15 Jul 1997 11:56:22 -0400 (EDT) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by merit.edu (8.8.5/8.8.5) with SMTP id LAA18311 for ; Tue, 15 Jul 1997 11:56:15 -0400 (EDT) Received: from spud.ascend.com (fw-ext.ascend.com [198.4.92.5]) by drawbridge.ascend.com (8.6.12/8.6.12) with ESMTP id IAA02761; Tue, 15 Jul 1997 08:56:09 -0700 Received: from ascend.com by ascend.com with ESMTP id IAA03239; Tue, 15 Jul 1997 08:56:08 -0700 Received: from gump.eng.ascend.com (gump.eng.ascend.com [206.65.212.67]) by wopr.eng.ascend.com (8.6.12/8.6.12) with ESMTP id IAA11398; Tue, 15 Jul 1997 08:55:37 -0700 Received: from carp.morningstar.com.ascend.com (karl@carp.MorningStar.Com [137.175.81.4]) by gump.eng.ascend.com (8.6.12/8.6.12) with SMTP id IAA20429; Tue, 15 Jul 1997 08:55:35 -0700 Date: Tue, 15 Jul 1997 08:55:35 -0700 Message-Id: <199707151555.IAA20429@gump.eng.ascend.com> From: Karl Fox To: "William Allen Simpson" Cc: ietf-ppp@merit.edu Subject: Re: New DESE number needed? In-Reply-To: <6273.wsimpson@greendragon.com> References: <6273.wsimpson@greendragon.com> Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ietf-ppp@merit.edu William Allen Simpson writes: > The only valid reason why a new number is needed with the current draft > is that a good implementer of the previously published RFC could follow > it exactly, and not be compatible with the new draft. > > Specifically, the required use of and removal of padding on IP (which > has an integral length) is different in the new draft. Would it help if padding was a MUST to add but only a MAY or SHOULD for removal? I think that would be backward compatible with all current implementations I've heard about. -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 15 14:23:32 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id OAA21725; Tue, 15 Jul 1997 14:23:16 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 15 Jul 1997 14:20:56 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id OAA21675 for ietf-ppp-outgoing; Tue, 15 Jul 1997 14:20:55 -0400 (EDT) Received: from zoom.eicon.com (zoom.eicon.com [192.219.20.250]) by merit.edu (8.8.5/8.8.5) with SMTP id OAA21670 for ; Tue, 15 Jul 1997 14:20:51 -0400 (EDT) Received: from admin.eicon.com by zoom.eicon.com with SMTP id AA17252 (5.67a/IDA-1.5 for ); Tue, 15 Jul 1997 14:26:52 -0400 Received: by admin.eicon.com with Microsoft Mail id <33CBEA05@admin.eicon.com>; Tue, 15 Jul 97 14:22:13 PDT From: Pierre-Luc Provencal To: ietf-ppp Subject: CHAP Challenge Request Date: Tue, 15 Jul 97 14:22:00 PDT Message-Id: <33CBEA05@admin.eicon.com> X-Mailer: Microsoft Mail V3.0 Sender: owner-ietf-ppp@merit.edu Hi, We have a serious concern when using a T/A, which operates MLPPP with BACP, as a server. The authentication is performed by the host PC which is configured with the usernames and secrets; therefore the T/A itself does not have access to any authentication configuration. This forces the T/A: 1) To duplicate the challenge coming from the PC on both links when initiating the connection. 2) And also raises the problem that the T/A must use old challenges when BAP drops and reconnects individual links since the PC is not aware of the "link manipulation". We realize that this situation weakens the authentication process and we would like to propose the following modification to the RFC 1994: Add a new CHAP packet that would request a CHAP challenge to the authenticator. The new sequence would look like this: SERVER T/A CLIENT Connection initiated. Authentication successfull. BAP drops one link. BAP brings it up again. Authentication must be performed. <======== CHAP challenge request (initiated by the T/A) CHAP challenge =======================================> <================================================ CHAP response CHAP success/failure ===================================> This new sequence would solve both above mentionned problems by forcing the server to send new challenges every time this situation is encountered. We would appreciate any comments that you may have about this suggestion. Pierre-Luc Provencal Eicon Technology Corp. pierrelp@eicon.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 15 14:44:13 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id OAA22108; Tue, 15 Jul 1997 14:44:12 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 15 Jul 1997 14:42:31 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id OAA22060 for ietf-ppp-outgoing; Tue, 15 Jul 1997 14:42:31 -0400 (EDT) Received: from vangogh.CS.Berkeley.EDU (vangogh.CS.Berkeley.EDU [128.32.33.5]) by merit.edu (8.8.5/8.8.5) with ESMTP id OAA22056 for ; Tue, 15 Jul 1997 14:42:27 -0400 (EDT) Received: (from sklower@localhost) by vangogh.CS.Berkeley.EDU (8.7.Beta.2/8.7.Beta.2) id LAA21783; Tue, 15 Jul 1997 11:41:01 -0700 (PDT) Date: Tue, 15 Jul 1997 11:41:01 -0700 (PDT) From: Keith Sklower Message-Id: <199707151841.LAA21783@vangogh.CS.Berkeley.EDU> To: ietf-ppp@merit.edu, karl@ascend.com, wsimpson@greendragon.com Subject: Re: New DESE number needed? Sender: owner-ietf-ppp@merit.edu From owner-ietf-ppp@merit.edu Tue Jul 15 09:12:46 1997 Date: Tue, 15 Jul 1997 08:55:35 -0700 William Allen Simpson writes: > The only valid reason why a new number is needed with the current draft > is that a good implementer of the previously published RFC could follow > it exactly, and not be compatible with the new draft. > > Specifically, the required use of and removal of padding on IP (which > has an integral length) is different in the new draft. Would it help if padding was a MUST to add but only a MAY or SHOULD for removal? I think that would be backward compatible with all current implementations I've heard about. I'm pretty sure this doesn't fix the problem, which is when a hypothetical implementation doesn't pad an non-VJ-IP packet which by random bad luck ends in a padding sequence, sends it to a system which MAY (and does) remove the padding. So the backward fix would be to FORBID the receiver from removing the padding. (Letting the IP layer do it). In a phone conversation with Karl, I tried to persuade him that this particular interation between a hypothetical bad new implementor (who implemented to the letter of RFC1969 overlooking that it had been obsoleted) and somebody obeying the new rules would not fail catastrophically, but would have packets discarded in the IP layer for a statistically rare case, and would be very, very difficult to debug. Whereas, if said implementor came up against a new system that rejected the old protocol number outright, it would be trivial to debug. I offered this in response to Karl's position that as a practical matter, all existing implementations already play by the new rules, and that the IETF shouldn't cater to people who don't take the trouble to verify that RFC's have been obsoleted, and that upping the version number (even though it represents a trivial change to the existing implementations), does represent an economic burden for the company's to upgrade their existing customers. So, the consensus we should come to, is whether it is worth the economic investment to buy an insurance policy guaranteeing future interoperability with new implementors. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 15 15:21:24 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id PAA23047; Tue, 15 Jul 1997 15:21:19 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 15 Jul 1997 15:19:26 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id PAA22988 for ietf-ppp-outgoing; Tue, 15 Jul 1997 15:19:25 -0400 (EDT) Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.8.5/8.8.5) with SMTP id PAA22973 for ; Tue, 15 Jul 1997 15:19:12 -0400 (EDT) Received: from mica.denver.sgi.com (mica.denver.sgi.com [169.238.67.6]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id MAA01165 for <@sgi.engr.sgi.com:ietf-ppp@merit.edu>; Tue, 15 Jul 1997 12:19:03 -0700 env-from (vjs@mica.denver.sgi.com) Received: (from vjs@localhost) by mica.denver.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA05727 for ietf-ppp@merit.edu; Tue, 15 Jul 1997 13:18:58 -0600 Date: Tue, 15 Jul 1997 13:18:58 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199707151918.NAA05727@mica.denver.sgi.com> To: ietf-ppp@merit.edu Subject: Re: CHAP Challenge Request Sender: owner-ietf-ppp@merit.edu > From: Pierre-Luc Provencal > ... > We have a serious concern when using a T/A, which operates MLPPP It is mostly the trade-rags and those whose primary source of information are the trade rags (instead of the RFCs) who call the protocol "MLPPP". No matter what you think of the choice in names, the official name is "MP". > with > BACP, as a server. The authentication is performed by the host PC which > is configured with the usernames and secrets; therefore the T/A itself > does not have access to any authentication configuration. Why have the T/A fiddle with CHAP packets at all? PAP and CHAP differ. > This forces the T/A: > > 1) To duplicate the challenge coming from the PC on both links when > initiating the connection. That is one way, but I think there is a better way. > 2) And also raises the problem that the T/A must use old challenges when > BAP drops and reconnects individual links It is not BAP that "drops and reconnects individual links", but MP. BAP is only a useless appendage to the useless BACP. (Yes, BACP had slim justification before L2TP for making multiple boxes in a hunt group appear to be one to peers. Still, BACP is dead, just in time for its birth.) > since the PC is not aware of > the "link manipulation". THe PC does not need to know about link manipulation to respond to CHAP challenges. CHAP and PAP differ in this area. > We realize that this situation weakens the authentication process and we > would like to propose the following modification to the RFC 1994: Add a > new CHAP packet that would request a CHAP challenge to the authenticator. > The new sequence would look like this: > ... > Authentication must be performed. > <======== CHAP challenge request (initiated by the T/A) > > CHAP challenge =======================================> > > <================================================ CHAP response > > CHAP success/failure ===================================> How does that differ from sending an LCP Configure-Request, other than in speed? If one PPP peer sends a Configure-Request, the peer must not only respond with a Configure-Ack and its own COnfigure-Request, but it must also respond with a Chap challenge (if CHAP is negotiated). > We would appreciate any comments that you may have about this suggestion. Instead of hoping to get the whole rest of the world to deploy new firmware and software to support protocol extensions that other people do not need (another of the mistakes in BACP/BAP), why not have your T/A pass all CHAP challenges through to the PC, and remember their source link in the MP bundle? The CHAP protocol has always required the PC to be able to respond to CHAP challenges at any time, and as often as the peer cares to send them. In your T/A situation, the PC might wonder why the peer is sending so many CHAP challenges, but the PC would have to just respond. Your T/A could remember that the challenge ID #123 came from the first link while that with ID #124 came from the second link in the bundle, and forward the responses as appropriate. You might want to forge some CHAP status answers to the PC and keep the real ones in the T/A so that the PC does not get them out of order. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 15 15:51:53 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id PAA23741; Tue, 15 Jul 1997 15:51:50 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 15 Jul 1997 15:49:45 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id PAA23679 for ietf-ppp-outgoing; Tue, 15 Jul 1997 15:49:44 -0400 (EDT) Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.8.5/8.8.5) with SMTP id PAA23673 for ; Tue, 15 Jul 1997 15:49:39 -0400 (EDT) Received: from mica.denver.sgi.com (mica.denver.sgi.com [169.238.67.6]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id MAA10558 for <@sgi.engr.sgi.com:ietf-ppp@merit.edu>; Tue, 15 Jul 1997 12:49:31 -0700 env-from (vjs@mica.denver.sgi.com) Received: (from vjs@localhost) by mica.denver.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA05781 for ietf-ppp@merit.edu; Tue, 15 Jul 1997 13:49:14 -0600 Date: Tue, 15 Jul 1997 13:49:14 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199707151949.NAA05781@mica.denver.sgi.com> To: ietf-ppp@merit.edu Subject: Re: CHAP Challenge Request Sender: owner-ietf-ppp@merit.edu > From: James Carlson > ... > I don't think that was the source of the problem; passing CHAP Challenges > through from the peer and demultiplexing the Response messages on the ID > number is the obvious solution for Challenges originating at the peer. > > I think the source of the query is for CHAP Challenges passing the other > direction. In other words, he's already got a link established. Now he > silently (without the PC's intervention) brings up a new link to the peer. > How does he generate a Challenge *TO* the peer? He needs some way to prod > the PC into generating a Challenge message for which it will accept a > valid response from the peer. (Let's all assume that he's got a decent > PC which actually *will* want to Challenge the peer.) That is a hard problem, but I bet not the one at issue. I bet the issue involves the PC/TA as authenticatee. > He has, I think, three options: > > - Simply wait for the next rechallenge by the PC. (Yecch.) > > - Use some new LCP or CHAP message to prod the PC. (Yecch.) > > - Forge an LCP Configure-Request to the PC to restart everything. > (Yecch ** 2) > > Unless I'm also missing something vital here, I don't think there are any > good answers for a fancy translating TA like this. Duplicating challenges from the PC is not a good plan in view of the forthcoming anti-CHAP-oracle efforts. I think the most likely to work and therefore least yecch solution for the PC challenging the (so called) server is forcing LCP. It is not pretty, but the others either won't work and are insecure (just waiting) or extending the protocol (won't happen). If you were to extend the protocol to deal with (reportedly mythical) PC's that authenticate "servers", I think other choices would be better: - use something to convey the secret from the PC to the T/A (TACAS, RADIUS, or even PAP) - move authentication into the LCP Configure- packets, where it belongs There is another solution. You could make the T/A a real router, one that talks PPP on both interfaces and has enough stable storage to do the right things. vjs - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 15 15:54:34 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id PAA23846; Tue, 15 Jul 1997 15:54:33 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 15 Jul 1997 15:52:50 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id PAA23771 for ietf-ppp-outgoing; Tue, 15 Jul 1997 15:52:48 -0400 (EDT) Received: from atlas.xylogics.com (atlas.xylogics.com [132.245.33.7]) by merit.edu (8.8.5/8.8.5) with ESMTP id PAA23766 for ; Tue, 15 Jul 1997 15:52:40 -0400 (EDT) Received: from vulcan.xylogics.com (vulcan.xylogics.com [132.245.33.8]) by atlas.xylogics.com (8.7.3/8.7.3) with SMTP id PAA26759; Tue, 15 Jul 1997 15:32:39 -0400 (EDT) Received: from localhost by vulcan.xylogics.com id AA12689 (4.1/UK-doug-951219); Tue, 15 Jul 97 15:32:38 EDT Message-Id: <12689.9707151932@vulcan.xylogics.com> To: vjs@mica.denver.sgi.com (Vernon Schryver) Cc: ietf-ppp@merit.edu Subject: Re: CHAP Challenge Request In-Reply-To: Your message of "Tue, 15 Jul 1997 13:18:58 MDT." <199707151918.NAA05727@mica.denver.sgi.com> Date: Tue, 15 Jul 1997 15:32:37 -0400 From: James Carlson Sender: owner-ietf-ppp@merit.edu In message <199707151918.NAA05727@mica.denver.sgi.com>, Vernon Schryver writes: > Instead of hoping to get the whole rest of the world to deploy new > firmware and software to support protocol extensions that other people > do not need (another of the mistakes in BACP/BAP), why not have your > T/A pass all CHAP challenges through to the PC, and remember their > source link in the MP bundle? I don't think that was the source of the problem; passing CHAP Challenges through from the peer and demultiplexing the Response messages on the ID number is the obvious solution for Challenges originating at the peer. I think the source of the query is for CHAP Challenges passing the other direction. In other words, he's already got a link established. Now he silently (without the PC's intervention) brings up a new link to the peer. How does he generate a Challenge *TO* the peer? He needs some way to prod the PC into generating a Challenge message for which it will accept a valid response from the peer. (Let's all assume that he's got a decent PC which actually *will* want to Challenge the peer.) He has, I think, three options: - Simply wait for the next rechallenge by the PC. (Yecch.) - Use some new LCP or CHAP message to prod the PC. (Yecch.) - Forge an LCP Configure-Request to the PC to restart everything. (Yecch ** 2) Unless I'm also missing something vital here, I don't think there are any good answers for a fancy translating TA like this. --- James Carlson , Prin Engr Tel: +1 508 916 4351 Bay Networks - Annex I/F Develop. / 8 Federal ST +1 800 225 3317 Mail Stop BL08-05 / Billerica MA 01821-3548 Fax: +1 508 916 4789 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 15 17:31:27 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id RAA25690; Tue, 15 Jul 1997 17:31:25 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 15 Jul 1997 17:29:14 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id RAA25635 for ietf-ppp-outgoing; Tue, 15 Jul 1997 17:29:13 -0400 (EDT) Received: from zoom.eicon.com (zoom.eicon.com [192.219.20.250]) by merit.edu (8.8.5/8.8.5) with SMTP id RAA25631 for ; Tue, 15 Jul 1997 17:29:05 -0400 (EDT) Received: from admin.eicon.com by zoom.eicon.com with SMTP id AA19677 (5.67a/IDA-1.5 for ); Tue, 15 Jul 1997 17:35:07 -0400 Received: by admin.eicon.com with Microsoft Mail id <33CC1624@admin.eicon.com>; Tue, 15 Jul 97 17:30:28 PDT From: Pierre-Luc Provencal To: ietf-ppp Subject: RE: CHAP Challenge Request Date: Tue, 15 Jul 97 17:30:00 PDT Message-Id: <33CC1624@admin.eicon.com> X-Mailer: Microsoft Mail V3.0 Sender: owner-ietf-ppp@merit.edu What you describe, James, is the right problem. The problem is not when we are being authenticated (trivial) but when the PC-T/A is the authenticator. So the only viable solution is to retransmit old CHAP challenges that were used during the initial authentication and were stored in the T/A memory with the corresponding CHAP responses and CHAP successes. This way the "whole rest of the world" is not affected in any manner. But is it secure enough, specially when we know that most implementations do not send subsequent CHAP challenges once the link is opened ??? Pierre-Luc Provencal Eicon Technology Corp. ---------- From: owner-ietf-ppp Sent: Tuesday, July 15, 1997 3:32 PM To: vjs Cc: ietf-ppp Subject: Re: CHAP Challenge Request In message <199707151918.NAA05727@mica.denver.sgi.com>, Vernon Schryver writes: > Instead of hoping to get the whole rest of the world to deploy new > firmware and software to support protocol extensions that other people > do not need (another of the mistakes in BACP/BAP), why not have your > T/A pass all CHAP challenges through to the PC, and remember their > source link in the MP bundle? I don't think that was the source of the problem; passing CHAP Challenges through from the peer and demultiplexing the Response messages on the ID number is the obvious solution for Challenges originating at the peer. I think the source of the query is for CHAP Challenges passing the other direction. In other words, he's already got a link established. Now he silently (without the PC's intervention) brings up a new link to the peer. How does he generate a Challenge *TO* the peer? He needs some way to prod the PC into generating a Challenge message for which it will accept a valid response from the peer. (Let's all assume that he's got a decent PC which actually *will* want to Challenge the peer.) He has, I think, three options: - Simply wait for the next rechallenge by the PC. (Yecch.) - Use some new LCP or CHAP message to prod the PC. (Yecch.) - Forge an LCP Configure-Request to the PC to restart everything. (Yecch ** 2) Unless I'm also missing something vital here, I don't think there are any good answers for a fancy translating TA like this. --- James Carlson , Prin Engr Tel: +1 508 916 4351 Bay Networks - Annex I/F Develop. / 8 Federal ST +1 800 225 3317 Mail Stop BL08-05 / Billerica MA 01821-3548 Fax: +1 508 916 4789 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 15 17:52:49 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id RAA26114; Tue, 15 Jul 1997 17:52:45 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 15 Jul 1997 17:51:05 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id RAA26055 for ietf-ppp-outgoing; Tue, 15 Jul 1997 17:51:03 -0400 (EDT) Received: from janus.3com.com (janus.3com.com [129.213.128.99]) by merit.edu (8.8.5/8.8.5) with ESMTP id RAA26033 for ; Tue, 15 Jul 1997 17:50:18 -0400 (EDT) From: Daniel_Brennan@3com.com Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by janus.3com.com (8.8.2/8.8.5) with ESMTP id OAA17694 for ; Tue, 15 Jul 1997 14:49:43 -0700 (PDT) Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104]) by new-york.3com.com (8.8.2/8.8.5) with SMTP id OAA13624 for ; Tue, 15 Jul 1997 14:48:14 -0700 (PDT) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v1.1 (385.6 5-6-1997)) id 082564D5.007CDF9B ; Tue, 15 Jul 1997 14:43:57 -0800 X-Lotus-FromDomain: 3COM To: ietf-ppp@merit.edu Message-ID: <852564D5.007C8BC8.00@hqoutbound.ops.3com.com> Date: Tue, 15 Jul 1997 18:42:45 -0400 Subject: Re: CHAP Challenge Request Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-ppp@merit.edu >> From: James Carlson >> ... >> I don't think that was the source of the problem; passing CHAP Challenges >> through from the peer and demultiplexing the Response messages on the ID >> number is the obvious solution for Challenges originating at the peer. >> >That is a hard problem, but I bet not the one at issue. I bet >the issue involves the PC/TA as authenticatee. I believe the scenario in question has the PC/TA as authenticator. Dan - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 15 17:52:46 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id RAA26110; Tue, 15 Jul 1997 17:52:43 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 15 Jul 1997 17:50:54 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id RAA26041 for ietf-ppp-outgoing; Tue, 15 Jul 1997 17:50:53 -0400 (EDT) Received: from janus.3com.com (janus.3com.com [129.213.128.99]) by merit.edu (8.8.5/8.8.5) with ESMTP id RAA26034 for ; Tue, 15 Jul 1997 17:50:23 -0400 (EDT) From: Daniel_Brennan@3com.com Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by janus.3com.com (8.8.2/8.8.5) with ESMTP id OAA17697 for ; Tue, 15 Jul 1997 14:49:43 -0700 (PDT) Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104]) by new-york.3com.com (8.8.2/8.8.5) with SMTP id OAA13627 for ; Tue, 15 Jul 1997 14:48:15 -0700 (PDT) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v1.1 (385.6 5-6-1997)) id 082564D5.007CDF74 ; Tue, 15 Jul 1997 14:43:56 -0800 X-Lotus-FromDomain: 3COM To: ietf-ppp@merit.edu Message-ID: <852564D5.007C2300.00@hqoutbound.ops.3com.com> Date: Tue, 15 Jul 1997 18:38:08 -0400 Subject: Re: CHAP Challenge Request Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-ppp@merit.edu >T/A pass all CHAP challenges through to the PC, and remember their >source link in the MP bundle? The CHAP protocol has always required >the PC to be able to respond to CHAP challenges at any time, and as >often as the peer cares to send them. In your T/A situation, the PC One reason is that there is a VERY popular PC OS that can't handle multiple CHAP challenges. >Vernon Schryver, vjs@sgi.com Dan - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 15 20:49:17 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id UAA28189; Tue, 15 Jul 1997 20:49:04 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 15 Jul 1997 20:47:17 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id UAA28143 for ietf-ppp-outgoing; Tue, 15 Jul 1997 20:47:16 -0400 (EDT) Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.8.5/8.8.5) with SMTP id UAA28139 for ; Tue, 15 Jul 1997 20:47:12 -0400 (EDT) Received: from mica.denver.sgi.com (mica.denver.sgi.com [169.238.67.6]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id RAA18605 for <@sgi.engr.sgi.com:ietf-ppp@merit.edu>; Tue, 15 Jul 1997 17:47:09 -0700 env-from (vjs@mica.denver.sgi.com) Received: (from vjs@localhost) by mica.denver.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA06573 for ietf-ppp@merit.edu; Tue, 15 Jul 1997 18:47:03 -0600 Date: Tue, 15 Jul 1997 18:47:03 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199707160047.SAA06573@mica.denver.sgi.com> To: ietf-ppp@merit.edu Subject: RE: CHAP Challenge Request Sender: owner-ietf-ppp@merit.edu > From: Pierre-Luc Provencal > What you describe, James, is the right problem. The problem is not when > we are being authenticated (trivial) but when the PC-T/A is the > authenticator. So the only viable solution is to retransmit old CHAP > challenges that were used during the initial authentication and were > stored in the T/A memory with the corresponding CHAP responses and CHAP > successes. This way the "whole rest of the world" is not affected in any > manner. But is it secure enough, specially when we know that most > implementations do not send subsequent CHAP challenges once the link is > opened ??? > ... Can you not extend your AT command sequence to include a way for the PC to tell the T/A the CHAP secret along with the telephone number? Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 15 21:25:32 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id VAA28868; Tue, 15 Jul 1997 21:25:30 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 15 Jul 1997 21:24:01 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id VAA28825 for ietf-ppp-outgoing; Tue, 15 Jul 1997 21:24:01 -0400 (EDT) Received: from coppermountain.com (cmcnt.coppermountain.com [206.71.190.2]) by merit.edu (8.8.5/8.8.5) with ESMTP id VAA28820 for ; Tue, 15 Jul 1997 21:23:56 -0400 (EDT) Received: by coppermountain.com from localhost (router,SLMail V2.5); Tue, 15 Jul 1997 18:24:18 -0800 Received: by coppermountain.com from eric (206.71.190.13::mail daemon; unverified,SLMail V2.5); Tue, 15 Jul 1997 18:24:17 -0800 Message-Id: <2.2.32.19970716012449.0033a9b0@coppermountain.com> X-Sender: "Eric Michelsen" X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 15 Jul 1997 18:24:49 -0700 To: ietf-ppp@merit.edu From: "Eric L. Michelsen" Subject: Re: Re[6]: DESE padding implementation poll; proposed language Sender: owner-ietf-ppp@merit.edu At 12:54 AM 7/14/97 -0700, Keith Sklower wrote: ... Although there is still an interoperability >problem between systems implementing "1", there won't be a problem between >systems implementing "new" and when somebody thinks that they've implemented >"1" ignoring the fact that RFC1969 has been obsoleted, when they go to test >they will discover that none of the major players will talk to them. I can't imagine that we're going to change a number because we're concerned that an implementer doesn't bother to check the RFC index for the current standard? I think we should not incur additional burden to accomodate such irresponsible behavior. Such an implementor may well have an incompatible box, and it will be his problem to fix it. -- Eric L. Michelsen, Copper Mountain Networks, Inc. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jul 16 03:28:51 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id DAA02635; Wed, 16 Jul 1997 03:28:41 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 16 Jul 1997 03:26:48 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id DAA02573 for ietf-ppp-outgoing; Wed, 16 Jul 1997 03:26:47 -0400 (EDT) Received: from ns.trancell.stph.net (prasan@ns.trancell.stph.net [196.12.55.2]) by merit.edu (8.8.5/8.8.5) with ESMTP id DAA02566 for ; Wed, 16 Jul 1997 03:26:28 -0400 (EDT) Received: from trancell.stph.net (prasan@localhost) by ns.trancell.stph.net (8.7.3/8.7.3) id NAA04042 for ietf-ppp@merit.edu; Wed, 16 Jul 1997 13:19:51 +0530 (IST) From: "N.G.Prasanna Kumar" Message-Id: <199707160749.NAA04042@trancell.stph.net> Subject: IP Subnet negotiations in IPCP ?? To: ietf-ppp@merit.edu Date: Wed, 16 Jul 1997 13:19:49 +0530 (IST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Hi , Are there any extended options from which we can know the subnetmask of the peer in IPCP negotiations ? -Thanx Prasanna - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jul 16 04:22:06 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id EAA03003; Wed, 16 Jul 1997 04:22:05 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 16 Jul 1997 04:20:35 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id EAA02976 for ietf-ppp-outgoing; Wed, 16 Jul 1997 04:20:34 -0400 (EDT) Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.8.5/8.8.5) with SMTP id EAA02972 for ; Wed, 16 Jul 1997 04:20:30 -0400 (EDT) Received: from mica.denver.sgi.com (mica.denver.sgi.com [169.238.67.6]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id BAA09152 for <@sgi.engr.sgi.com:ietf-ppp@merit.edu>; Wed, 16 Jul 1997 01:20:29 -0700 env-from (vjs@mica.denver.sgi.com) Received: (from vjs@localhost) by mica.denver.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id CAA07132 for ietf-ppp@merit.edu; Wed, 16 Jul 1997 02:20:25 -0600 Date: Wed, 16 Jul 1997 02:20:25 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199707160820.CAA07132@mica.denver.sgi.com> To: ietf-ppp@merit.edu Subject: IP Subnet negotiations in IPCP ?? Sender: owner-ietf-ppp@merit.edu > From: "N.G.Prasanna Kumar" > Are there any extended options from which we can know > the subnetmask of the peer in IPCP negotiations ? Given the fact that IPCP-PPP is a point-to-point protocol, what would be the meaning of knowing what netmask the peer is using for with IP address on some LAN or other interface in use by the peer? The only way I can see for the IP netmask to be meaningful is if 1. IPCP involved the assignment of networks, not just IP addresses. But IPCP does no such thing. It just negotiates or communicates host addresses for which the netmasks are 255.255.255.255. 2. the local system knows that the IP address negotiated for the peer is the same as the IP address of the peer on one of the peer's LAN interfaces, or on the same IP network, and the local system wants to advertise an IP route to that distant IP network. Despite the fact that the rewrite of `routed` I'm flogging does just that kind of thing, I do not think it is a particularly good or useful idea. In general, you can infer absolutely nothing about the IP networks beyond the peer from the IP host address it is using. It is not wise to assume that the peer is running "unnumbered." Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jul 16 04:25:16 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id EAA03040; Wed, 16 Jul 1997 04:25:15 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 16 Jul 1997 04:23:47 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id EAA03017 for ietf-ppp-outgoing; Wed, 16 Jul 1997 04:23:47 -0400 (EDT) Received: from lynx.europe.shiva.com (lynx.europe.shiva.com [134.191.64.5]) by merit.edu (8.8.5/8.8.5) with ESMTP id EAA03012 for ; Wed, 16 Jul 1997 04:23:40 -0400 (EDT) Received: from eurohub.europe.shiva.com (eurohub.europe.shiva.com [134.191.64.200]) by lynx.europe.shiva.com (8.8.5/8.8.5) with ESMTP id JAA13194; Wed, 16 Jul 1997 09:22:54 +0100 (BST) Received: from Lotus Notes (PU Serial #1281) by eurohub.europe.shiva.com (PostalUnion/SMTP(tm) v2.1.7 for Windows NT(tm)) id AA-1997Jul16.071822.1281.534359; Wed, 16 Jul 1997 09:19:51 +0100 From: gerry@europe.shiva.com (CN=Gerry Meyer/OU=Eng/OU=EDI/O=Shiva) To: emichelsen@coppermountain.com (Eric L. Michelsen) Cc: ietf-ppp@merit.edu (ietf-ppp) Message-ID: <1997Jul16.071822.1281.534359@eurohub.europe.shiva.com> X-Conversion-ID: X-Mailer: Lotus Notes via PostalUnion/SMTP for Windows NT Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Organization: Shiva Europe Ltd Date: Wed, 16 Jul 1997 09:19:51 +0100 Subject: Re: Re[6]: DESE padding implementation poll; proposed language Sender: owner-ietf-ppp@merit.edu A probable sequence of events is that an implementer downloads the current latest version of an RFC from their favourite site - implements it - and is then a) unaware that a new draft has come along - the downloaded version is never obsoleted! b) implemented it - it works for them - and has moved on to something else. c) notices a new version has come out, but given the two RFCs can not tell what the material differences are. In the case of DESE it MAY be that we have caught it sufficiently soon in the development cycle and all implementers are on this list and are aware that we intend to make a non-compatible change. But who can tell? I don't know. Its a close call. Gerry Eric L. Michelsen on 16/07/97 02:36:30 To: ietf-ppp @ EUROGATE cc: Subject: Re: Re[6]: DESE padding implementation poll; proposed language At 12:54 AM 7/14/97 -0700, Keith Sklower wrote: ... Although there is still an interoperability >problem between systems implementing "1", there won't be a problem between >systems implementing "new" and when somebody thinks that they've implemented >"1" ignoring the fact that RFC1969 has been obsoleted, when they go to test >they will discover that none of the major players will talk to them. I can't imagine that we're going to change a number because we're concerned that an implementer doesn't bother to check the RFC index for the current standard? I think we should not incur additional burden to accomodate such irresponsible behavior. Such an implementor may well have an incompatible box, and it will be his problem to fix it. -- Eric L. Michelsen, Copper Mountain Networks, Inc. ------ Message Header Follows ------ Received: from lynx.europe.shiva.com by eurohub.europe.shiva.com (PostalUnion/SMTP(tm) v2.1.7 for Windows NT(tm)) id AA-1997Jul16.023435.1281.295638; Wed, 16 Jul 1997 02:34:35 +0100 Received: from merit.edu (merit.edu [198.108.1.42]) by lynx.europe.shiva.com (8.8.5/8.8.5) with ESMTP id CAA09937 for ; Wed, 16 Jul 1997 02:37:37 +0100 (BST) Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id VAA28831; Tue, 15 Jul 1997 21:24:02 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 15 Jul 1997 21:24:01 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id VAA28825 for ietf-ppp-outgoing; Tue, 15 Jul 1997 21:24:01 -0400 (EDT) Received: from coppermountain.com (cmcnt.coppermountain.com [206.71.190.2]) by merit.edu (8.8.5/8.8.5) with ESMTP id VAA28820 for ; Tue, 15 Jul 1997 21:23:56 -0400 (EDT) Received: by coppermountain.com from localhost (router,SLMail V2.5); Tue, 15 Jul 1997 18:24:18 -0800 Received: by coppermountain.com from eric (206.71.190.13::mail daemon; unverified,SLMail V2.5); Tue, 15 Jul 1997 18:24:17 -0800 Message-Id: <2.2.32.19970716012449.0033a9b0@coppermountain.com> X-Sender: "Eric Michelsen" X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 15 Jul 1997 18:24:49 -0700 To: ietf-ppp@merit.edu From: "Eric L. Michelsen" Subject: Re: Re[6]: DESE padding implementation poll; proposed language Sender: owner-ietf-ppp@merit.edu - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jul 16 04:59:28 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id EAA03304; Wed, 16 Jul 1997 04:59:27 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 16 Jul 1997 04:57:56 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id EAA03269 for ietf-ppp-outgoing; Wed, 16 Jul 1997 04:57:56 -0400 (EDT) Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.8.5/8.8.5) with SMTP id EAA03265 for ; Wed, 16 Jul 1997 04:57:52 -0400 (EDT) Received: from mica.denver.sgi.com (mica.denver.sgi.com [169.238.67.6]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id BAA14453 for <@sgi.engr.sgi.com:ietf-ppp@merit.edu>; Wed, 16 Jul 1997 01:57:50 -0700 env-from (vjs@mica.denver.sgi.com) Received: (from vjs@localhost) by mica.denver.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id CAA07178 for ietf-ppp@merit.edu; Wed, 16 Jul 1997 02:57:48 -0600 Date: Wed, 16 Jul 1997 02:57:48 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199707160857.CAA07178@mica.denver.sgi.com> To: ietf-ppp@merit.edu Subject: Re: IP Subnet negotiations in IPCP ?? Sender: owner-ietf-ppp@merit.edu I forgot my point among my objections ... If you want to know the netmask used by the peer, why not use a protocol designed for the purpose of communicating IP network numbers and netmasks, namely a routing protocol? In almost all cases, you want to know the peer's netmask only to answer questions that are really routing questions, so why not run RIPv2, OSPF, HELO, or whatever routing protocol moves your bits? Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jul 16 04:52:09 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id EAA03232; Wed, 16 Jul 1997 04:52:07 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 16 Jul 1997 04:50:04 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id EAA03205 for ietf-ppp-outgoing; Wed, 16 Jul 1997 04:50:03 -0400 (EDT) Received: from directors.rdl.co.uk (directors.rdl.co.uk [193.119.77.2]) by merit.edu (8.8.5/8.8.5) with ESMTP id EAA03201 for ; Wed, 16 Jul 1997 04:49:58 -0400 (EDT) Received: from imaccgw.rdl.co.uk (imaccgw.rdl.co.uk [193.240.106.205]) by directors.rdl.co.uk (8.7.3/8.7.3) with SMTP id JAA07410 for ; Wed, 16 Jul 1997 09:49:56 +0100 (BST) Received: from ccMail by imaccgw.rdl.co.uk (IMA Internet Exchange 1.04b) id 3cc8ad10; Wed, 16 Jul 97 09:48:17 +0100 Mime-Version: 1.0 Date: Wed, 16 Jul 1997 09:43:33 +0100 Message-ID: <3cc8ad10@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re: CHAP Challenge Request Cc: ietf-ppp@merit.edu Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: owner-ietf-ppp@merit.edu James Carlson writes: >He has, I think, three options: Four, if you include the option of duplicating the original challenge. > > - Simply wait for the next rechallenge by the PC. (Yecch.) Slightly better would be duplicate the original challenge and then wait for the next rechallenge. Not much better, I admit. > > - Use some new LCP or CHAP message to prod the PC. (Yecch.) The trouble with this is that the TA is being sold to work with existing systems. Even if we all agreed that this is a good idea (unlikely in itself), it would probably be at least 2 years before it was released in a new version of the PC OS, by which time something would probably have happened to make this TA solution obsolete (e.g. Microsoft may release software which supports BACP/BAP). > > - Forge an LCP Configure-Request to the PC to restart > everything. (Yecch ** 2) Renegotiating LCP to the PC will cause it to renegotiate IPCP, which in the case of the PC OS we're talking about will clear down all active TCP sessions, making Bandwidth on Demand a bit pointless. > >Unless I'm also missing something vital here, I don't think there are any >good answers for a fancy translating TA like this. I don't either, and I've thought about it a lot (we've just released a "fancy translating TA"). But maybe we ought to examine the problems with duplicating the original challenge. It's obviously a lot weaker than having a different challenge each time, but it's still a lot stronger than PAP. What sort of attacks would it be vulnerable to ? I would have thought that an attacker would have to be in a position to snoop the original challenge in order to repeat the response, in which case he's quite likely to be able to mount a man-in-the-middle attack which we all know that CHAP isn't proof against anyway. Assuming, however, that he can snoop but can't get in the middle, what sort of damage can he do ? He has to be able to connect in while the original ISDN call is still up, and would then be able to deny service. If were able to disconnect the original ISDN call he would then have complete access, but only for as long as he was connected (i.e. the original user would have to reconnect for the attacker to be able to reconnect). Maybe this level of security risk will be acceptable to sort of users who would buy the TA solution. I think, however, that the real solution is not to use a TA at all. Install an ISDN card in the PC, and make do without BAP/BACP for Bandwidth on Demand (because, as Vernon keeps telling us, BAP isn't necessary for BOD). Or use a router attached to the PC via a LAN (if you have a bit more money to spend). --- Vernon Schryver writes: ] Can you not extend your AT command sequence to include a way for the PC ] to tell the T/A the CHAP secret along with the telephone number? This is ok for the authenticatee, but for the authenticator it may not be just a single secret. It'll be all the secrets for all the potential peers who may connect in. Besides, I don't know of any way to make the PC divulge its secrets. --- Jonathan Goodchild Racal Datacom - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jul 16 05:25:13 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id FAA03681; Wed, 16 Jul 1997 05:24:13 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 16 Jul 1997 05:18:57 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id FAA03614 for ietf-ppp-outgoing; Wed, 16 Jul 1997 05:18:56 -0400 (EDT) Received: from directors.rdl.co.uk (directors.rdl.co.uk [193.119.77.2]) by merit.edu (8.8.5/8.8.5) with ESMTP id FAA03610 for ; Wed, 16 Jul 1997 05:18:50 -0400 (EDT) Received: from imaccgw.rdl.co.uk (imaccgw.rdl.co.uk [193.240.106.205]) by directors.rdl.co.uk (8.7.3/8.7.3) with SMTP id KAA08020 for ; Wed, 16 Jul 1997 10:18:43 +0100 (BST) Received: from ccMail by imaccgw.rdl.co.uk (IMA Internet Exchange 1.04b) id 3cc91900; Wed, 16 Jul 97 10:17:04 +0100 Mime-Version: 1.0 Date: Wed, 16 Jul 1997 10:12:38 +0100 Message-ID: <3cc91900@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re-tries of Failed Authentication To: ietf-ppp@merit.edu Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: owner-ietf-ppp@merit.edu I've recently been asked to look into providing some sort of support for authentication re-tries. RFC 1994 states (on page 10): There is no provision for re-tries of failed authentication. However, the LCP state machine can renegotiate the authentication protocol at any time, thus allowing a new attempt. What I'd like to know is does anyone else support this ? If so, would you expect LCP to be re-negotiated instead of sending CHAP Failure, or after it ? And is allowing re-tries a sensible thing to do anyway ? Thanks, Jonathan Goodchild Racal-Datacom - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jul 16 06:17:44 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id GAA04025; Wed, 16 Jul 1997 06:17:43 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 16 Jul 1997 06:16:11 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id GAA03994 for ietf-ppp-outgoing; Wed, 16 Jul 1997 06:16:10 -0400 (EDT) Received: from blizzard.wise.edt.ericsson.se (blizzard-ext.wise.edt.ericsson.se [194.237.142.2]) by merit.edu (8.8.5/8.8.5) with ESMTP id GAA03990 for ; Wed, 16 Jul 1997 06:16:06 -0400 (EDT) Received: from nisms (nisms.tei.ericsson.se [141.137.75.1]) by blizzard.wise.edt.ericsson.se (8.7.5/8.7.3/glacier-0.9) with SMTP id MAA27499 for ; Wed, 16 Jul 1997 12:15:59 +0200 (MET DST) Received: from fagiolo.tei.ericsson.se ([141.137.74.115]) by nisms (4.1/LME-2.2.1) id AA13904; Wed, 16 Jul 97 12:15:58 +0200 Message-Id: <33CC9EEA.1E70E85C@RD.tei.ericsson.se> Date: Wed, 16 Jul 1997 12:14:04 +0200 From: cantoro Organization: eicsson X-Mailer: Mozilla 4.01 [en] (Win95; I) Mime-Version: 1.0 To: "ietf-ppp@merit.edu" Subject: PPP over Frame Relay X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Hi, we are looking for an Access Router that supports PPP connections over FR links according with RFC 1973 (PPP in Frame Relay). Any information about such kind of products will be appreciate. Thanks in advance. ------------------------------------------------------------ Salvatore Cantoro System Engineer Ericsson Telecomunicazioni SpA Tel. : +39-6-72584298 R&D Division Fax : +39-6-20410037 Via Anagnina 203 E-Mail : S.Cantoro@RD.tei.ericsson.se 00040 Rome (ITALY) - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jul 16 07:50:50 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id HAA04714; Wed, 16 Jul 1997 07:50:48 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 16 Jul 1997 07:48:57 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id HAA04689 for ietf-ppp-outgoing; Wed, 16 Jul 1997 07:48:57 -0400 (EDT) Received: from fsnt.future.futsoft.com ([38.242.192.5]) by merit.edu (8.8.5/8.8.5) with ESMTP id HAA04684 for ; Wed, 16 Jul 1997 07:48:50 -0400 (EDT) Received: from kailash.future.futsoft.com (38.242.192.4) by fsnt.future.futsoft.com (Integralis SMTPRS 1.51) with ESMTP id ; Wed, 16 Jul 1997 17:22:58 +0530 Received: from msgate.future.futsoft.com (msgate.future.futsoft.com [10.0.8.4]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id QAA10242 for ; Wed, 16 Jul 1997 16:59:42 +0530 Received: by msgate.future.futsoft.com with Microsoft Mail id <33CD6371@msgate.future.futsoft.com>; Wed, 16 Jul 97 17:12:33 PDT From: rajeshs To: "'ietf-ppp'" Subject: PPP over ATM or ADSL Date: Wed, 16 Jul 97 17:11:00 PDT Message-Id: <33CD6371@msgate.future.futsoft.com> X-Mailer: Microsoft Mail V3.0 Sender: owner-ietf-ppp@merit.edu Hello, Please excuse me for using the mailing list for a personal query. We're looking for any implementations of PPP over ATM and PPP over ADSL. Any info on standards regarding these or vendors providing these would be appreciated. Thanks in advance Rajesh Kumar (rajeshs@future.futsoft.com) - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jul 16 08:22:20 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id IAA05033; Wed, 16 Jul 1997 08:22:19 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 16 Jul 1997 08:20:42 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id IAA04998 for ietf-ppp-outgoing; Wed, 16 Jul 1997 08:20:41 -0400 (EDT) Received: from atlas.xylogics.com (atlas.xylogics.com [132.245.33.7]) by merit.edu (8.8.5/8.8.5) with ESMTP id IAA04989 for ; Wed, 16 Jul 1997 08:20:35 -0400 (EDT) Received: from vulcan.xylogics.com (vulcan.xylogics.com [132.245.33.8]) by atlas.xylogics.com (8.7.3/8.7.3) with SMTP id IAA19097; Wed, 16 Jul 1997 08:19:22 -0400 (EDT) Received: from localhost by vulcan.xylogics.com id AA00176 (4.1/UK-doug-951219); Wed, 16 Jul 97 08:19:21 EDT Message-Id: <176.9707161219@vulcan.xylogics.com> To: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Cc: ietf-ppp@merit.edu Subject: Re: CHAP Challenge Request In-Reply-To: Your message of "Wed, 16 Jul 1997 09:43:33 BST." <3cc8ad10@rdl.co.uk> Date: Wed, 16 Jul 1997 08:19:20 -0400 From: James Carlson Sender: owner-ietf-ppp@merit.edu In message <3cc8ad10@rdl.co.uk>, Jonathan Goodchild writes: > James Carlson writes: > > >He has, I think, three options: > > Four, if you include the option of duplicating the original challenge. I should have more explicitly excluded that option. I don't consider it a solution, since some good implementations will have replay protection built in and will either drop the link or deliberately return an incorrect response. > > - Forge an LCP Configure-Request to the PC to restart > > everything. (Yecch ** 2) > > Renegotiating LCP to the PC will cause it to renegotiate IPCP, > which in the case of the PC OS we're talking about will clear down > all active TCP sessions, making Bandwidth on Demand a bit > pointless. Excuse me? What kind of an implementation tears down active TCP sessions just based on a IP link bounce? Oh, yeah, never mind ... (The rest of the world long ago realized that "destination unreachable" in a TCP connection which is in Established state is not an immediately fatal error. Links and routes do bounce. Sometimes I forget that each generation must relearn all of the lessons of the one that went before.) (Yes, I know it's an "ease of use" thing. "Ease of use" is highly overrated.) > I don't either, and I've thought about it a lot (we've just released a > "fancy translating TA"). But maybe we ought to examine the problems with > duplicating the original challenge. It's obviously a lot weaker than > having a different challenge each time, but it's still a lot stronger than > PAP. That's an awfully strong statement. I don't think I'd be willing to make that claim. > Assuming, however, that he can snoop but can't get in the middle, what sort > of damage can he do ? I am not a security expert. But consider this: It is the case that all Challenges must have new ID numbers (which is part of the hash) and new "Value" fields. These are both 'MUST' in RFC 1994. I'm not willing to take that demand lightly, even when the Challenges are presented over nominally separate links. > I think, however, that the real solution is not to use a TA at all. > Install an ISDN card in the PC, and make do without BAP/BACP for Bandwidth > on Demand (because, as Vernon keeps telling us, BAP isn't necessary for > BOD). Or use a router attached to the PC via a LAN (if you have a bit more > money to spend). I think BAP/BACP is a red herring. The real issue here is not what BOD techniques are used, but rather who has the CHAP secret and who does not. The same problem crops up if you use MP without BAP/BACP but with an external TA doing the MP and doing BOD based on traffic density estimates. I agree that either teaching the PC MP or moving all of PPP out to the "TA" (to make it a router) fixes the problem. I'm not so sure, though, that translating TAs don't fill an important enough niche that they may need to exist for a while. If they will exist for a while, then we should at least follow up on the implications. In particular, without changes to PPP and without having the TA know the CHAP secret, then any system which uses an external translating TA and uses CHAP for security and wants to validate its peer (as any good implementation should) will be able to do so only on the first link established and not necessarily on subsequent links. Whether or not that's an important enough hole to warrant a new message is debatable. --- James Carlson , Prin Engr Tel: +1 508 916 4351 Bay Networks - Annex I/F Develop. / 8 Federal ST +1 800 225 3317 Mail Stop BL08-05 / Billerica MA 01821-3548 Fax: +1 508 916 4789 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jul 16 10:15:46 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id KAA06879; Wed, 16 Jul 1997 10:15:36 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 16 Jul 1997 10:13:25 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id KAA06825 for ietf-ppp-outgoing; Wed, 16 Jul 1997 10:13:25 -0400 (EDT) Received: from ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.5/8.8.5) with SMTP id KAA06821 for ; Wed, 16 Jul 1997 10:13:19 -0400 (EDT) Received: from ietf.ietf.org by ietf.org id aa06446; 16 Jul 97 9:39 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-des-encrypt-v2-00.txt Date: Wed, 16 Jul 1997 09:39:29 -0400 Message-ID: <9707160939.aa06446@ietf.org> Sender: owner-ietf-ppp@merit.edu --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : The PPP DES Encryption Protocol, Version 2 (DESE-bis) Author(s) : K. Sklower, G. Meyer Filename : draft-ietf-pppext-des-encrypt-v2-00.txt Pages : 11 Date : 07/15/1997 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. The PPP Encryption Control Protocol (ECP) [2] provides a method to negotiate and utilize encryption protocols over PPP encapsulated links. This document provides specific details for the use of the DES standard [5, 6] for encrypting PPP encapsulated packets. 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-des-encrypt-v2-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-des-encrypt-v2-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-des-encrypt-v2-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970715103050.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-des-encrypt-v2-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-des-encrypt-v2-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970715103050.I-D@ietf.org> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jul 16 10:26:17 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id KAA07029; Wed, 16 Jul 1997 10:26:16 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 16 Jul 1997 10:24:41 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id KAA06996 for ietf-ppp-outgoing; Wed, 16 Jul 1997 10:24:40 -0400 (EDT) Received: from POSTAL.CSELT.STET.IT (postal.cselt.it [163.162.4.5]) by merit.edu (8.8.5/8.8.5) with ESMTP id KAA06966 for ; Wed, 16 Jul 1997 10:22:50 -0400 (EDT) Received: from [163.162.15.36] (fantolino.cselt.stet.it) by POSTAL.CSELT.STET.IT (PMDF V4.2-15 #4385) id <01ILB76TE1F4000TQS@POSTAL.CSELT.STET.IT>; Wed, 16 Jul 1997 16:21:49 MET Date: Wed, 16 Jul 1997 16:23:07 +0100 From: luca.fantolino@CSELT.IT (Luca Fantolino) Subject: PPP over Ethernet and PPP Bridge To: ietf-ppp@merit.edu Message-id: X-Envelope-to: ietf-ppp@merit.edu MIME-version: 1.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: 7BIT X-Sender: FANTOLIN_EUD@POSTAL.CSELT.IT Sender: owner-ietf-ppp@merit.edu Thank you to everyone has replied my first mail. I elaborated further my thoughts and the scenario I have in mind now is depicted below: PC Server/NAS ----- +-----+ | | PPP Session | | | | <=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=->-|- - -|- -> ----- | | +---------+ PPP over Eth +------------+ PPP over ATM | | +---------+ <------------> | PPP Bridge | <------------> | | # +------------+ +-----+ # # \ / =============================== \___________________/ LAN (e.g. Ethernet) WAN (e.g. ATM) I understand that solutions for business users are now available. I guess they are proprietary solutions, since I was not able to locate any standrard or public specification on the matter. Those solutions require a complex gateway between the LAN and the WAN (e.g. Windows NT server) and provides flexibility, security... The need to consider a simpler solution stems from the low cost of Ethernet as a local wiring technology, applicable for residential or small business users (also user with one PC). Those users in a near future may be served by local telephone companies (or equivalent) with high speed layer 2 technology, such as ATM PON or xDSL, which can be used to provide high performance access to Internet. The goal is to provide functionally the same service, from the point of view of the PC, than the one perceived using a traditional telephone modem. The PC (not the PPP Bridge box) performs all the functions required by a PPP client (including LCP negotiation, authentication...) as if it will be connected by a telephone modem. A major difference may be that the layer 2 connection to the Server/NAS can be a permanent connection, such as an ATM UBR VCC: this will simplify the "PPP Bridge" box, because no signalling protocol is required. Two new things appear here: - PPP over Ethernet (PPPoE); - PPP bridge (PPP-B). To better clarify my thoughts, I provide below a first attempt description of the protocol and the PPP-B. PPP OVER ETHERNET (PPPoE) This protocol should be the simplest possible: it shall be possible to effectively implement PPPoE in a box much simpler (and cheaper) than a PC. In the following I name "client" the computer requiring PPP service, and "Eth-end-point" the box attached to the Ethernet which either provides PPP service or forwards the PPP connection. PPP-B is an example of Eth-end-point. PPP over Ethernet requirements: (1) PPPoE shall include a start-up procedure by which the terminal discover the MAC address of the Eth-end-point and viceversa; in addition this procedures may be used in the PPP-B to trigger the activation of a layer 2 connection (e.g. set-up of a ISDN channel). This procedure should use Ethernet broadcasting or multicasting (using a well-known Ethernet Multicast address). (2) PPP packets (RFC 1661) shall be transported over Ethernet transparently. A code number to be used in the Protocol field of the Ethernet packet header should uniquely assigned for that purpose. One PPP packet shall be transported by one Ethernet packet (3) A Flow Control mechanism should be implemented by PPPoE. The need for that function stems from the mismatch between the high speed available in the local environment (10 or 100 Mbit/s) and the low or medium speed in the WAN (as low as 64 kbit/s, for ISDN access). This mechanism may be as simple as XON/XOFF. (4) PPPoE shall include a reliable procedure to close a session. This will include a polling and time-out mechanism: if the Eth-end-point does not receive traffic from a client for longer than T seconds, it send a polling packet; if no answer to the polling packet is received the server may assume that the client is no longer active. This procedure may be used by a PPP-B to trigger the deactivation of a layer 2 connection. (5) PPPoE shall not interfere with other protocols run over the same Ethernet. The use of a unique code to be placed in the Protocol field should guarantee that. (6) Many PPPoE session between the PPP-B and different clients should be possible on one Ethernet. Transmission of normal packets (following start-up) should be singlecast, using the unique MAC address assigned to the client and to the Eth-end-point MAC interface. To support Multiple PPPoE session between the same pair of client and server is not a requirement. PPP BRIDGE (PPP-B) This box is much more simple that a NAS: - it is not required to perform any authentication/authorisation mechanism; - it is not required to assign addresses to the PPP client; - it is not required to negotiate options for PPP; - it is not required to multiplex many PPP session on one layer 2 connections (e.g. using L2TP). The PPP-B performs as a transparent bridge for PPP: a PPP session crosses the PPP-B, changing from an Ethernet to a different layer 2 (e.g. ATM). High level function (including PPP LCP and NCP) such as authentication/authorisation, are performed by the PC and its peer without involving the PPP-B. For ISDN WAN one PPP session on Ethernet correspond to one ISDN channel and viceversa. For ATM WAN one PPP session on Ethernet corresponds to one ATM VCC and viceversa. So a protocol such as L2TP is not needed. If in the WAN segment switched service is used (e.g. ISDN) the number which dial is either pre-assign or optionally may be conveyed as an option from the client during the start-up procedure. From the point of view of a Server/NAS there is no difference between a user directly attached (e.g. a PC with an ATM card linked to the Server/NAS by a VCC using PPP over ATM) and a user behind a PPP-B using the same layer 2 protocol. Any and all comments are welcome. Luca _______________________________________________________________________ Luca Fantolino CSELT (a STET Company) Tel: +39 11 228 7543 via G. Reiss Romoli, 274 Fax: +39 11 228 5069 10148 Torino - ITALY E-Mail: Luca.Fantolino@Cselt.It _______________________________________________________________________ - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jul 16 11:54:55 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id LAA08836; Wed, 16 Jul 1997 11:54:51 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 16 Jul 1997 11:52:51 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id LAA08767 for ietf-ppp-outgoing; Wed, 16 Jul 1997 11:52:50 -0400 (EDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm002-03.dialip.mich.net [141.211.7.139]) by merit.edu (8.8.5/8.8.5) with SMTP id LAA08760 for ; Wed, 16 Jul 1997 11:52:45 -0400 (EDT) Date: Wed, 16 Jul 97 14:56:53 GMT From: "William Allen Simpson" Message-ID: <6276.wsimpson@greendragon.com> To: ietf-ppp Subject: Re: CHAP Challenge Request Sender: owner-ietf-ppp@merit.edu I have not had time to Grok the entire sequence of messages, but I'll take exception to this one: > From: Pierre-Luc Provencal > What you describe, James, is the right problem. The problem is not when > we are being authenticated (trivial) but when the PC-T/A is the > authenticator. So the only viable solution is to retransmit old CHAP > challenges that were used during the initial authentication and were > stored in the T/A memory with the corresponding CHAP responses and CHAP > successes. This way the "whole rest of the world" is not affected in any > manner. But is it secure enough, specially when we know that most > implementations do not send subsequent CHAP challenges once the link is > opened ??? > It is absolutely and unequivocally improper and insecure to retransmit old challenges. That defeats the fundamental design of CHAP. Every CHAP implementation I have ever done, on several different vendors' products, has sent repeated timed CHAP challenges. Is there some implementation constituting "most" that does not? Please name the culprit. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jul 16 12:48:30 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id MAA09742; Wed, 16 Jul 1997 12:48:28 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 16 Jul 1997 12:46:51 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id MAA09686 for ietf-ppp-outgoing; Wed, 16 Jul 1997 12:46:50 -0400 (EDT) Received: from databus.databus.com (databus.databus.com [198.186.154.34]) by merit.edu (8.8.5/8.8.5) with SMTP id MAA09682 for ; Wed, 16 Jul 1997 12:46:37 -0400 (EDT) From: Barney Wolff To: ietf-ppp@merit.edu Date: Wed, 16 Jul 1997 12:39 EDT Subject: Re: Re-tries of Failed Authentication Content-Type: text/plain Message-ID: <33ccfadf0.7165@databus.databus.com> Sender: owner-ietf-ppp@merit.edu > Date: Wed, 16 Jul 1997 10:12:38 +0100 > From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) > > And is allowing re-tries a sensible thing to do anyway ? No. I've never heard of a PPP peer where the auth secret was hand-entered during the call, rather than pre-entered or contained in a script or database. The auth exchange is protected by FCS. So I cannot imagine that a retry will have a different outcome, unless something odd is going on. Possible oddities: 1. Allowing the user to change the secret while the call is still up. It's hard for me to imagine that this actually would save the caller money, unless he can type awfully fast (and accurately). 2. A super-smart script that, around a time of secret change, tried first one secret and then another. But this must be rare, and can be handled by retrying the whole call. Barney Wolff - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jul 16 12:50:03 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id MAA09792; Wed, 16 Jul 1997 12:50:01 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 16 Jul 1997 12:48:32 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id MAA09747 for ietf-ppp-outgoing; Wed, 16 Jul 1997 12:48:31 -0400 (EDT) Received: from shiva-dev.shiva.com (shiva.shiva.com [192.80.57.1]) by merit.edu (8.8.5/8.8.5) with ESMTP id MAA09735 for ; Wed, 16 Jul 1997 12:48:19 -0400 (EDT) Received: (jas@localhost) by shiva-dev.shiva.com (8.7.6/8.6.4) id MAA10627; Wed, 16 Jul 1997 12:44:56 -0400 (EDT) Date: Wed, 16 Jul 1997 12:44:56 -0400 (EDT) From: John Shriver Message-Id: <199707161644.MAA10627@shiva-dev.shiva.com> To: wsimpson@greendragon.com CC: ietf-ppp@merit.edu In-reply-to: <6276.wsimpson@greendragon.com> Subject: Re: CHAP Challenge Request Sender: owner-ietf-ppp@merit.edu Shiva does not re-challenge CHAP. The client would demand the user type the secret again. Most RAS vendors treat PAP and CHAP as user authentication, not machine authentication. Same applies to the client vendors. I know that Vern firmly disagrees with this. I agree with him. (All the clients let you "save" the password on disk. Steal the laptop, and you've broken into the company.) But it's the ugly thruth. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jul 16 13:32:56 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id NAA10724; Wed, 16 Jul 1997 13:32:52 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 16 Jul 1997 13:30:57 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id NAA10677 for ietf-ppp-outgoing; Wed, 16 Jul 1997 13:30:56 -0400 (EDT) Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.8.5/8.8.5) with SMTP id NAA10671 for ; Wed, 16 Jul 1997 13:30:52 -0400 (EDT) Received: from mica.denver.sgi.com (mica.denver.sgi.com [169.238.67.6]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id KAA22057 for <@sgi.engr.sgi.com:ietf-ppp@merit.edu>; Wed, 16 Jul 1997 10:30:50 -0700 env-from (vjs@mica.denver.sgi.com) Received: (from vjs@localhost) by mica.denver.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA08067 for ietf-ppp@merit.edu; Wed, 16 Jul 1997 11:30:50 -0600 Date: Wed, 16 Jul 1997 11:30:50 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199707161730.LAA08067@mica.denver.sgi.com> To: ietf-ppp@merit.edu Subject: re: Re-tries of Failed Authentication Sender: owner-ietf-ppp@merit.edu > From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) > I've recently been asked to look into providing some sort of support for > authentication re-tries. RFC 1994 states (on page 10): > > There is no provision for re-tries of failed authentication. > However, the LCP state machine can renegotiate the authentication > protocol at any time, thus allowing a new attempt. > > What I'd like to know is does anyone else support this ? If so, would > you expect LCP to be re-negotiated instead of sending CHAP Failure, or > after it ? > > And is allowing re-tries a sensible thing to do anyway ? What do you mean by re-trying authentication? You can't mean retransmitting CHAP challenges or PAP requests when the peer failed to answer, since you doubtless treat that as a normal lost packet. The classic timesharing attitude, predating UNIX (e.g. Project Genie or SDS-940 from the early 1960's), is that you must not give the other guy a chance make a lot of guesses. You must somehow limit a bad guy to at most a few guesses per second. In PPP, I think most of us with non-PC backgrounds figure that means hanging up the phone soon after sending a CHAP or PAP "wrong password" message, forcing the bad guy to spend the time to redial. (I'm sorry, but it's hard to not infer things from the continue revelations of the quality of "very popular" PC PPP software.) On the other end of the phone, what does it mean to retry authentication? Computers don't make typing mistakes, and so do not need more than one try per password. If the peer knows the right password, why wouldn't it use it the first time? Would your system try each of a dozen different passwords, hoping one of them is the right one? Does that sound like behavior that the authenticator should support? Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jul 16 13:47:43 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id NAA11159; Wed, 16 Jul 1997 13:47:41 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 16 Jul 1997 13:46:11 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id NAA11054 for ietf-ppp-outgoing; Wed, 16 Jul 1997 13:46:10 -0400 (EDT) Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.8.5/8.8.5) with SMTP id NAA11050 for ; Wed, 16 Jul 1997 13:46:05 -0400 (EDT) Received: from mica.denver.sgi.com (mica.denver.sgi.com [169.238.67.6]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id KAA26257 for <@sgi.engr.sgi.com:ietf-ppp@merit.edu>; Wed, 16 Jul 1997 10:46:02 -0700 env-from (vjs@mica.denver.sgi.com) Received: (from vjs@localhost) by mica.denver.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA08159 for ietf-ppp@merit.edu; Wed, 16 Jul 1997 11:46:01 -0600 Date: Wed, 16 Jul 1997 11:46:01 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199707161746.LAA08159@mica.denver.sgi.com> To: ietf-ppp@merit.edu Subject: Re: CHAP Challenge Request Sender: owner-ietf-ppp@merit.edu > From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) > ... > > - Use some new LCP or CHAP message to prod the PC. (Yecch.) > > The trouble with this is that the TA is being sold to work with existing > systems. Even if we all agreed that this is a good idea (unlikely in > itself), it would probably be at least 2 years before it was released in > a new version of the PC OS, by which time something would probably have > happened to make this TA solution obsolete (e.g. Microsoft may release > software which supports BACP/BAP). What does BACP/BAP have to do with anything? Never mind the fact that BACP is useful only if you belive that it makes sense to reserve up to 50% of the ports out of the hunt group. Never mind that there will always be literally millions of "clients" that will never support BACP/BAP. Never mind that the main need of BACP, to tell the client the first phone number to call, not the second, is impossible to meet. Never mind that L2TP, LTF, and the other tunneling protocols eliminate the need for BACP. Never mind that everyone now also supports tunneling to handle the multiple chassis problem. If you do believe in MPPP/MP+/BACP, wouldn't you be forced to put all BACP/BAP support into the TA? Wouldn't you make the TA filter all BACP/BAP packets so they do not reach the host? how would the PC running the new Microsoft BACP/BAP software tell the TA to dial another number using in-band signallihg on the single RS-232 async pipe between the host and the TA? You only get one shot of AT commands. > > > > - Forge an LCP Configure-Request to the PC to restart > > everything. (Yecch ** 2) > > Renegotiating LCP to the PC will cause it to renegotiate IPCP, > which in the case of the PC OS we're talking about will clear down > all active TCP sessions, making Bandwidth on Demand a bit > pointless. Say what? Not only do they not do CHAP as defined from the first RFC, but they cannot do IPCP as defined by all of its RFCs? And people say I'm unfair to PC software. Sheesh--there is a limit to how much contorting you should do for junk. There must be some non-junk PPP software for WINTEL machines. Why not tell those very few of your customers that will be using your TAs to answer phone calls to use it? > ... > Maybe this level of security risk will be acceptable to sort of users who > would buy the TA solution. Since most users are willing to use unidectional authentication, and most Internet Service Providers are unwilling to authenticate themselves to their clients (i.e. support bidirectional authentication), and since few people use async TAs to run ISP's, this whole issue seems a triffle moot. (Yes, I still think symmetric authentication is the right thing to do.) > I think, however, that the real solution is not to use a TA at all. > Install an ISDN card in the PC, and make do without BAP/BACP for Bandwidth > on Demand (because, as Vernon keeps telling us, BAP isn't necessary for > BOD). There are plenty of existence proofs. Besides, BAP/BACP has absolutely nothing to do with deciding to add or delete bandwidth. BAP/BACP had only a slight justification for communicating telephone numbers for second channels. But what do you figure BAP/BACP has to do with this issue? > Or use a router attached to the PC via a LAN (if you have a bit more > money to spend). If you can do 'it' with a "router", whatever 'it' is, why can't you do 'it' just as well with the CPU and so forth in your TA? What is the difference between a TA connected to the PC via an RS-232 cable and a TA connected to the PC via a LAN? Given the cost of 10BASE-T chips compared to RS-232 UARTS and driver/receivers, why should your customer need to spend more money just because your TA is topologically a router instead of hidden PPP bridge? (No, not an Ethernet bridge, but the equivalent of a bridge in the PPP universe.) > ] Can you not extend your AT command sequence to include a way for the PC > ] to tell the T/A the CHAP secret along with the telephone number? > > This is ok for the authenticatee, but for the authenticator it may not be > just a single secret. It'll be all the secrets for all the potential peers > who may connect in. You are not going to run an ISP with a translating TA, are you? > Besides, I don't know of any way to make the PC > divulge its secrets. What do you mean? You doubtless did as everyone else who makes modems or TAs, and extended the "Hayes AT command set" with your own special features. Why can't you also extend the AT command set to say "here is a list of 6 or 12 username/secret pairs". The host would send that AT command along with the other AT commands to specify phone numbers, SPIDs, permission to use MP, and so forth. Your TA could notice which username the PC uses on its first challenge, and then do the right thing, generating its own challenges without bothering the PC as the second channel comes and goes. Note that real bandwidth on demand is not just fiddling with the second channel, but also involves turning off the first channel when the link is idle. Then there is really genuine bandwidth on demand means that either system calls the other at need. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jul 16 13:46:42 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id NAA11083; Wed, 16 Jul 1997 13:46:41 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 16 Jul 1997 13:45:05 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id NAA11027 for ietf-ppp-outgoing; Wed, 16 Jul 1997 13:45:04 -0400 (EDT) Received: from horizon4.gandalf.ca (horizon.gandalf.ca [206.248.73.2]) by merit.edu (8.8.5/8.8.5) with SMTP id NAA11006 for ; Wed, 16 Jul 1997 13:44:32 -0400 (EDT) Received: tid NAA05208; Wed, 16 Jul 1997 13:49:24 -0400 Received: from cheeko.gandalf.ca by hobbit.gandalf.ca (4.1/SMI-4.1) id AA02265; Wed, 16 Jul 97 13:42:47 EDT From: sullivan@gandalf.ca (Chris Sullivan) Message-Id: <9707161742.AA02265@hobbit.gandalf.ca> Subject: Re: Re-tries of Failed Authentication To: vjs@mica.denver.sgi.com (Vernon Schryver) Date: Wed, 16 Jul 1997 13:42:45 -0400 (EDT) Cc: ietf-ppp@merit.edu In-Reply-To: <199707161730.LAA08067@mica.denver.sgi.com> from "Vernon Schryver" at Jul 16, 97 11:30:50 am X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu > What do you mean by re-trying authentication? > > You can't mean retransmitting CHAP challenges or PAP requests when the > peer failed to answer, since you doubtless treat that as a normal > lost packet. > > The classic timesharing attitude, predating UNIX (e.g. Project Genie or > SDS-940 from the early 1960's), is that you must not give the other guy > a chance make a lot of guesses. You must somehow limit a bad guy to at > most a few guesses per second. In PPP, I think most of us with non-PC > backgrounds figure that means hanging up the phone soon after sending a > CHAP or PAP "wrong password" message, forcing the bad guy to spend the > time to redial. (I'm sorry, but it's hard to not infer things from the > continue revelations of the quality of "very popular" PC PPP software.) > > On the other end of the phone, what does it mean to retry authentication? > Computers don't make typing mistakes, and so do not need more than one > try per password. If the peer knows the right password, why wouldn't > it use it the first time? Would your system try each of a dozen > different passwords, hoping one of them is the right one? Does that > sound like behavior that the authenticator should support? Implementation Notes: Because the Success might be lost, the authenticator MUST allow repeated Response packets during the Network-Layer Protocol phase after completing the Authentication phase. To prevent discovery of alternative Names and Secrets, any Response packets received having the current Challenge Identifier MUST return the same reply Code previously returned for that specific Challenge (the message portion MAY be different). Any Response packets received during any other phase MUST be silently discarded. These words in RFC1994 seem to disallow retries using the same packet ID. If the first one failed, later ones will fail. -- Chris Sullivan Gandalf Data Limited sullivan@gandalf.ca does not necessarily share my opinions, including this one - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jul 16 16:49:56 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id QAA15523; Wed, 16 Jul 1997 16:49:42 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 16 Jul 1997 16:47:46 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id QAA15448 for ietf-ppp-outgoing; Wed, 16 Jul 1997 16:47:45 -0400 (EDT) Received: from mailhost2.BayNetworks.COM (ns1.BayNetworks.COM [134.177.3.20]) by merit.edu (8.8.5/8.8.5) with ESMTP id QAA15441 for ; Wed, 16 Jul 1997 16:47:39 -0400 (EDT) Received: from mailhost.BayNetworks.COM ([134.177.1.107]) by mailhost2.BayNetworks.COM (8.8.5/BNET-97/07/07-E) with ESMTP id NAA09560; Wed, 16 Jul 1997 13:46:56 -0700 (PDT) for Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.5/BNET-97/07/07-I) with ESMTP id NAA02329; Wed, 16 Jul 1997 13:47:02 -0700 (PDT) for Posted-Date: Wed, 16 Jul 1997 13:47:02 -0700 (PDT) Received: from sgtpepper.engeast (sgtpepper [192.32.170.17]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id QAA12561; Wed, 16 Jul 1997 16:47:02 -0400 for Date: Wed, 16 Jul 1997 16:47:02 -0400 From: eallen@BayNetworks.COM (Ed Allen) Message-Id: <199707162047.QAA12561@pobox.engeast.BayNetworks.COM> Received: by sgtpepper.engeast (4.1/SMI-4.1) id AA09263; Wed, 16 Jul 97 16:47:00 EDT To: ietf-ppp@merit.edu Cc: dhaskin@engeast, eallen@engeast Subject: new IPv6 CP draft Sender: owner-ietf-ppp@merit.edu A new draft of the IPv6 CP is now available in the internet drafts directory under the file name draft-ietf-ipngwg-ipv6-over-ppp-02.txt The new draft contains further structure of the Interface Token option which reflects changes made in the IPv6 addressing architecture. We believe this is the last revision required. Once the IPv6 addressing architecture reaches stability (in the IPNG WG) we will request a working group last call on this draft. Looking forward to your review and comments. - Ed Allen - Dimitry Haskin - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jul 16 23:50:29 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id XAA23770; Wed, 16 Jul 1997 23:50:25 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 16 Jul 1997 23:47:58 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id XAA23675 for ietf-ppp-outgoing; Wed, 16 Jul 1997 23:47:57 -0400 (EDT) Received: from pitbull.cisco.com (pitbull.cisco.com [171.69.223.73]) by merit.edu (8.8.5/8.8.5) with SMTP id XAA23669 for ; Wed, 16 Jul 1997 23:47:53 -0400 (EDT) Received: from [171.69.128.118] (fred-hm-dhcp3.cisco.com [171.69.128.118]) by pitbull.cisco.com (8.6.12/8.6.5) with ESMTP id UAA20275 for ; Wed, 16 Jul 1997 20:47:22 -0700 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 16 Jul 1997 20:45:09 -0700 To: ietf-ppp@merit.edu From: tstream@west.net (by way of Fred Baker) Subject: BACP interoperability test Sender: owner-ietf-ppp@merit.edu Transtream Inc., is a California based company, involved in the development of ISDN TAs. We have recently implemented BACP (RFC 2125) in one of our products. We would appreciate it very much, if you could inform us where we can perform the interoperability test for this protocol. Thanks Nalinakshan. K - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jul 17 06:15:51 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id GAA27847; Thu, 17 Jul 1997 06:15:13 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 17 Jul 1997 06:13:10 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id GAA27819 for ietf-ppp-outgoing; Thu, 17 Jul 1997 06:13:09 -0400 (EDT) Received: from directors.rdl.co.uk (directors.rdl.co.uk [193.119.77.2]) by merit.edu (8.8.5/8.8.5) with ESMTP id GAA27813 for ; Thu, 17 Jul 1997 06:13:04 -0400 (EDT) Received: from imaccgw.rdl.co.uk (imaccgw.rdl.co.uk [193.240.106.205]) by directors.rdl.co.uk (8.7.3/8.7.3) with SMTP id LAA03822; Thu, 17 Jul 1997 11:13:00 +0100 (BST) Received: from ccMail by imaccgw.rdl.co.uk (IMA Internet Exchange 1.04b) id 3cdefc40; Thu, 17 Jul 97 11:11:16 +0100 Mime-Version: 1.0 Date: Thu, 17 Jul 1997 11:08:31 +0100 Message-ID: <3cdefc40@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re: CHAP Challenge Request To: ietf-ppp@merit.edu, vjs@mica.denver.sgi.com (Vernon Schryver) Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: owner-ietf-ppp@merit.edu From Vernon Schryver: >> ... >> > - Use some new LCP or CHAP message to prod the PC. (Yecch.) >> >> The trouble with this is that the TA is being sold to work with >> existing systems. Even if we all agreed that this is a good idea >> (unlikely in itself), it would probably be at least 2 years before it >> was released in a new version of the PC OS, by which time something >> would probably have happened to make this TA solution obsolete (e.g. >> Microsoft may release software which supports BACP/BAP). > What does BACP/BAP have to do with anything? Well, why do you need a "fancy translating TA" (FTTA) in the first place ? Now, I don't know the application that Eicon have in mind, but I do know that one that we targetted our product at: the FTTA would be a front end to a WindowsNT or Win95 RAS, which would allow access to a single remote user. Microsoft PPP already supports MP, so the user could use both B channels simply by connecting 2 cables from the 2 COM ports on the PC to two DTE ports on the TA. Or, you could provide some sort of multiplexing over a single cable if you were really clever. So the reason for having an FTTA would be to provide some sort of functionality that Microsoft PPP does not provide. Our justification for developing such a product was BACP/BAP (never mind that users don't actually need it - they seem to think that they want it). >... >If you do believe in MPPP/MP+/BACP, wouldn't you be forced to put all >BACP/BAP support into the TA? Wouldn't you make the TA filter all >BACP/BAP packets so they do not reach the host? Well, yes, this is what the FTTA does. >how would the PC running the new Microsoft BACP/BAP software tell the >TA to dial another number using in-band signallihg on the single >RS-232 async pipe between the host and the TA? You only get one shot >of AT commands. As I said above, use two cables, or have some sort of muxing (of course, you'd have to be able to write a Windows device driver to do it, plus get the user to install it, but it's simpler than doing the translation). >>... >> Renegotiating LCP to the PC will cause it to renegotiate IPCP, >> which in the case of the PC OS we're talking about will clear >> down all active TCP sessions, making Bandwidth on Demand a bit >> pointless. >Say what? Not only do they not do CHAP as defined from the first RFC, >but they cannot do IPCP as defined by all of its RFCs? And people say >I'm unfair to PC software. Sheesh--there is a limit to how much >contorting you should do for junk. There must be some non-junk >PPP software for WINTEL machines. Why not tell those very few of >your customers that will be using your TAs to answer phone calls to >use it? It would be easier to tell them to use one of our PC ISDN cards instead. But some users prefer TAs, and they are likely to be the same sort of user who wouldn't want to install another set of PPP software when they've already got one. You and I may know that Microsoft's PPP implementation may not be the best in the world, but it's difficult to convince users about that. So there may be a significant market for anyone prepared to go through the contortions. > ... >> I think, however, that the real solution is not to use a TA at all. >> Install an ISDN card in the PC, and make do without BAP/BACP for >> Bandwidth on Demand (because, as Vernon keeps telling us, BAP isn't >> necessary for BOD). > >There are plenty of existence proofs. Besides, BAP/BACP has >absolutely nothing to do with deciding to add or delete bandwidth. >BAP/BACP had only a slight justification for communicating telephone >numbers for second channels. > >But what do you figure BAP/BACP has to do with this issue? See above. >> Or use a router attached to the PC via a LAN (if you have a bit >> more money to spend). > >If you can do 'it' with a "router", whatever 'it' is, why can't you do >'it' just as well with the CPU and so forth in your TA? What is the >difference between a TA connected to the PC via an RS-232 cable and a >TA connected to the PC via a LAN? The difference is in software in the PC - if you use the COM port then you need the MS RAS software, otherwise you just use the standard LAN Manager software. If you're using the RAS software, then it treats the MS-CHAP or PAP authentication as a login to the file server. >Given the cost of 10BASE-T chips compared to RS-232 UARTS and >driver/receivers, why should your customer need to spend more money >just because your TA is topologically a router instead of hidden PPP >bridge? (No, not an Ethernet bridge, but the equivalent of a bridge >in the PPP universe.) Yes, you're probably right - an ethernet router could be just as cheap as a TA. >.... >> Besides, I don't know of any way to make the PC divulge its >> secrets. > >What do you mean? I mean that once all the Secrets have been entered in the PC, there's no published way to get at them. You'd have to store all the secrets twice, which is another sort of reduction in security. --- Jonathan Goodchild - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jul 17 07:14:42 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id HAA28266; Thu, 17 Jul 1997 07:14:35 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 17 Jul 1997 07:13:54 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id HAA28247 for ietf-ppp-outgoing; Thu, 17 Jul 1997 07:13:54 -0400 (EDT) Received: from directors.rdl.co.uk (directors.rdl.co.uk [193.119.77.2]) by merit.edu (8.8.5/8.8.5) with ESMTP id HAA28241 for ; Thu, 17 Jul 1997 07:13:49 -0400 (EDT) Received: from imaccgw.rdl.co.uk (imaccgw.rdl.co.uk [193.240.106.205]) by directors.rdl.co.uk (8.7.3/8.7.3) with SMTP id MAA05806 for ; Thu, 17 Jul 1997 12:13:45 +0100 (BST) Received: from ccMail by imaccgw.rdl.co.uk (IMA Internet Exchange 1.04b) id 3cdfe010; Thu, 17 Jul 97 12:12:01 +0100 Mime-Version: 1.0 Date: Thu, 17 Jul 1997 12:05:01 +0100 Message-ID: <3cdfe010@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re: Re-tries of Failed Authentication To: ietf-ppp@merit.edu Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: owner-ietf-ppp@merit.edu From Vernon Schryver: > What do you mean by re-trying authentication? I'm talking about the case in which the authentication involves human interaction and the user mis-types their password/secret. (Yes, PCs again !) > You can't mean retransmitting CHAP challenges or PAP requests when the > peer failed to answer, since you doubtless treat that as a normal > lost packet. Correct. > The classic timesharing attitude, predating UNIX (e.g. Project Genie or > SDS-940 from the early 1960's), is that you must not give the other guy > a chance make a lot of guesses. You must somehow limit a bad guy to at > most a few guesses per second. In PPP, I think most of us with non-PC > backgrounds figure that means hanging up the phone soon after sending a > CHAP or PAP "wrong password" message, forcing the bad guy to spend the > time to redial. Yes, I figure that as well. In fact, when I was originally asked the question, I said "don't be silly - no-one will support that", with the result that our Functional Spec got re-written to disallow re-tries for PAP and CHAP. But I got to thinking about it, and then I saw that paragraph I quoted from RFC 1994, and I wondered if I had been a bit hasty in discounting the possibility. > On the other end of the phone, what does it mean to retry authentication? > Computers don't make typing mistakes, and so do not need more than one > try per password. If the peer knows the right password, why wouldn't > it use it the first time? Would your system try each of a dozen > different passwords, hoping one of them is the right one? Does that > sound like behavior that the authenticator should support? No it doesn't. But what if a human is entering the password at the peer ? Chris Sullivan writes: ] Implementation Notes: Because the Success might be lost, the ] authenticator MUST allow repeated Response packets during ] the Network-Layer Protocol phase after completing the ] Authentication phase. To prevent discovery of alternative ] Names and Secrets, any Response packets received having the ] current Challenge Identifier MUST return the same reply Code ] previously returned for that specific Challenge (the message ] portion MAY be different). Any Response packets received during ] any other phase MUST be silently discarded. ] ] These words in RFC1994 seem to disallow retries using the same packet ID. ] If the first one failed, later ones will fail. Quite. Which is why you would have to renegotiate LCP before another attempt. I don't think there would be an interoperability penalty in implementing re-tries. The authenticator, having sent the CHAP failure or PAP Nak, would send a new LCP Configure-Request. If the peer hangs up the phone or terminates LCP, then it doesn't support re-tries, and you haven't lost anything. At the authenticatee, then send a new LCP Configure-Request when you receive the CHAP failure. If the authenticator terminates LCP, then you know that it doesn't allow re-tries, otherwise you tell the user to get ready to re-enter the password. Of course, the authenticator would have to limit the total number of re-tries per call to a small number (e.g. 2 re-tries, making 3 attempts in all). And maybe the default configuration for most installations would be zero re-tries. But unless I find out that someone else actually supports re-tries, I don't think I'll bother implementing it myself. --- Jonathan Goodchild - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jul 17 09:02:42 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id JAA00274; Thu, 17 Jul 1997 09:02:26 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 17 Jul 1997 08:59:50 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id IAA00174 for ietf-ppp-outgoing; Thu, 17 Jul 1997 08:59:49 -0400 (EDT) Received: from SanFrancisco01.POP.InterNex.Net (sanfrancisco01.pop.InterNex.Net [205.158.3.50]) by merit.edu (8.8.5/8.8.5) with ESMTP id IAA00170 for ; Thu, 17 Jul 1997 08:59:42 -0400 (EDT) Received: from senior ([205.158.231.117]) by SanFrancisco01.POP.InterNex.Net (post.office MTA v1.9.3 ID# 0-11028) with SMTP id AAA6440; Thu, 17 Jul 1997 05:59:40 -0700 Message-Id: <3.0.32.19970717053552.00a4c800@SanFrancisco01.pop.internex.net> X-Sender: larribeau-2@SanFrancisco01.pop.internex.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 17 Jul 1997 05:59:08 -0700 To: tstream@west.net (by way of Fred Baker), ietf-ppp@merit.edu From: bob@larribeau.com (Bob Larribeau) Subject: Re: BACP interoperability test Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu The California ISDN Users' Group is planning to hold its next ISDN PPP Interoperability Workshop in February next year. Send us your email address and we will add your email address to the list of people to receive an application. We will also send an email to this mailing list when applications are available. The applications will be sent out in December. Bob Larribeau Chairman At 08:45 PM 7/16/97 -0700, tstream@west.net wrote: > >Transtream Inc., is a California based company, involved in the development of >ISDN TAs. We have recently implemented BACP (RFC 2125) in one of our products. > >We would appreciate it very much, if you could inform us where we can >perform the interoperability test for this protocol. > >Thanks > >Nalinakshan. K > > > ***************************************************************** * California ISDN User's Group info@ciug.com * * P.O. Box 27901-318 http://www.ciug.org * * San Francisco, CA 94127 Voice: (415)241-9943 * * A California nonprofit corporation Fax: (415)753-6942 * * * * LATEST NEWSLETTER IS ON OUR WEB PAGE * * * * Send us your postal address Spring Conference * * and we will send you our June 19 &20 * * latest newsletter and San Diego Concourse * * information on our next conference * ***************************************************************** - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jul 17 12:08:26 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id MAA04996; Thu, 17 Jul 1997 12:08:14 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 17 Jul 1997 12:04:42 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id MAA04919 for ietf-ppp-outgoing; Thu, 17 Jul 1997 12:04:42 -0400 (EDT) Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.8.5/8.8.5) with SMTP id MAA04911 for ; Thu, 17 Jul 1997 12:04:37 -0400 (EDT) Received: from mica.denver.sgi.com (mica.denver.sgi.com [169.238.67.6]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id JAA06140 for <@sgi.engr.sgi.com:ietf-ppp@merit.edu>; Thu, 17 Jul 1997 09:04:20 -0700 env-from (vjs@mica.denver.sgi.com) Received: (from vjs@localhost) by mica.denver.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA10363 for ietf-ppp@merit.edu; Thu, 17 Jul 1997 10:02:37 -0600 Date: Thu, 17 Jul 1997 10:02:37 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199707171602.KAA10363@mica.denver.sgi.com> To: ietf-ppp@merit.edu Subject: Re: CHAP Challenge Request Sender: owner-ietf-ppp@merit.edu From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) > ... > >If you can do 'it' with a "router", whatever 'it' is, why can't you do > >'it' just as well with the CPU and so forth in your TA? What is the > >difference between a TA connected to the PC via an RS-232 cable and a > >TA connected to the PC via a LAN? > > The difference is in software in the PC - if you use the COM port then > you need the MS RAS software, otherwise you just use the standard LAN > Manager software. If you're using the RAS software, then it treats the > MS-CHAP or PAP authentication as a login to the file server. > > >Given the cost of 10BASE-T chips compared to RS-232 UARTS and > >driver/receivers, why should your customer need to spend more money > >just because your TA is topologically a router instead of hidden PPP > >bridge? (No, not an Ethernet bridge, but the equivalent of a bridge > >in the PPP universe.) > > Yes, you're probably right - an ethernet router could be just as cheap > as a TA. I wasn't clear. Let me rephrase it. Why does the PC care whether the PPP router to which it is connected via its single RS-232 cable is a foot away or 10 miles away? Why not make your ISDN TA a full-featured router with all of the stuff usually associated with the notion? Whether the PC talks to your ISDN router via PPP/RS-232 or Ethernet is a minor issue. Let this RS-232-ISDN-TA-router be configured via AT commands on its RS-232 port instead of (or in addition to) SNMP or whatever. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jul 17 13:16:38 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id NAA07078; Thu, 17 Jul 1997 13:16:17 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 17 Jul 1997 13:13:29 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id NAA07018 for ietf-ppp-outgoing; Thu, 17 Jul 1997 13:13:29 -0400 (EDT) Received: from directors.rdl.co.uk (directors.rdl.co.uk [193.119.77.2]) by merit.edu (8.8.5/8.8.5) with ESMTP id NAA07008 for ; Thu, 17 Jul 1997 13:13:23 -0400 (EDT) Received: from imaccgw.rdl.co.uk (imaccgw.rdl.co.uk [193.240.106.205]) by directors.rdl.co.uk (8.7.3/8.7.3) with SMTP id SAA17879 for ; Thu, 17 Jul 1997 18:13:21 +0100 (BST) Received: from ccMail by imaccgw.rdl.co.uk (IMA Internet Exchange 1.04b) id 3ce52490; Thu, 17 Jul 97 18:11:37 +0100 Mime-Version: 1.0 Date: Thu, 17 Jul 1997 18:06:21 +0100 Message-ID: <3ce52490@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re: CHAP Challenge Request To: ietf-ppp@merit.edu Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: owner-ietf-ppp@merit.edu From Vernon Schryver: >Why does the PC care whether the PPP router to which it is connected >via its single RS-232 cable is a foot away or 10 miles away? If you connect via RS-232 (i.e. via the COM port in PC terms), then the Windows RAS software expects the user to be on the other end of the link. It applies the authentication applies to 2 levels: 1) normal PPP link access 2) login to the file server If you have a router connected via the COM port, then you'll log the router into the server, rather than the real user. Alternatively, you would have to duplicate the secrets for all the users in the router, so that it could use the appropriate userid and secret. (I proposed this latter course of action for our TA, but I was told that users wouldn't accept it). You don't get this sort of problem when connecting via the LAN. Of course, you could write a driver to make the COM port look like a LAN interface. --- Jonathan Goodchild P.S. As I expect most people have lost interest in this thread by now, I'll keep any future responses off the list unless anyone mails me to request otherwise. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jul 17 13:32:16 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id NAA07620; Thu, 17 Jul 1997 13:32:15 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 17 Jul 1997 13:30:13 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id NAA07548 for ietf-ppp-outgoing; Thu, 17 Jul 1997 13:30:11 -0400 (EDT) Received: from adtrn-srv2.adtran.com ([206.26.161.246]) by merit.edu (8.8.5/8.8.5) with SMTP id NAA07537 for ; Thu, 17 Jul 1997 13:30:02 -0400 (EDT) Received: from crusher.adtran.com (engn-123.adtran.com) by adtrn-srv2.adtran.com (4.1/1.57) id AA04169; Thu, 17 Jul 97 12:29:27 CDT Message-Id: <9707171729.AA04169@adtrn-srv2.adtran.com> From: "Kyle Farnsworth" To: Subject: Re: CHAP Challenge Request Date: Thu, 17 Jul 1997 12:29:25 -0500 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu From: Vernon Schryver > Why does the PC care whether the PPP router to which it is connected > via its single RS-232 cable is a foot away or 10 miles away? > Why not make your ISDN TA a full-featured router with all of the > stuff usually associated with the notion? Whether the PC talks > to your ISDN router via PPP/RS-232 or Ethernet is a minor issue. > > Let this RS-232-ISDN-TA-router be configured via AT commands on > its RS-232 port instead of (or in addition to) SNMP or whatever. > Having the TA be protocol independent has advantages in that any routing protocol (IPX, Appletalk...etc.) can be used with the TA. The TA only worries about L2 protocols like PPP. __________________________________________ Kyle Farnsworth Adtran Inc. kfarnsworth@adtran.com http://www.adtran.com (205)-971-8000 __________________________________________ - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jul 17 13:59:40 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id NAA08671; Thu, 17 Jul 1997 13:59:37 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 17 Jul 1997 13:57:51 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id NAA08583 for ietf-ppp-outgoing; Thu, 17 Jul 1997 13:57:50 -0400 (EDT) Received: from webserver.casc.com (webserver.casc.com [152.148.41.200]) by merit.edu (8.8.5/8.8.5) with SMTP id NAA08560 for ; Thu, 17 Jul 1997 13:57:29 -0400 (EDT) Received: from casc.com (alpo [152.148.10.6]) by webserver.casc.com (8.6.12/8.6.12) with ESMTP id NAA02126; Thu, 17 Jul 1997 13:54:30 -0400 Received: from spice.cascade by casc.com (SMI-8.6/SMI-SVR4-bob.2) id NAA02269; Thu, 17 Jul 1997 13:58:05 -0400 Received: from localhost by spice.cascade (SMI-8.6/SMI-SVR4) id NAA03793; Thu, 17 Jul 1997 13:58:06 -0400 Date: Thu, 17 Jul 1997 13:58:05 -0400 (EDT) From: "Andrew G. Malis" X-Sender: amalis@spice To: rajeshs cc: "'ietf-ppp'" Subject: Re: PPP over ATM or ADSL In-Reply-To: <33CD6371@msgate.future.futsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Rajeshs, > Please excuse me for using the mailing list for a personal query. > We're looking for any implementations of PPP over ATM and PPP over > ADSL. Any info on standards regarding these or vendors providing > these would be appreciated. There are two I-Ds on the topic (one for PPP over AAL5 and the other for PPP over FUNI) that will be brought into the Munich meeting. They should be available in time for the 7/30 I-D deadline. They conform to the ADSL Forum's packet mode spec, are intended for use over ADSL (as well as standalone). Andy ________________________________________________________________________ Andrew G. Malis malis@casc.com phone:508 952-7414 fax:508 392-1484 Ascend Communications, Inc. 5 Carlisle Road Westford, MA 01886 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Jul 18 17:07:09 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id RAA14128; Fri, 18 Jul 1997 17:06:40 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 18 Jul 1997 16:52:26 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id QAA13792 for ietf-ppp-outgoing; Fri, 18 Jul 1997 16:52:25 -0400 (EDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.29]) by merit.edu (8.8.5/8.8.5) with ESMTP id QAA13785 for ; Fri, 18 Jul 1997 16:52:19 -0400 (EDT) Received: by mail4.microsoft.com with Internet Mail Service (5.0.1458.49) id ; Fri, 18 Jul 1997 13:49:48 -0700 Message-ID: From: Gurdeep Singh Pall To: "'Jonathan.Goodchild@rdl.co.uk'" , ietf-ppp@merit.edu Subject: RE: CHAP Challenge Request Date: Fri, 18 Jul 1997 13:49:08 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Sender: owner-ietf-ppp@merit.edu Sorry to jump into this discussion this late. While, you can always try to contort/distort/stretch the PPP protocol and its implementations to solve a problem, I will encourage you to look at the extensible WAN driver model in Win95 and NT to integrate your device better than having it sit behind a serial driver. About 200 implementations today use this driver model. We are also looking at providing a standard way to integrate devices like yours that have a single point of connection to the system (using serial cable, Ir, USB, 1394 connectivity) so that advanced features like Raw channel access, Voice, FAX, BAP, EAP and Qos are better integrated into Windows. Please contact me directly if you will like more info. Cheers, Gurdeep > -----Original Message----- > From: Jonathan.Goodchild@rdl.co.uk [SMTP:Jonathan.Goodchild@rdl.co.uk] > Sent: Thursday, July 17, 1997 3:09 AM > To: ietf-ppp@merit.edu; vjs@mica.denver.sgi.com > Subject: Re: CHAP Challenge Request > > From Vernon Schryver: > >> ... > >> > - Use some new LCP or CHAP message to prod the PC. (Yecch.) > >> > >> The trouble with this is that the TA is being sold to work with > >> existing systems. Even if we all agreed that this is a good idea > >> (unlikely in itself), it would probably be at least 2 years before > it > >> was released in a new version of the PC OS, by which time something > > >> would probably have happened to make this TA solution obsolete > (e.g. > >> Microsoft may release software which supports BACP/BAP). > > > What does BACP/BAP have to do with anything? > > Well, why do you need a "fancy translating TA" (FTTA) in the first > place ? > Now, I don't know the application that Eicon have in mind, but I do > know > that one that we targetted our product at: the FTTA would be a front > end > to a WindowsNT or Win95 RAS, which would allow access to a single > remote > user. > > Microsoft PPP already supports MP, so the user could use both B > channels > simply by connecting 2 cables from the 2 COM ports on the PC to two > DTE > ports on the TA. Or, you could provide some sort of multiplexing over > a > single cable if you were really clever. > > So the reason for having an FTTA would be to provide some sort of > functionality that Microsoft PPP does not provide. Our justification > for > developing such a product was BACP/BAP (never mind that users don't > actually need it - they seem to think that they want it). > > >... > >If you do believe in MPPP/MP+/BACP, wouldn't you be forced to put all > > >BACP/BAP support into the TA? Wouldn't you make the TA filter all > >BACP/BAP packets so they do not reach the host? > > Well, yes, this is what the FTTA does. > > >how would the PC running the new Microsoft BACP/BAP software tell the > > >TA to dial another number using in-band signallihg on the single > >RS-232 async pipe between the host and the TA? You only get one shot > > >of AT commands. > > As I said above, use two cables, or have some sort of muxing (of > course, you'd have to be able to write a Windows device driver to do > it, plus get the user to install it, but it's simpler than doing the > translation). > > >>... > >> Renegotiating LCP to the PC will cause it to renegotiate IPCP, > >> which in the case of the PC OS we're talking about will clear > >> down all active TCP sessions, making Bandwidth on Demand a bit > >> pointless. > > >Say what? Not only do they not do CHAP as defined from the first > RFC, > >but they cannot do IPCP as defined by all of its RFCs? And people > say > >I'm unfair to PC software. Sheesh--there is a limit to how much > >contorting you should do for junk. There must be some non-junk > >PPP software for WINTEL machines. Why not tell those very few of > >your customers that will be using your TAs to answer phone calls to > >use it? > > It would be easier to tell them to use one of our PC ISDN cards > instead. But some users prefer TAs, and they are likely to be the > same sort of user who wouldn't want to install another set of PPP > software when they've already got one. You and I may know that > Microsoft's PPP implementation may not be the best in the world, but > it's difficult to convince users about that. So there may be a > significant market for anyone prepared to go through the contortions. > > > ... > >> I think, however, that the real solution is not to use a TA at all. > > >> Install an ISDN card in the PC, and make do without BAP/BACP for > >> Bandwidth on Demand (because, as Vernon keeps telling us, BAP isn't > > >> necessary for BOD). > > > >There are plenty of existence proofs. Besides, BAP/BACP has > >absolutely nothing to do with deciding to add or delete bandwidth. > >BAP/BACP had only a slight justification for communicating telephone > >numbers for second channels. > > > >But what do you figure BAP/BACP has to do with this issue? > > See above. > > >> Or use a router attached to the PC via a LAN (if you have a bit > >> more money to spend). > > > >If you can do 'it' with a "router", whatever 'it' is, why can't you > do > >'it' just as well with the CPU and so forth in your TA? What is the > >difference between a TA connected to the PC via an RS-232 cable and a > > >TA connected to the PC via a LAN? > > The difference is in software in the PC - if you use the COM port then > > you need the MS RAS software, otherwise you just use the standard LAN > Manager software. If you're using the RAS software, then it treats > the > MS-CHAP or PAP authentication as a login to the file server. > > >Given the cost of 10BASE-T chips compared to RS-232 UARTS and > >driver/receivers, why should your customer need to spend more money > >just because your TA is topologically a router instead of hidden PPP > >bridge? (No, not an Ethernet bridge, but the equivalent of a bridge > >in the PPP universe.) > > Yes, you're probably right - an ethernet router could be just as cheap > > as a TA. > > >.... > >> Besides, I don't know of any way to make the PC divulge its > >> secrets. > > > >What do you mean? > > I mean that once all the Secrets have been entered in the PC, there's > no published way to get at them. You'd have to store all the secrets > twice, which is another sort of reduction in security. > > --- > Jonathan Goodchild > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Jul 21 00:21:28 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id AAA12045; Mon, 21 Jul 1997 00:21:07 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 21 Jul 1997 00:13:10 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id AAA11967 for ietf-ppp-outgoing; Mon, 21 Jul 1997 00:13:09 -0400 (EDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm002-07.dialip.mich.net [141.211.7.143]) by merit.edu (8.8.5/8.8.5) with SMTP id AAA11963 for ; Mon, 21 Jul 1997 00:13:04 -0400 (EDT) Date: Mon, 21 Jul 97 03:54:38 GMT From: "William Allen Simpson" Message-ID: <6290.wsimpson@greendragon.com> To: ietf-ppp@merit.edu Subject: MS TCP/IP/PPP considered harmful Sender: owner-ietf-ppp@merit.edu > From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) > If you connect via RS-232 (i.e. via the COM port in PC terms), then > the Windows RAS software expects the user to be on the other end of > the link. It applies the authentication applies to 2 levels: > > 1) normal PPP link access > 2) login to the file server > > If you have a router connected via the COM port, then you'll log the > router into the server, rather than the real user. > This certainly sounds like a terrible security hole to me! PPP is a peer to peer (machine to machine) link protocol -- not a client/server application protocol. It seems like the implementors at MS had a fundamental misunderstanding of computer networking. I've been privately prompted to collect all the problems with the currently shipping MS WinTel 95/NT TCP/IP/PPP stack(s) into a RFC. Send me your known problems (and workarounds when known), publically or privately, and I'll collate them with what I know already.... WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Jul 21 11:51:44 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id LAA20144; Mon, 21 Jul 1997 11:48:16 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 21 Jul 1997 11:38:10 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id LAA19881 for ietf-ppp-outgoing; Mon, 21 Jul 1997 11:38:09 -0400 (EDT) Received: from tor.securecomputing.com (tor.securecomputing.com [199.71.190.98]) by merit.edu (8.8.5/8.8.5) with ESMTP id LAA19872 for ; Mon, 21 Jul 1997 11:38:03 -0400 (EDT) Received: by janus.tor.securecomputing.com id <11650>; Mon, 21 Jul 1997 11:33:03 -0400 Message-Id: <97Jul21.113303edt.11650@janus.tor.securecomputing.com> To: ietf-ppp@merit.edu Subject: Re: MS TCP/IP/PPP considered harmful References: <6290.wsimpson@greendragon.com> In-reply-to: Your message of "Sun, 20 Jul 1997 23:54:38 -0400". <6290.wsimpson@greendragon.com> From: "C. Harald Koch" Date: Mon, 21 Jul 1997 11:37:50 -0400 Sender: owner-ietf-ppp@merit.edu In message <6290.wsimpson@greendragon.com>, "William Allen Simpson" writes: > This certainly sounds like a terrible security hole to me! > > PPP is a peer to peer (machine to machine) link protocol -- not a > client/server application protocol. It seems like the implementors > at MS had a fundamental misunderstanding of computer networking. MS merely made the (common) assumption that the device attached to the serial port is a modem/TA/whatever, that completes a link-layer connection to the remote access server. FWIW, I've never seen a TCP/IP/PPP stack that allows otherwise, without intelligence built into the com device. MS bashing is popular, but let's not go overboard, lest we be called a black kettle. -- Harald Koch - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Jul 21 15:42:25 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id PAA25783; Mon, 21 Jul 1997 15:42:10 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 21 Jul 1997 15:39:50 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id PAA25703 for ietf-ppp-outgoing; Mon, 21 Jul 1997 15:39:49 -0400 (EDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.31]) by merit.edu (8.8.5/8.8.5) with ESMTP id PAA25698 for ; Mon, 21 Jul 1997 15:39:41 -0400 (EDT) Received: by mail5.microsoft.com with Internet Mail Service (5.0.1458.49) id ; Mon, 21 Jul 1997 12:40:31 -0700 Message-ID: From: Gurdeep Singh Pall To: "'William Allen Simpson'" , ietf-ppp@merit.edu Subject: RE: MS TCP/IP/PPP considered harmful --- NOT! Date: Mon, 21 Jul 1997 12:38:42 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Sender: owner-ietf-ppp@merit.edu > -----Original Message----- > From: William Allen Simpson [SMTP:wsimpson@greendragon.com] > Sent: Sunday, July 20, 1997 8:55 PM > To: ietf-ppp@merit.edu > Subject: MS TCP/IP/PPP considered harmful > > > From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) > > If you connect via RS-232 (i.e. via the COM port in PC terms), then > > the Windows RAS software expects the user to be on the other end of > > the link. It applies the authentication applies to 2 levels: > > > > 1) normal PPP link access > > 2) login to the file server > > > > If you have a router connected via the COM port, then you'll log the > > router into the server, rather than the real user. > > > This certainly sounds like a terrible security hole to me! > Gurdeep> What Jonathon conjectures is untrue. Logging on to file servers is application layer function which gets triggered on the machine that dials in - after a PPP connection is made. This is done so that the user experiences a "seamless" logon to the remote network. In his example, the router will not be able to access file resources unless it too did an application level logon. > PPP is a peer to peer (machine to machine) link protocol -- not a > client/server application protocol. It seems like the implementors > at MS had a fundamental misunderstanding of computer networking. > Gurdeep> Another conjecture! (this time based on another wrong conjecture!) > I've been privately prompted to collect all the problems with the > currently shipping MS WinTel 95/NT TCP/IP/PPP stack(s) into a RFC. > Send me your known problems (and workarounds when known), publically > or > privately, and I'll collate them with what I know already.... > Gurdeep> Thanks for doing this! I hope you will do due dilligence and sift thru conjectures. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 22 09:56:03 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.6/8.8.5) with SMTP id JAA11830; Tue, 22 Jul 1997 09:55:26 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 22 Jul 1997 09:50:53 -0400 Received: (from majordom@localhost) by merit.edu (8.8.6/8.8.5) id JAA11715 for ietf-ppp-outgoing; Tue, 22 Jul 1997 09:50:52 -0400 (EDT) Received: from ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.6/8.8.5) with SMTP id JAA11711 for ; Tue, 22 Jul 1997 09:50:48 -0400 (EDT) Received: from ietf.ietf.org by ietf.org id aa07203; 22 Jul 97 9:50 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-pptp-01.txt Date: Tue, 22 Jul 1997 09:50:07 -0400 Message-ID: <9707220950.aa07203@ietf.org> Sender: owner-ietf-ppp@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 : Point-to-Point Tunneling Protocol--PPTP Author(s) : K. Hamzeh, G. Pall, W. Verthein, J. Taarud, W. Little Filename : draft-ietf-pppext-pptp-01.txt Pages : 62 Date : 07/21/1997 This document specifies a protocol which allows the Point to Point Protocol (PPP) to be tunneled through an IP network. PPTP does not specify any changes to the PPP protocol but rather describes a new vehicle for carrying PPP. A client-server architecture is defined in order to decouple functions which exist in current Network Access Servers (NAS) and support Virtual Private Networks (VPNs). The PPTP Network Server (PNS) is envisioned to run on a general purpose operating system while the client, referred to as a PPTP Access Concentrator (PAC) operates on a dial access platform. PPTP specifies a call-control and management protocol which allows the server to control access for dial-in circuit switched calls originating from a PSTN or ISDN or to initiate outbound circuit-switched connections. PPTP uses a GRE-like (Generic Routing Encapsulation) mechanism to provide a flow- and congestion-controlled encapsulated datagram service for carrying PPP packets. 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-pptp-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-pptp-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-pptp-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970721145118.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-pptp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-pptp-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970721145118.I-D@ietf.org> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 22 09:56:01 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.6/8.8.5) with SMTP id JAA11832; Tue, 22 Jul 1997 09:55:26 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 22 Jul 1997 09:50:47 -0400 Received: (from majordom@localhost) by merit.edu (8.8.6/8.8.5) id JAA11703 for ietf-ppp-outgoing; Tue, 22 Jul 1997 09:50:46 -0400 (EDT) Received: from ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.6/8.8.5) with SMTP id JAA11696 for ; Tue, 22 Jul 1997 09:50:41 -0400 (EDT) Received: from ietf.ietf.org by ietf.org id aa07032; 22 Jul 97 9:49 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-3des-encrypt-00.txt Date: Tue, 22 Jul 1997 09:49:47 -0400 Message-ID: <9707220949.aa07032@ietf.org> Sender: owner-ietf-ppp@merit.edu --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : The PPP Triple-DES Encryption Protocol (3DESE) Author(s) : H. Kummert Filename : draft-ietf-pppext-3des-encrypt-00.txt Pages : 8 Date : 07/21/1997 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. The PPP Encryption Control Protocol (ECP) [2] provides a method to negotiate and utilize encryption protocols over PPP encapsulated links. This document provides specific details for the use of the Triple-DES standard (3DES) [6] for encrypting PPP encapsulated packets. 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-3des-encrypt-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-3des-encrypt-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-3des-encrypt-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970721135330.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-3des-encrypt-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-3des-encrypt-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970721135330.I-D@ietf.org> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 22 10:10:29 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.6/8.8.5) with SMTP id KAA12418; Tue, 22 Jul 1997 10:10:26 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 22 Jul 1997 10:08:37 -0400 Received: (from majordom@localhost) by merit.edu (8.8.6/8.8.5) id KAA12274 for ietf-ppp-outgoing; Tue, 22 Jul 1997 10:08:36 -0400 (EDT) Received: from tor.securecomputing.com (tor.securecomputing.com [199.71.190.98]) by merit.edu (8.8.6/8.8.5) with ESMTP id KAA12266 for ; Tue, 22 Jul 1997 10:08:30 -0400 (EDT) Received: by janus.tor.securecomputing.com id <11653>; Tue, 22 Jul 1997 10:03:25 -0400 Message-Id: <97Jul22.100325edt.11653@janus.tor.securecomputing.com> To: ietf-ppp@merit.edu Subject: Re: draft-ietf-pppext-3des-encrypt-00.txt From: "C. Harald Koch" Date: Tue, 22 Jul 1997 10:08:17 -0400 Sender: owner-ietf-ppp@merit.edu It's kinda funny that both this and draft-ietf-ipsec-ciph-3des-expiv-00.txt showed up in my daily mirror at the same time. In the "avoid duplication of effort" department, I'd like to recommend replacing Section "1.2 Keys" with the corresponding section from the IPsec 3DES transform definition cited above. It would be nice to be able to use the same code everywhere. Specifically: 3. Key Sizes The secret DES-EDE3 key shared between the communicating parties is effectively 168-bits long. This key consists of three independent 56-bit quantities used by the DES algorithm. Each of the three 56- bit sub-keys is stored as a 64-bit (8 byte) quantity, with the least significant bit of each byte used as a parity bit. Implementations of this transform SHOULD take into consideration the parity bits when initially accepting a new set of keys. 3.1 Weak Keys DES has 64 known weak keys, including so-called semi-weak keys and possibly-weak keys [Schneier95, pp 280-282]. The likelihood of picking one at random is negligible. For DES-EDE3, there is no known need to reject weak or complementation keys. Any weakness is obviated by the other keys. However, if the first two independent 64-bit keys are equal (k1 == k2), then the 3DES operation is simply the same as DES. Implementers MUST reject keys that exhibit this property. -- Harald Koch - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 22 14:05:30 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.6/8.8.5) with SMTP id OAA18275; Tue, 22 Jul 1997 14:05:11 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 22 Jul 1997 14:02:12 -0400 Received: (from majordom@localhost) by merit.edu (8.8.6/8.8.5) id OAA18171 for ietf-ppp-outgoing; Tue, 22 Jul 1997 14:02:11 -0400 (EDT) Received: from directors.rdl.co.uk (directors.rdl.co.uk [193.119.77.2]) by merit.edu (8.8.6/8.8.5) with ESMTP id OAA18164 for ; Tue, 22 Jul 1997 14:02:04 -0400 (EDT) Received: from imaccgw.rdl.co.uk (imaccgw.rdl.co.uk [193.240.106.205]) by directors.rdl.co.uk (8.7.3/8.7.3) with SMTP id TAA28362 for ; Tue, 22 Jul 1997 19:02:02 +0100 (BST) Received: from ccMail by imaccgw.rdl.co.uk (IMA Internet Exchange 1.04b) id 3d4f50e0; Tue, 22 Jul 97 18:59:42 +0100 Mime-Version: 1.0 Date: Tue, 22 Jul 1997 13:44:43 +0100 Message-ID: <3d4f50e0@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re: MS TCP/IP/PPP considered harmful --- NOT! To: ietf-ppp@merit.edu Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: owner-ietf-ppp@merit.edu Gurdeep Singh Pall writes: > From: William Allen Simpson >> From: Jonathan Goodchild >> > If you connect via RS-232 (i.e. via the COM port in PC terms), >> > then the Windows RAS software expects the user to be on the other >> > end of the link. It applies the authentication applies to 2 >> >levels: >> > >> > 1) normal PPP link access >> > 2) login to the file server >> > >> > If you have a router connected via the COM port, then you'll log >> > the router into the server, rather than the real user. >> > >> This certainly sounds like a terrible security hole to me! > >Gurdeep> What Jonath*a*n conjectures is untrue. Logging on to file >servers is application layer function which gets triggered on the >machine that dials in - after a PPP connection is made. Ok, my apologies: clearly I got it wrong. However, I never meant to imply that there were any security weaknesses in the Windows server. So maybe Vernon is right - perhaps the TA could be a router and connect via the COM port. >This is done so that the user experiences a "seamless" logon to the >remote network. I don't think that "seamless" is the right word here - maybe the user only has to enter one password for two separate functions, but it seems to me that this "seamless" logon is the root cause of a number of the problems from which Microsoft's PPP has suffered, such as the inability to respond to ongoing CHAP (and MS-CHAP) challenges. I wouldn't go as far as actually considering MS TCP/IP/PPP harmful, merely limited. --- Jonathan Goodchild - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 22 14:40:01 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.6/8.8.5) with SMTP id OAA19174; Tue, 22 Jul 1997 14:40:00 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 22 Jul 1997 14:38:25 -0400 Received: (from majordom@localhost) by merit.edu (8.8.6/8.8.5) id OAA19117 for ietf-ppp-outgoing; Tue, 22 Jul 1997 14:38:24 -0400 (EDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.41]) by merit.edu (8.8.6/8.8.5) with ESMTP id OAA19113 for ; Tue, 22 Jul 1997 14:38:18 -0400 (EDT) Received: by INET-01-IMC with Internet Mail Service (5.0.1458.49) id ; Tue, 22 Jul 1997 11:37:46 -0700 Message-ID: From: Andrew Nicholson To: ietf-ppp@merit.edu Subject: RE: MS TCP/IP/PPP considered harmful --- NOT! Date: Tue, 22 Jul 1997 11:37:43 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Sender: owner-ietf-ppp@merit.edu Yeah, I'd say you folks might as well gather up all complaints you have about ppp in windows 95. This increases the likelihood someone will review them and make further improvements in the product. But I think you know as well as I do that it is one of the best implementations around - very easy to use and the most used ppp implementation anywhere. Just because various things were not implemented for various reasons (like chap rechallenges) does not detract from the high level of success it has brought to the market or it's stabilizing influence on the dial up service market. Oh, and by the way, if you can't tell the difference between a network login and the authentication protocol negotiation for validating access to dial up services then maybe you better not bother. Or maybe you are referring to Microsoft Networking in general, or perhaps the Dial Up Networking app, instead of the ppp implementation underneath. I never did see any of you folks at any of the bakeoffs, so maybe ppp is not your specialty. Cheers! Andy Nicholson > > I don't think that "seamless" is the right word here - maybe the user > only has to enter one password for two separate functions, but it > seems > to me that this "seamless" logon is the root cause of a number of the > > problems from which Microsoft's PPP has suffered, such as the > inability > to respond to ongoing CHAP (and MS-CHAP) challenges. > > I wouldn't go as far as actually considering MS TCP/IP/PPP harmful, > merely limited. > > --- > Jonathan Goodchild > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 22 17:57:13 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.6/8.8.5) with SMTP id RAA25595; Tue, 22 Jul 1997 17:56:51 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 22 Jul 1997 17:52:42 -0400 Received: (from majordom@localhost) by merit.edu (8.8.6/8.8.5) id RAA25394 for ietf-ppp-outgoing; Tue, 22 Jul 1997 17:52:39 -0400 (EDT) Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.8.6/8.8.5) with SMTP id RAA25383 for ; Tue, 22 Jul 1997 17:52:20 -0400 (EDT) Received: from mica.denver.sgi.com (mica.denver.sgi.com [169.238.67.6]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id OAA25054 for <@sgi.engr.sgi.com:ietf-ppp@merit.edu>; Tue, 22 Jul 1997 14:52:12 -0700 env-from (vjs@mica.denver.sgi.com) Received: (from vjs@localhost) by mica.denver.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA22203 for ietf-ppp@merit.edu; Tue, 22 Jul 1997 15:51:57 -0600 Date: Tue, 22 Jul 1997 15:51:57 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199707222151.PAA22203@mica.denver.sgi.com> To: ietf-ppp@merit.edu Subject: RE: MS TCP/IP/PPP considered harmful Sender: owner-ietf-ppp@merit.edu > From: Andrew Nicholson > Yeah, I'd say you folks might as well gather up all complaints you have > about ppp in windows 95. This increases the likelihood someone will > review them and make further improvements in the product. > > But I think you know as well as I do that it is one of the best > implementations > around - very easy to use and the most used ppp implementation anywhere. > Just because various things were not implemented for various reasons > (like chap rechallenges) does not detract from the high level of success > it > has brought to the market or it's stabilizing influence on the dial up > service market. > > Oh, and by the way, if you can't tell the difference between a network > login > and the authentication protocol negotiation for validating access to > dial up > services then maybe you better not bother. Or maybe you are referring > to > Microsoft Networking in general, or perhaps the Dial Up Networking app, > instead of the ppp implementation underneath. I never did see any of > you > folks at any of the bakeoffs, so maybe ppp is not your specialty. Admit ignoring the basic RFCs like CHAP reauthentication "for various reasons"? And then claim to have a strong implementation? Sheesh! I do not think an RFC listing any particular vendor's bugs is a good idea. However, that screed is a classic example of a major software development problem typical of (but not exclusive to) large outfits. I guess it could be called hubris. We all have bugs, but those who claim to have the fewest tend in fact to have the most. Good programmers are invariably neurotic about their code. You might be able to convince the rubes and some readers of the "MS Developers Forum" that the Microsoft PPP code is the best, but some of us around here know the difference between a Nak and an Ack. Microsoft's PPP implementations are among the weakest major players, judging from my personal experience in bakeoffs and real life. I can't think of another major implementation that has as many bugs and misfeatures as the Microsoft code. Its 'stablizing influence' has been as effective as that of a dead whale. Those trapped underneath or dining on the corpse conform, and everyone else tries to get up wind. It is as reasonable for Microsoft to claim to be responsible for the success of PPP as for the success of TCP/IP. (I think I've also seen some of the latter claims from Microsoft.) Instead of claiming that doubtful characteristics are features, such as the - mess with Configure-Reject vs. Nak for authentication. - inability to do symmetric authentication. - inability to do CHAP, the claims that the less secure MS-CHAP is more secure, and the general failure to understand the nature of cleartext. - the various "extensions" such as those for broadcast address and DNS service. why not do as the rest of us do? The good implementors look critically at their own code, check their (mis)understandings of the protocols and reality with others, and watch what each other are building. Oh, and by the way, if you cannot tell that Microsoft advises the use of the same underlying secret for network authentication and user authentication, despite the security implications, effectively confounding, confusing, and equating the two, perhaps you should review your colleagues's statements in the WG archives. And finally, you might consider the possibility that while the bake-offs are good things, they are just as irrelevent as the "MS Developer's Forum" and the comp.protocols.ppp netnews group for defining the protocol. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 22 18:48:29 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.6/8.8.5) with SMTP id SAA27156; Tue, 22 Jul 1997 18:48:25 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 22 Jul 1997 18:46:55 -0400 Received: (from majordom@localhost) by merit.edu (8.8.6/8.8.5) id SAA27106 for ietf-ppp-outgoing; Tue, 22 Jul 1997 18:46:54 -0400 (EDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.29]) by merit.edu (8.8.6/8.8.5) with ESMTP id SAA27102 for ; Tue, 22 Jul 1997 18:46:49 -0400 (EDT) Received: by mail4.microsoft.com with Internet Mail Service (5.0.1458.49) id ; Tue, 22 Jul 1997 15:47:45 -0700 Message-ID: From: Gurdeep Singh Pall To: "'Jonathan.Goodchild@rdl.co.uk'" , ietf-ppp@merit.edu Subject: RE: MS TCP/IP/PPP considered harmful --- NOT! Date: Tue, 22 Jul 1997 15:46:47 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Sender: owner-ietf-ppp@merit.edu > -----Original Message----- > From: Jonathan.Goodchild@rdl.co.uk [SMTP:Jonathan.Goodchild@rdl.co.uk] > > I don't think that "seamless" is the right word here - maybe the user > only has to enter one password for two separate functions, but it > seems > to me that this "seamless" logon is the root cause of a number of the > > problems from which Microsoft's PPP has suffered, such as the > inability > to respond to ongoing CHAP (and MS-CHAP) challenges. > Gurdeep> The first release of PPP on Win95 had this bug - - this is now fixed. NT worked fine all along. It had nothing to do with the fact that the logon is "seamless". - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 22 20:08:19 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.6/8.8.5) with SMTP id UAA28806; Tue, 22 Jul 1997 20:08:17 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 22 Jul 1997 20:06:04 -0400 Received: (from majordom@localhost) by merit.edu (8.8.6/8.8.5) id UAA28768 for ietf-ppp-outgoing; Tue, 22 Jul 1997 20:06:03 -0400 (EDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.41]) by merit.edu (8.8.6/8.8.5) with ESMTP id UAA28764 for ; Tue, 22 Jul 1997 20:05:59 -0400 (EDT) Received: by INET-01-IMC with Internet Mail Service (5.0.1458.49) id ; Tue, 22 Jul 1997 17:05:59 -0700 Message-ID: From: Gurdeep Singh Pall To: ietf-ppp@merit.edu Subject: RE: MS TCP/IP/PPP considered harmful --- NOT! Date: Tue, 22 Jul 1997 17:05:57 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Sender: owner-ietf-ppp@merit.edu We believe an average user gets confused when multiple secrets are involved. I also believe that Vernon gets confused when only one secret is involved. ;-) Multiple secrets can be used on Win95 and NT if users so desire. Instead of wasting everyone's time perhaps Vernon should go figure this out himself. Gurdeep > -----Original Message----- > From: vjs@mica.denver.sgi.com [SMTP:vjs@mica.denver.sgi.com] > > Oh, and by the way, if you cannot tell that Microsoft advises the use > of the same underlying secret for network authentication and user > authentication, despite the security implications, effectively > confounding, confusing, and equating the two, perhaps you should > review > your colleagues's statements in the WG archives. > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jul 23 12:58:17 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.6/8.8.5) with SMTP id MAA14734; Wed, 23 Jul 1997 12:56:58 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 23 Jul 1997 12:46:32 -0400 Received: (from majordom@localhost) by merit.edu (8.8.6/8.8.5) id MAA14571 for ietf-ppp-outgoing; Wed, 23 Jul 1997 12:46:32 -0400 (EDT) Received: from relay.conware.de (services@[153.92.5.3] (may be forged)) by merit.edu (8.8.6/8.8.5) with SMTP id MAA14564 for ; Wed, 23 Jul 1997 12:46:23 -0400 (EDT) Received: from gin.conware.de [153.92.64.18] by relay.conware.de with smtp (Exim 1.624 #1) id 0wr4XX-0007n4-00; Wed, 23 Jul 1997 18:45:27 +0200 Subject: Re: draft-ietf-pppext-3des-encrypt-00.txt To: chk@tor.securecomputing.com (C. Harald Koch) Date: Wed, 23 Jul 1997 18:51:37 +0200 (MET DST) From: "Holger Kummert" Cc: ietf-ppp@merit.edu (ietf-ppp) In-Reply-To: <97Jul22.100325edt.11653@janus.tor.securecomputing.com> from "C. Harald Koch" at Jul 22, 97 10:08:17 am Reply-To: Holger Kummert X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Message-ID: <33d6369a0.65b8@gin.conware.de> Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu C. Harald Koch writes: > > It's kinda funny that both this and draft-ietf-ipsec-ciph-3des-expiv-00.txt > showed up in my daily mirror at the same time. > > In the "avoid duplication of effort" department, I'd like to recommend > replacing Section "1.2 Keys" with the corresponding section from the IPsec > 3DES transform definition cited above. It would be nice to be able to use the > same code everywhere. Specifically: [...] The text looks ok. If there are no objections, I will include those sections 3. and 3.1 of the cited draft in the next revision of the draft. -- Holger Kummert Phone: +49 721 9495-0 Nentec GmbH http://www.nentec.de/ - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jul 23 17:22:25 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.6/8.8.5) with SMTP id RAA20478; Wed, 23 Jul 1997 17:22:16 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 23 Jul 1997 17:21:27 -0400 Received: (from majordom@localhost) by merit.edu (8.8.6/8.8.5) id RAA20443 for ietf-ppp-outgoing; Wed, 23 Jul 1997 17:21:27 -0400 (EDT) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by merit.edu (8.8.6/8.8.5) with SMTP id RAA20439 for ; Wed, 23 Jul 1997 17:21:23 -0400 (EDT) Received: from spud.ascend.com (fw-ext.ascend.com [198.4.92.5]) by drawbridge.ascend.com (8.6.12/8.6.12) with ESMTP id OAA24275 for ; Wed, 23 Jul 1997 14:21:21 -0700 Received: from ascend.com by ascend.com with ESMTP id OAA04258 for ; Wed, 23 Jul 1997 14:21:20 -0700 Received: from gump.eng.ascend.com (gump.eng.ascend.com [206.65.212.67]) by wopr.eng.ascend.com (8.6.12/8.6.12) with ESMTP id OAA15454 for ; Wed, 23 Jul 1997 14:20:49 -0700 Received: from carp.morningstar.com.ascend.com (karl@carp.MorningStar.Com [137.175.81.4]) by gump.eng.ascend.com (8.6.12/8.6.12) with SMTP id OAA14883 for ; Wed, 23 Jul 1997 14:20:48 -0700 Date: Wed, 23 Jul 1997 14:20:48 -0700 Message-Id: <199707232120.OAA14883@gump.eng.ascend.com> From: Karl Fox To: ietf-ppp@merit.edu Subject: Agenda items for August IETF in Munich, Germany Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ietf-ppp@merit.edu Please send me requests for agenda items for the August meeting in Munich, Germany. We have two meeting slots: Monday, August 11 at 1930-2200 (opposite calsch, snmpv3, udlr, tcpimp) Tuesday, August 12 at 1415-1515 (opposite nntpext) Please include the name of the presenter (if not yourself), the subject to be discussed, and any relevant RFCs or Internet Drafts. Also say which day you'd prefer, and I'll see if I can accomodate you. -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jul 23 17:27:43 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.6/8.8.5) with SMTP id RAA20576; Wed, 23 Jul 1997 17:27:42 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 23 Jul 1997 17:27:25 -0400 Received: (from majordom@localhost) by merit.edu (8.8.6/8.8.5) id RAA20555 for ietf-ppp-outgoing; Wed, 23 Jul 1997 17:27:24 -0400 (EDT) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by merit.edu (8.8.6/8.8.5) with SMTP id RAA20548 for ; Wed, 23 Jul 1997 17:27:17 -0400 (EDT) Received: from spud.ascend.com (fw-ext.ascend.com [198.4.92.5]) by drawbridge.ascend.com (8.6.12/8.6.12) with ESMTP id OAA24620; Wed, 23 Jul 1997 14:27:08 -0700 Received: from ascend.com by ascend.com with ESMTP id OAA04534; Wed, 23 Jul 1997 14:27:07 -0700 Received: from gump.eng.ascend.com (gump.eng.ascend.com [206.65.212.67]) by wopr.eng.ascend.com (8.6.12/8.6.12) with ESMTP id OAA15793; Wed, 23 Jul 1997 14:26:36 -0700 Received: from carp.morningstar.com.ascend.com (karl@carp.MorningStar.Com [137.175.81.4]) by gump.eng.ascend.com (8.6.12/8.6.12) with SMTP id OAA14980; Wed, 23 Jul 1997 14:26:33 -0700 Date: Wed, 23 Jul 1997 14:26:33 -0700 Message-Id: <199707232126.OAA14980@gump.eng.ascend.com> From: Karl Fox To: inads@research.ftp.com Cc: Steve Coya , ietf-ppp@merit.edu Subject: Mobile-IPv4 Configuration Option for PPP IPCP to Proposed Standard Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ietf-ppp@merit.edu Jeff and Tom, The PPPEXT Working Group recommends that the current Mobile-IPv4 Configuration Option for PPP IPCP Internet Draft, draft-ietf-pppext-ipcp-mip-02.txt, be advanced to Proposed Standard. -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jul 23 17:35:40 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.6/8.8.5) with SMTP id RAA20717; Wed, 23 Jul 1997 17:35:38 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 23 Jul 1997 17:35:21 -0400 Received: (from majordom@localhost) by merit.edu (8.8.6/8.8.5) id RAA20696 for ietf-ppp-outgoing; Wed, 23 Jul 1997 17:35:20 -0400 (EDT) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by merit.edu (8.8.6/8.8.5) with SMTP id RAA20691 for ; Wed, 23 Jul 1997 17:35:16 -0400 (EDT) Received: from spud.ascend.com (fw-ext.ascend.com [198.4.92.5]) by drawbridge.ascend.com (8.6.12/8.6.12) with ESMTP id OAA25079; Wed, 23 Jul 1997 14:35:08 -0700 Received: from ascend.com by ascend.com with ESMTP id OAA05093; Wed, 23 Jul 1997 14:35:08 -0700 Received: from gump.eng.ascend.com (gump.eng.ascend.com [206.65.212.67]) by wopr.eng.ascend.com (8.6.12/8.6.12) with ESMTP id OAA16288; Wed, 23 Jul 1997 14:34:37 -0700 Received: from carp.morningstar.com.ascend.com (karl@carp.MorningStar.Com [137.175.81.4]) by gump.eng.ascend.com (8.6.12/8.6.12) with SMTP id OAA15063; Wed, 23 Jul 1997 14:34:33 -0700 Date: Wed, 23 Jul 1997 14:34:33 -0700 Message-Id: <199707232134.OAA15063@gump.eng.ascend.com> From: Karl Fox To: Jeff Burgan , Thomas Narten , inads@research.ftp.com Cc: Steve Coya , ietf-ppp@merit.edu Subject: Mobile-IPv4 Configuration Option for PPP IPCP to Proposed Standard Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ietf-ppp@merit.edu [Second try, this one explicitly addressing our AD's. Mail to inads@research.ftp.com bounced, with research.ftp.com saying "user unknown" for inads@research.ftp.com] Jeff and Tom, The PPPEXT Working Group recommends that the current Mobile-IPv4 Configuration Option for PPP IPCP Internet Draft, draft-ietf-pppext-ipcp-mip-02.txt, be advanced to Proposed Standard. -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Jul 25 10:22:35 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.6/8.8.5) with SMTP id KAA25598; Fri, 25 Jul 1997 10:20:29 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 25 Jul 1997 10:14:25 -0400 Received: (from majordom@localhost) by merit.edu (8.8.6/8.8.5) id KAA25379 for ietf-ppp-outgoing; Fri, 25 Jul 1997 10:14:24 -0400 (EDT) Received: from ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.6/8.8.5) with SMTP id KAA25372 for ; Fri, 25 Jul 1997 10:14:20 -0400 (EDT) Received: from ietf.ietf.org by ietf.org id aa08644; 25 Jul 97 9:43 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-pptp-02.txt Date: Fri, 25 Jul 1997 09:43:08 -0400 Message-ID: <9707250943.aa08644@ietf.org> Sender: owner-ietf-ppp@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 : Point-to-Point Tunneling Protocol--PPTP Author(s) : K. Hamzeh, G. Pall, W. Verthein, J. Taarud, W. Little Filename : draft-ietf-pppext-pptp-02.txt Pages : 62 Date : 07/24/1997 This document specifies a protocol which allows the Point to Point Protocol (PPP) to be tunneled through an IP network. PPTP does not specify any changes to the PPP protocol but rather describes a new vehicle for carrying PPP. A client-server architecture is defined in order to decouple functions which exist in current Network Access Servers (NAS) and support Virtual Private Networks (VPNs). The PPTP Network Server (PNS) is envisioned to run on a general purpose operating system while the client, referred to as a PPTP Access Concentrator (PAC) operates on a dial access platform. PPTP specifies a call-control and management protocol which allows the server to control access for dial-in circuit switched calls originating from a PSTN or ISDN or to initiate outbound circuit-switched connections. PPTP uses a GRE-like (Generic Routing Encapsulation) mechanism to provide a flow- and congestion-controlled encapsulated datagram service for carrying PPP packets. 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-pptp-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-pptp-02.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-pptp-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970724173458.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-pptp-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-pptp-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970724173458.I-D@ietf.org> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Sun Jul 27 03:08:00 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.6/8.8.5) with SMTP id DAA18896; Sun, 27 Jul 1997 03:06:27 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Sun, 27 Jul 1997 03:02:42 -0400 Received: (from majordom@localhost) by merit.edu (8.8.6/8.8.5) id DAA18862 for ietf-ppp-outgoing; Sun, 27 Jul 1997 03:02:42 -0400 (EDT) Received: from rnd-gate.rad.co.il (rnd-gate.rad.co.il [207.232.32.14]) by merit.edu (8.8.6/8.8.5) with ESMTP id DAA18858 for ; Sun, 27 Jul 1997 03:02:34 -0400 (EDT) Received: from smtp-gateway.rad.co.il ([176.189.111.1]) by rnd-gate.rad.co.il (8.7.3/8.7.3) with SMTP id JAA28784 for ; Sun, 27 Jul 1997 09:50:55 +0300 (IDT) Received: by smtp-gateway.rad.co.il with Microsoft Mail id <33DB0266@smtp-gateway.rad.co.il>; Sun, 27 Jul 97 10:10:14 EST From: Michael Liwerant To: "'ietf_ppp'" Subject: Loss of Stac LZS synchronization Date: Sun, 27 Jul 97 10:01:00 EST Message-ID: <33DB0266@smtp-gateway.rad.co.il> X-Mailer: Microsoft Mail V3.0 Sender: owner-ietf-ppp@merit.edu Need clarification for the operation that should be performed at the receiver's when Stac-LZS synchronization is lost, a reset-request transmissions are performed (according to the predefined number of retries) and reset-ack is NOT received. I didn't find specification of operation that should be performed (at the receiver's side) in RFC-1974. Thank you for helping - Michael. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Sun Jul 27 03:23:16 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.6/8.8.5) with SMTP id DAA19017; Sun, 27 Jul 1997 03:23:14 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Sun, 27 Jul 1997 03:22:57 -0400 Received: (from majordom@localhost) by merit.edu (8.8.6/8.8.5) id DAA18996 for ietf-ppp-outgoing; Sun, 27 Jul 1997 03:22:57 -0400 (EDT) Received: from ns.frigate.com (ns.frigate.com [206.14.208.6]) by merit.edu (8.8.6/8.8.5) with ESMTP id DAA18989 for ; Sun, 27 Jul 1997 03:22:53 -0400 (EDT) Received: from localhost (mthorn@localhost) by ns.frigate.com (8.8.5/8.7.1) with SMTP id AAA22669; Sun, 27 Jul 1997 00:22:41 -0700 (PDT) Date: Sun, 27 Jul 1997 00:22:41 -0700 (PDT) From: Mike Thornburg To: Michael Liwerant cc: "'ietf_ppp'" Subject: Re: Loss of Stac LZS synchronization In-Reply-To: <33DB0266@smtp-gateway.rad.co.il> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu On Sun, 27 Jul 1997, Michael Liwerant wrote: > Need clarification for the operation that should be performed at the > receiver's when Stac-LZS synchronization is lost, a reset-request > transmissions are performed (according to the predefined number of > retries) and reset-ack is NOT received. > I didn't find specification of operation that should be performed (at the > receiver's side) in RFC-1974. > > Thank you for helping - Michael. > In this case, I don't think you have much choice but to try to shut down CCP using a CCP Terminate-Request. Either the other side's CCP Stac-LZS implementation is too broken to interoperate with or the line is extremely lossy. Thanks, Mike -------------- Mike Thornburg frigate networks 415.903.2266 mthorn@frigate.com http://www.frigate.com/ - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Sun Jul 27 18:53:09 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.6/8.8.5) with SMTP id SAA24272; Sun, 27 Jul 1997 18:52:38 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Sun, 27 Jul 1997 18:48:15 -0400 Received: (from majordom@localhost) by merit.edu (8.8.6/8.8.5) id SAA24227 for ietf-ppp-outgoing; Sun, 27 Jul 1997 18:48:15 -0400 (EDT) Received: from SantaClara01.pop.internex.net (santaclara01.pop.InterNex.Net [205.158.3.18]) by merit.edu (8.8.6/8.8.5) with ESMTP id SAA24223 for ; Sun, 27 Jul 1997 18:48:11 -0400 (EDT) Received: from flowpnt.flowpoint.com ([192.84.210.69]) by SantaClara01.pop.internex.net (post.office MTA v1.9.3 ID# 0-11030) with SMTP id AAA11948; Sun, 27 Jul 1997 15:48:08 -0700 Received: from zeus.flowpoint.com (ws67.flowpoint.com) by flowpnt.flowpoint.com (4.1/SMI-4.1) id AA27440; Sun, 27 Jul 97 15:32:48 PDT Received: by zeus.flowpoint.com (4.1/SMI-4.1) id AA13176; Sun, 27 Jul 97 15:32:48 PDT Date: Sun, 27 Jul 1997 15:32:47 -0700 (PDT) From: Philip Rakity X-Sender: pmr@zeus To: Michael Liwerant Cc: "'ietf_ppp'" Subject: Re: Loss of Stac LZS synchronization In-Reply-To: <33DB0266@smtp-gateway.rad.co.il> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Mike, What mode of operation are you using? There are no reset aks in type 4. If someone detects a loss of end marker, it is required to reset the history buffers in the stac code; it will NOT recover. Bob Friend at STAC is aware of the problem, and I submitted words to him and the mailing list to clarify the RFC. regards, Philip Rakity FlowPoint On Sun, 27 Jul 1997, Michael Liwerant wrote: > > Need clarification for the operation that should be performed at the > receiver's when Stac-LZS synchronization is lost, a reset-request > transmissions are performed (according to the predefined number of > retries) and reset-ack is NOT received. > I didn't find specification of operation that should be performed (at the > receiver's side) in RFC-1974. > > Thank you for helping - Michael. > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Jul 28 02:08:11 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.6/8.8.5) with SMTP id CAA27348; Mon, 28 Jul 1997 02:07:58 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 28 Jul 1997 02:07:24 -0400 Received: (from majordom@localhost) by merit.edu (8.8.6/8.8.5) id CAA27330 for ietf-ppp-outgoing; Mon, 28 Jul 1997 02:07:23 -0400 (EDT) Received: from rnd-gate.rad.co.il (rnd-gate.rad.co.il [207.232.32.14]) by merit.edu (8.8.6/8.8.5) with ESMTP id CAA27326 for ; Mon, 28 Jul 1997 02:07:16 -0400 (EDT) Received: from smtp-gateway.rad.co.il ([176.189.111.1]) by rnd-gate.rad.co.il (8.7.3/8.7.3) with SMTP id IAA12029 for ; Mon, 28 Jul 1997 08:55:38 +0300 (IDT) Received: by smtp-gateway.rad.co.il with Microsoft Mail id <33DC4700@smtp-gateway.rad.co.il>; Mon, 28 Jul 97 09:15:12 EST From: Michael Liwerant To: "'ietf_ppp'" Subject: Stac-LZS on noisy channel Date: Mon, 28 Jul 97 09:05:00 EST Message-ID: <33DC4700@smtp-gateway.rad.co.il> X-Mailer: Microsoft Mail V3.0 Sender: owner-ietf-ppp@merit.edu Hi guys Need some advise regarding the feasibility of performing a fallback (from using a session history buffer) to using NO history when too many synchronization losses are detected during RECEPTION of compressed packets. This fallback is involved in retransmission of config-request with History-Count=0, followed by reset of the history buffer when config-ack is received. Thank you for responding - Michael Liwerant. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Jul 28 13:07:41 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.6/8.8.5) with SMTP id NAA04327; Mon, 28 Jul 1997 13:07:10 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 28 Jul 1997 12:56:17 -0400 Received: (from majordom@localhost) by merit.edu (8.8.6/8.8.5) id MAA04106 for ietf-ppp-outgoing; Mon, 28 Jul 1997 12:56:17 -0400 (EDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm002-24.dialip.mich.net [141.211.7.160]) by merit.edu (8.8.6/8.8.5) with SMTP id MAA04100 for ; Mon, 28 Jul 1997 12:56:12 -0400 (EDT) Date: Mon, 28 Jul 97 16:41:41 GMT From: "William Allen Simpson" Message-ID: <6349.wsimpson@greendragon.com> To: ietf-ppp@merit.edu Subject: Re: draft-ietf-pppext-3des-encrypt-00.txt Sender: owner-ietf-ppp@merit.edu > From: "Holger Kummert" > C. Harald Koch writes: > > In the "avoid duplication of effort" department, I'd like to recommend > > replacing Section "1.2 Keys" with the corresponding section from the IPsec > > 3DES transform definition cited above. It would be nice to be able to use the > > same code everywhere. Specifically: > [...] > > The text looks ok. If there are no objections, I will include those > sections 3. and 3.1 of the cited draft in the next revision of the draft. > Actually, the authors of that "expiv" draft copied text from an old copy of an earlier draft of mine. There were later requests to reject the weak keys, even though we aren't sure that is cryptographically needed, because it is easy to do and safer against possible unknown attacks. My more recent draft 3DES reflects this consensus. To "avoid duplication of effort", please retain the check for weak keys. Your code base probably already has the check. I will also note that PPP uses a derived IV (from the previous packet) rather than an explicit IV (in every packet), and is thus closer to the RFC-1829 & 1851 design than the "expiv" effort. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 29 02:08:05 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.6/8.8.5) with SMTP id CAA16313; Tue, 29 Jul 1997 02:07:50 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 29 Jul 1997 02:07:13 -0400 Received: (from majordom@localhost) by merit.edu (8.8.6/8.8.5) id CAA16286 for ietf-ppp-outgoing; Tue, 29 Jul 1997 02:07:12 -0400 (EDT) Received: from fsnt.future.futsoft.com ([38.242.192.5] (may be forged)) by merit.edu (8.8.6/8.8.5) with ESMTP id CAA16282 for ; Tue, 29 Jul 1997 02:07:04 -0400 (EDT) Received: from kailash.future.futsoft.com (unverified [38.242.192.4]) by fsnt.future.futsoft.com (Integralis SMTPRS 2.04) with ESMTP id ; Tue, 29 Jul 1997 11:44:47 +0530 Received: from msgate.future.futsoft.com (msgate.future.futsoft.com [10.0.8.4]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id LAA28956 for ; Tue, 29 Jul 1997 11:18:37 +0530 Received: by msgate.future.futsoft.com with Microsoft Mail id <33DE3693@msgate.future.futsoft.com>; Tue, 29 Jul 97 11:29:39 PDT From: srinic To: "'ietf-ppp'" Subject: RE: Loss of Stac LZS synchronization Date: Tue, 29 Jul 97 11:27:00 PDT Message-Id: <33DE3693@msgate.future.futsoft.com> X-Mailer: Microsoft Mail V3.0 Sender: owner-ietf-ppp@merit.edu What Mike is pointing out is correct. But, to be more finer, we can adopt the following procedure. After sending the reset request, if data packets are received insteadof reset ack, CCP is going to send the Reset request for every received data packet. If no data/reset ack packets are received, we can have one idle timer and it will timeout after finite time which will result in shutting down CCP and the link itself. Hope this meets your requirement. -Srinivasan (srinic@future.futsoft.com) ---------- From: owner-ietf-ppp To: Michael Liwerant Cc: 'ietf_ppp' Subject: Re: Loss of Stac LZS synchronization Date: Sunday, 27 July, 1997 12:22AM On Sun, 27 Jul 1997, Michael Liwerant wrote: > Need clarification for the operation that should be performed at the > receiver's when Stac-LZS synchronization is lost, a reset-request > transmissions are performed (according to the predefined number of > retries) and reset-ack is NOT received. > I didn't find specification of operation that should be performed (at the > receiver's side) in RFC-1974. > > Thank you for helping - Michael. > In this case, I don't think you have much choice but to try to shut down CCP using a CCP Terminate-Request. Either the other side's CCP Stac-LZS implementation is too broken to interoperate with or the line is extremely lossy. Thanks, Mike -------------- Mike Thornburg frigate networks 415.903.2266 mthorn@frigate.com http://www.frigate.com/ - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 29 10:07:47 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.6/8.8.5) with SMTP id KAA20557; Tue, 29 Jul 1997 10:05:42 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 29 Jul 1997 10:01:51 -0400 Received: (from majordom@localhost) by merit.edu (8.8.6/8.8.5) id KAA20443 for ietf-ppp-outgoing; Tue, 29 Jul 1997 10:01:50 -0400 (EDT) Received: from ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.6/8.8.5) with SMTP id KAA20439 for ; Tue, 29 Jul 1997 10:01:47 -0400 (EDT) Received: from ietf.ietf.org by ietf.org id aa07198; 29 Jul 97 9:39 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-lcpext-ds-02.txt Date: Tue, 29 Jul 1997 09:39:13 -0400 Message-ID: <9707290939.aa07198@ietf.org> Sender: owner-ietf-ppp@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 : PPP LCP Extensions Author(s) : W. Simpson Filename : draft-ietf-pppext-lcpext-ds-02.txt Pages : 6 Date : 07/28/1997 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 (LCP) for establishing, configuring, and testing the data-link connection. This document defines additional LCP features that have been suggested over the past few years. 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-lcpext-ds-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-lcpext-ds-02.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-lcpext-ds-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970728171943.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-lcpext-ds-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-lcpext-ds-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970728171943.I-D@ietf.org> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 29 10:07:46 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.6/8.8.5) with SMTP id KAA20561; Tue, 29 Jul 1997 10:05:43 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 29 Jul 1997 10:01:38 -0400 Received: (from majordom@localhost) by merit.edu (8.8.6/8.8.5) id KAA20431 for ietf-ppp-outgoing; Tue, 29 Jul 1997 10:01:37 -0400 (EDT) Received: from ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.6/8.8.5) with SMTP id KAA20423 for ; Tue, 29 Jul 1997 10:01:33 -0400 (EDT) Received: from ietf.ietf.org by ietf.org id aa06926; 29 Jul 97 9:38 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-funi-01.txt Date: Tue, 29 Jul 1997 09:38:11 -0400 Message-ID: <9707290938.aa06926@ietf.org> Sender: owner-ietf-ppp@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 : PPP Over FUNI Author(s) : M. Kaycee, G. Gross, A. Lin, A. Malis, J. Stephens Filename : draft-ietf-pppext-funi-01.txt Pages : 9 Date : 07/28/1997 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document describes the use of ATM Frame User Network Interface (FUNI) for framing PPP encapsulated packets. Internet-Drafts are available by anonymous FTP. Login 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-funi-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-funi-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-funi-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970729092205.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-funi-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-funi-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970729092205.I-D@ietf.org> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 29 10:33:12 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.6/8.8.5) with SMTP id KAA21143; Tue, 29 Jul 1997 10:31:51 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 29 Jul 1997 10:31:42 -0400 Received: (from majordom@localhost) by merit.edu (8.8.6/8.8.5) id KAA21117 for ietf-ppp-outgoing; Tue, 29 Jul 1997 10:31:42 -0400 (EDT) Received: from shultz.gigapacket.com (shultz.gigapacket.com [38.161.132.2]) by merit.edu (8.8.6/8.8.5) with ESMTP id KAA21113 for ; Tue, 29 Jul 1997 10:31:38 -0400 (EDT) Received: from hochstetter (hochstetter.gigapacket.com [38.161.132.53]) by shultz.gigapacket.com (8.8.6/8.8.6) with SMTP id KAA23761 for ; Tue, 29 Jul 1997 10:31:06 -0400 (EDT) Message-Id: <3.0.1.32.19970729103335.00929220@shultz.gigapacket.com> X-Sender: kasten@shultz.gigapacket.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 29 Jul 1997 10:33:35 -0400 To: ietf-ppp@merit.edu From: Frank Kastenholz Subject: Re: I-D ACTION... Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Sorry about that... an impedence mismatch between a new-mailer and my old-fingers... frank kastenholz - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 29 10:27:17 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.6/8.8.5) with SMTP id KAA21058; Tue, 29 Jul 1997 10:25:55 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 29 Jul 1997 10:25:49 -0400 Received: (from majordom@localhost) by merit.edu (8.8.6/8.8.5) id KAA21040 for ietf-ppp-outgoing; Tue, 29 Jul 1997 10:25:48 -0400 (EDT) Received: from shultz.gigapacket.com (shultz.gigapacket.com [38.161.132.2]) by merit.edu (8.8.6/8.8.5) with ESMTP id KAA21035 for ; Tue, 29 Jul 1997 10:25:43 -0400 (EDT) Received: from hochstetter (hochstetter.gigapacket.com [38.161.132.53]) by shultz.gigapacket.com (8.8.6/8.8.6) with SMTP id KAA23569; Tue, 29 Jul 1997 10:25:09 -0400 (EDT) Message-Id: <3.0.1.32.19970729102737.00951e30@shultz.gigapacket.com> X-Sender: kasten@shultz.gigapacket.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 29 Jul 1997 10:27:37 -0400 To: dev@gigapacket.com From: Frank Kastenholz Subject: Re: I-D ACTION:draft-ietf-pppext-funi-01.txt Cc: ietf-ppp@merit.edu In-Reply-To: <9707290938.aa06926@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu At 09:38 AM 7/29/97 -0400, Internet-Drafts@ietf.org wrote: > 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 : PPP Over FUNI > Author(s) : M. Kaycee, G. Gross, A. Lin, > A. Malis, J. Stephens > Filename : draft-ietf-pppext-funi-01.txt > Pages : 9 > Date : 07/28/1997 > >The Point-to-Point Protocol (PPP) [1] provides a standard method for >transporting multi-protocol datagrams over point-to-point links. > >This document describes the use of ATM Frame User Network Interface >(FUNI) for framing PPP encapsulated packets. > >Internet-Drafts are available by anonymous FTP. Login 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-funi-01.txt". >A URL for the Internet-Draft is: >ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-funi-01.txt > >Internet-Drafts directories are located at: > > o Africa: ftp.is.co.za > > o Europe: ftp.nordu.net > ftp.nis.garr.it > > o Pacific Rim: munnari.oz.au > > o US East Coast: ds.internic.net > > o US West Coast: ftp.isi.edu > >Internet-Drafts are also available by mail. > >Send a message to: mailserv@ds.internic.net. In the body type: > "FILE /internet-drafts/draft-ietf-pppext-funi-01.txt". > >NOTE: The mail server at ds.internic.net can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e., documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version >of the Internet-Draft. > > > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 29 14:59:04 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.6/8.8.5) with SMTP id OAA28156; Tue, 29 Jul 1997 14:57:08 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 29 Jul 1997 14:56:38 -0400 Received: (from majordom@localhost) by merit.edu (8.8.6/8.8.5) id OAA28132 for ietf-ppp-outgoing; Tue, 29 Jul 1997 14:56:37 -0400 (EDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm036-13.dialip.mich.net [141.211.7.55]) by merit.edu (8.8.6/8.8.5) with SMTP id OAA28124 for ; Tue, 29 Jul 1997 14:56:32 -0400 (EDT) Date: Tue, 29 Jul 97 16:24:30 GMT From: "William Allen Simpson" Message-ID: <6358.wsimpson@greendragon.com> To: ietf-ppp@merit.edu Subject: LCP Extensions and Self-Describing-Padding Sender: owner-ietf-ppp@merit.edu Because of the interest in SDP outside this WG, I have split the specification into its own draft. Please take a look, and post any suggestions you have to this list. At every IETF meeting for more than a year, we have approved these options for Draft Standard. Please post a message privately to Karl Fox if you have implemented any one of these, as he needs to compile that list under our new formal rules in RFC2026. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jul 29 15:11:29 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.6/8.8.5) with SMTP id PAA28567; Tue, 29 Jul 1997 15:10:02 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 29 Jul 1997 15:09:50 -0400 Received: (from majordom@localhost) by merit.edu (8.8.6/8.8.5) id PAA28549 for ietf-ppp-outgoing; Tue, 29 Jul 1997 15:09:49 -0400 (EDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm035-20.dialip.mich.net [141.211.7.31]) by merit.edu (8.8.6/8.8.5) with SMTP id PAA28539 for ; Tue, 29 Jul 1997 15:09:43 -0400 (EDT) Date: Tue, 29 Jul 97 19:02:41 GMT From: "William Allen Simpson" Message-ID: <6361.wsimpson@greendragon.com> To: ietf-ppp@merit.edu Subject: LCP CallBack Sender: owner-ietf-ppp@merit.edu Last year, we had split out the CallBack into a separate draft. Supposedly, there were folks that desired some changes/extensions. I have received very few questions and/or suggestions. Part of this is my fault, as last fall I had an avid questioner, but I was out of town and very busy, and forgot to answer him when I had time a month later.... He must have given up on me. Mea Culpa. So, I just spent 6 hours reviewing everything that has been posted on the list regarding callback in the past 2 years. Most of that turned out to be BACP. But, there were some misconceptions that appeared more than once, mostly regarding how PPP options work, and it appears that a cross reference to the main PPP specification is needed. (heavy sigh) I have added a short Introduction. I have added E.165 for ISDN as requested, although I am not sure how many PPP ISDN implementations are using that. I see that ITU has added E.166 and E.167, but I've not read them. Anyone have any experience? I have added the suggestion (as an example) that CallBack be allowed to delay until late night hours (generalized to any kind of delay awaiting traffic). But, such configuration details are really policy matters, outside the scope of the specification. I have added a small example to operation 1. Yes, it is site dependent, but one (non-english speaker) didn't understand what a dialing string was.... I added a warning about configuration errors. As far as I can tell, there are no bits-on-the-wire changes, except adding E.165 as an option. If nobody actually needs that (by sending a positive indication to the list), I'll reserve it, but delete it from the next draft. I have indicated that operation 0 (authenticated user) support is required as the basic mechanism, as originally intended (that's why it's the first one)! And added a small amount of security considerations on unauthenticated and unrestricted callback. Please post a message privately to Karl Fox if you have implemented any one of these, as he needs to compile that list under our new formal rules in RFC2026. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jul 30 10:08:36 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.6/8.8.5) with SMTP id KAA15105; Wed, 30 Jul 1997 10:07:54 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 30 Jul 1997 09:58:46 -0400 Received: (from majordom@localhost) by merit.edu (8.8.6/8.8.5) id JAA14893 for ietf-ppp-outgoing; Wed, 30 Jul 1997 09:58:45 -0400 (EDT) Received: from ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.6/8.8.5) with SMTP id JAA14889 for ; Wed, 30 Jul 1997 09:58:41 -0400 (EDT) Received: from ietf.ietf.org by ietf.org id aa07503; 30 Jul 97 9:37 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-padding-ds-00.txt Date: Wed, 30 Jul 1997 09:37:39 -0400 Message-ID: <9707300937.aa07503@ietf.org> Sender: owner-ietf-ppp@merit.edu --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : PPP LCP Self Describing Padding Author(s) : W. Simpson Filename : draft-ietf-pppext-padding-ds-00.txt Pages : 5 Date : 07/29/1997 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 (LCP) for establishing, configuring, and testing the data-link connection. This document defines the Self-Describing-Padding option. 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-padding-ds-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-padding-ds-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-padding-ds-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970729152644.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-padding-ds-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-padding-ds-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970729152644.I-D@ietf.org> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jul 31 12:24:29 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.6/8.8.5) with SMTP id MAA11160; Thu, 31 Jul 1997 12:23:51 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 31 Jul 1997 12:19:02 -0400 Received: (from majordom@localhost) by merit.edu (8.8.6/8.8.5) id MAA11024 for ietf-ppp-outgoing; Thu, 31 Jul 1997 12:19:01 -0400 (EDT) Received: from ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.6/8.8.5) with SMTP id MAA10995 for ; Thu, 31 Jul 1997 12:18:49 -0400 (EDT) Received: from ietf.ietf.org by ietf.org id aa09001; 31 Jul 97 9:56 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary='NextPart' To: IETF-Announce@ietf.org Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION: draft-ietf-pppext-callback-ds-01.txt Date: Thu, 31 Jul 1997 09:56:38 -0400 Message-ID: <9707310956.aa09001@ietf.org> Sender: owner-ietf-ppp@merit.edu --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : PPP LCP CallBack Author(s) : W. Simpson Filename : draft-ietf-pppext-callback-ds-01.txt Pages : 5 Date : 1997-07-30 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 (LCP) for establishing, configuring, and testing the data-link connection. This document defines the CallBack option. Internet-Drafts are available by anonymous FTP. Login wih the username 'anonymous' and a password of your e-mail address. After logging in, type 'cd internet-drafts' and then 'get draft-ietf-pppext-callback-ds-01.txt'. A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-callback-ds-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: 'FILE /internet-drafts/draft-ietf-pppext-callback-ds-01.txt'. NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the 'mpack' utility. To use this feature, insert the command 'ENCODING mime' before the 'FILE' command. To decode the response(s), you will need 'munpack' or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with 'multipart' MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary='OtherAccess' OtherAccess Content-Type: Message/External-body; access-type='mail-server'; server='mailserv@ds.internic.net' Content-Type: text/plain Content-ID: <19970730153910.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-callback-ds-01.txt --OtherAccess Content-Type: Message/External-body; name='draft-ietf-pppext-callback-ds-01.txt'; site='ds.internic.net'; access-type='anon-ftp'; directory='internet-drafts' Content-Type: text/plain Content-ID: <19970730153910.I-D@ietf.org> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jul 31 15:36:32 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.6/8.8.5) with SMTP id PAA16782; Thu, 31 Jul 1997 15:36:29 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 31 Jul 1997 15:34:46 -0400 Received: (from majordom@localhost) by merit.edu (8.8.6/8.8.5) id PAA16728 for ietf-ppp-outgoing; Thu, 31 Jul 1997 15:34:46 -0400 (EDT) Received: from ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.6/8.8.5) with SMTP id PAA16724 for ; Thu, 31 Jul 1997 15:34:42 -0400 (EDT) Received: from ietf.ietf.org by ietf.org id aa11671; 31 Jul 97 11:22 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-aal5-01.txt Date: Thu, 31 Jul 1997 11:22:16 -0400 Message-ID: <9707311122.aa11671@ietf.org> Sender: owner-ietf-ppp@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 : PPP over AAL5 Author(s) : M. Kaycee, G. Gross, A. Lin, A. Malis, J. Stephens Filename : draft-ietf-pppext-aal5-01.txt Pages : 9 Date : 07/28/1997 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document describes the use of ATM Adaptation Layer 5 (AAL5) for framing PPP encapsulated packets. Internet-Drafts are available by anonymous FTP. Login 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-aal5-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-aal5-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-aal5-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970728113826.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-aal5-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-aal5-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970728113826.I-D@ietf.org> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jul 31 22:46:46 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.6/8.8.5) with SMTP id WAA23431; Thu, 31 Jul 1997 22:46:34 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 31 Jul 1997 22:44:23 -0400 Received: (from majordom@localhost) by merit.edu (8.8.6/8.8.5) id WAA23406 for ietf-ppp-outgoing; Thu, 31 Jul 1997 22:44:22 -0400 (EDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm054-16.dialip.mich.net [141.211.6.154]) by merit.edu (8.8.6/8.8.5) with SMTP id WAA23399 for ; Thu, 31 Jul 1997 22:44:18 -0400 (EDT) Date: Fri, 1 Aug 97 02:07:36 GMT From: "William Allen Simpson" Message-ID: <6386.wsimpson@greendragon.com> To: Michael Liwerant Cc: ietf-ppp@merit.edu Subject: Re: Stac-LZS on noisy channel Sender: owner-ietf-ppp@merit.edu > From: Michael Liwerant > Need some advise regarding the feasibility of performing a fallback (from > using a session history buffer) to using NO history when too many > synchronization losses are detected during RECEPTION of compressed > packets. This fallback is involved in retransmission of config-request > with History-Count=0, followed by reset of the history buffer when > config-ack is received. > Very feasible. You can renegotiate CCP at any time. Just do it. Other parts of the stack will suffer, too, like VJ header compression. In general, tho, I never found a regular line that lossy here in the States. On the other hand, I hear that Frame Relay links are getting buffer saturated, and folks are seeing heavy losses there. I haven't checked since the early testing, when it was fine. This does not bode well for PPP/ATM. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - -