Subject: [Monami6] IPsec and IKEv2 interaction with mutliple CoAs

From: Vijay Devarapalli <[email-masked]>
Date: Sat, 03 Mar 2007 00:52:23 -0800

Hello folks,

Here is the proposed text for section 8 (IPsec and IKE
interaction) in draft-ietf-monami6-multiplecoa. This is
just an initial draft version and a starting point for
further discussions. I am not sure if all issues have
been addressed. Please review and comment.

Vijay

------------------------------------------------------------------------

8.  IPsec and IKEv2 interaction

    Mobile IPv6 [2] and the NEMO protocol [3] require the use of IPsec to
    protect signaling messages like binding updates, binding
    acknowledgements and return routability messages.  IPsec may also be
    used protect all reverse tunneled data traffic.  The Mobile IPv6-
    IKEv2 specification [9] specifies how IKEv2 can be used to setup the
    required IPsec security associations.  The following assumptions were
    made in RFC 3775, RFC 3963 and the MIP6-IKEv2 specification with
    respect to the use of IKEv2 and IPsec.

    o  There is only one primary care-of address per mobile node.

    o  The primary care-of address is stored in the IPsec database for
       tunnel encapsulation and decapsulation.

    o  When the home agent receives a packet from the mobile node, the
       source address is verified against the care-of address in the
       corresponding binding cache entry.  If the packet is a reverse
       tunneled packet from the mobile node, the care-of address check is
       done against the source address on the outer IPv6 header.  The
       reverse tunnel packet could either be a tunneled HoTi message or
       tunneled data traffic to the correspondent node.

    o  The mobile node runs IKEv2 (or IKEv1) with the home agent using
       the care-of address.  The IKE SA is based on the care-of address
       of the mobile node.

    The above assumptions may not be valid when multiple care-of
    addresses are used by the mobile node.  In the following sections,
    the main issues with the use of multiple care-of address with IPsec
    are addressed.

8.1.  Use of Care-of Address in the IKEv2 exchange

    For each home address the mobile node sets up security associations
    with the home agent, the mobile node must pick one care-of address
    and use that as the source address for all IKEv2 messages exchanged
    to create and maintain the IPsec security associations associated
    with the home address.  The resultant IKEv2 security association is
    created based on this care-of address.

    If the mobile node needs to change the care-of address, it just sends
    a binding update with the care-of address it wants to use, without
    the Binding Unique Identifiery sub-option, but with the 'K' bit set.
    This will force the home agent to update the IKEv2 security
    association to use the new care-of address.  If the 'K' bit is not
    supported on the mobile node or the home agent, the mobile node MUST
    re-establish the IKEv2 security association with the new care-of
    address.  This will also result in new IPsec security associations
    being setup for the home address.

8.2.  Transport Mode IPsec protected messages

    For Mobile IPv6 signaling message protected using IPsec in transport
    mode, the use of a particular care-of address among multiple care-of
    addresses does not matter for IPsec processing.

    For Mobile Prefix Discovery messages, RFC 3775 requires the home
    agent to verify that the mobile node is using the care-of address
    that is in the binding cache entry that corresponds to the mobile
    node's home address.  If a different address is used as the source
    address, the message is silently dropped by the home agent.  This
    document requires the home agent implementation to process the
    message as long as the source address is is one of the care-of
    addresses in the binding cache entry for the mobile node.

8.3.  Tunnel Mode IPsec protected messages

    The use of IPsec in tunnel mode with multiple care-of address
    introduces a few issues that require changes to how the mobile node
    and the home agent send and receive tunneled traffic.  The route
    optimization mechanism described in RFC 3775 mandates the use of
    IPsec protection in tunnel mode for the HoTi and HoT messages.  The
    mobile node and the home agent may also choose to protect all reverse
    tunneled payload traffic with IPsec in tunnel mode.  The following
    sections address multiple care-of address support for these two types
    of messages.

