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

[Eliot Lear <[e-mail]>]

Daniel,


On 4/8/15 8:39 PM, Daniel Kahn Gillmor wrote:
> 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.
Open provides an indication that the flow is not a continuation, that
new state should be instantiated, that any old state of the 5-tuple
should be discarded.  Opens may flow in either direction, but may be
authorized for only some uses.
>
> 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.

This is by far the exception and not the rule.  Most state is torn down.

>   So on-path equipment needs to maintain timers anyway if they're
> tracking flow state instead of just passing IP traffic statelessly.

This misses the point.  If there is an implicit understanding of the
behavior of the endpoints, firewalls needn't keep state.  It is
sufficient in many cases to know that SYNs should be blocked whereas
SYN|ACK should be passed.  No state retained on the firewall.  There is
no equivalent in UDP without going up the stack.

Moreover, if a firewall is tracking state, it cannot tell if an incoming
packet is a continuation of a <flow/spud/tube> or an initiation if it is
*not* using timers.  This makes both open and close (as well as perhaps
some other gunk) very useful.

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

In fact, this is precisely the nature of a SYN attack.  Firewalls
regularly detect and block them in TCP.  UDP requires much more effort
and understanding of the higher layers.

Eliot