Subject: [tcpm] TCPM and draft-ietf-tcpm-icmp-attacks

From: Jari Arkko <[email-masked]>
Date: Thu, 18 Feb 2010 21:04:53 +0200

Hi,

This document was recently in IESG review. My opinion is that the 
document should be approved as an RFC. Thanks for writing it.

However, I would like to note the following text from the document:

 The consensus of the TCPM WG (TCP Maintenance and
 Minor Extensions Working Group) was to document this widespread
 implementation of nonstandard TCP behavior but to not change the TCP
 standard.

This would seem to imply that the TCPM WG has decided to deviate from 
the old IETF operating principle of "rough consensus and running code". 
For at least some of the techniques described in this draft, they are 
generally accepted and widely implemented on key implementations. I ask 
what the reason is for divorcing IETF standards from established best 
practices and actual running code? TCP RFCs are not sacred documents, 
they should reflect what we want our implementations to do. But maybe 
there are important use cases for the actual standard TCP behavior in 
this space, just that I don't know about them. Please educate me about 
the background for this decision.

Jari

---

From: Joe Touch <[email-masked]>
Date: Thu, 18 Feb 2010 11:20:11 -0800

> the old IETF operating principle of "rough consensus and running code".

The short answer is that there wasn't rough consensus for these changes
in the WG, as explained in the note in the text.

Joe

---

From: Jari Arkko <[email-masked]>
Date: Thu, 18 Feb 2010 21:34:45 +0200

Joe,

> in the WG, as explained in the note in the text.

Ok. And by the way, I didn't mean to imply that all of the changes 
should be adopted. But at least some of them seem... pretty reasonable 
and universal. Like ignoring source quench, for instance. But I admit 
that my knowledge of TCP practices is limited.

However, *if* the document is right that the techniques are widely 
implemented, it is interesting that the WG does not agree that they are 
universally appropriate. Is (1) the reality different from what the 
document claims, (2) are these practices causing harm in the real world, 
or (3) is the working group opinion incorrect?

Jari

---

From: Joe Touch <[email-masked]>
Date: Thu, 18 Feb 2010 11:50:56 -0800

Hi, Jari,

> that my knowledge of TCP practices is limited.

The WG decided to document "what is", and to indicate for each item
whether it was consistent with existing specs or not.

> or (3) is the working group opinion incorrect?

I don't think anyone wants the IETF to rubber-stamp deployed code for
that reason alone (e.g., consider Linux's inclusion of deprecated T/TCP,
or use of nonstandard TCP windowing). There are times it's useful to
modify the standards accordingly, there are times it's useful to declare
it a bug (RFC2525), and there are times - such as this one - where we
have no rough consensus on which way to go, but agree that it's useful
to know what's actually out there.

Joe

---

From: Jari Arkko <[email-masked]>
Date: Thu, 18 Feb 2010 22:06:14 +0200

Joe,

> that reason alone

Agreed.

> there are times - such as this one - where we
> have no rough consensus on which way to go

Sure. I guess my issue was that I did not see why this would be the case 
in this particular instance.

Jari

---

From: Joe Touch <[email-masked]>
Date: Thu, 18 Feb 2010 14:00:07 -0800

> in this particular instance.

There were various reasons - at least one of which was a desire to
address this issue more broadly for all transports, which is outside the
scope of TCPM and the focus of documenting this issue.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Thu, 18 Feb 2010 22:17:43 -0300

> in the WG, as explained in the note in the text.

I believe that the short answer is that *you* have done everything that
was available to stop this document (and others) from moving forward.
Requesting text to be added, then requesting the very same text to be
taken out of the I-D. And at some point, we ended up changing the track,
changing text, and changing whatever was out there just with the hope
that you'd be happy, we'd stop wasting energy, and the document would be
eventually published.

It is interesting to note that one of the issues with with you have
trashed this I-D is that it used vocabulary that could be taken as the
draft "recommending" the described counter-measures. Yet, as the editor
of the last version of the (close to infamous) TCP A-O effort, you have
crafted this text:

"  There are other mechanisms proposed to reduce the impact
   of ICMP attacks by further validating ICMP contents and changing the
   effect of some messages based on TCP state"

Note the use of the term "proposed". (that's specifically what I'm
referring to).

I believe this is the height of irony.

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

---

From: Jari Arkko <[email-masked]>
Date: Thu, 18 Feb 2010 20:49:03 +0200

