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