Subject: Re: [MOBILE-IP] Placement for Binding Update and Home Address opt ions

From: Francis Dupont <[email-masked]>
Date: Fri, 24 Nov 2000 16:03:46 +0100

In your previous mail you wrote:

   Francis, Sorry for the delay, see my comments/ questions below:
   --------------------
    In your previous mail you wrote:

      => I agree, home address and tunnel encapsulation limit between routing
      and fragment, all other destination options (binding XXX) after ESP.

         Comments?

      Does this mean that we are leaving the home address information
      without confidentiality protection?

   => you can't easily make the home address confidential because the ESP
   processing needs to know the real source (ie. the home address) in
   the SA selector phase :
    - or you hack your IPsec implementation in order to get the home address
      and to use it
    - or you hack your IPsec implementation in order to skip the SA selector
      phase but you can introduce a security problem
    - or you build the SA with the care-of address and you have to rebuild
      it at each movement
   (then it is not easy as I've said :-).
   BTW why do you want to hide the home address information?
   ----------------

   I don't want to rock the boat, specially a titanic like IPSec, so I would
   safely assume that the first and second options are out of question.

=> Richard Draves argues for the first option and we are trying to know
if this will be a big problem or not for IPsec implementors.

   I also understand the importance of having the home address, on which the SA
   lookup and verification is based on, in the clear at the security check
   points, whether it is a gateway, firewall or the end unit.

=> yes, firewalls don't like confidentiality... I don't know what is the
most important, firewalls or confidentiality (your following arguments
are obviously pros for confidentiality).

   I guess hiding the home address cannot be required. I don't know how much
   the service providers want to protect their network topologies?
   But what if a mobile node desires to have location privacy (c/o of address
   or home address), like asking your phone company not to list your home phone
   number, or cell phone number. Isn't this a feature that a lot of people
   would want?

=> perhaps but in this case the only good solution is a secure bidirectional
tunnel with the home agent. This should be an option for mobile IPv6 but
I believe we should get the optimized mobile IPv6 first.

   I don't exactly know, how a mobile handles the binding requests? There is no
   requirement for authentication for binding requests?

=> a mobile answers to a binding request only if it has the relevant entry
in its binding cache (then there is no security constraints).

   So is there enough
   protection for the binding update, so intruders would not be able to get
   mobile's home and c/o address by sending a binding request to its home
   address? (or maybe its old c/o)

=> if the attacker doesn't know its home address it can do nothing,
if it knows then the protection relies on the mobile node policy
(for instance it should not try to optimize the routing).

   Hope I am not too far out in the woods %-)

=> no, security is full of trade-off issue and we don't want an insecure
mobility.

Regards

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Wed, 29 Nov 2000 09:28:37 +0100

<MN> Could you please elaborate on what you mean by hacking the IPSec
   implementation, would you decrypt what comes after the ESP header?

=> there are two problems:
 - RFC 2401 mandates a check of the source address (inner one in tunnel mode)
   after each IPsec header processing. Richard's idea is to delay the check
   until the home address option is processed or to chase for it further
   in the packet.
 - RFC 2401 doesn't mandate a check of the outer source address in tunnel mode
   but many implementations do this, in general in the SA lookup routine
   (ie. very soon).

   Does it not add a lot to the processing burden?

=> it is a major change for some implementations but we don't know the
   proportion of implementations which can be affected or the weight of
   the burden...

   <MN> I have to read about the creation of binding cache more seriously.
   According to what I am hearing, binding caches can be created regardless of
   SAs.

=> but they are created only on the reception of a valid (then authenticated,
this needs a SA) binding update.

   So if you know the mobile's home address, can you create a binding
   entry for yourself at the mobile's binding cache?

=> perhaps you mean the binding update list? An entry in it can be created
by any packet received by the mobile node if its policy accepts this (and
the usual policy is to do it at least for any packet received though the
tunnel with the home agent).

   and that way keep asking mobile about its c/o?

=> you don't need a binding update, the mobile will reveal its c/o address
in any answer. The only way to hide the c/o address is to use a reverse tunnel
from the mobile node to the home agent (ie. to use a fully not-optimized
version of mobile IPv6). If you want to secure the tunnel (ie. use ESP)
then you fallback in the IPsec tunnel + mobility issue again...

Thanks

PS: in the IPv4 world reverse tunnelling is optional but should be used
in many cases (because of ingress filtering for instance). In such cases
mobile IPv6 stuff can be used nearly as it (encapsulation and security
issues collapse to ESP tunnel).