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

[Caitlin Bestler <[e-mail]>]

On 4/8/15 1:53 PM, 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
> - they're pretty sure that subsequent packets match that initial intent
> - 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
> - they know when to clean up state
> - 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
>
>  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.

Joe's analysis highlights an important point - there is no need for SPUD 
to be better than TCP.
If TCP is vulnerable to off-path reset attacks, then it would be ok for 
SPUD to be vulnerable.
We just have to avoid making SPUD *more* vulnerable.

>