[Ballot comment]

Thanks for addressing my discuss points.

--- old comments below

Used to be a discuss point:

(1) Only just about a discuss:  The title is overly broad -
are you claiming to have identified *all* security
implications? I doubt that. Truth in advertising would
suggest pre-pending "Some" to the title or perhaps appending
"considered in a bath." Same goes for the abstract.

-- comments....

- end of section 2: is it really true that the exact same
policies should be enforced for v6 and v4? I guess that
depends on what you call policy - some might consider the use
of NATs and private address space as a policy but that
doesn't seem to be something worth recommending does it? I'm
happy to let the INT or OPSEC folks say this however they
like but as stated this seems overly broad.

- 2.1 - is it really wise to recommend blocking v6 at layer
2? Would that not possibly get hard to turn off when you do
want v6 packets? Seems fragile to me fwiw. I know you don't
strongly recommend that but for things like this where you
point at something it'd be better if you also called out any
significant downsides.

[Ballot comment]
With respect to stephen's discuss. There's no advice I'm aware of out there as to how else to ameliorate that situation. nor were we able to solicit any.

Certain transition states (or in this case non-transition) effectively require the selective omission or synthesis of resource records for the avoidance of unwanted traffic, skipping over bugs in your stack, or in the ipv6 --> ipv4 direction to attract traffic to translators. those reflect local preference necessity and are hopefully not internet scale.

perhaps it is best to simply note that conquences for dnssec validation exist, that cannot be aleviated short of not doing it that way.

[Ballot discuss]
updated for -06

I don't see any change here and don't recall any specific
suggested text from authors/chairs/shepherd on the topic.
Apologies if I've missed that, (in which case please point
me at it) but it looks to me like the discuss point remains
unresolved.

(2) section 4, 3rd para seems to recommend something that'd
make DNSSEC deployment harder. Even in an informational
document that seems like a bad plan. Why is it ok to
recommend that? Or am I wrong that this practice would make
it harder to start deploying DNSSEC?

[Ballot comment]
Used to be a discuss point:

(1) Only just about a discuss:  The title is overly broad -
are you claiming to have identified *all* security
implications? I doubt that. Truth in advertising would
suggest pre-pending "Some" to the title or perhaps appending
"considered in a bath." Same goes for the abstract.

-- comments....

- end of section 2: is it really true that the exact same
policies should be enforced for v6 and v4? I guess that
depends on what you call policy - some might consider the use
of NATs and private address space as a policy but that
doesn't seem to be something worth recommending does it? I'm
happy to let the INT or OPSEC folks say this however they
like but as stated this seems overly broad.

- 2.1 - is it really wise to recommend blocking v6 at layer
2? Would that not possibly get hard to turn off when you do
want v6 packets? Seems fragile to me fwiw. I know you don't
strongly recommend that but for things like this where you
point at something it'd be better if you also called out any
significant downsides.

[Ballot comment]
I am abstaining on this document—I think the advice here is as good as can be managed if you want to disable IPv6 on your network, which is a valid thing to want to do, but I am uncomfortable with the IETF giving advice on how to do it. All of my comments and DISCUSSes (shown below) have been addressed.

Former comment:

The buffer overflow referred to in [Core2007] is six years old at the time of review, applies to an operating system that no-one uses, and is therefore a poor basis for recommending link-local filtering.  I think protecting against RA-based and DHCPv6-based attacks is important, but can't be cleanly achieved by filtering the IPv6 ethertype.

I support Stephen Farrel's DISCUSS relating to DNSSEC, as well as Barry Lieba's comment.

I think this document is trying to do something worthwhile, so please don't take these DISCUSS points as general disapproval.

Former DISCUSS:

1. This document recommends filtering all IPv6 link-local traffic. Link-local IPv6 traffic is widely used on notionally IPv4-only networks. For example Apple's Bonjour protocol relies on IPv6 link-local addressing. So filtering this traffic would create significant operational problems even in supposedly IPv4-only networks. Bonjour is widely used even by non-Apple devices, including most IP printers and Microsoft Windows printer drivers, so even a non-Apple shop would have a problem with this recommendation.

Proposed action: remove the first paragraph of section 2.1. Remove this text from the next paragraph:

  However,
  neither RA-Guard nor DHCPv6-Shield can mitigate attack vectors that
  employ IPv6 link-local addresses, since configuration of such
  addresses does not rely on Router Advertisement messages or DCHPv6-
  server messages.

Remove this paragraph:

      If native IPv6 traffic is filtered at layer-2, local IPv6 nodes
      would only get to configure IPv6 link-local addresses.

As an alternative, the authors could consider a much more restricted recommendation similar to the first paragraph of 2.1, but referring only to RA traffic and DHCPv6 traffic. This requires a fancier switch, but doesn't break Bonjour.

A much less satisfactory alternative would be to simply say that breaking IPv6 at layer two breaks Bonjour. In combination with a very strong applicability statement (see point 2), I would feel compelled to clear this item in the DISCUSS, even though I would not actually be happy with the outcome.  If you go this route, you should include all but the first sentence of the first paragraph of this DISCUSS point so that network operators who may not be aware of this realize what's at stake.

2. This document makes broad recommendations about filtering tunnel traffic. These recommendations are appropriate in an enterprise environment where IPv6 is not yet deployed, but are inappropriate in most other contexts (e.g., it would be very damaging if ISPs started filtering all tunnel traffic).

Proposed action: This document needs a very clear applicability statement at the top, before it even talks about any sort of recommendation of this type. There is a single sentence in the introduction about applicability, but this isn't sufficient.  I would suggest something like the following:

  Most general-purpose operating systems implement and enable native
  IPv6 [RFC2460] support and a number of transition/co-existence
  technologies by default.  Support of IPv6 by all nodes is intended
  to become best current practice [RFC6540].  Some enterprise
  networks might, however, choose to delay active use of IPv6.

  This document describes operational practices for enterprise networks
  to prevent security exposure resulting from unplanned use of IPv6 on
  such networks. This document is only applicable to enterprise
  networks: networks where the network operator is not providing a
  general-purpose internet, but rather a business-specific network. The
  solutions proposed here are not practical for home networks, nor are
  they appropriate for provider networks such as ISPs, mobile
  providers, Wifi hotspot providers or any other public internet
  service.

  In scenarios in which the IPv6-capable devices
  are deployed on enterprise networks that are
  intended to be IPv4-only, native IPv6 support and/or IPv6 transition/
  co-existence technologies could be leveraged by local or remote
  attackers for a number of (illegitimate) purposes.  For example,

Proposed alternative action: Some kinds of tunnel traffic are okay to filter in all environments, because their use is deprecated.  If this document only referred to those types of traffic, this would also satisfy my concern. E.g., I don't think it's a problem to have a blanket recommendation to filter Teredo.

3. This recommendation breaks DNS:

  For this reason, networks attempting to prevent IPv6 traffic from
  traversing their devices should consider configuring their local
  recursive DNS servers to respond to queries for AAAA DNS records with
  a DNS RCODE of 3 (NXDOMAIN) [RFC1035] or to silently ignore such
  queries, and should even consider filtering AAAA records at the
  network ingress point to prevent the internal hosts from attempting
  their own DNS resolution.  This will ensure that hosts which are on
  an IPv4-only network will only receive DNS A records, and they will
  be unlikely to attempt to use (likely broken) IPv6 connectivity to
  reach their desired destinations.

Suppose I do a AAAA query and an A query for a name that has non-AAAA records. Returning NXDOMAIN tells the resolver that there is no such domain name, not that there is no such record. The correct answer in this case is NOERROR, and an answer that contains no records. Silently ignoring these queries is bad advice as well, since it could potentially result in 90 second delays in accessing web pages on dual-stack servers.

Happy Eyeballs is at this point a widely-deployed solution, present in all modern web browsers, so filtering AAAA records to route around brokenness is probably not needed. However, if the working group really has consensus to make a recommendation like this, it should at least do it in a way that doesn't break the DNS.

Proposed action: Delete this paragraph.

Alternative proposed action: specify that when filtering AAAA queries, the filtering entity needs to actually do the query, and then return no records if it receives an answer. This is a fairly easy thing to do on a DNS proxy. Explain why just returning NXDOMAIN or dropping the query will break DNS.

If you go with the alternative proposed action, whatever text you put in should be vetted by the DNS directorate, because I'm just an amateur DNS geek and can't promise that I got the advice exactly right.

[Ballot comment]
I am abstaining on this document—I think the advice here is as good as can be managed if you want to disable IPv6 on your network, which is a valid thing to want to do, but I am uncomfortable with the IETF giving advice on how to do it.

The buffer overflow referred to in [Core2007] is six years old at the time of review, applies to an operating system that no-one uses, and is therefore a poor basis for recommending link-local filtering.  I think protecting against RA-based and DHCPv6-based attacks is important, but can't be cleanly achieved by filtering the IPv6 ethertype.

I support Stephen Farrel's DISCUSS relating to DNSSEC, as well as Barry Lieba's comment.

I think this document is trying to do something worthwhile, so please don't take these DISCUSS points as general disapproval.

Former DISCUSS:

1. This document recommends filtering all IPv6 link-local traffic. Link-local IPv6 traffic is widely used on notionally IPv4-only networks. For example Apple's Bonjour protocol relies on IPv6 link-local addressing. So filtering this traffic would create significant operational problems even in supposedly IPv4-only networks. Bonjour is widely used even by non-Apple devices, including most IP printers and Microsoft Windows printer drivers, so even a non-Apple shop would have a problem with this recommendation.

Proposed action: remove the first paragraph of section 2.1. Remove this text from the next paragraph:

  However,
  neither RA-Guard nor DHCPv6-Shield can mitigate attack vectors that
  employ IPv6 link-local addresses, since configuration of such
  addresses does not rely on Router Advertisement messages or DCHPv6-
  server messages.

Remove this paragraph:

      If native IPv6 traffic is filtered at layer-2, local IPv6 nodes
      would only get to configure IPv6 link-local addresses.

As an alternative, the authors could consider a much more restricted recommendation similar to the first paragraph of 2.1, but referring only to RA traffic and DHCPv6 traffic. This requires a fancier switch, but doesn't break Bonjour.

A much less satisfactory alternative would be to simply say that breaking IPv6 at layer two breaks Bonjour. In combination with a very strong applicability statement (see point 2), I would feel compelled to clear this item in the DISCUSS, even though I would not actually be happy with the outcome.  If you go this route, you should include all but the first sentence of the first paragraph of this DISCUSS point so that network operators who may not be aware of this realize what's at stake.

2. This document makes broad recommendations about filtering tunnel traffic. These recommendations are appropriate in an enterprise environment where IPv6 is not yet deployed, but are inappropriate in most other contexts (e.g., it would be very damaging if ISPs started filtering all tunnel traffic).

Proposed action: This document needs a very clear applicability statement at the top, before it even talks about any sort of recommendation of this type. There is a single sentence in the introduction about applicability, but this isn't sufficient.  I would suggest something like the following:

  Most general-purpose operating systems implement and enable native
  IPv6 [RFC2460] support and a number of transition/co-existence
  technologies by default.  Support of IPv6 by all nodes is intended
  to become best current practice [RFC6540].  Some enterprise
  networks might, however, choose to delay active use of IPv6.

  This document describes operational practices for enterprise networks
  to prevent security exposure resulting from unplanned use of IPv6 on
  such networks. This document is only applicable to enterprise
  networks: networks where the network operator is not providing a
  general-purpose internet, but rather a business-specific network. The
  solutions proposed here are not practical for home networks, nor are
  they appropriate for provider networks such as ISPs, mobile
  providers, Wifi hotspot providers or any other public internet
  service.

  In scenarios in which the IPv6-capable devices
  are deployed on enterprise networks that are
  intended to be IPv4-only, native IPv6 support and/or IPv6 transition/
  co-existence technologies could be leveraged by local or remote
  attackers for a number of (illegitimate) purposes.  For example,

Proposed alternative action: Some kinds of tunnel traffic are okay to filter in all environments, because their use is deprecated.  If this document only referred to those types of traffic, this would also satisfy my concern. E.g., I don't think it's a problem to have a blanket recommendation to filter Teredo.

3. This recommendation breaks DNS:

  For this reason, networks attempting to prevent IPv6 traffic from
  traversing their devices should consider configuring their local
  recursive DNS servers to respond to queries for AAAA DNS records with
  a DNS RCODE of 3 (NXDOMAIN) [RFC1035] or to silently ignore such
  queries, and should even consider filtering AAAA records at the
  network ingress point to prevent the internal hosts from attempting
  their own DNS resolution.  This will ensure that hosts which are on
  an IPv4-only network will only receive DNS A records, and they will
  be unlikely to attempt to use (likely broken) IPv6 connectivity to
  reach their desired destinations.

Suppose I do a AAAA query and an A query for a name that has non-AAAA records. Returning NXDOMAIN tells the resolver that there is no such domain name, not that there is no such record. The correct answer in this case is NOERROR, and an answer that contains no records. Silently ignoring these queries is bad advice as well, since it could potentially result in 90 second delays in accessing web pages on dual-stack servers.

Happy Eyeballs is at this point a widely-deployed solution, present in all modern web browsers, so filtering AAAA records to route around brokenness is probably not needed. However, if the working group really has consensus to make a recommendation like this, it should at least do it in a way that doesn't break the DNS.

Proposed action: Delete this paragraph.

Alternative proposed action: specify that when filtering AAAA queries, the filtering entity needs to actually do the query, and then return no records if it receives an answer. This is a fairly easy thing to do on a DNS proxy. Explain why just returning NXDOMAIN or dropping the query will break DNS.

If you go with the alternative proposed action, whatever text you put in should be vetted by the DNS directorate, because I'm just an amateur DNS geek and can't promise that I got the advice exactly right.

[Ballot discuss]

updated for -05

(2) section 4, 3rd para seems to recommend something that'd
make DNSSEC deployment harder. Even in an informational
document that seems like a bad plan. Why is it ok to
recommend that? Or am I wrong that this practice would make
it harder to start deploying DNSSEC?

[Ballot comment]

Used to be a discuss point:

(1) Only just about a discuss:  The title is overly broad -
are you claiming to have identified *all* security
implications? I doubt that. Truth in advertising would
suggest pre-pending "Some" to the title or perhaps appending
"considered in a bath." Same goes for the abstract.

-- comments....

- end of section 2: is it really true that the exact same
policies should be enforced for v6 and v4? I guess that
depends on what you call policy - some might consider the use
of NATs and private address space as a policy but that
doesn't seem to be something worth recommending does it? I'm
happy to let the INT or OPSEC folks say this however they
like but as stated this seems overly broad.

- 2.1 - is it really wise to recommend blocking v6 at layer
2? Would that not possibly get hard to turn off when you do
want v6 packets? Seems fragile to me fwiw. I know you don't
strongly recommend that but for things like this where you
point at something it'd be better if you also called out any
significant downsides.

