Group Communication for the Constrained Application Protocol (CoAP)
draft-ietf-core-groupcomm-25

Martin has a good catch about updates to 7252 and I support his Discuss.

---

It would have been nice to have heard about implementations of CoAP that
do group communication and whether they consider themselves consistent
with this I-D.

I agree with Richard/Martin that this doesn't seem like it is informational, and that experimental is probably the appropriate status.

Thanks for quickly addressing the issues raised.

Thank you for writing this document on this important topic. Iit is indeed something that many users of CoAP technology are wondering about.

For context, the comments below are based on the in-depth Gen-ART review for this document, by Ben Campbell - thank you! I have also read the document myself. I have also implemented multicast-based functionality for CoAP devices.

The document contains a lot very useful material. I do agree though with Ben and my esteemed Area Director colleagues who have raised Discusses: the document would be better classified as Experimental at this stage. The re-classification though is something that the IESG can easily do. But Martin and Ben, for instance, have provided additional useful suggestions on how to change the text itself; some changes are also necessary in my opinion.

A few more detailed comments. These are provided as-is, in the hopes that they are useful. At this moment I have no specific Discuss-level requirements for the draft, mainly because Brian and Martin already hold Discusses that I would have otherwise held.

     all.bldg6.example.com                   "all nodes in building 6"
     all.west.bldg6.example.com              "all nodes in west wing,
 
I have found that it is often useful to separate communications addressing and grouping from conceptual or application-specific grouping. The gathering of nodes in a group - and the design of a network to subnets - should be done based on communications convenience and efficiency, but it should not necessarily dictate all application-level groups that may be needed. To do so might in some cases lead to inflexibility and undue constraints on the network design. It may not be convenient to put all nodes in building 6 in one group, for instance, for various reasons. I would like to advocate a two-level approach, multicast for efficient reachability, but the application decisions are still based on information about the resources (such as location), rather than who  answered  a particular query on this multicast address. This also makes it easy to perform queries  of any complexity in a reasonable manner, e.g., "all sensors that have a reading higher than 27C".

   The non-idempotent CoAP method, POST, may only
   be used for group communication if the resource being POSTed to has
   been designed to cope with the unreliable and lossy nature of IP
   multicast.

This is certainly possible, and in my experience, very useful. The document would be  most helpful if it could provide more guidance regarding when a design is safe for use of POST.

   In the third case, typical in scenarios such as building control, a
   dynamic commissioning tool determines to which group a sensor or
   actuator node belongs, and writes this information to the node, which

Please make sure the document recognises the possibility that a device may simultaneously belong to multiple groups.

   Also, a form of authorization (making use of DTLS-secured CoAP
   [RFC7252]) MUST be used such that only authorized controllers are
   allowed by an endpoint to configure its group membership.

Is this "MUST use a form, e.g., DTLS" or "MUST use DTLS, a form"? I'd advocate the former...

   o  A server should not accept an IP multicast request that cannot be
      "authenticated" in some way (cryptographically or by some
      multicast boundary limiting the potential sources) [RFC7252].  See
      Section 5.3 for examples of multicast boundary limiting methods.

It is difficult for a server to know what boundary limitations may be in place in other devices around it.

  2.9.  Congestion Control

This section talks mainly about what the servers should do. There is only one rule about clients. Perhaps some additional guidance for the frequency that clients can send multicast requests would be advisable, unless it is already specified somewhere else.

  3.  Use Cases and Corresponding Protocol Flows

  3.1.  Introduction

I would have thought discovery of devices in the other direction, i.e., a GET ./well-kown  to all-coap-nodes would have been an interesting use case as well.

  5.  Security Considerations

I'm looking in particular at Sections 5.1 through 5.3. I'd like to say that I have had very positive experiences about using group communication with data object security, which is quite a lot better suited for group communication than transport layer solutions. No individual channels have to be established with the many group members. Messages can be signed with the authority of the sender rather than tying the security to the receiver. Forwarding through intermediaries retains security properties. And so on. 

