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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf