[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