[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.