[support] IPSec in NEMO BS with static keys

[Georgopoulos, Panagiotis]

Hello guys,

	Sorry for my late reply but I was running some tests and wanted to
make sure that my setup works (yeap I made it to work)! Many thanks for your
help;-)

	See some comments inline...


> On 2009/08/20, at 15:31, Sebastien Decugis wrote:
> >> Has anyone on the list tried to use IPSec for a mobile network
> >> (basically
> >> using umip+nepl)?
> >
> > Yes I have used similar setup (but with dynamic keying: the SA are
> > created by racoon2, not manually) at some point in the past and I was
> > successful protecting MNN->CN traffic between the MN and the HA. It
> > required a patch at the moment, that I believe has been merged in the
> > nepl patch since (I think Romain can confirm this, I did not check
> > myself, sorry). I remember the patch consisted in looping through the
> > list of prefixes when we add the IPsec rules.
> 
> Yes, the patch was integrated in since a few releases of the NEPL
> patch.
> 

I can verify that as I didn't use any additional patch and it eventually
worked. 

As a side note though, I am a bit confused of how the patches are being
created and integrated in the "mainstream" code.. Are you going to integrate
Arnaud's patches at some point?


> By the way Panos, was the "setkey" log you sent created while mip6d
> was running on the MR and the MR registered to the HA? It seems that
> your SPDs are empty, which makes me think that mip6d was not launched
> and/or the MR did not register to the HA (mip6d takes care of
> installing the SPDs).
> 

Romain you are right, this is my fault. The MR was registered successfully
to my HA, but I didn't know that the umip code removes the entries from the
spd when you stop running it (unlike the entries in the sad which are
persistent).

When I do a setkey -PD while running the code I do get the correct spd
entries (see file attached).


> >> You are right that using MCoA is complicating things more. I will
> >> follow
> >> your advice and disable it for now to see if it helps.
> >
> > I am not sure, but I'd say you should not use source code with MCoA
> > patch applied for testing IPsec, if I understood Romain comment
> > correctly (just disabling in the configuration will probably be not
> > enough).
> 
> Yes, this is what I meant. You should start with umip+nepl only
> (without the mcoa patch applied). Once it works fine, you could move
> to an environment with MCoA, but I do not guarantee it would work.
> 

Yes, I started with a fresh vanilla umip+nepl code (without the mcoa) and it
worked!


> >> You are right, but the question is do I install IPsec policies in
> >> the SAD or
> >> the SPD and how? (relating with the above)
> >
> > umip takes care of the SPD for you. You only need to provide entries
> > in
> > the SAD. The kernel will automatically use an appropriate SAD entry
> > when
> > a packet matches a policy in the SPD. If no appropriate entry
> > exists, an
> > ACQUIRE message will be generated, then you'll see an error after a
> > timeout (I think the error is "permission denied" but I am not so
> > sure).

Knowing that umip takes care of the SPD is very useful. I must have been
confused as the guide here
(http://member.wide.ad.jp/tr/wide-tr-nautilus6-configuring-ipsec-for-shisa-m
ipl-00.pdf) uses some configuration files that add spd entries manually
(using spdadd)


> > I am not too sure how the SAD entry in tunnel mode must be specified
> > in
> > the case you are interested in. I usually find that matching entries
> > with the reqid is easier, maybe something to try?

Now that I am starting to find my way around sad and spd it seems that
finding them using the requid is easier. It is very surprising that there
isn't any documentation out there describing them... 

By the way what is the difference between an "in ipsec" and "fwd ipsec" in
the spd? How would that operate differently from either the MR's or the HA's
point of view?

For example, what is the difference between the following two :

(Note : 
* 2001:db91::2 is the HA
* 2001:db94::215:58ff:fe77:bed8 is the CoA of a MR
* 2001:db72:: is the MNP that the MR advertises to nodes)

2001:db72::/64[any] ::/0[any] any
	fwd ipsec
	esp/tunnel/2001:db94::215:58ff:fe77:bed8-2001:db91::2/unique:20
	created: Aug 20 19:14:59 2009  lastused: Aug 20 19:54:08 2009
	lifetime: 0(s) validtime: 0(s)
	spid=2498 seq=5 pid=32498
	refcnt=1
2001:db72::/64[any] ::/0[any] any
	in ipsec
	esp/tunnel/2001:db94::215:58ff:fe77:bed8-2001:db91::2/unique:20
	created: Aug 20 19:14:59 2009  lastused: Aug 20 19:54:25 2009
	lifetime: 0(s) validtime: 0(s)
	spid=2488 seq=6 pid=32498
	refcnt=1


	Thanks again guys,

	Cheers,
	Panos
	
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: sad_spd_entries.txt
Url: http://ml.nautilus6.org/pipermail/support/attachments/20090821/90a25229/attachment.txt