Internet DRAFT - draft-gont-teredo-loops

draft-gont-teredo-loops






Network Working Group                                            F. Gont
Internet-Draft                                                   UK CPNI
Intended status: Informational                          January 10, 2012
Expires: July 13, 2012


                 Mitigating Teredo Rooting Loop Attacks
                     draft-gont-teredo-loops-00.txt

Abstract

   Recently, a number of routing loop vulnerabilities were discovered in
   the Teredo mechanism, which typically result in a Denial of Service
   of the involved systems, possibly also affecting the intervening
   networks.  This document describes a number of security checks that
   can be performed by Teredo hosts and Teredo servers such that these
   vulnerabilities are eliminated.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on July 13, 2012.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as



Gont                      Expires July 13, 2012                 [Page 1]

Internet-Draft            Teredo routing loops              January 2012


   described in the Simplified BSD License.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Attack vector #1: Teredo Client to NAT  . . . . . . . . . . . . 3
     2.1.  Operational considerations  . . . . . . . . . . . . . . . . 4
     2.2.  Implementation considerations . . . . . . . . . . . . . . . 4
   3.  Attack vector #2: Teredo Server . . . . . . . . . . . . . . . . 4
     3.1.  Operational considerations  . . . . . . . . . . . . . . . . 5
     3.2.  Implementation considerations . . . . . . . . . . . . . . . 5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 7
































Gont                      Expires July 13, 2012                 [Page 2]

Internet-Draft            Teredo routing loops              January 2012


1.  Introduction

   [USENIX-WOOT] describes a number Denial of Service attacks that can
   be performed, in a number of scenarios, against IPv6 automatic
   tunneling mechanisms.  These attacks typically result in a Denial of
   Service of the involved systems, possibly also affecting the
   intervening networks.  One of the affected mechanisms is Teredo
   [RFC4380], an automatic tunneling mechanism which provides "last
   resort" IPv6 connectivity when other technologies cannot be deployed.

   This document discusses the two Teredo routing loop attacks described
   [USENIX-WOOT], and proposes a number of security checks that can be
   performed such that these vulnerabilities are eliminated.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].


2.  Attack vector #1: Teredo Client to NAT

   This attack targets a Teredo client and the NAT(s) through which the
   Teredo client connects to the public Internet.  It assumes that the
   NAT is of type "cone", and that the aforementioned NAT supports hair-
   pin routing with source address translation.

   The attack is initiated by sending a Teredo packet, with its IPv4
   Source Address and its IPv4 Destination Address set to the Teredo
   Mapped Address of the victim Teredo client, and the UDP Source Port
   and the UDP Destination Port set to the Teredo Mapped Port of the
   victim Teredo client.  The IPv6 Source Address and IPv6 Destination
   Address of the encapsulated IPv6 packet are Teredo addresses, with
   their client IPv4 field and their Port field set to the "mapped IPv4
   address" and the obfuscated "mapped UDP port" of the victim Teredo
   client, respectively.  The C (cone) bit of the IPv6 Destination
   Address should be set to "1" (indicating a cone NAT) and the UG bits
   of the same address should be set to "00" (indicating a non-global
   unicast identifier).  The Server IPv4 field and/or the other bits of
   the Flags field of the IPv6 Destination Address should be different
   from that of the victim Teredo client, such that the resulting
   address is not the IPv6 address of the victim Teredo client.

      The idea is that the forged IPv6 Source Address be such that it
      passes the source address validation checks recommended in
      [RFC4380].  The forged IPv6 Destination Address should cause the
      packet to be looped back to the victim Teredo client, but should
      not be the Teredo address of the victim Teredo client (or else the
      packet would be processed by the Teredo client and the loop would



Gont                      Expires July 13, 2012                 [Page 3]

Internet-Draft            Teredo routing loops              January 2012


      not occur).

   Assuming that there already exists a corresponding mapping in the NAT
   (as a result of the Teredo Initial Qualification Procedure), the
   victim Teredo client will receive the forged packet.  [USENIX-WOOT]
   found that in some implementations, if the receiving node is in
   forwarding mode (i.e., it is acting as a router), it will forward the
   encapsulated IPv6 packet over the Teredo tunnel (as the victim Teredo
   client was not the final destination of the packet).  This will
   result in a forwarding loop that will finish only when the Hop Limit
   field of the encapsulated IPv6 packet is decremented to 0, possibly
   leading to a Denial of Service (DoS).

   There are a number of considerations that should be made about this
   attack vector.  Some of these considerations are operational, while
   others have to do with the Teredo implementation at the victim Teredo
   client.

2.1.  Operational considerations

   Firstly, given the deployment model of Teredo, it seems unlikely that
   a node acting as a router would enable Teredo for obtaining its IPv6
   connectivity.  Secondly, enforcement of ingress/egress filtering
   would probably mitigate this attack (although it would not prevent a
   malicious node on the same network as the victim Teredo client from
   launching the attack).

