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

From: Fred Baker <[email-masked]>
Date: Tue, 13 Jun 2006 12:52:29 -0700

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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 14 Jun 2006 00:20:38 +0200

On 13-jun-2006, at 21:52, Fred Baker wrote:

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

RFC 2461:

6.1.1.  Validation of Router Solicitation Messages

    Hosts MUST silently discard any received Router Solicitation
    Messages.

    A router MUST silently discard any received Router Solicitation
    messages that do not satisfy all of the following validity checks:

       - The IP Hop Limit field has a value of 255, i.e., the packet
         could not possibly have been forwarded by a router.

Although the document mentions using the hop limit at 255 as a  
security feature, I think this could be more prominent, as it may  
give people a reason to forego some or even all ICMPv6 filtering.

> As such, the document collects a fair bit of wisdom from which the  
> unschooled can learn.

You're making me bite my tongue here, Fred...

> presented during working group last call in May 2006. I believe  
> that it has had adequate review.

Please have the use of "hop count" changed to "hop limit" in the  
document to reflect the actual name of the field.

---

From: Fred Baker <[email-masked]>
Date: Tue, 13 Jun 2006 15:48:44 -0700

Let's see. How long have you had to review this, and when did the  
WGLC close? Remind me?

There will not be an IETF Last Call, as this is an informational  
document. If there were, I would encourage you to make the comment in  
response to the IETF last call. If the ADs send the document back for  
a new I-D for some reason, I will expect the authors to respond to  
this. I'm not going to hold it up for this, though. The document  
makes rather a point that there is significant value to ICMP  
filtering, so I can't imagine the comment really being interpreted as  
a reason to not filter.

On Jun 13, 2006, at 3:20 PM, Iljitsch van Beijnum wrote:
>> 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  
>> 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.
>
> RFC 2461:
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 14 Jun 2006 01:12:10 +0200

> Let's see. How long have you had to review this, and when did the  

I didn't read the document until a week ago or so when Pekka linked  
to it on the IETF list and asked for comments.

> document. If there were, I would encourage you to make the comment  
> in response to the IETF last call. If the ADs send the document  
> back for a new I-D for some reason, I will expect the authors to  
> respond to this. I'm not going to hold it up for this, though. The  
> document makes rather a point that there is significant value to  
> ICMP filtering, so I can't imagine the comment really being  
> interpreted as a reason to not filter.

No, why would we point out to people that our protocols are clever  
enough to not require any filtering? Or use the same name for the  
same field in different documents? That's way too much trouble with  
all those RFCs we have to write that no one in operations reads  
anyway because they're too long and too hard to read, and which are  
too hard to find out that they exist in the first place.

The fact that you talked about TTL=1 while claiming to have reviewed  
the document proves several of these points. Refusal to make changes  
proves a few more.

I know running a standards organization based 90% on volunteer effort  
is hard, but producing sub-par documents is not part of the solution.

The IETF seems fundamentally incapable of doing things fast, so  
getting things right is all the more important.

Last but not least: is "don't bother reviewing documents as we're  
going to ignore feedback" really the message you want to send? As  
soon as someone pays me to do IETF work I promise I'll get in my  
comments before last calls expire. Until that time, other work will  
have to take precedence.

---

From: Fred Baker <[email-masked]>
Date: Tue, 13 Jun 2006 17:29:53 -0700

No, I'm not trying to say "we're not going to do anything with the  
feedback". I *am*, however, saying that feedback needs to be timely,  
and given all the delays built into the system (one of which is me)  
and the number of times that the working group (which you are a part  
of) has been asked for comment, sending small comments in immediately  
after I *finally* send the document off to the IESG is *really*late*,  
and expecting the authors and the working group to spin on a dime to  
fix them isn't very realistic. If you want to discuss delays in  
process in detail, I would suggest you take Jim Bound or Yannick  
Pouffary aside and ask them what they really think about that silly  
chair of the v6ops WG delaying things every time just to get the  
document right...

We'll pick these comments up if the IESG asks for a revision.

As to my comment on the Hop Limit, I did read the document. It  
states, in several places, that the recommendation is that the Hop  
Limit be set to 255 and tested for still being 255 on receipt. What I  
stated was that I would go at it a different way. If the packet is  
sent with Hop Limit = 1, it cannot pass a compliant router or  
firewall, so there is no need to test for whether it did or didn't.  
My way is, I think, more robust - it depends only on the sender, not  
the sender and the receiver. But you note that I didn't require a  
change to suit my fancy either.

On Jun 13, 2006, at 4:12 PM, Iljitsch van Beijnum wrote:

> The fact that you talked about TTL=1 while claiming to have  
> reviewed the document proves several of these points. Refusal to  
> make changes proves a few more.
>
> I know running a standards organization based 90% on volunteer  
> effort is hard, but producing sub-par documents is not part of the  
> solution.
>

---

From: Pekka Savola <[email-masked]>
Date: Wed, 14 Jun 2006 07:59:27 +0300 (EEST)

