Subject: [tcpm] proposal for additional experimental-use option kind numbers

From: Wesley Eddy <[email-masked]>
Date: Tue, 16 Aug 2011 00:42:52 -0400

I would be interested in the WG's feedback on this proposal to
add more TCP option kind numbers designated for experimental-use:

http://www.ietf.org/id/draft-eddy-tcpm-addl-exp-options-00.txt

This would be intended to resolve the issue discovered with
tcpcrypt recently, which Joe brought up and Mark explained and
on the tsvwg list.

The idea is to simply provide more experimental-use numbers so
that this type of situation can be avoided, and to provide
enough that multiple simultaneous experiments are possible,
even if some of the new space happens to get accidentally
populated with shipping products again.

Particularly, I would like to know if there's WG consensus
that this approach to solving the problem is the way to go,
as I would hope this could be done by TCPM.

Thanks in advance.

-- 
Wes Eddy
MTI Systems

---

From: Joe Touch <[email-masked]>
Date: Mon, 15 Aug 2011 22:44:41 -0700

Hi, all,

I disagree with this proposal.

The two existing option values are more than sufficient. They can be used with a short nonce selected arbitrarily that should suffice to keep experiments distinct. The cost would be overhead and limited ability to be used with many other options concurrently outside of a closed test environment (where the nonce can be omitted). This overhead should be acceptable for experiments.

Any attempt to allocate additional numbers without use of this sort of nonce (which I had suggested for all such experimental option values, e.g., for the experimental port number codepoints) makes additional allocations continually necessary; if we assume this sort of nonce, the current pair of codepoints is more than sufficient.

In the meantime EVERYONE using the current codepoints in deployed products needs to be strongly encouraged to clean up the mess they've created. And anyone using non-experimental codepoints (tcpcrypt - I'm talking to YOU) needs to PULL THEIR CODE FROM THEIR DISTRIBUTION SERVER **NOW**.

If we're not going to do these last two things, let's just stop all this wasted effort and just not run a codepoint registry at all.

Joe

On Aug 15, 2011, at 9:42 PM, Wesley Eddy wrote:

> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Fernando Gont <[email-masked]>
Date: Wed, 24 Aug 2011 08:24:37 -0300

On 08/16/2011 02:44 AM, Joe Touch wrote:
> In the meantime EVERYONE using the current codepoints in deployed
> products needs to be strongly encouraged to clean up the mess they've
> created. And anyone using non-experimental codepoints (tcpcrypt - I'm
> talking to YOU) needs to PULL THEIR CODE FROM THEIR DISTRIBUTION
> SERVER **NOW**.

Without taking a stance with respect to the specific proposal and the
other issues being discussed, I'd argue that "the cat is out of the bag"
already.

So I don't think the aforementioned "clean-up" is feasible (not that I
like it, though).

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Joe Touch <[email-masked]>
Date: Wed, 24 Aug 2011 12:28:30 -0700

> So I don't think the aforementioned "clean-up" is feasible (not that I

That cannot be our approach. If it is, I *WILL* deploy code that uses 
all remaining option numbers in every protocol I can find, and we'll 
have none left for anyone. ;-)

Seriously, ERRORS ARE ERRORS - they don't define the de-facto standards. 
The standard is that these codepoints are not yet assigned, and those 
who use them need to STOP.

And - IMO - we as a community need to stop giving those who ignore our 
policies a mic at IETF meetings.

Joe

---

From: Tim Shepard <[email-masked]>
Date: Wed, 24 Aug 2011 16:02:18 -0400

> who use them need to STOP.

I don't believe the IETF or anyone else has any power to force anyone
to stop distributing anything.

In particular, anything that runs over IP can be done between
consenting end systems.

> policies a mic at IETF meetings.

You or anyone else are free to offer harsh criticism (which might be
appropriate here), but I think it is important that the IETF remain a
very open organization, with no particular overall policies on who
gets mic time.  (Though I do not object to empowering WG chairs to run
meetings in efficient ways.)

And we should do whatever makes sense going forward, without the
desire of some to punish or rebuke past bad behavior stopping us from
doing whatever makes good sense going forward.

BTW, with the way modern distributed version control systems work (and
the way "the net" works in many ways these days) there's no good way
to ever take anything back.  Git, for example, deliberately makes it
difficult to rewrite history.  (It is not impossible, but everyone
downstream can easily detect that upstream is attempting to change
history.  And it would be an unusual event.  IMHO this is a very good
thing.)

Instead of insisting that code be taken down, the more constructive
way forward is to offer a patch and convince as many people as
possible that the patch should be adopted.  And if you don't want to
develop the patch yourself, try to convince others to develop it, and
distribute it, and adopt it.  I don't think telling people to STOP
doing something that they find useful to do is likely to win them over.

(And I'm not sure a patch is even needed here, there may be an easier
 and simpler way forward.)

			-Tim Shepard
			 [email-masked]

---

From: Joe Touch <[email-masked]>
Date: Wed, 24 Aug 2011 13:07:27 -0700

On 8/24/2011 1:02 PM, Tim Shepard wrote:
...
>   and simpler way forward.)

Presuming you don't mean assigning the squatted numbers (which, again, I 
offer to gobble up if that's how things work), do you have a suggestion?

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 24 Aug 2011 14:58:20 -0700

On your other point...

> to stop distributing anything.

Force, no.

Shame, yes.

We also ought to have the power NOT to reward those who deliberately 
disobey what little rules we have.

> In particular, anything that runs over IP can be done between

Your rights end where mine begin, as with everything. Squatting on a TCP 
option number interferes with the assignment of that number to 
legitimate uses.

...
> doing whatever makes good sense going forward.

Please review the term "moral hazard".

If you don't address this past behavior, then others will follow. Like 
me, as I already suggested ;-)

We already had a similar debate on whether to assign the current TCP 
experimental option codepoints to a system that had been inappropriately 
deployed. Please review that discussion as well.

...
> possible that the patch should be adopted.

Sure. Let's all devote our spare time to fixing every bug in other 
people's experiments when they disobey our procedures.

Or - here's a new idea - why not ask (which I already did a few IETFs 
ago) them to fix their own mess? And if they don't, we ought to - as a 
community - demand better.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 24 Aug 2011 18:20:08 -0700

> policies a mic at IETF meetings.

To clarify this - I agree that our mic should be open to all parties 
that bring us ideas (time permitting).

However, I do feel that we have no obligation to *repeatedly* give time 
to promote ideas that violate Internet practices in ways that harm the 
rest of us. The first talk is fine, but once a serious issue is raised 
then that issue needs to be the *focus* of future discussion IMO.

This was not the case with the most recent presentation on tcpcrypt at 
TSVAREA in Quebec (which was presented previously at TCPM in Prague). 
The slot was 5 minutes in Prague; it was *40* in Quebec.

The slides do *not* indicate the TCP option number that they're 
squatting, or why they don't use the existing experimental codepoints. 
All the reasons they don't want to use the existing codepoints - BTW - 
are the same reasons nobody will want to use the codepoints they're 
squatting on.

Joe

---

From: Wesley Eddy <[email-masked]>
Date: Wed, 24 Aug 2011 22:18:20 -0400

> are the same reasons nobody will want to use the codepoints they're

I agree with you that it's not something that should be accepted.
In the long term, it's a harmful practice.

In the case of tcpcrypt, Mark did express regrets and admitted that
it was a mistake.  He needs to know what the right solution is to
correct it, and that's why we're having this discussion, I think.
I believe he expressed that his intention was to change to something
more acceptable that would also allow their experiment to work.  If
I'm wrong on this, Mark can correct me.

You and I have each proposed some potential solutions.

Here are pros and cons, as I see them.  Please correct if I
misunderstood your proposal (the "nonce approach"):

Summary of the nonce approach:
- use the 2 existing option kind numbers designated for experiments
- add a small "nonce" field to all options using these kinds to
   uniquely identify them

Advantages of nonce approach:
- no new kind numbers need to be allocated
- might allow new experiments to coexist with existing misuse of
   the 2 experimental kind numbers

Disadvantages of nonce approach:
- isn't the nonce really a "sub-kind" field?  If so, doesn't it
   need to be managed by IANA to avoid collisions?  This depends
   on how small the "small" nonce is.  If it's too small, then it
   needs to be coordinated in some way, or we have the same issue
- if the nonce isn't small, the already tight options space gets
   squeezed even more for these experiments; if you use multiple
   experimental options at once, you pay the tax multiple times
- protocols using this might need to remove the nonce if/when
   they transition away from just being an experiment
- depending on size of the nonce, alignment issues may cause
   extra space for padding to be burnt

Summary of draft-eddy-tcpm-addl-exp-options-00:
- allocate more experimental options

Advantages:
- quick, easy
- does not impinge on design/layout of options
- existing protocols that want to behave can do so right away by
   change of option kind
- avoids any potential conflict with deployed code misusing the
   existing experimental kinds
- compatible with nonce approach for people that want to use it

Disadvantages:
- burns some more option kinds (analyzed in draft, not really
   an issue, by my estimation)
- some danger of collision if lots of simultaneous experiments
   are running

I think figuring out how to advise the use of nonces is a better
long-term solution, but it does require a bit more thought to do
correctly and does involve additional "burden" for designers to use
it, so we need to think it out correctly.

I think to get something reasonable done in the short term (like
months) so that we have a reasonable solution for people, that the
draft-eddy-... approach is more likely to be able to be worked
quickly and applied in code.  I think it would be possible to do
that, and also work on specifying how to advise to use nonces in
parallel, which would "Update" it when published.

Thoughts?

-- 
Wes Eddy
MTI Systems

---

From: [email-masked] (Christos Zoulas)
Date: Thu, 25 Aug 2011 03:05:02 -0400

On Aug 24, 12:28pm, [email-masked] (Joe Touch) wrote:
-- Subject: Re: [tcpm] proposal for additional experimental-use option kind	n

| That cannot be our approach. If it is, I *WILL* deploy code that uses 
| all remaining option numbers in every protocol I can find, and we'll 
| have none left for anyone. ;-)
| 
| Seriously, ERRORS ARE ERRORS - they don't define the de-facto standards. 
| The standard is that these codepoints are not yet assigned, and those 
| who use them need to STOP.

I agree with you but there needs to be a procedure on how to do
this instead of fuming in mailing lists. Is there an official
channel we can notify the abusers via regular mail (getting lawyers
involved) to stop doing that? Giving them time to apply for proper
allocations and if approved, shift to them? What power does IETF
have to stop the abusers, and if not IETF then who?

christos

---

From: Lars Eggert <[email-masked]>
Date: Thu, 25 Aug 2011 10:10:17 +0300

> have to stop the abusers, and if not IETF then who?

One approach is to mark code points that are used without proper IANA assignment in the IANA registries, naming the companies or organizations involved and making very sure that the language used is clear that this is highly inappropriate.

Lars

---

From: Joe Touch <[email-masked]>
Date: Thu, 25 Aug 2011 09:16:35 -0700

Hi, Wes,

On 8/24/2011 7:18 PM, Wesley Eddy wrote:
...
> correct it, and that's why we're having this discussion, I think.

Step 1 - pull the code off the website. See below for further impact.

...
> extra space for padding to be burnt

The nonce should be at least 32 bits, and I would think that would be 
sufficient. It can then be selected either randomly or by the user via, 
e.g., systime() when the experimenter wants to self-assign a value.

I'm willing to bet that this is sufficient for a while ;-) If a registry 
is desired, experimenters can verify their chosen value is 
collision-free and provide a pointer to IANA. IANA would just accept 
values FCFS.

A 32-bit nonce cannot be an impediment to a serious experiment, since we 
need to expect that experiments are never the only option in use, and 
that they would never consume ALL remaining option space. Even the 
smallest options consume 2 bytes, so this allows at least two more 
options beyond the experiment, which is a reasonable expectation IMO.

In fact, here's what I'd propose:

     +--------+--------+--------+--------+
     |  KIND  |  LEN   |   (available)   |
     +--------+--------+--------+--------+
     |               NONCE               |
     +--------+--------+--------+--------+
     |  (available - con't if needed)... |

This is 32-bit aligned, and already provides 2 bytes for experiments. 
Implementations MUST check the NONCE *first* before examining any 
available space before or after the NONCE.

IF there is concern that the existing two codepoints (255, 254) are 
'tainted' by the Cisco/Juniper/Alcatel deployed proposed TCP 
authentication alternative, then we can assign two more codepoints, and 
declare that they MUST use nonces.

> - some danger of collision if lots of simultaneous experiments

This provides a hazard that just kicks the problem down the road. If 
nonces aren't required now, then the options assigned this way are 
tainted exactly as are 255/254 (and Mark has tainted 69/70).

> it, so we need to think it out correctly.

I can't see the complexity here; see above.

> months) so that we have a reasonable solution for people,

Anyone who is *serious* about this problem would take down code that 
needed fixing, or just shift to using the existing experimental 
codepoints (255/254), rather than putting the onus on us to find a quick 
fix.

> that the

See above; we can't UPDATE tainted option values. Once we cannot control 
the nonce field values (e.g., when they contain a MAC), the option 
values are dead.

I don't think we should be assigning MORE options that we know are going 
to die. Time to fix this, and I think the nonce solution is VERY simple.

Joe