[support] IKE (v2) and IPsec implementation in a NEPL context

[Sebastien Decugis]

Hi,

> 	Before I make some comments inline, let me try and clarify the
> following. Why do we need to modify both nepl and racoon to support dynamic
> keying? Is it because we want racoon to handle the creation, modification
> and deletion of SAs (meaning that it should handle the SAD) and get NEPL to
> handle the SPD?
>   

Yes, it is exactly this. mip6d (with or without NEPL patch) manages and
updates the SPD entries. It does not handle SAD. We need racoon2 to
create the appropriate SA entries when they are missing. We also need
racoon2 to be able to move the endpoints of the SA for rekeying
successfully. I am not sure why you're saying we need to modify NEPL?
The IPsec support of NEPL may be incomplete currently, that is the part
that must be improved. Static or dynamic keying makes almost no
difference for NEPL, as far as I recall.

About the requirements for racoon2, here are a few items that were
missing at that time (no idea what is the situation now):
- SPD entries managed by MIPv6 daemon.
- Asymmetrical Trafic Selectors (i.e. BU/BA)
- IKE_SA between CoA and HA; SA between HoA and HA.

> 	In theory, if NEPL fully supports IPSec, it should be able to handle
> the SPD anyway, so for example in the case of static keying. Am I right that
> NEPL does not fully support IPSec and as you said the nested case -and maybe
> other scenarios- suffer? 
>   
Yes :)

> 	I think, this just verifies what I have asked in the past, that NEPL
> does not currently support IPSec in the nested case even with static keys
> (sorry I am not trying to be picky, just want to clarify things!)
>   

I never tried it, but I believe it will not work out of the box, right
^^. There are probably some changes to make in the XFRM layer...
>> Almost, yes. The work on IKEv2 dynamic keying for NEPL was started when
>> Nautilus6 was active, and we got it working to some extent (not much
>> tests unfortunately, so there are probably some bugs around) -- but
>> then unfortunately Nautilus6 was terminated.
>>     
> Hmm, would it be too weird to ask to what extend? (I understand that you
> might not remember but just thought to try asking!). Am I guessing right
> that this work would be mainly in ipsec.c/h and keygen.c/h ?
>   
Actually quite a lot of tests as I can recall: tunnel-mode protection,
different IPsec parameters for different types of traffic (BU/BA;
MPS/MPA; ...) and so on. We had a demonstration of dynamic
keing-protected traffic payload also. You can find more information in
[1], sections 4 and 7.
I really don't recall the place in the code where the modifications were
made, but ipsec.c/h sounds good :)

>
> ..and here.. I have verified that static keying for a nested NEMO case is
> not working...
> (http://ml.nautilus6.org/pipermail/support/2010-February/001644.html )
>   
As I told before, I never tried the nested scenario. It requires a good
understanding of what should happen at each level (in different cases:
does the "inside" MR use the same HA or a different one? etc...)  and a
good understanding of current use of XFRM rules in the code. It is quite
a full-time job needed here ;) I don't even know if the current design
of NEPL and the XFRM rules can allow for the nested scenario...

> In addition, Arno had verified that he had problems getting ipsec working
> for a MN behind an MR (so this might lead to bugs in ipsec umip code?)...
> http://ml.nautilus6.org/pipermail/support/2009-September/001592.html 
>   

Yes, it is (almost) the same situation.

You can also add to your stack of "problematic situations" the case
where you have some DSMIP in the middle ;) The XFRM rules become really
complex!

> However, if we want to get IKEv2 support using Strongswan in a NEPL context,
> we would still be lacking the handling of the SPD from the nepl code.. am I
> right?
>   
The support is not lacking: it is already provided, and should work
sufficiently for usual cases. Anyway for more tricky situations (such as
nested case) some debugging is probably necessary.
Just for clarification, there is not much difference between the MR or
MN case (i.e. with or without the NEPL patch) with regards to IPsec. The
only difference concerns the protection of MNN traffic payload. If you
just want to protect MIPv6 signaling, you should have no problem at all
(except if the nested mobile does not already protect its signaling ;) )

[1] http://member.wide.ad.jp/tr/wide-tr-nautilus6-report2007-00.pdf

Hope this helps :)
Sebastien.