Subject: [dhcwg] Adopt draft-pruss-dhcp-auth-dsl as a working group item?

From: Ted Lemon <[email-masked]>
Date: Thu, 4 Feb 2010 15:17:39 -0500

At the IETF meeting in Hiroshima, we called for a sense of the room on the question of whether to adopt draft-pruss-dhcp-auth-dsl as a working group item.   The sense of the room was that we should adopt it.   It was agreed that we would call the question on the mailing list within a week of the meeting, with the expectation that by the end of that week, interested parties would have read the new version of the analysis document.

Several additional comments were made on the analysis document (draft-jjmb-dhcp-eap-auth-analysis), and it was our intention to address these comments in the draft and then call the question on the mailing list.   Unfortunately, that task fell to me, and during the time since Hiroshima Andrea and I have sold our house in Tucson and moved to Vermont, so things didn't go precisely as planned.

I just submitted a new version of the analysis draft that addresses points raised by Alper Yegin, Yoshihiro Ohba and Alfred Hönes in response to the -01 version of the draft that was published at the time of the meeting in Hiroshima.

Having done this, it is now time to call the question on the mailing list: should the DHC working group adopt Ric's draft and do work on it, or should we consider the job done as a consequence of having gotten to this point with the auth-analysis draft?

It is not my intention to revise the analysis draft prior to the working group answering this question - I think we've done enough work on the analysis that we should all have a sense of how to proceed at this point.   That's not to say that we are not interested in comments on the analysis draft, but those comments will not delay the question of whether or not to adopt this work.

So if you have an informed opinion on this question, please indicate whether or not the working group should adopt Ric's draft.

Thanks!

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 05 Feb 2010 18:31:54 +0900

I don't support draft-pruss-dhcp-auth-dsl to become a
working group item.

The main reason is that (i) the Broadband Forum TR-101
requires the Broadband Network Gateway to function as a DHCP
Relay Agent, while (ii) draft-jjmb-dhcp-eap-auth-analysis
strongly recommends not to implement draft-pruss in the
relay agent.  One may say that draft-pruss can be 
implemented in the BNG acting a DHCP proxy, but there is no 
requirement in TR-101 for the BNG to function as a DHCP 
proxy.  Considering the fact that AAA client is also 
implemented in the BNG, integration of DHCP relay and AAA 
client is required, basically (i) and (ii) are two 
contradicting things that prevent such integration for DSL. 
  Running host configuration and EAP over different 
protocols is a better approach that allows more flexibility 
in deployment.

Best Regards,
Yoshihiro Ohba

Ted Lemon wrote:
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 5 Feb 2010 12:04:25 +0200

No, IETF should NOT adopt pruss-dhcp-auth-dsl

Because (in the order of descending importance):

- This is a fundamentally and technically broken idea,
- Even if it were otherwise, there is no need and justification for it,
- It's IPR encumbered.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Ted Lemon
> Sent: Thursday, February 04, 2010 10:18 PM
> To: [email-masked] WG
> Subject: [dhcwg] Adopt draft-pruss-dhcp-auth-dsl as a working group
> item?
> 
> At the IETF meeting in Hiroshima, we called for a sense of the room on
> the question of whether to adopt draft-pruss-dhcp-auth-dsl as a working
> group item.   The sense of the room was that we should adopt it.   It
> was agreed that we would call the question on the mailing list within a
> week of the meeting, with the expectation that by the end of that week,
> interested parties would have read the new version of the analysis
> document.
> 
> Several additional comments were made on the analysis document (draft-
> jjmb-dhcp-eap-auth-analysis), and it was our intention to address these
> comments in the draft and then call the question on the mailing list.
> Unfortunately, that task fell to me, and during the time since
> Hiroshima Andrea and I have sold our house in Tucson and moved to
> Vermont, so things didn't go precisely as planned.
> 
> I just submitted a new version of the analysis draft that addresses
> points raised by Alper Yegin, Yoshihiro Ohba and Alfred Hönes in
> response to the -01 version of the draft that was published at the time
> of the meeting in Hiroshima.
> 
> Having done this, it is now time to call the question on the mailing
> list: should the DHC working group adopt Ric's draft and do work on it,
> or should we consider the job done as a consequence of having gotten to
> this point with the auth-analysis draft?
> 
> It is not my intention to revise the analysis draft prior to the
> working group answering this question - I think we've done enough work
> on the analysis that we should all have a sense of how to proceed at
> this point.   That's not to say that we are not interested in comments
> on the analysis draft, but those comments will not delay the question
> of whether or not to adopt this work.
> 
> So if you have an informed opinion on this question, please indicate
> whether or not the working group should adopt Ric's draft.
> 
> Thanks!
>

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 5 Feb 2010 17:32:15 +0700

Ted Lemon [mailto://[email-masked]] writes:

> Unfortunately, that task fell to me, and during the time since Hiroshima
> Andrea and I have sold our house in Tucson and moved to Vermont, so
> things didn't go precisely as planned.
> 
> It is not my intention to revise the analysis draft prior to the working
> group answering this question - I think we've done enough work on the
> analysis that we should all have a sense of how to proceed at this
> point.   That's not to say that we are not interested in comments on the
> analysis draft, but those comments will not delay the question of
> whether or not to adopt this work.
> 

It probably comes as no surprise that I'm in favor of WG adoption of this
draft ;-).

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 5 Feb 2010 09:44:13 -0600

I vote "yes"!   This is good work to take on, and very needed by the Broadband industry. 

Eric

> From: [email-masked], February 04, 2010 3:18 PM
>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 5 Feb 2010 07:51:54 -0800

On Feb 5, 2010, at 4:31 AM, Yoshihiro Ohba wrote:
> relay agent. 

To be clear, this was not a call for the working group to adopt the protocol as-is.   If we were to adopt this protocol as a working group item, it would give us the opportunity to make objections like the one you made, and to get Ric, et al., to fix problems like this.   If we do not adopt this work, BBF will just do whatever they're going to do, and we will not get a say in it.   (Unless someone would like to propose some alternative).   We do not have veto power over the BBF.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sat, 06 Feb 2010 07:44:42 +0900

> To be clear, this was not a call for the working group to adopt the protocol as-is.   If we were to adopt this protocol as a working group item, it would give us the opportunity to make objections…

Sure, but the implication of point (i) described in 
draft-jjmb-dhcp-eap-auth-analysis in my reading is that 
there is no way for draft-pruss to fix the problem unless 
they give up carrying EAP over DHCP, that's why my objection 
comes.

*If* draft-pruss is revised to replace carrying EAP over 
DHCP part with using RFC 5191, I would support it ;)

Thanks,
Yoshihiro Ohba

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 8 Feb 2010 16:43:15 -0800

On Fri, Feb 05, 2010 at 07:51:54AM -0800, Ted Lemon wrote:
> If we
> do not adopt this work, BBF will just do whatever they're going to do,
> and we will not get a say in it.   (Unless someone would like to propose
> some alternative).   We do not have veto power over the BBF.

In point of record, when this draft first came to us, a number of BBF
representatives attempted to communicate that many solutions had been
placed before the BBF and what they wanted to understand is if this
particular method was a good, general way for the Internet to proceed
in this problem space.  The solicitation was for a stamp of approval,
in my opinion on hearing it.

So I find it interesting that your intelligence now is that the BBF is
uninterested in soliciting or considering IETF consensus, and that
accepting this work in no way adjusts their measure of that judgement.

I have no reason to doubt your intelligence, as I have none, but as in
the months in-between we may have gained many new faces and lost some
old ones, I wanted to mention that historical matter of record.

To my mind the Vendor Message Extensions exist for the purpose of
empowering vendors to "do whatever they want" without engaging the
IETF and consuming WG resources (e.g. taking three years to bully
through a malignancy against the DHCPv4 protocol).

Noting now that draft-pruss-dhcp-auth-dsl-07 is encoded as an
Informational draft documenting BBF/Cisco's (future/present?) abuses
of the DHCPv4 protocol (without consideration or regard for IETF
feedback or consensus) as well as their uses of the DHCPv6 vendor
message extensions;

I support accepting draft-pruss-dhcp-auth-dsl-07 as a WG item with the
realistic understanding that our place in harboring an Informational
draft is to do little more than proof read and point out typo's.  This
in no way confers or provides any measure of approval; to the
contrary, I must express my staunch disapproval of this draft's
contents in regard to its molestation of DHCPv4 message semantics
with INIT.* clients.

This draft should not be implemented, but because BBF/Cisco refuse to
accept that, it should be documented clearly.

-- 
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: "Alper Yegin" <[email-masked]>
Date: Tue, 9 Feb 2010 10:40:50 +0200

> If we do
> not adopt this work, BBF will just do whatever they're going to do, and
> we will not get a say in it.   

Ted, I can only guess where you are getting this misunderstanding. 
I've been told by some BBF members that if the IETF does not approve
draft-pruss, then the BBF is not willing to adopt it. Otherwise, we'd not be
seeing so much effort by some people to get it rubber stamped, would we? 

> (Unless someone would like to propose
> some alternative).   

This is not a discussion for DHC WG.

IETF is asked its opinion about draft-pruss. 
Int-area gave this task to DHC WG.
Now DHC WG can provide its opinion on this question.
Int-area/IETF can add to it (such as asking BBF to consider other IETF-based
solutions).
And finally BBF makes it decision by taking non-IETF solutions into
consideration as well (e.g., IEEE 802.1X, etc.)

DHC WG shouldn't be like "oh my god, what is BBF going to do now?"
I think DHC WG should be more like "oh my god, what if someone tries to get
this implemented?"

> We do not have veto power over the BBF.

We give them the feedback they are asking for, and they do whatever they
want to do. DHC WG cannot be operating like a WG of BBF trying to solve
problems beyond its reach.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 9 Feb 2010 10:09:49 -0500

> accepting this work in no way adjusts their measure of that judgement.

That wasn't my point.   My point is that the BBF wants to move forward on something, and this has been delayed in the DHC working group for several years.   I'm sure the BBF is interested in our input, but they also have a job to complete, and if we aren't going to help them, they're going to complete it anyway.

> through a malignancy against the DHCPv4 protocol).

I actually wish it were called the Experimental Message Extensions protocol, because I think the term "Vendor" is inappropriate in a protocol spec.   But that's neither here nor there.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 9 Feb 2010 11:12:56 -0500

> seeing so much effort by some people to get it rubber stamped, would we? 

I think that the extent to which we should even consider political nonsense like this is as follows: do we need to do something?   That is the only question we need to ask.

The BBF will solve this problem whether we do something or not.   We can indeed do nothing, and the BBF will solve this problem without our input.   We can, as you suggest, "rubber stamp" the pruss draft, and the BBF may or may not adopt it.   I think you're right that if we don't work on the draft, BBF will not adopt it, but they *will* adopt *something*, and the only other proposal I'm aware of also uses DHCP.   If they are in fact working on a solution that doesn't involved DHCP, then you're right that there's no need for us to be involved.

However, your theory that we might "rubber stamp" this protocol is nonsense.   As you can see from the response to the call to consider taking this draft on as a work item, support for the draft is not unanimous.   If I were going to take a consensus at this point, I would say that there is no consensus to adopt this draft, but I think we need to wait a bit longer before drawing that conclusion - certainly quite a few people expressed interest in the draft at Hiroshima, and none of them have said anything about the call to adopt here; if they don't, we can assume they aren't that interested, and that this is not work the wg should do.

But even if we do adopt this draft, the lack of unanimity in the working group tells us that this draft will not get a rubber stamp.   The authors will have to make changes to get the draft through the working group.   Which, in my mind, is the entire point of calling the question.

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 9 Feb 2010 09:54:30 -0800

On Tue, Feb 09, 2010 at 10:09:49AM -0500, Ted Lemon wrote:
> That wasn't my point.   My point is that the BBF wants to move forward
> on something, and this has been delayed in the DHC working group for
> several years.   I'm sure the BBF is interested in our input, but they
> also have a job to complete, and if we aren't going to help them, they're
> going to complete it anyway.

Problem solved:  Let this draft expire and move on.

Consensus was called three years ago, then reaffirmed in INT-AREA,
there was no delay.

So when you use the words "they're going to complete it anyway" in the
context of this particular draft, you may be changing the meaning you
are intending to convey.  What it sounds like you're saying is, "the
answer 'do not do this' is unacceptable and we'll keep trying until we
get a different answer; any other response is a delay on DHC WG's
part."

Let's make this simpler:

Is the BBF broadly soliciting the IETF's approval of this approach, or
is it now a foregone conclusion (running code) seeking Informational
level documentation?

I can't speak for others, but my own determination on whether or not
to accept this draft as a WG item hinges on the answer.

-- 
David W. Hankins	BIND 10 needs more DHCP voices.
Software Engineer		There just aren't enough in our heads.
Internet Systems Consortium, Inc.		http://bind10.isc.org/

---

From: "MILES, DAVID (DAVID)" <[email-masked]>
Date: Wed, 10 Feb 2010 06:31:42 +0800

I support introducing this as a WG item. 

DHCP may be the unlucky candidate here, but there is desire to develop an authentication model with minimal complexity and impact on operators and vendors. Yes there are changes to the client, the introduction of a new message type and changes on the authenticator but if you accept changes are required in these areas anyway (to achieve the authentication goal) then I would look to minimizing complexity.

We are in this unfortunate situation because we have so-called L2 networks that are aware (and even maintaining state) based on higher layer: snooping DHCP, anti-spoofing on IP - the network topology has been hacked at in order to achieve a number of outcomes, it just so happens next on the platter is authentication. Leveraging something that is already there (even with changes) is almost always easier than inventing something new. I'm disagree that authentication is a significant departure from what DHCP already does, we do it all the time, be it on MAC address or circuit id and it is specific to a host, allowing configuration information (authorisation if you will) to be passed to the host on authentication success (or failure).

It would be wrong to not mention PANA. PANA achieves all it was set out to do it its charter but it adds one more thing to the mix. In these hacked L2 networks we love/hate there is no PANA snooping or circuit-id insertion. This can certainly be fixed. DHCP provides an attractive because it is already implemented and understood. Even bastardising it for authentication (and introducing new message types) is far less effort than introducing a new protocol.

-david

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 10 Feb 2010 08:33:03 +0900

I agree that PANA should be mentioned.

The good part of draft-pruss is that it describes the basic 
approach of running EAP between DHCPDISCOVER message and 
DHCPOFFER message, not before DHCPDISCOVER or after 
DHCPOFFER message.

What I don't agree is that draft-pruss uses DHCP as the EAP 
transport in this basic approach, for the reason that it 
will not satisfy both the requirement on support for DHCP 
relay in BNG in BBF TR-101 and the recommendation on not 
having EAP authenticator in DHCP relay in 
draft-jjmb-dhcp-eap-auth-analysis at the same time, as I 
mentioned in my previous email.  The draft, I believe, can 
gain more consensus if PANA is used as the EAP transport in 
the basic approach to run EAP between DHCPDISCOVER message 
and DHCPOFFER message.

Thanks,
Yoshihiro Ohba

MILES, DAVID (DAVID) wrote:
> DHCP may be the unlucky candidate here, but there is desire to develop an authentication model with mirenimal complexity and impact on operators and vendors. Yes there are changes to the client, the introduction of a new message type and changes on the authenticator but if you accept changes are required in these areas anyway (to achieve the authentication goal) then I would look to minimizing complexity.
>

---

From: <[email-masked]>
Date: Wed, 10 Feb 2010 01:22:49 +0100

The choice of DHCP as the protocol to transport EAP messages and achieve
user authentication is just plain bad. The arguments so far seem to be along
the lines that given the deployment of DHCP and it being fairly well
understood, it is okay to bastardise it for a purpose that it is not
intended for. 

The question is: Does the BBF have no alternatives if the DHC WG does not
specify this? They have been looking at 802.1x as well. A protocol solution
that would not impact the DHC client on hosts would be preferred.

If the IETF wants to extend DHC for the purposes of the BBF, I would rather
have it done as an individual submission or have it sponsored by an AD with
a good enough reason to staisfy the IESG. I would prefer to not have this
I-D go through as a DHC WG document because it gives the impression that the
IETF believes on extending DHCP this way.

-Raj 

On 2/9/10 4:31 PM, "ext MILES, DAVID (DAVID)"
<[email-masked]> wrote:

> DHCP may be the unlucky candidate here, but there is desire to develop an
> authentication model with minimal complexity and impact on operators and
> vendors. Yes there are changes to the client, the introduction of a new
> message type and changes on the authenticator but if you accept changes are
> required in these areas anyway (to achieve the authentication goal) then I
> would look to minimizing complexity.
> 
> We are in this unfortunate situation because we have so-called L2 networks
> that are aware (and even maintaining state) based on higher layer: snooping
> DHCP, anti-spoofing on IP - the network topology has been hacked at in order
> to achieve a number of outcomes, it just so happens next on the platter is
> authentication. Leveraging something that is already there (even with changes)
> is almost always easier than inventing something new. I'm disagree that
> authentication is a significant departure from what DHCP already does, we do
> it all the time, be it on MAC address or circuit id and it is specific to a
> host, allowing configuration information (authorisation if you will) to be
> passed to the host on authentication success (or failure).
> 
> It would be wrong to not mention PANA. PANA achieves all it was set out to do
> it its charter but it adds one more thing to the mix. In these hacked L2
> networks we love/hate there is no PANA snooping or circuit-id insertion. This
> can certainly be fixed. DHCP provides an attractive because it is already
> implemented and understood. Even bastardising it for authentication (and
> introducing new message types) is far less effort than introducing a new
> protocol.
> 
> -david

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 10 Feb 2010 12:26:59 +0200

Ted,

> I think that the extent to which we should even consider political
> nonsense like this is as follows: do we need to do something?   That is
> the only question we need to ask.
> 
> The BBF will solve this problem whether we do something or not.   We
> can indeed do nothing, and the BBF will solve this problem without our
> input.   We can, as you suggest, "rubber stamp" the pruss draft, and
> the BBF may or may not adopt it.   I think you're right that if we
> don't work on the draft, BBF will not adopt it, but they *will* adopt
> *something*, and the only other proposal I'm aware of also uses DHCP.
> If they are in fact working on a solution that doesn't involved DHCP,
> then you're right that there's no need for us to be involved.

Why are we even talking about what is in front of BBF? I have no idea what
that other proposal is. I know there is PANA on the table, and some
companies are also talking about IEEE 802.1X. There may be others too. One
has to be involved in the BBF to know the whole picture. DHC WG is not asked
"in the presence of solutions A, B, C, and D, is D the right solution". DHC
WG is asked "does D make sense?".  

> However, your theory that we might "rubber stamp" this protocol is
> nonsense.   As you can see from the response to the call to consider
> taking this draft on as a work item, support for the draft is not
> unanimous.   If I were going to take a consensus at this point, I would
> say that there is no consensus to adopt this draft, but I think we need
> to wait a bit longer before drawing that conclusion - certainly quite a
> few people expressed interest in the draft at Hiroshima, and none of
> them have said anything about the call to adopt here; if they don't, we
> can assume they aren't that interested, and that this is not work the
> wg should do.

Setting a deadline for the call would be useful.

> But even if we do adopt this draft, the lack of unanimity in the
> working group tells us that this draft will not get a rubber stamp.
> The authors will have to make changes to get the draft through the
> working group.   Which, in my mind, is the entire point of calling the
> question.

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 10 Feb 2010 11:48:40 -0800 (PST)

----- Original Message ----
> From: Ted Lemon <[email-masked]>
> To: "[email-masked] WG" <[email-masked]>
> Sent: Thu, February 4, 2010 2:17:39 PM
> Subject: [dhcwg] Adopt draft-pruss-dhcp-auth-dsl as a working group item?
> 
> At the IETF meeting in Hiroshima, we called for a sense of the room on the 
> question of whether to adopt draft-pruss-dhcp-auth-dsl as a working group item.  
> The sense of the room was that we should adopt it.  It was agreed that we would 
> call the question on the mailing list within a week of the meeting, with the 
> expectation that by the end of that week, interested parties would have read the 
> new version of the analysis document.

I was one of those. I support the adoption and agree with David.

Regards,

Behcet

---

From: <[email-masked]>
Date: Thu, 11 Feb 2010 15:56:21 +0100

I support adopting this as a WG item. 

I agree that from an academic standpoint, DHCP might not be the best candidate. However, in the interest of implementing a model which is as similar as possible compared to today's broadband deployments, I think that draft-pruss-dhcp-auth-dsl allows authentication with minimal complexity and impact on operators and vendors. I am confident that once the draft is adopted, the major pain points from the analysis can be fixed.
Using another protocol such as PANA adds much more complexity than tweaking an already existing mechanism. 
Far too much time has been wasted in the past, please allow this to progress a bit smoother from now on.

Best Regards,
Stefan Alfare

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: Thursday, February 04, 2010 9:18 PM
To: [email-masked] WG
Subject: [dhcwg] Adopt draft-pruss-dhcp-auth-dsl as a working group item?

Thanks!

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 11 Feb 2010 11:00:21 -0800

> to accept this draft as a WG item hinges on the answer.

In the absence of honest dialogue on this aspect, I would like to
change my position on accepting this draft as a WG item;

I abstain.

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 12 Feb 2010 15:19:38 +0200

Hi Ted, 

I am not in favor of draft-pruss-dhcp-auth-dsl becoming a working group item. 

Ciao
Hannes
 
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of ext Ted Lemon
>Sent: 04 February, 2010 22:18
>To: [email-masked] WG
>At the IETF meeting in Hiroshima, we called for a sense of the 
>room on the question of whether to adopt 
>draft-pruss-dhcp-auth-dsl as a working group item.   The sense 
>of the room was that we should adopt it.   It was agreed that 
>we would call the question on the mailing list within a week 
>of the meeting, with the expectation that by the end of that 
>week, interested parties would have read the new version of 
>the analysis document.
>
>Several additional comments were made on the analysis document 
>(draft-jjmb-dhcp-eap-auth-analysis), and it was our intention 
>to address these comments in the draft and then call the 
>question on the mailing list.   Unfortunately, that task fell 
>to me, and during the time since Hiroshima Andrea and I have 
>sold our house in Tucson and moved to Vermont, so things 
>didn't go precisely as planned.
>
>I just submitted a new version of the analysis draft that 
>addresses points raised by Alper Yegin, Yoshihiro Ohba and 
>Alfred Hönes in response to the -01 version of the draft that 
>was published at the time of the meeting in Hiroshima.
>
>Having done this, it is now time to call the question on the 
>mailing list: should the DHC working group adopt Ric's draft 
>and do work on it, or should we consider the job done as a 
>consequence of having gotten to this point with the 
>auth-analysis draft?
>
>It is not my intention to revise the analysis draft prior to 
>the working group answering this question - I think we've done 
>enough work on the analysis that we should all have a sense of 
>how to proceed at this point.   That's not to say that we are 
>not interested in comments on the analysis draft, but those 
>comments will not delay the question of whether or not to 
>adopt this work.
>
>So if you have an informed opinion on this question, please 
>indicate whether or not the working group should adopt Ric's draft.
>
>Thanks!
>

---

From: Subir Das <[email-masked]>
Date: Fri, 12 Feb 2010 08:36:12 -0500

I am also not in favor of accepting this draft as a working group item.

regards,
_Subir

---

From: Alan Kavanagh <[email-masked]>
Date: Fri, 12 Feb 2010 10:57:30 -0500

Hi Ted

Alan 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: February 4, 2010 3:18 PM
To: [email-masked] WG
Subject: [dhcwg] Adopt draft-pruss-dhcp-auth-dsl as a working group item?

Thanks!

---

From: Ted Lemon <[email-masked]>
Date: Fri, 12 Feb 2010 12:49:41 -0700

Thanks for all the responses.   If anybody else would like to respond to this, please do so before Monday.

Thanks!

Ted

---

From: <[email-masked]>
Date: Mon, 15 Feb 2010 14:50:23 +0100

Working for a telco / ISP I agree with the reasons Stefan brought up for adopting this I-D as WG item. 
ISPs need such a mechanism for an authentication of IP sessions very urgently and of course they are interested in re-using well understood protocols and don't like to implement new and more complex provisioning models. That's why I support to adopt draft-pruss-dhcp-auth-dsl as a WG item.

Kind regards
Olaf

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] 
> Im Auftrag von [email-masked]
> Gesendet: Donnerstag, 11. Februar 2010 15:56
> An: [email-masked]
> Cc: [email-masked]
> Betreff: Re: [dhcwg] Adopt draft-pruss-dhcp-auth-dsl as a 
> working group item?
> 
> I agree that from an academic standpoint, DHCP might not be 
> the best candidate. However, in the interest of implementing 
> a model which is as similar as possible compared to today's 
> broadband deployments, I think that draft-pruss-dhcp-auth-dsl 
> allows authentication with minimal complexity and impact on 
> operators and vendors. I am confident that once the draft is 
> adopted, the major pain points from the analysis can be fixed.
> Using another protocol such as PANA adds much more complexity 
> than tweaking an already existing mechanism. 
> Far too much time has been wasted in the past, please allow 
> this to progress a bit smoother from now on.
> 
> Best Regards,
> Stefan Alfare
> 
> 
> On Behalf Of Ted Lemon
> At the IETF meeting in Hiroshima, we called for a sense of 
> the room on the question of whether to adopt 
> draft-pruss-dhcp-auth-dsl as a working group item.   The 
> sense of the room was that we should adopt it.   It was 
> agreed that we would call the question on the mailing list 
> within a week of the meeting, with the expectation that by 
> the end of that week, interested parties would have read the 
> Several additional comments were made on the analysis 
> document (draft-jjmb-dhcp-eap-auth-analysis), and it was our 
> intention to address these comments in the draft and then 
> call the question on the mailing list.   Unfortunately, that 
> task fell to me, and during the time since Hiroshima Andrea 
> and I have sold our house in Tucson and moved to Vermont, so 
> the working group answering this question - I think we've 
> done enough work on the analysis that we should all have a 
> sense of how to proceed at this point.   That's not to say 
> that we are not interested in comments on the analysis draft, 
> but those comments will not delay the question of whether or 
> not to adopt this work.
>

---

From: Maglione Roberta <[email-masked]>
Date: Mon, 15 Feb 2010 15:55:21 +0100

I support adopting this draft as a WG item.

Best Regards,
Roberta

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, February 15, 2010 2:50 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dhcwg] Adopt draft-pruss-dhcp-auth-dsl as a working group item?

Kind regards
Olaf

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

---

From: Bill Welch <[email-masked]>
Date: Tue, 16 Feb 2010 01:59:13 -0500

A solution for this problem with maximum reuse and minimal provisioning model changes is required by Telco / ISP community.

Juniper has submitted an alternative DHCP solution to draft-pruss to BBF for March meeting.

Best regards,
Bill Welch
Juniper Networks

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, February 15, 2010 8:50 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dhcwg] Adopt draft-pruss-dhcp-auth-dsl as a working group item?

Kind regards
Olaf

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 16 Feb 2010 09:54:04 +0200

Hi Bill,

"minimal provisioning model changes"

Can you please expand on this? I don't remember discussing provisioning, and
I cannot figure out how any of the solutions impact/relate to provisioning.
If anyone is making decisions based on something that DHC WG is not aware
of, it'd be good to know.

Alper

> Of Bill Welch
> Sent: Tuesday, February 16, 2010 8:59 AM
> To: [email-masked]; [email-masked]
> A solution for this problem with maximum reuse and minimal provisioning
> model changes is required by Telco / ISP community.
> 
> Of [email-masked]
> ISPs need such a mechanism for an authentication of IP sessions very
> urgently and of course they are interested in re-using well understood
> protocols and don't like to implement new and more complex provisioning
> models. That's why I support to adopt draft-pruss-dhcp-auth-dsl as a WG
> item.
> 
> Kind regards
> Olaf
>

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 16 Feb 2010 15:11:45 +0700

Alper Yegin [mailto://[email-masked]] writes"

> I cannot figure out how any of the solutions impact/relate to

Perhaps that inability has something to do with the amazing success of PANA
in the marketplace...

> > Subject: Re: [dhcwg] Adopt draft-pruss-dhcp-auth-dsl as a working
> group
> > item?
> >
> > Subject: Re: [dhcwg] Adopt draft-pruss-dhcp-auth-dsl as a working
> group
> > item?
> >

---

From: <[email-masked]>
Date: Tue, 16 Feb 2010 10:49:24 +0100

I think that the question is not about PANA vs DHCP for EAP transport in BBF network.
The only question raised so far is: Is DHCP based solution for EAP transport is a good solution?

>From the very first presentation of the draft till now, it seems that there is at least some "consensus" (i.e. shared "also" by the authors and supporters of the draft) on the fact that any DHCP-based solution would be not considered as a standard solution for the global Internet BUT as a specific solution designed for BBF environment. (Do not hesitate to correct me but this is only based on what you can find all along the this discussion thread)

In that sense, if i'm still correct, this work can't become an official WG item. At least, if anything needs to be published, individual submission for an Informational RFC would be the only way to progress on this topic.

Lionel

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] 
> De la part de Glen Zorn
> Envoyé : mardi 16 février 2010 09:12
> À : 'Alper Yegin'; 'Bill Welch'; [email-masked]
> Cc : [email-masked]; [email-masked]
> Objet : Re: [dhcwg] Adopt draft-pruss-dhcp-auth-dsl as a 
> working group item?
> 
> > Can you please expand on this? I don't remember discussing 
> > provisioning, and I cannot figure out how any of the solutions 
> > impact/relate to provisioning.
> 
> Perhaps that inability has something to do with the amazing 
> success of PANA in the marketplace...
> 
> > If anyone is making decisions based on something that DHC WG is not 
> > aware of, it'd be good to know.
> > 
> > Alper
> > 
> > 
> > 
> > 
> > 
> > 
> > > From: [email-masked] [mailto:[email-masked]] On 
> > > Behalf Of Bill Welch
> > > Juniper has submitted an alternative DHCP solution to 
> draft-pruss to 
> > > BBF for March meeting.
> > >
> > > Best regards,
> > > Bill Welch
> > > Juniper Networks
> > >
> > >
> > >
> > >
> > > Working for a telco / ISP I agree with the reasons Stefan 
> brought up 
> > > for adopting this I-D as WG item.
> > > urgently and of course they are interested in re-using well 
> > > understood protocols and don't like to implement new and more 
> > > complex
> > provisioning
> > > models. That's why I support to adopt 
> draft-pruss-dhcp-auth-dsl as a
> > WG
> > > item.
> > >
> > > Kind regards
> > > Olaf
> > >
> > > > Von: [email-masked] [mailto:[email-masked]] Im 
> > > > Auftrag von [email-masked]
> > > > Betreff: Re: [dhcwg] Adopt draft-pruss-dhcp-auth-dsl as 
> a working 
> > > > group item?
> > > >
> > > > I agree that from an academic standpoint, DHCP might not be the 
> > > > best candidate. However, in the interest of 
> implementing a model 
> > > > which is as similar as possible compared to today's broadband 
> > > > deployments, I think that draft-pruss-dhcp-auth-dsl allows 
> > > > authentication with minimal complexity and impact on 
> operators and 
> > > > vendors. I am confident that once the draft is adopted, 
> the major 
> > > > pain points from the analysis can be fixed.
> > > > Using another protocol such as PANA adds much more 
> complexity than 
> > > > tweaking an already existing mechanism.
> > > > Far too much time has been wasted in the past, please 
> allow this 
> > > > to progress a bit smoother from now on.
> > > >
> > > > Best Regards,
> > > > Stefan Alfare
> > > >
> > > >
> > > > agreed that we would call the question on the mailing 
> list within 
> > > > a week of the meeting, with the expectation that by the end of 
> > > > that week, interested parties would have read the new 
> version of 
> > > > the analysis document.
> > > >
> > > > (draft-jjmb-dhcp-eap-auth-analysis), and it was our 
> intention to 
> > > > address these comments in the draft and then
> > > > task fell to me, and during the time since Hiroshima 
> Andrea and I 
> > > > have sold our house in Tucson and moved to Vermont, so things 
> > > > addresses points raised by Alper Yegin, Yoshihiro Ohba 
> and Alfred 
> > > > Hönes in response to the -01 version of the draft that was 
> > > > published at the time of the meeting in Hiroshima.
> > > >
> > > > mailing list: should the DHC working group adopt Ric's 
> draft and 
> > > > do work on it, or should we consider the job done as a 
> consequence 
> > > > of having gotten to this point with the auth-analysis draft?
> > > >
> > > > working group answering this question - I think we've 
> done enough 
> > > > work on the analysis that we should all have a
> > > > that we are not interested in comments on the analysis 
> draft, but 
> > > > those comments will not delay the question of whether or not to 
> > > > adopt this work.
> > > >

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

---

From: Richard Pruss <[email-masked]>
Date: Tue, 16 Feb 2010 21:40:24 +1000

In the past a deployment specific standards track document is done for Cable in RFC 3256, surely a BBF use case is a similar issue.

I hope the WG considers the use case important enough to take on, considering that the DSL portion BBF represents over 150 million subscribers and
the other deployments are growing at pace as well.

- Ric

On 16/02/2010, at 7:49 PM, <[email-masked]> <[email-masked]> wrote:

>>>> Behalf Of [email-masked]
>>>>> Behalf Of Ted Lemon

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 17 Feb 2010 11:25:40 +0200

> provisioning,
> > and

:-)

Seriously, if no one can explain what this provisioning relevance is and why
EAPoDHCP is good for it, I'm inclined to believe that this is just a
fiction. 

Alper

> Behalf
> > > Juniper has submitted an alternative DHCP solution to draft-pruss
> to
> > > BBF for March meeting.
> > >
> > > Best regards,
> > > Bill Welch
> > > Juniper Networks
> > >
> > >
> > >
> > >
> > > Working for a telco / ISP I agree with the reasons Stefan brought
> up
> understood
> > > models. That's why I support to adopt draft-pruss-dhcp-auth-dsl as
> a
> > WG
> > > item.
> > >
> > > Kind regards
> > > Olaf
> > >

---

From: <[email-masked]>
Date: Wed, 17 Feb 2010 11:31:59 +0100

Just to keep it short and not trying to do some large education session.
At the moment all the provisioning approaches of ISPs and Telcos (regarding authentication, access, address delegation etc.) are build around PPP and/or DHCP.

Inserting a new protocol suite has (unfortunately) major impacts to the whole provisioning process within a large company. And that means changes and additional CAPEX and OPEX.
Besides that our HG vendors are struggling with us regarding each additional line of code and each feature that have to be implemented in a new version of the HG in order to keep the costs for such devices as low as possible.

Sorry that's the reality.

Kind regards
Olaf

> Im Auftrag von Alper Yegin
> Gesendet: Mittwoch, 17. Februar 2010 10:26
> An: 'Glen Zorn'; 'Bill Welch'; Bonneß, Olaf
> Cc: [email-masked]; [email-masked]
> success of
> > PANA
> draft-pruss

---

From: [email-masked]
Date: Wed, 17 Feb 2010 11:55:10 +0000

On 17/02/10 10:31, [email-masked] wrote:
> Just to keep it short and not trying to do some large education
> session. At the moment all the provisioning approaches of ISPs and
> Telcos (regarding authentication, access, address delegation etc.)
> are build around PPP and/or DHCP.
> 
> Inserting a new protocol suite has (unfortunately) major impacts to
> the whole provisioning process within a large company. And that means
> changes and additional CAPEX and OPEX. Besides that our HG vendors
> are struggling with us regarding each additional line of code and
> each feature that have to be implemented in a new version of the HG
> in order to keep the costs for such devices as low as possible.
> 

	I'm missing a thing or two here, perhaps due to prejudices 
	formed by experience in an entirely different service delivery 
	environment, that of a routed campus Ethernet.

	What I'm missing is the logical leap from  the above problem
	statement to the idea that stretching DHCP so far as to be
	nearly equivalent to _developing_ a new protocol suite is somehow
	preferable to finding a solution to the problem based on mature
	and deployed technology such as 802.1x.

	I have the impression, from following this thread, that I'm not
	the only one for whom this is a difficulty.

	Best regards
	Niall O'Reilly

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 17 Feb 2010 14:04:10 +0200

We are only talking about the "authentication" part.
The others you counted can still be taken care of by the respective
protocols (DHCP, etc.)
Not performing access authentication with DHCP does not take anything away
from DHCP performing the other tasks.

Reusing an existing protocol does not always mean less work, less
complexity, less code. Anyone objectively reading the analysis document can
easily see how EAPoDHCP is becoming a very good example of that.

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, February 17, 2010 12:32 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: AW: [dhcwg] Adopt draft-pruss-dhcp-auth-dsl as a working group
> item?
> 
> session.
> At the moment all the provisioning approaches of ISPs and Telcos
> (regarding authentication, access, address delegation etc.) are build
> around PPP and/or DHCP.
> 
> Inserting a new protocol suite has (unfortunately) major impacts to the
> whole provisioning process within a large company. And that means
> changes and additional CAPEX and OPEX.
> Besides that our HG vendors are struggling with us regarding each
> additional line of code and each feature that have to be implemented in
> a new version of the HG in order to keep the costs for such devices as
> low as possible.
>

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 17 Feb 2010 15:03:24 +0200

Hi Olaf, 

Let's dig a bit deeper into this issue. 

First, there is the question of how you configure subscribers into the AAA servers. There are no changes unless you switch the authentication mechanisms or even the type of credentials being used. If you now run EAP with the backend infrastructure and previously you didn't then you will have to enhance your AAA server (unless it has support for EAP already).

There are software updates (some would not call this provisioning but let's assume it is) then you certainly have changes at the end host side (and the end host might be the DSL router, or a laptop, etc.). You have these changes regardless of the solution because that's the entire idea of any of these solutions. 

Finally, there will also be changes on the network infrastructure side since the protocol runs between the end host and the some entity in the network. These will be unavoidable. The actual address management procedure would, in my opinion, not be affected (regardless whether you do the address management in the AAA server or in a dedicated DHCP server).

Where do you see the changes from an operational point of view? 

Ciao
Hannes

>On Behalf Of ext [email-masked]
>Sent: 17 February, 2010 12:32
>At the moment all the provisioning approaches of ISPs and 
>Telcos (regarding authentication, access, address delegation 
>etc.) are build around PPP and/or DHCP.
>
>Inserting a new protocol suite has (unfortunately) major 
>impacts to the whole provisioning process within a large 
>company. And that means changes and additional CAPEX and OPEX.
>Besides that our HG vendors are struggling with us regarding 
>each additional line of code and each feature that have to be 
>implemented in a new version of the HG in order to keep the 
>costs for such devices as low as possible.
>
>> Betreff: Re: [dhcwg] Adopt draft-pruss-dhcp-auth-dsl as a working 
>> group item?
>> 
>> > > Hi Bill,
>> > >
>> Seriously, if no one can explain what this provisioning relevance is 
>> and why EAPoDHCP is good for it, I'm inclined to believe 
>that this is 
>> just a fiction.
>> 
>> Alper
>>  
>> 
>> 
>> > 
>> > > > > the best candidate. However, in the interest of 
>implementing a 
>> > > > > model which is as similar as possible compared to today's 
>complexity 
>> > > > > Subject: [dhcwg] Adopt draft-pruss-dhcp-auth-dsl as 
>a working 
>> > > > > group item?
>> > > > >
>> > > > > within a week of the meeting, with the expectation 
>that by the 
>> > > > > end of that week, interested parties would have read the new 
>> > > > > version of the analysis document.
>> > > > >
>intention 
>> > > > > to address these comments in the draft and then
>> > > > > enough work on the analysis that we should all have a

---

From: Richard Pruss <[email-masked]>
Date: Wed, 17 Feb 2010 23:36:51 +1000

On 17/02/2010, at 9:55 PM, [email-masked] wrote:
> 	I'm missing a thing or two here, perhaps due to prejudices 	formed by experience in an entirely different service delivery 	environment, that of a routed campus Ethernet.
> 
Given where you are coming from in campus network I certainly understand this must seem a little strange as it is totally driven by the requirements
of the very large scale aggregation in broadband which is currently migrating to ethernet.

Well it is far very from a new protocol in implementation we found it to be our existing EAP code (used in PPP and 802.1x) running on some DHCP messages, but before you buy that you need to understand that current Broadband deployments of DHCP commonly use AAA as a backend.  That means that most vendors have customers that use AAA to authorise/provision DHCP addresses.  We have a mapping that maps AAA into DHCP, this draft for us is a very small change to existing practice of provisioning users from AAA based on Option 82 information to provision users from AAA based on username and password over EAP. The final result aims to allow the migration from PPP to DHCP based authentication without impacting anything except the CPE and BRAS, the backend AAA etc is not impacted.

Finally your question on why not 802.1x, clearly a protocol most vendors support and could easily use.  
a) 802.1x's MAC address by design causes it to be dropped by the first hop switches, this vastly limits the deployment.
b) The implementations are typically for port authentication not subscriber control, and has allot of challenges being used for more than that.
c) As I detailed in an earlier email the layer 2 security on intermediate switches/dslam's is provisioned by DHCP.  So if a and b are ignored to use 802.1x you either need to limit the topology so that security at Layer 2 is not needed or implement a new protocol to back propagate, security policy events.

Hope that helps your understanding,
- Ric

---

From: Richard Pruss <[email-masked]>
Date: Wed, 17 Feb 2010 23:44:01 +1000

Just one note here, the AAA server does not need to run EAP for large migrations from exiting CHAP or PAP PPP systems.  One can transport PAP or CHAP inside EAP-TLS, where the TLS link just protects between the end-node and the BRAS, between the BRAS and the AAA server it can look just like normal PAP or CHAP.

- Ric

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 17 Feb 2010 16:32:26 +0200

Sure, there are different choices on how to integrate EAP into a AAA server. 

Terminating EAP (and therefore EAP-TLS method in the BRAS) would be possible (although introducing some security risks) but then just pushes the implementation burden more on the BRAS. 

In some cases, however, you will need some code modifications to the AAA server (depending on the gear you have and the deployment environment). 

These things are, however, independent of the specific transport mechanism of EAP frames but rather a consequence of switching to EAP.

I am trying to understand what operational aspects are introduced by the transport itself and which onces are the consequence of switching to a different authentication framework or a different network access deployment (such as running EAP from the end host to the network in comparison to running it from the DSL model to the network). 

Ciao
Hannes

>From: ext Richard Pruss [mailto:[email-masked]] 
>Sent: 17 February, 2010 15:44
>To: Tschofenig, Hannes (NSN - FI/Espoo)
>Cc: [email-masked]; [email-masked]; 
>[email-masked]; [email-masked]; 
>[email-masked]; [email-masked]
>Just one note here, the AAA server does not need to run EAP 
>for large migrations from exiting CHAP or PAP PPP systems.  
>One can transport PAP or CHAP inside EAP-TLS, where the TLS 
>link just protects between the end-node and the BRAS, between 
>the BRAS and the AAA server it can look just like normal PAP or CHAP.
>
>- Ric
>
>> First, there is the question of how you configure 
>subscribers into the AAA servers. There are no changes unless 
>you switch the authentication mechanisms or even the type of 
>credentials being used. If you now run EAP with the backend 
>infrastructure and previously you didn't then you will have to 
>enhance your AAA server (unless it has support for EAP already).
>> 
>> There are software updates (some would not call this 
>provisioning but let's assume it is) then you certainly have 
>changes at the end host side (and the end host might be the 
>DSL router, or a laptop, etc.). You have these changes 
>regardless of the solution because that's the entire idea of 
>any of these solutions. 
>> 
>> Finally, there will also be changes on the network 
>infrastructure side since the protocol runs between the end 
>host and the some entity in the network. These will be 
>unavoidable. The actual address management procedure would, in 
>my opinion, not be affected (regardless whether you do the 
>address management in the AAA server or in a dedicated DHCP server).
>> 
>>> Behalf Of ext [email-masked]
>>> (regarding authentication, access, address delegation
>>> additional line of code and each feature that have to be 
>implemented 
>>> in a new version of the HG in order to keep the costs for such 
>>> devices as low as possible.
>>> 
>Andrea and 
>>>>>>>> I have sold our house in Tucson and moved to Vermont, 
>so things 
>>>>>>>> working group answering this question - I think
>>> we've done
>>>>>>>> but those comments will not delay the question of 
>whether or not 
>>>>>>>> to adopt this work.
>>>>>>>>

---

From: <[email-masked]>
Date: Wed, 17 Feb 2010 16:22:50 +0100

2 to 3 remarks inline.

Regards
Olaf 

> Im Auftrag von Richard Pruss
> Gesendet: Mittwoch, 17. Februar 2010 14:44
> An: Tschofenig, Hannes (NSN - FI/Espoo)
> Cc: [email-masked]; Bonneß, Olaf; [email-masked]
> infrastructure and previously you didn't then you will have 
> to enhance your AAA server (unless it has support for EAP already).

OBo: I think Ric has answered that one.

> regardless of the solution because that's the entire idea of 

OBo: My  remark has been that even if the HGs are upgardable we have very hard discussions with the software vendors for our HGs in order to have a new SW version that keeps the device as cheap as possible and normaly the implementation of new protocols needs more memory more processing power etc.
(BTW by provisioning we understand not a software update - provisioning is in that case from our perspective the whole process from ordering a connection up to the automated process of address information provisioning to the HG and authentication, authorisation up to the links into the backend systems of a network provider.)

> unavoidable. The actual address management procedure would, 
> in my opinion, not be affected (regardless whether you do the 

OBo: Our intention is to keep these unavoidable changes to our network infrastructure (and to the needed and used processes) as small and transparent as possible. In the best case all the interfaces to for instance the accounting systems, legal interception, back end systems etc. are not touched or changed and my fear is that there will be major impacts if we implement and use a new protocol.
BTW: Nobody has at the moment any operational experience with PANA neither in an larger campus network nor in an ISP network (or did I miss something and there is an ISP out there that uses PANA?).
 
Just my 2 cent.

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 18 Feb 2010 10:31:47 +0200

Hello,

> OBo: Our intention is to keep these unavoidable changes to our network
> infrastructure (and to the needed and used processes) as small and
> transparent as possible. In the best case all the interfaces to for
> instance the accounting systems, legal interception, back end systems
> etc. are not touched or changed and my fear is that there will be major
> impacts if we implement and use a new protocol.

This is spreading FUD...

Whatever protocol you use between the CPE and BRAS (or wherever the NAS is)
stays in between the two.
There is no impact on the AAA and other backend systems.
Whether you use EAPoDHCP, EAPoPANA, EAPo8021X, or even EAPoAvians....
Same....

> BTW: Nobody has at the moment any operational experience with PANA
> neither in an larger campus network nor in an ISP network (or did I
> miss something and there is an ISP out there that uses PANA?).

I'm not aware either.
But how about EAPoDHCP? 

Alper

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 18 Feb 2010 10:34:45 +0200

That means that most vendors have customers that use AAA to
authorise/provision DHCP addresses.   

That does not mean you have to use DHCP for authentication.
Look at 802.1X-based WiFi, 3GPP2, WiMAX, 3GPP networks. They can all do the
above without having to use DHCP-based authentication.

---

From: <[email-masked]>
Date: Thu, 18 Feb 2010 09:58:48 +0100

> > impacts if we implement and use a new protocol.

Maybe. If you think so.

> But how about EAPoDHCP? 

It's treated as extension to DHCP.

Olaf

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 18 Feb 2010 11:20:10 +0200

Olaf,

> It's treated as extension to DHCP.

That was long time ago, when EAPoDHCP was portrayed as nothing more than few
new DHCP options.
And that was before it received any technical review from IETF community.
Analysis draft very well documents where EAPoDHCP is heading today...

---

From: Richard Pruss <[email-masked]>
Date: Thu, 18 Feb 2010 19:30:00 +1000

> Analysis draft very well documents where EAPoDHCP is heading today...
.... to become an extension of DHCP?

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 18 Feb 2010 11:46:53 +0200

Hi Olaf, 

Thanks for the response. Please see my comments below: 

>From: ext [email-masked] [mailto:[email-masked]] 
>Sent: 17 February, 2010 17:23
>To: [email-masked]; Tschofenig, Hannes (NSN - FI/Espoo)
>Subject: AW: [dhcwg] Adopt draft-pruss-dhcp-auth-dsl as a 
>working group item?
>
>2 to 3 remarks inline.
>
>Regards
>Olaf 
>
>for large 
>> migrations from exiting CHAP or PAP PPP systems.
>link just 
>> protects between the end-node and the BRAS, between the BRAS and the 
>> AAA server it can look just like normal PAP or CHAP.
>> 
>> - Ric
>> 
>> subscribers into the AAA servers. There are no changes unless you 
>> switch the authentication mechanisms or even the type of credentials 
>> being used. If you now run EAP with the backend infrastructure and 
>> previously you didn't then you will have to enhance your AAA server 
>> (unless it has support for EAP already).
>

Yes, we discussed that one. In short the conclusion was that there are no operational / provisioning implications to the backend infrastructure with any of these protocols we discuss here. Still, it is worthwhile to think about the design decision you made to terminate EAP in the BRAS as it has other implications, see below.  

>> provisioning but let's assume it is) then you certainly have changes 
>> at the end host side (and the end host might be the DSL router, or a 
>> laptop, etc.). You have these changes regardless of the solution 
>> because that's the entire idea of any of these solutions.
>
>OBo: My  remark has been that even if the HGs are upgardable 
>we have very hard discussions with the software vendors for 
>our HGs in order to have a new SW version that keeps the 
>device as cheap as possible and normaly the implementation of 
>new protocols needs more memory more processing power etc.
>(BTW by provisioning we understand not a software update - 
>provisioning is in that case from our perspective the whole 
>process from ordering a connection up to the automated process 
>of address information provisioning to the HG and 
>authentication, authorisation up to the links into the backend 
>systems of a network provider.)

All of the proposals I have seen are essentially new protocols. So, you have changes a couple of lines of code to write. If you additionally terminate EAP-TLS in devices other than the AAA/EAP server then you additionally have to implement EAP-TLS (not a tiny piece of code either) in these devices. This design decision obviously has memory, and performance implications but those are independent of the protocol mechanisms we are discussing here. 

So, I guess for some reason you seem to believe that there is less code to implement with some of the protocols because the have a magic (and familiar) label in the draft file name. Some of your vendors might also claim that all these things are so super challenging to charge more for it. You (or your co-workers) might want to have a closer look at the real amount of code changes needed (particularly in comparison with an approach that would run the EAP exchange all the way to the backend infrastructure). I could mention company names here who could make you interesting offers (better said offers to your business guys) but I will leave that aside. 

In your definition of provisioning you should not see a lot of changes regardless of the choice of protocol (based on what Ric previously commented). 

>> infrastructure side since the protocol runs between the end host and 
>> the some entity in the network. These will be unavoidable. 
>The actual 
>> address management procedure would, in my opinion, not be affected 
>> (regardless whether you do the address management in the AAA 
>server or 
>> in a dedicated DHCP server).
>
>OBo: Our intention is to keep these unavoidable changes to our 
>network infrastructure (and to the needed and used processes) 
>as small and transparent as possible. In the best case all the 
>interfaces to for instance the accounting systems, legal 
>interception, back end systems etc. are not touched or changed 
>and my fear is that there will be major impacts if we 
>implement and use a new protocol.

That makes sense from a certain point of view and none of the protocols we discuss here seem to require any of these changes. 

A little bit out-side the scope of the topic but I still want to mention it: From my own experience I have to say that extensions to the AAA backend infrastructure are not as problematic as they might seem. We have been working in RADEXT and DIME on various extensions that operators have been deploying and if you have a reasonable software architecture then the story is managable. 

>BTW: Nobody has at the moment any operational experience with 
>PANA neither in an larger campus network nor in an ISP network 
>(or did I miss something and there is an ISP out there that 
>uses PANA?).

All of the discussed protocols are new. So, quite naturally the operational experience is missing. That's common with new protocols. The situation is, however, not unique for PANA and is also true for the other proposed mechanisms. 

Ciao
Hannes

>impacts to 
>> >> the whole provisioning process within a large company. And that 
>> >> means changes and additional CAPEX and OPEX.
>> >> implemented in a new version of the HG in order to keep the costs 
>> >> for such devices as low as possible.
>> >> 
>> >>>>>> ISPs need such a mechanism for an authentication of 
>IP sessions
>> >>>> very

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 18 Feb 2010 11:54:53 +0200

Hi Ric, 
 
you seem to be creating the impression among folks in this group that
there is your proposal is just an extension to DHCP (which is why this
is discussed in this group) and hence there is not a big issue vs.
having a totally new protocol. 
 
While this is a nice try, from a marketing point of view, I believe it
is missing the point. All these things are new protocols regardless how
many marketing labels you stick to them.  Think about PANA as an
extension of UDP and it also sounds far less scary to you (since
everyone knows UDP).
 
Ciao
Hannes

________________________________

	From: ext Richard Pruss [mailto:[email-masked]] 
	Sent: 18 February, 2010 11:30
	To: Alper Yegin
	Cc: [email-masked]; Tschofenig, Hannes (NSN -
FI/Espoo); [email-masked]; [email-masked]
	Subject: Re: [dhcwg] Adopt draft-pruss-dhcp-auth-dsl as a
working group item?

		Olaf,

				I'm not aware either.

				But how about EAPoDHCP?

		That was long time ago, when EAPoDHCP was portrayed as
nothing more than few
		new DHCP options.
		And that was before it received any technical review
from IETF community.
		Analysis draft very well documents where EAPoDHCP is
heading today...

---

From: [email-masked]
Date: Thu, 18 Feb 2010 10:54:44 +0000

Thanks for your reply, and my apologies for the delay in acknowledging it.

On 17/02/10 13:36, Richard Pruss wrote:
> a) 802.1x's MAC address by design causes it to be dropped by the
> first hop switches, this vastly limits the deployment.

	Access control surely belongs at point of entry,
	not one or more hops upstream.

> b) The implementations are typically for port authentication not
> subscriber control, and has allot of challenges being used for more
> than that.

	Sorry, I don't understand.

> c) As I detailed in an earlier email the layer 2 security on 
> intermediate switches/dslam's is provisioned by DHCP. So if a and b
> are ignored to use 802.1x you either need to limit the topology so
> that security at Layer 2 is not needed or implement a new protocol to
> back propagate, security policy events.

	Sorry, I can't see any logic there.

> Hope that helps your understanding,

	Yes indeed.

	You've convinced me that it stands to reason that your draft
	should not be adopted as as a working group item.  I don't
	claim that my view matters.

	Thank you.

	Best regards,

	Niall O'Reilly

---

From: Ted Lemon <[email-masked]>
Date: Thu, 18 Feb 2010 10:35:20 -0700

> 	not one or more hops upstream.

It's content-free statements like this that really make this discussion frustrating for me.   In debate here at the Buddhist retreat center where I'm staying at the moment, we insist that any assertion be backed by a reason.   If the reason is correct and applicable, then the assertion is true.   If the reason can be shown to be incorrect, or not applicable, then the assertion hasn't been shown to be true (or false either, for that matter).

Unfortunately, in this discussion, I see a lot of assertions, and very few reasons.   And in the rare cases where I do see reasons, often they either aren't true, or don't apply.   This is poison for a debate, because it's impossible to ever reach any sustainable conclusion if we don't subject ourself to the rules of logic.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 18 Feb 2010 13:08:43 -0700

BTW, having bitten Niall's head off about logic, I should point out that I didn't intend to single him out - he just happened to give me a really good example of incomplete logic to talk about.

At the moment this discussion suffers from an extreme lack of clarity.   People have positions, but the arguments they use to justify their positions never reach up to the level of actual logical justification - they are all of the same kind as Niall's argument: simple, unsupported assertions.

It's very clear to me that if the authors had just adopted PANA several years ago instead of proposing this new DHCP-based scheme, they'd already be shipping working implementations.   I presume that they are also aware of this.   So why didn't they just do this?   There must be some reason.   I'm not satisfied with any of the answers I've heard thus far.

Designing a protocol in the IETF around the inadequacies of some vendor's provisioning system is a truly horrifying thought.   Someone proposed that on the DNSEXT mailing list the other day with, as far as I can tell, a complete lack of irony.   This is not what the IETF is supposed to be about, and it's not something I support.   If the real reason for this DHCP extension is that your provisioning system is junk, build a shim. This is not a reason to do a protocol extension.

But the people here who are proposing these extensions are smart people.   There has to be some reason behind it that they can articulate that's better than "my provisioning system is junk."

I'd really like to hear those arguments.   That's the reason I've been willing to take this work on.   It's not because I support the protocol as written.   You can see that from reading the analysis doc - it proposes a number of very substantial changes to the protocol that I think are required before the working group could consider it a valid offering.   The protocol spec as written clearly can't be forwarded to the IESG.

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 19 Feb 2010 00:55:22 +0200

Ted,

> BTW, having bitten Niall's head off about logic, I should point out
> that I didn't intend to single him out - he just happened to give me a
> really good example of incomplete logic to talk about.
> 
> At the moment this discussion suffers from an extreme lack of clarity.
> People have positions, but the arguments they use to justify their
> positions never reach up to the level of actual logical justification -
> they are all of the same kind as Niall's argument: simple, unsupported
> assertions.

"they are all of the same kind" ??
That's so unfair to all these people who are trying to explain why this is
such a bad idea for the 4th round in IETF! (Even Niall's point I understand,
maybe because of my background on network access security. This is a network
security discussion in DHC WG after all :-). 

If anything is not clear, I think asking for elaboration is a better
approach.

> It's very clear to me that if the authors had just adopted PANA several
> years ago instead of proposing this new DHCP-based scheme, they'd
> already be shipping working implementations.   I presume that they are
> also aware of this.   So why didn't they just do this?   There must be
> some reason.   I'm not satisfied with any of the answers I've heard
> thus far.
> 
> Designing a protocol in the IETF around the inadequacies of some
> vendor's provisioning system is a truly horrifying thought.   Someone
> proposed that on the DNSEXT mailing list the other day with, as far as
> I can tell, a complete lack of irony.   

Let me take us back to Oct 2006, when this concept first appeared from
another company.

http://www.ietf.org/mail-archive/web/dhcwg/current/msg06599.html
http://www.ietf.org/mail-archive/web/dhcwg/current/msg06594.html

It was killed on the spot. But then, someone else took the torch, and in the
past 3+ years this idea got rejected in 4 rounds of discussions and we are
still wondering "maybe there is something good in it?".... The only question
in my mind is how come we are not able to reach the bottom on this?

> This is not what the IETF is
> supposed to be about, and it's not something I support.   If the real
> reason for this DHCP extension is that your provisioning system is
> junk, build a shim. This is not a reason to do a protocol extension.
> 
> But the people here who are proposing these extensions are smart
> people.   There has to be some reason behind it that they can
> articulate that's better than "my provisioning system is junk."

If all you have is a hammer, everything looks like nail....

> I'd really like to hear those arguments.   That's the reason I've been
> willing to take this work on.   It's not because I support the protocol
> as written.   You can see that from reading the analysis doc - it
> proposes a number of very substantial changes to the protocol that I
> think are required before the working group could consider it a valid
> offering.   The protocol spec as written clearly can't be forwarded to
> the IESG.

Regards

---

From: Ted Lemon <[email-masked]>
Date: Thu, 18 Feb 2010 16:15:14 -0700

> security discussion in DHC WG after all :-). 

Well, if it's unfair, then that would imply that Niall had said something everybody could agree on, and that arguments similar to Niall's that have been presented in the past had the same quality.   But that's clearly not so.   Hence my criticism.

> If anything is not clear, I think asking for elaboration is a better

I don't need to ask for elaboration.   I understand why Niall thinks what he does, and why you think what you do.   I don't agree with Niall, though, and his assertion is in fact addressed in the analysis document.

> in my mind is how come we are not able to reach the bottom on this?

Because the arguments against it have never been clear, and have never been captured.   The primary argument against it is that we shouldn't use DHCP because PANA does the same thing.   If that's so, why are people so resistant to using PANA?   Why do these proposals keep coming up?   Why didn't we standardize on PANA as the solution to this problem four years ago?   If we could come up with a clear answer to that question, it would help us to take the next incremental step forward, instead of repeating history over and over again.

> If all you have is a hammer, everything looks like nail....

Now this really is unfair.   Essentially you are saying that the proponents of this solution are stupid.   They aren't.   So when you say something like this with the intention of discrediting your opponents in this argument, it just makes you look bad - it does nothing to support your position.   I do not mean you any disrespect when I say this, because in fact of all the participants in this discussion, you've contributed the most value (in my personal opinion, I hasten to add).  But please give this particular argument a rest - it's useless.

I want to know why we keep having this conversation, and why PANA wasn't adopted four years ago.   What's the missing piece in the architecture that PANA doesn't provide that leads people to keep pushing DHCP as the right transport for EAP in this problem space?

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 19 Feb 2010 09:25:17 +0900

> I want to know why we keep having this conversation, and why PANA wasn't adopted four years ago.   What's the missing piece in the architecture that PANA doesn't provide that leads people to keep p…

I believe nothing is missing in PANA in the architecture, 
and this was also backed up by David Miles mentioning "PANA 
achieves all it was set out to do it".  He also mentioned 
"but it adds one more thing to the mix" and "DHCP provides 
an attractive because it is already implemented and 
understood" to justify EAP-DHCP.  However, based on the 
content of the analysis document, his justification seems 
weak to convince opponents of EAPoDHCP including me.

Yoshihiro Ohba

---

From: Ted Lemon <[email-masked]>
Date: Thu, 18 Feb 2010 22:47:14 -0700

On Feb 18, 2010, at 5:25 PM, Yoshihiro Ohba wrote:
> He also mentioned 

That is a weak justification.   It's far too weak to justify all the effort that's gone into this.   Hence my question.

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 19 Feb 2010 08:23:17 -0600

> From Ted Lemon, February 19, 2010 12:47 AM
> 
> That is a weak justification.   It's far too weak to justify all the
> effort that's gone into this.   Hence my question.

The reasons I return to are (1) cost, (2) complexity, (3) minimizing
changes to DSLAMs, and (4) end user experience:

(1) Cost
a) For Broadband, PANA has more messages between client & server.  This
means more processing, and therefore fewer sessions which can be
supported on the BRAS.
b) PANA was initially not on a fixed port so it could not be snooped
(this something I believe that has changed but still played a factor
when DHCP Auth was kicked off).
c) We now have an operational EAPoUDP implementation (both Client &
Server).  I don't want to spend money again to develop something which
isn't as deployable.  Nevertheless, I will spend the money if customers
ask for PANA.  But they aren't asking for PANA (IMHO for the other
reasons below).

(2) Complexity
a) More messages mean more interim error states.   Each of these interim
states needs to be debuggable by an SP's help desk.   (Customers &
help-desks are used to PPPoE where authentication happens before Public
IP address assignment.  There aren't interim states which need debugging
during a customer call to a help desk.)  
b) A historical lesson which drove our thinking is the slow adoption of
802.1x in the wired Enterprise market. The lack of bonding &
explicit/consistent behavior between 802.1x and DHCP state machines led
to poor interoperability in implementation.  End users had to wait for
802.1x timeouts to expire before a reattempt at authentication gained
them network access.  The result is Network Operators frustrated with
complaining end users turned off 802.1x.  Broadband providers can't
afford to turn off authentication.
c) It might be easy to say "a perfect implementation will mean these
problems won't occur".  But there are at least three types of vendor
boxes involved (CPE, DSLAM, BRAS).  A simpler specification with
deterministic interworking of elements is a huge advantage.

(3) Minimizing changes to DSLAMs
a) Some DSLAMs pass a wide variety of DHCP messages prior to IP address
assignment, fewer pass PANA.  There is more work/cost in fixing things
for a PANA (i.e., DSLAM vendors have told us it is implementing PANA
snooping on the DSLAM is more expensive that retrofitting existing DHCP
snooping).
b) We needed a protocol that solves the problem at Layer 2 prior to the
commencement of Layer 3 packets.  Since we started building DHCP Auth,
PANA has invented an IP packets without IP addresses mode.  Still this
new mode is likely to be harder to implement than 2 new DHCP messages.

(4) End User Experience
With PANA, CPE & PCs can get an interim IP address which is later
reassigned to a public one.  It can look to a user or application like
WAN connectivity exists, when actually you are awaiting some timeout to
a DHCP-Renew before you get your real public address.

Despite years of email list arguments, IMHO enough of these reasons
remain for Broadband to justify DHCP Auth within this WG.   The
alternative is the publication of this spec via another process (which
is far less optimal). 

Ted, I would be glad to reply to you if you have questions on my email.
For others, please refer to the many dialogs from the intarea & dhcpwg
from 2007.  (My apologies, but I just don't have the cycles to rehash
these old arguments once again.)

Eric

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sat, 20 Feb 2010 02:10:13 +0900

> means more processing, and therefore fewer sessions which can be

If we just replace EAPoDHCP exchanges in draft-pruss with
PANA messages, then PANA requires only one additional
message (i.e., the last PANA-Auth-Answer message from PaC to
PAA) since DHCPDISCOVER can be used as a trigger for 
PAA-initiated PANA session.  This is a very minor difference 
to me.

> when DHCP Auth was kicked off).

PANA is on a fixed port number (716).

> ask for PANA.  But they aren't asking for PANA (IMHO for the other

EAPoDHCP will require significant changes suggested by the
analysis document.  So I think your justification about
deployment cost is still weak.

> during a customer call to a help desk.)

As I mentioned above, there is only one message difference
and the number of interim states is not so different.
I think this is a weak justification.

> afford to turn off authentication.

PANA does not have this problem because PANA explicitly
carries session lifetime.

> deterministic interworking of elements is a huge advantage.

Since EAPoDHCP will require significant changes based on the
analysis draft, I am not convinced to qualify that EAPoDHCP 
is a simpler specification.

> snooping on the DSLAM is more expensive that retrofitting existing DHCP

I have never been convinced on this.  Why passing one
additional protocol is more expensive?  "DSL vendors have
tols us" is actually not giving a technical reason.

> new mode is likely to be harder to implement than 2 new DHCP messages.

This still lacks actual technical reason for why
implementing PANA without IP address mode is harder than
EAPoDHCP.

> a DHCP-Renew before you get your real public address.

The interim IP address is not needed for PANA.

> alternative is the publication of this spec via another process (which

Thank you for listing the arguments, however, all of the
above points seems still weak or incorrect.

Regards,
Yoshihiro Ohba

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 19 Feb 2010 12:06:03 -0600

> From: Yoshihiro Ohba, February 19, 2010 12:10 PM

Yoshihiro, I respect the honorable way you have stewarded & championed
PANA.  Nevertheless, PANA has been presented multiple times at the BBF.
And multiple times the BBF has liaisoned to the IETF asking for
something else.  If the sum of all arguments were weak/incorrect, this
wouldn't be happening.

Eric

---

From: Ted Lemon <[email-masked]>
Date: Fri, 19 Feb 2010 11:28:43 -0700

> tols us" is actually not giving a technical reason.

On this question in particular, I have to admit that I don't understand the point being made.   The EAP-over-DHCP protocol seems to me to require *substantial* changes to the DSLAM, because the relay is not a simple DHCP relay anymore - it has to do all sorts of proxying and manage complete state machines for every client.   So to me this is actually *more* complex than using PANA.   What am I missing?

In any case, Ohba-san's point is well-taken: if there is a technical reason why this is hard, we should be given the reasons why it is hard, not simply assured that someone said it was hard.

>> alternative is the publication of this spec via another process (which

Publication of the spec in its current state would be disastrous, not just "less optimal," because there are a number of serious problems in the spec which are called out in the analysis doc which have not yet been addressed.   So yes, I agree that proceeding with this specification outside of the DHC working group would be a bad idea, since in all likelihood the problems raised in the analysis doc would not be addressed if that were to happen.

> PANA has been presented multiple times at the BBF.

Unfortunately those of us here in the IETF haven't all been privy to the discussions in the BBF about PANA, and we don't know why PANA has been rejected.   This is what I'm trying to get to.   There seems to be strong resistance to PANA in the BBF.   This must be motivated by some concern that people there have.

There are two ways that this could go: either it is possible to address those concerns, or it is not.   If it is possible to address those concerns, then we really should, because what we are working on right now is not a great solution.   If we can't address those concerns, then I would much rather that the DHC working group come up with the solution that BBF wants than that the BBF just come up with it on their own without DHCwg review.

But right now it feels a bit like a "put up or shut up" situation.   The participants in the BBF have not actually said what the problem is.   There are weirdnesses to the proposed EAP-over-DHCP protocol that suggest to me that there is a lot of information the BBF hasn't conveyed to us that is motivating all of this.   Perhaps the BBF has conveyed this information to someone in the IETF, but the information hasn't been widely disseminated--I have not been privy to it, for instance, and it's certainly never been presented to the DHC working group.

What we've gotten from the people who've been pushing the EAP-over-DHCP protocol have been descriptions of *what* they want to do, not *why* they want to do it.   This is ineffective because it's pretty clear to anybody who's a DHCP expert that the current proposal isn't really the right way to solve the problem, even if EAP-over-DHCP is the right solution for this particular problem space.   You can see that reflected in the analysis document.   So when we are given *what* but not *why*, it's hard to even come up with proposals for what to change to make it better, because we don't know why it's the way it is in the first place.

So if we are going to do any work on this protocol, it would be nice to get to that level of the discussion.   But before we can even do any work on the protocol (assuming that's even possible), we need to understand why it has to be EAP-over-DHCP and not PANA.   If we can't resolve that question, than I really can't see this ever going anywhere in the IETF.   And since apparently there are concrete reasons why BBF doesn't want PANA right now, this is inevitably going to result in BBF going around the DHC working group to do an extension to DHCP the wrong way, which we will then be stuck with.

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 19 Feb 2010 17:28:09 -0600

> From: Ted Lemon, February 19, 2010 1:29 PM
> On this question in particular, I have to admit that I don't
understand
> the point being made.   The EAP-over-DHCP protocol seems to me to
> require *substantial* changes to the DSLAM, because the relay is not a
> simple DHCP relay anymore - it has to do all sorts of proxying and
> manage complete state machines for every client.   So to me this is
> actually *more* complex than using PANA.   What am I missing?

DHCP proxy runs in the BRAS, not the DSLAM.  I was hoping the eventual
DSLAM solution would be very simple: if an IP address is assigned back
to the client via DHCP, then the DSLAM can assume Authentication worked,
and then can open up the user port for IP communications.  Since the
DSLAMs are in a protected/trusted environment, any complex proxy is
unnecessary.
 
> In any case, Ohba-san's point is well-taken: if there is a technical
> reason why this is hard, we should be given the reasons why it is
hard,
> not simply assured that someone said it was hard.

My company isn't a DSLAM vendor.  But assuming DSLAMs transparently pass
EAP messages, it is logical to assume small changes to DSLAMs would
result.
 
> >> alternative is the publication of this spec via another process
> >> (which is far less optimal).
> 
> Publication of the spec in its current state would be disastrous, not
> just "less optimal," because there are a number of serious problems in
> the spec which are called out in the analysis doc which have not yet
> been addressed.   So yes, I agree that proceeding with this
> specification outside of the DHC working group would be a bad idea,
> since in all likelihood the problems raised in the analysis doc would
> not be addressed if that were to happen.

It is 30+ months since the liaison the BBF sent the IETF on
requirements.
 
> Unfortunately those of us here in the IETF haven't all been privy to
> the discussions in the BBF about PANA, and we don't know why PANA has
> been rejected.   This is what I'm trying to get to.   There seems to
be
> strong resistance to PANA in the BBF.   This must be motivated by some
> concern that people there have.
> 
> There are two ways that this could go: either it is possible to
address
> those concerns, or it is not.   If it is possible to address those
> concerns, then we really should, because what we are working on right
> now is not a great solution.   If we can't address those concerns,
then
> I would much rather that the DHC working group come up with the
> solution that BBF wants than that the BBF just come up with it on
their
> own without DHCwg review.

Looking at Bill W.'s message earlier in this thread, it looks like the
ball will be in the BBF's court if DHCWG doesn't pick this up.
 
> But right now it feels a bit like a "put up or shut up" situation.
> The participants in the BBF have not actually said what the problem
is.
> There are weirdnesses to the proposed EAP-over-DHCP protocol that
> suggest to me that there is a lot of information the BBF hasn't
> conveyed to us that is motivating all of this.   Perhaps the BBF has
> conveyed this information to someone in the IETF, but the information
> hasn't been widely disseminated--I have not been privy to it, for
> instance, and it's certainly never been presented to the DHC working
> group.

The liaison statements from BBF to IETF are a starting point: 

   Subscriber Authentication in DSL Networks
   https://datatracker.ietf.org/documents/LIAISON/file457.doc 

   DSL Forum Liaison to IETF Internet Area about WT146
   https://datatracker.ietf.org/documents/LIAISON/file458.doc 

   DSL Subscriber Authentication using DHCP
   https://datatracker.ietf.org/documents/LIAISON/file490.doc 

Of course no liaison statement will contain all the infinite details of
what happened at the BBF.  And I wasn't at the BBF, so I can't tell you.
Therefore all I can offer is the set of reasons I sent earlier today.
While some might characterize these reasons as "weak", I certainly do
not.  BTW: I do consider PANA to be much better than when the dialog
started those many months ago when the liaisons occurred.  But it still
isn't the "minimal changes to the network" that is highly desired.
 
> What we've gotten from the people who've been pushing the
EAP-over-DHCP
> protocol have been descriptions of *what* they want to do, not *why*
> they want to do it.   This is ineffective because it's pretty clear to
> anybody who's a DHCP expert that the current proposal isn't really the
> right way to solve the problem, even if EAP-over-DHCP is the right
> solution for this particular problem space.   You can see that
> reflected in the analysis document.   So when we are given *what* but
> not *why*, it's hard to even come up with proposals for what to change
> to make it better, because we don't know why it's the way it is in the
> first place.
> 
> So if we are going to do any work on this protocol, it would be nice
to
> get to that level of the discussion.   But before we can even do any
> work on the protocol (assuming that's even possible), we need to
> understand why it has to be EAP-over-DHCP and not PANA.   If we can't
> resolve that question, than I really can't see this ever going
anywhere
> in the IETF.   And since apparently there are concrete reasons why BBF
> doesn't want PANA right now, this is inevitably going to result in BBF
> going around the DHC working group to do an extension to DHCP the
wrong
> way, which we will then be stuck with.

I would love for DHCWG to play the main role.  But after 30+ months, I
am skeptical.

Eric

---

From: Richard Pruss <[email-masked]>
Date: Sat, 20 Feb 2010 10:26:33 +1000

> On this question in particular, I have to admit that I don't understand the point being made.   The EAP-over-DHCP protocol seems to me to require *substantial* changes to the DSLAM, because the rel…

Probably because of PANA folks hysterics you have misunderstood where DHCP proxy actually runs and runs today.

The DHCP proxy runs in the BRAS's; the BRAS wants to be stateful for all of the IP sessions, so it can do session behaviour enforcement, session accounting and much much more, so to do this we want to see all DHCP messages which is why the BRAS looks like a DHCP server to the Home Gateway and like a DHCP client to the real network DHCP servers, for deployments that want to manage IP addresses using a DHCP server instead of allocating them from a AAA server as part of the access accept.

The DSLAM just does DHCP snooping so it can enforce IP address. The change that has to happen in a subset of DSLAM's that check DHCP message numbers is they need to be updates to recognise the new messages types.  A single line update to a range or table variable at worst.

To those of us who understand building large Broadband switches PANA was clearly not designed for our environment.   Mark took a list of things
we thought we wrong and tried to get them fixed while he was AD, I know he got the static port so it can snooped by intermediate devices now, but
the protocol still has a ton of extra bumf we do not want or need and then does not have the things like intermediate nodes adding line information
we need.

Most of all for me as I have often said PANA happens after addressing which is too late to ensure layer 2 security. If we really wanted a layer 3 solution, their are many options in the IETF, personally I like HIP, but this is not what is need in the solution.

The problem I have is that the IETF has failed to be a place where I can have a dialog with my peers with implementations in broadband about
practical solutions for the real world.  Instead I find myself endlessly defending hysterics from a bunch of researchers from Toshiba and associates
motivated by the fact that they want us to choose their byzantine invention, or trying to explain parts of a complex system with hundreds of requirements
and interdependencies is simple ways to people who understanding is based on the dawn of the internet, with open campuses and free love. 

Personally I am off camping for the weekend and hopefully when I see this thread again, we will have a resolution one way or another.

Have a nice weekend,
- Ric

---

From: Ted Lemon <[email-masked]>
Date: Fri, 19 Feb 2010 21:01:56 -0700

> Probably because of PANA folks hysterics you have misunderstood where DHCP proxy actually runs and runs today.

I was able to gleam some useful information from this rant, Ric, but for you to accuse the PANA folks of hysterics is neither accurate nor wise.

---

From: Niall O'Reilly <[email-masked]>
Date: Sat, 20 Feb 2010 22:24:22 +0000

On 18/02/10 17:35, Ted Lemon wrote:
> It's content-free statements like this that really make this discussion frustrating for me.

	After re-reading my message a couple of times,  I can now see what you mean, Ted.  
	What I was trying to say can't have been evident, except for a reader accidentally
	attuned to my mindset.  I'm not sure that what I meant matters any more, as the 
	moment has passed, and subsequent messages have made it clearer why 802.1x doesn't 
	seem to be part of the solution.

	Apologies to all, especially to Ric, for this lack of consideration on my part.

	Best regards,

	Niall O'Reilly

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Sun, 21 Feb 2010 09:45:51 +0200

Just a quick comment: While the statement of where to put access control
sounds "content-free" it actually isn't. 

When you look at the different access authentication architectures in
different systems (e.g. Wimax Forum, LTE, 3G) then you will notice that
questions around where to place the policy decision point, where policy
enforcement happens and where to terminate security for user traffic is
a very crutual question with far-reaching implications. 

Ciao
Hannes

>On Behalf Of ext Niall O'Reilly
>Sent: 21 February, 2010 00:24
>To: Ted Lemon
>Cc: DHC WG

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 22 Feb 2010 10:34:01 +0200

Ted,

> Well, if it's unfair, then that would imply that Niall had said
> something everybody could agree on, and that arguments similar to
> Niall's that have been presented in the past had the same quality.
> But that's clearly not so.   Hence my criticism.

Maybe there is a misunderstanding in here. I thought you had say "they" as
in "all the arguments from everyone". I agree that one argument from Niall
was not well articulated, but claiming all the argument from everyone have
the same issue is what I reacted to. 

> I don't need to ask for elaboration.   I understand why Niall thinks
> what he does, and why you think what you do.   I don't agree with
> Niall, though, and his assertion is in fact addressed in the analysis
> document.
> 
> Because the arguments against it have never been clear, 

I respectfully disagree.  

> and have never
> been captured.   The primary argument against it is that we shouldn't
> use DHCP because PANA does the same thing. 

No. Of course not. Even if PANA had not existed, or even if BBF were not to
accept PANA, EAPoDHCP is a bad idea... in absolute terms. Almost all of my
arguments are centered around that (please see my emails), and I know many
other people's are also coming from the same angle. Please see their emails
too. 

>  If that's so, why are
> people so resistant to using PANA?   Why do these proposals keep coming
> up?   Why didn't we standardize on PANA as the solution to this problem
> four years ago?   If we could come up with a clear answer to that
> question, it would help us to take the next incremental step forward,
> instead of repeating history over and over again.
> 
> Now this really is unfair.   Essentially you are saying that the
> proponents of this solution are stupid.  

Of course not! This is all about being an engineer, and even part of human
nature. I was trying to explain to you why people see things differently. It
has nothing to do with what you are saying.

> They aren't.   So when you
> say something like this with the intention of discrediting your
> opponents in this argument, it just makes you look bad - it does
> nothing to support your position.   I do not mean you any disrespect
> when I say this, because in fact of all the participants in this
> discussion, you've contributed the most value (in my personal opinion,
> I hasten to add).  But please give this particular argument a rest -
> it's useless.
> 
> I want to know why we keep having this conversation, and why PANA
> wasn't adopted four years ago. 

This is very clear to me. People embarked on this path because option 82 was
already used and they thought they could get to EAP with an addition of one
simple DHCP option. If it were so simple, they could have been done easily.
But over time people realized that it is not that simple. Meanwhile I guess
some people invested time/money on it, and they are not willing to let go.

>  What's the missing piece in the
> architecture that PANA doesn't provide that leads people to keep
> pushing DHCP as the right transport for EAP in this problem space?

Unfortunately, people who pushed EAPoDHCP gave the impression that EAPoDHCP
is so simple, and PANA has so many issues. Because they are quite
influential in BBF (and PANA folks has nowhere near representation there),
they built momentum there, which we are trying to technically clear up here
in IETF.

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 22 Feb 2010 11:24:15 +0200

> The DSLAM just does DHCP snooping so it can enforce IP address. The
> change that has to happen in a subset of DSLAM's that check DHCP
> message numbers is they need to be updates to recognise the new
> messages types.  A single line update to a range or table variable at
> worst.

Since you sound like familiar with DSLAM implementations, please also tell
us how many lines of code needs to change to recognize PANA.

> To those of us who understand building large Broadband switches PANA
> was clearly not designed for our environment.   Mark took a list of
> things
> we thought we wrong and tried to get them fixed while he was AD, I know
> he got the static port so it can snooped by intermediate devices now,
> but
> the protocol still has a ton of extra bumf we do not want or need 

For example?

> and
> then does not have the things like intermediate nodes adding line
> information
> we need.

Nothing prevents that. 

> Most of all for me as I have often said PANA happens after addressing
> which is too late to ensure layer 2 security. 

Too many wrongs in one single sentence.
First of all, EAPoDHCP is not really L2 security. IEEE 802.1X is an example
of L2 security.
Secondly, for EAPoDHCPv6, you start off with using an IPv6 link-local
address. 
Third, you can also run PANA with unspecified IPv4 address. See Section
6.5.4 in http://tools.ietf.org/html/draft-ietf-pana-panaoverdsl-01 (there'll
be a separate I-D soon). 

> If we really wanted a
> layer 3 solution, their are many options in the IETF, personally I like
> HIP, but this is not what is need in the solution.

Sure, IETF can discuss that too. In fact, all these should be considered by
IETF.

> 
> The problem I have is that the IETF has failed to be a place where I
> can have a dialog with my peers with implementations in broadband about
> practical solutions for the real world.  Instead I find myself
> endlessly defending hysterics from a bunch of researchers from Toshiba
> and associates
> motivated by the fact that they want us to choose their byzantine
> invention, or trying to explain parts of a complex system with hundreds
> of requirements
> and interdependencies is simple ways to people who understanding is
> based on the dawn of the internet, with open campuses and free love.
> 
> Personally I am off camping for the weekend and hopefully when I see
> this thread again, we will have a resolution one way or another.
> 
> Have a nice weekend,
> - Ric
> 
> 
>

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 22 Feb 2010 11:44:54 +0200

Ted,

> So if we are going to do any work on this protocol, it would be nice to
> resolve that question, than I really can't see this ever going anywhere
> going around the DHC working group to do an extension to DHCP the wrong

You are under the impression that BBF has already decided to use EAPoDHCP.
Where do you get that from? The latest liaison from DSLForum/BBF said:

	At this time, we would like to make the IETF aware that during our
most recent DSL Forum 
	quarterly meeting, the Architecture and Transport Working Group
agreed to seriously 
	consider adopting a mechanism such as that proposed in
draft-pruss-dhcp-auth-dsl-01.txt 
	or draft-zhao-dhc-user-authentication-02.

If BBF has made an official decision to adopt EAPoDHCP, then we better get
an update on that. In the absence of such an update, we cannot go with
EAPoDHCP supporters' "Ship has already sailed" claims. 

As far as I know, BBF is gating its decision to get IETF's feedback on
EAPoDHCP. Can anyone claim that BBF will adopt EAPoDHP even if IETF rejects
the idea?

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 22 Feb 2010 12:00:51 +0200

I'll jump to the parts that I have something to add.

> isn't as deployable.  

I didn't understand that part. You have a proprietary PANA solution.

> Nevertheless, I will spend the money if customers

If this were true, then one would expect no SDO/industry to ever use L2
authentication. But that was not the case with 3GPP, 3GPP2, WMF, Cablelabs.
1X's faith was shaped by multiple factors, including lack of client support
and availability of a client-less solution. 

> snooping on the DSLAM is more expensive that retrofitting existing DHCP

That would be true. But how much more, and how that factor weighs in along
with all the other factors? These are important things. 

> new mode is likely to be harder to implement than 2 new DHCP messages.

Why?

> a DHCP-Renew before you get your real public address.

This does not happen.
Either you are using unspec IP address, and that does not happen.
Or, if you are using IPv6 link-local address (btw, your DHCPv6 client uses
that too!), apps don't use that address. 
You could have this problem with IPv4 link-local address, but there you
don't wait for timeout, instead you trigger DHCP to get an IP address.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 22 Feb 2010 10:26:27 -0700

On Feb 21, 2010, at 12:45 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
> a very crucial question with far-reaching implications. 

This is true.   But Niall stated a conclusion to the question you propose here with no supporting evidence.   In some use cases, what he said is exactly true.   But it is not true for all cases.   He didn't qualify what he said, nor give a reason why it was true.   That's what I meant by "content-free."  I don't mean that Niall is completely wrong.   What I mean is that because made his statement in such an unqualified way, it was misleading to anyone who didn't know the context in which he stated it.   

Statements like this do not help us to get to consensus - we need to be clear in how we express ourselves.   We need to avoid muddying the debate with generalisms, as in Niall's case, ad-hominem attacks (I won't say who) and emotional statements that, while they may be founded in reason, do not express that reason, and thus do not advance the debate.

It might feel like muddying the debate is a useful tactic, in that it prevents us from making forward progress.   To an opponent of the work we're talking about, that might seem like a good idea.   But even opponents of this work have expressed to me privately how discouraged they are with the time it's taken to get to closure on this issue.   So for the sake of all the participants, please try to think clearly about what you say before you say it, and don't just shoot from the hip.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 22 Feb 2010 10:33:54 -0700

> You are under the impression that BBF has already decided to use EAPoDHCP.

No.   But the only proposals I am aware of advance some form of authentication using DHCP as the transport.   If you are aware of some proposal that uses PANA or some other mechanism to do this, I would like to hear about it.

The point I was making is that the BBF has a real business need to solve this problem. If we don't participate, they will solve it without us.   And since we are not aware of any solutions being advanced in the BBF that are not based on DHCP, that is something we (the DHC working group) should be concerned about.

I am not saying the ship has sailed.   I am saying that some ship will sail, and we can either have a say in which ship it is, or we can abstain.   We don't get to vote for no ship sailing.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 22 Feb 2010 10:36:22 -0700

> that too!), apps don't use that address. 

Point of clarity: apps do use that address.   Just not for off-subnet communications.   E.g., because IPv4 autoconf is so badly broken, Bonjour typically uses IPv6 link-local for ad-hoc communication on unconfigured networks.

---

From: Alan Kavanagh <[email-masked]>
Date: Mon, 22 Feb 2010 13:10:39 -0500

Hi Alper

I can not speak on behalf of the BBF but as a BBF delegate, no decision has been made Authentication in BBF.

BR
Alan 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alper Yegin
Sent: February 22, 2010 4:45 AM
To: 'Ted Lemon'; 'Eric Voit (evoit)'
Cc: 'DHC WG'
Subject: Re: [dhcwg] Adopt draft-pruss-dhcp-auth-dsl as a working group item?

Ted,

> wrong way, which we will then be stuck with.

	At this time, we would like to make the IETF aware that during our most recent DSL Forum 
	quarterly meeting, the Architecture and Transport Working Group agreed to seriously 
	consider adopting a mechanism such as that proposed in draft-pruss-dhcp-auth-dsl-01.txt 
	or draft-zhao-dhc-user-authentication-02.

If BBF has made an official decision to adopt EAPoDHCP, then we better get an update on that. In the absence of such an update, we cannot go with EAPoDHCP supporters' "Ship has already sailed" claims. 

As far as I know, BBF is gating its decision to get IETF's feedback on EAPoDHCP. Can anyone claim that BBF will adopt EAPoDHP even if IETF rejects the idea?

---

From: Ted Lemon <[email-masked]>
Date: Mon, 22 Feb 2010 11:40:25 -0700

> As far as I know, BBF is gating its decision to get IETF's feedback on EAPoDHCP. Can anyone claim that BBF will adopt EAPoDHP even if IETF rejects the idea?

BTW, what's going on here is that at the moment we don't have consensus to proceed with EAP over DHCP.   That's not the same thing as saying that we've rejected it - there is strong support for it.   There's just also strong opposition to it.

---

From: Alan Kavanagh <[email-masked]>
Date: Mon, 22 Feb 2010 14:30:34 -0500

It might be useful to revisit what uses we intend to use DHCP_Auth for in Fixed BB Networks, excuse if this has exercise has already been completed. Would it be useful to have BBF list all the requirements that Protocol "X" should fulfill?

BR
Alan

---

From: Ralph Droms <[email-masked]>
Date: Mon, 22 Feb 2010 14:37:26 -0500

The BBF has already supplied a list of requirements.  See the liaison  
from BBF dated 10/2007: https://datatracker.ietf.org/documents/LIAISON/file490.doc

- Ralph

On Feb 22, 2010, at 2:30 PM 2/22/10, Alan Kavanagh wrote:

> It might be useful to revisit what uses we intend to use DHCP_Auth  
> for in Fixed BB Networks, excuse if this has exercise has already  
> been completed. Would it be useful to have BBF list all the  
> requirements that Protocol "X" should fulfill?
>
> BR
> Alan
>
>> As far as I know, BBF is gating its decision to get IETF's feedback  
>> on EAPoDHCP. Can anyone claim that BBF will adopt EAPoDHP even if  
>> IETF rejects the idea?
>
> BTW, what's going on here is that at the moment we don't have  
> consensus to proceed with EAP over DHCP.   That's not the same thing  
> as saying that we've rejected it - there is strong support for it.    
> There's just also strong opposition to it.
>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 22 Feb 2010 12:42:55 -0700

> It might be useful to revisit what uses we intend to use DHCP_Auth for in Fixed BB Networks, excuse if this has exercise has already been completed. Would it be useful to have BBF list all the requ…

They did.   It's in the liason statements, links to which Eric Voit provided on Friday.

---

From: Alan Kavanagh <[email-masked]>
Date: Mon, 22 Feb 2010 16:00:01 -0500

Hi Ralph

That liaison is 3 years old and im not quite sure how useful that is now given the changes and additional requirements we have encountered in BBF todate. 

Alan 

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]] 
Sent: February 22, 2010 2:37 PM
To: Alan Kavanagh
Cc: Ted Lemon; dhc WG
Subject: Re: [dhcwg] Adopt draft-pruss-dhcp-auth-dsl as a working group item?

References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <000001caaedf$b288a4c0$1799ee40$@net> <[email-masked]> <[email-masked]> <[email-masked]>	<[email-masked]> <[email-masked]>	<[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <06c301cab3a3$b385ec20$1a91c460$@yegin@ye gin.org> <[email-masked]> <[email-masked]> <[email-masked]>
X-Mailer: Apple Mail (2.936)
X-Brightmail-Tracker: AAAAAxLvYBgS8Ar0EvA+eQ==
X-OriginalArrivalTime: 22 Feb 2010 19:37:31.0685 (UTC) FILETIME=[79989550:01CAB3F6]

The BBF has already supplied a list of requirements.  See the liaison from BBF dated 10/2007: https://datatracker.ietf.org/documents/LIAISON/file490.doc

- Ralph

On Feb 22, 2010, at 2:30 PM 2/22/10, Alan Kavanagh wrote:

> It might be useful to revisit what uses we intend to use DHCP_Auth for 
> in Fixed BB Networks, excuse if this has exercise has already been 
> completed. Would it be useful to have BBF list all the requirements 
> that Protocol "X" should fulfill?
>
> BR
> Alan
>

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 23 Feb 2010 11:30:32 +0200

Ted,

You are trying to have a discussion here that actually belongs to BBF.

BBF is the right place for discussing all proposals and making a decision
accordingly.
How can we know all the proposals, and make a judgment here in DHC WG?
With all due respect, that's plain wrong (*).

IETF Int-Area has asked DHC WG if EAPoDHCP is a good idea. Plain and simple
question.
Based on the DHC WG's feedback, Int-Area and in fact IETF (this is a
security discussion, not even Int-area matter, right ;-) can formulate an
opinion, which not only includes a response about EAPoDHCP, but it can also
include other feedback (e.g., recommending PANA, etc.). 

And BBF takes that IETF input, and looks at other options, and makes the
final decision.

You appear to be jumping lines and expecting the DHC WG to make a decision
on EAPoDHCP as if we are discussing this in BBF.

(*) I don't mean to look like I'm not answering your question, hence these
lines now....
PANA is a candidate. BBF indicated "We still have unresolved concerns and it
is unlikely that we will specify the use of PANA in its current form." That
was when the EAPoDHCP picture was really rosy. With all the feedback IETF
has been generating on EAPoDHCP, I'm confident that PANA can be
reconsidered. On top of that, again, there may be other proposals available
or in the works. I don't know....

Also, see requirement #20 from BBF:

IPAuth-20:   Must have a logical path towards standardization

So, should we still be scared that BBF would standardize DHCP-based solution
on its own (and despite the current feedback)?

Regards,

Alper

> No.   But the only proposals I am aware of advance some form of
> authentication using DHCP as the transport.   If you are aware of some
> proposal that uses PANA or some other mechanism to do this, I would
> like to hear about it.
> 
> The point I was making is that the BBF has a real business need to
> solve this problem. If we don't participate, they will solve it without
> us.   And since we are not aware of any solutions being advanced in the
> BBF that are not based on DHCP, that is something we (the DHC working
> group) should be concerned about.
> 
> I am not saying the ship has sailed.   I am saying that some ship will
> sail, and we can either have a say in which ship it is, or we can
> abstain.   We don't get to vote for no ship sailing.

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 23 Feb 2010 11:37:03 +0200

By my count 6 yes, 10 no for EAPoDHCP in this round.

Is there a difference between IETF members not accepting the idea 4 times
within 3+ years, and IETF rejecting an idea?

> Sent: Monday, February 22, 2010 8:40 PM
> To: DHC WG
> on EAPoDHCP. Can anyone claim that BBF will adopt EAPoDHP even if IETF
> rejects the idea?
> 
> BTW, what's going on here is that at the moment we don't have consensus
> to proceed with EAP over DHCP.   That's not the same thing as saying
> that we've rejected it - there is strong support for it.   There's just
> also strong opposition to it.
>

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 23 Feb 2010 11:51:00 +0200

IPAuth-6:    Must fit into TR-101 operational model

EAPoDHCP does not fit that because TR-101 requires BRAS be operating as
DHCP-relay and EAPoDHCP analysis states "For this reason, we strongly
recommend that the authors abandon the idea of implementing this protocol
extension in the relay agent."

IPAuth-7:    Must support revoking authentication
IPAuth-15:   Must offer an option to re-authenticate periodically or on
demand.

Not sure how these are satisfied.

IPAuth-18:   Must allow for multiple authenticated subscribers on same
physical or logical interface.

Does it mean that one needs to run DHCP multiple times (and configure an IP
address for each)? Again, I'm not sure how this is satisfied.

> Of Ralph Droms
> Sent: Monday, February 22, 2010 9:37 PM
> To: Alan Kavanagh
> Cc: dhc WG; Ted Lemon
> from BBF dated 10/2007:

---

From: Richard Pruss <[email-masked]>
Date: Tue, 23 Feb 2010 20:25:08 +1000

> extension in the relay agent."

I believe I have explained the difference between DHCP relay and DHCP proxy to death and
the BRAS in TR-101 is obviously stateful for the session, and obviously a proxy and obviously
DHCP auth works there as that were it is getting testing in SP's today.

Can you try use one inch of common sense in your statement, do you really think
three main vendors in a market space would somehow suggest a solution that does
not meet the market requirements?

> address for each)? Again, I'm not sure how this is satisfied.

Yes, Alper, it means in DSL we can have multiple VLAN's on a single physical connection
and the requirement is to authenticate each of them separately.  It also means that we
could have a bunch end-hosts on what looks like a single physical line at the BRAS, common
in something like Passive Optical networks and we need to authenticate all of them.
And yes we simply run DHCP Auth for each, so yes this works,

What is so telling for me about all your statements is that you do not have even a vague idea
of what a broadband network looks like or any of the details.

- Ric

---

From: Richard Pruss <[email-masked]>
Date: Tue, 23 Feb 2010 20:28:53 +1000

Well by my count three vendors and three SP's all actively in the market concerned spoke up
in favour.

To my knowledge nobody who has running code in this market has spoken against.

So my count is currently 6 yes and 0 no.

- Ric

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 23 Feb 2010 06:44:10 -0600

> From: Alper, February 23, 2010 4:31 AM
> 
> IETF Int-Area has asked DHC WG if EAPoDHCP is a good idea. Plain and
> simple question..... 

And the IETF executed a NO-OP/time-out.

> So, should we still be scared that BBF would standardize DHCP-based
> solution on its own (and despite the current feedback)?

Last week on this thread Bill Welsh said: "Juniper has submitted an
alternative DHCP solution to draft-pruss to BBF for March meeting."

Ric Pruss tried to do the right thing by driving the discussion at the
IETF.   He should be commended for this.  But this venue has proven far
too difficult to progress the discussion.  The track record of the last
30+ months demonstrates that the best interests of the Broadband
industry are served by migrating the effort to where a deployable result
can be achieved.

BTW: Anaheim is too late for the IETF waiting to decide on an action.
The BBF meets the previous week.

Eric

---

From: Ralph Droms <[email-masked]>
Date: Tue, 23 Feb 2010 09:38:58 -0500

Eric - I think you oversimplify when you claim "the IETF executed a NO- 
OP/time-out".  I explained the history in recent e-mail to the int- 
area working group. The dhc WG and the IETF have not been idle since  
the BBF sent the liaison asking the IETF to 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.

The dhc WG has completed an analysis of draft-pruss-dhcp-auth-dsl,  
and, even though there has been no consensus in the WG or the IETF to  
take on the work, the WG has helped the authors make significant  
improvements to draft-pruss-dhcp-auth-dsl.  I consider this a positive  
and tangible result.

Now, with the analysis and improved specification draft, the int-area  
can reconsider the issue for which it had no consensus and asked for  
more information.

To the dhcwg mailing list as a whole - this conversation would be  
better conducted, I think, in the broader int-area mailing list.   
Please read my e-mail at www.ietf.org/mail-archive/web/int-area/current/msg02097.html 
  and followup just to [email-masked].

- Ralph

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 23 Feb 2010 09:50:10 -0600

> From: Ralph Droms, February 23, 2010 9:39 AM
> 
> OP/time-out".  

Yes, I did over-simplify.  I do know much good work has occurred in
IETF.  And I certainly do appreciate the efforts of yourself, Ted, John,
Geoffrey & many others.

Nevertheless, I suspect 30 months of discussions within the IETF
constitutes a timeout from the perspective of the BBF liaison.  That was
the intent of my statement.  Certainly there are people on the DHC alias
asking whether the requirements are still the same as when the liaison
was sent.

Eric

---

From: Ted Lemon <[email-masked]>
Date: Tue, 23 Feb 2010 13:52:51 -0700

> within 3+ years, and IETF rejecting an idea?

Yes.   For the IETF to reject the idea, it would have to be the case that there was no support for it.   That's not the situation here.

Also, when this draft was first presented, it was extremely poorly specified, and wouldn't have been accepted even if it were the right idea.   The draft has matured quite a bit, although it's still unacceptable in its present form.   Thirty months is not a long time in the IETF, particularly when you have a draft that needs a lot of work.

E.g., DHCPv6 took much longer, and at one point we essentially threw out five years of work and started over.

My goal here isn't to second-guess the BBF.   It's to avoid a situation where the interests of the IETF and the BBF come into conflict in a way that has a serious negative impact on the DHCP protocol.

To be clear, on the one hand we have to do what the IESG has asked, which is to do an analysis of the proposal.   We have done that.   But the IESG is not the director of IETF business - it's a two way street.   The IESG doesn't tell working group members to do work, and then they do it, and otherwise they don't.   Rather, the IESG *can* ask working groups to do work, and working groups can also choose to do the work without any direction from the IESG.

If the working group were to take up this work (which it looks like isn't going to happen), that could be because someone came to the working group and advocated effectively in favor of the working group taking on the work.   That is what I think Ric hoped to do 30 months ago.   Unfortunately for him (and possibly for us), his advocacy hasn't been effective, for a variety of reasons.

So while I sympathize (STRONGLY!) with your desire for closure, it's simply not the case that the IETF has rejected this protocol.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 23 Feb 2010 13:58:26 -0700

On Feb 23, 2010, at 3:25 AM, Richard Pruss wrote:
> I believe I have explained the difference between DHCP relay and DHCP proxy to death and the BRAS in TR-101 is obviously stateful for the session, and obviously a proxy and obviously DHCP auth works there as that were it is getting testing in SP's today.

Ric, you need to do more than explain the difference.   In my personal (non-hat-wearing) opinion, you need to get rid of it.   The way you have the protocol specified is overly complex, incompatible with the way DHCP works, and hence undesirable.   You said you'd consider this when last we communicated on the topic, and now it sounds like you've forgotten that you said that (or maybe you meant something different than what I understood).

> Yes, Alper, it means in DSL we can have multiple VLAN's on a single physical connection and the requirement is to authenticate each of them separately.  It also means that we could have a bunch end-hosts on what looks like a single physical line at the BRAS, common in something like Passive Optical networks and we need to authenticate all of them.  And yes we simply run DHCP Auth for each, so yes this works,

This suggests that you need to choose a different DHCP server to contact based on the outcome of the authentication process.   Is this in fact the case?   Because it's not made clear (at least to my reading) in the spec.   This would go a long way toward explaining the complexity of your "DHCP proxy."

---

From: Richard Pruss <[email-masked]>
Date: Wed, 24 Feb 2010 07:55:01 +1000

> Ric, you need to do more than explain the difference.   In my personal (non-hat-wearing) opinion, you need to get rid of it.   The way you have the protocol specified is overly complex, incompatibl…

What I am considering doing is removing all mention of DHCP relay so it is clear that although the BRAS takes DHCP packets from the ethernet segment and sends them to the DHCP server it does so in a way that is different from traditional DHCP relay.  Ralph has a number of times pointed out we should document the differences in practice like the so called Proxy and the mapping of DHCP into AAA at some stage, a sentiment I agree with because it would make these conversations easier.

In saying that I must again point out that this is existing practice and did not evolve because of DHCP authentication, but evolved probably if I read the history correctly because the
BRAS side of the customer connection became unnumbered to save IP addresses, this design choice has been reinforced for many reasons over the years so it is hard to see the clear genesis.

> This suggests that you need to choose a different DHCP server to contact based on the outcome of the authentication process.   Is this in fact the case?   Because it's not made clear (at least to m…

Yes, the authentication process can result in the choice of both different AAA servers and DHCP servers.  This is what is commonly referred to as wholesale access scenarios, this
is common worldwide as it is often enforce by government regulation. Basically the access provider is required by law to allow equal access at layer 3 to ISP's.  This is commonly done by choosing ISP (and thus, DHCP, AAA and VRF or tunnel termination point) based on the @domain specified in the username.

This is the main business driver for why authentication needs to happen before IP address allocation.  I also believe all the Service Providers who responded with interest on the list are constrained by this sort of regulation.

Regards,
Ric

---

From: Hongyu Li <[email-masked]>
Date: Wed, 24 Feb 2010 10:41:39 +0800

> Sent: Tuesday, February 23, 2010 1:34 AM
> To: Alper Yegin
> Cc: 'DHC WG'
> No.   But the only proposals I am aware of advance some form 
> of authentication using DHCP as the transport.   If you are 
> aware of some proposal that uses PANA or some other mechanism 
> to do this, I would like to hear about it.
> 
> The point I was making is that the BBF has a real business 
> need to solve this problem. If we don't participate, they 
> will solve it without us.   And since we are not aware of any 
> solutions being advanced in the BBF that are not based on 
> DHCP, that is something we (the DHC working group) should be 
> concerned about.
> 

This may be true in IPv4. But now with IPv6 in BBF, DHCP is yet the biggest
boat, we do have a tiny one called SLAAC that are used by several big
telcos. However, DHCP may still be required even in SLAAC case.

Hongyu

---

From: Alan Kavanagh <[email-masked]>
Date: Tue, 23 Feb 2010 23:40:58 -0500

I agree with Ric that Authentication needs to occur before allocation of an IP Address and this is due to regulatory and deployment models seperating L-2 from L-3 access and therefore adm ctl should be performed also on L-3.

Alan  

-----Original Message-----
From: Richard Pruss [mailto:[email-masked]] 
Sent: February 23, 2010 4:55 PM
Cc: Alper Yegin; 'Ralph Droms'; Alan Kavanagh; 'dhc WG'
Subject: Re: [dhcwg] Adopt draft-pruss-dhcp-auth-dsl as a working group item?

References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <000001caaedf$b288a4c0$1799ee40$@net> <[email-masked]> <[email-masked]> <[email-masked]>	<[email-masked]> <[email-masked]>	<[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <06c301cab3a3$b385ec20$1a91c460$@yegin@ye  gin.org>	<1B6D0317D3A [email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <082c01cab46d$ba71b710$2f552530$@[email-masked]> <[email-masked]> <[email-masked]>
To: Ted Lemon <[email-masked]>
X-Mailer: Apple Mail (2.1077)
X-Brightmail-Tracker: AAAAARLvbOgReturn-Path: [email-masked]
X-OriginalArrivalTime: 23 Feb 2010 21:55:08.0394 (UTC) FILETIME=D6424A0:01CAB4D2]

In saying that I must again point out that this is existing practice and did not evolve because of DHCP authentication, but evolved probably if I read the history correctly because the BRAS side of the customer connection became unnumbered to save IP addresses, this design choice has been reinforced for many reasons over the years so it is hard to see the clear genesis.

> 
>> Yes, Alper, it means in DSL we can have multiple VLAN's on a single 
>> physical connection and the requirement is to authenticate each of 
>> them separately.  It also means that we could have a bunch end-hosts 
>> on what looks like a single physical line at the BRAS, common in 
>> something like Passive Optical networks and we need to authenticate 
>> all of them.  And yes we simply run DHCP Auth for each, so yes this 
>> works,
> 

Yes, the authentication process can result in the choice of both different AAA servers and DHCP servers.  This is what is commonly referred to as wholesale access scenarios, this is common worldwide as it is often enforce by government regulation. Basically the access provider is required by law to allow equal access at layer 3 to ISP's.  This is commonly done by choosing ISP (and thus, DHCP, AAA and VRF or tunnel termination point) based on the @domain specified in the username.

Regards,
Ric

---

From: Tom Taylor <[email-masked]>
Date: Tue, 23 Feb 2010 23:55:24 -0500

There's a disconnect between the model we're assuming in HOKEY and the model 
proposed here. HOKEY assumes EAP transport over L2 to the NAS, which then 
repackages the EAP into DIAMETER for transport to the EAP server. Why doesn't 
the BBF do that?

Alan Kavanagh wrote:
> References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <000001caaedf$b288a4c0$1799ee40$@net> <[email-masked]> <[email-masked]> <[email-masked]>	<[email-masked]> <[email-masked]>	<[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <06c301cab3a3$b385ec20$1a91c460$@yegin
@ye
>    gin.org>	<1B6D0317D3A [email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <082c01cab46d$ba71b710$2f552530$@[email-masked]> <[email-masked]> <[email-masked]>

---

From: Richard Pruss <[email-masked]>
Date: Wed, 24 Feb 2010 15:24:24 +1000

On 24/02/2010, at 2:55 PM, Tom Taylor wrote:

> There's a disconnect between the model we're assuming in HOKEY and the model proposed here. HOKEY assumes EAP transport over L2 to the NAS, which then repackages the EAP into DIAMETER for transport to the EAP server. Why doesn't the BBF do that?

You are correct Tom, we do assume EAP  transport over L2 to the NAS,  which then repackages the EAP  into RADIUS or DIAMETER  for transport to the EAP  server.
 The draft is really just about getting the EAP over that L2 hop using DHCP ( which is a layer two  protocol).  The  advantage of using DHCP  over some new layer two  transport is that the DSLAMs/first hop switches  will mark the customer line information into DHCP, this lets us couple who you claim to be with where you are to make a well-informed authentication.

In addition to that once the DHCP exchange is completed the switches use the completion of DHCP as explicit provisioning allowing customer traffic not just to the upstream NAS  that to other services upstream on layer 2, like voice gateways or video pumps.

-- Ric

---

From: Ted Lemon <[email-masked]>
Date: Tue, 23 Feb 2010 22:44:53 -0700

> The draft is really just about getting the EAP over that L2 hop using DHCP ( which is a layer two  protocol).  The  advantage of using DHCP over some new layer two  transport is that the DSLAMs/fir…

Okay, this totally makes sense, but why not just use the initial DHCP packet from the client to get the circuit information, and then trigger an EAP session originating from the BRAS using something other than DHCP as the transport?   Is there some reason why that model doesn't work?

---

From: Richard Pruss <[email-masked]>
Date: Wed, 24 Feb 2010 15:52:04 +1000

> Okay, this totally makes sense, but why not just use the initial DHCP packet from the client to get the circuit information, and then trigger an EAP session originating from the BRAS using somethin…

No,  no not really, that would kind of be exactly the same as what we're doing now, except that EAP message is would be encapsulated in something else, you still need to pause and DHCP state machines on the NAS  and end client, as we do for EAPoDHCP.  If you don't you run a strong risk of the DHCP clients timing out on getting no response and doing something weird.

 -- Ric

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 24 Feb 2010 11:36:09 +0200

Ric,

> DHCP auth works there as that were it is getting testing in SP's today.

According to TR-101:

5.5 DHCP Relay

These requirements describe the DHCP processing on Broadband Network
Gateways.

R-181 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.

So, you cannot discount DHCP relay from your I-D.

> physical connection

You are talking about "physical" interface. How about the "logical"
interface as stated in the requirement?

---

From: Richard Pruss <[email-masked]>
Date: Wed, 24 Feb 2010 20:18:47 +1000

> So, you cannot discount DHCP relay from your I-D.

Duh, one does not run authentication on an untrusted interface, the point of authentication is to
build a chain of trust.  More than that I am sure anyone would give that a DHCP proxy does all that a relay
does and so much more.

> interface as stated in the requirement? 

VLAN = Virtual Local Area Network is a logical interface on a ethernet interface.

- Ric

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 25 Feb 2010 00:08:58 +0900

> build a chain of trust.  More than that I am sure anyone would give that a DHCP proxy does all that a relay

That's why EAPoDHCP does not satisfy TR-101.  There is no 
TR-101 requirement to do "so much more" including being a 
stateful DHCP entity.

Yoshihiro Ohba

---

From: Alan Kavanagh <[email-masked]>
Date: Wed, 24 Feb 2010 10:16:52 -0500

Hi Ted

Because you still need something to carry the EAP packets, so think of DHCP providing the transport for the EAP to piggyback on ;-)

Alan

---

From: Ralph Droms <[email-masked]>
Date: Wed, 24 Feb 2010 07:46:50 -0500

(Moving to intarea mailing list)

In that case an updated list of requirements would be very helpful.

- Ralph

On Feb 22, 2010, at 4:00 PM 2/22/10, Alan Kavanagh wrote:

> Hi Ralph
>
> That liaison is 3 years old and im not quite sure how useful that is  
> now given the changes and additional requirements we have  
> encountered in BBF todate.
>
> Alan
>
> The BBF has already supplied a list of requirements.  See the  
> liaison from BBF dated 10/2007: https://datatracker.ietf.org/documents/LIAISON/file490.doc
>
> - Ralph
>
>> for

---

From: Ted Lemon <[email-masked]>
Date: Wed, 24 Feb 2010 11:59:52 -0700

> TR-101 requirement to do "so much more" including being a 

A thing, A, that is a superset of another thing, B, satisfies any requirement for B that does not specifically exclude the additional capabilities possessed by A.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 25 Feb 2010 04:34:38 +0900

> A thing, A, that is a superset of another thing, B, satisfies any requirement for B that does not specifically exclude the additional capabilities possessed by A.

If B is "DHCP Relay", there is a requirement that B needs to 
be stateless.  If A is "DHCP proxy", I don't consider A as a 
superset of B because A does not satisfy a requirement of B.

Thanks,
Yoshihiro Ohba

---

From: [email-masked]
Date: Wed, 24 Feb 2010 20:44:21 +0100 (CET)

> superset of B because A does not satisfy a requirement of B.

If you look at *actual implementations* that call themselves "DHCP
relay", and which customers think of as "DHCP relay", I believe you
will find that many of them are statefull to some degree.

An example I am familiar with: Juniper ERX "DHCP relay", e.g.

http://www.juniper.net/techpubs/en_US/junose11.0/information-products/topic-collections/broadband-access/id-52587.html#id-52587

By default this implementation creates so called "access internal
routes" on the BRAS, i.e. state, when the DHCP client receives an ACK.

Steinar Haug, Nethelp consulting, [email-masked]

---

From: Ralph Droms <[email-masked]>
Date: Wed, 24 Feb 2010 14:47:55 -0500

But can't that behavior be described as the relay agent process  
causing state in the device in which it is running as a side effect.   
The resulting state is not required for the correct operation of the  
relay agent and the DHCP messages exchanges.

- Ralph

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 24 Feb 2010 11:52:07 -0800

On Thu, Feb 18, 2010 at 10:35:20AM -0700, Ted Lemon wrote:
> It's content-free statements like this that really make this discussion
> frustrating for me.  In debate here at the Buddhist retreat center where
> I'm staying at the moment, we insist that any assertion be backed by a
> reason.  If the reason is correct and applicable, then the assertion is
> true.  If the reason can be shown to be incorrect, or not applicable,
> then the assertion hasn't been shown to be true (or false either, for
> that matter).

Have you considered advocating for an IETF Philosophy Area?  I do not
mean this sarcastically, I think the IETF can and should spend a
portion of its communal effort devoted to thinking about how it thinks,
and you obviously have an interest in sharing and expanding your
philosophy and the philosophies of others.

I think for example one output of an IETF Philosophy Area's WG, let's
say on Foundational Rules on Logical Discourse ("FuRL'D WG?"), that it
would find a need for, and a strict definition of, "the responsibility
of argument" as Aristotle may have called it if he spoke English,
including an idea I'll term the "burden of proof."  I don't know what
Buddha called these ideas, or if he even has analogues for them,
despite my years I have not found the time to study his philosophy
with any serious depth.

In this case, I would say that "responsibility of argument" which we
will call it for now lies with the document's authors and advocates,
and it is with them that lies the "burden of proof."

That is to say because of the argumentum ad ignorantiam fallacy as
Aristotle called it, or the fallacy of demanding negative proof if he
were again to speak English (which would really have been surprising,
considering).

But until there's a formalization of the systematic approach to IETF
discourse, we are both just expressing (contrary) opinions that are
completely irrelevant to informing the consensus before us.

Which is why it would be great if there were a Philosophy Area.

In the meantime, I'd prefer it if people expressed their opinions
freely, and that we all gave them whatever worth we valued them.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 25 Feb 2010 04:59:32 +0900

I am sorry, but I am so confused.  What DHCP relay 
definition we should use here in DHC WG?

Yoshihiro Ohba

---

From: [email-masked]
Date: Wed, 24 Feb 2010 21:07:20 +0100 (CET)

> relay agent and the DHCP messages exchanges.

Agreed. I guess I was simply reacting to the claim that DHCP relay
*must* be stateless, which doesn't necessarily seem to be the case
for actual implementations.

---

From: Ralph Droms <[email-masked]>
Date: Wed, 24 Feb 2010 15:08:56 -0500

My point is that the DHCP relay agent itself is stateless, although it  
may change state in the device in which it's running.

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Wed, 24 Feb 2010 13:14:35 -0700

> superset of B because A does not satisfy a requirement of B.

If B performs the function of a DHCP relay, and is stateless in its functioning as a DHCP relay, and A also performs the function of a DHCP relay, and is stateless in its functioning as a DHCP relay, then A and B both provide the same functionality with respect to DHCP relay.

In any case, even if your argument were valid, which it is not, it is just hair-splitting.   The reason DHCP relays are described as stateless is that it's cheaper and easier to implement them that way, not because there's a protocol requirement to implement them that way.

It's really frustrating to hear arguments like this, because you claim to be a participant in the DHC wg consensus, but your argument demonstrates that you are not a serious DHCP person.   I don't mean that you aren't competent in your own field, but how would you feel if the DHCwg descended en masse on your working group, on a topic where you *are* an expert, and started making arguments like this?   I'm guessing you'd feel like your time was being wasted.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 24 Feb 2010 13:24:25 -0700

> and it is with them that lies the "burden of proof."

It certainly is the document authors' responsibility to advocate for their document in the sense of explaining why it is a good idea.   However, opponents of the document who advance invalid, unsupported or otherwise spurious arguments in an effort to build an emotional sentiment against the advancement of a document are still behaving irresponsibly.

If the document is a bad idea, you should be able to demonstrate that it is a bad idea without resorting to unsupported assertions.   The whole point of repeating unsupported assertions is to get people who aren't reasoning about the question to take sides, which to me seems quite poisonous to the IETF process.

---

From: Ralph Droms <[email-masked]>
Date: Wed, 24 Feb 2010 15:26:16 -0500

Turning your statement around a little, extensions to DHCP developed  
by the dhc WG have always avoided *requiring* state in the relay  
agent, because of issues of scale and cost.

- Ralph

On Feb 24, 2010, at 3:14 PM 2/24/10, Ted Lemon wrote:

> [...]The reason DHCP relays are described as stateless is that it's  
> cheaper and easier to implement them that way, not because there's a  
> protocol requirement to implement them that way.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 24 Feb 2010 13:33:57 -0700

> agent, because of issues of scale and cost.

Exactly.

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 24 Feb 2010 13:25:30 -0800

On Wed, Feb 24, 2010 at 01:24:25PM -0700, Ted Lemon wrote:
> It certainly is the document authors' responsibility to advocate for their
> document in the sense of explaining why it is a good idea.

Maybe we will see some of that in the not too distant future then.

> However,
> opponents of the document who advance invalid, unsupported or otherwise
> spurious arguments in an effort to build an emotional sentiment against
> the advancement of a document are still behaving irresponsibly.
> 
> If the document is a bad idea, you should be able to demonstrate that it
> is a bad idea without resorting to unsupported assertions.   The whole
> point of repeating unsupported assertions is to get people who aren't
> reasoning about the question to take sides, which to me seems quite
> poisonous to the IETF process.

Again, we call this the burden of negative proof fallacy.

The consequence is that the only way to respond to unsupported
assertions ("opinions") is with contrary unsupported assertions.

It is not until the person who holds the burden of proof provides
their proof that dialectic responses can begin.

I really think you should work to start an IETF Philosophy Area if you
would like to investigate the process of discourse at an IETF in
detail.  This is completely off-topic in DHC.

Until then, I reaffirm my position that all should feel free to engage
openly in this process without undue censure (censure by reason of
disagreement with the chairs' philosophies).

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 25 Feb 2010 07:04:27 +0900

>> agent, because of issues of scale and cost.

Yes, that is what I am trying to argue.

Thanks,
Yoshihiro Ohba

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 25 Feb 2010 06:55:12 +0700

Yoshihiro Ohba [mailto://[email-masked]] writes:

...

> TR-101 requirement to do "so much more" including being a

I see.  So even though a DHCP proxy _is_ a DHCP relay, it is unacceptable
because it is not _just_ a relay?  

...

---

From: Richard Pruss <[email-masked]>
Date: Thu, 25 Feb 2010 09:55:43 +1000

On 25/02/2010, at 8:04 AM, Yoshihiro Ohba wrote:

>>> Turning your statement around a little, extensions to DHCP developed  by the dhc WG have always avoided *requiring* state in the relay  agent, because of issues of scale and cost.
>> Exactly.
> 

Yes but even a casual reader of TR-101 would notice that TR-101 requires per-session state in so many, many ways.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 24 Feb 2010 19:10:02 -0700

> assertions ("opinions") is with contrary unsupported assertions.

Your understanding of logic is either ill-expressed or ill-informed.   If an assertion is unsupported, the way to respond to it is to say that it's unsupported.   Responding to it with another unsupported assertion is not a valid way to refute it.

When you point out that an assertion is unsupported, it's your opponent's responsibility to provide a supporting reason.   If they don't, then no forward progress can be made, and indeed in the IETF context it then devolves into a popularity contest, which is what I am protesting.

Making unsupported assertions back and forth sounds like debate, because people are saying things and seem in opposition, but really it's just a shouting match dressed up as a debate, and it's insulting to those of us who bother to actually try to understand the various positions being espoused.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 24 Feb 2010 19:15:20 -0700

> Yes, that is what I am trying to argue.

It can't be, because you are arguing against the protocol.   The DHC working group has successfully avoided *requiring* state in relay agents in the past.   But we have advanced protocols in the past that presume that the relay agent will be maintaining state - the DHCP LEASEQUERY extension is an example.

So to say that some proposal can't go forward because it requires that state be maintained in the relay agent is simply erroneous, and not consistent with decisions the working group has made in the past.

---

From: Ralph Droms <[email-masked]>
Date: Wed, 24 Feb 2010 21:19:16 -0500

Ted - does DHCP LEASEQUERY require configuration state, operational  
state while LEASEQUERY is in operation or per client state?

- Ralph

On Feb 24, 2010, at 9:15 PM 2/24/10, Ted Lemon wrote:

> It can't be, because you are arguing against the protocol.   The DHC  
> working group has successfully avoided *requiring* state in relay  
> agents in the past.   But we have advanced protocols in the past  
> that presume that the relay agent will be maintaining state - the  
> DHCP LEASEQUERY extension is an example.
>
> So to say that some proposal can't go forward because it requires  
> that state be maintained in the relay agent is simply erroneous, and  
> not consistent with decisions the working group has made in the past.
>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 25 Feb 2010 11:23:19 +0900

> because it is not _just_ a relay?  

I am not still considering DHCP proxy as a DHCP relay 
because DHCP proxy requires to maintain state to provide a 
*similar* functionality to DHCP relay, while DHCP relay is 
required to be *implementable* without state.

BTW, I am not sure if people feel comfortable with me 
stating my opinion about DHCP because I am not a serious 
DHCP person.

Yoshihiro Ohba

---

From: Ted Lemon <[email-masked]>
Date: Wed, 24 Feb 2010 19:36:51 -0700

> stating my opinion about DHCP because I am not a serious 

I'd be a lot more comfortable if you'd back your opinions up with valid, applicable reasons.   You are of course entitled to your opinions, and in general I think it's common courtesy for us to consider them, but if we here at the IETF made all our decisions about protocols strictly on the basis of opinion, we probably would still be communicating primarily by telephone.

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 25 Feb 2010 08:44:44 -0800

On Wed, Feb 24, 2010 at 07:10:02PM -0700, Ted Lemon wrote:
> Your understanding of logic is either ill-expressed or ill-informed.
> If an assertion is unsupported, the way to respond to it is to say
> that it's unsupported.   Responding to it with another unsupported
> assertion is not a valid way to refute it.

They are equivalent.  Identifying an assertion as unsupported
postulates that it may be false to some varying degree of certainty,
it expresses a contrary opinion directly or hypothetically that must
be responded to.  Such postulation places no burden of negative proof
on the detractor of a position.

Your earlier position omits any of this as a possibility, requiring
negative proof, so I'm glad you have changed positions or now
vocalized a correct one.

You really need to start a relevant BoF and try for organizing the
Philosophy Area at the IETF if you want to explore this in any detail.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 25 Feb 2010 10:01:47 -0700

> on the detractor of a position.

Er, no, identifying a position as not having been supported with a valid or applicable reason says nothing at all about whether or not it is correct.   If you already accepted it as true you wouldn't ask for a supporting reason, but that's not the same thing as asserting that it's false.   In order to assert that a statement is false, you need to present a reason that contradicts it.

I realize that a logical positivist might assert that anything that hasn't been proven is presumed false, but logical positivism, while it is fairly popular in some circles in the present day, is not by any means the only system of philosophy that's taken seriously, nor indeed is it one with which I agree. So to propose that we follow its rules for discourse would be inappropriate in this forum, even if you might find the shortcuts that it offers helpful when debating with other logical positivists.

Anyway, you're the one who brought up philosophy.   I'm just trying to get some clarity on a DHCP issue, using my existing understanding of logic.   If you don't agree to the same rules of logic, there's nothing I can really do to sway you, but I don't think it's out of line for me to express why it is that I find your reasoning unhelpful.

---

From: Ralph Droms <[email-masked]>
Date: Thu, 25 Feb 2010 12:29:08 -0500

RFC 1542

- Ralph

On Feb 24, 2010, at 2:59 PM 2/24/10, Yoshihiro Ohba wrote:

> I am sorry, but I am so confused.  What DHCP relay definition we  
> should use here in DHC WG?
>
> Yoshihiro Ohba
>
>
> [email-masked] wrote:
>>> If B is "DHCP Relay", there is a requirement that B needs to be  
>>> stateless.  If A is "DHCP proxy", I don't consider A as a superset  
>>> of B because A does not satisfy a requirement of B.

---

From: Ralph Droms <[email-masked]>
Date: Thu, 25 Feb 2010 12:31:30 -0500

Using the term "DHCP proxy" is problematic because it is, as far as I  
know, not well-defined.  DHCP proxy does not appear anywhere in the  
DHCP specs (working from memory), while DHCP relay (assuming the term  
"DHCP relay" is equivalent to "BOOTP relay agent") is defined in RFC  
1542.

- Ralph

On Feb 24, 2010, at 6:55 PM 2/24/10, Glen Zorn wrote:

>>>> described in RFC 951 "BOOTP", RFC 2131"DHCP" and RFC 3046 "DHCP  
>>>> Relay
>> Agent

---

From: Ralph Droms <[email-masked]>
Date: Thu, 25 Feb 2010 12:35:02 -0500

Is that state required for the operation of DHCP or is it a side  
effect in the device in which the DHCP relay agent runs?

Another one of the terminology issues we have is "what is a DHCP relay  
agent".  I define a DHCP relay agent as that process that receives and  
forwards DHCP messages between clients and servers.  The DHCP relay  
agent runs on some device, which may have other functions related to  
packet forwarding.  As the function of the DHCP relay aqent has  
evolved, it has come to be that the DHCP relay agent causes state to  
be installed in the device in which it is running.

I think it is important to keep separate the side-effect state from  
the state required to run the protocol.  Perhaps that is overly  
pedantic of me.

- Ralph

On Feb 24, 2010, at 6:55 PM 2/24/10, Richard Pruss wrote:

>>>> Turning your statement around a little, extensions to DHCP  
>>>> developed  by the dhc WG have always avoided *requiring* state in  
>>>> the relay  agent, because of issues of scale and cost.
>>> Exactly.
>>
> Yes but even a casual reader of TR-101 would notice that TR-101  
> requires per-session state in so many, many ways.

---

From: Ralph Droms <[email-masked]>
Date: Thu, 25 Feb 2010 13:29:27 -0500

OK, I'll take the bait.  I'm a casual reader of TR-101 and I don't see  
a requirement for per-session state that affects the operation of the  
DHCP relay agent in support of the operation of DHCP.

I do see a lot of state in support of packet forwarding, which is  
installed as a side-effect of the DHCP relay agent operation.   
Strictly speaking, those side effects are not part of DHCP.

- Ralph

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 25 Feb 2010 12:00:14 -0800

On Thu, Feb 25, 2010 at 10:01:47AM -0700, Ted Lemon wrote:
> Er, no, identifying a position as not having been supported with a
> valid or applicable reason says nothing at all about whether or not
> it is correct.

It is possible that someone might, purely for academic purposes,
identify an incompleteness in an argument and request more information,
I believe this even happens often at IETF's as many are naturally
curious, however;

> If you already accepted it as true you wouldn't ask for a supporting
> reason,

Precisely.  The question asserts some degree of uncertainty in the
position, from none up to and including the belief it is outright
false.  The entire spectrum of disbelief is worthy of reflection.

There are many situations where an IETF WG participant can and should
express the belief that a statement is outright false, and where it is
either impractical or even impossible to provide proof of the negative
(it is also quite possible that statements we might hear at the IETF
either are impractical or even impossible to be proven true as well;
in my opinion this is why the IETF process relies on measuring the
consensus of practitioners).

> but that's not the same thing as asserting that it's false.

It is as near as makes no difference.

> In order to assert that a statement is false, you need to present a
> reason that contradicts it.

No.  Now you're back to requiring a burden of negative proof.  Where
did your previous assertion go that accepted skepticism?

> I realize that a logical positivist might assert that anything that
> hasn't been proven is presumed false, but logical positivism, while
> it is fairly popular in some circles in the present day, is not by
> any means the only system of philosophy that's taken seriously, nor
> indeed is it one with which I agree

I understand often, when talking about fallacies, people can get
confused between criticism of fallacy in rhetoric, and the truth or
falseness of the conclusions of the criticized arguments.  I don't
think I've taken any position on the assumption of truth, but if you'd
like me to, I'll say that truth or falseness must be proven, and
anything else is a state of indecision.  A state we regularly are
asked to provide consensus on.  To operate at the IETF, your
epistemology must have a way to cope with indecisiveness of evidence
when you must still make a decision, and in my case I might apply the
tenets of a different epistemology to each different rhetorical
situation to inform my own decision.

So if we were to form the IETF's Philosophy Area, I would line up
behind you at the microphone to criticize adopting logical positivism
in the IETF's formal epistemology.

But I'm afraid I still disagree with you on the position of demanding
negative proof, and all the rhetoric in the world won't change that.

It is simply, trivially, wrong.

> So to propose that we follow
> its rules for discourse would be inappropriate in this forum, even
> if you might find the shortcuts that it offers helpful when debating
> with other logical positivists.

I will do you one better:  It is inappropriate to set rules of
discourse in this forum.

> Anyway, you're the one who brought up philosophy.

Sorry, I'm not the one who brought Buddhism into it.  If you are
trying to say, as I have been trying to say, that philosophy is out of
scope for DHC, then I agree, and I think we should both shut up.

But that also means you cannot dictate epistemology to WG participants.
So we can strike your earlier assertions requiring negative proof?  You
seem to want this road to run one-way.

What I believe you must do instead is permit all WG participants to
express themselves freely (within the bounds of remaining cordial and
civil) to inform consensus.  Permit WG participants to accept or
filter out that input as fits or doesn't with their own individual
epistemology.  Call consensus and measure it.

Place your trust in WG participants to measure input correctly and
find consensus correctly.

I believe this is the long-form of the sentiment often expressed that
at the IETF, one should often "just press D."

Can you do that?

> I'm just trying to get some clarity on a DHCP issue, using my
> existing understanding of logic.   If you don't agree to the same
> rules of logic, there's nothing I can really do to sway you, but I
> don't think it's out of line for me to express why it is that I find
> your reasoning unhelpful.

It is absolutely out of line for a WG chair to demand a burden of
negative proof.  It is equally out of line for any WG participant
including the chair to demand any rule of any epistemology be
followed.  If you think I've been doing that (such as with your
reference to logical positivism), I haven't.

I'm really kind of bummed you don't really seem to have any interest
in forming the IETF Philosophy Area.

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 25 Feb 2010 13:58:02 -0800 (PST)

Hi Ted,
  Years ago we wrote a draft on DHCP Proxy which is at:
http://tools.ietf.org/id/draft-sarikaya-dhc-proxyagent-00.txt

in which we defined DHCP Proxy as DHCP Server with no local address depository, i.e. no state.

I am trying to see how all these discussions on DHCP Relay relates to DHCP Proxy as we described it.

Regards,

Behcet

----- Original Message ----
> To: Ralph Droms <[email-masked]>
> Cc: DHC WG <[email-masked]>
> Sent: Wed, February 24, 2010 2:33:57 PM
> Turning your statement 
> around a little, extensions to DHCP developed  
> by the dhc WG have 
> always avoided *requiring* state in the relay  
> agent, because of 
> issues of scale and 
> cost.

Exactly.

dhcwg 
> mailing list
> href="mailto:[email-masked]">[email-masked]
> href="https://www.ietf.org/mailman/listinfo/dhcwg" target=_blank

---

From: Ted Lemon <[email-masked]>
Date: Thu, 25 Feb 2010 20:58:36 -0700

> It is as near as makes no difference.

Asserting that a statement is unproven is not even remotely the same as asserting that it is false.   This is true because, as you admit, an unproven statement could be either true or false.   When we state a syllogism, the reason given to prove the statement is itself an unsupported statement, yet we do not demand a reason to support it unless we do not know it to be true.   So any debate ultimately must follow the chain of logic to a point of agreement (that is, an assertion for which neither party requires proof), or else the debate can't reach a point of agreement at all.

If an assertion hasn't been proven to the satisfaction of a participant in a discussion, and that participant doesn't agree with the assertion, then you are right that there is nothing further that can be done.   And that is why we eventually need to test the consensus, and why the IETF's work is based on running code and rough consensus, not on never standardizing on anything that hasn't been proven to be correct.

However, part of the process of gauging rough consensus is that the working group chair (or in our case, chairs) need to figure out who is participating in the consensus.   The standard for participation is generally that the participants understand the issues and have read the relevant drafts and other associated documents, and have participated in the discussion.   This prevents, for instance, Eric Voit or Alper Yegin from getting fifteen co-workers to come on the mailing list solely for the purpose of "voting" on the question.   If we operated strictly on the basis of voting, then the largest company would always win.

It is not my intention to prevent people from participating in this discussion.   Quite the opposite: I would like people to participate vigorously, but constructively.   The entire basis for my criticism was that I felt that people were fooling themselves (and possibly others) into believing that they were participating constructively, but were in fact not in full possession of the facts, and were not actually presenting valid or relevant arguments.   I wanted them to do so, not to shut up.

There is no need for an IETF working group on philosophy.   The IETF already has a clear philosophy, which I have paraphrased briefly here.  John and I can't gauge consensus if we can't determine who is participating, and who is simply showing up to add a voice to a co-worker who is the actual participant, or doing a drive-by to present an opinion that's not based on any sort of serious consideration of the matter being discussed, but simply represents a general prejudice that they hold based on their work in other working groups.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 25 Feb 2010 21:01:08 -0700

> I am trying to see how all these discussions on DHCP Relay relates to DHCP Proxy as we described it.

I think that they don't.   I happen to think that your use for the term "DHCP Proxy" makes more sense--what I would call Ric's proxy is an "EAP proxy," if it must be called a proxy.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 25 Feb 2010 21:08:39 -0700

> the state required to run the protocol.  Perhaps that is overly  

Actually, I think it's a good point.   There's a bit in the document that talks about how Ric's proposal breaks the DHCP client state machine that I think comes at the same problem from the other angle.

There are two kinds of state that we might be talking about when we call the DHCP relay "stateless."   One kind is state that's data - e.g., what the user's credentials are, and whether or not they have authenticated.   As you say, this isn't really DHCP state at all - it's EAP state, and its presence doesn't render the DHCP relay agent stateful, because it's got nothing to do with DHCP and doesn't, by itself, drive the protocol.

However, the other kind of state we might talk about is state as in "a state machine." In this sense, if the DHC relay is stateful, that's a problem, and that's why I wrote that section in the analysis document - I don't think the relay should have a state machine, because if it does, then the relay's state machine will wind up battling it out with the client's state machine, and that would be a bit of an interoperability nightmare.

So I would consider it a very different matter for there to be a DHCP protocol extension that adds new potential states to the DHCP client state machine, as compared to a DHCP protocol extension that adds a state machine to the relay agent.

As Ric's protocol is currently written, I think it adds a state machine to the DHCP relay agent, and in that sense Ohba-san's and Alper's objections regarding a stateful DHCP relay agent are valid objections.   If that is what Ohba-san meant when he was objecting to the DHCP relay being stateful, then I suspect I owe him an apology!

---

From: <[email-masked]>
Date: Fri, 26 Feb 2010 06:17:34 +0100

Ric,

Just a simple question about the use of DHCP as you explained below:

As part of this thread there has been mention of the need to authenticate
the user/host at layer 2 (before any IP address is assigned). In the
description below DHCP is essentially playing the role of a layer2 protocol
carrying EAP messages to authenticate the user/host. DHCP by no means is a
layer 2 protocol. Is it not a pretty gross violation of the layering
principles? 
3GPP, WiMAX, Wifi and CDMA/EV-DO networks all for example have layer 2
specific capability to authenticate the user exactly for the same reason why
BBF wants to authenticate the host prior to assigning an IP address. And
there is no problem with the binding of the assigned address to the
authentication performed at layer 2. Why would the BBF not consider
extending 802.1x (a layer 2 solution) to solve the problem? Has IEEE
rejected the possibility of extending 802.1x to overcome the current
limitation which is the reason why it cannot be used as is in the BBF
architecture today?

-Raj

On 2/23/10 11:24 PM, "ext Richard Pruss" <[email-masked]> wrote:

> You are correct Tom, we do assume EAP  transport over L2 to the NAS,  which
> then repackages the EAP  into RADIUS or DIAMETER  for transport to the EAP
> server.
>  The draft is really just about getting the EAP over that L2 hop using DHCP (
> which is a layer two  protocol).  The  advantage of using DHCP  over some new
> layer two  transport is that the DSLAMs/first hop switches  will mark the
> customer line information into DHCP, this lets us couple who you claim to be
> with where you are to make a well-informed authentication.
> 
> In addition to that once the DHCP exchange is completed the switches use the
> completion of DHCP as explicit provisioning allowing customer traffic not just
> to the upstream NAS  that to other services upstream on layer 2, like voice
> gateways or video pumps.
> 
> -- Ric

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 26 Feb 2010 14:34:41 +0900

Yes, that is what I meant in my objection.  Perhaps my 
wording was not clear enough about the differentiation 
between DHCP protocol state and other state.

Thanks,
Yoshihiro Ohba

---

From: Ted Lemon <[email-masked]>
Date: Thu, 25 Feb 2010 22:37:51 -0700

On Feb 25, 2010, at 10:17 PM, <[email-masked]> <[email-masked]>wrote:
> Why would the BBF not consider

You are not the first person to ask this question, and Ric has in fact already answered it.   It might help to review the discussion before chiming in--I think the issue you're talking about is important, but we can't really make any progress on it if everyone keeps asking the same questions that have already been answered.

BTW, based on the discussion over the past week, I think I will actually do another update to the analysis document, because one point of the document is to capture the discussion so that we don't keep repeating history.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 25 Feb 2010 22:50:26 -0700

> between DHCP protocol state and other state.

Then I am sorry for having misunderstood what you were saying and for correcting you when it wasn't warranted.

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 26 Feb 2010 05:36:09 -0500 (EST)

Ted,

> You are not the first person to ask this question, and Ric has in fact already
> answered it.  
Ric answered a different question (whether 1X can be used "as-is").
Raj is asking possibility of "extending" 1X.

 It might help to review the discussion before chiming in--I think the issue
you're talking about is important, but we can't really make any progress on it
if everyone keeps asking the same questions that have already been answered.>
> BTW, based on the discussion over the past week, I think I will actually do
> another update to the analysis document, because one point of the document is
> to capture the discussion so that we don't keep repeating history.
>
 
As long as it is about DHCP and EAPoDHCP, sure... If it is about IEEE 802.1X
(its applicability/inapplicability/extensibility), then I don't expect any
authoritative discussion being held in IETF DHC WG........... not in Int-Area,
and not even in IETF.

Alper

> _______________________________________________> dhcwg mailing list
> [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Fri, 26 Feb 2010 09:20:08 -0700

On Feb 26, 2010, at 3:36 AM, [email-masked] wrote:
> As long as it is about DHCP and EAPoDHCP, sure... If it is about IEEE 802.1X (its applicability/inapplicability/extensibility), then I don't expect any authoritative discussion being held in IETF DHC WG........... not in Int-Area, and not even in IETF.

The part of the discussion where we decide what to do next does belong in int-area.   If BBF decides, independently, to drop the DHCP requirement and switch to 802.1x, then you're right, we don't need to discuss it further in either group.   But that's not the situation at present.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 26 Feb 2010 09:22:24 -0700

> Raj is asking possibility of "extending" 1X.

Actually, Ric and Eric both answered this question.   They said they don't want to have to add code to the DSLAM.   802.1x would (so they said) require adding code to the DSLAM, even if it were extended somehow, in order for the DSLAMs to pass it.   At least, that's my understanding of what they said - hopefully they will correct me if I'm wrong.

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 26 Feb 2010 10:43:47 -0600

> From: Ted Lemon, February 26, 2010 11:22 AM
> Actually, Ric and Eric both answered this question.   They said they
> don't want to have to add code to the DSLAM.   802.1x would (so they
> said) require adding code to the DSLAM, even if it were extended
> somehow, in order for the DSLAMs to pass it.   At least, that's my
> understanding of what they said - hopefully they will correct me if
I'm
> wrong.

802.1x is an excellent protocol, and is used in some Broadband (Fiber)
implementations.  One big issue preventing 802.1x universal deployment
is that it was initially designed to protect directly connected physical
interfaces (i.e., not logical interfaces, and not across multiple
Ethernet hops).  Therefore aggregating 802.1x across a DSLAM into VLAN
towards a BRAS is non-standard behavior.  In addition, 802.1x uses
Ethertype x888E which would be unexpected by embedded DSLAMs.

Eric

---

From: <[email-masked]>
Date: Fri, 26 Feb 2010 17:55:35 +0100

> Ethertype x888E which would be unexpected by embedded DSLAMs.

At the time the LS was sent by BBF to the IETF, I believe there was a
similar LS also sent to IEEE to consider if 802.1x could be extended to
address the above issues that limit its usage in the DSL world. Has there
been any conclusion or response from IEEE on the topic?

I do realize that 802.1x in its current form would not meet the BBF
requirements. But I am also under the impression that extending 802.1x was a
feasible option for the BBF scenario.

I recognize that 802.1x is not in the scope of the IETF. The only reason to
discuss that here is for the simple reason that authentication of the
host/user needs to be done at L2. And I think .1x would be a better option.

-Raj

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 26 Feb 2010 11:42:01 -0800

On Thu, Feb 25, 2010 at 08:58:36PM -0700, Ted Lemon wrote:
> Asserting that a statement is unproven is not even remotely the same
> as asserting that it is false.

As I have said, they are similar in that both express doubt in the
truth of the statement.  In context remember that we are talking about
questioning a statement of the affirmative and your requirement for
proof of the negative, and not your shorthand: "any statement."

So I believe as I have already said, it is as near as makes no
difference.  No matter where the person voicing the negative stands on
the scale of disbelief, the person holding the affirmative has the
burden of proof.  The voice in the negative is informative to
consensus, and the position along the scale I describe is relevant.

A proof of the negative, where it is tractable and possible, is very
helpful in ending a debate, but it is not always tractable nor
possible (and not simply because the statement is true) and so
demanding it is irresponsible.

> It is not my intention to prevent people from participating in this
> discussion.   Quite the opposite: I would like people to participate
> vigorously, but constructively.   The entire basis for my criticism was
> that I felt that people were fooling themselves (and possibly others)
> into believing that they were participating constructively, but were in
> fact not in full possession of the facts, and were not actually
> presenting valid or relevant arguments.   I wanted them to do so, not
> to shut up.

I lament that the implicit answer to my question, "Can you do that?"
is apparently in the negative.  Your position shows to me that you can
place no trust in the community to not "be fooled" as you put it, but
instead take it on yourself to educate the community on how to
interpret input to consensus.

What was worrisome to me is that you did not, in my interpretation,
"ask people to participate more constructively" as you are
representing it now, but rather stated a specific rule by which they
must pass in order to participate: that they must provide negative
proof, or provide no input at all.

But as you say that was not your intention to express, so we now
understand it not to be a requirement for participation in your
opinion.  And we can both agree on that?

You are otherwise of course at your own discretion when you choose to
interact on the level of encouraging participation you find
constructive (but maybe you can be more careful to word it as a
request in future), or any other participation you choose to engage
in for that matter.

It still concerns me however because that level of interaction is not
as helpful as you seem to think it is.  It extends a discussion well
beyond its natural lifetime and consumes precious airtime we can
devote to more pressing matters (or better still, spend in quiet
reflection).  I think we've seen you do that here, in this consensus
call thread.  It is not our responsibility to extract a convincing
argument from any party; they should do that on their own
recognizance.  It is not your responsibility to engage someone until
they do so.

The ability to perpetuate discussions is not a quality I look for in a
WG chair, and it is not a function that I ask a chair to perform.  I
would like to ask you to reflect upon this issue over a period of some
time and hopefully come to a different position on the extent to which
you can "just press D."

> There is no need for an IETF working group on philosophy.

It's a pity you think so, because you clearly have the interest and
patience to share your philosophy (not just as you did recently, but
that you have a long track record for it) and test it in the crucible
of peer review.  You also write eloquently on the subject.  Despite my
opinion that your philosophy is fundamentally flawed in its position
of fallacy in the burden of proof, such a WG would benefit from your
participation and might serve to inform an IETF community you would
find more trustworthy.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 26 Feb 2010 12:57:17 -0700

On Feb 26, 2010, at 12:42 PM, David W. Hankins wrote:
> No matter where the person voicing the negative stands on
> burden of proof.

How does this contradict what I said?

> [you] rather stated a specific rule by which they

Where did I say that?   My original statement was simply that I was disgusted with the level of the discourse, because so many unsupported assertions were being made as if they were commonly understood to be true.

> Your position shows to me that you can

The community doesn't make the determination of consensus.   The working group chairs do.   If members of the community feel that the working group chairs made a mistake, there's an appeals process, although any sane working group chair will bend over backwards to avoid making a consensus call that would result in an appeal, because of the hassle involved.

Maybe you should read the Tao of IETF, speaking of IETF philosophy...

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 26 Feb 2010 12:55:49 -0800

> How does this contradict what I said?

If you feel that it does not, then we can finally agree.

> Where did I say that?   My original statement was simply that I was
> disgusted with the level of the discourse, because so many
> unsupported assertions were being made as if they were commonly
> understood to be true.

  http://www.ietf.org/mail-archive/web/dhcwg/current/msg10621.html

In interpreting this, I think it is possibly the tone and strong
language, in particular to "insist", that led me to that
interpretation of your meaning which we now together describe as a
mis-interpretation.

> The community doesn't make the determination of consensus.   The
> working group chairs do.

I was expressing that the community provides their support of
consensus, for example their support of accepting a draft as a WG
item, and that they must inform their decisions to do so individually.

It is absolutely our agreement that it is the chairs alone who measure
support and call consensus.

> Maybe you should read the Tao of IETF, speaking of IETF philosophy...

I already have.

---

From: Richard Pruss <[email-masked]>
Date: Sat, 27 Feb 2010 10:44:18 +1000

I did not say there was a "requirement for per-session state that affects the operation of the DHCP relay agent in support of the operation of DHCP."
I said "TR-101 requires per-session state in so many, many ways." which really should be obvious.

But in the interest of advancing your understand of the implementation, I will try answer what you asked:
a) I have mentioned on this thread before that if you do what we commonly call IP unnumbered interfaces require DHCP to store a routing table of MAC address to interface mappings so that packets returning from the server can be routed onto the correct interface, R-100 takes pains to specify how that return message should happen and also note that duplicate Mac addresses is explicitly allowed R-89 (Something that is far more common than one would think).
b) The access node must snoop all DHCP traffic.  For many reasons
1. To stop users DDOSing the server (R-105), (this requires tracking per session state on the number of DHCP transactions over time)
2. To maintain the ARP, flooding and spoofing protection when clients renew IP addresses  (R-106, R107) (Which as I have often pointed out is driven by the DHCP transaction.)

Hope that helps,
Ric

On 26/02/2010, at 4:29 AM, Ralph Droms wrote:
> 
> 
> OK, I'll take the bait.  I'm a casual reader of TR-101 and I don't see a requirement for per-session state that affects the operation of the DHCP relay agent in support of the operation of DHCP.
> 
> I do see a lot of state in support of packet forwarding, which is installed as a side-effect of the DHCP relay agent operation.  Strictly speaking, those side effects are not part of DHCP.
> 
> - Ralph
> 
>> Yes but even a casual reader of TR-101 would notice that  
>

---

From: Richard Pruss <[email-masked]>
Date: Sat, 27 Feb 2010 11:08:00 +1000

Well actually in a few years of more delay and debate maybe we are all using some new layer 2
and it will all be built in.

DHCP-Auth was done  30 months ago supposed to be a quick, easy to implement, small extension to existing
practice, if we wait a few more years the IEEE will probably make this a moot point with developments
of the future.

Ric

---

From: Richard Pruss <[email-masked]>
Date: Sat, 27 Feb 2010 11:19:58 +1000

> As Ric's protocol is currently written, I think it adds a state machine to the DHCP relay agent, and in that sense Ohba-san's and Alper's objections regarding a stateful DHCP relay agent are valid…

The proxy looks like a server to the client and a client to the server.  Which kinds of puts the duelling state machines in one ring.  ;-)

