Subject: [tcpm] AD review of draft-ietf-tcpm-experimental-options

From: Wesley Eddy <[email-masked]>
Date: Wed, 14 Nov 2012 00:48:12 -0500

Hi, I'm doing AD review of the draft on Shared Use of Experimental
TCP Options.

It's in basically good shape, and I would like to get it processed
quickly, especially since people are starting to use it.

Section 3.2 (Migration to Assigned Options) still bothers me a bit
though.  It mentions that we expect options going from Experimental
to Standards Track will get a real option number, yet says:

   The updated protocol specification SHOULD recommend that
   implementations intended to be backward-compatible with experimental
   deployments MUST support both the experimental codepoint/magic
   number and assigned codepoint variants of the option.

But, this would seem to really pollute the SYN, since you would have
to put both flavors of option in the SYN to negotiate use of either
the new Standards Track one or the old Experimental one.

This needs to be discussed and addressed.  I'm not sure we're giving
very good / clear guidance here, or being very honest about the
tradeoffs involved in moving to a new codepoint when going to Standards
Track.

Also, I think we'd heard that the Experimental codepoints were being
used by an earlier middlebox discovery mechanism too (not just by the
AO precursor), which might bear mention in the introduction.

The document mentions inappropriately used option numbers in the
Introduction, and that this could cause dangerous collisions that
could be mitigated via use of magic numbers.  Yet, 3.2 says:

   Once a specific TCP option codepoint is assigned to a protocol,
   that protocol SHOULD NOT continue to use a magic number as part of
   that assigned codepoint.

So, we're advising them not to be robust to option squatting then?  I
know this doc is supposed to be focused on use of 253/254, but it does
mention the inappropriate use of other numbers as well, and seems to
give conflicting guidance.  The magic number just seems to be useful
all-around for robustness in the face of currently unknown bad actors.

-- 
Wes Eddy
MTI Systems

---

From: Joe Touch <[email-masked]>
Date: Tue, 13 Nov 2012 23:18:58 -0800

Hi, Wes,

> the new Standards Track one or the old Experimental one.

The intent was to support both variants in the receiver processing 
during any overlap period, not to put both in the SYN.

> tradeoffs involved in moving to a new codepoint when going to Standards

One possible solution is for the sender is to use the assigned option 
and wait for it to be confirmed; if it is not, it might retry with the 
experimental variant in a separate SYN.

However, this doc is not intended as a study in all possible tradeoffs 
in the various ways to transition from experimental to standards-track 
codepoints. That appears to be an open field of research for which we do 
not have clear recommendations.

> AO precursor), which might bear mention in the introduction.

We continue to hear about misuse of experimental codepoints (being 
deployed operationally). We can note that such misuses are likely to 
continue.

> all-around for robustness in the face of currently unknown bad actors.

This doc is about the use of the experimental options. Recommendations 
on best practices for assigned codepoints don't seem to be in scope.

However, we definitely do NOT want to encourage continued use of magic 
numbers once codepoints are assigned. Option space is far to small for 
every option to use this technique forever.

Joe

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Wed, 14 Nov 2012 19:30:12 +0100

> > though.  It mentions that we expect options going from 
> Experimental to 
> > Standards Track will get a real option number, yet says:
> >
> The intent was to support both variants in the receiver 
> processing during any overlap period, not to put both in the SYN.

As document sheperd, that was my understanding of that section as well, esp. in the context of the previous section. But maybe we could add some explicit discussion regarding SYNs to "Once a specific TCP option codepoint is assigned to a protocol, that protocol SHOULD NOT continue to use a magic number as part of that assigned codepoint." 

> > tradeoffs involved in moving to a new codepoint when going to 
> > Standards Track.
>
> One possible solution is for the sender is to use the 
> assigned option and wait for it to be confirmed; if it is 
> not, it might retry with the experimental variant in a separate SYN.

This certainly works for a new connection to the same destination, i.e., destination caching. 

