Hi Vishwas, I am not a security expert, I can just say that the lightweight point is just one among other conseqences of the platform capabilities (limited processing power, memory, storage, heavy duty cycle) and expected life time (usually 5 years running on batteries) of the device.
My interest is the following: If our work on the cost of IPv6 features shows that some of them are too heavy, the ideal would be that necessary RFC updates (such as what 6lowpan started) occur, and ultimately RFC4294 can fit on a sensor, or that several "profiles" (like the DOD or NIST ones) are defined within 6man Cheers, Julien -----Original Message----- From: Vishwas Manral [mailto:[EMAIL PROTECTED] Sent: mardi 26 février 2008 11:47 To: Julien Abeille (jabeille) Subject: Re: Making IPsec *not* mandatory in Node Requirement Hi Julien, As you stress on "lightweight", I would like to stress the work in the BTNS working group. I would want to hear more form you and how we can change IPsec to meet your needs. Thanks, Vishwas On Tue, Feb 26, 2008 at 11:28 AM, Julien Abeille (jabeille) <[EMAIL PROTECTED]> wrote: > Hi John, > > Regarding sensors, > - some applications (e.g. sensors for process control in factories) > require strong security, but dedicated security mechanism are used (in > ISA standard for industrial automation as an example), the main > difference with IPSec being the importance of the "lightweigt" > requirement. A security mechanism and associated algorithms for such > sensors might use much less processing power, memory... than standard > IP mechanisms > - some applications might not require any security, e.g. a light sensor in > your flat might not need it and not implement it, also due to the very low > cost of the sensor. > > Cheers, > John > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: mardi 26 février 2008 20:13 > To: Julien Abeille (jabeille); [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] > Cc: ipv6@ietf.org; Fred Baker (fred) > Subject: RE: Making IPsec *not* mandatory in Node Requirement > > 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 > > > > > > > > > > > >-----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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
