Subject: Re: [MEXT] [IPsec] Redirect mechanism for IKEv2

From: [email-masked] (Arnaud Ebalard)
Date: Fri, 16 May 2008 11:44:05 +0200

Hi Vijay,

"Vijay Devarapallli" <[email-masked]> writes:

> The draft at the URL below describes a mechanism for re-directing an
> IKEv2 initiator to another gateway during the IKE_SA_INIT exchange.
> This could be used for Mobile IPv6 also for a home agent to re-direct
> a mobile node to another home agent.
>
> Comments/reviews are welcome.

Some comments below, with quoted parts from the draft. Sorry for
cross-posting but the discussion probably belongs to both ML. 

Mostly, the idea of the mechanim and the coverage looks ok to me but the
relationships with MIPv6 does not.

To summarize most of my comments, the draft makes the redirect mechanism
happen at the IKE level and expects that it has no impact on the work of
the MIPv6 part. In practice, the address of the Home Agent being also
the address of the IKE GW and the IPsec SA (even if the negotiation
could be modified to be for different addresses regarding the IPsec SA
and the IKE GW), there is a need for synchronization between IKE and
MIPv6. IMHO, this is missing in the draft and should be stated. 

Note that this summary and some of my comments/questions below can also
be applied to Section 9 of RFC 4877, which describes Dynamic Home
Address configuration using IKEv2.

For me, the redirect mechanism described in the draft is in some way the
dual of the Dynamic HoA configuration using IKE described in section 9
of RFC 4877. 

Basically:

- triggering event: IKE seems to initiate connections just like that,
  without real triggering events, i.e. some packets being sent that
  require protection and match some selector of a SPD entry.
- communications/synchronization: IKE is used (addresses here and in
  4877) for configuring/negotiating MIPv6 parameters but the
  synchronization of those elements is not covered. I would also include
  the IPsec in the picture. In practice, the MIPv6 modules, the IKE
  daemon and the IPsec stack must work *together*. At the moment, some
  draft and RFC on those elements have expectation but do not cover the
  interactions between those elements. 

If I missed some reference document or something obvious, don't hesitate
to correct me.

From the introduction:

>  Mobile IPv6 [3] uses IKEv2 for mutual authentication between the
>  mobile node and the home agent.  IKEv2 is also used for home address
>  configuration and setting up IPsec security associations for
>  protecting Mobile IPv6 signaling messages [4]."

uses -> may/can use. The mechanism is not required. IKEv1 is also
usable, so using IKE without any version might be better here.

>  The IKEv2 exchange precedes the exchange of Mobile IPv6 signaling
>  messages.

In practice, AFAICT, the IKE exchange is *triggered* by the emission of
the BU. It seems that RFC 4877 has started to take a different direction
where IKE is used to configure MIPv6, but the details are missing.

>  Therefore the mechanism described in this document can be also be 
>  used by a Mobile IPv6 home agent to re-direct a mobile node to
>  another home agent.

Collusion between Key Manager and HA operation.

>  There is a Home Agent Switch mechanism available for re-directing a
>  mobile node to another home agent, described in [5].  The Home Agent
>  Switch mechanism can only be used after the binding cache had been
>  created at the home agent for the mobile node.  The disadvantage with
>  this is that quite a bit of state is created on the home agent before
>  the mobile node can be re-directed to another home agent.  The
>  mechanism described in this document can be used for re-directing a
>  mobile node before any state is created on the home agent.

IMHO, there is a difference between IKE and MIPv6 operations:

1) A Home Agent is overloaded and start redirecting MN to another HA:
   for instance, it is already using all its available upload bandwidth
   for registered MN (which is unrelated to IPsec/IKE).
2) There are too many IKE peers connecting at the same time on an IKE
   daemon (for the setup of IPsec SA between MN and HA or common
   clients) and the IKE daemon starts redirecting clients to another IKE
   daemon.

What I mean is that, AFAICT, the two mechanism solve different problems,
through different channels.

In section 3

>  When the VPN client receives the IKE_SA_INIT response with the
>  REDIRECT payload, it initiates a new IKE_SA_INIT exchange with the
>  VPN gateway listed in the REDIRECT payload.  The VPN client includes
>  the IP address of the original VPN gateway that re-directed the
>  client.  The IKEv2 exchange then proceeds as normal with the selected
>  VPN gateway.

IMHO, the last sentence simply does not cover the possible associated
issues and how things should be done, *how* the associated users (IPsec
stack, MIPv6 module) are notified (on both sides). I am considering that
MIPv6 is used to cover all cases. 

- address of the IKE GW on the remote side
- the address of the HA used by the client
- the remote address of currently negotiated transport mode SA
  protecting MIPv6 signaling 
- endpoints of negotiated tunnel mode SA protecting data traffic if any

I imagine that they will be set to the new IP. AFAICT, if the
negotiation was triggered by a BU, there will be a mismatch between the
triggering packet and the new destination.

>  When this mechanism is used with Mobile IPv6, a mobile node's
>  security associations with its home agent may expire while it still
>  has a valid binding cache entry at the home agent.  In this case, the
>  mobile node MUST NOT use an anycast address as the destination
>  address in the IKE_SA_INIT exchange to setup new security
>  associations.  It MUST try to setup security associations with its
>  existing home agent.

How does the MN knows the address is anycast?

Here, I do not understand well the MIPv6 scenario. Can you clarify what
you mean.

> Section 4.

Perhaps the previous point regarding interactions of MIPv6 clients with
IKE daemons that are part of an anycast domain belong here. You should
probably add some clear statements regarding the use of anycast
addresses for IKE daemon for MIPv6 clients. More precisely, what are the
conditions for a MIPv6 client to be configured with an anycast address
(or a name resolving to an anycast address) for the IKE daemon of its
HA.

Can you tell me if I am wrong on this summary: you expect that a MIPv6
client can be configured with an anycast address (or a name resolving
to an anycast address) for the IKE daemon of its HA if:

- its local IKE Daemon support the Redirect
- it is redirected to a non-anycast unicast address when it connects the
  first time 
- it uses the address for all future connections to the remote IKE
  daemon while it is registered with its HA.

> 5.

I skipped it at the moment but will review in a future version of the
draft. 

> 6.  Security Considerations

ok.

Cheers,

a+

_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext