Re: [Mobopts] review of draft-irtf-mobopts-location-privacy-solutions

[Jari Arkko <jari.arkko at piuha.net>]

I recently read this draft, and wanted to post some comments and questions:

The draft was well written and easy to read. It is about a very 
interesting topic, and something that I would like to see even more IRTF 
work on. Generally very interesting stuff, particularly about the 
solution that allows you to communicate with a peer without telling the 
peer what your home address is!

For background information, the draft specifies two different solutions. 
The first solution uses a reverse tunneled binding update and obfuscated 
home address field to prevent outsiders on the mobile node's link from 
discovering the mobile node's home address, even if route optimization 
to the correspondent node is used. The first solution extends the 
definition of Routing Header Type 2 from RFC 3775 and allocates a new 
IPv6 destination option for a new type of a home address. The second 
solution specifies a new mechanism to allocate home addresses, and 
functionality in the home agent to translate payload packets from the 
use of the real home address to a newly allocated temporary home 
address. The solution introduces router-based inspection and 
modification of data packets. The draft allocates IPv6 destination 
option values, Mobility Options, and modifies the existing Routing 
Header Type 2 format.

I can see a potential problem in the redefinition of Type 2 Routing 
Header. As you know, problems have been discovered in standardized 
routing headers long after their specification. I am concerned that the 
overloading of the Type 2 routing header used by RFC 3775 and the 
proposed experimental extension couples the fate of these two functions. 
That is, if a problem is discovered later in the draft, it may lead to 
networks filtering all Type 2 routing headers, and not just the ones 
using the extensibility bits. It would be more prudent to allocate a new 
value for this specification, or perhaps use one of the already defined 
experimental values from RFC 4727.

Another problem is that as far as I can determine, the second solution 
introduces router-based packet inspection and an IPv6 NAT-like 
functionality. Or am I missing something? Even if so, I am uncertain, if 
the solution really needed this functionality. It might have been 
possible to use or extend the existing home address allocation 
mechanism, defined in RFC 4877 and make mobile node and upper layers 
aware of which temporary home address is being used.) Or maybe the issue 
is that the draft does not talk about how all this shows up for the 
mobile node vs. the correspondent node. If the mobile node believes it 
uses its home address when the correspondent node sees only a 
pseudoaddress, then you have essentially implemented an address 
translation, with some e2e effects visible to applications. If the 
mobile node is aware which address the other end sees, then that address 
can be chosen in address selection, and there is no e2e effects, just 
two invisible address changes along the path.

Also, I wonder if it was necessary to define a new mechanism for home 
address allocation, when we already have one in RFC 4877. Perhaps it 
could be extended to request allocation from a "privacy prefix".

I wish Section 4 had talked about applicability of the two methods. Does 
the second method provide support for home - foreign - home movements? 
It would seem that the answer is no. It should provide support for 
foreign-foreign movements, even though the spec is silent on this. Note 
that if it did provide foreign-foreign movements, while the real home 
address would be unknown, then by definition the correspondent node 
would have to know that that the mobile node in location A is the same 
node as the one that just moved to location B; the identity of the 
mobile node (as a concept) would be revealed. Secondly, if the spec 
provides no support for foreign-foreign or home-foreign-home movements, 
there's a slightly simpler design :-) just bypass all mobile IP 
processing and use a care-of address to communicate with the 
correspondent node.

Some other observations:

> Kpm =  HMAC_SHA1 (Kbm, 0).

If you are going to derive keys from Kbm, it would be a good idea to use 
a longer string than "0" -- there might be other keys derived in the 
future from Kbm. E.g., use "PRIVACY".

>       encrypted home address = Enc(Kpm, the home address)
>
>       Where Enc(.) is a symmetric key encryption algorithm.  AES is the
>       default encryption algorithm.

Are there details missing? E.g., SHA1 produces 160 bits and AES takes 
128 bits (or one of the versions takes 128 bits). Which version of AES 
is used? What mode?


> 5.3.5.  Receiving ICMP Error Message
>
>  If such a message is received,
>    the mobile node MUST not attempt to use the location privacy solution
>    with the correspondent node.

I suspect a SHOULD would be more useful here.

> However, eavesdroppers on the HA-CN path can launch an attack to 
> compromise the return routability procedure anyway.

This isn't entirely accurate. First some background. If you look at 
Mobile IPv6 without extensions defined in this specification, attackers 
on the HA-CN path will be able to block traffic, look at data packets, 
etc. However, this would be the case even if there was no Mobile IPv6 
and there was a non-mobile host in the home network, trying to connect 
to the CN.

And then back to this specification. What this specification does is 
re-use some aspects of the base specification for another purpose, 
namely employ some of the key material for confidential information. The 
key material isn't quite made for that, and therefore HA-CN path 
attackers will be able to see even the home addresses.

But that too is kind of besides the point. I would rewrite the paragraph 
as follows:

OLD
With the solution in Section 5, the real home address is visible in
 the Binding Update and Binding Acknowledgment messages along the
 HA-CN path.  However, eavesdroppers on the HA-CN path can launch an
 attack to compromise the return routability procedure anyway.
 Despite the limitations of the existing return routability mechanism,
 this solution meets all the requirements set forth for the location
 privacy solutions and provides a simple way to provide location
 privacy protection while allowing the use of the real home address
 with the correspondent node.
NEW:
With the solution in Section 5, the real home address is visible in
 the Binding Update and Binding Acknowledgment messages along the
 HA-CN path. Like Mobile IPv6 itself, it has not been designed to
 change the communications between the home network and the
 correspondent node; the same issues would affect non-mobile hosts
 as well. This solution meets all the requirements set forth
 for the location privacy solutions and provides a simple way to 
provide location
 privacy protection while allowing the use of the real home address
 with the correspondent node.


>    When receiving a Home Test Init message, the home agent performs the
>    operation as specified in Section 6.6.4.  If this operation succeeds
>    when the Pseudo Home Address mobility option is present in the Home
>    Test Init message, the home agent generates a Home Test Init message
>    and forwards to the correspondent node.  As shown in the following,
>    the pseudo home address carried in the Pseudo Home Address mobility
>    option is used as the source IP address in the forwarded Home Test
>    Init message.
>
>      IPv6 header (source = pseudo home address, destination = 
> correspondent)
>      Mobility Header (HoTI)
>          Home Init Cookie

This is an on-path modification of a packet not addressed to the party 
doing the modification. This is considered bad practice. It might even 
break things, such as any end-to-end security applied between the mobile 
node and correspondent node. Not to mention TCP checksums. Perhaps 
another approach would have been cleaner, such as an explicit message 
sent to the home agent (say, Home Test Init Delegate message).

> 6.  IP Address Location Privacy Solution Using the Pseudo Home Address

There are standard mechanisms for registering a new home address (e.g., 
RFC 4877). The use of such mechanisms would have resulted in a much 
cleaner approach architecturally; additional options could have been 
specified for marking a home address request to be from a privacy 
address pool. As both the mobile node, home agent, and correspondent 
node would have been on the same page about the used address, there 
would not be any of the NAT-like effects this specification creates. And 
we wouldn't need additional mechanisms.

> 6.3.1.  Reverse Tunneling Mode
>
>    The format of payload packets reverse-tunneled via the home agent is
>    the same as that specified for the home address test procedure in
>    Section 6.2.1.

I am having trouble understanding this. First of all, the format in 
6.2.1 was IP-tunneled packets with MH. Does the home agent do some 
conversions of home address=>pseudo home-address on the fly for each 
data packet?

> 6.3.2.  Route Optimization Mode
>
>    When the route optimized correspondent binding update procedure is
>    performed, the format of payload packets exchanged between the mobile
>    node and the correspondent node is the same as specified in RFC 3775.
>    The operation of the mobile node when communicating with the
>    correspondent node via the route optimization mode is described in
>    Section 6.5.6.
>
>    When the reverse tunneled correspondent binding update procedure is
>    performed, the format of payload packets exchanged between the mobile
>    node and the correspondent node is the same as specified in Section
>    5, except that the encrypted pseudo home address SHOULD be included
>    in the Encrypted Home Address destination option and the Type 2
>    routing header.

I was confused by this. First of all, we are under "6.3 Payload 
packets", so why does it matter how the binding update procedure is 
done? Either your payload packets are route optimized or reverse 
tunneled, and 6.3.1 already dealt with the reverse tunneled mode. 
Secondly, this is the first time you are introducing EHoA option usage 
for your second solution. Is this a typo, and you meant the HoA?

> 6.4.  Prefix Discovery
>
>    The solution to protect location privacy during the prefix discovery
>    procedure is similar to that used during the home binding update
>    procedure.

What does prefix discovery have to do with your solution?

> The Binding Update List entry is extended with a field, called Pseudo
>    Home Address.  This field MAY be implemented as a pointer that points
>    to a corresponding entry in the Pseudo Home Address table.  ...  
> For the
>    binding sent to a specific home agent, the Pseudo Home Address field
>    points to the first entry in the Pseudo Home Address table (or NULL
>    if the table is empty), so that the mobile node can access all the
>    pseudo home addresses registered at this home agent;

Is the field for (a) *one* address or (b) a *list* of addresses, or (c) 
for an address *or* a value denoting no pseudo address is used?

I think you actually want (c).

> In addition, if the Return Routability procedure
>    is for a new session with the correspondent node, the mobile node
>    selects any pseudo home address from those already registered with
>    the home agent and stored in the Pseudo Home Address table;
>    otherwise, the mobile node must use the same pseudo home address as
>    used with the same correspondent node before.

I think you mean the correct thing here, but the description may not be 
clearest for the reader. The route optimization mechanisms are actually 
not relevant here; once you exchange the first payload packet with the 
correspondent node via home agent or directly (when you are at home), 
you are committed to that address. This should be explained more 
clearly. Route optimization and all signaling simply must follow the 
commitment the node has taken earlier. How you know that such a 
commitment exists is another matter...

>       Encrypted Home Address (E)
>
>          The Encrypted Home Address (E) bit is set to indicate that the
>          encrypted home address is carried in the routing header.
>
> Note that if the Type 2 routing
>    header with the 'E' set is present in a packet, the encrypted home
>    address therein MUST not be treated as the real destination IP
>    address by the receiver.


I wonder what the tradeoffs are to do this as an extension of Type 2 
routing header vs. a new routing header type?

The latter text seems to indicate mandatory behaviour that existing Type 
2 implementations obviously cannot follow. I realize that you should not 
get to this situation because you need signalling agreement before you 
can use the extended Type 2 header. However, I'm concerned that if we 
find a problem in the extension, this will affect negatively on what 
firewalls etc. do on Type 2. As a result, perhaps it would be better to 
use a new type? Or has this matter been analyzed in some manner during 
discussions in MobOpts?

> advertently
> deterministicly
> procesing

Typos

Missing things:

I suspect the specification should say something about how it interacts 
with other extensions of Mobile IPv6. At least RFC 4866, 
draft-ietf-mext-multiplecoa and maybe others.

Jari