[Ballot comment]
This document is far enough outside of my expertise that I would normally ballot NO OBJECTION, especially because it's Informational. But between Brian's ABSTAIN, Stephen's DISCUSS, and the fact that I can't determine how this fits into OPSEC's charter, I will also ABSTAIN. Since this is Informational, this makes no practical difference; if Joel wants to go ahead with the document, my abstention won't affect approval. But I thought I ought to register my concern.

[Ballot comment]
The buffer overflow referred to in [Core2007] is six years old at the time of review, applies to an operating system that no-one uses, and is therefore a poor basis for recommending link-local filtering.  I think protecting against RA-based and DHCPv6-based attacks is important, but can't be cleanly achieved by filtering the IPv6 ethertype.

I support Stephen Farrel's DISCUSS relating to DNSSEC, as well as Barry Lieba's comment.

I think this document is trying to do something worthwhile, so please don't take these DISCUSS points as general disapproval.

[Ballot discuss]
1. This document recommends filtering all IPv6 link-local traffic. Link-local IPv6 traffic is widely used on notionally IPv4-only networks. For example Apple's Bonjour protocol relies on IPv6 link-local addressing. So filtering this traffic would create significant operational problems even in supposedly IPv4-only networks. Bonjour is widely used even by non-Apple devices, including most IP printers and Microsoft Windows printer drivers, so even a non-Apple shop would have a problem with this recommendation.

Proposed action: remove the first paragraph of section 2.1. Remove this text from the next paragraph:

  However,
  neither RA-Guard nor DHCPv6-Shield can mitigate attack vectors that
  employ IPv6 link-local addresses, since configuration of such
  addresses does not rely on Router Advertisement messages or DCHPv6-
  server messages.

Remove this paragraph:

      If native IPv6 traffic is filtered at layer-2, local IPv6 nodes
      would only get to configure IPv6 link-local addresses.

As an alternative, the authors could consider a much more restricted recommendation similar to the first paragraph of 2.1, but referring only to RA traffic and DHCPv6 traffic. This requires a fancier switch, but doesn't break Bonjour.

A much less satisfactory alternative would be to simply say that breaking IPv6 at layer two breaks Bonjour. In combination with a very strong applicability statement (see point 2), I would feel compelled to clear this item in the DISCUSS, even though I would not actually be happy with the outcome.  If you go this route, you should include all but the first sentence of the first paragraph of this DISCUSS point so that network operators who may not be aware of this realize what's at stake.

2. This document makes broad recommendations about filtering tunnel traffic. These recommendations are appropriate in an enterprise environment where IPv6 is not yet deployed, but are inappropriate in most other contexts (e.g., it would be very damaging if ISPs started filtering all tunnel traffic).

Proposed action: This document needs a very clear applicability statement at the top, before it even talks about any sort of recommendation of this type. There is a single sentence in the introduction about applicability, but this isn't sufficient.  I would suggest something like the following:

  Most general-purpose operating systems implement and enable native
  IPv6 [RFC2460] support and a number of transition/co-existence
  technologies by default.  Support of IPv6 by all nodes is intended
  to become best current practice [RFC6540].  Some enterprise
  networks might, however, choose to delay active use of IPv6.

  This document describes operational practices for enterprise networks
  to prevent security exposure resulting from unplanned use of IPv6 on
  such networks. This document is only applicable to enterprise
  networks: networks where the network operator is not providing a
  general-purpose internet, but rather a business-specific network. The
  solutions proposed here are not practical for home networks, nor are
  they appropriate for provider networks such as ISPs, mobile
  providers, Wifi hotspot providers or any other public internet
  service.

  In scenarios in which the IPv6-capable devices
  are deployed on enterprise networks that are
  intended to be IPv4-only, native IPv6 support and/or IPv6 transition/
  co-existence technologies could be leveraged by local or remote
  attackers for a number of (illegitimate) purposes.  For example,

Proposed alternative action: Some kinds of tunnel traffic are okay to filter in all environments, because their use is deprecated.  If this document only referred to those types of traffic, this would also satisfy my concern. E.g., I don't think it's a problem to have a blanket recommendation to filter Teredo.

3. This recommendation breaks DNS:

  For this reason, networks attempting to prevent IPv6 traffic from
  traversing their devices should consider configuring their local
  recursive DNS servers to respond to queries for AAAA DNS records with
  a DNS RCODE of 3 (NXDOMAIN) [RFC1035] or to silently ignore such
  queries, and should even consider filtering AAAA records at the
  network ingress point to prevent the internal hosts from attempting
  their own DNS resolution.  This will ensure that hosts which are on
  an IPv4-only network will only receive DNS A records, and they will
  be unlikely to attempt to use (likely broken) IPv6 connectivity to
  reach their desired destinations.

Suppose I do a AAAA query and an A query for a name that has non-AAAA records. Returning NXDOMAIN tells the resolver that there is no such domain name, not that there is no such record. The correct answer in this case is NOERROR, and an answer that contains no records. Silently ignoring these queries is bad advice as well, since it could potentially result in 90 second delays in accessing web pages on dual-stack servers.

Happy Eyeballs is at this point a widely-deployed solution, present in all modern web browsers, so filtering AAAA records to route around brokenness is probably not needed. However, if the working group really has consensus to make a recommendation like this, it should at least do it in a way that doesn't break the DNS.

Proposed action: Delete this paragraph.

Alternative proposed action: specify that when filtering AAAA queries, the filtering entity needs to actually do the query, and then return no records if it receives an answer. This is a fairly easy thing to do on a DNS proxy. Explain why just returning NXDOMAIN or dropping the query will break DNS.

If you go with the alternative proposed action, whatever text you put in should be vetted by the DNS directorate, because I'm just an amateur DNS geek and can't promise that I got the advice exactly right.

[Ballot discuss]
1. This document recommends filtering all IPv6 link-local traffic. Link-local IPv6 traffic is widely used on notionally IPv4-only networks. For example Apple's Bonjour protocol relies on IPv6 link-local addressing. So filtering this traffic would create significant operational problems even in supposedly IPv4-only networks. Bonjour is widely used even by non-Apple devices, including most IP printers and Microsoft Windows printer drivers, so even a non-Apple shop would have a problem with this recommendation.

Proposed action: remove the first paragraph of section 2.1. Remove this text from the next paragraph:

  However,
  neither RA-Guard nor DHCPv6-Shield can mitigate attack vectors that
  employ IPv6 link-local addresses, since configuration of such
  addresses does not rely on Router Advertisement messages or DCHPv6-
  server messages.

Remove this paragraph:

      If native IPv6 traffic is filtered at layer-2, local IPv6 nodes
      would only get to configure IPv6 link-local addresses.

As an alternative, the authors could consider a much more restricted recommendation similar to the first paragraph of 2.1, but referring only to RA traffic and DHCPv6 traffic. This requires a fancier switch, but doesn't break Bonjour.

A much less satisfactory alternative would be to simply say that breaking IPv6 at layer two breaks Bonjour. In combination with a very strong applicability statement (see point 2), I would feel compelled to clear this item in the DISCUSS, even though I would not actually be happy with the outcome.  If you go this route, you should include all but the first sentence of the first paragraph of this DISCUSS point so that network operators who may not be aware of this realize what's at stake.

2. This document makes broad recommendations about filtering tunnel traffic. These recommendations are appropriate in an enterprise environment where IPv6 is not yet deployed, but are inappropriate in most other contexts (e.g., it would be very damaging if ISPs started filtering all tunnel traffic).

Proposed action: This document needs a very clear applicability statement at the top, before it even talks about any sort of recommendation of this type. There is a single sentence in the introduction about applicability, but this isn't sufficient.  I would suggest something like the following:

  Most general-purpose operating systems implement and enable native
  IPv6 [RFC2460] support and a number of transition/co-existence
  technologies by default.  Support of IPv6 by all nodes is intended
  to become best current practice [RFC6540].  Some enterprise
  networks might, however, choose to delay active use of IPv6.

  This document describes operational practices for enterprise networks
  to prevent security exposure resulting from unplanned use of IPv6 on
  such networks. This document is only applicable to enterprise
  networks: networks where the network operator is not providing a
  general-purpose internet, but rather a business-specific network. The
  solutions proposed here are not practical for home networks, nor are
  they appropriate for provider networks such as ISPs, mobile
  providers, Wifi hotspot providers or any other public internet
  service.

  In scenarios in which the IPv6-capable devices
  are deployed on enterprise networks that are
  intended to be IPv4-only, native IPv6 support and/or IPv6 transition/
  co-existence technologies could be leveraged by local or remote
  attackers for a number of (illegitimate) purposes.  For example,

Proposed alternative action: Some kinds of tunnel traffic are okay to filter in all environments, because their use is deprecated.  If this document only referred to those types of traffic, this would also satisfy my concern. E.g., I don't think it's a problem to have a blanket recommendation to filter Teredo.

3. This recommendation breaks DNS:

  For this reason, networks attempting to prevent IPv6 traffic from
  traversing their devices should consider configuring their local
  recursive DNS servers to respond to queries for AAAA DNS records with
  a DNS RCODE of 3 (NXDOMAIN) [RFC1035] or to silently ignore such
  queries, and should even consider filtering AAAA records at the
  network ingress point to prevent the internal hosts from attempting
  their own DNS resolution.  This will ensure that hosts which are on
  an IPv4-only network will only receive DNS A records, and they will
  be unlikely to attempt to use (likely broken) IPv6 connectivity to
  reach their desired destinations.

Suppose I do a AAAA query and an A query for a name that has non-AAAA records. Returning NXDOMAIN tels the resolver that there is no such domain name, not that there is no such record. The correct answer in this case is NOERROR, and an answer that contains no records. Silently ignoring these queries is bad advice as well, since it could potentially result in 90 second delays in accessing web pages on dual-stack servers.

Happy Eyeballs is at this point a widely-deployed solution, present in all modern web browsers, so filtering AAAA records to route around brokenness is probably not needed. However, if the working group really has consensus to make a recommendation like this, it should at least do it in a way that doesn't break the DNS.

Proposed action: Delete this paragraph.

Alternative proposed action: specify that when filtering AAAA queries, the filtering entity needs to actually do the query, and then return no records if it receives an answer. This is a fairly easy thing to do on a DNS proxy. Explain why just returning NXDOMAIN or dropping the query will break DNS.

If you go with the alternative proposed action, whatever text you put in should be vetted by the DNS directorate, because I'm just an amateur DNS geek and can't promise that I got the advice exactly right.

[Ballot discuss]
1. This document recommends filtering all IPv6 link-local traffic. Link-local IPv6 traffic is widely used on notionally IPv4-only networks. For example Apple's Bonjour protocol relies on IPv6 link-local addressing. So filtering this traffic would create significant operational problems even in supposedly IPv4-only networks. Bonjour is widely used even by non-Apple devices, including most IP printers and Microsoft Windows printer drivers, so even a non-Apple shop would have a problem with this recommendation.

Proposed action: remove the first paragraph of section 2.1. Remove this text from the next paragraph:

  However,
  neither RA-Guard nor DHCPv6-Shield can mitigate attack vectors that
  employ IPv6 link-local addresses, since configuration of such
  addresses does not rely on Router Advertisement messages or DCHPv6-
  server messages.

Remove this paragraph:

      If native IPv6 traffic is filtered at layer-2, local IPv6 nodes
      would only get to configure IPv6 link-local addresses.

As an alternative, the authors could consider a much more restricted recommendation similar to the first paragraph of 2.1, but referring only to RA traffic and DHCPv6 traffic. This requires a fancier switch, but doesn't break Bonjour.

A much less satisfactory alternative would be to simply say that breaking IPv6 at layer two breaks Bonjour. In combination with a very strong applicability statement (see point 2), I would feel compelled to clear this item in the DISCUSS, even though I would not actually be happy with the outcome.

2. This document makes broad recommendations about filtering tunnel traffic. These recommendations are appropriate in an enterprise environment where IPv6 is not yet deployed, but are inappropriate in most other contexts (e.g., it would be very damaging if ISPs started filtering all tunnel traffic).

Proposed action: This document needs a very clear applicability statement at the top, before it even talks about any sort of recommendation of this type. There is a single sentence in the introduction about applicability, but this isn't sufficient.  I would suggest something like the following:

  Most general-purpose operating systems implement and enable native
  IPv6 [RFC2460] support and a number of transition/co-existence
  technologies by default.  Support of IPv6 by all nodes is intended
  to become best current practice [RFC6540].  Some enterprise
  networks might, however, choose to delay active use of IPv6.

  This document describes operational practices for enterprise networks
  to prevent security exposure resulting from unplanned use of IPv6 on
  such networks. This document is only applicable to enterprise
  networks: networks where the network operator is not providing a
  general-purpose internet, but rather a business-specific network. The
  solutions proposed here are not practical for home networks, nor are
  they appropriate for provider networks such as ISPs, mobile
  providers, Wifi hotspot providers or any other public internet
  service.

  In scenarios in
  which the IPv6-capable devices are deployed on networks that are
  intended to be IPv4-only, native IPv6 support and/or IPv6 transition/
  co-existence technologies could be leveraged by local or remote
  attackers for a number of (illegitimate) purposes.  For example,

Proposed alternative action: Some kinds of tunnel traffic are okay to filter in all environments, because their use is deprecated.  If this document only referred to those types of traffic, this would also satisfy my concern. E.g., I don't think it's a problem to have a blanket recommendation to filter Teredo.

3. This recommendation breaks DNS:

  For this reason, networks attempting to prevent IPv6 traffic from
  traversing their devices should consider configuring their local
  recursive DNS servers to respond to queries for AAAA DNS records with
  a DNS RCODE of 3 (NXDOMAIN) [RFC1035] or to silently ignore such
  queries, and should even consider filtering AAAA records at the
  network ingress point to prevent the internal hosts from attempting
  their own DNS resolution.  This will ensure that hosts which are on
  an IPv4-only network will only receive DNS A records, and they will
  be unlikely to attempt to use (likely broken) IPv6 connectivity to
  reach their desired destinations.

Suppose I do a AAAA query and an A query for a name that has non-AAAA records. Returning NXDOMAIN tels the resolver that there is no such domain name, not that there is no such record. The correct answer in this case is NOERROR, and an answer that contains no records. Silently ignoring these queries is bad advice as well, since it could potentially result in 90 second delays in accessing web pages on dual-stack servers.

Happy Eyeballs is at this point a widely-deployed solution, present in all modern web browsers, so filtering AAAA records to route around brokenness is probably not needed. However, if the working group really has consensus to make a recommendation like this, it should at least do it in a way that doesn't break the DNS.

Proposed action: Delete this paragraph.

Alternative proposed action: specify that when filtering AAAA queries, the filtering entity needs to actually do the query, and then return no records if it receives an answer. This is a fairly easy thing to do on a DNS proxy. Explain why just returning NXDOMAIN or dropping the query will break DNS.

If you go with the alternative proposed action, whatever text you put in should be vetted by the DNS directorate, because I'm just an amateur DNS geek and can't promise that I got the advice exactly right.

