> > If multiple DHCP exchanges are occurring with multiple servers, both > > IPv4 and IPv6 each needs to authenticate separately. > > > > So, the same host needs to get authenticated twice if it is using > > both IPv4 > > and IPv6. This is a very unusual model for AAA. You need to update AAA > > servers to allow "double login." And with that, it is already > > violating the > > following requirement: > > > > IPAuth-2 Must re-use existing SP Authentication > > infrastructure (use > > Radius Database) and allow mixed mode operation (eg PPP and IP) on > > the same L3 edge device > > The RFC3118 authentication from one session could be used in the > other. > > e.g. do full DHCP + EAP for IPv4, get a key. Use the same key to sign > the DHCPv6 packets. The NAS has the key and the clients identity (MAC), > so all it has to do is lookup the MAC in it's table of allowed keys, > check the signature, and forward the packet if the signature is OK.
We need to see the details documented. It is hard to understand what it looks like reading the above paragraph. > Their are drafts on key derivation from EAP to drive RFC 3118. I know, we wrote the one long time ago. But I cannot immediately see how you use achieve what you are describing above. Again, let's see some documentation/detailed description on that. > > ------------------- > > > > > > The client sends a DHCP Discover > > message with an option specifying the authentication protocol as EAP > > to find an available DHCP server. Any server that can that can > > authenticate and address it responds with a DHCPEAP-REQ message. > > > > A "DHCP server" sending a "request" to the "DHCP client"? This is so > > not-DHCP. Current DHCP state machine does not allow that. So, > > basically you > > are making a very significant change to the DHCP. > > > No actually DHCPFORCE in the Forced renw may have been the first to do > this but so does Rebind in a way. What I'm saying is, DHCP client sending out a DHCPDISCOVER and receiving a DHCPEA-REQ is not compliant with standard DHCP state machine. > > ------------------- > > > > I-D allows the DHCP server to respond to DHCPDISCOVER with "DHCPEAP- > > REQ" -- > > a brand new message (a request) sent in response. Again, breaking > > the state > > machine and effectively inventing a totally new protocol that does > > not look > > like DHCP anymore. > Ahh, what broke? It seems to work. See above. > > ------------------- > > > > In Figure 3, it seems like there is one DHCP client and two DHCP > > servers. > > Within the same DHCP flow, some messages are responded by one > > server, some > > by the other. This is certainly not standard DHCP. > > > > Actually this is commonly deployed DHCP as I have pointed out in many > messages. (Again) Please point to a IETF document that describes this. There is a whole lot of stuff happening out there, I don't think we can take them as-is without proper IETF buy-in. > > > ------------------- > > > > > > How is EAP-reauth initiated by the network is handled? The DHCP > > client needs > > to receive an unsolicited DHCP request from the DHCP server out of > > blue. > > This does not look like standard DHCP at all. > > > > I do not see reauth in the requirements. If it was we could put a > mechanism in to handle it. It's not only a standard EAP behavior that needs to be accommodated, but also explicitly stated in the requirements: IPAuth-15 Must offer an option to re-authenticate periodically or on demand. > > ------------------- > > > > How does DHCP satisfy the "orderly delivery" requirement imposed on > > the EAP > > lower layers by RFC 3748? > > > > > > Same as PPP. I don't think PPP and DHCP are the same protocol. I was asking how you handle this. A technical response would be appreciated. > > An overall observation: > > > > If we step back and look at the call flows, it is apparent that an EAP > > call-flow is wedged into regular(*) DHCP call-flow, which freezes at > > some > > point and resumes later. The wedged-in part is so different than > > DHCP, I > > don't understand the value of using DHCP as the transport for that > > part (why > > bother having such an impact on DHCP to the extent that it looks > > like a new > > protocol?). But worse than that, the wedged-in part also leaks into > > the > > regular DHCP call-flow (see how EAP Success/Failure gets transported > > over > > DHCPOFFER) -- hence not so regular anymore (*). > > > > I made pretty much the same observation on Pana for DSL yesterday. Nope. There is no modification to DHCP at all when PANA is used. No new DHCP options, messages, changes to the state machines, etc. Alper > > - Ric > > > > Alper > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Alper > > > >> -----Original Message----- > >> From: Alper Yegin [mailto:[EMAIL PROTECTED] > >> Sent: Saturday, July 26, 2008 2:28 AM > >> To: 'Richard Pruss' > >> Cc: '[email protected]'; '[EMAIL PROTECTED]' > >> Subject: RE: [Int-area] dhcp-auth > >> > >> I don't appreciate your comments. Let's stay on the technical course. > >> > >>>> Let's start just looking at the issues about Figure 3... > >>>> > >>>> - What is the DHCP-wise functionality of the NAS? Text claims it is > >>>> a "DHCP > >>>> relay" but I see it terminating some of the DHCP messages and also > >>>> generating some other messages. This is not compliant with DHCP. > >>>> > >>> > >>> As we explained to you many times most vendors BRAS's act as a DHCP > >>> proxy and terminate all messages and look like a server to the > >>> client. > >> > >> > >> That's not accurate according to Figure 3. I see "some" DHCP messages > >> terminating on the NAS (e.g., DHCPEAP*) and "others" going through > >> (e.g., > >> DHCPDISCOVER) within the same DHCP flow. > >> > >> I don't think it is as simple as your two-sentence explanation > >> anyways. As > >> requested earlier, IETF needs to see a document where this DHCP proxy > >> model is defined. I'm aware of one DHCP proxy model and it is > >> nothing like > >> what your document is suggesting. > >> > >> Can you please send us a document that describes the DHCP proxy > >> model? > >> IETF needs to buy in the DHCP proxy model before any other proposal > >> built > >> on top of that gets accepted. > >> > >> > >>>> - How does the NAS handle EAP retransmissions? It needs to send > >>>> unsolicited > >>>> DHCP messages to the DHCP client. This is not compliant with DHCP. > >>>> > >>> Actually that issue is open and we can discuss what a compliant > >>> implementation would mean in terms of retransmission timers so that > >>> right thing always happens at the right layer. > >> > >> OK, please explain. > >> > >> > >>>> - I see NAS inserting additional DHCP option (EAP Success) on > >>>> DHCPOFFER as > >>>> it forwards that message from DHCP server to DHCP client. This > >>>> again > >>>> breaks > >>>> DHCP. > >>>> > >>> As we explained to you many times most vendors BRAS's act as a DHCP > >>> proxy and terminate all messages and look like a server to the > >>> client. > >> > >> Again, NAS does not really terminate "all" messages (see above). > >> And this > >> "box in the middle" inserting DHCP options towards the DHCP client > >> breaks > >> DHCP. > >> > >>> Lets take this to the dhcwg list as that is where the review happens > >>> next week. > >> > >> Really? What happened to the escalation of this discussion to int- > >> area and > >> the outcome of the poll from last IETF? I hope Jari can clarify this. > >> > >> Alper > >> > >> > >> > >> > >> > >> > >> > >>> > >>> - Ric > >>> > >>> > >>> > >>>> > >>>> Alper > >>>> > >>>> > >>>> _______________________________________________ > >>>> Int-area mailing list > >>>> [email protected] > >>>> https://www.ietf.org/mailman/listinfo/int-area > > > > _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
