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

From: Joel Jaeggli <[email-masked]>
Date: Tue, 06 May 2008 23:34:58 -0700

I think, given the commentary over the last month that this is worth 
accepting as a working group document. I think it's pretty clear that 
there were some comments regarding the structure but relatively little 
regarding the content, which is consistent with what we discussed prior 
to IETF 71.

joelja

Fernando Gont wrote:
> 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
> 

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

---

From: Warren Kumari <[email-masked]>
Date: Wed, 7 May 2008 11:25:05 -0400

On May 7, 2008, at 2:34 AM, Joel Jaeggli wrote:

> accepting as a working group document.

Yes, I fully agree...

> I think it's pretty clear that

Yup.

--
After you'd known Christine for any length of time, you found yourself  
fighting a desire to look into her ear to see if you could spot  
daylight coming the other way.

     -- (Terry Pratchett, Maskerade)t

---

From: "Smith, Donald" <[email-masked]>
Date: Wed, 7 May 2008 09:38:18 -0600

Fernando, good work! I agree this should be accepted as a working group
document.

RM=for(1)
{manage_risk(identify_risk(product[i++]) &&
(identify_threat[product[i++]))}
[email-masked] giac 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Warren Kumari
> Sent: Wednesday, May 07, 2008 9:25 AM
> To: Joel Jaeggli
> Cc: opsec wg mailing list
> Subject: Re: [OPSEC] New I-D on ICMP filtering
> 
> 

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: [email-masked]
Date: Wed, 7 May 2008 23:49:29 -0400 (EDT)

This is most welcomed and well worth the WG's acceptance.

Doing ICMPv6 too is great. One suggestion: I believe that
additional ICMPv6 messages beyond the base spec have been defined,
e.g., for mobility. Perhaps consult the IANA assignments for
a current list.

Richard Graveman

---

From: "Smith, Donald" <[email-masked]>
Date: Thu, 8 May 2008 09:47:23 -0600

ICMPv6 is covered within this document.
I don't know if it covers any new mobility related ICMPv6 messages.

RM=for(1)

> On Behalf Of [email-masked]
> Sent: Wednesday, May 07, 2008 9:49 PM
> To: opsec wg mailing list

---

From: [email-masked]
Date: Sat, 10 May 2008 10:40:49 -0400 (EDT)

> I don't know if it covers any new mobility related ICMPv6 messages.

Right; my suggestion was to consult

http://www.iana.org/assignments/icmpv6-parameters

for a complete list of currently assigned types.

Richard

---

From: Fernando Gont <[email-masked]>
Date: Sat, 17 May 2008 23:46:40 -0300

At 03:34 a.m. 07/05/2008, Joel Jaeggli wrote:

>accepting as a working group document. I think it's pretty clear 
>that there were some comments regarding the structure but relatively 
>little regarding the content, which is consistent with what we 
>discussed prior to IETF 71.

[catching-up with e-mail... sorry for the delay in my response]

Should we resubmit the draft as draft-ietf?

Thanks!

Kind regards,

---

From: Fernando Gont <[email-masked]>
Date: Sun, 18 May 2008 05:20:57 -0300

Hello, Donald,

Thanks so much for your detailed feedback!

I beg your pardon for the delay in my response. You'll find my 
comments inline....

>Operational impact if blocked is a bit vauge.
>I think there are 6 kinds of "blocking" recommendations we could be
>making.
>
>Blocked towards your device (network element or host).
>Blocked through your device.
>Blocked from your device.
>
>Ratelimited towards your device.
>Ratelimited through your device.
>Ratelimited from your device.

I understand what you mean. However, the "operational impact if 
blocked" could encompass all these cases. If blocking a message 
breaks something (e.g., blocking "frag needed" breaks PMTUD), then 
the implications of all the possible six recommendations you mention 
would be straightforward. I mean, IMHO, there would be no need to 
include a discussion for what would happen for each of the six 
approaches you mention.

>Somewhere around 2.1.3.1 (redirect datagrams for the network )
>many of the types/codes areas are not filled in.
>I would be willing to assist there if your interested.

Yes, please do. (This revision of the doc was kinda a "draft of a 
draft"... most of all meant as a starting point to agree on the 
structure of the document)

>These comments are based on the 4/16/2008 version.
>
>2.1.1.1.1 "router can not forward a packet because it has no routes"
>Does not include the concept of BGP triggered blackhole. In that case
>the router does have a route but the route leads to /dev/null. A lookup
>in the cef or forwarding table usually results in 0 being returned so it
>is a route but it is a null route:)

Agreed. Will add some text about this. If you have any text that I 
could cut&paste into the doc, that would be even better. :-)

>2.1.1.6.1
>Many ISPs block or ignore source route. As do many enterprises. Most of
>those that are blocking or ignoring are also not sending source route
>failed icmp error msgs.

Do they send any ICMP error messages in response?

>2.1.1.7 destination netwokr unknown (code 6) (Deprecated).
>Since this is deprecated do we need to make any suggestions?
>Is it still acted upon?

I think we should. While these messages may be deprecated, you may 
stil encounter one of them, thus you should still decide waht to do 
if that happens.

>2.1.1.10.3 Threats
>"May reveal filtering policies" seems to be the same as network mapping
>or prehaps it should be network policy mapping.
>I would like to see the same text used if possible through the document.

Agreed. Will do.

>2.1.1.14.3 Threats
>Negative scan, reflective attacks, possibly blind resets?

Agreed for negative scan and reflective attacks. As for blind resets, 
this is already noted in the draft.

>2.1.1.15.3 Threats
>Network policy mapping from the inside of the network?
>I am not sure that is very valid. You could map the policy of an ISPs
>edge.

Not sure what you mean....

>2.1.4.1.4 Impact:
>I agree it breaks traceroute. I don't think it leads to long delays....

If you're trying to establish a TCP conenction using some specific IP 
destination address, and there's a routing loop somewhere en-route, 
you'll probably get one of these ICMP soft errors, which could have 
provided a hint to abort the conenction request and try some of the 
other IP addresses returned by the DNS.

P.S.: As you will have noted, I responded to only those comments to 
which I had anything to add. (That is, unless stated otherwise, the 
response is "will do" :-) ).

Thanks!