Subject: [OPSEC] Proposed changes for the ICMP filtering I-D

From: Fernando Gont <[email-masked]>
Date: Sun, 01 Jun 2008 22:10:52 -0300

Hello, folks,

(sorry if you get this one twice... not sure if it worked on my first try)

We are working on a revision of the ICMP filtering draft 
(http://www.gont.com.ar/drafts/icmp-filtering/draft-gont-opsec-icmp-filtering-00.txt). 
We'd like to get some input on a few issues relevant to the document structure:

1) Reducing the amount of text about message specifications
One of the comments we got on the was that the document provides too 
many details wrt to the specification of messages.
We're planning to reduce the amount of text by simply providing 
pointers to the specs, without any discussion of the referenced text. 
For example, the current text in Section 2.1.1.1.1:
"   Defined in [RFC0792].  Section 4.3.3.1 of [RFC1812] states that if a
    router cannot forward a packet because it has no routes at all
    (including no default route) to the destination specified in the
    packet, then the router MUST generate a Destination Unreachable, Code
    0 (Network Unreachable) ICMP message.  Section 3.2.2.1 of [RFC1122]
    states that this message may result from a routing transient, and
    MUST therefore be interpreted as only a hint, not proof, that the
    specified destination is unreachable.  For example, it MUST NOT be
    used as proof of a dead gateway.  Section 4.2.3.9 of [RFC1122] states
    that this message indicates a soft error, and therefore TCP MUST NOT
    abort the connection, and SHOULD make the information available to
    the application."

would become something like:
"   Specified in [RFC0792], Section 4.3.3.1 of [RFC1812], Section 3.2.2.1
    of [RFC1122], and Section 4.2.3.9 of [RFC1122]"

We could even completely remove section numbers... although I'd 
prefer not to (documents like RFC1122 and RFC1812 are simply too 
large for a loose reference to them being useful).

2) Providing advice on ICMP filtering at end-systems
We had originally thought about the draft discussing ICMP filtering 
in forwarding devices, and not in end-systems. However, some feedback 
from Donald Smith somehow raised the question (in my head, if you 
want :-) ) on whether the doc should provide advice on ICMP filtering 
when ICMP messages are destined to or originated at the router 
itself. That is, we might provide advice on what to do with ICMP 
messages at a finer granularity: ICMP messages originating at the 
device, messages that go through the device, and messages destined to 
the the device.

We'd like to know what's the opinion of the wg about this.

3) "Operational/Interoperability implications if blocked"
The current text discusses what you may break if you filter each of 
the ICMP type/codes. Donald pointed out that this might be a little 
bit vague. I personally think that this section could be kept "as 
is". My rationale is that if blocking a message breaks something 
(e.g., blocking "frag needed" breaks PMTUD), then the implications of 
rate-limiting, and filtering message to/from/through a router are 
straightforward.

However, input from the wg on this issue would be welcome, so that we 
agree on the basic structure of the document before committing too 
many cycles in a wrong direction.

4) Informational vs. BCP
The current version of the doc is meant for the Informational track. 
While talking with Carlos Pignataro, we realized that "BCP" might be 
a more appropriate track for this draft.

We'd like input on this one, too. :-)

Thanks!

Kind regards,

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

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

---

From: "Smith, Donald" <[email-masked]>
Date: Mon, 2 Jun 2008 09:00:09 -0600

Security through obscurity WORKS against some worms and ssh attacks:)
[email-masked] giac 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Fernando Gont
> Sent: Sunday, June 01, 2008 7:11 PM
> To: opsec wg mailing list
> Subject: [OPSEC] Proposed changes for the ICMP filtering I-D
> 
> Hello, folks,
> 

I like the details. It would help others understand and decide on the
filtering recommendations in the rfc.
Without those details we end up with recommendations without providing
the basis for those recommendations.

> the device.

I think we should cover the following destinations.
To (directed at the device itself)
Through (directed through the device)
>From (coming from the device)
and possibly
Behind (behind a device meant to protect a network such as a firewall or
router ACL).

If we do cover BEHIND that gets into firewalls/router acls but I think
that may also have value.

> rate-limiting, and filtering message to/from/through a router are 

I don't think it was vague as much as hard to list all things that will
break.
I am not sure we will be able to develop a complete list of applications
and services that break when you filter or rate limit some icmp type. I
still think it is worth the effort to list what we know but we may need
to add text somewhere saying that those applications are the ones we
know will be affected but that the list is not all inclusive.

> a more appropriate track for this draft.

I vote for BCP too:)

> We'd like input on this one, too. :-)

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.
_______________________________________________
OPSEC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsec

---

From: Sean Donelan <[email-masked]>
Date: Mon, 2 Jun 2008 11:35:23 -0400 (EDT)

> We'd like to know what's the opinion of the wg about this.

I tend to view it as understanding the intended scope of various
mesages rather than filtering.  The intended scope of some mesages
is within a LAN, a single administrative domain, between administrative 
domains, the Internet. The same messages may be very useful when used 
within their scope, and very disruptive when used outside of their scope.
Of course, when should messages cross between different scopes backs into 
the filtering question.
_______________________________________________
OPSEC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsec

---

From: Florian Weimer <[email-masked]>
Date: Mon, 02 Jun 2008 22:43:56 +0200

> We'd like to know what's the opinion of the wg about this.

For some devices (primarily hosts, but perhaps also middleboxes), there
might be an interaction between ICMP port unreachable messages and
source port randomization: the absence of an ICMP message could indicate
that a particular source port is being used (even to an attacker who is
not party to the conversation).  I'm not sure if this merits mention in
the draft, though.
_______________________________________________
OPSEC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsec

---

From: John Kristoff <[email-masked]>
Date: Fri, 6 Jun 2008 09:48:48 -0500

On Sun, 01 Jun 2008 22:10:52 -0300

> many cycles in a wrong direction.

I've avoided participating in this work since my original comments on
this subject in January.  I think the scope of your draft turned me
off quite frankly.  :-)

Don't get me wrong, a fine grained examination of ICMP filtering issues
and guidelines may be useful, but it looks to me what you're writing
is closer to a very detailed update of RFC 792.  Not that that would
be a bad thing.

I'm not sure its possible to make this a BCP.  These days filtering is
often a local decision, and in some cases rightfully so.

John

---

From: Joel Jaeggli <[email-masked]>
Date: Fri, 06 Jun 2008 07:59:33 -0700

> often a local decision, and in some cases rightfully so.

I think it should be clear what functionality you lose when you chose to 
filter something. desireable vs best is a fine line to walk I guess.

---

From: "Smith, Donald" <[email-masked]>
Date: Fri, 6 Jun 2008 09:29:43 -0600

> On Behalf Of John Kristoff
> Sent: Friday, June 06, 2008 8:49 AM
> To: [email-masked]
> Subject: Re: [OPSEC] Proposed changes for the ICMP filtering I-D
> 

I don't think the scope is finalized yet. We were discussing it.

Do we want to limit the scope to filtering/ratelimiting THROUGH a
system.
Or should we include to and from a system?

> often a local decision, and in some cases rightfully so.

I agree filtering is a local decision.
That is why along with the recommendations I believe it is important to
explain what that type/code combination is used for, why filtering
should be considered, and what the filtering is likely to impact.