Re: pppcn

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.