From owner-ietf-ppp@merit.edu Sun May 31 23:57:57 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id XAA13093; Sun, 31 May 1998 23:55:59 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Sun, 31 May 1998 23:51:19 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id XAA13001 for ietf-ppp-outgoing; Sun, 31 May 1998 23:51:18 -0400 (EDT) Received: from att.com (kcgw1.att.com [192.128.133.151]) by merit.edu (8.8.7/8.8.5) with SMTP id XAA12994 for ; Sun, 31 May 1998 23:51:13 -0400 (EDT) Received: by kcgw1.att.com; Sun May 31 22:51 CDT 1998 Received: from gab200r1.ems.att.com (gab200r1.ems.att.com [135.37.94.32]) by kcig1.att.att.com (AT&T/GW-1.0) with SMTP id WAA01800 for ; Sun, 31 May 1998 22:51:10 -0500 (CDT) Received: from njb140bh3.ems.att.com by gab200r1.ems.att.com (SMI-8.6/EMS-1.2 sol2) id XAA13007; Sun, 31 May 1998 23:50:15 -0400 Message-Id: <199806010350.XAA13007@gab200r1.ems.att.com> Received: by njb140bh3.ems.att.com with Internet Mail Service (5.5.1960.3) id ; Sun, 31 May 1998 23:51:09 -0400 From: "Mierloi, Cirus G, NPG NCIO" To: "'ietf-ppp@merit.edu'" Subject: RFC 1619 - POS Date: Sun, 31 May 1998 23:51:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ietf-ppp@merit.edu Hi, I research possible implementation of POS in a large TCP/IP environment. I would like to know what is the standardization state and status of this protocol. Can you point out any information resources and/or examples of successful implementation of TCP/IP over SONET? What is the highest line rate at which existing equipment works for POS (is it OC-192?). Any integration issues? Any help is appreciated! Cirus Mierloi AT&T (908)234-4804 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Jun 1 04:44:06 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id EAA16649; Mon, 1 Jun 1998 04:41:46 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 1 Jun 1998 04:39:30 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id EAA16585 for ietf-ppp-outgoing; Mon, 1 Jun 1998 04:39:30 -0400 (EDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by merit.edu (8.8.7/8.8.5) with ESMTP id EAA16580 for ; Mon, 1 Jun 1998 04:39:25 -0400 (EDT) Received: from chimp.juniper.net (chimp.juniper.net [208.197.169.196]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id BAA18883; Mon, 1 Jun 1998 01:38:54 -0700 (PDT) Received: (from tli@localhost) by chimp.juniper.net (8.7.6/8.7.3) id BAA14969; Mon, 1 Jun 1998 01:38:45 -0700 (PDT) To: cmierloi@att.com (Mierloi, Cirus G, NPG NCIO) cc: ietf-ppp@merit.edu Subject: Re: RFC 1619 - POS References: <199806010350.XAA13007@gab200r1.ems.att.com> From: Tony Li Date: 01 Jun 1998 01:38:45 -0700 In-Reply-To: cmierloi@att.com's message of 1 Jun 98 03:51:04 GMT Message-ID: <823edpbjoq.fsf@chimp.juniper.net> Lines: 46 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-ietf-ppp@merit.edu cmierloi@att.com (Mierloi, Cirus G, NPG NCIO) writes: > I research possible implementation of POS in a large TCP/IP environment. I > would like to know what is the standardization state and status of this > protocol. The PPP portion is of course already a standard. The SONET encapsulation has been implemented by at least Cisco in boards for the 7500 (OC-3) and 12000 (OC-3 and OC-12). I believe that Ascend has also implemented OC-3, but am unaware of any interoperability testing. There was an issue about the payload scrambler that has been resolved and I believe that there is widespread (but not unanimous ;-) consensus on the x^43+1 scrambler. > Can you point out any information resources and/or examples of successful > implementation of TCP/IP over SONET? I believe that Sprintlink has widely deployed this technology in its backbone. > What is the highest line rate at which existing equipment works for POS (is > it OC-192?). I'm unaware of anyone shipping anything faster than OC-12 today, tho have seen several claims. There are some interesting issues with running the HDLC portion of the spec at OC-192 having to do with byte stuffing at that rate. The result may be a slightly different encoding at that rate. > Any integration issues? The primary issue that I know of is the payload scrambler. Early cards do not support the payload scrambler. Newer cards may be forced to have a disableable scrambler. Tony p.s. While I do monitor this technology, I certainly don't claim to be an authoritative source for all relevant data, either public or private. Updates are most welcome. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Jun 5 20:55:43 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id UAA17462; Fri, 5 Jun 1998 20:52:17 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 5 Jun 1998 20:47:02 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id UAA17204 for ietf-ppp-outgoing; Fri, 5 Jun 1998 20:47:01 -0400 (EDT) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by merit.edu (8.8.7/8.8.5) with ESMTP id UAA17192 for ; Fri, 5 Jun 1998 20:46:53 -0400 (EDT) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (8.8.8/8.8.8) with ESMTP id RAA10815; Fri, 5 Jun 1998 17:46:46 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.0.1460.8) id ; Fri, 5 Jun 1998 17:47:31 -0700 Message-ID: From: Tim Pezarro To: "'Tony Li'" , cmierloi@att.com Cc: ietf-ppp@merit.edu Subject: RE: RFC 1619 - POS Date: Fri, 5 Jun 1998 17:47:52 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-ietf-ppp@merit.edu my comment below Tim Pezarro ATM/SONET/SDH Marketing Manager PMC-Sierra, Inc. 105-8555 Baxter Place Burnaby, BC, Canada V5A 4V7 ph: 604-415-6044 fax: 604-415-6208 email: pezarro@pmc-sierra.bc.ca http://www.pmc-sierra.com > -----Original Message----- > From: Tony Li [SMTP:tli@juniper.net] > Sent: Monday, June 01, 1998 1:39 AM > To: cmierloi@att.com > Cc: ietf-ppp@merit.edu > Subject: Re: RFC 1619 - POS > > cmierloi@att.com (Mierloi, Cirus G, NPG NCIO) writes: > > > I research possible implementation of POS in a large TCP/IP environment. > I > > would like to know what is the standardization state and status of this > > protocol. > > > The PPP portion is of course already a standard. The SONET encapsulation > has been implemented by at least Cisco in boards for the 7500 (OC-3) and > 12000 (OC-3 and OC-12). I believe that Ascend has also implemented OC-3, > but am unaware of any interoperability testing. > > There was an issue about the payload scrambler that has been resolved and > I > believe that there is widespread (but not unanimous ;-) consensus on the > x^43+1 scrambler. [Tim Pezarro] Consent is unanimous. ITU, ANSI and IETF have accepted baseline text to include the scrambler. Relevent documents are in the process of being modified and should all be updated by end of 1998. > > Can you point out any information resources and/or examples of > successful > > implementation of TCP/IP over SONET? > > > I believe that Sprintlink has widely deployed this technology in its > backbone. > > > > What is the highest line rate at which existing equipment works for POS > (is > > it OC-192?). > > > I'm unaware of anyone shipping anything faster than OC-12 today, tho have > seen several claims. There are some interesting issues with running the > HDLC portion of the spec at OC-192 having to do with byte stuffing at that > rate. The result may be a slightly different encoding at that rate. > > > > Any integration issues? > > > The primary issue that I know of is the payload scrambler. Early cards do > not support the payload scrambler. Newer cards may be forced to have a > disableable scrambler. > > Tony > > p.s. While I do monitor this technology, I certainly don't claim to be an > authoritative source for all relevant data, either public or private. > Updates are most welcome. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Jun 5 21:13:03 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id VAA17854; Fri, 5 Jun 1998 21:10:21 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 5 Jun 1998 21:09:59 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id VAA17828 for ietf-ppp-outgoing; Fri, 5 Jun 1998 21:09:59 -0400 (EDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by merit.edu (8.8.7/8.8.5) with ESMTP id VAA17819 for ; Fri, 5 Jun 1998 21:09:51 -0400 (EDT) Received: from chimp.juniper.net (chimp.juniper.net [208.197.169.196]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id SAA17803; Fri, 5 Jun 1998 18:09:19 -0700 (PDT) Received: (from tli@localhost) by chimp.juniper.net (8.7.6/8.7.3) id SAA27949; Fri, 5 Jun 1998 18:09:03 -0700 (PDT) Date: Fri, 5 Jun 1998 18:09:03 -0700 (PDT) Message-Id: <199806060109.SAA27949@chimp.juniper.net> From: Tony Li To: Tim_Pezarro@pmc-sierra.bc.ca CC: cmierloi@att.com, ietf-ppp@merit.edu In-reply-to: (message from Tim Pezarro on Fri, 5 Jun 1998 17:47:52 -0700) Subject: Re: RFC 1619 - POS Sender: owner-ietf-ppp@merit.edu | > There was an issue about the payload scrambler that has been resolved and | > I | > believe that there is widespread (but not unanimous ;-) consensus on the | > x^43+1 scrambler. | [Tim Pezarro] Consent is unanimous. ITU, ANSI and IETF have | accepted baseline text to include the scrambler. Relevent documents are in | the process of being modified and should all be updated by end of 1998. I beg to differ. In the interests of global peace, the record does reflect one dissenting voice within the IETF. Thus, we have widespread, but not unanimous consensus. Admittedly, for practical purposes, they are one and the same. Tony - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Jun 8 21:24:52 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id VAA11183; Mon, 8 Jun 1998 21:22:43 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 8 Jun 1998 21:09:53 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id VAA11046 for ietf-ppp-outgoing; Mon, 8 Jun 1998 21:09:52 -0400 (EDT) Received: from notes950.cc.bellcore.com ([192.4.194.238]) by merit.edu (8.8.7/8.8.5) with SMTP id VAA11040 for ; Mon, 8 Jun 1998 21:09:48 -0400 (EDT) From: cchan2@notes.cc.bellcore.com Received: by notes950.cc.bellcore.com(Lotus SMTP MTA v1.1 (385.6 5-6-1997)) id 8525661E.0006517F ; Mon, 8 Jun 1998 21:09:00 -0400 X-Lotus-FromDomain: BELLCORE To: ietf-ppp@merit.edu cc: cchan2@notes.cc.bellcore.com Message-ID: <8525661E.000507D8.00@notes950.cc.bellcore.com> Date: Mon, 8 Jun 1998 21:06:35 -0400 Subject: A question on PPP/AAL5 Mime-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Hi, I've a question on which version of ATM signaling should be used in svc enviroment for PPP/ATM. In "draft-ietf-pppext-aal5-06.txt", it states only Q.2931; but in FRC 1755, ATM Forum UNI 31/40 is assumed. Thanks, Ming Chan Bellcore - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jun 9 05:23:09 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id FAA19806; Tue, 9 Jun 1998 05:19:33 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 9 Jun 1998 05:08:56 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id FAA19679 for ietf-ppp-outgoing; Tue, 9 Jun 1998 05:08:55 -0400 (EDT) Received: from gatekeeper.atml.co.uk (gatekeeper.virata.com [194.129.40.2]) by merit.edu (8.8.7/8.8.5) with ESMTP id FAA19672 for ; Tue, 9 Jun 1998 05:08:49 -0400 (EDT) Received: from boletus.atml.co.uk (root@boletus.atml.co.uk [10.1.3.2]) by gatekeeper.atml.co.uk (8.8.5/8.8.5) with ESMTP id KAA08909 for ; Tue, 9 Jun 1998 10:08:15 +0100 Received: from anawara.atml.co.uk (anawara.atml.co.uk [192.168.219.98]) by boletus.atml.co.uk (8.8.5/8.8.5) with ESMTP id KAA22382 for ; Tue, 9 Jun 1998 10:08:14 +0100 Received: from risso.atml.co.uk (risso.atml.co.uk [192.168.219.57]) by anawara.atml.co.uk (8.8.8/8.8.5) with SMTP id KAA09038 for ; Tue, 9 Jun 1998 10:08:14 +0100 (BST) Received: by risso.atml.co.uk with Microsoft Mail id <01BD938E.6E714CC0@risso.atml.co.uk>; Tue, 9 Jun 1998 10:07:38 +-100 Message-ID: <01BD938E.6E714CC0@risso.atml.co.uk> From: William Stoye To: "ietf-ppp@merit.edu" Subject: RE: A question on PPP/AAL5 Date: Tue, 9 Jun 1998 10:07:36 +-100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Surely it should say something like here is the BLLI information there should be no BHLI all other issues such as which variant of ATM signalling, use of ILMI, QoS, bearer capabilities, traffic class etc. are left unspecified and are implementation/installation decisions. PPP should simply assume the presence of a valid, working signalling service. It would be a mistake to tie PPP to one particular signalling variant. All variants carry BLLI end to end - so far! (although the wording could be clearer for Q.2931's description of BLLI) Is this the intent of the current draft? --William Stoye ---------- From: cchan2@notes.cc.bellcore.com[SMTP:cchan2@notes.cc.bellcore.com] Sent: 09 June 1998 02:06 To: ietf-ppp@merit.edu Cc: cchan2@notes.cc.bellcore.com Subject: A question on PPP/AAL5 Hi, I've a question on which version of ATM signaling should be used in svc enviroment for PPP/ATM. In "draft-ietf-pppext-aal5-06.txt", it states only Q.2931; but in FRC 1755, ATM Forum UNI 31/40 is assumed. Thanks, Ming Chan Bellcore - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jun 9 09:36:36 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id JAA24165; Tue, 9 Jun 1998 09:33:48 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 9 Jun 1998 09:25:25 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id JAA23976 for ietf-ppp-outgoing; Tue, 9 Jun 1998 09:25:25 -0400 (EDT) Received: from notes950.cc.bellcore.com (notes950.cc.bellcore.com [128.96.115.72]) by merit.edu (8.8.7/8.8.5) with SMTP id JAA23968 for ; Tue, 9 Jun 1998 09:25:05 -0400 (EDT) From: cchan2@notes.cc.bellcore.com Received: by notes950.cc.bellcore.com(Lotus SMTP MTA v1.1 (385.6 5-6-1997)) id 8525661E.0049A098 ; Tue, 9 Jun 1998 09:24:12 -0400 X-Lotus-FromDomain: BELLCORE To: ietf-ppp@merit.edu Message-ID: <8525661E.0048BB50.00@notes950.cc.bellcore.com> Date: Tue, 9 Jun 1998 09:21:48 -0400 Subject: A Question on PPP/AAL5 Mime-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Hi, I've a question on which version of ATM signaling should be used in svc enviroment for PPP/ATM. In "draft-ietf-pppext-aal5-06.txt", it states only Q.2931; but in RFC 1755, ATM Forum UNI 31 is assumed. Thanks, Ming Chan Bellcore - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jun 9 10:40:20 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id KAA26256; Tue, 9 Jun 1998 10:38:51 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 9 Jun 1998 10:35:03 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA26080 for ietf-ppp-outgoing; Tue, 9 Jun 1998 10:35:02 -0400 (EDT) Received: from algw2.lucent.com (algw2.lucent.com [205.147.213.2]) by merit.edu (8.8.7/8.8.5) with SMTP id KAA26055 for ; Tue, 9 Jun 1998 10:34:48 -0400 (EDT) Received: from luna3.lc.lucent.com by alig2.firewall.lucent.com (SMI-8.6/EMS-L sol2) id KAA02341; Tue, 9 Jun 1998 10:43:43 -0400 Received: by luna3.lc.lucent.com (SMI-8.6/EMS-1.3.1 sol2) id KAA15719; Tue, 9 Jun 1998 10:31:50 -0400 Date: Tue, 9 Jun 1998 10:31:50 -0400 Message-Id: <199806091431.KAA15719@luna3.lc.lucent.com> From: gmg@luna3.lc.lucent.com (luna3!gmg) To: cchan2@notes.cc.bellcore.com, ietf-ppp@merit.edu Cc: gmgross@lucent.com Subject: Re: A Question on PPP/AAL5 Content-Type: text Sender: owner-ietf-ppp@merit.edu Hi, It really doesn't matter within this context which signaling dialect you use, they all treat the BLLI identically for this application. The ID refers to Q.2931 as an exemplar, as it is the base from which the others derive. There is no reason why you as an implementor could not use ATMF 3.X or ATMF 4.0, they will work too... George - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jun 18 08:48:33 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id IAA25747; Thu, 18 Jun 1998 08:47:43 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 18 Jun 1998 08:43:26 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id IAA25656 for ietf-ppp-outgoing; Thu, 18 Jun 1998 08:43:26 -0400 (EDT) Received: from atlanta.magic.fr (atlanta2.magic.fr [195.115.16.231]) by merit.edu (8.8.7/8.8.5) with ESMTP id IAA25652 for ; Thu, 18 Jun 1998 08:43:21 -0400 (EDT) Received: from www.tsqware.fr (ppp10-123.magic.fr [195.115.17.123]) by atlanta.magic.fr (8.8.8/8.8.8) with SMTP id OAA29555; Thu, 18 Jun 1998 14:43:16 +0200 (MET DST) Received: from tsqware.fr ([192.168.96.125]) by www.tsqware.fr (Lotus SMTP MTA SMTP v4.6 (462.2 9-3-1997)) with SMTP id C1256627.00469C73; Thu, 18 Jun 1998 14:51:15 +0200 Message-ID: <35890A20.2A591AFE@tsqware.fr> Date: Thu, 18 Jun 1998 14:37:52 +0200 From: Jean-Luc Triouleyre X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Working Group IETF-PPP CC: James CARLSON Subject: research for more details about COBS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Dear, I am working in a society dealing with Telecom devices designs. We plan to introduce COBS mechanisms in our next version of our High Speed Serial Lines device before the end of this year ( many of our customers asked it). So i went on the web in order to find more details about COBS; i read the IETF working group memo (november 97) about PPP Consistent Overhead Byte Stuffing and the Stuart David Cheshire Dissertation for his thesis. I noticed that IETF memo expired in may 1998. So does it exists a new revision of the document ? Does it also exists something more normative or a recommendation that presents COBS utilisation (what is mandatory, which kinds of evolution are possible, ...) and LCP format for the COBS configuration (at the initialisation of the communication, for renegociation, ...). Thank you in advance for your help Best regards Jean-Luc ------------------------- Jean-Luc TRIOULEYRE T-SQWARE 6 Parc Ariane - Immeuble Mercure Boulevard des Chenes 78284 GUYANCOURT Cedex FRANCE Email : jean-luc.triouleyre@tsqware.fr tel : 33 (0) 1 39 44 67 59 fax : 33 (0) 1 39 44 29 30 ------------------------- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jun 18 08:58:02 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id IAA25928; Thu, 18 Jun 1998 08:57:59 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 18 Jun 1998 08:57:47 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id IAA25902 for ietf-ppp-outgoing; Thu, 18 Jun 1998 08:57:46 -0400 (EDT) Received: from ironbridgenetworks.com (helios.ironbridgenetworks.com [146.115.140.2]) by merit.edu (8.8.7/8.8.5) with SMTP id IAA25898 for ; Thu, 18 Jun 1998 08:57:43 -0400 (EDT) Received: by ironbridgenetworks.com (SMI-8.6/SMI-SVR4) id IAA17740; Thu, 18 Jun 1998 08:57:35 -0400 Date: Thu, 18 Jun 1998 08:57:35 -0400 Message-Id: <199806181257.IAA17740@ironbridgenetworks.com> From: James Carlson To: Jean-Luc.Triouleyre@tsqware.fr CC: ietf-ppp@merit.edu In-reply-to: <35890A20.2A591AFE@tsqware.fr> (message from Jean-Luc Triouleyre on Thu, 18 Jun 1998 14:37:52 +0200) Subject: Re: research for more details about COBS References: <35890A20.2A591AFE@tsqware.fr> Sender: owner-ietf-ppp@merit.edu > We plan to introduce COBS mechanisms in our next version of our High > Speed Serial Lines device before the end of this year ( many of our > customers asked it). I'd be very interested in hearing what details you could provide. (Please send them to me rather than the list.) > So i went on the web in order to find more details about COBS; i > read the IETF working group memo (november 97) about PPP Consistent > Overhead Byte Stuffing and the Stuart David Cheshire Dissertation > for his thesis. > > I noticed that IETF memo expired in may 1998. So does it exists a > new revision of the document ? There will be soon. I'm working on it. There are a few minor modifications needed before it's published. (If you have any suggestions, please feel free to write me with them.) > Does it also exists something more normative or a recommendation > that presents COBS utilisation (what is mandatory, which kinds of > evolution are possible, ...) and LCP format for the COBS > configuration (at the initialisation of the communication, for > renegociation, ...). Of course, there is also RFC 1661 which describes in particular how LCP options are formatted and used. Is this what you need? (Any time I see the words "normative" and "recommendation," I think of the ITU. COBS isn't an ITU standard, nor do I expect it to become one; it's an IETF working group project.) In order for something to advance through the standards process, it's required that actual implementations be made. This is very different from the way things are done with ITU, ANSI, et cetera. See RFC 2026. -- James Carlson, Consulting S/W Engineer IronBridge Networks / 55 Hayden Avenue 71.246W Vox: +1 781 402 8032 Lexington MA 02173-7999 / USA 42.423N Fax: +1 781 402 8092 "PPP Design and Debugging" ------------- http://id.wing.net/~carlson/ppp - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jun 18 13:24:17 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id NAA29923; Thu, 18 Jun 1998 13:22:41 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 18 Jun 1998 13:21:51 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id NAA29901 for ietf-ppp-outgoing; Thu, 18 Jun 1998 13:21:51 -0400 (EDT) Received: from ironbridgenetworks.com (helios.ironbridgenetworks.com [146.115.140.2]) by merit.edu (8.8.7/8.8.5) with SMTP id NAA29897 for ; Thu, 18 Jun 1998 13:21:47 -0400 (EDT) Received: by ironbridgenetworks.com (SMI-8.6/SMI-SVR4) id NAA04979; Thu, 18 Jun 1998 13:21:46 -0400 To: ietf-ppp@merit.edu Path: not-for-mail From: Wayne Mesard Newsgroups: lists.ietf.ppp Subject: cmsg cancel <199806181707.NAA29732@merit.edu> Control: cancel <199806181707.NAA29732@merit.edu> Date: 18 Jun 1998 13:18:55 -0400 Organization: IronBridge Networks Lines: 1 Message-ID: <7gg1h2d3wg.fsf@tofu.ibnets.com> NNTP-Posting-Host: tofu.ironbridgenetworks.com Sender: owner-ietf-ppp@merit.edu I am canceling my own article. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Jun 19 04:55:01 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id EAA15692; Fri, 19 Jun 1998 04:53:08 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 19 Jun 1998 04:52:09 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id EAA15670 for ietf-ppp-outgoing; Fri, 19 Jun 1998 04:52:09 -0400 (EDT) Received: from wally.cooptel.qc.ca (wally.cooptel.qc.ca [206.167.253.10]) by merit.edu (8.8.7/8.8.5) with SMTP id EAA15666 for ; Fri, 19 Jun 1998 04:52:02 -0400 (EDT) From: mauricep@sym.com.tw Received: from 206.167.253.10 by wally.cooptel.qc.ca via SMTP (951211.SGI.8.6.12.PATCH1502/940406.SGI.AUTO) id EAA02119; Fri, 19 Jun 1998 04:37:44 -0400 Date: Fri, 19 Jun 98 03:47:38 EST To: richard23@sym.com.tw Subject: Do you market on the Internet? Message-ID: <17345945.197D@mail> X-PMFLAGS: 570949760 0 X-UIDL: 887812308.018 Comments: Authenticated sender is Sender: owner-ietf-ppp@merit.edu Dear Internet Marketer, Are you tired of endlessly posting your ad to online classified sites that just don't get the job done? The fact is there are over 300 such sites scattered about the Web and frankly none of them generate enough traffic to be worth your while. Even when someone does visit one of these sites, your ad is hopelessly lost in a myriad of similar offerings. The true professionals of online marketing have known for some time that nothing creates results the way a direct bulk email campaign does. We have assembled a complete package on one CD-ROM that will enable to get your message out to millions for surprisingly little cost and effort. INTRODUCING...MILLIONS VOL. 1 We took a total of over 92 million email addresses from many of the touted CD's that are out there (bought them all - some were $300+)! We added the millions we had in storage to those. When we combined them all, we had in excess of 100+ million addresses in one huge file. We then ran a super "sort/de-dupe" program against this huge list. It cut the file down to less than 25 million!!! Can you believe that? It seems that most people that are selling CD's are duping the public by putting numerous files of addresses in the CD over and over. This created many duplicate addresses. They also had many program "generated" email addresses like Compuserve, MCI, ANON's, etc. This causes a tremendous amount of undeliverables, and for those that use Stealth programs, clogs up servers quickly with trash, etc. We then ran a program that contained 150+ keywords to remove addresses with vulgarity, profanity, sex-related names, postmaster, webmaster, flamer, abuse, spam, etc., etc. Also eliminated all .edu, .mil, .org, .gov, etc. After that list was run against the remaining list, it reduced it down to near 16 million addresses! So, you see, our list will save people hundreds of dollars buying all others that are out there on CD and otherwise. Using ours will be like using the 100+ million that we started with, but a lot less money and a lot less time!! Besides the 16 Million general email address we include over 400,000 TARGETED addresses of Business Opportunity Seekers, MLM'ers and other Internet Marketers. These are people EAGER to hear about your products and services. Other services charge upwards of 5 cents per address for this type of list. We include it at no extra extra charge when you purchase Millions Vol. 1 We also purchased Cyber-Promo's ($995.00) CD. We received it just prior to finishing production work on the new CD. We had our people take a random sample of 300,000 addresses from the touted 2.9 million that they advertised. We used a program that allows us to take a random sample of addresses from any list. We were able to have the program take every 9th address, thus giving us a 300,000 list of Cyber's email addresses from top to bottom. We did not clean these, but we did create 3 separate files named cyber1.txt, cyber2.txt, & cyber3.txt of 100,000 addresses each. This will give all people that use the list an opportunity to send mail to the list before deciding if their CD is all it's hyped to be. We also included a 5+ million "Remove/Flamer" file broken into seperate files for ease of extracting and adding to your own database of removes. To help you manage your email lists, you'll find a fully functional evaluation copy of BulkMate 4.04 on your CD. BulkMate is an indispensible tool for the serious bulk mailer. Among its 10 utilites are the ability to filter any address list against a remove list, sort any list alphabetically and automatically remove dupes, remove specific domains from any list and count the number of addresses in each list. "You can buy from the REST or you can buy from the BEST. Your choice. _____________________________ What our clients are saying: "I received the CD on Friday evening. Like a kid with a new toy, I immediately started bulking out using the new email addresses. Over the course of the weekend, I emailed out over 500,000 emails and I received less than TWENTY undeliverables!! I am totally satisfied with my purchase!! Thanks Syrynx!!" Dave Buckley Houston, TX "This list is worth it's weight in gold!! I sent out 10,000 emails for my product and received 185 orders! Ann Colby New Orleans, LA "I am absolutely delighted! Your support is first rate. When I needed help you were there for me. I got a real person on the phone. I've been marketing my product now for two weeks and can't believe how many orders I've received. I can't thank you enough! Gail Swanton Boston, MA **************************************** HERE'S THE BOTTOM LINE Here is what you get when you order today! >> 16 Million Email Addresses... 1 per line in simple text format on a CD. Files are in lots of 100,000 (no codes needed to open files). All files are separated by domain name for your convenience. PLUS you receive a tremendous REMOVE list! AND Over 400,000 Targeted email addresses. AND The sampling of CyberPromo's HOT list. AND BulkMate 4.04 The ultimate mail management tool. >>> NOW ONLY $149.00! All lists are completely free of any duplicates. We also on a continual basis, add New Names and Remove Undeliverables and Remove Requests. The result is the Cleanest Email Addresses Available Anywhere to use over and over again, for a FRACTION of the cost that other companies charge. Typical rates for acquiring email lists are from 1 cent to as high as 3 cents per email address - that's "INFORMATION HIGHWAY" ROBBERY!. Don't even hesitate on this one or you will miss out on the most effective way to market anywhere..PERIOD! >>>As a special bonus we've included the entire suite of Earthonline >>>bulk email and marketing software demos on the CD. Including >>>the just released DirectMail 2.0 mailer. Use it free for 10 days !! >>>You'll also get our private Website address where you can check >>> for product upgrades and other valuable marketing information. To order our email package, simply print out the EZ ORDER FORM below and fax or mail it to our office today. We accept Checks by Fax and Mail and C.O.D. _________________ EZ Order Form _____Yes! I would like to order MILLIONS Vol. 1 email addresses for only $149.00. All orders are sent by US Priority Mail and we pay the shipping costs! ORDERING OPTIONS *Mail (USPS) *Include a check or money order for the correct amount. *Make the check payable to: Syrynx, Inc. *Include your phone number and/or email address in case we need to contact you. *Mail to: Syrynx, Inc. 500 Lake Avenue Suite 154 Lake Worth, Florida 33460 *C.O.D. *Fill out the order form completely and write/type COD on the form. *Mail the form to the above address or fax to 305-418-7590 *Please have a certified/cashiers check or money order in the amount of $165.00 payable to Syrynx, Inc ready when the order arrives. The additonal $16.00 covers overnight shipping and C.O.D. fees. *Fax *This is the preferred payment method at Syrynx, Inc. *ALL FUNDS ARE TO BE IN USA CURRENCY. *Your order can be received 24 hours a day, 7 days a week. *Print out and complete the following form. *To this form, attach a BLANK CHECK with "VOID" written somewhere on the body of the check. *This gives us the necessary account information to process your order. *Please note that Syrynx, Inc. charges a $40.00 fee for ALL BAD CHECKS. Thank you for your order. Syrynx, Inc. ********** MILLIONS VOL.1 ORDER FORM ********** *You must complete the entire form or your order can not be processed. *You will need to tape the blank check in the space indicated below. *Fill out and sign the authorization section below. *Fax the ENTIRE FORM to (305) 418-7590. *Please, print the following information. First Name: _______________________________________________________ Last Name: _______________________________________________________ Street Address: ___________________________________________________ _________________________________________________________________ City: ____________________________________________________________ State: _____________________ Zip: _________________________ Phone Number: __________________________________________________ EMail Address: ___________________________________________________ * * * * * * * * * * Authorization * * * * * * * * * * (leave blank for C.O.D. orders) I, ________________________________________________, hereby authorize Syrynx, Inc. to withdraw $________________________ from my checking account, account information enclosed, one time only, for the purchase of the Millions Vol. 1 CD-ROM. I have read and I understand the terms and conditions as stated above. The signature below is the authorized signature of the holder of the checking account. I understand that Syrynx, Inc. charges $40.00 for bad checks. I understand that if the funds are not available in my account, I agree to pay the amount of this order plus the $40.00 fee. (Cash or Certified Funds Only). Authorized Signature _______________________________________________ Date: __________________ order code:mvi *Attach voided, blank check below. (do not attach check for C.O.D. orders) - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Sun Jun 21 04:36:52 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id EAA12437; Sun, 21 Jun 1998 04:34:54 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Sun, 21 Jun 1998 04:27:46 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id EAA12372 for ietf-ppp-outgoing; Sun, 21 Jun 1998 04:27:46 -0400 (EDT) Received: from messenger.rnd.co.il ([209.88.177.2]) by merit.edu (8.8.7/8.8.5) with ESMTP id EAA12368 for ; Sun, 21 Jun 1998 04:27:39 -0400 (EDT) Received: by MESSENGER with Internet Mail Service (5.5.1960.3) id ; Sun, 21 Jun 1998 11:29:19 +0200 Message-ID: <0124851EDBF3D011AAA300008370C86711214B@MESSENGER> From: Michael Liwerant To: "'ietf_ppp'" Subject: BAP Negotiation - Link Types Date: Sun, 21 Jun 1998 11:29:15 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: multipart/alternative; boundary="---- =_NextPart_001_01BD9CF7.10320260" Sender: owner-ietf-ppp@merit.edu This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------ =_NextPart_001_01BD9CF7.10320260 Content-Type: text/plain Hi all, Can someone point to the exact 'link type' category (specified in RFC 2125 page 15) which is respective to each of the following kind of lines: a) Analog leased line (versus Analog dial-up modem line). b) ISDN dial-up (PRI and/or BRI). c) ISDN 'leased line' (also known in Japan as 'I Interface' - versus ISDN dial-up). c) Frame Relay. I will appreciate your help (even if you are familiar with partial information). Michael Liwerant - RADWIZ WAN Solutions. ------ =_NextPart_001_01BD9CF7.10320260 Content-Type: text/html Content-Transfer-Encoding: quoted-printable BAP Negotiation - Link Types

Hi all,

Can someone point to the exact 'link = type' category (specified in RFC 2125 page 15) which is respective to = each of the following kind of lines:

a) Analog leased line (versus Analog = dial-up modem line).
b) ISDN dial-up (PRI and/or = BRI).
c) ISDN 'leased line' (also known in = Japan as 'I Interface' - versus ISDN dial-up).
c) Frame Relay.

I will appreciate your help (even if = you are familiar with partial information).

Michael Liwerant - RADWIZ WAN = Solutions.

------ =_NextPart_001_01BD9CF7.10320260-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Jun 22 09:56:38 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id JAA25893; Mon, 22 Jun 1998 09:54:38 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 22 Jun 1998 09:50:19 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id JAA25812 for ietf-ppp-outgoing; Mon, 22 Jun 1998 09:50:19 -0400 (EDT) Received: from flipper.cisco.com (flipper.cisco.com [171.69.63.10]) by merit.edu (8.8.7/8.8.5) with ESMTP id JAA25808 for ; Mon, 22 Jun 1998 09:50:15 -0400 (EDT) Received: from flipper.cisco.com (flipper.cisco.com [171.69.63.10]) by flipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with SMTP id GAA25178; Mon, 22 Jun 1998 06:49:20 -0700 (PDT) Date: Mon, 22 Jun 1998 06:49:20 -0700 (PDT) From: John Bray To: Michael Liwerant cc: "'ietf_ppp'" Subject: Re: BAP Negotiation - Link Types In-Reply-To: <0124851EDBF3D011AAA300008370C86711214B@MESSENGER> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Ummm... Why do you need definitions for leased lines? BAP is used for dynamically adding/dropping links. That sort of implies dialed/switched lines, doesn't it? John On Sun, 21 Jun 1998, Michael Liwerant wrote: > Hi all, > > Can someone point to the exact 'link type' category (specified in RFC > 2125 page 15) which is respective to each of the following kind of > lines: > > a) Analog leased line (versus Analog dial-up modem line). > b) ISDN dial-up (PRI and/or BRI). > c) ISDN 'leased line' (also known in Japan as 'I Interface' - versus > ISDN dial-up). > c) Frame Relay. > > I will appreciate your help (even if you are familiar with partial > information). > > Michael Liwerant - RADWIZ WAN Solutions. > > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Jun 22 11:08:31 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id LAA27413; Mon, 22 Jun 1998 11:07:01 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 22 Jun 1998 11:06:20 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id LAA27369 for ietf-ppp-outgoing; Mon, 22 Jun 1998 11:06:19 -0400 (EDT) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by merit.edu (8.8.7/8.8.5) with ESMTP id LAA27354 for ; Mon, 22 Jun 1998 11:06:12 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.8.5/calcite) id JAA01879 for ietf-ppp@merit.edu mail_from ; Mon, 22 Jun 1998 09:06:09 -0600 (MDT) Date: Mon, 22 Jun 1998 09:06:09 -0600 (MDT) From: Vernon Schryver Message-Id: <199806221506.JAA01879@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: BAP Negotiation - Link Types Sender: owner-ietf-ppp@merit.edu > Ummm... Why do you need definitions for leased lines? BAP is used > for dynamically adding/dropping links. That sort of implies > dialed/switched lines, doesn't it? A better question is, given L2TP why you need (or care about) BAP at all. Since the last time I made my "BAP/BACP/MPPP/MP+ is snake oil" rant, I've been playing with a Cisco box that talks to some Ascend boxes, both supporting BAP/BACP/MPPP/MP+. I've been unable to detect any effective difference with BAP/BACP/MPPP/MP+ enable or disabled. I figured that given the opportunity, I should at least check my claims. BAP/BACP is theoretically useful for allowing two or more boxes in a single hunt-group and that do not support L2TP to act as a single box, but useless for any other purpose. If you have two or more boxes that need to answer MP calls and the boxes don't support L2TP, then it is generally necessary to cause the peers to dial the same box that their first phone call reached. That implies the boxes need to communicate the phone numbers of reserved ports. The second-link phone numbers must be reserved and not in the main hunt-group, since otherwise the probability that each box will have available ports is too low. That almost everyone who is willing reserve 30-50% of their ports to is also or more willing to put each box into its own hunt group is one reason why BAP/BACP is in practice essentially never used for this purpose. That there are literaly millions of PPP "clients" that support MP but not BAP/BACP is another compelling reason for not relying on BAP/BACP for the second port phone number. Another consideration is that a major reason for starting L2TP was to eliminate the need for PPP "clients" to know anything about the number of boxes composing the "server", including not needing any new PPP protocol support. There were and are no other valid technical justifications for BAP/BACP. One bogus but frequently made claim was that "servers" can measure the link load but "clients" cannot. As now demonstrated by zillions commercial PPP products, that was silly. As long as the MP bundle contains at least one link, each of a pair of PPP peers can compute the loading of their link in both directions. That means that having a PPP "server" tell the "client" what the client already knows, whether their link is saturated, is useless. BAP/BACP was intended to run on "servers" typically operated by internet service providers, providing service that is billed to those running "clients." Who would willingly delegate the decisions on when to add another link to an MP bundle (e.g. at 10% or 100%s staturation) to the outfit that makes up the bills? No one would trust an ISP to never "accidentally" set the add-a-link threshold to 10%, except when an additional link is free, and then they'd not trust the ISP to not set the threshold at infinity instead of 0%. Everyone wants their own clients to count bits and make the add-link decisions. That implies the facilities in BAP/BACP/MPPP/MP+ for the "server" telling the "client" to add a link are uninteresting. BAP/BACP/MPPP/MP+ cannot help with communicating the bundle utilization during the only time when the "client" does not already know it, when there are no links in the bundle. BAP/BACP/MPPP/MP+ also does not help with phone numbers when you need such help the most, when you cannot get the first link up. In the last couple of years, there has been talk that BAP/BACP/MPPP/MP+ is needed to support D-channel data, on the grounds that "clients" cannot figure out that they are sending or receiving close to 16 kbps and so need to add a B channel. Of course, the talk is never phrased that way, since it makes the reasoning sound rather weak. Early in the days of BAP as distinct from BACP/MPPP/MP+, it was suggested that PPP "servers" would use BAP to tell "clients" whether they have permission to add another link. In the real world, such facilities are not used or implemented that way. Instead, higher priority is given to "bosses" (one suggested catagory) by using different phone numbers. Peons or customers with low priority service dial additional lines regardless of whether the "server" says yea or nay. All reasonable "client" implementations do the obvious right things when phone calls for additional links in an MP bundle don't work, regardless of what BAP/BACP/MPPP/MP+ has or has not said. Vernon Schryver vjs@rhyolite.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Jun 22 14:28:43 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id OAA02792; Mon, 22 Jun 1998 14:27:02 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 22 Jun 1998 14:26:26 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA02760 for ietf-ppp-outgoing; Mon, 22 Jun 1998 14:26:25 -0400 (EDT) Received: from relay.efficient.com (relay.efficient.com [198.211.94.10]) by merit.edu (8.8.7/8.8.5) with SMTP id OAA02756 for ; Mon, 22 Jun 1998 14:26:18 -0400 (EDT) Received: from efficient.com ([198.211.94.14]) by relay.efficient.com (8.6.10/8.6.10) with ESMTP id NAA22121 for ; Mon, 22 Jun 1998 13:27:09 -0500 Received: from wanda.efficient.com (wanda [198.211.94.201]) by efficient.com (8.8.5/8.8.5) with SMTP id NAA27141 for ; Mon, 22 Jun 1998 13:25:22 -0500 (CDT) Received: by wanda.efficient.com (SMI-8.6/SMI-SVR4) id NAA21957; Mon, 22 Jun 1998 13:24:18 -0500 Date: Mon, 22 Jun 1998 13:24:18 -0500 From: tbuckley@efficient.com (Terry Buckley) Message-Id: <980622132417.ZM21955@wanda> X-Mailer: Z-Mail (4.0.1 13Jan97) To: ietf-ppp@merit.edu Subject: PPP Over ATM AAL5 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-ppp@merit.edu The draft does a good job at addressing the header questions and the other ATM related areas. While considering implementation the following came up. Should the draft have the following statments added ? 1. No ACCM escaping of any data is required. 2. CRC is not required in the PPP packet, the AAL5 CRC guarantees data integrity. 3. The CPCS-SDU size for PPP over ATM is 1536. Or state what the MTU really is in the real world... Thanks, Terry ------------------------------------------------------------------------------ Terry Buckley tbuckley@efficient.com Efficient Networks, Inc. "You can never be too rich, too thin, (972) 991-3884 or have too much bandwidth" (972) 991-3887(fax) http://www.efficient.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Jun 22 14:48:08 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id OAA03259; Mon, 22 Jun 1998 14:46:41 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 22 Jun 1998 14:46:20 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA03231 for ietf-ppp-outgoing; Mon, 22 Jun 1998 14:46:20 -0400 (EDT) Received: from volitans.MorningStar.Com (volitans.MorningStar.Com [137.175.2.11]) by merit.edu (8.8.7/8.8.5) with ESMTP id OAA03227 for ; Mon, 22 Jun 1998 14:46:16 -0400 (EDT) Received: from carp.morningstar.com (root@carp.MorningStar.Com [137.175.81.4]) by volitans.MorningStar.Com (8.8.7/) with ESMTP id OAA17476 for ; Mon, 22 Jun 1998 14:46:14 -0400 (EDT) Received: by carp.morningstar.com (8.8.8/95031605) id OAA12646; Mon, 22 Jun 1998 14:46:12 -0400 (EDT) From: Karl Fox Reply-To: Karl Fox To: ietf-ppp@merit.edu Subject: Microsoft PPP CHAP Extensions - Working Group Last Call Date: 22 Jun 1998 14:46:11 -0400 Message-ID: Lines: 7 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-ietf-ppp@merit.edu This is last call. I will advise the area directors that we want to take Microsoft PPP CHAP Extensions (draft-ietf-pppext-mschap-00.txt) to Informational Standard on July 7 unless there is substantive comment raised on the list. -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Jun 22 16:21:55 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id QAA05226; Mon, 22 Jun 1998 16:19:55 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 22 Jun 1998 16:19:04 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id QAA05142 for ietf-ppp-outgoing; Mon, 22 Jun 1998 16:19:03 -0400 (EDT) Received: from ihgw1.lucent.com (ihgw1.lucent.com [207.19.48.1]) by merit.edu (8.8.7/8.8.5) with SMTP id QAA05127 for ; Mon, 22 Jun 1998 16:18:57 -0400 (EDT) Received: from luna3.lc.lucent.com by ihig1.firewall.lucent.com (SMI-8.6/EMS-L sol2) id PAA09749; Mon, 22 Jun 1998 15:43:44 -0500 Received: by luna3.lc.lucent.com (SMI-8.6/EMS-1.3.1 sol2) id QAA16426; Mon, 22 Jun 1998 16:18:38 -0400 Date: Mon, 22 Jun 1998 16:18:38 -0400 Message-Id: <199806222018.QAA16426@luna3.lc.lucent.com> From: gmg@luna3.lc.lucent.com (luna3!gmg) To: tbuckley@efficient.com (Terry Buckley), ietf-ppp@merit.edu Cc: gmgross@lucent.com Subject: Re: PPP Over ATM AAL5 Content-Type: text Sender: owner-ietf-ppp@merit.edu Hi Terry, > The draft does a good job at addressing the header questions and the other ATM > related areas. thank you :-) > While considering implementation the following came up. > > Should the draft have the following statments added ? > > > 1. No ACCM escaping of any data is required. Section 9 in the ID discusses LCP option negotiation, and it states that ACCM must not be requested, and it must be rejected if it is requested. Within RFC1662, section 7.1 specifies that the default ACCM value is 0. > > 2. CRC is not required in the PPP packet, the AAL5 CRC guarantees data > integrity. Section 1 in the ID points out that the virtual connection will include error detection but not error correction. > > 3. The CPCS-SDU size for PPP over ATM is 1536. Or state what the MTU really is > in the real world... > > Section 9 only requires that the MRU must not be negotiated to a larger size than the maximum CPCS-SDU size in the associated direction. Both the max CPCS-SDU length and MRU value are implementation dependent and often can be set under admin control. Hope this clarifies things... George - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jun 24 15:46:59 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id PAA13253; Wed, 24 Jun 1998 15:44:58 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 24 Jun 1998 15:38:28 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id PAA13132 for ietf-ppp-outgoing; Wed, 24 Jun 1998 15:38:27 -0400 (EDT) Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by merit.edu (8.8.7/8.8.5) with ESMTP id PAA13128 for ; Wed, 24 Jun 1998 15:38:23 -0400 (EDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns2.raleigh.ibm.com (AIX4.2/UCB 8.7/8.7RTP-FW1.1) with ESMTP id PAA40698 for ; Wed, 24 Jun 1998 15:38:19 -0400 (EDT) Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.83.123]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id PAA38596 for ; Wed, 24 Jun 1998 15:38:22 -0400 Received: from localhost.raleigh.ibm.com (localhost.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (AIX4.3/UCB 8.7/8.7/RTP-ral-1.0) with SMTP id PAA16592 for ; Wed, 24 Jun 1998 15:38:20 -0400 (EDT) Message-Id: <199806241938.PAA16592@cichlid.raleigh.ibm.com> X-Authentication-Warning: cichlid.raleigh.ibm.com: Host localhost.raleigh.ibm.com [127.0.0.1] didn't use HELO protocol To: ietf-ppp@merit.edu Subject: PPP encryption documents Date: Wed, 24 Jun 1998 15:38:16 -0400 From: Thomas Narten Sender: owner-ietf-ppp@merit.edu The IESG recently discussed the following 2 PPP encryption documents: draft-ietf-pppext-3des-encrypt-00.txt draft-ietf-pppext-des-encrypt-v2-02.txt The two documents are up for consideration as Proposed Standards. During the IESG discussions, we observed that the two PPP encryption drafts only do encryption, and do not include any authentication. The IPSec folks were convinced a while back that encryption without authentication (i.e., integrity protection) is a Bad Thing. Consequently IPSec's ESP transform now includes an authentication MAC. At the very least, this should be mentioned in the Security Considerations section the two PPP documents. Beyond that, what the PPP group wants to do requires discussion. I suspect that the WG may want to publish one or both drafts anyway (i.e., with no on-the-wire protocol change) as at least for the single DES draft, this document updates an RFC that presumably has seen deployment. An important piece of data here is how much deployment the existing single DES RFC has seen. The WG may also decide that its worth defining a stronger transform that does both encryption/authentication. This could be a follow-on work item independent of the existing documents, or a replacement of the above drafts. If this route is chosen, some thought should be given to what the status of the documents should be. I.e, if a new, better transform is to be defined, perhaps the current drafts should be marked informational (gee, isn't that where we started?) with the new transform being the one to go on standards track. It is probably also worth noting that the use/deployment of L2TP tunnels may increase the desirability of having a per-packet PPP authentication capability, something that is missing now (one can authenticate the creation of a session, but not each individual packet of the session). Comments? Thomas - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jun 24 16:11:41 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id QAA13744; Wed, 24 Jun 1998 16:10:19 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 24 Jun 1998 16:09:58 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id QAA13720 for ietf-ppp-outgoing; Wed, 24 Jun 1998 16:09:57 -0400 (EDT) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by merit.edu (8.8.7/8.8.5) with ESMTP id QAA13715 for ; Wed, 24 Jun 1998 16:09:52 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.8.5/calcite) id OAA07397 mail_from ; Wed, 24 Jun 1998 14:09:49 -0600 (MDT) Date: Wed, 24 Jun 1998 14:09:49 -0600 (MDT) From: Vernon Schryver Message-Id: <199806242009.OAA07397@calcite.rhyolite.com> To: ietf-ppp@merit.edu, narten@raleigh.ibm.com Subject: Re: PPP encryption documents Sender: owner-ietf-ppp@merit.edu > From: Thomas Narten > ... > During the IESG discussions, we observed that the two PPP encryption > drafts only do encryption, and do not include any authentication. The > IPSec folks were convinced a while back that encryption without > authentication (i.e., integrity protection) is a Bad Thing. > ... How is that? Why doesn't having enough valid keys to encrypt and decrypt the data implicitly authenticate the identity of the sender to the receiver? (assuming, of course, there is protection against replay, etc.) > ... > The WG may also decide that its worth defining a stronger transform > that does both encryption/authentication. ... Given the very unfortunate history of PPP authentication (bugs, holes, bad implementations, after LCP instead of during), having yet another kind of PPP thing also called authentication sounds like can of worms. > ... > It is probably also worth noting that the use/deployment of L2TP > tunnels may increase the desirability of having a per-packet PPP > authentication capability, something that is missing now (one can > authenticate the creation of a session, but not each individual packet > of the session). Given the problems the L2TP people have had with security, that sounds a little messy. At the very least, such considerations should not be allowed to derail or delay L2TP. Besides, isn't the L2TP position that anyone who really cares about security below the application layer will be using IPSEC below the L2TP-PPP tunnel? Consider that PPP is a link-layer protocol, even when used for tunneling. Wouldn't it be cleaner all around to say "if you want security, use IPSEC"? And again, if the bad guy has enough keys to encrypt or decrypt data, why won't he also have enough keys to authenticate forgeries? Vernon Schryver vjs@rhyolite.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jun 24 17:17:56 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id RAA15411; Wed, 24 Jun 1998 17:17:48 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 24 Jun 1998 17:16:54 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id RAA15383 for ietf-ppp-outgoing; Wed, 24 Jun 1998 17:16:53 -0400 (EDT) Received: from alpha.shiva.com (eagle-ext.shiva.com [192.80.57.28]) by merit.edu (8.8.7/8.8.5) with ESMTP id RAA15379 for ; Wed, 24 Jun 1998 17:16:49 -0400 (EDT) Received: from brill.shiva.com (brill.shiva.com [140.248.193.94]) by alpha.shiva.com (8.8.8/8.8.8) with SMTP id RAA09920; Wed, 24 Jun 1998 17:14:05 -0400 (EDT) Received: by brill.shiva.com (SMI-8.6/SMI-SVR4) id RAA11689; Wed, 24 Jun 1998 17:16:17 -0400 Date: Wed, 24 Jun 1998 17:16:17 -0400 Message-Id: <199806242116.RAA11689@brill.shiva.com> From: John Shriver To: narten@raleigh.ibm.com CC: ietf-ppp@merit.edu In-reply-to: <199806241938.PAA16592@cichlid.raleigh.ibm.com> (message from Thomas Narten on Wed, 24 Jun 1998 15:38:16 -0400) Subject: Re: PPP encryption documents Sender: owner-ietf-ppp@merit.edu Yes, the ECP transforms don't include anti-replay protection, etc. (Vern, I beleive Steve Bellovin has written good stuff on why IPSec's ESP needs packet integrity checks and anti-replay checks. Same would apply to PPP.) But, I think that those needs are best met by IPSec in this day and age. I think that the L2TP people are looking at IPSec in general, since they need to secure what's under PPP, not what's over it. I think the security working group isn't interested in PPP re-inventing IPSec. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jun 25 09:56:54 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id JAA26587; Thu, 25 Jun 1998 09:54:53 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 25 Jun 1998 09:48:40 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id JAA26460 for ietf-ppp-outgoing; Thu, 25 Jun 1998 09:48:40 -0400 (EDT) Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by merit.edu (8.8.7/8.8.5) with ESMTP id JAA26456 for ; Thu, 25 Jun 1998 09:48:36 -0400 (EDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns2.raleigh.ibm.com (AIX4.2/UCB 8.7/8.7RTP-FW1.1) with ESMTP id JAA54296; Thu, 25 Jun 1998 09:48:34 -0400 (EDT) Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.83.123]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id JAA61764; Thu, 25 Jun 1998 09:48:35 -0400 Received: from hygro.raleigh.ibm.com (hygro.raleigh.ibm.com [9.67.118.19]) by cichlid.raleigh.ibm.com (AIX4.3/UCB 8.7/8.7/RTP-ral-1.0) with ESMTP id JAA20420; Thu, 25 Jun 1998 09:48:32 -0400 (EDT) Received: from hygro.raleigh.ibm.com (localhost [127.0.0.1]) by hygro.raleigh.ibm.com (8.7.6/8.7.3) with ESMTP id HAA00636; Thu, 25 Jun 1998 07:02:58 -0400 Message-Id: <199806251102.HAA00636@hygro.raleigh.ibm.com> To: Vernon Schryver cc: ietf-ppp@merit.edu Subject: Re: PPP encryption documents In-reply-to: Your message of "Wed, 24 Jun 1998 14:09:49 MDT." <199806242009.OAA07397@calcite.rhyolite.com> Date: Thu, 25 Jun 1998 07:02:58 -0400 From: Thomas Narten Sender: owner-ietf-ppp@merit.edu > Given the problems the L2TP people have had with security, that sounds a > little messy. At the very least, such considerations should not be allowed > to derail or delay L2TP. I mentioned L2TP only in the sense that a stronger PPP authentication mechanism might be useful to L2TP. Actually, to a client running PPP that suspects that L2TP is being used. Specifically, if you are a client, and you don't know anything about how L2TP is being used by your ISP, the standard thing to do is assume the worst and do you own end-to-end encryption/authentication. Right now, that does not include strong authentication at the PPP level. I would agree that using IPSec as part of the L2TP infrastructure makes sense, but that is not something the end user has control over. (The end user could also of course run IPSec end-to-end across PPP, but that would only help IP traffic.) Also, to clarify, although L2TP is being considered by the IESG at present, it's outcome is not tied to this discussion. > Besides, isn't the L2TP position that anyone who really cares about > security below the application layer will be using IPSEC below the L2TP-PPP > tunnel? The end user doesn't have control over this. Isn't one of the goals of L2TP that it is completely transparent to the client? I.e., the client doesn't even know it's being used. Thomas - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jun 25 10:38:19 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id KAA27357; Thu, 25 Jun 1998 10:36:53 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 25 Jun 1998 10:36:16 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA27320 for ietf-ppp-outgoing; Thu, 25 Jun 1998 10:36:15 -0400 (EDT) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA27316 for ; Thu, 25 Jun 1998 10:36:10 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.8.5/calcite) id IAA12181 mail_from ; Thu, 25 Jun 1998 08:36:07 -0600 (MDT) Date: Thu, 25 Jun 1998 08:36:07 -0600 (MDT) From: Vernon Schryver Message-Id: <199806251436.IAA12181@calcite.rhyolite.com> To: narten@raleigh.ibm.com, vjs@calcite.rhyolite.com Subject: Re: PPP encryption documents Cc: ietf-ppp@merit.edu Sender: owner-ietf-ppp@merit.edu > From: Thomas Narten > > > Given the problems the L2TP people have had with security, that sounds a > > little messy. At the very least, such considerations should not be allowed > > to derail or delay L2TP. > > I mentioned L2TP only in the sense that a stronger PPP authentication > mechanism might be useful to L2TP. Actually, to a client running PPP > that suspects that L2TP is being used. Specifically, if you are a > client, and you don't know anything about how L2TP is being used by > your ISP, the standard thing to do is assume the worst and do you own > end-to-end encryption/authentication. Right now, that does not include > strong authentication at the PPP level. I strongly disagree with that as stated. If you have 0.1% of a clue, and you care about the security (either integrity or confidentiality) of your data, you do run an end-to-end encryption (which includes replay attack defenses), and so do not give a fig what happens at or below any link layer in the path, including links those using PPP. None of PPP in almost any real situation, whether L2TP is involved or not, is remotely end-to-end. Better PPP/L2TP encryuption might protect your data between the first and last boxes at your ISP, but what about sniffers on the Ethernet connecting the last box to the next hop? It is inevitiable that essentially all uses of PPP are <> even remotely end-to-end. The best thing that can be done for security is to accept that fact and not obscure it by talking about security within, below, or beside PPP. The current as well as literally all conceivable kinds of PPP security harm real security by allowing people to fool themselves, or be fooled by salescritters. > I would agree that using IPSec as part of the L2TP infrastructure > makes sense, but that is not something the end user has control > over. If user cannot trust their ISP's to use L2TP with IPSec or take equivalent precautions (e.g. keeping the link between PPP/ISDN boxes in a secure space), then users cannot trust ISP's to do anything with L2TP security. Simply adding protocol mechanisms won't cause ISP's to pick good passwords for whatever mechanism you like, or keep them secret. And again, in most cases, the wires on which L2TP is run are as secure as the boxes L2TP connects. It would be silly to run serious security on the short wires on which L2TP runs, because the bad guy would be using the trace facilities in the terminal boxes because it's easier than using a sniffer. Or at least sniffing on the output of the last box, after MP has re-ordered the fragments and made the target's traffic readable. > (The end user could also of course run IPSec end-to-end across > PPP, but that would only help IP traffic.) If you really care about security, you run IPsec above PPP. If you don't, you're just talking about security or selling snake oil. As for not helping non-IP traffic, what non-IP traffic invovles ISPs who might sneak in an L2TP tunnel? Unless you are talking about traffic that never leaves the terminal PPP peers, PPP is still not end-to-end, and so any security involving PPP and/or L2TP is eyewash that that is a danger to the naive or unwary. Your Appletalk or Netware packets are far more likely to be sniffed on the Ethernet beyond the terminal PPP/L2TP box than in the L2TP link just before the terminal box. I've heard that some people think that L2TP will be used heavily for virtual private nets. I think that's unlikely, but if it does happen, they'll be using IPSec below L2TP. You cannot do real security without involving the ends. The end user always has all control necessary for security. Making L2TP more or less secure would have absolutely no effect on any real security, because end-to-end security involves the ends (including the user) and ignores the middle. If this hypothetical non-IP traffic does not have sufficient security of its own (e.g. application layer), then nothing you can do for, to, with, or by L2TP and/or PPP will help. > Also, to clarify, although L2TP is being considered by the IESG at > present, it's outcome is not tied to this discussion. good. > > Besides, isn't the L2TP position that anyone who really cares about > > security below the application layer will be using IPSEC below the L2TP-PPP > > tunnel? > > The end user doesn't have control over this. Isn't one of the goals of > L2TP that it is completely transparent to the client? I.e., the client > doesn't even know it's being used. Yes. So what? Regardless of whether L2TP is involved, your PPP link is equally and inevitably insecure. So what if your ISP exposes half of the MP fragments of your packets to a private, very secure 10-foot Ethernet connecting two hubs before assemblying them into complete IP packets and putting on much larger Ethernets, FDDI rings, and serial links, in the clear and very more available to bad guys with sniffers and taps? In real life, L2TP does and cannot affect the security of PPP for good or ill. Security requires honest and rational assessements of risks. Making L2TP secure would be about as smart as using multiport bridges (a.k.a. "switches") to Ethernets secure. That zillions of switch salescritters and their marks don't know about routing, ARP, and other hacks to look through that gauze curtain does not justify making PPP have similar snake oil security. Vernon Schryver vjs@rhyolite.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jun 25 10:48:07 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id KAA27565; Thu, 25 Jun 1998 10:46:46 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 25 Jun 1998 10:46:35 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA27540 for ietf-ppp-outgoing; Thu, 25 Jun 1998 10:46:34 -0400 (EDT) Received: from watchdog-rtp.cisco.com (watchdog-rtp.cisco.com [171.68.122.101]) by merit.edu (8.8.7/8.8.5) with SMTP id KAA27531 for ; Thu, 25 Jun 1998 10:46:28 -0400 (EDT) Received: from claret.cisco.com (claret.cisco.com [171.69.160.39]) by watchdog-rtp.cisco.com (8.6.12/CISCO.SERVER.1.1) with SMTP id OAA06543; Thu, 25 Jun 1998 14:45:18 GMT Date: Thu, 25 Jun 1998 10:45:20 -0400 (EDT) From: "W. Mark Townsley" To: Thomas Narten cc: Vernon Schryver , ietf-ppp@merit.edu, l2tp@zendo.com Subject: Re: PPP encryption documents In-Reply-To: <199806251102.HAA00636@hygro.raleigh.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu There are two issues here. Protecting L2TP, and protecting PPP that is being tunneled by L2TP. There are also two deployment models. Thomas is referring to the model where L2TP is transparent to the PPP user. Assuming the peer dialing into the ISP even knows that L2TP is being used to create his/her VPN, it is not up to the PPP peer (from the protocol's perspective) to dictate whether or not IPSec or any other type of protection over the L2TP tunnel is used. In this case, the ISP is initiatiating the tunnel, thus it is the ISP's responsibility to provide whatever level of protection that the client is paying for and that the ISP is willing to live with. If the client is truly concerned about the *privacy* of his or her data, then a form of end to end encryption should always be used (PPP, IP, Application level or otherwise). If the end user is not only running PPP, but initiating L2TP as well (sometimes referred to a PPP/LAC client), then it is up to the client provide whatever L2TP protection is desired. In this case, IPSec can and should be used by the client. PPP encryption alone would of course only serve to protect the PPP data, not the L2TP control messages and encapsulation (not to mention UDP/IP running under L2TP). The bonus here is that since L2TP and PPP are intiated and controlled by the same source, if L2TP is protected, PPP is protected as well, so PPP encryption is not necessary. On Thu, 25 Jun 1998, Thomas Narten wrote: > > Given the problems the L2TP people have had with security, that sounds a > > little messy. At the very least, such considerations should not be allowed > > to derail or delay L2TP. > > I mentioned L2TP only in the sense that a stronger PPP authentication > mechanism might be useful to L2TP. Actually, to a client running PPP > that suspects that L2TP is being used. Specifically, if you are a > client, and you don't know anything about how L2TP is being used by > your ISP, the standard thing to do is assume the worst and do you own > end-to-end encryption/authentication. Right now, that does not include > strong authentication at the PPP level. > > I would agree that using IPSec as part of the L2TP infrastructure > makes sense, but that is not something the end user has control > over. (The end user could also of course run IPSec end-to-end across > PPP, but that would only help IP traffic.) > > Also, to clarify, although L2TP is being considered by the IESG at > present, it's outcome is not tied to this discussion. > > > Besides, isn't the L2TP position that anyone who really cares about > > security below the application layer will be using IPSEC below the L2TP-PPP > > tunnel? > > The end user doesn't have control over this. Isn't one of the goals of > L2TP that it is completely transparent to the client? I.e., the client > doesn't even know it's being used. > > Thomas > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jun 25 11:53:35 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id LAA28982; Thu, 25 Jun 1998 11:52:02 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 25 Jun 1998 11:50:54 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id LAA28942 for ietf-ppp-outgoing; Thu, 25 Jun 1998 11:50:54 -0400 (EDT) Received: from dogwood-fe0.cisco.com (dogwood-fe0.cisco.com [171.68.122.251]) by merit.edu (8.8.7/8.8.5) with ESMTP id LAA28938 for ; Thu, 25 Jun 1998 11:50:49 -0400 (EDT) Received: from chsharp-pc (chsharp-isdn.cisco.com [171.68.116.221]) by dogwood-fe0.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id LAA12880; Thu, 25 Jun 1998 11:49:39 -0400 (EDT) Message-Id: <3.0.3.32.19980625113135.033ae5ac@dogwood.cisco.com> X-Sender: chsharp@dogwood.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 25 Jun 1998 11:31:35 -0400 To: "W. Mark Townsley" From: Chip Sharp Subject: Re: PPP encryption documents Cc: Thomas Narten , Vernon Schryver , ietf-ppp@merit.edu, l2tp@zendo.com In-Reply-To: References: <199806251102.HAA00636@hygro.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Some additional comments: At 10:45 AM 6/25/98 -0400, W. Mark Townsley wrote: > >There are two issues here. Protecting L2TP, and protecting PPP that is >being tunneled by L2TP. There are also two deployment models. > >Thomas is referring to the model where L2TP is transparent to the PPP >user. Assuming the peer dialing into the ISP even knows that L2TP is being >used to create his/her VPN, it is not up to the PPP peer (from the >protocol's perspective) to dictate whether or not IPSec or any other type >of protection over the L2TP tunnel is used. In this case, the ISP is >initiatiating the tunnel, thus it is the ISP's responsibility to provide >whatever level of protection that the client is paying for and that the >ISP is willing to live with. If the client is truly concerned about the >*privacy* of his or her data, then a form of end to end encryption should >always be used (PPP, IP, Application level or otherwise). The client can run IPSEC end to end (assuming the client's IP stack supports it of course). PPP encryption only runs from the client to the LNS. Of course, this could/would end up with the ISP protecting the tunnel with IPSEC and the client protecting their transmission with IPSEC. > >If the end user is not only running PPP, but initiating L2TP as well >(sometimes referred to a PPP/LAC client), then it is up to the client >provide whatever L2TP protection is desired. In this case, IPSec can and >should be used by the client. PPP encryption alone would of course only >serve to protect the PPP data, not the L2TP control messages and >encapsulation (not to mention UDP/IP running under L2TP). The bonus here >is that since L2TP and PPP are intiated and controlled by the same source, >if L2TP is protected, PPP is protected as well, so PPP encryption is not >necessary. There is an interesting component to client tunneling. Running IPSEC on the transport IP stack would protect the L2TP info, but only runs from the client to the LNS. True "end-to-end" encryption would use IPSEC on the upper IP stack. This would protect the data from the client to the destination application, but would not protect the L2TP control messages. Of course, you could run IPSEC on the upper IP layer to protect the end-to-end data and (a different instance) on the transport IP stack to protect the L2TP control messages. aaack! M.C. Escher could probably draw a good diagram of this. ;-\ Chip >On Thu, 25 Jun 1998, Thomas Narten wrote: > >> > Given the problems the L2TP people have had with security, that sounds a >> > little messy. At the very least, such considerations should not be allowed >> > to derail or delay L2TP. >> >> I mentioned L2TP only in the sense that a stronger PPP authentication >> mechanism might be useful to L2TP. Actually, to a client running PPP >> that suspects that L2TP is being used. Specifically, if you are a >> client, and you don't know anything about how L2TP is being used by >> your ISP, the standard thing to do is assume the worst and do you own >> end-to-end encryption/authentication. Right now, that does not include >> strong authentication at the PPP level. >> >> I would agree that using IPSec as part of the L2TP infrastructure >> makes sense, but that is not something the end user has control >> over. (The end user could also of course run IPSec end-to-end across >> PPP, but that would only help IP traffic.) >> >> Also, to clarify, although L2TP is being considered by the IESG at >> present, it's outcome is not tied to this discussion. >> >> > Besides, isn't the L2TP position that anyone who really cares about >> > security below the application layer will be using IPSEC below the L2TP-PPP >> > tunnel? >> >> The end user doesn't have control over this. Isn't one of the goals of >> L2TP that it is completely transparent to the client? I.e., the client >> doesn't even know it's being used. >> >> Thomas >> > > -------------------------------------------------- Chip Sharp voice: +1 (919) 851-2085 Cisco Systems Mgr - Telco Consulting -------------------------------------------------- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jun 25 13:13:45 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id NAA01110; Thu, 25 Jun 1998 13:13:34 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 25 Jun 1998 13:12:29 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id NAA01073 for ietf-ppp-outgoing; Thu, 25 Jun 1998 13:12:28 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by merit.edu (8.8.7/8.8.5) with SMTP id NAA01068 for ; Thu, 25 Jun 1998 13:12:23 -0400 (EDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA14015; Thu, 25 Jun 1998 10:11:04 -0700 Received: from hsmpka.eng.sun.com (phys-hsmpka-055.Eng.Sun.COM [129.146.55.37]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA12650; Thu, 25 Jun 1998 10:11:01 -0700 Received: from hsmpka.eng.sun.com by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA27632; Thu, 25 Jun 1998 10:10:56 -0700 Date: Thu, 25 Jun 1998 10:10:56 -0700 From: Pat.Calhoun@Eng.Sun.COM (Patrice Calhoun) Message-Id: <199806251710.KAA27632@hsmpka.eng.sun.com> To: "Chip Sharp" , "W. Mark Townsley" Cc: "Thomas Narten" , "Vernon Schryver" , ietf-ppp@merit.edu, l2tp@zendo.com Reply-To: Pat.Calhoun@Eng.Sun.COM X-Mailer: Sun NetMail 2.1.6 Subject: Re: PPP encryption documents Sender: owner-ietf-ppp@merit.edu This really comes down to packet effeciency more than anything else. If IPSEC is applied to the outer IP header, then you guarantee that both the L2TP protocol as well as the payload is protected. What we are really talking about here, in case I missed the original e-mail is protecting L2TP. Given that end-to-end encryption is far from ubiquitous, I believe this to be more than sufficient. In a scenario where end-to-end is required, then possibly all that really needed is AH on the outer IP header, and ESP (with possibly AH) on the inner IP header. PPP encryption simply does not work very well. I have had discussions with some people that used CCP, and with the current best effort state of the internet, it causes so much re-syncing on both ends that the effective throughput is not tolerable. So, although I have NO idea what originated this thread, nor what the initial question really was (since I think that it started on the PPP mailing list), I would state that IPSEC on the outer IP header only. Now, in the case of compulsory tunneling its a different beast altogether and it is clear that IPSEC on the inner IP header is necessary, however since end-to-end encryption is not available in most cases, I believe that the LNS will have to act as a "Security Gateway" that requires a security association between the PPP CLient and the LNS (see the IPSEC Architecture document for more info). Hope this helps, PatC >Some additional comments: >At 10:45 AM 6/25/98 -0400, W. Mark Townsley wrote: >> >>There are two issues here. Protecting L2TP, and protecting PPP that is >>being tunneled by L2TP. There are also two deployment models. >> >>Thomas is referring to the model where L2TP is transparent to the PPP >>user. Assuming the peer dialing into the ISP even knows that L2TP is >being >>used to create his/her VPN, it is not up to the PPP peer (from the >>protocol's perspective) to dictate whether or not IPSec or any other type >>of protection over the L2TP tunnel is used. In this case, the ISP is >>initiatiating the tunnel, thus it is the ISP's responsibility to provide >>whatever level of protection that the client is paying for and that the >>ISP is willing to live with. If the client is truly concerned about the >>*privacy* of his or her data, then a form of end to end encryption should >>always be used (PPP, IP, Application level or otherwise). > >The client can run IPSEC end to end (assuming the client's IP stack >supports it of course). PPP encryption only runs from the client to the >LNS. Of course, this could/would end up with the ISP protecting the >tunnel with IPSEC and the client protecting their transmission with IPSEC. >> >>If the end user is not only running PPP, but initiating L2TP as well >>(sometimes referred to a PPP/LAC client), then it is up to the client >>provide whatever L2TP protection is desired. In this case, IPSec can and >>should be used by the client. PPP encryption alone would of course only >>serve to protect the PPP data, not the L2TP control messages and >>encapsulation (not to mention UDP/IP running under L2TP). The bonus here >>is that since L2TP and PPP are intiated and controlled by the same >source, >>if L2TP is protected, PPP is protected as well, so PPP encryption is not >>necessary. > >There is an interesting component to client tunneling. Running IPSEC on >the transport IP stack would protect the L2TP info, but only runs from the >client to the LNS. True "end-to-end" encryption would use IPSEC on the >upper IP stack. This would protect the data from the client to the >destination application, but would not protect the L2TP control messages. >Of course, you could run IPSEC on the upper IP layer to protect the >end-to-end data and (a different instance) on the transport IP stack to >protect the L2TP control messages. aaack! > >M.C. Escher could probably draw a good diagram of this. ;-\ >Chip > >>On Thu, 25 Jun 1998, Thomas Narten wrote: >> >>> > Given the problems the L2TP people have had with security, that >sounds a >>> > little messy. At the very least, such considerations should not be >allowed >>> > to derail or delay L2TP. >>> >>> I mentioned L2TP only in the sense that a stronger PPP authentication >>> mechanism might be useful to L2TP. Actually, to a client running PPP >>> that suspects that L2TP is being used. Specifically, if you are a >>> client, and you don't know anything about how L2TP is being used by >>> your ISP, the standard thing to do is assume the worst and do you own >>> end-to-end encryption/authentication. Right now, that does not include >>> strong authentication at the PPP level. >>> >>> I would agree that using IPSec as part of the L2TP infrastructure >>> makes sense, but that is not something the end user has control >>> over. (The end user could also of course run IPSec end-to-end across >>> PPP, but that would only help IP traffic.) >>> >>> Also, to clarify, although L2TP is being considered by the IESG at >>> present, it's outcome is not tied to this discussion. >>> >>> > Besides, isn't the L2TP position that anyone who really cares about >>> > security below the application layer will be using IPSEC below the >L2TP-PPP >>> > tunnel? >>> >>> The end user doesn't have control over this. Isn't one of the goals of >>> L2TP that it is completely transparent to the client? I.e., the client >>> doesn't even know it's being used. >>> >>> Thomas >>> >> >> >-------------------------------------------------- >Chip Sharp voice: +1 (919) 851-2085 >Cisco Systems Mgr - Telco Consulting >-------------------------------------------------- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jun 25 14:58:40 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id OAA03281; Thu, 25 Jun 1998 14:58:22 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 25 Jun 1998 14:57:25 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA03241 for ietf-ppp-outgoing; Thu, 25 Jun 1998 14:57:25 -0400 (EDT) Received: from flowpoint.com (flowpnt.flowpoint.com [209.31.4.42]) by merit.edu (8.8.7/8.8.5) with ESMTP id OAB03237 for ; Thu, 25 Jun 1998 14:57:20 -0400 (EDT) Received: from localhost (pmr@localhost) by flowpoint.com (8.8.7/8.8.4) with SMTP id LAA08135; Thu, 25 Jun 1998 11:56:32 -0700 Date: Thu, 25 Jun 1998 11:56:32 -0700 (PDT) From: Philip Rakity X-Sender: pmr@flowpnt To: Chip Sharp cc: "W. Mark Townsley" , Thomas Narten , Vernon Schryver , ietf-ppp@merit.edu, l2tp@zendo.com Subject: Re: PPP encryption documents In-Reply-To: <3.0.3.32.19980625113135.033ae5ac@dogwood.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu We run RFC1669 PPP DES Encryption over a L2TP link to provide security between the LAC (eg our L2TP Client) and the LNS. The encrypted tunnel is created between us and the LNS and is not visible to the ISP, and the link is secured between the LAC and the ISP since it is encrypted. The security of the encrypted link depends upon the ablility to break DES and the ability to break the MD5 hash for CHAP (assuming that one is NOT stupid enough to use DES without authentication). We have implementated a DES key exchange mechanism using public keys. All of this was done without IPSec. The major security hole with this scheme is that it assumes that the LNS is in a secure environment as per Chip's observation and that authentication is done by both parties. regards, Philip Rakity FlowPoint Corporation On Thu, 25 Jun 1998, Chip Sharp wrote: > Some additional comments: > At 10:45 AM 6/25/98 -0400, W. Mark Townsley wrote: > > > >There are two issues here. Protecting L2TP, and protecting PPP that is > >being tunneled by L2TP. There are also two deployment models. > > > >Thomas is referring to the model where L2TP is transparent to the PPP > >user. Assuming the peer dialing into the ISP even knows that L2TP is > being > >used to create his/her VPN, it is not up to the PPP peer (from the > >protocol's perspective) to dictate whether or not IPSec or any other type > >of protection over the L2TP tunnel is used. In this case, the ISP is > >initiatiating the tunnel, thus it is the ISP's responsibility to provide > >whatever level of protection that the client is paying for and that the > >ISP is willing to live with. If the client is truly concerned about the > >*privacy* of his or her data, then a form of end to end encryption should > >always be used (PPP, IP, Application level or otherwise). > > The client can run IPSEC end to end (assuming the client's IP stack > supports it of course). PPP encryption only runs from the client to the > LNS. Of course, this could/would end up with the ISP protecting the > tunnel with IPSEC and the client protecting their transmission with IPSEC. > > > >If the end user is not only running PPP, but initiating L2TP as well > >(sometimes referred to a PPP/LAC client), then it is up to the client > >provide whatever L2TP protection is desired. In this case, IPSec can and > >should be used by the client. PPP encryption alone would of course only > >serve to protect the PPP data, not the L2TP control messages and > >encapsulation (not to mention UDP/IP running under L2TP). The bonus here > >is that since L2TP and PPP are intiated and controlled by the same > source, > >if L2TP is protected, PPP is protected as well, so PPP encryption is not > >necessary. > > There is an interesting component to client tunneling. Running IPSEC on > the transport IP stack would protect the L2TP info, but only runs from the > client to the LNS. True "end-to-end" encryption would use IPSEC on the > upper IP stack. This would protect the data from the client to the > destination application, but would not protect the L2TP control messages. > Of course, you could run IPSEC on the upper IP layer to protect the > end-to-end data and (a different instance) on the transport IP stack to > protect the L2TP control messages. aaack! > > M.C. Escher could probably draw a good diagram of this. ;-\ > Chip > > >On Thu, 25 Jun 1998, Thomas Narten wrote: > > > >> > Given the problems the L2TP people have had with security, that > sounds a > >> > little messy. At the very least, such considerations should not be > allowed > >> > to derail or delay L2TP. > >> > >> I mentioned L2TP only in the sense that a stronger PPP authentication > >> mechanism might be useful to L2TP. Actually, to a client running PPP > >> that suspects that L2TP is being used. Specifically, if you are a > >> client, and you don't know anything about how L2TP is being used by > >> your ISP, the standard thing to do is assume the worst and do you own > >> end-to-end encryption/authentication. Right now, that does not include > >> strong authentication at the PPP level. > >> > >> I would agree that using IPSec as part of the L2TP infrastructure > >> makes sense, but that is not something the end user has control > >> over. (The end user could also of course run IPSec end-to-end across > >> PPP, but that would only help IP traffic.) > >> > >> Also, to clarify, although L2TP is being considered by the IESG at > >> present, it's outcome is not tied to this discussion. > >> > >> > Besides, isn't the L2TP position that anyone who really cares about > >> > security below the application layer will be using IPSEC below the > L2TP-PPP > >> > tunnel? > >> > >> The end user doesn't have control over this. Isn't one of the goals of > >> L2TP that it is completely transparent to the client? I.e., the client > >> doesn't even know it's being used. > >> > >> Thomas > >> > > > > > -------------------------------------------------- > Chip Sharp voice: +1 (919) 851-2085 > Cisco Systems Mgr - Telco Consulting > -------------------------------------------------- > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jun 25 15:13:23 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id PAA03651; Thu, 25 Jun 1998 15:13:21 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 25 Jun 1998 15:12:59 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id PAA03623 for ietf-ppp-outgoing; Thu, 25 Jun 1998 15:12:58 -0400 (EDT) Received: from volitans.MorningStar.Com (volitans.MorningStar.Com [137.175.2.11]) by merit.edu (8.8.7/8.8.5) with ESMTP id PAA03611 for ; Thu, 25 Jun 1998 15:12:52 -0400 (EDT) Received: from carp.morningstar.com (root@carp.MorningStar.Com [137.175.81.4]) by volitans.MorningStar.Com (8.8.7/) with ESMTP id PAA00785; Thu, 25 Jun 1998 15:11:55 -0400 (EDT) Received: by carp.morningstar.com (8.8.8/95031605) id PAA16385; Thu, 25 Jun 1998 15:11:54 -0400 (EDT) From: Karl Fox Reply-To: Karl Fox To: Philip Rakity Cc: Chip Sharp , "W. Mark Townsley" , Thomas Narten , Vernon Schryver , ietf-ppp@merit.edu, l2tp@zendo.com Subject: Re: PPP encryption documents References: Date: 25 Jun 1998 15:11:54 -0400 In-Reply-To: Philip Rakity's message of Thu, 25 Jun 1998 11:56:32 -0700 (PDT) Message-ID: Lines: 16 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-ietf-ppp@merit.edu Philip Rakity writes: > We run RFC1669 PPP DES Encryption over a L2TP link to provide security ^^^^1969 > between the LAC (eg our L2TP Client) and the LNS. The encrypted tunnel is > created between us and the LNS and is not visible to the ISP, and the > link is secured between the LAC and the ISP since it is encrypted. > > The security of the encrypted link depends upon the ablility to break DES > and the ability to break the MD5 hash for CHAP Are you sure about this? If someone cracks your DES key but not the CHAP MD5 key, can't they inject encrypted packets into your L2TP stream? -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jun 25 15:16:34 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id PAA03728; Thu, 25 Jun 1998 15:16:33 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 25 Jun 1998 15:16:23 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id PAA03698 for ietf-ppp-outgoing; Thu, 25 Jun 1998 15:16:22 -0400 (EDT) Received: from flowpoint.com (flowpnt.flowpoint.com [209.31.4.42]) by merit.edu (8.8.7/8.8.5) with ESMTP id PAA03690 for ; Thu, 25 Jun 1998 15:16:17 -0400 (EDT) Received: from localhost (pmr@localhost) by flowpoint.com (8.8.7/8.8.4) with SMTP id MAA10367; Thu, 25 Jun 1998 12:14:56 -0700 Date: Thu, 25 Jun 1998 12:14:55 -0700 (PDT) From: Philip Rakity X-Sender: pmr@flowpnt To: Karl Fox cc: Chip Sharp , "W. Mark Townsley" , Thomas Narten , Vernon Schryver , ietf-ppp@merit.edu, l2tp@zendo.com Subject: Re: PPP encryption documents In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu If they break my des key then no authenication helps. Philip On 25 Jun 1998, Karl Fox wrote: > Philip Rakity writes: > > We run RFC1669 PPP DES Encryption over a L2TP link to provide security > ^^^^1969 > > between the LAC (eg our L2TP Client) and the LNS. The encrypted tunnel is > > created between us and the LNS and is not visible to the ISP, and the > > link is secured between the LAC and the ISP since it is encrypted. > > > > The security of the encrypted link depends upon the ablility to break DES > > and the ability to break the MD5 hash for CHAP > > Are you sure about this? If someone cracks your DES key but not the > CHAP MD5 key, can't they inject encrypted packets into your L2TP > stream? > -- > Karl Fox, servant of God, employee of Ascend Communications > 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jun 25 15:28:00 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id PAA04117; Thu, 25 Jun 1998 15:27:54 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 25 Jun 1998 15:27:38 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id PAA04091 for ietf-ppp-outgoing; Thu, 25 Jun 1998 15:27:37 -0400 (EDT) Received: from Fe3.rust.net (fe3.gle.verio.net [209.69.6.110]) by merit.edu (8.8.7/8.8.5) with ESMTP id PAA04087 for ; Thu, 25 Jun 1998 15:27:33 -0400 (EDT) From: bwhelan@nei.com Received: from snmpmgr.nei.com (snmpmgr.nei.com [209.69.28.91]) by Fe3.rust.net (8.8.5/8.8.5) with SMTP id PAA17132; Thu, 25 Jun 1998 15:26:45 -0400 (EDT) Received: from ccMail by snmpmgr.nei.com (ccMail Link to SMTP R8.00.00) id AA898802992; Thu, 25 Jun 98 15:30:00 -0500 Message-Id: <9806258988.AA898802992@snmpmgr.nei.com> X-Mailer: ccMail Link to SMTP R8.00.00 Date: Thu, 25 Jun 98 15:23:40 -0500 To: , Cc: , , , , , Subject: Re[2]: PPP encryption documents MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Philip, Even if they don't crack your DES key, can't they inject packets in a denial of service attack? If you fail to decrypt the injected packet, you discard that one as well as the next good one. Meanwhile, you're expending MIPs decrypting. If memory serves me (always questionable), one of the reasons for adding authentication to ESP was for such attacks. ESP Authentication is much faster than decryption. Bill ______________________________ Reply Separator _________________________________ Subject: Re: PPP encryption documents Author: Karl Fox at internet-mail Date: 6/25/98 3:11 PM Philip Rakity writes: > We run RFC1669 PPP DES Encryption over a L2TP link to provide security ^^^^1969 > between the LAC (eg our L2TP Client) and the LNS. The encrypted tunnel is > created between us and the LNS and is not visible to the ISP, and the > link is secured between the LAC and the ISP since it is encrypted. > > The security of the encrypted link depends upon the ablility to break DES > and the ability to break the MD5 hash for CHAP Are you sure about this? If someone cracks your DES key but not the CHAP MD5 key, can't they inject encrypted packets into your L2TP stream? -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jun 25 16:06:13 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id QAA04967; Thu, 25 Jun 1998 16:06:02 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 25 Jun 1998 16:04:08 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id QAA04911 for ietf-ppp-outgoing; Thu, 25 Jun 1998 16:04:07 -0400 (EDT) Received: from flowpoint.com (flowpnt.flowpoint.com [209.31.4.42]) by merit.edu (8.8.7/8.8.5) with ESMTP id QAA04903 for ; Thu, 25 Jun 1998 16:04:02 -0400 (EDT) Received: from localhost (pmr@localhost) by flowpoint.com (8.8.7/8.8.4) with SMTP id NAA17206; Thu, 25 Jun 1998 13:02:42 -0700 Date: Thu, 25 Jun 1998 13:02:41 -0700 (PDT) From: Philip Rakity X-Sender: pmr@flowpnt To: bwhelan@nei.com cc: karl@ascend.com, chsharp@cisco.com, townsley@cisco.com, narten@raleigh.ibm.com, vjs@calcite.rhyolite.com, ietf-ppp@merit.edu, l2tp@zendo.com Subject: Re: Re[2]: PPP encryption documents In-Reply-To: <9806258988.AA898802992@snmpmgr.nei.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Bill, You are correct. If one argues that a packet can be injected (correct sequence number, etc) then a denial of service attack is possible. One can also do the samething against IPSec by flooding IP packets. Philip On Thu, 25 Jun 1998 bwhelan@nei.com wrote: > > Philip, > > Even if they don't crack your DES key, can't they inject packets in a > denial of service attack? If you fail to decrypt the injected packet, > you discard that one as well as the next good one. Meanwhile, you're > expending MIPs decrypting. If memory serves me (always questionable), > one of the reasons for adding authentication to ESP was for such > attacks. ESP Authentication is much faster than decryption. > > Bill > > > ______________________________ Reply Separator _________________________________ > Subject: Re: PPP encryption documents > Author: Karl Fox at internet-mail > Date: 6/25/98 3:11 PM > > > Philip Rakity writes: > > We run RFC1669 PPP DES Encryption over a L2TP link to provide security > ^^^^1969 > > between the LAC (eg our L2TP Client) and the LNS. The encrypted tunnel is > > created between us and the LNS and is not visible to the ISP, and the > > link is secured between the LAC and the ISP since it is encrypted. > > > > The security of the encrypted link depends upon the ablility to break DES > > and the ability to break the MD5 hash for CHAP > > Are you sure about this? If someone cracks your DES key but not the > CHAP MD5 key, can't they inject encrypted packets into your L2TP > stream? > -- > Karl Fox, servant of God, employee of Ascend Communications > 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 > > > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jun 25 17:12:41 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id RAA07059; Thu, 25 Jun 1998 17:12:32 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 25 Jun 1998 17:11:24 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id RAA07014 for ietf-ppp-outgoing; Thu, 25 Jun 1998 17:11:24 -0400 (EDT) Received: from smtp-gw.BayNetworks.COM (ns1.BayNetworks.COM [134.177.3.20]) by merit.edu (8.8.7/8.8.5) with ESMTP id RAA07005 for ; Thu, 25 Jun 1998 17:11:18 -0400 (EDT) Received: from mailhost.BayNetworks.COM (h016b.s86b1.BayNetworks.COM [134.177.1.107] (may be forged)) by smtp-gw.BayNetworks.COM (8.8.8/8.8.8) with ESMTP id OAA15859; Thu, 25 Jun 1998 14:10:48 -0700 (PDT) Received: from lobster1.corpeast.Baynetworks.com (ns2.corpeast.baynetworks.com [192.32.72.17]) by mailhost.BayNetworks.COM (8.8.8/8.8.8) with SMTP id OAA27028; Thu, 25 Jun 1998 14:10:48 -0700 (PDT) Received: from bl-mail1.corpeast.BayNetworks.com (bl-mail1-nf0) by lobster1.corpeast.Baynetworks.com (4.1/BNET-97/04/29-S) id AA23831; Thu, 25 Jun 98 17:10:45 EDT for l2tp@zendo.com Received: from rshea ([132.245.250.122]) by bl-mail1.corpeast.BayNetworks.com (post.office MTA v2.0 0529 ID# 0-13458) with SMTP id AAA18010; Thu, 25 Jun 1998 17:10:38 -0400 Message-Id: <3.0.32.19980625171053.00c6c310@bl-mail1.corpeast.baynetworks.com> X-Sender: rshea@bl-mail1.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 25 Jun 1998 17:10:56 -0400 To: ietf-ppp@merit.edu, l2tp@zendo.com From: Rich_Shea@BayNetworks.COM (Rich Shea) Subject: Re: Re[2]: PPP encryption documents Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu At 01:02 PM 6/25/98 -0700, Philip Rakity wrote: > >Bill, > >You are correct. If one argues that a packet can be injected (correct >sequence number, etc) then a denial of service attack is possible. One >can also do the samething against IPSec by flooding IP packets. > Not as effectively, since with IPSEC you authenticate the packets first which is less intensive than decryption so the denial of service attack is not as effective. Also there is no chaining between IPSEC packets so there is no concept of having to drop a packet because the one before it was lost (or invalid). >Philip > > >On Thu, 25 Jun 1998 bwhelan@nei.com wrote: > >> >> Philip, >> >> Even if they don't crack your DES key, can't they inject packets in a >> denial of service attack? If you fail to decrypt the injected packet, >> you discard that one as well as the next good one. Meanwhile, you're >> expending MIPs decrypting. If memory serves me (always questionable), >> one of the reasons for adding authentication to ESP was for such >> attacks. ESP Authentication is much faster than decryption. >> >> Bill >> >> >> ______________________________ Reply Separator _________________________________ >> Subject: Re: PPP encryption documents >> Author: Karl Fox at internet-mail >> Date: 6/25/98 3:11 PM >> >> >> Philip Rakity writes: >> > We run RFC1669 PPP DES Encryption over a L2TP link to provide security >> ^^^^1969 >> > between the LAC (eg our L2TP Client) and the LNS. The encrypted tunnel is >> > created between us and the LNS and is not visible to the ISP, and the >> > link is secured between the LAC and the ISP since it is encrypted. >> > >> > The security of the encrypted link depends upon the ablility to break DES >> > and the ability to break the MD5 hash for CHAP >> >> Are you sure about this? If someone cracks your DES key but not the >> CHAP MD5 key, can't they inject encrypted packets into your L2TP >> stream? >> -- >> Karl Fox, servant of God, employee of Ascend Communications >> 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 >> >> >> > > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Richard Shea, Principal Engineer rshea@BayNetworks.com Bay Networks / Extranet Access 978-635-2019 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Jun 26 10:37:54 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id KAA19949; Fri, 26 Jun 1998 10:31:57 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 26 Jun 1998 10:27:00 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA19792 for ietf-ppp-outgoing; Fri, 26 Jun 1998 10:27:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA19788 for ; Fri, 26 Jun 1998 10:26:55 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA26644; Fri, 26 Jun 1998 10:25:50 -0400 (EDT) Message-Id: <199806261425.KAA26644@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: ietf-ppp@merit.edu From: The IESG Subject: Protocol Action: PPP Over FUNI to Proposed Standard Date: Fri, 26 Jun 1998 10:25:50 -0400 Sender: owner-ietf-ppp@merit.edu The IESG has approved the Internet-Draft 'PPP Over FUNI' as a Proposed Standard. This document is the product of the Point-to-Point Protocol Extensions Working Group. The IESG contact persons are Jeffrey Burgan and Thomas Narten. Technical Summary The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document describes the use of ATM Frame User Network Interface (FUNI) for framing PPP encapsulated packets. The ATM FUNI protocol is designed to provide virtual connections between end stations attached to the same network. These connections offer a packet delivery service that includes error detection, but does not do error correction. This specification is intended for those implementations which desire to use the facilities which are defined for PPP, such as the Link Control Protocol, Network-layer Control Protocols, authentication, and compression. These capabilities require a point-to-point relationship between the peers, and are not designed for the multi-point relationships which are available in ATM and other multi-access environments. Working Group Summary The Working Group last call produced no issues with this document. Protocol Quality This document has been reviewed by Jeffrey Burgan and Thomas Narten of the IESG. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Jun 26 10:37:55 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id KAA19946; Fri, 26 Jun 1998 10:31:57 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 26 Jun 1998 10:25:03 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA19740 for ietf-ppp-outgoing; Fri, 26 Jun 1998 10:25:03 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA19736 for ; Fri, 26 Jun 1998 10:24:59 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA26544; Fri, 26 Jun 1998 10:23:52 -0400 (EDT) Message-Id: <199806261423.KAA26544@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: ietf-ppp@merit.edu From: The IESG Subject: Protocol Action: PPP over AAL5 to Proposed Standard Date: Fri, 26 Jun 1998 10:23:52 -0400 Sender: owner-ietf-ppp@merit.edu The IESG has approved the Internet-Draft 'PPP over AAL5' as a Proposed Standard. This document is the product of the Point-to-Point Protocol Extensions Working Group. The IESG contact persons are Jeffrey Burgan and Thomas Narten. Technical Summary The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document describes the use of ATM Adaptation Layer 5 (AAL5) for framing PPP encapsulated packets. The ATM AAL5 protocol is designed to provide virtual connections between end stations attached to the same network. These connections offer a packet delivery service that includes error detection, but does not do error correction. This specification is intended for those implementations which desire to use the facilities which are defined for PPP, such as the Link Control Protocol, Network-layer Control Protocols, authentication, and compression. These capabilities require a point-to-point relationship between the peers, and are not designed for the multi-point relationships which are available in ATM and other multi-access environments. Working Group Summary The Working Group last call produced no issues with this document. Protocol Quality This document has been reviewed by Jeffrey Burgan and Thomas Narten of the IESG. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Jun 29 10:17:33 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id KAA19060; Mon, 29 Jun 1998 10:15:15 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 29 Jun 1998 10:10:06 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA18962 for ietf-ppp-outgoing; Mon, 29 Jun 1998 10:10:05 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA18958 for ; Mon, 29 Jun 1998 10:09:58 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA12371; Mon, 29 Jun 1998 10:09:25 -0400 (EDT) Message-Id: <199806291409.KAA12371@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu, l2tp@zendo.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-l2tpdwin-00.txt Date: Mon, 29 Jun 1998 10:09:25 -0400 Sender: owner-ietf-ppp@merit.edu --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : L2TP Dynamic Data Window Adjustment Author(s) : R. Shea Filename : draft-ietf-pppext-l2tpdwin-00.txt Pages : 5 Date : 26-Jun-98 The Layer Two Tunneling Protocol (L2TP) defines the specification of congestion window sizes for data sessions. In addition, an LNS is given the capability to turn off sequence number processing for a data session, provided the LAC did not include the Sequencing Required AVP during session setup. This document specifies a mechanism whereby an L2TP peer can dynamically change the window size values being used for a data session, in order to provide the flexibility to operate with smaller window sizes when history-bound protocols are operating over a session, and larger window sizes when no history-bound protocols are operating over a session. 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-l2tpdwin-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pppext-l2tpdwin-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pppext-l2tpdwin-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980626133211.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-l2tpdwin-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-l2tpdwin-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980626133211.I-D@ietf.org> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Jun 29 16:13:57 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id QAA01199; Mon, 29 Jun 1998 16:12:27 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 29 Jun 1998 16:11:41 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id QAA01152 for ietf-ppp-outgoing; Mon, 29 Jun 1998 16:11:40 -0400 (EDT) Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by merit.edu (8.8.7/8.8.5) with ESMTP id QAA01148 for ; Mon, 29 Jun 1998 16:11:36 -0400 (EDT) Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by thumper.bellcore.com (8.8.8/8.8.8) with ESMTP id QAA02662 for ; Mon, 29 Jun 1998 16:11:05 -0400 (EDT) Received: (from huitema@localhost) by seawind.bellcore.com (8.8.8/8.8.8) id QAA24132 for ietf-ppp@merit.edu; Mon, 29 Jun 1998 16:11:04 -0400 (EDT) Date: Mon, 29 Jun 1998 16:11:04 -0400 (EDT) From: Christian Huitema Message-Id: <980629161104.ZM24130@seawind.bellcore.com> X-Mailer: Z-Mail (5.0.0 30July97) To: ietf-ppp@merit.edu Subject: Question on outgoing calls in L2TP MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-ppp@merit.edu Looking at the L2TP draft (draft-ietf-pppext-l2tp-11.txt) I could not find the answer to what I would call the "dial-out redirection" problem. Suppose that a tunnel has been established an LNS and a LAC, and that the LNS requires to set up an outgoing call towards some telephone number. Suppose now that the LAC is unwilling or unable to set-up that call, but that it could "redirect" that call towards another NAS, that would either have more available ports or be nearer, from a phone tariff point of view, from the dialed number. I did not find a way to encode this redirection. Should it be added to the spec, or did I simply not look close enough? -- Christian Huitema ---------- See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/ - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Jun 29 17:36:11 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id RAA02848; Mon, 29 Jun 1998 17:34:38 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 29 Jun 1998 17:33:37 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id RAA02816 for ietf-ppp-outgoing; Mon, 29 Jun 1998 17:33:36 -0400 (EDT) Received: from watchdog-rtp.cisco.com (watchdog-rtp.cisco.com [171.68.122.101]) by merit.edu (8.8.7/8.8.5) with SMTP id RAA02812 for ; Mon, 29 Jun 1998 17:33:32 -0400 (EDT) Received: from claret.cisco.com (claret.cisco.com [171.69.160.39]) by watchdog-rtp.cisco.com (8.6.12/CISCO.SERVER.1.1) with SMTP id VAA11556; Mon, 29 Jun 1998 21:32:26 GMT Date: Mon, 29 Jun 1998 17:32:29 -0400 (EDT) From: "W. Mark Townsley" To: Christian Huitema cc: ietf-ppp@merit.edu Subject: Re: Question on outgoing calls in L2TP In-Reply-To: <980629161104.ZM24130@seawind.bellcore.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu On Mon, 29 Jun 1998, Christian Huitema wrote: > Looking at the L2TP draft (draft-ietf-pppext-l2tp-11.txt) I could > not find the answer to what I would call the "dial-out redirection" > problem. > > Suppose that a tunnel has been established an LNS and a LAC, and that > the LNS requires to set up an outgoing call towards some telephone > number. Suppose now that the LAC is unwilling or unable to set-up > that call, but that it could "redirect" that call towards another > NAS, that would either have more available ports or be nearer, from > a phone tariff point of view, from the dialed number. I did not > find a way to encode this redirection. Should it be added to the > spec, or did I simply not look close enough? There is a Result Code and optional Error Code included in the CDN that is sent from the LAC when an unacceptable Outgoing Call-Request is received. As a basic indication of lack of resources, one of the following Result Codes could be utilized within the CDN, depending on which is more appropriate: 4 - Call failed due to no appropriate facilities being available (temporary condition) 5 - Call failed due to no appropriate facilities being available (permanent condition) Alternatively, there is a set of General Error Codes that are shared between the CDN and StopCCN messages which also could convey a similar messsage: 4 - Insufficient resources to handle this operation now 7 - Try another. If LAC is aware of other possible LNS destinations, it should try one of them. This can be used to guide an LAC based on LNS policy, for instance, the existence of multilink PPP bundles. There are no mechanisms to "suggest" another LAC to the initiating LNS beyond these. Thus, currently it is fully up to the LNS to be aware of alternatives if they exist. > > -- > Christian Huitema > ---------- > See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/ > - - - - - - - - - - - - - - - - -