Re: Last Call: <draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03.txt> (Security Implications of IPv6 on IPv4 Networks) to Informational RFC

[Fernando Gont <[e-mail]>]

SM,

On 03/31/2013 06:29 AM, SM wrote:
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final comments on this action. Please send substantive comments to the
>> [e-mail] mailing lists by 2013-04-12. Exceptionally, comments may be
> 
> From Section 6:
> 
>   "In general, the possible mitigations boil down to enforcing on native
>    IPv6 and IPv6 transition/co-existence traffic the same security
>    policies currently enforced for IPv4 traffic, and/or blocking the
>    aforementioned traffic when it is deemed as undesirable."
> 
> My reading of the mitigation is that it comes down to block everything
> IPv6.  The draft seems to treat every network as a military operation
> network.

Please re-read the above paragraph -- you missed the part that says
"...the same security policies".



> In the Section 1:
> 
>   "Native IPv6 support could also possibly lead to VPN traffic leakages
>    when hosts employ VPN software that not only does not support IPv6,
>    but that does nothing about IPv6 traffic.
>    [I-D.ietf-opsec-vpn-leakages] describes this issue, along with
>    possible mitigations."
> 
> I don't understand the relationship between the above and "IPv4-only"
> networks.

Those issues are not present when your network employs v4-only.



> From Section 2:
> 
>  "This means that even if a network is expected to be IPv4-only,
>   much of its infrastructure is nevertheless likely to be
>   IPv6 enabled."
> 
> What is an IPv4-only network?

A network were none of the devices connected to it implement v6.



>   "[CORE2007] is a security advisory about a buffer overflow which
>    could be remotely-exploited by leveraging link-local IPv6
>    connectivity that is enabled by default."
> 
> How is this attack mitigated within the context of the draft?

The reference is meant to illustrate that that even if you think your
network only employs IPv4 (and hence forget about the v6 support), you
could be hit by that.



>   "Additionally, unless appropriate measures are taken, an attacker with
>    access to an 'IPv4-only' local network could impersonate a local
>    router and cause local hosts to enable their 'non-link-local' IPv6
>    connectivity (e.g. by sending Router Advertisement messages),
>    possibly circumventing security controls that were enforced only on
>    IPv4 communications."
> 
> Where is the mitigation for this?

For attacks that employ link-local connectivity, it bolds down to packet
filtering (either by a personal firewall at the host, or by filtering v6
at layer-2) -- this is discussed in the I-D.



> From Section 4:
> 
>   "IPv6 deployments in the Internet are continually increasing"
> 
> I am no longer worried about IPv6 deployment as the OPSEC working group
> has a plan to stop that. :-)
> 
>   'Upstream filtering of transition technologies or situations
>    where a mis-configured node attempts to "provide" native IPv6
>    service on a given network without proper upstream IPv6 connectivity
>    may result in hosts attempting to reach remote nodes via IPv6, and
>    depending on the absence or presence and specific implementation
>    details of "Happy Eyeballs" [RFC6555], there might be a non-trivial
>    timeout period before the host falls back to IPv4 [Huston2010a]
>   [Huston2012].'
> 
> I don't see what "Happy Eyeballs" has to do with operational security.

Happy Eyeballs has to do with what you do when you drop packets. If you
silently drop them, the host may have rely on timeouts rather than
having a positive indication that a packet has been dropped.



>   "For this reason, networks attempting to prevent IPv6 traffic from
>    traversing their devices should consider configuring their local
>    recursive DNS servers to respond to queries for AAAA DNS records with
>    a DNS RCODE of 3 (NXDOMAIN) [RFC1035] or to silently ignore such
>    queries, and should even consider filtering AAAA records at the
>    network ingress point to prevent the internal hosts from attempting
>    their own DNS resolution."
> 
> The above breaks DNS in an attempt to remove everything IPv6 related
> from the network.

Could you please elaborate?



> The title of the draft is "Security Implications of IPv6 on IPv4
> Networks".  The Abstract mentions "IPv4-only" networks.  The
> Introduction Section mentions "networks that are assumed to be
> IPv4-only".

Please see the quotes when we say "'IPv4-only' networks" -- in practice,
there's no such a thing, and you should think v6 security even if you
think/want to run an IPv4-only network.


> I don't understand what this draft is about.

This one I cannot do much about. :-)

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