Subject: [OPSEC] Security Implications of IPv6 on IPv4 Networks

From: "George, Wes" <[email-masked]>
Date: Thu, 13 Dec 2012 13:28:24 -0500

I've reviewed draft-ietf-opsec-ipv6-implications-on-ipv4-nets.

First a comment about your filtering recommendations:
I believe that you need to recommend filtering AAAA records and discuss the risk of IPv6 breakage if these security controls are not implemented properly on internet-connected networks. It'd be good for us to make sure that this doesn't become another example of the problems created when an overzealous or incompetent security person filters indiscriminately (e.g. filtering all ICMP because they don't realize that not all ICMP is bad). 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. Upstream filtering of transition technologies or native IPv6 without also filtering AAAA records may result in end hosts attempting to reach IPv6 hosts, and depending on the absence or presence of happy eyeballs, there may be a non-trivial timeout period before the host falls back to IPv4. 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. I believe that there are a few networks in Japan that had to do this on their private IPv6 networks to prevent major brokenness as more websites went dual-stack. 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.

I also have a concern about the general tone of the document that I believe should be addressed.
What I mean is that this document currently treats IPv4-only networks as something that will be relatively commonplace, but assumes that the same network administrators who are un[willing|able] to expend the effort to deploy IPv6 will also be concerned enough about it to worry about its security impacts, even concerned enough to expend energy to disable it or defeat it rather than deploying it and implementing proper security controls or simply forcibly disabling it on the end hosts. I'm not convinced about that choice of audience. 5 years ago, maybe, but not in 2013.

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. This usually results in any transition technologies shutting down in favor of the native connectivity, and even if it doesn't, the act of disabling IPv6 transition technologies will not result in shutting down IPv6 access as noted in my comments above. 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. 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 think that the last sentence in section 2.1 should probably set the tone for the document - that is, there are going to be legitimate reasons for having IPv4-only networks, and those networks should consider IPv6 when building their security profile because it is enabled by default now, but an IPv4-only network should be the exception rather than the rule. As a result, disabling or otherwise interfering with IPv6 traffic should be a last resort, probably based on the knowledge that this network will *never* support or require IPv6, rather than simply to delay use of IPv6 because the network [administrator] "isn't ready" for IPv6 yet. While I don't think that it's appropriate for IETF to identify specific "legitimate" reasons or use cases for a network remaining IPv4-only, I think we could perhaps pose a few general questions to guide the thought process between whether to deploy IPv6 or disable it as an answer to its potential security risks.

Thanks,

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.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 17 Dec 2012 13:03:09 -0300

Hi, Wes,

Thanks so much for your feedback! -- Please find my responses inline....

On 12/13/2012 03:28 PM, George, Wes wrote:
> I believe that you need to recommend filtering AAAA records 

Filtering AAAA records at the organizational recursive DNS server?

> and discuss
> the risk of IPv6 breakage if these security controls are not implemented
> properly on internet-connected networks. 

Could you please elaborate on what you mean by "IPv6 breakage"?

> It’d be good for us to make
> sure that this doesn’t become another example of the problems created
> when an overzealous or incompetent security person filters
> indiscriminately (e.g. filtering all ICMP because they don’t realize
> that not all ICMP is bad). 

FWIW, this I-D does not really advocate filtering, but rather argues
that "you should do something about this". Filtering is just one of the
possible things one might do.

> 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. Upstream
> filtering of transition technologies or native IPv6 without also
> filtering AAAA records may result in end hosts attempting to reach IPv6
> hosts, and depending on the absence or presence of happy eyeballs, there
> may be a non-trivial timeout period before the host falls back to IPv4.

Ok, I see what you mean. I will add a paragraph about this.

> 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?

> I
> believe that there are a few networks in Japan that had to do this on
> their private IPv6 networks to prevent major brokenness as more websites
> went dual-stack. 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...

> What I mean is that this document currently treats IPv4-only networks as
> something that will be relatively commonplace, but assumes that the same
> network administrators who are un[willing|able] to expend the effort to
> deploy IPv6 will also be concerned enough about it to worry about its
> security impacts, even concerned enough to expend energy to disable it
> or defeat it rather than deploying it and implementing proper security
> controls or simply forcibly disabling it on the end hosts. I’m not
> convinced about that choice of audience. 5 years ago, maybe, but not in
> 2013.

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".

> 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.

Put another way, being an ops document, I'd personally like to keep it
as realistic as possible....

> This usually results in any transition
> technologies shutting down in favor of the native connectivity, and even
> if it doesn’t, the act of disabling IPv6 transition technologies will
> not result in shutting down IPv6 access as noted in my comments above.
> 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.

> 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.

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.

(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)

> I think that the last sentence in section 2.1 should probably set the
> tone for the document – that is, there are going to be legitimate
> reasons for having IPv4-only networks, and those networks should
> consider IPv6 when building their security profile because it is enabled
> by default now, but an IPv4-only network should be the exception rather
> than the rule. As a result, disabling or otherwise interfering with IPv6
> traffic should be a last resort, probably based on the knowledge that
> this network will **never** support or require IPv6, rather than simply
> to delay use of IPv6 because the network [administrator] “isn’t ready”
> for IPv6 yet. 

As noted above, I personally think this is going too far.

Example: I'm running a network that currently does not support v6. IN
that network,I enforce the filtering policies described in this
document. I know that sometime in the future I will deploy v6 on this
network... at which point I'll remove the current filtering policies.

> While I don’t think that it’s appropriate for IETF to
> identify specific “legitimate” reasons or use cases for a network
> remaining IPv4-only, I think we could perhaps pose a few general
> questions to guide the thought process between whether to deploy IPv6 or
> disable it as an answer to its potential security risks.

I personally think that the question of whether to deploy v6 or not is,
for the most part, unrelated to this document. You'll deploy v6 if you
have reasons to do so. If you have decided to deploy v6, then you'll
address v6 security implications by enforcing v6 security controls.
OTOH, if for some reason you haver decided not to deploy v6 (yet), then
(most likely) you'll address many of the v6 security implications by
enforcing packet filtering.

FWIW, that's *my* take... I'm all ears for others to weigh in....

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: "George, Wes" <[email-masked]>
Date: Mon, 17 Dec 2012 17:29:29 -0500

> From: Fernando Gont [mailto:[email-masked]]
>
[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.

> > 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.
>
[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.
>
[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 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.
> and you should make an explicit decision on what you want to do with
[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.
> > unauthorized use of IPv6 in an IPv4-only network is to deploy IPv6
> > with proper security controls.
>

[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.
> > 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.
>
[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).
> > complements IETF's guidance in RFC6540 (IPv6 is no longer optional)
> nicely.
>
[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.
> 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.
> 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

---

From: Simon Eng <[email-masked]>
Date: Tue, 18 Dec 2012 09:28:58 +0800

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-masked]>wrote:

> [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.
>
> >
> [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.
> >
> [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.
> >
> >
> [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.
> >
> >
> [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.
> >
> 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
> [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.
> >
> [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.
> >
> [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
>
> 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-masked]
> https://www.ietf.org/mailman/listinfo/opsec
>

---

From: Fernando Gont <[email-masked]>
Date: Mon, 17 Dec 2012 23:51:10 -0300

On 12/17/2012 07:29 PM, George, Wes wrote:
> 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?
> 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.

>>> unauthorized use of IPv6 in an IPv4-only network is to deploy
>>> IPv6 with proper security controls.
>> 
>> option. People is going to deploy v6 if they need it -- not to
>> mitigate it's security implications.
>> 
>> 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.
> 
> 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....

> [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)
> 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,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 17 Dec 2012 23:56:37 -0300

Hi, Simon,

Thanks so much for your feedback! Please find my comments inline....

On 12/17/2012 10:28 PM, Simon Eng wrote:
> Hence, from Wes's suggestion, DNS filtering should be added (maybe
> Section 3??).

Wes's suggestions seems to be to do DNS AAAA filtering *when* you do
native/transition traffic filtering...

> 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??

Yep. This should probaly be added to the intro -- if it's not already
there....

> In Section 2, only DHCPv6 & RA are mentioned.  I'd like to suggest

You mean ICMPv6 errors, or what?

Thanks!

Best regards,

---

From: Simon Eng <[email-masked]>
Date: Tue, 18 Dec 2012 11:44:35 +0800

Hi,

Pls see my comments as below:

a)  Yes, maybe DNS AAAA filtering can be mentioned in a separate new
section.

b) No, I do not mean ICMPv6 errors only, but all ICMPv6 messages (which
should not be there in IPv4-only network right??).  So a Network IDS/IPS
can filter/block ICMPv6 traffic (similar to RA guard, detect-block DHCPv6,
etc).

I am not sure if this works. But suppose a malicious host knows a Dual
Stack Host MAC address via ARP, can it uses ICMPv6 Neigh Solicit/Discovery
to trick Dual Stack Host to connect/route IPv6 packets to it, which in turn
can do a NAT64 send out to outside world?

[Dual stack]<--IPv6-->[Malicious Host doing NAT64, DNS64,
etc]<--IPv4-->[IPv4 only router]<-->(Outside world)

If I am not wrong, most IETF suggestions are to try IPv6 first, then fall
back to IPv4 (e.g. behaviour of DNS64?? Try AAAA then A??).  Hence, in IPv4
only network, ICMPv6 (using ARP info) can be used for Man-In-Middle??

---

From: Fernando Gont <[email-masked]>
Date: Tue, 18 Dec 2012 04:00:01 -0300

Hi, Simon,

> a)  Yes, maybe DNS AAAA filtering can be mentioned in a separate new

My take is that this kind of filtering is meant t complement the kind of
filtering already discussed in the document. In such case, the
corresponding text shuld be added to some of the existing section(s).

> can filter/block ICMPv6 traffic (similar to RA guard, detect-block
> DHCPv6, etc).

The discussion of RA-Guard and DHCPv6-Shield is meant to prevent an
attacker from successfully triggerring v6-conectivity at the target
hosts, and is a layer-2 filtering.

For other packets, you proaby simply ant to filter IPv6 packets , with
such a coarse granularity.

> Stack Host MAC address via ARP, can it uses ICMPv6 Neigh
> Solicit/Discovery to trick Dual Stack Host to connect/route IPv6 packets
> to it, which in turn can do a NAT64 send out to outside world?  

Except for linklocl traffi, this shoudl be performed in conjunction with
other attacks 7e.g., forging RAs).

> If I am not wrong, most IETF suggestions are to try IPv6 first, then
> fall back to IPv4 (e.g. behaviour of DNS64?? Try AAAA then A??).  Hence,
> in IPv4 only network, ICMPv6 (using ARP info) can be used for
> Man-In-Middle?? 

Yes. Although that implies you already have some v6 connectivity.

Thanks!

Cheers,

---

From: "George, Wes" <[email-masked]>
Date: Tue, 18 Dec 2012 13:44:02 -0500

> 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. "

> -- 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
[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).
> 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.
> 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.
> happen as a result of something else, and not just to address these
[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.
> because that's not my idea, and not what I wanted to reflect in the
[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

---

From: Fernando Gont <[email-masked]>
Date: Tue, 18 Dec 2012 17:31:22 -0300

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,

---

From: "George, Wes" <[email-masked]>
Date: Wed, 19 Dec 2012 08:32:04 -0500

> Sent: Tuesday, December 18, 2012 3:31 PM

> >> should) happen as a result of something else, and not just to address
> >> these issues.

[WEG] yes, thanks a lot

Wes George