On 12/17/2012 07:29 PM, George, Wes wrote:
>> 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.
Should I include some text in the Intro (only), or should I include a
note in each of the filtering sections ("If you filter these packets,
you should probably also filter the corresponding AAAA records").
>>> 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.
It might make sense to add a note about this - although I recall that at
least some version of Windows would keep resending the SYN even in the
presence of an RST. -- i.e., the RST would not cause Windows to try "the
next address in the list" - this might have changed nowadays, though.
>>> 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.
You're right -- I should have said "in all cases, modulo, 6to4...."
> that it's functional. Similarly, a locally-defined 6in4 tunnel may
> not include connectivity verification. While many implementations
IMO, 6in4 is less of an issue, since it's manually configured. At which
point, you're assumed to know what you're doing....
> 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 point 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.
I think you've raised a valid point. Please do let me know where (which
sections) you think should include some words on the subject... and I'll
come back with a proposed next-rev.
>> 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.
Me, I never thought about filtering about an "indefinite solution".
As noted in my previous email, my take is that networks will address
these issues by "enforcing IPv6 security controls" only if they have
already deployed v6 for some *other* reason. I don't think anyone would
deploy v6 just for this.
>>> 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.
Well, for all these cases, the filtering happens in v4, rather than v6
-- e.g., filter ip proto 41, or the Teredo IPv4-based UDP ports, etc.
> 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?
Please see above. In all these cases, the filtering happens in v4, and
not in v6.
>>> 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.
>From the security admin pov, that's an attack -- hence the admin doesn't
need to allow such traffic.
> 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.
If you're enforcing v4 controls in your network, but do not enforce any
v6 controls, you probably don't want the v6 traffic there...
>>> 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.
I'd like others to weigh in. Me, I just want to avoid v6-evangelism here....
>> 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.
I don't necessarily see v6 as "optional" -- and I certainly do not see
as optional in the future.
That said when faced with these security implications, you've already
deployed v6 (and should therefore enforce v6 security controls), or
you're probably going to go the packet-filtering way.
My take is that the decision about whether to deploy v6 is (and should)
happen as a result of something else, and not just to address these issues.
>> (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.
Is there anything (in particular) that gives you such idea? -- I ask
because that's not my idea, and not what I wanted to reflect in the
document.
> 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.
Well, it doesn't need to be "black or white". As noted above, simple
v4-based packet filtering can mitigate many of these issues...
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
