Hi, Wes, Thanks so much for your feedback! -- Please find my responses inline....
On 12/13/2012 03:28 PM, George, Wes wrote: > I believe that you need to recommend filtering AAAA records Filtering AAAA records at the organizational recursive DNS server? > and discuss > the risk of IPv6 breakage if these security controls are not implemented > properly on internet-connected networks. Could you please elaborate on what you mean by "IPv6 breakage"? > 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). FWIW, this I-D does not really advocate filtering, but rather argues that "you should do something about this". Filtering is just one of the possible things one might do. > 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. Ok, I see what you mean. I will add a paragraph about this. > 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. Isn't that of sending RSTs like getting into too many details? Or, do you think I should add some text about this? > 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. For all the cases discussed in the document, hosts would not even get to configure an IPv6 address. e.g., if you're filtering 6to4, it's because you're not planning to send legitimate RAs on the local network. In the same way, when we discuss filtering Teredo, the host doesnt get to configure a Teredo address... > 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. This document doesn't take a stance on whether you should deploy v6 or not. There are too many details and factors behind such decision. The document essentially argues "this v6 stuff is running on your network, and you should make an explicit decision on what you want to do with it". > 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. I'm personally not sure whether it's possible for us to make such recommendation, in the sense that for many networks, that's not an option. People is going to deploy v6 if they need it -- not to mitigate it's security implications. e.g., think about a network currently employing [put your favorite security technologies/devices here] that currently do not support v6. They are not going to buy new gear just to address these issues -- most likely, they are going to employ packet filtering. Put another way, being an ops document, I'd personally like to keep it as realistic as possible.... > 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. Well, here we're providing advice to network/security administrators, who are the ones expected to set the policy for their network. In these cases, users do not "decide", but rather comply with the policy set by the security/network admin. > 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 personally think that that would be kind of out of the scope for this document. However, I have no problem to go in that direction if wg agrees to do do. My take is that this is an *op*sec document. And while "you should deploy v6" sounds nice, for many networks that'd be unrealistic. (FWIW, we had a similar discussion at the last IETF meeting, where some folks argued that the way to go to mitigate vpn leakages was to add v6 support to the VPN software, but then it became clear that that was easier said than done -- please take a look at the minutes) > 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. As noted above, I personally think this is going too far. Example: I'm running a network that currently does not support v6. IN that network,I enforce the filtering policies described in this document. I know that sometime in the future I will deploy v6 on this network... at which point I'll remove the current filtering policies. > 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. I personally think that the question of whether to deploy v6 or not is, for the most part, unrelated to this document. You'll deploy v6 if you have reasons to do so. If you have decided to deploy v6, then you'll address v6 security implications by enforcing v6 security controls. OTOH, if for some reason you haver decided not to deploy v6 (yet), then (most likely) you'll address many of the v6 security implications by enforcing packet filtering. FWIW, that's *my* take... I'm all ears for others to weigh in.... Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: [email protected] PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
