Re: [Mip6] Review of draft-irtf-mobopts-ro-enhancements-00.txt

Francis Dupont <Francis.Dupont@enst-bretagne.fr> Tue, 07 June 2005 10:39 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfbUP-00069e-KC; Tue, 07 Jun 2005 06:39:21 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfbUK-00069V-5L; Tue, 07 Jun 2005 06:39:20 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08884; Tue, 7 Jun 2005 06:39:13 -0400 (EDT)
Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfbpM-0007Vp-2a; Tue, 07 Jun 2005 07:01:00 -0400
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j57Ad0W03768; Tue, 7 Jun 2005 12:39:00 +0200
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j57Ad0Xt021018; Tue, 7 Jun 2005 12:39:01 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200506071039.j57Ad0Xt021018@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: James Kempf <kempf@docomolabs-usa.com>
Subject: Re: [Mip6] Review of draft-irtf-mobopts-ro-enhancements-00.txt
In-reply-to: Your message of Thu, 26 May 2005 16:02:22 PDT. <0abd01c56246$fe2927f0$016115ac@dcml.docomolabsusa.com>
Date: Tue, 07 Jun 2005 12:39:00 +0200
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
X-Spam-Score: 2.4 (++)
X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196
Cc: mip6@ietf.org, mobopts@irtf.org
X-BeenThere: mip6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: mip6.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mip6>, <mailto:mip6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mip6@ietf.org>
List-Help: <mailto:mip6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mip6>, <mailto:mip6-request@ietf.org?subject=subscribe>
Sender: mip6-bounces@ietf.org
Errors-To: mip6-bounces@ietf.org

 In your previous mail you wrote:

=> I agree with your main comment, for instance the security of RR
was already well analyzed and should not be reproduced in the document.
   
   Section 2.0: I believe Pekka Nikander has a MIP6 WG draft
   (draft-ietf-mip6-ro-sec-02.txt) that discusses many of the issues that are
   discussed in this and subsequent sections. This draft should be referenced
   somewhere here.
   
=> the example itself (:-).

   Section 2.3, 2nd last para: I was looking here for the standard "ingress
   filtering will handle redirection-based DoS attacks" here, and the
   refutation of why that isn't practical. It might be useful to put in a
   forward reference, since it is dealt with later in the paper.
   
=> note that my argument about the ingress filtering is not this one.

   Section 3.2, end of 1st para: The impact on the core Internet of
   bidirectional tunneling is actually quite minimal given the amount of dark
   fiber left over from the Boom. It has been estimated that less that 10% of
   the cross-continent fiber in North America is lit, and the number is
   probably similar for intercontinental and other long distance links in other
   countries.

=> soem kind of "the Internet is ultra-metric" argument?
(d(A,B) + d(B,C) = d(A,C))
   
   Section 3.2, 6th para: This paragraph misses the issue of CRL checks. These
   could be a significant issue when using certificates for route optimization
   security.
   
=> note the CRL check issue is a property of some PKIs, including X.509
as it should be used...

   Section 3.2, 9th para: In my mind, the primary argument against depending on
   ingress filtering is that there is no incentive - financial, regulatory, or
   legal - for ISPs to deploy it.

=> as you said after this is true for any global Internet security device.

   A diligent ISP will of course do so, but a
   corrupt ISP might even have a financial incentive to not deploy it, if
   redirection-based DoS attacks using route optimization ever become possible
   and are exploited for financial gain. This has been an issue with spam, for
   example. I think something to that effect needs to be said. While some
   people might be offended by this, the need for security in the Internet
   results from the fact that, lacking any incentives to the contrary, some
   people will do bad things if they can get away with it and it can result in
   financial gain. Most discussions of security ignore this basic fact of human
   nature, and treat the problem like solar physics or something.
   
=> I fully agree but your argument works only against the "ingress
filtering will save MIPv6" thesis, not against my "without ingress
filtering we have no defense against flooding attacks with or without
MIPv6". The current situation unfortunately supports mine with the
everyday DDoS attacks using "botnets", and if today the issue is for
IPv4, IPv6 is a worse case because the lack of support for ingress
filtering BCPs (with a plural because BCP84/RFC3704 is more critical
for the IPv6 way to support multi-homing).

   The argument you advance
   later in the paper that the attacker can still mount an attack on the subnet
   is irrelevent. An attacker can do that without using route optimization, by
   creating a zombie and programming it to iterate through non-existant
   addresses in the victim subnet.
   
=> note this is in fact an instance of my argument in favor of
the ingress filtering!

   Section 6.3.2: final, all-encompassing method -> widespread method
   Actually, I disagree with this conclusion. I think the current crop of
   limited applicability RO security protocols are likely to die from lack of
   implementation and interest and a next gen protocol, possibly including CGA
   and CBA, that is widely applicable and a big improvement on RR is likely to
   have more success.
   
=> I don't know: when I ask friends about their interest into RO deployment
(I control the implementation point :-), the two common concerns are the
lack of security of RR and the complexity of CN code. There are some
limited applicability ROs which answer to both but they have limited
applicability... I believe CGA or something equivalent (but without CBA
which gives nothing real in exchange of its extra complexity) is the
last chance of RO, but do we need RO?

   Section 6.3.2: One issue that I've never really seen dealt with is whether
   or not RO is really needed.

=> this is the question we should not ask because we are afraid of its
possible answer (:-).

   Nobody has measured this. Skype seems to get by
   with lots of indirect routes For example, our experiments show that when we
   make a Skype call from one node in our San Jose lab to another, it goes
   through a supernode in Europe, yet the quality of the call is fine.
   Everybody seems to be assuming this is a problem, but nobody seems to have
   set up a network and actually measured whether it is *really* a problem,
   with MOS scores, etc.
   
=> bi-tunneling has still good security properties: it can be made very
secure (encrypt everything) and provide location privacy. Perhaps we
should put our effort on the basic MIPv6/NEMO support. I believed there
was no good business cases for MIPv6, mainly because computers are not
designed to be mobile, and smaller devices worked better without IP.
But today I believe MIPv6 is better than depending in WLAN & co security:
 + unified framework
 + easy vertical handoff support
 + good performance on handoffs (.5 RTT vs re-auth nightmare)
 - no DoS protection but 802.11i for instance has none too...
has 3GPP2 already what I am thinking to?

Regards

Francis.Dupont@enst-bretagne.fr

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