Subject: [dhcwg] Comments on draft-pruss-dhcp-auth-dsl-06 and draft-brzozowski-dhcp-eap-analysis-00

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 26 Jul 2009 18:13:21 -0400

I have read both documents. Thanks for the authors for both documents 
providing techinical details.

However, I still have an issue with carrying EAP over DHCP. The issue is 
basically a conflict between statefullness of EAP and statelessness of 
DHCP relay agent.

As far as I understand, DHCP relay agent does not maintain a state. On 
the other hand, EAP requires peer and authenticator to maintain a state 
(see RFC 4137). When DHCP relay agent acts EAP authenticator, then the 
relay agent will be no longer a stateless DHCP entity. I think this is 
not discussed in dhcp-eap-analysis draft. Is this an acceptable design 
change for DHCP?  Or please correct me if I am wrong.

Regards,
Yoshihiro Ohba

---

From: Richard Pruss <[email-masked]>
Date: Mon, 27 Jul 2009 15:55:27 +1000

Relay's in the broadband architecture have to be stateful to enforce  
DHCP address assignment, so it is not a change to the existing  
architecture.

- Ric

On 27/07/2009, at 8:13 AM, Yoshihiro Ohba wrote:

> I have read both documents. Thanks for the authors for both  
> documents providing techinical details.
>
> However, I still have an issue with carrying EAP over DHCP. The  
> issue is basically a conflict between statefullness of EAP and  
> statelessness of DHCP relay agent.
>
> As far as I understand, DHCP relay agent does not maintain a state.  
> On the other hand, EAP requires peer and authenticator to maintain a  
> state (see RFC 4137). When DHCP relay agent acts EAP authenticator,  
> then the relay agent will be no longer a stateless DHCP entity. I  
> think this is not discussed in dhcp-eap-analysis draft. Is this an  
> acceptable design change for DHCP?  Or please correct me if I am  
> wrong.
>
> Regards,
> Yoshihiro Ohba
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 27 Jul 2009 02:55:15 -0400

> DHCP address assignment, so it is not a change to the existing 
As far as I understand, enforcing DHCP address assignment is needed 
*after* DHCP exchanges are done, and therefore the state is maintained 
outside the context of DHCP, which I don't care.  My comment was if DHCP 
relay needs to be stateful in the middle of DHCP exchanges to carry EAP.
 From DHCP point of view, it seems to be a major design change to DHCP.

Regards,
Yoshihiro Ohba

>> However, I still have an issue with carrying EAP over DHCP. The issue 
>> is basically a conflict between statefullness of EAP and 
>> acceptable design change for DHCP?  Or please correct me if I am wrong.
>>
>> Regards,
>> Yoshihiro Ohba

---

From: Richard Pruss <[email-masked]>
Date: Mon, 27 Jul 2009 17:04:00 +1000

On 27/07/2009, at 4:55 PM, Yoshihiro Ohba wrote:

> Richard Pruss wrote:
>> Relay's in the broadband architecture have to be stateful to  
>> enforce DHCP address assignment, so it is not a change to the  
>> existing architecture.
> *after* DHCP exchanges are done, and therefore the state is  
> maintained outside the context of DHCP, which I don't care.  My  
> comment was if DHCP relay needs to be stateful in the middle of DHCP  
> exchanges to carry EAP.

Do you actually have an implementation of broadband DHCP relay  
because  what you are talking makes very little sense?

- Ric

>>> As far as I understand, DHCP relay agent does not maintain a  
>>> state. On the other hand, EAP requires peer and authenticator to  
>>> maintain a state (see RFC 4137). When DHCP relay agent acts EAP  
>>> authenticator, then the relay agent will be no longer a stateless  
>>> DHCP entity. I think this is not discussed in dhcp-eap-analysis  
>>> draft. Is this an acceptable design change for DHCP?  Or please  
>>> correct me if I am wrong.
>>>
>>> Regards,
>>> Yoshihiro Ohba

---

From: Ralph Droms <[email-masked]>
Date: Mon, 27 Jul 2009 09:26:05 +0200

Ric - the question seems sensible to me.

I would consider enforcing the address assignment as a separate  
function of the box that happens to house the DHCP relay agent  
function.  That is, the relay agent extracts the assigned address from  
the DHCPACK and hands it to the address enforcement function.   
Therefore, the relay agent function is not keeping any state.  The  
address enforcement function could just as easily get that address  
assignment information from some other source like CLI or SNMP.

The original purpose of the relay agent option was to hold state for  
the relay agent.  We've tried to maintain that stateless operation  
(but I'm not sure we've strictly enforced the rule) with the  
definition of subsequent relay agent options.

- Ralph

On Jul 27, 2009, at 9:04 AM 7/27/09, Richard Pruss wrote:

>> comment was if DHCP relay needs to be stateful in the middle of  
>> DHCP exchanges to carry EAP.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 27 Jul 2009 00:27:05 -0700

On Sunday, July 26, 2009 10:55 PM, =Richard Pruss wrote"====
> Relays in the broadband architecture have to be stateful to enforce

Ric, unless I am horribly out of touch with the state of the art (always a possibilty), this statement is not in fact true.   It seems that either you are using "relay agent" as a shorthand for something that's more than a relay agent, or else you failed to sufficiently constrain the set of situations in which your statement applies.   It's true that *caching* state is common in relays in a broadband environment, but that doesn't make those relays "stateful" in the usual sense that we mean.

---

From: Richard Pruss <[email-masked]>
Date: Mon, 27 Jul 2009 17:39:21 +1000

Well Ralph,  as you say something else is holding the state and the  
relay agent is simply handing the EAP messages to the AAA  service in  
the relay function... so no the question still makes no sense to me.

The thing that makes no sense is the assertion that the relay agent  
suddenly needs to hold state, beyond what it already does to handle ip  
unnumbered interfaces,
Ric

On 27/07/2009, at 5:26 PM, Ralph Droms wrote:

> function.  That is, the relay agent extracts the assigned address  
> from the DHCPACK and hands it to the address enforcement function.   
>>> As far as I understand, enforcing DHCP address assignment is  
>>> needed *after* DHCP exchanges are done, and therefore the state is  
>>>>> authenticator, then the relay agent will be no longer a  
>>>>> stateless DHCP entity. I think this is not discussed in dhcp-eap- 
>>>>> analysis draft. Is this an acceptable design change for DHCP?   
>>>>> Or please correct me if I am wrong.
>>>>>
>>>>> Regards,
>>>>> Yoshihiro Ohba

---

From: Richard Pruss <[email-masked]>
Date: Mon, 27 Jul 2009 17:40:16 +1000

On 27/07/2009, at 5:27 PM, Ted Lemon wrote:

> Ric, unless I am horribly out of touch with the state of the art  
> (always a possibilty), this statement is not in fact true.   It  
> seems that either you are using "relay agent" as a shorthand for  
> something that's more than a relay agent, or else you failed to  
> sufficiently constrain the set of situations in which your statement  
> applies.   It's true that *caching* state is common in relays in a  
> broadband environment, but that doesn't make those relays "stateful"  
> in the usual sense that we mean.

Okay I worded that badly the BRAS is state-full for the session, not  
necessarily DHCP relay function in the BRAS,
Ric

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 27 Jul 2009 03:50:44 -0400

> the relay function... so no the question still makes no sense to me.
This is an incorrect statement. DHCP relay acting EAP authenticator is 
not simply handing EAP messages to the AAA, it needs to maintain a state 
including a retransmission timer to retransmit outstanding EAP-Request 
message (cf. RFC 4137).

Yoshihiro Ohba

---

From: Richard Pruss <[email-masked]>
Date: Mon, 27 Jul 2009 17:53:39 +1000

On 27/07/2009, at 5:50 PM, Yoshihiro Ohba wrote:

>> relay agent is simply handing the EAP messages to the AAA  service  
>> in the relay function... so no the question still makes no sense to  
>> me.
> This is an incorrect statement. DHCP relay acting EAP authenticator  
> is not simply handing EAP messages to the AAA, it needs to maintain  
> a state including a retransmission timer to retransmit outstanding  
> EAP-Request message (cf. RFC 4137).

No mate this is the part you probably missed, EAP is doing that and it  
is a separate function regardless of what it is being carried on ,  
PPP, Ethernet, DHCP here is just transport.

- Ric

>> suddenly needs to hold state, beyond what it already does to handle  
>> ip unnumbered interfaces,
>> Ric
>>
>>> from the DHCPACK and hands it to the address enforcement  
>>> function.  Therefore, the relay agent function is not keeping any  
>>> state.  The address enforcement function could just as easily get  
>>> that address assignment information from some other source like  
>>> CLI or SNMP.
>>>
>>> The original purpose of the relay agent option was to hold state  
>>> for the relay agent.  We've tried to maintain that stateless  
>>> operation (but I'm not sure we've strictly enforced the rule) with  
>>> the definition of subsequent relay agent options.
>>>
>>> - Ralph
>>>
>>>>> needed *after* DHCP exchanges are done, and therefore the state  
>>>>> is maintained outside the context of DHCP, which I don't care.   
>>>>> My comment was if DHCP relay needs to be stateful in the middle  
>>>>> of DHCP exchanges to carry EAP.
>>>>>>> However, I still have an issue with carrying EAP over DHCP.  
>>>>>>> The issue is basically a conflict between statefullness of EAP  
>>>>>>> and statelessness of DHCP relay agent.
>>>>>>>
>>>>>>> state. On the other hand, EAP requires peer and authenticator  
>>>>>>> to maintain a state (see RFC 4137). When DHCP relay agent acts  
>>>>>>> EAP authenticator, then the relay agent will be no longer a  
>>>>>>> stateless DHCP entity. I think this is not discussed in dhcp- 
>>>>>>> eap-analysis draft. Is this an acceptable design change for  
>>>>>>> DHCP?  Or please correct me if I am wrong.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 27 Jul 2009 03:59:25 -0400

Richard Pruss wrote:
>>> in the relay function... so no the question still makes no sense to me.
>> is not simply handing EAP messages to the AAA, it needs to maintain a 
>> state including a retransmission timer to retransmit outstanding 

All EAP transport protocols that I know of, including the ones you 
listed above requires to maintain a state to carry EAP message.  There 
is no exception.

Yoshihiro Ohba

>>>>>>>> stateless DHCP entity. I think this is not discussed in 
>>>>>>>> dhcp-eap-analysis draft. Is this an acceptable design change 
>>>>>>>> for DHCP?  Or please correct me if I am wrong.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Yoshihiro Ohba

---

From: Richard Pruss <[email-masked]>
Date: Mon, 27 Jul 2009 18:10:44 +1000

On 27/07/2009, at 5:59 PM, Yoshihiro Ohba wrote:

>>>> Well Ralph,  as you say something else is holding the state and  
>>>> the relay agent is simply handing the EAP messages to the AAA   
>>>> service in the relay function... so no the question still makes  
>>>> no sense to me.
>>> This is an incorrect statement. DHCP relay acting EAP  
>>> authenticator is not simply handing EAP messages to the AAA, it  
>>> needs to maintain a state including a retransmission timer to  
>>> retransmit outstanding EAP-Request message (cf. RFC 4137).
>>
>> No mate this is the part you probably missed, EAP is doing that and  
>> it is a separate function regardless of what it is being carried  
>> on , PPP, Ethernet, DHCP here is just transport.
>
> listed above requires to maintain a state to carry EAP message.   
> There is no exception.
What state?

>
> Yoshihiro Ohba
>
>
>>
>> - Ric
>>
>>
>>>
>>> Yoshihiro Ohba
>>>
>>>>
>>>>
>>>> The thing that makes no sense is the assertion that the relay  
>>>> agent suddenly needs to hold state, beyond what it already does  
>>>> to handle ip unnumbered interfaces,
>>>> Ric
>>>>
>>>>> function.  That is, the relay agent extracts the assigned  
>>>>> address from the DHCPACK and hands it to the address enforcement  
>>>>> function.  Therefore, the relay agent function is not keeping  
>>>>> any state.  The address enforcement function could just as  
>>>>> easily get that address assignment information from some other  
>>>>> source like CLI or SNMP.
>>>>>
>>>>> operation (but I'm not sure we've strictly enforced the rule)  
>>>>> with the definition of subsequent relay agent options.
>>>>>
>>>>> - Ralph
>>>>>
>>>>>>> needed *after* DHCP exchanges are done, and therefore the  
>>>>>>> state is maintained outside the context of DHCP, which I don't  
>>>>>>> care.  My comment was if DHCP relay needs to be stateful in  
>>>>>>> the middle of DHCP exchanges to carry EAP.
>>>>>>>>> The issue is basically a conflict between statefullness of  
>>>>>>>>> EAP and statelessness of DHCP relay agent.
>>>>>>>>>
>>>>>>>>> state. On the other hand, EAP requires peer and  
>>>>>>>>> authenticator to maintain a state (see RFC 4137). When DHCP  
>>>>>>>>> relay agent acts EAP authenticator, then the relay agent  
>>>>>>>>> will be no longer a stateless DHCP entity. I think this is  
>>>>>>>>> not discussed in dhcp-eap-analysis draft. Is this an

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 27 Jul 2009 04:42:02 -0400

In general, a state on the logical connection between the peer and 
authenticator needs to be maintained by any EAP lower-layer for each EAP 
conversation. Such a state at least includes transport addresses and/or 
port numbers and they are not carried in EAP message.

Yoshihiro Ohba

Richard Pruss wrote:
>>>>> service in the relay function... so no the question still makes no 
>>>>> sense to me.
>>> it is a separate function regardless of what it is being carried on 
>>> , PPP, Ethernet, DHCP here is just transport.
>>
>>>>> agent suddenly needs to hold state, beyond what it already does to 
>>>>> handle ip unnumbered interfaces,
>>>>> Ric
>>>>>
>>>>>>>>>> to maintain a state (see RFC 4137). When DHCP relay agent 
>>>>>>>>>> acts EAP authenticator, then the relay agent will be no 
>>>>>>>>>> longer a stateless DHCP entity. I think this is not discussed 
>>>>>>>>>> in dhcp-eap-analysis draft. Is this an acceptable design

---

From: Ralph Droms <[email-masked]>
Date: Mon, 27 Jul 2009 10:47:32 +0200

Ric - my understanding is that the relay agent would have to hold  
state, including the original message from the DHCP client, for each  
of the outstanding message exchanges that have been handed off to the  
EAP function.

I suppose the relay agent could discard the original message and rely  
on the client to retransmit after the EAP-over-DHCP exchange...

- Ralph

---

From: Richard Pruss <[email-masked]>
Date: Mon, 27 Jul 2009 19:27:19 +1000

As I said to Ralph earlier we track transport and port associations  
already to facilitate unnumbered interfaces, so the question was what  
state beyond that.

On 27/07/2009, at 6:42 PM, Yoshihiro Ohba wrote:

> authenticator needs to be maintained by any EAP lower-layer for each  
> EAP conversation. Such a state at least includes transport addresses  
> and/or port numbers and they are not carried in EAP message.
>
> Yoshihiro Ohba
>
>
> Richard Pruss wrote:
>>
>>>> No mate this is the part you probably missed, EAP is doing that  
>>>> and it is a separate function regardless of what it is being  
>>>> carried on , PPP, Ethernet, DHCP here is just transport.
>>>
>>>>>>> I would consider enforcing the address assignment as a  
>>>>>>> separate function of the box that happens to house the DHCP  
>>>>>>> relay agent function.  That is, the relay agent extracts the  
>>>>>>> assigned address from the DHCPACK and hands it to the address  
>>>>>>> enforcement function.  Therefore, the relay agent function is  
>>>>>>> not keeping any state.  The address enforcement function could  
>>>>>>> just as easily get that address assignment information from  
>>>>>>> some other source like CLI or SNMP.
>>>>>>>
>>>>>>> The original purpose of the relay agent option was to hold  
>>>>>>> state for the relay agent.  We've tried to maintain that  
>>>>>>> stateless operation (but I'm not sure we've strictly enforced  
>>>>>>> the rule) with the definition of subsequent relay agent options.
>>>>>>>
>>>>>>> - Ralph
>>>>>>>
>>>>>>>>>> Relay's in the broadband architecture have to be stateful  
>>>>>>>>>> to enforce DHCP address assignment, so it is not a change  
>>>>>>>>>> to the existing architecture.
>>>>>>>>> state is maintained outside the context of DHCP, which I  
>>>>>>>>> don't care.  My comment was if DHCP relay needs to be  
>>>>>>>>> stateful in the middle of DHCP exchanges to carry EAP.
>>>>>>>> Do you actually have an implementation of broadband DHCP  
>>>>>>>> relay because  what you are talking makes very little sense?
>>>>>>>>
>>>>>>>> - Ric
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Yoshihiro Ohba
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> - Ric
>>>>>>>>>>
>>>>>>>>>>> I have read both documents. Thanks for the authors for  
>>>>>>>>>>> both documents providing techinical details.
>>>>>>>>>>>
>>>>>>>>>>> However, I still have an issue with carrying EAP over  
>>>>>>>>>>> DHCP. The issue is basically a conflict between  
>>>>>>>>>>> statefullness of EAP and statelessness of DHCP relay agent.
>>>>>>>>>>>
>>>>>>>>>>> As far as I understand, DHCP relay agent does not maintain  
>>>>>>>>>>> a state. On the other hand, EAP requires peer and  
>>>>>>>>>>> authenticator to maintain a state (see RFC 4137). When  
>>>>>>>>>>> DHCP relay agent acts EAP authenticator, then the relay  
>>>>>>>>>>> agent will be no longer a stateless DHCP entity. I think  
>>>>>>>>>>> this is not discussed in dhcp-eap-analysis draft. Is this  
>>>>>>>>>>> an acceptable design change for DHCP?  Or please correct  
>>>>>>>>>>> me if I am wrong.
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Yoshihiro Ohba

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 27 Jul 2009 18:02:44 +0300

Your DHCP relay, now that it wants to be an EAP lower-layer, has to keep
track of the EAP sessions. For each EAP session, it has to know the
associated DHCP session and AAA (RADIUS, Diameter) session. If you wonder
why so, think of how would the DHCP relay know which host to transmit the
EAP request to when it receives an EAP request from AAA client
implementation? The same "mapping" issue arises for the EAP responses that
are bridged from the EAP peer side to the authentication server side by the
DHCP relay implementation. 

Aside from having to deal with "handles" needed for demultiplexing, sooner
or later key derivation will be needed by the BBF (e.g., for securing DHCP,
L2, etc.) and MSK will also be stored by the EAP lower-layer -- namely your
DHCP relay.

Alper

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Richard Pruss
> Sent: Monday, July 27, 2009 12:27 PM
> To: Yoshihiro Ohba
> Cc: dhc WG; Ralph Droms
> Subject: Re: [dhcwg] Comments on draft-pruss-dhcp-auth-dsl-06 and
> draft-brzozowski-dhcp-eap-analysis-00
>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 27 Jul 2009 11:29:39 -0400

> already to facilitate unnumbered interfaces, so the question was what 
Beyond that each EAP conversation needs to be mapped to a distinct 
transport and port association, which will require a state maintained by 
DHCP relay.

Yoshihiro Ohba

>>>>>>>> address from the DHCPACK and hands it to the address 
>>>>>>>>>>> enforce DHCP address assignment, so it is not a change to 
>>>>>>>>>>> the existing architecture.

---

From: "MILES DAVID" <[email-masked]>
Date: Tue, 28 Jul 2009 07:53:19 +0800

I wish to ask a question for clarification.

I understood the proposal in draft-pruss-auth-dsl was that the DHCP
client was in fact also the EAP supplicant. There is no EAPoL or 802.1x
device. The DHCP relay is not performing a EAPoL/802.1x to DHCP
conversion.

While the EAP/DHCP client on Home Gateway and Server will need to be
aware/stateful with respect to EAP why would this extend to a DHCP
relay? Is this not similar to the case of EAP-Message over RADIUS? A
RADIUS proxy does not need to be aware of the details of the EAP-Message
nor be able to decode them.

In the proposed DHCP message exchange of DISCOVER, DHCPEAP, DHCPOFFER,
ACK I see no requirement for a stateful DHCP relay to support DHCPEAP.
As with other DHCP relayed messages there is sufficient information in
the response ( contains chaddr (IPv4) or peer address (IPv6 relay))
received from the DHCP server to forward this message to the Home
Gateway (operating as DHCP client and EAP supplicant).

d

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Yoshihiro Ohba
Sent: Tuesday, July 28, 2009 1:00 AM
To: Richard Pruss
Cc: dhc WG; Ralph Droms
Subject: Re: [dhcwg] Comments on draft-pruss-dhcp-auth-dsl-06 and
draft-brzozowski-dhcp-eap-analysis-00

DHCP relay.

Yoshihiro Ohba

>>>>>>>>>> >From DHCP point of view, it seems to be a major design
change 
>>>>>>>>>> to DHCP.

>>>>>>>>>>>> acceptable design change for DHCP?  Or please correct me if

>>>>>>>>>>>> I am wrong.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 27 Jul 2009 20:27:08 -0400

> device. The DHCP relay is not performing a EAPoL/802.1x to DHCP
DHCP relay is running EAP acting as an EAP authenticator.
> nor be able to decode them.
The difference from RADIUS proxy is that the RADIUS proxy is not running 
EAP.
> ACK I see no requirement for a stateful DHCP relay to support DHCPEAP.
Why? As I commented above, DHCP relay is running EAP acting as an EAP 
authenticator, which will require lower-layer (in this case DHCP relay) 
to maintain a state.
> Gateway (operating as DHCP client and EAP supplicant).
In Figure 3 of draft-pruss, DHCPEAP message does not come from or go to 
the DHCP server.
The DHCP relay in draft-pruss is not relaying DHCPEAP message between 
DHCP client and DHCP server.

Yoshihiro Ohba

>>>>>>>>> the rule) with the definition of subsequent relay agent
>>>>>>>>>                   
> options.
>   
>>>>>>>>> - Ralph
>>>>>>>>>

---

From: "MILES DAVID" <[email-masked]>
Date: Tue, 28 Jul 2009 09:17:00 +0800

I had not realized you were referring to Figure 3 - I was referring to a
DHCP relay that may be between the NAS and the client such as those
described as L2 DHCP relays and present in an access node/DSLAM, etc. I
apologies for creating any further confusion there.

If there were a bootp relay or l2 DHCP relay between the NAS and HGW in
figure 2 - it would not need to be stateful. Also, if the NAS were not
forking EAP/RADIUS (it was a "classical" bootp/DHCP relay) it would not
need to have new state tables for DHCPEAP.

Figure 3 describes something that is not well-described as a DHCP relay
IMO (which may be your point as well). I would agree that there is state
in this device by its nature and that having a forked EAP and it is a
EAP authenticator. 

I am interested in the example of figure 2 and less interested in the
deployment model of figure 3. Could it be an option to remove the
split/forked EAP/RADIUS deployment model (which seems to be causing
concern) and look at the model in figure 2?

Thanks

-David

-----Original Message-----
From: Yoshihiro Ohba [mailto:[email-masked]] 
Sent: Tuesday, July 28, 2009 9:57 AM
To: MILES DAVID
Cc: Richard Pruss; dhc WG; Ralph Droms
Subject: Re: [dhcwg] Comments on draft-pruss-dhcp-auth-dsl-06 and

EAP.

Yoshihiro Ohba

>>>>>>>>> I would consider enforcing the address assignment as a
separate

>>>>>>>>>>>> Relay's in the broadband architecture have to be stateful
to

>>>>>>>>>> Do you actually have an implementation of broadband DHCP
relay
>>>>>>>>>>>>> I have read both documents. Thanks for the authors for
both
>>>>>>>>>>>>> However, I still have an issue with carrying EAP over
DHCP.

>>>>>>>>>>>>> authenticator to maintain a state (see RFC 4137). When
DHCP

---

From: Richard Pruss <[email-masked]>
Date: Tue, 28 Jul 2009 11:23:43 +1000

I agree with you David, most of the vendors have called that a proxy  
function in our documentation
and it well pre-dates the Auth proposal, I think it originally evolved  
to provide DHCP with a addresses
and other details from AAA.

- Ric

---

From: Richard Pruss <[email-masked]>
Date: Tue, 28 Jul 2009 11:32:05 +1000

Yes, well as we have so often discussed, it is far simpler to add map  
our existing state in the broadband DHCP on the NAS
to EAP then other proposals and yes over time we would want expand to  
key management to facilitate, policy
control that scales to the millions at the broadband edge.

- Ric

On 28/07/2009, at 1:02 AM, Alper Yegin wrote:

>>>>>>>>>>> change to DHCP.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 28 Jul 2009 04:37:58 -0400

David,

I don't think "your interest" in Figure 2 more than Figure 3 is the same 
as Broadband Forum's requirements. In TR-101, there is a requirement 
"The Broadband Network Gateway MUST be able to function as a DHCP Relay 
Agent as described in RFC 951 “BOOTP”, RFC 2131”DHCP” and RFC 3046 “DHCP 
Relay Agent Information Option” on selected untrusted interfaces."

It seems to me that if draft-pruss does not support Figure 3, then it 
does not satisfy Broadband Forum's requirements. Please correct me if my 
observation is wrong.

Yoshihiro Ohba

MILES DAVID wrote:
>> client was in fact also the EAP supplicant. There is no EAPoL or
>>     
> 802.1x
>   
>> RADIUS proxy does not need to be aware of the details of the
>>     
> EAP-Message
>   
>> transport and port association, which will require a state maintained
>>     
> by
>   
>> DHCP relay.
>>
>> Yoshihiro Ohba
>>
>>   
>>     
>>>>>>>>>>>>>> acceptable design change for DHCP?  Or please correct me
>>>>>>>>>>>>>>                             
> if
>   
>>>>>>>>>>>>>>                           
>>>>>>>>>>>>>>                             
>>   
>>     
>>>>>>>>>>>>>> I am wrong.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>> Yoshihiro Ohba

---

From: Richard Pruss <[email-masked]>
Date: Tue, 28 Jul 2009 20:10:12 +1000

Oh, for crying in a bucket.

How on earth do you draw this conclusion?

  Can you PANA folks go back to your cave.  We are not about to adopt  
PANA so please stop with the noise and this nonsense.

- Ric

On 28/07/2009, at 6:37 PM, Yoshihiro Ohba wrote:

> David,
>
> I don't think "your interest" in Figure 2 more than Figure 3 is the  
> same as Broadband Forum's requirements. In TR-101, there is a  
> requirement "The Broadband Network Gateway MUST be able to function  
> as a DHCP Relay Agent as described in RFC 951 “BOOTP”, RFC  
> 2131”DHCP” and RFC 3046 “DHCP Relay Agent Information Option” on  
> selected untrusted interfaces."
>
> It seems to me that if draft-pruss does not support Figure 3, then  
> it does not satisfy Broadband Forum's requirements. Please correct  
> me if my observation is wrong.
>
> Yoshihiro Ohba
>
>
> MILES DAVID wrote:
>> From: Yoshihiro Ohba [mailto:[email-masked]] Sent:  
>> Tuesday, July 28, 2009 9:57 AM
>> To: MILES DAVID
>> Why? As I commented above, DHCP relay is running EAP acting as an  
>> EAP authenticator, which will require lower-layer (in this case  
>> DHCP relay) to maintain a state.
>>
>> In Figure 3 of draft-pruss, DHCPEAP message does not come from or  
>> go to the DHCP server.
>> The DHCP relay in draft-pruss is not relaying DHCPEAP message  
>> between DHCP client and DHCP server.
>>
>> Yoshihiro Ohba
>>
>>
>>> d
>>>
>>>> As I said to Ralph earlier we track transport and port  
>>>> associations already to facilitate unnumbered interfaces, so the  
>>>> question was what
>>>>
>>
>>
>>>> state beyond that.
>>>>
>>>>> In general, a state on the logical connection between the peer  
>>>>> and authenticator needs to be maintained by any EAP lower-layer  
>>>>> for each
>>>>>
>>
>>
>>>>>>>>>> the relay agent is simply handing the EAP messages to the  
>>>>>>>>>> AAA  service in the relay function... so no the question  
>>>>>>>>>> still makes
>>>>>>>>>>
>>
>>
>>>>>>>>>> no sense to me.
>>>>>>>>>>
>>>>>>>>> authenticator is not simply handing EAP messages to the AAA,  
>>>>>>>>> it needs to maintain a state including a retransmission  
>>>>>>>>> timer to retransmit outstanding EAP-Request message (cf. RFC  
>>>>>>>>> 4137).
>>>>>>>>>
>>>>>>>> No mate this is the part you probably missed, EAP is doing  
>>>>>>>> that and it is a separate function regardless of what it is  
>>>>>>>> being carried on , PPP, Ethernet, DHCP here is just transport.
>>>>>>>>
>>>>>>> listed above requires to maintain a state to carry EAP  
>>>>>>> message.  There is no exception.
>>>>>>>
>>>>>> What state?
>>>>>>
>>>>>>
>>>>>>> Yoshihiro Ohba
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> - Ric
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Yoshihiro Ohba
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> The thing that makes no sense is the assertion that the  
>>>>>>>>>> relay agent suddenly needs to hold state, beyond what it  
>>>>>>>>>> already does
>>>>>>>>>>
>>
>>
>>>>>>>>>>> enforcement function.  Therefore, the relay agent function  
>>>>>>>>>>> is not keeping any state.  The address enforcement  
>>>>>>>>>>> function could
>>>>>>>>>>>
>>
>>
>>>>>>>>>>> just as easily get that address assignment information  
>>>>>>>>>>> from some other source like CLI or SNMP.
>>>>>>>>>>>
>>>>>>>>>>> stateless operation (but I'm not sure we've strictly  
>>>>>>>>>>> enforced the rule) with the definition of subsequent relay  
>>>>>>>>>>> agent
>>>>>>>>>>>
>>> options.
>>>
>>>>>>>>>>> - Ralph
>>>>>>>>>>>
>>>>>>>>>>>>>> enforce DHCP address assignment, so it is not a change  
>>>>>>>>>>>>> needed *after* DHCP exchanges are done, and therefore  
>>>>>>>>>>>>> the state is maintained outside the context of DHCP,  
>>>>>>>>>>>>> which I don't care.  My comment was if DHCP relay needs  
>>>>>>>>>>>>> to be stateful in the middle of DHCP exchanges to carry  
>>>>>>>>>>>>> EAP.
>>>>>>>>>>>>>>> relay agent acts EAP authenticator, then the relay  
>>>>>>>>>>>>>>> agent will be no longer a stateless DHCP entity. I  
>>>>>>>>>>>>>>> think this is
>>>>>>>>>>>>>>>
>>
>>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 28 Jul 2009 16:56:01 +0200

Ric, I get that you are frustrated by this discussion, but for us  
innocent bystanders, it would be helpful if you could respond  
factually, rather than expressing your frustration. Please remember  
that your grasp of what you are trying to do is much greater than  
ours, since we aren't trying to do it.   If you think it's a bad  
question, I'd like to see you say why.

---

From: "Alan Kavanagh" <[email-masked]>
Date: Tue, 28 Jul 2009 11:56:30 -0400

Ric

Just to understand correctly here, are you saying that the DHCP Relay
Model is no longer needed? 

Also, just to add to what David Miles has noted on the thread, are we
saying that the supplicant must be in the Home Gateway? How do we handle
the case where some devices will be bridged and not routed through the
HGw? 

Im not comparing applies and oranges but I would like to understand more
about if this is a one for all model!

Alan 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Yoshihiro Ohba
Sent: July 28, 2009 4:38 AM
To: MILES DAVID
Cc: dhc WG; Ralph Droms
Subject: Re: [dhcwg] Comments on draft-pruss-dhcp-auth-dsl-06 and
draft-brzozowski-dhcp-eap-analysis-00

David,

I don't think "your interest" in Figure 2 more than Figure 3 is the same
as Broadband Forum's requirements. In TR-101, there is a requirement
"The Broadband Network Gateway MUST be able to function as a DHCP Relay
Agent as described in RFC 951 "BOOTP", RFC 2131"DHCP" and RFC 3046 "DHCP
Relay Agent Information Option" on selected untrusted interfaces."

Yoshihiro Ohba

MILES DAVID wrote:
> I had not realized you were referring to Figure 3 - I was referring to

> a DHCP relay that may be between the NAS and the client such as those 
> described as L2 DHCP relays and present in an access node/DSLAM, etc. 
> I apologies for creating any further confusion there.
>
> If there were a bootp relay or l2 DHCP relay between the NAS and HGW 
> in figure 2 - it would not need to be stateful. Also, if the NAS were 
> not forking EAP/RADIUS (it was a "classical" bootp/DHCP relay) it 
> would not need to have new state tables for DHCPEAP.
>
> Figure 3 describes something that is not well-described as a DHCP 
> relay IMO (which may be your point as well). I would agree that there 
> is state in this device by its nature and that having a forked EAP and

> it is a EAP authenticator.
>
>> In the proposed DHCP message exchange of DISCOVER, DHCPEAP, 
>> DHCPOFFER, ACK I see no requirement for a stateful DHCP relay to
support DHCPEAP.
> authenticator, which will require lower-layer (in this case DHCP 
> relay) to maintain a state.
>   
>> As with other DHCP relayed messages there is sufficient information 
>> in the response ( contains chaddr (IPv4) or peer address (IPv6 
>> relay)) received from the DHCP server to forward this message to the 
>> Home Gateway (operating as DHCP client and EAP supplicant).
>>   
>>     
> In Figure 3 of draft-pruss, DHCPEAP message does not come from or go 
> to the DHCP server.
>> From: [email-masked] [mailto:[email-masked]] On 
>> Behalf Of Yoshihiro Ohba

>>>>>>>>> to handle ip unnumbered interfaces, Ric
>>>>>>>>>

---

From: Richard Pruss <[email-masked]>
Date: Wed, 29 Jul 2009 05:37:15 +1000

Sorry Ted, he is claiming we do not meet the requirements because we  
vendors call the L3 DHCP relay
function a proxy.   Sinking to a semantic debate on if something is a  
proxy or a relay is a new low.

We do lots of extra things in this L3 edge because we compete on  
features and this L3 Edge does all kind
of things I am sure a pure relay does not, ones I often mention are  
map attributes from AAA and interact with
the local session enforcement and routing mechanisms so that the  
assigned address is the only one the DHCP client can
send and receive traffic on.

It was because DHCP does so much already in the BRAS/NAS that the  
adding a few attributes for authentication
to add to the quality of the decision is a logical choice.

- Ric

---

From: Richard Pruss <[email-masked]>
Date: Wed, 29 Jul 2009 06:02:00 +1000

Hi Alan,

> Model is no longer needed?
Nope it is still needed, but most of us including I believe the  
SmartEdge call this DHCP proxy
because it proxies attributes into AAA.

> saying that the supplicant must be in the Home Gateway?
No there is no such limitation in the draft, but realistically this is  
targeted at PPP migration so
places where we use authentication today.

> How do we handle
This works just fine and we are certainly seeing this being used for  
set-top box network
authentication and IP address allocation, in some very large chaotic  
L2 centric networks.

> about if this is a one for all model!

Totally fun with doing that,
Ric

> same
>>>>>>>>> it
>>>>>>>>>>> is
>>>>>>>>>>> enforced

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 28 Jul 2009 18:38:57 -0400

> proxy or a relay is a new low.

Ric, the reason of my cliam is NOT because you call the DHCP relay 
funtion a proxy.  I really don't care how vendors are calling the L3 
DHCP relay.  My claim is, if the scenario described in Figure 3 of 
draft-pruss is removed from the draft, then it will not satisfy the 
Broadband Forum's requirements.
> send and receive traffic on.

As far as I understand, what you often mention regarding mapping 
attributes from AAA *without EAP* is still possible based on caching.  
As Ted mentioned earlier, this kind of caching does not necessarily 
require the DHCP relay (or DHCP proxy in your term) to be stateful 
entity in terms of DHCP operation.  However, *with EAP*, the DHCP relay 
will need to be stateful as I  and Alper mentioned earlier. It seems 
that DHC WG people are sensible about such a change.  I hope I explained 
my technical point clear enough. If not, let's discuss further.

Yoshihiro Ohba

---

From: Richard Pruss <[email-masked]>
Date: Wed, 29 Jul 2009 08:51:07 +1000

On 29/07/2009, at 8:38 AM, Yoshihiro Ohba wrote:

> Richard Pruss wrote:
>> Sorry Ted, he is claiming we do not meet the requirements because  
>> we vendors call the L3 DHCP relay
>> function a proxy.   Sinking to a semantic debate on if something is  
>> a proxy or a relay is a new low.
>

So you are editing what is an not in the draft for me?

> attributes from AAA *without EAP* is still possible based on  
> caching.  As Ted mentioned earlier, this kind of caching does not  
> necessarily require the DHCP relay (or DHCP proxy in your term) to  
> be stateful entity in terms of DHCP operation.  However, *with EAP*,  
> the DHCP relay will need to be stateful as I  and Alper mentioned  
> earlier. It seems that DHC WG people are sensible about such a  
> change.  I hope I explained my technical point clear enough. If not,  
> let's discuss further.

Actually as I have mentioned twice, port tracking state you pointed to  
long predates DHCP with EAP as when the BRAS ports are unnumbered a  
single IP address is used as the interface address for thousands of  
interfaces, you need to know that state to be able to forward the DHCP  
packets back down to the correct port.  So no as I have being trying  
to point out this is no change, these are session aggregation devices,  
their roll is to be stateful for each session.  Regardless of if the  
state is implemented inside or outside of the DHCP relay function the  
BRAS is certainly tracking that state and a whole lot more.

- Ric

>>> factually, rather than expressing your frustration. Please  
>>> remember that your grasp of what you are trying to do is much  
>>> greater than ours, since we aren't trying to do it.   If you think  
>>> it's a bad question, I'd like to see you say why.
>>>
>>
>>
>>
>

---

From: "MILES DAVID" <[email-masked]>
Date: Wed, 29 Jul 2009 07:09:21 +0800

Hi Yoshihiro,

See my line below:
> Also, if the NAS were not

There is a new working text looking at what is called "IP Sessions" in the Broadband Forum that would likely address things like DHCP Auth which is extensible to support new models. PS, the next BBF is in Tokyo as I understand.

My interest is namely that, just what I am interested in (and an observation of what architectures I have seen deployed). A split model where both RADIUS and DHCP come from a BNG/NAS is not very common as customers will typically use either or. I do not place a split model as a high priority and have simply observed that this is where much debate is originating from.

Cheers,

-d

-----Original Message-----
From: Yoshihiro Ohba [mailto:[email-masked]] 
Sent: Tuesday, July 28, 2009 6:08 PM
To: MILES DAVID
Cc: Richard Pruss; dhc WG; Ralph Droms
Subject: Re: [dhcwg] Comments on draft-pruss-dhcp-auth-dsl-06 and draft-brzozowski-dhcp-eap-analysis-00

David,

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 28 Jul 2009 21:25:15 -0400

Richard Pruss wrote:
>> necessarily require the DHCP relay (or DHCP proxy in your term) to be 
>> stateful entity in terms of DHCP operation.  However, *with EAP*, the 
>> DHCP relay will need to be stateful as I  and Alper mentioned 

Let me clarify. What you mentioned twice is what I am mentioning as 
doable as cache.  My point is, if DHCP starts carrying EAP, your DHCP 
relay will need to create a state within DHCP relay and the state needs 
to exist until an EAP conversation completes in order to appropriately 
map the EAP conversation to a transport entity, which I think is more 
than a cache. My question is: is  this kind of change beyond cache 
acceptable to the DHC WG?  Of course I may be misunderstanding 
something. In that case, I would appreciate if someone can provide much 
more details on interactions between DHCP relay and AAA in DSL environment.

Regards,
Yoshihiro Ohba

---

From: Richard Pruss <[email-masked]>
Date: Wed, 29 Jul 2009 11:38:34 +1000

On 29/07/2009, at 11:25 AM, Yoshihiro Ohba wrote:

>>> be stateful entity in terms of DHCP operation.  However, *with  
>>> EAP*, the DHCP relay will need to be stateful as I  and Alper  
>>> mentioned earlier. It seems that DHC WG people are sensible about  
>>> such a change.  I hope I explained my technical point clear  
>>> enough. If not, let's discuss further.
>>
>> Actually as I have mentioned twice, port tracking state you pointed  
>> to long predates DHCP with EAP as when the BRAS ports are  
>> unnumbered a single IP address is used as the interface address for  
>> thousands of interfaces, you need to know that state to be able to  
>> forward the DHCP packets back down to the correct port.  So no as I  
>> have being trying to point out this is no change, these are session  
>> aggregation devices, their roll is to be stateful for each  
>> session.  Regardless of if the state is implemented inside or  
>> outside of the DHCP relay function the BRAS is certainly tracking  
>> that state and a whole lot more.
>
> doable as cache.  My point is, if DHCP starts carrying EAP, your  
> DHCP relay will need to create a state within DHCP relay and the  
> state needs to exist until an EAP conversation completes in order to  
> appropriately map the EAP conversation to a transport entity, which  
> I think is more than a cache. My question is: is  this kind of  
> change beyond cache acceptable to the DHC WG?  Of course I may be  
> misunderstanding something. In that case, I would appreciate if  
> someone can provide much more details on interactions between DHCP  
> relay and AAA in DSL environment.

Which begs the question what is this state beyond the cached port  
information are you talking about, Alper mentioned some future  
possible keying when one distributes keys to DHCP RFC 3118 will  
probably be interesting in the relay but I have heard about no  
additional state required now for this.

- Ric

>>>>> Ric, I get that you are frustrated by this discussion, but for  
>>>>> us innocent bystanders, it would be helpful if you could respond  
>>>>> greater than ours, since we aren't trying to do it.   If you  
>>>>> think it's a bad question, I'd like to see you say why.
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 28 Jul 2009 21:47:19 -0400

Richard Pruss wrote:
> References: <[email-masked]> 
> <[email-masked]> 
> <[email-masked]> 
> <[email-masked]> 
> <[email-masked]> 
> <[email-masked]> 
> <[email-masked]> 
> <[email-masked]> 
> <[email-masked]> 
> <[email-masked]> 
> <[email-masked]> 
> <[email-masked]> 
> <[email-masked]> 
> <[email-masked]> 
> <[email-masked]> 
> <[email-masked]> 
> <[email-masked]> 
> <[email-masked]> 
> <[email-masked]> 
> <[email-masked]> 
> <[email-masked]> 
> <8FB19091-639D-4A2C-B9C0-87237199F65C@cisco.!
> com> <[email-masked]>
> X-Mailer: Apple Mail (2.935.3)
> Return-Path: [email-masked]
> X-OriginalArrivalTime: 29 Jul 2009 01:38:37.0644 (UTC) 
> FILETIME=[4B2DD0C0:01CA0FED]
>
>
>>>> such a change.  I hope I explained my technical point clear enough. 
>>>> If not, let's discuss further.
>>>
>>> to long predates DHCP with EAP as when the BRAS ports are unnumbered 
>>> a single IP address is used as the interface address for thousands 
>>> of interfaces, you need to know that state to be able to forward the 
>>> DHCP packets back down to the correct port.  So no as I have being 
>>> trying to point out this is no change, these are session aggregation 
>>> devices, their roll is to be stateful for each session.  Regardless 
>>> of if the state is implemented inside or outside of the DHCP relay 
>>> function the BRAS is certainly tracking that state and a whole lot 
>>> more.
>>
>> relay will need to create a state within DHCP relay and the state 
>> needs to exist until an EAP conversation completes in order to 
>> appropriately map the EAP conversation to a transport entity, which I 
>> think is more than a cache. My question is: is  this kind of change 
>> beyond cache acceptable to the DHC WG?  Of course I may be 

In addition, your DHCP relay will need to have a state for EAP 
authenticator state machine.

Yoshihiro Ohba

---

From: Richard Pruss <[email-masked]>
Date: Wed, 29 Jul 2009 12:36:50 +1000

> authenticator state machine.

While that is true for the DHCP server function I am not sure why you  
feel the relay would need this as it is not controlling flow control.

- Ric

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 28 Jul 2009 22:47:25 -0400

> feel the relay would need this as it is not controlling flow control.

That is needed because DHCP relay is acting EAP authenticator in your 
model.  This has nothing to do with flow control.

Yoshihiro Ohba

---

From: Richard Pruss <[email-masked]>
Date: Wed, 29 Jul 2009 12:55:45 +1000

On 29/07/2009, at 12:47 PM, Yoshihiro Ohba wrote:

