Subject: [mobile-ip] Protecting the MN-HA signaling with IPsec

From: Jari Arkko <[email-masked]>
Date: Fri, 20 Sep 2002 08:52:54 +0300

Hi,

As you recall, issue #69 was a complaint that our specification does
not describe in sufficient detail how to use IPsec to protect the MN-HA
signaling. As a result of that, Vijay and myself wrote a note that
was posted to the list. This note was brief and didn't include everything.
We also debated some aspects of the note.

With Francis and Vijay, we have now written an expanded note in draft
form. The intention of this draft is to become a companion RFC for
the base MIPv6 specification and to illustrate in detail all aspects
of the issue: processing requirements, packet formats, configuration
procedures, and internal processing order. The normative processing
requirements will stay in the base RFC, however (with some updates
needed). But seeing only those processing requirements it isn't
very easy to understand the whole picture, and it may not be enough
to convince ourselves and the IESG that this actually works ;-)

The draft has been submitted, but before it appears in the official
directories, you can access it at the following URL:

   http://www.piuha.net/~jarkko/publications/mipv6/draft-ietf-mobileip-mipv6-ha-ipsec-00.txt

Writing this draft involved coming up with solutions to certain issues
such as how to use dynamic keying without causing chicken-and-egg problems.
You probably also recall Francis' draft which listed a number of issues
that were either necessary to fix before IPsec and MIPv6 worked together,
or optimized their behavior when used together. Finally, we made some
design choices (how easy the rules are for BITS implemenations etc) that
could perhaps be debated. So take a look at Section 10 for a discussion
of some of these hard issues.

Jari

---

From: Keiichi SHIMA / 島慶一 <[email-masked]>
Date: Fri, 20 Sep 2002 16:40:32 +0900 (JST)

Hi,

I have a question.

In section 5.2, the wire format of the HoTI packet is described as
follows:

>        IPv6 header (source = care-of address, destination = home agent)
>        ESP header
>        IPv6 header (source = home address, destination = correspondent node)
>        Mobility Header
>           Home Test Init

But, in section 6, the draft says as:

>          - If the mobile node tunnels Home Test Init messages or pay-
>          load packets via the home agent with IPsec protection, the
>          mobile node MUST use the Home Address destination and IPsec
>          tunnel mode encapsulation.

Which is correct?

And, same question about the format of the HoT packet.  In section
5.2, there is no RTHDR2 in the wire format, but in section 6, the
draft says 'the home anget MUST use the Type 2 Routing header and
IPsec tunnel mode encapsulation.'

Best Regards,
---
Keiichi SHIMA
IIJ Research Laboratory <[email-masked]>
KAME Project <[email-masked]>

---

From: Francis Dupont <[email-masked]>
Date: Fri, 20 Sep 2002 09:55:52 +0200

Which is correct?
   
=> of course not. But this is solved in the (just posted) new draft
draft-ietf-mobileip-mipv6-ha-ipsec-00.txt) !

=> this is the same issue.

Regards

[email-masked]

---

From: Keiichi SHIMA / 島慶一 <[email-masked]>
Date: Fri, 20 Sep 2002 17:33:28 +0900 (JST)

Hi Francis,

From: Francis Dupont <[email-masked]>

> draft-ietf-mobileip-mipv6-ha-ipsec-00.txt) !

