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

RE: Error recovery?



People who connect using dial-up generally just hang-up. You can intercept
this and try sending a DELETE, but your results may vary...

As well, numerous vendors do not keep phase-1's up, and I suspect they feel
that renegotiating for the sake of a DELETE is not worth it.

OTOH, it would still be damn helpful where you could have it.

Paul Kierstead
TimeStep Corporation
mailto:pmkierst@timestep.com		http:\\www.timestep.com


> -----Original Message-----
> From: Mike Williams [mailto:mikewill@ibm.net]
> Sent: Tuesday, November 23, 1999 11:02 AM
> To: Andrew Krywaniuk
> Cc: ipsec@lists.tislabs.com
> Subject: Re: Error recovery?
> 
> 
> Andrew,
> 
> I agree that the best alternative is a keep-alive mechanism 
> similar to what is
> done with L2TP.
> 
> What I don't understand is why people are not sending DELETEs 
> when they go
> down.  I realize that DELETEs are not acknowledged and can be 
> lost, however in
> most situations this helps solve the problem. It seems like 
> the most appropriate
> way to inform the other side that you are going to stop using 
> an SA before it
> naturally expires.
> 
> In our implementation, we always send DELETEs for any 
> existing phase 1 or phase
> 2 SAs that we current know about when we go down.  We will 
> try this regardless
> of the reason we are going down - maybe a normal shutdown, 
> however maybe an
> exception that is bringing us down.  This has help tremendously, but
> unfortunately this does not appear to be common practice.
> 
> Mike Williams
> 
> Andrew Krywaniuk wrote:
> 
> > Hansi,
> >
> > I've done a fairly exhaustive analysis of this situation, 
> and it seems
> > apparent that the only way to really fix the problem is 
> with some kind of
> > keep-alive protocol.
> >
> > It doesn't really matter if it's a stateless asynchronous 
> query protocol:
> >
> > E.g. "Are you still there?" "Yes."
> >
> > or a stateful synchronous uni-directional protocol:
> >
> > E.g. "I'm still here (seq no=1234)."
> >
> > The problem is that if the SA really has gone down then the 
> peer can't
> > communicate with you without performing some kind of time-consuming
> > operation (e.g. negotiating a new SA, signing a packet with 
> RSA, etc). This
> > makes it very easy for an attacker to spoof a packet which 
> will elicit a
> > response from one of the peers, thus effecting a DoS 
> attack. The only way to
> > detect a lost SA without the DoS vulnerability is to rely 
> on a timeout.
> >
> > As for the keep-alive alternatives, the query protocol will 
> yield a faster
> > recovery time, but the synchronous protocol is easier to write.
> > Unfortunately, there is currently no standardized 
> keep-alive protocol in
> > IKE/IPSec.
> >
> > BTW, the other solution is to keep all state information in 
> non-volatile
> > storage so it sticks around after a reboot. That's not very 
> practical for
> > most of us, though.
> >
> > Andrew
> > _______________________________________________
> >  Beauty without truth is insubstantial.
> >  Truth without beauty is unbearable.
> >
> > > -----Original Message-----
> > > From: Hans-Joachim Knobloch [mailto:hajo@knobloch.de]
> > > Sent: Friday, November 19, 1999 1:02 PM
> > > To: ipsec@lists.tislabs.com
> > > Subject: Error recovery?
> > >
> > >
> > > Please excuse, if this is a FAQ or if I was simply too blind
> > > to find the
> > > answer in the RFCs and drafts on IPSec.
> > >
> > > Consider the case that two hosts communicate via two 
> IPSec security
> > > gateways
> > >              A <---> SG1 <-----> SG2 <---> B
> > >
> > > and that appropriate ISAKMP and IPSec SAs are 
> established. Let us call
> > > these SAs SA1, SA2AB and SA2BA respectively.
> > > Now what happens, when SG2 is reset?
> > >
> > > When B sends a packet to A everything should be fine, 
> since SG2 will
> > > initiate new phase 1 and phase 2 exchanges.
> > > But what if A sends a packet to B? SG1 will process the
> > > packet with the
> > > old IPsec SA2AB and SG2 will receive a packet with a most
> > > probably unknown
> > > SPI. Is this supposed to happen until SA2AB does 
> "naturally expire"?
> > > Do we have to set SA lifetime short enough and/or hope that B
> > > will also
> > > send a packet more sooner than later?
> > >
> > > Alternatively one could imagine that SG2 sends SG1 some kind of
> > > (ICMP?) message to tell it to invalidate SA2AB. But then,
> > > this might be
> > > abused by an attacker to cause unnecessary ISAKMP traffic and
> > > a service
> > > disruption until new SAs are installed.
> > >
> > > In the above example, when SA2AB expires, SG1 will 
> probably initiate a
> > > phase 2 exchange with the old SA1. What is the correct 
> way for SG2 to
> > > respond to this? Initiate a nes phase 1 exchange? Send an error
> > > notification to SG2 (then necessarily unencrypted due to 
> nonexistant
> > > ISAKMP SA)? The latter might open up a denial-of-service
> > > attack by sending
> > > spoofed error notifications to make SG1 invalidate its
> > > existing SAs and
> > > thus cause lots of unnecessary ISAKMP traffic and service 
> disruption.
> > >
> > > Hansi
> > >
> > >
> 


Follow-Ups: