Re: [Dots] [Gen-art] Genart last call review of draft-ietf-dots-data-channel-27

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@orange.com wrote:
> 
> Re-,
> 
> I hear you, 
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : Roni Even (A) [mailto:roni.even@huawei.com]
>> Envoyé : jeudi 7 mars 2019 13:29
>> À : BOUCADAIR Mohamed TGI/OLN; Datatracker on behalf of Roni Even; gen-
>> art@ietf.org
>> Cc : draft-ietf-dots-data-channel.all@ietf.org; ietf@ietf.org; dots@ietf.org
>> 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@ietf.org] On Behalf Of
>> mohamed.boucadair@orange.com
>> Sent: Thursday, March 07, 2019 1:57 PM
>> To: Datatracker on behalf of Roni Even; gen-art@ietf.org
>> Cc: draft-ietf-dots-data-channel.all@ietf.org; ietf@ietf.org; dots@ietf.org
>> 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@ietf.org]
>>> Envoyé : jeudi 7 mars 2019 11:21 À : gen-art@ietf.org Cc :
>>> draft-ietf-dots-data-channel.all@ietf.org; ietf@ietf.org;
>>> dots@ietf.org 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@ietf.org
>> https://www.ietf.org/mailman/listinfo/gen-art
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art