Subject: Re: [dhcwg] comments on dhc-eap-auth-analysis-01

From: "Alper Yegin" <[email-masked]>
Date: Tue, 1 Dec 2009 15:28:11 +0200

> What is not shown on this slide but is certainly often the case is the
> both the DSLAM and the NAS only allow forwarding for an IP address
> after the DHCP offer, also other attributes from RADIUS are used for
> provisioning the
> edge session behaviour on the NAS.
> 
> So in current deployments DHCP provisions the client and the chain of
> network elements.

So, that already breaks with the introduction of IPv6. DHCP client already
has and does use the IPv6 link-local address prior to getting any DHCP
offer. 

> I was once naive and thought people were asking genuine questions as
> opposed to
> just trying to disrupt, and so I wrote many an email trying to explain
> the l2/l3 relationships
> in the broadband edge and why PANA and some of the other alternatives
> do not fly.

Apparently not everyone is on the same page with you, since PANA is already
part of the ETSI TISPAN NASS spec (ES 282 004, the Stage 2).

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 1 Dec 2009 15:33:37 +0200

Are we talking about the same thing?
The "DHCP thing" in this I-D is one that forwards some messages to a DHCP
server, that consumes some DHCP messages, and that originates (not forwards!
It originates) some DHCP messages "all within the same DHCP session." Is
there really such a thing being used somewhere?

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of [email-masked]
> Sent: Thursday, November 26, 2009 1:31 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [dhcwg] comments on dhc-eap-auth-analysis-01
> 
> > In your slide 5, you explicitly mention DHCP relay (instead
> > of DHCP proxy) implemented on BNG.  This (and any) DHCP
> > relay can never be called as DHCP proxy if DHCP proxy
> > maintains a state.
> 
> Not commenting on the thread as such - but this statement is wrong
> in the context of existing DHCP implementations on BRAS (and other)
> boxes. See for instance
> 
> http://www.juniper.net/techpubs/en_US/junose10.3/information-
> products/topic-collections/broadband-access/id-78582.html#id-78582
> 
> where what Juniper calls DHCP proxy for the E-series most definitely
> maintains state.
> 
> Steinar Haug, Nethelp consulting, [email-masked]
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Richard Pruss <[email-masked]>
Date: Wed, 2 Dec 2009 05:30:20 +1000

> has and does use the IPv6 link-local address prior to getting any DHCP

The IPv6 mechanisms will be addressed by SAVI and we can all be very
sure that will not require PANA.

> part of the ETSI TISPAN NASS spec (ES 282 004, the Stage 2).

DHCP Auth and PANA are only examples of mechanisms in that document  
and the whole document
is on hold since Jari sent an unsolicited liaison that blocks it.   
Something I assume
Jari and Ralph will address once the WG has moved forward on it.

Nice try Alper,
Ric

---

From: [email-masked]
Date: Tue, 01 Dec 2009 23:15:41 +0100 (CET)

> there really such a thing being used somewhere?

Absolutely. The Juniper E-series DHCP proxy described in the previously
mentioned URL does indeed originate DHCP messages (e.g. DHCP DISCOVER
messages are sent from the IP address of the Juniper router, *not* the
typical 0.0.0.0 address of the client).

---

From: Ted Lemon <[email-masked]>
Date: Tue, 1 Dec 2009 16:16:33 -0700

> typical 0.0.0.0 address of the client).

What's in giaddr?

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 2 Dec 2009 10:22:05 +0200

> sure that will not require PANA.

I think you misunderstood me.
What I'm saying is this: You claim DSL infra is such that it cannot be
changed to allow forwarding IP address until the DHCP offer is sent out; yet
as you see that claim falls apart as soon as IPv6 comes into the picture.

> Jari and Ralph will address once the WG has moved forward on it.

Yeah, somehow ETSI thought EAPoDHCP was a fine idea. Only someone who is
following the DHC and Int area lists would know the issues. For those
interested, here is the aforementioned liaison:

https://datatracker.ietf.org/documents/LIAISON/file735.txt

Alper

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 2 Dec 2009 10:25:39 +0200

Ok, this sounds like a different beast.
It's hard to understand what/why/how it does without seeing a message flow.

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, December 02, 2009 12:16 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]

---

From: Richard Pruss <[email-masked]>
Date: Wed, 2 Dec 2009 21:07:26 +1000

> as you see that claim falls apart as soon as IPv6 comes into the  

No I expect the theory mechanism will be the same for DHCP v6. The  
security will probably
be driven by the DHCPv6 REPLY message.

Probably a bit premature to call this but smart people are working on
it in the SAVI WG.

http://tools.ietf.org/html/draft-bi-savi-dhcp-00

- Ric