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

From: Datatracker on behalf of Roni Even <[email-masked]>
Date: Thu, 07 Mar 2019 02:21:03 -0800

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. I
think that this can be considered as an attack and should be mentioned in the
security section. I also think that such a conflict must be reported to the
administrator even if rejected.

Nits/editorial comments:

1. In figure 2 missing HTTP layer?
2. In section 6.1 "If the request is missing a mandatory attribute or its
contains " should be "it" instead of "its" 3. 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. After figure 29 "bound to a given ACL as
shown in Figure 28 " I think it should be 27? 5. In figure 31
""pending-lifetime": 8000 ," why 8000 and not 9080 as in figure 28?

---

From: <[email-masked]>
Date: Thu, 7 Mar 2019 11:56:46 +0000

Hi Roni, 

Thank you for the review. 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Datatracker on behalf of Roni Even [mailto:[email-masked]]
> Envoyé : jeudi 7 mars 2019 11:21
> À : [email-masked]
> Cc : [email-masked]; [email-masked]; [email-masked]
> Objet : Genart last call review of draft-ietf-dots-data-channel-27
> 
> Reviewer: Roni Even
> 1. In section 2 there is a discussion about conflicting filtering requests. 

[Med] I guess you meant section 3.

I
> 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. 

> 1. In figure 2 missing HTTP layer?

[Med] No, that is on purpose. RESTCONF (which is an HTTP-based protocol) layer is sufficient.    

> contains " should be "it" instead of "its" 3.

[Med] Thank you for catching this. Fixed.

 In section 7.3 "A DOTS client
> 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.

---

From: "Roni Even (A)" <[email-masked]>
Date: Thu, 7 Mar 2019 12:28:48 +0000

Hi Med,
Thanks I am OK with your response only open one

[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. 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.
Roni

-----Original Message-----
From: Gen-art [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, March 07, 2019 1:57 PM
To: Datatracker on behalf of Roni Even; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Gen-art] Genart last call review of draft-ietf-dots-data-channel-27

Hi Roni, 

Please see inline.

Cheers,
Med

> Envoyé : jeudi 7 mars 2019 11:21 À : [email-masked] Cc : 
> [email-masked]; [email-masked]; 
> [email-masked] Objet : Genart last call review of 
> draft-ietf-dots-data-channel-27
> 
> Reviewer: Roni Even
> 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.
> 
> The document is ready with nits and one minor issue for publication as 
> a standard track RFC
> 
> Major issues:
> 
> Minor issues:
> 

I
> think that this can be considered as an attack and should be mentioned 
> in the security section.

> 2. In section 6.1 "If the request is missing a mandatory attribute or 
> its contains " should be "it" instead of "its" 3.

> periodically queries  ...".  I did not see any text about why this is 
> done is this a common behavior? how often? 4.

 5. In figure 31

[Med] This is because pending-lifetime was decremented since the GET in Figure 28 was issued.   
_______________________________________________
Gen-art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art

---

From: <[email-masked]>
Date: Thu, 7 Mar 2019 13:04:12 +0000

Re-,

I hear you, 
 
Cheers,
Med

> De : Roni Even (A) [mailto:[email-masked]]
> Envoyé : jeudi 7 mars 2019 13:29
> À : BOUCADAIR Mohamed TGI/OLN; Datatracker on behalf of Roni Even; gen-
> [email-masked]
> Objet : RE: Genart last call review of draft-ietf-dots-data-channel-27
> 
> Hi Med,
> [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  ...

> [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.
> 
> 
> [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:
> >