Subject: [Mip6] Review of the draft-ietf-mip6-ikev2-ipsec-07.txt

From: Tero Kivinen <[email-masked]>
Date: Tue, 7 Nov 2006 00:05:32 +0200

>   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]

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Sun, 26 Nov 2006 13:25:41 -0800

Hi Tero,

thanks for the review.

> IKEv2 when addresses changes. 

the use of MOBIKE and MIP6 between the mobile node
and the home agent at the same time was discussed
quite extensively on the MIP6 mailing list. the
general thinking is that you shouldn't have two
protocols trying to manage the tunnel between the
mobile node and the home agent at the same time.
with MIPv6, the tunnel is basically a MIP tunnel,
sometimes protected by ESP in tunnel mode. the
binding update/binding acknowledgment messages are
used for updating the tunnel end-point whenever the
mobile node moves, irrespective of whether the
tunnel is protected by ESP or not.

> MOBIKE ADDRESS_UPDATE notify.

RFC 3775 describes the use of a flag (K) in the
binding update/binding ack messages to signal the
capability to update the IPsec SA when the MIP
tunnel end point is updated. this document does
not modify that.

> point, as it just adds confusion. 

agreed. here is the new text.

    When the mobile node uses its home address in the IDi field,
    implementations are not required to match the source address in the
    outermost IP header with the IP address in the IDi field.  According
    to RFC 4306 [4], the IP header fields in the IKEv2 messages are
    ignored and used only in the IP headers for IKEv2 messages sent as
    replies.

> Actually the rfc4718 does not mention anything about this. 

agreed. RFC 4718 does not address how the IKEv2
responder can acquire the actual mobile node
identity.

> The RFC4306

the current text is there to address scenarios
where the identify in the IDi field is not the
same identity sent in the EAP messages. section
3.5 of RFC 4718 does say that there could be
such cases. it simplifies things if the IDi does
contain the actual identify of the mobile node.
I would be happy to remove the text.

>>    duration for which the dynamically allocated home address is valid.

yes this make sense in IKEv2 context. however...

> changing or not being able to renew it.

if we tie the home address lifetime to the IKE SA
lifetime, then I am afraid that home address
assignment through IKEv2 is not going to be popular.
folks would use other mechanisms to assign the home
address to the mobile node. a Mobile IP home address
by definition is supposed to be a long lived address
that does not change very often.

if there is no restriction that the lifetime in
INTERNAL_ADDRESS_EXPIRY attribute should always be
less than the IKEv2 SA lifetime, perhaps MIPv6 could
use the INTERNAL_ADDRESS_EXPIRY attribute. maybe we
have found a use for the attribute. ;)

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 27 Nov 2006 07:33:46 -0800

Tero Kivinen wrote:
> Vijay Devarapalli writes:
> Using MOBIKE would allow MIP6 to work on more implementations as I
> guess MOBIKE will be implemented in most of the future IPsec client
> style implementations. I.e. if MIP6 could be able to use standard
> IPsec + MOBIKE combination, there would be no need for special support
> for MIP6 inside the IPsec stack. 

IMHO, this is not sufficient to add a dependency
to MOBIKE for MIPv6. moreover, the main problem
with the use of MOBIKE is that it competes to
manage the same tunnel as Mobile IP between the
mobile node and the home agent.

> As by IKEv2 RFC we are not sending EAP identifies inside EAP exchange
> when using EAP in IKEv2, the IDi field is used in the EAP.

I was under the same impression, until Jari pointed
out the text in RFC 4718 as part his AD review. this
text was added then.

would it be ok if I add some text warning that there
are implementations out there where EAP implementations
out there where the actual identity is carried inside
the EAP exchange?

