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

[Warren Kumari <[e-mail]>]

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

> 
> On Jan 22, 2013, at 3:17 PM, Warren Kumari <[e-mail]> wrote:
> 
>> 
>> On Jan 10, 2013, at 11:28 AM, Warren Kumari <[e-mail]> wrote:
>> 
>>> 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.
>> 
>> 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…
> 
> 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).

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


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

> 
> W
> 
>> 
>> W
>> 
>>> 
>>> --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?" 
>>> 
>>> 
>>> _______________________________________________
>>> OPSEC mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/opsec
>>> 
>> 
>> --
>> The duke had a mind that ticked like a clock and, like a clock, it regularly went cuckoo.
>> 
>>   -- (Terry Pratchett, Wyrd Sisters)
>> 
>> 
>> _______________________________________________
>> OPSEC mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/opsec
>> 
> 
> --
> "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