|
To be clear, this fragmentation issue is a problem for RADIUS, but not RADSEC, correct? I'd assume that TCP MSS negotiation combined with Packetization Layer Path MTU discovery should make fragmentation of TCP segments relatively unlikely. BTW, how does IPsec solve the fragmentation problem for RADIUS? Couldn't it make it worse? > Date: Fri, 8 Feb 2008 11:23:05 +0100 > From: aland@deployingradius.com > To: stefan.winter@restena.lu > CC: aland@nitros9.org; radiusext@ops.ietf.org > Subject: Re: draft-winter-radsec-01 published > > 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/> |