EAP/IKEv2 as an alternative to PANA (RE: The Emperor Has No Clothes: Is PANA actually useful?)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]