Subject: [eap] Issue 168: Peer link usage

From: Bernard Aboba <[email-masked]>
Date: Fri, 22 Aug 2003 13:25:33 -0700 (PDT)

Issue 168: Peer link usage
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: 8/22/2003
Reference:
Document: RFC2284bis
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

I have recently looked at EAP authentication traces where the
peer is sending data packets before and interspersed with,
EAP authentication.  The peer had been previously attached to
another authenticator and was sending high-rate UDP traffic (video).
This is not a re-authentication -- it represents the authentication of a
peer to a new Authenticator (AP) after a roam.

After it connects to the new Authenticator, the peer continues to
empty the queue onto the new link.

Of course, the new Authenticator silently discards the traffic, but the
EAP traffic is trapped in the queue (e.g. is not prioritized), and so
it can take seconds to be sent by the peer.  The result is
retransmission by the Authenticator -- and horrendous EAP
authentication latencies.

I would also note that this problem is not rare -- it has shown up in
quite a few implementations that we have tested.

It occurs to me that perhaps we need some explicit language in RFC 2284bis
to make it clear that this is nonsensical behavior.  For example, that the
peer should not be sending outbound data or receiving
inbound data (e.g. non-EAP or 802.1X) traffic prior to the link being
usable.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Alper Yegin <[email-masked]>
Date: Fri, 22 Aug 2003 18:33:32 -0700

> inbound data (e.g. non-EAP or 802.1X) traffic prior to the link being

I think this should be tied to the state machine, such that the implementors
know when the "link is usable".

This is similar to some of the recent DNA discussions. Just because the
interface is available to send and receive IP packets does not necessarily
mean that it is ready to send/receive user data packets. We are seeing the
same in this example, at a lower layer though...

alper

---

From: John Vollbrecht <[email-masked]>
Date: Mon, 25 Aug 2003 13:46:17 -0400

> inbound data (e.g. non-EAP or 802.1X) traffic prior to the link being

This sounds like a real problem that should be handled.  I am thinking this 
is better for 802.1x or other lower layer than for EAP.  What do you think?

---

From: John Vollbrecht <[email-masked]>
Date: Mon, 25 Aug 2003 13:51:55 -0400

--On Friday, August 22, 2003 6:33 PM -0700 Alper Yegin 
<[email-masked]> wrote:

> > It occurs to me that perhaps we need some explicit language in RFC
> > 2284bis to make it clear that this is nonsensical behavior.  For
> > example, that the peer should not be sending outbound data or receiving
> I think this should be tied to the state machine, such that the
> implementors know when the "link is usable".
>
I think it is in the lower layer state machine.  EAP should not be called 
to run on a link with a lot of other stuff on it - seems to me.  If it 
isn't called at the wrong time it doesn't need to say don't use the link.

Other ways of doing this seem to make it hard to do reauthentication on an 
existing stream.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 25 Aug 2003 15:45:17 -0700 (PDT)

> is better for 802.1x or other lower layer than for EAP.  What do you think?

It's hard for me to imagine that this would be correct behavior for an
implementation of EAP on any media -- so I think the fix belongs in RFC
2284bis.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 25 Aug 2003 15:47:23 -0700 (PDT)

> isn't called at the wrong time it doesn't need to say don't use the link.

Actually, it's the EAP state machine that controls whether the port is
perceived to be usable to send data traffic, not the other way around.

> Other ways of doing this seem to make it hard to do reauthentication on an

Are you saying that the current EAP state machine does not correctly
handle reauthentication?

---

From: John Vollbrecht <[email-masked]>
Date: Wed, 27 Aug 2003 08:38:43 -0400

--On Monday, August 25, 2003 3:45 PM -0700 Bernard Aboba 
<[email-masked]> wrote:

> > This sounds like a real problem that should be handled.  I am thinking
> > this is better for 802.1x or other lower layer than for EAP.  What do
> > you think?
>

I agree it is not correct, but I don't think EAP should specify what the 
lower layer does.  
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: John Vollbrecht <[email-masked]>
Date: Thu, 28 Aug 2003 18:03:59 -0400

--On Monday, August 25, 2003 3:47 PM -0700 Bernard Aboba 
<[email-masked]> wrote:

> > I think it is in the lower layer state machine.  EAP should not be
> > called to run on a link with a lot of other stuff on it - seems to me.
> > If it isn't called at the wrong time it doesn't need to say don't use
> > the link.
>
My understanding is that the lower layer takes care of the port.  The lower 
layer sets PortEnabled to go to a start state.  It then sends eapReq and 
gets eapResp or eapNoResp.   When done it sets either eapSuccess or 
eapFailure.

The lower layer is responible for transmitting packets over the Link.  EAP 
does not know if this is being done with other packets or not.    EAP does 
authentication not port control.

> > Other ways of doing this seem to make it hard to do reauthentication on
> > an existing stream.
>
No.  What I was thinking about was if the NAS/AP decides to reauthenticate 
after some time, without taking the port down.  I believe this works fine. 
It takes some work on the port side, but should work with 802.1aa.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 28 Aug 2003 15:49:24 -0700

I agree with John.  

EAP should just starts authentication when requested by a lower-layer
and returns a success/failure result (and EAP-specific additional
information such as MSKs if any) when authentication completes. (Of
course EAP messages are passed between EAP entity and lowe-layer
entity during authentication).  It should be the responsibility of the
lower-layer to determine whether to filter data packets on the port
based on the authentication result and lower-layer specific states.

Having said that, I think the portEnabled variable in the state machie
draft should be renamed to some generic name like eapStarted, which
provides the same level of abstraction as eapSuccess/eapFailure
variables.  And I also think that eapRestart and eapBackendRestart are
redundant and can be deleted.

Yoshihiro Ohba

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 28 Aug 2003 15:32:27 -0700 (PDT)

> based on the authentication result and lower-layer specific states.

EAP is media independent, which implies that the result of an EAP
conversation has to be the same on any media; EAP-Success needs to mean
the same thing on PPP, IEEE 802.1, IEEE 802.11, etc.  Same with failure.

So I don't think we can say that the result is dependent on the link
layer. RFC 2284bis doesn't say this now -- in several places it talks
about "enabling the link".
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Nick Petroni <[email-masked]>
Date: Fri, 29 Aug 2003 21:51:24 -0400 (EDT)

> the same thing on PPP, IEEE 802.1, IEEE 802.11, etc.  Same with failure.

IMHO, "EAP-Success" does mean the same thing- EAP is an authentication
protocol and the authentication is still valid. I think access
control should be orthogonal to authentication, although it should be
clearly stated that if you are basing that access on authentication
then it's probably a good idea not to open the link.

> about "enabling the link".

I don't see how the "result" is dependent even if you allow traffic during
the conversation, but I agree that the language is misleading. By
"enabling" it seems the draft really means any secure channel based on
that authentication. I may not be framing that argument precisely enough,
but I tend to agree with John and Yoshihiro- it's up to the lower layer to
utilize the authentication decision as it sees fit.

nick