Re: [secdir] Routing loop attacks using IPv6 tunnels - the 6rd case

Rémi Després <remi.despres@free.fr> Tue, 18 August 2009 17:00 UTC

Return-Path: <remi.despres@free.fr>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A244B3A6BB1; Tue, 18 Aug 2009 10:00:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.949
X-Spam-Level:
X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1vGohu1WbNe5; Tue, 18 Aug 2009 10:00:44 -0700 (PDT)
Received: from smtp2a.orange.fr (smtp2a.orange.fr [80.12.242.140]) by core3.amsl.com (Postfix) with ESMTP id B56D93A6922; Tue, 18 Aug 2009 10:00:43 -0700 (PDT)
Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2a23.orange.fr (SMTP Server) with ESMTP id 321A980003C0; Tue, 18 Aug 2009 19:00:48 +0200 (CEST)
Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2a23.orange.fr (SMTP Server) with ESMTP id 2622680000B9; Tue, 18 Aug 2009 19:00:48 +0200 (CEST)
Received: from [193.248.104.104] (Mix-Lille-207-14-104.w193-248.abo.wanadoo.fr [193.248.104.104]) by mwinf2a23.orange.fr (SMTP Server) with ESMTP id 78E3D80003C0; Tue, 18 Aug 2009 19:00:45 +0200 (CEST)
X-ME-UUID: 20090818170045495.78E3D80003C0@mwinf2a23.orange.fr
In-Reply-To: <789539.81531.qm@web45502.mail.sp1.yahoo.com>
References: <789539.81531.qm@web45502.mail.sp1.yahoo.com>
Mime-Version: 1.0 (Apple Message framework v753.1)
Content-Type: text/plain; charset="ISO-8859-1"; delsp="yes"; format="flowed"
Message-Id: <6D7FF41F-717B-42D2-A744-750DC874356B@free.fr>
Content-Transfer-Encoding: quoted-printable
From: Rémi Després <remi.despres@free.fr>
Date: Tue, 18 Aug 2009 19:00:42 +0200
To: Gabi Nakibly <gnakibly@yahoo.com>
X-Mailer: Apple Mail (2.753.1)
X-Mailman-Approved-At: Tue, 18 Aug 2009 10:30:30 -0700
Cc: v6ops <v6ops@ops.ietf.org>, Mark Townsley <townsley@cisco.com>, 6man 6man <ipv6@ietf.org>, secdir@ietf.org
Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels - the 6rd case
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Aug 2009 17:00:45 -0000

Hi Gabi,

First, thanks to you and your colleagues for this research, and for  
the clear presentation of its results.
In my understanding, your contribution is important for transition  
solutions to be carefully selected, and where needed improved.

This mail is to complement the analysis with what applies to 6rd.

For those who don't know it, 6rd, like 6to4, ISATAP and Teredo, is an  
automatic tunnel mechanism in actual use for IPv6 across IPv4 clouds.
With it, service providers can offer native IPv6 to their customers  
while using for this their existing IPv4 infrastructures.
Publication of the RFC that describes it, RFC 5569, has been delayed  
since May for a reason related to intellectual property rights  
applicable to independent submissions.
But the draft on which 6rd is based is still available, and a new  
draft to extend its applicability is also available:
- tools.ietf.org/html/draft-despres-6rd-03
- tools.ietf.org/html/draft-townsley-ipv6-6rd-01


(1) Case of ISPs that operate 6rd relays and no 6to4 relays (and  
neither Teredo relays nor ISP-infrastructure NATs)

In its sec. 3, draft-despres-6rd-03 says:
<<<
    The IPv4 anycast address of 6rd relays may be chosen  
independently by
    each ISP.  The only constraint is that routes toward the ISP that  
are
    advertised must not include this address.
 >>>
In view of your study and in my understanding, it should be completed  
with:
"Also, the ISP must not forward toward the global IPv4 global  
Internet packets having this address as source."

With this, an ISP that operates 6rd relays but operates neither 6to4  
relays nor Teredo relays nor NATs is immune to the routing loop  
attack because:
- An IPv6 packet forwarded to the IPv6 Internet by a 6rd relay cannot  
come back to an IPv4 interface of a 6rd relay of the same ISP: there  
is no IPv4 route back to the ISP for its 6rd anycast address.
- An IPv6 packet received from the IPv6 Internet by a 6rd relay  
cannot be sent back to the IPv4 global Internet: the source address  
of its IPv4 encapsulating packet is the 6rd anycast address, which  
prevents it from reaching the IPv4 global Internet.

Note that, if interfaces of the ISP to the IPv4 global Internet are  
already subject to ingress filtering (packets received by the global  
Internet are discarded if there is no reverse path available for  
them), the added sentence is not necessary. It is just just a double  
precaution for cases where such ingress filtering doesn't apply.



