[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 draft-ietf-v6ops-tunnel-loops

Network Working Group                                         G. Nakibly
Internet-Draft                                    National EW Research &
Updates: 3056, 5214                                    Simulation Center
(if approved)                                            F. Templin, Ed.
Intended status: Informational              Boeing Research & Technology
Expires: August 5, 2010                                 February 1, 2010


  Routing Loops using ISATAP and 6to4: Problem Statement and Proposed
                               Solutions
                draft-nakibly-v6ops-tunnel-loops-01.txt

Abstract

   This document is concerned with security vulnerabilities in the
   ISATAP and 6to4 tunnels.  These vulnerabilities allow an attacker to
   take advantage of inconsistencies between a tunnel's overlay IPv6
   routing state and the native IPv6 routing state.  The attacks form
   routing loops which can be abused as a vehicle for traffic
   amplification to facilitate DoS attacks.  We describe these security
   vulnerabilities and the attacks which exploit them.  We further
   recommend on solutions to remove the vulnerabilities.

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), 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 August 5, 2010.

Copyright Notice




Nakibly & Templin        Expires August 5, 2010                 [Page 1]


Internet-Draft        ISATAP and 6to4 Routing Loops        February 2010


   Copyright (c) 2010 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
   described in the BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Detailed Descriptions of the Attacks . . . . . . . . . . . . .  3
     2.1.  Attack #1: 6to4 Relay to ISATAP Router . . . . . . . . . .  4
     2.2.  Attack #2: ISATAP Router to 6to4 Relay . . . . . . . . . .  5
     2.3.  Attack #3: ISATAP Router to ISATAP Router  . . . . . . . .  6
   3.  Recommended Solutions  . . . . . . . . . . . . . . . . . . . .  7
     3.1.  Destination and Source Address Check . . . . . . . . . . .  7
       3.1.1.  Known IPv6 Prefix Check  . . . . . . . . . . . . . . .  8
     3.2.  Neighbor Cache Check . . . . . . . . . . . . . . . . . . .  9
     3.3.  Known IPv4 Address Check . . . . . . . . . . . . . . . . . 11
   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 12
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12


















Nakibly & Templin        Expires August 5, 2010                 [Page 2]


Internet-Draft        ISATAP and 6to4 Routing Loops        February 2010


1.  Introduction

   Recent research [USENIX09] has pointed out the existence of some
   security vulnerabilities in the design of the automatic tunnels
   ISATAP [RFC5214] and 6to4 [RFC3056].  These vulnerabilities allow a
   specially crafted packet to loop back and forth between ISATAP
   routers or 6to4 relays thereby overloading them.

   In automatic tunnels a packet's egress node's IPv4 address is
   computationally derived from the destination IPv6 address of the
   packet.  This feature eliminates the need to keep an explicit routing
   table at the tunnel's end points.  In particular, the end points do
   not have to be updated as peers join and leave the tunnel.  In fact,
   the end points of an automatic tunnel do not know which other end
   points are currently part of the tunnel.  However, all end points
   operate on the implicit assumption that once a packet arrives at the
   tunnel, its destination indeed is part of the tunnel.  This
   assumption poses a security vulnerability since it may result in an
   inconsistency between a tunnel's overlay IPv6 routing state and the
   native IPv6 routing state there by allowing a routing loop to be
   formed.

   An attacker can exploit this vulnerability by crafting a packet which
   is routed over a tunnel to a node that is not participating in that
   tunnel.  This node may forward the packet out of the tunnel to a
   native IPv6 network.  In that network, the packet is routed back to
   the ingress point that forwards it back into the tunnel.
   Consequently, the packet will loop in and out of the tunnel.

   A loop terminates only when the Hop Limit field in the IPv6 header of
   the packet is zeroed out.  The maximum value that can be assigned to
   this field is 255.  Note that when the packet is tunneled over IPv4
   routers, the Hop Limit does not decrease.  Every attack packet will
   traverse each hop along the loop 255/N times, where N is the number
   of IPv6 routers on the loop.  As a result, the loops can be used as
   traffic amplification tools with a ratio of 255/N. The number of IPv6
   routers on the loop is determined by the positions of the two
   victims.  The closer the two victims are, the larger the
   amplification ratio will be.


2.  Detailed Descriptions of the Attacks

   For the sake of completeness, this section details the three attacks
   from [USENIX09] that exemplify how the security vulnerability
   described above may be exploited.





Nakibly & Templin        Expires August 5, 2010                 [Page 3]


Internet-Draft        ISATAP and 6to4 Routing Loops        February 2010


2.1.  Attack #1: 6to4 Relay to ISATAP Router

   The two victims of this attack are a 6to4 relay and an ISATAP router.
   Let IPa and IPb denote the IPv4 address of the ISATAP router and the
   6to4 relay, respectively.  Let Prfa denote the IPv6 64-bit prefix of
   the ISATAP tunnel.  The attack is depicted in Figure Figure 1.  It is
   initiated by sending an IPv6 packet (packet 0 in Figure Figure 1) to
   a 6to4 destination address with an embedded router address of IPa,
   i.e., the destination address begins with 2002:IPa::/48.  The source
   address of the packet is an ISATAP address with Prfa as the prefix
   and IPb as the embedded IPv4 address.  As the destination address is
   6to4, the packet will be routed over the IPv6 network to the closest
   6to4 relay.  The relay receives the packet through its IPv6 interface
   and processes it as a normal IPv6 packet that needs to be delivered
   to the appropriate 6to4 site.  Hence, the packet is forwarded over
   the relay's IPv4 interface with an IPv4 header having a destination
   address derived from the IPv6 destination, i.e., IPa.  The source
   address is the address of the 6to4 relay, IPb.  The packet (packet 1
   in Figure Figure 1.) is routed over the IPv4 network to the ISATAP
   router.  The router receives the packet on its IPv4 interface.  It
   processes the packet as a regular IPv4 packet that originates from
   one of the end points of the ISATAP tunnel.  Since the IPv4 source
   address corresponds to the IPv6 source address, the packet will be
   decapsulated.  Since the packet's IPv6 destination is outside the
   ISATAP tunnel, the packet will be forwarded onto the native IPv6
   interface.  The forwarded packet (packet 2 in Figure Figure 1.) is
   identical to the original attack packet.  Hence, it will be routed
   back to the closest 6to4 relay, in which the loop will start again.

             ISATAP Router     6to4 Relay
                (IPa)            (IPb)
                  |                |   0
                  |        1       |<------
                  |<===============|
                  |        2       |
                  |--------------->|
                  |        .       |
                  |        .       |

           1  - IPv4: IPb --> IPa
                IPv6: Prfa::0200:5EFE:IPb --> 2002:IPa:*
           0,2- IPv6: Prfa::0200:5EFE:IPb --> 2002:IPa:*

   Legend: ====> - tunneled IPv6, ---> - native IPv6

             Figure 1: Attack #1: 6to4 Relay to ISATAP Router





Nakibly & Templin        Expires August 5, 2010                 [Page 4]


Internet-Draft        ISATAP and 6to4 Routing Loops        February 2010


2.2.  Attack #2: ISATAP Router to 6to4 Relay

   The two victims in this attack are again a 6to4 relay and an ISATAP
   router, but here they have swapped roles.  This time the ISATAP
   router accepts the attack packet and forwards it on its ISATAP tunnel
   to the 6to4 relay, which decapsulates it and forwards it back to the
   ISATAP router on the IPv6 network.  Let IPa, IPa and Prfa be the same
   as above.  The attack is depicted in Figure Figure 2.  This attack is
   initiated by sending an IPv6 packet (packet 0 in Figure Figure 2)
   with a destination ISATAP address having Prfa as the prefix and IPb
   as the embedded IPv4 address.  The source address of the packet is a
   6to4 address with a router having the IPa address , i.e., the
   destination address begins with 2002:IPa::/48.  The packet will be
   routed over the IPv6 network to the ISATAP router.  The router
   receives the packet through its IPv6 interface and processes it as a
   normal IPv6 packet that needs to be delivered to the appropriate end
   point in the ISATAP tunnel.  Hence, the packet is forwarded over the
   router's IPv4 interface with an IPv4 encapsulation having a
   destination address derived from the IPv6 destination , i.e., IPb.
   The source address is the address of the ISATAP router, IPa.  The
   packet (packet 1 in Figure Figure 2) is routed over the IPv4 network
   to the 6to4 relay.  The relay receives the packet on its IPv4
   interface.  It processes the packet as a normal IPv4 packet that
   originates from one of the end points of the 6to4 tunnel.  Since the
   IPv4 source address corresponds to the IPv6 source address, the
   packet will be admitted and decapsulated.  Since the packet's IPv6
   destination is outside the 6to4 tunnel, the packet will be forwarded
   out on the native IPv6 interface.  The forwarded packet (packet 2 in
   Figure Figure 2) is identical to the original attack packet.  Hence,
   it will be routed back to the ISATAP router, in which the loop will
   start again.




















