Subject: RE: pppcn

From: "Kevin Purser (QA/EMC)" <[email-masked]>
Date: Wed, 17 Sep 2003 09:33:44 -0500

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    [email-masked]
>

---

From: James Carlson <[email-masked]>
Date: Wed, 17 Sep 2003 10:43:35 -0400

> 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                <[email-masked]>
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: Vernon Schryver <[email-masked]>
Date: Wed, 17 Sep 2003 08:44:49 -0600 (MDT)

> From: "Kevin Purser (QA/EMC)" <[email-masked]>

> ...
> 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.

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: Bernard Aboba <[email-masked]>
Date: Wed, 17 Sep 2003 07:33:57 -0700 (PDT)

> 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

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: James Carlson <[email-masked]>
Date: Wed, 17 Sep 2003 11:20:48 -0400

> 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.

---

From: James Carlson <[email-masked]>
Date: Wed, 17 Sep 2003 11:43:20 -0400

Kehn, Doug writes:
> 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.

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 17 Sep 2003 12:04:53 -0600 (MDT)

> From: James Carlson <[email-masked]>
> To: Bernard Aboba <[email-masked]>

> the last session (saved in some local storage), and use that hash as

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.

> is more obtuse than either PAP or CHAP.

Probably so, although I don't see how for any likely authentication
mechanism.