Subject: RE: latest MPPE spec

From: Robert Friend <[email-masked]>
Date: Tue, 24 Mar 1998 11:20:13 -0800

Hi Glen,

I have some minor questions and a comment about this doc.

Section 5.: Are the configuration values of 0x20 and 0x40 "backwards
compatible"?  I am not sure what this means because I don't know who has
implemented MPPE-00.  Maybe that is the answer?

Section 7.7.1.: The stateless scheme seems to work well, but it seems to
require quite a lot of resources calculating new keys.  If the packets
are less than 256 bytes then this sounds expensive.  Of course, hardware
would mitigate this performance hit.  :-).

Section 7.7.1.: Question: is it possible in a tunnel to receive packets
out of order?  That is, if the receiver the following coherency counts:
0, 2, 1.  Then how does the receiver handle the third packet (i.e. C3 =
1)?

Section 7.7.2.: The document does not say what the receiver does between
the time he sends a Reset-REQ and the time he receives a packet with the
Flush bit set.  Due to line delays, the receiver could receive several
packets without the Flush bit set.  What does he do with them?  Silently
Discard them?

Regards,
_____________________________________________________________

Robert C. Friend              Hi/fn
Applications Engineering      5973 Avenida Encinas, Suite 110
voice: (760) 827-4542         Carlsbad, CA 92008
FAX:   (760) 827-4577         email: [email-masked]

---

From: Richard Shea <[email-masked]>
Date: Fri, 27 Mar 1998 08:57:31 -0500

Robert Friend wrote:
[..]
> would mitigate this performance hit.  :-).

It is also made worse under conditions of packet loss.  Say four packets
in a row are lost, the receiver then performs 4 re-keys when he receives
the packet following the four that got lost.

The efficacy of an already existent denial of service attack that
already exists is increased as well.  If a malicious host spoofs a
tunneled MPPE packet for a session with a sequence number higher than
the one the receiver is expecting, not only is the state of that session
lost (all MPPE traffic no longer unencrypts correctly since keys will be
out of sync) but the receiver also wastes CPU performing the rekeys for
all the packets it thinks were lost.  The malicious host could repeat at
will, continuing to use up CPU resources on the tunnel endpoint.  Use of
mechanisms for securing the tunnel traffic with per-packet
authentication are obviated by this.

> 0, 2, 1.  Then how does the receiver handle the third packet (i.e. C3

It should be noted that L2TP, PPTP, and L2F all have mechanisms to
provide in-order delivery to the PPP layer.  IF such mechanisms fail or
are not used correctly, then, as Glenn says "Drop it" is the answer to
the second question.

Richard.

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Richard Shea, Principal Engineer               [email-masked]
Bay Networks / Extranet Access                     978-266-1011 x210