Re: Making IPsec *not* mandatory in Node Requirement

Hi all, # I'm surprised that opinion in the ML has changed from 2002. I agree that IPsec is not a universal security tool as many people had pointed out. I also would like to say that IPsec is still one of the useful tools. So, SHOULD　seems good to me. Thanks, From: Thomas Narten <[EMAIL PROT

RE: IPsec and 6LoWPAN (was: Re: Making IPsec *not* mandatory inNode Requirement)

Hi Jim: All I can say is that at least one Wireless Sensor Network standard under development will not use IPSec. ISA100.11a (http://www.isa.org/MSTemplate.cfm?MicrositeID=1134&CommitteeID=6891) has decided to endorse - and extend when necessary - the work done at 802.15.4 and 6LoWPAN, which m

RE: IPsec and 6LoWPAN (was: Re: Making IPsec *not* mandatory in Node Requirement)

Good point and Gordon Bell has almost always been right for me so I know I listen to him. The key is do these low power and restricted sensor components require security at the IP layer? If IEEE xxx is secure can we conclude the IP layer is not relevant for sensors, but I would suggest they ar

RE: Making IPsec *not* mandatory in Node Requirement

I don't think unanimous support is needed just the support within the domain of use and that could be a private or public network with collaboration with the firewall rules at the edge or the node directly in the case of p2p. On the issue of e2e encrypt/decrypt except the header there are those

RE: Making IPsec *not* mandatory in Node Requirement

This is clearly the path of least resistance to achieve consensus too and ecumenical in this community to achieve a common agreement. In this case less could be better (Mark Twain shorter please) but we need to be sure we do not have bugs and have to rev biz updates every 6 months if we are to

RE: Making IPsec *not* mandatory in Node Requirement

Agreed. /jim > -Original Message- > From: Julien Abeille (jabeille) [mailto:[EMAIL PROTECTED] > Sent: Tuesday, February 26, 2008 5:21 PM > To: Bound, Jim; Thomas Narten > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; ipv6@ietf.org; Fred Baker (fred) > Subject: RE: Making I

Re: Making IPsec *not* mandatory in Node Requirement

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

IPsec and 6LoWPAN (was: Re: Making IPsec *not* mandatory in Node Requirement)

I won't argue against the fact that security is an important part of a complete solution. The question for me is whether IPsec is the most appropriate solution for highly constrained embedded devices (constrained in energy, memory, compute, and link capabilities). From the few implementation n

RE: Making IPsec *not* mandatory in Node Requirement

> -Original Message- > From: Ed Jankiewicz [mailto:[EMAIL PROTECTED] > That is a good point, does IPsec depend on unanimous support? We > struggled with this in the DoD Profiles. Our rationale for > making IPsec > mandatory (except at the moment for some simple appliances) > was tha

RE: Making IPsec *not* mandatory in Node Requirement

Julien, >Ok, I get it, but I would think this is to be left to the >choice of the vendor if/how he provides security. > >I am in favor of the approach where node requirements rfc >defines the bare minimum for two nodes to be able to talk to >each other, then phrase the other sections like seti

Re: Making IPsec *not* mandatory in Node Requirement

That is a good point, does IPsec depend on unanimous support? We struggled with this in the DoD Profiles. Our rationale for making IPsec mandatory (except at the moment for some simple appliances) was that for IPsec to be a feasible solution it needs to be available throughout the network. W

RE: Making IPsec *not* mandatory in Node Requirement

Ok, I get it, but I would think this is to be left to the choice of the vendor if/how he provides security. I am in favor of the approach where node requirements rfc defines the bare minimum for two nodes to be able to talk to each other, then phrase the other sections like setion 6.1, 6.2, i.

RE: Making IPsec *not* mandatory in Node Requirement

Julien, I guess the point is that some cases and deployment, secuirty is not required to be used. However, if you are making a product and you do not include security as part of the solution, than IPSec then you have a problem. John >Fine with this > >The important point as Kevin Kargel menti

RE: Making IPsec *not* mandatory in Node Requirement

Fine with this The important point as Kevin Kargel mentions is that there ARE use cases where security is not required and/or end-to-end security is not required and/or IPSec is not required. Julien -Original Message- From: Bound, Jim [mailto:[EMAIL PROTECTED] Sent: mardi 26 février 2

RE: Making IPsec *not* mandatory in Node Requirement

On the contrary some of the laser sensing capabilities now could be considered light so I guess it is what we mean by "light" technically or from a physics/scientific view I took it to be light controlled by sensors. /jim > -Original Message- > From: Julien Abeille (jabeille) [mailto:[E

RE: Making IPsec *not* mandatory in Node Requirement

Example. Bad guy psychopath (medical definition) is able to shut off ones lights or security lighting system comes outside of the through window one did not expect gets in and is 6'8" tall 260 lbs and solid muscle (no fat) and not a nice person :--). Clearly extreme but some want security for

RE: Making IPsec *not* mandatory in Node Requirement

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

RE: the role of the node "requirements" document

Hi Brian, Please see inline. Cheers, Julien -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian E Carpenter Sent: mardi 26 février 2008 12:46 To: Ed Jankiewicz Cc: Brian Haberman; ipv6@ietf.org Subject: Re: the role of the node "requirements" document

Re: Making IPsec *not* mandatory in Node Requirement

Hi Brian, BTNS extensions to IPsec provide out-of-band security authentication (its not always in-band like you state). We can replicate the behavior of TLS/ SSL using IPsec. Have a look at: http://www.ietf.org/internet-drafts/draft-ietf-btns-prob-and-applic-06.txt Thanks, Vishwas On Tue, Feb 2

Re: the role of the node "requirements" document

On 2008-02-27 05:36, Ed Jankiewicz wrote: > (full disclosure - I am one of the editors of the DoD IPv6 Profiles > document - but comments are my own as an individual) > > 1. Can we discuss the normative level of the revised Node Requirements > document? My preference would be that it is a stan

IGPs [Re: Updates to Node Requirements-bis]

On 2008-02-26 19:00, Pekka Savola wrote: > On Mon, 25 Feb 2008, Manfredi, Albert E wrote: >> One MUST that the NIST IPv6 Profile introduced was mandating of OSPFv3 >> as the routing protocol. Is this because RIPng is not beiong adopted in >> practice? Small networks should do well with RIPng, I wou

Re: Making IPsec *not* mandatory in Node Requirement

[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

RE: Making IPsec *not* mandatory in Node Requirement

A sensor can only sense..., you are talking about a light actuator. Julien -Original Message- From: Thomas Narten [mailto:[EMAIL PROTECTED] Sent: mardi 26 février 2008 12:00 To: Julien Abeille (jabeille) Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; i

RE: Making IPsec *not* mandatory in Node Requirement

While I agree that by and large security is a good priority, there are cases for lightweight protocols to conserve cost. One example would be remote reporting thermometers that I actually use on IPv4 now. They are non-configurable, they have no settings other than network config. You plug them

Re: Making IPsec *not* mandatory in Node Requirement

> - 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. I agree. There is absolutely no need to prevent my neighbor (or a bad guy outside my window) from being able to contro

FW: Making IPsec *not* mandatory in Node Requirement

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 inter

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" r

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 >-

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 a

RE: Making IPsec *not* mandatory in Node Requirement

I don't see the implementation complexity as supporting rationale but would be open to hearing the issues of signaling maybe? MIPv6, IPsec, and IKEv2 (I also think it was the market mandate IKEv2 right now) do need to be cohesive wihin an implementation but clearly different discrete components

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

RE: Updates to Node Requirements-bis

I concur with Jeffrey regarding the email objective to the IETF below. The IETF develops specifications and guidelines (being loose here with the term). Our role is to "not" standardize deployment practices. The market uses this SDO work here to define their deployment scenarios for their busi

Re: Making IPsec *not* mandatory in Node Requirement

It is not the load or processing that is the issue really which I think you are alluding to. It is just the complexity of integrating a protocol like Mobile IPv6 with IPsec and IKE/IKEv2. Mobile IPv6 signaling can be secured via simpler mechanisms. But because of the prevailing thinking that IPsec

Re: Making IPsec *not* mandatory in Node Requirement

Hi Basavraj, But isn't that something IPsec needs to improve on. We already have efforts like BTNS with "connection latching" in IPsec which may help to ease the load on the end devices, which seems to have been the main issue raised. Thanks, Vishwas On Tue, Feb 26, 2008 at 9:58 AM, Basavaraj Pa

RE: Making IPsec *not* mandatory in Node Requirement

Thomas, >As a general "node requirement", SHOULD is the right level, not MUST. I veer to being somewhat conservative in this area. I don't think that we should be re-interpreting Standards-track RFCs in the Node Req document. I think that we can only refer to what the base standards track RFCs

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 implement

Re: Making IPsec *not* mandatory in Node Requirement

Hi Thomas, I would again suggest that instead of making it non-mandatory, we could provide a seperate set of requirements - for different device types. OSPFv3 currently uses IPsec because the assumption is that IPv6 mandates IPsec, and that means we do not need any other mechanism for the same. O

Re: the role of the node "requirements" document

(full disclosure - I am one of the editors of the DoD IPv6 Profiles document - but comments are my own as an individual) 1. Can we discuss the normative level of the revised Node Requirements document? My preference would be that it is a standards track or BCP ultimately, to give firm definit

Re: the role of the node "requirements" document

Pekka Savola <[EMAIL PROTECTED]> writes: > The node requirements document, despite its misleading title, is > INFORMATIONAL. It does not represent IETF consensus, so even if the > document would say every IPv6 node MUST implement IPsec, it would mean > basically nothing. You may be correct in

Re: Making IPsec *not* mandatory in Node Requirement

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,

RE: Updates to Node Requirements-bis (UNCLASSIFIED)

> -Original Message- > From: Vishwas Manral [mailto:[EMAIL PROTECTED] > Sent: Tuesday, February 26, 2008 10:58 AM > To: Manfredi, Albert E > Cc: Pekka Savola; ipv6@ietf.org > Subject: Re: Updates to Node Requirements-bis (UNCLASSIFIED) > > Hi Albert, > > Instead of mandating every protoc

Re: Updates to Node Requirements-bis (UNCLASSIFIED)

Hi Albert, Instead of mandating every protocol, would it be helpful to further break the functionality into two subclasses and have seperate requirements in such cases. I do not like the idea of having to impose a superset of the requirements for all such nodes. In my view such functionality shou

RE: the role of the node "requirements" document

Brian, Indeed, I know that RFC4294 is INFORMATIONAL. I got confused because I see the new node-req-bis draft URL snipped below to be on Standards Track. http://www.ietf.org/internet-drafts/draft-ietf-6man-node-req-bis-01.txt Sorry, if I am missing some IETF process. I was expecting the bis draft

RE: Updates to Node Requirements-bis (UNCLASSIFIED)

> -Original Message- > From: Pekka Savola [mailto:[EMAIL PROTECTED] > NIST's goal was probably, "some implementations on the field just > support static and maybe RIPng. We want to mandate something more > scalable, and OSPFv3 is as good an option as any". I completely agree. And, if

RE: the role of the node "requirements" document

Hi all, If people feel that further disclaimers are needed in the current bis draft to ensure that people understand that it only meant as an informative compendium, then I am happy to add that extra text. John >-Original Message- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >

RE: the role of the node "requirements" document

> I totally appreciate Alain's concern for cable modem devices > with limited memory for IPv6 but the problem is that IPv6 > community decided as far back as 1998 with RFC 2401 that > IPSec is mandatory for IPv6. The events of 1998 are irrelevant. The fact is that this website

Re: the role of the node "requirements" document

Hemant, Take a look at the category for RFC 4294 at http://tools.ietf.org/html/rfc4294. It is Informational and no discussion has occurred to change that classification for this update. Regards, Brian Hemant Singh (shemant) wrote: > Pekka, > > The node requirement draft as I read it fro

RE: the role of the node "requirements" document

Pekka, The node requirement draft as I read it from http://www.ietf.org/internet-drafts/draft-ietf-6man-node-req-bis-01.txt is on Standards Track. Did I miss anything because you think this node requirement doc is an INFORMATIONAL draft? As for IPSec and IPv6, indeed it is true that IPSec is m

the role of the node "requirements" document

On Tue, 26 Feb 2008, Alain Durand wrote: > The problem is that some of those devices have really limited memory and > they already do (too?) many things, so there is no room left... Some vendors > had to go back at their code and spend a lot of time and effort to clean > things up to make room for

Re: Making IPsec *not* mandatory in Node Requirement

Hi Alain, I really know the situation what you are saying. And there is other fact: Practical activities usually take over standardized specification. Anyway, aggressive vendors sometimes remove unused functions even though those are specified as MUST. So, the discussion you rose may be r

Re: Making IPsec *not* mandatory in Node Requirement

The problem is that some of those devices have really limited memory and they already do (too?) many things, so there is no room left... Some vendors had to go back at their code and spend a lot of time and effort to clean things up to make room for the very basic IPv6 code, so every kb count. The