Subject: [core] Spencer Dawkins' No Objection on draft-ietf-core-groupcomm-21: (with COMMENT)

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 19 Aug 2014 14:45:54 -0700

Spencer Dawkins has entered the following ballot position for
draft-ietf-core-groupcomm-21: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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?

---

From: "Rahman, Akbar" <[email-masked]>
Date: Tue, 19 Aug 2014 18:21:16 -0400

Hi Spencer,

Thanks for the good advice on the potential status for the document.
I'll wait for our AD (Barry) to make the final decision on that issue.
With regards to your final technical question:

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

Response:
-------------
Yes, you could technically do this.  But it would be a very inefficient
system as you would propagate multicast packets throughout the network
and have them received and decoded in a device's IP stack only to throw
it away at the last moment because it is on the wrong port.  It would be
much saner/efficient to have different IP multicast addresses to
segregate the packets from the beginning instead of counting on
different UDP ports.

Best Regards,

Akbar

-----Original Message-----
From: core [mailto:[email-masked]] On Behalf Of Spencer Dawkins
Sent: Tuesday, August 19, 2014 5:46 PM
To: The IESG
Cc: [email-masked];
[email-masked]; [email-masked]
Subject: [core] Spencer Dawkins' No Objection on
draft-ietf-core-groupcomm-21: (with COMMENT)

1.2.  Scope

In this text:

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?

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

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 19 Aug 2014 17:56:51 -0500

Thank you for the quick response!

> address, and each group uses its own UDP port, what doesn't work?

This is up to you, but "cannot" doesn't mean "bad idea" to me :-)

If I might make a suggestion, perhaps deleting the last sentence, and
saying something like this in its own paragraph?

"Because CoAP is often used with limited-power devices, it is RECOMMENDED
that disjoint groups do not attempt to share IP multicast addresses,
because all the devices using  the same IP multicast address will see
traffic for all groups, only to discard traffic intended for other
groups based on UDP port."

Or maybe multicast people all know that?

But do the right thing!

Spencer

> From: core [mailto:[email-masked] <javascript:;>] On Behalf Of
> Spencer Dawkins
> Cc: [email-masked] <javascript:;>;
> [email-masked] <javascript:;>; [email-masked]
> <javascript:;>
> [email-masked] <javascript:;>

---

From: "Rahman, Akbar" <[email-masked]>
Date: Tue, 19 Aug 2014 20:50:47 -0400

Hi Spencer,

>If I might make a suggestion, perhaps deleting the last sentence, and saying something like this in its own paragraph?

>"Because CoAP is often used with limited-power devices, it is RECOMMENDED that disjoint groups do not attempt to share IP multicast addresses, because all the devices using  the same IP multicast address will see traffic for all groups, only to discard traffic intended for other groups based on UDP port."

Response:

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

Okay.  Good suggestion.  We will add it in that section.  (Please leave us editorial license to modify the wording slightly depending on what happens on the other discussion regarding use of Normative language in the draft).

Best Regards,

Akbar

From: Spencer Dawkins at IETF [mailto:[email-masked]] 
Sent: Tuesday, August 19, 2014 6:57 PM
To: Rahman, Akbar
Cc: The IESG; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Spencer Dawkins' No Objection on draft-ietf-core-groupcomm-21: (with COMMENT)

On Tuesday, August 19, 2014, Rahman, Akbar <[email-masked]> wrote:

Hi Spencer,

Response:
-------------

If I might make a suggestion, perhaps deleting the last sentence, and saying something like this in its own paragraph?

"Because CoAP is often used with limited-power devices, it is RECOMMENDED that disjoint groups do not attempt to share IP multicast addresses, because all the devices using  the same IP multicast address will see traffic for all groups, only to discard traffic intended for other groups based on UDP port."

But do the right thing!

Spencer 

	Best Regards,

	Akbar

	-----Original Message-----
	From: core [mailto:[email-masked] <javascript:;> ] On Behalf Of Spencer Dawkins
	Sent: Tuesday, August 19, 2014 5:46 PM
	To: The IESG
	Cc: [email-masked] <javascript:;> ;
	[email-masked] <javascript:;> ; [email-masked] <javascript:;> 
	Subject: [core] Spencer Dawkins' No Objection on
	draft-ietf-core-groupcomm-21: (with COMMENT)

	

	
	1.2.  Scope

	

	
	In this text:

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 19 Aug 2014 20:22:33 -0500

On Tuesday, August 19, 2014, Rahman, Akbar <[email-masked]>
wrote:

> Okay.  Good suggestion.  We will add it in that section.  (Please leave us
> editorial license to modify the wording slightly depending on what happens
> on the other discussion regarding use of Normative language in the draft).
>
>
Oh, heck, yeah! You folk are the experts on CoAP ...

Spencer

>
>
>
>
> Best Regards,
>
>
>
>
>
> Akbar
>
>
>
>
>
> *From:* Spencer Dawkins at IETF [mailto:[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>]
> *Sent:* Tuesday, August 19, 2014 6:57 PM
> *To:* Rahman, Akbar
> *Cc:* The IESG; [email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>;
> [email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>;
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> *Subject:* Re: Spencer Dawkins' No Objection on
> On Tuesday, August 19, 2014, Rahman, Akbar <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
> Hi Spencer,
>
>