Subject: Re: [dhcwg] *DRAFT* minutes for dhc WG meeting in Dublin

From: "David W. Hankins" <[email-masked]>
Date: Thu, 4 Sep 2008 13:43:09 -0700

On Sat, Aug 30, 2008 at 10:25:19PM +0300, Alper Yegin wrote:
> The notes on draft-pruss-dhcp-auth-dsl-03 discussion say:
> 
> 	An ad hoc team from the dhc WG will write a report describing the
> 	impact of this proposal on DHCP architecture, implementations and
> 	deployments.
> 
> I don't recall such a thing being discussed at all. And the recorded audio
> confirms my memory. Where did this part come from?

..and where is it going?

There has already been some INT<->DHC crossposted discussion which
seems like the need for this has been filled.  What exactly are the
open questions?

Sorry if this is a duplicate...some kind of X-Files thing going on
with my email in switching my desktop around.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 4 Sep 2008 13:45:28 -0700

On Sat, Aug 30, 2008 at 07:20:37AM -0400, Ralph Droms wrote:
> In particular, please review the DHCP auth discussion to confirm the
> attribution of remarks to individuals (esp. as noted in the minutes).

Uh...I did not attend DHC at IETF 72.  I was in a taxi cab, so I was
not on Jabber either.

> David Hankins responded that's for a different WG.  He noted that
> there is a framed IPv6 prefix, only slightly related.  What is one
> supposed to do with that?
>
> David Hankins said that it seems like outside of DHCP we need to look
> at additional RADIUS options to support populating these RAs.

 !

...

Am I to conclude that we have another David Hankins attending DHC
meetings?

Sorry if this is a duplicate.  Same X-files thing.

---

From: Ralph Droms <[email-masked]>
Date: Thu, 4 Sep 2008 16:53:24 -0400

Well, it's the presidential election season here in the USA, so let me  
put a positive spin on your comments...

We can conclude that the review process for dhc WG minutes works and  
you've pointed out a problem with the minutes that needs to be  
corrected!

- Ralph

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 4 Sep 2008 14:05:55 -0700

As I did not attend the meeting, I have some questions based on the
discussion;

On Sat, Aug 30, 2008 at 07:20:37AM -0400, Ralph Droms wrote:
> Piet asked if the DHCP authentication could be extended to PC clients.
> Has Ric thought about including a message in a DHCPNAK if
> authentication fails, so the client knows it's not getting IP address
> because authentication failed.
> 
> Ric responded that's actually a policy decision: you may want to give
> the client an IP address and put him on a remedial segment.  So adding
> a message in the DHCPNAK is a good idea.

In response to which message (DHCPDISCOVER or DHCPREQUEST)
specifically?

> calling it proxy; the NAS has to see all the messages.  Ralph said we
> have well-defined mechanisms for having the relay agent see all the
> messages. 

We don't, actually, unless I misunderstand Ralph's point (if it is
limited to some specific deployment scenario, for example)?  Bernie
suggested to fix this problem in DHCPv6 actually with a monotonically
increasing sequence number, which I believe the WG eventually decided
not to enter into.  DHCPv4 is identical in this respect, I believe.

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 4 Sep 2008 14:10:12 -0700

On Thu, Sep 04, 2008 at 04:53:24PM -0400, Ralph Droms wrote:
> We can conclude that the review process for dhc WG minutes works and you've 
> pointed out a problem with the minutes that needs to be corrected!

Shucks.

I was really hoping there was someone else I could assign my draft
work to.  :(

---

From: Richard Pruss <[email-masked]>
Date: Fri, 5 Sep 2008 07:18:31 +1000

> In response to which message (DHCPDISCOVER or DHCPREQUEST)
The issue here is what to do when authentication fails.  So the last  
message
would be an EAP response from the client and now the question is what  
to do next.

Basically a policy choice is made at that point.  Either give the  
subscriber an
IP with some appropriate network limitations or give no IP address.

My comment was simply that DHCPNAK makes sense in the later case, when  
you are going to give no IP address as it sends
the client neatly back to INIT state.

Regards,
Ric

---

From: Ralph Droms <[email-masked]>
Date: Thu, 4 Sep 2008 17:24:30 -0400

On Sep 4, 2008, at Sep 4, 2008,5:05 PM, David W. Hankins wrote:

>> [...]

I was thinking of the "DHCP Server Identifier Override Suboption", RFC  
5107.

- Ralph

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 4 Sep 2008 14:28:16 -0700

On Fri, Sep 05, 2008 at 07:18:31AM +1000, Richard Pruss wrote:
> would be an EAP response from the client and now the question is what to do 
> next.
>

I understand that, I think.

> My comment was simply that DHCPNAK makes sense in the later case, when you 
> are going to give no IP address as it sends

But do you mean at DHCPDISCOVER time or DHCPREQUEST time?

If you mean at DHCPDISCOVER, then in this case actually the DHCPNAK is
probably a waste.  Clients will be listening for DHCPOFFERs only, they
will ignore DHCPNAKs.

They're also already in INIT state.  So the best thing to do is to
simply not reply and let them keep exponentially backing off their
retransmission timer (rather than suggesting to reset it).

On the other hand, if you mean at DHCPREQUEST, then yes, a DHCPNAK
is helpful if they can't actually be allowed to have that
configuration, and the information to send them back to INIT is
helpful.

But this is obvious as that is how DHCPv4 works from the start.

So I'm really at a loss as to what's being described here.

---

From: Richard Pruss <[email-masked]>
Date: Fri, 5 Sep 2008 07:30:28 +1000

> So I'm really at a loss as to what's being described here.
DHCPDISCOVER time, the client has not got an offer.

Regards,
Ric

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 4 Sep 2008 14:46:01 -0700

> I was thinking of the "DHCP Server Identifier Override Suboption", RFC 

OK, then we are talking about a limited subset of deployments, as this
does not allow the relay to see all the messages where two relays are
involved (at INIT/REBINDING/etc, drops to one, not the other), nor
where more than one server is involed (differing sets of information
supplied is normal operation).

Right?  Or am I remembering the PD discussions wrong?

For completeness, it also presumes no support of DHCPINFORM messages
(servers reply to ciaddr not giaddr, so relays will not see server
replies), which I assumed already as this draft is purposed to
authorize access to IP address resources, which DHCPINFORM does not
convey.

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 4 Sep 2008 14:47:07 -0700

> DHCPDISCOVER time, the client has not got an offer.

Then I advise against DHCPNAK.  Just leave the client in INIT
state.