UDP and fragmentation

[Victor Sudakov]

Colleagues,

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.

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.

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?

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

TIA.

[Greg Hudson]

Post by Victor Sudakov
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?

Yes, it should.

It's possible that there are cases where one IP-layer network device
fragments the packets and another IP-layer network device throws away
fragments (if the fragments are received out of order, or all of the
time). But the KDC process does not care whether a UDP packet was
fragmented or not.

[Jeffrey Altman]

Many VPNs are built into routers that support stateful packet
inspection as part of the firewall. If the VPN is IPSec based, the MTU
on the vpn connection is typically 152 octets smaller than the MTU on
the networks it connects. As a result any packet that is larger than
this smaller MTU size must be fragmented. Unfortunately, many of the
routers are configured to drop fragmented UDP packets because
reconstructing the packets to pass them through the stateful packet
inspection algorithms in one piece requires memory and cpu resources
which when used for this purpose would hinder overall throughput statistics.

To answer your question, the KDC does not see the fragmentation. It
often doesn't see the packets at all or only sees the first fragment of
the message which is insufficient to generate a response.

Jeffrey Altman

Post by Victor Sudakov
Colleagues,
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.
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.
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?
I assume the KDC should just receive data from the socket, no matter
if the datagram was bigger than the MTU, is it correct?
TIA.

[Danny Mayer]

Post by Victor Sudakov
Colleagues,
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.

Any VPN that cannot handle UDP fragmentation is broken. Get one that
works. Routers need to fragment packets as necessary but that should be
transparent to the higher layers.

Danny

Post by Victor Sudakov
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.
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?
I assume the KDC should just receive data from the socket, no matter
if the datagram was bigger than the MTU, is it correct?
TIA.

[Victor Sudakov]

Post by Danny Mayer

Post by Victor Sudakov
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.

Any VPN that cannot handle UDP fragmentation is broken. Get one that
works.

There is no VPN in my setup. Just the Kerberos packets are for some
reason bigger than the 1500 MTU can handle.

BTW what can make Kerberos packets so big? Microsoft says: "Depending
on a variety of factors including security identifier (SID) history
and group membership, some accounts will have larger Kerberos
authentication packet sizes." What's there inside? Long principal
names? Long keys?

Post by Danny Mayer
Routers need to fragment packets as necessary but that should be
transparent to the higher layers.

I thought so too but Microsoft seems to think otherwise.

[Greg Hudson]

Post by Victor Sudakov
BTW what can make Kerberos packets so big? Microsoft says: "Depending
on a variety of factors including security identifier (SID) history
and group membership, some accounts will have larger Kerberos
authentication packet sizes." What's there inside? Long principal
names? Long keys?

An Active Directory KDC will include authorization data within a
Kerberos ticket which includes the set of groups you are a member of.
If that's a lot of groups, then your ticket will be large.

Another way Kerberos packets can get big is Diffie-Hellman values
conveyed for PKINIT during initial authentication.

[Victor Sudakov]

Post by Greg Hudson

Post by Victor Sudakov
BTW what can make Kerberos packets so big? Microsoft says: "Depending
on a variety of factors including security identifier (SID) history
and group membership, some accounts will have larger Kerberos
authentication packet sizes." What's there inside? Long principal
names? Long keys?

An Active Directory KDC will include authorization data within a
Kerberos ticket which includes the set of groups you are a member of.
If that's a lot of groups, then your ticket will be large.

It is very interesting. Where is room in a Kerberos ticket for
such data?

I have tried to examine the large Active Directory KDC packets with
Wireshark and found nothing unusual (I think nothing I have not
already seen in Heimdal packets).

Post by Greg Hudson
Another way Kerberos packets can get big is Diffie-Hellman values
conveyed for PKINIT during initial authentication.

[Greg Hudson]

Post by Victor Sudakov

Post by Greg Hudson

Post by Victor Sudakov
BTW what can make Kerberos packets so big? Microsoft says: "Depending
on a variety of factors including security identifier (SID) history
and group membership, some accounts will have larger Kerberos
authentication packet sizes." What's there inside? Long principal
names? Long keys?

An Active Directory KDC will include authorization data within a
Kerberos ticket which includes the set of groups you are a member of.
If that's a lot of groups, then your ticket will be large.

It is very interesting. Where is room in a Kerberos ticket for
such data?

The KDC-REP contains a Ticket, which contains an EncTicketPart, which
contains AuthorizationData. That's where the PAC is stored, which
contains (among other things) the list of groups.

Your packet traces may not be able to show you the authorization data
since it's within an encrypted blob, and the key for that blob is not
generally known by the client. (The PAC information is for the benefit
of the service, not the client.)

[Nicolas Williams]

Post by Victor Sudakov

Post by Greg Hudson

Post by Victor Sudakov
BTW what can make Kerberos packets so big? Microsoft says: "Depending
on a variety of factors including security identifier (SID) history
and group membership, some accounts will have larger Kerberos
authentication packet sizes." What's there inside? Long principal
names? Long keys?

An Active Directory KDC will include authorization data within a
Kerberos ticket which includes the set of groups you are a member of.
If that's a lot of groups, then your ticket will be large.

It is very interesting. Where is room in a Kerberos ticket for
such data?

In the authorization-data field [of EncTicketPart]. See RFC4120.

Nico
--

[Victor Sudakov]

Post by Victor Sudakov
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.

Post by Victor Sudakov
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.

Post by Victor Sudakov
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 thought as much.

Post by Victor Sudakov
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.

Then what is Microsoft talking about?

[Casper H.S. Dik]

Post by Victor Sudakov
Then what is Microsoft talking about?

Through the wrong orifice?

Clearly, middleware boxes can fail to forward
such packets and host based firewalls may discard
such packets; but that would be wrong.

Unless you want to inspect the whole packet, a
firewall can safely forward the second and later
packets as dropping the first packet makes sure
it never gets reassembled.

Casper

[Casper H.S. Dik]

Post by Victor Sudakov
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.

Post by Victor Sudakov
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.

Post by Victor Sudakov
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.

Post by Victor Sudakov
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