[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
(usagi-users 03930) Re: RACOON/UMIP/KERNEL Patches
- To: usagi-users@xxxxxxxxxxxxxx
- Subject: (usagi-users 03930) Re: RACOON/UMIP/KERNEL Patches
- From: arno@xxxxxxxxxxxx (Arnaud Ebalard)
- Date: Wed, 29 Aug 2007 08:43:01 +0200
- References: <firstname.lastname@example.org> <46D4FDD4.email@example.com>
- Reply-to: usagi-users@xxxxxxxxxxxxxx
- User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.95 (gnu/linux)
Sebastien Decugis <sdecugis@xxxxxxxxxxxxxxxx> writes:
> Arnaud Ebalard a écrit :
>> I must confess that (IMHO) there are still open points in the expected
>> relationship between IKE daemons and MIPv6 stack, even if everything
>> works fine 99.9% of the time. This includes various situations where
>> movement occurs at a bad moment (Phase 2 rekeying) or simply HL2FL or
>> FL2HL w.r.t. SA/SP states handling in racoon.
> I agree, I have the same kind of issues with racoon2. Need some
> stabilization work I guess.
I have prepared a Home Agent with a patched racoon i intend to use on a
day to day basis to debug problems. As my test laptop managed to stay up
and running for days, it's now stable enough to start doing that.
>> ps: The SADB_X_EXT_PACKET support has also been tested by Sebastien
>> using racoon2 as KM.
> Yes. People have to be aware that the SADB_X_EXT_PACKET does not
> contain the "real" packet (BU message) but a constructed one. It does
> not contain the DestOpt header for example (at least in the
> pre-release I tested) It is not a problem for us since we are only
> interested in CoA, not HoA (we can retrieve the HoA from other place
> in the message).
Yes. An earlier version contained the DestOpt header carrying the HAO
but i removed it after a discussion with Shinta. The CoA is now
extracted from the AltCoA option (which is in sync with current RFC on
the topic and also with another idea i have).
>> Here are precise comments for every patch that [IMHO] will at least
>> provide pointers to the curious reader and possibly spare him funny
>> hours of digging in the code:
>> o Against the most recent branch of umip development git tree
>> ( 0.4rc2 ) - allow_interface_addition_removal.patch:
> Did you by chance test this with NetworkManager tool? This tool (that
> simplifies the process of connecting to wireless networks) currently
> breaks mip6 features and cannot be used together with mip6.
I don't use NetworkManager at all. Basically, my test laptop has wifi
activated, sometimes bluetooth (for fun because latency is terrible)
and also ethernet when some cable is plugged. Using preferences on
interfaces in umip, everything works fine. my resolv.conf has a static
DNS configuration (quite logical).
Probably a stupid question but what's the interest of NetworkManager in
that context ?
>> The feature is not for HA.
> Do you mean the patch must not be applied to the HA daemon?
The patch is fine for MN, HA and CN but if you try to start a HA with a
mip6d.conf that expect eth4 to be available it has to be there at
startup (just like it is without the patch), i.e. the patch does not
provide the improvement for HA. With some work, this might be
feasible. To make it simple, i did not have the need and HA are pretty
stable in term of interfaces while MN and CN are not.
>> o Against current CVS version of raccon (to be applied in that order)
>> Discussion: one of the expected (positive) side effect is that the
>> rekeying of the SA is still performed even if the associated SP has
>> been deleted. This is because ipsecdoi_setid2() contains a call to
>> getspbyspid() which makes the function return if no SP is
>> associated with the the SA. In the case of tunnel mode SA, when
>> returning home, the SP gets removed, which normally means that next
>> rekeying will simply not work. I don't know if it is the expected
>> behavior of racoon to have next rekeying not working or if it is
>> just a bug. More generally, what is the expected behavior a KM
>> should have on that point. How does racoon2 handles that ?
> I don't know what is the expected behavior with regards to the SA. The
> SPD entries are removed, so the SA are not used anymore while the MN
> is at home, is it correct?
> Anyway if we keep these alive, they will be ready when the MN moves
> again. So I guess both behaviors are acceptable.
I'll discuss that with Yvan and others as i think there is an expected
behavior for a KM (so that they can interoperate).
> With regards to racoon2, I am not familiar with the rekeying
1) Simple test: negotiate CHILD_SA lifetime of 60 sec and see the
behavior after a movement.
2) Question: from old reading of 4306, i think i remember that lifetime
are no more negotiated but each side manages its own
direction. Tell me if i'm wrong. This might end up creating
problems if the KM on the HA tries to rekey when the MN
moves. On the MN, this could be detected.
> In any case, iked daemon does not handle the pfkey message
> when spd entry is deleted
In racoon, it does.
> and smpd daemon only removes the binding spid - selector.
In racoon, one of the patches removes the need to access the SP during
rekeying (for generating ID). If the racoon2 also does that kind of
thing, you can't keep the SA up with the HA (via rekeying) when on HL
> rekeying, I have not investigated.
Investigating you need. May the force be with you.