And before I get 100 "OMG it is not going to work emails!" like that please consider that at least 4 major vendors implement proxies like this with millions of working clients and
servers and so far none of the state-machines have melted a hole in the space-time continuum or broken their finite flow graphs in a way to may Markov wince.

And again I will nod to Ralph noting to me three IETF's ago  that someone should document this, and I agree that someone should, I am just as sure given my
experience in the IETF that the someone will not be me,
Ric

---

From: Richard Pruss <[email-masked]>
Date: Sat, 27 Feb 2010 11:22:03 +1000

But this is proxy to AAA, not proxy to DHCP, so
it does seems to be a different thing.

---

From: Richard Pruss <[email-masked]>
Date: Sat, 27 Feb 2010 11:25:32 +1000

I am at a loss to what your point is.  Are you saying that we should deny the implementations in this market because
the standardisation is clearly lagging implementation on one area?

DHCP Proxy is not just running code, this is common, very well deployed running code.

- Ric

On 26/02/2010, at 3:31 AM, Ralph Droms wrote:

> Using the term "DHCP proxy" is problematic because it is, as far as I know, not well-defined.  DHCP proxy does not appear anywhere in the DHCP specs (working from memory), while DHCP relay (assuming the term "DHCP relay" is equivalent to "BOOTP relay agent") is defined in RFC 1542.
> 
> - Ralph
>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 26 Feb 2010 18:43:21 -0700

On Feb 26, 2010, at 6:19 PM, Richard Pruss wrote:
> And before I get 100 "OMG it is not going to work emails!" like that please consider that at least 4 major vendors implement proxies like this with millions of working clients and servers and so far none of the state-machines have melted a hole in the space-time continuum or broken their finite flow graphs in a way to may Markov wince.

There is no state machine in a DHCP server.   The only state machine in the DHCP protocol is the DHCP client state machine.   So whether there is an EAP state machine in the DHCP server or in the DHCP relay, it's still a major change to the protocol, and it's not the same thing as the existing practice that you are talking about, which does not require a state machine in the relay or the server.

---

From: Ralph Droms <[email-masked]>
Date: Fri, 26 Feb 2010 21:49:30 -0500

On Feb 26, 2010, at 7:44 PM 2/26/10, Richard Pruss wrote:

> I did not say there was a "requirement for per-session state that  
> affects the operation of the DHCP relay agent in support of the  
> operation of DHCP."

What is relevant to a discussion of DHCP is per-session state for  
DHCP, so that's what I commented first.

Then I agreed with you that there is "a lot of state in support of  
packet forwarding".

- Ralph

> But in the interest of advancing your understand of the  
> implementation, I will try answer what you asked:
> a) I have mentioned on this thread before that if you do what we  
> commonly call IP unnumbered interfaces require DHCP to store a  
> routing table of MAC address to interface mappings so that packets  
> returning from the server can be routed onto the correct interface,  
> R-100 takes pains to specify how that return message should happen  
> and also note that duplicate Mac addresses is explicitly allowed  
> R-89 (Something that is far more common than one would think).
> 1. To stop users DDOSing the server (R-105), (this requires tracking  
> per session state on the number of DHCP transactions over time)
> 2. To maintain the ARP, flooding and spoofing protection when  
> clients renew IP addresses  (R-106, R107) (Which as I have often  
> pointed out is driven by the DHCP transaction.)
>
>
> Hope that helps,
> Ric
>
>> OK, I'll take the bait.  I'm a casual reader of TR-101 and I don't  
>> see a requirement for per-session state that affects the operation  
>> of the DHCP relay agent in support of the operation of DHCP.
>>
>>>>>> developed  by the dhc WG have always avoided *requiring* state  
>>>>>> in the relay  agent, because of issues of scale and cost.
>>>>> Exactly.
>>>>

---

From: "Alper Yegin" <[email-masked]>
Date: Sat, 27 Feb 2010 17:59:25 +0200

Carrying out informative discussions is fine.
Documenting some outcomes about IEEE 802.1X is not fine (because the right
expertise is not here).

> From: Ted Lemon [mailto:[email-masked]]
> Sent: Friday, February 26, 2010 6:20 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: IEEE 802.1X and BBF auth (was Re: [dhcwg] Adopt draft-
> pruss-dhcp-auth-dsl as a working group item?)
> 
> > As long as it is about DHCP and EAPoDHCP, sure... If it is about IEEE
> 802.1X (its applicability/inapplicability/extensibility), then I don't
> expect any authoritative discussion being held in IETF DHC
> WG........... not in Int-Area, and not even in IETF.
> 
> The part of the discussion where we decide what to do next does belong
> in int-area.   If BBF decides, independently, to drop the DHCP
> requirement and switch to 802.1x, then you're right, we don't need to
> discuss it further in either group.   But that's not the situation at
> present.

---

From: "Alper Yegin" <[email-masked]>
Date: Sat, 27 Feb 2010 18:28:33 +0200

> >>> EAPoDHCP does not fit that because TR-101 requires BRAS be
> operating
> >> as
> >> I believe I have explained the difference between DHCP relay and
> DHCP
> >> proxy to death and
> >> the BRAS in TR-101 is obviously stateful for the session, and
> obviously
> >> a proxy and obviously
> build a chain of trust.  

I don't understand what your point is (or its relevancy).

> More than that I am sure anyone would give
> that a DHCP proxy does all that a relay
> does and so much more.

So, you want to sweep DHCP relay under the DHCP proxy carpet, and make that
go undefined, and problem solved. Nice.....

TR-101 makes explicit reference to "DHCP relay".
If you want to do your suggested magic, you have to:
1. Convince BBF that TR-101 requirements allow substituting DHC relay
requirements with DHCP proxy requirements. R-181 is clear.
2. Define DHCP proxy. 
3. Let the DHCP proxyfied EAPoDHCP analyzed.

---

From: "Alper Yegin" <[email-masked]>
Date: Sat, 27 Feb 2010 18:37:03 +0200

Ric

I don't remember seeing your response to the following.... did I miss it?

---

From: Ted Lemon <[email-masked]>
Date: Sat, 27 Feb 2010 10:11:49 -0700

> TR-101 makes explicit reference to "DHCP relay".

I take it from this line of argument that you feel that something that is a superset of a DHCP relay is disqualified from acting as a DHCP relay.   Could you explain why this is so?

---

From: "Alper Yegin" <[email-masked]>
Date: Sun, 28 Feb 2010 01:12:36 +0200

> I take it from this line of argument that you feel that something that
> is a superset of a DHCP relay is disqualified from acting as a DHCP
> relay.   Could you explain why this is so?

Can you please explain to us what DHCP proxy is in detail, and how it is
considered a superset of DHCP relay? All of a sudden we take that as a
given, and now we have to explain things in terms of something we don't even
understand (in DHC WG, not in some vendor's product team).

For people's background...... There are many variants of the concept "DHCP
proxy". We use one in WiMAX NWG. It's not anything like Ric suggests. In
WiMAX, DHCP proxy and DHCP relay are two distinct things, one is not a
superset of the other.

Anyways, let's hear the details, and then I can tell you if it is really a
superset of DHCP relay (as far as BBF is concerned, as far as EAP and AAA
are concerned).

To make people's life easier, a pointer to BBF specs that explain DHCP proxy
also counts. 

Alper

---

From: Ted Lemon <[email-masked]>
Date: Sat, 27 Feb 2010 17:25:25 -0700

On Feb 27, 2010, at 4:12 PM, Alper Yegin wrote:
> considered a superset of DHCP relay?

You just answered a direct, easily answered question with another question.  Let me ask you the question again, and try to phrase it more clearly, in hopes of eliciting an answer this time.

Suppose there is a device on the network which performs all the functions of a DHCP relay agent.   Suppose this device also performs other functions.   Does the fact that it performs other functions mean that it does not satisfy a requirement for a DHCP relay agent?   If so, why?

Now, in answer to your question, the protocol specification says what the "DHCP proxy" does.   If you feel that the specification is unclear, it would be helpful to know what you feel is missing, or what about it doesn't make sense to you.

It might be helpful to refer to the analysis document, which talks about some known problems with the "DHCP proxy" as it is currently specified, so that we don't find ourself revisiting ground that has already been covered.   Quite a bit of verbiage in the document was put there to address previous questions you've asked about the proxy.  

Like you, I am eager to hear Ric's answers to the concerns raised in the analysis document.

---

From: Richard Pruss <[email-masked]>
Date: Sun, 28 Feb 2010 18:32:23 +1000

Requires DHCP revoke, which requires keys for DHCP message authentication, which we want to share over EAP.

You moaned about draft on that done by Joe and I on and said that you were going to
revive your own one.

We are watching with interest,
Ric