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

[Brian Trammell <[e-mail]>]

hi Daniel, all,

Thanks for your comments; commentcomments per tradition inline...

> On 08 Apr 2015, at 20:39, Daniel Kahn Gillmor <[e-mail]> wrote:
> 
> Hi folks--
> 
> Thanks to those who organized the SPUD BoF at IETF 92.  Despite having
> some serious big-picture concerns about SPUD overall, I sympathize with
> the general goal of facilitating encrypting more traffic to protect the
> confidentiality, integrity and anonymity of Internet communications, so
> i appreciate the effort.
> 
> I'll write up the big-picture concerns separately, but right now i plan
> to focus on some of the concrete details that i find unconvincing about
> the idea and the associated proposals.  I'll try to keep each detail
> relatively succinct.
> 
> This message is about the need for open/close in SPUD, which in the
> presentations i saw was frequently the first example brought out to
> explain what advantages SPUD can offer to existing on-path equipment.
> 
> These signals don't seem to provide any useful advantages to me: Open is
> superfluous, and Close is unreliable.
> 
> Open is superfluous
> -------------------
> 
> Given the existing 5-tuple, on-path equipment trivially knows when a
> flow starts already: it is a 5-tuple that they haven't seen before.  If
> you want to maintain a distinction between a one-side-opened flow and a
> replied flow, this is also traceable by looking at the 5-tuple.  It's
> not clear that the "open" signal gives on-path equipment any additional
> useful information that it didn't have already from the 5-tuple.

I'll defer to Joe's answer on what makes firewall guys happy. :)

I think part of the problem is we're trying to draw a boundary we don't quite understand between the "over" transport (the thing inside SPUD) and the "minimal common" transport that SPUD provides. Which is why we're putting effort into a prototype, on which see my next message (hopefully somewhen tomorrow...)

The explicit signaling of OPEN to devices on path is an accident of the design of TCP. There are devices out there that treat SYNs specially, and the point of signaling OPEN is, in the first order, to allow those devices to do those things they do on SYN. On the other hand, reacting to SYN specially is one of the mechanisms by which these devices make assumptions that can break connectivity, so maybe this is one of those requirements that isn't really a requirement, but rather something common to the over-transport.

Another way to look at OPEN is that it is the inverse of signaling the running state. As a middlebox, seeing packets on a tube for which you didn't see an OPEN or an ACK means:

(1) you rebooted or got a new address
(2) routing is different and you're seeing the middle of a flow
(3) someone is messing with you

It also means that you're missing any ADEC information associated with the tube, and cannot tell whether the tube is valid. It's also not 100% clear you can do anything useful with these.

SPUD's ACK (roughly TCP SYN/ACK) is more interesting. A SYN/ACK in proper response to a SYN means that someone on the other side of the firewall decided a connection could proceed, or more mundanely means there is now actually state on the endpoint so any state the network needs should be there too. For bidirectional transports (i.e., for every transport one should be running over SPUD, since congestion control requires feedback, as does proof of reverse reachability to reduce spoofing) it might be that ACK is sufficient to get us what we need. (In reviewing that paragraph, we probably also need to name it something other than ACK.)

> Close is unreliable
> -------------------
> 
> One of the reasons on-path equipment would like a "close" signal is so
> that they know when to tear down associations that are no longer needed.
> This would reduce memory consumption and make a device more resilient to
> DoS attacks that exhaust its connection table.  Without "close", the
> on-path equipment has to rely on timers to decide when to tear down the
> connection.
> 
> Unfortunately, we can't rely on endpoints to send Close.  Legitimate
> endpoints crash, run out of power, or have their network connectivity
> cut.

Another reason: transports running over SPUD might not even have a signal that maps to CLOSE.

> So on-path equipment needs to maintain timers anyway if they're
> tracking flow state instead of just passing IP traffic statelessly.

Yep. Nobody's saying you can chuck the timers with CLOSE. You can set faster timers once you've seen one, and use state space only for the exceptions. Right now, just looking at a bare UDP datagram, you can't.

It is important to note that if CLOSE is done right, and the active tube ID space remains sufficiently sparse, then only devices on the path or entities cooperating with them -- i.e., those that are in position trivially block or inject traffic -- can fake a CLOSE: you have to be able to fake a valid tube ID.

> And
> in a DoS scenario, it's trival for an actively malicious end-point to
> send lots of "open" messages without ever sending a "close", so it
> doesn't protect against DoS either.

I don't think we can have devices on path that keep any sort of state without defenses against state exhaustion, and I don't know that it's useful to design those into a signaling encapsulation. You still have to have reverse-reachability, cookies can help, and you probably need some sort of heuristic for rate-limiting. Indeed, these all speak toward making ACK the important OPEN.

Cheers,

Brian