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
On Oct 19, 2007, at Oct 19, 2007,3:14 PM, Alper Yegin wrote:
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
-----Original Message-----
From: Ralph Droms [mailto:[EMAIL PROTECTED]
Sent: Friday, October 19, 2007 4:27 PM
To: Alper Yegin
Cc: Internet Area
Subject: Re: [Int-area] DCHP-based authentication for DSL?
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:
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
-----Original Message-----
From: Richard Pruss [mailto:[EMAIL PROTECTED]
Sent: Friday, October 19, 2007 6:01 AM
To: Yoshihiro Ohba
Cc: Internet Area
Subject: Re: [Int-area] DCHP-based authentication for DSL?
Yoshihiro Ohba wrote, around 19/10/07 11:39 AM:
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.
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
Yoshihiro Ohba
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
