Julien and Alain, My high-level question to you both is, for sensors and set-top boxes - do you feel that you do not need security for any reason? Is this a long-term issue or a short-term issue.
I can't really think of a reason why security would not be an issue, but I could be wrong. John >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >Behalf Of ext Julien Abeille (jabeille) >Sent: 26 February, 2008 11:12 >To: Bound, Jim; Patil Basavaraj (NSN - US/Irving); Thomas >Narten; Nobuo OKABE >Cc: Loughney John (Nokia-OCTO/PaloAlto); ipv6@ietf.org; Fred >Baker (fred) >Subject: RE: Making IPsec *not* mandatory in Node Requirement > >Hi all, > >To come back to constrained device, as I already mentionned on >the list within 6lowpan, we are working on a draft which >documents the cost of each feature mandated by RFC4294, from >an implementation perspective (target platform is 8bit >microcontroller, few 10K ROM, few K RAM). I guess as soon as >we have results, this might help the discussion. > >To give a bit of insight on sensor industry, the market is >highly fragmented in terms of technology. Most vendors have >proprietary L3, sometimes proprietary L2, and there are a >bunch of standards coming, like ZigBee, Z-Wave, ISA, HART... >One reason for people not to go for IPv6 is "Oh this is too >big for a sensor", also because they are not always familiar with IP. > >What I want to say is that this kind of question (do we >mandate IPSec) is critical for a domain which promises >billions of device. > >Cheers, >Julien > > > > >Julien Abeillé >Software Engineer >Technology Center >[EMAIL PROTECTED] >Fax:+41 21 822 1604 >Cisco Systems International Sàrl >Av. des Uttins 5 >1180 Rolle >Switzerland (FR) >www.cisco.com > > >This e-mail may contain confidential and privileged material >for the sole use of the intended recipient. Any review, use, >distribution or disclosure by others is strictly prohibited. >If you are not the intended recipient (or authorized to >receive for the recipient), please contact the sender by reply >e-mail and delete all copies of this message. > > >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >Behalf Of Bound, Jim >Sent: mardi 26 février 2008 19:50 >To: Basavaraj Patil; Thomas Narten; Nobuo OKABE >Cc: John Loughney; ipv6@ietf.org; Fred Baker (fred) >Subject: RE: Making IPsec *not* mandatory in Node Requirement > >For defense in depth scenarios I disagree in the case for the >MN to verify with the HA. But I see your point. >/jim > >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf >> Of Basavaraj Patil >> Sent: Tuesday, February 26, 2008 12:58 PM >> To: Thomas Narten; Nobuo OKABE >> Cc: John Loughney; ipv6@ietf.org; [EMAIL PROTECTED] >> Subject: Re: Making IPsec *not* mandatory in Node Requirement >> >> >> I agree with Thomas about his views on IPsec being a mandatory and >> default component of the IPv6 stack. >> Because of this belief, Mobile IPv6 (RFC3775) design relied on IPsec >> for securing the signaling. This has lead to complexity of the >> protocol and not really helped either in adoption or implementation. >> IPsec based security is an overkill for Mobile IPv6 and illustrates >> the point that you do not have to use it simply because it >happens to >> be an integral part of IPv6. >> >> -Basavaraj >> >> >> On 2/26/08 10:18 AM, "ext Thomas Narten" <[EMAIL PROTECTED]> wrote: >> >> > IMO, we need to get over the idea that IPsec is mandatory in IPv6. >> > Really. Or that mandating IPsec is actually useful in practice. >> > >> > It is the case that mandating IPsec as part of IPv6 has >> contributed to >> > the hype about how great IPv6 is and how one will get >> better security >> > with IPv6. Unfortunately, that myth has also harmed the >> overall IPv6 >> > deployment effort, as people look more closely and come to >> understand >> > that deploying IPv6 doesn't automatically/easily yield improved >> > security. >> > >> > We all know the reality of security is very different and >much more >> > complicated/nuanced then just saying "use IPsec". >> > >> > Consider: >> > >> > IPsec by itself (with no key management) is close to useless. The >> > average person cannot configure static keys, so the result is (in >> > effect) a useless mandate (as a broad mandate for ALL nodes). >> > >> > What applications actually make use of IPsec for security? >> A lot fewer >> > than one might think. For many IPv6 devices/nodes, if one actually >> > looks at the applications that will be used on them, they >> do not use >> > IPsec today for security. And, there are strong/compelling >> arguments >> > for why IPsec is not the best security solution for many >> applications. >> > Thus, requiring IPsec is pointless. >> > >> > To be truly useful, we (of course) need key management. If >> we want to >> > mandate key management, the stakes go way up. IKEv1/v2 is >> not a small >> > implementation effort. And, we are now in the funny situation where >> > IKEv1 has been implemented, but due to shortcomings, IKEv2 >> has already >> > been developed. IKEv2 has been out for over 2 years, but >> > implementations are not widespread yet. So, would we mandate IKEv1 >> > (which is obsoleted and has documented issues), or do we mandate >> > IKEv2, even though it is clear it is not widely available yet? >> > >> > IMO, we should drop the MUST language surrounding IPsec. >> The technical >> > justification for making it MUST are simply not compelling. >> It seems >> > to me that the MUST is there primarily for historical/marketing >> > reasons. >> > >> > Note that dropping the MUST will not mean people stop implementing >> > IPsec, where there is compelling benefit. Indeed, note >that the USG >> > has already moved away from IKEv1 and has strongly >> signalled that it >> > will require IKEv2 going forward. So I am confident that IPsec (and >> > IKE) will get implemented going forward. >> > >> > But there is no reason why IPsec should be mandated in >> devices where >> > it is clear (based on the function/purpose of the device) >> that IPsec >> > will in fact not actually be used. >> > >> > As a general "node requirement", SHOULD is the right level, >> not MUST. >> > >> > Thomas >> > >-------------------------------------------------------------------- >> > IETF IPv6 working group mailing list ipv6@ietf.org Administrative >> > Requests: http://www.ietf.org/mailman/listinfo/ipv6 >> > >-------------------------------------------------------------------- >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
