Skip to main content

Recommendations for Filtering ICMPv6 Messages in Firewalls
RFC 4890

Yes

(David Kessens)

No Objection

(Dan Romascanu)
(Jari Arkko)
(Magnus Westerlund)
(Mark Townsley)
(Ross Callon)
(Ted Hardie)

Note: This ballot was opened for revision 03 and is now closed.

Lars Eggert No Objection

Comment (2006-10-24)
Section 1., paragraph 1:
>    When a network supports IPv6 [RFC2460], the Internet Control Message
>    Protocol version 6 (ICMPv6) [RFC4443], [I-D.ietf-ipngwg-icmp-v3]
>    plays a fundamental role including being an essential component in
>    establishing communications both at the interface level and for
>    sessions to remote nodes.  This means that overly aggressive
>    filtering of ICMPv6 may have a detrimental effect on the
>    establishment of IPv6 communications.

  It's not only "establishment" but also management of established
  connections for which some types of ICMP messages are critical, e.g.,
  PMTU discovery after a route change. I'd thus suggest to rephrase this
  throughout the document.


Section 1., paragraph 4:
>             [[anchor2: [RFC Editor: Please update
>             references to RFC2461 when the new version of RFC2461 is
>             published.] --Authors]]

  If the intent is to hold this document until a revision of RFC2461 (a
  normative reference) is published, update the reference to the ID that
  updates RFC2461. (If that isn't the intent, I don't understand the
  reason for these instructions.)

>             [[anchor3:
>             [RFC Editor: Please update references to RFC2462 when the
>             new version of RFC2462 is published.] --Authors]]

  Same as for RFC2461 above.


Section 2.4., paragraph 1:
>    Many ICMPv6 messages have a role in establishing communications to
>    and from the firewall and such messages have to be accepted by
>    firewalls for local delivery.  Generally a firewall will also be
>    acting as a router so that all the messages that might be used in
>    configuring a router interface need to be accepted and generated.
>    This type of communication establishment messages should not be
>    passed through a firewall as they are normally intended for use
>    within a link.

  I don't understand how "this type of communication establishment
  messages should not be passed..." in the last sentence follows from
  the preceding ones, because they talk about passing such messages.


Section 4.1., paragraph 2:
>    Messages that are authenticated by means of an IPsec AH or ESP header
>    may be subject to less strict policies than unauthenticated messages.

  Does "are authenticated" mean "the firewall can authenticate them" or
  "an AH or ESP header is present?" (The latter doesn't really add much
  security.)


Section 4.3.4., paragraph 3:
>    The base ICMPv6 specification suggests that error messages which are
>    not explicitly known to a node should be forwarded and passed to any
>    higher level protocol that might be able to interpret them.  There is
>    a small risk that such messages could be used to provide a covert
>    channel or form part of a DoS attack.  Administrators should be aware
>    of this and determine whether they wish to allow these messages
>    through the firewall.

  Paragraph seems to make a much weaker recommendation that the heading
  implies ("Traffic for which a Dropping Policy Should be Defined.") I
  understood the heading to mean "SHOULD drop." Rephrase heading?
  (Comment also applies to other sections with the same heading below.)

(David Kessens; former steering group member) Yes

Yes ()

                            

(Brian Carpenter; former steering group member) No Objection

No Objection (2006-10-25)
From Gen-ART review by Spencer Dawkins:

Non-English:

  o  Messages that may be dropped in firewall/routers but it is not
     essential because they would normally be dropped for other reasons
     (e.g., because they would be using link-local addresses) or the
     protocol specification would cause them to be rejected if they had
     passed through a router.

Perhaps

  o  Messages that may be dropped in firewall/routers, but these messages
     may already be targeted to drop for other reasons, (e.g., because
     they are using link-local addresses), or because the protocol
     specification would cause the messages to be rejected if they had
     passed through a router.

(Cullen Jennings; former steering group member) No Objection

No Objection (2006-10-25)
I think putting this sort of code in a document is a bad idea. The odds that someone will have to make an update to this are very high. It is not clear what license this code is under of if anyone can use for  anything. My recommendation would be make this code available under some open source license, put it on a website somewhere and have this document have an informational reference to that web site.

(Dan Romascanu; former steering group member) No Objection

No Objection ()

                            

(Jari Arkko; former steering group member) (was Discuss) No Objection

No Objection ()

                            

(Magnus Westerlund; former steering group member) (was Discuss) No Objection

No Objection ()

                            

(Mark Townsley; former steering group member) No Objection

No Objection ()

                            

(Ross Callon; former steering group member) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) No Objection

No Objection (2006-10-25)
  In section 3.3, there should be a distinction to open wireless links
  and ones that require authentication.  For example, the use of IEEE
  802.11i with EAP-TLS adds considerable security.  I suggest:

    s/a wireless link/an open wireless link/

(Ted Hardie; former steering group member) No Objection

No Objection ()