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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf