Subject: [mobile-ip] Comments to draft-castelluccia-mobileip-privacy-00.txt

From: Pekka Nikander <[email-masked]>
Date: Mon, 19 Mar 2001 18:56:25 +0200

Claude,

Here are some half-baked comments to your draft
draft-castelluccia-mobileip-privacy-00.txt

Firstly, I don't immediately see the usability of TMI instead
of just dropping the Home Address altogether, as I suggest
(among other things) in my Homeless Mobile IPv6 draft,
  draft-nikander-mobileip-homelessv6-01.txt

That is, if you use IPsec, you don't need home 
addresses and therefore the home address
destination option is useless.  On the other hand, if
IPsec is not used, the home address destination option
may be faked, and its only use is to try to find out the
supposedly right socket that should receive the packet.
However, if there exists an entry in the Binding Cache,
you can use that entry to look up the right home address
anyway, and therefore you don't need the home address.
Thus, the only reason for sending a home address in the
Home Address Destiation Option is to use it for a Binding
Update.  But then again, you would be using Ipsec....
Ok, I admit that there is the case where you do not or
cannot send a BU but you still want to use your CoA
as the source address and home address in the dest opt.
However, the only reason for that is ingress filtering,
which is broken IMHO anyway.

Secondly, the method that you propose to create TMIs 
actually largely defeats your purpose.  That is, if you know
the home address, you can easily calculate the TMI, and you
can still follow the communications as easily as if you
were using the home address.  This even applies to the
subsequently generated TMIs.

What comes to security, I think that using TMIs would
make it even harder to authorize BUs.  In one way, when
a MN is the client and sends a TMI, it is no different
from e.g. PBK EIDs.  If they are clearly given a separate
address space, as you tentatively suggest, then the
problem might disappear.  However, if you allow overlapping
between TMIs and genuine home addresses, you actually
make it very easy to steal traffic destined to specific
home addresses unless you solve the address ownership problem.

--Pekka

---

From: Claude Castelluccia <[email-masked]>
Date: Tue, 20 Mar 2001 13:56:41 +0100

Hello Pekka and thanks for your comments.

>   draft-nikander-mobileip-homelessv6-01.txt

The reasons for not dropping the Home Address altogether
are the same that the reasons why we do not encrypt the Home Address
option.
There were some discussions about this issues few weeks ago on the
mailing list...
The reasons of keeping the Home Address (in cleartext) is:
- because IPSec uses it to locate the SA...if you remove the Home
Address
option you basically needs to use the CoA and since this CoA changes you

have to reestablished the SA each time you move...
- because some firewalls use it to perform some kind of filtering...

> subsequently generated TMIs.

In the draft  we suggest to generate the TMI as follows:
new TMI = MD5 ( Home address | current TMI),

if the current TMI is initialized with a random value, you won't be able
to
calculate the TMI even if you know the Home Address...
However if you know the current TMI and the home address, you will
be able to compute the next TMI....

We should probably use something like that:

new TMI = MD5 ( Home address | current TMI | random value),

thanks ! We will update the draft...

> a MN is the client and sends a TMI, it is no different

I am not sure...this depends the address owernship mechanism that
will be used...

> home addresses unless you solve the address ownership problem.

we have some ideas on how to do that....

thanks again for your comments,

Claude.

--

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

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 21 Mar 2001 07:35:26 +0200

> - because IPSec uses it to locate the SA...if you remove the Home Address

Hmm.  I am unsure about this.  Isn't SAs looked up by the SPI 
and the _destination_ address?  Quoting RFC2401, "A security 
association is uniquely identified by a triple consisting
of a Security Parameter Index (SPI), an IP Destination Address, 
and a security protocol (AH or ESP) identifier. "  The Home
Address Destination Option carries the source address, doen't it?

My understanding is that the home address destination option is
needed _only_ for looking up the right socket, and, as I have
explained, can be done by other means, too.

> - because some firewalls use it to perform some kind of filtering...

Yes, I know.  But, IMHO, that is _completely_ flawed since the
the firewalls cannot verify it's validity in any way.

> new TMI = MD5 ( Home address | current TMI),
snip
> new TMI = MD5 ( Home address | current TMI | random value),

Or maybe you can do even better by calculation a few TMIs beforehand
and using them then backwards.  But then you'd come directly to a
solution similar to what I suggest in the forthcoming pbk-addresses 
draft...

--Pekka

---

From: Jean-Michel COMBES <[email-masked]>
Date: Mon, 26 Mar 2001 16:23:55 +0200

Hi,

sorry for the delay ...

> Address Destination Option carries the source address, doen't it?

JMC :
yes ... but most of IPsec implementations need to have it (SPD) ...

> the firewalls cannot verify it's validity in any way.

JMC :
I don't think that a firewall have to verify the validity ... but to manage IP
traffic :
so you need Home-Address ...

> solution similar to what I suggest in the forthcoming pbk-addresses

Regards.
JMC.

--

France Telecom R&D - DTL/SSR
Jean-Michel COMBES, Internet/Intranet Security
E-Mail : [email-masked]
Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19
PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214

---

From: Michael Thomas <[email-masked]>
Date: Mon, 26 Mar 2001 13:21:53 -0800 (PST)

> - because some firewalls use it to perform some kind of filtering...

   You could do the same thing by placing the
   home address in the source address too. 

   In general, I think we need to be very careful
   about requiring intermediate routers to inspect
   things that are explicitly intended to be end
   to end. There are performance issues to be 
   considered when requiring routers to chase down 
   IP header chains. I'm aware that transport
   headers are in the same predicament, but that's
   a bug, not a feature in my mind.

	  Mike

---

From: Jean-Michel COMBES <[email-masked]>
Date: Mon, 26 Mar 2001 16:23:55 +0200

Hi,

sorry for the delay ...

JMC :

JMC :

Regards.
JMC.

--