[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Synchronisation in IKE
> Hi,
> Problem 1,2,3 : this problem can be solved if IKE keeps a HELLO or keep
> alive
> message periodically (not in rfc).
> Problem 4 : In this case B should send INVALID_COOKIE(rfc 2408) notify to A
> .
>
I wouldn't recommend that solution as B would have to send an UN-encrypted
notify (Since it doesn't have a Phase 1). And if Side A accepts UN-encrypted
notifies for invalid cookie as an indication that Side B has lost it's
phase 1, Side A is open to Spoofed notify DOS attack. ( I suppose Side B could
initiate a phase 1 in order to send a protected notify )
Our solution is to retry QM's several times (3 by default) and if that fails,
fall back to doing a Phase 1. If the Phase 1 fails to negotiate, the VPN is
torn down.
Regards,
Michael Carney.
>
>
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
>
>
>
> I think this is a very important issue and is giving me plenty of
> headaches.
> Is there any documents that talks about how to resynchronise IKE
> negotiations.
> Any advice on the subject would be greatly appreciated.
> Take as an Example the next case:
>
> 1- A (Initiator) negotiates with B (Responder)
> 2- B reboots and is unable to send any delete notification.
> 3- A can't talk to B anymore (A has IPSEC SAs, but no B) I have no
> solution for this. IDEAS?
> 4- IPSEC SAs in A expire. A Initiates a Quick mode negotiation but B
> doesn't have ISAKMP SAs either
> That could be solved letting A detect that B can't negotiate and
> initiating a new Phase I negotiation.
> Is there any problem with this solution? If yes is there an
> alternative?
> What do I do with the old ISAKMP SA? Keep or destroy it? I'd
> destroy it, but not sure if can give any problem.
>
> I'd really appreciate any response.
> Thanks in advance.
>
> Toni
>
Follow-Ups:
References: