John, Clarification: I am not talking about set top box, but cable modems. Very different beast.
- Alain. On 2/27/08 3:12 AM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > 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); [email protected]; 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; [email protected]; 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; [email protected]; [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 [email protected] Administrative >>>> Requests: http://www.ietf.org/mailman/listinfo/ipv6 >>>> >> -------------------------------------------------------------------- >>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> [email protected] >>> Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> [email protected] >> Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> [email protected] >> Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