Hi,

Jari

---

From: "David Harrington" <[email-masked]>
Date: Thu, 18 Feb 2010 23:32:54 -0500

Let's make sure we remain civil, guys.

David Harrington
[email-masked]
[email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Fernando Gont
> Sent: Thursday, February 18, 2010 8:18 PM
> To: Joe Touch
> Cc: [email-masked]; Jari Arkko; [email-masked]
> Subject: Re: [tcpm] TCPM and draft-ietf-tcpm-icmp-attacks
> 
> Joe Touch wrote:
>

---

From: "Smith, Donald" <[email-masked]>
Date: Fri, 19 Feb 2010 09:51:33 -0700

In my opinion;

3. The wg "opinion" is incorrect.
Several protocol vulnerabilities that are RFC based have been identified. We are supposed to be the group fixing TCP but instead this has become an informational RFC when it addresses basic protocol flaws.

(coffee != sleep) & (!coffee == sleep)
 [email-masked]
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Joe Touch [[email-masked]]
Sent: Thursday, February 18, 2010 12:50 PM
To: Jari Arkko
Cc: [email-masked]
Subject: Re: [tcpm] TCPM and draft-ietf-tcpm-icmp-attacks

Hi, Jari,

Joe

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: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[email-masked]>
Date: Fri, 19 Feb 2010 11:26:33 -0600

Replying to Donald's message, but not picking on him in
particular :) ...

I think, as Joe noted, those "flaws" apply to transport protocols
in general and not just TCP.  I put "flaws" in quotes because I
think it's a wrong and misleading word; these are vulnerabilities
that have developed based on changing requirements and changing
deployment scenarios over multiple decades.  The same
vulnerabilities impact other transports and would most properly
be fixed on the standards track or BCP for all of them, rather
than having TCP, SCTP, etc. all play whack-a-mole as people
realize the same vulnerabilities exist N times.

Instead of debating paltry issues like Informational versus
Standards Track for this particular document, I think the
discussion should be elevated to consider what the role of
these ICMP messages is in the Internet architecture.  If we're
going to decide that transports should ignore many of them,
then should we also decide that hosts routers shouldn't generate
them?  This discussion involves deprecation of pieces of STD 5,
and update of RFCs 1122 and 1812, and is not something TCPM should
be doing implicitly, but should really be a bigger-picture
discussion between transport and internet areas.

In my opinion, it was reasonable to do this as Informational for
TCP at this point in time in order to document the implemented
behaviors so that they're clear, but there are definitely
deployments you could imagine where the vulnerabilities may not
be applicable and the ICMP signals may actually be useful to
maintain responses to.  There are many networks less dangerous
than the general Internet where the responsiveness that ICMP
provides could be seen as valuable.

--
Wes Eddy
MTI Systems

>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Smith, Donald
>Sent: Friday, February 19, 2010 11:52 AM
>To: Joe Touch; Jari Arkko
>Cc: [email-masked]
>Several protocol vulnerabilities that are RFC based have been
>identified. We are supposed to be the group fixing TCP but instead this
>has become an informational RFC when it addresses basic protocol flaws.
>
>
>_______________________________________________
>tcpm mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/tcpm

---

From: Jari Arkko <[email-masked]>
Date: Fri, 19 Feb 2010 19:30:29 +0200

Joe ,

> scope of TCPM and the focus of documenting this issue.

That might be a good approach.

But I will note three things. First, AFAIK we are not presently doing 
this. Should work be started? Second, it is not immediately obvious to 
me that everything that we have said about TCP applies to other 
transports. For instance, IMHO it is obvious that Source Quench can be 
ignored on TCP. But is this obvious for other protocols, e.g., UDP? 
Third, we can provide more specific guidance on TCP, such as what the 
effect of ICMPs referring to already acknowledged sequence numbers might be.

Given all this, my personal preference is that we at least specify this 
for TCP. We should probably start more generic work to update the ICMP 
processing rules as well, but the TCP is the low-hanging fruit.

Jari

---

From: Joe Touch <[email-masked]>
Date: Fri, 19 Feb 2010 09:36:51 -0800

> effect of ICMPs referring to already acknowledged sequence numbers might

That one is simply erroneous, and I and others (Bob Braden) have pointed
this out at numerous WGs. ICMPs are not required to be returned in a
timely fashion, so expecting the sequence numbers to be in-window is
simply incorrect.

It may help when under attack, but it also breaks legitimate responses
from working. It is definitely not in the spirit of "be liberal in what
you accept".

> processing rules as well, but the TCP is the low-hanging fruit.

If we want to make TCP-specific recommendations, we need to limit them
to the subset that may be correct and appropriate:

	- changing hard to soft during a connection
	though we do need to examine this in detail; I still feel that
	there are legitimate cases where this interprets valid messages
	as attack; we may decide that it's OK to throw that behavior
	out, but we need to explicitly note that

	- source quench
	we've needed to deprecate that one for a while

Others are not so easy. If we want to split those out, sure. But that is
not what the author wanted to do, and that has caused the problem with
this doc.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 19 Feb 2010 09:38:43 -0800

> was available to stop this document (and others) from moving forward.

The doc contains many items, some of which continue to be completely
inappropriate and incorrect (checking TCP sequence numbers), where
others are somewhat reasonable (port randomization).

One problem is that we never agreed on exactly what to focus on
recommending, as well as that TCP isn't the only protocol affected by
ICMP issues.

Another problem is that some of the responses may be appropriate when
under attack, but the overall tone of the document is that if a message
is "unexpected" it is malicious. That's the antithesis of "be liberal in
what you accept".

> Note the use of the term "proposed". (that's specifically what I'm

Yes, please do note it. "proposed" doesn't mean recommended.

The full text is:

   There are other mechanisms proposed to reduce the impact of ICMP
   attacks by further validating ICMP contents and changing the effect
   of some messages based on TCP state, but these do not provide the
   level of authentication for ICMP that TCP-AO provides for TCP [Go09].

It goes on to include SOME of the recommendations in this doc (but
notably not others, even though widely deployed). Note that these latter
changes were included because of *your* input *after* last call.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 19 Feb 2010 09:59:39 -0800

Hi, Jari,

> the background for this decision.

The issue, from my view, in TCPM has been a penchant for trying to
upturn a long history of "be liberal in what you receive" to react to a
number of specific recent threats to TCP.

Much of this "rush to react" has led to a perspective that any incoming
packet that isn't expected is an indication of *attack*. That could
easily lead to changes to TCP that make it inappropriately complex and
fragile, at the expense of protecting every home computer from attacks
that are typically waged only at routers or other core network components.

I agree with Wes that the role of ICMP in the Internet needs to be
re-examined, and some changes made. However, I also believe that many of
the current TCPM "rush to react" changes (including tcpsecure, some of
the ICMP checks, some parts of the TCP cookie transactions proposal) are
a poor substitute for the use of true security (IPsec, TCP-AO), which
may also need to include more widely-deployable variants with different
levels of protection (e.g., BTNS).

Yes, I have been the most vocal proponent of this view on TCPM, and
perhaps in TSV. I do not believe I represent only myself, however - if
that's the "rough consensus", there are mechanisms to override me
anyway. It's also useful to note that some of the most vocal proponents
of "it's deployed, so let's change the standard" were involved in their
deployment.

TCP, IMO, ought to be treated with a lot more careful consideration than
that.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 19 Feb 2010 10:17:22 -0800

Joe Touch wrote:
...
> changes were included because of *your* input *after* last call.

Also note that the changes are considered appropriate in the context of
connections protected by TCP-AO, which is intended to be more
conservative in what it accepts than TCP by design. They may or may not
be appropriate for TCP in general, or may be appropriate, e.g., only
during evidence of a repeated attack.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Fri, 19 Feb 2010 19:22:47 -0300

> that are typically waged only at routers or other core network components.

Joe, your statement (At least wrt icmp attacks) has no correlation with
reality.

ICMP reset attacks have been pretty usual since the 90's as IRC nuke
attacks. i.e., they have been performed mostly against end users, rather
than "core network components". Google for "irc nuke", or the like, and
I'm sure you'll find 10+ years old icmp exploits.

That said, I would call 5+ years a rush... :-))

> a poor substitute for the use of true security (IPsec, TCP-AO), 

They are not a substitute. And the recent support by Ran Atkinson
(co-author of previous versions of the IPsec std) should be a good hint.
See: http://www.ietf.org/mail-archive/web/ietf/current/msg60159.html

I don't really think anybody could call himself a "good engineer" if he
enabled IPsec just to mitigate the off-path attacks we have been
discussing in the last few years, when there are general and lightweight
mitigations for them.

> which

Side note: I wonder what would be the result if you submitted BTNS to
the same level of "correctness evaluation" as you have submitted this I-D...
(Maybe the "BTNS" acronym is an implicit acknowledgement of that?)

> of "it's deployed, so let's change the standard" were involved in their

Joe, I was involved in the deployment of "ignore source quenches" and
the PMTUD fix, only

The TCP SEQ check had already been incorporated in Linux years ago, and
was incorporated in lots of other stacks as a result of my I-D, rather
than my "code".

And if you want to "blame" somebody for the hard errors -> soft errors,
you should probably "blame" Mike Karels -- me, I'm thankful for his
work. FWIW, this behavior has been deployed for more than fifteen years.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 19 Feb 2010 19:31:41 -0300

> Yes, please do note it. "proposed" doesn't mean recommended.

Are you serious? Do I really have to go through the mailing-list archive
to provide you with a list of all those times in which you trashed the
doc for the instances of terms such as "proposed", "propose", etc.?

> changes were included because of *your* input *after* last call.

That's not the point I'm making. I'm saying that TCP-AO says "There are
other mechanism proposed". And if *you* were to review TCP-AO with the
same perspective with which you have reviewed icmp-attacks, you would
have said "NO! icmp-attacks *describes* or *documents*... it doesn't
'propose' anything... blah blah..".

I don't care myself about the wording you used. And when it comes to
addressing my input, you did a really good job. -- I just wonder why
it's hard to have you in the same "operation mode" when you're not the
author of the document being discussed.

Last, but not least, I made exactly the same comments (wrt TCP-AO and
ICMP attacks) ages ago (way before LC)... but you simply ignored my
comments, as other people has claimed you ignored theirs' when editing
the TCP-AO I-D.

Thanks,

---

From: Joe Touch <[email-masked]>
Date: Fri, 19 Feb 2010 14:36:08 -0800

> I'm sure you'll find 10+ years old icmp exploits.

Useful to include in your doc. Not cited, I note.

Yours is not the only document you have accused me of impeding. It would
be useful to reconsider my post in the context of the totality of work
it addresses (including the comment about being involved in deployment).

> See: http://www.ietf.org/mail-archive/web/ietf/current/msg60159.html

Note that he supports this as offered - Informational.

> (Maybe the "BTNS" acronym is an implicit acknowledgement of that?)

BTNS doesn't redefine the core, *non-secure* TCP service for everyone.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 19 Feb 2010 14:43:42 -0800

> doc for the instances of terms such as "proposed", "propose", etc.?

There is a difference between "there are mechanisms [that are] proposed"
and "this document proposes".

The text in AO was unchanged since the -00 version (Nov 2007). You
waited until after last call to complain about adding specific calls for
ICMP actions. If you want to now complain that we remove the word
"proposed" (would you prefer 'described'), I can do that rev.

> 'propose' anything... blah blah..".

I didn't say "the icmp doc proposes" - I said "[that are] proposed"
(i.e., the omitted words are implied). I didn't say who proposed them -
they're clearly proposed by someone. In fact, I wouldn't care if your
doc says "some people have proposed" or "the implementation in X proposes".

My objection was "**THIS** document proposes". That ends op saying that
the WG proposes, since it was a WG doc. The WG decided *not* to "propose".

I used the same mode here, but the English is admittedly a bit subtle. I
admit that I take that for granted as a native speaker, perhaps more
than I should. I'd be glad to explain further, either on or off list, if
useful.

> comments, as other people has claimed you ignored theirs' when editing

I didn't ignore the comments - they didn't have "rough consensus". Not
every proposed change by an individual necessarily makes it into a doc -
you and I both know that.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Fri, 19 Feb 2010 19:52:24 -0300

> Note that he supports this as offered - Informational.

That's incorrect. Go ask Ran Atkinson.

> BTNS doesn't redefine the core, *non-secure* TCP service for everyone.

icmp-attacks does not, either. It changes a protocol policy. It doesn't
redefine any service -- TCP is still a connection-oriented realiable
byte-stream protocol. So I don't see your point.

Thanks,

---

From: Joe Touch <[email-masked]>
Date: Fri, 19 Feb 2010 15:02:32 -0800

> That's incorrect. Go ask Ran Atkinson.

From the URL *you* provided:

"I have reviewed this document and I support publishing it as
an Informational RFC."

> byte-stream protocol. So I don't see your point.

icmp-attacks discusses changes TCP for everyone, not just for those who
enable a particular form, or while under attack. BTNS is a specific
variant of IPsec that is not what you get by default.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Fri, 19 Feb 2010 20:04:25 -0300

> and "this document proposes".

Don't both of them imply the same thing????!??? :-)

> ICMP actions. 

Look at this:
http://www.ietf.org/mail-archive/web/tcpm/current/msg04593.html

Is June 16th, 2009 what you call last-minute???????

> If you want to now complain that we remove the word

No, Joe. That's the game *you* like to play, not me. As far as I'm
concerned, you can leave the text "as is".

> you and I both know that.

I could give a long response here... but I have had enough. Anybody that
hsa participated in tcpm since its creation can probably guess a (or
craft their own ;-) ) response to this comment.

Thanks,

---

From: Joe Touch <[email-masked]>
Date: Fri, 19 Feb 2010 15:13:14 -0800

> Don't both of them imply the same thing????!??? :-)

No, they do not. The WG cannot prevent others from proposing something,
but it makes its own decisions on what to propose.

> Is June 16th, 2009 what you call last-minute???????

It was raised as you cite, discussed at the WG meeting in Stockholm, and
we proceeding with the result from that meeting (see slide 8). There was
then a last call, at which you did not yet again raise the issue.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Fri, 19 Feb 2010 20:14:45 -0300

> "I have reviewed this document and I support publishing it as

Again, go and ask Ran about this I-D. Please.

BTW, Ran said: "F. Gont has done a tremendous public service in putting
together this (and predecessor) documents with risk analyses for various
widely deployed protocols."

And you have trashed each of the documents he's referring to (including
icmp-attacks, draft-ietf-tcpm-tcp-security, etc.).

Kind regards,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 19 Feb 2010 20:17:50 -0300

Joe Touch wrote:

> we proceeding with the result from that meeting (see slide 8). 

We proceeded with the result of that meeting? :-) I thought the
mailing-list were important in the IETF process.

Maybe I'm just missing something?

Thanks,

---

From: Joe Touch <[email-masked]>
Date: Fri, 19 Feb 2010 15:22:49 -0800

> widely deployed protocols."

The entire quote has both parts, and directly cites Informational.

I have reviewed this document and I support publishing it as
an Informational RFC.  F. Gont has done a tremendous public
service in putting together this (and predecessor) documents
with risk analyses for various widely deployed protocols.

> icmp-attacks, draft-ietf-tcpm-tcp-security, etc.).

I have criticized these documents for proposing changes to standards; I
do not have an issue with merely documenting those changes.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 19 Feb 2010 15:35:23 -0800

Fernando Gont wrote:
> We proceeded with the result of that meeting?

OK. Let me be *very* specific.

The issue was discussed on the list - see my summary of the debate we
had and a call for additional input:
http://www.ietf.org/mail-archive/web/tcpm/current/msg04604.html

Nobody else weighed in. At that point TCP-AO had the same recommendation
as IPsec (standards-track), and did not include specific indications (as
per your informational-track doc).

I asked for input at the WG meeting in Stockholm, and the notes indicate:

  - Issues raised – ICMP handling
    o No need to do more than IPsec

I raised the issue, and we did not have any additional concerns raised
at the meeting. We did not make a new decision on this at the meeting.

Joe

---

From: "Smith, Donald" <[email-masked]>
Date: Fri, 19 Feb 2010 16:42:08 -0700

Top posting, I too support this as an Informational RFC HOWEVER I would have rather supported it as a standard.
So supporting this as an informational RFC does NOT mean Ran or anyone else would not have supported it as a standard which seems to be the conclusion Joe is making.

Sent: Friday, February 19, 2010 4:22 PM
To: Fernando Gont

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 19 Feb 2010 15:50:40 -0800

> So supporting this as an informational RFC does NOT mean Ran or anyone else would not have supported it as a standard which seems to be the conclusion Joe is making.

We would need to ask whether *each* of the changes proposed is something
we agree to be standard.

As I already noted, and Wes reiterated, there are other reasons for not
doing this in the context of this doc - esp. because some of these
changes really ought to be considered in the context of all transports,
not just TCP, where others are specific to TCP.

If we want to go back and split these out, that's a way forward.
However, publishing this as informational doesn't preclude that as a
separate path

Joe