[Spud] SPUD's open/close are unconvincing

[Daniel Kahn Gillmor <[e-mail]>]

Hi folks--

Thanks to those who organized the SPUD BoF at IETF 92.  Despite having
some serious big-picture concerns about SPUD overall, I sympathize with
the general goal of facilitating encrypting more traffic to protect the
confidentiality, integrity and anonymity of Internet communications, so
i appreciate the effort.

I'll write up the big-picture concerns separately, but right now i plan
to focus on some of the concrete details that i find unconvincing about
the idea and the associated proposals.  I'll try to keep each detail
relatively succinct.

This message is about the need for open/close in SPUD, which in the
presentations i saw was frequently the first example brought out to
explain what advantages SPUD can offer to existing on-path equipment.

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

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.


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.



Why should SPUD bother with explicitly signalling open and close?

    --dkg