I don't understand why this dhcp-based access authentication proposal is getting a 4th chance...
It was already discussed 3 times in the past and strongly rejected. First time when Huawei proposal was discussed in DHC ML: http://www1.ietf.org/mail-archive/web/dhcwg/current/msg06599.html http://www1.ietf.org/mail-archive/web/dhcwg/current/msg06594.html Second time when Cisco version was discussed in DHC ML: http://www1.ietf.org/mail-archive/web/dhcwg/current/msg07141.html Third time when the discussion was initiated in INT-area ML: http://www1.ietf.org/mail-archive/web/int-area/current/msg00735.html http://www1.ietf.org/mail-archive/web/int-area/current/msg00736.html http://www1.ietf.org/mail-archive/web/int-area/current/msg00751.html http://www1.ietf.org/mail-archive/web/int-area/current/msg00749.html [I've intentionally excluded the feedback of PANA supporters. Obviously there are few of those in addition to the above list of people.] On top of that, there is an IAB document that speaks against such a hack: 2.5. Configuration is Not Access Control Network access authentication is a distinct problem from Internet host configuration. Network access authentication is best handled independently of the configuration mechanisms in use for the Internet and higher layers. IETF community has spoken in many forms. Not sure why we are still considering such a proposal. Alper > -----Original Message----- > From: Mark Townsley [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 09, 2007 1:13 AM > To: Jari Arkko > Cc: James Kempf; Internet Area > Subject: Re: [Int-area] DCHP-based authentication for DSL? > > Jari Arkko wrote: > > James, > > > > > >> I will venture a guess here: they don't want to deploy a new protocol. > >> > > > > It would be good to get the exact details from Ric or Mark or whoever > > knows them. But my understanding is that their desires relate to > > the following: > > > Good summary, Jari, I only have a bit more to add. > > [In the interest of disclosure, I am fairly active in the DSL Forum, and > have been working in an advisory role with Ric and others on DHCP auth. > Suffice to say, I'm already fairly convinced that something like this is > necessary, or at least inevitable, given what I know about current DSL > deployments and trends. So, with individual contributor hat firmly in > hand....] > > - Moving away from a user/password authentication that the > > PPPoE users had would require changes in the business > > processes, e.g., relying on line ID only. > > > Another part of the process is that the authentication stage needs to > happen before an IP address is assigned, and ACLs installed throughout > the network (by snooping the DHCP packets in transit) to allow packets > to/from that IP address to be sent and received. > > And it would be a good thing to be able to move around with > > your subscription. Assuming of course that the lower layers > > in the DSL system are capable of allowing that without > > some configuration. > In addition, is the requirement to support more than one device > (typically a Set-Top-Box) over a single subscriber line in "bridged" > mode between the STB and the BRAS. In the latter case, both line-id > credentials inserted by the DSLAM and credentials from the DHCP client > are used. > > There is also the case where, due to the nature of the way the network > is operated and other circumstances, relying on the line id in the DSLAM > is not possible. > > (And of course, its also a Good Thing to move away from > > PPPoE... we should support that.) > > > > - Moving away from AAA-based authentication would imply > > changes in how subscriber data is managed and served. > > > > - DSLAMs are already looking at DHCP packets and filtering > > them appropriately. A new protocol would require changes > > in DSLAMs. > > > > - 802.1x runs between a port and a switch, I think this means > > that in the DSL world this would translate into a requirement > > for the DSLAM rather than the BRAS performing the > > authentication. > > > The above two points center around the need for the authentication > protocol to operate over networks which may be ATM, Ethernet, a > combination of the two, have one or more DSLAMs and agg switches, etc. > DSL networks around the world have a variety of different architectures > at L2 and below. > > - Practical implementations on the BRAS side currently do > > the option 82 processing in the DHCP code, so new processing > > steps for related purposes are convenient to have in the > > same part of the code. > > > Use-cases require information which is currently presented to the BRAS > in the DHCP Discover, indicating a need for tight coupling with DHCP, > regardless of the packaging. > > - Mark > > The different reasons have a different nature. The first two > > items do not imply that a DHCP-based solution is needed, just > > that some AAA-based approach is. Last item is more about > > convenience than anything else. Not sure what would be > > involved in the third and fourth items. > > > > Jari > > > > > > > > _______________________________________________ > > 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
