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

[Bob Briscoe <[e-mail]>]

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.

1) Parallel control channel
___________________________
Client A sends two SYNs back-to-back to an existing well-known port (e.g. 80).
* 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.

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.
* Channel C would need some way to refer to the segments of channel D 
that was robust against re-segmentation.
* 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>

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


Bob

At 22:12 22/05/2014, David Borman wrote:

>On May 22, 2014, at 12:58 PM, Joe Touch <[e-mail]> wrote:
>
> >> 2) However, I think the main problem is that many important cases will
> >> need as large or larger TCP option space on the SYN as on non-SYNs.
> >
> > Oh, I certainly agree with this. The point of this proposal is twofold:
> >
> >       a) (primary) to put to bed the notion that 'there is a way'
> >       to extend SYN option space without contaminating connections to
> >       legacy hosts
>
>Add to that "without adding any additional packet 
>exchanges."  That's really the issue.  This can be done, within the 
>existing TCP processing, but at the cost of an additional RTT, which 
>everyone tries to avoid.  The receiver could respond to the initial 
>SYN with another SYN, which *can* take advantage of an extended 
>option space because it now knows that the other side supports 
>EDO.  The originator incurs an additional RTT before it can send 
>data (2 vs 1 RTT), the receiver has no delay for when it can send 
>data (1.5 RTT).
>
>Besides the additional RTT for the originator, the biggest problem 
>with this would be all those blasted firewalls that would drop the 
>returning SYN-only responses.  The other way to do this is that when 
>the SYN/ACK comes back indicating that the other side supports EDO, 
>then the originator sends another SYN with the expanded option 
>space.  That has a cost of a full RTT in both directions.
>
>
>But the issue still remains the same: for that initial SYN packet, 
>with no a priori knowledge, there is no way to extend the option 
>space and maintain 100% backwards compatibility.
>
>                         -David Borman

________________________________________________________________
Bob Briscoe,                                                  BT