AD review of mipshop-4140bis
Jari Arkko <jari.arkko <at> piuha.net>
2008-01-16 15:35:53 GMT
I have made my AD review of this document. Please find detailed comments
below.
Overall, I was pleasantly surprised by this specification. It is in
relatively good shape and while there are issues, there are generally
minor and mostly solvable by removing the offending parts. I was happy
with the security parts. The main issues that I have are the flooding
scheme and the error recovery parts.
I expect some discussion and a new draft revision. After that we can go
to IETF Last Call.
Technical:
> This specification allows a mobile node to use more than one RCoA if
> it received more than one MAP option. In this case, the mobile node
> MUST perform the binding update procedure for each RCoA.
This MUST seems overly strong. Why would the mobile node be forced to
use more than one MAP, if it only wanted to use one? See also further
below where some inconsistencies with the above have been detected.
> Note that a mobile node may send a BU containing its LCoA (instead of
> its RCoA) to correspondent nodes, which are connected to its same
> link. Packets will then be routed directly without going through the
> MAP.
How does this happen? If two nodes sit on the same link and employ
MAP(s) and home agent(s), they will only see each other's RCoAs and/or
HoAs. They would see each other's care-of addresses when route
optimization is attempted. But per your specification above you may not
attempt it with your local address unless you already know the other
node is on the same link. Chicken and egg...
Suggestion: do not restrict the type of address the nodes may use in
route optimization.
> Upon reception of a router advertisement with the MAP option, the
> receiving router MUST copy the option and re-send it after
> incrementing the Distance field by one.
I hope you do not mean re-sending every RA again on another interface,
triggered by the reception. This would disturb the router's own timing
and processing of RAs. Please clarify the text to indicate that the
received RAs are only used for learning the information, and then the
information is used in the router's own independent RA sending process.
> The MAP option is propagated towards ARs in its domain.
I'm not convinced that the dynamic distribution of MAP information is
useful. First of all, its a very small configuration task compared to
some of the other things you would have to have in this environment
(e.g., security policies and key material allowing each mobile node to
talk to each MAP securely).
Secondly, you seem to be assuming that the MAP is placed in the router
hierarchy. I would actually expect that a local domain's MAP would be
placed in the same network as other servers and services exists, not
necessarily in the aggregated router hierarchy that leads to the
Internet. This would imply that a MAP RA would have to be distributed
not just "down" but also "sideways" or even "up" if you draw the router
placement in the network in a hierarchical manner. Of course, you can
configure the routers to do this. But at the end of the day, you've
created a complicated flooding scheme to achieve very little. And there
may be error modes that we have not thought of.
I would suggest removing the support for dynamic distribution, and
simply requiring ARs to be configured with this information.
> A mobile node MUST store the received option(s) in order to choose at
> least one MAP to register with. Storing the options is essential, as
> they will be compared to other options received later for the purpose
> of the movement detection algorithm.
>
The "at least one" part is right, in my opinion. But it is inconsistent
with what I quoted earlier: "MUST perform the binding update procedure
for each RCoA"
> If no MAP options are found in the router advertisement, the mobile
> node MUST use the Mobile IPv6 protocol, as specified in [1 <http://tools.ietf.org/html/draft-ietf-mipshop-4140bis-01#ref-1>].
>
Hmm. I think MUST NOT use HMIP would be more appropriate within the
specification of how to deal with MAP options. You are assuming that
whoever implements your spec will also implement and be able to use
Mobile IPv6 (including, for instance, having a home agent).
> 10. Detection and Recovery from MAP Failures
Paragraph 1 is good, but the rest seems suspect. For instance, on a
large domain having every AR send this many pings to the MAP would by
itself create a problem. And I am not sure this document should be
dictating a specific mechanisms where service provider infrastructure
keeps aware of what's up and what's not. I would suggest removing
everything else except the ability of mobile nodes to react to zero
lifetime. Or perhaps even that could be removed, if you simply
recommended that if routers become aware of inability to reach the MAP,
the MAP option is deleted from RAs.
Editorial:
Please correct the issues from
http://tools.ietf.org/wg/mipshop/draft-ietf-mipshop-4140bis/draft-ietf-mipshop-4140bis-01.nits.txt
> It is pertinent to note that the use of the MAP does not reply or
> assume that a permanent Home Agent is present.
s/reply/rely/
> The mobile node can communicate with a correspondent node through the
> HA, or in a route-optimised manner, as described in [1
<http://tools.ietf.org/html/draft-ietf-mipshop-4140bis-01#ref-1>]. When
> communicating through the HA, the message formats in [1
<http://tools.ietf.org/html/draft-ietf-mipshop-4140bis-01#ref-1>] can be re-
> used.
s/can be re-used/are used/
> This specification does not provide an algorithm
> for the distance-based MAP selection. However, such an algorithm may
> be introduced in future extensions utilising information about the
> speed of mobility from lower layers.
>
> ... The following algorithm is simply based on selecting the
> MAP that is most distant, provided that its preference value did not
> reach a value of zero. The mobile node operation is shown below:
>
> 1. Receive and parse all MAP options
An apparent inconsistency. Do you provide a distance-based algorithm or
not? Note that there might be different algorithms, better/perfect,
etc., but that was not what the text was claiming.
> This is achieved by using the RCoA as the identity in IKE Phase 2
> negotiation. This step is identical to the use of the home address
> in IKE phase 2.
>
I think you mean child SA creation, not phase 2. Phase 2 was an IKEv1
concept. I see that Vijay noted this as well in his review.
Jari
RSS Feed