[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Error recovery?
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: