Subject: [Int-area] Combined draft on DHCP authentication

From: Richard Pruss <[email-masked]>
Date: Mon, 19 Nov 2007 13:32:29 +1000

A combination the DHCP drafts from Cisco and Hauwei on DHCP 
Authentication has been submitted and is available at:
http://www.ietf.org/internet-drafts/draft-pruss-dhcp-auth-dsl-02.txt

Regards,
Ric

_______________________________________________
Int-area mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 19 Nov 2007 10:10:12 +0100

> http://www.ietf.org/internet-drafts/draft-pruss-dhcp-auth-dsl-02.txt

Doesn't seem to address IPv6. This makes it useless in my book.

---

From: Richard Pruss <[email-masked]>
Date: Mon, 19 Nov 2007 23:16:10 +1000

> Doesn't seem to address IPv6. This makes it useless in my book.
Ahh, you have written a book on authentication in DSL architectures... ;-)

If you point me to the IPv6 deployment architecture from the DSLForum I 
can send you a draft on how to do the authentication in it.  Putting EAP 
into DHCP v6 is no big trick, the real trick is what does the rest of 
the IPv6 architecture look like.

There are a ton of questions like:

a) Do we have multiple services with separate addresses or are they on 
the same address as IPv4.  Both approaches have pro's and cons.

b) How far into the L2 architecture are link local addresses allowed.

c) SAVA

and on and on.

It is simply premature to guess at what authentication is appropriate 
and while PANA seems to think they have a hammer for everything.  I do 
not think DHCP Authentication may be the write answer to every question.

So leave off the IPv6, we just cannot answer the question with the 
architectures under discussion at the DSLForum.

- Ric

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 19 Nov 2007 14:38:04 +0100

> Ahh, you have written a book on authentication in DSL  

No. I'm guessing that would be a short book. Especially the IPv6 part,  
as doing IPv6 over PPP isn't workable in practice.

> If you point me to the IPv6 deployment architecture from the  
> DSLForum I can send you a draft on how to do the authentication in  
> it.  Putting EAP into DHCP v6 is no big trick, the real trick is  
> what does the rest of the IPv6 architecture look like.

Most hosts running IPv6 today don't run DHCPv6. If I'm not going to  
run DHCPv6 to learn IPv6 nameserver addresses, I'm also not going to  
do it just because my DSL provider wants me to.

> There are a ton of questions like:

[...]

> It is simply premature to guess at what authentication is appropriate

Does it make sense to go forward with something that requires an  
update for ALL (new?) customers only to redo much of the same for  
IPv6, probably less than two years later?

Figuring out how we want to do IPv6 over DSL (and cable) and then  
making all the changes in one go seems like a much more sensical  
approach to me.

---

From: Mark Townsley <[email-masked]>
Date: Mon, 19 Nov 2007 14:41:40 +0100

Ric, any final IETF work that involves IPv4 does has to at the very 
least have detailed IPv6 considerations in order to be complete. I 
understand that the DSLF IPv6 architecture for IP sessions is very 
incomplete, and I am going to personally try and rectify that as much as 
I can via my own participation in the Forum. This doesn't mean you are 
off the hook for DHCP Auth, and I highly suggest the next version of 
your document speak to this in as clear and frank a manner as possible.

Iljitsch, your comment wasn't exactly written with a constructive tone 
either. Let's all please try not to push each others buttons and throw 
flames here.

- Mark

Richard Pruss wrote:
> If you point me to the IPv6 deployment architecture from the DSLForum 
> I can send you a draft on how to do the authentication in it.  Putting 
> EAP into DHCP v6 is no big trick, the real trick is what does the rest 
> of the IPv6 architecture look like.
>

---

From: <[email-masked]>
Date: Mon, 19 Nov 2007 05:49:25 -0800

> Doesn't seem to address IPv6. This makes it useless in my book.
 
I'm not clear how the specified mechanism would work with address
autoconfiguration.  Would EAP be encapsulated within an RS/RA exchange?

---

From: <[email-masked]>
Date: Mon, 19 Nov 2007 05:53:52 -0800

> as doing IPv6 over PPP isn't workable in practice.

Out of curiosity -- why not? 

