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

[Toerless Eckert <[e-mail]>]

Daniel,

a) I think one hope of SPUDs design is to make UDP look enough like
   TCP to persuade FWs (and similar middleboxes) to police / permit it
   as well as TCP flows are policed/permitted.

b) If you don't like how it works, let me generalize the question,
   would like to hear your (and others) answers:

   What is the best possible design we can do to make UDP flows
   be equal or better permissible across WELL BEHAVED FW and similar
   middleboxes ? Please define "WELL BEHAVED"as part of your answer.

c) If i read it correctly, SPUD can 

   a) set up potentially multiple independent pipes across the same 5-tuple.
   b) A single pipe can go across different 5-tuples (multipath/mobility).
   
   These two features should explain why tracking 5-tuple as you
   suggest alone would not be sufficient.

   Btw: I am a fan of b), i don't think a) should be encouraged given
   experience with RTCweb. In that sense, the total number of
   pipes would even be equal or smaller than the number of 5 tuples.


Cheers
    Toerless

P.S.: Cool domain name. Is that indicative of the role you're planning
to take in the discussion ? ;-))) (sorry, i can never resists these questions).


On Wed, Apr 08, 2015 at 02:39:16PM -0400, Daniel Kahn Gillmor wrote:
> 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
> 
> _______________________________________________
> Spud mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spud