Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-01.txt

[Joe Touch <[e-mail]>]

On 5/23/2014 5:13 AM, Bob Briscoe wrote:
> David,
>
> There is certainly no need for an additional RTT.
>
> Let me propose a couple of concrete strawmen (concrete men?) to show
> this. I'm not claiming these are novel. I know Joe and others think that
> we've seen enough of attempts to extend the TCP options on the SYN, but
> Joe should know that when he claims something is impossible, he wakes
> sleeping dragons in people like me.

I slay dragons all the time ;-)

("Defender of the cruciform packet"* is one of my mottos)

> 1) Parallel control channel
> ___________________________
> Client A sends two SYNs back-to-back to an existing well-known port
> (e.g. 80).

You can send in whatever order you want; packets will be reordered, 
lost, and sent along alternate paths.

FWIW, do these use the same source port and ISN?
	- if they do, it'll reset the connection
	- if they don't, you're now limiting the number of
	concurrent connections to roughly half:
	http://www.isi.edu/touch/pubs/infocomm99/infocomm99-web/

> * SYN D, establishes a regular data connection, with sufficient TCP
> options to be workable but they still fit within the existing 40B option
> limit.
> * SYN C establishes another parallel connection to the same well-known
> port that looks like regular data from the outside (it could even be an
> extension to HTTP to ensure middleboxes will let it pass), but it talks
> a new app-layer 'TCP control' protocol inside.

What happens when they arrive out of order? What happens when you get D 
but not yet C? How long do you wait for C?

This is the problem with dual-stack approaches - new endpoints penalize 
legacy endpoints if there's a stall, and undermine new endpoints if they 
don't.

> If there is no support for the new app-layer protocol on port 80 the
> control channel just shuts down with a suitable HTTP error, while SYN D
> has opened a data connection with sufficient TCP options to be workable.
> If the new app-layer TCP control protocol is supported on port 80, the
> parallel control channel (C) adds unlimited additional control
> flexibility to the data channel (D) hardly any added latency.
>
> Establishing a similar control channel in the opposite direction would
> be fairly trivial.
>
> There are few, if any, middlebox problems with the above approach.
> However, there are certainly other problems, but no more insurmountable
> than all the problems that have already been discussed with taking the
> 'easy' route of EDO:
> * A secure binding would have to be added to bind channel C to a secret
> known only to the originator of channel D, otherwise it would open up
> data channels to spoof control channel attacks. This binding could be
> built on a TCP-AO option in channel D.

Yes, that's another problem.

> * Channel C would need some way to refer to the segments of channel D
> that was robust against re-segmentation.

Which means it won't work in the current Internet, because 
resegmentation is also widespread (though evil, IMO).

> * The main problem is that the two channels don't share fate;a control
> packet can be delayed relative to the point in the data stream at which
> it is attempting to exert control, possibly for a RTT if it is lost and
> has to be retransmitted. However, this is not insurmountable. The
> control protocol could include a mode to "synthesise shared fate", by
> making the data channel buffer data until an associated control segment
> had arrived. This would duplicate the latency impact of a loss or delay
> on either channel, but one can imagine mitigations that would consign
> this latency impact to corner cases.
> * It's a bit of a mess, but that comes with the territory when trying to
> fix legacy protocol problems.
> * The internal stack architecture seems to require a trombone back down
> into the kernel from user-space, but that is not insurmountable - a shim
> within the kernel on port 80 (for example) could redirect control
> channel data across to the "TCP control channel module" in the kernel,
> while passing non-control channel connections to user-space.
>
> 2) Build on LOIC
> ______________________
> Long option with invalid checksum <draft-yourtchenko-tcp-loic-00>

Won't work through current NATs, which won't recalculate the checksum 
properly.

>
> At 18:53 22/05/2014, John Leslie wrote:
>>    That's too big of a change to ask folks to believe it safe.
>
> When I read an idea, I don't take it as set in stone and just find a
> hole and dismiss it. I see it as a potential stepping stone to a
> solution and think about how it could be done better. In fact, Andrew
> Yourtchenko said that was the intention of his write-up of LOIC.
>
> I believe that an approach worth further thought would be a mixture of
> the control channel idea and the invalid checksum idea. I'm thinking of:
> * a pure control SYN (C) sent first, then a base SYN (D) sent
> back-to-back, both to the same port.

Again, please don't assume back-to-back means anything.

> * SYN C would contain something invalid to cause a legacy TCP stack or
> legacy app to discard it (and hopefully less probability that a
> middlebox would), e.g. a payload that is invalid for the application
> protocol on the port.

But so will a NAT, etc.

> * there would be additional TCP options in the payload of SYN C to be
> added to the TCP options that arrived separately on the base SYN
> * The control SYN could be bound crytographically to the base SYN (as
> already described).
> * It could use the shim-like control stack arangement described earlier.
>
> By focusing solely on extending the SYN, this would avoid the ongoing
> shared fate problems that a separate control channel suffers throughout
> the connection. There would still be shared fate problems with 2 SYNs
> (e.g. the two SYNs get re-ordered), but the protocol would have to be
> designed to be robust to that (naively, SYN D could include a new TCP
> option that told a new stack to wait a few ticks for a SYN C, but that
> would be vulnerable to meddleboxes). Not insurmountable.

AFAICT, it is.


*with a nod to Raiders 3.