Re: [Spud] SPUD's open/close are unconvincing

[Christian Huitema <[e-mail]>]

> These signals don't seem to provide any useful advantages to me: Open is
> superfluous, and Close is unreliable.

Did you check the "reset middlebox attack" thread? It was threading much of the same ground. The general notion is that passing session state information in a clear text header allows for a set of denial of service attacks "through the middleboxes." The simplest attack is a fake "stop" causing middleboxes to drop their state and thus terminate the session, even if end-to-end authentication protects the end points against that attack.

> Open is superfluous
> -------------------
> 
> Given the existing 5-tuple, on-path equipment trivially knows when a flow starts
> already: it is a 5-tuple that they haven't seen before.  If you want to maintain a
> distinction between a one-side-opened flow and a replied flow, this is also
> traceable by looking at the 5-tuple.  It's not clear that the "open" signal gives on-
> path equipment any additional useful information that it didn't have already
> from the 5-tuple.

Yes. If it did, we would have to be concerned with route changes, which result in the same five-tuple being routed through a new set of middleboxes. The route change would have to be signaled to the end point, so they repeat the additional "open" information for the benefit of new middleboxes. That looks like a big can of worms.

> Close is unreliable
> -------------------
> 
> One of the reasons on-path equipment would like a "close" signal is so that they
> know when to tear down associations that are no longer needed.
> This would reduce memory consumption and make a device more resilient to
> DoS attacks that exhaust its connection table.  Without "close", the on-path
> equipment has to rely on timers to decide when to tear down the connection.
> 
> Unfortunately, we can't rely on endpoints to send Close.  Legitimate endpoints
> crash, run out of power, or have their network connectivity cut.  So on-path
> equipment needs to maintain timers anyway if they're tracking flow state
> instead of just passing IP traffic statelessly.  And in a DoS scenario, it's trival for
> an actively malicious end-point to send lots of "open" messages without ever
> sending a "close", so it doesn't protect against DoS either.

That, and the injection of fake stop packets by whoever can listen to the path and inject from the side.

> Why should SPUD bother with explicitly signalling open and close?

Agree with you, it would be better if it just did not include these indications.

The initial argument for open/close bit relates to "opening ports in the enterprise firewall." That's probably better handled by an explicit signaling protocol like the Port Control Protocol. In the previous thread, Tiru Reddy pointed to the work in progress to add authentication to PCP, and to the use of PCP to reduce the required frequency of keep alives. That seems more robust than unauthenticated bits in a clear text header.

-- Christian Huitema