If I understand the situation correctly (fragmentation needed with packets having 0.0.0.0 source address), a potential mitigation is through the use of IP-in-IP encapsulation and RFC3927 link local addresses. A DHCP/EAP client which does not yet have an address can then wrap its DHCP messages in an inner IP header with an RFC3927 source address and an outer IP header with a source address of 0.0.0.0. Both the inner and outer destination address would be that of the DHCP/EAP server.
During the encapsulation, the client can fragment the inner DHCP message into inner IP fragments no larger than the path MTU minus 20 bytes, then encapsulate each inner fragment in an outer IP header with DF=1. In this sense, the RFC3927 address is still a link-local, because the tunnel between the client and the server is just an ordinary link from IP's perspective. There is a potential for collision in the server's reassembly cache with other clients choosing the same link-local address, however the inner ip-id can be used for further differentiation. In the event of collision in both the ip-src and ip-id planes, the UDP checksum is available to detect reassembly corruption and the sprite-mtu checksum (draft-templin-inetmtu-05) could also be used if an additional and complementary check is desired. Or, maybe I am misunderstanding the situation? Fred [EMAIL PROTECTED] > -----Original Message----- > From: Yoshihiro Ohba [mailto:[EMAIL PROTECTED] > Sent: Monday, October 29, 2007 4:43 AM > To: Ralph Droms > Cc: Internet Area > Subject: Re: [Int-area] DCHP-based authentication for DSL? > > On Sun, Oct 28, 2007 at 04:22:27PM -0400, Ralph Droms wrote: > > The only reference to fragmentation in RFC 951 is: > > > > 3. Packet Format > > > > [...] For > > simplicity it is assumed that the BOOTP packet is never > fragmented. > > > > There are no references to fragmentation in RFC 213[12] or RFC 3315. > > > > In my opinion, this reference is to simplicity in the IP > layer, not > > in the BOOTP layer. The IP layer handles any fragmentation > and the > > BOOTP/DHCP layers are unaware of that fragmentation. > Therefore, any > > addresses included in the DHCP messages are irrelevant to > BOOTP/DHCP > > message reassembly. > > I don't think IP layer can correctly reassemble IP datagrams with the > unspecified source address (0.0.0.0) which breaks uniqueness of > fragments among multiple *different* source nodes. > > > > > On the other hand, as I wrote in a previous message, all > bets are off > > regarding L2 (or other) devices that snoop the DHCP > messages without > > performing IP reassembly. > > Sure, this is another issue. > > > > > And, as a practical matter, I suspect all extant DHCP clients and > > servers have a DHCP message MTU less than 1500 octets. > > For the above reasons, DHCP message should not be IP-fragmented. > However, DHCP message MTU being not more than link-layer MTU can be a > non-workable requirement when carrying EAP, considering the fact that > EAP can consume up to 1020 octets and additionally other options need > to be carried in a DHCP message. > > Yoshihiro Ohba > > > > > > - Ralph > > > > > > On Oct 25, 2007, at Oct 25, 2007,8:28 PM, Yoshihiro Ohba wrote: > > > > >Isn't DHCP designed based on the same assumption as BOOTP > in terms of > > >IP fragmentation? BOOTP assumes that BOOTP messages are never > > >fragmented according RFC 951. > > > > > >An issue with fragmenting DHCP message I can think of is > that a DHCP > > >relay agent or server may not be able to correctly reassemble > > >fragmented messages when simultaneously received from multiple DHCP > > >clients if the source address of those messages is unspecified > > >(0.0.0.0). How does DHCP address this issue? > > > > > >Note: DHCPv6 does not have this issue because a specified > address is > > >always used. > > > > > >Yoshihiro Ohba > > > > > > > > >On Wed, Oct 24, 2007 at 05:03:01PM -0400, Ralph Droms wrote: > > >>Sorry, I made a goof. Relay agents can forward fragmented DHCP > > >>messages. There is, if I recall correctly, a > recommendation against > > >>fragmentation (perhaps RFC 2131); however, the stack on the node > > >>where the relay agent is instantiated will re-assemble the DHCP > > >>message before delivering it to the relay agent, and then > re-fragment > > >>the new DHCP message resent by the relay agent. > > >> > > >>- Ralph > > >> > > >>On Oct 24, 2007, at Oct 24, 2007,4:54 PM, Ralph Droms wrote: > > >> > > >>>Section 6.3 of draft-pruss-dhcp-auth-dsl-01 addresses how to fit > > >>>the EAP info into DHCP options, using RFC 3396. > > >>> > > >>>However, there is also a recommendation, when using EAP, that the > > >>>server set the "Maximum DHCP Message Size" option to > 1604. Sending > > >>>a DHCP message of this size may require fragmentation, but DHCP > > >>>relay agents cannot forward fragmented DHCP messages. > > >>> > > >>>- Ralph > > >>> > > >>>On Oct 24, 2007, at Oct 24, 2007,4:36 PM, Richard Pruss wrote: > > >>> > > >>>> > > >>>> > > >>>>Stig Venaas wrote, around 24/10/07 7:23 PM: > > >>>>>It's not as simple as just putting credentials into option 82 > > >>>>>though. > > >>>>>For one thing there are strict limits on the size of DHCP > > >>>>>messages that > > >>>>>will limit what EAP or other mechanisms you can use. > When the EAP > > >>>>>MTU is too small for the EAP message, you need multiple > > >>>>>requests and > > >>>>>responses to transport the message. This is not > possible without > > >>>>>major DHCP changes. Hence you are not free to use what EAP > > >>>>>mechanisms > > >>>>>or credentials you like without major changes to DHCP. > While with > > >>>>>say > > >>>>>PANA you could do that. > > >>>>> > > >>>>Stig section 6.3 of the currently posted -01 draft addresses the > > >>>>size issue of EAP in some detail, it is not clear if you are > > >>>>saying the proposed mechanism would not work. > > >>>> > > >>>>Regardless of the mechanism if one thinks of this from the > > >>>>implementation it should be no big deal as for EAP and > RADIUS one > > >>>>has to chop EAP into small enough chunks to get through > > >>>>limitations in RADIUS (<253 bytes). While DHCP has similar > > >>>>problems (<255 bytes), and one could can expect that most > > >>>>networking companies would have implemented the lower common > > >>>>denominator of RADIUS here. > > >>>> > > >>>>Regards, > > >>>>Ric > > >>>> > > >>>> > > >>>> > > >>>> > > >>>>_______________________________________________ > > >>>>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 > > >> > > > > > _______________________________________________ > 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
