Subject: [MEXT] RE: [Mip6] RE: [nemo] Please review and provide input to DSMIP6-IKEv2discussion

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 

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

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

---

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*.
>  > 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. :)  > > >>  > > >  > 
>  > > 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]