Re: [secdir] Routing loop attacks using IPv6 tunnels

Gabi Nakibly <gnakibly@yahoo.com> Tue, 18 August 2009 10:31 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 5BCD328C0F2 for <secdir@core3.amsl.com>; Tue, 18 Aug 2009 03:31:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.701
X-Spam-Level:
X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[AWL=-0.099, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 y3MxM1wJnWa2 for <secdir@core3.amsl.com>; Tue, 18 Aug 2009 03:31:58 -0700 (PDT)
Received: from n72.bullet.mail.sp1.yahoo.com (n72.bullet.mail.sp1.yahoo.com [98.136.44.34]) by core3.amsl.com (Postfix) with SMTP id F18A83A69A4 for <secdir@ietf.org>; Tue, 18 Aug 2009 03:31:57 -0700 (PDT)
Received: from [69.147.84.144] by n72.bullet.mail.sp1.yahoo.com with NNFMP; 18 Aug 2009 10:29:27 -0000
Received: from [69.147.84.34] by t6.bullet.mail.sp1.yahoo.com with NNFMP; 18 Aug 2009 10:29:27 -0000
Received: from [127.0.0.1] by omp210.mail.sp1.yahoo.com with NNFMP; 18 Aug 2009 10:29:27 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 213279.79398.bm@omp210.mail.sp1.yahoo.com
Received: (qmail 44992 invoked by uid 60001); 18 Aug 2009 10:29:27 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1250591367; bh=FhrggRYJfMQPyzw933PNcehrE2GcrLL8yvQV75aq6fg=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=c2ncJKmi+IvpWWl+/0XblUJqFhD6Kke//EwQzKZArrfAqZywwQJLvsNjpwaQhQdyhCsoFVdm2LgeUwh7mjh+Wam7rMtf7nhvav4QKK3KAoGQ6TRzFBACG9GrBkGzOU6sxThFQhqp/iKfXQqV0xUHAbz0LeLIsKwl9kz9Bk0XY6c=
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; b=0yD4r7gEQf6M8btJ0pELKZSFEbB7/rWoTdyfD8evzVfk2ObDgD6/8DiazZEjr5Q8opQbrB7XIRtsQo/Aj3hHt+Qecf9cQ/3mBAMLyq8MFAp48bLMSVNrRvIvDdVtX/EhPcXSHKLBZ4UFsJ4pk5NXZr3prVNah+jtY1QcNa/cpsQ=;
Message-ID: <2705.42043.qm@web45502.mail.sp1.yahoo.com>
X-YMail-OSG: VBI9GEkVM1llUTTNFOz1BkkiBeoEYErNwFMrfpoXtT.d3KOzB_djLgS3
Received: from [89.138.113.91] by web45502.mail.sp1.yahoo.com via HTTP; Tue, 18 Aug 2009 03:29:26 PDT
X-Mailer: YahooMailRC/1358.27 YahooMailWebService/0.7.338.2
References: <789539.81531.qm@web45502.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106497BE7@XCH-NW-7V2.nw.nos.boeing.com>
Date: Tue, 18 Aug 2009 03:29:26 -0700 (PDT)
From: Gabi Nakibly <gnakibly@yahoo.com>
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>, v6ops <v6ops@ops.ietf.org>
In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A106497BE7@XCH-NW-7V2.nw.nos.boeing.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1918408619-1250591366=:42043"
Cc: ipv6@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels
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 10:31:59 -0000

Indeed the ISATAP interface of the ISATAP router is meant to be an enterprise-interior (note that it is still assumed that the associated IPv4 address is non-private). As we explicitly note in the paper, the first three attacks will be mitigated if proper protocol-41 filtering is deployed on the site's border. However, note that RFC5214 does not mandate or require this filtering. It is only mentioned as a possible mitigation against incoming spurious protocol-41 packets. In addition, Section 10 of RFC5214 only mentions ingress not egress filtering. Hence it will not stop attack #2. 
In addition, as mentioned, protocol-41 filtering is not helpful when attack #3 is launched on two routers that reside in the same site. Note that it may be possible for the attack packet to be sourced from outside the site unless proper filtering of incoming IPv6 packets is deployed. If the attacker resides in the site, usually ingress filtering will not be helpful since it is deployed in general on the site's border.

In general, I would like to point out that indeed as in most other attacks these attacks may also be mitigated by proper firewall rules. However, I do not believe that this should be our only answer against these attacks. I believe that since these attacks are made possible due to the inherent characteristics of the tunnels they should be stopped intrinsically as much as possible by the tunnel participants and not relay on outside filtering rules.

Gabi


________________________________
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: Gabi Nakibly <gnakibly@yahoo.com>om>; v6ops <v6ops@ops..ietf.org>
Cc: ipv6@ietf.org; secdir@ietf.org
Sent: Monday, August 17, 2009 8:35:08 PM
Subject: RE: Routing loop attacks using IPv6 tunnels


Gabi,
 
Thanks for publishing this work. In the document, attacks A, B and C
correspond to a configuration that violates section 6.2 of RFC5214:
 
> 6.2.  ISATAP Interface Address Configuration
> 
>   Each ISATAP interface configures a set of locators consisting of IPv4
>   address-to-interface mappings from a single site; i.e., an ISATAP
>   interface's locator set MUST NOT span multiple sites.
 
In particular, in scenarios A, B and C the IPv4 locator used for ISATAP
is seen both within the enterprise as site #1 and within the global Internet
itself as site #2. If the ISATAP interface is to be used as an enterprise-
interior interface, it should therefore not accept IP-proto-41 packets
coming from an IPv4 source outside of the enterprise nor source
IP-proto-41 packets that are destined to an IPv4 node outside of the
enterprise. This condition should be satisfied by having the site border
routers implement IPv4 ingress filtering and ip-protocol-41 filtering as
required in Section 10 of RFC5214.
 
It is mentioned that attack C could also occur when the routers reside
in the same site, where their addresses may be private. This would
correspond to a case in which an attacker within the site attacks the
site itself, which can easily be traced – especially when source address
spoofing from a node within the site is prevented through proper ingress
filtering.
 
Fred
fred.l.templin@boeing.com
 

________________________________

From:Gabi Nakibly [mailto:gnakibly@yahoo.com] 
Sent: Monday, August 17, 2009 8:21 AM
To: v6ops
Cc: ipv6@ietf.org; secdir@ietf.org
Subject: Routing loop attacks using IPv6 tunnels
 
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