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

Re: Synchronisation in IKE



Comments inline....
> 
> 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?

We will not detect that B has lost state until we rekey the SA, thus the
QM rekey. Thus this is not an ideal situation, but one which is eventually
recovered.  Keepalives would also do the trick if the usage was standardized.

How about if B initiates a Phase 1 (if it can based on it's static configuration)
in order to send an protected "unknown SPI" notify message? (Rate limited of
course). 


Regards,
Michael Carney

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