Re: Re: RR checks to avoid DoS attacks

Short story: Personally, I agree with Bill on this issue.

Longer version: In order to determine whether RR is needed
in this case, we need to first look at the potential damage
vs other attacks. Is this attack worse? As we all know,
there's plenty of denial-of-service attack and flooding
attack opportunities in the current Internet. For instance,
attackers can just send some packets to the victims, or
they can send spoofed packets to the victim, or even
reflect the packets out of some other service, such as
DNS.

There's little we can do about such attacks in the
current Internet architecture*. But at least we should
avoid making it worse. Here we have to compare the
cost/benefit of attacks vs. currently available attacks.

The primary issue with redirection/flooding attacks
is *not* that we can send packets to the wrong place --
clearly some of the other attacks mentioned above can
do that as well. Instead, the issue is about how much
*amplication* we can get out if it, and as a result
possibly a better bang-for-the-buck ratio for the
attacker. Let's look at the cost side:

1. Need to have a security association with the server,
    and identify oneself
2. Need to run D-H to establish IKEv2 in the first place
3. Need to setup a stream
4. Need to send some signaling packets to redirect the
    stream

The benefit side is getting N packets to the victim, with
N varying highly depending on the application and its
transport layer behaviour.

Its kind of hard to compare the results without a
specific situation. But I would like to avoid providing
an amplification opportunity for any situation, given
that most of the current attacks have no amplification.
Also, item 1 from the cost list does not apply in all
situations, such as with opportunistic IPsec, or when
your machine has been taken over by some malware. (I
know that a million virus-infected PCs can already do
a lot of DoS damage, but consider giving them amplification
tools too!)

The ICMPs and other signals that Tero mentioned help
here, but I wonder if they help soon enough to prevent
the amplification; applications and transport protocols
will have some safeguards as well, so the streams will
_eventually_ end. More importantly, since we assumed
one of the peers was malicious, there's nothing preventing
it to send protected TCP ACKs, for instance, to keep the
streams going.

All this leads me to believe that we need to have an RR check
in the protocol, performed always except when there's
a certificate that explicitly lists the addresses.

FYI: There are also recent innovations where the peers track
the traffic they have sent to each other, and based on
past "effort" they can allow a temporary traffic redirection
to an untested address, until the RR test can be completed.
In this case it becomes possible to prove that the remaining
attacks have less bang-for-the-buck than, say, source address
spoofing. But I think adopting something like that for MOBIKE
would be premature and an overkill.

--Jari

*) Something called i3 is an example of a modified
architecture which would be able to prevent this.