Alper Yegin writes: > > Some of the key issues to keep in mind here are: > > > > 1) Is the logical link point-to-point, or is it shared among multiple > > devices of the same subscriber, or is it shared among multiple > > subscribers? > > Requirement IPAuth-18 and WT-146 implies that all three are legal > > models. > > According to my understanding, the architecture is intended to be capable > of > identifying the data traffic of an authenticated client, and enforcing a > policy on it. This relies on network element placement, of course.
I don't see how your response above is relevant to issue #1, which is the link model. > > 2) Is the problem about authenticating access to the local link, or > > about authenticating access to the network behind the L3 edge device? > > I think it is both. If it is both, and the link is capable of carrying non-IP traffic (like Ethernet is), then a L3 solution would be particularly inappropriate. -Dave > I'm not aware of a case where clients are authorized > to > send/receive IP traffic with the others connected to the same DSLAM/BRAS, > but not with the ones on the Internet. > > Alper > > > > > There's no significant difference in the point-to-point link case, but > > in the other two models, the difference becomes very significant. So > > for example, for subscriber-to-subscriber communication where > > subscribers are on the same shared media, do you care about restricting > > access between them? If so, then L3 is the wrong place to solve the > > problem, and the whole notion of IP Sessions is suspect for this > > particular problem. Indeed, the requirement would be for a > > network-layer-protocol-independent solution. Basically you would want a > > mechanism which is L2-independent as well as L3-independent. > > > > 3) Since power management is an important issue for many hosts, and > > there can be (per WT-146) hosts on the link, it is important to not > > constantly ping hosts with packets that can result in the host coming > > out of a low power state, as this can drastically increase the power > > costs (either in electric bill, or battery life) to consumers. Hence > > page 17 of WT-146 can be scary to many people. > > > > -Dave > > > > > -----Original Message----- > > > From: Jari Arkko [mailto:[EMAIL PROTECTED] > > > Sent: Tuesday, July 24, 2007 2:35 PM > > > To: Internet Area > > > Cc: Dhc Chairs > > > Subject: [Int-area] DSL forum liaison statement on subscriber > > > authentication > > > > > > This relates to the earlier discussion on using DHCP or something > > > else for subscriber authentication and/or network access control. > > > > > > We have received a liaison statement from the DSL forum. > > > Please see > > > > > > https://datatracker.ietf.org/documents/LIAISON/file457.doc > > > https://datatracker.ietf.org/documents/LIAISON/file458.doc > > > http://www.dslforum.org/techwork/tr/TR-101.pdf > > > http://www.arkko.com/ietf/intarea/dsl2006.887.03.doc > > > > > > Comments on these requirements and potential approaches > > > to satisfying them would be appreciated. > > > > > > Jari > > > > > > P.S. The last two items have been missed in the IETF liaison > > > site; I'm working to get them up there. > > > > > > > > > > > > _______________________________________________ > > > 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
