Subject: [Ace] Pub Sub and multicast

From: Francesca Palombini <[email-masked]>
Date: Thu, 21 Mar 2019 15:31:20 +0000

Hi all,

TL;DR: Pub/sub and multicast hallway discussion happening at IETF104 (possibly during the hackathon?). Slides here:
https://github.com/EricssonResearch/coap-pubsub-profile/blob/master/Pubsub-multicast.pdf  Contact me if interested.
As mentioned during the CoRE interim, I have started to think on how to progress the security for pub/sub work. For the people not following, there is currently one draft in Ace that describes a profile of Ace for authorization and key distribution + communication protection for CoAP pubsub [1]: https://tools.ietf.org/html/draft-palombini-ace-coap-pubsub-profile-03.

While looking at how to move forward that draft, some things came up: first of all, it would be nice to use multicast to broadcast notifications from broker to subscribers, for performance reasons. Secondly, the ace-coap-pubsub document miss a way to protect unaware nodes to get unwillingly subscribed by attackers spoofing their IP address. In fact, ace-coap-pubsub does protect the publication, but does not set up the “authorization for subscribers” mechanism, or any other DoS protection mechanism.

These two points might seem parallel and independent, but one influence the others: depending on how multicast notifications are set up, we might reuse existing mechanisms that might protect against unauthorized nodes being sent notifications from the broker.

I put up some ideas in slides and was hoping to get some discussion started during the hackathon (if possible):
https://github.com/EricssonResearch/coap-pubsub-profile/blob/master/Pubsub-multicast.pdf and/or in the mailing list. As you can see, I try to explain the problem and come up with possible solutions based on the existing drafts. These are of course just very high level draft solutions, and require more discussion.

Any feedback welcome!

Francesca

[1] https://tools.ietf.org/html/draft-ietf-core-coap-pubsub-08

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 21 Mar 2019 17:03:51 +0100

I’m certainly interested.

Not sure I understand “	• Additionally, the Subscriber must be authorized to subscribe, otherwise an attacker could DoS external nodes that do not want to receive the publications”.  Whether the attacker is authorized to subscribe and whether the actual notification receiver is interested is kind of orthogonal.

Generally, we’d need a way to prove address ownership for setting up observation interest.  The Echo option can be used for that…

Grüße, Carsten

---

From: Francesca Palombini <[email-masked]>
Date: Fri, 22 Mar 2019 08:25:03 +0000

Hi Carsten,

Yes, the phrasing is not good on that slide... If you notice, the "proposals" afterward point to a general "DoS protection mechanism". How that is done really depends on the tools available, for example the broker might only send notifications to subscribers that have been added to an OSCORE group, but echo is definitely another way of doing that.

Thanks,
Francesca

On 21/03/2019, 17:04, "Carsten Bormann" <[email-masked]> wrote:

    
    
    Grüße, Carsten