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

Re: Error recovery?

Gentlemen, Check out the ISIS transaction transport or the TibCO's
Information Bus, these systems all have process control and restart built
into them and it has worked over IP based connections for years.

Restart and control parsing are key parts of distributed control functions
and have been worked out by folks that had real-world events to control,
like 1.5 ton autos rolling down a conveyor belt.

The reality is that Policy and Service Management is exactly analogous to
the Industrial Automation technologies pioneered in the 60's-80's and we
should learn from the mistakes and successes these folks have had...


Todd


I suggest that the
----- Original Message -----
From: "Andrew Krywaniuk" <akrywaniuk@TimeStep.com>
To: <ipsec@lists.tislabs.com>
Sent: Friday, November 19, 1999 05:02 PM
Subject: 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
> >
> >
References: