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

[Georgopoulos, Panagiotis]

Hello Sebastien,

	Once more thanks for your reply, it is very useful !

	Please see some minor comments inline..

> 
> 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.

OK, we are certainly on the same side now! This is my understanding as well!

> 
> 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.
> 

Thanks;-)


> > 	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...

.. and I believe you are right.


> >> 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.

Thanks for the pointer!


> 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...
> 

Yes that needs further tests...


> > 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.

In my mind having an MR behind an MR is not that tricky and can arise in the
real world very easily. But for the shake of understanding, indeed the
nested case is a further step from the simple case, that is getting an MR
supporting MNN :-)


> 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. 

Yeap, again this is all clear to me now!

> 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.

It does, thanks a lot,
Panos