Subject: [Int-area] DCHP-based authentication for DSL?

From: Jari Arkko <[email-masked]>
Date: Thu, 04 Oct 2007 23:22:15 +0300

We talked about the DSL requirements earlier on this list. Now
they have sent us a liaison statement regarding what they would
like to do:

"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. We understand that the authors
of these specifications intend to produce a combined document soon.
The DSL Forum formally requests that the IETF adopt this as a work
item, and would appreciate being advised of progress as soon as possible.

Our next quarterly meeting is December 10-13, in Lisbon, Portugal."

How do we feel about this? Is this a good idea, considering the DSL
architecture? How will it affect DHCP the protocol? How would
you go about making DHCP extensions so that they work best
for all possible environments and not just DSL? Is anyone
already working on the combined draft promised above? Are
there any other choices that we should recommend instead?

I would like to hold the discussion on this in this list until
we've determined that the DHCP protocol is the right tool
for the job. If it is, we can recharter DHC WG again to add
the actual development work there. (DHC is right now
being rechartered but that recharting is mostly a cleanup
and not the addition of functionality to do this.)

Jari

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

---

From: Richard Pruss <[email-masked]>
Date: Fri, 05 Oct 2007 08:45:33 +1000

Jari Arkko wrote, around 5/10/07 6:22 AM:
> already working on the combined draft promised above?
Yep, Li Yizhow, Roberta, Glen and I are working on the combined draft.

- Ric

>  Are

---

From: Alan DeKok <[email-masked]>
Date: Fri, 05 Oct 2007 09:27:04 +0200

Jari Arkko wrote:
> architecture?

  I have no opinion about that, but the choice of CHAP is problematic.

> How will it affect DHCP the protocol? How would

  If architectural issues prevent the choice of other protocols, that
should be reflected in the draft.  It would also help guide discussion.

  If DHCP is going to be used, I would suggest EAP rather than CHAP.
Though that has its own set of issues.  In addition, the method should
have some mechanism for negotiating authentication domains.  This does
not exist in 802.1x, and is sorely missed.

  Alan DeKok.

---

From: "Maglione Roberta" <[email-masked]>
Date: Fri, 5 Oct 2007 17:15:54 +0200

> there any other choices that we should recommend instead?

As a Service Provider I can say that architecture considerations done in DSLF are mainly driven by the evolution of the already deployed solutions for IP Sessions: infect in order to gradually migrate from PPP based to IP based Sessions many SP's today already use a naïf form of identification/authentication based on line ID carried on DHCP w/option 82. Using DHCP w/option 82 as credential for authentication lacks in flexibility because line ID is automatically inserted by the Access Node and restricts the authentication to the DSL Line so it does not allow performing authentication based on username and password, but it can be seen as good starting point to develop a complete solution starting from an existing and already used approach. Basically DHCP is the protocol already involved in the IP Session creation because used for configuring the IP address, and it is the protocol that is currently allowed to transit across Access Node before authentication process completes; adding Authentication mechanism to the DHCP protocol could be seen a way to fill the gap currently present for username/password authentication capability keeping the same behavior provided by PPP: subscriber authentication done before IP Address allocation. In addition considering the impacts on other network elements, DHCP Auth impacts the Residential Gateways (RGW), end user devices and BNG (Broadband Gateway/L3 edge) requiring an extension of a protocol already present on these devices, but it does not require any change to both AAA infrastructure allowing SP's to re-use currently implemented RADIUS based architecture already in place for PPP, and it does not require additional functionalities in the Access Node that can continues to play the role of the DHCP snooping agent together with performing Layer 2 security functions (like preventing Layer 2 flooding, and DHCP spoofing attempts.) 
In summary I think IETF should take in account architecture aspects evaluated by DSL Forum and work on DHCP Authentication proposal as a solution that can fulfill these requirements.

Thanks and Best Regards,
Roberta

-------------------------------------------------------
Roberta Maglione  - CCIE #18425
Telecom Italia 
Broadband Network Services Innovation
-------------------------------------------------------

--------------------------------------------------------------------

CONFIDENTIALITY NOTICE

This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to [email-masked].

        Thank you

                                        www.telecomitalia.it

--------------------------------------------------------------------

---

From: "James Kempf" <[email-masked]>
Date: Fri, 5 Oct 2007 10:19:05 -0700

So I have a some questions.

Around 5 years ago when PANA started, there was significant pushback from 
several IAB members regarding putting network access authentication at the 
IP layer. The pushback was that network access authentication rightly 
belongs at the link layer, because the security problem is authentication 
and authorization for a host to access the link and to allow routing to the 
Internet. Authorization for obtaining configuration information such as an 
IP address, DNS server, etc., is a completely different matter and is 
covered for DHCP by RFC 3118 (though that RFC leaves out the significant 
issue of key provisioning which is important in public access networks such 
as hotspots). PANA was chartered anyway, for the same reasons that are being 
cited now for doing AAA through DHCP, namely that XYZ external body (in that 
case 3GPP2) with the power to push through deployment (which IETF doesn't 
have) said they wanted IP level network access authentication to replace 
PPP.

The first question is, why is this architectural issue any less relevent 
today than it was when PANA was chartered? Why can't the DSL Forum provide 
network access authentication at the link layer, the way 802.11 does? "We 
have all these deployed systems and we can't change them" isn't a valid 
argument, the same was true with 802.11 when 802.1x was added (though 
perhaps not as many deployed systems).

PANA completed their work, I haven't been following it for a while so I 
don't know the publication status of their documents. But presuming they 
have been approved by the IESG and published, why can't the DSL Forum use 
PANA?

I will venture a guess here: they don't want to deploy a new protocol. This 
brings up what, to my mind, is a serious and significant philisophical issue 
about the IETF. PANA is just one of a number of instances in the last three 
or four years in which attempts to do new protocols to solve new problems 
have either been hijacked by people wanting to hack existing protocols or, 
if the new protocol has been developed, have been ignored by network 
equipment vendors and thus have failed to be deployed. Isn't it maybe time 
for the IETF to modify the process whereby new work is chartered, so that no 
working groups are opened that do new protocols and that all work is 
restricted to simply modifying and upgrading old protocols? This would save 
a whole lot of money, both IETFs and the companies who send their people to 
the meetings and allow them to waste their time on email and draft writing 
for protocols that don't get deployed. All that money that IETF and 
companies spent on PANA was essentially wasted.

            jak

----- Original Message ----- 
From: "Jari Arkko" <[email-masked]>
To: "Internet Area" <[email-masked]>
Sent: Thursday, October 04, 2007 1:22 PM
Subject: [Int-area] DCHP-based authentication for DSL?

Jari

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 5 Oct 2007 13:40:58 -0400

The quoted text from the liaison statement is not clear on what they
would like to do.  Do they need a user authentication mechanism for
DHCP?  Or do they need a user authentication mechanism for network
access control?

Yoshihiro Ohba

---

From: Pekka Savola <[email-masked]>
Date: Fri, 5 Oct 2007 22:32:22 +0300 (EEST)

On Fri, 5 Oct 2007, Maglione Roberta wrote:
> As a Service Provider I can say that architecture considerations 
> done in DSLF are mainly driven by the evolution of the already 
> deployed solutions for IP Sessions: infect in order to gradually 
> migrate from PPP based to IP based Sessions many SP's today already 
> use a naïf form of identification/authentication based on line ID 
> carried on DHCP w/option 82. Using DHCP w/option 82 as credential 
> for authentication lacks in flexibility because line ID is 
> automatically inserted by the Access Node and restricts the 
> authentication to the DSL Line so it does not allow performing 
> authentication based on username and password, ...

One thing has been bugging me for a while.  Why exactly is 
username/password authentication useful in this context?

In some cases it's probably worthwhile to tie some special 
configuration (e.g., if the customer has a fixed IP address [can also 
be achieved in DHCP server configs] or an associated static route -- 
these are mainly for power users, SOHOs and SMEs) to the specific 
customer.  Line identification is in many cases sufficient here. 
However one potential advantage is that with user/pass auth the user 
could take his DSL modem, plug it in to some other part of the network 
and get his personal configuration with no config changes at the ISP 
end.

But at least so far (e.g., with ATM based DSL systems) I've seen that 
such transparent moving doesn't work as the ISPs need to configure 
something (not sure what exactly) on their systems in any case.  So, 
unless technology has changed so that transparent moving can be 
supported without config changes, it's not clear how much user vs line 
identification matters.

Because probably 95% or 99% of customers have no special 
configuration, i.e., every bulk user is configured the same way I see 
little reason why username/password authentication would be useful. 
It seems to mostly be a relic of the old "PPP" based thinking.

Am I missing something?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: "Alper Yegin" <[email-masked]>
Date: Sat, 6 Oct 2007 00:12:28 +0300

>Are there any other choices that we should recommend instead?

PANA is the protocol that we have been developing exactly for this problem
space, and especially DSL being one of the usage cases. Looking at the
requirements presented earlier, PANA appears to satisfy them all. If someone
thinks otherwise, let us know. The spec has cleared IESG review, and the
approval announcement is expected in a day or two.

So it is not clear why designing any other solution for this problem space
is needed.

Alper

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 5 Oct 2007 21:18:01 +0200

> there any other choices that we should recommend instead?

Let's start with the last question first: there is no discussion of  
IEEE 802.1x and why that would be insufficient here. Both drafts seem  
to be written to make things as easy as possible on the DSL service  
providers and their vendors without much consideration for the  
migration issues this would impose on end-users. DHCP clients are  
generally not a user serviceable part in the most popular operating  
systems and home gateways. This makes using something that is  
available today, such as 802.1x, highly preferable.

The other thing that is missing in action is IPv6. I think it's  
irresponsible to deploy any new technology that's IPv4-only at this  
point in time. For this reason, too, it's highly preferable to use a  
non-IP based authentication protocol.

There is some discussion in one of the drafts about what the client  
would be, but the discussion is not very illuminating. In my  
experience, there are two ways of connecting to DSL networks: with a  
simple modem, that doesn't do much except some protocol translation,  
and with a home gateway/router with the modem function built in. In  
the former case, the modem generally passes authentication prFrom [email-masked] Sat Oct 06 05:42:45 2007
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: [Int-area] DCHP-based authentication for DSL?
Date: Fri, 5 Oct 2007 21:18:01 +0200
To: Jari Arkko <[email-masked]>
Cc: Internet Area <[email-masked]>

> there any other choices that we should recommend instead?

Let's start with the last question first: there is no discussion of  
IEEE 802.1x and why that would be insufficient here. Both drafts seem  
to be written to make things as easy as possible on the DSL service  
providers and their vendors without much consideration for the  
migration issues this would impose on end-users. DHCP clients are  
generally not a user serviceable part in the most popular operating  
systems and home gateways. This makes using something that is  
available today, such as 802.1x, highly preferable.

The other thing that is missing in action is IPv6. I think it's  
irresponsible to deploy any new technology that's IPv4-only at this  
point in time. For this reason, too, it's highly preferable to use a  
non-IP based authentication protocol.

There is some discussion in one of the drafts about what the client  
would be, but the discussion is not very illuminating. In my  
experience, there are two ways of connecting to DSL networks: with a  
simple modem, that doesn't do much except some protocol translation,  
and with a home gateway/router with the modem function built in. In  
the former case, the modem generally passes authentication protocols  
through more or less transparently, so any device connected to the  
modem, such as a PC or a home gateway/router without the modem  
function built in, will have to engage in authentication directly. In  
the case of the integrated home gateway, the authentication  
credentials would be configured on the gateway and client PCs  
wouldn't have to run the authentication protcol.

If PCs are expected to run the authentication protocol, I have two  
issues (in addition to the ones already mentioned, of course). The  
first is that, assuming the same options are defined for IPv6, I  
would oppose a de-facto requirement that all IPv6 hosts run DHCPv6.  
(Or DHCP for IPv4, for that matter.) For IPv4 hosts, the requirement  
to run DHCP doesn't seem excessive, considering current practice. The  
other issue is how the authentication is started. If client is  
expected to initiate authentication in the first message, this means  
it's not possible to have a client that can seamlessly connect to  
multiple networks that require authentication because the client  
wouldn't know which credentials to use at any given time. Also, being  
easily prompted to send credentials would be a security isssue: an  
attacker could initiate frequent DHCP exchanges to harvast hashed  
credentials. (Experience with WEP shows that this can be detrimental  
under certain circumstances.) So a mechanism where the server  
authenticates itself to the client would be a lot better.

Also, one of the drafts mentions MD5, which is pretty much dead in  
the water with a huge hole in the hull right now, it's only a matter  
of time until it officially sinks.

Further, I'd like to see a more general mechanism. Another situation  
where users need to provide credentials that can benefit from better  
standards are wifi hotspots. This situation is largely similar to the  
DSL situation with the exception that there is often no direct  
relationship with the operator of the hotspot and the user, so the  
user must either select a roaming partner and provide credentials  
appropriate for that roaming partner, or use some other interactive  
method to gain temporary access (scratch cards, credit card  
transactions).

This suggests that a mechanism where unauthenticated users are given  
temporary access to a walled garden and then full access at some  
later point would be more appropriate than a simple success/fail  
authentication method.

---

From: Richard Pruss <[email-masked]>
Date: Mon, 08 Oct 2007 20:03:27 +1000

Pekka Savola wrote, around 6/10/07 5:32 AM:
>> As a Service Provider I can say that architecture considerations done 
>> in DSLF are mainly driven by the evolution of the already deployed 
>> solutions for IP Sessions: infect in order to gradually migrate from 
>> PPP based to IP based Sessions many SP's today already use a naïf 
>> form of identification/authentication based on line ID carried on 
>> DHCP w/option 82. Using DHCP w/option 82 as credential for 
>> authentication lacks in flexibility because line ID is automatically 
>> inserted by the Access Node and restricts the authentication to the 
>> DSL Line so it does not allow performing authentication based on 
>> username and password, ...
>
> and get his personal configuration with no config changes at the ISP end.
>
> little reason why username/password authentication would be useful. It 
> seems to mostly be a relic of the old "PPP" based thinking.
>
> Am I missing something?
It's a good question and for many SP's the line id mechanisms like 
Option 82 marking in DHCP coupled to AAA seem enough, we are seeing two 
cases where it is not:
a) Very large existing SP's would like to move to Ethernet from PPPoA 
and PPPoE.  They have huge customer bases with order entry, billing, 
help desks and all the procedure of established telecommunications 
geared to delivering service against the username and password.  In 
currently a minority of cases line ID is used as well, often with 
different services against different usernames/passwords to provide 
differentiated services to the same physical site.
b) In countries with innovative models between the layer 3 service 
provider and the customer, or more ah hoc, chaotic business 
relationships, between central telco's and local connectivity providers, 
no meaningfully secure knowledge of the access line is possible.  We see 
this out of predominantly but not exclusively China and India.

Do not knock PPP so readily, it brought us through dial and there are 
around 100 million DSL customers using it today.  I have been looking at 
replacing all the things it does in ethernet networks for four years and 
I have grown to respect how much PPP does and does very simply and well 
coupled! This great little protocol has been morphed from dial, across 
as a muxing solution from multiple links between providers and how we 
have learnt to scale it or possibly how it was designed well enough to 
scale for 64K subscribers in a single device with the control plane CPU 
probably equivalent to next years cell phones.  I actually find it a 
profound pity it has become the whipping dog of the IETF crowd and view 
as old fashioned in SP's today.

- Ric

>
> ------------------------------------------------------------------------
>

---

From: Alan DeKok <[email-masked]>
Date: Mon, 08 Oct 2007 13:53:11 +0200

Iljitsch van Beijnum wrote:
> Let's start with the last question first: there is no discussion of IEEE
> 802.1x and why that would be insufficient here.

  DHCP requests are broadcast, whereas EAPoL packets are not.  Perhaps
that makes a difference in certain networks.

> ... The other issue is
> how the authentication is started. If client is expected to initiate
> authentication in the first message, this means it's not possible to
> have a client that can seamlessly connect to multiple networks that
> require authentication

  There could be a DHCP response saying "authentication required", which
would key the new behavior.

> Also, one of the drafts mentions MD5, which is pretty much dead in the
> water with a huge hole in the hull right now, it's only a matter of time
> until it officially sinks.

  Using a non-MD5 authentication method would avoid security issues such
as broken MD5, and harvesting hashes of credentials.

> relationship with the operator of the hotspot and the user, so the user
> must either select a roaming partner and provide credentials appropriate
> for that roaming partner, or use some other interactive method to gain
> temporary access (scratch cards, credit card transactions).

  Most users at hotspots have figured this out already.  They select a
roaming partner, and get redirected to a branded login page.  This
appears to be sufficient for most purposes.

> temporary access to a walled garden and then full access at some later
> point would be more appropriate than a simple success/fail
> authentication method.

  Hotspots do this already.  Many switches have "default VLAN" fallbacks
for unauthenticated (802.1x) users.  I don't think any new technology is
needed here.

  Alan DeKok.

---

From: Jari Arkko <[email-masked]>
Date: Mon, 08 Oct 2007 15:03:44 +0300

Iljitsch,

> available today, such as 802.1x, highly preferable.

802.1x has been one of the other options on the table in DSL
forum, and I think they even sent a similar question to IEEE
as they did earlier to us. I don't know if the IEEE responded
about 802.1x. In any case DSL Forum is saying that their
preferred solution is based on DHCP.

> non-IP based authentication protocol.

Presumably you could develop the same feature for both
IPv4 and IPv6 DHCP. However, IPv6 has also other address
configuration mechanisms, so clearly this could not be
used for preventing access to those. In the case that
the DSL Forum is looking at that does not seem to matter,
however, because in their environment DSL home router
and BRAS would communicate via DHCP only. Presumably
in IPv6 they would use prefix delegation.

> credentials would be configured on the gateway and client PCs wouldn't
> have to run the authentication protcol.

I believe they are looking at the second case. Clearly, expecting new
support from hosts would be very problematic for deployment.

Jari

---

From: Pekka Savola <[email-masked]>
Date: Mon, 8 Oct 2007 17:19:32 +0300 (EEST)

On Fri, 5 Oct 2007, Iljitsch van Beijnum wrote:
> There is some discussion in one of the drafts about what the client would be, 
> but the discussion is not very illuminating. In my experience, there are two 
> ways of connecting to DSL networks: with a simple modem, that doesn't do much 
> except some protocol translation, and with a home gateway/router with the 
> modem function built in. In the former case, the modem generally passes 
> authentication protocols through more or less transparently, so any device 
> connected to the modem, such as a PC or a home gateway/router without the 
> modem function built in, will have to engage in authentication directly. In 
> the case of the integrated home gateway, the authentication credentials would 
> be configured on the gateway and client PCs wouldn't have to run the 
> authentication protcol.

I believe a third option also exists and has some but not so 
significant market share as the first two: DSL adapter resides in a 
PCI card or USB stick that's plugged to the computer.

As a result, 'no host changes' becomes more blurred and in practice, 
anything a DSL router needs to implement must be implemented in common 
host operating systems as well.

But I guess the perspective the DSL forum has here is that they can 
tell the user/ISP deploying this technology to buy a new CPE (brings 
in more money too, yay!) but they cannot require the user to upgrade 
their host operating system.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 8 Oct 2007 16:35:37 +0200

> As a result, 'no host changes' becomes more blurred and in  
> practice, anything a DSL router needs to implement must be  
> implemented in common host operating systems as well.

> tell the user/ISP deploying this technology to buy a new CPE  
> (brings in more money too, yay!) but they cannot require the user  
> to upgrade their host operating system.

The trouble that I have with this is that the model where the modem  
is a gateway that actively does IP stuff is that it gets in the way  
of transparently passing IP to and from the network. I'm currently in  
the position to get a new (probably) DSL line and all services  
include a "router", which I take to be a NAT device. I really don't  
want NAT, but if I have to have it, I want this function to be  
implemented in a device of my choice rather than what my ISP could  
get on the cheap this month.

---

From: Jari Arkko <[email-masked]>
Date: Mon, 08 Oct 2007 17:49:21 +0300

James,

> I will venture a guess here: they don't want to deploy a new protocol. 

It would be good to get the exact details from Ric or Mark or whoever
knows them. But my understanding is that their desires relate to
the following:

- Moving away from a user/password authentication that the
  PPPoE users had would require changes in the business
  processes, e.g., relying on line ID only.

  And it would be a good thing to be able to move around with
  your subscription. Assuming of course that the lower layers
  in the DSL system are capable of allowing that without
  some configuration.

  (And of course, its also a Good Thing to move away from
  PPPoE... we should support that.)

- Moving away from AAA-based authentication would imply
  changes in how subscriber data is managed and served.

- DSLAMs are already looking at DHCP packets and filtering
  them appropriately. A new protocol would require changes
  in DSLAMs.

- 802.1x runs between a port and a switch, I think this means
  that in the DSL world this would translate into a requirement
  for the DSLAM rather than the BRAS performing the
  authentication.

- Practical implementations on the BRAS side currently do
  the option 82 processing in the DHCP code, so new processing
  steps for related purposes are convenient to have in the
  same part of the code.

The different reasons have a different nature. The first two
items do not imply that a DHCP-based solution is needed, just
that some AAA-based approach is. Last item is more about
convenience than anything else. Not sure what would be
involved in the third and fourth items.

Jari

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 8 Oct 2007 19:33:23 +0300

> knows them. But my understanding is that their desires relate to

There was a requirements document presented some time ago. If Mark and Ric
add to that, I think we'd have better understanding.

...

>   them appropriately. A new protocol would require changes

I don't remember not touching the DSLAM was a requirement.
But at any rate, whichever solution you pick, I believe DSLAM would be
touched. 
 
>   for the DSLAM rather than the BRAS performing the

I think that's not the issue. There may be switches even between the CPE and
the DSLAM. For that, 802.1X does not work at all in practical deployments.

>   steps for related purposes are convenient to have in the

Today some DHCP option may be used as a line "identification" tool and
therefore assist AAA in some way. But that does not justify all of a sudden
turning host configuration protocol DHCP into a network access
authentication protocol. That'd be a hack! Many people spoke against doing
that to DHCP. I don't see a justification for IETF to endorse such a
solution, especially when IETF already has a solution for this problem.

I can recap on earlier points and expand on why it is such a bad idea to
overload DHCP for this purpose. But before I do that, I really want to
understand why expand any energy on this when IETF has designed PANA. 

Can the supporters of dhcp-auth explain why they think PANA does not solve
the DSL authentication problem?

Alper

---

From: Mark Townsley <[email-masked]>
Date: Tue, 09 Oct 2007 00:13:09 +0200

> knows them. But my understanding is that their desires relate to
Good summary, Jari, I only have a bit more to add.

[In the interest of disclosure, I am fairly active in the DSL Forum, and 
have been working in an advisory role with Ric and others on DHCP auth. 
Suffice to say, I'm already fairly convinced that something like this is 
necessary, or at least inevitable, given what I know about current DSL 
deployments and trends. So, with individual contributor hat firmly in 
hand....]
>   processes, e.g., relying on line ID only.
Another part of the process is that the authentication stage needs to 
happen before an IP address is assigned, and ACLs installed throughout 
the network (by snooping the DHCP packets in transit) to allow packets 
to/from that IP address to be sent and received.
>   in the DSL system are capable of allowing that without
In addition, is the requirement to support more than one device 
(typically a Set-Top-Box) over a single subscriber line in "bridged" 
mode between the STB and the BRAS. In the latter case, both line-id 
credentials inserted by the DSLAM and credentials from the DHCP client 
are used.

There is also the case where, due to the nature of the way the network 
is operated and other circumstances, relying on the line id in the DSLAM 
is not possible.
>   for the DSLAM rather than the BRAS performing the
The above two points center around the need for the authentication 
protocol to operate over networks which may be ATM, Ethernet, a 
combination of the two, have one or more DSLAMs and agg switches, etc. 
DSL networks around the world have a variety of different architectures 
at L2 and below.
>   steps for related purposes are convenient to have in the
Use-cases require information which is currently presented to the BRAS 
in the DHCP Discover, indicating a need for tight coupling with DHCP, 
regardless of the packaging.

- Mark

---

From: Richard Pruss <[email-masked]>
Date: Tue, 09 Oct 2007 09:58:07 +1000

> that makes a difference in certain networks.
You are on the right track.

The first issue is simply that 802.1x does not traverse a switch. So 
where you have a few layers of switches aggregating your network,  where 
we had PPPoE running from the CPE to the BRAS across the switches, we 
cannot simply put 802.1x and have it replace the authentication function 
of PPPoE. A whole world of issues arise when you try break that part of 
802.1x by having it traverse a switch as 802.1x is port authentication, 
not host authentication, this means if that a single device on the 
switch opens the whole ethernet.  There are a bunch of things happening 
in the IEEE that will fix pieces of this over the years to come.

- Ric

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 08 Oct 2007 22:48:45 -0700

>DHCP requests are broadcast, whereas EAPoL packets are not.

EAPoL packets are sent to a non-forwardable multicast address in wired 
networks, and to a unicast address in IEEE 802.11.

>The first issue is simply that 802.1x does not traverse a switch.

Not so.  Forwarding of IEEE 802.1X frames is a frequently implemented 
feature in switches.  For example, this feature is routinely supported on 
low end switches and VOIP handsets with switch ports.

>A whole world of issues arise when you try break that part of 802.1x by 
>having it traverse a switch as 802.1x is port authentication, not host 
>authentication

Again, not true.  IEEE 802.1X switches today routinely support MAC address 
state, not just port state.  In fact, this feature is supported within the 
Cisco 65xx series switches.

---

From: Richard Pruss <[email-masked]>
Date: Wed, 10 Oct 2007 06:07:14 +1000

I do not get your point? If you are saying we can fix this by changing 
802.1x, and changing every low end switch and every aggregation switch 
in broadband, as well as the RGW and BNG currently involved in PPPoE, 
then bravo, you get right on that.

In the meanwhile two vendors and a couple of service providers have a 
proposal that requires changing the RGW and BNG only.

- Ric

Bernard Aboba wrote, around 9/10/07 3:48 PM:
> feature in switches.  For example, this feature is routinely supported 
> on low end switches and VOIP handsets with switch ports.
> 
>> A whole world of issues arise when you try break that part of 802.1x 
>> by having it traverse a switch as 802.1x is port authentication, not 
>> host authentication
> 
> Again, not true.  IEEE 802.1X switches today routinely support MAC 
> address state, not just port state.  In fact, this feature is supported 
> within the Cisco 65xx series switches.
>

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 10 Oct 2007 12:54:51 +0300

I don't understand why this dhcp-based access authentication proposal is
getting a 4th chance...

It was already discussed 3 times in the past and strongly rejected.

First time when Huawei proposal was discussed in DHC ML:

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

Second time when Cisco version was discussed in DHC ML:

http://www1.ietf.org/mail-archive/web/dhcwg/current/msg07141.html

Third time when the discussion was initiated in INT-area ML:

http://www1.ietf.org/mail-archive/web/int-area/current/msg00735.html
http://www1.ietf.org/mail-archive/web/int-area/current/msg00736.html
http://www1.ietf.org/mail-archive/web/int-area/current/msg00751.html
http://www1.ietf.org/mail-archive/web/int-area/current/msg00749.html

[I've intentionally excluded the feedback of PANA supporters. Obviously
there are few of those in addition to the above list of people.]

On top of that, there is an IAB document that speaks against such a hack:

2.5.  Configuration is Not Access Control

   Network access authentication is a distinct problem from Internet
   host configuration.  Network access authentication is best handled
   independently of the configuration mechanisms in use for the Internet
   and higher layers.

IETF community has spoken in many forms. Not sure why we are still
considering such a proposal.

Alper

> -----Original Message-----
> From: Mark Townsley [mailto:[email-masked]]
> Sent: Tuesday, October 09, 2007 1:13 AM
> To: Jari Arkko
> Cc: James Kempf; Internet Area

---

From: Jari Arkko <[email-masked]>
Date: Wed, 10 Oct 2007 13:06:14 +0300

> Not sure why we are still

Because there is a proposal and request from DSL Forum
about this. We will look at the issue and decide what is
best. And formally, we need to develop a response to
DSL Forum.

Past discussion that you cited is very relevant, but
I don't feel that we completed the discussion at that
time. Some of the current discussion has also revealed
things that I did not know earlier, e.g., about 802.1X
and its applicability.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Wed, 10 Oct 2007 13:30:20 +0300

Do we have some actual data about the availability of
802.1X switch passing feature in DSL deployments?
Would the upgrade for that be a software or a hardware
upgrade? What's the standardization status of the switch
passing feature in IEEE?

Jari

Richard Pruss kirjoitti:
>> EAPoL packets are sent to a non-forwardable multicast address in
>> wired networks, and to a unicast address in IEEE 802.11.
>>
>> feature in switches.  For example, this feature is routinely
>> supported on low end switches and VOIP handsets with switch ports.
>>
>> address state, not just port state.  In fact, this feature is
>> supported within the Cisco 65xx series switches.
>>
>
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 10 Oct 2007 12:44:02 +0200

> upgrade? What's the standardization status of the switch

I'd say that the availability of this feature in the telco/ISP part  
of the DSL line is not an issue: this part is under the control of  
the people providing the service, so adding this feature (unless it's  
technically difficult to do) shouldn't present any problems.

However, if we expect end-user PCs to talk 802.1x to the ISP  
equipment, this means that all the stuff that the end-user may have  
installed, such as the modem (if not provided by the ISP), a home  
gateway, wifi base station and switches must also pass the protocol.

Or the assumption would have to be that the device connecting to the  
modem talks 802.1x. This would be a "lighter" requirement than having  
a new DHCP option as most hosts already do 802.1x.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 10 Oct 2007 13:49:11 +0300

Iljitsch,

> gateway, wifi base station and switches must also pass the protocol.

Since we are talking about converting PPPoE customers to this
new scheme, *something* at the home site has to change.
My guess would be that most likely change would be at the
DSL box that you get from the provider. If it does 802.1X,
PANA, or DHCP Auth from that point to the network does
not matter from the home user's perspective.

Jari

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 10 Oct 2007 13:47:11 +0200

> not matter from the home user's perspective.

Today, you can:

1. hook up a PC directly to a DSL modem
2. use some kind of gateway to connect multiple PCs
3. use a modem with gateway functionality

I would be very interested in learning which of these models the DSL  
forum wants to support. I'm somewhat worried about a situation where  
3. is the only option, because that way, end-users would have to live  
with whatever functionality the (ISP-provided) gateway delivers,  
which will invariably include NAT, and although NAT is always a bad  
thing in theory, a "good" NAT isn't too troublesome in practice while  
a bad one is a disaster.

---

From: Ralph Droms <[email-masked]>
Date: Wed, 10 Oct 2007 08:19:21 -0400

I believe the DSLF document "Subscriber Sessions" (DSLF WT-146) lists  
the DSLF requirements for subscriber session management.  Do we  
(IETF) have access to this document?

- Ralph

On Oct 10, 2007, at Oct 10, 2007,7:47 AM, Iljitsch van Beijnum wrote:

> I would be very interested in learning which of these models the  
> DSL forum wants to support. I'm somewhat worried about a situation  
> where 3. is the only option, because that way, end-users would have  
> to live with whatever functionality the (ISP-provided) gateway  
> delivers, which will invariably include NAT, and although NAT is  
> always a bad thing in theory, a "good" NAT isn't too troublesome in  
> practice while a bad one is a disaster.
>
>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 10 Oct 2007 08:53:12 -0400

> low end switches and VOIP handsets with switch ports.

I'm wondering if it can work over wired networks where a
non-forwardable multicast address is used as the destination MAC
address of EAPoL frames.  How two Supplicants attached to such a
switch can run 802.1X where one Supplicant may receive EAPoL frames
intended to be received by the other one?

Yoshihiro Ohba

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 10 Oct 2007 16:16:16 -0700

>address of EAPoL frames.

IEEE 802.11i supports 802.1X pre-authentication, in which another Ethertype 
is used, and 802.1X frames are sent to a unicast destination, forwarded by 
as many switches as necessary.

Scenarios involving forwarding of multicast frames are typically limited to 
situations in which the switch terminating IEEE 802.1X is one hop away, and 
the forwarding switch acts as a TPMR for 802.1X traffic.  For example, a 
wired VOIP phone might have a switch port, but does not act as a RADIUS 
client, so it forwards 802.1X traffic to a switch at the wall-port.

>How two Supplicants attached to such a

Typically the 802.1X forwarder will not send the 802.1X frames to all ports, 
just to the switch one hop deeper in the network.  That way other 
supplicants should not get confused.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 10 Oct 2007 20:36:38 -0400

> as many switches as necessary.

This 802.1X usage is specific to IEEE 802.11i pre-authentication where
802.1X exchanged over the wired port of the target AP is used for
controlling wireless ports of the AP.  I don't think we can make it
applicable to DSL simply because of different usage.  I believe there
would be lots of corner cases to tackle with if we define an extention
to 802.1X that can generally work across multiple LAN segments.

> client, so it forwards 802.1X traffic to a switch at the wall-port.

I think that two port MAC relay is not applicable to DSL especially in
bridge mode where multiple Supplicants may exist.

> Typically the 802.1X forwarder will not send the 802.1X frames to all 
> ports, just to the switch one hop deeper in the network.  That way other 

I believe downlink Supplicants directly attached to a switch with more
than two ports still get confused, while the direct uplink
Authenticator would not get confused.

Yoshihiro Ohba

---

From: Mark Townsley <[email-masked]>
Date: Thu, 11 Oct 2007 05:11:45 +0200

Ralph Droms wrote:
> the DSLF requirements for subscriber session management.  Do we (IETF) 
> have access to this document?
Ralph, the IETF did get a liaison from the DSLF on WT-146, but the 
entire document does not seem to be posted on our liaison statements 
page. I'm checking with the DSLF now to see if it was expected and 
understood that a snapshot of WT-146 be posted publicly. Generally, 
"Working Texts" are only available to DSL Forum members, though approved 
"Technical Reports" are made public. In any case, a subsequent liaison 
directly included some relevant requirements as an excerpt from WT-146, 
I've cut and paste them here so that folks do not have to deal with the 
.doc if they don't want to:

Req #    Description

IPAuth-1    Authentication must not depend on the use of any given 
application, eg web browser.

IPAuth-2    Must re-use existing SP Authentication infrastructure (use 
Radius Database)  and allow mixed mode operation (eg PPP and IP) on the 
same L3 edge device

IPAuth-3    Must offer L3 edge device (BRAS) subscriber policy 
enforcement via pull and push methods, ie L3 edge must be aware of 
authentication status and any subscriber credentials

IPAuth-4    Must allow for authorization purposes the use of any 
additional identifiers that may be available, eg MAC address, Option82 
circuit-id.

IPAuth-5    Should allow for subscriber nomadicity and support tracking 
of changes to location.

IPAuth-6    Must fit into TR-101 operational model

(TR101 may be found here: 
https://datatracker.ietf.org/documents/LIAISON/file468.pdf)

IPAuth-7     Must support revoking authentication

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)

IPAuth-10    Must be independent of medium type (eg Fixed Ethernet, 
Legacy ATM, PON, WiFi, WiMax, etc)

IPAuth-11    Must not require major re-work for IPv6. None ideally.

IPAuth-12    Must be resilient to attacks on the subscriber, eg against 
brute-force challenge attacks, or  spoofing of an authenticator edge device

IPAuth-13    Must offer authenticator edge device resiliency, eg not be 
prone to DOS authentication attacks

IPAuth-14    Must allow for authentication and download of  subscriber 
service profile before service IP address is assigned

IPAuth-15    Must offer an option to re-authenticate periodically or on 
demand.

IPAuth-16    At an absolute minimum, must provide equivalent or better 
security than PPP CHAP/MD5 does today. Must include the ability to move 
to more secure authentication methods over time.

IPAuth-17    Should  offer authentication fail/success reason message to 
subscriber from authenticator .

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

IPAuth-19    Must  offer scalable subscriber management, eg not rely on 
subscriber credentials configured on the authenticator Edge

IPAuth-20    Must have a logical path towards standardization

IPAuth-21    Must scale to 10000s of  subscribers per L3 edge device (ie 
must be conservative in use of resources)

---

From: Ralph Droms <[email-masked]>
Date: Thu, 11 Oct 2007 08:19:08 -0400

Thanks, Mark...

- Ralph

On Oct 10, 2007, at Oct 10, 2007,11:11 PM, Mark Townsley wrote:

> Ralph Droms wrote:
>> I believe the DSLF document "Subscriber Sessions" (DSLF WT-146)  
>> lists the DSLF requirements for subscriber session management.  Do  
>> we (IETF) have access to this document?
> entire document does not seem to be posted on our liaison  
> statements page. I'm checking with the DSLF now to see if it was  
> expected and understood that a snapshot of WT-146 be posted  
> publicly. Generally, "Working Texts" are only available to DSL  
> Forum members, though approved "Technical Reports" are made public.  
> In any case, a subsequent liaison directly included some relevant  
> requirements as an excerpt from WT-146, I've cut and paste them  
> here so that folks do not have to deal with the .doc if they don't  
> want to:
>
> Req #    Description
>
> IPAuth-2    Must re-use existing SP Authentication infrastructure  
> (use Radius Database)  and allow mixed mode operation (eg PPP and  
> IP) on the same L3 edge device
>
> additional identifiers that may be available, eg MAC address,  
> Option82 circuit-id.
>
> IPAuth-5    Should allow for subscriber nomadicity and support  
> tracking of changes to location.
>
> (TR101 may be found here: https://datatracker.ietf.org/documents/ 
> LIAISON/file468.pdf)
>
> IPAuth-8    Must handle L3 CPE device authentication and end-device  
> (PC) user based authentication (likely with L2 CPEs in the latter  
> case)
>
> IPAuth-12    Must be resilient to attacks on the subscriber, eg  
> against brute-force challenge attacks, or  spoofing of an  
> authenticator edge device
>
> IPAuth-13    Must offer authenticator edge device resiliency, eg  
> not be prone to DOS authentication attacks
>
> IPAuth-14    Must allow for authentication and download of   
> subscriber service profile before service IP address is assigned
>
> IPAuth-15    Must offer an option to re-authenticate periodically  
> or on demand.
>
> IPAuth-16    At an absolute minimum, must provide equivalent or  
> better security than PPP CHAP/MD5 does today. Must include the  
> ability to move to more secure authentication methods over time.
>
> IPAuth-17    Should  offer authentication fail/success reason  
> message to subscriber from authenticator .
>
> IPAuth-18    Must allow for multiple authenticated subscribers on  
> same physical or logical interface.
>
> IPAuth-19    Must  offer scalable subscriber management, eg not  
> rely on subscriber credentials configured on the authenticator Edge
>
> IPAuth-21    Must scale to 10000s of  subscribers per L3 edge  
> device (ie must be conservative in use of resources)
>
>
>
>
>>
>> - Ralph
>>
>>> DSL forum wants to support. I'm somewhat worried about a  
>>> situation where 3. is the only option, because that way, end- 
>>> users would have to live with whatever functionality the (ISP- 
>>> provided) gateway delivers, which will invariably include NAT,  
>>> and although NAT is always a bad thing in theory, a "good" NAT  
>>> isn't too troublesome in practice while a bad one is a disaster.
>>>
>>>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 11 Oct 2007 10:12:51 -0400

Two of the reasons the DSLF is asking for DHCP Auth to be considered by
the IETF are that:

(1) PANA does not meet IPAuth-14 "Must allow for authentication and
download of subscriber service profile before service IP address is
assigned."  IPAuth14 is from the earlier DSLF liaison document to which
Mark referred.

(2) Standard 802.1x was driven by security between physical Ethernet
ports.  The extension work on 802.1af needed for credentials to traverse
a DSLAM will not be available in needed timeframes.

I expect there will be providers who can use PANA & existing 802.1x.
However these are not the use cases the DSLF is requesting assistance
upon.

Eric

> From: Jari Arkko, October 10, 2007 6:06 AM
> 
> Because there is a proposal and request from DSL Forum about 
> this. We will look at the issue and decide what is best. And 
> formally, we need to develop a response to DSL Forum.
> 
> Past discussion that you cited is very relevant, but I don't 
> feel that we completed the discussion at that time. Some of 
> the current discussion has also revealed things that I did 
> not know earlier, e.g., about 802.1X and its applicability.
> 
> Jari
> 
> 
>

---

From: Stig Venaas <[email-masked]>
Date: Thu, 11 Oct 2007 16:48:19 +0200

> assigned."  IPAuth14 is from the earlier DSLF liaison document to which

It says service IP address. I suppose you could possibly get an initial
IP address that allows you to do PANA but not much else, and then after
you are authenticated you would get the service IP address?

Stig

---

From: Mark Townsley <[email-masked]>
Date: Thu, 11 Oct 2007 20:32:15 +0200

> you are authenticated you would get the service IP address?

Possibly. But, remember that the auth step in DHCP is mostly rounding 
out use cases for the operational model that is already in place for DSL 
without PPP. The current model uses Option 82 inserted in the DHCP 
Discover message transiting the network to authenticate the subscriber 
line before IP addresses are assigned, routes installed, and filters 
opened up (binding a MAC address to an IP address) along the path 
between the home and the BRAS. Auth in DHCP allows additional 
credentials from equipment on the residential side of the subscriber 
line to be used by AAA, rather than relying on credentials inserted by 
the DSLAM alone. Allowing an IP address to be assigned, opening filters 
specifically for PANA/EAP alone (as well as inserting the same option 82 
information into PANA during transit, as this will certainly come next 
for cases where RG+DSLAM credentials are necessary at the same time) 
then changing that IP address on the fly, reinstalling filters, etc, is 
a rather significant change in the currently deployed behavior for not a 
lot of gain from the provider's perspective.

- Mark

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 11 Oct 2007 15:50:14 -0400

I don't understand why "reinstalling filters" is needed here.  The
sequence I am thinking is as follows: In the initial state (i.e.,
before PANA authentication), filters are open for DHCP and PANA only.
After PANA authentication, filters for binding the MAC address and
service IP address as well as routes are installed and another DHCP
delivers the service IP address to the client.

Yoshihiro Ohba

---

From: Richard Pruss <[email-masked]>
Date: Fri, 12 Oct 2007 06:48:07 +1000

> delivers the service IP address to the client.
That would require PANA snooping on every switch that does Option 82
insertion and DHCP snooping today.
It would also require a suite of new features on those switches to
filter at the IP layer protocol. Current switches do MAC IP matching and
security features around those two on a per port basis.
This is where the PANA proposal breaks down as it requires every element
in the network to change.

- Ric

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 11 Oct 2007 17:27:35 -0400

I would like to know if PANA snooping is much more difficult than DHCP
snooping.  Also, aren't those switches already doing filtering at the
IP layer protocol by looking at the IP header in order to check if the
received MAC frame carrying the IP packet matches the installed
filters for binding the MAC address and the service IP address?

Yoshihiro Ohba

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 11 Oct 2007 18:37:07 +0200

> assigned."  IPAuth14 is from the earlier DSLF liaison document to  

Hm, but this could be worked around by having a provisional IP  
address that can be used to carry PANA, after which the "service" IP  
address is assigned. The PANA spec specifically mentions such a  
scenario. The advantage of PANA over DHCP is that, as far as I can  
tell from a quick read of the spec, PANA is completely IP version  
agnostic while DHCP and DHCPv6 are orthogonal protocols, raising all  
kinds of issues when 1. adding IPv6 or 2. replacing IPv4 with IPv6.  
Also, while it should be doable to get the necessary changes to DHCP  
into new home gateways within a reasonable timeframe (but forget most  
existing ones), it would be quite hard to upgrade DHCP  
implementations in operating systems. A small but significant part of  
all users uses OS versions which are no longer supported. Unless I  
missed something, PANA could be implemented as a simple third party  
application or even be run as a Java applet in a web browser.

Apart from the IPv4/IPv6 issue and deployment difficulties I'm also  
worried about putting information in DHCP that is specific to a  
single attachment point while DHCP is meant to help a host attach to  
the network in numerous locations without location-specific  
configuration.

Another good way to meet the DSL Forum's requirement would be to run  
PANA over IPv6 link-local addresses. Assuming the presence of an IPv6  
stack on both ends, this seems to be the least problematic way to do  
all of this: you get to talk to the first layer 3 device upstream  
without any layer 2 issues to worry about but address provisioning  
hasn't happened yet so no difficulties there either. This wouldn't be  
ethernet-specific but it would probably be advantageous to correlate  
the MAC address that was used in the PANA exchange with the MAC  
address in subsequent DHCP exchanges.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 12 Oct 2007 11:40:39 +0200

On 11-okt-2007, at 22:48, Richard Pruss wrote:

> That would require PANA snooping on every switch that does Option  
> 82 insertion and DHCP snooping today.
> filter at the IP layer protocol. Current switches do MAC IP  
> matching and security features around those two on a per port basis.
> This is where the PANA proposal breaks down as it requires every  
> element in the network to change.

