[Dots] draft-francois-dots-ipv6-signal-option-00

Jérôme François <jerome.francois@inria.fr> Fri, 16 September 2016 12:54 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 6CF6312B138 for <dots@ietfa.amsl.com>; Fri, 16 Sep 2016 05:54:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.408
X-Spam-Level:
X-Spam-Status: No, score=-8.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.508] 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 swM6WRo6lbTH for <dots@ietfa.amsl.com>; Fri, 16 Sep 2016 05:54:53 -0700 (PDT)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (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 4ADD812B0E9 for <dots@ietf.org>; Fri, 16 Sep 2016 05:54:53 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.30,344,1470693600"; d="scan'208";a="237108795"
Received: from static-176-183-206-74.ncc.abo.bbox.fr (HELO [192.168.1.17]) ([176.183.206.74]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 16 Sep 2016 14:54:51 +0200
Message-ID: <57DBEB9A.4010402@inria.fr>
Date: Fri, 16 Sep 2016 14:54:50 +0200
From: Jérôme François <jerome.francois@inria.fr>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: dots@ietf.org
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/QORP4OCNwv-RPwT4ye_yHZiukv4>
Subject: [Dots] draft-francois-dots-ipv6-signal-option-00
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.17
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: Fri, 16 Sep 2016 12:54:55 -0000

Dear all,

We'd like to present our response to the community feedback we received
after presenting our draft-francois-dots-ipv6-signal-option-00 draft in
Berlin.


1) On the use of the IPv6 Hop-by-Hop options:

We recognized that this can be an issue as it may entail some processing
overhead at the router side (also described in draft-krishnan-ipv6-hopbyhop-05).

The main issue is the unbounded number of TLV encoded attributes in the
option. In our opinion, our proposition is not particularly affected by
this threats, due the following:

   * only DOTS clients may craft such an option. Therefore, with a
previously defined policy set, other hosts trying to use it should be
easily detected and drop at the first router they will encounter.

   * we assume that there is a trust relationships between dots agents
and the network (remaining that we mainly focus on the intra-domain use
case). If not, additional techniques (rate / size limiting) can be
applied on the IPv6 packets.

   * there is some processing overhead  but (i)  not all routers need to
process them (a sort of trade-off between reaching the
server and the overhead) and (ii) this overhead would be insignificant
regarding the DDoS impact, which in our mind make this more acceptable.


2) The option encodes the same information that the client sends to the
server but the main difference is that the propagation will be done in
an epidemic manner (i.e. not taking the regular forwarding path, which
might even been under attack).

One one hand, you can restrict the  epidemic propagation towards a
certain direction to be sure that the signaling is not going to a
direction too far from the sever. On the other hand, we recommend in our
draft to use all possible paths in the very first instants of the attack
to have more chance to reach the client or a DOTS gateway. In brief, our
proposal is intended to be used in intra-domain scenario with
distributed gateways
rather than only relying only a single DOTS server.

We will take those into account in our draft as well as any additional
feedback we'll reveive on the ML.

We'll also introduce our draft on the ipv6 ML for advice and feedback.
We have also started first experiments with running code.

Best regards,
Jérôme