From owner-ietf-ppp-outgoing@merit.edu Fri Jan 7 00:48:50 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00337 for ; Fri, 7 Jan 2000 00:48:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2B70B5DD90; Fri, 7 Jan 2000 00:48:17 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A9E5D5DDA3; Fri, 7 Jan 2000 00:48:16 -0500 (EST) Received: from fsnt.future.futusoft.com (unknown [203.197.140.35]) by segue.merit.edu (Postfix) with ESMTP id 5FD125DD90 for ; Fri, 7 Jan 2000 00:48:12 -0500 (EST) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Fri, 07 Jan 2000 11:23:33 +0530 Received: from maturin.future.futsoft.com (maturin.future.futsoft.com [10.0.12.18]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id LAA20915 for ; Fri, 7 Jan 2000 11:07:15 +0530 Received: by localhost with Microsoft MAPI; Fri, 7 Jan 2000 11:15:13 +0530 Message-Id: <01BF5900.780C3040.aruljp@future.futsoft.com> From: "aruljp@future.futsoft.com" Reply-To: "aruljp@future.futsoft.com" To: "'ietf-ppp@segue.merit.edu'" Subject: Doubts in PPP-MP+ Date: Fri, 7 Jan 2000 11:15:12 +0530 Organization: Future Software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Hi, Please clarify these doubts. * For what kind of remote configuration is MP+ used. * Is MP+ interaction between two PPP peers. * Should LCP negotiation be over before MP+ protocol starts to configure a remote station. Thanks in advance, Arul Mohan. From owner-ietf-ppp-outgoing@merit.edu Fri Jan 7 03:45:21 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13104 for ; Fri, 7 Jan 2000 03:45:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id D8F335DD94; Fri, 7 Jan 2000 03:28:27 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5412A5DD97; Fri, 7 Jan 2000 03:28:27 -0500 (EST) Received: from mailhost.digiweb2.dk (mailhost.digiweb2.dk [194.239.250.245]) by segue.merit.edu (Postfix) with ESMTP id BBE235DD94 for ; Fri, 7 Jan 2000 03:28:24 -0500 (EST) Received: from mailhost.digiweb2.dk (mailhost.digiweb2.dk [194.239.250.245]) by mailhost.digiweb2.dk (8.9.3+Sun/8.9.1) with SMTP id JAA15402 for ; Fri, 7 Jan 2000 09:24:04 GMT Received: from mail-hotel.dk ( [195.41.82.145]) by mailhost.digiweb2.dk with SMTP (MailShield v1.5); Fri, 07 Jan 2000 09:24:04 -0000 Received: from 195.41.82.145 [195.41.82.145] by mail-hotel.dk (SMTPD32-5.05) id A3341D9A00FA; Fri, 07 Jan 2000 09:26:28 +0100 Received: from ipsemiconductors.com (ips11.com.dtu.dk [192.38.77.51]) by with SMTP (MailShield v1.5); Fri, 07 Jan 2000 09:26:27 +0100 Message-ID: <3875A262.5A33DAB6@ipsemiconductors.com> Date: Fri, 07 Jan 2000 09:22:58 +0100 From: Allan Nielsen X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-ppp@segue.merit.edu" Subject: PPP on ATM Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: mail-hotel.dk X-SMTP-MAIL-FROM: allan@ipsemiconductors.com X-SMTP-RCPT-TO: ietf-ppp@merit.edu X-SMTP-PEER-INFO: [195.41.82.145] Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Hi, For clarification, RFC 2364 says that you CAN use AAL5 framing when doing PPP on AAL5 (meaning no HDLC). Does that mean that HDLC sometime is used or... If you have any refrences on the subj. -- /Allan From owner-ietf-ppp-outgoing@merit.edu Fri Jan 7 05:12:13 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13643 for ; Fri, 7 Jan 2000 05:12:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id C05765DD97; Fri, 7 Jan 2000 05:11:33 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 518235DDB9; Fri, 7 Jan 2000 05:11:33 -0500 (EST) Received: from wacko.redbacknetworks.com (wacko.redbacknetworks.com [155.53.130.200]) by segue.merit.edu (Postfix) with ESMTP id 34A9A5DD97 for ; Fri, 7 Jan 2000 05:11:31 -0500 (EST) Received: from tradrat.redbacknetworks.com (tradrat.redbacknetworks.com [155.53.190.107]) by wacko.redbacknetworks.com (8.9.3/8.9.3) with ESMTP id CAA28635; Fri, 7 Jan 2000 02:11:30 -0800 (PST) Received: (from tor@localhost) by tradrat.redbacknetworks.com (8.8.8/8.6.9) id CAA11393; Fri, 7 Jan 2000 02:11:29 -0800 (PST) Date: Fri, 7 Jan 2000 02:11:29 -0800 From: Rene Tio To: Allan Nielsen Cc: "ietf-ppp@segue.merit.edu" Subject: Re: PPP on ATM Message-ID: <20000107021129.B11201@tradrat.redbacknetworks.com> References: <3875A262.5A33DAB6@ipsemiconductors.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us In-Reply-To: <3875A262.5A33DAB6@ipsemiconductors.com>; from Allan Nielsen on Fri, Jan 07, 2000 at 09:22:58AM +0100 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu On Fri, Jan 07, 2000 at 09:22:58AM +0100, Allan Nielsen wrote: > Hi, > > For clarification, RFC 2364 says that you CAN use AAL5 framing when > doing PPP on AAL5 (meaning no HDLC). Does that mean that HDLC sometime > is used or... It's not optional. In theory, there is no HDLC framing. In practice, most implementations allow you the option. > If you have any refrences on the subj. > -- > /Allan From owner-ietf-ppp-outgoing@merit.edu Fri Jan 7 06:39:43 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14166 for ; Fri, 7 Jan 2000 06:39:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id DA63D5DDB6; Fri, 7 Jan 2000 06:39:16 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8F5E95DDB9; Fri, 7 Jan 2000 06:39:16 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 844D15DDB6 for ; Fri, 7 Jan 2000 06:39:14 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14087; Fri, 7 Jan 2000 06:39:13 -0500 (EST) Message-Id: <200001071139.GAA14087@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-pppmux-00.txt Date: Fri, 07 Jan 2000 06:39:12 -0500 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 Multiplexed Frame Option Author(s) : R. Pazhyannur, I. Ali, G. Fox Filename : draft-ietf-pppext-pppmux-00.txt Pages : 7 Date : 06-Jan-00 This draft describes a method to reduce the PPP framing overhead used to transport small packets over slow links. The method, PPP Multiplexing, sends multiple PPP encapsulated packets in a single PPP frame. As a result, the PPP overhead per packet is reduced. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-pppmux-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-pppmux-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-pppmux-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: <20000106091507.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-pppmux-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-pppmux-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000106091507.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ppp-outgoing@merit.edu Fri Jan 7 07:06:59 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14691 for ; Fri, 7 Jan 2000 07:06:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9FB6E5DDC0; Fri, 7 Jan 2000 07:06:33 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2C50D5DDC1; Fri, 7 Jan 2000 07:06:33 -0500 (EST) Received: from ironbridgenetworks.com (helios.ironbridgenetworks.com [146.115.140.2]) by segue.merit.edu (Postfix) with ESMTP id 1C2265DDC0 for ; Fri, 7 Jan 2000 07:06:31 -0500 (EST) Received: (from news@localhost) by ironbridgenetworks.com (8.9.3/8.9.3) id HAA04953 for ietf-ppp@merit.edu; Fri, 7 Jan 2000 07:06:26 -0500 (EST) To: ietf-ppp@merit.edu From: James Carlson Newsgroups: lists.ietf.ppp Subject: Re: Doubts in PPP-MP+ Date: 07 Jan 2000 07:06:25 -0500 Organization: IronBridge Networks Lines: 25 Message-ID: <86bt6yt7b2.fsf@ironbridgenetworks.com> References: <01BF5900.780C3040.aruljp@future.futsoft.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 aruljp@future.futsoft.com ("aruljp@future.futsoft.com") writes: > * For what kind of remote configuration is MP+ used. It's intended for small remote access routers, preferably using ISDN, like the Lucent/Ascend Pipeline 50. (Note that it is an Informational RFC.) > * Is MP+ interaction between two PPP peers. Yes. All PPP protocols are used between two PPP peers. > * Should LCP negotiation be over before MP+ protocol starts to configure a remote station. Yes. All PPP protocols other than LCP wait for LCP to go to Opened state. The LCP option that enables MP+ is negotiated in parallel with all other LCP options. The MP+ frames, however, must wait for LCP to complete. This means that MP+'s configuration features require the "unconfigured" remote station to at least have physical link and LCP configuration already set properly. -- 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 Sun Jan 9 23:15:24 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14301 for ; Sun, 9 Jan 2000 23:15:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id 94C405DD8D; Sun, 9 Jan 2000 23:03:00 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1E6B65DDFC; Sun, 9 Jan 2000 23:03:00 -0500 (EST) Received: from intra0.extant.net (unknown [216.28.121.11]) by segue.merit.edu (Postfix) with ESMTP id A43D05DD8D for ; Sun, 9 Jan 2000 23:02:56 -0500 (EST) Received: from karl ([208.46.234.139]) by intra0.extant.net (Netscape Messaging Server 3.6) with ESMTP id AAA2F2A; Sun, 9 Jan 2000 21:03:08 -0700 Message-Id: <4.2.2.20000109230031.00d2b310@mail.extant.net> X-Sender: kfox@mail.extant.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Sun, 09 Jan 2000 23:02:51 -0500 To: Thomas Narten , Erik Nordmark From: "Karl Fox" Subject: PPP Bridging Control Protocol (BCP) 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 PPP Bridging Control Protocol (BCP), draft-ietf-pppext-bcp-02.txt, be recycled at Proposed Standard. Karl Fox Key fingerprint = 5B15 7260 D55E D680 0B93 4953 8A3B AB0E C05D 77A3 From owner-ietf-ppp-outgoing@merit.edu Thu Jan 13 06:41:05 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15309 for ; Thu, 13 Jan 2000 06:41:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id AEEF15DD94; Thu, 13 Jan 2000 06:40:26 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3B91E5DDA9; Thu, 13 Jan 2000 06:40:26 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 170565DD94 for ; Thu, 13 Jan 2000 06:40:24 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15293; Thu, 13 Jan 2000 06:40:23 -0500 (EST) Message-Id: <200001131140.GAA15293@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-06.txt Date: Thu, 13 Jan 2000 06:40:22 -0500 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. Hernandez Valencia, J. Manchester Filename : draft-ietf-pppext-sdl-06.txt Pages : 29 Date : 12-Jan-00 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-06.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-06.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-06.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: <20000112123652.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-sdl-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-sdl-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000112123652.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ppp-outgoing@merit.edu Thu Jan 13 11:42:31 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21138 for ; Thu, 13 Jan 2000 11:42:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 46DC45DDC7; Thu, 13 Jan 2000 11:41:47 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C6EC35DDDA; Thu, 13 Jan 2000 11:41:46 -0500 (EST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by segue.merit.edu (Postfix) with ESMTP id 83F8D5DDC7 for ; Thu, 13 Jan 2000 11:41:44 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.3/calcite) id JAA18304 for ietf-ppp@merit.edu env-from ; Thu, 13 Jan 2000 09:41:41 -0700 (MST) Date: Thu, 13 Jan 2000 09:41:41 -0700 (MST) From: Vernon Schryver Message-Id: <200001131641.JAA18304@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: mailing list archives Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu What has happened the the mailing list archive? My old notes as well as http://www.ietf.org/html.charters/pppext-charter.html point to ftp://merit.edu/pub/ietf-ppp-archive, but merit.edu does not answer port 21 or 80. ftp://ftp.merit.edu/oldmerit/pub/ietf-ppp-archive/ says they are in ftp://ftp.merit.edu/mail.archives/ietf-ppp-archive/, but that directory is empty and ftp://ftp.merit.edu/oldmerit/pub/ietf-ppp-archive/ contains logs through at least part of March 1999. I'm looking to see if there has been any discussion of draft-onoe-proxy-server-option-00.txt I think that the stupid, nonstandard, embrace-and-extend Microsoft DNS LCP option notwithstanding, putting HTTP proxy searching into IPCP is a very bad idea. It is my impression that the general feeling of the working group is that standard IP mechanisms should be used over all links, including PPP. If that is close to the consensus, the working group should publish an RFC to squelch future efforts like the Microsoft DNS LCP option and draft-onoe-proxy-server-option-00.txt Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp-outgoing@merit.edu Thu Jan 13 14:14:12 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24045 for ; Thu, 13 Jan 2000 14:14:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id E669A5DE20; Thu, 13 Jan 2000 14:13:17 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5326B5DE0D; Thu, 13 Jan 2000 14:13:17 -0500 (EST) Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by segue.merit.edu (Postfix) with ESMTP id 105705DDC0 for ; Thu, 13 Jan 2000 14:13:15 -0500 (EST) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA12308; Thu, 13 Jan 2000 14:12:52 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.37.82.31]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id OAA31156; Thu, 13 Jan 2000 14:12:06 -0500 Received: from rotala.raleigh.ibm.com (localhost [127.0.0.1]) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id OAA09064; Thu, 13 Jan 2000 14:10:53 -0500 Message-Id: <200001131910.OAA09064@rotala.raleigh.ibm.com> To: Vernon Schryver Cc: ietf-ppp@merit.edu Subject: Re: mailing list archives In-Reply-To: Message from Vernon Schryver of "Thu, 13 Jan 2000 09:41:41 MST." <200001131641.JAA18304@calcite.rhyolite.com> Date: Thu, 13 Jan 2000 14:10:53 -0500 From: Thomas Narten Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > What has happened the the mailing list archive? Merit moved a bunch of its mail stuff around a while back, and not everyone noticed. This is not the first WG to have discovered the merit archive has changed. Until its properly located, there is a backup at ftp://ftp.ietf.org/ietf-mail-archive/pppext Thomas From owner-ietf-ppp-outgoing@merit.edu Fri Jan 14 03:27:48 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13508 for ; Fri, 14 Jan 2000 03:27:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7908B5DE34; Fri, 14 Jan 2000 03:17:05 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 210E65DE06; Fri, 14 Jan 2000 03:17:01 -0500 (EST) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by segue.merit.edu (Postfix) with ESMTP id EEE3D5DDEA for ; Fri, 14 Jan 2000 03:16:53 -0500 (EST) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id JAA02393 for ; Fri, 14 Jan 2000 09:15:58 +0100 (MET) Received: from mchh201e.demchh201e.icn.siemens.de ([218.1.68.104]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id JAA13252 for ; Fri, 14 Jan 2000 09:16:55 +0100 (MET) Received: by MCHH201E with Internet Mail Service (5.5.2448.0) id ; Fri, 14 Jan 2000 09:16:45 +0100 Message-ID: From: Riegel Maximilian To: ietf-ppp@merit.edu Cc: Eichler Carsten Subject: AO/DI - How to authenticate? Date: Fri, 14 Jan 2000 09:16:31 +0100 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 I went through the AODI ID to get some information about authentication issues on the initial connection over X.25 in the D-channel as well as additional connections in the B-channels but didn't find much. Is a PPP authentication phase mandatory for the initial PPP connection in the D-channel as well as for every additional Multilink PPP channel over B-channels, or is it more common to use phone numbers for authentication? Any hints and opinions are appreciated. Kind regards Max ____________________________________________________________ Maximilian Riegel, Siemens ICN M CS 21, Ph: +49 89 722 49557 Internet Standards, email: maximilian.riegel@icn.siemens.de From owner-ietf-ppp-outgoing@merit.edu Fri Jan 14 09:33:05 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17617 for ; Fri, 14 Jan 2000 09:33:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id B75D25DE3B; Fri, 14 Jan 2000 09:29:32 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 32D7E5DE38; Fri, 14 Jan 2000 09:29:32 -0500 (EST) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by segue.merit.edu (Postfix) with ESMTP id 4334D5DE3B for ; Fri, 14 Jan 2000 09:29:30 -0500 (EST) Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id GAA24918; Fri, 14 Jan 2000 06:16:40 -0800 (PST) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 14 Jan 2000 14:22:43 UT Received: from porky (porky.ascend.com [192.207.23.83]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id GAA03127; Fri, 14 Jan 2000 06:22:42 -0800 (PST) Received: from ascend.com by ascend.com Message-Id: <4.2.2.20000114061833.00addba0@porky> X-Sender: mhold@porky X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 14 Jan 2000 06:23:23 -0800 To: Riegel Maximilian From: Matt Holdrege Subject: Re: AO/DI - How to authenticate? Cc: ietf-ppp@merit.edu, Eichler Carsten Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu At 09:16 AM 1/14/00 +0100, Riegel Maximilian wrote: >I went through the AODI ID to get some >information about authentication issues on the initial connection over X.25 >in the D-channel as well as additional connections in the B-channels but >didn't find much. > >Is a PPP authentication phase mandatory for the initial PPP connection in >the D-channel as well as for every additional Multilink PPP channel over >B-channels, or is it more common to use phone numbers for authentication? The choice of authentication is generally up to the entity accepting the incoming connection. No RFC mandates authentication. The PPP RFC's describe how to handle authentication if you wish to employ it. From owner-ietf-ppp-outgoing@merit.edu Mon Jan 17 15:46:09 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08600 for ; Mon, 17 Jan 2000 15:46:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id F1ECC5DE1F; Mon, 17 Jan 2000 15:44:52 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 804505DE26; Mon, 17 Jan 2000 15:44:52 -0500 (EST) Received: from intra0.extant.net (intra0.lvp.extant.net [216.28.121.11]) by segue.merit.edu (Postfix) with ESMTP id BEF625DE1F for ; Mon, 17 Jan 2000 15:44:50 -0500 (EST) Received: from karl ([216.28.121.202]) by intra0.extant.net (Netscape Messaging Server 3.6) with ESMTP id AAA9BC; Mon, 17 Jan 2000 13:45:05 -0700 Message-Id: <4.2.2.20000117154216.00c8d3f0@mail.extant.net> X-Sender: kfox@mail.extant.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 17 Jan 2000 15:44:48 -0500 To: ietf-ppp@merit.edu From: "Karl Fox" Subject: PPPEXT not meeting in Adelaide 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 Based on our new charter and the state of our documents, I see no need for PPPEXT to meet in Adelaide. Those of you who need to justify a trip to Australia should begin to make your case using other working groups. :-) Karl Fox Key fingerprint = 5B15 7260 D55E D680 0B93 4953 8A3B AB0E C05D 77A3 From owner-ietf-ppp-outgoing@merit.edu Wed Jan 19 11:53:42 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01945 for ; Wed, 19 Jan 2000 11:53:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 389BB5DDAC; Wed, 19 Jan 2000 11:52:55 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id BA8895DDAF; Wed, 19 Jan 2000 11:52:54 -0500 (EST) Received: from cobalt3-he.global.net.uk (cobalt3-he.global.net.uk [195.147.246.163]) by segue.merit.edu (Postfix) with ESMTP id 907B95DDAC for ; Wed, 19 Jan 2000 11:52:52 -0500 (EST) Received: from p45s09a10.client.global.net.uk ([195.147.121.70] helo=hardy.farsite.co.uk) by cobalt3-he.global.net.uk with esmtp (Exim 2.12 #1) id 12AyL8-0008F4-00 for ietf-ppp@merit.edu; Wed, 19 Jan 2000 08:52:15 -0800 Received: by HARDY with Internet Mail Service (5.5.2650.21) id ; Wed, 19 Jan 2000 16:25:28 -0000 Message-ID: From: Jonathan Goodchild To: ietf-ppp@merit.edu Subject: NT RAS CCP oddity Date: Wed, 19 Jan 2000 16:25:27 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu I've recently been doing some testing with a PPP terminal (which happens to be a mobile phone) connecting into Windows NT 4.0 RAS, and I've found something rather odd that I thought I'd share with you all... The connection proceeds as follows: LCP negotiation completes, then Authentication occurs, and IPCP negotiation takes place (so far, so good). During IPCP negotiation, RAS issues a CCP Configure Request, which the peer attempts to Protocol Reject. Now it so happens that the implementation of Protocol Rejects in the mobile phone is broken: the format of the LCP Protocol Reject packet it transmits is invalid (it doesn't contain the code for the rejected protocol, in this case 0x80fd), so RAS quite properly ignores it, and eventually retransmits the CCP Configure Request. In the meantime, IPCP negotiation completes, and the mobile attempts to establish a TCP connection. However, there is no response from RAS; the TCP packet is retransmitted a couple of times, and then the mobile gives up. (Before that happens, several more CCP Configure Requests are transmitted by RAS, followed by invalid Protocol Rejects from the mobile.) It appears that RAS is unable to deal with the incoming TCP packets until the CCP negotiation completes. If RAS is reconfigured to disable CCP (not a straightforward change - you need to hack the RAS registry entry) then everything works fine. Now my interpretation is that it should be possible to transfer IP data as soon as IPCP negotiation has completed, regardless of the state of CCP negotiation. Anyone have any views? And does anyone know if Microsoft have fixed this problem in Windows 2000? Jonathan Goodchild Farsite Communications Ltd email: jon.goodchild@farsite.co.uk web: http://www.farsite.co.uk/ From owner-ietf-ppp-outgoing@merit.edu Wed Jan 19 12:38:09 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02547 for ; Wed, 19 Jan 2000 12:38:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5BC3C5DDC0; Wed, 19 Jan 2000 12:32:42 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 883705DDED; Wed, 19 Jan 2000 12:31:16 -0500 (EST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by segue.merit.edu (Postfix) with ESMTP id B5F575DE20 for ; Wed, 19 Jan 2000 12:30:22 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.3/calcite) id KAA08842 for ietf-ppp@merit.edu env-from ; Wed, 19 Jan 2000 10:30:21 -0700 (MST) Date: Wed, 19 Jan 2000 10:30:21 -0700 (MST) From: Vernon Schryver Message-Id: <200001191730.KAA08842@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: NT RAS CCP oddity Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: Jonathan Goodchild > ... > It appears that RAS is unable to deal with the incoming TCP packets until > the CCP negotiation completes. If RAS is reconfigured to disable CCP (not a > straightforward change - you need to hack the RAS registry entry) then > everything works fine. > > Now my interpretation is that it should be possible to transfer IP data as > soon as IPCP negotiation has completed, regardless of the state of CCP > negotiation. You are right. It is a serious bug that betrays either unacceptable sloppiness in testing or a fundamental lack of understanding of how networks should work. > Anyone have any views? I've heard similar reports of failures to work for minutes at a time until CCP negotiations time out, possibly in other implementations. Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp-outgoing@merit.edu Wed Jan 19 14:22:44 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03956 for ; Wed, 19 Jan 2000 14:22:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 244EA5DE21; Wed, 19 Jan 2000 14:20:19 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9F7FB5DE2E; Wed, 19 Jan 2000 14:15:08 -0500 (EST) Received: from mx.seanet.com (dns2.seanet.com [199.181.164.2]) by segue.merit.edu (Postfix) with ESMTP id 437CA5DE34 for ; Wed, 19 Jan 2000 14:12:24 -0500 (EST) Received: from seanet.com (p1.dialup.seanet.com [207.12.130.97]) by mx.seanet.com (8.9.3/Seanet-8.7.3) with ESMTP id LAA10007; Wed, 19 Jan 2000 11:12:10 -0800 (PST) Message-ID: <38860C5E.67E94C36@seanet.com> Date: Wed, 19 Jan 2000 11:11:26 -0800 From: Glen Zorn Reply-To: gwz@acm.org X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Vernon Schryver Cc: ietf-ppp@merit.edu Subject: Re: NT RAS CCP oddity References: <200001191730.KAA08842@calcite.rhyolite.com> 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 Content-Transfer-Encoding: 7bit Vernon Schryver wrote: > > From: Jonathan Goodchild > > > ... > > It appears that RAS is unable to deal with the incoming TCP packets until > > the CCP negotiation completes. If RAS is reconfigured to disable CCP (not a > > straightforward change - you need to hack the RAS registry entry) then > > everything works fine. > > > > Now my interpretation is that it should be possible to transfer IP data as > > soon as IPCP negotiation has completed, regardless of the state of CCP > > negotiation. It depends. If encryption (MPPE) is configured on the NT side, then it makes no sense to transmit data until the CCP negotiation is complete, in fact it would be a serious security hole. This is because MPPE is negotiated as part of CCP. > > > You are right. It is a serious bug that betrays either unacceptable > sloppiness in testing or a fundamental lack of understanding of how > networks should work. > > > Anyone have any views? > > I've heard similar reports of failures to work for minutes at a time until > CCP negotiations time out, possibly in other implementations. > > Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp-outgoing@merit.edu Wed Jan 19 14:40:17 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04334 for ; Wed, 19 Jan 2000 14:40:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id E6AD85DDC4; Wed, 19 Jan 2000 14:21:17 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 554385DE94; Wed, 19 Jan 2000 14:21:17 -0500 (EST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by segue.merit.edu (Postfix) with ESMTP id 7CF005DDC4 for ; Wed, 19 Jan 2000 14:20:14 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.3/calcite) id MAA12577 for ietf-ppp@merit.edu env-from ; Wed, 19 Jan 2000 12:20:13 -0700 (MST) Date: Wed, 19 Jan 2000 12:20:13 -0700 (MST) From: Vernon Schryver Message-Id: <200001191920.MAA12577@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: NT RAS CCP oddity Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: Glen Zorn > ... > > > Now my interpretation is that it should be possible to transfer IP data as > > > soon as IPCP negotiation has completed, regardless of the state of CCP > > > negotiation. > > It depends. If encryption (MPPE) is configured on the NT side, then it makes no > sense to transmit data until the CCP negotiation is complete, in fact it would be > a serious security hole. This is because MPPE is negotiated as part of CCP. Ah, yes, I'd forgotten that design flaw in Microsoft's proprietary, non-standard, embrace-and-extend MPPE. Note that the characterization "serious security hole" is based on the unsupported and not generally accepted assumption that running with MPPE is noticably more secure than running without MPPE. Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp-outgoing@merit.edu Wed Jan 19 15:11:58 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04664 for ; Wed, 19 Jan 2000 15:11:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id 595DB5DDB9; Wed, 19 Jan 2000 15:11:29 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DD7DD5DDC2; Wed, 19 Jan 2000 15:11:28 -0500 (EST) Received: from blue.cosinecom.com (proxy4.cosinecom.com [208.248.148.132]) by segue.merit.edu (Postfix) with ESMTP id 6AA125DDB9 for ; Wed, 19 Jan 2000 15:11:24 -0500 (EST) Received: from cosinecom.com by blue.cosinecom.com (8.8.8+Sun/SMI-SVR4) id MAA29525; Wed, 19 Jan 2000 12:05:28 -0800 (PST) Message-ID: <38861907.7721E1A0@cosinecom.com> Date: Wed, 19 Jan 2000 12:05:28 -0800 From: Srinivasan Chakravarthy Organization: CoSine Communications Inc. X-Mailer: Mozilla 4.06 [en] (WinNT; U) MIME-Version: 1.0 To: Jonathan Goodchild Cc: ietf-ppp@merit.edu Subject: Re: NT RAS CCP oddity References: 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 Content-Transfer-Encoding: 7bit Win '98 uses CCP to negotiate MPPE as its option. In Win '98, only if you enable the data encryption, it uses CCP. Having enabled the data encryption, if the CCP negotiation fails (though the IPCP is UP), the windows station terminates the connection which i feel is absolutely correct. So, the windows station behaves correcly with the data encryption enabled. Well, i dont know about how to configure CCP in the Win NT RAS. But, even in this case, if the data encryption is enabled, what NT does is correct. Thanks & Regards, Srinivasan. Jonathan Goodchild wrote: > I've recently been doing some testing with a PPP terminal (which happens to > be a mobile phone) connecting into Windows NT 4.0 RAS, and I've found > something rather odd that I thought I'd share with you all... > > The connection proceeds as follows: LCP negotiation completes, then > Authentication occurs, and IPCP negotiation takes place (so far, so good). > During IPCP negotiation, RAS issues a CCP Configure Request, which the peer > attempts to Protocol Reject. > > Now it so happens that the implementation of Protocol Rejects in the mobile > phone is broken: the format of the LCP Protocol Reject packet it transmits > is invalid (it doesn't contain the code for the rejected protocol, in this > case 0x80fd), so RAS quite properly ignores it, and eventually retransmits > the CCP Configure Request. > > In the meantime, IPCP negotiation completes, and the mobile attempts to > establish a TCP connection. However, there is no response from RAS; the TCP > packet is retransmitted a couple of times, and then the mobile gives up. > (Before that happens, several more CCP Configure Requests are transmitted by > RAS, followed by invalid Protocol Rejects from the mobile.) > > It appears that RAS is unable to deal with the incoming TCP packets until > the CCP negotiation completes. If RAS is reconfigured to disable CCP (not a > straightforward change - you need to hack the RAS registry entry) then > everything works fine. > > Now my interpretation is that it should be possible to transfer IP data as > soon as IPCP negotiation has completed, regardless of the state of CCP > negotiation. > > Anyone have any views? > And does anyone know if Microsoft have fixed this problem in Windows 2000? > > Jonathan Goodchild > Farsite Communications Ltd > email: jon.goodchild@farsite.co.uk > web: http://www.farsite.co.uk/ From owner-ietf-ppp-outgoing@merit.edu Wed Jan 19 15:24:06 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04762 for ; Wed, 19 Jan 2000 15:24:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id 96EC45DDC8; Wed, 19 Jan 2000 15:15:35 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 222F35DDBE; Wed, 19 Jan 2000 15:15:35 -0500 (EST) Received: from mx.seanet.com (dns2.seanet.com [199.181.164.2]) by segue.merit.edu (Postfix) with ESMTP id 825D05DDC9 for ; Wed, 19 Jan 2000 15:15:29 -0500 (EST) Received: from seanet.com (gg18.dialup.seanet.com [207.12.135.178]) by mx.seanet.com (8.9.3/Seanet-8.7.3) with ESMTP id MAA19202; Wed, 19 Jan 2000 12:15:26 -0800 (PST) Message-ID: <38861B30.82F35E7@seanet.com> Date: Wed, 19 Jan 2000 12:14:40 -0800 From: Glen Zorn Reply-To: gwz@acm.org X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: vjs@calcite.rhyolite.com Cc: ietf-ppp@merit.edu Subject: Re: NT RAS CCP oddity 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 Content-Transfer-Encoding: 7bit >> From: Glen Zorn >> ... >> > > Now my interpretation is that it should be possible to transfer IP data as > >> > soon as IPCP negotiation has completed, regardless of the state of CCP > > >> negotiation. >> > >It depends. If encryption (MPPE) is configured on the NT side, then it makes no > >sense to transmit data until the CCP negotiation is complete, in fact it would be > >a serious security hole. This is because MPPE is negotiated as part of CCP. >Ah, yes, I'd forgotten that design flaw in Microsoft's proprietary, >non-standard, embrace-and-extend MPPE. Be that as it may, the IPSec folks seem to think that negotiating crypto and compression at the same time is not a bad idea... >Note that the characterization "serious security hole" is based on the >unsupported and not generally accepted assumption that running with MPPE >is noticably more secure than running without MPPE. Sure, encryption, cleartext, it's all the same, right? Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp-outgoing@merit.edu Wed Jan 19 16:41:15 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05708 for ; Wed, 19 Jan 2000 16:41:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2E2F65DE78; Wed, 19 Jan 2000 16:29:42 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 44BDF5DDE3; Wed, 19 Jan 2000 16:24:20 -0500 (EST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by segue.merit.edu (Postfix) with ESMTP id 0A3205DDF0 for ; Wed, 19 Jan 2000 16:22:18 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.3/calcite) id OAA14755 for ietf-ppp@merit.edu env-from ; Wed, 19 Jan 2000 14:22:17 -0700 (MST) Date: Wed, 19 Jan 2000 14:22:17 -0700 (MST) From: Vernon Schryver Message-Id: <200001192122.OAA14755@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: NT RAS CCP oddity Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: Glen Zorn > ... > >Ah, yes, I'd forgotten that design flaw in Microsoft's proprietary, > >non-standard, embrace-and-extend MPPE. > > Be that as it may, the IPSec folks seem to think that negotiating crypto > and compression at the same time is not a bad idea... Nonsense! It is often good to compress before encrypting, and if you're encrypting, you don't want to pass any unencrypted data. However, the right way to have designed a PPP encryption scheme with obiligatory compression would be to call it encryption and Configure-Reject or Protocol-Reject CCP, and certainly not send any CCP Configure-Requests. It would be a minor, irrelevant detail for an encryption scheme to put ciphertext of fewer bits on the wire than the corresponding corresponding cleartext. It is simply and obviously wrong to intertwine CCP and ECP as Microsoft has done with MPPE. > >Note that the characterization "serious security hole" is based on the > >unsupported and not generally accepted assumption that running with > MPPE > >is noticably more secure than running without MPPE. > > Sure, encryption, cleartext, it's all the same, right? In many cases, that is right. Outside of what I recently saw described in either the Wall Street Journal or ABC News as the "unusually insular" culture at Redmond is the common observation that many home grown encryption schemes are not usefully different from cleartext. In other words, has MPPE been examined by independent experts, and if so, did they find it better than the other Microsoft PPP encryption efforts? It should also be noted that link layer encryption by its nature adds little or no real security. People who understand the issue and really need encryption do it at a higher layer, such as with IPSec, so that none of their cleartext is routers controlled by potentially interested strangers. Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp-outgoing@merit.edu Wed Jan 19 16:43:25 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05735 for ; Wed, 19 Jan 2000 16:43:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id A4BCB5DE73; Wed, 19 Jan 2000 16:34:37 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 164F95DE8A; Wed, 19 Jan 2000 16:34:25 -0500 (EST) Received: from ironbridgenetworks.com (helios.ironbridgenetworks.com [146.115.140.2]) by segue.merit.edu (Postfix) with ESMTP id CA8E95DE73 for ; Wed, 19 Jan 2000 16:32:48 -0500 (EST) Received: (from news@localhost) by ironbridgenetworks.com (8.9.3/8.9.3) id QAA07776 for ietf-ppp@merit.edu; Wed, 19 Jan 2000 16:32:47 -0500 (EST) To: ietf-ppp@merit.edu From: James Carlson Newsgroups: lists.ietf.ppp Subject: Re: NT RAS CCP oddity Date: 19 Jan 2000 16:32:47 -0500 Organization: IronBridge Networks Lines: 26 Message-ID: <86hfg9kark.fsf@ironbridgenetworks.com> References: <38861B30.82F35E7@seanet.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 gwz@seanet.com (Glen Zorn) writes: > Be that as it may, the IPSec folks seem to think that negotiating crypto > and compression at the same time is not a bad idea... What they think about the combination of encryption and compression is quite irrelevant. In PPP, encryption and compression use separate protocols *unless* you're talking to machines made by one particular vendor. > >Note that the characterization "serious security hole" is based on the > >unsupported and not generally accepted assumption that running with > MPPE > >is noticably more secure than running without MPPE. > > Sure, encryption, cleartext, it's all the same, right? A reasonable administrator who also thinks that encrypting just on a local link rather than end-to-end (as with IPSec) is somehow useful would likely *CONFIGURE* the use of both CCP and ECP. They needn't be architecturally forced together in order to operate together. -- 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 Thu Jan 20 12:21:37 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08104 for ; Thu, 20 Jan 2000 12:21:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3EF855DDBB; Thu, 20 Jan 2000 12:20:53 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id AE2745DDD0; Thu, 20 Jan 2000 12:20:52 -0500 (EST) Received: from cobalt1-he.global.net.uk (cobalt1-he.global.net.uk [195.147.246.161]) by segue.merit.edu (Postfix) with ESMTP id 8A41B5DDBB for ; Thu, 20 Jan 2000 12:20:50 -0500 (EST) Received: from p98s07a01.client.global.net.uk ([195.147.135.153] helo=hardy.farsite.co.uk) by cobalt1-he.global.net.uk with esmtp (Exim 2.12 #1) id 12BLFW-000402-00 for ietf-ppp@merit.edu; Thu, 20 Jan 2000 09:19:58 -0800 Received: by HARDY with Internet Mail Service (5.5.2650.21) id ; Thu, 20 Jan 2000 17:20:29 -0000 Message-ID: From: Jonathan Goodchild To: ietf-ppp@merit.edu Subject: RE: Re: NT RAS CCP oddity Date: Thu, 20 Jan 2000 17:20:28 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu From Glen Zorn: > If encryption (MPPE) is configured on the NT side, then it makes no > sense to transmit data until the CCP negotiation is complete, in fact it would be > a serious security hole. Hmmm, I'm not sure that I agree with this. It seems to me that there are 3 possibilities with encryption: 1) You don't do any encryption; 2) You don't need to do encryption, but you're quite happy to do so if the peer wants to; 3) You insist upon encryption. Why should the state of ECP (or CCP in the case of MPPE) negotiation affect what you do with received data packets in any of these cases? Obviously in case #3 you never send any clear text data and always discard received clear text data. Equally obviously, in case #1 you should be able to transfer data as soon as the NCP negotiation has completed. That leaves case #2 (and frankly I don't see how it's any different from case #1 from a security viewpoint): seeing as you're prepared to accept clear text data eventually, I don't see how a security hole is introduced by accepting the data packets before ECP negotiation has completed. Jonathan Goodchild From owner-ietf-ppp-outgoing@merit.edu Mon Jan 31 19:07:10 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18713 for ; Mon, 31 Jan 2000 19:07:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9022C5DD9B; Mon, 31 Jan 2000 19:06:20 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 641BF5DD95; Mon, 31 Jan 2000 19:06:20 -0500 (EST) Received: from kiki.netreach.net (kiki.netreach.net [207.29.194.29]) by segue.merit.edu (Postfix) with SMTP id EBE595DD9B for ; Mon, 31 Jan 2000 19:06:15 -0500 (EST) Received: (qmail 617 invoked by uid 50014); 1 Feb 2000 00:06:45 -0000 Message-ID: <20000201000645.616.qmail@kiki.netreach.net> From: tisc-pc@corecom.com To: ietf-ppp@merit.edu Subject: TISC April 24-28 2000 San Jose Date: Tue, 01 Feb 2000 00:06:45 GMT 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 Fourth Internet Security Conference will be held April 24-28, 2000 in San Jose, CA, at the Fairmont Hotel. TISC is an educational forum for security professionals and practitioners. The TISC Security Symposium is an opportunity for individuals to share their expertise and practical experience with others involved in the design, implementation and deployment of networked security systems. To register, or to learn more about TISC workshops and symposium sessions, visit http://tisc.corecom.com We invite you to subscribe to the TISC bi-weekly newsletter, Insight, by visiting http://tisc.corecom.com/insight.html We hope to see you in San Jose! Regards, The TISC Advisory Board