Re: [tcpm] TCP-AO review comments.

["Anantha Ramaiah (ananth)" <[e-mail]>]

Joe, 

> -----Original Message-----
> From: Joe Touch [mailto:[e-mail]] 
> Sent: Friday, August 01, 2008 4:16 PM
> To: Anantha Ramaiah (ananth)
> Cc: [e-mail]
> Subject: Re: [tcpm] TCP-AO review comments.
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Ananth,
> 
> Thanks for posting the comments. Some notes/questions below.

Pl find inline responses.

> 
> Anantha Ramaiah (ananth) wrote:
> | 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.
> 
> 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? I would have preferred "Updates/Revises"
which gives some leeway for co-existence to support legacy. That's just
me.. Anyways I was hoping to see more discussion on this and the
collective wisdom of this WG on this aspect.

<snip>

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

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

Ok, that clarifies.

<snip>

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

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

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

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

Ok.

<snip>

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

[Yes, I agree that there is corner case here, what if the key value
changed in between Or you can't retrieve the key for some valid reasons
(the whole box crashed and the key database is gone), etc., but those
events are rare and hence I call this a best-effort approach which has
worked well for us]

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]

Hope this is clear, now.

-Anantha
_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm