I like the idea of developing a generic threat model for homenets. This should frame what we are up against and make it clearer what the appropriate countermeasures should be and where they are best placed.

Robert

On 28/03/2012 8:42 PM, Brian E Carpenter wrote:
Maybe we should add a statement that device designers must assume
that DDoS and other forms of malicious traffic are present on
the homenet, as well as a statement that all traffic may be visible
to unknown third parties. A sort of generic threat model for homenets.

Regards
    Brian

On 2012-03-29 00:20, Robert Cragie wrote:
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,

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?

-Dmitry

------------------------------------------------------------------------
*From:* Cameron Byrne [[email protected]]
*Sent:* Tuesday, March 27, 2012 8:29 PM
*To:* Brian E Carpenter
*Cc:* Mark Townsley; Dmitry Anipko; [email protected] Group
*Subject:* Re: [homenet] Security goals


On Mar 27, 2012 6:53 PM, "Brian E Carpenter"
<[email protected]<mailto:[email protected]>>  wrote:
On 2012-03-28 11:58, Dmitry Anipko wrote:
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.
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.

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.

Cb
    Brian
_______________________________________________
homenet mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/homenet


_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet

------------------------------------------------------------------------

_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet

Reply via email to