[prev in list] [next in list] [prev in thread] [next in thread] 

List:       snap-users
Subject:    (KAME-snap 5049) Re: Continuing adventures with generate_policy
From:       Shoichi Sakane <sakane () kame ! net>
Date:       2001-06-28 13:47:49
[Download RAW message or body]

> > this problem causes the initiator has IPSec-SAs but the responder doesn't
> > have them.  this is same to the situation when the responder lost its
> > IPSec-SAs by rebooting or something.  there is no difference essentially
> > even if we can use a commit bit in the phase2 3rd message.  there is no
> > simple solution.

> > i'd say that we should make the value of the phase1 lifetime enough longer
                (1)
> > than the one of the phase2 lifetime in order that we can avoid this problem.
> > but they are not complete solution..

or (2) we should make the phase2 lifetime very short.

> From your experiements, how much longer should the
> phase2 lifetime be?

i don't have correct answer.  but, if we choice #1 then the phase1 lifetime
should be veeery long hour.  it means the phase1 expiration won't happen.
so above problem won't occur.
if we choice #2 then the phase2 lifetime should be very short.
it means we cannot be aware of above problem because the phase1 negotiation
can start immediately after the phase1 expiration happens.

i have another solution, that is (3) the phase1 and the phase2 should be
merged.  that is why i like HIP.

[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic