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

["Toerless Eckert (eckert)" <[e-mail]>]

Jana:

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

IMHO, and stealing a sentence from DanW: FW/Middlebox admins
are charged to stop bad bits to come in (virus), stop good bits to go out
(secrets) and otherwise not impact the business. Thats Mission Impossible,
but there are a bunch of aspects where SPUD can help:

- Filtering based on combination of port-numbers + IP addresses +
  roles of communicating parties (initiator, responder).  This assumes
  you trust at least one side (because of IP) to assign port-numbers
  according to well known or otherwise intended use. What protocols like
  SPUD could help here is to substitute the limited space of 16-bit port
  numbers with better application-intent metadata. It could also decouple
  roles from sequencing of packets. Today, coming from TCP, initiator == 
  client, responder == client, initator sends first. Now imagine you would
  want in IoT servers polling clients for example. By explicitly including
  role as a signaling element (client/server) you can do this, and e
  voila: UDP+SPUD becomes more flexible and FW friendly than TCP.

- Filtering of "malformed"/"unknown" protocol packets. 
  Today, for UDP everything is in some higher layer payload. So if we
  move an equivalent level of connection management as TCP has it into
  a standardized over-UDP level protocol, and will give FW operators the
  same degree of protection as when using TCP.

- Filtering based on signalled cryptographic authenticators (eg:
  cert + challenge/reply snooping/filtering). Can't quite remember
  how much of that was proposed in SPUD, but certainly a worthwhile
  area for real security. 

Just some thoughts. There is of course a lot more.

Cheers
    Toerless

On Wed, Apr 08, 2015 at 04:46:06PM -0700, Jana Iyengar wrote:
> 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.
> 

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