Mark Townsley wrote:
Subir Das wrote:
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.
If the DSLF wants an 802 based solution, this is certainly an IEEE
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.
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
indicate that it is a layer-2 auth problem.
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
- Mark
regards,
-Subir
Richard Pruss wrote:
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 protected]
https://www1.ietf.org/mailman/listinfo/pana
_______________________________________________
Pana mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pana
_______________________________________________
Pana mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pana
