Subject: Re: [Int-area] DHCP-based subscriber authentication

From: Mark Townsley <[email-masked]>
Date: Mon, 01 Mar 2010 12:06:18 +0100

I won't be able to attend the upcoming IETF (if all continues to go 
well, I will be taking care of my new daughter slated to arrive in the 
next couple of weeks instead!).

If I were to be there, I'm sure that during discussion I would try and 
point out the irony of how much WG time and effort has been put into 
this, while still dancing around whether it is an official WG item. If 
only all of our official WG documents were guaranteed so much WG attention.

Given the interest-level from operators, running code available, and WG 
time spent, I think that it is high time to call a fig a fig and publish 
what has been done here.  If there is no consensus on making this a 
standards track work, classify it as Informational or Experimental. 
Informational would seem to fit the bill best, and if the dhc WG wants 
to continue to avoid making a call, this could be handled by a willing 
AD shepherding it through the IESG with all appropriate disclaimers, and 
then some, applied.

Personally, I'd rather see the dhc WG take on the work officially, and 
continue to provide the guidance it already has (including weighing in 
on all the various similar proposals that are popping up). Continuing in 
this grey-area of working on the document, but not really working on the 
document, just makes us look more interested in document labels than 
engineering.

- Mark

On 2/19/10 7:35 PM, Ralph Droms wrote:
>
> In July, 2007, the DSL Forum (now the Broadband Forum, or BBF) sent a
> liaison to the IETF [1] asking about solutions for the problem of
> subscriber authentication in DSL networks, which included a list of
> requirements for any solutions.  In October, 2007, the DSL Forum sent
> a second liaison [2] asking more specifically that the IETF take on a
> work item to develop a subscriber authentication mechanism based on
> DHCP, as described in draft-pruss-dhcp-auth-dsl-01.txt or
> draft-zhao-dhc-user-authentication-02.
>
> There was a long discussion of DHCP-based subscriber authentication at
> the IETF 70 intarea open session.  A poll to determine consensus about
> taking on the work item was inconclusive.  The outcome of the
> discussion was to ask the dhc WG to write an analysis of the mechanism
> proposed in draft-pruss-dhcp-auth-dsl, as a way of providing better
> information to the decision about whether or not to take on the work.
>
> Writing the analysis turned out to be an interative process, in which
> draft-pruss-dhcp-auth-dsl was updated to reflect the points made in
> the analysis document, followed by updates to the analysis to reflect
> the changes in draft-pruss-dhcp-auth-dsl.  That process has converged;
> the analysis is available in draft-jjmb-dhc-eap-auth-analysis-02 and
> the updated DHCP-based authentication specification is in
> draft-pruss-dhcp-auth-dsl-07.
>
> Now that the analysis is complete, the intarea can reconsider the
> original question: should the IETF take on this work?  We will
> allocate some time in the intarea open session at the upcoming IETF to
> a discussion and resolution the question.  In preparation for that
> discussion, please review the analysis and protocol documents, and
> post comments to the [email-masked] mailing list.
>
> - Ralph and Jari
>
> [1] https://datatracker.ietf.org/documents/LIAISON/file457.doc
> [2] https://datatracker.ietf.org/documents/LIAISON/file490.doc
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area
>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 1 Mar 2010 11:54:37 -0700

Mark, the problem we have is that there's no consensus in the DHC working group at the moment to take up the work, and no consensus to drop it, which, as you observe, is a recipe for wasting a lot of cycles on a non-working-group item.

And unfortunately the work, as it stands, is pretty broken in what it does to the DHCP protocol state machine.   The fact that you have running code doesn't ameliorate that - I've seen plenty of protocols that are fundamentally broken but that can be made to work when people who understand the goal are working together to write interoperable implementations.   That doesn't mean that someone reading the spec could make an interoperable implementation that would work dependably.

So this leaves us in the awkward situation where it would probably be beneficial for us to work on it, because we could make it less broken, but we don't have consensus to work on it, so we can't make it less broken.   So we basically have the choice between publishing a document describing something that's very broken, or not publishing the document.

I'd much rather that one of our options was to fix it.   If you have any suggestions for how we could get to that, I'd like to hear them.

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 17 Mar 2010 14:42:45 +0200

> original question: should the IETF take on this work?  

No.

Because:

- This is a fundamentally and technically broken idea (see
draft-jjmb-dhc-eap-auth-analysis-02, and Section 2.5 of RFC 5505),
- It does not even satisfy BBF requirements
(https://datatracker.ietf.org/documents/LIAISON/file457.doc.  Req#6 is
broken, Req#7 and #15 are currently not handled).
- It's IPR encumbered.

In its response to BBF, IETF shall recommend BBF to re-consider RFC 5191, as
this is the IETF's solution to this specific problem, and it satisfies the
BBF requirements. [BBF had not been too enthusiastic about RFC 5191 in the
past because they were under the impression that EAPoDHCP was as simple as
defining one new DHCP option. Given the current understanding the community
has reached, I'm hoping that they'd be more receptive to alternative
approaches.]

Regards,

Alper

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 18 Mar 2010 01:22:45 +1100

FWIW, I agree with Alper. After reading the analysis draft on the dhc WG and
seeing some of the reasons provided for adopting this work, I don't think it
makes sense to adopt it.
Given all the years it has taken to push this work, something useful could
have been done in the meantime. IETF should not hasten the adoption of new
standards because "something has to be done", but develop solutions based on
what we think is right and useful. I don't think piggybacking auth on DHCP
is right.  

Hesham

---

From: Richard Pruss <[email-masked]>
Date: Thu, 18 Mar 2010 06:03:09 +1000

> has reached, I'm hoping that they'd be more receptive to alternative

In the end that is what really has been going on here.  Alper has successfully disrupted most
meaningful dialog, with his continual howling.  The first draft of the analysis was great with good
input for the draft and really improved things, the second draft of the analysis now has a bunch of
Alper inspired rubbish in as well that we have responded to many times on the mailing list and
were deeply disappointed to see made the grade into the analysis.  Should we bother responding
again, there is no evidence that people hear what we say, and for sure Alper will ignore it.

What happened to rough consensus and running code, two - possibly three vendors now have
differing implementations of the basic idea here.  Most if not all of the aggregation vendors have
spoken in favour of adoption,  many operators spoke up on the mailing list but we have been
howled out of a meaningful dialog by Alper and his Panamaniacs.

- Ric

---

From: John Schnizlein <[email-masked]>
Date: Wed, 17 Mar 2010 17:06:34 -0400

It is not true that Panamaniacs are solely responsible for the  
continued opposition to the EAPoDHCP proposal. As Alper knows, I am  
not an advocate for PANA.  Although I tired of the repeated arguments  
and disengaged from discussion of the de-merits of the proposal, I  
find the analysis in draft-jjmb-dhc-eap-auth-analysis-02 not only  
compelling but similar to what I and several colleagues told Ric and  
Mark even before the proposal was brought to the IETF.  I tacitly  
agreed with the challenge that we would defer if its advocates could  
persuade IETF experts in the absence of our criticism.  Now that that  
challenge has failed, without my public engagement, it is time to  
withdraw the bad idea.

The strongest reasons not to make the proposal an IETF standard have  
nothing to do with PANA.  They are (1) its radical change to the DHCP  
state machine and (2) its direct violation of RFC 5505's principle:
       network access authentication and authorization is best handled
       independently of the Internet and higher-layer configuration  
mechanisms."
Other reasons, such as the availability of alternative access  
authentication protocols such as IEEE 802.1X and PANA, and the other  
points in draft-jjmb-dhc-eap-auth-analysis-02, are also valid.

John

---

From: Richard Pruss <[email-masked]>
Date: Thu, 18 Mar 2010 08:13:10 +1000

John I am delighted that you brought up the state machine and RFC 5505.
 
Lets start with RFC 5505.
This document for me shows a serious disconnect by the IETF for the real constraints of Service Providers.  Constraints like existing investment,  provisioning and regulation, and the fact that SP's need to bill and be able to simply and cheaply associate service provided with a revenue flow.
 
RFC 5505 from the IAB, simply ignores existing practice of hundreds of millions of broadband and mobile connections
of close coupling between configuration  and access type, in favour of the something that will never see the light of day
in SP's (at least without unjustifiable costs & processes being added).  It's a tragedy that
so few service providers speak up in the IETF when this sort of document attempts to set an uneconomic the tone for the debate.
 
I think it is a badge of honour that DHCP auth is in contravention of that part of RFC 5505!
 
Now for the state machine.
There is no "radical" change of the DHCP state machine.  This is extremely close to what is done today.  In broadband deployments, the DHCP state machine starts in init state,
 then is paused while we run EAP state machine and then resume the DHCP machine normally.  This is so simple I am always baffled at how people can make the "massive" and
"radical" change claims without smiley's to show they are joking.

On 18/03/2010, at 7:06 AM, John Schnizlein wrote:

> It is not true that Panamaniacs are solely responsible for the continued opposition to the EAPoDHCP proposal. As Alper knows, I am not an advocate for PANA.  Although I tired of the repeated arguments and disengaged from discussion of the de-merits of the proposal, I find the analysis in draft-jjmb-dhc-eap-auth-analysis-02 not only compelling but similar to what I and several colleagues told Ric and Mark even before the proposal was brought to the IETF.  I tacitly agreed with the challenge that we would defer if its advocates could persuade IETF experts in the absence of our criticism.  Now that that challenge has failed, without my public engagement, it is time to withdraw the bad idea.
> 
> The strongest reasons not to make the proposal an IETF standard have nothing to do with PANA.  They are (1) its radical change to the DHCP state machine and (2) its direct violation of RFC 5505's principle:
>      independently of the Internet and higher-layer configuration mechanisms."
> Other reasons, such as the availability of alternative access authentication protocols such as IEEE 802.1X and PANA, and the other points in draft-jjmb-dhc-eap-auth-analysis-02, are also valid.
> 
> John
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 17 Mar 2010 21:24:35 -0400

On Mar 17, 2010, at 6:13 PM, Richard Pruss <[email-masked]> wrote:

> In broadband deployments, the DHCP state machine starts in init state,
>  then is paused while we run EAP state machine and then resume the  
> DHCP machine normally.

I'm not familiar with the RFC (or other document) that describes this.  
Could you clue me in?

---

From: Ted Lemon <[email-masked]>
Date: Wed, 17 Mar 2010 21:40:11 -0400

On Mar 17, 2010, at 4:03 PM, Richard Pruss <[email-masked]> wrote:

> the second draft of the analysis now has a bunch of
> were deeply disappointed to see made the grade into the analysis

The rubbish is your content-free bickering, which is the primary  
reason why you have had no traction here--despite having valid reasons  
to want to advance your protocol, every time you start to get  
traction, you shoot yourself in the foot with another stupid ad- 
hominem diatribe and then complain about how the lack of forward  
progress is someone else's fault.

The fault tests squarely on your shoulders for responding this way. It  
may well be too late to salvage anything of value from this process.   
But if it is possible, you need to stop shooting yourself in the foot  
before it really does become impossible.

---

From: Richard Pruss <[email-masked]>
Date: Thu, 18 Mar 2010 13:10:00 +1000

On 18/03/2010, at 11:40 AM, Ted Lemon wrote:

> The rubbish is your content-free bickering, which is the primary reason why you have had no traction here--despite having valid reasons to want to advance your protocol, every time you start to get traction, you shoot yourself in the foot with another stupid ad-hominem diatribe and then complain about how the lack of forward progress is someone else's fault.
> 
> The fault tests squarely on your shoulders for responding this way. It may well be too late to salvage anything of value from this process.  But if it is possible, you need to stop shooting yourself in the foot before it really does become impossible.

Here is the diff between the in my view constructive version 1 of the analysis and the version 2 of the analysis.
http://tools.ietf.org/rfcdiff?url2=draft-jjmb-dhc-eap-auth-analysis-02

As far as I can see ever point is standards lawyering and was raised by Alper but hey I might be wrong.

Now lets go through them and see if they are rubbish.

4.1.9.  Authorization lifetime versus lease time

As we discussed when Alper raised this we need Forced Renew to force Renew with authentication.
We gave a draft on how keys for DHCP message authentication could be provisioned with EAP but
that was disrupted by Alper as well.

So yep, rubbish because we know this is easily solved.

6 Dual-stack issues

As we have said many times it by design that each assigned address be authenticated
separately.  Which is not an option in the write-up in the analysis paragraph.  This is so
that IP addresses can be authenticated per service.  As we have mentioned, try think about
the edge in a wholesale context where different providers can provide services on different
IP addresses ranges at the same time.

So yep, rubbish because this is a feature by design.

7.  Appropriateness	
See my response to John on this RFC. 

Personally I believe in a cheap, scalable access layer, with as few messages as possible.  
I want to see edge access become cheap as air and massive BRAS scale numbers become common.
We will not do this with massive stacks protocols, doing some vague coupled dance.  Some access
media are now well in excess of 32 messages before they are set-up, that is all simply delay and cost. 

I do agree that I have tired of this endless debate and I have become an impediment to progress here.
Andrew McLachlan from BT access architecture team has volunteered to take on editing this draft
should it become a Working Group document.

Regards,
Ric

---

From: Richard Pruss <[email-masked]>
Date: Thu, 18 Mar 2010 17:03:33 +1000

On 18/03/2010, at 11:24 AM, Ted Lemon wrote:

>>  then is paused while we run EAP state machine and then resume the DHCP machine normally.
> 
> I'm not familiar with the RFC (or other document) that describes this. Could you clue me in?

I believe the draft does this but if it does not please draw or illustrate the claimed "radical" changes to the state machine, because
I just do not get it.

- Ric

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 19 Mar 2010 13:26:55 +0200

Ric,

- The idea behind dhcp-auth,
- The way some people must have given you the idea that getting a rubber
stamp in IETF would be a "piece of cake,"
- The way such a bad idea was allowed to drain precious IETF cycles for so
long,
- And the way the type of language you are using is allowed on the IETF
mailing lists....

IMO, these are the real "rubbish." 

> -----Original Message-----
> From: Richard Pruss [mailto:[email-masked]]
> Sent: Wednesday, March 17, 2010 10:03 PM
> To: Alper Yegin; Internet Area; Ralph Droms
> Subject: Re: [Int-area] DHCP-based subscriber authentication
> 
>

---

From: Jari Arkko <[email-masked]>
Date: Tue, 23 Mar 2010 06:41:09 -0700

I would like to remind everyone that no matter how strongly we feel 
about a topic, IETF mailing list discussions should stay on the 
technical matters. Please do not attack the persons.

Jari