Nakibly & Templin        Expires August 5, 2010                 [Page 5]


Internet-Draft        ISATAP and 6to4 Routing Loops        February 2010


             ISATAP Router     6to4 Relay
                (IPa)            (IPb)
              0   |                |
            ----->|        1       |
                  |===============>|
                  |        2       |
                  |<---------------|
                  |        .       |
                  |        .       |

           1  - IPv4: IPa --> IPb
                IPv6: 2002:IPa:* --> Prfa::0200:5EFE:IPb
           0,2- IPv6: 2002:IPa:* --> Prfa::0200:5EFE:IPb

   Legend: ====> - tunneled IPv6, ---> - native IPv6

             Figure 2: Attack #2: ISATAP Router to 6to4 Relay

2.3.  Attack #3: ISATAP Router to ISATAP Router

   The two victims in this attack are two ISATAP routers -- router A and
   router B -- having addresses IPa and IPb, respectively.  Let Prfa and
   Prfb be the prefixes of the ISATAP tunnels of router A and router B,
   respectively.  Note that the two routers do not participate in the
   same ISATAP tunnel.  However, they may reside at the same or
   different sites.  The attack is depicted in Figure Figure 3.  It is
   initiated by sending an IPv6 packet (packet 0 in Figure Figure 3)
   with a destination ISATAP address having Prfa as the prefix and IPb
   as the embedded IPv4 address.  The source address of the packet is an
   ISATAP address having Prfb as the prefix and IPa as the embedded IPv4
   address.  The packet will be routed over the IPv6 network to router
   A. The router receives the packet through its IPv6 interface and
   processes it as a normal IPv6 packet that needs to be delivered to
   the appropriate end point of its ISATAP tunnel.  The fact that the
   source address is also an ISATAP address does not matter here; the
   important thing is that the packet originated outside of the tunnel
   A. Hence, the packet is forwarded over the router's IPv4 interface
   with an IPv4 encapsulation having a destination address derived from
   the IPv6 destination , i.e., IPb.  The source address is the address
   of the router A, IPa.  The packet (marked with 1 in Figure Figure 3)
   is routed over the IPv4 network to router B. The router receives the
   packet on its IPv4 interface.  It processes the packet as a regular
   IPv4 packet that originates from one of the end points of its tunnel.
   Since the IPv4 source address corresponds to the IPv6 source address,
   the packet will be decapsulated.  The packet's IPv6 destination is
   outside of router B's tunnel; hence the packet is forwarded out onto
   the IPv6 interface.  The forwarded packet (packet 2 in Figure
   Figure 3) is identical to the original attack packet.  Hence, it will



Nakibly & Templin        Expires August 5, 2010                 [Page 6]


Internet-Draft        ISATAP and 6to4 Routing Loops        February 2010


   be routed back to router A, in which the loop will start again.

   The attack can also be launched on two ISATAP routers having private
   IPv4 addresses in th same IPv4 routing region.

             ISATAP Router    ISATAP Router
                (IPa)            (IPb)
              0   |                |
            ----->|        1       |
                  |===============>|
                  |        2       |
                  |<---------------|
                  |        .       |
                  |        .       |

           1  - IPv4: IPa --> IPb
                IPv6: Prfb::0200:5EFE:IPa --> Prfa::0200:5EFE:IPb
           0,2- IPv6: Prfb::0200:5EFE:IPa --> Prfa::0200:5EFE:IPb

   Legend: ====> - tunneled IPv6, ---> - native IPv6

            Figure 3: Attack #3: ISATAP Router to ISATAP Router


3.  Recommended Solutions

   This section describes the recommended solutions that mitigate the
   attacks above.  For each solution we shall discuss its advantages and
   disadvantages.

3.1.  Destination and Source Address Check

   Tunnel routers can use a source address check mitigation when they
   forward an IPv6 packet into a tunnel interface with an IPv6 source
   address that embeds one of the router's configured IPv4 addresses.
   Similarly, tunnel routers can use a destination address check
   mitigation when they receive an IPv6 packet on a tunnel interface
   with an IPv6 destination address that embeds one of the router's
   configured IPv4 addresses.  These checks should correspond to both
   tunnels' IPv6 address formats, regardless of the type of tunnel the
   router employs.

   For example, if tunnel router A (ISATAP router or 6to4 relay)
   forwards a packet into a tunnel interface with an IPv6 source address
   that matches the 6to4 prefix 2002:IPa::/48, the router discards the
   packet if IPa is one of its own IPv4 addresses.  In a second example,
   if tunnel router B (ISATAP router or 6to4 relay) receives an IPv6
   packet on a tunnel interface with an IPv6 destination address that



Nakibly & Templin        Expires August 5, 2010                 [Page 7]


Internet-Draft        ISATAP and 6to4 Routing Loops        February 2010


   matches the ISATAP address suffix ::0200:5EFE:IPb, the router
   discards the packet if IPb is one of its own IPv4 addresses.  In both
   of these examples, the router can unambiguously check the addresses
   IPa and IPb since both are known to be public IPv4 addresses by
   definition of the 6to4 and ISATAP address formats.  However, the
   router cannot perform the simple check if the embedded IPv4 address
   is a private one [RFC1918] since it is ambiguous in scope.  This
   reservation is relevant only to attacks of type #3 (a loop between
   two ISATAP routers) since the other two types of attack involves a
   6to4 tunnel which always embeds public IPv4 addresses.

   When a tunnel router (ISATAP, 6to4) has a way of knowing whether an
   embedded IPv4 address is one of its own addresses, it can avoid the
   routing loop attack scenarios depicted in Figures 1, 2 and 3 by
   performing the following simple checks:

   o  When the router forwards an IPv6 packet into a tunnel interface,
      it discards the packet if the IPv6 source address is not one of
      the router's configured IPv6 addresses but embeds one of the
      router's configured IPv4 addresses.

   o  When the router receives an IPv6 packet on a tunnel interface, it
      discards the packet if the IPv6 destination address is not one of
      the router's configured IPv6 addresses but embeds one of the
      router's configured IPv4 addresses.

   This approach can be employed by an ISATAP router or 6to4 relay.  As
   noted above the router must perform the embedded IPv4 address
   inspections for both ISATAP and 6to4 IPv6 address formats even if the
   router does not implement one of those tunnels.  This approach has
   the advantage that it is easy to implement and that no ancillary
   state is required, since checking is through static lookup in the
   lists of IPv4 and IPv6 addresses belonging to the router.

   As noted above, this simple approach alone cannot be used when the
   embedded IPv4 address in the ISATAP address is private, because the
   address may be legitimately allocated to another node in another
   routing region.  To apply this check the router must first
   unambiguously determine the scope of the address.  The following
   check serves this purpose.

3.1.1.  Known IPv6 Prefix Check

   The known IPv6 prefix check is tied to the conceptual ISATAP link
   model.  It observes that an ISATAP link spans a portion of a
   connected IPv4 routing region up to (but not beyond) the entire
   connected IPv4 routing region itself.  For example, if there were no
   physical or logical segmentations (e.g., enterprise network border



Nakibly & Templin        Expires August 5, 2010                 [Page 8]


Internet-Draft        ISATAP and 6to4 Routing Loops        February 2010


   gateways) the entire public IPv4 Internet would be spanned by a
   single ISATAP link.  Similarly, a private IPv4 address routing region
   can be spanned by one or more ISATAP links that are distinct from the
   links that span other private IPv4 routing regions.

   Each IPv4 routing region can be segmented through logical or physical
   segmentation, e.g., through ip-proto-41 filters, firewalls, etc.  In
   that case, each distinct segment is spanned by a distinct ISATAP
   link.  As for any links, multiple distinct ISATAP links can be joined
   together by bridges or IPv6 routers.

   Each ISATAP link configures a set of IPv6 subnet prefixes, where each
   subnet prefix spans either the entire link or only a portion of the
   link.  Therefore, if the router can determine the full list of IPv6
   subnet prefixes assigned to ISATAP interfaces attached to the link,
   it can use the list to determine when static destination and source
   address checks are necessary.  By keeping track of the list of IPv6
   prefixes assigned to ISATAP interfaces connected to the link, an
   ISATAP router can perform the following checks on an ISATAP address
   which embeds a private IPv4 address:

   o  When the ISATAP router forwards an IPv6 packet into an ISATAP
      interface with a source address that matches an IPv6 prefix in the
      on-link prefix list, it determines whether the packet should be
      discarded or forwarded by performing the source address check
      specified in Section 3.1.  Otherwise, the router forwards the
      packet.

   o  When the ISATAP router receives an IPv6 packet on an ISATAP
      interface with a destination address that matches an IPv6 prefix
      in the on-link prefix list, it determines whether the packet
      should be discarded or accepted by performing the destination
      address check specified in Section 3.1.  Otherwise, the router
      accepts the packet.

   The disadvantage of this approach is the administrative overhead for
   maintaining the list of IPv6 subnet prefixes associated with an
   ISATAP link may become unwieldy should that list be long and/or
   frequently updated.

3.2.  Neighbor Cache Check

   The neighbor cache check mitigation observes that the routing loop
   attack scenarios depicted in Figures 1, 2 and 3 specifically target
   the ISATAP IPv6 on-link subnet model.  In this approach, hosts
   configure IPv6 addresses and assign IPv6 subnet prefixes on an ISATAP
   interface based on the Prefix Information Options included in the
   unicast Router Advertisement (RA) messages they receive from routers.



Nakibly & Templin        Expires August 5, 2010                 [Page 9]


Internet-Draft        ISATAP and 6to4 Routing Loops        February 2010


   Moreover, ISATAP hosts must first send Router Solicitation (RS)
   messages to routers in order to elicit these RAs since the ISATAP
   link model is Non-Broadcast, Multiple Access (NBMA).  Therefore,
   ISATAP routers can keep track of the hosts from which they have
   recently received RS messages by maintaining entries in their ISATAP
   interface neighbor cache that are keyed on the IPv6 unicast link-
   local source addresses received in the RS messages.  The ISATAP
   router can then determine which hosts are willing participants in the
   ISATAP IPv6 on-link subnets.

   By keeping track of the hosts that have recently sent RS messages, an
   ISATAP router can perform the following simple checks:

   o  When the ISATAP router forwards a packet into an ISATAP interface
      with an IPv6 destination address that matches a non-link-local
      prefix assigned to the interface and that embeds the IPv4 address
      IPa, it discards the packet if there is no corresponding neighbor
      cache entry for the interface keyed on an IPv6 unicast link-local
      address that embeds the IPv4 address IPa.

   o  When the ISATAP router receives a packet on an ISATAP interface
      with an IPv6 source address that matches a non-link-local prefix
      assigned to the interface and embeds the IPv4 address IPb, it
      discards the packet if there is no corresponding neighbor cache
      entry for the interface keyed on an IPv6 unicast link-local
      address that embeds the IPv4 address IPb.

   This approach can only be employed by an ISATAP router.  It has the
   advantage that the ISATAP router discards only those IPv6 packets
   that could cause the looping conditions, i.e., those packets with
   source and/or destination addresses taken from an ISATAP IPv6 on-link
   subnet prefix but for which no corresponding neighbor cache entry
   exists.  In contrast, other approaches could in some cases discard
   IPv6 packets that pertain to legitimate communications.  The approach
   is also easy to implement, and naturally leverages the relationship
   between the router's advertised prefix lifetimes and the interval
   between the host's successive RS transmissions according to the
   specifications in [RFC5214].

   This approach requires the ISATAP router to maintain a neighbor cache
   with entries created or updated by the reception of ISATAP host RS
   messages.  These entries must be retained for a duration that is at
   least as long as the router's advertised prefix lifetimes, i.e., even
   if the entries transition into the STALE state.  This may require an
   implementation to adjust its garbage-collection interval for stale
   neighbor cache entries.  The approach further requires that hosts
   perform the RS/RA exchanges specified in Section 8.3.4 of [RFC5214],
   i.e., the host-initiated RS/RA exchanges must be performed.  Finally,



Nakibly & Templin        Expires August 5, 2010                [Page 10]


Internet-Draft        ISATAP and 6to4 Routing Loops        February 2010


   this approach assumes that the neighbor cache will remain coherent
   and not subject to malicious attack, which must be confirmed based on
   specific deployment scenarios.  One possible way for an attacker to
   subvert the neighbor cache is to send false RS messages with a
   spoofed source address.

3.3.  Known IPv4 Address Check

   The known IPv4 address check method observes that each on-link IPv6
   subnet prefix on an ISATAP interface is configured over a limited set
   of IPv4 addresses, since each ISATAP Potential Router List will be
   used only by a finite set of hosts.  Therefore, only those hosts
   configured from a subset of the IPv4 addresses in an IPv4 routing
   region are authorized to configure IPv6 addresses and subnet prefixes
   advertised by a given ISATAP router.  By keeping track of the set of
   IPv4 addresses that are authorized to use an ISATAP on-link IPv6
   subnet, an ISATAP router can perform the following simple checks:

   o  When the ISATAP router forwards an IPv6 packet into an ISATAP
      interface with a destination address that matches a non-link-local
      prefix assigned to the interface and that embeds the IPv4 address
      IPa, it discards the packet if IPa does not belong to the list of
      IPv4 addresses over which the ISATAP on-link IPv6 subnet is
      configured.

   o  When the ISATAP router receives an IPv6 packet on an ISATAP
      interface with a source address that matches a non-link-local
      prefix assigned to the interface and that embeds the IPv4 address
      IPb, it discards the packet if IPb does not belong to the list of
      IPv4 addresses over which the ISATAP on-link IPv6 subnet is
      configured.

   This approach can only be employed by an ISATAP router, and offers a
   close analogy to the neighbor cache check discussed in Section 3.2.
   Indeed, one possible interpretation of this approach is that the
   router should simply cache the IPv4 addresses of hosts that have sent
   it an RS message.  In this interpretation, the only difference
   between this approach and the neighbor cache check discussed in
   Section 3.2 is the nature of the internal data structure used to
   store the IPv4 addresses, which is likely to be an implementation
   detail.  Therefore, the same set of advantages and disadvantages as
   described in Section 3.2 apply.

   Alternatively, the ISATAP router could pre-configure a static list of
   known IPv4 host addresses.  This list would be discovered through
   some unspecified means (e.g., manual configuration), and would serve
   as a "Potential Host List (PHL)" for the ISATAP interface.




Nakibly & Templin        Expires August 5, 2010                [Page 11]


Internet-Draft        ISATAP and 6to4 Routing Loops        February 2010


4.  IANA Considerations

   This document has no IANA considerations.


5.  Security Considerations

   This document aims at mitigating routing loops which involves ISATAP
   routers and 6to4 relays.  It contains various checks that aim to
   recognize and drop specific packets that have strong potential to
   cause a routing loop.  These checks does not introduce new security
   threats.


6.  Acknowledgments

   This work has benefited from discussions on the V6OPS, 6MAN and
   SECDIR mailing lists.  Remi Despres and Christian Huitema are
   acknowledged for their contributions.


7.  References

7.1.  Normative References

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

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

   [RFC5214]  Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
              Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
              March 2008.

7.2.  Informative References

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










Nakibly & Templin        Expires August 5, 2010                [Page 12]


Internet-Draft        ISATAP and 6to4 Routing Loops        February 2010


Authors' Addresses

   Gabi Nakibly
   National EW Research & Simulation Center
   P.O. Box 2250 (630)
   Haifa  31021
   Israel

   Email: gnakibly@yahoo.com


   Fred L. Templin (editor)
   Boeing Research & Technology
   P.O. Box 3707 MC 7L-49
   Seattle, WA  98124
   USA

   Email: fltemplin@acm.org

































Nakibly & Templin        Expires August 5, 2010                [Page 13]


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