[Search] [pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
Internet Engineering Task Force                                P. Savola
Internet Draft                                                 CSC/FUNET
Expiration Date: August 2002
                                                           February 2002


                    Security Considerations for 6to4

               draft-savola-ngtrans-6to4-security-01.txt

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 10 of RFC2026.

   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.

   To view the list Internet-Draft Shadow Directories, see
   http://www.ietf.org/shadow.html.

Abstract

   The IPv6 interim mechanism 6to4 [6TO4] uses automatic IPv6-over-IPv4
   tunneling to interconnect IPv6 networks.  The architecture includes
   Relay Routers and Routers, which accept and decapsulate IPv4 traffic
   from anywhere.  There aren't many constraints on the embedded IPv6
   packets, or where IPv4 traffic will be automatically tunneled to.
   These could enable one to go around access controls, and more likely,
   being able to perform proxy Denial of Service attacks using Relays as
   reflectors.  This document discusses these issues in more detail and
   tries to suggest enhancements to alleviate the problems.









Savola                    [Expires August 2002]                 [Page 1]


Internet Draft  draft-savola-ngtrans-6to4-security-00.txt  February 2002


Table of Contents

   1.  Introduction  ...............................................   3
   2.  Different 6to4 Forwarding Scenarios  ........................   3
     2.1.  From 6to4 to 6to4  ......................................   4
     2.2.  From Native to 6to4  ....................................   4
     2.3.  From 6to4 to Native  ....................................   5
   3.  Some Functionalities of 6to4  ...............................   5
     3.1.  Functions of Different 6to4 Network Components  .........   5
     3.2.  Non-functions of Different 6to4 Network Components  .....   7
   4.  Special Processing of 6to4 Packets  .........................   7
     4.1.  Encapsulating IPv6 Packets into IPv4  ...................   7
     4.2.  Decapsulating IPv4 Packets into IPv6  ...................   8
   5.  Solutions  ..................................................   8
     5.1.  Generic Approach  .......................................   8
       5.1.1.  Encapsulating IPv6 into IPv4  .......................   8
       5.1.2.  Decapsulating IPv4 into IPv6  .......................   8
       5.1.3.  IPv4 and IPv6 Sanity Checks  ........................   9
         5.1.3.1.  IPv4  ...........................................   9
         5.1.3.2.  IPv6  ...........................................   9
         5.1.3.3.  Optional Ingress Filtering  .....................  10
         5.1.3.4.  Notes About the Checks  .........................  10
     5.2.  Simplified Approach  ....................................  10
       5.2.1.  Encapsulating IPv6 into IPv4  .......................  10
       5.2.2.  Decapsulating IPv4 into IPv6  .......................  11
     5.3.  All Relays Must Be Anycast  .............................  11
   6.  Problems  ...................................................  12
     6.1.  Implementation Considerations with Automatic Tunnels  ...  12
     6.2.  Reduced Flexibility  ....................................  12
   7.  Security Considerations  ....................................  13
   8.  Acknowledgements  ...........................................  14
   9.  References  .................................................  14
   Author's Address  ...............................................  14
   A.  Some Attack Scenarios Outlined  .............................  15
     A.1.  IPv6 Spoofing and Access Control Avoidance  .............  16
     A.2.  IPv4 Local Directed Broadcast Attacks  ..................  16
     A.3.  DoS Reflector  ..........................................  16
     A.4.  Remote Net-access Threats  ..............................  17













Savola                    [Expires August 2002]                 [Page 2]


Internet Draft  draft-savola-ngtrans-6to4-security-00.txt  February 2002


1. Introduction

   The IPv6 interim mechanism "6to4" [6TO4] specifies automatic
   IPv6-over-IPv4 tunneling to interconnect isolated IPv6 clouds without
   explicit tunnels by embedding the tunnel IPv4 address in the IPv6
   6to4 prefix.

   One challenge with this mechanism is that all 6to4 routers must
   accept and decapsulate IPv4 packets from every other 6to4 router;
   there are no strict constraints on what the IPv6 packet may contain,
   which implies a trust relationship.

   Another, bigger challenge is that to interconnect native IPv6
   networks and 6to4 clouds, relay routers are used as bridges between
   these two clouds.  Relay routers can be tricked by malicious parties
   to send IPv4, or IPv6, traffic anywhere the attacker wants.  With
   source address spoofing, this could be called traffic "laundering" or
   a "proxy" denial-of-service attack.

   The 6to4 specification outlined quite a few security considerations,
   but it has been shown that in practice some of these have been
   difficult to get implemented due to their abstract nature.

   This draft analyses the 6to4 security issues in more detail and
   outlines some enhancements and caveats.

   Sections 2-4 are more or less introductory in nature, rehashing how
   6to4 should be used today based on the 6to4 specification, so that it
   is easier to understand how security could be affected.

   Appendix A outlines a few possible attack scenarios.

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

2. Different 6to4 Forwarding Scenarios

   It should be noted that when communicating between 6to4 and native
   domains, the relays that will be used in the two directions are very
   likely different; routing is highly asymmetric.  Because of this, it
   is not feasible to limit relays you accept traffic from with e.g.
   access lists.








Savola                    [Expires August 2002]                 [Page 3]


Internet Draft  draft-savola-ngtrans-6to4-security-00.txt  February 2002


2.1. From 6to4 to 6to4

   6to4 domains always exchange 6to4 traffic directly via IPv4
   tunneling; the endpoint address V4ADDR is derived from 6to4 prefix
   2002:V4ADDR.

    .--------.           _----_          .--------.
    |  6to4  |         _( IPv4 )_        |  6to4  |
    | Router | <====> ( Internet ) <===> | Router |
    '--------'         (_      _)        '--------'
        ^                '----'              ^
        |      Direct tunneling over IPv4    |
        V                                    V
    .--------.                           .-------.
    |  6to4  |                           |  6to4  |
    | Client |                           | Client |
    '--------'                           '--------'

   It is required that every 6to4 router considers every other 6to4
   router it wants to talk to to be "on-link" (with IPv4 as the link-
   layer).  If this is restricted by increasing the prefix length from
   2002::/16, some traffic will be sent to the 6to4 Relay Router, which
   would forward it to other 6to4 Routers.  However, if the original
   destination does not have equally long prefix, the traffic it tries
   to send back will be tunneled directly, and will be dropped.

   Therefore, the restricted scenario is not globally workable and will
   not be considered here.

2.2. From Native to 6to4

   Native domains send traffic to 6to4 address 2002:V4ADDR, and it will
   be routed to the topologically nearest, advertising 6to4 Relay
   Router.  Relay router will tunnel the traffic over IPv4 to the
   corresponding IPv4 address V4ADDR.  (Note that IPv4 address 9.0.0.1
   here is just an example of a global IPv4 address.)















Savola                    [Expires August 2002]                 [Page 4]


Internet Draft  draft-savola-ngtrans-6to4-security-00.txt  February 2002


              2002::/16       Closest to 'Native Client'
    .--------.       _----_        .------------.            .--------.
    | Native |     _( IPv6 )_      | 6to4 Relay |  Tunneled  |  6to4  |
    | Client | -> ( Internet ) --> | Router     | =========> | Router |
    '--------'     (_      _)      '------------'   9.0.0.1  '--------'
                     '----'    dst=2002:0900:0000::1             |
                                                                 V
                                                             .-------.
                                                             |  6to4  |
                                                             | Client |
                                                             '--------'

2.3. From 6to4 to Native

   6to4 domains send traffic to native domains by tunneling it over IPv4
   to their configured 6to4 Relay Router, or the closest found using
   6to4 IPv4 Anycast [6TO4ANY].  The relay will decapsulate the packet
   and forward it to native IPv6 Internet using normal routing table and
   mechanisms.

                         Configured/found by IPv4 Anycast
    .--------.       _----_        .------------.            .--------.
    | Native |     _( IPv6 )_      | 6to4 Relay |  Tunneled  |  6to4  |
    | Client | <- ( Internet ) <-- | Router     | <========= | Router |
    '--------'     (_      _)      '------------' 192.88.99.1'--------'
                     '----'                     (or configured)   ^
                dst=3ffe:ffff::1                                  |
                                                             .-------.
                                                             |  6to4  |
                                                             | Client |
                                                             '--------'

3. Some Functionalities of 6to4

3.1. Functions of Different 6to4 Network Components

     o Non-6to4 (Native) Node

            If native IPv6 nodes want to communicate with 6to4 nodes,
            they send the traffic along normally.  The traffic will
            reach the topologically closest, advertising 6to4 Relay
            Router, and will be tunneled to the destination 6to4 Router,
            which will pass it to the 6to4 node via normal forwarding
            process.







Savola                    [Expires August 2002]                 [Page 5]


Internet Draft  draft-savola-ngtrans-6to4-security-00.txt  February 2002


     o 6to4 Host

            A host, usually autoconfigured and has an address from a
            6to4 prefix, but doesn't have a 6to4 pseudo-interface.  It
            doesn't need to know anything about 6to4, and it acts like a
            normal IPv6 Host in every manner.  Note that 6to4 Hosts can
            also be 6to4 Routers in some scenarios, but then 6to4 Router
            functionalities, below, apply.

     o 6to4 Router

            Acts on the border of a 6to4 domain.  It does not have a
            native, global IPv6 address.  More specifically:

              - provide "native-like" IPv6 connectivity to local clients
                and routers
              - if packets are sent to foreign 6to4 addresses, tunnel
                them to the destination 6to4 router using IPv4
              - if packets are sent to locally configured 6to4
                addresses, forward them normally
              - if packets are sent to non-6to4 addresses, tunnel them
                to the configured/closest-by-anycast 6to4 Relay Router,
                which will pass them on
              - if packets are received from 6to4 addresses, decapsulate
                the IPv4 packets received from 6to4 routers
              - if packets are received from non-6to4 addresses,
                decapsulate the IPv4 packets received from 6to4 Relay
                Router closest to the source.

     o 6to4 Relay Router

            Acts as a relay between all 6to4 domains and native IPv6;
            more specifically:

              - advertises the reachability of the 2002::/16 prefix to
                native IPv6 routing, thus receiving traffic to all 6to4
                addresses from closest native IPv6 nodes
              - (if implements RFC3068) advertise the reachability of
                IPv4 '6to4 Relay anycast prefix' (192.88.99.0/24) to
                IPv4 routing, thus receiving some tunneled traffic to
                native IPv6 nodes from 6to4 Routers
              - if packets are received from 6to4 addresses through
                tunneling, decapsulate them and forwards them on using
                normal IPv6 routing
              - if packets are received through normal IPv6 routing from
                native addresses, and are destined for 2002::/16, tunnel
                them to the corresponding 6to4 Router




Savola                    [Expires August 2002]                 [Page 6]


Internet Draft  draft-savola-ngtrans-6to4-security-00.txt  February 2002


3.2. Non-functions of Different 6to4 Network Components

   What should not happen; this forms a basis for the security checks.
   The lists are not exhaustive.

     o 6to4 Router or Relay
         - use private, broadcast or reserved IPv4 addresses in tunnels,
           or the matching 6to4 prefixes
         - receive traffic from 6to4 Routers where the IPv4 tunnel
           source address does not match the 6to4 prefix
         - receive traffic where the destination IPv6 address is not a
           global address; in particular, e.g. link-local addresses,
           mapped addresses and such should not be used
     o 6to4 Router
         - send traffic to other 6to4 domains through 6to4 Relay Router
           or via some third party 6to4 Router
         - receive traffic from other 6to4 domains via a 6to4 Relay
           Router
         - receive traffic to other than to your own 6to4 prefix(es)
     o 6to4 Relay Router
         - receive traffic from 6to4 to 6to4

4. Special Processing of 6to4 Packets

   One could summarize the special processing of 6to4 as follows:

     o Relay Router
          1. incoming from native, tunneled to 6to4
          2. tunneled from 6to4, going to native

     o Router
          1. tunneled from relay, source is native
          2. tunneled to relay, destination is native
          3. tunneled directly, destination is 6to4

4.1. Encapsulating IPv6 Packets into IPv4

   IPv6 packets are encapsulated into IPv4 in three scenarios:

      1. 6to4 Router sends packets to other 6to4 Routers (2002::/16
         destination)
      2. 6to4 Router sends packets to its configured/nearest-by-anycast
         6to4 Relay Router (non-2002::/16 destination)
      3. 6to4 Relay Router sends packets from native IPv6 sources to
         6to4 Routers (2002::/16 destination)






Savola                    [Expires August 2002]                 [Page 7]


Internet Draft  draft-savola-ngtrans-6to4-security-00.txt  February 2002


4.2. Decapsulating IPv4 Packets into IPv6

   IPv6 packets are decapsulated from IPv4 in three scenarios:

      1. 6to4 Router receives packets from other 6to4 Routers (2002::/16
         source)
      2. 6to4 Router receives packets from its 6to4 Relay Router closest
         to the source (non-2002::/16 source)
      3. 6to4 Relay Router receives packets from 6to4 Routers, to be
         sent to native IPv6 destinations (2002::/16 source)

5. Solutions

5.1. Generic Approach

5.1.1. Encapsulating IPv6 into IPv4

    src and dst SHOULD pass ipv6-sanity checks, else drop (defined below)
    if src=2002
        src MUST match src_v4
            [ the scenario: 4.1. case 1. or 2. ]
        if dst=2002
            dst_v4 SHOULD NOT be assigned to the router (avoid misconfigurations)
                [ the scenario: 4.1. case 1. ]
        fi
    elif dst=2002
        dst_v4 MAY have to match one of ipv4 equiv. of 6to4 prefixes masked by a
           user-specified prefix length (restricting who can use the relay)
            [ the scenario: 4.1. case 3. ]
    else
        drop
            [ the scenario: we somehow got a native-native ipv6 packet ]
    fi
    accept

5.1.2. Decapsulating IPv4 into IPv6

    src_v4 and dst_v4 SHOULD pass ipv4-sanity checks, else drop (defined below)
    src and dst SHOULD pass ipv6-sanity checks, else drop (defined below)
    if dst=2002
        dst MUST match dst_v4
        src_v4 may be restricted to be 6to4_ipv4_anycast [not useful for a long time yet]
            [ the scenario: 4.2. case 1. or 2. ]
            if src=2002
                src MUST match src_v4
                dst_v4 SHOULD be assigned to the router (see notes below)
                    [ the scenario: 4.2. case 1. ]
            fi



Savola                    [Expires August 2002]                 [Page 8]


Internet Draft  draft-savola-ngtrans-6to4-security-00.txt  February 2002


    elif src=2002
        src MUST match src_v4
        dst_v4 SHOULD be assigned to the router (see notes below)
        src_v4 MAY have to match one of ipv4 equiv. of 6to4 prefixes masked by a
               user-specified prefix length (restricting who can use the relay)
            [ the scenario: 4.2. case 3. ]
    else
        drop
            [ the scenario: we somehow got a native-native ipv6 packet ]
    fi
    accept

5.1.3. IPv4 and IPv6 Sanity Checks

5.1.3.1. IPv4

   IPv4 address MUST be a global unicast address, as required by the
   6to4 specification.  The disallowed addresses include those defined
   in [RFC1812], and others widely used and known not to be global.
   These are:
     o 0.0.0.0/8      (the system has no address assigned yet)
     o 10.0.0.0/8     (private)
     o 127.0.0.0/8    (loopback)
     o 172.16.0.0/12  (private)
     o 192.168.0.0/16 (private)
     o 169.254.0.0/16 (IANA Assigned DHCP link-local)
     o 224.0.0.0/4    (multicast)
     o 255.0.0.0/8    (broadcast)

   In addition it it SHOULD be checked that the address is not any of
   the system's broadcast addresses.  This is especially important if
   the implementation is made so that it can receive and process
   encapsulated IPv4 packets arriving at its broadcast addresses, or try
   to send encapsulated IPv4 packets to one of its broadcast addresses.

5.1.3.2. IPv6

   IPv6 address MUST not be:
     o 0::/16    (compatible, mapped addresses, loopback, unspecified,
       ...)
     o fe80::/10 (link-local)
     o fec0::/10 (site-local)
     o ff02::/16 (link-local multicast)

   Other multicast could also be considered for filtering.

   In addition, it MUST be checked that equivalent 2002:V4ADDR checks,
   where V4ADDR is any of the above IPv4 addresses, will not be passed.



Savola                    [Expires August 2002]                 [Page 9]


Internet Draft  draft-savola-ngtrans-6to4-security-00.txt  February 2002


5.1.3.3. Optional Ingress Filtering

   In addition, the implementation may perform some form of ingress
   filtering (e.g. Unicast Reverse Path Forwarding checks).  For
   example, if a Router has multiple interfaces, of which some are
   "internal", receiving either IPv4 or IPv6 packets with source address
   belonging to any of these internal networks from the Internet might
   be disallowed.

   If these checks are implemented, it is RECOMMENDED that they default
   to disabled.

5.1.3.4. Notes About the Checks

   The rule 'dst_v4 SHOULD be assigned to the router' is not needed if
   the implementation is made in such a way that it only accepts and
   processes encapsulated IPv4 packets arriving on unicast IPv4
   addresses, and that if destination address is known to be a local
   broadcast address, not try to encapsulate and send packets to it.

   Some checks, especially the IPv4/IPv6 Sanity Checks, could be at
   least partially implementable with system-level access lists, if one
   would like to avoid placing too many restrictions in the 6to4
   implementation itself.  This depends on how many hooks for ACL's are
   in place.  In practice it seems like this could not be done
   effectively enough unless the access list mechanism is able to parse
   the encapsulated packets within IP-IP.

5.2. Simplified Approach

   This makes some assumptions about the implementation as pointed above
   to simplify the above rules.

5.2.1. Encapsulating IPv6 into IPv4

    src and dst SHOULD pass ipv6-sanity checks, else drop
    if src=2002
        src MUST match src_v4
    elif dst=2002
        (accept)
    else
        drop
    fi
    accept







Savola                    [Expires August 2002]                [Page 10]


Internet Draft  draft-savola-ngtrans-6to4-security-00.txt  February 2002


5.2.2. Decapsulating IPv4 into IPv6

    src_v4 and dst_v4 SHOULD pass ipv4-sanity checks, else drop
    src and dst SHOULD pass ipv6-sanity checks, else drop
    if dst=2002
        dst MUST match dst_v4
            if src=2002
                src MUST match src_v4
            fi
    elif src=2002
        src MUST match src_v4
    else
        drop
    fi
    accept

5.3. All Relays Must Be Anycast

   In this model, all Relay Routers must always use 6to4 IPv4 Anycast
   address as the source address.

   In order for this to be implementable, every single 6to4 Relay Router
   must use only anycast.  This may be too significant a deployment
   restriction.

   Also, in certain circumstances if Unicast RPF is used, the use of
   IPv4 anycast as a source address globally will fail the checks and
   result in dropped packets.

   The checks would be:

   if src_v4 is 6to4 ipv4 anycast address
       accept [coming from relay]
   elif src_v4 is non-global ipv4 unicast address
       drop
   elif src = 2002
       src MUST match src_v4 [coming from router]
       accept
   else
       drop
   fi










Savola                    [Expires August 2002]                [Page 11]


Internet Draft  draft-savola-ngtrans-6to4-security-00.txt  February 2002


6. Problems

6.1. Implementation Considerations with Automatic Tunnels

   There is a problem with multiple transition mechanisms if security is
   implemented.  This may vary a bit from implementation to
   implementation.

   Consider three mechanisms using automatic tunneling: 6to4, ISATAP
   [ISATAP] and Automatic Tunneling using Compatible Addresses [MECH].
   All of these use IP-IP (protocol 41) [IPIP] IPv4 encapsulation with,
   more or less, a pseudo-interface.

   When a router, which has any two of these enabled, receives an IPv4
   encapsulated IPv6 packet:

        src_v4 = 10.0.0.1
        dst_v4 = 20.20.20.20
        src = 3ffe:ffff::1
        dst = 2002:1010:1010::2

   what can it do?  How should it decide which transitionary mechanism
   this belongs to; there is no "transitionary mechanism number" in IPv6
   or IPv4 header to signify this. (This can also be viewed as a
   flexibility benefit.)

   Without any kind of security checks (in any of implemented methods)
   these often just "work" as the mechanisms aren't differentiated but
   handled in "one big lump".

   Configured tunneling [MECH] does not suffer from this as it is point-
   to-point, and based on src/dst pairs of both IPv4 and IPv6 addresses
   it can be deduced which logical tunnel interface is in the question.

   Solutions for this include not using more than one automatic
   tunneling mechanisms in the same system or binding different
   mechanisms to different IPv4 addresses.

6.2. Reduced Flexibility

   There is a worry about too strict rules limiting the (future)
   flexibility of 6to4.  If later, for some reason, one would want to
   introduce new revolutionary ways to use 6to4, strict checking in all
   relevant nodes might prevent it, as new updated version would have to
   be deployed everywhere before the new method could be used.

   On the other hand, one could argue that 6to4 has always been intended
   as an intermediate mechanism, and that future flexibility should not



Savola                    [Expires August 2002]                [Page 12]


Internet Draft  draft-savola-ngtrans-6to4-security-00.txt  February 2002


   be critical.  However, it is difficult to predict how long the
   intermediate period will be.

7. Security Considerations

   This draft discusses security considerations.

   If proper checks are not implemented, there are significant security
   threats ranging from DoS proxy attacks to spoofing and attacks
   against 6to4 pseudo-interface.

   Remainder threats, if "maximal" security is implemented (e.g. all
   MUSTs and SHOULDs in 5.2.1 and 5.2.2):
     o one cannot verify that the relay is authorized to originate the
       traffic from native sources
     o relays can be used for remote reflection (packets sent to
       2002:[target ipv4])
     o relays can be used without authorization (theft of service); EGP
       advertisement restrictions aren't enough, e.g. routing headers
       can be used to work around these.

   The first could be partially remedied by keeping a list of trusted
   relays but that is not a really scalable or completely secure
   solution.  The latter two of these can be worked around (but only in
   a very closed environment) by IPv6 packet filter access-lists.

   Remainder threats, when only the most important checks have been
   implemented (e.g. only MUSTs in 5.2.1 and 5.2.2):
     o relays used for local amplified reflection (packets sent to
       2002:[addr], where addr is a (subnet) broadcast or multicast
       address.
     o relays' 6to4 pseudo-interface is subject to some remote local
       netaccess threats [NETACCESS] (e.g. with destination being link-
       local).

   This assumes that when encapsulating (or in some cases,
   decapsulating), the destination is not checked completely.

   As can be seen, relays are the toughest part to get secured, but
   luckily enough, there aren't thousands of them and the administrators
   can be assumed to be at least partially knowledgeable.










Savola                    [Expires August 2002]                [Page 13]


Internet Draft  draft-savola-ngtrans-6to4-security-00.txt  February 2002


8. Acknowledgements

   Alexey Kuznetsov brought up the implementation problem with IPv6
   martian checks.  Christian Huitema formulated the rules that rely on
   Relays using only anycast.  Keith Moore brought up the point about
   reduced flexibility.  Brian Carpenter, Tony Hain and Vladislav
   Yasevich for lengthy discussions.

9. References

   [6TO4]      Carpenter, B. and Moore K., "Connection of IPv6 Domains
               via IPv4 Clouds", RFC 3056, February 2001.

   [6TO4ANY]   Huitema, C. "An Anycast Prefix for 6to4 Relay
               Routers", RFC 3068, June 2001.

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

   [RFC1918]   Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G.
               and E. Lear, "Address Allocation for Private Internets",
               BCP 5, RFC 1918, February 1996.

   [MECH]      Gilligan, R., and Nordmark, E. "Transition Mechanisms for
               IPv6 Hosts and Routers", RFC 2893, August 2000.

   [IPIP]      Simpson, W. "IP in IP Tunneling", RFC 1853, October
               1995.

   [ISATAP]    Templin, F. "Intra-Site Automatic Tunnel Addressing
               Protocol (ISATAP)", draft-ietf-ngtrans-isatap-03.txt
               (work in progress).

   [NETACCESS] Kempf, J., Nordmark, E., "Threat Analysis for IPv6 Public
               Multi-Access Links", draft-kempf-ipng-netaccess-00.txt
               (work in progress).

Author's Address

   Pekka Savola
   CSC/FUNET
   Espoo, Finland
   EMail: psavola@funet.fi








Savola                    [Expires August 2002]                [Page 14]


Internet Draft  draft-savola-ngtrans-6to4-security-00.txt  February 2002


A. Some Attack Scenarios Outlined

   If the security checks haven't been properly implemented, at least
   the following are possible.

   The following addresses are used in these examples.  IPv4 addresses
   are indeed just examples of global IPv4 addresses.

          __________________                       __________________
         | Native IPv6 N1   |                     | Native IPv6 N2   |
         | 3ffe:ffff:1::/48 |                     | 3ffe:ffff:2::/48 |
         '------------------'                     '------------------'
                _______________________   _______________________
               | 6to4 Relay Router RR1 | | 6to4 Relay Router RR2 |
               | 3ffe:ffff:10::1/48    | | 3ffe:ffff:11:1::1/48  |
               | 2002:0900:0001::1/48  | | 2002:0900:0002::1/48  |
               | (IPv4) 9.0.0.1        | | (IPv4) 9.0.0.2        |
               '-----------------------' '-----------------------'
          ______________________                   ______________________
         |    6to4 Router RA    |                 |  6to4 Router RB      |
         | 2002:0800:0001::1/48 |                 | 2002:0800:0002::1/48 |
         | (IPv4) 8.0.0.1       |                 | (IPv4) 8.0.0.2       |
         '----------------------'                 '----------------------'

   When two 6to4 Routers send traffic to each others' domains, packet
   sent by RA to RB is like:

        src = 2002:0800:0001::aaaa
        dst = 2002:0800:0002::bbbb
        src_v4 = 8.0.0.1 (added when encapsulated to IPv4)
        dst_v4 = 8.0.0.2 (added when encapsulated to IPv4)

   When the packet is received by IPv4 stack on RB, it will be
   decapsulated so that only src and dst remain, as originally sent by
   RA:

        src = 2002:0800:0001::aaaa
        dst = 2002:0800:0002::bbbb

   As every other node is just "one hop away" and the "link-layer"
   addresses are lost, this may open a lot of possibilities for misuse.
   Some possible approaches are outlined below.









Savola                    [Expires August 2002]                [Page 15]


Internet Draft  draft-savola-ngtrans-6to4-security-00.txt  February 2002


  A.1. IPv6 Spoofing and Access Control Avoidance

   Unidirectional IPv6 spoofing is made trivial because nobody can check
   (without delving into IP-IP packets) whether the encapsulated IPv6
   addresses were authentic (With native IPv6, this can be done by e.g.
   RPF-like mechanisms or access lists in upstream routers).

        src = 2002:1234:5678::aaaa (forged)
        dst = 2002:0800:0002::bbbb
        src_v4 = 8.0.0.1 (added when encapsulated to IPv4)
        dst_v4 = 8.0.0.2 (added when encapsulated to IPv4)

   More worries come in to the picture if e.g.

        src = ::ffff:[some trusted IPv4 in a private network]
        src/dst = ::ffff:127.0.0.1
        src/dst = ::1
        src/dst = ...

   Some implementations might have been careful enough to have designed
   the stack to as to avoid these, but who can say for all ...

  A.2. IPv4 Local Directed Broadcast Attacks

   Relays could be targeted with local broadcast attacks:

        src = 3ffe:ffff:5678::aaaa (forged)
        dst = 2002:0900:00ff::bbbb

   Now, if the Relay doesn't check the destination address for
   broadcast, it would send the encapsulated IP-IP packet to 9.0.0.255
   which might be a local broadcast address (packets sent to every IPv4
   node in the subnet).  Classic directed broadcast checks will not
   prevent this as the packet doesn't come from outside (in IPv4 sense).

  A.3. DoS Reflector

   Denial-of-Service attacks could be reflected against either IPv4
   nodes (not that useful, only thing that could be sent is IP-IP
   packets) or IPv6 nodes.

   6to4 Relay Router could be abused as follows:

        src = X
        dst = Y
        src_v4 = 8.0.0.1 (added when encapsulated to IPv4)
        dst_v4 = 9.0.0.2 (added when encapsulated to IPv4)




Savola                    [Expires August 2002]                [Page 16]


Internet Draft  draft-savola-ngtrans-6to4-security-00.txt  February 2002


     a) X=2002:1234:5678::1 or X=3ffe:1122:3344::1 (forged)
        Y=2002:0500:0001::1 or Y=::0500:0001 (the victim)

   Target IPv4 address 5.0.0.1 would be bombed with reflected packets
   from 6to4 Relay Router RR2.  Source address in IPv6 header reveals
   nothing, or can be used to throw blame on someone else.

     b) X=2002:1234:5678::1 or X=3ffe:1122:3344::1 (forged)
        Y=3ffe:aabb:ccdd::1 (the victim)

   As above, the target could be native IPv6 address too, not
   necessarily an IPv4 node.

   Improper 6to4 Router could be abused as follows:

        src = X
        dst = Y
        src_v4 = 8.0.0.1 (added when encapsulated to IPv4)
        dst_v4 = 8.0.0.2 (added when encapsulated to IPv4)

   Both issues from above may also apply, if not implemented properly.
   For example:

    a)  X=2002:1234:5678::1 or X=3ffe:1122:3344::1 (forged)
        Y=3ffe:aabb:ccdd::1 (the victim)

   This might allow one to tunnel to the 6to4 Router RB, and place
   packets, with forged source addresses (be they 6to4 or not) to the
   router, and if it accepted them to be routed natively (ie. the
   forwarding process doesn't check that it shouldn't send them out the
   same way they came), be tunneled to Relay Router, and from there to
   Internet.

  A.4. Remote Net-access Threats

   As [NETACCESS] points out, there are a significant number of issues
   with public multi-access links.  The security mechanism is that
   nobody will want to do any harm, Hop Limit can be verified to be 255
   (the packet has not been forwarded) and link-local addresses are
   used.

   However, with 6to4 pseudo-interface, unless there are checks for the
   destination addresses (a bit problematic especially in 6to4 Relays),
   none of these are valid!  The packet would look like:







Savola                    [Expires August 2002]                [Page 17]


Internet Draft  draft-savola-ngtrans-6to4-security-00.txt  February 2002


        src_v4 = <something>
        dst_v4 = <relay or router>
        ttl_v4 = <whatever>
        src = 3ffe:ffff::1 or (in some cases) fe80::2
        dst = fe80::1
        hop limit = 255

   Needless to say, this would bring the security of 6to4 pseudo-
   interface (or any interface blindly decapsulating packets and not
   performing strict checks on the content) could become like that of a
   public multi-access network.

   Similarly, e.g. '::1' could also be used as a destination address.






































Savola                    [Expires August 2002]                [Page 18]