> Hmm... I have been thinking that most of the implementations do limit
> the INTERNAL_ADDRESS_EXPIRY to be shorter time than the expected IKE
> lifetime, but I do not think there is anything in the specifications
> to limit it so. So in that sense it would be ok to specify much longer
> time for the INTERNAL_ADDRESS_EXPIRY, but on the other hand as long as
> the address is valid all the time during the IKEv2 exchnage there is
> no need to give any INTERNAL_ADDRESS_EXPIRY times, as next time you
> connect again and get new address, you of course propose the
> previous address you already have.
> 
> On the other hand why does the client need to know the time how long
> the address is valid? If he has connection to the server (IKEv2 SA, or
> MIP6 state) all the time, then the server will probably keep the
> address reserved for him all that time, and changing it would cause
> lots of problems.
> 
> When client does not have any state with the server (i.e. no IKEv2 SA,
> and no MIP6 state anymore), then when it first time connects it will
> need to get the address for himself again anyways, and in that case it
> can propose the old address, and the server can give it if it is free.
> 
> Also in IPv6 I do not think we can claim that the server needs to
> recycle addresses, so most of the time addresses are changed because
> client requests so, not because server will run out of IP-addresses.

ok. removed the INTERNAL_ADDRESS_EXPIRY attribute.
the new text would be

    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 duration for which the home address is allocated
    to the mobile node is the same as the IKEv2 security association
    lifetime.

there is text already in the following paragraph
to say that the mobile node can request the same
home address again.

    The mobile node could suggest a home address that it wants to use in
    the CFG_REQUEST.  For example, this could be a home address that it
    was allocated before or could be an address the mobile node auto-
    configured from the IPv6 prefix on the home link.  The Home Agent
    could let the mobile node use the same home address by setting the
    INTERNAL_IP6_ADDRESS attribute in the CFG_REPLY payload to the same
    home address.

Vijay

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 27 Nov 2006 12:16:50 -0800

<snip>

> 
> RFC 3775 describes the use of a flag (K) in the binding 
> update/binding ack messages to signal the capability to 
> update the IPsec SA when the MIP tunnel end point is updated. 
> this document does not modify that.
> 

You mean the IKE_SA? I don't see any text in RFC3775 that describes
updating the IPsec SA - I guess the assumption was that the IPsec SA is
based on the HoA and it survives movements. However, when ESP is used in
tunnel mode, this would imply changing the tunnel outer address. Is that
captured anywhere? 

Vidya

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 27 Nov 2006 16:21:51 -0800

> tunnel mode, this would imply changing the tunnel outer address. Is that

from RFC 3775

    Key Management Mobility Capability (K)

       If this bit is cleared, the protocol used for establishing the
       IPsec security associations between the mobile node and the home
       agent does not survive movements.  It may then have to be rerun.
       (Note that the IPsec security associations themselves are expected
       to survive movements.)  If manual IPsec configuration is used, the
       bit MUST be cleared.

the K bit has always been for the protocol that
setup the IPsec security associations, which means
IKEv2.

Vijay

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 29 Nov 2006 23:22:49 +0100

Hi all,

This message, in accordance with IETF procedures, is to inform the MIP6 
working group that the MIP6 co-chairs have commissioned a MIP6 Firewall 
Traversal design team.

The purpose of this design team is to complete the following WG charter 
item:
"
Work on solutions to deal with firewalls and the problems that
firewalls cause as identified in RFC 4487.
"

The output of the design team is one or more document(s) to the MIP6 
working group. This design team will use a separate mailing list, 
conference calls and Jabber chats.

Members of the design team are:
Hannes Tschofenig: [email-masked]
Gabor Bajko: [email-masked]
Suresh Krishnan: [email-masked]
Hesham Soliman: [email-masked]
Yaron Sheffer: [email-masked]
Qiu Ying: [email-masked]
Ram Vishnu: [email-masked]
Niklas Steinleitner: [email-masked]

The following hat wearers are also take part:
Basavaraj Patil: [email-masked]
Gopal Dommety: [email-masked]

Archives of this design team can be found here:
http://zeke.ecotroph.net/pipermail/mip6-firewall/

As with any design team in the IETF, the output of this design team must 
be approved by the MIP6 working group nor carries any special 
consideration in development of MIP6 working group consensus.

Ciao
Hannes

PS: I would like to thank Andy Newton for setting up the mailing list.

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 27 Nov 2006 13:17:01 +0200