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

[Christian Huitema <[e-mail]>]

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

The mapping to actual transport semantics is not entirely clear. Many transport protocols implement some kind of protection against SYN Flooding. One popular such protection is a cookie challenge. So we get a connect/SYN request, a challenge response, a confirmation of the challenge, and only then the actual accept by the server. Which of the server's message map to ACK? The challenge, or the actual confirmation?

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

Even that is not obvious. What kind of value do you give to the "fast timer?" What if the mobile client is asleep when the fake CLOSE arrives, and cannot invalidate it quickly by sending more traffic? 

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

Please take a look at the Quantum attacks, which combine passive listening on the path with injection from the side. There is a difference between "block traffic" and "inject traffic." Only the forwarding agents can effectively block traffic. Passive listeners can inject traffic without cooperating with the forwarding agents.

-- Christian Huitema