[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

(usagi-users 03929) Re: RACOON/UMIP/KERNEL Patches



Hi Arnaud,

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.

No problem.


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.


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 not investigated.


Best regards, Sebastien.