Re: [secdir] Routing loop attacks using IPv6 tunnels

"Templin, Fred L" <Fred.L.Templin@boeing.com> Mon, 17 August 2009 17:35 UTC

Return-Path: <Fred.L.Templin@boeing.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 6A63B3A6D39; Mon, 17 Aug 2009 10:35:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.76
X-Spam-Level:
X-Spam-Status: No, score=-5.76 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4]
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 qsXAopEIIv3R; Mon, 17 Aug 2009 10:35:10 -0700 (PDT)
Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 712353A6B87; Mon, 17 Aug 2009 10:35:10 -0700 (PDT)
Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n7HHZAt2001095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 17 Aug 2009 10:35:10 -0700 (PDT)
Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n7HHZAB3016048; Mon, 17 Aug 2009 10:35:10 -0700 (PDT)
Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n7HHZ8XE015894; Mon, 17 Aug 2009 10:35:10 -0700 (PDT)
Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Aug 2009 10:35:10 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA1F61.10FEDC58"
Date: Mon, 17 Aug 2009 10:35:08 -0700
Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A106497BE7@XCH-NW-7V2.nw.nos.boeing.com>
In-Reply-To: <789539.81531.qm@web45502.mail.sp1.yahoo.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Routing loop attacks using IPv6 tunnels
Thread-Index: AcofTmXEPOk1UYNFRUS+bwV+J7jmOAADteKg
References: <789539.81531.qm@web45502.mail.sp1.yahoo.com>
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: "Gabi Nakibly" <gnakibly@yahoo.com>, "v6ops" <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 17 Aug 2009 17:35:10.0344 (UTC) FILETIME=[11BE1880:01CA1F61]
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: Mon, 17 Aug 2009 17:35:17 -0000

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