Hierarchical Mobile IPv6 Mobility Management (HMIPv6)
Note: This ballot was opened for revision 04 and is now closed.
(Steven Bellovin) Discuss
Discuss (2004-11-12 for -)
The Security Considerations section says: It is crucial that the security relationship between the mobile node and the MAP is of strong nature; it MUST involve mutual authentication, but there is no hint of how this can be done. In particular, how does the mobile node know that the MAP is *authorized* for that role? This is much worse than the ordinary MIPv6 situation, since in the normal case you're dealing with an on-link forwarder where the added risk is low. (The risk is high, but the added risk from MIP is low, and SEND helps with the normal risk -- but not for this.) I don't expect a solution in this document, but the problem needs to be discussed. I believe there's some good text in one of the SEND documents that can be used. Let me spell out the authorization issue a bit more. The RA message tells you what the MAP is. If you believe the RA is genuine, you can presumably believe the pointer; as you note, SEND can help here, but the Security Considerations needs to point that out. Beyond that, though, you still have a problem: how does the MN know what sort of certificate chain to expect for the MAP? It will have a certificate, of course, but anyone can create arbitrary certificates; I do that all the time. The certificate chain needs to be rooted in some trust anchor that the MN accepts. (This was an issue for SEND, too -- when I sit down in my local hotspot, how do I know the certificate for the RA is for the real router and not my evil neighbor's laptop.) This problem needs to be discussed, and is discussed in the SEND draft. Beyond that, the document also says "the MAP does not need to know the identity of the mobile node". This contradicts the previous statement about mutual authentication. I believe I know what they mean, but it isn't clearly enough expressed in the document. The problem here is the converse of the earlier point: how does the MAP know that it's talking to the "right" MN? You can't authenticate someone if you have no a priori knowledge of whom they should be. Do you mean "the same as last time"? "Someone whom I've authorized via AAA"? You say "no prior knowledge", and that's fine, but then you need to clarify how the MAP can authenticate such a party.
(Thomas Narten) Yes
(Harald Alvestrand) No Objection
Comment (2004-09-16 for -)
Reviewed by John Loughney, Gen-ART His review: I would be tempted to place a discuss on this draft, see the Major comments section. However, this is an experimental protocol, so I'm not sure how strict we should be on it. I think this is a useful protocol for the Internet, but it should be experimental. I think I am most concerned about the security point below. Major comments: 1) Lots of claims in this document, location privacy, benefits of reduced signaling, improvements in performance, etc. - are these really appropriate for an experimental draft? I'd probably prefer to see this kind of text softened. 2) I have concerns about the scalability of security arrangements between the MN & MAP. How many potential MAPs might a MN need to have a relationship with. 3) How does the MN know that MAP is trustworthy? What if a MAP is being run by a really bad guy, isn't this a new potential man-in-the-middle attack? General comments: 1) Abstract should say what benefit HMIP brings. Reading the abstract, I don't get any the purpose of HMIP. 2) Should put MN in the terminology section 3) MAP is alternatively called a Node and a Function - which is it? 4) HMIP claims: "Furthermore, HMIPv6 allows mobile nodes to hide their location from correspondent nodes and Home Agents while using Mobile IPv6 route optimisation." Does it really? I assume that the MN is behind the MAP, so the MN is really hidden, but more likely obscured ... 5) Probably want to define MAP domain. 6) Section 3.1. HMIPv6 Operation - might want to put forward section references to thinks like MAP discovery, etc. 7) Security Considerations might want to point out that HMIP would suffer if a MAP is compromised. I guess the threat might be more common than if a Home Agent is compromised, as there is not a pre-existing relationship Nits 1) Some formatting problems in 11. IANA Considerations
(Margaret Cullen) No Objection
(Bill Fenner) No Objection
(Sam Hartman) (was Discuss) No Objection
(Scott Hollenbeck) No Objection
(Russ Housley) (was Discuss) No Objection
(David Kessens) No Objection
(Allison Mankin) No Objection
Comment (2004-09-16 for -)
Normative reference to Router Renumbering has the RFC wrong; it's 2894, not 2984. Almost a Discuss: MAP "discovery" by Router Renumbering is MAP configuration distribution, but the grafting of the MAP information onto the RR seems plain wrong: RR's protocol is for instructions to propagate prefixes from a boundary, not to distribute other information that routers can propagate in RAs. This extension of RR also seems inappropriate to HMIP given that HMIP is Experimental, so it is probably best to use it manually. Also HMIP is meant to be used with quite a local domain, and RR can't ensure that the propagation will stay in a low-latency, local environment. (Stated goal of HMIP: "The MAP will limit the amount of Mobile IPv6 signalling outside the local domain.") This Experimental protocol should drop its use of the extension of RR in its experimental phase.