Ralph, > -----Original Message----- > From: Ralph Droms [mailto:[EMAIL PROTECTED] > Sent: Monday, November 05, 2007 7:06 PM > To: Internet Area > Subject: Re: [Int-area] DCHP-based authentication for DSL? > > 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.
Right about the IP fragmentation issues; that is why it may be worth considering DHCP fragmentation. As Ric said, fragmentation may be a non-issue for specific use cases (e.g., the one that inspired the DHCP auth proposal) but if we wanted to extend to other use cases there may be instances in which path MTU restrictions play a role. One use case for consideration is Mobile Ad-hoc Networks. Fred [EMAIL PROTECTED] > 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 > _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
