Subject: [eap] Re: Question on EAP

From: [email-masked] (Bernard Aboba)
Date: Tue, 10 Sep 2002 03:44:58 -0700 (PDT)

> Sorry for those who get this twice. I am a starter of PPP and related
> extentions. I have a question based on the case below,

Note: We now have an EAP WG -- so that this is the appropriate forum for
discussion on EAP. The AAA WG is focussed on development of the Diameter
protocol. However, it appears that your question centers on 802.11,
so that the best place to discuss this topic is one of the
802.11 task groups, such as IEEE 802.11i.

> The authentication server is not only providing
> authentication service but registration services.

EAP is an ACK/NAK protocol, so it is not particularly well suited to
supporting a complex registration process requiring substantial data
transfer.

> And the registration service of the authentication server needs to know the
> user's status in the network (registered or not). Therefore, it relys on
> some sort of information reported by the authenticator which is close to the
> terminals

Is the "Authenticator" an AP or NAS device? Does it speak 802.11/EAP to
the terminal?

> When the terminal powers off, we want the authenticator to detect this

In EAP there is now way for a peer to send a "disconnect" to an
authenticator.

Before the STA goes into "802.11 power save mode" it can communicate this
to the AP, which will queue received packets for it. Alternatively, the
terminal could send an 802.11 disassociate or 802.1X EAPOL-Logoff to the
AP.

> report to the authenitcation server that user is not registered anymore
> (because user has turned off its terminal).

Typically, the AP will not discard authentication/authorization state
merely as a result of entering "power save" mode. A disassociate *may*
accomplish this, but only if EAP is run after association. An 802.1X
EAPOL-Logoff will accomplish this in all cases.

> The question is does the current WLAN technologies and EAP protocol support
> this operation.

I'd recommend looking at the following specifications:

IEEE 802.11
IEEE 802.11i

---

From: [email-masked] (tom bonacci)
Date: Tue, 10 Sep 2002 15:08:14 -0600

> supporting a complex registration process requiring substantial data

I guess I'm not sure what would make this true.  Once EAP has been
negotiated at LCP and an EAP conversation begun (but before the 'final'
EAP Success packet has been sent), what would preclude an arbitrary
number of EAP request/response packets from containing whatever data a
complex registration process may require?

-tom

---

From: [email-masked] (Bernard Aboba)
Date: Tue, 10 Sep 2002 13:34:42 -0700 (PDT)

> complex registration process may require?

Say you wanted to transfer a substantial amount of data (e.g. S=1.5MB)
over an EAP link with an RTT of 500 ms from client to AAA server (not
atypical, given AAA application latencies). Assuming a
link MTU of 1500B, this would take S/1500B * 500 ms = 500 sec = 8.3
minutes. The effective transfer rate is 24 Kbps, *regardless of the link
bandwidth*.

However, using TCP with a 64 KB window, and assuming a 300 ms
RTT (pure transport latency), the effective bandwidth (not taking slow
start into account) is 8 * 64 Kb/.3 sec = 1,747,626 bps, or 73 times the
speed.

So the morale is that if you're looking to do bulk data transfer, EAP is
one of the worst imaginable transport protocols.