Recommendations for Filtering ICMPv6 Messages in Firewalls
draft-ietf-v6ops-icmpv6-filtering-recs-03

[Ballot discuss]
In Section, 4.3.5 (Traffic which Should be Dropped Unless a 
Good Case can be Made), you list the unallocated values as
something that should be normally dropped. At the end of
the day, that is probably the right action, but needs to
be accompanied with a clear warning that as new technology
becomes developed, some of the currently unallocated numbers
may in fact be essential for some new service. I would
suggest reformulating the text on this. For instance,

  All informational messages with types not explicitly assigned by
  IANA are currently:

  o  Types 154 - 199 inclusive and 202 - 254 inclusive.

  The base ICMPv6 specification requires that informational
  messages with unknown types must be silently discarded. As
  a result, as long as none of the devices within the network
  support new extensions that use these numbers, there is
  no harm for letting them pass through. However, it may
  not always be possible to determine what new extensions
  are in the devices, or whether they pose security
  vulnerabilities. It is therefore recommended that these
  messages are currently dropped, but the administrators
  follow new developments and be ready to change the policy
  when new allocations appear.

(Update: after a discussion with Sam, we would
actually like to require both accept-unknown
and drop-unknown to be valid policies, without
recommending between them. So ignore the above
text suggestion.)

Also, I read the document as if it were directed to
an end site. Rules for service providers would be
quite different, e.g., I would not like to see
a service provider filter out unallocated ICMP
codes. Did I understand the target audience
correctly? If yes, can you add an explicit
statement at the beginning of the document
about it?

[Ballot discuss]
The document is missing scoping on the firewalls it addresses. I think there are at least three different main categories of firewalls:
a. End-host FW
b. Site border FW
c. ISP located FW

Without clear scoping on for who these rules applies it is very unclear if they the rules and recommendations are working correctly. For example from the security consideration:

3.4.  Renumbering Attacks

  Spurious Renumbering messages can lead to the disruption of a site.
  Although Renumbering messages are required to be authenticated with
  IPsec, so that it is difficult to carry out such attacks in practice,
  they should not be allowed through a firewall.

To me the above recommendations about filtering things work fine for the two last two types, but not well for a FW in an router or in front of a router for a small section of the site. Because that would prevent even legimite and authenticated messages to be dropped.

I would like to have the introduction part define which types of FW that the document addresses.

[Ballot discuss]
The document is missing scoping on the firewalls it addresses. I think there are at least three different main categories of firewalls:
a. End-host FW
b. Site border FW
c. ISP located FW

Without clear scoping on for who these rules applies it is very unclear if they the rules and recommendations are working correctly. For example from the security consideration:

3.4.  Renumbering Attacks

  Spurious Renumbering messages can lead to the disruption of a site.
  Although Renumbering messages are required to be authenticated with
  IPsec, so that it is difficult to carry out such attacks in practice,
  they should not be allowed through a firewall.

To me the above recommendations about filtering things work fine for the two last two types, but not well for a FW in an end-host. Because that would prevent even legimite and authenticated messages to be dropped.

[Ballot discuss]
In Section, 4.3.5 (Traffic which Should be Dropped Unless a 
Good Case can be Made), you list the unallocated values as
something that should be normally dropped. At the end of
the day, that is probably the right action, but needs to
be accompanied with a clear warning that as new technology
becomes developed, some of the currently unallocated numbers
may in fact be essential for some new service. I would
suggest reformulating the text on this. For instance,

  All informational messages with types not explicitly assigned by
  IANA are currently:

  o  Types 154 - 199 inclusive and 202 - 254 inclusive.

  The base ICMPv6 specification requires that informational
  messages with unknown types must be silently discarded. As
  a result, as long as none of the devices within the network
  support new extensions that use these numbers, there is
  no harm for letting them pass through. However, it may
  not always be possible to determine what new extensions
  are in the devices, or whether they pose security
  vulnerabilities. It is therefore recommended that these
  messages are currently dropped, but the administrators
  follow new developments and be ready to change the policy
  when new allocations appear.

Also, I read the document as if it were directed to
an end site. Rules for service providers would be
quite different, e.g., I would not like to see
a service provider filter out unallocated ICMP
codes. Did I understand the target audience
correctly? If yes, can you add an explicit
statement at the beginning of the document
about it?

[Ballot discuss]
In Section, 4.3.5 (Traffic which Should be Dropped Unless a 
Good Case can be Made), you list the unallocated values as
something that should be normally dropped. At the end of
the day, that is probably the right action, but needs to
be accompanied with a clear warning that as new technology
becomes developed, some of the currently unallocated numbers
may in fact be essential for some new service. I would
suggest reformulating the text on this. For instance,

  All informational messages with types not explicitly assigned by
  IANA are currently:

  o  Types 154 - 199 inclusive and 202 - 254 inclusive.

  The base ICMPv6 specification requires that informational
  messages with unknown types must be silently discarded. As
  a result, as long as none of the devices within the network
  support new extensions that use these numbers, there is
  no harm for letting them pass through. However, it may
  not always be possible to determine what new extensions
  are in the devices, or whether they pose security
  vulnerabilities. It is therefore recommended that these
  messages are currently dropped, but the administrators
  follow new developments and be ready to change the policy
  when new allocations appear.

Also, I read the document as if it were directed to
an end site. Rules for service providers would be
quite different, e.g., I would not like to see
a service provider filter out unallocated ICMP
codes. Did I understand the target audience
correctly? If yes, can you add an explicit
statement at the beginning of the document
about it?

[Note]: 'PROTO shepherd: Fred Baker This document is a late addition to the agenda.
Feel free to defer if you need more time for review.' added by Yoshiko Chong

[Ballot comment]
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/

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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.)

[Note]: 'PROTO shepherd: Fred Baker

This document is a late addition to the agenda.
Feel free to defer if you need more time for review.' added by David Kessens

PROTO Write-up

> 1.a) Have the chairs personally reviewed this version of the
> Internet
> Draft (ID), and in particular, do they believe this ID is
> ready
> to forward to the IESG for publication? Which chair is the WG
> Chair Shepherd for this document?

Yes, I have reviewed the document, and I plan to shepherd it. I
believe that it gives practical advice on who firewalls and other
security middleware may be configured to manage IPv6 ICMP traffic,
which one must expect to be used as IPv4 ICMP traffic has been used
in fomenting attacks.

The real value in this document, besides suggesting appropriate
firewall configurations, is in the lines of reasoning presented for
the configuration elements. For example, a router solicitation by
definition travels from a host seeking a first hop router to a system
that it is directly connected to at a lower layer such as a wired or
wireless Ethernet. The document recommends that this class of message
never be forwarded, and one in fact hopes that not only would it not
be forwarded, but that the originator would set TTL=1 to prevent the
occurrence even if the router were misconfigured. As such, the
document collects a fair bit of wisdom from which the unschooled can
learn.

> 1.b) Has the document had adequate review from both key WG members
> and key non-WG members? Do you have any concerns about the
> depth or breadth of the reviews that have been performed?

This document has been through working group review since its
introduction about a year ago. This version responds to comments
presented during working group last call in May 2006. I believe that
it has had adequate review.

> 1.c) Do you have concerns that the document needs more review
> from a
> particular (broader) perspective (e.g., security, operational
> complexity, someone familiar with AAA, internationalization,
> XML, etc.)?

Since it deals with security issues, a review from the security area
may be of value.

> 1.d) Do you have any specific concerns/issues with this document
> that
> you believe the ADs and/or IESG should be aware of? For
> example, perhaps you are uncomfortable with certain parts
> of the
> document, or have concerns whether there really is a need for
> it. In any event, if your issues have been discussed in
> the WG
> and the WG has indicated it that it still wishes to advance
> the
> document, detail those concerns in the write-up.

The document was originally proposed for BCP status, and was
downgraded to informational based on the notion that we should get
experience with the document before giving it that class of
approbation. We expect to review the document about a year hence in
view of operational experience. Apart from that, the working group
has been supportive.

> 1.e) How solid is the WG consensus behind this document? Does it
> represent the strong concurrence of a few individuals, with
> others being silent, or does the WG as a whole understand and
> agree with it?

v6ops is, as a group, quiet. One therefore has to describe this as
having strong proponents rather than an avalanch of support. My
observation, however, is that when v6ops does not support something,
they tell us, and this has not happened. I conclude that there is
operational support and little if any dissent.

> 1.f) Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarise the areas of conflict in
> separate email to the Responsible Area Director. (It
> should be
> separate email because this questionnaire will be entered into
> the tracker).

no

> 1.g) Have the chairs verified that the document checks out against
> all the ID nits? (see http://www.ietf.org/ID-Checklist.html).
> Boilerplate checks are not enough; this check needs to be
> thorough.

draft-ietf-v6ops-icmpv6-filtering-recs-01.txt was run through idnits
1.102 on 13 June. It reported no issues.

I also ran it through ispell on a Solaris system. It revealed some
disagreements between British and American versions of English. The
Brits can't spill there wards rite.

> 1.h) Has the document split its references into normative and
> informative? Are there normative references to IDs, where the
> IDs are not also ready for advancement or are otherwise in an
> unclear state? The RFC Editor will not publish an RFC with
> normative references to IDs (will delay the publication until
> all such IDs are also ready for RFC publicatioin). If the
> normative references are behind, what is the strategy for
> their
> completion? On a related matter, are there normative
> references
> that are downward references, as described in BCP 97, RFC 3967
> RFC 3967 [RFC3967]? Listing these supports the Area
> Director in
> the Last Call downref procedure specified in RFC 3967.

The references are so divided.

There are two normative references to internet drafts, draft-ietf-
ipngwg-icmp-name-lookups and draft-ietf-ipngwg-icmp-v3. The former is
in the RFC Editor's queue, and the latter was recently published as
RFC 4443, which is also listed as a normative reference.

In addition, there are two informative references to internet drafts.
draft-chown-v6ops-port-scanning-implications will, in the coming
weeks, be replaced by draft-ietf-v6ops-scanning-implications, and
will in all likelihood be sent to the IESG following a working group
last call in July. draft-gont-tcpm-icmp-attacks has been replaced by
draft-ietf-tcpm-icmp-attacks, which was placed in the "AD is
watching" state by Lars Eggert last March.

I would recommend that the RFC Editor update these references to the
appropriate RFC references during the edit-for-publication process.

> 1.i) For Standards Track and BCP documents, the IESG approval
> announcement includes a write-up section with the following
> sections:
>
> * Technical Summary

In networks supporting IPv6 the Internet Control Message Protocol
version 6 (ICMPv6) plays a fundamental role with a large number of
functions, and a correspondingly large number of message types and
options. A number of security risks are associated with uncontrolled
forwarding of ICMPv6 messages. On the other hand, compared with IPv4
and the corresponding protocol ICMP, ICMPv6 is essential to the
functioning of IPv6 rather than a useful auxiliary. This document
provides some recommendations for ICMPv6 firewall filter
configuration that will allow propagation of ICMPv6 messages that are
needed to maintain the functioning of the network but drop messages
which are potential security risks.

> * Working Group Summary

This was approved by the IPv6 Operations Working Group following an
extended discussion.

> * Protocol Quality

This is not a protocol, but it describes operational configurations
for mnaging a protocol whose counterpart has warranted similar
controls in the IPv4 Internet. The working group believes that the
logic it presents and the configuration paradigm it espouses are
correct. v6ops plans to review deployment experience and recommend
elevation to BCP status in 12-24 months.