Subject: [mobile-ip] observation on the mip/ipsec draft

From: Michael Thomas <[email-masked]>
Date: Mon, 28 Oct 2002 09:42:44 -0800 (PST)

Hi all,

I've been chatting with the authors of this draft
and it's time now to get a wider audience. For
those either unfamiliar with the draft or the
general problem, let me attempt to summarize it.
With communication between the home agent and
mobile node, we want to make certain that the
supposed mobile node making the request to change
bindings, etc, is in fact both authenticated and
authorized to make the change. Authentication is
relatively straightforward: we use IPsec which
gives us the ability to determine who is sending
the packet by virtue of sharing some keying
material. Thus, we have any easy way of keeping
people who don't share keying material with the HA
out. However, this does not prevent an
unscrupulous -- but authenticated -- mobile node
from hijacking another mobile node's sessions,
etc. This is an authorization problem.

As usual, authortization is more tricky. The
current draft, essentially, performs authorization
via an "exclusion" mechanism. That is, it only
permits traffic through to the MIP MH processing
module which is both authenticated and the IP
addresses in the header are correct for that 
particular MH. This is done using IPsec's packet
filtering mechanism and several discreet SA's
per mobile node. While this certainly works, as
should be evident reading the draft, the SPD
entries are, shall we say, complex and the cost
at the home agent for all of those SA's is of
some concern (I believe the current count is 
3 SA's, 4 if you wanted to have a general data
SA too).

What I realized and have been chatting with the
authors about is that there is another general
approach to the authorization problem we can
take. That is we can *defer* the authorization
check back into the MIP module itself. That is,
instead of blocking potentially unauthorized
MH traffic at the IPsec filtering layer, we can
permit all MH traffic through and allow the
MIP layer to determine which mobile nodes are 
allowed to change which bindings. This has the
advantage that the SPD entry is not complicated
and the number of different SA's needed per
mobile node is 1 -- including general mobile
node data if that's desirable.

Here's the method: 

1) A SDP entry for all mobile nodes is
   required. This entry at a minimum says to
   not pass any MH data without a valid SA. The
   SA can be tunnel or transport, ESP or AH,
   and MAY allow other data to pass (ie, it does
   not require IPsec packet filtering capability).

2) At SA establisment time (either in IKEd or
   manually), the MIP module is informed of the
   binding of SA/SPI to home address for the
   mobile node. This is purely an API issue, 
   most likely a setsockopt to MIP. This binding
   can be very specific as needed, say, in a
   service provider environment, or very loose
   essentially saying that auth == authz which
   may be an acceptible simplifying assumption
   for enterprise.

3) When a MH is received directed at the home
   agent, IPsec filters out unauthenticated traffic
   bu passes identifiable MH to the MIP module
   including the SPI that it came in on.

4) The MIP module then checks to see if the SPI
   present in the MH packet is authorized to change
   the mobility binding set up in step 2. If it is,
   it changes the binding, otherwise it rejects it.

Essentially what I've done here is used an
"application" layer tie in (in the MIP module)
to take advantage of IPsec credentials. This is
something that a lot of us think is a generally
useful thing that should be provided by IPsec
API's, but here since MIP is often in the kernel
it is a something of a "baby step" toward that
ultimate goal.

My proposal is to add this method to the current
draft as an acceptible alternative -- not replace it.
I believe that it is compatible with the existing
text in -18-bis-triple-prime ( :) ) and is not
reliant on the question of header processing order
that will be discussed in another message.

	  Mike

---

From: "James Kempf" <[email-masked]>
Date: Mon, 28 Oct 2002 12:39:38 -0800

Michael,

This sounds like a sensible and practical alternative. Since it depends on an
API mechanism, it would be useful to have an implementation to check if there
are any unanticipated consequences, but in principle, I support putting this
into the draft.

One question is why not replace the packet filtering design with this design
rather than putting the API design in as an alternative?

            jak

---

From: Michael Thomas <[email-masked]>
Date: Mon, 28 Oct 2002 14:51:48 -0800 (PST)

> are any unanticipated consequences, but in principle, I support putting this

   Great.
 
 > rather than putting the API design in as an alternative?

   It's up to the working group; I was just trying to
   create the least number of waves...

	  Mike

---

From: Jari Arkko <[email-masked]>
Date: Tue, 29 Oct 2002 00:49:11 +0200

Thanks Mike for writing this up.

>    it changes the binding, otherwise it rejects it.

I'm trying to understand what we'd need to do in order
to make this possible. Draft 18/19 now says the following:

    A mobile node must be prevented from
    using its security association to send a Binding Update on behalf
    of another mobile node using the same home agent.  Therefore, the
    security policy database entries MUST unequivocally identify a
    single security association for any given home address and home
    agent.  For the policy checks to work, it is necessary that the home
    address of the mobile node is visible in the Binding Updates and
    Acknowledgements.

So, in order to accommodate your method we'd need
to say something like

    ... using the same home agent. This MUST be achieved by checking
    that the given home address has been used with the right
    security association. Such a check can be provided in
    IPsec processing, by having the security policy database entries
    unequivocally identify a single security association for any
    given home address and home agent. The check may also be
    provided as a part of Mobile IPv6 processing, if information
    about the used security association is available in there. In
    any case, it is necessary that the home address of the mobile
    node is visible in the Binding Updates and Acknowledgements.

Note that I have chosen to _require_ the check above, even if you
are right that in theory there might be some organizations that
don't need it in their network. But I'm not sure I like making
it optional.

Is this all? Assuming of course that the number-of-sas issue
is kept orthogonal to authorization. By the way, I'm not sure
I fully understand in what situations you can reduce the number
of SAs. Can you do it even if you don't protect regular
payload traffic but still need protection for BUs, prefix discovery,
and HOTI? Does the Mobile IPv6 code need to be able also *control*
the use of SA, and not just observe what SAs got used?

Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 28 Oct 2002 15:43:21 -0800

the API is troubling me Mike. MIPv6 is one of the applications 
for IPsec. How does MIPv6 alone tell IPsec that it is interested 
in SPI/HoA information and that IPsec should provide the 
information through a new socket option? Is it a flag in the SA 
which tells the IPsec code that is should pass on some information 
to the app? Or is it a request/reply socket when a packet with 
Mobility Hdr reaches the MIPv6 module?

How does it change if IKE/manual keying/some other keying mechanism
is used?

Vijay

---

From: Michael Thomas <[email-masked]>
Date: Mon, 28 Oct 2002 15:57:51 -0800 (PST)

> How does it change if IKE/manual keying/some other keying mechanism

   Let me see if I can state this concisely. When
   a SA is created which is authorized to change
   mobility bindings, the MIP code -- probably in
   the kernel -- needs to be informed of which SPI
   those MH messages should be arriving on. This
   is most likely a setsockopt or ioctl or
   something like that. In the MIP code itself,
   it just needs access to the SPI which was
   associated with the actual packet so that it
   can do a lookup in its authorization database
   (eg, the one that was built with those
   setsockopts). If the HoA/SPI match the incoming
   packet's version of same, then it admits the
   MH as legit, otherwise it drops it.

   Clearer?

		Mike

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 28 Oct 2002 16:11:41 -0800

Mike,

Michael Thomas wrote:
>    mobility bindings, 

how does IPsec code decide the following? 

"hey, I am creating an SA for an app which does its own 
authorization. now I need to send the SPI/HoA information 
to this app through this socket"

I was thinking about the API and had this question.

>    the MIP code -- probably in

this I understood a week ago.

Vijay

---

From: Michael Thomas <[email-masked]>
Date: Mon, 28 Oct 2002 16:20:36 -0800 (PST)

> I was thinking about the API and had this question.

   I assume you mean the IKE or manual keying
   code rather than IPsec the kernel entity, right?

   It's really a property of the credentials. That
   is a given credential gives a particular set of
   authorizations. In reality I suspect that the policy
   here is most likely to be something like:

   if (gotPastMainMode ())
       setsockopt (mipfd, MIPBINDAUTHZ, &HoA, &SPI)

   if you take my meaning :)

	  Mike

---

From: Jari Arkko <[email-masked]>
Date: Tue, 29 Oct 2002 02:17:35 +0200

>    MH as legit, otherwise it drops it.

In some stack designs that I have seen, I would just
attach an administrative field to the skbuff or similar
data structure that tells the information to the "applications"
that need this information. This would work only inside
the kernel though, but that's the case for most MIPv6
implementations I would think.

In the dynamic keying case the situation is more complicated.
Basically, someone would either have to keep a mapping of
phase 1 identities to SAs so that MIPv6 could access this
information, or the phase 1 identity information should available
by sockopt per packet. Or there should be an ioctl to ask
for the phase 1 identity information given an SPI. Then the
MIPv6 code would have to have a configuration file that
tells which home addresses correspond to which phase 1 identities.

Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 28 Oct 2002 16:34:41 -0800

>    I assume you mean the IKE or manual keying

yes. I used the term IPsec to include the IKE daemon and policy 
engine. I should have been more specific. sorry.

>    authorizations. 

these credentials have to say that the particular app is capable
of authorizations, and pass the SPI - HoA information to it, right?

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 28 Oct 2002 16:47:12 -0800

hi Mike,

lets consider the HA receiving a tunneled HoTi.

from section 14.5 of
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-18.txt

> When receiving
>    tunneled traffic the home agent verifies the outer IP address
>    corresponds to the current location of the mobile node.  This
>    prevents attacks where the attacker is controlled by ingress
>    filtering.  It also prevents attacks when the attacker does not know
>    the current care-of address of the mobile node.  Attackers who know
>    the care-of address and are not controlled by ingress filtering could
>    still send traffic through the home agent.  This includes attackers
>    on the same local link as the mobile node is currently on.  But such
>    attackers could also send spoofed packets without using a tunnel.

in the solution you have described, by the time the MIPv6
module gets the packet, the decapsulation is done. the outer
header is lost. how does the MIPv6 module perform the check?

in draft-ietf-mobileip-mipv6-ha-ipsec-01.txt, it was easy 
because IPsec performs this check.

regards
Vijay

ps: we had a similar discussion last week, but I was not satisfied 
with the responses.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 29 Oct 2002 11:08:15 -0800 (PST)

> because IPsec performs this check.

Vijay, 

Actually after re-reading this, it's not clear
that it would check it. I believe this is wrapped
up in the discussion about whether the HoA or CoA
is what is used for IPsec filtering (ie, do you
replace the CoA for the HoA before IPsec
processing or not). 

However, getting back to your question, another
way to provide this kind of ingress filtering is
to perform an RPF check once it decapsulates the
tunneled packet. I think that the spec should be
agnostic to the *means* of providing that check so
long as it's available.

	     Mike

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 29 Oct 2002 11:24:26 -0800

> replace the CoA for the HoA before IPsec

first of all, the question was about a tunneled HoTi. this
is how it looks

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

the CoA is checked as part of the interface-id match. the 
MN - HA tunnel is the interface we are talking about here.
and the SA is keyed on the tunnel interface.

the HoA is checked as part of the src and dst selector match
on the inner header.

> agnostic to the *means* of providing that check so

as part of the SPD filtering I get this automatically.
why do I need another mechanism? and I would like it
for the HoTi to go to the forwarding path immediately.
not go to the MIPv6 modules to perform an RPF check.

and it becomes significant when it comes to reverse
tunneled IPsec protected payload traffic, because the
check needs to done for every packet.

Vijay