Subject: [dhcwg] We really mean it this time *FINAL* agenda for dhc WG meeting

From: Ralph Droms <[email-masked]>
Date: Sat, 14 Mar 2009 23:03:50 -0400

DHC WG Agenda - IETF 74
                            0900-1130 2009-03-27
                    (Last revised 2009-03-14 10:48 PM ET)
                    -------------------------------------

Administrivia                                   Brzozowski/Droms 15  
minutes
   Agenda bashing; blue sheets; scribe; Jabber scribe
   Draft last call and adoption announcements

Bulk DHCPv4 Lease Query                         R. Johnson       05  
minutes
   <draft-ietf-dhc-dhcpv4-bulk-leasequery-00>
   Ready for WG last call?

Option Guidelines                               D. Hankins       05  
minutes
   <draft-ietf-dhc-option-guidelines-05>
   Ready for WG last call?

DHCP Inform Clarify                             D. Hankins       15  
minutes
   <draft-ietf-dhc-dhcpinform-clarify-03>
   WG discussion

Dynamic Host Configuration Protocol Option for Softwires
                                                 D. Hankins       05  
minutes
   <draft-dhankins-softwire-tunnel-option-02>
   WG review

Usage of Host Generating Interface Identifier in DHCPv6
                                                 F. Xia           10  
minutes
   <draft-xia-dhc-host-gen-id-01>
   WG discussion

DHCPv6 option for network boot                  T. Huth          10  
minutes
   <draft-ietf-dhc-dhcpv6-opt-netboot-03>
   Ready for WG last call?

DHCPv6 MRC Clarification                        E. Hunt          05  
minutes
   <draft-hunt-dhcpv6-clarify-mrc-00>
   Initial WG review

Forcerenew Key Authentication                   D. Miles         15  
minutes
   <draft-miles-dhc-forcerenew-key-01>
   Revision of raft-vinokour-dhcp-reconfigure-option-00

Lightweight DHCPv6 Relay Agent (LDRA)           D. Miles         05  
minutes
   <draft-miles-dhc-dhcpv6-ldra-02>
   Ready to accept as WG work item?

Layer 2 Relay Agent Information                 D. Miles         05  
minutes
   <draft-ietf-dhc-l2ra-03>
   Ready for WG last call?

DHCPv6 Route Option                             W. Dec           10  
minutes
   <draft-dec-dhcpv6-route-option-01>
   Initial WG review

Default Router and Prefix Advertisement Options for DHCPv6
                                                 R. Droms         10  
minutes
   <draft-droms-dhc-dhcpv6-default-router-00>
   Initial WG review

DHCPv6 Relay Agent Assignment Notification Option
                                                 R. Droms         15  
minutes
   <draft-ietf-dhc-dhcpv6-agentopt-delegate-03>
   Review discussion; ready for WG last call?

DHCPv6 Server Reply Sequence Number Option      R. Droms         05  
minutes
   <draft-ietf-dhc-dhcpv6-srsn-option-02>
   Review discussion; ready for WG last call?

Authentication Extensions for the Dynamic Host Configuration Protocol
                                                 G. Zorn          10  
minutes
   <draft-pruss-dhcp-auth-dsl-04>
   Ready to accept as WG work item?
                                                                  
-----------
                                                                 145  
minutes

---

From: "Alper Yegin" <[email-masked]>
Date: Sun, 15 Mar 2009 15:37:46 +0200

Hi Ralph,

>    Ready to accept as WG work item?

Are the chairs really asking the WG to adopt this I-D? The plan was to see
the designated team's analysis on this I-D first, before anything moves
forward. 

Alper

---

From: Jari Arkko <[email-masked]>
Date: Sun, 15 Mar 2009 22:17:25 -0700

Indeed. And where is the analysis? We've been waiting for that quite a 
bit...

Jari

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 16 Mar 2009 10:47:23 -0700

> the designated team's analysis on this I-D first, before anything moves

If you look at the draft, it has changed significantly;

o It is now Informational.

o It is tied to Bernie's "Vendor Messages", and documents in pretty
  fine detail their use of those messages to implement "DHCPEAP".
  It requires no IANA assignment, so they do not need these drafts
  to progress to implement it.

I don't know if this is considered bad form at the IETF, but I think
we need to seriously (re)consider this compromise; a show of good
faith on DSL Forum's behalf to document their (ab)uses.

(I would like to note briefly that I see no evidence the draft has
 made any attempt to address the technical concerns I raised last
 year, and so I still must say this draft "documents a bad idea in
 fine detail.")

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

---

From: Richard Pruss <[email-masked]>
Date: Tue, 17 Mar 2009 08:25:38 +1000

> year, and so I still must say this draft "documents a bad idea in

David your fundamental disagreement was on if DHCP should configure  
the network element as well as the
host.  We feel it does and this draft revolves around improving that,  
but I certainly have given allot of thought
to your comment but little I could say in the draft that would address  
that.   The simple fact is that
although it was not part of DHCP at the outset; DHCP does configure  
relays in many enterprise and service
provider networks today.

But I as for the rest of the details, as I hope you noted, we have  
given serious weight to the practical suggestions you made
in you email back in August.

- Ric

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 16 Mar 2009 15:46:46 -0700

On Tue, Mar 17, 2009 at 08:25:38AM +1000, Richard Pruss wrote:
> David your fundamental disagreement was on if DHCP should configure the 
> network element as well as the
> host.

I would say this was not my fundamental disagreement.  I did bring up
several points of which you could say you are summarizing your opinion
of one, but for that point I would have chosen different words.

The fundamental technical problem lies in making requests of clients
that are in INIT state, and the new requirements to clients this
implies.  I believe this fundamentally breaks the DHCPv4 client/server
model beyond which we can reasonably maintain over time.

> although it was not part of DHCP at the outset; DHCP does configure relays 
> in many enterprise and service
> provider networks today.

I am fully aware of this, but it also /doesn't/.  Not everywhere.

The point is that solving client access control by using a mechanism
that only fulfills the role in a subset of environments is "throwing
spaghetti at the wall" by solving one problem several times in
different places.

This is great fun of course, unless you are the wall.

Or the Janitor.

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 16 Mar 2009 16:42:07 -0700

> faith on DSL Forum's behalf to document their (ab)uses.

I may not have been clear;

We have had other protocols at the IETF that were turned down for
publication through consensus of the relevant practicioners, who
believed these protocols would actively damage the Internet.  But they
were widely deployed anyway.  The absence of documentation of those
protocols was (looking back, in my opinion) a detriment to our
community (and, as an aside, a catalyst in the ever-shrinking
relevance of the IETF).

One example within DHC WG's lifetime and applicability would be the
WPAD option.  It is /still/ used today despite never becoming an RFC,
it /did/ actively damage the Internet's security (so these
practicioners were vindicated) and so has changed over the years, but
there is also measurable damage for the absence of any specification;
people must now seek this documentation in "DHCP Undergrounds."

I think therefore the question of permitting the publication of this
draft in this form (and therefore as a DHC WG item) bears
re-evaluation, even if its technical contents (and capacity to
actively damage the Internet) remain effectively unchanged since the
last time it was rejected as a WG item.

I don't think anything outside of that question (of re-evaluation as
a WG item) is before us.

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 17 Mar 2009 09:47:20 +0200

David,

This I-D is not adopted by DSLF.
It is just one of the candidate solutions.
DSLF is expecting IETF's evaluation.
If IETF does not give the green light, this ("damaging") I-D does not get
adopted by the DSLF.

If IETF is going to produce any official document on this, it should be
titled "EAP over DHCP considered harmful" IMHO.

Alper

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of David W. Hankins
> Sent: Tuesday, March 17, 2009 1:42 AM
> To: DHC WG
> Subject: Re: [dhcwg] We really mean it this time *FINAL* agenda for dhc
> WG meeting
> 
> community (and, as an aside, a catalyst in the ever-shrinking relevance
> of the IETF).
> 
> draft in this form (and therefore as a DHC WG item) bears re-
> evaluation, even if its technical contents (and capacity to actively
> damage the Internet) remain effectively unchanged since the last time
> it was rejected as a WG item.
> 
> I don't think anything outside of that question (of re-evaluation as a
> WG item) is before us.
> 
> --

---

From: Bud Millwood <[email-masked]>
Date: Tue, 17 Mar 2009 12:31:57 +0100

> >  to progress to implement it.

What did I miss here? If DHCPEAP is tied to vendor messages, how is that 
expected to be deployed at all?

- Bud

Bud Millwood
Weird Solutions, Inc.
http://www.weird-solutions.com
tel: +46 8 758 3700
fax: +46 8 758 3687

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 17 Mar 2009 10:37:15 -0400

The DSLF is waiting for a response from IETF on DHCP Auth.  This is a
fact.

PPPoE is the closest analogy for a historical model.  The IETF rejected
it, and Broadband folks implemented it anyway because it was the right
thing to do at the time.  (In retrospect, nobody can sanely argue that
PPPoE has been "harmful to the internet".)

Many individuals who build BNGs (e.g., from Juniper, Redback, Huawei,
Nortel, Cisco) have stated reasons why they think DHCP Auth is an
appropriate way to go.  The discussions are well documented on the
int-serv list, and I will not waste anyone's time by revisiting them
again.

The will be running code and deployments on DHCP Auth shortly.  Fighting
the effort, even as an *informational* draft is just silly.  Everyone
knows the arguments.  People here are adults.  They can choose to
build/deploy or not.  

And then the market will choose.

Eric

> Of Alper Yegin
> Sent: Tuesday, March 17, 2009 3:47 AM
> To: 'David W. Hankins'; 'DHC WG'
> Subject: Re: [dhcwg] We really mean it this time *FINAL* agenda fordhc
> WG meeting
> 
> David,
> 
> relevance
> a
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Alan Kavanagh" <[email-masked]>
Date: Tue, 17 Mar 2009 11:29:19 -0400

Redback and Ericsson can speak for themselves on this matter.

Alan  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Eric Voit (evoit)
Sent: March 17, 2009 10:37 AM
To: Alper Yegin; David W. Hankins
Cc: DHC WG
Subject: Re: [dhcwg] We really mean it this time *FINAL* agendafordhc WG
meeting

Eric

> If IETF does not give the green light, this ("damaging") I-D does not 
> get adopted by the DSLF.
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 17 Mar 2009 08:37:38 -0700

> From: Alper Yegin [mailto:[email-masked]]
> Sent: Tuesday, March 17, 2009 12:47 AM
WG meeting
> If IETF does not give the green light, this ("damaging") I-D does not
get
> titled "EAP over DHCP considered harmful" IMHO.

While not intending to make a statement regarding the
current document, I cringe whenever I see a casual use
of "* considered harmful". Such proclamations can have
a profound influence on the way things move forward or
don't - and not always for the best.

Fred
[email-masked]

relevance
a

---

From: Bill Welch <[email-masked]>
Date: Tue, 17 Mar 2009 11:39:03 -0400

Eric,

Please let Juniper speak on it's own behalf.

Thank you.

Bill Welch

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Eric Voit (evoit)
Sent: Tuesday, March 17, 2009 10:37 AM
To: Alper Yegin; David W. Hankins
Cc: DHC WG
Subject: Re: [dhcwg] We really mean it this time *FINAL* agendafordhc WG
meeting

Eric

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 17 Mar 2009 09:03:39 -0700

> And then the market will choose.

Throwing spaghetti at the wall just to see what sticks.

It is great fun!  Heartily enjoyed by all.  Except the wall.  Or the
Janitor.

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 17 Mar 2009 09:25:39 -0700

