Recommendations for Filtering ICMPv6 Messages in Firewalls
RFC 4890
Yes
No Objection
Note: This ballot was opened for revision 03 and is now closed.
Lars Eggert No Objection
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
(Brian Carpenter; former steering group member) No Objection
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
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
(Jari Arkko; former steering group member) (was Discuss) No Objection
(Magnus Westerlund; former steering group member) (was Discuss) No Objection
(Mark Townsley; former steering group member) No Objection
(Ross Callon; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
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