OK.  My next question is (i'm sorry if this had been already discussed
in the list but I couldn't find related threads), why not to use home
address destination option and rthdr type2 for an outer header of the
tunneling packets?  Just to save some bits?

If we uses a tunnel mode encapsulation between a mobile node's home
address and the home agent address (if I remember correctly, this is a
proposed style before), we do not need to manage SA pair from Mobile
IPv6 stack.  If we do so, I guess we need not to define an IPsec
API(listed as an open issues in section 10) to manage SA from the
Mobile IPv6.

Best Regards,

---
Keiichi SHIMA

---

From: Francis Dupont <[email-masked]>
Date: Fri, 20 Sep 2002 11:21:09 +0200

=> in fact there are two possibilities :
 - either the IPsec tunnel is built with the CoA as the outer MN address
   (this is simpler and more efficient but this puts a constraint on
    the IPsec implementation)
 - or the IPsec tunnel is built with the HoA and the mobility support
   adds a HAO or a RH2 (this works with a stupid IPsec implementation).
I argued for a SHOULD for the first solution and a MAY for the second
but not everybody agreed for a flexible solution...

   IPv6 stack.

=> we already need this for the BU/BA protection... and my final goal
is to get some integration between IPsec and Mobility (the API and
a "re-address" exchange in the Son-Of-Ike).

   If we do so, I guess we need not to define an IPsec API
   (listed as an open issues in section 10) to manage SA from the
   Mobile IPv6.
   
=> in fact the create/delete (aka rekeying) of the current API is
enough for today needs. When PFS is not used in quick mode, IKE
supports a fairly cheap rekeying/readdressing.

Regards

---

From: Jari Arkko <[email-masked]>
Date: Fri, 20 Sep 2002 15:03:39 +0300

> tunneling packets?  Just to save some bits?

About the inconsistency in the draft: Section 5.2 is right, Section 6
just didn't get updated when we decided to go for the tunnel mode only
encapsulation.

And then to the reasons of tunnel mode vs. tunnel mode plus HAO/RH2.
Here are some considerations:

- There's an efficiency difference of 24 bytes/packet in favor of
   the tunnel-mode only solution. This probably does not matter at
   all for just HOT/HOTI protection, but it may matter for protecting
   all of the payload packets. Yet, in the long term I would somehow
   see it more likely that the traffic is secured end-to-end rather
   than just to the HA.

   Conclusion: it may matter a bit (no pun intended), but not much.

- Direct tunnel mode encapsulation looks prettier.

   Conclusion: Hmm...

- Direct tunnel mode encapsulation needs an API towards IPsec.
   (It needs an implementation of an API, I don't think we need
   to specify it).

   The functionality that is needed is this: whenever a care-of
   address is updated in a binding entry, find all tunnel mode SAs where
   the destination selector is the corresponding home address
   and the source selector is the home agent, and update the tunnel
   gateway address. (Exercise for the reader: prove that this is
   sufficient even when dynamic keying is used.)

   The IPsec implementation that I wrote long time ago would have
   been able to offer such an API. Do all implementations have this?
   No. Is the API requirement unreasonable: I don't think so, it
   is likely that most implementations need an API anyway for a
   variety of reasons, including management.

   Conclusion: The direct tunnel mode encapsulation requires an
   API, but in some cases such an API may be available. But it
   is an additional burden.

- Recreate vs. update: Francis pointed out that it was
   possible to do a create/delete e.g. via PF_KEY instead
   of adding complex support for modifying SAs.

   (I might also be possible to have IKE renegotiate, but
   that I actually doubt because I don't know how the
   tunnel gateway would be set correctly automatically.
   Remember that IKE is run on the care-of addresses,
   so I'm not sure it survives movement if if the SAs
   created by it do.)

   Conclusion: there may be some easier ways to do the
   API than to require an update operation.

All in all, it's some bandwidth savings and slightly
prettier format vs. some additional implementation
requirements. Which side has heavier weight? When writing
the draft I was undecided for a long time, but I now think
that perhaps this is something where we should just require
the cleanest packet format. UNLESS this causes real problems
for many implementations.

Keiichi, others, please comment if this is possible in
your implementation!
Jari

---

From: Francis Dupont <[email-masked]>
Date: Fri, 20 Sep 2002 15:34:15 +0200

=> I have the answer to this point and (incredible :-) I know
some implementations which already implement it.
Ref: draft-dupont-ipsec-mipv6-01.txt recommendations L (common sense)
and R (ISAKMP SPI). The idea is to keep the phase one context
and to redo only a phase two.

Regards

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 20 Sep 2002 15:41:29 +0200 (CEST)

I haven't checked these comments against the posted draft
so some of them might have been fixed since the version I looked at
before the I-D was submitted.

A few comments:

          - When a packet is matched against IPsec security policy, an
          address appearing in a Home Address destination option MUST
          be considered as the source address of the packet.

          - Similarly, a home address within a Type 2 Routing header
          MUST be considered as the destination address of the packet.

Similar requirents to the above apply for the SA matching rules I assume.
I would make sense to make than explicit.

I misread the "Home address destination" as "destination option".
What is that part of the sentence trying to say? Just that the IPsec
tunnel is for the home address? (The tunnel endpoint is the CoA.)

          - If the home agent tunnels Home Test messages or payload
          packets to the mobile node with IPsec protection, the home
          agent MUST use the Type 2 Routing header and IPsec tunnel
          mode encapsulation.

The tunneled packets don't have a RH. They just have ESP plus an outr IP header
as stated in section 5.

         - SA2(OUT, 5002, home address, ESP, TRANSPORT):
           source = home agent & destination = home address & proto = MH
         - SA1(IN, 5001, home agent, ESP, TRANSPORT):
           source = home address & destination = home agent & proto = MH

The 5001 and 5002 SPIs might throw people off thinking they are fixed.
Using SPIa, SPIb, etc might make more sense.

In 7.3.1.

       mobile node SPD OUT:
         - IF source = home address & destination = home agent & proto = MH
           THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user1

Conceptually should the CREATE also specify that the created SA be bound
to the home address? Or where/how do you specify the binding between
"user1" and the specific home address?
Is that what the text at the end of 7.3.1 is saying?

In 7.3.2 you have
     Note that this specification has still the same problems as the
     manual protection for return routability signaling had.
However, the manual section (7.2.2) doesn't list any poribles.

Section 8 uses "forwarding" in some cases when the packet is originated.
Using "sending" in those cases makes more sense.
E.g. in 8.1 step 5.
Also, section 8.5 step 5 says "routed" whre "sent" makes more sence.

  Erik

---

From: Jari Arkko <[email-masked]>
Date: Sat, 21 Sep 2002 22:15:55 +0300

> I would make sense to make than explicit.

Yes.

> The tunneled packets don't have a RH. They just have ESP plus an outr IP header

These two requirements were wrong. As direct tunnel mode is used, then
the requirements should have said:

   - If IPsec is used to protect return routability signaling or
     payload packets tunneled via the home agent, IPsec tunnel mode
     encapsulation MUST be used.

> Using SPIa, SPIb, etc might make more sense.

Ok.

> Is that what the text at the end of 7.3.1 is saying?

The format is a bit misleading. What usually happens in an IPsec implementation
is that the SPD entries define the SA parameters (or at least their patterns),
even if IKE is used. What I wanted to present here was that the MN side will,
if it needs an SA to protect BUs, establish an IKE connection using phase 1
identity "user1" and try to negotiate the SA parameters for the home address.
On the home agent side we check the identity == "user1" before we allow
this specific home address in an SA.

Hmm... maybe I should have made it clearer that "home address" is a specific
home address home_address_1 rather than the general concept of a home
address.

I'll try to think something to make the format of these dynamic SPD
entries clearer. (Suggestions are welcome!)

> However, the manual section (7.2.2) doesn't list any poribles.

Oops, old text. No problems any more.

> Also, section 8.5 step 5 says "routed" whre "sent" makes more sence.
Yes.

Jari