Subject: RE: [Mipshop] IESG evaluation - John Loughney's comments

From: [email-masked]
Date: Wed, 22 Sep 2004 15:14:13 +0300

Hi Hesham,

These comments were part of a General Area review.  I noticed that
Harald did not issue a DISCUSS, so take all of my comments as
suggestions - you are not required to do anything for them.

> Thanks for the comments. Comments and responses 
> below.
> 
> >	Reviewed by John Loughney, Gen-ART
> 
> => BTW, what's GEN-ART?

Harald has a small review team for doing General Area Review
(General Area Review Team - Gen-ART).
 
> >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.
> 
> => Not sure what you mean. These features are supported by the spec
> regardless of its status. I don't think we should be making 
> less claims unless there is a reason to do so.

This is an experimental protocol, and generally, experimental protocols
are experimental because we need to have some more hands-on experience
with them before recommending deployment.  Therefore, I work from the
assumption that claims shouldn't be made in experimental documents, but
something along the lines of 'HMIP may be able to provide location privacy'
as opposed to 'HMIP is good at providing location privacy.'  Again, as
we are seeking deployment experience with experimental protcols, I am
concerned about claims.
 
> >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.
> 
> => One. At most two.

It might be good to be more explicit about this as I had a hard time
understanding this.
 
> >3) How does the MN know that MAP is trustworthy?  
> 
> => This is explained in section 12.
> 
> >What if a MAP is being run by a really
> >  bad guy, isn't this a new potential man-in-the-middle attack?
> 
> => There is always a potential MITM attack with any protocol.
> In HMIPv6 this is mitigated by the use of strong authentication
> with IPsec and IKE. Please see section 12 and let us know if 
> there are specific comments on that.

I can live with Section 12.
 
> >General comments:
> 
> >1) Abstract should say what benefit HMIP brings.  Reading 
> the abstract, I don't
> >  get any the purpose of HMIP.
> 
> => The current abstract says:
> 	This document introduces extensions to Mobile IPv6 and 
> IPv6 Neighbour Discovery to 	allow for local mobility 
> handling. Hierarchical mobility management for Mobile IPv6 	
> reduces the amount of signalling between the Mobile Node, its 
> Correspondent Nodes and 	its Home Agent. The Mobility 
> Anchor Point described in this document can also be used 	
> to improve the performance of Mobile IPv6 in terms of handover speed.
> 
> Hence, the benefits are reduced signalling and assistance with the handover
> performance. There are more benefits like some location privacy and
> use of RCoA as a src. Is this what you want us to add? I have no 
> problem with adding that. However, this seems to contradict your 
> first major comment.

Well, I'm comfortable if you can tweak the introduction to include your
explaination, which the proper perspective. Something like:

 HMIP tries to reduce signalling and improve with the handover
 performance. Other potential benefits are location privacy and use of RCoA as a
 src. 

Or something like that.

> >2) Should put MN in the terminology section
> 
> => ok
> 
> >3) MAP is alternatively called a Node and a Function - which is it?
> 
> => The MAP function is located in a router, which is a node.
> RFC 3775 defines a HA as follows:
> 
> home agent
> 
>       A router on a mobile node's home link with which the mobile node
>       has registered its current care-of address.  While the mobile node
>       is away from home, the home agent intercepts packets on the home
>       link destined to the mobile node's home address, encapsulates
>       them, and tunnels them to the mobile node's registered care-of
>       address.
> 
> A router can include many functions, the HA/MAP is one of them.

So, a MAP is a function inside a node, not a node itself. 

> >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? 
> 
> => Yes.
> 
>     I assume that the MN is behind
> >  the MAP, so the MN is really hidden, but more likely obscured ...
> 
> => I really don't understand what this means. Please elaborate.

Does a CN would know you are behind a specific MAP? If so, then you
don't have real location privacy. If not, then I am missing something.
 
> >5) Probably want to define MAP domain.
> 
> => In section 3 (overview section) the following text defines
> the MAP domain:
> 
> 	A MAP domain's boundaries are defined by the Access 
> Routers (ARs) advertising the MAP 	information to the 
> attached Mobile Nodes. 
> 	The detailed extensions to Mobile IPv6 and operations 
> of the different nodes will be 	explained later in this 
> document.
> 
> This is repeated elsewhere in the spec. 

I meant define it upfront in the document.
 
> >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
> 
> => No it's not more common than the HA. Having a node being 
> compromised is just as likely. In fact, the permanence of the
> relationship between the MN and a HA (in case of preconfig SAs) 
> makes compromising the HA much more dangerous. I don't think
> this text should be added. Compromising any node is dangerous
> and is a threat to any protocol, so it's not specific to this
> case.

What I meant to say is that a MN may see more MAPs than HAs, especially
if the MN travels to many places.  Therefore, encountering new
MAPs raises the potential threat, IMO.

John

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

---

From: "Soliman, Hesham" <[email-masked]>
Date: Wed, 22 Sep 2004 09:57:17 -0400

> we are seeking deployment experience with experimental protcols, I am

=> Ok, I'll see if these can be clarified. Some of the claims
are quite stright forward, like signalling reduction. I'll 
look at it again to see if it's too strong. 

 >  performance. Other potential benefits are location privacy 

=> ok.

 > So, a MAP is a function inside a node, not a node itself. 

=> Sure. Just like an HA, MR, FA, OSPF, or any other IP function.

 > don't have real location privacy. If not, then I am missing 

=> The CN doesn't know anything about the existence of a MAP.
Think of it in the same way as a CN talking to a MN without using
RO. It would have no idea where the MN is.

 > MAPs raises the potential threat, IMO.

=> Right, I don't really agree because the MN also encounters
many other nodes and hosts, any of which can be compromised.
So I see this as a general issue.

Hesham

 > John

===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is strictly
 prohibited.  If you are not the intended recipient please contact the sender
 and delete all copies.
===========================================================

---

From: [email-masked]
Date: Wed, 29 Sep 2004 16:52:18 +0300

Hi Hesham,

I think you've addressed my concerns here, so I'm OK with all of your answers.

thanks,
John

> -----Original Message-----
> From: ext Soliman, Hesham [mailto:[email-masked]]
> Sent: 22 September, 2004 16:57
> To: Loughney John (Nokia-NRC/Helsinki)
> Cc: [email-masked]
> Subject: RE: [Mipshop] IESG evaluation - John Loughney's comments
> 
> 
>