Perhaps this alternative should be mentioned. Indeed, other than for low-security applications such as discovering network components, it is difficult to imagine completely unsecured operation, particularly considering that many if not most networks have a multitude of different devices in them, and it is not in my opinion a workable long-term solution to assume a firewall-based security model.

  8.  References

The group communication draft does not mention the observe draft, and the observe draft does not mention multicast. Are there any feature interaction issues that you might want to cover?

Thank you for updating the section on monitoring.  The description covering both targeted and pervasive attacks is very clear now and covers and explains the threats nicely.

I happy to see it go as experimental.

I agree with others: I sure would like to see this be Experimental, see some implementation experience, and, when security issues are sussed out, see it moved onto the Standards Track.

A few small comments; nothing earth-shattering:

2.7.2.1/2.7.2.2/2.7.2.6/2.7.2.7:

   ...the endpoint MUST effect registration...as soon as possible.
   
"MUST" do something "as soon as possible" does not seem like a testable requirement. What purpose is it serving?

2.8: These normative behaviors and guidelines look like they could use 2119 keywords. In particular, quite a few of those "should not"s look like they are meant as "SHOULD NOT"s. They obviously don't need to be, but I was wondering if there was something I was missing.

Given the complete lack of security mechanisms, I would be happier if this were Experimental, to be promoted to Standards Track once the group keying issues are addressed.

I share the concerns Martin listed in his Discuss, but that conversation is already underway. 

I saw that Martin is questioning whether this document should be Informational, but 

1.2.  Scope

   While [RFC7252] supports various modes of DTLS based security for
   CoAP over unicast IP, it does not specify any security modes for CoAP
   over IP multicast.  That is, [RFC7252] assumes that CoAP over IP
   multicast is not encrypted, nor authenticated, nor access controlled.
   This document assumes the same security model (see Section 5.1).
   However, there are several promising security solutions being
   developed that should be considered in the future for protecting CoAP
   group communications (see Section 5.3.3).

would make me uneasy about publishing it as standards-track in 2014. If this specification was Experimental, I'd feel better, but as the specification itself correctly points out:

5.4.  Pervasive Monitoring Considerations

   A key additional threat consideration for group communication is
   pointed to by [RFC7258] which warns of the dangers of pervasive
   monitoring.  CoAP group communication which is built on top of IP
   multicast should pay particular heed to these dangers.  This is
   because IP multicast is easier to intercept (e.g., and to secretly
   record) compared to unicast traffic.  Also, CoAP traffic is meant for
   the Internet of Things.  This means that CoAP traffic is often used
   for the control and monitoring of critical infrastructure (e.g.,
   lights, alarms, etc.) which may be prime targets for attack.

Approving it as a Proposed Standard seems to be begging for someone to deploy it without reading the warning labels ... would anyone who's planning to use CoAP group communications without security (beyond suggestions such as enabling WiFi security), be unwilling to use it at Experimental?

In this text:

2.3.  Port and URI Configuration

   A CoAP server that is a member of a group listens for CoAP messages
   on the group's IP multicast address, usually on the CoAP default UDP
   port, 5683.  If the group uses a specified non-default UDP port, be
   careful to ensure that all group members are configured to use that
   same port.  Therefore different ports for the same IP multicast
   address cannot be used to specify different CoAP groups.

I'm probably missing something, but I'm not understanding this. If I have two groups of IoT devices configured to use the same IP multicast address, and each group uses its own UDP port, what doesn't work?

Sorry, I only had time to quickly scan this. 

- For a non MC IP addr, how does one know a URI is for a
group?

- 5.3.3: That draft-keoh draft is quite controversial in the
DICE WG. The question there is whether or not its at all
sensible to try do group security in the DTLS record layer. I
think you really ought recognise that, since its quite
possible that a very different solution will be needed in
reality.

- Thanks for 5.4! I think you should also note that even with
encryption providing confidentiality, traffic analysis could
be a powerful tool against CoAP and group communication, so
future work with CoAP and developers/deployers should also
take into account traffic analsyis. To use your fav example,
its not hard to detect the lights being turned on or off even
if that's done via ciphertext is it?