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

From: Warren Kumari <[email-masked]>
Date: Thu, 10 Jan 2013 11:28:09 -0500

Hello OpSec!

This starts a working group last call for draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02 -- "Security Implications of IPv6 on IPv4 Networks"

The draft is available at http://tools.ietf.org/html/draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02 and https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-implications-on-ipv4-nets/ 

Please review this draft to see if you think it is ready for publication. Send comments to the list.  

The WGLC will end on 25th January 2013.

--Warren, speaking as OpSec WG co-chair

-- 
I had no shoes and wept.  Then I met a man who had no feet.  So I said, "Hey man, got any shoes you're not using?"

---

From: "George, Wes" <[email-masked]>
Date: Wed, 16 Jan 2013 15:25:03 -0500

All of my concerns with this document have been addressed, and I think it's ready to go.

Thanks,

Wes George

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Warren Kumari
> Sent: Thursday, January 10, 2013 11:28 AM
> To: [email-masked]; opsec chairs
> Cc: Warren Kumari
> Subject: [OPSEC] WGLC on draft-ietf-opsec-ipv6-implications-on-ipv4-
> nets-02
>
> Hello OpSec!
>
> This starts a working group last call for draft-ietf-opsec-ipv6-
> implications-on-ipv4-nets-02 -- "Security Implications of IPv6 on IPv4
> Networks"
>
> The draft is available at http://tools.ietf.org/html/draft-ietf-opsec-
> ipv6-implications-on-ipv4-nets-02 and
> https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-implications-on-
> ipv4-nets/
>
> I had no shoes and wept.  Then I met a man who had no feet.  So I said,
> "Hey man, got any shoes you're not using?"
>
>
> _______________________________________________
> OPSEC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsec

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: Rama Darbha <[email-masked]>
Date: Sun, 20 Jan 2013 13:15:03 -0500

I concur with Wes. After you've put in the concerns he raised, this 
document looks good to publish.

- Rama
> ---------- Forwarded message ----------
> From: *George, Wes* <[email-masked] 
> <mailto:[email-masked]>>
> Date: Wed, Jan 16, 2013 at 3:25 PM
> Subject: Re: [OPSEC] WGLC on 
> draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02
> To: Warren Kumari <[email-masked] <mailto:[email-masked]>>, 
> "[email-masked] <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>, opsec chairs <[email-masked] 
> <mailto:[email-masked]>>
>
>
> > From: [email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked] <mailto:[email-masked]>] On Behalf
> > Of Warren Kumari
> > To: [email-masked] <mailto:[email-masked]>; opsec chairs
> > Cc: Warren Kumari
> > [email-masked] <mailto:[email-masked]>
> 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.
> [email-masked] <mailto:[email-masked]>

-- 
Rama Darbha, CCIE#28006
919-574-5071
[email-masked]
Cisco TAC - Security Solutions
RTP, NC, USA
Hours: 8h30 - 17h00 (EST)

http://www.cisco.com/tac/

---

From: Warren Kumari <[email-masked]>
Date: Tue, 22 Jan 2013 15:17:03 -0500

> The WGLC will end on 25th January 2013.

This is a reminder to please provide feedback on this draft -- so far I do not think we have enough feedback to call consensus.
Thanks to the folk we do have feedback from; Wes, Simon and Rama...

W

--
The duke had a mind that ticked like a clock and, like a clock, it regularly went cuckoo.

    -- (Terry Pratchett, Wyrd Sisters)

---

From: "Smith, Donald" <[email-masked]>
Date: Tue, 22 Jan 2013 23:11:48 +0000

1. 

No mention of v6 aware devices that haven't been configured for v6. One example is acls on most routers have to be duplicated for v6. Firewall rules too. So it isn't just a "can it support issue" but also a is it configured to examine v6 or other tunneled traffic.

Only in some exceptional cases (such as military operations networks)
   could this approach to mitigating the aforementioned security
   implications be thought of as a longer-term strategy.

I am not sure that is true. Some enterprise may very well be able to use just v4 for quite a while especially internally. They might have to offer services on v6 but via some hosting or other DMZ methods they may be able to keep their internal network v4 for many more years.

3.6 
The corresponding addresses can be easily obtained from a UNIX
      host by issuing the command 'dig teredo.ipv6.microsoft.com a'
      (without quotes).

dig isn't a "standard" unix tool. nslookup or host is in nearly all cases but not all unix systems have dig installed by default. (nslookup is deprecated for host but still fairly common if not universal).

How about nslookup since that is also on windows and other platforms?

4.
This:
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 connectivity is provided relies on a transition
   technology over an IPv4-only network.
Should be this:
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 connectivity as provided relies on a transition
   technology over an IPv4-only network.

Shouldn't this be NXD instead of dropping the requests. That way the client can see it is getting errors not just blackholeing the aaaa requests?

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.

That could also be done on a forwarder right not just a local recursive dns server?

A firewall could signal the packet drop by means of an ICMPv6
      error message (or TCP [RFC0793] RST segment if appropriate), such
      that the source node can e.g. quickly react as described in
      [RFC5461].

If there is no v6 connectivity I wouldn't expect icmpv6 to work and the queries will usually be udp so a tcp resest is not valid.

I think therefore that NXD from  dns server or icmpv4 from a middle box is better. And I would change firewall to middle box since there are IPSes, UTM devices, portals etc... that could be dropping the v6 queries.

(coffee != sleep) & (!coffee == sleep)
 [email-masked]

From: [email-masked] [[email-masked]] on behalf of Warren Kumari [[email-masked]]
Sent: Tuesday, January 22, 2013 1:17 PM
To: [email-masked]; opsec chairs
Cc: Warren Kumari
Subject: Re: [OPSEC] WGLC on draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02

W

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Wed, 23 Jan 2013 16:52:50 +0000

After reviewing it again, I think the doc is mostly ready.

I didn't see a question about it before, but would it be worth to also add a section on how to filter AYIYA?

Rgs,
Panos

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Warren Kumari
Sent: Tuesday, January 22, 2013 3:17 PM
To: [email-masked]; opsec chairs
Cc: Warren Kumari
Subject: Re: [OPSEC] WGLC on draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02

W

---

From: Fernando Gont <[email-masked]>
Date: Thu, 24 Jan 2013 01:23:43 -0300

Hi, Panos,

On 01/23/2013 01:52 PM, Panos Kampanakis (pkampana) wrote:
> I didn't see a question about it before, but would it be worth to
> also add a section on how to filter AYIYA?

I've dropped a note to the author of the aforementioned I-D regarding
the status (in terms of standardization and deployment/use) of AYIYA.

If it's still alive, we should add a section about it -- not that I'm
happy to go through the whole
<http://tools.ietf.org/html/draft-massar-v6ops-ayiya-02>, but.... :-)

Thanks!

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

---

From: joel jaeggli <[email-masked]>
Date: Thu, 24 Jan 2013 18:17:08 -0800

I reread this document with an eye towards publication.

generally I think it is good and ready for publication modula the 
comments below which obviously you can take at your discretion or not.

section 1

	Among such controls is the enforcement of
    	filtering policies, such that undesirable traffic is blocked.

is awkward.

	IPv6 supporting security controls  can enforce filtering policy such that undesirable traffic is blocked.

I take issue with the example in this sentence

  	Only
    	in some exceptional cases (such as military operations networks)
    	could this approach to mitigating the aforementioned security
    	implications be thought of as a longer-term strategy.

the people who find that sort of approach necessary know who they are. 
the same applies to a similar stanza in 2.1

the citations in section 2 for toolkits. read like advertising and 
should be detuned accordingly. citing them as examples is fine. if the 
third citation is factually incorrect in some fashion it should be dropped.

       [Waters2011] provides an example of how this could be achieved
       using publicly available tools (besides incorrectly claiming the
       discovery of a "0day vulnerability").

section 3.

    Unless properly managed, tunneling mechanisms might result in
    negative security implications

statement is vague even when followed by the citation.

might result in exposure is more explicit and simpler.

drop "therefore" from the second paragraph

section 3.6

It should be noted  that dig is part of bind or bindutils it is a 
product of ISC and while it comes with lots of unix systems it is not 
generic to them.

---

From: Alec Waters <[email-masked]>
Date: Fri, 25 Jan 2013 10:11:32 +0000

Hi Joel,

> if the third citation is factually incorrect in some fashion it should be dropped.
> 

If the reference is deemed of value to the draft, I (as author of the reference) can reproduce it at another location minus all the 0day nonsense put in there by the "editors" at Infosec Institute.

alec
--

---

From: Fernando Gont <[email-masked]>
Date: Sat, 26 Jan 2013 03:23:25 -0300

Hi, Joel,

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

>        filtering policies, such that undesirable traffic is blocked.

mmm.. what do you mean by "awkward"?

> that undesirable traffic is blocked.

Is this a proposed text to replace the above? Something else?

> the same applies to a similar stanza in 2.1

Are you suggesting that we should remove this paragraph, or something else?

> should be detuned accordingly. citing them as examples is fine.

Please suggest how I could rephrease the text to look better -- the text
is meant to just provide examples of tools that readers can use to play
with this stuff. (FWIW, both toolkits are free software... so nobody is
making money out of them).

> if the

Others have complained about it, already. I personally find the example
valuable -- modulo the reference to it being a 0-day. -- SHould we leave
it in if Alec modifies the text as noted on-list?

> might result in exposure is more explicit and simpler.

Exposure is one factor. They might also help to evade security controls,
might contain bugs with security implications, and might contain
protocol-based vulnerabilities (think Nakibly et al's paper on routing
loops).

> product of ISC and while it comes with lots of unix systems it is not

Should I replace it with something else? host? nslookup?

Thanks so much!

Best regards,

---

From: joel jaeggli <[email-masked]>
Date: Sun, 27 Jan 2013 11:48:59 -0800

> mmm.. what do you mean by "awkward"?
I mean if if you read that sentence alone it doesn't make a lot of 
sense. I suspect a copy editor would ask you to fix it.
> Is this a proposed text to replace the above? Something else?
yes

> Are you suggesting that we should remove this paragraph, or something else?
I'm suggesting that the authors and contributors don't run military 
operations networks so it's speculative, and that the people that do run 
networks that find this necessary won't find the example relatable, it's 
a property of operational requirements, not which industrial vertical 
you happen to be in that drives the requiresments.
> making money out of them).
So if it's not addressed it likely will be an issue for the IESG review.

these simples possible answer would be something like.

1. This is a toolkit, it does foo -->
2. this is also a toolkit, it does foo -->
> it in if Alec modifies the text as noted on-list?
alec's suggestion on the list was fine. a citation that says, this like 
is great except all the parts we dispute or which are just wrong is less 
useful in my book than being able to say foo is a source for bar. if the 
link is sufficiently stable that it's likely to be there a decade from 
now so much the better.
> protocol-based vulnerabilities (think Nakibly et al's paper on routing
right so, you could expand on the implications a bit. the text you wrote 
above it pretty good for example.
> Should I replace it with something else? host? nslookup?
just cite that it's part of bind.

---

From: Fernando Gont <[email-masked]>
Date: Sun, 27 Jan 2013 20:12:17 -0300

> sense. I suspect a copy editor would ask you to fix it.

English as non-native language here, but... what this text is supposed
to mean is "one of the things that you can do is enforce IPv6 filtering,
such that the IPv6-based traffic you don't like is blocked").

Doesn't that sentence convey that information?

>>>      IPv6 supporting security controls  can enforce filtering policy
>>> such
>>> that undesirable traffic is blocked.

If anything, shouldn't it be "IPv6-supporting security controls..."? (or
maybe "IPv6-enabled security controls"..).

> operations networks so it's speculative, 

FWIW, this note was added in response to feedback from folks involved in
military networks.

> and that the people that do run

I couldn't parse tis last sentence... Anyway...  What's your proposed
path to addresss the point you've raised?

FWIW, this note was included because the previous paragraph noted that,
if anything, this should only be considered as a "short-term" strategy.
However, in some networks (in which you only deploy stuff you have no
other option to), this could be a longer-term strategy.

> 2. this is also a toolkit, it does foo -->

I will tweak the I-D as suggested.

> useful in my book than being able to say foo is a source for bar. 

Agreed. But we only had the former.

> link is sufficiently stable that it's likely to be there a decade from

What I can personally offer is to put it on my personal site. I'll wait
and see what Alec has to offer in this respect, anyway.

> above it pretty good for example.

Ok, will do.

> just cite that it's part of bind.

Will do.

Thanks!

Best regards,

---

From: Alec Waters <[email-masked]>
Date: Tue, 29 Jan 2013 15:15:30 +0000

Hi Fernando,

> and see what Alec has to offer in this respect, anyway.

How's this:

http://wirewatcher.wordpress.com/2011/04/04/the-slaac-attack-using-ipv6-as-a-weapon-against-ipv4/

alec
--

---

From: joel jaeggli <[email-masked]>
Date: Tue, 29 Jan 2013 17:35:27 -0800

> http://wirewatcher.wordpress.com/2011/04/04/the-slaac-attack-using-ipv6-as-a-weapon-against-ipv4/
it's excellent.

---

From: Warren Kumari <[email-masked]>
Date: Fri, 25 Jan 2013 09:11:18 -0500

