Re: [tcpm] TCP-AO review comments.

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

Hi, Ananth,

As I noted with Eric's comments, we can discuss this further in the
meeting today, but it might be useful to try to discuss some on the list
first... see below.

Joe

Whether or not we are obsoleting things is a topic for today's
discussion. I should have removed it from the doc header until we make a
decision, though.

| 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

There is no key rollover option to TCP MD5. The doc is vague on this
issue, saying only "presumably connection specific"; there is no key ID,
and no discussion of the impact of changing keys during a connection.

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

The desire to use a new option number has nothing to do with backward
compatibility. As noted in precursors to this doc, the TCP MD5 ID could
be reused. Backward compatibility is limited - and we are discussing the
extent to which that is needed today as well. A given connection is not
intended to back off from TCP-AO and use TCP-MD5 automatically.

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

We probably want to leave the current examples (and add MSDP), as well
as noting the general utility of this mechanism.

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

Agreed that it is not discussed explicitly, but a key rollover would
generate logging error messages ("probably advisable"). Current
implementations may have a working mechanism for rollover, but they make
many presumptions that are not specified, e.g., that retransmissions
must use the new key once installed. Further, key rollover would result
in lost segments, retransmission, and potential impact on the congestion
window.

The section should clarify that TCP-AO "explicitly allows rekeying
during a TCP connection, without impacting packet loss"

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

TSAD is setup out-of-band; that's the purpose of the key management
mechanism, e.g.

The contents are specified for two reasons:
	- to define the API to access the info
	- to define the syntactic relationship between components

The TSAD can be implemented in any way the user desires, so long as it
stores and retrieves the data specified thusly.

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

A single TSAD entry can have multiple keys. Having multiple matching
TSAD entries means there is a collision that cannot be resolved.

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

This can be clarified. The intent is to exclude or include all options;
parsing and including individual options would be expensive on a
per-packet basis. The TCP-AO option MAC is zeroed if the options are
included.

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

This can be clarified. The goal is that all changes during a connection
do not affect packet loss. Doing so for the option exclusion means an
additional per-packet check which doesn't seem to be necessary.

| - It says "keyID MAY have value of 0" - really what is the point here?

The goal is to not preclude or reserve any KeyID values.

| Also, shouldn't we allow non-numeric key ID's ?

The KeyID is an 8-bit field, interpreted as an index of 0-255. What
purpose would non-numeric IDs serve?

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

The utility of this was discussed in Philadelphia. The doc might benefit
from expanded review of that discussion.

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

IMO, that's handled by using NONE, i.e., the keyID changes and thus the
corresponding algorithm. TCP state - i.e., the fact that TCP-AO is being
used - never changes during a connection; that's because TCP doesn't
support such state negotiation after the SYN exchange, and to add that
would effectively change the TCP state diagram (which seems avoidable
and desirable to avoid).

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

RFC793 specifies the TCP API. STATUS is defined there. BSD implements
that API (or at least a close approximation of it ;-)

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

IMO, that's a deficiency of other option docs ;-)

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

I'm not sure what the question here is; the RST MUST have the TCP-AO
with the correct fields to be accepted at the receiver. Can you restate
the question regarding RSTs?

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

iEYEARECAAYFAkiNiv0ACgkQE5f5cImnZrtOTQCg05lOQTahQTIRDFk1lRyUjl9P
NhoAn37/C7donQo8Er//Xtmra4j/0dHF
=ok2w
-----END PGP SIGNATURE-----
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm