draft-ietf-v6ops-icmpv6-filtering-recs to informational

[Fred Baker <fred@cisco.com>]

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