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

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


Sebastien Decugis <sdecugis@xxxxxxxxxxxxxxxx> writes:

> Well in that context it is probably useless. NetworkManager becomes
> very convenient when you are moving to several locations with
> different WiFi configurations for example. But that tool is not
> IPv6-friendly at all currently :( And it becomes worst when MIPv6 is
> around...

This is one of the main advantages of MIPv6: you only need stupid
connectivity to be at home, where everything can be kept static from a
configuration standpoint.

>>> With regards to racoon2, I am not familiar with the rekeying
>>> process.
>> 1) Simple test: negotiate CHILD_SA lifetime of 60 sec and see the
>>                 behavior after a movement.
> Since the IKE_SA survives movement, the rekeying should happen
> regarless of movement.

yes, it is what is expected to happen. I just say that stressing a MN
that way allow to test the implementation in an easy and efficient

> Anyway I have had the case where CHILD_SA expired during the handover
> and... segfault. 

racoon does not segfault when that happens but it takes some time
(timeout and retries) for it to get things right (i.e. complete the

> I definitly need to spend time on this configuration,
> but I have more urgent tasks currently.


>> 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.
> IIRC, only the initiator should initiate a rekeying process. The
> configurations have to be in sync so that the initiator SA lifetime is 
>>= to the responder SA lifetime. I have not verified this in the RFC.

I'll check that in the RFC when i find some time.

>> 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
>> (if acceptable). 
> Hmmm that is exactly the kind of side-effect I was thinking of. We
> would need to determine if the SA should survive when MN is at home,
> before making it possible to rekey.

I was thinking about a knob in racoon conifiguration file if the idea
of surviving SA with no more associated SP makes sense. Not that when
the SP is added again by umip, there might be some side effects to track
due to the links that where cut when the initial SP was flushed.