Subject: [Mip6] [issue86] Review by Tero Kivinen <[email-masked]>

From: admin <[email-masked]>
Date: Wed, 15 Nov 2006 20:31:54 +0000

New submission from admin <[email-masked]>:

>   Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture
>                    draft-ietf-mip6-ikev2-ipsec-07.txt
...
> 1.  Introduction
> 
>    RFC 3776 describes how IPsec, as described in RFC 2401 [11], is used
>    with Mobile IPv6 [2] to protect the signaling messages.  It also
>    illustrates examples of Security Policy Database and Security
>    Association Database entries that can be used to protect Mobile IPv6
>    signaling messages.
> 
>    The IPsec architecture has been revised in RFC 4301 [5].  Among the
>    many changes, the list of selectors has been expanded to include the
>    Mobility Header message type.  This has an impact on how security
>    policies and security associations are configured for protecting
>    mobility header messages.  It becomes easier to differentiate between
>    the various Mobility Header messages based on the type value instead
>    of checking if a particular mobility header message is being sent on
>    a tunnel interface between the mobile node and the home agent, as it
>    was in RFC 3776.  The revised IPsec architecture specification also
>    includes ICMP message type and code as selectors.  This makes it
>    possible to protect Mobile Prefix Discovery messages without applying
>    the same security associations to all ICMPv6 messages.
> 
>    This document discusses new requirements for the home agent and the
>    mobile node to use the revised IPsec architecture and IKEv2.
>    Section 4 lists the requirements.  Section 6 and Section 7 describe
>    the required Security Policy Database (SPD) and Security Association
>    Database (SAD) entries.
> 
>    The Internet Key Exchange (IKE) has also been substantially revised
>    and simplified [4].  Section 7.2 of this document describes how IKEv2
>    can be used to setup security associations for Mobile IPv6.
> 
>    The use of EAP within IKEv2 is allowed to authenticate the mobile
>    node to the home agent.  This is described in Section 8.  A method
>    for dynamically configuring a home address from the home agent using
>    the Configuration Payload in IKEv2 is described in Section 9.

This should probably also talk about MOBIKE, as MOBIKE can offer some
more building blocks for the MIP6 which will make it easier to use
IKEv2 when addresses changes. 

> 4.  Requirements
...
> 4.4.  Dynamic Keying Requirements
..
>    o  If the home agent has used IKEv2 to establish security
>       associations with the mobile node, it should follow the procedures
>       discussed in Section 10.3.1 and 10.3.2 of the base specification
>       [2] to determine whether the IKE endpoints can be moved or if the
>       IKE SA has to be re-established.

I do not know exactly what the RFC3775 specifies how to detect whether
the SA can be moved or not, but if MOBIKE was supported by both ends
when the IKEv2 SA was created, then SAs can always be updated with
MOBIKE ADDRESS_UPDATE notify.

> 7.1.  Security Policy Database Entries
...
>    In the examples shown below, the identity of the user of the mobile
>    node is assumed to be user_1, the home address of the mobile node is
>    assumed to be home_address_1, he primary care-of address of the
				  ^^^
>    mobile node is assumed to be care_of_address_1 and the IPv6 address
>    of the Home Agent is assumed to be home_agent_1.

Typo.

> 7.2.  Security Association negotiation using IKEv2
...
>    When the mobile node uses its home address in the IDi field,
>    implementations are required to match the source address in the
>    outermost IP header with the IP address in the IDi field [8].  This
>    verification step, however, should be configurable [8].  With Mobile
>    IPv6, this verification step will always fail because the source
>    address in the IP header is the care-of address and the IP address in
>    the IDi field is the home address.  Therefore, this verification step
>    MUST be disabled.

Actually RFC 4306 section 3.1 says:

   Information from the beginning of the packet through
   the UDP header is largely ignored except that the IP addresses and
   UDP ports from the headers are reversed and used for return
   packets.

I.e the outer IP addresses are not used to verify IDi/IDr fields.
RFC4718 (IKEv2 Clarifications and Implementation Guidelines) says this
explicitly in section 7.1:

   Furthermore, IKEv2 does not require that the addresses in
   ID_IPV4_ADDR/ID_IPV6_ADDR match the address in the IP header of the
   IKE packets.  However, other specifications may place additional
   requirements regarding this.  For example, [PKI4IPsec] requires that
   implementation must be capable of comparing the addresses in the
   ID_IPV4_ADDR/ID_IPV6_ADDR with the addresses in the IP header of the
   IKE packets, and this comparison must be enabled by default.

So it would be enough here to say that you follow IKEv2 way of not
matching the outer IP addresses with the ID payloads, and not follow
the pki4ipsec profile about the IKEv1 (pki4ipsec is mostly for IKEv1
in any case). Also PKI4IPsec WG is now thinking whether they should
say that section 3 of the draft-ietf-pki4ipsec-ikecert-profile-11.txt
is only used for IKEv1 or for both IKEv1 and IKEv2.

It would be better not to refer the pki4ipsec draft at all in this
point, as it just adds confusion. 

> 
> 7.3.  Movements and Dynamic Keying
> 
>    If the mobile node moves and its care-of address changes, the IKEv2
>    SA might not be valid.  RFC 3775 defines a mechanism based on the
>    successful exchange of Binding Update and Binding Acknowledgement
>    messages.  The mobile node establishes the IKE SA with the home agent
>    using its primary care-of address.  The IKE SA endpoints are updated
>    on the home agent when it receives the Binding Update from the mobile
>    node's new care-of address and on the mobile node when it sends the
>    Binding Update to the home agent or when it receives the Binding
>    acknowledgement sent by the home agent.  This capability to change
>    IKE endpoints is indicated through setting the Key Management
>    Capability (K) flag [2] in the Binding Update and Binding
>    Acknowledgement messages.  If the mobile node or the home agent does
>    not support this capability, and has no other means to update the
>    addresses, then an IKEv2 exchange MUST be initiated to re-establish a
>    new IKE SA.

Again MOBIKE should probably be mentioned here.

> 8.  The use of EAP authentication
...
>    When EAP is used, the identity presented by the mobile node in the
>    IDi field may not be the actual identity of the mobile node.  It
>    could be set to an identity that is used only for AAA routing
>    purposes and selecting the right EAP method.  The actual identity is
>    carried inside EAP payloads that is not visible to the home agent.
>    The home agent MUST acquire the mobile node's identity from the
>    corresponding AAA server.  More details can be found in [13].

Actually the rfc4718 does not mention anything about this. The RFC4306
says that the EAP Identity requests SHOULD NOT be sent (section 3.16):

   Note that since IKE passes an indication of initiator identity in
   message 3 of the protocol, the responder SHOULD NOT send EAP Identity
   requests.  The initiator SHOULD, however, respond to such requests if
   it receives them.

I.e the EAP exchange does not include EAP Identity request and reply,
as that information has already been passed inside the ID payloads of
the IKE exchange, and those same IDs are used as EAP identities when
talking to the AAA server.

So the actual identity is visible to the home agent as it is sent
inside the ID payload. 

> 9.  Dynamic Home Address Configuration
...
>    When the home agent receives a configuration payload with a
>    CFG_REQUEST for INTERNAL_IP6_ADDRESS, it replies with a valid home
>    address for the mobile node.  The INTERNAL_IP6_ADDRESS attribute in
>    the CFG_REPLY contains the prefix length of the home prefix in
>    addition to a 128 bit home address.  The home agent could use a local
>    database or contact a DHCPv6 server on the home link to allocate a
>    home address.  The Home Agent should also include an
>    INTERNAL_ADDRESS_EXPIRY attribute to indicate to the mobile node, the
>    duration for which the dynamically allocated home address is valid.

RFC4718 says:
----------------------------------------------------------------------
6.7.  INTERNAL_ADDRESS_EXPIRY

   Section 3.15.1 defines the INTERNAL_ADDRESS_EXPIRY attribute as
   "Specifies the number of seconds that the host can use the internal
   IP address.  The host MUST renew the IP address before this expiry
   time.  Only one of these attributes MAY be present in the reply."

   Expiry times and explicit renewals are primarily useful in
   environments like DHCP, where the server cannot reliably know when
   the client has gone away.  However, in IKEv2 this is known, and the
   gateway can simply free the address when the IKE_SA is deleted.

   Also, Section 4 says that supporting renewals is not mandatory.
   Given that this functionality is usually not needed, we recommend
   that gateways should not send the INTERNAL_ADDRESS_EXPIRY attribute.
   (And since this attribute does not seem to make much sense for
   CFG_REQUESTs, clients should not send it either.)

   Note that according to Section 4, clients are required to understand
   INTERNAL_ADDRESS_EXPIRY if they receive it.  A minimum implementation
   would use the value to limit the lifetime of the IKE_SA.
----------------------------------------------------------------------

So, I would suggest you do recommend NOT to use
INTERNAL_ADDRESS_EXPIRY at all, and simply get the address lifetime
from the lifetime of the IKEv2 SA, i.e. the server will keep on
renewing (if needed, in most cases the IP addresses are allocated from
the local pool, so there is no needs to do renewals) the IP address as
long as client keeps the IKEv2 SA up, and in case the address for some
reason cannot be renewed, or is changed, deletes the IKEv2 SA forcing
the client to get new IP address. As we are talking about home address
here, there should not really be any problems with the address
changing or not being able to renew it.
-- 
[email-masked]

----------
category: Technical
draft: draft-ietf-mip6-ikev2-ipsec
messages: 274
nosy: admin
priority: Should fix
status: Pending
title: Review by Tero Kivinen <[email-masked]>

_________________________________________________
Mip6 issue tracker <[email-masked]>
<http://www.mip4.org/issues/tracker/mip6/issue86>
_________________________________________________

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6