Re: [Spud] The reset middleboxes attack

["Bless, Roland (TM)" <[e-mail]>]

Hi Christian,

comments inline.

On 30.03.2015 at 22:36 Christian Huitema wrote:
>> On Monday, March 30, 2015, at 7:35 AM, Bless, Roland (TM)
>> wrote: ...
>>> I can see that implementers may not be enthusiastic with the 
>>> additional complexity. But we would be naïve to just dismiss the 
>>> attack. We do see attackers capable of eavesdropping traffic, and
>>> then injecting packets "from the side." I am sure that these
>>> attackers would find good use of a capability to nuke connections
>>> at will.
>> 
>> The described approach would be still vulnerable to on-path
>> attackers, right?
> 
> If we add a cryptographic protection on the reset packets, then it
> will prevent the reset injection attack by anyone, including on path
> attackers.

Sorry, I was confused by the term "hash result" R in your previous mail,
and reread the mail again. So R is the preimage that comes with the
CLOSE, while T comes with the OPEN and therefore the middlebox can
verify that H(R)=T.

> Of course, on path middleboxes have the possibility to just drop all
> packets for a connection. That's a different attack, and it is
> possible to find out the culprit by looking at where packets are
> dropped. It is much harder to get away undetected with a blocking
> attack than with a single packet injection attack.

Yep. However, there is little you can do against such a DoS attack anyway.

>> Furthermore, middleboxes must be prepared that route changes may
>> occur and they may see only the start packet and maybe some data
>> packets, but never the end packet.
> 
> The route changes issue is probably worth its own thread.
> 
> I am worried that even if routing does not change, SPUD expose end
> points to new attacks. The root cause is that SPUD middleboxes are
> expected to make decisions based on unauthenticated data in the
> packet headers. The reset attack is just one of those, probably the
> most obvious one. Quick brainstorm comes up with other possible
> attacks:
> 
> * Inject lots of "open" packets with different context ID, targeting
> the same five tuple. These will be discarded by the end points, but
> for the middle boxes they are the equivalent of a "SYN Flooding"
> attack.

Yes.

> * Inject packets with creative values for declared bandwidth and
> other parameters. Depending on parameter values, this can be either a
> DOS against the end point (e.g., fake requirement of 100 bps for a
> video stream) or a DOS attack against the network (e.g., stack a lot
> of bandwidth reservations for nonexistent flows).

IMHO resource reservation is a different game and doesn't make much
sense without some form of authorization. That's why I don't buy the
argument that SPUD will cause no harm because of its purely indicative
nature (like a flow + traffic specification): if such indicative values
would have no effect on middlebox operation, you could simply dismiss
them. Otherwise if middleboxes take them seriously it may lead to attack
vectors just as you described.

> I understand how to protect against the reset attack, but I am not
> sure what to do about these other attacks.

It is possible to create some protection schemes, but usually that will
end up in 3-way handshakes and the like, which isn't lightweight anymore.

Regards,
 Roland