Re: [tcpm] draft-ietf-tcpm-experimental-options

Hi, Jamshid,

On 2/22/2013 12:54 PM, Mahdavi, Jamshid wrote:
...
> The draft claims that experimental TCP options are
>
>            “intended to be used both in controlled environments and in
> are allowed in public deployments (when not enabled as default) [RFC3962]”
>
> (Side note:  typo “in”, and the citation is wrong, it should be 3692.)

Those are part of pending updates.

> However, that goes against other documentation – for example these
> statements in 3692:
>
> “Mutually consenting devices could use these numbers for whatever
> purposes they desire, but under the understanding that they are reserved
> for generic testing purposes” (i.e. not for production use)
>
> “They are not intended to be used in general deployments or be enabled
> by default in products or other general releases.”  (my reading of that
> has always been, “not intended for use in the public Internet”)

The key is the term "default". I.e., they are allowed in general 
releases if not enabled by default.

> And, on the IANA assigned numbers:
>
> “RFC3692-style Experiment 1 (also improperly used for shipping
> products)” – clearly implying these are not intended for use in
> commercial products.

Not by default. But having them available where users can turn them on 
causes the same problem.

> Finally, the draft itself implies the experimental option usage is still
> intended to be temporary in the discussion “Migration to Assigned Options”.

That's correct. The goal would be for experiments with sufficient 
experience that are sufficiently warranted to justify assignment of 
permanent TCP option codepoints.

> (Another side note:  I’d have concerns about implementing the proposed
> migration mechanism in practice due to the creation of extra connections
> which would just be dropped.)
>
> In the absence of a better solution, a vendor may find using an
> experimental option to be preferable to squatting somewhere else in the
> option space, but this draft in its current form does not really appear
> to change any of the underlying rules which suggest experimental options
> are not intended for this type of use.
>
> One other suggestion for the draft:  it might merit a word or two in the
> security considerations how this draft might affect the firewall
> processing of TCP options 253 and 254.

I can add that.

> Having the IANA registry
> suggested elsewhere in the thread would actually help firewalls to have
> better visibility into the contents of these options to be more
> selective about what to allow.

The IANA registry would help firewalls only if they parsed inside TCP 
options; is that remotely likely?

Joe

>
> --Jamshid
>
>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>