Re: I-D ACTION:draft-jabley-ipv6-rh0-is-evil-00.txt

Tim Enos <timbeck04@verizon.net> Fri, 11 May 2007 21:19 UTC

Return-path: <ipv6-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmcWU-0008H8-Ca; Fri, 11 May 2007 17:19:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmcWT-0008H2-Mx for ipv6@ietf.org; Fri, 11 May 2007 17:19:33 -0400
Received: from vms042pub.verizon.net ([206.46.252.42]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmcWT-0005EH-DI for ipv6@ietf.org; Fri, 11 May 2007 17:19:33 -0400
Received: from vms126.mailsrvcs.net ([192.168.1.2]) by vms042.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JHW009IDB87P9F5@vms042.mailsrvcs.net> for ipv6@ietf.org; Fri, 11 May 2007 16:19:19 -0500 (CDT)
Received: from 129.55.200.20 ([129.55.200.20]) by vms126.mailsrvcs.net (Verizon Webmail) with HTTP; Fri, 11 May 2007 16:19:18 -0500 (CDT)
Date: Fri, 11 May 2007 16:19:18 -0500
From: Tim Enos <timbeck04@verizon.net>
X-Originating-IP: [129.55.200.20]
To: Pekka Savola <pekkas@netcore.fi>, "Ebalard, Arnaud" <Arnaud.Ebalard@eads.net>
Message-id: <2205955.3391151178918359084.JavaMail.root@vms126.mailsrvcs.net>
MIME-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
X-Spam-Score: 0.5 (/)
X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024
Cc: Brian Haberman <brian@innovationslab.net>, IETF IPv6 Mailing List <ipv6@ietf.org>
Subject: Re: I-D ACTION:draft-jabley-ipv6-rh0-is-evil-00.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
Errors-To: ipv6-bounces@ietf.org

Hi all,

>Oy,
>
>Le 10 mai 07 à 16:49, Pekka Savola a écrit :
>
>> On Thu, 10 May 2007, Jeroen Massar wrote:
>>> As such, when you are a transit provider, and you have on the  
>>> edges of
>>> your network some vulnerable hosts, those hosts can be used to apply
>>> this attack to your network.
>>>
>>> The documentation should thus specify that, where possible, RH0  
>>> should
>>> be filtered at customer borders.
>>
>> Well, IMHO that's a bit unnecessary.
>>
>> If you see packet ping-pong on the Internet, it's an indication that
>> ingress and egress filters haven't been adequately set up.  Adding
>> those will stop your network's bandwidth being wasted.
>>
>> Maybe this RH0 vulnerability will turn out for the good after all if
>> it means better BCP38/84 deployment :-)
>
>I agree. To sum up :
>
>- ingress filtering will prevent the use of clients unpatched/non  
>compliant clients nodes for bouncing RH0 traffic towards the  
>internet. This will limit potential attacks to internal networks in  
>the worst case scenario (if nothing is done by site administrators).

FWIW I think that loose RPF on the core routers could help mitigate attacks (on internal networks at least).
  
>This is efficiently implemented as this is done on the leaves. This  
>does not impacts clients for regular traffic (including MIPv6).
>

Agreed that ingress filtering ala BCP 38 at the edge is strongly advised (at least a SHOULD). As cited by the authors (end of section 4), the number of asymmetric routes would seem to preclude the additional use of strict RPF. OTOH, loose RPF in the core seems to make sense.

>- on core routers, if RH0 are not processed as a result of  
>deprecation/deactivation, this prevents their use for bouncing RH0  
>traffic: this also makes the Hop Limit an effective mean for limiting  
>things too as the average distance between 2 possible waypoints (non  
>compliant / unpatched) will be far higher than at the moment.
>
>In worst case scenario, an attacker could use 2 leaves in the network  
>(i.e. in a single ISP network) and locally wastes some bandwidth.  
>Basically, this will motivate the network operator to implement  
>ingress filtering ;-)
>
>As deprecation also guarantees attackers won't be able to target  
>service on compliant hosts, only unpatched/unfiltered ones will  
>undergo attacks (in worst case scenario).
>
>Cheers,
>
>a+
>
>-- Arnaud Ebalard
>EADS Innovation Works - IT Sec Research Engineer
>PGP KeyID:047A5026 FingerPrint:47EB85FEB99AAB85FD0946F30255957C047A5026
>
>
>
>--------------------------------------------------------------------
>IETF IPv6 working group mailing list
>ipv6@ietf.org
>Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
>--------------------------------------------------------------------

Best Regards,

Tim Enos
Rom 8:28


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------