From nobody Fri Sep 4 13:38:30 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4C01AC423 for ; Fri, 4 Sep 2015 13:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 rKIM9f9ziKED for ; Fri, 4 Sep 2015 13:38:26 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D2E81AC42A for ; Fri, 4 Sep 2015 13:38:24 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CAV64443; Fri, 04 Sep 2015 20:38:22 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 4 Sep 2015 21:38:21 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0235.001; Fri, 4 Sep 2015 13:38:20 -0700 From: Linda Dunbar To: Roland Dobbins , "dots@ietf.org" Thread-Topic: wht are the "good reasons" to oppose "telemetry used for detection/classification/traceback of DDoS attacks" Thread-Index: AQHQ51GirKLP2OunGU+EcANgo357EQ== Date: Fri, 4 Sep 2015 20:38:19 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657D21479@dfweml701-chm> References: <359EC4B99E040048A7131E0F4E113AFCD94F1C56@marathon> <55D01F5E.4070009@gondrom.org> <55DDA4A9.3050603@inria.fr> <8775DC11-7FE3-4A02-89EE-E6BDAC6A1C13@arbor.net> In-Reply-To: <8775DC11-7FE3-4A02-89EE-E6BDAC6A1C13@arbor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.192] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Dots] wht are the "good reasons" to oppose "telemetry used for detection/classification/traceback of DDoS attacks" X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2015 20:38:28 -0000 Roland,=20 Can you elaborate the "good reasons" for opposing "telemetry used for the d= etection/classification/traceback of DDoS attacks"?=20 Thank you very much,=20 Linda Dunbar -----Original Message----- From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Roland Dobbins There are very good reasons to oppose scope-creep of this group into the ar= ena of general telemetry used for the detection/classification/traceback of= DDoS attacks, and very good reasons to maintain its focus on a signaling m= ethodology for requesting DDoS mitigation services, which has the beneficia= l side-effect of making the provisioning of said DDoS mitigation services m= ore automated. ----------------------------------- Roland Dobbins _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Fri Sep 4 14:14:56 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52CC81AD1EC for ; Fri, 4 Sep 2015 14:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 rfivhHY81PQK for ; Fri, 4 Sep 2015 14:14:49 -0700 (PDT) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43C571ACEE4 for ; Fri, 4 Sep 2015 14:10:43 -0700 (PDT) Received: by ykei199 with SMTP id i199so33131443yke.0 for ; Fri, 04 Sep 2015 14:10:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=+Vmr/NXvdkCN0083q7KSuj+8F2vOsPMDF4T0CTyvEqA=; b=go1n+I4DUIEOCxZPKiHCPjVNXbTAV5BSWnRIiRoryo3y9ywczFfbpGp0+WNaCKpYuW uXuvfQDLpBT4g6/ZUiuPhZ2TWmGzDtdbIbnV0g1kgj6DYByArMfcAL0T30LUovjIN8fc u3YAHk6wzCpUrGjQ+xFlKdzfMeLvK/gsfK89+BjgSIg7iGtra7Y63ARbxk0IApBNHIbD gl5rJz+zXyquqCGmVytK+uDuFOdoJWuH89+POTbaJJkAtd4xlT066ZLytxqyEQP85E17 pYKoRV0lgMN4aZQYETwbf+pvN7O8ECX0oC8ln22OiZfIowAwY3wTgazt0EBXtOWnMsF0 obcA== MIME-Version: 1.0 X-Received: by 10.170.150.133 with SMTP id r127mr6728645ykc.52.1441401042574; Fri, 04 Sep 2015 14:10:42 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.13.237.135 with HTTP; Fri, 4 Sep 2015 14:10:42 -0700 (PDT) In-Reply-To: <55CB494A.9020706@mti-systems.com> References: <55CB494A.9020706@mti-systems.com> Date: Fri, 4 Sep 2015 17:10:42 -0400 X-Google-Sender-Auth: 4IQVavpDlC4VNoxQDgs3922Ah_o Message-ID: From: Christopher Morrow To: Wesley Eddy Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "gclark mti-systems.com" , "dots@ietf.org" , Justin Dailey Subject: Re: [Dots] use of SDN for DDoS mitigation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2015 21:14:54 -0000 On Wed, Aug 12, 2015 at 9:25 AM, Wesley Eddy wrote: > This is not strictly within the scope of the DOTS charter, but > because it's related to DDoS mitigation, we thought it might > be of interest to the DOTS list. > > This draft was posted to the SDNRG, and discusses use of OpenFlow > interdomain, for delegating control of ISP network filtering to > customers: Folk might consider looking at the prior-art in this arena... specifically N-Layer's use of flow-spec from customers, and the fairly well published failure modes of same. 'Let your customer traffic engineer your network!' (no, don't do that) 'Let your customer consume valuable resources on devices in your network to which they have no ideas about limits of' (no, don't do that) > https://datatracker.ietf.org/doc/draft-eddy-sdnrg-customer-filters/ > > We're eager to hear your comments, criticisms, and questions, but I > assume that the DOTS chairs would like this to be offlist (or on the > SDNRG list) since it is not really in-scope for DOTS and might be a > distraction from the chartered work. > > -- > Wes Eddy > MTI Systems > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Fri Sep 4 14:33:53 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FCA31B2D9C for ; Fri, 4 Sep 2015 14:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 R-VVlLLTwPqM for ; Fri, 4 Sep 2015 14:33:43 -0700 (PDT) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B31091B2D78 for ; Fri, 4 Sep 2015 14:33:43 -0700 (PDT) Received: by ykdg206 with SMTP id g206so33587003ykd.1 for ; Fri, 04 Sep 2015 14:33:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=cZeIxNCMj5em5ebpyMXr2ShU1Gu09VeiKHNoWag5Q7U=; b=w/y5mdmZ+KBvCt2OZYJfB4dB2lgJzn6jWdbdwZxluKka4fL3UeqYzzncl5RGG4SLvX SWguqDdEGELZBYRriMtz8j9Ct9dDm+tuFLfkDkyupN8+1YWJP5soW5PFEAJCwHFj8rBr 2FdfR6jYksC3p63EeHaRqmlAJJLWhUQ4SNlHybaFyszajfuyExmap9obhX1cOY7KPjz2 N5GWtfuNLbFrJ6lzD81IkIqO1KU4iJTS5MIx/YJkt/eeN3ALFPV7yGhXPar0uyo21xy5 tj4boivHy61mK03oYUqkejI7CfE9XVi3ff0GpniDb6W4GpEXHvTn/ijv8ZgrVJq2/JfP D7PA== MIME-Version: 1.0 X-Received: by 10.129.4.132 with SMTP id 126mr6842870ywe.138.1441402422986; Fri, 04 Sep 2015 14:33:42 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.13.237.135 with HTTP; Fri, 4 Sep 2015 14:33:42 -0700 (PDT) In-Reply-To: <55DF1EB7.9000703@cisco.com> References: <359EC4B99E040048A7131E0F4E113AFCD94F1C56@marathon> <55D01F5E.4070009@gondrom.org> <55DDA4A9.3050603@inria.fr> <8775DC11-7FE3-4A02-89EE-E6BDAC6A1C13@arbor.net> <55DF1EB7.9000703@cisco.com> Date: Fri, 4 Sep 2015 17:33:42 -0400 X-Google-Sender-Auth: vRlFPbEIWHfY2wourfy4DPsL9Xk Message-ID: From: Christopher Morrow To: Flemming Andreasen Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Roland Dobbins , dots@ietf.org Subject: Re: [Dots] DOTS: next steps - call for editor volunteers for use case draft and requirements draft X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2015 21:33:51 -0000 On Thu, Aug 27, 2015 at 10:29 AM, Flemming Andreasen wrote: > On 8/27/15 3:12 AM, Roland Dobbins wrote: >> >> On 27 Aug 2015, at 17:01, Xialiang (Frank) wrote: >> >>> which includes the DDoS related telemetry information as its part, >> >> >> The DDoS telemetry referred to in the WG charter is a starting point for >> DOTS signaling - the telemetry itself is out-of-scope for this WG. > > Can you clarify the distinction you are making here ? The charter explicitly > talks about DDoS related telemetry and based on previous discussions, It was > my understanding that we wanted to provide information about an ongoing > attack to an upstream entity to enable a more accurate and rapid response by > that upstream entity. perhaps part of the problem here is related to 'provide information about an ongoing attack to an upstream entity....' what information? pps? destination ip/network? src-addresses? port/protocols used? I suspect that the upstream provider can very quickly determine the problem in almost all cases, probably better than the initial reporter... and I'm not sure it's particularly useful to send upstream much more than: "I am seeing an attack to destination X port/protocol Y/Z" you will want to ask the upstream: "do not disable access" probably... and as to the charter, the charter can always be changed... or that work item can wait until the decision is that 'this work is not relevant anymore'... it'd be best, I think, to focus on the basic dots protocol work and leave the telemetry for a later decision. > >> If the language needs to be massaged to reflect this, we can do it. >> > I don't think we can just change the charter, however we should make sure to > capture the outcome of this thread as part of the overall requirements. charters always change, it's not written in stone by aliens. From nobody Fri Sep 4 14:34:51 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06D921B2E0C for ; Fri, 4 Sep 2015 14:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 tcv00QuvrUH2 for ; Fri, 4 Sep 2015 14:34:46 -0700 (PDT) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0225B1B2E05 for ; Fri, 4 Sep 2015 14:34:46 -0700 (PDT) Received: by ykek143 with SMTP id k143so33661801yke.2 for ; Fri, 04 Sep 2015 14:34:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=JCw03TvU6WFEiiDBev9movqo39S9EUAxH4gP9JOpTrU=; b=OXDXgdEjgNy6Im9wPjbxsjKW1fAkWZbdlpSfrpzA2KDbgusB+8Htw10wMrHR2UslAS SQjsg1wwtNUBsMFWUZ9jfh/wSWSFO3C/AaSj8tvRtdZa4xnx+PhckpU43V+GJAl7HHSA f6ItY8bv9ye31UYwQ659mpd/6AVWAUCDlkvbyO2O0U2+VoCUrMeGlCMLgcSekALYHSIs j9KRrnxVuM7Yi6l2zQh8fPDvIO2Af1QVaUAZVIdlL4n/V3fOsHOxBGdZO+kQEVhmQN2D fcu0LoM9jCLNQrTu6raS51sCFAcepXH8Bxzm7rVdyG/N4Vx1S7P7zOoakbNOJM+AHMpF iUSw== MIME-Version: 1.0 X-Received: by 10.129.4.132 with SMTP id 126mr6847456ywe.138.1441402485291; Fri, 04 Sep 2015 14:34:45 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.13.237.135 with HTTP; Fri, 4 Sep 2015 14:34:45 -0700 (PDT) In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657D21479@dfweml701-chm> References: <359EC4B99E040048A7131E0F4E113AFCD94F1C56@marathon> <55D01F5E.4070009@gondrom.org> <55DDA4A9.3050603@inria.fr> <8775DC11-7FE3-4A02-89EE-E6BDAC6A1C13@arbor.net> <4A95BA014132FF49AE685FAB4B9F17F657D21479@dfweml701-chm> Date: Fri, 4 Sep 2015 17:34:45 -0400 X-Google-Sender-Auth: MRZV2QgI91LamOVohFJVwwphFQ0 Message-ID: From: Christopher Morrow To: Linda Dunbar Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Roland Dobbins , "dots@ietf.org" Subject: Re: [Dots] wht are the "good reasons" to oppose "telemetry used for detection/classification/traceback of DDoS attacks" X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2015 21:34:51 -0000 On Fri, Sep 4, 2015 at 4:38 PM, Linda Dunbar wrot= e: > Roland, > > Can you elaborate the "good reasons" for opposing "telemetry used for the= detection/classification/traceback of DDoS attacks"? > it's not clear that a customer link can tell what's really going on, so 'bad information' is worse than 'no information'... when bad things are happening. > Thank you very much, > > Linda Dunbar > > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Roland Dobbins > > > There are very good reasons to oppose scope-creep of this group into the = arena of general telemetry used for the detection/classification/traceback = of DDoS attacks, and very good reasons to maintain its focus on a signaling= methodology for requesting DDoS mitigation services, which has the benefic= ial side-effect of making the provisioning of said DDoS mitigation services= more automated. > > ----------------------------------- > Roland Dobbins > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Fri Sep 4 21:34:41 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB0E91B469A for ; Fri, 4 Sep 2015 21:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.507 X-Spam-Level: X-Spam-Status: No, score=-3.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 EV6j4bDQvcPi for ; Fri, 4 Sep 2015 21:34:39 -0700 (PDT) Received: from INFPACM004.services.comms.unsw.edu.au (smtp.unsw.edu.au [149.171.193.32]) by ietfa.amsl.com (Postfix) with ESMTP id CFDC01B4694 for ; Fri, 4 Sep 2015 21:34:38 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CQAgBfcOpV/zkaFKxdgyFUaQa9ZwEJgW0KhXkCgTQ4FAEBAQEBAQGBCoQjAQEBBAEBAWsLDAQCAQUDDQgmBAchBgEKFBECBAENBYgZAxINxQ0NR4RBAQEBAQEFAQEBAQEBAQEWBIZzhHuCT4IJMweELAWHMY4kihh0AYFtiRKKJ4c8JoIQHBaBPj4ziEWBBQEBAQ X-IPAS-Result: A2CQAgBfcOpV/zkaFKxdgyFUaQa9ZwEJgW0KhXkCgTQ4FAEBAQEBAQGBCoQjAQEBBAEBAWsLDAQCAQUDDQgmBAchBgEKFBECBAENBYgZAxINxQ0NR4RBAQEBAQEFAQEBAQEBAQEWBIZzhHuCT4IJMweELAWHMY4kihh0AYFtiRKKJ4c8JoIQHBaBPj4ziEWBBQEBAQ X-IronPort-AV: E=Sophos;i="5.17,472,1437400800"; d="scan'208";a="213160598" Received: from unknown (HELO INFPWXH004.ad.unsw.edu.au) ([172.20.26.57]) by INFPACM004.services.comms.unsw.edu.au with ESMTP; 05 Sep 2015 14:34:18 +1000 Received: from INFPWXM010.ad.unsw.edu.au ([169.254.4.30]) by INFPWXH004.ad.unsw.edu.au ([172.20.26.57]) with mapi id 14.03.0248.002; Sat, 5 Sep 2015 14:34:17 +1000 From: Xiaohong Deng To: Christopher Morrow , Linda Dunbar Thread-Topic: [Dots] wht are the "good reasons" to oppose "telemetry used for detection/classification/traceback of DDoS attacks" Thread-Index: AQHQ51Gr1oHfA2N+0EqH2NTbi9ltwp4sPMGAgAEc3AA= Date: Sat, 5 Sep 2015 04:34:17 +0000 Message-ID: References: <359EC4B99E040048A7131E0F4E113AFCD94F1C56@marathon> <55D01F5E.4070009@gondrom.org> <55DDA4A9.3050603@inria.fr> <8775DC11-7FE3-4A02-89EE-E6BDAC6A1C13@arbor.net> <4A95BA014132FF49AE685FAB4B9F17F657D21479@dfweml701-chm> In-Reply-To: Accept-Language: en-GB, en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [149.171.135.82] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Roland Dobbins , "dots@ietf.org" Subject: Re: [Dots] wht are the "good reasons" to oppose "telemetry used for detection/classification/traceback of DDoS attacks" X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Sep 2015 04:34:40 -0000 On 5/09/2015 7:34 am, "Christopher Morrow" wrote: >On Fri, Sep 4, 2015 at 4:38 PM, Linda Dunbar >wrote: >> Roland, >> >> Can you elaborate the "good reasons" for opposing "telemetry used for >>the detection/classification/traceback of DDoS attacks"? >> > >it's not clear that a customer link can tell what's really going on, What makes you think so? To our knowledge, it=B9s been already happening i= n industry.=20 DeepField, a company who does Big Data Business Intelligence for Network Operators DNSFlow, becoming the largest Cloud and Telecom Big Data provider in the Americas with coverage of more than 1/5 of all US Internet traffic. All sorts of telemetry, BGP, iBGP, AAA, and Custom datasets, in addition to basic NetFlow and Sflow they use to detect attacks and other Network anomalies.=20 Virtela( NTT acquired company), able to detecting network anomalies, application behaviour anomalies and even give predictive forecast as they claim, by using self-defined telemetry and analytics. =20 Hop Analysis, event Analysis, path paris with significant event are enabled on end-to-end visibility across multi-domain paths by collecting link telemetry, as per Narada Metrics. >so 'bad information' is worse than 'no information'... when bad things Market proved technology can not be providing =8Cbad information=B9 in my understanding. If sucessful industry use cases do not look persuasive to WG, then I=B9ve used up my 2 Cents. :-) -Xiaohong=20 >are happening. > >> Thank you very much, >> >> Linda Dunbar >> >> -----Original Message----- >> From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Roland Dobbins >> >> >> There are very good reasons to oppose scope-creep of this group into >>the arena of general telemetry used for the >>detection/classification/traceback of DDoS attacks, and very good >>reasons to maintain its focus on a signaling methodology for requesting >>DDoS mitigation services, which has the beneficial side-effect of making >>the provisioning of said DDoS mitigation services more automated. >> >> ----------------------------------- >> Roland Dobbins >> >> _______________________________________________ >> Dots mailing list >> Dots@ietf.org >> https://www.ietf.org/mailman/listinfo/dots >> >> _______________________________________________ >> Dots mailing list >> Dots@ietf.org >> https://www.ietf.org/mailman/listinfo/dots > >_______________________________________________ >Dots mailing list >Dots@ietf.org >https://www.ietf.org/mailman/listinfo/dots From nobody Fri Sep 4 22:30:35 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD4D1B4A6A for ; Fri, 4 Sep 2015 22:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 mNY6CbECgX0d for ; Fri, 4 Sep 2015 22:30:32 -0700 (PDT) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06E721B4A62 for ; Fri, 4 Sep 2015 22:30:32 -0700 (PDT) Received: by ykdg206 with SMTP id g206so39741124ykd.1 for ; Fri, 04 Sep 2015 22:30:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=1p08gXQ1ZQw75IHc0J6U0Ppqog7XM39TyTZtG+S6iYI=; b=YnYarE9ozB9aqSTCdwi5QistZoYbJYqkFFQNHLusZ81sCeewXU/A6EhE97Smpj+8ns huenDH0YmBiTZtT4l9H2+VSG69oOBlgha1ZskZAQ269GCswXF7CuIb2lyLdgVxz777iw q+ObrI5hoF08UoWDXLPjFe+BfY5bBl1h4MWtcbnBuxIFizH5lhunVZ10JHCLpj78wWQi qlTV6EzaYt8VBPMBSrYES8QRsHBH3u/JduuXa1ugwkcnsXKTm1hgPhxjgK418dRJ4Qv5 6Fv6QRsqRZkpDcsivi+aeurdzz2zkbTAu+SZB0mNs5d2IZ6ChaxLtJLIJZY/N6HfvC6t 4a9g== MIME-Version: 1.0 X-Received: by 10.129.40.144 with SMTP id o138mr8151643ywo.145.1441431031332; Fri, 04 Sep 2015 22:30:31 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.13.237.135 with HTTP; Fri, 4 Sep 2015 22:30:31 -0700 (PDT) In-Reply-To: References: <359EC4B99E040048A7131E0F4E113AFCD94F1C56@marathon> <55D01F5E.4070009@gondrom.org> <55DDA4A9.3050603@inria.fr> <8775DC11-7FE3-4A02-89EE-E6BDAC6A1C13@arbor.net> <4A95BA014132FF49AE685FAB4B9F17F657D21479@dfweml701-chm> Date: Sat, 5 Sep 2015 01:30:31 -0400 X-Google-Sender-Auth: 1Hb6QsfmP-nNCctKnHP1IYO9NUA Message-ID: From: Christopher Morrow To: Xiaohong Deng Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Roland Dobbins , "dots@ietf.org" , Linda Dunbar Subject: Re: [Dots] wht are the "good reasons" to oppose "telemetry used for detection/classification/traceback of DDoS attacks" X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Sep 2015 05:30:33 -0000 On Sat, Sep 5, 2015 at 12:34 AM, Xiaohong Deng wrote: > > > On 5/09/2015 7:34 am, "Christopher Morrow" wrot= e: > >>On Fri, Sep 4, 2015 at 4:38 PM, Linda Dunbar >>wrote: >>> Roland, >>> >>> Can you elaborate the "good reasons" for opposing "telemetry used for >>>the detection/classification/traceback of DDoS attacks"? >>> >> >>it's not clear that a customer link can tell what's really going on, > > What makes you think so? To our knowledge, it=C2=B9s been already happen= ing in > industry. having operated a very large network doing dos mitigation for customers of that network for ~8 yrs. >>so 'bad information' is worse than 'no information'... when bad things > > Market proved technology can not be providing =C5=92bad information=C2=B9= in my > understanding. certainly they can? From nobody Sat Sep 5 02:47:52 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45E801B29D6 for ; Sat, 5 Sep 2015 02:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham 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 WGJ8j7FrGDkB for ; Sat, 5 Sep 2015 02:47:50 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 270471B337F for ; Sat, 5 Sep 2015 02:47:50 -0700 (PDT) Received: by pacwi10 with SMTP id wi10so47400251pac.3 for ; Sat, 05 Sep 2015 02:47:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-type; bh=I7QLOdsKD8XviZdXpke6tO3n11fyjojyyK/Xb52Ylz0=; b=JtgZwwbeu7GEVKxKFJCSgmrdBdSZmh8De6w50tGAQWBDgygqGJ+0kT9oXmBPpjAAVs 3l8Do052s0dg74r5RwE4XcJGStXg9NHK2W6nDXWZQ+Em5en0gtuj7FMLiT/7TlyMxjAL bZ2laXN0ZrfKHX8sEGDFPpG9QvgfQ9eSrKFCo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-type; bh=I7QLOdsKD8XviZdXpke6tO3n11fyjojyyK/Xb52Ylz0=; b=YVFh12gtqRSaokJ9aeH9JpYIAGQD8gH1hfxEhLt98eiKOTpAs05xTUstQpqEeljSb0 kAlddHaQOM0tzLI0MdCDzgfzZ9XXH9LZyLBEPw4JuP47o21qMx+qvqbInvVd6C0Ow1Mv j80fDx1uSEY/b+f5TIJD5J1Z+Ddfd5kd1zq3ceFVFNw3R8xUVu6jI0cOAGFuJ8itnJYJ TVznn8gt88FIPQzEHj08qWXonfnycsbURyMMpIm3BNVlx+I5Re9HyIv9U9RqL7pYn5XU fr+n4KpKpPUGKIBc/GaebTn0QDL5bnEeOZtnh/ewvBeCkXiiTA7WwjduAfEVnu3jqUqk t6mg== X-Gm-Message-State: ALoCoQmqxQ4nfBxdVrs7SkELVY55tUy0X/UIVBa23p+8s2NG3392KVb7zUkkA6nEau6j2KQQ6Ic7 X-Received: by 10.66.122.207 with SMTP id lu15mr18952077pab.146.1441446469547; Sat, 05 Sep 2015 02:47:49 -0700 (PDT) Received: from [172.19.254.107] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id lf9sm1729318pbc.48.2015.09.05.02.47.47 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 05 Sep 2015 02:47:48 -0700 (PDT) From: "Roland Dobbins" To: dots@ietf.org Date: Sat, 05 Sep 2015 16:47:44 +0700 Message-ID: In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657D21479@dfweml701-chm> References: <359EC4B99E040048A7131E0F4E113AFCD94F1C56@marathon> <55D01F5E.4070009@gondrom.org> <55DDA4A9.3050603@inria.fr> <8775DC11-7FE3-4A02-89EE-E6BDAC6A1C13@arbor.net> <4A95BA014132FF49AE685FAB4B9F17F657D21479@dfweml701-chm> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Subject: Re: [Dots] wht are the "good reasons" to oppose "telemetry used for detection/classification/traceback of DDoS attacks" X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Sep 2015 09:47:51 -0000 On 5 Sep 2015, at 3:38, Linda Dunbar wrote: > Can you elaborate the "good reasons" for opposing "telemetry used for > the detection/classification/traceback of DDoS attacks"? I'm not opposed to the use of telemetry for that purpose - I use it every day, as do many, many others.. What I'm opposed to is this WG group getting involved in things beyond its scope and trying to redefine the world. We need to focus on *one thing* - the ability to automatically summon (with the side benefit of autoprovisioning) DDoS mitigation on demand. What's meant by the current language in the WG charter is that utilizing such telemetry in a situationally-appropriate way to determine mitigation response is something we may wish to incorporate into the DOTS signal composition process, at some point. I know this because *I'm the person who inserted that language into the charter*. This WG has no authority to define or redefine telemetry formats. We have enough to do right now in terms of defining DOTS; it makes zero sense to go haring off in the direction of messing about with telemetry formats which we have no authority to change, and which already work very well today. There is no burning need to alter IPFIX. Altering IPFIX from a telemetry standpoint is not within the remit of this group. Continuing to stray into off-charter areas is not productive and does not advance achieving the goal of this WG, which is automated signaling for DDoS mitigation assistance. We need to focus on the matter at hand. ----------------------------------- Roland Dobbins From nobody Sat Sep 5 02:52:33 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76B521B5148 for ; Sat, 5 Sep 2015 02:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham 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 K1szYDw-i5wN for ; Sat, 5 Sep 2015 02:52:31 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 490061B4ACC for ; Sat, 5 Sep 2015 02:52:31 -0700 (PDT) Received: by pacfv12 with SMTP id fv12so48445195pac.2 for ; Sat, 05 Sep 2015 02:52:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; bh=NeYhGKXCYCHUfduS3ePRhT+D6DpNYqvtQpulS61uDCc=; b=RyD57ltL+ET9PrCtAAIcuYoGAldovjjF1Q8GgbHX1tyyQtFG2RpoYZhWTWV0Awmtn6 Cv9u9IG+5nwGpTVMq47NqFcWJuc2Im3i68wIkKkCCzHG3s6cVk2CZ4idXZFY4RLXYShl L+mldSv/YuS9dF2rsMaMBcMsCvSnhsIDkVLj4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=NeYhGKXCYCHUfduS3ePRhT+D6DpNYqvtQpulS61uDCc=; b=c0WOaDSQBYfNAKmJVceHTORHgtjQ8YJZNDvOj1LaBK/ynsurvWM0yutEbVLAxav9Ac rh92eTUeITzQiqX1+I1UmQHL3zp9HgPgVW50G/iZpEXdx4X0xmT0zeK2fz6VfIkbJS8d hTCU8pmZS4CZV1rPOIGkQPFhjkzhoz+Vz5LnQsnwu6tclu2BwyFJlWZOW1SrH1NGmg0/ n/1dc3fYBI94j+Mmyu18QjQEQNAkxscLTgymMgReYKSh2ZPRekfDxLXuVNyiFT+EJ0yS 04ocl+6n1HtKvblbZY2037ma0j7Hqp6Cyfq/9inVTJAVC6C4gAjwr+gNvrfgBB+oAH20 iurA== X-Gm-Message-State: ALoCoQnPAn5Sypbtpn2B1Q7iCg/sTJ3QzBxhIa46nSelTPX85v+TuhGry2kZSGeTtxbscOCDJYcJ X-Received: by 10.66.163.227 with SMTP id yl3mr19251265pab.10.1441446750872; Sat, 05 Sep 2015 02:52:30 -0700 (PDT) Received: from [172.19.254.107] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id e4sm5271303pdd.45.2015.09.05.02.52.29 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 05 Sep 2015 02:52:30 -0700 (PDT) From: "Roland Dobbins" To: dots@ietf.org Date: Sat, 05 Sep 2015 16:52:26 +0700 Message-ID: In-Reply-To: References: <359EC4B99E040048A7131E0F4E113AFCD94F1C56@marathon> <55D01F5E.4070009@gondrom.org> <55DDA4A9.3050603@inria.fr> <8775DC11-7FE3-4A02-89EE-E6BDAC6A1C13@arbor.net> <4A95BA014132FF49AE685FAB4B9F17F657D21479@dfweml701-chm> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.2r5107) Archived-At: Subject: Re: [Dots] wht are the "good reasons" to oppose "telemetry used for detection/classification/traceback of DDoS attacks" X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Sep 2015 09:52:32 -0000 On 5 Sep 2015, at 11:34, Xiaohong Deng wrote: > What makes you think so? To our knowledge, it¹s been already > happening in > industry. Yes, it's used for this purpose every day, by networks which have that capability, . But that isn't the point. The endpoint nodes which require DDoS mitigation assistance and/or the networks on which they reside may well have no organic ability to perform telemetry generation and/or collection/analysis of same. The goal of this WG is to produce a standards-based protocol, DOTS, which can be used by anything and everything with an IP address to programmatically summon DDoS mitigation assistance; this has the additional side-benefit of aiding auto-provisioning of DDoS mitigation services. That is quite enough for us to work on, without straying into areas which are not our focus, and which are not in dire need of remediation in the first place. Let's please focus on the task at hand. ----------------------------------- Roland Dobbins From nobody Sat Sep 5 03:02:03 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FEB11B514E for ; Sat, 5 Sep 2015 03:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham 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 k0wOr7lHxTd4 for ; Sat, 5 Sep 2015 03:02:01 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42FBB1B503D for ; Sat, 5 Sep 2015 03:02:01 -0700 (PDT) Received: by pacex6 with SMTP id ex6so47715572pac.0 for ; Sat, 05 Sep 2015 03:02:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-type; bh=YTDSHm42iX/grxhZKcTvj38/rmuyNma5LwMNT+xmD4Q=; b=i4OiYQ84TZh+VlVsth5+i2xNQb9SovZeZr7JhgI3xXj/BFTx5L4ZrOI8BQzZQTWyuk VyLTue36XHlfBzxR0NfHpWSyucJaFxGFYVUpLw1EUH0YdhZbNi/lv04IbJgntJMo/fTk dDkE2oP8KadRRxd09UGH/4/iekebiHSm39/Pw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-type; bh=YTDSHm42iX/grxhZKcTvj38/rmuyNma5LwMNT+xmD4Q=; b=c30+rJtLRoEWV4Ids/C02j+jW+cnH2fyKUV0xE18paQ1immabVcsXgYT9x8ZLQBad7 xEl4ue2qralEz61Uhl7MTjPBnqHNvlWP+m61Lw4AC4usINxLUiGkup3MT7FLfmMNfwPK INlZw6zpugYPRM7by/iDYq+DPUQu0TvynJdvSxOEuw1+13rHaZme9w+DyVHfbG8bsN70 1sr9yNo7dL5rMeAkA8BCfCwjt6EpKfh1waCJ3BtOJT4GNqO8SiUFLotfQgRTmuWRpwIb OJEBhAnlrR8Hju8H0h6rbeWgvAiVdtTnwkEB4S0LQ44pW+84x8IA3alqjqsvSMYYCF/U IiZg== X-Gm-Message-State: ALoCoQk8N0P96D9FoclUYkFk3mGFnixvGiGPQLBCNjxVITXH4TlvYn0JpfNZ6fBb83X8gtvY54/W X-Received: by 10.69.2.69 with SMTP id bm5mr18995230pbd.41.1441447320803; Sat, 05 Sep 2015 03:02:00 -0700 (PDT) Received: from [172.19.254.107] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id fi5sm5312772pdb.5.2015.09.05.03.01.59 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 05 Sep 2015 03:02:00 -0700 (PDT) From: "Roland Dobbins" To: dots@ietf.org Date: Sat, 05 Sep 2015 17:01:56 +0700 Message-ID: <42A9C43A-8371-4BCB-927E-A8BA27CD562A@arbor.net> In-Reply-To: <55DF1EB7.9000703@cisco.com> References: <359EC4B99E040048A7131E0F4E113AFCD94F1C56@marathon> <55D01F5E.4070009@gondrom.org> <55DDA4A9.3050603@inria.fr> <8775DC11-7FE3-4A02-89EE-E6BDAC6A1C13@arbor.net> <55DF1EB7.9000703@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Subject: Re: [Dots] DOTS: next steps - call for editor volunteers for use case draft and requirements draft X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Sep 2015 10:02:02 -0000 On 27 Aug 2015, at 21:29, Flemming Andreasen wrote: > The charter explicitly talks about DDoS related telemetry and based on > previous discussions, It was my understanding that we wanted to > provide information about an ongoing attack to an upstream entity to > enable a more accurate and rapid response by that upstream entity. My intent when contributing that language to the charter was just this - to ensure that we determined what, if any, telemetry-derived information we wanted to make possible for DOTS supplicants to supply to DDoS mitigation service-providing entities. Obviously, I didn't do a very good job of expressing that clearly, heh. > I don't think we can just change the charter Re-chartering is easy, especially at such an early stage of the life of a WG. It shouldn't be necessary, but if this language is continued to be used as the basis for diluting our focus on the simple, straightforward task of producing a standardized protocol for the summoning of DDoS mitigation assistance, then we ought to correct it now, so that no more time and energy is wasted in discussing matters which are beyond the actual remit and intent of this WG (e.g., spending time talking about re-opening IPFIX when we already have an urgently-needed problem which we ought to be spending our time and energy solving). ----------------------------------- Roland Dobbins From nobody Sat Sep 5 03:12:03 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 394991A89FF for ; Sat, 5 Sep 2015 03:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham 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 wWFPl2QOWa25 for ; Sat, 5 Sep 2015 03:12:01 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDBA21A1A78 for ; Sat, 5 Sep 2015 03:12:00 -0700 (PDT) Received: by padhy16 with SMTP id hy16so45577730pad.1 for ; Sat, 05 Sep 2015 03:12:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; bh=uXHXiZrljzjiJ93dWKGDV5XLnqUkCZuD6wcN2gZyH9s=; b=E3jOC5E+1fIxlqeqTNEaMx9JfrnD31smUHxeyVUioFFf+5fMtk+Lefq3HBozQwrXBN EL5MH/xZbGioffC2dMFIkOXW8iNsnIyy80l+m6UbqroTIjvbCTLZG6GWQb32zirdhJVs DQAqqJ6TxgqIcHO1I998jPBvDTQAfH658aCA4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=uXHXiZrljzjiJ93dWKGDV5XLnqUkCZuD6wcN2gZyH9s=; b=E1wKXBetu4ktteYkU2gfjEAbQxt4sVaUIyz/kgNIgrItbIhMj0s18Eb7CaeOFoBB7y NA7zBE7Pj3HVuCjg9xPTS56NSm3YL8ayxdsTrDx7HwmG5vJ2GQxlQnsOliGzwSGiIlWJ 4e3X5MXtxgLOTtmlB6wNYFtASFPb1kXK55BISdyY0QmVBPKOpuDAx0xffSabo/ZXVp7s tAAwi5lxbqe7t/+so0NoajZdKFepmPEoPZdaPaKWkUbRmH+dX6NI2S2+KjPVhDkyrtme 8dk0/w0o0oMaQxEIXv3OxNoBkMXwiM+6UH7KiRXGNg7vWNGpM2rbwCGQLUQCKOs0Ml6w 7bGQ== X-Gm-Message-State: ALoCoQlSrZHiburTtnljQZWQyDVBvvDEGmUtXkP5ogah9D/9eUzwtsjLwOpw9OC1a7Gz1vCoyZvG X-Received: by 10.69.26.161 with SMTP id iz1mr19494252pbd.17.1441447920364; Sat, 05 Sep 2015 03:12:00 -0700 (PDT) Received: from [172.19.254.107] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id j10sm5339800pdr.7.2015.09.05.03.11.58 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 05 Sep 2015 03:11:59 -0700 (PDT) From: "Roland Dobbins" To: dots@ietf.org Date: Sat, 05 Sep 2015 17:11:56 +0700 Message-ID: <6A491DC4-87CE-499C-947D-B70B8E00DB1B@arbor.net> In-Reply-To: References: <359EC4B99E040048A7131E0F4E113AFCD94F1C56@marathon> <55D01F5E.4070009@gondrom.org> <55DDA4A9.3050603@inria.fr> <8775DC11-7FE3-4A02-89EE-E6BDAC6A1C13@arbor.net> <4A95BA014132FF49AE685FAB4B9F17F657D21479@dfweml701-chm> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.2r5107) Archived-At: Subject: Re: [Dots] wht are the "good reasons" to oppose "telemetry used for detection/classification/traceback of DDoS attacks" X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Sep 2015 10:12:02 -0000 On 5 Sep 2015, at 12:30, Christopher Morrow wrote: > certainly they can? Can and are, you're 100% correct. As you indicate, the telemetry formats in use today for DDoS detection/classification/traceback, while not perfect, work pretty well - the proof of this is that they are successfully used for this purpose each and every day, and have been for 15 years or more. The entire raison d'être for this WG is to produce a protocol intended to allow supplicants to summon DDoS mitigation assistance as needed; this has the side-benefit of allowing auto-provisioning of such services, which is also an urgent problem today. This is more than enough for the DOTS WG to chew on. This WG has no authority to re-open IPFIX to add additional classification elements; nor is there a burning need for same. We need to stick to our knitting. ----------------------------------- Roland Dobbins From nobody Sat Sep 5 03:19:55 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D11211B3D50 for ; Sat, 5 Sep 2015 03:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham 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 8csoYION9AIN for ; Sat, 5 Sep 2015 03:19:52 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EE301B3CC2 for ; Sat, 5 Sep 2015 03:19:52 -0700 (PDT) Received: by pacex6 with SMTP id ex6so47988523pac.0 for ; Sat, 05 Sep 2015 03:19:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-type; bh=tkKVm0oDV0VCIxuU4ECWvK6iw9arZBsu5Lh8gkpJxWI=; b=hhiLBNE1N5H0/vxuhbA47AdURhxaxq3NfiFBFV+VJF0qxZRYA6tuXU1lu8/w7Lu/dh KsE34zQEJ7280BTQI/113nV4x1sLr1JxF29YKGpbF5G6Hp4rwEiIOCyuIHeC4nuA5kJc K4alVMpQjG5MQJHUb2GIRR9PM6PeA9qkQfYe0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-type; bh=tkKVm0oDV0VCIxuU4ECWvK6iw9arZBsu5Lh8gkpJxWI=; b=TenEn3It0uSNWa8ithKipClfuAPeYZTcnx5e8GcdOdtZ34bUgJRuXSjou8tte5jPtt HnjzRAyvKDQHSG+70446hwEWqtGqDmpBTHvmvCVm9MhSvVn22u7zwnpqrJq9oZxCqxXY PToBwu6DmngDwXOZ76B7WQuYpyyVRaj04bT6dextmGTFZM7cJNM8GG0/t1RfqYO4/5ZO 4lpbJTefm+oDTg9lDsq8U73fYBl7VB5KVR0zSL+fn2pG9+AH06qHWs23Hy9/qWiyHf+Y VWkWNSYqSiw0dzvUx8N4KG5hXZEmazwOWg7fuuFcIZb/t0z//ILbD3Stlkub4rPZ/yNN 5WLw== X-Gm-Message-State: ALoCoQlNSpMkEQeAKp2W2TNJ4d88vheFa+oaqcX4mXwu5PEbj05wc95OKdVDM4XPPwcwQFTJiXKL X-Received: by 10.69.11.5 with SMTP id ee5mr19341881pbd.89.1441448392146; Sat, 05 Sep 2015 03:19:52 -0700 (PDT) Received: from [172.19.254.107] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id ct4sm5368533pdb.8.2015.09.05.03.19.50 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 05 Sep 2015 03:19:51 -0700 (PDT) From: "Roland Dobbins" To: dots@ietf.org Date: Sat, 05 Sep 2015 17:19:48 +0700 Message-ID: <3F7F0F8D-24DC-46D5-A1F7-19C7F67154DB@arbor.net> In-Reply-To: References: <359EC4B99E040048A7131E0F4E113AFCD94F1C56@marathon> <55D01F5E.4070009@gondrom.org> <55DDA4A9.3050603@inria.fr> <8775DC11-7FE3-4A02-89EE-E6BDAC6A1C13@arbor.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Subject: Re: [Dots] DOTS: next steps - call for editor volunteers for use case draft and requirements draft X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Sep 2015 10:19:54 -0000 On 27 Aug 2015, at 15:15, Dacheng Zhang wrote: > However, I agree that we may need to adjust some contents and make the > draft fit the scope of the group better. As the person who contributed that language to the charter, I can unambiguously assert that the intent behind it was to allow for the possibility of doing so in the service of *utilizing those existing standards in the service of summoning DDoS mitigation*, *not* to start adding additional traffic classification elements which are of dubious utility. Obviously, I didn't do a good job of expressing this concept. Concur 100% that it may be necessary to re-charter to clarify this intent, so that we can focus on our actual mission of producing a standards-based mechanism for signaling the need for DDoS mitigation assistance. It's easy enough to do it at this early stage. ----------------------------------- Roland Dobbins From nobody Sat Sep 5 03:33:37 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFC3E1B3E71 for ; Sat, 5 Sep 2015 03:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham 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 8dt6M3U93WwF for ; Sat, 5 Sep 2015 03:33:35 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 722311B3E39 for ; Sat, 5 Sep 2015 03:33:35 -0700 (PDT) Received: by padhy16 with SMTP id hy16so45900306pad.1 for ; Sat, 05 Sep 2015 03:33:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-type; bh=Pe+J2vdOO2M0YSOTYx8bNKBP5VueNQRrwAlD3EcNLQk=; b=PV7PEMv+/OG8CxGfDQZkGMb5mbC9erLKMSW+eQL1giIPGY/JUUZ6+CA+vWhgtalsW9 9k4OFG0xs/hRKdC5mTTpnaTJ/W5wp6J6Zn+BRn2rORNnA/YtqnUUFXNKrSdZii8bbWkb ho7qYmeIKN5PECWK+yTc76b4cv7Azj+diXsP0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-type; bh=Pe+J2vdOO2M0YSOTYx8bNKBP5VueNQRrwAlD3EcNLQk=; b=Qe2fcrK+B91uh/GkNCMbzPofBLCpGgNDLOhCvBDjY7M7VKsT0BYFCYoeqWLNds2xeP eGAiMz/P+Px3SEb/C3r6rucsuQ3Dlt/QhCki7fqkQiIeMl/q9+eY15jGSoZpKK/1J//r 2qAC2Zl+IStM5FQGbz+n3yMqLCM4rUJ/t/tVWSRwCl/fC3KJv8pUzHkyGUkIHQYxCfB3 YuvpCPtYMtEJy90VMd3DEgPcXd3ZuxoQ1droimaeQhdCcQx9YfrtT4q03vexK1xH+ZTa sxjCg2opuFhEOHksL0UX9Z1aWtVGGfxLJb/heEdl8XELRnIi3SHfjXRHaibs/D2D1tes xthw== X-Gm-Message-State: ALoCoQkFtAhaT8r8EuQdGlWGiqtwZnWAAux2dhKcZaRd0Y0KcomWHpq07ueF+u3NSJJNHLmO+WdU X-Received: by 10.66.248.72 with SMTP id yk8mr19502108pac.112.1441449215057; Sat, 05 Sep 2015 03:33:35 -0700 (PDT) Received: from [172.19.254.107] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id hv3sm5379218pbb.83.2015.09.05.03.33.33 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 05 Sep 2015 03:33:34 -0700 (PDT) From: "Roland Dobbins" To: dots@ietf.org Date: Sat, 05 Sep 2015 17:33:30 +0700 Message-ID: <26484CDD-185A-4D37-924B-1DB0E79CEC3B@arbor.net> In-Reply-To: References: <359EC4B99E040048A7131E0F4E113AFCD94F1C56@marathon> <55D01F5E.4070009@gondrom.org> <55DDA4A9.3050603@inria.fr> <8775DC11-7FE3-4A02-89EE-E6BDAC6A1C13@arbor.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Subject: Re: [Dots] DOTS: next steps - call for editor volunteers for use case draft and requirements draft X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Sep 2015 10:33:36 -0000 On 27 Aug 2015, at 19:13, Xialiang (Frank) wrote: > [Frank]: I cannot agree with you at this point. Whether you agree with me or not, that was what was meant by the language in the charter discussing the possible need to examine and possibly update existing telemetry formats. I know, because I'm the person who contributed it. Existing telemetry formats are successfully used every day to detect, classify, and traceback DDoS attacks. While imperfect (there's always room for improvement), there is no burning need to add additional classification elements to them, and it is not within the remit of this group to do so. > [Frank]: Instead of the subjective statements, I prefer to have more > constructive discussion on specific technical points. We need to focus this WG's effort on the development of a standards-based mechanism for signaling the need for DDoS mitigation assistance - i.e., the actual purpose of this WG - instead of delving into areas which are not directly related to that attainment of that goal. Can we please table discussion of draft-fu-ipfix-network-security-01 until after we've developed and delivered the actual DOTS specification draft? ----------------------------------- Roland Dobbins From nobody Sat Sep 5 23:07:41 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9CC41B4FBA for ; Sat, 5 Sep 2015 23:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 w5yY36ZwpEiv for ; Sat, 5 Sep 2015 23:07:37 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD76A1B496A for ; Sat, 5 Sep 2015 23:07:36 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CAW52648; Sun, 06 Sep 2015 06:07:34 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.235.1; Sun, 6 Sep 2015 07:07:32 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.33]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0235.001; Sun, 6 Sep 2015 14:07:28 +0800 From: Sheng Jiang To: "dots@ietf.org" Thread-Topic: New Proposed Networks Machine Learning (NML) Research Group Thread-Index: AdDoakyvpvmeZnnPQr63UkAMITCswA== Date: Sun, 6 Sep 2015 06:07:27 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927BB2D11F@nkgeml512-mbx.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.197] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Dots] New Proposed Networks Machine Learning (NML) Research Group X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2015 06:07:40 -0000 SGksIERvdHMsDQoNClNpbmNlIHlvdSBhcmUgaW50ZXJlc3RlZCBpbiAiZGF0YSBtaW5pbmcgRERP UyBwcm90ZWN0aW9uIiwgeW91IG1heSBhbHNvIGJlIGludGVyZXN0ZWQgaW4gdGhlIG5ld2x5IHBy b3Bvc2VkIFJlc2VhcmNoIEdyb3VwIGluIElSVEYgLSBOZXR3b3JrcyBNYWNoaW5lIExlYXJuaW5n IChOTUwpLiBXZSBiZWxpZXZlIHRoZSBtYWNoaW5lIGxlYXJuaW5nIG1lY2hhbmlzbSB3b3VsZCBo ZWxwIHRoZSBkZXZlbG9wbWVudCBvZiB0aGUgSW50ZXJuZXQuIEl0IGNvdWxkIGludHJvZHVjZSBu ZXcgd2F5cyB0byBtYWtlIGRlY2lzaW9uIGF1dG9ub21pY2FsbHkgYnkgbmV0d29yayBkZXZpY2Vz IG9yIHByb3ZpZGUgaGVscGZ1bCBpbmZvcm1hdGlvbiBmb3IgbmV0d29yayBhZG1pbmlzdHJhdG9y cy4gQW5kIGl0IGNvdWxkIHByb3ZpZGUgZmxleGliaWxpdHkgYW5kIGFkYXB0YWJpbGl0eSB0byBu ZXR3b3Jrcy4gTm90IGFueSB0aGUgbmV0d29yayBtYW5hZ2VtZW50LCBidXQgYWxzbyBuZXR3b3Jr IGVzdGFibGlzaG1lbnQgb3IgY29udHJvbCBhcmUgcG90ZW50aWFsbHkgYmVuZWZpdGVkIGZyb20g dGhlIG1hY2hpbmUgbGVhcm5pbmcgbWVjaGFuaXNtLiBBcHBseWluZyB0aGUgbWFjaGluZSBsZWFy bmluZyBtZWNoYW5pc20gaW4gbmV0d29yayBkb21haW5zIGFyZSBzdGlsbCBub3QgbWF0dXJlZCwg dGhhdCBpcyB3aHkgaXQgaXMgYSByZXNlYXJjaCBncm91cC4gQnV0IGl0IHdvdWxkIHJhcGlkbHkg bW92ZSBmcm9tIGFjYWRlbWljIHJlc2VhcmNoIGludG8gcHJhY3RpY2FsIGFwcGxpY2F0aW9uLiBX ZSBhcmUgcGxhbm5pbmcgdG8gaG9sZCB0aGUgZmlyc3QgbWVldGluZyBpbiBJRVRGIDk0LCBZb2tv aGFtYS4gUGFydGljaXBhbnRzIGZyb20gYm90aCB1bml2ZXJzaXR5IGVudmlyb25tZW50cyBhbmQg aW5kdXN0cmlhbCByZXNlYXJjaCBhbmQgZGV2ZWxvcG1lbnQgb3JnYW5pemF0aW9ucyBhcmUgYWxs IHdlbGNvbWUuDQoNClRoZSBjaGFydGVyIGFuZCBtYWlsIGxpc3QgaW5mb3JtYXRpb24gaXMgYmVs b3c6DQoNCk5ldHdvcmtzIE1hY2hpbmUgTGVhcm5pbmcgUmVzZWFyY2ggR3JvdXANCg0KTGluazog aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvZ3JvdXAvaXJ0Zi90cmFjL3dpa2kvbm1sDQoNCk1h aWxpbmcgTGlzdA0KICAgbm1scmdAaXJ0Zi5vcmcNCiAgIGh0dHBzOi8vd3d3LmlydGYub3JnL21h aWxtYW4vbGlzdGluZm8vbm1scmcNCg0KQ2hhcnRlcg0KDQpNYWNoaW5lIGxlYXJuaW5nIHRlY2hu b2xvZ2llcyBjYW4gbGVhcm4gZnJvbSBoaXN0b3JpY2FsIGRhdGEsIGFuZCBtYWtlIHByZWRpY3Rp b25zIG9yIGRlY2lzaW9ucywgcmF0aGVyIHRoYW4gZm9sbG93aW5nIHN0cmljdGx5IHN0YXRpYyBw cm9ncmFtIGluc3RydWN0aW9ucy4gVGhleSBjYW4gZHluYW1pY2FsbHkgYWRhcHQgdG8gYSBjaGFu Z2luZyBzaXR1YXRpb24gYW5kIGVuaGFuY2UgdGhlaXIgb3duIGludGVsbGlnZW5jZSB3aXRoIGJ5 IGxlYXJuaW5nIGZyb20gbmV3IGRhdGEuIFRoaXMgYXBwcm9hY2ggaGFzIGJlZW4gc3VjY2Vzc2Z1 bCBpbiBpbWFnZSBhbmFseXNpcywgcGF0dGVybiByZWNvZ25pdGlvbiwgbGFuZ3VhZ2UgcmVjb2du aXRpb24sIGNvbnZlcnNhdGlvbiBzaW11bGF0aW9uLCBhbmQgbWFueSBvdGhlciBhcHBsaWNhdGlv bnMuIEl0IGNhbiBsZWFybiBhbmQgY29tcGxldGUgY29tcGxpY2F0ZWQgdGFza3MuIEl0IGFsc28g aGFzIHBvdGVudGlhbCBpbiB0aGUgbmV0d29yayB0ZWNobm9sb2d5IGFyZWEuIEl0IGNhbiBiZSB1 c2VkIHRvIGludGVsbGlnZW50bHkgbGVhcm4gdGhlIHZhcmlvdXMgZW52aXJvbm1lbnRzIG9mIG5l dHdvcmtzIGFuZCByZWFjdCB0byBkeW5hbWljIHNpdHVhdGlvbnMgYmV0dGVyIHRoYW4gYSBmaXhl ZCBhbGdvcml0aG0uIFdoZW4gaXQgYmVjb21lcyBtYXR1cmUsIGl0IHdvdWxkIGJlIGdyZWF0bHkg YWNjZWxlcmF0ZSB0aGUgZGV2ZWxvcG1lbnQgb2YgYXV0b25vbWljIG5ldHdvcmtpbmcuDQoNClRo ZSBOZXR3b3JrIE1hY2hpbmUgTGVhcm5pbmcgUmVzZWFyY2ggR3JvdXAgKE5NTFJHKSBwcm92aWRl cyBhIGZvcnVtIGZvciByZXNlYXJjaGVycyB0byBleHBsb3JlIHRoZSBwb3RlbnRpYWwgb2YgbWFj aGluZSBsZWFybmluZyB0ZWNobm9sb2dpZXMgZm9yIG5ldHdvcmtzLiBJbiBwYXJ0aWN1bGFyLCB0 aGUgTk1MUkcgd2lsbCB3b3JrIG9uIHBvdGVudGlhbCBhcHByb2FjaGVzIHRoYXQgYXBwbHkgbWFj aGluZSBsZWFybmluZyB0ZWNobm9sb2dpZXMgaW4gbmV0d29yayBjb250cm9sLCBuZXR3b3JrIG1h bmFnZW1lbnQsIGFuZCBzdXBwbHlpbmcgbmV0d29yayBkYXRhIGZvciB1cHBlci1sYXllciBhcHBs aWNhdGlvbnMuDQoNClRoZSBpbml0aWFsIGZvY3VzIG9mIHRoZSBOTUxSRyB3aWxsIGJlIG9uIGhp Z2hlci1sYXllciBjb25jZXB0cyB3aGVyZSB0aGUgbWFjaGluZSBsZWFybmluZyBtZWNoYW5pc20g Y291bGQgYmUgYXBwbGllZCBpbiBvcmRlciB0byBlbmhhbmNlIHRoZSBuZXR3b3JrIGVzdGFibGlz aGluZywgY29udHJvbGxpbmcsIG1hbmFnaW5nLCBuZXR3b3JrIGFwcGxpY2F0aW9ucyBhbmQgY3Vz dG9tZXIgc2VydmljZXMuIFRoaXMgaW5jbHVkZXMgbWVjaGFuaXNtcyB0byBhY3F1aXJlIGtub3ds ZWRnZSBmcm9tIHRoZSBleGlzdGluZyBuZXR3b3JrcyBzbyB0aGF0IG5ldyBuZXR3b3JrcyBjYW4g YmUgZXN0YWJsaXNoZWQgd2l0aCBtaW5pbXVtIGVmZm9ydHM7IHRoZSBwb3RlbnRpYWwgdG8gdXNl IG1hY2hpbmUgbGVhcm5pbmcgbWVjaGFuaXNtcyBmb3Igcm91dGluZyBjb250cm9sIGFuZCBvcHRp bWl6YXRpb247IHVzaW5nIG1hY2hpbmUgbGVhcm5pbmcgbWVjaGFuaXNtcyBpbiBuZXR3b3JrIG1h bmFnZW1lbnQgdG8gcHJlZGljdCBmdXR1cmUgbmV0d29yayBzdGF0dXM7IHVzaW5nIG1hY2hpbmUg bGVhcm5pbmcgbWVjaGFuaXNtcyB0byBhdXRvbm9taWMgYW5kIGR5bmFtaWNhbGx5IG1hbmFnZSB0 aGUgbmV0d29yazsgdXNpbmcgbWFjaGluZSBsZWFybmluZyBtZWNoYW5pc21zIHRvIGFuYWx5emUg bmV0d29yayBmYXVsdHMgYW5kIHN1cHBvcnQgcmVjb3Zlcnk7IGxlYXJuaW5nIG5ldHdvcmsgYXR0 YWNrcyBhbmQgdGhlaXIgYmVoYXZpb3IsIHNvIHRoYXQgcHJvdGVjdGlvbiBtZWNoYW5pc21zIGNv dWxkIGJlIHNlbGYtZGV2ZWxvcGVkOyB1bmlmeWluZyB0aGUgZGF0YSBzdHJ1Y3R1cmUgYW5kIHRo ZSBjb21tdW5pY2F0aW9uIGludGVyZmFjZSBiZXR3ZWVuIG5ldHdvcmsvbmV0d29yayBkZXZpY2Vz IGFuZCBjdXN0b21lcnMsIHNvIHRoYXQgdGhlIHVwcGVyLWxheWVyIGFwcGxpY2F0aW9ucyBjb3Vs ZCBlYXNpbHkgb2J0YWluIHJlbGV2YW50IG5ldHdvcmsgaW5mb3JtYXRpb24sIGV0Yy4NCg0KVGhl IE5NTFJHIGlzIGV4cGVjdGVkIHRvIGlkZW50aWZ5IGFuZCBkb2N1bWVudCByZXF1aXJlbWVudHMs IHRvIHN1cnZleSBwb3NzaWJsZSBhcHByb2FjaGVzLCB0byBwcm92aWRlIHNwZWNpZmljYXRpb25z IGZvciBwcm9wb3NlZCBzb2x1dGlvbnMsIGFuZCB0byBwcm92ZSBjb25jZXB0cyB3aXRoIHByb3Rv dHlwZSBpbXBsZW1lbnRhdGlvbnMgdGhhdCBjYW4gYmUgdGVzdGVkIGluIHJlYWwtd29ybGQgZW52 aXJvbm1lbnRzLg0KDQpUaGUgZ3JvdXAgd2lsbCByZXBvcnQgaXRzIHByb2dyZXNzIHRocm91Z2gg YSBwdWJsaWNseSBhY2Nlc3NpYmxlIHdlYiBzaXRlIGFuZCBwcmVzZW50YXRpb25zIGF0IElFVEYg bWVldGluZ3MuIFNwZWNpZmljYXRpb25zIGRldmVsb3BlZCBieSB0aGUgTk1MUkcgd2lsbCBiZSBz dWJtaXR0ZWQgZm9yIHB1YmxpY2F0aW9uIGFzIEV4cGVyaW1lbnRhbCBvciBJbmZvcm1hdGlvbmFs IFJGQ3MuDQoNClRoaXMgdG9waWMgaXMgcmFwaWRseSBtb3ZpbmcgZnJvbSBhY2FkZW1pYyByZXNl YXJjaCBpbnRvIHByYWN0aWNhbCBhcHBsaWNhdGlvbi4gVGhlcmVmb3JlIHdlIGhvcGUgdG8gYXR0 cmFjdCBwYXJ0aWNpcGFudHMgZnJvbSBib3RoIHVuaXZlcnNpdHkgZW52aXJvbm1lbnRzIGFuZCBp bmR1c3RyaWFsIHJlc2VhcmNoIGFuZCBkZXZlbG9wbWVudCBvcmdhbml6YXRpb25zLCBpbiBvcmRl ciB0byBjcmVhdGUgc3luZXJneSBhbmQgY29udmVydCB0aGVvcnkgaW50byBwcmFjdGljZS4gUGVv cGxlIGFjdGl2ZWx5IGltcGxlbWVudGluZyByZWxldmFudCBzb2Z0d2FyZSB3aWxsIGJlIGVzcGVj aWFsbHkgd2VsY29tZS4NCg0KTWVtYmVyc2hpcA0KDQpNZW1iZXJzaGlwIGlzIG9wZW4gdG8gYW55 IGludGVyZXN0ZWQgcGFydGllcy9pbmRpdmlkdWFscy4gDQpNZWV0aW5ncw0KDQpSZWd1bGFyIHdv cmtpbmcgbWVldGluZ3MgYXJlIGhlbGQgYWJvdXQgdHdvL3RocmVlIHRpbWVzIHBlciB5ZWFyIGF0 IGxvY2F0aW9ucyBjb252ZW5pZW50IHRvIHRoZSBtYWpvcml0eSBvZiB0aGUgcGFydGljaXBhbnRz LiBXb3JraW5nIG1lZXRpbmdzIHR5cGljYWxseSB0YWtlIDEtMiBkYXlzIGFuZCBhcmUgdHlwaWNh bGx5IGNvLWxvY2F0ZWQgd2l0aCBlaXRoZXIgSUVURiBtZWV0aW5ncyBvciBjb25mZXJlbmNlcyBy ZWxhdGVkIHRvIG1hY2hpbmUgbGVhcm5pbmcgb3IgYXV0b25vbWljIG5ldHdvcmtzLg0KDQpCZXN0 IHJlZ2FyZHMsDQoNClNoZW5nDQo= From nobody Sun Sep 6 21:35:22 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 283051B3B28 for ; Sun, 6 Sep 2015 21:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.278 X-Spam-Level: * X-Spam-Status: No, score=1.278 tagged_above=-999 required=5 tests=[BAYES_50=0.8, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 R06GPXxRWlDY for ; Sun, 6 Sep 2015 21:35:18 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A6F21B3B03 for ; Sun, 6 Sep 2015 21:35:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BXF56616; Mon, 07 Sep 2015 04:35:16 +0000 (GMT) Received: from SZXEMA412-HUB.china.huawei.com (10.82.72.71) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 7 Sep 2015 05:35:15 +0100 Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.68]) by SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id 14.03.0235.001; Mon, 7 Sep 2015 12:35:12 +0800 From: "Xialiang (Frank)" To: Christopher Morrow Thread-Topic: [Dots] DOTS: next steps - call for editor volunteers for use case draft and requirements draft Thread-Index: AQHQ1+Rbj3GGCU8ZsUuh3PHZFemaaZ4dsOiAgAD+mgCAAIxFkP//hNIAgACw55D//4gLgIAAegqAgA0JQwCABAfccA== Date: Mon, 7 Sep 2015 04:35:11 +0000 Message-ID: References: <359EC4B99E040048A7131E0F4E113AFCD94F1C56@marathon> <55D01F5E.4070009@gondrom.org> <55DDA4A9.3050603@inria.fr> <8775DC11-7FE3-4A02-89EE-E6BDAC6A1C13@arbor.net> <55DF1EB7.9000703@cisco.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.43.91] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: Roland Dobbins , Flemming Andreasen , "dots@ietf.org" Subject: Re: [Dots] DOTS: next steps - call for editor volunteers for use case draft and requirements draft X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2015 04:35:21 -0000 SGkgQ2hyaXMsDQpBY2NvcmRpbmcgdG8geW91ciBjb21tZW50czogDQoiIGl0J3Mgbm90IGNsZWFy IHRoYXQgYSBjdXN0b21lciBsaW5rIGNhbiB0ZWxsIHdoYXQncyByZWFsbHkgZ29pbmcgb24sIHNv ICdiYWQgaW5mb3JtYXRpb24nIGlzIHdvcnNlIHRoYW4gJ25vIGluZm9ybWF0aW9uJy4uLiB3aGVu IGJhZCB0aGluZ3MgYXJlIGhhcHBlbmluZy4iDQpJIGhhdmUgYSBxdWVzdGlvbjogSW4geW91ciBt aW5kLCB3aGljaCBraW5kIG9mIHRocmVhdCBpbmZvcm1hdGlvbiBpcyBiYWQgaW5mb3JtYXRpb24s IGFuZCB3aGljaCBpcyBnb29kPyANCk15IHVuZGVyc3RhbmRpbmcgaXM6IEl0IHNlZW1zIHRoYXQg bW9zdCBvZiB1cyBoYXZlIGNvbnNlbnN1cyBvbiB0aGUgdmFsdWUgb2YgdGVsZW1ldHJ5IChpcGZp eCBvciBvdGhlcnMpIGluZm9ybWF0aW9uLCBhbmQgdGhlIGZhY3QgdGhhdCBpdCB3b3JrcyBwcmV0 dHkgd2VsbCBmb3IgbWFueSB5ZWFycy4gV2Ugc2hvdWxkIG5vdCBjb25zaWRlciB0aGVtIGFzIGJh ZCBpbmZvcm1hdGlvbiwgcmlnaHQ/DQpJIHRoaW5rIHlvdXIgd29ycnkgaXMgbm90IHJlbGF0ZWQg dG8gdGhlIHRlbGVtZXRyeSBpdHNlbGYsIGJ1dCB0byB0aGUgY29sbGVjdGlvbiBtZWNoYW5pc20s IGFuZCB0aGUgYW5hbHlzaXMgYWxnb3JpdGhtIHRvIHRoZSBjb2xsZWN0ZWQgdGVsZW1ldHJ5IGlu Zm9ybWF0aW9uLiBBbmQgdGhlc2UgYXJlIG5vdCBpbiBzY29wZSBvZiBET1RTIHN0YW5kYXJkIHdv cmtzLg0KDQpSZXNwb25zZSB0byB5b3VyIG90aGVyIGNvbW1lbnQgYmVsb3c6DQoNCkIuUi4NCkZy YW5rDQoNCg0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IERvdHMgW21haWx0bzpkb3RzLWJv dW5jZXNAaWV0Zi5vcmddILT6se0gQ2hyaXN0b3BoZXIgTW9ycm93DQq3osvNyrG85DogMjAxNcTq OdTCNcjVIDU6MzQNCsrVvP7IyzogRmxlbW1pbmcgQW5kcmVhc2VuDQqzrcvNOiBSb2xhbmQgRG9i YmluczsgZG90c0BpZXRmLm9yZw0K1vfM4jogUmU6IFtEb3RzXSBET1RTOiBuZXh0IHN0ZXBzIC0g Y2FsbCBmb3IgZWRpdG9yIHZvbHVudGVlcnMgZm9yIHVzZSBjYXNlIGRyYWZ0IGFuZCByZXF1aXJl bWVudHMgZHJhZnQNCg0KT24gVGh1LCBBdWcgMjcsIDIwMTUgYXQgMTA6MjkgQU0sIEZsZW1taW5n IEFuZHJlYXNlbiA8ZmFuZHJlYXNAY2lzY28uY29tPiB3cm90ZToNCj4gT24gOC8yNy8xNSAzOjEy IEFNLCBSb2xhbmQgRG9iYmlucyB3cm90ZToNCj4+DQo+PiBPbiAyNyBBdWcgMjAxNSwgYXQgMTc6 MDEsIFhpYWxpYW5nIChGcmFuaykgd3JvdGU6DQo+Pg0KPj4+IHdoaWNoIGluY2x1ZGVzIHRoZSBE RG9TIHJlbGF0ZWQgdGVsZW1ldHJ5IGluZm9ybWF0aW9uIGFzIGl0cyBwYXJ0LA0KPj4NCj4+DQo+ PiBUaGUgRERvUyB0ZWxlbWV0cnkgcmVmZXJyZWQgdG8gaW4gdGhlIFdHIGNoYXJ0ZXIgaXMgYSBz dGFydGluZyBwb2ludCANCj4+IGZvciBET1RTIHNpZ25hbGluZyAtIHRoZSB0ZWxlbWV0cnkgaXRz ZWxmIGlzIG91dC1vZi1zY29wZSBmb3IgdGhpcyBXRy4NCj4NCj4gQ2FuIHlvdSBjbGFyaWZ5IHRo ZSBkaXN0aW5jdGlvbiB5b3UgYXJlIG1ha2luZyBoZXJlID8gVGhlIGNoYXJ0ZXIgDQo+IGV4cGxp Y2l0bHkgdGFsa3MgYWJvdXQgRERvUyByZWxhdGVkIHRlbGVtZXRyeSBhbmQgYmFzZWQgb24gcHJl dmlvdXMgDQo+IGRpc2N1c3Npb25zLCBJdCB3YXMgbXkgdW5kZXJzdGFuZGluZyB0aGF0IHdlIHdh bnRlZCB0byBwcm92aWRlIA0KPiBpbmZvcm1hdGlvbiBhYm91dCBhbiBvbmdvaW5nIGF0dGFjayB0 byBhbiB1cHN0cmVhbSBlbnRpdHkgdG8gZW5hYmxlIGEgDQo+IG1vcmUgYWNjdXJhdGUgYW5kIHJh cGlkIHJlc3BvbnNlIGJ5IHRoYXQgdXBzdHJlYW0gZW50aXR5Lg0KDQpwZXJoYXBzIHBhcnQgb2Yg dGhlIHByb2JsZW0gaGVyZSBpcyByZWxhdGVkIHRvICdwcm92aWRlIGluZm9ybWF0aW9uIGFib3V0 IGFuIG9uZ29pbmcgYXR0YWNrIHRvIGFuIHVwc3RyZWFtIGVudGl0eS4uLi4nDQoNCndoYXQgaW5m b3JtYXRpb24/IHBwcz8gZGVzdGluYXRpb24gaXAvbmV0d29yaz8gc3JjLWFkZHJlc3Nlcz8NCnBv cnQvcHJvdG9jb2xzIHVzZWQ/DQoNCkkgc3VzcGVjdCB0aGF0IHRoZSB1cHN0cmVhbSBwcm92aWRl ciBjYW4gdmVyeSBxdWlja2x5IGRldGVybWluZSB0aGUgcHJvYmxlbSBpbiBhbG1vc3QgYWxsIGNh c2VzLCBwcm9iYWJseSBiZXR0ZXIgdGhhbiB0aGUgaW5pdGlhbCByZXBvcnRlci4uLiBhbmQgSSdt IG5vdCBzdXJlIGl0J3MgcGFydGljdWxhcmx5IHVzZWZ1bCB0byBzZW5kIHVwc3RyZWFtIG11Y2gg bW9yZSB0aGFuOg0KICAiSSBhbSBzZWVpbmcgYW4gYXR0YWNrIHRvIGRlc3RpbmF0aW9uIFggcG9y dC9wcm90b2NvbCBZL1oiDQoNCg0KeW91IHdpbGwgd2FudCB0byBhc2sgdGhlIHVwc3RyZWFtOg0K ICAiZG8gbm90IGRpc2FibGUgYWNjZXNzIg0KDQpbRnJhbmtdOiBpcGZpeC1iYXNlZCBuZXR3b3Jr IGZsb3cgc2FtcGxpbmcgbWV0aG9kIGlzIGFscmVhZHkgYWRvcHRlZCBieSBtYW55IG9wZXJhdG9y cyAobmV0d29yayBvciBzZXJ2aWNlKSBpbiBtYW55IGNhc2VzLiBJbiBvdXIgZHJhZnQgLS0gZHJh ZnQtZnUtaXBmaXgtbmV0d29yay1zZWN1cml0eS0wMSwgdGhlIGdvYWwgaXMgdmVyeSBjbGVhcjog aWRlbnRpZnkgdGhlIG1pc3NpbmcgSVBGSVggbWV0cmljcyBmb3Igc3BlY2lmaWMgbmV0d29yayB0 aHJlYXRzIG1vbml0b3JpbmcgYW5kIHByb3Bvc2Ugc3VwcGxlbWVudCB0byBjdXJyZW50IElQRklY IG1ldHJpY3Mgc2V0LCB3aGljaCBkb2VzIG5vdCByZXF1aXJlIG1vZGlmeWluZyB0aGUgSVBGSVgg Zm9ybWF0LiBGb3IgdGhvc2Ugb3BlcmF0b3JzIHdobyBhbHJlYWR5IGRlcGxveSBpcGZpeCwgdGhl IG5ldHdvcmsgdGhyZWF0cyBkZXRlY3Rpb24gaXMgbXVjaCBlYXN5IHRoYW4gYmVmb3JlIHRocm91 Z2ggdGhlc2UgbmV3IG1ldHJpY3MsIGFuZCB3aXRoIGxpdHRsZSBjaGFuZ2UgdG8gY3VycmVudCBJ UEZJWCBwcm90b2NvbC4gSSBwZXJzb25hbCB0aGluayB0aGlzIHdvcmsgaXMgcHJvbWlzaW5nIGFu ZCB3b3J0aHdoaWxlLiBTb21lIGV4YW1wbGVzIG9mIG5ldyBpcGZpeCBtZXRyaWNzIGluY2x1ZGU6 IHBrdFVwc3RyZWFtQ291bnQsIHBrdERvd25zdHJlYW1Db3VudCwgaWNtcEVjaG9Db3VudCwgaWNt cEVjaG9SZXBseUNvdW50LCBmcmFnbWVudEluY29tcGxldGVDb3VudCwgZnJhZ21lbnRPZmZlc3RF cnJvciwgLi4uIFdlIHdpbGwgaW1wcm92ZSBhbmQgZGV0YWlsIHRoZSBkcmFmdCBmb3IganVzdGlm eWluZyB0aGlzIGRpcmVjdGlvbi4NCg0KDQoNCg0KDQpwcm9iYWJseS4uLiBhbmQgYXMgdG8gdGhl IGNoYXJ0ZXIsIHRoZSBjaGFydGVyIGNhbiBhbHdheXMgYmUgY2hhbmdlZC4uLiBvciB0aGF0IHdv cmsgaXRlbSBjYW4gd2FpdCB1bnRpbCB0aGUgZGVjaXNpb24gaXMgdGhhdCAndGhpcyB3b3JrIGlz IG5vdCByZWxldmFudCBhbnltb3JlJy4uLiBpdCdkIGJlIGJlc3QsIEkgdGhpbmssIHRvIGZvY3Vz IG9uIHRoZSBiYXNpYyBkb3RzIHByb3RvY29sIHdvcmsgYW5kIGxlYXZlIHRoZSB0ZWxlbWV0cnkg Zm9yIGEgbGF0ZXIgZGVjaXNpb24uDQoNCj4NCj4+IElmIHRoZSBsYW5ndWFnZSBuZWVkcyB0byBi ZSBtYXNzYWdlZCB0byByZWZsZWN0IHRoaXMsIHdlIGNhbiBkbyBpdC4NCj4+DQo+IEkgZG9uJ3Qg dGhpbmsgd2UgY2FuIGp1c3QgY2hhbmdlIHRoZSBjaGFydGVyLCBob3dldmVyIHdlIHNob3VsZCBt YWtlIA0KPiBzdXJlIHRvIGNhcHR1cmUgdGhlIG91dGNvbWUgb2YgdGhpcyB0aHJlYWQgYXMgcGFy dCBvZiB0aGUgb3ZlcmFsbCByZXF1aXJlbWVudHMuDQoNCmNoYXJ0ZXJzIGFsd2F5cyBjaGFuZ2Us IGl0J3Mgbm90IHdyaXR0ZW4gaW4gc3RvbmUgYnkgYWxpZW5zLg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRG90cyBtYWlsaW5nIGxpc3QNCkRvdHNA aWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90cw0K From nobody Sun Sep 6 23:21:09 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 496EC1B47CE for ; Sun, 6 Sep 2015 23:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham 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 Y110R4Z7OFHK for ; Sun, 6 Sep 2015 23:21:04 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B58581B472C for ; Sun, 6 Sep 2015 23:21:04 -0700 (PDT) Received: by pacex6 with SMTP id ex6so87107964pac.0 for ; Sun, 06 Sep 2015 23:21:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-type; bh=SRpG0+CNiaPOORyB5dJ5nU80N2B5tDOj7l1bL6MDWh4=; b=JkbfgMXtRJdXuw4FBGUa3oo6b/fsO5Z49fut+Bzwe7koSdFqCnkNwGJtT24j0sAHZr 791Ul8UUi4Hja77oU1xC/tTLaSO6znr5DLqlxqzaQVL6bX52MmJYmy40baIWBRTs+d4F obM1poteliM71pPfObAJv4pbWa02NKHamCSFg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-type; bh=SRpG0+CNiaPOORyB5dJ5nU80N2B5tDOj7l1bL6MDWh4=; b=Te1s8gdjl5jLq6r4gUoHmQZV8ydsBnzsZhMH0W1aSbUeLQmhL4em5vXSCQaOwVBoLM Bfx+l6iRtzsVIh9SYDd9XYUGEPL97Bl/as/PPFxxx61/I5HuhMAj8iUDwT3E0yW4Vu5n mjn7KfWXBNs6iNYo0RQT09qJHCpOTBg3qunU8EtuvATyCBM7whunOlSRSermm6v0ECf4 yjFci2gdN8G5g4QMt9q4UXlAJbQEmIm1AUzS53tDnsaPfhLgVgdMLKMcr6BhZXtWmDiA FlIF6yWlIvrqwo90rNUXCMcDn/YuSTodFP5ElMj5173KPUlnN7fq2BLQMM4SByQPwG6I 7Zew== X-Gm-Message-State: ALoCoQkIbMTnrBVQ2c2b/SRfAN+8ovPzk7ae9Z6GREGjQldZ5HiWxsPn+/THtUlxPYhjaAbhymPS X-Received: by 10.66.250.226 with SMTP id zf2mr41871377pac.20.1441606864366; Sun, 06 Sep 2015 23:21:04 -0700 (PDT) Received: from [172.19.254.107] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id pg5sm10565912pdb.81.2015.09.06.23.21.02 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 06 Sep 2015 23:21:03 -0700 (PDT) From: "Roland Dobbins" To: dots@ietf.org Date: Mon, 07 Sep 2015 13:20:59 +0700 Message-ID: <7F42E6D6-FFFA-45BD-B77C-F4FCC766FF80@arbor.net> In-Reply-To: References: <359EC4B99E040048A7131E0F4E113AFCD94F1C56@marathon> <55D01F5E.4070009@gondrom.org> <55DDA4A9.3050603@inria.fr> <8775DC11-7FE3-4A02-89EE-E6BDAC6A1C13@arbor.net> <55DF1EB7.9000703@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Subject: Re: [Dots] DOTS: next steps - call for editor volunteers for use case draft and requirements draft X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2015 06:21:07 -0000 On 7 Sep 2015, at 11:35, Xialiang (Frank) wrote: > In your mind, which kind of threat information is bad information, and > which is good? I'm not Chris, but what he means is that having incomplete/inaccurate telemetry is worse than having none at all. > identify the missing IPFIX metrics for specific network threats > monitoring and propose supplement to current IPFIX metrics set, which > does not require modifying the IPFIX format. This is not within the remit of this WG. And IPFIX is IPFIX; other than enterprise elements, there is no modifying it without reopening it. We need to focus on getting the actual DOTS protocol standard devised before going around trying to take other WG's work from them. All this discussion about IPFIX has not advanced the WG's iota by one centimeter. Can we please focus on the matter at hand? ----------------------------------- Roland Dobbins From nobody Sun Sep 6 23:49:57 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A77431B4BF4 for ; Sun, 6 Sep 2015 23:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.422 X-Spam-Level: X-Spam-Status: No, score=-1.422 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 GHxRfU21o9qh for ; Sun, 6 Sep 2015 23:49:53 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89E6D1B4BB2 for ; Sun, 6 Sep 2015 23:49:52 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BXF67233; Mon, 07 Sep 2015 06:49:50 +0000 (GMT) Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 7 Sep 2015 07:49:49 +0100 Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.68]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0235.001; Mon, 7 Sep 2015 14:49:41 +0800 From: "Xialiang (Frank)" To: Roland Dobbins Thread-Topic: [Dots] wht are the "good reasons" to oppose "telemetry used for detection/classification/traceback of DDoS attacks" Thread-Index: AQHQ51S7ORh823sfqU+gZIQqQs0rHp4tKw0AgANmv5A= Date: Mon, 7 Sep 2015 06:49:41 +0000 Message-ID: References: <359EC4B99E040048A7131E0F4E113AFCD94F1C56@marathon> <55D01F5E.4070009@gondrom.org> <55DDA4A9.3050603@inria.fr> <8775DC11-7FE3-4A02-89EE-E6BDAC6A1C13@arbor.net> <4A95BA014132FF49AE685FAB4B9F17F657D21479@dfweml701-chm> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.43.91] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "dots@ietf.org" Subject: Re: [Dots] wht are the "good reasons" to oppose "telemetry used for detection/classification/traceback of DDoS attacks" X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2015 06:49:55 -0000 SGkgUm9sYW5kLA0KRnJvbSBteSB1bmRlcnN0YW5kaW5nLCB0aGUgd29ya3MgYSBXRyBzaG91bGQg ZG8gb3VnaHQgdG8gYmUgZGVjaWRlZCBvciBkZXJpdmVkIGZyb20gdGhlIHJlYWwgdXNlIGNhc2Vz IGFuZCByZXF1aXJlbWVudHMsIG5vdCB0aGUgc29sdXRpb24gd2hhdCB3ZSBoYXZlIG5vdy4gU28s IG15IHN1Z2dlc3Rpb24gaXMgdG8gcHVzaCBhc2lkZSB0aGUgZGlzY3Vzc2lvbiBvbiBzcGVjaWZp YyBzb2x1dGlvbiwgYW5kIGJlIGNvbmNlcm5lZCBvbiB0aGUgdXNlIGNhc2VzIGFuZCByZXF1aXJl bWVudHMgcmlnaHQgbm93LiBBdCBsYXN0LCB0aGV5IHdpbGwgbmF0dXJhbGx5IGxlYWQgdXMgdG8g d2hhdCBzb2x1dGlvbiBpcyBtb3N0bHkgcmVxdWlyZWQsIHdoYXQgcGFydCBpcyBtaXNzZWQgbm93 LCBldGMuDQoNClNvbWUgb2YgbXkgcmVzcG9uc2VzIHRvIHlvdXIgY29tbWVudHMgYXJlIGJlbG93 Og0KDQoNCg0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IERvdHMgW21haWx0bzpkb3RzLWJv dW5jZXNAaWV0Zi5vcmddILT6se0gUm9sYW5kIERvYmJpbnMNCreiy83KsbzkOiAyMDE1xOo51MI1 yNUgMTc6NDgNCsrVvP7IyzogZG90c0BpZXRmLm9yZw0K1vfM4jogUmU6IFtEb3RzXSB3aHQgYXJl IHRoZSAiZ29vZCByZWFzb25zIiB0byBvcHBvc2UgInRlbGVtZXRyeSB1c2VkIGZvciBkZXRlY3Rp b24vY2xhc3NpZmljYXRpb24vdHJhY2ViYWNrIG9mIEREb1MgYXR0YWNrcyINCg0KT24gNSBTZXAg MjAxNSwgYXQgMzozOCwgTGluZGEgRHVuYmFyIHdyb3RlOg0KDQo+IENhbiB5b3UgZWxhYm9yYXRl IHRoZSAiZ29vZCByZWFzb25zIiBmb3Igb3Bwb3NpbmcgInRlbGVtZXRyeSB1c2VkIGZvciANCj4g dGhlIGRldGVjdGlvbi9jbGFzc2lmaWNhdGlvbi90cmFjZWJhY2sgb2YgRERvUyBhdHRhY2tzIj8N Cg0KSSdtIG5vdCBvcHBvc2VkIHRvIHRoZSB1c2Ugb2YgdGVsZW1ldHJ5IGZvciB0aGF0IHB1cnBv c2UgLSBJIHVzZSBpdCBldmVyeSBkYXksIGFzIGRvIG1hbnksIG1hbnkgb3RoZXJzLi4NCg0KV2hh dCBJJ20gb3Bwb3NlZCB0byBpcyB0aGlzIFdHIGdyb3VwIGdldHRpbmcgaW52b2x2ZWQgaW4gdGhp bmdzIGJleW9uZCBpdHMgc2NvcGUgYW5kIHRyeWluZyB0byByZWRlZmluZSB0aGUgd29ybGQuDQoN CldlIG5lZWQgdG8gZm9jdXMgb24gKm9uZSB0aGluZyogLSB0aGUgYWJpbGl0eSB0byBhdXRvbWF0 aWNhbGx5IHN1bW1vbiAod2l0aCB0aGUgc2lkZSBiZW5lZml0IG9mIGF1dG9wcm92aXNpb25pbmcp IEREb1MgbWl0aWdhdGlvbiBvbiBkZW1hbmQuDQpbRnJhbmtdOiB5ZXMsIHRoYXQncyBvdXIgZW5k IGdvYWwuIEJ1dCwgbXkgcXVlc3Rpb24gaXMgaG93IHRvIHJlYWNoIGl0IHdpdGhvdXQgc3BlY2lm eWluZyB0aGUgaW5mb3JtYXRpb24gY29udGVudCBhbmQgZm9ybWF0IChwcmVmZXIgdGhlIGV4aXN0 aW5nIG9uZSkgY29tbXVuaWNhdGVkIGJldHdlZW4gZGlzdHJpYnV0ZWQgYW50aS1kZG9zIGVsZW1l bnRzPw0KDQpXaGF0J3MgbWVhbnQgYnkgdGhlIGN1cnJlbnQgbGFuZ3VhZ2UgaW4gdGhlIFdHIGNo YXJ0ZXIgaXMgdGhhdCB1dGlsaXppbmcgc3VjaCB0ZWxlbWV0cnkgaW4gYSBzaXR1YXRpb25hbGx5 LWFwcHJvcHJpYXRlIHdheSB0byBkZXRlcm1pbmUgbWl0aWdhdGlvbiByZXNwb25zZSBpcyBzb21l dGhpbmcgd2UgbWF5IHdpc2ggdG8gaW5jb3Jwb3JhdGUgaW50byB0aGUgRE9UUyBzaWduYWwgY29t cG9zaXRpb24gcHJvY2VzcywgYXQgc29tZSBwb2ludC4NCltGcmFua106IHdvdWxkIHlvdSBwbGVh c2UgY2xhcmlmeTogd2hhdCBpcyAiIGEgc2l0dWF0aW9uYWxseS1hcHByb3ByaWF0ZSB3YXkgIj8g d2hhdCBkb2VzIGl0IG1lYW4gYnkgIiBpbmNvcnBvcmF0ZSBpbnRvIHRoZSBET1RTIHNpZ25hbCBj b21wb3NpdGlvbiBwcm9jZXNzICI/DQoNCkkga25vdyB0aGlzIGJlY2F1c2UgKkknbSB0aGUgcGVy c29uIHdobyBpbnNlcnRlZCB0aGF0IGxhbmd1YWdlIGludG8gdGhlIGNoYXJ0ZXIqLg0KDQpUaGlz IFdHIGhhcyBubyBhdXRob3JpdHkgdG8gZGVmaW5lIG9yIHJlZGVmaW5lIHRlbGVtZXRyeSBmb3Jt YXRzLiAgV2UgaGF2ZSBlbm91Z2ggdG8gZG8gcmlnaHQgbm93IGluIHRlcm1zIG9mIGRlZmluaW5n IERPVFM7IGl0IG1ha2VzIHplcm8gc2Vuc2UgdG8gZ28gaGFyaW5nIG9mZiBpbiB0aGUgZGlyZWN0 aW9uIG9mIG1lc3NpbmcgYWJvdXQgd2l0aCB0ZWxlbWV0cnkgZm9ybWF0cyB3aGljaCB3ZSBoYXZl IG5vIGF1dGhvcml0eSB0byBjaGFuZ2UsIGFuZCB3aGljaCBhbHJlYWR5IHdvcmsgdmVyeSB3ZWxs IHRvZGF5Lg0KW0ZyYW5rXTogSSBhZ3JlZSBET1RTIFdHIGNhbm5vdCByZWRlZmluZSB0aGUgdGVs ZW1ldHJ5IGZvcm1hdHMuIFdoYXQgd2Ugc2hvdWxkIGRvIGlzIGRlZmluaW5nIHRoZSBpbmZvcm1h dGlvbiBtb2RlbCBhbmQgYWNjb3JkaW5nIGRhdGEgbW9kZWwgYmFzZWQgb24gYXBwcm9wcmlhdGUg ZXhpc3RpbmcgZm9ybWF0cyAoeG1sLCBpcGZpeCwganNvbiwgZXRjKS4gQW5kIHRoZSByZWFzb24g YmVoaW5kcyB3aGljaCBpcyBjdXJyZW50IGluZm9ybWF0aW9uIG1vZGVsIGRvZXMgbm90IGV4aXN0 cywgb3IgbWlzcyBzb21ldGhpbmcgdG8gc3VwcG9ydCBuZXcgc2NlbmFyaW9zLiBNSUxFIGFuZCBT QUNNIFdHIHdpdGggdGhlIHNpbWlsYXIgZ29hbHMgYXJlIGV4YWN0bHkgYWN0aW5nIHRoaXMgd2F5 Lg0KDQpUaGVyZSBpcyBubyBidXJuaW5nIG5lZWQgdG8gYWx0ZXIgSVBGSVguICBBbHRlcmluZyBJ UEZJWCBmcm9tIGEgdGVsZW1ldHJ5IHN0YW5kcG9pbnQgaXMgbm90IHdpdGhpbiB0aGUgcmVtaXQg b2YgdGhpcyBncm91cC4gIENvbnRpbnVpbmcgdG8gc3RyYXkgaW50byBvZmYtY2hhcnRlciBhcmVh cyBpcyBub3QgcHJvZHVjdGl2ZSBhbmQgZG9lcyBub3QgYWR2YW5jZSBhY2hpZXZpbmcgdGhlIGdv YWwgb2YgdGhpcyBXRywgd2hpY2ggaXMgYXV0b21hdGVkIHNpZ25hbGluZyBmb3IgRERvUyBtaXRp Z2F0aW9uIGFzc2lzdGFuY2UuDQpbRnJhbmtdOiBJIGFtIHN0aWxsIGNvbmZ1c2VkIG9uIHlvdXIg b3BpbmlvbiBhYm91dCB0aGUgbmVjZXNzaXR5IG9mIHNwZWNpZnlpbmcgdGhlIHNpZ25hbGluZyBi ZXR3ZWVuIHRoZSBhbnRpLWRkb3MgZWxlbWVudHMuIENvdWxkIHlvdSBwbGVhc2UgY2xhcmlmeSB0 byBtZT8gVGhhbmtzIQ0KDQpCLlIuDQpGcmFuaw0KDQpXZSBuZWVkIHRvIGZvY3VzIG9uIHRoZSBt YXR0ZXIgYXQgaGFuZC4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClJv bGFuZCBEb2JiaW5zIDxyZG9iYmluc0BhcmJvci5uZXQ+DQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpEb3RzIG1haWxpbmcgbGlzdA0KRG90c0BpZXRm Lm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3RzDQo= From nobody Sun Sep 6 23:59:36 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28BD01B4D5F for ; Sun, 6 Sep 2015 23:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.078 X-Spam-Level: ** X-Spam-Status: No, score=2.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 G8BWFSSrrBK0 for ; Sun, 6 Sep 2015 23:59:33 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39C711B4D5E for ; Sun, 6 Sep 2015 23:59:33 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BXF68309; Mon, 07 Sep 2015 06:59:31 +0000 (GMT) Received: from SZXEMA414-HUB.china.huawei.com (10.82.72.73) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 7 Sep 2015 07:59:30 +0100 Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.68]) by SZXEMA414-HUB.china.huawei.com ([10.82.72.73]) with mapi id 14.03.0235.001; Mon, 7 Sep 2015 14:59:24 +0800 From: "Xialiang (Frank)" To: Roland Dobbins Thread-Topic: [Dots] DOTS: next steps - call for editor volunteers for use case draft and requirements draft Thread-Index: AQHQ1+Rbj3GGCU8ZsUuh3PHZFemaaZ4dsOiAgAD+mgCAAIxFkP//hNIAgACw55D//4gLgIAAegqAgA0JQwCABAfccP//sCCAABHfEUA= Date: Mon, 7 Sep 2015 06:59:23 +0000 Message-ID: References: <359EC4B99E040048A7131E0F4E113AFCD94F1C56@marathon> <55D01F5E.4070009@gondrom.org> <55DDA4A9.3050603@inria.fr> <8775DC11-7FE3-4A02-89EE-E6BDAC6A1C13@arbor.net> <55DF1EB7.9000703@cisco.com> <7F42E6D6-FFFA-45BD-B77C-F4FCC766FF80@arbor.net> In-Reply-To: <7F42E6D6-FFFA-45BD-B77C-F4FCC766FF80@arbor.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.43.91] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "dots@ietf.org" Subject: [Dots] =?gb2312?b?tPC4tDogIERPVFM6IG5leHQgc3RlcHMgLSBjYWxsIGZv?= =?gb2312?b?ciBlZGl0b3Igdm9sdW50ZWVycyBmb3IgdXNlIGNhc2UgZHJhZnQgYW5kIHJl?= =?gb2312?b?cXVpcmVtZW50cyBkcmFmdA==?= X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2015 06:59:35 -0000 UGxlYXNlIHNlZSBteSByZXNwb25zZSBpbmxpbmU6DQoNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8 /sjLOiBEb3RzIFttYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3JnXSC0+rHtIFJvbGFuZCBEb2Ji aW5zDQq3osvNyrG85DogMjAxNcTqOdTCN8jVIDE0OjIxDQrK1bz+yMs6IGRvdHNAaWV0Zi5vcmcN Ctb3zOI6IFJlOiBbRG90c10gRE9UUzogbmV4dCBzdGVwcyAtIGNhbGwgZm9yIGVkaXRvciB2b2x1 bnRlZXJzIGZvciB1c2UgY2FzZSBkcmFmdCBhbmQgcmVxdWlyZW1lbnRzIGRyYWZ0DQoNCk9uIDcg U2VwIDIwMTUsIGF0IDExOjM1LCBYaWFsaWFuZyAoRnJhbmspIHdyb3RlOg0KDQo+IEluIHlvdXIg bWluZCwgd2hpY2gga2luZCBvZiB0aHJlYXQgaW5mb3JtYXRpb24gaXMgYmFkIGluZm9ybWF0aW9u LCBhbmQgDQo+IHdoaWNoIGlzIGdvb2Q/DQoNCkknbSBub3QgQ2hyaXMsIGJ1dCB3aGF0IGhlIG1l YW5zIGlzIHRoYXQgaGF2aW5nIGluY29tcGxldGUvaW5hY2N1cmF0ZSB0ZWxlbWV0cnkgaXMgd29y c2UgdGhhbiBoYXZpbmcgbm9uZSBhdCBhbGwuDQpbRnJhbmtdOiBJdCdzIG5vdCB0aGUgcHJvYmxl bSBvZiB0ZWxlbWV0cnkgaXRzZWxmLCBpdCdzIG1vcmUgb2YgdGhlIHByb2JsZW0gYWJvdXQgdGhl IGNvbGxlY3Rpb24gbWVjaGFuaXNtIGFuZCB0aGUgYW5hbHlzaXMgYWxnb3JpdGhtIG9uIHRoZW0u IFdoYXQgSSBtZWFuIGlzIElQRklYIHRlbGVtZXRyeSBpcyB1c2VmdWwgYW5kIGdvb2QgaW5mb3Jt YXRpb24sIGFzIGl0IGlzIHdpZGVseSB1c2VkIGluIGluZHVzdHJ5IGluIG1hbnkgY2FzZXMuDQoN Cj4gaWRlbnRpZnkgdGhlIG1pc3NpbmcgSVBGSVggbWV0cmljcyBmb3Igc3BlY2lmaWMgbmV0d29y ayB0aHJlYXRzIA0KPiBtb25pdG9yaW5nIGFuZCBwcm9wb3NlIHN1cHBsZW1lbnQgdG8gY3VycmVu dCBJUEZJWCBtZXRyaWNzIHNldCwgd2hpY2ggDQo+IGRvZXMgbm90IHJlcXVpcmUgbW9kaWZ5aW5n IHRoZSBJUEZJWCBmb3JtYXQuDQoNClRoaXMgaXMgbm90IHdpdGhpbiB0aGUgcmVtaXQgb2YgdGhp cyBXRy4gIEFuZCBJUEZJWCBpcyBJUEZJWDsgb3RoZXIgdGhhbiBlbnRlcnByaXNlIGVsZW1lbnRz LCB0aGVyZSBpcyBubyBtb2RpZnlpbmcgaXQgd2l0aG91dCByZW9wZW5pbmcgaXQuDQoNCldlIG5l ZWQgdG8gZm9jdXMgb24gZ2V0dGluZyB0aGUgYWN0dWFsIERPVFMgcHJvdG9jb2wgc3RhbmRhcmQg ZGV2aXNlZCBiZWZvcmUgZ29pbmcgYXJvdW5kIHRyeWluZyB0byB0YWtlIG90aGVyIFdHJ3Mgd29y ayBmcm9tIHRoZW0uDQoNCkFsbCB0aGlzIGRpc2N1c3Npb24gYWJvdXQgSVBGSVggaGFzIG5vdCBh ZHZhbmNlZCB0aGUgV0cncyBpb3RhIGJ5IG9uZSBjZW50aW1ldGVyLiAgQ2FuIHdlIHBsZWFzZSBm b2N1cyBvbiB0aGUgbWF0dGVyIGF0IGhhbmQ/DQpbRnJhbmtdOiBvaywgbGV0J3MgcHVzaCBhc2lk ZSB0aGlzIHNwZWNpZmljIGRpc2N1c3Npb24gYWJvdXQgc29sdXRpb24uIEl0J3MgbW9yZSBlZmZl Y3RpdmUgdG8gc3RhcnQgd2l0aCB1c2UgY2FzZXMgYW5kIHJlcXVpcmVtZW50cy4NCg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClJvbGFuZCBEb2JiaW5zIDxyZG9iYmluc0Bh cmJvci5uZXQ+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpEb3RzIG1haWxpbmcgbGlzdA0KRG90c0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9kb3RzDQo= From nobody Mon Sep 7 00:01:04 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4FCF1B4DCA for ; Mon, 7 Sep 2015 00:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham 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 1kWAtHyLkp3V for ; Mon, 7 Sep 2015 00:00:58 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B460D1B4DC5 for ; Mon, 7 Sep 2015 00:00:58 -0700 (PDT) Received: by pacfv12 with SMTP id fv12so90206359pac.2 for ; Mon, 07 Sep 2015 00:00:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-type; bh=DDMx1pJ31hvzBxL/iShO95MmeqCScKTAh60BCEntvME=; b=BC5TWoUIfPzdNFXmLF3QkorXdWZMFPnab/daQe1g2e/PcyZTTgUisUIl9VlxOU/OJh fk1iVP8Pe+aSSC+F+4UiqmZhlUkbqgSHD/bSMc+TNc7Yx1vwNHnyjn91EbqIlxdhNqJW nod113xhIbvaSbg2Ej4yR2fhj6fOibJ09ejnU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-type; bh=DDMx1pJ31hvzBxL/iShO95MmeqCScKTAh60BCEntvME=; b=lDEh8EpWjUJ9w1Rjn+daN55xvGlr+VyPIPFaI1u9kEnvnDMUbeRVjzdUHYxCBdXdl4 5v5skkibNYZ++eTEqkY38waNf9ORsPXWZoKXhiP7VIxtThY2BIaZFB5uSmo23s0B+kAl HuvzGrCFbFXLMZANgtGAcY6/ciibeXS1qrLGL/KlJgBbY7cVFpN2nYwIVWLQFtj38Dgx 7bKNYJJemowlp5ITV3FWRhxpEyBd+xVhH4JrhYOgjf+1XIeB3IClzXIRmm3sg4bR1skK kV42FQW+t1wNWqlLHdYU3GMhFeKQwclisknsiOtoZIrELNuM2AiyRp0b1+aCyGtnhFWR g85g== X-Gm-Message-State: ALoCoQng0KEy5Y2eypXzXX4ApLY/QMXvw+r0r2zrRcnxYrAG+1AB9JPuzubuQtmOUiJtHO5j9EMm X-Received: by 10.68.250.5 with SMTP id yy5mr42464547pbc.34.1441609258160; Mon, 07 Sep 2015 00:00:58 -0700 (PDT) Received: from [172.19.254.107] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id x6sm10722368pbt.3.2015.09.07.00.00.56 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 07 Sep 2015 00:00:57 -0700 (PDT) From: "Roland Dobbins" To: dots@ietf.org Date: Mon, 07 Sep 2015 14:00:54 +0700 Message-ID: <4C8F81B0-E982-4F7A-B859-46A5EB48E67A@arbor.net> In-Reply-To: References: <359EC4B99E040048A7131E0F4E113AFCD94F1C56@marathon> <55D01F5E.4070009@gondrom.org> <55DDA4A9.3050603@inria.fr> <8775DC11-7FE3-4A02-89EE-E6BDAC6A1C13@arbor.net> <4A95BA014132FF49AE685FAB4B9F17F657D21479@dfweml701-chm> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Subject: Re: [Dots] wht are the "good reasons" to oppose "telemetry used for detection/classification/traceback of DDoS attacks" X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2015 07:01:04 -0000 On 7 Sep 2015, at 13:49, Xialiang (Frank) wrote: > [Frank]: yes, that's our end goal. But, my question is how to reach it > without specifying the information content and format (prefer the > existing one) communicated between distributed anti-ddos elements? We intend to do just that. But it has nothing to do with these changes to IPFIX you're pushing. > [Frank]: would you please clarify: what is " a > situationally-appropriate way "? what does it mean by " incorporate > into the DOTS signal composition process "? It means that IPFIX or another existing standard may be suitable to serve as the basis for the DOTS protocol, nothing more. > [Frank]: I agree DOTS WG cannot redefine the telemetry formats. Then why do you keep pushing do just that? > What we should do is defining the information model and according data > model based on appropriate existing formats (xml, ipfix, json, etc). > And the reason behinds which is current information model does not > exists, or miss something to support new scenarios. MILE and SACM WG > with the similar goals are exactly acting this way. Yes. But the modifications you keep pushing for IPFIX do not fall under the category of inter-node signaling from supplicants to mitigation elements, and between mitigation elements, and so are inapplicable. > [Frank]: I am still confused on your opinion about the necessity of > specifying the signaling between the anti-ddos elements. Could you > please clarify to me? Thanks! There is no basis for your confusion, as I have clearly and consistently stated that such signaling is certainly within our remit. Our first priority is signaling from the supplicant to the DDoS mitigation elements (the supplicant itself may well be a DDoS mitigation element). But this continual harping on draft-fu-ipfix-network-security-01 is unhelpful, as it has nothing to do with signaling from supplicants to mitigation elements. It is a distraction from our actual goals. Let's please table draft-fu-ipfix-network-security-01 and similar proposals until after the initial DOTS specification has been finalized and is on the standards track. ----------------------------------- Roland Dobbins From nobody Mon Sep 7 00:15:36 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA0AB1B3185 for ; Mon, 7 Sep 2015 00:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham 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 dBK7mslCivcb for ; Mon, 7 Sep 2015 00:15:33 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B76441B30AD for ; Mon, 7 Sep 2015 00:15:33 -0700 (PDT) Received: by padhk3 with SMTP id hk3so3749556pad.3 for ; Mon, 07 Sep 2015 00:15:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-type; bh=688mKXYQz+kXhaamMcAUV0guwfzyjSiaP0CV9hiCvKI=; b=amlVcUT89shQMohSpNvgkVitdOgWuxr8V4SnvmNxGPW8eyD0IXqyQeugx9znHaKZMV 0tH6eaZDaHpHRBXNtxOsA8IBMxsOTYhQkfHbTrdrgG4GrXVQgqwg2egNN7y07dWXx9aN 8ckR1Hhj7a0fbAm5p27Tohs8gFjNYAjH8o5eE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-type; bh=688mKXYQz+kXhaamMcAUV0guwfzyjSiaP0CV9hiCvKI=; b=cC2ddbbjbaFguQbJD1+iaoixLNqNiT8ueKZIyxo9lM8im84PEqdevhMe/ZeeQpzg8p qPfC1m2hHfDudWbMZylCvLwKEsSYN7ap9aFKjo74PTovpZWENI6Oohti3VCi4khjpGFu 4mVczizgfnWkE4t7kxwzPFPkFtJtN9nqubc4WikMf1caqM1qYCd0bwb8xDtr0huYW/Tt 86QcctYmqWJysCGxYJ2ulM6nfbEocJZlrnK4FewT+NxdYpTHVjpAEKGcKUllqJPTJPes lBA8RRwyGlNtoV2+wkIFIXSm3yE4v/ZXH2YUqgwLidQZmiV/c+LTqwgVfgtvvgRvptJE DBAA== X-Gm-Message-State: ALoCoQmjw//t6eb94WB9Udkd/Z5F9XQ2e3gdAiHQmzVPpuYf8i8+4Gm9p/6hAdEtpDJ8QKich4UZ X-Received: by 10.68.162.99 with SMTP id xz3mr43113310pbb.134.1441610133367; Mon, 07 Sep 2015 00:15:33 -0700 (PDT) Received: from [172.19.254.107] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id dd5sm7613131pdb.64.2015.09.07.00.15.31 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 07 Sep 2015 00:15:32 -0700 (PDT) From: "Roland Dobbins" To: dots@ietf.org Date: Mon, 07 Sep 2015 14:15:29 +0700 Message-ID: <77F46E54-568D-4ADF-A8F4-AB8F14C3DD60@arbor.net> In-Reply-To: References: <359EC4B99E040048A7131E0F4E113AFCD94F1C56@marathon> <55D01F5E.4070009@gondrom.org> <55DDA4A9.3050603@inria.fr> <8775DC11-7FE3-4A02-89EE-E6BDAC6A1C13@arbor.net> <55DF1EB7.9000703@cisco.com> <7F42E6D6-FFFA-45BD-B77C-F4FCC766FF80@arbor.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Subject: Re: [Dots] DOTS: next steps - call for editor volunteers for use case draft and requirements draft X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2015 07:15:36 -0000 On 7 Sep 2015, at 13:59, Xialiang (Frank) wrote: > What I mean is IPFIX telemetry is useful and good information, as it > is widely used in industry in many cases. Everyone here knows that, thanks. > [Frank]: ok, let's push aside this specific discussion about solution. > It's more effective to start with use cases and requirements. Concur 100%, thanks! ----------------------------------- Roland Dobbins From nobody Mon Sep 7 10:09:47 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04C141B436D for ; Mon, 7 Sep 2015 10:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 XWadis-nXZId for ; Mon, 7 Sep 2015 10:09:44 -0700 (PDT) Received: from mail-qg0-f97.google.com (mail-qg0-f97.google.com [209.85.192.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C867E1B472C for ; Mon, 7 Sep 2015 10:09:42 -0700 (PDT) Received: by qgt47 with SMTP id 47so4494461qgt.0 for ; Mon, 07 Sep 2015 10:09:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :user-agent:content-type:content-id:content-transfer-encoding :mime-version; bh=naSmkPNy1+R4ztezc2X+mDp4hKmvCEdFFFXj0wHOqXA=; b=Aum0Vxc8IwjDjXOMvVD/uN0xcC9GLiICLrmar5hfuIKlwKsJxPCj3PR8EMWICZE7WZ 7tuU6Fnmefcuu0Mt2oTHDm5OxOHevBYjx6E1L8zS8OJKW6qZkk/kyxbDRwrIEcPtZg7I eJg6VqowJNAzTXhFusIjTbaPx/buAYREO7AmXKg+q5/PP/6WYsQRewywCm571hK0sdRG pqSmcCIHZcCVxM3shy4vtcwmLx9DLXjGmRH0LkNsSSyfzyItgtLhpvevdJV5Mrs55H/n JlICCD22Ws4jubGEgEKBEQh4A5Dj+D+yO6f01faDs+M5NmgZZJGZri0cca8MXr47JXaQ zB6g== X-Gm-Message-State: ALoCoQm+NdMVY9t1qBYaof7c26MQ2Ex8cSk+50zFrqVA/UbnV5HM8fzJaN5NBTYHiKz/ABQmHCQilOPzE/N4V0np9M/uCZlCDQ== X-Received: by 10.140.42.8 with SMTP id b8mr25858598qga.58.1441645781903; Mon, 07 Sep 2015 10:09:41 -0700 (PDT) Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by smtp-relay.gmail.com with ESMTPS id v86sm130604qkv.0.2015.09.07.10.09.41 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 07 Sep 2015 10:09:41 -0700 (PDT) X-Relaying-Domain: verisign.com Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01 [10.173.152.255]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id t87H9eiD000827 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 7 Sep 2015 13:09:41 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Mon, 7 Sep 2015 13:09:40 -0400 From: "Teague, Nik" To: Tobias Gondrom , "dots@ietf.org" Thread-Topic: [Dots] DOTS: next steps - call for editor volunteers for use case draft and requirements draft Thread-Index: AQHQ1+RatmYVa/zAJU2XXMMDdxNWRZ4eehOAgAGiZgCABhcdgIAA2ZUAgAq20gA= Date: Mon, 7 Sep 2015 17:09:39 +0000 Message-ID: References: <359EC4B99E040048A7131E0F4E113AFCD94F1C56@marathon> <55D01F5E.4070009@gondrom.org> <55DDA4A9.3050603@inria.fr> <55DF03A4.8020105@cisco.com> <55E4D60A.50002@gondrom.org> In-Reply-To: <55E4D60A.50002@gondrom.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.4.150722 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] DOTS: next steps - call for editor volunteers for use case draft and requirements draft X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2015 17:09:46 -0000 SGksDQoNCk9uIDMxLzA4LzIwMTUgMjM6MzIsICJEb3RzIG9uIGJlaGFsZiBvZiBUb2JpYXMgR29u ZHJvbSINCjxkb3RzLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHRvYmlhcy5nb25kcm9t QGdvbmRyb20ub3JnPiB3cm90ZToNCg0KPkRlYXIgYWxsLCANCj4NCj5hcG9sb2dpZXMuIFJvbWFu IGFuZCBJIGFyZSBjdXJyZW50bHkgc3RpbGwgZ29pbmcgdGhyb3VnaCB0aGUgKGxvbmcpIGxpc3QN Cj5vZiBlZGl0aW5nIHZvbHVudGVlcnMuIFdoaWNoIGlzIGEgZ3JlYXQgcGxhY2UgdG8gYmUgaW4g Zm9yIG91ciBXRy4gSQ0KPmd1ZXNzLCB3ZSBzaG91bGQgYmUgZG9uZSBieSB0b21vcnJvdy4NCj4N Cj4NCj5JbiBhZGRpdGlvbiB0byB0aGUgZWRpdGluZyB2b2x1bnRlZXJzLCBJIGFncmVlIHRoYXQg ZGVzaWduIHRlYW1zIGZvciB0aGUNCj50d28gZHJhZnRzIG1pZ2h0IGJlIHVzZWZ1bC4gQWx3YXlz IGtlZXAgaW4gbWluZCB0aGF0IHRoZSBlZGl0b3IncyBkdXR5IGlzDQo+dG8gY2FwdHVyZSB0aGUg aW5wdXQgZnJvbSB0aGUgV0cgYW5kIHdyaXRlIGl0IGRvd24uIFNvIGV2ZXJ5b25lIGNhbg0KPmVx dWFsbHkgY29udHJpYnV0ZS4gQW5kIGEgZGVzaWduIHRlYW0gdG8gd29yaw0KPiBvdXQgdGhlIGRl dGFpbHMgc291bmRzIHVzZWZ1bC4NCg0KSG93IGNsb3NlIGFyZSB3ZSB0byBnZXR0aW5nIHRoaXMg dW5kZXJ3YXk/ICBJ4oCZbSBrZWVuIGFzIEkgY2FuIHNlZSBvdGhlcnMNCmFyZSB0byBnZXQgdGhp bmdzIG1vdmluZyBhbmQgaXQgd291bGQgYmUgZ3JlYXQgaWYgd2UgY2FuIGhhdmUgc29tZSBzb2xp ZA0KY29udHJpYnV0aW9ucy9kaXNjdXNzaW9ucyBnb2luZyBiZWZvcmUgdGhlIGludGVyaW0gbWVl dGluZy4NCg0KRG8geW91IGhhdmUgYW55IGlkZWFzIHJlZ2FyZGluZyBkZXNpZ24gdGVhbXMgb3Ig d2UgY2FuIHNlbGYgb3JnYW5pc2U/DQoNClRoYW5rcywNCg0KLU5paw0KDQo= From nobody Tue Sep 8 08:21:54 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1DA1B43E1 for ; Tue, 8 Sep 2015 08:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 b4nl9to2SrB1 for ; Tue, 8 Sep 2015 08:21:51 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE01F1B49CF for ; Tue, 8 Sep 2015 08:21:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1857; q=dns/txt; s=iport; t=1441725711; x=1442935311; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=TSUcnL/BagWxEi6YXZTjtNf9KuX7wcK+vE4A7as8QXg=; b=X1/9+MEokh7Jxr5I6Y6Itp1acXx3eUcqxEYwjQO1cz1QnDHzxpje4bOo pkQuDxZObF48QnQPgsIRnLMU4CghyQCF/bvS3rjuiT+ovbSLgy0ca6IFD bE/QwFVaY8YVhEWBzfGwPCIg/5LlaN4bHS3FB/brgbQWOkMF2We+Nsf1L w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BsAgAy/O5V/xbLJq1dg3dpgyS6BgEJgW0KhXkCgWsUAQEBAQEBAYEKhCMBAQEDAQEBASAPAQU2ChELDgoCAgUWBAcCAgkDAgECARUwBgEMBgIBAYgiCA23A5QBAQEBAQEBAQEBAQEBAQEBAQEBFgSBIoVRhHuFE4JpgUMBBIcxjiSMeoFMhDOCfJF8JoJCgVoiM4hJAQEB X-IronPort-AV: E=Sophos;i="5.17,490,1437436800"; d="scan'208";a="611469753" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 08 Sep 2015 15:21:48 +0000 Received: from [10.98.149.195] (bxb-fandreas-8812.cisco.com [10.98.149.195]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t88FLllr021116; Tue, 8 Sep 2015 15:21:48 GMT To: Roland Dobbins , dots@ietf.org References: <359EC4B99E040048A7131E0F4E113AFCD94F1C56@marathon> <55D01F5E.4070009@gondrom.org> <55DDA4A9.3050603@inria.fr> <8775DC11-7FE3-4A02-89EE-E6BDAC6A1C13@arbor.net> <4A95BA014132FF49AE685FAB4B9F17F657D21479@dfweml701-chm> From: Flemming Andreasen Message-ID: <55EEFD32.3090601@cisco.com> Date: Tue, 8 Sep 2015 11:22:26 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Dots] wht are the "good reasons" to oppose "telemetry used for detection/classification/traceback of DDoS attacks" X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 15:21:52 -0000 On 9/5/15 5:52 AM, Roland Dobbins wrote: > On 5 Sep 2015, at 11:34, Xiaohong Deng wrote: > >> What makes you think so? To our knowledge, it¹s been already >> happening in >> industry. > > Yes, it's used for this purpose every day, by networks which have that > capability, . But that isn't the point. > > The endpoint nodes which require DDoS mitigation assistance and/or the > networks on which they reside may well have no organic ability to > perform telemetry generation and/or collection/analysis of same. > > The goal of this WG is to produce a standards-based protocol, DOTS, > which can be used by anything and everything with an IP address to > programmatically summon DDoS mitigation assistance; this has the > additional side-benefit of aiding auto-provisioning of DDoS mitigation > services. I think this is an oversimplification of the WG's goal as per the charter text as well. One of the use case scenarios I would like to see covered is the case where an on-premise (e.g. enterprise) DDoS detector signals an upstream entity (e.g. SP or cloud provider) for help in mitigating a DDoS attack, and as part of that signaling, baseline information as well as locally known information about the attack is provided to that upstream entity so detection and mitigation doesn't have to start from scratch. Do you agree this is in scope ? Thanks -- Flemming > > That is quite enough for us to work on, without straying into areas > which are not our focus, and which are not in dire need of remediation > in the first place. Let's please focus on the task at hand. > > ----------------------------------- > Roland Dobbins > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Tue Sep 8 08:25:58 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE5DA1B3BF5 for ; Tue, 8 Sep 2015 08:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 AiEvv-Wk5f3k for ; Tue, 8 Sep 2015 08:25:54 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13F421B4699 for ; Tue, 8 Sep 2015 08:25:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1261; q=dns/txt; s=iport; t=1441725954; x=1442935554; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=oQNlBqcBsXNjBeNf+L9KIdkAvm0eHvflMeLXMHp/pPw=; b=Li9ak4EYXK8pNGuJCIoiOJ2A1oktOGdTSouBX/I0ckoXXSXNsk+ZJBzh VQOSATNz5PsiUplwosp/m7j26AJr96E5yQp73DNm2bUSyHxCRzWh/58rO FKYmBAciJ0bukeXWYtlGULrkWd+2oYMaFctUmx0UHk83+3S3mbo6HYbRs w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BFAgCj/O5V/xbLJq1TCoN3ab0qAQmBbQqFeQKBaxQBAQEBAQEBgQqEJAEBBAEBARobNgoRCw4KCRYPCQMCAQIBFTAGAQwGAgEBiCoNywYBAQEBAQEBAQEBAQEBAQEBAQEWBIZzhHuBPQGCcWSELAEEhzGOJIx6gUyEM4J8jhCDbCaCHSWBWiIziEkBAQE X-IronPort-AV: E=Sophos;i="5.17,490,1437436800"; d="scan'208";a="629593272" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 08 Sep 2015 15:25:52 +0000 Received: from [10.98.149.195] (bxb-fandreas-8812.cisco.com [10.98.149.195]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t88FPpY2022044; Tue, 8 Sep 2015 15:25:51 GMT To: Roland Dobbins , dots@ietf.org References: <359EC4B99E040048A7131E0F4E113AFCD94F1C56@marathon> <55D01F5E.4070009@gondrom.org> <55DDA4A9.3050603@inria.fr> <8775DC11-7FE3-4A02-89EE-E6BDAC6A1C13@arbor.net> <55DF1EB7.9000703@cisco.com> <7F42E6D6-FFFA-45BD-B77C-F4FCC766FF80@arbor.net> From: Flemming Andreasen Message-ID: <55EEFE25.3090501@cisco.com> Date: Tue, 8 Sep 2015 11:26:29 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <7F42E6D6-FFFA-45BD-B77C-F4FCC766FF80@arbor.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dots] DOTS: next steps - call for editor volunteers for use case draft and requirements draft X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 15:25:56 -0000 On 9/7/15 2:20 AM, Roland Dobbins wrote: > On 7 Sep 2015, at 11:35, Xialiang (Frank) wrote: > >> In your mind, which kind of threat information is bad information, >> and which is good? > > I'm not Chris, but what he means is that having incomplete Disagree > /inaccurate Agree > telemetry is worse than having none at all. > >> identify the missing IPFIX metrics for specific network threats >> monitoring and propose supplement to current IPFIX metrics set, which >> does not require modifying the IPFIX format. > > This is not within the remit of this WG. And IPFIX is IPFIX; other > than enterprise elements, there is no modifying it without reopening it. > > We need to focus on getting the actual DOTS protocol standard devised > before going around trying to take other WG's work from them. > > All this discussion about IPFIX has not advanced the WG's iota by one > centimeter. Can we please focus on the matter at hand? > I agree - use cases and requirements first. Thanks -- Flemming > ----------------------------------- > Roland Dobbins > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > From nobody Tue Sep 8 08:28:32 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EED51B42DD for ; Tue, 8 Sep 2015 08:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 lq2EHCCGe5r6 for ; Tue, 8 Sep 2015 08:28:30 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EADC81B42BA for ; Tue, 8 Sep 2015 08:28:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1413; q=dns/txt; s=iport; t=1441726109; x=1442935709; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=jpyPNkPXWmrTFVPYg7XMpSqLnWWJX25HBiqqL16ZMjg=; b=OgC2wSRCzKUqYxHkEdgq7NHj1iegphb+gldVB2j1Osk9YBpXBlOG1yzs Xqvw3FAoamRloUqI9Vsq9HN9/iY6mpd6BmU8XH3QCBE61+XqkQzADqHhC EONKK+yXhzoLOoO5iyTc+uwxuD2y/i09X7YrOiPwo3edEw/V0ihQ64Eq4 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C4BQDs/e5V/5pdJa1dgyOBPYMkuhCHcAKBMzkTAQEBAQEBAYEKhCQBAQQdBhVAARALGAICBRYLAgIJAwIBAgFFBg0GAgEBiCq3GJQBAQEBAQEBAQEBAQEBAQEBAQEbgSKFUYR7gT0Bg04HgmmBQwEElVWMeoh7kXwmgh0lgVoiM4hJAQEB X-IronPort-AV: E=Sophos;i="5.17,490,1437436800"; d="scan'208";a="185328995" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-2.cisco.com with ESMTP; 08 Sep 2015 15:28:29 +0000 Received: from [10.98.149.195] (bxb-fandreas-8812.cisco.com [10.98.149.195]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t88FSSDX006570; Tue, 8 Sep 2015 15:28:28 GMT To: Christopher Morrow References: <359EC4B99E040048A7131E0F4E113AFCD94F1C56@marathon> <55D01F5E.4070009@gondrom.org> <55DDA4A9.3050603@inria.fr> <8775DC11-7FE3-4A02-89EE-E6BDAC6A1C13@arbor.net> <55DF1EB7.9000703@cisco.com> From: Flemming Andreasen Message-ID: <55EEFEC2.4020404@cisco.com> Date: Tue, 8 Sep 2015 11:29:06 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Roland Dobbins , dots@ietf.org Subject: Re: [Dots] DOTS: next steps - call for editor volunteers for use case draft and requirements draft X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 15:28:31 -0000 On 9/4/15 5:33 PM, Christopher Morrow wrote: > On Thu, Aug 27, 2015 at 10:29 AM, Flemming Andreasen wrote: >> On 8/27/15 3:12 AM, Roland Dobbins wrote: >>> On 27 Aug 2015, at 17:01, Xialiang (Frank) wrote: >>> >>>> which includes the DDoS related telemetry information as its part, >>> >>> The DDoS telemetry referred to in the WG charter is a starting point for >>> DOTS signaling - the telemetry itself is out-of-scope for this WG. >> Can you clarify the distinction you are making here ? The charter explicitly >> talks about DDoS related telemetry and based on previous discussions, It was >> my understanding that we wanted to provide information about an ongoing >> attack to an upstream entity to enable a more accurate and rapid response by >> that upstream entity. > perhaps part of the problem here is related to 'provide information > about an ongoing attack to an upstream entity....' > > what information? pps? destination ip/network? src-addresses? > port/protocols used? > > I suspect that the upstream provider can very quickly determine the > problem in almost all cases, probably better than the initial > reporter... and I'm not sure it's particularly useful to send upstream > much more than: > "I am seeing an attack to destination X port/protocol Y/Z" I disagree, and I know of at least one DDoS vendor that does as well. -- Flemming From nobody Tue Sep 8 08:37:32 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AACA21B313E for ; Tue, 8 Sep 2015 08:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham 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 1xDb4KB1QGOI for ; Tue, 8 Sep 2015 08:37:29 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A5B01B30F0 for ; Tue, 8 Sep 2015 08:37:29 -0700 (PDT) Received: by pacex6 with SMTP id ex6so127060350pac.0 for ; Tue, 08 Sep 2015 08:37:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-type; bh=g8jtoxKUalDUBh7akhjFkH4j6w78i/7udDmtVVPdwac=; b=OWPTAo1ju/iRoR4jz2x2bnSjlBBNfW6iz1Ud7Kgnc2TpA67XqGOAc+12GIRgR9T17/ LP83Kpcavg4sAdYPPdQ/XGG41MUdkolyjtICRarYuThlALUk/Ba59k5uFOr87cuqLC2Z SogbbbTgtx95TrLn4gCYfRigEjOMKk8KGfZVE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-type; bh=g8jtoxKUalDUBh7akhjFkH4j6w78i/7udDmtVVPdwac=; b=Y0FVIn+3R8UCYh00OQExmFjY+LOD/MDmT+APi56MuJo8f6ww1ictONSkEncMjg+WCy DsxsqOIE5BRuV+frl5yXaM0qNdUvEJzfMTpDbYCl0po6xDAWzSOagafmX3vzQy5APXzu aY6baAgdU0aVPqQO+trh3ClCiXsp/uh3DGVkIQZoPQa81JeeqlVh7Lh7DR4Tuf4KwsPA DaTPQ5l5YrTekjXFcbMZ4cvexmBvOET4uGDejmIcagVwkAkCb7m86KGlPaesZpPae8qB Tf5OYHQZTmFHNJcMzZgMyMfXLnrRfEqiF69KdYQfcbx+UomnSEUOrQzqFW+aCDwAHVwJ PQnA== X-Gm-Message-State: ALoCoQlo2BkH5Pk8Y5pvNtUdRemCxQydAy+gAZ+7XUWzKTKdo3pMSNZkgUIsnfvROFX+hc80AGLL X-Received: by 10.68.57.143 with SMTP id i15mr59867753pbq.104.1441726649075; Tue, 08 Sep 2015 08:37:29 -0700 (PDT) Received: from [172.19.254.107] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id gx11sm3821521pbd.82.2015.09.08.08.37.27 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 08 Sep 2015 08:37:28 -0700 (PDT) From: "Roland Dobbins" To: dots@ietf.org Date: Tue, 08 Sep 2015 22:37:24 +0700 Message-ID: <7D90F6FE-B56D-4AD6-A140-E5CA55B23564@arbor.net> In-Reply-To: <55EEFEC2.4020404@cisco.com> References: <359EC4B99E040048A7131E0F4E113AFCD94F1C56@marathon> <55D01F5E.4070009@gondrom.org> <55DDA4A9.3050603@inria.fr> <8775DC11-7FE3-4A02-89EE-E6BDAC6A1C13@arbor.net> <55DF1EB7.9000703@cisco.com> <55EEFEC2.4020404@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Subject: Re: [Dots] DOTS: next steps - call for editor volunteers for use case draft and requirements draft X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 15:37:30 -0000 On 8 Sep 2015, at 22:29, Flemming Andreasen wrote: > I disagree, and I know of at least one DDoS vendor that does as well. My operational experience with this is that, with some notable exceptions, the endpoint network folks lack the skills and experience to utilize the tools which can give them accurate information in terms of detection/classification/traceback, even if they have those tools. The relatively few endpoint networks who're good at this tend to be ASPs/content providers, themselves; tech companies, some financials, and so forth. Regardless, our task here in DOTS is to standardize signaling; we can't assume that the supplicant has any organic detection/classification/traceback capabilities (though if they do, of course, we want to be able to provide whats relevant to the mitigator). ----------------------------------- Roland Dobbins From nobody Tue Sep 8 09:19:03 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8C661B450E for ; Tue, 8 Sep 2015 09:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 rPDkBjgqDwfx for ; Tue, 8 Sep 2015 09:18:59 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 489531B342E for ; Tue, 8 Sep 2015 09:18:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1533; q=dns/txt; s=iport; t=1441729139; x=1442938739; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=+INYdV4vdK0vMZBYJXzkGE4ib9W5bVdiTK2KgEpWzPM=; b=kk2dfBq/nHC9x/qzvISAgC1GgHGPrVcU4q8xgaiciwqDI9HDdDAN9skG 8FhrYWIpWB91RG9uJmOXviU99C7hLNr8QjmR2/8rJg8+JPvT8oBLZe81C seDzv1/52HASsnkivQmVPl274BPDAqDf5LPfC2iSzVIjJiv3diDuCpGE+ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BFAgCaCe9V/xbLJq1dg3dpvSoBCYFtCoV5AoFuFAEBAQEBAQGBCoQjAQEBAwEBAQEaGzYKBgsLDgoJFg8JAwIBAgEVMAYBDAYCAQEViA0IDcsuAQEBAQEBAQEBAQEBAQEBAQEBFgSGc4R7gT0Bg1WELAEEhzGOJIx6iHuRfCaCHSWBWiIziEkBAQE X-IronPort-AV: E=Sophos;i="5.17,490,1437436800"; d="scan'208";a="629594491" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 08 Sep 2015 16:18:57 +0000 Received: from [10.98.149.195] (bxb-fandreas-8812.cisco.com [10.98.149.195]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t88GIuWE017461; Tue, 8 Sep 2015 16:18:57 GMT To: Roland Dobbins , dots@ietf.org References: <359EC4B99E040048A7131E0F4E113AFCD94F1C56@marathon> <55D01F5E.4070009@gondrom.org> <55DDA4A9.3050603@inria.fr> <8775DC11-7FE3-4A02-89EE-E6BDAC6A1C13@arbor.net> <55DF1EB7.9000703@cisco.com> <55EEFEC2.4020404@cisco.com> <7D90F6FE-B56D-4AD6-A140-E5CA55B23564@arbor.net> From: Flemming Andreasen Message-ID: <55EF0A97.9020603@cisco.com> Date: Tue, 8 Sep 2015 12:19:35 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <7D90F6FE-B56D-4AD6-A140-E5CA55B23564@arbor.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dots] DOTS: next steps - call for editor volunteers for use case draft and requirements draft X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 16:19:01 -0000 On 9/8/15 11:37 AM, Roland Dobbins wrote: > On 8 Sep 2015, at 22:29, Flemming Andreasen wrote: > >> I disagree, and I know of at least one DDoS vendor that does as well. > > My operational experience with this is that, with some notable > exceptions, the endpoint network folks lack the skills and experience > to utilize the tools which can give them accurate information in terms > of detection/classification/traceback, even if they have those tools. > I'm not talking about endpoints. > The relatively few endpoint networks who're good at this tend to be > ASPs/content providers, themselves; tech companies, some financials, > and so forth. > > Regardless, our task here in DOTS is to standardize signaling; we > can't assume that the supplicant has any organic > detection/classification/traceback capabilities (though if they do, of > course, we want to be able to provide whats relevant to the mitigator). > Agreed - modularity and flexibility is key here; we don't want to mandate an overly comprehensive set of capabilities on everybody, but at the same time, there are real-life examples where those capabilities exists, and having a standardized signaling mechanism in place for those is where I see a lot of value in the DOTS work. -- Flemming > ----------------------------------- > Roland Dobbins > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > . > From nobody Tue Sep 8 13:27:12 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05BF71A1B21 for ; Tue, 8 Sep 2015 13:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 k7_MVQil4_Gp for ; Tue, 8 Sep 2015 13:27:08 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9CD31B2A36 for ; Tue, 8 Sep 2015 13:27:07 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CBA54972; Tue, 08 Sep 2015 20:27:05 +0000 (GMT) Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 8 Sep 2015 21:27:04 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml703-chm ([10.193.5.130]) with mapi id 14.03.0235.001; Tue, 8 Sep 2015 13:26:53 -0700 From: Linda Dunbar To: Christopher Morrow , Flemming Andreasen Thread-Topic: minimum information to exchange to upstream DDoS (was RE: [Dots] DOTS: next steps - call for editor volunteers for use case draft and requirements draft Thread-Index: AQHQ51lrjrgpJg76NE2owVNXXJohl54y90Yg Date: Tue, 8 Sep 2015 20:26:52 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657D22093@dfweml701-chm> References: <359EC4B99E040048A7131E0F4E113AFCD94F1C56@marathon> <55D01F5E.4070009@gondrom.org> <55DDA4A9.3050603@inria.fr> <8775DC11-7FE3-4A02-89EE-E6BDAC6A1C13@arbor.net> <55DF1EB7.9000703@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.142.174] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: Roland Dobbins , "dots@ietf.org" Subject: [Dots] minimum information to exchange to upstream DDoS (was RE: DOTS: next steps - call for editor volunteers for use case draft and requirements draft X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 20:27:11 -0000 Chris,=20 I like your example on the concrete information that the DOTS initiator can= send to upstream DDoS entity: =20 "I am seeing an attack to destination X port/protocol Y/Z" Are you saying that other telemetry, like the number of attacks, Src IP add= resses or ports of the detected attacks, etc, are not necessary? If the ini= tiator send those detailed information, does it hurt? What are the issues o= f sending those extra information beyond taking up some bandwidth?=20 Just curious.=20 Linda -----Original Message----- From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Christopher Morrow Sent: Friday, September 04, 2015 4:34 PM To: Flemming Andreasen Cc: Roland Dobbins; dots@ietf.org Subject: Re: [Dots] DOTS: next steps - call for editor volunteers for use c= ase draft and requirements draft On Thu, Aug 27, 2015 at 10:29 AM, Flemming Andreasen w= rote: > On 8/27/15 3:12 AM, Roland Dobbins wrote: >> >> On 27 Aug 2015, at 17:01, Xialiang (Frank) wrote: >> >>> which includes the DDoS related telemetry information as its part, >> >> >> The DDoS telemetry referred to in the WG charter is a starting point=20 >> for DOTS signaling - the telemetry itself is out-of-scope for this WG. > > Can you clarify the distinction you are making here ? The charter=20 > explicitly talks about DDoS related telemetry and based on previous=20 > discussions, It was my understanding that we wanted to provide=20 > information about an ongoing attack to an upstream entity to enable a=20 > more accurate and rapid response by that upstream entity. perhaps part of the problem here is related to 'provide information about a= n ongoing attack to an upstream entity....' what information? pps? destination ip/network? src-addresses? port/protocols used? I suspect that the upstream provider can very quickly determine the problem= in almost all cases, probably better than the initial reporter... and I'm = not sure it's particularly useful to send upstream much more than: "I am seeing an attack to destination X port/protocol Y/Z" you will want to ask the upstream: "do not disable access" probably... and as to the charter, the charter can always be changed... or = that work item can wait until the decision is that 'this work is not releva= nt anymore'... it'd be best, I think, to focus on the basic dots protocol w= ork and leave the telemetry for a later decision. > >> If the language needs to be massaged to reflect this, we can do it. >> > I don't think we can just change the charter, however we should make=20 > sure to capture the outcome of this thread as part of the overall require= ments. charters always change, it's not written in stone by aliens. _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Tue Sep 8 13:27:19 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA9921A1B21 for ; Tue, 8 Sep 2015 13:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 xH9TIdQBUFIK for ; Tue, 8 Sep 2015 13:27:11 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AF6A1A0399 for ; Tue, 8 Sep 2015 13:27:07 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BXJ53280; Tue, 08 Sep 2015 20:27:06 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 8 Sep 2015 21:27:06 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml704-chm ([10.193.5.141]) with mapi id 14.03.0235.001; Tue, 8 Sep 2015 13:26:53 -0700 From: Linda Dunbar To: Roland Dobbins , "dots@ietf.org" Thread-Topic: What are the necessary attributes to automatically summon DDoS mitigation on demand ?(was: what are the "good reasons" to oppose "telemetry used for detection/classification/traceback of DDoS attacks" Thread-Index: AQHQ6nSysYylxz9zpkmn1z13AOpVaA== Date: Tue, 8 Sep 2015 20:26:52 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657D2208B@dfweml701-chm> References: <359EC4B99E040048A7131E0F4E113AFCD94F1C56@marathon> <55D01F5E.4070009@gondrom.org> <55DDA4A9.3050603@inria.fr> <8775DC11-7FE3-4A02-89EE-E6BDAC6A1C13@arbor.net> <4A95BA014132FF49AE685FAB4B9F17F657D21479@dfweml701-chm> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.142.174] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Dots] What are the necessary attributes to automatically summon DDoS mitigation on demand ?(was: what are the "good reasons" to oppose "telemetry used for detection/classification/traceback of DDoS attacks" X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 20:27:12 -0000 Roland,=20 Thank you very much for the good explanation.=20 In your opinion, what are the necessary attributes or parameters to "automa= tically summon (with the side benefit of auto-provisioning) DDoS mitigation= on demand"? i.e. for an entity "A" to summon a DDoS mitigation somewhere else, what doe= s the entity "A" need to provide? I have my view, but curious to hear your= s.=20 Linda -----Original Message----- From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Roland Dobbins Sent: Saturday, September 05, 2015 4:48 AM To: dots@ietf.org Subject: Re: [Dots] wht are the "good reasons" to oppose "telemetry used fo= r detection/classification/traceback of DDoS attacks" On 5 Sep 2015, at 3:38, Linda Dunbar wrote: > Can you elaborate the "good reasons" for opposing "telemetry used for=20 > the detection/classification/traceback of DDoS attacks"? I'm not opposed to the use of telemetry for that purpose - I use it every d= ay, as do many, many others.. What I'm opposed to is this WG group getting involved in things beyond its = scope and trying to redefine the world. We need to focus on *one thing* - the ability to automatically summon (with= the side benefit of autoprovisioning) DDoS mitigation on demand. What's meant by the current language in the WG charter is that utilizing su= ch telemetry in a situationally-appropriate way to determine mitigation res= ponse is something we may wish to incorporate into the DOTS signal composit= ion process, at some point. I know this because *I'm the person who inserted that language into the cha= rter*. This WG has no authority to define or redefine telemetry formats. We have = enough to do right now in terms of defining DOTS; it makes zero sense to go= haring off in the direction of messing about with telemetry formats which = we have no authority to change, and which already work very well today. There is no burning need to alter IPFIX. Altering IPFIX from a telemetry s= tandpoint is not within the remit of this group. Continuing to stray into = off-charter areas is not productive and does not advance achieving the goal= of this WG, which is automated signaling for DDoS mitigation assistance. We need to focus on the matter at hand. ----------------------------------- Roland Dobbins _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Tue Sep 8 13:35:53 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65BB01B2B81 for ; Tue, 8 Sep 2015 13:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham 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 vT6yw_P7PArx for ; Tue, 8 Sep 2015 13:35:51 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 337E61B2B7D for ; Tue, 8 Sep 2015 13:35:51 -0700 (PDT) Received: by pacfv12 with SMTP id fv12so136600138pac.2 for ; Tue, 08 Sep 2015 13:35:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-type; bh=3NAi8fd3/fJid05s/Y+SgUsSJLvRUk6MBsvoh9Wupmo=; b=n5VmC3xEtD7G2H/91ed2bq5B9Jd8uxc/KcpZGRXoxJ8tzTAIwuO0CeVsIN3fzTRrgQ ENK6h27dx74H0QBFWhYctIvLNcEZPTzM+CmbAV3lnQ3pjBQ6MCDdS7muqQ3gAItqnxmX zoCJUJlbQWChMrFaqhhFpWh1N9GdzeH3DnjAo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-type; bh=3NAi8fd3/fJid05s/Y+SgUsSJLvRUk6MBsvoh9Wupmo=; b=Jpa8GQ/KqnBr6gA/Mv2/reWDyx9ApR6+Pzcsb42ex4UL0dY9XX2YvxDNaNBI3PBAVY YTKHiP1S9jkctlVttn/HbAbmb2k1BwqKum4p8wFVgCNJXsUBzyDuAzSo1WGWShMOe/vU AVY9OzpxhOT6fR4y7AyO4iLWhIYvtsN0+kkVuTEn5cVeVoQ1no7wcsp0fiZmyyfok6zZ nsKGSXQLigZHmVuC78+oK4xJkIDeHsLbzpaobxdOcefzRGhRgZ/orhJ1uT1hJXWWrbxg /P6HJL+KHG1tbdISDefxy7lOzKn4xzAPYOhnZYIByqtZ3gDV29cRg1Wni6hqxMk898KP vAIg== X-Gm-Message-State: ALoCoQnRix6cGVSqWtu0hOICOy1XbheuId+Droe0rxNoNcLl40HdvCvcQG5hzM1+4JxvKiCxgDOT X-Received: by 10.68.226.134 with SMTP id rs6mr62357366pbc.11.1441744550809; Tue, 08 Sep 2015 13:35:50 -0700 (PDT) Received: from [172.19.254.107] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id y15sm4410456pbt.90.2015.09.08.13.35.48 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 08 Sep 2015 13:35:49 -0700 (PDT) From: "Roland Dobbins" To: dots@ietf.org Date: Wed, 09 Sep 2015 03:35:46 +0700 Message-ID: In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657D22093@dfweml701-chm> References: <359EC4B99E040048A7131E0F4E113AFCD94F1C56@marathon> <55D01F5E.4070009@gondrom.org> <55DDA4A9.3050603@inria.fr> <8775DC11-7FE3-4A02-89EE-E6BDAC6A1C13@arbor.net> <55DF1EB7.9000703@cisco.com> <4A95BA014132FF49AE685FAB4B9F17F657D22093@dfweml701-chm> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Subject: Re: [Dots] minimum information to exchange to upstream DDoS (was RE: DOTS: next steps - call for editor volunteers for use case draft and requirements draft X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 20:35:52 -0000 On 9 Sep 2015, at 3:26, Linda Dunbar wrote: > Are you saying that other telemetry, like the number of attacks, Src > IP addresses or ports of the detected attacks, etc, are not necessary? Not even that amount of information is necessary. 'I am under attack, and I'm running these apps/services on these ports/protocols, and here're my credentials' is Good Enough. > If the initiator send those detailed information, does it hurt? What > are the issues of sending those extra information beyond taking up > some bandwidth? The issue is that the supplicant may not have the capability to do so, or even if it does, to do so accurately. The supplicant may well be an app on a mobile phone that has a Big Red Button. We must make no assumptions that the supplicant has any ability whatsoever to detect/classify/traceback traffic. It may only be able to know it's under load, or a human being may've noticed that it's staggering, and pushed the Big Red Button on that app. By self-identifying, the supplicant allows upstream mitigators to auto-provision countermeasures and other potential mitigation actions. Provisioning is a huge problem in dealing with DDoS attacks today; DOTS will have the welcome side-effect of promoting automagic or semi-automagic DDoS defense provisioning. ----------------------------------- Roland Dobbins From nobody Tue Sep 8 13:37:14 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81A541B2A91 for ; Tue, 8 Sep 2015 13:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham 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 p2hF9IOLMEWh for ; Tue, 8 Sep 2015 13:37:12 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94C6B1A90FB for ; Tue, 8 Sep 2015 13:37:12 -0700 (PDT) Received: by pacfv12 with SMTP id fv12so136627788pac.2 for ; Tue, 08 Sep 2015 13:37:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=from:to:subject:date:message-id:in-reply-to:references:mime-version; bh=4J0Tpj//y9/XR4UkEuQN4Qrni0Zdncxz67HhWmgOjgg=; b=YQj7VnbUYADs1Yl1tYJXZHDiDrY6W8Mo8XNr48QITYP95bRkZ44jpAFimjsyIDKpo1 7f9FjxyCn6s3k5Rw3YdVW9enBwYAkyzhByZ4FyLLpyoKAUbzJrHqw2mzUYKypvDEs3Xg KrayNCBJ4I0yKg0JRUSChmRJlei4jWPxX9kGA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version; bh=4J0Tpj//y9/XR4UkEuQN4Qrni0Zdncxz67HhWmgOjgg=; b=Gyj4oMj92B11BOG/jL0L8quCNKomMD91cJMtTnLwxnneLisJLkIBjFGpZaWn1ZJ6CC o7c3aKFW+miT0zswpg4Uku3aIo9OOZoHyr3HCTF4rBAnfT+PpPKsjl5JqN4BqepAZcj6 xncxm1pQ+K5WH/Nf3skm/D/E0+RwsKd7ktwTB6zZ2zLma5BVt+BhIdlVi+Q+G9pGzAS2 /qpLbjO43VSyY32vNDasKsIuKkfXQNqdUIwcpKGmcEbrrdlu6ZfXBKbfGOs73rfmuyCD geQDwfXij59UzVVvtXV5Yigx284p0CRmfvkvY3U/NVdBeGZO93XLRL5C1xvh1tUyxasj V6MQ== X-Gm-Message-State: ALoCoQm/rVRjLLquYTtV2VzuUAz1zOMP3GCJLU5mAQYXdJXwtT3XD/Lq39V9IVIVgu4D+IrduEv1 X-Received: by 10.68.247.226 with SMTP id yh2mr62942551pbc.12.1441744632294; Tue, 08 Sep 2015 13:37:12 -0700 (PDT) Received: from [172.19.254.107] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id qu8sm4444757pab.29.2015.09.08.13.37.10 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 08 Sep 2015 13:37:11 -0700 (PDT) From: "Roland Dobbins" To: dots@ietf.org Date: Wed, 09 Sep 2015 03:37:07 +0700 Message-ID: <70CB1B34-F6C2-42FB-AFC7-922D738A10BE@arbor.net> In-Reply-To: References: <359EC4B99E040048A7131E0F4E113AFCD94F1C56@marathon> <55D01F5E.4070009@gondrom.org> <55DDA4A9.3050603@inria.fr> <55DF03A4.8020105@cisco.com> <55E4D60A.50002@gondrom.org> MIME-Version: 1.0 X-Mailer: MailMate (1.9.2r5107) Archived-At: Subject: Re: [Dots] DOTS: next steps - call for editor volunteers for use case draft and requirements draft X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 20:37:13 -0000 On 8 Sep 2015, at 0:09, Teague, Nik wrote: > Do you have any ideas regarding design teams or we can self organise? I vote for self-organization. ----------------------------------- Roland Dobbins From nobody Tue Sep 8 13:38:51 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE1D41A0399 for ; Tue, 8 Sep 2015 13:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham 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 qHEswyXu0aMQ for ; Tue, 8 Sep 2015 13:38:48 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 536721A8A05 for ; Tue, 8 Sep 2015 13:38:48 -0700 (PDT) Received: by padhk3 with SMTP id hk3so48655260pad.3 for ; Tue, 08 Sep 2015 13:38:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-type; bh=0xoIcJLAjVkTECGx9h0358toTjpbfG/K+YKprlCqBHg=; b=nBoDEtF2VPg6MgXYLIzoMsA8Y46XmWKpw75jV3n28uC4cp8HCjbnrlcP5UgeyvCY1W lhjpEGc7gBqKz4Zhgeqcd4NJIRwoSvHQxMdNrkD0WHnI4T0dPC7XWNvIqnJQZXcK59sW 0pNSnG1Kf/pkCgRISBHPll8g6LHodH3vU79Tg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-type; bh=0xoIcJLAjVkTECGx9h0358toTjpbfG/K+YKprlCqBHg=; b=Uh46+bF0o7Aza3Wyny/QIXjacSbUIJx9Gjl75IIbYhU1+oupCAWiidqiMhsIjh4Srh X/btq4OnTf2FkF705ZxlVWtYk20xFRZycbgIsoUrwyUg0qSIxrRXP9nkIW5/AL2D3LPG MRy57A731wh41bOlmMJ9qFKBc2cXpNwqeY6Hs+Bmv9rkbHrQz4pT0LJnhH9HlXVH/wRe 6voXs1g2LnLtONHJaBa4BVxYvutZ4xeiz3ZDY8XGQsCXSpXF04fRSdqlw/7L1xIUXYNp gF48q+mJqdXVeutfR4/mdfWcD/aK8lo6/iZjeoeFLdi4z+TPPaOdcwDuZ18ELZ3sXdvM mWWg== X-Gm-Message-State: ALoCoQmAcpal20jHDDEgM7uOAIddm7SUCfvVCSFY+a89kPt+eypgfiAw79CVKXkxra2d+J1ekCp/ X-Received: by 10.68.142.130 with SMTP id rw2mr61987688pbb.107.1441744727951; Tue, 08 Sep 2015 13:38:47 -0700 (PDT) Received: from [172.19.254.107] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id iv2sm4418045pbd.88.2015.09.08.13.38.46 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 08 Sep 2015 13:38:47 -0700 (PDT) From: "Roland Dobbins" To: dots@ietf.org Date: Wed, 09 Sep 2015 03:38:43 +0700 Message-ID: In-Reply-To: <55EEFD32.3090601@cisco.com> References: <359EC4B99E040048A7131E0F4E113AFCD94F1C56@marathon> <55D01F5E.4070009@gondrom.org> <55DDA4A9.3050603@inria.fr> <8775DC11-7FE3-4A02-89EE-E6BDAC6A1C13@arbor.net> <4A95BA014132FF49AE685FAB4B9F17F657D21479@dfweml701-chm> <55EEFD32.3090601@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Subject: Re: [Dots] wht are the "good reasons" to oppose "telemetry used for detection/classification/traceback of DDoS attacks" X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 20:38:50 -0000 On 8 Sep 2015, at 22:22, Flemming Andreasen wrote: > Do you agree this is in scope ? Of course, but detection/classification information oughtn't to be mandatory. I've stated before that if such information is available from the supplicant, fine; if not, that's fine, too. Apologies for being unclear! ----------------------------------- Roland Dobbins From nobody Tue Sep 8 13:39:54 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3DD21B2C1B for ; Tue, 8 Sep 2015 13:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham 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 Cqn-7N_vcco1 for ; Tue, 8 Sep 2015 13:39:51 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F1E91B2C1D for ; Tue, 8 Sep 2015 13:39:46 -0700 (PDT) Received: by padhy16 with SMTP id hy16so131424573pad.1 for ; Tue, 08 Sep 2015 13:39:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-type; bh=GxlFfmLd3xe3gdpoJcARfrq72JIhrXI2NfkwFDITMho=; b=Yx56Wi06GR3NCOjGLk+ClwjYMLaOwmDW5wGRu1arg/iLO0eDWt2/uMBGY5URdfUDC/ UsvKDFv0wR6maBFMDtnpC/nVf2K/PyYD7dWjUErAd3Lxse8rQ+/nnYF5s1+PxEJPHOuK b1XEYVvHpd1nMLApXQGhqEii/fHc6yMHD1QJ0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-type; bh=GxlFfmLd3xe3gdpoJcARfrq72JIhrXI2NfkwFDITMho=; b=TocUG5rdvjWIzWOpHdZoHxpF8PKHREb98OkZirtaSY/XEFD9of16H5uYtjx99pN5uX NOxAQY4R7xzSE0gxCDUq4UkTahzB1DjpA0cRMJ2+8sfm63+WQygFtgmJhNGrtAHYuoZv YYRuZ/iGOkFvgRfVhlWfRYTzYzDnnNVgc4giMgJ6YK2wuQGBful/IKj4Xsh4OQVoxiXH HMnGWtbBHtXUHf/7SGGsicWG79GCt4FfKHoE1DZ9+THxOWh5R479D1GufXrkyc3YgfIc WD3qJJ3XSkvgHj7JU+Cm+wfb3kTvD2PJRddGmVsKoWnpOgXLcf51kBpOilGaR0lfYSzv farQ== X-Gm-Message-State: ALoCoQmur8LNqw9rWy7zhr2IDTdL4nv+yYaLgDzIDZr8+0zyZT17Kf7UGLV9qrmcRRcB+XJJYop7 X-Received: by 10.66.124.229 with SMTP id ml5mr52040521pab.77.1441744786205; Tue, 08 Sep 2015 13:39:46 -0700 (PDT) Received: from [172.19.254.107] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id gh5sm4420032pbc.87.2015.09.08.13.39.44 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 08 Sep 2015 13:39:45 -0700 (PDT) From: "Roland Dobbins" To: dots@ietf.org Date: Wed, 09 Sep 2015 03:39:42 +0700 Message-ID: <81B4B4EE-C56F-42BC-BBC6-35DE7D4C8124@arbor.net> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657D2208B@dfweml701-chm> References: <359EC4B99E040048A7131E0F4E113AFCD94F1C56@marathon> <55D01F5E.4070009@gondrom.org> <55DDA4A9.3050603@inria.fr> <8775DC11-7FE3-4A02-89EE-E6BDAC6A1C13@arbor.net> <4A95BA014132FF49AE685FAB4B9F17F657D21479@dfweml701-chm> <4A95BA014132FF49AE685FAB4B9F17F657D2208B@dfweml701-chm> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Subject: Re: [Dots] What are the necessary attributes to automatically summon DDoS mitigation on demand ?(was: what are the "good reasons" to oppose "telemetry used for detection/classification/traceback of DDoS attacks" X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 20:39:52 -0000 On 9 Sep 2015, at 3:26, Linda Dunbar wrote: > i.e. for an entity "A" to summon a DDoS mitigation somewhere else, > what does the entity "A" need to provide? I have my view, but curious > to hear yours. "I need DDoS mitigation assistance. Here's my IP address. Here're the service/apps I'm running on these ports/protocols. Here're my auth credentials." ----------------------------------- Roland Dobbins From nobody Tue Sep 8 14:15:42 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF5231B2FB9 for ; Tue, 8 Sep 2015 14:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham 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 7lZnMo8LL2M1 for ; Tue, 8 Sep 2015 14:15:37 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A9DE1B2F80 for ; Tue, 8 Sep 2015 14:15:37 -0700 (PDT) Received: by padhk3 with SMTP id hk3so49425058pad.3 for ; Tue, 08 Sep 2015 14:15:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-type; bh=Vph8M9n6qYKjXPvGPxdiAbrHTEnNxtaKKfxeKVv8lAw=; b=QRJK9eoeZ5Z+yW3HlNoa/dQcMpOwrG6SmtlCDRnhqvErXG/1to7I/floTNBzF8JsH7 Gn5ZF322eHM/FvpVCLCu9dTn3Fhw/cJlf5o49414Rmul417QGddcAdx26uT5bl4waRHd fJ1EeGW0FDglvtBqK3yf3FoSmjehrXWqc+ePI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-type; bh=Vph8M9n6qYKjXPvGPxdiAbrHTEnNxtaKKfxeKVv8lAw=; b=RpMmtI5JiaNFlkOo/5skP1odsjBxhzT/K8Xuc2mtVx2tbA1w27OLHuxHyRRBQdYV+9 F6bYS0kP0l0yCHYGmlEFZYsWcrCMjdeOJho3mwecPXrS4YO2PieOrwkGICiZ1ZrxWjVv eyeTd0UntFhiQ4zjsaDH+HW5XtrHrbQbu6pzLC4tIPDq2m8Ewx/yjeH7ZPMom0qMBNQo xK4cEDWZWje56WUDVIYRQaD9EWiH5ySbYo+aWaRPNOzqefHJW2A+YtE27PsSY55+yV8M mql7F1QAZtTiOYabVLPy6LPKH7+uTeIMvVqdSn9DSbIXrZiZwBYAU3wLMiw6NrrZZ9YR unUg== X-Gm-Message-State: ALoCoQl+6+yOcx1Xqdx8TuT0fWR/0QxPQGZiia7zMcgyCE/VLLEy0uyKN7I3Q806d+4CTuwgdVHB X-Received: by 10.68.114.196 with SMTP id ji4mr62522589pbb.46.1441746936640; Tue, 08 Sep 2015 14:15:36 -0700 (PDT) Received: from [172.19.254.107] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id mn2sm4483011pbc.75.2015.09.08.14.15.35 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 08 Sep 2015 14:15:36 -0700 (PDT) From: "Roland Dobbins" To: dots@ietf.org Date: Wed, 09 Sep 2015 04:15:32 +0700 Message-ID: <3DCF1498-D846-412C-A9AD-AE73E953E89C@arbor.net> In-Reply-To: <81B4B4EE-C56F-42BC-BBC6-35DE7D4C8124@arbor.net> References: <359EC4B99E040048A7131E0F4E113AFCD94F1C56@marathon> <55D01F5E.4070009@gondrom.org> <55DDA4A9.3050603@inria.fr> <8775DC11-7FE3-4A02-89EE-E6BDAC6A1C13@arbor.net> <4A95BA014132FF49AE685FAB4B9F17F657D21479@dfweml701-chm> <4A95BA014132FF49AE685FAB4B9F17F657D2208B@dfweml701-chm> <81B4B4EE-C56F-42BC-BBC6-35DE7D4C8124@arbor.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Subject: Re: [Dots] What are the necessary attributes to automatically summon DDoS mitigation on demand ?(was: what are the "good reasons" to oppose "telemetry used for detection/classification/traceback of DDoS attacks" X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 21:15:41 -0000 On 9 Sep 2015, at 3:39, Roland Dobbins wrote: > "I need DDoS mitigation assistance. Here's my IP address. Here're > the service/apps I'm running on these ports/protocols. Here're my > auth credentials." Actually, "I need DDoS mitigation assistance. Here's my IP address. Here're my auth credentials" should probably be the minimum-viability DOTS mitigation request, in cases where the end-customer organization are simply incapable of providing this information, for whatever reason. But the information about services/apps on ports/protocols is really important, and should be provided whenever possible. ----------------------------------- Roland Dobbins From nobody Tue Sep 8 14:22:31 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E28631B2E1C for ; Tue, 8 Sep 2015 14:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 vORjNjhgfM7n for ; Tue, 8 Sep 2015 14:22:28 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40B9E1A89F0 for ; Tue, 8 Sep 2015 14:22:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=701; q=dns/txt; s=iport; t=1441747348; x=1442956948; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=zG2bQz4d/6tkZSdgkqXv2lo90tYWzQSMn6ootZWPzLo=; b=R2YlVHMi220cD7GYvUS1ACIUTDdk7aYAqqNVTTby9pYb1p9UoN0hUmca pMtj4HwINz0LDV06+kbGSukAd7tvuxP5TuQbJT2ZeyCT0Yp180LLCBrTq nf9YPbwUYRFh7RXX8enpmwm0Q8nsZQnJwxVj6dlkI8op6z0UW1dnSXSMp Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BFAgD4UO9V/xbLJq1dg3dpvSkBCYFtCoV5AoFxFAEBAQEBAQGBCoQkAQEEAQEBNTYKEQsOCgkWBAsJAwIBAgEVMAYBDAYCAQGIKg3LZQEBAQEBAQEBAQEBAQEBAQEBARYEhnOEe4UThCwBBIcxjiSMeoh7kXwmgkKBWiIziEkBAQE X-IronPort-AV: E=Sophos;i="5.17,492,1437436800"; d="scan'208";a="611477277" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 08 Sep 2015 21:22:26 +0000 Received: from [10.98.149.195] (bxb-fandreas-8812.cisco.com [10.98.149.195]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t88LMP0S023295; Tue, 8 Sep 2015 21:22:25 GMT To: Roland Dobbins , dots@ietf.org References: <359EC4B99E040048A7131E0F4E113AFCD94F1C56@marathon> <55D01F5E.4070009@gondrom.org> <55DDA4A9.3050603@inria.fr> <8775DC11-7FE3-4A02-89EE-E6BDAC6A1C13@arbor.net> <4A95BA014132FF49AE685FAB4B9F17F657D21479@dfweml701-chm> <55EEFD32.3090601@cisco.com> From: Flemming Andreasen Message-ID: <55EF51B7.4030700@cisco.com> Date: Tue, 8 Sep 2015 17:23:03 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dots] wht are the "good reasons" to oppose "telemetry used for detection/classification/traceback of DDoS attacks" X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 21:22:30 -0000 On 9/8/15 4:38 PM, Roland Dobbins wrote: > On 8 Sep 2015, at 22:22, Flemming Andreasen wrote: > >> Do you agree this is in scope ? > > Of course, but detection/classification information oughtn't to be > mandatory. I've stated before that if such information is available > from the supplicant, fine; if not, that's fine, too. > > Apologies for being unclear! > No worries - sounds like we are on the same page here after all. Cheers -- Flemming > ----------------------------------- > Roland Dobbins > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > . > From nobody Tue Sep 8 14:28:27 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C20C1A1B88 for ; Tue, 8 Sep 2015 14:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Nwn4liMg2SID for ; Tue, 8 Sep 2015 14:28:23 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CC331AC3AE for ; Tue, 8 Sep 2015 14:28:22 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CBA58107; Tue, 08 Sep 2015 21:28:19 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 8 Sep 2015 22:28:19 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml702-chm ([10.193.5.72]) with mapi id 14.03.0235.001; Tue, 8 Sep 2015 14:28:16 -0700 From: Linda Dunbar To: Roland Dobbins , "dots@ietf.org" Thread-Topic: [Dots] What are the necessary attributes to automatically summon DDoS mitigation on demand ?(was: what are the "good reasons" to oppose "telemetry used for detection/classification/traceback of DDoS attacks" Thread-Index: AQHQ6nSysYylxz9zpkmn1z13AOpVaJ4zjWkAgAAKAwD//4xdIA== Date: Tue, 8 Sep 2015 21:28:15 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657D22266@dfweml701-chm> References: <359EC4B99E040048A7131E0F4E113AFCD94F1C56@marathon> <55D01F5E.4070009@gondrom.org> <55DDA4A9.3050603@inria.fr> <8775DC11-7FE3-4A02-89EE-E6BDAC6A1C13@arbor.net> <4A95BA014132FF49AE685FAB4B9F17F657D21479@dfweml701-chm> <4A95BA014132FF49AE685FAB4B9F17F657D2208B@dfweml701-chm> <81B4B4EE-C56F-42BC-BBC6-35DE7D4C8124@arbor.net> <3DCF1498-D846-412C-A9AD-AE73E953E89C@arbor.net> In-Reply-To: <3DCF1498-D846-412C-A9AD-AE73E953E89C@arbor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.142.174] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657D22266dfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Dots] What are the necessary attributes to automatically summon DDoS mitigation on demand ?(was: what are the "good reasons" to oppose "telemetry used for detection/classification/traceback of DDoS attacks" X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 21:28:25 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657D22266dfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Roland, You said " But the information about services/apps on ports/protocols is reall= y important, and should be provided whenever possible." Should the End Points register their "Services/Apps on ports/protocols" bef= ore any attack starts? Say with an entity (e.g. the upstream management sys= tem)? I would imagine that end points can provide more accurate information= before the end point is attacked, correct? Linda -----Original Message----- From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Roland Dobbins Sent: Tuesday, September 08, 2015 4:16 PM To: dots@ietf.org Subject: Re: [Dots] What are the necessary attributes to automatically summ= on DDoS mitigation on demand ?(was: what are the "good reasons" to oppose "= telemetry used for detection/classification/traceback of DDoS attacks" On 9 Sep 2015, at 3:39, Roland Dobbins wrote: > "I need DDoS mitigation assistance. Here's my IP address. Here're > the service/apps I'm running on these ports/protocols. Here're my > auth credentials." Actually, "I need DDoS mitigation assistance. Here's my IP address. Here're my auth credentials" should probably be the minimum-viability DOTS = mitigation request, in cases where the end-customer organization are simply= incapable of providing this information, for whatever reason. But the information about services/apps on ports/protocols is really import= ant, and should be provided whenever possible. ----------------------------------- Roland Dobbins > _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots --_000_4A95BA014132FF49AE685FAB4B9F17F657D22266dfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Roland,
 
You said
" But the information abou= t services/apps on ports/protocols is really important, and should be provi= ded whenever possible."
 
Should the End Points register their "Services/Apps on ports/prot= ocols" before any attack starts? Say with an entity (e.g. the upstream= management system)? I would imagine that end points can provide more accur= ate information before the end point is attacked, correct?
 
Linda
 
-----Original Message-----
From: Dots [mailto:dots-bounces@ie= tf.org] On Behalf Of Roland Dobbins
Sent: Tuesday, September 08, 2015 4:16 PM
To: dots@ietf.org
Subject: Re: [Dots] What are the necessary attributes to automatically summ= on DDoS mitigation on demand ?(was: what are the "good reasons" t= o oppose "telemetry used for detection/classification/traceback of DDo= S attacks"
 
 
On 9 Sep 2015, at 3:39, Roland Dobbins wrote:
 
> "I need DDoS mitigation assistance.  Here's my IP addre= ss.  Here're
> the service/apps I'm running on these ports/protocols.  Here= 're my
> auth credentials."
 
Actually, "I need DDoS mitigation assistance.  Here's my IP = address. 
Here're my auth credentials" should probably be the minimum-viabi= lity DOTS mitigation request, in cases where the end-customer organization = are simply incapable of providing this information, for whatever reason.
 
But the information about services/apps on ports/protocols is really i= mportant, and should be provided whenever possible.
 
-----------------------------------
Roland Dobbins <rdobbins@arbo= r.net>
 
_______________________________________________
Dots mailing list
 
 --_000_4A95BA014132FF49AE685FAB4B9F17F657D22266dfweml701chm_-- From nobody Tue Sep 8 14:45:53 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1548F1B3153 for ; Tue, 8 Sep 2015 14:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.765 X-Spam-Level: X-Spam-Status: No, score=-94.765 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HELO_EQ_D_D_D_D=1.597, HELO_DYNAMIC_IPADDR=1.951, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=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 g-gN5vohpSN6 for ; Tue, 8 Sep 2015 14:45:48 -0700 (PDT) Received: from lvps5-35-241-16.dedicated.hosteurope.de (www.gondrom.org [5.35.241.16]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68E4B1ACD2D for ; Tue, 8 Sep 2015 14:45:47 -0700 (PDT) Received: from [192.168.178.32] (x590f9c53.dyn.telefonica.de [89.15.156.83]) by lvps5-35-241-16.dedicated.hosteurope.de (Postfix) with ESMTPSA id 9596E634B1; Tue, 8 Sep 2015 23:45:44 +0200 (CEST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=y0AJglZoN78dtkDZcbxj79pSIAOpucp43Fvq2MxKDdl7LOEm3TW6gg8/fNoP0c2lAadMeyfRY7pwy3eb4AgT+jKynvB1z6H4vt8p0mBHsHjsbYkcX/NjtJYv302feBTb+H+Qw4fcX91kmtc+eWez6mgSzgIBZ64FkY4avVkRIFk=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:X-Priority:Content-Type; Message-ID: <55EF5708.1080003@gondrom.org> Date: Tue, 08 Sep 2015 23:45:44 +0200 From: Tobias Gondrom 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 X-Priority: 2 (High) Content-Type: multipart/alternative; boundary="------------050505030100080801070705" Archived-At: Cc: rdd@cert.org Subject: [Dots] WG draft editors & next steps X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 21:45:52 -0000 This is a multi-part message in MIME format. --------------050505030100080801070705 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear DOTS team, thank you for the discussions and ideas being posted here on the mailing-list and at our last WG meeting in Prague. Your help and work is greatly appreciated! Roman and I had a conversation last week with Roman and we like to propose the following teams as co-editors for our WG use case and requirements draft. *For the use case draft **(in alphabetical order)**: *Daniel (daniel.migault@ericsson.com), Frank (frank.xialiang@huawei.com), Nik (nteague@verisign.com), Roland (rdobbins@arbor.net) and Stefan (Stefan.Fouant@corero.com), *For the requirements draft **(in alphabetical order): ** *Andrew (amortensen@arbor.net), Bob (rgm@htt-consult.com) and Tiru (tireddy@cisco.com) In fact there were many more great volunteers, but we had to limit the editor teams to ensure they will work effective. We believe, diverse groups can bring a good multitude of view points and make sure that we capture the full range of use cases and requirements from the contributions in the WG. And thereby avoid ignoring or forgetting use cases that may not be relevant for their own individual organisation. *I like to explicitly remind everyone that one of the main tasks of draft editors is **in the first priority **to fulfil WG consensus.* That means we serve the WG, of which we naturally can also be a contributing part. But editors are not dictating the results nor are they in any way superior in interpretation of text or decisions only because they edited the draft for our WG. Everyone within the WG is equally welcome and encouraged to contribute to the drafts with ideas and feedback. For people from outside of IETF, this editor role definition may be a bit unusual, but please keep this in mind when you work on the draft. *And please also do take note of the IETF Note Well as it applies to all IETF contributions: **https://www.ietf.org/about/note-well.html** *** All of the technical discussions should be on the mailing-list to allow for open discussions and that all WG members can participate equally. And so that we can measure WG consensus in cases of disagreements and make sure that all concerns have been addressed. Of course everyone is free to talk on- or off-list, but for WG discussions the mailing-list is the right place to go. If the editors like, they can use the IETF issue tracker to help manage and resolve lists of issues. In fact, I recommend it, as other WGs have made good experience with it. *We also intend to progress ASAP to the resulting protocol specifications. (open for volunteer**s**).* In our current plan we started now work on the requirements and use cases drafts. And soon after, anytime from now, we can start working on protocol drafts. We do not have to wait until we publish the first drafts as RFCs before we could start with the protocols, but rather intend to progress on several fronts in parallel. So if you have certain protocols or protocol extensions in mind in order to fulfil the requirements and use cases currently being worked on, please feel free to submit anytime. There is no need to wait for the finishing of the first documents to go to RFC. *So what are the next steps: 0. We strongly encourage all WG participants to submit your ideas and contributions. * 1. We plan to have an interim meeting end of September to allow for presentation and discussion of progress on these two drafts and other draft ideas coming up. For this we shall send around a date proposal in the next few days. 2. We will have a WG meeting at IETF 94 in Yokohama, begin of November. 3. We are considering to set up something like open design teams (one for use cases and one for requirements) where people could join freely based on their interest. The design teams would be open and informal, per draft and would not have separate mailing-lists. All technical email discussions shall remain on the WG mailing-list, but you may have design team meetings using skype or other remote conference tools to advance complicated discussions. We hope some co-editors could help organising such calls for the design team if the WG wishes so. And last but not least, let me say thank you again to all contributors and volunteers so far and I am very much looking forward to our exciting work together in DOTS and our future protocol specification results. Best regards, Tobias and Roman (DOTS WG chairs) --------------050505030100080801070705 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Dear DOTS team,

thank you for the discussions and ideas being posted here on the mailing-list and at our last WG meeting in Prague.

Your help and work is greatly appreciated!

Roman and I had a conversation last week with Roman and we like to propose the following teams as co-editors for our WG use case and requirements draft.

For the use case draft (in alphabetical order):
Daniel (daniel.migault@ericsson.com), Frank (frank.xialiang@huawei.com), Nik (nteague@verisign.com), Roland (rdobbins@arbor.net) and Stefan (Stefan.Fouant@corero.com),

For the requirements draft (in alphabetical order):
Andrew (amortensen@arbor.net), Bob (rgm@htt-consult.com) and Tiru (tireddy@cisco.com)

In fact there were many more great volunteers, but we had to limit the editor teams to ensure they will work effective. We believe, diverse groups can bring a good multitude of view points and make sure that we capture the full range of use cases and requirements from the contributions in the WG. And thereby avoid ignoring or forgetting use cases that may not be relevant for their own individual organisation.

I like to explicitly remind everyone that one of the main tasks of draft editors is in the first priority to fulfil WG consensus. That means we serve the WG, of which we naturally can also be a contributing part. But editors are not dictating the results nor are they in any way superior in interpretation of text or decisions only because they edited the draft for our WG. Everyone within the WG is equally welcome and encouraged to contribute to the drafts with ideas and feedback. For people from outside of IETF, this editor role definition may be a bit unusual, but please keep this in mind when you work on the draft.

And please also do take note of the IETF Note Well as it applies to all IETF contributions: https://www.ietf.org/about/note-well.html
All of the technical discussions should be on the mailing-list to allow for open discussions and that all WG members can participate equally. And so that we can measure WG consensus in cases of disagreements and make sure that all concerns have been addressed.
Of course everyone is free to talk on- or off-list, but for WG discussions the mailing-list is the right place to go.
If the editors like, they can use the IETF issue tracker to help manage and resolve lists of issues. In fact, I recommend it, as other WGs have made good experience with it.

We also intend to progress ASAP to the resulting protocol specifications. (open for volunteers). In our current plan we started now work on the requirements and use cases drafts. And soon after, anytime from now, we can start working on protocol drafts. We do not have to wait until we publish the first drafts as RFCs before we could start with the protocols, but rather intend to progress on several fronts in parallel.
So if you have certain protocols or protocol extensions in mind in order to fulfil the requirements and use cases currently being worked on, please feel free to submit anytime. There is no need to wait for the finishing of the first documents to go to RFC.

So what are the next steps:
0. We strongly encourage all WG participants to submit your ideas and contributions.
1. We plan to have an interim meeting end of September to allow for presentation and discussion of progress on these two drafts and other draft ideas coming up. For this we shall send around a date proposal in the next few days.
2. We will have a WG meeting at IETF 94 in Yokohama, begin of November.
3. We are considering to set up something like open design teams (one for use cases and one for requirements) where people could join freely based on their interest. The design teams would be open and informal, per draft and would not have separate mailing-lists. All technical email discussions shall remain on the WG mailing-list, but you may have design team meetings using skype or other remote conference tools to advance complicated discussions. We hope some co-editors could help organising such calls for the design team if the WG wishes so.

And last but not least, let me say thank you again to all contributors and volunteers so far and I am very much looking forward to our exciting work together in DOTS and our future protocol specification results.

Best regards,

Tobias and Roman
(DOTS WG chairs)


 --------------050505030100080801070705-- From nobody Tue Sep 8 15:33:10 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 442831B303E for ; Tue, 8 Sep 2015 15:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham 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 lIRR1eV_ZRVF for ; Tue, 8 Sep 2015 15:33:06 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D76411A008F for ; Tue, 8 Sep 2015 15:33:06 -0700 (PDT) Received: by padhy16 with SMTP id hy16so133786314pad.1 for ; Tue, 08 Sep 2015 15:33:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-type; bh=Vt4pmot8Iuj4trJ6nsQGGm38BuBh+hW9uioAP5VZ/hE=; b=JS6rM+w1Q8kfUjxfgGKJi4Dg00D4kEBlQ6BbQrOkywHsicrGMY5TeygJ1kG13RBQ8Q B63xjkRmTtoeoDMqIuPDn+dLout0H0Q5rIwyceLn6657ZA/kCZ6S/mwZzNMmoAxyuNc/ OrY7Izo26JWB4mxpTqVXsPA8PPZh2upJj9nik= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-type; bh=Vt4pmot8Iuj4trJ6nsQGGm38BuBh+hW9uioAP5VZ/hE=; b=ji5GjMHARjEn/FTGq2DF7iJjhm6TAKspAXtceqT1KpDISOB2lkTY9tqLswmjiWlGb7 AzyFawmLn+gpzWv78UgYuB1MDR7+H+twHp9QtgYHroRG33fCbjs1tlgMbmzsA/W3ri6h Wgn0cRcOiuaubWo06NJ3PwK6YyxxcUtM6l9y5jMM4+BDRBYaWM6Te5MrzKv8N81fTg6H zmDTGCplPI4pEc9pd0KNZYZ4nRmZ2aS1U5Ck4vijqEFsSgMmLdbCHW/KWbHuEemLPHxT JlvAVtxMG/SfBwllcrtNc5EaQH3BcKG2OhqIdbaN9ew/4mjWQ9L3/6UwKdzA4LueuH1h p9EQ== X-Gm-Message-State: ALoCoQkfS0OLqjR7ubVBkSKh8Az0Rp4R6Ro/PYxdFnc0Rp8hPq1C+gdGUWbH5vs/7cmc7OBYZB2c X-Received: by 10.68.249.66 with SMTP id ys2mr63832596pbc.82.1441751586440; Tue, 08 Sep 2015 15:33:06 -0700 (PDT) Received: from [172.19.254.107] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id hm7sm4623834pdb.24.2015.09.08.15.33.05 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 08 Sep 2015 15:33:05 -0700 (PDT) From: "Roland Dobbins" To: dots@ietf.org Date: Wed, 09 Sep 2015 05:33:02 +0700 Message-ID: <7113C62D-44B6-4336-A0AE-122113571B88@arbor.net> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657D22266@dfweml701-chm> References: <359EC4B99E040048A7131E0F4E113AFCD94F1C56@marathon> <55D01F5E.4070009@gondrom.org> <55DDA4A9.3050603@inria.fr> <8775DC11-7FE3-4A02-89EE-E6BDAC6A1C13@arbor.net> <4A95BA014132FF49AE685FAB4B9F17F657D21479@dfweml701-chm> <4A95BA014132FF49AE685FAB4B9F17F657D2208B@dfweml701-chm> <81B4B4EE-C56F-42BC-BBC6-35DE7D4C8124@arbor.net> <3DCF1498-D846-412C-A9AD-AE73E953E89C@arbor.net> <4A95BA014132FF49AE685FAB4B9F17F657D22266@dfweml701-chm> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Subject: Re: [Dots] What are the necessary attributes to automatically summon DDoS mitigation on demand ?(was: what are the "good reasons" to oppose "telemetry used for detection/classification/traceback of DDoS attacks" X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 22:33:09 -0000 On 9 Sep 2015, at 4:28, Linda Dunbar wrote: > Should the End Points register their "Services/Apps on > ports/protocols" before any attack starts? Ideally, yes, that's how it should work. But just-in-time (JIT) would be possible, as well - and that's key for organizations which didn't have a mitigation service in place ahead-of-time, which come under attack, and are screaming for DDoS mitigation assistance. If their apps/services/infrastructure is DOTS-capable, mitigation can be provisioned JIT, without all the fumbling and bumbling of trying to a) manually gather/vet the requisite information and b) communicate it manually, either verbally or in writing (see p. 20 of , and pp. 15-20 of ). Note that this isn't a function of the DOTS signaling protocol itself, but rather a function of the mitigation organization's infrastructure, operational practices, etc. > Say with an entity (e.g. the upstream management system)? I would > imagine that end points can provide more accurate information before > the end point is attacked, correct? We assume that the provisioning information is accurate, as that's generally much more static and well-understood (even though in many cases, it's poorly understood, or not at all understood) than traffic statistics, attack classification, etc. The accuracy should be unchanged with regards to pre-attack vs. active-attack scenarios. And as moves/adds/changes happen over time, there's obviously a high desirability for re-registration as events warrant. Provisioning validation, mitigation validation/rehearsal, et. al. all become easier, as well. ----------------------------------- Roland Dobbins From nobody Tue Sep 8 15:41:10 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E87C1B3321 for ; Tue, 8 Sep 2015 15:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 f9hrlAw1xFwZ for ; Tue, 8 Sep 2015 15:41:05 -0700 (PDT) Received: from mail-yk0-f182.google.com (mail-yk0-f182.google.com [209.85.160.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B60781B3270 for ; Tue, 8 Sep 2015 15:41:04 -0700 (PDT) Received: by ykdg206 with SMTP id g206so142367743ykd.1 for ; Tue, 08 Sep 2015 15:41:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qVU3UXQ8nHSCQbJutXNrJ7e0zQtDnmI0G4Tsif4qK1I=; b=B+EYGzckECzl7kb7fvFDZSElcqnoxrp7cJhwxNl7ZePe7wN0pR8Lx0vRrkQHBdT9jK TrhvK4yU3G7ku586v81Ckp1i0C2oMHQp5UkHZh+K/JDPE3QDH3Oy3u7Kd6/QCPNGlzf/ lNRBIhgFR77fGoZaAZfW9QCpE2VJp4tMsRGh77JryqBzejY93gARnWnaNT6em3zc/FQd cVtoLB+SxLjKJ3klOrKgTVMCeBZey2Sb/x5zDk7opN4LKbAOyVsLQsqg06g/bW3pZZ8c dxOGocZHPjIcQovu7l++w6y5/Rk7h0jFQCFDqlydArwIZzruEO/lJyrCGasTaSIkS+wM S0uw== X-Gm-Message-State: ALoCoQnfhsoMFl/BavgOHZH7Upvdy/4aMO0xWI6K3xLAeNWGD4QcGwjRGmzNltY8FaRMcttuhw0L MIME-Version: 1.0 X-Received: by 10.170.53.209 with SMTP id 200mr32435346ykv.39.1441752063566; Tue, 08 Sep 2015 15:41:03 -0700 (PDT) Received: by 10.31.93.71 with HTTP; Tue, 8 Sep 2015 15:41:03 -0700 (PDT) In-Reply-To: <7113C62D-44B6-4336-A0AE-122113571B88@arbor.net> References: <359EC4B99E040048A7131E0F4E113AFCD94F1C56@marathon> <55D01F5E.4070009@gondrom.org> <55DDA4A9.3050603@inria.fr> <8775DC11-7FE3-4A02-89EE-E6BDAC6A1C13@arbor.net> <4A95BA014132FF49AE685FAB4B9F17F657D21479@dfweml701-chm> <4A95BA014132FF49AE685FAB4B9F17F657D2208B@dfweml701-chm> <81B4B4EE-C56F-42BC-BBC6-35DE7D4C8124@arbor.net> <3DCF1498-D846-412C-A9AD-AE73E953E89C@arbor.net> <4A95BA014132FF49AE685FAB4B9F17F657D22266@dfweml701-chm> <7113C62D-44B6-4336-A0AE-122113571B88@arbor.net> Date: Tue, 8 Sep 2015 15:41:03 -0700 Message-ID: From: Jelena Mirkovic To: Roland Dobbins Content-Type: multipart/alternative; boundary=001a11391d329a9500051f440ff9 Archived-At: Cc: dots@ietf.org Subject: Re: [Dots] What are the necessary attributes to automatically summon DDoS mitigation on demand ?(was: what are the "good reasons" to oppose "telemetry used for detection/classification/traceback of DDoS attacks" X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 22:41:09 -0000 --001a11391d329a9500051f440ff9 Content-Type: text/plain; charset=UTF-8 Now I'm confused. JIT assumes that someone will mitigate attacks for free, if there was no preregistration, no contract. Is there a movement in industry in this direction? ========================= Jelena Mirkovic Research Faculty USC Information Sciences Institute 4676 Admiralty Way, Suite 1001 Marina del Rey, CA 90292 310-448-9170 On Tue, Sep 8, 2015 at 3:33 PM, Roland Dobbins wrote: > On 9 Sep 2015, at 4:28, Linda Dunbar wrote: > > Should the End Points register their "Services/Apps on ports/protocols" >> before any attack starts? >> > > Ideally, yes, that's how it should work. But just-in-time (JIT) would be > possible, as well - and that's key for organizations which didn't have a > mitigation service in place ahead-of-time, which come under attack, and are > screaming for DDoS mitigation assistance. If their > apps/services/infrastructure is DOTS-capable, mitigation can be provisioned > JIT, without all the fumbling and bumbling of trying to a) manually > gather/vet the requisite information and b) communicate it manually, either > verbally or in writing (see p. 20 of < > https://app.box.com/s/wwvlklsqsaeus3upx2sssxu4p8wytpqq>, and pp. 15-20 of > ). > > Note that this isn't a function of the DOTS signaling protocol itself, but > rather a function of the mitigation organization's infrastructure, > operational practices, etc. > > Say with an entity (e.g. the upstream management system)? I would imagine >> that end points can provide more accurate information before the end point >> is attacked, correct? >> > > We assume that the provisioning information is accurate, as that's > generally much more static and well-understood (even though in many cases, > it's poorly understood, or not at all understood) than traffic statistics, > attack classification, etc. The accuracy should be unchanged with regards > to pre-attack vs. active-attack scenarios. > > And as moves/adds/changes happen over time, there's obviously a high > desirability for re-registration as events warrant. Provisioning > validation, mitigation validation/rehearsal, et. al. all become easier, as > well. > > > ----------------------------------- > Roland Dobbins > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > --001a11391d329a9500051f440ff9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Now I'm confused. JIT assumes that someone will mitiga= te attacks for free, if there was no preregistration, no contract. Is there= a movement in industry in this direction?
=

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

Jelena Mirkovic
Research= Faculty
USC Informa= tion Sciences Institute
4676 Admiralty Way, Suite 1001
Marina del Rey, CA 90292
310-448-9170


On Tue, Sep 8, 2015 at 3:33 PM, Roland Dobbi= ns <rdobbins@arbor.net> wrote:
On 9 Sep 2015, at 4:28, Linda Dunbar wrote:

Should the End Points register their "Services/Apps on ports/protocols= " before any attack starts?

 Ideally, yes, that's how it should work.=C2=A0 But just-in-time (JIT) w= ould be possible, as well - and that's key for organizations which didn= 't have a mitigation service in place ahead-of-time, which come under a= ttack, and are screaming for DDoS mitigation assistance.=C2=A0 If their app= s/services/infrastructure is DOTS-capable, mitigation can be provisioned JI= T, without all the fumbling and bumbling of trying to a) manually gather/ve= t the requisite information and b) communicate it manually, either verbally= or in writing (see p. 20 of <https://app.b= ox.com/s/wwvlklsqsaeus3upx2sssxu4p8wytpqq>, and pp. 15-20 of <https://app.box.com/s/wwvlklsqsaeus3upx2sssxu4p8w= ytpqq>).

Note that this isn't a function of the DOTS signaling protocol itself, = but rather a function of the mitigation organization's infrastructure, = operational practices, etc.

Say with an entity (e.g. the upstream management system)? I would imagine t= hat end points can provide more accurate information before the end point i= s attacked, correct?

 We assume that the provisioning information is accurate, as that's gene= rally much more static and well-understood (even though in many cases, it&#= 39;s poorly understood, or not at all understood) than traffic statistics, = attack classification, etc.=C2=A0 The accuracy should be unchanged with reg= ards to pre-attack vs. active-attack scenarios.

And as moves/adds/changes happen over time, there's obviously a high de= sirability for re-registration as events warrant.=C2=A0 Provisioning valida= tion, mitigation validation/rehearsal, et. al. all become easier, as well.<= div class=3D"HOEnZb">


-----------------------------------
Roland Dobbins <= rdobbins@arbor.net>

_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots

--001a11391d329a9500051f440ff9-- From nobody Tue Sep 8 15:51:55 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7FE1AD151 for ; Tue, 8 Sep 2015 15:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham 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 UW0l7VcX09Rh for ; Tue, 8 Sep 2015 15:51:52 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEB9A1A0062 for ; Tue, 8 Sep 2015 15:51:52 -0700 (PDT) Received: by padhk3 with SMTP id hk3so51426834pad.3 for ; Tue, 08 Sep 2015 15:51:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-type; bh=243ZADYjrsjQDIyNUpVQ6dO3yCtmMpW7dSGO+LZy/iw=; b=cZXmedjlxTAZkHnvkVE9vO3EiNduArKTnoa0jW7q6bRCZRMuMBrLHDGmHwnyRgj3oT KoShYM8+ruoiKBVfXAJWkt+Iwms25VaGyDV2GAedHiYex6sSj2fHpEGcH3x4bBm2cigO UzgxQrEyQmrBtyj+8UXCx6S/EbKuOYy1YEvtY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-type; bh=243ZADYjrsjQDIyNUpVQ6dO3yCtmMpW7dSGO+LZy/iw=; b=QjARkbPDkVavRPm/q/UDVWpIxh5WzFv0iI+Yy7c79h8YXPZ011EDJIrbK4XBxyIP4T Q2hG2ZZuoj2oSm/BDJs46rlQGk1VM/bphZWbAULQqLvKahzaNTQYsL9ob8aUVZ47QIQd XeKclqPpahsULThu+IewIXiZVM1vYI7E/v/Hk7m7of5G8vCGGksxy5O7G1n8TBYYeRiR 9Iv/zuEvh0dwL+fsomYLIUNNgDTYRAzAJMUnDkW//EzacXiDz5K5J/ZspQEKYed2g9Xk dseRF+zrfmH1hs0rHltFNzlzF76r+ib9qF0aZfvlC8S/DH5ERd6vK/1I37oNYb5jjjUP FlFQ== X-Gm-Message-State: ALoCoQmp7M+iV8gRfeMYJV0nigLuz4fDzr15db3WTScq1qk9ckiMHE5V3/f7ZvdImhZfrw9o+TNV X-Received: by 10.68.88.69 with SMTP id be5mr63376027pbb.105.1441752712351; Tue, 08 Sep 2015 15:51:52 -0700 (PDT) Received: from [172.19.254.107] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id dl1sm4199080pdb.22.2015.09.08.15.51.51 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 08 Sep 2015 15:51:51 -0700 (PDT) From: "Roland Dobbins" To: dots@ietf.org Date: Wed, 09 Sep 2015 05:51:48 +0700 Message-ID: <30D26F83-2C2B-4E38-BAF9-E8F73A846E79@arbor.net> In-Reply-To: References: <359EC4B99E040048A7131E0F4E113AFCD94F1C56@marathon> <55D01F5E.4070009@gondrom.org> <55DDA4A9.3050603@inria.fr> <8775DC11-7FE3-4A02-89EE-E6BDAC6A1C13@arbor.net> <4A95BA014132FF49AE685FAB4B9F17F657D21479@dfweml701-chm> <4A95BA014132FF49AE685FAB4B9F17F657D2208B@dfweml701-chm> <81B4B4EE-C56F-42BC-BBC6-35DE7D4C8124@arbor.net> <3DCF1498-D846-412C-A9AD-AE73E953E89C@arbor.net> <4A95BA014132FF49AE685FAB4B9F17F657D22266@dfweml701-chm> <7113C62D-44B6-4336-A0AE-122113571B88@arbor.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Subject: Re: [Dots] What are the necessary attributes to automatically summon DDoS mitigation on demand ?(was: what are the "good reasons" to oppose "telemetry used for detection/classification/traceback of DDoS attacks" X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 22:51:54 -0000 On 9 Sep 2015, at 5:41, Jelena Mirkovic wrote: > JIT assumes that someone will mitigate attacks for free, if there was > no preregistration, no contract. No - JIT assumes the end-customer calls up the ISP/MSSP screaming, "Help, the Internet is down!", and the ISP/MSSP says, "Credit card, please," and the end-customer provides it, and then rapid provisioning followed by mitigation takes place. Note that this may also take place online, with zero human-to-human contact. But the above is the logical representation of the process. ;> A *lot* of DDoS attacks are mitigated (and all too often, not) due to this kind of approach. DOTS will make it much less error-prone and achievable within an operationally useful timeframe (e.g., while the attack is still taking place). I've personally taken a combo transit/hosting/colo/wireline broadband access/wireless mobile broadband ISP from zero DDoS detection/classification/traceback/mitigation capability to full capability and active attack mitigation in 90 minutes, *during an attack*, and that included racking and stacking boxes and getting everything turned up. This particular attack was against the largest and most prominent bank in the country in question; the ISP successfully mitigated the attack, everything came back up, and they negotiated the contractual and billing stuff post-attack. Chris Morrow can provide similar examples, as I'm sure can Stefan Fouant and Scott Barvick. DOTS will make this sort of thing far more doable - and, it's hoped, far less common, eventually. ----------------------------------- Roland Dobbins From nobody Tue Sep 8 19:54:05 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC321A87D0 for ; Tue, 8 Sep 2015 19:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 4Y6f7bMAdpGL for ; Tue, 8 Sep 2015 19:54:01 -0700 (PDT) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D3C81A1A43 for ; Tue, 8 Sep 2015 19:54:01 -0700 (PDT) Received: by ykdu9 with SMTP id u9so74557101ykd.2 for ; Tue, 08 Sep 2015 19:54:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=n4yQIBz6XuuV2c75hRyw5svvHT3uBU3wVrk2ROPd1sY=; b=X6zX08SInuNEZ3Dsy6+zkzrMY3VuT+IuFeVlccM0TJAcaKhsZ52CkmRQI/zYMxXQxc dMYWSM1O646zK0lVrAnSqdUBVqd0r3pJXGu7mT69tUddoLh00WVkQBBjjaN04+oeUquU qxF83sEK2UdQtqhxlDO/ZME4CDf80muTlhmDL9bz1ToUizytJyp+sELn9Kk+Z5M9Yyzk 9yaqzJ4RDs6WGTKOD1hCLMXXB2eOUk/SUf5XRPegAv64mAWM+YN/KIoWJVMkVVpB5vx+ +IJvzhgMfHP47DK4Qiwu3OlXE07ilc2FNOEATj4KxrOl0jNOfj5fhgzqzSawwxDWomg7 riQA== MIME-Version: 1.0 X-Received: by 10.129.85.86 with SMTP id j83mr32509719ywb.28.1441767240783; Tue, 08 Sep 2015 19:54:00 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.13.237.135 with HTTP; Tue, 8 Sep 2015 19:54:00 -0700 (PDT) In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657D22093@dfweml701-chm> References: <359EC4B99E040048A7131E0F4E113AFCD94F1C56@marathon> <55D01F5E.4070009@gondrom.org> <55DDA4A9.3050603@inria.fr> <8775DC11-7FE3-4A02-89EE-E6BDAC6A1C13@arbor.net> <55DF1EB7.9000703@cisco.com> <4A95BA014132FF49AE685FAB4B9F17F657D22093@dfweml701-chm> Date: Tue, 8 Sep 2015 22:54:00 -0400 X-Google-Sender-Auth: uSD2763ePMKMTwdPNyeBVFmN_rM Message-ID: From: Christopher Morrow To: Linda Dunbar Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Flemming Andreasen , Roland Dobbins , "dots@ietf.org" Subject: Re: [Dots] minimum information to exchange to upstream DDoS (was RE: DOTS: next steps - call for editor volunteers for use case draft and requirements draft X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 02:54:03 -0000 On Tue, Sep 8, 2015 at 4:26 PM, Linda Dunbar wrot= e: > Chris, > > I like your example on the concrete information that the DOTS initiator c= an send to upstream DDoS entity: > > "I am seeing an attack to destination X port/protocol Y/Z" > > Are you saying that other telemetry, like the number of attacks, Src IP a= ddresses or ports of the detected attacks, etc, are not necessary? If the i= nitiator send those detailed information, does it hurt? What are the issues= of sending those extra information beyond taking up some bandwidth? > Quite often the ISP customer has much smaller pipes and much less information about the problem than the ISP has access to. The case often is: "I am being synflooded!!" when the real problem is not a synflood, but a full connection flood where the syns are 'line rate' for the customer access link... or the speed of the server interface :( 'That is not a synflood, that is a full connection flood' there are different methods to mitigate such attacks, so sending an ISP technician off to solve 'syn flood' will not necessarily help in the case of 'full connection flood'. Wrong information is almost always a distraction and time-wasting event for the upstream mitigation provider. The minimal information required upstream is: what ip(s) are being attacked over which protocol(s) to which destination port(s) "can the mitigation provider block all access to the affected address(es)= " (There are, actually, quite a few cases where the /32 being attacked can be turned off, and other services at the end-site are still reachable/useful. The endsite should have the option to say 'just make the attack stop') -chris > Just curious. > > Linda > > > > > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Christopher Morrow > Sent: Friday, September 04, 2015 4:34 PM > To: Flemming Andreasen > Cc: Roland Dobbins; dots@ietf.org > Subject: Re: [Dots] DOTS: next steps - call for editor volunteers for use= case draft and requirements draft > > On Thu, Aug 27, 2015 at 10:29 AM, Flemming Andreasen = wrote: >> On 8/27/15 3:12 AM, Roland Dobbins wrote: >>> >>> On 27 Aug 2015, at 17:01, Xialiang (Frank) wrote: >>> >>>> which includes the DDoS related telemetry information as its part, >>> >>> >>> The DDoS telemetry referred to in the WG charter is a starting point >>> for DOTS signaling - the telemetry itself is out-of-scope for this WG. >> >> Can you clarify the distinction you are making here ? The charter >> explicitly talks about DDoS related telemetry and based on previous >> discussions, It was my understanding that we wanted to provide >> information about an ongoing attack to an upstream entity to enable a >> more accurate and rapid response by that upstream entity. > > perhaps part of the problem here is related to 'provide information about= an ongoing attack to an upstream entity....' > > what information? pps? destination ip/network? src-addresses? > port/protocols used? > > I suspect that the upstream provider can very quickly determine the probl= em in almost all cases, probably better than the initial reporter... and I'= m not sure it's particularly useful to send upstream much more than: > "I am seeing an attack to destination X port/protocol Y/Z" > > you will want to ask the upstream: > "do not disable access" > > probably... and as to the charter, the charter can always be changed... o= r that work item can wait until the decision is that 'this work is not rele= vant anymore'... it'd be best, I think, to focus on the basic dots protocol= work and leave the telemetry for a later decision. > >> >>> If the language needs to be massaged to reflect this, we can do it. >>> >> I don't think we can just change the charter, however we should make >> sure to capture the outcome of this thread as part of the overall requir= ements. > > charters always change, it's not written in stone by aliens. > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Tue Sep 8 19:58:36 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 540391A92B1 for ; Tue, 8 Sep 2015 19:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 y5UbTcIfR1FI for ; Tue, 8 Sep 2015 19:58:33 -0700 (PDT) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A67171A904A for ; Tue, 8 Sep 2015 19:58:33 -0700 (PDT) Received: by ykcf206 with SMTP id f206so150050465ykc.3 for ; Tue, 08 Sep 2015 19:58:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=b/SJOutxMxlzoGKBaajgAadwtZkienEkmDo4ehPBVew=; b=rv/Iwa/rQc4bWXtpG7Qyu8JwM0VweDz6CYvmMWm6j8ZvONB3GfszzwVHnq/lEJ6s7C VO96AbBp+wpUWJJp7J8GC50omyKAYFf7oPu+eF42RJ7E6W7/N0BehgLmo/Cwu1DT/GIf 5OcnUxz71bBn1ao++L2k39dEm0KaU+CZqbE8y7Zmb/DFZosQAW7VFmce06PFqDgpHmus we2nQWXY6vL33EAo5t7oc/jfNhcEnEq+xqdEOLNuh/W5KTfFqPVQVoMjU0oltg7VJmR9 t1Zs0T3+amCNFDdanrAMr+0hjAClWmMfOKWbBTIzqoMhPw8A2goPPv6FhVARvRHCZy8w NDkA== MIME-Version: 1.0 X-Received: by 10.170.150.133 with SMTP id r127mr34298797ykc.52.1441767513038; Tue, 08 Sep 2015 19:58:33 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.13.237.135 with HTTP; Tue, 8 Sep 2015 19:58:32 -0700 (PDT) In-Reply-To: References: <359EC4B99E040048A7131E0F4E113AFCD94F1C56@marathon> <55D01F5E.4070009@gondrom.org> <55DDA4A9.3050603@inria.fr> <8775DC11-7FE3-4A02-89EE-E6BDAC6A1C13@arbor.net> <55DF1EB7.9000703@cisco.com> <4A95BA014132FF49AE685FAB4B9F17F657D22093@dfweml701-chm> Date: Tue, 8 Sep 2015 22:58:32 -0400 X-Google-Sender-Auth: naflj9lRCmis3Ls8ICUvBq6NeIo Message-ID: From: Christopher Morrow To: Roland Dobbins Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: dots@ietf.org Subject: Re: [Dots] minimum information to exchange to upstream DDoS (was RE: DOTS: next steps - call for editor volunteers for use case draft and requirements draft X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 02:58:35 -0000 (teach me to read out of order) On Tue, Sep 8, 2015 at 4:35 PM, Roland Dobbins wrote: > > On 9 Sep 2015, at 3:26, Linda Dunbar wrote: > >> Are you saying that other telemetry, like the number of attacks, Src IP >> addresses or ports of the detected attacks, etc, are not necessary? > > > Not even that amount of information is necessary. 'I am under attack, and > I'm running these apps/services on these ports/protocols, and here're my > credentials' is Good Enough. > I forgot the credentials.. I presumed there was a pre-existing relationship (I think there HAS to be this, really anyway) in which: "requests from IP-X are bob, and are "OK" he has contracted for X services over Y time" (of course that happens automatically, but my point is pre-provisioned relationships are mandatory). Roland's auth point here is: "But I am not bob and I can tell you to do things to bob... hahahaa!" which is, of course, correct... auth is required. >> If the initiator send those detailed information, does it hurt? What are >> the issues of sending those extra information beyond taking up some >> bandwidth? > > > The issue is that the supplicant may not have the capability to do so, or > even if it does, to do so accurately. > it's really the 'accurately' part that I find almost no downstream can get right :( so I'd rather they not confuse the issue and let the mitigation provider figure out what's going on, it really only takes a moment anyway... dos is pretty darned clear when it's happening. > The supplicant may well be an app on a mobile phone that has a Big Red > Button. > > We must make no assumptions that the supplicant has any ability whatsoever > to detect/classify/traceback traffic. It may only be able to know it's > under load, or a human being may've noticed that it's staggering, and pushed > the Big Red Button on that app. > yup! > By self-identifying, the supplicant allows upstream mitigators to > auto-provision countermeasures and other potential mitigation actions. > Provisioning is a huge problem in dealing with DDoS attacks today; DOTS will > have the welcome side-effect of promoting automagic or semi-automagic DDoS > defense provisioning. > this is my hope. > ----------------------------------- > Roland Dobbins > > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Tue Sep 8 20:01:00 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 603831B2F4E for ; Tue, 8 Sep 2015 20:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 PxNphF8aqHdP for ; Tue, 8 Sep 2015 20:00:57 -0700 (PDT) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8D2A1B2F3D for ; Tue, 8 Sep 2015 20:00:57 -0700 (PDT) Received: by ykdu9 with SMTP id u9so74735028ykd.2 for ; Tue, 08 Sep 2015 20:00:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=EM2pCXO52GqcBhB6qQEYZHRKmYIQ2zwZx1RBR7V3+UY=; b=rKsnHEyzHGJeli25kJVmUe/vAy6PwoMwq8lexSM+FPxumi2fHSTwOmMkrM8KYTI2W0 24MOcFab1DC+7Xfqx5vPlpRbzg8hqosDR2d7+0Ze39bpEoWI021gKzbD+/0x1hPYX+el cnz5O65wOXRA/QsKej00RX9/P6iyvkXU3n0aDNLjRxQdaccPRynevRSb371u+L1GyuCY GMBcoiBi57ztBlgEkf3oyS04BWwxHPi23G5HLrfoas5PY7QnnkfE6o3tZDUqaeD3RDxR +rer0olpjwvvDBIWvsB2A/CboN/dBImTAcrn2390J2McXR5c2qdffiOcpnG2UAxfDjfh dfZA== MIME-Version: 1.0 X-Received: by 10.170.128.2 with SMTP id u2mr33624603ykb.72.1441767657076; Tue, 08 Sep 2015 20:00:57 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.13.237.135 with HTTP; Tue, 8 Sep 2015 20:00:56 -0700 (PDT) In-Reply-To: <7F42E6D6-FFFA-45BD-B77C-F4FCC766FF80@arbor.net> References: <359EC4B99E040048A7131E0F4E113AFCD94F1C56@marathon> <55D01F5E.4070009@gondrom.org> <55DDA4A9.3050603@inria.fr> <8775DC11-7FE3-4A02-89EE-E6BDAC6A1C13@arbor.net> <55DF1EB7.9000703@cisco.com> <7F42E6D6-FFFA-45BD-B77C-F4FCC766FF80@arbor.net> Date: Tue, 8 Sep 2015 23:00:56 -0400 X-Google-Sender-Auth: Y87xUS5a4foEjC6HG6u9GzOgYAQ Message-ID: From: Christopher Morrow To: Roland Dobbins Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: dots@ietf.org Subject: Re: [Dots] DOTS: next steps - call for editor volunteers for use case draft and requirements draft X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 03:00:59 -0000 On Mon, Sep 7, 2015 at 2:20 AM, Roland Dobbins wrote: > On 7 Sep 2015, at 11:35, Xialiang (Frank) wrote: > >> In your mind, which kind of threat information is bad information, and >> which is good? > > > I'm not Chris, but what he means is that having incomplete/inaccurate > telemetry is worse than having none at all. exactly. > >> identify the missing IPFIX metrics for specific network threats monitoring >> and propose supplement to current IPFIX metrics set, which does not require >> modifying the IPFIX format. > > > This is not within the remit of this WG. And IPFIX is IPFIX; other than > enterprise elements, there is no modifying it without reopening it. > > We need to focus on getting the actual DOTS protocol standard devised before > going around trying to take other WG's work from them. > yes > All this discussion about IPFIX has not advanced the WG's iota by one > centimeter. Can we please focus on the matter at hand? The first step here is: "Agree on what the protocol between the two endpoints of the conversation (supplicant and mitigation-provider) should include" I think we could start with roland's list ... and move along from there. From nobody Tue Sep 8 20:06:59 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5BF1AD074 for ; Tue, 8 Sep 2015 20:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 OmEHgIWjI-Nu for ; Tue, 8 Sep 2015 20:06:56 -0700 (PDT) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D0761A9114 for ; Tue, 8 Sep 2015 20:06:56 -0700 (PDT) Received: by ykei199 with SMTP id i199so150166554yke.0 for ; Tue, 08 Sep 2015 20:06:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=weVF6HWEIz87dn2NE1rlJ8tFAhZECaHW1jbByUf5+lM=; b=0mZ4ee1f+T+Q9qrE+Ubgp3GuxIh0jzxk54rxLdTlm+gtKsomOn14txep5Sj1OMJjrJ 7Gh2eyuxD4+no0irBZiKH1GURIMi+ue7ErmUhzG30s/qLVOdXxYRuMYLQNXlf71kzDym 0LQudnIzUeImofFfiiIArLK4YhD5/8irvi4uM4mWKpEBUdMd+t1fscXcOUSlmXOj3129 TMvfDlF983cZQWVI/GNJ6RJJd0TSEl8lg4QYFgzwcKxWqNBT8dLYXL/1QEXyhzPJoCwX g5eBMIu4axG6MLmf9nxZ1US9jYR4Rs5guqjntwt+u4nVWdu171IBV6RxVszsoOGJ7aD+ OMxw== MIME-Version: 1.0 X-Received: by 10.129.4.132 with SMTP id 126mr34928352ywe.138.1441768015830; Tue, 08 Sep 2015 20:06:55 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.13.237.135 with HTTP; Tue, 8 Sep 2015 20:06:55 -0700 (PDT) In-Reply-To: <30D26F83-2C2B-4E38-BAF9-E8F73A846E79@arbor.net> References: <359EC4B99E040048A7131E0F4E113AFCD94F1C56@marathon> <55D01F5E.4070009@gondrom.org> <55DDA4A9.3050603@inria.fr> <8775DC11-7FE3-4A02-89EE-E6BDAC6A1C13@arbor.net> <4A95BA014132FF49AE685FAB4B9F17F657D21479@dfweml701-chm> <4A95BA014132FF49AE685FAB4B9F17F657D2208B@dfweml701-chm> <81B4B4EE-C56F-42BC-BBC6-35DE7D4C8124@arbor.net> <3DCF1498-D846-412C-A9AD-AE73E953E89C@arbor.net> <4A95BA014132FF49AE685FAB4B9F17F657D22266@dfweml701-chm> <7113C62D-44B6-4336-A0AE-122113571B88@arbor.net> <30D26F83-2C2B-4E38-BAF9-E8F73A846E79@arbor.net> Date: Tue, 8 Sep 2015 23:06:55 -0400 X-Google-Sender-Auth: dwIfuGTiLsU07wbT-SCHlJu-_q4 Message-ID: From: Christopher Morrow To: Roland Dobbins Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: dots@ietf.org Subject: Re: [Dots] What are the necessary attributes to automatically summon DDoS mitigation on demand ?(was: what are the "good reasons" to oppose "telemetry used for detection/classification/traceback of DDoS attacks" X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 03:06:58 -0000 On Tue, Sep 8, 2015 at 6:51 PM, Roland Dobbins wrote: > > On 9 Sep 2015, at 5:41, Jelena Mirkovic wrote: > >> JIT assumes that someone will mitigate attacks for free, if there was no >> preregistration, no contract. > I'd argue that this isn't really important to the ietf nor dots... the 'business model' could be different depending on the players involved. > > No - JIT assumes the end-customer calls up the ISP/MSSP screaming, "Help, > the Internet is down!", and the ISP/MSSP says, "Credit card, please," and > the end-customer provides it, and then rapid provisioning followed by > mitigation takes place. > > Note that this may also take place online, with zero human-to-human contact. > But the above is the logical representation of the process. > > ;> > yup, sometimes there's payment, sometimes not, in either case, if the process gues from: "oh noz!" to "yes we can help!" the next bit is where dots-like stuff should happen. > A *lot* of DDoS attacks are mitigated (and all too often, not) due to this > kind of approach. DOTS will make it much less error-prone and achievable > within an operationally useful timeframe (e.g., while the attack is still > taking place). > > I've personally taken a combo transit/hosting/colo/wireline broadband > access/wireless mobile broadband ISP from zero DDoS > detection/classification/traceback/mitigation capability to full capability > and active attack mitigation in 90 minutes, *during an attack*, and that > included racking and stacking boxes and getting everything turned up. This > particular attack was against the largest and most prominent bank in the > country in question; the ISP successfully mitigated the attack, everything > came back up, and they negotiated the contractual and billing stuff > post-attack. > > Chris Morrow can provide similar examples, as I'm sure can Stefan Fouant and > Scott Barvick. > yup. have similar experience as roland in this regard. I don't view the business-plan part as important at all to the dots process. -chris > DOTS will make this sort of thing far more doable - and, it's hoped, far > less common, eventually. > > > ----------------------------------- > Roland Dobbins > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Tue Sep 8 22:33:10 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0B281A90B4 for ; Tue, 8 Sep 2015 22:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham 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 rPBLpQjU3Vfp for ; Tue, 8 Sep 2015 22:33:07 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D49D31A21BB for ; Tue, 8 Sep 2015 22:33:07 -0700 (PDT) Received: by padhk3 with SMTP id hk3so61412423pad.3 for ; Tue, 08 Sep 2015 22:33:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-type; bh=m5lGzkmKrlbyhHlyyeuOxM17Vg4Eo1yvFxYNwKRdBWo=; b=fPbQnxaHNf1oMI2d2a6DxwYbIvILFnt0RkGjQ/49drjCtqMGyWzxKabvAKusdmr5ZZ eE8ZEQiywUy4bonsuIqHLhIPFAfckCh4v7ur98qGUKidsexIK3+qC6ItdNFeW8PReLYW py/QJWKeX1qbC+HeZLriuHyA9ByKIFR4gGxIk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-type; bh=m5lGzkmKrlbyhHlyyeuOxM17Vg4Eo1yvFxYNwKRdBWo=; b=aSO5m9gHQqbluL3RpDIqBNZdLcY0nv5w3MLZPiTrBBMjXfzZD76fgQ7O7/ZIJO2nY8 0WEINc06qF/6bUujWX5mhBMflfynzcloZQw51cSUvEaF98n5ARZ3GChn8hgbiwaHv1hc Jv/AmPf64nWiGCOvv2HzWEUYfnqxOrh04kJBDuK5YOi/Jwz5SOkFCigUGLLpO1rfZrmt eSdc2MVYw7vXmTSM9og3Fjs+YIVNdOV2pfsd/KNQ2tppjRIOS3RQ7tpbdvIXdZC/sNQi yF9rLgDz9JErwsbckHcU50BQpuMqGG46tp34WgkDlNAmhmerpEGcIOGhcwuBaqNPgfxO DX0g== X-Gm-Message-State: ALoCoQkFdbV8t/xeGUHn5g2CjjyfBFW/5xTwwxbWYsIdEJ01H01Qwh5wwBdgLJZfwat07ydOnGqv X-Received: by 10.67.30.232 with SMTP id kh8mr57325496pad.36.1441776787371; Tue, 08 Sep 2015 22:33:07 -0700 (PDT) Received: from [172.19.254.107] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id fg5sm5464854pdb.33.2015.09.08.22.33.06 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 08 Sep 2015 22:33:06 -0700 (PDT) From: "Roland Dobbins" To: dots@ietf.org Date: Wed, 09 Sep 2015 12:33:03 +0700 Message-ID: <8A3A6425-BEFB-4AE4-96AB-A603BABC397B@arbor.net> In-Reply-To: References: <359EC4B99E040048A7131E0F4E113AFCD94F1C56@marathon> <55D01F5E.4070009@gondrom.org> <55DDA4A9.3050603@inria.fr> <8775DC11-7FE3-4A02-89EE-E6BDAC6A1C13@arbor.net> <4A95BA014132FF49AE685FAB4B9F17F657D21479@dfweml701-chm> <4A95BA014132FF49AE685FAB4B9F17F657D2208B@dfweml701-chm> <81B4B4EE-C56F-42BC-BBC6-35DE7D4C8124@arbor.net> <3DCF1498-D846-412C-A9AD-AE73E953E89C@arbor.net> <4A95BA014132FF49AE685FAB4B9F17F657D22266@dfweml701-chm> <7113C62D-44B6-4336-A0AE-122113571B88@arbor.net> <30D26F83-2C2B-4E38-BAF9-E8F73A846E79@arbor.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Subject: Re: [Dots] What are the necessary attributes to automatically summon DDoS mitigation on demand ?(was: what are the "good reasons" to oppose "telemetry used for detection/classification/traceback of DDoS attacks" X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 05:33:09 -0000 On 9 Sep 2015, at 10:06, Christopher Morrow wrote: > I'd argue that this isn't really important to the ietf nor dots... the > 'business model' could be different depending on the players involved. Concur - just pointing out that pre-provisioning isn't absolutely necessary, in response to Linda's question. ----------------------------------- Roland Dobbins From nobody Wed Sep 9 01:44:40 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC7EC1B2C0A for ; Wed, 9 Sep 2015 01:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 MiEFqufAOxbg for ; Wed, 9 Sep 2015 01:44:37 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 899321B2E98 for ; Wed, 9 Sep 2015 01:44:37 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=N01332) by mail.jpshallow.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1ZZazb-00081m-G4 for ietf-supjps-dots@ietf.org; Wed, 09 Sep 2015 09:44:35 +0100 From: "Jon Shallow" To: References: <359EC4B99E040048A7131E0F4E113AFCD94F1C56@marathon> <55D01F5E.4070009@gondrom.org> <55DDA4A9.3050603@inria.fr> <8775DC11-7FE3-4A02-89EE-E6BDAC6A1C13@arbor.net> <55DF1EB7.9000703@cisco.com> <4A95BA014132FF49AE685FAB4B9F17F657D22093@dfweml701-chm> In-Reply-To: Date: Wed, 9 Sep 2015 09:44:34 +0100 Message-ID: <009d01d0eadb$c0c24940$4246dbc0$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKqnVVYz3uzQGPcpyLqz9bcUm4oVwINla7XAcaXWfABtlcnUwOOix+bASt6m+QB2wgESgJVZdrCAlc0ltYDCp9EPgLXP8+ZAerSWIKbu7RRMA== Content-Language: en-gb Archived-At: Subject: Re: [Dots] minimum information to exchange to upstream DDoS (was RE: DOTS: next steps - call for editor volunteers for use case draft and requirements draft X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 08:44:39 -0000 I would also argue that the source port potentially is also a vital component if it is singular. Think reflective attacks coming back from port 123, 53 etc. to potentially random destination ports in which case the destination port is usually meaningless. Regards Jon -----Original Message----- From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of Christopher Morrow Sent: 09 September 2015 03:54 To: Linda Dunbar Cc: Flemming Andreasen; Roland Dobbins; dots@ietf.org Subject: Re: [Dots] minimum information to exchange to upstream DDoS (was RE: DOTS: next steps - call for editor volunteers for use case draft and requirements draft On Tue, Sep 8, 2015 at 4:26 PM, Linda Dunbar wrote: > Chris, > > I like your example on the concrete information that the DOTS initiator can send to upstream DDoS entity: > > "I am seeing an attack to destination X port/protocol Y/Z" > > Are you saying that other telemetry, like the number of attacks, Src IP addresses or ports of the detected attacks, etc, are not necessary? If the initiator send those detailed information, does it hurt? What are the issues of sending those extra information beyond taking up some bandwidth? > Quite often the ISP customer has much smaller pipes and much less information about the problem than the ISP has access to. The case often is: "I am being synflooded!!" when the real problem is not a synflood, but a full connection flood where the syns are 'line rate' for the customer access link... or the speed of the server interface :( 'That is not a synflood, that is a full connection flood' there are different methods to mitigate such attacks, so sending an ISP technician off to solve 'syn flood' will not necessarily help in the case of 'full connection flood'. Wrong information is almost always a distraction and time-wasting event for the upstream mitigation provider. The minimal information required upstream is: what ip(s) are being attacked over which protocol(s) to which destination port(s) "can the mitigation provider block all access to the affected address(es)" (There are, actually, quite a few cases where the /32 being attacked can be turned off, and other services at the end-site are still reachable/useful. The endsite should have the option to say 'just make the attack stop') -chris > Just curious. > > Linda > > > > > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Christopher > Morrow > Sent: Friday, September 04, 2015 4:34 PM > To: Flemming Andreasen > Cc: Roland Dobbins; dots@ietf.org > Subject: Re: [Dots] DOTS: next steps - call for editor volunteers for > use case draft and requirements draft > > On Thu, Aug 27, 2015 at 10:29 AM, Flemming Andreasen wrote: >> On 8/27/15 3:12 AM, Roland Dobbins wrote: >>> >>> On 27 Aug 2015, at 17:01, Xialiang (Frank) wrote: >>> >>>> which includes the DDoS related telemetry information as its part, >>> >>> >>> The DDoS telemetry referred to in the WG charter is a starting point >>> for DOTS signaling - the telemetry itself is out-of-scope for this WG. >> >> Can you clarify the distinction you are making here ? The charter >> explicitly talks about DDoS related telemetry and based on previous >> discussions, It was my understanding that we wanted to provide >> information about an ongoing attack to an upstream entity to enable a >> more accurate and rapid response by that upstream entity. > > perhaps part of the problem here is related to 'provide information about an ongoing attack to an upstream entity....' > > what information? pps? destination ip/network? src-addresses? > port/protocols used? > > I suspect that the upstream provider can very quickly determine the problem in almost all cases, probably better than the initial reporter... and I'm not sure it's particularly useful to send upstream much more than: > "I am seeing an attack to destination X port/protocol Y/Z" > > you will want to ask the upstream: > "do not disable access" > > probably... and as to the charter, the charter can always be changed... or that work item can wait until the decision is that 'this work is not relevant anymore'... it'd be best, I think, to focus on the basic dots protocol work and leave the telemetry for a later decision. > >> >>> If the language needs to be massaged to reflect this, we can do it. >>> >> I don't think we can just change the charter, however we should make >> sure to capture the outcome of this thread as part of the overall requirements. > > charters always change, it's not written in stone by aliens. > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Wed Sep 9 02:39:00 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C9631A8A65 for ; Wed, 9 Sep 2015 02:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham 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 deUJOxJZFq7m for ; Wed, 9 Sep 2015 02:38:58 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C4C31AC447 for ; Wed, 9 Sep 2015 02:38:58 -0700 (PDT) Received: by padhk3 with SMTP id hk3so5317567pad.3 for ; Wed, 09 Sep 2015 02:38:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-type; bh=ZgHQmCynJCHABYpAABwshA6PXoXjWxnreefuhU2Wgis=; b=Ia3xcD3+c6Ly7d4FLdIbZjIfbobvP9FDZ+86KCiEu6lRn0S3zvKGIcBUiyCFNiB0sp us98GsNGD90FE77SchBF6k83WY9W2lEJCoB9F2sFAkrfFC5/IszUXsLFOjIzpSn6+wvm Sf5FfHqwbF+bLL6VNq538d+rbRb24Rlr4Pj5w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-type; bh=ZgHQmCynJCHABYpAABwshA6PXoXjWxnreefuhU2Wgis=; b=c5Tmt3CzjIzXxwFmyLFKSTc1b6h3Y4Xw2M/jvirTjD6xZwjodqEpadqN67gc/jrH12 60S30sfHKIGnU8Oz1FmDDBAdqnbb1JxzJDxx3irUZxLBaVPeC2Rg5j1yaePa9DUD5j5d kd2PgbrbZ+SPhGkqX/qQOgPgntUhFvvHXYIQQzJYzroPp/7zwPGFhcMjwSPnEhMVn1VB L7trHY9w/lLv0H1O7fjt7XwGJTRZMdiGJ+bmSIsUlOW9S9BdEmXEpDC5/7DWcN5dC775 RNOdJBEMz8M6+ooCwb/4viZzl4Qal4K5aHw5SBlh8raG08kQPf1B6xPuhDp6NfeoXudh JvBA== X-Gm-Message-State: ALoCoQmq/1Rwd5M3c8YcW1XF02izVgw7kqyngjxvmD0LG4KgrclEpj8P5hfHPbbAPDrSagRSp/0O X-Received: by 10.68.102.225 with SMTP id fr1mr69720432pbb.65.1441791538059; Wed, 09 Sep 2015 02:38:58 -0700 (PDT) Received: from [172.19.254.107] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id xv1sm6343272pbb.25.2015.09.09.02.38.55 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 09 Sep 2015 02:38:57 -0700 (PDT) From: "Roland Dobbins" To: dots@ietf.org Date: Wed, 09 Sep 2015 16:38:53 +0700 Message-ID: <01811E7E-E18D-4C9F-A5A5-C5BA3226DDDE@arbor.net> In-Reply-To: <009d01d0eadb$c0c24940$4246dbc0$@jpshallow.com> References: <359EC4B99E040048A7131E0F4E113AFCD94F1C56@marathon> <55D01F5E.4070009@gondrom.org> <55DDA4A9.3050603@inria.fr> <8775DC11-7FE3-4A02-89EE-E6BDAC6A1C13@arbor.net> <55DF1EB7.9000703@cisco.com> <4A95BA014132FF49AE685FAB4B9F17F657D22093@dfweml701-chm> <009d01d0eadb$c0c24940$4246dbc0$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Subject: Re: [Dots] minimum information to exchange to upstream DDoS (was RE: DOTS: next steps - call for editor volunteers for use case draft and requirements draft X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 09:39:00 -0000 On 9 Sep 2015, at 15:44, Jon Shallow wrote: > I would also argue that the source port potentially is also a vital > component if it is singular. Think reflective attacks coming back > from port > 123, 53 etc. to potentially random destination ports in which case the > destination port is usually meaningless. Again, there mustn't be a presumption of any detection/classification/traceback capability on the supplicant. Most UDP reflection/amplification attacks pummel either UDP/80, UDP/443, UDP/123, and UDP/53 on the target, btw. ----------------------------------- Roland Dobbins From nobody Wed Sep 9 06:09:08 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3091B3422 for ; Wed, 9 Sep 2015 06:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 ePG6GPdTtzaU for ; Wed, 9 Sep 2015 06:09:01 -0700 (PDT) Received: from atl4mhob15.myregisteredsite.com (atl4mhob15.myregisteredsite.com [209.17.115.53]) by ietfa.amsl.com (Postfix) with ESMTP id 603081B3390 for ; Wed, 9 Sep 2015 06:09:01 -0700 (PDT) Received: from atl4oxapp107.mgt.hosting.qts.netsol.com ([10.30.71.144]) by atl4mhob15.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id t89D8vhC016901; Wed, 9 Sep 2015 09:08:57 -0400 Date: Wed, 9 Sep 2015 09:08:57 -0400 (EDT) From: "gclark mti-systems.com" To: dots , Roland Dobbins Message-ID: <737719725.3158.1441804137966.JavaMail.vpopmail@atl4oxapp107.mgt.hosting.qts.netsol.com> In-Reply-To: <01811E7E-E18D-4C9F-A5A5-C5BA3226DDDE@arbor.net> References: <359EC4B99E040048A7131E0F4E113AFCD94F1C56@marathon> <55D01F5E.4070009@gondrom.org> <55DDA4A9.3050603@inria.fr> <8775DC11-7FE3-4A02-89EE-E6BDAC6A1C13@arbor.net> <55DF1EB7.9000703@cisco.com> <4A95BA014132FF49AE685FAB4B9F17F657D22093@dfweml701-chm> <009d01d0eadb$c0c24940$4246dbc0$@jpshallow.com> <01811E7E-E18D-4C9F-A5A5-C5BA3226DDDE@arbor.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.6.2-Rev14 X-Originating-Client: open-xchange-appsuite Archived-At: Subject: Re: [Dots] minimum information to exchange to upstream DDoS (was RE: DOTS: next steps - call for editor volunteers for use case draft and requirements draft X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "gclark mti-systems.com" List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 13:09:06 -0000 I think earlier in the thread there was also a question of if or how detection / classification / traceback of the supplicant could be trusted if it is present. I suppose that one could set up something involving signatures and reputation as ways to establish varying degrees of trust (and thus support different sets of telemetry), but that seems like it could be complex to implement, deploy, and maintain. Regardless, +1 that most information should be optional. In general, I'm of the opinion that DOTS should: * Keep *requirements* for mitigation requests simple * Offer a way to *optionally* include additional information with the message for the provider to consider ] Offhand, I'd think that information encoded here should be arbitrary but self-descriptive, with a registry of well-known types of telemetry ] For example, "source port", "destination port", that kind of thing ] I don't think message size is a primary consideration (as long as it's sane) ] Alternative idea might be to use publish / subscribe for this - customer explicitly requests mitigation assistance to provider and the message includes a subscription endpoint to which the provider can attach to receive more information about the attack. provider can optionally choose to subscribe to indicated endpoint. customer's device then publishes telemetry (over something that might work better across a bad link ... raptor codes come to mind, but maybe not) to all subscribed providers, who are able to use that information in whatever way they see (or don't see) fit. * If additional information is included, explicitly note that the provider is under no obligation to do anything with it (though it can if it wants) Also, it might be interesting to say that, *if* any additional information is included beyond "help, I'm under attack", there is expected to be a minimum set of components that are included then (e.g. must specify port information or something). -Gilbert > On September 9, 2015 at 5:38 AM Roland Dobbins wrote: > > > > On 9 Sep 2015, at 15:44, Jon Shallow wrote: > > > I would also argue that the source port potentially is also a vital > > component if it is singular. Think reflective attacks coming back > > from port > > 123, 53 etc. to potentially random destination ports in which case the > > destination port is usually meaningless. > > Again, there mustn't be a presumption of any > detection/classification/traceback capability on the supplicant. > > Most UDP reflection/amplification attacks pummel either UDP/80, UDP/443, > UDP/123, and UDP/53 on the target, btw. > > > > ----------------------------------- > Roland Dobbins > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Wed Sep 9 06:25:55 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 475DD1B2BD7 for ; Wed, 9 Sep 2015 06:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 yKOFo5vMI3QK for ; Wed, 9 Sep 2015 06:25:48 -0700 (PDT) Received: from atl4mhob18.myregisteredsite.com (atl4mhob18.myregisteredsite.com [209.17.115.111]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC8E1B2C39 for ; Wed, 9 Sep 2015 06:25:48 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.208]) by atl4mhob18.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id t89DPenv009198 for ; Wed, 9 Sep 2015 09:25:40 -0400 Received: (qmail 28237 invoked by uid 0); 9 Sep 2015 13:25:37 -0000 X-TCPREMOTEIP: 24.166.126.82 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.0.148?) (wes@mti-systems.com@24.166.126.82) by 0 with ESMTPA; 9 Sep 2015 13:25:36 -0000 From: Wesley Eddy To: Christopher Morrow References: <55CB494A.9020706@mti-systems.com> Organization: MTI Systems Message-ID: <55F03348.3090604@mti-systems.com> Date: Wed, 9 Sep 2015 09:25:28 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "gclark mti-systems.com" , "dots@ietf.org" , Justin Dailey Subject: Re: [Dots] use of SDN for DDoS mitigation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 13:25:54 -0000 On 9/4/2015 5:10 PM, Christopher Morrow wrote: > On Wed, Aug 12, 2015 at 9:25 AM, Wesley Eddy wrote: >> This is not strictly within the scope of the DOTS charter, but >> because it's related to DDoS mitigation, we thought it might >> be of interest to the DOTS list. >> >> This draft was posted to the SDNRG, and discusses use of OpenFlow >> interdomain, for delegating control of ISP network filtering to >> customers: > > Folk might consider looking at the prior-art in this arena... > specifically N-Layer's use of flow-spec from customers, and the fairly > well published failure modes of same. Hi Christopher, thanks for your comments. We are also doing some research on improvements to the BGP flowspec capability that you might be interested in: https://tools.ietf.org/html/draft-eddy-idr-flowspec-exp-00 This doesn't directly answer to the implementation problems referenced above, but those seem like software issues more than protocol failings. > 'Let your customer traffic engineer your network!' (no, don't do that) > 'Let your customer consume valuable resources on devices in your > network to which they have no ideas about limits of' (no, don't do > that) On this, we fully agree, and in fact our approach is to keep the ISPs in full control of their own networks, and to only allow customers to control a limited amount of flow table resources, for filtering only, and those are sandwiched between ingress and egress flow table chains that the ISP retains full control of (and are not made visible to the customers). Any comments you have on that approach would be really interesting to us. We think it might meet your requirement of keeping the customer from trying to engineer the provider's network or chew up resources. If this isn't of interest to the rest of DOTS, the chairs can kick us off-list, and we won't be offended. -- Wes Eddy MTI Systems From nobody Wed Sep 9 06:37:55 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2801A005B for ; Wed, 9 Sep 2015 06:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham 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 hWoUitDULxhy for ; Wed, 9 Sep 2015 06:37:51 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7155C1A00D4 for ; Wed, 9 Sep 2015 06:37:51 -0700 (PDT) Received: by padhy16 with SMTP id hy16so10884109pad.1 for ; Wed, 09 Sep 2015 06:37:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-type; bh=JIzmzcxx/PyH2+tlOL5gKHGxhveHDXSeXRgZsPWtYmQ=; b=RfASFz75sR+0r0UgEGVxZ70d1o1K45kuicMn5BfoJOOUCZmNbP2j8cnn/9ZUbVbFVY Z4Vu41La7SEB4CeF330NQFFny40aBzwJhLHin1+s1mCBkRuK5QpNggTV/qTgBIcL0In4 JwLFupmcOUDgBFqvI75i5IF22Gf0spBSVs3Zk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-type; bh=JIzmzcxx/PyH2+tlOL5gKHGxhveHDXSeXRgZsPWtYmQ=; b=ZKLWsz+KHK/Euz9HGS4V0qm4WqYLQYKQvwZPESrlmNXaAx2V14AqyQmQQKfLd+lytw o8PpVDG9490b5ZJD0qJPk+GiFNZ/tNt0d5mC/GQ3bgAXbkCYU/eoe0R6eohP79Pk0381 IWHgCHRux12tACXXZFwGxGJWpXCrWttl37SwQXUl4MEmPYgbgyNBvUOItRPZTOsSaRTs ASQ2VTtXKWP1yRhYAyiQqGn/CJdgMwD3W+YVyQV3RTF3X7y+IxOrBXbTyZICAGgl706v RXZB2WXyuJlvRprX/9sI18hhGGeYJC4tpviVSSBiHlJHjLnmrRC7D1ttXR6xZ1R/NP7g tZHg== X-Gm-Message-State: ALoCoQmVCkNg8tjUopAD1J/x/Xwpjf4u3HjrphYVnPz42f+23KliAzKu+Y81CVfbrVQfFgmfBw8X X-Received: by 10.68.125.197 with SMTP id ms5mr71808838pbb.38.1441805870915; Wed, 09 Sep 2015 06:37:50 -0700 (PDT) Received: from [172.19.254.107] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id qv5sm2401230pbc.71.2015.09.09.06.37.48 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 09 Sep 2015 06:37:50 -0700 (PDT) From: "Roland Dobbins" To: dots@ietf.org Date: Wed, 09 Sep 2015 20:37:46 +0700 Message-ID: In-Reply-To: <55F03348.3090604@mti-systems.com> References: <55CB494A.9020706@mti-systems.com> <55F03348.3090604@mti-systems.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Cc: Wesley Eddy , "gclark mti-systems.com" , Christopher Morrow , Justin Dailey Subject: Re: [Dots] use of SDN for DDoS mitigation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 13:37:53 -0000 On 9 Sep 2015, at 20:25, Wesley Eddy wrote: > If this isn't of interest to the rest of DOTS, the chairs can kick us > off-list, and we won't be offended. It's of general interest, but not directly relevant, IMHO. We're focusing on signaling to initiate DDoS mitigation, not on actual mitigation mechanisms; that's what happens post-signaling. Still good info for folks to know. I personally think draft-eddy-idr-flowspec-exp-00 is a welcome set of enhancements to flowspec, and strongly support this work. ----------------------------------- Roland Dobbins From nobody Wed Sep 9 06:42:52 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2671A8961 for ; Wed, 9 Sep 2015 06:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham 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 xUfhm3QFEgqN for ; Wed, 9 Sep 2015 06:42:48 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71E511A894E for ; Wed, 9 Sep 2015 06:42:48 -0700 (PDT) Received: by pacex6 with SMTP id ex6so11030113pac.0 for ; Wed, 09 Sep 2015 06:42:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-type; bh=EDbc60JOGCGd4QSv7h3Fa6x6Os7Fo9gWelom2OY+//U=; b=BMwVywIR2dQZVarI8Gi7LIDGrZC3djZNb01Fl0eqfTyUP+Weva1BhFnN2z4RGP73RW Fj++RyrZvXeIvmPKiExGDsZ9KOTeFeydkzUImDEK/91AXzPNoT++1+p+Zl247kpZPzK1 e+oqEDraytNmfct95v5ShMWem74c2eiRGC/As= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-type; bh=EDbc60JOGCGd4QSv7h3Fa6x6Os7Fo9gWelom2OY+//U=; b=VOVaUQhRfUFX3Oaqkrx2KXp7EFok21bsJcRxnv8PCMUm/8a+xLGEjIXiltvJ1AFSgC BaovjFHNT/affQAFWtBGQdEtTPOyX8cuesbZWSl8+WQHoqafEvRiyVEFOqoErEgtFWpm k3ggTKpFG57meQvjdzSZn/R6tPB6UU3QUrmM8csEP1yRUsKtczvX9EdA8o+jC0B4nAFo m5ictZQ1DBX4YgVW1msGJgcgTHj4y8jTcLkMUWCTT3835KDtzP8AIOB53v6XOrhWpTNL 4/BswPpoOm+OAROWjLzRBzJe/4og6sOYlbsnQICwMzvvptj3KWa+uBR7yOhdjkyNcJ6+ UV0Q== X-Gm-Message-State: ALoCoQmP23Rpt9Mw5IeL/fXnclwWb71l9nfK4Gy4W8dsIlxJVbf77n2qgfgHzrsxD/4KWNTlidzY X-Received: by 10.66.186.39 with SMTP id fh7mr62553127pac.48.1441806168095; Wed, 09 Sep 2015 06:42:48 -0700 (PDT) Received: from [172.19.254.107] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id rg10sm7131344pbc.33.2015.09.09.06.42.46 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 09 Sep 2015 06:42:47 -0700 (PDT) From: "Roland Dobbins" To: dots Date: Wed, 09 Sep 2015 20:42:43 +0700 Message-ID: <0B878DC6-7210-4C3D-9283-395580C90679@arbor.net> In-Reply-To: <737719725.3158.1441804137966.JavaMail.vpopmail@atl4oxapp107.mgt.hosting.qts.netsol.com> References: <359EC4B99E040048A7131E0F4E113AFCD94F1C56@marathon> <55D01F5E.4070009@gondrom.org> <55DDA4A9.3050603@inria.fr> <8775DC11-7FE3-4A02-89EE-E6BDAC6A1C13@arbor.net> <55DF1EB7.9000703@cisco.com> <4A95BA014132FF49AE685FAB4B9F17F657D22093@dfweml701-chm> <009d01d0eadb$c0c24940$4246dbc0$@jpshallow.com> <01811E7E-E18D-4C9F-A5A5-C5BA3226DDDE@arbor.net> <737719725.3158.1441804137966.JavaMail.vpopmail@atl4oxapp107.mgt.hosting.qts.netsol.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Subject: Re: [Dots] minimum information to exchange to upstream DDoS (was RE: DOTS: next steps - call for editor volunteers for use case draft and requirements draft X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 13:42:50 -0000 On 9 Sep 2015, at 20:08, gclark mti-systems.com wrote: > I think earlier in the thread there was also a question of if or how > detection / > classification / traceback of the supplicant could be trusted if it is > present. The concern was actually regarding fidelity; DOTS will have auth reds. > Alternative idea might be to use publish / subscribe for this - > customer > explicitly requests mitigation assistance to provider and the message > includes a > subscription endpoint to which the provider can attach to receive more > information about the attack. provider can optionally choose to > subscribe to > indicated endpoint. customer's device then publishes telemetry (over > something > that might work better across a bad link ... raptor codes come to > mind, but > maybe not) to all subscribed providers, who are able to use that > information in > whatever way they see (or don't see) fit. This is way too complex and well beyond our remit, IMHO. We're working on the signaling protocol, and functions directly associated therewith. This gets into other areas which may be interesting, but not part of what we're directly trying to accomplish with DOTS. > * If additional information is included, explicitly note that the > provider is > under no obligation to do anything with it (though it can if it wants) Concur with this. > > Also, it might be interesting to say that, *if* any additional > information is > included beyond "help, I'm under attack", there is expected to be a > minimum set > of components that are included then (e.g. must specify port > information or > something). Concur with this, too. ----------------------------------- Roland Dobbins From nobody Wed Sep 9 07:27:44 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAD4E1ACE64 for ; Wed, 9 Sep 2015 07:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 x7fysoXJ9iV0 for ; Wed, 9 Sep 2015 07:27:36 -0700 (PDT) Received: from atl4mhfb03.myregisteredsite.com (atl4mhfb03.myregisteredsite.com [209.17.115.61]) (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 534721A8AD4 for ; Wed, 9 Sep 2015 07:27:36 -0700 (PDT) Received: from atl4mhob19.myregisteredsite.com (atl4mhob19.myregisteredsite.com [209.17.115.112]) by atl4mhfb03.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id t89ERWEe022441 for ; Wed, 9 Sep 2015 10:27:32 -0400 Received: from atl4oxapp107.mgt.hosting.qts.netsol.com ([10.30.71.144]) by atl4mhob19.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id t89EQp8H019441; Wed, 9 Sep 2015 10:26:51 -0400 Date: Wed, 9 Sep 2015 10:26:51 -0400 (EDT) From: "gclark mti-systems.com" To: dots , Roland Dobbins Message-ID: <1919208794.5969.1441808811868.JavaMail.vpopmail@atl4oxapp107.mgt.hosting.qts.netsol.com> In-Reply-To: <0B878DC6-7210-4C3D-9283-395580C90679@arbor.net> References: <359EC4B99E040048A7131E0F4E113AFCD94F1C56@marathon> <55D01F5E.4070009@gondrom.org> <55DDA4A9.3050603@inria.fr> <8775DC11-7FE3-4A02-89EE-E6BDAC6A1C13@arbor.net> <55DF1EB7.9000703@cisco.com> <4A95BA014132FF49AE685FAB4B9F17F657D22093@dfweml701-chm> <009d01d0eadb$c0c24940$4246dbc0$@jpshallow.com> <01811E7E-E18D-4C9F-A5A5-C5BA3226DDDE@arbor.net> <737719725.3158.1441804137966.JavaMail.vpopmail@atl4oxapp107.mgt.hosting.qts.netsol.com> <0B878DC6-7210-4C3D-9283-395580C90679@arbor.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.6.2-Rev14 X-Originating-Client: open-xchange-appsuite Archived-At: Subject: Re: [Dots] minimum information to exchange to upstream DDoS (was RE: DOTS: next steps - call for editor volunteers for use case draft and requirements draft X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "gclark mti-systems.com" List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 14:27:43 -0000 > > Alternative idea might be to use publish / subscribe for this - > > customer > > explicitly requests mitigation assistance to provider and the message > > includes a > > subscription endpoint to which the provider can attach to receive more > > information about the attack. provider can optionally choose to > > subscribe to > > indicated endpoint. customer's device then publishes telemetry (over > > something > > that might work better across a bad link ... raptor codes come to > > mind, but > > maybe not) to all subscribed providers, who are able to use that > > information in > > whatever way they see (or don't see) fit. > > This is way too complex and well beyond our remit, IMHO. > > We're working on the signaling protocol, and functions directly > associated therewith. This gets into other areas which may be > interesting, but not part of what we're directly trying to accomplish > with DOTS. > I'll buy the way too complex bit. In my head, the actual straw-man there wasn't intended to be the focus so much as the idea that, in general, it might make sense to just point the provider to a way to *get* the information it wants / needs from the customer (should the customer choose to provide it) than it would to actually provide that information as a part of any DOTS protocol ... that keeps the initial HELP message sizes to a relative minimum, avoids wasted telemetry frames destined for the provider if the provider isn't interested, and is an attempt to avoid protocol bloat (since, in theory, this could lead to less of a temptation to keep adding new, "useful" fields to a signaling protocol). Cheers, Gilbert From nobody Wed Sep 9 08:47:08 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 486331A1A76 for ; Wed, 9 Sep 2015 08:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 HC7_qeQozU9l for ; Wed, 9 Sep 2015 08:47:03 -0700 (PDT) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BA7E1B2F8C for ; Wed, 9 Sep 2015 08:47:03 -0700 (PDT) Received: by ykdt18 with SMTP id t18so895898ykd.3 for ; Wed, 09 Sep 2015 08:47:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=rJn6bVyxJI1mV2Y79YQqnsZCsFK7O/JUKE23jMFloGU=; b=k6ZklR7PCQxg+UWhd0NoKn1Q9Y9OJ5NPcYMd+83ugH3exbyjmb6ACIaf97/OQBZcov qzv1XjUhXJLdzrBSFtblH7q4N35259l5+J0mN3ounT/IoA3JeLjGBL0T6ihbhMjiPAGG amev6sVIt74JCQ1c7aEtVkbjehV1o2YmrK8y4yFDB/B4f7HunlySNSF8jTCJ1JyVAOZN MggjY3MUEOn7ux6HpSoWOx9CAfEnC+aRHM39UKOJuZoAHoBpdSxlXGmI0qZACYD+uJ5/ JOsMiz0bcFqvXvhGu8lwwmaQUHpwB3eNJrhwG9YTW9oVAH5oLjxab/YimlfBVzLwgq6B 23nA== MIME-Version: 1.0 X-Received: by 10.129.4.132 with SMTP id 126mr39681946ywe.138.1441813622641; Wed, 09 Sep 2015 08:47:02 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.13.237.135 with HTTP; Wed, 9 Sep 2015 08:47:02 -0700 (PDT) In-Reply-To: <8A3A6425-BEFB-4AE4-96AB-A603BABC397B@arbor.net> References: <359EC4B99E040048A7131E0F4E113AFCD94F1C56@marathon> <55D01F5E.4070009@gondrom.org> <55DDA4A9.3050603@inria.fr> <8775DC11-7FE3-4A02-89EE-E6BDAC6A1C13@arbor.net> <4A95BA014132FF49AE685FAB4B9F17F657D21479@dfweml701-chm> <4A95BA014132FF49AE685FAB4B9F17F657D2208B@dfweml701-chm> <81B4B4EE-C56F-42BC-BBC6-35DE7D4C8124@arbor.net> <3DCF1498-D846-412C-A9AD-AE73E953E89C@arbor.net> <4A95BA014132FF49AE685FAB4B9F17F657D22266@dfweml701-chm> <7113C62D-44B6-4336-A0AE-122113571B88@arbor.net> <30D26F83-2C2B-4E38-BAF9-E8F73A846E79@arbor.net> <8A3A6425-BEFB-4AE4-96AB-A603BABC397B@arbor.net> Date: Wed, 9 Sep 2015 11:47:02 -0400 X-Google-Sender-Auth: jENN42u5-i0E26HarR2Ce9Yw0TQ Message-ID: From: Christopher Morrow To: Roland Dobbins Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: dots@ietf.org Subject: Re: [Dots] What are the necessary attributes to automatically summon DDoS mitigation on demand ?(was: what are the "good reasons" to oppose "telemetry used for detection/classification/traceback of DDoS attacks" X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 15:47:07 -0000 On Wed, Sep 9, 2015 at 1:33 AM, Roland Dobbins wrote: > On 9 Sep 2015, at 10:06, Christopher Morrow wrote: > >> I'd argue that this isn't really important to the ietf nor dots... the >> 'business model' could be different depending on the players involved. > > > Concur - just pointing out that pre-provisioning isn't absolutely necessary, > in response to Linda's question. yup, totally agree with this. From nobody Thu Sep 10 12:34:04 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E52681A88B8 for ; Thu, 10 Sep 2015 12:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.088 X-Spam-Level: X-Spam-Status: No, score=0.088 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=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 jkrpwP3Q3Lx1 for ; Thu, 10 Sep 2015 12:34:01 -0700 (PDT) Received: from mail-vk0-f46.google.com (mail-vk0-f46.google.com [209.85.213.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B4F31A908B for ; Thu, 10 Sep 2015 12:34:01 -0700 (PDT) Received: by vkhf67 with SMTP id f67so15370655vkh.1 for ; Thu, 10 Sep 2015 12:34:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gU4ky+rvcOhhrpuj0ze2220/JZEfu1OPmxet4KROhgc=; b=Il5sQEtE7KuFCIfmi/P6VddXBYzOEigvXnNcc9BATzjC06NPXDWBCqqiXwyuyCI+A5 ucd3N/HyL2GFt4LoV9yHN98fG/xVf79SNLsBxVCuhWzqi6pxW7TVTRjvOfMLQ3c+PXb1 pkwZ3ZM7PoUQNm3yl9sE78pFCo0ffNmp3mDcTGIFXtFKLQU0SNfY21MDIqgnGoBBMdxT Yhw/Lf/G3xTP7NKnaawYBjFuH5Kb5oY6FeC9Uv+EWRl9hUlXve6DU3o6SuDfJyYVmcjW 8LfC2SheJ5s12bzweOSA3u+88g3k2+XZojxECencdWGngnC1k8jSDazBVzKufwxqlazv wEww== X-Gm-Message-State: ALoCoQk3vb/wXN8O/K1vuggKypaKEr3VlTmq+P7IIvpAQuv5Qn5Ba2UyQRxdV2J1DBDMkDAIs+tF MIME-Version: 1.0 X-Received: by 10.31.4.145 with SMTP id 139mr2198515vke.76.1441913640177; Thu, 10 Sep 2015 12:34:00 -0700 (PDT) Received: by 10.103.0.3 with HTTP; Thu, 10 Sep 2015 12:34:00 -0700 (PDT) X-Originating-IP: [162.208.80.4] In-Reply-To: <55F03348.3090604@mti-systems.com> References: <55CB494A.9020706@mti-systems.com> <55F03348.3090604@mti-systems.com> Date: Thu, 10 Sep 2015 15:34:00 -0400 Message-ID: From: Ida Leung To: Wesley Eddy Content-Type: multipart/alternative; boundary=001a11429d3851ec92051f69aef8 Archived-At: Cc: "gclark mti-systems.com" , Christopher Morrow , "dots@ietf.org" , Justin Dailey Subject: Re: [Dots] use of SDN for DDoS mitigation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2015 19:34:03 -0000 --001a11429d3851ec92051f69aef8 Content-Type: text/plain; charset=UTF-8 Wes, Just one comment about delegate the control of filters to customer. Routers today have limitation of how many flowspec routes they can handle (which is not very big number). Should there be something in the proposed draft feedback session can do to make sure not crash to the limit? I never do any scale test in my lab and I don't know what happen if the limit of flowspec routes exceed. But that is my biggest worryto delegate the control besides customer make mistakes on the filter. ...Ida On Wed, Sep 9, 2015 at 9:25 AM, Wesley Eddy wrote: > On 9/4/2015 5:10 PM, Christopher Morrow wrote: > > On Wed, Aug 12, 2015 at 9:25 AM, Wesley Eddy > wrote: > >> This is not strictly within the scope of the DOTS charter, but > >> because it's related to DDoS mitigation, we thought it might > >> be of interest to the DOTS list. > >> > >> This draft was posted to the SDNRG, and discusses use of OpenFlow > >> interdomain, for delegating control of ISP network filtering to > >> customers: > > > > Folk might consider looking at the prior-art in this arena... > > specifically N-Layer's use of flow-spec from customers, and the fairly > > well published failure modes of same. > > > Hi Christopher, thanks for your comments. We are also doing some > research on improvements to the BGP flowspec capability that you might > be interested in: > https://tools.ietf.org/html/draft-eddy-idr-flowspec-exp-00 > > This doesn't directly answer to the implementation problems referenced > above, but those seem like software issues more than protocol failings. > > > > 'Let your customer traffic engineer your network!' (no, don't do that) > > 'Let your customer consume valuable resources on devices in your > > network to which they have no ideas about limits of' (no, don't do > > that) > > > On this, we fully agree, and in fact our approach is to keep the ISPs > in full control of their own networks, and to only allow customers to > control a limited amount of flow table resources, for filtering only, > and those are sandwiched between ingress and egress flow table chains > that the ISP retains full control of (and are not made visible to the > customers). > > Any comments you have on that approach would be really interesting to > us. We think it might meet your requirement of keeping the customer > from trying to engineer the provider's network or chew up resources. > If this isn't of interest to the rest of DOTS, the chairs can kick us > off-list, and we won't be offended. > > -- > Wes Eddy > MTI Systems > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > --001a11429d3851ec92051f69aef8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Wes,

Just one comment about delegate th= e control of filters to customer.=C2=A0 Routers today have limitation of ho= w many flowspec routes they can handle (which is not very big number). =C2= =A0 Should there be something in the proposed draft feedback session can do= to make sure not crash to the limit?=C2=A0 I never do any scale test in my= lab and I don't know what happen if the limit of flowspec routes excee= d.=C2=A0 But that is my biggest worryto delegate the control besides custom= er make =C2=A0mistakes on the filter.

...Ida
=

On Wed, Sep 9, 20= 15 at 9:25 AM, Wesley Eddy <wes@mti-systems.com> wrote:
On 9/4/2015 5:10 PM, Chris= topher Morrow wrote:
> On Wed, Aug 12, 2015 at 9:25 AM, Wesley Eddy <wes@mti-systems.com> wrote:
>> This is not strictly within the scope of the DOTS charter, but
>> because it's related to DDoS mitigation, we thought it might >> be of interest to the DOTS list.
>>
>> This draft was posted to the SDNRG, and discusses use of OpenFlow<= br> >> interdomain, for delegating control of ISP network filtering to >> customers:
>
> Folk might consider looking at the prior-art in this arena...
> specifically N-Layer's use of flow-spec from customers, and the fa= irly
> well published failure modes of same.


Hi Christopher, thanks for your comments.=C2=A0 We are also doing so= me
research on improvements to the BGP flowspec capability that you might
be interested in:
https://tools.ietf.org/html/draft-eddy-id= r-flowspec-exp-00

This doesn't directly answer to the implementation problems referenced<= br> above, but those seem like software issues more than protocol failings.


> 'Let your customer traffic engineer your network!' (no, don= 9;t do that)
> 'Let your customer consume valuable resources on devices in your > network to which they have no ideas about limits of' (no, don'= t do
> that)


On this, we fully agree, and in fact our approach is to keep the ISP= s
in full control of their own networks, and to only allow customers to
control a limited amount of flow table resources, for filtering only,
and those are sandwiched between ingress and egress flow table chains
that the ISP retains full control of (and are not made visible to the
customers).

Any comments you have on that approach would be really interesting to
us.=C2=A0 We think it might meet your requirement of keeping the customer from trying to engineer the provider's network or chew up resources. If this isn't of interest to the rest of DOTS, the chairs can kick us off-list, and we won't be offended.

--
Wes Eddy
MTI Systems

_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots

--001a11429d3851ec92051f69aef8-- From nobody Thu Sep 10 12:38:24 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34ABE1A87A0 for ; Thu, 10 Sep 2015 12:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham 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 SUUEfbtpXFpb for ; Thu, 10 Sep 2015 12:38:22 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07CAD1B2B32 for ; Thu, 10 Sep 2015 12:38:22 -0700 (PDT) Received: by padhy16 with SMTP id hy16so51418911pad.1 for ; Thu, 10 Sep 2015 12:38:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-type; bh=ZKZdmTDr13DOFAbh8HVYvDDZlrz9FwlLK5PofqA/phA=; b=Fs7Aix0HcXyqfxq4ju8WzwQhXms0ZAHIZZJPZOyiXi9cGI7CfdRze6WjBRrCMCracx BwoiWEid5I6ketllFHrnk3kOaMHrGCt1nUbnabAr7BiUwwVAgv3I7FAkjj2fvy9ZeSWu cCHPPOLbKjqB7Sbl/E6Qkv1+KPFBdUfgWQ4Yk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-type; bh=ZKZdmTDr13DOFAbh8HVYvDDZlrz9FwlLK5PofqA/phA=; b=VaYZGMKKGcUznC2Ves6OiDxhPSUMD6l7YqdOJnl3/jRT8EhwvhnWzQWjoDFK1Yj66v +1/0oB2GxlTuA6e76XZ5kmHZgNVWOoskFqZU3C6MNnwvpz50nWTeb/eV/X9lqAFnEtWy pFjHx3KJERw1N4oD9IVLLXY0Y89t+x30y0BIzWNd8X+2jQpvxJ90PnDnDnMpskQTfJyR WsRj3QNnpnccnDquBoT3HJCDlvByvBN96ixdtnFvEWYLd2utukC/A7m5mIealA8HA1fe AV3rMNszURMvAsd/4Sm+b2+G+JTvzXRGAfHcAIZ6ccmvVwvayGkSOWcQf5Ws8Vch/1Ni 6sWw== X-Gm-Message-State: ALoCoQmzrbtc74gaze7Cr+oJJMLoekAhmVZ90kNnoXgC/+ivLnQ1jMjmseuz1gYfRQQNrexsg/im X-Received: by 10.68.69.40 with SMTP id b8mr74196361pbu.84.1441913901533; Thu, 10 Sep 2015 12:38:21 -0700 (PDT) Received: from [172.19.254.107] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id ku8sm8827569pab.0.2015.09.10.12.38.20 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 10 Sep 2015 12:38:21 -0700 (PDT) From: "Roland Dobbins" To: dots Date: Fri, 11 Sep 2015 02:38:17 +0700 Message-ID: <31C5F6F7-59DF-4A69-BFAC-17D9680C5B56@arbor.net> In-Reply-To: References: <55CB494A.9020706@mti-systems.com> <55F03348.3090604@mti-systems.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Subject: Re: [Dots] use of SDN for DDoS mitigation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2015 19:38:23 -0000 On 11 Sep 2015, at 2:34, Ida Leung wrote: > Should there be something in the proposed draft feedback session can > do to make sure not crash to the limit? DOTS doesn't involve sending flowspec routes directly to network infrastructure. Resource management is a function of the mitigation infrastructure and systems of the mitigating organization, it's entirely abstracted from whatever actual mitigation steps/mechanisms are employed by the mitigating organization (though we should support optional generic requested-action verb primitives, it's up to the mitigating organization's infrastructure/systems as to whether/how to honor them). This is all beyond the scope for DOTS; it will be mentioned in the use-cases draft as a consideration for mitigating organizations. ----------------------------------- Roland Dobbins From nobody Thu Sep 10 12:49:06 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0E451B5B7E for ; Thu, 10 Sep 2015 12:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.312 X-Spam-Level: X-Spam-Status: No, score=-1.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=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 j3hDP68yip0t for ; Thu, 10 Sep 2015 12:49:02 -0700 (PDT) Received: from mail-vk0-f48.google.com (mail-vk0-f48.google.com [209.85.213.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2431A1B5B48 for ; Thu, 10 Sep 2015 12:49:02 -0700 (PDT) Received: by vkgd64 with SMTP id d64so15552780vkg.0 for ; Thu, 10 Sep 2015 12:49:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=RRnofCL+hdAsmw3xVOCQsCFHPY5bQoq/1w1xbKHDYS4=; b=BxzU7z1UbUUTiuTwrjU6mykEur4lHaRLQzIvmNHthYBf6awgBoXM5Y7H4FVFpAH2O6 Dm+h+H5rwP7W0b94KkYQJ1PM7kzSOGxeJrJDgDl9TFJZt4HSFtqBFs55XdBToTYopahp veqkceITQIdViIq9pDUxJtigdIHL+MR2BBnbrXFE1++yrLn/OYHtmY3VJWrY18hYZ73/ xN47KiTLKyfJmcVijESN/8I75A3sAHIWf8LRQCDRmfj7voHPRzHHdwIsHxNDbOM2PhEI ZUs2Y6cXSz0h+jbSZLOHwthHWf8QiPtJ0sALv/QRj63QgZXZxnN5QpC2THa+dtmOXYJL VgDw== X-Gm-Message-State: ALoCoQliOBSg/SuRppOR0sYwQIssEpcHbo4bNZjhMDwIsj8diHHAB/fqz1T5iq1Xg4VbHCAxKK7m MIME-Version: 1.0 X-Received: by 10.31.178.138 with SMTP id b132mr1768313vkf.98.1441914541139; Thu, 10 Sep 2015 12:49:01 -0700 (PDT) Received: by 10.103.0.3 with HTTP; Thu, 10 Sep 2015 12:49:01 -0700 (PDT) X-Originating-IP: [162.208.80.4] In-Reply-To: <31C5F6F7-59DF-4A69-BFAC-17D9680C5B56@arbor.net> References: <55CB494A.9020706@mti-systems.com> <55F03348.3090604@mti-systems.com> <31C5F6F7-59DF-4A69-BFAC-17D9680C5B56@arbor.net> Date: Thu, 10 Sep 2015 15:49:01 -0400 Message-ID: From: Ida Leung To: Roland Dobbins Content-Type: multipart/alternative; boundary=001a114383c805874c051f69e402 Archived-At: Cc: dots Subject: Re: [Dots] use of SDN for DDoS mitigation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2015 19:49:04 -0000 --001a114383c805874c051f69e402 Content-Type: text/plain; charset=UTF-8 Ops. should just reply to Wes for the comment of the flowspec draft. Not this DOTS mailing list. On Thu, Sep 10, 2015 at 3:38 PM, Roland Dobbins wrote: > On 11 Sep 2015, at 2:34, Ida Leung wrote: > > Should there be something in the proposed draft feedback session can do to >> make sure not crash to the limit? >> > > DOTS doesn't involve sending flowspec routes directly to network > infrastructure. > > Resource management is a function of the mitigation infrastructure and > systems of the mitigating organization, it's entirely abstracted from > whatever actual mitigation steps/mechanisms are employed by the mitigating > organization (though we should support optional generic requested-action > verb primitives, it's up to the mitigating organization's > infrastructure/systems as to whether/how to honor them). > > This is all beyond the scope for DOTS; it will be mentioned in the > use-cases draft as a consideration for mitigating organizations. > > ----------------------------------- > Roland Dobbins > > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > --001a114383c805874c051f69e402 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ops. should just reply to Wes for the comment of the flows= pec draft.=C2=A0 Not this DOTS mailing list.

On Thu, Sep 10, 2015 at 3:38 PM, Roland Do= bbins <rdobbins@arbor.net> wrote:
On 11 Sep 2015, at 2:34, Ida Leung wrote:

Should there be something in the proposed draft feedback session can do to = make sure not crash to the limit?

 DOTS doesn't involve sending flowspec routes directly to network infras= tructure.

Resource management is a function of the mitigation infrastructure and syst= ems of the mitigating organization, it's entirely abstracted from whate= ver actual mitigation steps/mechanisms are employed by the mitigating organ= ization (though we should support optional generic requested-action verb pr= imitives, it's up to the mitigating organization's infrastructure/s= ystems as to whether/how to honor them).

This is all beyond the scope for DOTS; it will be mentioned in the use-case= s draft as a consideration for mitigating organizations.

-----------------------------------
Roland Dobbins <= rdobbins@arbor.net>


_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots

--001a114383c805874c051f69e402-- From nobody Mon Sep 21 13:35:55 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2E4F1A6F64 for ; Mon, 21 Sep 2015 13:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 HPAzmlKn_8wC for ; Mon, 21 Sep 2015 13:35:51 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 43F4D1A6F59 for ; Mon, 21 Sep 2015 13:35:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 8F95C6029B; Mon, 21 Sep 2015 16:35:49 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id GGW5QIJGe3Nv; Mon, 21 Sep 2015 16:35:44 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.20]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 2C4A160186; Mon, 21 Sep 2015 16:35:44 -0400 (EDT) To: Roland Dobbins , dots References: <359EC4B99E040048A7131E0F4E113AFCD94F1C56@marathon> <55D01F5E.4070009@gondrom.org> <55DDA4A9.3050603@inria.fr> <8775DC11-7FE3-4A02-89EE-E6BDAC6A1C13@arbor.net> <55DF1EB7.9000703@cisco.com> <4A95BA014132FF49AE685FAB4B9F17F657D22093@dfweml701-chm> <009d01d0eadb$c0c24940$4246dbc0$@jpshallow.com> <01811E7E-E18D-4C9F-A5A5-C5BA3226DDDE@arbor.net> <737719725.3158.1441804137966.JavaMail.vpopmail@atl4oxapp107.mgt.hosting.qts.netsol.com> <0B878DC6-7210-4C3D-9283-395580C90679@arbor.net> From: Robert Moskowitz Message-ID: <56006A12.3010101@htt-consult.com> Date: Mon, 21 Sep 2015 16:35:30 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <0B878DC6-7210-4C3D-9283-395580C90679@arbor.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dots] minimum information to exchange to upstream DDoS (was RE: DOTS: next steps - call for editor volunteers for use case draft and requirements draft X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2015 20:35:54 -0000 On 09/09/2015 09:42 AM, Roland Dobbins wrote: > On 9 Sep 2015, at 20:08, gclark mti-systems.com wrote: > >> I think earlier in the thread there was also a question of if or how >> detection / >> classification / traceback of the supplicant could be trusted if it >> is present. > > The concern was actually regarding fidelity; DOTS will have auth reds. reds? or reqs? thanks > >> Alternative idea might be to use publish / subscribe for this - customer >> explicitly requests mitigation assistance to provider and the message >> includes a >> subscription endpoint to which the provider can attach to receive more >> information about the attack. provider can optionally choose to >> subscribe to >> indicated endpoint. customer's device then publishes telemetry (over >> something >> that might work better across a bad link ... raptor codes come to >> mind, but >> maybe not) to all subscribed providers, who are able to use that >> information in >> whatever way they see (or don't see) fit. > > This is way too complex and well beyond our remit, IMHO. > > We're working on the signaling protocol, and functions directly > associated therewith. This gets into other areas which may be > interesting, but not part of what we're directly trying to accomplish > with DOTS. > >> * If additional information is included, explicitly note that the >> provider is >> under no obligation to do anything with it (though it can if it wants) > > Concur with this. >> >> Also, it might be interesting to say that, *if* any additional >> information is >> included beyond "help, I'm under attack", there is expected to be a >> minimum set >> of components that are included then (e.g. must specify port >> information or >> something). > > Concur with this, too. > > ----------------------------------- > Roland Dobbins > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > From nobody Mon Sep 21 13:38:17 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 773A81A6F82 for ; Mon, 21 Sep 2015 13:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 homddTTZHBgQ for ; Mon, 21 Sep 2015 13:38:15 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 064601A6F7F for ; Mon, 21 Sep 2015 13:38:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 19985602A2; Mon, 21 Sep 2015 16:38:13 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id nMZwaK3L97lS; Mon, 21 Sep 2015 16:38:06 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.20]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id DE4DA60186; Mon, 21 Sep 2015 16:38:02 -0400 (EDT) To: "gclark mti-systems.com" , dots , Roland Dobbins References: <359EC4B99E040048A7131E0F4E113AFCD94F1C56@marathon> <55D01F5E.4070009@gondrom.org> <55DDA4A9.3050603@inria.fr> <8775DC11-7FE3-4A02-89EE-E6BDAC6A1C13@arbor.net> <55DF1EB7.9000703@cisco.com> <4A95BA014132FF49AE685FAB4B9F17F657D22093@dfweml701-chm> <009d01d0eadb$c0c24940$4246dbc0$@jpshallow.com> <01811E7E-E18D-4C9F-A5A5-C5BA3226DDDE@arbor.net> <737719725.3158.1441804137966.JavaMail.vpopmail@atl4oxapp107.mgt.hosting.qts.netsol.com> <0B878DC6-7210-4C3D-9283-395580C90679@arbor.net> <1919208794.5969.1441808811868.JavaMail.vpopmail@atl4oxapp107.mgt.hosting.qts.netsol.com> From: Robert Moskowitz Message-ID: <56006AA7.9090905@htt-consult.com> Date: Mon, 21 Sep 2015 16:37:59 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <1919208794.5969.1441808811868.JavaMail.vpopmail@atl4oxapp107.mgt.hosting.qts.netsol.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dots] minimum information to exchange to upstream DDoS (was RE: DOTS: next steps - call for editor volunteers for use case draft and requirements draft X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2015 20:38:16 -0000 On 09/09/2015 10:26 AM, gclark mti-systems.com wrote: >>> Alternative idea might be to use publish / subscribe for this - >>> customer >>> explicitly requests mitigation assistance to provider and the message >>> includes a >>> subscription endpoint to which the provider can attach to receive more >>> information about the attack. provider can optionally choose to >>> subscribe to >>> indicated endpoint. customer's device then publishes telemetry (over >>> something >>> that might work better across a bad link ... raptor codes come to >>> mind, but >>> maybe not) to all subscribed providers, who are able to use that >>> information in >>> whatever way they see (or don't see) fit. >> This is way too complex and well beyond our remit, IMHO. >> >> We're working on the signaling protocol, and functions directly >> associated therewith. This gets into other areas which may be >> interesting, but not part of what we're directly trying to accomplish >> with DOTS. >> > I'll buy the way too complex bit. In my head, the actual straw-man there wasn't > intended to be the focus so much as the idea that, in general, it might make > sense to just point the provider to a way to *get* the information it wants / > needs from the customer (should the customer choose to provide it) than it would > to actually provide that information as a part of any DOTS protocol ... that > keeps the initial HELP message sizes to a relative minimum, avoids wasted > telemetry frames destined for the provider if the provider isn't interested, and > is an attempt to avoid protocol bloat (since, in theory, this could lead to less > of a temptation to keep adding new, "useful" fields to a signaling protocol). Isn't that why you have a language to describe how to define fields within the protocol? Not to try to create a complete taxonomy of all possible useful fields? Reminds me of some X. work of old. From nobody Mon Sep 21 13:40:48 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4A031A6F82 for ; Mon, 21 Sep 2015 13:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 2zVm5K98S1IU for ; Mon, 21 Sep 2015 13:40:44 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 01FBF1A6FB1 for ; Mon, 21 Sep 2015 13:40:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 0D7656029B; Mon, 21 Sep 2015 16:40:42 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id q0T9-SoA8Q23; Mon, 21 Sep 2015 16:40:24 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.20]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id E3F7060186; Mon, 21 Sep 2015 16:40:23 -0400 (EDT) To: Ida Leung , Wesley Eddy References: <55CB494A.9020706@mti-systems.com> <55F03348.3090604@mti-systems.com> From: Robert Moskowitz Message-ID: <56006B32.5080404@htt-consult.com> Date: Mon, 21 Sep 2015 16:40:18 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------010105060003060205030207" Archived-At: Cc: Christopher Morrow , "gclark mti-systems.com" , "dots@ietf.org" , Justin Dailey Subject: Re: [Dots] use of SDN for DDoS mitigation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2015 20:40:46 -0000 This is a multi-part message in MIME format. --------------010105060003060205030207 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 09/10/2015 03:34 PM, Ida Leung wrote: > Wes, > > Just one comment about delegate the control of filters to customer. > Routers today have limitation of how many flowspec routes they can > handle (which is not very big number). Should there be something in > the proposed draft feedback session can do to make sure not crash to > the limit? I never do any scale test in my lab and I don't know what > happen if the limit of flowspec routes exceed. But that is my biggest > worryto delegate the control besides customer make mistakes on the > filter. Today's limit is tomorrow recommended minimum. Only where there is some hard limit like how much can be transmitted in a set time does this make sense. The later I see a lot in designing of wireless and industrial control protocols where you count the microseconds and bits. > > ...Ida > > On Wed, Sep 9, 2015 at 9:25 AM, Wesley Eddy > wrote: > > On 9/4/2015 5:10 PM, Christopher Morrow wrote: > > On Wed, Aug 12, 2015 at 9:25 AM, Wesley Eddy > > wrote: > >> This is not strictly within the scope of the DOTS charter, but > >> because it's related to DDoS mitigation, we thought it might > >> be of interest to the DOTS list. > >> > >> This draft was posted to the SDNRG, and discusses use of OpenFlow > >> interdomain, for delegating control of ISP network filtering to > >> customers: > > > > Folk might consider looking at the prior-art in this arena... > > specifically N-Layer's use of flow-spec from customers, and the > fairly > > well published failure modes of same. > > > Hi Christopher, thanks for your comments. We are also doing some > research on improvements to the BGP flowspec capability that you might > be interested in: > https://tools.ietf.org/html/draft-eddy-idr-flowspec-exp-00 > > This doesn't directly answer to the implementation problems referenced > above, but those seem like software issues more than protocol > failings. > > > > 'Let your customer traffic engineer your network!' (no, don't do > that) > > 'Let your customer consume valuable resources on devices in your > > network to which they have no ideas about limits of' (no, don't do > > that) > > > On this, we fully agree, and in fact our approach is to keep the ISPs > in full control of their own networks, and to only allow customers to > control a limited amount of flow table resources, for filtering only, > and those are sandwiched between ingress and egress flow table chains > that the ISP retains full control of (and are not made visible to the > customers). > > Any comments you have on that approach would be really interesting to > us. We think it might meet your requirement of keeping the customer > from trying to engineer the provider's network or chew up resources. > If this isn't of interest to the rest of DOTS, the chairs can kick us > off-list, and we won't be offended. > > -- > Wes Eddy > MTI Systems > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > > > > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots --------------010105060003060205030207 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 09/10/2015 03:34 PM, Ida Leung wrote:
Wes,

Just one comment about delegate the control of filters to customer.  Routers today have limitation of how many flowspec routes they can handle (which is not very big number).   Should there be something in the proposed draft feedback session can do to make sure not crash to the limit?  I never do any scale test in my lab and I don't know what happen if the limit of flowspec routes exceed.  But that is my biggest worryto delegate the control besides customer make  mistakes on the filter.

Today's limit is tomorrow recommended minimum.  Only where there is some hard limit like how much can be transmitted in a set time does this make sense.  The later I see a lot in designing of wireless and industrial control protocols where you count the microseconds and bits.


...Ida

On Wed, Sep 9, 2015 at 9:25 AM, Wesley Eddy <wes@mti-systems.com> wrote:
On 9/4/2015 5:10 PM, Christopher Morrow wrote:
> On Wed, Aug 12, 2015 at 9:25 AM, Wesley Eddy <wes@mti-systems.com> wrote:
>> This is not strictly within the scope of the DOTS charter, but
>> because it's related to DDoS mitigation, we thought it might
>> be of interest to the DOTS list.
>>
>> This draft was posted to the SDNRG, and discusses use of OpenFlow
>> interdomain, for delegating control of ISP network filtering to
>> customers:
>
> Folk might consider looking at the prior-art in this arena...
> specifically N-Layer's use of flow-spec from customers, and the fairly
> well published failure modes of same.


Hi Christopher, thanks for your comments.  We are also doing some
research on improvements to the BGP flowspec capability that you might
be interested in:
https://tools.ietf.org/html/draft-eddy-idr-flowspec-exp-00

This doesn't directly answer to the implementation problems referenced
above, but those seem like software issues more than protocol failings.


> 'Let your customer traffic engineer your network!' (no, don't do that)
> 'Let your customer consume valuable resources on devices in your
> network to which they have no ideas about limits of' (no, don't do
> that)


On this, we fully agree, and in fact our approach is to keep the ISPs
in full control of their own networks, and to only allow customers to
control a limited amount of flow table resources, for filtering only,
and those are sandwiched between ingress and egress flow table chains
that the ISP retains full control of (and are not made visible to the
customers).

Any comments you have on that approach would be really interesting to
us.  We think it might meet your requirement of keeping the customer
from trying to engineer the provider's network or chew up resources.
If this isn't of interest to the rest of DOTS, the chairs can kick us
off-list, and we won't be offended.

--
Wes Eddy
MTI Systems

_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots



_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots

--------------010105060003060205030207-- From nobody Mon Sep 21 17:54:13 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE1BA1AD0A7 for ; Mon, 21 Sep 2015 17:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 2yTSFutQ6y-R for ; Mon, 21 Sep 2015 17:54:09 -0700 (PDT) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A344C1AD072 for ; Mon, 21 Sep 2015 17:54:09 -0700 (PDT) Received: by ykdz138 with SMTP id z138so39596390ykd.2 for ; Mon, 21 Sep 2015 17:54:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=5eVrvyAxulCB6kufitAPuWjoSCzvIK8RmyY5wY+Nz3s=; b=ubCRp50ck7GlJnJDCXrl5y7UL7SYrSeiV73HOFYuqr6xHqGZ+IFI9tWPHiUvd1qQuf hjLRjaJDkmkD+uZD6irNkg1Zapu4gHebDXzrYJfDcdEVt6u7sinKyU0ZeZp5rSwJE7XS MDZ48RYALd7ezZNdwQ14L1BoOkE7vqq/ziW65NpYaAdLMkJbaA6p7/Dhs4yyE1UYiMx0 jOasSpHoktarl7/Kl8zoCXeAha0CVx2b0VA6QpfkkiFPxjF44gliAF5COUTbMWSeWs7p Yg0GLaAT/YGs7YOEJBVXKe6NIAiDPTN1nVZGRP6MLLRt5hJMAwtZE8NLiEYn3XKThkQk MvDg== MIME-Version: 1.0 X-Received: by 10.129.102.10 with SMTP id a10mr17479970ywc.19.1442883248952; Mon, 21 Sep 2015 17:54:08 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.13.202.22 with HTTP; Mon, 21 Sep 2015 17:54:08 -0700 (PDT) In-Reply-To: <56006A12.3010101@htt-consult.com> References: <359EC4B99E040048A7131E0F4E113AFCD94F1C56@marathon> <55D01F5E.4070009@gondrom.org> <55DDA4A9.3050603@inria.fr> <8775DC11-7FE3-4A02-89EE-E6BDAC6A1C13@arbor.net> <55DF1EB7.9000703@cisco.com> <4A95BA014132FF49AE685FAB4B9F17F657D22093@dfweml701-chm> <009d01d0eadb$c0c24940$4246dbc0$@jpshallow.com> <01811E7E-E18D-4C9F-A5A5-C5BA3226DDDE@arbor.net> <737719725.3158.1441804137966.JavaMail.vpopmail@atl4oxapp107.mgt.hosting.qts.netsol.com> <0B878DC6-7210-4C3D-9283-395580C90679@arbor.net> <56006A12.3010101@htt-consult.com> Date: Mon, 21 Sep 2015 20:54:08 -0400 X-Google-Sender-Auth: vWrl3v0wsIXB28Ho95AUXk1ciZw Message-ID: From: Christopher Morrow To: Robert Moskowitz Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Roland Dobbins , dots Subject: Re: [Dots] minimum information to exchange to upstream DDoS (was RE: DOTS: next steps - call for editor volunteers for use case draft and requirements draft X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2015 00:54:11 -0000 On Mon, Sep 21, 2015 at 4:35 PM, Robert Moskowitz wrote: > > > On 09/09/2015 09:42 AM, Roland Dobbins wrote: >> >> On 9 Sep 2015, at 20:08, gclark mti-systems.com wrote: >> >>> I think earlier in the thread there was also a question of if or how >>> detection / >>> classification / traceback of the supplicant could be trusted if it is >>> present. >> >> >> The concern was actually regarding fidelity; DOTS will have auth reds. > > > reds? or reqs? creds, credentials > > thanks > > >> >>> Alternative idea might be to use publish / subscribe for this - customer >>> explicitly requests mitigation assistance to provider and the message >>> includes a >>> subscription endpoint to which the provider can attach to receive more >>> information about the attack. provider can optionally choose to >>> subscribe to >>> indicated endpoint. customer's device then publishes telemetry (over >>> something >>> that might work better across a bad link ... raptor codes come to mind, >>> but >>> maybe not) to all subscribed providers, who are able to use that >>> information in >>> whatever way they see (or don't see) fit. >> >> >> This is way too complex and well beyond our remit, IMHO. >> >> We're working on the signaling protocol, and functions directly associated >> therewith. This gets into other areas which may be interesting, but not >> part of what we're directly trying to accomplish with DOTS. >> >>> * If additional information is included, explicitly note that the >>> provider is >>> under no obligation to do anything with it (though it can if it wants) >> >> >> Concur with this. >>> >>> >>> Also, it might be interesting to say that, *if* any additional >>> information is >>> included beyond "help, I'm under attack", there is expected to be a >>> minimum set >>> of components that are included then (e.g. must specify port information >>> or >>> something). >> >> >> Concur with this, too. >> >> ----------------------------------- >> Roland Dobbins >> >> _______________________________________________ >> Dots mailing list >> Dots@ietf.org >> https://www.ietf.org/mailman/listinfo/dots >> > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Sep 24 05:05:31 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B60B1A90AD for ; Thu, 24 Sep 2015 05:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 bM1N6x07g2yp for ; Thu, 24 Sep 2015 05:05:25 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 7B0D71A90A6 for ; Thu, 24 Sep 2015 05:05:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 42B8A6029B for ; Thu, 24 Sep 2015 08:05:24 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id abq-xFPbckTu for ; Thu, 24 Sep 2015 08:05:14 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.20]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 9FBC25FA40 for ; Thu, 24 Sep 2015 08:05:13 -0400 (EDT) To: dots From: Robert Moskowitz Message-ID: <5603E6F4.5040407@htt-consult.com> Date: Thu, 24 Sep 2015 08:05:08 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Dots] How constrained due to attack congestion X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2015 12:05:30 -0000 One of the requirements for DOTS is to be able to message an attack while the attack is congesting the link. Are we going to put any measure on this or recommend any approach to communicate over a constrained link. As I view where I am coming from on this, I have spent considerable time down in IEEE 802.15 dealing with very constrained and lousy links. A lot of thought goes into what CAN be transmitted and to what degree of effort is made at what level to improve likelihood of success. To this end, do we recommend that the DOTS message about an attack MUST fit wtihin a single datagram? And if so how do we count the bytes? That is figure out the transmission overhead: TCP or UDP and what security envelope? Consider what CORE has done to design CoAP as a binary RESTful protocol to work over a constrained link. Is IPFix thus a good approach? Does anyone have any actual measurements of what size messages CAN get through during an attack? thank you From nobody Thu Sep 24 06:04:27 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB03F1ACE86 for ; Thu, 24 Sep 2015 06:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.012 X-Spam-Level: X-Spam-Status: No, score=-0.012 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Jk-dj746oExc for ; Thu, 24 Sep 2015 06:04:24 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 081001ACE8E for ; Thu, 24 Sep 2015 06:04:22 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=N01332) by mail.jpshallow.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Zf6CC-0005Xa-49 for ietf-supjps-dots@ietf.org; Thu, 24 Sep 2015 14:04:20 +0100 From: "Jon Shallow" To: References: <5603E6F4.5040407@htt-consult.com> In-Reply-To: <5603E6F4.5040407@htt-consult.com> Date: Thu, 24 Sep 2015 14:04:22 +0100 Message-ID: <009901d0f6c9$8821cbc0$98656340$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEX3aJmB5+MNbXjArwA6sfeTna5Lp+90Yww Content-Language: en-gb Archived-At: Subject: Re: [Dots] How constrained due to attack congestion X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2015 13:04:26 -0000 Hi Rob, As I see this, the congested link can be in one of two directions (or possibly both). "Local" is signalling to "Remote" about what is happening. Direction Inbound Congestion. Any protocol that requires an acknowledgement (e.g. TCP) will fail when trying to send an outbound "Help Attack" message. As there is no outbound congestion, the "Help Attack" messages would not be constrained to a minimal size, but, in my opinion, should be able to fit in a standard packet (see Protocols below). Direction Outbound Congestion Any "Help Attack" message will not get through - but as this is Outbound, then the remote end cannot respond, but will be able to detect the lack of any "Heart Beat" messages getting through. The local end will need to put mitigation defences in place to stop the outbound congestion. Direction Both Congestion The Outbound Congestion needs to be fixed locally. Protocols This then leans towards the use of a protocol such as UDP for sending "Help Attack" messages. If this protocol has to have a security wrapper (most would say yes), then any key exchange updates may not successfully take place during this congestion period - thus there would have to be support for being able to use old keys during this congestion period. Whether IPFix is the correct layer 7 protocol is open for debate. Regards Jon -----Original Message----- From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Robert Moskowitz Sent: 24 September 2015 13:05 To: dots Subject: [Dots] How constrained due to attack congestion One of the requirements for DOTS is to be able to message an attack while the attack is congesting the link. Are we going to put any measure on this or recommend any approach to communicate over a constrained link. As I view where I am coming from on this, I have spent considerable time down in IEEE 802.15 dealing with very constrained and lousy links. A lot of thought goes into what CAN be transmitted and to what degree of effort is made at what level to improve likelihood of success. To this end, do we recommend that the DOTS message about an attack MUST fit wtihin a single datagram? And if so how do we count the bytes? That is figure out the transmission overhead: TCP or UDP and what security envelope? Consider what CORE has done to design CoAP as a binary RESTful protocol to work over a constrained link. Is IPFix thus a good approach? Does anyone have any actual measurements of what size messages CAN get through during an attack? thank you _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Thu Sep 24 08:14:44 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94BB31AD363 for ; Thu, 24 Sep 2015 08:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 7R-_xCGc4un6 for ; Thu, 24 Sep 2015 08:14:41 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72C301B29BB for ; Thu, 24 Sep 2015 08:14:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3549; q=dns/txt; s=iport; t=1443107679; x=1444317279; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=sv2X4r7JwaWx6iOMO4L2RA/eMWli4DO9m9zyl1pc9WI=; b=f+4sMg/mEhfYV2HvGGfqzuiM1W3tomY5ms4AcylKcDPGrDXMUctH562r 3BsAmdks6yWDxlk7BhsDe0VkPHE0yoZMKU4uXfQqoIlP3OwJZbLAxV4yc cETmlgyvMzPEcN1ASB2dwxRFcst3y0u+mUKD3sxjX37ayYVegwTcPpyeU Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DyAQAQEgRW/5NdJa1dgyRUaQa9PQENgXAKhXkCgUU4FAEBAQEBAQGBCoQkAQEBAwEBAQE3NBcEAgEIDgMEAQEfCQcnCxQJCAIEARIIiB4IDcwTAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSGc4R9hEJSBoQmBZVnAY0Gmy0BHwEBQoIOH4FUcYhngQUBAQE X-IronPort-AV: E=Sophos;i="5.17,581,1437436800"; d="scan'208";a="190884838" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-4.cisco.com with ESMTP; 24 Sep 2015 15:14:38 +0000 Received: from XCH-RCD-020.cisco.com (xch-rcd-020.cisco.com [173.37.102.30]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t8OFEcUs029114 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 24 Sep 2015 15:14:38 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-RCD-020.cisco.com (173.37.102.30) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 24 Sep 2015 10:14:37 -0500 Received: from xch-rcd-017.cisco.com ([173.37.102.27]) by XCH-RCD-017.cisco.com ([173.37.102.27]) with mapi id 15.00.1104.000; Thu, 24 Sep 2015 10:14:37 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] How constrained due to attack congestion Thread-Index: AQHQ9sFQrMB2/1x1w06CKM52FUfcE55L+V4A///OGNA= Date: Thu, 24 Sep 2015 15:14:37 +0000 Message-ID: <10e4a13c8d0a4cdcb76d38eb4f29aa3d@XCH-RCD-017.cisco.com> References: <5603E6F4.5040407@htt-consult.com> <009901d0f6c9$8821cbc0$98656340$@jpshallow.com> In-Reply-To: <009901d0f6c9$8821cbc0$98656340$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.49.202] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] How constrained due to attack congestion X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2015 15:14:42 -0000 > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow > Sent: Thursday, September 24, 2015 6:34 PM > To: dots@ietf.org > Subject: Re: [Dots] How constrained due to attack congestion >=20 > Hi Rob, >=20 > As I see this, the congested link can be in one of two directions (or pos= sibly > both). "Local" is signalling to "Remote" about what is happening. >=20 > Direction Inbound Congestion. > Any protocol that requires an acknowledgement (e.g. TCP) will fail when > trying to send an outbound "Help Attack" message. As there is no outboun= d > congestion, the "Help Attack" messages would not be constrained to a > minimal size, but, in my opinion, should be able to fit in a standard pac= ket > (see Protocols below). >=20 > Direction Outbound Congestion > Any "Help Attack" message will not get through - but as this is Outbound, > then the remote end cannot respond, but will be able to detect the lack o= f > any "Heart Beat" messages getting through. The local end will need to pu= t > mitigation defences in place to stop the outbound congestion. >=20 > Direction Both Congestion > The Outbound Congestion needs to be fixed locally. >=20 > Protocols > This then leans towards the use of a protocol such as UDP for sending "He= lp > Attack" messages. If this protocol has to have a security wrapper (most > would say yes), then any key exchange updates may not successfully take > place during this congestion period - thus there would have to be support= for > being able to use old keys during this congestion period. TLS session resumption without server-side state RFC5077 can possibly be us= ed, but it still consumes 1 round trip before the "Help attack" message can= be signaled. Another alternative is to go with TLS 1.3 which supports zero= round-trip. -Tiru >=20 > Whether IPFix is the correct layer 7 protocol is open for debate. >=20 > Regards >=20 > Jon >=20 > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Robert Moskowitz > Sent: 24 September 2015 13:05 > To: dots > Subject: [Dots] How constrained due to attack congestion >=20 > One of the requirements for DOTS is to be able to message an attack while > the attack is congesting the link. >=20 > Are we going to put any measure on this or recommend any approach to > communicate over a constrained link. >=20 > As I view where I am coming from on this, I have spent considerable time > down in IEEE 802.15 dealing with very constrained and lousy links. A lot= of > thought goes into what CAN be transmitted and to what degree of effort is > made at what level to improve likelihood of success. >=20 > To this end, do we recommend that the DOTS message about an attack MUST > fit wtihin a single datagram? And if so how do we count the bytes? > That is figure out the transmission overhead: TCP or UDP and what securi= ty > envelope? >=20 > Consider what CORE has done to design CoAP as a binary RESTful protocol t= o > work over a constrained link. Is IPFix thus a good approach? >=20 > Does anyone have any actual measurements of what size messages CAN get > through during an attack? >=20 > thank you >=20 >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Sep 24 11:54:49 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFBE81A8761 for ; Thu, 24 Sep 2015 11:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 7kD_iPWGUXF5 for ; Thu, 24 Sep 2015 11:54:46 -0700 (PDT) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E44A41A872F for ; Thu, 24 Sep 2015 11:54:45 -0700 (PDT) Received: by ykdz138 with SMTP id z138so93330403ykd.2 for ; Thu, 24 Sep 2015 11:54:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=aMHAR1IcFCYIl/k9FqHx+t201sCmHXrHI9MqVGbHVSs=; b=CAvYdp2k5xnIAMXkHcaaM7D0uVsB9d+Z97HfZM7CJQgkjksLmDGIc7zSrp/GozBTVJ 24NSPImL+cdel2eg/NTDn0LD6bo7oawxG4kPPSBicbMlEjkP7iwXif68wiMYHFlRIqTE W+9emU7c1uhklS8cjA9dwfvSt0pxRecRIwNruQseX2S0CRtLrKtnn6H85wNVW9TAp7qW HxFOcjtbX/8N1vJ/CBIm7XyV1sWG8K65QXlC5zL+3Nvm53+dRjVb5KBVKz9ipuwnQ923 HFX0LHYa23pwj9nS2F0yD3TTLtgmN08h4U91OGnHVezXtW+LC3UYKAHilPDd0Xl4y/OA EPrQ== MIME-Version: 1.0 X-Received: by 10.129.4.132 with SMTP id 126mr1207285ywe.138.1443120885210; Thu, 24 Sep 2015 11:54:45 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.13.202.22 with HTTP; Thu, 24 Sep 2015 11:54:45 -0700 (PDT) In-Reply-To: <10e4a13c8d0a4cdcb76d38eb4f29aa3d@XCH-RCD-017.cisco.com> References: <5603E6F4.5040407@htt-consult.com> <009901d0f6c9$8821cbc0$98656340$@jpshallow.com> <10e4a13c8d0a4cdcb76d38eb4f29aa3d@XCH-RCD-017.cisco.com> Date: Thu, 24 Sep 2015 14:54:45 -0400 X-Google-Sender-Auth: AgtyH1az7ij7iOGZbtVI-CnK568 Message-ID: From: Christopher Morrow To: "Tirumaleswar Reddy (tireddy)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Jon Shallow , "dots@ietf.org" Subject: Re: [Dots] How constrained due to attack congestion X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2015 18:54:48 -0000 this all sounds like 'bikeshedding' at this point... we don't yet (I think) have 'what will be communicated' between the endpoints in question. Once we agree on that, perhaps we can decide how to pack 10lbs into the 5lb bag. The vast majority of 'oh crap, I'm under attack' problems are 'my inbound link is full, holy crap!', so outbound traffic ought to 'just work', presuming you don't require timely replies... anyway, it seems like we jumped ahead of ourselves, it's good to keep in mind for later though. On Thu, Sep 24, 2015 at 11:14 AM, Tirumaleswar Reddy (tireddy) wrote: >> -----Original Message----- >> From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow >> Sent: Thursday, September 24, 2015 6:34 PM >> To: dots@ietf.org >> Subject: Re: [Dots] How constrained due to attack congestion >> >> Hi Rob, >> >> As I see this, the congested link can be in one of two directions (or possibly >> both). "Local" is signalling to "Remote" about what is happening. >> >> Direction Inbound Congestion. >> Any protocol that requires an acknowledgement (e.g. TCP) will fail when >> trying to send an outbound "Help Attack" message. As there is no outbound >> congestion, the "Help Attack" messages would not be constrained to a >> minimal size, but, in my opinion, should be able to fit in a standard packet >> (see Protocols below). >> >> Direction Outbound Congestion >> Any "Help Attack" message will not get through - but as this is Outbound, >> then the remote end cannot respond, but will be able to detect the lack of >> any "Heart Beat" messages getting through. The local end will need to put >> mitigation defences in place to stop the outbound congestion. >> >> Direction Both Congestion >> The Outbound Congestion needs to be fixed locally. >> >> Protocols >> This then leans towards the use of a protocol such as UDP for sending "Help >> Attack" messages. If this protocol has to have a security wrapper (most >> would say yes), then any key exchange updates may not successfully take >> place during this congestion period - thus there would have to be support for >> being able to use old keys during this congestion period. > > TLS session resumption without server-side state RFC5077 can possibly be used, but it still consumes 1 round trip before the "Help attack" message can be signaled. Another alternative is to go with TLS 1.3 which supports zero round-trip. > > -Tiru > >> >> Whether IPFix is the correct layer 7 protocol is open for debate. >> >> Regards >> >> Jon >> >> -----Original Message----- >> From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Robert Moskowitz >> Sent: 24 September 2015 13:05 >> To: dots >> Subject: [Dots] How constrained due to attack congestion >> >> One of the requirements for DOTS is to be able to message an attack while >> the attack is congesting the link. >> >> Are we going to put any measure on this or recommend any approach to >> communicate over a constrained link. >> >> As I view where I am coming from on this, I have spent considerable time >> down in IEEE 802.15 dealing with very constrained and lousy links. A lot of >> thought goes into what CAN be transmitted and to what degree of effort is >> made at what level to improve likelihood of success. >> >> To this end, do we recommend that the DOTS message about an attack MUST >> fit wtihin a single datagram? And if so how do we count the bytes? >> That is figure out the transmission overhead: TCP or UDP and what security >> envelope? >> >> Consider what CORE has done to design CoAP as a binary RESTful protocol to >> work over a constrained link. Is IPFix thus a good approach? >> >> Does anyone have any actual measurements of what size messages CAN get >> through during an attack? >> >> thank you >> >> >> _______________________________________________ >> Dots mailing list >> Dots@ietf.org >> https://www.ietf.org/mailman/listinfo/dots >> >> _______________________________________________ >> Dots mailing list >> Dots@ietf.org >> https://www.ietf.org/mailman/listinfo/dots > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Sep 24 12:41:39 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0BAD1A88BA for ; Thu, 24 Sep 2015 12:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 5mzbjdcDvr-m for ; Thu, 24 Sep 2015 12:41:35 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 6C89A1A88A7 for ; Thu, 24 Sep 2015 12:41:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 4EB2D602A2; Thu, 24 Sep 2015 15:41:33 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id yTRwsKBpXmrp; Thu, 24 Sep 2015 15:41:28 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.20]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 179836029B; Thu, 24 Sep 2015 15:41:09 -0400 (EDT) To: Christopher Morrow , "Tirumaleswar Reddy (tireddy)" References: <5603E6F4.5040407@htt-consult.com> <009901d0f6c9$8821cbc0$98656340$@jpshallow.com> <10e4a13c8d0a4cdcb76d38eb4f29aa3d@XCH-RCD-017.cisco.com> From: Robert Moskowitz Message-ID: <560451D3.7080502@htt-consult.com> Date: Thu, 24 Sep 2015 15:41:07 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Jon Shallow , "dots@ietf.org" Subject: Re: [Dots] How constrained due to attack congestion X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2015 19:41:38 -0000 Not quite so if this goes into the requirements document. Of which Tiru, Andy, and I are the joint editors... "The protocol design needs to be cognizant of transmission limitations during an attack and minimize the number of datagrams and return acknowledgments to send to initiate a mitigation action." Is really vague but covers the concern. More meat would be good for the meal... Or "If the controller has not heard a heartbeat (if supported) within a reasonable time, an attack may be underway and mitigation should be initiated." On 09/24/2015 02:54 PM, Christopher Morrow wrote: > this all sounds like 'bikeshedding' at this point... we don't yet (I > think) have 'what will be communicated' between the endpoints in > question. Once we agree on that, perhaps we can decide how to pack > 10lbs into the 5lb bag. > > The vast majority of 'oh crap, I'm under attack' problems are 'my > inbound link is full, holy crap!', so outbound traffic ought to 'just > work', presuming you don't require timely replies... > > anyway, it seems like we jumped ahead of ourselves, it's good to keep > in mind for later though. > > On Thu, Sep 24, 2015 at 11:14 AM, Tirumaleswar Reddy (tireddy) > wrote: >>> -----Original Message----- >>> From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow >>> Sent: Thursday, September 24, 2015 6:34 PM >>> To: dots@ietf.org >>> Subject: Re: [Dots] How constrained due to attack congestion >>> >>> Hi Rob, >>> >>> As I see this, the congested link can be in one of two directions (or possibly >>> both). "Local" is signalling to "Remote" about what is happening. >>> >>> Direction Inbound Congestion. >>> Any protocol that requires an acknowledgement (e.g. TCP) will fail when >>> trying to send an outbound "Help Attack" message. As there is no outbound >>> congestion, the "Help Attack" messages would not be constrained to a >>> minimal size, but, in my opinion, should be able to fit in a standard packet >>> (see Protocols below). >>> >>> Direction Outbound Congestion >>> Any "Help Attack" message will not get through - but as this is Outbound, >>> then the remote end cannot respond, but will be able to detect the lack of >>> any "Heart Beat" messages getting through. The local end will need to put >>> mitigation defences in place to stop the outbound congestion. >>> >>> Direction Both Congestion >>> The Outbound Congestion needs to be fixed locally. >>> >>> Protocols >>> This then leans towards the use of a protocol such as UDP for sending "Help >>> Attack" messages. If this protocol has to have a security wrapper (most >>> would say yes), then any key exchange updates may not successfully take >>> place during this congestion period - thus there would have to be support for >>> being able to use old keys during this congestion period. >> TLS session resumption without server-side state RFC5077 can possibly be used, but it still consumes 1 round trip before the "Help attack" message can be signaled. Another alternative is to go with TLS 1.3 which supports zero round-trip. >> >> -Tiru >> >>> Whether IPFix is the correct layer 7 protocol is open for debate. >>> >>> Regards >>> >>> Jon >>> >>> -----Original Message----- >>> From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Robert Moskowitz >>> Sent: 24 September 2015 13:05 >>> To: dots >>> Subject: [Dots] How constrained due to attack congestion >>> >>> One of the requirements for DOTS is to be able to message an attack while >>> the attack is congesting the link. >>> >>> Are we going to put any measure on this or recommend any approach to >>> communicate over a constrained link. >>> >>> As I view where I am coming from on this, I have spent considerable time >>> down in IEEE 802.15 dealing with very constrained and lousy links. A lot of >>> thought goes into what CAN be transmitted and to what degree of effort is >>> made at what level to improve likelihood of success. >>> >>> To this end, do we recommend that the DOTS message about an attack MUST >>> fit wtihin a single datagram? And if so how do we count the bytes? >>> That is figure out the transmission overhead: TCP or UDP and what security >>> envelope? >>> >>> Consider what CORE has done to design CoAP as a binary RESTful protocol to >>> work over a constrained link. Is IPFix thus a good approach? >>> >>> Does anyone have any actual measurements of what size messages CAN get >>> through during an attack? >>> >>> thank you >>> >>> >>> _______________________________________________ >>> Dots mailing list >>> Dots@ietf.org >>> https://www.ietf.org/mailman/listinfo/dots >>> >>> _______________________________________________ >>> Dots mailing list >>> Dots@ietf.org >>> https://www.ietf.org/mailman/listinfo/dots >> _______________________________________________ >> Dots mailing list >> Dots@ietf.org >> https://www.ietf.org/mailman/listinfo/dots > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > From nobody Thu Sep 24 12:52:14 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A31241ABB1A for ; Thu, 24 Sep 2015 12:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham 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 cmiau4bRgbJl for ; Thu, 24 Sep 2015 12:52:11 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.11]) (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 EC6B81ABC0F for ; Thu, 24 Sep 2015 12:52:04 -0700 (PDT) Received: from [216.82.250.19] by server-11.bemta-12.messagelabs.com id 9E/13-31485-46454065; Thu, 24 Sep 2015 19:52:04 +0000 X-Env-Sender: Stefan.Fouant@corero.com X-Msg-Ref: server-12.tower-87.messagelabs.com!1443124322!42037786!1 X-Originating-IP: [71.184.227.49] X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12008 invoked from network); 24 Sep 2015 19:52:03 -0000 Received: from mercury.corero.com (HELO MERCURY.corero.com) (71.184.227.49) by server-12.tower-87.messagelabs.com with AES128-SHA encrypted SMTP; 24 Sep 2015 19:52:03 -0000 Received: from MERCURY.corero.com ([fe80::2c05:6b26:abe2:ad24]) by MERCURY.corero.com ([fe80::2c05:6b26:abe2:ad24%19]) with mapi id 14.03.0248.002; Thu, 24 Sep 2015 15:52:02 -0400 From: Stefan Fouant To: Robert Moskowitz , Christopher Morrow , "Tirumaleswar Reddy (tireddy)" Thread-Topic: [Dots] How constrained due to attack congestion Thread-Index: AQHQ9sFRB9t5g/y4ekyGeb27kJH2Qp5L6JoAgAAkZYCAAD2BgIAADPSA//+//oA= Date: Thu, 24 Sep 2015 19:52:02 +0000 Message-ID: References: <5603E6F4.5040407@htt-consult.com> <009901d0f6c9$8821cbc0$98656340$@jpshallow.com> <10e4a13c8d0a4cdcb76d38eb4f29aa3d@XCH-RCD-017.cisco.com> <560451D3.7080502@htt-consult.com> In-Reply-To: <560451D3.7080502@htt-consult.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [70.106.201.72] Content-Type: text/plain; charset="us-ascii" Content-ID: <3E585F09A23A324BB7B09415E17AD23F@corero.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Jon Shallow , "dots@ietf.org" Subject: Re: [Dots] How constrained due to attack congestion X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2015 19:52:13 -0000 Is the plan to work on the requirements doc at the same time as the use case? Because I envision the use case doc could cover some of this from a high level. I like the idea of using a connectionless oriented methodology coupled w/ heartbeats but there are caveats to such an approach - we may not want to initiate a mitigation action solely based on loss of such as any number of maintenance activities or other things could potentially trigger a mitigation.=20 Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI, CISSP Senior Security Engineer Corero Network Security Mobile: +1.703.625.6243 =20 Your Solution for Real-Time DDoS Protection On 9/24/15, 3:41 PM, "Dots on behalf of Robert Moskowitz" wrote: >Not quite so if this goes into the requirements document. Of which >Tiru, Andy, and I are the joint editors... > >"The protocol design needs to be cognizant of transmission limitations >during an attack and minimize the number of datagrams and return >acknowledgments to send to initiate a mitigation action." Is really >vague but covers the concern. More meat would be good for the meal... > >Or "If the controller has not heard a heartbeat (if supported) within a >reasonable time, an attack may be underway and mitigation should be >initiated." > > > >On 09/24/2015 02:54 PM, Christopher Morrow wrote: >> this all sounds like 'bikeshedding' at this point... we don't yet (I >> think) have 'what will be communicated' between the endpoints in >> question. Once we agree on that, perhaps we can decide how to pack >> 10lbs into the 5lb bag. >> >> The vast majority of 'oh crap, I'm under attack' problems are 'my >> inbound link is full, holy crap!', so outbound traffic ought to 'just >> work', presuming you don't require timely replies... >> >> anyway, it seems like we jumped ahead of ourselves, it's good to keep >> in mind for later though. >> >> On Thu, Sep 24, 2015 at 11:14 AM, Tirumaleswar Reddy (tireddy) >> wrote: >>>> -----Original Message----- >>>> From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow >>>> Sent: Thursday, September 24, 2015 6:34 PM >>>> To: dots@ietf.org >>>> Subject: Re: [Dots] How constrained due to attack congestion >>>> >>>> Hi Rob, >>>> >>>> As I see this, the congested link can be in one of two directions (or >>>>possibly >>>> both). "Local" is signalling to "Remote" about what is happening. >>>> >>>> Direction Inbound Congestion. >>>> Any protocol that requires an acknowledgement (e.g. TCP) will fail >>>>when >>>> trying to send an outbound "Help Attack" message. As there is no >>>>outbound >>>> congestion, the "Help Attack" messages would not be constrained to a >>>> minimal size, but, in my opinion, should be able to fit in a standard >>>>packet >>>> (see Protocols below). >>>> >>>> Direction Outbound Congestion >>>> Any "Help Attack" message will not get through - but as this is >>>>Outbound, >>>> then the remote end cannot respond, but will be able to detect the >>>>lack of >>>> any "Heart Beat" messages getting through. The local end will need >>>>to put >>>> mitigation defences in place to stop the outbound congestion. >>>> >>>> Direction Both Congestion >>>> The Outbound Congestion needs to be fixed locally. >>>> >>>> Protocols >>>> This then leans towards the use of a protocol such as UDP for sending >>>>"Help >>>> Attack" messages. If this protocol has to have a security wrapper >>>>(most >>>> would say yes), then any key exchange updates may not successfully >>>>take >>>> place during this congestion period - thus there would have to be >>>>support for >>>> being able to use old keys during this congestion period. >>> TLS session resumption without server-side state RFC5077 can possibly >>>be used, but it still consumes 1 round trip before the "Help attack" >>>message can be signaled. Another alternative is to go with TLS 1.3 >>>which supports zero round-trip. >>> >>> -Tiru >>> >>>> Whether IPFix is the correct layer 7 protocol is open for debate. >>>> >>>> Regards >>>> >>>> Jon >>>> >>>> -----Original Message----- >>>> From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Robert >>>>Moskowitz >>>> Sent: 24 September 2015 13:05 >>>> To: dots >>>> Subject: [Dots] How constrained due to attack congestion >>>> >>>> One of the requirements for DOTS is to be able to message an attack >>>>while >>>> the attack is congesting the link. >>>> >>>> Are we going to put any measure on this or recommend any approach to >>>> communicate over a constrained link. >>>> >>>> As I view where I am coming from on this, I have spent considerable >>>>time >>>> down in IEEE 802.15 dealing with very constrained and lousy links. A >>>>lot of >>>> thought goes into what CAN be transmitted and to what degree of >>>>effort is >>>> made at what level to improve likelihood of success. >>>> >>>> To this end, do we recommend that the DOTS message about an attack >>>>MUST >>>> fit wtihin a single datagram? And if so how do we count the bytes? >>>> That is figure out the transmission overhead: TCP or UDP and what >>>>security >>>> envelope? >>>> >>>> Consider what CORE has done to design CoAP as a binary RESTful >>>>protocol to >>>> work over a constrained link. Is IPFix thus a good approach? >>>> >>>> Does anyone have any actual measurements of what size messages CAN get >>>> through during an attack? >>>> >>>> thank you >>>> >>>> >>>> _______________________________________________ >>>> Dots mailing list >>>> Dots@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dots >>>> >>>> _______________________________________________ >>>> Dots mailing list >>>> Dots@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dots >>> _______________________________________________ >>> Dots mailing list >>> Dots@ietf.org >>> https://www.ietf.org/mailman/listinfo/dots >> _______________________________________________ >> Dots mailing list >> Dots@ietf.org >> https://www.ietf.org/mailman/listinfo/dots >> > >_______________________________________________ >Dots mailing list >Dots@ietf.org >https://www.ietf.org/mailman/listinfo/dots From nobody Thu Sep 24 12:54:32 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA321AC3FC for ; Thu, 24 Sep 2015 12:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 s8qI2rg3cHpT for ; Thu, 24 Sep 2015 12:54:28 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 01B001AC3F8 for ; Thu, 24 Sep 2015 12:54:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 82CB56029B; Thu, 24 Sep 2015 15:54:25 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id zRaSXTvMSzPY; Thu, 24 Sep 2015 15:54:15 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.20]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 379F45FA40; Thu, 24 Sep 2015 15:54:15 -0400 (EDT) To: Stefan Fouant , Christopher Morrow , "Tirumaleswar Reddy (tireddy)" References: <5603E6F4.5040407@htt-consult.com> <009901d0f6c9$8821cbc0$98656340$@jpshallow.com> <10e4a13c8d0a4cdcb76d38eb4f29aa3d@XCH-RCD-017.cisco.com> <560451D3.7080502@htt-consult.com> From: Robert Moskowitz Message-ID: <560454E5.1070602@htt-consult.com> Date: Thu, 24 Sep 2015 15:54:13 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Jon Shallow , "dots@ietf.org" Subject: Re: [Dots] How constrained due to attack congestion X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2015 19:54:30 -0000 They are two separate editing teams. Both needing to get a document ready for November. Do the math. Well I am consulting with one of the use case members... On 09/24/2015 03:52 PM, Stefan Fouant wrote: > Is the plan to work on the requirements doc at the same time as the use > case? Because I envision the use case doc could cover some of this from a > high level. > > I like the idea of using a connectionless oriented methodology coupled w/ > heartbeats but there are caveats to such an approach - we may not want to > initiate a mitigation action solely based on loss of such as any number of > maintenance activities or other things could potentially trigger a > mitigation. > > Stefan Fouant > JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI, CISSP > Senior Security Engineer > Corero Network Security > Mobile: +1.703.625.6243 > > Your Solution for Real-Time DDoS Protection > > > > On 9/24/15, 3:41 PM, "Dots on behalf of Robert Moskowitz" > wrote: > >> Not quite so if this goes into the requirements document. Of which >> Tiru, Andy, and I are the joint editors... >> >> "The protocol design needs to be cognizant of transmission limitations >> during an attack and minimize the number of datagrams and return >> acknowledgments to send to initiate a mitigation action." Is really >> vague but covers the concern. More meat would be good for the meal... >> >> Or "If the controller has not heard a heartbeat (if supported) within a >> reasonable time, an attack may be underway and mitigation should be >> initiated." >> >> >> >> On 09/24/2015 02:54 PM, Christopher Morrow wrote: >>> this all sounds like 'bikeshedding' at this point... we don't yet (I >>> think) have 'what will be communicated' between the endpoints in >>> question. Once we agree on that, perhaps we can decide how to pack >>> 10lbs into the 5lb bag. >>> >>> The vast majority of 'oh crap, I'm under attack' problems are 'my >>> inbound link is full, holy crap!', so outbound traffic ought to 'just >>> work', presuming you don't require timely replies... >>> >>> anyway, it seems like we jumped ahead of ourselves, it's good to keep >>> in mind for later though. >>> >>> On Thu, Sep 24, 2015 at 11:14 AM, Tirumaleswar Reddy (tireddy) >>> wrote: >>>>> -----Original Message----- >>>>> From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow >>>>> Sent: Thursday, September 24, 2015 6:34 PM >>>>> To: dots@ietf.org >>>>> Subject: Re: [Dots] How constrained due to attack congestion >>>>> >>>>> Hi Rob, >>>>> >>>>> As I see this, the congested link can be in one of two directions (or >>>>> possibly >>>>> both). "Local" is signalling to "Remote" about what is happening. >>>>> >>>>> Direction Inbound Congestion. >>>>> Any protocol that requires an acknowledgement (e.g. TCP) will fail >>>>> when >>>>> trying to send an outbound "Help Attack" message. As there is no >>>>> outbound >>>>> congestion, the "Help Attack" messages would not be constrained to a >>>>> minimal size, but, in my opinion, should be able to fit in a standard >>>>> packet >>>>> (see Protocols below). >>>>> >>>>> Direction Outbound Congestion >>>>> Any "Help Attack" message will not get through - but as this is >>>>> Outbound, >>>>> then the remote end cannot respond, but will be able to detect the >>>>> lack of >>>>> any "Heart Beat" messages getting through. The local end will need >>>>> to put >>>>> mitigation defences in place to stop the outbound congestion. >>>>> >>>>> Direction Both Congestion >>>>> The Outbound Congestion needs to be fixed locally. >>>>> >>>>> Protocols >>>>> This then leans towards the use of a protocol such as UDP for sending >>>>> "Help >>>>> Attack" messages. If this protocol has to have a security wrapper >>>>> (most >>>>> would say yes), then any key exchange updates may not successfully >>>>> take >>>>> place during this congestion period - thus there would have to be >>>>> support for >>>>> being able to use old keys during this congestion period. >>>> TLS session resumption without server-side state RFC5077 can possibly >>>> be used, but it still consumes 1 round trip before the "Help attack" >>>> message can be signaled. Another alternative is to go with TLS 1.3 >>>> which supports zero round-trip. >>>> >>>> -Tiru >>>> >>>>> Whether IPFix is the correct layer 7 protocol is open for debate. >>>>> >>>>> Regards >>>>> >>>>> Jon >>>>> >>>>> -----Original Message----- >>>>> From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Robert >>>>> Moskowitz >>>>> Sent: 24 September 2015 13:05 >>>>> To: dots >>>>> Subject: [Dots] How constrained due to attack congestion >>>>> >>>>> One of the requirements for DOTS is to be able to message an attack >>>>> while >>>>> the attack is congesting the link. >>>>> >>>>> Are we going to put any measure on this or recommend any approach to >>>>> communicate over a constrained link. >>>>> >>>>> As I view where I am coming from on this, I have spent considerable >>>>> time >>>>> down in IEEE 802.15 dealing with very constrained and lousy links. A >>>>> lot of >>>>> thought goes into what CAN be transmitted and to what degree of >>>>> effort is >>>>> made at what level to improve likelihood of success. >>>>> >>>>> To this end, do we recommend that the DOTS message about an attack >>>>> MUST >>>>> fit wtihin a single datagram? And if so how do we count the bytes? >>>>> That is figure out the transmission overhead: TCP or UDP and what >>>>> security >>>>> envelope? >>>>> >>>>> Consider what CORE has done to design CoAP as a binary RESTful >>>>> protocol to >>>>> work over a constrained link. Is IPFix thus a good approach? >>>>> >>>>> Does anyone have any actual measurements of what size messages CAN get >>>>> through during an attack? >>>>> >>>>> thank you >>>>> >>>>> >>>>> _______________________________________________ >>>>> Dots mailing list >>>>> Dots@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dots >>>>> >>>>> _______________________________________________ >>>>> Dots mailing list >>>>> Dots@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dots >>>> _______________________________________________ >>>> Dots mailing list >>>> Dots@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dots >>> _______________________________________________ >>> Dots mailing list >>> Dots@ietf.org >>> https://www.ietf.org/mailman/listinfo/dots >>> >> _______________________________________________ >> Dots mailing list >> Dots@ietf.org >> https://www.ietf.org/mailman/listinfo/dots > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > From nobody Thu Sep 24 13:00:45 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C58D81AC39A for ; Thu, 24 Sep 2015 13:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 VPaEwBIaQXcF for ; Thu, 24 Sep 2015 13:00:42 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 8A91C1AC3D6 for ; Thu, 24 Sep 2015 13:00:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 996396029B; Thu, 24 Sep 2015 16:00:39 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id DEf11+p5TBJM; Thu, 24 Sep 2015 16:00:33 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.20]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 5AA7F5FA40; Thu, 24 Sep 2015 16:00:30 -0400 (EDT) To: Christopher Morrow , "Tirumaleswar Reddy (tireddy)" References: <5603E6F4.5040407@htt-consult.com> <009901d0f6c9$8821cbc0$98656340$@jpshallow.com> <10e4a13c8d0a4cdcb76d38eb4f29aa3d@XCH-RCD-017.cisco.com> From: Robert Moskowitz Message-ID: <5604565C.1060203@htt-consult.com> Date: Thu, 24 Sep 2015 16:00:28 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Jon Shallow , "dots@ietf.org" Subject: Re: [Dots] How constrained due to attack congestion X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2015 20:00:44 -0000 On 09/24/2015 02:54 PM, Christopher Morrow wrote: > this all sounds like 'bikeshedding' at this point... we don't yet (I > think) have 'what will be communicated' between the endpoints in > question. Once we agree on that, perhaps we can decide how to pack > 10lbs into the 5lb bag. With regard to 5lb in 10lb bags. We do that a lot in IoT networking. You should see the IEEE 11073 data model. Or maybe it is better if you did not. Afterall, it is in many of those wonderful new wireless medical devices coming to market. But my point is this road is well worn by others and there is much to take away from what they have done. Particularly in industrial control where timing is everything even when the network is lousy. Then you get to wireless building security controls and how they handle RF DOS attacks (or don't as the case may be). > The vast majority of 'oh crap, I'm under attack' problems are 'my > inbound link is full, holy crap!', so outbound traffic ought to 'just > work', presuming you don't require timely replies... > > anyway, it seems like we jumped ahead of ourselves, it's good to keep > in mind for later though. > > On Thu, Sep 24, 2015 at 11:14 AM, Tirumaleswar Reddy (tireddy) > wrote: >>> -----Original Message----- >>> From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow >>> Sent: Thursday, September 24, 2015 6:34 PM >>> To: dots@ietf.org >>> Subject: Re: [Dots] How constrained due to attack congestion >>> >>> Hi Rob, >>> >>> As I see this, the congested link can be in one of two directions (or possibly >>> both). "Local" is signalling to "Remote" about what is happening. >>> >>> Direction Inbound Congestion. >>> Any protocol that requires an acknowledgement (e.g. TCP) will fail when >>> trying to send an outbound "Help Attack" message. As there is no outbound >>> congestion, the "Help Attack" messages would not be constrained to a >>> minimal size, but, in my opinion, should be able to fit in a standard packet >>> (see Protocols below). >>> >>> Direction Outbound Congestion >>> Any "Help Attack" message will not get through - but as this is Outbound, >>> then the remote end cannot respond, but will be able to detect the lack of >>> any "Heart Beat" messages getting through. The local end will need to put >>> mitigation defences in place to stop the outbound congestion. >>> >>> Direction Both Congestion >>> The Outbound Congestion needs to be fixed locally. >>> >>> Protocols >>> This then leans towards the use of a protocol such as UDP for sending "Help >>> Attack" messages. If this protocol has to have a security wrapper (most >>> would say yes), then any key exchange updates may not successfully take >>> place during this congestion period - thus there would have to be support for >>> being able to use old keys during this congestion period. >> TLS session resumption without server-side state RFC5077 can possibly be used, but it still consumes 1 round trip before the "Help attack" message can be signaled. Another alternative is to go with TLS 1.3 which supports zero round-trip. >> >> -Tiru >> >>> Whether IPFix is the correct layer 7 protocol is open for debate. >>> >>> Regards >>> >>> Jon >>> >>> -----Original Message----- >>> From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Robert Moskowitz >>> Sent: 24 September 2015 13:05 >>> To: dots >>> Subject: [Dots] How constrained due to attack congestion >>> >>> One of the requirements for DOTS is to be able to message an attack while >>> the attack is congesting the link. >>> >>> Are we going to put any measure on this or recommend any approach to >>> communicate over a constrained link. >>> >>> As I view where I am coming from on this, I have spent considerable time >>> down in IEEE 802.15 dealing with very constrained and lousy links. A lot of >>> thought goes into what CAN be transmitted and to what degree of effort is >>> made at what level to improve likelihood of success. >>> >>> To this end, do we recommend that the DOTS message about an attack MUST >>> fit wtihin a single datagram? And if so how do we count the bytes? >>> That is figure out the transmission overhead: TCP or UDP and what security >>> envelope? >>> >>> Consider what CORE has done to design CoAP as a binary RESTful protocol to >>> work over a constrained link. Is IPFix thus a good approach? >>> >>> Does anyone have any actual measurements of what size messages CAN get >>> through during an attack? >>> >>> thank you >>> >>> >>> _______________________________________________ >>> Dots mailing list >>> Dots@ietf.org >>> https://www.ietf.org/mailman/listinfo/dots >>> >>> _______________________________________________ >>> Dots mailing list >>> Dots@ietf.org >>> https://www.ietf.org/mailman/listinfo/dots >> _______________________________________________ >> Dots mailing list >> Dots@ietf.org >> https://www.ietf.org/mailman/listinfo/dots > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > From nobody Thu Sep 24 13:00:59 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A0BC1AC3A1 for ; Thu, 24 Sep 2015 13:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 VLHDA7x_n7q7 for ; Thu, 24 Sep 2015 13:00:51 -0700 (PDT) Received: from mail-oi0-f98.google.com (mail-oi0-f98.google.com [209.85.218.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A46A21AC407 for ; Thu, 24 Sep 2015 13:00:51 -0700 (PDT) Received: by oibi136 with SMTP id i136so5210316oib.3 for ; Thu, 24 Sep 2015 13:00:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:user-agent:content-type:content-id :content-transfer-encoding:mime-version; bh=0cWJtSheIbwC/iirWMSOZ7dM1xtqGVGuiKHzhoqW4NU=; b=R+I514uyvl8UXWRcVeKgVnyqw+YD0xkFJ0qpF8WsypAMRR8qqDog1JH9VsLUn1RxEP SvVK/NYyb+yVeWkjED3dXFdFeutvMqqPO6DiN/pHH9ZK4A5+7yOdxkn5QrchwmFCZsMb dk+dHkGai+MoOBbsjxU9bUVNZO9UsIGvup40nqox7k2Glopt9GSmP/uvJLauJxSbTuR7 bLSJaiDr91+xa3fxr1pTbzOCXzgBGsw642qwvcSyNqbUOwAzuCoy82zmYaTvIKPxHhZQ n9TEoj8ZO782KKuMOU5YqMSAwYNuF+waxcetkkAIhUFF7V299wXLwgwRjDBNg9imSRWX ygkw== X-Gm-Message-State: ALoCoQkh4lF75ehq27IhUkEq9DpACE3Z2MOU0ZX+03K15K/EtA0LpJJzRWGb8JBY1A0VMf61tmuFnGey37Z/icYPOGjrOHCMAA== X-Received: by 10.140.102.206 with SMTP id w72mr1787294qge.93.1443124850961; Thu, 24 Sep 2015 13:00:50 -0700 (PDT) Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by smtp-relay.gmail.com with ESMTPS id q3sm1270412qki.11.2015.09.24.13.00.50 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 24 Sep 2015 13:00:50 -0700 (PDT) X-Relaying-Domain: verisign.com Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01 [10.173.152.205]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id t8OK0nTI001537 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Sep 2015 16:00:49 -0400 Received: from BRN1WNEXMBX02.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Thu, 24 Sep 2015 16:00:49 -0400 From: "Teague, Nik" To: Stefan Fouant , Robert Moskowitz , Christopher Morrow , "Tirumaleswar Reddy (tireddy)" Thread-Topic: [Dots] How constrained due to attack congestion Thread-Index: AQHQ9sFRq3pPp6SNCkm1bHsV37fwLJ5L6JoAgAAkZYCAAD2BgIAADPSAgAADDQD//79kgA== Date: Thu, 24 Sep 2015 20:00:49 +0000 Message-ID: References: <5603E6F4.5040407@htt-consult.com> <009901d0f6c9$8821cbc0$98656340$@jpshallow.com> <10e4a13c8d0a4cdcb76d38eb4f29aa3d@XCH-RCD-017.cisco.com> <560451D3.7080502@htt-consult.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.5.150821 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="utf-8" Content-ID: <40BB6DF197C9D4469A94B56D7E34C568@verisign.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Jon Shallow , "dots@ietf.org" Subject: Re: [Dots] How constrained due to attack congestion X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2015 20:00:56 -0000 SGksDQoNCk9uIDI0LzA5LzIwMTUgMTU6NTIsICJEb3RzIG9uIGJlaGFsZiBvZiBTdGVmYW4gRm91 YW50Ig0KPGRvdHMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgU3RlZmFuLkZvdWFudEBj b3Jlcm8uY29tPiB3cm90ZToNCg0KPklzIHRoZSBwbGFuIHRvIHdvcmsgb24gdGhlIHJlcXVpcmVt ZW50cyBkb2MgYXQgdGhlIHNhbWUgdGltZSBhcyB0aGUgdXNlDQo+Y2FzZT8gQmVjYXVzZSBJIGVu dmlzaW9uIHRoZSB1c2UgY2FzZSBkb2MgY291bGQgY292ZXIgc29tZSBvZiB0aGlzIGZyb20gYQ0K PmhpZ2ggbGV2ZWwuDQoNCkhpIHRoZSB1c2UgY2FzZSBhbmQgcmVxdWlyZW1lbnRzIHNob3VsZCBj b21wbGltZW50IGVhY2ggb3RoZXIuDQoNCj4NCj5JIGxpa2UgdGhlIGlkZWEgb2YgdXNpbmcgYSBj b25uZWN0aW9ubGVzcyBvcmllbnRlZCBtZXRob2RvbG9neSBjb3VwbGVkIHcvDQo+aGVhcnRiZWF0 cyBidXQgdGhlcmUgYXJlIGNhdmVhdHMgdG8gc3VjaCBhbiBhcHByb2FjaCAtIHdlIG1heSBub3Qg d2FudCB0bw0KPmluaXRpYXRlIGEgbWl0aWdhdGlvbiBhY3Rpb24gc29sZWx5IGJhc2VkIG9uIGxv c3Mgb2Ygc3VjaCBhcyBhbnkgbnVtYmVyIG9mDQo+bWFpbnRlbmFuY2UgYWN0aXZpdGllcyBvciBv dGhlciB0aGluZ3MgY291bGQgcG90ZW50aWFsbHkgdHJpZ2dlciBhDQo+bWl0aWdhdGlvbi4NCg0K QSBoZWFydGJlYXQgc2hvdWxkbuKAmXQgYmUgZW5vdWdoIHRvIHRyaWdnZXIgYW4gYXV0b21pdGln YXRpb24gaW4gbXkgbWluZA0KYnV0IHNob3VsZCBzaWduYWwgdGhhdCBjb21tcyBhcmUgbG9zdCBz b21ld2hlcmUNCg0KVGhhbmtzLA0KDQotTmlrDQoNCg== From nobody Thu Sep 24 13:08:21 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA14E1AC3AE for ; Thu, 24 Sep 2015 13:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham 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 0Ep2X7EF9klT for ; Thu, 24 Sep 2015 13:08:19 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.4]) (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 4376D1AC415 for ; Thu, 24 Sep 2015 13:08:19 -0700 (PDT) Received: from [216.82.250.19] by server-4.bemta-12.messagelabs.com id 26/C8-29923-23854065; Thu, 24 Sep 2015 20:08:18 +0000 X-Env-Sender: Stefan.Fouant@corero.com X-Msg-Ref: server-8.tower-87.messagelabs.com!1443125297!44795791!1 X-Originating-IP: [71.184.227.49] X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23734 invoked from network); 24 Sep 2015 20:08:18 -0000 Received: from mercury.corero.com (HELO MERCURY.corero.com) (71.184.227.49) by server-8.tower-87.messagelabs.com with AES128-SHA encrypted SMTP; 24 Sep 2015 20:08:18 -0000 Received: from MERCURY.corero.com ([fe80::2c05:6b26:abe2:ad24]) by MERCURY.corero.com ([fe80::2c05:6b26:abe2:ad24%19]) with mapi id 14.03.0248.002; Thu, 24 Sep 2015 16:08:17 -0400 From: Stefan Fouant To: "Teague, Nik" , Robert Moskowitz , Christopher Morrow , "Tirumaleswar Reddy (tireddy)" Thread-Topic: [Dots] How constrained due to attack congestion Thread-Index: AQHQ9sFRB9t5g/y4ekyGeb27kJH2Qp5L6JoAgAAkZYCAAD2BgIAADPSA//+//oCAAEWDgP//vwaA Date: Thu, 24 Sep 2015 20:08:16 +0000 Message-ID: References: <5603E6F4.5040407@htt-consult.com> <009901d0f6c9$8821cbc0$98656340$@jpshallow.com> <10e4a13c8d0a4cdcb76d38eb4f29aa3d@XCH-RCD-017.cisco.com> <560451D3.7080502@htt-consult.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [70.106.201.72] Content-Type: text/plain; charset="Windows-1252" Content-ID: <7790683B987D974AA02F48C0150C5A29@corero.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Jon Shallow , "dots@ietf.org" Subject: Re: [Dots] How constrained due to attack congestion X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2015 20:08:20 -0000 On 9/24/15, 4:00 PM, "Teague, Nik" wrote: >Hi, > >On 24/09/2015 15:52, "Dots on behalf of Stefan Fouant" > wrote: > >>Is the plan to work on the requirements doc at the same time as the use >>case? Because I envision the use case doc could cover some of this from a >>high level. > >Hi the use case and requirements should compliment each other. > >> >>I like the idea of using a connectionless oriented methodology coupled w/ >>heartbeats but there are caveats to such an approach - we may not want to >>initiate a mitigation action solely based on loss of such as any number >>of >>maintenance activities or other things could potentially trigger a >>mitigation. > >A heartbeat shouldn=B9t be enough to trigger an automitigation in my mind >but should signal that comms are lost somewhere Perhaps some type of signaling like we have in Graceful Restart where when a reboot is planned we can signal to peers to hold off a bit before reconverging might be of use=8A in equivalent terms, I think a method for indicating upstream that a planned maintenance is taking place might be warranted, such that simply loss of heartbeats doesn=B9t automatically impl= y mitigation. Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI, CISSP Senior Security Engineer Corero Network Security Mobile: +1.703.625.6243 =20 =20 Your Solution for Real-Time DDoS Protection From nobody Thu Sep 24 16:37:48 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5137F1B41E6 for ; Thu, 24 Sep 2015 16:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham 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 adRpZ7682s1M for ; Thu, 24 Sep 2015 16:37:45 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 229061B41E5 for ; Thu, 24 Sep 2015 16:37:45 -0700 (PDT) Received: by pacex6 with SMTP id ex6so86404170pac.0 for ; Thu, 24 Sep 2015 16:37:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-type; bh=25L59Ts5U7/1v9yYvl7LzG35uRnQDrqeNmA+PavdAwk=; b=MKHjHA1Prz4P7nfjbuulKbR6thhBzJmAKNqwXY44Kq0Y9WXYhihx08qSR60Qkwg0uM OHjpu7mVS770EYSzSlT3W7YAZwPFF9XcapEehjI2X4uePXscPlnLL6/KE6gO+YU1DUCk G3hnL5zSOpiU5MjWBiiemJSsbUeI4787YdYOQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-type; bh=25L59Ts5U7/1v9yYvl7LzG35uRnQDrqeNmA+PavdAwk=; b=Nt4VHpttTv65X/Sz+AYqhCwsuCDK3BWmGW56tEXCJ8aERG7StROhyCVbxylsY16Opv ds0sS0NoZh3NtXRmENAjkNpbrW76HVhkRCgWpI+VVqc2JavAUc4SAoKTYWdWhSi+EOaP nPEe4NUZJcr5mZpaJCOc9j5HUfnykHSeJcyf7Fg7MheOu86Q+W1z6TSQnNLoj20+0V5l Z8Gt7K4Xr2bYyv6IqNw/WOxm5N8i01KO5apT/rFkC6lK+2HUdoZkeU8GxJhQj+j8K02p 0X6KqGGqgEFfg+HmLnLvxjyeyTJFP3lSa84G3j9kjOyAb1HWq/hoU3hCc9Z2iOoRc+tw Su/w== X-Gm-Message-State: ALoCoQnZDzXYYGqbgPomijjsgIy9XzIX4BzxWrYtBE6JQVpAt8nupL2aIG40O10FpeqPMSqf491z X-Received: by 10.68.202.9 with SMTP id ke9mr2936516pbc.85.1443137864645; Thu, 24 Sep 2015 16:37:44 -0700 (PDT) Received: from [172.19.254.145] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id bk8sm484367pad.18.2015.09.24.16.37.42 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 24 Sep 2015 16:37:43 -0700 (PDT) From: "Roland Dobbins" To: dots@ietf.org Date: Fri, 25 Sep 2015 06:37:39 +0700 Message-ID: <5B01B3B3-826E-47D4-8D85-597823EBCA28@arbor.net> In-Reply-To: <560454E5.1070602@htt-consult.com> References: <5603E6F4.5040407@htt-consult.com> <009901d0f6c9$8821cbc0$98656340$@jpshallow.com> <10e4a13c8d0a4cdcb76d38eb4f29aa3d@XCH-RCD-017.cisco.com> <560451D3.7080502@htt-consult.com> <560454E5.1070602@htt-consult.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Subject: Re: [Dots] How constrained due to attack congestion X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2015 23:37:46 -0000 On 25 Sep 2015, at 2:54, Robert Moskowitz wrote: > Well I am consulting with one of the use case members... It would be good to consult with all of us. As has been noted both on this list and during the DOTS WG meeting in Prague, both stateless and stateful transports are necessary. It's unclear why this is being rehashed yet again. With regards to single-packet, the most basic DOTS supplicant request should fit into one, yes. But there are additional desirable options which would include multiple packets. ----------------------------------- Roland Dobbins From nobody Thu Sep 24 16:53:21 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B21B11B2E28 for ; Thu, 24 Sep 2015 16:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.665 X-Spam-Level: X-Spam-Status: No, score=-96.665 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HELO_EQ_D_D_D_D=1.597, HELO_DYNAMIC_IPADDR=1.951, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=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 VB3JgsdPNFQA for ; Thu, 24 Sep 2015 16:53:18 -0700 (PDT) Received: from lvps5-35-241-16.dedicated.hosteurope.de (www.gondrom.org [5.35.241.16]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C15B51B2E1E for ; Thu, 24 Sep 2015 16:53:18 -0700 (PDT) Received: from ip-109-85-73-19.web.vodafone.de (ip-109-85-73-19.web.vodafone.de [109.85.73.19]) by lvps5-35-241-16.dedicated.hosteurope.de (Postfix) with ESMTPSA id 6249D638E9; Fri, 25 Sep 2015 01:53:15 +0200 (CEST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=r9RvuzmHP0HolBdKGzf5Zzf8GA1n9/L95eVrHz5vqtNTBPGSGiAYDS4UkRRsxt5K0OwSgzs2SDi7d6b9EPBk86NH1YeedlOCm5PqnOdLs1UnsuZaKBLMBfx75Z5bFb2/3HXGpUrtMc0qSWRMojFUib5aLwGPdN1F0VFJxKTrkf0=; h=User-Agent:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Content-Type:Subject:From:Date:To:Message-ID; User-Agent: K-9 Mail for Android In-Reply-To: <5B01B3B3-826E-47D4-8D85-597823EBCA28@arbor.net> References: <5603E6F4.5040407@htt-consult.com> <009901d0f6c9$8821cbc0$98656340$@jpshallow.com> <10e4a13c8d0a4cdcb76d38eb4f29aa3d@XCH-RCD-017.cisco.com> <560451D3.7080502@htt-consult.com> <560454E5.1070602@htt-consult.com> <5B01B3B3-826E-47D4-8D85-597823EBCA28@arbor.net> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Tobias Gondrom Date: Thu, 24 Sep 2015 16:53:09 -0700 To: Roland Dobbins ,dots@ietf.org Message-ID: Archived-At: Subject: Re: [Dots] How constrained due to attack congestion X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2015 23:53:20 -0000 On September 24, 2015 4:37:39 PM PDT, Roland Dobbins wrote: >On 25 Sep 2015, at 2:54, Robert Moskowitz wrote: > >> Well I am consulting with one of the use case members... > >It would be good to consult with all of us. > >As has been noted both on this list and during the DOTS WG meeting in >Prague, both stateless and stateful transports are necessary. It's >unclear why this is being rehashed yet again. +1 Best regards, Tobias > >With regards to single-packet, the most basic DOTS supplicant request >should fit into one, yes. But there are additional desirable options >which would include multiple packets. > >----------------------------------- >Roland Dobbins > >_______________________________________________ >Dots mailing list >Dots@ietf.org >https://www.ietf.org/mailman/listinfo/dots -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From nobody Thu Sep 24 17:27:21 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26D8C1B2BBC for ; Thu, 24 Sep 2015 17:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham 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 EPmHwIDRCw_s for ; Thu, 24 Sep 2015 17:27:18 -0700 (PDT) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.201]) (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 8960E1B42D8 for ; Thu, 24 Sep 2015 17:27:18 -0700 (PDT) Received: from [216.82.241.211] by server-9.bemta-8.messagelabs.com id 9C/04-18860-5E494065; Fri, 25 Sep 2015 00:27:17 +0000 X-Env-Sender: Stefan.Fouant@corero.com X-Msg-Ref: server-15.tower-85.messagelabs.com!1443140836!54954831!1 X-Originating-IP: [71.184.227.49] X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31909 invoked from network); 25 Sep 2015 00:27:17 -0000 Received: from mercury.corero.com (HELO MERCURY.corero.com) (71.184.227.49) by server-15.tower-85.messagelabs.com with AES128-SHA encrypted SMTP; 25 Sep 2015 00:27:17 -0000 Received: from MERCURY.corero.com ([fe80::2c05:6b26:abe2:ad24]) by MERCURY.corero.com ([fe80::2c05:6b26:abe2:ad24%19]) with mapi id 14.03.0248.002; Thu, 24 Sep 2015 20:27:16 -0400 From: Stefan Fouant To: Roland Dobbins , "dots@ietf.org" Thread-Topic: [Dots] How constrained due to attack congestion Thread-Index: AQHQ9sFRB9t5g/y4ekyGeb27kJH2Qp5L6JoAgAAkZYCAAD2BgIAADPSA//+//oCAAEOrgIAAPm2A///KzIA= Date: Fri, 25 Sep 2015 00:27:15 +0000 Message-ID: References: <5603E6F4.5040407@htt-consult.com> <009901d0f6c9$8821cbc0$98656340$@jpshallow.com> <10e4a13c8d0a4cdcb76d38eb4f29aa3d@XCH-RCD-017.cisco.com> <560451D3.7080502@htt-consult.com> <560454E5.1070602@htt-consult.com> <5B01B3B3-826E-47D4-8D85-597823EBCA28@arbor.net> In-Reply-To: <5B01B3B3-826E-47D4-8D85-597823EBCA28@arbor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [70.106.201.72] Content-Type: text/plain; charset="us-ascii" Content-ID: <85D1F5EFDD1A924AB089E5DF1DE46B13@corero.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] How constrained due to attack congestion X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 00:27:20 -0000 On 9/24/15, 7:37 PM, "Dots on behalf of Roland Dobbins" wrote: >On 25 Sep 2015, at 2:54, Robert Moskowitz wrote: > >> Well I am consulting with one of the use case members... > >It would be good to consult with all of us. > >As has been noted both on this list and during the DOTS WG meeting in >Prague, both stateless and stateful transports are necessary. It's >unclear why this is being rehashed yet again. Agreed and apologies as I was not in Prague so I have not been synced up on all that was discussed during that meeting. Looking forward to working with all of you as we has out the use case requirements. Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI, CISSP Senior Security Engineer Corero Network Security Mobile: +1.703.625.6243 From nobody Thu Sep 24 17:36:52 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7033D1B4343 for ; Thu, 24 Sep 2015 17:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 LPkWpQ2PGgul for ; Thu, 24 Sep 2015 17:36:49 -0700 (PDT) Received: from mail-vk0-f50.google.com (mail-vk0-f50.google.com [209.85.213.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9778A1B4341 for ; Thu, 24 Sep 2015 17:36:49 -0700 (PDT) Received: by vkao3 with SMTP id o3so47249868vka.2 for ; Thu, 24 Sep 2015 17:36:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ZzLPqJH4xGvOKfqbeEkfydepk0pwtan+1nISPkJFHi0=; b=NEYrN2lBkNWB4APDLujm9JUAR3UmwtdyE2zy+rZQm2+9tjZwqfvKwH3rzja1ZJ/9qM vdtb1KeYm4WWCZvV9fycAcJEbUnd2jdEZCJ/H5WLBl22XCaQYK5mhYwlplYOvzMVEFVn 2q1/b/naGacsw5+BYyLP5eiaeriQx9v4smmQ7p7g0Hz4qJT3c4a8JMimOuXDvfJ9TT63 GJ6WctjeQ3cTacPDk1izBbV9y6AnrFYRLWIcDp5NvfCic0c3/bwuiJqkvjoK+//nCX19 bXtJDd/gVuRec+T0DfLY9HgoEo/qTvMyxR65ZZbeYFODg+TSSDQ6h1Onqb5SmpJfl1ec O+zw== X-Gm-Message-State: ALoCoQmnTEfPyVyxp4Q1hopa4jUojIRlIr3+jo408yV796D2Lm4I3UedcATnkejKo0VcDmLtthIs MIME-Version: 1.0 X-Received: by 10.31.161.80 with SMTP id k77mr1402645vke.106.1443141408717; Thu, 24 Sep 2015 17:36:48 -0700 (PDT) Received: by 10.31.93.71 with HTTP; Thu, 24 Sep 2015 17:36:48 -0700 (PDT) In-Reply-To: <5B01B3B3-826E-47D4-8D85-597823EBCA28@arbor.net> References: <5603E6F4.5040407@htt-consult.com> <009901d0f6c9$8821cbc0$98656340$@jpshallow.com> <10e4a13c8d0a4cdcb76d38eb4f29aa3d@XCH-RCD-017.cisco.com> <560451D3.7080502@htt-consult.com> <560454E5.1070602@htt-consult.com> <5B01B3B3-826E-47D4-8D85-597823EBCA28@arbor.net> Date: Thu, 24 Sep 2015 17:36:48 -0700 Message-ID: From: Jelena Mirkovic To: Roland Dobbins Content-Type: multipart/alternative; boundary=001a1143f8580714cb0520878b5b Archived-At: Cc: dots@ietf.org Subject: Re: [Dots] How constrained due to attack congestion X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 00:36:51 -0000 --001a1143f8580714cb0520878b5b Content-Type: text/plain; charset=UTF-8 It really sounds as if we'd need to start with use cases and work to implementations, then turn back, revisit, rehash, etc. There are several possible scenarios and we should give them names and support/work with all of them. 1. On-demand trust establishment, sign for protection service. This requires key exchange and TCP. Will work in some cases 2. I'm so clogged I cannot get messages back. I doubt that this is the case for acks which are usually super-small and will fit in router queues where larger packets won't but certainly in this case we cannot do on-demand trust establishment. 3. I'm so clogged I cannot get messages out. I'd like automated mitigation when this happens. etc. ========================= Jelena Mirkovic Research Faculty USC Information Sciences Institute 4676 Admiralty Way, Suite 1001 Marina del Rey, CA 90292 310-448-9170 On Thu, Sep 24, 2015 at 4:37 PM, Roland Dobbins wrote: > On 25 Sep 2015, at 2:54, Robert Moskowitz wrote: > > Well I am consulting with one of the use case members... >> > > It would be good to consult with all of us. > > As has been noted both on this list and during the DOTS WG meeting in > Prague, both stateless and stateful transports are necessary. It's unclear > why this is being rehashed yet again. > > With regards to single-packet, the most basic DOTS supplicant request > should fit into one, yes. But there are additional desirable options which > would include multiple packets. > > ----------------------------------- > Roland Dobbins > > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > --001a1143f8580714cb0520878b5b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It really sounds as if we'd need to start with use cas= es and work to implementations, then turn back, revisit, rehash, etc. There= are several possible scenarios and we should give them names and support/w= ork with all of them.=C2=A0

1. On-demand trust establish= ment, sign for protection service. This requires key exchange and TCP. Will= work in some cases

2. I'm so clogged I cannot= get messages back. I doubt that this is the case for acks which are usuall= y super-small and will fit in router queues where larger packets won't = but certainly in this case we cannot do on-demand trust establishment.

3. I'm so clogged I cannot get messages out. I'= ;d like automated mitigation when this happens.

et= c.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

Jelena Mirkovic
Research= Faculty
USC Informa= tion Sciences Institute
4676 Admiralty Way, Suite 1001
Marina del Rey, CA 90292
310-448-9170


On Thu, Sep 24, 2015 at 4:37 PM, Roland Dobb= ins <rdobbins@arbor.net> wrote:
On 25 Sep 2015, at 2:54, Robert Moskowitz wrote:
Well I am consulting with one of the use case members...

 It would be good to consult with all of us.

As has been noted both on this list and during the DOTS WG meeting in Pragu= e, both stateless and stateful transports are necessary.=C2=A0 It's unc= lear why this is being rehashed yet again.

With regards to single-packet, the most basic DOTS supplicant request shoul= d fit into one, yes.=C2=A0 But there are additional desirable options which= would include multiple packets.

-----------------------------------
Roland Dobbins <= rdobbins@arbor.net>


_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots

--001a1143f8580714cb0520878b5b-- From nobody Thu Sep 24 17:39:26 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67B111B4348 for ; Thu, 24 Sep 2015 17:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham 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 fQdVOTeDjHMZ for ; Thu, 24 Sep 2015 17:39:24 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 669761B434C for ; Thu, 24 Sep 2015 17:39:24 -0700 (PDT) Received: by pacfv12 with SMTP id fv12so89354179pac.2 for ; Thu, 24 Sep 2015 17:39:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-type; bh=HkEhpi31yxtzLbc3cEMQgLJNbtTlxh8hlr51QwG8kV4=; b=H2gPxV7ZZCP56Ajz9NXdCTTIFjNgUHnrj0HLNFglPeH2nJhxEPHQ3u8zNhGN/W5wXS gTiq+ob/YfgwwHhOTgbVPHZz6wRQmgsV2BjFVUGLdy2ISIzy8uQESh8gywXKhohcv3K1 h5GbWPptre8DpFDD0Xr37y0ThKnMHu19Ntp3Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-type; bh=HkEhpi31yxtzLbc3cEMQgLJNbtTlxh8hlr51QwG8kV4=; b=C/0jXHZ20pHJxsEpY1gsvyHNfYKg4roZKqxOn3KU1nO96DCyKe5W5p4TwsIlddts2Z zqFOBv5zHZUpkEvQzW36zWLDbI5FahP+C6Z9CcR8FqcQpchjPvFAIJjSERlSGbOeDv7X DNIXE5hp1HvCiIzkuJi8v+YJWZ4ELPF2EHgOMXRRxf+BPiS2MN6tK7acC4D1K5XqAhVx 6g5DSqR8AwLwNTNMyJyO8PDlAhXHvP9nfr5K9Z/9U8F1vg82UV6egLYYwfti4P1n9JSv HWxS5/LXSIUDOwNRXy2v98WVYq2713Ao20j2YUsC3ieCGe0DV3hYoqyruSztDVG9mrnx urCw== X-Gm-Message-State: ALoCoQmieF8YMb22x8krLTTLhb68LB3k/ZPW3d1YqMMuDgNN+aKd1h/MN2VCBHAcBzB3rDwWroAi X-Received: by 10.68.111.165 with SMTP id ij5mr3192731pbb.59.1443141563921; Thu, 24 Sep 2015 17:39:23 -0700 (PDT) Received: from [172.19.254.145] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id pu5sm617358pbc.58.2015.09.24.17.39.21 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 24 Sep 2015 17:39:22 -0700 (PDT) From: "Roland Dobbins" To: dots@ietf.org Date: Fri, 25 Sep 2015 07:39:18 +0700 Message-ID: In-Reply-To: References: <5603E6F4.5040407@htt-consult.com> <009901d0f6c9$8821cbc0$98656340$@jpshallow.com> <10e4a13c8d0a4cdcb76d38eb4f29aa3d@XCH-RCD-017.cisco.com> <560451D3.7080502@htt-consult.com> <560454E5.1070602@htt-consult.com> <5B01B3B3-826E-47D4-8D85-597823EBCA28@arbor.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Subject: Re: [Dots] How constrained due to attack congestion X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 00:39:25 -0000 On 25 Sep 2015, at 7:36, Jelena Mirkovic wrote: > It really sounds as if we'd need to start with use cases and work to > implementations, then turn back, revisit, rehash, etc. If we were starting from first principles in an intellectual vacuum, yes. Fortunately, we aren't. We've already discussed in a reasonable degree of detail the broad requirements, and we've also discussed the broad requirements; couple that with the skills and experience of those who're participating in this effort, and we can start at each and work simultaneously towards the middle. ----------------------------------- Roland Dobbins From nobody Thu Sep 24 17:46:40 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3618C1A8968 for ; Thu, 24 Sep 2015 17:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 p5CAycv8O8xu for ; Thu, 24 Sep 2015 17:46:37 -0700 (PDT) Received: from atl4mhob10.myregisteredsite.com (atl4mhob10.myregisteredsite.com [209.17.115.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4D51A8AC3 for ; Thu, 24 Sep 2015 17:46:32 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.204]) by atl4mhob10.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id t8P0kV4T018206 for ; Thu, 24 Sep 2015 20:46:31 -0400 Received: (qmail 8711 invoked by uid 0); 25 Sep 2015 00:46:31 -0000 X-TCPREMOTEIP: 75.118.191.143 X-Authenticated-UID: gclark@mti-systems.com Received: from unknown (HELO ?192.168.0.3?) (gclark@mti-systems.com@75.118.191.143) by 0 with ESMTPA; 25 Sep 2015 00:46:31 -0000 To: dots@ietf.org References: <5603E6F4.5040407@htt-consult.com> <009901d0f6c9$8821cbc0$98656340$@jpshallow.com> <10e4a13c8d0a4cdcb76d38eb4f29aa3d@XCH-RCD-017.cisco.com> <560451D3.7080502@htt-consult.com> From: Gilbert Clark Message-ID: <56049960.8070702@mti-systems.com> Date: Thu, 24 Sep 2015 20:46:24 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Dots] How constrained due to attack congestion X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 00:46:39 -0000 On 9/24/2015 4:08 PM, Stefan Fouant wrote: > On 9/24/15, 4:00 PM, "Teague, Nik" wrote: > > >> Hi, >> >> On 24/09/2015 15:52, "Dots on behalf of Stefan Fouant" >> wrote: >> >>> Is the plan to work on the requirements doc at the same time as the use >>> case? Because I envision the use case doc could cover some of this from a >>> high level. >> Hi the use case and requirements should compliment each other. >> >>> I like the idea of using a connectionless oriented methodology coupled w/ >>> heartbeats but there are caveats to such an approach - we may not want to >>> initiate a mitigation action solely based on loss of such as any number >>> of >>> maintenance activities or other things could potentially trigger a >>> mitigation. >> A heartbeat shouldn¹t be enough to trigger an automitigation in my mind >> but should signal that comms are lost somewhere > Perhaps some type of signaling like we have in Graceful Restart where when > a reboot is planned we can signal to peers to hold off a bit before > reconverging might be of useŠ in equivalent terms, I think a method for > indicating upstream that a planned maintenance is taking place might be > warranted, such that simply loss of heartbeats doesn¹t automatically imply > mitigation. Well, my thought here is that a lost heartbeat is not necessarily indicative of a DDoS, only of a more general network issue somewhere between points A and B. I would think heartbeats should therefore never be used (on their own) to trigger an automated mitigation. -Gilbert From nobody Thu Sep 24 17:47:46 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 310B21A8F43 for ; Thu, 24 Sep 2015 17:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham 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 t28ehTtch_Ef for ; Thu, 24 Sep 2015 17:47:41 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26D721A8F3B for ; Thu, 24 Sep 2015 17:47:41 -0700 (PDT) Received: by padhy16 with SMTP id hy16so88151209pad.1 for ; Thu, 24 Sep 2015 17:47:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=from:to:subject:date:message-id:mime-version:content-type; bh=ez+MIqk5jJtyCo3vPVrVEEkyhxdeTqAuNiu8VyTed2c=; b=QOjw3ET33Huhp6xGA6rDaLR7G2YhM2hqY5BG3fbkavUaJWvPMbx31K07yL7MpnWOvi df4zViSiF1W7LONoZISY1sFJi2tEnmsKEv405DQnOVV2pI/FtqLFGDhKYS91xwLT1jn+ KIk044eUPjk8LgQ1dGDyUIdGhACr5NpqgrjvU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-type; bh=ez+MIqk5jJtyCo3vPVrVEEkyhxdeTqAuNiu8VyTed2c=; b=dt1bCnItciofqO1PibEwKtWtQLlrXbkAhlgnq6ts0gjhKjO7rpu+83pjjwvi/KGcNf JAazl4o43m8LsL62rSarvdGEx6wFuY7PV99OVU5iqyvlt+Sgqz3DYwDbA4jXNpFdV1Q3 4fgrmpooog9uI5HuawEhRlyJO+Q4E2AjS+9yvjDByPSk+nToN/AWgoytpY70kGx6AbKM eLJVpJ3zbKWifgZ+P0tw7BM05GLKhI3ssJBJsD67MJW2ilc3ogQT2riZpXG6lsKYg94Q wEqBWJZMxtpZSx6A2n3ORoffClgCo/nVzmIfl55cIPGJOSjOn0Ig9hlYGuUdxA0/6Qg7 +H3g== X-Gm-Message-State: ALoCoQmATbbUFV4oig8U62mgep6yZTv1vyu940z1sNWRRy1Lh/N9Wxh6cXHreZTxaUHVp7KOu3Ru X-Received: by 10.68.137.35 with SMTP id qf3mr3246609pbb.89.1443142060791; Thu, 24 Sep 2015 17:47:40 -0700 (PDT) Received: from [172.19.254.145] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id ox2sm625850pbb.87.2015.09.24.17.47.39 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 24 Sep 2015 17:47:40 -0700 (PDT) From: "Roland Dobbins" To: dots Date: Fri, 25 Sep 2015 07:47:36 +0700 Message-ID: <59F3A868-2028-4EB5-A429-C29CA6F3CB15@arbor.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Subject: [Dots] IETF 93 DOTS WG operational requirements preso. X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 00:47:44 -0000 As a reminder/refresher for those who were unable to attend the WG meeting in Prague and/or didn't get a chance to look at the video of the meeting, here's a presentation which provides a decent overview of the problem space, what we aim to accomplish, and broad requirements for doing so (.pdf file hosted on box.com): ----------------------------------- Roland Dobbins From nobody Thu Sep 24 19:02:19 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAA2B1B34A4 for ; Thu, 24 Sep 2015 19:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 RqnDm2I3JJWP for ; Thu, 24 Sep 2015 19:02:15 -0700 (PDT) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70FFD1B34A2 for ; Thu, 24 Sep 2015 19:02:15 -0700 (PDT) Received: by ykdz138 with SMTP id z138so102700113ykd.2 for ; Thu, 24 Sep 2015 19:02:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=uAjU1dbloEoU2+QUKjSXJgj6U8hCo7aIlq2VgkEaFuY=; b=Y/I2QcTtH5ZFbW174Lenlg+ifhU2W2CNz5AC1aih875/PqBzCmlEJzCcSLz77cgona E4hVQOlKS3O6v/tlFMR/X88I11wWYIlLeyoqOt5Q0fF6VgAvi7+gPgMkhxiYMOEr64w9 IqX6YGi4d3/cOfEKwkr7mag2VRuqbxdFseJqAg07zsD3x6X18r27zYUgKOltwPBeyqsQ aGiIH/biq9ZEQsCkAUDQv+pUv8Ufwz6JpOH3Hk+Y7FwEMiwhOz2ibxTQzTcyS0/MChcI XhthSP4dzndgK/FDxPI3rFvAZDxW6eFavrwIDeHuI0Aqbvh3lYqbossdHx1I5PSGybqV MFLA== MIME-Version: 1.0 X-Received: by 10.170.73.66 with SMTP id p63mr2677029ykp.42.1443146534746; Thu, 24 Sep 2015 19:02:14 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.13.202.22 with HTTP; Thu, 24 Sep 2015 19:02:14 -0700 (PDT) In-Reply-To: <560451D3.7080502@htt-consult.com> References: <5603E6F4.5040407@htt-consult.com> <009901d0f6c9$8821cbc0$98656340$@jpshallow.com> <10e4a13c8d0a4cdcb76d38eb4f29aa3d@XCH-RCD-017.cisco.com> <560451D3.7080502@htt-consult.com> Date: Thu, 24 Sep 2015 22:02:14 -0400 X-Google-Sender-Auth: o5_iq5Lmt6TOJo5_m4qA2qM-lxg Message-ID: From: Christopher Morrow To: Robert Moskowitz Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Jon Shallow , "dots@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [Dots] How constrained due to attack congestion X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 02:02:18 -0000 On Thu, Sep 24, 2015 at 3:41 PM, Robert Moskowitz wrote: > Not quite so if this goes into the requirements document. Of which Tiru, > Andy, and I are the joint editors... > > "The protocol design needs to be cognizant of transmission limitations > during an attack and minimize the number of datagrams and return > acknowledgments to send to initiate a mitigation action." Is really vague > but covers the concern. More meat would be good for the meal... as a requirement: "Be stingy with network resources" seems ok, sure. I don't think it's relevant if it's "during an attack" or not. > Or "If the controller has not heard a heartbeat (if supported) within a > reasonable time, an attack may be underway and mitigation should be > initiated." > yikes, that seems like a poor plan... what if my detector is simply offline for reasons not related to dos? (power cycle, power problems in that rack/row, 'bad hardware') -chris > > > On 09/24/2015 02:54 PM, Christopher Morrow wrote: >> >> this all sounds like 'bikeshedding' at this point... we don't yet (I >> think) have 'what will be communicated' between the endpoints in >> question. Once we agree on that, perhaps we can decide how to pack >> 10lbs into the 5lb bag. >> >> The vast majority of 'oh crap, I'm under attack' problems are 'my >> inbound link is full, holy crap!', so outbound traffic ought to 'just >> work', presuming you don't require timely replies... >> >> anyway, it seems like we jumped ahead of ourselves, it's good to keep >> in mind for later though. >> >> On Thu, Sep 24, 2015 at 11:14 AM, Tirumaleswar Reddy (tireddy) >> wrote: >>>> >>>> -----Original Message----- >>>> From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow >>>> Sent: Thursday, September 24, 2015 6:34 PM >>>> To: dots@ietf.org >>>> Subject: Re: [Dots] How constrained due to attack congestion >>>> >>>> Hi Rob, >>>> >>>> As I see this, the congested link can be in one of two directions (or >>>> possibly >>>> both). "Local" is signalling to "Remote" about what is happening. >>>> >>>> Direction Inbound Congestion. >>>> Any protocol that requires an acknowledgement (e.g. TCP) will fail when >>>> trying to send an outbound "Help Attack" message. As there is no >>>> outbound >>>> congestion, the "Help Attack" messages would not be constrained to a >>>> minimal size, but, in my opinion, should be able to fit in a standard >>>> packet >>>> (see Protocols below). >>>> >>>> Direction Outbound Congestion >>>> Any "Help Attack" message will not get through - but as this is >>>> Outbound, >>>> then the remote end cannot respond, but will be able to detect the lack >>>> of >>>> any "Heart Beat" messages getting through. The local end will need to >>>> put >>>> mitigation defences in place to stop the outbound congestion. >>>> >>>> Direction Both Congestion >>>> The Outbound Congestion needs to be fixed locally. >>>> >>>> Protocols >>>> This then leans towards the use of a protocol such as UDP for sending >>>> "Help >>>> Attack" messages. If this protocol has to have a security wrapper (most >>>> would say yes), then any key exchange updates may not successfully take >>>> place during this congestion period - thus there would have to be >>>> support for >>>> being able to use old keys during this congestion period. >>> >>> TLS session resumption without server-side state RFC5077 can possibly be >>> used, but it still consumes 1 round trip before the "Help attack" message >>> can be signaled. Another alternative is to go with TLS 1.3 which supports >>> zero round-trip. >>> >>> -Tiru >>> >>>> Whether IPFix is the correct layer 7 protocol is open for debate. >>>> >>>> Regards >>>> >>>> Jon >>>> >>>> -----Original Message----- >>>> From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Robert Moskowitz >>>> Sent: 24 September 2015 13:05 >>>> To: dots >>>> Subject: [Dots] How constrained due to attack congestion >>>> >>>> One of the requirements for DOTS is to be able to message an attack >>>> while >>>> the attack is congesting the link. >>>> >>>> Are we going to put any measure on this or recommend any approach to >>>> communicate over a constrained link. >>>> >>>> As I view where I am coming from on this, I have spent considerable time >>>> down in IEEE 802.15 dealing with very constrained and lousy links. A >>>> lot of >>>> thought goes into what CAN be transmitted and to what degree of effort >>>> is >>>> made at what level to improve likelihood of success. >>>> >>>> To this end, do we recommend that the DOTS message about an attack MUST >>>> fit wtihin a single datagram? And if so how do we count the bytes? >>>> That is figure out the transmission overhead: TCP or UDP and what >>>> security >>>> envelope? >>>> >>>> Consider what CORE has done to design CoAP as a binary RESTful protocol >>>> to >>>> work over a constrained link. Is IPFix thus a good approach? >>>> >>>> Does anyone have any actual measurements of what size messages CAN get >>>> through during an attack? >>>> >>>> thank you >>>> >>>> >>>> _______________________________________________ >>>> Dots mailing list >>>> Dots@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dots >>>> >>>> _______________________________________________ >>>> Dots mailing list >>>> Dots@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dots >>> >>> _______________________________________________ >>> Dots mailing list >>> Dots@ietf.org >>> https://www.ietf.org/mailman/listinfo/dots >> >> _______________________________________________ >> Dots mailing list >> Dots@ietf.org >> https://www.ietf.org/mailman/listinfo/dots >> > From nobody Thu Sep 24 19:02:59 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAE4A1B349E for ; Thu, 24 Sep 2015 19:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 kzvgtrAL-89j for ; Thu, 24 Sep 2015 19:02:56 -0700 (PDT) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CE051B3456 for ; Thu, 24 Sep 2015 19:02:56 -0700 (PDT) Received: by ykdg206 with SMTP id g206so101062537ykd.1 for ; Thu, 24 Sep 2015 19:02:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=LXsekQL5KtT8tshIBayVl0xt0prmQu2pwRL9cFlsnAQ=; b=OPCw3jigGLpzJfwMiiFjb1xyy6AIDTccCcXFc3yXBN6NKWBKzy67LVEYBYmYfNcM+V DRmWfDaybkVZPp12WH74ApEMtgBR3BOaENq8DbKbbni8/aJYNYZKJ3Audml3E7O0XpEs DqXWoS0EN78qzSTKYV5ByV+Rd3LMxKL86U9FeCwsHMgDCwxz0j3dgH47kxTxXJVsQVsb Nq4tklnp6rzj+YLgN/urFUw6DyWgyQMAyHssqG6XqHtVSuvxHSM6O7nnclBvf2Esnah1 n64s3gs1kigxlO2c/ewu6XftP9KSFhdcppftihZ0K02A4mz5NnHk9gOUBkx5/zyAyl7k Yi0w== MIME-Version: 1.0 X-Received: by 10.170.136.67 with SMTP id d64mr2571470ykc.103.1443146575543; Thu, 24 Sep 2015 19:02:55 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.13.202.22 with HTTP; Thu, 24 Sep 2015 19:02:55 -0700 (PDT) In-Reply-To: References: <5603E6F4.5040407@htt-consult.com> <009901d0f6c9$8821cbc0$98656340$@jpshallow.com> <10e4a13c8d0a4cdcb76d38eb4f29aa3d@XCH-RCD-017.cisco.com> <560451D3.7080502@htt-consult.com> Date: Thu, 24 Sep 2015 22:02:55 -0400 X-Google-Sender-Auth: T8n6OATxffKr3Q53bu65bVMzSCQ Message-ID: From: Christopher Morrow To: Stefan Fouant Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Jon Shallow , "dots@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" , Robert Moskowitz Subject: Re: [Dots] How constrained due to attack congestion X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 02:02:58 -0000 On Thu, Sep 24, 2015 at 3:52 PM, Stefan Fouant wrote: > Is the plan to work on the requirements doc at the same time as the use > case? Because I envision the use case doc could cover some of this from a > high level. > > I like the idea of using a connectionless oriented methodology coupled w/ > heartbeats but there are caveats to such an approach - we may not want to > initiate a mitigation action solely based on loss of such as any number of > maintenance activities or other things could potentially trigger a > mitigation. this was my thinking, I should have read more of the thread :) > Stefan Fouant > JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI, CISSP > Senior Security Engineer > Corero Network Security > Mobile: +1.703.625.6243 > > Your Solution for Real-Time DDoS Protection > > > > On 9/24/15, 3:41 PM, "Dots on behalf of Robert Moskowitz" > wrote: > >>Not quite so if this goes into the requirements document. Of which >>Tiru, Andy, and I are the joint editors... >> >>"The protocol design needs to be cognizant of transmission limitations >>during an attack and minimize the number of datagrams and return >>acknowledgments to send to initiate a mitigation action." Is really >>vague but covers the concern. More meat would be good for the meal... >> >>Or "If the controller has not heard a heartbeat (if supported) within a >>reasonable time, an attack may be underway and mitigation should be >>initiated." >> >> >> >>On 09/24/2015 02:54 PM, Christopher Morrow wrote: >>> this all sounds like 'bikeshedding' at this point... we don't yet (I >>> think) have 'what will be communicated' between the endpoints in >>> question. Once we agree on that, perhaps we can decide how to pack >>> 10lbs into the 5lb bag. >>> >>> The vast majority of 'oh crap, I'm under attack' problems are 'my >>> inbound link is full, holy crap!', so outbound traffic ought to 'just >>> work', presuming you don't require timely replies... >>> >>> anyway, it seems like we jumped ahead of ourselves, it's good to keep >>> in mind for later though. >>> >>> On Thu, Sep 24, 2015 at 11:14 AM, Tirumaleswar Reddy (tireddy) >>> wrote: >>>>> -----Original Message----- >>>>> From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow >>>>> Sent: Thursday, September 24, 2015 6:34 PM >>>>> To: dots@ietf.org >>>>> Subject: Re: [Dots] How constrained due to attack congestion >>>>> >>>>> Hi Rob, >>>>> >>>>> As I see this, the congested link can be in one of two directions (or >>>>>possibly >>>>> both). "Local" is signalling to "Remote" about what is happening. >>>>> >>>>> Direction Inbound Congestion. >>>>> Any protocol that requires an acknowledgement (e.g. TCP) will fail >>>>>when >>>>> trying to send an outbound "Help Attack" message. As there is no >>>>>outbound >>>>> congestion, the "Help Attack" messages would not be constrained to a >>>>> minimal size, but, in my opinion, should be able to fit in a standard >>>>>packet >>>>> (see Protocols below). >>>>> >>>>> Direction Outbound Congestion >>>>> Any "Help Attack" message will not get through - but as this is >>>>>Outbound, >>>>> then the remote end cannot respond, but will be able to detect the >>>>>lack of >>>>> any "Heart Beat" messages getting through. The local end will need >>>>>to put >>>>> mitigation defences in place to stop the outbound congestion. >>>>> >>>>> Direction Both Congestion >>>>> The Outbound Congestion needs to be fixed locally. >>>>> >>>>> Protocols >>>>> This then leans towards the use of a protocol such as UDP for sending >>>>>"Help >>>>> Attack" messages. If this protocol has to have a security wrapper >>>>>(most >>>>> would say yes), then any key exchange updates may not successfully >>>>>take >>>>> place during this congestion period - thus there would have to be >>>>>support for >>>>> being able to use old keys during this congestion period. >>>> TLS session resumption without server-side state RFC5077 can possibly >>>>be used, but it still consumes 1 round trip before the "Help attack" >>>>message can be signaled. Another alternative is to go with TLS 1.3 >>>>which supports zero round-trip. >>>> >>>> -Tiru >>>> >>>>> Whether IPFix is the correct layer 7 protocol is open for debate. >>>>> >>>>> Regards >>>>> >>>>> Jon >>>>> >>>>> -----Original Message----- >>>>> From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Robert >>>>>Moskowitz >>>>> Sent: 24 September 2015 13:05 >>>>> To: dots >>>>> Subject: [Dots] How constrained due to attack congestion >>>>> >>>>> One of the requirements for DOTS is to be able to message an attack >>>>>while >>>>> the attack is congesting the link. >>>>> >>>>> Are we going to put any measure on this or recommend any approach to >>>>> communicate over a constrained link. >>>>> >>>>> As I view where I am coming from on this, I have spent considerable >>>>>time >>>>> down in IEEE 802.15 dealing with very constrained and lousy links. A >>>>>lot of >>>>> thought goes into what CAN be transmitted and to what degree of >>>>>effort is >>>>> made at what level to improve likelihood of success. >>>>> >>>>> To this end, do we recommend that the DOTS message about an attack >>>>>MUST >>>>> fit wtihin a single datagram? And if so how do we count the bytes? >>>>> That is figure out the transmission overhead: TCP or UDP and what >>>>>security >>>>> envelope? >>>>> >>>>> Consider what CORE has done to design CoAP as a binary RESTful >>>>>protocol to >>>>> work over a constrained link. Is IPFix thus a good approach? >>>>> >>>>> Does anyone have any actual measurements of what size messages CAN get >>>>> through during an attack? >>>>> >>>>> thank you >>>>> >>>>> >>>>> _______________________________________________ >>>>> Dots mailing list >>>>> Dots@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dots >>>>> >>>>> _______________________________________________ >>>>> Dots mailing list >>>>> Dots@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dots >>>> _______________________________________________ >>>> Dots mailing list >>>> Dots@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dots >>> _______________________________________________ >>> Dots mailing list >>> Dots@ietf.org >>> https://www.ietf.org/mailman/listinfo/dots >>> >> >>_______________________________________________ >>Dots mailing list >>Dots@ietf.org >>https://www.ietf.org/mailman/listinfo/dots > From nobody Thu Sep 24 20:34:15 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D214A1B35EE for ; Thu, 24 Sep 2015 20:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001] autolearn=ham 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 Adr-eO9pmcX3 for ; Thu, 24 Sep 2015 20:34:11 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 591D11B35EB for ; Thu, 24 Sep 2015 20:34:11 -0700 (PDT) Received: by iofb144 with SMTP id b144so98746696iof.1 for ; Thu, 24 Sep 2015 20:34:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=NEVeHIn76yF6ZoEE2/4nSfVeBHGep7NQ8Fi+NwXAfPA=; b=Q7eZRifxwRGJHUUw3jKRB7sxuYrhwlWznsP1VYfROJnG29ssfawOXR9cg19gEhiCcj h6zK7JL0fNOiQCs5+YKm1/Fvuizyt6tzIewpRXPvfzOz6wLnWb5/Hrr+qAmO7YheimLi O8w0Ldh3QL3iDUUkt3+qbrq5oA6QvxhnuuOw8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=NEVeHIn76yF6ZoEE2/4nSfVeBHGep7NQ8Fi+NwXAfPA=; b=ZzXpnf1uc83jHJx1QMFq+1xYgy6TuDk7PKJuDsgK0CcD6geaHqf0t7PPR6vA07u3ie HCHDXvLFGGtbu4cvCWXkO91hc/TK5MDqCVXrvDrPY00UkrmeR+0nB/BTKDGEdJ8hyRp0 yQG4528pZVX4l0G+bDdnog7KW1IWBgur9ZAgG/cuSeDCOcFEYnjU8HCr34cK1dKCl3i8 9zUB7CbHLW3QQIbofTbMDrw1dxGBlxT2C/TTQ4bj8QnWFkysyXUTO6sbuel5Ahj5i9P4 GwNpR32uX5lxoKPcGfwElkqKtup/01mVBOFdO0X4Y8KFhXY3R7P+8oqE7jY9bYWBls20 dKYg== X-Gm-Message-State: ALoCoQmYPO2BUzpLh2q/HSERf581XcwxYaT01wjDDdVNEY2I1oX1QZrSxsoE+/0xR4jWm8Y3tNjZ X-Received: by 10.107.158.146 with SMTP id h140mr4057924ioe.3.1443152050180; Thu, 24 Sep 2015 20:34:10 -0700 (PDT) Received: from [10.0.1.6] (c-68-49-167-203.hsd1.mi.comcast.net. [68.49.167.203]) by smtp.gmail.com with ESMTPSA id yr2sm594635igb.22.2015.09.24.20.34.09 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Sep 2015 20:34:09 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_4C193F36-6863-4AE0-A709-9604B2761A3D" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Andrew Mortensen In-Reply-To: Date: Thu, 24 Sep 2015 23:34:09 -0400 Message-Id: References: <5603E6F4.5040407@htt-consult.com> <009901d0f6c9$8821cbc0$98656340$@jpshallow.com> <10e4a13c8d0a4cdcb76d38eb4f29aa3d@XCH-RCD-017.cisco.com> <560451D3.7080502@htt-consult.com> To: "dots@ietf.org" X-Mailer: Apple Mail (2.2102) Archived-At: Cc: Christopher Morrow Subject: [Dots] Heartbeat requirements (was: How constrained due to attack congestion) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 03:34:14 -0000 --Apple-Mail=_4C193F36-6863-4AE0-A709-9604B2761A3D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Sep 24, 2015, at 10:02 PM, Christopher Morrow = wrote: >=20 > On Thu, Sep 24, 2015 at 3:52 PM, Stefan Fouant = wrote: >> Is the plan to work on the requirements doc at the same time as the = use >> case? Yes, please see the list archives: > My expectation, based on my reading of other contemporary drafts at this = stage, is that each draft will inform the other. >> I like the idea of using a connectionless oriented methodology = coupled w/ >> heartbeats but there are caveats to such an approach - we may not = want to >> initiate a mitigation action solely based on loss of such as any = number of >> maintenance activities or other things could potentially trigger a >> mitigation. >=20 > this was my thinking, Mine as well. Given the reasons you=E2=80=99ve both cited, I=E2=80=99ll = go further and say servers/mitigators MUST NOT treat loss of heartbeat = in either direction=E2=80=94client messages failing to reach the server, = and vice versa=E2=80=94as grounds to begin mitigation. Loss of = heartbeat/signal from the client is not an attack canary. With respect to heartbeats generally, I discussed signal channel health = a bit in my initial rough requirements draft prior to the last meeting: = In my view, any successfully delivered message acts as a heartbeat. andrew= --Apple-Mail=_4C193F36-6863-4AE0-A709-9604B2761A3D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Sep 24, 2015, at 10:02 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:

On Thu, Sep 24, 2015 = at 3:52 PM, Stefan Fouant <Stefan.Fouant@corero.com> wrote:
Is the plan to work on = the requirements doc at the same time as the use
case?

Yes, please see the list archives:


My expectation, = based on my reading of other contemporary drafts at this stage, is that = each draft will inform the other.


I like = the idea of using a connectionless oriented methodology coupled w/
heartbeats but there are caveats to such an approach - we may = not want to
initiate a mitigation action solely based on = loss of such as any number of
maintenance activities or = other things could potentially trigger a
mitigation.

this was my = thinking,

Mine as well. = Given the reasons you=E2=80=99ve both cited, I=E2=80=99ll go further and = say servers/mitigators MUST NOT treat loss of heartbeat in either = direction=E2=80=94client messages failing to reach the server, and vice = versa=E2=80=94as grounds to begin mitigation. Loss of heartbeat/signal = from the client is not an attack canary.

With respect to heartbeats generally, I discussed = signal channel health a bit in my initial rough requirements draft prior = to the last meeting:


In= my view, any successfully delivered message acts as a = heartbeat.

andrew
= --Apple-Mail=_4C193F36-6863-4AE0-A709-9604B2761A3D-- From nobody Thu Sep 24 21:00:39 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4C21B3622 for ; Thu, 24 Sep 2015 21:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 E9H9X6NxUv0C for ; Thu, 24 Sep 2015 21:00:37 -0700 (PDT) Received: from mail-qg0-f97.google.com (mail-qg0-f97.google.com [209.85.192.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E7041B361F for ; Thu, 24 Sep 2015 21:00:37 -0700 (PDT) Received: by qgt47 with SMTP id 47so4870529qgt.0 for ; Thu, 24 Sep 2015 21:00:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:user-agent:content-type:content-id :content-transfer-encoding:mime-version; bh=B/TXlbqyqMuNFx6N1Zakwf4hYYRozPGznfEjBNrkw94=; b=G1/XCV2JhOLU6AUn+fxhab03jMB6wFKghi6qqcHw/cc26AwC+f4NBz9NfrZ1U7YJjM Jp833VDVQUqUOcSmsLoqh2nTKCz4k4PagsZ8O9zCbce26D1BmmPbH5phzawiTQwjL494 /1kOPdp1bhlUIhFhyYzxh5WXqKhkuWdFqKyIYv6rIYvtnSwuWALyQ0dVcyYwVe7mblWh uifDkieu4P3MIvbdWsv03Odf3HRw9ROnN2CpChiqkQDa6E3MVSSTHWoabO29h5IxtTeG hLhTNocG+8Nmi0/muDT4sf8KlMy9J3CVKn7D1iUCHUayAufJpxIRI12v0MeQWbHbE/9U 9CAg== X-Gm-Message-State: ALoCoQm+MPPIscWcoXuQrV3zlrymMNMhXNjP+AGDKPiiegVCezQLH1wXpPpT0JS3TXMyb768fLYSR1wsu2Q7qvDGhmq3lG6vVA== X-Received: by 10.55.22.143 with SMTP id 15mr3713374qkw.38.1443153636341; Thu, 24 Sep 2015 21:00:36 -0700 (PDT) Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by smtp-relay.gmail.com with ESMTPS id s2sm155469qks.1.2015.09.24.21.00.36 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 24 Sep 2015 21:00:36 -0700 (PDT) X-Relaying-Domain: verisign.com Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01 [10.173.152.255]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id t8P40Zq3023154 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Sep 2015 00:00:35 -0400 Received: from BRN1WNEXMBX02.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Fri, 25 Sep 2015 00:00:34 -0400 From: "Teague, Nik" To: Andrew Mortensen , "dots@ietf.org" Thread-Topic: [Dots] Heartbeat requirements (was: How constrained due to attack congestion) Thread-Index: AQHQ90a6otD6FTyQ00GaK7iOMUC7lw== Date: Fri, 25 Sep 2015 04:00:33 +0000 Message-ID: References: <5603E6F4.5040407@htt-consult.com> <009901d0f6c9$8821cbc0$98656340$@jpshallow.com> <10e4a13c8d0a4cdcb76d38eb4f29aa3d@XCH-RCD-017.cisco.com> <560451D3.7080502@htt-consult.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.5.150821 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="utf-8" Content-ID: <2DAF5FFE86E46549B9FBF08C7B5E65A0@verisign.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Christopher Morrow Subject: Re: [Dots] Heartbeat requirements (was: How constrained due to attack congestion) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 04:00:39 -0000 T24gMjQvMDkvMjAxNSAyMzozNCwgIkRvdHMgb24gYmVoYWxmIG9mIEFuZHJldyBNb3J0ZW5zZW4i DQo8ZG90cy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBhbW9ydGVuc2VuQGFyYm9yLm5l dD4gd3JvdGU6DQo+DQo+V2l0aCByZXNwZWN0IHRvIGhlYXJ0YmVhdHMgZ2VuZXJhbGx5LCBJIGRp c2N1c3NlZCBzaWduYWwgY2hhbm5lbCBoZWFsdGggYQ0KPmJpdCBpbiBteSBpbml0aWFsIHJvdWdo IHJlcXVpcmVtZW50cyBkcmFmdCBwcmlvciB0byB0aGUgbGFzdCBtZWV0aW5nOg0KPg0KPg0KPjxo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbW9ydGVuc2VuLXRocmVhdC1zaWduYWxp bmctcmVxdWlyZW1lbnRzDQo+LTAwI3NlY3Rpb24tMy4xLjE+DQo+DQo+DQo+SW4gbXkgdmlldywg YW55IHN1Y2Nlc3NmdWxseSBkZWxpdmVyZWQgbWVzc2FnZSBhY3RzIGFzIGEgaGVhcnRiZWF0Lg0K DQpJdCBzdHJpa2VzIG1lIHRoYXQgd2Ugc2hvdWxkIGFsbG93IGZvciBlaXRoZXIgZW5kIHRvIGlu aXRpYXRlIG9wZXJhdG9yDQp0cmlnZ2VyZWQgaGVhcnRiZWF0cyB0byBhY3QgYXMgYSBwaW5nIGFj cm9zcyB0aGUgc2lnbmFsIGNoYW5uZWwgdG8gYWlkIGluDQpwYXRoIHRyb3VibGVzaG9vdGluZy4g IEnigJltIGFsc28gaW5jbGluZWQgdG8gdGhpbmsgdGhhdCBwYWRkaW5nIG1heSBhbHNvIGJlDQph biBvcHRpb24gaW4gb3JkZXIgdG8gZW5zdXJlIGEgY29tcGxldGUgc2lnbmFsIHBhY2tldCBjYW4g YmUgZGVsaXZlcmVkDQpmcm9tIHRoZSBzaWduYWxlciB0byB0aGUgaGFuZGxlci4NCg0KVGhhbmtz LA0KDQotTmlrDQoNCg== From nobody Thu Sep 24 21:17:53 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9C0B1B3637 for ; Thu, 24 Sep 2015 21:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 pFaif1GW_mNG for ; Thu, 24 Sep 2015 21:17:49 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 A7C961B3126 for ; Thu, 24 Sep 2015 21:17:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 141506029B; Fri, 25 Sep 2015 00:17:47 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dyhFFdNglIYx; Fri, 25 Sep 2015 00:17:30 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.20]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 43A835FA40; Fri, 25 Sep 2015 00:17:26 -0400 (EDT) To: Roland Dobbins , dots@ietf.org References: <5603E6F4.5040407@htt-consult.com> <009901d0f6c9$8821cbc0$98656340$@jpshallow.com> <10e4a13c8d0a4cdcb76d38eb4f29aa3d@XCH-RCD-017.cisco.com> <560451D3.7080502@htt-consult.com> <560454E5.1070602@htt-consult.com> <5B01B3B3-826E-47D4-8D85-597823EBCA28@arbor.net> From: Robert Moskowitz Message-ID: <5604CAD1.9090602@htt-consult.com> Date: Fri, 25 Sep 2015 00:17:21 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <5B01B3B3-826E-47D4-8D85-597823EBCA28@arbor.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dots] How constrained due to attack congestion X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 04:17:51 -0000 On 09/24/2015 07:37 PM, Roland Dobbins wrote: > On 25 Sep 2015, at 2:54, Robert Moskowitz wrote: > >> Well I am consulting with one of the use case members... > > It would be good to consult with all of us. > > As has been noted both on this list and during the DOTS WG meeting in > Prague, both stateless and stateful transports are necessary. It's > unclear why this is being rehashed yet again. > > With regards to single-packet, the most basic DOTS supplicant request > should fit into one, yes. But there are additional desirable options > which would include multiple packets. I was not rehashing stateful/less. Rather what does constrained do to congested links mean and thus what are the requirements. But I have some things to go on now. From nobody Thu Sep 24 21:20:16 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 984261B363A for ; Thu, 24 Sep 2015 21:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 D3Pql0NxV6In for ; Thu, 24 Sep 2015 21:20:12 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 66B561B3639 for ; Thu, 24 Sep 2015 21:20:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 0F64E6029B; Fri, 25 Sep 2015 00:20:10 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id fn4cx1GQ19jW; Fri, 25 Sep 2015 00:20:03 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.20]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 105745FA40; Fri, 25 Sep 2015 00:19:58 -0400 (EDT) To: Christopher Morrow References: <5603E6F4.5040407@htt-consult.com> <009901d0f6c9$8821cbc0$98656340$@jpshallow.com> <10e4a13c8d0a4cdcb76d38eb4f29aa3d@XCH-RCD-017.cisco.com> <560451D3.7080502@htt-consult.com> From: Robert Moskowitz Message-ID: <5604CB69.5000403@htt-consult.com> Date: Fri, 25 Sep 2015 00:19:53 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Jon Shallow , "dots@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [Dots] How constrained due to attack congestion X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 04:20:14 -0000 On 09/24/2015 10:02 PM, Christopher Morrow wrote: > On Thu, Sep 24, 2015 at 3:41 PM, Robert Moskowitz > wrote: >> Not quite so if this goes into the requirements document. Of which Tiru, >> Andy, and I are the joint editors... >> >> "The protocol design needs to be cognizant of transmission limitations >> during an attack and minimize the number of datagrams and return >> acknowledgments to send to initiate a mitigation action." Is really vague >> but covers the concern. More meat would be good for the meal... > as a requirement: "Be stingy with network resources" seems ok, sure. I > don't think it's relevant if it's "during an attack" or not. > >> Or "If the controller has not heard a heartbeat (if supported) within a >> reasonable time, an attack may be underway and mitigation should be >> initiated." >> > yikes, that seems like a poor plan... what if my detector is simply > offline for reasons not related to dos? (power cycle, power problems > in that rack/row, 'bad hardware') > > > -chris > >> >> On 09/24/2015 02:54 PM, Christopher Morrow wrote: >>> this all sounds like 'bikeshedding' at this point... we don't yet (I >>> think) have 'what will be communicated' between the endpoints in >>> question. Once we agree on that, perhaps we can decide how to pack >>> 10lbs into the 5lb bag. >>> >>> The vast majority of 'oh crap, I'm under attack' problems are 'my >>> inbound link is full, holy crap!', so outbound traffic ought to 'just >>> work', presuming you don't require timely replies... >>> >>> anyway, it seems like we jumped ahead of ourselves, it's good to keep >>> in mind for later though. >>> >>> On Thu, Sep 24, 2015 at 11:14 AM, Tirumaleswar Reddy (tireddy) >>> wrote: >>>>> -----Original Message----- >>>>> From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow >>>>> Sent: Thursday, September 24, 2015 6:34 PM >>>>> To: dots@ietf.org >>>>> Subject: Re: [Dots] How constrained due to attack congestion >>>>> >>>>> Hi Rob, >>>>> >>>>> As I see this, the congested link can be in one of two directions (or >>>>> possibly >>>>> both). "Local" is signalling to "Remote" about what is happening. >>>>> >>>>> Direction Inbound Congestion. >>>>> Any protocol that requires an acknowledgement (e.g. TCP) will fail when >>>>> trying to send an outbound "Help Attack" message. As there is no >>>>> outbound >>>>> congestion, the "Help Attack" messages would not be constrained to a >>>>> minimal size, but, in my opinion, should be able to fit in a standard >>>>> packet >>>>> (see Protocols below). >>>>> >>>>> Direction Outbound Congestion >>>>> Any "Help Attack" message will not get through - but as this is >>>>> Outbound, >>>>> then the remote end cannot respond, but will be able to detect the lack >>>>> of >>>>> any "Heart Beat" messages getting through. The local end will need to >>>>> put >>>>> mitigation defences in place to stop the outbound congestion. >>>>> >>>>> Direction Both Congestion >>>>> The Outbound Congestion needs to be fixed locally. >>>>> >>>>> Protocols >>>>> This then leans towards the use of a protocol such as UDP for sending >>>>> "Help >>>>> Attack" messages. If this protocol has to have a security wrapper (most >>>>> would say yes), then any key exchange updates may not successfully take >>>>> place during this congestion period - thus there would have to be >>>>> support for >>>>> being able to use old keys during this congestion period. >>>> TLS session resumption without server-side state RFC5077 can possibly be >>>> used, but it still consumes 1 round trip before the "Help attack" message >>>> can be signaled. Another alternative is to go with TLS 1.3 which supports >>>> zero round-trip. >>>> >>>> -Tiru >>>> >>>>> Whether IPFix is the correct layer 7 protocol is open for debate. >>>>> >>>>> Regards >>>>> >>>>> Jon >>>>> >>>>> -----Original Message----- >>>>> From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Robert Moskowitz >>>>> Sent: 24 September 2015 13:05 >>>>> To: dots >>>>> Subject: [Dots] How constrained due to attack congestion >>>>> >>>>> One of the requirements for DOTS is to be able to message an attack >>>>> while >>>>> the attack is congesting the link. >>>>> >>>>> Are we going to put any measure on this or recommend any approach to >>>>> communicate over a constrained link. >>>>> >>>>> As I view where I am coming from on this, I have spent considerable time >>>>> down in IEEE 802.15 dealing with very constrained and lousy links. A >>>>> lot of >>>>> thought goes into what CAN be transmitted and to what degree of effort >>>>> is >>>>> made at what level to improve likelihood of success. >>>>> >>>>> To this end, do we recommend that the DOTS message about an attack MUST >>>>> fit wtihin a single datagram? And if so how do we count the bytes? >>>>> That is figure out the transmission overhead: TCP or UDP and what >>>>> security >>>>> envelope? >>>>> >>>>> Consider what CORE has done to design CoAP as a binary RESTful protocol >>>>> to >>>>> work over a constrained link. Is IPFix thus a good approach? >>>>> >>>>> Does anyone have any actual measurements of what size messages CAN get >>>>> through during an attack? So that one did not stick on the wall... :) From nobody Thu Sep 24 23:06:46 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E553E1B3678 for ; Thu, 24 Sep 2015 23:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 DoUcmLht3yz9 for ; Thu, 24 Sep 2015 23:06:43 -0700 (PDT) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 900871B3674 for ; Thu, 24 Sep 2015 23:06:43 -0700 (PDT) Received: by ykdg206 with SMTP id g206so104629792ykd.1 for ; Thu, 24 Sep 2015 23:06:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=s2L56NqndExtD8Bsam/qqYoTuBvJjOnEzmIk+8Gu8lc=; b=D7K82vreWwWuG9c7fLmtZDLYtgrRcfH/Zc+R82Vr1KX//b2Z7Sqc5lHa7qmeZnJzTK atiW/UU7LaxfsTyoWiXNxvpR/nTl1Nm8jiyTAEZQmnWE8ltwNUII6d9CWd0b6a2Mplha nsuPEggw2eDx718AbZF1v6msZ2ZwDy18/qex84pF3Lh+ZQOC0ipKcgFTxFPkHveOO8Y3 jKzPQbV0FhbYcoL4y0/XJVpnzM/jlAo5IdGUZjvI3PbkQj4DwqlPNZwrUoL4xs/F+9fP muO6pBoU2w+54DXRv92mRs8JNiou4QN3Fp4T0D05LUKscHzOGvPBJdFUY5bLrQ6jWxPb NeHQ== MIME-Version: 1.0 X-Received: by 10.129.107.138 with SMTP id g132mr3395575ywc.8.1443161202837; Thu, 24 Sep 2015 23:06:42 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.13.202.22 with HTTP; Thu, 24 Sep 2015 23:06:42 -0700 (PDT) In-Reply-To: <5604CB69.5000403@htt-consult.com> References: <5603E6F4.5040407@htt-consult.com> <009901d0f6c9$8821cbc0$98656340$@jpshallow.com> <10e4a13c8d0a4cdcb76d38eb4f29aa3d@XCH-RCD-017.cisco.com> <560451D3.7080502@htt-consult.com> <5604CB69.5000403@htt-consult.com> Date: Fri, 25 Sep 2015 02:06:42 -0400 X-Google-Sender-Auth: oDEOR3tmLn1yBa6FPJKXmREXgMs Message-ID: From: Christopher Morrow To: Robert Moskowitz Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Jon Shallow , "dots@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [Dots] How constrained due to attack congestion X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 06:06:45 -0000 On Fri, Sep 25, 2015 at 12:19 AM, Robert Moskowitz wrote: >>>>>> Consider what CORE has done to design CoAP as a binary RESTful >>>>>> protocol >>>>>> to >>>>>> work over a constrained link. Is IPFix thus a good approach? it's not clear (to me) what part ipfix has in the 'oh crap, attack!' message process, let's skip that for now. >>>>>> >>>>>> Does anyone have any actual measurements of what size messages CAN get >>>>>> through during an attack? > > > So that one did not stick on the wall... i've seen customers get 'far more than' 10gbps of traffic inbound to them and end up with essentially empty outbound link. So... in that case, with connectionless protocols the answer is: "full packets, almost at line rate" (not realistic to expect 'line rate', but... in the end there's lots of ways to mix this cake batter, but first: "What do you want to say, to whom, with credentials or not?" sorts of things really ought to get sorted out. From nobody Fri Sep 25 02:08:28 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2256C1A0093 for ; Fri, 25 Sep 2015 02:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham 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 8mPiEX4xsHr4 for ; Fri, 25 Sep 2015 02:08:26 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 182A11A0024 for ; Fri, 25 Sep 2015 02:08:25 -0700 (PDT) Received: by pablk4 with SMTP id lk4so3922265pab.3 for ; Fri, 25 Sep 2015 02:08:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-type; bh=/qEGizH+0E5vhb3JDs0bGaSmVDmEFHzF4bRbQnxIORk=; b=VEZMQ025S7349P8I3ZL6uVSLCizpHtx1Pto67QaaU6ipIrKyJQ3APoDNGxji9TFbdy FCL/NbsQd3RBecdI+1GrinSkR9fk/ftaCzwnwWtGKgkwObkZJZypmiGE73EngmvVCt5f TNp9FaOnKxQbTlx/ZMX7heN5aeDB06tCm5tMA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-type; bh=/qEGizH+0E5vhb3JDs0bGaSmVDmEFHzF4bRbQnxIORk=; b=Iqdv4rhM9UtzF9DTuidPkCJ5Ed7u3bz7Y5yM1bDglRpFL5AnCqsxDGjhjL7inQD8iT uy9PuC1dShP/JBKmOAFsgsPnzK90UV2FoGhKuoq/GKccusUbBMaPFGPy3KDsfYIYzcsS RKXNJfHov4LLNcj/ULRl/uL2T2teYIZ2VRxhkIH2XKRnoU8VxwBWj/taJUkdhwwl75gd ONk8UFGd6SCWStVsLDL0ft5+Rfc5EMV8rEEVkpY+aKAjAz6OPY7aec2UbKU2+iMaI4qJ xL6RkeW6Uk2se5fsmMZoTcreUo44GO+2LjaAI1DwJ2wlQrmizxEViSR8XN/3Vl9bDASN 3Rig== X-Gm-Message-State: ALoCoQmc80ZyHj/Gzbc/VXuk5taqgiv3yfsrSOf618dBy95AGiomy/vgDmvmDRIMpIcgRRhp1p/l X-Received: by 10.68.114.34 with SMTP id jd2mr5915994pbb.94.1443172105383; Fri, 25 Sep 2015 02:08:25 -0700 (PDT) Received: from [172.19.254.145] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id x6sm2791253pbt.3.2015.09.25.02.08.23 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 25 Sep 2015 02:08:24 -0700 (PDT) From: "Roland Dobbins" To: dots@ietf.org Date: Fri, 25 Sep 2015 16:08:21 +0700 Message-ID: <58D4C421-7306-499D-BD22-7A3F571D8C31@arbor.net> In-Reply-To: <56049960.8070702@mti-systems.com> References: <5603E6F4.5040407@htt-consult.com> <009901d0f6c9$8821cbc0$98656340$@jpshallow.com> <10e4a13c8d0a4cdcb76d38eb4f29aa3d@XCH-RCD-017.cisco.com> <560451D3.7080502@htt-consult.com> <56049960.8070702@mti-systems.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Subject: Re: [Dots] How constrained due to attack congestion X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 09:08:27 -0000 On 25 Sep 2015, at 7:46, Gilbert Clark wrote: > I would think heartbeats should therefore never be used (on their own) > to trigger an automated mitigation. Normally, I would agree. However, this is an implementation decision and has nothing to do with the DOTS protocol itself. ----------------------------------- Roland Dobbins From nobody Fri Sep 25 02:09:24 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AAE21A00FA for ; Fri, 25 Sep 2015 02:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham 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 dDA5hK7zpt1u for ; Fri, 25 Sep 2015 02:09:22 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 389D31A0024 for ; Fri, 25 Sep 2015 02:09:22 -0700 (PDT) Received: by padhy16 with SMTP id hy16so100861417pad.1 for ; Fri, 25 Sep 2015 02:09:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; bh=poHox5LgtHC0e8DSYYu94XXZBQBJyI/ZFbad+h5Zrg8=; b=dAdwKv21ymj7NEeuNh2bC2MpnUByVw1WkR7h/TMmZObX8PY3iMN/Tl6socZMqrQy+3 RR0p88WjhfE29xdz34vLjbkP8y3dgdPHfrSeYpgoMBLRyLKuPXrzM3O6+bOWwhzVCrQ2 AUuJ9VUU49XtX3qAF9biirTxTYq1g6yst/Um8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=poHox5LgtHC0e8DSYYu94XXZBQBJyI/ZFbad+h5Zrg8=; b=hMb/iFrLUE/YgeBtskEl+rl8OHLfTF5op2UtuLl0+V4p1HsevlmwtgVrsXDXre1m6V tLhFjJh1DE1qkP2IHnTo+BRQQTZytZqMeDjYB28qcykuyzlY8BfqA6ByPL1UYl9tQ7kl JpaeuYYkBe+2fI6qUpM4lkNxXnG5r/2Ff37qJo32YM231UoieHSU7IYSjuzLPQA4YgHW u9KjYl7lrGhdQP1HlivUZlUPWYLB+B+gnlmXv2XsDTGs4WPXrIHHc7417J6kQXZH5SHZ ms9ZgTgYnkoYv08E+GiGR0a2Aa5Awfa5AcYpItiPEA3vR5bVvhF/BdDpnNs8SVBchikY d2Bw== X-Gm-Message-State: ALoCoQmqEIasNSAgaGXpxTuowx6A8TBHNskQGFRW9XbwiEtPwPQ52Sit7VQYNX38d1d/Mzj/DJuV X-Received: by 10.66.102.74 with SMTP id fm10mr5665499pab.151.1443172161900; Fri, 25 Sep 2015 02:09:21 -0700 (PDT) Received: from [172.19.254.145] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id a17sm2775254pbu.55.2015.09.25.02.09.20 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 25 Sep 2015 02:09:21 -0700 (PDT) From: "Roland Dobbins" To: dots Date: Fri, 25 Sep 2015 16:09:17 +0700 Message-ID: <5B5DF29E-22A2-4705-B688-AAADC0A00784@arbor.net> In-Reply-To: References: <5603E6F4.5040407@htt-consult.com> <009901d0f6c9$8821cbc0$98656340$@jpshallow.com> <10e4a13c8d0a4cdcb76d38eb4f29aa3d@XCH-RCD-017.cisco.com> <560451D3.7080502@htt-consult.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.2r5107) Archived-At: Subject: Re: [Dots] Heartbeat requirements (was: How constrained due to attack congestion) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 09:09:23 -0000 On 25 Sep 2015, at 11:00, Teague, Nik wrote: > It strikes me that we should allow for either end to initiate operator > triggered heartbeats to act as a ping across the signal channel to aid in > path troubleshooting Triggered re-registration can serve this purpose. > . I’m also inclined to think that padding may also be > an option in order to ensure a complete signal packet can be delivered > from the signaler to the handler. Concur. ----------------------------------- Roland Dobbins From nobody Fri Sep 25 02:10:39 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5581A00FA for ; Fri, 25 Sep 2015 02:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham 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 kj2SvHOVg6Fs for ; Fri, 25 Sep 2015 02:10:36 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DD721A00EE for ; Fri, 25 Sep 2015 02:10:36 -0700 (PDT) Received: by pablk4 with SMTP id lk4so3976195pab.3 for ; Fri, 25 Sep 2015 02:10:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-type; bh=mNTiv+ot13uZTGgTZ5sOwc4oX4Bs06PRB0ZjWg5rj+s=; b=XZgaaY97TaLyvPlFRwdAQK11zIfBTZ9e2VRXs1RyYNUOM//yykYEn2QyzoDTJSRqDf rx/EmE/T/wZRj15/eTiUis3mOCIyze2IXAQS79OzRrQ2KIuIPAnIZh6F7w8Mqk0JNkeL 4Lqoc+wRMRrzG5+kZEDHNdA0sl2Uhv/tgUHtI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-type; bh=mNTiv+ot13uZTGgTZ5sOwc4oX4Bs06PRB0ZjWg5rj+s=; b=I8v5AF8Z2ng10zgw9U6b0Ei4PsxLMtIerRbRdmuUJGRJm1x4AaP6DQeCXvRXo4RK0A dI4JCRmorpd/H4gWDZbu0urPL/R2rRjiez/YdnCOkN/GkSB2Lie8weDX071T4d/daLRd /Hv0laT1r2cR9Ni2fCzqx49J+q+l/y1ZyFL0qZLWhH9d1oXNiX48yf8exy2GZr7Rqs7L bz9SeI9dP01R7ej1TxrelA/i2erqjEZljmD+e/DVvi6C6jGwT8v7P6HPH5/PE5zdfz3q PxxsPi9aO4XRoJSVEvltgbzplNqNL+gf7KrvOBoCk/7MMkeLy3vyMLdMbBO2zTBy6ig4 7unQ== X-Gm-Message-State: ALoCoQnU5z2toBbCHH78xiQLBztaQJutSPQb88938kyqJjJAGrM1myNdarYAO2P7K4Yx3Ceb7uoO X-Received: by 10.67.22.169 with SMTP id ht9mr5813469pad.35.1443172236015; Fri, 25 Sep 2015 02:10:36 -0700 (PDT) Received: from [172.19.254.145] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id fm5sm2799905pab.24.2015.09.25.02.10.34 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 25 Sep 2015 02:10:35 -0700 (PDT) From: "Roland Dobbins" To: dots@ietf.org Date: Fri, 25 Sep 2015 16:10:31 +0700 Message-ID: <99301368-EAE8-4515-9EBB-31390BB081CB@arbor.net> In-Reply-To: <5604CAD1.9090602@htt-consult.com> References: <5603E6F4.5040407@htt-consult.com> <009901d0f6c9$8821cbc0$98656340$@jpshallow.com> <10e4a13c8d0a4cdcb76d38eb4f29aa3d@XCH-RCD-017.cisco.com> <560451D3.7080502@htt-consult.com> <560454E5.1070602@htt-consult.com> <5B01B3B3-826E-47D4-8D85-597823EBCA28@arbor.net> <5604CAD1.9090602@htt-consult.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Subject: Re: [Dots] How constrained due to attack congestion X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 09:10:37 -0000 On 25 Sep 2015, at 11:17, Robert Moskowitz wrote: > Rather what does constrained do to congested links mean and thus what > are the requirements. It's highly situationally-specific. Retry beaconing until supplicant status change is the answer for this. ----------------------------------- Roland Dobbins From nobody Fri Sep 25 06:11:46 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB741A0252 for ; Fri, 25 Sep 2015 06:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham 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 ti5nMwTfVwR9 for ; Fri, 25 Sep 2015 06:11:43 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.9]) (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 A76E31A0250 for ; Fri, 25 Sep 2015 06:11:41 -0700 (PDT) Received: from [216.82.250.19] by server-9.bemta-12.messagelabs.com id ED/9A-04874-C0845065; Fri, 25 Sep 2015 13:11:40 +0000 X-Env-Sender: Stefan.Fouant@corero.com X-Msg-Ref: server-10.tower-87.messagelabs.com!1443186694!30415765!1 X-Originating-IP: [71.184.227.49] X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17266 invoked from network); 25 Sep 2015 13:11:35 -0000 Received: from mercury.corero.com (HELO MERCURY.corero.com) (71.184.227.49) by server-10.tower-87.messagelabs.com with AES128-SHA encrypted SMTP; 25 Sep 2015 13:11:35 -0000 Received: from MERCURY.corero.com ([fe80::2c05:6b26:abe2:ad24]) by MERCURY.corero.com ([fe80::2c05:6b26:abe2:ad24%19]) with mapi id 14.03.0248.002; Fri, 25 Sep 2015 09:11:34 -0400 From: Stefan Fouant To: Christopher Morrow , Robert Moskowitz Thread-Topic: [Dots] How constrained due to attack congestion Thread-Index: AQHQ9sFRB9t5g/y4ekyGeb27kJH2Qp5L6JoAgAAkZYCAAD2BgIAADPSAgABqfACAACZ1gIAAHdgAgAAzpQA= Date: Fri, 25 Sep 2015 13:11:33 +0000 Message-ID: References: <5603E6F4.5040407@htt-consult.com> <009901d0f6c9$8821cbc0$98656340$@jpshallow.com> <10e4a13c8d0a4cdcb76d38eb4f29aa3d@XCH-RCD-017.cisco.com> <560451D3.7080502@htt-consult.com> <5604CB69.5000403@htt-consult.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.59.78] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Jon Shallow , "dots@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [Dots] How constrained due to attack congestion X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 13:11:45 -0000 On 9/25/15, 2:06 AM, "Dots on behalf of Christopher Morrow" wrote: > >i've seen customers get 'far more than' 10gbps of traffic inbound to >them and end up with essentially empty outbound link. So... in that >case, with connectionless protocols the answer is: "full packets, >almost at line rate" (not realistic to expect 'line rate', but... > >in the end there's lots of ways to mix this cake batter, but first: >"What do you want to say, to whom, with credentials or not?" sorts of >things really ought to get sorted out. Another thing we may want to consider, almost all networking vendors worth their salt allocate by default ~5% of bandwidth to Network Control via precedence bit 111. Tagging DOTS signaling as such could ensure delivery even in periods of high congestion (assuming end user has done nothing to change classifications and schedulers). Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI, CISSP Senior Security Engineer Corero Network Security Mobile: +1.703.625.6243 From nobody Fri Sep 25 06:24:08 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B70101A0318 for ; Fri, 25 Sep 2015 06:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 qEF4vRptFd4C for ; Fri, 25 Sep 2015 06:23:58 -0700 (PDT) Received: from mail-qg0-f100.google.com (mail-qg0-f100.google.com [209.85.192.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D36DF1A034C for ; Fri, 25 Sep 2015 06:23:57 -0700 (PDT) Received: by qgt47 with SMTP id 47so5519705qgt.0 for ; Fri, 25 Sep 2015 06:23:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:user-agent:content-type:content-id :content-transfer-encoding:mime-version; bh=61+9+TsoCNO5xzpAy6uQg/G2g+KOgkiO2RZ9qK7D3bY=; b=BAM1vROUaI4UYlmlOKFtE+sHU8DxEyekoZ76MEQmBapAevI1EkiUG9nr4R7eG6JTWw Du7PXEnRFQmPGJ+rp9plmO1zvxohYmZ5WLjWu4n9UscenModnv+seRVUnlq6RYxFMFoe J+YNMyZLC0MuMUgCAQLvJfTnWscXOsrSlo0NE6K/0W3OAOSXNHiuqVCLx1/CcTXM0nYK zy2eN5m7Eqicp6m471eYql0/lP42Wa+YZ9g0JvURlmYSCEjK34RpXfaIDRjYD9QXgzLZ m7BEs3919LP4pe9amLE3NVyH3Xk49wPzzWIyv9GvGc4r9eN1h/czildHm1ZG/xMM8Cxc amDQ== X-Gm-Message-State: ALoCoQlJChFIdyNnB/TQQoHZhOxzKYPg0VYl3tIEFQFlK757NIuNPBrx08Oor6zhaU8aUgEkDdRTXatXixZk9leXBD31GeQvEA== X-Received: by 10.140.41.81 with SMTP id y75mr5986529qgy.5.1443187436946; Fri, 25 Sep 2015 06:23:56 -0700 (PDT) Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by smtp-relay.gmail.com with ESMTPS id b67sm321110qka.7.2015.09.25.06.23.56 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 25 Sep 2015 06:23:56 -0700 (PDT) X-Relaying-Domain: verisign.com Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01 [10.173.152.205]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id t8PDNtFf030108 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Sep 2015 09:23:56 -0400 Received: from BRN1WNEXMBX02.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Fri, 25 Sep 2015 09:23:54 -0400 From: "Teague, Nik" To: Stefan Fouant , Christopher Morrow , Robert Moskowitz Thread-Topic: [Dots] How constrained due to attack congestion Thread-Index: AQHQ9sFRq3pPp6SNCkm1bHsV37fwLJ5L6JoAgAAkZYCAAD2BgIAADPSAgABqfACAACZ1gIAAHdgAgAB2tID//8BlAA== Date: Fri, 25 Sep 2015 13:23:53 +0000 Message-ID: References: <5603E6F4.5040407@htt-consult.com> <009901d0f6c9$8821cbc0$98656340$@jpshallow.com> <10e4a13c8d0a4cdcb76d38eb4f29aa3d@XCH-RCD-017.cisco.com> <560451D3.7080502@htt-consult.com> <5604CB69.5000403@htt-consult.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.5.150821 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="utf-8" Content-ID: <71DAD2A56F0A11418427867DB76C7861@verisign.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Jon Shallow , "dots@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [Dots] How constrained due to attack congestion X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 13:24:06 -0000 SGksDQoNCk9uIDI1LzA5LzIwMTUgMDk6MTEsICJEb3RzIG9uIGJlaGFsZiBvZiBTdGVmYW4gRm91 YW50Ig0KPGRvdHMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgU3RlZmFuLkZvdWFudEBj b3Jlcm8uY29tPiB3cm90ZToNCg0KPkFub3RoZXIgdGhpbmcgd2UgbWF5IHdhbnQgdG8gY29uc2lk ZXIsIGFsbW9zdCBhbGwgbmV0d29ya2luZyB2ZW5kb3JzIHdvcnRoDQo+dGhlaXIgc2FsdCBhbGxv Y2F0ZSBieSBkZWZhdWx0IH41JSBvZiBiYW5kd2lkdGggdG8gTmV0d29yayBDb250cm9sIHZpYQ0K PnByZWNlZGVuY2UgYml0IDExMS4gVGFnZ2luZyBET1RTIHNpZ25hbGluZyBhcyBzdWNoIGNvdWxk IGVuc3VyZSBkZWxpdmVyeQ0KPmV2ZW4gaW4gcGVyaW9kcyBvZiBoaWdoIGNvbmdlc3Rpb24gKGFz c3VtaW5nIGVuZCB1c2VyIGhhcyBkb25lIG5vdGhpbmcgdG8NCj5jaGFuZ2UgY2xhc3NpZmljYXRp b25zIGFuZCBzY2hlZHVsZXJzKS4NCg0KSXQgYWxzbyBhc3N1bWVzIHRoYXQgbm8gYmxlYWNoaW5n IG9jY3VycyBzbyB3b3VsZCBub3QgYmUgYXNzdXJlZCB0bw0Kc3Vydml2ZSBuZXR3b3JrIGJvdW5k YXJpZXMuDQoNClRoYW5rcywNCg0KLU5paw0KDQo= From nobody Fri Sep 25 06:24:38 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6871A036A for ; Fri, 25 Sep 2015 06:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham 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 eJa0XDiLw9V3 for ; Fri, 25 Sep 2015 06:24:29 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61E9E1A0364 for ; Fri, 25 Sep 2015 06:24:29 -0700 (PDT) Received: by pacex6 with SMTP id ex6so106077975pac.0 for ; Fri, 25 Sep 2015 06:24:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-type; bh=3VPr0v/AKNcJAj4pKkK+FXlQ1ib+J0coIbxJSGFgqSk=; b=XhWA6xfNNqfaUZ55gaKK3E5QzuJo6pdXWVp5h1pCWgo/n3CpdfgWxnHMkD+QkENPK7 1XSAFawiRykK/thJfu+ySiTpyd5v2vN77EtL+mU705BiiAnDZVPn538PANCRNEzuCUdG ixYxLyjwYMsoKAtFaQ+ie2nBUZyAASmfu5Z9I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-type; bh=3VPr0v/AKNcJAj4pKkK+FXlQ1ib+J0coIbxJSGFgqSk=; b=TST1ku/BPleY1Zu/WGymgvG15R5NfllVrMNb4RWovs1A9w4w8CyeqhBAHoPpWhpSEJ PTAwhO0zoJvYOtVPubndj0t+4ViOrFJBkBFa0Qy6ZRG3WSSJAzXCVuU8KyHWAzzSq6x2 0bm5EFEN55c+5mxSsKTuwpNEXcxz70zBJf1soz9YkCq59m5OHjqUwitNLxH6o//LKsNt 8JWN2PCMLtJfoObvfdqCCC7rB9OMUEjKoXCyhYQOTQ+04zTefJm/cbLz/VpFYmEEK5bL nMN0AvwffSjDy6SJ1mQPeGg1vQ4S07eQSS2qfyX6YW+3FBOwiEahNys7s70RtfUgnCqH hMoQ== X-Gm-Message-State: ALoCoQmxuuPhY/GHOLGfVm0eYZfqKdxDECzcWCdRXeLmK9wsMr/PFu9CQnkckjMWs3vHi28ZsvAM X-Received: by 10.68.68.233 with SMTP id z9mr7326606pbt.132.1443187468844; Fri, 25 Sep 2015 06:24:28 -0700 (PDT) Received: from [172.19.254.145] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id si1sm4026383pbc.72.2015.09.25.06.24.26 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 25 Sep 2015 06:24:27 -0700 (PDT) From: "Roland Dobbins" To: dots Date: Fri, 25 Sep 2015 20:24:24 +0700 Message-ID: <4AFECE15-2992-44B8-9B6D-ABB3CF40233B@arbor.net> In-Reply-To: References: <5603E6F4.5040407@htt-consult.com> <009901d0f6c9$8821cbc0$98656340$@jpshallow.com> <10e4a13c8d0a4cdcb76d38eb4f29aa3d@XCH-RCD-017.cisco.com> <560451D3.7080502@htt-consult.com> <5604CB69.5000403@htt-consult.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Subject: Re: [Dots] How constrained due to attack congestion X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 13:24:34 -0000 On 25 Sep 2015, at 20:11, Stefan Fouant wrote: > Tagging DOTS signaling as such could ensure delivery even in periods > of high congestion (assuming end user has done nothing to change > classifications and schedulers). The BCP is to re-color on ingress, and we certainly don't want to interfere with control-plane traffic in high-congestion situations, thereby contributing to an outage. Instead, one of our deployment recommendations should be to utilize QoS where/when available to reserve appropriate headroom for DOTS signaling. Same idea, but under the control of the respective operators. ----------------------------------- Roland Dobbins From nobody Fri Sep 25 06:28:21 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE2091A0318 for ; Fri, 25 Sep 2015 06:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham 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 JVL-9SQjICSq for ; Fri, 25 Sep 2015 06:28:18 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD52E1A0264 for ; Fri, 25 Sep 2015 06:28:18 -0700 (PDT) Received: by pacex6 with SMTP id ex6so106153333pac.0 for ; Fri, 25 Sep 2015 06:28:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-type; bh=FDHHaEgkYIr5mBl8JJei3r3dtrhUe/xl57WIpWKduws=; b=TfCzqNhuTJcZhsuIuStKRdTdDgAkWUVkxTtPOd5N/8DR52GMbNYcUraff/u+8FWVd9 /r1x0fAMiEtHOhFLnSexfrr5Ffe+kIgf3/dwkEoVX5SRMlLhp2tP5ZGZr5gKEJ+5IJDM gdXb61r9HbezcDbjQLxIh9qqMXti41tIV5yMg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-type; bh=FDHHaEgkYIr5mBl8JJei3r3dtrhUe/xl57WIpWKduws=; b=UWcikrcQvANLvc7w9HhfP4ffDss5+VuSscX0R6hnyE+8njoOzPur6udtuQloZR2u2z wr3J/z55j1Iu2StzDZEXStITcNTwMywL1nWo0PvUlUz0W/Tw1b0JWLkSOn77KXXOYr5Y 0ipyCMPhjUMF/WUCaI/BWCoWlYESJpQfOWhMt/piXcky6OihW8F7X00PYYlO4QWj37L1 u4Rate+npWgmMbKYA7As/SfwioMOyqS3Jc3b6IDkIy79sv0xKC8ktFfNYe1TfseqVtI9 ifgxSTDb2eh5yO+frDbnuERDt7hT3PhPRBkketAV+CLjILKIZNE8UUS+xOXY2rRjGXOU U/4A== X-Gm-Message-State: ALoCoQkZZKV5xJxMKJMQt3Ib3rs+tZjrg5ikkn/PprUQIUI4cTFy8Ly0dNkYvpRxvp5HdBA0dSg/ X-Received: by 10.66.141.165 with SMTP id rp5mr7150379pab.127.1443187698379; Fri, 25 Sep 2015 06:28:18 -0700 (PDT) Received: from [172.19.254.145] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id k10sm4038289pbq.78.2015.09.25.06.28.17 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 25 Sep 2015 06:28:17 -0700 (PDT) From: "Roland Dobbins" To: dots Date: Fri, 25 Sep 2015 20:28:14 +0700 Message-ID: <89AAB9D6-2296-4E83-BCBE-3F9474B8D261@arbor.net> In-Reply-To: <4AFECE15-2992-44B8-9B6D-ABB3CF40233B@arbor.net> References: <5603E6F4.5040407@htt-consult.com> <009901d0f6c9$8821cbc0$98656340$@jpshallow.com> <10e4a13c8d0a4cdcb76d38eb4f29aa3d@XCH-RCD-017.cisco.com> <560451D3.7080502@htt-consult.com> <5604CB69.5000403@htt-consult.com> <4AFECE15-2992-44B8-9B6D-ABB3CF40233B@arbor.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Subject: Re: [Dots] How constrained due to attack congestion X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 13:28:20 -0000 On 25 Sep 2015, at 20:24, Roland Dobbins wrote: > Instead, one of our deployment recommendations should be to utilize > QoS where/when available to reserve appropriate headroom for DOTS > signaling. Same idea, but under the control of the respective > operators. Note that this is in the absence of an out-of-band signaling channel, which is the ideal, but which sadly is going to be available in a minority of deployments. We should recommend out-of-band where/when feasible, of course. ----------------------------------- Roland Dobbins From nobody Fri Sep 25 06:29:11 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 623DB1A0318 for ; Fri, 25 Sep 2015 06:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham 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 mfMhDGx4R8hQ for ; Fri, 25 Sep 2015 06:29:04 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.15]) (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 80AEE1A033B for ; Fri, 25 Sep 2015 06:29:04 -0700 (PDT) Received: from [216.82.250.179] by server-15.bemta-12.messagelabs.com id 5E/AF-09905-02C45065; Fri, 25 Sep 2015 13:29:04 +0000 X-Env-Sender: Stefan.Fouant@corero.com X-Msg-Ref: server-6.tower-210.messagelabs.com!1443187742!41104725!1 X-Originating-IP: [71.184.227.49] X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11716 invoked from network); 25 Sep 2015 13:29:03 -0000 Received: from mercury.corero.com (HELO MERCURY.corero.com) (71.184.227.49) by server-6.tower-210.messagelabs.com with AES128-SHA encrypted SMTP; 25 Sep 2015 13:29:03 -0000 Received: from MERCURY.corero.com ([fe80::2c05:6b26:abe2:ad24]) by MERCURY.corero.com ([fe80::2c05:6b26:abe2:ad24%19]) with mapi id 14.03.0248.002; Fri, 25 Sep 2015 09:29:02 -0400 From: Stefan Fouant To: "Teague, Nik" , Christopher Morrow , Robert Moskowitz Thread-Topic: [Dots] How constrained due to attack congestion Thread-Index: AQHQ9sFRB9t5g/y4ekyGeb27kJH2Qp5L6JoAgAAkZYCAAD2BgIAADPSAgABqfACAACZ1gIAAHdgAgAAzpQCAAEaBgP//vmGA Date: Fri, 25 Sep 2015 13:29:02 +0000 Message-ID: References: <5603E6F4.5040407@htt-consult.com> <009901d0f6c9$8821cbc0$98656340$@jpshallow.com> <10e4a13c8d0a4cdcb76d38eb4f29aa3d@XCH-RCD-017.cisco.com> <560451D3.7080502@htt-consult.com> <5604CB69.5000403@htt-consult.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.59.78] Content-Type: text/plain; charset="us-ascii" Content-ID: <02D27C823582C54A9B2A05B8075A990C@corero.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Jon Shallow , "dots@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [Dots] How constrained due to attack congestion X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 13:29:10 -0000 On 9/25/15, 9:23 AM, "Teague, Nik" wrote: >Hi, > >On 25/09/2015 09:11, "Dots on behalf of Stefan Fouant" > wrote: > >>Another thing we may want to consider, almost all networking vendors >>worth >>their salt allocate by default ~5% of bandwidth to Network Control via >>precedence bit 111. Tagging DOTS signaling as such could ensure delivery >>even in periods of high congestion (assuming end user has done nothing to >>change classifications and schedulers). > >It also assumes that no bleaching occurs so would not be assured to >survive network boundaries. Very true, as many network operators do clear and/or reclassify code points at the edge of their network. However, in this case all we are concerned with is ensuring the scheduler on the outbound link from CPE or similar device will treat such traffic with higher priority so as to get the signal out in face of congested resources. Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI, CISSP Senior Security Engineer Corero Network Security Mobile: +1.703.625.6243 From nobody Fri Sep 25 06:48:13 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5242F1A19E3 for ; Fri, 25 Sep 2015 06:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham 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 0dQ11ZxNM1gA for ; Fri, 25 Sep 2015 06:48:07 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37E0F1A0AF1 for ; Fri, 25 Sep 2015 06:48:07 -0700 (PDT) Received: by pablk4 with SMTP id lk4so9765423pab.3 for ; Fri, 25 Sep 2015 06:48:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-type; bh=f/SIVybU4A/hR4yteE8gLHolnpFob//MNWM5p8n93CA=; b=VbLs3bQuuBAdeAdqDfP20JKIoCtEG3V6XXigfixtWxsvnWnE3loDkvKjtqLSzpwN6p CTe1B6sqibIF9TF8nuAougYzbj5WafWSnDMtqeEMO4qGQbiKU+f0kH3X1BR9CX2NaXst gM3Ipeb6MKLjnzYXwdimcfqjO0lbnS1ljzePc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-type; bh=f/SIVybU4A/hR4yteE8gLHolnpFob//MNWM5p8n93CA=; b=VMMzXh/QxvQndXuh3qgFgzx6kFWZVEzoriI8S/Mmm5n5vxYQiKsKHsr5IuuoUkImzd Frza//TeATFWC5ZG3YgRRMLDdbGiPJauviJt6MHgRmIraGEubaJABu6TU3znGtDw30XQ sc1VT+BQWsnvO9raA1rGLrjtTRisW3V0j6Js2WE/TuHTe8+NqWLGgpI8mjhPGXYduJKj m6h5HnKcmxQwFJxIVtIrBEMeelPHRoFEr5it9Xf8Xg/DI7DI/wJmXT0Z8AfwwflH/aJu Ro3tDCtCh5ynw12zkUq32diPYXBxeEUZqr2jZFdWbq9EX6sxMWD7lQFrS5N6vE3wYheR 3r6w== X-Gm-Message-State: ALoCoQmQehjZQG3nMQREhAH5ii74qIzE6czMVEMyJp4PKmkohgzniWTqWNZOGLCU9nlzNtXEZWhx X-Received: by 10.66.100.168 with SMTP id ez8mr7342473pab.142.1443188886707; Fri, 25 Sep 2015 06:48:06 -0700 (PDT) Received: from [172.19.254.145] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id ql5sm4144887pac.46.2015.09.25.06.48.04 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 25 Sep 2015 06:48:05 -0700 (PDT) From: "Roland Dobbins" To: dots Date: Fri, 25 Sep 2015 20:48:02 +0700 Message-ID: In-Reply-To: References: <5603E6F4.5040407@htt-consult.com> <009901d0f6c9$8821cbc0$98656340$@jpshallow.com> <10e4a13c8d0a4cdcb76d38eb4f29aa3d@XCH-RCD-017.cisco.com> <560451D3.7080502@htt-consult.com> <5604CB69.5000403@htt-consult.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Subject: Re: [Dots] How constrained due to attack congestion X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 13:48:11 -0000 On 25 Sep 2015, at 20:29, Stefan Fouant wrote: > However, in this case all we are concerned with is ensuring the > scheduler on the outbound link from CPE or > similar device will treat such traffic with higher priority so as to > get > the signal out in face of congested resources. Again, the correct way to achieve this goal is via QoS. We must not abuse precedence values. ----------------------------------- Roland Dobbins From nobody Fri Sep 25 06:56:53 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDB531A1A2F for ; Fri, 25 Sep 2015 06:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 3bKB0dFHBllj for ; Fri, 25 Sep 2015 06:56:50 -0700 (PDT) Received: from mail-qg0-f97.google.com (mail-qg0-f97.google.com [209.85.192.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 358E11A1A06 for ; Fri, 25 Sep 2015 06:56:50 -0700 (PDT) Received: by qgev79 with SMTP id v79so5560960qge.3 for ; Fri, 25 Sep 2015 06:56:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:user-agent:content-type:content-id :content-transfer-encoding:mime-version; bh=6Pvz3kjdVMdkGt5mlpwqu73cikALdX0VK2DN1EGh698=; b=Tl3ot8SE0AvnBfFeWbk5TRvpBWhijU9cpVCUHpsB4FcFg2epF9IHxe9zTOUuKN39Xo 1nGLCjnNWMlhBEVZBdr/vcY78WwkB+A+IbTm9R4iIxB4VvFuCGfOFOAwS5tgj82WbDi0 RqQLe6VRSJ3plfYpLoRELjSiqmxORACiiVTDnME/pkb7pqhy82C8yUXC86uUq32cje07 33NiZXDi+TNB0QDUIpnnXjE9TUN8MiSqlhWKuWr/72OZffHOi3BWeEL2bNnMPjYj5Vz/ AL81jaWG2k7QTbqIpPlTK6MBUaz9aV1R3VwCQHhWbkDGFXSE8iCacyjztY+FOsLzJ2GS cVRQ== X-Gm-Message-State: ALoCoQkZberc8eX7lZ8kD2g9qHmqE7p1aGK7KSoIeWzjHi98h6r2NSIx5APpgtzPbI6DQbkEtb+4WngwqSGFbkUrESwew+2SGQ== X-Received: by 10.140.131.135 with SMTP id 129mr6742445qhd.31.1443189409389; Fri, 25 Sep 2015 06:56:49 -0700 (PDT) Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by smtp-relay.gmail.com with ESMTPS id m12sm339792qki.0.2015.09.25.06.56.49 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 25 Sep 2015 06:56:49 -0700 (PDT) X-Relaying-Domain: verisign.com Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01 [10.173.152.205]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id t8PDumNh025919 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Sep 2015 09:56:48 -0400 Received: from BRN1WNEXMBX02.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Fri, 25 Sep 2015 09:56:48 -0400 From: "Teague, Nik" To: Stefan Fouant , Christopher Morrow , Robert Moskowitz Thread-Topic: [Dots] How constrained due to attack congestion Thread-Index: AQHQ9sFRq3pPp6SNCkm1bHsV37fwLJ5L6JoAgAAkZYCAAD2BgIAADPSAgABqfACAACZ1gIAAHdgAgAB2tID//8BlAIAARH4A///EsQA= Date: Fri, 25 Sep 2015 13:56:47 +0000 Message-ID: References: <5603E6F4.5040407@htt-consult.com> <009901d0f6c9$8821cbc0$98656340$@jpshallow.com> <10e4a13c8d0a4cdcb76d38eb4f29aa3d@XCH-RCD-017.cisco.com> <560451D3.7080502@htt-consult.com> <5604CB69.5000403@htt-consult.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.5.150821 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Jon Shallow , "dots@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [Dots] How constrained due to attack congestion X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 13:56:52 -0000 SGksDQoNCk9uIDI1LzA5LzIwMTUgMDk6MjksICJTdGVmYW4gRm91YW50IiA8U3RlZmFuLkZvdWFu dEBjb3Jlcm8uY29tPiB3cm90ZToNCg0KPlZlcnkgdHJ1ZSwgYXMgbWFueSBuZXR3b3JrIG9wZXJh dG9ycyBkbyBjbGVhciBhbmQvb3IgcmVjbGFzc2lmeSBjb2RlDQo+cG9pbnRzIGF0IHRoZSBlZGdl IG9mIHRoZWlyIG5ldHdvcmsuIEhvd2V2ZXIsIGluIHRoaXMgY2FzZSBhbGwgd2UgYXJlDQo+Y29u Y2VybmVkIHdpdGggaXMgZW5zdXJpbmcgdGhlIHNjaGVkdWxlciBvbiB0aGUgb3V0Ym91bmQgbGlu ayBmcm9tIENQRSBvcg0KPnNpbWlsYXIgZGV2aWNlIHdpbGwgdHJlYXQgc3VjaCB0cmFmZmljIHdp dGggaGlnaGVyIHByaW9yaXR5IHNvIGFzIHRvIGdldA0KPnRoZSBzaWduYWwgb3V0IGluIGZhY2Ug b2YgY29uZ2VzdGVkIHJlc291cmNlcy4NCg0KSSB3b3VsZCBuZWVkIGEgbG90IG9mIGFzc3VyYW5j ZXMgdGhhdCBWZW5kb3IgWCB3YXMgZ29pbmcgdG8gcGxheSBuaWNlIHdpdGgNCm15IHByb3RlY3Rl ZCBOQyByZXNvdXJjZXMuICBJIGFncmVlIHdpdGggdGhlIHZpZXcgdGhhdCB0aGlzIHNob3VsZCBi ZQ0KbWFuYWdlZCBieSB0aGUgb3BlcmF0b3IgdG8gZGVjaWRlIG9uIHRoZWlyIG5ldHdvcmsuDQoN ClRoYW5rcywNCg0KLU5paw0KDQo= From nobody Fri Sep 25 07:01:56 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 817931A1A5D for ; Fri, 25 Sep 2015 07:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham 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 x7dtnkMriOJm for ; Fri, 25 Sep 2015 07:01:50 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D96571A1A57 for ; Fri, 25 Sep 2015 07:01:50 -0700 (PDT) Received: by pacex6 with SMTP id ex6so106831508pac.0 for ; Fri, 25 Sep 2015 07:01:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=from:to:subject:date:message-id:in-reply-to:references:mime-version; bh=HE1Q4JJE3wViK8nJbFV0Er4DcoOak3DDIuWU0vLOtfM=; b=Np47HfH1TgXVSOmZfgyxpIehmezolPt8N+cgpyt6K3epu+0hErA96LnVSfEc5zOGny EWMYrfo3lHeAF/oJB6UYj1YkFGxXaTRLlbxLaEoTHETz2EnMiyf7QaE93yAN1okiDoMc Ye20PWHDN+pCPUUawWIbqgPGPHvGymvZDuNkM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version; bh=HE1Q4JJE3wViK8nJbFV0Er4DcoOak3DDIuWU0vLOtfM=; b=fL2Jyz8SYCPDHQ27qHqVkw1P95KgfGRX6Gtc/g+ymGJMxwzRFbwn4nap9h3RsT407d vevROhVyr1v3W9ICRU+GrsBu0Si9JJRiEwZFkvCFccovXU77CRR3GlHnAMtgNn23QpQb 22Wb7C1JKMeqcDYUBW2f0bkqBYUoRuwavAmtgeH6etUBEG8U7/oq/I/MdjVM9En8X/k+ EQ4e9J+aHUVUT9ZyIr8ZO601jJQn87rgzfStp/D196nh50fR/PxwpsztNb4aN2B7n583 m8M/R5jI5FVEZg/Rub0sQgFTWhnZpuxAJVsKPWKpUxRVUw5AWCtYvAKoDn54cZKDsZGq xpmQ== X-Gm-Message-State: ALoCoQkRz8kIhtZBRGboVcY4RtzPLkSQN/do1FfQqJEugd9xp7zr7kDse/en5s0PzCUzFNY9oDCa X-Received: by 10.68.88.130 with SMTP id bg2mr7334211pbb.129.1443189710428; Fri, 25 Sep 2015 07:01:50 -0700 (PDT) Received: from [172.19.254.145] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id rs8sm4208554pbb.14.2015.09.25.07.01.48 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 25 Sep 2015 07:01:49 -0700 (PDT) From: "Roland Dobbins" To: dots Date: Fri, 25 Sep 2015 21:01:46 +0700 Message-ID: <7FCD0DBB-53C4-476D-AFC6-D395414E4934@arbor.net> In-Reply-To: References: <5603E6F4.5040407@htt-consult.com> <009901d0f6c9$8821cbc0$98656340$@jpshallow.com> <10e4a13c8d0a4cdcb76d38eb4f29aa3d@XCH-RCD-017.cisco.com> <560451D3.7080502@htt-consult.com> <5604CB69.5000403@htt-consult.com> MIME-Version: 1.0 X-Mailer: MailMate (1.9.2r5107) Archived-At: Subject: Re: [Dots] How constrained due to attack congestion X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 14:01:54 -0000 On 25 Sep 2015, at 20:56, Teague, Nik wrote: > I would need a lot of assurances that Vendor X was going to play nice with > my protected NC resources. Stefan has the right idea; QoS is the best way to implement it. ----------------------------------- Roland Dobbins From nobody Fri Sep 25 07:05:28 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 851F61A1A6D for ; Fri, 25 Sep 2015 07:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 VbnAIw_iaijc for ; Fri, 25 Sep 2015 07:05:23 -0700 (PDT) Received: from mx-out02.mykolab.com (mx01.mykolab.com [95.128.36.1]) (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 EE04A1A1A6C for ; Fri, 25 Sep 2015 07:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at kolabnow.com Received: from mx03.mykolab.com (mx03.mykolab.com [10.20.7.101]) by mx-out02.mykolab.com (Postfix) with ESMTPS id A8ED460F3D; Fri, 25 Sep 2015 16:05:14 +0200 (CEST) To: Roland Dobbins References: <5603E6F4.5040407@htt-consult.com> <009901d0f6c9$8821cbc0$98656340$@jpshallow.com> <10e4a13c8d0a4cdcb76d38eb4f29aa3d@XCH-RCD-017.cisco.com> <560451D3.7080502@htt-consult.com> <5604CB69.5000403@htt-consult.com> <7FCD0DBB-53C4-476D-AFC6-D395414E4934@arbor.net> From: Paul Ferguson Organization: Clowns R. Mofos Message-ID: <56055493.10307@mykolab.com> Date: Fri, 25 Sep 2015 07:05:07 -0700 In-Reply-To: <7FCD0DBB-53C4-476D-AFC6-D395414E4934@arbor.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: dots Subject: Re: [Dots] How constrained due to attack congestion X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 14:05:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 9/25/2015 7:01 AM, Roland Dobbins wrote: > On 25 Sep 2015, at 20:56, Teague, Nik wrote: > >> I would need a lot of assurances that Vendor X was going to play >> nice with my protected NC resources. > > Stefan has the right idea; QoS is the best way to implement it. > If you do not own the end-to-end path, 'QoS' is exactly like Pixie Dust and unicorns, - - ferg - -- Paul Ferguson PGP Public Key ID: 0x54DC85B2 Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlYFVJIACgkQKJasdVTchbLRagEA1aqpiUBtzNv5XvXQ/oAdhDA+ 7SUx6br5t2XiABWRL4EBAIAm2HrzYMoVrPn7Q3JWKQUKDwcQOmE2Ef6FTJFgCCQt =JfH7 -----END PGP SIGNATURE----- From nobody Fri Sep 25 07:08:28 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCFA11A1A72 for ; Fri, 25 Sep 2015 07:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.259 X-Spam-Level: X-Spam-Status: No, score=-6.259 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 ZAPD7BNMITbt for ; Fri, 25 Sep 2015 07:08:24 -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 RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3193A1A1A58 for ; Fri, 25 Sep 2015 07:08:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.17,587,1437429600"; d="scan'208,217";a="148581339" Received: from unknown (HELO [192.168.43.145]) ([80.215.199.191]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 25 Sep 2015 16:08:22 +0200 Message-ID: <56055555.2020305@inria.fr> Date: Fri, 25 Sep 2015 16:08:21 +0200 From: =?windows-1252?Q?J=E9r=F4me_Fran=E7ois?= 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 References: <5603E6F4.5040407@htt-consult.com> <009901d0f6c9$8821cbc0$98656340$@jpshallow.com> <10e4a13c8d0a4cdcb76d38eb4f29aa3d@XCH-RCD-017.cisco.com> <560451D3.7080502@htt-consult.com> <5604CB69.5000403@htt-consult.com> <7FCD0DBB-53C4-476D-AFC6-D395414E4934@arbor.net> <56055493.10307@mykolab.com> In-Reply-To: <56055493.10307@mykolab.com> Content-Type: multipart/alternative; boundary="------------080101090303060604050708" Archived-At: Subject: Re: [Dots] How constrained due to attack congestion X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 14:08:26 -0000 This is a multi-part message in MIME format. --------------080101090303060604050708 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi, When a congestion occurs, the DOTS signaling could also be transmitted through other, even non standard, channels. For example, the signaling could be sent through available mobile communications with a chance they are not under attack. This is of course highly dependent of the attacker knowledge. Although selecting and evaluating what are the best communication channels is probably not in the scope of the signaling itself, the client and the controller should negotiate such channels information beforehand (during the subscription or discover dynamically). If using heartbeats, alternatives channels could be specified in the heartbeat messages such that the controller can contact the client on another channel if heartbeats are not received anymore. jerome Le 25/09/2015 16:05, Paul Ferguson a écrit : > On 9/25/2015 7:01 AM, Roland Dobbins wrote: > > > On 25 Sep 2015, at 20:56, Teague, Nik wrote: > > >> I would need a lot of assurances that Vendor X was going to play > >> nice with my protected NC resources. > > > Stefan has the right idea; QoS is the best way to implement it. > > > > If you do not own the end-to-end path, 'QoS' is exactly like Pixie > Dust and unicorns, > > - ferg > > > > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots --------------080101090303060604050708 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi,

When a congestion occurs, the DOTS signaling could also be transmitted through other, even non standard, channels. For example, the signaling could be sent through available mobile communications with a chance they are not under attack. This is of course highly dependent of the attacker knowledge. Although selecting and evaluating what are the best communication channels is probably not in the scope of the signaling itself, the client and the controller should negotiate such channels information beforehand (during the subscription or discover dynamically).

If using heartbeats, alternatives channels could be specified in the heartbeat messages such that the controller can contact the client on another channel if heartbeats are not received anymore.

jerome

Le 25/09/2015 16:05, Paul Ferguson a écrit :
On 9/25/2015 7:01 AM, Roland Dobbins wrote:

> On 25 Sep 2015, at 20:56, Teague, Nik wrote:

>> I would need a lot of assurances that Vendor X was going to play
>> nice with my protected NC resources.

> Stefan has the right idea; QoS is the best way to implement it.



If you do not own the end-to-end path, 'QoS' is exactly like Pixie
Dust and unicorns,

- ferg



>
> _______________________________________________
> Dots mailing list
> Dots@ietf.org
> https://www.ietf.org/mailman/listinfo/dots


--------------080101090303060604050708-- From nobody Fri Sep 25 07:08:37 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0FD01A1A72 for ; Fri, 25 Sep 2015 07:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham 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 lbHcOmGCxtDX for ; Fri, 25 Sep 2015 07:08:31 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 963421A1A69 for ; Fri, 25 Sep 2015 07:08:31 -0700 (PDT) Received: by pablk4 with SMTP id lk4so10183382pab.3 for ; Fri, 25 Sep 2015 07:08:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-type; bh=18PbvfoMHX2X4GVebwVMBKAUZRO0ap8nBg07Qo/wqJo=; b=Hul+q9d57fvVgjQgcD/m1rIGxD8N1N3NNrQchLFiBNsrlh5P//BLoubOlFrQrBctmW +9HcN7k4m6EwHa+ldHe1K3aufeVpEkfu1/3G4PIJkwWyjnfsm8UtCfSKEw8xSHEMx771 7gmFdYgS9SxFL3PCrIoUJPQqnB/GURsVmbW1Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-type; bh=18PbvfoMHX2X4GVebwVMBKAUZRO0ap8nBg07Qo/wqJo=; b=MPqfwIVBzoQZrOZ/kAojm7undCSlPNG/zC68ZUtnx80gp2aYpes0j2uoq4ojuL5Tt1 sjzHOa5HtE2y2Zz1Y4NGMcO7h9qy1wnLIp2SeU8dLjFeQZwn2FRMzGo6q6msjAGrXwbL 6ADzVfvP9xWXjLgWTcEepclFWedJR5Ehy6F1jkEOWiZRALaI7ffErDOBM2uvIus2EC2n UnFJedD3HdzJQbGSaX3+3GmR7ddBPENdXy2H+BjVIACPF20xbRjtdgzF8kHr/3W9a84c ijY/TS57E/8l8FqOjjCFP4Q6Oh056yt5PBtnqCziAyVstjGbAaOqCwm+IYjZpQVy+3LW Ssow== X-Gm-Message-State: ALoCoQl/AWnMLIUFRtRi2oex7o+GXuD+mTLNL8wJAfCH0BiaYHPOMMkNC1jNNiXIg4pQpKGsrBLy X-Received: by 10.68.189.198 with SMTP id gk6mr7344352pbc.141.1443190111102; Fri, 25 Sep 2015 07:08:31 -0700 (PDT) Received: from [172.19.254.145] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id lg7sm4242153pbc.1.2015.09.25.07.08.29 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 25 Sep 2015 07:08:30 -0700 (PDT) From: "Roland Dobbins" To: dots Date: Fri, 25 Sep 2015 21:08:26 +0700 Message-ID: <5687B312-98F7-47EC-9221-721437E4CB2B@arbor.net> In-Reply-To: <56055493.10307@mykolab.com> References: <5603E6F4.5040407@htt-consult.com> <009901d0f6c9$8821cbc0$98656340$@jpshallow.com> <10e4a13c8d0a4cdcb76d38eb4f29aa3d@XCH-RCD-017.cisco.com> <560451D3.7080502@htt-consult.com> <5604CB69.5000403@htt-consult.com> <7FCD0DBB-53C4-476D-AFC6-D395414E4934@arbor.net> <56055493.10307@mykolab.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Subject: Re: [Dots] How constrained due to attack congestion X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 14:08:36 -0000 On 25 Sep 2015, at 21:05, Paul Ferguson wrote: > If you do not own the end-to-end path, 'QoS' is exactly like Pixie > Dust and unicorns, We all know this, Paul, thanks. The same constraint applies to dorking around with precedence. A great deal of these deployments will consist of supplicants on endpoint networks signaling upstream to their transit providers. So, in that very common deployment scenario, QoS can work just fine. It's a different story with overlay MSSPs, of course. But dorking around with precedence wouldn't help there, either. ----------------------------------- Roland Dobbins From nobody Fri Sep 25 07:09:51 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6951A1A83 for ; Fri, 25 Sep 2015 07:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham 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 BWka2ea28aGN for ; Fri, 25 Sep 2015 07:09:49 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.107]) (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 4295B1A1A7F for ; Fri, 25 Sep 2015 07:09:49 -0700 (PDT) Received: from [216.82.253.227] by server-11.bemta-7.messagelabs.com id A5/86-09489-CA555065; Fri, 25 Sep 2015 14:09:48 +0000 X-Env-Sender: Stefan.Fouant@corero.com X-Msg-Ref: server-16.tower-170.messagelabs.com!1443190167!42574589!1 X-Originating-IP: [71.184.227.49] X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32075 invoked from network); 25 Sep 2015 14:09:28 -0000 Received: from mercury.corero.com (HELO MERCURY.corero.com) (71.184.227.49) by server-16.tower-170.messagelabs.com with AES128-SHA encrypted SMTP; 25 Sep 2015 14:09:28 -0000 Received: from MERCURY.corero.com ([fe80::2c05:6b26:abe2:ad24]) by MERCURY.corero.com ([fe80::2c05:6b26:abe2:ad24%19]) with mapi id 14.03.0248.002; Fri, 25 Sep 2015 10:09:27 -0400 From: Stefan Fouant To: Paul Ferguson , Roland Dobbins Thread-Topic: [Dots] How constrained due to attack congestion Thread-Index: AQHQ9sFRB9t5g/y4ekyGeb27kJH2Qp5L6JoAgAAkZYCAAD2BgIAADPSAgABqfACAACZ1gIAAHdgAgAAzpQCAAEaBgP//vmGAgABK0ICAAAFlAIAAAO+A//++JoA= Date: Fri, 25 Sep 2015 14:09:26 +0000 Message-ID: References: <5603E6F4.5040407@htt-consult.com> <009901d0f6c9$8821cbc0$98656340$@jpshallow.com> <10e4a13c8d0a4cdcb76d38eb4f29aa3d@XCH-RCD-017.cisco.com> <560451D3.7080502@htt-consult.com> <5604CB69.5000403@htt-consult.com> <7FCD0DBB-53C4-476D-AFC6-D395414E4934@arbor.net> <56055493.10307@mykolab.com> In-Reply-To: <56055493.10307@mykolab.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.59.78] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <4F48EE8B272CD843AEAC5B03BBFEE1F3@corero.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: dots Subject: Re: [Dots] How constrained due to attack congestion X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 14:09:50 -0000 On 9/25/15, 10:05 AM, "Dots on behalf of Paul Ferguson" wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA256 > >On 9/25/2015 7:01 AM, Roland Dobbins wrote: > >> On 25 Sep 2015, at 20:56, Teague, Nik wrote: >>=20 >>> I would need a lot of assurances that Vendor X was going to play >>> nice with my protected NC resources. >>=20 >> Stefan has the right idea; QoS is the best way to implement it. >>=20 > > >If you do not own the end-to-end path, 'QoS' is exactly like Pixie >Dust and unicorns, My take is end-to-end path is orthogonal to the discussion. The main issue is the last mile where the sending device might be contending for resources. Typically, that=B9s not a problem in the service provider core, so I don=B9t care how it=B9s treated upstream, so long as the message gets = out. Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI, CISSP Senior Security Engineer Corero Network Security Mobile: +1.703.625.6243 From nobody Fri Sep 25 07:11:28 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A922F1A1A78 for ; Fri, 25 Sep 2015 07:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham 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 Rhv-vX29EupJ for ; Fri, 25 Sep 2015 07:11:25 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C66F1A1A72 for ; Fri, 25 Sep 2015 07:11:25 -0700 (PDT) Received: by pacfv12 with SMTP id fv12so108978718pac.2 for ; Fri, 25 Sep 2015 07:11:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=from:to:subject:date:message-id:mime-version; bh=nEAXPzfiiPg0UrxdAjsAaKKJmhs6eKPOk9fBfqsnf98=; b=D5Xdq4EJsp9PWJlcWLCsrpFFwbomxbNzHxgo4eeUeHeLHsOxZE+d7ZTzbJf0ufOEQJ z12CM/0cv7WpUvXEOZ7NYbrFvn/vIMnBmOYFgzMgCmIymDzk83iREIeKWxwc67bwlPO3 PSKajvJwFXi05Fbk1rTMdEkWteBH3EojHJOA8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:mime-version; bh=nEAXPzfiiPg0UrxdAjsAaKKJmhs6eKPOk9fBfqsnf98=; b=ZRcJUCgcCsKDiqnJ8QQpBvnEvktTiFzgf4CSM4bp+xxpBH5POkzUWhxtHgtnw2CUVk sYBeObMwub2WPJBOTKRHAMdy2vY5fz9kSBCSWnS4RRl8pqtWWyTUE7i55ohWs2qPs8ZJ repBBYH2gy8WDiWu1aNREU2YNBJCwEgZAZ8pCiHzxGfQ13lSkgjVQV7JZ4aJ2n6LBcFz TNmDVTATu3WZgcqJ++b6EuSMaC7pVgXayBcNyJla/wKMr47+kJH4r3gZf6X31QfTlHuX xl83BLeXhXx6EOjFyX5MTFvAzpzXjcqzLTftDUeKd3ckWvAnA48yQEUfQVWZi6uMxKXc bwBw== X-Gm-Message-State: ALoCoQn8tFCtfyytcRsRSbKpIbmyFlI0xhcdNaYqvR/uRzHlL+LjiymxoVANjW8MbOLNrTChwnvU X-Received: by 10.68.219.169 with SMTP id pp9mr7640795pbc.115.1443190285046; Fri, 25 Sep 2015 07:11:25 -0700 (PDT) Received: from [172.19.254.145] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id rz9sm4228739pbb.61.2015.09.25.07.11.23 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 25 Sep 2015 07:11:24 -0700 (PDT) From: "Roland Dobbins" To: dots Date: Fri, 25 Sep 2015 21:11:20 +0700 Message-ID: <57619E61-4EDF-46DE-A42E-1289C6402312@arbor.net> MIME-Version: 1.0 X-Mailer: MailMate (1.9.2r5107) Archived-At: Subject: [Dots] Test, please ignore. X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 14:11:26 -0000 ----------------------------------- Roland Dobbins From nobody Fri Sep 25 07:37:50 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99A7A1A1B3E for ; Fri, 25 Sep 2015 07:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 yMFpYluCYYRa for ; Fri, 25 Sep 2015 07:37:46 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 AC9B81A1B3D for ; Fri, 25 Sep 2015 07:37:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 28B5F6029B; Fri, 25 Sep 2015 10:37:43 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id wLEf+QXVNnav; Fri, 25 Sep 2015 10:37:38 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.20]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 5A10760186; Fri, 25 Sep 2015 10:37:38 -0400 (EDT) To: Roland Dobbins , dots@ietf.org References: <5603E6F4.5040407@htt-consult.com> <009901d0f6c9$8821cbc0$98656340$@jpshallow.com> <10e4a13c8d0a4cdcb76d38eb4f29aa3d@XCH-RCD-017.cisco.com> <560451D3.7080502@htt-consult.com> <560454E5.1070602@htt-consult.com> <5B01B3B3-826E-47D4-8D85-597823EBCA28@arbor.net> <5604CAD1.9090602@htt-consult.com> <99301368-EAE8-4515-9EBB-31390BB081CB@arbor.net> From: Robert Moskowitz Message-ID: <56055C30.8060604@htt-consult.com> Date: Fri, 25 Sep 2015 10:37:36 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <99301368-EAE8-4515-9EBB-31390BB081CB@arbor.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dots] How constrained due to attack congestion X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 14:37:49 -0000 On 09/25/2015 05:10 AM, Roland Dobbins wrote: > On 25 Sep 2015, at 11:17, Robert Moskowitz wrote: > >> Rather what does constrained do to congested links mean and thus what >> are the requirements. > > It's highly situationally-specific. > > Retry beaconing until supplicant status change is the answer for this. I am guessing here that you do not mean 'beaconing' in the RF sense (eg 802.11 BEACON of 802.15.4 SUPERBEACON frames). I see that my work in RF networks has colored my view of bandwidth attacks. Kind of forget that MANY wired PHYs are full duplex. (note that PHYs used in BACnet are shared bus, but not of interest here). From nobody Fri Sep 25 07:39:29 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D86001A1B51 for ; Fri, 25 Sep 2015 07:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 R2aaxbJiWwLe for ; Fri, 25 Sep 2015 07:39:26 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 0150A1A1B4C for ; Fri, 25 Sep 2015 07:39:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id A2ABE6029B; Fri, 25 Sep 2015 10:39:22 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id JhbnMmWibocQ; Fri, 25 Sep 2015 10:39:16 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.20]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id E88DA60186; Fri, 25 Sep 2015 10:39:15 -0400 (EDT) To: Stefan Fouant , Christopher Morrow References: <5603E6F4.5040407@htt-consult.com> <009901d0f6c9$8821cbc0$98656340$@jpshallow.com> <10e4a13c8d0a4cdcb76d38eb4f29aa3d@XCH-RCD-017.cisco.com> <560451D3.7080502@htt-consult.com> <5604CB69.5000403@htt-consult.com> From: Robert Moskowitz Message-ID: <56055C92.7060707@htt-consult.com> Date: Fri, 25 Sep 2015 10:39:14 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Jon Shallow , "dots@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [Dots] How constrained due to attack congestion X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 14:39:28 -0000 On 09/25/2015 09:11 AM, Stefan Fouant wrote: > On 9/25/15, 2:06 AM, "Dots on behalf of Christopher Morrow" > wrote: > > >> i've seen customers get 'far more than' 10gbps of traffic inbound to >> them and end up with essentially empty outbound link. So... in that >> case, with connectionless protocols the answer is: "full packets, >> almost at line rate" (not realistic to expect 'line rate', but... >> >> in the end there's lots of ways to mix this cake batter, but first: >> "What do you want to say, to whom, with credentials or not?" sorts of >> things really ought to get sorted out. > Another thing we may want to consider, almost all networking vendors worth > their salt allocate by default ~5% of bandwidth to Network Control via > precedence bit 111. Tagging DOTS signaling as such could ensure delivery > even in periods of high congestion (assuming end user has done nothing to > change classifications and schedulers). Will ISPs buy into this? From nobody Fri Sep 25 07:41:42 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC871A1B5D for ; Fri, 25 Sep 2015 07:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 DPD_ADfBsP0r for ; Fri, 25 Sep 2015 07:41:40 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 377301A1B4B for ; Fri, 25 Sep 2015 07:41:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id ACC426029B; Fri, 25 Sep 2015 10:41:38 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id NY+Rgx-syEip; Fri, 25 Sep 2015 10:41:34 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.20]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 3C6E660186; Fri, 25 Sep 2015 10:41:34 -0400 (EDT) To: Roland Dobbins , dots References: <5603E6F4.5040407@htt-consult.com> <009901d0f6c9$8821cbc0$98656340$@jpshallow.com> <10e4a13c8d0a4cdcb76d38eb4f29aa3d@XCH-RCD-017.cisco.com> <560451D3.7080502@htt-consult.com> <5604CB69.5000403@htt-consult.com> <4AFECE15-2992-44B8-9B6D-ABB3CF40233B@arbor.net> From: Robert Moskowitz Message-ID: <56055D1B.7020002@htt-consult.com> Date: Fri, 25 Sep 2015 10:41:31 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <4AFECE15-2992-44B8-9B6D-ABB3CF40233B@arbor.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dots] How constrained due to attack congestion X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 14:41:42 -0000 On 09/25/2015 09:24 AM, Roland Dobbins wrote: > On 25 Sep 2015, at 20:11, Stefan Fouant wrote: > >> Tagging DOTS signaling as such could ensure delivery even in periods >> of high congestion (assuming end user has done nothing to change >> classifications and schedulers). > > The BCP is to re-color on ingress, and we certainly don't want to > interfere with control-plane traffic in high-congestion situations, > thereby contributing to an outage. > > Instead, one of our deployment recommendations should be to utilize > QoS where/when available to reserve appropriate headroom for DOTS > signaling. Same idea, but under the control of the respective operators. Sounds much better. More leeway to how an ISP runs their network. From nobody Fri Sep 25 07:42:42 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6306A1A1B5C for ; Fri, 25 Sep 2015 07:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham 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 6FgiYAnMocVz for ; Fri, 25 Sep 2015 07:42:34 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92F0C1A1B1F for ; Fri, 25 Sep 2015 07:42:34 -0700 (PDT) Received: by padhy16 with SMTP id hy16so107818031pad.1 for ; Fri, 25 Sep 2015 07:42:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=from:to:subject:date:message-id:in-reply-to:references:mime-version; bh=40TYEaW+bcloK3RDS9UkWpRlYiQTMvQsiccMVr95vts=; b=nFRBdsk1gvc1IIX9RpPEaJcKujJKKY0WoZLcC0xtvbc5jqeqRpfHl6Hltqjv0mHLBn Z41wbZjr2Y2de++Hd7aBbo/D3mSskd/GMusVlYaDQ5el8nHCcHA4l6TMLnw3HpWp8M2L F0T4okYACHSHiIVq9UqzIX26eBiBnlAGbTR8w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version; bh=40TYEaW+bcloK3RDS9UkWpRlYiQTMvQsiccMVr95vts=; b=gyLnZ8Mp45n/PWTdiE2852xDjVi57oEjprN1cbqA0pZ95gmMRV+1L+MrroKQqJ+gxX XQHJ6XF/CoaERGKdADOISVONiDipgKhDFzl/TYJmVX9NNI4otxzDKw9jGUqi5TdxhpdC Ql2CkRq6xXWsT1RA9KBWxu5PZQzuC9rC13WpeZXTlbhD4wf0Uf8t1K+CV1syDrHUI0Eh uRoSK8zpr36pvxLDxPsC1U9YVT7FwnOBw257qzwjvo3phxmOh/cWcriGcJm+KAqBDfZb uAUy3NCKIovHjhnviIOdqhV1pTc178PSLVQAnqxItFBZiqVVVnc/eIHM6g0gdJMREEJB 7fww== X-Gm-Message-State: ALoCoQl9AoAlV3E32S8mtHLidkiMr90Y2PmeqblktQ/ixWvCC4gDKfXfr2ztJ2AGW1pUGkMrqIo/ X-Received: by 10.66.124.229 with SMTP id ml5mr5641358pab.77.1443192154154; Fri, 25 Sep 2015 07:42:34 -0700 (PDT) Received: from [172.19.254.145] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id o3sm4375190pap.37.2015.09.25.07.42.19 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 25 Sep 2015 07:42:20 -0700 (PDT) From: "Roland Dobbins" To: dots Date: Fri, 25 Sep 2015 21:42:17 +0700 Message-ID: <36DCCA55-853F-412B-8E8D-1E6B4AA7C912@arbor.net> In-Reply-To: <56055C92.7060707@htt-consult.com> References: <5603E6F4.5040407@htt-consult.com> <009901d0f6c9$8821cbc0$98656340$@jpshallow.com> <10e4a13c8d0a4cdcb76d38eb4f29aa3d@XCH-RCD-017.cisco.com> <560451D3.7080502@htt-consult.com> <5604CB69.5000403@htt-consult.com> <56055C92.7060707@htt-consult.com> MIME-Version: 1.0 X-Mailer: MailMate (1.9.2r5107) Archived-At: Subject: Re: [Dots] How constrained due to attack congestion X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 14:42:40 -0000 On 25 Sep 2015, at 21:39, Robert Moskowitz wrote: > Will ISPs buy into this? Nope. They will in some cases buy into QoS, however. ----------------------------------- Roland Dobbins From nobody Fri Sep 25 07:45:20 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AFA21A1BA2 for ; Fri, 25 Sep 2015 07:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 IIhEyNYIoLLb for ; Fri, 25 Sep 2015 07:45:18 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 743221A1B9A for ; Fri, 25 Sep 2015 07:45:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 3D7286029B; Fri, 25 Sep 2015 10:45:15 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id HxMajJBM8P8r; Fri, 25 Sep 2015 10:45:06 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.20]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id DE9BE60186; Fri, 25 Sep 2015 10:45:05 -0400 (EDT) To: Paul Ferguson , Roland Dobbins References: <5603E6F4.5040407@htt-consult.com> <009901d0f6c9$8821cbc0$98656340$@jpshallow.com> <10e4a13c8d0a4cdcb76d38eb4f29aa3d@XCH-RCD-017.cisco.com> <560451D3.7080502@htt-consult.com> <5604CB69.5000403@htt-consult.com> <7FCD0DBB-53C4-476D-AFC6-D395414E4934@arbor.net> <56055493.10307@mykolab.com> From: Robert Moskowitz Message-ID: <56055DF0.1060803@htt-consult.com> Date: Fri, 25 Sep 2015 10:45:04 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <56055493.10307@mykolab.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: dots Subject: Re: [Dots] How constrained due to attack congestion X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 14:45:19 -0000 On 09/25/2015 10:05 AM, Paul Ferguson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 9/25/2015 7:01 AM, Roland Dobbins wrote: > >> On 25 Sep 2015, at 20:56, Teague, Nik wrote: >> >>> I would need a lot of assurances that Vendor X was going to play >>> nice with my protected NC resources. >> Stefan has the right idea; QoS is the best way to implement it. >> > > If you do not own the end-to-end path, 'QoS' is exactly like Pixie > Dust and unicorns, Very true, but here we are 'just' trying to get the message out of the congested attack area into a more congeal network. From nobody Fri Sep 25 07:46:16 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2E21A0381 for ; Fri, 25 Sep 2015 07:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham 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 GWer3qol0oaS for ; Fri, 25 Sep 2015 07:46:13 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6EDA1A010D for ; Fri, 25 Sep 2015 07:46:13 -0700 (PDT) Received: by pablk4 with SMTP id lk4so10948054pab.3 for ; Fri, 25 Sep 2015 07:46:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-type; bh=FO2Po3GPrvXubSZAZ6ksTYUk3jVens7w6JM25Q4g6JA=; b=hTZBoEAwXl5uBes6v7x3aoNeo64eTRw4hfdZu5dpTBzH2ZP8zD5Abv0b7HV+euvm// 7EeBucRYMFEPk8cZ8/spt+3vXTNaVlrYCUvVoLb8jiU7rND0UvwqHOFHxn9o6PMq1/t8 aM4D/YkUl4vLen8AdAYc8IhGeSeIQkq3ETnQE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-type; bh=FO2Po3GPrvXubSZAZ6ksTYUk3jVens7w6JM25Q4g6JA=; b=D0md+dmbSEXi9claYT6lHXkyi4RbvhkY3oCEchs0FV5wzrRIl6vjd2iTVQdbnhTewT 1CWsGI4KqRZaqPQlu6TVMYSbJsY0BZzccrdz0k2YrE3qxdAMtVDYwvoxNbj5mAFGL9eJ OKoC1AsAzTwm2EexyqsAsUD5xDw9B2cMImhJGVhSSnbc2iFUfWokDNuPuPth4UGjEYzy tcWfthCRSSAIiRe2184PxNJuWFs9evHGThVMDr17nZ9Q7bV5JpFQUutCS2avtJJCFqeR lG8eXQ4dtKp0jOgXJle3rR8uTc6XN1dmXGXLQOgb0O5TLxiPtNAsAD8mvE+14GgYIeXT Xm+Q== X-Gm-Message-State: ALoCoQnsivl/FH2pX/v7SzZTa3O481WV4bX7EeEE4xOGzaNnRIf3ofvhsk1tq6zB+nVfmvJlurNj X-Received: by 10.68.94.3 with SMTP id cy3mr7503457pbb.113.1443192373305; Fri, 25 Sep 2015 07:46:13 -0700 (PDT) Received: from [172.19.254.145] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id xa4sm4397739pac.28.2015.09.25.07.46.11 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 25 Sep 2015 07:46:12 -0700 (PDT) From: "Roland Dobbins" To: dots@ietf.org Date: Fri, 25 Sep 2015 21:46:09 +0700 Message-ID: <558C3655-3916-4FA6-A488-96B039A7D31A@arbor.net> In-Reply-To: <56055C30.8060604@htt-consult.com> References: <5603E6F4.5040407@htt-consult.com> <009901d0f6c9$8821cbc0$98656340$@jpshallow.com> <10e4a13c8d0a4cdcb76d38eb4f29aa3d@XCH-RCD-017.cisco.com> <560451D3.7080502@htt-consult.com> <560454E5.1070602@htt-consult.com> <5B01B3B3-826E-47D4-8D85-597823EBCA28@arbor.net> <5604CAD1.9090602@htt-consult.com> <99301368-EAE8-4515-9EBB-31390BB081CB@arbor.net> <56055C30.8060604@htt-consult.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Subject: Re: [Dots] How constrained due to attack congestion X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 14:46:15 -0000 On 25 Sep 2015, at 21:37, Robert Moskowitz wrote: > I am guessing here that you do not mean 'beaconing' in the RF sense > (eg 802.11 BEACON of 802.15.4 SUPERBEACON frames). Correct! ;> ----------------------------------- Roland Dobbins From nobody Fri Sep 25 07:47:58 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 269751A1A67 for ; Fri, 25 Sep 2015 07:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham 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 4Vs5d2VXi2Km for ; Fri, 25 Sep 2015 07:47:57 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F0991A0545 for ; Fri, 25 Sep 2015 07:47:57 -0700 (PDT) Received: by padhy16 with SMTP id hy16so107927529pad.1 for ; Fri, 25 Sep 2015 07:47:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-type; bh=t8HEAAYQ1hsFcht3coULKIjUf8RqX1KJhhSB+0Gg8Vk=; b=YewjSLjuelnxF7NH40fL6D5rGR7fL2BF5UGvP/7XkRc9Oa9gJkJVPOrXPvOoTg7AGP o+U8uZrtBz1a8dpvMhyAfsjc9OuIgxYX2oZosqqSBiGhYYW+6VXQlJKmv0nWc+kB/0/R 5FH6+dxltITNcnMjcgZb/o9b1dPIUI6wuzn/I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-type; bh=t8HEAAYQ1hsFcht3coULKIjUf8RqX1KJhhSB+0Gg8Vk=; b=E+7Mbwk4YZlAGvUnjVrlP28XKel1rs70l5L8l5fRajmxMHJtFwTsL0o/aALJSFpYyu YwEWTr6/N7t/2iCsMgJnMzrmRsjKaSb21ZNF1SPL4aqMqc/meQuA344JVR3vUiCRv7xV tr4Syzo+3evRrGuwa6cT1koprQt5CPnLedOdFT5L7BVWjDkl35b+QwN3KO2MXjKJcthI 04ErZ/91OBptLPsjxbYeuFYVVKGumC+wvjn8n6gBffTfBydDn2ImnH69rd7Vj2Pf/sbK 7sfEo2zbhOSTz269ovGlMCTwc/j2ZuHJEgd5ifvrI6EmTn1SD/ZYeyS6A0Up8ejj/QP9 gMVw== X-Gm-Message-State: ALoCoQlcJm5OLjx691jFl7DSs1otMy468Gp2ELF6xHLutWOZHU9QyuLT4CJj+p+EylohZQ9KKleZ X-Received: by 10.66.161.137 with SMTP id xs9mr7872402pab.117.1443192476866; Fri, 25 Sep 2015 07:47:56 -0700 (PDT) Received: from [172.19.254.145] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id fx4sm4359365pbb.92.2015.09.25.07.47.55 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 25 Sep 2015 07:47:56 -0700 (PDT) From: "Roland Dobbins" To: dots Date: Fri, 25 Sep 2015 21:47:52 +0700 Message-ID: <1A1EAAD1-642D-44DD-A6DC-75B3D8D7124C@arbor.net> In-Reply-To: <56055DF0.1060803@htt-consult.com> References: <5603E6F4.5040407@htt-consult.com> <009901d0f6c9$8821cbc0$98656340$@jpshallow.com> <10e4a13c8d0a4cdcb76d38eb4f29aa3d@XCH-RCD-017.cisco.com> <560451D3.7080502@htt-consult.com> <5604CB69.5000403@htt-consult.com> <7FCD0DBB-53C4-476D-AFC6-D395414E4934@arbor.net> <56055493.10307@mykolab.com> <56055DF0.1060803@htt-consult.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Subject: Re: [Dots] How constrained due to attack congestion X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 14:47:58 -0000 On 25 Sep 2015, at 21:45, Robert Moskowitz wrote: > Very true, but here we are 'just' trying to get the message out of the > congested attack area into a more congeal network. Concur 100%. ----------------------------------- Roland Dobbins From nobody Fri Sep 25 07:49:42 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4141A1B4E for ; Fri, 25 Sep 2015 07:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham 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 LEC-pTFtPqKX for ; Fri, 25 Sep 2015 07:49:39 -0700 (PDT) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.195]) (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 7CC421A1A92 for ; Fri, 25 Sep 2015 07:49:38 -0700 (PDT) Received: from [216.82.242.179] by server-3.bemta-8.messagelabs.com id B1/EF-02305-10F55065; Fri, 25 Sep 2015 14:49:37 +0000 X-Env-Sender: Stefan.Fouant@corero.com X-Msg-Ref: server-9.tower-86.messagelabs.com!1443192576!62722109!1 X-Originating-IP: [71.184.227.49] X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32418 invoked from network); 25 Sep 2015 14:49:36 -0000 Received: from mercury.corero.com (HELO MERCURY.corero.com) (71.184.227.49) by server-9.tower-86.messagelabs.com with AES128-SHA encrypted SMTP; 25 Sep 2015 14:49:36 -0000 Received: from MERCURY.corero.com ([fe80::2c05:6b26:abe2:ad24]) by MERCURY.corero.com ([fe80::2c05:6b26:abe2:ad24%19]) with mapi id 14.03.0248.002; Fri, 25 Sep 2015 10:49:36 -0400 From: Stefan Fouant To: Robert Moskowitz , Paul Ferguson , Roland Dobbins Thread-Topic: [Dots] How constrained due to attack congestion Thread-Index: AQHQ9sFRB9t5g/y4ekyGeb27kJH2Qp5L6JoAgAAkZYCAAD2BgIAADPSAgABqfACAACZ1gIAAHdgAgAAzpQCAAEaBgP//vmGAgABK0ICAAAFlAIAAAO+AgAALKgD//74ygA== Date: Fri, 25 Sep 2015 14:49:34 +0000 Message-ID: References: <5603E6F4.5040407@htt-consult.com> <009901d0f6c9$8821cbc0$98656340$@jpshallow.com> <10e4a13c8d0a4cdcb76d38eb4f29aa3d@XCH-RCD-017.cisco.com> <560451D3.7080502@htt-consult.com> <5604CB69.5000403@htt-consult.com> <7FCD0DBB-53C4-476D-AFC6-D395414E4934@arbor.net> <56055493.10307@mykolab.com> <56055DF0.1060803@htt-consult.com> In-Reply-To: <56055DF0.1060803@htt-consult.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [70.106.201.72] Content-Type: text/plain; charset="us-ascii" Content-ID: <8ECA49249084B7489FA01D121211EA9A@corero.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: dots Subject: Re: [Dots] How constrained due to attack congestion X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 14:49:40 -0000 On 9/25/15, 10:45 AM, "Dots on behalf of Robert Moskowitz" wrote: > > >On 09/25/2015 10:05 AM, Paul Ferguson wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> On 9/25/2015 7:01 AM, Roland Dobbins wrote: >> >>> On 25 Sep 2015, at 20:56, Teague, Nik wrote: >>> >>>> I would need a lot of assurances that Vendor X was going to play >>>> nice with my protected NC resources. >>> Stefan has the right idea; QoS is the best way to implement it. >>> >> >> If you do not own the end-to-end path, 'QoS' is exactly like Pixie >> Dust and unicorns, > >Very true, but here we are 'just' trying to get the message out of the >congested attack area into a more congeal network. Could not agree more. Most provider cores are over engineered. Our main objective is getting the message out along that congested last mile. Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI, CISSP Senior Security Engineer Corero Network Security Mobile: +1.703.625.6243 From nobody Fri Sep 25 07:52:37 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 010841A1A14 for ; Fri, 25 Sep 2015 07:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 vlfx3OJnWyis for ; Fri, 25 Sep 2015 07:52:35 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 EDDE81A1BAF for ; Fri, 25 Sep 2015 07:52:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 13E3A6029B; Fri, 25 Sep 2015 10:52:33 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 8TbBoTQRp-LI; Fri, 25 Sep 2015 10:52:28 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.20]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 0EE3F60186; Fri, 25 Sep 2015 10:52:24 -0400 (EDT) To: Stefan Fouant , Paul Ferguson , Roland Dobbins References: <5603E6F4.5040407@htt-consult.com> <009901d0f6c9$8821cbc0$98656340$@jpshallow.com> <10e4a13c8d0a4cdcb76d38eb4f29aa3d@XCH-RCD-017.cisco.com> <560451D3.7080502@htt-consult.com> <5604CB69.5000403@htt-consult.com> <7FCD0DBB-53C4-476D-AFC6-D395414E4934@arbor.net> <56055493.10307@mykolab.com> From: Robert Moskowitz Message-ID: <56055FA4.9070101@htt-consult.com> Date: Fri, 25 Sep 2015 10:52:20 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: dots Subject: Re: [Dots] How constrained due to attack congestion X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 14:52:36 -0000 On 09/25/2015 10:09 AM, Stefan Fouant wrote: > On 9/25/15, 10:05 AM, "Dots on behalf of Paul Ferguson" > wrote: > > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> On 9/25/2015 7:01 AM, Roland Dobbins wrote: >> >>> On 25 Sep 2015, at 20:56, Teague, Nik wrote: >>> >>>> I would need a lot of assurances that Vendor X was going to play >>>> nice with my protected NC resources. >>> Stefan has the right idea; QoS is the best way to implement it. >>> >> >> If you do not own the end-to-end path, 'QoS' is exactly like Pixie >> Dust and unicorns, > My take is end-to-end path is orthogonal to the discussion. The main issue > is the last mile where the sending device might be contending for > resources. Typically, that¹s not a problem in the service provider core, > so I don¹t care how it¹s treated upstream, so long as the message gets out. Depends on the solution fielded. Some will and some won't the customer/provider decides. Not us. From nobody Fri Sep 25 10:18:40 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 959CC1ACE05 for ; Fri, 25 Sep 2015 10:18:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 V2LDcT9o5MrC for ; Fri, 25 Sep 2015 10:18:37 -0700 (PDT) Received: from mail-vk0-f42.google.com (mail-vk0-f42.google.com [209.85.213.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3F441A1EF3 for ; Fri, 25 Sep 2015 10:18:36 -0700 (PDT) Received: by vkgd64 with SMTP id d64so60248357vkg.0 for ; Fri, 25 Sep 2015 10:18:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vSwtymKZi5zEE91Ahwjue+7cLlvvk5VkgO1M9NwjjGE=; b=RkbQgmMxWVqPqL3OyP3T3KWy2MXcuWhbpi9HFoxCG+olOqZ/qLH+H2zlyLfC5rAUTb XDwiH4AR4bsgdkd/j2epIySupoWt9ZVnEvMsFf5otPUf/JtY+papYLYVxUvF22BawuAU LeWiFIpvJdFVTBfK48YHgmgYKhjDTAuzTn96cbmumVfloIje4Wc+RiHnaVZ8a5+u8l1/ oRgovkAgkzs8A7WpJQkXjwicvg+KrrSzf03/uiNRZTZBE7ukCY4T0zLhgdzfF6hwWsuz joHfodWojW9MO8SSo/4aUGY38DQPoCboWyhhs5GMHzGi2qIgcKSq6OmXfC1wjR83MG66 NTyQ== X-Gm-Message-State: ALoCoQmb1Cfeav/06E8D2Kih2UCF4ttrYSqQ2Xat2MwVsW1eEiCwpq2xW9PbzTBa2ObYw3Tbh8NV MIME-Version: 1.0 X-Received: by 10.31.138.141 with SMTP id m135mr3873496vkd.66.1443201516008; Fri, 25 Sep 2015 10:18:36 -0700 (PDT) Received: by 10.31.93.71 with HTTP; Fri, 25 Sep 2015 10:18:35 -0700 (PDT) In-Reply-To: References: <5603E6F4.5040407@htt-consult.com> <009901d0f6c9$8821cbc0$98656340$@jpshallow.com> <10e4a13c8d0a4cdcb76d38eb4f29aa3d@XCH-RCD-017.cisco.com> <560451D3.7080502@htt-consult.com> <560454E5.1070602@htt-consult.com> <5B01B3B3-826E-47D4-8D85-597823EBCA28@arbor.net> Date: Fri, 25 Sep 2015 10:18:35 -0700 Message-ID: From: Jelena Mirkovic To: Roland Dobbins Content-Type: multipart/alternative; boundary=001a11440caab392e705209589f8 Archived-At: Cc: dots@ietf.org Subject: Re: [Dots] How constrained due to attack congestion X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 17:18:38 -0000 --001a11440caab392e705209589f8 Content-Type: text/plain; charset=UTF-8 My point was not that we should wait or serialize. Instead I was saying that we need not exclude use cases. We should list all/most possible use cases and then designing protocol *modes* to work for each. Even if some cases seem less likely to some of us. They may become more likely in some environments. ========================= Jelena Mirkovic Research Faculty USC Information Sciences Institute 4676 Admiralty Way, Suite 1001 Marina del Rey, CA 90292 310-448-9170 On Thu, Sep 24, 2015 at 5:39 PM, Roland Dobbins wrote: > On 25 Sep 2015, at 7:36, Jelena Mirkovic wrote: > > It really sounds as if we'd need to start with use cases and work to >> implementations, then turn back, revisit, rehash, etc. >> > > If we were starting from first principles in an intellectual vacuum, yes. > > Fortunately, we aren't. > > We've already discussed in a reasonable degree of detail the broad > requirements, and we've also discussed the broad requirements; couple that > with the skills and experience of those who're participating in this > effort, and we can start at each and work simultaneously towards the middle. > > > ----------------------------------- > Roland Dobbins > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > --001a11440caab392e705209589f8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My point was not that we should wait or serialize. Instead= I was saying that we need not exclude use cases. We should list all/most p= ossible use cases and then designing protocol *modes* to work for each. Eve= n if some cases seem less likely to some of us. They may become more likely= in some environments.



=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

Jelena Mirkovic
Research= Faculty
USC Informa= tion Sciences Institute
4676 Admiralty Way, Suite 1001
Marina del Rey, CA 90292
310-448-9170


On Thu, Sep 24, 2015 at 5:39 PM, Roland Dobb= ins <rdobbins@arbor.net> wrote:
On 25 Sep 2015, at 7:36, Jelena Mirkovic wrote:

It really sounds as if we'd need to start with use cases and work to im= plementations, then turn back, revisit, rehash, etc.

 If we were starting from first principles in an intellectual vacuum, yes.
Fortunately, we aren't.

We've already discussed in a reasonable degree of detail the broad requ= irements, and we've also discussed the broad requirements; couple that = with the skills and experience of those who're participating in this ef= fort, and we can start at each and work simultaneously towards the middle.<= div class=3D"HOEnZb">


-----------------------------------
Roland Dobbins <= rdobbins@arbor.net>

_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots

--001a11440caab392e705209589f8-- From nobody Fri Sep 25 10:52:54 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 671A41A0235 for ; Fri, 25 Sep 2015 10:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=unavailable 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 yZQG77liZZtw for ; Fri, 25 Sep 2015 10:52:52 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B43FB1A0162 for ; Fri, 25 Sep 2015 10:50:06 -0700 (PDT) Received: by padhy16 with SMTP id hy16so111859855pad.1 for ; Fri, 25 Sep 2015 10:50:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=from:to:subject:date:message-id:in-reply-to:references:mime-version; bh=0Zv+CZ+b68Ok1vIA5n27JfbrpdQ/tKYmuSCwmhgTaxM=; b=Fl5Msn7D+icPOWfmaEC4ledO+aE6tpnVB28CDSTRMjORPIQIPumZ1SQXQCp43Y/Tw3 Qn/Za/xInVgjP3La8WQR/IcTdytO7e2YiKv+DUaI3Gt7D6zEtmCADkEHOKvyIWiE4jbg QbFc+DIAruZl7fHTh9Z51233mhNRnHR4fgHGI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version; bh=0Zv+CZ+b68Ok1vIA5n27JfbrpdQ/tKYmuSCwmhgTaxM=; b=QG24cb6wjPKd9ECjaEPvr1bFwMJ11xoszVvfB3etBskg7KKLNTE808uXDUJiZk6Vdh PRlORWm7buYJvFNgehAEkDylNcHV+P4qV8yMW+R17JWpgFwzJ4MTQHBokBnDzo3b/poO tf5BVR99TiWipekSR+LupKqRr5PQlCSjSdK5ejvVNjjGvMveaUrzpBrPzSj3p9P1bKJW nbd/0kqP/p04kdVPrAkHnqZwtulJQHAwAYSpgHgWunfq/wbIpoNHV0crwfzXsKMapr/r rCHEuat/hkJ/V+uIEDLETvWH4YkJhAFadFyC0LmzDyXOsmPdtaL5AQ6jOidlko2uQapZ EEWg== X-Gm-Message-State: ALoCoQm4jqPQkn/GptLL420p+upLNCOOlQFKwQsPP3Tq/MeiMs888XqWWPYNsFP0hJj1YUMTBFN/ X-Received: by 10.67.22.196 with SMTP id hu4mr8750481pad.20.1443203406247; Fri, 25 Sep 2015 10:50:06 -0700 (PDT) Received: from [172.19.254.145] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id kw10sm5026808pbc.25.2015.09.25.10.50.04 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 25 Sep 2015 10:50:05 -0700 (PDT) From: "Roland Dobbins" To: dots@ietf.org Date: Sat, 26 Sep 2015 00:50:01 +0700 Message-ID: <985ACEDC-76FA-48A8-9824-576884044B97@arbor.net> In-Reply-To: References: <5603E6F4.5040407@htt-consult.com> <009901d0f6c9$8821cbc0$98656340$@jpshallow.com> <10e4a13c8d0a4cdcb76d38eb4f29aa3d@XCH-RCD-017.cisco.com> <560451D3.7080502@htt-consult.com> <560454E5.1070602@htt-consult.com> <5B01B3B3-826E-47D4-8D85-597823EBCA28@arbor.net> MIME-Version: 1.0 X-Mailer: MailMate (1.9.2r5107) Archived-At: Subject: Re: [Dots] How constrained due to attack congestion X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 17:52:53 -0000 On 26 Sep 2015, at 0:18, Jelena Mirkovic wrote: > Instead I was saying that we need not exclude use cases. We will include a variety of likely use cases. ----------------------------------- Roland Dobbins From nobody Fri Sep 25 13:40:50 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04A001A6EE0 for ; Fri, 25 Sep 2015 13:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 hBv9NRdholcY for ; Fri, 25 Sep 2015 13:40:47 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 04C181A00C6 for ; Fri, 25 Sep 2015 13:40:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 85BD86029B; Fri, 25 Sep 2015 16:40:43 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 27BErI9uymK8; Fri, 25 Sep 2015 16:40:30 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.20]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 5E09F5FA40; Fri, 25 Sep 2015 16:40:30 -0400 (EDT) To: Roland Dobbins , dots@ietf.org References: <5603E6F4.5040407@htt-consult.com> <009901d0f6c9$8821cbc0$98656340$@jpshallow.com> <10e4a13c8d0a4cdcb76d38eb4f29aa3d@XCH-RCD-017.cisco.com> <560451D3.7080502@htt-consult.com> <560454E5.1070602@htt-consult.com> <5B01B3B3-826E-47D4-8D85-597823EBCA28@arbor.net> <5604CAD1.9090602@htt-consult.com> <99301368-EAE8-4515-9EBB-31390BB081CB@arbor.net> <56055C30.8060604@htt-consult.com> <558C3655-3916-4FA6-A488-96B039A7D31A@arbor.net> From: Robert Moskowitz Message-ID: <5605B13D.1020706@htt-consult.com> Date: Fri, 25 Sep 2015 16:40:29 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <558C3655-3916-4FA6-A488-96B039A7D31A@arbor.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dots] How constrained due to attack congestion X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 20:40:50 -0000 On 09/25/2015 10:46 AM, Roland Dobbins wrote: > On 25 Sep 2015, at 21:37, Robert Moskowitz wrote: > >> I am guessing here that you do not mean 'beaconing' in the RF sense >> (eg 802.11 BEACON of 802.15.4 SUPERBEACON frames). > > Correct! > > ;> Ah, I just 'found' it in the requirements document terminology section that I am going through for edits... From nobody Mon Sep 28 06:55:58 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E19F41A9109 for ; Mon, 28 Sep 2015 06:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham 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 onFHDKYnNYNy for ; Mon, 28 Sep 2015 06:55:56 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0EC21A9108 for ; Mon, 28 Sep 2015 06:55:55 -0700 (PDT) Received: by igcpb10 with SMTP id pb10so55862037igc.1 for ; Mon, 28 Sep 2015 06:55:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=UNXTg4rTRuDcSNcs4U9piF3A+TfCw1uLepFZeWBhHvM=; b=lCwT1fRCyJLvHmukNkqnkgOl3glj3UGJhw52PFEUkfHYcmsQD3MVrkRigD/To7CXZ/ ZQipelQVROSr5lBSqT4PDIFMyA8eyGVCp0RmmMCRSD9GZKFGRPweewn+uJGaDBIVF3Em 300gas5tExhZc6v/ZPcky0gxjRMFYBSWs7sm8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:content-transfer-encoding :subject:message-id:date:to:mime-version; bh=UNXTg4rTRuDcSNcs4U9piF3A+TfCw1uLepFZeWBhHvM=; b=SeHgEaQeMcapg81RUdLq6ZDH83sIDIrqOLQrkMLvze8AGAoQ01Oz/U7B9PbkdcHfv1 wp/Tc/nNJU2ZlO2doD70GtO+Vnox5RVppagkJ1jgZ5wBA5To8wlQucUuR9tOoK8EjvLO UhFkj8f8PNcksYgew3V6hOqeeqsJ9MdsStEbSU852OZXw3GJ1TACUZ43rk43PQKQok6j XgNf8jZN2u6uyCVR7HcMfNP5W/tWpdzvrLxbm1rB21nBOiY7niNQ31olypMR0V5B4J7m rkfRFwtzTAq2XGi8zWcK5zcccIo7XrESRHtPQkLY+lb+Wh/TVEJl7tnUbJ3FFn1baqmp SWsQ== X-Gm-Message-State: ALoCoQl0nkURw6JmZLwL5ROnziVR6QN/aI+zW8nD2JzxEfBUuFyL8bvabXQt4ptFcOHY5ubzkscZ X-Received: by 10.50.80.14 with SMTP id n14mr2523197igx.30.1443448554879; Mon, 28 Sep 2015 06:55:54 -0700 (PDT) Received: from desktop-10-16.aa.arbor.net ([216.130.192.3]) by smtp.gmail.com with ESMTPSA id c97sm8538592ioj.41.2015.09.28.06.55.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Sep 2015 06:55:54 -0700 (PDT) From: Andrew Mortensen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <35CD785E-8079-4CD8-93D2-DDBE98F1A776@arbor.net> Date: Mon, 28 Sep 2015 09:55:52 -0400 To: dots@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) X-Mailer: Apple Mail (2.2102) Archived-At: Subject: [Dots] Next DOTS meeting time? X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2015 13:55:57 -0000 Good morning, chairs. Do you have a sense of what day of the week our = next meeting is likely to be? andrew= From nobody Mon Sep 28 09:16:41 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF1881ACE38 for ; Mon, 28 Sep 2015 09:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 Y6afdiy4_NlQ for ; Mon, 28 Sep 2015 09:16:37 -0700 (PDT) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 406D71ACE32 for ; Mon, 28 Sep 2015 09:16:37 -0700 (PDT) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by shetland.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id t8SGGZTP029755; Mon, 28 Sep 2015 12:16:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1443456995; bh=EEuFuTmzmW+BvGRpy1tdHVQ+HuJo2/yi0ugBrAAx2v4=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version:Sender: Reply-To:Cc; b=mdXzz4xdR7T/tA0+G9yj8UgNh/F1bTeOEMg5gc8nnZW/8ec0SHp9IeQomwOoaxnmf sA//V9NAqV+WvYPhmDp6JSo9hcPOk5yFyyJDwQpE1aGpGEyHrAnM5IhDESutrlIJlo L9FKEF9l77EyHhNw4ppkModH5sGC1WzR9YFpqP9k= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by timber.sei.cmu.edu (8.14.4/8.14.4/1456) with ESMTP id t8SGGYEU008631; Mon, 28 Sep 2015 12:16:34 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0248.002; Mon, 28 Sep 2015 12:16:33 -0400 From: "Roman D. Danyliw" To: Andrew Mortensen , "dots@ietf.org" Thread-Topic: [Dots] Next DOTS meeting time? Thread-Index: AQHQ+fVuGAyTbR0UGEi+W6okjQx52J5R+LuQ Date: Mon, 28 Sep 2015 16:16:32 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFCD9516D26@marathon> References: <35CD785E-8079-4CD8-93D2-DDBE98F1A776@arbor.net> In-Reply-To: <35CD785E-8079-4CD8-93D2-DDBE98F1A776@arbor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Next DOTS meeting time? X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2015 16:16:39 -0000 Good afternoon Andrew! It is too soon to say on what day the DOTS meeting will occur. A request w= as submitted with the following parameters: Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 I would expect a draft agenda to be published in about a week. Roman > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Andrew Mortensen > Sent: Monday, September 28, 2015 9:56 AM > To: dots@ietf.org > Subject: [Dots] Next DOTS meeting time? >=20 > Good morning, chairs. Do you have a sense of what day of the week our nex= t > meeting is likely to be? >=20 > andrew > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Mon Sep 28 09:28:53 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8E1A1ACE3F for ; Mon, 28 Sep 2015 09:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham 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 1J9VlSW4zrDn for ; Mon, 28 Sep 2015 09:28:51 -0700 (PDT) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D4121ACE3C for ; Mon, 28 Sep 2015 09:28:51 -0700 (PDT) Received: by igbkq10 with SMTP id kq10so56984030igb.0 for ; Mon, 28 Sep 2015 09:28:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OnyhKBZQcVTqnZ5vRxssSJoRgFCdu45zik17XGGgw08=; b=HZNaqC1atCp5bJ4OQuxFVRsNequSmNWwoTjaTfsjLGnvk9yhf4ZReirA0XJzcbt2Nu J9KZzLZYHpQcmIwUVVxcj6+uJmE0AWzAyDclUuuUHptHlIyhWSeWk5J6Bh1X46XkjWPu BjqoY7xgvfnO0lZOWbNppdA+uE5khsSA/C+m4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=OnyhKBZQcVTqnZ5vRxssSJoRgFCdu45zik17XGGgw08=; b=je2Nxe3N3AjW3FVYw1B06SjWaxkzfRdOtBxYzJJP2e0op9oR0fx9lFzWibcZypjM69 hEmLuPxtOYE7akg9/uwDk9CNiAediuyuS+whKSTGokocUGNHmqn9HwFWn1Yq+z7ls9UM yRzhrhHs21w3lVbfl8lfbQOvhjoHDXq9ZC3GK3UIiMfPFJiT59gCLMKjVlO1QlWqa4Xn 8pq8qKEjlVXcz7clUAjIpkfKGbJ5dKmd7jlY1yVDtkshg8j5yuoDUujgxQBkPiv3MlaM IQP6XpIKE90MY+JOX8DLpSXhkSxy+lqpUiZ+VQc9g9nGUasRgBXeYbuZFyJYFoxozfvi WISA== X-Gm-Message-State: ALoCoQmnnI7vulxzvlTAqLnoRuV+L/GMx8TF3s/h5reLRDiEWQ8DrsloJmYScOJld5z5p/10oGw5 X-Received: by 10.50.62.46 with SMTP id v14mr16919083igr.79.1443457730582; Mon, 28 Sep 2015 09:28:50 -0700 (PDT) Received: from desktop-10-16.aa.arbor.net ([216.130.192.3]) by smtp.gmail.com with ESMTPSA id e19sm8057053igo.14.2015.09.28.09.28.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Sep 2015 09:28:50 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Andrew Mortensen In-Reply-To: <359EC4B99E040048A7131E0F4E113AFCD9516D26@marathon> Date: Mon, 28 Sep 2015 12:28:48 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3F07CA97-7C64-4861-9C24-927D52A0A699@arbor.net> References: <35CD785E-8079-4CD8-93D2-DDBE98F1A776@arbor.net> <359EC4B99E040048A7131E0F4E113AFCD9516D26@marathon> To: "Roman D. Danyliw" X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "dots@ietf.org" Subject: Re: [Dots] Next DOTS meeting time? X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2015 16:28:52 -0000 Thanks for the update! > On Sep 28, 2015, at 12:16 PM, Roman D. Danyliw wrote: >=20 > Good afternoon Andrew! >=20 > It is too soon to say on what day the DOTS meeting will occur. A = request was submitted with the following parameters: >=20 > Number of Sessions: 1 > Length of Session(s): 2 Hours > Number of Attendees: 100 >=20 > I would expect a draft agenda to be published in about a week. >=20 > Roman >=20 >> -----Original Message----- >> From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Andrew = Mortensen >> Sent: Monday, September 28, 2015 9:56 AM >> To: dots@ietf.org >> Subject: [Dots] Next DOTS meeting time? >>=20 >> Good morning, chairs. Do you have a sense of what day of the week our = next >> meeting is likely to be? >>=20 >> andrew >> _______________________________________________ >> Dots mailing list >> Dots@ietf.org >> https://www.ietf.org/mailman/listinfo/dots >=20 From nobody Mon Sep 28 17:18:24 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 312031B2CCE for ; Mon, 28 Sep 2015 17:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.078 X-Spam-Level: ** X-Spam-Status: No, score=2.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 BsH4wHG6abzM for ; Mon, 28 Sep 2015 17:18:20 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AECA11B2CCD for ; Mon, 28 Sep 2015 17:18:19 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CBV28712; Tue, 29 Sep 2015 00:18:17 +0000 (GMT) Received: from SZXEMA412-HUB.china.huawei.com (10.82.72.71) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 29 Sep 2015 01:18:17 +0100 Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.77]) by SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id 14.03.0235.001; Tue, 29 Sep 2015 08:18:10 +0800 From: "Xialiang (Frank)" To: "Roman D. Danyliw" Thread-Topic: [Dots] Next DOTS meeting time? Thread-Index: AQHQ+fVsvJ+R8wBAu0iSxejtLVMlyJ5RmAwAgAELKPA= Date: Tue, 29 Sep 2015 00:18:09 +0000 Message-ID: References: <35CD785E-8079-4CD8-93D2-DDBE98F1A776@arbor.net> <359EC4B99E040048A7131E0F4E113AFCD9516D26@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFCD9516D26@marathon> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.43.91] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: Andrew Mortensen , "dots@ietf.org" Subject: [Dots] =?gb2312?b?tPC4tDogIE5leHQgRE9UUyBtZWV0aW5nIHRpbWU/?= X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2015 00:18:22 -0000 SGkgUm9tYW4sDQpGWUksIDEwLTAxfn4xMC0wNyBpcyBDaGluYSBOYXRpb25hbCBEYXkgaG9saWRh eS4gUGxlYXNlIGNvbnNpZGVyIGhvbGRpbmcgdGhlIG1lZXRpbmcgbm90IGluIHRoZXNlIGRheXMu DQpUaGFua3MhDQoNCkIuUi4NCkZyYW5rDQoNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBE b3RzIFttYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3JnXSC0+rHtIFJvbWFuIEQuIERhbnlsaXcN Creiy83KsbzkOiAyMDE1xOo51MIyOcjVIDA6MTcNCsrVvP7IyzogQW5kcmV3IE1vcnRlbnNlbjsg ZG90c0BpZXRmLm9yZw0K1vfM4jogUmU6IFtEb3RzXSBOZXh0IERPVFMgbWVldGluZyB0aW1lPw0K DQpHb29kIGFmdGVybm9vbiBBbmRyZXchDQoNCkl0IGlzIHRvbyBzb29uIHRvIHNheSBvbiB3aGF0 IGRheSB0aGUgRE9UUyBtZWV0aW5nIHdpbGwgb2NjdXIuICBBIHJlcXVlc3Qgd2FzIHN1Ym1pdHRl ZCB3aXRoIHRoZSBmb2xsb3dpbmcgcGFyYW1ldGVyczoNCg0KTnVtYmVyIG9mIFNlc3Npb25zOiAx DQpMZW5ndGggb2YgU2Vzc2lvbihzKTogIDIgSG91cnMNCk51bWJlciBvZiBBdHRlbmRlZXM6IDEw MA0KDQpJIHdvdWxkIGV4cGVjdCBhIGRyYWZ0IGFnZW5kYSB0byBiZSBwdWJsaXNoZWQgaW4gYWJv dXQgYSB3ZWVrLg0KDQpSb21hbg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZy b206IERvdHMgW21haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbmRy ZXcgDQo+IE1vcnRlbnNlbg0KPiBTZW50OiBNb25kYXksIFNlcHRlbWJlciAyOCwgMjAxNSA5OjU2 IEFNDQo+IFRvOiBkb3RzQGlldGYub3JnDQo+IFN1YmplY3Q6IFtEb3RzXSBOZXh0IERPVFMgbWVl dGluZyB0aW1lPw0KPiANCj4gR29vZCBtb3JuaW5nLCBjaGFpcnMuIERvIHlvdSBoYXZlIGEgc2Vu c2Ugb2Ygd2hhdCBkYXkgb2YgdGhlIHdlZWsgb3VyIA0KPiBuZXh0IG1lZXRpbmcgaXMgbGlrZWx5 IHRvIGJlPw0KPiANCj4gYW5kcmV3DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IERvdHMgbWFpbGluZyBsaXN0DQo+IERvdHNAaWV0Zi5vcmcNCj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3RzDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpEb3RzIG1haWxpbmcgbGlzdA0K RG90c0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3Rz DQo= From nobody Mon Sep 28 17:44:15 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C84B1B2CD6 for ; Mon, 28 Sep 2015 17:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 kptN5nc6XZ_G for ; Mon, 28 Sep 2015 17:44:13 -0700 (PDT) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BF101B2CD8 for ; Mon, 28 Sep 2015 17:44:13 -0700 (PDT) Received: by ykft14 with SMTP id t14so199344145ykf.0 for ; Mon, 28 Sep 2015 17:44:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=pis6Ncf4G9actk4IsM9IMFeeIjzT/rucQCJLQGo3PKQ=; b=Q3R1H3PHiiSLtmUVnDa2eG8PAAI9exdNWDS5NLNq3JKhJAmGL022kDqJTF8A5ciVXK AnwUQSZSdmn6lI4Izg9yvAeILbuFCiwegKIkTBmhjkzd7seSN2fZwerHOs6bYxOrzutm ksXz/KCnMjPXZnjeFgjYoAm3fObRlC44grPkA7IfrCo5uztkf465QcCLW934ElE0x5Xw HSbhqbC7hKwbjtQD3H7BOonqCNvFBYpi7b1xcOkX/c2IdjyxwRAjve4Digs691S2A3qZ 3ycx/g4rg/xntoxE5rDz58kMIJVfv9J1yl4ni7ev7azyHlFAvPdzPWsVJeOrJ/f3x6SU JMZw== MIME-Version: 1.0 X-Received: by 10.129.40.144 with SMTP id o138mr17963311ywo.145.1443487452460; Mon, 28 Sep 2015 17:44:12 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.13.202.22 with HTTP; Mon, 28 Sep 2015 17:44:12 -0700 (PDT) In-Reply-To: References: <35CD785E-8079-4CD8-93D2-DDBE98F1A776@arbor.net> <359EC4B99E040048A7131E0F4E113AFCD9516D26@marathon> Date: Mon, 28 Sep 2015 20:44:12 -0400 X-Google-Sender-Auth: H3PD42zoX0Y3v8v9e0FsO0qAlc4 Message-ID: From: Christopher Morrow To: "Xialiang (Frank)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "Roman D. Danyliw" , Andrew Mortensen , "dots@ietf.org" Subject: Re: [Dots] =?utf-8?b?562U5aSNOiBOZXh0IERPVFMgbWVldGluZyB0aW1lPw==?= X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2015 00:44:14 -0000 On Mon, Sep 28, 2015 at 8:18 PM, Xialiang (Frank) wrote: > Hi Roman, > FYI, 10-01~~10-07 is China National Day holiday. Please consider holding the meeting not in these days it's not like the chairs get a call on the day, folks... the secretariat will put out the schedule 3 wks prior to the meeting start, then some scrambling happens... From nobody Mon Sep 28 17:57:17 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40A3A1B2CE4 for ; Mon, 28 Sep 2015 17:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 iNLkQHvKXV1W for ; Mon, 28 Sep 2015 17:57:13 -0700 (PDT) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A30581B2CE3 for ; Mon, 28 Sep 2015 17:57:13 -0700 (PDT) Received: by qgev79 with SMTP id v79so136168195qge.0 for ; Mon, 28 Sep 2015 17:57:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NFH1zYpc4AXSg+LHU+FNDV6mD1wyPxgQZAYEz3dAgVA=; b=0iL3ROWrv7GQX3qPAgzVKq34eLm0OnUnhWlayd4CIoEymzm4evwEKVybh5xPONj3sm C0XL1r3SiV+qjD6eBdcOowXJZn8gyPdY1eACkHOIkbHfpq7Y15eLmXLk1DkI71NkYxO6 u2BWVMyXTE4TtpT9OHBXbRn8jr4wghsfTCB3lZL/Thhb9+Crm7+0TaMxuk/7C0oYWiZG IvZXlKAaPDmhjpNp87jOMWRhOXrqQ50oEwLT2obajPuvVVQX/bFhOWjzW4Q0SIkwTLuw Vw8I0Oy/sOtf3P5mwdztZpM9DcGQV62Tsr9eevofJYstRK9pOVETi1y0Dn/cP/ZfOBCZ fCcA== X-Received: by 10.140.82.163 with SMTP id h32mr25568236qgd.29.1443488232751; Mon, 28 Sep 2015 17:57:12 -0700 (PDT) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by smtp.gmail.com with ESMTPSA id 79sm8228219qhw.4.2015.09.28.17.57.11 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Sep 2015 17:57:11 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (12H143) In-Reply-To: Date: Mon, 28 Sep 2015 20:57:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0ED82EB8-45D4-4A48-98F4-2F34B28385F5@gmail.com> References: <35CD785E-8079-4CD8-93D2-DDBE98F1A776@arbor.net> <359EC4B99E040048A7131E0F4E113AFCD9516D26@marathon> To: Christopher Morrow Archived-At: Cc: "Roman D. Danyliw" , Andrew Mortensen , "Xialiang \(Frank\)" , "dots@ietf.org" Subject: Re: [Dots] =?utf-8?b?562U5aSNOiBOZXh0IERPVFMgbWVldGluZyB0aW1lPw==?= X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2015 00:57:16 -0000 The next IETF meeting runs from November 1-6 in Yokohama. There is no plan f= or a DOTS meeting on the October dates listed below. The agenda is being worked on and will be published once we deconflict a few= sessions based on requests and known conflicts. Thank you, Kathleen=20 Sent from my iPhone > On Sep 28, 2015, at 8:44 PM, Christopher Morrow w= rote: >=20 > On Mon, Sep 28, 2015 at 8:18 PM, Xialiang (Frank) > wrote: >> Hi Roman, >> FYI, 10-01~~10-07 is China National Day holiday. Please consider holding t= he meeting not in these days >=20 > it's not like the chairs get a call on the day, folks... the > secretariat will put out the schedule 3 wks prior to the meeting > start, then some scrambling happens... >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Mon Sep 28 18:01:29 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDED71B2CEC for ; Mon, 28 Sep 2015 18:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.078 X-Spam-Level: ** X-Spam-Status: No, score=2.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 QYClgDGz3CVB for ; Mon, 28 Sep 2015 18:01:25 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04A971B2CEB for ; Mon, 28 Sep 2015 18:01:24 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BYD25897; Tue, 29 Sep 2015 01:01:23 +0000 (GMT) Received: from SZXEMA414-HUB.china.huawei.com (10.82.72.73) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 29 Sep 2015 02:01:22 +0100 Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.77]) by SZXEMA414-HUB.china.huawei.com ([10.82.72.73]) with mapi id 14.03.0235.001; Tue, 29 Sep 2015 09:01:15 +0800 From: "Xialiang (Frank)" To: Kathleen Moriarty , Christopher Morrow Thread-Topic: =?gb2312?B?W0RvdHNdILTwuLQ6IE5leHQgRE9UUyBtZWV0aW5nIHRpbWU/?= Thread-Index: AQHQ+k/5pP++7y1BPUK9AMiNEt5bpp5SKM0AgACGDKA= Date: Tue, 29 Sep 2015 01:01:14 +0000 Message-ID: References: <35CD785E-8079-4CD8-93D2-DDBE98F1A776@arbor.net> <359EC4B99E040048A7131E0F4E113AFCD9516D26@marathon> <0ED82EB8-45D4-4A48-98F4-2F34B28385F5@gmail.com> In-Reply-To: <0ED82EB8-45D4-4A48-98F4-2F34B28385F5@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.43.91] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "Roman D. Danyliw" , Andrew Mortensen , "dots@ietf.org" Subject: [Dots] =?gb2312?b?tPC4tDogILTwuLQ6IE5leHQgRE9UUyBtZWV0aW5nIHRp?= =?gb2312?b?bWU/?= X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2015 01:01:28 -0000 T2gsIEkganVzdCBmaW5kIHRoYXQgSSBtaXN1bmRlcnN0YW5kIHRoZSBxdWVzdGlvbi4gVGhhbmtz IGZvciB0aGUgcmVtaW5kLg0KDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7IyzogS2F0aGxlZW4g TW9yaWFydHkgW21haWx0bzprYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbV0gDQq3osvN yrG85DogMjAxNcTqOdTCMjnI1SA4OjU3DQrK1bz+yMs6IENocmlzdG9waGVyIE1vcnJvdw0Ks63L zTogWGlhbGlhbmcgKEZyYW5rKTsgUm9tYW4gRC4gRGFueWxpdzsgQW5kcmV3IE1vcnRlbnNlbjsg ZG90c0BpZXRmLm9yZw0K1vfM4jogUmU6IFtEb3RzXSC08Li0OiBOZXh0IERPVFMgbWVldGluZyB0 aW1lPw0KDQpUaGUgbmV4dCBJRVRGIG1lZXRpbmcgcnVucyBmcm9tIE5vdmVtYmVyIDEtNiBpbiBZ b2tvaGFtYS4gIFRoZXJlIGlzIG5vIHBsYW4gZm9yIGEgRE9UUyBtZWV0aW5nIG9uIHRoZSBPY3Rv YmVyIGRhdGVzIGxpc3RlZCBiZWxvdy4NCg0KVGhlIGFnZW5kYSBpcyBiZWluZyB3b3JrZWQgb24g YW5kIHdpbGwgYmUgcHVibGlzaGVkIG9uY2Ugd2UgZGVjb25mbGljdCBhIGZldyBzZXNzaW9ucyBi YXNlZCBvbiByZXF1ZXN0cyBhbmQga25vd24gY29uZmxpY3RzLg0KDQpUaGFuayB5b3UsDQpLYXRo bGVlbiANCg0KU2VudCBmcm9tIG15IGlQaG9uZQ0KDQo+IE9uIFNlcCAyOCwgMjAxNSwgYXQgODo0 NCBQTSwgQ2hyaXN0b3BoZXIgTW9ycm93IDxtb3Jyb3djLmxpc3RzQGdtYWlsLmNvbT4gd3JvdGU6 DQo+IA0KPiBPbiBNb24sIFNlcCAyOCwgMjAxNSBhdCA4OjE4IFBNLCBYaWFsaWFuZyAoRnJhbmsp IA0KPiA8ZnJhbmsueGlhbGlhbmdAaHVhd2VpLmNvbT4gd3JvdGU6DQo+PiBIaSBSb21hbiwNCj4+ IEZZSSwgMTAtMDF+fjEwLTA3IGlzIENoaW5hIE5hdGlvbmFsIERheSBob2xpZGF5LiBQbGVhc2Ug Y29uc2lkZXIgDQo+PiBob2xkaW5nIHRoZSBtZWV0aW5nIG5vdCBpbiB0aGVzZSBkYXlzDQo+IA0K PiBpdCdzIG5vdCBsaWtlIHRoZSBjaGFpcnMgZ2V0IGEgY2FsbCBvbiB0aGUgZGF5LCBmb2xrcy4u LiB0aGUgDQo+IHNlY3JldGFyaWF0IHdpbGwgcHV0IG91dCB0aGUgc2NoZWR1bGUgMyB3a3MgcHJp b3IgdG8gdGhlIG1lZXRpbmcgDQo+IHN0YXJ0LCB0aGVuIHNvbWUgc2NyYW1ibGluZyBoYXBwZW5z Li4uDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBEb3RzIG1haWxpbmcgbGlzdA0KPiBEb3RzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90cw0K