[Mip6] Review of draft-irtf-mobopts-ro-enhancements-00.txt
"James Kempf" <kempf@docomolabs-usa.com> Thu, 26 May 2005 23:01 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbRLu-0001NF-HZ; Thu, 26 May 2005 19:01:22 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbRLs-0001N6-TN for mip6@megatron.ietf.org; Thu, 26 May 2005 19:01:21 -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 TAA22084 for <mip6@ietf.org>; Thu, 26 May 2005 19:01:17 -0400 (EDT)
Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbReY-0001G0-89 for mip6@ietf.org; Thu, 26 May 2005 19:20:39 -0400
Message-ID: <0abd01c56246$fe2927f0$016115ac@dcml.docomolabsusa.com>
From: James Kempf <kempf@docomolabs-usa.com>
To: mip6@ietf.org, mobopts@irtf.org
Date: Thu, 26 May 2005 16:02:22 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 2.4 (++)
X-Scan-Signature: 3f3e54d3c03ed638c06aa9fa6861237e
Content-Transfer-Encoding: 7bit
Cc:
Subject: [Mip6] Review of draft-irtf-mobopts-ro-enhancements-00.txt
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
Raj requested I review this draft. Here is my review. jak ----------------------- Editorial meta-comment: While I found the draft to be very good, it is quite long, and I think it could be improved by dropping some parts that are superficial and not relevent to the basic theme. For example, Sections 5.13 through 5.17, Section 6.2.1, and some material in Section 6.3 on the same topics. These sections all talk about handover optimizations schemes that do not involve improvements in the basic Mobile IPv6 route optimization algorithm and its security, return routability, which is the basic theme of the document. There is a very extensive academic literature on HMIP, FMIP, and other local optimizations for Mobile IP handover, and none of this has been cited or reviewed in this draft. Removing the material on this would help to focus and shorten the draft. Specific comments: page 6: lightway and does not -> lightweight and does not page 6: "On the other hand, the return routability procedure usually consumes one round-trip time" - The number I've seen cited is 1.5 RTT on the average. 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. 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. 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. There is of course still an issue with access networks, but the real impact of always tunneling through the home agent is on RTT latency. This is sometimes known as "the two Japanese in America" problem, where two people from Japan come to America, and call each other through their Mobile IP home agents back in Japan. Section 3.2, begining of the 2nd para: I'm not clear what the relationship between the CN and authorization for a home address has to do with deployment of route optimization. There is an even more basic issue, that is that modifications for route optimization which utilize end-to-end signaling require that every CN in the IPv6 Internet support them. While we are yet far away from widespread deployment of IPv6, the longer such end-to-end optimizations are delayed, the less likely that every CN will support them. Section 3.2, 3rd para: and so does without -> and does so without Section 3.2, 5th para: The preconfigured keys draft should be cited here. 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. 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. 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. Section 3.2, 10th para: This section loses sight of the fact that malware installed surreptitiously on a host may compromise it even if the host has a trust relationship with the home agent service provider. The issue is not the trust relationship but rather that the home agent service provider has a record of who the user is and can cut them off if they start behaving badly. Now how the home agent service provider is supposed to detect whether or not a particular host is behaving badly is another story. Section 3.3, 1st para: against the tree -> against the three Section 3.3, 3rd para: This said -> That said Section 3.3, 4th para: But here again could the attacker launch -> But here again, the attacker can launch Section 3.3, 5th para: that is called "space-and-time shift attacks" -> that is called a "space-and-time-shift attack" for a better point of time -> for a better point in time Section 4.1, 2nd para: This isn't clear. If the MN sends a BU to the CN, then it isn't a round trip, it's one way. I'm assuming here that the text isn't including the HoTI/HoT, CoTI/CoT in that calculation. If so, then I think the average would be 2 RTs, 1.5 for the RR signaling and 0.5 for the BU. Section 4.2, 3rd & 4th para: I've never been convinced that a mobile node would want to keep optimized routes hot while it was in dormant mode, and this example doesn't convince me either. Route optimization helps with RTT latency, and such latency is an issue primarily in real time traffic. The example given here, a messaging server (presumably IM), is a store and forward system that will derive little benefit from keeping routes hot during optimization. Even for real time traffic, like VoIP, the CN still has to do SIP signaling to initiate the connection, and while there is some amount of urgency to the signaling above a store and forward application, it still is not going to suffer if the traffic is routed through the home agent. The latency involved in initiating the IP connection with the dormant mode mobile node through paging is likely to exceed any benefit from keeping optimized routes hot. Section 4.3, 1st para: lightway -> lightweight In some cases, however, may better security be useful -> ???? Section 4.3, 2nd para: mobility management can the Internet as whole not -> mobility management, the Internet as a whole can not Section 5, meta comment: One issue the entire document has ignored is route optimization for mobile networks. As noted above, since end to end route optimization technquies require support in every IPv6 node, a host-based route optimization technique that is adopted for next-gen MIPv6 but doesn't support mobile networks may preclude widespread use of route optimization for mobile networks because it might be difficult to get the support in a broad enough collection of IPv6 nodes. Section 6.3.2, paragraph 1 makes the argument that the current set of new RO techniques is likely to be directed at specific usage scenerios, but I'm not so sure that's likely to be the case. Section 5, para 1: many enhancements techniques -> many enhancement techniques Section 5, para 1: Are the tradeoffs between universal applicablity v.s. efficiency discussed in this paper anywhere? This would be the ideal paper to have the discussion. Section 5.1, para 2: IP-ddress -> IP-address can anyway do without route optimization -> can do without route optimization anyway Section 5.1, para 3: Again, I've heard 1.5 RTT for this. Section 5.2, para 1: same problem as in 5.1 para 2 Section 5.4, para 1: I've never heard the term "critical phase" used. Section 5.4, para 2: One issue raised earlier in the paper was the frequency of signaling. Here, it seems to be advocating doing a home address test every 3.5 mintues regardless of whether movement is immanent or not. This seems a contradiction. anyway re-initiate the correspondent registration -> re-initiate the correspondent registration anyway Section 5.5, para 2: Later in the paper, you discuss this, but the statistical uniqueness properties of CGAs suggest that the care-of test might not be needed since the probability of another node having exactly the same interface identifier is fairly low. I think you should state that here. It is the same tradeoff that optimistic DAD makes. 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. Section 5.6, para 1: until it has been told about this -> until it has been told. are usually lost and must be transmitted -> are usually lost and must be retransmitted Section 5.7: I think it might be worthwhile to include a paragragh describing how the mobile node's credit is measured. I recently attempted to construct a bandwidth measuring algorithm and found it not so simple. There are probably very simple ways to do it, but I think they may not be obvious to the casual reader. Section 5.7, para 5: Thus, its is the -> Thus, it is the Section 5.7, para 5.7: I wonder if the Spot Check tokens aren't a potential state depletion threat. Since they are essentially per flow state, an attacker could iterate creating a bunch of flows until the victim's Spot Check token storage was exhausted. Section 5.8, para 2: it in general hard -> it is in general hard Actually, I think it is impossible for the correspondent to know that two home addresses are from the same node unless the interface identifier is the same. The interface identifier is what is used for routing on the last hop link, and so only it will determine if two packets with destination addresses known to be home addresses and the same subnet prefix go to the same node. Section 5.9, para 4: RFC 3972 describes how to compute CGAs such that an attacker can't claim ownership. It used the said subnet prefix trick, and should probably be cited. Section 5.10: This section seems to imply that the CoA test can be eliminated with preconfiguration, but I think that is too optimistic. Even if two nodes that trust each other initially are preconfigured, subsequently one or the other can be infected with malware without the owner knowing and become untrustworthy. Section 6.2.2, para 2: The assumption that mobile nodes are fair-minded turns out to be quite far stretching. -> ?????? from figure Figure 1, -> from Figure 1, and a trust relationship for misuse prevention -> and an address authorization for misuse prevention Section 6.2.2, para 4: These things said, -> That said, protocol bendable to different -> protocol customizable to different Section 6.2.3: Here is the discussion of statistical uniqueness and its effect on the need for the CoA test. The point about network attacks in the 2nd para is really irrelevant, as noted above. Section 6.2.4, 4th para: that mobility-managment protocols -> that these mobility-management protocols Section 6.2.4: Can CBA somehow get rid of the need to re-authorize every 7 minutes? If the MN is building credit, then perhaps it doesn't need to re-authorize because its ability to attack is limited by the credit. Of course, the issue of the home address test would have to be addressed too, but I think it worthwhile to explore this, since the signaling overhead of RR is onerous. Section 6.3.1: This section could be removed too. 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. Section 6.3.2: One issue that I've never really seen dealt with is whether or not RO is really needed. 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. _______________________________________________ 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