> do it just because my DSL provider wants me to.

I had the impression that this was primarily for use on the CPE.   If
we're talking about adding this to Host Requirements, then there are 
a series of very daunting problems that will arise, such as compatibility
with the installed base.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 19 Nov 2007 15:01:20 +0100

On 19 nov 2007, at 14:49, <[email-masked]> <[email-masked] 
 > wrote:

> autoconfiguration.  Would EAP be encapsulated within an RS/RA  

Sounds like something that would be quite painful to deploy, right?

My take on this is that the idea of coupling authentication with  
address configuration isn't the best possible one. Ideally, all of  
this would happen at a layer below IP.

On 19 nov 2007, at 14:53, <[email-masked]> wrote:

>> No. I'm guessing that would be a short book. Especially the IPv6  
>> part,  as doing IPv6 over PPP isn't workable in practice.

> Out of curiosity -- why not?

There is no IPv6 address assignment through PPP specified and  
implementers have different takes on the use of RAs on PPP links so  
this doesn't work either. Haven't tried with DHCPv6 but I expect  
issues with that, too, because PPP is point-to-point rather than  
multipoint so I don't see how the addresses on both sides of the PPP  
link would stay in sync.

>> Most hosts running IPv6 today don't run DHCPv6. If I'm not going  
>> to  run DHCPv6 to learn IPv6 nameserver addresses, I'm also not  
>> going to  do it just because my DSL provider wants me to.

> I had the impression that this was primarily for use on the CPE.

It looked to me like the requirements left the possibility of  
connecting a host directly open although this is obviously not the  
primary focus.

---

From: Mark Townsley <[email-masked]>
Date: Mon, 19 Nov 2007 15:02:57 +0100

> as doing IPv6 over PPP isn't workable in practice.
Why not? AFAIK, the earlier cited SP that has provided IPv6 since 2001 
(NTT) delivers it over PPP, so I'm really puzzled now.
>> I can send you a draft on how to do the authentication in it.  
>> Putting EAP into DHCP v6 is no big trick, the real trick is what does 
>> the rest of the IPv6 architecture look like.
>
But your provider-spec'd CPE might run DHCPv6 PD, and then of course 
your host doesn't have to.

In any case, these are exactly the things that the DSLF, and more 
importantly the DSL industry, needs to nail down. It has barely broached 
the topic thus far for IP sessions.
> making all the changes in one go seems like a much more sensical 
However sensical, I don't think gating incremental developments in IPv4 
service on IPv6 is a very realistic option in practice - not to mention 
hoping that the DSL and Cable industries will work harmoniously with one 
another ;-)

- Mark

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 19 Nov 2007 15:13:26 +0100

On 19 nov 2007, at 15:02, Mark Townsley wrote:

>> doing IPv6 over PPP isn't workable in practice.

> Why not? AFAIK, the earlier cited SP that has provided IPv6 since  
> 2001 (NTT) delivers it over PPP, so I'm really puzzled now.

See my message from a few minutes ago.

I'd be very interested in learning how they do this. If I were to  
create something like this I'd probably tunnel over IPv4 at some  
juncture.

> your host doesn't have to.

Right. It would be great if the players in this area could agree to  
use DHCPv6 prefix delegation for customer address provisioning.

However, that doesn't entirely solve the problem: individual hosts  
could connect to the service, and also, the CPE needs an address on  
the link to the ISP. This could probably be a link local address but  
for the purposes of this discussion I don't think that makes things  
easier.

> However sensical, I don't think gating incremental developments in  
> IPv4 service on IPv6 is a very realistic option in practice

Well, I don't think adding authentication to DHCP is so incrimental...

---

From: Mark Townsley <[email-masked]>
Date: Mon, 19 Nov 2007 15:26:28 +0100

> create something like this I'd probably tunnel over IPv4 at some 
Oh, I believe there is definitely some of that, but the PPP is in the 
tunnel as well ;-)

I'd suggest you trying to catch Shin Miyakawa in Vancouver if you want 
any gory details.
> use DHCPv6 prefix delegation for customer address provisioning.
FWIW, I agree.
> Well, I don't think adding authentication to DHCP is so incrimental...
This is a very subjective assessment, but the argument can certainly be 
made that it is incremental if you look at the system architecture 
level, where DHCP is already directly tied to AAA.

- Mark

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 19 Nov 2007 10:20:49 -0500

In addition, I highly suggest that the next revision of
draft-pruss-dhcp-auth-dsl to contain an appendix to explain why the
proposal needs to be standardized while IETF has completed its basic
design of a protocol to carry EAP over IPv4 and IPv6 in order to fill
the gap where link-layer EAP transport is not applicable.  This would
require a thorough and fair analysis on PANA in which a lot of
considerations have been taken into account.

Yoshihiro Ohba

---

From: Shin Miyakawa <[email-masked]>
Date: Tue, 20 Nov 2007 00:23:18 +0900 (JST)

From: Mark Townsley <[email-masked]>
Subject: Re: [Int-area] Combined draft on DHCP authentication
Date: Mon, 19 Nov 2007 15:26:28 +0100

> I'd suggest you trying to catch Shin Miyakawa in Vancouver if you want 

Welcome, anytime :-)

We NTT Communications which runs AS2914 worldwide backbone carrying 
IPv4/v6 dual stack also are deploying IPv6 native service over 
ADSL for Japanese nationwide :-)

The service specification is described in RFC4241 .

Also, I'd like to discuss with all of you about some IPv6 access scheme
issues in Vancouver as well...

Best regards,

Shin Miyakawa, Ph.D
NTT Communications Corporation

---

From: Richard Pruss <[email-masked]>
Date: Tue, 20 Nov 2007 08:07:26 +1000

> autoconfiguration.  Would EAP be encapsulated within an RS/RA exchange?
No, even if the IP address is not delivered over DHCP the rest of the 
CPE configuration will be. When DHCP v6 is done to configure the CPE and 
EAP can be done.  I think in all probability the concept of addressing 
CPE's with address autoconfiguration will not be part of the 
architecture as it is hard to picture how one is going to protect 
resources and hosts in the layer 2 infrastructure, revoke service etc, 
when hosts can choose any IP address themselves without per CPE 
constraints but either way one can still run DHCP v6.

- Ric

---

From: Shin Miyakawa <[email-masked]>
Date: Tue, 20 Nov 2007 00:02:53 +0900 (JST)

Welcome, anytime :-)

Best regards,

Shin Miyakawa, Ph.D

---

From: Shin Miyakawa <[email-masked]>
Date: Tue, 20 Nov 2007 00:02:53 +0900 (JST)

Welcome, anytime :-)

Best regards,

Shin Miyakawa, Ph.D

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 21 Nov 2007 09:29:38 +0200

> EAP can be done.  I think in all probability the concept of addressing

So, you'll let link-local and global address configuration before access
authentication. What you have been arguing against with PANA is what you are
suggesting here.

> constraints but either way one can still run DHCP v6.

And how about on the PCs? Did you notice that Windows XP does not support
DHCPv6?

Alper

---

From: Richard Pruss <[email-masked]>
Date: Thu, 22 Nov 2007 05:56:26 +1000

Alper Yegin wrote, around 21/11/07 5:29 PM:
> And how about on the PCs? 

Have you read the requirements?  Instead of endless mailing us about you 
hammer and how pretty it is, please read the requirements.

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 21 Nov 2007 22:43:07 +0200

> Have you read the requirements?  

Yeah I did. Have you?

IPAuth-8	Must handle L3 CPE device authentication and end-device (PC)
user based authentication (likely with L2 CPEs in the latter case)

IPAuth-9	Should be simple to implement on client (PC or CPE)

> Instead of endless mailing us about you

---

From: Richard Pruss <[email-masked]>
Date: Thu, 22 Nov 2007 13:38:23 +1000

> IPAuth-9	Should be simple to implement on client (PC or CPE)

Ahh okay.  I understand how you have got confused. It is a little 
subtle.  The key thing is:
IPAuth-6	Must fit into TR-101 operational model
And then we always send TR-101 along.

TR-101 has two models

- one is the bridged and the only identity is done by port marking DHCP 
in Access Node.

- the other is routed with PPPoE running from the RG,  PPPoE tag 
insertion on the access node marks the site, and obviously PPP does the 
identity.

If you really want to dig you will find the requirements in device 
originated PPPoE in TR-68 which is the document on RG's.

So in short TR-101 does not have username and password across what is 
called the T-interface in the DSLForum i.e. the customers lan, so we do 
not need to consider a migration path for them.

The main change in WT-148 is to move to an environment where one has 
multiple services points on the ethernet as opposed to TR-101 which all 
services came through a single BRAS.

Regards,
Ric

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 21 Nov 2007 23:59:16 -0500

Section 2 of TR-101 says:

"The principle guiding this specification work is that the resulting
functions should enable an as smooth as possible migration process
from an ATM based aggregation network to an Ethernet based aggregation
network."

Terminal originated PPPoE is mentioned also in TR-101 (e.g., Figure 15).

>From customer's point of view, it would be natural to think that a
*smooth* migration path includes support for existing PPPoE terminals
to be able to migrate to Ethernet based aggregation network without
necessarily upgrading their legacy CPEs to RGs.

In this thread, when the discussion comes to end-host support, I
always see inconsistency between what is stated in the DSLF
requirements (and TR-101) and what is stated by proponents of DHCP
authentication.  If IPAuth-8 and IPAuth-9 are not really requirements,
why not re-send revised requirements officially from DSLF to IETF?
Unless requirements are revised, I don't think we can make a progress.

Yoshihiro Ohba

---

From: Richard Pruss <[email-masked]>
Date: Thu, 22 Nov 2007 18:53:16 +1000

> Unless requirements are revised, I don't think we can make a progress.

I am sorry I do not see the inconstancy, the requirements make perfect
sense if you understand that the TR's have multiple deployment models in
them.

TR-101 is about moving from an ATM uplink for DSLAMs (access nodes) and
TR-101 mandated no changes to the CPE or RG's.  WT-148 which we are
working on now is not TR-101 and while all involved want the minimum
changes it is well understood that we cannot remove PPPoA and PPPoE from
the system without changing the CPE.

The system must provide a model for supporting PC's with no change to
the software of the PC is provided in TR-101 and it does not involve a
credential exchange.  This system must continue to work in the new
proposal and the DHCP Authentication draft has a section on handling
clients that do not support the authentication mechanism.

Regards,
Ric

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 22 Nov 2007 11:16:20 +0200

There is no point in getting lost in the TR-101 text.
You said to look at the requirements, so we did it.
It reads in plain English:

	Should be simple to implement on client (PC or CPE)

Unless PC is not "PC", there is no point in arguing....

> -----Original Message-----
> From: Richard Pruss [mailto:[email-masked]]
> Sent: Thursday, November 22, 2007 10:53 AM
> To: Yoshihiro Ohba
> Cc: Alper Yegin; [email-masked]

---

From: Richard Pruss <[email-masked]>
Date: Fri, 23 Nov 2007 06:40:38 +1000

Alper possibly this has been the problem with this thread.  You simply 
do not understand that half the complexity in the DSL deployment is the 
Layer 2 parts of TR-101.

- Ric

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 22 Nov 2007 20:30:09 -0500

Sorry, I still feel the inconsistency.  Please answer to the following
question by either "YES" or "NO":

  Are IPAuth-8 and IPAuth-9 requirements for subscriber authentication
  in DSL networks?

Maybe I am so stupid that additional explanation won't help much.

Yoshihiro Ohba

Is it appropriate to complain about people who read the requirements
and questions about the requirements 
instead of complaining about the requirements.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 29 Nov 2007 16:43:20 +0200

Ric,

> architectures under discussion at the DSLForum.

I think the question about IPv6 is an important one, primarily because
we know that there's a difference going from IPv4 to IPv6 on how
universal DHCP needs to be. I am not saying that we cannot have
something based on DHCP, however. If our crystal ball said that the
mechanisms that you are proposing are only going to be implemented in a
provider-supplied CPE box, I would see no problem running DHCPv6 (and
prefix delegation) between that and the BRAS. If the scope is larger
than CPEs, however, we have significant deployment and compatibility
issues as Bernard has pointed out.

Jari