Draft: draft-ietf-core-resource-directory

Commentary: This addresses a note from the SecDir review[1 ] and follows an earlier suggestion[2 ] . [ 1 ] : [ 2 ] : 
 Before the 2020 - 08 - 13 telechat , some reviews have come in : : Not   : Clarification on " subject " -- my intention was to include anything " subject " , but I do n't really know what else to put in there . Minor : Why is the first attempt special ? -- Can clarify , PR to come . [ edit : ] Nits addressed in More nits ( IDnits ) do not require editing , but some explanation -- where would that go ? Shepherd writeup ? ( that would be → :   that the DDOS mitigation section is a bit history heavy . I had similar comment in ; should we use that comment to shorten here ? [ edit : If so , want an ACK . ] " It is my impression , that Security Considerations were mostly written having in mind that ( D)TLS is always used , however it is only " SHOULD " in this draft ( or even " MAY " if we look at RFC6690 which Security Considerations this draft refers to ) . I think that adding a few words describing which consequences for security not using ( D)TLS would have and in which cases it is allowed will make the Security Considerations more consistent . " -- [ edit : covered in ] I 'll issue PRs for what I think we can do something about quickly , but wo n't merge them or create a -26 without an ACK on them ( given we 're late in the whole publication stage and my impression is that ill - coordinated uploads do more harm than good ) and will follow up on this comment when they 're ready for review . 
 With the additional reviews that have come in today , I see no point in addressing some of what has come in in a pre - telechat update ( as we ca n't resolve all the discuss points ) -- taking the urgency off this . I 'll still file PRs for changes resulting from the reviewer comments . Procedurally ( so this goes to or Is the general expectation with IESG comments that the text be further improved to answer all the points ( especially when they are comments ) , or can a plain " we did it that way because " suffice ? In the latter case , would it make sense to collect point - to - point responses here so they get author or WG review before " we " answer them ? 
 With and its follow - ups sent out , this is closed ; any further comments will be opened as new issues . 
 From  's Secdir review , this is something we should address . The hard part is the " how " , as echo - request - tag is about to update 7252 with a concrete suggestion ( which would apply to RD implicitly ) , but saying that here would create a normative ( forward ? they 're not far apart ) reference between otherwise unrelated documents . It might be worth adding a note that a simple registration does n't need special consideration in that respect , as the GET .well - known / core is not significantly larger than the POST /rd -- at least from a DDOS point of view . ( By the way , that whole paragraph is quite a mouthful , reads a bit like a history lesson -- I wonder why that did n't occur to me earlier , but changing such things now is probably hard ; let 's leave it to a summarizing " but in the end that 's what you do against it " )
Mailing list commentary: Hello , CoRE and IESG members , thanks for your input to the Resource Directory document , and your patience while it was being processed . Before the individual point to point responses can go out , this mail is to address the general status , and answer a few points that were brought up by different reviewers ( it will be referred back to in the point to point responses ) . In summary , the points raised in the reviews led to the changes of the recently uploaded [ -26 ] , and where no changes were made , the reasoning behind the choices in the document is outlined below or in the following mails . ( Either way , short of aggregated nits paragraphs , all points are responded to in the following mails ) . A few larger issues evolved from the review comments being discussed in the interim meetings , so please expect a -27 at a later point ( after IETF109 ) with the changes mentioned below . Kind regards Christian [ -26 ] : Preface = = = = = = = References into the issue tracker are primarily intended for bookkeeping and to give you access to the altered text if you 're curious -- but for general review purposes , the responses are self - contained . Anticipated changes = = = = = = = = = = = = = = = = = = = We have opted to submit a new version that should clear out all the other comments , so that the remaining work can be focused and swift : Replay and Freshness ( OPEN - REPLAY - FRESHNESS ) The comment on DTLS replay made us reevaluate the security properties of operations on the registration resource . While these are successively harder going from DTLS without replay protection to DTLS with replay protection and hardest with OSCORE , the text as it is is still vulnerable to an attacker stopping a reoccurring registration , or undoing alterations in registration attributes . Mitigation from a concurrent document ( the Echo mechanism of I - D.ietf - core - echo - request - tag in event freshness mode ) is planned , but the text is not complete yet . Necessity of the value in all responses The requirements around    and the necessity to express all looked up links in fully resolved form have stemmed from different ways has been read , both in the IETF community and by implementers . A comment from has shown a clear error in one of the readings . That reading is single - handedly responsible for most of the overhead in the wire format ( savings can go up to 50 % ) , which is of high importance to the CoRE field . Due to that , it is the WG 's and authors ' intention to remove the reading from the set of interpretations that led to the rules set forth . The change will not render any existing RD server implementation incompatible ( older RDs would merely be needlessly verbose ) , and the known implementations of parsers can easily be updated . The updates to the document could not be completed in time with the rest of the changes , because a ) it requires revisiting the known implementations for confirmation and b ) will affect almost every example that contains lookup results . Server authorization ( OPEN - SERVER ) The two areas of " how is the RD discovery secured " and " what do applications based on the RD need to consider " jointly opened up new questions about server authorization and the linkage between a client 's intention and the server 's promises that may easily not conclusde in timeframe reasonable for . While steps have been taken to address the issue both on the RD discovery and the applications side ( ) , the ongoing discussions in the working group may turn up with a less cumbersome phrasing for these parts . There 's a few small open issues Esko brought up on the issue tracker that could not be addressed in time ; most of them are about enhancing the examples , which best happens after the anchor cleanup anyway . Repeated topics = = = = = = = = = = = = = = = A few common topics came up in multiple reviews , and are addressed in the following section ; the individual responses can be found in follow - up mails , and refer to the common topics as necesary . GENERIC - FFxxDB
Paragraph (version A):
Services that run over UDP unprotected are vulnerable to unknowingly
become part of a DDoS attack as UDP does not require return
routability check.  Therefore, an attacker can easily spoof the
source IP of the target entity and send requests to such a service
which would then respond to the target entity.  This can be used for
large-scale DDoS attacks on the target.  Especially, if the service
returns a response that is order of magnitudes larger than the
request, the situation becomes even worse as now the attack can be
amplified.  DNS servers have been widely used for DDoS amplification
attacks.  There is also a danger that NTP Servers could become
implicated in denial-of-service (DoS) attacks since they run on
unprotected UDP, there is no return routability check, and they can
have a large amplification factor.  The responses from the NTP server
were found to be 19 times larger than the request.  An RD which
responds to wild-card lookups is potentially vulnerable if run with
CoAP over UDP.  Since there is no return routability check and the
responses can be significantly larger than requests, RDs can
unknowingly become part of a DDoS amplification attack.
Paragraph (version B):
Services that run over UDP unprotected are vulnerable to unknowingly
amplify and distribute a DoS attack as UDP does not require return
routability check.  Since RD lookup responses can be significantly
larger than requests, RDs are prone to this.
Paragraph (version B):
Security considerations: Shorten amplification mitigation by
removing the references to earlier cases of DDoS amplification,
and by removing redundancies between the problem introduction and
the description of how an RD could become part of the problem.