> >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.
More fundamentally, when there are multiple gateways (for any redundancy/failover/etc reason), pure IKEv2 solution requires multiple EAP runs to get authorized for accessing "one" network. This does not work well with the AAA backend deployments (which defaults to one authentication per network access). And it did not make any sense to augment IKEv2 (let alone not being able to use IKEv1) to meet the PANA requirements, and then force everyone to use it even though they are not interested in IPsec SAs. This was discussed in the PANA WG long time ago. But for people who are not following the work and trying a last minute "how about this now?" this might appear like an original idea. Alper _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf