Re: [secdir] Routing loop attacks using IPv6 tunnels

Rémi Després <remi.despres@free.fr> Fri, 04 September 2009 17:05 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 7CC4B3A682E; Fri, 4 Sep 2009 10:05:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.532
X-Spam-Level:
X-Spam-Status: No, score=-1.532 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, 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 dfbkAS7F67Zq; Fri, 4 Sep 2009 10:05:47 -0700 (PDT)
Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id DE0543A67EF; Fri, 4 Sep 2009 10:05:45 -0700 (PDT)
Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id DB1C1E0808D; Fri, 4 Sep 2009 19:05:24 +0200 (CEST)
Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 87F19E080E5; Fri, 4 Sep 2009 19:05:20 +0200 (CEST)
In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1065D7539@XCH-NW-7V2.nw.nos.boeing.com>
References: <31484.26522.qm@web45503.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106555B38@XCH-NW-7V2.nw.nos.boeing.com> <373420.97768.qm@web45509.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106599177@XCH-NW-7V2.nw.nos.boeing.com> <342868.34354.qm@web45502.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A1065D7539@XCH-NW-7V2.nw.nos.boeing.com>
Mime-Version: 1.0 (Apple Message framework v753.1)
Content-Type: text/plain; charset="ISO-8859-1"; delsp="yes"; format="flowed"
Message-Id: <021A8F28-173E-471C-98E6-1E9A313E9715@free.fr>
Content-Transfer-Encoding: quoted-printable
From: Rémi Després <remi.despres@free.fr>
Date: Fri, 04 Sep 2009 19:05:19 +0200
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>
X-Mailer: Apple Mail (2.753.1)
Cc: Gabi Nakibly <gnakibly@yahoo.com>, v6ops <v6ops@ops.ietf.org>, 6man 6man <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: Fri, 04 Sep 2009 17:05:48 -0000

Comment below

Le 3 sept. 09 à 17:59, Templin, Fred L a écrit :

> Gabi,
>
>> -----Original Message-----
>> From: Gabi Nakibly [mailto:gnakibly@yahoo.com]
>> Sent: Thursday, September 03, 2009 8:00 AM
>> To: Templin, Fred L; v6ops
>> Cc: ipv6@ietf.org; secdir@ietf.org
>> Subject: Re: Routing loop attacks using IPv6 tunnels
>>
>> Hi Fred,
>> see inline.
>>
>> Gabi
>>
>> ----- Original Message ----
>>> From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
>>> To: Gabi Nakibly <gnakibly@yahoo.com>; v6ops <v6ops@ops.ietf.org>
>>> Cc: ipv6@ietf.org; secdir@ietf.org
>>> Sent: Tuesday, September 1, 2009 6:49:56 PM
>>> Subject: RE: Routing loop attacks using IPv6 tunnels
>>>
>>> Gabi,
>>>
>>>> -----Original Message-----
>>>> From: Gabi Nakibly [mailto:gnakibly@yahoo.com]
>>>> Sent: Monday, August 31, 2009 12:41 PM
>>>> To: Templin, Fred L; v6ops
>>>> Cc: ipv6@ietf.org; secdir@ietf.org
>>>> Subject: Re: Routing loop attacks using IPv6 tunnels
>>>>
>>>> Fred,
>>>>
>>>> I agree that the source address check discussed below should be  
>>>> made. I would
>>> also add a forth
>>>> check to mitigate attack #3 as a second layer of defense in case  
>>>> the opposite
>>> ISATAP router does not
>>>> make the proper check on the destination address.
>>>>
>>>> isatap_xmt() {
>>>>      ...
>>>>      if (src == "<foreign prefix>::0200:5efe:<my IP address>")
>>>>        drop_pkt(); /* attack #3 mitigation */
>>>>      ...
>>>>  }
>>>
>>> Having thought about it a bit, I agree but for ISATAP I see
>>> the source address check as a MAY and the destination address
>>> check as a SHOULD.


The two following scenarios show in my understanding that ISATAP  
routers SHOULD check Source addresses of packets they receive in IPv6:

SCENARIO 1: between two ISATAP routers A and B

   ISATAP router A receives in IPv6:
   Dst6 = </96 prefix of ISATAP router A> . <IPv4 address of ISATAP  
router B>
   Src6 = </96 prefix of ISATAP router B> . <IPv4 address of ISATAP  
router A>

   If ISATAP router A doesn't discard the packet because of its  
source address, it will encapsulate it with:
   Dst4 = <IPv4 address of ISATAP router B>
   Src4 = <IPv4 address of ISATAP router A>

   Then, ISATAP router B finds that Src6 and Src4 are consistent, and  
forwards the IPv6 packet to ISATAP router A.
   The routing loop is in place.

SCENARIO 2: between an ISATAP router and a 6to4 relay router

   The ISATAP router receives in IPv6:

   Dst6 = </96 prefix of the ISATAP router> . <IPv4 address of the  
6to4 relay>
   Src6 = 2002::/16 . <IPv4 address of the ISATAP router>

   If it doesn't discard the packet because of its source address, it  
will encapsulate it with:
   Dst4 = <IPv4 address of the 6to4 relay>
   Src4 = <IPv4 address of the ISATAP router>

   Then, the 6to4 relay finds that Src6 and Src4 are consistent, and  
forwards the IPv6 packet to the ISATAP router.
   The routing loop is in place.

Anything missing?

Regards,
RD