[Dots] OP-005: draft-ietf-dots-requirements

<mohamed.boucadair@orange.com> Tue, 02 May 2017 07:45 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 B44431293D8 for <dots@ietfa.amsl.com>; Tue, 2 May 2017 00:45:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.72
X-Spam-Level:
X-Spam-Status: No, score=-0.72 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 0sPf5se9hDyu for <dots@ietfa.amsl.com>; Tue, 2 May 2017 00:45:04 -0700 (PDT)
Received: from relais-inet.orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CA6212EBB2 for <dots@ietf.org>; Tue, 2 May 2017 00:40:01 -0700 (PDT)
Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 72FB6600F9; Tue, 2 May 2017 09:39:59 +0200 (CEST)
Received: from Exchangemail-eme3.itn.ftgroup (unknown [xx.xx.50.25]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 5178840082; Tue, 2 May 2017 09:39:59 +0200 (CEST)
Received: from OPEXCNORMAD.corporate.adroot.infra.ftgroup ([fe80::f1a0:3c6b:bc7b:3aaf]) by OPEXCNORM4C.corporate.adroot.infra.ftgroup ([fe80::347e:851c:671b:3eed%21]) with mapi id 14.03.0339.000; Tue, 2 May 2017 09:39:59 +0200
From: mohamed.boucadair@orange.com
To: "Mortensen, Andrew" <amortensen@arbor.net>
CC: "dots@ietf.org" <dots@ietf.org>
Thread-Topic: OP-005: draft-ietf-dots-requirements
Thread-Index: AdLDF0ujzjgX1+CaSLuJv7de+fVvQg==
Date: Tue, 02 May 2017 07:39:58 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009E5F407@OPEXCNORMAD.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.5]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933009E5F407OPEXCNORMADcorp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/3MvOMakIZq6dEIr6Uv6T9bnACcY>
Subject: [Dots] OP-005: draft-ietf-dots-requirements
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 02 May 2017 07:45:07 -0000

Hi Andrew,

Below some comments about this text:


      DOTS clients SHOULD include a mitigation lifetime in all

      mitigation requests.  If a DOTS client does not include a

      mitigation lifetime in requests for help sent to the DOTS server,

      the DOTS server will use a reasonable default as defined by the

      protocol.


*         I suggest to change SHOULD to MUST so that clients are encouraged to always set a lifetime. Systematically setting (finite) lifetimes will help removing stale state entries.

*         The text can indicate that DOTS clients MAY set that lifetime to infinite but they MUST be prepared that infinite lifetimes may be discarded by the DOTS server.

"DOTS servers MAY refuse mitigations with
      indefinite lifetimes, for policy reasons.  The reasons themselves
      are out of scope for this document, but MUST be included in the
      mitigation rejection message from the server, per OP-004."

Should the text be updated to include the following:

*         DOTS clients should cache the maximum mitigation returned by the DOTS server for use in subsequent DOTS mitigation requests destined to that server? Doing so allows to offload the server by systematically returning an error message if the proposed lifetime is not honored.

*         DOTS servers should be configurable with a maximum mitigation lifetime. This configuration parameter can be global configuration, per-network, per DOTS client, ..

Cheers,
Med