From owner-ietf-ppp@merit.edu Tue Sep 16 16:50:40 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id AB82E5DE6F; Tue, 16 Sep 2003 16:50:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EC55F9139D; Tue, 16 Sep 2003 16:16:24 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 35AF7912F1; Tue, 16 Sep 2003 16:16:22 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CB7B99139D for ; Tue, 16 Sep 2003 16:16:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 168295DDAA; Tue, 16 Sep 2003 16:16:11 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id B6EB35DD90 for ; Tue, 16 Sep 2003 16:16:10 -0400 (EDT) Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.9/8.12.9) with ESMTP id h8GK9bAP024004; Tue, 16 Sep 2003 15:09:37 -0500 (CDT) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Tue, 16 Sep 2003 15:09:35 -0500 Message-ID: <7B2A7784F4B7F0409947481F3F3FEF830A082B9A@eammlex037.lmc.ericsson.se> From: "Kevin Purser (QA/EMC)" To: "'karlfox@columbus.rr.com'" , "'internet-drafts@ietf.org'" , "'ietf-ppp@merit.edu'" Subject: Date: Tue, 16 Sep 2003 15:09:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C37C8E.73B2B91E" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C37C8E.73B2B91E Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37C8E.73B2B91E" ------_=_NextPart_001_01C37C8E.73B2B91E Content-Type: text/plain; charset="iso-8859-1" Hello All, I would like to submit the following I-D for consideration by the PPPEXT WG. Please feel free to send comments/questions/flames directly to me. Kev Abstract: If the Internet is accessed via cellular networks, the Point-to-Point protocol (PPP) is most commonly used for configuration of the circuit-switched or packet-switched link. Thus, this PPP configuration time comes in addition to the usual call-setup time for the cellular connection. In many cases this will result in a fairly long "wait time" as perceived by end users before actual application data can be transmitted. This proposal describes a solution in which the PPP configuration time can be significantly reduced (on the order of seconds) in cases where both peer protocol entities can be modified according to this proposal, which involves modifying standard PPP. In cases where one PPP peer is modified and the other utilizes only standard PPP, the modified peer can fallback to standard PPP operation. This fallback mechanism will not noticeably affect the PPP setup time, and serves to ensure interoperability. <> ------_=_NextPart_001_01C37C8E.73B2B91E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello All,

I would like to submit the following = I-D for consideration by the PPPEXT WG.  Please feel free to send = comments/questions/flames directly to me.

Kev


Abstract:

   If the Internet is = accessed via cellular networks, the Point-to-Point
   protocol (PPP) is most = commonly used for configuration of the
   circuit-switched or = packet-switched link.  Thus, this PPP
   configuration time comes = in addition to the usual call-setup time for
   the cellular = connection.  In many cases this will result in a fairly
   long "wait = time" as perceived by end users before actual application
   data can be = transmitted.

   This proposal describes a = solution in which the PPP configuration
   time can be = significantly reduced (on the order of seconds) in cases
   where both peer protocol = entities can be modified according to this
   proposal, which involves = modifying standard PPP.  In cases where one
   PPP peer is modified and = the other utilizes only standard PPP, the
   modified peer can = fallback to standard PPP operation.  This fallback
   mechanism will not = noticeably affect the PPP setup time, and serves
   to ensure = interoperability.

= <<draft-purser-pppext-pppcn-00.txt>>

------_=_NextPart_001_01C37C8E.73B2B91E-- ------_=_NextPart_000_01C37C8E.73B2B91E Content-Type: text/plain; name="draft-purser-pppext-pppcn-00.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-purser-pppext-pppcn-00.txt" Internet Draft Kevin Purser, = editor Document: draft-purser-pppext-pppcn-00.txt = Ericsson Expires: March 2004 September = 2003 PPP Adaptation for Cellular Networks Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six = months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract If the Internet is accessed via cellular networks, the = Point-to-Point protocol (PPP) is most commonly used for configuration of the circuit-switched or packet-switched link. Thus, this PPP configuration time comes in addition to the usual call-setup time = for the cellular connection. In many cases this will result in a fairly long "wait time" as perceived by end users before actual application data can be transmitted. This proposal describes a solution in which the PPP configuration time can be significantly reduced (on the order of seconds) in cases where both peer protocol entities can be modified according to this proposal, which involves modifying standard PPP. In cases where one PPP peer is modified and the other utilizes only standard PPP, the modified peer can fallback to standard PPP operation. This fallback mechanism will not noticeably affect the PPP setup time, and serves to ensure interoperability. Purser expires March 2004 [Page = 1] Internet Draft PPP-CN September = 2003 1. Introduction In cellular networks, direct access to the internet is provided to mobile users via the PDSN in CDMA2000 or the MSC/GSN in GSM/GPRS. The Point-to-Point Protocol (PPP) is first used to configure the traffic channel between the terminal equipment (TE) and the cellular network node and subsequently to transport network layer protocol data units (PDU) over the traffic channel. Since PPP was initially designed to run over the wire, it normally requires numerous exchanges of signaling messages (figure 1) between the two peers to configure their connection, namely LCP, IPCP, etc. +------+ +-------+ | TE | |3G Node| +------+ +-------+ | LCP-Req | |------------------------------>| | LCP-Req-Ack | |<------------------------------| | PAP/CHAP-Req | |------------------------------>| | PAP/CHAP-Req-Ack | |<------------------------------| | IPCP-Req | |------------------------------>| | IPCP-Req-Ack | |<------------------------------| | | Figure 1: Common message exchanges involved in PPP negotiation For the sake of simplicity, the LCP- and IPCP- Requests initiated concurrently by the 3G node are not shown in figure 1. In addition, CHAP also requires a 3-way handshake as opposed to the 2-way handshake for PAP initiated by the TE as indicated. However, this does not change the overall PPP configuration time, since the 3G = node can send the CHAP challenge immediately following the LCP-Req-Ack. Note that standard PPP [PPP] specifies that neither the PAP/CHAP authentication phase, nor the IPCP configuration phase, nor the exchange of IP packets can begin prior to the completion of the preceding phase. This results in a minimum duration of the PPP negotiation of 2 or 3 round trip times (RTT), depending on whether the optional authentication phase is employed. With PPP in use traditionally over wired links, these multiple round trips aren't of major consequence. Cellular links on the other hand are characterized by high latency and a much higher rate of packet loss. Thus, the negotiation shown in figure 1 when applied to Purser expires March 2004 [Page = 3] Internet Draft PPP-CN September = 2003 cellular networks can typically comprise 7 RTTs or more, due to retransmissions after packet loss, additional PPP negotiation parameters, etc. This number of round trips, considering that the average RTT in GSM today is approximately 750ms, can easily result = in PPP negotiation setup times of several seconds. 1.1. Acronyms This section lists acronyms commonly used throughout this document. CHAP - Challenge-Handshake Authentication Protocol GSN - GPRS Support Node IPCP - Internet Control Protocol LCP - Link Control Protocol MRU - Maximum Receive Unit MSC - Mobile Switching Center PAP - Password Authentication Protocol PDSN - Packet Data Serving Node PDU - Protocol Data Unit PPP - Point-to-Point Protocol RTT - Round Trip Time TE - Terminal Equipment 1.2. Definitions This section lists terms commonly used throughout this document. Standard-PPP-Peer: A PPP peer which only implements PPP as specified in [PPP]. PPPCN-Peer: A PPP Peer which implements a modified PPP state machine which allows it to conform to standard PPP as specified in [PPP] = when required, but also to conform to the enhanced PPP as defined in this document. Masked PPP packets: LCP, PAP, CHAP, IPCP or IP packets with syntax and semantics as defined in [PPP], but carrying an "incorrect" value in the PPP protocol field. Protocol fields values of these packets MUST NOT be reserved (see [Num]), and MUST be uniquely chosen conforming to [PPP] with respect to how valid protocol fields values are defined. For example, protocol field values chosen from the 0x8001 to 0x801F (hex) range would be acceptable candidates. PPPCN- Peers will accept and process these packets, but as put forth in [PPP], Standard-PPP-Peers MUST silently discard these packets. 2. Protocol Description The general premise of this protocol is that when 2 PPPCN-Peers = begin Purser expires March 2004 [Page = 4] Internet Draft PPP-CN September = 2003 negotiating PPP setup, the strict separation of LCP, authentication (PAP or CHAP) and IPCP phases as well as the exchange of IP packets will no longer be required. Instead, both peers will assume a pre- defined set of LCP and IPCP options as defined in figure 2, and initiate the aforementioned phases concurrently as follows. = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D protocol | option | default value ---------+----------------------------+--------------- LCP | MRU | 576 ---------+----------------------------+--------------- LCP | Authentication Protocol | not required ---------+----------------------------+--------------- LCP | Quality Protocol | not required ---------+----------------------------+--------------- LCP | Magic Number | not required ---------+----------------------------+--------------- LCP | Protocol Field Compression | required ---------+----------------------------+--------------- LCP | Address/Control Field Comp | required ---------+----------------------------+--------------- IPCP | IP-Addresses | not required ---------+----------------------------+--------------- IPCP | IP-Compression Protocol | not required ---------+----------------------------+--------------- IPCP | IP-Address | required ---------+----------------------------+--------------- IPCP | TCP/IP Header Compression | required = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Figure 2: Default values to be used for LCP and IPCP phases of = PPP negotiation A PPPCN-Peer MUST begin negotiations by sending an initial set of masked PPP packets, where each packet is sent immediately following the preceding packet, without waiting for an acknowledgement of any kind. This MUST be immediately followed by a standard LCP packet. The standard LCP packet MUST carry all options of the pre-defined = set that differ from the default options specified in [PPP]. A = receiving Standard-PPP-Peer MUST silently discard the masked PPP packets as specified in [PPP], and begin by processing the standard LCP packet. On the other hand, a receiving PPPCN-Peer MUST silently discard the standard LCP packet but instead begin by processing the masked PPP packets. Optionally, a PPPCN-Peer may change pre-defined LCP or IPCP settings (e.g. the MRU to a value between 296 and 1500) by sending an appropriate masked LCP or IPCP packet as a part of the = aforementioned Purser expires March 2004 [Page = 5] Internet Draft PPP-CN September = 2003 initial set of masked PPP packets. This MAY or MAY NOT be accepted by the receiving PPPCN-Peer which MUST respond with a masked ACK or NACK, respectively. A receiving PPPCN-Peer will be able to determine by inspecting the first packets whether it is communicating with a Standard- or PPPCN- Peer. Thus, in order to guarantee interoperability, a PPPCN-Peer which only receives a standard LCP packet MUST fallback to operate = as a Standard-PPP-Peer. Likewise, a Standard-PPP-Peer which receives any masked PPP packets will silently discard them and acknowledge = the starting standard LCP packet, thus indicating to the originating = PPP- Peer to fallback into Standard-PPP-Peer mode. PPPCN-Peers MUST support both PAP and CHAP, but the PPPCN-Peer in = the 3G cellular node dictates the authentication protocol to be used. = If authentication is required, any masked IP packets received during = the PPP negotiation by a PPPCN-Peer MUST be buffered and MUST NOT be forwarded to the receiving IP peer until the necessary PPP negotiation phases have succeeded. In the case of any unsuccessful phase of the PPP negotiation between two PPPCN-Peers (e.g. the authentication fails but an IP address has already been assigned, and IP packets received), the link MUST be terminated, and any state in the 3G cellular node (any assigned IP addresses, received IP packets, etc) regarding the originating = PPPCN- Peer MUST be discarded, and any allocated IP addressed MUST be de- allocated. 3. Use Cases This section will illustrate a few example scenarios. The following cases assume that a PPPCN-Peer in the TE communicates with a PPPCN- Peer in the 3G Node, and accordingly, all packets shown are masked PPP packets unless otherwise noted. For the sack of brevity, we = have omitted optional masked LCP/IPCP packets for changing pre-defined settings. Also, packets sent immediately after one another are = drawn with the same arrow, to indicate concurrency. Purser expires March 2004 [Page = 6] Internet Draft PPP-CN September = 2003 Case 1: TE does not initiate authentication and the 3G node does not require authentication. +------+ +-------+ | TE | |3G Node| +------+ +-------+ | LCP-Req + | | IPCP-Req + | | Standard LCP-Req | |------------------------------>| | LCP-Req-Ack + | | IPCP (IP address) | |<------------------------------| | First IP packet | |------------------------------>| | | Case 2: TE does not initiate authentication, but the 3G node = requires the use of PAP authentication +------+ +-------+ | TE | |3G Node| +------+ +-------+ | LCP-Req + | | IPCP-Req + | | Standard LCP-Req | |------------------------------>| | LCP-Req-Ack + | | PAP-Required + | | IPCP (IP address) | |<------------------------------| | PAP-UserID/Password + | | First IP packet | |------------------------------>| | | Purser expires March 2004 [Page = 7] Internet Draft PPP-CN September = 2003 Case 3: TE initiates using PAP authentication, but the 3G node requires the use of CHAP authentication +------+ +-------+ | TE | |3G Node| +------+ +-------+ | LCP-Req + | | PAP-UserID/Password + | | IPCP-Req + | | Standard LCP-Req | |------------------------------>| | LCP-Req-Ack + | | PAP-Nack + | | CHAP-Challenge + | | IPCP (IP address) | |<------------------------------| | CHAP-UserID/Password + | | First IP packet | |------------------------------>| | | 4. Security Considerations Security considerations are not discussed in this memo. However, since the aim of this protocol is merely to reduce PPP negotiation time by allowing the distinct negotiation phases to happen concur- rently instead of in a serial fashion, there should not be any addi- tional security risks introduced which are not already present in [PPP]. 5. Acknowledgements The author wishes to acknowledge Reiner Ludwig and Martin Gerdes, = the original authors of this solution as presented in [QPPP]. 6. Author's Addresses Kevin Purser 8400 Decarie Blvd. Town of Mount Royal, Quebec H4P 2N2 CANADA Phone: +1-514-345-7900 Email: kevin.purser@ericsson.ca 7. References Purser expires March 2004 [Page = 8] Internet Draft PPP-CN September = 2003 [PPP] W. Simpson (editor), "The Point-to-Point Protocol (PPP)", RFC1661, July 1994 [IPCP] G. McGregor, "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992 [PPPAuth] B. Lloyd, W. Simpson, "PPP Authentication Protocols", RFC 1334, October 1992 [Num] J. Reynolds, J. Postel, "ASSIGNED NUMBERS", RFC 1340, = July 1992 [QPPP] R. Ludwig, B. Rathonyi, "Link Layer Enhancements for TCP/IP over GSM", In Proceedings of IEEE INFOCOM, March 1999 Purser expires March 2004 [Page = 9] Internet Draft PPP-CN September = 2003 =1B[1mTable of Contents=1B[0m 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . = 3 1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . = 4 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . = 4 2. Protocol Description . . . . . . . . . . . . . . . . . . . . . . = 4 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . = 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . . = 8 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . = 8 6. Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . = 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . . = 8 Purser expires March 2004 [Page = 1] ------_=_NextPart_000_01C37C8E.73B2B91E-- From owner-ietf-ppp@merit.edu Tue Sep 16 19:35:37 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 467AD5E091; Tue, 16 Sep 2003 19:35:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id ED87691288; Tue, 16 Sep 2003 19:35:25 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B6FB59128B; Tue, 16 Sep 2003 19:35:25 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B535C91288 for ; Tue, 16 Sep 2003 19:35:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8E64D5E091; Tue, 16 Sep 2003 19:35:24 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by segue.merit.edu (Postfix) with ESMTP id 83D635E07D for ; Tue, 16 Sep 2003 19:35:23 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.12.10.Beta4/8.12.10.Beta4) id h8GNZEP2018905 env-from ; Tue, 16 Sep 2003 17:35:14 -0600 (MDT) Date: Tue, 16 Sep 2003 17:35:14 -0600 (MDT) From: Vernon Schryver Message-Id: <200309162335.h8GNZEP2018905@calcite.rhyolite.com> To: ietf-ppp@merit.edu, kevin.p.purser@ericsson.com Subject: Re: pppcn References: <7B2A7784F4B7F0409947481F3F3FEF830A082B9A@eammlex037.lmc.ericsson.se> Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: "Kevin Purser (QA/EMC)" > To: "'karlfox@columbus.rr.com'" , > "'internet-drafts@ietf.org'" , > "'ietf-ppp@merit.edu'" > I would like to submit the following I-D for consideration by > the PPPEXT WG. Please feel free to send comments/questions/flames > directly to me. If our public attention was justifiably requisitioned by the original message, then our responses should be public. What is about about Scandanavian telephone companies that makes this issue so compelling that the same non-problem and similar non-solutions are raised every few years? It makes no sense in most of the rest of the world. Hasn't it been Ericsson that has repeatedly proposed modifying PPP to dealy the supposed multi-second connection setup times of PPP? The problem makes no sense in most of the rest of the world because no PPP connection that is useful in this century has round trip times that are so long that 3 extra round trips can total "on the order of seconds." Any PPP connection where a few extra RTTs are objectionable is useless to any likely modern application, because modern applications are so profligate with both bandwidth and round trips. Exactly what modern application is usable on a link with effective RTTs of 0.75 seconds? Exactly what application can tolerate packet loss rates so hight that 3 RTTs turn into 7 on average? This solution is not quite as bad as previous Scandanavian telco efforts that proposed to give up entirely on authentication, However, this one still misses the obvious solution to the non-problem that has been published here and elsewhere (e.g. James Carlson's book) more than once. This proposal may be intended to be that obvious solution, but it fails by defining a new "masked packet" protocol. The obvious solution does not require any changes to the on-the-wire PPP protocol. It is for both peers to anticipate each others' sequence and magjic numbers and options, and to send a single burst of LCP, authentication, and IPCP packets. This solution requires no changes in PPP state machines except for what might be called "pre-loading. Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp@merit.edu Tue Sep 16 22:46:44 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 5621F5DD8E; Tue, 16 Sep 2003 22:46:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CE7A391233; Tue, 16 Sep 2003 22:46:03 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A26B59124D; Tue, 16 Sep 2003 22:46:03 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0F3CD91233 for ; Tue, 16 Sep 2003 22:46:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D80185DDB1; Tue, 16 Sep 2003 22:46:01 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by segue.merit.edu (Postfix) with ESMTP id 3B1B75DD90 for ; Tue, 16 Sep 2003 22:45:58 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.12.10.Beta4/8.12.10.Beta4) id h8H2jh1H020997 for ietf-ppp@merit.edu env-from ; Tue, 16 Sep 2003 20:45:43 -0600 (MDT) Date: Tue, 16 Sep 2003 20:45:43 -0600 (MDT) From: Vernon Schryver Message-Id: <200309170245.h8H2jh1H020997@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: draft-purser-pppext-pppcn-00.txt References: <200309170110.SAA02859@grigri.eng.ascend.com> Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: Ignacio Goyret > ... > PS: In the future, please refrain from sending HTML messages. They are > almost always unreadable, often due to specific sender's personal choices > like colors and font sizes. Use text messages instead, which have always > been (and always will be) readable. That's a good point. How many extra RTTs and bandwidth were spent on sending that introductory message as both text/plain and as quoted-printable--text/html and then attaching the proposal as quoted-printable? It emphasizes my point about the oddity of worrying about 4 or 6 extra PPP packets at the start. Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp@merit.edu Tue Sep 16 23:43:10 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 2E8665DFE3; Tue, 16 Sep 2003 23:43:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E3FF0912F2; Tue, 16 Sep 2003 23:42:57 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A81B4912F1; Tue, 16 Sep 2003 23:42:56 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 669A9912EC for ; Tue, 16 Sep 2003 23:42:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 421995DFEE; Tue, 16 Sep 2003 23:42:55 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from ohsmtp01.ogw.rr.com (ohsmtp01.ogw.rr.com [65.24.7.36]) by segue.merit.edu (Postfix) with ESMTP id A0A755DFEB for ; Tue, 16 Sep 2003 23:42:54 -0400 (EDT) Received: from columbus.rr.com (dhcp93124156.columbus.rr.com [24.93.124.156]) by ohsmtp01.ogw.rr.com (8.12.5/8.12.2) with ESMTP id h8H3goGX005202; Tue, 16 Sep 2003 23:42:50 -0400 (EDT) Date: Tue, 16 Sep 2003 23:42:54 -0400 Subject: Re: pppcn Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: ietf-ppp@merit.edu, kevin.p.purser@ericsson.com To: Vernon Schryver From: Karl Fox In-Reply-To: <200309162335.h8GNZEP2018905@calcite.rhyolite.com> Message-Id: <04FAD3D0-E8C1-11D7-96F6-000A958718F0@columbus.rr.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu On Tuesday, September 16, 2003, at 07:35 PM, Vernon Schryver wrote: > This solution is not quite as bad as previous Scandanavian telco > efforts that proposed to give up entirely on authentication, However, > this one still misses the obvious solution to the non-problem that > has been published here and elsewhere (e.g. James Carlson's book) more > than once. From "PPP Design and Debugging," by James Carlson, pages 68-69: "An example in Chapter 7 shows that PPP can fully negotiate even in complex cases within a few round-trip times and that this negotiation is easily faster than switched-circuit setup times, even on ISDN. Some users, however, view PPP negotiation as too slow for some applications, perhaps based on their experiences with bad PPP implementations. These designers have many times proposed complex mechanisms to maintain state across sessions in order to bypass normal PPP negotiation. These proposals are usually termed "fast reconnect" or "short hold." These proposed protocols, such as draft-ietf-pppext-scm-00.txt, greatly weaken security and are completely unnecessary. As the example in Chapter 7 shows, PPP is already faster than the inherent delays in circuit set-up, but PPP can be made faster still, if necessary. A technique proposed by Vernon Schryver reduces this delay to a single-round trip time, at the expense of a minor but generally compatible violation of RFC 1661 and a possible time-out delay with some peers. It does not require any new PPP options or protocols." Buy the book. Read Chapter 7. Build a blindingly fast PPP implementation that does all you want and more, without changing the protocol at all. Other people have done it this way; you can too. Karl Fox PPPEXT Working Group Chair P.S. Thank you, James Carlson, for such a powerful tool. From owner-ietf-ppp@merit.edu Wed Sep 17 08:40:09 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 3FB195DDBD; Wed, 17 Sep 2003 08:40:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B15CF91296; Wed, 17 Sep 2003 08:39:55 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 870749131E; Wed, 17 Sep 2003 08:39:55 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 70EE991296 for ; Wed, 17 Sep 2003 08:39:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 24DFD5DDC7; Wed, 17 Sep 2003 08:39:54 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by segue.merit.edu (Postfix) with ESMTP id 9CB105DDBA for ; Wed, 17 Sep 2003 08:39:53 -0400 (EDT) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h8HCddoj011484; Wed, 17 Sep 2003 05:39:39 -0700 (PDT) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h8HCdctK025016; Wed, 17 Sep 2003 08:39:38 -0400 (EDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.12.9+Sun/8.12.9) with ESMTP id h8HCdcQS042609; Wed, 17 Sep 2003 08:39:38 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.12.9+Sun/8.12.9/Submit) id h8HCdcAd042606; Wed, 17 Sep 2003 08:39:38 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16232.22026.42939.63669@gargle.gargle.HOWL> Date: Wed, 17 Sep 2003 08:39:38 -0400 From: James Carlson To: Karl Fox Cc: Vernon Schryver , ietf-ppp@merit.edu, kevin.p.purser@ericsson.com Subject: Re: pppcn In-Reply-To: Karl Fox's message of 16 September 2003 23:42:54 References: <200309162335.h8GNZEP2018905@calcite.rhyolite.com> <04FAD3D0-E8C1-11D7-96F6-000A958718F0@columbus.rr.com> X-Mailer: VM 7.01 under Emacs 21.3.2 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Karl Fox writes: > From "PPP Design and Debugging," by James Carlson, pages 68-69: [...] > P.S. Thank you, James Carlson, for such a powerful tool. *blush* Thanks! There may be an underlying issue here that's related to what Vern Schryver said. Is the link usable at all with such an atrocious RTT? If it's for the usual sort of web-surfing activities, the answer seems to be "no," in as much as the PPP RTTs are just the tip of an iceberg. "Building the unusable" probably shouldn't be an explicit part of the working group charter. But what of transaction-oriented systems? Suppose the end node intends to do only one or two packet exchanges with some peer before ditching the link? In that case, the PPP RTTs could loom comparatively large in the picture. (This is sort of analogous to the situation with modems: ordinarily, the training time is insignificant in the overall usage, but for transaction-oriented systems where only a few hundred bytes are sent, it's a killer, and there are thus special 1200bps "fast-connect" modems designed just for that purpose.) I think the pre-loading scheme still fixes the PPP problem in this case, and is both simpler than and equivalent to the "masked" approach, but it's possible that a bigger fix (e.g., dispensing with link layer authentication and perhaps PPP as well and turning to network or higher layer authentication) might be better. The question turns back to a perennial favorite: so, what is the actual problem to be solved? -- James Carlson, IP Systems Group Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Wed Sep 17 10:35:27 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 851315DDB4; Wed, 17 Sep 2003 10:35:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B33A991329; Wed, 17 Sep 2003 10:35:14 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5995E91324; Wed, 17 Sep 2003 10:33:48 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 488D79129C for ; Wed, 17 Sep 2003 10:33:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2D44C5DDAE; Wed, 17 Sep 2003 10:33:46 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id EC9DA5DD9E for ; Wed, 17 Sep 2003 10:33:45 -0400 (EDT) Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.9/8.12.9) with ESMTP id h8HEXjAP016144 for ; Wed, 17 Sep 2003 09:33:45 -0500 (CDT) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Wed, 17 Sep 2003 09:33:42 -0500 Message-ID: <7B2A7784F4B7F0409947481F3F3FEF830A082B9C@eammlex037.lmc.ericsson.se> From: "Kevin Purser (QA/EMC)" To: ietf-ppp@merit.edu Subject: RE: pppcn Date: Wed, 17 Sep 2003 09:33:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Hello All, > > > I would like to submit the following I-D for consideration by > > the PPPEXT WG. Please feel free to send comments/questions/flames > > directly to me. > > If our public attention was justifiably requisitioned by the original > message, then our responses should be public. I stand corrected. > > What is about about Scandanavian telephone companies that makes this > issue so compelling that the same non-problem and similar > non-solutions > are raised every few years? It makes no sense in most of the rest of > the world. Hasn't it been Ericsson that has repeatedly proposed > modifying PPP to dealy the supposed multi-second connection setup > times of PPP? > > The problem makes no sense in most of the rest of the world because > no PPP connection that is useful in this century has round trip times > that are so long that 3 extra round trips can total "on the order of > seconds." Any PPP connection where a few extra RTTs are objectionable > is useless to any likely modern application, because modern > applications > are so profligate with both bandwidth and round trips. Exactly what > modern application is usable on a link with effective RTTs of 0.75 > seconds? Exactly what application can tolerate packet loss rates so > hight that 3 RTTs turn into 7 on average? I personally tend to agree with this. Nonetheless, CDMA2000 has incorporated the use of PPP to set up packet data sessions... > > This solution is not quite as bad as previous Scandanavian telco > efforts that proposed to give up entirely on authentication, However, > this one still misses the obvious solution to the non-problem that > has been published here and elsewhere (e.g. James Carlson's book) more > than once. > > This proposal may be intended to be that obvious solution, but > it fails by defining a new "masked packet" protocol. > > The obvious solution does not require any changes to the on-the-wire > PPP protocol. It is for both peers to anticipate each > others' sequence > and magjic numbers and options, and to send a single burst of LCP, > authentication, and IPCP packets. This solution requires no changes > in PPP state machines except for what might be called "pre-loading. Yes, this is exactly what we were aiming for- at least from reading rfc1661, I understood that sending this burst of packets was not allowed. What draft/rfc describes this "pre-loading"? Kev > > > Vernon Schryver vjs@rhyolite.com > From owner-ietf-ppp@merit.edu Wed Sep 17 10:48:29 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id A1DBB5DE50; Wed, 17 Sep 2003 10:48:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A39BC9139C; Wed, 17 Sep 2003 10:43:05 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 70DA4913BE; Wed, 17 Sep 2003 10:43:05 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A8D7F9139C for ; Wed, 17 Sep 2003 10:42:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8C49C5DDA9; Wed, 17 Sep 2003 10:42:59 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id 617FC5DD8E for ; Wed, 17 Sep 2003 10:42:59 -0400 (EDT) Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.9/8.12.9) with ESMTP id h8HEgxAP018320 for ; Wed, 17 Sep 2003 09:42:59 -0500 (CDT) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Wed, 17 Sep 2003 09:42:55 -0500 Message-ID: <7B2A7784F4B7F0409947481F3F3FEF830A082B9E@eammlex037.lmc.ericsson.se> From: "Kevin Purser (QA/EMC)" To: ietf-ppp@merit.edu Subject: RE: draft-purser-pppext-pppcn-00.txt Date: Wed, 17 Sep 2003 09:42:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > > ... > > PS: In the future, please refrain from sending HTML > messages. They are > > almost always unreadable, often due to specific sender's > personal choices > > like colors and font sizes. Use text messages instead, > which have always > > been (and always will be) readable. > > That's a good point. How many extra RTTs and bandwidth were spent > on sending that introductory message as both text/plain and as > quoted-printable--text/html and then attaching the proposal as > quoted-printable? It emphasizes my point about the oddity of > worrying about 4 or 6 extra PPP packets at the start. Ok, ok. I should have known my new company PC's M$ installation would send HTML messages by default- my apologies. > > > Vernon Schryver vjs@rhyolite.com > From owner-ietf-ppp@merit.edu Wed Sep 17 10:48:33 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id C22FD5DE5C; Wed, 17 Sep 2003 10:48:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1A417913C8; Wed, 17 Sep 2003 10:43:46 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 46DB5913C6; Wed, 17 Sep 2003 10:43:45 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 00DEB913BF for ; Wed, 17 Sep 2003 10:43:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DB5545DD95; Wed, 17 Sep 2003 10:43:39 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by segue.merit.edu (Postfix) with ESMTP id 512D95DD8E for ; Wed, 17 Sep 2003 10:43:39 -0400 (EDT) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h8HEhaXw001788; Wed, 17 Sep 2003 08:43:36 -0600 (MDT) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h8HEhafM016762; Wed, 17 Sep 2003 10:43:36 -0400 (EDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.12.9+Sun/8.12.9) with ESMTP id h8HEhaQS042797; Wed, 17 Sep 2003 10:43:36 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.12.9+Sun/8.12.9/Submit) id h8HEhZK8042794; Wed, 17 Sep 2003 10:43:35 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16232.29463.646083.797871@gargle.gargle.HOWL> Date: Wed, 17 Sep 2003 10:43:35 -0400 From: James Carlson To: "Kevin Purser (QA/EMC)" Cc: ietf-ppp@merit.edu Subject: RE: pppcn In-Reply-To: Kevin Purser (QA/EMC)'s message of 17 September 2003 09:33:44 References: <7B2A7784F4B7F0409947481F3F3FEF830A082B9C@eammlex037.lmc.ericsson.se> X-Mailer: VM 7.01 under Emacs 21.3.2 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Kevin Purser (QA/EMC) writes: > > The obvious solution does not require any changes to the on-the-wire > > PPP protocol. It is for both peers to anticipate each > > others' sequence > > and magjic numbers and options, and to send a single burst of LCP, > > authentication, and IPCP packets. This solution requires no changes > > in PPP state machines except for what might be called "pre-loading. > > Yes, this is exactly what we were aiming for- at least from reading rfc1661, I understood that sending this burst of packets was not allowed. What draft/rfc describes this "pre-loading"? None. Nor is any needed, since it's really just an implementation detail. As far as any observer looking at the wire can tell, the negotiation is all happening "normally," albeit with remarkable prescience on the part of the cooperating peers. -- James Carlson, IP Systems Group Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Wed Sep 17 10:48:34 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id B0BD45DE43; Wed, 17 Sep 2003 10:48:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 666649139B; Wed, 17 Sep 2003 10:42:09 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 78C73913A3; Wed, 17 Sep 2003 10:42:07 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 121BB9139B for ; Wed, 17 Sep 2003 10:40:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CE52A5DDB2; Wed, 17 Sep 2003 10:40:07 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id 70BB95DDA9 for ; Wed, 17 Sep 2003 10:40:07 -0400 (EDT) Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.9/8.12.9) with ESMTP id h8HEe7AP017601 for ; Wed, 17 Sep 2003 09:40:07 -0500 (CDT) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Wed, 17 Sep 2003 09:40:03 -0500 Message-ID: <7B2A7784F4B7F0409947481F3F3FEF830A082B9D@eammlex037.lmc.ericsson.se> From: "Kevin Purser (QA/EMC)" To: "'ietf-ppp@merit.edu'" Subject: RE: draft-purser-pppext-pppcn-00.txt Date: Wed, 17 Sep 2003 09:40:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Hello All, > > 4. Security Considerations > > Security considerations are not discussed in this memo. However, > since the aim of this protocol is merely to reduce PPP negotiation > time by allowing the distinct negotiation phases to happen concur- > rently instead of in a serial fashion, there should not be > any addi- > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > tional security risks introduced which are not already present in > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > [PPP]. > > No additional security risks? Really? How about revealing an > IP address > before you have even authenticated the peer? Or accepting an unlimited > number of IP packets waiting for some negotiation to complete? > Neither of these significant security issues are present in RFC1661, > and both represent leaks that can easily be abused. If anything, this > draft _adds_ serious security risks. Perhaps the text wasn't clear enough. While the IP address may be "revealed" to the peer, it's of no consequence if packets sent by that peer will *not* be forwarded by the authenticating peer until *after* completing the auth phase, right? And the sending of IP packets was really only a further optimization to the proposal, not a requirement. Kev > > -Ignacio > > PS: In the future, please refrain from sending HTML messages. They are > almost always unreadable, often due to specific sender's > personal choices > like colors and font sizes. Use text messages instead, which > have always > been (and always will be) readable. > From owner-ietf-ppp@merit.edu Wed Sep 17 10:49:10 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id D0DB35DE05; Wed, 17 Sep 2003 10:49:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 99B899144A; Wed, 17 Sep 2003 10:45:24 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 828CC91446; Wed, 17 Sep 2003 10:45:23 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2BCB991441 for ; Wed, 17 Sep 2003 10:45:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 808D95DD9E; Wed, 17 Sep 2003 10:45:19 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by segue.merit.edu (Postfix) with ESMTP id 1F8A45DD8D for ; Wed, 17 Sep 2003 10:45:17 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.12.10.Beta4/8.12.10.Beta4) id h8HEinDY027114 env-from ; Wed, 17 Sep 2003 08:44:49 -0600 (MDT) Date: Wed, 17 Sep 2003 08:44:49 -0600 (MDT) From: Vernon Schryver Message-Id: <200309171444.h8HEinDY027114@calcite.rhyolite.com> To: ietf-ppp@merit.edu, kevin.p.purser@ericsson.com Subject: RE: pppcn References: <7B2A7784F4B7F0409947481F3F3FEF830A082B9C@eammlex037.lmc.ericsson.se> Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: "Kevin Purser (QA/EMC)" > ... > > The obvious solution does not require any changes to the on-the-wire > > PPP protocol. It is for both peers to anticipate each > > others' sequence > > and magjic numbers and options, and to send a single burst of LCP, > > authentication, and IPCP packets. This solution requires no changes > > in PPP state machines except for what might be called "pre-loading. > > Yes, this is exactly what we were aiming for- at least from > reading rfc1661, I understood that sending this burst of packets > was not allowed. What draft/rfc describes this "pre-loading"? A better question is "draft/rfc prohibits this pre-loading"? An even better question is "how could any standard prohibit it"? What you cannot test for cannot be prohibited. The idea of the pre-loading is that as far as the PPP peer is concerned, each PPP packet arrives as if with a 0 or smaller RTT. As soon as the PPP peer finishes sending its LCP Configure-Request, it discovers that it has received the Configure-Ack. So it processes it and sends its authentiation packet, and instantly receives a response. It's as if there is a super-fast tunnel that delivers the PPP handshakes. The idea is the same as SMTP command pipelining, which is itself a retreading of an even more ancient idea. Vernon Schryver vjs@rhyolite.com P.S. yes, of course, if you could check for this hack just as you can check for the illicit SMTP command pipelining used by some spammers. From owner-ietf-ppp@merit.edu Wed Sep 17 10:49:26 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 4F7045DE4F; Wed, 17 Sep 2003 10:49:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 23F96914A6; Wed, 17 Sep 2003 10:47:00 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E1CAB914A7; Wed, 17 Sep 2003 10:46:59 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9B00C914A6 for ; Wed, 17 Sep 2003 10:46:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7315B5DDA4; Wed, 17 Sep 2003 10:46:57 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id EB44B5DD92 for ; Wed, 17 Sep 2003 10:46:56 -0400 (EDT) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h8HEksMx014468; Wed, 17 Sep 2003 08:46:54 -0600 (MDT) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h8HEkrfM017588; Wed, 17 Sep 2003 10:46:53 -0400 (EDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.12.9+Sun/8.12.9) with ESMTP id h8HEkrQS042815; Wed, 17 Sep 2003 10:46:53 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.12.9+Sun/8.12.9/Submit) id h8HEkrnP042812; Wed, 17 Sep 2003 10:46:53 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16232.29661.518501.77320@gargle.gargle.HOWL> Date: Wed, 17 Sep 2003 10:46:53 -0400 From: James Carlson To: "Kevin Purser (QA/EMC)" Cc: "'ietf-ppp@merit.edu'" Subject: RE: draft-purser-pppext-pppcn-00.txt In-Reply-To: Kevin Purser (QA/EMC)'s message of 17 September 2003 09:40:04 References: <7B2A7784F4B7F0409947481F3F3FEF830A082B9D@eammlex037.lmc.ericsson.se> X-Mailer: VM 7.01 under Emacs 21.3.2 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Kevin Purser (QA/EMC) writes: > > No additional security risks? Really? How about revealing an > > IP address > > before you have even authenticated the peer? Or accepting an unlimited > > number of IP packets waiting for some negotiation to complete? > > Neither of these significant security issues are present in RFC1661, > > and both represent leaks that can easily be abused. If anything, this > > draft _adds_ serious security risks. > > Perhaps the text wasn't clear enough. While the IP address may be "revealed" to the peer, it's of no consequence if packets sent by that peer will *not* be forwarded by the authenticating peer until *after* completing the auth phase, right? And the sending of IP packets was really only a further optimization to the proposal, not a requirement. I agree with that. The proposal doesn't omit the required security steps, and IP addresses seem to me to be hardly something that could be considered "secrets." -- James Carlson, IP Systems Group Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Wed Sep 17 10:50:06 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id A6C195DDA4; Wed, 17 Sep 2003 10:50:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 627E69129C; Wed, 17 Sep 2003 10:49:54 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2E00A9129D; Wed, 17 Sep 2003 10:49:54 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0E4809129C for ; Wed, 17 Sep 2003 10:49:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F2C7D5DD92; Wed, 17 Sep 2003 10:49:51 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by segue.merit.edu (Postfix) with ESMTP id 5EE2F5DD8E for ; Wed, 17 Sep 2003 10:49:50 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.12.10.Beta4/8.12.10.Beta4) id h8HEnku4028088 env-from ; Wed, 17 Sep 2003 08:49:46 -0600 (MDT) Date: Wed, 17 Sep 2003 08:49:46 -0600 (MDT) From: Vernon Schryver Message-Id: <200309171449.h8HEnku4028088@calcite.rhyolite.com> To: ietf-ppp@merit.edu, kevin.p.purser@ericsson.com Subject: RE: draft-purser-pppext-pppcn-00.txt References: <7B2A7784F4B7F0409947481F3F3FEF830A082B9E@eammlex037.lmc.ericsson.se> Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: "Kevin Purser (QA/EMC)" > > That's a good point. How many extra RTTs and bandwidth were spent > > on sending that introductory message as both text/plain and as > > quoted-printable--text/html and then attaching the proposal as > > quoted-printable? It emphasizes my point about the oddity of > > worrying about 4 or 6 extra PPP packets at the start. > > Ok, ok. I should have known my new company PC's M$ installation > would send HTML messages by default- my apologies. But what about the more interesting point of the problem you are trying to solve? If it makes sense to use Micrstupid style bloated email (next comes the 200 or 400 extra lines of XML mail cruft from new installations of Exchange), why does it make sense to worry about a few PPP bits? Vernon Schryver vjs@rhyolite.com P.S. while you're taming your Microstupid infestation, it wouldn't hurt to try to convince it to use ~70 character lines. From owner-ietf-ppp@merit.edu Wed Sep 17 10:52:24 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id ABBB05DD99; Wed, 17 Sep 2003 10:52:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 80B979129D; Wed, 17 Sep 2003 10:52:13 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5035491324; Wed, 17 Sep 2003 10:52:13 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5EBC59129D for ; Wed, 17 Sep 2003 10:52:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4824B5DDA4; Wed, 17 Sep 2003 10:52:12 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from relay5.ftech.net (relay5.ftech.net [195.200.0.100]) by segue.merit.edu (Postfix) with ESMTP id 15EDF5DD9E for ; Wed, 17 Sep 2003 10:52:12 -0400 (EDT) Received: from pc1.faradsl.ftech.co.uk ([212.32.46.162] helo=GENERAL.farsite.co.uk) by relay5.ftech.net with esmtp (Exim 3.36-ftechp12 #2) id 19zdf9-0000kM-00; Wed, 17 Sep 2003 15:52:11 +0100 Received: by GENERAL.farsite.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Sep 2003 15:52:10 +0100 Message-ID: <7C078C66B7752B438B88E11E5E20E72E24F1F0@GENERAL.farsite.co.uk> From: Jonathan Goodchild To: 'James Carlson' Cc: "'ietf-ppp@merit.edu'" Subject: RE: pppcn Date: Wed, 17 Sep 2003 15:52:09 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu From: James Carlson >> What draft/rfc describes this "pre-loading"? > > None. Nor is any needed, since it's really just an implementation detail. True, but could there be some value in such a draft, if only to avoid future unnecessary proposed protocol extensions such as this one? Jonathan Goodchild From owner-ietf-ppp@merit.edu Wed Sep 17 10:56:05 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 12C2A5DDB4; Wed, 17 Sep 2003 10:56:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 381F49132B; Wed, 17 Sep 2003 10:55:52 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0738691324; Wed, 17 Sep 2003 10:55:51 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CB59791330 for ; Wed, 17 Sep 2003 10:55:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id ACD1B5DD9E; Wed, 17 Sep 2003 10:55:50 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id 7F7DD5DD8E for ; Wed, 17 Sep 2003 10:55:50 -0400 (EDT) Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.9/8.12.9) with ESMTP id h8HEtoAP021029 for ; Wed, 17 Sep 2003 09:55:50 -0500 (CDT) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Wed, 17 Sep 2003 09:55:45 -0500 Message-ID: <7B2A7784F4B7F0409947481F3F3FEF830A082B9F@eammlex037.lmc.ericsson.se> From: "Kevin Purser (QA/EMC)" To: ietf-ppp@merit.edu Subject: RE: draft-purser-pppext-pppcn-00.txt Date: Wed, 17 Sep 2003 09:55:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > > > > That's a good point. How many extra RTTs and bandwidth were spent > > > on sending that introductory message as both text/plain and as > > > quoted-printable--text/html and then attaching the proposal as > > > quoted-printable? It emphasizes my point about the oddity of > > > worrying about 4 or 6 extra PPP packets at the start. > > > > Ok, ok. I should have known my new company PC's M$ installation > > would send HTML messages by default- my apologies. > > But what about the more interesting point of the problem you > are trying > to solve? If it makes sense to use Micrstupid style bloated > email (next > comes the 200 or 400 extra lines of XML mail cruft from new > installations > of Exchange), why does it make sense to worry about a few PPP bits? > Because I'm not sending you the email to your cellphone, over a cellular link with much higher latency characteristics than the physical wire. Sorry- thought that was obvious. Kev > > Vernon Schryver vjs@rhyolite.com > > P.S. while you're taming your Microstupid infestation, it wouldn't > hurt to try to convince it to use ~70 character lines. > From owner-ietf-ppp@merit.edu Wed Sep 17 11:06:28 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 0F3A75DD95; Wed, 17 Sep 2003 11:06:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3CD3291334; Wed, 17 Sep 2003 11:06:20 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BDA7191331; Wed, 17 Sep 2003 11:06:19 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 912379132D for ; Wed, 17 Sep 2003 11:04:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 72E565DD9E; Wed, 17 Sep 2003 11:04:51 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by segue.merit.edu (Postfix) with ESMTP id 32BE55DD96 for ; Wed, 17 Sep 2003 11:04:51 -0400 (EDT) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h8HF4loj014572; Wed, 17 Sep 2003 08:04:47 -0700 (PDT) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h8HF4ltK025270; Wed, 17 Sep 2003 11:04:47 -0400 (EDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.12.9+Sun/8.12.9) with ESMTP id h8HF4kQS042857; Wed, 17 Sep 2003 11:04:46 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.12.9+Sun/8.12.9/Submit) id h8HF4k28042854; Wed, 17 Sep 2003 11:04:46 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16232.30734.640222.59888@gargle.gargle.HOWL> Date: Wed, 17 Sep 2003 11:04:46 -0400 From: James Carlson To: Jonathan Goodchild Cc: "'ietf-ppp@merit.edu'" Subject: RE: pppcn In-Reply-To: Jonathan Goodchild's message of 17 September 2003 15:52:09 References: <7C078C66B7752B438B88E11E5E20E72E24F1F0@GENERAL.farsite.co.uk> X-Mailer: VM 7.01 under Emacs 21.3.2 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Jonathan Goodchild writes: > From: James Carlson > > >> What draft/rfc describes this "pre-loading"? > > > > None. Nor is any needed, since it's really just an implementation detail. > > > True, but could there be some value in such a draft, if only to avoid future > unnecessary proposed protocol extensions such as this one? I've resisted the idea in the past, only because I think it's outside of the IETF's proper domain. I don't think we should be specifying implementation details here -- either software designs, APIs, configuration mechanisms, or other such documents. What matters is the bits on the wire and specifying them in enough detail that all can interoperate. The rest is very specific to particular domains, implementations, programming languages, other standards bodies, and the like. Moreover, using the IETF to specify such things (as is unfortunately sometimes done) only encourages more of the same grot in the future. I don't think we need any more "here's how you use HTML+HTTP+TCP+IP+ PPP+CDMA for the FooBar product line" sorts of Informational drafts floating around. These really aren't all that informational, and serve no lasting purpose other than as low-cost advertising. However, if this issue, despite all of the previous discussion stretching back years in the ietf-ppp archives, is going to keep coming back to life like an extra from a Cesar Romero movie, then I guess a preemptive "please try something else" document is the only way out. (I'd still question the usefulness of that document somewhat, since I don't quite see why such an Informational RFC would necessarily be any more likely to be seen and read than are the existing working group archives. But perhaps it's worth a shot.) -- James Carlson, IP Systems Group Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Wed Sep 17 11:07:45 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 0A1405DD9E; Wed, 17 Sep 2003 11:07:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2785F91298; Wed, 17 Sep 2003 11:07:38 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ED4539132D; Wed, 17 Sep 2003 11:07:37 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1DE6C91298 for ; Wed, 17 Sep 2003 11:07:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 04DF25DD95; Wed, 17 Sep 2003 11:07:37 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 0498B5DD8E for ; Wed, 17 Sep 2003 11:07:35 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h8HEXwC17282; Wed, 17 Sep 2003 07:34:06 -0700 Date: Wed, 17 Sep 2003 07:33:57 -0700 (PDT) From: Bernard Aboba To: "Kevin Purser (QA/EMC)" Cc: ietf-ppp@merit.edu Subject: RE: pppcn In-Reply-To: <7B2A7784F4B7F0409947481F3F3FEF830A082B9C@eammlex037.lmc.ericsson.se> Message-ID: References: <7B2A7784F4B7F0409947481F3F3FEF830A082B9C@eammlex037.lmc.ericsson.se> 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 > Exactly what modern application is usable on a link with effective RTTs > of 0.75 seconds? A properly engineered TCP should be usable for bulk data transport even at these RTTs. Streaming media can also work fine with appropriate buffering. Interactive applications will be intolerable. > Exactly what application can tolerate packet loss rates so > high that 3 RTTs turn into 7 on average? Agree with you here. TCP won't function at these loss rates, and neither will interactive applications. I'd claim that any link layer that produces these loss rates is improperly engineered -- it requires link layer reliability improvement via FEC, etc. >It is for both peers to anticipate each others' sequence >and magjic numbers and options, and to send a single burst of LCP, >authentication, and IPCP packets. This solution requires no changes >in PPP state machines except for what might be called "pre-loading. How is it possible to "anticipate" authentication protocols? If this were true, it would imply that the authentication algorithms were broken since they are required to demonstrate pseudo-randomness. From owner-ietf-ppp@merit.edu Wed Sep 17 11:24:06 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 7FBA85DDF8; Wed, 17 Sep 2003 11:23:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 841E491360; Wed, 17 Sep 2003 11:21:34 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 573599135F; Wed, 17 Sep 2003 11:21:34 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 38E5491366 for ; Wed, 17 Sep 2003 11:21:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 03A765DDB2; Wed, 17 Sep 2003 11:21:26 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by segue.merit.edu (Postfix) with ESMTP id 735955DD8E for ; Wed, 17 Sep 2003 11:21:25 -0400 (EDT) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h8HFKnoj022435; Wed, 17 Sep 2003 08:20:49 -0700 (PDT) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h8HFKnfM026338; Wed, 17 Sep 2003 11:20:49 -0400 (EDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.12.9+Sun/8.12.9) with ESMTP id h8HFKmQS042906; Wed, 17 Sep 2003 11:20:48 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.12.9+Sun/8.12.9/Submit) id h8HFKmX3042903; Wed, 17 Sep 2003 11:20:48 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16232.31696.758432.265941@gargle.gargle.HOWL> Date: Wed, 17 Sep 2003 11:20:48 -0400 From: James Carlson To: Bernard Aboba Cc: "Kevin Purser (QA/EMC)" , ietf-ppp@merit.edu Subject: RE: pppcn In-Reply-To: Bernard Aboba's message of 17 September 2003 07:33:57 References: <7B2A7784F4B7F0409947481F3F3FEF830A082B9C@eammlex037.lmc.ericsson.se> X-Mailer: VM 7.01 under Emacs 21.3.2 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Bernard Aboba writes: > >It is for both peers to anticipate each others' sequence > >and magjic numbers and options, and to send a single burst of LCP, > >authentication, and IPCP packets. This solution requires no changes > >in PPP state machines except for what might be called "pre-loading. > > How is it possible to "anticipate" authentication protocols? If this were > true, it would imply that the authentication algorithms were broken since > they are required to demonstrate pseudo-randomness. It's actually fairly easy. All that needs to be done is guarantee that someone who doesn't know a shared secret cannot predict the 'random' portions of the message. For example, generate a cryptographic hash based on a shared secret and the challenge used in the last session (saved in some local storage), and use that hash as the challenge string. Obviously, such a trick is ineffective if the authentication mechanism is more obtuse than either PAP or CHAP. -- James Carlson, IP Systems Group Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Wed Sep 17 11:43:47 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id EFD7A5DD9C; Wed, 17 Sep 2003 11:43:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9A7799129A; Wed, 17 Sep 2003 11:43:34 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 65EBA91331; Wed, 17 Sep 2003 11:43:34 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4BD2F9129A for ; Wed, 17 Sep 2003 11:43:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 357865DDA3; Wed, 17 Sep 2003 11:43:33 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id AC67D5DD9C for ; Wed, 17 Sep 2003 11:43:32 -0400 (EDT) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h8HFhLMx017488; Wed, 17 Sep 2003 09:43:21 -0600 (MDT) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h8HFhKtK004271; Wed, 17 Sep 2003 11:43:20 -0400 (EDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.12.9+Sun/8.12.9) with ESMTP id h8HFhKQS042974; Wed, 17 Sep 2003 11:43:20 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.12.9+Sun/8.12.9/Submit) id h8HFhK2M042971; Wed, 17 Sep 2003 11:43:20 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16232.33048.328435.744197@gargle.gargle.HOWL> Date: Wed, 17 Sep 2003 11:43:20 -0400 From: James Carlson To: "Kehn, Doug" Cc: Bernard Aboba , "Kevin Purser (QA/EMC)" , ietf-ppp@merit.edu Subject: RE: pppcn In-Reply-To: Kehn, Doug's message of 17 September 2003 05:35:12 References: <7B2A7784F4B7F0409947481F3F3FEF830A082B9C@eammlex037.lmc.ericsson.se> <16232.31696.758432.265941@gargle.gargle.HOWL> <1063794913.1332.14.camel@dklaptop> X-Mailer: VM 7.01 under Emacs 21.3.2 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Kehn, Doug writes: > > Obviously, such a trick is ineffective if the authentication mechanism > > is more obtuse than either PAP or CHAP. > > > It also seems that the trick would be ineffective in the presence of > L2TP. Especially, when the LAC uses one authentication protocol to > determine which LNS to setup a tunnel with and the LNS end of the tunnel > renegotiates LCP to a different authentication protocol. Not really. In either case, both ends must be able to predict the exact packet sequence that leads to success. It doesn't matter how that sequence is formed. I'll grant that if the LAC doesn't bother to buffer some small number of packets until the tunnel is established, then it'll most likely fall back to traditional PPP negotiation. Again, that possible buffering issue seems like an internal quality-of-implementation detail to me. -- James Carlson, IP Systems Group Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Wed Sep 17 14:12:44 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 4C0D45DE66; Wed, 17 Sep 2003 14:12:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 39490913CE; Wed, 17 Sep 2003 14:05:06 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 89EDF913D3; Wed, 17 Sep 2003 14:05:04 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8CAC3913C4 for ; Wed, 17 Sep 2003 14:04:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 790D55DDA9; Wed, 17 Sep 2003 14:04:58 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by segue.merit.edu (Postfix) with ESMTP id CC93D5DD9C for ; Wed, 17 Sep 2003 14:04:56 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.12.10.Beta4/8.12.10.Beta4) id h8HI4rtq001922 for ietf-ppp@merit.edu env-from ; Wed, 17 Sep 2003 12:04:53 -0600 (MDT) Date: Wed, 17 Sep 2003 12:04:53 -0600 (MDT) From: Vernon Schryver Message-Id: <200309171804.h8HI4rtq001922@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: RE: pppcn References: <16232.31696.758432.265941@gargle.gargle.HOWL> Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: James Carlson > To: Bernard Aboba > ... > > How is it possible to "anticipate" authentication protocols? If this were > > true, it would imply that the authentication algorithms were broken since > > they are required to demonstrate pseudo-randomness. > > It's actually fairly easy. All that needs to be done is guarantee > that someone who doesn't know a shared secret cannot predict the > 'random' portions of the message. For example, generate a > cryptographic hash based on a shared secret and the challenge used in > the last session (saved in some local storage), and use that hash as > the challenge string. Exactly. "Psuedo-random" does not imply "insecure." "Predictable by the bad guy" does, but that's a quite special and in this context undesirable subset of "psuedo-random." For another example of predicted shared secrets, consider S/key. > Obviously, such a trick is ineffective if the authentication mechanism > is more obtuse than either PAP or CHAP. Probably so, although I don't see how for any likely authentication mechanism. Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp@merit.edu Wed Sep 17 14:49:16 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 8E6225DE0F; Wed, 17 Sep 2003 14:49:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 58B429144C; Wed, 17 Sep 2003 14:40:55 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 27B0391431; Wed, 17 Sep 2003 14:37:37 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C5A3791422 for ; Wed, 17 Sep 2003 14:37:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 63F045DDA9; Wed, 17 Sep 2003 14:37:17 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by segue.merit.edu (Postfix) with ESMTP id 764285DD9C for ; Wed, 17 Sep 2003 14:37:16 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.12.10.Beta4/8.12.10.Beta4) id h8HIbCLD008835 for ietf-ppp@merit.edu env-from ; Wed, 17 Sep 2003 12:37:12 -0600 (MDT) Date: Wed, 17 Sep 2003 12:37:12 -0600 (MDT) From: Vernon Schryver Message-Id: <200309171837.h8HIbCLD008835@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: RE: pppcn References: <16232.30734.640222.59888@gargle.gargle.HOWL> Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: James Carlson > ... > > True, but could there be some value in such a draft, if only to avoid future > > unnecessary proposed protocol extensions such as this one? > > I've resisted the idea in the past, only because I think it's outside > of the IETF's proper domain. ... > Moreover, using the IETF to specify such things (as is unfortunately > sometimes done) only encourages more of the same grot in the future. > I don't think we need any more "here's how you use HTML+HTTP+TCP+IP+ > PPP+CDMA for the FooBar product line" sorts of Informational drafts > floating around. These really aren't all that informational, and > serve no lasting purpose other than as low-cost advertising. I agree. > However, if this issue, despite all of the previous discussion > stretching back years in the ietf-ppp archives, is going to keep > coming back to life like an extra from a Cesar Romero movie, then I > guess a preemptive "please try something else" document is the only > way out. Searching the mailing archives is very hard. If its title were sufficiently enticing in the index, an RFC might help. > (I'd still question the usefulness of that document somewhat, since I > don't quite see why such an Informational RFC would necessarily be any > more likely to be seen and read than are the existing working group > archives. But perhaps it's worth a shot.) There are a couple other reasons to be skeptical. One is that the idea is obvious, common in many fields (e.g. "speculative execution" in CPUs), and old. Would people who don't think of it independently pay attention to an RFC? Another reason is whether it would address the motives for the continuing proposals for fast PPP (re)connection. I don't want to offend anyone, but when I'm trying to solve a technical problem, I might post questions in likely mailing lists, but my questions are unlikely to look like formal proposals complete with bibliographies. The substantial effort of writing an Internet-Draft seems like a good the first step only if the primary goals including writing an RFC. An RFC wouldn't replace or amend the "Link Layer Enhancements for TCP/IP over GSM" in the Proceedings of IEEE INFOCOM, March 1999 that may have been the inspiration or instigation for this cycle. It's also not as if your book is out of print (I hope). On the third hand, an RFC might save the IESG some time if we ever get tired of being wet blankets. Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp@merit.edu Wed Sep 17 15:12:35 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 78C7F5DDDD; Wed, 17 Sep 2003 15:12:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 55970912A2; Wed, 17 Sep 2003 15:11:29 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1726D91351; Wed, 17 Sep 2003 15:11:29 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CA662912A2 for ; Wed, 17 Sep 2003 15:11:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B3F585DDCB; Wed, 17 Sep 2003 15:11:23 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id 596AD5DDC9 for ; Wed, 17 Sep 2003 15:11:23 -0400 (EDT) Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.9/8.12.9) with ESMTP id h8HJBNAP016561 for ; Wed, 17 Sep 2003 14:11:23 -0500 (CDT) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Wed, 17 Sep 2003 14:11:19 -0500 Message-ID: <7B2A7784F4B7F0409947481F3F3FEF830A082BA7@eammlex037.lmc.ericsson.se> From: "Kevin Purser (QA/EMC)" To: ietf-ppp@merit.edu Subject: RE: pppcn Date: Wed, 17 Sep 2003 14:11:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > > However, if this issue, despite all of the previous discussion > > stretching back years in the ietf-ppp archives, is going to keep > > coming back to life like an extra from a Cesar Romero movie, then I > > guess a preemptive "please try something else" document is the only > > way out. > > Searching the mailing archives is very hard. If its title were > sufficiently enticing in the index, an RFC might help. Agreed. Since I haven't been a participant in this WG prior to now, I haven't been privy to these past discussions. Had I known of these discussions, trust that I certainly wouldn't have burdened the WG once more. I usually don't go back very far inspecting mail archives because it is far too difficult/time consuming. > > > > (I'd still question the usefulness of that document > somewhat, since I > > don't quite see why such an Informational RFC would > necessarily be any > > more likely to be seen and read than are the existing working group > > archives. But perhaps it's worth a shot.) > > There are a couple other reasons to be skeptical. One is that the > idea is obvious, common in many fields (e.g. "speculative execution" > in CPUs), and old. Would people who don't think of it independently > pay attention to an RFC? > > Another reason is whether it would address the motives for > the continuing > proposals for fast PPP (re)connection. I don't want to offend anyone, > but when I'm trying to solve a technical problem, I might > post questions > in likely mailing lists, but my questions are unlikely to look like > formal proposals complete with bibliographies. The substantial effort > of writing an Internet-Draft seems like a good the first step only if > the primary goals including writing an RFC. No offense taken here on my part. I understand that for active WG participants, it's certainly more productive for all involved to simply post a question. On the other hand, in the WGs I have been involved with, it's all too often that a newcomer will post a seemingly odd/inflammatory question, only to be completely ignored. I just went ahead and put together a quick I-D (which we did want to see become an RFC eventually) to ensure I'd get some response, good or bad, so thanks to all for the overwhelmingly dissenting responses.... that's still far better than nothing. :) Kev > > An RFC wouldn't replace or amend the "Link Layer Enhancements for > TCP/IP over GSM" in the Proceedings of IEEE INFOCOM, March 1999 that > may have been the inspiration or instigation for this cycle. > > It's also not as if your book is out of print (I hope). > > On the third hand, an RFC might save the IESG some time if we > ever get tired of being wet blankets. > > > Vernon Schryver vjs@rhyolite.com > From owner-ietf-ppp@merit.edu Wed Sep 17 20:52:17 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 4D5315DDD1; Wed, 17 Sep 2003 20:52:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A805391366; Wed, 17 Sep 2003 20:52:03 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7916891368; Wed, 17 Sep 2003 20:52:03 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8401691366 for ; Wed, 17 Sep 2003 20:52:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 719BD5DDD1; Wed, 17 Sep 2003 20:52:02 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from ohsmtp02.ogw.rr.com (ohsmtp02.ogw.rr.com [65.24.7.37]) by segue.merit.edu (Postfix) with ESMTP id 329E35DDCA for ; Wed, 17 Sep 2003 20:52:02 -0400 (EDT) Received: from columbus.rr.com (dhcp93124156.columbus.rr.com [24.93.124.156]) by ohsmtp02.ogw.rr.com (8.12.5/8.12.2) with ESMTP id h8I0pJfh027587; Wed, 17 Sep 2003 20:51:19 -0400 (EDT) Date: Wed, 17 Sep 2003 13:37:27 -0400 Subject: Re: pppcn Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Jonathan Goodchild , ietf-ppp@merit.edu To: James Carlson From: Karl Fox In-Reply-To: <16232.30734.640222.59888@gargle.gargle.HOWL> Message-Id: <9B2FC408-E935-11D7-94C7-000A958718F0@columbus.rr.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu On Wednesday, September 17, 2003, at 11:04 AM, James Carlson wrote: > However, if this issue, despite all of the previous discussion > stretching back years in the ietf-ppp archives, is going to keep > coming back to life like an extra from a Cesar Romero movie, then I > guess a preemptive "please try something else" document is the only > way out. > > (I'd still question the usefulness of that document somewhat, since I > don't quite see why such an Informational RFC would necessarily be any > more likely to be seen and read than are the existing working group > archives. But perhaps it's worth a shot.) Um, didn't you write a book that describes this? Couldn't we just point people at your book? (Didn't I just do that yesterday? :-) Karl From owner-ietf-ppp@merit.edu Thu Sep 18 05:24:25 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id C48875DD8D; Thu, 18 Sep 2003 05:24:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D95CD913A1; Thu, 18 Sep 2003 05:24:11 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A635D913A3; Thu, 18 Sep 2003 05:24:11 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A729D913A1 for ; Thu, 18 Sep 2003 05:24:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8F7665DDDF; Thu, 18 Sep 2003 05:24:10 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from relay5.ftech.net (relay5.ftech.net [195.200.0.100]) by segue.merit.edu (Postfix) with ESMTP id 2FE565DDDC for ; Thu, 18 Sep 2003 05:24:10 -0400 (EDT) Received: from pc1.faradsl.ftech.co.uk ([212.32.46.162] helo=GENERAL.farsite.co.uk) by relay5.ftech.net with esmtp (Exim 3.36-ftechp12 #2) id 19zv1C-0003NJ-00 for ietf-ppp@merit.edu; Thu, 18 Sep 2003 10:24:06 +0100 Received: by GENERAL.farsite.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Sep 2003 10:24:05 +0100 Message-ID: <7C078C66B7752B438B88E11E5E20E72E24F1F8@GENERAL.farsite.co.uk> From: Jonathan Goodchild To: "'ietf-ppp@merit.edu'" Subject: RE: pppcn Date: Thu, 18 Sep 2003 10:24:05 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu From James Carlson: > All that needs to be done is guarantee that someone who > doesn't know a shared secret cannot predict the 'random' > portions of the message. For example, generate a cryptographic > hash based on a shared secret and the challenge used in the > last session (saved in some local storage), and use that > hash as the challenge string. Ummmm, this must mean that both peers need to agree on the mechanism for generating the next challenge. In which case, for there to be interoperability between peers, this mechanism must be a widely understood protocol of some sort, and so I would have thought that there would be grounds for publishing it as an RFC. Jonathan Goodchild From owner-ietf-ppp@merit.edu Thu Sep 18 07:10:04 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 2BD425DDDC; Thu, 18 Sep 2003 07:10:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 98239913A7; Thu, 18 Sep 2003 07:09:51 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6904F913A8; Thu, 18 Sep 2003 07:09:51 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 61E05913A7 for ; Thu, 18 Sep 2003 07:09:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4AFA15DDDE; Thu, 18 Sep 2003 07:09:50 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id B26575DDBE for ; Thu, 18 Sep 2003 07:09:49 -0400 (EDT) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h8IB9jHn014723; Thu, 18 Sep 2003 04:09:46 -0700 (PDT) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h8IB9jfM020675; Thu, 18 Sep 2003 07:09:45 -0400 (EDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.12.9+Sun/8.12.9) with ESMTP id h8IB9jbS000642; Thu, 18 Sep 2003 07:09:45 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.12.9+Sun/8.12.9/Submit) id h8IB9jbg000639; Thu, 18 Sep 2003 07:09:45 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16233.37497.46986.133035@gargle.gargle.HOWL> Date: Thu, 18 Sep 2003 07:09:45 -0400 From: James Carlson To: Karl Fox Cc: ietf-ppp@merit.edu Subject: Re: pppcn In-Reply-To: Karl Fox's message of 17 September 2003 13:37:27 References: <16232.30734.640222.59888@gargle.gargle.HOWL> <9B2FC408-E935-11D7-94C7-000A958718F0@columbus.rr.com> X-Mailer: VM 7.01 under Emacs 21.3.2 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Karl Fox writes: > Um, didn't you write a book that describes this? Couldn't we just > point people at your book? (Didn't I just do that yesterday? :-) Yes, another reason to suspect that an RFC wouldn't actually help much. But, apparently, the original poster feels he would have looked to the RFCs first. -- James Carlson, IP Systems Group Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Thu Sep 18 07:18:45 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 287B85DD8E; Thu, 18 Sep 2003 07:18:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3DD03913A8; Thu, 18 Sep 2003 07:18:38 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 06A79913A9; Thu, 18 Sep 2003 07:18:37 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C6E36913A8 for ; Thu, 18 Sep 2003 07:18:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B48A85DD9C; Thu, 18 Sep 2003 07:18:36 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 43E7E5DDBA for ; Thu, 18 Sep 2003 07:18:36 -0400 (EDT) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h8IBIWU7019099; Thu, 18 Sep 2003 05:18:33 -0600 (MDT) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h8IBIWtK004695; Thu, 18 Sep 2003 07:18:32 -0400 (EDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.12.9+Sun/8.12.9) with ESMTP id h8IBIWbS000652; Thu, 18 Sep 2003 07:18:32 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.12.9+Sun/8.12.9/Submit) id h8IBIWVC000649; Thu, 18 Sep 2003 07:18:32 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16233.38024.181133.666723@gargle.gargle.HOWL> Date: Thu, 18 Sep 2003 07:18:32 -0400 From: James Carlson To: Jonathan Goodchild Cc: "'ietf-ppp@merit.edu'" Subject: RE: pppcn In-Reply-To: Jonathan Goodchild's message of 18 September 2003 10:24:05 References: <7C078C66B7752B438B88E11E5E20E72E24F1F8@GENERAL.farsite.co.uk> X-Mailer: VM 7.01 under Emacs 21.3.2 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Jonathan Goodchild writes: > >From James Carlson: > > > All that needs to be done is guarantee that someone who > > doesn't know a shared secret cannot predict the 'random' > > portions of the message. For example, generate a cryptographic > > hash based on a shared secret and the challenge used in the > > last session (saved in some local storage), and use that > > hash as the challenge string. > > Ummmm, this must mean that both peers need to agree on the mechanism for > generating the next challenge. Sure. They also have to agree on the CHAP shared secret and the peer names. Quite a bit of agreement is required. > In which case, for there to be interoperability between peers, this > mechanism must be a widely understood protocol of some sort, and so I would > have thought that there would be grounds for publishing it as an RFC. The protocol on the wire is still CHAP -- it's only a usage convention, and then only one that is applicable in some restricted domains (you probably wouldn't want to do this everywhere or perhaps even for very long into the future as link technologies improve), and one that poses no interoperability issues at all (if the peer doesn't understand what you're doing, no harm is done, and normal negotiation proceeds). So, I don't quite see it as a problem that requires an RFC, but (again) if someone really wants to publish it, that's fine by me. (It wasn't my original idea anyway ...) -- James Carlson, IP Systems Group Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Thu Sep 18 08:59:03 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id C78E55DDDC; Thu, 18 Sep 2003 08:59:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CB92F913B9; Thu, 18 Sep 2003 08:58:49 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 94645913BA; Thu, 18 Sep 2003 08:58:49 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A589D913B9 for ; Thu, 18 Sep 2003 08:58:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8DDAB5DDEF; Thu, 18 Sep 2003 08:58:48 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from relay5.ftech.net (relay5.ftech.net [195.200.0.100]) by segue.merit.edu (Postfix) with ESMTP id 60E8C5DDED for ; Thu, 18 Sep 2003 08:58:48 -0400 (EDT) Received: from pc1.faradsl.ftech.co.uk ([212.32.46.162] helo=GENERAL.farsite.co.uk) by relay5.ftech.net with esmtp (Exim 3.36-ftechp12 #2) id 19zyMw-0003eN-00 for ietf-ppp@merit.edu; Thu, 18 Sep 2003 13:58:47 +0100 Received: by GENERAL.farsite.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Sep 2003 13:58:45 +0100 Message-ID: <7C078C66B7752B438B88E11E5E20E72E24F1FF@GENERAL.farsite.co.uk> From: Jonathan Goodchild To: "'ietf-ppp@merit.edu'" Subject: RE: pppcn Date: Thu, 18 Sep 2003 13:58:44 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu From: James Carlson > it's only a usage convention, and then only one that is applicable > in some restricted domains (you probably wouldn't want to do this > everywhere or perhaps even for very long into the future as link > technologies improve), and one that poses no interoperability > issues at all (if the peer doesn't understand what you're doing, > no harm is done, and normal negotiation proceeds). Yes, but for "Fast Reconnect" (or whatever it's called) to have any value, everyone needing to use it would have to do it in the same way - it's a different level of agreement than just how a secret is configured. (And even if they don't use CHAP, they still have to know how the PPP Identifier fields will be generated by the peer for LCP and IPCP.) A manufacturer trying to implement it would need to know how other manfacturers have done so - doesn't that make it an interoperability issue? If it's to be adopted by the CDMA2000 community (or whoever), it would need to be documented somewhere. Maybe they could do it themselves somehow, but what if some other group found a use for it - would they start from scratch and maybe do it slightly differently? Besides, if it is to be documented, isn't it more likely to be done properly by the people most competent to do so (i.e. this working group)? Jonathan Goodchild From owner-ietf-ppp@merit.edu Thu Sep 18 09:39:27 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 2AAAC5DE02; Thu, 18 Sep 2003 09:39:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E29BA913ED; Thu, 18 Sep 2003 09:37:04 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9FA9F913E5; Thu, 18 Sep 2003 09:37:04 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 944CE913F1 for ; Thu, 18 Sep 2003 09:36:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 82BE45DDED; Thu, 18 Sep 2003 09:36:47 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by segue.merit.edu (Postfix) with ESMTP id 9CBA95DD9C for ; Thu, 18 Sep 2003 09:36:46 -0400 (EDT) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h8IDaeQ7019798; Thu, 18 Sep 2003 06:36:40 -0700 (PDT) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h8IDadtK021374; Thu, 18 Sep 2003 09:36:40 -0400 (EDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.12.9+Sun/8.12.9) with ESMTP id h8IDacbS004644; Thu, 18 Sep 2003 09:36:38 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.12.9+Sun/8.12.9/Submit) id h8IDacdD004641; Thu, 18 Sep 2003 09:36:38 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16233.46310.564235.839972@gargle.gargle.HOWL> Date: Thu, 18 Sep 2003 09:36:38 -0400 From: James Carlson To: Jonathan Goodchild Cc: "'ietf-ppp@merit.edu'" Subject: RE: pppcn In-Reply-To: Jonathan Goodchild's message of 18 September 2003 13:58:44 References: <7C078C66B7752B438B88E11E5E20E72E24F1FF@GENERAL.farsite.co.uk> X-Mailer: VM 7.01 under Emacs 21.3.2 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Jonathan Goodchild writes: > Yes, but for "Fast Reconnect" (or whatever it's called) to have any value, > everyone needing to use it would have to do it in the same way - it's a > different level of agreement than just how a secret is configured. (And > even if they don't use CHAP, they still have to know how the PPP Identifier > fields will be generated by the peer for LCP and IPCP.) Agreed. I suppose I wasn't clear enough in what I was saying: I don't think it has sufficient lasting value to bother writing it up in an RFC. It seems to me to be harmless if a handful of vendors choose to implement such hacks^Wfeatures on their own. The underlying issue (long RTTs and slow links) seems to me to be at best a temporary problem, and not something that needs to be etched into stone by the IETF, or warrants assigning new protocol IDs or option numbers in PPP. In other words, if it were just a local usage convention within the CDMA2000 community, I'd be happier. This would be in keeping all the other sorts of wackiness we've seen over the years -- for example, IS-835, which *requires* ACCM set to 0, use of reduced-functionality IPCP when authentication is rejected, use of Mobile IP without RFC 2290 negotiation, and all sorts of restrictions on the use of peer names. (In fact, it goes so far to mandate that implementations must not support Proposed Standard RFC 2290.) (And those are just the PPP-related parts.) I agree that this proposal doesn't quite rise to that level in terms of harm, but I guess I'm having trouble determining exactly where the line between "domain specific private arrangements" and "public standards" should lie here, assuming there is such a line. (Along with a nagging fear that this is just the start of a flood ...) -- James Carlson, IP Systems Group Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Thu Sep 18 10:58:29 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 40E135DE08; Thu, 18 Sep 2003 10:58:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A63A09149E; Thu, 18 Sep 2003 10:38:48 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 72A06914BA; Thu, 18 Sep 2003 10:38:37 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E75F2913DE for ; Thu, 18 Sep 2003 10:33:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C509D5DDEE; Thu, 18 Sep 2003 10:33:58 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id 5A2EE5DDED for ; Thu, 18 Sep 2003 10:33:58 -0400 (EDT) Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.9/8.12.9) with ESMTP id h8IEXwAP021408 for ; Thu, 18 Sep 2003 09:33:58 -0500 (CDT) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Thu, 18 Sep 2003 09:33:53 -0500 Message-ID: <7B2A7784F4B7F0409947481F3F3FEF830A082BA9@eammlex037.lmc.ericsson.se> From: "Kevin Purser (QA/EMC)" To: ietf-ppp@merit.edu Subject: RE: pppcn Date: Thu, 18 Sep 2003 09:33:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > But, apparently, the original poster feels he would have looked > to the RFCs first. bingo. Kev > > -- > James Carlson, IP Systems Group > > Sun Microsystems / 1 Network Drive 71.234W Vox +1 > 781 442 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 > 781 442 1677 > From owner-ietf-ppp@merit.edu Thu Sep 18 15:57:07 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 789C05DE20; Thu, 18 Sep 2003 15:57:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9694F91432; Thu, 18 Sep 2003 13:09:01 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C12B49142D; Thu, 18 Sep 2003 13:08:58 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 43234916CF for ; Thu, 18 Sep 2003 13:04:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 33A615DDDD; Thu, 18 Sep 2003 13:04:25 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id CA50A5DD8D for ; Thu, 18 Sep 2003 13:04:24 -0400 (EDT) Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.9/8.12.9) with ESMTP id h8IH4OAP023863 for ; Thu, 18 Sep 2003 12:04:24 -0500 (CDT) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Thu, 18 Sep 2003 12:04:19 -0500 Message-ID: <7B2A7784F4B7F0409947481F3F3FEF830A082BAA@eammlex037.lmc.ericsson.se> From: "Kevin Purser (QA/EMC)" To: ietf-ppp@merit.edu Subject: RE: pppcn Date: Thu, 18 Sep 2003 12:03:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > Buy the book. Read Chapter 7. Build a blindingly fast PPP > implementation that does all you want and more, without changing the > protocol at all. Other people have done it this way; you can too. Perhaps I can then ask if anybody is aware of any open source PPP implementations available that do this? Kev > > Karl Fox > PPPEXT Working Group Chair > > P.S. Thank you, James Carlson, for such a powerful tool. > From owner-ietf-ppp@merit.edu Thu Sep 18 15:57:31 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id A656E5DF70; Thu, 18 Sep 2003 15:57:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 336FD9142C; Thu, 18 Sep 2003 13:23:13 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8D327916E9; Thu, 18 Sep 2003 13:12:57 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8ABB991725 for ; Thu, 18 Sep 2003 13:12:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6DEB25DDF2; Thu, 18 Sep 2003 13:12:14 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id E79925DDE6 for ; Thu, 18 Sep 2003 13:12:13 -0400 (EDT) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h8IHCAU7020340; Thu, 18 Sep 2003 11:12:11 -0600 (MDT) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h8IHCAtK012065; Thu, 18 Sep 2003 13:12:10 -0400 (EDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.12.9+Sun/8.12.9) with ESMTP id h8IHC8bS006465; Thu, 18 Sep 2003 13:12:08 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.12.9+Sun/8.12.9/Submit) id h8IHC8L7006462; Thu, 18 Sep 2003 13:12:08 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16233.59240.634731.324342@gargle.gargle.HOWL> Date: Thu, 18 Sep 2003 13:12:08 -0400 From: James Carlson To: "Kevin Purser (QA/EMC)" Cc: ietf-ppp@merit.edu Subject: RE: pppcn In-Reply-To: Kevin Purser (QA/EMC)'s message of 18 September 2003 12:03:21 References: <7B2A7784F4B7F0409947481F3F3FEF830A082BAA@eammlex037.lmc.ericsson.se> X-Mailer: VM 7.01 under Emacs 21.3.2 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Kevin Purser (QA/EMC) writes: > Perhaps I can then ask if anybody is aware of any open source PPP > implementations available that do this? Nope. I might know people who've experimented with it (*cough*), but no available code. -- James Carlson, IP Systems Group Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677