Hi, If I am not wrong, the 3 key parts for draft-ietf-opsec-ipv6-implications-on-ipv4-nets-01 are:
Section 1 Introduction/Problem Statement Section 2 Filtering Native IPv6 Section 3 Filtering Transition Hence, from Wes's suggestion, DNS filtering should be added (maybe Section 3??). Another scenario to consider for DNS is a malicious host on the IPv4 network acting as an IPv6 Router-cum-DNS64 => spoof DNS AAAA replies so that dual-stack hosts will route IPv6 traffic to malicious host => Man-In-Middle attack?? In Section 2, only DHCPv6 & RA are mentioned. I'd like to suggest filtering of ICMPv6 too. Regards. Simon On Tue, Dec 18, 2012 at 6:29 AM, George, Wes <[email protected]>wrote: > > > 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 >
_______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
