Subject: [tcpm] Inner Option Space revised: inner-space-01

From: Bob Briscoe <[email-masked]>
Date: Mon, 27 Oct 2014 23:00:20 +0000

TCPM folks,

I've posted a revision to:
"Inner Space for TCP Options"
<https://tools.ietf.org/html/draft-briscoe-tcpm-inner-space-01>

Thanks to the following for useful discussions (mostly off-list), 
whom I've added the Acknowledgements section:
Costin Raiciu, Marcelo Bagnulo Braun, Julian Chesterfield and Jaime 
Garcia, and of course the continuing discussions with Joe Touch.

       Technical changes:

       *  Corrected DO to 4 * DO (twice)
       *  Confirmed that receive window applies to Inner Options
       *  Generalised the cause of decryption/decompression from a
          previous TCP option to any previous control message
       *  Added requirement for a middlebox not to defer data on SYN
       *  Latency of dual handshake is worst of two
       *  Completed "Interaction with Pre-Existing TCP Implementations"
          section, covering other TCP variants, TCP in middleboxes and
          the TCP API.  Shifted some TCP options to Outer only, because
          of RWND deadlock problem
       *  Added two outstanding issues: i) ossifies reliable ordered
          delivery; ii) Ideally Outer in Inner.

       Editorial changes:

       *  Removed section on Echo TCP option to a separate I-D that is
          mandatory to implement for inner-space, and shifted some SYN
          flood discussion in Security Considerations
       *  Clarifications throughout
       *  Acknowledged more review comments

Cheers

Bob

>From: <[email-masked]>
>To: Bob Briscoe <[email-masked]>, "Bob J. Briscoe" <[email-masked]>
>Subject: New Version Notification for draft-briscoe-tcpm-inner-space-01.txt
>Date: Mon, 27 Oct 2014 12:07:17 -0700
>
>
>A new version of I-D, draft-briscoe-tcpm-inner-space-01.txt
>has been successfully submitted by Bob Briscoe and posted to the
>IETF repository.
>
>Name:           draft-briscoe-tcpm-inner-space
>Revision:       01
>Title:          Inner Space for TCP Options
>Document date:  2014-10-27
>Group:          Individual Submission
>Pages:          49
>URL: 
>http://www.ietf.org/internet-drafts/draft-briscoe-tcpm-inner-space-01.txt
>Status: 
>https://datatracker.ietf.org/doc/draft-briscoe-tcpm-inner-space/
>Htmlized:       http://tools.ietf.org/html/draft-briscoe-tcpm-inner-space-01
>Diff: 
>http://www.ietf.org/rfcdiff?url2=draft-briscoe-tcpm-inner-space-01
>
>Abstract:
>    This document describes an experimental method to extend the limited
>    space for control options in every segment of a TCP connection.  It
>    can use a dual handshake so that, from the very first SYN segment,
>    extra option space can immediately start to be used optimistically.
>    At the same time a dual handshake prevents a legacy server from
>    getting confused and sending the control options to the application
>    as user-data.  The dual handshake is only one strategy - a single
>    handshake will usually suffice once deployment has got started.  The
>    protocol is designed to traverse most known middleboxes including
>    connection splitters, because it sits wholly within the TCP Data.  It
>    also provides reliable ordered delivery for control options.
>    Therefore, it should allow new TCP options to be introduced i) with
>    minimal middlebox traversal problems; ii) with incremental deployment
>    from legacy servers; iii) without an extra round of handshaking delay
>    iv) without having to provide its own loss recovery and ordering
>    mechanism and v) without arbitrary limits on available space.
>
> 
>
>
>
>Please note that it may take a couple of minutes from the time of submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>The IETF Secretariat

________________________________________________________________
Bob Briscoe,                                                  BT

---

From: Wesley Eddy <[email-masked]>
Date: Mon, 27 Oct 2014 19:54:32 -0400

> <https://tools.ietf.org/html/draft-briscoe-tcpm-inner-space-01>

Hi Bob, this is well written, and I think it has some good pieces.

The EchoCookie, for instance, seems useful with or without regard
to all these other documents about extending option space.

That said, I really don't like so-called "dual handshake" or
multiple parallel SYN designs, personally.

The downsides are well trodden, and you mention some in the draft.
The driving force behind this approach, as I understand, is to
keep latency minimal.

IMHO, the draft-borman-tcp4way approach:
http://tools.ietf.org/html/draft-borman-tcp4way-00
is a bit cleaner in avoiding the parallel SYNs and the associated
issues.

The main downside of 4way is potentially a slight latency.

Importantly, just as you say that after upgrades have been made,
the multiple SYNs of inner-space can go away, and only upgraded SYNs
be sent, the same is true of the 4way approach; it could just revert
to a normal 3way handshake after transition.

Also, I believe it would be possible to implement a cache of hosts
that have successfully negotiated using 4way in the recent past,
so that new client connections can optimistically directly send
an upgraded SYN, rather than initiating a full 4way connection.
This would be a heuristic, of course, for cases where latency is
a major concern.

So, I guess this is very long-winded, but my real question is for
others in the working group and whether or not there's consensus
about multiple parallel SYN approaches being an acceptable design
pattern or not.

My personal opinion is that they aren't desirable.

-- 
Wes Eddy
MTI Systems

---

From: Joe Touch <[email-masked]>
Date: Mon, 27 Oct 2014 17:01:53 -0700

> My personal opinion is that they aren't desirable.

I have similar issues with 4WHS, FWIW.

I.e., it's clear we need to put the additional SYN space outside the
original SYN. We have three options:

	- supplement segment sent in parallel
		SYN-OOB, as per my draft

	- dual-stack
		IMO, that's what inner-space ends up being

	- an additional exchange
		IMO, that's what 4WHS ends up being, albeit
		reversed and overlapped

I'm not completely sure we need to pick yet, however; it's very clear we
need more experience with these approaches to see what works and
determine interactions.

Joe

---

From: John Leslie <[email-masked]>
Date: Mon, 27 Oct 2014 20:42:18 -0400

Wesley Eddy <[email-masked]> wrote:
>... 

   Alas, we have long since painted ourselves in a corner where
parallel SYNs is arguably the "cleanest" way out. :^(

> The driving force behind this approach, as I understand, is to

   That, alas, is pretty essential.

> is a bit cleaner in avoiding the parallel SYNs and the associated

   It's a toss-up... I feel more nervous about that path right now.

> The main downside of 4way is potentially a slight latency.

   I have some other worries, but any added latency is nearly fatal.

> to a normal 3way handshake after transition.

   Both those future optimizations deserve to be discussed; but won't
drive the decision which approach(es) to use.

> This would be a heuristic, of course, for cases where latency is

   That, alas, is dangerous ground, with load-balancers out there
which do nothing to verify compatibility of the hosts behind them.

> about multiple parallel SYN approaches being an acceptable design

   I don't think we're ready for a consensus call on that.

   But my own opinion is that parallel-SYN is entirely "acceptable".
Nobody is forced to use it. (There's really no good reason to use
it on _every_ TCP connection.)

> My personal opinion is that they aren't desirable.

   My own preference would be to route-around-it, working up a clean
solution for expanded option space on the SYN-ACK; and working in
parallel to reduce the need for nearly-all options to be listed in
the initial SYN. (Even reducing the size of the instance of an option
in the initial SYN could help substantially.)

   (I've been biting my tongue during the recent discussion about
whether options need to be "negotiated" starting with the initial
SYN...)

--
John Leslie <[email-masked]>

---

From: Wesley Eddy <[email-masked]>
Date: Tue, 28 Oct 2014 00:42:07 -0400

> 		IMO, that's what 4WHS ends up being, albeit

I neglected to mention the OOB approach, though now I remember that
you did sketch this taxonomy already in section 4 of the syn-ext-opt
draft.

For what it's worth, I also think the OOB approach is more desirable
than the "dual-stack" type, however, am more uncertain about firewall
behavior towards the segments with both SYN & ACK bits clear.  That's
definitely a good experiment to get widespread data on.  I also don't
really understand specifically how one decides how long to wait for
the OOB segment before assuming it isn't coming, but that could be
tweakable or algorithmically determined, so I don't think it's a major
issue.

> need more experience with these approaches to see what works and

Agreed!  My curiosity is whether we only need a smaller number of
experiments because maybe we prefer approach X and just need to know
if it really tends to pass through a high enough percentage of the time.

-- 
Wes Eddy
MTI Systems

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 28 Oct 2014 10:59:41 +0000

Wes,

Before doing experiments, we need to understand / agree what problem 
we're trying to solve and what success would look like.

The roll-out of an enabling technology like extended option space has 
to be tied to the roll-out of something really useful that it 
enables. No-one will go through deployment pain with only a weak 
promise of possible future gain.

Opportunistic encryption is one possible flag-pole to tie the extra 
option space flag to. The problem that the tcpinc w-g faces is that 
if something new in the TCP header is 'normalised' on 15% of paths by 
middleboxes, then it's really easy for <large_security_agency> to 
target connections it wants to snoop by just normalising headers. Ie. 
when middleboxes are indistinguishable from downgrade attacks, it's 
easy to hide a real downgrade attack.

So the ideal is 100% legacy middlebox traversal{Note1}. 99.9% might 
be enough, but 98% would be too low. Then we get the full force of 
demand for increased security behind extra option space deployment.

If that succeeds, we get widespread integrity-checking of the TCP 
options, and we've beaten the middleboxes for ever (see previous email).

And ideally 0% average extra latency. 1% might be OK, but 10% would not.

And finally, the protocol architecture needs to remain clean and evolvable.

For instance Inner Space places TCP Options within the TCP Data 
because I've learned that's the proper way to make a protocol 
architecture evolvable. I.e. TCP should always have been like that. 
It's not just a hack.

Regards

Bob

{Note1} To be clear 'legacy' does not include any middleboxes 
specifically coded to seek out and destroy the new approach. As long 
as that's very rare, users won't click on "Connection not secured; 
Continue anyway?" without being reeeeeeally careful.