[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
(usagi-users 03929) Re: RACOON/UMIP/KERNEL Patches
- To: usagi-users@xxxxxxxxxxxxxx
- Subject: (usagi-users 03929) Re: RACOON/UMIP/KERNEL Patches
- From: Sebastien Decugis <sdecugis@xxxxxxxxxxxxxxxx>
- Date: Wed, 29 Aug 2007 14:02:12 +0900
- In-reply-to: <firstname.lastname@example.org>
- References: <email@example.com>
- Reply-to: usagi-users@xxxxxxxxxxxxxx
- User-agent: Thunderbird 184.108.40.206 (Windows/20070728)
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.
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).
ppppps: Sebastien, i have taken a quick look at your howto. Good
work. I'll try to update it soon with a section on racoon
configuration (most notably identity handling).
Thank you. I have not made it public yet, I hope I can do this soon.
pp..ps: Martin, Sebastien, sorry for the delay.
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 )
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.
The feature is not for HA.
Do you mean the patch must not be applied to the HA daemon?
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.
With regards to racoon2, I am not familiar with the rekeying process. In
any case, iked daemon does not handle the pfkey message when spd entry
is deleted, and smpd daemon only removes the binding spid - selector.
Removing this selector may have some side effects on rekeying, I have