Re: [tcpm] TCP-AO review comments.

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

Ananth,

Thanks for posting the comments. Some notes/questions below.

Practically, "obsoletes" doesn't obsolete anything. It does indicate
that the IETF wants a protocol to be replaced by something else. That
doesn't mean the older one can't be used for legacy support, e.g.,
AFAICT - and that clearly should apply here. If the IESG thinks that
this is consistent with "Obsoltes", would that be OK?

|... Also, TCP-AO is
| taking a new TCP option number with backward compatibility in mind.

The desire to use a new option KIND is not related to backward
compatibility; that can already be determined by the length field, as
noted in an earlier draft-touch precursor document.

It would probably be useful to use the latter, and give the former as
some current examples.

| Just wanted to convey the feeling that it is
| intended to be a generic TCP authentication option.

That was the WG intent AFIACT, and should be captured.

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

That should be clarified to "explicitly supports"...

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

We need to indicate the contents of the TSAD that the key management
system would modify, and the ones we depend on. The interpretation of
those values is part of the state of the TCP-AO protocol.

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

The goal is to avoid overlapping matches, or sufficiently limit them
that the preference is deterministic. Multiple keys would be handled
within a single TSAD entry, as well.

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

Good point. I believe there is no utility in including the option in the
calculation. Handling the option confirms the KIND. Matching the MAC
confirms the keyID and length. There's nothing left to include.

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

One target requirement (IMO) is to avoid stateful changes during a
connection. Otherwise, things like retransmission get messy, and we'd
need flags for every parameter that could change, to indicate the
appropriate state for a given segment.

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

This just confirms that there are no reserved values. Some protocols
break on corner cases, and this just notes the corner case is the normal
case.

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

The keyID is just an index; what would the utility of non-numeric keyIDs be?

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

Yes.

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

Yes - but both sides are agreeing to the authentication used in both
directions (even when NONE). If that's not a mode you want to use, then
you don't enable it.

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

<IHO>
IMO, because TCP doesn't turn options on and off during a connection, we
shouldn't either. We're trying to create a simple replacement for TCP
MD5, not break new ground in TCP option issues.

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

All of the API calls noted in this document are listed exactly because
they are described in 793. BSD sockets happen to implement the 793
commands as calls, but the API is actually specified in 793.

| - 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 you're suggesting here; are you saying we can say we
handle connectionless resets the same way as TCP MD5?

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

iEYEARECAAYFAkiTmTMACgkQE5f5cImnZrvNCgCg31ahJ6uNQ2V12js02aaqfiKP
WUAAn0Z6DXgvV5SYWSg+cNLFZvJ4I7Ai
=cBkq
-----END PGP SIGNATURE-----

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