This is an interesting workaround. However, if EAP/DHCP requires a temporal IP address and IP-in-IP encapsulation to operate, it would be very difficult for DSLF to claim that DHCP authentication is simple.
Yoshihiro Ohba On Tue, Oct 30, 2007 at 09:19:53AM -0700, Templin, Fred L wrote: > 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