Out of my head, I wonder if this would indeed work for the first connection for which the sender has already seen the SYN-ACK?
 
> However, this doc is not intended as a study in all possible 
> tradeoffs in the various ways to transition from experimental 
> to standards-track codepoints. That appears to be an open 
> field of research for which we do not have clear recommendations.

If that is not cleam maybe we could state more explicitly, e. g., in "This document does not require a specific migration plan..."?

I am not a native speaker, but maybe "require" could be replaced by another word?

> We continue to hear about misuse of experimental codepoints 
> (being deployed operationally). We can note that such misuses 
> are likely to continue.
> 
> This doc is about the use of the experimental options. 
> Recommendations on best practices for assigned codepoints 
> don't seem to be in scope.

I think TCPM discussions focused on 253/254.

Other codepoints would imply a much larger scope. I recall community feedback that it should be possible to get and use dedicated codepoint without implementing this draft (provided that the IESG assigns the codepoint). Thus, recommending magic numbers for other codepoints might require further discussions in TCPM.

> However, we definitely do NOT want to encourage continued use 
> of magic numbers once codepoints are assigned. Option space 
> is far to small for every option to use this technique forever.

+1

Michael

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

---

From: Joe Touch <[email-masked]>
Date: Thu, 15 Nov 2012 12:41:41 -0800

Hi, Michael, et al.,

> As document sheperd, that was my understanding of that section as well, esp. in the context of the previous section. But maybe we could add some explicit discussion regarding SYNs to "Once a specif…

Certainly.

> This certainly works for a new connection to the same destination, i.e., destination caching.

Yes, but it also implies that either the TCP layer (unlikely) or the app 
retries the second connection with the different configuration. I doubt 
that will be desirable.

I generally assume that any assigned codepoint might work as if the 
experiment never happened - i.e., use that new codepoint only, and 
expect the endpoint to use it too.

So there are two cases:

- an endpoint speaks only the old (experimental) variant, at which point 
it uses the experimental codepoint with the magic number

- an endpoint speaks the new variant, at which point it uses the new 
codepoint (without the magic number)

An implementation might support b
oth modes, but an application would more likely pick just one to try. 
I.e., the implementation can support "legacy" use of the experimental 
codepoint/magic number if desired.

IMO, we should shy away from proposing untested mechanisms for trying 
alternates of a single option.

> Out of my head, I wonder if this would indeed work for the first connection for which the sender has already seen the SYN-ACK?

See above; let's not propose new untested mechanism.

> I am not a native speaker, but maybe "require" could be replaced by another word?

This document does not imply or indicate that specifications defining 
TCP options that use the experimental codepoints with magic numbers need 
to include a migration plan.

> I think TCPM discussions focused on 253/254.

This document focuses on TCP 253/254.

> Other codepoints would imply a much larger scope. I recall community feedback that it should be possible to get and use dedicated codepoint without implementing this draft (provided that the IESG a…
The approach in this doc could be useful elsewhere, but may not be 
needed elsewhere. It makes some assumptions (that the option space is 
limited and that the option fields can support the insertion of a magic 
number). Those assumptions may not be important elsewhere.

---

From: Joe Touch <[email-masked]>
Date: Wed, 28 Nov 2012 13:24:37 -0800

Hi, all,

I have updated a new version (03) draft based on AD review and Apps 
review as follows. It should show up in the usual places shortly.

Please let me know if this addresses your concerns, or if anyone has any 
other feedback.

Thanks,

Joe

---------------------------------------

AD review:

1) reorganized the sections
	split section 3 into separate first-level sections
	inserted subsections in section 3 to clarify the discussion

2) revised the discussion of migration to assigned options
	the current text is intended to be agnostic to
	a specific solution, but to make recommendations on
	what NOT to do

3) cleaned up the wording in many places, esp. the RFC2119 recommendations

Apps review:

4) added an explanation of the use of experimental codepoints vs. 
Experimental RFCs in the intro

5) cleaned up the discussion of collisions in section 4

------------------------