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

<mohamed.boucadair@orange.com> Thu, 07 March 2019 13:04 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C638F131323; Thu, 7 Mar 2019 05:04:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1_937jG4x70j; Thu, 7 Mar 2019 05:04:14 -0800 (PST)
Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2728131382; Thu, 7 Mar 2019 05:04:13 -0800 (PST)
Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 44FW6h3LlWzFqTl; Thu, 7 Mar 2019 14:04:12 +0100 (CET)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.92]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id 44FW6h2Zd1zCqk9; Thu, 7 Mar 2019 14:04:12 +0100 (CET)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM34.corporate.adroot.infra.ftgroup ([fe80::7873:1668:636f:52c%21]) with mapi id 14.03.0439.000; Thu, 7 Mar 2019 14:04:12 +0100
From: <mohamed.boucadair@orange.com>
To: "Roni Even (A)" <roni.even@huawei.com>, Datatracker on behalf of Roni Even <noreply@ietf.org>, "gen-art@ietf.org" <gen-art@ietf.org>
CC: "draft-ietf-dots-data-channel.all@ietf.org" <draft-ietf-dots-data-channel.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "dots@ietf.org" <dots@ietf.org>
Thread-Topic: Genart last call review of draft-ietf-dots-data-channel-27
Thread-Index: AQHU1M96HszzcMciF0iwB2qD1pPbmaX/+XRQgAAeAMCAAAhoMA==
Date: Thu, 7 Mar 2019 13:04:12 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302EA353C8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <155195406376.15866.11400149967812730230@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA352D6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <6E58094ECC8D8344914996DAD28F1CCD18CB9C0D@dggemm526-mbx.china.huawei.com>
In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD18CB9C0D@dggemm526-mbx.china.huawei.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.245]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/RTDpfN8dGUTi0N4TrwYVoUqacqc>
Subject: Re: [Gen-art] Genart last call review of draft-ietf-dots-data-channel-27
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Mar 2019 13:04:17 -0000

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