[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 07 08 09 10 RFC 5991

IPv6 Operations Working Group                                S. Krishnan
Internet-Draft                                                  Ericsson
Expires: May 19, 2008                                        J. Hoagland
                                                                Symantec
                                                       November 16, 2007


                        Teredo Security Updates
                 draft-krishnan-v6ops-teredo-update-01

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on May 19, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   Additional security concerns with Teredo are documented, beyond what
   is in RFC 4380.  This is based on an independent analysis of Teredo's
   security implications.  The primary intent of this document is to
   describe the updates required to update the Teredo specification.






Krishnan & Hoagland       Expires May 19, 2008                  [Page 1]

Internet-Draft           Teredo Security Updates           November 2007


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Randomize flags . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Deprecate cone bit  . . . . . . . . . . . . . . . . . . . . . . 4
   4.  Proposed changes  . . . . . . . . . . . . . . . . . . . . . . . 4
   5.  Backward Compatibility  . . . . . . . . . . . . . . . . . . . . 5
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
     9.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 6
   Intellectual Property and Copyright Statements  . . . . . . . . . . 7




































Krishnan & Hoagland       Expires May 19, 2008                  [Page 2]

Internet-Draft           Teredo Security Updates           November 2007


1.  Introduction

   An independent analysis of Teredo's security implications was
   conducted by Symantec[TEREDOSEC], based on the Teredo specification
   ([RFC4380]).  This analysis uncovered some security concerns
   associated with Teredo which are not documented in the Teredo
   specification.  This document discloses these additional concerns
   proposes the updates required to Teredo in order to address these
   concerns.  This Internet Draft is also influenced to an extent by an
   examination of the Teredo implementation on Microsoft Windows Vista
   [WVNASA].  This draft recommeds two changes to Teredo in order to
   make it more secure.


2.  Randomize flags

   Teredo addresses are structured and some of the fields contained in
   them are fairly predictable.  This can be used to better predict the
   address.

   Teredo prefix:  This field is 32 bits and has a single IANA assigned
      value

   Server:  This field is 32 bits and is set to the server in use.  The
      server to use is usually statically configured on the client.
      This means that overall entropy of the server field will be low,
      i.e., that the server will not be hard to predict.  Attackers
      could confine their guessing to the most popular server IP
      addresses.

   Flags:  The flags field is 16 bits in length, but RFC 4380 provides
      for only one of these bits (the cone bit) to vary.

   Client port:  This 16 bit field corresponds to the external port
      number assigned to the client's Teredo service port.  Thus the
      value of this field depends on two factors (the chosen Teredo
      service port and the NAT port assignment behavior) and therefore
      it is harder to predict the entropy this field will have.  If
      clients tend to use a predictable port number and NATs are often
      port-preserving ([RFC4787]), then the port number can be rather
      predictable.

   Client IPv4 address:  This 32 bit field corresponds to the external
      IPv4 address the NAT has assigned for the client port.  In
      principle, this can be any address in the assigned part of the
      IPv4 unicast address space.  However, if an attacker is looking
      for the address of a specific Teredo client, they will have to
      have the external IPv4 address pretty well narrowed down.  Certain



Krishnan & Hoagland       Expires May 19, 2008                  [Page 3]

Internet-Draft           Teredo Security Updates           November 2007


      IPv4 address ranges could also become well known for having a
      higher concentration of Teredo clients, making it easier to find
      an arbitrary Teredo client.  These addresses could correspond to
      large organizations that allows Teredo such as a university or
      enterprise or to Internet Service Providers that only provide
      their customers with RFC 1918 addresses.

   Optimizations in scanning can also reduce the number addresses that
   need to be checked.  For example, for addresses behind a cone NAT, it
   would likely be easy to probe if a specific port number is open on a
   IPv4 address, prior to trying to form a Teredo address for that
   address and port.

   Most of this is elaborated on more in [TEREDOSEC].


3.  Deprecate cone bit

   The cone bit tells the attacker whether a bubble is needed to proceed
   a connection.  It may also have some value in terms of profiling to
   the extent that it reveals the security posture of the network.  If
   the cone bit is set, the attacker may decide it is fruitful to port
   scan the embedded external IPv4 address and others associated with
   the same organization, looking for open ports.  Deprecating the cone
   bit would prevent the a priori revelation of the security posture of
   the NAT and would not reduce the functionality of the Teredo
   protocol.  The qualification procedure described in section 5.2.1 of
   [RFC4380] will also be affected by this change.


4.  Proposed changes

   The Flags field defined in section 4 of [RFC4380] is redefined as
   follows.


             0       0 0       1
            |0       7 8       5
            +----+----+----+----+
            |zzrr|rrUG|rrrr|rrrr|
            +----+----+----+----+

                          Figure 1: Flags format

   o  The bits "UG" should be set to the value "00", indicating a non-
      global unicast identifier.





Krishnan & Hoagland       Expires May 19, 2008                  [Page 4]

Internet-Draft           Teredo Security Updates           November 2007


   o  The bits marked"z" SHOULD be set to 0.  This bit was earlier
      defined as the Cone bit to indicate if the client was behind a
      cone NAT.

   o  The bits marked with "r" SHOULD be chosen at random by the client.

   Assuming there is no bias in those bit settings, then this adds 12
   additional bits of entropy (4096 times as many addresses).  This
   makes it harder for an attacker to guess Teredo addresses.


5.  Backward Compatibility

   The Microsoft web site [MSTO] indicates that Windows Vista already
   randomizes the bits as suggested in this document.  Other
   implementations need to be updated to perform this.  All client
   implementations need to be modified to always set the cone bit to 0.
   But in either case, there are no functional interoperability issues
   and Teredo components updated as suggested in this specification are
   fully compatible with implementations that follow RFC 4380.  The
   changes suggested in this document can improve some aspects related
   to security.


6.  Acknowledgments

   The authors would like to thank Remi Denis-Courmont, Dave Thaler,
   Fred Templin, Jori Palet Martinez, James Woodyatt and Christian
   Huitema for reviewing earlier versions of the document and providing
   comments to make this document better.


7.  Security Considerations

   This document describes some updates to RFC4380 in order to improve
   the security of the base Teredo mechanism.  Teredo is NOT RECOMMENDED
   as a solution for managed networks.  Administrators of such networks
   may wish to filter all Teredo traffic at the boundaries of their
   networks.


8.  IANA Considerations

   There are no IANA considerations resulting from this document.


9.  References




Krishnan & Hoagland       Expires May 19, 2008                  [Page 5]

Internet-Draft           Teredo Security Updates           November 2007


9.1.  Normative References

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

   [RFC4787]  Audet, F. and C. Jennings, "Network Address Translation
              (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
              RFC 4787, January 2007.

9.2.  Informative References

   [MSTO]     Microsoft, "Teredo Overview", <http://www.microsoft.com/
              technet/prodtechnol/winxppro/maintain/teredo.mspx>.

   [TEREDOSEC]
              Hoagland, J., "The Teredo Protocol: Tunneling Past Network
              Security and Other Security Implications", November 2006,
              <http://www.symantec.com/avcenter/reference/
              Teredo_Security.pdf>.

   [WVNASA]   Hoagland, J., Conover, M., Newsham, T., and O. Whitehouse,
              "Windows Vista Network Surface Analysis", March 2007,
              <http://www.symantec.com/avcenter/reference/
              Vista_Network_Attack_Surface_RTM.pdf>.


Authors' Addresses

   Suresh Krishnan
   Ericsson
   8400 Decarie Blvd.
   Town of Mount Royal, QC
   Canada

   Phone: +1 514 345 7900 x42871
   Email: suresh.krishnan@ericsson.com


   James Hoagland
   Symantec Corporation
   350 Ellis St.
   Mountain View, CA  94043
   US

   Email: Jim_Hoagland@symantec.com
   URI:   http://symantec.com/




Krishnan & Hoagland       Expires May 19, 2008                  [Page 6]

Internet-Draft           Teredo Security Updates           November 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Krishnan & Hoagland       Expires May 19, 2008                  [Page 7]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/