Hi, Wes,
On 12/18/2012 03:44 PM, George, Wes wrote:
>> 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").
>
> [WEG] I think that perhaps a section on IPv6 brokenness inserted
> before the discussion of the specific filtering options, or at the
> end of the intro might make sense. Something like: "IPv6 deployments
> in the Internet are continually increasing, and some hosts default to
> preferring IPv6 connectivity whenever it is available. This is likely
> to cause IPv6-capable hosts to attempt to reach an ever-increasing
> number of popular destinations via IPv6, even if this IPv6 is via a
> transition technology over an IPv4-only network. 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. [citation to Huston's studies?] Upstream
> filtering of transition technologies or situations where a
> misconfigured node attempts to "provide" native IPv6 service on a
> given network without proper upstream IPv6 connectivity may result in
> end hosts attempting to reach IPv6 hosts, and depending on the
> absence or presence and specific implementation details of happy
> eyeballs [rfc 6555], there may be a non-trivial timeout period before
> the host falls back to IPv4. For this reason, networks attempting to
> prevent IPv6 traffic from traversing their devices SHOULD consider
> configuring their local recursive DNS servers to ignore queries for
> AAAA DNS records, or even consider filtering AAAA records at the
> network ingress point to prevent end hosts from attempting their own
> DNS resolution. This will ensure that end hosts which are on an
> IPv4-only network will only receive DNS A records, and they will be
> unlikely to attempt to use (likely broken) IPv6 connectivity to reach
> their desired destinations. "
*Thanks you*! -- I will incorporate this in the next rev.
>> 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.
>>
> [WEG] you make a valid point that I'm sort of ashamed that I missed,
> and that led to me conflating a couple of things in a way that was
> not helpful. My apologies. *blush*
No worries at all!
>> Please see above. In all these cases, the filtering happens in v4,
>> and not in v6.
>>
> [WEG] Noted. However, you also discuss other security measures that
> are more IPv6-specific, such as ways to block rogue RAs, DHCPv6, etc,
> or even any link-local IPv6 traffic, which is more what I had in mind
> when I mentioned IPv6 security control.
Yes. This is all "enforcing IPv6 security controls on your IPv6
networks" -- there's no other way to mitigate link-local attacks (except
if you filter v6 packets based on the Ethernet Proto field).
> How does one go about
> blocking IPv6 traffic on your network if it doesn't pass the security
> device encapsulated in IPv4, or doesn't pass the security device at
> all because it's local to a LAN?
Filter packets based on the Ethernet Proto field, or enforce layer-2/3
filtering a la RA-Guard/DHCPv6-Shield.
>>> [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.
>
> [WEG] not saying they need to allow it. I'm saying that it exists
> because adherence to security policies is rarely 100%. But the point
> I'm really making here is that if a user has taken it upon themselves
> to make a way to carry IPv6 traffic through a network that doesn't
> yet support it, a good security admin (that is one that doesn't
> simply rule with an iron fist) should probably try to determine why
> this has happened, and whether there might be a legitimate business
> reason for it that might lead to a different decision (eg "we need to
> deploy IPv6") or whether it is the result of an attempt to set up a
> covert channel or other malicious intent.
In my personal experience, most admins generally fall into the "iron
fist" category.. :-) But YMMV...
>> I don't necessarily see v6 as "optional" -- and I certainly do not
>> see as optional in the future.
> [WEG] so I don't understand the resistance to making that statement
> in the document, even if it's only a couple of sentences in the
> intro.
If anything, I was resisting to "the way to mitigate this is to deploy
v6". Something along the lines of what you wrote below ("IPv6
deployments are happening, and this idea of filtering the traffic is a
temporary solution to protect your network until you deploy IPv6") is
perfectly fine to me.
>> 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.
> [WEG] I agree, however, my view is that this is yet one more reason
> that should contribute to the decision to deploy IPv6, rather than
> being evaluated independently from that discussion. I think we agree
> that the message of this document is "IPv6 is here, and it may be on
> your 'IPv4-only' network, you need to consider the security
> implications." What I'm suggesting is that there's an added thing
> which is "IPv6 deployments are happening, and this idea of filtering
> the traffic is a temporary solution to protect your network until you
> deploy IPv6." Perhaps with some qualifier about the fact that some
> networks will have justification to remain IPv4-only for longer than
> others, but this should be the exception rather than the default.
So, have about including something along those lines in the intro. i.e.
"IPv6 deployments are happening, and thus filtering IPv6 traffic to
mitigate IPv6 security implications on IPv4 networks is a temporary
solution to protect your network until you deploy IPv6. In some
exceptional cases (such as e.g. military operations networks), this
approach to mitigating the aforementioned security implications could be
thought of as a longer-term strategy."
(please suggest tweaks if deemed appropriate).
>>> [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.
>>
> [WEG] the fact that the document doesn't include the point I made
> just above and the fact that you're justifying it by citing
> discussion that we shouldn't recommend IPv6 deployment as a solution
> because IPv6 deployment is hard.
Would the above changes address your concerns?
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
