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

Jeroen Massar <jeroen@unfix.org> Thu, 10 May 2007 14:57 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 1HmA4j-000799-E8; Thu, 10 May 2007 10:57:01 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmA4i-000791-Ln for ipv6@ietf.org; Thu, 10 May 2007 10:57:00 -0400
Received: from purgatory.unfix.org ([2001:7b8:20d:0:290:27ff:fe24:c19f]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmA4h-00010e-1R for ipv6@ietf.org; Thu, 10 May 2007 10:57:00 -0400
Received: from [IPv6:2001:770:100:9e::2] (cl-159.dub-01.ie.sixxs.net [IPv6:2001:770:100:9e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by purgatory.unfix.org (Postfix) with ESMTP id 1B326140C356; Thu, 10 May 2007 16:56:58 +0200 (CEST)
Message-ID: <464332BA.9060001@spaghetti.zurich.ibm.com>
Date: Thu, 10 May 2007 15:56:58 +0100
From: Jeroen Massar <jeroen@unfix.org>
Organization: Unfix
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666
MIME-Version: 1.0
To: Pekka Savola <pekkas@netcore.fi>
References: <31D43DED-5BEE-4730-8FCB-476FA9EE1A97@eads.net> <46432309.1020902@innovationslab.net> <46432F3F.8010400@spaghetti.zurich.ibm.com> <Pine.LNX.4.64.0705101747290.30965@netcore.fi>
In-Reply-To: <Pine.LNX.4.64.0705101747290.30965@netcore.fi>
X-Enigmail-Version: 0.95.0
OpenPGP: id=333E7C23
X-Virus-Scanned: ClamAV 0.90.2/3225/Thu May 10 10:08:21 2007 on purgatory.unfix.org
X-Virus-Status: Clean
X-Spam-Score: -2.8 (--)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
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>
Content-Type: multipart/mixed; boundary="===============0857037320=="
Errors-To: ipv6-bounces@ietf.org

Pekka Savola wrote:
> 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 :-)

Oops, forgot about that indeed. uRPF resolves that concern already :)

I do also have it noted here that folks should do BCP38 properly:
 http://www.sixxs.net/faq/connectivity/?faq=filters

As such, maybe include an extra reference and heavy lined note to BCP38?

Also, maybe force vendors to enable BCP38 per default by making it a MUST?

Greets,
 Jeroen


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