[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
- [Dots] draft-francois-dots-ipv6-signal-option-00 Jérôme François