> If the reference is deemed of value to the draft, I (as author of the reference) can reproduce it at another location minus all the 0day nonsense put in there by the "editors" at Infosec Institute.

<no hat>
Personally I think that that would be useful, although another option would be for Fernando to remove the somewhat snide parenthetical…
</no hat>

--
"When it comes to glittering objects, wizards have all the taste and self-control of a deranged magpie."
-- Terry Pratchett

---

From: joel jaeggli <[email-masked]>
Date: Tue, 29 Jan 2013 18:40:21 -0800

> Personally I think that that would be useful, although another option would be for Fernando to remove the somewhat snide parenthetical…
new proposed reference created by alec, cited is more than fine.

---

From: Warren Kumari <[email-masked]>
Date: Wed, 30 Jan 2013 10:04:26 -0500

> Personally I think that that would be useful, although another option would be for Fernando to remove the somewhat snide parenthetical…

Sorry, this was spooled in a mail queue from a while back….

W

--
"Let's just say that if complete and utter chaos was lightning, he'd be the sort to stand on a hilltop in a thunderstorm wearing wet copper armour and shouting 'All gods are bastards'."

    -- Rincewind discussing Twoflower (Terry Pratchett, The Colour of Magic)

---

From: Warren Kumari <[email-masked]>
Date: Thu, 31 Jan 2013 11:36:32 -0500

On Jan 24, 2013, at 11:25 AM, Warren Kumari <[email-masked]> wrote:

> 
> On Jan 22, 2013, at 3:17 PM, Warren Kumari <[email-masked]> wrote:
> 
>> 
>> Thanks to the folk we do have feedback from; Wes, Simon and Rama…
> 
> And another reminder -- we are extending the WGLC to Feb 1st -- but, feel *free* to get your comments in sooner than that!

with no hats…

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. 

W

1.  Introduction

   Most general-purpose operating systems implement and enable by
   default native IPv6 [RFC2460] support and a number of transition/
   co-existence technologies.  In those cases in which the corresponding
   devices are deployed on networks that are assumed to be IPv4-only,
   native IPv6 support and/or IPv6 transition/co-existence technologies
   could be leveraged by local or remote attackers for a number of
   (illegitimate) purposes.  For example,

O: implement and enable by default[...]technologies.
P: implement and enable [...] technologies by default.
C: Readability

O: In those cases
P: For cases 
C: Readability

   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

   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)

   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

         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

   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

   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.

   IPv6 widespread/global IPv6 deployment has been slower than expected,
   it is nevertheless happening, and thus filtering IPv6 traffic
   (whether native or transition/co-existence) to mitigate IPv6 security
   implications on IPv4 networks should only be considered as a
   temporary solution to protect a network until IPv6 is deployed.  Only
   in some exceptional cases (such as military operations networks)
   could this approach to mitigating the aforementioned security
   implications be thought of as a longer-term strategy.

O: happening, and thus filtering
P: happening; and thus, filtering

O: considered as a temporary solution to protect a network until IPv6 is deployed.
P: considered as a temporary measure, until IPv6 is deployed.

Gont & Liu                Expires July 1, 2013                  [Page 3]
Internet-Draft     Sec. Impl. of IPv6 on IPv4 networks     December 2012

   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?

Gont & Liu                Expires July 1, 2013                  [Page 4]
Internet-Draft     Sec. Impl. of IPv6 on IPv4 networks     December 2012

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

   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?

   [I-D.ietf-opsec-vpn-leakages] describes this issue, along with
   possible mitigations.

   In general, networks should enforce on native IPv6 traffic the same
   security policies they currently enforce on IPv4 traffic.  However,
   in those networks in which IPv6 has not yet been deployed, and
   enforcing the aforementioned policies is deemed as unfeasible, a
   network administrator might mitigate IPv6-based attack vectors by
   means of appropriate packet filtering.

O: they currently enforce
P: currently enforced

O: might
P: could

2.1.  Filtering Native IPv6 Traffic

   Some layer-2 devices might have the ability to selectively filter
   packets based on the type of layer-2 payload.  When such

Gont & Liu                Expires July 1, 2013                  [Page 5]
Internet-Draft     Sec. Impl. of IPv6 on IPv4 networks     December 2012

   functionality is available, IPv6 traffic could be blocked at those
   layer-2 devices by blocking e.g.  Ethernet frames with the Protocol
   Type field set to 0x86dd [IANA-ETHER].

