Subject: Re: [saag] Fwd: fyi: tcpcrypt draft

From: Joe Touch <[email-masked]>
Date: Wed, 27 Jul 2011 14:59:39 -0700

Hi, Mark (et al.),

I'm cc-ing this to the TSVWG mailing list for the benefit of those 
attending TSVAREA, where the presentation will occur tomorrow AM.

Since this is the second IETF transport presentation (the first was in 
TCPM at IETF 80), I hope this presentation will clarify how the current 
tcpcrypt code uses the existing TCP option space.

In specific, it appears to use *two* unassigned TCP option codepoints 
(69 and 70), rather than experimental codepoints (and, IMO, it should 
use the latter instead).

I hope the presentation this time will address the plans to correct the 
currently deployed code to appropriately use the experimental codepoints.

Joe

---

From: Mark Handley <[email-masked]>
Date: Thu, 28 Jul 2011 13:15:48 -0400

On 27 July 2011 17:59, Joe Touch <[email-masked]> wrote:
> Since this is the second IETF transport presentation (the first was in TCPM
> at IETF 80), I hope this presentation will clarify how the current tcpcrypt
> code uses the existing TCP option space.
>
> In specific, it appears to use *two* unassigned TCP option codepoints (69
> and 70), rather than experimental codepoints (and, IMO, it should use the
> latter instead).

Hi Joe,

You're correct that our code is currently using two unassigned
codepoints, and we should not be doing so.  I've looked into what we
should do, and the problem is that there are deployed products using
the two experimental options.  We don't wish them to interfere with
our experiments, nor do we wish to interfere with their experiments.

But using unassigned ports is bad too.  I've talked with Wes and
David, and we're working on figuring out the least bad solution.  Wes
will raise the issue with the IESG, and we'll implement whatever they
decide is best.

 - Mark

---

From: Joe Touch <[email-masked]>
Date: Thu, 28 Jul 2011 11:04:39 -0700

On 7/28/2011 10:15 AM, Mark Handley wrote:
> On 27 July 2011 17:59, Joe Touch<[email-masked]>  wrote:

Hi, Mark,

It's hard to understand how these could interfere, since experiments are 
not supposed to be widely deployed. The only interference would be if 
theirs were widely deployed *and* yours were too, which means you're 
both using those codepoints inappropriately.

> will raise the issue with the IESG, and we'll implement whatever they

AOK. It'd be useful to note this in your talk, IMO.

Thanks,

Joe

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Thu, 28 Jul 2011 11:41:45 -0700

Is there any consideration to allocate more code points for TCP
experimental usage? With the increasing number of experimental TCP
drafts (some of which uses TCP  options), it would be useful thing to
extend the experimental TCP option space. Wondering whether this has
been brought up before?

-Anantha

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Joe Touch
> Sent: Thursday, July 28, 2011 11:05 AM
> To: Mark Handley
> Cc: [email-masked]; [email-masked]; tsvwg
> Subject: Re: [saag] Fwd: fyi: tcpcrypt draft
> 
> 
>

---

From: Joe Touch <[email-masked]>
Date: Thu, 28 Jul 2011 11:52:19 -0700

Hi, Anantha,

> extend the experimental TCP option space. Wondering whether this has

It has. In principle, the entire space can be used of the code is 
*ensured* to never leave the lab; these codepoints were assigned for safety.

IMO, nobody should EVER use an experimental codepoint without including 
a nonce that can be used to identify their use of that codepoint; that 
would prevent interference if (when) accidental deployment occurs.

Systems that intend to be widely deployed should get assigned 
codepoints, period. I personally think that posting code on a website 
for public use that includes experimental codepoints MUST NOT be 
tolerated (yes, that means that tcpcrypt code *needs* be taken down 
until this is resolved).

Joe