Subject: [nemo] Re: [Mip6] Please review and provide input to DSMIP6-IKEv2 discussion

From: Shinta Sugimoto <[email-masked]>
Date: Fri, 02 Nov 2007 14:25:45 +0900

Hi Hesham and all,

Thanks for the summary and excuse me for responding late.
I went through all the emails concerning the topic of
DSMIPv6 and IKE.  Let me state my opinion.

In conclusion, I prefer solution 1.  It seems that there
is no optimal solution to solve the problem.  Ultimately,
to achieve address-family-agnostic IP mobility with the
support of network layer security (payload protection by
IPsec) in a *clean* way, MOBIKE would be the best choice,
I believe.  And IMHO, we should note this fact when
choosing the solution.  Please note that I am NOT saying
that DSMIPv6 is not needed at all.  DSMIPv6 and MOBIKE
are meant to solve different problems and have different
properties.  And thus we need a solution for DSMIPv6 to
solve the problem that has been discussed in the mailing
list.

IMHO, we should take the arpproach that modifies DSMIPv6
rather than IKE because the approach of making modifications
to IKE would never be superior to MOBIKE, anyway.  For
this reason, I prefer solution 1.

However, I need one clarification on solution 1.  How
would IKE run initially (at the bootstrap stage)?
In solution 1, it is assumed that IKE runs over MIPv6,
i.e., IKE chooses home address as an IKE/IPsec endpoint.
Then there is an obvious chicken-and-egg problem because
IKE relies on MIPv6 and MIPv6 relies on IPsec (i.e., IKE).
The implication is that IKE cannot be initiated in the
bootstrapping stage, unless some exceptional handling
is done.  In bootstrapping, there is no MIPv6 home
registration made yet, thus there is no home address
available.  I am not sure if such operation of IKE -
establishing IPsec SA whose endpoint is an IP address
which is not working/available at the point of IPsec
SA negotiation - is permitted or not.  If not, then
solution 1 should be excluded from the candidate solution.
If yes, then the specification should address how IKE
negotiation is done in the bootstrapping stage.
Another implication of solution 1 is that MN cannot
bootstrap from IPv4 private networks because we don't
assume IKE to handle NAT.

Regards,
Shinta

Basavaraj Patil wrote:
> 
> Hello,
> 
> I would like to encourage more people on the MIP6 and NEMO lists to review
> the discussion related to DSMIP6 and IKEv2 and the issue that was raised
> earlier as well as the proposed solutions.
> Please provide your feedback to the ML.
> 
> At the present time there are only a handful of people commenting and it is
> difficult to gauge consensus as a result.
> 
> I have also requested a couple of IKE experts (Tero Kivinen and Pasi Eronen)
> to review and provide input.
> 
> -Basavaraj
> 
> 
> On 10/25/07 9:01 AM, "ext Hesham Soliman" <[email-masked]> wrote:
> 
> 
>>Folks,
>>
>>This discussion has been going on for a while and I'm sure it wasn't for
>>easy to follow. 
>>This email contains a summary of the discussion so far and a call for
>>comment/concensus. Please respond promptly because there is some pressure
>>from 3GPP to get this draft out very soon.
>>
>>The issue is how to run IKE in combination with DSMIPv6 in a private
>>IPv4-only network. If you want more detail about why this is a problem
>>please look at the thread "DSMIPv6 and IKE".
>>
>>There are three types of solutions that we discussed. A quick summary of
>>each below:
>>
>>1. The Virtual link approach. In this case IKE runs over v6 only and is
>>completely unaware of the IPv4 network. As a result IKE's NAT traversal is
>>never invoked. Only DSMIPv6's NAT traversal is used. In this approach, the
>>DSMIPv6 implementation in the HA is required to cache the outer IPv4 address
>>and source port of the IPv4 message that contains IKE, then append them to
>>the response from its own IKE daemon. This is basically done to hide the
>>IPv4 network from IKE and effectively disable its NAT traversal, which
>>solves our problem.
>>Three people agreed with this approach but two people (I'm including
>>Christian) are against it. So there doesn't seem to be concensus on this. I
>>believe the concern here was that the HA's caching of the outer address and
>>port was complex for the implementation.
>>
>>2. Karen suggested a way of running IKE without any changes (again see the
>>thread for details). In this approach DSMIPv6 BUs are secured with ESP as
>>usual. Normal traffic is sent over the DSMIPv6 port. However, secure traffic
>>is sent over the IKE port (4500). The result of this approach is that it
>>takes two messages to complete a handover, one from DSMIPv6 (BU) and an
>>update from IKE (for the secure traffic). The concern that I had here in the
>>discussion with Karen was the number of messages and the delays associated
>>for that. Of course IKE doesn't do movement detection ...etc. So my concern
>>is the discriminatory experience of the handover for different parts of the
>>traffic. 
>>
>>3. The third class of solutions involves either modifying MIPv6 (adding new
>>messages) or IKE or both. I'm only including this for completeness, no one
>>really wants this.
>>
>>Please send your comments on the above. Basically the options are 1 or 2. In
>>theory we could do both but I think it's best to pick one method for this to
>>avoid interoperability issues and additional complexity.
>>
>>Hesham
>>
>>
>>
>>
>>_______________________________________________
>>Mip6 mailing list
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/mip6
> 
> 
> 
> _______________________________________________
> Mip6 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mip6
>

---

From: "Hesham Soliman" <[email-masked]>
Date: Fri, 2 Nov 2007 17:33:53 +1000

Hi Shinta,  

Please see my response below

 > In conclusion, I prefer solution 1.  

=> ok.

 > this reason, I prefer solution 1.

=> ok.

 > available.  

=> I think given that we're not allowed to use a mapped address as a CoA, it
should be understood that for DSMIPv6 to work there MUST be a home address
known to the MN. I think this is bad news for DSMIPv6 but there is nothing I
can do about it. So to answer your question, an IPv6 HoA must already be
known. The rest of the handling is well know, the src address selection
gives the IPv6 HoA to IKE (IKE need not *choose* it) and the HA side was
explained in my email. 

Hesham

---

From: Shinta Sugimoto <[email-masked]>
Date: Fri, 02 Nov 2007 16:53:28 +0900

Hi Hesham,

Please find my comments below:

Hesham Soliman wrote:

(snip)

> can do about it.

Sorry, I don't follow.  Could you please elaborate why the design
choice made (to not use mapped address as a CoA) has an effect on
the chicken-and-egg problem of IKE and DSMIPv6?

> So to answer your question, an IPv6 HoA must already be

Let me responde to your comments above, after I understand your
earlier comments.

Regards,
Shinta

---

From: "Hesham Soliman" <[email-masked]>
Date: Sun, 4 Nov 2007 11:41:03 +1000

> the chicken-and-egg problem of IKE and DSMIPv6?

=> If I understood you correctly you were saying that when IKE is run, there
is no home registration and therefore there is no home address. So I thought
you were saying that because of that reason IKE cannot run using the IPv6
home address. So my answer is that we can't run IKE over an IPv6 CoA anyway
because we don't have one. So we have to run it over the HoA, which implies
that a HoA has to be known to the MN already and not through IKE. 

Hesham

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Sun, 4 Nov 2007 18:25:54 -0800

All,
After all these iterations we've had, Alternative #2 sounds the best to
me.  However, I think the recommended mode of operation to update a
tunnel mode SA should be to use MOBIKE.  This way, the update is only
1RT and can happen in parallel with the BU/BA update.  Also, there is no
mandate to only use transport mode SA for BU/BA exchange - if a tunnel
mode SA is in use for that, the IKE SA will have to be first updated
before the BU/BA can even be exchanged from the new attachment point.
So, in all these cases, the use of MOBIKE is a better approach.  Of
course, we wouldn't need to mandate MOBIKE - when it is not supported, a
transport mode SA for BU/BA, along with a sequential IKE update or a
parallel full IKEv2 exchange can be done.  

Also, one other point to note is that the MIP6 update is only needed
when there is unprotected data exchange.  In a case where all the data
exchange is protected using IPsec, the MOBIKE update is sufficient.  The
MIP6 update can happen later when required.  So, in essence, the IKE SA
update is more time critical for protected traffic.  In reverse, the
MIP6 update is more time critical for unprotected traffic, as has
already been pointed out.  

We also need to describe the process properly so that implementations
can accept the IPsec BU/BA that are not exchanged on port 4500 (apart
from running it by the IPsec community :)). 

Regards,
Vidya

> -----Original Message-----
> From: Basavaraj Patil [mailto:[email-masked]] 
> Sent: Tuesday, October 30, 2007 9:33 PM
> To: ext Hesham Soliman; [email-masked]; [email-masked]
> Subject: [nemo] Please review and provide input to 
> DSMIP6-IKEv2 discussion
> 
> 
> 
> Hello,
> 
> I would like to encourage more people on the MIP6 and NEMO 
> lists to review the discussion related to DSMIP6 and IKEv2 
> and the issue that was raised earlier as well as the proposed 
> solutions.
> At the present time there are only a handful of people 
> commenting and it is difficult to gauge consensus as a result.
> 
> I have also requested a couple of IKE experts (Tero Kivinen 
> and Pasi Eronen) to review and provide input.
> 
> -Basavaraj
> 
> 
> > This discussion has been going on for a while and I'm sure 
> it wasn't 
> > for easy to follow.
> > comment/concensus. Please respond promptly because there is some 
> > pressure from 3GPP to get this draft out very soon.
> > 
> > There are three types of solutions that we discussed. A 
> quick summary 
> > of each below:
> > 
> > 1. The Virtual link approach. In this case IKE runs over v6 
> only and 
> > is completely unaware of the IPv4 network. As a result IKE's NAT 
> > traversal is never invoked. Only DSMIPv6's NAT traversal is 
> used. In 
> > this approach, the
> > DSMIPv6 implementation in the HA is required to cache the 
> outer IPv4 
> > address and source port of the IPv4 message that contains IKE, then 
> > append them to the response from its own IKE daemon. This 
> is basically 
> > done to hide the
> > Christian) are against it. So there doesn't seem to be concensus on 
> > this. I believe the concern here was that the HA's caching of the 
> > outer address and port was complex for the implementation.
> > 
> > 2. Karen suggested a way of running IKE without any changes 
> (again see 
> > the thread for details). In this approach DSMIPv6 BUs are 
> secured with 
> > ESP as usual. Normal traffic is sent over the DSMIPv6 port. 
> However, 
> > secure traffic is sent over the IKE port (4500). The result of this 
> > approach is that it takes two messages to complete a handover, one 
> > from DSMIPv6 (BU) and an update from IKE (for the secure 
> traffic). The 
> > concern that I had here in the discussion with Karen was 
> the number of 
> > messages and the delays associated for that. Of course IKE 
> doesn't do 
> > movement detection ...etc. So my concern is the discriminatory 
> > experience of the handover for different parts of the traffic.
> > 
> > messages) or IKE or both. I'm only including this for 
> completeness, no 
> > one really wants this.
> > 
> > Please send your comments on the above. Basically the 
> options are 1 or 
> > 2. In theory we could do both but I think it's best to pick 
> one method 
> > for this to avoid interoperability issues and additional complexity.
> > 
> > Hesham
> > 
> > 
> > 
> >

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 05 Nov 2007 11:02:10 -0800

