Subject: [mobile-ip] HA-IPSec draft nits

From: Jari Arkko <[email-masked]>
Date: Mon, 13 Jan 2003 18:22:22 +0200

I have taken a look at certain other specifications
dealing with the use of IPsec for some protocol. For instance,
draft-ietf-ips-security-18.txt contains an extensive discussion on how
to apply IPsec for the block storage protocols such as iSCSI.

In reading these other documents it has become apparent to me that
we need some additional details in our specification. These details
include the following:

1. (Editorial) A short introduction to Mobile IPv6 is necessary so
    that the document stands better on its own. It is also necessary to
    briefly discuss the security issues leading to the requirements
    for protecting the control traffic.

    The following text has now been included in the latest draft
    version:

      "In Mobile IPv6 [6], a mobile node is always expected to be
       addressable at its home address, whether it is currently attached to
       its home link or is away from home.  The "home address" is an IP
       address assigned to the mobile node within its home subnet prefix on
       its home link.  While a mobile node is at home, packets addressed to
       its home address are routed to the mobile node's home link.

       While a mobile node is attached to some foreign link away from home,
       it is also addressable at a care-of addresses.  A care-of address is
       an IP address associated with a mobile node that has the subnet
       prefix of a particular foreign link.  The association between a
       mobile node's home address and care-of address is known as a
       "binding" for the mobile node.  While away from home, a mobile node
       registers its primary care-of address with a router on its home link,
       requesting this router to function as the "home agent" for the mobile
       node.  The mobile node performs this binding registration by sending
       a "Binding Update" message to the home agent.  The home agent replies
       to the mobile node by returning a "Binding Acknowledgement" message.

       Any other nodes communicating with a mobile node are referred to as
       "correspondent nodes".  Mobile nodes can provide information about
       their current location to correspondent nodes, again using Binding
       Updates and Acknowledgements.  Additionally, return routability test
       is performed between the mobile node, home agent, and the
       correspondent node in order to authorize the establishment of the
       binding.  Packets between the mobile node and the correspondent node
       are either tunneled via the home agent, or sent directly if a binding
       exists in the correspondent node for the current location of the
       mobile node.

       Mobile IPv6 also provides support for the reconfiguration of the home
       network.  Here the home subnet prefixes may change over time.  Mobile
       nodes can learn new information about home subnet prefixes through
       the "prefix discovery" mechanism.

       This draft discusses security mechanisms for the control traffic
       between the mobile node and the home agent. If this traffic is
       not protected, mobile nodes and correspondent nodes are
       vulnerable to Man-in-the-Middle, Hijacking, Confidentiality,
       Impersonation, and Denial-of-Service attacks. Any third parties
       are also vulnerable to Denial-of-Service attacks. These threats
       are discussed in more detail in Section 15.1 of the Mobile IPv6
       base specification [6].

       In order to avoid these attacks, the base specification uses IPsec
       [1] to protect control traffic between the home agent and the mobile
       node.  This control traffic consists of various messages carried by
       ..."

2. It would be useful to talk about when IKE and IPsec SAs
    are established, and what happens when they are rekeyed.

    For this I propose that we add a new processing order
    subsections:

    5.x. Establishing New Security Associations

         Step 1. The mobile node wishes to send a Binding Update
	to the home agent.

           IPv6 header (source = home address,
                        destination = home agent)
           Mobility header
              Binding Update

	Step 2. There is no existing security association to protect
	the Binding Update, so IKE is initiated. The IKE packets
	are as follows:

           IPv6 header (source = care-of address,
                        destination = home agent)
              UDP
              IKE

	Step 3. IKE phase 1 completes, and phase 2 is initiated to
	request SAs for protecting traffic between the mobile node's
	home address and the home agent. This involves sending and
	receiving additional IKE packets. The below example shows
	a received packet:

           IPv6 header (source = home agent,
                        destination = care-of address)
              UDP
              IKE

         Step 4. The remaining steps are as shown in Section 5.1.

    5.y.	Rekeying Security Associations

         Step 1. The mobile node and the home agent have existing
	security associations. Either side may decide at any time that
	the security associations need to be rekeyed, for instance,
	because the specified lifetime is approaching.

	Step 2. Messages sent during rekey may be protected by the
	existing security associations.

	Step 3. When the key refresh is finished, new security
	associations are established. In practice there is a time
	interval during which an old, about-to-expire SA and newly
	established SA will both be valid. The IPsec implementation
	will choose which security association to use based on local
	policy

	Step 4. A notification of the deletion of the old security
	associations is received. After this, only the new security
	assocations are used."

3. It would be useful to clarify the relationship between IKE
    SA establishment and bindings. Or more to the point, it would
    be useful to explicitly say that these are independent.

    The proposal is to add the following text at the end of "5.y"
    above:

        "Note that there is no requirement that the existence of the
         IPSec and IKE security associations is tied to the existence
         of bindings. It is not necessary to delete a security
         association if a binding is removed, as a new binding may soon
         be established after this.

	Since cryptographic acceleration hardware may only be able to
	handle a limited number of active security associations,
	security associations may be deleted via IKE as a means of
	keeping the number of active cryptographic contexts to a
	minimum. Such deletions should not be interpreted as a sign of
	losing a contact to the peer or as a reason to remove a
	binding. Rather, if additional traffic needs to be sent, it
	is preferable to bring up another security association to
	protect it."

4. IKE behaves badly when large certificates or certificate chains
    are involved. It makes sense to describe this problem and
    discuss why it isn't as much relevant to Mobile IPv6 as it
    is perhaps in other cases.

      "When certificate authentication is used, IKE fragmentation can be
       encountered. This can occur when certificate chains are used, or
       even with single certificates if they are large. Many firewalls
       do not handle fragments properly, and may drop them. Routers in
       the path may also discard fragments after the initial one, since
       they typically will not contain full IP headers that can be
       compared against an access list. Where fragmentation occurs, the
       endpoints will not always be able to establish a security
       association. Fortunately, typical Mobile IPv6 deployment uses
       short certificate chains, as the mobile node is communicating
       directly with its home network. Nevertheless, where the problem
       appears, the preferred solution is to replace the firewalls or
       routers with equipment that can properly support fragments. If
       this cannot be done, it may help to obtain the certificates
       through other means."