For completeness, I think the fundamental potential problem (which
Ric did not describe explicitly) arises from the observation that
DHCP messages sent with a 0.0.0.0 source address (typ. from a client
when the client does not have a confirmed address assignment) cannot
be fragmented by IP (well, they can be fragmented but not reliably
reassembled). There is a secondary potential problem with snooping
(rather than forwarding by a relay agent) DHCP messages that have
been fragmented by IP.
So, if messages from DHCP clients will never exceed the MTU between
the client and the first relay agent, the first problem won't be
realized. And, if none of the DHCP messages between the client and
the relay agent exceed the MTU, the second problem won't be realized.
If I have my arithmetic correct, allowing for the DHCP message
header, magic cookie and some option headers (you'll need one two-
byte option header for each 254 bytes of payload), there should be
about 1240 bytes available for authentication info payload in an
unfragmented DHCP message on a link with a 1500 byte MTU. I'll leave
it to the EAP experts to determine if EAP payloads can be carried
under these constraints.
And, of course, unlimited authentication info can be carried if DHCP
is extended to allow that info to be spread over multiple DHCP
message exchanges. Not that I recommend such an extension, which the
dhc WG ruled out early on in the development of DHCP when we realized
such an extension would be reinventing either TFTP/UDP or TCP,
depending on how you want to solve the problem.
- Ralph
On Nov 4, 2007, at Nov 4, 2007,10:09 PM, Richard Pruss wrote:
I felt some deeper analysis on fragmentation seemed necessary after
volume of emails on the topic.
A couple of emails lay out the basics of the matter:
http://www1.ietf.org/mail-archive/web/int-area/current/msg01110.html
http://www1.ietf.org/mail-archive/web/int-area/current/msg01116.html
http://www1.ietf.org/mail-archive/web/int-area/current/msg01121.html
http://www1.ietf.org/mail-archive/web/int-area/current/msg01124.html
The facts in summary:
"For simplicity it is assumed that the BOOTP packet is never
fragmented." - RFC 951
According to [RFC3748], lower layers must provide an EAP MTU of
1020 bytes or greater.
"Also, not all EAP methods support fragmentation, and among those
that do, not all implementations support an MTU that varies on a
per-packet basis." - Bernard Aboba
Now this is all fine but from the thread I infer that people are
making two additional incorrect assumptions that actually introduce
a problem where none exists.
The first assumption is people assume the minimum DHCP message
size, which is not reasonable or accurate for the deployments use
cases at hand. The link MTU here can be reasonably assumed to be
at least 1500 bytes as it is Ethernet.
Secondly people seem to assume that other DHCP options will be
making the space available for EAP options to stack vary, thus
creating a variable MTU for EAP. This is not the case, the draft
has an option which puts one-way chap onto the existing methods but
for the EAP alternative a new DHCP message is proposed just to
carry the EAP message option.
Thus in summary there is no fragmentation issue as DHCP
Authentication alternative for EAP.
- Ric
P.S. Also on a simple practical note but kind of off topic, I had a
look at EAPOL traces for the various methods nothing and in the
sample I saw nothing was near 500 bytes in length from the ones
that do not support fragmentation. The main two that are of a
concern that do not support fragmentation today are EAP-SIM and EAP-
AKA, how large do these actually get, in practice, I understand new
messages could expact EAP-SIM but what is it today?
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
