[Mobopts] FW: draft-weniger-mobopts-mip6-cnlocpriv-01.txt

[Rajeev Koodli <[e-mail]>]

------ Forwarded Message
From: ext Kilian Weniger <[e-mail]>
Date: Fri, 27 Apr 2007 08:07:51 -0500
To: Vijay Devarapalli <[e-mail]>
Cc: "Koodli Rajeev (NSN - US/Palo Alto)" <[e-mail]>, "ext
Chowdhury, Kuntal" <[e-mail]>
Conversation: draft-weniger-mobopts-mip6-cnlocpriv-01.txt
Subject: RE: draft-weniger-mobopts-mip6-cnlocpriv-01.txt

Hi Vijay,

thanks a lot for taking the time to review the draft!
I really appreciate that and I agree with much of what you said,
however, I couldn't resist to comment on some statements, so please see
some my comments inline.

Furthermore, I'm looking forward to Kuntal's upcoming comments ;)

> -----Original Message-----
> From: Vijay Devarapalli [mailto:[e-mail]]
> Sent: Dienstag, 24. April 2007 11:45
> To: Rajeev Koodli
> Cc: ext Chowdhury, Kuntal; ext Kilian Weniger
> Subject: Re: draft-weniger-mobopts-mip6-cnlocpriv-01.txt
>
> I looked at this draft again. I have a few concerns.
>
> This draft assumes that the mobile node is able to bootstrap a
> home agent close to the CN. This is a *big* assumption since
> it is not know what kind of CNs the MN might have sessions with
> and if it is possible to always find an ORHA close to the CN.

It is true that there are assumptions and that it may not always be
possible to find a ORHA close to the CN, but that all very much depends
on the deployment scenario as you said. Regarding deployment, I think
the number of deployed HAs will increase dramatically in the next years
due to the recent 3GPP, 3GPP2, WiMax etc. developments. Furthermore,
many roaming relationships exist in such networks, that could be
utilized for MIPv6 bootstrapping. So the applicability of
draft-weniger-mobopts-mip6-cnlocpriv-01.txt should be very good in such
future networks IMO.

Furthermore, please note that currently there is no other solution
proposed in mobopts that can provide simultaneous location privacy and
RO (to CN) with MIPv6. So this is the best we can do currently. Of
course, everybody is invited to submit a better solution for this
problem (which then probably has other limitations ;).

Anyway, please note that limitations in terms of applicability almost
always exist, sometimes more, sometimes less. For instance, "Using IPsec
between Mobile and Correspondent IPv6 Nodes"
(draft-ietf-mip6-cn-ipsec-04.txt, will be RFC soon) has much bigger
assumptions and is more restricted in terms of applicability than
draft-weniger-mobopts-mip6-cnlocpriv-01.txt IMO.

> The draft punts the problem to MIP6 bootstrapping solutions, but
> the MIP6 bootstrapping solutions do assume some kind of trust
> between the MN and the domain hosting the HA. The bootstrapping
> solutions do not assume scenarios where the HAs are selected
> from arbitrary domains.

What do you mean by "arbitrary domains"?

I think the bootstrapping solutions don't make any assumptions about the
location of the domain of the HA (MSP may or may not be co-located with
MSA and may or may not be co-located with ASP), they only make the
assumptions that the necessary trust relationships and AAA
infrastructure are in place. draft-weniger-mobopts-mip6-cnlocpriv-01.txt
has exactly the same assumptions (no surprise, since it just uses the
MIPv6 bootstrapping solutions).

What is new is the discovery of a HA located in a domain close to the CN
domain. Many possible solutions to achieve that, e.g., the MN's home
operator/MSA could select and assign an ORHA to the MN that is located
in a domain (MSP) that has the necessary trust relationships with the
MN's home operator (MSA).

>
> How close is the ORHA to the CN?

The closer the ORHA is located to the CN and the path between MN and CN,
the better the routing efficiency. Which ORHA is chosen depends on the
available/deployed ORHAs, the trust relationships and the ORHA selection
mechanism, which all is implementation/operator/deployment specific and
hence out of scope of the draft.

> The ORHA does know the real
> CoA of the MN. If the ORHA and the CN are in the same domain
> then the CN could potentially get the MN information from the
> ORHA.

Can you elaborate on this?

Why should the CN be able to access the BC in the ORHA just because they
are in the same domain? If this would be true, then it would be possible
for every MN to find out the location of any other MN that uses a HA
from the same operator. I don't think this is possible today.

BTW, if this would really be true, then this would be a new MPv6
location privacy issue, which we would have to add to
draft-ietf-mip6-location-privacy-06.txt.

>
> I also would like to know if this draft belongs in mobopts? To
> describe this draft briefly, the solution involves configuring
> a home agent (ORHA) close to the CN using MIP6 bootstrapping
> solutions and using the ORHA (either through bi-direction
> tunneling or using route optimization between the MN and the
> ORHA) to route the packets to the CN. If this is the right way
> to have Route Optimization with location privacy with a CN,
> perhaps it should be taken directly to the MIP6 or MIPSHOP WGs?

As you probably know, MIPv6 location privacy solutions are currently
developed in mobopts and collected in
draft-irtf-mobopts-location-privacy-solutions. Later, the topic is
supposed to be given to MIP6 and MIP6 will standardize probably one or
more of the solutions proposed by mobopts.

What I don't quite understand in your statement is why the solution in
draft-weniger-mobopts-mip6-cnlocpriv-01.txt should be handled
differently than the other MIPv6 location privacy solutions ("taken
directly to MIP6 or MIPSHOP"). Why not add the solution in
draft-weniger-mobopts-mip6-cnlocpriv-01.txt to the list of solutions in
draft-irtf-mobopts-location-privacy-solutions? Can you please elaborate?


> Do we want people to experiment with this solution before
> standardizing this in the IETF? In fact this solution being

I would support this.

Thanks again,

Kilian


> proposed depends more on deployment considerations (having an
> ORHA close to the CN).
>
> Vijay
>
> Rajeev Koodli wrote:
> > Hi Vijay and Kuntal,
> >
> > I spoke to you guys about this draft. I am interested in
> your feedback on
> > this draft which proposes to hide the location of a MN from
> a CN using an
> > agent "closer to a CN". Could you please take a look at the
> draft and let me
> > know your thoughts?
> >
> >
> http://tools.ietf.org/wg/mip6/draft-weniger-mobopts-mip6-cnloc
> priv-01.txt
> >
> >
> > Thanks,
> >
> > -Rajeev
> >
>
>
>


Panasonic R&D Center Germany GmbH
63225 Langen, Hessen, Germany
Reg: AG Offenbach (Hessen) HRB 33974
Managing Director: Thomas Micke




............................................................................
..
Confidentiality Notice
The information contained in this Email, and any attachments, is intended
for the named recipients only. It may contain confidential and/or legally
privileged information. If you are not the intended recipient, you must not
copy, store, distribute or take any action in reliance on it. Any views
expressed do not necessarily reflect the views of the company.

If you receive this Email by mistake, please advise the sender by using the
reply facility in your Email software and then delete it.
............................................................................
.


------ End of Forwarded Message

_______________________________________________
Mobopts mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mobopts