Re: [tcpm] TCP-AO review comments.

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. 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?). Practically this makes the transition 
from MD5 to AO a hard issue. Considering this, in the future (lets say in 5 
years) another such option 'upgrade' won't be feasible.

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. 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?
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm