Subject: [mobile-ip] Issue 306 summary

From: Jari Arkko <[email-masked]>
Date: Fri, 23 May 2003 16:15:51 +0300

Here's my brief summary of the issues raised by Francis and Santeri
regarding ha-ipsec.

The issues are:

1. Terminology and other corrections needed in ha-ipsec
2. Suitability of MIPv6 and HA-IPSEC for BITS implementations
3. Feasibility of the SPD definition for the MN-HA tunnel interface
4. IKE is needed

I will talk about each in turn:

1. Terminology and other corrections needed in ha-ipsec

    This seems largely handled now. Thanks, Francis!

2. Suitability of MIPv6 and HA-IPSEC for BITS implementations

    We have developed a rough outline for a possible implementation
    strategy in a BITS implementation. Generally the following is
    needed:
      - per packet "normalization" before IPsec treatment, to get
        rid of HAOs and RH2s.
      - specific configuration/recognition of MIPv6 tunnels to HA
      - update of SA endpoints upon movement, via a config API

    These tasks appear doable IMHO, though may not be possible for all BITS
    implementations. For instance, the BITS could be controlled only
    through a GUI.

    Additionally, the normalization process may not match what
    current hardware does. However, it isn't clear if any IPv6-capable
    hardware accelators actually exist, so perhaps the question is
    more about whether future accelerators can take MIPv6 in account
    with reasonable effort.

    As discussed under item 4, there are alternative proposals to how
    ha-ipsec could be rearranged to avoid the normalization
    process. However, IMHO these proposals appear to have other requirements
    to the BITS implementations.

3. Feasibility of the SPD definition for the MN-HA tunnel interface

    According to RFC 2401 and 2460 definitions, one can consider
    even a MIPv6 (IPv6 encapsulation) tunnel as an interface for which
    SPD entries can be defined.

    The current approach makes use of this fact, but Francis believes
    that this is a too hard requirement for implementations, we'd only
    see special purpose home agents and cause too long delay in
    getting general support from most platforms.

    The problem in this case is that it is hard to differentiate
    other MH packets sent by the MN or the HA from those that
    need to be protected. Basically, the only difference is
    that one set of packets is going to the MN-HA tunnel,
    and the other set is not.

    This leaves the following alternatives:
    - accept the requirement for the SPD entries
    - a yet to be determined solution that avoids this
    - revert to an on/off IPsec encapsulation for all tunneled packets

4. IKE is needed

    Francis and Santeri argue that in practise IKE is always
    required for a real deployment. There are number of
    questions related to this:

    - accurate understanding of the implications of IKE
      and manual keying usage
    - the current keyword for IKE (only a MAY)
    - the possibility of an IKE-only approach
      which would make some of the issues easier for
      BITS implementations to handle

    Related to the first two questions, we have recently
    updated the base draft security consideration section
    to give an accurate description of what the implications
    are. I think this is key in what have to do, I see the
    keywords as of lesser importance. Vendors will provide
    IKE if its the only practical solution as you say.

    See
    http://www.piuha.net/~jarkko/publications/mipv6/drafts/mobilev6.html#seccons:homeupd

    I haven't heard anything which would indicate that
    the current solution does not work with IKE.

    We have, however, an agreement that Santeri's
    care-of address based approach would work easier
    in terms of IPsec. This would free the BITS implementations
    from dealing with HAOs and RH2s. However, a problem remains
    that in order to provide a home address - mobile node
    check for home agent binding updates, the care-of address
    approach is not very useful. This check can be provided
    by other means, such as through an API. But it isn't clear
    that the required existence for such an API would be
    less of a problem than the currently required things.
    In particular, such an API would probably be quite hard
    to arrange for a BITS implementation.

Jari's Summary

The first issue has been handled, but for the rest I do not see a
clear alternative to the current specification. What ever we do, there
is going to be some modifications required for BITS (probably starting
from the need to add IPv6 support). I'd very much like to avoid the
tunnel interface SPD entries that Francis complained, but are other
folks going to accept on/off tunnel encryption without differentiation
to the RR packets? I'm not sure I see other alternatives. Finally, as
far as I understand we have not heard a specific complaint that in the
current approach IKE would not work. I agree that in most cases IKE
would be used for real-world cases. But I'm not sure I'm willing to
avoid make manually keyed SAs impossible. (I'm also getting more
convinced that the use of IPsec for securing home agent communications
has lead to a rather complex feature, and as I said on the mipcharter
list an apps layer solution would have made it easy to do dynamic home
addresses. Perhaps we will work on something like that in the future.)

---

From: Jari Arkko <[email-masked]>
Date: Mon, 26 May 2003 16:41:25 +0300

Hi,

We did continue the discussion about issue 306 (interfaces & policy
checks) and 307 (bumb-in-the-stack implementations). After the discussion,
the below proposals were made, and the chairs decided to close
the issues as per the proposals. Not unanimous among the
folks who discussed this, but most of us agreed... and this
allowed us to post the drafts.

-----307-----

After a discussion in this matter I'd like to
propose the following as the resolution for the BITS issue:

Section 7 in the ha-ipsec draft is expanded to talk about the
specific problems associated with BITS implementations. However,
the current model in use in Mobile IPv6 and MN-HA security is
kept as is.

Here's my reasoning for this:

* The new information that we developed during the
   discussion should be reflected in the implementation
   considerations.

* The IKE-only approach, while interesting and a very clean
   approach, alleviates some problems with BITS implementations
   (HAO/RH2 processing), but creates also new requirements. In
   particular, in order to provide home address authorization,
   we'd need a per-packet API between the BITS and the rest of
   the stack. This appears to be a tough requirement. Alternatively,
   new MIPv6-specific policy checks would have to be added.
   Either way, we would move from a situation where MIPv6 support
   is possible (at least on some cases) with an unmodified IPsec
   implementation, to a situation where some modifications would
   be needed under all cases.

* Process: we are beyond the wg and ietf last calls. Hence
   we should only consider specific, previously unknown problems.
   We should not debate again trade-offs that we have known
   to exist. In this case, the problems with the BITS implementations
   have been known to the WG.

Here's the suggested new text:

    Mobile IPv6 sets high requirements for a so-called Bump-In-The-Stack
    (BITS) implementation model of IPsec.  As Mobile IPv6 specific
    modifications of the packets are required before or after IPsec
    processing, the BITS implementation has to perform also some tasks
    related to mobility.  This may increase the complexity of the
    implementation, even if it already performs some tasks of the IP
    layer (such as fragmentation).

    Specifically, Bump-in-the-Stack implementations may have to deal with
    the following issues:

    o  Processing the Home Address destination option and Routing header
       type 2 to a form suitable for IPsec processing to take place.
       This is needed, among other things, for the security association
       and policy lookups.  While relatively straightforward, the
       required processing may have a hardware effect in BITS
       implementations, if they use hardware support beyond the
       cryptographic operations.

    o  Detecting packets sent between the mobile node and its home agent
       using IPv6 encapsulation.

    o  Offering the necessary APIs for updating the IPsec and IKE
       security association endpoints.

-------306---------

After the discussion I'd like to propose a
resolution to this issue.

It seems that after the weekend's discussion we seem
to agree upon the following:

* Formats on the wire are right.

* There is an inconsistency between 11.3.2 and
   the tunnel interface policy lookup.

Our disagreement is mainly about the processing.
As has been noted, we have already used (on purpose!)
enough weasel-wording to make it clear that we do not
recommend a specific implementation. But the
inconsistency needs to be solved, and it would also
be useful to have a few words about other implementation
strategies.

The SHOULD that Francis doesn't like can be changed
to talk about the desired outcome, and only point out
with weaker words the use of the SPD rules. In addition,
the base and ha-ipsec used MUST/SHOULD inconsistently.
I think we can use MUST with the new formulation. In both
documents, change

    "The security policy database entries MUST(SHOULD) be
     defined as if they were specifically for the IPv6
     encapsulated tunnel interface between the mobile
     node and the home agent."
=>
    "When IPsec is used to protect return routability
     signaling or payload packets, this protection MUST
     only be applied to the return routability packets
     entering the IPv6 encapsulated tunnel interface
     between the mobile node and the home agent. This
     can be achieved, for instance, by defining the
     security policy database entries specifically for
     the tunnel interface."

The 11.3.2 inconsistency can be solved by adding a statement
in 11.3.2 about the need to determine outgoing
interface (including tunnel) at an early step. Note: this
is only partially about mobility processing, the real
mobility actions come later as in the current version.
But RFC 2401 requires SAD and SPD to be interface
specific, so I think this can be pointed out. Also
remember that this text begins with a disclaimer that
we do not wish to require a specific implementation,
as long as the output is the same.

New item list in 11.3.2:

    o  The packet is created by higher layer protocols and applications
       (e.g., by TCP) as if the mobile node were at home and Mobile IPv6
       were not being used.

    o  Determine the outgoing interface for the packet.  (Note that the
       selection between reverse tunneling and route optimization may
       imply different interfaces, particularly if tunnels are considered
       interfaces as well.) <--- NEW

    o  As part of outbound packet processing in IP, the packet is
       compared against the IPsec security policy database to determine
       what processing is required for the packet [4].

    o  If IPsec processing is required, the packet is either mapped to an
       existing Security Association (or SA bundle), or a new SA (or SA
       bundle) is created for the packet, according to the procedures
       defined for IPsec.

    o  Since the mobile node is away from home, the mobile is either
       using reverse tunneling or route optimization to reach the
       correspondent node.

    ...