Subject: [tcpm] More option space on any segment: draft-briscoe-tcpm-inner-space-00 (was syn-op-sis-02)

From: Bob Briscoe <[email-masked]>
Date: Mon, 20 Oct 2014 01:58:26 +0100

Chairs and list,

My individual draft has a new file-name (and title): 
<https://tools.ietf.org/html/draft-briscoe-tcpm-inner-space-00>inner-space-00
This is a major rev of 
<https://tools.ietf.org/html/draft-briscoe-tcpm-syn-op-sis-02>syn-op-sis-02, 
but I won't be using that name any more.
Sorry to confuse everyone by changing the name. But the old name was 
no longer relevant.

I believe the new Inner Space protocol could be a significant advance for TCP.

It should allow new TCP options to be introduced:
i) with minimal middlebox traversal problems;
ii) avoiding incremental deployment problems with pre-existing servers;
iii) without a round of handshaking delay
iv) without having to provide their own loss recovery and ordering mechanism
v) without arbitrary limits on available space.

I believe this could be a significant simplifying foundation over 
which tcpinc (TCP increased security) could be built. So I want to 
encourage folks on the list to read and criticise it with some 
urgency, because tcpinc is working to a fairly tight schedule.

I've been working on this fairly intensely in my 'spare' time over 
the last few weeks, working through all the possible interactions 
with middleboxes and other options, then simplifying and iterating 
through the checks again. I'm v happy with how it's turned out now.

It's intended for experimental status. Listening to the advice on the 
list, I've chosen a basic 'mandatory to implement' core, and included 
optional extensions in appendices.

I've also written-up an extensive Design Rationale section, because 
there's a lot of subtlety in it, even tho the core protocol looks v simple.

The appendices and the rationale make the doc v long (48pp). Sorry 
about that! But the core spec is actually still only 13pp.

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-00.txt
>Date: Sun, 19 Oct 2014 16:59:03 -0700
>
>
>A new version of I-D, draft-briscoe-tcpm-inner-space-00.txt
>has been successfully submitted by Bob Briscoe and posted to the
>IETF repository.
>
>Name:           draft-briscoe-tcpm-inner-space
>Revision:       00
>Title:          Inner Space for TCP Options
>Document date:  2014-10-19
>Group:          Individual Submission
>Pages:          45
>URL: 
>http://www.ietf.org/internet-drafts/draft-briscoe-tcpm-inner-space-00.txt
>Status: 
>https://datatracker.ietf.org/doc/draft-briscoe-tcpm-inner-space/
>Htmlized:       http://tools.ietf.org/html/draft-briscoe-tcpm-inner-space-00
>
>
>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 the 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) avoiding incremental
>    deployment problems with pre-existing 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: Joe Touch <[email-masked]>
Date: Mon, 20 Oct 2014 11:54:32 -0700

On 10/19/2014 5:58 PM, Bob Briscoe wrote:
> Chairs and list,
> 
> My individual draft has a new file-name (and title): inner-space-00
> <https://tools.ietf.org/html/draft-briscoe-tcpm-inner-space-00>
> This is a major rev of syn-op-sis-02
> <https://tools.ietf.org/html/draft-briscoe-tcpm-syn-op-sis-02>, but I
> won't be using that name any more.
> Sorry to confuse everyone by changing the name. But the old name was no
> longer relevant.
> 

IMO, you're on the path to implementing TCP inside TCP.

That is, right up until a middlebox starts parsing and modifying the
inner TCP, at which point you'll need TCP-in-TCP-in-TCP, ad infinitum.

IMO this whole exercise is a significant step backwards, except as a
good example of why we need constraints for middleboxes.

Joe

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 27 Oct 2014 18:05:06 +0000

Joe,

>inner TCP, at which point you'll need TCP-in-TCP-in-TCP, ad infinitum.

Nope. Here's a bulleted summary of the section in 
inner-space that explains why this could be a 
permanent stop on middleboxes, not just a step in 
an arms race. Of course, I can't predict for 
certain what the operators will buy, but this is a plausible argument:

non-goal
* evasion of security middleboxes
   –they will evolve to check Inner Options

goal
* Inner Space deployed for something useful (e.g. tcpcrypt)
   –traverses most middleboxes, so reaches critical mass
   –can deploy integrity protection over TCP Data
   –(cannot protect Outer Options for consumer 
Internet today – would fail too often)
* raises stakes
   –then tampering with Inner Options will break comms,
   not just the theoretical potential benefit of a new option
* puts security middlebox designers on the back foot
   –blocking comms just 'cos options are non-typical will not sell
   –distinguishing attacks from the latest advances will sell

result
* mess with options and you shoot yourself in the foot

For full text, see
<https://tools.ietf.org/html/draft-briscoe-tcpm-inner-space-00#section-3.2.2>

>good example of why we need constraints for middleboxes.

It /is/ about constraining future middleboxes. 
But you have to provide something useful as well, 
to get it deployed. And that means getting thru today's middleboxes first.

It's fairly pointless trying to constrain 
deployment of middleboxes that are already deployed. That horse has bolted.

Bob

---

From: Joe Touch <[email-masked]>
Date: Mon, 27 Oct 2014 11:36:34 -0700

On 10/27/2014 11:05 AM, Bob Briscoe wrote:
> Nope. Here's a bulleted summary of the section in inner-space that
> explains why this could be a permanent stop on middleboxes, not just a
> step in an arms race. Of course, I can't predict for certain what the
> operators will buy, but this is a plausible argument:
...
> * mess with options and you shoot yourself in the foot

And, as now, we'll all start to worry about that and try to create a
mechanism that avoids letting middleboxes shoot themselves in the foot.
And the result will be TCP-in-TCP-in-TCP, as I noted originally.

We're both just guessing, but I see no reason to believe that "laws for
the lawless" ever ends up getting the lawless to obey the new laws.

Joe