Re: [Spud] The reset middleboxes attack

[Caitlin Bestler <[e-mail]>]

On 3/29/15 9:15 AM, Yoav Nir wrote:
> Routing on the internet can change at any time, so you can’t trust that for a particular TCP connection, a UDP flow or a “tube” all packets are going to follow the same path and pass through the same intermediaries.
>
> Fortunately, the stateful intermediaries, such a firewalls, QoS boxes and NATs tend to be placed at such choke points that all packets do flow through them. The exception is when one endpoint gets reconfigured, such as a mobile device moving from one network to another. TCP handles this gracefully by closing the connection (OK, that’s not really “gracefully”), and for UDP it didn’t matter, because there was no meta-data in the packets.
>
> With SPUD the “tube” will have meta-data in the packet, so either we copy TCP’s breakage when something changes, or we do something else. In the BoF we talked about the intermediaries being able to inject packets into the tube. I guess we could have them inject a “need-state” command when they detect what appears to be an already-open tube. In response the endpoints can send a special packet with the parameters needed at the OPEN command, affirming that this is indeed an open tube. endpoints whose address has changed could proactively send such packets to avoid getting blocked for a round-trip.
>
>
If a middlebox is doing something stateful then routing an existing TCP 
connection through it will not work.
That is how middleboxes work today.

I cannot think of why a middlebox would be doing something stateful if 
they were not at some form of
check point. Middleboxes do not take on per-connection state because 
they are bored.

Having a set of middleboxes somehow be aware that they form alternative 
routes to a protected domain,
and automatically share state and responsibility for protecting said 
domain is, to put it mildly, too ambitious
of a project for standardization.