Re: [Dots] WGLC for draft-ietf-dots-rfc8782-bis-01

Yasuaki Morita <yasuaki.morita@lepidum.co.jp> Wed, 07 October 2020 11:49 UTC

Return-Path: <yasuaki.morita@lepidum.co.jp>
X-Original-To: dots@ietfa.amsl.com
Delivered-To: dots@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAD243A0A7D for <dots@ietfa.amsl.com>; Wed, 7 Oct 2020 04:49:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, 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=lepidum-co-jp.20150623.gappssmtp.com
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 yAml-9ZqJlcA for <dots@ietfa.amsl.com>; Wed, 7 Oct 2020 04:49:47 -0700 (PDT)
Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 642123A0A80 for <dots@ietf.org>; Wed, 7 Oct 2020 04:49:43 -0700 (PDT)
Received: by mail-lf1-x134.google.com with SMTP id b22so1893804lfs.13 for <dots@ietf.org>; Wed, 07 Oct 2020 04:49:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lepidum-co-jp.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=wCEI/Xnmt2pGliGAmYGMfiNn1qLPkB6BoM0dwq+UHKo=; b=dBDbGXvksufqdkQX9WlKFjCMJWLnEYdQTYQ5m///aJ5z5NaOqxpb+mnvclbaK1TkbY kXtc3QC2UfMuqpD1WhUVt6f08qWcAvvE0hGjXDVoBSHvOzmMWJOuB2aPoRQcB81fHuJ9 vUdAuqqYGrIvUU5Dh5TEP5/F5vLjvDp/32YXNxh7RccTZV6pMQd6YizIAneLD6zkd98A VYjY+fWH4E1bE1AfULuVpJsvXh3pn6qj3F+5BupO+c+led81aHpMpH5/MbG08fQxMWRn r/5dSl4W2uqAcq1epHG8Co/uxHQhN5iwioUoXmWcmZkDqGUaFCJF+LuSyZdRm/kKQnSE 5KIg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=wCEI/Xnmt2pGliGAmYGMfiNn1qLPkB6BoM0dwq+UHKo=; b=BLZrsJFGIEkwoH3OffG2v3zXwiFA8ydDWQ5EUN+4/S4+yHINjdt4l2VBh7Ch9NbaTx CwoAsxWBrMDyELeFG6BkxvkTCUT7nuFvKSKoyMi4zNCWN2awpCeH9hIdbQX8n9mDwJcO 3UDKKAzryNj67sZ7n+uYT9dICn3ATU+2EZd7pl4Gy8+LOVx7NrQbH9PFIxZA1FpZl3DW aPpqPIEUXdaVYA68oh71YLvc1MC4J5KklaMVFQje8AXPM2i1T7D5OkNmdxNAfJUQYddf Rpul67s6YZmR8Es7JWhNdRvGDmfHk57LtaR7yRRE6F+AMDf2FToaM2yS44tuK04513y7 loGA==
X-Gm-Message-State: AOAM533Fw+vYhXd774/xT37bFgFJD7JSVKHSIHf053t6NrlRZO7eVuYB +OTnQkF5b98Yt7XXDkyEdiAug7aw03u20gO9ROsf4w==
X-Google-Smtp-Source: ABdhPJyZ5fOV7+y7+d+7Q+z6WASZbloBpBad7+9Kd3Yn0xZshOZq0cNSWMbs5nQYbKeecPOMMpJRiZ/+3BZa6cOo2ws=
X-Received: by 2002:a19:771d:: with SMTP id s29mr752619lfc.521.1602071381203; Wed, 07 Oct 2020 04:49:41 -0700 (PDT)
MIME-Version: 1.0
References: <14ca01d69bd5$dbf0d0a0$93d271e0$@smyslov.net> <CAFDrJwkTPz7xHHxjOGk66XFJsgh=e0Zhri+4rXnPt7WQT_icBA@mail.gmail.com> <14948_1601988535_5F7C67B7_14948_426_3_787AE7BB302AE849A7480A190F8B93303154DCDC@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <CAFDrJw=D1+eqLTfF=y_sbr0eS=2B7d3SmVa-fczoShn18WtWHQ@mail.gmail.com> <17820_1602051842_5F7D5F02_17820_303_1_787AE7BB302AE849A7480A190F8B93303154E25F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <17820_1602051842_5F7D5F02_17820_303_1_787AE7BB302AE849A7480A190F8B93303154E25F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
From: Yasuaki Morita <yasuaki.morita@lepidum.co.jp>
Date: Wed, 07 Oct 2020 11:49:30 +0000
Message-ID: <CAFDrJwnc8uu0VkWcytpfR8Am1Rv5Z=kYjEnwpmdJKmd_rV8CrA@mail.gmail.com>
To: mohamed.boucadair@orange.com
Cc: Valery Smyslov <valery@smyslov.net>, "dots@ietf.org" <dots@ietf.org>, "dots-chairs@ietf.org" <dots-chairs@ietf.org>, "draft-ietf-dots-rfc8782-bis@ietf.org" <draft-ietf-dots-rfc8782-bis@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/jtqDMPjw7-jKg1xMrOLZUQ13YsA>
Subject: Re: [Dots] WGLC for draft-ietf-dots-rfc8782-bis-01
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <dots.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dots>, <mailto:dots-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dots/>
List-Post: <mailto:dots@ietf.org>
List-Help: <mailto:dots-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dots>, <mailto:dots-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Oct 2020 11:49:50 -0000

Hi,

> (Putting aside how the information will be used by the second client: anomaly detect among clients of the same domain(?))
> This assumes that the server maintains two mitigation requests with conflicting scopes and which are issued by distinct clients of the same domain. This is not allowed in the current spec. When such mitigations are received, is likely to maintain only one of them active.
> So even if the constraint is relaxed to echo "attack-status" by a server, only the client that communicated the parameter can access it ... but I don't see why we need to do that.

I assumed that multiple entities share and use cuid, once it is created.
Say, when one of the entities creates cuid and PUT mitigation, and
distributes its cuid and mid to the rest of them, so that they can
request GET and check the status (or attack-status),
it makes a bit of a difference regarding the presence of
"attack-status" in GET responses.

But now I understand the original use of attack-status.
I think it has been clarified in bis better than the original RFC8782.
Any doubts about ":(client-to-server)" have been resolved.

Thank you.

On Wed, 7 Oct 2020 at 06:24, <mohamed.boucadair@orange.com> wrote:
>
> Hi Yasuaki,
>
> Thank you for clarifying.
>
> > I can explain the use case but I am not sure it is meaningful.
> > Let a client send a PUT mitigation request to the server, and
> > another client program send a GET request to obtain that mitigation
> > request.
> > In this case, the latter client might get more information if the
> > GET response includes attack-status.
>
> (Putting aside how the information will be used by the second client: anomaly detect among clients of the same domain(?))
>
> This assumes that the server maintains two mitigation requests with conflicting scopes and which are issued by distinct clients of the same domain. This is not allowed in the current spec. When such mitigations are received, is likely to maintain only one of them active.
>
> So even if the constraint is relaxed to echo "attack-status" by a server, only the client that communicated the parameter can access it ... but I don't see why we need to do that.
>
> Cheers,
> Med
>
> > -----Message d'origine-----
> > De : Yasuaki Morita [mailto:yasuaki.morita@lepidum.co.jp]
> > Envoyé : mardi 6 octobre 2020 16:58
> > À : BOUCADAIR Mohamed TGI/OLN <mohamed.boucadair@orange.com>
> > Cc : Valery Smyslov <valery@smyslov.net>; dots@ietf.org; dots-
> > chairs@ietf.org; draft-ietf-dots-rfc8782-bis@ietf.org
> > Objet : Re: [Dots] WGLC for draft-ietf-dots-rfc8782-bis-01
> >
> > Hi Med
> >
> > Thank you for your reply.
> >
> > > [Med] It is mandatory in a request and an accepted mitigation
> > response, but not in a conflict response for instance.
> > > The structure applies of the mitigation independently whether this
> > a request, response, conflict, efficacy update, etc.
> >
> > I see, I understand.
> >
> > > [Med] "attack-status" is an attribute that is sent by a client to
> > share its view on the attack with the server. The server manipulates
> > "status" to report the status as seen at the server side.
> > > The server does not include the "attack-status" (received from the
> > client) in a GET.
> > >
> > > > There is no reason to restrict the server sending attack-status
> > to
> > > > the clients.
> >
> > Perhaps this is something I didn't understand correctly about the
> > use of "attack-status" in RFC8782 (not bis), which defines "attack-
> > status"
> > as the following.
> >
> >            |     +--rw attack-status?          iana-signal:attack-
> > status
> >
> > >
> > > [Med] What would be the use case if that constraint was relaxed?
> >
> > I can explain the use case but I am not sure it is meaningful.
> > Let a client send a PUT mitigation request to the server, and
> > another client program send a GET request to obtain that mitigation
> > request.
> > In this case, the latter client might get more information if the
> > GET response includes attack-status.
> >
>
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>