Re: [middisc] TCP middlebox option requirements

["Anantha Ramaiah (ananth)" <[e-mail]>]

Hi David,

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of David Harrington
> Sent: Tuesday, May 24, 2011 6:13 AM
> To: 'Eddy,Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]'; 'Ron Frederick';
> 'Mark Day'
> Cc: [e-mail]
> 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).

This thread has been quiet for sometime and last week I had sent an
email describing the current status and the steps moving forward to
reach consensus.
I agree with your concerns in the above paragraph and I am sure we need
to have a section (applicability section ) which exactly spells out the
scope of the middlebox option, caveats etc.,  I am afraid this is best
that can be done, we can talk and debate about it but the reality is
multiple vendors already have WAN opt options and it is non-goal of this
effort to interoperate among vendors.

> 
> 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.

Actually I had asked this question (about IANA managing the vendor
codes) earlier in this thread. It sounds very useful to me.

> 
> 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.

Good to know.

> 
> 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.

One of the issues is the limited space of TCP options currently
available,  having a standard vendor code would cause it to eat more TCP
option space which would impact the usability of this option. Given that
we have an handful of vendors ( I suspect this number to grow for the
use case of WAN optimization anytime), it is probably ok to go ahead
with a shorter vendor code point.

> 
> 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.

Actually sometime back I had mentioned the other use cases like the
following draft by Dan Wing :-
http://tools.ietf.org/html/draft-wing-nat-reveal-option-01

Actually it would be expedient to make the middlebox  option extensible
to accommodate use cases like the above. As far as the WAN optimization
option goes, there are a very handful of vendors today and allocating a
whole byte is overkill and we can sub-divide that portion to accommodate
other use cases like the above. But this is something we want to do if
there is a consensus, at the minimum the goal of this effort is to get a
TCP option for WAN optimization allocated. (which is the original
intent)

To make things clear I am talking about the following format (which was
one of the choices listed which the group came up with)
Case 3:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Opt kind=TBD  |    Opt len    | sub-type + Vendor  |          |
+---------------+---------------+--------------------+----------|
|                                                               |
| ...Optional vendor payload data dependent on vend typecode... |
|                                                               |
+---------------+---------------+---------------+---------------+

In the above we have a option sub-type which can be 3 bits long :-

000 - WAN opt.
001  - NAT reveal

This gives vendor codes 5 bits which is more than enough as far as this
option goes. The point here is putting the OUI information is up to the
vendor and that belongs to the vendor specific metadata. All that is
required is a type code for middlebox option and have this format as
generic as possible so that multiple vendors requirements (currently as
we speak there is Bluecoat, Riverbed, Cisco and maybe Citrix)

Adding Dan in the loop.

-Anantha
> 
> 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