2.2.  Implementation considerations

   Given that Teredo is a mechanism of "last resort" for obtaining IPv6
   connectivity by IPv6 hosts, a node should not forward over the Teredo
   tunnel IPv6 packets that were not originated on the local node, and
   should discard those packets received over the Teredo tunnel that are
   not destined to the Teredo client.  These security checks completely
   eliminate this vulnerability.


3.  Attack vector #2: Teredo Server

   This attack vector engages only one victim, a Teredo server, and
   consists in having the Teredo server send a Teredo bubble destined to
   itself, which will result in a forwarding loop that will continue
   indefinitely.








Gont                      Expires July 13, 2012                 [Page 4]

Internet-Draft            Teredo routing loops              January 2012


      As the Teredo server decapsulates the bubble packet (an empty IPv6
      datagram) and re-encapsulates it in another IPv4 packet before
      forwarding it, there is no mechanism to limit the number of times
      a bubble packet is "forwarded".

   The attack consists in sending a forged "Teredo bubble" with the IPv4
   Source Address and the IPv4 Destination Address both set to the IPv4
   address of the victim Teredo server, and the UDP Source Port and the
   UDP Destination Port both set to the Teredo UDP Port (3544).  The
   IPv6 Source Address and the IPv6 Destination Address of the
   encapsulated IPv6 packet should have their client IPv4 field set to
   the obfuscated IPv4 address of the victim Teredo server, and the
   their Port field set to the obfuscated Teredo UDP port (3544).  The
   Server IPv4 field and the Flags field can be set to any value.

      The idea is that the IPv6 Source Address must be such that the
      forged Teredo packet will pass the source address validation
      checks described in [RFC4380].  The IPv6 Destination Address must
      be such that the forged Teredo bubble is re-sent by the victim
      Teredo server to its own IPv4 address and Teredo UDP Port.

   There are a number of considerations that should be made about this
   attack vector.  Some of these considerations are operational, while
   others have to do with the Teredo implementation at the victim Teredo
   client.

3.1.  Operational considerations

   Implementation of ingress/egress filtering would probably mitigate
   this attack.  However, ingress/egress filtering should not be relied
   upon as the "first line of defense".

3.2.  Implementation considerations

   In order for this attack to succeed, a Teredo server must be willing
   to accept a Teredo packet that contains its own address in the IPv4
   Source Address field, and accept the Source Address and the
   Destination Address of the encapsulated IPv6 packet to embed its own
   (obfuscated) address in the "client IPv4" field.  There are no
   legitimate reasons for a Teredo packet to contain such values.
   Therefore, this vulnerability could be eliminated by having Teredo
   servers silently discard such Teredo packets.

   Teredo servers should discard Teredo packets that have an IPv4 Source
   Address equal to one of the receiving server's IPv4 addresses, and
   should discard Teredo packets that embed the (obfuscated) IPv4
   address of the receiving server in the "client IPv4" field of the
   Source Address or the Destination Address of the encapsulated IPv6



Gont                      Expires July 13, 2012                 [Page 5]

Internet-Draft            Teredo routing loops              January 2012


   packet.


4.  Security Considerations

   The routing-loop vulnerabilities discussed in this document typically
   lead to a Denial of Service (DoS) of the target systems, thus
   resulting in a consequent Denial of Service of those hosts being
   serviced by the aforementioned systems.  If the amount of traffic
   resulting from the aforementioned attacks is large enough, it may
   negatively affect the intervening networks, possibly resulting in a
   large-scale Denial of Service.

   This document describes a number of security checks that can be
   performed by Teredo hosts and Teredo servers such that the
   aforementioned vulnerabilities are completely eliminated.


5.  IANA Considerations

   This document has no actions for IANA.


6.  Acknowledgements

   The routing loop attacks against Teredo discussed in this document
   were discovered by Gabi Nakibly and Michael Arov, and documented in
   [USENIX-WOOT].

   This document is heavily based on the upcoming document "Security
   Implications of the Internet Protocol version 6 (IPv6)" [CPNI-IPv6].

   Fernando Gont would like to thank CPNI (http://www.cpni.gov.uk) for
   their continued support.


7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4380]  Huitema, C., "Teredo: Tunneling IPv6 over UDP through
              Network Address Translations (NATs)", RFC 4380,
              February 2006.





Gont                      Expires July 13, 2012                 [Page 6]

Internet-Draft            Teredo routing loops              January 2012


7.2.  Informative References

   [CPNI-IPv6]
              Gont, F., "Security Assessment of the Internet Protocol
              version 6 (IPv6)",  UK Centre for the Protection of
              National Infrastructure, (available on request).

   [USENIX-WOOT]
              Nakibly, G. and M. Arov, "Routing Loop Attacks using IPv6
              Tunnels",  USENIX WOOT, 2009.


Author's Address

   Fernando Gont
   UK Centre for the Protection of National Infrastructure

   Email: fernando@gont.com.ar
   URI:   http://www.cpni.gov.uk
































Gont                      Expires July 13, 2012                 [Page 7]