Vidya, Administratively scoped multicast is not the only way for PAA discovery. DHCP based PAA discovery is also available: draft-ietf-dhc-paa-option-02.txt Regards, Yoshihiro Ohba On Fri, May 26, 2006 at 04:34:22PM -0700, Narayanan, Vidya wrote: > Hi Jari, > > > > > Hi Vidya, > > > > >>Re 1: I do believe an IP layer solution in this space is > > potentially > > >>useful. Not as something that replaces existing link layer > > solutions > > >>and takes over the market, but there are situations where > > it would be > > >>useful, for instance over link layers that have no such > > support, as a > > >>solution for networks where you just want to add a node in > > the middle > > >>of the access network without updating all access points > > (kind of like > > >>a replacement for weblogin but without the need for user > > >>intervention), etc. > > >> > > >> > > >> > > > > > >I am trying to figure out the use case for an IP layer > > solution in this > > >space as an access authentication protocol and I am not > > convinced that > > >we need something like PANA. If you are in fact, adding a > > node in the > > >middle of the access network that is going to perform access > > control, > > >is it just performing authentication or also attempting to > > derive keys > > >and secure the data traffic? With a solution like PANA, a link layer > > >secure association protocol or IPsec needs to be run to secure data > > >traffic. If the former, the authenticator (or at least the > > EP) needs to > > >be located at the edge. This needs support at the link layer anyway, > > >and all such link layers already support EAP. > > > > > >If the latter, the most natural solution to use is IKEv2 with EAP, > > >since even with PANA, you still need to run IKE/IKEv2 and > > IPsec - so, I > > >don't see what benefit PANA provides here. > > > > > > > > My comment above relates to the overall interest in an IP > > layer solution without considering what protocol is used. > > > > I also wrote in my e-mail something about the different > > alternative solutions. It is true that IKEv2 with EAP is > > potentially a good fit for this task. IKEv2 is my favorite > > EAP encapsulation protocol :-) However, its not clear that it > > currently has all the parts (though I could have missed some > > extension somewhere). > > For instance, some mechanism appears to be needed to discover > > that you are in a network that requires this type of > > operation, and to find the address of the control device that > > you need to talk to. I haven't done the research on how easy > > it would be to add this (probably quite easy) or if there are > > other things that we would need. Thoughts? > > > > Let me separate out two issues here. In order to discover that you are > in a network that requires this type of operation, you need to know via > some kind of advertisements (SSID, for instance) that you are not in the > home network. For instance, VPN connections today are mostly user > initiated. > > Another issue that you mention here is the discovery of the address of > the control device - this is typically done via DNS today. > > Thinking further about the PAA discovery mechanisms outlined in the PANA > protocol, it seems to bring some deployment concerns. Administratively > scoped multicast is one of the advocated methods of performing PAA > discovery. Administrative scoping of multicast is a huge administrative > burden and is not a good deployment option. Protocols like DVMRP allow > TTL scoping which are somewhat better. But, the thought of opening up > port control to allow multicast packets into the network prior to > authentication is not appealing to me. > > Another option that PANA provides for PAA discovery is traffic-driven > discovery. This is somewhat similar to what EAP relies on - i.e., the > network figures out that it needs to send an EAP Request Identity (in > the absence of an EAPoL-Start like message). > > In short, discovery hardly seems to be a reason to use PANA to me - I'm > trying to at least taste the kool-aid, even if I can't drink it all, but > somehow, am yet finding a convincing reason why I should :) > > Vidya > > > > Anyway, I agree with Dave Crocker that the bar should be > > higher for using "there's another solution" argument in last > > call discussion of chartered work than in, say, a BOF > > discussion. Perhaps we should focus more on whether the > > function itself is something that we agree on, and what we > > can do to fix/scope/help PANA. > > > > --Jari > > > > > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf > > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf