> From: Fernando Gont [mailto:[email protected]] > > Filtering AAAA records at the organizational recursive DNS server? > > [WEG] yes, to ensure that even if an end client thinks it has IPv6 connectivity, and the network is actively working to filter/disable IPv6, this will ensure that the client doesn't receive responses for AAAA queries and attempt to connect to an IPv6 host.
> > > 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? [WEG] The only reason I mention it is that AFAIK it's deployed in an operational network as a means to prevent IPv6 brokenness because while IPv6 is present and in use, it's not actually connected to the IPv6 Internet. In a network where there is no IPv6 at all, it ends up being a "belt and suspenders" approach that catches the cases where an end host attempts to connect to an IPv6 host using an IPv6 literal instead of a DNS AAAA response. Do I think those are particularly common? No, and I think that most times if you're trying to use an IPv6 literal, you'll know when it doesn't work that you need to try IPv4. I just raised the issue for completeness, and I'd be interested in others feedback on whether it's important to include. > > > 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... [WEG] I'm not sure I understand your rationale here. There is nothing that prevents an end host from configuring a 6to4 address (eg 2002::[foo]) and attempting to send packets to the IPv4 6to4 anycast gateway. From the host's perspective, that is a functional IPv6 connection. Only if the host has something implemented to validate the connectivity before attempting to use it will it realize that it's faulty if/when the 6to4 packets are being filtered upstream. Likewise, teredo has a little better behavior in that it is supposed to make checks for connectivity to the teredo server before assuming that it's functional. Similarly, a locally-defined 6in4 tunnel may not include connectivity verification. While many implementations have either depreferenced these technologies for all but forced IPv6 connections (attempts to connect to a literal, for example), or have started using something like Happy Eyeballs to detect brokenness and fall back to IPv4 quicker, not all have. The poi nt is that there are many ways to implement broken IPv6 connectivity with the use of these transition technologies, and filtering often makes that brokenness more likely. > > > 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". [WEG] I'm not proposing that this document get into the specific details and factors behind a decision to deploy IPv6. What I am proposing is that it make the generic statement that absent a reason to the contrary, the path forward should be to deploy IPv6, rather than making it seem like this recommendation is a suitable indefinite solution for a network that doesn't technically *need* to remain IPv4-only. > > > > 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. [WEG] Yes, except that for the same reason, they may not be able to implement packet filtering for IPv6 traffic because their current [security widget] doesn't know what an IPv6 packet is. My view has always been that the recommendation should be somewhat like the way that building codes read - if you don't touch it, you aren't required to update things to comply with current building code, only the one in force when construction was done. But if you tear open the wall, you have to bring anything that is exposed up to current building code. Unless the security person views IPv6 as a real threat enough to justify upgrading hardware to support proper IPv6 security controls, the more likely thing is that it will just be ignored. If they're going to the trouble of purchasing hardware that supports IPv6 for filtering, why not go the rest of the way? There may be legitimate reasons not to, but that line of logic should be discussed here. > > Put another way, being an ops document, I'd personally like to keep it > as realistic as possible.... > > > 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. [WEG] now who's talking about keeping an ops document as realistic as possible? ;-) Seriously, except in some of the most draconian of user environments (where network security violations are a zero-tolerance termination offense and 100% of devices on the network are centrally managed/locked down against unauthorized changes or both), I think that it's unrealistic to assume that there are no users "deciding" that the security/network admin's policy either doesn't apply to them or is otherwise stupid and "deciding" to find a way to circumvent it. This is the classic tussle between ensuring proper security and making it so onerous to the userbase that it is defeated so that they can get work done. If IPv6 traffic is detected on a network that does not have IPv6 deployed yet, it's either a misconfigured host trying to do something automatically, or it's a host purposely configured to attempt some sort of IPv6 connectivity. There's value in discussing how to determine one vs the other, because that may also lead to a course of action (e.g. push an update to disable the automatic/misconfiguration vs setting up filtering to prevent purposeful attempts to force IPv6 traffic through). > > > > 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. [WEG] I'm not recommending it be a major focus. There are plenty of IPv6 evangelism drafts already. I'm mainly suggesting that it be discussed briefly to round out the recommendations of the draft. > > 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. [WEG] While I agree that it's unlikely that a security person reviewing this document will have this sudden epiphany where they slap themselves on the forehead and say "right, I should be deploying IPv6!" and run to convince everyone else of this, I'm mainly looking for a consistent message when it comes to getting away from the notion that IPv6 is going to remain optional indefinitely for generic cases. There are exceptions to every rule, but the message we should be sending is that IPv6 is here, it's not going away, and therefore you should be making a conscious decision to deploy or justify delaying deployment based on your own circumstances, but the default answer should be deploy. That's why I made reference to 6540. > > (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) [WEG] I'll have a look, but at some point the "math is hard, let's go shopping" [1] justification for delaying IPv6 deployment really stops being relevant, and I think we do a disservice to those reviewing documents like this to make it seem like that's really an option to consider indefinitely. As I said above, either the potential security risk presented by "rogue" IPv6 deployments in the presence of software and hardware that doesn't fully support them is big enough to justify spending time and money to fix it, or it is a small enough risk to be safely ignored until the legacy software/hardware ages out on its own. Thanks Wes George [1] http://itre.cis.upenn.edu/~myl/languagelog/archives/002919.html 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
