Subject: RE: [mobile-ip] I-D ACTION:draft-mccann-mobileip-80211fh-01.txt

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Thu, 7 Nov 2002 01:24:54 +0100

> We're not discussing tunnel based handover, we are 
  > discussing whether
  > anticipated handover should be standardized at this time. 

=> That's the main question, I thought we were discussing
fast handovers in WLAN under the following assumptions:

- This draft is specific for 802.11
- We have a generic framework for fast handovers

Based on this, the only useful feedback to the main
draft should be whether something is missing to be able
to support 802.11. Unfortunately that's not the suggestion
being made, on the contrary, the suggestion is that methods
XYZ don't work; ok so what's the alternative? If there is something 
missing in IEEE standards let's take it there. Otherwise, if some 
HW does support this mechanism and some doesn't then all
the best for those vendors who will claim that their
HW will perform better. But yes ideally we want an API, 
however, it is not an IETF issue.

Now in the absence of anticipation, I don't see a 
point of doing fast handovers in 802.11. If we're going
to wait until the MN moves to a new link then just use
HMIPv6 and the performance will be exactly the same, if not 
better than updating oAR.
So I can't (and I'm trying) see the point of removing 
anticipation and calling it a "Fast handover". 

  > IMHO, pure tunnel
  > based handover is also experimental. For FMIPv4, this has 
  > been recognized by the
  > WG by taking the draft to Experimental rather than Proposed.

=> IMHO Tunnel-based handovers are not relevant to 802.11

  > > => My Lucent card gives me this information. Unfortunately
  > > our implementation is not finished yet so I can't point you
  > > to it; Anyway, it's not open source so I can't send it to
  > > the list. But see:
  > >
  > > http://www.cs.umd.edu/~moustafa/Downloads.htm
  > >
  > > as one example, and see Greg's mail for another example.
  > >
  > 
  > Thanx for the tip, we'll look into it. It looks like there 
  > may be a few cards
  > where this could be done. But not all, and that is a 
  > problem with doing a
  > standard. Would the standard have to say something like 
  > "don't try this except
  > on Manufacturer Foo's card?"

=> Of course not, it's not the business of IETF to
specify what HW a node should use. This is completely
out of scope. Naturally, the mechanism will only
work when the HA allows it. 
What happens if someone designs a link layer that 
shows MTU of 1000 to IPv6? 

If we don't do this work now and inform those who 
don't support it, the API will never be done. Whereas
if we show them that things will perform better with
the API I don't see why they won't do it.

Hesham

---

From: "James Kempf" <[email-masked]>
Date: Thu, 7 Nov 2002 08:54:58 -0800

> anticipation and calling it a "Fast handover".

Some operators may want to use HMIPv6 for location privacy, in fact, that's the
way I advocate its use. If you use HMIPv6 primarily for location privacy, it
argues for having the MAP as close to the border router as possible, so that you
get maximum coverage of topology/geography, consistent with good scalability and
performance.

I don't see putting a MAP in every subnet, the architecture you seem to be
advocating, as a cost effective, viable option, because it requires an extra box
in every subnet in addition to the access router. I also don't agree that HMIPv6
should be built into the routers, because that would effectively turn MIPv6 into
MIPv4, since the MAP/AR would effectively be acting as an FA. That option would
also provide zero location privacy benefit, and no performance benefit, since
the MN would have to perform a change of RCoA on every subnet move. I see FMIP
as providing fast handover, and HMIP as providing location privacy, with some
minor performance benefit.

The architectural advantage of HMIPv6 comes primarily from the ability to cover
a broad topological/geographic area, and thus mask the exact location of the
mobile node, in the absence of any radical change in the routing algorithms,
similar to the way RFC 3041 allows a host to mask its identity. HMIP is not the
ideal solution for location privacy, but it works with existing routers.

> => IMHO Tunnel-based handovers are not relevant to 802.11

Well, in fact, they are, so we clearly disagree. We have tunnel based handover
working here. There are two types of tunnels, one initiated by the mobile node
and one initiated by the access router or access point. Tunnels allow the mobile
node to obtain its traffic while RO is happening.

How do you expect the traffic to get to the MN while the BU to HA and RR/BU to
CNs is occuring?

> the API I don't see why they won't do it.

Having 802.11 scanning be host controllable, which is what the driver for the
Orinoco card you pointed me to does, still won't give you much. The scanning
must be done regardless of whether anticipated signaling is happening or not. So
instead of bunding the scanning and handover together in the firmware, the
sequence will look like this;

    Layer            Operation                       Approximate Time
    -----             -----------                      -------------------

   802.11           Scan                            80-300 ms gap in host IP
service

    IP                 Perform Prereg/
                        anticipated signaling       variable depending on the
traffic load, but typically 80-200 ms, possible
                                                             gap in IP service
if host forced to backoff.

   802.11          Reassociation                Probably less than 20 ms gap in
host IP service

If the scanning and reassociation are done together, then the sequence looks
like this:

    Layer            Operation                       Approximate Time
    -----             -----------                      -------------------

   802.11           Scan                            80-300 ms gap in host IP
service

   802.11          Reassociation                Probably less than 20 ms gap in
host IP service

    IP                 Posthandover                10-20 ms
                         Tunnel initiation

The net effect is that the user traffic would probably be interrupted less with
post handover tunnel initiation, because there is less signaling.

If 802.1x is used and the prehandover signaling results in a tunnel being set
up, there is more of a benefit because 802.1x can delay re-establishing IP
service on the new access point considerably.

                    jak

---

From: Claude Castelluccia <[email-masked]>
Date: Thu, 07 Nov 2002 18:26:48 +0100

> ideal solution for location privacy, but it works with existing routers.

Hello Jim,

I am just curious: 
What would be the ideal solution for location privacy.
What is missing to HMIPv6 to achieve this solution?
 
thanks,

cheers,
Claude.

-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/

---

From: "James Kempf" <[email-masked]>
Date: Thu, 7 Nov 2002 11:39:16 -0800

> What is missing to HMIPv6 to achieve this solution?

What is missing is that there is still a correlation between the broader
geographic location and the subnet prefix in the RCoA. Thus, if I live in Lyon
and I decide to take the day off and go to the beach, my boss can't tell from my
RCoA whether I am at the beach or at work if the MAP covers all of France. But
he can tell if I decide to go to Switzerland.

            jak

---

From: Claude Castelluccia <[email-masked]>
Date: Fri, 08 Nov 2002 09:45:05 +0100

Hello Jim,

ok i agree but nothing prevents you from using the French MAP even if
you are travelling
abroad ...of course the routing will be less optimal but that the price
to pay...

More generally you could have a list of MAPs (randomly distributed on
the Internet) and have
each mobile host choose a MAP randomly (a host in France could use a MAP
in Japan)...
once again the price to pay is in routing...
The MAPs could also be MIXes if you want to increase privacy...

An other issue is that most of the schemes assume that the users trust
their network operator
(i guess this is ok with you ;-))...If fact the operator knows the
binding between the RCoA
and LCoA. It is then quite easy for him to retrieve the HoA from the
RCoA....
I agree some work is still needed here...but HMIPv6 is flexible enough
to provide a reasonable
and deployable solution.

Cheers,
Claude.

PS: maybe a document that defines what are the requirements of a
location privacy solution will be useful at
this stage...

--

---

From: Pars Mutaf <[email-masked]>
Date: Fri, 08 Nov 2002 16:13:17 +0100

> he can tell if I decide to go to Switzerland.

Hello!

I think, even if there is no correlation between the broader
geographic location and the subnet prefix in the RCoA,
location privacy is not enough unless you have "distance
privacy".

For example, Thierry is a professional thief...

Thierry can tell whether Bob will be back home tonight
regarding Bob's distance and proceed accordingly. If Bob is
in another country, he certainly stays in a hotel tonight. So,
Thierry can safely enter his house and steal his property.

Location privacy is not necessarily a solution to this problem.
Thierry doesn't care if Bob is currently in Paris, California or
New Guinea. He only needs an idea about his distance.

Obviously, distance can be RTT or perhaps TTL variation.
A quick experiment has shown that
RTT(california<->myhost) = 16 x RTT(france<->myhost)
RTT(finland<->myhost) = 6 x RTT(france<->myhost)

(myhost is in france)

So, RTT is reliable enough to reveal one's distance.

IMHO distance privacy is needed, otherwise RCoA privacy
may not make sense. But it is hard to tell which solution is
enough for which problem. There are many threat models
associated with location privacy.

Regards,

pars

---

From: "James Kempf" <[email-masked]>
Date: Fri, 8 Nov 2002 08:46:24 -0800

> The MAPs could also be MIXes if you want to increase privacy...

The routing price is the issue.

> I agree some work is still needed here...but HMIPv6 is flexible enough

I think HMIP is sufficient for a first generation solution that requires no
change to existing routers. In that, it is like RFC 3041. Whether that will be
enough ultimately to satisfy the technical, political, and social requirements,
to say nothing of legal and regulatory, for location privacy once Mobile IPv6
networks become really common is another matter.

> location privacy solution will be useful at

Actually, I am not sure. I don't think this is really a standardization issue, I
think it is a research issue, and for research, I question the need for
requirements.

With regard to the political and social requirements for location privacy, I
don't think the IETF is in a position to really say much about that one way or
another. It would be an excellent topic for an ISOC white paper, though.

I think it is important that we get some research going, with different ideas
about how we can improve location privacy and address privacy, so that we'll be
in a position to agree on the technical properties and recommend solutions for
standardization once the political and social pressure builds for standardized
privacy solutions in the Internet beyond what HMIP provides.

                jak

---

From: "James Kempf" <[email-masked]>
Date: Fri, 8 Nov 2002 09:54:01 -0800

> New Guinea. He only needs an idea about his distance.

Seems pretty risky to me. What if Bob accidently left his mobile phone in the
departure lounge of the Heathrow Airport? Or Bob might be a CS grad student who
has rigged a router to decrement his TTL so he can catch Thierry in the act. :-)

> RTT(finland<->myhost) = 6 x RTT(france<->myhost)

Yes, but it might also be true that:

RTT(thailand<->myhost) = 16 x RTT(france<->myhost)
RTT(south africa<->myhost) = 6 x RTT(france<->myhost)

You get topological distance information from this, not geographical distance
location.

This is the same kind of information you can get by dialing someone's cell phone
number and measuring the delay before it starts to ring.

> associated with location privacy.

I can't imagine how one could remove or mask the TTL.

I think the primary issue is how to mask the exact location so that the GEOPRIV
requirements can be met, i.e., so that only authorized clients can obtain access
to geographical information. If an unauthorized client can use the IPv6 routing
prefix to obtain somebody's location, then GEOPRIV's security guarantees won't
be worth anything.

            jak

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Fri, 8 Nov 2002 12:12:47 -0800

> > The MAPs could also be MIXes if you want to increase privacy...

Sure, there is a trade-off between location privacy and route
optimization.

Location privacy is highest when there is no router optimzation.
(i.e., all traffic flows through HA).

Location privacy is lowest when there is end2end route optimization.
(i.e., CN directly send to MN's CoA).

Any fine tuning in between these two extremes can be achieved by
choosing the location of MAP in HMIP.

> The routing price is the issue.

Can you solve this without:
a- relying on host routes all accross the Internet (max. loc. priv,
   max. route optimization).
b- relying on MAP's that are as close to CNs as possible, hence
   blocking the view of CNs about the location of MN.

(a) is not practical at all.
(b) is relatively practical, but very costly.

alper

---

From: Pars Mutaf <[email-masked]>
Date: Sat, 09 Nov 2002 18:19:25 +0100

Hello,

Please find further responses below..

pars

James Kempf wrote:

> Seems pretty risky to me.

I guess, you mean risky for the thief. Sorry, I don't understand
the reasoning. I already don't feel comfortable when I leave home
for longtime :-) MIP shouldn't introduce additional risk.

> What if Bob accidently left his mobile phone in the

:-)

But, what if Bob did not "accidentally" leave his phone at the airport?
We can't rely on that.

> You get topological distance information from this, not geographical distance

Yes, of course. But I think for "long" geographical distances, topological
distance is also considerable. A factor of e.g. 10 is not negligible and means
something. Your Thailand, South Africa examples show (with
an important probability) that Bob is not in France. This is helpful
information.

Another example: I know that Mr. X is currently in California or France.
I don't care about his exact location but I want to know if he is in France.
RTT will give me this information with an important probability. Again,
location privacy wasn't useful for Mr. X.

> number and measuring the delay before it starts to ring.

OK.

> I can't imagine how one could remove or mask the TTL.

May be when you send a packet, you can choose a random TTL
between the maximum value and an acceptable minimum value.
The acceptable minimum value may be the diameter of the
Internet (which is around 30), plus a value to tolerate
possible errors. Of course this is open to discussion, especially
if the diameter of the Internet will change next year. But
the person who measured it, told me that the diameter of
the Internet does not change. Of course, I don't know if we
can rely on such an assumption.

I still have the impression that the RTT is also important info
against location privacy (for long distances). May be Chaum's
MIXes can solve this problem.

> prefix to obtain somebody's location, then GEOPRIV's security guarantees won't

OK. But I also think that the exact location is not the only issue. The distance
is also important. For two reasons at least:

1. Sometimes I don't care about one's exact location. I'm interested in his/her
distance.
2. Sometimes (when combined with social engineering) one's distance, can
reveal his/her location (Mr. X example, above).

Thanks,

pars