Last Call Review of draft-ietf-core-resource-directory-24
review-ietf-core-resource-directory-24-secdir-lc-montville-2020-03-24-00

Request Review of draft-ietf-core-resource-directory
Requested rev. no specific revision (document currently at 25)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2020-03-31
Requested 2020-03-10
Authors Zach Shelby, Michael Koster, Carsten Bormann, Peter Van der Stok, Christian Amsüss
Draft last updated 2020-03-24
Completed reviews Secdir Last Call review of -24 by Adam Montville (diff)
Genart Last Call review of -24 by Russ Housley (diff)
Genart Telechat review of -25 by Russ Housley
Assignment Reviewer Adam Montville
State Completed
Review review-ietf-core-resource-directory-24-secdir-lc-montville-2020-03-24
Posted at https://mailarchive.ietf.org/arch/msg/secdir/sILowJEcUXs23I1N9l3KeTi6jN4
Reviewed rev. 24 (document currently at 25)
Review result Ready
Review completed: 2020-03-24

Review
review-ietf-core-resource-directory-24-secdir-lc-montville-2020-03-24

I generally feel that this draft is ready. I do think the Security ADs should pay particular attention to some of the security considerations. Most notable is Section 8.3, Denial of Service Attacks. This section describes how a Resource Directory (RD) “…can unknowingly become part of a DDoS amplification attack,” but doesn’t provide any real mitigation or normative language toward that end.

It is clear from the draft that the preferred deployment of these capabilities is to leverage TLS or DTLS, but doing so is not mandatory per the draft. There is an assumption, also, that clients are provided a certificate at the time of manufacture, which can then be used by the RD as the endpoint’s name.

It seems that, with use of TLS/DTLS, and with certain device characteristics in place, things are pretty well buttoned up. Without these assumptions, however, it seems that the use of an RD could be problematic in more open deployments. Then again, I’m not operating in the space of constrained devices day-to-day.