Subject: Re: [Pana] DSLF Requirement analysis

From: Richard Pruss <[email-masked]>
Date: Wed, 05 Dec 2007 19:14:58 -0800

>
> In the spirit of analyzing the DSLF's Subscriber Authentication Requirements
> as presented through a liaison letter on May 25, 2007, we discussed the
> following material during IETF 70 PANA WG meeting.
>
> http://www3.ietf.org/proceedings/07dec/slides/pana-3.ppt
>
> We have reached consensus among the PANA WG members present in the room. In
> order to make this an official WG consensus, we are running this by the WG
> via mailing list.
>
> If you have any feedback, please send an e-mail on the mailing list by
> December 11, 2007 Tuesday 6pm PT. 
>
> If there is no objection, IETF PANA WG will send a liaison letter to DSLF
> based on this consensus.
>   
> - IETF PANA WG Chairs 
>   
I strongly disagree. PANA is not suitable to DSLForum requirements.  
Other protocols in the IETF and IEEE are far better candidates.  Taking 
this work in the PANA WG is a totally wrong conclusion that somehow PANA 
is the correct framework for solving a layer 2 authentication problem!

Put you hammer back in the drawer,  not every problem is a nail you need 
to hit with it.

- Ric

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 6 Dec 2007 05:28:34 +0200

Ric,

> I strongly disagree. PANA is not suitable to DSLForum requirements.

Could you please be specific?

> is the correct framework for solving a layer 2 authentication problem!

Unfortunately since you are the one calling this a "layer 2 authentication
problem", could you please explain what exactly you mean by that and how
"DHCP" is solving that "L2 auth" problem, and how DSLF requirements
"IPAuth-10	Must be independent of medium type (eg Fixed Ethernet,
Legacy ATM, PON, WiFi, WiMax, etc)" plays into that? 

> Put you hammer back in the drawer,  not every problem is a nail you need

That's a misconception I've been hearing from you, but in case you haven't
noticed, this WG was created exactly for this problem space, even to the
extent that we mentioned it in our RFC 4058

   DSL networks are a specific example where PANA has the potential for
   addressing some of the deployment scenarios.  Some DSL deployments do
   not use PPP [RFC1661] as the access link-layer (IP is carried over
   ATM and the subscriber device is either statically or DHCP-
   configured).  The operators of these networks are left either using
   an application-layer web-based login (captive portal) scheme for
   subscriber authentication, or providing a best-effort service only as
   they cannot perform subscriber authentication required for the
   differentiated services.  The captive portal scheme is a non-standard
   solution that has various limitations and security flaws.

Alper

---

From: Subir Das <[email-masked]>
Date: Thu, 06 Dec 2007 11:03:20 -0500

It would be nice if someone can explain what's wrong with the conclusion.
Also if it is a layer-2 authentication problem, I do not know whether it
fits in IETF. On the other hand,  DSLF requirements do not not seem to
indicate that it is a layer-2 auth problem.

regards,
-Subir

Richard Pruss wrote:
> Other protocols in the IETF and IEEE are far better candidates.  
> Taking this work in the PANA WG is a totally wrong conclusion that 
> somehow PANA is the correct framework for solving a layer 2 
> authentication problem!
>
> Put you hammer back in the drawer,  not every problem is a nail you 
> need to hit with it.
>
> - Ric
>

---

From: Mark Townsley <[email-masked]>
Date: Thu, 06 Dec 2007 08:40:17 -0800

Subir Das wrote:
> fits in IETF. 
If the DSLF wants an 802 based solution, this is certainly an IEEE 
problem. But DHCP would of course be IETF.

When we speak about layers in the conventional sense, we think of 
something that operates in a steady state on top of one another in a 
vertical stack. Authentication occurs during a setup phase, thus the 
point in time in which that operation occurs relative to other items 
becomes significant, bringing another dimension to the problem. If you 
can think of steady-state layers vertically, think of the authentication 
phase as horizontally, where time is as important as layer.

> On the other hand,  DSLF requirements do not not seem to
I think that this is captured as part of the "TR-101 operational model" 
- I understand that is a lot to try and digest. But I think what Ric has 
been saying is important is that the point in time that IP packets can 
flow on the network from a given subscriber is significant to the 
security model in DSL.

- Mark

---

From: Subir Das <[email-masked]>
Date: Thu, 06 Dec 2007 12:07:27 -0500

> problem. But DHCP would of course be IETF.
    Yes that's  true. But can we call DHCP a layer-2 auth? I understand 
that we may not need to use the strict layering model
     here, but typically L2-auth does not  allow the link access before 
authentication. For DHCP case, it's different.since
     DHCP DISCOVER has a source address 0.0.0.0 and one can argue that  
the node is capable of sending IP packets.
> can think of steady-state layers vertically, think of the 
> authentication phase as horizontally, where time is as important as 
> layer.
>
> I think that this is captured as part of the "TR-101 operational 
> model" - I understand that is a lot to try and digest. But I think 
> what Ric has been saying is important is that the point in time that 
> IP packets can flow on the network from a given subscriber is 
> significant to the security model in DSL.
     Yes, the security model is an important issue. Whether DSLF chooses 
to use DHCP or some other IETF protocols, IMO, this is a new 
architecture model
     that traditional  L2 -auth model provides today. Of course, it has 
to be secured whatever protocol we recommend.

     regards,

    -Subir