Hierarchical Mobile IPv6 Mobility Management (HMIPv6)
RFC 4140

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 -)
No email
send info
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 


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 -)
No email
send info
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.

(Bert Wijnen) No Objection

(Alex Zinin) No Objection