Subject: [eap] Re: [Issue 50] lower layer ordering requirement

From: [email-masked] (Bernard Aboba)
Date: Mon, 6 Jan 2003 08:23:47 -0800 (PST)

> EAP was originally defined to run on PPP and RFC 1661 has the
> necessary ordering requirement:
>
> 1.  Introduction
>
>    The Point-to-Point Protocol is designed for simple links which
>    transport packets between two peers.  These links provide full-duplex
>    simultaneous bi-directional operation, and are assumed to deliver
>    packets in order.  It is intended that PPP provide a common solution
>
> Any other transport of EAP *must* respect the ordering requirements of
> PPP.
>

Since this snippet relates to link layer requirements (another issue),
I've taken the liberty of changing the subject line.

Since both the PPP and IEEE 802 link layers provide ordering guarantees,
this issue is not directly relevant to those encapsulations of EAP. But we
have seen proposals for EAP over UDP or even ICMP, where ordering
guarantees would *not* be provided. L2TP is OK, because it does provide
ordering guarantees.

I had been under the impression that the ACK/NAK nature of EAP provided
implicit ordered delivery, so that if the lower layer did *not* provide
ordering guarantees, EAP could compensate.

Is this not the case? What bad things could happen in an EAP over UDP
encapsulation, for example?

---

From: [email-masked] (Yoshihiro Ohba)
Date: Mon, 6 Jan 2003 13:11:37 -0500

In RFC2284, identifier assignment rule does not mandate the use of
monotonically increasing value, which would result in Peer side
accepting any Requests that do not have the identifier of the last 
responded Request.  This would make DoS attack easily by randomly
sending bogus packets to break authentication exchange.

If EAP runs on reliable transport with stricter sequence number rule
(e.g., TCP), such a random attack is not possible since the attacker
needs to synchronize on the TCP sequence number.

BTW, how IEEE 802 link layers provide ordering guarantees?

Yoshihiro Ohba

On Mon, Jan 06, 2003 at 08:23:47AM -0800, Bernard Aboba wrote:
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
>

---

From: [email-masked] (Bernard Aboba)
Date: Mon, 6 Jan 2003 09:29:45 -0800 (PST)

A good reference on IEEE 802 link invariants is "The Switch Book" by Rich
Seifert. Section 2.2.1 discusses "hard" invariants (non duplication and
sequential delivery) and "soft" invariants (low error rate, high
bandwidth, low delay).

While IEEE 802 has no sequence numbers, and does not require receivers to
check for proper ordering, non duplication and sequential delivery are
requirements in the design of bridges. The guarantee is that re-ordering
will not occur in frames sent between a given Source-Destination pair, at
a given level of 802.1p priority.

I'd note that IEEE 802.1X *does* mandate monotonically increasing value,
but since the Identifier space isn't large (only 256 possible values), it
isn't hard for an attacker to go through the entire space.

In discussing duplication, we've talked about how a MIC check is
processed; the language suggested by James requires no state change as the
result of a failed MIC. So a method can be written that would discard all
the bogus packets, regardless of sequence number. But it is true that
requiring monotically increasing values for the Identifier would throw
away 255 out of 256 possible values before the MIC check was even done.

---

From: [email-masked] (Yoshihiro Ohba)
Date: Mon, 6 Jan 2003 15:31:17 -0500

OK, I have overlooked the strawman text for section 4.1 which already
captures the behavior of discarding invalid Request.  And thanks for
the pointer to the book.

Yoshihiro Ohba

On Mon, Jan 06, 2003 at 09:29:45AM -0800, Bernard Aboba wrote:
> result of a failed MIC. 
> So a method can be written that would discard all