Re: [Dots] A general question about the near source mitigation and DOTS call home mechanism:

<mohamed.boucadair@orange.com> Fri, 12 July 2019 05:24 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 50493120168; Thu, 11 Jul 2019 22:24:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level:
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 hdnasNRy-94p; Thu, 11 Jul 2019 22:24:55 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.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 AF87212011B; Thu, 11 Jul 2019 22:24:51 -0700 (PDT)
Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 45lLw13tSwz8tF9; Fri, 12 Jul 2019 07:24:49 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.26]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id 45lLw12n5NzCqjy; Fri, 12 Jul 2019 07:24:49 +0200 (CEST)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM31.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0439.000; Fri, 12 Jul 2019 07:24:49 +0200
From: mohamed.boucadair@orange.com
To: "Xialiang (Frank, Network Standard & Patent Dept)" <frank.xialiang@huawei.com>, "dots@ietf.org" <dots@ietf.org>
CC: "draft-ietf-dots-signal-call-home.authors@ietf.org" <draft-ietf-dots-signal-call-home.authors@ietf.org>, "dots-chairs@ietf.org" <dots-chairs@ietf.org>
Thread-Topic: A general question about the near source mitigation and DOTS call home mechanism:
Thread-Index: AdU4YWiV0o6ZgW1PTuq0BxDsS/XflAAD0NKQ
Date: Fri, 12 Jul 2019 05:24:49 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302EACACA3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <C02846B1344F344EB4FAA6FA7AF481F13E7C87BC@dggemm511-mbx.china.huawei.com>
In-Reply-To: <C02846B1344F344EB4FAA6FA7AF481F13E7C87BC@dggemm511-mbx.china.huawei.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.247]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93302EACACA3OPEXCAUBMA2corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/faYbKXwNsMSysoO6LbHT2OkPtzg>
Subject: Re: [Dots] A general question about the near source mitigation and DOTS call home mechanism:
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.29
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, 12 Jul 2019 05:24:57 -0000

Hi Franck,

The source information can be used in the DOTS signal channel. The I-D says the following:


   This specification extends the mitigation request defined in

   Section 4.4.1 of [I-D.ietf-dots-signal-channel<https://tools.ietf.org/html/draft-ietf-dots-signal-call-home-03#ref-I-D.ietf-dots-signal-channel>] to convey the

   attacker source prefixes and source port numbers.


     augment /ietf-signal:dots-signal/ietf-signal:message-type

             /ietf-signal:mitigation-scope/ietf-signal:scope:

       +--rw source-prefix*     inet:ip-prefix {source-signaling}?

       +--rw source-port-range* [lower-port] {source-signaling}?

       |  +--rw lower-port    inet:port-number

       |  +--rw upper-port?   inet:port-number

       +--rw source-icmp-type-range*

          |                    [lower-type] {source-signaling}?

          +--rw lower-type    uint8

          +--rw upper-type?   uint8

The attributes are optional for the DOTS signal channel:


      This is an optional attribute for the base DOTS signal channel

      operations [I-D.ietf-dots-signal-channel<https://tools.ietf.org/html/draft-ietf-dots-signal-call-home-03#ref-I-D.ietf-dots-signal-channel>].

while some of them are mandatory for the call home:


   The 'source-prefix' parameter is a mandatory attribute when the

                                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

   attack traffic information is signaled by a DOTS client in the Call

                                                                  ^^^^

   Home scenario (depicted in Figure 2).

   ^^^^

Cheers,
Med

De : Xialiang (Frank, Network Standard & Patent Dept) [mailto:frank.xialiang@huawei.com]
Envoyé : vendredi 12 juillet 2019 05:38
À : dots@ietf.org
Cc : draft-ietf-dots-signal-call-home.authors@ietf.org; dots-chairs@ietf.org
Objet : A general question about the near source mitigation and DOTS call home mechanism:

Hi all,
If I am correct, current dots call home draft include 2 main points: 1-dots server create underlay tls connection with dots client due to the dots server is located behind home gateway (more generally, DC gateway, cloud gateway, branch gateway, ...); 2-for near source mitigation, dots client should send the attack source information (address, port, ...) to dots server for its mitigation.

I am wondering why we cannot use the same attack source information of point 2 in the dots signal channel, which aims for the same goal of near source mitigation? I do see the use cases and requirements for many outbound attacks. And it also means the point 1 and 2 of signal channel call home is not necessary to be combined together always.

And should we consider the update of current signal channel WG draft, or other way?

Your comments?

B.R.
Frank