> If IETF does not give the green light, this ("damaging") I-D does not get

I'm getting conflicting feedback on this.  I suspect you're in a
position to know better than me; but the authors have said that they
currently have "running lab code".

This insight to me is a threat to deploy.  There is no other reason to
make that statement other than to say, "It is already in our firmware."
We are in a recession here in the US, and no one wants to hear that
they have spent money building an object they can't sell.  They will
deploy it just to pretend they're making money off of it and no one
has to get fired.

So I wonder if DSLF is in any greater position of power to control
release than IETF is...?

I am thinking it is the draft's authors, and neither the IETF nor
DSLF/Broadband Forum about which we should be concerned, and therefore
address.

> titled "EAP over DHCP considered harmful" IMHO.

I was rather thinking about the benefits of having the protocol
documented clearly, from the point of view of a draft analyzing it.

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 17 Mar 2009 12:32:25 -0400

Fair enough, let me rephrase my point.

I 100% agree that individuals should speak for themselves.  To date
people developing BNGs have *not* endorsed any specific DHCP Auth draft.
Some example statements indicating support for the investigation of DHCP
Auth as general technology topic however are at:

http://www.ietf.org/mail-archive/web/int-area/current/msg01288.html
http://www.ietf.org/mail-archive/web/int-area/current/msg01083.html
https://datatracker.ietf.org/documents/LIAISON/file490.doc 

These messages/docs are from vendors & standards groups not on any of
the DHCP Auth drafts.

Bill, I apologize since my message could have been read as an approval
of a specific draft.  That was not the intent.

Eric

> From: Bill Welch [mailto:[email-masked]]
> Sent: Tuesday, March 17, 2009 11:39 AM
> To: Eric Voit (evoit); Alper Yegin; David W. Hankins
> Cc: DHC WG
> Subject: RE: [dhcwg] We really mean it this time *FINAL* agendafordhc
> WG meeting
> 
> Eric,
> 
> > > Subject: Re: [dhcwg] We really mean it this time *FINAL* agenda
for
> > dhc

---

From: Bill Welch <[email-masked]>
Date: Tue, 17 Mar 2009 12:44:09 -0400

Thanks Eric!

-----Original Message-----
From: Eric Voit (evoit) [mailto:[email-masked]] 
Sent: Tuesday, March 17, 2009 12:32 PM
To: Bill Welch
Cc: DHC WG
Subject: RE: [dhcwg] We really mean it this time *FINAL* agendafordhc WG
meeting

Eric

> fordhc
for

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 17 Mar 2009 17:04:59 -0700

...

> titled "EAP over DHCP considered harmful" IMHO.

I support this fully -- but only, of course, after the publication of its
companion document, entitled "PANA Considered a Useless Waste of Time" ;-).

...

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 18 Mar 2009 17:04:26 +0200

Glen,

> I support this fully -- 

Thank you.

> but only, of course, after the publication of
> its

EAP over DHCP by itself is a bad idea. That fact does not change with or
without PANA. 

Alper

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 18 Mar 2009 14:02:17 -0400

> EAP over DHCP by itself is a bad idea

You opinion is noted.  Again.

EAP over DHCP is not for all deployments.  It is for Broadband.  The
Broadband Forum has specifically asked for this kind of mechanism.  
https://datatracker.ietf.org/documents/LIAISON/file490.doc 
The BBF certainly has had many opportunities to hear & review your
concerns.

Eric

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 19 Mar 2009 09:00:42 +0200

> EAP over DHCP is not for all deployments.  It is for Broadband.  

Broadband constitutes large part of Internet. And even if that were not the
case, once an IETF-endorsed protocol is out, how do you prevent it getting
further hacked-up and spreading elsewhere?

> The Broadband Forum has specifically asked for this kind of mechanism.

That 1.5-year old letter states "Architecture and Transport Working Group
agreed to *seriously consider adopting*" an early version of your I-D.
Discussion has progressed since then, both in DSLF/BBF and IETF. It'd only
make sense to be talking about the current state of discussions in Broadband
Forum, and I hope one of the BBF chairs can make a statement on that.

> The BBF certainly has had many opportunities to hear & review your

And now you are talking on behalf of BBF?
It'd be like I saying "IETF has had many opportunities to hear & review your
draft" and trying to conclude this thread.

Alper

---

From: Jari Arkko <[email-masked]>
Date: Thu, 19 Mar 2009 14:55:22 -0700

A point of process. When we talked about draft-pruss for the last time, 
a number of concerns were raised, and the authors agreed to take these 
into consideration and attempt to come up with an improved proposal. We 
agreed to let the DHCP experts take a look at the end result, and 
determine what problems remained in the end result.

My understanding is that that report is about to come out (or did it 
already come out?) after a design team looked at the issue. I'd like to 
focus the discussion first on the facts, i.e., do we have remaining 
problems or not. Only then we can have a reasonable discussion about 
whether we are ready to accept the remaining issues and adopt the document.

Finally, when different standards bodies work together, the point of 
asking the other one for an opinion is usually truly the need to know 
what the other one thinks, not to just stamp an approval. We do have a 
real ability to tell BBF what we think. If there are significant 
problems we should say no.

Jari

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 20 Mar 2009 15:16:47 -0400

I did not propose the vendor message drafts because of DHCPEAP or any
other specific technology (in fact, I had discussed this idea a long
while ago - before DHCPEAP ever surfaced). I had thought it potentially
useful for failover/redundancy, server-to-server configuration,
server-to-relay communication such as Bulk LQ. Note that with RFC 5460
(DHCPv6 Bulk Leasequery) and
draft-ietf-dhc-dhcpv4-bulk-leasequery-00.txt, DHCP messages are no
longer limited to just UDP.

As with any new messages, the vendor message could be used to implement
something new as an experimental / interim solution. This can be viewed
as bad (since it allow things to exist in the "wild" that might
otherwise not) or good (as it allows testing of solutions that only help
to improve any final specification or perhaps show the error in the
idea). The benefit to this vendor message drafts is that these messages
can safely co-exist and from different vendors, and clients, relays, and
servers can be appropriate protected to process only those that they
know.

And, that's exactly what
http://www.ietf.org/internet-drafts/draft-pruss-dhcp-auth-dsl-04.txt
proposes to do (see 5.1 and Figure 2: DHCP Message Flow with DHCPEAP
messages):

   A DHCPEAP message (using the DHCP Vendor-specific Message
   [I-D.volz-dhc-dhcpv4-vendor-message]) is used in the DHCP message
   flow to support the new EAP phase which occurs before a DHCPOFFER is
   sent by the Server.  This message is used to integrate authentication
   methods supported by EAP, including CHAP and any other "in the clear"
   password mechanisms (for example, to support One-Time Password
   mechanisms), or to carry other EAP methods.

If the vendor message drafts weren't available and someone wanted to
implement this, they'd be left to hijack a DHCP message number or use a
completely different port/protocol (though in this particular case, I
doubt the different port/protocol would be used because that would
require significant changes elsewhere in the DSL network). There's
plenty of unused DHCP message numbers - and it would be unlikely that
there would be a conflict with a future IANA assignment if you picked a
number such as 200 (there's about 180 unused message numbers before IANA
would hit 200, and given the past rate of new message numbers, I suspect
we'd all be long gone before using that many).

I hope there isn't any "guilt by association" (as I think there are lots
of us that view the DHCPEAP work unfavorably or have serious concerns).

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Bud Millwood
Sent: Tuesday, March 17, 2009 7:32 AM
To: [email-masked]
Subject: Re: [dhcwg]We really mean it this time *FINAL* agenda for dhc
WG meeting

- Bud

Bud Millwood
Weird Solutions, Inc.