On Tuesday, August 19, 2014, Rahman, Akbar <Akbar.Rahman@interdigital.com>
wrote:

> 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).
>
>
Oh, heck, yeah! You folk are the experts on CoAP ...

Spencer


>
>
>
>
> Best Regards,
>
>
>
>
>
> Akbar
>
>
>
>
>
> *From:* Spencer Dawkins at IETF [mailto:spencerdawkins.ietf@gmail.com
> <javascript:_e(%7B%7D,'cvml','spencerdawkins.ietf@gmail.com');>]
> *Sent:* Tuesday, August 19, 2014 6:57 PM
> *To:* Rahman, Akbar
> *Cc:* The IESG; core-chairs@tools.ietf.org
> <javascript:_e(%7B%7D,'cvml','core-chairs@tools.ietf.org');>;
> draft-ietf-core-groupcomm@tools.ietf.org
> <javascript:_e(%7B%7D,'cvml','draft-ietf-core-groupcomm@tools.ietf.org');>;
> core@ietf.org <javascript:_e(%7B%7D,'cvml','core@ietf.org');>
> *Subject:* Re: Spencer Dawkins' No Objection on
> draft-ietf-core-groupcomm-21: (with COMMENT)
>
>
>
> Thank you for the quick response!
>
> On Tuesday, August 19, 2014, Rahman, Akbar <Akbar.Rahman@interdigital.com
> <javascript:_e(%7B%7D,'cvml','Akbar.Rahman@interdigital.com');>> wrote:
>
> 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.
>
>
>
> 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
>
>
>
>
>
> Best Regards,
>
>
> Akbar
>
>
>
> -----Original Message-----
> From: core [mailto:core-bounces@ietf.org] On Behalf Of Spencer Dawkins
> Sent: Tuesday, August 19, 2014 5:46 PM
> To: The IESG
> Cc: core-chairs@tools.ietf.org;
> draft-ietf-core-groupcomm@tools.ietf.org; core@ietf.org
> Subject: [core] Spencer Dawkins' No Objection on
> draft-ietf-core-groupcomm-21: (with COMMENT)
>
> 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?
>
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>
>