From owner-ietf-ppp@merit.edu  Tue Sep 16 16:18:20 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09700
	for <pppext-archive@lists.ietf.org>; Tue, 16 Sep 2003 16:18:19 -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 <ietf-ppp@trapdoor.merit.edu>; 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 <ietf-ppp@merit.edu>; 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 <S8498VPL>; Tue, 16 Sep 2003 15:09:35 -0500
Message-ID: <7B2A7784F4B7F0409947481F3F3FEF830A082B9A@eammlex037.lmc.ericsson.se>
From: "Kevin Purser (QA/EMC)" <kevin.p.purser@ericsson.com>
To: "'karlfox@columbus.rr.com'" <karlfox@columbus.rr.com>,
        "'internet-drafts@ietf.org'" <internet-drafts@ietf.org>,
        "'ietf-ppp@merit.edu'" <ietf-ppp@merit.edu>
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.

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

------_=_NextPart_001_01C37C8E.73B2B91E
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE></TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hello All,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I would like to submit the following =
I-D for consideration by the PPPEXT WG.&nbsp; Please feel free to send =
comments/questions/flames directly to me.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Kev</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Abstract:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; If the Internet is =
accessed via cellular networks, the Point-to-Point</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; protocol (PPP) is most =
commonly used for configuration of the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; circuit-switched or =
packet-switched link.&nbsp; Thus, this PPP</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; configuration time comes =
in addition to the usual call-setup time for</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; the cellular =
connection.&nbsp; In many cases this will result in a fairly</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; long &quot;wait =
time&quot; as perceived by end users before actual application</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; data can be =
transmitted.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; This proposal describes a =
solution in which the PPP configuration</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; time can be =
significantly reduced (on the order of seconds) in cases</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; where both peer protocol =
entities can be modified according to this</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; proposal, which involves =
modifying standard PPP.&nbsp; In cases where one</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; PPP peer is modified and =
the other utilizes only standard PPP, the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; modified peer can =
fallback to standard PPP operation.&nbsp; This fallback</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; mechanism will not =
noticeably affect the PPP setup time, and serves</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; to ensure =
interoperability.</FONT>
</P>

<P><FONT FACE=3D"Arial" SIZE=3D2 COLOR=3D"#000000"> =
&lt;&lt;draft-purser-pppext-pppcn-00.txt&gt;&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_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"
Content-Transfer-Encoding: quoted-printable







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:35 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19943
	for <pppext-archive@lists.ietf.org>; Tue, 16 Sep 2003 19:35:34 -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 <ietf-ppp@trapdoor.merit.edu>; 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 <ietf-ppp@merit.edu>; 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 <vjs>;
	Tue, 16 Sep 2003 17:35:14 -0600 (MDT)
Date: Tue, 16 Sep 2003 17:35:14 -0600 (MDT)
From: Vernon Schryver <vjs@calcite.rhyolite.com>
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)" <kevin.p.purser@ericsson.com>
> To: "'karlfox@columbus.rr.com'" <karlfox@columbus.rr.com>,
>         "'internet-drafts@ietf.org'" <internet-drafts@ietf.org>,
>         "'ietf-ppp@merit.edu'" <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:37 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24987
	for <pppext-archive@lists.ietf.org>; Tue, 16 Sep 2003 22:46:37 -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 <ietf-ppp@trapdoor.merit.edu>; 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 <ietf-ppp@merit.edu>; 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 <vjs>;
	Tue, 16 Sep 2003 20:45:43 -0600 (MDT)
Date: Tue, 16 Sep 2003 20:45:43 -0600 (MDT)
From: Vernon Schryver <vjs@calcite.rhyolite.com>
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 <igoyret@lucent.com>

> ...
> 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:11 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26745
	for <pppext-archive@lists.ietf.org>; Tue, 16 Sep 2003 23:43:11 -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 <ietf-ppp@trapdoor.merit.edu>; 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 <ietf-ppp@merit.edu>; 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 <vjs@calcite.rhyolite.com>
From: Karl Fox <karlfox@columbus.rr.com>
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
Content-Transfer-Encoding: 7bit

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:06 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09173
	for <pppext-archive@lists.ietf.org>; Wed, 17 Sep 2003 08:40:05 -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 <ietf-ppp@trapdoor.merit.edu>; 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 <ietf-ppp@merit.edu>; 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 <james.d.carlson@sun.com>
To: Karl Fox <karlfox@columbus.rr.com>
Cc: Vernon Schryver <vjs@calcite.rhyolite.com>, 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
Content-Transfer-Encoding: 7bit

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                <james.d.carlson@sun.com>
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:51 2003
Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15340
	for <pppext-archive@lists.ietf.org>; Wed, 17 Sep 2003 10:35:50 -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 <ietf-ppp@trapdoor.merit.edu>; 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 <ietf-ppp@merit.edu>; 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 <ietf-ppp@merit.edu>; Wed, 17 Sep 2003 09:33:45 -0500 (CDT)
Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2656.59)
	id <S840AQXS>; Wed, 17 Sep 2003 09:33:42 -0500
Message-ID: <7B2A7784F4B7F0409947481F3F3FEF830A082B9C@eammlex037.lmc.ericsson.se>
From: "Kevin Purser (QA/EMC)" <kevin.p.purser@ericsson.com>
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:44:31 2003
Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15569
	for <pppext-archive@lists.ietf.org>; Wed, 17 Sep 2003 10:44:30 -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 <ietf-ppp@trapdoor.merit.edu>; 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 <ietf-ppp@merit.edu>; 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 <ietf-ppp@merit.edu>; Wed, 17 Sep 2003 09:40:07 -0500 (CDT)
Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2656.59)
	id <S840AR5X>; Wed, 17 Sep 2003 09:40:03 -0500
Message-ID: <7B2A7784F4B7F0409947481F3F3FEF830A082B9D@eammlex037.lmc.ericsson.se>
From: "Kevin Purser (QA/EMC)" <kevin.p.purser@ericsson.com>
To: "'ietf-ppp@merit.edu'" <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:45:02 2003
Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15613
	for <pppext-archive@lists.ietf.org>; Wed, 17 Sep 2003 10:45:01 -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 <ietf-ppp@trapdoor.merit.edu>; 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 <ietf-ppp@merit.edu>; 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 <ietf-ppp@merit.edu>; Wed, 17 Sep 2003 09:42:59 -0500 (CDT)
Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2656.59)
	id <S840ASJ9>; Wed, 17 Sep 2003 09:42:55 -0500
Message-ID: <7B2A7784F4B7F0409947481F3F3FEF830A082B9E@eammlex037.lmc.ericsson.se>
From: "Kevin Purser (QA/EMC)" <kevin.p.purser@ericsson.com>
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:45:05 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15629
	for <pppext-archive@lists.ietf.org>; Wed, 17 Sep 2003 10:45:04 -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 <ietf-ppp@trapdoor.merit.edu>; 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 <ietf-ppp@merit.edu>; 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 <james.d.carlson@sun.com>
To: "Kevin Purser (QA/EMC)" <kevin.p.purser@ericsson.com>
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
Content-Transfer-Encoding: 7bit

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                <james.d.carlson@sun.com>
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:45:53 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15690
	for <pppext-archive@lists.ietf.org>; Wed, 17 Sep 2003 10:45:52 -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 <ietf-ppp@trapdoor.merit.edu>; 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 <ietf-ppp@merit.edu>; 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 <vjs>;
	Wed, 17 Sep 2003 08:44:49 -0600 (MDT)
Date: Wed, 17 Sep 2003 08:44:49 -0600 (MDT)
From: Vernon Schryver <vjs@calcite.rhyolite.com>
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)" <kevin.p.purser@ericsson.com>

> ...
> > 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:47:48 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15738
	for <pppext-archive@lists.ietf.org>; Wed, 17 Sep 2003 10:47:47 -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 <ietf-ppp@trapdoor.merit.edu>; 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 <ietf-ppp@merit.edu>; 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 <james.d.carlson@sun.com>
To: "Kevin Purser (QA/EMC)" <kevin.p.purser@ericsson.com>
Cc: "'ietf-ppp@merit.edu'" <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
Content-Transfer-Encoding: 7bit

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                <james.d.carlson@sun.com>
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:12 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15786
	for <pppext-archive@lists.ietf.org>; Wed, 17 Sep 2003 10:50:12 -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 <ietf-ppp@trapdoor.merit.edu>; 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 <ietf-ppp@merit.edu>; 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 <vjs>;
	Wed, 17 Sep 2003 08:49:46 -0600 (MDT)
Date: Wed, 17 Sep 2003 08:49:46 -0600 (MDT)
From: Vernon Schryver <vjs@calcite.rhyolite.com>
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)" <kevin.p.purser@ericsson.com>


> > 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:31 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15882
	for <pppext-archive@lists.ietf.org>; Wed, 17 Sep 2003 10:52:30 -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 <ietf-ppp@trapdoor.merit.edu>; 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 <ietf-ppp@merit.edu>; 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 <SSH0MXML>; Wed, 17 Sep 2003 15:52:10 +0100
Message-ID: <7C078C66B7752B438B88E11E5E20E72E24F1F0@GENERAL.farsite.co.uk>
From: Jonathan Goodchild <jon.goodchild@farsite.co.uk>
To: "'James Carlson'" <james.d.carlson@sun.com>
Cc: "'ietf-ppp@merit.edu'" <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:02 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15965
	for <pppext-archive@lists.ietf.org>; Wed, 17 Sep 2003 10:56:01 -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 <ietf-ppp@trapdoor.merit.edu>; 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 <ietf-ppp@merit.edu>; 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 <ietf-ppp@merit.edu>; Wed, 17 Sep 2003 09:55:50 -0500 (CDT)
Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2656.59)
	id <S840AT79>; Wed, 17 Sep 2003 09:55:45 -0500
Message-ID: <7B2A7784F4B7F0409947481F3F3FEF830A082B9F@eammlex037.lmc.ericsson.se>
From: "Kevin Purser (QA/EMC)" <kevin.p.purser@ericsson.com>
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:26 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16362
	for <pppext-archive@lists.ietf.org>; Wed, 17 Sep 2003 11:06:26 -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 <ietf-ppp@trapdoor.merit.edu>; 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 <ietf-ppp@merit.edu>; 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 <james.d.carlson@sun.com>
To: Jonathan Goodchild <jon.goodchild@farsite.co.uk>
Cc: "'ietf-ppp@merit.edu'" <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
Content-Transfer-Encoding: 7bit

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                <james.d.carlson@sun.com>
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:53 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16419
	for <pppext-archive@lists.ietf.org>; Wed, 17 Sep 2003 11:07:53 -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 <ietf-ppp@trapdoor.merit.edu>; 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 <ietf-ppp@merit.edu>; 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 <aboba@internaut.com>
To: "Kevin Purser (QA/EMC)" <kevin.p.purser@ericsson.com>
Cc: ietf-ppp@merit.edu
Subject: RE: pppcn
In-Reply-To: <7B2A7784F4B7F0409947481F3F3FEF830A082B9C@eammlex037.lmc.ericsson.se>
Message-ID: <Pine.LNX.4.53.0309170729090.16719@internaut.com>
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:23:59 2003
Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16982
	for <pppext-archive@lists.ietf.org>; 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 <ietf-ppp@trapdoor.merit.edu>; 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 <ietf-ppp@merit.edu>; 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 <james.d.carlson@sun.com>
