UDP and fragmentation

[Casper H.S. Dik]

Victor Sudakov <vas at mpeks.no-spam-here.tomsk.su> writes:

>Quoting from http://support.microsoft.com/kb/244474/
>By default, Kerberos uses connectionless UDP datagram packets.
>Depending on a variety of factors including security identifier (SID)
>history and group membership, some accounts will have larger Kerberos
>authentication packet sizes. Depending on the virtual private network
>(VPN) hardware configuration, these larger packets have to be
>fragmented when going through a VPN. The problem is caused by
>fragmentation of these large UDP Kerberos packets. Because UDP is a
>connectionless protocol, fragmented UDP packets will be dropped if
>they arrive at the destination out of order.

Only a broken implementation would drop such packets, especially when
they arrive at the destination.  I believe that some Linux implementations
always transmit UDP packets in reverse order but that is not common.

More likely is intervention by (broken) firewalls who can't filter
UDP packets properly.


>Quoting from
>http://blogs.technet.com/b/askds/archive/2008/03/06/kerberos-for-the-busy-admin.aspx
>A common problem is that routers will arbitrarily fragment UDP
>packets; when this happens the Kerberos ticket request packets are
>discarded by the KDC. 

Unless the TCP/IP stack on that KDC is broken; the KDC wouldn't
notice.

>Please tell me how on earth does the KDC know that the packet has been
>fragmented? Packets are fragmented and reassembled on the network
>level (IP level), the fragmentation process should be opaque to UDP
>and the application, shouldn't it? 

It can't.

>I assume the KDC should just receive data from the socket, no matter
>if the datagram was bigger than the MTU, is it correct?

Yes.

Casper
-- 
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.