Re: draft-winter-radsec-01 published

[Alan DeKok <aland@deployingradius.com>]

Stefan Winter wrote:
> The issue is more about the supplicant knowing its MTU, sending the maximum 
> payload possible (typically, in EAP-TLS where the supplicant has a lot to 
> say), the authenticator encapsulating that in a RADIUS packet, which grows 
> larger than the MTU on its own uplink, leading to fragmentation of the UDP 
> packet.

  Ah.  That's a completely separate problem.

> That is not in principle a problem, but practical experience has 
> shown that too many firewalls drop the fragments and auth doesn't work.

  Broken firewalls are bad.  Putting a firewall between a NAS and a
RADIUS server is generally not a good idea.  Sending RADIUS over the
wider Internet isn't a good idea, unless encapsulation is used (IPSec,
etc.), which solves the UDP fragmentation problem.

> It would be desirable to be able to tell the supplicant that it should send 
> *less* than its own MTU to prevent that from happening.

  This is a path MTU discovery problem.  It's hard.  i.e. impossible, in
the general case.

> On the server side, EAP fragment size is statically configured, and is often a 
> lot less than what supplicant could handle (1024 is a common default). Thus, 
> sending less payload than would be possible means that a server has to split 
> the EAP conversation in more RADIUS packets than need be, meaning more 
> round-trips and longer time-to-auth. 

  I'm not sure what else to say other than "Yes, that's life..."

  I think it's a bad idea to add complexity to EAP in order to work
around firewall bugs.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>