[Mip6] review of draft-dupont-mipv6-3bombing-00.txt

Jari Arkko <jari.arkko@kolumbus.fi> Mon, 16 February 2004 01:41 UTC

Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07385 for <mip6-archive@odin.ietf.org>; Sun, 15 Feb 2004 20:41:26 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsXkn-00069f-UJ for mip6-archive@odin.ietf.org; Sun, 15 Feb 2004 20:40:58 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1G1evvn023655 for mip6-archive@odin.ietf.org; Sun, 15 Feb 2004 20:40:57 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsXkn-00069S-N2 for mip6-web-archive@optimus.ietf.org; Sun, 15 Feb 2004 20:40:57 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07368 for <mip6-web-archive@ietf.org>; Sun, 15 Feb 2004 20:40:55 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsXkl-0007du-00 for mip6-web-archive@ietf.org; Sun, 15 Feb 2004 20:40:55 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsXjo-0007aT-00 for mip6-web-archive@ietf.org; Sun, 15 Feb 2004 20:39:57 -0500
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AsXiw-0007XG-00 for mip6-web-archive@ietf.org; Sun, 15 Feb 2004 20:39:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsXiv-00063z-0T; Sun, 15 Feb 2004 20:39:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsXin-00063g-LM for mip6@optimus.ietf.org; Sun, 15 Feb 2004 20:38:53 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07318 for <mip6@ietf.org>; Sun, 15 Feb 2004 20:38:51 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsXil-0007W1-00 for mip6@ietf.org; Sun, 15 Feb 2004 20:38:51 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsXhp-0007St-00 for mip6@ietf.org; Sun, 15 Feb 2004 20:37:54 -0500
Received: from fep20-0.kolumbus.fi ([193.229.0.47] helo=fep20-app.kolumbus.fi) by ietf-mx with esmtp (Exim 4.12) id 1AsXhE-0007QC-00 for mip6@ietf.org; Sun, 15 Feb 2004 20:37:16 -0500
Received: from kolumbus.fi ([62.248.154.14]) by fep20-app.kolumbus.fi with ESMTP id <20040216013708.BHLD15980.fep20-app.kolumbus.fi@kolumbus.fi>; Mon, 16 Feb 2004 03:37:08 +0200
Message-ID: <40301E53.2090004@kolumbus.fi>
Date: Mon, 16 Feb 2004 03:35:15 +0200
From: Jari Arkko <jari.arkko@kolumbus.fi>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
CC: mip6@ietf.org
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Mip6] review of draft-dupont-mipv6-3bombing-00.txt
Sender: mip6-admin@ietf.org
Errors-To: mip6-admin@ietf.org
X-BeenThere: mip6@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mip6>, <mailto:mip6-request@ietf.org?subject=unsubscribe>
List-Id: <mip6.ietf.org>
List-Post: <mailto:mip6@ietf.org>
List-Help: <mailto:mip6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mip6>, <mailto:mip6-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hi Francis,

And thanks for writing this draft. I think we need it.

I pretty much agree with all that you say in the draft. I think
prohibiting alternate care-of address option is a good idea,
and it should be studied further.

I'd like to expand a little bit on what you say in under
2.3 regarding route optimization.

As you have pointed out, anyone can spoof the source address
of a TCP SYN packet, so we generally can not worry too much
single request - single response attacks. Except where mechanisms
to defeat ingress filtering are provided, which you also mention.

As Christian pointed out in his e-mail explaining the security
background for early binding updates, and is also discussed in
Section 2.5 of [1], we also need to consider the possible
amplification factor. The problem with bombing attacks in the
RO case is using first a right address, getting to see TLP sequence
numbers so that fake acks can be sent, and then moving
the stream to the victim's address. This can be devastating,
at least under some conditions. The difference to a regular
TCP SYN spoofing is that you actually get to see some
inital part of the traffic, which may make things easier
for the attacker. Having said this, [1] notes that different
TLPs and different TCP implementations behave in different
ways regarding this attack. It might be useful to shed
some further light on this, to figure out exactly how
serious (or not) this attack is.

There is a related issue that has to do with the level
of ingress filtering support in the Internet. We have
more or less accepted the situation where this support
is not universal. So, we can assume that we can be targets
of e.g. spoofed TCP SYNs or reflected packets. I would
not like to make this any worse by making it possible to
be a victim of a stream of packets.

Comments?

--Jari

[1] http://www.arkko.com/publications/draft-aura-mipv6-bu-attacks-01.txt



_______________________________________________
Mip6 mailing list
Mip6@ietf.org
https://www.ietf.org/mailman/listinfo/mip6