[support] IPSec in NEMO BS with static keys

[Sebastien Decugis]

Hi,

>> packet is matched with the FWD rules upon reception. I am not so sure
>> if
>> it also go through OUT rules before being sent.
> 
> It seems that you remember rightly;-) 

Good ^^


> My tests also suggest that a packet from a MNN to a CN via an MR, goes
> through MR's FWD and then OUT rules. To me it seemed more logical that the
> packet would go through IN rules when it reaches the MR and then follow the
> FWD rule instead of OUT, but maybe this is just how my mind perceives it. 

It's interesting, I remember I had the same remark, to me also IN + FWD
would have seemed more natural. Probably just a matter of taste... :)


> Just to clarify it again (as I do not want to confuse anyone in the list) a
> packet that is being forwarded from an MR seems to be following FWD and then
> OUT rules.
> 
> It seems that IN equals "I am going to consume the packet, the packet is
> destined at me", FWD equals "the packet is not for me" and OUT is always
> followed. 

Yes, that is a good summary.

>> 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 :)
> 
> This is a good example. So, in the case of forwarding traffic from MN1 to
> MN2, and because the MR is neither source nor destination) the rules should
> hit FWD and then OUT rules, but I guess that because there are no rules for
> IPSec-ing that part, the packets should hit the FWD+OUT and then be sent
> unencrypted, is that right?

Yes that is correct. The corresponding code is in the NEPL patch
(version on
http://cachenet.u-strasbg.fr/hg/umip-dsmip/file/42c136944bd6/nepl.patch
) at lines 2011 and 2831 for the MR rules (BYPASS rules mean the traffic
is not encrypted, and have a higher priority).


> Yes, I know that the project has been terminated and it is very good to see
> you guys offer your time and resources to support it voluntarily;-) 
> 
> In order for me to write a guide about these rules, I have to firstly
> understand them very well, don't I? And this will take some time:!

Yes :) I personally found that the most efficient way to understand how
XFRM works was to follow execution in the kernel, when a packet was
received.
For educational purpose, you might want to look a our DSMIPv6 code: we
add a new XFRM transformation in the kernel for UDP encapsulation (which
is probably totally outdated now) so by looking at the patch you may see
what kernel code path is called, and the corresponding rules in the
daemon to add matching policies...

Good luck with that!

Best regards,
Sebastien.

> 
> Thanks for your help,
> Panos
> 
> 
>