> assume IKE to handle NAT.

You would not be able to bootstrap the home address using IKEv2 with 
solution 1.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 05 Nov 2007 11:06:11 -0800

Narayanan, Vidya wrote:
> me.  

Ok.

> However, I think the recommended mode of operation to update a
> tunnel mode SA should be to use MOBIKE.  

Disagree. If there is no NAT, the tunnel mode SAs can be updated
based on just the BU/BAck exchange.

> This way, the update is only

There is no issue at all with a transport mode SA based on the IPv6
home address for protecting the BU. So why would we want to send it
using a tunnel mode SA?

> already been pointed out. 

You should write this up in a separate draft as an alternative. :)

> from running it by the IPsec community :)).

Yes, we should add text on this.

Vijay

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 6 Nov 2007 17:00:19 -0800

> > However, I think the recommended mode of operation to 
> update a tunnel 
> > mode SA should be to use MOBIKE.
> 
> Disagree. If there is no NAT, the tunnel mode SAs can be 
> updated based on just the BU/BAck exchange.
> 

Yes, but, the case under discussion here is the case when there is a NAT
and in that case, the IKE_SA update is important for protected traffic.

> > 1RT and can happen in parallel with the BU/BA update.  
> Also, there is 
> > no mandate to only use transport mode SA for BU/BA exchange - if a 
> > tunnel mode SA is in use for that, the IKE SA will have to be first 
> > updated before the BU/BA can even be exchanged from the new 
> attachment point.
> 
> There is no issue at all with a transport mode SA based on 
> the IPv6 home address for protecting the BU. So why would we 
> want to send it using a tunnel mode SA?
> 

I'm not talking theory here.  The spec does not mandate a transport mode
SA for BU/BA exchange.  Hence, we do need to understand what happens
when tunnel mode is used.  And, tunnel mode can be used if someone
wishes to protect MIP6 signaling and data, all with the same SA.  No
reason to have a separate transport mode SA for the signaling.  

> > course, we wouldn't need to mandate MOBIKE - when it is not 
> supported, 
> > a transport mode SA for BU/BA, along with a sequential IKE 
> update or a 
> > exchange is protected using IPsec, the MOBIKE update is 
> sufficient.  
> > The
> > MIP6 update can happen later when required.  So, in 
> essence, the IKE 
> > SA update is more time critical for protected traffic.  In reverse, 
> > the

Thanks for the suggestion (hint: I disagree :)).  We are not mandating
MOBIKE here - but, it would make sense to recommend it for updating
tunnel mode SAs in the presence of NATs.  So, I don't understand the
issue of not making use of something that works and is available.  You
can always not support MOBIKE in your implementation if that's what you
are concerned about. 

Vidya

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 06 Nov 2007 18:42:25 -0800

> reason to have a separate transport mode SA for the signaling.  

But the transport mode SA is not dependent on updating the IPsec
or the IKEv2 SA. The BU/BAck exchange can be completed right away
after a handover using the transport mode SA. I would not
complicate that part.

> can always not support MOBIKE in your implementation if that's what you

We need a mechanism that works without MOBIKE. Period. You are
free to write up another document that describes how MOBIKE helps
in improving the situation.

Vijay

---

From: Shinta Sugimoto <[email-masked]>
Date: Wed, 07 Nov 2007 14:21:21 +0900

Hello Hesham,

Sorry for the delay in my response. Please find my comments inline.

Hesham Soliman wrote:
> is no home registration and therefore there is no home address.

Yes, you are right.

> So I thought
> home address.

Partially correct.  There are two different use of IP address that
we should look at:  A) IKE endpoint and B) IPsec SA endpoint address.
(Note that I am giving an example of establishing ESP transport mode
SA pair)  Under the scenario of solution 1, as for A), there is no
possibility of using home address since it is not routable.  The only
possible option for A) is to choose a working IP address (could be
care-of address, of course) to run IKE.  On the other hand, as for B),
the home address of the mobile node may be specified, even though
the home address is not available yet.

I examined feasibility of solution 1 and came to the following
conclusion.  In my understanding, the solution 1 should work
(on MN) as below:

(1) MN bootstraps. Neither home address assignment nor IPsec SA
establishment is done yet.
(2) IKEv2 is triggered somehow.
(3) IKE_AUTH message exhcnage is made in which home address
assignment is done by configuration payload.
(4) IPsec SA (ESP transport mode) is established.
(5) MIPv6 module sends the initial BU to the HA which is protected
by the
(6) IKE module updates the IKE endpoint with the home address

subsequently, IKE runs on top of MIPv6, hence there is no need
for updating the IKE endpoint nor IPsec SA endpoint addresses.
IPsec SA for protecting user traffic (ESP in tunnel mode) may
be established, if necessary.

So, I don't think that there is no significant limitation in
solution 1.  Home address assignment can be done through IKEv2
as usual.

The only prerequisite is that IKE runs without any help from
MIPv6 at the beginning, and then migrate its endpoint (IKE
endpoint) to the home address.

Does this make sense?

> So my answer is that we can't run IKE over an IPv6 CoA anyway
> because we don't have one.

In your statement above, which kind of address A) or B) are you
talking about?

> So we have to run it over the HoA, which implies

I hope my explanation above replies to your comments.

Regards,
Shinta

---

From: Shinta Sugimoto <[email-masked]>
Date: Wed, 07 Nov 2007 14:37:31 +0900

Hi Vijay,

> You would not be able to bootstrap the home address using IKEv2 with 

I am afraid the above is not true.  Could you check my
reponse to Hesham, and hear me if you can agree?

Regards,
Shinta

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 06 Nov 2007 22:20:29 -0800

> assignment is done by configuration payload.

This is not possible. The way I understand solution 1, IKEv2 is
run on top of the DS-MIPv6 tunnel using the home address of the
mobile node as the IKEv2 end point. The resulting IKEv2 SA is
based on the home address of the mobile node. Forget the IPsec
SA. I don't see how you can request for the home address and at
the same time base the IKEv2 SA on the home address.

In regular MIPv6, the IKEv2 SA is always based on the care-of
address of the mobile node.

Or did I got solution 1 wrong?

Vijay

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 6 Nov 2007 22:34:02 -0800

> > I'm not talking theory here.  The spec does not mandate a transport 
> > mode SA for BU/BA exchange.  Hence, we do need to understand what 
> > happens when tunnel mode is used.  And, tunnel mode can be used if 
> > someone wishes to protect MIP6 signaling and data, all with 
> the same 
> > SA.  No reason to have a separate transport mode SA for the 
> signaling.
> 
> But the transport mode SA is not dependent on updating the 
> IPsec or the IKEv2 SA. The BU/BAck exchange can be completed 
> right away after a handover using the transport mode SA. I 
> would not complicate that part.
> 

Who said anything about complicating the transport mode operation?  Are
you reading things I didn't write? You asked about why someone would use
a tunnel mode SA and I was giving an example.  

> >>> parallel full IKEv2 exchange can be done.

Please re-read the above paragraph I wrote in my first email. 

<snip> 

> We need a mechanism that works without MOBIKE. Period. You 
> are free to write up another document that describes how 
> MOBIKE helps in improving the situation.

Thanks for informing me what I'm free to do!  Things work without MOBIKE
as I've said above. It is just not as efficient.   For more efficient
operation, the IKE SA update needs to be done using MOBIKE. There is no
reason for a separate document on this.  You should really get past your
now long-term hangup on using MOBIKE along with MIP6 - this is a
perfectly viable use case for it and there is absolutely no good reason
to prevent it. 

Vidya

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 06 Nov 2007 22:44:34 -0800

Narayanan, Vidya wrote:
> as I've said above. It is just not as efficient.  

You missed what I was saying. The default operation for the use
of IKEv2 with DS-MIPv6 should not assume MOBIKE functionality
being used at the same time. If you think it is efficient to do
that please do that in a separate document. Not in the DS-MIPv6
document.

For more efficient
> perfectly viable use case for it and there is absolutely no good reason

Until now the binding update was sufficient to update the IKEv2
SA. But with the presence of NAT, the BU is not sufficient.
You need to either re-run IKEv2 or use MOBIKE to update the IKEv2
SA. I agree with that.

There is also another solution I had proposed where the HA treats
the handover as if the intermediate NAT box lost state or rebooted
and allocated a new NATed IP address and source port and accepts
the traffic for a configurable amount of time while waiting for
the IKEv2 SA to be re-keyed. This solution was proposed for the
IPsec tunneled payload traffic.

Vijay

---

From: Shinta Sugimoto <[email-masked]>
Date: Wed, 07 Nov 2007 15:49:32 +0900

Vijay Devarapalli wrote:

> This is not possible.

I believe it is possible, but I do agree that such operation
is not normal at present.

> The way I understand solution 1, IKEv2 is
> mobile node as the IKEv2 end point.

Yes. That's correct.

> The resulting IKEv2 SA is
> SA.

Sorry, what do you mean by "Forget the IPsec SA."?

> I don't see how you can request for the home address and at

As I wrote above, it can be done by using different IP address
for IKE endpoint and IPsec SA endpoint address in the initial
IKE negotiation.  Could you explain why you think it is impossible?
Do you see any violation of specification of IPsec/IKE?
Or is there any flaw?

> address of the mobile node.

You mean IKE SA, right?  Then, yes, the IKE SA endpoint on the
side of mobile node is normally the care-of address.

In solution 1, both IKE SA and IPsec SA endpoint address are
home address.  Exceptionally, IKE chooses different IP address
than home address for IKE SA endpoint in the bootstrap stage.
That's how I see it.

Regards,
Shinta

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 06 Nov 2007 23:31:56 -0800

> than home address for IKE SA endpoint in the bootstrap stage.

What is this different IP address?

Vijay

---

From: Shinta Sugimoto <[email-masked]>
Date: Wed, 07 Nov 2007 18:39:24 +0900

> What is this different IP address?

Any IP address (globally-scoped unicast IP address) that can
be used for transporting IKE messages to the peer.  The address
cannot be home address since home address is not available yet.
Normally, the IP address would be the care-of address.

Regards,
Shinta

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 07 Nov 2007 08:27:30 -0800

> Normally, the IP address would be the care-of address.

In this case, there is only an IPv4 CoA available to the mobile
node. I am not sure from which prefix the mobile node would
configure this temporary IPv6 address.

This would result in a 2 stage approach where the mobile node
would first use the temporary IPv6 address to run IKEv2 and
acquire a home address. The mobile node would then run IKEv2
again to use home address as the source address of the IKEv2
exchange and create a new IKEv2 SA based on the home address.

Vijay

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 7 Nov 2007 10:28:18 -0800

> > Thanks for informing me what I'm free to do!  Things work without 
> > MOBIKE as I've said above. It is just not as efficient.
> 
> You missed what I was saying. The default operation for the 
> use of IKEv2 with DS-MIPv6 should not assume MOBIKE 
> functionality being used at the same time. If you think it is 
> efficient to do that please do that in a separate document. 
> Not in the DS-MIPv6 document.
> 

I think I have made it sufficiently clear that this does not require a
separate document.  All that needs to be written is 2 lines for saying
that the IKE SA can be udpated using MOBIKE, in parallel with the BU/BA
exchange, when a tunnel mode SA is used.  It is ridiculous to require a
separate document for this.  This is not preventing whatever else you
want to do either.  So, the objection makes no sense to me. 

Vidya

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 07 Nov 2007 10:34:40 -0800

> want to do either.  So, the objection makes no sense to me. 

It does not make sense to me because we can avoid updating the
IKEv2 SA in the middle of a handover. If the IKEv2 SA is being
updated after the handover, it does not matter if MOBIKE or a
CREATE_CHILD_SA exchange is used.

MOBIKE comes with its own baggage.

BTW, you need to convince the WG to make the change. Not ask
why I am objecting. :)

Vijay

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 9 Nov 2007 14:32:50 -0800

> IKEv2 SA in the middle of a handover. If the IKEv2 SA is 
> being updated after the handover, it does not matter if 
> MOBIKE or a CREATE_CHILD_SA exchange is used.
> 

You seem to keep going back to losing focus on the problem under
discussion.  We are talking about the case where the IKE SA update must
happen at the time of handover, due to the SA being a tunnel mode one
and due to NATs being present.  That is the environment in which MOBIKE
brings advantages and, before we forget again, it would be an *optional*
mechanism to use.  It is not helping to say that in other cases, it is
not needed, because that's just using an irrelevant point to lose focus
on the relevant one.  To remove any ambiguity in what I'm saying, it is
not even a point of debate that it is not needed in other cases, because
no one is saying it is. 

> MOBIKE comes with its own baggage.

You have made this claim many times without qualifying it.  It is time
to either qualify it or drop it. 

> BTW, you need to convince the WG to make the change. Not ask 

I don't see anyone else objecting (or saying anything for that matter)
on this topic. 

Vidya

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 09 Nov 2007 15:06:35 -0800

Narayanan, Vidya wrote:
> and due to NATs being present.  

I had proposed a solution for the tunnel mode too.
http://www1.ietf.org/mail-archive/web/mip6/current/msg06910.html

Did you miss the email or just dismiss it? The solution in the mail
at the above URL was the basis for what I wrote in the previous email.

> That is the environment in which MOBIKE

For example, movement detection and two round trips for the
MOBIKE update.

> I don't see anyone else objecting (or saying anything for that matter)

Nobody is supporting it.

Vijay

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 9 Nov 2007 17:39:08 -0800

> Did you miss the email or just dismiss it? The solution in 
> the mail at the above URL was the basis for what I wrote in 
> the previous email.
> 

Ok, this discussion is tiring and unproductive and this will be my last
email on this topic.  For the last time, I was NOT proposing MOBIKE to
be the *only* mechanism for this scenario - all I was saying was that it
doesn't involve tentative binding cache entries or sequential roundtrips
and hence, needs to be permitted and documented as such as an *option*.
We haven't been discussing your other email, since I never objected to
allowing a non-MOBIKE approach for the problem also. 

> For example, movement detection and two round trips for the 

We already said that two roundtrips are unavoidable for updating a
tunnel mode SA in the presence of NATs.  With MOBIKE, the updates are
happening in parallel and hence, there isn't a latency impact.  With
sequential updates required for handover, there is a latency impact and
with the solution you proposed, there is a window of time where the
insecure binding cache updates need to be accepted.  With MOBIKE,
neither of these drawbacks apply.  So, I don't understand the logic
where we deliberately disallow a no-drawback solution and only propose
to use the ones with drawbacks. 

> >> BTW, you need to convince the WG to make the change. Not 
> ask why I am 
> >> objecting. :)
> >>
> > 

Not the point, since you said the WG needs convincing; nobody is asking
to be convinced and you are the only one objecting it.  

Vidya

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 9 Nov 2007 14:32:50 -0800

Vidya

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 09 Nov 2007 15:06:35 -0800

Nobody is supporting it.

Vijay

---

From: "Hesham Soliman" <[email-masked]>
Date: Sun, 11 Nov 2007 20:45:53 +1000

Vidya, (cleaned up the cc list and moved to mext)

Let me know if I understand what you're asking for correctly. 
Effectively you're saying that if we follow something like alternative 2,
which allows IPsec tunnel mode over port 4500 for normal traffic, then we
should be able to use MOBIKE to update that SA. Is my understanding correct?

I believe there are two ways of updating the IKE SA in the presence of NATs,
one is the "implicit mode" where IKE in the HA just sees that the
addresses/ports have changed and it updates the SA accordingly. The other is
obviously the explicit MOBIKE. 
So if I understand this correctly you're saying that we don't need to say
"MOBIKE MUST be used", you're saying it should be possible to use MOBIKE. Is
this a correct understanding? 

If I understood you correctly then I don't see how we can stop people from
using MOBIKE. But of course if you want to mandate MOBIKE then it's a
different discussion. Let me know if I got it right. 

Hesham 

 > From: Narayanan, Vidya [mailto:[email-masked]] 
 > Sent: Saturday, November 10, 2007 11:39 AM
 > To: Vijay Devarapalli
 > Cc: Basavaraj Patil; ext Hesham Soliman; [email-masked]; [email-masked]
 > Subject: RE: [Mip6] RE: [nemo] Please review and provide 
 > input to DSMIP6-IKEv2discussion
 > 
 > > 

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

---

From: <[email-masked]>
Date: Mon, 12 Nov 2007 10:59:06 +0100

Hi,

> I don't see anyone else objecting (or saying anything for that matter)

I don't see any technical reasons for us not considering optional usage
of MOBIKE for
this situation. MOBIKE do implement what is requried. It does however
require us to describe exactly
how to communicate optional usage of MOBIKE. The usage of MOBIKE must be
OPTIONAL,
in my opinion, as we have ways to do this without requirering MOBIKE
support in the implementations.

But a question that comes to mind then, though, is whether it really
make sense to use MOBIKE when
moving in Ipv4 foreign networks (with or without NAT - ?) but standard
MIP-IKE interactions for DSMIP
in IPV6 foreign networks as well as for standard MIPv6.

BR, Karen

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 12 Nov 2007 10:43:16 -0800

> and hence, needs to be permitted and documented as such as an *option*.

Ok. But I am still objecting to specifying the use of MOBIKE as one
of the solutions in the DS-MIPv6 document. There are multiple reason.
It may require two round trips during the handover. And You will
have two mobility management protocols running at the same time.

I do agree with Hesham that we can't really prevent if someone wants
to use MOBIKE at the same time.

I suggest a separate document on this if you still want MOBIKE to be
an alternative.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 12 Nov 2007 10:45:12 -0800

> in IPV6 foreign networks as well as for standard MIPv6.

IMO, it does not. If you are using MOBIKE to update the IKEv2 SA
(and the tunnel IPsec SAs) after a handover, you might as well use
it all the time, even when the mobile node is attached to IPv6
access networks. :)

Vijay

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 12 Nov 2007 19:55:22 +0100

> Narayanan, Vidya wrote:
...
> I suggest a separate document on this if you still want MOBIKE to be

I agree with Vijay's viewpoints above.

	Henrik

---

From: "T.J. Kniveton" <[email-masked]>
Date: Mon, 12 Nov 2007 15:25:02 -0800

> I agree with Vijay's viewpoints above.
Same here. The potential reduction in latency for updates when 
traversing a NAT doesn't seem like a good tradeoff for the additional 
complexity of running two mobility management protocols.

TJ

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 12 Nov 2007 17:33:12 -0800

Hi Hesham,
Yes, your observations are correct.  It's not a question of stopping
someone from using MOBIKE - I was more saying that the document should
record that it is an option and have some notes on how that can be done.
I see that a few of the people are opting for not including that, but,
IMHO, that would be wrong.  I haven't seen any good technical reasons
why that is complex (as seems to be what is being hinted) other than the
philosophy of using two mobility management protocols.  We are not in a
competition here between MOBIKE and MIP6 - the goal is to try and use
the best technical solution. 

Thanks,
Vidya 

> From: Hesham Soliman [mailto:[email-masked]] 
> Sent: Sunday, November 11, 2007 2:46 AM
> To: Narayanan, Vidya
> Cc: [email-masked]
> Effectively you're saying that if we follow something like 
> alternative 2, which allows IPsec tunnel mode over port 4500 
> for normal traffic, then we should be able to use MOBIKE to 
> update that SA. Is my understanding correct?
> 
> 
> I believe there are two ways of updating the IKE SA in the 
> presence of NATs, one is the "implicit mode" where IKE in the 
> HA just sees that the addresses/ports have changed and it 
> updates the SA accordingly. The other is obviously the 
> explicit MOBIKE. 
> So if I understand this correctly you're saying that we don't 
> need to say "MOBIKE MUST be used", you're saying it should be 
> possible to use MOBIKE. Is this a correct understanding? 
> 
> If I understood you correctly then I don't see how we can 
> stop people from using MOBIKE. But of course if you want to 
> mandate MOBIKE then it's a different discussion. Let me know 
> if I got it right. 
> 
> Hesham 
> 
>  > From: Narayanan, Vidya [mailto:[email-masked]]  > 
> Sent: Saturday, November 10, 2007 11:39 AM  > To: Vijay 
> Devarapalli  > Cc: Basavaraj Patil; ext Hesham Soliman; 
> [email-masked]; [email-masked]  > Subject: RE: [Mip6] RE: 
> [nemo] Please review and provide  > input to 
> DSMIP6-IKEv2discussion  >  > >  > > I had proposed a solution 
> for the tunnel mode too.
>  > > Did you miss the email or just dismiss it? The solution 
> in  > > the mail at the above URL was the basis for what I 
> wrote in  > > the previous email.
>  > >
>  >
>  > Ok, this discussion is tiring and unproductive and this 
> will  > be my last  > email on this topic.  For the last 
> time, I was NOT proposing  > MOBIKE to  > be the *only* 
> mechanism for this scenario - all I was saying  > was that it 
>  > doesn't involve tentative binding cache entries or  > 
> sequential roundtrips  > and hence, needs to be permitted and 
> documented as such as  > an *option*.
>  > We haven't been discussing your other email, since I never 
>  > objected to  > allowing a non-MOBIKE approach for the 
> problem also. 
>  >
>  > >
>  > > For example, movement detection and two round trips for 
> the  > > MOBIKE update.
>  > >
>  >
>  > We already said that two roundtrips are unavoidable for 
> updating a  > tunnel mode SA in the presence of NATs.  With 
> MOBIKE, the updates are  > happening in parallel and hence, 
> there isn't a latency impact.  With  > sequential updates 
> required for handover, there is a latency  > impact and  > 
> with the solution you proposed, there is a window of time 
> where the  > insecure binding cache updates need to be 
> accepted.  With MOBIKE,  > neither of these drawbacks apply.  
> So, I don't understand the logic  > where we deliberately 
> disallow a no-drawback solution and  > only propose  > to use 
> the ones with drawbacks. 
>  >
>  > > >> BTW, you need to convince the WG to make the change. 
> Not  > > ask why I am  > > >> objecting. :)  > > >>  > > >  > 
> > > I don't see anyone else objecting (or saying anything for 
>  > > that matter)  > > > on this topic.
>  > >
>  > > Nobody is supporting it.
>  > >
>  >
>  > Not the point, since you said the WG needs convincing;  > 
> nobody is asking  > to be convinced and you are the only one 
> objecting it.  
>  >
>  > Vidya
>  > 
> 
>

---

From: "Hesham Soliman" <[email-masked]>
Date: Tue, 13 Nov 2007 12:38:38 +1000

I agree of course the MOBIKE is one of the solutions for this. I don't have
a problem mentioning that in the draft but let's see the balance of opinions
on this. I hope everyone provides technical reasons regardless of which way
they prefer. 

Hesham

 > Sent: Tuesday, November 13, 2007 11:33 AM
 > To: Hesham Soliman
 > Cc: [email-masked]

---

From: <[email-masked]>
Date: Tue, 13 Nov 2007 09:46:23 +0100

> complexity of running two mobility management protocols.

Doing this in a separate document sounds like the best approach.
Especially so,
given that the potential usage of MOBIKE is not particular to DSMIP
(read also relevant for MIPv6).

Karen

---

From: Basavaraj Patil <[email-masked]>
Date: Tue, 13 Nov 2007 15:06:00 -0600

I agree that the MIP6/DS-MIP6 protocol need not have a normative dependency
on Mobike. I agree that it is one way of solving the issue but there are
other solutions proposed as well that do not rely on Mobike.
Requiring Mobike capability for MIP/DS-MIP6 is not essential.

-Raj

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 13 Nov 2007 15:52:41 -0800

I don't understand why an optional feature would introduce a normative
dependency.  Also, I'm not understanding the rationale behind keeping
this out of the DSMIP6 spec - MOBIKE is a fully specified solution and
all we need is a description of how it works with DSMIP6 (much like what
we would write for regular IKEv2, probably even less), especially when
that is technically the most optimal solution for this particular
scenario being discussed.  

I'm not talking about replacing MIP6 mobility management with MOBIKE
mobility management for all cases - I'm only talking about handling IPv4
tunnel mode NAT-T with MOBIKE.  The two solutions that are being
proposed for this case in the base spec are both sub-optimal and we have
an optimal solution fully baked and available.  I'm puzzled by the
conclusion that is being reached at here. 

Vidya

> Sent: Tuesday, November 13, 2007 1:06 PM
> To: Levkowetz; Vijay Devarapalli
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Mip6] RE: [nemo] Please review and provide 
> input toDSMIP6-IKEv2discussion
> 
> 
> I agree that the MIP6/DS-MIP6 protocol need not have a 
> normative dependency on Mobike. I agree that it is one way of 
> solving the issue but there are other solutions proposed as 
> well that do not rely on Mobike.
> will be my 
> >>> last email on this topic.  For the last time, I was NOT proposing 
> >>> MOBIKE to be the *only* mechanism for this scenario - all I was 
> >>> saying was that it doesn't involve tentative binding 
> cache entries 
> >>> or sequential roundtrips and hence, needs to be permitted 
> and documented as such as an *option*.
> >> 
> >> It may require two round trips during the handover. And 
> You will have 
> >> two mobility management protocols running at the same time.
> >>

---

From: Basavaraj Patil <[email-masked]>
Date: Tue, 13 Nov 2007 23:51:16 -0600

Hi Vidya,

The scope of the current discussion is of course limited to the usage of
IKEv2 in the presence of NATs when the MN moves to a v4 network.

What you are suggesting is that the issue can be solved if the MN has Mobike
capability. This IMO makes it normative.
However I have no problems if this is mentioned as an option for hosts which
have Mobike capability.
A DS-MIP6 host however does not need Mobike capability. To solve the IKEv2
issue, we need a solution that may be suboptimal (as you say).

The few opinions that have been expressed indicate a preference for having
usage of Mobike in the context of MIP6 specified in a separate I-D. I have
not seen any support for using Mobike to solve the current problem even
though it has been acknowledged that it is "a" solution.

Hence I would recommend that the WG focus on specifying a non-Mobike
solution to address the issue.

-Raj

---

From: "George Tsirtsis" <[email-masked]>
Date: Wed, 14 Nov 2007 09:42:16 +0100

Hi Raj et.al.,,

My understanding is that we already have two solutions (sub-optimal
and optimal) that do not require changes to IKEv2 and/or MOBIKE.

The "sub-optimal" solution is what Hesham called solution 2 in an
earlier thread: i.e.,
 "Karen suggested a way of running IKE without any changes (again see
the thread for details). In this approach DSMIPv6 BUs are secured with
ESP as usual. Normal traffic is sent over the DSMIPv6 port. However,
secure traffic is sent over the IKE port (4500)." The sub-optimality
comes from the fact that the solution causes additional delay to
cyphered traffic.

We also have an optimal solution which is the same as the above except
that MOBIKE is also used so that the additional delay for cyphered
traffic is removed.

Why don't we document both. The first being mandatory and the second optional?

Thanks
George

---

From: "Hesham Soliman" <[email-masked]>
Date: Wed, 14 Nov 2007 19:55:14 +1000

George,

I don't know if this is an accurate categorisation but from my
understanding, this is what we have:

Solution 1, which is suboptimal from an implementation point of view
Solution 2, which is suboptimal because of the reasons you mentioned below
and I mentioned earlier.  
Solution Mobike, which is also suboptimal compared to 1 (in terms of
messages) but more optimal compared to solution 2, which essentially needs
IKE to re-establish the SA unless IKE dynamic updates are supported and we
hope they are!

So yes Mobike is faster than 2 (assuming IKE dynamic updates are not used) I
think but not optimal.

Hesham

 > From: George Tsirtsis [mailto:[email-masked]] 
 > Sent: Wednesday, November 14, 2007 6:42 PM
 > To: Basavaraj Patil
 > Cc: [email-masked]; [email-masked]; Levkowetz
 > inputtoDSMIP6-IKEv2discussion
 > 
 > Hi Raj et.al.,,
 >

---

From: "George Tsirtsis" <[email-masked]>
Date: Wed, 14 Nov 2007 10:01:50 +0100

OK, lets not get stack on the definition of the word "optimal" :-)

My proposal is to make "Solution 2" mandatory, since it is fully
implementable using just IKEv2 and DSMIPv6 and "Solution Mobike"
optional, since it results in better performance than "Solution 1" but
requires MOBIKE support in HA and MN..

George

---

From: "Hesham Soliman" <[email-masked]>
Date: Wed, 14 Nov 2007 20:29:35 +1000

> OK, lets not get stack on the definition of the word "optimal" :-)

=> ok :)

 > requires MOBIKE support in HA and MN..

=> It doesn't perform better than 1, it performs better than 2 if there is
no support for dynamic updates. I.e. if the IKE daemon on the HA doesn't
support dynamic updates solution 2 would need to re-run IKE to setup a new
SA. But if dynamic updates are supported then both perform the same way
AFAICS. 

I don't have a problem with mentioning Mobike as an option but several
people seem to be against it. Frankly, I don't know why it's so bad to
mention it as an option.

Hesham

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 14 Nov 2007 10:42:54 +0100

Hi Hesham,

> people seem to be against it. Frankly, I don't know why it's so bad to

'Mentioning it as an option' sounds like something like a 1-sentence update.
That's fine with me.

'Documenting it' (as has been said) sounds like a whole new section.  I'm
opposed to adding that to this document.

	Henrik

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 14 Nov 2007 07:49:23 -0600

Hesham,

I am okay with Mobike being mentioned as an optional solution for MNs that
have such capability and an HA supporting it as well in the I-D. However
without providing more details on the behavior of the MN and HA w.r.t when
Mobike is used, I think it would be less than useful.

-Raj

---

From: "Hesham Soliman" <[email-masked]>
Date: Thu, 15 Nov 2007 00:56:35 +1000

Ok, I think there is agreement on mentioning this without extensive
documentation.
I'll add it to the next rev. 

Hesham 

 > Sent: Wednesday, November 14, 2007 11:49 PM
 > To: ext Hesham Soliman; 'George Tsirtsis'

---

From: "George Tsirtsis" <[email-masked]>
Date: Wed, 14 Nov 2007 15:19:09 +0100

I am now a bit concerned with what it means to "mention MOBIKE without
extensive documentation".

I think the documentation should be enough to allow the implementor to
understand how MOBIKE can be used as an alternative to Solution 2.
Since no change to MOBIKE is required for this, however, I expect the
description to be relatively brief and easy.

In any case I trust Hesham to apply common sense in this case :-)

Regards
George

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 14 Nov 2007 09:53:46 -0800

> comes from the fact that the solution causes additional delay to

We can avoid the delay for cyphered traffic. See
http://www1.ietf.org/mail-archive/web/mip6/current/msg06910.html
and follow the thread.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 14 Nov 2007 09:55:52 -0800

Hesham Soliman wrote
> people seem to be against it. Frankly, I don't know why it's so bad to

Because just mentioning it is not sufficient. You need to explain how
it will work, especially the MOBIKE's and MIP6's movement detection
algorithms.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 14 Nov 2007 10:01:06 -0800

> I'll add it to the next rev.

What is "extensive documentation"? Are you going to add a sentence
that says "Note that MOBIKE may be used to update the IKEv2 SA and
IPsec tunnel SAs after a handover".?

I believe this is not sufficient for someone to get MOBIKE working
with DS-MIPv6. So what is the purpose, just to recognize that there
might other ways of updating the IKEv2 SAs and IPsec tunnel SAs or
pointing to a viable alternative?

Vijay