Subject: [tcpm] closing WGLC for TCP-AO

From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[email-masked]>
Date: Tue, 1 Dec 2009 15:42:11 -0600

The period for the working group last call on the AO documents
has passed.  I didn't see any major issues that were identified.
Even though the response was light, given the large amount of
discussion that's gone into it to reach this point, I think this
is okay to proceed; we'll write the PROTO statements if the
authors can rev the drafts based on any feedback they got.

One additional question that was open was whether the NAT draft
of Joe's should be rolled in.  Since several people supported
this, and none were against it, I think Joe should go ahead and
include it before it gets sent to the IESG.

My late, and minor, comments on the AO and crypto drafts are
below, as a WG participant.

On the main AO draft
====================

1) editorial - in Abstract:
"TCP-AO uses its own option identifier, even though used mutually
 exclusive of TCP MD5 on a given TCP connection."
could this just be:
"TCP-AO uses a separate option identifier from TCP MD5 and the
 two options are not capable of being used at the same time."

2) editorial, in Figure 1 (section 4.1):
It's probably clear to everyone that the MD5 digest field wraps through
the remainder of the option length, but could a "..." or "... (cont.)"
be added to the empty areas to make that explicit?  The way it's shown
in Figure 2 is nice, I think.

3) editorial, in section 5.2:
"derived from the MKT and the properties of a connection.  For
 established connections, these properties include the socket pair
 (local IP address, local TCP port, remote IP address, remote port),"
could be:
"derived from the MKT and the local and remote pairs of IP addresses
 and TCP port numbers,"

4) technical/editorial in section 5.2:
I think this is just a typo, but to make sure ...:
"A single MKT can be used to derive any of four different MKTs:"
should be:
"A single MKT can be used to derive any of four different traffic keys:"

5) editorial, in section 7.2:
The heading is "Key Derivation Functions", I think it would be better
as "Traffic Key Derivation Functions", as it doesn't discuss the
derivation of master keys.

On the AO crypto draft
======================

1) editorial, in abstract:
"algorithm(s)" -> "algorithms" ?

2) editorial, in Section 1:
"to TCP-AO [TCP-AO] [I-D.ietf-tcpm-tcp-auth-opt]."
->
"to TCP-AO [I-D.ietf-tcpm-tcp-auth-opt]."

3) editorial, in Section 1:
"two key derivations functions"
->
"two key derivation functions"

4) editorial, in section 2.2:
"Security Area Directors"
->
"IETF Security Area Directors"

5) editorial/technical, in section 2.2:
"especially given that the tags are truncated to 96 bits"
->
"even though the tags are truncated to 96 bits"
???

6) editorial/technical, in section 2.2:
"aren't practical on SHA-1"
->
"aren't practical on HMAC-SHA-1"
???

7) editorial, section 7.1:
use of Output_Length included here is not consistent with
the way that the main auth-opt draft defines this.

8) editorial, section 3.1.1:
"Each"
->
""

9) editorial, figure 1:
formatting of top line is off

--
Wes Eddy
MTI Systems

---

From: Joe Touch <[email-masked]>
Date: Tue, 01 Dec 2009 13:49:10 -0800

Hi, Wes,

To confirm below...

Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote:
...
> On the main AO draft
...
> "A single MKT can be used to derive any of four different traffic keys:"

Yes. That's what's intended; the original text is a typo.

Joe

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Tue, 1 Dec 2009 23:19:11 -0800

Maybe I missing something here, I haven't seen any responses for this
WGLC, typically if that is the case, I have seen the urge to ask folks
to read and even they don't have any comments "I have read it, it is
fine". No such thing seem to have happened for this case. May be I
missed some responses.

IMO, this TCP-AO option needs to have an "Applicability statement". The
typical advise whenever one tries to make TCP robust or provide TCP
security has always been "use IPSec" and such an argument has derailed
any changes that improve TCP's robustness and resulted in endless
debates in the past in TCPM.  The rationale of having TCP-AO stems from
the fact that "some applications can't use IPsec due to n number of
reasons", TCP-MD5 came into play which is now being replaced by the TCP
AO option. But not all applications/devices would want to use this
option neither should it be encouraged to use this option, if one were
to go by the "IPsec mantra".  So, I would like to have an AS put in the
doc which states the circumstances (long lived connections),
applications (like BGP) and devices (routers) where the usage of this
TCP option is recommended. TCP secure document has an AS which can be
used as a template, if needed. Also I would want a paragraph which
explains why IPsec cannot
 be used (even though the document contains pointers to earlier
motivation document, I would rather prefer this to be made
self-contained in this document.) 

The introduction does have something to this effect, but sounds too
general and not specific.

As far as the NAT document goes, there seems to be rush here in folding
this along with the TCP-AO. The NAT document doesn't even show up in
this TCPM charter page, FWIW.

Regarding the NAT document, I have some general questions :

- how many clients are there that are behind NAT and still would want to
use this option?. The currently used TCP-MD5 option didn't face such an
issue, in other words NAT compatibility was the least bothering issue,
IMO.
- Also the document says it reduces the entropy and advises the both
localNAT/remoteNAT should not be turned on. Hoe can you detect
mis-configurations? What happens when someone configures this on the
middle of the connection?

I have a feeling that the NAT solution proposed has not been discussed
thoroughly (there have been lot of discussions before that, but after
the NAT document was written, there was some support to fold this
content with the TCP-AO, agreed)  but it seems like we are rushing this
part, IMO.

-Anantha

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]
> Sent: Tuesday, December 01, 2009 1:42 PM
> To: [email-masked]
> Cc: Joe Touch
> Subject: [tcpm] closing WGLC for TCP-AO
> 
> The period for the working group last call on the AO 
> documents has passed.  I didn't see any major issues that 
> were identified.
> discussion that's gone into it to reach this point, I think 
> this is okay to proceed; we'll write the PROTO statements if 
> the authors can rev the drafts based on any feedback they got.
> 
> One additional question that was open was whether the NAT 
> draft of Joe's should be rolled in.  Since several people 
> supported this, and none were against it, I think Joe should 
> go ahead and include it before it gets sent to the IESG.
> 
> "TCP-AO uses its own option identifier, even though used 
> mutually  exclusive of TCP MD5 on a given TCP connection."
> could this just be:
> "TCP-AO uses a separate option identifier from TCP MD5 and 
> the  two options are not capable of being used at the same time."
> 
> It's probably clear to everyone that the MD5 digest field 
> wraps through the remainder of the option length, but could a 
> "..." or "... (cont.)"
> be added to the empty areas to make that explicit?  The way 
> it's shown in Figure 2 is nice, I think.
> 
> "derived from the MKT and the properties of a connection.  
> For  established connections, these properties include the 
> socket pair  (local IP address, local TCP port, remote IP 
> address, remote port),"
> could be:
> "derived from the MKT and the local and remote pairs of IP 
> addresses  and TCP port numbers,"
> 
> The heading is "Key Derivation Functions", I think it would 
> be better as "Traffic Key Derivation Functions", as it 
> doesn't discuss the derivation of master keys.
> 
> 
> 
> On the AO crypto draft
> ======================
> 
> use of Output_Length included here is not consistent with the 
> way that the main auth-opt draft defines this.
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: Joe Touch <[email-masked]>
Date: Wed, 02 Dec 2009 00:10:16 -0800

Hi, Anantha,

> fine". No such thing seem to have happened for this case. May be I

There was one response from Donald Smith on 11/3. I didn't see any
confirming responses, but we haven't required that during last calls AFAIR.

> TCP option is recommended.

Although there is no section entitled "Applicability Statement", the
text you're seeking is already contained in the third paragraph of the
Introduction (sec 2).

> TCP secure document has an AS which can be

It's quite specific. Use TCP-AO where authentication is needed and IPsec
is not desired or where keys need to be bound to connections. That's
about as specific as it gets.

> this TCPM charter page, FWIW.

There has always been interest in considering NAT support for TCP-AO,
and it has been discussed many times. Until we developed the
master/traffic key mechanism based on the ISNs, however, it wasn't feasible.

The NAT mechanism was posted to this list 7/30. You commented on it 8/7.
I don't understand your claim that this has been a rush. Keep in mind
that the time needed to evaluate it ought to be commensurate with its
complexity. It just zeroes out the ports, and explains why that's
feasible given how traffic keys are now derived.

> issue, in other words NAT compatibility was the least bothering issue,

TCP-AO is intended to be a general mechanism. In that regard, if we can
support NAT traversal without substantial complexity, then we should.
Zeroing the ports prior to HMAC calculation seems a fairly low level of
complexity.

> middle of the connection?

TCP-AO is not a security configuration negotiation protocol.
Misconfigurations result in dropped segments, as they would in any protocol.

If someone turns this on in the middle of a connection the port fields
aren't protected by the authentication algorithm, but it won't help much
to change them on the fly. They'll just be dropped because their traffic
keys won't match those of other connections (with very high probability).

> content with the TCP-AO, agreed)  but it seems like we are rushing this

It has been out on the list for 3 months, with discussion, and was
included in the request for the last call.

Joe

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Wed, 2 Dec 2009 01:13:57 -0800

<snip>
 
> There was one response from Donald Smith on 11/3. I didn't 

Yes, I remember that. The email from Donald expressed concerns w.r.t
connectionless Resets and clarifications were sought. (actually I have a
quite of bit of thoughts in this area all coming from addressing/solving
customer issues w.r.t RST's and MD5, but never found time to gather and
share those experiences)

> see any confirming responses, but we haven't required that 
> during last calls AFAIR.

My mileage is different than yours. If there are no sufficent responses
within the WGLC time period, then mostly the WGLC extension was given,
AFAIR.

> 
> > IMO, this TCP-AO option needs to have an "Applicability statement". 
> > The typical advise whenever one tries to make TCP robust or provide 
> > TCP security has always been "use IPSec" and such an argument has 
> > derailed any changes that improve TCP's robustness and resulted in 
> > endless debates in the past in TCPM.  The rationale of 
> having TCP-AO 
> > stems from the fact that "some applications can't use IPsec 
> due to n 
> > number of reasons", TCP-MD5 came into play which is now 
> being replaced 
> > by the TCP AO option. But not all applications/devices 
> would want to 
> > use this option neither should it be encouraged to use this 
> option, if 
> > one were to go by the "IPsec mantra".  So, I would like to 
> have an AS 
> > put in the doc which states the circumstances (long lived 
> > connections), applications (like BGP) and devices (routers) 
> where the 
> > usage of this TCP option is recommended.
> 
> Although there is no section entitled "Applicability 
> Statement", the text you're seeking is already contained in 
> the third paragraph of the Introduction (sec 2).

Yes, I read that and pointed out the same below, then what is the harm
in calling this as an "Applicabiliy statement". Since this TCP-AO usage
needs to be restricted to a handful of situations and one need to always
use IPsec if available.  Having an AS, it makes things more clearer for
the reader, this is the general consensus a while back.

> It's quite specific. Use TCP-AO where authentication is 
> needed and IPsec is not desired or where keys need to be 
> bound to connections. That's about as specific as it gets.

It doesn't say why Ipsec can't be used, what reasons (explicit)?
(motivation document may have it, but that needs to be spelled out here
for the benefit of completeness, IMO).

Then what is wrong in putting it under an AS and sending out for review?
What makes you think that an AS is not necesssary, this will surely
benefit a lot of implementers.

> > As far as the NAT document goes, there seems to be rush here in 
> > folding this along with the TCP-AO. The NAT document 
> doesn't even show 
> > up in this TCPM charter page, FWIW.
> 
> There has always been interest in considering NAT support for 
> TCP-AO, and it has been discussed many times. Until we 
> developed the master/traffic key mechanism based on the ISNs, 
> however, it wasn't feasible.

The MKT generation can be done multiple ways and usage of ISN's is one
such scheme? Are we mandating this in TCP-AO, atleast I didn't get that
feeling (that is how it should be and left to the implementer) 

> The NAT mechanism was posted to this list 7/30. You commented 

Sorry can't recall, which email you are referring to? Are you talking
about the current document or the old NAT discussions which happened,
but that time this proposed solution was non-existent.

> I don't understand your claim that this has been a rush. Keep 
> in mind that the time needed to evaluate it ought to be 
> commensurate with its complexity. It just zeroes out the 
> ports, and explains why that's feasible given how traffic 
> keys are now derived.

Well, that is easy to say. Let me step back a bit: Are TCP documents
which are general in nature should take into account NAT/middlebox
issues/, till recently the answer was (even from your earlier emails)
shouldn't probably care.. The method followed in the past is to say
"this wont work, just document it" Now we seem to have relaxed this a
bit further by proposing solutions, a 3 month review for the same isn't
simply enough and if it is considered otherwise, I simply chose to call
it as a "Rush".

> > - how many clients are there that are behind NAT and still 
> would want 
> > to use this option?. The currently used TCP-MD5 option didn't face 
> > such an issue, in other words NAT compatibility was the least 
> > bothering issue, IMO.
> 
> TCP-AO is intended to be a general mechanism. In that regard, 

What do you mean by a "general mechanism" what makes TCP-MD5 specific?
TCP AO is an enhancement on the exisiting TCP-MD5 option, that's it. It
may have all the "nice" things, but that doesn't re-define its
applicability AFAICT. When the motivation document was written a few
years ago it was keeping in mind the needs of specfic applications that
cannot use the recommended, existing security mechanism (called as
IPsec)

> if we can support NAT traversal without substantial 
> complexity, then we should.

This way you can keep adding support for almost anything, but that was
not the goals of this document, esp when this is required by only a
handful of protocols. (of course important ones)

> It has been out on the list for 3 months, with discussion, 
> and was included in the request for the last call.

3 months is very short time considering the life-span of typical IETF
(TCPM in particular) documents . YMMV ;-) I would still call this as a
"rush".

-Anantha

<snip>

---

From: Fernando Gont <[email-masked]>
Date: Wed, 02 Dec 2009 11:01:48 -0300

> fine". No such thing seem to have happened for this case. May be I

+1

Kind regards,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[email-masked]>
Date: Wed, 2 Dec 2009 08:39:10 -0600

There's a big difference between documents that authors think are ready for WGLC but have only seen light discussion in the WG, and documents that have been extensively discussed in hundreds of mail-list posts and hours of WG face-to-face meeting time and other high-bandwidth offline discussion.

Early retransmit was a good example of the first case; the document was basically done, but we couldn't tell if the WG had read it sufficiently, so the WGLC got extended until we had that confidence.

AO is an example of the second case; it's benefited from very long sesssions in some of our meetings (Dublin, Minneapolis, San Francisco, etc), and the mailing list traffic attests that a lot of people have read it, raised their issues, and had them addressed in document updates.  In this case, the consensus seemed to be formed well before the WGLC, making it more of a "speak now or forever hold your peace" moment, rather than an attempt to make sure sufficient review had been obtained.

I hope this clears things up for those of you who think this is odd.  It's not :).

________________________________________
From: Fernando Gont [[email-masked]] On Behalf Of Fernando Gont [[email-masked]]
Sent: Wednesday, December 02, 2009 9:01 AM
To: Anantha Ramaiah (ananth)
Cc: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]; [email-masked]; Joe Touch
Subject: Re: [tcpm] closing WGLC for TCP-AO

+1

Kind regards,

---

From: Joe Touch <[email-masked]>
Date: Wed, 02 Dec 2009 07:08:53 -0800

> the reader, this is the general consensus a while back.

TCP-AO provides protections that IPsec does not and cannot - notably,
keys that change on a per-connection basis even when the addr/port pair
is reused. There is no mechanism in IPsec or via IKE to force a key
change when a connection is terminated or when a new connection ensues,
even after TIME_WAIT.

If you have reasons you want to suggest to restrict the use of TCP-AO,
please list them. They have not been raised in the several years this
issues has been under discussion. The design team began several years
ago with a mandate to develop a general authentication mechanism, not
one specific to a "handful of situations".

> It doesn't say why Ipsec can't be used, what reasons (explicit)?

It does say the two specific reasons:

	- when IPsec is not desired
	- when keys need to be bound to connections

The latter is clear. The former can happen for many reasons, and we
don't make that case in this doc. The doc intended to provide a solution
in that case for those who have already made up their mind.

> Then what is wrong in putting it under an AS and sending out for review?

Nothing. This is something you had several *years* to raise, though.

> benefit a lot of implementers.

I don't think it's not necessary; I think it's already sufficiently
included. I'll leave it to the WG chairs to suggest how to proceed.

> feeling (that is how it should be and left to the implementer) 

Please read the doc. Use of ISNs is very specifically specified and
required.

>> The NAT mechanism was posted to this list 7/30....
> 

The proposed solution was described in my post of 7/13 (sorry - typo).
It is appended below. It was discussed on the list in July, and
presented at the Stockholm IETF.

The posted I-D is largely just that email wrapped in boilerplate with
longer sentences.

> simply enough and if it is considered otherwise, I simply chose to call

As I said, until we developed the MKT/traffic key approach, it was not
possible to support NATs except via existing NAT traversal mechanisms
(e.g., that encapsulate), and that's what we had included.

This feature of the MKT/traffic key approach was recognized on the
multipath mailing list (see traffic on 7/9).

...
> What do you mean by a "general mechanism" what makes TCP-MD5 specific?

Basically, its "applicability statement", at least as much of one as it
describes.

> cannot use the recommended, existing security mechanism (called as

These "needs" were the first half of what we already indicate:

	- when users don't want to use IPsec

That hasn't changed.

The second "need" is to have keys change on a per-connection basis,
which we already describe.

> handful of protocols. (of course important ones)

Please do look at the mailing list archives. The issue of NATs was
raised many years ago. The issue of generality and even NAT support was
raised when the design team was formed.

Joe

Subject: possible NAT support for TCP-AO
From: Joe Touch <[email-masked]>
To: tcpm Extensions WG <[email-masked]>
Date: Mon, 13 Jul 2009 13:58:19 -0700

Hi, all,

Based on a discussion on a different list with Dan Wing, I'd like to
revisit thinking about NATs in the context of the current AO, which uses
traffic keys derived from the socket pair and ISN pair. We might be able
to now support NATs as follows, e.g.:

	add the following flags to the MKT:

		localNAT flag - indicates whether the local IP/port are
			zeroed before MAC calculation

		remoteNAT flag - indicates whether the remote IP/port
			are zeroed before MAC calculation

	add steps to the incoming/outgoing processing:
		zero the corresponding IP/port when the flag indicates,
		both on outgoing and incoming MAC calculation

That's basically it. A client behind a NAT would have a MKT with
localNAT true, and a server for that client would need to have a MKT
with remoteNAT true. This does require careful MKT configuration.
Although I wouldn't expect both localNAT and remoteNAT to be true, there
isn't a particular reason it needs to be prohibited.

Here's the security impact:

	- no impact to other connections (AFAICT)

	- SYN/SYN-ACKs limited only as much as the MKT TCP connection
	ID is, i.e., as a small range or single value rather than
	wildcard for either address or port

	- connections are reasonably well-protected once established,
	much like BTNS (due to use of both ISNs in the traffic keys)

	- reduced entropy for the traffic keys from a given MKT,
	since their input could be limited to the ISN pair in the
	worst case

I did NOT include this in TCP-AO-05, but it's simple enough to add if
useful. I'd like to ask that we think about this before Stockholm, and
discuss it on the list if possible in advance.

Joe

---

From: "Smith, Donald" <[email-masked]>
Date: Wed, 2 Dec 2009 08:12:56 -0700

Yes, connectionless resets being equal to spoofed resets is a major drawback and will hinder deployment in production systems.

(coffee != sleep) & (!coffee == sleep)
 [email-masked] gcia
________________________________
From: [email-masked] [[email-masked]] On Behalf Of Anantha Ramaiah (ananth) [[email-masked]]
Sent: Wednesday, December 02, 2009 2:13 AM
To: Joe Touch
Cc: [email-masked]
Subject: Re: [tcpm] closing WGLC for TCP-AO

<snip>

-Anantha

<snip>

________________________________
This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful. If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy
all copies of the communication and any attachments.

---

From: Joe Touch <[email-masked]>
Date: Wed, 02 Dec 2009 07:21:27 -0800

Smith, Donald wrote:
> Yes, connectionless resets being equal to spoofed resets is a major
> drawback and will hinder deployment in production systems.

It is present for IPsec as well. There's no way to recover generated
keys that are lost after a reboot.

The only solution is to save the relevant state so it is not lost after
a reboot.

Why do you believe this would be an issue? It's already present whenever
connections are not cleanly closed and addresses are reassigned to new
hosts.

It's simple enough for a server that really cares about the state kept
by such orphan connections to clean them up after a timeout.

Joe

---

From: "Smith, Donald" <[email-masked]>
Date: Wed, 2 Dec 2009 08:58:46 -0700

(coffee != sleep) & (!coffee == sleep)
 [email-masked] gcia
________________________________
From: Joe Touch [[email-masked]]
Sent: Wednesday, December 02, 2009 8:21 AM
To: Smith, Donald
Cc: Anantha Ramaiah (ananth); [email-masked]
Subject: Re: [tcpm] closing WGLC for TCP-AO

>The only solution is to save the relevant state so it is not lost after

And I think for tcp-ao and bgp that should be the recommended solution (at least a should if not a must).

>connections are not cleanly closed and addresses are reassigned to new

My main area of concern here is BGP. When a router reboots and can not reset its neighbors bgp sessions depending on various timers you can have long delays before the restarting speaker can get neighbors to accept new connections. In one senerio we had to remove the MD5 auth to allow connectionless resets to terminate the old sessons before new sessions could be established. This changed convergence time from minutes to seconds.

>by such orphan connections to clean them up after a timeout.
True, I don't have an issue with the orphan connections in most cases but in bgp esp single session bgp this can have quite an impact on restablishment and convergence times.

---

From: Joe Touch <[email-masked]>
Date: Wed, 02 Dec 2009 08:18:35 -0800

Smith, Donald wrote:
> ... Smith, Donald wrote:
>>> Yes, connectionless resets being equal to spoofed resets is a
>>> major drawback and will hinder deployment in production systems.
> 
>> It is present for IPsec as well. There's no way to recover
>> generated keys that are lost after a reboot.
> 
>> The only solution is to save the relevant state so it is not lost
>> after a reboot.
> 
> And I think for tcp-ao and bgp that should be the recommended
> solution (at least a should if not a must).

That helps only if this is a reboot issue. If the host simply disappears
and the address is reassigned, then there's no such recovery possible.

>> Why do you believe this would be an issue? It's already present
>> whenever connections are not cleanly closed and addresses are
>> reassigned to new hosts.
> 
> My main area of concern here is BGP. When a router reboots and can 
> not reset its neighbors bgp sessions depending on various timers you 
> can have long delays before the restarting speaker can get neighbors 
> to accept new connections. In one senerio we had to remove the MD5 
> auth to allow connectionless resets to terminate the old sessons 
> before new sessions could be established. This changed convergence 
> time from minutes to seconds.

First, this matters only when BOTH port numbers are reused.

Second, if you have enough access to a machine to shut off TCP MD5, why
not simply clear out the stale connections?

There are numerous reasons not to want to keep security state on disk -
notably, it's a security hazard. This seems like an implementation issue
that is not specific to TCP-AO - any security solution requires that old
connections be purgeable by an operator.

>> It's simple enough for a server that really cares about the state
>> kept by such orphan connections to clean them up after a timeout.
> 
> True, I don't have an issue with the orphan connections in most cases
> but in bgp esp single session bgp this can have quite an impact on
> restablishment and convergence times.

The kind of state that needs to be kept for TCP-AO may make this very
complicated. The rebooting host needs to establish new connections with
new traffic keys, but needs to allow the connection to be reset with old
traffic keys.

This would strictly require keeping all traffic keys around until a new
connection is successfully established on a given socket pair. That
means keeping traffic keys (or enough info to reconstitute them)
basically forever, "just in case".

I'm not clear that this is a desirable alternative - the state required
could be huge, and the delays required to save the state to disk
reliably would impede the start of new connections (can't send SYN/ACK
until logging the ISNs, etc.). It seems more appropriate to adjust
existing timers,. and to try new connection attempt (with different
source ports) after a reasonable period of non-response.

Note that:

	- if the surviving side has data pending to send,
	that connection will be cleaned up due to existing
	TCP timeouts

	- if TCP has keepalives set, the same should be true
	even when there is no data to send

So wouldn't keepalives solve this?

Joe

---

From: Fernando Gont <[email-masked]>
Date: Wed, 02 Dec 2009 13:31:42 -0300

Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote:

> AO is an example of the second case; it's benefited from very long
> sesssions in some of our meetings (Dublin, Minneapolis, San
> Francisco, etc), and the mailing list traffic attests that a lot of
> people have read it, raised their issues, and had them addressed in
> document updates.  

FWIW, I raised at least a couple of times that the document should make
specific recommendations on what to do with ICMP messages. I have
skimmed through the last version of the I-D, and while it does mention
ICMP attacks, I don't think it provides concrete advice on what to do
about it.

If I were to implemente TCP-AO, one way or another I would have to make
a decision about what to do about ICMP. And there's no clear advice in
the current document wrt what to do about it.

Some specific comments:

Section 2.1:

>    o  TCP-AO does not authenticate ICMP messages (some ICMP messages may
>       be authenticated when using IPsec, depending on the
>       configuration).

It's not clear to me why if IPsec is there to authenticate some ICMP
messages, one would be using TCP-AO in the first place. (My take is that
IPsec won't be there).

Section 12:

>        f. Optional ICMP discard.
> 
>           The option should allow certain ICMPs to be discarded, notably
>           Type 3 (destination unreachable), Codes 2-4 (transport
>           protocol unreachable, port unreachable, or fragmentation
>           needed and IP DF field set), i.e., the ones indicating the
>           failure of the endpoint to communicate.

I don't think ICMP discard should be "optional". What's the point of
using TCP-AO if you still abort connections in response to ICMP errors?

IMO, it is a hole in the spec if this is left open. The spec should
recommend a default.

Also, this assumes PMTUD is not in use. What if PMTUD *is*¨in use?

Thanks,

---

From: Ron Bonica <[email-masked]>
Date: Wed, 2 Dec 2009 11:34:26 -0500

> True, I don't have an issue with the orphan connections in most cases but 
>in bgp esp single session bgp this can have quite an impact on restablishment 
>and convergence times.

One way to address this problem is to set the BGP Keepalive timer to a
sufficiently low value. The down side is that BGP will send bgp
keepalives more frequently. The up side is that you will detect this and
many other problems in a more timely manner.

                                        Ron

---

From: Joe Touch <[email-masked]>
Date: Wed, 02 Dec 2009 08:46:35 -0800

> ICMP attacks, I don't think it provides concrete advice on what to do

See Section 12 as noted below.

> the current document wrt what to do about it.

There was, AFAIR, no clear WG consensus on whether to require a
particular behavior as default.

> messages, one would be using TCP-AO in the first place. (My take is that

That paragraph isn't talking about using IPsec with TCP-AO; it's
discussing the properties of the two separately.

> Also, this assumes PMTUD is not in use. What if PMTUD *is*¨in use?

Well, there's you're reason for not having this as a default. If you do,
then you have a MTU discovery black hole you didn't know about.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 02 Dec 2009 08:50:02 -0800

Additionally:

   >> A TCP-AO implementation MUST allow the system administrator to
   configure whether TCP will ignore incoming ICMP messages of Type 3
   (destination unreachable) Codes 2-4 (protocol unreachable, port
   unreachable, and fragmentation needed - 'hard errors') intended for
   connections that match MKTs. An implementation SHOULD allow ignored
   ICMPs to be logged.

   This control affects only ICMPs that currently require 'hard errors',
   which would abort the TCP connection [RFC1122]. This recommendation
   is intended to be similar to how IPsec would handle those messages
   [RFC4301].

> messages, one would be using TCP-AO in the first place. (My take is that

Note also that this is in the summary explaining how TCP-AO is different
from IPsec, so I think the intent of the statement is clear.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 02 Dec 2009 09:02:29 -0800

Hi, all,

> has passed.  I didn't see any major issues that were identified.

Well, apparently everyone took that as the invitation for a real last
call. I'll summarize the issues, with some questions to the WG:

- - discarding RSTs after reboot

	QUESTION: whether to include a note about
	recommending TCP keepalive on both ends where this is a concern,
	additionally:

	include that the side that is blocking (not the side rebooting)
	needs to have the keepalive set

	include a note that the alternative is to prevent destruction
	of state due to a reboot, but that a similar
	effect happens when a machine is replaced
	or when an address is reassigned

- - ICMPs

	QUESTION: whether to recommend discard hard ICMPs
	for TCP-AO protected connections as a MUST or SHOULD

Note - at this point, AFAICT we'd be seeking consensus, so even if you
agree, please post.

Given we're already past last-call, I'd presume we could close the call
for responses after a very short interval.

Were there any other specific issues?

Joe

---

From: Fernando Gont <[email-masked]>
Date: Wed, 02 Dec 2009 14:15:26 -0300

> particular behavior as default.

I don't think this issues was even discussed. I raised it, but other
than your response, there was no discussion about it.

> then you have a MTU discovery black hole you didn't know about.

Let me rephrase my comment:

TCP-AO should make a specific recommendation on how to deal with ICMP.

This means it may recommend ignore ICMP hard errors (or, well, process
them as soft errors) *and* implement PLPMTUD, or whatever.

But I don't think this should be left unspecified. Everyone will have to
make this decision when TCP-AO is implemented. So we would be washing
our hands about this problem, and what's worse, chances are that some
implementation will end up doing the wrong thing.

Note: I think this issue can be easily addressed. And I'm trying to be
constructive.

Thanks,

---

From: "Smith, Donald" <[email-masked]>
Date: Wed, 2 Dec 2009 10:22:24 -0700

(coffee != sleep) & (!coffee == sleep)
 [email-masked]<mailto:[email-masked]>
________________________________
From: Joe Touch [[email-masked]]
Sent: Wednesday, December 02, 2009 9:18 AM
To: Smith, Donald
Cc: Anantha Ramaiah (ananth); [email-masked]
Subject: Re: [tcpm] closing WGLC for TCP-AO

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Smith, Donald wrote:
> > ... Smith, Donald wrote:

Agreed, but that almost never happens to bgp peers:)

> First, this matters only when BOTH port numbers are reused.
No if a single session bgp speaker reboots his peers will NOT allow a new session to establish till the hold timer (or some other timer) expires.

In graceful restart mode a receiving speaker should treat a new session from the restarting speaker as reason to terminate the old session but we have seen implementations that do not follow the rfc.

> not simply clear out the stale connections?

This needs to be automatic. Turning off md5 auth was a manual task that I wouldn't normally recommend be done on

live productions systems.

> notably, it's a security hazard.
Assuming good physical and logical security I would argue this isn't much of a hazard.
Most routers already store various security creditential, including a password of last resort, on disk often in a reversable encrypted state.

>This seems like an implementation issue

Agreed, but you don't want to be doing this on production bgp speakers in real time.
So either you disable it per your base configuration or accept connectionless resets won't work.

> new traffic keys, but needs to allow the connection to be reset with old

Not quite, the rebooting host needs to be able to reset the old session to its peers with the old keys.
It doesn't need it's old session reset.

> basically forever, "just in case".

Not forever. This could probably be tied to the GR restart time.

Without GR you could have a "reboot" timer so some sort so you keep old keys for a reasonable amount of time.

> could be huge, and the delays required to save the state to disk

I don't think it is huge if a router had 20 peers that would be 20 keys.

> until logging the ISNs, etc.).

Actually I think you would want to log the key or ISNs after the three way was successful.
Perhaps even after a successful open msg?

>It seems more appropriate to adjust

Which tend to be fairly long (minutes, multiple retrys ...) and are not always adjustable.

The bgp hold timer usually comes into play first depending on the value you have assigned to that.

>         even when there is no data to send

I haven't seen a bgp implementation that relied on tcp keepalives.

Most use the hold timer and keep alive advertisement specific to bgp.

The recommend minimum for holdtimer and KA is 21/7 seconds.

Which if your trying for a HA type failover is a LONG time.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
>
> iEYEARECAAYFAksWk1sACgkQE5f5cImnZruCMwCg5ZsR7wewwmuvXwyZyP2Zf3Ri
> jHgAoK0QelKNd6KMycYPjPSj1PZRJx9E
> =FoLh
> -----END PGP SIGNATURE-----
>
>

---

From: Joe Touch <[email-masked]>
Date: Wed, 02 Dec 2009 09:32:34 -0800

Smith, Donald wrote:
...
> It doesn't need it's old session reset.

The state is at the non-rebooting side.

When the rebooting side tries to connect, it will receive a RST back,
which will have the old keys and be ignored.

The only way the non-rebooting side would receive a RST would be because
it's still trying to send data, at which point TCP would time-out
anyway. As Ron noted - this can be adjusted with the hold-down timers.

> Not forever. This could probably be tied to the GR restart time.

You need to hold onto the keys as long as it might ever take to have an
endpoint restart. Note that restarting also means being physically
replaced with a new system with the same IP address, i.e., upgraded -
e.g., as would happen when the old system died rather than being safely
shut down.

> Perhaps even after a successful open msg?

You'd need to do it before you got into a TCP state that doesn't have an
idle timeout. If you want 'responsiveness',  you'd need to do it for
basically any TCP transition.

...
> Which if your trying for a HA type failover is a LONG time.

That's seconds. I can't see changing a protocol to save seconds for an
event that - if frequent - is more indicative of a problem with a router
than a problem with a protocol.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 02 Dec 2009 09:37:56 -0800

Fernando Gont wrote:
...
> them as soft errors) 

That might be reasonable.

> *and* implement PLPMTUD,

We could note that this could be used, but I don't see us requiring
something that heavyweight by default.

> or whatever.

Can you be more specific?

> But I don't think this should be left unspecified.

You've made that point before. I've made the point that it is
unspecified as a default for IPsec. Let's hear from others.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Wed, 02 Dec 2009 15:00:44 -0300

> something that heavyweight by default.

I agree that PLPMTUD is heavyweight -- just proposed that as a
NIH-suggestion.

I would argue that the mechanism described in the ICMP attacks I-D is
easy to implement (I did it myself), and unless you can interrupt the
packet flow, it is hard to tamper with (and is certainly better than
nothing, anyway).

> Can you be more specific?

ignoring hard errors (or processing them as soft errors) *and*
implementing the PMTUD mitigation technique in the ICMP I-D is another
possibility.

For the BGP-use case, one might argue that you could probably safely
ignores ICMP PTB that advertise a small MTU.

> unspecified as a default for IPsec. 

There are lots of things that have been left unspecified. Both in IPsec,
TCP MD5, and others. That doesn't mean that we should re-hash that.

Thanks,

---

From: "Smith, Donald" <[email-masked]>
Date: Wed, 2 Dec 2009 11:10:21 -0700

Sent: Wednesday, December 02, 2009 10:32 AM

> The state is at the non-rebooting side.
No the non-rebooting side still "thinks" it has a session with the restarting/rebooting peer.
It is the rebooting side that needs to be able to send an authenticated reset to terminate the old peering session.

> which will have the old keys and be ignored.
No, when the rebooting side tries to connect (depending on if GR is enabled) you will see to different behaviors.
The rebooting router attempts to establish a new session.
The non-rebooting router allows that connection since this is a valid peer.
The rebooting router sends an open msg with its neighbor ID.
The non-rebooting router sees that is already has that neighbor ID in its data base and sends some type of msg usually a notify error msg.

They do a 3 or 4 way fin handshake to teardown the NEW session.

Depending on hold timer you may see this happen a few time:(

> anyway. As Ron noted - this can be adjusted with the hold-down timers.

That is the issue. The reset will be sent by the rebooting router on the first packet from the non-rebooting peer so at a minimum it will reset based on the next keepalive packet/timer (usually a 1/3 of the hold timer). So based on bcp's if you wait for the hold timer it will be three times as long before a session can be established.

> than a problem with a protocol.

In my example it is seconds but that is the minimum most holdtimers and KA are much longer then that.

In most of the implementations I have seen the default in most cases is minutes.

Cisco uses 60/180 KA/holdtime.

http://www.cisco.com/en/US/docs/ios/12_0/np1/configuration/guide/1cbgp.html

Juniper appears to use 30/90 http://www.juniper.net/techpubs/software/junos/junos56/swcmdref56/html/bgp-monitor5.html

If your also using a deferal timer to allow an igp to converge before sending out route updates you have to add that to the hold-timer.

> iEYEARECAAYFAksWpLIACgkQE5f5cImnZrvv6gCfZdXLrQpM2p2joBkQlnec6lCn
> rRkAni9sEUI3Usx0L8sNn4PIwcdq21pV
> =/Mf4

---

From: Joe Touch <[email-masked]>
Date: Wed, 02 Dec 2009 10:10:49 -0800

> than your response, there was no discussion about it.

You raised it 6/16, and on 6/16 agreed to the text that the doc now
includes (see snip below). You did say we ought to consider a default at
that time (and in a few followup posts, all on the same day). As you
note, nobody else posted on this issue.

Joe

- ---

> We could add that TCP-AO, like IPsec (text copied from 4301):
> >
> >    ...A compliant TCP-AO
> >    implementation MUST permit a local administrator to configure an
> >    IPsec implementation to accept or reject unauthenticated ICMP
> >    traffic.  This control MUST be at the granularity of ICMP type and
> >    MAY be at the granularity of ICMP type and code.  Additionally, an
> >    implementation SHOULD incorporate mechanisms and parameters for
> >    dealing with such traffic.  For example, there could be the ability
> >    to establish a minimum PMTU for traffic (on a per destination basis),
> >    to prevent receipt of an unauthenticated ICMP from setting the PMTU
> >    to a trivial size.

Makes sense to me. Although, again, I believe there should be (safe)
defaults for this.

---

From: Joe Touch <[email-masked]>
Date: Wed, 02 Dec 2009 10:21:19 -0800

> packet flow, it is hard to tamper with (and is certainly better than

We can refer off to that doc; it'd be preferable if that were just
"possible ways to deal with it" than normative (as a MUST).

> implementing the PMTUD mitigation technique in the ICMP I-D is another

OK - we can refer off to that doc (presumably you mean Sec 7.2 of that I-D).

> ignores ICMP PTB that advertise a small MTU.

I'm trying to recall where I saw that there might be a threshold for
MTUs from PTBs that would be larger than 68.

I think you're suggesting that BGP might declare that the min would need
to be high enough to make routing to that node useful, right? We can
note that as well.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 02 Dec 2009 10:56:40 -0800

Donald,

Please jump to the word "understand" below.

I've responded linearly, but we need to get on the same page as to
whether you're assuming the rebooted router reuses the port pair or not.

If the ports are NOT reused, then there's a BGP issue to discuss.

If they ARE reused, then I think we've already covered a useful and
sufficient solution (TCP keepalives).

Joe
__________________________
> No the non-rebooting side still "thinks" it has a session with the restarting/rebooting peer.

Right - that's why I said the state is at he non-rebooting side.

> It is the rebooting side that needs to be able to send an
> authenticated reset to terminate the old peering session.

(this presumes BGP is trying to restart a connection with the same port
pair - which it really shouldn't at least for 2*MSL, due to TIME_WAIT
rules -- it can't know it wasn't in TIME_WAIT before the reboot).

(if BGP is NOT restarting a connection with the old port pair, please
ignore this and jump to "understand" below)

Either side can send the RST and have that effect (presuming it's
accepted).

Consider two cases of the non-rebooting side, ignoring the effects of
TCP-AO (i.e., a non-TCP-AO connection):

1) nonrebooter has data to send or keepalives set

	nonrebooter sends a segment

	rebooter receives a segment while not in ESTABLISHED

		rebooter returns a RST and clears out state

2) nonrebooter has no data AND keepalives is not set
	
	rebooter sends a SYN

	- if the SYN is in-window:

		non-rebooter sends a RST, clear out the state,
		goes to CLOSED

		either the RST is received by the rebooter:

			which clears out its state too

		or it's lost:

			the rebooter resends the SYN,
			which is handled correctly

	- if the SYN isn't in-window:

		the nonrebooter sends the ACK of the last
		data received, without the SYN set

		the rebooter receives the ACK in SYN-SENT state
		if in-window:
		
			this gets silently dropped because
			the SYN isn't set	
			** TO: this results in a timeout stall

		if not in-window:

			rebooter sends a RST and clears out state

Note that many of these cause timeout problems (see "TO").

Let's consider what happens when TCP-AO is running and the keys are lost
by the rebooter:

1) nonrebooter has data to send or keepalives set

	nonrebooter sends a segment

	rebooter silently discards the segment

	nonrebooter times out and flushes its connection locally

