Subject: [MOBILE-IP] mobile IPv6 & IPsec policies

From: Richard Draves <[email-masked]>
Date: Mon, 13 Nov 2000 21:06:10 -0800

I have some questions about the interactions between mobile IPv6 and IPsec
policy selection (SPD lookup) and IKE (SA negotiation) in
draft-ietf-mobileip-ipv6-12, especially sections 4.4 and 10.2. If this is
all obvious to others then perhaps the draft could be clarified. It's not
obvious to me and I don't know enough about IPsec & IKE to be certain of the
answers.

I believe the draft says/implies: the security policies on the mobile node
do not usually change when the mobile node moves, and policy lookups use
home addresses, not care-of addresses.

A. What policy selectors should be used when sending/receiving a Binding
Update? Section 10.2 says:

    -  As part of outbound packet processing in IP, the packet is
       compared against the IPsec Security Policy Database (SPD) to
       determine what processing is required for the packet [13].

    -  As a special case for Mobile IP, if a Binding Update or
       Binding Acknowledgement is being included in the packet, IPsec
       authentication, integrity protection, and replay protection MUST
       be applied to the packet [13, 11, 12], as defined in Section 4.4.
       If the SPD check above has already indicated that authentication
       and replay protection are required, this processing is sufficient
       for the Mobile IP requirement that all packets containing Binding
       Updates or Binding Acknowledgements be authenticated and covered
       by replay protection.  Otherwise, an implementation can force
       the required IPsec processing on this individual packet by, for
       example, creating a temporary SPD entry for the handling of this
       packet.

Suppose you are piggy-backing a Binding Update on a TCP or UDP packet, but
the selectors find a policy of "no IPsec needed" in the SPD. Then Mobile
IPv6 is saying, you should negotiate and use an SA anyway, because the
Binding Update needs to be protected. The suggestion is to create a
temporary SPD entry. What should this temporary SPD entry contain? What
transforms should be proposed in the ensuing IKE negotation? What if there
is a policy, but it doesn't provide the required protections - if you try to
negotiate an SA with IKE for transforms that aren't in the policy, isn't the
correspondent likely to reject the proposals when they don't match its
policy?

Suppose this is a "naked" Binding Update, not piggy-backed on a TCP or UDP
packet. What selectors should be used in the policy lookup? Should there be
a policy lookup at all, or should you instead try to find & use any suitable
existing SA between the two machines? It seems like a naked Binding Update
should reuse if possible an existing SA between the two machines.

B. Suppose the mobile node's home is in the same organization as the
correspondent node (ie normally no IPsec needed for communication between
home location & correspondent), but the mobile node is away from home. In
fact there is a Security Gateway between the mobile node and the
correspondent node, and the mobile node needs to use one SA to communicate
with the SG (say ESP tunnel-mode) and a second SA (say transport-mode AH) to
send binding-updates through to the correspondent node. A policy lookup on
the mobile node based solely on the home address will not work because the
result will be "no IPsec needed". Even if you force the use of IPsec to
protect the Binding Updates (as discussed above), you won't know to
negotiate a tunnel-mode SA and communicate via the SG.

One possibility (that I like) is that Mobile IPv6 effectively mandates that
policies that need communication via a security gateway must be implemented
in the routing table via a tunnel interface, instead of in the SPD. However,
mandating this style of implementation for security gateway policies would
be a departure from the base IPsec standard as I understand it. For one
thing, because routing table lookups are usually based just on destination
address and don't take into account the other IPsec selectors, this would
limit the kinds of policies that you could use.

An alternative would be to say the mobile node does TWO lookups in the SPD,
one using its home address and another using its care-of address, and merges
the resulting policies that it gets from those two lookups. Actually it gets
more complicated, because there might be an HA->CoA mapping for the
destination as well as the source address. The tunnel interface approach to
dealing with security gateways seems simpler.

Thanks,
Rich

---

From: Francis Dupont <[email-masked]>
Date: Tue, 14 Nov 2000 11:16:42 +0100

In your previous mail you wrote:

=> IPsec & IKE details are very implementation dependent...

=> this is the idea.

   temporary SPD entry.

=> this is one option. Another one is to send the Binding Update alone...

   What should this temporary SPD entry contain? What

=> I believe if no SA is already available (ie. the temporary SPD entry
will call IKE) then it is far simpler to send the Binding Update (or
Acknowledge) in its own packet. But if the SPD processing can pick up
a SA then the temporary SPD entry can be a good solution...

   Suppose this is a "naked" Binding Update, not piggy-backed on a TCP or UDP
   packet. What selectors should be used in the policy lookup?

=> this is a different issue. I use the "protocol" 60 (destination option
header type) but of course this has to be understood by the peer.
An interoperable solution is to use the "any protocol" but this will
protect every packets (and solve both issues BTW).

   Should there be

=> I agree but if you don't like to have a special processing because
of mobility you have to use the standard way (ie. SPD lookup, ...).

=> this is SPD implementation dependent but I believe it should work
because it should be able to handle both protection/SPD entries for
the SG and for the correspondent...

   be a departure from the base IPsec standard as I understand it.

=> no but it is an implementation choice not yet understood (then without
consensus :-) by many IPsec folk.

   An alternative would be to say the mobile node does TWO lookups in the SPD,
   one using its home address and another using its care-of address, and merges
   the resulting policies that it gets from those two lookups.

=> if I have understood the problem is in the merge between the mobility
policy (with the correspondent) and the local/visit policy (use the SG).
If the second is not for the care-of address but for a wildcard address
(or the outgoing interface) then the merge seems possible (no conflict).
(my idea is the local/visit policy is a "situation" policy then the source
address is not the selector of choice)

   Actually it gets
   more complicated, because there might be an HA->CoA mapping for the
   destination as well as the source address.

=> for destination the things can be more transparent,

   The tunnel interface approach to
   dealing with security gateways seems simpler.

=> but are you ready to have link-local addresses for an IPsec tunnel
(ie. a SA in tunnel mode) ???

Regards

[email-masked]