Recommendations for Filtering ICMPv6 Messages in Firewalls
draft-ietf-v6ops-icmpv6-filtering-recs-03
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
03 | (System) | post-migration administrative database adjustment to the No Objection position for Jari Arkko |
2012-08-22
|
03 | (System) | post-migration administrative database adjustment to the No Objection position for Magnus Westerlund |
2007-04-19
|
03 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
2007-03-01
|
03 | (System) | IANA Action state changed to No IC from In Progress |
2007-03-01
|
03 | (System) | IANA Action state changed to In Progress |
2007-02-28
|
03 | Amy Vezza | IESG state changed to Approved-announcement sent |
2007-02-28
|
03 | Amy Vezza | IESG has approved the document |
2007-02-28
|
03 | Amy Vezza | Closed "Approve" ballot |
2007-02-27
|
03 | David Kessens | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by David Kessens |
2007-02-16
|
03 | Jari Arkko | [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss by Jari Arkko |
2007-02-16
|
03 | Magnus Westerlund | [Ballot Position Update] Position for Magnus Westerlund has been changed to No Objection from Discuss by Magnus Westerlund |
2007-02-14
|
03 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2007-02-14
|
03 | (System) | New version available: draft-ietf-v6ops-icmpv6-filtering-recs-03.txt |
2006-11-08
|
03 | (System) | Request for Early review by SECDIR Completed. Reviewer: Tero Kivinen. |
2006-10-27
|
03 | (System) | Removed from agenda for telechat - 2006-10-26 |
2006-10-26
|
03 | Amy Vezza | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza |
2006-10-26
|
03 | Jari Arkko | [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 … [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? |
2006-10-26
|
03 | Mark Townsley | [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley |
2006-10-26
|
03 | Magnus Westerlund | [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. … [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. |
2006-10-26
|
03 | Magnus Westerlund | [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. … [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. |
2006-10-26
|
03 | Magnus Westerlund | [Ballot Position Update] New position, Discuss, has been recorded by Magnus Westerlund |
2006-10-26
|
03 | Jari Arkko | [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 … [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? |
2006-10-26
|
03 | Jari Arkko | [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 … [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? |
2006-10-26
|
03 | Jari Arkko | [Ballot Position Update] New position, Discuss, has been recorded by Jari Arkko |
2006-10-26
|
03 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu |
2006-10-26
|
03 | Yoshiko Fong | IANA Last Call Comment: As described in the IANA Considerations section, we understand this document to have NO IANA Actions |
2006-10-26
|
03 | Yoshiko Fong | [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.' … [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 |
2006-10-25
|
03 | Russ Housley | [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 … [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/ |
2006-10-25
|
03 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley |
2006-10-25
|
03 | Brian Carpenter | [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 … [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. |
2006-10-25
|
03 | Brian Carpenter | [Ballot Position Update] New position, No Objection, has been recorded by Brian Carpenter |
2006-10-25
|
03 | Ross Callon | [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon |
2006-10-25
|
03 | Cullen Jennings | [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings |
2006-10-25
|
03 | Cullen Jennings | [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 … [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. |
2006-10-24
|
03 | Ted Hardie | [Ballot Position Update] New position, No Objection, has been recorded by Ted Hardie |
2006-10-24
|
03 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert |
2006-10-24
|
03 | Lars Eggert | [Ballot comment] Section 1., paragraph 1: > When a network supports IPv6 [RFC2460], the Internet Control Message > Protocol version 6 … [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.) |
2006-10-20
|
03 | David Kessens | [Ballot Position Update] New position, Yes, has been recorded for David Kessens |
2006-10-20
|
03 | David Kessens | Ballot has been issued by David Kessens |
2006-10-20
|
03 | David Kessens | Created "Approve" ballot |
2006-10-20
|
03 | David Kessens | Placed on agenda for telechat - 2006-10-26 by David Kessens |
2006-10-20
|
03 | David Kessens | State Changes to IESG Evaluation from Publication Requested::AD Followup by David Kessens |
2006-10-20
|
03 | David Kessens | [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.' … [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 |
2006-07-24
|
03 | Yoshiko Fong | IANA Last Call Comment: As described in the IANA Considerations section, we understand this document to have NO IANA Actions. |
2006-07-12
|
03 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2006-07-12
|
02 | (System) | New version available: draft-ietf-v6ops-icmpv6-filtering-recs-02.txt |
2006-07-09
|
03 | David Kessens | State Changes to Publication Requested::Revised ID Needed from Waiting for AD Go-Ahead by David Kessens |
2006-07-03
|
03 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2006-06-19
|
03 | Amy Vezza | Last call sent |
2006-06-19
|
03 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2006-06-19
|
03 | David Kessens | Last Call was requested by David Kessens |
2006-06-19
|
03 | (System) | Ballot writeup text was added |
2006-06-19
|
03 | (System) | Last call text was added |
2006-06-19
|
03 | (System) | Ballot approval text was added |
2006-06-19
|
03 | David Kessens | State Changes to Last Call Requested from Publication Requested by David Kessens |
2006-06-16
|
03 | Dinara Suleymanova | PROTO Write-up > 1.a) Have the chairs personally reviewed this version of the > Internet > Draft (ID), and in particular, do they believe this … 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. |
2006-06-16
|
03 | Dinara Suleymanova | Draft Added by Dinara Suleymanova in state Publication Requested |
2006-06-13
|
01 | (System) | New version available: draft-ietf-v6ops-icmpv6-filtering-recs-01.txt |
2006-04-26
|
00 | (System) | New version available: draft-ietf-v6ops-icmpv6-filtering-recs-00.txt |