[Ballot discuss]
1. This document recommends filtering all IPv6 link-local traffic. Link-local IPv6 traffic is widely used on notionally IPv4-only networks. For example Apple's Bonjour protocol relies on IPv6 link-local addressing. So filtering this traffic would create significant operational problems even in supposedly IPv4-only networks. Bonjour is widely used even by non-Apple devices, including most IP printers and Microsoft Windows printer drivers, so even a non-Apple shop would have a problem with this recommendation.

Proposed action: remove the first paragraph of section 2.1. Remove this text from the next paragraph:

  However,
  neither RA-Guard nor DHCPv6-Shield can mitigate attack vectors that
  employ IPv6 link-local addresses, since configuration of such
  addresses does not rely on Router Advertisement messages or DCHPv6-
  server messages.

Remove this paragraph:

      If native IPv6 traffic is filtered at layer-2, local IPv6 nodes
      would only get to configure IPv6 link-local addresses.

As an alternative, the authors could consider a much more restricted recommendation similar to the first paragraph of 2.1, but referring only to RA traffic and DHCPv6 traffic. This requires a fancier switch, but doesn't break Bonjour.

A much less satisfactory alternative would be to simply say that breaking IPv6 at layer two breaks Bonjour. In combination with a very strong applicability statement (see point 2), I would feel compelled to clear this item in the DISCUSS, even though I would not actually be happy with the outcome.

2. This document makes broad recommendations about filtering tunnel traffic. These recommendations are appropriate in an enterprise environment where IPv6 is not yet deployed, but are inappropriate in most other contexts (e.g., it would be very damaging if ISPs started filtering all tunnel traffic).

Proposed action: This document needs a very clear applicability statement at the top, before it even talks about any sort of recommendation of this type. There is a single sentence in the introduction about applicability, but this isn't sufficient.  I would suggest something like the following:

  Most general-purpose operating systems implement and enable native
  IPv6 [RFC2460] support and a number of transition/co-existence
  technologies by default.  Support of IPv6 by all nodes is intended to
  become best current practice [RFC6540].  Some enterprise networks
  might, however, choose to delay active use of IPv6.

  This document describes operational practices for enterprise networks
  to prevent security exposure resulting from unplanned use of IPv6 on
  such networks. This document is only applicable to enterprise
  networks: networks where the network operator is not providing a
  general-purpose internet, but rather a business-specific network. The
  solutions proposed here are not practical for home networks, nor are
  they appropriate for provider networks such as ISPs, mobile providers,
  Wifi hotspots or any other public internet service.

  In scenarios in
  which the IPv6-capable devices are deployed on networks that are
  intended to be IPv4-only, native IPv6 support and/or IPv6 transition/
  co-existence technologies could be leveraged by local or remote
  attackers for a number of (illegitimate) purposes.  For example,

Proposed alternative action: Some kinds of tunnel traffic are okay to filter in all environments, because their use is deprecated.  If this document only referred to those types of traffic, this would also satisfy my concern. E.g., I don't think it's a problem to have a blanket recommendation to filter Teredo.

3. This recommendation breaks DNS:

  For this reason, networks attempting to prevent IPv6 traffic from
  traversing their devices should consider configuring their local
  recursive DNS servers to respond to queries for AAAA DNS records with
  a DNS RCODE of 3 (NXDOMAIN) [RFC1035] or to silently ignore such
  queries, and should even consider filtering AAAA records at the
  network ingress point to prevent the internal hosts from attempting
  their own DNS resolution.  This will ensure that hosts which are on
  an IPv4-only network will only receive DNS A records, and they will
  be unlikely to attempt to use (likely broken) IPv6 connectivity to
  reach their desired destinations.

Suppose I do a AAAA query and an A query for a name that has non-AAAA records. Returning NXDOMAIN tels the resolver that there is no such domain name, not that there is no such record. The correct answer in this case is NOERROR, and an answer that contains no records. Silently ignoring these queries is bad advice as well, since it could potentially result in 90 second delays in accessing web pages on dual-stack servers.

Happy Eyeballs is at this point a widely-deployed solution, present in all modern web browsers, so filtering AAAA records to route around brokenness is probably not needed. However, if the working group really has consensus to make a recommendation like this, it should at least do it in a way that doesn't break the DNS.

Proposed action: Delete this paragraph.

Alternative proposed action: specify that when filtering AAAA queries, the filtering entity needs to actually do the query, and then return no records if it receives an answer. This is a fairly easy thing to do on a DNS proxy. Explain why just returning NXDOMAIN or dropping the query will break DNS.

If you go with the alternative proposed action, whatever text you put in should be vetted by the DNS directorate, because I'm just an amateur DNS geek and can't promise that I got the advice exactly right.

[Ballot comment]
The buffer overflow referred to in [Core2007] is six years old at the time of review, and is a poor basis for making such a drastic recommendation.

I support Stephen Farrel's DISCUSS relating to DNSSEC, as well as Barry Lieba's comment.

[Ballot comment]
I have issues with this document, but do not see any benefit in arguing for changes.  This document:

- Only discusses approaches that have been well-known for years and have been discussed on numerous IPv6-related mailing lists

- Encourages filtering of nascent/experimental testing of IPv6 in legacy networks rather than encouraging controlled testing/deployment/monitoring of IPv6 traffic

- Engendered only a smattering of positive support in the WG and a large amount of disinterest from the silent majority.

[Ballot comment]
I found the draft interesting to read. However, I wish the draft would be clearer regarding:
1. the security mechanisms that should be in place while waiting for the network to be IPv6-enabled, and then disabled (example: "layer-2 device filtering")
2. versus the measures that must remain in place once the network is IPv6-enabled (RA-Guard [RFC6105])
    Within 2., there are actually two cases
    2.1 when the network is both IPv6 and IPv4 enabled
    2.2 when the network is only IPv6.

It's interesting to note that
- this is just one example. For example, same question for the next section "tunneling mechanisms" (some tunneling mechanisms are not valid any longer in the 2.2 case )
- the two previous examples are from the same section "filtering native IPv6 traffic". Having different sections for the points 1 and 2 may help, or having an introduction with generic security mechanism (point 2), and then, the content of this draft (point 1)

If there are more reviews in that direction, it might be worth seriously considering.

[Ballot comment]
My shakey notes from the roads around the Cliffs of Moher read like this:

----

0) Should we rename this "Filtering IPv6 from IPv4 to avoid some IPv6 Security Issues".

1) I guess there's the recommendation that the same security policy be applied to both IPv4 and IPv6 traffic, but that's really what like 2 paragraphs in the whole draft?

2) Do we REALLY want to recommend filtering IPv6?

----

I think the first and second bits are kind of covered by Stephen's discuss, but maybe we should go a step further in truth in advertising and just title this draft what it's mostly about.

Funny that the 3rd one Jari and Joel discussed while at the IESG retreat last week (not security related but more like unexpected traffic loads) so I know these surprises happen on mixed networks.  But, 'd hate for this kind of recommendation to stick around for a while.  That is when we don't need to be filtering for immature products we ought to get this document gone.

[Ballot discuss]

(1) Only just about a discuss:  The title is overly broad -
are you claiming to have identified *all* security
implications? I doubt that. Truth in advertising would
suggest pre-pending "Some" to the title or perhaps appending
"considered in a bath." Same goes for the abstract.

(2) section 4, 3rd para seems to recommend something that'd
make DNSSEC deployment harder. Even in an informational
document that seems like a bad plan. Why is it ok to
recommend that? Or am I wrong that this practice would make
it harder to start deploying DNSSEC?

[Ballot comment]

- end of section 2: is it really true that the exact same
policies should be enforced for v6 and v4? I guess that
depends on what you call policy - some might consider the use
of NATs and private address space as a policy but that
doesn't seem to be something worth recommending does it? I'm
happy to let the INT or OPSEC folks say this however they
like but as stated this seems overly broad.

- 2.1 - is it really wise to recommend blocking v6 at layer
2? Would that not possibly get hard to turn off when you do
want v6 packets? Seems fragile to me fwiw. I know you don't
strongly recommend that but for things like this where you
point at something it'd be better if you also called out any
significant downsides.

[Ballot comment]
From the shepherd writeup:

  The Document Shepherd has had a number of discussions with the authors on
  this topic, and has followed the progression of the draft through revisions and
  the WG.  The Document Shepherd also sat in the bath with a highlighter and
  carefully reviewed the document.

One can always rely on Warren for a good chuckle....

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03 under
the Evaluation ticket [#668335] on 2013-03-26.  The Evaluation
notification was issued before the Last Call notification.

We understand that, upon approval of this document, there are no IANA
Actions that need completion.

We have received an acknowledgment from Fernando Gont confirming
the above.

The comment is in the tracker.

The following Last Call announcement was sent out:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: <opsec@ietf.org>
Reply-To: ietf@ietf.org
Subject: Last Call: <draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03.txt> (Security Implications of IPv6 on IPv4 Networks) to Informational RFC


The IESG has received a request from the Operational Security
Capabilities for IP Network Infrastructure WG (opsec) to consider the
following document:
- 'Security Implications of IPv6 on IPv4 Networks'
  <draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03.txt> as
Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-04-12. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document discusses the security implications of native IPv6
  support and IPv6 transition/co-existence technologies on "IPv4-only"
  networks, and describes possible mitigations for the aforementioned
  issues.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-implications-on-ipv4-nets/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-implications-on-ipv4-nets/ballot/


No IPR declarations have been submitted directly on this I-D.

S)

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03, which
is currently in IESG Evaluation and has the following comments:

We understand that, upon approval of this document, there are no IANA
Actions that need completion.

If this assessment is not accurate, please respond as soon as possible.

BTW, we did not locate a Last Call request for this document in our
ticketing system.

This starts a working group last call for draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02 -- "Security Implications of IPv6 on IPv4 Networks"

The draft is available at http://tools.ietf.org/html/draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02 and https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-implications-on-ipv4-nets/

Please review this draft to see if you think it is ready for publication. Send comments to the list. 

The WGLC will end on 25th January 2013.