I don't think this can be a serious argument against other solutions  
that DHCP, because EVERY solution requires numerous changes. The fact  
that adding authentication to DHCP means a little less ISP  
infrastructure needs to change can't be a reason to reject other  
solutions out of hand. Especially because a DHCP solution would  
impose considerable issues on the end-user side. I also don't  
remember seeing this as a requirement in the list that Mark posted.

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 12 Oct 2007 08:23:13 -0400

> October 11, 2007 @ 12:37: Iljitsch van Beijnum 
> 
> > assigned."  IPAuth14 is from the earlier DSLF liaison document to 
> > which Mark referred.
> 
> Hm, but this could be worked around by having a provisional 
> IP address that can be used to carry PANA, after which the 
> "service" IP address is assigned. The PANA spec specifically 
> mentions such a scenario. The advantage of PANA over DHCP is 
> that, as far as I can tell from a quick read of the spec, 
> PANA is completely IP version agnostic while DHCP and DHCPv6 
> are orthogonal protocols, raising all kinds of issues when 1. 
> adding IPv6 or 2. replacing IPv4 with IPv6.  
> Also, while it should be doable to get the necessary changes 
> to DHCP into new home gateways within a reasonable timeframe 
> (but forget most existing ones), 

Yes, the DSLF liaison statements were driven by triple-play providers
who need to change out their CPE anyway.   Since there are 200M+ DSL
lines in the world, this triple play market could eventually become
large.

> it would be quite hard to 
> upgrade DHCP implementations in operating systems. A small 
> but significant part of all users uses OS versions which are 
> no longer supported. Unless I missed something, PANA could be 
> implemented as a simple third party application or even be 
> run as a Java applet in a web browser.
> 
> Apart from the IPv4/IPv6 issue and deployment difficulties 
> I'm also worried about putting information in DHCP that is 
> specific to a single attachment point while DHCP is meant to 
> help a host attach to the network in numerous locations 
> without location-specific configuration.

Many DSL providers already use DHCP with Option 82 (added at the DSLAM)
for location information.  The EAP information transported from the
client would be used incrementally for subscriber (or CPE) identity.
(As an FYI for triple play, it is important that "trusted" customer
specific CPEs can be identified.)
 
> Another good way to meet the DSL Forum's requirement would be 
> to run PANA over IPv6 link-local addresses. Assuming the 
> presence of an IPv6 stack on both ends, this seems to be the 
> least problematic way to do all of this: you get to talk to 
> the first layer 3 device upstream without any layer 2 issues 
> to worry about but address provisioning hasn't happened yet 
> so no difficulties there either. This wouldn't be 
> ethernet-specific but it would probably be advantageous to 
> correlate the MAC address that was used in the PANA exchange 
> with the MAC address in subsequent DHCP exchanges.

What you describe is certainly possible.  But to me it seems more
complicated for failure mode debugging than the DHCP Auth proposals.
(And remember, DSL providers already use DHCP & Option 82.)

Eric

---

From: Mark Townsley <[email-masked]>
Date: Fri, 12 Oct 2007 15:13:32 +0200

Iljitsch van Beijnum wrote:
>> filter at the IP layer protocol. Current switches do MAC IP matching 
>> and security features around those two on a per port basis.
> solutions out of hand. 
I can promise you that the economic realities of the solution will most 
certainly be part of what the ISP decides to deploy.
> I also don't remember seeing this as a requirement in the list that 
> Mark posted.
One of the requirements was: "IPAuth-6    Must fit into TR-101 
operational model" - while "fit into" is rather subjective, I think the 
spirit here was that the solution shouldn't require major rework to that 
design.
> Especially because a DHCP solution would impose considerable issues on 
> the end-user side. 
Now this is getting closer to what the DSL Forum is asking us. What kind 
of issues do you envision here?

- Mark

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 12 Oct 2007 16:44:56 +0200

> client would be used incrementally for subscriber (or CPE) identity.

Yes, I can see how a DHCP solution is attractive from this perspective.

> specific CPEs can be identified.)

Are we then talking about a protocol that is only exchanged between  
an ISP-supplied CPE and the DSLAM? In that case they can use any  
protocol that they want because there is no interaction with the end- 
user or any equipment that's not under the control of the ISP.  
However, from the list of requirements it seems that the DSL Forum is  
looking for something that goes from the end-user PC to the DSLAM or  
from a third party gateway installed and operated by the end-user to  
the DSLAM so the protocol needs to make sense both on commercially  
available home gateways and on regular multi-purpose operating systems.

>> to run PANA over IPv6 link-local addresses.

> (And remember, DSL providers already use DHCP & Option 82.)

So how would a DHCP solution work when the user connects:

- a Windows XP or MacOS X machine but Microsoft/Apple won't be  
including the new DHCP option for another 12 months
- a Windows 98 machine that is no longer getting updates from Microsoft
- a no brand home gateway which can't be upgraded by the user
- a machine that runs DHCP for IPv4 and DHCPv6 for IPv6
- a machine that runs DHCP for IPv6 and runs IPv6 but not DHCPv6
- a machine that doesn't run IPv4 but IPv6 + DHCPv6
- a machine that doesn't run IPv4 but IPv6 without DHCPv6

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 12 Oct 2007 18:40:24 +0200

On 12-okt-2007, at 15:13, Mark Townsley wrote:

>> Especially because a DHCP solution would impose considerable  
>> issues on the end-user side.

> Now this is getting closer to what the DSL Forum is asking us. What  
> kind of issues do you envision here?

See my earlier messages. Basically:

- what happens with IPv6 with and without IPv4, with and without DHCPv6
- deployment issues because DHCP is implemented deep inside OSes
- how does a host know when to present which credentials

---

From: Mark Townsley <[email-masked]>
Date: Fri, 12 Oct 2007 18:59:00 +0200

Iljitsch van Beijnum wrote:
>>> Especially because a DHCP solution would impose considerable issues 
>>> on the end-user side.
>
Perhaps others can answer better, but let me try.
> - what happens with IPv6 with and without IPv4, with and without DHCPv6
Work definitely needs to be done in the DHCP IDs on IPv6. I imagine this 
is coming soon. As for the grander picture of when and where DHCPv6 is 
and is not used in DSL, sad to say but there is no DSL Forum document I 
am aware of that captures this, nor is there industry consensus on 
exactly how it is to be done yet (for DSL), so it's hard to answer that 
question. This is something I am personally going to be pushing for the 
DSL Forum to do very soon, I hope that they are receptive.
> - deployment issues because DHCP is implemented deep inside OSes
Implementation folks familiar with client code I have talked to have 
said that this is not insurmountable. On the BNG side, the servers are 
pretty well used to a call to RADIUS between the Discover and Offer.
> - how does a host know when to present which credentials
I imagine by configuration (along with the username/password which would 
likely accompany such config). Much like a PPPoE interface today.

- Mark

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 12 Oct 2007 13:52:36 -0400

> DSL Forum to do very soon, I hope that they are receptive.

Isn't DSLAM upgrade needed anyways to support IPv6?  Specifically
DHCPv6 spoofing and filters for binding MAC address and IPv6 address
(and IPv4 address as well for dual stack clients) would be needed for
DHCP-based authentication.  Please correct me if I'm wrong, but I
suspect that difference between PANA and DHCP-auth with regard to
impacts on existing DSLAM deployment is only marginal.

Yoshihiro Ohba

---

From: Mark Townsley <[email-masked]>
Date: Fri, 12 Oct 2007 19:59:37 +0200

Yes, updating equipment on the client side is Hard. That's chiefly why 
the dominant mechanism today relies on option 82 where you can do 
subscriber line authentication in DHCP, without touching the Client. The 
Client-side authentication in DHCP is only for the cases where option 82 
isn't workable, and in these cases it is a foregone conclusion that some 
update must be done on the client-side software. Note that the dominant 
*short-term* interest seems to be from ISPs where the client in question 
is a box that they provide to the customer for which they have a lot of 
control over the code within, while the transit switches and BNG come 
from (a variety of) vendors.

- Mark

Iljitsch van Beijnum wrote:
> Are we then talking about a protocol that is only exchanged between an 
> ISP-supplied CPE and the DSLAM? In that case they can use any protocol 
> that they want because there is no interaction with the end-user or 
> any equipment that's not under the control of the ISP. However, from 
> the list of requirements it seems that the DSL Forum is looking for 
> something that goes from the end-user PC to the DSLAM or from a third 
> party gateway installed and operated by the end-user to the DSLAM so 
> the protocol needs to make sense both on commercially available home 
> gateways and on regular multi-purpose operating systems.
>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 12 Oct 2007 14:13:00 -0400

> Iljitsch van Beijnum, October 12, 2007 10:45 AM
> 
> Are we then talking about a protocol that is only exchanged 
> between an ISP-supplied CPE and the DSLAM? In that case they 
> can use any protocol that they want because there is no 
> interaction with the end- user or any equipment that's not 
> under the control of the ISP. 

I don't believe this is the case.  SPs still have a UNI demarcation
between the home and the network.  SPs desire a standardized protocol
which matches to their existing operational experience here.

Beyond that, off-the-shelf CPE is still relevant.  In fact this email
will traverse my Verizon FiOS triple play router.  It turns out this is
a typical off-the-shelf Broadband Router, except with some tweaks such
as the hiding of the WAN PPPoE credentials & configuration.  However
before I got my triple play Router, I just had FiOS broadband service.
In that case I used an off-the-shelf Linksys router, and I was able to
enter my PPPoE credentials myself.  In other words, the CPE to Network
protocol stayed the same across my Verizon FTTH phys as the service mix
and even CPE changed.  Standardizing such parts is *very* valuable for
Operations & troubleshooting.
 
> However, from the list of requirements it seems that the DSL 
> Forum is looking for something that goes from the end-user PC 
> to the DSLAM or from a third party gateway installed and 
> operated by the end-user to the DSLAM so the protocol needs 
> to make sense both on commercially available home gateways 
> and on regular multi-purpose operating systems.

Sequencing is always an issue since it impacts the phased emergence of
deployment models.  PPPoE was PC client software long before it made it
into Broadband routers.
 
> >> PANA over IPv6 link-local addresses.
> 
> - a Windows XP or MacOS X machine but Microsoft/Apple won't 
> be including the new DHCP option for another 12 months

All good questions, it will be interesting to see which of these are
determined to be in-scope if the DSLF request for a WG draft in this
space is accepted :-)

Eric

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 12 Oct 2007 22:33:27 +0300

> assigned."  IPAuth14 is from the earlier DSLF liaison document to which

As others have already explained, PANA can be run using an IP address that
is solely configured/assigned for the PANA signaling (e.g., a link-local
address, or a short-lease private address, etc.) Once PANA is successful,
the client is allowed to configure another IP address, and that'd be your
"service IP address." We have already taken this into account in PANA
design.

...

Coming back to the implementation issue... DSLAMs are already doing DHCP
snooping. Introduction of PANA would mean they also need to snoop on PANA
now. I don't think this justifies EAP/DHCP standardization at all.

Alper

---

From: Jari Arkko <[email-masked]>
Date: Sat, 13 Oct 2007 14:36:35 -0500

> IPAuth-7     Must support revoking authentication

How is this performed in a DHCP solution?

> Legacy ATM, PON, WiFi, WiMax, etc)

Some of thee have their own native network access mechanisms, e.g.,
802.1x/11i, 802.16e EAP authentication, etc. I'm not sure its reasonable
to suggest that based on DSL Forum requirements, these other access
networks would suddenly start doing something else. So what does
this requirement really mean?

Also, some of the suggested solutions appear to be very architecture
dependent. For instance, DHCP-only based authentication scheme
would be inadequate in a network that employs stateless address
autoconfiguration.

> security than PPP CHAP/MD5 does today. Must include the ability to
> move to more secure authentication methods over time.

Is binding of the authentication exchange to the actual address allocation
exchange a requirement? E.g., RFC 3118 authentication in DHCP after
an EAP run vs. simply doing EAP and then DHCP in the usual unprotected
manner? Will cryptographic protection of the data packets ever be
needed in any environment?

Jari

 +0300 (EEST)
Date: Sat, 13 Oct 2007 14:36:35 -0500
From: Jari Arkko <[email-masked]>
To: Mark Townsley <[email-masked]>
Subject: Re: [Int-area] DCHP-based authentication for DSL?
Cc: Bernard Aboba <[email-masked]>, [email-masked]

> IPAuth-7     Must support revoking authentication

How is this performed in a DHCP solution?

> Legacy ATM, PON, WiFi, WiMax, etc)

Some of thee have their own native network access mechanisms, e.g.,
802.1x/11i, 802.16e EAP authentication, etc. I'm not sure its reasonable
to suggest that based on DSL Forum requirements, these other access
networks would suddenly start doing something else. So what does
this requirement really mean?

Also, some of the suggested solutions appear to be very architecture
dependent. For instance, DHCP-only based authentication scheme
would be inadequate in a network that employs stateless address
autoconfiguration.

> security than PPP CHAP/MD5 does today. Must include the ability to
> move to more secure authentication methods over time.

Is binding of the authentication exchange to the actual address allocation
exchange a requirement? E.g., RFC 3118 authentication in DHCP after
an EAP run vs. simply doing EAP and then DHCP in the usual unprotected
manner? Will cryptographic protection of the data packets ever be
needed in any environment?

Jari

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 13 Oct 2007 18:47:57 +0200

> Beyond that, off-the-shelf CPE is still relevant.

Well, in that case it makes sense to consider the bigger picture and  
possibly select a solution that means more work in the short term but  
which better addresses longer-term issues.

> triple play

Off-topic: most of my career, I've been working on multihoming and  
redundancy. It scares me more than a little to use a single wire for  
pretty much everything...

---

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 14 Oct 2007 17:54:03 -0700

>a DSLAM will not be available in needed time frames.

What extensions are you referring to?  In terms of timeframes, are we 
talking about changes to hosts, CPE or DSLAMs?

Tracing this thread, I still am not clear what the transition scenario is:

a)  No changes to hosts, firmware upgrade to CPE and DSLAMs?
b)  No changes to hosts, hardware upgrade to CPE, firmware upgrade to 
DSLAMs?
c) Changes to hosts, firmware upgrades to CPE and DSLAMs?
d) Changes to hosts, hardware upgrades to CPE and DSLAMs?

---

From: Richard Pruss <[email-masked]>
Date: Mon, 15 Oct 2007 11:30:59 +1000

> d) Changes to hosts, hardware upgrades to CPE and DSLAMs?
I am sure there is a a) to z) of options here, all with their own 
chances in the market. When all of our conversations with providers tend 
to end is:
e) No changes to hosts, probably whole new CPE, no changes to DSLAMs, no 
changes to aggregating switches, software upgrade to NAS, no flag day so 
customers at their own speed running PPPoE can switch to IPoE without 
re-provisioning when they get a new CPE for new services.

I do think over time that we will get a secure layer 2 capability driven 
by enterprise requirements and supported by changes in host, CPE and all 
manner of switches, but the time frame for that is simply unknowble.  
Almost all proposals for authentication, at any layer seem to be 
controversial, this makes them slow, including unfortunately DHCP Auth 
it seems.

- Ric

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 17 Oct 2007 18:16:32 +0300

> complicated for failure mode debugging than the DHCP Auth proposals.

Can you elaborate on that? 

> (And remember, DSL providers already use DHCP & Option 82.)

Yes, that is for "line identification". The problem at hand is "subscriber
authentication". They are not quite the same thing.

Alper

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 17 Oct 2007 14:12:15 -0400

> > > PANA over IPv6 link-local addresses. Assuming the presence of an 
> > > IPv6 stack on both ends, this seems to be the least 
> problematic way 
> > > to do all of this: you get to talk to the first layer 3 device 
> > > upstream without any layer 2 issues to worry about but address 
> > > provisioning hasn't happened yet so no difficulties there either. 
> > > This wouldn't be ethernet-specific but it would probably be 
> > > advantageous to correlate the MAC address that was used 
> in the PANA 
> > > exchange with the MAC address in subsequent DHCP exchanges.
> > 

My comment on "certainly possible" related to the larger discussion
earlier in your thread (now cut out) on provisional IP addresses.
Re-inserting your thoughts below:

"As others have already explained, PANA can be run using an IP address
that is solely configured/assigned for the PANA signaling (e.g., a
link-local address, or a short-lease private address, etc.) Once PANA is
successful, the client is allowed to configure another IP address, and
that'd be your "service IP address." We have already taken this into
account in PANA design."

Anyway, last night (no joke :-( ) my parents called me up to
troubleshoot their home DSL router. They had no external connectivity.
I had them log into the home router, and we quickly found they had no
WAN IP address.  I had them re-enter their WAN username/password
credentials, and everything then was back to normal for them.

We didn't have to worry about:
(1) recognizing a temporary signaling IP address
(2) understanding any difference between authentication & IP address
assignment
In this case all we had to understand is that their WAN connection is
either "on" or "off".  

*This is not a knock on PANA*  I am absolutely sure there are extra
capabilities which come from PANA's additional messages.  But the extra
PANA messages/state machines by definition mean more failure modes and
therefore debugging opportunities.  

Hopefully any PANA client software can hide most of these. But I am not
looking forward to the day when my parents call me up and their home
gateway has a provisional IP address, the Authentication has passed
successfully, but for some reason the IP address reconfig has failed.  

Eric

> Yes, that is for "line identification". The problem at hand 
> is "subscriber authentication". They are not quite the same thing.
> 
> Alper
>

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 17 Oct 2007 22:44:06 +0300

> (1) recognizing a temporary signaling IP address

That's trivial. By now anyone who troubleshoots networks can recognize IPv4
and IPv6 link-local addresses. And they know you cannot get far using such
IP addresses.

> (2) understanding any difference between authentication & IP address

Not sure I understand how performing both using the same protocol helps
here.

> therefore debugging opportunities.

Somehow this sounds like we are as close to defining EAP/DHCP as defining
just a DHCP option. That's very unrealistic. EAP and network access
authentication process have its own state machine. See IEEE 802.X and IEEE
PKMv2 state machines. You cannot not have one if you are defining a new EAP
transport. And the problem is, those state machines are not compatible with
the DHCP state machine. 

EAP/DHCP will have to have a state machine, and even the "extra" messages to
be a proper EAP lower layer for network access authentication.

Alper

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 17 Oct 2007 16:21:55 -0400

> That's trivial. By now anyone who troubleshoots networks can 
> recognize IPv4 and IPv6 link-local addresses. And they know 
> you cannot get far using such IP addresses.

My parents are not networking experts.  At all.  But if they buy an
off-the-shelf broadband router, they are expected to troubleshoot its
various states.
 
A truism is that more states = more complexity when debugging.  

Eric

---

From: Alan DeKok <[email-masked]>
Date: Thu, 18 Oct 2007 01:29:57 +0200

> and IPv6 link-local addresses. And they know you cannot get far using such

  If the network providers have configured their systems nicely, you
should be able to use multicast DNS to find a local web page with "help"
information.  You may even discover that the web page contains
information about your machine: what's wrong, and/or why your account
has been disabled.

  Alan DeKok.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 18 Oct 2007 09:27:20 +0200

> A truism is that more states = more complexity when debugging.

A good argument for no authentication and hardcoded IP provisioning  
rather than using all kinds of protocols to configure this stuff each  
time a connection comes up.

But it's a false dichotomy. A complex protocol can be easy to manage  
if designed properly. 10 years ago I often had to debug PPP  
negotiations but these days, that's no longer necessary because even  
though PPP is fairly complex in its interactions, implementations on  
both sides have matured to the point where failures because of  
incorrect information on the subscriber side are almost always  
obvious enough even for non-technical users.

---

From: "Julien Bournelle" <[email-masked]>
Date: Thu, 18 Oct 2007 17:08:06 +0200

Hi all,

 some years ago we proposed to add configuration data to the EAP protocol.
This proposal had been rejected and one argument was that EAP protocol
is an authentication protocol and not a configuration protocol and that the IETF
configuration protocol is DHCP. Now, I have the impression that this
the opposite,
some want to add authentication mechanism in the IETF configuration protocol
and I feel the argument is the same. As mentioned several time by alper, this
is clearly stated in a IAB's draft, section 2.5

http://www.ietf.org/internet-drafts/draft-iab-ip-config-00.txt

"Network access authentication is a distinct problem from Internet
   host configuration.  Network access authentication is best handled
   independently of the configuration mechanisms in use for the Internet
   and higher layers."

If people does not agree with the above statement, they should say so to IAB.

Based on that, my opinion is that the IETF should not support DHCP-based
authentication and should recommend use of PANA which has been defined
at the IETF for network access authentication.

Best Regards;

 Julien Bournelle

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 18 Oct 2007 08:41:23 -0700

>information about your machine: what's wrong, and/or why your account

This is true only if the users actually have connectivity.  In my 
experience, in most situations in which only an IPv4 link-local address is 
available, there is no IP-level connectivity.  This is typically due to a 
link-level failure of some kind, such as an acknowledgement failure within 
the IEEE 802.11 4-way handshake.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 18 Oct 2007 17:40:58 +0200

> configuration protocol is DHCP. Now, I have the impression that this

  PPP, RADIUS, and Diameter have been combining authentication and
authorization (including host configuration) for a long time.  PANA
doesn't carry configuration directly, but does interact with
configuration systems when the PaC IP address changes.

  One trend I've noticed recently is that AAA is showing up in nearly
every WG.  I think it's a recognition that authentication can't be
performed independently of everything else.  It has to be strongly tied
into the network design.

  Alan DeKok.

---

From: David R Oran <[email-masked]>
Date: Wed, 17 Oct 2007 08:40:44 -0400

Jari asked me to forward this to the int-area list, so here it is:

> I have similar architectural questions and concerns.
>
> Full disclosure: I have had a long-standing (>18 month) standing
> technical disagreement with the author of one of the proposals. I have
> suggested a number of alternative designs, which have not been
> pursued.
>
> The state of affairs is that a number of DSL providers have awakened
> to the fact that PPPoE does not scale well in G-PON environments, and
> are looking to a system which maintains the PPPoE L2 virtual-circuit
> model of subscriber management and security while using a
> lighter-weight and scalable solution like DHCP. However, they are
> allegedly unable (unwilling?) to replace the PPPoE-style authorization
> scheme with something architecturally clean, and instead see adding
> access authorization as a side-effect of IP address assignment as the
> expedient thing to do.
>
> In the PPPoE world, IP addresses are assigned as part of link
> initialization and hence the two operations are atomic. In the world
> of multi-access channels and DHCP, they two are not coupled unless you
> change the DHCP protocol to make them coupled.
>
> I think coupling IP address assignment (and by extension the rest of
> host configuration) to access authorization is the wrong thing to do,
> for a number of reasons:
>
> a) The two have little or nothing to do with one another conceptually
>
> b) It ties access authorization to DHCP lease times, forcing
> tradeoffs/compromises between address pool usage as a resource and
> communication bandwidth as a resource.
>
> c) It limits, and perhaps prohibits, an IP-based approach to access
> authorization via a separate protocol, thereby making a number of
> things more difficult, among them are:
> - the ability to provide destination address-limited or rate-limited
> IP packet transport prior to access authorization, or in the case
> where it fails due to reasons other than the subscriber not having
> appropriate credentials.
> - the ability to receive packets from a (possibly limited) set of
> services that need to talk to the host prior to access authorization.
> If you couple to DHCP, the host is essentially able to do nothing
> useful if it can't send packets because it can't obtain an IP address.
>
> d) it makes yet another arbitrary difference between unicast and
> multicast - I can receive multicasts without getting a unicast IP
> address assigned, and hence this authorization approach will not work
> for multicast and something else may be needed anyway.
>
> Of these I consider (c) to be the most serious.
>
> Dave Oran (speaking as an individual, but with my IAB hat close at
> hand).
>

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 18 Oct 2007 22:02:53 +0300

> My parents are not networking experts.  

We were talking about you as the person troubleshooting their system. I
wasn't expecting them to know that. Like they'd not know what various DHCP
states resulting from EAP/DHCP or other DHCP configurations would mean.

> At all.  But if they buy an

EAP and network access authentication related states do not disappear just
because you are embedding EAP inside the host configuration protocol. It
just happens that the host configuration protocol all of a sudden starts
having a combined state machine that reflects all possible combinations of
the former type states and the latter types. How is that a good thing?

A limited-access IP address configured before access authentication is also
a good thing. Like Alan was suggesting, it helps the end user achieve
limited connectivity for troubleshooting. And also consider emergency
services. They expect you to dial 911 even without authentication. There you
need an IP address.  

Btw, whether you like it or nor, even with your EAP/DHCP solution you get
one IPv6 link-local address on the CPE before authentication. What do you
want to do with that one?

Alper

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 18 Oct 2007 16:59:05 -0400

> > > recognize IPv4 and IPv6 link-local addresses. And they know you 
> > > cannot get far using such IP addresses.
> > 
> We were talking about you as the person troubleshooting their 
> system. I wasn't expecting them to know that.

Yes, but I don't scale across my whole neighborhood either. (I am sure
just about everyone one this list does nighttime work for their
friends/family on home networking issues :-).

> Like they'd not 
> know what various DHCP states resulting from EAP/DHCP or 
> other DHCP configurations would mean.
>
> EAP and network access authentication related states do not 
> disappear just because you are embedding EAP inside the host 
> configuration protocol.

Granted.  I have been assuming troubleshooting the EAP part would be
independent no matter what lower layer protocol is used.

> It just happens that the host 
> configuration protocol all of a sudden starts having a 
> combined state machine that reflects all possible 
> combinations of the former type states and the latter types. 
> How is that a good thing?

It is a *wonderful* thing to hide interim states from an end client when
knowledge of that interim state wouldn't change the end result of the
call flow.  A good example of this is your typical credit card
transaction:

When you buy something on a credit card, your card-issuing bank is
validated, your account is checked to see if it is active & in good
standing, and the amount to be applied against the account is checked
against the available balance.  These are not three separate
transactions with the CPE.  All that really matters is a single response
to a query which either indicates success, or the reason for a failure.

If you accept that Authentication & IP Address assignment can be bundled
when talking to some types of CPE (and not everyone agrees to that, but
it works for PPPoE), then it is not unreasonable to reduce the number of
interactions with a CPE.
 
> A limited-access IP address configured before access 
> authentication is also a good thing. Like Alan was 
> suggesting, it helps the end user achieve limited 
> connectivity for troubleshooting. And also consider emergency 
> services. They expect you to dial 911 even without 
> authentication. There you need an IP address.  

Any standardized DHCP Auth mechanism shouldn't preclude this.  In fact,
non-standard 802.1x implementations have already blazed this trail.  EAP
over 802.1x credential failure can allow the access port to be allocated
to a guest VLAN instead of the access port going into a port-blocked
mode.  Likewise, DHCP Auth EAP credential failure could result in the L3
edge assigning the subscriber a non-public IP Address, and associating
the customer with a diagnostic VRF (w/ 911 support of course).   

Eric
 
> Btw, whether you like it or nor, even with your EAP/DHCP 
> solution you get one IPv6 link-local address on the CPE 
> before authentication. What do you want to do with that one?
> 
> Alper
> 
> 
> > 
> > Eric
>

---

From: Richard Pruss <[email-masked]>
Date: Fri, 19 Oct 2007 07:32:03 +1000

Et Tu Brutus,
Inline:

>> a) The two have little or nothing to do with one another conceptually
AAA has always coupled authentication and configuration.
>> communication bandwidth as a resource.
Connects, does not tie.  Authentication can live longer than the lease.
>> useful if it can't send packets because it can't obtain an IP address.
You are assuming the outcome of a policy actions in the BRAS.  If a 
client does not authenticate it can be given an IP address and 
appropriate network context configuration that can let the user by 
example reach a web server to subscribe to the service.

- Ric

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 18 Oct 2007 19:36:44 -0400

> the customer with a diagnostic VRF (w/ 911 support of course).   

Then how is DHCP auth different from PANA in terms of debugging?

Yoshihiro Ohba

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 18 Oct 2007 21:08:53 -0400

> From: Yoshihiro Ohba, October 18, 2007 7:37 PM
> > Any standardized DHCP Auth mechanism shouldn't preclude this.  In
> > fact, non-standard 802.1x implementations have already blazed this
> > trail.  EAP over 802.1x credential failure can allow the
> access port
> > to be allocated to a guest VLAN instead of the access port
> going into
> > a port-blocked mode.  Likewise, DHCP Auth EAP credential
> failure could
> > result in the L3 edge assigning the subscriber a non-public
> IP Address, and associating

? Compare the number of total state transitions between CPE boot &
operation; compare the operational delta from existing/embedded DHCP
Option 82 deployments.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 18 Oct 2007 21:39:00 -0400

> operation; compare the operational delta from existing/embedded DHCP

I was mentinoning in terms of the number of combinations of IP address
allocation state (no address/non-service address/service address) and
authentication state (unauthenticated/authenticated) that may be used
for debugging/troubleshooting.  But even in terms of state transtions,
I don't see much difference.  EAP state transitions make no
diffirence.  Option 82 makes no difference if option 82 is also
inserted in PANA message.  DHCP state transisions (excluding those for
EAP state transitions) before completion of authentication makes no
diffirence.  The only difference would be DHCP state transitions after
successful authentication in PANA, but I don't really think this is a
big deal that can justify significant change to DHCP.

Yoshihiro Ohba

---

From: Richard Pruss <[email-masked]>
Date: Fri, 19 Oct 2007 13:00:48 +1000

Yoshihiro Ohba wrote, around 19/10/07 11:39 AM:
> Option 82 makes no difference if option 82 is also
You still arguing PANA? The difference is that DHCP snooping and Option
82 insertion is implemented.
Running code, get it? DHCP snooping and Option 82 insertion is
implemented and deployed worldwide, working for millions of subscribers...

If the DSLForum is going to try recommend the huge cost to do something
that changes every device in the Ethernet layer I suspect they probably
will take something from IEEE,
that fixes MAC security and takes something like 802.1x but that
traverses client side and provider switches. Not PANA.

DHCP Authentication is a small change to the existing deployment that
has Port as credentials for Option 82 and simply adds the ability to
have client supplied credentials but
otherwise uses the same architecture that is deployed today for Option
82 driven Ethernet DSLAMs and the upstream terminating BRASes.

