Re: [tcpm] TCP-AO review comments.

[Joe Touch <[e-mail]>]

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

<indiv hat on>

Stefanos Harhalakis wrote:
| On Sunday 10 August 2008, Joe Touch wrote:
|> Stefanos Harhalakis wrote:
|> | Also, is there any good in including a (1-byte - or smaller with some
|> | unused
|> | bits) version field in TCP-AO? This will help similar future
|> | extensions/replacements and will also allow for easier authentication
|> | option
|> | handshaking by falling back to the highest commonly supported method.
|>
|> <indiv hat on>
|> Options don't typically have version numbers; they're implicit in the
|> option KIND itself. IMO, that's why TCP-AO is requesting a new KIND
value.
|
| Agreed, but since this is a 'group of options' that exclude each
other, a kind
| of initial handshake is inevitable.

Handshakes in this case aren't meaningful.

| As far as I see it, even with just
| TCP-MD5 and TCP-AO there is an initial handshake problem for deciding
which
| one of them both ends support (no?).

Once a packet contains a TCP MD5 header, it MUST be authenticated using
that option, regardless of other options - thus it is irrelevant to have
alternative options present. That rule basically prevents negotiation of
the TCP MD5 option, or 'escalating' it into TCP-AO.

| Practically this makes the transition
| from MD5 to AO a hard issue.

TCP MD5 made this impossible. TCP-AO permits 'optional' use, i.e., that
the option can be present or ignored on an individual connection, which
may enable future negotiation among a variety of authentication
alternatives.

...
| Of course a new KIND is required for TCP-AO but I believe that this
should be
| the last one for the "series" of TCP authentication options.

TCP-AO is intended to be sufficiently general - e.g., by the use of a
MAC field which is defined on a per connection basis - that future
updates should not be needed for a long time. That said, there are
plenty of KIND values left if we consume one every 10 years for this
purpose...

| In fact, this
| may not be considered as a different 'KIND' of options, unless the
SYN-senter
| negotiations all authentication options and the SYN-receiver selects
the best
| that it supports. Since this isn't possible with limited TCP options space
| and SYN-cookies issues, something different is required (versioning).
|
| Do you see another (better) long-term solution?

Overall, since they keys and parameters need to be configured on a
per-endpoint-pair basis anyway, IMO this sort of handshake ought to
occur in the KMS, not in TCP. TCP's SYN option space is insufficient to
contain multiple authentication fields, AFAICT, in addition to the other
fields currently commonly in use.

Joe

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkifmoIACgkQE5f5cImnZrsH2gCg0tmFJkBO7pkeFJsjvXctAwrD
eAYAniIRWYRX8S30PghaBIn40GGV2K5z
=Z5Ky
-----END PGP SIGNATURE-----
_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm