Subject: [OPSEC] A clarification on icmp-filtering I-D

From: Fernando Gont <[email-masked]>
Date: Tue, 13 Apr 2010 00:20:31 -0300

Hi, folks,

I wasn't at the opsec wg meeting, and have jut sync'ed with the meeting
(I've just read the minutes). Here are some comments regarding the
discussion about icmp-filtering:

> ron bonica: rationale is that many ISPs block ICMP messages. There are
>   some ISPs that let everything through. Others let some through, e.g.
>   for pMTU discovery, but others they drop. what I wanted was a
>   discussion for each ICMP message to allow an ISP to make informed
>   decisions.
> 
> joe touch: some decisions are being made on what has been deployed,
>   opinions of some individuals. had this discussion in tcpm. 

This is entirely misleading. The discussion in tcpm was about ICMP hard
errors, and about what countermeasures could be implemented in TCP to
mitigate them.

This I-D is orthogonal to that.

>   this
>   document shouldn't repeat that discussion; it should refer to the
>   tcpm discussion. second thing, why and whether it's appropriate
>   to check the contents of icmp messages, check checksums, check fields
>   inside. example: check sequence number. 

Can you please point the specific section in the icmp-filtering I-D that
recommends this? (or that even mentions this???)

> ron bonica: first, agree with joe touch re referencing rather than
>   reiterating. we should reference when we can. second, we should
>   probably send the doc for external review, and send instructions for
>   reviewer. document's goals are to explain what you lose if ou filter,
>   what you  risk if you don't filter, let the operator make an informed
>   decision. what we want is for him to make an informed decision.

+1.

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

---

From: Joe Touch <[email-masked]>
Date: Mon, 12 Apr 2010 20:59:42 -0700

Fernando,

Also, the doc cites the need to

> This I-D is orthogonal to that.

First, I'm referring to the decisions of operators, not the decisions in
the document.

Second, the document is clearly not orthogonal to the TCPM ICMP docs
(see numerous citations to both RFC5461 and ICMP attacks ID).

In specific, this doc repeatedly states:

   May lead to long delays between connection establishment attempts or
   long response times that could have been avoided by aborting non-
   synchronized connections in response to ICMP soft errors [RFC5461].

This implicitly endorses the soft errors solution, which, as noted in
RFC5461 in the abstract:

   This document describes a non-standard, but widely implemented,
   modification to TCP's handling of ICMP soft error messages

This is why I consider some of the suggestions and discussion in this
document to be based on what has been deployed, and is clearly the
opinion of some individuals, but not the advice of TCPM.

> recommends this? (or that even mentions this???)

My point is that the icmp-filtering doc makes ample reference to the
tcpm-icmp-attacks doc, without stating that the mechanisms in that tcpm
doc are not necessarily appropriate.

>>   decision. what we want is for him to make an informed decision.

+1

Informed decisions include knowing that you're playing with deployed
code that is not recommended, and in cases oversteps the standards.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 12 Apr 2010 21:02:22 -0700

> Also, the doc cites the need to

Skip this snippet. Not needed.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Tue, 13 Apr 2010 02:08:11 -0300

Joe,

> This implicitly endorses the soft errors solution, which, as noted in

That was not the intent. We may weak the wording, if that's an issue.

We don't want to endorse anything. But as there are numerous stacks that
implement the behavior in RFC 5461, this was noted. In particular,
implementation of RFC 5461 is quite popular in the v6 world, and
probably expected (for instance, that's where the soft-errors I-D was born)

> opinion of some individuals, but not the advice of TCPM.

Why do you think we're endorsing RFC 5461? The idea was to mention that
if you filter soft errors, then the non-standard workaround described in
RFC5461 will fail. That's it.

> doc are not necessarily appropriate.

The reference to icmp-attacks is for the description of the
vulnerabilities, rather than for the counter-measures. Yes, it does
references icmp-attacks. But it doesn't endorse the countermeasures. --
It does not even mention them!

> code that is not recommended, and in cases oversteps the standards.

In the case of icmp-attacks, there's no play with deployed code at all.
As I've already mentioned the I-D/RFC is referenced because it's the
first documentation of those vulnerabilities. In the case of soft-errors
(RFC5461), I may note that it's a non-standard behavior, if you want.

Honestly speaking, there's no intent at all to encourage or endorse
icmp-attacks or RFC5461, or anything.

I'll note that of RFC5461 being "widely deployed, but non-standard" in
the next rev. If you have any specific proposal for the wording, please
post it. -- there's no need to fight for this document.

Thanks,

---

From: Joe Touch <[email-masked]>
Date: Thu, 15 Apr 2010 15:59:39 -0700

> probably expected (for instance, that's where the soft-errors I-D was born)

Repeating it is endorsing it. I don't agree with either.

> RFC5461 will fail. That's it.

The text (see ** above) says that you get long delays that could be
avoided by USING the nonstandard workarounds in 5461.

I.e., it says the opposite of what you're saying here, so at best the
text needs revision if that's the case.

> It does not even mention them!

That's worth noting explicitly, e.g., as a note somewhere (e.g., in the
background or intro) - i.e., the following doc is cited to explain the
details of certain attacks, but also includes countermeasures that this
document does not endorse.
...

> post it. ...

See just above. I think we're agreeing on this, but it does need
clarification in the doc.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Thu, 15 Apr 2010 20:23:08 -0300

> Repeating it is endorsing it. I don't agree with either.

That's *your* take. Again, I will note that of "widely implemented, but
non-standard behavior", though.

> text needs revision if that's the case.

Ok, will do.

> document does not endorse.

Joe, do we really need to start polluting this doc, and make it result
in 100-page of disclaimers?

Your argument has been considered. But your voice (by itself) does not
represent wg consensus for such a change.

> clarification in the doc.

Will fix this as noted above (i.e., "if you filter soft errors, then the
non-standard workaround described in RFC5461 will fail...").

Thanks,

---

From: Joe Touch <[email-masked]>
Date: Thu, 15 Apr 2010 17:08:47 -0700

Keeping this short...

Fernando Gont wrote:
...
> in 100-page of disclaimers?

That's *your* take. Mine is that this is needed for understanding the
context and avoiding giving a mistaken impression to the reader.

> represent wg consensus for such a change.

Agreed. And your voice (by itself) doesn't represent WG consensus for
when an argument has been considered (as you claim above) or whether a
change is needed or not.

> non-standard workaround described in RFC5461 will fail...").

At this point, I'd like to point out that the repeated mention of a
nonstandard workaround is *itself* pollution, which could just as easily
be omitted.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Thu, 15 Apr 2010 21:41:38 -0300

Joe Touch wrote:

> That's *your* take. 

Agreed.

> when an argument has been considered (as you claim above) or whether a

I have considered your argument. If there's strong consensus for that
change, of course I'll apply it. that's it.

> nonstandard workaround is *itself* pollution, which could just as easily

Joe, what's the change you expect? You mention a problem. I propose a
solution, but you don't like it.

Thanks,

---

From: Joe Touch <[email-masked]>
Date: Fri, 16 Apr 2010 06:46:12 -0700

Fernando Gont wrote:
...
> solution, but you don't like it.

I'll repeat the solution:

Avoid repeated mention (and thus, IMO, implied endorsement) of a
nonstandard workaround as being affected by soft error filtering.

That issue is worth - at best - one mention in this doc. It is not worth
noting at every single soft error affected.

Joe