Subject: Re: [middisc] TCP middlebox option requirements

From: "David Harrington" <[email-masked]>
Date: Tue, 24 May 2011 09:13:19 -0400

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
[email-masked] (preferred for ietf)
[email-masked]
+1 603 828 1401 (cell)

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] 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: [email-masked]
> Subject: Re: [middisc] TCP middlebox option requirements
> 
> >-----Original Message-----
> >From: [email-masked] [mailto:[email-masked]] On
> >Behalf Of Ron Frederick
> >Sent: Thursday, May 27, 2010 12:44 PM
> >To: Mark Day
> >Cc: [email-masked]
> >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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/middisc
>

---

From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[email-masked]>
Date: Tue, 24 May 2011 09:22:35 -0500

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 [[email-masked]]
Sent: Tuesday, May 24, 2011 9:13 AM
To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]; 'Ron Frederick'; 'Mark Day'
Cc: [email-masked]; 'David Harrington'
Subject: RE: [middisc] TCP middlebox option requirements

Hi,

David Harrington

total

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Tue, 24 May 2011 09:03:29 -0700

Hi David,

> 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: [email-masked]

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.

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

> http://www.iana.org/assignments/enterprise-numbers.

Good to know.

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

> 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

---

From: Andrew Knutsen <[email-masked]>
Date: Tue, 24 May 2011 13:30:41 -0700

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]

---

From: Andrew Knutsen <[email-masked]>
Date: Tue, 24 May 2011 13:33:50 -0700

Anantha, what do you see as the advantage of adding a sub-type to 
the type code, which follows the vendor ID?

Andrew

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Tue, 24 May 2011 13:46:40 -0700

Andrew,
     My primary motivation here was to accommodate other possible use
cases and at the same time be very sensitive to TCP option bits. Hence I
thought we could sub-divide the vendor field into 2 pieces. Instead of
having 8 bits for vendor type and another 8 bits for sub-type. We could
also have something like if the MSB is set, then it is WAN opt option,
what follows is vendor information, if 0 it can be used for other
things. 
    Also to paraphrase what I said earlier : if we want to restrict this
TCP option allocation proposal's scope to middlebox WAN optimization use
case alone, I am fine with that too.
-Anantha

> From: Andrew Knutsen [mailto:[email-masked]]
> Sent: Tuesday, May 24, 2011 1:34 PM
> To: Anantha Ramaiah (ananth)
> Cc: David Harrington; Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP];
> Ron Frederick; Mark Day; [email-masked]
> > option goes, there are a very handful of vendors today and
allocating
> a

---

From: Andrew Knutsen <[email-masked]>
Date: Tue, 24 May 2011 13:56:51 -0700

If you don't need a vendor code, that means its a standard type, 
which has vendor ID 0 in the current proposal.

Andrew

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Tue, 24 May 2011 14:02:07 -0700

That may be ok, but the issue is, we are using 1 byte (vendor ID = 0)
for explicitly stating that it is a standard type and there can be need
for multiple standard types and then one needs to have sub-type to cater
to multiple use cases. IMO, this is wastage of TCP option bits.

-Anantha

> Sent: Tuesday, May 24, 2011 1:57 PM
> >>>> develop a weak or non- security solution and claim it will be
only
> >> be
> >>>> in a vendor code. The best way to avoid that is to reach
agreement
> >> on
> >>> to have a section (applicability section ) which exactly spells
out
> >> the
> >>> multiple vendors already have WAN opt options and it is non-goal
of
> >> this
> >>> 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
> >>>> for one-byte vendor codes plus OUI support. and you will have
> added
> >> a
> >>> other use cases like the above. But this is something we want to
do
> >> if
> >>> To make things clear I am talking about the following format
(which
> >> was
> >>> option goes. The point here is putting the OUI information is up
to
> >> the
> >>> generic as possible so that multiple vendors requirements
> (currently
> >> as
> >>>> your vendor codes. OR don't support vendor codes at all, and
agree
> >> on
[mailto:[email-masked]]
> >> On

---

From: Andrew Knutsen <[email-masked]>
Date: Tue, 24 May 2011 14:44:49 -0700

I also think having a full 0 byte for standard types is wasteful.  
So what you're suggesting is using the vendor byte for three bits of 
standard type or 5 bits of vendor ID, right?  And if there is a 33rd 
vendor, they have to use the 24-bit ID?

    Two alternatives have occurred to me:

     - A bit in the vendor byte, indicating whether the byte is a vendor 
or a standard type.  Both get 7 bits.  The objection to this was it 
might be hard to parse in hardware.

     - Allocating standard types out of the same 8-bit space as the 
vendor IDs.

Andrew

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Tue, 24 May 2011 15:09:55 -0700

> Sent: Tuesday, May 24, 2011 2:45 PM
> standard type or 5 bits of vendor ID, right?  

Yes.

> And if there is a 33rd vendor, they have to use the 24-bit ID?

My feeling is that there won't be 33 vendors doing WAN opt solutions and
the need to do option insertion for the same purpose.

> or a standard type.  Both get 7 bits.  

This is what I meant below when I mentioned MSB for demux.

> The objection to this was it might be hard to parse in hardware.

Agreed, I thought about that as well.

>      - Allocating standard types out of the same 8-bit space as the

Well even then you need to sub-divide the space otherwise how else you
would distinguish between them. 

-Anantha

> >>>        My primary motivation here was to accommodate other
possible
> >> use
> >>> thought we could sub-divide the vendor field into 2 pieces.
Instead
> >>>       Also to paraphrase what I said earlier : if we want to
> restrict
> >> this
> >>> TCP option allocation proposal's scope to middlebox WAN
> optimization
> >> use
> >>>>       Anantha, what do you see as the advantage of adding a sub-
> type
> >> to
> >>>>>> 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
> >>>>>> used within an enterprise, but it then gains use in the
> Internet.
> >> I
> >>>>> I agree with your concerns in the above paragraph and I am sure
> we
> >>>> need
> >>>>> 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
> >>>>>> IANA already maintains an Enterprise Number registry that is
> used
> >>>> for
> >>>>>> Maybe you can convince the IESG that having another set of
codes
> >>>>>> have a different code in your vendor code list than that used
by
> >>>> other
> >>>>> we have an handful of vendors ( I suspect this number to grow
for
> >>>>>> If expansion CAN take place in the future, and now you need
0xff
> >>>> plus
> >>>>> there is a consensus, at the minimum the goal of this effort is
> to
> >>>> get a
> >>>>>     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
> >>>>> |
|
> >>>>> |
|
> >>>>> This gives vendor codes 5 bits which is more than enough as far
> as
> >>>> this
> >>>>> vendor and that belongs to the vendor specific metadata. All
that
> >> is
> >>>>> required is a type code for middlebox option and have this
format
> >>>>>>>> number of type codes across all vendors to 256. We'd
basically

---

From: Andrew Knutsen <[email-masked]>
Date: Tue, 24 May 2011 15:37:44 -0700

> would distinguish between them.

    No need to; interpretation of the rest of the option depends on that 
code, whichever sort it is.

Andrew

---

From: "Frederick, Ron" <[email-masked]>
Date: Sat, 28 May 2011 20:35:31 +0000

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

Choosing to go with the OUI instead of a PEN here was mainly because OUIs only took 24 bits of space rather than 32 bits. which is the my understanding of the intended size of a PEN. However, even 24 bits was more than we wanted to pay in most cases, and that's what led to the different variants of the option, where the OUI was only used as a fallback.

If there are still objections to using a full byte for vendor code (due to this "wasting" a byte for standard options), I would propose one of the following:

- Allow standard type codes to be allocated starting with 0x00, in an increasing fashion and allow vendor codes to be allocated starting with 0xFE in a decreasing fashion. At some point, if it looks like too many vendor codes are being allocated, IANA can declare that no more are available and that additional vendors must use the 0xFF form with an OUI, leaving the remainder of the space for standard type codes.

or

- Allow both standard type codes and vendor codes to just be allocated in an increasing fashion from 0x00. As Andrew noted, the code determines everything about how to interpret the rest of the payload, so there's really no difference between the two from a decoding perspective.

Either way, I would want to see a rule that IANA would only ever allocate one single-byte vendor code to any vendor and it would be up to that vendor to allocate any necessary additional bits or bytes in the payload as needed to support multiple option types. If a vendor failed to plan ahead in this regard, they would need to either rework their options later to adjust for this or to allocate additional options using the 0xFF variant with their OUI.
-- 
Ron Frederick
[email-masked]