From ietf-ppp-request@MERIT.EDU Wed May 3 04:28:53 1995 Received: (from slist@localhost) by merit.edu (8.6.10/merit-2.0) id EAA02650; Wed, 3 May 1995 04:28:53 -0400 Resent-Date: Wed, 3 May 1995 04:28:53 -0400 From: Gerry Meyer Date: Wed, 3 May 95 09:24:50 +0100 Message-Id: <28449.9505030824@orbweb.spider.co.uk> To: ietf-ppp@MERIT.EDU Subject: Re: woe is me--MP headers cannot be avoided Resent-Message-ID: <"kbpE33.0.1f.awpfl"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/466 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Vernon Schryver (vjs@sgi.com) wrote: >That's all just great, but I've found a problem that seems hard to >solve. When should MP headers be turned back on? A system that was >sending sequence-critical traffic (e.g. compressed packets) can turn >start using MP headers a suitable time before dialing to add a new >link, and things work fine. However, what happens if the peer does the >dialing? By the time you know that an incoming call belongs to an >existing bundle on which you've not not been using MP headers, it is at >least half an RTT too late. Not sending any traffic on the new link >until all of the non-MP encapsulated traffic on the old link has >reached the peer would work, but would also waste more bandwidth than >would be saved by not using MP headers. The problem is no different whether the remote or local end initiates the second call. - Link A is transmitting all frames without ML headers - Add link B to the bundle - The next packet (for an order-sensitive protocol) MUST be ML-encapsulated and MUST be sent on link A. Subsequent packets on both links are ML-encapsulated. (ie never send an order sensitive packet on link B until you have sent one on link A with an ML header). Using the 'expected' sequence number flushes link A and prevents anything on link B jumping the gun. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed May 3 09:29:01 1995 Received: (from slist@localhost) by merit.edu (8.6.10/merit-2.0) id JAA13274; Wed, 3 May 1995 09:29:01 -0400 Resent-Date: Wed, 3 May 1995 09:29:01 -0400 Date: Wed, 3 May 1995 07:28:19 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199505031328.HAA06743@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: woe is me--MP headers cannot be avoided Resent-Message-ID: <"T7xXY3.0.7F3.PKufl"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/467 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Gerry Meyer > >That's all just great, but I've found a problem that seems hard to > >solve. When should MP headers be turned back on? .... > The problem is no different whether the remote or local end initiates > the second call. > >- Link A is transmitting all frames without ML headers >- Add link B to the bundle >- The next packet (for an order-sensitive protocol) MUST be ML-encapsulated and > MUST be sent on link A. Subsequent packets on both links are ML-encapsulated. > > (ie never send an order sensitive packet on link B until you have sent > one on link A with an ML header). > > Using the 'expected' sequence number flushes link A and prevents > anything on link B jumping the gun. Oh. Yes, of course. thanks. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon May 8 15:24:29 1995 Received: (from slist@localhost) by merit.edu (8.6.10/merit-2.0) id PAA14300; Mon, 8 May 1995 15:24:29 -0400 Resent-Date: Mon, 8 May 1995 15:24:29 -0400 Date: Mon, 8 May 1995 15:22:52 -0400 From: John Gregg Message-Id: <199505081922.PAA11957@shiva.shiva.com> To: ietf-ppp@MERIT.EDU Subject: Questions about PPP over ISDN Resent-Message-ID: <"PcAjz3.0.wU3.l-chl"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/468 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I understand that at some point in the last couple of months some of these issues were covered here, but unfortunately I did not save the relevant postings. So at the risk of igniting something I might not want to ignite, I have a few questions upon reading RFC 1618, "PPP over ISDN". I have a box which talks PPP, either over async HDLC (for good old modems) and bit-sync HDLC (for CSU/DSUs, mostly). Let's assume for the moment that this box will be talking PPP to another, identical box. At some point, I get an ISDN line between my two boxes, and I buy a couple of terminal adapters. I unplug my old modems, and put the terminal adapters in their place, connecting them to the PPP boxes with the same DB25/RS232 cable I had been using to connect the modems. I set the TAs up to talk async out the DB25s (and to do V.110 async rate adaption). Since my boxes are used to dealing with modems, they already talk async. Everything works. By and by, I decide to go sync and stop wasting local bandwidth on start/stop bits, improve my throughput by not using V.110, etc. so I reconfigure my TAs to talk sync out the DB25 connectors unstead of async, and set my PPP boxes up to talk sync HDLC. Everything works. In both scenarios, my PPP boxes don't know or care about such things as: V.110, V.120, BONDING, NRZI (except on the local, i.e. non-ISDN side of the TA, I guess that's reference point R). In both cases my PPP boxes see an async pipe, just like in the old modem days, or a sync pipe, just like in the old CSU/DSU days. Why then, is V.110 deprecated? Why is V.120 deprecated in favor of PPP over Frame Relay? Why all the talk in the RFC about encoding, and automatic detection thereof using multiple Config Requests, different framings, etc.? I did not understand section 4, "Out-of-Band signaling" at all. Is there any other RFC which pertains to PPP which even mentions LLC-IE values? Am I missing the point of this RFC, or was it meant for implementing a much more tightly integrated PPP/ISDN, without actual TAs? Most importantly, has anyone out there implemented a PPP over ISDN according to RFC 1618? Thanks for any insight, -John Gregg Shiva Corp. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue May 9 17:50:01 1995 Received: (from slist@localhost) by merit.edu (8.6.10/merit-2.0) id RAA14350; Tue, 9 May 1995 17:50:01 -0400 Resent-Date: Tue, 9 May 1995 17:50:01 -0400 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; cc: ietf-ppp@MERIT.EDU From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-pppext-bsd-compress-03.txt Date: Tue, 09 May 95 17:37:24 -0400 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9505091737.aa10942@IETF.CNRI.Reston.VA.US> Resent-Message-ID: <"eUUDV1.0.wV3.ZD-hl"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/469 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Note: This revision reflects comments received during the last call period. Title : PPP BSD Compression Protocol Author(s) : V. Schryver Filename : draft-ietf-pppext-bsd-compress-03.txt Pages : 25 Date : 05/08/1995 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. The PPP Compression Control Protocol [2] provides a method to negotiate and utilize compression protocols over PPP encapsulated links. This document describes the use of the Unix Compress compression protocol for compressing 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-bsd-compress-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-bsd-compress-03.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-bsd-compress-03.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19950508130442.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-bsd-compress-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-bsd-compress-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950508130442.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed May 10 13:20:32 1995 Received: (from slist@localhost) by merit.edu (8.6.10/merit-2.0) id NAA28498; Wed, 10 May 1995 13:20:32 -0400 Resent-Date: Wed, 10 May 1995 13:20:32 -0400 Date: Wed, 10 May 95 12:40:28 EDT From: hhs@teleoscom.com (Chip Sharp 6424) Message-Id: <9505101640.AA12409@teleoscom.com> To: ietf-ppp@MERIT.EDU Subject: TIA Data Compression Draft Standard Resent-Message-ID: <"sA5hU1.0.du6.lMFil"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/470 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I just got a copy of a draft standard for ballot titled "Support for Terminal Adaption and Data Compression in Data Circuit-Terminating Equipment (DCE) with Provision for Negotiation of Parameters" This would be published as TIA/EIA-655 if it is passed. To quote Section 5.3 "Protocol Architecture" The protocols described in this standard combine the terminal adaption features of Recommendation V.12 with the multiplexing and negotiation features of the Internet Standard Point-to-Point protocol (PPP). The data compression formats and procedures are based on those specified in the PPP Compression Control Protocol (RFC CCP). This was produced by TIA subcommittee TR 30.1 and the number of the proposal is SP-3245. Has anyone on this list heard of this document or reviewed it? BTW, the specification actually puts a V.120-like Terminal Adaption inside the PPP packet. ======================================================================= Hascall H. ("Chip") Sharp Teleos Communications, Inc. Sr. Systems Engineer 2 Meridian Road Eatontown, NJ 07724 USA voice: +1 908 544 6424 fax: +1 908 544 9890 email: hhs@teleoscom.com ======================================================================== - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed May 10 15:34:00 1995 Received: (from slist@localhost) by merit.edu (8.6.10/merit-2.0) id PAA04303; Wed, 10 May 1995 15:34:00 -0400 Resent-Date: Wed, 10 May 1995 15:34:00 -0400 Date: Wed, 10 May 95 14:41:08 EDT From: hhs@teleoscom.com (Chip Sharp 6424) Message-Id: <9505101841.AA17433@teleoscom.com> To: ietf-ppp@MERIT.EDU In-Reply-To: Chip Sharp 6424's message of Wed, 10 May 95 12:40:28 EDT <9505101640.AA12409@teleoscom.com> Subject: Re: TIA Data Compression Draft Standard Resent-Message-ID: <"8saWv3.0.331.bKHil"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/471 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Item 1: I made a typo. In the original text I had V.12 instead of V.120. The following is correct: To quote Section 5.3 "Protocol Architecture" The protocols described in this standard combine the terminal adaption features of Recommendation V.120 with the multiplexing and negotiation features of the Internet Standard Point-to-Point protocol (PPP). The data compression formats and procedures are based on those specified in the PPP Compression Control Protocol (RFC CCP). Item 2: It is not even V.120. It is "based on" V.120. Item 3: I don't know anything about the production of this draft. I was hoping someone on the list might have heard of it or know something about it. I happen to be a voting member of TIA, but I don't attend all the subcommittee meetings. Item 4: FYI, the following is a rendition of the protocol layer structure: |[Transported Data Field |Hdr| TA sublayer (V.120') \ / \ / \ / |PID| Mux Info Field | Mux 2 PDU (PPP???) \ / \ / |DCP Hdr|[Seq Num]|[Data Field] |LCB| Data Compression (CCP) \ / \ / | PID | Mux Info Field | Mux 1 PDU (RFC 1661) \ / \ / |F|[A]|[C]| Data Link Info Field |FCS|F| Data Link Frame (RFC 1662/3) Item 5: This doesn't make sense to me either. ======================================================================= Hascall H. ("Chip") Sharp Teleos Communications, Inc. Sr. Systems Engineer 2 Meridian Road Eatontown, NJ 07724 USA voice: +1 908 544 6424 fax: +1 908 544 9890 email: hhs@teleoscom.com ======================================================================== - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue May 16 12:02:34 1995 Received: (from slist@localhost) by merit.edu (8.6.10/merit-2.0) id MAA02767; Tue, 16 May 1995 12:02:34 -0400 Resent-Date: Tue, 16 May 1995 12:02:34 -0400 Message-Id: <9505161600.AA00536@azure.rns.com> X-Sender: ken@azure.rns.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 16 May 1995 08:52:44 -0700 To: ietf-ppp@MERIT.EDU From: ken@RNS.COM (Ken Mueller) X-Mailer: Content-Length: 900 Resent-Message-ID: <"zBq9l2.0.wg.3oCkl"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU Subject: Unidentified subject! X-Mailing-List: archive/latest/472 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU i have a question about how CCP should encapsulate the protocol of a datagram being compressed. i have read through draft-ietf-pppext-compression-04.txt looking for the answer and it seems not to be dealt with. the question is, should you try to do protocol compression on the protocol field or not. i would guess that the original intent of the draft was to look at the LCP PFC option value and compress or not as negotiated. this won't work for compression above an MP bundle where you don't know which LCP to look at. in this case, should the protocol always be compressed if possible or never compressed? is there now a general rule that is not the draft? to summarize, i would like to know: 1) if not using MP, should we compress according to the negotiated PFC value. 2) if using MP and compressing above the bundle, what are the protocol compression rules? ken mueller ken@rns.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue May 16 13:47:47 1995 Received: (from slist@localhost) by merit.edu (8.6.10/merit-2.0) id NAA07055; Tue, 16 May 1995 13:47:47 -0400 Resent-Date: Tue, 16 May 1995 13:47:47 -0400 Date: Tue, 16 May 1995 11:46:14 -0600 Message-Id: <199505161746.LAA09810@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: CCP, protocol compression, and MP From: ken@RNS.COM (Ken Mueller) Resent-Message-ID: <"lG49m1.0.2k1._KEkl"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/473 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: ken@RNS.COM (Ken Mueller) > > i have a question about how CCP should encapsulate the protocol of a > datagram being compressed. i have read through > draft-ietf-pppext-compression-04.txt looking for the answer and it seems not > to be dealt with. I think the individual CCP compression scheme specifications deal with how the protocol numbers of the compressed packets should be handled. > the question is, should you try to do protocol compression on the protocol > field or not. i would guess that the original intent of the draft was to > look at the LCP PFC option value and compress or not as negotiated. this > won't work for compression above an MP bundle where you don't know which LCP > to look at. in this case, should the protocol always be compressed if > possible or never compressed? is there now a general rule that is not the > draft? > > to summarize, i would like to know: > > 1) if not using MP, should we compress according to the negotiated PFC value. > > 2) if using MP and compressing above the bundle, what are the protocol > compression rules? MP and CCP are entirely independent from each other and from LCP. They are at different layers of the onion. What each does with the protocol numbers it is in charge of is independent of what the others do with their protocol numbers. Consider MP and LCP. MP packets often have two protocol numbers. The outer protocol number is 0x3d (MP). Whether it is compressed or not depends entirely and only on whether LCP Protocol-Field was negotiated in LCP Configure-Requests. The inner protocol number is often 0x21 (IP). According to the MP rules, that number should always appear as one byte of 0x21 and not two bytes regardless of whether the outer 0x3d number is one byte or two. I think a robust implementation should be prepared to deal receiving protocol numbers of 1, 2 and even 3 bytes. You just keep grabbing and shifting bytes until you hit an odd byte, or give up in disgust. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue May 16 14:21:54 1995 Received: (from slist@localhost) by merit.edu (8.6.10/merit-2.0) id OAA08887; Tue, 16 May 1995 14:21:54 -0400 Resent-Date: Tue, 16 May 1995 14:21:54 -0400 Message-Id: <9505161819.AA01656@azure.rns.com> X-Sender: ken@azure.rns.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 16 May 1995 11:12:26 -0700 To: ietf-ppp@MERIT.EDU From: ken@RNS.COM (Ken Mueller) Subject: Re: CCP, protocol compression, and MP X-Mailer: Content-Length: 2751 Resent-Message-ID: <"oAfXq3.0.cA2.-qEkl"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/474 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >> From: ken@RNS.COM (Ken Mueller) >> blah, blah, blah fro ken >I think the individual CCP compression scheme specifications deal with >how the protocol numbers of the compressed packets should be handled. > sorry, i did not explain myself well in the first email. i'm only asking about the protocol being encapsulated by CCP as part of its compression process. i'm not asking about the CCP compressed data protocols (0x00FD or 0x00FB). how to encapsulate the protocol coming down the transmit stack is not mentions in the draft specification. > >> the question is, should you try to do protocol compression on the protocol >> field or not. i would guess that the original intent of the draft was to >> look at the LCP PFC option value and compress or not as negotiated. this >> won't work for compression above an MP bundle where you don't know which LCP >> to look at. in this case, should the protocol always be compressed if >> possible or never compressed? is there now a general rule that is not the >> draft? >> >> to summarize, i would like to know: >> >> 1) if not using MP, should we compress according to the negotiated PFC value. >> >> 2) if using MP and compressing above the bundle, what are the protocol >> compression rules? > >MP and CCP are entirely independent from each other and from LCP. They >are at different layers of the onion. What each does with the protocol >numbers it is in charge of is independent of what the others do with >their protocol numbers. > >Consider MP and LCP. MP packets often have two protocol numbers. The >outer protocol number is 0x3d (MP). Whether it is compressed or not >depends entirely and only on whether LCP Protocol-Field was negotiated >in LCP Configure-Requests. The inner protocol number is often 0x21 >(IP). According to the MP rules, that number should always appear as >one byte of 0x21 and not two bytes regardless of whether the outer 0x3d >number is one byte or two. > again, i'm only asking about the inner protocol. i agree, rfc1717 specifies what to do with it, the compression draft doesn't mention it. i think that the compression draft should follow the example of RFC1717 and specify to compress the protocol if possible but i don't want to break anyone's implementation (if possible). i mostly would like some rule so that our implementation will work with other implementations which will not be the case if each implementor gets to decide individually what to do with it. > >I think a robust implementation should be prepared to deal receiving >protocol numbers of 1, 2 and even 3 bytes. You just keep grabbing and >shifting bytes until you hit an odd byte, or give up in disgust. agreed! >Vernon Schryver, vjs@sgi.com > ken mueller, ken@rns.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue May 16 14:23:08 1995 Received: (from slist@localhost) by merit.edu (8.6.10/merit-2.0) id OAA09094; Tue, 16 May 1995 14:23:08 -0400 Resent-Date: Tue, 16 May 1995 14:23:08 -0400 From: Karl Fox Date: Tue, 16 May 95 14:21:45 -0400 Message-Id: <9505161821.AA24812@gefilte.MorningStar.Com> To: ietf-ppp@MERIT.EDU Subject: CCP, protocol compression, and MP In-Reply-To: <199505161746.LAA09810@mica.denver.sgi.com> References: <199505161746.LAA09810@mica.denver.sgi.com> Reply-To: Karl Fox Organization: Morning Star Technologies, Inc. Resent-Message-ID: <"Opibm2.0.gB2.xrEkl"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/476 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU A message with Ken Mueller's name at the top and Vernon Schryver's name at the bottom (didn't this happen on ietf-ppp before?) said: > Consider MP and LCP. MP packets often have two protocol numbers. The > outer protocol number is 0x3d (MP). Whether it is compressed or not > depends entirely and only on whether LCP Protocol-Field was negotiated > in LCP Configure-Requests. The inner protocol number is often 0x21 > (IP). According to the MP rules, that number should always appear as > one byte of 0x21 and not two bytes regardless of whether the outer 0x3d > number is one byte or two. Not exactly. RFC 1717 says The packets to be transmitted using the multilink procedure are encapsulated according to the rules for PPP where the following options would have been manually configured: o No async control character Map o No Magic Number o No Link Quality Monitoring o Address and Control Field Compression [I don't know why A/C compression is mentioned, since it doesn't affect the encapsulation] o Protocol Field Compression o No Compound Frames o No Self-Describing-Padding and later PPP multilink fragments are encapsulated using the protocol identifier 0x00-0x3d. Following the protocol identifier is a four byte header containing a sequence number, and two one bit fields indicating that the fragment begins a packet or terminates a packet. After negotiation of an additional PPP LCP option, the four byte header may be optionally replaced by a two byte header with only a 12 bit sequence space. Address & Control and Protocol ID compression are assumed to be in effect. Individual fragments will, therefore, have the following format: Having protocol field compression `in effect' doesn't mean that all 00xx protocol fields must always be compressed to xx, it just means they *may* be compressed (see RFC 1661). > I think a robust implementation should be prepared to deal receiving > protocol numbers of 1, 2 and even 3 bytes. You just keep grabbing and > shifting bytes until you hit an odd byte, or give up in disgust. I agree, except that I draw the line at two bytes. By the way, how do those of you out there who have implemented MP deal with the `IP header is on an odd boundary' problem? Do you copy every received IP-over-MP packet, or do you just only use it on CPUs that don't care about word or longword alignment? This isn't a problem for me at low speeds, but it really cuts into my throughput on a T1, at least when I can't convince the peer to do P/F compression on the LCP link. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue May 16 14:23:06 1995 Received: (from slist@localhost) by merit.edu (8.6.10/merit-2.0) id OAA09083; Tue, 16 May 1995 14:23:06 -0400 Resent-Date: Tue, 16 May 1995 14:23:06 -0400 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; cc: ietf-ppp@MERIT.EDU From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-pppext-bsd-compress-04.txt Date: Tue, 16 May 95 13:32:53 -0400 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9505161332.aa08562@IETF.CNRI.Reston.VA.US> Resent-Message-ID: <"zmkNI1.0.XB2.vrEkl"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/475 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Note: This revision reflects comments received during the last call period. Title : PPP BSD Compression Protocol Author(s) : V. Schryver Filename : draft-ietf-pppext-bsd-compress-04.txt Pages : 25 Date : 05/15/1995 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. The PPP Compression Control Protocol [2] provides a method to negotiate and utilize compression protocols over PPP encapsulated links. This document describes the use of the Unix Compress compression protocol for compressing 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-bsd-compress-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-bsd-compress-04.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-bsd-compress-04.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19950515123906.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-bsd-compress-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-bsd-compress-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950515123906.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue May 16 15:03:25 1995 Received: (from slist@localhost) by merit.edu (8.6.10/merit-2.0) id PAA11186; Tue, 16 May 1995 15:03:25 -0400 Resent-Date: Tue, 16 May 1995 15:03:25 -0400 Date: Tue, 16 May 1995 13:02:10 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199505161902.NAA10116@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: CCP, protocol compression, and MP Cc: ken@RNS.COM (Ken Mueller) Resent-Message-ID: <"zZHcy1.0.ak2.uRFkl"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/477 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: ken@RNS.COM (Ken Mueller) > ... > >I think the individual CCP compression scheme specifications deal with > >how the protocol numbers of the compressed packets should be handled. > > >sorry, i did not explain myself well in the first email. i'm only asking about > the protocol being encapsulated by CCP as part of its compression process. > i'm not asking about the CCP compressed data protocols (0x00FD or 0x00FB). > how to encapsulate the protocol coming down the transmit stack is not > mentions in the draft specification. > ... > again, i'm only asking about the inner protocol. i agree, rfc1717 specifies > what to do with it, the compression draft doesn't mention it. In at least some of the individual CCP compression schemes, what should be done with the protocol field of the compressed data, often containing 0x21 (IP), is specified in the compression scheme itself. See, for example, page 5 of the BSD Compress draft. > i think that the compression draft should follow the example of RFC1717 and > specify to compress the protocol if possible but i don't want to break > anyone's implementation (if possible). i mostly would like some rule so > that our implementation will work with other implementations which will not > be the case if each implementor gets to decide individually what to do with it While it is clearly good to make a choice and document it somewher, I think I disagree about where it should be documented. It might make sense to compress packets in such a way that it would make no sense to talk about whether the protocol field of the inner packet is protocol-field-compressed or not. For example, consider a compression scheme that deals with only IP and IPX. It would make no more sense to dedicate 8 bits than 16 bits to the protocol field. Instead, dedicate a single bit to say IPX or IP (and then perhaps compress that bit). Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue May 16 15:34:24 1995 Received: (from slist@localhost) by merit.edu (8.6.10/merit-2.0) id PAA12575; Tue, 16 May 1995 15:34:24 -0400 Resent-Date: Tue, 16 May 1995 15:34:24 -0400 Date: Tue, 16 May 1995 13:33:17 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199505161933.NAA10212@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: CCP, protocol compression, and MP Resent-Message-ID: <"KBP9N.0.E43.xuFkl"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/478 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Karl Fox > > A message with Ken Mueller's name at the top and Vernon Schryver's > name at the bottom (didn't this happen on ietf-ppp before?) said: Sorry, that was my editing error. > > ... According to the MP rules, that number should always appear as > > one byte of 0x21 and not two bytes regardless of whether the outer 0x3d > > number is one byte or two. > > Not exactly. RFC 1717 says > ... > Having protocol field compression `in effect' doesn't mean that all > 00xx protocol fields must always be compressed to xx, it just means > they *may* be compressed (see RFC 1661). That is a good point. Some people at the recent San Ramon, Calif. MP PPP/ISDN test thought RFC 1717 meant to outlaw leading zeros on protocol fields. Instead, "MUST be compressed" ought to be understood as something like "leading 0's should be stripped but it's legal if perhaps inefficient to not strip the leading 0's". Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue May 16 16:01:54 1995 Received: (from slist@localhost) by merit.edu (8.6.10/merit-2.0) id QAA14028; Tue, 16 May 1995 16:01:54 -0400 Resent-Date: Tue, 16 May 1995 16:01:54 -0400 Date: Tue, 16 May 1995 13:00:42 -0700 (PDT) From: Keith Sklower Message-Id: <199505162000.NAA14698@vangogh.CS.Berkeley.EDU> To: ietf-ppp@MERIT.EDU Subject: answer to Karl Fox's question concerning RFC1717 minutiae Resent-Message-ID: <"EQiQq.0.0R3.jIGkl"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/479 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Karl wrote: "Not exactly. RFC 1717 says ... where the following options would have been manually configured: ... o Address and Control Field Compression [I don't know why A/C compression is mentioned, since it doesn't affect the encapsulation]" (end of what Karl wrote) If this were not specified, consider the lead fragment of a chain. The multilink headers and packet headers would look like: FF 03 (when ACFC not negotiated on link) 00 3d (when PC not negotiated or when the sender just feels like it) flags + sequence # FF 03 (Again, because ACFC would not have been configured on the bundle) Proto id for bundled packet. (again, possibly with leading 0) Information field for bundled packet. The first FF 03 could be conceivably be required by the serial interface board. (although I don't know personally of any boards out there these days that can't be made to do raw HDLC framing irrespective o). It seemed to me that the second FF 03 was a complete waste of bandwidth, so I took what editorial leeway I had and mandated it out of existence. Since we're thinking of tidying up 1717 a bit when it goes to draft standard, should I make the document incrementally longer by including this explanation? - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue May 16 17:22:21 1995 Received: (from slist@localhost) by merit.edu (8.6.10/merit-2.0) id RAA17416; Tue, 16 May 1995 17:22:21 -0400 Resent-Date: Tue, 16 May 1995 17:22:21 -0400 From: Karl Fox Date: Tue, 16 May 95 17:21:01 -0400 Message-Id: <9505162121.AA27642@gefilte.MorningStar.Com> To: ietf-ppp@MERIT.EDU Subject: answer to Karl Fox's question concerning RFC1717 minutiae In-Reply-To: <199505162000.NAA14698@vangogh.CS.Berkeley.EDU> References: <199505162000.NAA14698@vangogh.CS.Berkeley.EDU> Reply-To: Karl Fox Organization: Morning Star Technologies, Inc. Resent-Message-ID: <"tXO-Z1.0.yF4.9UHkl"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/480 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I wrote: > [I don't know why A/C compression is mentioned, since it doesn't > affect the encapsulation]" Keith replied: > If this were not specified, consider the lead fragment of > a chain. The multilink headers and packet headers would look like: > > FF 03 (when ACFC not negotiated on link) > 00 3d (when PC not negotiated or when the sender just feels like it) > flags + sequence # > FF 03 (Again, because ACFC would not have been configured on the bundle) ... > so I took what editorial leeway I had and mandated it out of existence. Oh, *now* I understand. Unfortunately, the FF 03 isn't mandated out of existence--just like the leading 00 byte in the protocol field, it's only optionally gone. I guess I need to go back and do some defensive coding. > Since we're thinking of tidying up 1717 a bit when it goes to draft > standard, should I make the document incrementally longer by including > this explanation? I think some more clarification would be helpful. If no existing implementations ever send the FF 03, then I'd recommend explicitly disallowing it. I'm not sure you should change the protocol field requirements, though; in fact, some discussion about how to help with (IP header) alignment issues would be especially appreciated. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue May 16 18:50:23 1995 Received: (from slist@localhost) by merit.edu (8.6.10/merit-2.0) id SAA20904; Tue, 16 May 1995 18:50:23 -0400 Resent-Date: Tue, 16 May 1995 18:50:23 -0400 Date: Tue, 16 May 1995 16:49:30 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199505162249.QAA11045@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: MP and A/C compression Resent-Message-ID: <"YgLUl3.0.Q65.fmIkl"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/481 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > > If this were not specified, consider the lead fragment of > > a chain. The multilink headers and packet headers would look like: > > > > FF 03 (when ACFC not negotiated on link) > > 00 3d (when PC not negotiated or when the sender just feels like it) > > flags + sequence # > > FF 03 (Again, because ACFC would not have been configured on the bundle)... > > so I took what editorial leeway I had and mandated it out of existence. > > Oh, *now* I understand. Unfortunately, the FF 03 isn't mandated out > of existence--just like the leading 00 byte in the protocol field, > it's only optionally gone. I guess I need to go back and do some > defensive coding. > > Since we're thinking of tidying up 1717 a bit when it goes to draft > > standard, should I make the document incrementally longer by including > > this explanation? > > I think some more clarification would be helpful. If no existing > implementations ever send the FF 03, then I'd recommend explicitly > disallowing it. ... I second that motion. If the 0xFF03 is really now only optionally absent, then let's make it officially forbidden. The protocol field differs from the 0xff03. The 0xff03 is more of a real HDLC thing. You always need the protocol field's information, but the 0xff03 is just noise except when doing raw HDLC. Also, some implemenation might like to not compress the protocol field to help alignment, perhaps when using short sequence numbers. Personally, I wouldn't care if the protocol field were mandated to not have any leading zero's, but I suspect that would increase problems. It seems far easier to fail to compress the protocol field than to fail to completely omit the 0xff03. Easy bugs tend to happen. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed May 17 13:42:53 1995 Received: (from slist@localhost) by merit.edu (8.6.10/merit-2.0) id NAA01966; Wed, 17 May 1995 13:42:53 -0400 Resent-Date: Wed, 17 May 1995 13:42:53 -0400 Message-Id: <9505171743.AA03411@fet.com> To: ietf-ppp@MERIT.EDU Subject: Magic Number option Date: Wed, 17 May 95 10:43:14 -0700 From: "S. Arnold Fukutomi" Resent-Message-ID: <"yQp4t2.0.QU.lLZkl"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/482 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Hello, I have some question about Magic Number option. There is a sentense bellow in RFC1661. Does anyone have an idea about this? Page 46, the third paragraph, 6 line, "If an implementation does receive a Configure-Reject in response to a Configure-Request, it can only mean that the link is not looped-back, and that its peer will not be using Magic-Numbers. In this case, an implementation SHOULD act as if the negotiation had been successful (as if it had instead received a Configure-Ack)." In this case receiver of Configure-Reject becomes to OPEN state, but sender of Configure-Reject does not become to OPEN state and wait for receiving Configure-Request again. I do not think there is transition to OPEN state when it receive Configure-Reject. How should we solve this issue? Arnold Fukutomi, Furukawa Electric Technologies, Inc. (Tel) 408-248-4884 (Fax) 408-248-8815 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed May 17 18:25:02 1995 Received: (from slist@localhost) by merit.edu (8.6.10/merit-2.0) id SAA12929; Wed, 17 May 1995 18:25:02 -0400 Resent-Date: Wed, 17 May 1995 18:25:02 -0400 From: Brad Wilson Message-Id: <199505172224.SAA03419@cps203.cps.cmich.edu> Subject: Re: Magic Number option To: arnold@fet.com (S. Arnold Fukutomi) Date: Wed, 17 May 1995 18:24:26 -0400 (EDT) Cc: ietf-ppp@MERIT.EDU In-Reply-To: <9505171743.AA03411@fet.com> from "S. Arnold Fukutomi" at May 17, 95 10:43:14 am X-Mailer: ELM [version 2.4 PL22beta3] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1460 Resent-Message-ID: <"scMme3.0.p93.xUdkl"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/483 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU These words were uttered by S. Arnold Fukutomi ... : Hello, : : I have some question about Magic Number option. There is a sentense : bellow in RFC1661. Does anyone have an idea about this? : : Page 46, the third paragraph, 6 line, : "If an implementation does receive a Configure-Reject in response to a : Configure-Request, it can only mean that the link is not looped-back, : and that its peer will not be using Magic-Numbers. In this case, an : implementation SHOULD act as if the negotiation had been successful : (as if it had instead received a Configure-Ack)." I think that what the intent is is to tell you what is happening if you are using Magic Number for loopback testing. If you send a request and get a reject, you are not looped back. I don't know (without the whole context) if this is poorly worded, or out of context. The reality is that you should send a 0 magic number for anything that uses a magic number (like echo requests) if you get rejected on it, even though you have used it to determine you are not looped back. -- Brad Wilson Internet: wilson@cps.cmich.edu Voice: +1 810 625-2473 Sr. Software Engineer Crucial Software Data: +1 810 620-9803 Engineering services available in C++ for Windows 95 and Windows NT For PGP 2.6.2 public key: "finger -l wilson@cps.cmich.edu" "Drugs have taught an entire generation of American kids the metric system" - PJ O'Rourke - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed May 17 19:36:58 1995 Received: (from slist@localhost) by merit.edu (8.6.10/merit-2.0) id TAA15780; Wed, 17 May 1995 19:36:58 -0400 Resent-Date: Wed, 17 May 1995 19:36:58 -0400 Message-Id: <9505172338.AA04401@fet.com> To: Brad Wilson Cc: ietf-ppp@MERIT.EDU Subject: Re: Magic Number option In-Reply-To: Your message of "Wed, 17 May 95 18:24:26 EDT." <199505172224.SAA03419@cps203.cps.cmich.edu> Date: Wed, 17 May 95 16:38:11 -0700 From: "S. Arnold Fukutomi" Resent-Message-ID: <"vdShq.0.Ks3.MYekl"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/484 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Mr. Wilson Thank you for your help. I should explain more detail for your understanding. >> These words were uttered by S. Arnold Fukutomi ... >> >> : Hello, >> : >> : I have some question about Magic Number option. There is a sentense >> : bellow in RFC1661. Does anyone have an idea about this? >> : >> : Page 46, the third paragraph, 6 line, >> : "If an implementation does receive a Configure-Reject in response to a >> : Configure-Request, it can only mean that the link is not looped-back, >> : and that its peer will not be using Magic-Numbers. In this case, an >> : implementation SHOULD act as if the negotiation had been successful >> : (as if it had instead received a Configure-Ack)." >> >> I think that what the intent is is to tell you what is happening if you >> are using Magic Number for loopback testing. If you send a request and >> get a reject, you are not looped back. I don't know (without the whole >> context) if this is poorly worded, or out of context. The reality is >> that you should send a 0 magic number for anything that uses a magic >> number (like echo requests) if you get rejected on it, even though you >> have used it to determine you are not looped back. The issue is one(A) which intent to use Magic Number option and other(B) which does not intent to use Magic Number option. (A) (B) Layer Up Req-Sent ----------------------> Config-Req(Magic-Num) . . . . Layer Up Req-Sent <---------------------- Config-Req Ack-Sent ----------------------> Ack-Rcvd Config-Ack ----------------------> Config-Req(Magic-Num) Opened <---------------------- stay Ack-Rcvd ? Config-Rej (A) is sending Config-Req with Magic-Num option. (B) is sending Config-Req without Magic-Num option. At the above sequense (A) will be Opened state after receiving Config-Rej. I think (B) is staying at Ack-Rcvd because (B) sent Config-Rej. Is ther any implementation sugestion? Arnold Fukutomi, Furukawa Electric Technologies, Inc. (Tel) 408-248-4884 (Fax) 408-248-8815 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed May 17 21:28:33 1995 Received: (from slist@localhost) by merit.edu (8.6.10/merit-2.0) id VAA20059; Wed, 17 May 1995 21:28:33 -0400 Resent-Date: Wed, 17 May 1995 21:28:33 -0400 Date: Wed, 17 May 95 18:30:07 PST From: Michael Zheng Message-ID: <9505171830.A14272@snail.combinet.com> To: ietf-ppp@MERIT.EDU Subject: Re: CCP language Resent-Message-ID: <"q33o82.0.Ev4._Agkl"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/485 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I just got the draft-ietf-pppext-compression-04.txt from nic.ddn.mil and found that the section 4 does not contain text that addresses the fast/first ack issue as suggested in the following mail. (It does contain one line under the OUI section that says the first matching compression will be used.) Since I haven't been following the mailing list lately, I wonder what the final concensus is. Also, does anybody know of anyone who has offered to do the interoperability test of his CCP implementation? Thanks. -mz ______________________________ Reply Separator _________________________________ Subject: CCP language Author: ietf-ppp@MERIT.EDU at Internet-Mail Date: 3/9/95 8:03 AM Received: from snail.combinet.com by cc:Mail (1.30/SMTPLink) merit.edu by combinet.com (8.6.5/1.00) id FAA22604; Thu, 9 Mar 1995 05:01:21 -0800 Received: (from slist@localhost) by merit.edu (8.6.10/merit-2.0) id IAA14170; Th Resent-Date: Thu, 9 Mar 1995 08:03:30 -0500 Date: Thu, 9 Mar 95 11:56:10 GMT From: "William Allen Simpson" Message-ID: <4211.Bill.Simpson@um.cc.umich.edu> To: ietf-ppp@MERIT.EDU Subject: CCP language Resent-Message-ID: <"3azyJ.0.ET3.UolNl"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/351 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU After considerable private email and voice conversations, here is what we have been able to come up with: 1) Send one at a time. This is most robust, and always will work. Most fielded implementations work this way. It is slower when lots of algorithms are offered. In one case, 4 algorithms. 2) Sending more than one at a time is allowed, but the peer should reject all but one. This always results in 2 exchanges, which was acceptable to us. We were not able to agree on the 3rd mode where multiple options are sent, and if they are all acceptable, just -Ack, and use the first. While this would save a round trip, the implementation isn't as robust, and won't work with some fielded implementations. It also won't apply in very many cases, since we were unable to find any two implementations that had exactly the same set of options. ---- 4. CCP Configuration Options CCP Configuration Options allow negotiation of compression algorithms and their parameters. CCP uses the same Configuration Option format defined for LCP [1], with a separate set of Options. Configuration Options, in this protocol, indicate algorithms that the implementation is willing or able to receive to decompress data sent by the peer. Most commonly, only one algorithm will be offered in the Configure-Request. Implementations MAY offer to accept multiple algorithms, sorted in order of preference. If an Option is unrecognized by the peer, a Configure-Reject is sent. When more than one Option remains, the peer SHOULD Configure-Reject all except the most preferred of the remaining Options. Note: Since the Options are sorted by preference in the request, this is most readily implemented by skipping the first acceptable Option, and rejecting the others. However, more complicated analysis schemes are possible. Take care that the Options in the Configure-Reject remain in the original order. If all Options are recognized, but one or more is not acceptable due to values in the request (or optional parameters not in the request), a Configure-Nak MUST be sent with the Option(s) modified appropriately. A new Configure-Request SHOULD be sent with only the single most preferred Option, adjusted as specified in the Configure-Nak. If all Options offered are rejected by the peer, then no compression is enabled in that direction of the link, and the link will continue to operate without compression. If link reliability has been separately negotiated, then it will continue to be used, until the LCP is re-negotiated. Up-to-date values of the CCP Option Type field are specified in the .... Bill.Simpson@um.cc.umich.edu - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu May 18 12:35:34 1995 Received: (from slist@localhost) by merit.edu (8.6.10/merit-2.0) id MAA24712; Thu, 18 May 1995 12:35:34 -0400 Resent-Date: Thu, 18 May 1995 12:35:34 -0400 From: Brad Wilson Message-Id: <199505181634.MAA04547@cps203.cps.cmich.edu> Subject: Re: Magic Number option To: arnold@fet.com (S. Arnold Fukutomi) Date: Thu, 18 May 1995 12:34:41 -0400 (EDT) Cc: wilson@cps201.cps.cmich.edu, ietf-ppp@MERIT.EDU In-Reply-To: <9505172338.AA04401@fet.com> from "S. Arnold Fukutomi" at May 17, 95 04:38:11 pm X-Mailer: ELM [version 2.4 PL22beta3] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1167 Resent-Message-ID: <"ZgJ7E1.0.w16.GTtkl"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/486 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU These words were uttered by S. Arnold Fukutomi ... : The issue is one(A) which intent to use Magic Number option and : other(B) which does not intent to use Magic Number option. I agree that the wording is incorrect. What I was attempting to do was to shed some light on the possible reason that the bad wording slipped into the document. A rejected magic number should not be resent. If a magic number is rejected, you can presume that means that your link is not looped back (at least, I don't think there are any implementations with unidirectional magic number support where they send it only). IN THAT LINE OF THOUGHT ONLY, the use of magic number was successful. How the faulty wording got into the document is a mystery. ;-) : Is ther any implementation sugestion? Yes. Ignore the wording and implement according to the actual meaning of a Configure-Reject. -- Brad Wilson Internet: wilson@cps.cmich.edu Voice: +1 810 625-2473 Sr. Software Engineer Crucial Software Data: +1 810 620-9803 Engineering services available in C++ for Windows 95 and Windows NT For PGP 2.6.2 public key: "finger -l wilson@cps.cmich.edu" - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Sat May 20 08:44:41 1995 Received: (from slist@localhost) by merit.edu (8.6.10/merit-2.0) id IAA00507; Sat, 20 May 1995 08:44:41 -0400 Resent-Date: Sat, 20 May 1995 08:44:41 -0400 Message-Id: <0jjSDZ30GRli5Uc2VU@chaos> Date: Sat, 20 May 1995 05:43:17 -0700 (PDT) From: Jay Laefer To: ietf-ppp@MERIT.EDU Subject: Multilink Begin fragment Resent-Message-ID: <"7sQn23.0.e7.TGUll"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/487 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU What are the chances that we could put the following requirement in Multilink? When a packet is fragmented for transmission by the sender, the sender MUST ensure that the PPP protocol field is in the first fragment. Null fragments with no data and both the Begin and End bits set would be exempt from this requirement (since there's no protocol field in the fragment). Rationale: For receiving plain old PPP, I try to keep the Information field longword aligned. If Address-and-Control compression and/or Protocol field compression is being used, then I quietly slip the skipped characters into my receive buffer. Thus, my PPP header is always 4 bytes. For multilink, I'd like to do something similar. When using 24-bit sequence numbers, the multilink header is another 4 bytes. (12-bit sequence numbers could be padded.) Unfortunately, all of the following (somewhat pathological) cases might occur after the multilink header is received for the first fragment: Key: P1 == Hi byte of Protocol field P2 == Lo byte of Protocol field S1 == Hi byte of FCS S2 == Lo byte of FCS [S1 S2] [FF S1 S2] [P1 S1 S2] [FF 03 S1 S2] [FF 03 P1 S2] What ends up happening in most of these cases is that I would treat the FCS as packet data for the purposes of slipping 0xFF, 0x03, or 0x00 into the fragment as it arrives. If I know that P2 is in the first fragment, I can guarantee that I never treat the FCS as data. I would assume (perhaps incorrectly) that most implementations include P2 in the first fragment. My suggested change to RFC 1717 would hopefully not force anyone to alter their implementation. Comments please? -Jay Laefer jay@gordian.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Sat May 20 10:35:37 1995 Received: (from slist@localhost) by merit.edu (8.6.10/merit-2.0) id KAA04424; Sat, 20 May 1995 10:35:37 -0400 Resent-Date: Sat, 20 May 1995 10:35:37 -0400 Date: Sat, 20 May 1995 08:34:25 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199505201434.IAA07089@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: Multilink Begin fragment Resent-Message-ID: <"Zrxyo.0.t41.puVll"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/488 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Jay Laefer > When a packet is fragmented for transmission by the sender, the sender > MUST ensure that the PPP protocol field is in the first fragment. > ... What do you mean by the "first fragment"? Since it is impossible for the peer to control the temporal order of fragments arriving at your ends of the links, you must mean "first fragment in MP sequence number order." I do not understand. Are you proposing to outlaw silly fragmentation? That the peer could not omit all of the useful bytes in the first fragment? > For receiving plain old PPP, I try to keep the Information field > longword aligned. If Address-and-Control compression and/or Protocol > field compression is being used, then I quietly slip the skipped > characters into my receive buffer. Thus, my PPP header is always 4 > bytes. What if you have negotiated both A&C and Protocol compression, but the peer decides on an arbitrary packet to send you a packet with neither kind of compression? As has been pointed out, but as some people did not realize, when you have received a Configure-Ack for A&C and Protocol compression, you can only say that the peer is allowed to send you packets without the 0xff03 or the leading 0 of protocol. The peer is perfectly welcome to send you a Configure-Ack for both, and then always start packets with 0xff0300. In fact, the peer ought to send packets with 0xff03 whenever it suspects synchronization has been lost, as when it sends a new LCP configure request. Or do you mean that you look at the first bytes of each packet, and if they are missing the 0xff03 or the 0x0 of the protocol field, then you add them to the buffer? If so, then I do the same. > ... > I would assume (perhaps incorrectly) that most implementations include > P2 in the first fragment. My suggested change to RFC 1717 would > hopefully not force anyone to alter their implementation. I don't think I understand, but maybe I do. Would a sufficient (but not necessary) condition be that all fragments except the last have a minimum length of 2 bytes? Possibly with the additional words recently discussed that the 0xFF03 of the encapsulated packet are never sent? We've argued about minimum fragment sizes, but I don't remember what positions were advanced. A minimum, non-ending fragment size of 2, 4, or even 8 strikes me now as reasonable. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Sat May 20 21:21:31 1995 Received: (from slist@localhost) by merit.edu (8.6.10/merit-2.0) id VAA25888; Sat, 20 May 1995 21:21:31 -0400 Resent-Date: Sat, 20 May 1995 21:21:31 -0400 Message-Id: <0jjdJS30GRliFXR0BG@chaos> Date: Sat, 20 May 1995 18:20:30 -0700 (PDT) From: Jay Laefer To: ietf-ppp@MERIT.EDU Subject: Re: Multilink Begin fragment Resent-Message-ID: <"SRCiL3.0.KK6.NMfll"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/489 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: vjs@mica.denver.sgi.com (Vernon Schryver) >> When a packet is fragmented for transmission by the sender, the sender >> MUST ensure that the PPP protocol field is in the first fragment. >What do you mean by the "first fragment"? I mean the fragment with the (B)egin bit set. > I do not understand. Are you proposing to outlaw silly fragmentation? > That the peer could not omit all of the useful bytes in the first > fragment? Well, my suggestion would only outlaw one set of silly fragmentation. Frankly, reassembly is much harder that fragmentation. It would be nice to stack the deck a little more in favor of reassembly. So, yes, I would forbid the omission of the "useful bytes" in the Begin fragment. > Or do you mean that you look at the first bytes of each packet, and if > they are missing the 0xff03 or the 0x0 of the protocol field, then you > add them to the buffer? If so, then I do the same. I do what you do. I only insert bytes that were missing. > I don't think I understand, but maybe I do. Would a sufficient (but > not necessary) condition be that all fragments except the last have a > minimum length of 2 bytes? Possibly with the additional words recently > discussed that the 0xFF03 of the encapsulated packet are never sent? The combinbation of both above would work for me. > We've argued about minimum fragment sizes, but I don't remember what > positions were advanced. A minimum, non-ending fragment size of 2, 4, > or even 8 strikes me now as reasonable. Okay, three possibilities listed solve my problem. My idea: The Begin fragment must contain the low byte of the Protocol field. VJS' idea (1): All fragments must have at least 2 bytes of data following the MP header. *And* 0xFF03 is always omitted by the transmitter. VJS' idea (2): All fragments must have at least 4 bytes of data following the MP header. Personally, I don't need any requirements for non-Begin fragments, but others might. -Jay Laefer jay@gordian.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon May 22 11:38:40 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id LAA13516; Mon, 22 May 1995 11:38:40 -0400 Resent-Date: Mon, 22 May 1995 11:38:40 -0400 Date: Mon, 22 May 1995 11:28:13 -0400 From: Rob Martino Message-Id: <199505221528.LAA08933@olympus.ctron.com> To: ietf-ppp@MERIT.EDU Subject: CCP negotiation Resent-Message-ID: <"Gw6pe1.0.iI3.9_Aml"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/490 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Hello, Some questions: In our compression implementation (Stacker LZS) let's say one side is configured for compression and the other side, while it supports LZS as well, has compression turned off. Would I want the no-compression side to configure-reject the request from the side that wants LZS (option 17), or configure-nak it? It seems the configure-nak is more appropriate when both sides want LZS but the options (history count, check mode) are not correct. But then again, I am still a PPP novice so I don't always know what the heck I am doing. Rob - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon May 22 11:46:01 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id LAA14153; Mon, 22 May 1995 11:46:01 -0400 Resent-Date: Mon, 22 May 1995 11:46:01 -0400 From: sherry@crab.ims.advantis.com (Sherry Chiramanaphand) Message-Id: <9505221546.AA12247@crab.ims.advantis.com> Subject: Source code for PPP Stacker LZS compression protocol To: ietf-ppp@MERIT.EDU Date: Mon, 22 May 1995 11:46:20 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 219 Resent-Message-ID: <"oC6Wk2.0.zS3.r6Bml"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/491 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I am reading the working draft for PPP Stacker LZS Compression Protocol, and I would like to know if there is source code that is available to public. Please let me know how to obtain it. sherryc@ims.advantis.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon May 22 19:02:15 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id TAA01508; Mon, 22 May 1995 19:02:15 -0400 Resent-Date: Mon, 22 May 1995 19:02:15 -0400 Date: Mon, 22 May 1995 16:01:25 -0700 (PDT) From: Keith Sklower Message-Id: <199505222301.QAA07948@vangogh.CS.Berkeley.EDU> To: ietf-ppp@MERIT.EDU Subject: On whether RFC1717 can forbid FF03 inside a multilink payload Resent-Message-ID: <"lktw_1.0.KN.pVHml"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/492 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I've always taken the point of view that the "bundle" is a valid PPP entity in its own right, and should have all the rights, and responsibilities thereof. Since the PPP RFC says you can can send FF03 even when you've negotiated ACFC, then I think multilink implementations "MUST" accept them. However, I think we can get away with saying you "SHOULD NOT" transmit them. (I used capitalization here, not for emphasis, but as literals to be placed in the document). Now that Tom Coradetti is back on the list, I'ld like to revisit a topic that was discussed at the last IETF, which is whether it makes sense to Configure-Nak an Endpoint Discrimanator option. I brought up the subject at the meeting, because there had been mail from Vern Schryver on the list who was proposing to forbid it. And, that section being pretty much written by Tom C., I hadn't realized it was **already** forbidden. The current language of the RFC is: This option is not required to be supported either by the system or the peer. If the option is not present in a Configure-Request, the system MUST NOT generate a Configure-Nak of this option, instead it SHOULD behave as if it had received the option with Class = 0, Address = 0. If a system receives a Configure-Nak or Configure- Reject of this option, it MUST remove it from any additional Configure-Request. In a phone conversation I had with Tom, he said his reasoning was that if the implementation supported the ED option, it should always provide one, so that even if you feed it a "cue bid" by NAKing, if it could have provided one, it would have already done so, so the exercise is useless. Can we leave this paragraph as is? - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon May 22 21:32:37 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id VAA06905; Mon, 22 May 1995 21:32:37 -0400 Resent-Date: Mon, 22 May 1995 21:32:37 -0400 From: Karl Fox Date: Mon, 22 May 95 21:31:58 -0400 Message-Id: <9505230131.AA24204@gefilte.MorningStar.Com> To: Keith Sklower Cc: ietf-ppp@MERIT.EDU Subject: On whether RFC1717 can forbid FF03 inside a multilink payload In-Reply-To: <199505222301.QAA07948@vangogh.CS.Berkeley.EDU> References: <199505222301.QAA07948@vangogh.CS.Berkeley.EDU> Reply-To: Karl Fox Organization: Morning Star Technologies, Inc. Resent-Message-ID: <"3ShYY3.0.jh1.oiJml"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/493 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Keith Sklower writes: > The current language of the RFC is: > > This option is not required to be supported either by the system or > the peer. If the option is not present in a Configure-Request, the > system MUST NOT generate a Configure-Nak of this option, instead it > SHOULD behave as if it had received the option with Class = 0, > Address = 0. If a system receives a Configure-Nak or Configure- ------------------------------------ > Reject of this option, it MUST remove it from any additional ------------------------------------------------------------ > Configure-Request. ------------------ > Can we leave this paragraph as is? I think the underlined part is a little weird, since it specifies what to do in response to an essentially illegal message while not forbidding the transmission of the illegality itself. The paragraph allows the peer to Configure-Nak our ED option, but what would such a Nak contain? It is absurd when you think about it. I would rather it forbid the nacking of ED options altogether, although shutting down ED negotiation is probably a reasonable response. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon May 22 21:44:58 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id VAA07559; Mon, 22 May 1995 21:44:58 -0400 Resent-Date: Mon, 22 May 1995 21:44:58 -0400 Date: Mon, 22 May 1995 18:44:11 -0700 (PDT) From: Keith Sklower Message-Id: <199505230144.SAA08647@vangogh.CS.Berkeley.EDU> To: ietf-ppp@MERIT.EDU Subject: re: ok to forbid Configure-Nak'ing an ED option? Cc: karl@MorningStar.Com Resent-Message-ID: <"k-92A3.0.wr1.NuJml"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/494 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I wrote: S> The current language of the RFC is: S> This option is not required to be supported either by the system or S> the peer. If the option is not present in a Configure-Request, the S> system MUST NOT generate a Configure-Nak of this option, instead it ^^^^^^ S> SHOULD behave as if it had received the option with Class = 0, S> Address = 0. Quoting Karl out of context: F} I would rather it forbid the nacking of ED options altogether, although F} shutting down ED negotiation is probably a reasonable response Now, when I read that text this morning, I speed-read the underscored "system", and imagined I had seen "peer", (although it actually doesn't say that) and concluded that it was Tom's intent that Configure-Nak'ing was forbidden. Yoo-Hoo ... Tom ... Are you there? Is this what you meant? - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon May 22 21:56:58 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id VAA08086; Mon, 22 May 1995 21:56:58 -0400 Resent-Date: Mon, 22 May 1995 21:56:58 -0400 Date: Mon, 22 May 1995 19:56:16 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199505230156.TAA11023@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: On whether RFC1717 can forbid FF03 inside a multilink payload Resent-Message-ID: <"jNpAr.0.6-1.c3Kml"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/495 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Keith Sklower > I've always taken the point of view that the "bundle" is a valid PPP > entity in its own right, and should have all the rights, and responsibilities > thereof. > > Since the PPP RFC says you can can send FF03 even when you've negotiated > ACFC, then I think multilink implementations "MUST" accept them. However, > I think we can get away with saying you "SHOULD NOT" transmit them. > (I used capitalization here, not for emphasis, but as literals to be > placed in the document). I do not understand how considering the bundle as a PPP entity implies that an MP packet may have two copies of the FF03. I always figured that the FF03 bytes are part of the framing, that the following words from page 6 of RFC 1717 meant that the FF03 bytes are forbidden: Network Protocol packets are first encapsulated (but not framed) according to normal (Yes, I've since added defensive code.) In any case, in the name of simplicity and speed, why can't the RFC say "MUST NOT" instead of "SHOULD NOT"? Is it too much to hope that no current implementation transmits two FF03 pairs in a single packet? > Now that Tom Coradetti is back on the list, I'ld like to revisit a topic > that was discussed at the last IETF, which is whether it makes > sense to Configure-Nak an Endpoint Discrimanator option. > I brought up the subject at the meeting, because there had been mail > from Vern Schryver on the list who was proposing to forbid it. > And, that section being pretty much written by Tom C., > I hadn't realized it was **already** forbidden. > > The current language of the RFC is: > > This option is not required to be supported either by the system or > the peer. If the option is not present in a Configure-Request, the > system MUST NOT generate a Configure-Nak of this option, instead it > SHOULD behave as if it had received the option with Class = 0, > Address = 0. If a system receives a Configure-Nak or Configure- > Reject of this option, it MUST remove it from any additional > Configure-Request. > > In a phone conversation I had with Tom, he said his reasoning was > that if the implementation supported the ED option, it should > always provide one, so that even if you feed it a "cue bid" > by NAKing, if it could have provided one, it would have already done > so, so the exercise is useless. > > Can we leave this paragraph as is? Oh. Yes, that paragraph is ok as far as my original objection. However, should something be said about other reasons for a Configure-Nak? Shouldn't it say that the system "MUST NOT" Configure-Nak for any other reason, such as a different style of endpoint? Yes, I know that would be an odd thing to do, but I have evidence that some MP implementations are not treating Endpont Discriminators as an opaque identifier. I think some look at the IP address in that type of discriminator to decide whether to proced with the connection, even on the first link of a bundle. While I think this is clearly wrong (the RFC does not say which IP address a multi-homed host should use as a discriminator), and it is not strictly relevant, it suggests that some people might view the discriminator as something to negotiate. It is a small step from parsing a discriminator to Nak'ing for a different one. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue May 23 04:33:56 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id EAA21935; Tue, 23 May 1995 04:33:56 -0400 Resent-Date: Tue, 23 May 1995 04:33:56 -0400 Date: Tue, 23 May 1995 09:29:14 +0100 From: Gerry Meyer Message-Id: <199505230829.JAA27664@orbweb.spider.co.uk> To: martino@ctron.com Subject: Re: CCP negotiation Cc: ietf-ppp@MERIT.EDU Resent-Message-ID: <"6jX2S1.0.ZM5.YtPml"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/496 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >In our compression implementation (Stacker LZS) let's say >one side is configured for compression and the other side, >while it supports LZS as well, has compression turned off. >Would I want the no-compression side to configure-reject the >request from the side that wants LZS (option 17), or Yes. Configure-Reject >configure-nak it? No. >It seems the configure-nak is more >appropriate when both sides want LZS but the options >(history count, check mode) are not correct. But then >again, I am still a PPP novice so I don't always know >what the heck I am doing. Yes. The Configure-Nak would be used to suggest alternative history count, check mode values and hopefully a compromise would be achieved. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue May 23 06:08:40 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id GAA25078; Tue, 23 May 1995 06:08:40 -0400 Resent-Date: Tue, 23 May 1995 06:08:40 -0400 Date: Tue, 23 May 1995 11:04:16 +0100 From: Gerry Meyer Message-Id: <199505231004.LAA29771@orbweb.spider.co.uk> To: ietf-ppp@MERIT.EDU Subject: ECP text Resent-Message-ID: <"_nHWx1.0.f76.aGRml"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/497 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I will be putting out a new version of the ECP draft shortly. I intend to summarise the discussion of CCP/ECP negotiation of a couple of months ago using the new section below. Comments? Gerry 4.3 Negotiating an Encryption Algorithm ECP uses LCP option negotiation techniques to negotiate encryption algorithms. In contast with most other LCP or NCP negotiation of multiple options, ECP negotiation is expected to converge on a single mutually agreeable option (encryption algorithm) - or none. Encryp- tion SHOULD be negotiated in both directions, but the algorithms MAY be different. An implementation willing to decrypt using a particular encryption algorithm (or one of a set of algorithms) offers the algorithm(s) as an option (or options) in an ECP Configure-Request - call this end the Decrypter; call the peer the Encrypter. A Decrypter supporting more than one encryption algorithm may send a Configure-Request containing either: o an ordered list of options, with the most-preferred encryption algorithm coming first. o Or may just offer its preferred (not already Rejected) option. An Encrypter wishing to accept the first option (of several) MAY Configure-Ack ALL Options to indicate complete acceptance of the first-listed, preferred, algorithm. Otherwise, if the Encrypter does not recognise - or is unwilling to support - an option it MUST send a Configure-Reject for that option. Where more than one option is offered, the Encrypter SHOULD Configure-Reject all but a single preferred option. If the Encrypter Configure-Rejects all offered ECP options - and the Decrypter has no further (non-rejected) options it can offer in a Configure-Request - the Encrypter SHOULD take the link down. If the Encrypter recognises an option, but it is not acceptable due to values in the request (or optional parameters not in the request), it MUST send a Configure-Nak with the option modified appropriately. The Configure-Nak MUST contain only those options that will be acceptable. The Decrypter SHOULD send a new Configure-Request with only the single preferred option, adjusted as specified in the Configure-Nak. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue May 23 07:17:39 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id HAA27587; Tue, 23 May 1995 07:17:39 -0400 Resent-Date: Tue, 23 May 1995 07:17:39 -0400 Date: Tue, 23 May 95 12:48 +0100 From: Butler_Tim@euskom.spritel.es Subject: On whether RFC1717 can forbid FF03 inside a multilink payload To: ietf-ppp@MERIT.EDU Message-ID: <9505231248.73815@EUSKOM.SPRITEL.ES> Resent-Message-ID: <"oHfpt2.0.ok6.GHSml"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/498 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU In discussing ACFC, the PPP RFC itself is very explicit in NOT mentioning 'FF03'; it states: By default, all implementations MUST transmit frames with Address and Control fields appropriate to the link framing. The inclusion within the MP bundle of an A/C field of 'FF03' arbitrarily assigns some of the attributes of PPP in HDLC-like Framing to the virtual link. This is only one of several framing methods which could carry PPP on a point-point link. If indeed the intent of RFC1717 is to allow 'FF03', then it seems to me that it should explicitly assign HDLC's Address/Control property to the virtual link. Personally, I would rather forbid the possibility of 'FF03', or any other A/C encapsulation which is particular to a physical framing technique. An explicit definition for the "link framing" properties of an MP bundle which states something like o No Address and Control fields o No FCS o Octet transparent (no framing or synchronization bits/bytes) might alleviate any ambiguities with respect to MP encapsulation. Tim Butler butler_tim@euskom.spritel.es - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue May 23 19:39:57 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id TAA26112; Tue, 23 May 1995 19:39:57 -0400 Resent-Date: Tue, 23 May 1995 19:39:57 -0400 Date: 23 May 95 19:34:14 EDT From: Tom Coradetti <70761.1664@compuserve.com> To: "INTERNET:ietf-ppp@MERIT.EDU" Subject: On whether RFC1717 can forbid FF03 inside a multilink payload Message-ID: <950523233413_70761.1664_EHM175-1@CompuServe.COM> Resent-Message-ID: <"mL9t01.0.PN6.M8dml"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/499 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Keith Sklower writes: >I've always taken the point of view that the "bundle" is a valid PPP >entity in its own right, and should have all the rights, and responsibilities >thereof. Whatever entity it is, it is certainly not one which places PPP packets directly on a medium. >Since the PPP RFC says you can can send FF03 even when you've negotiated >ACFC, then I think multilink implementations "MUST" accept them. However, >I think we can get away with saying you "SHOULD NOT" transmit them. >(I used capitalization here, not for emphasis, but as literals to be >placed in the document). If there is any error here, it is not in RFC 1717, but in the PPP document. (And I don't think there is really an error there either.) I must admit that I was orginally confused about where the FF 03 belonged. But careful reading of the base PPP documents helped me conclude that the FF 03 is not part of the PPP packet, but part of the HDLC definition. The fact that LCP allows negotiation of this aspect of the enclosing HDLC framing does not mean that FF 03 is part of the PPP packet. Since Multilink fragments PPP packets, not the thing that goes over the medium, it should SAY NOTHING about FF 03, HDLC, or any other medium related framing attribute. It is not optional to send FF 03 inside the bundle. It is a bug. I had that bug at DigiBoard and fixed it. Anyone else should do the same. If you want to be generous and let your receiver accept it, go ahead. But don't feel any more obligated to do so than to also accept a random IEEE 802.3 header, ATM header, Wireless header, or White Sox double header stuck in front of the bundled PPP packet. -------------------------------------------------------- Tom Coradetti Sidewalk Software Phone: (612) 490 7856 1190 Josephine Road Email: 70761.1664@compuserve.com Roseville, MN 55113 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue May 23 19:39:58 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id TAA26115; Tue, 23 May 1995 19:39:58 -0400 Resent-Date: Tue, 23 May 1995 19:39:58 -0400 Date: 23 May 95 19:34:18 EDT From: Tom Coradetti <70761.1664@compuserve.com> To: "INTERNET:ietf-ppp@MERIT.EDU" Subject: On NAK'ing endpoint discriminators Message-ID: <950523233418_70761.1664_EHM175-2@CompuServe.COM> Resent-Message-ID: <"UHref1.0.aN6.O8dml"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/500 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Keith Sklower excerpts from RFC 1717: > This option is not required to be supported either by the system or > the peer. If the option is not present in a Configure-Request, the > system MUST NOT generate a Configure-Nak of this option, instead it > SHOULD behave as if it had received the option with Class = 0, > Address = 0. If a system receives a Configure-Nak or Configure- > Reject of this option, it MUST remove it from any additional > Configure-Request. and writes: >Can we leave this paragraph as is? Yes. Karl Fox writes: >I think the part is a little weird, since it specifies what >to do in response to an essentially illegal message while not >forbidding the transmission of the illegality itself. The paragraph >allows the peer to Configure-Nak our ED option, but what would such a >Nak contain? It is absurd when you think about it. I would rather it >forbid the nacking of ED options altogether, although shutting down ED >negotiation is probably a reasonable response. There is no force in nature which can successfully forbid a peer from doing anything in its configure requests. It is only the reaction by the receiver which can and should be specified. RFC 1717 is explicit that the receiver MUST remove the ED option it it is NAK'ed. If an implementor reads the document and concludes that some other response can occur from sending an ED NAK, that's pretty sad. On the other hand, if he implemented without carefully reading the RFC (the sort of thing I've been known to do) he should just quietly fix his code. and Keith replies: > ... concluded that it was Tom's intent that Configure-Nak'ing >was forbidden. Yoo-Hoo ... Tom ... Are you there? Is this what you meant? Yeah. It was never my intention that the ED have a negotiable value. Its major function is to determine that one link is NOT coming from the same place as some other link, by causing a miscompare. A peer should not ever change the value while one or more links are connected, EVEN the link being negotiated, since that could cause two links from the same peer to appear different. The requirement to remove ED on receipt of a REJECT is formally correct and consistent with PPP conventions. The requirement to remove ED on receipt of a NAK is not strictly required by the LCP RFC. But in view of the fact that it can not be changed, the requestor has only the choice to repeat the original value (which is now known to be unacceptable for some reason) or drop the ED from the request. I chose the latter, since I thought that this was more likely to lead to an ACK. I considered that the NAK'ing side might have a bug and really meant to REJECT the ED because it did not know what it was. Vernon Schryver also writes: >Configure-Nak? Shouldn't it say that the system "MUST NOT" >Configure-Nak for any other reason, such as a different style of >endpoint? >Yes, I know that would be an odd thing to do, but I have evidence that >some MP implementations are not treating Endpont Discriminators as an >opaque identifier. I think some look at the IP address in that type of >discriminator to decide whether to proced with the connection, even on >the first link of a bundle. While I think this is clearly wrong (the >RFC does not say which IP address a multi-homed host should use as a >discriminator), and it is not strictly relevant, it suggests that some >people might view the discriminator as something to negotiate. It is a >small step from parsing a discriminator to Nak'ing for a different >one. It is wrong to think that the peer receiving the config request can steer the peer sending ED towards a more acceptable class or value. I did intended for that to be impossible. However, the ED does not have to be treated strictly as an opaque identifier. A device may chose to recognize certain forms and draw conclusions about the requestor, through some vendor specific prior agreement. The burden is on the recipient to decide what to do if the ED does not conform to that expectation. If a peer choses to send ED in the IP address class, and it has more than one to chose from, it need only use the same one consistently AS LONG AS ONE OR MORE LINKS ARE CONNECTED, since that is the minimum requirement to prevent erroneous discrimination of links from the same place. Which class or address to chose, when multiple choices are available, is outside the scope of RFC 1717. and finally... Keith Sklower writes: > And, that section being pretty much written by Tom C., ... I've often wondered what percentage of the characters in 1717 I would have had to have written to be listed as a co-author... But then I am reminded to be careful what to wish for. -------------------------------------------------------- Tom Coradetti Sidewalk Software Phone: (612) 490 7856 1190 Josephine Road Email: 70761.1664@compuserve.com Roseville, MN 55113 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue May 23 20:17:13 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id UAA27810; Tue, 23 May 1995 20:17:13 -0400 Resent-Date: Tue, 23 May 1995 20:17:13 -0400 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 23 May 1995 17:15:56 -0700 To: sklower@vangogh.cs.berkeley.edu From: fred@cisco.com (Fred Baker) Subject: Re: On whether RFC1717 can forbid FF03 inside a multilink payload Cc: ietf-ppp@MERIT.EDU Resent-Message-ID: <"5J5H32.0.Io6.6idml"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/501 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU At 7:34 PM 5/23/95, Tom Coradetti wrote: >But careful reading of the base PPP documents helped me conclude that >the FF 03 is not part of the PPP packet, but part of the HDLC definition. very true. If I run PPP/LAPB, there is no FF-03, there is the address of the other system and the control field, which contains send and receive sequence numbers. If I run PPP/FR, There is an address which occupies two octets, the UI or numbered information field, and the NLPID 0xCF. Please leave FF-03 out of the document. M/L is being carried by a generalized carrier, which is itself providing the physical layer header - which happens to be the address/control field and PID of the containing PPP frame. MUST NOT sounds like a good thing, with that context. And maybe you want to pick up the above text as a usage note explaining why, if you feel clarification is required. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "I stand by all the misstatements that I've made." Dan Quayle - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue May 23 20:41:32 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id UAA28937; Tue, 23 May 1995 20:41:32 -0400 Resent-Date: Tue, 23 May 1995 20:41:32 -0400 Date: Tue, 23 May 1995 18:41:13 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199505240041.SAA12568@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: On whether RFC1717 can forbid FF03 inside a multilink payload Resent-Message-ID: <"cqXD3.0.s37.s2eml"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/502 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Tom Coradetti <70761.1664@compuserve.com> > ... > If there is any error here, it is not in RFC 1717, but in the PPP document. > (And I don't think there is really an error there either.) > I must admit that I was orginally confused about where the FF 03 belonged. > But careful reading of the base PPP documents helped me conclude that > the FF 03 is not part of the PPP packet, but part of the HDLC definition. > The fact that LCP allows negotiation of this aspect of the enclosing HDLC > framing does not mean that FF 03 is part of the PPP packet. >Since Multilink fragments PPP packets, not the thing that goes over the medium, > it should SAY NOTHING about FF 03, HDLC, or any other medium related > framing attribute. It is not optional to send FF 03 inside the bundle. It is a > bug. > I had that bug at DigiBoard and fixed it. Anyone else should do the same. > ... An RFC, like any other standards document or even general specification, exists only to serve a purpose. It does not matter that the FF03 is not part of the PPP packet. We are not here to make perfect standards where everything is mentioned exactly once in exactly the right place. On the contrary, we are here to produce documents that ensure as much as possible that implementations built by people who communicate only by reading these documents work. That at least one implementor got it wrong for a while, and that several others have been at least transiently convinced that the others were not wrong is compelling proof that the MP RFC MUST mention the FF03. That a single person misreads a document is always, ALWAYS, good evidence that the document is deficient. When several people misread it or are uncertain about the intended meaning, then the document must be changed. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue May 23 20:54:57 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id UAA29449; Tue, 23 May 1995 20:54:57 -0400 Resent-Date: Tue, 23 May 1995 20:54:57 -0400 Date: Tue, 23 May 1995 18:54:42 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199505240054.SAA12615@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: On NAK'ing endpoint discriminators Resent-Message-ID: <"9OJGm1.0.wB7.UFeml"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/503 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Tom Coradetti <70761.1664@compuserve.com> > ... > There is no force in nature which can successfully forbid a peer from doing > anything in its configure requests. True. > It is only the reaction by the receiver > which >can and should be specified. There is no force in nature which can successfully forbid a peer from doing anything with a received configure request. > RFC 1717 is explicit that the receiver MUST remove > the ED option it it is NAK'ed. If an implementor reads the document and > concludes that some other response can occur from sending an ED NAK, > that's pretty sad. On the other hand, if he implemented without carefully > reading the RFC (the sort of thing I've been known to do) he should just > quietly fix his code. > ... > It was never my intention that the ED have a negotiable value. > Its major function is to determine that one link is NOT coming from the same > place as some other link, by causing a miscompare. A peer should not > ever change the value while one or more links are connected, EVEN the link >being negotiated, since that could cause two links from the same peer to appear > different. > ... It would do no harm to add words like those above, or just something shorter like "ED options MUST NOT be included in a Configure-Nak." Given the fact that no one except the original author of the words now in RFC 1717 was certain of his intended meaning, new words explicity outlawing of Nak'ing ED's are required. Such a prohibition, even without explanation, would illuminate the intended meaing of the words now in RFC 1717. The purpose of any RFC is not to be concise, pretty, or elegant. The only purpose of any RFC is to prevent misunderstanding by imperfect people who often do not read as closely as they ought. Exegesis of standards documents is a nasty business. Let's minimize the need for it. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed May 24 10:42:48 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id KAA28926; Wed, 24 May 1995 10:42:48 -0400 Resent-Date: Wed, 24 May 1995 10:42:48 -0400 Date: Wed, 24 May 1995 10:32:59 -0400 From: Rob Martino Message-Id: <199505241432.KAA18781@olympus.ctron.com> To: ietf-ppp@MERIT.EDU Subject: LZS packet/continuous Resent-Message-ID: <"6YBXS3.0.i37.XNqml"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/504 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I was wondering how most people implement packet versus continuous mode. Fist of all, isn't packet mode simply history count negotiated to be 0? Do you have the user set packet or continuous mode, or just have the default continuous mode, and if you find you are dropping packets or something, switch to packet mode? Are people implementing some statistics capabilities to see if packets are being dropped? Rob - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed May 24 11:08:18 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id LAA00127; Wed, 24 May 1995 11:08:18 -0400 Resent-Date: Wed, 24 May 1995 11:08:18 -0400 Date: Wed, 24 May 1995 11:07:40 -0400 From: John Shriver Message-Id: <199505241507.LAA06564@shiva.shiva.com> To: martino@ctron.com CC: ietf-ppp@MERIT.EDU In-reply-to: <199505241432.KAA18781@olympus.ctron.com> (message from Rob Martino on Wed, 24 May 1995 10:32:59 -0400) Subject: Re: LZS packet/continuous Resent-Message-ID: <"dvHPl2.0.l1.Vlqml"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/505 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I suspect that everyone uses the default of continuous mode -- 1 history. That's the only value I support, propose anything else and you're going to see NAK-ing. This IS one of my marginal comments on the Internet Draft: "is there a default?" One also might ask which values MUST or SHOULD be implemented. I dunno. I don't think the compression ratio is too hot with a history count of 0. You don't save any memory, either. Yes, it does work better that way if a lot of packets are being dropped, but nothing works well if a lot of packets are being dropped, compression or not. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu May 25 17:45:33 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id RAA08227; Thu, 25 May 1995 17:45:33 -0400 Resent-Date: Thu, 25 May 1995 17:45:33 -0400 From: Robert Lutz To: "'Sherry Chiramanaphand'" Cc: IETF PPP Subject: FW: Source code for PPP Stacker LZS compression protocol Date: Thu, 25 May 95 14:43:00 PDT Message-Id: <2FC4FB3D@stac.com> Encoding: 27 TEXT X-Mailer: Microsoft Mail V3.0 Resent-Message-ID: <"7rJlg2.0.I02.dfFnl"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/506 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU sherryc@ims.advantis.com wrote: > I am reading the working draft for PPP Stacker LZS Compression Protocol, > and I would like to know if there is source code that is available to > public. > > Please let me know how to obtain it. Sherry, The complete description of the compression format is included in the Stac LZS PPP Compression standard. A pseudo-code implementation of the Stac LZS algorithm can be found in the ANSI standard ANSI X3.241. The actual implementation of the Stac LZS algorithm is available from Stac Electronics. It is available as software or hardware. The software is available in a variety of languages (including C source code). Although the software implementations require a license from Stac, the C source code version is free of charge. Please contact me or send an email to hardware.sales@stac.com for further information. Robert Lutz Stac Electronics Product Manager 5993 Avenida Encinas (619)794-4545 Carlsbad, CA 92008 (619)794-4577(fax) Email:RLutz@stac.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu May 25 18:26:46 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id SAA09708; Thu, 25 May 1995 18:26:46 -0400 Resent-Date: Thu, 25 May 1995 18:26:46 -0400 From: George Taylor Message-Id: <199505252226.PAA21848@nacho.cisco.com> Subject: Re: FW: Source code for PPP Stacker LZS compression protocol To: rlutz@stac.com (Robert Lutz) Date: Thu, 25 May 95 15:26:00 PDT Cc: sherryc@ims.advantis.com, ietf-ppp@MERIT.EDU In-Reply-To: <2FC4FB3D@stac.com>; from "Robert Lutz" at May 25, 95 2:43 pm X-Mailer: ELM [version 2.3 PL11] Resent-Message-ID: <"dmPVc1.0.TN2.ZGGnl"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/507 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > Robert Lutz writes: > > The complete description of the compression format is included in the Stac > LZS PPP Compression standard. A pseudo-code implementation of the Stac LZS > algorithm can be found in the ANSI standard ANSI X3.241. > > The actual implementation of the Stac LZS algorithm is available from Stac > Electronics. It is available as software or hardware. > > The software is available in a variety of languages (including C source > code). Although the software implementations require a license from Stac, > the C source code version is free of charge. Please contact me or send an > email to hardware.sales@stac.com for further information. The latest version of the C source for Stac LZS includes the ability for the LZS decompress function to use original uncompressed packets for history fix-up. A nice feature, but currently not much use if your using PPP. Your draft document, "PPP Stacker LZS Compression Protocol", makes no use of this new feature. Could this be added in the next release? It doesn't have to be a mandatory field. Making it a negotiable option for backwards software compatibilty would be fine. Something along the lines of the uncompressed length octect used in the "PPP Predictor Compression Protocol", would be great. Thanks, George -- George M. Taylor Voice(Mail): 1.408.526.7754 Software Engineer FAX: 1.408.526.4952 Cisco Systems Inc. Email: gtaylor@cisco.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu May 25 21:03:52 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id VAA15503; Thu, 25 May 1995 21:03:52 -0400 Resent-Date: Thu, 25 May 1995 21:03:52 -0400 Date: Thu, 25 May 1995 19:02:55 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199505260102.TAA00844@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: FW: Source code for PPP Stacker LZS compression protocol Resent-Message-ID: <"10WaQ2.0.xn3.lZInl"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/508 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > > Robert Lutz writes: > ... > > The software is available in a variety of languages (including C source > > code). Although the software implementations require a license from Stac, > > the C source code version is free of charge. ... Is that the same old C source that cannot be modified without buying a STAC license, except "to make it compile," and so cannot be used in any PPP implementation? > From: George Taylor > The latest version of the C source for Stac LZS includes the ability for the > LZS decompress function to use original uncompressed packets for history > fix-up. > > A nice feature, but currently not much use if your using PPP. > Your draft document, "PPP Stacker LZS Compression Protocol", makes no use of > this new feature. > > Could this be added in the next release? It doesn't have to be a mandatory > field. Making it a negotiable option for backwards software compatibilty > would be fine. > Something along the lines of the uncompressed length octect used in the > "PPP Predictor Compression Protocol", would be great. Perhaps I do not understand. If the idea is to feed uncompressed packets into the decompressor, then why is an uncompressed length needed? Why not do as is done in BSD Compress? Feed all packets with most protocol numbers through the decompressor, decompressing those that had protocol 0xFD or 0xFB, and just training the decompressor with the others. That scheme means that no bandwidth is spent on indicating which packets were compressed and which were not. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu May 25 21:30:53 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id VAA16602; Thu, 25 May 1995 21:30:53 -0400 Resent-Date: Thu, 25 May 1995 21:30:53 -0400 From: George Taylor Message-Id: <199505260130.SAA05533@nacho.cisco.com> Subject: Re: FW: Source code for PPP Stacker LZS compression protocol To: vjs@mica.denver.sgi.com (Vernon Schryver) Date: Thu, 25 May 95 18:30:14 PDT Cc: ietf-ppp@MERIT.EDU In-Reply-To: <199505260102.TAA00844@mica.denver.sgi.com>; from "Vernon Schryver" at May 25, 95 7:02 pm X-Mailer: ELM [version 2.3 PL11] Resent-Message-ID: <"xsUFK.0.B34.AzInl"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/509 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > Vernon Schryver writes: > > > George Taylor wrote: > > > > The latest version of the C source for Stac LZS includes the ability for the > > LZS decompress function to use original uncompressed packets for history > > fix-up. > > > > A nice feature, but currently not much use if your using PPP. > > Your draft document, "PPP Stacker LZS Compression Protocol", makes no use of > > this new feature. > > > > Could this be added in the next release? It doesn't have to be a mandatory > > field. Making it a negotiable option for backwards software compatibilty > > would be fine. > > Something along the lines of the uncompressed length octect used in the > > "PPP Predictor Compression Protocol", would be great. > > > Perhaps I do not understand. If the idea is to feed uncompressed > packets into the decompressor, then why is an uncompressed length > needed? It's not. Since it only takes a boolean (i.e. one bit) to say if it's compressed or not and if your going to spend an octet or two on a boolean then fill the rest with something usefull. I only sighted it as an example. Length is not, in this case, important. > Why not do as is done in BSD Compress? Feed all packets with > most protocol numbers through the decompressor, decompressing those > that had protocol 0xFD or 0xFB, and just training the decompressor with > the others. That scheme means that no bandwidth is spent on indicating > which packets were compressed and which were not. Fine, if someone wants to put it in writing that this is the expected behaviour for PPP Stac, I'll go with it. Just give me a standardised method of dealing with this scenario. I personally prefer the Predictor method to the BSD method. Why? I don't like the idea of CCP having to trap "most" protocol packets and process them on the fly. If it's destined for CCP then it should be marked so. BSD's method does save a couple of bytes in header space. That I do like about it. I feel however it's more open to causing future incompatibilities between our various implementations, unless properly defined. "most protocol numbers" - cringe. :-) Anyone else got an opinion on this? George -- George M. Taylor Voice(Mail): 1.408.526.7754 Software Engineer FAX: 1.408.526.4952 Cisco Systems Inc. Email: gtaylor@cisco.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu May 25 22:07:09 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id WAA17743; Thu, 25 May 1995 22:07:09 -0400 Resent-Date: Thu, 25 May 1995 22:07:09 -0400 Date: Thu, 25 May 1995 20:06:22 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199505260206.UAA00931@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: FW: Source code for PPP Stacker LZS compression protocol Resent-Message-ID: <"sMgGF3.0.0L4.1VJnl"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/510 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: George Taylor > ... > Why? I don't like the idea of CCP having to trap "most" protocol packets and > process them on the fly. If it's destined for CCP then it should be marked > so. > BSD's method does save a couple of bytes in header space. That I do like > about it. > I feel however it's more open to causing future incompatibilities between > our various implementations, unless properly defined. > "most protocol numbers" - cringe. :-) > ... If there are room in the draft for future incompatibilities among various implementations of BSD Compress, I'd like to hear of them. It's past time to get done with it. The notion of "most protocol numbers" for BSD Compress is fairly precisely, albeit widely drawn, at all protocol numbers from 0x0 to 0x3FFF except 0xFD and 0xFB. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri May 26 09:50:31 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id JAA12887; Fri, 26 May 1995 09:50:31 -0400 Resent-Date: Fri, 26 May 1995 09:50:31 -0400 Message-Id: <199505261350.JAA12865@merit.edu> From: Kevin Schneider Subject: Re: FW: Source code for PPP Stacker LZS compression protocol To: gtaylor@cisco.com Date: Fri, 26 May 95 8:36:14 CDT Cc: ietf-ppp@MERIT.EDU In-Reply-To: <199505260130.SAA05533@nacho.cisco.com>; from "George Taylor" at May 25, 95 6:30 pm Mailer: Elm [revision: 70.85] Resent-Message-ID: <"2YFLc2.0.893.XoTnl"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/511 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > > > > George Taylor wrote: > > > > > > The latest version of the C source for Stac LZS includes the ability for the > > > LZS decompress function to use original uncompressed packets for history > > > fix-up. > > > > > > A nice feature, but currently not much use if your using PPP. > > > Your draft document, "PPP Stacker LZS Compression Protocol", makes no use of > > > this new feature. > > > > > > Could this be added in the next release? It doesn't have to be a mandatory > > > field. Making it a negotiable option for backwards software compatibilty > > > would be fine. > ... > > Anyone else got an opinion on this? > Our LZS-DCP protocol (used for DSU data compression) uses a header that has a bit to signify compressed or uncompressed. Whether the uncompressed packets are used to update the compression/decompression history is determined by a parameter (Process-Mode) in the configuration option. Since to my knowledge the ability to update the history with uncompressed packets is not yet in the assembly language version of the stac library, my opinion is that the use of this feature should definitely be negotiable. I have a general feeling that there may be times that using uncompressed packets to update the compression history will cause lower compression ratios than otherwise. (e.g. 2 separate tcp streams, one with compressible data, one with non-compressible data, packets interleaved). Providing an ability to distinguish between uncompressed packets that would be used to update the compression history (with the FD or FB PID) and uncompressed packets that would not go to the compression system seems like a good idea. -- Kevin Schneider Phone: (205) 971-8024 ADTRAN, Inc. FAX: (205) 971-8751 901 Explorer Blvd. Huntsville, AL 35806-2807 email: kevin@adtran.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon May 29 19:38:35 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id TAA04249; Mon, 29 May 1995 19:38:35 -0400 Resent-Date: Mon, 29 May 1995 19:38:35 -0400 Date: Mon, 29 May 1995 16:36:59 -0700 (PDT) From: Keith Sklower Message-Id: <199505292336.QAA14472@vangogh.CS.Berkeley.EDU> To: internet-drafts@ietf.CNRI.Reston.Va.US Subject: Proposal: the use of DES in conjunction with PPP Encryption Control Protocol Cc: ietf-ppp@MERIT.EDU Resent-Message-ID: <"Pi1rq1.0._11.Ahbol"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/512 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Fred Baker has authorized this draft to be issued as a working group document (rather than a personal contribution): Network Working Group K. Sklower INTERNET-DRAFT University of California, Berkeley Expires: December 1st, 1995 G. Meyer Spider Systems The PPP DES Encryption Protocol (DESE) draft-ietf-pppext-des-encrypt-00.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 [Page 1] INTERNET-DRAFT PPP DES Encryption June 1995 Acknowledgements The authors extend hearty thanks to Fred Baker of Cisco helpful improvements to the clarity 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 .................................................. 9 10. Authors' Addresses ......................................... 10 11. Expiration Date of this Draft .............................. 10 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 [Page 2] INTERNET-DRAFT PPP DES Encryption June 1995 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 the 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 [Page 3] INTERNET-DRAFT PPP DES Encryption June 1995 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 ro 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. Further, if chaining is not used, even if the key is never deduced, the communication may be subject to replay attacks. 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 [Page 4] INTERNET-DRAFT PPP DES Encryption June 1995 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 1, to indicate the DESE protocol. 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 reply 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 [Page 5] INTERNET-DRAFT PPP DES Encryption June 1995 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 [Page 6] INTERNET-DRAFT PPP DES Encryption June 1995 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, 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. (Additional padding of the ciphered packet for the purposes of transmission by HDLC hardware which requires an even number of bytes should not be necessary since the information field will now be of length a multiple of 8, and whether or not the packet is of even length can be forced by use or absence of a leading zero in the protocol field). For protocols which do have an explicit length field, such as IP, IPX, XNS, and CLNP, then padding may be accomplished by adding random trailing garbage. Even when performing the Multilink protocol, if it is only being applied to packets with explicit length fields, and if care is taken so that all non-terminating fragments (i.e., those not bearing the (E)nd bit) are of lengths divisible by 8; then no ill effects will happen if garbage padding is applied only to terminating fragments. For certain cases, such as the PPP bridging protocol when the trailing CRC is forwarded or when any bridging is being applied to protocols not having explicit length fields, adding garbage changes Sklower & Meyer [Page 7] INTERNET-DRAFT PPP DES Encryption June 1995 the interpretation of the packet. The self-describing padding option [4] permits unambiguous removal of padded bytes; although it should only be used when absolutely necessary as it may inadvertently require adding as many as 8 octets to packets that could otherwise be left unaltered. Consider a packet, which by unlucky circumstance is already a multiple of 8 octets, but terminates in the sequence 0x1, 0x2. Self-describing padding would otherwise remove the trailing two bytes. For purposes of coexistence with archaic HDLC chips where it is necessary to transmit packets of even length, one would normally only have to add an additional two octets (0x1, 0x2), which could then be removed. However, since the packet was initially a multiple of 8 bytes, an additional 8 bytes would need to be added. 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 received 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 P[i] = C[i-1] ^ D[k](C[i]), Sklower & Meyer [Page 8] INTERNET-DRAFT PPP DES Encryption June 1995 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. 9. References [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, Daydreamer, July 1994. Sklower & Meyer [Page 9] INTERNET-DRAFT PPP DES Encryption June 1995 [2] Meyer, G., "The PPP Encryption Protocol", work-in-progress, Spider Systems. [3] Sklower, K., Lloyd, B., McGregor, G., and D. Carr, "The PPP Multilink Protocol (MP)", RFC 1717, UC Berkeley, November, 1994. [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 Spider Systems Stanwell Street Edinburgh EH6 5NG Scotland, UK Phone: (UK) 31 554 9424 Fax: (UK) 31 554 0649 Email: gerry@spider.co.uk 11. Expiration Date of this Draft December 1st, 1995 Sklower & Meyer [Page 10] - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon May 29 21:17:58 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id VAA06631; Mon, 29 May 1995 21:17:58 -0400 Resent-Date: Mon, 29 May 1995 21:17:58 -0400 Date: Mon, 29 May 1995 19:17:32 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199505300117.TAA12256@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: ECP vs. CCP Resent-Message-ID: <"btdyQ.0.Od1.-8dol"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/513 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Gerry Meyer > Date: Tue, 23 May 1995 10:24:44 GMT > ... > An Encrypter wishing to accept the first option (of several) MAY > Configure-Ack ALL Options to indicate complete acceptance of the > first-listed, preferred, algorithm. > ... Is there any chance we could do the same thing for CCP? Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed May 31 06:48:57 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id GAA28974; Wed, 31 May 1995 06:48:57 -0400 Resent-Date: Wed, 31 May 1995 06:48:57 -0400 Date: Tue, 30 May 1995 14:39:15 +0100 From: Gerry Meyer Message-Id: <199505301339.OAA09127@orbweb.spider.co.uk> To: gerry@orbweb.spider.co.uk, ietf-ppp@MERIT.EDU Subject: PPP Encryption Control Protocol (ECP) Resent-Message-ID: <"eayqm2.0.R47.yb4pl"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/514 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU This updated ECP draft contains clarifcation of the text (requested by the IESG) to: - IANA's role - IEEE 802 addresses - Reference to a 'default' ECP encrytion option. - encryption plus compression I have also included section 4.3 on negotiating multiple ECP options. Gerry X----X----X----X----X----X----X----X----X----X----X----X----X----X----X Network Working Group G.M. Meyer Internet Draft Spider Systems Expires Nov 30, 1995 May 1994 The PPP Encryption Control Protocol (ECP) draft-ietf-pppext-encryption-04.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 not appropriate to use Internet Drafts as reference material, or to cite them other than as a ``working draft'' or ``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 ds.internic.net (US East Coast), nic.nordu.net Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Abstract The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol. This document defines a method for negotiating data encryption over PPP links. Conventions The following language conventions are used in the items of specification in this document: o MUST -- the item is an absolute requirement of the specification. Meyer [Page 1] Internet Draft PPP Encryption May 1994 MUST is only used where it is actually required for interopera- tion, not to try to impose a particular method on implementors where not required for interoperability. o SHOULD -- the item should be followed for all but exceptional cir- cumstances. o MAY or optional -- the item is truly optional and may be followed or ignored according to the needs of the implementor. The words "should" and "may" are also used, in lower case, in their more ordinary senses. Table of Contents 1. Introduction ........................................... 2 2. Encryption Control Protocol (ECP) ...................... 3 2.1 Sending Encrypted Datagrams ....................... 4 3. Additional Packets ..................................... 5 3.1 Reset-Request and Reset-Ack ....................... 5 4. ECP Configuration Options .............................. 7 4.1 Proprietary Encryption OUI ........................ 7 4.2 Publicly Available Encryption Types ............... 9 4.3 Negotiating an Encryption Algorithm ............... 9 5. Security Considerations ................................ 10 1. Introduction In order to establish communications over a PPP link, each end of the link must first send LCP packets to configure and test the data link during Link Establishment phase. After the link has been established, optional facilities may be negotiated as needed. One such facility is data encryption. A wide variety of encryption methods may be negotiated, although typically only one method is used in each direction of the link. A different encryption algorithm may be negotiated in each direction, for speed, cost, memory or other considerations. Meyer [Page 2] Internet Draft PPP Encryption May 1994 2. Encryption Control Protocol (ECP) The Encryption Control Protocol (ECP) is responsible for configuring and enabling data encryption algorithms on both ends of the point- to-point link. ECP uses the same packet exchange mechanism as the Link Control Protocol (LCP). ECP packets may not be exchanged until PPP has reached the Network-Layer Protocol phase. ECP packets received before this phase is reached should be silently discarded. The Encryption Control Protocol is exactly the same as LCP [1] with the following exceptions: Frame Modifications The packet may utilise any modifications to the basic frame format which have been negotiated during the Link Establishment phase. Data Link Layer Protocol Field Exactly one ECP packet is encapsulated in the PPP Information field, where the PPP Protocol field indicates type hex 8053 (Encryption Control Protocol). When individual link data encryption is used in a multiple link connection to a single destination [2], the PPP Protocol field indicates type hex 8055 (Individual link Encryption Control Protocol). Code field ECP uses (decimal) codes 1 through 7 (Configure-Request, Configure-Ack, Configure-Nak, Configure-Reject, Terminate- Request, Terminate-Ack and Code-Reject); And may also use code 14 (Reset-Request) and code 15 (Reset-Ack). Other codes should be treated as unrecognised and should result in Code-Rejects. Negotiation ECP packets may not be exchanged until PPP has reached the Network-Layer Protocol phase. An implementation should be prepared to wait for Authentication and Link Quality Determination to finish before timing out waiting for a Configure-Ack or other response. An implementation MUST NOT transmit data until ECP negotiation Meyer [Page 3] Internet Draft PPP Encryption May 1994 has completed successfully. If ECP negotiation is not successful the link SHOULD be brought down. Configuration Option Types ECP has a distinct set of Configuration Options. 2.1 Sending Encrypted Datagrams Before any encrypted packets may be communicated, PPP must reach the Network-Layer Protocol phase, and the Encryption Control Protocol must reach the Opened state. An encrypted packet is encapsulated in the PPP Information field, where the PPP Protocol field indicates type hex 0053 (Encrypted datagram). When using multiple PPP links to a single destination [2], there are two methods of employing data encryption: o The first method is to encrypt the data prior to sending it out through the multiple links. The PPP Protocol field MUST indicate type hex 0053. o The second is to treat each link as a separate connection, that may or may not have encryption enabled. On links which have negotiated encryption, the PPP Protocol field MUST be type hex 0055 (Individual link encrypted datagram). Only one encryption algorithm in each direction is in use at a time, and that is negotiated prior to sending the first encrypted frame. The PPP Protocol field of the encrypted datagram indicates that the frame is encrypted, but not the algorithm with which it was encrypted. The maximum length of an encrypted packet transmitted over a PPP link is the same as the maximum length of the Information field of a PPP encapsulated packet. If the encryption algorithm is likely to increase the size of the message beyond that, multilink should also be negotiated to allow fragmentation of the frames (even if only using a single link). If the encryption algorithm carries history between frames, the encryption algorithm must supply a way of determining if it is passing data reliably, or it must require the use of a reliable transport such as LAPB [3]. Meyer [Page 4] Internet Draft PPP Encryption May 1994 Compression may also be negotiated using the Compression Control Protocol [5]. To ensure interoperability, plain text MUST be: o First compressed. o Then encrypted. This order has been chosen since it should result in smaller output and more secure encryption. 3. Additional Packets The Packet format and basic facilities are already defined for LCP [1]. Up-to-date values of the ECP Code field are specified in the most recent "Assigned Numbers" RFC [4]. This specification concerns the following values: 14 Reset-Request 15 Reset-Ack 3.1 Reset-Request and Reset-Ack Description ECP includes Reset-Request and Reset-Ack Codes in order to provide a mechanism for indicating a decryption failure in one direction of a decrypted link without affecting traffic in the other direction. Some encryption algorithms may not require this mechanism. Individual algorithms need to specify a mechanism for determining how to detect a decryption failure. On initial detection of a decryption failure, an ECP implementation SHOULD transmit an ECP packet with the Code field set to 14 (Reset-Request). The Data field may be filled with any desired data. Once a Reset-Request has been sent, any encrypted packets received are discarded. Further Reset-Requests MAY be sent with the same Identifier, until a valid Reset-Ack is received. When the link is busy, one decryption error is usually followed by several more before the Reset-Ack can be received. It is undesirable to transmit Reset-Requests more frequently than the Meyer [Page 5] Internet Draft PPP Encryption May 1994 round-trip-time of the link, since this will result in redundant Reset-Requests and Reset-Acks being transmitted and processed. The receiver MAY elect to limit transmission of Reset-Requests (to say one per second) while a Reset-Ack is outstanding. Upon reception of a Reset-Request, the transmitting encrypter is reset to an initial state. An ECP packet MUST be transmitted with the Code field set to 15 (Reset-Ack), the Identifier field copied from the Reset-Request packet, and the Data field filled with any desired data. On receipt of a Reset-Ack, the receiving decrypter is reset to an initial state. Since there may be several Reset-Acks in the pipe, the decrypter MUST be reset for each Reset-Ack which matches the currently expected identifier. A summary of the Reset-Request and Reset-Ack packet formats is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+ Code 14 for Reset-Request; 15 for Reset-Ack. Identifier On transmission, the Identifier field MUST be changed whenever the content of the Data field changes, and whenever a valid reply has been received for a previous request. For retransmissions, the Identifier SHOULD remain unchanged. On reception, the Identifier field of the Reset-Request is copied into the Identifier field of the Reset-Ack packet. Data The Data field is zero or more octets and contains uninterpreted Meyer [Page 6] Internet Draft PPP Encryption May 1994 data for use by the sender. The data may consist of any binary value and may be of any length from zero to the peer's established MRU minus four. 4. ECP Configuration Options ECP Configuration Options allow negotiation of encryption algorithms and their parameters. ECP uses the same Configuration Option format defined for LCP [1], with a separate set of Options. Configuration Options, in this protocol, indicate algorithms that the receiver is willing or able to use to decrypt data sent by the sender. Systems may offer to accept several algorithms, and negotiate a single one that will be used. Up-to-date values of the ECP Option Type field are specified in the most recent "Assigned Numbers" RFC [4]. Current values are assigned as follows: ECP Option Encryption type 0 OUI 1 DESE All compliant ECP implementations SHOULD implement ECP option 1 - the PPP DES Encryption Protocol (DESE) [6]. Vendors who want to use proprietary encryption MAY use the OUI mechanism to negotiate these without recourse to requesting an assigned option number from the Internet Assigned Number Authority. 4.1 Proprietary Encryption OUI Description This Configuration Option provides a way to negotiate the use of a proprietary encryption protocol. Vendor's encryption protocols are distinguished from each other by means of an Organisationally Unique Identifier (OUI), namely the first three octets of a Vendor's Ethernet address assigned by IEEE 802. Since the first matching encryption will be used, it is recommended that any known OUI encryption options be transmitted first, before the common options are used. Meyer [Page 7] Internet Draft PPP Encryption May 1994 Before accepting this option, the implementation must verify that the OUI identifies a proprietary algorithm that the implementation can decrypt, and that any vendor specific negotiation values are fully understood. A summary of the Proprietary Encryption OUI Configuration Option format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | OUI ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ OUI | Subtype | Values... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type 0 Length >= 6 IEEE OUI The IEEE OUI is the most significant three octets of an Ethernet Physical Address, assigned to the vendor by IEEE 802. This identifies the option as being proprietary to the indicated vendor. The bits within the octet are in canonical order, and the most significant octet is transmitted first. Subtype This field is specific to each OUI, and indicates an encryption type for that OUI. There is no standardisation for this field. Each OUI implements its own values. Values This field is zero or more octets, and contains additional data as determined by the vendor's encryption protocol. Meyer [Page 8] Internet Draft PPP Encryption May 1994 4.2 Publicly Available Encryption Types Description These Configuration Options provide a way to negotiate the use of a publicly defined encryption algorithm. These protocols should be made available to interested parties, but may have certain licencing or export restrictions associated with them. For additional information, refer to the encryption protocol documents that define each of the encryption types. A summary of the Encryption Type Configuration Option format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Values... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type 1 to 254 Length >= 2 Values This field is zero or more octets, and contains additional data as determined by the encryption protocol. 4.3 Negotiating an Encryption Algorithm ECP uses LCP option negotiation techniques to negotiate encryption algorithms. In contrast with most other LCP or NCP negotiation of multiple options, ECP negotiation is expected to converge on a single mutually agreeable option (encryption algorithm) - or none. Encryption SHOULD be negotiated in both directions, but the algorithms MAY be different. An implementation willing to decrypt using a particular encryption algorithm (or one of a set of algorithms) offers the algorithm(s) as Meyer [Page 9] Internet Draft PPP Encryption May 1994 an option (or options) in an ECP Configure-Request - call this end the Decrypter; call the peer the Encrypter. A Decrypter supporting more than one encryption algorithm may send a Configure-Request containing either: o an ordered list of options, with the most-preferred encryption algorithm coming first. o Or may just offer its preferred (not already Rejected) option. An Encrypter wishing to accept the first option (of several) MAY Configure-Ack ALL Options to indicate complete acceptance of the first-listed, preferred, algorithm. Otherwise, if the Encrypter does not recognise - or is unwilling to support - an option it MUST send a Configure-Reject for that option. Where more than one option is offered, the Encrypter SHOULD Configure-Reject all but a single preferred option. If the Encrypter Configure-Rejects all offered ECP options - and the Decrypter has no further (non-rejected) options it can offer in a Configure-Request - the Encrypter SHOULD take the link down. If the Encrypter recognises an option, but it is not acceptable due to values in the request (or optional parameters not in the request), it MUST send a Configure-Nak with the option modified appropriately. The Configure-Nak MUST contain only those options that will be acceptable. The Decrypter SHOULD send a new Configure-Request with only the single preferred option, adjusted as specified in the Configure-Nak. 5. Security Considerations Negotiation of encryption using PPP is designed to provide protection against eavesdropping on that link. The strength of the protection is dependent on the encryption algorithm used and the care with which any 'secret' used by the encryption algorithm is protected. It must be recognised that complete security can only be obtained through end-to-end security between hosts. References [1] Simpson, W., Editor; "The Point-to-Point Protocol (PPP)", RFC 1548, Computer Systems Consulting Services, December 1993. [2] Sklower, K., Lloyd, B., McGregor, G. and Carr, D., "The PPP Meyer [Page 10] Internet Draft PPP Encryption May 1994 Multilink Protocol (MP)", RFC 1717, University of California, Berkeley, November 1994. [3] Rand, D., "PPP Reliable Transmission", RFC 1663, Novell, July 1994. [4] Reynolds, J., and Postel, J.; "ASSIGNED NUMBERS", RFC 1700, USC/Information Sciences Institute, October 1994. [5] Rand, D., "The PPP Compression Control Protocol (CCP)", work in progress, Novell. [6] Sklower, K., and Meyer, G. "The PPP DES Encryption Protocol (DESE)", work in progress, University of California, Berkeley. Acknowledgements The style and approach of this proposal owes much to the work on the Compression CP [5]. Chair's Address The working group can be contacted via the current chair: Fred Baker Cisco Systems 519 Lado Drive Santa Barbara California 93111 Email: fred@cisco.com Author's Address: Gerry Meyer Spider Systems Stanwell Street Edinburgh EH6 5NG Scotland, UK Phone: (UK) 131 554 9424 Fax: (UK) 131 554 0649 Email: gerry@spider.co.uk Meyer [Page 11] - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed May 31 08:14:46 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id IAA01904; Wed, 31 May 1995 08:14:46 -0400 Resent-Date: Wed, 31 May 1995 08:14:46 -0400 From: Karl Fox Date: Wed, 31 May 95 08:13:56 -0400 Message-Id: <9505311213.AA12568@gefilte.MorningStar.Com> To: Gerry Meyer Cc: gerry@orbweb.spider.co.uk, ietf-ppp@MERIT.EDU Subject: PPP Encryption Control Protocol (ECP) In-Reply-To: <199505301339.OAA09127@orbweb.spider.co.uk> References: <199505301339.OAA09127@orbweb.spider.co.uk> Reply-To: Karl Fox Organization: Morning Star Technologies, Inc. Resent-Message-ID: <"MEbkB1.0.XT.os5pl"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/515 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Gerry Meyer writes: > This updated ECP draft contains clarifcation of the text (requested by the > IESG) to: ... > - Reference to a 'default' ECP encrytion option. ... > ECP Option Encryption type > > 0 OUI > 1 DESE > > All compliant ECP implementations SHOULD implement ECP option 1 - the > PPP DES Encryption Protocol (DESE) [6]. Although I agree that DES is a good and useful standard, it would sure be nice if the required default was allowed to cross national boundaries. At the very least, I would hope it would be exportable from the U.S. I recommend you talk to the NSA about coming up with a simple, non-patentable, exportable encryption algorithm which would serve much the same function as the Predictor-1 compression algorithm. I can get you names and phone numbers if you like. I know this issue is offensive to many people, but it is a very real business concern for every U.S. router company. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed May 31 14:18:07 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id OAA12598; Wed, 31 May 1995 14:18:07 -0400 Resent-Date: Wed, 31 May 1995 14:18:07 -0400 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; cc: ietf-ppp@MERIT.EDU From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-pppext-des-encrypt-00.txt Date: Wed, 31 May 95 13:25:02 -0400 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9505311325.aa05087@IETF.CNRI.Reston.VA.US> Resent-Message-ID: <"hTWwo3.0.d43.MBBpl"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/516 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@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 (DESE) Author(s) : K. Sklower, G. Meyer Filename : draft-ietf-pppext-des-encrypt-00.txt Pages : 10 Date : 05/30/1995 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-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-des-encrypt-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-des-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. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19950530131825.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-des-encrypt-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-des-encrypt-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950530131825.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed May 31 22:05:38 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id WAA25259; Wed, 31 May 1995 22:05:38 -0400 Resent-Date: Wed, 31 May 1995 22:05:38 -0400 From: Karl Fox Date: Wed, 31 May 95 22:04:46 -0400 Message-Id: <9506010204.AA19447@gefilte.MorningStar.Com> To: vjs@mica.denver.sgi.com (Vernon Schryver) Cc: ietf-ppp@MERIT.EDU Subject: Re: FW: Source code for PPP Stacker LZS compression protocol In-Reply-To: <199505260102.TAA00844@mica.denver.sgi.com> References: <199505260102.TAA00844@mica.denver.sgi.com> Organization: Morning Star Technologies, Inc. Resent-Message-ID: <"C8nZl3.0.SA6.Y1Ipl"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/517 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Vernon Schryver writes: > > > Robert Lutz writes: > > > ... > > > The software is available in a variety of languages (including C source > > > code). Although the software implementations require a license from Stac, > > > the C source code version is free of charge. ... > > Is that the same old C source that cannot be modified without buying > a STAC license, except "to make it compile," and so cannot be used in any > PPP implementation? The latest version of STAC's code compiled without error or warning, and runs flawlessly in my environment (I had to whack the daylights out of the previous version to get it to work). It's also substantially faster than the old version. - - - - - - - - - - - - - - - - -