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
- [Mip6] Review of draft-irtf-mobopts-ro-enhancemen… James Kempf
- Re: [Mip6] Review of draft-irtf-mobopts-ro-enhanc… Francis Dupont
- Re: [Mip6] Review of draft-irtf-mobopts-ro-enhanc… James Kempf
- Re: [Mip6] Review of draft-irtf-mobopts-ro-enhanc… Francis Dupont
- Re: [Mip6] Review of draft-irtf-mobopts-ro-enhanc… Christian Vogt