- Ric

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 19 Oct 2007 01:02:49 -0400

Yoshihiro,
Jari,

I don't have a problem with PANA.  It looks like a fine protocol.

Yet the DSL Forum didn't ask for PANA, they asked for DHCP Auth.  Twice.
I believe there are sound operational reasons for why they have done so.
And I have done my best to reflect some of those during this debate.

Since it has been two weeks, I have reattached at the bottom Jari's
original request which started this thread.  His original question
remains: do we recharter DHC to do what is being requested?

If the IETF's answer is "no", I would suspect the DSLF will refocus
itself on extending the nascent 802.1af work instead.  Remember, the
first DSLF liaison statement was also addressed to the IEEE.

IMHO, the IETF needs to soon decide whether it wants to continue the
protocol leadership it has enjoyed with Broadband and its hundreds of
millions of PPPoE & DHCP Opt82 subscribers, or pass the baton to the
IEEE.

Eric   

> From: Yoshihiro Ohba, October 18, 2007 9:39 PM
> 
> I was mentinoning in terms of the number of combinations of 
> IP address allocation state (no address/non-service 
> address/service address) and authentication state 
> (unauthenticated/authenticated) that may be used for 
> debugging/troubleshooting.  But even in terms of state 
> transtions, I don't see much difference.  EAP state 
> transitions make no diffirence.  Option 82 makes no 
> difference if option 82 is also inserted in PANA message.  
> DHCP state transisions (excluding those for EAP state 
> transitions) before completion of authentication makes no 
> diffirence.  The only difference would be DHCP state 
> transitions after successful authentication in PANA, but I 
> don't really think this is a big deal that can justify 
> significant change to DHCP.
> 
> Yoshihiro Ohba
> 

-----Original Message-----
From: Jari Arkko [mailto:[email-masked]] 
Sent: Thursday, October 04, 2007 4:22 PM
To: Internet Area
Subject: [Int-area] DCHP-based authentication for DSL?

We talked about the DSL requirements earlier on this list. Now they have
sent us a liaison statement regarding what they would like to do:

"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. We understand that the authors of
these specifications intend to produce a combined document soon.
The DSL Forum formally requests that the IETF adopt this as a work item,
and would appreciate being advised of progress as soon as possible.

How do we feel about this? Is this a good idea, considering the DSL
architecture? How will it affect DHCP the protocol? How would you go
about making DHCP extensions so that they work best for all possible
environments and not just DSL? Is anyone already working on the combined
draft promised above? Are there any other choices that we should
recommend instead?

I would like to hold the discussion on this in this list until we've
determined that the DHCP protocol is the right tool for the job. If it
is, we can recharter DHC WG again to add the actual development work
there. (DHC is right now being rechartered but that recharting is mostly
a cleanup and not the addition of functionality to do this.)

Jari

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 19 Oct 2007 11:31:48 +0300

Ric,

We are not saying DSLF MUST use PANA. But if DSLF is coming to IETF with the
requirements it did and seeking a L3-based access authentication protocol,
IETF has designed PANA exactly for that.

If DSLF is satisfied with a 802.1X extension and IEEE is delivering that, so
be it. There is nothing wrong with that.

There does not appear to be a strong justification to hack DHCP the way you
are proposing. Many people spoke against that already. 

Based on a cost/benefit analysis, doing that to DHCP may be justified for a
DSL product line group, I'd understand. But not for the IETF, imo.

Alper 

> From: Richard Pruss [mailto:[email-masked]]
> Sent: Friday, October 19, 2007 6:01 AM
> To: Yoshihiro Ohba
> Cc: Internet Area

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 19 Oct 2007 10:48:03 +0200

> And I have done my best to reflect some of those during this debate.

However, they also seem to be interested in something future proof.  
Apart from numerous other issues, nobody has been able to explain  
what doing this with DHCP will mean for IPv6 (with or without IPv4  
being present).

In my opinion, until that happens to a satisfactory degree, it's  
impossible to continue.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 19 Oct 2007 12:10:02 +0300 (EEST)

> are proposing. Many people spoke against that already.

FWIW, Cisco has claimed IPR on the DHCP solution:

http://www1.ietf.org/ietf/IPR/cisco-ipr-draft-pruss-dhcp-auth-dsl-00.txt

I wonder if other solutions are similarly affected.

Just something to chew on when looking at potentially applicable 
solutions...

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 19 Oct 2007 11:15:52 +0200

That explains a bit better why the existing solution "cannot be used" ...

Pekka, thanks for the pointer!

---

From: "Julien Bournelle" <[email-masked]>
Date: Fri, 19 Oct 2007 13:09:43 +0200

Hi,

> millions of PPPoE & DHCP Opt82 subscribers, or pass the baton to the

 I don't think that this is what IETF need to decide...we need to
decide if DHCP-based
authentication is the right thing to do.

Julien

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 19 Oct 2007 08:04:21 -0400

It seems that the IETF answer is pretty clear, so let me make a
comment on extending IEEE 802.1af.  

I believe extending IEEE 802.1af has its own contradiction.  If 802.1X
frames are allowed to be forwarded across multiple LAN segments in a
LAN, then it means that the clients already have, before they are
authenticated, full access to the MAC-layer service including bridging
service.  If we consider an analogy by taking one layer up, it is
similar to running network access authentication over IP between pairs
of IP hosts in end-to-end fashion while the IP hosts already have full
Internet access, which does not make much sense.  Of course, if data
packet ciphering is needed at L2 in addition to full access to the
MAC-layer service, then it might make sense to define IPsec-like
security architecture over L2 (with IKE-like protocol for
authentication and key management) that works between pairs of L2
devices across multiple LAN segments in a LAN, but I doubt if DSLF
really needs data packet ciphering at L2 across multiple LAN segments.
I would suggest DSLF people to think about this architectural aspect
before seriously considering an extension of 802.1af.

Best Regards,
Yoshihiro Ohba

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Fri, 19 Oct 2007 14:48:20 +0200

> 
> Based on a cost/benefit analysis, doing that to DHCP may be 
> justified for a DSL product line group, I'd understand. But 
> not for the IETF, imo.

This doesn't square up to the fact that specific technology groups do
have requirements that the IETF is engaged in addressing, eg capwap,
ancp, 16ng, etc, etc. DHCP extensions to suit specific technologies also
abound, eg RFC 3594, RFC 4390, etc. All in all, thus it seems like the
IETF is open to allowing technology specific protocols or extensions
there-of, which is even more understandable, imo.

-Woj.

> inserted in PANA 
> > > message.  DHCP state transisions (excluding those for EAP state 
> > > diffirence.  The only difference would be DHCP state transitions 
> > > after successful authentication in PANA, but I don't really think 
> > > this is a big deal that can justify significant change to DHCP.
> > >
> > >
> > If the DSLForum is going to try recommend the huge cost to do 
> > something that changes every device in the Ethernet layer I suspect 
> > they probably will take something from IEEE, that fixes MAC 
> security 
> > and takes something like 802.1x but that traverses client side and 
> > provider switches. Not PANA.
> > 
> > have client supplied credentials but otherwise uses the same 
> > architecture that is deployed today for Option

---

From: Ralph Droms <[email-masked]>
Date: Fri, 19 Oct 2007 09:27:00 -0400

Alper - It looks like the DSLF requirements have evolved over time.   
The initial DSLF liaison statements (May, 2007), sent to both the  
IETF and the IEEE, request a solution to subscriber authentication  
without specifying a particular solution technology.  The  
requirements in "Subscriber Authentication in DSL Networks" don't  
mention the use of any specific IETF or IEEE protocols:

   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

The more recent DSLF liaison statement (August, 2007), sent to the  
IETF, is more specific, asking the IETF to adopt a document merging  
the mechanisms in draft-pruss-dhcp-auth-dsl-01.txt or draft-zhao-dhc- 
user-authentication-02 as a work item; note the title explicitly  
calls out DHCP:

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

Therefore, it seems that now the DSLF is looking for a DHCP-based  
solution, based on the as yet unpublished document derived from the  
two I-Ds cited above.

- Ralph

On Oct 19, 2007, at Oct 19, 2007,4:31 AM, Alper Yegin wrote:

> justified for a
>>> after
>> something

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 19 Oct 2007 07:33:19 -0700

>service.

IEEE 802.1af has discussed allowing unicast destinations in IEEE 802.1X
wired frames, similar to what is already done in IEEE 802.11i.  If that is
adopted, then the forwarding issue is moot.  Even with multicast
destinations I would not assume that arbitrary forwarding is allowed;
existing implementations forward only to a specific designated 
authenticator.

I would also note that IEEE 802.1af is discussing "discovery" extensions 
very
similar to what exists in PPPOE.

>Of course, if data
>devices across multiple LAN segments in a LAN

That is within the charter of IEEE 802.1af, which is about providing keying 
material for IEEE 802.1ae (e.g. "encrypted Ethernet").

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 19 Oct 2007 12:00:25 -0400

> From: Pekka Savola, October 19, 2007 5:10 AM
> To: Alper Yegin
> Cc: 'Internet Area'
> 
> > There does not appear to be a strong justification to hack DHCP the 
> > way you are proposing. Many people spoke against that already.
> 
> Just something to chew on when looking at potentially 
> applicable solutions...
> 

Well, since you brought it up...

Binding of DHCP and PANA...
http://tinyurl.com/yvjx9l

Triggering DHCP actions from IEEE 802.1x state changes...
http://tinyurl.com/2avgk2

If you spend ten minutes on the USPTO website, you will quickly see that
all of this technology has claims on it, far more than on the IETF IPR
website.

http://www.uspto.gov/patft/

"Results of Search in US Patent Collection db for:
(DSL AND Authentication): 953 patents."

"Results of Search in US Patent Collection db for:
((EAP AND Network) AND Access): 146 patents."

At least Cisco disclosed its IPR to the IETF.

Eric

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 19 Oct 2007 18:30:32 +0200

What a mess....

Only good that the 953 patents found with the (DSL AND Authentication) 
query are not all related to DHCP-EAP and PANA ...

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 19 Oct 2007 22:14:00 +0300

Ralph, 

This is quite confusing.

In their latest liaison letter, DSLF says they "are aware that discussion is
still ongoing" based on their requirements. Last time they contacted us,
they left us with the requirements. And that's where IETF has been.

The latest liaison letter also says "seriously consider adopting". So, it is
not like they decided to use that thing. Would they still want to pursue it
even after so many people said it is a bad idea?

I'm sure the DSLF would appreciate the feedback and would be willing to
reconsider it. Besides, that's the spirit of the thread Jari started. This
is not a 'how we merge the two documents and make an RFC out of it'
discussion.

Alper

> From: Ralph Droms [mailto:[email-masked]]
> Sent: Friday, October 19, 2007 4:27 PM
> To: Alper Yegin
> Cc: Internet Area
> > way you

---

From: Mark Townsley <[email-masked]>
Date: Fri, 19 Oct 2007 22:07:04 +0200

Alper Yegin wrote:
> The latest liaison letter also says "seriously consider adopting". 
It also says "The DSL Forum formally requests that the IETF adopt this 
as a work item, and would appreciate being advised of progress as soon 
as possible."
> So, it is
I suppose that depends on the reasons given when they received the news. 
If, for example, a rejection is sent on fundamental architectural 
grounds against using DHCP for subscriber line authentication and 
initiation of IP sessions, the IETF and DSLF would likely be at an 
impasse as this is the fundamental basis for TR-101 and a great deal of 
code and deployment.

- Mark

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 19 Oct 2007 23:30:54 +0300

> as a work item, and would appreciate being advised of progress as soon

Yes, this is why it is confusing. The letter seems to imply DSLF is asking
IETF to adopt something that they are just considering to use.

> initiation of IP sessions, 

What is "subscriber line authentication" now? Option 82 helps with "line
identification". And what is needed is "subscriber authentication". The two
are quite distinct things. 

> the IETF and DSLF would likely be at an

Is TR-101 fundamentally based on using DHCP for subscriber authentication? 

As for the "great deal ..." we have yet to understand what the exact delta
is, between hacking DHCP vs using PANA. I'd appreciate if someone can
enumerate it.

Alper

---

From: Ralph Droms <[email-masked]>
Date: Fri, 19 Oct 2007 16:47:15 -0400

Alper - I was mostly responding to what you wrote as "if DSLF is  
coming to IETF with the requirements it did and seeking a L3-based  
access authentication protocol [...]".

My read of the liaison statements is that the first liaison  
statements were looking for an L3 solution.  And I agree that the  
DSLF will listen carefully to our feedback, based on Jari's request  
that the Internet Area discuss the architectural issues surrounding  
"IP subscriber authentication".

Reading the latest liaison statement, starting with the title "DSL  
Subscriber Authentication using DHCP" and the request for the IETF to  
take on draft-pruss-dhcp-auth-dsl and/or draft-zhao-dhc-user- 
authentication-02 as a work item, leads me to believe the DSLF is  
asking now for a DHCP solution rather than, more generally, an L3- 
based access authentication protocol.  If the int-area discussion  
leads to consensus that DHCP is not the right basis for "subscriber  
authentication", I suspect we will need to build a solid case arguing  
for some other solution in our response to the DSLF.

Speaking as an individual IETF contributor, I don't think we have  
enough information to make a good judgment about whether to adopt a  
DHCP-based solution as a work item, or whether some other standards  
can be composed into a solution.  We have the requirements from the  
earlier liaison statements, but no guidance as to why "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 or  
draft-zhao-dhc-user-authentication-02".  We have heard additional  
arguments for and against a DHCP-based solution, but those arguments  
are based on undocumented requirements, business considerations,  
etc.  We don't yet have the "combined document" based on the two  
Internet Drafts for review.  And, we don't have a document that  
completely describes an alternative, non-DHCP solution that can be  
analyzed against the DSLF requirements.

- Ralph

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 19 Oct 2007 16:53:55 -0400

> Would they still want to pursue it even after so many people 
> said it is a bad idea?

Alper,

You are stretching facts way past the breaking point here.  Looking back
at the thread only one person from a Service Provider has said they
prefer PANA to DHCP Auth (Lionel).  One person from an SP has written
why DHCP Auth is a good idea (Roberta).

Is it surprising that the intensity of our current debate has pushed
providers into a "wait & see" mode?  This debate is too important for
the outcome to depend on a small number of loud voices with vested
interests talking past each other.

I am going to encourage SPs I know to contact Jari, Ralph, Stig, & Mark
directly.  You could do the same with any SPs desiring PANA.  Hopefully
the direct feedback will give them clarity into the request on the
table.

Eric

---

From: "Alper Yegin" <[email-masked]>
Date: Sat, 20 Oct 2007 00:03:11 +0300

Ralph,

> And, we don't have a document that

http://ietf.org/internet-drafts/draft-ietf-pana-pana-18.txt

Alper

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 19 Oct 2007 17:28:50 -0400

Ralph, 

Will do. 

Eric

> From: Ralph Droms, October 19, 2007 5:09 PM
> 
> Eric - please ask those SPs participate in the public 
> Internet Area discussion.  This is a request to the IETF and 
> a decision based on IETF consensus, not based on information 
> known only to WG chairs and ADs.
> 
> - Ralph
> 
> On Oct 19, 2007, at Oct 19, 2007,4:53 PM, Eric Voit (evoit) wrote:
> 
> >> Would they still want to pursue it even after so many 
> people said it 
> >> is a bad idea?
> >
> > Alper,
> >
> > You are stretching facts way past the breaking point here.  Looking 
> > back at the thread only one person from a Service Provider has said 
> > they prefer PANA to DHCP Auth (Lionel).  One person from an SP has 
> > written why DHCP Auth is a good idea (Roberta).
> >

---

From: Mark Townsley <[email-masked]>
Date: Sat, 20 Oct 2007 00:28:53 +0200

> are quite distinct things. 
Whether the information comes as a text string via DHCP from the DSLAM, 
or comes via a challenge-handshake in DHCP from the CPE, is fairly 
immaterial in terms of the fact that DHCP is still triggering the start 
of an IP session at the BRAS, an Access-Request is being made to AAA 
based on information within the DHCP messages, an Access-Accept or 
Access-Reject is being received by the BRAS along with a subscriber 
profile, IP address, etc., DHCP is then allowed to continue or not based 
upon the AAA response, and offers information based on the subscriber 
profile received from AAA. A route and filter is dynamically installed 
at the BRAS, and equipment between the BRAS and CPE sniff the DHCP ACK, 
binding the IP address (or prefix) and MAC address to better ensure that 
only traffic from the device involved in the DHCP exchange is allowed to 
send packets via the offered prefix and associated MAC into the network.

So, imagine you call your SP for new service. The SP finds a wire that 
stretches from your DSLAM to your home, give it a name, and type it into 
the DSLAM. Or, they ship you a box with a username and password stored 
in it, and you connect it to the other end of that same wire. Or, 
perhaps you buy your own box and you both agree on something to type 
into it. Maybe you are even allowed to connect two boxes to one wire. In 
each of these cases, a credential is being transmitted to the BRAS via 
DHCP and the rest of the events that follow are the same. The only 
fundamental difference is where the name is being stored, and whether it 
is being passed as clear text or not.

> Is TR-101 fundamentally based on using DHCP for subscriber authentication? 
TR-101 is based on the scenario I outline above. DHCP plays a very 
significant role. Authentication of the subscriber is certainly 
happening (it has too, or everyone could get service for free), it's 
just via clear text information inserted into DHCP at a point in the 
network that the SP perceives they can trust enough that they don't need 
to use a cryptographic mechanism to guard against hacking. I'm not sure 
that trust is always well-founded, but it is the only basis for the 
information being sent as an option vs. a set of messages.
> is, between hacking DHCP vs using PANA. I'd appreciate if someone can
Start with the outline above, and think about the differences between 
the two options. Know that the opt 82 would continue to exist alongside 
the CPE-auth version, and that it is not a realistic option to remove it 
from the architecture at this stage.

- Mark
>>> reconsider it. Besides, that's the spirit of the thread Jari started.
>>>       
>> This
>>

---

From: "Julien Bournelle" <[email-masked]>
Date: Sat, 20 Oct 2007 12:20:10 +0200

Hi,

> the direct feedback will give them clarity into the request on the

 hmm, so if the majority of SP you know want that IETF standardize what
some technical expert at the IETF considers as a hack, we shall standardize
it ?

 I don't think we shall make the decision based on a SP's poll. The decision
should be done on a technical basis by IETF's experts in that field.

 Regards,

 Julien

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 21 Oct 2007 15:44:13 +0200

On 19-okt-2007, at 22:47, Ralph Droms wrote:

> Subscriber Authentication using DHCP" and the request for the IETF  
> to take on draft-pruss-dhcp-auth-dsl and/or draft-zhao-dhc-user- 
> authentication", I suspect we will need to build a solid case  
> arguing for some other solution in our response to the DSLF.

> can be composed into a solution.

I'm not sure what the normal procedure is in these cases, but it  
seems advantageous to me to make the DSL Forum aware of the content  
of our discussion in the past weeks. Based on that, the DSL Forum may  
decide it's a good idea to explore PANA or 802.1x. Or they may want  
to stick to a DHCP solution, in which case I'm very interested in  
learning their opinion about the difficulties with modifying existing  
DHCP implementations and how to handle IPv6.

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Mon, 22 Oct 2007 11:04:25 +0200

> From: Iljitsch van Beijnum [mailto:[email-masked]] 
> Sent: 21 October 2007 15:44
> To: Ralph Droms (rdroms)
> Cc: Internet Area
> I'm not sure what the normal procedure is in these cases, but 
> it seems advantageous to me to make the DSL Forum aware of 
> the content of our discussion in the past weeks. Based on 
> that, the DSL Forum may decide it's a good idea to explore 
> PANA or 802.1x. Or they may want to stick to a DHCP solution, 
> in which case I'm very interested in learning their opinion 
> about the difficulties with modifying existing DHCP 
> implementations and how to handle IPv6.

Speaking as a DSL Forum participant: Both PANA and 802.1x have been
previously presented at the DSL Forum in the context of TR-101 and
WT-146 work. PANA in particular was presented by one of the framework
draft co-authors. The fact that the DSLF chose to express "serious
interest" in a based DHCP solution says the rest.

-Woj.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 22 Oct 2007 11:09:18 +0200

> interest" in a based DHCP solution says the rest.

Well then, let's hear what the DSL Forum has to say about the issues  
surrounding upgrading existing DHCP implementation in host OSes,  
which, as far as I can tell, can only be done by their vendors (i.e.,  
Microsoft and Apple), and how to address IPv6, both with and without  
IPv4 and with and without DHCPv6.

Iljitsch

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Mon, 22 Oct 2007 11:32:22 +0200

> Sent: 22 October 2007 11:09
> To: Wojciech Dec (wdec)
> Cc: Ralph Droms (rdroms); Internet Area
> Well then, let's hear what the DSL Forum has to say about the 
> issues surrounding upgrading existing DHCP implementation in 
> host OSes, which, as far as I can tell, can only be done by 
> their vendors (i.e., Microsoft and Apple), and how to address 
> IPv6, both with and without

Are you seeking to ask the DSLF to design the protocol or answer on
behalf of Microsoft?
Seriously, I believe that the DSLF has come to the IETF seeking progress
on a solution that conceptually "fits the bill" (ie the requirements)
from the SDO perceived as owning the (DHCP) protocol definition. It
would be rather disingenious for the IETF to seek from the DSLF answers
on how OS specific implementations should be carried out, or specifics
on how protocol should be designed.
Further note: In the DSLF the target devices for incorporating a
subscriber authentication mechanism ones that are provided by the SP (eg
video STB's, DSL Routers), and here the stacks are much more
controllable. PC End hosts, while not not being totally ruled out, are
of secondary importance. That said, AFAIK how a DHCP based solution will
be implemented is still TBD, and so saying that it will require a full
change of stack is premature.

-Woj.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 22 Oct 2007 11:51:52 +0200

> Are you seeking to ask the DSLF to design the protocol or answer on

No, what I want to know is how they expect to deal with the situation  
where a user has a computer that she wants to connect to the service  
and that computer is running (for instance) Windows and the Windows  
DHCP implementation doesn't support the new options. Installing a new  
DHCP client doesn't doesn't seem a workable option here, so what is  
the user expected to do in this situation?

> from the SDO perceived as owning the (DHCP) protocol definition.

So far, what I see is a lot of Cisco people and maybe one or two  
others pushing really hard for this while pretty much everyone else  
sees significant issues. The IETF has also developed a technology for  
exactly this purpose which seems to be rejected out of hand.

So far, nobody has addressed the IPv6 issue. I don't think the IETF  
can go forward with any solution that only works for IPv4.

Please note that DHCP has a long history of vendor extensions. It's  
probably easier for everyone involved to go that route rather than to  
push the IETF to do work that is severely problematic.

I think the DSL Forum should consider the issues that have been  
brought up in this discussion and decide what it wants to do based on  
that. Rough consensus that this is a great idea and the dhc wg should  
go ahead writing a spec doesn't seem to be forthcoming.

> of secondary importance.

Either they are supported or they aren't. There's no middle ground.  
The way I read the requirements, they are supported.

> That said, AFAIK how a DHCP based solution will

The nature of the change is immaterial, the issue is that the DHCP  
client isn't a user serviceable part in a commercial operating system  
so the vendor will have to apply any changes, however minor. This  
tends to take a long time.

---

From: Ralph Droms <[email-masked]>
Date: Mon, 22 Oct 2007 07:23:33 -0400

I exchanged e-mail with Davw Alan (DSLF liaison to IETF) at the end  
of last week about this discussion of the DSLF liaison statement.   
Dave posted a note to the appropriate DSLF mailing list making DSLF  
members aware of the int-area lis discussion and asking them to  
participate and provide DSLF input.

- Ralph

On Oct 21, 2007, at Oct 21, 2007,9:44 AM, Iljitsch van Beijnum wrote:

>> leads to consensus that DHCP is not the right basis for  
>> "subscriber authentication", I suspect we will need to build a  
>> solid case arguing for some other solution in our response to the  
>> DSLF.
>
>> enough information to make a good judgment about whether to adopt  
>> a DHCP-based solution as a work item, or whether some other  
>> standards can be composed into a solution.
>
> of our discussion in the past weeks. Based on that, the DSL Forum  
> may decide it's a good idea to explore PANA or 802.1x. Or they may  
> want to stick to a DHCP solution, in which case I'm very interested  
> in learning their opinion about the difficulties with modifying  
> existing DHCP implementations and how to handle IPv6.

---

From: Ralph Droms <[email-masked]>
Date: Mon, 22 Oct 2007 09:19:08 -0400

Early morning fat-fingering - my e-mail should have read "Dave Allan"...

- Ralph

-----

- Ralph

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 23 Oct 2007 06:40:25 +0300

Wojciech,

> draft co-authors. 

Which presentation are you referring to?

Alper

> The fact that the DSLF chose to express "serious

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 23 Oct 2007 10:36:37 +0300

> send packets via the offered prefix and associated MAC into the network.

Sorry, this just does not explain the term "subscriber line authentication",
if you really meant to use such a term. 

Anyhow, I have few questions. 
- Why does the DSLF think the "line identification" is not sufficient
anymore and they think they need a crypto-based "subscriber authentication?"
- Once they have a subscriber authentication, do they still need the line
identification?  
- If so, how are they planning to use these dual verification schemes?

> information being sent as an option vs. a set of messages.

We understood by now how DSLF uses line identification via DHCP option 82.
If the DSL deployments still need it and want to use it after there is a
proper subscriber authentication mechanism, they can definitely do so. But
otherwise, I don't see use of a subscriber authentication scheme other than
making one out of DHCP causing an impasse of any kind.

> the two options. 

Configure a link-local address on the CPE, run PANA first, than run DHCP.
I'd appreciate if you can explain us the "great deal" part of this.

> Know that the opt 82 would continue to exist alongside

You don't have to remove it just because you are using PANA. You can keep
using it if you think it is necessary even after there is a proper
subscriber authentication used by the network.

Alper

---

From: "Peter Arberg" <[email-masked]>
Date: Tue, 23 Oct 2007 02:11:24 -0700

Hi,

I will like to give a late input to this discussion.

I do believe the DHCP based authentication is a preferred solution
if we believe that per subscriber authentication is needed in a 
DSL broadband network.

BRAS, BNG or NAS equipment, or what we call it, has always 
been optimized towards subscriber bring up rate, and the model with
PPPoE, with what I will call a link negotiation part, a authentication
part and finally a ip-address allocation part has been the model for
optimization for a long time.

The fact that the BRAS/IP Edge equipment in this case do not have
to "distribute" a full subscriber IP state in the BRAS until the
subscriber is okay, is a big advantage to the subscriber bring up rate.

The DHCP authentication model proposed in the "pruss-draft" 
to me is a good suggestion for a IP DHCP authentication of
broadband subscribers, which follows the same idea as PPPoE
today, and will benefit from the optimization aready done 
in BRAS equipments.

How will this work with IPv4 and IPv6 ??  I will expect that
the DHC WG will be able to make sure this is a proposal which 
will make sense also for IPv6 broadband subscribers.

To me the question is not as mush between PANA, 802.1x or DHCP,
it is more about, DHCP option 82 based authentication is used
today, and working, so only in the case where ISP's start placing
the access nodes in non secure locations do a subscriber CPE
authentication make sense, and then in that case what should it be ?

DHCP option 82 authentication when access nodes are in secure
locations and DHCP authentication as proposed in the "pruss-draft"
when a need is to rely on the CPE information for authentication sounds
like the best option to me.

As such I will like to voice the support for DHC WG to take on
this work to investigate if this is a viable solution for both
IPv4 and IPv6 solutions.

thanks,
Peter

> From: Alper Yegin [mailto:[email-masked]] 
> Sent: 23. oktober 2007 00:37
> To: 'Mark Townsley'
> Cc: 'Internet Area'
> Subject: RE: [Int-area] DCHP-based authentication for DSL?
> 
> > >>
> > >> I suppose that depends on the reasons given when they 
> received the
> > news.
> > > identification". And what is needed is "subscriber 
> authentication". The
> > two
> > > As for the "great deal ..." we have yet to understand 
> what the exact
> > delta
> > >>> I'm sure the DSLF would appreciate the feedback and 
> would be willing
> > to
> > >>>>> We are not saying DSLF MUST use PANA. But if DSLF is 
> coming to IETF
> > >>>>> with the
> > >>>>> requirements it did and seeking a L3-based access 
> authentication
> > >>>>> protocol,
> > >>>>> If DSLF is satisfied with a 802.1X extension and IEEE 
> is delivering
> > >>>>> that, so
> > >>>>>>> EAP state transitions) before completion of 
> authentication makes
> > no
> > >>>>>>> successful authentication in PANA, but I don't 
> really think this
> > >>>>>>> is a
> > >>>>>> You still arguing PANA? The difference is that DHCP 
> snooping and
> > >>>>>> Option
> > >>>>>> that changes every device in the Ethernet layer I 
> suspect they
> > >>>>>> probably
> > >>>>>> DHCP Authentication is a small change to the 
> existing deployment
> > that
> > >>>>>> has Port as credentials for Option 82 and simply 
> adds the ability
> > to
> > >>>>>> otherwise uses the same architecture that is 
> deployed today for
> > >>>>>> Option

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 23 Oct 2007 11:30:40 +0200

> will make sense also for IPv6 broadband subscribers.

I don't think it's a good idea to assume that the dhc wg will be able  
to sort this out.

The trouble with DHCP and IPv6 is that DHCPv6 is a completely new  
protocol that runs completely independently from IPv4 DHCP. Adding  
IPv6 information to IPv4 DHCP doesn't make sense for that reason, and  
even if we do it anyway, this means that IPv6-only sites would have  
to run IPv4 DHCP, which would be an extremely ugly hack. On the other  
hand, considering the following, maybe it's the best way to go.

On the other hand, adding equivalent options to DHCPv6 means that the  
vendors will have to do significant work to do DHCPv6 snooping. Also,  
this means that DHCPv6 would be a requirement to subscribe to  
broadband service. That would be ok for the case where the CPE is an  
IPv6 router that obtains an IPv6 prefix through DHCPv6 prefix  
delegation, but NOT in the case where a PC is directly connected to a  
modem/CPE that functions as a bridge.

And there's the whole "not a user-serviceable part" issue. I really  
think we need to make sure there will be a workable end result before  
the dhc wg starts writing a spec.

---

From: "Bill Welch" <[email-masked]>
Date: Tue, 23 Oct 2007 19:55:07 -0400

Peter,

Well stated.  BRAS/BNG equipment is optimized for subscriber brings up
rate as 10s of thousands and maybe hundred of thousands of subscribers
are terminated on the BRAS/BNG.  

Having a solution that assigns a temporary address or uses a link local
address complicates the implementation and does not mirror the existing
PPPoE solution.

The details of an IPv6 solution need to be worked out but I think this
is a good start.

Best regards,
Bill Welch

-----Original Message-----
From: Peter Arberg [mailto:[email-masked]] 
Sent: Tuesday, October 23, 2007 5:11 AM
To: 'Alper Yegin'; 'Mark Townsley'
Cc: 'Internet Area'
Subject: RE: [Int-area] DCHP-based authentication for DSL?

Hi,

thanks,
Peter

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 24 Oct 2007 04:08:23 +0300

I think we need to understand this a bit better, as now we are talking about
implementation optimizations.

> subscriber is okay, is a big advantage to the subscriber bring up rate.

How is the situation different if you were using PANA? 

> address complicates the implementation and does not mirror the existing

Can you please expand on the complication part? Please note that the IP
address configured prior to subscriber authentication is not the "service IP
address". 

Also, even with DHCPv6, the client is already configured with a link-local
IPv6 address prior to sending the very first DHCPv6 message. 

Alper

---

From: "Bill Welch" <[email-masked]>
Date: Wed, 24 Oct 2007 16:24:03 -0400

Alper,

It's just a matter of resource management and managing state on the
BRAS/BNG.

With PPPoE you have the following steps:
Authentication
Resource assignment (Address, QoS, filters)

With PANA you have the following:
Temp resource assignment (Address, QoS, filters)
Authentication
Removal of temp resources (Address, QoS, filters)
Service resource assignment (Address, QoS, filters)

The Addresses, Qos and filters will not be the same for temp resource
assignment and Service resource assignment.

Every login is four step process vs. a two step process and you have to
manage some type of token or identifier between the authentication and
service resource assignment.

Best regards,
Bill Welch

-----Original Message-----
From: Alper Yegin [mailto:[email-masked]] 
Sent: Tuesday, October 23, 2007 9:08 PM
To: [email-masked]; Bill Welch
Cc: 'Internet Area'
Subject: RE: [Int-area] DCHP-based authentication for DSL?

I think we need to understand this a bit better, as now we are talking
about
implementation optimizations.

Can you please expand on the complication part? Please note that the IP
address configured prior to subscriber authentication is not the
"service IP
address". 

Also, even with DHCPv6, the client is already configured with a
link-local
IPv6 address prior to sending the very first DHCPv6 message. 

Alper

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 24 Oct 2007 23:12:35 +0200

Nobody says that you have to apply QoS treatment and filters to the 
temporarily assigned address.

Bill Welch wrote:
>> subscriber is okay, is a big advantage to the subscriber bring up
>>     
> rate.
>
>> Having a solution that assigns a temporary address or uses a link
>>     
> local
>   
>> address complicates the implementation and does not mirror the
>>     
> existing
>   
>> PPPoE solution.
>>     
>

---

From: Ralph Droms <[email-masked]>
Date: Wed, 24 Oct 2007 17:13:30 -0400

I think this sort of detailed analysis goes beyond what we can talk  
about without a more detailed description of the deployment scenarios.

For example, I can imagine doing the address assignment with PANA in  
a way that uses static QoS and filters on an address pool from which  
all temporary address assignments are made.  In that case, the PANA  
sequence might be:

Temp address assignment
Authentication
Service resource assignment

with no impact on the BRAS state maintenance, and a doubling of  
impact on the DHCP server (which might be in the BRAS).

But I'm speculating wildly here without explicit text to discuss.  It  
might not even be necessary to use temporary address assignment if  
address assignment can take place prior to authentication, with  
denial of access and/or revocation if authentication fails.

- Ralph

---

From: Richard Pruss <[email-masked]>
Date: Thu, 25 Oct 2007 07:45:47 +1000

Funny I thought you would have more QoS and filter treatment for 
temporary unsecured unknown users than normal operation.

Hannes Tschofenig wrote, around 25/10/07 7:12 AM:
>> From: Alper Yegin [mailto:[email-masked]] Sent: Tuesday, 
>> October 23, 2007 9:08 PM

---

From: "Bill Welch" <[email-masked]>
Date: Wed, 24 Oct 2007 17:39:33 -0400

Service provider experience has proven this to be true with Security
issues and Distributed DOS attacks.

Best regards,
Bill Welch

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 24 Oct 2007 23:47:10 +0200

I don't believe this without further details.

Bill Welch wrote:
>> Every login is four step process vs. a two step process and you have
>>     
> to
>   
>> Can you please expand on the complication part? Please note that the
>>     
> IP
>

---

From: Richard Pruss <[email-masked]>
Date: Thu, 25 Oct 2007 07:54:27 +1000

Did the liaison not come with the architecture documents and the living 
list for all this?  I really do not think the whole architecture belongs 
in the draft.

I think to implement the static assignment you are talking about you 
would have to manage the migration of a session to and from a routing 
context protected for this temporary address space, which actually 
probably has as many state implications than the QoS and filter one.

- Ric

Ralph Droms wrote, around 25/10/07 7:13 AM:
> For example, I can imagine doing the address assignment with PANA in a 
> way that uses static QoS and filters on an address pool from which all 
> temporary address assignments are made.  In that case, the PANA 
> sequence might be:
>
> Temp address assignment
> Authentication
> with no impact on the BRAS state maintenance, and a doubling of impact 
> on the DHCP server (which might be in the BRAS).
>
> address assignment can take place prior to authentication, with denial 
> of access and/or revocation if authentication fails.
>
> - Ralph
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 24 Oct 2007 23:55:35 +0200

One would get the QoS parameter via the AAA infrastructure and then they 
are combined with the identifiers describing the direction of the 
traffic and other classification parameters. The QoS rules are activated 
when the final IP address is available.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 24 Oct 2007 17:53:33 -0400

> denial of access and/or revocation if authentication fails.

Yes, that is also possible.  A service address can be assigned for
unauthenticated clients, but with a shorter lifetime (e.g., 60-sec)
than that for authenticated ones.  After successful authentication,
the lifetime can be extended by DHCP renew.

Yoshihiro Ohba

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 25 Oct 2007 11:38:59 +0200

On 24-okt-2007, at 23:13, Ralph Droms wrote:

> For example, I can imagine doing the address assignment with PANA  
> in a way that uses static QoS and filters on an address pool from  
> which all temporary address assignments are made.

Right. Another option that I suggested earlier would be to do this  
using IPv6 link-local addresses. I'm not sure how much work it would  
be to snoop those, and possibly add a 82-like option to them.

A different approach would be to see if PANA can be run using  
multicast addresses etc the same way DHCP does. This is probably  
easiest for intermediate snoopers but it's sure to require some  
massaging of the PANA spec.

Iljitsch

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 29 Oct 2007 00:45:23 +0200

Bill,

Thank you for your response. Sorry about the latency of mine. 

> With PANA you have the following:
1.> Temp resource assignment (Address, QoS, filters)
2.> Authentication
3.> Removal of temp resources (Address, QoS, filters)
4.> Service resource assignment (Address, QoS, filters)

Regarding step 1:

As other folks have said, some preconfigured QoS and filters can be applied
to the PANA exchange. 

And the same needs to be done even if you were using EAP/DHCP. The DHCP
packets need to be exposed to some QoS and filter rules prior to successful
authentication. 

Regarding step 3:

If we apply preconfigured rules to pre-auth traffic (e.g., allow only PANA
with QoS ....), not sure if you need to remove anything.

> assignment and Service resource assignment.

Right.

> service resource assignment.

If you are talking about what identifier can tie PANA authentication to DHCP
configuration, that can be either the MAC address or the IP address. 

Alper

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 29 Oct 2007 01:38:30 +0200

> WT-146 work. PANA in particular was presented by one of the framework

I still didn't get a pointer to which presentation you are referring to.
Nevertheless, see below...

> interest" in a based DHCP solution says the rest.

Saying that would be rushing the DSLF to a particular decision.

Note that, there is no PANA representation in DSLF. What's been done so far
does not go beyond few informational presentations by the visitors (once I
gave one). On the other hand, the owner of DHCP solution has a very strong
presence in the DSLF.  

So it is no surprise that one solution went neglected when the other one
received the whole positive attention. Misunderstandings about PANA that we
found out during these latest (online and offline) IETF discussions are a
good proof of that. And so are the problems we found about the DHCP-based
solution.

I don't know how DSLF progressed from "requirements stage" (previous contact
with IETF) to "serious interest in one solution stage".

Alper

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Mon, 29 Oct 2007 09:13:26 +0100

> Sent: 29 October 2007 00:39
> To: Wojciech Dec (wdec); 'Iljitsch van Beijnum'; Ralph Droms (rdroms)
> Cc: 'Internet Area'

Sorry. I've set-up a dedicated filter for this mother-of-all-threads, so
it must have hijacked your mail somewhere...

> Nevertheless, see below...

Well, here's the list, along with the dates they were submitted on and
authors:

dsl2006.607.00 	Evaluation of IP Subscriber Authentication Mechanisms
09/12/2006 Alessandro Capurso, Alper Yegin, John Kaippallimalil, Lionel
Morand, Subir Das
dsl2006.387.00 	IP Subscriber and Session Authentication (for WT-146)
05/02/2006 Prakash Jayaraman, Alper Yegin
dsl2005.120.00 	AAA Protocols for WT-101 Architecture 03/03/2005
Jayaraman, Prakash
dsl2003.409.00 	IETF PANA overview 11/04/2003 Bathrick, Gregory

> 
> > The fact that the DSLF chose to express "serious interest" 
> in a based 
> > DHCP solution says the rest.
> 
> Note that, there is no PANA representation in DSLF. What's 
> been done so far does not go beyond few informational 
> presentations by the visitors (once I gave one). On the other 
> hand, the owner of DHCP solution has a very strong presence 
> in the DSLF.  

This is of course a bogus statement. The following list
http://www.dslforum.org/about/members.php shows the current DSLF member
list, which also includes  employers of what one may assume to be the
"PANA delegation". Now when being a DSLF member whether one chooses to
participate in DSLF meetings and proceedings is another matter, which I
gather the PANA delegation chose not to. That's a poor excuse though.

> 
> So it is no surprise that one solution went neglected when 
> the other one received the whole positive attention. 
> Misunderstandings about PANA that we found out during these 
> latest (online and offline) IETF discussions are a good proof 
> of that. And so are the problems we found about the 
> DHCP-based solution.

Well, so the time spent on the 4 contributions above wasn't well spent
since despite these numerous informational presentations folks still
"misunderstand PANA". Or is it that perhaps they don't see such a clear
justification for it?

BTW, if the discussion in the IETF community itself shows a
misunderstanding of PANA, then one should really be concerned if it ever
will be understood. At least the DHCP-based solution doesn't seem to be
failing on that front, perhaps because it's not trying to be all things
to all people. 

> 
> I don't know how DSLF progressed from "requirements stage" 
> (previous contact with IETF) to "serious interest in one 
> solution stage".

Speaking as a participant in the DSLF I can say that all of the
candidate mechanism have been presented previously (and in some cases
repeatedly so too) but no progress has been made in adopting one nor in
obtaining liaison replies from other SDOs to their previous requests.
Hence the DSLF chose to express it's "serious interest" more clearly.

-Woj.

---

From: "Bill Welch" <[email-masked]>
Date: Mon, 29 Oct 2007 12:09:38 -0400

Alper,

We are starting to get into specific QoS and filter implementations.

But BRAS/BNG has limits on the amount and type of QOS and filter
resources available.  We strive to support the same number of
subscribers with DHCP as we do with PPP.  It will be difficult to reach
this goal if the authentication models are different between PPP and
DHCP.

Pre configured or dynamic the QOS and filter resources will get used.

And yes your observation is correct, the DHCP auth solution with EAP has
the same issues.

Best regards,
Bill Welch

-----Original Message-----
From: Alper Yegin [mailto:[email-masked]] 
Sent: Sunday, October 28, 2007 6:45 PM
To: Bill Welch; [email-masked]
Cc: 'Internet Area'
Subject: RE: [Int-area] DCHP-based authentication for DSL?

Bill,

Regarding step 1:

As other folks have said, some preconfigured QoS and filters can be
applied
to the PANA exchange. 

And the same needs to be done even if you were using EAP/DHCP. The DHCP
packets need to be exposed to some QoS and filter rules prior to
successful
authentication. 

Regarding step 3:

If we apply preconfigured rules to pre-auth traffic (e.g., allow only
PANA
with QoS ....), not sure if you need to remove anything.

Right.

to
> service resource assignment.

If you are talking about what identifier can tie PANA authentication to
DHCP
configuration, that can be either the MAC address or the IP address. 

Alper

IP

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 30 Oct 2007 12:52:29 +0200

> gather the PANA delegation chose not to. That's a poor excuse though.

Since people here in IETF are surprised how IETF's own solution has not
received adequate attention and how a hacky solution like EAP/DHCP made it
to the liaison letter, I'm giving the background. 

> "misunderstand PANA". Or is it that perhaps they don't see such a clear

None of the above. I can add few other "perhaps" but no need to stray from a
technical discussion here.

> failing on that front, perhaps because it's not trying to be all things

I was referring to the misunderstanding of the DSLF people, not IETF (e.g.,
how use of PANA means DHCP Option 82 needs to be deprecated, how PANA fails
IPAuth-14, how PANA is at an disadvantage compared to EAP/DHCP when
implementation optimizations are considered, etc.... none of which turned
out to be true). 

> Hence the DSLF chose to express it's "serious interest" more clearly.

Can you point to some meeting minutes or other material where EAP/DHCP was
evaluated against the other solutions and got into the liaison letter? That
background would help IETF to understand if EAP/DHCP is justified, at all...

Alper

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Wed, 31 Oct 2007 11:28:04 +0100

> > > (previous contact with IETF) to "serious interest in one solution 
> > > stage".
> > 
> > repeatedly so too) but no progress has been made in 
> adopting one nor 
> > in obtaining liaison replies from other SDOs to their 
> previous requests.
> Can you point to some meeting minutes or other material where 
> EAP/DHCP was evaluated against the other solutions and got 
> into the liaison letter? That background would help IETF to 
> understand if EAP/DHCP is justified, at all...

Am afraid that the meeting minutes are published/accessible to DSLF
members, and it's not within my authority to circulate them - I guess it
would require a decision by the DSLF to do so. That said, the DSLF has
issued previous liaison statements to the IETF on the topic on more than
one occasion...

-Woj.