8.3.1.  Tunneled HoTi and HoT messages

    The mobile node MAY use the same care-of address for all HoTi
    messages sent reverse tunneled through the home agent.  The mobile
    node may use the same care-of address irrespective of which
    correspondent node the HoTi message is being sent.  RFC 3775 requires
    the home agent to verify that the mobile node is using the care-of
    address that is in the binding cache entry, when it receives a
    reverse tunneled HoTi message.  If a different address is used as the
    source address, the message is silently dropped by the home agent.
    This document requires the home agent implementation to decapsulate
    and forward the HoTi message as long as the source address is one of
    the care-of addresses in the binding cache entry for the mobile node.

    When the home agent tunnels a HoT message to the mobile node, the
    care-of address used in the outer IPv6 header is not relevant to the
    HoT message.  So regular IPsec tunnel encapsulation with the care-of
    address known to the IPsec implementation on the home agent is
    sufficient.

8.3.2.  Tunneled Payload Traffic

    When the mobile sends and receives multiple traffic flows protected
    by IPsec to different care-of addresses, the use of the correct
    care-of address for each flow becomes important.  Support for this
    requires the following two considerations on the home agent.

    o  When the home agent receives a reverse tunneled payload message
       protected by IPsec in tunnel mode, it must check that the care-of
       address is one of the care-of addresses in the binding cache
       entry.  According to RFC 4306, the IPsec implementation on the
       home agent does not check the source address on the outer IPv6
       header.  Therefore the care-of address used in the reverse
       tunneled traffic can be different from the care-of address used as
       the source address in the IKEv2 exchange.  However, the Mobile
       IPv6 stack on the home agent MUST verify that the source address
       is one of the care-of addresses registed by the mobile node before
       decapsulating and forwding the payload traffic towards the
       correspondent node.

    o  For tunneled IPsec traffic from the home agent to the mobile node,
       The IPsec implementation on the home agent may not be aware of
       which care-of address to use when performing IPsec tunnel
       encapsulation.  The Mobile IP stack on the home agent must specify
       the tunnel end point for the IPsec tunnel.  This may require tight
       integration between the IPsec and Mobile IP implementations on the
       home agent.

----------------------------------------------------------------------------

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

---

From: Francis Dupont <[email-masked]>
Date: Tue, 06 Mar 2007 12:56:10 +0100

In your previous mail you wrote:

   Some comments:

   
=> I don't know if IPsec or IKEv2 are concerned by secondary care-of
addresses (IMHO they are not) so even if this statement is a bit strange
(primary implies one) it is correct.

=> database -> SAD
Note the check described below doesn't make sense for IPsec itself as
the origin of packets is cryptographically verified.

   
=> the traditional wording is "IKEv2 runs over".

=> note this is not the secondary care-of address(es) case. I believe
the context (i.e., the document itself) will make the point clear.

                                    ^
   
=> it should be fined at least in the list to have the SPD entries for
this case.

                                ^ ar
          correspondent node.
   
=> I deeply disagree with this paragraph:
 - IPsec verifies the origin of packets with something far stronger than
  an address check (i.e., crypto vs access list).
 - one can't assume the entity performing the decapsulation is the
  Mobile IPv6 stack. In fact it should be more likely the IPsec stack.
IMHO we have here a good example of a spurious check: it doesn't improve
the security but has a real impact on the flexibility.

       o  For tunneled IPsec traffic from the home agent to the mobile node,
          The IPsec implementation on the home agent may not be aware of
          which care-of address to use when performing IPsec tunnel
          encapsulation.
=> this is not true: the address to use is a property of the SA and
is usually the addresse IKE runs over.

          The Mobile IP stack on the home agent must specify
          the tunnel end point for the IPsec tunnel.

=> this is a false consequence of the preceeding false claim.

          This may require tight
   
=> fortunately the right is not true...

Regards

[email-masked]

PS: to summary the situation from the IPsec side:
 - at the decapsulation phase the outer source address doesn't matter
  because the origin is cryptographically verified.
 - at the encapsulation phase any working outer destination address is
  enough, so the default (current primary care-of address for HA -> MN)
  is enough.
 - there is no specified way (i.e., MOBIKE failed to provide one) to change
  the outer address: one has to establish another IKE session in parallel.

---

From: Vijay Devarapalli <[email-masked]>
Date: Sat, 17 Mar 2007 21:34:19 -0700

Hi Francis,

Sorry for the delay in responding
> (primary implies one) it is correct.

Perhaps re-word as "one care-of address at a time per
mobile node"?

> the origin of packets is cryptographically verified.

True. But in MIPv6 we require the HA to check the source
address on the outer header before decapsulating and
forwarding the tunneled packets.

> => it should be fined at least in the list to have the SPD entries for

I don't understand. You want the SPD entries listed here?

>   an address check (i.e., crypto vs access list).

Thats fine. I can re-word it to say, the IPsec implementation
does not compare the source address used on the outer header
against the address used to in the IKEv2 exchange.

> the security but has a real impact on the flexibility.

Unfortunately we have a 'MUST' in RFC 3775 to check the
source address on the outer IPv6 header against the CoA in
binding cache entry. You want to relax that for IPsec
protected tunneled traffic?

> is usually the addresse IKE runs over.

Yes, there is an issue here. The right CoA to use for a
particular flow is known to the Monami6 implementation and
the encapsulation is done by the IPsec implementation on
the home agent.

> => fortunately the right is not true...

I am open to suggestions that does not require tighter
integration between the IPsec and Monami6 implementations
on the HA. :)

>   enough, so the default (current primary care-of address for HA -> MN)

ah.. no. We still want to send a particular flow to a
particular CoA. "Any CoA" won't do.

>   the outer address: one has to establish another IKE session in parallel.

Setting up one IKE SA per CoA is always possible. I hope
we can do better. Perhaps we should add text that also
describes the simple case of one IKEv2 SA per CoA and one
IPsec tunnel SA per CoA.

Vijay

---

From: Francis Dupont <[email-masked]>
Date: Sun, 18 Mar 2007 21:32:57 +0100

=> as there can be some secondary care-of addresses the re-word is false.
What about "ther is a primary care-of address per mobile node"?

   
=> but this check is not useful as it is an ACL-type check when
IPsec provides a crypto proof. One way to solve this is to stand
that with IPsec the entity performing encapsulation/decapsulation
is IPsec itself and not MIPv6 (and this is the way most implementations
follow).

   > => it should be fine at least in the list to have the SPD entries for
   > this case.

=> yes, I'd like to get the SPD for this case.

   
=> I agree.

   
=> yes!

   
=> hum. IPsec doesn't give a direct control on the CoA, it uses the address
IKE runs over, which is a typical indirect control.

   we can do better.

=> I am afraid hope is not yet enough in this case (:-).

   Perhaps we should add text that also
   describes the simple case of one IKEv2 SA per CoA and one
   IPsec tunnel SA per CoA.
   
=> this shall work but is not better.
It seems we agree about the IPsec/IKE side, doesn't it?

Regards

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 19 Mar 2007 02:56:01 -0700

> => as there can be some secondary care-of addresses the re-word is false.

Even if there is a second care-of address, for a particular
IKEv2 SA and the associated IPsec SAs, there is only one
CoA. Thats what is assumed in RFC 3775.

> is IPsec itself and not MIPv6 (and this is the way most implementations

It is probably best if the MIPv6/Monami6 stack always performs
this check. As you know, the traffic can be sent reverse-tunneled
without IPsec protection.

> It seems we agree about the IPsec/IKE side, doesn't it?

We do.

But we do need a solution for the Monami6 stack to specify the
tunnel end point for IPsec protected traffic flows. And we don't
want to create an IKEv2 SA per CoA.

Vijay

---

From: Francis Dupont <[email-masked]>
Date: Mon, 19 Mar 2007 18:10:57 +0100

=> Vijay, you are saying that even there are two CoAs there is only one...

   
   
=> you assume both the entity doing the encapsulation and decapsulation
is the same and it uses the same address when by definition after
decapsulation the outer address is dropped...

   We do.

=> but even we don't want it today it is the only solution.
So do you propose:
 - resume MOBIKE activity but this time make the WG to do a better job
  (note I asked many times for the feature we need, i.e., to update
   the endpoint addresse of a subset of IPsec SAs, unfortunately
   without success)
 - create our own mechanism (but IPsec/IKE is not in the scope of
   the WG...
 - something else
 - stay with current working but not pretty solution.

Thanks

PS: I am next room (congress III) at Softwire but I've just joined
Jabber monami6 room to be warned if/when I'll need to move.