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

Alissa Cooper <alissa@cooperw.in> Thu, 02 May 2019 14:27 UTC

Return-Path: <alissa@cooperw.in>
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 907E7120045; Thu, 2 May 2019 07:27:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=De37U9Rx; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=3QQBXs6H
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 FxzWQWJTZWdF; Thu, 2 May 2019 07:27:49 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6D921203B7; Thu, 2 May 2019 07:27:34 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id DFF8224032; Thu, 2 May 2019 10:27:33 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Thu, 02 May 2019 10:27:33 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=G A4JF7/yINr0sg5EHPZPIR9swo8cj4ksah6I44YK1bI=; b=De37U9Rxq0mkrHQfI dGW7Gsp8m5HAaSu3cG58GbNyMEBfKqg6BqlWBcoQds3f/VsMhTAbP18AnQBsriqb zdoMx15bB+In3TDudFhLz0nVSLwEJ2s6/Q0BxLleiSFR0WhDj1GuGNWf/GW/f/H8 lcu0Mn2a+8FjQAuBZAmOui491O1WYi1XMYzyDZMkZ61CwwWFhirZ+k0LirSq/n8E 57wOlN11eZWld/xiIIVFZcbSsS+qZingxduAcTa3I4/jZOIn7O6Z4RqV+d/uFzZx lz0tA1VyS8K4wgflgh246uK4dBXe/9pusAboeGwcv4+LKMwVLgw+QrUX2fnv4ziK X5JZw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=GA4JF7/yINr0sg5EHPZPIR9swo8cj4ksah6I44YK1 bI=; b=3QQBXs6H/QmL1LBYgtiRAG3EaqHvjNnoycE8pMOz20wjV1WwQ0EIgf8Kp Ilqla0bWuTDqoYyUiUhGlPbOjUbxAFcqC2i2GV5nRwkreRwvkWwDWUTylfv8GlLS O4PrFATnjQF/DkP85byvkBJllPkHnI7LpzuFcpdJL6hjeg+BmdgGofX5NmZUOAPk y4C1XTXpM0uXJpO6iXniRB/Fs8A8RJnxMActfdc1SjxrQ+GtcoZyR1d/eJSo8RmM hKmex7A8IJZ7IP+fQQKr1tS5do98sPwP+faUxIWqmlHa0Nb67KWPiRSPwB4Bc6Se nCFQIkM1k9zt6N+t3CUB0lCrhkZnQ==
X-ME-Sender: <xms:Vf7KXITaJZWbF12VQREJm4KVz_ryX83CCfZG2xH3i_RrMuRMp7bmVg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrieelgdejlecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeetlhhishhs rgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecukfhppeduje efrdefkedruddujedrleegnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhishhsrges tghoohhpvghrfidrihhnnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:Vf7KXOg9SQpquWznqm4I1y1O2vUTKNd4nn5ufJALFMvJh6RDYoIcZw> <xmx:Vf7KXEjrTLskkWY9aU3viQnnYIP98YousUoaFv6TfTUXn2IJUYW9Kw> <xmx:Vf7KXOZ0nZPgo_aj3yqI8ZBQ_fNgTBZW-HPn0vcWYhOZqq_WySXnCA> <xmx:Vf7KXC2wop9Eqbt3WqwqqZ5gS49QjQ9Icq-kKGkajhEi6_o3hLlz4g>
Received: from rtp-alcoop-nitro5.cisco.com (unknown [173.38.117.94]) by mail.messagingengine.com (Postfix) with ESMTPA id 8236B103D2; Thu, 2 May 2019 10:27:32 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA353C8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Date: Thu, 2 May 2019 10:27:32 -0400
Cc: Datatracker on behalf of Roni Even <noreply@ietf.org>, "gen-art@ietf.org" <gen-art@ietf.org>, "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>
Content-Transfer-Encoding: quoted-printable
Message-Id: <DAA0E5B6-7928-42A3-B591-E6C8FE484E9D@cooperw.in>
References: <155195406376.15866.11400149967812730230@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA352D6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <6E58094ECC8D8344914996DAD28F1CCD18CB9C0D@dggemm526-mbx.china.huawei.com> <787AE7BB302AE849A7480A190F8B93302EA353C8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
To: mohamed.boucadair@orange.com, "Roni Even (A)" <roni.even@huawei.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/0wOR7Q--xcXT8cl4jMEbIrQfrw4>
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, 02 May 2019 14:27:52 -0000

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