Re: [OPSEC] WGLC on draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02

[Fernando Gont <[e-mail]>]

Hi, Warren,

Thanks so much for your feedback! -- Please find my comments in-line...

On 01/31/2013 01:36 PM, Warren Kumari wrote:
> And hare are a chunk more comments. These are just nits / readability
> bits…
> 
> On a slightly more substantive note, I also think that the reference
> to military networks is unneeded / not helpful.

The only reason for which it was added is because the text just
preceding it essentially claims that "blocking transition technologies
should only be considered a short-term strategy" (but that doesn't hold
true for some networks).

To be honest, I wouldn't waste anyone's energy on this one :-), and
could just remove such note if the wg thinks that's the best way
forward. (As a matter of personal taste, I'd remove any wording of
short-term vs. longer-term strategies, or note in which cases (such as
military networks) blocking this stuff might be seen as a longer term
thing).

Input is certainly welcome!


[I've removed all the readability bits that I'll apply "as suggested"]
> o  A Network Intrusion Detection System (NIDS) might be prepared to 
> detect attack patterns for IPv4 traffic, but might be unable to 
> detect the same attack patterns when a transition/co-existence 
> technology is leveraged for that purpose.
> 
> O: might be prepared [...] might be unable P: may be prepared [...]
> but may not be able

Some native-English-speaking folk advised me to phrase the text as
suggested, noting that "may" implies "permission", rather than
"probability" (FWIW, I studied this a looong time :-) ago, and I'm not
sure I could tell the difference).



> o  An IPv4 firewall might enforce a specific security policy in
> IPv4, but might be unable to enforce the same policy in IPv6.
> 
> O: might (twice) P: may (twice)

Same as above -- please double-check...



> o  Some transition/co-existence mechanisms might cause an internal 
> host with otherwise limited IPv4 connectivity to become globally 
> reachable over IPv6, therefore resulting in increased (and possibly
> unexpected) host exposure.
> 
> O: might P: could

Fixed.



> Some transition/co-existence mechanisms (notably Teredo) are designed
> to traverse Network Address Port Translation (NAPT) [RFC2663]
> devices, allowing incoming IPv6 connections from the Internet to
> hosts behind the organizational firewall or NAPT (which in many
> deployments provides a minimum level of protection by only allowing
> those instances of communication that have been initiated from the
> internal network).
> 
> O:  or NAPT (which in many deployments P: or NAPT. (In many
> deployments, this

Is it okay to have a full sentece within parenthesis?



> o  IPv6 support might, either inadvertently or as a result of a 
> deliberate attack, result in VPN traffic leaks if IPv6-unaware 
> Virtual Private Network (VPN) software is employed by dual-stacked 
> hosts [I-D.ietf-opsec-vpn-leakages].
> 
> O: might P: could

Fixed.



> In general, most of the aforementioned security implications can be 
> mitigated by enforcing security controls on native IPv6 traffic and 
> on IPv4-tunneled traffic.  Among such controls is the enforcement of 
> filtering policies, such that undesirable traffic is blocked. While
> 
> O: , such that undesirable traffic is blocked. P: to block
> undesirable traffic.

Fixed.



> This document discusses the security implications of IPv6 and IPv6 
> transition/co-existence technologies on (allegedly) IPv4-only 
> networks, and provides guidance on how to mitigate the
> aforementioned issues.
> 
> O: This document discusses the security implications of IPv6 and
> IPv6 transition/co-existence technologies on (allegedly) IPv4-only 
> networks, and provides guidance on how to mitigate the
> aforementioned issues. P: Delete above paragraph C: Already in the
> abstract; not sure why it is here as well?

Common practice of producing the abstract from the Intro? :-)



> 2.  Security Implications of Native IPv6 Support
> 
> Most popular operating systems include IPv6 support that is enabled 
> by default.  This means that even if a network is expected to be 
> IPv4-only, much of its infrastructure is nevertheless likely to be 
> IPv6 enabled.  For example, hosts are likely to have at least link- 
> local IPv6 connectivity which might be exploited by attackers with 
> access to the local network.
> 
> [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.
> 
> 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.
> 
> [THC-IPV6] is the first publicly-available toolkit that implemented
> this attack vector (along with many others).
> 
> [IPv6-Toolkit] is a fully-featured trouble-shooting and security 
> assessment tool that implements this attack vector (along with many
> others).
> 
> [Waters2011] provides an example of how this could be achieved using
> publicly available tools (besides incorrectly claiming the discovery
> of a "0day vulnerability").
> 
> 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.
> 
> O: about IPv6 traffic. P: with IPv6 traffic, instead allowing that to
> bypass the VPN. C: Not sure if this is what is meant?

What I meant is that is not just that they cannot tunnel v6 traffic, but
that they also don't even bother to block it.

Should we s/about/with/, or keep it "as is"?

Thanks so much!

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