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

[Joe Touch <touch at ISI.EDU>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, Andrew,

Andrew Knutsen wrote:
> 
>    I'll take a first shot at this.  My colleagues may also want to chip
> in...
...
>>     - 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).

You don't use TCP-AO, but the endpoints might. It's intended to be more
generally useful than was TCP MD5 (which is used typically only for BGP).

It's unrealistic to fill the option space with this one extension. It
would basically preclude any other options from being included. The
option space is severely limited, especially in SYNs.

I would object to this going forward using more than a highly
constrained amount of space. If additional space is needed for extended
information, that can be exchanged in option fields after the initial
negotiation- the info in the SYN is supposed to just be "do you speak X".

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

Using this much space in the option would kill all other future uses of
the option space. If it's between an extra RTT and shutting down future
use of options, we need to take the RTT hit.

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

TCP-AO allows endpoints to either include all the TCP options in the MAC
or exclude them. This information is not visible on the wire. If you
modify any of the options en-route and the options are included in the
MAC, the packet will be silently dropped by the receiver.

TCP is an endpoint protocol. It is not particularly intended for
intermediate parties to modify its contents.

Since you brought that up, I have to then consider whether it's
appropriate to even have a TCP option whose primary purpose is NOT to
communicate to the receiving endpoint, and I have to say that on that
basis, this should not be a TCP option at all.

I appreciate the desire to have a signal on the path with the TCP SYN,
and to embed it in the that segment. Have you considered putting this in
the IP option space?

I.e., it would still fate-share with the TCP SYN, but it would be in a
place it ought to be to be examined and/or modified by intermediate
parties. That would also give you a bit more room to play in...

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

Where you say it is protected separately, you should also indicate
"inside the target data area, as specified by the target data format"

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

It MAY appear in SYNs, or in ACKs to a SYN.

It MUST NOT appear in other segments.

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

You need to say *exactly* how it should be handled *when* it comes up.
It may be a corner case, but addressing it is required for all TCP
modifications.

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

RFC 793 includes an API. You're extending that RFC, and by inclusion,
its API. You need to state that, in an abstract way, the OPEN and STATUS
calls are modified to include parameters that set and read the status of
this option.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAkrDuCYACgkQE5f5cImnZrsifgCgxU0nTdaZ72AJ3fl3tZZ2l4zY
+c0An1G8SygAZLHnVRoI8hZ9UMJZMlWW
=hpWN
-----END PGP SIGNATURE-----