On Fri, 12 Apr 2002, Shoichi Sakane wrote:

> > we don't have a fix for it? It seems to me the simplest thing is when we
> > get packets refering to SPIs we don't have keys for, we send back an IKE
> > message saying I don't know what you're talking about. I know we have the
> > ability when starting IKE to say we've rebooted, can't we use this in
> > cases where we don't necessrily want to initiate IKE but believe the other
> > side is confused?
>
> the receiver who gets unknwon SPIs doesn't know the sender
> is a valid macihne or malicious machines.  i think it's reasonable
> to just drop the packets without telling to the peer.

I understand your concern (we don't want to make a new DOS avenue).  But
the current situation *sucks*. If one side reboots, at the moment, I have
to manually go to all the other machines and reset their security policy
to re-establish communications. I started to go on a bit more about this
in the first note, but didn't for brevity. I will now in the interest of
finding a solution.

We can use a few huristics to help. First, if we don't have a potential
SPDs that would cover the request, we drop it. Like if we get an ESP input
from a host we don't have an ESP SPD with, we drop it. That would limit
whatever we do to hosts we "know" enough to have security policies with.

Next, we can rate-limit our response. If we have received and dealt with a
previous errant packet in say the last second or two, we don't do
anything. If the IKE daemon (racoon or isakmpd) is negotiating (not sure
how to detect this state), we don't do anything.

Not sure what to do if we have other, good SPDs from that host. Probably
nothing. Otherwise this might be someone else trying to interfeer with
established communications.

> another solution is that a process, IKE for example, in the sender
> sends an packet to the receiver periodically by using the SA.
> if the receiver had rebooted and lost the SA, the process never
> get any response.  then the sender can know to start new IKE
> negotiation.  but i'm not sure it's the best way to know.

My ideas are above. I'm not sure what is the best thing to do, but what
we're doing now isn't it. :-)

Take care,

Bill