Subject: [MEXT] IPsec for MIPv6

From: "Alper Yegin" <[email-masked]>
Date: Fri, 21 Nov 2008 16:03:04 +0200

I was really puzzled about the pushback on Charlie's presentation.

Comments supporting sufficiency of IPsec for MIP6 seemed to ignore the facts
that:

-          RFC 4285 existed

-          SDOs adopted it

-          Vendors implemented it

How can anyone say IPsec is the best solution for MIP6 security and industry
does not need anything else. 

Alper

 

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

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 21 Nov 2008 08:30:28 -0800

Hi Alper,

IPsec exists.
3775 Requires it.
Vendors implemented it.

:)

So, just like the presentation, that line of argument really is 
unconvincing.

In the meanwhile 4285 has an IESG note at the beginning that says, the 
following is a bogus protocol, please don't use it.  The first step may 
be to make 4285 standards track and we can have this discussion.

While doing so, it might be worthwhile to think about what I wrote 
earlier about interoperability and interworking with two different key 
management and encapsulation protocols.

thanks,
Lakshminath

On 11/21/2008 6:03 AM, Alper Yegin wrote:
> I was really puzzled about the pushback on Charlie’s presentation.
> 
>  
> 
> Comments supporting sufficiency of IPsec for MIP6 seemed to ignore the 
> facts that:
> 
> -          RFC 4285 existed
> 
> -          SDOs adopted it
> 
> -          Vendors implemented it
> 
>  
> 
> How can anyone say IPsec is the best solution for MIP6 security and 
> industry does not need anything else…
> 
>  
> 
> Alper
> 
>  
> 
>  
> 
>  
> 
>  
> 
> 
> ------------------------------------------------------------------------
>

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 21 Nov 2008 18:50:50 +0200

Hi Lakshminath,

> Vendors implemented it.

Indeed. Nobody disputed that. Maybe you misunderstood yesterday's discussion, it was not about eradicating IPsec from the world.

> following is a bogus protocol, please don't use it.  

:) it does not say that. You are misreading it, to say the least. 

If you want to RFC to say that, or to eradicate that RFC, then you need to write an I-D "RFC 4285 considered harmful" and get IETF to publish it. Only after than it makes sense for people to ignore RFC 4285.

Alper

> The first step may

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 21 Nov 2008 09:08:45 -0800

Hi Alper,

For what it's worth we don't have such a process specified anywhere. 
4285 is informational and has the following status*. If we are to say 
that it has equivalent status, there needs to be an intermediate step to 
make it standards track. That's our process.

* 2026:

An "Informational" specification is published for the general
   information of the Internet community, and does not represent an
   Internet community consensus or recommendation.

So, really we have a few intermediate options to get there from here:
1 Begin publication process of 4285 contents in standards track.
2 change 2026's definition of "Informational"

You may have an easier time with the first option :).

best,
Lakshminath
>>> I was really puzzled about the pushback on Charlieâ��s presentation.
>>>
>>>
>>>
>>> Comments supporting sufficiency of IPsec for MIP6 seemed to ignore
>>>       
>> the
>>     
>>> facts that:
>>>
>>> -          RFC 4285 existed
>>>
>>> -          SDOs adopted it
>>>
>>> -          Vendors implemented it
>>>
>>>
>>>
>>> industry does not need anything elseâ�Š
>>>
>>>
>>>
>>> Alper
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>>       
>> ---
>>

---

From: Basavaraj Patil <[email-masked]>
Date: Sat, 22 Nov 2008 13:45:11 -0600

Vendors might be a bit of a stretch here. If you can name any
other vendor other than yourself, I would believe the plurality.
Of course there is the open source UMIP implementation. I hope you
are not including that in your statement.
But in terms of vendors, please indicate who else besides your
company has an implementation.

The other point is that IPsec exists. But IPsec use today
beyond VPN connectivity for hosts to enterprises is the only thing.
And IPsec is not a component in every host that has an IP stack today.

3775 is headed towards becoming a protocol of academic interest only
if we do not correct course and build stuff that people would actually
want to implement and use.

-Raj

>> I was really puzzled about the pushback on Charlie¹s presentation.
>> 
>>  
>> 
>> industry does not need anything elseŠ
>> 
>>  
>> 
>> Alper
>>

---

From: Lakshminath Dondeti <[email-masked]>
Date: Sat, 22 Nov 2008 17:11:50 -0800

> want to implement and use.

Hi Raj,

There are always people who want to advocate for a little bit of 
security; we only have to look at WEP, WPA advocates, implementers and 
users for recent proof.  Each time, similar arguments as you use above 
were used to standardize those.  Perhaps we need to educate and convince 
product managers as to what is the right thing to do, rather than taking 
the route of WEP and WPA, yet again.

best,
Lakshminath

>>> industry does not need anything else�
>>>
>>>  
>>>
>>> Alper
>>>
> 
> 
>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Sat, 22 Nov 2008 21:45:42 -0800

Hello Lakshminath,

Nowhere in the presentation was it stated that we were
promoting a scheme with reduced security.  Our emphasis
remains on enabling alternative security mechanisms to
be used when appropriate.

Regards,
Charlie P.

Lakshminath Dondeti wrote:
> were used to standardize those.  Perhaps we need to educate and 
> convince product managers as to what is the right thing to do, rather 
> than taking the route of WEP and WPA, yet again.
>

---

From: Lakshminath Dondeti <[email-masked]>
Date: Sun, 23 Nov 2008 00:34:50 -0800

Hi Charlie,

Many thanks for the clarification.  I presume then that you do not 
support 4285 as the alternative mechanism.

regards,
Lakshminath

---

From: "Alper Yegin" <[email-masked]>
Date: Sun, 23 Nov 2008 15:36:23 +0200

Lakshminath,

Nowhere in my discussions I said informational RFCs have the same status as standard RFCs, or RFC 4285 shall be upgraded to standards track. If these were your concerns, then don't worry.

Alper

> -----Original Message-----
> From: Lakshminath Dondeti [mailto:[email-masked]]
> Sent: Friday, November 21, 2008 7:09 PM
> To: Alper Yegin
> Cc: [email-masked]
> Subject: Re: [MEXT] IPsec for MIPv6
> 
> 
> 
> > Indeed. Nobody disputed that. Maybe you misunderstood yesterday's
> discussion, it was not about eradicating IPsec from the world.
> >
> >
> >> :)
> >>
> > If you want to RFC to say that, or to eradicate that RFC, then you
> need to write an I-D "RFC 4285 considered harmful" and get IETF to
> publish it. Only after than it makes sense for people to ignore RFC
> 4285.
> >
> Hi Alper,
>

---

From: "QIU Ying" <[email-masked]>
Date: Tue, 25 Nov 2008 18:56:49 +0800

Hi,

I support to reconsider the use of IPSec in MIP6. Current RFC3775 uses ESP 
to protect the mobility signaling messages between MN and HA. Hence all of 
mobility flags in mobility signaling are invisible by ESP encapsulation.

Since the mobility signaling messages are not so sensitive, it would not 
necessary to use ESP to encrypt these messages. Perhaps, it is satisfaction 
to just use IPSec AH mode to authenticate these signalings.

In my opinion, the reason that MIP6 has been not widely employed currently 
is due to IPv6, not the overhead of IKE/IPSec. So far, who has heard a lot 
of the complaints on SSL overhead from the mobile users? :-)

By the way, the overhead of establishing the security association would be 
ignored thanks to the quickly improvement of performance of mobile devices. 
For example, the performance of current mobile phones is already similar to 
the notebooks in 2000. Below is a simple comparison between ThinkPad X20, a 
popular notebook in 2000, and iPAQ900, a latest mobile phone:

CPU: Intel Celeron 500Mhz  vs.  Intel PXA270 412MHz
Memory: 64 MB  vs.  128MB SDRAM
Harddisk: 10GB  vs  16GB SD card
Connection: 10Mbps Ethernet  vs  7.2 Mbps HSDPA

I do not think WEP/WPA solutions would be suitable for MIP6 environments, 
because:
1) The connective range is much different: 300m LAN (WiFi) vs. global (MIP6)
2) The requested security strength is different: As roaming in global, MIP6 
would not accept the concept of broadcasting the GTK (group temporal key).
3) In most cases, especially for accounting purpose, the HA needs to 
authenticate the mobile users' IDs. WEP/WPA omits the users' IDs
4) A flaw has been uncovered in the latest version of WAP2.

Regards
Qiu Ying

----- Original Message ----- 
From: "Charles E. Perkins" <[email-masked]>
To: "Lakshminath Dondeti" <[email-masked]>
Cc: <[email-masked]>; "Basavaraj Patil" <[email-masked]>
Sent: Sunday, November 23, 2008 1:45 PM
Subject: Re: [MEXT] IPsec for MIPv6

>> the route of WEP and WPA, yet again.

**********************  ANNOUNCEMENT ********************************
 We have moved to Fusionopolis!
 Our official address is:
 Institute for Infocomm Research,  1 Fusionopolis Way,  #21-01 Connexis, South Tower,
 Singapore 138632.   Main line: +65 64082000. Main fax: +65 67761378
 Please visit http://www.fusionopolis.a-star.edu.sg/ for more information
 on Fusionopolis.
******************************************************************

Institute For Infocomm Research - Disclaimer This email is confidential and may be privileged.  If you are not the intended recipient, please delete it and notify us immediately. Please do not copy or use it for any purpose, or disclose its contents to any other person. Thank you."
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: <[email-masked]>
Date: Mon, 24 Nov 2008 12:41:48 +0100

Hi,

Please count my company in as a SW vendor implementing.
MIPv6, DSMIPv6 with 3775 security solution based on IPsec and IKEv2.

I cannot mention the products our SW is part of.

BR, Karen

*****************************************************************************************
Karen Egede Nielsen
Systems Designer, Ph.D.

TietoEnatorA/S
IP Solutions, Telecom & Media
Skanderborgvej 232, 8260 Viby J, DK-Denmark
Phone: +45 89385100
Fax: +45 89385101
Direct Phone / Mobile +45 25134336
E-mail: [email-masked]
*****************************************************************************************
www.tietoenator.com  

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Basavaraj Patil
> Sent: Saturday, November 22, 2008 8:45 PM
> To: ext Lakshminath Dondeti; Alper Yegin
> Cc: [email-masked]