Security Implications of IPv6 on IPv4 Networks
draft-ietf-opsec-ipv6-implications-on-ipv4-nets-07

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.

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.

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.