Subject: [Mip6] MIPv6 use of IPsec

From: "Michael Roe" <[email-masked]>
Date: Mon, 25 Oct 2004 17:29:36 +0100

At the ETSI IPv6 plugtest, I encountered some interoperability problems
with MIPv6 use of IPSec. I am starting to think that replacements for
RFC 3776 (e.g. the IKEv2 and MIPv6 document) ought to give more detail
on what is mandatory to implement - so that we can guarantee that a
conforming MN and a conforming HA will be able to talk to each other.

There are (at least) three ways to IPSec protect RR and payload packets
between a MN and HA:

a) RR signalling uses SA3/SA4; payload packets use IP-in-IP (not IPSec) encapulation

b) RR signalling and payload packets use the SAME pair of Sas

c) RR signalling and payload packets use a DIFFERENT pair of Sas
   (SA4/SA4 for RR, SA7/SA8 for payload)

The Microsoft implementation only supports option (b). I believe that
KAME can also support (b).

RFC 3776 says this:

   o  ESP encapsulation of the Home Test Init and Home Test messages
      tunneled between the mobile node and home agent MUST be supported
      and SHOULD be used.

   o  ESP encapsulation of the ICMPv6 messages related to prefix
      discovery MUST be supported and SHOULD be used.

   o  ESP encapsulation of the payload packets tunneled between the
      mobile node and home agent MAY be supported and used.

But this isn't enough to guarantee interoperability. An implementation that
only supports (a) is conforming, but so is an implementation that only supports
(c), and the two don't interoperate.

For example, RFC 3775 does not say that IP-in-IP encapsulation of payload
packets MUST be implemented. Should it?

RFC 3775 isn't very clear on whether you should implement (b) or (c) if you
support ESP encapsulation of payload packets. Part of the problem is that
the IPSec security policy database is an ordered list, but RFC 3775 doesn't
say what order the rules are in. Does the rule in section 5.2.4 have higher
priority than the rule in section 5.2.2 (in which case we have option b) or
is it the other way round (in which case we have option c)?

The rules are:

     home agent SPD OUT:
       - IF interface = IPv6 tunnel to home_address_1 &
            source = any & destination = home_address_1 &
            proto = MH
         THEN USE SA SA4

     home agent SPD OUT:
       - IF interface = IPv6 tunnel to home_address_1 &
            source = any & destination = home_address_1 &
            proto = X
         THEN USE SA SA8

Suppose have "interface = IPv6 tunnel to home_address_1", source = any,
destination = home_address_1 and proto = MH. Both rules match. Do we
use SA4 or SA8?

Some practical considerations:
1) For performance reasons, some people might want to use different crypto
transforms for SA3/4 and SA7/8, e.g. authentication-only for SA7/8.

2) The more SPD entries we have, the longer it takes to configure MIPv6:
   there are more SPI values and crypto keys to enter manually. From a
   usability point of view, 6 security associations are quicker to configure
   than 8.

3) The "interface = IPv6 tunnel to home_address_1" business gives rise to
   implementation problems that would make it non-trivial for us to support
   both (b) and (c).

Mike

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 27 Oct 2004 00:31:49 -0700

hi,

> packets MUST be implemented. Should it?

actually it does. RFC 2473 is referenced and there is the following text

    Each intercepted
    packet is tunneled to the mobile node's primary care-of address.
    This tunneling is performed using IPv6 encapsulation [15].

in section 8.5

    o  The node MUST be able to perform IPv6 encapsulation and
       decapsulation [15].

[15] is RFC 2473.

> support ESP encapsulation of payload packets. 

both MN and HA must support a) and must support b) or c). they should
use b) or c), if the reverse tunneled payload traffic needs to be
protected by IPsec. they should use a), if the reverse tunneled payload
traffic does not need IPsec protection. this is my understanding.

> Part of the problem is that

the SPD entries in RFC 3776 are ordered. in section 5.2.2

    Note that the rules in the SPD are ordered, and the ones
    in the previous section must take precedence over these ones.

in section 5.2.4

    It is assumed that the entries for
    protecting Binding Updates and Acknowledgements, and the entries to
    protect Home Test Init and Home Test messages take precedence over
    these entries.

you can have the following policy in your SPD to achieve (b).

   Mobile Node SPD OUT:
        IF interface = IPv6 tunnel to home_agent_1 &
            source = home_address_1 & destination = any &
            proto = any
        THEN USE SA some_tunnel_sa

you can ignore the SPD entries in section 5.2.2 and 5.2.4 and have
the just the above SPD. and you make sure you negotiate only such
an SA with the Home Agent.

> destination = home_address_1 and proto = MH. Both rules match. Do we

they are ordered. so the first one matches.

>    implementation problems that would make it non-trivial for us to support

if you are using IKE, there shouldnt be a problem negotiating security
associations for either b) or c). but at any time, I see only either
b) or c) used. not both.

Vijay

---

From: Francis Dupont <[email-masked]>
Date: Thu, 28 Oct 2004 00:04:40 +0200

Michael, can you resend (if not already done) your mail with a more
common charset and encoding (i.e., not UTF-8 in base64) ?
BTW I agree but for another reason: with IKEv2 you can have multiple
traffic selectors for the same SPD entry so explicitly share SAs...

Regards

[email-masked]