O: devices by blocking e.g. 
P: devices by, for example, blocking
C: Readability

   SLAAC-based attacks [RFC3756] can be mitigated with technologies such
   as RA-Guard [RFC6105] [I-D.ietf-v6ops-ra-guard-implementation].  In a
   similar way, DHCPv6-based attacks can be mitigated with technologies
   such as DHCPv6-Shield [I-D.ietf-opsec-dhcpv6-shield].  However,
   neither RA-Guard nor DHCPv6-Shield can mitigate attack vectors that
   employ IPv6 link-local addresses, since configuration of such
   addresses does not rely on Router Advertisement messages or DCHPv6-
   server messages.

   Administrators considering the filtering of native IPv6 traffic at
   layer-3 devices are urged to pay attention to the general
   considerations for IPv6 traffic filtering discussed in Section 4.

      If native IPv6 traffic is filtered at layer-2, local IPv6 nodes
      would only get to configure IPv6 link-local addresses.

   In order to mitigate attacks based on native IPv6 traffic, IPv6
   security controls should be enforced on both IPv4 and IPv6 networks.
   The aforementioned controls might include: deploying IPv6-enabled
   NIDS, implementing IPv6 firewalling, etc.

      In some very specific scenarios (e.g., military operations
      networks) in which only IPv4 service might be desired, a network
      administrator might want to disable IPv6 support in all the
      communicating devices.

Gont & Liu                Expires July 1, 2013                  [Page 6]
Internet-Draft     Sec. Impl. of IPv6 on IPv4 networks     December 2012

3.  Security Implications of Tunneling Mechanisms

   Unless properly managed, tunneling mechanisms might result in
   negative security implications ([RFC6169] describes the security
   implications of tunneling mechanisms in detail).

O: might
P: could

      Of the plethora of tunneling mechanism that have so far been

O: mechanism
P: mechanisms

      standardized and widely implemented, the so-called "automatic
      tunneling" mechanisms (such as Teredo, ISATAP, and 6to4) are of
      particular interest from a security standpoint, since they might
      be employed without prior consent or action of the user or network
      administrator.

   Therefore, tunneling mechanisms should be a concern not only to
   network administrators that have consciously deployed them, but also
   to network and security administrators whose security policies might
   be bypassed by exploiting these mechanisms.

O: , but also [...] mechanisms.
P: , but also to those who have not deployed them, as these mechanisms may bypass their security policies.
C: Original was a bit unclear.

      [CERT2009] contains some examples of how tunnels can be leveraged
      to bypass firewall rules.

   The aforementioned issues could be mitigated by applying the common
   security practice of only allowing traffic deemed as "necessary"
   (i.e., the so-called "default deny" policy).  Thus, when such policy
   is enforced IPv6 transition/co-existence traffic would be blocked by
   default, and would only be allowed as a result of an explicit
   decision (rather than as a result of lack of awareness about such
   traffic).

O: is enforced
P: is enforced,

O: (rather than as a result of lack of awareness about such
   traffic)
P: delete the above
C: redundant; already implied in "explicit."

      It should be noted that this type of policy is usually enforced at
      a network that is the target of such traffic (such as an

O: at a network
P: on a network

      enterprise network).  IPv6 transition traffic should generally
      never be filtered e.g. by an ISP when it is transit traffic.

   In those scenarios in which transition/co-existence traffic is meant
   to be blocked, it is highly recommended that, in addition to the
   enforcement of filtering policies at the organizational perimeter,
   the corresponding transition/co-existence mechanisms be disabled on
   each node connected to the organizational network.  This would not
   only prevent security breaches resulting from accidental use of these
   mechanisms, but would also disable this functionality altogether,
   possibly mitigating vulnerabilities that might be present in the host
   implementation of these transition/co-existence mechanisms.

[ End of nits / comments ] 

> "Have you got any previous convictions?"
> 
> "Well, I dunno... I suppose I used to believe very firmly that a penny saved is a penny earned--"
> -- Terry Pratchett
> 
> 
> 

--
Life is a concentration camp.  You're stuck here and there's no way out and you can only rage impotently against your persecutors.
                -- Woody Allen

---

From: Fernando Gont <[email-masked]>
Date: Fri, 01 Feb 2013 04:02:30 -0300

Hi, Warren,

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

On 01/31/2013 01:36 PM, Warren Kumari wrote:
> 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: 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...

> 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: might P: could

Fixed.

> O: , such that undesirable traffic is blocked. P: to block
> undesirable traffic.

Fixed.

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

> [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), 
> [THC-IPV6] is the first publicly-available toolkit that implemented
> this attack vector (along with many others).
> 
> 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").
> 
> 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,