> 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.
>
> 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 r
eason, 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. "
>
> 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*
>
>
> 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. 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? So I think the choice
becomes either find a way with your existing IPv4-only devices to block *all*
IPv6 traffic within your LANs, upgrade at least some of them to recognize and
block local IPv6 traffic (along with any upstream blocking of encapsualated
v6), or acknowledge that you may still have local IPv6 traffic on the network,
and the potential security risk that may present (a compromised machine can
trigger IPv6 exploits on other machines in the network, etc).
>
> > >>
> > [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.
>
> >
> 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.
>
> 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.
>
> > [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.
Wes George
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
