I would like to know if PANA snooping is much more difficult than DHCP snooping. Also, aren't those switches already doing filtering at the IP layer protocol by looking at the IP header in order to check if the received MAC frame carrying the IP packet matches the installed filters for binding the MAC address and the service IP address?
Yoshihiro Ohba On Fri, Oct 12, 2007 at 06:48:07AM +1000, Richard Pruss wrote: > > > Yoshihiro Ohba wrote, around 12/10/07 5:50 AM: > > I don't understand why "reinstalling filters" is needed here. The > > sequence I am thinking is as follows: In the initial state (i.e., > > before PANA authentication), filters are open for DHCP and PANA only. > > After PANA authentication, filters for binding the MAC address and > > service IP address as well as routes are installed and another DHCP > > delivers the service IP address to the client. > > > That would require PANA snooping on every switch that does Option 82 > insertion and DHCP snooping today. > It would also require a suite of new features on those switches to > filter at the IP layer protocol. Current switches do MAC IP matching and > security features around those two on a per port basis. > This is where the PANA proposal breaks down as it requires every element > in the network to change. > > - Ric > > > > Yoshihiro Ohba > > > > On Thu, Oct 11, 2007 at 08:32:15PM +0200, Mark Townsley wrote: > > > >> Stig Venaas wrote: > >> > >>> Eric Voit (evoit) wrote: > >>> > >>> > >>>> Two of the reasons the DSLF is asking for DHCP Auth to be considered by > >>>> the IETF are that: > >>>> > >>>> (1) PANA does not meet IPAuth-14 "Must allow for authentication and > >>>> download of subscriber service profile before service IP address is > >>>> assigned." IPAuth14 is from the earlier DSLF liaison document to which > >>>> Mark referred. > >>>> > >>>> > >>> It says service IP address. I suppose you could possibly get an initial > >>> IP address that allows you to do PANA but not much else, and then after > >>> you are authenticated you would get the service IP address? > >>> > >>> > >> Possibly. But, remember that the auth step in DHCP is mostly rounding > >> out use cases for the operational model that is already in place for DSL > >> without PPP. The current model uses Option 82 inserted in the DHCP > >> Discover message transiting the network to authenticate the subscriber > >> line before IP addresses are assigned, routes installed, and filters > >> opened up (binding a MAC address to an IP address) along the path > >> between the home and the BRAS. Auth in DHCP allows additional > >> credentials from equipment on the residential side of the subscriber > >> line to be used by AAA, rather than relying on credentials inserted by > >> the DSLAM alone. Allowing an IP address to be assigned, opening filters > >> specifically for PANA/EAP alone (as well as inserting the same option 82 > >> information into PANA during transit, as this will certainly come next > >> for cases where RG+DSLAM credentials are necessary at the same time) > >> then changing that IP address on the fly, reinstalling filters, etc, is > >> a rather significant change in the currently deployed behavior for not a > >> lot of gain from the provider's perspective. > >> > >> - Mark > >> > >>> Stig > >>> > >>> > >>> _______________________________________________ > >>> 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
