Re: [Spud] The reset middleboxes attack

[Christian Huitema <[e-mail]>]

> On Monday, March 30, 2015, at 7:35 AM, Bless, Roland (TM) [mailto:[e-mail]] 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.

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. 

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

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

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

-- Christian Huitema