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

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