Re: RE: issue 34 -- ESP vs. IKE based NAT reboot detection

 > >Sorry if this was discussed at the meeting. I did not understand a couple of things in this mail
> >
> >1) You mention implementation complexity. I saw some reference to it in the slides if i am not
> >     mistaken. Also, Jari mentioned something in his mail. Is this general "complexity" of MOBIKE ?
> >     or something specific to this feature i.e NAT traversal ? Having implemented NAT traversal,
> >     i don't know how it can be considered complex considering the complexity of IKEv2 itself :-)
> >     So, i am missing something..
> >  
> >
> I guess the main complexity that people were worried about
> is that the *ipsec* part needs to detect a changed address
> and tell this to the IKE part. This may involve a PFKEY extension,
> among other things, 
>
Linux (2.6) uses netlink sockets for this purpose. The hook is there and the
event does not get generated from IPsec to IKE. But it is trivial to implement.
So, if some one wants to cook up a PF_KEY extension, they can do so
and it should not be a problem. If someone feels that this functionality is needed,
i don't think this is hard to implement. Perhaps, the real reason is nobody
needs it and hence it does not seem to be there. So, i don't agree that this
is complex.

> and may be hard on a hardware that
> does IPsec but does not have this address detection function.
> 
Ok. Again, i am not sure whether the reason it does not exist in hardware today
is because there is a lack of need for it or it is difficult to do it in hardware ?
As VPN gateway most likely will use hardware acceleration and as this
feature does not seem to be present in the hardware, would it not make
sense to use alt.3 ? Note that we can't help with the current IKEv2 NAT
traversal. At least  there is some *reason* (complexity, no hardware support,
 security etc.) why it does not exist today. Perhaps, we can make this work
with MOBIKE if we don't rely on the IKEv2 NAT traversal mechanism.

-mohan



> --Jari
> 
>