From owner-ietf-ppp-outgoing@merit.edu Thu Sep 2 10:37:23 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B824D44462; Thu, 2 Sep 1999 10:37:22 -0400 (EDT) Received: from intra0.extant.net (intra0.lvp.extant.net [216.28.121.11]) by segue.merit.edu (Postfix) with ESMTP id 3689044461 for ; Thu, 2 Sep 1999 10:37:21 -0400 (EDT) Received: from karl ([209.116.97.128]) by intra0.extant.net (Netscape Messaging Server 3.6) with ESMTP id AAA248F; Thu, 2 Sep 1999 10:37:15 -0400 Message-Id: <4.2.0.58.19990902103527.042e3100@mail.extant.net> X-Sender: kfox@mail.extant.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 02 Sep 1999 10:37:14 -0400 To: Thomas Narten , Erik Nordmark From: "Karl Fox" Subject: L2TP MIB to Proposed Standard Cc: ietf-ppp@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Thomas and Erik, The PPPEXT Working Group recommends that Layer Two Tunneling Protocol 'L2TP' Management Information Base (draft-ietf-pppext-l2tp-mib-05.txt) be advanced to Proposed Standard. Karl Fox Key fingerprint = 5B15 7260 D55E D680 0B93 4953 8A3B AB0E C05D 77A3 From owner-ietf-ppp-outgoing@merit.edu Thu Sep 2 10:41:35 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 049364445E; Thu, 2 Sep 1999 10:41:34 -0400 (EDT) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by segue.merit.edu (Postfix) with ESMTP id 01C9444462 for ; Thu, 2 Sep 1999 10:41:33 -0400 (EDT) Received: from zrtpd004.us.nortel.com (actually nrtpd004) by smtprch1.nortel.com; Thu, 2 Sep 1999 09:33:18 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Thu, 2 Sep 1999 10:41:08 -0400 Message-ID: From: "John Tintor" To: ietf-ppp@merit.edu Subject: remove Date: Thu, 2 Sep 1999 10:41:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu remove From owner-ietf-ppp-outgoing@merit.edu Thu Sep 2 10:42:03 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 518AA4446E; Thu, 2 Sep 1999 10:42:03 -0400 (EDT) Received: from smtprtp1.ntcom.nortel.net (smtprtp1.ntcom.nortel.net [137.118.22.14]) by segue.merit.edu (Postfix) with ESMTP id 6B94544468 for ; Thu, 2 Sep 1999 10:41:57 -0400 (EDT) Received: from zrtpd004.us.nortel.com (actually nrtpd004) by smtprtp1.ntcom.nortel.net; Thu, 2 Sep 1999 10:41:45 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Thu, 2 Sep 1999 10:41:44 -0400 Message-ID: From: "John Tintor" To: ietf-ppp@merit.edu Subject: delete Date: Thu, 2 Sep 1999 10:41:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu delete From owner-ietf-ppp-outgoing@merit.edu Tue Sep 7 03:26:22 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DA7E244428; Tue, 7 Sep 1999 03:26:21 -0400 (EDT) Received: from cc.sookmyung.ac.kr (cc.sookmyung.ac.kr [203.252.201.4]) by segue.merit.edu (Postfix) with ESMTP id 2B1DF44428 for ; Tue, 7 Sep 1999 03:26:19 -0400 (EDT) Received: from cs.sookmyung.ac.kr (cs.sookmyung.ac.kr [203.252.206.1]) by cc.sookmyung.ac.kr (8.8.8+Sun/8.8.8) with SMTP id QAA28541 for ; Tue, 7 Sep 1999 16:26:39 +0900 (KST) Received: from cs.sookmyung.ac.kr by cs.sookmyung.ac.kr (SMI-8.6/SMI-SVR4) id QAA26093; Tue, 7 Sep 1999 16:22:53 +0900 Date: Tue, 7 Sep 1999 16:22:52 +0900 (KST) From: "mira : using \" Jung Mi Ra\"" To: ietf-ppp@merit.edu Subject: question of L2TP product Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Hello~ I'm a student studying L2TP. As I knew, there are lots of L2TP product. Where could I get the features of L2TP product? Thanks in advance.. From owner-ietf-ppp-outgoing@merit.edu Tue Sep 7 07:12:56 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DD737445D2; Tue, 7 Sep 1999 07:12:55 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 56A9244404 for ; Tue, 7 Sep 1999 07:12:54 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01252; Tue, 7 Sep 1999 07:12:48 -0400 (EDT) Message-Id: <199909071112.HAA01252@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-sdl-04.txt Date: Tue, 07 Sep 1999 07:12:47 -0400 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : PPP over Simple Data Link (SDL) using SONET/SDH with ATM-like framing Author(s) : J. Carlson, P. Langner, E.J. Hernandez Valencia, J. Manchester Filename : draft-ietf-pppext-sdl-04.txt Pages : 29 Date : 03-Sep-99 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links, and RFCs 1662 [2] and 1619 [3] provide a means to carry PPP over Synchronous Optical Network (SONET) [4] and Synchronous Digital Hierarchy (SDH) [5] circuits. This document extends these standards to include a new encapsulation for PPP called Simple Data Link (SDL) [6]. SDL provides a very low overhead alternative to standard HDLC encapsulation, and can also be used on SONET/SDH links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-sdl-04.txt Internet-Drafts are also 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-sdl-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pppext-sdl-04.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: <19990903095122.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-sdl-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-sdl-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990903095122.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ppp-outgoing@merit.edu Tue Sep 7 12:18:44 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8191F4440E; Tue, 7 Sep 1999 12:18:44 -0400 (EDT) Received: from p-voyageur.issy.cnet.fr (p-voyageur.issy.cnet.fr [139.100.0.39]) by segue.merit.edu (Postfix) with SMTP id 0B2B14440C for ; Tue, 7 Sep 1999 12:18:38 -0400 (EDT) Received: by p-voyageur.issy.cnet.fr with Internet Mail Service (5.5.2448.0) id ; Tue, 7 Sep 1999 18:19:40 +0200 Message-ID: From: RABARISON Dina CNET/DTD/LAN To: ietf-ppp@merit.edu Subject: about L2TP stack of protocols Date: Tue, 7 Sep 1999 18:18:50 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Hi, My question concerns the RFC 2661 (L2TP), more especially, figure 3.0, L2TP Protocol Structure. What does this figure exactly represent ? Is it the stack of protocols of L2TP ? So, how to understand that UDP packet transport is in the same level as ATM, ... Is it that we've got in one case .../PPP/L2TP/(ATM or FR) and in other case .../PPP/L2TP/UDP/IP/... ? Thanks in advance, Best Regards Dina From owner-ietf-ppp-outgoing@merit.edu Tue Sep 7 12:26:55 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 10E934440F; Tue, 7 Sep 1999 12:26:55 -0400 (EDT) Received: from zwei.siemens.at (zwei.siemens.at [193.81.246.12]) by segue.merit.edu (Postfix) with ESMTP id 679F344434 for ; Tue, 7 Sep 1999 12:26:40 -0400 (EDT) Received: from vies194a.sie.siemens.at (root@firix-hme0 [10.1.140.1]) by zwei.siemens.at with ESMTP id SAA24184; Tue, 7 Sep 1999 18:27:50 +0200 (MET DST) Received: by vies194a.sie.siemens.at with Internet Mail Service (5.5.2448.0) id ; Tue, 7 Sep 1999 18:26:33 +0200 Message-ID: From: Klausberger Walter To: "'RABARISON Dina CNET/DTD/LAN'" Cc: ietf-ppp@merit.edu, "'l2tp@ipsec.org'" Subject: AW: about L2TP stack of protocols Date: Tue, 7 Sep 1999 18:26:27 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Hi Dina, L2TP can be used over UDP/IP or FR or ATM. I think that's what figure = 3.0 refers to. UDP/IP itself can again be transported over ATM or FR or = .... This figure only shows that Control Messages are handled different to = Data Messages inside the L2TP stack. Hope that covers your question. with best regards Walter > -----Urspr=FCngliche Nachricht----- > Von: RABARISON Dina CNET/DTD/LAN > [mailto:dina.rabarison@cnet.francetelecom.fr] > Gesendet am: Dienstag, 07. September 1999 18:19 > An: ietf-ppp@merit.edu > Betreff: about L2TP stack of protocols >=20 > Hi,=20 >=20 > My question concerns the RFC 2661 (L2TP), more especially,=20 > figure 3.0, L2TP > Protocol Structure.=20 >=20 > What does this figure exactly represent ? Is it the stack of=20 > protocols of > L2TP ? > So, how to understand that UDP packet transport is in the=20 > same level as ATM, > ...=20 >=20 > Is it that we've got in one case .../PPP/L2TP/(ATM or FR)=20 > and in other case > .../PPP/L2TP/UDP/IP/... ? >=20 > Thanks in advance,=20 > Best Regards >=20 > Dina =09 > =20 >=20 >=20 From owner-ietf-ppp-outgoing@merit.edu Tue Sep 7 12:37:17 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A70D24440F; Tue, 7 Sep 1999 12:37:16 -0400 (EDT) Received: from p-biset.issy.cnet.fr (p-biset.issy.cnet.fr [139.100.0.33]) by segue.merit.edu (Postfix) with SMTP id 913A44440E for ; Tue, 7 Sep 1999 12:37:14 -0400 (EDT) Received: by p-biset.issy.cnet.fr with Internet Mail Service (5.5.2448.0) id ; Tue, 7 Sep 1999 18:38:16 +0200 Message-ID: From: RABARISON Dina CNET/DTD/LAN To: 'Klausberger Walter' , ietf-ppp@merit.edu, "'l2tp@ipsec.org'" Subject: RE: about L2TP stack of protocols Date: Tue, 7 Sep 1999 18:37:27 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Thanks for your answer (Walter and Ignacio), I agree with the fact that UDP/IP itself can be transported over ATM or FR, or ...=20 So, I was expected in having UDP/IP/PPP/L2TP/(ATM or FR) in the case of UDP/IP. With the configuration PPP/L2TP/UDP/IP/... in what case ? which = interest ? advantages ? Isn't it a risk of overhead ?=20 thanks for your advice, Dina > ---------- > De : Klausberger Walter[SMTP:walter.klausberger@siemens.at] > Date : mardi 7 septembre 1999 18:26 > A : 'RABARISON Dina CNET/DTD/LAN' > Cc : ietf-ppp@merit.edu; 'l2tp@ipsec.org' > Objet : AW: about L2TP stack of protocols >=20 > Hi Dina, >=20 > L2TP can be used over UDP/IP or FR or ATM. I think that's what figure = 3.0 > refers to. UDP/IP itself can again be transported over ATM or FR or = .... > This figure only shows that Control Messages are handled different to = Data > Messages inside the L2TP stack. >=20 > Hope that covers your question. >=20 > with best regards > Walter >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: RABARISON Dina CNET/DTD/LAN > > [mailto:dina.rabarison@cnet.francetelecom.fr] > > Gesendet am: Dienstag, 07. September 1999 18:19 > > An: ietf-ppp@merit.edu > > Betreff: about L2TP stack of protocols > >=20 > > Hi,=20 > >=20 > > My question concerns the RFC 2661 (L2TP), more especially,=20 > > figure 3.0, L2TP > > Protocol Structure.=20 > >=20 > > What does this figure exactly represent ? Is it the stack of=20 > > protocols of > > L2TP ? > > So, how to understand that UDP packet transport is in the=20 > > same level as ATM, > > ...=20 > >=20 > > Is it that we've got in one case .../PPP/L2TP/(ATM or FR)=20 > > and in other case > > .../PPP/L2TP/UDP/IP/... ? > >=20 > > Thanks in advance,=20 > > Best Regards > >=20 > > Dina =09 > > =20 > >=20 > >=20 >=20 From owner-ietf-ppp-outgoing@merit.edu Tue Sep 7 14:42:20 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A841044447; Tue, 7 Sep 1999 14:42:19 -0400 (EDT) Received: from ironbridgenetworks.com (helios.ironbridgenetworks.com [146.115.140.2]) by segue.merit.edu (Postfix) with ESMTP id 08F8944445 for ; Tue, 7 Sep 1999 14:42:18 -0400 (EDT) Received: (from news@localhost) by ironbridgenetworks.com (8.9.3/8.9.3) id OAA23395 for ietf-ppp@merit.edu; Tue, 7 Sep 1999 14:42:17 -0400 (EDT) To: ietf-ppp@merit.edu From: James Carlson Newsgroups: lists.ietf.ppp Subject: Re: about L2TP stack of protocols Date: 07 Sep 1999 14:42:17 -0400 Organization: IronBridge Networks Lines: 29 Message-ID: <86emga7ed2.fsf@ironbridgenetworks.com> References: NNTP-Posting-Host: helios.ibnets.com X-Newsreader: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu dina.rabarison@cnet.francetelecom.fr (RABARISON Dina CNET/DTD/LAN) writes: > Thanks for your answer (Walter and Ignacio), I agree with the fact that > UDP/IP itself can be transported over ATM or FR, or ... > > So, I was expected in having UDP/IP/PPP/L2TP/(ATM or FR) in the case of > UDP/IP. Yes, that's what it looks like if the *application* is doing UDP over IP over PPP over L2TP running on ATM or Frame Relay. The L2TP document doesn't describe all the ways you can run applications over protocols that run over PPP. It just describes how to run PPP over some other network. > With the configuration PPP/L2TP/UDP/IP/... in what case ? which interest ? It allows you to run L2TP over the general Internet or any other IP network so that you can tunnel PPP across it. > advantages ? Isn't it a risk of overhead ? Yes, 28 bytes of overhead plus whatever your chosen link-layer below IP adds. -- James Carlson, System Architect IronBridge Networks / 55 Hayden Avenue 71.246W Vox: +1 781 372 8132 Lexington MA 02421-7996 / USA 42.423N Fax: +1 781 372 8090 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Tue Sep 7 17:26:49 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 859CC44449; Tue, 7 Sep 1999 17:26:49 -0400 (EDT) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by segue.merit.edu (Postfix) with ESMTP id B93F64443D for ; Tue, 7 Sep 1999 17:26:47 -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 (6.6.6/6.6.6) with ESMTP id OAA28080 for ; Tue, 7 Sep 1999 14:26:42 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2448.0) id ; Tue, 7 Sep 1999 14:26:43 -0700 Message-ID: From: Shahram Davari To: ietf-ppp@merit.edu Subject: RE: I-D ACTION:draft-ietf-pppext-sdl-04.txt Date: Tue, 7 Sep 1999 14:26:42 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Hi, I have found the following errors/shortcomings in this draft: 1) Section 4.4 False Sync can occur when a False Framing has occurred even if the scrambler state message is correct. That is due to the fact that the header is not scrambled, and therefore the two consecutive false CRC-16 match headers are removed and are not descrambled, causing the other data bits to be in wrong descrambling/sync position. PFS = PFF = 2^-16 = 1.5 E-5 rather than the very low value of 54.21 E-21 in the document. 2) Section 4.4 In first paragraph it is written 232.8E-21 = 2^-32 which is wrong and should be 232.8 E-12 = 2.328 E-10 3) In almost all probabilities the scientific notation should include only one decimal point before the fraction point like 3.679 E-1 rather than 367.9 E-3. Because this is the proper use of scientific notation and it prevents the probabilities to look better than what they are at first glance. 4) Section 4.1 Average packet is 354 bytes not 384 bytes. 5)In Applicability section It can be easily shown that in the absence of malicious user, O-S HDLC adds less than 1% overhead, and also O-S HDLC has one byte less fixed header overhead than SDL. Therefore statements like "Significant higher throughput can be obtained" is not correct. Besides SDL cost is higher than O-S HDLC because you require multiple parallel framers, and you need to still have the O-S HDLC (as default)and therefore you require both HDLC and SDL which makes the equipment more complicated and more expensive. 6) Security section One potential security problem (in set-reset scrambler), which is not mentioned, is the possibility of a Malicious user transmitting consecutive data looking like Length+CRC16 which can significantly increase MTTF (remember the set-rest scrambler can't help because it is disabled before frame Sync. is achieved). For example a packet containing: FF CRC16 FF CRC16 FF CRC16 ... ,in which CRC16 is calculated over FF, can increase MTTF for 354 byte average packet to 185 packets rather than normal 1.5 packets. Regards, Shahram -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Tuesday, September 07, 1999 4:13 AM Cc: ietf-ppp@merit.edu Subject: I-D ACTION:draft-ietf-pppext-sdl-04.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : PPP over Simple Data Link (SDL) using SONET/SDH with ATM-like framing Author(s) : J. Carlson, P. Langner, E.J. Hernandez Valencia, J. Manchester Filename : draft-ietf-pppext-sdl-04.txt Pages : 29 Date : 03-Sep-99 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links, and RFCs 1662 [2] and 1619 [3] provide a means to carry PPP over Synchronous Optical Network (SONET) [4] and Synchronous Digital Hierarchy (SDH) [5] circuits. This document extends these standards to include a new encapsulation for PPP called Simple Data Link (SDL) [6]. SDL provides a very low overhead alternative to standard HDLC encapsulation, and can also be used on SONET/SDH links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-sdl-04.txt Internet-Drafts are also 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-sdl-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pppext-sdl-04.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. From owner-ietf-ppp-outgoing@merit.edu Wed Sep 8 11:41:14 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B6B954AB85; Wed, 8 Sep 1999 09:12:34 -0400 (EDT) Received: from lohi.eng.telia.fi (lohi.eng.telia.fi [195.10.149.18]) by segue.merit.edu (Postfix) with ESMTP id A9FD25A92D for ; Wed, 8 Sep 1999 05:39:46 -0400 (EDT) Received: (from jh@localhost) by lohi.eng.telia.fi (8.9.3/8.9.3/Debian/GNU) id MAA05577; Wed, 8 Sep 1999 12:39:40 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14294.11996.688610.851703@lohi.eng.telia.fi> Date: Wed, 8 Sep 1999 12:39:40 +0300 (EEST) To: ietf-ppp@merit.edu Subject: l2tp m bit semantics X-Mailer: VM 6.74 under Emacs 19.34.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu what is the scope of the word "recognize" in this statement of the l2tp spec? Mandatory (M) bit: Controls the behavior required of an implementation which receives an AVP which it does not recognize. for example, if an lns receives an SCCRQ request that has the Result Code AVP in it, should it consider the Result Code AVP as unrecognized within the SCCRQ message and thus silently ignore it or should it consider the message errorneous and reject the whole request? i'm asking on behalf of who major vendors that interprete the statement differently. -- juha From owner-ietf-ppp-outgoing@merit.edu Wed Sep 8 11:50:34 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 77D5F4FAB6; Wed, 8 Sep 1999 11:49:45 -0400 (EDT) Received: from mercury.ukc.ac.uk (mercury.ukc.ac.uk [129.12.21.10]) by segue.merit.edu (Postfix) with ESMTP id 138894FBF8 for ; Wed, 8 Sep 1999 11:48:29 -0400 (EDT) Received: from gos.ukc.ac.uk ([129.12.4.65] helo=gos) by mercury.ukc.ac.uk with esmtp (Exim 2.12 #1) id 11OjxT-0001Ly-00 for ietf-ppp@merit.edu; Wed, 8 Sep 1999 16:48:27 +0100 Received: from localhost ([127.0.0.1]) by gos with smtp (Exim 2.12 #2) id 11Ojx9-0005pB-00 for ietf-ppp@merit.edu; Wed, 8 Sep 1999 16:48:07 +0100 Date: Wed, 8 Sep 1999 16:48:07 +0100 (BST) From: "Ian Moy." X-Sender: ism1@gos To: ppp Subject: MPPE and Multi-link Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Hi, I have been looking at implementing MPPE over a multi-link and have come up with a few questions. I was planning to do the encryption at the bundle level, before the multi-link stage. If I wanted to use a 128-bit key, you need to use the CHAP challenge value to initialise the session key but, I believe, CHAP will be used on each individual link. Will a different challenge value be used on each link? If so, does this mean that you cannot use MPPE with 128-bit key at the bundle level? I am presuming that MPPE with 40-bit key can be used as this only requires the password, which will be the same for each link? Any help on this matter will be greatly received. Ian. From owner-ietf-ppp-outgoing@merit.edu Wed Sep 8 14:54:56 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 785175DD94; Wed, 8 Sep 1999 14:54:56 -0400 (EDT) Received: from auemlsrv.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by segue.merit.edu (Postfix) with ESMTP id 0063C5DD92 for ; Wed, 8 Sep 1999 14:54:44 -0400 (EDT) Received: from auemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id OAA23273 for ; Wed, 8 Sep 1999 14:54:44 -0400 (EDT) Received: from hoserve.ho.lucent.com (h135-17-35-10.lucent.com [135.17.35.10]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id OAA23173; Wed, 8 Sep 1999 14:54:38 -0400 (EDT) From: enrique@lucent.com Received: from hopaw32.ho.lucent.com by hoserve.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id OAA18148; Wed, 8 Sep 1999 14:56:08 -0400 Received: by hopaw32.ho.lucent.com (8.8.8+Sun/EMS-1.4.1 client sol2) id OAA15733; Wed, 8 Sep 1999 14:56:05 -0400 (EDT) Date: Wed, 8 Sep 1999 14:56:05 -0400 (EDT) Message-Id: <199909081856.OAA15733@hopaw32.ho.lucent.com> To: ietf-ppp@merit.edu, Shahram_Davari@pmc-sierra.com Subject: RE: I-D ACTION:draft-ietf-pppext-sdl-04.txt Reply-To: enrique@bell-labs.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: LBX+dn+N7A0hxdvfYNHYqA== Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Shahram_Davari wrote: > > 1) Section 4.4 > > False Sync can occur when a False Framing has occurred even if the scrambler > state message is correct. That is due to the fact that the header is not > scrambled, and therefore the two consecutive false CRC-16 match headers are > removed and are not descrambled, causing the other data bits to be in wrong > descrambling/sync position. You must still pass 2 header CRC-16s and 2 payload CRC-16s ... > 2) Section 4.4 > > In first paragraph it is written 232.8E-21 = 2^-32 which is wrong and should > be 232.8 E-12 = 2.328 E-10 Right (transposed numbers 21 vs 12). Thanks, we'll correct that. > 3) In almost all probabilities the scientific notation should include only > one decimal point before the fraction point like 3.679 E-1 rather than > 367.9 E-3. Because this is the proper use of scientific notation and it > prevents the probabilities to look better than what they are at first > glance. No need to look for ulterior motives, you only need to ask. > 4) Section 4.1 > > Average packet is 354 bytes not 384 bytes. We seem to be using slightly different assumptions. > 5)In Applicability section > > It can be easily shown that in the absence of malicious user, O-S HDLC adds > less than 1% overhead, and also O-S HDLC has one byte less fixed header > overhead than SDL. Therefore statements like "Significant higher throughput > can be obtained" is not correct. As you point out, the distinction is between short-term vs long-term throughputs, particularly for applications that natively generate large numbers of (relevant) control characters. > Besides SDL cost is higher than O-S HDLC > because you require multiple parallel framers, and you need to still have > the O-S HDLC (as default)and therefore you require both HDLC and SDL which > makes the equipment more complicated and more expensive. Neither is required. Besides, the cost of implemented SDL in some chipsets is so low that you almost get it for free. > 6) Security section > > One potential security problem (in set-reset scrambler), which is not > mentioned, is the possibility of a Malicious user transmitting consecutive > data looking like Length+CRC16 which can significantly increase MTTF > (remember the set-rest scrambler can't help because it is disabled before > frame Sync. is achieved). For example a packet containing: FF CRC16 FF CRC16 > FF CRC16 ... ,in which CRC16 is calculated over FF, can increase MTTF for > 354 byte average packet to 185 packets rather than normal 1.5 packets. We seem to be taking about a different mechanism. Still, such a packet cannot, by itself, force link re-synchronization (as was the issue for the killer packet). Thus, the probability of link resynch (already quite low) is independent of the packet payload, which makes the overall probability of such an event rather small. If this rare event does happen (link fails, only one framer, next frame is a malicious user frame) it can only delay the time to frame, as oppose to bringing down the link. Thanks for the comments, Enrique From owner-ietf-ppp-outgoing@merit.edu Wed Sep 8 17:19:55 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3B4A05DD90; Wed, 8 Sep 1999 17:19:55 -0400 (EDT) Received: from ironbridgenetworks.com (helios.ironbridgenetworks.com [146.115.140.2]) by segue.merit.edu (Postfix) with ESMTP id 907775DD8C for ; Wed, 8 Sep 1999 17:19:53 -0400 (EDT) Received: (from news@localhost) by ironbridgenetworks.com (8.9.3/8.9.3) id RAA08962 for ietf-ppp@merit.edu; Wed, 8 Sep 1999 17:19:53 -0400 (EDT) To: ietf-ppp@merit.edu From: James Carlson Newsgroups: lists.ietf.ppp Subject: Re: I-D ACTION:draft-ietf-pppext-sdl-04.txt Date: 08 Sep 1999 17:19:52 -0400 Organization: IronBridge Networks Lines: 37 Message-ID: <86puztyubr.fsf@ironbridgenetworks.com> References: <199909081856.OAA15733@hopaw32.ho.lucent.com> NNTP-Posting-Host: helios.ibnets.com X-Newsreader: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu enrique@lucent.com writes: > Shahram_Davari wrote: > > 3) In almost all probabilities the scientific notation should include only > > one decimal point before the fraction point like 3.679 E-1 rather than > > 367.9 E-3. Because this is the proper use of scientific notation and it > > prevents the probabilities to look better than what they are at first > > glance. > > No need to look for ulterior motives, you only need to ask. Yes, I agree that the way I'm using scientific notation here is not standard. I chose to do this so that the numbers would be a little easier to read, not to obscure the statistics -- they're in groups of 3. If it makes anyone any happier at all, I'll forgo trying to get the decimals to line up, and switch to straight X.XXXE-YY format while I fix the typo. > > 4) Section 4.1 > > > > Average packet is 354 bytes not 384 bytes. > > We seem to be using slightly different assumptions. The "average" packet size is not a fixed thing. It has been changing over time and certain varies depending on whose network you're monitoring and which particular links. I have assumed 384 here because larger packets are actually *WORSE* for SDL in terms of unavailability, since larger packets mean fewer opportunities for synchronization. -- James Carlson, System Architect IronBridge Networks / 55 Hayden Avenue 71.246W Vox: +1 781 372 8132 Lexington MA 02421-7996 / USA 42.423N Fax: +1 781 372 8090 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Wed Sep 8 17:37:04 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5D22E5DD96; Wed, 8 Sep 1999 17:37:04 -0400 (EDT) Received: from ironbridgenetworks.com (helios.ironbridgenetworks.com [146.115.140.2]) by segue.merit.edu (Postfix) with ESMTP id A13B35DD91 for ; Wed, 8 Sep 1999 17:37:02 -0400 (EDT) Received: (from news@localhost) by ironbridgenetworks.com (8.9.3/8.9.3) id RAA16696 for ietf-ppp@merit.edu; Wed, 8 Sep 1999 17:37:02 -0400 (EDT) To: ietf-ppp@merit.edu From: James Carlson Newsgroups: lists.ietf.ppp Subject: Re: l2tp m bit semantics Date: 08 Sep 1999 17:37:02 -0400 Organization: IronBridge Networks Lines: 27 Message-ID: <86ogfdytj5.fsf@ironbridgenetworks.com> References: <14294.11996.688610.851703@lohi.eng.telia.fi> NNTP-Posting-Host: helios.ibnets.com X-Newsreader: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu jh@lohi.eng.telia.fi (Juha Heinanen) writes: > Mandatory (M) bit: Controls the behavior required of an > implementation which receives an AVP which it does not recognize. > > for example, if an lns receives an SCCRQ request that has the Result > Code AVP in it, should it consider the Result Code AVP as unrecognized > within the SCCRQ message and thus silently ignore it or should it > consider the message errorneous and reject the whole request? One would think that AVPs defined by the base document (RFC 2661) are fully defined by that document. In other words, if Result Code appears outside of the context of CDN or StopCCN, then it's a protocol error, not an "unrecognized" AVP. The implication would be that the only "unrecognized" AVPs are those that an implementation doesn't implement in any context. (Presumably because they're defined outside of RFC 2661.) I agree, though, with the idea that the "mandatory" bit is an incompletely specified idea. A better implementation of the same idea is in RFC 1771 ... -- James Carlson, System Architect IronBridge Networks / 55 Hayden Avenue 71.246W Vox: +1 781 372 8132 Lexington MA 02421-7996 / USA 42.423N Fax: +1 781 372 8090 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Wed Sep 8 17:42:47 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 844C45DD9B; Wed, 8 Sep 1999 17:42:47 -0400 (EDT) Received: from ironbridgenetworks.com (helios.ironbridgenetworks.com [146.115.140.2]) by segue.merit.edu (Postfix) with ESMTP id E84EB5DD96 for ; Wed, 8 Sep 1999 17:42:45 -0400 (EDT) Received: (from news@localhost) by ironbridgenetworks.com (8.9.3/8.9.3) id RAA19283 for ietf-ppp@merit.edu; Wed, 8 Sep 1999 17:42:45 -0400 (EDT) To: ietf-ppp@merit.edu From: James Carlson Newsgroups: lists.ietf.ppp Subject: Re: MPPE and Multi-link Date: 08 Sep 1999 17:42:45 -0400 Organization: IronBridge Networks Lines: 29 Message-ID: <86n1uxyt9m.fsf@ironbridgenetworks.com> References: NNTP-Posting-Host: helios.ibnets.com X-Newsreader: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu ism1@ukc.ac.uk ("Ian Moy.") writes: > I have been looking at implementing MPPE over a multi-link and have come > up with a few questions. > > I was planning to do the encryption at the bundle level, before the > multi-link stage. If I wanted to use a 128-bit key, you need to use the > CHAP challenge value to initialise the session key but, I believe, CHAP > will be used on each individual link. At least *some* security must be present on each individual link if it is present on *any* link in the bundle. > Will a different challenge value be used on each link? Absolutely! CHAP demands that the random numbers be, well, random. > If so, does this mean that you cannot use MPPE with 128-bit key at the > bundle level? I would say that MPPE isn't a standard, isn't an active subject of this working group, and doesn't take some of the other relevant standards, such as RFC 1990, into consideration in its design. If it doesn't work in that or other contexts, then that's just how it is. -- James Carlson, System Architect IronBridge Networks / 55 Hayden Avenue 71.246W Vox: +1 781 372 8132 Lexington MA 02421-7996 / USA 42.423N Fax: +1 781 372 8090 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Wed Sep 8 17:51:16 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6A7595DD9B; Wed, 8 Sep 1999 17:51:16 -0400 (EDT) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by segue.merit.edu (Postfix) with ESMTP id AD6585DD97 for ; Wed, 8 Sep 1999 17:51:14 -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 (6.6.6/6.6.6) with ESMTP id OAA10456; Wed, 8 Sep 1999 14:51:08 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2448.0) id ; Wed, 8 Sep 1999 14:51:07 -0700 Message-ID: From: Shahram Davari To: "'enrique@bell-labs.com'" , ietf-ppp@merit.edu Cc: "'James Carlson'" Subject: RE: I-D ACTION:draft-ietf-pppext-sdl-04.txt Date: Wed, 8 Sep 1999 14:51:05 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Hi Enrique, In the order of questions: 1) According to page 9 of the draft "The Scrambler is not clocked when SDL header bits are transmitted". 3) Sorry, I didn't mean that it was done in purpose. 4) I took the 354 bytes from some other Lucent's SDL paper, which had exactly the same final service unavailability results. 5) Let's not generalize special cases. For example one can argue that in voice applications which have very short packets, SDL has less throughput than HDLC, because SDL has 8 bytes fixed header, vs. 7 bytes in HDLC. Plus the fact that using set-reset scrambler requires one state transmission every 8 frames. Now is one allowed to state "HDLC has higher throughput than SDL"? If you don't include parallel framers the performance will suffer. And if you don't include HDLC, you will face interoperability issue. 6) As in (1) during miss-framing period wrong number of bits are potentially passed through descrambler, and therefore your descrambler state and therefore your byte sync. is wrong. And as you agree MTTF will also suffer. Regards, Shahram -----Original Message----- From: enrique@lucent.com [mailto:enrique@lucent.com] Sent: Wednesday, September 08, 1999 11:56 AM To: ietf-ppp@merit.edu; Shahram_Davari@pmc-sierra.com Subject: RE: I-D ACTION:draft-ietf-pppext-sdl-04.txt Shahram_Davari wrote: > > 1) Section 4.4 > > False Sync can occur when a False Framing has occurred even if the scrambler > state message is correct. That is due to the fact that the header is not > scrambled, and therefore the two consecutive false CRC-16 match headers are > removed and are not descrambled, causing the other data bits to be in wrong > descrambling/sync position. You must still pass 2 header CRC-16s and 2 payload CRC-16s ... > 2) Section 4.4 > > In first paragraph it is written 232.8E-21 = 2^-32 which is wrong and should > be 232.8 E-12 = 2.328 E-10 Right (transposed numbers 21 vs 12). Thanks, we'll correct that. > 3) In almost all probabilities the scientific notation should include only > one decimal point before the fraction point like 3.679 E-1 rather than > 367.9 E-3. Because this is the proper use of scientific notation and it > prevents the probabilities to look better than what they are at first > glance. No need to look for ulterior motives, you only need to ask. > 4) Section 4.1 > > Average packet is 354 bytes not 384 bytes. We seem to be using slightly different assumptions. > 5)In Applicability section > > It can be easily shown that in the absence of malicious user, O-S HDLC adds > less than 1% overhead, and also O-S HDLC has one byte less fixed header > overhead than SDL. Therefore statements like "Significant higher throughput > can be obtained" is not correct. As you point out, the distinction is between short-term vs long-term throughputs, particularly for applications that natively generate large numbers of (relevant) control characters. > Besides SDL cost is higher than O-S HDLC > because you require multiple parallel framers, and you need to still have > the O-S HDLC (as default)and therefore you require both HDLC and SDL which > makes the equipment more complicated and more expensive. Neither is required. Besides, the cost of implemented SDL in some chipsets is so low that you almost get it for free. > 6) Security section > > One potential security problem (in set-reset scrambler), which is not > mentioned, is the possibility of a Malicious user transmitting consecutive > data looking like Length+CRC16 which can significantly increase MTTF > (remember the set-rest scrambler can't help because it is disabled before > frame Sync. is achieved). For example a packet containing: FF CRC16 FF CRC16 > FF CRC16 ... ,in which CRC16 is calculated over FF, can increase MTTF for > 354 byte average packet to 185 packets rather than normal 1.5 packets. We seem to be taking about a different mechanism. Still, such a packet cannot, by itself, force link re-synchronization (as was the issue for the killer packet). Thus, the probability of link resynch (already quite low) is independent of the packet payload, which makes the overall probability of such an event rather small. If this rare event does happen (link fails, only one framer, next frame is a malicious user frame) it can only delay the time to frame, as oppose to bringing down the link. Thanks for the comments, Enrique From owner-ietf-ppp-outgoing@merit.edu Fri Sep 10 04:11:59 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A5B2D5DDAF; Fri, 10 Sep 1999 04:11:58 -0400 (EDT) Received: from s2.smtp.oleane.net (s2.smtp.oleane.net [195.25.12.6]) by segue.merit.edu (Postfix) with ESMTP id 9CD9E5DDAD for ; Fri, 10 Sep 1999 04:11:56 -0400 (EDT) Received: from nec.oleane.com (dyn-1-1-253.Cor.dialup.oleane.fr [62.161.8.253]) by s2.smtp.oleane.net with SMTP id KAA41853 for ; Fri, 10 Sep 1999 10:11:55 +0200 (CEST) Message-ID: <012001befb64$4d7d20e0$0201a8c0@nec.oleane.com> From: "Peter lewis" To: Subject: QoS Summit Date: Fri, 10 Sep 1999 10:13:01 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu QoS Summit: key requirements for advanced applications running on future networks. Technologies (MPLS, ATM, IntSev/DiffServ, Frame Relay). Managing, policing, billing, charging QoS. The annual rendez-vous with top senior specialists. Paris, France, 16-19 November 1999 Please see details at the following web address: http://www.upperside.fr/baqos.htm Sorry to post this message on the list. Thanks From owner-ietf-ppp-outgoing@merit.edu Fri Sep 10 11:12:10 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0AC105DE05; Fri, 10 Sep 1999 11:11:49 -0400 (EDT) Received: from mercury.ukc.ac.uk (mercury.ukc.ac.uk [129.12.21.10]) by segue.merit.edu (Postfix) with ESMTP id 6AE625DDFE for ; Fri, 10 Sep 1999 11:09:48 -0400 (EDT) Received: from gos.ukc.ac.uk ([129.12.4.65] helo=gos) by mercury.ukc.ac.uk with esmtp (Exim 2.12 #1) id 11PSJ5-0007aX-00 for ietf-ppp@merit.edu; Fri, 10 Sep 1999 16:09:43 +0100 Received: from localhost ([127.0.0.1]) by gos with smtp (Exim 2.12 #2) id 11PSIj-0001g4-00 for ietf-ppp@merit.edu; Fri, 10 Sep 1999 16:09:21 +0100 Date: Fri, 10 Sep 1999 16:09:21 +0100 (BST) From: "Ian Moy." X-Sender: ism1@gos To: ppp Subject: MPPE and MS-CHAP Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Hi, According to RFC 2433, MS PPP CHAP extensions, the use of the LAN management password should not be used in MS-CHAP and with MS-CHAP-v2, the LAN management password is not included at all. Does this mean that MPPE with a 40-bit key, which uses the LAN management password to initialise, is also redundant? Is it possible to use the NT password for the initialisation of the 40-bit key if the LAN management password is not present? Any help on sorting out this problem would be greatly received. Cheers, Ian. From owner-ietf-ppp-outgoing@merit.edu Fri Sep 10 17:32:13 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B32315DDE7; Fri, 10 Sep 1999 17:32:12 -0400 (EDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by segue.merit.edu (Postfix) with ESMTP id 5FD325DDC9 for ; Fri, 10 Sep 1999 17:32:11 -0400 (EDT) Received: from southrelay01.raleigh.ibm.com (southrelay01.raleigh.ibm.com [9.37.3.208]) by e2.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id RAA205416 for ; Fri, 10 Sep 1999 17:31:41 -0400 Received: from jmartz (DIP005899END.endicott.ibm.com [9.130.69.192]) by southrelay01.raleigh.ibm.com (8.8.8m2/NCO v2.04) with SMTP id RAA43848 for ; Fri, 10 Sep 1999 17:32:06 -0400 Message-ID: <000f01befbd3$ec5ad6c0$c0458209@us.ibm.com> From: "John R. Martz" To: Subject: How handle an unacceptable CfgNak?? Date: Fri, 10 Sep 1999 17:31:53 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu What's the correct response if a peer sends a CfgNak to prompt for an option that is NOT acceptable for negotiation? Today I was looking through a trace that came in from a customer and saw a situation like this. My implementation is receiving a Configure-Nak containing MRRU (LCP option 0x11) from the other peer. Apparently the other peer desires to use MP in the worst way, but it's just not going to happen. Is there a way to actively tell a peer that is sending you prompting CfgNak's to "shut up already"? All I could think of was Configure-Reject. However, the description of Configure-Reject in RFC 1661 only allows sending Configure-Reject in response to an option in a Configure-Request, not Configure-Nak. Thanks, -john martz (jmartz@us.ibm.com) IBM AS/400 TCP/IP PPP (and stuff) From owner-ietf-ppp-outgoing@merit.edu Fri Sep 10 17:58:21 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 52F5F5DDC3; Fri, 10 Sep 1999 17:58:21 -0400 (EDT) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by segue.merit.edu (Postfix) with ESMTP id A019A5DDC1 for ; Fri, 10 Sep 1999 17:58:19 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.0/calcite) id PAA13427 for ietf-ppp@merit.edu env-from ; Fri, 10 Sep 1999 15:58:18 -0600 (MDT) Date: Fri, 10 Sep 1999 15:58:18 -0600 (MDT) From: Vernon Schryver Message-Id: <199909102158.PAA13427@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: How handle an unacceptable CfgNak?? Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: "John R. Martz" > What's the correct response if a peer sends a CfgNak to prompt for an option that is NOT acceptable > for negotiation? > > Today I was looking through a trace that came in from a customer and saw a situation like this. My > implementation is receiving a Configure-Nak containing MRRU (LCP option 0x11) from the other peer. > Apparently the other peer desires to use MP in the worst way, but it's just not going to happen. > > Is there a way to actively tell a peer that is sending you prompting CfgNak's to "shut up already"? No. Your implementation should just (and can only) be patient. > All I could think of was Configure-Reject. However, the description of Configure-Reject in RFC 1661 > only allows sending Configure-Reject in response to an option in a Configure-Request, not > Configure-Nak. That's right. You cannot send a Configure-Reject in response to a Configure-Nak. James Carlson's book, "PPP Design and Debugging" addresses this and similar issues. I know this point has been often mentioned in this mailinglist, but Jim's book is shorter and more readable. It also has an index that points to page 34, which says ... Of course, this rarely works to prod the Configure-Request sender to include the option. ... Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp-outgoing@merit.edu Mon Sep 13 06:51:30 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B63C95DDD0; Mon, 13 Sep 1999 06:51:29 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 550385DDC6 for ; Mon, 13 Sep 1999 06:51:27 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20007; Mon, 13 Sep 1999 06:51:25 -0400 (EDT) Message-Id: <199909131051.GAA20007@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-mppe-keys-01.txt Date: Mon, 13 Sep 1999 06:51:25 -0400 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@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 : MPPE Key Derivation Author(s) : G. Zorn Filename : draft-ietf-pppext-mppe-keys-01.txt Pages : 16 Date : 10-Sep-99 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. The PPP Compression Control Protocol [2] provides a method to negotiate and utilize compression protocols over PPP encapsulated links. Microsoft Point to Point Encryption (MPPE) [4] is a means of representing PPP packets in an encrypted form. MPPE uses the RSA RC4 [5] algorithm to provide data confidentiality. The length of the session key to be used for initializing encryption tables can be negotiated. MPPE currently supports 40-bit and 128-bit session keys. MPPE session keys are changed frequently; the exact frequency depends upon the options negotiated, but may be every packet. MPPE is negotiated within option 18 [6] in the Compression Control Protocol. This document describes the method used to derive initial MPPE session keys from a variety of credential types. It is expected that this memo will be updated whenever Microsoft defines a new key derivation method for MPPE, since its primary purpose is to provide an open, easily accessible reference for third-parties wishing to interoperate with Microsoft products. The algorithm used to change session keys during a session is described in [4]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-mppe-keys-01.txt Internet-Drafts are also 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-mppe-keys-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pppext-mppe-keys-01.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: <19990910070717.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-mppe-keys-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-mppe-keys-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990910070717.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ppp-outgoing@merit.edu Mon Sep 13 17:33:27 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4AAFD5DDE0; Mon, 13 Sep 1999 17:33:27 -0400 (EDT) Received: from intra0.extant.net (intra0.lvp.extant.net [216.28.121.11]) by segue.merit.edu (Postfix) with ESMTP id C33D25DD95 for ; Mon, 13 Sep 1999 17:33:25 -0400 (EDT) Received: from karl ([216.28.121.202]) by intra0.extant.net (Netscape Messaging Server 3.6) with ESMTP id AAA63E6; Mon, 13 Sep 1999 17:33:27 -0400 Message-Id: <4.2.0.58.19990913173121.04652670@mail.extant.net> X-Sender: kfox@mail.extant.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 13 Sep 1999 17:33:23 -0400 To: ietf-ppp@merit.edu From: "Karl Fox" Subject: draft-ietf-pppext-eaptls-06.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu The IESG has suggested that the draft draft-ietf-pppext-eaptls-06.txt should perhaps go forward as Experimental rather than Informational. We originally sent it up as Informational since there didn't seem to be broad calls for it, but there is nothing proprietary about it and it is indeed possible that one day we might want to advance it along the standards track. Should we ever do so, it would be easier if it were Experimental. Comments? Karl Fox Key fingerprint = 5B15 7260 D55E D680 0B93 4953 8A3B AB0E C05D 77A3 From chantall@upperside.fr Tue Sep 14 06:45:10 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from s2.smtp.oleane.net (s2.smtp.oleane.net [195.25.12.6]) by segue.merit.edu (Postfix) with ESMTP id 83CDE5DD94; Tue, 14 Sep 1999 06:45:08 -0400 (EDT) Received: from Dell (dyn-1-1-236.Cor.dialup.oleane.fr [62.161.8.236]) by s2.smtp.oleane.net with SMTP id MAA96764; Tue, 14 Sep 1999 12:26:12 +0200 (CEST) Message-ID: <007501befe9b$d731be60$0701a8c0@oleane.com> From: "Chantal Ladouce" To: "chantal" Subject: From Firewall to IPSec VPNs Date: Tue, 14 Sep 1999 12:26:36 +0200 Organization: upperside MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0072_01BEFEAC.637FC320" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 This is a multi-part message in MIME format. ------=_NextPart_000_0072_01BEFEAC.637FC320 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Security services and protection mechanisms IPv6 promises regarding IPSec Certification infrastructure Standardization update Case Studies: ISPs, carriers, private networks AH and ESP protocols description Possible future extensions and modifications of the IKE protocol Complementarity between IPSec and firewalls Global Site-to-Site IPSec VPN's with End-to-End SLA's Managing widespread IPSEC virtual private networks Solving IPSec VPNs scalability Results of some interoperability tests IPSec architectures and non-standardized aspects of IPSec Adding IPSec VPN functions in an existing router network Impact of fragmentation on the performance of IPSec coding IPSEC 99 Conference From Firewall to IPSec VPNs October 26, 27, 28, 29, 1999 Paris - France More infos: www.upperside.fr/baipsec.htm ------=_NextPart_000_0072_01BEFEAC.637FC320 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Security services and protection mechanisms
IPv6 = promises=20 regarding IPSec
Certification infrastructure
Standardization=20 update
Case Studies: ISPs, carriers, private networks
AH and ESP = protocols=20 description
Possible future extensions and modifications of the IKE=20 protocol
Complementarity between IPSec and firewalls
Global = Site-to-Site=20 IPSec VPN's with End-to-End SLA's
Managing widespread IPSEC virtual = private=20 networks
Solving IPSec VPNs scalability
Results of some = interoperability=20 tests
IPSec architectures and non-standardized aspects of = IPSec
Adding=20 IPSec VPN functions in an existing router network
Impact of = fragmentation on=20 the performance of IPSec coding

IPSEC 99 Conference
From = Firewall to=20 IPSec VPNs

October 26, 27, 28, 29, 1999
Paris - = France

More=20 infos: www.upperside.fr/baipsec.htm=
 
 
 
------=_NextPart_000_0072_01BEFEAC.637FC320-- From owner-ietf-ppp-outgoing@merit.edu Wed Sep 15 14:34:52 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8287A5DDAE; Wed, 15 Sep 1999 14:34:52 -0400 (EDT) Received: from smtpgw02.wanmail.net (smtpgw02.wanmail.net [209.154.194.61]) by segue.merit.edu (Postfix) with ESMTP id 100D45DF11 for ; Wed, 15 Sep 1999 14:34:51 -0400 (EDT) Received: from wcomexch1.wcom.net (wcomexch1.wcom.net [209.154.236.12]) by smtpgw02.wanmail.net (8.9.1/8.9.1) with ESMTP id OAA28344; Wed, 15 Sep 1999 14:34:44 -0400 (EDT) Received: by wcomexch1.wcom.net with Internet Mail Service (5.5.2448.0) id ; Wed, 15 Sep 1999 14:34:06 -0400 Message-ID: <9A74C89D6696D2118E500008C7BA7C560C03B0AD@wcomexch1.wcom.net> From: "Beadles, Mark A." To: "'Karl Fox'" , ietf-ppp@merit.edu Subject: RE: draft-ietf-pppext-eaptls-06.txt Date: Wed, 15 Sep 1999 14:33:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu I think there may be value in standardizing this document. If calling it Experimental makes that easier, then I am all for that. + Mark Anthony Beadles + UUNET Product Development + + mbeadles@wcom.net + http://networking.us.uu.net + + Voice 614.723.1941 + Fax 614.723.8407 + From owner-ietf-ppp-outgoing@merit.edu Fri Sep 17 13:43:43 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8017F5DDD0; Fri, 17 Sep 1999 13:43:43 -0400 (EDT) Received: from abraham.cs.berkeley.edu (abraham.CS.Berkeley.EDU [128.32.37.121]) by segue.merit.edu (Postfix) with ESMTP id 79FAD5DDCF for ; Fri, 17 Sep 1999 13:43:39 -0400 (EDT) Received: from blowfish.isaac.cs.berkeley.edu (blowfish.isaac.cs.berkeley.edu [169.229.3.195]) by abraham.cs.berkeley.edu (8.8.6/8.8.6) with ESMTP id KAA21213 for ; Fri, 17 Sep 1999 10:43:14 -0700 Received: (from daw@localhost) by blowfish.isaac.cs.berkeley.edu (8.8.7/8.8.7) id KAA09521 for ietf-ppp@merit.edu; Fri, 17 Sep 1999 10:21:29 -0700 From: David Wagner Message-Id: <199909171721.KAA09521@blowfish.isaac.cs.berkeley.edu> Subject: Re: I-D ACTION:draft-ietf-pppext-mppe-keys-01.txt To: ietf-ppp@merit.edu Date: Fri, 17 Sep 1999 17:21:29 +0000 () In-Reply-To: <199909131051.GAA20007@ietf.org> X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Some feedback on the MPPE draft: The MPPE key derivation process uses a fixed prefix, 0xD1269E, to derive 40-bit RC4 session keys. I find this use of a "magic number" very suspicious. Where did this value come from? Who picked it? Why should we believe that it is not a trapdoor? Was it randomly chosen, or does it have special properties? Most cryptographers (justifiably) have a widespread distrust of "magic numbers" like this, because there are examples where they can be used to secretly weaken a system. Thus, most block cipher designs today explain how their S-boxes were chosen (e.g., the digits of pi, the contents of the Declaration of Independence, the SHA-hash of zero), so the reader can be sure that they were not chosen as a special backdoor. I propose that, for an IETF standard such as PPP, either (1) the choice of this "magic number" must be clearly and thoroughly explained, or (2) the "magic number" must be eliminated from the standard. Just my opinion. -- David Wagner, daw@cs.berkeley.edu From owner-ietf-ppp-outgoing@merit.edu Fri Sep 17 15:29:09 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 29B7C5DDC0; Fri, 17 Sep 1999 15:29:09 -0400 (EDT) Received: from smtpgw02.wanmail.net (smtpgw02.wanmail.net [209.154.194.61]) by segue.merit.edu (Postfix) with ESMTP id BB6AD5DDB1 for ; Fri, 17 Sep 1999 15:29:07 -0400 (EDT) Received: from wcomexch1.wcom.net (wcomexch1.wcom.net [209.154.236.12]) by smtpgw02.wanmail.net (8.9.1/8.9.1) with ESMTP id PAA08191; Fri, 17 Sep 1999 15:28:35 -0400 (EDT) Received: by wcomexch1.wcom.net with Internet Mail Service (5.5.2448.0) id ; Fri, 17 Sep 1999 15:27:59 -0400 Message-ID: <9A74C89D6696D2118E500008C7BA7C560C03B0C1@wcomexch1.wcom.net> From: "Beadles, Mark A." To: "'David Wagner'" , ietf-ppp@merit.edu Subject: RE: I-D ACTION:draft-ietf-pppext-mppe-keys-01.txt Date: Fri, 17 Sep 1999 15:27:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu From: David Wagner [mailto:daw@cs.berkeley.edu] >I propose that, for an IETF standard such as PPP, either (1) the >choice of this "magic number" must be clearly and thoroughly explained, >or (2) the "magic number" must be eliminated from the standard. From the draft: >Category: Informational >This memo >does not specify an Internet standard of any kind. + Mark Anthony Beadles + UUNET Product Development + + mbeadles@wcom.net + http://networking.us.uu.net + + Voice 614.723.1941 + Fax 614.723.8407 + From owner-ietf-ppp-outgoing@merit.edu Mon Sep 20 17:15:47 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id BF4185DDE0; Mon, 20 Sep 1999 17:15:46 -0400 (EDT) Received: from abraham.cs.berkeley.edu (abraham.CS.Berkeley.EDU [128.32.37.121]) by segue.merit.edu (Postfix) with ESMTP id 057FD5DDB9 for ; Mon, 20 Sep 1999 17:15:45 -0400 (EDT) Received: from blowfish.isaac.cs.berkeley.edu (blowfish.isaac.cs.berkeley.edu [169.229.3.195]) by abraham.cs.berkeley.edu (8.8.6/8.8.6) with ESMTP id OAA22476 for ; Mon, 20 Sep 1999 14:15:23 -0700 Received: (from daw@localhost) by blowfish.isaac.cs.berkeley.edu (8.8.7/8.8.7) id NAA11291 for ietf-ppp@merit.edu; Mon, 20 Sep 1999 13:53:32 -0700 From: David Wagner Message-Id: <199909202053.NAA11291@blowfish.isaac.cs.berkeley.edu> Subject: Re: I-D ACTION:draft-ietf-pppext-mppe-keys-01.txt To: ietf-ppp@merit.edu Date: Mon, 20 Sep 1999 20:53:30 +0000 () In-Reply-To: <9A74C89D6696D2118E500008C7BA7C560C03B0C1@wcomexch1.wcom.net> X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Several folks have noted that the MPPE Internet-drafts are not standards-track. You're right -- I overlooked that. Thanks. I agree that this makes these issues less important. But I'm still under the impression that this is an appropriate forum for comments. (Correct me if I'm wrong.) After all, these drafts live in the draft-ietf-pppext-* namespace, which I understood to be reserved for matters under consideration of the PPPEXT working group. (That seemed to be the policy in the IPSEC working group.) But maybe I'm mistaken; I'm not terribly experienced in the ways of the IETF. If the drafts are not intended to be a product of the working group, I suggest that they should be named draft-zorn-* in the future so they do not falsely acquire the appearance of being endorsed as a working document of an IETF working group. A nit, to be sure, but I think it behooves us to make sure the IETF is not seen as endorsing crypto protocols of questionable technical merit. From owner-ietf-ppp-outgoing@merit.edu Tue Sep 21 23:12:34 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 684D45DDA4; Tue, 21 Sep 1999 23:12:34 -0400 (EDT) Received: from pinky.rte.microsoft.com (unknown [131.107.152.16]) by segue.merit.edu (Postfix) with ESMTP id B31525DD8E for ; Tue, 21 Sep 1999 23:12:32 -0400 (EDT) Received: from localhost (gwz@localhost) by pinky.rte.microsoft.com (8.7.6/8.7.3) with SMTP id TAA21677; Tue, 21 Sep 1999 19:56:24 -0700 (PDT) X-Authentication-Warning: pinky.rte.microsoft.com: gwz owned process doing -bs Date: Tue, 21 Sep 1999 19:56:24 -0700 (PDT) From: Glen Zorn To: David Wagner Cc: ietf-ppp@merit.edu Subject: Re: I-D ACTION:draft-ietf-pppext-mppe-keys-01.txt In-Reply-To: <199909202053.NAA11291@blowfish.isaac.cs.berkeley.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu On Mon, 20 Sep 1999, David Wagner wrote: > Several folks have noted that the MPPE Internet-drafts are not > standards-track. You're right -- I overlooked that. Thanks. I agree > that this makes these issues less important. > > But I'm still under the impression that this is an appropriate forum > for comments. (Correct me if I'm wrong.) Not wrong. Since I was (undoubtedly inadvertantly) dropped from this list and only recently re-subscribed, perhaps you could fill me in. > After all, these drafts > live in the draft-ietf-pppext-* namespace, which I understood to be > reserved for matters under consideration of the PPPEXT working group. > (That seemed to be the policy in the IPSEC working group.) But maybe > I'm mistaken; I'm not terribly experienced in the ways of the IETF. > > If the drafts are not intended to be a product of the working group, > I suggest that they should be named draft-zorn-* in the future so they > do not falsely acquire the appearance of being endorsed as a working > document of an IETF working group. There is no 'false acquisition' happening here. > > A nit, to be sure, but I think it behooves us to make sure the IETF is > not seen as endorsing crypto protocols of questionable technical merit. > So what, exactly, is the question? Or, more precisely perhaps, what is the problem? > From owner-ietf-ppp-outgoing@merit.edu Wed Sep 22 16:48:46 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 11BBF5DDC0; Wed, 22 Sep 1999 16:48:46 -0400 (EDT) Received: from pinky.rte.microsoft.com (unknown [131.107.152.16]) by segue.merit.edu (Postfix) with ESMTP id 33C555DDB4 for ; Wed, 22 Sep 1999 16:48:44 -0400 (EDT) Received: from localhost (gwz@localhost) by pinky.rte.microsoft.com (8.7.6/8.7.3) with SMTP id NAA22608; Wed, 22 Sep 1999 13:31:31 -0700 (PDT) X-Authentication-Warning: pinky.rte.microsoft.com: gwz owned process doing -bs Date: Wed, 22 Sep 1999 13:31:31 -0700 (PDT) From: Glen Zorn To: David Wagner Cc: ietf-ppp@merit.edu Subject: Re: I-D ACTION:draft-ietf-pppext-mppe-keys-01.txt In-Reply-To: <199909220309.UAA13186@blowfish.isaac.cs.berkeley.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu On Wed, 22 Sep 1999, David Wagner wrote: > > Not wrong. Since I was (undoubtedly inadvertantly) dropped from this list > > and only recently re-subscribed, perhaps you could fill me in. > > Sure, no problem. Here's a copy of the note I sent to the list > a few days ago. Criticisms / flames are welcome if I'm off-base. > > Thanks for taking the time to look into this, > -- David > > > > > Some feedback on the MPPE draft: > > The MPPE key derivation process uses a fixed prefix, 0xD1269E, to > derive 40-bit RC4 session keys. > > I find this use of a "magic number" very suspicious. Where did > this value come from? Who picked it? Why should we believe that > it is not a trapdoor? Was it randomly chosen, or does it have > special properties? Nobody knows where it came from. It's been suggested that it was picked out of thin air by someone who left the company a long time ago. As far as anyone knows there are no "special properties". > > Most cryptographers (justifiably) have a widespread distrust of > "magic numbers" like this, because there are examples where they > can be used to secretly weaken a system. Thus, most block cipher > designs today explain how their S-boxes were chosen (e.g., the > digits of pi, the contents of the Declaration of Independence, > the SHA-hash of zero), so the reader can be sure that they were > not chosen as a special backdoor. > > I propose that, for an IETF standard such as PPP, either (1) the > choice of this "magic number" must be clearly and thoroughly explained, > or (2) the "magic number" must be eliminated from the standard. > Actually, I'm not sure what the uproar is about (given the (relative) ease of breaking 40-bit RC4). At any rate, since the recent loosening of export controls, I would think that the question is moot: if a customer is concerned at all, they can use 128-bit keys. > Just my opinion. -- David Wagner, daw@cs.berkeley.edu > From owner-ietf-ppp-outgoing@merit.edu Sat Sep 25 01:04:00 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 94DFB5DDAB; Sat, 25 Sep 1999 01:04:00 -0400 (EDT) Received: from cc.sookmyung.ac.kr (cc.sookmyung.ac.kr [203.252.201.4]) by segue.merit.edu (Postfix) with ESMTP id 03A7E5DD99 for ; Sat, 25 Sep 1999 01:03:57 -0400 (EDT) Received: from cs.sookmyung.ac.kr (cs.sookmyung.ac.kr [203.252.206.1]) by cc.sookmyung.ac.kr (8.8.8+Sun/8.8.8) with SMTP id OAA17858 for ; Sat, 25 Sep 1999 14:04:00 +0900 (KST) Received: from cs.sookmyung.ac.kr by cs.sookmyung.ac.kr (SMI-8.6/SMI-SVR4) id OAA10107; Sat, 25 Sep 1999 14:00:22 +0900 Date: Sat, 25 Sep 1999 14:00:22 +0900 (KST) From: "mira : using \" Jung Mi Ra\"" To: ietf-ppp@merit.edu Subject: [Q] L2TP testbed? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Hi~ all Is there any L2TP testbed? Thanks in advance :-) From owner-ietf-ppp-outgoing@merit.edu Tue Sep 28 06:59:03 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8B69F5DDAF; Tue, 28 Sep 1999 06:59:03 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 764FA5DDA8 for ; Tue, 28 Sep 1999 06:59:01 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07204; Tue, 28 Sep 1999 06:58:59 -0400 (EDT) Message-Id: <199909281058.GAA07204@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-secure-ra-00.txt Date: Tue, 28 Sep 1999 06:58:59 -0400 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@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 : Secure Remote Access with L2TP Author(s) : P. Srisuresh Filename : draft-ietf-pppext-secure-ra-00.txt Pages : 18 Date : 27-Sep-99 L2TP protocol is a virtual extension of PPP across IP network infrastructure. L2TP makes possible for an access concentrator(LAC) to be near remote clients, while allowing PPP termination server (LNS) to be located in enterprise premises. L2TP allows an enterprise to retain control of RADIUS data base, which is used to control Authentication, Authorization and Accountability (AAA) of dial-in users. The objective of this document is to extend security characteristics of IPsec to remote access users, as they dial-in through the Internet. This is accomplished without creating new protocols and using the existing practices of Remote Access and IPsec. Specifically, the document proposes three new RADIUS parameters for use by the LNS node, acting as Secure Remote Access Server (SRAS) to mandate network level security between remote clients and the enterprise. The document also discusses limitations of the approach. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-secure-ra-00.txt Internet-Drafts are also 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-secure-ra-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pppext-secure-ra-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: <19990927095311.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-secure-ra-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-secure-ra-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990927095311.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ppp-outgoing@merit.edu Thu Sep 30 07:00:11 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8A5335DE4C; Thu, 30 Sep 1999 07:00:10 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 115525DE44 for ; Thu, 30 Sep 1999 07:00:07 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04437; Thu, 30 Sep 1999 07:00:00 -0400 (EDT) Message-Id: <199909301100.HAA04437@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-bcp-00.txt Date: Thu, 30 Sep 1999 06:59:59 -0400 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : PPP Bridging Control Protocol (BCP) Author(s) : M. Higashiyama, F. Baker, R. Bowen Filename : draft-ietf-pppext-bcp-00.txt Pages : 31 Date : 29-Sep-99 The Point-to-Point Protocol (PPP) [6] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols for establishing and configuring different network-layer protocols. This document defines the Network Control Protocol for establishing and configuring Remote Bridging for PPP links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-bcp-00.txt Internet-Drafts are also 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-bcp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pppext-bcp-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: <19990929093047.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-bcp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-bcp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990929093047.I-D@ietf.org> --OtherAccess-- --NextPart--