Re: Re: RR checks to avoid DoS attacks

Thanks Jari, for your detailed comments. 

I have not sanity checked the following possible attacks completely, but 
I thought these might also be possible.  Please see inline:

Jari Arkko wrote:

>
> 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!)
>
I am not quite sure what you mean by amplification (do you mean MOBIKE 
protocols make things worse?).  In any event, my understanding of the 
attack is that without RR it might be possible for a hacker to take over 
a vulnerable host and launch a DoS attack another one that she could not 
hack into.  But, I think if a hacker can obtain valid credentials to log 
into a VoD server protected by IPsec, RR only offers limited protection.

For example, would it also be possible for an adversary to gain control 
of n clients, log in to a VoD server, start a video download, and then 
change the address to a single target host's address in all of the 
clients?  If traffic flows to the new address before RR verification 
(which could take some time if the number of retries is reasonably 
large: 'dozen times over a period of at least several minutes' as 
suggested in IKEv2-13 in a similar context :-) ), it will result in the 
video streams requested by all n clients to be sent the victim at once.  
Furthermore, the adversary can divide the n clients into m groups and 
can launch a fairly sustained attack.  There might be an IKEv2 safeguard 
against this; I have to check.

> 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.

I did not think of the 'sending of protected TCP ACKs to fake liveness' 
:-), but that prompts me to say that RR should require the client to 
decrypt the RR request message, and send a reply with information from 
within the request message.  If the protocol were to send an empty 
informational message, wouldn't the client be able to "expect the time 
of the request" and send a valid "response?"


best,
Lakshminath

>
> 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.
>