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 > > > > -----Original Message----- > > From: Alper Yegin [mailto:[EMAIL PROTECTED] > > 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. > > > >> 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. > > > > 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? > > > > > 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. > > > > 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. > > > > > > > > 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. > > > > 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 > > > the CPE-auth version, and that it is not a realistic option > > to remove it > > > from the architecture at this stage. > > > > 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 > > > > > > > > > > - 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 > > > _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
