[Mobopts] Review of draft-irtf-mobopts-ro-enhancements-00.txt

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.

_______________________________________________
Mobopts mailing list
Mobopts@irtf.org
https://www1.ietf.org/mailman/listinfo/mobopts