Re: [tcpm] TCP-AO review comments.

[Joe Touch <[e-mail]>]

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

Hi, Ananth,

Just a few remaining points to clarify...

Anantha Ramaiah (ananth) wrote:
|> | #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.
|>
|> 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?
|
| Sure, ok let me rephrase the question here : "TCP MD5 option would
| continue to exist and should be supported for quite sometime" Does
| "obselete" allow this fact?

My impression is that it does, i.e., it recommends replacement, but
doesn't prevent it being used for legacy purposes.

< I would have preferred "Updates/Revises"
| which gives some leeway for co-existence to support legacy.

We're not changing anything in TCP MD5, so we neither update nor revise it.

It seems like those of us replying are in agreement on this overall
point, but don't quite know what the best language to use is (if others
want to debate that point, though, please do). It might be useful to ask
the IESG for advice (which I will do).

|> | 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.
|
| Hmm.. This makes the specification more complicated, IMO. I would have
| preferred to move these stuff under implemntation section. Anyways if
| the WG is ok with the current structure, I am fine with it too.

We can continue to examine this issue; if it's considered an
implementation detail (as with IPsec), we can omit the specifics. The
goal is to enable others to design key management systems that
interoperate with TCP-AO (in IPsec, there is only one such KMS - IKE).

|> | - 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.
|
| Repacketization combines multiple segments into one, thereby dictating a
| new ipid for example, so such things aren't considered messy, the
| question becomes how much flexibility you want to provide here...

It would be difficult to support repacketization and ensure
authentication, AFAICT. How do others feel?

|> The keyID is just an index; what would the utility of
|> non-numeric keyIDs be?
|
| Key ID's are generally going to be an index assuming you have a TSAD
| like database ( agreed this is what we do in our implementations today).
| I was just asking whether we should allow non-numeric key ID's as well?
| I can't think of any utility value on top of my head..

It's interpreted as an index; if you want it to be, e.g., a single ASCII
character, it wouldn't matter to us.

|> | 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.
|
| Fair enough :-) At the least the document needs to narrate the
| repurcussions of doing so.

Agreed.

|> | - 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?
|
| The point I am trying to make is that 2385 didn't elaborate on
| connectionless resets, nor does TCP AO. However the implementations
| (like IOS) have done the following today w.r.t TCP MD5 :
|
| - if there is no control block (for whatever reason) && if the incoming
| segment has MD5 option present, TCP consults the application (or TSAD)
| to retrieve the key associated with this 4 tuple (src addr, .....).
|
| - It then uses that to sign (compute digest) the RST packet.
|
| Doing this has proven to be a good scheme to recover from half open
| TCB's, since if you don't sign your RST the other end won't accept it. [
| it has to incur an application timeout, we have seen ACK wars in some
| cases etc.,)
|
| I was thinking that this can be explicitly stated in the document.

Agreed.

...
| Thinking a bit differently here, both TCP MD5 and TCP AO, in some sense
| have violated the RFC 793 mechanism of host/TCP crash recovery (RST's)
| and silently resorted to application timeouts to fix this! Well this
| sort of mandates an application timeout. For applications like BGP etc.,
| this is probably not an issue, but if we are looking at TCP AO as a
| generic auth mechanism, then it seems like an issue. This fact needs to
| be docuemnted. [ I see the security consideration does mention it
| briefly but there is scope to expand on this somewhere in a separate
| section by itself]

We should discuss this on the list further; this is definitely a tricky
case.


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

iEYEARECAAYFAkiXEhQACgkQE5f5cImnZrtLbACgtofaL+yx8L4Ge21EJctgpoJG
oj0An1cJMaXNNLnAC3xTnBueWNanZlBb
=nxX4
-----END PGP SIGNATURE-----
_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm