Subject: [mobile-ip] Re: IPsec and Mobile IPv6

From: Jari Arkko <[email-masked]>
Date: Wed, 17 Jul 2002 08:53:48 +0300

Hi Francis,

> The second version of my draft about IPsec and Mobile IPv6 is
> available (name : draft-dupont-ipsec-mipv6-01.txt).

(Sorry for the crosspost -- perhaps replies can go to the mobile ip
list only.)

Your draft looks like a very useful analysis of various cases
regarding mobility and IPsec. But I still lack some practical
background information so that this work could be taken in account
in the relevant protocol descriptions. In particular, could you
classify your recommendations as

   1) Those that restate something which already is in the
      current protocol specifications (but perhaps not stated
      clearly enough).

   2) Those which fix something that would break MIPv6
      security. Draft draft-ietf-mobileip-ipv6-18.txt uses IPsec
      for a part of its security, namely for the HA - MN signaling.
      A more detailed description including SPD entries can be
      found from http://www.piuha.net/~jarkko/publications/mipv6/ipsec_usage.txt

   3) Those which fix something that would break IPsec
      when used for protecting regular payload traffic
      in the presense of MIPv6.

   4) Those that make IPsec work smoother, more efficiently, or
      with less configuration when used together with mobility
      or for the protection of mobility signaling.

   5) Architectural long-term recommendations.

   6) Something completely different.

In particular class 2 is interesting for completing the MIPv6 work,
as is class 3. From my initial understanding, your recommendations
can be classified as follows:

    1) A, C1, C2, E1, E2, E3, G, H, I, K, M, O, Q
    2) P [makes use of IKE for HA-MN security hard -- this is
       very interesting, thanks!]
    3) nothing?
    4) B, F [and I think we were disagreeing on the mip list whether
       these two are good goals], L1, L2, R
    5) nothing?
    6) D [of course!], J
    unclear: N

Is this correct? How do we go about fixing P, is your recommendation
the only way to handle that? Is there anything in the MIPv6 documents
that you'd like to clarify in class 1?

Jari

---

From: Francis Dupont <[email-masked]>
Date: Sun, 21 Jul 2002 17:35:19 +0200

I've revisited your classification:

       1A) [Already in IPsec specs]
           C1, C2, G, H, I, J, L1, L2, M, Q, R

       1B) [Already in Mobile IPv6 specs]
           A, E1, E2, E3, O

       2) [Fixes for Mobile IPv6]
          N, P

       3) [Fixes for IPsec in a Mobile IPv6 context]
          none

       4) [IPsec improvements for Mobile IPv6]
          B, F, K

       5) [Architectural long-term recommendations]
          Appendix B

       6) [Other stuffs]
          D, Appendix D

   Is there anything in the MIPv6 documents that you'd like to clarify
   in class 1?
   
=> I believe we should make the mobile VPN a subset of Mobile IPv6.
Mostly we have to relax the usage of tunnels between a CN and a MN,
in current specifications we have for the CN:
 - if the packet is not genuine (i.e., is forwarded):
   * nothing if the CN is not the HA
   * tunneling if the CN is the HA
 - lookup in the binding cache per CN address
   * nothing is no entry found, fallback to the previous case on the HA
   * routing header if a valid entry is found.
On a mobile VPN CNs have no BC and the SG takes the role of the HA but
it puts all packets in the tunnel, so I propose to relax the Mobile IPv6
rules in two ways:
 - tunneling may replace the routing header (this is useful for the
   mobile to mobile case too)
 - the only mandatory usage of a routing header is for signaling
   (i.e., for genuine packets with a mobile header).
For the MN, the obvious thing is to authorize tunneling in place of
the HAO for non-signaling traffic.

Regards

[email-masked]