Subject: [mobile-ip] rules for using IPsec for MN-HA protection

From: Jari Arkko <[email-masked]>
Date: Sat, 13 Jul 2002 03:55:40 +0300

Due to several requests, we have created some text that describes
how IPsec is set up to protect MN-HA BUs and other messages, what
the order processing is, what headers will be included in the sent
packets, etc.

Please send us feedback on these rules. Also, let us know if you
feel some of this information should go to the MIPv6 draft in some
form (I think James was suggesting something like this perhaps).

Jari

USING IPSEC TO PROTECT MOBILE IPV6

July 12th, 2002
Jari Arkko and Vijay Devaparalli

1. INTRODUCTION

Mobile IPv6 uses 

2. SPD Entries

In the following we describe the SPD and SAD entries necessary to
protect BUs and BAs exchanged between the mobile node and the home
agent. We assume ESP is used with manually configured SAs.

  MN SPD: - if src = HoA, dst = HA  and proto = MH, use SA1
          - if src = HA,  dst = HoA and proto = MH, use SA2
  MN SAD: - SA1 (ESP): src = HoA, dst = HA,  Mode = transport, SPI = 1
          - SA2 (ESP): src = HA,  dst = HoA, Mode = transport, SPI = 2

  HA SPD: - if src = HA,  dst = HoA and proto = MH, use SA3
          - if src = HoA, dst = HA  and proto = MH, use SA4
  HA SAD: - SA3 (ESP): src = HA,  dst = HoA, Mode = transport, SPI = 2
          - SA4 (ESP): src = HoA, dst = HA,  Mode = transport, SPI = 1

In the following we describe the necessary SPD and SAD entries to
protect RR signaling between the mobile node and the home agent.
Note that the rules in the SPD are ordered, and the ones above
take precedence over these ones:

  MN SPD: - if src = HoA, dst = *   and proto = MH, use SA5
          - if src = *,   dst = HoA and proto = MH, use SA6
  MN SAD: - SA5 (ESP): src = HoA, dst = *,   Mode = tunnel to HA, SPI = 5
          - SA6 (ESP): src = *,   dst = HoA, Mode = tunnel,       SPI = 6

  HA SPD: - if src = *,   dst = HoA and proto = MH, use SA7
          - if src = HoA, dst = *   and proto = MH, use SA8
  HA SAD: - SA7 (ESP): src = *,   dst = HoA, Mode = tunnel to HoA, SPI = 6
          - SA8 (ESP): src = HoA, dst = *,   Mode = tunnel,        SPI = 5

It is also possible to perform some additional, optional, protection
of tunneled payload packets. This protection would take place in a
similar manner to the RR protection above, but would require a
different value for the protocol field. For brevity, we do not repeat
the SPD entries here.

In the following we describe some additional SPD and SAD entries to
protect prefix discovery. (Note that when actual new prefixes are
discovered, there may be a need to enter new manually configured SAs
to protect BUs.)

  MN SPD: - if src = HoA, dst = HA  and proto = ICMPv6, use SA9
          - if src = HA,  dst = HoA and proto = ICMPv6, use SA10
  MN SAD: - SA9  (ESP): src = HoA, dst = HA,  Mode = transport, SPI = 9
          - SA10 (ESP): src = HA,  dst = HoA, Mode = transport, SPI = 10

  HA SPD: - if src = HA,  dst = HoA and proto = ICMPv6, use SA11
          - if src = HoA, dst = HA  and proto = ICMPv6, use SA12
  HA SAD: - SA11 (ESP): src = HA,  dst = HoA, Mode = transport, SPI = 10
          - SA12 (ESP): src = HoA, dst = HA,  Mode = transport, SPI = 9

3. Packet Formats

In this section we describe the order of headers within the protected
and tunneled packets over the wire.

The BUs sent from the mobile node to the home agent look like this:

   IPv6 hdr (src=CoA, dst=HA)
   Dst Opt
      HAO
   ESP hdr
   Mobility hdr
      BU

The BAs sent back to the mobile node look like this:

   IPv6 hdr (src=HA, dst=CoA)
   Routing hdr
      HoA
   ESP hdr
   Mobility hdr
      BA

The HoTI messages tunneled to the HA look like this:

   IPv6 hdr (CoA, HA)
   Dst Opt
      HAO
   ESP hdr
   IPv6 hdr (HoA, CN)
   Mobility Hdr
      HoTI

The HoT messages tunneled from the HA look like this:

   IPv6 hdr (HA, CoA)
   Routing hdr
      HoA
   ESP hdr
   IPv6 hdr (CN, HoA)
   Mobility Hdr
      HoT

4. Procedures

4.1. Procedures for Sending a BU to the HA

- At the MN, MIPv6 module first produces the following packet

   IPv6 hdr (src=HoA, dst=HA)
   Mobility hdr
      BU

- This packet is detected by the IPsec filters on the MN and results in

   IPv6 hdr (src=HoA, dst=HA)
   ESP hdr
   Mobility hdr
      BU

- Before forwarding the packet, the HAO (home address option) is inserted
  into the packet

   IPv6 hdr (src=CoA, dst=HA)
   Dst Opt
      HAO
   ESP hdr
   Mobility hdr
      BU

4.2. Procedures for Receiving a BU from the MN

- The following packet is received at the HA

   IPv6 hdr (src=CoA, dst=HA)
   Dst Opt
      HAO
   ESP hdr
   Mobility hdr
      BU

- The home address option is processed first, which results in

   IPv6 hdr (src=HoA, dst=HA)
   Dst Opt
      HAO
   ESP hdr
   Mobility hdr
      BU

- ESP hdr is processed next, resulting in

    IPv6 hdr (src=HoA, dst=HA)
    Dst Opt
       HAO
    Mobility hdr
       BU

- This packet matches the selectors (src = HoA, dst = HA, proto = MH).

- The BU is delived to the MIPv6 module.

4.3. Procedures for Sending a BA to the MN

- MIPv6 produces the following packet

   IPv6 hdr (src=HA, dst=HoA)
   Mobility hdr
      BA

- This packet is picked up by the IPsec policy filters resulting in
  the use of SA3:

   IPv6 hdr (src=HA, dst=HoA)
   ESP hdr
   Mobility hdr
      BA

- Before forwarding the packet, the packet is compared against the
  binding cache and results in:

   IPv6 hdr (src=HA, dst=CoA)
   Routing hdr
      HoA
   ESP hdr
   Mobility hdr
      BA

4.4. Procedures for Receiving a BA from the HA

- The following packet is received at the MN

   IPv6 hdr (src=HA, dst=CoA)
   Routing hdr
      HoA
   ESP hdr
   Mobility hdr
      BA

- After the routing header is processed the packet becomes

   IPv6 hdr (src=HA, dst=HoA)
   Routing hdr
      CoA
   ESP hdr
   Mobility hdr
      BA

- ESP hdr is processed next, resulting in:

   IPv6 hdr (src=HA, dst=HoA)
   Routing hdr
      CoA
   Mobility hdr
      BA

- The BA is delived to the MIPv6 module.

4.5. Procedures for Tunneling a HoTI to the HA

- The MN constructs a HoTI message:

   IPv6 hdr (src=HoA, dst=CN)
   Mobility hdr
      HoTI

- This matches the SPD entry for IPsec processing,
  resulting in:

   IPv6 hdr (src=HoA, dst=HA)
   ESP hdr
   IPv6 hdr (src=HoA, dst=CN)
   Mobility hdr
      HoTI

- The MIPv6 code adds a Home Address option:

   IPv6 hdr (src=CoA, dst=HA)
   Dst Opt
      HAO
   ESP hdr
   IPv6 hdr (src=HoA, dst=CN)
   Mobility Hdr
      HoTI

4.6. Procedures for Receiving a Tunneled HoTI from the MN

- The HA receives the following packet:

   IPv6 hdr (src=CoA, dst=HA)
   Dst Opt
      HAO
   ESP hdr
   IPv6 hdr (src=HoA, dst=CN)
   Mobility Hdr
      HoTI

- The home address option is processed first, which results in

   IPv6 hdr (src=HoA, dst=HA)
   Dst Opt
      CoA
   ESP hdr
   IPv6 hdr (src=HoA, dst=CN)
   Mobility Hdr
      HoTI

- ESP is processed next, resulting in

   IPv6 hdr (src=HoA, dst=CN)
   Mobility Hdr
      HoTI

- The packet is then forwarded towards the CN

4.7. Procedures for Tunneling a HoT to the MN

- The HA receives a HoT packet from the CN:

   IPv6 hdr (src=CN, dst=HoA)
   Mobility Hdr
      HoTI

- This matches the IPsec SPD entries, resulting in the
  application of SA7:

   IPv6 hdr (src=HA, dst=HoA)
   ESP hdr
   IPv6 hdr (src=CN, dst=HoA)
   Mobility Hdr
      HoTI

- After the routing header is processed the packet becomes

   IPv6 hdr (src=HA, dst=CoA)
   Routing hdr
      HoA
   ESP hdr
   IPv6 hdr (src=CN, dst=HoA)
   Mobility Hdr
      HoTI

4.8. Procedures for Receiving a Tunneled HoT from the HA

- The MN receives the following packet:

   IPv6 hdr (src=HA, dst=CoA)
   Routing hdr
      HoA
   ESP hdr
   IPv6 hdr (src=CN, dst=HoA)
   Mobility Hdr
      HoTI

- After the routing header is processed the packet becomes

   IPv6 hdr (src=HA, dst=HoA)
   Routing hdr
      CoA
   ESP hdr
   IPv6 hdr (src=CN, dst=HoA)
   Mobility Hdr
      HoTI

- ESP is processed next, resulting in:

   IPv6 hdr (src=CN, dst=HoA)
   Mobility Hdr
      HoTI

- This matches the selectors (src = *, dst = HoA) and the packet is
  given to MIPv6 processing.

5. Conclusions

All addresses in the SPD entries, in the selectors, and in the tunnel
gateway settings shall use the home address of the mobile node, and
not the care-of address.

For outbound packets, IPsec processing shall take place before
mobility processing (routing headers, HAO, tunnel headers). For
inbound packets, mobility processing shall take place before IPsec.
All this is normal behaviour in any case.

Some packets -- such as HoTI and HoT -- are protected by IPsec when
tunneled via the home agent. At the HA, packet interception shall be
followed by IPsec processing, and mobility delivery processing shall
take place after IPsec processing. If IPsec processing does not add
anything (like for example a data packet from CN to MN), the BC lookup
will result in the addition of a tunnel (src = HA, dest = CoA, no
routing header) to the data packet.  if IPsec processing adds
something (like a tunnel for HoT message), BC lookup will result in
the addition of a routing header.

---

From: "James Kempf" <[email-masked]>
Date: Sat, 13 Jul 2002 06:10:09 -0700

One question: 

    Are manual SAs required or was that just a convenience for specifying what the SPD and SAD entries look like?

            jak

----- Original Message ----- 
From: "Jari Arkko" <[email-masked]>
To: <[email-masked]>
Cc: "Vijay Devarapalli" <[email-masked]>
Sent: Friday, July 12, 2002 5:55 PM
Subject: [mobile-ip] rules for using IPsec for MN-HA protection

> form (I think James was suggesting something like this perhaps).

--------------------------------------------------------------------------------

---

From: "James Kempf" <[email-masked]>
Date: Sat, 13 Jul 2002 06:08:01 -0700

Excellent! That is what I was looking for.

            jak

---

From: Francis Dupont <[email-masked]>
Date: Mon, 15 Jul 2002 03:33:28 +0200

2. SPD Entries
   
=> you should add the direction (in/out) and (funny?) the interface.

    We assume ESP is used with manually configured SAs.
   
=> I have a real concern about this assumption: we should use
something like IKE (and we know how to use it in fact, don't forget
that near I-D 13 we had some interoperable implementations with full
IPsec). BTW low SPIs are *reserved*. Last point, for these entries
(i.e., not the RR pair, ...), AH is enough and should be allowed.

   3. Packet Formats

      IPv6 hdr (CoA, HA)
      Dst Opt
         HAO

=> why a HAO here? This is a *tunnel*!

      ESP hdr
      IPv6 hdr (HoA, CN)
      Mobility Hdr
         HoTI

      IPv6 hdr (HA, CoA)
      Routing hdr
         HoA

=> same concern.

      ESP hdr
      IPv6 hdr (CN, HoA)
      Mobility Hdr
         HoT

   
   
=> NO, the tunnel has CoA and HA outer addresses!

   
   
=> same problem.

   5. Conclusions

=> please add "traffic" before the word "selectors".

   
=> no, it is deeply stupid to add a degenerated tunnel stuff to
an already encapsulated packet: just use the correct addresses!

Regards

[email-masked]

---

From: Jari Arkko <[email-masked]>
Date: Mon, 15 Jul 2002 07:03:35 +0300

> Are manual SAs required or was that just a convenience for specifying what the SPD and SAD entries look like?

Dynamically established SAs are also possible. A different security
policy set up is needed. Or to be more exact, a different security
policy set up is more useful with dynamic keying, as you may not need
to deal with individual entries for all mobile nodes.

It looks like it would be useful to have some text that describes
the dynamic set up as well.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Mon, 15 Jul 2002 07:33:27 +0300

Thanks Francis for taking a look at this. I was about to ask you to

> => you should add the direction (in/out) and (funny?) the interface.

Yes.

> IPsec).

I agree... the intention is to write another example that shows how
to set up IKE-based security.

> BTW low SPIs are *reserved*.

Right ;-)

> Last point, for these entries

Agreed. Draft 18 should allow any type of IPsec to be used (except
for RR encryption). The text above should have read "Our examples
assume ESP is used..."

>    The HoT messages tunneled from the HA look like this:

The question is: do we first encapsulate in an IPv6 tunnel due to
normal MIPv6 tunneling principles and then apply IPsec, or do we
first apply IPsec and only then check if MIPv6 tunneling is
necessary?

If we do the former, I'm not sure how we can make the SPD
entries specific enough so that they would match only the MH
messages, but leave rest of traffic in the clear. Can IPsec
SPD entries see through the tunnel header?

> => NO, the tunnel has CoA and HA outer addresses!

See above for a discussion of tunnel-first-then-ipsec vs.
ipsec-first-then-tunnel.
 
> => please add "traffic" before the word "selectors".

Ok.

> an already encapsulated packet: just use the correct addresses!

Let me first check if you are objecting

1) The order, ipsec-first-then-tunnel?
2) The addition of a tunnel in the ipsec-does-not-add-anything
    case above? I suppose not, this is normal MIPv6 tunneling from the
    HA.
3) The addition of RH to the IPsec-tunneled packet?

I'm assuming you must talk about #3.

This is a design choice. We could either use HoA or CoA as the destination
of the tunnel. If we use the HoA (as we have suggested), the IPsec SPD
and SAD entries are static and do not have to be modified when the MN
moves. This eliminates the need for coordination between the MIPv6 and
IPsec code parts. The disadvantage is an additional RH in the packet (24
bytes?). I suppose it would also be possible to use the CoA as the
destination of the tunnel, but then we need the API.

Jari

---

From: Francis Dupont <[email-masked]>
Date: Mon, 15 Jul 2002 07:13:25 +0200

=> a hard question to begin: is the MN <-> HA tunnel an interface?   

   
=> this question is not sound because you specified a tunnel mode,
so the tunnel is both a MIPv6 and IPsec one (i.e., the worms are
going out of the can :-).

=> yes because they use traffic selectors in a tunnel mode...
Of course a transport mode over a tunnel should be different.

   

=> #3 because if your IPsec tunnel is correctly set up you should not
have to add something. I argue IPsec and Mobile IPv6 should cooperate,
I am trying to convince people in the ipsec WG (look at my draft
draft-dupont-ipsec-mipv6-01.txt) so I'd like to avoid the same issue
from mobileip WG: one encapsulation is enough, or with other words
why four addresses are not enough?

   This is a design choice.

=> without a discussion?

   We could either use HoA or CoA as the destination
   of the tunnel. If we use the HoA (as we have suggested), the IPsec SPD
   and SAD entries are static and do not have to be modified when the MN
   moves.

=> it seems you have not yet understood all the IPsec details:
the SPD and SAD entries don't change because the traffic selectors
are for the inner addresses... Of course the fact you can characterize
a SA with zero to four addresses (I have a reference for the five cases)
doesn't really help (:-).

   This eliminates the need for coordination between the MIPv6 and
   IPsec code parts.

=> this coordination is a good target. I strongly object to avoid
it (i.e., don't put a MUST for the HOA/RH here).

   The disadvantage is an additional RH in the packet (24
   bytes?). I suppose it would also be possible to use the CoA as the
   destination of the tunnel, but then we need the API.
   
=> you need something or you won't be able to establish the SA pair
for the MN-HA BU/BA exchange (don't forget the MN side selector is
the HoA and you can't use the HoA until the BU is processed).
My suggession is to get the whole stuff: current IKE is being modified
(in drafts for IKEv1, directly in IKEv2) for NAT traversal (an ipsec
WG charter item) which is intrinsically insecure. With some good
arguments we can get a good mobility/multi-homing support (without
the security bug).

Regards

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 15 Jul 2002 15:06:04 -0700

hi Francis,

> => a hard question to begin: is the MN <-> HA tunnel an interface?

the tunnel end point changes every time the MN moves. 

> Of course a transport mode over a tunnel should be different.

lets assume the MN receives the following packet. it is a tunneled
HoT message.

IPv6 hdr (HA, CoA)
ESP hdr
IPv6 hdr (CN, HoA)
Mobility hdr
     HoT

to pick the right SA, the MN needs destination address, SPI and IPsec
protocol. it is missing the destination address. the only way out
seemed to be to add the routing header.

> why four addresses are not enough?

this draft is good. I am not on the IPsec mailing list. has this been
discussed there? is it being adopted? is there anything Mobile IP WG
can do to help?

> it (i.e., don't put a MUST for the HOA/RH here).

the MUST can definitely be avoided. but for IPsec and MIPv6 to
work together as they are currently defined, I think we need HAO 
and RH.

regards
Vijay

---

From: Francis Dupont <[email-masked]>
Date: Tue, 16 Jul 2002 03:40:40 +0200

=> is it a tentative answer to the question (:-)?

   
   IPv6 hdr (HA, CoA)
   ESP hdr
   IPv6 hdr (CN, HoA)
   Mobility hdr
        HoT

=> no, if the RH is before the ESP hdr this argument doesn't apply.

   > why four addresses are not enough?
   
   this draft is good.

=> thanks!

   I am not on the IPsec mailing list. has this been discussed there?

=> not yet but I am trying to get a slot in the ipsec WG session
Wednesday.

   is it being adopted? is there anything Mobile IP WG can do to help?
   
=> IMHO mobile-ip WG people should ask for a better support for
mobility and multi-homing in IPsec, including the Son-Of-Ike.
Today there is only a buggy NAT-traversal (because it is in the charter)
and a half-baked multi-homing support (from SCTP).

   
=> I disagree. And as the SAD description in the original message
doesn't give the outer addresses I can't see your reasoning.

Regards

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 15 Jul 2002 19:00:06 -0700

> => no, if the RH is before the ESP hdr this argument doesn't apply.

hold it. I am not sure we are talking about the same thing. you mean
something like this?

IPv6 hdr (HA, CoA)
Routing hdr (HoA)
ESP hdr
IPv6 hdr (CN, HoA)
Mobility hdr
     HoT

if yes, this is what is there in the writeup. if no, I dont follow.

Vijay

---

From: Francis Dupont <[email-masked]>
Date: Tue, 16 Jul 2002 04:13:01 +0200

IPv6 hdr (HA, CoA)
   Routing hdr (HoA)
   ESP hdr
   IPv6 hdr (CN, HoA)
   Mobility hdr
        HoT
   
=> yes, this is in the original message. And as the inbound processing
puts the HoA in the source IPsec doesn't see the CoA and is happy.
My concern is that if it works there is a more efficient solution.

Regards

---

From: Michael Thomas <[email-masked]>
Date: Wed, 24 Jul 2002 15:12:57 -0700 (PDT)

Sorry to take so long to get around to this...

 > first apply IPsec and only then check if MIPv6 tunneling is

   IMO, it should be IP6+MIP+ESP since MIP is essentially
   a routing layer construct. Also: there's no need to
   ever protect the MIP IP-IP tunnel header itself.

 > SPD entries see through the tunnel header?

   Do we actually care? What are the chances that somebody
   would go through the motions of setting up a tunnel *only*
   for MIP BU traffic? It seems pretty clear to me that 
   VPN+HA is going to be a very popular combination for
   road warriors trying to get past the corporate
   edge. Or am I misreading this?

   Also: IMO the longer term solution here is to
   allow IPsec tunnels to be used instead of IP-IP
   tunnels to get rid of the redundant tunnel
   layer. (backward compatible, yadda yadda).

		    Mike

---

From: Jari Arkko <[email-masked]>
Date: Fri, 26 Jul 2002 12:07:56 +0300

>    edge. Or am I misreading this?

It's probably going to be popular, yes. But there also seems to
be quite many folks who don't want to be forced into doing IPsec
for all of their traffic just because they wanted to protect (a)
BUs to HAs and (b) HOTIs/HOTs routed through the HA. So, we need
to have a way to be selective about the traffic. HA is easy, because
there is unlikely to be any other traffic between the HA and the MN
besides the BUs. The HOTI/HOT case is tougher, because we need
to be selective and not e.g. encrypt all the web browsing traffic
that the MN is doing.

So I think it is a requirement that the HOTs/HOTIs be protected
separately from the rest of the payload traffic.

Jari

---

From: Francis Dupont <[email-masked]>
Date: Sat, 27 Jul 2002 17:51:09 +0200

It's probably going to be popular, yes. But there also seems to
   be quite many folks who don't want to be forced into doing IPsec
   for all of their traffic just because they wanted to protect (a)
   BUs to HAs and (b) HOTIs/HOTs routed through the HA.

=> note that (a) is transport mode.

=> I disagree: you should stand HOTs/HOTIs must be protected and
leave the "separately" to implementors' choice. In fact IMHO:
 - protection requirements should be "MUSTs"
 - standard/smart way to do it should be "SHOULDs"
 - there must be some "MAYs" for alternative less efficient but
   easier in some cases solutions. The protection of the whole
   traffic through the MN-HA tunnel is a good example of this.

Regards