Re: [homenet] Security goals

[Robert Cragie]

I think there are two orthogonal aspects here. There is one regarding the ability for host to perform end to end communication securely (i.e with integrity and/or confidentiality). This goes without saying and I agree there needs to be a strong statement regarding this. However this is orthogonal to a host's ability to handle all manner of traffic which could be directed to it, especially malicious traffic. Ideally hosts would be able to handle this and the recommendation would still be to require hosts to firewall their own data. When a host is implemented on a platform with plenty of storage and processing power, this is not really an issue. However, in the LLN case, hosts may be running on platforms which have very little storage and processing power by comparison with limited ability to firewall. I do not think we should be precluding these type of devices.

Robert

On 28/03/2012 6:47 AM, Dmitry Anipko wrote:

Brian,





-Dmitry

------------------------------------------------------------------------
*From:* Cameron Byrne [cb.li...@gmail.com]
*Sent:* Tuesday, March 27, 2012 8:29 PM
*To:* Brian E Carpenter
*Cc:* Mark Townsley; Dmitry Anipko; homenet@ietf.org Group
*Subject:* Re: [homenet] Security goals

I personally would definitely want to see a stronger statement that hosts should be implementing means sufficient to perform end 2 end communication securely on any network, without requiring additional protections from outside. But I guess a few people would then argue that some hosts can't implement the same degree of security protection as the degree e.g. tablets and PC can - and that guess led to the current lanuage. If you think it should be changed to some stronger statement, do you have something specific in mind? On Mar 27, 2012 6:53 PM, "Brian E Carpenter" <brian.e.carpen...@gmail.com <mailto:brian.e.carpen...@gmail.com>> wrote:

>
> On 2012-03-28 11:58, Dmitry Anipko wrote:

> >

>
> I think we know from some famous cases that SCADA systems are highly
> insecure, mainly due to following this principle (translated as
> "security is too hard and this device will always be on a private
> network anyway"). I'm a bit nervous that this policy will encourage
> low-end device designers to classify their devices as not having
> enough resource to deal with security.
>





Cb
>    Brian
> _______________________________________________
> homenet mailing list
> homenet@ietf.org <mailto:homenet@ietf.org>
> https://www.ietf.org/mailman/listinfo/homenet



_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

> > As someone who works for a host software vendor, I'd like to add couple of points. I agree with Mark that in general the security topic is wider than only filtering on the borders of the realms of the traffic destined to hosts, and I support the efforts to figure out the right set of knobs for the former. That said, for the latter, I'd like to see something along the below lines in the requirements > > (some of which may already be in the text in some form, putting it here just for fluency of this piece of the story). > > 1. Homenet hosts MUST implement their own security policies in accordance to their computing capabilities. This category should / will be eliminated by market forces, too much liability associated with being willfully insecure. There are famous cases for this too. If internet segmentation is all that is required, there are address types that facilitate local only access.

smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet