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

From: "Alper Yegin" <[email-masked]>
Date: Wed, 5 Aug 2009 00:22:39 +0300

Hi,

BNG/NAS/AN is where AAA client is implemented.
If DHCP server is placed on a node other than the BNG/NAS/AN, I don't think
the AAA client goes with the DHCP server.

Alper

> -----Original Message-----
> From: MILES DAVID [mailto:[email-masked]]
> Sent: Friday, July 31, 2009 7:13 AM
> To: Alper Yegin; Richard Pruss; Ted Lemon
> Cc: dhc WG; Ralph Droms
> Subject: RE: [dhcwg] Comments on draft-pruss-dhcp-auth-dsl-06 and
> draft-brzozowski-dhcp-eap-analysis-00
> 
> 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
> draft-brzozowski-dhcp-eap-analysis-00
> 
> > 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.
> 
> 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?
> 
> 
> > 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.
> 
> 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
> 
> 
> 
> 
> >
> > 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
> >
> > On 29/07/2009, at 12:56 AM, Ted Lemon wrote:
> >
> > > 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.
> > >
> >
> > _______________________________________________
> > dhcwg mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "MILES DAVID" <[email-masked]>
Date: Wed, 5 Aug 2009 08:26:47 +0800

It is a broader discussion, that's for sure.

In an environment where there is no RADIUS (deployments exist) we are
using DHCP options like circuit-id as a trusted credential - technically
authentication.
It is certainly a stretch of DHCP beyond its original intent - but even
then you could use hardware address as a authentication credential of
sorts. For a variety of reasons there are customers and vendors who
support a DHCP-only environment - there are some operational and capex
advantages is trying to re-use and extend these DHCP systems.
I probably should reiterate that the AN scenario (in the option 3 I
mentioned) is critical - it needs to be covered (ie, the AN DHCP relay /
Layer 2 Relay Agent). 

I guess my final thoughts are that the wider DHC WG needs to have some
input onto this, as we seem to be taking up the majority of the
discussion. I believe that without more WG support we won't be able to
progress this draft anyway.

My summary of the discussion so far follows (if it may help others):

- The current draft describes two modes
	- A mode where the BRAS or BNG acts as DHCP server. The AAA is
performed by RADIUS and the credentials in the DHCPEAP messages copied
into the RADIUS user-name/password AVP.
	- A mode where the BRAS or BNG was performing a split
authentication. DHCPEAP was using RADIUS user-name/password
authentication, while the DHCP we know today was continuing to a remote
DHCP server (for address assignment, etc). 

- It was noted that the split model puts new requirements on a BRAS or
BNG, namely caching, possible state machines, etc. The current draft
refers to the split model as having a DHCP Relay, though these
additional requirements seem to push the current definition. One would
need to coordinate the two separate external functions (DHCP server and
RADIUS server responses) into the DHCP messages towards a client.

- An alternative to the second option would be to eliminate the split
messaging and use a stand-alone DHCP server for AAA (without RADIUS).
This appears to require minimal changes to the BNG/BRAS or any other
intermediate relay agent (like the L2 Relay agent or Lightweight DHCPv6
Relay Agent) other than to support the new DHCP message type. No state
is required. This option has a consequence of turning a DHCP server into
a AAA platform.

- Alternative protocols exist, PANA and 802.1aj (tunneled EAPoL)

Cheers,

-David

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

Hi,

BNG/NAS/AN is where AAA client is implemented.
If DHCP server is placed on a node other than the BNG/NAS/AN, I don't
think
the AAA client goes with the DHCP server.

Alper