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

[Joe Touch <touch at ISI.EDU>]

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

Some comments:

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)

	- 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

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

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

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

	what happens in simultaneous open?

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?

Joe


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

iEYEARECAAYFAkrDndgACgkQE5f5cImnZrtXaACgpV/WeMDTv74XynK9pYbG5dOR
L6kAoJesr0uh2HGAWhFUSzGquWwbgEKD
=6O04
-----END PGP SIGNATURE-----