(2) Case of ISPs that operate 6rd relays AND 6to4 relays (but neither  
Teredo relays nor ISP-infrastructure NATs)

In its sec. 5 on security, draft-despres-6rd-03 says:
<<<
    o  RELAY PACKETS TOWARD THE INTERNET: The IPv6 source must be a 6rd
       address that matches the IPv4 source.  The IPv6 destination must
       not start with the ISP 6rd prefix.
...
    o  RELAY PACKETS FROM THE INTERNET: The IPv6 source must not be a  
6rd
       address of the ISP.  The IPv4 destination must not be multicast,
       i.e. must not start with 224/3...
 >>>

In view of your study and in my understanding, it MUST be completed  
with:
- after the first quoted paragraph:
"Furthermore, if the ISP also operates 6to4 relays that advertise on  
the IPv6 network the 6to4 IPv6 prefix 2002::/16, the IPv4 source must  
be neither the 6to4 anycast address 192.88.99.0 nor any of its  
equivalent IPv4 unicast addresses."
- after the second quoted paragraph:
"Furthermore, if the ISP also operates 6to4 relays that advertise on  
the IPv6 network the 6to4 IPv6 prefix 2002::/16, the IPv4 destination  
derived from the IPv6 destination must be neither the IPv4 anycast  
address 192.88.99.0 nor any of its equivalent IPv4 unicast addresses."

With this, an ISP that operates both 6rd and 6to4 relays is also  
immune to the routing-loop attack because:
- an IPv6 packet forwarded to the global Internet by 6rd relays can  
come back to the ISP IPv4 network via one of the 6to4 relays of the  
ISP BUT cannot be accepted again by a 6rd relay: its IPv4 source  
address is then one of a 6to4 relay, which, with the first added  
sentence, prevents it from being accepted by the 6rd relay.
- an IPv6 packet received from the IPv6 Internet by a 6rd relay  
cannot be sent back to the IPv4 global Internet via one of the 6to4  
relays: the IPv4 address derived from its IPv6 destination would have  
for this to be one of a 6to4 relays, which, with the second added  
sentence, prevents it from being forwarded by the 6rd relay.

Note: RFC 3068, where the 6to4 anycast address is introduced, says  
that "each 6to4 relay router that advertise the 6to4 anycast prefix  
MUST also provide an equivalent IPv4 unicast address". Whether this  
is really important in practice is IMHO unclear. On the other hand,  
if this MUST is dispensed with, the above security precaution can be  
implemented in 6rd relays without a need to handle a variable number  
of addresses, and to administratively configure them (with the  
associated risks of human errors).



To conclude:
- Without needing to modify 6to4 relays, ISATAP relays, and Teredo  
relays, ISPs that support 6rd and don't support 6to4 appear to be  
already protected against routing loop attacks if ingress filtering  
is operational at their interfaces to the IPv4 global Internet. With  
an additional simple precaution in 6rd relays, they can also be  
immune in the absence of such filtering.
- A necessary additional security precaution against routing-loop  
attacks is now identified for ISPs that support 6rd and that, having  
started with 6to4, wish to keep it for backward compatibility. Thanks  
again for your analysis which made it possible.


Best regards,
RD



Le 17 août 09 à 17:21, Gabi Nakibly a écrit :

> Hi all,
> I would like to draw the attention of the list to some research  
> results which my colleague and I at the National EW Research &  
> Simulation Center have recently published. The research presents a  
> class of routing loop attacks that abuses 6to4, ISATAP and Teredo.  
> The paper can be found at: http://www.usenix.org/events/woot09/tech/ 
> full_papers/nakibly.pdf
>
> Here is the abstract:
> IPv6 is the future network layer protocol for the Internet. Since  
> it is not compatible with its predecessor, some interoperability  
> mechanisms were designed. An important category of these mechanisms  
> is automatic tunnels, which enable IPv6 communication over an IPv4  
> network without prior configuration. This category includes ISATAP,  
> 6to4 and Teredo. We present a novel class of attacks that exploit  
> vulnerabilities in these tunnels. These attacks 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 exhibit five attacks of this class. One of the  
> presented attacks can DoS a Teredo server using a single packet.  
> The exploited vulnerabilities are embedded in the design of the  
> tunnels; hence any implementation of these tunnels may be  
> vulnerable. In particular, the attacks were tested against the  
> ISATAP, 6to4 and Teredo implementations of Windows Vista and  
> Windows Server 2008 R2.
>
> I think the results of the research warrant some corrective action.  
> If this indeed shall be the general sentiment of the list, I will  
> be happy write an appropriate I-D. The mitigation measures we  
> suggested in the paper are the best we could think of to completely  
> eliminate the problem. However they are far from perfect since they  
> would require tunnel implementations to be updated in case new  
> types of automatic tunnels are introduced.
>
> Your comments are welcome.
>
> Gabi
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------