Subject: Re: [dhcwg] [Int-area] dhcp-auth, part 2

From: "Alper Yegin" <[email-masked]>
Date: Mon, 28 Jul 2008 23:42:46 +0300

Here are the rest of my review comments on this latest version. 

-------------------

   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 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.

-------------------

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.

-------------------

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.

-------------------

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.

-------------------

How does DHCP satisfy the "orderly delivery" requirement imposed on the EAP
lower layers by RFC 3748?

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 (*).

Alper

Alper

> -----Original Message-----
> From: Alper Yegin [mailto:[email-masked]]
> Sent: Saturday, July 26, 2008 2:28 AM
> To: 'Richard Pruss'
> Cc: [email-masked]'; [email-masked]'
> 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-masked]
> > > https://www.ietf.org/mailman/listinfo/int-area

_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Richard Pruss <[email-masked]>
Date: Tue, 29 Jul 2008 09:01:58 +0100

> Here are the rest of my review comments on this latest version.

  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.

Their are drafts on key derivation from EAP to drive RFC 3118.

No actually DHCPFORCE in the Forced renw may have been the first to do  
this but so does Rebind in a way.
Ahh, what broke?  It seems to work.

Actually this is commonly deployed DHCP as I have pointed out in many  
messages.

I do not see reauth in the requirements.   If it was we could put a  
mechanism in to handle it.

Same as PPP.

> DHCPOFFER) -- hence not so regular anymore (*).

I made pretty much the same observation on Pana for DSL yesterday.

- Ric

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 29 Jul 2008 12:04:36 +0300

> 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.

> 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.

> Ahh, what broke?  It seems to work.

See above.

> Actually this is commonly deployed DHCP as I have pointed out in many

(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.

> 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.

> > lower layers by RFC 3748?

I don't think PPP and DHCP are the same protocol. I was asking how you
handle this. A technical response would be appreciated.

> 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

---

From: Richard Pruss <[email-masked]>
Date: Tue, 29 Jul 2008 10:43:27 +0100

> documentation/detailed description on that.

http://www3.tools.ietf.org/html/draft-salowey-dhc-eapkey-3118-00

> DHCPEA-REQ is not compliant with standard DHCP state machine.

You have also said that the proposal in effect pauses the state  
between the Discover and the Offer.
In implementation we seem to have had no problem understanding this  
pause.

> without proper IETF buy-in.

I am sorry but I do not buy that at all.  We have implementations that  
behave this way
and we now need to somehow pretend for your academic reasons that they  
do not exist?

> IPAuth-15	Must offer an option to re-authenticate periodically or on

Fine.  DHCPFORCE message can out the client into rebind and then  
reauth can be initiated from the client or
we can simply check the key.

> handle this. A technical response would be appreciated.
Technically there is no difference in terms of orderly delivery of EAP  
over PPPoE than EAP over DHCP.

> options, messages, changes to the state machines, etc.

And you propose a whole new protocol that is not supported on all the  
network devices in question.

- Ric

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 29 Jul 2008 13:07:55 +0300

> http://www3.tools.ietf.org/html/draft-salowey-dhc-eapkey-3118-00

There is a huge gap between what you are vaguely describing above and what
this I-D describes. You need to fill in that gap for us to understand how
this works.

> In implementation we seem to have had no problem understanding this

You can implement anything and make it work. That's not same as making it a
standard for the whole industry.

> and we now need to somehow pretend for your academic reasons that they

This is IETF, not me. Not everything that got implemented somewhere get the
free ticket to be rubber-stamped as an RFC. 

> we can simply check the key.

Please show us the detailed call flow.

> over PPPoE than EAP over DHCP.

You are not really answering the question. Does DHCP ensure orderly
delivery? If yes, please point out how (not by giving reference to other
protocols)? If not, then you have an additional problem to solve.

> network devices in question.

Yes, and that's a fair statement. On one side there is a brand new protocol
(RFC 5191) standardized by IETF specifically for this problem, and on the
other side there is a legacy protocol (DHCP) that has nothing to do with
"subscriber authentication" that needs to be extended beyond recognition
(effectively giving birth to a new protocol). I cannot wrap my head around
on how IETF would do such a thing.

Alper

---

From: Basavaraj Patil <[email-masked]>
Date: Tue, 29 Jul 2008 05:19:48 -0500

Hi Ric,

> network devices in question.

I hope you are not implying that with DHCP-auth there is no implication or
impact to hosts or network devices in question. What you are proposing is
essentially transforming DHCP into an entirely new protocol. You are just
riding on the DHCP coattails and expect EAP to get a free ride... But I
don't believe it is that simple.

-Raj

---

From: Richard Pruss <[email-masked]>
Date: Tue, 29 Jul 2008 14:47:50 +0100

> don't believe it is that simple.

Actually it is.  We have DHCP implementations integrated to subscriber  
control and RADIUS and we have EAP.
The gap to implementation of this is by design very small.

- Ric

>>>>>> terminating on the NAS (e.g., DHCPEAP*) and "others" going  
>>>>>> through
>>>>>> (e.g.,
>>>>>> IETF needs to buy in the DHCP proxy model before any other  
>>>>>> proposal
>>>>>> built
>>>>>> "box in the middle" inserting DHCP options towards the DHCP  
>>>>>> client
>>>>>> breaks
>>>>>> DHCP.
>>>>>>
>>>>>> Really? What happened to the escalation of this discussion to  
>>>>>> int-
>>>>>> area and

---

From: Richard Pruss <[email-masked]>
Date: Tue, 29 Jul 2008 18:31:27 +0100

On 29/07/2008, at 3:52 PM, Bernard Aboba wrote:

> > I am sorry but I do not buy that at all. We have implementations  
> that behave
> > this way and we now need to somehow pretend for your academic  
> reasons that they
> > do not exist?
>
> Is the question under discussion whether to document what has  
> already been implemented?
> If so, then discussion of the merits/demerits is indeed academic --  
> but so is discussion of
> adoption of the document as an IETF WG work item.  Just put the  
> documentation on a web
> site, or send it to the RFC Editor for publication as an Independent  
> Submission.
>
> Or is the question whether the document is an appropriate basis for  
> future work?  If so,
> then discussion of merits/demerits is not at all academic -- it is a  
> core issue.

This part of the thread was not about DHCP Authentication but the  
relay behaviour in broadband networks.  Basically current behaviour is  
to do a Radius Access Request on the DHCP discover and fill in  
information from the Access Response into the DHCP Offer.  Now in some  
cases IP address comes from the AAA server or the DHCP Discover is  
relayed to a DHCP server and then we have the situation that  
information from the Access Request can be "inserted" in at what is a  
type of a relay function and their was repeatedly expressed concern  
from Alper at that.

It has become clear to many folk that this is not written up in the  
IETF and in some conversations we had post this mornings WG meeting  
Peter Arberg from Redback has kindly offered to start a write it up  
from the DSL community so the behaviour of this function can be  
documented, independent of the fate of the Subscriber Authentication  
proposals.

- Ric