Re: [dhcwg] FW: New Version Notification for draft-brzozowski-dhcp-eap-analysis-00

["Alper Yegin" <alper.yegin at yegin.org>]

I was really wondering about the thoughts of the authors. Since they did the
analysis, they must have considered these points (which were already raised
on the mailing list).


> > - The role of NAS with respect to DHCP is unclear. For some part it
> is
> > acting as a DHCP relay, for others as a DHCP server (as it
> > terminates DHCP
> > messages and generates DHCP messages -- for EAP). Is the NAS playing
> > two
> > distinct DHCP roles within the same DHCP session? How well does that
> > fit
> > DHCP?
> 
> Yes, in Broadband the NAS can be a relay or a server at the operators
> choice.

At the same time for the same DHCP session? I don't think so. There is no
way (barring serious hacks) for a DHCP session be executed between one DHCP
client and multiple DHCP servers. [NAS acting as a relay for some DHCP
client for the duration of a DHCP session, and as a server for other clients
for the duration of a DHCP session is OK -- but that's not same as what is
in your I-D]

> > - NAS (acting as DHCP relay) is inserting DHCP options towards the
> > DHCP
> > client. I'm not aware of DHCP relays inserting options in that
> > direction. To
> > say the least, that breaks the end-to-end security, such as the one
> > using
> > RFC 3118.
> 
> Depends how the keying for RFC 3118 was implemented.  We have a draft
> as you are aware that has the NAS aware of the keys.

I am not aware of any draft that tries to secure this aforementioned broken
model. Please provide us a reference if there is any.

> > - " The client sends a Solicit message with an Option specifying the
> >   session authentication protocol as EAP to the
> >   All_DHCP_Relay_Agents_and_Servers address to find available DHCP
> >   servers.  Any server that can authenticate and address it responds
> >   with a DHCPEAP-REQ message."
> >
> > This is talking about a DHCP server sending a "request" to the DHCP
> > "client", quite the opposite of current DHCP architecture. How well
> > does
> > that fit the state machine?
> 
> Draw the diagram of what you are talking it is so trivially obvious, I
> fail to understand your question.

DHCP "server" sending "requests" is exactly the opposite of the current DHCP
architecture. I'd expect an analysis of impact on DHCP to take this into
account.

> > - According to EAP, the EAP authenticator has to be able to
> > retransmit EAP
> > requests. That means the NAS has to rexmit DHCPEAP-REQ to the DHCP
> > client
> > until it receives a DHCPEAP-RES. How does this fit "DHCP"?
> 
> As specified in the draft and now in multiple implementations.

Again, this does not fit the "clients sending requests in DHCP" model.
You have a server sending requests. Maybe you have a DHCP client in NAS?

> > - EAP re-authentication may be initiated by the network. How would
> > this be
> > handled?
> 
> Really?  Is it a requirement in broadband separate to re-addressing?

I'm talking about "re-authentication", not "re-addressing".
Every AAA architecture supports re-authentication. This is already supported
by the EAP, EAP methods, RADIUS, Diameter. It's an integral part of every
AAA design. You should be able to perform auth, re-auth, termination, etc.
You have to support that.

 
> > It requires the DHCP client to receive an unsolicited DHCP request
> > message from the NAS (a DHCP relay??). "DHCP client receiving a
> > request from
> > relay" sounds quite non-standard to me.
> 
> 
> 
> >
> > - Finally, I wonder how orderly delivery of EAP (as mandated by RFC
> > 3748) is
> > satisfied by this proposed EAP lower layer.
> 
> This is a boring academic point with no relevance to real networking,
> can simply be answered
> with the statement that there is no transport difference between EAP
> running over PPPoE,
> than their is with EAP running over DHCP on an Ethernet network.

This is not an answer. There is no big deal in here anyways. Just put a
sequence number in the EAP-encapsulating DHCP option and be done with it. 

Alper