[Dots] draft-francois-dots-ipv6-signal-option-02: clarification

Jérôme François <jerome.francois@inria.fr> Mon, 24 July 2017 10:27 UTC

Return-Path: <jerome.francois@inria.fr>
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 BDFFF131C79 for <dots@ietfa.amsl.com>; Mon, 24 Jul 2017 03:27:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 ay_7JTzpndsG for <dots@ietfa.amsl.com>; Mon, 24 Jul 2017 03:27:56 -0700 (PDT)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 050D6131C60 for <dots@ietf.org>; Mon, 24 Jul 2017 03:27:55 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.40,406,1496095200"; d="scan'208";a="232624835"
Received: from router-testbed.loria.fr (HELO [192.168.1.182]) ([152.81.12.195]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 24 Jul 2017 12:27:53 +0200
From: Jérôme François <jerome.francois@inria.fr>
To: dots@ietf.org
Message-ID: <68c90ed4-00ce-dc0f-7576-02ecdf14431f@inria.fr>
Date: Mon, 24 Jul 2017 12:27:52 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/_jLnGdNZ59R00GUmtn07jSTNIyg>
Subject: [Dots] draft-francois-dots-ipv6-signal-option-02: clarification
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: Mon, 24 Jul 2017 10:27:59 -0000

Dear all,

Here is clarification regarding the proposition to include a repository
functionality.

To illustrate, there are three cases:
- Out-of-band signaling : the client can contact the server eventually
through a gatway without experiencing any connectivity issue
- In-band signaling - case 1: the attack degrades quality of
connectivity between the client and the server avoiding the signal to be
transmitted but the client can still send packets to given locations (at
least in an intermittent manner)
- In-band signaling - case 2: the attack completely disrupt the
connectivity, the client is fully isolated with no capacity to send any
packet.


Below the motivation of using an  auxiliary asynchronous signalling:

Out-of-band signaling: no need for auxiliary signaling mechanism

In-band signaling - Case 1: in that case, the goal is to store
persistent information about the attack where both the client and server
could connect to but not necessarily at the same time. Establishing a
direct connection between them is impossible. However the client is able
to send information to the "repository" in uncontrolled/intermitent
manner and the server as well (they are not synchronized and we need
thus an asynchronous signaling. It increase the chance of delivering the
signal).   Actually this has its ground into our original idea using
IPv6 HbH by storing signal at router level which could be delivered
afterwards. Hence, multiple repositories should be used simultaneously
by the client (preferably well distributed into the network topology).
In such a scenario, the server is still able to obtain some fresh
information (even with a bit more of delay)

In-band signaling - Case 2:  in that case, the server relies on stored
information (pro-actively set before the attack is confirmed) to trigger
mitigation.

Regarding the comment, I agree that if we consider that the server has
the capacity to store the information in a persistent manner, the
in-band signaling - case  2 scenario could be covered but not case 1.

jerome