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

[Jana Iyengar <[e-mail]>]

Hi all,

One higher-order point: This conversation seems to refer to middlebox
admins as outsiders and represents them as an ossified whole. If this new
architecture is to be a end-middle-end architecture, the middle needs to be
represented in a technical debate about the value of new protocol
machinery. I would sincerely love to see that happen. I think there's a
good bit of serious architectural work that can be done here, but this
requires wrangling with hard questions about trust, delegation, and
placement of network functions. I fear that discussions on what exact bits
to expose so that middlebox admins don't turn into fire-breathing monsters
misses the larger architectural questions.

It's not clear to me that we should negotiate with middlebox admins on what
bits they want -- I'd like some degree of engagement on exactly why they
want it. I'm not keen to see the middlebox admin's wishlist of what headers
they'd like to see. I'm substantially more interested in understanding the
network functions they are looking for. Chances are these are implementable
without the information they think they need.  If not, let's make that case
-- one network function at a time -- do a cost-benefit analysis for the
good of the Internet, and decide whether to expose any bits.

dkg has quite nicely said many of the things I've wanted to say below; I'll
re-echo these and I'll add a couple of comments inline.

> 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.


+1.


>
> > - 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.


+1.


>
> > - 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.


+1.


>
> > - 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


+1.


> > - 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.


+1. I'll add that it wouldn't be surprising for clients to disappear or for
servers to drop TCP connections without sending a FIN or an RST, for a
variety of reasons. (As it turns out, this can be energy-saving for mobile
devices that don't have to wake the radio up only to receive and process a
FIN! See: http://conferences.sigcomm.org/co-next/2013/program/p211.pdf.)


> > 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
>

It obviously does matter if we disagree with them. We're considering a
rework of the Internet's architecture -- I don't think this is what you're
saying, but at what point did we decide to take their needs as absolute?
"They" need to make technical arguments about their needs, if more
information is to be exposed for their use.

> 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.
>

Doesn't it seem silly that we will be engaging with corporate firewall
admins, but only to learn that *they think* our traffic needs to look like
TCP for them to be comfortable with it? Their perceptions of TCP are most
likely ossified, and quite possibly wrong -- what do we do then? (Perhaps
we should run the "Underhanded TCP Contest" -- make crazy stuff happen but
look like TCP on the wire :-)) TCP FastOpen and Minion both challenge prior
notions of what was (incorrectly but commonly) considered TCP behavior. I
would be quite disappointed if we were to enshrine this ossification in a
wg, and for non-TCP protocols too! This wouldn't be evolution, this would
be ossification on steroids.

> 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?
>

+1.

- jana