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

From: Fernando Gont <[email-masked]>
Date: Tue, 01 Apr 2008 18:30:34 -0300

Ron,

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

Thanks!

>The following are a few comments:
>
>Section 1: Is your advice directed to ISPs? Enterprise Operators? SOHO
>users?

I'd say the current document is pretty general, and would apply to 
ISPs and Enterprise Operators. I was planning to include a section on 
stateful ICMP filtering, which would only apply to SOHO.

>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.

Makes a lot of sense. Will do.

>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.

Okay, but... in which section would we include the pointers to 
reference documents if we omit both the "Message specification" and 
"Uses" sections?

>                                    /individual contributor
>                                     Ron
>
>P.S. I have not met Guillermo Gont. Are the authors brothers? Father and
>son?

Brothers. Having him co-author the doc has been my intent to get him 
read RFCs and get his hands dirty. :-) I'm don't think  this 
ICMP-torture is getting him excited, but....  ;-)

(Based on past experience, I'm starting to think that at some point I 
*might* have a kid and end up including him as a co-author of some 
draft I have active at the IETF... and you know what I am talking 
about :-) :-( )

Kindest 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: Ron Bonica <[email-masked]>
Date: Wed, 02 Apr 2008 08:38:05 -0400

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

> 
> 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?
> 

In the table, you could make the pointer as specific as it needs to be
(example: RFC 792, Section 2.1, Paragraph 1).

                                           Ron

---

From: "Smith, Donald" <[email-masked]>
Date: Wed, 30 Apr 2008 16:05:48 -0600

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 Fernando Gont
> Sent: Tuesday, April 01, 2008 3:31 PM
> To: Ron Bonica
> Cc: opsec wg mailing list
> Subject: Re: [OPSEC] New I-D on ICMP filtering
> 
> Ron,
> 
I also think this document is a very good document and wanted to provide
some comments and questions wrt it.
 
> >Section 1: Is your advice directed to ISPs? Enterprise 

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.

> Makes a lot of sense. Will do.

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.

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:)

2.1.1.3.3 Threats
Negative scanning. This is how protocol scanning is preformed in nmap.

2.1.1.4.3 Threats
Negative scanning. This is how UDP port scanning is preformed in nmap.
Spoofed blind resets.

2.1.1.5.3 Threats
Negative scanning. This is how UDP port scanning is preformed in nmap.
Spoofed blind resets.

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.
If they do the threat becomes one of network mapping and/or network
capability mapping.

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?

2.1.1.8.3 Threats
Negative scan. Reflective attack. Network mapping.

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.

2.1.1.11.3 Threats
Negative scan, relective attack, network policy mapping.

2.1.1.12.3 Threats
network policy mapping, negative scan, relective attack.

2.1.1.13.3 Threats
Network policy mapping, reflective attacks.

2.1.1.14.3 Threats
Negative scan, reflective attacks.

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

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.

2.1.1.16.3 Threats
Negative scan, network policy mapping, reflective attack.

2.1.2.2 Uses
Tarpitting, slowing aggressive hosts.

2.1.3.1.3 Threats 
Spoofed redirect could cause multi networked hosts to send traffic in
the wrong direction.
Consider a WAP with one port going to the broadband uplink and the other
going out wireless.
If the home system received a spoofed redirect you may be able to get
the Internet bound traffic to go out the wap to a local hijacker.
2.1.3.1.4 Impact:
This is often blocked at enterprise edges. Routers usually ignore it.

2.1.3.2.4 Impact:
This is often blocked at enterprise edges. Routers usually ignore it.

2.1.3.4.3 Threat:
Route hijacking, man in the middle attacks.

2.1.3.4.4
This is often blocked at enterprise edges. Routers usually ignore it.

2.1.4.1.3 Threats:
Network mapping, reflective attacks, Negative scannings.

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

2.1.4.2.3 Threats:
Reflective, network mapping.

2.1.5 should have the same uses, threats, and impact as destination
unreachable (1,5).

2.2.1.1.3 Threats:
An example of icmp-scanning would be natchi.
Smurf is a specific example of reflective attacks.
Network mapping.

2.2.1.2.3 Threats:
Smurf is a specific example of reflective attacks.

2.2.2.2.3 Threats:
Route hijack.

2.2.3.1.3 Threats:
Can be used to establish time potentially to by pass time based
authentication methods.
Can be used to establish time potentially to geo map a system.

2.2.4.1.3 Threats:
Network mapping, reflective attacks.

2.2.5.1.3 Threats:
Reflective attacks.

This is as far as I have gotten so far:)

> >Specification" and "Uses" sections and trusting the reader 

I don't think threats and impact will be the same in most cases.
Threats should be what a malicious party could do with them such as:
Negative scan, network mapping, spoofed reflective attack (w or w/o
amp), directed DOS attack.
I don't think you should combine them.

> draft I have active at the IETF... and you know what I am talking 

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