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

[David Kessens <david.kessens@nokia.com>]

Fred,

I have requested the secretariat to do a last call on this document.
Strictly speaking, that is not required but I believe that there might
be a wider audience that is interested in this work than the standard
v6ops crowd.

Also, this can give you a chance/a bit of time to possibly find a
resolution with (some of) Iljitsch comments.

David Kessens
---

On Tue, Jun 13, 2006 at 12:52:29PM -0700, Fred Baker wrote:
> >   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.

David Kessens
---