[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: mobile IPv6 & IPsec policies

I had an old address for the ipsec list in my original email, so please
reply to this email instead.

-----Original Message-----
From: Richard Draves 
Sent: Monday, November 13, 2000 9:06 PM
To: Mobile IP (E-mail); IPsec (E-mail)
Subject: mobile IPv6 & IPsec policies


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