Re: [tcpm] New version of TCP Option for Transparent Middlebox Discovery available

[Andrew Knutsen <andrew.knutsen at bluecoat.com>]

   I'll take a first shot at this.  My colleagues may also want to chip 
in...

Joe Touch wrote:
> 1) use of the TCP option is OK, but the option needs some additional
> caveats:
>
> 	- undefined if length < 4 (i.e., receiver should send a RST)
>   
   We'll add this.

> 	- there ought to be a max suggested length
> 	see, e.g., draft-ietf-tcpm-tcp-auth-opt-05 section-9.6
>
> 	with TCP-AO, a typical SYN would have 7-9 bytes available
> 	for this option, e.g. IMO, the option should never be more than
> 	7 bytes; there is never a reason for the SYN to carry the full
> 	weight of arbitrary "target data", and I don't see why it needs
> 	to carry a full IEEE OUI. IMO, there ought to be enough bits
> 	that IANA assigns to make this work in a *known, fixed* length,
> 	and I don't see a good reason to ever have this option exceed 4
> 	bytes
>   

   In current practice, we don't use the authentication option, but we 
do use scaling and timestamps. We end up just about filling the extended 
header, and wishing we had more room. This is without the OUI, using our 
present invalid kind (as do the other vendors in this market).

   What happens is a space vs time tradeoff. Leaving info out of the 
option can imply another roundtrip when setting up a tunnel. Forcing 
this would likely preclude use of the option for its primary (ie 
current) purpose.

> 2) the security considerations needs to be revised
>
> 	- IPsec encryption would prevent detection of the option;
> 	IPsec encryption *or* authentication would prevent response.
>
> 	- TLS allows both detection and response
>   
> 	- TCP-AO allows detection in all cases.
> 	when options are included in the MAC, TCP-AO would
> 	prevent response
>
>   

   We can add this additional detail.  Which MAC options alter the 
behavior of AO?

> 	- the "target data" should not appear in the option space,
> 	as noted above, but if it did it's not clear how it could
> 	possibly be protected separately unless *this doc* describes
> 	how to include a signature within the option
> 	(and there is no room for that, IMO)
>   

   As noted above and in the draft, removing the "target data" from the 
option would render it useless.

   Also note that the draft says that the format of the "target data" 
is dependent on the "device type". Thus the intent is that any desired 
protection would be defined in the spec for that type. Since different 
situations would require different protection, I think specifying it 
here might be overkill.

> 3) Section 5.3 needs to be specific about other uses of this option
>
> 	i.e., it MUST NOT appear in segments other than SYN and
> 	the response
>   

   I suppose this is clearer than saying it MUST be in the SYN/SYN-ACK 
packets...  Mostly because the current wording might be construed to 
imply the option must be present in all SYN packets, which is unlikely 
since its an "option", but...

> 	what happens in simultaneous open?
>   

   Wesley brought this up, and we added the last paragraph of section 
5.  It never happens in current use, so we haven't addressed it.  
Perhaps we should add some suggestions, but since its not expected or 
implemented, they would be vague.

> 4) the document is missing some key elements of any TCP option
> description; in this case:
>
> 	what is the API extension that allows this value to be
> 	set or detected?
>   

   Its my understanding, and observation, that RFCs are protocol 
documents and do not generally specify APIs. Also, since all current 
implementations are proprietary, any APIs added to the draft would be 
speculative.

Andrew