Subject: Re: [mobile-ip] Location privacy

From: Subir Das <[email-masked]>
Date: Tue, 03 Apr 2001 11:31:44 -0400

Hesham,

>
>
> >  and to some extent (*maybe*) provide
> > a local entity in the serving network to authorize the MN access to
> > the network.
> >
>         => Can we say that such authorisation is done by virtue
>          of the BU to the MAP ? Would that be satisfactory ?
>          I'm just trying to avoid integrating AAA into MIP.

      Just curious,  cann't you do this  via BURP?

Thanks,

Subir

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 3 Apr 2001 17:06:03 +0200

Hi Raj, 

> I do not believe location privacy should be one of the focal points
> of HMIPv6. I think the key thing to be accomplished with HMIPv6
> is the ability to reduce signaling to CNs and HA whenever a MN
> moves (and changes it's COA)
> 
	=> Sounds good. Actually that's what we wanted as well,
	but, the solution we came up with gave us location
	privacy for free. So I agree that it shouln't be the 
	focal point and that HMIPv6 should not be the optimal 
	location privacy solution. It would be good if someone 
	started looking into a more optimal way of doing it.

	Thanks,
	Hesham

---

From: Theo Pagtzis <[email-masked]>
Date: Tue, 03 Apr 2001 10:23:11 -0700

>          I'm just trying to avoid integrating AAA into MIP.

Further to the above discussion we need to clearly distinguish on what
constitutes location privacy

Are we looking location privacy WRT

      1) the visiting domain and the current location of the MN
      2) the world and the current location of the MN
      3) the visiting domain and the home location of the MN

Currently my interpretation of the HMIPv6 draft allows only in Basic
Mode to avoid devulging the home addr of the MN to the visiting domain.
This is case (3) since in Basic mode you sustain uniqueness of reference
on a per MN unique RCoA as created by the MAP prefix. I have explicitly
expresses my concern that this would bring up (scaling angle on)
millions of new RCoAs for management and DAD verification on the MAP box
or at the very least to the MAP domain.

Extended mode does not do that as it uses the Home address of the MN as
a uniqueness ref key in the B- Cache of the MAP AND uses a unique RCoA
for ALL MN...so a single RCoA seems to work in extended but not wanted
in Basic mode....WHY.......?????

As far as (2) is concerned...CNs can find the current location of the MN
in no time if
            the source addr is the LCoA of the MN. I have heard the
argument that the RCoA may be allowed in the src addr in upstream data
packets from the MN. I believe that this argument is completely unsound
since
                            egress filtering is more that expected to be
found in ISPs. If the assumption is NOT then we will have a bad time
trying to convince ISP to do switch off egress filtering
                            if egress filtering is on and you still want
the RCoA on, you MUST go through a specific route to the filter that
understand the RCoA (say the visiting domain). That to me seems like an
upstream routing hierarchy with specific upstream routes...I am
confident that such has been a no-no from both hierarchical schemes.

(1) simply will never happen since the MN has to register with the
mobility agent (MAP or GMA)

Theo

UCL / Mobile Systems

---

From: Michael Thomas <[email-masked]>
Date: Tue, 3 Apr 2001 11:00:03 -0700 (PDT)

Note that this is applicable to any of [A-Z]MIP's

 > 	 I'm just trying to avoid integrating AAA into MIP. 

   I don't think so. Any time you request services from
   a node, that request may need to be both authenticated
   and authorized. A BU can be sufficient so long as 
   the shared key establishment implies authorization
   for the use of the service. If it doesn't, then you
   need other ways to authorize the request including
   classic AAA. Given the typical NAS model, I'd expect
   there will be a lot of desire to use AAA.

		Mike