Subject: [OPSEC] New I-D on ICMP filtering

From: Fernando Gont <[email-masked]>
Date: Sun, 30 Mar 2008 19:46:55 -0300

Folks,

After quite some time of discussing this subject on the list, we have 
finally published a (very drafty) internet draft on ICMP filtering. 
Our draft borrows its structure from the wiki George Jones had 
started on the subject.

We have spent an extraordinary amount of time digging into the specs, 
in the hope of being able to include pointers to the relevant RFCs 
where each of the ICMP messages are defined (part of this work should 
be credited to Carlos Pignataro).

So far, we have included all this information in our draft, and have 
already started populating the "uses", "security threats" and 
"Operational implications if blocked" subsections corresponding to 
each of the ICMP messages.

We'd like to receive feedback on the structure of the draft. That is, 
whether you are happy with the current structure of the draft (so 
that we continue moving in this direction), or whether some changes 
would be needed for you to feel happier about it. Among the possible 
changes could be:

* Discuss request/response messages in the same section, rather than 
having subsections for each of them. I think the current structure 
(having a subsection for each type/code) is good, but...

* Changing the structure of the draft actually, the xml tag in the 
xml source) so that "Uses", "Threats" and 
"Operational/interoperability impact if blocked" are NOT "sections". 
This would avoid section numbers having a fifth level of nesting 
(e.g., 1.2.3.4.5)... but might be good for referencing a specific 
part of this draft.

Any other comments are welcome.

The draft is available at the ID repository, but we have also put it 
online (and in different fancy formats) at: 
http://www.gont.com.ar/drafts/icmp-filtering/index.html

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: Pekka Savola <[email-masked]>
Date: Mon, 31 Mar 2008 09:17:03 +0300 (EEST)

> would be needed for you to feel happier about it. Among the possible

I was not involved in the discussions that led to this I-D, so I may 
be missing something.

This format would be great for reference documentation (e.g. as an 
addon to RFC791/1122/1812 and various ICMP specs) as an int-area 
project.  It seems somewhat verbose from the OPsec point of view.  If 
the document length exceeds 15-20 pages, it's too long to be 
considered as a useful recommendation.

Maybe we can put a "summary" section in front which would be 2 pages 
and the rest of the document would be 30 or 40 pages but not sure 
whether opsec is the right place to develop this kind of doc.

From the OPsec perspective, I'd have thought that the most useful 
output would be generated by starting by trying to develop consensus 
on filtering practices, describe the tradeoffs when consensus does not 
emerge and draw in support/analysis from specifications only as 
necessary (rather than start from the specifications).

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
OPSEC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsec

---

From: George M Jones <[email-masked]>
Date: Mon, 31 Mar 2008 07:30:03 -0400

Looks like a good start.

Only issue is length.   Does it need to restate the existing specs in 
such detail ?
Would it be possible to have a summary table or something at the front ?

---George Jones

---

From: Fernando Gont <[email-masked]>
Date: Mon, 31 Mar 2008 12:10:10 -0300

At 08:30 a.m. 31/03/2008, George M Jones wrote:

>state the existing specs in such detail ?

Our take on providing "detailed pointers" to the specs is that you 
know where to look at if you want to make a more informed decision on 
whether to block the message or not, Additionally, you know where to 
look at if you want to understand the consequences of filtering the 
error messages better. I guess one could provide some sort of 
table.... but for many messages that would include "RFC1122" and 
"RFC792", which wouldn't shed much light?

But that's just me thinking out loud. As mentioned in my post, this 
-00 version means to raise discussion among us on the best way to go. 
So we're open to any changes in the draft structure.

Thanks!

---

From: Ron Bonica <[email-masked]>
Date: Tue, 01 Apr 2008 10:58:40 -0400

Fernando,

This is an excellent document and I encourage you to post it.

The following are a few comments:

Section 1: Is your advice directed to ISPs? Enterprise Operators? SOHO
users?

Missing Section: You might want to add a Section up front that includes
two tables. One table represents ICMPv4 and the other ICMPv6. Each table
entry represents a type/code combination. Each table entry also includes
a pointer to the section of the document that addresses the message
type, and a recommendation to pass or filter the message.

This section would also have to include a disclaimer stating the the
recommendation is just that, a recommendation. Operators should look at
the corresponding section and decide for them self whether the want to
pass or filter the message.

General: For many message types, the "Threats" and "Impact if blocked"
are identical. So, it is tempting to merge these sections. However, this
is not possible because the "Message Specification" and "Uses" are not
identical. Maybe you can solve the problem by omitting the "Message
Specification" and "Uses" sections and trusting the reader to read the
reference documents.

                                   /individual contributor
                                    Ron

P.S. I have not met Guillermo Gont. Are the authors brothers? Father and
son?

---

From: Fernando Gont <[email-masked]>
Date: Mon, 31 Mar 2008 13:39:55 -0300

At 03:17 a.m. 31/03/2008, Pekka Savola wrote:

>addon to RFC791/1122/1812 and various ICMP specs) as an int-area project.

Yes, as a matter of fact, we had done much of the "digging" work in 
the hopes of publishing such a document.

> output would be generated by starting by trying to develop 
> consensus on filtering practices, describe the tradeoffs when 
> consensus does not emerge and draw in support/analysis from 
> specifications only as necessary (rather than start from the specifications).

I understand your point, and agree.

mmm... are you suggesting to collapse each the "Message 
specification", "Uses", "Threats", and "Operational/interoperability 
implications if blocked" group of subsections into a single 
subsection? (and rather than having a verbose description of the 
relevant specs, simply state e.g., "specified by RFC792, RFC1122, and 
RFC1812"?)

Or.... maybe for each message have a "Uses" subsection (that 
collapses a non-verbose version of the current "Message 
specification" and the current "uses" subsections), a "Threats" 
subsection (with a description on the security implications of the 
message) and a ""Operational/interoperability implications if 
blocked" section which discusses filtering of the corresponding messages?

Any other suggestion will be more than welcome, as at this point we 
still have time to change the structure of the draft.

What do other folks think about this?

Thanks!

---

From: Fernando Gont <[email-masked]>
Date: Mon, 31 Mar 2008 13:39:55 -0300

Thanks!