[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. > > Let me answer on everyone's behalf:
IPsec is an end-to-end security protocol. For many environments, such as set-top boxes and the like, the box has its own ability to secure itself (or make itself unusable), and the L0/L1/L2 portion of the network is under the provider's physical control. So, for a substantial portion of deployed equipment (cable/dsl boxes, embedded systems), with no user-serviceable parts, *how* security is handled, is orthogonal to the issue of whether it needs security. Suggesting that in-band, network-wide, heavy-weight security (IPsec) is the *only* solution to the requirement, doesn't fly. Any of a bunch of other kinds of security can do the job, from TLS to SSH to use of out-of-band channels. And *this* is why I think that IPsec ought to be downgraded to SHOULD for IPv6 node requirements. Brian Dickson > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
