Re: [middisc] TCP middlebox option requirements

[Andrew Knutsen <[e-mail]>]

    Just out of curiosity, what advantage to the PEN's have over OUI's?  
Perhaps that they're easier to get?

     If we do use PEN's, I'd suggest using the same three bytes we're 
using for the OUI now.  Or, we could make a three-byte PEN an 
alternative to the OUI, using vendor 0xFE for example.

    In any case, I think the single-byte vendor code alternative is 
still a necessity given the crowding  in SYN packets. I expect most 
"stakeholders" here plan on using that alternative.

    I'm hoping the inclusion of either a vendor code or a standard type, 
combined with minimal requirements on what the option is used for in an 
RFC, will be sufficient to discourage misuse.

Andrew

On 5/24/2011 7:22 AM, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] 
wrote:
> Hi David, PENs are a good thought in comparison to OUIs for this purpose.
>
> I don't speak for the authors, but we have to be a bit sympathetic to the fact that there is only very limited amount of space available for TCP options and burning 32-bits for an enterprise number is going to eat away considerably from the space available to do something useful.
>
> Personally, I would have no problem seeing a compact mechanism that's just big enough to allow expandability to some double-digit multiple of the number of current vendors, and also support falling back to using either a full Private Enterprise Number or an OUI once the more compacted space is exhausted.
>
>
> ________________________________________
> From: David Harrington [[e-mail]]
> Sent: Tuesday, May 24, 2011 9:13 AM
> To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]; 'Ron Frederick'; 'Mark Day'
> Cc: [e-mail]; 'David Harrington'
> Subject: RE: [middisc] TCP middlebox option requirements
>
> Hi,
>
> I also have no skin in this game. and I'm looking at this list after
> months of ignoring it, so I'm way behind in the discussions.
>
> I am concerned that unless severely limited in what it can be used
> for, this will lead to other vendor-specific options.
> Whether that is good or bad I'll leave to other people to decide, such
> as my co-area director Wes, the IETF community and the IESG that will
> need to approve any document produced as a result of this discussion.
>
> I will observe that many IETF protocols developed for a limited use
> "escape into the wild". This happens ofetn when people decide to
> develop a weak or non- security solution and claim it will be only be
> used within an enterprise, but it then gains use in the Internet. I
> don't know if there is anything you can do to prevent this from
> becoming a generic option for vendor-specific features if you design
> in a vendor code. The best way to avoid that is to reach agreement on
> a standard that does not include a vendor code (which means accepting
> that your current products continue to not be compliant to the new
> standard).
>
> If you do have vendor-specific options, it will be important to make
> sure that each vendor is uniquely identified, so we don't have two
> vendors fighting over a vendor code. I recommend registering vendor
> codes with IANA to make sure this doesn't happen.
>
> IANA already maintains an Enterprise Number registry that is used for
> many IETF standards. It is a widely used ***standard*** in IETF
> standards for identifying vendors using a code number.
> http://www.iana.org/assignments/enterprise-numbers.
>
> Maybe you can convince the IESG that having another set of codes to
> identify vendors is important, and that a given vendor will likely
> have a different code in your vendor code list than that used by other
> standards. It doesn't sound very convincing to me.
>
> If expansion CAN take place in the future, and now you need 0xff plus
> an OUI, you will also have added complexity to TCP, requiring suppoort
> for one-byte vendor codes plus OUI support. and you will have added a
> new list of vendor codes (whether maintained by IANA or not), and
> you'll need to convince IESG all this extra complexity is justified.
>
> I recommend you consider simply using an existing IETF standard
> registry already supported by IANA, such as Enterprise Numbers, for
> your vendor codes. OR don't support vendor codes at all, and agree on
> a single standard.
>
> David Harrington
> Director, IETF Transport Area
> [e-mail] (preferred for ietf)
> [e-mail]
> [phone] (cell)
>
>
>> -----Original Message-----
>> From: [e-mail]
>> [mailto:[e-mail]] On Behalf Of Eddy, Wesley
>> M. (GRC-MS00)[ASRC AEROSPACE CORP]
>> Sent: Thursday, May 27, 2010 12:53 PM
>> To: Ron Frederick; Mark Day
>> Cc: [e-mail]
>> Subject: Re: [middisc] TCP middlebox option requirements
>>
>>> -----Original Message-----
>>> From: [e-mail] [mailto:[e-mail]] On
>>> Behalf Of Ron Frederick
>>> Sent: Thursday, May 27, 2010 12:44 PM
>>> To: Mark Day
>>> Cc: [e-mail]
>>> Subject: Re: [middisc] TCP middlebox option requirements
>>>
>>> ...
>>>
>>> If this is really the case, it would be a mistake to limit the
> total
>>> number of type codes across all vendors to 256. We'd basically be
>>> repeating the mistake that led to this effort in the first
>> place, where
>>> TCP options as a whole have a space of 256 options and we're
>> currently
>>> using multiple of those to solve this problem.
>>
>> I don't have skin in the game, but on reading this thread, my
>> thought was that it's probably possible to use a single byte,
>> but define one codepoint (like 0xFF) to mean "use a full OUI
>> which follows".  This way you can start with using a single
>> byte given the relatively small number of vendors today, and
>> have a way to accommodate larger numbers in the future, if
>> the need arises.
>>
>> This only works if the means of extending to a full OUI is
>> part of the base specification and everyone has to support
>> it, otherwise there are backwards-compatibility issues when
>> someone tries to use it in the future.
>>
>> --
>> Wes Eddy
>> MTI Systems
>>
>>
>> _______________________________________________
>> middisc mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/middisc
>>
> _______________________________________________
> middisc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/middisc