>> While that is true for the DHCP server function I am not sure why  
>> you feel the relay would need this as it is not controlling flow  
>> control.
>
> That is needed because DHCP relay is acting EAP authenticator in  
> your model.  This has nothing to do with flow control.

Well the BRAS is acting as the EAP authenticator in the architecture  
but I do not see why this requires state in an implementation of the  
DHCP relay in the BRAS.

- Ric

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 28 Jul 2009 23:38:35 -0400

> but I do not see why this requires state in an implementation of the 

EAP authenticator is responsible for method type negotiation, 
remembering the negotiated method type, retransmission of outstanding 
EAP request message, etc. DHCP relay will need to maintain a state to 
access the EAP authenticator state machine block, for each DHCP client, 
to realize this.

Yoshihiro Ohba

---

From: Richard Pruss <[email-masked]>
Date: Wed, 29 Jul 2009 18:46:54 +1000

On 29/07/2009, at 1:38 PM, Yoshihiro Ohba wrote:

>>>>>> Which begs the question what is this state beyond the cached  
>>>>>> port information are you talking about, Alper mentioned some  
>>>>>> future possible keying when one distributes keys to DHCP RFC  
>>>>>> 3118 will probably be interesting in the relay but I have heard  
>>>>>> about no additional state required now for this.
>>>>>
>> Well the BRAS is acting as the EAP authenticator in the  
>> architecture but I do not see why this requires state in an  
>> implementation of the DHCP relay in the BRAS.
>
> remembering the negotiated method type, retransmission of  
> outstanding EAP request message, etc. DHCP relay will need to  
> maintain a state to access the EAP authenticator state machine  
> block, for each DHCP client, to realize this.
We are in so deep into what one could consider this implementation  
specific territory, but I consider the previously mentioned cached  
state sufficient to access said EAP authenticator state block.

- Ric

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 29 Jul 2009 15:36:46 -0400

Richard Pruss wrote:
>> access the EAP authenticator state machine block, for each DHCP 
>> client, to realize this.
I believe EAP state machine block needs to stay longer than the cache, 
otherwise your DHCP relay with cache is characterized as a stateful 
entity. I would like to see much more detailed description and analysis 
on this aspect in the analysis draft so that members can evaluate 
appropriately.

Yoshihiro Ohba

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 30 Jul 2009 19:11:59 +0300

> proxy or a relay is a new low.

Your I-D rightfully calls the entity residing on NAS a "DHCP relay". 

   Figure 3: DHCP Authentication Message Flow with DHCP relay NAS

If you remove this scenario, you fail the TR-101 requirement:

The Broadband Network Gateway MUST be able to function as a DHCP Relay Agent
as described in RFC 951 "BOOTP", RFC 2131"DHCP" and RFC 3046 "DHCP Relay
Agent Information Option" on selected untrusted interfaces." 

Isn't that obvious to everyone?

> send and receive traffic on.

People's concern is "DHCP relay implementation" maintaining state; not "the
box that implements DHCP relay" maintaining state. Obviously the latter
would have state for non-DHCP reasons.

Alper

---

From: "MILES DAVID" <[email-masked]>
Date: Fri, 31 Jul 2009 12:13:27 +0800

Gents,

We currently have the two options below:

1) A BNG that acts as DHCP Server, and uses RADIUS for all AAA
2) A BNG that splits the EAP messages from DHCP: Uses RADIUS for EAP
transport, but maintains DHCP for address assignment  (split AAA)

This second model is obviously causing significant controversy. 

I propose the following model, to me this satisfies operators who wish
the BNG to be a DHCP relay, and does not introduce any requirement for
caching, storing, or otherwise processing the new message type. 

You can consider this:
3) A BNG that acts as a DHCP Relay. All DHCP messages are relayed to the
DHCP server. There is no cached state, no processing of EAP messages, or
sending EAP requests. The DHCP Server must perform this function.

It is important that we acknowledge this model because any intermediate
relay (including L2RA and LDRA) will need to process the DHCPEAP
messages like this as well - for this reason I have labeled in NAS or AN
[Access Node]. For a BNG it continues to snoop the DHCP ACK to create
the IP Session.

       (HGW)               (NAS or AN)                  (DHCP)
     DHCP client           DHCP Relay            DHCP server
   EAP Supplicant

        DHCPDISCOVER -------->
         (w/DHCP-auth-proto EAP)
                                  DHCPDISCOVER ------->
                                   (w/DHCP-auth-proto EAP)

                                  <------------ DHCPEAP
                                           (w/EAP ID Req.)
        <------------- DHCPEAP
             (w/EAP ID Req.)

        DHCPEAP ------------->
         (w/EAP Message)
                                  DHCPEAP ------------>
                                   (w/EAP Message)
   +--
   |                              <------------ DHCPEAP
   |                                       (w/EAP Message)
   |    <------------- DHCPEAP
   |         (w/EAP Message)
   |
   |    DHCPEAP ------------->
   |     (w/EAP Message)
   |                              DHCPEAP ------------>
   |                              (w/EAP Message)
   +--
    (The last four messages repeat until EAP Success or EAP fail)

                                  <------------ DHCPEAP
                                           (w/EAP Success)
        <------------- DHCPEAP
                (w/EAP Success)

                                  <----------DHCP OFFER
        <---------- DHCP OFFER

        DHCP REQUEST -------->
                                  DHCP REQUEST ------->

                                  <----------DHCP ACK
        <------------ DHCP ACK

Cheers,

d

-----Original Message-----
From: Alper Yegin [mailto:[email-masked]] 
Sent: Friday, July 31, 2009 1:42 AM
To: 'Richard Pruss'; 'Ted Lemon'
Cc: 'dhc WG'; MILES DAVID; 'Ralph Droms'
Subject: RE: [dhcwg] Comments on draft-pruss-dhcp-auth-dsl-06 and

The Broadband Network Gateway MUST be able to function as a DHCP Relay
Agent
as described in RFC 951 "BOOTP", RFC 2131"DHCP" and RFC 3046 "DHCP Relay
Agent Information Option" on selected untrusted interfaces." 

> send and receive traffic on.

People's concern is "DHCP relay implementation" maintaining state; not
"the
box that implements DHCP relay" maintaining state. Obviously the latter
would have state for non-DHCP reasons.

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 31 Jul 2009 03:03:47 -0400

Your suggested model does not fit DSL Network Architecture (Figure 1) 
where NAS is the entity that interacts with AAA, whereas in your model 
DHCP server (separated from NAS or AN) needs to be the entity that 
interacts with AAA.

Yoshihiro Ohba