[tcpm] TCP-AO review comments.

Hi,
  I went over the latest copy of the TCP authentication draft and
jotting down my observations and comments.

#1 
   I have problem with the term "obsoletes 2385" [ I did bring this up
before] It is going to be a long time before deployments move over to
the new TCP auth option. Many customers (deployments) are fine with TCP
MD5 with periodic key rollover option and hence would not move to TCP-AO
immediately. So, in short it really depends on combination of perceived
threat levels, desired security level of a network. Also, TCP-AO is
taking a new TCP option number with backward compatibility in mind.

Abstract

- It mentions BGP and LDP. FWIW MSDP also uses TCP MD5 and some
proprietary protocols as well. Should we use the word, "long lived
connections" instead? Just wanted to convey the feeling that it is
intended to be a generic TCP authentication option.

Section 1.1

"allows rekeying during a TCP connection "

2385 doesn't mention re-keying nor does it preclude one from doing so.
Like I mentioned earlier, deployments have been running code with some
implicit key rollover schemes.

Section 3
(security association management (TSAD)

- IMO, the contents and interpreation of TSAD should be implementation
specific. Applications can use some out of band (or configuration)
mechanism to set up the TSAD. 

- It says : "there MUST be no more than one matching TSAD entry" Not
sure why, you could have a primary and secondary key here. (I understand
that this is not robust) but using a MUST here seems too much of a
restriction. In other words, IMO, this document shouldn't be specifying
too much about TSAD. 

- TCP option exclusion : reading this it seems unclear to me as to
whether TCP-AO is excluded in the option calculation or not. 

- it says : "TCP option kind exclusion list MUST NOT change during TCP
connection" Not sure why? Needs explanation.

- It says "keyID MAY have value of 0" - really what is the point here?
Also, shouldn't we allow non-numeric key ID's ?

- "Asymmetric use of TCP-AO" - I am kind of confused here, are we saying
that the ACK's are not going to be signed, from the peer which has
negotaited "NONE" ? If so, isn't a security hole since someone can spoof
an ACK and cause issues for the side which HAS signed up for
authentication? 

- Question :
I have heard cases where some customers (although rare) want the
authentication to be turned off at some point of time, and also turned
on dynamically. TCP, today doesn't allow options negotiation "on
demand", so the latter point is moot for now. What are the thoughts
about turning off the AO option ?

- TCP user interface - I am not sure why this document (no other TCP
option document even mentions that), for eg:- STATUS call, there is no
such thing as TCP API document, typically BSD sockets are the popular
API set, the point is that you may want to simply say "appropriate API's
for the application to read/configure entries"  Just a nitpick since I
haven't seen any other TCP option document even talk about such things..
This comment can be ignored if needed..

- On connectionless resets.
Today, the way implementations work is that when a RST is generated, if
the incoming TCP segment has the TCP MD5 option, then it consults the
database to obtain the key for the the 4 tuple in question. In the case
TCP-AO option with the use of index, you could still obtain this piece
of information and generate the RST. Well, this is a "best effort", but
has been proven to be useful field experience. 

So much so far..

-Anantha
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm