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

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

On Wed 2015-04-08 16:53:24 -0400, Joe Hildebrand (jhildebr) wrote:
> On 4/8/15, 1:39 PM, "Toerless Eckert (eckert)" <[e-mail]> wrote:
>
>>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.
>
> Yes.  In talking with enterprise firewall admins, they're comfortable with these properties of TCP:
>
> - they're sure which interface the intent to start an association came in on

This is true of UDP today.

> - they're pretty sure that subsequent packets match that initial intent

This is also true of UDP today; responses to the same 5-tuple (with
source and dest swapped) provide a "pretty sure" match.

> - they're pretty sure that if a box goes down comes back up, or a new
>   box takes the old one's address listening on the same port, that the
>   host will be able to reject traffic left over from an old association

Surely this is a matter for endpoints and not for middleboxes, and
dependent on the protocol implemented by the listener?  For stateless
listeners on an endpoint, they shouldn't mind seeing traffic from an old
"association" because no state is associated with it.  For stateful
listeners, they can simply discard traffic that doesn't align with their
internal state.

> - they know when to clean up state

This is untrue of either TCP or UDP today in an absolute sense.  In both
cases, they must each rely on timeouts because either peer can fall
off-net for many different reasons that are beyond anyone's control.

> - they don't feel the need to set as aggressive timeouts as they
> currently do for UDP, which would cause apps to send lots of extra
> keep-alives

So they're willing to permit longer timeouts for raw TCP SYNs than they
do for UDP?  That sounds like a trivial state exhaustion attack waiting
to happen.  If they treat an unacknowledged TCP SYN with an aggressive
timeout, but then lengthen the timeout after seeing a SYN/ACK, then
surely they can just treat an unreplied UDP 5-tuple with the aggressive
timeout, and lengthen it when they see a response?  This doesn't require
any on-wire format change.

> From a certain perspective, it doesn't necessarily matter if we
> completely agree with them that today's implicit heuristics are not
> good enough.  We have evidence that there are enough corporate
> firewall admins have similar feelings, particularly in places where
> folks that want to deploy standards-based WebRTC solutions (e.g.),
> that I believe we need to take their perceptions into account.  The
> approach that SPUD currently takes is to smell enough like TCP from a
> policy perspective that we can get corporate firewall admins to allow
> the traffic by policy.
>
> In other words: these are potentially deployment requirements, not
> technical requirements.

This argument is also unconvincing to me.  It sounds like you're saying
that we cannot rely on this group of administrators to make reasonable
decisions about how to operate their equipment on the basis of the data
that they currently have, so we're going to do some unnecessary things
to the bits on the wire that will convince them to make reasonable
decisions on the basis of some other unnecessary data.

Why should i believe that this will be the eventual outcome?  A group of
administrators has already provided evidence that they're unwilling to
consider reasonable approaches with data format A; why would equivalent
data format B suggest they would do anything different?

      --dkg