Subject: Re: [MOBILE-IP] New draft for Mobile IPv6

From: Richard Draves <[email-masked]>
Date: Sat, 18 Nov 2000 22:52:10 -0800

> A revised Internet Draft is available for "Mobility Support
> for IPv6" is
> available
> at the following URL:
>     http://www.diameter.org/charliep/txt/mobilev6/mobilev6.txt
>
> This draft has been submitted to the Internet Draft
> directories, and is
> intended
> to address all the issues that have been raised during working group
> Last Call.

I'm still looking for clarification of the issues I raised in the below
email. I've only seen one response (thanks Francis) and it left me with the
impression that there isn't consensus on these questions, which are rather
important for interoperability.

Thanks,
Rich

> -----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
>

---

From: Mattias Pettersson <[email-masked]>
Date: Tue, 21 Nov 2000 17:04:41 +0100

> important for interoperability.
I would go for Home Address option between Routing Header and Fragment
Header. IMHO this is the logical place to put it with respect to the
order headers are processed and with no respect to existing
implementations of whatsoever protocol.

If we have a chance to put it where it should belong, let's do it before
specs get more fixed.

/Mattias