2) nonrebooter has no data AND keepalives is not set
	
	rebooter sends a SYN

	nonrebooter silently drops the SYN

		No forward progress

So basically this is an issue only when keepalives are not set and when
there is no data to send on the nonrebooter side.

> The non-rebooting router allows that connection since this is a valid peer.

I think I may understand better; I think you're assuming that:

	- new connections use new ports, thus they are NOT blocked
	by TCP-AO

	- the interference is at the BGP level due to multiple open
	connections to the same neighbor ID

If that's correct, then we can proceed below. If not, then you're
talking not only about keeping old keys, but keeping TCP connection
state after a reboot. Otherwise, you'd never know which port pair to reuse.

IMO, if you don't reuse the port pair, then you might have a BGP issue
(but see below).

If you do reuse the port pair, you should use TCP keepaliaves and it'll
all work fine (as noted above).

> The rebooting router sends an open msg with its neighbor ID.

If using a different port pair, this would work.

> The non-rebooting router sees that is already has that neighbor ID in
> its data base and sends some type of msg usually a notify error msg.

This depends on the keepalive time, but yes, if the nonrebooting side
hasn't flushed the state this would happen.

> They do a 3 or 4 way fin handshake to teardown the NEW session.

Sounds like you want it to tear down the old session when this happens,
not the new one. If you did, then the nonrebooting router would issue an
ABORT, send a RST, and clear out its state. The rebooting router would
ignore the RST because it wouldn't match keys. Everything would work
fine at that point.

...
> That is the issue. The reset will be sent by the rebooting router on
> the first packet from the non-rebooting peer so at a minimum it will
> reset based on the next keepalive packet/timer (usually a 1/3 of the
> hold timer). So based on bcp's if you wait for the hold timer it will be
> three times as long before a session can be established.

So you're relying on the rebooting router to clear out the dup state at
the nonrebooting one.

That sounds like a poor implementation decision to me (though, IMO,
there are numerous such problems with BGP, including relying on TCP
connectivity to establish peering availability).

What you want is new successful connections to *immediately* clear out
old ones. Otherwise, let the old ones time out naturally if the other
side isn't there.

This way you recover more quickly when you can, and don't break things
when you can't.

I.e., this is an application TCP issue, not a TCP-AO issue. We could
note it in TCP-AO, but it would be more useful to address in the KART
WG, IMO.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Wed, 02 Dec 2009 16:21:16 -0300

> "possible ways to deal with it" than normative (as a MUST).

"MUST" would be too much. But I think it deserves a SHOULD. If not the
particular mitigation, at least "some" mitigation.

> OK - we can refer off to that doc (presumably you mean Sec 7.2 of that I-D).

Yes, Section 7.2

> MTUs from PTBs that would be larger than 68.

Some systems (e.g. OpenBSD) enforce a minimum MTU of 296 for he general
case (it is hardcoded in the stack).

For the BGP scenario, my take is that this thershold could be raised
much more.

> to be high enough to make routing to that node useful, right? We can

Not just useful: are there any BGP peers with an MTU of, say, 600 bytes?
 (i.e., does that really happen in practice)

Thanks,

---

From: Joe Touch <[email-masked]>
Date: Wed, 02 Dec 2009 11:38:28 -0800

> particular mitigation, at least "some" mitigation.

So there are several parts:

	- ignore certain hard ICMPs (as already listed)
		MUST be able to ignore
		MUST be configurable
		MUST be defaulted to ON ?

	- consider additional mechanisms for ICMP PTB
		I don't know if we can go much beyond
		"consider", though. Even SHOULD would
		be normative, and it's not described in
		a way that is really normative.

		I don't know what we would put after SHOULD,
		i.e., - SHOULD what, exactly?

...
> For the BGP scenario, my take is that this thershold could be raised

If we did have a threshold, I can't see why it would be much higher than
296. The impact of packets that small, vs., e.g., 576, isn't all that bad.

>  (i.e., does that really happen in practice)

I don't know, but I can't see why BGP should care (vs., e.g., 1500?)

Joe

---

From: "Smith, Donald" <[email-masked]>
Date: Wed, 2 Dec 2009 14:18:26 -0700

Sent: Wednesday, December 02, 2009 11:56 AM

> whether you're assuming the rebooted router reuses the port pair or not.
Yes, I realize now you assumed port reuse and I was not assuming that.
That explains part of our misunderstanding.

> sufficient solution (TCP keepalives).
Application specific KAs which are normally fairly long.

> > Cc: Anantha Ramaiah (ananth); [email-masked]<mailto:[email-masked]>
> >>> > > Not quite, the rebooting host needs to be able to reset the
>>>>>>> old session to
> >>> >> its peers with the old keys.
> > No, when the rebooting side tries to connect
> > (depending on if GR is enabled) you will see to different behaviors.
correct.
>         connections to the same neighbor ID
Correct.

> If using a different port pair, this would work.
It works from the standpoint of that a new bgp session can be established.
It doesn't work from the single session bgp standpoint.

> hasn't flushed the state this would happen.

If GraceFull restart is enabled a new session attempt should trigger tear down

of the previous session. At least one implementation I have worked on did not

preform that way:(

> not the new one.
Correct per rfc4724
"4.2. Procedures for the Receiving Speaker When the Restarting Speaker restarts, the Receiving Speaker may or may not detect the termination of the TCP session with the Restarting Speaker, depending on the underlying TCP implementation, whether or not [BGP-AUTH] is in use, and the specific circumstances of the restart. In case it does not detect the termination of the old TCP session and still considers the BGP session as being established, it MUST treat the subsequent open connection from the peer as an indication of the termination of the old TCP session and act accordingly (when the Graceful Restart Capability has been received from the peer). See Section 8 for a description of this behavior in terms of the BGP finite state machine.

Read more: http://www.faqs.org/rfcs/rfc4724.html#ixzz0YZAF2SIr"

>If you did, then the nonrebooting router would issue an
> ABORT, send a RST, and clear out its state.
The ABORT won't work the rebooting router doesn't have
a bgp session with the non-rebooting router (anymore).
That would require a LOT more state to make work;)

The rst will probably also be ignored but that is ok.
As long as the nonrebooting router kills its session and drops the
router ID.

>The rebooting router would
It will ignore the reset because it didn't reuse the src/dst ports.

> So you're relying on the rebooting router to clear out the dup state at

To signal that the nonrebooting router should clear the "dup" state.

> old ones.
Yes and that is the expected behavior for GR enabled bgp sessions.
It is NOT for non-GR enabled bgp sessions. Without GR single session bgp
will have to wait for the hold time to expire before reestablishing an new session.
So an authenticated reset would still be helpful in that case.

>Otherwise, let the old ones time out naturally if the other
> side isn't there.

Yes based on hold time and possible other timers.

> note it in TCP-AO, but it would be more useful to address in the KART

I see where your headed but AFAIK most tcp-auth implementations were specificly implemented

for BGP. They were 'pushed' out due to blindly spoofed tcp reset within window issue identified by Gont.

So in my opinion a tcp-auth or tcp-ao rfc that doesn't address issues with bgp is less valuable then

one that does.

Additionally if a router or any device with multiple cpus wanted to do subminute
HA failover the ability to reuse the previous session would
require this type of state be maintained so that KA's or other bgp
msgs could be could be responded to with valid authentication.

Although I have been using bgp as the main long lived tcp session here that is because I am
familar with bgp. Other long lived tcp sessions would also benefit from this ability.

> iEYEARECAAYFAksWuGcACgkQE5f5cImnZrsplwCg+2nQbj9TmyVqOFtm1wsSXqv9
> IZkAoLUIJtckJa5lDa9wdHFltr4z7QsZ
> =Y18A

---

From: Joe Touch <[email-masked]>
Date: Wed, 02 Dec 2009 15:19:18 -0800

> of the previous session. At least one implementation I have worked on did not

So it seems like graceful restart is what you want, and it's already
specified. Would it be sufficient to note this?

> a bgp session with the non-rebooting router (anymore).

I was suggesting the nonrebooting router do the ABORT, not the rebooting
one. RFC4724 just says "close", so if that's sufficient, that's fine.

...
> So an authenticated reset would still be helpful in that case.

I don't see why the transport layer should be augmented to solve a
problem for which a standards-track solution is already available at the
application layer, and which makes sufficient sense.

...
> for BGP. They were 'pushed' out due to blindly spoofed tcp reset within window issue identified by Gont.

The issue was identified by Convery and Franz in 2003 - see RFC-4953.

> So in my opinion a tcp-auth or tcp-ao rfc that doesn't address issues with bgp is less valuable then

Fair enough - but IMO that argues for MUST/SHOULD graceful restart,
rather than including additional requirements for implementations to
recover state after reboot.

> msgs could be could be responded to with valid authentication.

I'm not sure I follow. You appear to be implying that multiple CPUs are
used without a single view of the connection state of the machine -
accessible across all CPUs. If that view isn't supported , you have more
problems than just TCP-AO.

> familar with bgp. Other long lived tcp sessions would also benefit from this ability.

It is BGP that is erroneously using TCP connectivity as a liveness
indicator, and that prefers a nonfunctioning previous connection to a
functioning new connection. I don't see why this doc needs to warn
against that sort of incorrect application semantics.

Joe

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 02 Dec 2009 19:27:37 -0800

At Tue, 1 Dec 2009 15:42:11 -0600,
> include it before it gets sent to the IESG.

Sorry, I've been pretty swamped and didn't get to this in time.

That said, I don't think that NAT should be added. I haven't
read the most recent version but don't remember being impressed
with the initial drafts I saw.

-Ekr

---

From: Joe Touch <[email-masked]>
Date: Wed, 02 Dec 2009 19:36:34 -0800

> with the initial drafts I saw.

A comment based on the draft, which has been available for over 6 weeks
and contains only 2 pages of content, would be useful if possible.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 02 Dec 2009 19:37:20 -0800

Eric Rescorla wrote:
...
> with the initial drafts I saw.

Also, it would be useful if you could raise a substantive concern to
accompany your impression. ;-)

Joe

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 02 Dec 2009 21:06:51 -0800

At Wed, 02 Dec 2009 19:37:20 -0800,
> accompany your impression. ;-)

Yes, I'll send comments on it once I have a chance to read it and
write some. If you prefer, I can of course just raise any issues
in IETF LC, but I thought people might appreciate a heads-up that
I likely wasn't in favor.

-Ekr

---

From: Joe Touch <[email-masked]>
Date: Wed, 02 Dec 2009 21:37:22 -0800

> I likely wasn't in favor.

It's great that you have such a well formed uninformed position. Feel
free to comment when your ready, whenever that is.

Joe

---

From: Chandrashekhar Appanna <[email-masked]>
Date: Wed, 2 Dec 2009 21:49:45 -0800

> I hope this clears things up for those of you who think this is odd.  It's not :).

  The entire process asociated with this draft has been very odd.. on
  all fronts it has shown exactly how the IETF should not do things.
  The fact that one vocal and nagging individual can usurp and upset
  the effort and the ideas that originated with others was definitely 
  odd to me..  I do not intend to debate or argue but since this is
  an open forum and opnions are being stated, I want to put mine in
  for the record too.

  0.02 :)
  Chandra.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 03 Dec 2009 09:36:12 -0800

At Wed, 02 Dec 2009 21:37:22 -0800,
Joe Touch wrote:
> It's great that you have such a well formed uninformed position.

Joe, this sort of personal attack is really uncalled for.

I've been doing other things for the past few weeks and while still
swamped only just noticed the last call had ended, remembered I
didn't like this draft, and thought it would be good to register
*some* objection rather than just sandbagging people in IETF LC.

In any case, now that I've had time to sleep on it, I recall what
the issue is: it puts way too much stress on the ISN-based
uniqueness mechanism.

As should be immediately apparent, with TCP-AO if the connection
parameters are ever reused an attacker can then replay traffic from
one connection to another. However, because the host/port quartet is
included in the MAC calculation (and the KDF, but that isn't necessary
for this discussion), you cannot cut and paste traffic between
connections originated between two different pairs of hosts, even if
they use the same underlying master key. Now, you may say that that's
bad key hygiene, but it's actually likely to be quite common if (for
instance) two sites have multiple adjacencies but use the same key for
each one.  In any case, the current structure of AO completely
prevents such attacks.  By contrast, with this extension, if the
parameters are ever reused then an attacker can potentially
cut-and-paste between connections initiated by two remote hosts, even
those not behind the same NAT (because it blocks out the entire IP,
not just narrows it to some subrange).

Of course, it's reasonable to ask how likely reuse is. Consider
the obvious case where Alice and Bob are both behind NATs and they are
connecting to Charlie, which has a fixed IP address. I.e.

Alice   --- NAT ------------------------------   
                                                 Charlie
Bob     --- NAT ------------------------------

Thus Alice and Bob have localNAT set and Charlie has remoteNAT set.

Now, if Alice and Bob and Charlie all share the same key, then they
can clearly impersonate each other, but that's OK in some cases,
for instance if they are all operated by the same people (or at 
least Alice and Bob are).

Now, for the protocol parameters: Charlie's side of the connection
likely has a constant IP and port, so that doesn't contribute to
uniqueness. Alice and Bob's sides are wiped out so they don't.
This only leaves the ISNs (note that this is contrary to the
Security Considerations analysis, which suggests that it's only
a problem if you use the NAT flag on both sides) as security,
so at best you have 64 bits of uniqueness, but if the PRNGs
aren't strong, it's potentially much worse. Moreover, an attacker
who captures some corpus of initial SYNs can potentially probe
Charlie from a variety of source addresses/ports in whatever
the acceptable range is in an attempt to elicit a correct
SYN/ACK. This removes the issue of the client ISN and brings
us down to a 2^32 (at best) attack level.[*]

This seems to me to undercut the basic AO security guarantees.

-Ekr

P.S. The entropy analysis in the security considerations seems
incorrect. For starters, there is nowhere near 32 bits of entropy
in an IP address or port since neither is chosen from a uniform
range (especially in the case of server ports).

[*] Actually, probably worse, since the standard randomization
solutions tend to randomly distribute the starting point only
and so you can choose a good starting point and then linearly
home in.

---

From: Joe Touch <[email-masked]>
Date: Thu, 03 Dec 2009 10:14:50 -0800

> *some* objection rather than just sandbagging people in IETF LC.

I object to "I didn't read the draft but..." sorts of comments. They are
unprofessional at best, and disrespectful to the list as well as
authors. If you have a concern, voice it with content.

> each one. 

We cannot correct for poor MKT management, nor should we try. IMO that
is the purvue of a KMS.

> In any case, the current structure of AO completely

This is possible when:

	a) the ISNs are repeated
AND
	b) the nonchanging adr/port is repeated (presuming at least one
	side doesn't change)

Note that an attacker can't know when this happens because omission of
the adr/port on one side isn't signalled on the wire. They would have to
wait around until the ISNs repeat (which is visible) AND the adr/port
pair repeats to ensure their attack would succeed.

Agreed that for hosts behind a NAT, the nonchanging adr/port may repeat
by reconnecting to a single host. But in order for an attack to succeed,
the ISNs of *both sides* would need to reappear. Even if one side were
to be reused, that's useless unless the other side also reuses its.

So this boils down to the chance that two ISN generators between two
machines ever repeat *as a pair*. IMO, that's fairly strong.

> aren't strong, it's potentially much worse. 

We can point out that the uniqueness is essentially only 64 bits even
when used on only one side.

> Moreover, an attacker

Your analysis presumes that sending repeated SYNs will elicit ISNs in a
known sequence. If they're created arbitrarily, esp. using a hash
function (see RFC 1948), then this attack isn't realistic AFAICT.

A client could easily detect an attempt of such an attack because it
would involve repeated receipt of a SYN with the same socket pair and
the same ISN - I would hope that an alarm could go off before 2^32 were
tried. We could add a note in the security considerations to address
that issue, which might be relevant regardless of whether NAT support is
included.

> range (especially in the case of server ports).

We'll update that. However, if that's true, then even the basic AO has
only the entropy of the ISNs, and *maybe* the entropy of the source
port. Noting that many implementations select from among only the
dynamic range, that entropy is fairly small (14 bits) at best. Gont's
analysis suggests that it's not even all that much, given the way in
which source ports are selected.

So basically we're relying on the entropy of the ISNs anyway.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 03 Dec 2009 10:53:21 -0800

At Thu, 03 Dec 2009 10:14:50 -0800,
Joe Touch wrote:
> authors.

Joe, to be blunt, you're hardly my guidepost on how to act professional
and respectful.

> If you have a concern, voice it with content.

As I have. The draft is broken for the reasons I indicated.

> We cannot correct for poor MKT management, nor should we try. IMO that

This is a fine key management practice. The problem is that the draft
weakens AO's security guarantees.

> the adr/port on one side isn't signalled on the wire.

Unless they have other information about the network structure, which
isn't at all unlikely.

> They would have to

No, that's not correct, because the attacker can force a repeat on the
client side by retransmitting the client's ISN, as I indicated below.

> function (see RFC 1948), then this attack isn't realistic AFAICT.

You misunderstand the 1948 algorithm, which simply adds a random
(but fixed for each socketpair) offset to the ISN sequence:

       ISN = M + F(localhost, localport, remotehost, remoteport).

Repeated probes indeed to produce ISNs in a specific sequence.

Moreover, the random start behavior is a feature for the attacker
because they can try scattered source ports and thus access
sparse initial starting points and thus reduce their search 
space.

> tried.

I prefer to have my security based on something other than hope.

> So basically we're relying on the entropy of the ISNs anyway.

Yes, AO relies on the entropy of the ISNs but the security guarantees
in case they are weak are much better than with this draft.

Chairs: You said that "Since several people supported
this, and none were against it." I am against it and I've posted
my reasons why. Given that it sounds like support was modest at
best, I think that's sufficient reason to say there's not
consensus for including this functionality in the version
sent to the IESG.

-Ekr

---

From: Lars Eggert <[email-masked]>
Date: Thu, 3 Dec 2009 09:00:50 -1000

Hi,

speaking as an individual contributor.

I believe the two drafts are ready for publication (modulo some minor editorial nits, see e.g. Wes' email.)

There is no question in my mind that we can continue to tweak the two docs forever, and maybe we'll even manage to substantially improve them. But I don't think that would the most productive use of our combined time. What we have is good enough to be published as PS, and needs to be published ASAP so people have a standards-track replacement for TCP-MD5.

Lars

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 03 Dec 2009 11:07:04 -0800

At Thu, 3 Dec 2009 09:00:50 -1000,
Lars Eggert wrote:
> There is no question in my mind that we can continue to tweak the
> two docs forever, and maybe we'll even manage to substantially
> improve them. But I don't think that would the most productive use
> of our combined time. What we have is good enough to be published as
> PS, and needs to be published ASAP so people have a standards-track
> replacement for TCP-MD5.

This does not apply to the NAT document, AFAIK. TCP-MD5 does not support
NATs. It's purely a feature enhancement. I don't see why it needs to
be rushed, and in view of the evident security problems, published
at all.

-Ekr

---

From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[email-masked]>
Date: Thu, 3 Dec 2009 13:08:19 -0600

>From: Eric Rescorla [mailto:[email-masked]]
>Sent: Thursday, December 03, 2009 1:53 PM
>To: Joe Touch
>Cc: Eric Rescorla; Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP];
>[email-masked]

Agreed; since there are apparently issues that will require
further detailed discussion, for the sake of moving the base
AO protocol forward in the near term, let's bookmark this in
the WG as a possible future extension to be considered, but
move AO forward without it for the moment.

We should take time to properly discuss the NAT extension
in TCPM rather than get heated with each other about it now.
Thanks for sharing your concerns at this juncture rather
than waiting for IETF LC; we should start a new thread to
continue the NAT topic since it's no longer related to
finishing the WGLC.

--
Wes Eddy
MTI Systems

---

From: Joe Touch <[email-masked]>
Date: Thu, 03 Dec 2009 11:24:08 -0800

Eric Rescorla wrote:
...
> Repeated probes indeed to produce ISNs in a specific sequence.

M is a 4ms timer. You'd need the timer to wrap around. Can you explan
why you think this presents a vulnerability?

Further F is intended to include more than just the presented arguments:

   It is vital that F not be computable from the outside, or an attacker
   could still guess at sequence numbers from the initial sequence
   number used for some other connection.  We therefore suggest that F
   be a cryptographic hash function of the connection-id and some secret
   data.  MD5 [9] is a good choice, since the code is widely available.
   The secret data can either be a true random number [10], or it can be
   the combination of some per-host secret and the boot time of the
   machine.  The boot time is included to ensure that the secret is
   changed on occasion.  Other data, such as the host's IP address and
   name, may be included in the hash as well; this eases administration
   by permitting a network of workstations to share the same secret data
   while still giving them separate sequence number spaces.  Our
   recommendation, in fact, is to use all three of these items: as
   random a number as the hardware can generate, an administratively-
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   installed pass phrase, and the machine's IP address.  This allows for
   local choice on how secure the secret is.

This would not be repeatable for a given set of inputs.

...
> I prefer to have my security based on something other than hope.

Would a recommendation (SHOULD) to put in an "excessive repeated SYN"
alarm be sufficient?

> in case they are weak are much better than with this draft.

This is the crux of your argument - that ISNs alone are insufficient,
but you haven't shown how adding the addrs and ports really adds much.
In fact, it was *you* who suggested adding the ISNs (see your post of
3/11/2008 to the design team), and *you* who is pointing out that the
addrs/ports don't add entropy.

By your argument, TCP-AO isn't as secure as you'd like (which may be the
case), but TCP-AO with NAT isn't substantially *less* secure.

Joe

---

From: David Borman <[email-masked]>
Date: Thu, 3 Dec 2009 13:30:06 -0600

I agree, we should move AO forward without NAT.  The NAT document can continue to be discussed, and if/when agreement is reached, at that time we'll have the option of either publishing it as a separate document, or making a rev of AO to add the NAT information, but we don't need to decide that right now.

			-David Borman, TCPM WG co-chair

---

From: Lars Eggert <[email-masked]>
Date: Thu, 3 Dec 2009 10:28:54 -1000

Hi,

> be rushed, and in view of the evident security problems, published

agreed. For the NAT stuff, I sent an earlier message (during WGLC). Based on the current discussion, it's not clear that it can be added quickly, because it seems to require some more discussion.

Begin forwarded message:
> From: "Eggert Lars (Nokia-NRC/Espoo)" <[email-masked]>
> Date: November 23, 2009 8:50:37 HST
> To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, Joe Touch <[email-masked]>
> Subject: Re: [tcpm] working group status 11/17/09
> 
> Hi,
> 
> without wearing any hats: if it can be added very quickly, i.e., O(days), I'd be mildly in favor. Otherwise, let's just ship what we have now.
> 
> Lars

Lars

---

From: "Smith, Donald" <[email-masked]>
Date: Thu, 3 Dec 2009 14:35:53 -0700

I object to this due to concerns previously expressed specifically connectionless resets == spoofed resets.

(coffee != sleep) & (!coffee == sleep)
 [email-masked]<mailto:[email-masked]>
________________________________
From: [email-masked] [[email-masked]] On Behalf Of Lars Eggert [[email-masked]]
Sent: Thursday, December 03, 2009 1:28 PM
To: Eric Rescorla
Cc: Joe Touch; [email-masked]
Subject: Re: [tcpm] closing WGLC for TCP-AO

Hi,

Lars

---

From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[email-masked]>
Date: Thu, 3 Dec 2009 15:47:56 -0600

Just to clarify, your reply isn't objecting to the decision
to not include NAT extensions, is it?

Based on the second line, it seems to be about the thread
Joe is trying to converge with you on:
http://www.ietf.org/mail-archive/web/tcpm/current/msg05058.html
Are his proposals there about noting the issue and how it
can be addressed via BGP graceful restart reasonable?

--
Wes Eddy
MTI Systems

>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Smith, Donald
>Sent: Thursday, December 03, 2009 4:36 PM
>To: Lars Eggert; Eric Rescorla
>Cc: [email-masked]; Joe Touch
>agreed. For the NAT stuff, I sent an earlier message (during WGLC).
>Based on the current discussion, it's not clear that it can be added
>quickly, because it seems to require some more discussion.
>
>Begin forwarded message:
>> without wearing any hats: if it can be added very quickly, i.e.,
>O(days), I'd be mildly in favor. Otherwise, let's just ship what we have
>now.
>>
>> Lars
>
>Lars
>

---

From: "Smith, Donald" <[email-masked]>
Date: Thu, 3 Dec 2009 15:09:27 -0700

No sorry I wasn't clear this is just related to the connectionless reset issue.
Not related to NAT inclusion at this time.

(coffee != sleep) & (!coffee == sleep)
 [email-masked]<mailto:[email-masked]>
________________________________
From: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] [[email-masked]]
Sent: Thursday, December 03, 2009 2:47 PM
To: Smith, Donald; Lars Eggert; Eric Rescorla
Cc: [email-masked]; Joe Touch
Subject: RE: [tcpm] closing WGLC for TCP-AO

--
Wes Eddy
MTI Systems

---

From: Joe Touch <[email-masked]>
Date: Thu, 03 Dec 2009 22:42:07 -0800

Lars Eggert wrote:
>> NATs. It's purely a feature enhancement.

That could be said of key changeover coordination, establishment of
per-connection ISN-based traffic keys, or even the idea of agile
algorithms. These are all things we added *because they weren't in TCP MD5*.

>> I don't see why it needs to

I'd like to take some time on the list to discuss these, because so far
all that has been claimed is that the traffic keys are somewhat weaker,
but not necessarily weak enough to present a real issue yet.

I.e., I don't want to rush to put this in, but I don't see why we would
rush to keep it out either.

Joe

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 04 Dec 2009 07:14:10 -0800

At Thu, 03 Dec 2009 11:24:08 -0800,
> why you think this presents a vulnerability?

But again, you don't. You just scatter around the source address/port
space until you find a reply ISN within a reasonable time of where you
want to be and then you wait.  Remember that you have 16 bits of port
to play with, so you can generally get a starting point within 65k
timer ticks.

>    random a number as the hardware can generate, an administratively-

Again, this produces a secret *offset* to the ordinary timer. Otherwise,
you couldn't guarantee timer monotonicity for a given connection_id.

> Would a recommendation (SHOULD) to put in an "excessive repeated SYN"

This seems like a nontrivial recommendation to follow.

> case), but TCP-AO with NAT isn't substantially *less* secure.

TCP-AO isn't as secure as I would like. I thought I made that pretty
clear from the beginning. However, the consequences of
TCP-AO repeats only include retransmitting packets within a given 
connection. That's not true here.

Stepping up a level: I don't understand what the motivation for this is:
TCP-AO is basically good for a fairly limited set of use cases where
people are worried about DoS and so they can't use TLS and they feel
IPsec is too heavyweight. To my knowledge, that set consists of basically
one application: BGP connections. What are the large set of behind-NAT
applications which have a need for TCP-AO?

-Ekr

---

From: Joe Touch <[email-masked]>
Date: Fri, 04 Dec 2009 13:25:56 -0800

Hi, Eric,

It might be useful to separate the issues you're raising:

- - concerns about ISN entropy

- - concerns about whether NAT support is needed

If NATs are supported, it seems like we're just at the mercy of the
entropy of the ISNs no matter what we do anyway. So there are two
options, AFAICT:

	1. include support for NATs

	2. do NOT include support for NATs

The second case means that NATs are not protectable at all using TCP-AO.
However, TCP-AO has been intended as supporting general use all along;
this isn't just about any known current uses. I don't see why we should
prohibit this, unless we believe it would compromise non-NAT connections.

Can we cover this concern with some directives, e.g.: (if you prefer a
different directive, please suggest one):

	NAT support MUST NOT change on a given connection, i.e.,
	the MKT used at connection start either supports NAT or not,
	and that support MUST match subsequent MKTs used
	with that connection.

Joe

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 4 Dec 2009 16:13:53 -0800

...
> Stepping up a level: I don't understand what the motivation 
> for this is:  TCP-AO is basically good for a fairly limited set 
> of use cases where people are worried about DoS and so they 
> can't use TLS and they feel IPsec is too heavyweight.  To my 
> knowledge, that set consists of basically one application: BGP 
> connections. What are the large set of behind-NAT applications 
> which have a need for TCP-AO?

TCP-AO could be useful for long-lived connections from applications
like SIP or XMPP.  Those TCP clients are often behind NATs.

Today, it also isn't that IPsec is 'too heavy'; applications are 
unaware of IPsec is providing encryption underneath the application.  
The new IPsec API would fix that - once it's available.  At which 
point we would be back to just the 'IPsec is heavy' complaint, think.

-d

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 05 Dec 2009 08:39:36 -0800

At Fri, 4 Dec 2009 16:13:53 -0800,
> like SIP or XMPP.  Those TCP clients are often behind NATs.

Those applications use TLS. I am unaware of any widespread
demand that those applications have for resistance to connection
level termination resistance.

-Ekr

---

From: "Dan Wing" <[email-masked]>
Date: Sat, 5 Dec 2009 11:44:30 -0800

> level termination resistance.

I am also unaware of widespread demand.

However, extending TCP-AO to support NAT, so that TLS can benefit
from the same sort of protection as DTLS, seems like it would 
create that demand.  Those applications are unlikely to switch
to IPsec-over-UDP merely to gain such functionality.

-d

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Mon, 7 Dec 2009 23:25:24 -0800

[catching up again]

> for this is:
> one application: BGP connections.

Exactly, this is the point which I was trying to emphasize as well when
I suggested an explicit "Applicability statement" to be put in place.
This gives advice/guidance to implementers as to why and when TCP-AO
should be used. TCP-secure draft has an AS put in place for similar
reasons. I don't see why we should not put an AS for TCP-AO whose usage
(practically speaking) is fairly restricted?

> What are the large set of behind-NAT

None, to my knowledge.

-Anantha

---

From: "Smith, Donald" <[email-masked]>
Date: Tue, 8 Dec 2009 08:49:44 -0700

Until Connection_less_resets != Spoofed_resets
I know a lot of people can't use this for bgp which seems to be one of the main reasons this was written.

In a separate email with Joe, I recommended a SHOULD for "maintain enough state across reboot to be able to send
authenticated resets". Not a MUST but as a SHOULD or even a MAY then engineers can point to the standard and in their RFC process require this state across reboot if they need it.

(coffee != sleep) & (!coffee == sleep)
 [email-masked]<mailto:[email-masked]>
________________________________
From: [email-masked] [[email-masked]] On Behalf Of Anantha Ramaiah (ananth) [[email-masked]]
Sent: Tuesday, December 08, 2009 12:25 AM
To: Eric Rescorla; Joe Touch
Cc: [email-masked]
Subject: Re: [tcpm] closing WGLC for TCP-AO

 [catching up again]

None, to my knowledge.

-Anantha

---

From: Fernando Gont <[email-masked]>
Date: Tue, 08 Dec 2009 17:29:07 -0300

> (practically speaking) is fairly restricted?

Actually, not including an AS in TCP-AO would be rather ironic.

We have an AS in tcp-secure, which describes mitigations every
real-world stack wants to have enabled.

Therefore, not having an AS in TCP-AO (whose usage is fairly restricted)
would be "incongruent".

Thanks,

---

From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[email-masked]>
Date: Tue, 8 Dec 2009 14:41:42 -0600

I think we could pretty easily craft an applicability
statement; the essence of one is already started in the
abstract:

   The result is intended to support
   current infrastructure uses of TCP MD5, such as to protect long-lived
   connections (as used, e.g., in BGP and LDP), and to support a larger
   set of MACs with minimal other system and operational changes.

So we'd just need to flesh that out in a new section
for an Applicability Statement and be more explicit
about how IPsec and TLS relate (or don't), which the
Introduction already partially covers too.

What do you think Joe?

--
Wes Eddy
MTI Systems

>Sent: Tuesday, December 08, 2009 3:29 PM

---

From: Joe Touch <[email-masked]>
Date: Tue, 08 Dec 2009 13:20:07 -0800

> Introduction already partially covers too.

I think this is all about two things:

- - the desire for a header before the paragraph below that actually says
"Applicability Statement":

   This document is not intended to replace the use of the IPsec suite
   (IPsec and IKE) to protect TCP connections [RFC4301][RFC4306]. In
   fact, we recommend the use of IPsec and IKE, especially where IKE's
   level of existing support for parameter negotiation, session key
   negotiation, or rekeying are desired. TCP-AO is intended for use only
   where the IPsec suite would not be feasible, e.g., as has been
   suggested is the case to support some routing protocols, or in cases
   where keys need to be tightly coordinated with individual transport
   sessions [Be07].

- - the desire for one more sentence or two explaining the difference
between TCP-AO and TLS

- - the desire to move the some (or all) of the discussion in 2.1 into the
AS section

This is all easy to do.

However, I would not assume that this would say "use TCP-AO only for BGP".

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 08 Dec 2009 13:25:05 -0800

...
> I think this is all about two things:

Before anyone jumps, yes, there were three things listed; they fall into
two groups:

- - wanting a header
- - wanting things moved around under that header, with one additional point

PS: the TLS point can trivially be made in one sentence by referring to
 RFC 4953.

Joe

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 08 Dec 2009 20:57:12 -0800

At Tue, 08 Dec 2009 13:20:07 -0800,
> However, I would not assume that this would say "use TCP-AO only for BGP".

I would assume not either. Rather, we should tell people what it does
and let them make their own decisions about what it's good for.

I would suggest something like:

The primary feature that this document offers that TLS does not is
that it operates at the transport layer whereas TLS operates above
the transport layer. Thus, while TLS provides for data integrity 
it is not resistant to DoS attacks on the transport layer; in
fact it is especially sensitive because any damage to the 
byte stream results in a MAC failure and connection termination.
By contrast, TLS currently offers a far richer set of key
management and authentication primitives and is thus a superior
choice when DoS is not a concern.

-Ekr

---

From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[email-masked]>
Date: Wed, 9 Dec 2009 00:13:23 -0600

It sounds like people are asking for a clear header with the relevant text arranged under it, since the tcpsecure document was referenced as an example.

I fully agree on including a pointer to 4953; it would be good to use as a reference following the text Eric sent.

________________________________________
From: Joe Touch [[email-masked]]
Sent: Tuesday, December 08, 2009 4:25 PM
To: Joe Touch
Cc: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]; Fernando Gont; Anantha Ramaiah (ananth); [email-masked]
Subject: Re: [tcpm] closing WGLC for TCP-AO

...

- - wanting a header

Joe

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Tue, 8 Dec 2009 22:24:34 -0800

> - - the desire for a header before the paragraph below that 
> actually says "Applicability Statement":
> 
>    suggested is the case to support some routing protocols, 

Now, "as has been suggested" comes across dubious. Where it has been
suggested, a reference would help or more qualification of the above
statement is desired.

The reason being, a reader would appreciate either a self-contained
paragraph on why AO was desired (some of the reasons are the same as why
TCP-MD5 was needed in the first place)  why IPsec cannot be used, why
SO-BGP cannot address this issue, or just quote references to documents
where such an analysis has already been done.

So the AS should spell out these things, IMO.

> or in cases

This above statement is fine since it has a reference attached to it.

-Anantha

---

From: Andrew Lange <[email-masked]>
Date: Wed, 9 Dec 2009 11:13:55 -0800

Joe,

I find your protestations about "rushing to keep NAT out" rather disingenuous.  The WG agreed, including yourself, in Stockholm that NAT would be moved out of -AO and into a separate draft for further consideration.   The purpose of this move was not to continue to conflate the two issues of -AO and NAT support for -AO.  Continuing to press the point goes directly against the intent of the move to a separate document.  This issue is indicative of how poorly this entire process has gone. 

The one constant that is consistently identified as being the cause of this going badly is the most vocal of the -AO document editors.  There is a clear conflict at this point between the editor as an author and as someone who can update the document to reflect WG consensus.  I would like to move that the WG remove that editor and ask the co-editors to take a more active role in putting the final touches on this document.  Things will go much more smoothly, and more accurately reflect the WG's combined opinion if we put and end to this obvious conflict-of-interest.

Andrew

On Dec 3, 2009, at 10:42 PM, Joe Touch wrote:

> iEYEARECAAYFAksYrz8ACgkQE5f5cImnZrs+NgCeO/r96odyLabjArBOvP7NgMfZ
> /A0An3q86VK/pk8LBerDJc8qYeKlVmw2
> =YvjI

---

From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[email-masked]>
Date: Wed, 9 Dec 2009 13:53:22 -0600

Last week both TCPM co-chairs indicated that the path forward is
to leave NAT out for now:

http://www.ietf.org/mail-archive/web/tcpm/current/msg05074.html
http://www.ietf.org/mail-archive/web/tcpm/current/msg05072.html

I think Joe is already working on a document update, and assumed
that it won't include NAT, but that he's just continuing the
thread while the topic is fresh in people's minds ... I think
since the expected update (including the WG consensus to leave
out NAT, for now) is in-progress and then the document will be
sent to the IESG for publication, shuffling editors isn't
called for and would only slow completion of the document down.

To avoid any confusion, it seems like a good idea to table the
NAT discussion for now and revive it later if there's desire,
after the document has progressed.

--
Wes Eddy
MTI Systems

>Andrew Lange
>Sent: Wednesday, December 09, 2009 2:14 PM
>To: Joe Touch
>Cc: [email-masked]
>I find your protestations about "rushing to keep NAT out" rather
>disingenuous.  The WG agreed, including yourself, in Stockholm that NAT
>would be moved out of -AO and into a separate draft for further
>consideration.   The purpose of this move was not to continue to
>conflate the two issues of -AO and NAT support for -AO.  Continuing to
>press the point goes directly against the intent of the move to a
>separate document.  This issue is indicative of how poorly this entire
>process has gone.
>
>The one constant that is consistently identified as being the cause of
>this going badly is the most vocal of the -AO document editors.  There
>is a clear conflict at this point between the editor as an author and as
>someone who can update the document to reflect WG consensus.  I would
>like to move that the WG remove that editor and ask the co-editors to
>take a more active role in putting the final touches on this document.
>Things will go much more smoothly, and more accurately reflect the WG's
>combined opinion if we put and end to this obvious conflict-of-interest.
>
>Andrew
>
>

---

From: Joe Touch <[email-masked]>
Date: Wed, 09 Dec 2009 13:46:31 -0800

Andrew Lange wrote:
> separate document. 

The decoupling was intended for last call, which has long since closed.
How it affects the doc as we move forward was something the WG had
already agreed to discuss, and we're discussing it.

Joe