Skip to main content

Last Call Review of draft-ietf-core-resource-directory-24

Request Review of draft-ietf-core-resource-directory
Requested revision No specific revision (document currently at 28)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2020-03-31
Requested 2020-03-10
Authors Christian Amsüss , Zach Shelby , Michael Koster , Carsten Bormann , Peter Van der Stok
Draft last updated 2020-03-24
Completed reviews Secdir Last Call review of -24 by Adam W. Montville (diff)
Genart Last Call review of -24 by Russ Housley (diff)
Genart Telechat review of -25 by Russ Housley (diff)
Secdir Telechat review of -25 by Valery Smyslov (diff)
Assignment Reviewer Adam W. Montville
State Completed
Review review-ietf-core-resource-directory-24-secdir-lc-montville-2020-03-24
Posted at
Reviewed revision 24 (document currently at 28)
Result Ready
Completed 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.