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

Gabi Nakibly <gnakibly@yahoo.com> Mon, 24 August 2009 16:11 UTC

Return-Path: <gnakibly@yahoo.com>
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 9D42228C259 for <secdir@core3.amsl.com>; Mon, 24 Aug 2009 09:11:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.303
X-Spam-Level:
X-Spam-Status: No, score=-0.303 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396]
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 5Jh8I8ANyn9c for <secdir@core3.amsl.com>; Mon, 24 Aug 2009 09:11:55 -0700 (PDT)
Received: from n16a.bullet.mail.mud.yahoo.com (n16a.bullet.mail.mud.yahoo.com [68.142.207.126]) by core3.amsl.com (Postfix) with SMTP id CDEE528C1F6 for <secdir@ietf.org>; Mon, 24 Aug 2009 09:11:54 -0700 (PDT)
Received: from [68.142.194.243] by n16.bullet.mail.mud.yahoo.com with NNFMP; 24 Aug 2009 16:11:59 -0000
Received: from [68.142.201.246] by t1.bullet.mud.yahoo.com with NNFMP; 24 Aug 2009 16:11:59 -0000
Received: from [127.0.0.1] by omp407.mail.mud.yahoo.com with NNFMP; 24 Aug 2009 16:11:59 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 434488.81695.bm@omp407.mail.mud.yahoo.com
Received: (qmail 57852 invoked by uid 60001); 24 Aug 2009 16:11:58 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1251130318; bh=Z5S+vdzSLcYqgBnb1PXmFH30/JUIE1+UrWKg0MnGidA=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=XGMFXdLb0zdjmRkJhge7ufZk+kHJlAfd1CZfkTXu5/sexJ7zwJ/h2P/XvbN8iBaB7esRZNS9bkX35IS0OUNAUNWV6hJ7BrnQTEeH/2zF4zX8SAdwBtYO/oliLzhP9X3qm0lKlWxxAsE4h8zGPqQCBloFbMnz+Qw2Gpq373EzKtE=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=xTka0r3PHg+JqqX48geadQeDIgLMq8N9xv08QdEargNVWDtIzNu+1+rZcLgoLOpxgWyjIZQZGmjjFqn4K2k/yYwwR39cCMSqGRM6VmhR9e/3mVsciq5rzjZM95PbDusfZzNq2SV7hUMX9YUnZdYUR6gyvCE8lZFwaXr+CW6E1+c=;
Message-ID: <852107.57254.qm@web45516.mail.sp1.yahoo.com>
X-YMail-OSG: BwdE_vYVM1l_QUwItUxA19HWhxOH2XcfwADSMeBP98NOt9z5vTVug3eSdhkThEsX7o2o0yN8v6nAfjZY.e.HDmnWyEUwLc8J0n24VqIW3tDbg3._jBQdcDBpW.1ELeMAHTQcw8LrtIWYnPVT407.OBZRP5_wbpf.DQPuY4BjYJ4Bz1bgjfN0_qnL8e5jK.c5lEaFaBXE4NUIQvOhUPDyQDKU0xE4kffrku7Ye1BruQN.9Z5x1vg-
Received: from [93.172.27.171] by web45516.mail.sp1.yahoo.com via HTTP; Mon, 24 Aug 2009 09:11:58 PDT
X-Mailer: YahooMailRC/1358.27 YahooMailWebService/0.7.338.2
References: <789539.81531.qm@web45502.mail.sp1.yahoo.com> <6D7FF41F-717B-42D2-A744-750DC874356B@free.fr> <808598.58470.qm@web45510.mail.sp1.yahoo.com> <A63D19A5-2750-4075-A126-4936591F4A75@free.fr>
Date: Mon, 24 Aug 2009 09:11:58 -0700 (PDT)
From: Gabi Nakibly <gnakibly@yahoo.com>
To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= <remi.despres@free.fr>
In-Reply-To: <A63D19A5-2750-4075-A126-4936591F4A75@free.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
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: Mon, 24 Aug 2009 16:11:56 -0000

Remi,
See my comments inline (<gn>).

Gabi



----- Original Message ----
From: Rémi Després <remi.despres@free.fr>
To: Gabi Nakibly <gnakibly@yahoo.com>
Cc: v6ops <v6ops@ops.ietf.org>rg>; 6man 6man <ipv6@ietf.org>rg>; secdir@ietf.org; Mark Townsley <townsley@cisco.com>
Sent: Thursday, August 20, 2009 11:34:49 AM
Subject: Re: Routing loop attacks using IPv6 tunnels - the 6rd case

gabi,

Thanks for your quick answer.
Further remarks in line.

Le 19 août 09 à 12:12, Gabi Nakibly a écrit :

> Remi,
> See my comments inline (<gn>).
> Gabi
> 
> From: Rémi Després <remi.despres@free.fr>
> To: Gabi Nakibly <gnakibly@yahoo.com>
> Cc: v6ops <v6ops@ops.ietf.org>rg>; 6man 6man <ipv6@ietf.org>rg>; secdir@ietf.org; Mark Townsley <townsley@cisco.com>
> Sent: Tuesday, August 18, 2009 8:00:42 PM
> Subject: Re: Routing loop attacks using IPv6 tunnels - the 6rd case
> 
> 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
> <gn>
> I must admit that this is the first time I read the spec of 6rd so forgive me if I miss something.
> </gn>
> 
> (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.
> <gn>
> I agree with you that above check will work. However, I might choose another way here: the relay must make the following two checks:
> 1) When an IPv6 packet is received from the IPv6 Internet the 6rd relay must ensure before encapsulation that the intended IPv4 destination address belongs to one of the ISP's clients (I assume it can make this check easily). This way no IPv6 packet received from the IPv6 Internet will be relayed to a 6to4 relay (and then back to the 6rd relay through the IPv6 Internet).

The problem is that this check is not easy "in general" because ISPs typically have their IPv4 prefixes allocated one by one as they increase the number of their clients.


> 2) When an encapsulated packet is received from the IPv4 network side the 6rd relay must check that the IPv6 destination does not include its own IPv4 address. For example the IPv6 destination address must not be: 2002:<IPv4 address of 6rd relay>::/48. This will prevent the packet from ever reaching back the 6rd relay through its IPv4 interface

The problem is that to be general, and as you noted, this test depends on a knowledge of all formats used to embed IPv4 addresses in IPv6 addresses. When a new format is introduced, a security weakness therefore holds until all relays are upgraded to support it.
Besides, and more important, some formats may use _ISP dependent prefixes_ (and 6rd is already in this case!). These formats cannot be recognized by a constant code.


This being noted, I agree that, to extend applicability of 6rd relays to cases where ingress filtering doesn't apply, and to deal more simply with the case of 6rd ISPs that also operate 6to4 relays, 6rd relays SHOULD do as you propose:
*In 6rd relays, packets received on the IPv4 side should be discarded if their IPv6 destinations are 6to4 addresses containing the ISP 6rd anycast address.*


> 
> This way all the checks are done only at the 6rd relay and not in other IPv4 border routers of the ISP which should not be aware of the 6rd deployment.

Note that IPv4 border routers of the ISP need not to be aware of the 6rd in particular.
They only have to make sure that ingress filtering "in general" applies to packets sent toward the global Internet.
(If their downstream neighbors do ingress filtering as they should, these border routers have nothing specific to do. In cases where this isn't sure though, they should better prevent source address spoofing by filtering themselves source addresses for which they have no reverse path.)


<gn>
- For packets coming from the IPv6 side: if the first check I suggested of the ISP's clients is not easy, then you can instead check, as you suggested below, the IPv6 source address of the incoming packet to verify that it is not a 6to4 address containing the 6rd relay IPv4 address. This can make the check of the source address in other IPv4 border routers redundant.
- For packets coming from the IPv4 side: on second thought, if the 6rd spec already ensures that there is no IPv4 route from an external 6to4 relay to a 6rd relay, then indeed the second check I proposed is redundant. Moreover, I completely agree that this check can only eliminate routing loops with a 6to4 relay and not with relays of other types of tunnels. 
 </gn>


> </gn>
> 
> 
> (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."
> <gn>
> Actually, I believe that the precautions I suggested above will work here also instead of those checks. Won't they?

As explained above, it would be 100% safe only if all embedded IPv4 addresses were guaranteed to be recognized, which is not the case.


> In general, I think that checks performed on the destination address (IPv4 or IPv6) should be more robust than checks on a source address.

In my understanding, not always.
Each scenario has to be studied for what it is.

> </gn>
> 
> 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).
> 
> <gn>
> If you do the check on the destination address you can avoid this administrative configuration altogether.

Agreed for packets forwarded to the IPv6 side (see above).

Now, for packets from the IPv6 Internet, rather than checking that the embedded IPv4 destination has one of the ISP allocated prefixes, there is a better check I hadn't seen before sending the previous e-mail:
*In 6rd relays, packets received on the IPv6 side should be discarded if their source addresses are 6to4 addresses containing the ISP 6rd anycast address.*

<gn>
I fully agree.
<\gn>

 
The above administrative configuration is thus unnecessary, and the 6rd relay cannot participate in a routing loop attack even if its ISP also operates 6to4 relays.

NOTE: As a matter of fact, a source address check can also be used to improve the Mitigation Measures you proposed for 6to4, ISATAP and Teredo relays:
*In your three forwarding conditions, it would be sufficient to add "or source" after each occurrence of "destination".*
Thus, each of these relays becomes protected against rooting loop attacks via any other 6to4, ISATAP, and Teredo relay, even if this relay doesn't make the new check on destination addresses.

<gn>
You are right. This can add another layer of security. However, one must note that for this check to work the other relay that participates in the routing loop must indeed validate before it decapsulates a packet that its IPv4 source address corresponds to its IPv6 source address. If this is not true, then the check of the source address you noted above is useless. I am making this note, since I have encountered some implementations of 6to4 and ISATAP that does not follow their corresponding spec and do not make this validation, as they should. 
But, again, I agree that this check can be used as another layer of security.
</gn>


> </gn>
> 
> 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..
> <gn>
> I fully agree.

Thanks.
Thoughts on the proposal to improve your mitigation measures?

Regards,
RD

> </gn>
> - 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
> > --------------------------------------------------------------------
> 
> 
> 
> 
>