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

From: Fernando Gont <[email-masked]>
Date: Sun, 18 May 2008 07:12:49 -0300

Hello, folks,

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