Subject: Re: [core] Clarification of coap-08 multicast security requirements

From: Carsten Bormann <[email-masked]>
Date: Thu, 1 Dec 2011 09:35:27 +0100

Indeed, this is an interesting discussion.
Let me try to expand on that.

Why do we specify properties of a protocol?
Normally, we do this so the peer instance can rely on some behavior.
This will enable it to plan its actions appropriately and to correctly interpret responses.
Let's call this the "functional" reason for a mandate.

Another reason to mandate something is to protect nodes or the network.
Here, the specification is indeed not trying to help the peer instance.
This is about packets that don't authenticate.
The whole point of section 10.3.3 is to protect *other* nodes from becoming a victim of amplification attacks.
So this is not a "functional" mandate, it is a "protective" one.
These are typically stronger -- third party nodes won't care if a node fails on a functional level, but they may be disrupted by a failure on a protective mandate.
(For a physical-life analogy, when repairing cars there are stronger mandates on fixing your brakes than fixing your motor.)

Note that the current text says SHOULD NOT, not MUST NOT.  So it says there may be a reason to not heed this mandate.  But, by the meaning of "SHOULD NOT", this reason must exist, and it must outweigh the reasons given for the SHOULD NOT.  (The draft is however lacking in explaining what those reasons could be -- as a general rule, reasons SHOULD be given for not heeding a SHOULD/SHOULD NOT, otherwise it SHOULD be a MUST/MUST NOT.)  

Note also that the mandate is not specific on how the "authenticate" is achieved, so if there is some other way the CoAP server can ascertain that the request is not an attack, it can respond fine.  Specifically, on a network with L2 access protection, I would usually consider that level of source authentication to be implied for a packet that is using a local multicast scope.  We may want to expand on that.

BTW, "MAY NOT" is not very helpful anyway, as with that the sender of an un-authenticated multicast then simply doesn't know whether the desired nodes will reply or not.

Grüße, Carsten

---

From: "Dijk, Esko" <[email-masked]>
Date: Thu, 1 Dec 2011 09:50:27 +0000

Thanks Carsten, convincing arguments.

Thinking about this, the SHOULD NOT gives CoAP server implementers a clear rule how to configure its default behaviour towards the safe side, which is good. Only with good reasons a server can then respond to multicast requests e.g. in NoSec mode. I was thinking of some good example reasons:

1. to be able to use multicast at all in a system, if NoSec mode is used and if no further authentication means are available.
2. responding to multicast requests on /.well-known/core during initial configuration/commissioning of a system. In this configuration phase, security contexts may not have yet been established so nodes possibly have to rely on NoSec mode and multicast to be discoverable.
3. In order to implement CoAP servers that act as intermediaries to very constrained sensor nodes as in draft-arkko-core-sleepy-sensors. The sensors may not have any security/authentication mechanisms on board and yet they need to send out multicast.

In this light a 'SHOULD NOT' seems to be the best for the protective reasons mentioned.

Esko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Carsten Bormann
Sent: Thursday 1 December 2011 9:35
To: TianLinyi
Cc: [email-masked]
Subject: Re: [core] Clarification of coap-08 multicast security requirements

Grüße, Carsten

_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Thomas Fossati <[email-masked]>
Date: Thu, 1 Dec 2011 11:31:55 +0100

Carsten, Linyi, Kerry, Esko,

> (For a physical-life analogy, when repairing cars there are stronger mandates on fixing your brakes than fixing your motor.)

as a matter of taste, I don't like very much the idea that a protocol specification mandates a policy.  I'd prefer the spec to give us just a set of tools and a companion security analysis that clearly highlights the issues that may impact a deployment in case a given threat comes true.
It's an easier, cleaner, and more adaptive approach IMHO.

That's why in the first place I agreed with Esko.

The amplification attack that you want to counteract with the SHOULD NOT is in fact just one of the possible threats on the constrained nodes/network, which may or may not be real depending on the threat model of your specific deployment.

Another deployment may be particularly sensitive to unicast spoofing attacks, in which case crypto based authentication would help a lot in repelling the attacker.  Yet we don't say anywhere that unauthenticated unicast messages SHOULD NOT be accepted; that's because we correctly identify any countermeasure as a local policy matter.  And also, we've put a notice in the security consideration section that tells the CoAP implementer that there is a risk there, so that she is warned and may armor her implementation, if needed.

My two cents.