[support] IPSec in NEMO BS with static keys

[Sebastien Decugis]

Hello,

Sorry for my late answer.

> I see, maybe that should be mentioned in the nautilus website as the above
> guide is the only one regarding ipsec and static keys and what you mentioned
> is a huge difference in the implementation stack and makes a difference to
> anyone trying to use it as a guide. 
>   
Well, the guide you refer mention that SHISA is the mobility stack of
NetBSD and FreeBSD in its introduction... Furthermore, it's a technical
report from 2006, we cannot really change its content.
> Judging from Romain's email there is a constant effort to update
> documentation and maintain the code which is extremely good and helpful so
> that more people would be interested to investigate and support this effort
> more. 
>   
The configuration of the mobility daemon is shown in that tutorial
(referenced from the NEMO tutorial):
http://www.nautilus6.org/~sdecugis/dynamic_keying/Howto_dynamic_keying.html
In the context of the tutorial, we are dealing with dynamic SA. But
since SA are handled outside of the daemon, they can be added
statically. You are right that this should be mentioned somewhere. I
believe that Romain is updating its NEMO tutorial to include some notes
about configuration of static IPsec (with your set of configuration ;) )

I hope these changes will help newcomers to find their way in this
complex world :)

>> The rules that are matched are different if the local host is an
>> endpoint of the packet or not. I don't exactly remember how the rules
>> are matched between IN, OUT and FWD. Simply put, a forwarded packet
>> does
>> not go through IN then OUT rules. (I seem to remember it's FWD + OUT
>> but
>> I am not sure at all!)
>>     
>
> Hm, I am doing some tests in my current setup to try and find out in
> practise which rules are matched. Basically I am running pings across my
> testbed and checking what the setkey -PD reports in the last used field. 
> (as a side note, why the rule for the BU is created every time a BU is sent,
> and it does not just update its timestamp? Are the rules being removed from
> the spd after a while? Is there a timer that expires? This does not seem to
> be the case with other rules though..)
>   
This is the way UMIP is designed. You have to consider the expected
behavior of you MN (or MR) in the following cases: no binding
established; a BU is sent but BA is not recevied; the binding is
established. Depending on the step where you are, you want to be able to
receive incoming traffic and/or incoming signaling. To find the fine
information about this, the best way is to follow the execution of UMIP...

> It is far from easy to realize how the rules are used:-/ When you say above
> that FWD +OUT rule is matched, in what case do you refer to ? Is it the case
> of an MR forwarding MN's traffic up the tunnel? Because bellow you are
> saying that a fw packet will not follow the OUT rule...
>   
Yes it was more a general comment about XFRM transformation rules. You
have IN and OUT rules. For routers, a forwarded packet would logically
go first through IN rules, then through OUT rules. But in XFRM you have
also FWD rules, and forwarded packets (the local node is neither source
nor destination) will match these rules. In the case of forwarded packet
(yes, for example, a packet from MNN to CN, when it reaches the MR) the
packet is matched with the FWD rules upon reception. I am not so sure if
it also go through OUT rules before being sent. In the MR for example,
the forwarding is quite complex with regards to IPsec rules if you are
protecting traffic between MR and HA. Imagine a MR with 2 mobile
networks MN1 and MN2. you must forward in clear packets from MN1 to MN2,
but encrypt packets from MN1 to CN (through HA). You can see the
complete set of rules we came to in the MR in the daemon's code :)

> You are very correct on this and it is certainly due to the lack of
> documentation. I found some papers regarding xfrm but still they are not
> helping a lot... 
>
> A good idea would be to document xfrm and ipsec policies and rules (probably
> on nepl's website) as this would help people to understand the whole concept
> a lot easier.
>   
Yes, it would be great, but I think nobody in Nautilus6 has the
resources to do that... As you may have read, the project is terminated
and we only do volunteer support now, with limited time. But if you want
to write such a guide, it would surely be useful for a lot of people ;)

Best regards,
Sebastien.