Re: [Dots] WGLC signal draft: Conflict information conflicts

<mohamed.boucadair@orange.com> Thu, 16 August 2018 07:54 UTC

Return-Path: <mohamed.boucadair@orange.com>
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 7A16B131000 for <dots@ietfa.amsl.com>; Thu, 16 Aug 2018 00:54:53 -0700 (PDT)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 EdRIoEUrtP7G for <dots@ietfa.amsl.com>; Thu, 16 Aug 2018 00:54:50 -0700 (PDT)
Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AE5C130F07 for <dots@ietf.org>; Thu, 16 Aug 2018 00:54:50 -0700 (PDT)
Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 41rdsM6z6xz7tbT; Thu, 16 Aug 2018 09:54:47 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.24]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 41rdsM5xLszBrLd; Thu, 16 Aug 2018 09:54:47 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7D.corporate.adroot.infra.ftgroup ([fe80::9044:c5ee:4dd2:4f16%19]) with mapi id 14.03.0408.000; Thu, 16 Aug 2018 09:54:47 +0200
From: mohamed.boucadair@orange.com
To: Jon Shallow <supjps-ietf@jpshallow.com>, "dots@ietf.org" <dots@ietf.org>
Thread-Topic: [Dots] WGLC signal draft: Conflict information conflicts
Thread-Index: AdQ1MhVo+Ls9fJ86SFKNTBk529RlrQAAv6yw
Date: Thu, 16 Aug 2018 07:54:46 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302DFAAAA3@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <019701d43532$15826110$40872330$@jpshallow.com>
In-Reply-To: <019701d43532$15826110$40872330$@jpshallow.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.6]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93302DFAAAA3OPEXCLILMA3corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/kBCxvT8xagkpjyse18JG4IKGhY8>
Subject: Re: [Dots] WGLC signal draft: Conflict information conflicts
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.27
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: Thu, 16 Aug 2018 07:55:02 -0000

Hi Jon,

Please see inline.

Cheers,
Med

De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow
Envoyé : jeudi 16 août 2018 09:24
À : dots@ietf.org
Objet : [Dots] WGLC signal draft: Conflict information conflicts

Hi there,

Issue A.

It is undefined as to how to tell the DOTS client that 4.09 conflict for a "cuid" has occurred as in

4.1.1 Request Mitigation
      DOTS servers MUST return 4.09 (Conflict) error code to a DOTS peer
      to notify that the 'cuid' is already in-use by another DOTS
      client.  Upon receipt of that error code, a new 'cuid' MUST be
      generated by the DOTS peer.

The DOTS client generates a new "cuid" for every 4.09 ???

[Med] Isn't this covered by this text?

         3:  CUID Collision.  This code is returned when a DOTS client
             uses a 'cuid' that is already used by another DOTS client.
             This code is an indication that the request has been
             rejected and a new request with a new 'cuid' is to be re-
             sent by the DOTS client.

I think we need a new conflict status

         4:  DOTS server has detected the presented 'cuid' is already in use by another DOTS client.  A new 'cuid' needs to be generated.

And text updated

      DOTS servers MUST return 4.09 (Conflict) error code to a DOTS peer
      to notify that the 'cuid' is already in-use by another DOTS
      client, along with a conflict-status of 4.  Upon receipt of that error code and conflict-status, a new 'cuid' MUST be
      generated by the DOTS peer.

[Med] We do already have the following:


"The response includes enough information for a DOTS

   client to recognize the source of the conflict as described below:"



which means that cuid collision will be included in such case.

Issue B.

We have confusion over the use of the word "different" for "different DOTS client" - this was previously brought up but got lost on the way.  The following is (correctly) for the same client

   For example, if the DOTS server receives a mitigation request which
   overlaps with an existing mitigation with a higher numeric 'mid', the
   DOTS server rejects the request by returning 4.09 (Conflict) to the
   DOTS client.  The response includes enough information for a DOTS
   client to recognize the source of the conflict as described below:

[Med] This text is about requests from the same client.

Yet we later have (which really should be corrected)

[Med] This is about conflicts involving multiple clients. What is the issue with this text?

   If the request is conflicting with an existing mitigation request
   from a different DOTS client, the DOTS server may return 2.01
   (Created) or 4.09 (Conflict) to the requesting DOTS client.  If the
   DOTS server decides to maintain the new mitigation request, the DOTS
   server returns 2.01 (Created) to the requesting DOTS client.  If the
   DOTS server decides to reject the new mitigation request, the DOTS
   server returns 4.09 (Conflict) to the requesting DOTS client.  For
   both 2.01 (Created) and 4.09 (Conflict) responses, the response
   includes enough information for a DOTS client to recognize the source
   of the conflict as described below:

   conflict-information:  Indicates that a mitigation request is
      conflicting with another mitigation request(s) from other DOTS
      client(s).  This optional attribute has the following structure:

      conflict-status:  Indicates the status of a conflicting mitigation
         request.  The following values are defined:

         1:  DOTS server has detected conflicting mitigation requests
             from different DOTS clients.  This mitigation request is
             currently inactive until the conflicts are resolved.
             Another mitigation request is active.

         2:  DOTS server has detected conflicting mitigation requests
             from different DOTS clients.  This mitigation request is
             currently active.

         3:  DOTS server has detected conflicting mitigation requests
             from different DOTS clients.  All conflicting mitigation
             requests are inactive.

Issue C.

'mid' is missing from the second definition of conflict-scope as in

      conflict-scope:  Indicates the conflict scope.  It may include a
         list of IP addresses, a list of prefixes, a list of port
         numbers, a list of target protocols, a list of FQDNs, a list of
         URIs, a list of alias-names, or references to conflicting ACLs.

[Med] It is not. mid is only required for conflicts which belong to the same clients. When multiple clients are involved, mid is not needed.

Regards

Jon