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

[Caitlin Bestler <[e-mail]>]

On 4/8/15 3:21 PM, Daniel Kahn Gillmor wrote:
> Hi Toerless--
>
> On Wed 2015-04-08 15:39:21 -0400, Toerless Eckert wrote:
>
>> 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.
> As i wrote to Joe, i'm not convinced that this is an answerable question
> considering that no one has provided a technical argument yet for why
> the enterprise firewall operators can't already do what we're talking
> about here.
>
>
With what information? Are you talking about separate switch
vendors independently implementing a SPUD-like solution, or
are you claiming they already have enough information to perform
this with no assist from the endpoints?

I believe that endpoint assist in the form of declarative information
is necessary to enable optimum network response. Standardizing
that information will make it something vendors and endpoint
stack developers will support. Without standardization you have
a chicken and egg problem that will never be resolved.

The key questions are:
* Are the hints sufficient to provide optimizations that more than
    reward the cost of sending the hints?
* Are we avoiding creating some form of DOS-vector, which would
    result in everyone turning off this feature in the field?

I suspect there are some refinements that may be needed to
avoid enhancing DOS attacks. But we need to set the goal
realistically as avoiding *enhanced* attacks, and not rejecting
SPUD for being vulnerable to the same attacks that would have
worked against TCP.