Subject: [mobile-ip] Mipv6 issue #192: Authz in SPD or in MIPv6?

From: Jari Arkko <[email-masked]>
Date: Fri, 27 Dec 2002 14:47:43 +0200

This is an attempt to see what it would mean to do all authorization
tasks in Mobile IPv6 code, as suggested by Michael Thomas. I like this
approach for several reasons but we haven't had a detailed description
of how it would work. For this reason I set out to make an example
configuration for this new style. I have modified the SPD and SAD
entries from sections 7.2 and 7.3 of the MN-HA IPsec draft to the new
style below.

There are NOTEs within the text to explain differences to the current
style.

Overall, the main findings are as follows:

   o  When manual keying is used, we can reduce the number of SAs
      from Nx6 to Nx4 (or even Nx2 if we are willing accept some
      additional headers). The number of SAD entries is reduced
      similarly. The number of SPD entries is constant and does
      not depend on the number of home addresses. These are
      positive findings.

   o  When IKE is being used, the new style simplifies the
      configuration considerably. This too is positive.

   o  However, at the same time we are forced into the following changes:

      - All MH traffic to and from the HA must be protected with IPsec,
        making it hard, for instance, for my home server to be simultaenously
        both a home agent and a public web server. (See 7.3.1 below.)

        Question: Could we base our SPD rules on home network prefixes?

      - If we want to avoid mobile node -specific policy entries (which was
        one of the goals), we have to create tunnel mode SAs bound to the
        care-of addresses. This implies a new IKE run is needed on every
        movement. (See 7.3.2 below.)

        Question: Does it help if we keep the modify-the-tunnel-gw
        API as well?

      - Address spoofing of HOTIs can't be checked (but this isn't
        considered very dangerous given that HOTs are routed correctly).

My conclusion from the above is that while there are extremely big
advantages, there still seems to be also some significant open
questions. Perhaps Mike or others have suggestions on how to overcome
these issues and to answer the questions? Otherwise, I think we should
go with the current (tested) approach and do some more long-term work
as an add-on.

OVERVIEW OF OPERATIONS
======================

In this new style, we leave IPsec to do the authentication work, and
deal with the authorization issues as much as we can in Mobile IPv6
module. That is, IPsec ensures that for the "significant traffic",
only packets coming from authenticated peers get through. In this
context, "authentication" means, for instance, any node belonging to
the corporate intranet.

Security issues in Mobile IPv6 go beyond authentication, however. We
need to ensure that mobile node A does not send a Binding Update for
mobile node B, for instance, even if both are authenticated.  The
purpose of the authorization step is to make sure this does not
happen. The authorization step is performed in the Mobile IPv6 module
in this new style.

The overall approach at the IPsec layer is to require authentication
but leave as much of address and protocol information freely expressed
as possible. Then we require an API to exist between the IPsec layer
and the Mobile IPv6 module to communicate the "identity" used in the
successful authentication to Mobile IPv6. Mobile IPv6 will then
compare this identity and the claimed home address to the information
it has in configuration table about authorizated nodes and their
addresses. Alternatively, such configuration table may also be
accessed through an AAA lookup.

The details of the required API are not relevant at this stage.  What
is needed is a way to associate a given packet to some "credentials",
either Phase 1 identities from IKE or some manual SA identifier. This
can happen per-packet or through some form of properties assigned to a
socket or security associations.

Note that we may not always be successful in avoiding addresses and
protocol information in the IPsec policy entries and SAs. It is still
necessary for us to specify when IPsec is to be applied and when not.
This may have to be done in part using addresses from the packets.

Note also that the authorization checks can only be performed when
some message actually comes to the Mobile IPv6 module. This is the
case for MH packets terminated to the home agent, for instance. But it
is not the case for traffic tunneled through the home agent.

CONFIGURATION EXAMPLES
======================

7.2.  Manual Configuration

7.2.1.  Binding Updates and Acknowledgements

NOTE: There difference in the new style is that we can make a single
       pair of SPD entries that covers even multiple home addresses
       (more useful in the HA side). We still need home address
       -specific SAs, but the SAs can be reused for multiple
       purposes. In this example configuration we use two transport
       mode SAs for BU and prefix protection, and two tunnel mode SAs
       for RR protection. (These could have been merged as well, with
       the cost of some additional headers for BUs.)

        mobile node SPD OUT:
          - IF source = any & destination = home_agent_1 & proto = MH
            THEN USE any SA

        mobile node SPD IN:
          - IF source = home_agent_1 & destination = any &
               proto = MH
            THEN USE any SA

        mobile node SAD:
          - SA1(OUT, spi_a, home_agent_1, ESP, TRANSPORT):
            source = home_address_1 & destination = home_agent_1
          - SA2(IN, spi_b, home_address_1, ESP, TRANSPORT):
            source = home_agent_1 & destination = home_address_1

NOTE: In the home agent the same thing applies. These SAD entries are
       still mobile node -specific, which is of course to be expected
       for the manual keying case. We only need two SPD entries, however.

        home agent SPD OUT:
          - IF source = home_agent_1 & destination = any &
               proto = MH
            THEN USE any SA

        home agent SPD IN:
          - IF source = any & destination = home_agent_1 &
               proto = MH
            THEN USE any SA

        home agent SAD:
          - SA2(OUT, spi_b, home_address_1, ESP, TRANSPORT):
            source = home_agent_1 & destination = home_address_1
          - SA1(IN, spi_a, home_agent_1, ESP, TRANSPORT):
            source = any & destination = home_agent_1

7.2.2.  Return Routability Signaling

NOTE: Here too we can keep just two SPD entries, but need
       SAD entry pairs for each different home address.
       Remember that we might have also reused the BU SAs
       here.

        mobile node SPD OUT:
          - IF interface = tunnel to home_agent_1 & source = any &
               destination = any & proto = MH
            THEN USE

        mobile node SPD IN:
          - IF interface = tunnel from home_agent_1 & source = any &
               destination = any & proto = MH
            THEN USE SA4

        mobile node SAD:
          - SA3(OUT, spi_c, home_agent_1, ESP, TUNNEL):
            source = any & destination = home_agent_1
          - SA4(IN, spi_d, home_address_1, ESP, TUNNEL):
            source = any & destination = home_address_1

NOTE: As above.

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

        home agent SPD IN:
          - IF interface = any tunnel from any mobile node & source = any &
               destination = any & proto = MH
            THEN USE SA3

        home agent SAD:
          - SA4(OUT, spi_d, home_address_1, ESP, TUNNEL):
            source = any & destination = home_address_1 & proto = MH
          - SA3(IN, spi_c, home_agent_1, ESP, TUNNEL):
            source = any & destination = home_agent_1 & proto = MH

7.2.3.  Prefix Discovery

NOTE: Here we will see some benefits. We can reuse the SAs for
       BU protection here as well.

        mobile node SPD OUT:
          - IF source = any & destination = home_agent_1 &
               proto = ICMPv6
            THEN USE any SA

        mobile node SPD IN:
          - IF source = home_agent_1 & destination = home_address_1 &
               proto = ICMPv6
            THEN USE any SA

NOTE: As above.

        home agent SPD OUT:
          - IF source = home_agent_1 & destination = home_address_1 &
               proto = ICMPv6
            THEN USE any SA

        home agent SPD IN:
          - IF source = home_address_1 & destination = home_agent_1 &
               proto = ICMPv6
            THEN USE any SA

7.2.4.  Payload Packets

NOTE: I didn't do this exercise and decided that we could even live without
       this protection if necessary.

7.3.  Dynamic Keying

7.3.1.  Binding Updates and Acknowledgements

NOTE: Mobile node SPD ignores home address, and now applies even to care-of
       addresses. This is fine from the point of view of the mobile node.

       IKE is run on care-of addresses, but the created SAs are allowed to
       use *any* home address. This avoids the need to rerun IKE on every
       movement. In any case the Mobile IPv6 code will check the used
       credentials vs. the specified home address.

        mobile node SPD OUT:
          - IF source = any & destination = home_agent_1 & proto = MH
            THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user_1

        mobile node SPD IN:
          - IF source = home_agent_1 & destination = any & proto = MH
            THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user_1

NOTE: Home agent SPD ignores home address i.e. the peer's address
       completely. The general rule becomes then SO general that it
       precludes cleartext MH. For instance, the same node can't act as
       a home agent for you and as a web-server with route optimization
       for someone else.

        home agent SPD OUT:
          - IF source = home_agent_1 & destination = any & proto = MH
            THEN CREATE ESP TRANSPORT SA

        home agent SPD IN:
          - IF source = any & destination = home_agent_1 & proto = MH
            THEN CREATE ESP TRANSPORT SA

NOTE: We create an additional configuration table for the home agent
       to list the relationship of IKE Phase 1 identities to home
       addresses. Mobile IPv6 module will check this using an API for
       all MH packets.

        home agent MIP ID TABLE:
          - user_1 has home_address_1

7.3.2.  Return Routability Signaling

NOTE: Mobile node SPD roughly same as before, but home address not
       tested, and neither is the specific tunnel. Applies even for
       multiple home addresses.

        mobile node SPD OUT:
          - IF interface = any tunnel to home_agent_1 &
               source = any & destination = any & proto = MH
            THEN CREATE ESP TUNNEL SA: gateway = home_agent_1 &
                                       local phase 1 identity = user_1

        mobile node SPD IN:
          - IF interface = any tunnel from home_agent_1 &
               source = any & destination = any & proto = MH
            THEN CREATE ESP TUNNEL SA: gateway = home_agent_1 &
                                       local phase 1 identity = user_1

NOTE: The home agent policy entries have been radically simplified.
       Remember that earlier entries already forced us to require IPsec
       for every MH message, making the use of the home agent as a
       general correspondent node hard. We use this fact to write the
       entries in a very simple way, all MH packets from anywhere to
       anywhere must be tunneled with IPsec (the BU entries from 7.3.1
       take precendence however).

NOTE: Since we run IKE on top of care-of addresses and don't want to
       have mobile node specific policy entries, the tunnels will be
       established to care-of address, requiring them to be redone on
       every movement.

NOTE: The home agent will not be performing any home address spoofing
       checks for the HOTI messages. This is seen as unnecessary,
       however, given that HOTs will always be routed to the right
       mobile node.

        home agent SPD OUT:
          - IF source = any & destination = any & proto = MH
            THEN CREATE ESP TUNNEL SA: gateway = care-of address
	   (there is no IKE attribute to set the gateway
	   differently from IKE transport addresses)

        home agent SPD IN:
          - IF source = any & destination = any & proto = MH
            THEN CREATE ESP TUNNEL SA: gateway = care-of address

7.3.3.  Prefix Discovery

NOTE: The mobile node SPD entries now ignore the home address. Note
       that since the rules still keep the home agent's global unicast
       address, these rules will not match ND traffic which uses
       link-local addresses.  This is good as chicken-and-egg problems
       in securing ND with IKE can be avoided.

        mobile node SPD OUT:
          - IF source = any & destination = home_agent_1 & proto = ICMPv6
            THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user_1

        mobile node SPD IN:
          - IF source = home_agent_1 & destination = any & proto = ICMPv6
            THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user_1

NOTE: As above.

        home agent SPD OUT:
          - IF source = home_agent_1 & destination = any & proto = ICMPv6
            THEN CREATE ESP TRANSPORT SA

        home agent SPD IN:
          - IF source = any & destination = home_agent_1 & proto = ICMPv6
            THEN CREATE ESP TRANSPORT SA

7.3.4.  Payload Packets

NOTE: I didn't do this exercise and decided that we could even live without
       this protection if necessary.

---

From: Jari Arkko <[email-masked]>
Date: Tue, 31 Dec 2002 01:44:43 +0200

Answering my own e-mail...

>        making it hard, for instance, for my home server to be 
>        simultaenously both a home agent and
>        a public web server. (See 7.3.1 below.)
> 

This seems possible. BUs, RR, and prefix discovery rules will all have
conditions on the mobile node's address being within the home prefix.

See below for the rules.

>        Question: Does it help if we keep the modify-the-tunnel-gw

Both the -02 version of the draft as well as my suggested formulation
of Mike's approach has the same problem. In IKE, the tunnel gateway
is set to the addresses IKE uses for communication. The policy entries
can't change this, but our APIs require setting the gateway based on
movements. It appears that this has to be done also when the SAs are
created.

Jari
----

        mobile node SPD OUT:

        mobile node SPD IN:

        mobile node SAD:

        home agent SPD OUT:
          - IF source = home_agent_1 & destination = home_prefix_1/64 &
               proto = MH
            THEN USE any SA

        home agent SPD IN:
          - IF source = home_prefix_1/64 & destination = home_agent_1 &
               proto = MH
            THEN USE any SA

        home agent SAD:

        mobile node SPD OUT:

        mobile node SPD IN:

        mobile node SAD:

NOTE: As above.

        home agent SPD OUT:
          - IF source = any & destination = home_prefix_1/64 & proto = MH
            THEN USE SA4

        home agent SPD IN:
          - IF source = home_prefix_1/64 & destination = any & proto = MH
            THEN USE SA3

        home agent SAD:

7.2.3.  Prefix Discovery

        mobile node SPD OUT:

        mobile node SPD IN:

NOTE: As above.

        home agent SPD OUT:
          - IF source = home_agent_1 & destination = home_prefix_1/64 &
               proto = ICMPv6
            THEN USE any SA

        home agent SPD IN:
          - IF source = home_prefix_1/64 & destination = home_agent_1 &
               proto = ICMPv6
            THEN USE any SA

7.2.4.  Payload Packets

7.3.  Dynamic Keying

        mobile node SPD OUT:

        mobile node SPD IN:

NOTE: Home agent SPD ignores home address i.e. the peer's address
       except for the prefix. The rule becomes then so general that it
       precludes cleartext MH within this network even for other nodes.
       Luckily, all nodes that could possibly have use for MH in this
       network are mobile nodes who should already have the necessary
       means to establish SAs with the home agent(s).

        home agent SPD OUT:
          - IF source = home_agent_1 & destination = home_prefix_1/64 & proto = MH
            THEN CREATE ESP TRANSPORT SA

        home agent SPD IN:
          - IF source = home_prefix_1/64 & destination = home_agent_1 & proto = MH
            THEN CREATE ESP TRANSPORT SA

        home agent MIP ID TABLE:

        mobile node SPD OUT:
          - IF interface = any tunnel to home_agent_1 &
               source = any & destination = any & proto = MH
            THEN CREATE ESP TUNNEL SA: local phase 1 identity = user_1

        mobile node SPD IN:
          - IF interface = any tunnel from home_agent_1 &
               source = any & destination = any & proto = MH
            THEN CREATE ESP TUNNEL SA: local phase 1 identity = user_1

NOTE: The home agent policy entries have been simplified.  All MH
       packets to anywhere with a home network source or destination
       must be tunneled with IPsec (the BU entries from 7.3.1 take
       precendence however).

        home agent SPD OUT:
          - IF source = any & destination = home_prefix_1/64 & proto = MH
            THEN CREATE ESP TUNNEL SA
	   (gateway set by APIs to current care-of address)

        home agent SPD IN:
          - IF source = home_prefix_1/64 & destination = any & proto = MH
            THEN CREATE ESP TUNNEL SA
	   (gateway set by APIs to current care-of address)

7.3.3.  Prefix Discovery

        mobile node SPD OUT:

        mobile node SPD IN:

NOTE: As above.

        home agent SPD OUT:

        home agent SPD IN:

7.3.4.  Payload Packets