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

Note: This ballot was opened for revision 03 and is now closed.

(Joel Jaeggli) Yes

Comment (2013-12-01 for -06)
No email
send info
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.

(Jari Arkko) No Objection

Comment (2013-05-16 for -04)
No email
send info
I agree with the issues Ted has raised.

(Richard Barnes) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

Comment (2013-05-15 for -04)
No email
send info
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.

(Spencer Dawkins) No Objection

(Adrian Farrel) No Objection

(Stephen Farrell) (was Discuss) No Objection

Comment (2013-12-09)
No email
send info
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.

Barry Leiba No Objection

Comment (2013-05-10 for -04)
No email
send info
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....

(Martin Stiemerling) No Objection

(Sean Turner) No Objection

(Brian Haberman) Abstain

Comment (2013-05-15 for -04)
No email
send info
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.

(Ted Lemon) (was Discuss) Abstain

Comment (2013-11-26 for -06)
No email
send info
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.

(Pete Resnick) Abstain

Comment (2013-05-15 for -04)
No email
send info
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.