> 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.
It's just a proposal, and I haven't studied the problem (if there is one) in detail. But, I don't agree wrt the simplicity aspect. Fred [EMAIL PROTECTED] > 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
