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: [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
