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

Bob Briscoe <bob.briscoe@bt.com> Mon, 27 October 2014 18:05 UTC

Message-ID: <201410271805.s9RI5EIs016509@bagheera.jungle.bt.co.uk>
Date: Mon, 27 Oct 2014 18:05:06 +0000
To: Joe Touch <touch@isi.edu>
From: Bob Briscoe <bob.briscoe@bt.com>
In-Reply-To: <54455A68.9040708@isi.edu>
References: <201410200058.s9K0wQnS014207@bagheera.jungle.bt.co.uk> <54455A68.9040708@isi.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/D96_8Xvdn9CG_baJWhN60J-AafA
Cc: tcpm IETF list <tcpm@ietf.org>
Subject: Re: [tcpm] More option space on any segment: draft-briscoe-tcpm-inner-space-00 (was syn-op-sis-02)
Precedence: list

Joe,

At 18:54 20/10/2014, Joe Touch wrote:

>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.
> >
> > I believe the new Inner Space protocol could be a significant advance
> > for TCP.
>
>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.

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>

>IMO this whole exercise is a significant step backwards, except as a
>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

>Joe

________________________________________________________________
Bob Briscoe,                                                  BT

[tcpm] More option space on any segment: draft-br… Bob Briscoe
Re: [tcpm] More option space on any segment: draf… Joe Touch
Re: [tcpm] More option space on any segment: draf… Bob Briscoe
Re: [tcpm] More option space on any segment: draf… Joe Touch