Alper Yegin wrote:
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,
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.
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.
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.
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.
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.
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
Alper
- Mark
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
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
