Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-icmp-filtering-02.txt

From: Carlos Pignataro <[email-masked]>
Date: Sat, 10 Mar 2012 13:06:06 -0500

Hello, Panos,

Thanks for the feedback, please see inline.

On Feb 21, 2012, at 4:35 PM, Panos Kampanakis (pkampana) wrote:

> Hello,
> 
> Since this was revived (seems significantly changed with plenty of edits to
> follow), here are my initial comments.
> 
> 
> - In "2.  Internet Control Message Protocol version 4 (ICMP)" maybe it would
> be worth to clarify the table. That it refers to the actions devices need to
> take when generating, forwarding or receive such traffic.
> 
I thought this was clear, how would you improve for clarity?
> Also "Depr" keyword is not clear what it means. For traffic generated it
> means you are not supposed to generate it. But when you are receiving, does
> it mean you should not allow the packet?
> 
Good point. I think this should be (is) explained in each section since the table is only a summary.
> Also I am not sure about the "ICMPv4-unreach", "ICMPv4-redirect" and
> "ICMPv4-parameter" that are shown as N/A. The various codes for each are
> covered in the sebsequenct options per ICMP type. So, they represent a
> superset of the various options. So, I am not sure they need to be in the
> table. Or maybe then can be in there just to group their options together.
> 
> 
They are not aggregated because different codes for a given type do not have the same common recommendation.
> - There is a difference between Router and Firewall traffic processing. It
> seems the document mostly speaks about recommendations on how to process
> ICMP with routers. Maybe you want to clarify if the document addresses just
> routers of network devices in general. And if the scope includes firewalls,
> the recommendations especially for ICMP generation will need to be
> clarified.
> 
> 
When would they differ? I think we should refer to general network elements, no?
> - In "2.1.1.4.3.  Threats" it seems rate limiting doesn't address the
> "connection-reset attacks". Maybe you want to make it clear or propose other
> mitigations.
> You might also want to explicitly say that it should not be rate-limited or
> blocked.
> 
> - In 2.1.1.5.4. maybe you want to mention the impact of breaking PMTU,
> especially in VPN setups.
> 
We should probably find an RFC to cite, because we can go into a rat-hole describing this impact.
> 
> - In 2.1.1.7.3 and 2.1.1.9.3 don't you want to deny the deprecated message
> and not rate-limit?
> 
> 
We should clarify the behavior for deprecated.
> - In 2.1.1.10.3 and 2.1.1.11.3 "May reveal filtering policies" is not
> mitigated. You may want to mention the deny for transient traffic.
> 
> - In 2.1.1.12.3 and 2.1.1.13.2 "May reveal routing policies" is not
> mitigated. You may want to mention the deny for transient traffic.
> 
> - In most Threats section rate limiting is mentioned. But blocking transient
> traffic is not mentioned to mitigate threats even though it is in the tables
> as deny.
> 
> - 2.1.3.1.3, 2.1.3.2.3 and 2.1.3.3.3 don't discuss mitigations, rate
> limiting or blocking
> 
Sorry I do not understand these.
> 
> - Recommendations like inspection statefully or blocking broadcast
> destinations (smurf) are not addressed in 2.2.1.1.3 and 3.2.1.2.3 (ICMPv6)
> 
> 
But those are more specifics than the recommendations for the ICMP themselves. I am not sure it would make sense to describe every combination (multicast, ttl, etc)
> - 2.2.4.1 are deprecated messages. Should routers generate them or drop?
> Depr in the table doesn't show if I receive an information echo request
> wheat I should do as a router, for example.
> 
Good point. Same as above.
> 
> - Rare ICMPv4 message types 30 and 31 (rfc1475) could be mentioned
> 
> - IPv6 threats sections don't mention mitigations as in ICMP for IPv4
> 
> - Many ICMPv6 messages are missing from the v6 section including ICMPv6 RS,
> RA, NS, ND. A list is here http://www.iana.org/assignments/icmpv6-parameters
> 
> 
Yes, there are still messages pending.

Thanks again!

-- Carlos.
> 
> 
> Rgs,
> Panos
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Friday, February 17, 2012 10:58 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [OPSEC] I-D Action: draft-ietf-opsec-icmp-filtering-02.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Operational Security
> Capabilities for IP Network Infrastructure Working Group of the IETF.
> 
>         Title           : Recommendations for filtering ICMP messages
>         Author(s)       : Fernando Gont
>                           Guillermo Gont
>                           Carlos Pignataro
>         Filename        : draft-ietf-opsec-icmp-filtering-02.txt
>         Pages           : 49
>         Date            : 2012-02-17
> 
>    This document document provides advice on the filtering of ICMPv4 and
>    ICMPv6 messages.  Additionaly, it discusses the operational and
>    interoperability implications of such filtering.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-opsec-icmp-filtering-02.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-opsec-icmp-filtering-02.txt
> 
> _______________________________________________
> OPSEC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsec
> 
>

---

From: Fernando Gont <[email-masked]>
Date: Sun, 11 Mar 2012 09:17:01 -0300

Hi, Panos,

Please find my comments inline...

> take when generating, forwarding or receive such traffic.

You mean including such a para in Section 2, before the actual table? --
If so, I've just done that.

> it mean you should not allow the packet?

Good point. I've fixed this ("Depr" was "moved" to the message type, and
the "action" is now to "deny" them -- since they are deprecated).

> table. 

Makes sense. -- I've removed them.

> the recommendations especially for ICMP generation will need to be

This is kind of the similar issue that arised with the
ip-options-filtering I-D.

My take is that for routers, you block whatever is known to have
security implications ("default allow"), while for firewalls, you block
everything you have not explicitly allowed ("default deny").

I'd like others to weigh in about this one....

> "connection-reset attacks". Maybe you want to make it clear or propose other

Fixed.

> You might also want to explicitly say that it should not be rate-limited or

NOt sure why... could you please clarify this one?

> especially in VPN setups.

I've addded a few commments about this.

> - In 2.1.1.7.3 and 2.1.1.9.3 don't you want to deny the deprecated message

True. Done!

> mitigated. You may want to mention the deny for transient traffic.

Agreed about the "not mitigated" thing... However, I'm not sure what you
mean with the latter.

> - 2.1.3.1.3, 2.1.3.2.3 and 2.1.3.3.3 don't discuss mitigations, rate

Fixed!

> destinations (smurf) are not addressed in 2.2.1.1.3 and 3.2.1.2.3 (ICMPv6)

The problem with filtering broadcasted ICMPs is that it can only be
achieved at the last hop. -- I've added a note about this.

> wheat I should do as a router, for example.

I've fixed this.

> RA, NS, ND. A list is here http://www.iana.org/assignments/icmpv6-parameters

Yes. These will be included in the next rev.

Thanks!

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

---

From: "Panos Kampanakis" <[email-masked]>
Date: Mon, 12 Mar 2012 22:50:25 -0400

Thanks for answering my questions Fernando. They make sense. 

I am not sure if this comment has come up in the past, but I Came across
"RFC4890: Recommendations for Filtering ICMPv6 Messages in Firewalls". It
seems section 4 of that has similarities with the IPv6 section in
draft-ietf-opsec-icmp-filtering even though it doesn't follow the exact same
format. One distinction between draft-ietf-opsec-icmp-filtering and 4890 is
that it consolidates and summarizes v4 and v6 ICMP filtering. But are there
any other reasons why a newly created draft describes information in another
RFC without adding additional elements? I didn't see 4890 mentioned in
draft-ietf-opsec-icmp-filtering. Should draft-ietf-opsec-icmp-filtering
extend or update RFC4890?

Panos

-----Original Message-----
From: Fernando Gont [mailto:[email-masked]] On Behalf
Of Fernando Gont
Sent: Sunday, March 11, 2012 8:17 AM
To: Panos Kampanakis
Cc: [email-masked]; Carlos Pignataro (cpignata)
Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-icmp-filtering-02.txt

Hi, Panos,

On 02/21/2012 06:35 PM, Panos Kampanakis wrote:
> - In "2.  Internet Control Message Protocol version 4 (ICMP)" maybe it 
> would be worth to clarify the table. That it refers to the actions 
> devices need to take when generating, forwarding or receive such traffic.

You mean including such a para in Section 2, before the actual table? -- If
so, I've just done that.

> Also "Depr" keyword is not clear what it means. For traffic generated 
> it means you are not supposed to generate it. But when you are 
> receiving, does it mean you should not allow the packet?

Good point. I've fixed this ("Depr" was "moved" to the message type, and the
"action" is now to "deny" them -- since they are deprecated).

> "ICMPv4-parameter" that are shown as N/A. The various codes for each 
> are covered in the sebsequenct options per ICMP type. So, they 
> represent a superset of the various options. So, I am not sure they 
> need to be in the table.

> - There is a difference between Router and Firewall traffic 
> processing. It seems the document mostly speaks about recommendations 
> on how to process ICMP with routers. Maybe you want to clarify if the 
> document addresses just routers of network devices in general. And if 
> the scope includes firewalls, the recommendations especially for ICMP 
> generation will need to be clarified.

This is kind of the similar issue that arised with the ip-options-filtering
I-D.

My take is that for routers, you block whatever is known to have security
implications ("default allow"), while for firewalls, you block everything
you have not explicitly allowed ("default deny").

> "connection-reset attacks". Maybe you want to make it clear or propose 
> other mitigations.

Fixed.

> You might also want to explicitly say that it should not be 
> rate-limited or blocked.

> - In 2.1.1.7.3 and 2.1.1.9.3 don't you want to deny the deprecated 
> message and not rate-limit?

True. Done!

Fixed!

> destinations (smurf) are not addressed in 2.2.1.1.3 and 3.2.1.2.3 

The problem with filtering broadcasted ICMPs is that it can only be achieved
at the last hop. -- I've added a note about this.

> Depr in the table doesn't show if I receive an information echo 
> request wheat I should do as a router, for example.

I've fixed this.

> - Many ICMPv6 messages are missing from the v6 section including 
> ICMPv6 RS, RA, NS, ND. A list is here 
> http://www.iana.org/assignments/icmpv6-parameters

Thanks!

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