To: Bernard Aboba <aboba@internaut.com>
Cc: "Kevin Purser (QA/EMC)" <kevin.p.purser@ericsson.com>, 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>
	<Pine.LNX.4.53.0309170729090.16719@internaut.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
Content-Transfer-Encoding: 7bit

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                <james.d.carlson@sun.com>
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:43 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18183
	for <pppext-archive@lists.ietf.org>; Wed, 17 Sep 2003 11:43:43 -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 <ietf-ppp@trapdoor.merit.edu>; 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 <ietf-ppp@merit.edu>; 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 <james.d.carlson@sun.com>
To: "Kehn, Doug" <Doug.Kehn@siemens.com>
Cc: Bernard Aboba <aboba@internaut.com>,
        "Kevin Purser (QA/EMC)" <kevin.p.purser@ericsson.com>,
        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>
	<Pine.LNX.4.53.0309170729090.16719@internaut.com>
	<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
Content-Transfer-Encoding: 7bit

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                <james.d.carlson@sun.com>
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:06:20 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22190
	for <pppext-archive@lists.ietf.org>; Wed, 17 Sep 2003 14:06:20 -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 <ietf-ppp@trapdoor.merit.edu>; 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 <ietf-ppp@merit.edu>; 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 <vjs>;
	Wed, 17 Sep 2003 12:04:53 -0600 (MDT)
Date: Wed, 17 Sep 2003 12:04:53 -0600 (MDT)
From: Vernon Schryver <vjs@calcite.rhyolite.com>
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 <james.d.carlson@sun.com>
> To: Bernard Aboba <aboba@internaut.com>

> ...
> > 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:42:24 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23301
	for <pppext-archive@lists.ietf.org>; Wed, 17 Sep 2003 14:42:24 -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 <ietf-ppp@trapdoor.merit.edu>; 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 <ietf-ppp@merit.edu>; 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 <vjs>;
	Wed, 17 Sep 2003 12:37:12 -0600 (MDT)
Date: Wed, 17 Sep 2003 12:37:12 -0600 (MDT)
From: Vernon Schryver <vjs@calcite.rhyolite.com>
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 <james.d.carlson@sun.com>

> ...
> > 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:31 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24793
	for <pppext-archive@lists.ietf.org>; Wed, 17 Sep 2003 15:12:31 -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 <ietf-ppp@trapdoor.merit.edu>; 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 <ietf-ppp@merit.edu>; 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 <ietf-ppp@merit.edu>; Wed, 17 Sep 2003 14:11:23 -0500 (CDT)
Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2656.59)
	id <S840B4WG>; Wed, 17 Sep 2003 14:11:19 -0500
Message-ID: <7B2A7784F4B7F0409947481F3F3FEF830A082BA7@eammlex037.lmc.ericsson.se>
From: "Kevin Purser (QA/EMC)" <kevin.p.purser@ericsson.com>
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:12 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08229
	for <pppext-archive@lists.ietf.org>; Wed, 17 Sep 2003 20:52:11 -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 <ietf-ppp@trapdoor.merit.edu>; 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 <ietf-ppp@merit.edu>; 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 <jon.goodchild@farsite.co.uk>, ietf-ppp@merit.edu
To: James Carlson <james.d.carlson@sun.com>
From: Karl Fox <karlfox@columbus.rr.com>
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
Content-Transfer-Encoding: 7bit

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:21 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03462
	for <pppext-archive@lists.ietf.org>; Thu, 18 Sep 2003 05:24:21 -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 <ietf-ppp@trapdoor.merit.edu>; 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 <ietf-ppp@merit.edu>; 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 <SSH0MZND>; Thu, 18 Sep 2003 10:24:05 +0100
Message-ID: <7C078C66B7752B438B88E11E5E20E72E24F1F8@GENERAL.farsite.co.uk>
From: Jonathan Goodchild <jon.goodchild@farsite.co.uk>
To: "'ietf-ppp@merit.edu'" <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:01 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07062
	for <pppext-archive@lists.ietf.org>; Thu, 18 Sep 2003 07:10:00 -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 <ietf-ppp@trapdoor.merit.edu>; 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 <ietf-ppp@merit.edu>; 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 <james.d.carlson@sun.com>
To: Karl Fox <karlfox@columbus.rr.com>
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
Content-Transfer-Encoding: 7bit

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                <james.d.carlson@sun.com>
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:51 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07374
	for <pppext-archive@lists.ietf.org>; Thu, 18 Sep 2003 07:18:51 -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 <ietf-ppp@trapdoor.merit.edu>; 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 <ietf-ppp@merit.edu>; 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 <james.d.carlson@sun.com>
To: Jonathan Goodchild <jon.goodchild@farsite.co.uk>
Cc: "'ietf-ppp@merit.edu'" <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
Content-Transfer-Encoding: 7bit

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                <james.d.carlson@sun.com>
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:02 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09856
	for <pppext-archive@lists.ietf.org>; 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 <ietf-ppp@trapdoor.merit.edu>; 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 <ietf-ppp@merit.edu>; 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 <SSH0MZX0>; Thu, 18 Sep 2003 13:58:45 +0100
Message-ID: <7C078C66B7752B438B88E11E5E20E72E24F1FF@GENERAL.farsite.co.uk>
From: Jonathan Goodchild <jon.goodchild@farsite.co.uk>
To: "'ietf-ppp@merit.edu'" <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:38:57 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11176
	for <pppext-archive@lists.ietf.org>; Thu, 18 Sep 2003 09:38:57 -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 <ietf-ppp@trapdoor.merit.edu>; 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 <ietf-ppp@merit.edu>; 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 <james.d.carlson@sun.com>
To: Jonathan Goodchild <jon.goodchild@farsite.co.uk>
Cc: "'ietf-ppp@merit.edu'" <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
Content-Transfer-Encoding: 7bit

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                <james.d.carlson@sun.com>
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:40:36 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15712
	for <pppext-archive@lists.ietf.org>; Thu, 18 Sep 2003 10:40:35 -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 <ietf-ppp@trapdoor.merit.edu>; 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 <ietf-ppp@merit.edu>; 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 <ietf-ppp@merit.edu>; Thu, 18 Sep 2003 09:33:58 -0500 (CDT)
Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2656.59)
	id <S840FWVX>; Thu, 18 Sep 2003 09:33:53 -0500
Message-ID: <7B2A7784F4B7F0409947481F3F3FEF830A082BA9@eammlex037.lmc.ericsson.se>
From: "Kevin Purser (QA/EMC)" <kevin.p.purser@ericsson.com>
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                
> <james.d.carlson@sun.com>
> 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 13:10:22 2003
Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23858
	for <pppext-archive@lists.ietf.org>; Thu, 18 Sep 2003 13:10:22 -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 <ietf-ppp@trapdoor.merit.edu>; 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 <ietf-ppp@merit.edu>; 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 <ietf-ppp@merit.edu>; Thu, 18 Sep 2003 12:04:24 -0500 (CDT)
Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2656.59)
	id <S840GKCG>; Thu, 18 Sep 2003 12:04:19 -0500
Message-ID: <7B2A7784F4B7F0409947481F3F3FEF830A082BAA@eammlex037.lmc.ericsson.se>
From: "Kevin Purser (QA/EMC)" <kevin.p.purser@ericsson.com>
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 13:29:00 2003
Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24463
	for <pppext-archive@lists.ietf.org>; Thu, 18 Sep 2003 13:29:00 -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 <ietf-ppp@trapdoor.merit.edu>; 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 <ietf-ppp@merit.edu>; 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 <james.d.carlson@sun.com>
To: "Kevin Purser (QA/EMC)" <kevin.p.purser@ericsson.com>
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
Content-Transfer-Encoding: 7bit

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                <james.d.carlson@sun.com>
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