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

[Jana Iyengar <[e-mail]>]

Eliot,

A few responses:

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

If used like this, it creates another DoS vector where anyone can trivially
kick someone else's connection off.


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

AFAIK, TCP connections are commonly torn down with an RST (not a FIN), and
not infrequently with silence. I would love to know what the truth is -- is
there any data that I can look at to prove myself wrong?

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

Why does it need to tell the difference? I'm not sure I see a use case at
the middlebox for using this information.

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

Why would a DoS attacker set the OPEN bit in SPUD if it will thwart their
attack? That would be silly...