Re: [middisc] TCP middlebox option requirements

[Andrew Knutsen <[e-mail]>]

    I agree with your concern about terminology.  I just spent about 6 
months trying to get this past TCPM, and although the word "tunnel" 
didn't raise (many) hairs, the idea of spoofing sure did...  And of 
course transparent tunnels, like proxies, are spoofed (more than once if 
the customer doesn't even want to see tunnels on their network ;-).  
Funny thing is I bet almost everyone on that list uses spoofed 
connections every day.  Its not our job to help them with their denial 
though.

    If you think we should use the current draft as a starting point, 
please let us know if you think any part of it is "problematic". I had 
to make it somewhat explicit in some areas to give folks on the list 
some context, but we don't have to keep it all.  I don't have a problem 
with adding the "maintaining communication" text.

Andrew

Mark Day wrote:
>
> Specifying a single-byte vendor code, with some reserved "standard" 
> value(s) of that byte, sounds good.  I also agree that we need to 
> define what this is intended for so it doesn't become the all-purpose 
> option.
>
>  
>
> As a practical matter the "t-word" (tunnel) may be problematic. Any of 
> you who are not exposed to the competitive side of this market may 
> find it mind-boggling, but there has been a lot of thrashing around on 
> the topic of whether tunnels are evil and whether a given product does 
> or doesn't use tunnels.  (Some of this has involved misunderstanding 
> or mischaracterizing other vendors' products).  Accordingly it seems 
> unwise to write a high-level generic statement of purpose in terms of 
> establishing or maintaining "tunnels".
>
>  
>
> Can we say instead that this option is about discovering some other 
> middlebox and maintaining communication with that discovered middlebox?
>
>  
>
> --Mark
>
>  
>
>  
>
> *From:* Andrew Knutsen [mailto:[e-mail]]
> *Sent:* Tuesday, May 25, 2010 8:28 PM
> *To:* Mark Day
> *Cc:* [e-mail]; Ron Frederick; Qing Li
> *Subject:* Re: [middisc] TCP middlebox option requirements
>
>  
>
>
>     It seems to me that if we do limit our goal here to agreeing on an 
> option number and vendor ID scheme, we haven't really limited 
> ourselves to autodiscovery except in the requirements we state for 
> getting a vendor ID (ie, agreements on use). Mostly this would involve 
> removing the requirement that the option only be present with the SYN 
> bit. We added this requirement primarily due to concerns about 
> reliable transmission, but in later discussions we came up with a 
> midstream discovery requirement and mechanism where that isn't an 
> issue, so I don't think we're particularly attached to it. Also, we 
> probably don't have to require everyone to encode the vendor-specific 
> type information in the same way.
>
>    Another implication of that goal is that we wouldn't be making a 
> standard per se; rather we'd be making a first step towards a set of 
> standards.  Thats the purpose of the "P" bit in the current proposal, 
> and the "standard vendor" codes in the proposal for removing the OUI 
> in my message below. The idea is that as the technology matures, we 
> can move towards a standard mechanism.
>
>    I'm not familiar with IPv6 options, but at this point what we're 
> doing sounds so simple it should work.
>
>    I'm getting the impression that to make this alternate option 
> useful to everyone here, we have to change the proposal in a few ways, 
> including:
>
>     1) Removing the OUI, and having a single byte of vendor code. The 
> option format would be vendor-specific.
>     2) Replacing the P bit with a "standard" vendor code or codes -- 
> perhaps one code per interoperable option format.
>     3) Removing the requirement that the option only be present with 
> the SYN bit set.
>     4) It sounds like the R bit may be redundant with other, more 
> complex schemes already implemented by some vendors.
>
>     This would mean the option format would only specify a single byte 
> of vendor ID after the option length. We would need some stipulations 
> on the option's use (making and maintaining tunnels, perhaps). Vendors 
> would have to agree to these stipulations to get a code, so we aren't 
> making a "catch-all" option.
>
>     Opinions?
>
> Andrew
>
> Mark Day wrote:
>
> Two additional issues seem worth clarifying since I'm not sure how others would view them.
>  
> 1. Are we concerned strictly with autodiscovery options, or are we attempting to understand the requirements for options usage generally among current symmetric middleboxes?  For example, Riverbed uses a different option for some forms of addressing information in situations after the two communicating peers have been established by autodiscovery.  It wouldn't surprise me to learn that other vendors have other similar schemes.
>  
> 2. Don't we also need to consider requirements for autodiscovery options in IPv6 environments?  
>  
> In both cases, I can see a pragmatic argument for focusing narrowly vs. an architectural argument for considering broader issues. IPv4 autodiscovery is the clear existing interoperability/coexistence problem and may be solvable by simply agreeing on an option number and vendor id scheme, while the other areas might not yet have enough experience and implementations to justify a standard.  And yet it feels to me like we might solve one option-related problem just to trip across another similar one soon afterward.
>  
> --Mark
>  
> -----Original Message-----
> From: [e-mail] <mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Andrew Knutsen
> Sent: Friday, May 21, 2010 2:23 PM
> To: [e-mail] <mailto:[e-mail]>
> Subject: Re: [middisc] TCP middlebox option requirements
>  
>  
>     Thanks Ananth.
>  
>     One possibility that Jamshid and I talked about addresses concerns 
> about using 3 bytes for the OUI. We could skip it (and the P bit), and 
> break up the 15 bits or so of "device capability" into an IANA-assigned 
> vendor code of maybe 7 bits, leaving 8 bits (or so) for vendor-specific 
> type. There could be one or more "standard" vendor codes for 
> multi-vendor interoperability (ie, IANA-assigned types), and an 
> extension code if we run out of room.
>  
>     Perhaps we also need to define the requirements for getting a vendor 
> code or a standard type -- for instance, we might not want any 
> individual to be able to get a vendor code, since they are limited; and 
> the standard types would need some documentation, but perhaps not as 
> widely reviewed as for a top-level option kind.
>  
> Andrew
>  
> Anantha Ramaiah (ananth) wrote:
>   
>
>     Hi,
>
>        I am just taking the liberty to post the first email on this mailing
>
>     list. During our last call there was talk about the requirements of this
>
>     TCP option. From our pov, the following would be the general
>
>     requirements of the TCP option.
>
>      
>
>      
>
>     Reason for TCP option :
>
>      
>
>     - A standard TCP option is needed because every vendor cannot have one
>
>     option for the same purpose of auto-discovery and capability exchange.
>
>     By standardizing the TCP option, firewalls etc., are aware of this
>
>     option and problems can be avoided.
>
>      
>
>     Requirements of this TCP option :
>
>      
>
>     - There has to be a vendor ID (OUI) which would identify the specific
>
>     vendor. This is needed because every vendors option format is going to
>
>     be 
>
>     different.
>
>      
>
>     - Already existing non-standardized option numbers (TCP option 33,
>
>     riverbed's options no's) for doing auto discovery should not be
>
>     allocated for this new TCP option. This is to prevent any confusion.
>
>      
>
>     - The TCP option needs to be variable length to permit multiple option
>
>     formats since the option size may vary depending on the vendor.
>
>      
>
>     - This TCP option should be advocated for use only by middleboxes.
>
>      
>
>      
>
>     My guess is that these requirements may be common for all the vendors or
>
>     there may be some additional requirements not covered by this post. In
>
>     either case we can continue the discussion and come to some conclusions.
>
>      
>
>     -Anantha
>
>     _______________________________________________
>
>     middisc mailing list
>
>     [e-mail] <mailto:[e-mail]>
>
>     https://www.ietf.org/mailman/listinfo/middisc
>
>       
>
>         
>
>  
> _______________________________________________
> middisc mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/middisc
>   
>
>  
>