Roni, thank you for your review. Med, thanks for your responses. I ran out of time to review this document before the telechat so I entered a No Objection ballot on the basis of this Gen-ART review. Alissa > On Mar 7, 2019, at 8:04 AM, mohamed.boucadair@xxxxxxxxxx wrote: > > Re-, > > I hear you, > > Cheers, > Med > >> -----Message d'origine----- >> De : Roni Even (A) [mailto:roni.even@xxxxxxxxxx] >> Envoyé : jeudi 7 mars 2019 13:29 >> À : BOUCADAIR Mohamed TGI/OLN; Datatracker on behalf of Roni Even; gen- >> art@xxxxxxxx >> Cc : draft-ietf-dots-data-channel.all@xxxxxxxx; ietf@xxxxxxxx; dots@xxxxxxxx >> Objet : RE: Genart last call review of draft-ietf-dots-data-channel-27 >> >> Hi Med, >> Thanks I am OK with your response only open one >> >> >>> administrator even if rejected. >> >> [Med] This is deployment-specific. For example, if conflict handling requires >> "notify an administrator for validation", there is no point to report again. >> [RE] Yes but for example "reject all" may cause an attack cancelling a valid >> filter, so it should also be notified to the administrator for validation. > > [Med] The notification can be part of the local policy, see below: > > DOTS servers SHOULD support a configuration parameter to indicate the > behavior to follow when a conflict is detected (e.g., reject all, > reject the new request, notify an administrator for validation). > > I >> did not see any discussion about this is the security section that will warn >> about such a possible attack that can happen for a specific policy. > > [Med] IMHO, this is not a new attack vector. This is falling under this part: > > this usage. Appropriate security measures are recommended to prevent > illegitimate users from invoking DOTS data channel primitives. > Nevertheless, an attacker who can access a DOTS client is technically > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > capable of launching various attacks, such as: > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > o Setting an arbitrarily low rate-limit, which may prevent > legitimate traffic from being forwarded (rate-limit). > > o ... > >> Roni >> >> -----Original Message----- >> From: Gen-art [mailto:gen-art-bounces@xxxxxxxx] On Behalf Of >> mohamed.boucadair@xxxxxxxxxx >> Sent: Thursday, March 07, 2019 1:57 PM >> To: Datatracker on behalf of Roni Even; gen-art@xxxxxxxx >> Cc: draft-ietf-dots-data-channel.all@xxxxxxxx; ietf@xxxxxxxx; dots@xxxxxxxx >> Subject: Re: [Gen-art] Genart last call review of draft-ietf-dots-data- >> channel-27 >> >> Hi Roni, >> >> Thank you for the review. >> >> Please see inline. >> >> Cheers, >> Med >> >>> -----Message d'origine----- >>> De : Datatracker on behalf of Roni Even [mailto:noreply@xxxxxxxx] >>> Envoyé : jeudi 7 mars 2019 11:21 À : gen-art@xxxxxxxx Cc : >>> draft-ietf-dots-data-channel.all@xxxxxxxx; ietf@xxxxxxxx; >>> dots@xxxxxxxx Objet : Genart last call review of >>> draft-ietf-dots-data-channel-27 >>> >>> Reviewer: Roni Even >>> Review result: Ready with Nits >>> >>> I am the assigned Gen-ART reviewer for this draft. The General Area >>> Review Team (Gen-ART) reviews all IETF documents being processed by >>> the IESG for the IETF Chair. Please treat these comments just like >>> any other last call comments. >>> >>> For more information, please see the FAQ at >>> >>> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. >>> >>> Document: draft-ietf-dots-data-channel-?? >>> Reviewer: Roni Even >>> Review Date: 2019-03-07 >>> IETF LC End Date: 2019-03-13 >>> IESG Telechat date: Not scheduled for a telechat >>> >>> Summary: >>> The document is ready with nits and one minor issue for publication as >>> a standard track RFC >>> >>> Major issues: >>> >>> Minor issues: >>> >>> 1. In section 2 there is a discussion about conflicting filtering requests. >> >> [Med] I guess you meant section 3. >> >> I >>> think that this can be considered as an attack and should be mentioned >>> in the security section. >> >> [Med] Conflicts may be caused by various "legitimate" actions. Of course, as >> discussed in the Security section, an attacker who access to a DOTS client >> can do a lot of things such as installing some filters including conflicting >> ones. This is already reported in the security section. >> >> >> I also think that such a conflict must be reported to the >>> administrator even if rejected. >> >> [Med] This is deployment-specific. For example, if conflict handling requires >> "notify an administrator for validation", there is no point to report again. >> >>> >>> Nits/editorial comments: >>> >>> 1. In figure 2 missing HTTP layer? >> >> [Med] No, that is on purpose. RESTCONF (which is an HTTP-based protocol) >> layer is sufficient. >> >>> 2. In section 6.1 "If the request is missing a mandatory attribute or >>> its contains " should be "it" instead of "its" 3. >> >> [Med] Thank you for catching this. Fixed. >> >> In section 7.3 "A DOTS client >>> periodically queries ...". I did not see any text about why this is >>> done is this a common behavior? how often? 4. >> >> [Med] This is left to implementations. We don't have any solid argument to >> recommend a value. >> >> >> After figure 29 "bound to a given ACL >>> as >>> shown in Figure 28 " I think it should be 27? >> >> [Med] This should be Figure 30. Fixed. Thanks. >> >> 5. In figure 31 >>> ""pending-lifetime": 8000 ," why 8000 and not 9080 as in figure 28? >>> >> >> [Med] This is because pending-lifetime was decremented since the GET in >> Figure 28 was issued. >> _______________________________________________ >> Gen-art mailing list >> Gen-art@xxxxxxxx >> https://www.ietf.org/mailman/listinfo/gen-art > _______________________________________________ > Gen-art mailing list > Gen-art@xxxxxxxx > https://www.ietf.org/mailman/listinfo/gen-art
