Subject: Re: [tcpm] TCP-AO review comments.

From: Joe Touch <[email-masked]>
Date: Fri, 01 Aug 2008 16:16:03 -0700

Ananth,

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

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?

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

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

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?

_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Sun, 3 Aug 2008 20:56:56 -0700

Joe, 

> -----Original Message-----
> From: Joe Touch [mailto:[email-masked]] 
> Sent: Friday, August 01, 2008 4:16 PM
> To: Anantha Ramaiah (ananth)
> Cc: [email-masked]
> Subject: Re: [tcpm] TCP-AO review comments.
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Ananth,
> 

Pl find inline responses.

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

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

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

> 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 

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.

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

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

---

From: Joe Touch <[email-masked]>
Date: Mon, 04 Aug 2008 07:28:36 -0700

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.

---

From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <[email-masked]>
Date: Mon, 4 Aug 2008 10:01:39 -0500

>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of Joe Touch
>Sent: Monday, August 04, 2008 10:29 AM
>

I think that "obsoletes" is correct.  There are problems with 2385, and
AO is the solution that we're creating to replace it.  We *do* want to
discourage 2385 use when AO is ready, so obsoleting seems like the right
thing to do.  Of course someone could still use 2385; the status of a
document has no power over what's in an implementation or enabled in a
deployment, we just don't want to encourage it.

---

From: "Adam Langley" <[email-masked]>
Date: Mon, 4 Aug 2008 09:44:32 -0700

> authentication, AFAICT. How do others feel?

At the moment, TCP MD5 requires disabling LRO and TSO (both software
and hardware). There's no reason that hardware couldn't support AO
aware repacketisation in the future, but at the moment, it's
incompatible.

AGL

-- 
Adam Langley [email-masked] http://www.imperialviolet.org
_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: Chandrashekhar Appanna <[email-masked]>
Date: Mon, 4 Aug 2008 11:45:52 -0700

> deployment, we just don't want to encourage it.

  Not sure if this will obselete that.. this is a new option with different
  goals and we are not even sure if at this point how much consensus there
  is about moving AO forward.. there is much discussion on the keying aspects,
  the design team seems to be just one person speaking up mostly; and
  given the comments from other design team members at the mike at the ietf
  I would not be in favour of making AO obselete the other method.. like you
  say the status of the document has no power and therefore it is better
  to not think it has some if it does not line up ;).. forcing a document
  through without the implied working code and rough consensus may end up
  doing more harm to the doc itself..

  Rgds,
  Chandra.

---

From: Lars Eggert <[email-masked]>
Date: Wed, 6 Aug 2008 14:47:31 +0300

> this is consistent with "Obsoltes", would that be OK?

We need to distinguish between one RFC obsoleting another RFC, and  
moving an RFC to "historic". Unfortunately, neither is very clearly  
defined.

Here's my current thinking: Obsoleting is typically used when one RFC  
is a drop-in replacement for another RFC. For example, bug-fix  
revisions of an RFC typically obsolete the previous RFC, as do minor  
backwards-compatible implementations. That isn't quite the case for AO  
and TCP-MD5. AO is a replacement for TCP-MD5, but it isn't a simple  
revision or extension of TCP-MD5, it's a new mechanism to provide  
similar functionality in a (slightly) different way.

So, my current thinking is that AO should maybe move TCP-MD5 to  
"historic". That would indicate that new implementations shouldn't  
implement TCP-MD5 and existing ones are encouraged to move away from  
it. But this isn't a clear -cut case. Comments?

Lars

---

From: Caitlin Bestler <[email-masked]>
Date: Wed, 06 Aug 2008 06:58:36 -0700

Lars Eggert wrote:
> Here's my current thinking: Obsoleting is typically used when one RFC is 
> a drop-in replacement for another RFC. For example, bug-fix revisions of 
> an RFC typically obsolete the previous RFC, as do minor 
> implement TCP-MD5 and existing ones are encouraged to move away from it. 
> But this isn't a clear -cut case. Comments?
> 

I have always viewed a new TCP-Auth RFC as a drop-in replacement
for TCP-MD5.

Basically, this is an application layer problem being foisted upon
the transport layer. It creates unneeded clutter at the transport
layer that is not of general utility.

The fact that it is replacing an existing option is the only real
justification for doing it. Stare decisis is good for constitutional
law, it makes sense for standards as well.

But we need to be clear that we are not creating an *additional*
transport layer encryption solution to solve poor application design,
we're just replacing an existing problem.
_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 06 Aug 2008 08:15:33 -0700

At Wed, 06 Aug 2008 06:58:36 -0700,
> we're just replacing an existing problem.

Hmm... I'm not sure I agree with this assessment. What do you think
the application layer problem in question is?

-Ekr

---

From: Joe Touch <[email-masked]>
Date: Thu, 07 Aug 2008 11:27:02 -0700

Chandrashekhar Appanna wrote:
Just to clear up a potential point of confusion

...
|> I think that "obsoletes" is correct.
|
|   Not sure if this will obselete that.. this is a new option with
different
|   goals

AFAICT, this option has the same fundamental goal - transport layer
protection of the transport protocol. TCP-AO has additional requirements
that exceed TCP MD5, primarily (and arguably solely) to address
inadequacies in TCP MD5.

|   and we are not even sure if at this point how much consensus there
|   is about moving AO forward.. there is much discussion on the keying
aspects,
|   the design team seems to be just one person speaking up mostly; and
|   given the comments from other design team members at the mike at the
ietf
|   I would not be in favour of making AO obselete the other method..
like you
|   say the status of the document has no power and therefore it is better
|   to not think it has some if it does not line up ;).. forcing a document
|   through without the implied working code and rough consensus may end up
|   doing more harm to the doc itself..

TCP MD5 uses a faulty hash and does not protect against replay attacks.
IMO it is sufficiently faulty that it ought to be deprecated regardless
of the state of a replacement.

Joe

---

From: Ron Bonica <[email-masked]>
Date: Fri, 08 Aug 2008 13:37:33 -0400

> layer that is not of general utility.

Caitlin,

I disagree. TCP-AO protects against some classes of attack against the 
TCP control plane. These attacks cannot be addressed at the application 
layer.

For example, there is nothing that can be done at the application layer 
to protect against the insertion of an empty TCP segment with the reset 
bit set. TCP-AO protects against this.

                                      Ron

---

From: Stefanos Harhalakis <[email-masked]>
Date: Sun, 10 Aug 2008 12:37:46 +0300

> it. But this isn't a clear -cut case. Comments?

IMHO, "shouldn't implement" in the above phrase should be changed 
to "shouldn't use". For backwards compatibility reasons implementations may 
(or should) (and most probably will) implement TCP-MD5 too.

> similar functionality in a (slightly) different way.

Following your thoughts: Since TCP-AO is mutually exclusive with TCP-MD5, one 
cannot view them as two distinct options. This means that TCP-AO is actually 
a replacement of TCP-MD5 and we can also describe it as a 'newer, 
backwards-incompatible version' of the existing authentication mechanism of 
TCP. Having this in mind, perhaps 'obsoletes' is correct.

Also, is there any good in including a (1-byte - or smaller with some unused 
bits) version field in TCP-AO? This will help similar future 
extensions/replacements and will also allow for easier authentication option 
handshaking by falling back to the highest commonly supported method.
_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Sun, 10 Aug 2008 04:11:14 -0700

Stefanos Harhalakis wrote:
...
| Also, is there any good in including a (1-byte - or smaller with some
unused
| bits) version field in TCP-AO? This will help similar future
| extensions/replacements and will also allow for easier authentication
option
| handshaking by falling back to the highest commonly supported method.

<indiv hat on>
Options don't typically have version numbers; they're implicit in the
option KIND itself. IMO, that's why TCP-AO is requesting a new KIND value.

Joe

---

From: Joe Touch <[email-masked]>
Date: Sun, 10 Aug 2008 04:19:47 -0700

Ron (et al.)

Ron Bonica wrote:
|
|>
|> Basically, this is an application layer problem being foisted upon
|> the transport layer. It creates unneeded clutter at the transport
|> layer that is not of general utility.
|>
|
| Caitlin,
|
| I disagree. TCP-AO protects against some classes of attack against the
| TCP control plane. These attacks cannot be addressed at the application
| layer.

FWIW, I think Caitlin is referring to BGPs assumption that TCP
connectivity implies network connectivity, i.e., when a BGP TCP
connection is dropped, the routes should be removed immediately. I agree
with her that this is an application layer problem (IMO, an application
layer making invalid assumptions).

That doesn't prevent the need for a transport layer protection for
transport connections (as you note below). There's utility in protecting
invested TCP state - e.g., large window sizes, or pending transfers -
from attackers, even when applications use TCP appropriately.

Joe

| For example, there is nothing that can be done at the application layer
| to protect against the insertion of an empty TCP segment with the reset
| bit set. TCP-AO protects against this.

---

From: Stefanos Harhalakis <[email-masked]>
Date: Sun, 10 Aug 2008 15:07:35 +0300

On Sunday 10 August 2008, Joe Touch wrote:
> | unused
> | option

Agreed, but since this is a 'group of options' that exclude each other, a kind 
of initial handshake is inevitable. As far as I see it, even with just 
TCP-MD5 and TCP-AO there is an initial handshake problem for deciding which 
one of them both ends support (no?). Practically this makes the transition 
from MD5 to AO a hard issue. Considering this, in the future (lets say in 5 
years) another such option 'upgrade' won't be feasible.

Of course a new KIND is required for TCP-AO but I believe that this should be 
the last one for the "series" of TCP authentication options. In fact, this 
may not be considered as a different 'KIND' of options, unless the SYN-senter 
negotiations all authentication options and the SYN-receiver selects the best 
that it supports. Since this isn't possible with limited TCP options space 
and SYN-cookies issues, something different is required (versioning).

Do you see another (better) long-term solution?
_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Sun, 10 Aug 2008 18:49:08 -0700

<indiv hat on>

Stefanos Harhalakis wrote:
| On Sunday 10 August 2008, Joe Touch wrote:
|> Stefanos Harhalakis wrote:
|> | Also, is there any good in including a (1-byte - or smaller with some
|> | unused
|> | bits) version field in TCP-AO? This will help similar future
|> | extensions/replacements and will also allow for easier authentication
|> | option
|> | handshaking by falling back to the highest commonly supported method.
|>
|> <indiv hat on>
|> Options don't typically have version numbers; they're implicit in the
|> option KIND itself. IMO, that's why TCP-AO is requesting a new KIND
value.
|
| Agreed, but since this is a 'group of options' that exclude each
other, a kind
| of initial handshake is inevitable.

Handshakes in this case aren't meaningful.

| As far as I see it, even with just
| TCP-MD5 and TCP-AO there is an initial handshake problem for deciding
which
| one of them both ends support (no?).

Once a packet contains a TCP MD5 header, it MUST be authenticated using
that option, regardless of other options - thus it is irrelevant to have
alternative options present. That rule basically prevents negotiation of
the TCP MD5 option, or 'escalating' it into TCP-AO.

| Practically this makes the transition
| from MD5 to AO a hard issue.

TCP MD5 made this impossible. TCP-AO permits 'optional' use, i.e., that
the option can be present or ignored on an individual connection, which
may enable future negotiation among a variety of authentication
alternatives.

...
| Of course a new KIND is required for TCP-AO but I believe that this
should be
| the last one for the "series" of TCP authentication options.

TCP-AO is intended to be sufficiently general - e.g., by the use of a
MAC field which is defined on a per connection basis - that future
updates should not be needed for a long time. That said, there are
plenty of KIND values left if we consume one every 10 years for this
purpose...

| In fact, this
| may not be considered as a different 'KIND' of options, unless the
SYN-senter
| negotiations all authentication options and the SYN-receiver selects
the best
| that it supports. Since this isn't possible with limited TCP options space
| and SYN-cookies issues, something different is required (versioning).
|
| Do you see another (better) long-term solution?

Overall, since they keys and parameters need to be configured on a
per-endpoint-pair basis anyway, IMO this sort of handshake ought to
occur in the KMS, not in TCP. TCP's SYN option space is insufficient to
contain multiple authentication fields, AFAICT, in addition to the other
fields currently commonly in use.

Joe

---

From: Stefanos Harhalakis <[email-masked]>
Date: Sat, 23 Aug 2008 15:11:09 +0300

Hello again after 12 days,

On Monday 11 August 2008, Joe Touch wrote:
> | that it supports. Since this isn't possible with limited TCP options
> | space and SYN-cookies issues, something different is required
> | (versioning).
> |

  After rereading the draft and rethinking the conversation, I (finally) agree 
with you. Indeed everything is as you stated above. Since by definition any 
handshake will occur out-of-band in KMS, any different behaviour will require 
another KIND.
_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm