Subject: [IPsec] MIP6 and IKEv2 interaction (was Re: Redirect mechanism for IKEv2)

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 14 Jul 2008 14:39:38 -0700

Hi Arnaud,

I changed the subject since this is not relevant to the IKEv2 redirect
mechanism anymore.

On Sat, Jul 12, 2008 at 3:21 AM, Arnaud Ebalard <[email-masked]> wrote:

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

No, it wouldn't work. RFC 4887 and RFC 5026 identify the additional
requirements for making IKEv2 work with MIPv6.

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

IMHO, such a document is not required. For example it is sufficient to
say that the address obtained through the INTERNAL_IP6_ADDRESS
attribute should be assigned as the MIPv6 home address. Similarly it
is sufficient to say that the home agent IP address bootstrapped by
the mobile node should appear in the SPD entry that is used for
protecting the Binding Update message. Nothing more needs to be said
in the IETF. How the two requirements are implemented in the mobile
node would be specific to the particular implementation. Even if we do
say something about that in the IETF, it would be INFORMATIONAL at the
most.

>> 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.
>
> 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
>> details you are looking for. I think many of the details you are
>> looking for is implementation specific.
>
> The ones described and addressed in draft-sugimoto-mip6-pfkey-migrate
> and draft-qi-mip6-ikev2-interfacing, to start with.

Sure. I think these documents were proposed to be added to the IPsec
and MEXT charters. But there wasn't enough support for them to get
added to the charter.

> Simply put: don't
> expect MIPv6+IKE to work (bootstrapping, movement) without what is in
> the drafts.

Or it could be left implementation specific.

I am not going to respond to the rest of your email since we seem to
have some basic disagreement on what needs to be left implementation
specific and what needs to be addressed in a Standards Track document.
We should discuss that first.

Vijay

>>>>  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.
>
> 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?
>
>
>>>>  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?
>
> 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?
>
>
>>>>  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?
>
> 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?
>
>
>>> 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.
>
> Can you elaborate on that ?
>
>
>>> 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.
>
> ack. Thanks.
>
>
> Cheers,
>
> a+
>
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Hui Deng" <[email-masked]>
Date: Tue, 15 Jul 2008 06:53:20 +0800

Please allow me cut in,

> and MEXT charters. But there wasn't enough support for them to get
as one of co-author of the draft, I have talked with both authors of these
two drafts
to consider merge them together, will try to propose it again in next ietf
meeting.

-Hui

---

From: [email-masked] (Arnaud Ebalard)
Date: Tue, 15 Jul 2008 09:34:59 +0200

Hi Vijay,

Julien, Marcelo, request for comment for you at the end.

> I changed the subject since this is not relevant to the IKEv2 redirect

ack.

> requirements for making IKEv2 work with MIPv6.

Yes, RFC 4877 contains additional requirements and help developers. RFC
5026 adds new functionalities but comes with new questions, IMHO.

> say something about that in the IETF, it would be INFORMATIONAL at the

RFC 2367 is informational (RFC 3549 too). I see your point but I also
think that it makes sense to have the glue/bridges availables (even if
it is in an informational fashion, resulting from development
feedback). Leaving holes prevents interoperability, all the more when
common interfaces do exist.

MIGRATE draft is referenced in many documents including RFC 4877.

> and MEXT charters. But there wasn't enough support for them to get

There was support and at least two documents already available: they are
just considered outside the scope of both WG. IPsec one because it is 
MIPv6-specific and MEXT because it is considered an IPsec issue.

> Or it could be left implementation specific.

Yes. I won't call that a solution, but this is a way to do it. In the
end, as long as the implementation specific parts in MIPv6/IPsec/IKE
picture are pointed, it is still useful, IMHO. Just like feedback from
developers by the mean of informational documents.

> We should discuss that first.

ok, thank you for your comments. IIRC, I never asked for inclusion of
implementation specific parts in Standards Track document. I just
pointed that:

- some mechanisms will not work out of the box because the glue is
  missing with other [normalized] parts of the picture
- this is not explicitly stated in the documents that define the
  features. I find that misleading.

If chairs tell me this is ok that way, I will stop bothering people with
the two previous points.

Cheers,

a+

---

From: Julien Laganier <[email-masked]>
Date: Tue, 15 Jul 2008 14:32:04 +0200

Hello Arnaud,

Speaking as MEXT co-chair, below are inlined two clarifications:

On Tuesday 15 July 2008, Arnaud Ebalard wrote:
> [...]
> >> The ones described and addressed in
> >> draft-sugimoto-mip6-pfkey-migrate and
> >> draft-qi-mip6-ikev2-interfacing, to start with.
> >
> > Sure. I think these documents were proposed to be added to the
> > IPsec and MEXT charters. But there wasn't enough support for them
> > to get added to the charter.
>
> There was support and at least two documents already available: they
> are just considered outside the scope of both WG. IPsec one because
> it is MIPv6-specific and MEXT because it is considered an IPsec
> issue.

A work item on interaction b/w IKEv2 and MIPv6 wasn't added to the MEXT 
charter for two reasons:

- it wasn't possible to add every item with some support to the MEXT 
charter, prioritization was thus needed, and from that point of view 
there wasn't enough support for this compared to other items proposed 
at the time.

- it was also noted that if interactions between MIPv6 and IKEv2 are to 
be based on PFKEY, although these could presumably fall into the MEXT 
scope, there's some upstream work to be done prior to that in the IPsec 
WG to revise PFKEY to IKEv2 and the revised IPsec architecture (RFC 
4301).

> >> Simply put: don't
> >> expect MIPv6+IKE to work (bootstrapping, movement) without what is
> >> in the drafts.
> >
> picture are pointed, it is still useful, IMHO. Just like feedback
> from developers by the mean of informational documents.
>
> > I am not going to respond to the rest of your email since we seem
> > to have some basic disagreement on what needs to be left
> > implementation specific and what needs to be addressed in a
> > Standards Track document. We should discuss that first.
>
> If chairs tell me this is ok that way, I will stop bothering people
> with the two previous points.

As of now we are not chartered to work on this topic, thus I consider we 
don't need to discuss that more, at least for now.

--julien

---

From: [email-masked] (Arnaud Ebalard)
Date: Tue, 15 Jul 2008 17:12:22 +0200

Hi Julien,

> Speaking as MEXT co-chair, below are inlined two clarifications:

Ack.

> there wasn't enough support for this compared to other items proposed 

With two proposed drafts and from the replies I have seen, I had a
different feeling but I imagine you made a precise count. That's fine
for me.

> scope there's some upstream work to be done prior to that in the IPsec 

Hum, I don't see how/why the mechanism described in MIGRATE draft would
benefit in waiting for an update of PF_KEY. On the opposite direction, if
the glue between MIPv6 and IPsec/IKE provided by a PF_KEY-based
interface is available as an informational document *when/if* there is
an update of the standard, it would possibly be considered to be merged
with this update. In the end, I don't buy this argument.

> don't need to discuss that more, at least for now.

Ack. At your request, I will try and stop arguing against the trend in
some recent mechanisms which now make no difference between IPsec/IKE
and MIPv6 entities (implicitly leaving interfaces between the two as
implementation issues). I will wait for you to bug me on that.

Thanks for your time,

Cheers,

a+