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

[Joe Touch <touch at ISI.EDU>]

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



Andrew Knutsen wrote:
> 
>    A new version of the Transparent Middlebox Discovery option draft is
> available at
> <http://www.ietf.org/id/draft-knutsen-tcpm-middlebox-discovery-02.txt>.
> 
> The following changes have been made:
...
> - Simultaneous open is addressed.

Simply stating that simultaneous open isn't supported is insufficient.
The document needs to explain what happens when a SYN is received with
the option when in the SYN-SENT state - i.e., what happens in response
to the SYN received, and what happens if the other end responds to the
option in the SYN that has been sent.

...
> In addition, we made a couple more changes which I wasn't able to post
> before the
> pre-meeting deadline. They include:
> 
> - Options with length < 4 are addressed. The following text is included:
> 
>   Options with length less than 4 MUST be ignored.
> 
> - The issue of limited option space is addressed. The following text is
> included:
> 
>   There may be situations where other options are required in the SYN
>   packet which do not leave enough room for all of the target data
>   necessary for the desired device capability to be advertised. In
>   these cases, a shorter alternate device capability may be defined
>   which signals the request to further negotiate the capability after
>   the handshake completes. This will impact performance by introducing
>   an extra round-trip during connection set-up, but this may be the
>   only way to perform the negotiation within the limited TCP option
>   space available.

FWIW, the text in the security considerations needs to take space into
account as well, e.g., when asserting that this option can be protected
with either TCP MD5 (18 bytes total) or TCP-AO (16 bytes total under
both MACs defined in ao-crypto). Given the current ubiquity of the
following:

   o  SACK permitted (2 bytes) [RFC2018][RFC3517]

   o  Timestamps (10 bytes) [RFC1323]

   o  Window scale (3 bytes) [RFC1323]

The result is 9 bytes remaining with TCP-AO, and 7 with TCP-MD5. That
means this option basically has at best trivial target data (at most 3
bytes); if the P-bit is set, there is no room for target data at all. It
would be useful to address whether this option is expected to be useful
with such little (or no) target data - i.e., is this the typical case,
or a useful case? If not, then it would not be appropriate to claim that
protection from either of the TCP mechanisms is expected.

One additional question - is this option really meaningful only when the
SYN bit is set? What happens if you receive it in the SYN-ACK - you
won't be able to send a response back in the ACK (i.e., the last step of
the three-way handshake).

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

iEYEARECAAYFAkrmiIkACgkQE5f5cImnZrsa5ACeI+aR+NmHlb0saRdLUHMNeFC7
x3AAn3QXja7BySQXpph7Yna6boyGBuPx
=Ku/V
-----END PGP SIGNATURE-----