Subject: RE: Outlawing (Avoiding) NAT with IPv6

From: Pekka Savola <[email-masked]>
Date: Tue, 1 Apr 2003 10:34:29 +0300 (EEST)

On Mon, 31 Mar 2003, Tony Hain wrote:
> John Bartas wrote:
> > 	If IPv6 has a better anonymity solution, can someone 
> > point me to it? Or do I have to start working on NATv6?  
> > (See, this is why I don't always want to identify myself! 
> > :-)
> 
> See RFC 3041 - It does exactly what you want without the drawbacks of
> NAT.

NAT, applied *where*?

On your DSL/cablemodem/etc. box -- about right.

By the ISP?  RFC3041 doesn't give you anything except a false sense of
anonomity and broken apps.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 01 Apr 2003 13:54:08 +0200

> See RFC 3041 - It does exactly what you want without the drawbacks of

Actually not, if you have a domestic /48 or /64 prefix. But the
MobileIP solution looks OK.

   Brian

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 1 Apr 2003 08:04:17 -0800

Pekka Savola wrote:
> ...
> By the ISP?  RFC3041 doesn't give you anything except a false 
> sense of anonomity and broken apps.

It provides anonomity for devices that appear on multiple networks. It
does not prevent an ISP from identifying the customer demarc. It does
not break apps that were not broken already due to a reliance on a DNS
ptr record as some warped form of security.

Tony

---

From: Leif Johansson <[email-masked]>
Date: Tue, 01 Apr 2003 18:27:31 +0200

>ptr record as some warped form of security.
Applications break for _completely_ different reasons than that Tony!

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 02 Apr 2003 14:36:49 +0200

Brian E Carpenter wrote:
>>> If IPv6 has a better anonymity solution, can someone point me 
>>> to it? Or do I have to start working on NATv6? (See, this is 
>>> why I don't always want to identify myself! :-)
>> 
>> See RFC 3041 - It does exactly what you want without the 
>> drawbacks of NAT.
> 
> 

Looks but doesn't act like really providing location privacy, IMHO.

In my understanding, the essence of the hmipv6 location privacy
mechanism lies in the MAP replacing a RCoA for a LCoA (when
decapsulating).  However, it is very much likely that the two
addresses will only differ in the /64 prefix.

Suffices it for an attacker that wants to find the correlation
LCoA-RCoA to visit the MAP domain once and learn that domain's
prefixes that are part of all of that domain's LCoA's.

What one really obtains with HMIP is that one gets assigned two
addresses and is free to inform its CN about one of those addresses.
Nothing about a location being assigned to an address, let alone the
question of hiding that location.

Another location privacy drawback in hmipv6 is that it is the
network that decides whether an MN can use that location privacy or
not.  That should supposedly be entirely an MN choice.

My two cents worth; (two because I'm getting the ipng mails twice :-)

Alex
GBU

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 02 Apr 2003 16:29:25 +0200

> Looks but doesn't act like really providing location privacy, IMHO.

I meant HMIPv6 providing location privacy is dubitable (I was not
referring to Mobile IPv6).

Alex
GBU

---

From: Alper Yegin <[email-masked]>
Date: Wed, 02 Apr 2003 11:01:25 -0800

> prefixes that are part of all of that domain's LCoA's.

I don't quite understand this... All CN knows is the RCoA of the MN.
Only LCoA can reveal the location of the MN within the network. And CN
cannot figure out LCoA by looking at RCoA. This is so much like what NAT
does as far as hiding LCoA  is concerned.

> not.  That should supposedly be entirely an MN choice.

MN can choose to engage in HMIP and hence take advantage of it. I don't see
the network forcing MN to use this protocol. So, at the end, it's MN's
choice.

> My two cents worth; (two because I'm getting the ipng mails twice :-)

alper

---

From: Greg Daley <[email-masked]>
Date: Thu, 03 Apr 2003 09:07:05 +1000

Hi Alexandru,

A quick HMIPv6 comment below.

Alexandru Petrescu wrote:
> Brian E Carpenter wrote:
> 
>>>> If IPv6 has a better anonymity solution, can someone point me to it? 
>>>> Or do I have to start working on NATv6? (See, this is why I don't 
>>>> always want to identify myself! :-)
>>>
>>>

There is no problem with the RCoA and LCoA differing only in prefix
if the LCoA and RCoA are based on RFC3041 addresses.

In this case, there is no identity information in the care-of-addresses,
and no specific location information available in packets which
are sent from the RCoA.

For communications completed while the RCoA is unchanged, the MN can
use a 3041 based RCoA, and not use the MIPv6 Home Address options
(or use the RCoA as a home address), in which case there is no
identity information in the packets sent or received from the MN
to correspondent nodes, and no location information more accurate
than which MAP the MN is using.

Please try to track a user in this situation!

> prefixes that are part of all of that domain's LCoA's.

Location privacy within the MAP domain is still achieved for
the MN, since this is not divulged to anyone other than the
MAP.  Of course you could easily determine what the advertised
MAP coverage was, but anyone could still use a MAP when they
are not in the base coverage domain, so long as there is
connectivity between the MAP and MN, and the MAP policy allows this.

> question of hiding that location.

Locations are implied by IPv6 subnet information in the LCoA.
IP access subnets which span greater areas than a city are a
bad idea IMHO.

Of course the MN is responsible for which addresses it uses
in conversation.  If it's aware of a need for privacy and still
advertises the IP subnet it is located at then privacy isn't
going to work.

> not.  That should supposedly be entirely an MN choice.

I think that there may be location indirection services which
accept fees from MNs to provide location privacy with HMIPv6, without
being in the Access Service provider.  This would be an opt-in service,
on the MN's behalf.

Also, we're looking at the possibility that certain countries will
ensure that ISPs in their jurisdiction provide location privacy.
If HMIPv6 is the only candidate (and works), I'm sure that it will
be adopted.

If you're more interested in the technical details, then we can take
this to Mobile-IP WG.

Greg

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 03 Apr 2003 12:11:15 +0200

Alper Yegin wrote:
> I don't quite understand this... All CN knows is the RCoA of the 
> MN. Only LCoA can reveal the location of the MN within the network.
>  And CN cannot figure out LCoA by looking at RCoA.

What's the difference between a RCoA and a LCoA of a same MN?  In my
understanding only the /64 prefix differs.  The RCoA prefix is valid
on the MAP subnet and the LCoA prefix is valid in the AR subnet.

A CN is presented with the RCoA.  A CN can have "out-of-band"
knowledge about the prefixes valid under various ARs.  Based on this
input, a CN can build the LCoA corresponding to the RCoA.

That's what I was trying to say, but maybe I fail somewhere.

> This is so much like what NAT does as far as hiding LCoA  is 
> concerned.

To me, there are some common points, but there are also huge
differences.  I'm thinking about in NAT there is a specific set of
types of addresses (the not publicly-routable) that can be reused by
any site at will.  However, with HMIPv6, the LCoAs must be globally
unique.

Alex
GBU

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 03 Apr 2003 14:11:19 +0200

Hi Greg,

>  if the LCoA and RCoA are based on RFC3041 addresses.

A-ha, that sounds like a tangible goal.  I mean there is a big
if in your phrasing.  I still need to understand how this would work
in practice (answering your question on if I'm interested on tech
details).  Currently HMIPv6 has no RFC 3041 in it, so saying it might
be made to work, it is ok, but saying that HMIPv6 provides location
privacy is not quite ok (IMHO).  And, this of course depends on what
the location privacy problem is (if any).

[snip text on functioning]

> For communications completed while the RCoA is unchanged, the MN 
> can use a 3041 based RCoA, and not use the MIPv6 Home Address 
> options (or use the RCoA as a home address), in which case there is
>  no identity information in the packets sent or received from the 
> MN to correspondent nodes, and no location information more 
> accurate than which MAP the MN is using.
> 

That is ok, I agree.  (You must be sure MAP maintains the right
association between one LCoA and several RCoAs (RCoAs change for rfc
3041 reasons, if I understand correctly).)

The MAP is a HA, that's all.  RO is not used, so CN knows nothing
about the location.  So this is pure Mobile IPv6. That's why I tried
to distinguish between Mobile IPv6 and HMIPv6.

>> addresses and is free to inform its CN about one of those 
>> addresses. Nothing about a location being assigned to an address,
>>  let alone the question of hiding that location.
> 
> Locations are implied by IPv6 subnet information in the LCoA. IP 
> access subnets which span greater areas than a city are a bad idea 
> IMHO.

Aha, so location is the IPv6 subnet information where the MN is
attached.  That is the location.  That is what it is tried to be
hidden from CN.

> If you're more interested in the technical details, then we can 
> take this to Mobile-IP WG.

Yes, I'm interested in the technical details, but I'm afraid of
cluttering the Mobile IP group with this, they have a much more
important job now.

Until we figure out where to do it, let me say that I agree with most
of your points, but not all.  And that I will try to refrain from
posting on ipng as well.

Alex
GBU

---

From: Alper Yegin <[email-masked]>
Date: Thu, 03 Apr 2003 12:28:29 -0800

> on the MAP subnet and the LCoA prefix is valid in the AR subnet.

I don't think HMIP protocol  requires that RCoA and LCoA have the same
suffix.  RCoA can be configured with a random interface id to break the
correlation between the host and RCoA.

> input, a CN can build the LCoA corresponding to the RCoA.

Since CN does not know the location of the MN, it does not know the prefix
of LCoA, hence it cannot figure out LCoA by looking at the RCoA.

> any site at will.  However, with HMIPv6, the LCoAs must be globally

That's right. This gives the option to use LCoA with a CN if MN wants to.
So, location privacy is an optional feature for MN to use, unlike with the
NATs. This is nice, because the MN might want to signal its location to some
CNs for things like location-based services.

alper

---

From: Greg Daley <[email-masked]>
Date: Fri, 04 Apr 2003 09:30:00 +1000

Hi Alper,

Just a quick note.

Alper Yegin wrote:
[much text cut]
> CNs for things like location-based services.

Actually, it is possible to use a site-local address for LCoA, if
all outbound packets are forced to go through the MAP.
Since there is a unique mapping for RCoA to the LCoA and tunneling
of received globally addressed packets you don't get the application
interference of NAT though.

Of course, this will only be possible if we still have site-locals,
and may require some protocol tweaks on entering a MAP domain
which only advertises site-locals.

I'm not going to recommend this as a solution though.
I'm not flame proof.

Greg

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 04 Apr 2003 11:45:16 +0200

Hi Alper, Greg.  I'm not flaming, and not try to generate any heat :-)

Greg Daley wrote:
>> That's right. This gives the option to use LCoA with a CN if MN 
>> wants to. So, location privacy is an optional feature for MN to 
>> use, unlike with the NATs.

Actually, I think that MN can decide about its use of location privacy
only if the network allows it.  If the network doesn't allow it, in
the advertised MAP options, then MN can not do anything and it will
reveal its location to CN?:

    "This can be done if the I or P flags are set in the MAP option.
     Otherwise location privacy can not be provided in this manner. If
     the V flag is set (in addition to the P or I flags), the mobile
     node MUST tunnel all outgoing packets to the MAP."

Specifically, if the V, I and P flags are not set in the MAP options
(in other words network decides MN is not a VIP) then MN must reveal
location information to CN.

I mean, I interpret it that way, but the intended meaning might be
otherwise.

>> This is nice, because the MN might want to signal its location to
>>  some CNs for things like location-based services.

Yes, ok, but must be entirely MNs option, not network's?  Or maybe
this was already discussed.
> all outbound packets are forced to go through the MAP. Since there
>  is a unique mapping for RCoA to the LCoA and tunneling of received
>  globally addressed packets you don't get the application 

Ok, here is were we diverge.  Mobile IPv6 in itself provides a form of
location privacy, in that if RO is not used, then all packets are
tunneled back to HA, so CN doesn't know the actual location.
Moreover, in Mobile IPv6 it would be much simpler if the concept of
"site-locals" didn't exist.

In HMIPv6, the above text, kind of requires the site-locals concept to
be in place in order to offer location privacy.

So, an idea is that the location privacy might be a problem, and that
Mobile IPv6 might offer a site-local-free solution for that problem,
and that HMIPv6 needs site locals in order to provide a solution to
that problem.

Alex
GBU

---

From: Alper Yegin <[email-masked]>
Date: Fri, 04 Apr 2003 11:33:46 -0800

Alex,
 
> and that HMIPv6 needs site locals in order to provide a solution to

This is not a correct conclusion. As I have explained earlier, HMIP provides
location privacy by hiding MN's LCoA from the CN. LCoA does not need to be
site-local. 

You'd need site-locals if you want to replicate the IPv4-NAT architecture
one-to-one in this context. But this is not needed for achiving location
privacy.

alper

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 05 Apr 2003 00:03:25 +0200

Alper, I tried to draw a logic conclusion from this:
-I assumed LCoA and RCoA have same last 64 bits
-I was countered that that is not absolutely necessary, and that rfc
3041 could be used.
-I replied: yes, could, but it is not.
-I was pointed that site-locals might be used too.
-so I concluded.

That's only simple logic, sorry if I understood you wrong.

> You'd need site-locals if you want to replicate the IPv4-NAT 
> architecture one-to-one in this context. But this is not needed for
>  achiving location privacy.

Ok.

It's overwhelming with emails, so please allow me to agree with some
parts of your argumentation and maybe we get a chance to further
discuss about this later.

Alex
GBU

---

From: Claude Castelluccia <[email-masked]>
Date: Mon, 07 Apr 2003 09:14:12 +0200

Hello Alexandru,

> -I assumed LCoA and RCoA have same last 64 bits

It does not have too ...and must not if you use HMIPv6 to provide
location privacy...

Claude.

--

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