Regarding sensors that needs scope there are sensor deployments being planned 
that will not even use TCP/IP but only layer 1 and 2 except for the gateway 
sensor.  So can we speak of sensors, sensor nets, sensor instrumentation that 
is using the TCP/IP protocol to be clear.

/jim

> -----Original Message-----
> From: Julien Abeille (jabeille) [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, February 26, 2008 2:28 PM
> To: [EMAIL PROTECTED]; Bound, Jim;
> [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Cc: ipv6@ietf.org; Fred Baker (fred)
> Subject: RE: Making IPsec *not* mandatory in Node Requirement
>
> 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
>
>
>
> 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]
> 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
> >
> >
> >
> >
> >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
--------------------------------------------------------------------

Reply via email to