On Wed, 14 Jun 2006, Iljitsch van Beijnum wrote:
> No, why would we point out to people that our protocols are clever enough to 
> not require any filtering? Or use the same name for the same field in 
> different documents? That's way too much trouble with all those RFCs we have 
> to write that no one in operations reads anyway because they're too long and 
> too hard to read, and which are too hard to find out that they exist in the 
> first place.

This is what section 4.3.3 is about.  I grant you that it doesn't seem 
to spell out our protocol design wisdom :-), but it does mention 
TTL=255 checking.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 14 Jun 2006 07:31:33 +0200

On 14-jun-2006, at 2:29, Fred Baker wrote:

> Limit be set to 255 and tested for still being 255 on receipt.

That's not a recommendation, it's a requirement.

> What I stated was that I would go at it a different way. If the  
> packet is sent with Hop Limit = 1, it cannot pass a compliant  
> router or firewall, so there is no need to test for whether it did  
> or didn't. My way is, I think, more robust - it depends only on the  
> sender, not the sender and the receiver. But you note that I didn't  
> require a change to suit my fancy either.

Setting and checking for 255 is a security feature: this makes it  
impossible for an attacker sitting behind one or more routers to  
spoof a packet that seems to originate on the local link, which can  
be done with 1.

And of course setting the hop limit to 1 and checking for 255 doesn't  
work, as we learned when trying to apply the same mechanism to BGP.

If vendors don't bother implementing the check for 255, the solution  
is for users to find a better vendor, not reward that behavior by  
relaxing security features.

---

From: Gert Doering <[email-masked]>
Date: Wed, 14 Jun 2006 17:28:11 +0200

Hi,

On Tue, Jun 13, 2006 at 05:29:53PM -0700, Fred Baker wrote:
> the sender and the receiver. 

Well, actually I tend to disagree.  If you're concerned about security,
you must assume that the sender will do everything possible to break
things - and that way, he will NOT be well-behaved and send out packets
with a TTL of 1.

Making the TTL=255? check on the receiver makes sure that the packet MUST
come from a directly connected host - no matter how ill the intentions of
the sender.

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  92315

SpaceNet AG                    Mail: [email-masked]
Joseph-Dollinger-Bogen 14      Tel : +49-89-32356-0
D- 80807 Muenchen              Fax : +49-89-32356-234

---

From: [email-masked]
Date: Wed, 14 Jun 2006 13:46:59 -0400 (EDT)

Just a couple of comments on this.

First, we should remember that all this hop count checking is pretty weak
security for protocols that have mechanisms like IPsec and SEND available.
Anyone who sees a packet can mess around with it and resend it wherever
one chooses.

Second, I don't see much benefit to the hop count = 1 trick. If the sender
wants the packet not to be routed, send it to a destination address on the
same segment.

Third, the hop count = 255 trick may have some benefit if routers and
other packet forwarders (we have lots of them in IPv6) are behaving
properly. But remember, for example, that packets from anywhere popping
out an IPv6-in-IPv4 transition mechanism tunnel don't typically get their
hop count decremented, so 255 can mean anything at that point.

Rich Graveman

---

From: Tim Chown <[email-masked]>
Date: Thu, 15 Jun 2006 11:53:32 +0100

> come from a directly connected host - no matter how ill the intentions of

Hmm, this discussion looks very familiar ;)

-- 
Tim/::1

---

From: David Kessens <[email-masked]>
Date: Mon, 19 Jun 2006 07:21:00 -0700

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

> elevation to BCP status in 12-24 months.

David Kessens
---

---

From: Fred Baker <[email-masked]>
Date: Mon, 19 Jun 2006 07:39:27 -0700

> resolution with (some of) Iljitsch comments.

Thanks.

---

From: Elwyn Davies <[email-masked]>
Date: Wed, 28 Jun 2006 10:58:54 +0100

[Having returned from holiday..]

Note: We are talking about draft-v6ops-icmpv6-filtering-recs-01.

Iljitsch van Beijnum wrote:
>> occurrence even if the router were misconfigured.
>
> RFC 2461:
>
> security feature, I think this could be more prominent, as it may give 
> people a reason to forego some or even all ICMPv6 filtering.
>
The draft itself is quite clear and accurate about the hop limit field 
in Router Solicitations (s 4.2.3 notes they must be received with hop 
limit = 255).  Fred's gloss needs to be corrected - a different example 
in the proto questionnaire would be better!
> document to reflect the actual name of the field.
This was corrected in the changes from -00 to -01.

Regards,
Elwyn

---

From: Elwyn Davies <[email-masked]>
Date: Wed, 28 Jun 2006 11:09:57 +0100

> to spell out our protocol design wisdom :-), but it does mention 
Iljitsch's previous comments *were* actioned.  v01 (which is the one 
that Fred was referring to and has gone to IETF Last Call) already had 
the hop count/hop limit issue fixed and an added note in s1 to direct 
impatient ICMPv6 experts straight to the rules section.

Hopefully we can publicise this document more widely once it has been 
approved/published  so that those real operations people can read it.

/Elwyn