I've reviewed draft-ietf-opsec-ipv6-implications-on-ipv4-nets. First a comment about your filtering recommendations: I believe that you need to recommend filtering AAAA records and discuss the risk of IPv6 breakage if these security controls are not implemented properly on internet-connected networks. It'd be good for us to make sure that this doesn't become another example of the problems created when an overzealous or incompetent security person filters indiscriminately (e.g. filtering all ICMP because they don't realize that not all ICMP is bad). A large source of IPv6 brokenness today comes from nodes that believe that they have functional IPv6 connectivity, but the path to their destination fails somewhere upstream. Upstream filtering of transition technologies or native IPv6 without also filtering AAAA records may result in end hosts attempting to reach IPv6 hosts, and depending on the absence or presence of happy eyeballs, there may be a non-trivial timeout period before the host falls back to IPv4. Depending on the network and DNS configuration, it may be enough to simply configure the recursive DNS to not answer any AAAA queries (in the case where all DNS is forced to a set of managed servers). If DNS traffic is permitted from other hosts in the network, it may be necessary to examine all port 53 traffic and block AAAAs at the entrance to the network. It may even be appropriate to recommend something like sending resets to any attempts to establish connections to IPv6 hosts. I believe that there are a few networks in Japan that had to do this on their private IPv6 networks to prevent major brokenness as more websites went dual-stack. We have enough major destinations and applications IPv6-enabled that it's important to make it clear how bad of an idea it is to just break IPv6 under the assumption that no one uses it yet anyway.
I also have a concern about the general tone of the document that I believe should be addressed. What I mean is that this document currently treats IPv4-only networks as something that will be relatively commonplace, but assumes that the same network administrators who are un[willing|able] to expend the effort to deploy IPv6 will also be concerned enough about it to worry about its security impacts, even concerned enough to expend energy to disable it or defeat it rather than deploying it and implementing proper security controls or simply forcibly disabling it on the end hosts. I'm not convinced about that choice of audience. 5 years ago, maybe, but not in 2013. I think the document should be stating up front that the primary recommendation for addressing the security considerations of unauthorized use of IPv6 in an IPv4-only network is to deploy IPv6 with proper security controls. This usually results in any transition technologies shutting down in favor of the native connectivity, and even if it doesn't, the act of disabling IPv6 transition technologies will not result in shutting down IPv6 access as noted in my comments above. This also could underscore the point that part of the reason why there may be tunneled IPv6 traffic or other transition technologies in use on the network is *because* there is no official IPv6 support and one or more of the users of the network have decided that IPv6 support is necessary enough to take matters into their own hands. Reiterating a strong recommendation to deploy IPv6 to solve this problem also complements IETF's guidance in RFC6540 (IPv6 is no longer optional) nicely. I think that the last sentence in section 2.1 should probably set the tone for the document - that is, there are going to be legitimate reasons for having IPv4-only networks, and those networks should consider IPv6 when building their security profile because it is enabled by default now, but an IPv4-only network should be the exception rather than the rule. As a result, disabling or otherwise interfering with IPv6 traffic should be a last resort, probably based on the knowledge that this network will *never* support or require IPv6, rather than simply to delay use of IPv6 because the network [administrator] "isn't ready" for IPv6 yet. While I don't think that it's appropriate for IETF to identify specific "legitimate" reasons or use cases for a network remaining IPv4-only, I think we could perhaps pose a few general questions to guide the thought process between whether to deploy IPv6 or disable it as an answer to its potential security risks. Thanks, Wes George ________________________________ This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
_______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
