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

Re: Synchronisation in IKE

On Tue, 28 Nov 2000, Mike Carney wrote:

> > 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.
> 
But how do you know to send a QM? The problem is that host A is sending
packets to B. B is silently discarding them, because B rebooted or lost SA's
or whatever.

B can send send an unprotected notify, but that has DoS problems, if A
   actually heeds the unprotected notify.
B can initiate a QM (or phase 1), but again there are DoS problems (As
   stephane pointed out).

There's no 100% secure way that B can let A know that it doesn't have SA's
for the traffic that A is sending.

Keepalives are fine, but are a somewhat expensive approach (although there's
some rather decent solutions; also it's arguable if keepalives aren't
something that a routing protocol is supposed to be doing). The only other
thing is to do some rate-limiting and trade-offs so that the DoS problems can
be bounded (Have B send unprotected notifies to A every 20-100 packets (I
just made up those numbers), and have A discard them, unless it got more
than, say, 5, AND it actually sent the traffic that's being complained about
recently. Then it MIGHT behoove itself to initiate a new QM or phase 1 to B,
and the DoS Problems have at least been reduced, although that's arguable).

I don't see where A could figure this out on its own, so i don't quite
understand your 'Our solution is to retry QM's several times' above...

Let me know if I missed something,
jan





> 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
> > 
> 
> 

 --
Jan Vilhuber                                            vilhuber@cisco.com
Cisco Systems, San Jose                                     (408) 527-0847
References: