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

+1 on everything you said, but (*grin*) i think we should
layer the analysis:

The base layer is analysing how a "session setup/teardown" signaling
on top of UDP with an arbitrary transport protocol encapsulated
inside of it compares to eg: Native TCP wrt. security and
policy for end-to-end operations and FW/middlebox operations.

The only bar to pass here is that it should not be significantly worse
than TCP.

Then the next level is to add the possible enhancements (or
others) factored into the SPUD proposals and see how each of them
fares. Some of them would have to be compared with other existing
approaches. Eg: if the tube ID is an alernative or enhancement to
MPTCP, then one would have to compare with that.

On the base layer, the main downside i can come up with is that the
filtering of invalid protocol packets or sequence of packets is something
that ideally should become more easy, because the FW would only have
to do it once for SPUD instead of every different transport separately,
but alas that is not true because an attacker can still modify the
encapsulated transport proto signaling elements, so a FW that would
like to provide that state-machinery/packet-header filtering for
transport protocols would need to still understand the whole SPUD+Transport
stack. Just off the top of my head, the best way out would be to
move towards UDP+SPUD+dTLS+reliable-transport, because that would protect
that arbitrary transport protocol headers from attacks and would leave
FWs with only SPUD and dTLS to worry about.

Cheers
    Toerless

On Thu, Apr 09, 2015 at 09:59:29AM -0700, Caitlin Bestler wrote:
> 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.
> 
> _______________________________________________
> Spud mailing list
> Spud@ietf.org
> https://www.ietf.org/mailman/listinfo/spud