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
