From ietf-ppp-request@ucdavis.ucdavis.edu Fri Nov 1 08:48:19 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA11842; Fri, 1 Nov 91 08:30:46 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA11642; Fri, 1 Nov 91 08:20:14 -0800 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA06067; Fri, 1 Nov 91 11:19:09 -0500 From: bsimpson@vela.acs.oakland.edu (Bill Simpson) Message-Id: <9111011619.AA06067@vela.acs.oakland.edu> Subject: Re: Editorial changes to lcp and ipcp docs To: pgross@nri.reston.va.us (Phill Gross) Date: Fri, 1 Nov 91 11:19:08 EST Cc: ietf@isi.edu, ietf-ppp@ucdavis.edu, pgross@ans.net In-Reply-To: <9110311642.aa24106@NRI.NRI.Reston.VA.US>; from "Phill Gross" at Oct 31, 91 4:42 pm X-Mailer: ELM [version 2.3 PL11] Thank you for the clarification. It should be very easy to add seven words to the line for Drew Perkins which already appears in the (extensive) acknowledgments section. This is such a trivial change! I recommend that in the future, such changes be made during the normal course of moving the document from draft to RFC, rather than delaying the document for many months. Bill Simpson From ietf-ppp-request@ucdavis.ucdavis.edu Mon Nov 4 20:01:16 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA13685; Mon, 4 Nov 91 19:45:39 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from CAYMAN.CAYMAN.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA13581; Mon, 4 Nov 91 19:41:16 -0800 Received: from caicos.Cayman.COM by cayman.Cayman.COM (4.1/SMI-4.0) id AA10452; Mon, 4 Nov 91 22:40:35 EST Received: from localhost by caicos.Cayman.COM (4.1/SMI-4.1) id AA13266; Mon, 4 Nov 91 22:40:35 EST Message-Id: <9111050340.AA13266@caicos.Cayman.COM> To: ietf-ppp@ucdavis.edu Subject: Re: call for implementations In-Reply-To: Mail from bsimpson@vela.acs.oakland.edu (Bill Simpson) dated Wed, 30 Oct 91 05:15:38 EST <9110301015.AA22399@vela.acs.oakland.edu> Date: Mon, 04 Nov 91 22:40:33 -0500 From: brad@Cayman.COM You can add Cayman with: Cayman Async VJ -brad From ietf-ppp-request@ucdavis.ucdavis.edu Tue Nov 5 12:28:59 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA02210; Tue, 5 Nov 91 12:01:19 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Shiva.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA01977; Tue, 5 Nov 91 11:50:48 -0800 Received: by Shiva.COM (1.34b) Tue, 5 Nov 91 14:49:50 EST Date: Tue, 5 Nov 91 14:49:50 EST From: Marty Del Vecchio Message-Id: <9111051949.AA17096@Shiva.COM> To: ietf-ppp@ucdavis.edu Subject: Meeting at IETF Has it been decided when the PPP group will meet at IETF in Santa Fe? I'd like to arrange my travel plans around that if it is possible. Thanks. From ietf-ppp-request@ucdavis.ucdavis.edu Tue Nov 5 13:07:47 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA02495; Tue, 5 Nov 91 12:16:31 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ftp.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA02247; Tue, 5 Nov 91 12:02:48 -0800 Received: from gordon.port2.ftp.com by ftp.com via PCMAIL with DMSP id AA04334; Tue, 5 Nov 91 15:03:29 -0500 Date: Tue, 5 Nov 91 15:03:29 -0500 Message-Id: <9111052003.AA04334@ftp.com> To: bsimpson@vela.acs.oakland.edu Subject: Re: call for implementations From: gordon@ftp.com (Gordon Lee) Cc: ietf-ppp@ucdavis.edu Repository: babyoil.ftp.com Originating-Client: port2.ftp.com > From: bsimpson@vela.acs.oakland.edu (Bill Simpson) > > We need to have a periodic call for implementations. > > FTP Software Async Ours also supports PAP, but only in one direction. That is, PC/TCP will supply a userid/password if asked, but it will not ask the remote peer to identify itself. - GL -- }} Gordon Lee voice: (617) 246-0900 fax: (617) 245-7943 }} FTP Software 26 Princess St Wakefield, MA 01880 From ietf-ppp-request@ucdavis.ucdavis.edu Wed Nov 6 12:05:10 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA00980; Wed, 6 Nov 91 11:35:35 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [192.124.48.2] by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA00694; Wed, 6 Nov 91 11:28:04 -0800 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA00466; Wed, 6 Nov 91 11:26:33 PST Date: Wed, 6 Nov 91 11:26:33 PST From: brian@lloyd.com (Brian Lloyd) Message-Id: <9111061926.AA00466@ray.lloyd.com> To: marty@Shiva.COM Cc: ietf-ppp@ucdavis.edu In-Reply-To: Marty Del Vecchio's message of Tue, 5 Nov 91 14:49:50 EST <9111051949.AA17096@Shiva.COM> Subject: Meeting at IETF The preliminary agenda was published last week. There are two PPP sessions on Wednesday, both in the morning and in the afternoon. Would everyone please send me the items that they feel need to be discussed and how much time they feel is necessary to properly discuss them. I will try to come up with an agenda so we can stay on track. Brian Lloyd, WB6RQN Lloyd and Associates Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392 From ietf-ppp-request@ucdavis.ucdavis.edu Thu Nov 7 20:00:47 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA17211; Thu, 7 Nov 91 19:45:29 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from volitans.morningstar.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA17048; Thu, 7 Nov 91 19:37:01 -0800 Received: from crappie.morningstar.com by volitans.morningstar.com (5.65a/91110101) id AA12485; Thu, 7 Nov 91 22:35:43 -0500 Received: by crappie.morningstar.com (5.65a/910712902) id AA02207; Thu, 7 Nov 91 22:34:46 -0500 Date: Thu, 7 Nov 91 22:34:46 -0500 From: Karl Fox Message-Id: <9111080334.AA02207@crappie.morningstar.com> To: ietf-ppp@ucdavis.edu Subject: Implementing LQM I have just completed implementing LQM in our PPP-for-Unix product. Having had some significant difficulty understanding how to go about it, I wanted to explain my understanding of the mechanism (as I understand it and as I implemented it), so that I can either get agreement or correction from the pool of PPP knowledge out there. When machine A sends a Configure-Request containing the Link-Quality- Monitoring configuration option to machine B, it is saying "I (A) want you (B) to periodically send me Link-Quality-Report messages (LQRs) at the interval specified in this request." If machine B does not also include the LQM option in its CR, then machine A will not send LQRs. Getting to the understanding described in the above paragraph was the part that caused me the most trouble. It took me a long time to understand that LQM negotiated in one only direction still has value -- the requesting side receives the LQRs, and thus can still use the recommended policy described in the LCP document (requiring one to receive at least k out of every n transmitted LQRs to consider the line of high enough quality to justify continued use). My stumbling block was that, if only one side negotiates LQM, no LQRs will ever have the V bit set and all of the measurements will be meaningless. However, this doesn't matter, since all the LQM policy cares about is whether the LQRs arrive or not. Incidentally, actually processing (generating and parsing) the LQR messages is almost trivial -- the document describes exactly what to do at each step, even to the point of listing what state variables and counters to keep and what their types should be. The only tough part was deciding how to handle timeouts for received LQRs, but maybe it's just because I haven't been getting much sleep since Interop. :-) If all of the above is obvious, please forgive me. If you think it's wrong, please tell me why. If the LCP draft is ambiguous or incorrect, now would be a good time to correct it. From ietf-ppp-request@ucdavis.ucdavis.edu Thu Nov 7 23:01:08 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA20427; Thu, 7 Nov 91 22:45:43 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA20401; Thu, 7 Nov 91 22:42:04 -0800 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA19301; Fri, 8 Nov 91 01:41:04 -0500 From: bsimpson@vela.acs.oakland.edu (Bill Simpson) Message-Id: <9111080641.AA19301@vela.acs.oakland.edu> Subject: Re: call for implementations To: ietf-ppp@ucdavis.edu Date: Fri, 8 Nov 91 1:41:03 EST In-Reply-To: <9110301015.AA22399@vela.acs.oakland.edu>; from "Bill Simpson" at Oct 30, 91 5:15 am X-Mailer: ELM [version 2.3 PL11] Here are the posted implementations so far: 3Com Sync (magic only) PAP IP Bridging DECnet XNS CLNP Appletalk Vines IS-IS OSPF Brixton Async&Sync lqm PAP IP+vj Cayman Async IP+vj Cisco Sync (lqm only '92) IP FTP Software Async PAP IP INTERACTIVE/Lachman Async IP+vj KA9Q Async PAP IP+vj Merit Async PAP IP+vj Morning Star Async&Sync lqm PAP CHAP IP+vj SunOS (PD) Async PAP IP+vj Telebit Async&Sync IP+vj Certainly enough to go to Draft Standard status! Bill Simpson From ietf-ppp-request@ucdavis.ucdavis.edu Fri Nov 8 01:02:05 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA22426; Fri, 8 Nov 91 00:46:13 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from enet-gw.pa.dec.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA22265; Fri, 8 Nov 91 00:39:26 -0800 Received: by enet-gw.pa.dec.com; id AA00156; Fri, 8 Nov 91 00:38:26 -0800 Message-Id: <9111080838.AA00156@enet-gw.pa.dec.com> Received: from marvin.enet; by decwrl.enet; Fri, 8 Nov 91 00:38:27 PST Date: Fri, 8 Nov 91 00:38:27 PST From: SEMPER INFACEBO SUMUS - SOLE PROFUNDUM VARIAT 08-Nov-1991 0838 To: ietf-ppp@ucdavis.edu Apparently-To: ietf-ppp@ucdavis.edu > of high enough quality to justify continued use). My stumbling block > was that, if only one side negotiates LQM, no LQRs will ever have the V > bit set and all of the measurements will be meaningless. However, this > doesn't matter, since all the LQM policy cares about is whether the LQRs > arrive or not. This is surely only true when there is one way LQM, (since the V bit is never set). When there is two way LQM, then the policy must check the contents of the LQR otherwise they are completely redundant. (I'm sure this is what you meant. It's just the the above doesn't seem to imply that) :-) /Dean From ietf-ppp-request@ucdavis.ucdavis.edu Sat Nov 9 10:15:28 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA27329; Sat, 9 Nov 91 10:01:17 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from plg.waterloo.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA27188; Sat, 9 Nov 91 09:49:48 -0800 Received: by plg.waterloo.edu id ; Sat, 9 Nov 91 12:48:44 -0500 Date: Sat, 9 Nov 91 12:48:44 -0500 From: Dave Mason Message-Id: <9111091748.AA15329@plg.waterloo.edu> To: ietf-ppp@ucdavis.edu In-Reply-To: Drew D. Perkins's message of Sat, 9 Nov 91 10:19:20 EST <9111091519.AA19006@interstream.com> Subject: RE: PPP implementations > From: ddp@interstream.com (Drew D. Perkins) > Subject: Re: PPP implementations > > There are versions for Sun's. I don't know if there are any for Ultrix (or > are you running 4.3BSD?). Try sending mail to ietf-ppp@ucdavis.edu for info > on where to get these. > > Drew Could you tell me where I might find (preferably freely-copyable) versions of PPP for Sparcstations & Vaxes? Thanks. ../Dave From ietf-ppp-request@ucdavis.ucdavis.edu Sun Nov 10 09:31:45 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA15249; Sun, 10 Nov 91 09:08:13 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from plg.waterloo.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA15066; Sun, 10 Nov 91 08:45:49 -0800 Received: by plg.waterloo.edu id ; Sun, 10 Nov 91 11:44:42 -0500 Date: Sun, 10 Nov 91 11:44:42 -0500 From: Dave Mason Message-Id: <9111101644.AA00555@plg.waterloo.edu> To: ddp@interstream.com Cc: ietf-ppp@ucdavis.edu In-Reply-To: Drew D. Perkins's message of Sat, 9 Nov 91 10:19:20 EST <9111091519.AA19006@interstream.com> Subject: RE: PPP implementations > There are versions for Sun's. I don't know if there are any for Ultrix (or > are you running 4.3BSD?). Try sending mail to ietf-ppp@ucdavis.edu for info > on where to get these. I got an implementation for SunOS4.1 from them, thanks. The Vax runs 4.3Tahoe. Does that help? Thanks ../Dave From ietf-ppp-request@ucdavis.ucdavis.edu Mon Nov 11 18:47:44 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA14847; Mon, 11 Nov 91 18:17:16 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from CAYMAN.CAYMAN.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA14667; Mon, 11 Nov 91 18:08:54 -0800 Received: from moon-patrol.engineering (moon-patrol.cayman.com) by cayman.Cayman.COM (4.1/SMI-4.0) id AA15626; Mon, 11 Nov 91 13:31:52 EST Received: by moon-patrol.engineering (4.1/SMI-4.1) id AA00477; Mon, 11 Nov 91 13:32:13 EST Date: Mon, 11 Nov 91 13:32:13 EST From: brad@Cayman.COM (Brad Parker) Message-Id: <9111111832.AA00477@moon-patrol.engineering> To: ietf-ppp@ucdavis.edu Cc: arap-wg@apple.com Subject: Proposal for Dial-back via LCP options X-Zippy: UH-OH!! I think KEN is OVER-DUE on his R.V. PAYMENTS and HE'S having a NERVOUS BREAKDOWN too!! Ha ha. I have been chairing a group formed by Apple to specify the use of PPP as a transport for Appletalk. We call ourselves the "ARAP working group", for Appletalk Remote Access Protocol. The group was originally semi-private (Apple + vendors) with a proprietary protocol (ARAP) but has decided to use PPP and try and integrate with the "Apple-IP" IETF workgroup. We plan to discuss our current draft (available via ftp from ftp.cayman.com) at Santa Fe. As part of our work, we have a strong desire to support so called "dial-back" to enhance security and allow for "toll reversal". I'll be the first to admit that this attempt may be a. foolish, b. in the wrong place or c. doomed to failure, but in any case we wrote up a document which attempts to outline a simple extension to the LCP to give up various forms for dial-back support. I'd like some guidance from others with a broader perspective (i.e. more experience) - where should we go with this? I seem to remember seeing some mention of others doing work in this area. I've included the latest "dial back" proposal. Please give feed back. Brad Parker Cayman Systems Chair, ARAP Working group ---- cut here ---- Proposal for ARAP Working group / IETF PPP extensions WG Brad Parker (brad@cayman.com) 10/25/91 Proposed Extension to the PPP LCP Protocol to Support Dial-Back Overview Two additional options are added to the defined PPP LCP option set. These options allow a "caller" to request dial-back or have the "callee" demand dial-back. On the first connection attempt, the "dial-back request" option is negotiated. If successfully negotiated, the link is torn down and a "call-back" is initiated. When the "call-back" occurs, the LCP option negotiation restarts, negotiating with the "dial-back response" option. If negotiated successfully, the link is established. It is assumed that the password protocol (in either it's secure or non-secure form) is used to authenticate the caller. Additional Configuration Option Types 5 Dial-back Request 6 Dial-back Response In our discussions, the model of async "dial-in" is used. In this model the "dial-in" initiator is referred to as a "client", and the "dial-in" acceptor is referred to as a "server". It was expressed that a server will want these facility for security and that a client will want for toll-reversal. Dial-back Request ----------------- Length > 0 Option data is defined as a sequence of bytes which help to uniquely identify the caller. Presumably these bytes in conjunction with any authentication (either PPP PAP or better) allow the answering side of the connection to call back. If unable, the option is rejected. If the option is acked, it is assumed that the link will be torn down and the call-back initiated. Two fields: session id (4 bytes) optional data - ascii string (could be phone #) Dial-back Response ------------------ Length > 0 Option data is the identical sequence of bytes provided in the Dial-back Request option. If the caller does not agree with the supplied data (i.e. it does not match what was negotiated in the dial-back request), the option is rejected and the link is torn down. Discussion ---------- We talked about how these options could be used to affect both server initiated and client initiated dial-back. Server initiated (dial-in) client <------- req w/# (session id) -------> ack (hang up, server dials-in) client -------> req w/# (session id) <------- ack Client initiated (dial-in) client -------> req w/# (session id, optional phone #) <------- ack (hang up, server dials-in) client <------- req w/# (session id) -------> ack The need to secure authentication was strong in both these situations, but deferred to the PPP/CHAP protocol. From ietf-ppp-request@ucdavis.ucdavis.edu Mon Nov 11 22:02:09 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA16589; Mon, 11 Nov 91 21:45:51 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [192.124.48.2] by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA16485; Mon, 11 Nov 91 21:33:31 -0800 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA01968; Mon, 11 Nov 91 21:31:53 PST Date: Mon, 11 Nov 91 21:31:53 PST From: brian@lloyd.com (Brian Lloyd) Message-Id: <9111120531.AA01968@ray.lloyd.com> To: ietf-ppp@ucdavis.edu Subject: PPP WG Agenda I still have not heard from anyone regarding the items we need to cover in the PPP sessions. I need to come up with an agenda and it will be my agenda if I don't hear from others. Brian Lloyd, WB6RQN Lloyd and Associates Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392 From ietf-ppp-request@ucdavis.ucdavis.edu Mon Nov 11 22:15:37 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA16627; Mon, 11 Nov 91 21:53:32 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [192.124.48.2] by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA16498; Mon, 11 Nov 91 21:34:22 -0800 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA01965; Mon, 11 Nov 91 21:30:38 PST Date: Mon, 11 Nov 91 21:30:38 PST From: brian@lloyd.com (Brian Lloyd) Message-Id: <9111120530.AA01965@ray.lloyd.com> To: brad@Cayman.COM Cc: ietf-ppp@ucdavis.edu, arap-wg@apple.com In-Reply-To: Brad Parker's message of Mon, 11 Nov 91 13:32:13 EST <9111111832.AA00477@moon-patrol.engineering> Subject: Proposal for Dial-back via LCP options The issue of dial back, and, in fact, all issues relating to dynamic connections in PPP (dial-up, ISDN, etc.) should be addressed in the PPPEXT WG sessions this coming week. I had originally scheduled a WG session and a BOF to discuss the connection related issued but decided that the BOF should really be a full session. The issue of dial-back is a good one. With dial-up service it is necessary to hang up and dial back if you want to reverse the charging (not everyone has 800 service). On the other hand services like ISDN may offer a "reverse the charges" mode through the D channel or something like that. In any case you need to perform the authentication so that you know who to dial back. That is why there is a dial-back field in the CHAP protocol (we didn't put it into PAP because PAP had already been pretty well set in concrete and being backward compatible would be too much of a pain). Let's discuss this in the afternoon session. Brian Lloyd, WB6RQN Lloyd and Associates Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392 From ietf-ppp-request@ucdavis.ucdavis.edu Tue Nov 12 05:33:28 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA20216; Tue, 12 Nov 91 05:15:46 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from volitans.morningstar.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA20017; Tue, 12 Nov 91 05:10:11 -0800 Received: from roughy.morningstar.com by volitans.morningstar.com (5.65a/91110101) id AA02876; Tue, 12 Nov 91 08:08:56 -0500 Received: by roughy.morningstar.com (5.65a/910712902) id AA05057; Tue, 12 Nov 91 08:08:51 -0500 Date: Tue, 12 Nov 91 08:08:51 -0500 From: Bob Sutterfield Message-Id: <9111121308.AA05057@roughy.morningstar.com> To: ietf-ppp@ucdavis.edu Subject: another "dialback"-like scenario to consider Telebit's NetBlazer advertizes the capability to "demultiplex" a logical point-to-point connection over several physical circuits, so that the effective bandwidth between two routers can be multiplied by the number of modems available. The decision to place the additional call is based on the length of the queue of packets waiting to traverse the link. This is a nifty feature, and some of our customers are asking whether we support it too (not yet...) But one can easily imagine useful and potentially common scenarios where the end with the queue is not the end that can do the dialing: Suppose a network service provider is accessible via modem pools that answer on an 800- or 900-number rotary, but that are unable to dial. "Leaf" node customers will typically generate more customer-bound than hub-bound traffic, with NNTP and FTP etc. So while the queues will typically grow on the network provider's router, the ability to place a parallel call might reside (if anywhere) on the customer's machine. But the customer's machine wouldn't see the queue growth, and would never see the need to place the parallel calls. I would suggest that, in addition to the "shut down this line and call me back" semantics, it might be useful to consider providing "leave this line up and call me in parallel". This might be as simple as sending a "call me back" and then REJing the terminate-request, or some more complexity might be involved. I haven't considered just how this might be provided, but during the dialback discussion seems a good time and place to address it. Unfortunately, I won't be able to attend the meetings, so I'd appreciate it if this forum were kept apprised of progress... From ietf-ppp-request@ucdavis.ucdavis.edu Wed Nov 13 10:50:50 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA09480; Wed, 13 Nov 91 10:34:30 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [192.124.48.2] by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA08653; Wed, 13 Nov 91 10:16:19 -0800 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA02448; Wed, 13 Nov 91 10:14:34 PST Date: Wed, 13 Nov 91 10:14:34 PST From: brian@lloyd.com (Brian Lloyd) Message-Id: <9111131814.AA02448@ray.lloyd.com> To: galvin@TIS.COM Cc: balenson@TIS.COM, ietf-ppp@ucdavis.edu In-Reply-To: James M Galvin's message of Tue, 12 Nov 91 20:15:21 -0500 <9111130115.AA21595@TIS.COM> Subject: PPP Authentication at Santa Fe Reply-To: James M Galvin Date: Tue, 12 Nov 91 20:15:21 -0500 From: James M Galvin Dave (or Brian), What is the status of security in PPP, in particular Authentication. Is there a plan for issues to be discussed at one of the working group meetings? PLease let me know ASAP. I am preparing the Security Track for Santa Fe and I would like to include this information. Thanks, Jim The PAP/CHAP document is out and is available from nri.reston.va.us as draft-ietf-pppext-authentication-00.txt. We never did get the verbiage on proper dissemination of "secrets" but it is easy to add later. Brian Lloyd, WB6RQN Lloyd and Associates Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392 From ietf-ppp-request@ucdavis.ucdavis.edu Wed Nov 13 12:48:17 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA10643; Wed, 13 Nov 91 12:08:16 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [192.124.48.2] by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA10396; Wed, 13 Nov 91 11:46:34 -0800 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA02511; Wed, 13 Nov 91 11:44:45 PST Date: Wed, 13 Nov 91 11:44:45 PST From: brian@lloyd.com (Brian Lloyd) Message-Id: <9111131944.AA02511@ray.lloyd.com> To: galvin@TIS.COM Cc: balenson@TIS.COM, ietf-ppp@ucdavis.edu In-Reply-To: James M Galvin's message of Wed, 13 Nov 91 13:28:20 -0500 <9111131828.AA08818@TIS.COM> Subject: PPP Authentication at Santa Fe I think that we ought to have you at least take a look at the doc (it is simple so it should take you about 5 minutes to read) and make comments. The folks at Morningstar in their mailing list have brough up the subject of encryption so I want to add that to the agenda too. Your presence there would be greatly appreciated. I will see to it that you get the preliminary agenda so you do not have to attend a full day of PPP discussions. The PPP sessions are morning and afternoon on Wednesday. Would morning or afternoon suit you better? Brian Lloyd, WB6RQN Lloyd and Associates Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392 From ietf-ppp-request@ucdavis.ucdavis.edu Wed Nov 13 15:13:38 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA12494; Wed, 13 Nov 91 14:51:11 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [192.124.48.2] by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA12368; Wed, 13 Nov 91 14:36:54 -0800 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA02619; Wed, 13 Nov 91 14:33:51 PST Date: Wed, 13 Nov 91 14:33:51 PST From: brian@lloyd.com (Brian Lloyd) Message-Id: <9111132233.AA02619@ray.lloyd.com> To: galvin@TIS.COM Cc: balenson@TIS.COM, ietf-ppp@ucdavis.edu In-Reply-To: Brian Lloyd's message of Wed, 13 Nov 91 11:44:45 PST <9111131944.AA02511@ray.lloyd.com> Subject: PPP Authentication at Santa Fe I was just informed that the ppp authentication doc at nri.reston.va.us is not current (damn!). I have made the doc available for anonymous FTP from angband.stanford.edu. Look in pub/ppp. Sorry folks. Brian Lloyd, WB6RQN Lloyd and Associates Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392 From ietf-ppp-request@ucdavis.ucdavis.edu Wed Nov 13 23:45:59 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA17513; Wed, 13 Nov 91 23:30:09 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [192.124.48.2] by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA17391; Wed, 13 Nov 91 23:17:47 -0800 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA02769; Wed, 13 Nov 91 23:16:10 PST Date: Wed, 13 Nov 91 23:16:10 PST From: brian@lloyd.com (Brian Lloyd) Message-Id: <9111140716.AA02769@ray.lloyd.com> To: ietf-ppp@ucdavis.edu Subject: agenda for IETF This is the basic agenda. Please speak now or hold your peace. Brian Lloyd, WB6RQN Lloyd and Associates Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392 ------------------------------ Morning Session: LCP Document discuss escapes/compression in LCP frames LQM implementations IPCP Document Authentication Document "Secret" management (SAAG Key BOF) Afternoon Session: Status of other implementations Status of other documents NCPs for: CLNP IPX Appletalk DECnet What did Appletalk folks implement? Dial-up issues standard connection establishment procs dial back issues inverse muxing Ed Vielmetti's frequently asked questions From ietf-ppp-request@ucdavis.ucdavis.edu Fri Nov 15 00:22:26 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA00427; Fri, 15 Nov 91 00:00:35 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from leeyi.aa.ox.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA00215; Thu, 14 Nov 91 23:55:03 -0800 Received: by leeyi.aa.ox.com (/\==/\ Smail3.1.22.1 #22.9) id ; Fri, 15 Nov 91 02:53 EST Message-Id: To: ietf-ppp@ucdavis.edu Subject: cisco v.25bis calling Date: Fri, 15 Nov 91 02:53:19 -0500 From: Edward Vielmetti X-Mts: smtp sorry for the headers, but it's important to see who else got cc'd on the message. the rtftools on (what's that machine at wisconsin -- indri ?) migth would turn the msword into something resembling ascii. --Ed ------- Forwarded Message To: isdn@list.prime.com, petri@digiw.fi (Petri Alhola), Peter Elford , rdthomps@vela.acs.oakland.edu (Robert D. Thompson), timr@labtam.labtam.oz.au (Tim Roper), "John D. Balogh, PSU OTC, 814.863.1252" , Petri Ojala , santo@roadrunner.pictel.com (Santo Wiryaman) Subject: cisco/Ascend V.25bis Implementor's Agreement Date: Thu, 14 Nov 91 17:21:40 PST From: Jim Forster Several weeks ago I wrote this: >> > PS: V.25bis is rather broad, so we did a sort of "Implementor's Agreement" >> > with Ascend communications. I can post it on ftp.cisco.com if desired. Its >> > an MS-Word, but I can put the Postscript there as well. Then unfortunately this: > My apologies, but some small typo's have recently been found in the spec, > and rather than confuse things, I thought it better to wait for the correct > version. I'll be away from my mail for a bit, so it will be probably be > two weeks before I get this on ftp.cisco.com. Sorry for the delay. Finally I have it ready to go. On ftp.cisco.com, you will find four files: V.25bis.MSWord V.25bis.PS V.25bis.MSWord.Z V.25bis.PS.Z The first is a Macbinary version of the MS-Word document. The second is a postscript version. The last two are compressed versions. The files are listed in the README file. The very quick summary of this is that it specifies V.25bis bit-sync, addressed call mode. It has an easy to follow narrative of the typical scenarios, and a detailed state/event table. In response to some questions that were asked: >> V.25bis is asynchronous character based interface, most ISDN adapters that >> are supporting it, are async adapters and using rs232 (v.28) interface. >> The sync adapters are most commonly using X.21 interface and dialing mecanism, >> there are also V.35 and V.11 options, but TA documants does not clearly specify >> how dialing is implemented. V.25bis also specifies bit-sync mode. That's what we're using. I'm told that IBM modems/TA's use basically the same scheme, and I'd be interested in hearing any details. >> How you do incoming call autentication with dial up connections. >> There is PAP option in PPP specification, but it is not yet implemented >> in cisco. The PAP connects into LLC layer of PPP, is there possibility >> to connect external daemon in cisco PPP low level driver ( i.e pass >> data send with some protocoll id field in ppp frams to UDP packets ) ?. Our first release will not have authentication, but I agree its very important, so we'll add it shortly. At this point the PPP CHAP looks like the best way to go. >> Is the IP address negotiating implemented in cisco PPP. No, not yet. -- Jim ------- End of Forwarded Message From ietf-ppp-request@ucdavis.ucdavis.edu Fri Nov 15 11:49:51 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA24689; Fri, 15 Nov 91 11:33:31 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from OPAL.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA23990; Fri, 15 Nov 91 11:15:39 -0800 Received: by opal.acc.com (4.1/SMI-4.0) id AA23480; Fri, 15 Nov 91 11:12:19 PST Date: Fri, 15 Nov 91 11:12:19 PST From: art@opal.acc.com (Art Berggreen) Message-Id: <9111151912.AA23480@opal.acc.com> To: ietf-ppp@ucdavis.edu, martillo@azea.clearpoint.com, tcp-ip@nic.ddn.mil Subject: Re: Multiprotocol Interconnect on X.25 and Packet Mode ISDN Cc: iplpdn@NRI.Reston.VA.US > . > . > . >In short, this claim that bridging is something which you don't want >to do is pure prejudice and does not belong in a technical discussion >unless the claim can be supported by reasoned and sound technical >arguments. There are often sound reasons to want to bridge and sound >reasons to avoid routing. > . > . > . >Joachim Carlo Santos Martillo Ajami Mr. Ajami, I must admit that I sort of admire your tenacity in defending your views in a fairly hostile environment. But I believe you have become a bit combative anytime a negative opinion about bridging is voiced. While believing that routing is a superior mechanism to bridging in general, I'll also accept that bridges can be useful in the proper environments. After all, bridging is just another forwarding decision based on addressing and topology information. But MAC addresses, learning and Spanning trees don't inherently convey the kind of topology information needed in complex networks. Also, most of the protocols which require bridging are designed to utilize the latency and broadcast reachability inherent on a single LAN, and were never intended to run in some of the networks extant today. It is a goal of bridges to attempt to provide similar behavior in more complex environments. Local LAN bridges perform this function very well in very small configurations and less well as the size scales. Remote bridges have a much harder time providing the desired environment and are considerably more sensitive to the characteristics of the WAN services. Most routed protocols have been designed to assume much less in the underlying link level services and can provide much better topology information to make forwarding decisions with. Now, the original subject of this thread was bridging over X.25. For most existing X.25 networks, I (and MANY others) believe that this is one of the worst WAN evironments to attempt bridging on. The two major reasons are the large and variable latencies which are commonplace, and the cost of flooding (mostly broadcast) packets. Art From ietf-ppp-request@ucdavis.ucdavis.edu Fri Nov 15 14:56:28 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA02099; Fri, 15 Nov 91 14:22:22 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from gatekeeper.oracle.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA01599; Fri, 15 Nov 91 14:15:00 -0800 Received: from rivendell.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.6) id AA15479; Fri, 15 Nov 91 14:13:50 PST Received: by rivendell.us.oracle.com (5.59.11/37.7) id AA07465; Fri, 15 Nov 91 14:13:44 PST Message-Id: <9111152213.AA07465@rivendell.us.oracle.com> Date: Fri, 15 Nov 91 14:13:44 PST From: Jack Haverty To: art@opal.acc.com Cc: ietf-ppp@ucdavis.edu, martillo@azea.clearpoint.com, tcp-ip@nic.ddn.mil, iplpdn@NRI.Reston.VA.US In-Reply-To: Art Berggreen's message of Fri, 15 Nov 91 11:12:19 PST <9111151912.AA23480@opal.acc.com> Subject: Multiprotocol Interconnect on X.25 and Packet Mode ISDN One additional tidbit for the fray: In considering bridging/routing/X.25/whatever, it's important to understand what applications are being used. Independent of the broadcast/multicast issue, there are applications which were designed with the assumption that communications on a LAN is inexpensive, and therefore they freely communicate - an example of this is various kinds of "hello" schemes. These can be extremely costly if the "LAN" in question is actually two LANs with bridge/repeater style of interconnection. Bridging over an expensive leased circuit can be almost as costly as bridging over X.25 PDNs. Conversely, you can find expensive systems built using routers - e.g., connecting two large DECNet areas or IP networks with a public X.25 service can be very costly, due to the background chatter associated with the various "hello" exchanges (DNS for example) and routing updates. I don't believe it is reasonable to make any blanket statements about one approach being better than another without looking "up" to see what the higher layer systems are doing in the particular situation. Jack From ietf-ppp-request@ucdavis.ucdavis.edu Mon Nov 18 12:47:53 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA25323; Mon, 18 Nov 91 12:33:10 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from TIS.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA25075; Mon, 18 Nov 91 12:29:48 -0800 Received: from TIS.COM by TIS.COM (4.1/SUN-5.64) id AA23348; Mon, 18 Nov 91 15:28:16 EST Message-Id: <9111182028.AA23348@TIS.COM> To: brian@lloyd.com (Brian Lloyd), Bill_Simpson@um.cc.umich.edu Cc: galvin@TIS.COM, ietf-ppp@ucdavis.edu Subject: Re: PPP Authentication at Santa Fe In-Reply-To: Your message of Wed, 13 Nov 91 11:44:45 PST. <9111131944.AA02511@ray.lloyd.com> Date: Mon, 18 Nov 91 15:28:14 -0500 From: balenson@TIS.COM > I think that we ought to have you at least take a look at the doc (it > is simple so it should take you about 5 minutes to read) and make > comments. Brian/Bill- Here are some last minute comments on the latest PAP draft. My most significant comments would be the need for text describing the management of keys and passwords, but you've already aknowledged that this is missing and will be filled in. Otherwise, my comments are relatively minor, perahps bordering on editorial. My primary concern is that the document should be as precise as possible. -DB ----- COMMENTS ON PPP AUTHENTICATION INTERNET DRAFT DATES OCTOBER 1991 David M. Balenson November 18, 1991 o Section 4, Challenge Handshake Authentication Protocol, and Section 4.3, Challenge and Response: The phrase "challenge checksum" is potentially confusing. An inattentive reader might think that the checksum itself was a challenge, or something like that. I would suggest simply calling it a "checksum". o Section 4.1, Configuration Option Format: The term "digest" is used. Elsewhere in the text the term "checksum" is used. I would suggest using only one term, probably "checksum". The description of the Digest states that the field indicates "the challenge method" to be used. To be more precise, the field indicates the "checksum" or "digest" method to be used. Also, note that the protocol requires the use of not just a checksum algorithm, but specifically a cryptographic checksum algorithm, which has special properties required for use in the challenge handshake. This might be useful to point out in a sentence or two at the beginning of Section 4. o Section 4.3 Challenge and Response: The statement that "The random value MUST be different each time a challenge is issued" is potentially misleading. At a minimum, what should be required is that each challenge is randomly generated. Over time, it's possible that a previously generated challenge would be randomly repeated, but that's ok since the repetition would not be predictable. Taken literally, one might interpret the current statement to mean that one needs to keep track of (e.g., in a list) all previously generated values to ensure non-repetition. I still think that the description should be more precise about the formation of the data to be checksummed. The text currently indicates "the Challenge Value followed by the secret". Insofar as the term "following" can have temporal as well as positional meanings, I think a term such as "concatenation" would be better, as in "compute a checksum on the concatenation of the Challenge value and the secret", or something like that. o Section 4.4, Success and Failure Section 4.3 indicates that the checksum computed by the authenticator is compared with the checksum in the response. This section indicates that appropriate response i.e., success or failure, is based on whether the value received in the reponse is "acceptable" or "not acceptable", respectively. Just to be precise, it should be stated that "acceptable" values are EQUAL values and that "unacceptable" values are UNEQUAL values. ** From ietf-ppp-request@ucdavis.ucdavis.edu Tue Nov 19 10:33:59 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA01171; Tue, 19 Nov 91 10:16:58 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from LOBSTER.WELLFLEET.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA01004; Tue, 19 Nov 91 10:10:56 -0800 Received: from js.Wellfleet.Com ([192.32.1.186]) by lobster.wellfleet.com (4.1/SMI-4.1) id AA17058; Tue, 19 Nov 91 13:07:16 EST Received: by js.Wellfleet.Com (3.2/SMI-3.2) id AA00174; Tue, 19 Nov 91 13:06:43 EST Date: Tue, 19 Nov 91 13:06:43 EST From: Bill Allocca Message-Id: <9111191806.AA00174@js.Wellfleet.Com> To: ietf-ppp@ucdavis.edu Subject: PPP Control Protocols Cc: wallocca@wellfleet.com Which of the Control Protocols (other than IPCP) have been defined over PPP, and where can I obtain draft copies of the documents describing those Control Protocols? Thank-you. William Allocca Wellfleet Communications, Inc. Phone: (617) 275-7750 x397 Fax: (617) 275-5001 Mail: wallocca@wellfleet.com From ietf-ppp-request@ucdavis.ucdavis.edu Tue Nov 19 22:18:27 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA20429; Tue, 19 Nov 91 22:00:22 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA20231; Tue, 19 Nov 91 21:51:05 -0800 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA15651; Wed, 20 Nov 91 00:50:02 -0500 Received: from um.cc.umich.edu by mailrus.cc.umich.edu (5.61/1123-1.0) id AA13392; Tue, 19 Nov 91 14:29:04 -0500 Received: from merit.edu by um.cc.umich.edu via Internet with TCP; Tue, 19 Nov 91 14:29:03 EST Return-Path: Received: from venera.isi.edu by merit.edu (5.65/1123-1.0) id AA26719; Tue, 19 Nov 91 14:28:54 -0500 Received: by venera.isi.edu (5.61/5.65+local-1) id ; Tue, 19 Nov 91 07:48:55 -0800 Received: from NRI.RESTON.VA.US by venera.isi.edu (5.61/5.65+local-1) id ; Tue, 19 Nov 91 07:48:52 -0800 Received: from NRI.NRI.Reston.Va.US by NRI.NRI.Reston.VA.US id aa09979; 19 Nov 91 10:42 EST To: IETF From: Internet-Drafts@nri.reston.va.us Subject: ID ACTION:draft-ietf-ppp-multidatagrams-03.txt Date: Tue, 19 Nov 91 10:42:57 -0500 Message-Id: <9111191043.aa09979@NRI.NRI.Reston.VA.US> 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 Working Group of the IETF. Title : The Point-to-Point Protocol (PPP): A Proposed Standard for the Transmission of Multi-Protocol Datagrams Over Point-to-Point Links Author(s) : W. A. Simpson Filename : draft-ietf-ppp-multidatagrams-03.txt Pages : 76 The Point-to-Point Protocol (PPP) provides a method for transmitting datagrams over serial point-to-point links. This document defines the PPP encapsulation scheme, together with the PPP Link Control Protocol (LCP), an extensible option negotiation protocol which is able to negotiate a rich assortment of configuration parameters and provides additional management functions. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-ppp-multidatagrams-03.txt". Internet-Drafts directories are located at: o East Coast (US) Address: nnsc.nsf.net (128.89.1.178) o West Coast (US) Address: ftp.nisc.sri.com (192.33.33.22) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mail-server@nisc.sri.com. In the body type: "SEND internet-drafts/draft-ietf-ppp-multidatagrams-03.txt". For questions, please mail to internet-drafts@nri.reston.va.us. From ietf-ppp-request@ucdavis.ucdavis.edu Wed Nov 20 11:57:30 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA08874; Wed, 20 Nov 91 11:20:32 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ftp.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA08610; Wed, 20 Nov 91 11:14:25 -0800 Received: from gordon.128.165.199.6 by ftp.com via PCMAIL with DMSP id AA06691; Wed, 20 Nov 91 14:15:26 -0500 Date: Wed, 20 Nov 91 14:15:26 -0500 Message-Id: <9111201915.AA06691@ftp.com> To: Internet-Drafts@nri.reston.va.us Subject: Re: ID ACTION:draft-ietf-ppp-multidatagrams-03.txt From: gordon@ftp.com (Gordon Lee) Cc: ietf-ppp@ucdavis.edu Repository: babyoil.ftp.com Originating-Client: 128.165.199.6 > From: Internet-Drafts@nri.reston.va.us > Subject: ID ACTION:draft-ietf-ppp-multidatagrams-03.txt > > Internet-Drafts directories are located at: > > o East Coast (US) > Address: nnsc.nsf.net (128.89.1.178) On this machine, the ppp draft mentioned above is truncated. > o West Coast (US) > Address: ftp.nisc.sri.com (192.33.33.22) On this machine the ppp draft has no read permission > o Pacific Rim > Address: munnari.oz.au (128.250.1.21) On this machine the draft was just right ! :-) - GL (GoldiLocks) PS. can't speak for nic.nordu.net -- }} Gordon Lee voice: (617) 246-0900 fax: (617) 245-7943 }} FTP Software 26 Princess St Wakefield, MA 01880 From ietf-ppp-request@ucdavis.ucdavis.edu Wed Nov 20 12:45:12 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA10553; Wed, 20 Nov 91 12:16:39 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from NRI.RESTON.VA.US by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA10045; Wed, 20 Nov 91 12:00:09 -0800 Received: from NRI.NRI.Reston.Va.US by NRI.NRI.Reston.VA.US id aa16072; 20 Nov 91 14:52 EST To: gordon@ftp.com Cc: Internet-Drafts@NRI.Reston.VA.US, ietf-ppp@ucdavis.edu, cclark@NRI.Reston.VA.US Subject: Re: ID ACTION:draft-ietf-ppp-multidatagrams-03.txt In-Reply-To: Your message of "Wed, 20 Nov 91 14:15:26 EST." <9111201915.AA06691@ftp.com> Date: Wed, 20 Nov 91 14:52:10 -0500 From: Cynthia Clark Message-Id: <9111201452.aa16072@NRI.NRI.Reston.VA.US> Hi Gordon Lee, Thank you for informing me. I have already fixed this. I sincerely hope this will not happen again. I was going to forward you a copy of the draft as a courtesy, but it seem that you already got a copy. If you have any problem, please do not hesitate to contact me anytime. Thanks, Cynthia Clark, IETF Mailing List Coordinator Corporation for National Research Initiatives 1895 Preston White Drive Suite 100 Reston, VA 22091 ------------ Forwarded Message ------------------ > From: Internet-Drafts@nri.reston.va.us > Subject: ID ACTION:draft-ietf-ppp-multidatagrams-03.txt > > Internet-Drafts directories are located at: > > o East Coast (US) > Address: nnsc.nsf.net (128.89.1.178) On this machine, the ppp draft mentioned above is truncated. > o West Coast (US) > Address: ftp.nisc.sri.com (192.33.33.22) On this machine the ppp draft has no read permission > o Pacific Rim > Address: munnari.oz.au (128.250.1.21) On this machine the draft was just right ! :-) - GL (GoldiLocks) PS. can't speak for nic.nordu.net -- }} Gordon Lee voice: (617) 246-0900 fax: (617) 245-7943 }} FTP Software 26 Princess St Wakefield, MA 01880 From ietf-ppp-request@ucdavis.ucdavis.edu Wed Nov 20 13:50:18 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA13022; Wed, 20 Nov 91 13:35:04 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from NRI.RESTON.VA.US by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA12602; Wed, 20 Nov 91 13:22:09 -0800 Received: from NRI.NRI.Reston.Va.US by NRI.NRI.Reston.VA.US id aa18467; 20 Nov 91 16:16 EST To: Bob Sutterfield Cc: gordon@ftp.com, Internet-Drafts@NRI.Reston.VA.US, ietf-ppp@ucdavis.edu, cclark@NRI.Reston.VA.US Subject: Re: ID ACTION:draft-ietf-ppp-multidatagrams-03.txt In-Reply-To: Your message of "Wed, 20 Nov 91 16:02:08 EST." <9111202102.AA06934@volitans.morningstar.com> Date: Wed, 20 Nov 91 16:16:05 -0500 From: Cynthia Clark Message-Id: <9111201616.aa18467@NRI.NRI.Reston.VA.US> Bob, I am sorry that I do not understand.... Are you asking or just implying ? Cynthia ---------------- Forwarded Message --------------------- Received: from volitans.morningstar.com by NRI.NRI.Reston.VA.US id aa18158; 20 Nov 91 16:03 EST Received: by volitans.morningstar.com (5.65a/91111501) id AA06934; Wed, 20 Nov 91 16:02:08 -0500 Date: Wed, 20 Nov 91 16:02:08 -0500 From: Bob Sutterfield Message-Id: <9111202102.AA06934@volitans.morningstar.com> To: gordon@ftp.com Cc: Internet-Drafts@NRI.Reston.VA.US, ietf-ppp@ucdavis.edu In-Reply-To: (Gordon Lee's message of Wed, 20 Nov 91 14:15:26 -0500 <9111201915.AA06691@ftp.com> Subject: ID ACTION:draft-ietf-ppp-multidatagrams-03.txt It seems to be readable and full-size on nic.ddn.mil:internet-drafts/ -rw-rw-rw- 1 gvaudre nri 151848 Nov 19 05:34 draft-ietf-ppp-multidatagrams-03.txt Now, if I can just get some packets from them... From ietf-ppp-request@ucdavis.ucdavis.edu Thu Nov 21 08:52:06 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA09329; Thu, 21 Nov 91 08:31:39 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA08888; Thu, 21 Nov 91 08:17:19 -0800 Received: by Angband.Stanford.EDU (5.65/inc-1.0) id AA07931; Thu, 21 Nov 91 08:15:41 -0800 Date: Thu, 21 Nov 91 08:15:41 -0800 From: brian@Angband.Stanford.EDU (Brian Lloyd) Message-Id: <9111211615.AA07931@Angband.Stanford.EDU> To: ietf-ppp@ucdavis.edu, mdavies@nri.reston.va.us Cc: eric@telebit.com, dnmrt@interlan.com, dean@sun2.retix.com, ccox@wnyose.nctsw.navy.mil, csn@3com.com, rrj@3com.com, sgw@sgw.xyplex.com, townsend@xylogics.com, schaefer@davidsys.com, crepea@cisco.com, natadm!ycw@uunet.uu.net, holly@apple.com, morgan@jessica.stanford.edu, stevea@i88.isc.com Subject: minutes of PPPWG meeting Date: Nov. 20, 1991 Chair: Brian Lloyd Scribe: Michele Wright PPPEXT Minutes: Brian Lloyd welcomed the group, asked for sign-in and a short discussion on mailing list, ppp archive availability and history of PPP working group was held. Also Brian discussed current status and current implementations of PPP. Bill Simpson reported that SAAG has reviewed the PPP authentication draft document. The result is that the message digest algorithm used in the Challenge Handshake Authentication Protocol (CHAP) may be either MD4 or MD5. The document is being changed to support this. The default algorithm will be the same as that chosen by the SNMP working group for SNMP authentication. [MD5 was chosen]. Brian Lloyd reported on the IPLDN discussion on frame relay, X.25 and PPP over the same physical interface. They decided to use XID to distinguish which protocol will run on the link. Brad Parker of Cayman gave a synopsis of the work on PPP in the Appletalk WG. Apple has chosen to use PPP instead of a proprietary point-to-point protocol, thus paving the way for both IP and Appletalk on the same serial interface. The result is a document that is ready for review by the PPP WG. Two implementations are available. Brad has partially completed work on the drivers and [name] at the University of Michican is planning on continuing the effort. Phil Almquist presented the comments on the PPP requirements portion of the Router Requirements document. The members of the RR WG objected to listing line speeds above which VJ header compression should not be used. The result was that the recommendation from the PPPEXT WG was changed to read that VJ header compression should be used below 20Kbps and may be used at any speed above that. The upper bound above which VJ header compression should not be used, previously set at 64Kbps, was removed. Phil also reported that there were objections by the members of the RR WG to the requirement for Link Quality Monitoring (LQM). This led into a discussion of LQM. The issue was also raised that some of the vendors wish to do other forms of proprietary LQM. One of the problems with the existing LQM is that it is considered to be part of the LCP and hence must use an async control character map (ACCM) of all 1's. This just about doubles the size of an LQM packet on an async link. As a result the LCP document will be modified to support a slightly different LQM negotiation that can support multiple types of LQM. If an implementation supports LQM at all, it must support the existing type of LQM so that there will be a common denominator (analogy to MIB-1 and MIB-2 of SNMP). As a result of the LQM problem the group decided that all Link Control Protocol (LCP) packet/option codes less than or equal to seven that are needed to bring the LCP to the open state must be escaped using the all-ones ACCM. After the link is open the other options, i.e. authentication, new LQM, etc., may be transmitted using the negotiated ACCM and compression options even though these packets are ostensibly LCP packets. There is a problem that occurs when the LCP goes to the open state and a frame that has the ACCM set to zero (control characters not escaped) arrives at the receiver before the receiver has updated its ACCM and changed to the open state (this often occurs when the first NCP packet immediately follows the last LCP ack). The NCP frame is discarded at the receiver. There was a suggestion to insert a delay to allow the receiver to get to the open state before sending the NCP packet. It was noted that this is not a serious problem because the standard error recovery sequence properly deals with this. It was decided not to make a change in the state machine and to add an implementation note describing the problem. There was concern about the length of time that it can take to determine that a link has failed (10 retries with 3 seconds between retries). The final decision was to make it clear that the 3 second delay may be adjusted to accomodate links with lower latency, i.e., that high speed link interfaces timeout values should be smaller. This information will be added to the LCP document and the default timeout value will become part of the PPP MIB. Glenn McGregor presented his IPCP document and discussed the changes to Van Jacobson header compression as used in PPP. Now, the slot number -- which is used to identify a particular session being compressed -- is not compressed. This greatly improves error recovery if a packet is lost or damaged in transit. PPP Minutes PM Session: IP Address discussion continued. The WG decided to remove the feature for negotiating/reporting multiple IP addresses on an interface. In addition the WG decided that the IP address negotiation procedure was too complicated to ensure that it worked properly. The group decided on a much simpler scheme that retains all the features of the earlier version without the complexity. The IPCP document will contain a description of the old method along with a strong note indicating that implementations should use the new IP address negotiation procedure. And that the old IP address negotiation will be eliminated sometime in the not-too-distant future as the IPCP document proceeds down the standards track. Bill Simpson and Brian Lloyd presented the Authentication Document. The section on management of secrets (keys) has a hole due to the lack of availability of a secure mechanism for the dissemination of the "secret". This will be gated by the work on Common Authentication Technology (CAT) and on SNMP secret dissemination technology. Also the CHAP will change the way it uses MD5 to generate the authentication "signature" so as to be 100% compatible with SNMP. This should allow the core authentication procedures to be completely interchangable between PPP and SNMP. The discussion then proceeded to the call-back field of CHAP. The purpose of this field is for one end or the other to indicate to the peer that it wishes to terminate the link and call-back, primarily for purposes of reversing charges (some indicated that call-back may prove useful for enhancing security). Several people indicated that multiple call-back destinations may be desirable so a call-back address (phone number) field was defined and added. Marty Del Vecchio from Shiva Corp presented proposed Netware IPX Control Protocol which he has implemented. The group suggested a number of changes and improvements. Marty will do further research and present an improved document soon. Other documents were discussed. It was noted that 3Com has implemented stripped down versions of most of the NCPs. There was nothing to report on CLNP/OSI over PPP. Appletalk over PPP is very close to completion. Michele Wright of Timplex will take over DECnet over PPP doc. Several of the implementors present indicated that they are actively working on an implementation of PPP that supports DECnet. The topic of conversation then moved on to switched circuit (dial-up, ISDN, etc.) connection techniques. A discussion then ensued about techniques for automatically starting PPP during a login process. It was noted that the first PPP frame on an async link consists of the octet sequence '7e ff 7d 03'. This makes it possible for a terminal server or host to recognize that the peer wishes to run PPP and may start PPP immediately. The discussion also went back to PPP over ISDN. The XID technique for determining which protocol would run, e.g., PPP, frame relay, or X.25, was discussed again. The discussion then proceeded to the topic of inverse multiplexing, e.g., using multiple PPP links to simulate a single link/interface with greater bandwidth. There is a need to add a mechanism to indicate to the remote peer that one end or the other needs to increase capacity and will be opening an additional link. It was suggested that the new link need only open the LCP and authenticate, and there is no need to renegotiate the NCPs. The magic number that is negotiated on a link could be used as a logical connection number and can be made unique across all of the logical PPP connections, e.g., all physical connections that are part of a single logical interface will use the same magic number. Results and Decisions: The group decided to move the status of the LCP document back to "proposed" because of the changes to LQM. The group decided to move the status of the IPCP document back to "proposed" status because of the desired changes to the IP address negotiation. The group decided to keep the status of the Authentication document at "proposed" status due to the changes in the CHAP. From ietf-ppp-request@ucdavis.ucdavis.edu Fri Nov 22 06:45:47 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA11948; Fri, 22 Nov 91 06:30:42 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from TIS.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA11692; Fri, 22 Nov 91 06:23:40 -0800 Received: from TIS.COM by TIS.COM (4.1/SUN-5.64) id AA19573; Fri, 22 Nov 91 09:22:51 EST Message-Id: <9111221422.AA19573@TIS.COM> To: brian@angband.stanford.edu (Brian Lloyd) Cc: ietf-ppp@ucdavis.edu, eric@telebit.com, dnmrt@interlan.com, dean@sun2.retix.com, ccox@wnyose.nctsw.navy.mil, csn@3com.com, rrj@3com.com, sgw@sgw.xyplex.com, townsend@xylogics.com, schaefer@davidsys.com, crepea@cisco.com, natadm!ycw@uunet.uu.net, holly@apple.com, morgan@jessica.stanford.edu, stevea@i88.isc.com Subject: Re: minutes of PPPWG meeting In-Reply-To: Your message of Thu, 21 Nov 91 08:15:41 PST. <9111211615.AA07931@Angband.Stanford.EDU> Date: Fri, 22 Nov 91 09:22:44 -0500 From: balenson@TIS.COM > The document is being changed to support this. The default > algorithm will be the same as that chosen by the SNMP working group for > SNMP authentication. [MD5 was chosen]. Brian- I still don't have all the news from the IETF meeting, so unless something was changed this past week, I understand that SNMP authentication will be using MD4 because it's a bit faster than MD5. -DB From ietf-ppp-request@ucdavis.ucdavis.edu Fri Nov 22 09:55:08 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA16828; Fri, 22 Nov 91 09:16:43 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [192.124.48.2] by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA16356; Fri, 22 Nov 91 09:03:58 -0800 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA00453; Fri, 22 Nov 91 09:01:59 PST Date: Fri, 22 Nov 91 09:01:59 PST From: brian@lloyd.com (Brian Lloyd) Message-Id: <9111221701.AA00453@ray.lloyd.com> To: balenson@TIS.COM Cc: ietf-ppp@ucdavis.edu In-Reply-To: balenson@TIS.COM's message of Fri, 22 Nov 91 09:22:44 -0500 <9111221422.AA19573@TIS.COM> Subject: minutes of PPPWG meeting THe SNMP working group decided that they would use MD5. We (PPP WG) decided that we would use whatever SNMP used. Therefore we are going to specify the use of MD5 as the message digest algorithm for CHAP. Brian Lloyd, WB6RQN Lloyd and Associates Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392 From ietf-ppp-request@ucdavis.ucdavis.edu Tue Nov 26 08:47:46 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA25574; Tue, 26 Nov 91 08:30:37 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA25124; Tue, 26 Nov 91 08:16:04 -0800 Received: by aggie.ucdavis.edu (5.61/UCD2.03) id AA06396; Tue, 26 Nov 91 08:08:52 -0800 Date: Tue, 26 Nov 91 08:08:52 -0800 Message-Id: <9111261608.AA06396@aggie.ucdavis.edu> To: ietf-ppp@aggie.ucdavis.edu Subject: Re: minutes of PPPWG meeting From: stev@ftp.com (stev knowles) Repository: babyoil.ftp.com Originating-Client: d-cell.ftp.com i'll tell you folks what i told the SNMP security boyz. if you dont tell people who to export the code with MD5 in it, there are people (like ftp) who will not implement it. it will require too much overhead to find out what is going on with exporting it, and we dont have the resources to keep and police two packages. From ietf-ppp-request@ucdavis.ucdavis.edu Tue Nov 26 09:48:03 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA27260; Tue, 26 Nov 91 09:31:04 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from interlan.InterLan.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA26712; Tue, 26 Nov 91 09:15:41 -0800 Received: by interlan.interlan.com (5.65/1.35) id AA21010; Tue, 26 Nov 91 12:16:48 -0500 Date: Tue, 26 Nov 91 12:16:48 -0500 From: curran@interlan.interlan.com (Richard Curran) Message-Id: <9111261716.AA21010@interlan.interlan.com> To: ietf-ppp@ucdavis.edu Subject: PPP Terminate Connection Question What is the proper way to "kill" a PPP connection? In some instances, our implementation would like to "abort" (abort meaning that no acknowledgement is expected) the connection rather than "close" the connection by sending a "terminate-request" which would require waiting for the "terminate-ack" response. Is it sufficient to send an unelicited "terminate-ack", which would indicate to the receiver that the sender is in the "Closed" or "Listen" state (pg. 32 of the PPP RFC draft, November 1991) or should the "abort" scenario be treated as a "physical line down" which would require only local actions? Thanks, Rich Curran Racal Datacom Boxborough, MA 01719 508 - 263 - 9929 x374 curran@interlan.interlan.com From ietf-ppp-request@ucdavis.ucdavis.edu Tue Nov 26 23:06:59 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA17890; Tue, 26 Nov 91 22:45:27 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from wolf.cisco.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA17786; Tue, 26 Nov 91 22:43:27 -0800 Received: from lager.cisco.com by wolf.cisco.com with TCP; Tue, 26 Nov 91 22:41:05 -0800 Message-Id: <9111270641.AA09709@wolf.cisco.com> To: stev@ftp.com (stev knowles) Cc: ietf-ppp@ucdavis.edu Subject: Re: minutes of PPPWG meeting In-Reply-To: Your message of "Tue, 26 Nov 91 08:08:52 PST." <9111261608.AA06396@aggie.ucdavis.edu> Date: Tue, 26 Nov 91 22:42:13 PST From: Jim Forster >> i'll tell you folks what i told the SNMP security boyz. if you dont tell >> people who to export the code with MD5 in it, there are people (like ftp) >> who will not implement it. it will require too much overhead to find out >> what is going on with exporting it, and we dont have the resources to >> keep and police two packages. I actually read the August and September versions of the Federal Regulations on the export of Bridges, Routers, and Encryption. I certainly could have missed something, but my reading is that anything cryptographic places it into the same category. I didn't see any distinction for DES, non-DES, etc. There is, however, a specific exception when the encyrption is for password type applications when it cannot be used to to encrypt arbitrary data. CHAP would fit into this category. So as I read it, CHAP with MD5 should be fairly easy to export, but obviously not as easy as PAP. If anyone can confirm or refute this I'd be interested in hearing more. -- Jim From ietf-ppp-request@ucdavis.ucdavis.edu Wed Nov 27 00:47:29 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA20487; Wed, 27 Nov 91 00:30:29 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SGI.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA20192; Wed, 27 Nov 91 00:20:42 -0800 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (911016.SGI/910110.SGI) for ietf-ppp@ucdavis.edu id AA11516; Wed, 27 Nov 91 00:19:36 -0800 Received: by rhyolite.wpd.sgi.com (911016.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@ucdavis.edu id AA07825; Wed, 27 Nov 91 00:19:35 -0800 Date: Wed, 27 Nov 91 00:19:35 -0800 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9111270819.AA07825@rhyolite.wpd.sgi.com> To: ietf-ppp@ucdavis.edu Subject: Re: minutes of PPPWG meeting Aren't the new COCOM restrictions on "datagrams" and "adaptive routing" more troublesome than the encryption restrictions? I have the impression (having spent only an hour or so talking to DOC and SGI's export control warriors) that PPP is an intended target of those new restrictions, if they could only figure a way to discover it is not already free and widely available. Vernon Schryver, vjs@sgi.com From ietf-ppp-request@ucdavis.ucdavis.edu Wed Nov 27 19:16:08 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA17910; Wed, 27 Nov 91 19:00:30 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA17669; Wed, 27 Nov 91 18:53:21 -0800 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA07868; Wed, 27 Nov 91 21:51:57 -0500 From: bsimpson@vela.acs.oakland.edu (Bill Simpson) Message-Id: <9111280251.AA07868@vela.acs.oakland.edu> Subject: Re: minutes of PPPWG meeting To: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Date: Wed, 27 Nov 91 21:51:55 EST Cc: ietf-ppp@ucdavis.edu In-Reply-To: <9111270819.AA07825@rhyolite.wpd.sgi.com>; from "Vernon Schryver" at Nov 27, 91 12:19 am X-Mailer: ELM [version 2.3 PL11] > I have the impression (having spent only an hour or so talking to DOC and > SGI's export control warriors) that PPP is an intended target of those new > restrictions, if they could only figure a way to discover it is not already > free and widely available. > > > Vernon Schryver, vjs@sgi.com > PPP is both free, and widely available. I have put a source version into the public domain, and have ascertained that there are versions running in Finland and Australia (and anyone running KA9Q in dozens of countries). So <*> on them! Please pass this along at your earliest convenience.... Bill Simpson From ietf-ppp-request@ucdavis.ucdavis.edu Wed Nov 27 19:45:35 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA18516; Wed, 27 Nov 91 19:30:33 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA18319; Wed, 27 Nov 91 19:20:48 -0800 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA08785; Wed, 27 Nov 91 22:19:40 -0500 From: bsimpson@vela.acs.oakland.edu (Bill Simpson) Message-Id: <9111280319.AA08785@vela.acs.oakland.edu> Subject: New FSA To: ietf-ppp@ucdavis.edu Date: Wed, 27 Nov 91 22:19:39 EST X-Mailer: ELM [version 2.3 PL11] Here is the revised FSA which was requested at the IETF! My original mandate, a year ago, was to fix the FSA with as few changes as possible, so that we could go to the next standard step. Now that we have decided to stay at the same step, we can make the standard as *clear* as possible. This FSA answers almost all of the questions I have ever been asked about implementing PPP. I have tried to answer them with cookbooks, with Notes, with more text, etc. We still had multiple interpretations of the semantics. This FSA is *almost* the same as the previous non-deterministic FSA. There is ONE, and *only* one, packet change (which translates to 4 additions in the new FSA). Whoever can figure it out will gain the honor of this list, and be added to the acknowlegements section. Send your guesses directly to the list. I want *open* discussion, particularly from those who did not attend the IETF meeting. Happy holiday. Bill Simpson ========================================================================= .nf Events Actions AO = Active-Open - = illegal event PO = Passive-Open C = Close TO+ = Timeout with counter > 0 zrc = zero restart counter TO- = Timeout with counter expired U = Lower-Layer-Up D = Lower-Layer-Down RCR+ = Receive-Configure-Request (Good) scr = Send Configure-Request RCR- = Receive-Configure-Request (Bad) RCA = Receive-Configure-Ack sca = Send Configure-Ack RCN = Receive-Configure-Nak/Rej scn = Send Configure-Nak/Rej RTR = Receive-Terminate-Request str = Send Terminate-Request RTA = Receive-Terminate-Ack sta = Send Terminate-Ack RUC = Receive-Unknown-Code scj = Send-Code-Reject RCJ = Receive-Code-Reject RER = Receive-Echo-Request ser = Send-Echo-Reply .fi .RE .bp .Nh 2 State Transition Table .LP .RS The complete state transition table follows. Implementation should be done by consulting it rather than the state diagram. States are indicated horizontally, and events are read vertically. State transitions and actions are represented in the form action/new-state. Multiple actions are separated by commas, and may continue on succeeding lines as space requires. .LP .RS Historical Note: In previous versions of this table, a simplified non-deterministic finite-state automaton was used, with considerable detailed information specified in the semantics. This lead to interoperability problems from differing interpretations. This table functions nearly identically to the previous versions, with the up/down and active/passive flags expanded to explicit states. .RE .RE .LP .nf | State | 1 2 3 4 5 6 7 8 | Closed Opening Listening Closed Opening Listening Closing Resuming Events| Down Down Down Up Up Up Passive ------+------------------------------------------------------------------- AO | 2 2 2 scr/9 5 scr/9 scr/9 scr/9 PO | 3 3 3 6 6 6 8 8 C | 1 1 1 4 4 4 7 7 | U | 4 scr/9 6 - - - - - D | - - - 1 2 3 1 3 TO+ | - - - - - - str/7 str/8 TO- | - - - - - - 4 6 | RCR+ | - - - sta/4 scr, scr, 7 scr, | sca/13 sca/14 sca/14 RCR- | - - - sta/4 scr, scr, 7 scr, | scn/9 scn/10 scn/10 RCA | - - - sta/4 sta/5 sta/6 7 sta/8 RCN | - - - sta/4 sta/5 sta/6 7 sta/8 | RTR | - - - sta/4 sta/5 sta/6 sta/7 sta/8 RTA | - - - 4 5 6 4 6 | RUC | - - - scj/4 scj/5 scj/6 scj/7 scj/8 RCJ | - - - 4 5 6 4 6 | RER | - - - 4 5 6 7 8 .fi .bp .nf | State | 9 10 11 12 13 14 15 16 | Req-Sent Req-Sent Ack-Rcvd Ack-Rcvd Ack-Sent Ack-Sent Opened Opened Events| Active Passive Active Passive Active Passive Active Passive ------+--------------------------------------------------------------------- AO | 9 9 11 11 13 13 15 15 PO | 10 10 12 12 14 14 16 16 C | zrc/7 zrc/7 zrc/7 zrc/7 str/7 str/7 str/7 str/7 | U | - - - - - - - - D | 2 3 2 3 2 3 2 3 TO+ | scr/9 scr/10 scr/9 scr/10 scr/9 scr/10 - - TO- | 5 6 5 6 5 6 - - | RCR+ | sca/13 sca/14 sca/15 sca/16 sca/13 sca/14 scr, scr, | sca/13 sca/14 RCR- | scn/9 scn/10 scn/11 scn/12 scn/9 scn/10 scr, scr, | scn/9 scn/10 RCA | 11 12 scr/9 scr/10 15 16 scr/9 scr/10 RCN | scr/9 scr/10 scr/9 scr/10 scr/13 scr/14 scr/9 scr/10 | RTR | sta/9 sta/10 sta/9 sta/10 sta/9 sta/10 sta/5 sta/6 RTA | 9 10 9 10 9 10 scr/9 scr/10 | RUC | scj/5 scj/6 scj/5 scj/6 scj/5 scj/6 scj/5 scj/6 RCJ | 5 6 5 6 5 6 5 6 | RER | 9 10 11 12 13 14 ser/15 ser/16 .fi .LP .RS The states in which the Timer is running are identifiable by the presence of TO events. Only the Send-Configure-Request and Send-Terminate-Request events start or re-start the Timer. The Timer SHOULD be stopped when transitioning from any state where the Timer is running to a state where the Timer is not running. .RE From ietf-ppp-request@ucdavis.ucdavis.edu Wed Nov 27 20:30:46 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA19157; Wed, 27 Nov 91 20:15:28 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SGI.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA18870; Wed, 27 Nov 91 20:00:07 -0800 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (911016.SGI/910110.SGI) for ietf-ppp@ucdavis.edu id AA29545; Wed, 27 Nov 91 19:59:00 -0800 Received: by rhyolite.wpd.sgi.com (911016.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@ucdavis.edu id AA09956; Wed, 27 Nov 91 19:58:58 -0800 Date: Wed, 27 Nov 91 19:58:58 -0800 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9111280358.AA09956@rhyolite.wpd.sgi.com> To: ietf-ppp@ucdavis.edu Subject: Re: minutes of PPPWG meeting > > I have the impression (having spent only an hour or so talking to DOC and > > SGI's export control warriors) that PPP is an intended target of those new > > restrictions, if they could only figure a way to discover it is not already > > free and widely available. > > > > Vernon Schryver, vjs@sgi.com > PPP is both free, and widely available. I have put a source version into > the public domain, and have ascertained that there are versions running > in Finland and Australia (and anyone running KA9Q in dozens of countries). > > So <*> on them! Please pass this along at your earliest convenience.... > > Bill Simpson If you care, please help. Several vendors have been working on this for some time. It's sillier than the DES stuff. The Dept. of Comm. is trying to get the regulations interpreted to exempt anything that is bit-for-bit identical with 4.3BSD. Otherwise, you must remove routed and several other things from your product if sent to certain destinations, such as the People's Republic of China. I do not think the Dept. of Comm is not doing anyone a favor. No one's 4.3BSD networking code is exactly identical with 4.3BSD. Which 4.3BSD? Reno, tahoe, network, network-2? At one point I understood they were saying it would be ok to ship BSD source for routed, but not objects, because the objects would be "modified" from the source. If the Dept. of Comm does make some form of a BSD exemption work, it may make it easier for some vendors to fill current orders, but it also makes the regulations reasonable to the so called minds of the beltway-. I and many others have chanted the mantra "BSD KA9Q BSD FTP uunet KA9Q PPP BSD FTP uunet CSRG-tapes KA9Q" but it's going to require something stronger. Vernon Schryver, vjs@sgi.com From ietf-ppp-request@ucdavis.ucdavis.edu Thu Nov 28 02:15:41 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA26080; Thu, 28 Nov 91 02:00:22 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from enet-gw.pa.dec.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA25702; Thu, 28 Nov 91 01:35:53 -0800 Received: by enet-gw.pa.dec.com; id AA11317; Thu, 28 Nov 91 01:34:43 -0800 Message-Id: <9111280934.AA11317@enet-gw.pa.dec.com> Received: from marvin.enet; by decwrl.enet; Thu, 28 Nov 91 01:34:46 PST Date: Thu, 28 Nov 91 01:34:46 PST From: SEMPER INFACEBO SUMUS - SOLE PROFUNDUM VARIAT 28-Nov-1991 0934 To: ietf-ppp@ucdavis.edu Apparently-To: ietf-ppp@ucdavis.edu Subject: PPP Finite State Automoton Hmmmmm. Very interesting. It would appear that the inclusion of the Passive Open event just about doubles the complexity of the FSA. I'm sure that there was a (very good?) historical reason why PPP needs a Passive Open but at the moment it completely escapes me. Does anyone out there know why PPP really does have to have a Passive Open. We've managed to implement HDLC PtP stuff without the concept of a Passive Open. All comments would be most welcome. Dean Morris - DEC Corporate Backbone Networks Group. From ietf-ppp-request@ucdavis.ucdavis.edu Thu Nov 28 22:46:15 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA17241; Thu, 28 Nov 91 22:30:27 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [192.124.48.2] by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA17038; Thu, 28 Nov 91 22:22:41 -0800 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA00159; Thu, 28 Nov 91 22:19:06 PST Date: Thu, 28 Nov 91 22:19:06 PST From: brian@lloyd.com (Brian Lloyd) Message-Id: <9111290619.AA00159@ray.lloyd.com> To: forster@cisco.com Cc: stev@ftp.com, ietf-ppp@ucdavis.edu In-Reply-To: Jim Forster's message of Tue, 26 Nov 91 22:42:13 PST <9111270641.AA09709@wolf.cisco.com> Subject: minutes of PPPWG meeting There was significant discussion of the problems associated with exportation of crypto and authentication stuff. Seems that by making the code serve for authentication only you fall under the jurisdiction of Dept. of Commerce instead of Dept. of State for encryption devices. Rumor has it that DOC is much easier to do business with because its regs are more relaxed and it is relatively easy to get a blanket export license. Please remember that this is strictly second hand but I will get more info. Brian Lloyd, WB6RQN Lloyd and Associates Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392 From ietf-ppp-request@ucdavis.ucdavis.edu Fri Nov 29 09:15:12 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA27039; Fri, 29 Nov 91 09:01:41 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from gateway.bnr.ca by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA26927; Fri, 29 Nov 91 08:54:36 -0800 Received: from BNRECADA.BNR.CA by gateway.bnr.ca (5.61/1.34) id AA02968; Fri, 29 Nov 91 11:53:23 -0500 Message-Id: <9111291653.AA02968@gateway.bnr.ca> Received: from BNRECADA.BNR.CA by BNRECADA.BNR.CA (IBM VM SMTP R1.2.1) with BSMTP id 3509; Fri, 29 Nov 91 11:53:16 EST Date: 29 Nov 91 11:53:00 EST To: ietf-ppp@ucdavis.edu From: Gary (G.P.) Mussar Subject: 16/32 bit CRC Negotiation Quite a while ago there was an Internet-draft issued concerning a scheme using 48 bit CRCs which allow the creation of frames that could be correctly received by devices supporting either 16 bit CRCs or 32 bit CRCs. Has anyone already provide some code to implement this? Is anyone interested in some (I wrote a quick and dirty set of routines a few days ago). Gary ------------------------------------------------------------------------------- Gary Mussar |Internet: mussar@bnr.ca | Phone: (613) 763-4937 BNR Ltd. | | FAX: (613) 763-2626 From ietf-ppp-request@ucdavis.ucdavis.edu Fri Nov 29 12:15:35 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA00342; Fri, 29 Nov 91 12:00:24 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [192.124.48.2] by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA29974; Fri, 29 Nov 91 11:47:20 -0800 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA00271; Fri, 29 Nov 91 11:46:03 PST Date: Fri, 29 Nov 91 11:46:03 PST From: brian@lloyd.com (Brian Lloyd) Message-Id: <9111291946.AA00271@ray.lloyd.com> To: ietf-ppp@ucdavis.edu Cc: forster@cisco.com, stev@ftp.com Subject: Export issues I figured that this discussion about the legality of exporting authentication software was pointless until we had more info therefore Lloyd & Associates has retained a governmental consultant/specialist to deal with DOD, DOC, and State. He will be looking into the issues surrounding export of CHAP and to expedite creation of an export license for same. I will report back when I have further info. Brian Lloyd, WB6RQN Lloyd and Associates Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392 From ietf-ppp-request@ucdavis.ucdavis.edu Fri Nov 29 12:30:46 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA00374; Fri, 29 Nov 91 12:04:25 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [192.124.48.2] by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA00206; Fri, 29 Nov 91 11:53:23 -0800 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA00282; Fri, 29 Nov 91 11:51:47 PST Date: Fri, 29 Nov 91 11:51:47 PST From: brian@lloyd.com (Brian Lloyd) Message-Id: <9111291951.AA00282@ray.lloyd.com> To: MUSSAR@BNR.CA Cc: ietf-ppp@ucdavis.edu In-Reply-To: Gary (G.P.) Mussar's message of 29 Nov 91 11:53:00 EST <9111291653.AA02968@gateway.bnr.ca> Subject: 16/32 bit CRC Negotiation Sender: ietf-ppp-request@ucdavis.edu Date: 29 Nov 91 11:53:00 EST From: Gary (G.P.) Mussar Quite a while ago there was an Internet-draft issued concerning a scheme using 48 bit CRCs which allow the creation of frames that could be correctly received by devices supporting either 16 bit CRCs or 32 bit CRCs. Has anyone already provide some code to implement this? Is anyone interested in some (I wrote a quick and dirty set of routines a few days ago). Gary ------------------------------------------------------------------------------- Gary Mussar |Internet: mussar@bnr.ca | Phone: (613) 763-4937 BNR Ltd. | | FAX: (613) 763-2626 There was great discussion of this issue at the recent IETF meeting. Bottom line is that noone knew of an implementation anywhere. Brian Lloyd, WB6RQN Lloyd and Associates Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392 From ietf-ppp-request@ucdavis.ucdavis.edu Fri Nov 29 13:33:06 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA01409; Fri, 29 Nov 91 13:00:31 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from gateway.bnr.ca by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA01336; Fri, 29 Nov 91 12:59:54 -0800 Received: from BNRECADA.BNR.CA by gateway.bnr.ca (5.61/1.34) id AA24394; Fri, 29 Nov 91 15:58:36 -0500 Message-Id: <9111292058.AA24394@gateway.bnr.ca> Received: from BNRECADA.BNR.CA by BNRECADA.BNR.CA (IBM VM SMTP R1.2.1) with BSMTP id 3618; Fri, 29 Nov 91 15:58:30 EST Date: 29 Nov 91 15:58:00 EST To: Cc: brian@lloyd.com From: Gary (G.P.) Mussar Subject: re:16/32 bit CRC Negotiation In message "16/32 bit CRC Negotiation", >From: brian@lloyd.com (Brian Lloyd) >There was great discussion of this issue at the recent IETF meeting. >Bottom line is that noone knew of an implementation anywhere. I have some software that can generate the required data. It can (theoretically) run on 8, 16, 32 or 64 bit architectures that are either big endian or little endian. I have run it on my IBM-PC under Turbo-C and on my Sparc. Because I tried to accomodate a number of different architectur es, the code is not completely optimal, but... - it can be sped up for a given architecture - the code is only required for initial negotiation. I offer this code to anyone who wishes to play with it, or use it (or improve it :-). It isn't particularly large. Gary ------------------------------------------------------------------------------- Gary Mussar |Internet: mussar@bnr.ca | Phone: (613) 763-4937 BNR Ltd. | | FAX: (613) 763-2626 From ietf-ppp-request@ucdavis.ucdavis.edu Fri Nov 29 13:45:31 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA02137; Fri, 29 Nov 91 13:32:03 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA01867; Fri, 29 Nov 91 13:21:36 -0800 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA07858; Fri, 29 Nov 91 16:20:06 -0500 From: bsimpson@vela.acs.oakland.edu (Bill Simpson) Message-Id: <9111292120.AA07858@vela.acs.oakland.edu> Subject: Re: 16/32 bit CRC Negotiation To: MUSSAR@bnr.ca (Gary) Date: Fri, 29 Nov 91 16:20:04 EST Cc: ietf-ppp@ucdavis.edu In-Reply-To: <9111291653.AA02968@gateway.bnr.ca>; from "Gary" at Nov 29, 91 11:53 am X-Mailer: ELM [version 2.3 PL11] Several months ago, I issued a call for algorithms on this topic. If you write it up, I will pull it into the current draft, and give you first authorship. Thanks. There hasn't been a lot of interest in the topic, however. There doesn't seem to be hardware that requires 32 bit FCS, as yet. > > Quite a while ago there was an Internet-draft issued concerning > a scheme using 48 bit CRCs which allow the creation of frames > that could be correctly received by devices supporting either > 16 bit CRCs or 32 bit CRCs. Has anyone already provide some > code to implement this? Is anyone interested in some (I wrote > a quick and dirty set of routines a few days ago). > > Gary > ------------------------------------------------------------------------------- > Gary Mussar |Internet: mussar@bnr.ca | Phone: (613) 763-4937 > BNR Ltd. | | FAX: (613) 763-2626 > From ietf-ppp-request@ucdavis.ucdavis.edu Fri Nov 29 14:15:26 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA02651; Fri, 29 Nov 91 14:01:46 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA02325; Fri, 29 Nov 91 13:46:04 -0800 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA08572; Fri, 29 Nov 91 16:44:27 -0500 From: bsimpson@vela.acs.oakland.edu (Bill Simpson) Message-Id: <9111292144.AA08572@vela.acs.oakland.edu> Subject: re:16/32 bit CRC Negotiation To: MUSSAR@bnr.ca (Gary) Date: Fri, 29 Nov 91 16:44:26 EST Cc: ietf-ppp@ucdavis.edu, brian@lloyd.com In-Reply-To: <9111292058.AA24394@gateway.bnr.ca>; from "Gary" at Nov 29, 91 3:58 pm X-Mailer: ELM [version 2.3 PL11] Please put a copy of the software in merit.edu:pub/ppp/incoming. I'll add it to the 32-bit FCS draft sometime in the next couple of weeks. Bill Simpson From ietf-ppp-request@ucdavis.ucdavis.edu Sat Nov 30 18:12:19 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA00432; Sat, 30 Nov 91 17:47:30 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA00247; Sat, 30 Nov 91 17:41:26 -0800 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA17875; Sat, 30 Nov 91 19:43:13 -0500 From: bsimpson@vela.acs.oakland.edu (Bill Simpson) Message-Id: <9112010043.AA17875@vela.acs.oakland.edu> Subject: CFV: Passive Open To: ietf-ppp@ucdavis.edu Date: Sat, 30 Nov 91 19:43:12 EST X-Mailer: ELM [version 2.3 PL11] There has been a suggestion to eliminate the Passive Open from the FSA. This is a Call for Votes. Please send your vote to the list (unlike NetNews). If your vote is negative, it should include an explanation of why your implementation actually uses the Passive Open. Votes will be tabulated after 19:00 EST (16:00 PST) December 6th, 1991. Technical details: Analysis has shown that with the addition of a specific Up event, there is no longer a need for the Passive Open. If the implementation desires to delay the Active Open, the Up event is delayed instead. For example, if your implementation detects 0x7EFF at the login prompt to switch to PPP mode, the Up event would be sent to the PPP FSA at that time, rather than when carrier was initially detected. In the case where there is no Up event available (ie. because the link is a 3-wire line through a null modem), there will be no harm in sending configuration packets until the restart counter expires, and then listening for the other end (the Opening-Up state). This should be upwardly compatible with previous implementations, since an Active Open will be generated, triggering the Passive Open at the peer. Bill Simpson From ietf-ppp-request@ucdavis.ucdavis.edu Sat Nov 30 21:16:14 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA05096; Sat, 30 Nov 91 21:01:40 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [192.124.48.2] by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA04906; Sat, 30 Nov 91 20:45:33 -0800 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA02676; Sat, 30 Nov 91 20:43:15 PST Date: Sat, 30 Nov 91 20:43:15 PST From: brian@lloyd.com (Brian Lloyd) Message-Id: <9112010443.AA02676@ray.lloyd.com> To: bsimpson@vela.acs.oakland.edu Cc: ietf-ppp@ucdavis.edu In-Reply-To: Bill Simpson's message of Sat, 30 Nov 91 19:43:12 EST <9112010043.AA17875@vela.acs.oakland.edu> Subject: CFV: Passive Open Since the standard seems to be to always start with an AO, I would go with the change and eliminate the PO. Thumbs down on PO! Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392