Re: [core] Review of draft-ietf-core-groupcomm-bis-03

[John Mattsson <[e-mail]>]

Hi,

I just submitted draft-mattsson-core-coap-attacks-00 which has a section on amplification attacks with descriptions of multicast and multicast observe but does not give any answers how to mitigate such amplification attacks.

Cheers,
John

-----Original Message-----
From: John Mattsson <[e-mail]>
Date: Thursday, 25 February 2021 at 00:27
To: "[e-mail]" <[e-mail]>
Subject: Review of draft-ietf-core-groupcomm-bis-03

Review of draft-ietf-core-groupcomm-bis-03

I think this looks very well-written. I read through most of the document quickly and found very little to comment about.

- It seems unclear to me exactly how this updates RFC 7252. Do everything in RFC 7252 still apply, or are some multicast parts replaced? In such case which parts?

- The document seems a bit too locked to "UDP/IP multicast" for my taste. RFC 7252 left things much more open with statements like "by default, are transported over UDP". CoAP is now popular in many environment without UDP/IP and the same will/is true for Group CoAP. I don't see any reason why most of the things in the document could not easily be used with broadcast, geocast, unicast, and non-IP multicast. Maybe you could soften it down a bit so people wanting to use Group CoAP over Foo can still claim they are doing group CoAP draft-ietf-core-groupcomm-bis.

- I think group CoAP needs quite a bit more text on aplification attacks and DoS. There has been several negative articles regarding CoAP and DDoS in the last years. Group CoAP with it's 1 requests and N responses is a amplification in itself. Multicast Observe is even worse, 1 requests and N^2 responses. Multicast can however not be used on the public Internet which limits any attacks. The current document only mention amplification in some specific cases. I think the draft needs to expand on the text in RFC 7252:

 "This specification attempts to reduce the
   amplification effects of multicast requests by limiting when a
   response is returned.  To limit the possibility of malicious use,
   CoAP servers SHOULD NOT accept multicast requests that can not be
   authenticated in some way, cryptographically or by some multicast
   boundary limiting the potential sources.  If possible, a CoAP server
   SHOULD limit the support for multicast requests to the specific
   resources where the feature is required."

A reader of draft-ietf-core-groupcomm-bis might think that Group OSCORE and Echo is enough to stop amplification, which is not the case. Echo only helps a bit by limiting the size of the responses but not the number of responses. An attacker can spoof the source IP of the request and a smart attacker would send it to a resource that supports multicast requests. Not sure Group OSCORE helps much at all as an attacker can take an existing group request and change the source IP. 

Cheers,
John

-----Original Message-----
From: core <[e-mail]> on behalf of "[e-mail]" <[e-mail]>
Reply to: "[e-mail]" <[e-mail]>
Date: Monday, 22 February 2021 at 17:51
To: "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: [core] I-D Action: draft-ietf-core-groupcomm-bis-03.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Constrained RESTful Environments WG of the IETF.

        Title           : Group Communication for the Constrained Application Protocol (CoAP)
        Authors         : Esko Dijk
                          Chonggang Wang
                          Marco Tiloca
	Filename        : draft-ietf-core-groupcomm-bis-03.txt
	Pages           : 58
	Date            : 2021-02-22

Abstract:
   This document specifies the use of the Constrained Application
   Protocol (CoAP) for group communication, using UDP/IP multicast as
   the underlying data transport.  Both unsecured and secured CoAP group
   communication are specified.  Security is achieved by use of the
   Group Object Security for Constrained RESTful Environments (Group
   OSCORE) protocol.  The target application area of this specification
   is any group communication use cases that involve resource-
   constrained devices or networks.  This document replaces RFC7390,
   while it updates RFC7252 and RFC7641.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-core-groupcomm-bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-core-groupcomm-bis-03
https://datatracker.ietf.org/doc/html/draft-ietf-core-groupcomm-bis-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-core-groupcomm-bis-03


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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