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

From: "Vijay Devarapalli" <[email-masked]>
Date: Fri, 11 Jul 2008 16:29:22 -0700

Hi Arnaud,

I apologize for the delay in responding to your email.

On Fri, May 16, 2008 at 2:44 AM, Arnaud Ebalard <[email-masked]> wrote:
> 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.

I am not sure if this document should talk about the interactions
between the MIPv6 and IKEv2 processes in a particular implementation.

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

I have seen other emails from you on this subject, especially the
interactions between IKEv2 and MIPv6 as described in RFC 4877 and RFC
5026. Perhaps, as you suggest, it might be a good idea to write a
separate document that describes how these two protocols can interact
with each other. Personally, it is not clear to me on what sort of
details you are looking for. I think many of the details you are
looking for is implementation specific.

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

Fixed.

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

When the mobile node boots up and figures that it needs to configure a
home address, it can trigger an IKEv2 exchange with the home agent.
Nothing needs to be said. This would be implementation specific on the
mobile node.

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

Yes. So?

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

Do you see the need for any changes in the draft for this?

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

It does not have to be triggered by the Binding Update. The
bootstrapping procedure on a Mobile IPv6 mobile node could be
triggered for some other reason.

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

The MIPv6 home agents anycast address is well known. See
http://www.iana.org/assignments/ipv6-anycast-addresses. But I
understand what you mean. I modified the paragraph as follows.

   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 the original home agent 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.

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

The re-direct should work irrespective of whether an anycast address
is used. If anycast addresses are used, you don't have to necessarily
configure the mobile node with the anycast address. The DNS lookup for
the home agent can return an anycast address too.

Vijay

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

---

From: [email-masked] (Arnaud Ebalard)
Date: Sat, 12 Jul 2008 12:21:47 +0200

Hi Vijay,

> I apologize for the delay in responding to your email.

no problem. Some responses below.

> between the MIPv6 and IKEv2 processes in a particular implementation.

If it does not, everything is left as an implementation issue, which
prevents IKE deamon from vendor "A" to be used out of the box with MIPv6
daemon from vendor "B" on a given platform. My question would be: if
someone implements the mechanism proposed by the draft in an IKE daemon,
will that work out of the box when the IKE daemon is used on a
MN. AFAICT, no. 

IMHO, if it is time consuming to understand the precise associated needs
for interaction or to address them in the draft, it should be stated in
the document so noone thinks it will work without more work.

> with each other. 

Yes, now that there is some implementation feedback on the topic, it
would be good to:

1) consider them
2) address them

The difficulties are that the subject is both IPsec/IKE and
MIPv6-related which makes it a less obvious item on ipsec or
mext ML than a new functionality for one of the protocol.

> Personally, it is not clear to me on what sort of

The ones described and addressed in draft-sugimoto-mip6-pfkey-migrate
and draft-qi-mip6-ikev2-interfacing, to start with. Simply put: don't
expect MIPv6+IKE to work (bootstrapping, movement) without what is in
the drafts.

> Nothing needs to be said. This would be implementation specific on the

Precisely and in the order of the sentence:

- I agree that a MN will manage to know that it needs a Home Addres
- I don't see *how* it will trigger an IKEv2 exchange
- I don't see *how* it will retrieve the address gathered during the
  IKEv2 exchange

Again, at the end of the day, if 'A' develops a MIPv6 Daemon, and 'B'
develops an IKEv2 daemon, there is no way you can even start to make
them interoperate WRT HoA assignement *IF* they have not work together
to define a *custom* interface. What do you think?

>> Collusion between Key Manager and HA operation.

I don't follow you: are you considering that MIPv6 and IKEv2 operations
must be implemented in a single application in all cases? Hence, the
lack of interface because you consider that as internal plumbering? 

> Do you see the need for any changes in the draft for this?

perhaps adding some use cases by discussing how the IKE could monitor
some values (number of IKE peer, upload bandwidth consumed by MN, ...)
or how you expect an administrator would use the proposed solution: what
specific need does the solution address?

> triggered for some other reason.

Can you elaborate on that ?

>    associations.  It MUST try to setup security associations with its

ack. Thanks.

Cheers,

a+