Subject: [eap] Q: EAP retransmission & fragmentation

From: Mahesh Kelkar <[email-masked]>
Date: Tue, 7 Jun 2005 14:13:18 -0700 (PDT)

Consider an example where... 
- EAP-server & Radius Server lie on the same backend
authentication server. 
- Access Point(AP)/NAS acts as a passthrough for the EAP
auth negotiation. 
- EAP-client lies on the peer. 
- EAP authentication is negotiated between EAP-server &
EAP-client.

Question 1) Who is supposed to retransmit the EAP packets?
EAP-server or AP? 
- According to RFC2716 EAP-server should retransmit the EAP
packets (section 3.2 - Retry Behavior - "As with other EAP
protocols, the EAP server is responsible for retry
behavior")
- According to RFC3748 AP should retransmit the EAP packets
(4.1 - Request and Response - "Implementation Note: The
authenticator is responsible for retransmitting Request
messages.  If the Request message is obtained from
elsewhere (such as from a backend authentication server),
then the authenticator will need to save a copy of the
Request in order to accomplish this.")
- According to RFC 3579, AP should retransmit the EAP
packets (2.3 - Retransmission - As noted in [RFC2284], if
an EAP packet is lost in transit between the authenticating
peer and the NAS (or vice versa), the NAS will retransmit)

Which one is true? 
I think it is very unnatural for AP to retransmit the
packets. Because it is acting as a pass-though and
shouldn't be involved in caching the packets & keeping
track of it.

Question 2)
Normally, EAP-server is instructed to fragment the
EAP-packets to the size of FRAMED-MTU (transmitted in the
Radius Access request). Lets say if we have an EAP-server
or Radius Server that does not comply with this and
fragments the packet to the size more than the link MTU
between AP & the peer. 

Now, AP will have to fragment the EAP packet using the
fragmentation specified by the authentication method (TLS
in this case). And each fragment will require a unique
identifier.
 
In this case how do we manage the identification fields of
the EAP packets? Because if we don't then EAP-response from
peer, reassembled at the AP, will definitely have a
different id than the original id of the EAP request
packet.

Also, can we fragment the EAP-TLS fragment in order to fit
it within the link MTU?

Thanks
Mahesh

__________________________________ 
Discover Yahoo! 
Get on-the-go sports scores, stock quotes, news and more. Check it out! 
http://discover.yahoo.com/mobile.html
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Artur Hecker <[email-masked]>
Date: Wed, 08 Jun 2005 11:31:19 +0200

hi

group, please correct me if i'm wrong:

to Question 1:

i think that depending on what is lost and where, both cases can occur. 
EAP-server is responsible for the EAP method, the authenticator is 
responsible for the EAP "channel". please remember that the EAP method 
is NOT implemented on the authenticator. i would generally suppose that 
a retry is something different than a retransmit. retransmit is a 
reissue of the same packet, whereas retry might imply semantic changes 
to the packet body (increase counters, etc). the latter case can 
impossibly be treated by the authenticator/AP. even if the EAP/TLS 
document does not really describe this case, some EAP methods might 
depend on critical, method-specific timeouts etc. finally, packets might 
be lost between the server and the authenticator. the authenticator will 
only retransmit the EAP packets on the link, according to its EAP state 
machine.

you can perhaps look at it as at layering. the authenticator builds the 
EAP channel, but the EAP server builds the EAP method semantics. i.e. it 
is comparable to the second layer managing retransmissions and e.g. TCP 
managing retransmissions.

to Question 2:

as already said, the AP will not be able to fragment the EAP packet 
according to the EAP method because it does not implement the EAP 
method. citing RFC3748 "fragmentation is not supported within EAP 
itself; however, individual EAP methods may support this."

regards
artur

---

From: Mahesh Kelkar <[email-masked]>
Date: Wed, 8 Jun 2005 09:11:33 -0700 (PDT)

Arthur,

Thanks for the response. 
Please see inline [mvk]

Thanks
Mahesh

--- Artur Hecker <[email-masked]> wrote:

> responsible for the EAP "channel". 

[mvk] This is not clearly spelled out in any RFC. 

If both the EAP-server & EAP-authenticator share the
responsiblity of retransmition, who decides when to
retransmit? I mean, EAP-authenticator can start a timer
after forwarding the request packet and retransmit the
packet again on the timeout. So can EAP-server.

Packet could get lost in the paths EAP-server &
authenticator or authenticator & the peer. There is no way
EAP-server could know about it. If EAP-server is equiped
with the retransmissions, then I think there is no real
need for EAP-authenticator to get involved in the
retransmitions & duplicate detection.

Also, is it true that retransmission of the identity
request packet (that originates on the EAP-authenticator)
should have a different identifier. i.e. it should be a
retry not a retransmission?

>please remember that
> the EAP method 

[mvk] Thus, Radius Server and/or EAP-server (that resides
on the backend authentication server) MUST comply with the
default min EAP MTU of 1020 bytes or the FRAMED-MTU passed
in the Radius Access request. right?

+++++++++++++++++++++++++++++
 M a h e s h  V  K e l k a r

__________________________________ 
Yahoo! Mail 
Stay connected, organized, and protected. Take the tour: 
http://tour.mail.yahoo.com/mailtour.html