From nobody Sun Nov 1 00:18:12 2015 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EE9BE1A88F5; Mon, 19 Oct 2015 09:22:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151019162243.18886.94206.idtracker@ietfa.amsl.com> Date: Mon, 19 Oct 2015 09:22:43 -0700 Archived-At: X-Mailman-Approved-At: Sun, 01 Nov 2015 00:18:11 -0700 Cc: dots@ietf.org Subject: [Dots] I-D Action: draft-ietf-dots-use-cases-00.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 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, 19 Oct 2015 16:22:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DDoS Open Threat Signaling Working Group of the IETF. Title : Use cases for DDoS Open Threat Signaling Authors : Roland Dobbins Stephane Fouant Daniel Migault Robert Moskowitz Nik Teague Liang Xia Filename : draft-ietf-dots-use-cases-00.txt Pages : 22 Date : 2015-10-19 Abstract: This document delineates principal and ancillary use cases for DDoS Open Threat Signaling (DOTS), a communications protocol intended to facilitate the programmatic, coordinated mitigation of Distributed Denial of Service (DDoS) attacks via a standards-based mechanism. DOTS is purposely designed to support requests for DDoS mitigation services and status updates across inter-organizational administrative boundaries. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-use-cases/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dots-use-cases-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Nov 1 00:18:25 2015 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AEE01ACD25; Mon, 19 Oct 2015 10:27:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.6.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151019172722.23547.45444.idtracker@ietfa.amsl.com> Date: Mon, 19 Oct 2015 10:27:22 -0700 Archived-At: X-Mailman-Approved-At: Sun, 01 Nov 2015 00:18:24 -0700 Cc: dots@ietf.org Subject: [Dots] I-D Action: draft-ietf-dots-requirements-00.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 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, 19 Oct 2015 17:27:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DDoS Open Threat Signaling Working Group of the IETF. Title : DDoS Open Threat Signaling Requirements Authors : Andrew Mortensen Robert Moskowitz Tirumaleswar Reddy Filename : draft-ietf-dots-requirements-00.txt Pages : 12 Date : 2015-10-19 Abstract: This document defines the requirements for the DDoS Open Threat Signaling (DOTS) protocols coordinating attack response against Distributed Denial of Service (DDoS) attacks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-requirements/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dots-requirements-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Nov 1 00:18: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 96BD61B2F92 for ; Wed, 21 Oct 2015 13:36:23 -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 y7M1lNh2063v for ; Wed, 21 Oct 2015 13:36:20 -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 605F81B2F90 for ; Wed, 21 Oct 2015 13:36:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 4F324607C9; Wed, 21 Oct 2015 16:36:17 -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 j7VfDXEvD278; Wed, 21 Oct 2015 16:36:11 -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 4EFAC5FA11; Wed, 21 Oct 2015 16:36:10 -0400 (EDT) To: Daniel Migault , "dots@ietf.org" References: <20151019162244.18886.799.idtracker@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11217B7F1@eusaamb107.ericsson.se> From: Robert Moskowitz Message-ID: <5627F738.3060306@labs.htt-consult.com> Date: Wed, 21 Oct 2015 16:36:08 -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: <2DD56D786E600F45AC6BDE7DA4E8A8C11217B7F1@eusaamb107.ericsson.se> Content-Type: multipart/alternative; boundary="------------070709040105040206030506" Archived-At: X-Mailman-Approved-At: Sun, 01 Nov 2015 00:18:33 -0700 Cc: Roland Dobbins , Stephane Fouant , Liang Xia , Nik Teague Subject: Re: [Dots] New Version Notification for draft-ietf-dots-use-cases-00.txt 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, 21 Oct 2015 20:36:23 -0000 This is a multi-part message in MIME format. --------------070709040105040206030506 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit At some point I am going to have to offer alternative wording for some of the run-on sentences like: It should be noted that DOTS servers may be standalone entities which, upon receiving a DOTS mitigation service request from a DOTS client, then initiate DDoS mitigation service by communicating directly or indirectly with DDoS mitigators, and likewise terminate the service upon receipt of a DOTS service termination request; conversely, the DDoS mitigators themselves may incorporate DOTS servers and/or DOTS clients. That would at best be a 'C-' from my 7th grade english teacher! Boy DID I write some good ones back then... :) On 10/20/2015 06:30 AM, Daniel Migault wrote: > Hi, > > Please find the use cases document. Feel free to comment on the ML. We will be happy to address them on the ML or discuss them further at the IETF94. > > BR, > Daniel > > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, October 19, 2015 5:23 PM > To: Stephane Fouant; Nik Teague; Nik Teague; Liang Xia; Robert Moskowitz; Robert Moskowitz; Roland Dobbins; Stephane Fouant; Daniel Migault; Roland Dobbins; Daniel Migault; Liang Xia > Subject: New Version Notification for draft-ietf-dots-use-cases-00.txt > > > A new version of I-D, draft-ietf-dots-use-cases-00.txt has been successfully submitted by Daniel Migault and posted to the IETF repository. > > Name: draft-ietf-dots-use-cases > Revision: 00 > Title: Use cases for DDoS Open Threat Signaling > Document date: 2015-10-19 > Group: dots > Pages: 22 > URL: https://www.ietf.org/internet-drafts/draft-ietf-dots-use-cases-00.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-dots-use-cases/ > Htmlized: https://tools.ietf.org/html/draft-ietf-dots-use-cases-00 > > > Abstract: > This document delineates principal and ancillary use cases for DDoS > Open Threat Signaling (DOTS), a communications protocol intended to > facilitate the programmatic, coordinated mitigation of Distributed > Denial of Service (DDoS) attacks via a standards-based mechanism. > DOTS is purposely designed to support requests for DDoS mitigation > services and status updates across inter-organizational > administrative boundaries. > > > > > Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > -- Standard Robert Moskowitz Owner HTT Consulting C:248-219-2059 F:248-968-2824 E:rgm@labs.htt-consult.com There's no limit to what can be accomplished if it doesn't matter who gets the credit --------------070709040105040206030506 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit At some point I am going to have to offer alternative wording for some of the run-on sentences like:

It should be noted that DOTS servers may be standalone entities which, upon receiving a DOTS mitigation service request from a DOTS client, then initiate DDoS mitigation service by communicating directly or indirectly with DDoS mitigators, and likewise terminate the service upon receipt of a DOTS service termination request; conversely, the DDoS mitigators themselves may incorporate DOTS servers and/or DOTS clients.

That would at best be a 'C-' from my 7th grade english teacher!  Boy DID I write some good ones back then...

:)


On 10/20/2015 06:30 AM, Daniel Migault wrote:
Hi, 

Please find the use cases document. Feel free to comment on the ML. We will be happy to address them on the ML or discuss them further at the IETF94.

BR, 
Daniel 


-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] 
Sent: Monday, October 19, 2015 5:23 PM
To: Stephane Fouant; Nik Teague; Nik Teague; Liang Xia; Robert Moskowitz; Robert Moskowitz; Roland Dobbins; Stephane Fouant; Daniel Migault; Roland Dobbins; Daniel Migault; Liang Xia
Subject: New Version Notification for draft-ietf-dots-use-cases-00.txt


A new version of I-D, draft-ietf-dots-use-cases-00.txt has been successfully submitted by Daniel Migault and posted to the IETF repository.

Name:		draft-ietf-dots-use-cases
Revision:	00
Title:		Use cases for DDoS Open Threat Signaling
Document date:	2015-10-19
Group:		dots
Pages:		22
URL:            https://www.ietf.org/internet-drafts/draft-ietf-dots-use-cases-00.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-dots-use-cases/
Htmlized:       https://tools.ietf.org/html/draft-ietf-dots-use-cases-00


Abstract:
   This document delineates principal and ancillary use cases for DDoS
   Open Threat Signaling (DOTS), a communications protocol intended to
   facilitate the programmatic, coordinated mitigation of Distributed
   Denial of Service (DDoS) attacks via a standards-based mechanism.
   DOTS is purposely designed to support requests for DDoS mitigation
   services and status updates across inter-organizational
   administrative boundaries.

                                                                                  


Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

--
Standard Robert Moskowitz
Owner
HTT Consulting
C:      248-219-2059
F:      248-968-2824
E:      rgm@labs.htt-consult.com

There's no limit to what can be accomplished if it doesn't matter who gets the credit
--------------070709040105040206030506-- From nobody Sun Nov 1 09:36: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 D23D01B8A46 for ; Sun, 1 Nov 2015 09:36:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_64=0.6, 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 v3wyIykKEwYK for ; Sun, 1 Nov 2015 09:36:12 -0800 (PST) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::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 4B0771B8A42 for ; Sun, 1 Nov 2015 09:36:12 -0800 (PST) Received: by iody8 with SMTP id y8so123541879iod.1 for ; Sun, 01 Nov 2015 09:36:11 -0800 (PST) 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=tJL6HgymjQetCNjdnAbg61QijGKrOL0mecAA20TopeE=; b=RhxGZpEMupbWglabVhYr7ofzIFKS2os7vNGlDM/tQMZGAVrcVNvUownFLHZstkRpIK XCVYJGXJhm0KdFJCP864vA5LwRH44Rjm8GZPnlePg8MwQ9OaDAuOCWNvK2sleOcdupiO RsAIvpJSeiN/0OT+PhSWfJ0d87DL52zj0ENz4= 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=tJL6HgymjQetCNjdnAbg61QijGKrOL0mecAA20TopeE=; b=a09uWCW0wNl0E7mrqQWjd7t/Qc+60HNGk1iU+/gqMaxDm7wTR0vz19B5mo5BMqF+rQ a9CGyJGQTIo3zcQUYjDG3CaH/W2pZheizvcStshk9yevoJtBNSjsFMOGXjK/DHYOeuM1 yEOmGnALhR2iSMInqnIIqYKaTkz8q6IpXZLjWlMWATGArr0hqW+6/QJC2omSs4tffFoS g9hplI3cN+Z9KxNOp5q5dDachPkiEHRZOnR4ZXuICQT5TmpYKgafdh6HzzTgg1ycqnGR Fj+meyW1nSdXLSRKDwR4kfjQT6K0+Fql/F1IGqdcovOe9sT6kZ3awD3yv1iJ8QdvktXm iqGw== X-Gm-Message-State: ALoCoQmlD/s/CJgk6vcDzi6qksEHixP5qdHVpqHah/qXb8xEiac3aAWJTnw3RVj+TWIbbwvdoqb/ X-Received: by 10.107.134.94 with SMTP id i91mr18677666iod.74.1446399371655; Sun, 01 Nov 2015 09:36:11 -0800 (PST) Received: from [10.205.141.41] ([209.226.201.248]) by smtp.gmail.com with ESMTPSA id 81sm6473105ioi.10.2015.11.01.09.36.10 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 01 Nov 2015 09:36:10 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Andrew Mortensen In-Reply-To: <359EC4B99E040048A7131E0F4E113AFCD9547406@marathon> Date: Sun, 1 Nov 2015 12:36:09 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1FB02492-1CC8-401C-90CB-E12F3EB865A5@arbor.net> References: <359EC4B99E040048A7131E0F4E113AFCD9547406@marathon> To: "Roman D. Danyliw" X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: "dots@ietf.org" Subject: Re: [Dots] draft-ietf-dots-requirements-00 questions/comments 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, 01 Nov 2015 17:36:14 -0000 Thanks for the comments, Roman! My responses are [AM] inline. > On Oct 30, 2015, at 9:01 PM, Roman D. Danyliw wrote: >=20 > Hello Andrew, Robert and Tiru! >=20 > [Note: This note is written as an individual contributor. Chair hat = off.] >=20 > Thanks again for preparing this initial WG draft of the requirements. = In reviewing draft-ietf-dots-requirements-00, I had the following = questions and comments. >=20 > ** Page 3: Section 1.1: Overview: "To achieve this aim, the protocol = must permit DOTS clients ... to set the scope of the mitigation ...; and = supply summarized attack information and additional hints the ...". > =09 > OP-006 aligns with the "set the scope of the mitigation". DATA-004 = aligns with the "summarized attack information". My question is whether = "summarized attack information" should be restricted to only white and = black lists (DATA-004). Do we need other attack information ("attack = telemetry=E2=80=9D)? [AM] At the previous meeting and in subsequent mail threads, Chris = Morrow has made a very strong case for treating any attack telemetry = from the DOTS client as advisory [1]:=20 "Wrong information is almost always a distraction and = time-wasting event for the upstream mitigation provider.=E2=80=9D I=E2=80=99m definitely in this camp, which is why I specified = =E2=80=9Cadditional hints=E2=80=9D rather than telemetry per se. I meant = the =E2=80=9Csummarized attack information=E2=80=9D to be broad enough = to encompass existing vendor needs. In contrast to attack telemetry, = which gives the mitigating entity the DOTS client=E2=80=99s (possibly = wrong) view of the attack, black- and white-listing involves absolutes: = the DOTS client should be able to indicate that it *always* wants = certain prefixes blocked or conversely always permitted. [1] See the following from Chris: = = = =09 > ** Page 3: Terminology: I'm not sure where the canonical terminology = list should be. I noticed that draft-ietf-dots-use-case-00 includes a = definition for "DDoS", "attack target" and "Countermeasure" not present = in this draft. It also defines "attack telemetry" and "mitigation" = differently. [AM] As Roland said, we=E2=80=99ll work on reconciliation for the next = revisions. > ** Page 6: General Requirements: G-004 and G-005 appear to only apply = to the signal channel. Since there is a Data Channel Requirements = section (Section 2.3), it seems like there should be corresponding = Signal Channel requirements one as well. With G-003, "signaling = protocol" is used to scope the requirement. Is that the same as "signal = channel" or "DOTS signal" (i.e., signal+data channel)? [AM] Good points. DOTS signal/heartbeat are meant to be distinct from = the data channel. Will discuss re-organization with co-editors. > ** Page 7: G-006: In order for DOTS ... despite advancements in = cryptanalysis ...". I'd recommend a broader statement. Minimally, "... = despite advancements in cryptanalysis and traffic analysis=E2=80=9D. >=20 > ** Page 7: G-007: " ... such as including a timestamp or sequence = number in every heartbeat and signal sent between DOTS agents." I would = recommend removing this last clause. IMO, it is too specific and = implementation oriented. The requirement articulated in the first part = of the sentence is clear enough. >=20 > ** Page 7: G-008: This requirement appears to only apply to the Data = Channel. IMO, it would fit better in Section 2.3, the section for data = channel requirements. >=20 > ** Page 7: G-008: "As the resilience requirements for DOTS mandate = small ...". I propose this sentence read "As the resilience = requirements for the DOTS signal channel mandates ..." to highlight that = the signal and data channels have different requirements. [AM] Above all marked for update. > ** Page 9: DATA-002: How is this requirement different than G-006? It = has more specificity on why integrity and confidentiality are important = for the data channel, but it still just repeats that encryption and = authentication is required. [AM] I think only (and only potentially) different in form. Marked for = removal. > ** Page 10: DATA-003: How is this authentication clause of this = requirement different than OP-002? DATA-003 does add an authorization = requirement not present in OP-002. [AM] Would emphasizing the authorization requirement address your = concern? > ** In considering the ancillary used cases in = draft-ietf-dots-use-cases-00, OP-006 would likely cover at least some of = the Provisioning Use Case (Section 4.2.2). I didn't see a requirement = covering the Registration Use Case (Section 4.2.1). [AM] Marked for addition. Thanks! andrew= From nobody Mon Nov 2 10:48: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 040451A90F4 for ; Mon, 2 Nov 2015 10:48:16 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7, 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 43pANw3mb15Q for ; Mon, 2 Nov 2015 10:48:14 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8661A90EB for ; Mon, 2 Nov 2015 10:48:14 -0800 (PST) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by wtl-exchp-1.sandvine.com (192.168.194.178) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 2 Nov 2015 13:48:13 -0500 Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([fe80::6c6d:7108:c63c:9055%14]) with mapi id 14.03.0181.006; Mon, 2 Nov 2015 13:48:19 -0500 From: Dave Dolson To: "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-use-cases-00.txt Thread-Index: AQHRFHV6rwGUQR3pPU2YODuE392pVJ6JEC3Q Date: Mon, 2 Nov 2015 18:48:14 +0000 Message-ID: References: <20151019162243.18886.94206.idtracker@ietfa.amsl.com> In-Reply-To: <20151019162243.18886.94206.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [183.77.156.199] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-use-cases-00.txt 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, 02 Nov 2015 18:48:16 -0000 Is it intentional that the use-cases effectively lay out the protocol, not = in the message format but in the sense of who says what to whom, which comm= ands and information are conveyed from client to server and vice versa? Example: it seems that the use-cases document requires a server-pushes mode= l (vs. a client-polls model) for the status updates. Was that level of specificity intended? -Dave -----Original Message----- From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org Sent: Tuesday, October 20, 2015 1:23 AM To: i-d-announce@ietf.org Cc: dots@ietf.org Subject: [Dots] I-D Action: draft-ietf-dots-use-cases-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DDoS Open Threat Signaling Working Group = of the IETF. Title : Use cases for DDoS Open Threat Signaling Authors : Roland Dobbins Stephane Fouant Daniel Migault Robert Moskowitz Nik Teague Liang Xia Filename : draft-ietf-dots-use-cases-00.txt Pages : 22 Date : 2015-10-19 Abstract: This document delineates principal and ancillary use cases for DDoS Open Threat Signaling (DOTS), a communications protocol intended to facilitate the programmatic, coordinated mitigation of Distributed Denial of Service (DDoS) attacks via a standards-based mechanism. DOTS is purposely designed to support requests for DDoS mitigation services and status updates across inter-organizational administrative boundaries. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-use-cases/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dots-use-cases-00 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Mon Nov 2 11:38: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 79CE51B2B91; Mon, 2 Nov 2015 11:38:51 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7, 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 lrIU339TKrfb; Mon, 2 Nov 2015 11:38:50 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id B9B6E1B2B77; Mon, 2 Nov 2015 11:38:49 -0800 (PST) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa%18]) with mapi id 14.03.0195.001; Mon, 2 Nov 2015 14:38:49 -0500 From: Dave Dolson To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-requirements-00.txt Thread-Index: AQHRFHWAA72N17GeHEOBJOqaqqVLS56JIcGA Date: Mon, 2 Nov 2015 19:38:51 +0000 Message-ID: References: <20151019172722.23547.45444.idtracker@ietfa.amsl.com> In-Reply-To: <20151019172722.23547.45444.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [183.77.156.199] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "dots@ietf.org" Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-00.txt 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, 02 Nov 2015 19:38:51 -0000 Regarding draft-ietf-dots-requirements-00, Is OP-006 intended to refer to source or destination IP addresses, or both? It could also be clarified for port range. "OP-006 Mitigation Scope: DOTS clients MUST indicate the desired address space coverage of any mitigation, for example by using Classless Internet Domain Routing (CIDR) [RFC1518],[RFC1519] prefixes, [RFC2373] for IPv6 prefixes, the length/prefix convention established in the Border Gateway Protocol (BGP) [RFC4271], or by a prefix group alias agreed upon with the server through the data channel. If there is additional information available narrowing the scope of any requested attack response, such as targeted port range, protocol, or service, clients SHOULD include that information in client signals." -Dave -----Original Message----- From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org Sent: Tuesday, October 20, 2015 2:27 AM To: i-d-announce@ietf.org Cc: dots@ietf.org Subject: [Dots] I-D Action: draft-ietf-dots-requirements-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DDoS Open Threat Signaling Working Group = of the IETF. Title : DDoS Open Threat Signaling Requirements Authors : Andrew Mortensen Robert Moskowitz Tirumaleswar Reddy Filename : draft-ietf-dots-requirements-00.txt Pages : 12 Date : 2015-10-19 Abstract: This document defines the requirements for the DDoS Open Threat Signaling (DOTS) protocols coordinating attack response against Distributed Denial of Service (DDoS) attacks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-requirements/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dots-requirements-00 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Mon Nov 2 11:39: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 004B91B2BBD for ; Mon, 2 Nov 2015 11:39:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 heU5KtfdDMd4 for ; Mon, 2 Nov 2015 11:38:56 -0800 (PST) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) by ietfa.amsl.com (Postfix) with ESMTP id F36051B2BAB for ; Mon, 2 Nov 2015 11:38:55 -0800 (PST) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by WTL-EXCHP-3.sandvine.com (192.168.196.177) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 2 Nov 2015 14:38:57 -0500 Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([fe80::6c6d:7108:c63c:9055%14]) with mapi id 14.03.0181.006; Mon, 2 Nov 2015 14:39:02 -0500 From: Dave Dolson To: "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-requirements-00.txt Thread-Index: AQHRFHWAA72N17GeHEOBJOqaqqVLS56JHKpw Date: Mon, 2 Nov 2015 19:38:57 +0000 Message-ID: References: <20151019172722.23547.45444.idtracker@ietfa.amsl.com> In-Reply-To: <20151019172722.23547.45444.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [183.77.156.199] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-00.txt 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, 02 Nov 2015 19:39:01 -0000 Regarding the dots-requirements-00, Another type of Security Consideration should be mentioned in the document: Knowing (or guessing) the criteria for automatically triggering mitigation,= an attacker could set up traffic patterns to cause mitigation to be enacte= d. Since a mitigation can deny service to legitimate traffic, an attacker c= ould therefore trick the system into creating mitigations and denying servi= ce. Furthermore, an attacker could create multiple mitigations, and without pro= tection could overload the dots protocol itself, attacking dots session sta= te, dots protocol bandwidth and dots CPU utilization. An "attack" might even be accidental, such as with a new release of an appl= ication that creates unexpected traffic patterns. This isn't mentioned in the use-cases doc either. I don't think it's purely theoretical; it could occur with threshold settin= gs that are too low (na=EFve or mistakes). So, perhaps something like this: DOTS must define protections against attacks on the DOTS infrastructure by = an attacker who creates false-positive attack detections. DOTS must define mechanisms for a client or server to function robustly und= er high messaging load from its peer(s). DOTS must define back-off mechanisms so that neither client nor server will= overload the peer with messaging. A method of back-off may include adapting the threshold settings. -Dave -----Original Message----- From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org Sent: Tuesday, October 20, 2015 2:27 AM To: i-d-announce@ietf.org Cc: dots@ietf.org Subject: [Dots] I-D Action: draft-ietf-dots-requirements-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DDoS Open Threat Signaling Working Group = of the IETF. Title : DDoS Open Threat Signaling Requirements Authors : Andrew Mortensen Robert Moskowitz Tirumaleswar Reddy Filename : draft-ietf-dots-requirements-00.txt Pages : 12 Date : 2015-10-19 Abstract: This document defines the requirements for the DDoS Open Threat Signaling (DOTS) protocols coordinating attack response against Distributed Denial of Service (DDoS) attacks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-requirements/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dots-requirements-00 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Mon Nov 2 15:16: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 C78561A903D for ; Mon, 2 Nov 2015 15:16:28 -0800 (PST) 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 OzsJ32q2zHVj for ; Mon, 2 Nov 2015 15:16:27 -0800 (PST) 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 B1EC51A9038 for ; Mon, 2 Nov 2015 15:16:27 -0800 (PST) Received: by padec8 with SMTP id ec8so52816269pad.1 for ; Mon, 02 Nov 2015 15:16:27 -0800 (PST) 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=1plfflZHX1iidpXDARQ+WKbCH5+0Uh8MM2n2ZCGYjb0=; b=HeUQgIJ7p3tqf2XpKjGFYoFtlDuRJRfmuT/AFbQkU/vwGJ5mWgfIJvfGUsnkMzeoyg TMhk1fdlF67c93qk8dFNAkxXJ+MgMenjBzTr8wmMIhuwrMj9QkLS/dra9HAApRxLRkyZ ku6hJnKO7FBZm4mWL/QgRJyysvkRrFiFEI3U8= 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=1plfflZHX1iidpXDARQ+WKbCH5+0Uh8MM2n2ZCGYjb0=; b=Y+Hqbhn0tHbs1deQwGPQVTOzJIk6D8eMmVO3nJtRVN1rz49w73cpBpeD6yj7g9k7LS BhlOKiYvEiotMrtha7o3/zPLYrkwKKY49/bnX0RPk9Tjfj1OWqw9VhLC6FJ3zp+5Erlw wYhowwO4LUH4rGYUwRHg2R5UVHKYwZIAITccGpglacxGdhjl0DAcbviTiJJhJsE62NqO VJ8irGa/hROgAd2fKAqii9AJQGmMfwP70982xdzxRbiD4dwMcOanFElf2agOEybMbm5u YzgyvFG6qt4ChwkvX/cB0N5i0onWfnIICl7xBvse1q7OLm5kktUASuEa7yU+/+lDHYmO myWg== X-Gm-Message-State: ALoCoQnWZrFLLUbNITFtFK10G3Vgre0vLSZcFi55HR/e+lrHzbmdGPItMFsAAc0IQngo7i4Bfzt/ X-Received: by 10.66.186.141 with SMTP id fk13mr29715722pac.7.1446506187309; Mon, 02 Nov 2015 15:16:27 -0800 (PST) Received: from [10.0.1.3] (p5231-ipngn5001hodogaya.kanagawa.ocn.ne.jp. [153.220.164.231]) by smtp.gmail.com with ESMTPSA id qd2sm25938784pbb.68.2015.11.02.15.16.26 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 02 Nov 2015 15:16:26 -0800 (PST) From: "Roland Dobbins" To: "dots@ietf.org" Date: Tue, 03 Nov 2015 08:16:24 +0900 Message-ID: <7990C2F1-6EE9-473E-A45C-097B894F2F51@arbor.net> In-Reply-To: References: <20151019162243.18886.94206.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5141) Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-use-cases-00.txt 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, 02 Nov 2015 23:16:28 -0000 On 3 Nov 2015, at 3:48, Dave Dolson wrote: > Is it intentional that the use-cases effectively lay out the protocol, > not in the message format but in the sense of who says what to whom, > which commands and information are conveyed from client to server and > vice versa? Yes, in terms of operationally-significant information flow and informational checkpoints. > Example: it seems that the use-cases document requires a server-pushes > model (vs. a client-polls model) for the status updates. Server can push from its perspective, client can push from its perspective, both can poll. In the examples in question, status updates regarding ongoing mitigation are natural and expected from the system(s) doing the actual mitigating. Likewise, updates on the efficacy of said mitigation are natural and expected from the system(s) southbound of said mitigation. Does this make sense? > Was that level of specificity intended? Yes, in the context of the specific examples in question - but not as a limitation - see above. ----------------------------------- Roland Dobbins From nobody Mon Nov 2 17:47: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 D7ED21B2B73 for ; Mon, 2 Nov 2015 17:47:28 -0800 (PST) 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 aIPeCttpVlvW for ; Mon, 2 Nov 2015 17:47:26 -0800 (PST) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::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 E45621B2B74 for ; Mon, 2 Nov 2015 17:47:24 -0800 (PST) Received: by igpw7 with SMTP id w7so70367750igp.0 for ; Mon, 02 Nov 2015 17:47:24 -0800 (PST) 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=j02tEfPs5iKPD3MbQm10OcA5c6OcqSA2g9l8ajV5hQk=; b=eUynYZzYq3wRsMfvRGd1n4braPqgDlHOWTvhsn/SygLyo6aQr2VxX71G/wyBIHC4vX +23dH/De1Jy0KRSbbim6inTCwmHgWPCAGqXf0Xwkt1F69cqMGUJZ8JsF6hdvh9vln44N mzV+VwcxKxZZxqzieLJOCZDpQNHTJlyE96kdg= 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=j02tEfPs5iKPD3MbQm10OcA5c6OcqSA2g9l8ajV5hQk=; b=Wab6dHrTDb8vn/AVg7zHxh9uwh1/ZQakMjKh8OQniuj0dU9Tws7Rx5e6gea3mHVa9t Ofzs2Sz92kL+J4yDGO+6AKB80YxNbRiWbmdkXVZZellr97q+mw5NkWGYXoNEJM8V82jH BdawXH+2rgSWM+2cDOzd0kp9Rbc59P+0Oa2+UNEX3hDn7UmqkH1veJ4lB6GikkyVxpmN +zBUxHb4C0DZSr7LxvEvLe+G95a4PwbU9ed8t/VAGjbJHK2EuMF7Xi/obYoZjEPwntlG bG5/HG/88l7CgmGtkIXR6MgrBoJKClbZiBDcp2W2MdSAmAi6vzpJlDzpwOb6T9UA/ncN xtKw== X-Gm-Message-State: ALoCoQlM7DcuFzTrqrqzx6nql7Kfo/H2DanjIbodVVbg+biDspIjIBv6Vf74zx5iaptPM2H7f+Z5 X-Received: by 10.50.79.170 with SMTP id k10mr15012074igx.90.1446515244343; Mon, 02 Nov 2015 17:47:24 -0800 (PST) Received: from dhcp-35-191.meeting.ietf94.jp (dhcp-35-191.meeting.ietf94.jp. [133.93.35.191]) by smtp.gmail.com with ESMTPSA id j10sm6924356igx.13.2015.11.02.17.47.23 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Nov 2015 17:47:23 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Andrew Mortensen In-Reply-To: Date: Mon, 2 Nov 2015 20:47:21 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151019172722.23547.45444.idtracker@ietfa.amsl.com> To: Dave Dolson X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: "internet-drafts@ietf.org" , "dots@ietf.org" , "i-d-announce@ietf.org" Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-00.txt 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, 03 Nov 2015 01:47:29 -0000 > On Nov 2, 2015, at 2:38 PM, Dave Dolson wrote: >=20 > Regarding draft-ietf-dots-requirements-00, >=20 > Is OP-006 intended to refer to source or destination IP addresses, or = both? Thanks for your comments. As written, OP-006 refesr to protected = resources only, so that the client can help shape the scope of a = particular mitigation. A client is authoritative in the scope of = protection for address space it owns, but may not be authoritative or = accurate with respect to the sources of attack. I will clarify. As a separate but related point, a client may also request mitigation in = the absence of attack (e.g., always on, or in anticipation of an = impending attack), which is something I should make explicit. > It could also be clarified for port range. Marked for addition. andrew >=20 > "OP-006 Mitigation Scope: DOTS clients MUST indicate the desired > address space coverage of any mitigation, for example by using > Classless Internet Domain Routing (CIDR) [RFC1518],[RFC1519] > prefixes, [RFC2373] for IPv6 prefixes, the length/prefix > convention established in the Border Gateway Protocol (BGP) > [RFC4271], or by a prefix group alias agreed upon with the server > through the data channel. If there is additional information > available narrowing the scope of any requested attack response, > such as targeted port range, protocol, or service, clients SHOULD > include that information in client signals." >=20 > -Dave >=20 > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of = internet-drafts@ietf.org > Sent: Tuesday, October 20, 2015 2:27 AM > To: i-d-announce@ietf.org > Cc: dots@ietf.org > Subject: [Dots] I-D Action: draft-ietf-dots-requirements-00.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the DDoS Open Threat Signaling Working = Group of the IETF. >=20 > Title : DDoS Open Threat Signaling Requirements > Authors : Andrew Mortensen > Robert Moskowitz > Tirumaleswar Reddy > Filename : draft-ietf-dots-requirements-00.txt > Pages : 12 > Date : 2015-10-19 >=20 > Abstract: > This document defines the requirements for the DDoS Open Threat > Signaling (DOTS) protocols coordinating attack response against > Distributed Denial of Service (DDoS) attacks. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dots-requirements/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-dots-requirements-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=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 Mon Nov 2 17:56: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 454691A017A; Mon, 2 Nov 2015 17:56:09 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7, 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 HtJFbpq8NQtF; Mon, 2 Nov 2015 17:56:07 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 4408C1A0130; Mon, 2 Nov 2015 17:56:07 -0800 (PST) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa%18]) with mapi id 14.03.0195.001; Mon, 2 Nov 2015 20:56:06 -0500 From: Dave Dolson To: Andrew Mortensen Thread-Topic: [Dots] I-D Action: draft-ietf-dots-requirements-00.txt Thread-Index: AQHRFHWAA72N17GeHEOBJOqaqqVLS56JIcGAgAC8ToD//61iIA== Date: Tue, 3 Nov 2015 01:56:08 +0000 Message-ID: References: <20151019172722.23547.45444.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [133.93.38.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "internet-drafts@ietf.org" , "dots@ietf.org" , "i-d-announce@ietf.org" Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-00.txt 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, 03 Nov 2015 01:56:09 -0000 Andrew, I think you are saying that only destination address filtering can be speci= fied? If a client detects an attack coming from a particular source, wouldn't it = make sense to make a more precise filter? -Dave -----Original Message----- From: Andrew Mortensen [mailto:amortensen@arbor.net]=20 Sent: Tuesday, November 03, 2015 10:47 AM To: Dave Dolson Cc: internet-drafts@ietf.org; i-d-announce@ietf.org; dots@ietf.org Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-00.txt > On Nov 2, 2015, at 2:38 PM, Dave Dolson wrote: >=20 > Regarding draft-ietf-dots-requirements-00, >=20 > Is OP-006 intended to refer to source or destination IP addresses, or bot= h? Thanks for your comments. As written, OP-006 refesr to protected resources = only, so that the client can help shape the scope of a particular mitigatio= n. A client is authoritative in the scope of protection for address space i= t owns, but may not be authoritative or accurate with respect to the source= s of attack. I will clarify. As a separate but related point, a client may also request mitigation in th= e absence of attack (e.g., always on, or in anticipation of an impending at= tack), which is something I should make explicit. > It could also be clarified for port range. Marked for addition. andrew >=20 > "OP-006 Mitigation Scope: DOTS clients MUST indicate the desired=20 > address space coverage of any mitigation, for example by using=20 > Classless Internet Domain Routing (CIDR) [RFC1518],[RFC1519] prefixes,=20 > [RFC2373] for IPv6 prefixes, the length/prefix convention established=20 > in the Border Gateway Protocol (BGP) [RFC4271], or by a prefix group=20 > alias agreed upon with the server through the data channel. If there=20 > is additional information available narrowing the scope of any=20 > requested attack response, such as targeted port range, protocol, or=20 > service, clients SHOULD include that information in client signals." >=20 > -Dave >=20 > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of=20 > internet-drafts@ietf.org > Sent: Tuesday, October 20, 2015 2:27 AM > To: i-d-announce@ietf.org > Cc: dots@ietf.org > Subject: [Dots] I-D Action: draft-ietf-dots-requirements-00.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the DDoS Open Threat Signaling Working Group= of the IETF. >=20 > Title : DDoS Open Threat Signaling Requirements > Authors : Andrew Mortensen > Robert Moskowitz > Tirumaleswar Reddy > Filename : draft-ietf-dots-requirements-00.txt > Pages : 12 > Date : 2015-10-19 >=20 > Abstract: > This document defines the requirements for the DDoS Open Threat > Signaling (DOTS) protocols coordinating attack response against > Distributed Denial of Service (DDoS) attacks. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dots-requirements/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-dots-requirements-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=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 Mon Nov 2 18:00: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 286271A1A6D for ; Mon, 2 Nov 2015 18:00:46 -0800 (PST) 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 qxu1VG8GYfpc for ; Mon, 2 Nov 2015 18:00:44 -0800 (PST) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::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 018E81A1A2E for ; Mon, 2 Nov 2015 18:00:44 -0800 (PST) Received: by ioll68 with SMTP id l68so5501626iol.3 for ; Mon, 02 Nov 2015 18:00:43 -0800 (PST) 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=rYGrkoAJVhcgokNxOfJDzzLoxQY009LFdm1f+vIQ6Rs=; b=kzzgjqMw2pzqbWM6M5G4lrtPiOjanGyQFnv6DYmJE21b5Mkx++eZawti4j0lT3JdBy bkWd941qhWVU1bd26qLorChDYGHpzDuToGeLZYYpnTzovFQbFHeZFAnzaCxau/WUTy/m au0FlfVo6bxJJjT1z1QNFxGKCJCKiBffhFK7s= 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=rYGrkoAJVhcgokNxOfJDzzLoxQY009LFdm1f+vIQ6Rs=; b=CrJ0OFXkJtt858T/LlRx8jSWPBLBEL78bb2DhvyIkITXaYw7f532YTNZ1A+RKpFSOI 6OIkJpDr6wip11xakJ/58fjFOHNDE7qHtf8tILohzPFmYeI9YCPuF/UKwwmE/F0jdVuq KqDymTUvGcwHLFAHtZFQKvvqcEPVx5bsLXz7sWkX0yaQsm7765Bt8WazXMr6UO85BKcj L1j2Td19FyPiD6QBikOwRLWgmdcCACvuXQn8vSsTcDPHiyl41YggiW6pJV8mJvk43RKp Kc0kT73L5fYhlfuruepMm2sW8jDCKHMtV0+Vv2gKmFGwn/xRDVNXptkOSwz93LwyhaGf W9bw== X-Gm-Message-State: ALoCoQk4nym8j7pJ9oXGVDT7hXsNWyofVWRkg0y13XEwsGnS7BIKyaV58+vePEIX8gK4PX/LrUKT X-Received: by 10.107.136.216 with SMTP id s85mr25270689ioi.142.1446516043297; Mon, 02 Nov 2015 18:00:43 -0800 (PST) Received: from dhcp-35-191.meeting.ietf94.jp (dhcp-35-191.meeting.ietf94.jp. [133.93.35.191]) by smtp.gmail.com with ESMTPSA id e1sm508051igx.6.2015.11.02.18.00.41 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Nov 2015 18:00:42 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Andrew Mortensen In-Reply-To: Date: Mon, 2 Nov 2015 21:00:39 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151019172722.23547.45444.idtracker@ietfa.amsl.com> To: Dave Dolson X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: "internet-drafts@ietf.org" , "dots@ietf.org" , "i-d-announce@ietf.org" Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-00.txt 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, 03 Nov 2015 02:00:46 -0000 > On Nov 2, 2015, at 8:56 PM, Dave Dolson wrote: >=20 > Andrew, > I think you are saying that only destination address filtering can be = specified? >=20 > If a client detects an attack coming from a particular source, = wouldn't it make sense to make a more precise filter? Specifying mitigation scope=E2=80=94that is, the client restricting a = mitigation to address space/services it owns=E2=80=94and blacklisting = sources of bad traffic are distinct. It=E2=80=99s not feasible or = effective for a DOTS client to try to narrow mitigation scope by source = address when the services under attack are being hit by a botnet = comprised of thousands of hosts. andrew >=20 > -----Original Message----- > From: Andrew Mortensen [mailto:amortensen@arbor.net]=20 > Sent: Tuesday, November 03, 2015 10:47 AM > To: Dave Dolson > Cc: internet-drafts@ietf.org; i-d-announce@ietf.org; dots@ietf.org > Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-00.txt >=20 >=20 >> On Nov 2, 2015, at 2:38 PM, Dave Dolson wrote: >>=20 >> Regarding draft-ietf-dots-requirements-00, >>=20 >> Is OP-006 intended to refer to source or destination IP addresses, or = both? >=20 > Thanks for your comments. As written, OP-006 refesr to protected = resources only, so that the client can help shape the scope of a = particular mitigation. A client is authoritative in the scope of = protection for address space it owns, but may not be authoritative or = accurate with respect to the sources of attack. I will clarify. >=20 > As a separate but related point, a client may also request mitigation = in the absence of attack (e.g., always on, or in anticipation of an = impending attack), which is something I should make explicit. >=20 >> It could also be clarified for port range. >=20 > Marked for addition. >=20 > andrew >=20 >=20 >=20 >>=20 >> "OP-006 Mitigation Scope: DOTS clients MUST indicate the desired=20 >> address space coverage of any mitigation, for example by using=20 >> Classless Internet Domain Routing (CIDR) [RFC1518],[RFC1519] = prefixes,=20 >> [RFC2373] for IPv6 prefixes, the length/prefix convention established=20= >> in the Border Gateway Protocol (BGP) [RFC4271], or by a prefix group=20= >> alias agreed upon with the server through the data channel. If there=20= >> is additional information available narrowing the scope of any=20 >> requested attack response, such as targeted port range, protocol, or=20= >> service, clients SHOULD include that information in client signals." >>=20 >> -Dave >>=20 >> -----Original Message----- >> From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of=20 >> internet-drafts@ietf.org >> Sent: Tuesday, October 20, 2015 2:27 AM >> To: i-d-announce@ietf.org >> Cc: dots@ietf.org >> Subject: [Dots] I-D Action: draft-ietf-dots-requirements-00.txt >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the DDoS Open Threat Signaling Working = Group of the IETF. >>=20 >> Title : DDoS Open Threat Signaling Requirements >> Authors : Andrew Mortensen >> Robert Moskowitz >> Tirumaleswar Reddy >> Filename : draft-ietf-dots-requirements-00.txt >> Pages : 12 >> Date : 2015-10-19 >>=20 >> Abstract: >> This document defines the requirements for the DDoS Open Threat >> Signaling (DOTS) protocols coordinating attack response against >> Distributed Denial of Service (DDoS) attacks. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-dots-requirements/ >>=20 >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-dots-requirements-00 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=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 >=20 From nobody Mon Nov 2 19:51: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 234411B2C0F for ; Mon, 2 Nov 2015 18:54:04 -0800 (PST) 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 Z6SKYkO5sfzh for ; Mon, 2 Nov 2015 18:54:02 -0800 (PST) Received: from mail.amsl.com (mail.amsl.com [4.31.198.40]) by ietfa.amsl.com (Postfix) with ESMTP id E07451B2C0D for ; Mon, 2 Nov 2015 18:54:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 15BD01E59F6 for ; Mon, 2 Nov 2015 18:53:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JqdpB4KDktm2 for ; Mon, 2 Nov 2015 18:53:29 -0800 (PST) Received: from t20010c400000302418ef1e5e1effddeb.v6.meeting.ietf94.jp (t20010c400000302418ef1e5e1effddeb.v6.meeting.ietf94.jp [IPv6:2001:c40:0:3024:18ef:1e5e:1eff:ddeb]) by c8a.amsl.com (Postfix) with ESMTPA id B13CA1E59F0 for ; Mon, 2 Nov 2015 18:53:28 -0800 (PST) From: Alexa Morris Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Nov 2015 18:54:02 -0800 Message-Id: <54E51BF5-B577-4548-97CA-48D3D1099BEA@amsl.com> To: dots@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Sendlaterdate: Mon, 2 Nov 2015 18:54:02 -0800 X-Mailer: Apple Mail (2.1878.6) Archived-At: X-Mailman-Approved-At: Mon, 02 Nov 2015 19:51:51 -0800 Subject: [Dots] Virtual Queue for DOTS Remote Attendees 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, 03 Nov 2015 02:54:04 -0000 If you are planning to participate in the DOTS session here at IETF 94 = today =97 either locally in Yokohama or as a remote participant =97 we = want to make sure that you are aware that the IETF is providing a remote = participants with a fairly new way to ask questions or make comments. In = addition to using the Jabber room, for the DOTS session there is also = the opportunity for remote participants to enter a virtual queue and ask = questions directly into the meeting room.=20 This experimental queue was used in several sessions at IETF 92 and IETF = 93, so you may have already seen it in action. There will be two queues = for the DOTS session =97 a virtual queue and an actual (in-room) queue. = Remote attendees will log into the Meetecho platform and will have a = virtual mic line that they can enter if they have a question or comment. = In-room participants will continue to use normal mic lines.=20 Instructions for remote participants are at = http://ietf94.conf.meetecho.com/index.php/Remote_Participation.=20 Information on how to join the Meetecho session is at = http://ietf94.conf.meetecho.com/. Verify that you are WebRTC compliant (required to use the virtual queue) = by performing a self-test here: = http://ietf94.conf.meetecho.com/index.php/Self_Test.=20 Regards, Alexa ---------- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: amorris@amsl.com Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com From nobody Mon Nov 2 21:43: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 B2B721ACE6A; Mon, 2 Nov 2015 21:42:26 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 ez3Au7HuXxzS; Mon, 2 Nov 2015 21:42:25 -0800 (PST) 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 CAB561AD0A5; Mon, 2 Nov 2015 21:42:23 -0800 (PST) Received: by ykft191 with SMTP id t191so6114692ykf.0; Mon, 02 Nov 2015 21:42:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=gE9yOnspXXYUV9NjPfGh8W6hYM/RVu3KJ4s7/2ceefA=; b=y75HaFrpBcs8fi5AXTPumQrrdjk5dcAk0YSMlwVMxRXN6CwvO69u4317D62PTdJS0D cJHsLEQwStPkkQ4RX3ywp2hYUeCd2Pw2e+TEvn8TpzyPxSvrGroXonxxtQBa61Ji2fg3 BEyiuXMDtCQ6ZxS9kck/PsTfTgTcpId8KAcVZwjDo9nE+mRE4pLk958fv8uuoqJ5mfNz D+A1Wzoa+0c6Kdf79mdfbrxqKrDW8RK3XsUgExQo/KlE6YYLBpzTHHFDTukdNBtQXBmt iPjAo3IBw26gVqVLLp6h4TtITlXoeEY39ckqz6LLC5/KZ+s1hKobq/E1xJLxt57SB2sY +TUw== MIME-Version: 1.0 X-Received: by 10.129.55.211 with SMTP id e202mr18930401ywa.254.1446529343189; Mon, 02 Nov 2015 21:42:23 -0800 (PST) Received: by 10.37.95.2 with HTTP; Mon, 2 Nov 2015 21:42:23 -0800 (PST) Date: Tue, 3 Nov 2015 14:42:23 +0900 Message-ID: From: Aaron Falk To: tsvwg@ietf.org Content-Type: multipart/alternative; boundary=001a1143fb7aa87e2705239c5b1c Archived-At: X-Mailman-Approved-At: Mon, 02 Nov 2015 21:43:02 -0800 Cc: dots@ietf.org Subject: [Dots] Best transport selection during an attack? 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, 03 Nov 2015 05:42:26 -0000 --001a1143fb7aa87e2705239c5b1c Content-Type: text/plain; charset=UTF-8 Dear TSV- There was a discussion in DDoS Open Threat Signaling (DOTS) this afternoon about selecting a transport that is likely to be able to carry an "SOS" message when a network is under DDOS. UDP gets filtered. TCP may have trouble getting ACKs back through a congested link. They'd like some advice. I suggested they come to the TSV Area meeting (but there isn't one). So, can the chairs give a few minutes from TSVWG to layout the problem? See - draft-reddy-dots-transport-01 Presentation --aaron --001a1143fb7aa87e2705239c5b1c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear TSV-

There was a discussion in DDo= S Open Threat Signaling (DOTS) this afternoon about selecting a transport t= hat is likely to be able to carry an "SOS" message when a network= is under DDOS.=C2=A0 UDP gets filtered.=C2=A0 TCP may have trouble getting= ACKs back through a congested link.=C2=A0 They'd like some advice.=C2= =A0 I suggested they come to the TSV Area meeting (but there isn't one)= .=C2=A0 So, can the chairs give a few minutes from TSVWG to layout the prob= lem?


--aaron
--001a1143fb7aa87e2705239c5b1c-- From nobody Mon Nov 2 23:57: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 0CA051ACEFB for ; Mon, 2 Nov 2015 23:57:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.664 X-Spam-Level: X-Spam-Status: No, score=-96.664 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, 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 WJYFS4ZM4v9O for ; Mon, 2 Nov 2015 23:57:51 -0800 (PST) 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 BF9371AC3F3 for ; Mon, 2 Nov 2015 23:57:51 -0800 (PST) Received: from [133.93.36.191] (dhcp-36-191.meeting.ietf94.jp [133.93.36.191]) by lvps5-35-241-16.dedicated.hosteurope.de (Postfix) with ESMTPSA id 26FB762CF0; Tue, 3 Nov 2015 08:57:48 +0100 (CET) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=kqNPFolAiHim2WD72yvfQVvO7s+wfS/IeVqy92az455u6ATKkuFO5IqtF5alK5zJVWfj7VSsLrp6rJf7i4W1pUWZAZFoNMrYetQP6X38QYXG8COW4ipwRIJBjNTt1OGuPyiN7efvpwPg9MzJpQ6B0Ys5U/IqSy6lmbUeroAB7yU=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type; Message-ID: <563868F9.8050107@gondrom.org> Date: Tue, 03 Nov 2015 16:57:45 +0900 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, rdd@cert.org Content-Type: multipart/alternative; boundary="------------090204030804040409040401" Archived-At: Subject: [Dots] DOTS office hour - room 318, on Nov-5 at 15:30 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, 03 Nov 2015 07:57:53 -0000 This is a multi-part message in MIME format. --------------090204030804040409040401 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi dear DOTS fellows, very good meeting today. And thank you for all the good contributions and discussions. As mentioned at the end of our WG meeting today, the DOST chairs like to offer an office hour for interested contributors and any general questions. We arranged for that *room 318 on Thursday Nov-5 from 15:30 to 16:30. * During that time, the room can also serve as a meeting point or offer some discussion space for conversations on future or current DOTS drafts or design topics, talking about implementation, starting protocol or data model drafts, ... Basically, if you have questions or like to chat about DOTS with like-minded folks, please feel free to drop by. Best regards, Tobias & Roman (DOTS co-chairs) --------------090204030804040409040401 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hi dear DOTS fellows,

very good meeting today. And thank you for all the good contributions and discussions.

As mentioned at the end of our WG meeting today, the DOST chairs like to offer an office hour for interested contributors and any general questions. We arranged for that room 318 on Thursday Nov-5 from 15:30 to 16:30.

During that time, the room can also serve as a meeting point or offer some discussion space for conversations on future or current DOTS drafts or design topics, talking about implementation, starting protocol or data model drafts, ...
Basically, if you have questions or like to chat about DOTS with like-minded folks, please feel free to drop by.

Best regards,

Tobias & Roman (DOTS co-chairs)








 --------------090204030804040409040401-- From nobody Tue Nov 3 02:11: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 AEF071B3148 for ; Tue, 3 Nov 2015 02:11:43 -0800 (PST) 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 MelIlJ1AyXL7 for ; Tue, 3 Nov 2015 02:11:42 -0800 (PST) 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 42F681B3123 for ; Tue, 3 Nov 2015 02:11:42 -0800 (PST) Received: by pacfv9 with SMTP id fv9so15154377pac.3 for ; Tue, 03 Nov 2015 02:11:42 -0800 (PST) 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=tKLTLkhpMCsUg3TDp1xWse2vYkXr/Cx4aXmW5TIhCVg=; b=ZLUlsnOV0c3Ss1j2AfvicSheJ+OBsFcDZCA2h4U6nlSrG3CLvRDrSVipTB9Sd9rkPk 4VmvjnJYT0gK6vk2JBfrD5NHj4hOKrAWm+ap/zaG6qvHRXlbLNLgbcAjd617ayrygGkU C6yxmPurPEjKs1y4X3otI0FpkGEyxN61w10dM= 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=tKLTLkhpMCsUg3TDp1xWse2vYkXr/Cx4aXmW5TIhCVg=; b=GBpjQCA9zXVyBDopBpczjBVmUbsQJlsnEA5Q3eNThYXqXj4otGp0/IlBD77cwR7DkG 2nlDXbBZz3+bTte6JppMcUHAxZGCrY380SH5FtwkcMMqvJ1goGiqL/BBudZNhZqkhOtu 50Ce5Rzb2DhL/qyq7bBJdbp4XDPSJtqComp9zZ5kzNLNkndzD+uhoSypwYrkWy1Ih8Y+ VLvLH+R0ka3e0y0XR0GjeGyCNeu5lwWEZQoj2TgOWnrZi/vaF6h6civCmkUBSnrsaCU0 tduSrOqRiTR4FKehpKnwSqSplHnXgeF9re73a6bMrBbz45FfqwKb/rNPv94e2Wxa3hjt N8Zw== X-Gm-Message-State: ALoCoQmRWkgFmJO6/ME1DoruJVWKPJ0XjS5+gREOACX+myQH5yclv0r2PursWouZZCkV7nNZw747 X-Received: by 10.68.174.1 with SMTP id bo1mr32468721pbc.110.1446545501933; Tue, 03 Nov 2015 02:11:41 -0800 (PST) Received: from [10.0.1.3] (p5231-ipngn5001hodogaya.kanagawa.ocn.ne.jp. [153.220.164.231]) by smtp.gmail.com with ESMTPSA id xa4sm28693988pac.28.2015.11.03.02.11.40 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 03 Nov 2015 02:11:41 -0800 (PST) From: "Roland Dobbins" To: "dots@ietf.org" Date: Tue, 03 Nov 2015 19:11:38 +0900 Message-ID: <1837A898-7562-4449-AEDB-EEF8CA9E099A@arbor.net> In-Reply-To: References: <20151019172722.23547.45444.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.2r5141) Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-00.txt 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, 03 Nov 2015 10:11:43 -0000 On 3 Nov 2015, at 4:38, Dave Dolson wrote: > I don't think it's purely theoretical; it could occur with threshold > settings that are too low (naïve or mistakes). This isn't a DOTS-specific issue; it's the realm of the detection/classification/traceback/mitigation systems which may be DOTS-enabled. So, this is really out of bounds for DOTS, which is merely a messaging system. ----------------------------------- Roland Dobbins From nobody Tue Nov 3 07:01: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 1C2C91A0178; Tue, 3 Nov 2015 06:01:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 9w_bS26cxtd8; Tue, 3 Nov 2015 06:01:49 -0800 (PST) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c: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 68A8A1A0062; Tue, 3 Nov 2015 06:01:49 -0800 (PST) Received: by wijp11 with SMTP id p11so72354043wij.0; Tue, 03 Nov 2015 06:01:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Cbk1t0Nl3UBPVz54l916JRDdroGRAofXJQI9TnAFAZU=; b=BFqMGgIlP1V/WGUmPu0O9XWDBLipMz4PAo2L/LJ2Bh/TZFfBkwE6OwhjxOfGh3hdf8 4lCejRwp+lWjrnU9F9vxmd4nz7dvmpZZ9QeEV6Oov81kbjTXe3yPl7CsrBbOhd6RlFbu yGYiw/gMszOTz32+gmjb7MQpFBk+rOtPKk2wofH1e8k6Fzv/SolT32Yld3x9jHJLkkJK OcnY8pfo+eYKHcVTddpcPP6GYWQ6/gAeo0gDVWXS867o/WJ3VybijxoBYk/Wm+l0JBvS Lb2RR34f2rbkTYM4xU4WWY6Bw1cYPr77uGaeGr0Xc1qkQ8ASRhe03jB+t/0GcJievYSS p/Pg== MIME-Version: 1.0 X-Received: by 10.194.89.135 with SMTP id bo7mr33368738wjb.147.1446559308000; Tue, 03 Nov 2015 06:01:48 -0800 (PST) Received: by 10.194.174.130 with HTTP; Tue, 3 Nov 2015 06:01:47 -0800 (PST) In-Reply-To: References: Date: Tue, 3 Nov 2015 06:01:47 -0800 Message-ID: From: Ca By To: Aaron Falk Content-Type: multipart/alternative; boundary=047d7bf10af0b3376f0523a35555 Archived-At: X-Mailman-Approved-At: Tue, 03 Nov 2015 07:01:41 -0800 Cc: "tsvwg@ietf.org" , "dots@ietf.org" Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 03 Nov 2015 14:01:51 -0000 --047d7bf10af0b3376f0523a35555 Content-Type: text/plain; charset=UTF-8 On Monday, November 2, 2015, Aaron Falk wrote: > Dear TSV- > > There was a discussion in DDoS Open Threat Signaling (DOTS) this afternoon > about selecting a transport that is likely to be able to carry an "SOS" > message when a network is under DDOS. UDP gets filtered. TCP may have > trouble getting ACKs back through a congested link. They'd like some > advice. I suggested they come to the TSV Area meeting (but there isn't > one). So, can the chairs give a few minutes from TSVWG to layout the > problem? > > See - draft-reddy-dots-transport-01 Presentation > > > --aaron > Please see https://tools.ietf.org/html/draft-byrne-opsec-udp-advisory-00 I am a network operator (eyeballs) Nearly 100% of my daily volumetric attacks are on udp and there is no simple way to proactively stop this traffic aside from flat udp filters. Using udp would be counter productive. Anything aside from udp will do fine. Sctp, tcp, udp in esp ... You can also look to https://tools.ietf.org/html/draft-ietf-tsvwg-rfc5405bis-06 Don't use udp: "These mechanisms are difficult to implement correctly. For most applications, the use of one of the existing IETF transport protocols is the simplest method of acquiring the required mechanisms. Consequently, the RECOMMENDED alternative to the UDP usage described in the remainder of this section is the use of an IETF transport protocol such as TCP [RFC0793 ], Stream Control Transmission Protocol (SCTP) [RFC4960 ], and SCTP Partial Reliability Extension (SCTP-PR) [RFC3758 ], or Datagram Congestion Control Protocol (DCCP) [RFC4340 ] with its different congestion control types [RFC4341 ][RFC4342][RFC5622 ]." --047d7bf10af0b3376f0523a35555 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Monday, November 2, 2015, Aaron Falk <aaron.falk@gmail.com> wrote:
Dear TSV-

There was a dis= cussion in DDoS Open Threat Signaling (DOTS) this afternoon about selecting= a transport that is likely to be able to carry an "SOS" message = when a network is under DDOS.=C2=A0 UDP gets filtered.=C2=A0 TCP may have t= rouble getting ACKs back through a congested link.=C2=A0 They'd like so= me advice.=C2=A0 I suggested they come to the TSV Area meeting (but there i= sn't one).=C2=A0 So, can the chairs give a few minutes from TSVWG to la= yout the problem?


-= -aaron

=C2=A0
<= font size=3D"2">Please= see=C2=A0=C2=A0https://tools.ietf.org/html/draft-byrne-opsec-udp-advisory-0= 0

I am a network operator (eyebal= ls)

=C2=A0Nearly=C2=A0100% of my dail= y volumetric attacks are on udp and there is no simple way to proactively s= top this traffic aside from flat udp filters. =C2=A0
Using udp would be counter productive.=C2=A0 Anything = aside from udp will do fine. Sctp, tcp, udp in esp ... =C2=A0=

You can also look to
=
<= /span>

Don't us= e udp:=C2=A0

"These mechanisms ar= e difficult to implement correctly. For most
applications, the use of one of t=
he existing IETF transport protocols is the simplest method of acquiring th=
e required mechanisms. Consequently, the RECOMMENDED alternative to the UDP=
 usage described in the remainder of this section is the use of an IETF tra=
nsport protocol such as TCP [RFC0793], Stream =
Control Transmission Protocol (SCTP) [RFC49=
60], and SCTP Partial Reliability Extension (SCTP-PR) [RFC3758], or Datag=
ram Congestion Control Protocol (DCCP) [RFC4340] with its different congestion control types [RFC4341][RFC4342][RFC5622]."

--047d7bf10af0b3376f0523a35555-- From nobody Tue Nov 3 07:08:18 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 1A5A61A1BAC; Tue, 3 Nov 2015 07:08:17 -0800 (PST) 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 8VFzpxz1y0LE; Tue, 3 Nov 2015 07:08:15 -0800 (PST) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::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 729151A1BD9; Tue, 3 Nov 2015 07:08:04 -0800 (PST) Received: by ykft191 with SMTP id t191so20093013ykf.0; Tue, 03 Nov 2015 07:08:03 -0800 (PST) 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=pGfHfcQgAOAX+GFl+17DdwuKkQ9beLpJJfH7hHZoT6I=; b=QWtK8k5lMACglpk8gWNZF2DFq76jM1WwWuXke95TrffynreNrBoTPrl8a3NtF0ibYp SS9Hz0+yIYJxSqghGkBqbBnNIK9SDvhui3nYQa6MLQnf6whw0KyiHYpu4w//MCFXWXUs i0DPcuUZgvlY0qVAYveUi0UeltEk6hF8h5dD1cIqYL3SkQPiZ//j1aA9Uel5YSPVWrod I9ZWRe4Sk6Pri1tewJEwHLwiptVO4XGHSFvqVPDu1lLDc3YagG8qZo9ok1DEd5B1BtEB stPDK6rIaLHakxQcYUMwYD9Yq106Enyow6tzKBl9K34AbJ2KEes4sM+TYveXQKmzub1p HDBw== MIME-Version: 1.0 X-Received: by 10.129.77.68 with SMTP id a65mr23349337ywb.180.1446563283426; Tue, 03 Nov 2015 07:08:03 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.13.202.16 with HTTP; Tue, 3 Nov 2015 07:08:03 -0800 (PST) In-Reply-To: References: Date: Wed, 4 Nov 2015 02:08:03 +1100 X-Google-Sender-Auth: sK8z77PUNrPlKUhmAKBT1BQA7xY Message-ID: From: Christopher Morrow To: Ca By Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Aaron Falk , "tsvwg@ietf.org" , "dots@ietf.org" Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 03 Nov 2015 15:08:17 -0000 On Wed, Nov 4, 2015 at 1:01 AM, Ca By wrote: > > Please see https://tools.ietf.org/html/draft-byrne-opsec-udp-advisory-00 > > I am a network operator (eyeballs) > > Nearly 100% of my daily volumetric attacks are on udp and there is no > simple way to proactively stop this traffic aside from flat udp filters. > > Using udp would be counter productive. Anything aside from udp will do > fine. Sctp, tcp, udp in esp ... > > You can also look to > > https://tools.ietf.org/html/draft-ietf-tsvwg-rfc5405bis-06 > > Don't use udp: for the data in question, the need is a packet which: 1) is not going to require state be maintained from client -> server 2) not require an ACK from the server (or management of a session at all 3) not need many / any round-trips in order to get the job done The thought expressed in slideware (and txt I believe) was: "Be able to send from client -> server a packet with: auth token 'help!' message " udp seems to fit the bill.. I suppose someone could just crap out a raw IP packet with the data, because why bother putting an L4 header at all? > > "These mechanisms are difficult to implement correctly. For most > > applications, the use of one of the existing IETF transport protocols is the > simplest method of acquiring the required mechanisms. Consequently, the > RECOMMENDED alternative to the UDP usage described in the remainder of this > section is the use of an IETF transport protocol such as TCP [RFC0793], > Stream Control Transmission Protocol (SCTP) [RFC4960], and SCTP Partial > Reliability Extension (SCTP-PR) [RFC3758], or Datagram Congestion Control > Protocol (DCCP) [RFC4340] with its different congestion control types > [RFC4341][RFC4342][RFC5622]." > > > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > From nobody Tue Nov 3 07:30: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 B30C21A21AB for ; Tue, 3 Nov 2015 07:30:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.451 X-Spam-Level: X-Spam-Status: No, score=-0.451 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_DNSWL_NONE=-0.0001] 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 aj-Co-pqskeQ for ; Tue, 3 Nov 2015 07:30:42 -0800 (PST) Received: from atl4mhob04.myregisteredsite.com (atl4mhob04.myregisteredsite.com [209.17.115.42]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB571A21B4 for ; Tue, 3 Nov 2015 07:30:42 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.208]) by atl4mhob04.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id tA3FUe3w022856 for ; Tue, 3 Nov 2015 10:30:40 -0500 Received: (qmail 26492 invoked by uid 0); 3 Nov 2015 15:30:39 -0000 X-TCPREMOTEIP: 24.166.126.82 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.0.137?) (wes@mti-systems.com@24.166.126.82) by 0 with ESMTPA; 3 Nov 2015 15:30:39 -0000 To: Aaron Falk , tsvwg@ietf.org References: From: Wesley Eddy Message-ID: <5638D31B.4080801@mti-systems.com> Date: Tue, 3 Nov 2015 10:30:35 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: dots@ietf.org Subject: Re: [Dots] Best transport selection during an attack? 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, 03 Nov 2015 15:30:46 -0000 On 11/3/2015 12:42 AM, Aaron Falk wrote: > Dear TSV- > > There was a discussion in DDoS Open Threat Signaling (DOTS) this > afternoon about selecting a transport that is likely to be able to > carry an "SOS" message when a network is under DDOS. UDP gets > filtered. TCP may have trouble getting ACKs back through a congested > link. They'd like some advice. I suggested they come to the TSV Area > meeting (but there isn't one). So, can the chairs give a few minutes > from TSVWG to layout the problem? The signaling shouldn't be high-bandwidth, so supporting multiple options, and using all available options, hoping at least one gets through, seems totally feasible to me. The messaging just needs to be able to support de-duplication, in case multiple signaling channels happen to work. Obviously any UDP-based options will be expected to follow the TSVWG UDP Guidelines RFC. Whether or not UDP will work between networks can be tested and determined ahead of time, so resolving UDP-blocking problems can be dealt with in non-realtime (the same problem may exist for blocking of unknown TCP ports anyways, so testing of the signaling channel should always be done in nominal conditions, ahead of when its needed for attack response). I don't think there are any real obstacles to having a UDP-based option, it's just that it seems like a good idea to have other options. Using AQM with flow-based hashing like fq_codel on the congested link may help a bit with the TCP ACK problem, as well, but of course that's outside the protocol. That same problem impacts SCTP. From nobody Tue Nov 3 08:22: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 AD3BA1A6F6F; Tue, 3 Nov 2015 08:22:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 DT_-ZTDi2qb6; Tue, 3 Nov 2015 08:22:27 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 0F2DD1A873B; Tue, 3 Nov 2015 08:22:27 -0800 (PST) Received: by wmeg8 with SMTP id g8so19317278wme.1; Tue, 03 Nov 2015 08:22:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gACG3TdZUDvDAtZgogokr/80dC2jSeDPvKAumchnKng=; b=yhoooQ2TL/41BqJ3AiqVRwddu/WWWAX9qBkWd2/TL1ynq5xSB3y3r2I7bFIYhoPkaa JabiBEqoLrANpUdOgEdtMzgNNhQ4Goa8YWObfdg8sbl3ufZShHVlyNjJXK4/I9iMHW9D KKMVc9xTHqJnT62h2SzE7UMSJx6wPY6QrNSpBLpbpDcMYf+qD8Yu6mpCJXCEqZyBpHP8 6H5O2sodCpFMZk3TvBRnTE6Jqx3om1v782jhNZDdrnGpgUEX49r8bRGNARuhzvYm6/nT 2YjilMrO/VIpb99KmeYFBe4kHeedrwGSLud3jCtMj/Mx5XwbR4c/KzT74oKLFCk/GRH9 rTww== MIME-Version: 1.0 X-Received: by 10.28.51.70 with SMTP id z67mr19214408wmz.25.1446567745511; Tue, 03 Nov 2015 08:22:25 -0800 (PST) Received: by 10.194.174.130 with HTTP; Tue, 3 Nov 2015 08:22:25 -0800 (PST) In-Reply-To: <5638D31B.4080801@mti-systems.com> References: <5638D31B.4080801@mti-systems.com> Date: Tue, 3 Nov 2015 08:22:25 -0800 Message-ID: From: Ca By To: Wesley Eddy Content-Type: multipart/alternative; boundary=001a114432fc9d68e60523a54c9e Archived-At: Cc: Aaron Falk , "tsvwg@ietf.org" , dots@ietf.org Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 03 Nov 2015 16:22:28 -0000 --001a114432fc9d68e60523a54c9e Content-Type: text/plain; charset=UTF-8 On Tue, Nov 3, 2015 at 7:30 AM, Wesley Eddy wrote: > On 11/3/2015 12:42 AM, Aaron Falk wrote: > >> Dear TSV- >> >> There was a discussion in DDoS Open Threat Signaling (DOTS) this >> afternoon about selecting a transport that is likely to be able to carry an >> "SOS" message when a network is under DDOS. UDP gets filtered. TCP may >> have trouble getting ACKs back through a congested link. They'd like some >> advice. I suggested they come to the TSV Area meeting (but there isn't >> one). So, can the chairs give a few minutes from TSVWG to layout the >> problem? >> > > > > The signaling shouldn't be high-bandwidth, so supporting multiple options, > and using all available options, hoping at least one gets through, seems > totally feasible to me. The messaging just needs to be able to support > de-duplication, in case multiple signaling channels happen to work. > > Obviously any UDP-based options will be expected to follow the TSVWG UDP > Guidelines RFC. Whether or not UDP will work between networks can be > tested and determined ahead of time, so resolving UDP-blocking problems can > be dealt with in non-realtime (the same problem may exist for blocking of > unknown TCP ports anyways, so testing of the signaling channel should > always be done in nominal conditions, ahead of when its needed for attack > response). I don't think there are any real obstacles to having a > UDP-based option, it's just that it seems like a good idea to have other > options. > > This is not correct, at least in the case i am most familiar with. Check this diagram https://twitter.com/theipv6guy/status/623535325915168768 The dotty yellow lines that cross the blue lines represent the packet loss that UDP policers cause \ absorb during a UDP DDoS attack. With DOTS in UDP, you are putting the DOTs traffic in that path that becomes the most lossy during a a DDoS. > Using AQM with flow-based hashing like fq_codel on the congested link may > help a bit with the TCP ACK problem, as well, but of course that's outside > the protocol. That same problem impacts SCTP. > > > > --001a114432fc9d68e60523a54c9e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Nov 3, 2015 at 7:30 AM, Wesley Eddy <wes@mti-systems.com= > wrote:
On 11/3/2015 12:42 = AM, Aaron Falk wrote:
Dear TSV-

There was a discussion in DDoS Open Threat Signaling (DOTS) this afternoon = about selecting a transport that is likely to be able to carry an "SOS= " message when a network is under DDOS.=C2=A0 UDP gets filtered.=C2=A0= TCP may have trouble getting ACKs back through a congested link.=C2=A0 The= y'd like some advice.=C2=A0 I suggested they come to the TSV Area meeti= ng (but there isn't one).=C2=A0 So, can the chairs give a few minutes f= rom TSVWG to layout the problem?



 The signaling shouldn't be high-bandwidth, so supporting multiple optio= ns, and using all available options, hoping at least one gets through, seem= s totally feasible to me.=C2=A0 The messaging just needs to be able to supp= ort de-duplication, in case multiple signaling channels happen to work.

Obviously any UDP-based options will be expected to follow the TSVWG UDP Gu= idelines RFC.=C2=A0 Whether or not UDP will work between networks can be te= sted and determined ahead of time, so resolving UDP-blocking problems can b= e dealt with in non-realtime (the same problem may exist for blocking of un= known TCP ports anyways, so testing of the signaling channel should always = be done in nominal conditions, ahead of when its needed for attack response= ).=C2=A0 I don't think there are any real obstacles to having a UDP-bas= ed option, it's just that it seems like a good idea to have other optio= ns.


This is not correct, at least in the c= ase i am most familiar with.



--001a114432fc9d68e60523a54c9e-- From nobody Tue Nov 3 08:30: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 E8A251A874C for ; Tue, 3 Nov 2015 08:30:51 -0800 (PST) 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 OYhScvwfajfQ for ; Tue, 3 Nov 2015 08:30:50 -0800 (PST) Received: from atl4mhob14.myregisteredsite.com (atl4mhob14.myregisteredsite.com [209.17.115.52]) by ietfa.amsl.com (Postfix) with ESMTP id 91CA21A8732 for ; Tue, 3 Nov 2015 08:30:50 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.205]) by atl4mhob14.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id tA3GUmaR003899 for ; Tue, 3 Nov 2015 11:30:48 -0500 Received: (qmail 26402 invoked by uid 0); 3 Nov 2015 16:30:48 -0000 X-TCPREMOTEIP: 24.166.126.82 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.0.137?) (wes@mti-systems.com@24.166.126.82) by 0 with ESMTPA; 3 Nov 2015 16:30:48 -0000 To: Ca By References: <5638D31B.4080801@mti-systems.com> From: Wesley Eddy Message-ID: <5638E134.7050303@mti-systems.com> Date: Tue, 3 Nov 2015 11:30:44 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Aaron Falk , "tsvwg@ietf.org" , dots@ietf.org Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 03 Nov 2015 16:30:52 -0000 On 11/3/2015 11:22 AM, Ca By wrote: > > With DOTS in UDP, you are putting the DOTs traffic in that path that > becomes the most lossy during a a DDoS. > You might have missed that I suggested to use multiple signaling channels, an dnot rely on UDP? From nobody Tue Nov 3 08:42: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 174411A8870 for ; Tue, 3 Nov 2015 08:42:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 70mXukbiXjtc for ; Tue, 3 Nov 2015 08:42:45 -0800 (PST) Received: from Mail2.SpriteLink.NET (Mail2.SpriteLink.NET [195.182.5.83]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEEDA1A87E2 for ; Tue, 3 Nov 2015 08:42:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by Mail2.SpriteLink.NET (Postfix) with ESMTP id 58FF0261848 for ; Tue, 3 Nov 2015 17:42:43 +0100 (CET) X-Virus-Scanned: amavisd-new at SpriteLink.NET Received: from Mail2.SpriteLink.NET ([195.182.5.83]) by localhost (Mail2.SpriteLink.NET [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QlFbuvZlJiGm for ; Tue, 3 Nov 2015 17:42:40 +0100 (CET) Received: from Kristians-MacBook-Pro.local (c-1a95e253.041-205-73746f13.cust.bredbandsbolaget.se [83.226.149.26]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: kristian@spritelink.net) by Mail2.SpriteLink.NET (Postfix) with ESMTPSA id E7FA7261846 for ; Tue, 3 Nov 2015 17:42:40 +0100 (CET) To: dots@ietf.org References: <5638D31B.4080801@mti-systems.com> From: Kristian Larsson Message-ID: <5638E400.2000906@spritelink.net> Date: Tue, 3 Nov 2015 17:42:40 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.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] [tsvwg] Best transport selection during an attack? 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, 03 Nov 2015 16:42:47 -0000 On 03/11/15 17:22, Ca By wrote: > > > On Tue, Nov 3, 2015 at 7:30 AM, Wesley Eddy > wrote: > > On 11/3/2015 12:42 AM, Aaron Falk wrote: > > Dear TSV- > > There was a discussion in DDoS Open Threat Signaling (DOTS) this > afternoon about selecting a transport that is likely to be able > to carry an "SOS" message when a network is under DDOS. UDP > gets filtered. TCP may have trouble getting ACKs back through a > congested link. They'd like some advice. I suggested they come > to the TSV Area meeting (but there isn't one). So, can the > chairs give a few minutes from TSVWG to layout the problem? > > > > > The signaling shouldn't be high-bandwidth, so supporting multiple > options, and using all available options, hoping at least one gets > through, seems totally feasible to me. The messaging just needs to > be able to support de-duplication, in case multiple signaling > channels happen to work. > > Obviously any UDP-based options will be expected to follow the TSVWG > UDP Guidelines RFC. Whether or not UDP will work between networks > can be tested and determined ahead of time, so resolving > UDP-blocking problems can be dealt with in non-realtime (the same > problem may exist for blocking of unknown TCP ports anyways, so > testing of the signaling channel should always be done in nominal > conditions, ahead of when its needed for attack response). I don't > think there are any real obstacles to having a UDP-based option, > it's just that it seems like a good idea to have other options. > > > This is not correct, at least in the case i am most familiar with. > > Check this diagram > > https://twitter.com/theipv6guy/status/623535325915168768 > > The dotty yellow lines that cross the blue lines represent the packet > loss that UDP policers cause \ absorb during a UDP DDoS attack. Surely this is for the opposite direction. Quic is used to fetch web pages so the request is small but the response is much bigger and that response might run into various policers. DOTS is only looking at sending a small packet. An incoming UDP based attack shouldn't influence that much. Kind regards, Kristian. From nobody Tue Nov 3 09:42:43 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 57F831A87A4 for ; Tue, 3 Nov 2015 09:42:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 YDxvhddXdGF5 for ; Tue, 3 Nov 2015 09:42:40 -0800 (PST) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::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 51DD21B3344 for ; Tue, 3 Nov 2015 09:42:40 -0800 (PST) Received: by ykek133 with SMTP id k133so28469377yke.2 for ; Tue, 03 Nov 2015 09:42:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isi_edu.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3Nmvkr8xaCeiTp6E8692EPr341YGqU65/KwMKFxwLUM=; b=kMlmtvR0q1AWQsuyzmFek5GAwnqgYG9bPQ0zsHxeRrUG8ZECWfY6T9AD0C9l0l7JdC okqASpa3/sc6LL06u7we37QddSfMZeW3IxW8/k4lQRU00Lr1HHo6WHEKYRG78FXNPSrO EQG79YbyYX9VDipLb9gdrDE9KnC/9MY2Q1/WutY/g6GGcikS1GPYIjfp2Mja53xIxDCN yV01c+ERmZTzycxxiy+gM4fs1bnoI8Fgm/4cp01wbbDD7RW8spAsfwCxcxUEr7DOP9ua vRn012w9pdJC3LGIl9CvA4AXnxA4y9yL3jO16zV94cZdhTjmFkwj3eLboQQQimpG0ByL G9lA== 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=3Nmvkr8xaCeiTp6E8692EPr341YGqU65/KwMKFxwLUM=; b=i1bbu9p01lqqk3Xr2tIBG/dzZs6bSr1FKBvbgwMVUrGspEJ/JLM9COuuE0k7+SOKFY TQIlpjgEHdS95onoDnogZrpk3IoIEFGsCfFLyw+tz3iQXHNcwUQc3D+LYszHX5W8ddrz FLWbchJtaZan4Ukx2wydOyLEvyuBJi4R1uBH5O3Yk8FLeG4FKqLD/1/C0/ZuvR7O9sYq 8icgr5mFSRFS29IBiGLzD0KzywLoH9paM6FYAj0Ky7sWOGQcm1YvkLbTgEYmxkST0VNP QGIBlrzogA4d+Dn/LoMJc0NW2U0O+8h0XNrktCkXssOlZ5CLHMvOEYxHhwjFNG+rGRp8 KrrQ== X-Gm-Message-State: ALoCoQm/yFi98MrdSGKDxitpxYTnfZSD9SexM61BDiXaJ8vxRmN23tffx2FAMPiDDtP5wmRis+tS MIME-Version: 1.0 X-Received: by 10.31.138.72 with SMTP id m69mr19466696vkd.66.1446572559482; Tue, 03 Nov 2015 09:42:39 -0800 (PST) Received: by 10.31.13.146 with HTTP; Tue, 3 Nov 2015 09:42:39 -0800 (PST) In-Reply-To: <5638E400.2000906@spritelink.net> References: <5638D31B.4080801@mti-systems.com> <5638E400.2000906@spritelink.net> Date: Tue, 3 Nov 2015 09:42:39 -0800 Message-ID: From: Jelena Mirkovic To: Kristian Larsson Content-Type: multipart/alternative; boundary=001a114563228cd7670523a66b41 Archived-At: Cc: dots@ietf.org Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 03 Nov 2015 17:42:42 -0000 --001a114563228cd7670523a66b41 Content-Type: text/plain; charset=UTF-8 I might have missed some context. Is there supporting evidence that TCP ACKs have that much of a trouble getting through? First, they are small packets and should fit into an almost full router queue by that virtue, whereas data packets won't. Second, they are resent by TCP. Third, it should be fairly easy to craft a filter that lets ACKs through at any level (victim or first-hop ISP). So, while I second Wes's idea for multiple channels is there strong operational evidence that ACKs indeed have a problem? Note that DDoS is a game of probability. X legitimate bytes + Y attack bytes (Y>>X) are trying to fit a limited N sized link. Legitimate bytes always have a non zero chance of getting through. ========================= Jelena Mirkovic Research Faculty USC Information Sciences Institute 4676 Admiralty Way, Suite 1001 Marina del Rey, CA 90292 310-448-9170 On Tue, Nov 3, 2015 at 8:42 AM, Kristian Larsson wrote: > > > On 03/11/15 17:22, Ca By wrote: > >> >> >> On Tue, Nov 3, 2015 at 7:30 AM, Wesley Eddy > > wrote: >> >> On 11/3/2015 12:42 AM, Aaron Falk wrote: >> >> Dear TSV- >> >> There was a discussion in DDoS Open Threat Signaling (DOTS) this >> afternoon about selecting a transport that is likely to be able >> to carry an "SOS" message when a network is under DDOS. UDP >> gets filtered. TCP may have trouble getting ACKs back through a >> congested link. They'd like some advice. I suggested they come >> to the TSV Area meeting (but there isn't one). So, can the >> chairs give a few minutes from TSVWG to layout the problem? >> >> >> >> >> The signaling shouldn't be high-bandwidth, so supporting multiple >> options, and using all available options, hoping at least one gets >> through, seems totally feasible to me. The messaging just needs to >> be able to support de-duplication, in case multiple signaling >> channels happen to work. >> >> Obviously any UDP-based options will be expected to follow the TSVWG >> UDP Guidelines RFC. Whether or not UDP will work between networks >> can be tested and determined ahead of time, so resolving >> UDP-blocking problems can be dealt with in non-realtime (the same >> problem may exist for blocking of unknown TCP ports anyways, so >> testing of the signaling channel should always be done in nominal >> conditions, ahead of when its needed for attack response). I don't >> think there are any real obstacles to having a UDP-based option, >> it's just that it seems like a good idea to have other options. >> >> >> This is not correct, at least in the case i am most familiar with. >> >> Check this diagram >> >> https://twitter.com/theipv6guy/status/623535325915168768 >> >> The dotty yellow lines that cross the blue lines represent the packet >> loss that UDP policers cause \ absorb during a UDP DDoS attack. >> > > Surely this is for the opposite direction. Quic is used to fetch web pages > so the request is small but the response is much bigger and that response > might run into various policers. > > DOTS is only looking at sending a small packet. An incoming UDP based > attack shouldn't influence that much. > > Kind regards, > Kristian. > > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > --001a114563228cd7670523a66b41 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I might have missed some context. Is there supporting evid= ence that TCP ACKs have that much of a trouble getting through? First, they= are small packets and should fit into an almost full router queue by that = virtue, whereas data packets won't. Second, they are resent by TCP. Thi= rd, it should be fairly easy to craft a filter that lets ACKs through at an= y level (victim or first-hop ISP). So, while I second Wes's idea for mu= ltiple channels is there strong operational evidence that ACKs indeed have = a problem?

Note that DDoS is a game of probability. X le= gitimate bytes + Y attack bytes (Y>>X) are trying to fit a limited N = sized link. Legitimate bytes always have a non zero chance of getting throu= gh.

=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, Nov 3, 2015 at 8:42 AM, Kristian Lar= sson <kristian@spritelink.net> wrote:


On 03/11/15 17:22, Ca By wrote:


On Tue, Nov 3, 2015 at 7:30 AM, Wesley Eddy <wes@mti-systems.com
<mailto:wes@mti= -systems.com>> wrote:

=C2=A0 =C2=A0 On 11/3/2015 12:42 AM, Aaron Falk wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Dear TSV-

=C2=A0 =C2=A0 =C2=A0 =C2=A0 There was a discussion in DDoS Open Threat Sign= aling (DOTS) this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 afternoon about selecting a transport that is l= ikely to be able
=C2=A0 =C2=A0 =C2=A0 =C2=A0 to carry an "SOS" message when a netw= ork is under DDOS.=C2=A0 UDP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 gets filtered.=C2=A0 TCP may have trouble getti= ng ACKs back through a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 congested link.=C2=A0 They'd like some advi= ce.=C2=A0 I suggested they come
=C2=A0 =C2=A0 =C2=A0 =C2=A0 to the TSV Area meeting (but there isn't on= e).=C2=A0 So, can the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 chairs give a few minutes from TSVWG to layout = the problem?




=C2=A0 =C2=A0 The signaling shouldn't be high-bandwidth, so supporting = multiple
=C2=A0 =C2=A0 options, and using all available options, hoping at least one= gets
=C2=A0 =C2=A0 through, seems totally feasible to me.=C2=A0 The messaging ju= st needs to
=C2=A0 =C2=A0 be able to support de-duplication, in case multiple signaling=
=C2=A0 =C2=A0 channels happen to work.

=C2=A0 =C2=A0 Obviously any UDP-based options will be expected to follow th= e TSVWG
=C2=A0 =C2=A0 UDP Guidelines RFC.=C2=A0 Whether or not UDP will work betwee= n networks
=C2=A0 =C2=A0 can be tested and determined ahead of time, so resolving
=C2=A0 =C2=A0 UDP-blocking problems can be dealt with in non-realtime (the = same
=C2=A0 =C2=A0 problem may exist for blocking of unknown TCP ports anyways, = so
=C2=A0 =C2=A0 testing of the signaling channel should always be done in nom= inal
=C2=A0 =C2=A0 conditions, ahead of when its needed for attack response).=C2= =A0 I don't
=C2=A0 =C2=A0 think there are any real obstacles to having a UDP-based opti= on,
=C2=A0 =C2=A0 it's just that it seems like a good idea to have other op= tions.


This is not correct, at least in the case i am most familiar with.

Check this diagram

https://twitter.com/theipv6guy/status/623535= 325915168768

The dotty yellow lines that cross the blue lines represent the packet
loss that UDP policers cause \ absorb during a UDP DDoS attack.

Surely this is for the opposite direction. Quic is used to fetch web pages = so the request is small but the response is much bigger and that response m= ight run into various policers.

DOTS is only looking at sending a small packet. An incoming UDP based attac= k shouldn't influence that much.

Kind regards,
=C2=A0 =C2=A0 Kristian.


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

--001a114563228cd7670523a66b41-- From nobody Tue Nov 3 10:06: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 8D11F1B342E; Tue, 3 Nov 2015 10:06:24 -0800 (PST) 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 KI_A0JQpta2Q; Tue, 3 Nov 2015 10:06:23 -0800 (PST) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.209]) (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 B2E321B342C; Tue, 3 Nov 2015 10:06:22 -0800 (PST) Received: from [216.82.241.211] by server-17.bemta-8.messagelabs.com id 10/26-02819-D97F8365; Tue, 03 Nov 2015 18:06:21 +0000 X-Env-Sender: Stefan.Fouant@corero.com X-Msg-Ref: server-13.tower-85.messagelabs.com!1446573981!5186278!1 X-Originating-IP: [71.184.227.49] X-StarScan-Received: X-StarScan-Version: 7.19.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2456 invoked from network); 3 Nov 2015 18:06:21 -0000 Received: from mercury.corero.com (HELO MERCURY.corero.com) (71.184.227.49) by server-13.tower-85.messagelabs.com with AES128-SHA encrypted SMTP; 3 Nov 2015 18:06:21 -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; Tue, 3 Nov 2015 13:06:21 -0500 From: Stefan Fouant To: Christopher Morrow , Ca By Thread-Topic: [Dots] [tsvwg] Best transport selection during an attack? Thread-Index: AQHRFkiPbmPUbdP/E0St0CItMWMwcJ6Kuh+AgADIr4A= Date: Tue, 3 Nov 2015 18:06:20 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [113.157.253.130] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7DDD233B66108342A2FA38FB313DFDF7@corero.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Aaron Falk , "tsvwg@ietf.org" , "dots@ietf.org" Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 03 Nov 2015 18:06:24 -0000 On 11/4/15, 12:08 AM, "Dots on behalf of Christopher Morrow" wrote: >for the data in question, the need is a packet which: > 1) is not going to require state be maintained from client -> server > 2) not require an ACK from the server (or management of a session at all > 3) not need many / any round-trips in order to get the job done > >The thought expressed in slideware (and txt I believe) was: > "Be able to send from client -> server a packet with: > auth token > 'help!' message > " > >udp seems to fit the bill.. I suppose someone could just crap out a >raw IP packet with the data, because why bother putting an L4 header >at all? As it seems like there is not a general consensus here, and there are valid points for both a connection-oriented and connection-less approach, wouldn=B9t it be feasible to have both? While I do agree with your points above, I can see the case for a stateful approach so that a DOTS client can receive notification that the request went through... Of course, such a response may never come if the link is saturated, but not all attacks are link saturating. In these cases there is tremendous value to confirmation of a received request. If not, a fallback mechanism can kick in and employ the use of UDP. Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI, CISSP Senior Security Engineer Corero Network Security Mobile: +1.703.625.6243 From nobody Tue Nov 3 11:37: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 DA9081A6FE5 for ; Tue, 3 Nov 2015 11:37:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 HFj-rt0j0Ks8 for ; Tue, 3 Nov 2015 11:37:16 -0800 (PST) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) by ietfa.amsl.com (Postfix) with ESMTP id 228BC1A6FAD for ; Tue, 3 Nov 2015 11:37:16 -0800 (PST) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by WTL-EXCHP-3.sandvine.com (192.168.196.177) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 3 Nov 2015 14:37:17 -0500 Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([fe80::6c6d:7108:c63c:9055%14]) with mapi id 14.03.0181.006; Tue, 3 Nov 2015 14:37:15 -0500 From: Dave Dolson To: Roland Dobbins , "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-requirements-00.txt Thread-Index: AQHRFHWAA72N17GeHEOBJOqaqqVLS56JHKpwgAFOSgCAAEo5fg== Date: Tue, 3 Nov 2015 19:37:17 +0000 Message-ID: <20151103193713.594948115.49782.45699@sandvine.com> References: <20151019172722.23547.45444.idtracker@ietfa.amsl.com> , <1837A898-7562-4449-AEDB-EEF8CA9E099A@arbor.net> In-Reply-To: <1837A898-7562-4449-AEDB-EEF8CA9E099A@arbor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-00.txt 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, 03 Nov 2015 19:37:19 -0000 As I understand the purpose of =FDthe security section, you should nonethel= ess document the issue. But I'm not sure that rate-limiting DOTS events should be out of the questi= on. E.g. Dime WG added rate feedback and control to Diameter protocol even thou= gh one could point to the problem of "too many users joining the network at= once" as out of scope. Original Message From: Roland Dobbins Sent: Tuesday, November 3, 2015 7:11 PM To: dots@ietf.org Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-00.txt On 3 Nov 2015, at 4:38, Dave Dolson wrote: > I don't think it's purely theoretical; it could occur with threshold > settings that are too low (na=EFve or mistakes). This isn't a DOTS-specific issue; it's the realm of the detection/classification/traceback/mitigation systems which may be DOTS-enabled. So, this is really out of bounds for DOTS, which is merely a messaging system. ----------------------------------- Roland Dobbins _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Tue Nov 3 11:43:18 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 4B5651A7001 for ; Tue, 3 Nov 2015 11:43:17 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7, 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 4BvGqWi8ZTkC for ; Tue, 3 Nov 2015 11:43:16 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 5E6561A6FFD for ; Tue, 3 Nov 2015 11:43:16 -0800 (PST) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by WTL-EXCHP-2.sandvine.com (192.168.194.177) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 3 Nov 2015 14:43:18 -0500 Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([fe80::6c6d:7108:c63c:9055%14]) with mapi id 14.03.0181.006; Tue, 3 Nov 2015 14:43:15 -0500 From: Dave Dolson To: dots Thread-Topic: Using Diameter transport for DOTS? Thread-Index: AdEWb+LjKy2VsZZAT7KTysuTEiK/GQ== Date: Tue, 3 Nov 2015 19:43:17 +0000 Message-ID: <20151103194312.594948115.52080.45702@sandvine.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-ID: <45052E7228E0C2449BA269377DADA983@sandvine.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [Dots] Using Diameter transport for DOTS? 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, 03 Nov 2015 19:43:17 -0000 Q291bGQgRGlhbWV0ZXIgc2F0aXNmeSB0aGUgdHJhbnNwb3J0IHByb3RvY29sIG5lZWRzIG9mIERP VFM/DQpJdCBhbHJlYWR5IGhhcyBzZWN1cml0eSwgbXV0dWFsIGF1dGhlbnRpY2F0aW9uLCBib3Ro IGRhdGFncmFtIChTQ1RQKSBhbmQgVENQIHRyYW5zcG9ydHPigI4sIHdhdGNoZG9nIHRpbWVycywg cmVkdW5kYW5jeSwgdGhlIGNvbmNlcHQgb2YgcmVsYXlzLi4uDQoNCi1EYXZlDQoNCg== From nobody Tue Nov 3 12:26: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 3093E1B2FB6 for ; Tue, 3 Nov 2015 12:26:43 -0800 (PST) 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 phCo8MqE-4au for ; Tue, 3 Nov 2015 12:26:42 -0800 (PST) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::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 C1B351B34BE for ; Tue, 3 Nov 2015 12:26:41 -0800 (PST) Received: by qkcl124 with SMTP id l124so11761928qkc.3 for ; Tue, 03 Nov 2015 12:26:40 -0800 (PST) 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=b6Jq1eNmuajd9kNVbtRceC9GbnOl0MtP9/qUbVds/TM=; b=Bd/I5VqJT99Vt8gUVEmHd9QAQh18rG8r2IhLKdXbr1fNUZZXQ/TrKorU+z3Eb0EZDa LfzjQgdulSeEPwhMhCUywaVErBrpYH0WF3oWgNtzy3kbORejYtVPZln04IOw1ihuHw60 Uf6sKFLbC/wH7mQda/ANzOnOboFrIZbxklhy1bIzhxFaEWU9B+mzhJ3DBT9lrnDS+uvu Pdvbuc6wB6AzQVObjQb27nqfGtaqQP7hImeg/EnAIYZOykmFt0t35e94xwGmeRezFxVg nnA9IaWnfUZPwgyi839w+HqmCqZ6/+xlnCaQLqT8Hhp29yJHU1haIhlOY86U9epjEzTY 4K+w== X-Received: by 10.55.212.70 with SMTP id l67mr39972820qki.7.1446582400767; Tue, 03 Nov 2015 12:26:40 -0800 (PST) Received: from [10.206.162.123] (mobile-107-107-60-208.mycingular.net. [107.107.60.208]) by smtp.gmail.com with ESMTPSA id f90sm10333758qga.26.2015.11.03.12.26.39 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Nov 2015 12:26:40 -0800 (PST) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (12H143) In-Reply-To: <20151103194312.594948115.52080.45702@sandvine.com> Date: Tue, 3 Nov 2015 15:26:36 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <156C879E-5525-45A2-B2B0-0D11698C54AC@gmail.com> References: <20151103194312.594948115.52080.45702@sandvine.com> To: Dave Dolson Archived-At: Cc: dots Subject: Re: [Dots] Using Diameter transport for DOTS? 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, 03 Nov 2015 20:26:43 -0000 I thought end-to-end crypto hasn't been solved for Diameter yet... Thanks, Kathleen=20 Sent from my iPhone > On Nov 3, 2015, at 2:43 PM, Dave Dolson wrote: >=20 > Could Diameter satisfy the transport protocol needs of DOTS? > It already has security, mutual authentication, both datagram (SCTP) and T= CP transports=E2=80=8E, watchdog timers, redundancy, the concept of relays..= . >=20 > -Dave >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Tue Nov 3 12:27: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 9480E1B34C2 for ; Tue, 3 Nov 2015 12:27:36 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7, 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 Ej95agU13euF for ; Tue, 3 Nov 2015 12:27:35 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 153D11B34BE for ; Tue, 3 Nov 2015 12:27:35 -0800 (PST) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by WTL-EXCHP-2.sandvine.com (192.168.194.177) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 3 Nov 2015 15:27:36 -0500 Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([fe80::6c6d:7108:c63c:9055%14]) with mapi id 14.03.0181.006; Tue, 3 Nov 2015 15:27:34 -0500 From: Dave Dolson To: Roland Dobbins , "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-use-cases-00.txt Thread-Index: AQHRFHV6rwGUQR3pPU2YODuE392pVJ6JEC3QgACjtQCAAQ5TsA== Date: Tue, 3 Nov 2015 20:27:35 +0000 Message-ID: References: <20151019162243.18886.94206.idtracker@ietfa.amsl.com> <7990C2F1-6EE9-473E-A45C-097B894F2F51@arbor.net> In-Reply-To: <7990C2F1-6EE9-473E-A45C-097B894F2F51@arbor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [183.77.156.199] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-use-cases-00.txt 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, 03 Nov 2015 20:27:36 -0000 Roland, Thanks. It seems to me that the use-cases document is actually an architecture docu= ment, in the sense that it describes all of the architectural components an= d interfaces. I don't see any architectural freedom. I'm not saying that's inherently bad, just my sense of it. -Dave -----Original Message----- From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Roland Dobbins Sent: Tuesday, November 03, 2015 8:16 AM To: dots@ietf.org Subject: Re: [Dots] I-D Action: draft-ietf-dots-use-cases-00.txt On 3 Nov 2015, at 3:48, Dave Dolson wrote: > Is it intentional that the use-cases effectively lay out the protocol,=20 > not in the message format but in the sense of who says what to whom,=20 > which commands and information are conveyed from client to server and=20 > vice versa? Yes, in terms of operationally-significant information flow and information= al checkpoints. > Example: it seems that the use-cases document requires a server-pushes=20 > model (vs. a client-polls model) for the status updates. Server can push from its perspective, client can push from its perspective,= both can poll. In the examples in question, status updates regarding ongoing mitigation ar= e natural and expected from the system(s) doing the actual mitigating.=20 Likewise, updates on the efficacy of said mitigation are natural and expe= cted from the system(s) southbound of said mitigation. Does this make sense? > Was that level of specificity intended? Yes, in the context of the specific examples in question - but not as a lim= itation - see above. ----------------------------------- Roland Dobbins _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Tue Nov 3 12:54: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 A67961B3557 for ; Tue, 3 Nov 2015 12:54:49 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7, 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 YD-CoPupkzur for ; Tue, 3 Nov 2015 12:54:46 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id CE3391B3552 for ; Tue, 3 Nov 2015 12:54:45 -0800 (PST) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by wtl-exchp-1.sandvine.com (192.168.194.176) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 3 Nov 2015 15:54:45 -0500 Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([fe80::6c6d:7108:c63c:9055%14]) with mapi id 14.03.0181.006; Tue, 3 Nov 2015 15:54:44 -0500 From: Dave Dolson To: Kathleen Moriarty Thread-Topic: [Dots] Using Diameter transport for DOTS? Thread-Index: AdEWb+LjKy2VsZZAT7KTysuTEiK/GQAL/W0AAApUjgA= Date: Tue, 3 Nov 2015 20:54:46 +0000 Message-ID: References: <20151103194312.594948115.52080.45702@sandvine.com> <156C879E-5525-45A2-B2B0-0D11698C54AC@gmail.com> In-Reply-To: <156C879E-5525-45A2-B2B0-0D11698C54AC@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [183.77.156.199] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: dots Subject: Re: [Dots] Using Diameter transport for DOTS? 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, 03 Nov 2015 20:54:49 -0000 DQpJcyBlbmQtdG8tZW5kIGNyeXB0byByZXF1aXJlZCBpbiBET1RTLCBnaXZlbiBob3AtYnktaG9w IHNlY3VyaXR5IGlzIGdvb2Q/DQpbTm90IGludGVuZGVkIGFzIGEgcmhldG9yaWNhbCBxdWVzdGlv bi5dDQpUbyB0aG9zZSBub3QgZmFtaWxpYXIgd2l0aCBEaWFtZXRlciwgaW4gdGhlIERPVFMgY29u dGV4dCwgdGhlIGNsaWVudC10by1wcm94eSBhbmQgcHJveHktdG8tc2VydmVyIGNvbm5lY3Rpb25z IHdvdWxkIGJlIHNlY3VyZSBhbmQgZW5jcnlwdGVkLCBidXQgdGhlIHByb3h5IGNvdWxkIHZpZXcg YW5kIG1vZGlmeSBtZXNzYWdlcy4NCg0KSW4gRE9UUywgYXJlIHRoZSBwcm94eSBhbmQgc2VydmVy IGluIHRoZSBzYW1lIG9yIGRpZmZlcmVudCBhZG1pbmlzdHJhdGl2ZSBkb21haW5zLCBvciBpcyB0 aGUgcHJveHkgdHJ1c3RlZD8NCkV2ZW4gc28sIGFyZSB0aGVyZSBtZXNzYWdlcyBjb21wb25lbnRz IHRoYXQgc2hvdWxkIGJlIGhpZGRlbiBmcm9tIHRoZSBwcm94eT8NCg0KUHJhY3RpY2FsbHksIGlm IGl0IGlzIGEgaGFyZCBwcm9ibGVtIGluIERpYW1ldGVyLCBpcyBpdCBhbHNvIGhhcmQgZm9yIERP VFM/DQpDb252ZXJzZWx5LCB3aGVuIGRpbWUgZmlndXJlcyBpdCBvdXQsIGl0IHdvdWxkIGJlIGlu aGVyaXRlZCBmb3IgZnJlZS4NCg0KVGhlIG1vcmUgSSB0aGluayBhYm91dCBpdCwgaXQgc2VlbXMg dG8gbWUgYSBsb3QgZWFzaWVyIHRoYW4gc3RhcnRpbmcgYXQgdGhlIFVEUCBsYXllciBhbmQgaW52 ZW50aW5nIGEgcHJvdG9jb2wgZnJvbSBzY3JhdGNoLg0KU2hvdWxkIERPVFMgYnJhaW5zdG9ybSBv dGhlciBjYW5kaWRhdGUgc2Vzc2lvbi1sYXllciBwcm90b2NvbHMgYXMgd2VsbD8NCg0KLURhdmUN Cg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogS2F0aGxlZW4gTW9yaWFydHkg W21haWx0bzprYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbV0gDQpTZW50OiBXZWRuZXNk YXksIE5vdmVtYmVyIDA0LCAyMDE1IDU6MjcgQU0NClRvOiBEYXZlIERvbHNvbg0KQ2M6IGRvdHMN ClN1YmplY3Q6IFJlOiBbRG90c10gVXNpbmcgRGlhbWV0ZXIgdHJhbnNwb3J0IGZvciBET1RTPw0K DQpJIHRob3VnaHQgZW5kLXRvLWVuZCBjcnlwdG8gaGFzbid0IGJlZW4gc29sdmVkIGZvciBEaWFt ZXRlciB5ZXQuLi4NCg0KVGhhbmtzLA0KS2F0aGxlZW4gDQoNClNlbnQgZnJvbSBteSBpUGhvbmUN Cg0KPiBPbiBOb3YgMywgMjAxNSwgYXQgMjo0MyBQTSwgRGF2ZSBEb2xzb24gPGRkb2xzb25Ac2Fu ZHZpbmUuY29tPiB3cm90ZToNCj4gDQo+IENvdWxkIERpYW1ldGVyIHNhdGlzZnkgdGhlIHRyYW5z cG9ydCBwcm90b2NvbCBuZWVkcyBvZiBET1RTPw0KPiBJdCBhbHJlYWR5IGhhcyBzZWN1cml0eSwg bXV0dWFsIGF1dGhlbnRpY2F0aW9uLCBib3RoIGRhdGFncmFtIChTQ1RQKSBhbmQgVENQIHRyYW5z cG9ydHPigI4sIHdhdGNoZG9nIHRpbWVycywgcmVkdW5kYW5jeSwgdGhlIGNvbmNlcHQgb2YgcmVs YXlzLi4uDQo+IA0KPiAtRGF2ZQ0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gRG90cyBtYWlsaW5nIGxpc3QNCj4gRG90c0BpZXRmLm9yZw0K PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHMNCg== From nobody Tue Nov 3 13:01: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 6431A1A044E for ; Tue, 3 Nov 2015 13:01:37 -0800 (PST) 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 6MNaip5iAEXl for ; Tue, 3 Nov 2015 13:01:31 -0800 (PST) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.197]) (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 C60BA1A022C for ; Tue, 3 Nov 2015 13:01:30 -0800 (PST) Received: from [216.82.242.33] by server-5.bemta-8.messagelabs.com id 84/2C-03226-9A029365; Tue, 03 Nov 2015 21:01:29 +0000 X-Env-Sender: Stefan.Fouant@corero.com X-Msg-Ref: server-11.tower-55.messagelabs.com!1446584489!2571876!1 X-Originating-IP: [71.184.227.49] X-StarScan-Received: X-StarScan-Version: 7.19.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 45319 invoked from network); 3 Nov 2015 21:01:29 -0000 Received: from mercury.corero.com (HELO MERCURY.corero.com) (71.184.227.49) by server-11.tower-55.messagelabs.com with AES128-SHA encrypted SMTP; 3 Nov 2015 21:01:29 -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; Tue, 3 Nov 2015 16:01:29 -0500 From: Stefan Fouant To: Dave Dolson Thread-Topic: [Dots] Using Diameter transport for DOTS? Thread-Index: AdEWb+LjKy2VsZZAT7KTysuTEiK/GQAL/W0AAApUjgD//2NIyA== Date: Tue, 3 Nov 2015 21:01:28 +0000 Message-ID: <4972C21F-5168-4A61-A176-B7FE79439B97@corero.com> References: <20151103194312.594948115.52080.45702@sandvine.com> <156C879E-5525-45A2-B2B0-0D11698C54AC@gmail.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Kathleen Moriarty , dots Subject: Re: [Dots] Using Diameter transport for DOTS? 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, 03 Nov 2015 21:01:37 -0000 > On Nov 4, 2015, at 5:55 AM, Dave Dolson wrote: >=20 >=20 > Is end-to-end crypto required in DOTS, given hop-by-hop security is good? > [Not intended as a rhetorical question.] > To those not familiar with Diameter, in the DOTS context, the client-to-p= roxy and proxy-to-server connections would be secure and encrypted, but the= proxy could view and modify messages. There is no mandate for that requirement DOTS currently, but I can name a f= ew large ISPs that I am talking to who would likely prefer any such signali= ng to be fully encrypted end-to-end as they have a mandate to encrypt or fu= lly privatize any customer related data due to contractual obligations. Stefan Sorry for the typos, on my iPhone. = From nobody Tue Nov 3 13:06: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 36BC21A8747 for ; Tue, 3 Nov 2015 13:06:29 -0800 (PST) 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 o_oXwrt3bqZl for ; Tue, 3 Nov 2015 13:06:27 -0800 (PST) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::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 3BE3C1A01A2 for ; Tue, 3 Nov 2015 13:06:27 -0800 (PST) Received: by iodd200 with SMTP id d200so32873441iod.0 for ; Tue, 03 Nov 2015 13:06:26 -0800 (PST) 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=BWOF0bXu3+w3Utj12JSRoet3rNYzBbqEFqUmjcMytqo=; b=B4yF+TrZYhxr34dsSsjFVaoVxFJUKDEz25CEMje7W69oL/jafOUydUww3ng6ksr6hR NdXYd4GokDHo+aa5QnieW2ILHmVYkJedKoOk5AhDY6nZfIvL5d0b5dDSYRSjPXBByebV /YEgfg3fEAcyy7rHmxEfQUJtmoFUF0HsB3EyU= 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=BWOF0bXu3+w3Utj12JSRoet3rNYzBbqEFqUmjcMytqo=; b=PBbrvLt6bc9JTIuexzHtjd/16hQHx2cwpweRUB2YYsX5nF4RWrJe9bBvTAhoYV6o/8 dF7buGLKgpSKXHo16w3ZMSF4N/e2yQ5L2gYHOZxcjMLr7axC06evWApDYMwKIE4mRVey +/+wWHswLXTyYu9xdSWMRnY5NIbNY83/1QZRLPW7CP3Fj0d6OnPffizpcM6YnrDjEOQo PuDPUzxXh/qeAdWb48BM54yibKoXXz8br1gcEDSVQ6L6zjuRpd9IXg4696bQAIglfSlm zjDOHVx++r1DdvbFDZ0dZ4EGWkLEEPx+wAGiX+6cDH/WyM1kOA+qLhpH56JddSmsz4Ym vzuw== X-Gm-Message-State: ALoCoQki6E3ulwJYwH0C5NKF7YkolAMiZ5xwMwH/GYeGG7iC3l8fgVBBrPhg5T88GUtwtT7Jokfn X-Received: by 10.107.26.12 with SMTP id a12mr30677282ioa.155.1446584786456; Tue, 03 Nov 2015 13:06:26 -0800 (PST) Received: from [192.168.2.101] (i223-218-131-39.s41.a014.ap.plala.or.jp. [223.218.131.39]) by smtp.gmail.com with ESMTPSA id k12sm7622801igt.2.2015.11.03.13.06.25 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Nov 2015 13:06:25 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Andrew Mortensen In-Reply-To: <4972C21F-5168-4A61-A176-B7FE79439B97@corero.com> Date: Tue, 3 Nov 2015 16:06:24 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <98B352C0-D4AD-49A8-A6AE-2C1AB8EEE79D@arbor.net> References: <20151103194312.594948115.52080.45702@sandvine.com> <156C879E-5525-45A2-B2B0-0D11698C54AC@gmail.com> <4972C21F-5168-4A61-A176-B7FE79439B97@corero.com> To: Stefan Fouant X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: Kathleen Moriarty , dots , Dave Dolson Subject: Re: [Dots] Using Diameter transport for DOTS? 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, 03 Nov 2015 21:06:29 -0000 > On Nov 3, 2015, at 4:01 PM, Stefan Fouant = wrote: >=20 >=20 >> On Nov 4, 2015, at 5:55 AM, Dave Dolson wrote: >>=20 >>=20 >> Is end-to-end crypto required in DOTS, given hop-by-hop security is = good? >> [Not intended as a rhetorical question.] >> To those not familiar with Diameter, in the DOTS context, the = client-to-proxy and proxy-to-server connections would be secure and = encrypted, but the proxy could view and modify messages. >=20 > There is no mandate for that requirement DOTS currently, but I can = name a few large ISPs that I am talking to who would likely prefer any = such signaling to be fully encrypted end-to-end as they have a mandate = to encrypt or fully privatize any customer related data due to = contractual obligations. Nor is hop-by-hop security going to be adequate for the use case = Flemming brought up yesterday (service on public cloud signaling a = third-party scrubbing service). andrew= From nobody Tue Nov 3 13:12: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 A7D5D1A89F9 for ; Tue, 3 Nov 2015 13:12:15 -0800 (PST) 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 pj0mhNjeplIt for ; Tue, 3 Nov 2015 13:12:13 -0800 (PST) Received: from atl4mhob03.myregisteredsite.com (atl4mhob03.myregisteredsite.com [209.17.115.41]) by ietfa.amsl.com (Postfix) with ESMTP id C89FD1A8A67 for ; Tue, 3 Nov 2015 13:12:07 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.211]) by atl4mhob03.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id tA3LC33j032240 for ; Tue, 3 Nov 2015 16:12:03 -0500 Received: (qmail 6531 invoked by uid 0); 3 Nov 2015 21:11:20 -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; 3 Nov 2015 21:11:19 -0000 To: dots@ietf.org References: <20151019172722.23547.45444.idtracker@ietfa.amsl.com> <1837A898-7562-4449-AEDB-EEF8CA9E099A@arbor.net> <20151103193713.594948115.49782.45699@sandvine.com> From: Gilbert Clark Message-ID: <563922F6.5010307@mti-systems.com> Date: Tue, 3 Nov 2015 16:11:18 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151103193713.594948115.49782.45699@sandvine.com> Content-Type: text/plain; charset=windows-1256; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-00.txt 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, 03 Nov 2015 21:12:15 -0000 I really don't like the idea of including anything in DOTS that has already been implemented elsewhere without having a good reason to do so. I see a DOTS message as a simple, no-nonsense way to convey a request for help from point A to point B. Additional thoughts inline: On 11/3/2015 2:37 PM, Dave Dolson wrote: > As I understand the purpose of ýthe security section, you should nonetheless document the issue. Could be wrong, but ... I don't believe the security section of a requirements draft is necessarily the same as the security considerations section of an eventual protocol draft. In my head, I see security items included in the requirements draft as being the principles that most influence the eventual design of the DOTS protocol. The security considerations of a DOTS protocol draft would define items that should be considered when deploying or using the protocol. > But I'm not sure that rate-limiting DOTS events should be out of the question. I'm not convinced that the DOTS protocol is the *right place* to include said rate-limiting. Why should we re-invent that particular function here? Additionally, responding to a (related) previous message: > So, perhaps something like this: > DOTS must define protections against attacks on the DOTS infrastructure by an attacker who creates false-positive attack detections. In my mind, DOTS is simply a request for help with some context attached. It doesn't know what a false positive is. Why should *DOTS* be responsible for this? > DOTS must define mechanisms for a client or server to function robustly under high messaging load from its peer(s). Disagree with inclusion in the requirements as stated. Different failure modes can make sense in different cases, and "high messaging load" and "robustly" are both relative. Also, I doubt a network could support updates to mitigation configurations at anything resembling high messaging load: many mitigation strategies will take discrete time to propagate (especially inter-domain) and will consume resources. Flooding a DOTS server with messages for help (or even updates to previous help requests, for that matter) won't make the help come any faster. Thus, I don't see a reason to even bother to try to process these messages at high rate: instead, I'd imagine that someone would apply aggressive rate limits to messages sourced by each individual supplicant, and only worry about supporting high messaging load in the cases it was actually necessary (read: a handful of large providers). > DOTS must define back-off mechanisms so that neither client nor server will overload the peer with messaging. Disagree with inclusion in the requirements as stated. See note about rate-limiting above. Believe this would make a good note in the security considerations section of an eventual protocol draft, however. -Gilbert From nobody Tue Nov 3 13:16: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 F114A1A1B40 for ; Tue, 3 Nov 2015 13:16:01 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7, 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 6zoUT6uADHjh for ; Tue, 3 Nov 2015 13:16:00 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 5E6B61A03A0 for ; Tue, 3 Nov 2015 13:16:00 -0800 (PST) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by WTL-EXCHP-2.sandvine.com (192.168.194.177) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 3 Nov 2015 16:16:02 -0500 Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([fe80::6c6d:7108:c63c:9055%14]) with mapi id 14.03.0181.006; Tue, 3 Nov 2015 16:15:59 -0500 From: Dave Dolson To: Andrew Mortensen , Stefan Fouant Thread-Topic: [Dots] Using Diameter transport for DOTS? Thread-Index: AdEWb+LjKy2VsZZAT7KTysuTEiK/GQAL/W0AAApUjgD//2NIyIAAVTIAgABTTAA= Date: Tue, 3 Nov 2015 21:16:01 +0000 Message-ID: References: <20151103194312.594948115.52080.45702@sandvine.com> <156C879E-5525-45A2-B2B0-0D11698C54AC@gmail.com> <4972C21F-5168-4A61-A176-B7FE79439B97@corero.com> <98B352C0-D4AD-49A8-A6AE-2C1AB8EEE79D@arbor.net> In-Reply-To: <98B352C0-D4AD-49A8-A6AE-2C1AB8EEE79D@arbor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [183.77.156.199] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Kathleen Moriarty , dots Subject: Re: [Dots] Using Diameter transport for DOTS? 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, 03 Nov 2015 21:16:02 -0000 If I understand correctly, to spell it out: If the proxy is more than an IP router, - a message is comprised of information elements that the proxy needs to re= ad and those end-to-end elements it must not be able to read - the end-to-end information elements are encrypted/signed with end-to-end = keys - the entire message is encrypted/signed with hop-by-hop keys. Out of curiosity, can you give examples of what aspects of the "SOS" messag= e must not be seen by the proxy? -Dave -----Original Message----- From: Andrew Mortensen [mailto:amortensen@arbor.net]=20 Sent: Wednesday, November 04, 2015 6:06 AM To: Stefan Fouant Cc: Dave Dolson; Kathleen Moriarty; dots Subject: Re: [Dots] Using Diameter transport for DOTS? > On Nov 3, 2015, at 4:01 PM, Stefan Fouant wrot= e: >=20 >=20 >> On Nov 4, 2015, at 5:55 AM, Dave Dolson wrote: >>=20 >>=20 >> Is end-to-end crypto required in DOTS, given hop-by-hop security is good= ? >> [Not intended as a rhetorical question.] To those not familiar with=20 >> Diameter, in the DOTS context, the client-to-proxy and proxy-to-server c= onnections would be secure and encrypted, but the proxy could view and modi= fy messages. >=20 > There is no mandate for that requirement DOTS currently, but I can name a= few large ISPs that I am talking to who would likely prefer any such signa= ling to be fully encrypted end-to-end as they have a mandate to encrypt or = fully privatize any customer related data due to contractual obligations. Nor is hop-by-hop security going to be adequate for the use case Flemming b= rought up yesterday (service on public cloud signaling a third-party scrubb= ing service). andrew From nobody Tue Nov 3 13:25: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 059121ACD03 for ; Tue, 3 Nov 2015 13:25:58 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7, 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 Cqk01DBseVfW for ; Tue, 3 Nov 2015 13:25:56 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 410D81ACCFF for ; Tue, 3 Nov 2015 13:25:56 -0800 (PST) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa%18]) with mapi id 14.03.0195.001; Tue, 3 Nov 2015 16:25:54 -0500 From: Dave Dolson To: Gilbert Clark , "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-requirements-00.txt Thread-Index: AQHRFHWAA72N17GeHEOBJOqaqqVLS56JHKpwgAFOSgCAAEo5foAAbhYA//+vFTA= Date: Tue, 3 Nov 2015 21:25:56 +0000 Message-ID: References: <20151019172722.23547.45444.idtracker@ietfa.amsl.com> <1837A898-7562-4449-AEDB-EEF8CA9E099A@arbor.net> <20151103193713.594948115.49782.45699@sandvine.com> <563922F6.5010307@mti-systems.com> In-Reply-To: <563922F6.5010307@mti-systems.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [183.77.156.199] Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-00.txt 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, 03 Nov 2015 21:25:58 -0000 Gilbert, > I'd imagine that someone would apply aggressive rate limits to messages s= ourced by each individual supplicant, and only worry about supporting high = messaging load in the cases it was actually necessary This is precisely an example of a mechanism for functioning under high mess= age load! I'm not saying the concerns are insurmountable. I think most of the dots pa= rticipants are intuitively working towards robust design. Anyhow, take it or leave it. I'm trying to ensure that I'm understood, but = I'm not a security reviewer. -Dave -----Original Message----- From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Gilbert Clark Sent: Wednesday, November 04, 2015 6:11 AM To: dots@ietf.org Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-00.txt I really don't like the idea of including anything in DOTS that has already= been implemented elsewhere without having a good reason to do so. I see a= DOTS message as a simple, no-nonsense way to convey a request for help fro= m point A to point B. Additional thoughts inline: On 11/3/2015 2:37 PM, Dave Dolson wrote: > As I understand the purpose of =FDthe security section, you should noneth= eless document the issue. Could be wrong, but ... I don't believe the security section of a requireme= nts draft is necessarily the same as the security considerations section of= an eventual protocol draft. In my head, I see security items included in = the requirements draft as being the principles that most influence the even= tual design of the DOTS protocol. The security considerations of a DOTS pr= otocol draft would define items that should be considered when deploying or= using the protocol. > But I'm not sure that rate-limiting DOTS events should be out of the ques= tion. I'm not convinced that the DOTS protocol is the *right place* to include sa= id rate-limiting. Why should we re-invent that particular function here? Additionally, responding to a (related) previous message: > So, perhaps something like this: > DOTS must define protections against attacks on the DOTS infrastructure b= y an attacker who creates false-positive attack detections. In my mind, DOTS is simply a request for help with some context attached. = It doesn't know what a false positive is. Why should *DOTS* be responsible= for this? > DOTS must define mechanisms for a client or server to function robustly u= nder high messaging load from its peer(s). Disagree with inclusion in the requirements as stated. Different failure m= odes can make sense in different cases, and "high messaging load" and "robu= stly" are both relative. Also, I doubt a network could support updates to = mitigation configurations at anything resembling high messaging load: many = mitigation strategies will take discrete time to propagate (especially inte= r-domain) and will consume resources. =20 Flooding a DOTS server with messages for help (or even updates to previous = help requests, for that matter) won't make the help come any faster. Thus,= I don't see a reason to even bother to try to process these messages at hi= gh rate: instead, I'd imagine that someone would apply aggressive rate limi= ts to messages sourced by each individual supplicant, and only worry about = supporting high messaging load in the cases it was actually necessary (read= : a handful of large providers). > DOTS must define back-off mechanisms so that neither client nor server wi= ll overload the peer with messaging. Disagree with inclusion in the requirements as stated. See note about rate= -limiting above. Believe this would make a good note in the security considerations section = of an eventual protocol draft, however. -Gilbert _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Tue Nov 3 13:54: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 42EC71B2A8A for ; Tue, 3 Nov 2015 13:54:54 -0800 (PST) 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=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 2qUE38cT7PI2 for ; Tue, 3 Nov 2015 13:54:53 -0800 (PST) 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 F35451B2A8B for ; Tue, 3 Nov 2015 13:54:52 -0800 (PST) Received: by pabfh17 with SMTP id fh17so29927617pab.0 for ; Tue, 03 Nov 2015 13:54:52 -0800 (PST) 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=i85PyNLVvyD7SHgyVTd1IPlhpsNFLsWjIJL48mOgspM=; b=mZ575bKQWgF10zwSIF0sUQBYmyO6aIFjJFQIZtb2wPjc2aJEbawU0TzHuKYWbR1I8n koBWqGKW6vjhvV2gmX+a15UGEj279IZdToLjYHsdt8CaEWaMAZlITKJDwIt3VOqs2LYx Hw0CW1/IA6XZ4OoezSBBr1M+Dc1VRnqNT1dKg= 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=i85PyNLVvyD7SHgyVTd1IPlhpsNFLsWjIJL48mOgspM=; b=LHrwa+2CdwNOon18SFKZLF67jzFDPbfgaK5iWfW7Ene/ZVCPOru/3U6WCwxu9rSaiv jMfAXngVZWpFGqdsZ6vQgazGAYQEXCxAiCpXfEXZHh2euVNLP/RduHwsXJzT3ysKC/RN mhV8cD/lwwYMTjEUqpHsgY7XQl4DEunP/VYzFtdbnrYKpaqGV42lTn88s+T25e5K5xD3 GD3IHJEpu/3nt33IOCM/E9gYSM+iKQtB3tTTUJFcMgtRGcNSWosx2ISV3onMehoVa8gG tymt5J67KZOG9X3FB867CUUQSe4rFCphDdtxQGDTbcymPDtN0b1xPHyxy6hFPI3yRlHJ 5GjQ== X-Gm-Message-State: ALoCoQkkLKJDckeXxOzsB2xa+Mo2Mez5vM/fpYYhRcz/vTm0yehItIGW2h/Si5JO9tAEpQ2NVhap X-Received: by 10.68.202.170 with SMTP id kj10mr36554718pbc.104.1446587692637; Tue, 03 Nov 2015 13:54:52 -0800 (PST) Received: from [10.0.1.3] (p5231-ipngn5001hodogaya.kanagawa.ocn.ne.jp. [153.220.164.231]) by smtp.gmail.com with ESMTPSA id fe6sm2762845pab.40.2015.11.03.13.54.51 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 03 Nov 2015 13:54:52 -0800 (PST) From: "Roland Dobbins" To: "dots@ietf.org" Date: Wed, 04 Nov 2015 06:54:49 +0900 Message-ID: <1222CC43-0776-472B-9CC5-B0A19CFCF18B@arbor.net> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5164) Archived-At: Cc: "tsvwg@ietf.org" Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 03 Nov 2015 21:54:54 -0000 On 4 Nov 2015, at 3:06, Stefan Fouant wrote: > I can see the case for a stateful approach so that a DOTS client can > receive notification that the request > went through... It's already been determined that both stateless and stateful transports are necessary because of overly-restrictive network access policies in many environments - we discussed that very early on, IIRC. ----------------------------------- Roland Dobbins From nobody Tue Nov 3 14:03:34 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 933FE1B2A9C for ; Tue, 3 Nov 2015 14:03:32 -0800 (PST) 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 EVzHiWnxp57s for ; Tue, 3 Nov 2015 14:03:30 -0800 (PST) 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 470E21B2A9B for ; Tue, 3 Nov 2015 14:03:30 -0800 (PST) Received: by pacdm15 with SMTP id dm15so5778625pac.3 for ; Tue, 03 Nov 2015 14:03:29 -0800 (PST) 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=Ww1llcIzfNH3al7sGSdbp85fZL+HwYgVi1Z8AyaHZlc=; b=HD3m2z5QrGrW2SW+qfvKlIIN/O7NfxW5xyssX1Fj+xSiNwr4PRVP56dfDzoPoziEN9 oI5WuiCynqxRd1PGkSPm+PQKlWXpC/dr3Lr8sMsn/z5pnmEVoSyLhY2T2ZcrwWBCGduH ls4ayVvQd1yksMUqLvpgRfqe64osgsGVOSck4= 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=Ww1llcIzfNH3al7sGSdbp85fZL+HwYgVi1Z8AyaHZlc=; b=HXTOl2TlWojl9eQgtpHyRfQBI5iDanj+b+mxxhj2QUUyTQMcjMrt+UhH7qQxcJ3cVc KN5Qwc3YQif53PoTwI+HyR4BvOrJ7sGAdBFXvyBNvM03iNs2fjJmtnhHlQ6xgCwPXSGx QmhH7DvlqoJnxB1Q6Zup3QDnY60XizxOueqIO7oJOKpeBcCL24wfPGPkimdQXXtBmDTB +ewoAU6uyAZvyx3r9RE5D8XpZSK7ITs4VnD9M5KgCD/zutQti6wnZHL0HNBEMmjB9lI1 iz5uWyp6uZ5jPZwlHF71Meqnb70fU9Rn0yvbVXvbprPCULIKi03NyqhooD4fiHPBXIFm XwOQ== X-Gm-Message-State: ALoCoQmRLEyzNy2ZAyY/7IpPqp1wvkzJGQcR5JY9RMvO62M5x0OItpT1KcAvlISMMT0OlydIGqFr X-Received: by 10.68.254.137 with SMTP id ai9mr35504874pbd.68.1446588209812; Tue, 03 Nov 2015 14:03:29 -0800 (PST) Received: from [10.0.1.3] (p5231-ipngn5001hodogaya.kanagawa.ocn.ne.jp. [153.220.164.231]) by smtp.gmail.com with ESMTPSA id tp6sm31247027pbc.81.2015.11.03.14.03.28 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 03 Nov 2015 14:03:29 -0800 (PST) From: "Roland Dobbins" To: dots@ietf.org Date: Wed, 04 Nov 2015 07:03:26 +0900 Message-ID: <33D6299F-BD59-47CC-88D3-AA8246965BD9@arbor.net> In-Reply-To: References: <5638D31B.4080801@mti-systems.com> <5638E400.2000906@spritelink.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5164) Archived-At: Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 03 Nov 2015 22:03:32 -0000 On 4 Nov 2015, at 2:42, Jelena Mirkovic wrote: > So, while I second Wes's idea for multiple channels is there strong > operational evidence that ACKs indeed have a > problem? Try Web browsing sometime whilst under a volumetric DDoS attack down the same link. Or even when someone else is downloading enough large files simultaneously to tax the link capacity. ;> In all seriousness, in many cases, enough will get through to allow a message to be sent. But this protocol is designed for use under emergency conditions, with ongoing link congestion a commonplace event in the circumstances under which it is to be used. So, we really need both stateless and stateful options. One of the applications for DOTS relays is also to serve as a well-known address within a given organization for DOTS messaging which allows holes to be poked in overly-restrictive policies, and which has little need ever to be changed, irrespective of whatever configuration changes take place further in the background with regards to mitigation systems and DOTS servers which communicate with them. Potential issues with networks policing down UDP is more likely to occur in situations involving overlay mitigation providers who're topologically distant from the properties they're protecting. There's always UDP/53, if nothing else, of course. But it's far too early to be thinking along those lines. UDP works just fine, even when some networks are doing lots of UDP filtering, under most circumstances - e.g., if you can play your PS4 or XBone or PC multiplayer games, UDP is working. ----------------------------------- Roland Dobbins From nobody Tue Nov 3 14:10:25 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 0F0321B2AF6 for ; Tue, 3 Nov 2015 14:10:24 -0800 (PST) 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 b_4uWtSHvDCp for ; Tue, 3 Nov 2015 14:10:23 -0800 (PST) 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 6B7201B2AF7 for ; Tue, 3 Nov 2015 14:10:22 -0800 (PST) Received: by pabfh17 with SMTP id fh17so30269928pab.0 for ; Tue, 03 Nov 2015 14:10:22 -0800 (PST) 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=JOjWI6f6nzmlVO7kNLr//KFgVEOV5ZdjgTadf4Lipds=; b=WB1xhwQbmGpoV5614DfXdMwABznQaOes/tdZe1zfKm+UtwVwAE0dckH3P8lqjHrm5l kzOnw5YhWKMWMWBJ5nptaiERKl9p9eAIGw5U/1XPFPiE6pv88+b+YoFHthLZ2fViL72B ukyTrtodKvNHdbR/bqnsWGwbj36y8aRFCSBNE= 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=JOjWI6f6nzmlVO7kNLr//KFgVEOV5ZdjgTadf4Lipds=; b=kvtZ5yVrQIptmZsJUSsT+Y29Vzc9NX1pVcIbrCii69bCmL0+TRItKTN7cxLTrMbZkX EY65A9GQbJ5DpleFeTrfqwbEbm7lZriFmA78zyoB67041LYen9PQvxpPoOUspy3RiM1D ISrBmxlx2wRx4IfbbS1L03vHqv+gQkGYdtp7Mz6TfnolQjBSLmb8cVo0HcsEtofX51PQ h4CHaFg3/J2UBLDQYMCv65btTo8JeZtAZws7mvJUXOE8Wqy+Vm9zwdJaQLUpC0//C9vY iHHLEkb5ChoSTZCGghJra88/OM48zTJkEuvDVQ4SX7zYhR5VV35haMqYAz+5Lejz9d2n rA3Q== X-Gm-Message-State: ALoCoQkZn7lJ/hw8R6bMY69r9YNjdq0kmkm2oNk36Mz/9V3MbJ3cu+e51DjfDZEvHyQwsQZfNvvF X-Received: by 10.66.196.168 with SMTP id in8mr36239775pac.27.1446588621960; Tue, 03 Nov 2015 14:10:21 -0800 (PST) Received: from [10.0.1.3] (p5231-ipngn5001hodogaya.kanagawa.ocn.ne.jp. [153.220.164.231]) by smtp.gmail.com with ESMTPSA id ir5sm31344286pbc.13.2015.11.03.14.10.20 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 03 Nov 2015 14:10:21 -0800 (PST) From: "Roland Dobbins" To: dots@ietf.org Date: Wed, 04 Nov 2015 07:10:18 +0900 Message-ID: <0A836E5A-C801-4CF4-916C-41EA065D3D30@arbor.net> In-Reply-To: References: <5638D31B.4080801@mti-systems.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5164) Archived-At: Cc: "tsvwg@ietf.org" Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 03 Nov 2015 22:10:24 -0000 On 4 Nov 2015, at 1:22, Ca By wrote: > at least in the case i am most familiar with. It is important to keep this part in mind. > With DOTS in UDP, you are putting the DOTs traffic in that path that > becomes the most lossy during a a DDoS. This is an overgeneralization - see above. There are lots of topological and pathing assumptions being made, here, as well as policy-filtering assumptions. It has been clear from the beginning of this effort that both stateless and stateful transport options are necessary, due to overly-restrictive network access policies, edge QoSing as a (counterproductive, IMHO) measure against UDP reflection/amplification attacks, etc. This has been discussed on-list and in meetings, it's unclear why it's become contentious, all of a sudden. ----------------------------------- Roland Dobbins From nobody Tue Nov 3 14:49: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 72B671B356C for ; Tue, 3 Nov 2015 14:49:21 -0800 (PST) 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 goRRn8K4LobC for ; Tue, 3 Nov 2015 14:49:20 -0800 (PST) Received: from atl4mhob11.myregisteredsite.com (atl4mhob11.myregisteredsite.com [209.17.115.49]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB431B356A for ; Tue, 3 Nov 2015 14:49:20 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.210]) by atl4mhob11.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id tA3MnJkV028055 for ; Tue, 3 Nov 2015 17:49:19 -0500 Received: (qmail 26061 invoked by uid 0); 3 Nov 2015 22:49:18 -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; 3 Nov 2015 22:49:18 -0000 To: dots@ietf.org References: <5638D31B.4080801@mti-systems.com> <0A836E5A-C801-4CF4-916C-41EA065D3D30@arbor.net> From: Gilbert Clark Message-ID: <563939F2.8010601@mti-systems.com> Date: Tue, 3 Nov 2015 17:49:22 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <0A836E5A-C801-4CF4-916C-41EA065D3D30@arbor.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 03 Nov 2015 22:49:21 -0000 tsvwg list removed from this message. On 11/3/2015 5:10 PM, Roland Dobbins wrote: > On 4 Nov 2015, at 1:22, Ca By wrote: > >> at least in the case i am most familiar with. > > It is important to keep this part in mind. > >> With DOTS in UDP, you are putting the DOTs traffic in that path that >> becomes the most lossy during a a DDoS. > > This is an overgeneralization - see above. > > There are lots of topological and pathing assumptions being made, > here, as well as policy-filtering assumptions. > > It has been clear from the beginning of this effort that both > stateless and stateful transport options are necessary, due to > overly-restrictive network access policies, edge QoSing as a > (counterproductive, IMHO) measure against UDP reflection/amplification > attacks, etc. This has been discussed on-list and in meetings, it's > unclear why it's become contentious, all of a sudden. > As a comment: the presentation referenced in the original note to tsvwg did explicitly note a proposed transport of UDP + DTLS for SOS messages. There was no mention (as far as I'm aware, anyway) of an alternative stateful channel which could be used for that message type. For those to whom this is a new problem (read: folks on tsvwg who are not also on dots) or those who may have not attended the working group meeting, a lack of context may be contributing to the way this conversation has been going. -Gilbert From nobody Tue Nov 3 15:37: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 3F7A51B3622 for ; Tue, 3 Nov 2015 15:37:56 -0800 (PST) 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 qhsFltIGZ_So for ; Tue, 3 Nov 2015 15:37:54 -0800 (PST) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::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 D3D001B3621 for ; Tue, 3 Nov 2015 15:37:53 -0800 (PST) Received: by iody8 with SMTP id y8so36402283iod.1 for ; Tue, 03 Nov 2015 15:37:53 -0800 (PST) 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=2byaqRLT1x+E6vyCpACx9XOGTtHww6HYqPdd74AwRQ8=; b=hRkBR9tGwi9F3nRtfkFqMVIewR+Vv4uJLiN9Rv0xTqkDPPeiKzek3i8ft9OwARNZls IHleksC9s3XvEu7AT8+FDlxnjtPZ87ySYAhBapvLJmTW46TIOH/enQ+p24sWfpJB38k+ ibt8VPqFUeqfeihYBr7td2L/UFyhJUn6TG5DQ= 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=2byaqRLT1x+E6vyCpACx9XOGTtHww6HYqPdd74AwRQ8=; b=EJX/3EdBMk9ZfRlsx4srtQlAsuT8tGEgRIRXJmEBzqfYmYTOlti9clR2SVgbfuhAkS NolXv0OfC44+/Qh/CGvXpoV637+Ov7J2rKtuvtYyVCw7ceRU45uudPK1Xk8Fvt8RPYw+ +ctMGTEX1ry2mP+C7uVUm/40Yfx+T/R5+HNv7e2aTV0um5M9aR4NCzGU4AwWra69MuSP gnL1xcobEtEM1L8s4IJslZD4l5kVPLFkkv5BQqswvTJYcPNwpQV6ns9psvNMSz7UbefR WvRgkHtpLyDsfOGSCmGYvHm+ctoqXTSWsuao5K3RdRZr4fv7qcD7HBFYdh9BPrkKbHbx Pdjw== X-Gm-Message-State: ALoCoQlNjtOySs+Mlv4K8So6H+0eRJaf+eU9D+c3RWWtQqus4fgQfMjdiPIgpn2IIwUDK6nFVCIA X-Received: by 10.107.128.98 with SMTP id b95mr29742595iod.26.1446593873198; Tue, 03 Nov 2015 15:37:53 -0800 (PST) Received: from dhcp-35-191.meeting.ietf94.jp (dhcp-35-191.meeting.ietf94.jp. [133.93.35.191]) by smtp.gmail.com with ESMTPSA id q80sm10119869ioe.31.2015.11.03.15.37.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Nov 2015 15:37:52 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_423A4A67-93A3-4D29-AE96-D759524ED84E" Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Andrew Mortensen In-Reply-To: <563939F2.8010601@mti-systems.com> Date: Tue, 3 Nov 2015 18:37:49 -0500 Message-Id: <3AFD973D-22CB-49BD-A384-A1C10A0167E9@arbor.net> References: <5638D31B.4080801@mti-systems.com> <0A836E5A-C801-4CF4-916C-41EA065D3D30@arbor.net> <563939F2.8010601@mti-systems.com> To: Gilbert Clark X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: dots@ietf.org Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 03 Nov 2015 23:37:56 -0000 --Apple-Mail=_423A4A67-93A3-4D29-AE96-D759524ED84E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 3, 2015, at 5:49 PM, Gilbert Clark = wrote: >=20 > tsvwg list removed from this message. >=20 > On 11/3/2015 5:10 PM, Roland Dobbins wrote: >> On 4 Nov 2015, at 1:22, Ca By wrote: >>=20 >>> at least in the case i am most familiar with. >>=20 >> It is important to keep this part in mind. >>=20 >>> With DOTS in UDP, you are putting the DOTs traffic in that path that = becomes the most lossy during a a DDoS. >>=20 >> This is an overgeneralization - see above. >>=20 >> There are lots of topological and pathing assumptions being made, = here, as well as policy-filtering assumptions. >>=20 >> It has been clear from the beginning of this effort that both = stateless and stateful transport options are necessary, due to = overly-restrictive network access policies, edge QoSing as a = (counterproductive, IMHO) measure against UDP reflection/amplification = attacks, etc. This has been discussed on-list and in meetings, it's = unclear why it's become contentious, all of a sudden. >>=20 >=20 > As a comment: the presentation referenced in the original note to = tsvwg did explicitly note a proposed transport of UDP + DTLS for SOS = messages. There was no mention (as far as I'm aware, anyway) of an = alternative stateful channel which could be used for that message type. = For those to whom this is a new problem (read: folks on tsvwg who are = not also on dots) or those who may have not attended the working group = meeting, a lack of context may be contributing to the way this = conversation has been going. All draft-reddy-dots-transport-01 actually says with respect to protocol = is the following: "TBD: SOS messages SHOULD be exchanged over DTLS over = UDP.=E2=80=9D Compare with OP-001 from draft-ietf-dots-requirements-00: "While the protocol resilience requirement strongly RECOMMENDS the use = of connectionless protocol, in particular the User Datagram Protocol = (UDP), use of a standardized, connection-oriented protocol like the = Transmission Control Protocol (TCP) MAY be necessary due to network = policy or middleware limitations." andrew= --Apple-Mail=_423A4A67-93A3-4D29-AE96-D759524ED84E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Nov 3, 2015, at 5:49 PM, Gilbert Clark <gclark@mti-systems.com> wrote:

tsvwg list removed from this message.

On 11/3/2015 5:10 PM, Roland Dobbins = wrote:
On 4 Nov = 2015, at 1:22, Ca By wrote:

at least in the case i am most familiar = with.

It is important to keep = this part in mind.

With DOTS in UDP, you are putting the DOTs traffic in that = path that becomes the most lossy during a a DDoS.

This is an overgeneralization - = see above.

There are lots of topological = and pathing assumptions being made, here, as well as policy-filtering = assumptions.

It has been clear from the = beginning of this effort that both stateless and stateful transport = options are necessary, due to overly-restrictive network access = policies, edge QoSing as a (counterproductive, IMHO) measure against UDP = reflection/amplification attacks, etc.  This has been discussed = on-list and in meetings, it's unclear why it's become contentious, all = of a sudden.


As a comment: the = presentation referenced in the original note to tsvwg did explicitly = note a proposed transport of UDP + DTLS for SOS messages.  There = was no mention (as far as I'm aware, anyway) of an alternative stateful = channel which could be used for that message type.  For those to = whom this is a new problem (read: folks on tsvwg who are not also on = dots) or those who may have not attended the working group meeting, a = lack of context may be contributing to the way this conversation has = been going.

All draft-reddy-dots-transport-01 actually = says with respect to protocol is the following: "TBD: SOS messages = SHOULD be exchanged over DTLS over UDP.=E2=80=9D

Compare with OP-001 from = draft-ietf-dots-requirements-00:

"While the protocol resilience requirement strongly = RECOMMENDS the use of connectionless protocol, in particular the User = Datagram Protocol (UDP), use of a standardized, connection-oriented = protocol like the Transmission Control Protocol (TCP) MAY be necessary = due to network policy or middleware limitations."
andrew
= --Apple-Mail=_423A4A67-93A3-4D29-AE96-D759524ED84E-- From nobody Tue Nov 3 17: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 5C7E71A87EC for ; Tue, 3 Nov 2015 17:09:07 -0800 (PST) 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 tzECyTT9-SEr for ; Tue, 3 Nov 2015 17:09:06 -0800 (PST) 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 48A551A87E7 for ; Tue, 3 Nov 2015 17:09:06 -0800 (PST) Received: by padhx2 with SMTP id hx2so26706082pad.1 for ; Tue, 03 Nov 2015 17:09:06 -0800 (PST) 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=S19BlIyEhPiAXvXLwwhZV7S+eUzgzL3EtopkBoDkxsE=; b=lZ4YCPJHIPSj1DuVjMfB+z6EwNqBlcJN43a21adbPCdNRdf9HHCn76gNLhoTxqgdS1 iTRAE1BL32MTmSQ28iyxoDhQL8JPsmfIzs3eWeKfdIIfXOSFfPQX5N1gNJ/FruHuDykM OdjFGMZ2jBYZghQru9t6ZM6u1ar4k10VopZi4= 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=S19BlIyEhPiAXvXLwwhZV7S+eUzgzL3EtopkBoDkxsE=; b=WBfRcnHakheDi3MyABArNFhKNIoaOZSbVH2ZheI98tfEZwTEp3QfRkNUu2KQkyZxfr kNJpsILpi4yqpnL2rgFC1oPIRLGEIYZknwXd9SV161DIlhEAYWNr76B3pEhFOrvcnaF8 h5i8uHVbr9yUT6jbgMT++ZK7RH/qb8CMaKWN9tAFCC+Am7tKhGPBKkseNVGFro+VPeA4 0TpI5hZDKkZhpYySZgkjxmTD6YbOi04raAqB1lf1EmKN6wTGBcILldueY3bvE2PM6GD+ UHDxfqa2JLqofcn6BXz8LuMM05/KxnGdCfKm85vvEU5IzZSwsPEOoSIKDK/ifP3j+QYH WhwA== X-Gm-Message-State: ALoCoQkSo5A2jFuwp7VwQshIsrRmpYzHU4ouK8k1/lq1poW3iZGPtZDwd0n7PCZ8PsFBE/B7lS3i X-Received: by 10.68.135.97 with SMTP id pr1mr10058470pbb.27.1446599345967; Tue, 03 Nov 2015 17:09:05 -0800 (PST) Received: from [10.0.1.3] (p5231-ipngn5001hodogaya.kanagawa.ocn.ne.jp. [153.220.164.231]) by smtp.gmail.com with ESMTPSA id bh1sm31766609pbc.26.2015.11.03.17.09.04 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 03 Nov 2015 17:09:05 -0800 (PST) From: "Roland Dobbins" To: "dots@ietf.org" Date: Wed, 04 Nov 2015 10:09:02 +0900 Message-ID: In-Reply-To: <20151103193713.594948115.49782.45699@sandvine.com> References: <20151019172722.23547.45444.idtracker@ietfa.amsl.com> <1837A898-7562-4449-AEDB-EEF8CA9E099A@arbor.net> <20151103193713.594948115.49782.45699@sandvine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.3r5164) Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-00.txt 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, 04 Nov 2015 01:09:07 -0000 On 4 Nov 2015, at 4:37, Dave Dolson wrote: > As I understand the purpose of ‎the security section, you should > nonetheless document the issue. I'm not sure I agree with this. It has nothing to do with DOTS itself. > But I'm not sure that rate-limiting DOTS events should be out of the > question. That's a different issue, and a valid one, IMHO. DOTS clients, servers, and relays should have this capability, IMHO. ----------------------------------- Roland Dobbins From nobody Tue Nov 3 17:11: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 52C7F1A87E9 for ; Tue, 3 Nov 2015 17:11:17 -0800 (PST) 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 ONji5R5iM6N4 for ; Tue, 3 Nov 2015 17:11:16 -0800 (PST) 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 7920C1A87E3 for ; Tue, 3 Nov 2015 17:11:15 -0800 (PST) Received: by pasz6 with SMTP id z6so35202248pas.2 for ; Tue, 03 Nov 2015 17:11:15 -0800 (PST) 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=K/spn4sS7hzmS+verMv9IkDZBTXdtiWOj1YquFp4Upc=; b=OTqvvbcOvN8ADLr4zz1f9fNinnACQPXG5calZawh6/ispcPvoGCRsEJ4K3WW23g1UJ 4ee/zlC4f0nbf4NhLXbkRkMZkLZjaBQC8Zawu5G4n5gul8FzNFZKX5EnEIPgeC76mAGh mVjSp0HVBsUmL6/sxmOh2QMhnn/rJqxcwKWts= 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=K/spn4sS7hzmS+verMv9IkDZBTXdtiWOj1YquFp4Upc=; b=gjHpJ7DvcWFOiD+mDP6VC8yxuOrZogBulfeHzxpVqLBO79sCrYb5RBReqs7BvtsHIL pv+zdDIA31SDl7tQmI70E34zVn/hweCRRZmt78Y6SWKtJzRjJyAvkM5Fy4a41XOujQg0 ndtRgoxsrDqCZHa0WuCImA+MjgsZFBVO+NKheRDQnWVhZ4hM+HcopPLYfR2qxnukKLTV BI8nmNWVTs64H+gXL2jbIWpC1zH7oV2faPdj7ZACMa5mG6MR4DqobUZFvKXcTZiB+NQx PHyzt8KNxazkprMKlB3wrZOHHMZkse7l4VSjxemm6uIPlkQSv1yhSOcsFyWhyEmJYN0y alCw== X-Gm-Message-State: ALoCoQmNAlV41E1hgDCo7Z6Qo7JgLIZw+XvGrapxS1pdDCr4I2zjtUD9bUIezkUu4/Tz8BrXMD/q X-Received: by 10.66.132.37 with SMTP id or5mr37164824pab.5.1446599475144; Tue, 03 Nov 2015 17:11:15 -0800 (PST) Received: from [10.0.1.3] (p5231-ipngn5001hodogaya.kanagawa.ocn.ne.jp. [153.220.164.231]) by smtp.gmail.com with ESMTPSA id w8sm31691644pbs.87.2015.11.03.17.11.12 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 03 Nov 2015 17:11:12 -0800 (PST) From: "Roland Dobbins" To: dots@ietf.org Date: Wed, 04 Nov 2015 10:11:10 +0900 Message-ID: <3D65080C-6580-4577-9AF9-50D48FAFE9B3@arbor.net> In-Reply-To: <563922F6.5010307@mti-systems.com> References: <20151019172722.23547.45444.idtracker@ietfa.amsl.com> <1837A898-7562-4449-AEDB-EEF8CA9E099A@arbor.net> <20151103193713.594948115.49782.45699@sandvine.com> <563922F6.5010307@mti-systems.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5164) Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-00.txt 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, 04 Nov 2015 01:11:17 -0000 On 4 Nov 2015, at 6:11, Gilbert Clark wrote: > Disagree with inclusion in the requirements as stated. See note about > rate-limiting above. I concur with all your points, except I do see utility in the ability to rate-limit DOTS message generation/forwarding/parsing as an implementation requirement for all DOTS agents. ----------------------------------- Roland Dobbins From nobody Tue Nov 3 17:13: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 D75AF1A87E7 for ; Tue, 3 Nov 2015 17:13:50 -0800 (PST) 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 Gg4nU3kiX353 for ; Tue, 3 Nov 2015 17:13:49 -0800 (PST) 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 AE7E51A8824 for ; Tue, 3 Nov 2015 17:13:49 -0800 (PST) Received: by pasz6 with SMTP id z6so35275522pas.2 for ; Tue, 03 Nov 2015 17:13:49 -0800 (PST) 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=fB0nNdCW41XvdlgmgcYLnf5PF1OH+cpYxImQJN3Wb8A=; b=f1lq5tnSTSD6C2kpcX6vSPd8TgWpzlLmVOr0XV29+LLc9iw49ZkBTR0cp+lcc2mTR9 8/JgeVGSaY2LFMphascjPuxB0Fqrk+sMOi16Xby0icTp4euuwb3YP4D6d0jGtFBW/8o/ X+H9mhrx5UeG1E7wg8Fx7hSwD3rXSDuM9AoNk= 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=fB0nNdCW41XvdlgmgcYLnf5PF1OH+cpYxImQJN3Wb8A=; b=XUlVOOxVhTGrDNNOk+mjYMvClkAYJozq7sUj9GvSSnm1kxqmM0Ri78omgrb//nnsCy CrVAtxA0jX/0bHKn5UwjhJzaGs91W65I65qF/P/PA1eqj2wmNfIdC5+wHtFBuTlVQoZZ GbHCXJ/upo1Km2ln6V5UK1IjehE7zPykWuEODreVD75BUW4cpN/Ce96DiGNdZJ5hjkdP qE6vwm7uvWgEVx2tW9LLRpg+Vyw333CTRF9FMCxHIxFtb0T2q7ASYDbwD9uFDYsJauG5 Z1+4eKS395HYnsP4bFl9r8v0S9LUaSOFWHYlIIQAKHz3AuWQS2/Ow/DDRJ300LHRGqpJ tRwg== X-Gm-Message-State: ALoCoQnvONyWjTH8hzD71kCQkfl6M0h48JIEqWcYJbpw4dsASCiZEvjFU097v1CpJPPegUfL0ZHX X-Received: by 10.66.122.69 with SMTP id lq5mr37187672pab.125.1446599629295; Tue, 03 Nov 2015 17:13:49 -0800 (PST) Received: from [10.0.1.3] (p5231-ipngn5001hodogaya.kanagawa.ocn.ne.jp. [153.220.164.231]) by smtp.gmail.com with ESMTPSA id hi4sm5761405pbc.7.2015.11.03.17.13.48 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 03 Nov 2015 17:13:48 -0800 (PST) From: "Roland Dobbins" To: dots@ietf.org Date: Wed, 04 Nov 2015 10:13:46 +0900 Message-ID: In-Reply-To: <5638D31B.4080801@mti-systems.com> References: <5638D31B.4080801@mti-systems.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5164) Archived-At: Cc: tsvwg@ietf.org Subject: Re: [Dots] Best transport selection during an attack? 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, 04 Nov 2015 01:13:51 -0000 On 4 Nov 2015, at 0:30, Wesley Eddy wrote: > The signaling shouldn't be high-bandwidth, so supporting multiple > options, and using all available options, hoping at least one gets > through, seems totally feasible to me. The messaging just needs to be > able to support de-duplication, in case multiple signaling channels > happen to work. Concur 100% with your very salient observations. ----------------------------------- Roland Dobbins From nobody Tue Nov 3 17:31: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 78FAB1A889F; Tue, 3 Nov 2015 17:29:50 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 ZYWgpraiSwYb; Tue, 3 Nov 2015 17:29:49 -0800 (PST) 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 1D1771A88A1; Tue, 3 Nov 2015 17:29:49 -0800 (PST) Received: by ykek133 with SMTP id k133so47978417yke.2; Tue, 03 Nov 2015 17:29:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1UH2864tOUVGBx5wX9Z5kVjff17/RBf+TsVjIaz9CAs=; b=YgS4KtdxSphRLFIVwVYEW39cIj+cpPhJqamRtHOUrwn2pDdRAZlxnno2jDE8U3a1/Z Wq1AuIJkJlbkxel0m+b6K52VY/zG71Kcf1ctTKx/mOWmYfNgyQ1Nx2Gwk9SREYgITz76 177Wx6wAoky40bvIHRvA+nFRhxqIdXA2PJtwraEe0p2Rrl4uBwJjLpgABOQsKzkMn/jq ++bQLBaCQh0CMRmGbquVKjqpivCrbgfv0fAcPPQ/NqbYY28oS5NmZfneTAEyeS2jzP5k 3jGbl1f1koGdYLrrhZVekV3JLy5RSIAAD6tHigIj13fZszZkiQsQafYW+S9ZK9P3v3Qw UG6Q== MIME-Version: 1.0 X-Received: by 10.129.105.213 with SMTP id e204mr10760223ywc.61.1446600588321; Tue, 03 Nov 2015 17:29:48 -0800 (PST) Received: by 10.37.95.2 with HTTP; Tue, 3 Nov 2015 17:29:48 -0800 (PST) In-Reply-To: <5638D31B.4080801@mti-systems.com> References: <5638D31B.4080801@mti-systems.com> Date: Wed, 4 Nov 2015 10:29:48 +0900 Message-ID: From: Aaron Falk To: Wesley Eddy Content-Type: multipart/alternative; boundary=001a114938a832eb220523acf278 Archived-At: X-Mailman-Approved-At: Tue, 03 Nov 2015 17:31:27 -0800 Cc: tsvwg@ietf.org, dots@ietf.org Subject: Re: [Dots] Best transport selection during an attack? 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, 04 Nov 2015 01:29:50 -0000 --001a114938a832eb220523acf278 Content-Type: text/plain; charset=UTF-8 On Wed, Nov 4, 2015 at 12:30 AM, Wesley Eddy wrote: > > Whether or not UDP will work between networks can be tested and determined > ahead of time, so resolving UDP-blocking problems can be dealt with in > non-realtime (the same problem may exist for blocking of unknown TCP ports > anyways, so testing of the signaling channel should always be done in > nominal conditions, ahead of when its needed for attack response). Wes- DOTS has a use case where the DOTS server may in a cloud provider, ie, not be in an adjacent network. I think your comment above may be difficult to implement since the client would require cooperation from network providers with whom they have no business relationship. And, you might not be able to tell you have a problem getting UDP through until you are under attack, when some operator may implement filtering that inhibits connectivity. --aaron --001a114938a832eb220523acf278 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Nov 4, 2015 at 12:30 AM, Wesley Eddy <wes@mti-systems.com> wrote:
>
Whether or not UDP will work between networks can be tested and det= ermined ahead of time, so resolving UDP-blocking problems can be dealt with= in non-realtime (the same problem may exist for blocking of unknown TCP po= rts anyways, so testing of the signaling channel should always be done in n= ominal conditions, ahead of when its needed for attack response).

Wes-

DOTS has a use case wh= ere the DOTS server may in a cloud provider, ie, not be in an adjacent netw= ork.=C2=A0 I think your comment above may be difficult to implement since t= he client would require cooperation from network providers with whom they h= ave no business relationship.=C2=A0 And, you might not be able to tell you = have a problem getting UDP through until you are under attack, when some op= erator may implement filtering that inhibits connectivity.
--aaron
--001a114938a832eb220523acf278-- From nobody Tue Nov 3 17:37: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 2A7BA1A88E6 for ; Tue, 3 Nov 2015 17:37:24 -0800 (PST) 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 YdCuviBBuKDW for ; Tue, 3 Nov 2015 17:37:23 -0800 (PST) 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 1F11F1A88C6 for ; Tue, 3 Nov 2015 17:37:23 -0800 (PST) Received: by padhx2 with SMTP id hx2so27469568pad.1 for ; Tue, 03 Nov 2015 17:37:22 -0800 (PST) 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=eFJ5CrrsXztNALBeRIPArPQr5EZodzFiTLrzQx+JvwY=; b=LD2A4gcAcORvAokZ9KuRVrJrfmJhLHyJ3QKO8oBjGld4zvoIawku+s0AQcZqaGH71E CSS/oC4Rg1MzerDraKVnV8+xtLaXGJSlp5R7hZWoT6rFk0DMBk71hcI6yZiH1F4tr9jV FgtQg01mrUnmna97x0aQVQcXEB5Qb/sevo5sg= 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=eFJ5CrrsXztNALBeRIPArPQr5EZodzFiTLrzQx+JvwY=; b=G3FJGbDNkz0tY3UW8hi7RWwjZx3UXcpITMnsZGzK5dp2CtGJu2cnm+iYJfwRtzpL18 Rms71qrR6MbvX+wEgLFVyhT9ucX5spglAB4OV2v+WbiU/LY9cSaFeXH6uT8C708DFoRW pH+ihHWGjOTWyhA61dbBnFgTL4Puo/vDLTmBZVqmfGezOIObUtgZKFx3v0FCvKRGEYA7 eCfM/xkcHr8kHNAvdc+LqfXe2fnBDg+YOBr7xsjGZIDosnv2nu8SoWw+XuoNZhV1g2kP SX4SpRe8h9cQnNJzsUzqZlw8IVSUWoirtbV7ekdTP08fNT/QOXpcfrd10Y8dVBaAbNrj W6qQ== X-Gm-Message-State: ALoCoQlaSPghrf9bPXj8sioOIn5IfX9XPEr6CkdptA1Nm+btIA7SNEnLymaN7M94OhyC6HV79Ja+ X-Received: by 10.66.154.199 with SMTP id vq7mr31036278pab.88.1446601042690; Tue, 03 Nov 2015 17:37:22 -0800 (PST) Received: from [10.0.1.3] (p5231-ipngn5001hodogaya.kanagawa.ocn.ne.jp. [153.220.164.231]) by smtp.gmail.com with ESMTPSA id ux3sm31904953pac.18.2015.11.03.17.37.20 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 03 Nov 2015 17:37:21 -0800 (PST) From: "Roland Dobbins" To: dots@ietf.org Date: Wed, 04 Nov 2015 10:37:19 +0900 Message-ID: <10B4A768-25EC-4AFF-99D0-1BEC1C24CF2A@arbor.net> In-Reply-To: References: <5638D31B.4080801@mti-systems.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5164) Archived-At: Cc: tsvwg@ietf.org Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 04 Nov 2015 01:37:24 -0000 On 4 Nov 2015, at 10:29, Aaron Falk wrote: > And, you might not be able to tell you have a problem getting UDP > through until you are under attack, > when some operator may implement filtering that inhibits connectivity. Regular heartbeats between clients and servers, clients and relays, and relays and servers can serve the function of ensuring end-to-end connectivity on an ongoing basis. Failure to receive service request acknowledgements can serve this purpose under duress. It's expected that DOTS clients will update DOTS servers (either directly or via DOTS relays) with either continued mitigation requests and/or situational updates with regards to mitigation efficacy throughout mitigation service windows. Likewise, DOTS servers are expected to do the same with regards to DOTS clients (again, either directly or via DOTS relays). Note that other than a DOTS server receiving a DOTS mitigation service requests, none of these message types are necessary in order to mitigation service to be initiated. They are important and useful, but not mission-critical; the only mission-critical DOTS messages are mitigation service requests from DOTS clients and mitigation service refusals from DOTS servers. ----------------------------------- Roland Dobbins From nobody Tue Nov 3 18:31: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 9E8B41A014C for ; Tue, 3 Nov 2015 18:31:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 556r9tOPGJUU for ; Tue, 3 Nov 2015 18:31:25 -0800 (PST) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) by ietfa.amsl.com (Postfix) with ESMTP id 357791A016A for ; Tue, 3 Nov 2015 18:31:24 -0800 (PST) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([::1]) with mapi id 14.03.0195.001; Tue, 3 Nov 2015 21:31:26 -0500 From: Dave Dolson To: "dots@ietf.org" Thread-Topic: Does DOTS require sneaker-net support? Thread-Index: AdEWqAR5qW9Gcm/vQPCCGnZr5Yl/WA== Date: Wed, 4 Nov 2015 02:31:25 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [133.93.38.225] Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9830D83DD5wtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Subject: [Dots] Does DOTS require sneaker-net support? 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, 04 Nov 2015 02:31:26 -0000 --_000_E8355113905631478EFF04F5AA706E9830D83DD5wtlexchp2sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable With respect to the DOTS information that needs to be exchanged before an a= ttack-the configuration, resource manifest, etc., - Should sneaker-net (https://en.wikipedia.org/wiki/Sneakernet ) t= ransport be supported? I.e., a file on a USB stick taken between sites. - Similarly, but not equivalently, should it be human readable suc= h that it could be sent by fax? - Should it be QR-encodable so that it can be sent by JPEG (take a= picture and send it to me)? I'm asking because yesterday someone mentioned that occasionally operators = need to set things up after an attack has begun. Admittedly, I'm have a bit of fun with this :-) But seriously, having the configuration described as a document format vs. = as a protocol is worth considering. -Dave --_000_E8355113905631478EFF04F5AA706E9830D83DD5wtlexchp2sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

With respect to the DOTS information that needs to b= e exchanged before an attack—the configuration, resource manifest, et= c.,

-     &= nbsp;    Should sneaker-net (https://en.wikipedia.org/wiki/Sneakernet ) transp= ort be supported? I.e., a file on a USB stick taken between sites.

-     &= nbsp;    Similarly, but not equivalently, should it be human= readable such that it could be sent by fax?

-     &= nbsp;    Should it be QR-encodable so that it can be sent by= JPEG (take a picture and send it to me)?

 

I’m asking because yesterday someone mentioned= that occasionally operators need to set things up after an attack has begu= n.

 

Admittedly, I’m have a bit of fun with this :-= )

 

But seriously, having the configuration described as= a document format vs. as a protocol is worth considering.

 

-Dave

 

 

--_000_E8355113905631478EFF04F5AA706E9830D83DD5wtlexchp2sandvi_-- From nobody Tue Nov 3 18:48: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 12E991A8A62 for ; Tue, 3 Nov 2015 18:48:52 -0800 (PST) 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 57vkJteEl96N for ; Tue, 3 Nov 2015 18:48:50 -0800 (PST) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C44821A8A64 for ; Tue, 3 Nov 2015 18:48:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1200; q=dns/txt; s=iport; t=1446605330; x=1447814930; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=odQHokWouqSh6DKkoP9vWDCtGDtpyNw+apmMN9Kn9S0=; b=ZpRAaxAv5C7haw+MxmXuUr0gTD5X9cnQTC/U4V78Q4ch7rrV8dxIY+xs Rknl6mkWOUqzU310vMMqoNc54VU4AdmXgvqYPY+DVUmsGJQXSiEnWykAe X8tnkRAWdAX2OPKZSkUTNFTi/KleLNYPA1ooHbjcGA8M98IUW5Bpyuurp E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CsBACxcTlW/xjFo0hehA5vvzIXCoVyAoILAQEBAQEBgQuENgEBBAEBASAPAQU2ChELDgoCAgUWCwICCQMCAQIBFTAGAQwGAgEBiCoNsF+QfQEBAQEBAQEBAQEBAQEBAQEBAQEBARQEgQKFU4R+h3WBQwEEjhCINogNhRWBWoQ/gwGTJWOEIiA0hTQBAQE X-IronPort-AV: E=Sophos;i="5.20,241,1444694400"; d="scan'208";a="56226183" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 04 Nov 2015 02:48:40 +0000 Received: from [10.70.233.40] ([10.70.233.40]) by bgl-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id tA42md6Z029606; Wed, 4 Nov 2015 02:48:39 GMT To: Dave Dolson , dots References: <20151103194312.594948115.52080.45702@sandvine.com> From: Flemming Andreasen Message-ID: <56397209.1070404@cisco.com> Date: Tue, 3 Nov 2015 21:48:41 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151103194312.594948115.52080.45702@sandvine.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Dots] Using Diameter transport for DOTS? 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, 04 Nov 2015 02:48:52 -0000 We obvioulsy should do a proper evaluation against the requirements once we have vetted those a bit more, but my initial reaction is that this seems like a fairly heavy-handed approach to the problem at hand (we do need to understand the requirements on DOTS relays better though). TLS/DTLS satisfy a lot of what you list below, and I'm not sure we need something as elaborate as DIAMETER on top of that. Also, please keep in mind that we have use case scenarios involving endpoints, and requiring those to support DIAMETER for a basic client-side app or web portal seems like a tall order to me. On a related note, it's been a while since I looked at DIAMETER, but what is the adoption/deployment status of that outside of 3GPP these days ? Thanks -- Flemming On 11/3/15 2:43 PM, Dave Dolson wrote: > Could Diameter satisfy the transport protocol needs of DOTS? > It already has security, mutual authentication, both datagram (SCTP) and TCP transports‎, watchdog timers, redundancy, the concept of relays... > > -Dave > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Tue Nov 3 18:57: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 2CB7B1A8A9C for ; Tue, 3 Nov 2015 18:57:40 -0800 (PST) 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 Ya3kSvHTJOZY for ; Tue, 3 Nov 2015 18:57:37 -0800 (PST) Received: from mx-out03.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 B98271A8A97 for ; Tue, 3 Nov 2015 18:57:37 -0800 (PST) X-Virus-Scanned: amavisd-new at kolabnow.com Received: from mx03.mykolab.com (mx03.mykolab.com [10.20.7.101]) by mx-out03.mykolab.com (Postfix) with ESMTPS id 66A7D201DA; Wed, 4 Nov 2015 03:57:34 +0100 (CET) To: Flemming Andreasen References: <20151103194312.594948115.52080.45702@sandvine.com> <56397209.1070404@cisco.com> From: Paul Ferguson Organization: Clowns R. Mofos Message-ID: <5639741A.80408@mykolab.com> Date: Tue, 3 Nov 2015 18:57:30 -0800 In-Reply-To: <56397209.1070404@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: dots , Dave Dolson Subject: Re: [Dots] Using Diameter transport for DOTS? 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, 04 Nov 2015 02:57:40 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 May I also underscore this sentiment: > TLS/DTLS satisfy a lot of what you list below, and I'm not sure we > need something as elaborate as DIAMETER on top of that. This is a statement I also endorse, and would like to understand better what DIAMETER would actually add to the equation. - - ferg On 11/3/2015 6:48 PM, Flemming Andreasen wrote: > We obvioulsy should do a proper evaluation against the requirements > once we have vetted those a bit more, but my initial reaction is > that this seems like a fairly heavy-handed approach to the problem > at hand (we do need to understand the requirements on DOTS relays > better though). TLS/DTLS satisfy a lot of what you list below, and > I'm not sure we need something as elaborate as DIAMETER on top of > that. Also, please keep in mind that we have use case scenarios > involving endpoints, and requiring those to support DIAMETER for a > basic client-side app or web portal seems like a tall order to me. > > On a related note, it's been a while since I looked at DIAMETER, > but what is the adoption/deployment status of that outside of 3GPP > these days ? > > Thanks > > -- Flemming > > > > > On 11/3/15 2:43 PM, Dave Dolson wrote: >> Could Diameter satisfy the transport protocol needs of DOTS? It >> already has security, mutual authentication, both datagram >> (SCTP) and TCP transports‎, watchdog timers, redundancy, the >> concept of relays... >> >> -Dave >> >> _______________________________________________ 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 - -- 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 iF4EAREIAAYFAlY5dBoACgkQKJasdVTchbLhWAD/VxzQ61gKGVRXOLtbBT7UFb5r CnGsU8gf8xCSgY2zKyUBAIkZhS3Uo/njhx1xChcRVDGdqzpsPGqCJ8Ey7HaNuCpa =l3ib -----END PGP SIGNATURE----- From nobody Tue Nov 3 19:01: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 99E051A8AA9 for ; Tue, 3 Nov 2015 19:01:09 -0800 (PST) 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 Sj5CrTIhBKaS for ; Tue, 3 Nov 2015 19:01:08 -0800 (PST) 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 281E21A8AAB for ; Tue, 3 Nov 2015 19:01:03 -0800 (PST) Received: by pabfh17 with SMTP id fh17so37657284pab.0 for ; Tue, 03 Nov 2015 19:01:02 -0800 (PST) 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=7FA2zCdg5ODtJe0e+dqy8jhNZHlRFGPdqg044LIP4s8=; b=Oe/6DSGYonOreOsgI7ap6l52Zb5DQmbfsgBjm/aIpB4It3LP7uyDqu2/ZJzupUhUqh MKuHt4dI6zqC3Ah0Tv/WbnxhbE5OmhR/tdcTW4bxq856wG3L1d1A9H8FFGf9F/g6phCK u6cLEbcI7NUYrlB5hzmsfU7goxcf/I2ZTy3wk= 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=7FA2zCdg5ODtJe0e+dqy8jhNZHlRFGPdqg044LIP4s8=; b=BaXkli6v84/2UWI8Yb2CSADJlMa74NOr+O1HSJAeW9at71DfxbOZ/9oVbh8RjFd3s9 MBoCLzzR0vATrKpSJ0XfpEGKn7I+WzplxbAzcgBpFWkbZZExZVITy3/qph5cVcJ3oQtN oSA/i0VsnW7DgXvz+NmROguerJM3aLIlXGY3gH2qggzYPS21Z4hmIOadBodEC6Bkf7NM s2QsyLN3FU8VFo8uUZcRzmLKOKN1Y6vtAqbdWCcCNYEPJTafaGJkf6HgXUAyVBOxgDR+ +OZj6c36vXP9VExe84NGBaHDjwSiMfmtbJYTfE1qfNC+Zh894XDhtzg9hm9jWcGAasca zsbg== X-Gm-Message-State: ALoCoQmP84bKOis+LmOD5n0qBW7paA7Lu/sWNjOTP8LV71XSj7VOh5Gt5t9v7kpd+0UC+xRE8NjJ X-Received: by 10.68.134.167 with SMTP id pl7mr37542174pbb.45.1446606062843; Tue, 03 Nov 2015 19:01:02 -0800 (PST) Received: from [10.0.1.3] (p5231-ipngn5001hodogaya.kanagawa.ocn.ne.jp. [153.220.164.231]) by smtp.gmail.com with ESMTPSA id c4sm32195562pat.46.2015.11.03.19.01.01 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 03 Nov 2015 19:01:01 -0800 (PST) From: "Roland Dobbins" To: "dots@ietf.org" Date: Wed, 04 Nov 2015 12:00:59 +0900 Message-ID: <5534122E-42C4-4EF0-91EB-69A6A38E5528@arbor.net> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5164) Archived-At: Subject: Re: [Dots] Does DOTS require sneaker-net support? 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, 04 Nov 2015 03:01:09 -0000 On 4 Nov 2015, at 11:31, Dave Dolson wrote: > I'm asking because yesterday someone mentioned that occasionally > operators need to set things up after an attack has begun. I believe this is actually worthy of consideration - it's an interesting 'failsafe' approach. We shouldn't spend a lot of time on it just yet, but should keep it in mind as we progress, IMHO. DNS could also be potentially used for this sort of thing. ----------------------------------- Roland Dobbins From nobody Tue Nov 3 19:11: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 A18171A8BB1 for ; Tue, 3 Nov 2015 19:11:12 -0800 (PST) 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 vS08MCtC7Dbz for ; Tue, 3 Nov 2015 19:11:08 -0800 (PST) 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 463B21A8BB4 for ; Tue, 3 Nov 2015 19:11:08 -0800 (PST) Received: by pabfh17 with SMTP id fh17so37928495pab.0 for ; Tue, 03 Nov 2015 19:11:08 -0800 (PST) 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=cr2qmxkAESN8HzKnqkCIPNssrSnpbbATerfM4710X/U=; b=irK6WJ/xN7jnMkBJDFiLCS/JQUeMaKylLIjhUrtW1qii0juNn7JRmmv9qLhfAQw2Om 5hK4C30vyH6XimwkRpLZArtDTJvIjOoUrQmwwDbmm0gKvj/czpSOQmt+6WjCkOAPc5Tp slQztefsb/zElAcZQhLApCzBPMUWSz2720gUA= 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=cr2qmxkAESN8HzKnqkCIPNssrSnpbbATerfM4710X/U=; b=TCXMOOQUrd2U2H5iwHBwmCJ855Jeoo6bNYhdeUrgJhEuwYK1Oprfe1J6T1O0OQblyf xcOqf4Qv0v4IyHTptZqA/ZRyYL+WuuYiw4p6KBNs8CelA21OhBiDTREHO+4NXMAdJVff 1kIoDZQl1ZL//GTKtHz0+hLcCtEtrVRyHzLs6hHX4T4Gg5qsbuVOwY7PviUi2cPcrf2b RLHPCgEcyEYN2F0nKkiZEl89tgAZOiCT0Bd9EEfN7+lYye0QkVBkYcBVmHLfZZtTJHSx FE+Z/WunWjR1FUkcJtyr0q5EmtPQT6YM7IQuSTCIaH8sfKz7dozVLLMWt7tU/tTTXpvv JGCQ== X-Gm-Message-State: ALoCoQk761pGtmj4aa0WYrpWl+S2nRXwkVnNrfzkoVGGX/ndhTZGIqAaUvrM9LmeTOMFyJo9zqDe X-Received: by 10.66.172.144 with SMTP id bc16mr37303709pac.114.1446606667894; Tue, 03 Nov 2015 19:11:07 -0800 (PST) Received: from [10.0.1.3] (p5231-ipngn5001hodogaya.kanagawa.ocn.ne.jp. [153.220.164.231]) by smtp.gmail.com with ESMTPSA id c4sm32227126pat.46.2015.11.03.19.11.06 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 03 Nov 2015 19:11:07 -0800 (PST) From: "Roland Dobbins" To: dots Date: Wed, 04 Nov 2015 12:11:00 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5164) Archived-At: Subject: [Dots] DOTS crypto. (was Re: Using Diameter transport for DOTS?) 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, 04 Nov 2015 03:11:13 -0000 On 4 Nov 2015, at 11:48, Flemming Andreasen wrote: > TLS/DTLS satisfy a lot of what you list below From the crypto side of things, this model that the LISP folks are evaluating is potentially interesting for DOTS, IMHO: ----------------------------------- Roland Dobbins From nobody Tue Nov 3 19:21:02 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 CFA331A8F46 for ; Tue, 3 Nov 2015 19:21:00 -0800 (PST) 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 EyGTzSLUNyNV for ; Tue, 3 Nov 2015 19:20:56 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 877AA1A8F45 for ; Tue, 3 Nov 2015 19:20:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2780; q=dns/txt; s=iport; t=1446607256; x=1447816856; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=v4DAzRW9LyL6R8nHkqp05aSqmRPbhIcVrvyZgUT95ec=; b=eGJ0JDr0eqa6s6v48hBeOaTuPGddH4M3I1LSp8RH7wADKWRWFkB7c8Xs h/EqK9fIlSX0HBt3aEob82eZ6BgwQcpoJA/ifph+qSGV7Xdla9949N55z 5tgPFjBechCb/cq8y2wMRUkP+S5HbI7ue1KW4Iu7bbZF/brGkcGIe1H0J 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D7AQAieTlW/5xdJa1egztTbwa9QQENgV0XCoVyAhyBIzgUAQEBAQEBAYEKhDUBAQEEAQEBIBE6FwQCAQgRBAEBAQICIwMCAgIlCxQBCAgBAQQBEgiIJg2wWpB+AQEBAQEBAQEBAQEBAQEBAQEBAQEBFASBAoVThH6EQoMzgUMFlkYBiAyFDoFhhD+WJQEfAQFChARyhC2BBwEBAQ X-IronPort-AV: E=Sophos;i="5.20,241,1444694400"; d="scan'208";a="41597002" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 04 Nov 2015 03:20:55 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id tA43Kt9m005037 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 Nov 2015 03:20:55 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 3 Nov 2015 21:20:54 -0600 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; Tue, 3 Nov 2015 21:20:55 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "Flemming Andreasen (fandreas)" , Dave Dolson , dots Thread-Topic: [Dots] Using Diameter transport for DOTS? Thread-Index: AdEWb+LjKy2VsZZAT7KTysuTEiK/GQAbbfaAAAvQTcA= Date: Wed, 4 Nov 2015 03:20:55 +0000 Message-ID: <5730f98c87df41179715cdff49503c86@XCH-RCD-017.cisco.com> References: <20151103194312.594948115.52080.45702@sandvine.com> <56397209.1070404@cisco.com> In-Reply-To: <56397209.1070404@cisco.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.42.239] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Using Diameter transport for DOTS? 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, 04 Nov 2015 03:21:01 -0000 KyAxIGZvciAoRClUTFMuIEFuZCB3aXRoIFRMUyAxLjMsIDAtUlRUIGlzIHBvc3NpYmxlLiANCkRP VFMgY2xpZW50IGFuZCBzZXJ2ZXIgY2FuIGNvbXBsZXRlIERUTFMgaGFuZHNoYWtlIGR1cmluZyBu b24tYXR0YWNrIHRpbWUgYW5kIHRoZSBET1RTIGNsaWVudCBjYW4gY29udmV5IHRoZSBTT1MgbWVz c2FnZSBhbG9uZyB3aXRoIHRoZSBDbGllbnQgSGVsbG8uIFNpbWlsYXJseSB3aXRoIFRDUCBmYXN0 IE9wZW4sIFNPUyBjYW4gYmUgc2VudCBpbiBTWU4gcGFja2V0IGl0c2VsZiBhbG9uZyB3aXRoIHRo ZSBDbGllbnQgSGVsbG8uIFNPUyBtZXNzYWdlIGFuZCBtb3N0IG9mIHRoZSBoYW5kc2hha2UgbWVz c2FnZSB3aWxsIGFsc28gYmUgZW5jcnlwdGVkLiANCg0KLVRpcnUNCg0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBEb3RzIFttYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgRmxlbW1pbmcNCj4gQW5kcmVhc2VuIChmYW5kcmVhcykNCj4gU2VudDog V2VkbmVzZGF5LCBOb3ZlbWJlciAwNCwgMjAxNSA4OjE5IEFNDQo+IFRvOiBEYXZlIERvbHNvbjsg ZG90cw0KPiBTdWJqZWN0OiBSZTogW0RvdHNdIFVzaW5nIERpYW1ldGVyIHRyYW5zcG9ydCBmb3Ig RE9UUz8NCj4gDQo+IFdlIG9idmlvdWxzeSBzaG91bGQgZG8gYSBwcm9wZXIgZXZhbHVhdGlvbiBh Z2FpbnN0IHRoZSByZXF1aXJlbWVudHMgb25jZQ0KPiB3ZSBoYXZlIHZldHRlZCB0aG9zZSBhIGJp dCBtb3JlLCBidXQgbXkgaW5pdGlhbCByZWFjdGlvbiBpcyB0aGF0IHRoaXMgc2VlbXMgbGlrZQ0K PiBhIGZhaXJseSBoZWF2eS1oYW5kZWQgYXBwcm9hY2ggdG8gdGhlIHByb2JsZW0gYXQgaGFuZCAo d2UgZG8gbmVlZCB0bw0KPiB1bmRlcnN0YW5kIHRoZSByZXF1aXJlbWVudHMgb24gRE9UUyByZWxh eXMgYmV0dGVyIHRob3VnaCkuDQo+IFRMUy9EVExTIHNhdGlzZnkgYSBsb3Qgb2Ygd2hhdCB5b3Ug bGlzdCBiZWxvdywgYW5kIEknbSBub3Qgc3VyZSB3ZSBuZWVkDQo+IHNvbWV0aGluZyBhcyBlbGFi b3JhdGUgYXMgRElBTUVURVIgb24gdG9wIG9mIHRoYXQuIEFsc28sIHBsZWFzZSBrZWVwIGluDQo+ IG1pbmQgdGhhdCB3ZSBoYXZlIHVzZSBjYXNlIHNjZW5hcmlvcyBpbnZvbHZpbmcgZW5kcG9pbnRz LCBhbmQgcmVxdWlyaW5nDQo+IHRob3NlIHRvIHN1cHBvcnQgRElBTUVURVIgZm9yIGEgYmFzaWMg Y2xpZW50LXNpZGUgYXBwIG9yIHdlYiBwb3J0YWwgc2VlbXMNCj4gbGlrZSBhIHRhbGwgb3JkZXIg dG8gbWUuDQo+IA0KPiBPbiBhIHJlbGF0ZWQgbm90ZSwgaXQncyBiZWVuIGEgd2hpbGUgc2luY2Ug SSBsb29rZWQgYXQgRElBTUVURVIsIGJ1dCB3aGF0IGlzDQo+IHRoZSBhZG9wdGlvbi9kZXBsb3lt ZW50IHN0YXR1cyBvZiB0aGF0IG91dHNpZGUgb2YgM0dQUCB0aGVzZSBkYXlzID8NCj4gDQo+IFRo YW5rcw0KPiANCj4gLS0gRmxlbW1pbmcNCj4gDQo+IA0KPiANCj4gDQo+IE9uIDExLzMvMTUgMjo0 MyBQTSwgRGF2ZSBEb2xzb24gd3JvdGU6DQo+ID4gQ291bGQgRGlhbWV0ZXIgc2F0aXNmeSB0aGUg dHJhbnNwb3J0IHByb3RvY29sIG5lZWRzIG9mIERPVFM/DQo+ID4gSXQgYWxyZWFkeSBoYXMgc2Vj dXJpdHksIG11dHVhbCBhdXRoZW50aWNhdGlvbiwgYm90aCBkYXRhZ3JhbSAoU0NUUCkgYW5kDQo+ IFRDUCB0cmFuc3BvcnRz4oCOLCB3YXRjaGRvZyB0aW1lcnMsIHJlZHVuZGFuY3ksIHRoZSBjb25j ZXB0IG9mIHJlbGF5cy4uLg0KPiA+DQo+ID4gLURhdmUNCj4gPg0KPiA+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gRG90cyBtYWlsaW5nIGxpc3QN Cj4gPiBEb3RzQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9kb3RzDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiBEb3RzIG1haWxpbmcgbGlzdA0KPiBEb3RzQGlldGYub3JnDQo+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90cw0K From nobody Tue Nov 3 19:23: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 88A451A8FD5 for ; Tue, 3 Nov 2015 19:23:49 -0800 (PST) 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 iLhaTXv6EgM5 for ; Tue, 3 Nov 2015 19:23:48 -0800 (PST) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::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 CDBFF1A8AD6 for ; Tue, 3 Nov 2015 19:23:47 -0800 (PST) Received: by ykek133 with SMTP id k133so51573158yke.2 for ; Tue, 03 Nov 2015 19:23:47 -0800 (PST) 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=LRaXsiH7fHGVLwHj/g5FdG0wkE91J6mYN0deWtOUmME=; b=j5jNJry96Wf0nzICekNVw1B8689fl/rPnKi4xw4xvlkU3vIUMxmBoCRadvLMvqlC9T tIh+Hq5GICJyEqTvddzheUyDE5gywYyOO5cBkDs+7O3pemgZmRLI5qXjEweEOkemb1Is X4RMNNLlb7FB55eLlLqGshehWi7ExRNl8q7Fm55vegtWGLq1cV4+7FZej+AgRo6w5vk0 Is/om0xK3j8XB94m69W8qfYjHD74vYUPIUaa/sY/cCDD4hdNZ6RsYKKWkkUCVXADd00/ 47uKj85LSaUVbUGApJek2pun8YKjTJbSBXpPngrhtoEcyIV8OAzcq5Rs7Fui3aCJLYQy vCdQ== MIME-Version: 1.0 X-Received: by 10.129.82.18 with SMTP id g18mr23524459ywb.234.1446607427154; Tue, 03 Nov 2015 19:23:47 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.13.202.16 with HTTP; Tue, 3 Nov 2015 19:23:47 -0800 (PST) In-Reply-To: <5534122E-42C4-4EF0-91EB-69A6A38E5528@arbor.net> References: <5534122E-42C4-4EF0-91EB-69A6A38E5528@arbor.net> Date: Wed, 4 Nov 2015 14:23:47 +1100 X-Google-Sender-Auth: ahGZNOijGpdh8RGHONWYoqmTSnw Message-ID: From: Christopher Morrow To: Roland Dobbins Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "dots@ietf.org" Subject: Re: [Dots] Does DOTS require sneaker-net support? 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, 04 Nov 2015 03:23:49 -0000 it might be worth (for dave maybe at least) waling through a 'day in the life' of this job: scenario 1 - customer setup with mitigation service and dots equipment/etc. 1) drink coffee 2) customer detects attack (or you detect attack on customer) 3) dots client fires off 'help me' message 4) back to coffee scenario 2 - customer as no dos-mitigation service/setup with you 1) drink coffee 2) customer calls your 'soc' (tech support) with issue 3) issue is triaged to 'dos attack on customer' 4) attack mitigation initiated for customer in some manner (perhaps via dots client under your control, perhaps with other means, not important) 5) get sales-eqiuvalent-folks involved with customer to discuss longer term strategy, ie: "Hey, we did this for free, it's costing us bucks, how about we get a contract/etc done so you share some fo the burden here (and consequently get quicker mitigation in the future)" 6) back to coffee (note that not all dos-mitigation-workers drink coffee) I think there may be the need to agree up on the credentials/endpoints/resources-under-protection/etc out of band. There is certainly the scenario where this all happens 'on the line' and via some automated means. In the end, the conversation during a problem is: o short o to the point o not dependent upon 2 way communications (though certainly with 2-way more rich information could be expressed) o 'secure' -chris On Wed, Nov 4, 2015 at 2:00 PM, Roland Dobbins wrote: > On 4 Nov 2015, at 11:31, Dave Dolson wrote: > >> I'm asking because yesterday someone mentioned that occasionally operators >> need to set things up after an attack has begun. > > > I believe this is actually worthy of consideration - it's an interesting > 'failsafe' approach. We shouldn't spend a lot of time on it just yet, but > should keep it in mind as we progress, IMHO. > > DNS could also be potentially used for this sort of thing. > > ----------------------------------- > Roland Dobbins > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Tue Nov 3 19:32:07 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 CCCC01A9042 for ; Tue, 3 Nov 2015 19:32:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 QIv8jhNRLp-q for ; Tue, 3 Nov 2015 19:32:03 -0800 (PST) Received: from atl4mhob16.myregisteredsite.com (atl4mhob16.myregisteredsite.com [209.17.115.109]) by ietfa.amsl.com (Postfix) with ESMTP id 3C10F1A9044 for ; Tue, 3 Nov 2015 19:32:03 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.209]) by atl4mhob16.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id tA43W1tB029334 for ; Tue, 3 Nov 2015 22:32:01 -0500 Received: (qmail 29452 invoked by uid 0); 4 Nov 2015 03:32:01 -0000 X-TCPREMOTEIP: 50.241.159.113 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?172.20.2.57?) (wes@mti-systems.com@50.241.159.113) by 0 with ESMTPA; 4 Nov 2015 03:32:01 -0000 To: dots@ietf.org References: <5638D31B.4080801@mti-systems.com> From: Wesley Eddy Message-ID: <56397C2D.9060102@mti-systems.com> Date: Tue, 3 Nov 2015 22:31:57 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------080000040400080804030907" Archived-At: Subject: Re: [Dots] Best transport selection during an attack? 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, 04 Nov 2015 03:32:06 -0000 This is a multi-part message in MIME format. --------------080000040400080804030907 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 11/3/2015 8:29 PM, Aaron Falk wrote: > On Wed, Nov 4, 2015 at 12:30 AM, Wesley Eddy > wrote: > > > > Whether or not UDP will work between networks can be tested and > determined ahead of time, so resolving UDP-blocking problems can > be dealt with in non-realtime (the same problem may exist for > blocking of unknown TCP ports anyways, so testing of the signaling > channel should always be done in nominal conditions, ahead of when > its needed for attack response). > > > Wes- > > DOTS has a use case where the DOTS server may in a cloud provider, ie, > not be in an adjacent network. I think your comment above may be > difficult to implement since the client would require cooperation from > network providers with whom they have no business relationship. And, > you might not be able to tell you have a problem getting UDP through > until you are under attack, when some operator may implement filtering > that inhibits connectivity. By probing the path ahead of time, and using all available protocols, you're going to wind up utilizing any feasible channel. If there are no feasible channels, you're just screwed, and nothing more can really be done over the network. You might fall-back to using a modem to dial-out and get a direct connection to control mitigations over, or maybe you can pack the SOS message into an SMS and text it out (securing that seems more difficult though). --------------080000040400080804030907 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 11/3/2015 8:29 PM, Aaron Falk wrote:
On Wed, Nov 4, 2015 at 12:30 AM, Wesley Eddy <wes@mti-systems.com> wrote:
>
Whether or not UDP will work between networks can be tested and determined ahead of time, so resolving UDP-blocking problems can be dealt with in non-realtime (the same problem may exist for blocking of unknown TCP ports anyways, so testing of the signaling channel should always be done in nominal conditions, ahead of when its needed for attack response).

Wes-

DOTS has a use case where the DOTS server may in a cloud provider, ie, not be in an adjacent network.  I think your comment above may be difficult to implement since the client would require cooperation from network providers with whom they have no business relationship.  And, you might not be able to tell you have a problem getting UDP through until you are under attack, when some operator may implement filtering that inhibits connectivity.


By probing the path ahead of time, and using all available protocols, you're going to wind up utilizing any feasible channel.  If there are no feasible channels, you're just screwed, and nothing more can really be done over the network.  You might fall-back to using a modem to dial-out and get a direct connection to control mitigations over, or maybe you can pack the SOS message into an SMS and text it out (securing that seems more difficult though).




--------------080000040400080804030907-- From nobody Tue Nov 3 19:32: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 6E7561A9045 for ; Tue, 3 Nov 2015 19:32:21 -0800 (PST) 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 19tyOFubGsVK for ; Tue, 3 Nov 2015 19:32:20 -0800 (PST) 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 384F21A9037 for ; Tue, 3 Nov 2015 19:32:20 -0800 (PST) Received: by pasz6 with SMTP id z6so39141742pas.2 for ; Tue, 03 Nov 2015 19:32:19 -0800 (PST) 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=M9TejHJ0hKE4iAABl/G0xHrHPpJBZap/PCksKxuj6SA=; b=ECuQeat8NMCoM/IkakzuA0Zno5lBpmBxc1GmpAilcXpyB9VxkuWtxBHnedewBi8t63 o1dOAp2Uuk7kfwoVzzvGUzGXNXtHaF9Asec2HxO2aRePTnekKW7fgCGml3w2EAVGEVdl 48yW3mH2G54HD2yo0/LKxnx776OhdeAYw70z0= 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=M9TejHJ0hKE4iAABl/G0xHrHPpJBZap/PCksKxuj6SA=; b=X96z9vSC9KluZe6NtxJYuZ34CZj/Mq2rhVit+oBXJ7GA/++Xq0Bdt0n4/lMkVHS7pe WNEnDDNxXOYPvFXxHgL4US3PUnQb+H8CfvdEggI4+0IihUCx/A2zgfnGil/Edk2Bbgul NgcYNm57DnZsTMYJ4ob9+LZhhEK+fn10jLZgqTUSSBrFPa/MFaXktbVzgVdh5gjufdgL gkGSwNv2nFL6k/p4OP2YkWmkysQDoRt5gTYUuCNVyOgDdTuKX47Ejug2DU2/Ad0q/yaV SIvbgK91G/fZSg+wud5TbJaWJmhcyjTFPib08kJRgQRabkW5Jxm8r5J0jD3eU/R0uSDc jEuQ== X-Gm-Message-State: ALoCoQkShbpm00jyicSr5LCy21R+6zb+tzpiIDj33Vvm3T1qMVp7wWmgTyYssPnV4CULncYSSbs4 X-Received: by 10.66.253.232 with SMTP id ad8mr37784758pad.21.1446607939851; Tue, 03 Nov 2015 19:32:19 -0800 (PST) Received: from [10.0.1.3] (p5231-ipngn5001hodogaya.kanagawa.ocn.ne.jp. [153.220.164.231]) by smtp.gmail.com with ESMTPSA id c3sm32166819pbu.24.2015.11.03.19.32.18 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 03 Nov 2015 19:32:18 -0800 (PST) From: "Roland Dobbins" To: "dots@ietf.org" Date: Wed, 04 Nov 2015 12:32:16 +0900 Message-ID: In-Reply-To: References: <5534122E-42C4-4EF0-91EB-69A6A38E5528@arbor.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5164) Archived-At: Subject: Re: [Dots] Does DOTS require sneaker-net support? 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, 04 Nov 2015 03:32:21 -0000 On 4 Nov 2015, at 12:23, Christopher Morrow wrote: > In the end, the conversation during a problem is: > o short > o to the point > o not dependent upon 2 way communications (though certainly with > 2-way more rich information could be expressed) > o 'secure' Concur - this is the desired process for ad-hoc, out-of-band provisioning and mitigation service initiation. If folks agree, maybe we can keep this on the back-burner until we're a bit further along. ----------------------------------- Roland Dobbins From nobody Tue Nov 3 19:43: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 BF02E1A9084 for ; Tue, 3 Nov 2015 19:43:47 -0800 (PST) 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 WPQJfV3PNzkx for ; Tue, 3 Nov 2015 19:43:46 -0800 (PST) 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 31AC11A9087 for ; Tue, 3 Nov 2015 19:43:46 -0800 (PST) Received: by pasz6 with SMTP id z6so39443551pas.2 for ; Tue, 03 Nov 2015 19:43:45 -0800 (PST) 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=76NeKAPFqf3RNF4x5RwlYTXl5AhgGGkQqyW/Pbmu5AE=; b=VicxKkprBONO22TSxC05oMTv23L33FPxyic9gEBj3c2w6TEnEhokES+KHjRLX4X/8S 2OT7i92EpheafNS1plBezzFWvk8zR9QoxK2ZfOvXeTks4SsQb7Xl+g+Yo03shT6sgE8J +PBouPUm2Msx178uawmt8ljLZOkmyzsGny6e0= 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=76NeKAPFqf3RNF4x5RwlYTXl5AhgGGkQqyW/Pbmu5AE=; b=NSSEx21NqP5gTYRXm97ILxuM94zO6ylWLZj/aaA5VdGFcglbNogvdNADDDuo/KxC4J knWkZtKrBFQ4Sda+stBkXyyt+dfnmZAsTn7qm4SdOqbWZj13pRiJqzv+nGt3/wxFtd3k n2riVbFRhU6LTbmv/pONZoTXzTkLQTi6V6HwKghvIoR7xdRNPxAwG07OM970NWvnnL7o FqVH78Zss+OutdoOQmoR1e2B0JraPNAQG+Pwwt1QrltkdteVj3aFk935iYDTzi3x8tqp e9i+Dj+Xaqi+kD2wggkZRsmY1DRt93xGQ2M+C539RusUIgmNC0I2mYedHy5yEnO95wQ6 J0Qg== X-Gm-Message-State: ALoCoQm6/hMnhfMKVVpcXnrl6nYVrheE07dQ2yEBdCTqVM2GJ5pO9+H51IZ2Mm9JY3e6t7kFnzUK X-Received: by 10.68.201.5 with SMTP id jw5mr24754553pbc.28.1446608625818; Tue, 03 Nov 2015 19:43:45 -0800 (PST) Received: from [10.0.1.3] (p5231-ipngn5001hodogaya.kanagawa.ocn.ne.jp. [153.220.164.231]) by smtp.gmail.com with ESMTPSA id tn2sm32258357pac.0.2015.11.03.19.43.44 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 03 Nov 2015 19:43:45 -0800 (PST) From: "Roland Dobbins" To: dots@ietf.org Date: Wed, 04 Nov 2015 12:43:42 +0900 Message-ID: <4BE83613-FB76-47C7-9AC3-6389A8F3D269@arbor.net> In-Reply-To: <56397C2D.9060102@mti-systems.com> References: <5638D31B.4080801@mti-systems.com> <56397C2D.9060102@mti-systems.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5164) Archived-At: Subject: Re: [Dots] Best transport selection during an attack? 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, 04 Nov 2015 03:43:47 -0000 On 4 Nov 2015, at 12:31, Wesley Eddy wrote: > By probing the path ahead of time, Again, heartbeats fulfill this function pre-attack, and the status messaging and related acknowledgements fulfill this function during an attack. And paths or some portions thereof may well be dynamic due to the nature of the Internet and BGP in general, much less any local decisionmaking on the originating end (presuming multihoming). Ideally, DOTS signaling would be done out-of-band in relation to the attack path, but we know that the majority of deployments won't bother with this. Nevertheless, it should be part of the deployment guidance for DOTS. ----------------------------------- Roland Dobbins From nobody Tue Nov 3 19:47: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 457301A9096 for ; Tue, 3 Nov 2015 19:47:51 -0800 (PST) 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 oPUkD0dum4Ei for ; Tue, 3 Nov 2015 19:47:49 -0800 (PST) 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 9360C1A9067 for ; Tue, 3 Nov 2015 19:47:49 -0800 (PST) Received: by pacdm15 with SMTP id dm15so14525404pac.3 for ; Tue, 03 Nov 2015 19:47:49 -0800 (PST) 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=99EBn7MNNrJ7mgImE69U4ZpQ8s/8TwisjDRJQypCWS8=; b=Zhis6du8Yz61LfaWrfeJv0E3dmRnHLZL7ddabdZLg6zs+TLIzN+dLhZORPs3V2tjUK F+J/G7mcQBH6gi4Z4nw+q0TBrzHBME3vxrfietzf1sxp70qZ639bw0Gd/8gr4eHhGMrH +vT9FcwwKV7A/6q5y+GLST+AMaMTCLpislYS0= 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=99EBn7MNNrJ7mgImE69U4ZpQ8s/8TwisjDRJQypCWS8=; b=Pq6QP3R7zW9r4gEQUK5W0Q+0m8bZvCh+0O/b8EViFXj2laNQeVHZIrTyJs46CTUBTl dkyO0K60/iqbYn9ZlTy2SRBavHrPnCVnGtPWfoSeWssoAUWwTUjty7g7ni9vYgFT5AdA rPUtWOCWDLALonKOL3I4Qy9x6yOQHhVDZYcDand20zBeruSA9+YXxckNIRSub7rPKS6g AF77oMxEws7IX9pj0izUyaDYR8cNz2xITAa4MblHNUAttUX2X/Ekgu6Qm+fs45NNRqFl omAXUmy1mR7Yswr0ISuOnJ9memRB0seDrFLdcEuoLhtVC4PsKEiAd4X8Y+hIaIvqPBvO 3zSA== X-Gm-Message-State: ALoCoQmBazstbROH0Sv7+WmhrBl7lgZD9kcEbd5K+T8W+xyWdpziKaO6Bz7QQVGvYGI1ccd4y8wf X-Received: by 10.68.134.3 with SMTP id pg3mr37747454pbb.41.1446608869242; Tue, 03 Nov 2015 19:47:49 -0800 (PST) Received: from [10.0.1.3] (p5231-ipngn5001hodogaya.kanagawa.ocn.ne.jp. [153.220.164.231]) by smtp.gmail.com with ESMTPSA id xu5sm32302167pab.12.2015.11.03.19.47.48 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 03 Nov 2015 19:47:48 -0800 (PST) From: "Roland Dobbins" To: dots Date: Wed, 04 Nov 2015 12:47:46 +0900 Message-ID: <2880D1B0-BE00-4B87-9763-AA55B024F286@arbor.net> In-Reply-To: <5730f98c87df41179715cdff49503c86@XCH-RCD-017.cisco.com> References: <20151103194312.594948115.52080.45702@sandvine.com> <56397209.1070404@cisco.com> <5730f98c87df41179715cdff49503c86@XCH-RCD-017.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5164) Archived-At: Subject: Re: [Dots] Using Diameter transport for DOTS? 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, 04 Nov 2015 03:47:51 -0000 On 4 Nov 2015, at 12:20, Tirumaleswar Reddy (tireddy) wrote: > DOTS client and server can complete DTLS handshake during non-attack > time This assumes pre-attack provisioning. A depressingly large proportion of DDoS mitigation provisioning takes place during an attack. > and the DOTS client can convey the SOS message along with the Client > Hello. Personally, I'm not a big fan of the 'SOS' terminology. > Similarly with TCP fast Open, SOS can be sent in SYN packet itself > along with the Client Hello. True, s/'SOS'/'Mitigation service request'. > SOS message and most of the handshake message will also be encrypted. Again, this assumes proactive provisioning. Sadly, we can't assume that, per the above. ----------------------------------- Roland Dobbins From nobody Tue Nov 3 20:02: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 441291A8881 for ; Tue, 3 Nov 2015 20:02:26 -0800 (PST) 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 g9UnmP5rRQmz for ; Tue, 3 Nov 2015 20:02:24 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAA4B1A88E9 for ; Tue, 3 Nov 2015 20:02:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1626; q=dns/txt; s=iport; t=1446609746; x=1447819346; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=NbZJxCyvdmJF4uu9BE83xzvasSMr6q2M8JOacU8zfaI=; b=J5JaZiKNkOn5q+PKaCc/NaY8gJN0loZbGr77CGaM1VKq1Ct9DZbqJZzQ hTsS1JsiOSpoPrQsUXsEcrS1K2wyP9LwxLQeTXl/8VisZ4hyE2SEN00XO L39+DyvwzIRrrMaVzpOMghegQcVjoluWVjQYeWgLUIM9t6EluRRIXlQD7 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D6AQBggjlW/5BdJa1egztTbwa9QQENgV0XCoVyAoE8OBQBAQEBAQEBgQqENQEBAQMBAQEBNzQXBAIBCA4DBAEBAR4JBycLFAkIAQEEARIIiB4IDcFSAQEBAQEBAQEBAQEBAQEBAQEBAQEBFASGVYR+hEKEdgWHRI8CAY0anEUBHwEBQoQEcoQtgQcBAQE X-IronPort-AV: E=Sophos;i="5.20,241,1444694400"; d="scan'208";a="43639146" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-4.cisco.com with ESMTP; 04 Nov 2015 04:02:25 +0000 Received: from XCH-ALN-019.cisco.com (xch-aln-019.cisco.com [173.36.7.29]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id tA442NuJ010472 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 Nov 2015 04:02:23 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-ALN-019.cisco.com (173.36.7.29) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 3 Nov 2015 22:02:23 -0600 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; Tue, 3 Nov 2015 22:02:23 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Roland Dobbins , dots Thread-Topic: [Dots] Using Diameter transport for DOTS? Thread-Index: AdEWb+LjKy2VsZZAT7KTysuTEiK/GQAbbfaAAAvQTcD//7H/AIAAYo2A Date: Wed, 4 Nov 2015 04:02:23 +0000 Message-ID: <83efd6bb305348aea6145f4b94629d3d@XCH-RCD-017.cisco.com> References: <20151103194312.594948115.52080.45702@sandvine.com> <56397209.1070404@cisco.com> <5730f98c87df41179715cdff49503c86@XCH-RCD-017.cisco.com> <2880D1B0-BE00-4B87-9763-AA55B024F286@arbor.net> In-Reply-To: <2880D1B0-BE00-4B87-9763-AA55B024F286@arbor.net> 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.42.239] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Using Diameter transport for DOTS? 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, 04 Nov 2015 04:02:26 -0000 > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Roland Dobbins > Sent: Wednesday, November 04, 2015 9:18 AM > To: dots > Subject: Re: [Dots] Using Diameter transport for DOTS? >=20 >=20 > On 4 Nov 2015, at 12:20, Tirumaleswar Reddy (tireddy) wrote: >=20 > > DOTS client and server can complete DTLS handshake during non-attack > > time >=20 > This assumes pre-attack provisioning. A depressingly large proportion of > DDoS mitigation provisioning takes place during an attack. DOTS client and server must perform mutual authentication, and if authentic= ation is to happen during an attack then it involves multiple messages back= and forth. With TLS 1.3, pre-attack provisioning helps to send only one en= crypted and integrity protected 'Mitigation service request' message.=20 >=20 > > and the DOTS client can convey the SOS message along with the Client > > Hello. >=20 > Personally, I'm not a big fan of the 'SOS' terminology. Any suggestions for alternate names ? -Tiru >=20 > > Similarly with TCP fast Open, SOS can be sent in SYN packet itself > > along with the Client Hello. >=20 > True, s/'SOS'/'Mitigation service request'. >=20 > > SOS message and most of the handshake message will also be encrypted. >=20 > Again, this assumes proactive provisioning. Sadly, we can't assume that,= per > the above. >=20 > ----------------------------------- > Roland Dobbins >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Tue Nov 3 20:12: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 BFCC31A8A60; Tue, 3 Nov 2015 20:02:33 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 poHI_dpclA_G; Tue, 3 Nov 2015 20:02:29 -0800 (PST) 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 DD0A71A8A06; Tue, 3 Nov 2015 20:02:28 -0800 (PST) Received: by ykdr3 with SMTP id r3so52425205ykd.1; Tue, 03 Nov 2015 20:02:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bF3bzWJE1KsQKKKmD79BdZDmnehkT5Baeuc+UI3EPWM=; b=Qao3NasXEaGelgSBgJ47N+T6BqHvdO/lc+eoqkg+nnYYKuRzv0YOqWQL3ZuKlvB7m8 zrBQ18OcYUB4D7o2FK+EOfmeIyaN1iobQ/T2iPu2IPTuRHlrsOHZj7qsp+X2f0PXTrRe a1dz3FHrF99UhB0QPUZeNcWuwdpzrmArfsaOh2wvw9GWihF8uw2baSKNnB9jykZ2CzlR 699GxzC73zRvaMi5KdVeCIqjEVOaoc9dXBQeFfgTJ5o8cDyd4R0dlEWtNhvqAeiVRygH 1TNmYv2Lf/awsObQMlC001qvamXplkVoMBJmlxDG4+Xgws258FXJRTPPQWamqkt8mpSL udRw== MIME-Version: 1.0 X-Received: by 10.129.55.211 with SMTP id e202mr23077795ywa.254.1446609748234; Tue, 03 Nov 2015 20:02:28 -0800 (PST) Received: by 10.37.95.2 with HTTP; Tue, 3 Nov 2015 20:02:28 -0800 (PST) In-Reply-To: <0A836E5A-C801-4CF4-916C-41EA065D3D30@arbor.net> References: <5638D31B.4080801@mti-systems.com> <0A836E5A-C801-4CF4-916C-41EA065D3D30@arbor.net> Date: Wed, 4 Nov 2015 13:02:28 +0900 Message-ID: From: Aaron Falk To: "tsvwg-chairs@ietf.org" Content-Type: multipart/alternative; boundary=001a1143fb7a2c1e190523af14ef Archived-At: X-Mailman-Approved-At: Tue, 03 Nov 2015 20:12:18 -0800 Cc: dots@ietf.org, "tsvwg@ietf.org" Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 04 Nov 2015 04:02:33 -0000 --001a1143fb7a2c1e190523af14ef Content-Type: text/plain; charset=UTF-8 TSVWG chairs- Will you allocate some time for this topic? --aaron On Wed, Nov 4, 2015 at 7:10 AM, Roland Dobbins wrote: > On 4 Nov 2015, at 1:22, Ca By wrote: > > at least in the case i am most familiar with. >> > > It is important to keep this part in mind. > > With DOTS in UDP, you are putting the DOTs traffic in that path that >> becomes the most lossy during a a DDoS. >> > > This is an overgeneralization - see above. > > There are lots of topological and pathing assumptions being made, here, as > well as policy-filtering assumptions. > > It has been clear from the beginning of this effort that both stateless > and stateful transport options are necessary, due to overly-restrictive > network access policies, edge QoSing as a (counterproductive, IMHO) measure > against UDP reflection/amplification attacks, etc. This has been discussed > on-list and in meetings, it's unclear why it's become contentious, all of a > sudden. > > ----------------------------------- > Roland Dobbins > > --001a1143fb7a2c1e190523af14ef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
TSVWG chairs-

Will you allocate some ti= me for this topic?

--aaron

On Wed, Nov 4, 2015 at 7:10= AM, Roland Dobbins <rdobbins@arbor.net> wrote:
On 4 Nov 2015, at 1:22, Ca By wrote= :

at least in the case i am most familiar with.

 It is important to keep this part in mind.

With DOTS in UDP, you are putting the DOTs traffic in that path that become= s the most lossy during a a DDoS.

 This is an overgeneralization - see above.

There are lots of topological and pathing assumptions being made, here, as = well as policy-filtering assumptions.

It has been clear from the beginning of this effort that both stateless and= stateful transport options are necessary, due to overly-restrictive networ= k access policies, edge QoSing as a (counterproductive, IMHO) measure again= st UDP reflection/amplification attacks, etc.=C2=A0 This has been discussed= on-list and in meetings, it's unclear why it's become contentious,= all of a sudden.

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


--001a1143fb7a2c1e190523af14ef-- From nobody Tue Nov 3 20:19: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 652781A914E for ; Tue, 3 Nov 2015 20:19:35 -0800 (PST) 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 JMuQuM1kGPlq for ; Tue, 3 Nov 2015 20:19:31 -0800 (PST) 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 9A0A31A9147 for ; Tue, 3 Nov 2015 20:19:31 -0800 (PST) Received: by padhx2 with SMTP id hx2so31751061pad.1 for ; Tue, 03 Nov 2015 20:19:31 -0800 (PST) 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=TF5pA/JPmFAvxEb36BDUIS27FBU2yrZtkH7uCCuCk94=; b=oF9DWRqyIuwZKYak+yAyue/L8JERJdMit/xLfQeYDDvlcT0wKtCDEJ7xNT6zEqb6al 5yymDy1ibG0OIjQNE9FX4NTtXifG5uOfiYH6/8BCb/J8GbISt+H0ZSJrhdIXmFIUBZF4 ZNmbli0Et6RKLdbH4thDgl7yjhQ5jW1R0MIPM= 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=TF5pA/JPmFAvxEb36BDUIS27FBU2yrZtkH7uCCuCk94=; b=XnaiRcubDzjlPUiU/JHFegZ24PbG79OrY3Q9D3zFroL9ZyYMnjTza4jHI2wlkGkNX/ /ct1VTglzny9MRAndBuwiAIbXU7b/jpJDpxE4QqzI7Tj4uhdBZUt0aRsWIAia0rDo8Lj CFrFy/mwLSzTE2Fnwn+E+w0c3lHsmGJQL0ltlc7yP1ekLd+XqriLOSFYf/ySizvJ8/m+ x0ae1YG8svVybNSbAjepYiRwYCt8c3qtGCWhTmdfzbiE4y+8AN2rvG2PeLjPRwGnXmim 0+THvu/5GVIDOPvjqhCyNLCRTeYb5rJ6ZfWWe+lafjjYl483E8WsR0RjfG8gWwB4UfCo x5gw== X-Gm-Message-State: ALoCoQnpYmcpPEydLU9T1Fn3wLsejNTSFJIylSSDSq+9VCDtG98p8j+X9jfRTN9VFzqMURa4kWHk X-Received: by 10.69.10.163 with SMTP id eb3mr38818613pbd.162.1446610771274; Tue, 03 Nov 2015 20:19:31 -0800 (PST) Received: from [10.0.1.3] (p5231-ipngn5001hodogaya.kanagawa.ocn.ne.jp. [153.220.164.231]) by smtp.gmail.com with ESMTPSA id sb6sm15195219pbc.66.2015.11.03.20.19.30 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 03 Nov 2015 20:19:30 -0800 (PST) From: "Roland Dobbins" To: dots Date: Wed, 04 Nov 2015 13:19:28 +0900 Message-ID: <12018EDA-A9E6-48DA-AC9A-F6E87C9D19B3@arbor.net> In-Reply-To: <83efd6bb305348aea6145f4b94629d3d@XCH-RCD-017.cisco.com> References: <20151103194312.594948115.52080.45702@sandvine.com> <56397209.1070404@cisco.com> <5730f98c87df41179715cdff49503c86@XCH-RCD-017.cisco.com> <2880D1B0-BE00-4B87-9763-AA55B024F286@arbor.net> <83efd6bb305348aea6145f4b94629d3d@XCH-RCD-017.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5164) Archived-At: Subject: Re: [Dots] Using Diameter transport for DOTS? 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, 04 Nov 2015 04:19:35 -0000 On 4 Nov 2015, at 13:02, Tirumaleswar Reddy (tireddy) wrote: > DOTS client and server must perform mutual authentication, and if > authentication is to happen during an attack then it involves multiple > messages back and forth. Not necessarily: > With TLS 1.3, pre-attack provisioning helps to send only one encrypted > and integrity protected 'Mitigation service request' message. True, in the context of TLS 1.3. > Any suggestions for alternate names ? 'Mitigation service request'. ;> ----------------------------------- Roland Dobbins From nobody Tue Nov 3 20:33: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 745F81A92DC for ; Tue, 3 Nov 2015 20:33:01 -0800 (PST) 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 vrkf596iGH8D for ; Tue, 3 Nov 2015 20:33:00 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E4561A92E1 for ; Tue, 3 Nov 2015 20:33:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1146; q=dns/txt; s=iport; t=1446611580; x=1447821180; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=jRSXqA5LU2zFtRv36jZkiv5SsfDuu34NIdR4IHm574E=; b=TezNhgXsemdJvHo7zZfVWAhnGyp/puhRMlLyEImjdP8FnpghAr1YrFvQ srDbJO75G6hqNILw5eUWvxdvPSjOu1gemmk9+TrQNoHH2M7BJE6F3e+Wo urkXIjRnvFls+XWDDgZhke5c/8FihP1JLmtv/bb9pxqbj+8unBmJsM3WY E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D5AQAoiTlW/4ENJK1egzuBSL1BAQ2BXYYTAhyBIDgUAQEBAQEBAYEKhDYBAQQjEUUQAgEIDgwCJgICAjAVEAIEAQ0NiCawXpB/AQEBAQEBAQEBAQEBAQEBAQEBAQEBGIEChVOEfoRCgzOBQwEElkYBjRqcRQEfAQFChASEXAU+gQcBAQE X-IronPort-AV: E=Sophos;i="5.20,241,1444694400"; d="scan'208";a="41843102" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-8.cisco.com with ESMTP; 04 Nov 2015 04:32:59 +0000 Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id tA44Wxiv002605 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 Nov 2015 04:32:59 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 3 Nov 2015 22:32:58 -0600 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; Tue, 3 Nov 2015 22:32:59 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Andrew Mortensen , Gilbert Clark Thread-Topic: [Dots] [tsvwg] Best transport selection during an attack? Thread-Index: AQHRFonkqXl3p0h6iU67WsajDuI4Lp6LWM2A///m3KA= Date: Wed, 4 Nov 2015 04:32:58 +0000 Message-ID: <49d27818011843fcb79d6a2faca09b5f@XCH-RCD-017.cisco.com> References: <5638D31B.4080801@mti-systems.com> <0A836E5A-C801-4CF4-916C-41EA065D3D30@arbor.net> <563939F2.8010601@mti-systems.com> <3AFD973D-22CB-49BD-A384-A1C10A0167E9@arbor.net> In-Reply-To: <3AFD973D-22CB-49BD-A384-A1C10A0167E9@arbor.net> 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.42.239] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "dots@ietf.org" Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 04 Nov 2015 04:33:01 -0000 QWxsIGRyYWZ0LXJlZGR5LWRvdHMtdHJhbnNwb3J0LTAxIGFjdHVhbGx5IHNheXMgd2l0aCByZXNw ZWN0IHRvIHByb3RvY29sIGlzIHRoZSBmb2xsb3dpbmc6ICJUQkQ6IFNPUyBtZXNzYWdlcyBTSE9V TEQgYmUgZXhjaGFuZ2VkIG92ZXIgRFRMUyBvdmVyIFVEUC7igJ0NCg0KQ29tcGFyZSB3aXRoIE9Q LTAwMSBmcm9tIGRyYWZ0LWlldGYtZG90cy1yZXF1aXJlbWVudHMtMDA6DQoNCiJXaGlsZSB0aGUg cHJvdG9jb2wgcmVzaWxpZW5jZSByZXF1aXJlbWVudCBzdHJvbmdseSBSRUNPTU1FTkRTIHRoZSB1 c2Ugb2YgY29ubmVjdGlvbmxlc3MgcHJvdG9jb2wsIGluIHBhcnRpY3VsYXIgdGhlIFVzZXIgRGF0 YWdyYW0gUHJvdG9jb2wgKFVEUCksIHVzZSBvZiBhIHN0YW5kYXJkaXplZCwgY29ubmVjdGlvbi1v cmllbnRlZCBwcm90b2NvbCBsaWtlIHRoZSBUcmFuc21pc3Npb24gQ29udHJvbCBQcm90b2NvbCAo VENQKSBNQVkgYmUgbmVjZXNzYXJ5IGR1ZSB0byBuZXR3b3JrIHBvbGljeSBvciBtaWRkbGV3YXJl IGxpbWl0YXRpb25zLiINCg0KW1RSXSBET1RTIGNsaWVudCBjYW4gcG9zc2libHkgdXNlICJIYXBw eSBFeWViYWxsIG1lY2hhbmlzbSIgdG8gdHJ5IGJvdGggVURQIGFuZCBUQ1AuIElmIFVEUCBpcyBu b3QgYmxvY2tlZCB0aGVuIGl0IHdpbGwgcmVjZWl2ZSByZXNwb25zZSBmcm9tIHRoZSBET1RTIHNl cnZlciBhbmQgY2FuIHRlcm1pbmF0ZSB0aGUgVENQIGNvbm5lY3Rpb24uIFRDUCBjb3VsZCBiZSBz dWJqZWN0ZWQgdG8gUlNUIGF0dGFja3MgYW5kIHRoZSBhZGRpdGlvbmFsIG92ZXJoZWFkIG9mIFRD UC1BTyBpcyByZXF1aXJlZC4NCg0KLVRpcnUNCg0KYW5kcmV3DQo= From nobody Tue Nov 3 20:39: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 0DE0B1AC3A5 for ; Tue, 3 Nov 2015 20:39:35 -0800 (PST) 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 C1KIAbo3eA-7 for ; Tue, 3 Nov 2015 20:39:33 -0800 (PST) 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 895BF1AC39A for ; Tue, 3 Nov 2015 20:39:33 -0800 (PST) Received: by pabfh17 with SMTP id fh17so40263249pab.0 for ; Tue, 03 Nov 2015 20:39:33 -0800 (PST) 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=ors0ieHJsrr5msv6MeCPQ0sEguXFATU2XLGUiuZwPYo=; b=ftv1JAaDCvU7CUK8tC34My2m5Y3Uao36qUwYrAN2q4JoAkclSks+itlJLBvL5ckFuh Ol2VtQkbnN+s7+TrrTAviB+DnFELc+dKGbpbirzwxispgu8ZRwEiysm9ABFbfdhsj5vS WtHhDXkgkr0dYzF5eR4ImExYefdEqoA+HB3bU= 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=ors0ieHJsrr5msv6MeCPQ0sEguXFATU2XLGUiuZwPYo=; b=lWJ6d3Me43J8Oee9RDbuRpkKQUKRdxv0xCOUG9M93BRxQ/aNhFCrjGGZTzOfswHnfs xYutJ2X7tP+bpjqMzj7i/Y0gWyLIdG7HivQgtAYxQ1MRPwk0cYj3Ja4zqDvL6ktR972t 8eHLIAkrVIaiIg0dHcL022MQ482Siw1HCHGcM9ELXbZGDkFNfE08AvJKw3dHAlq8o4OM Z87OMCiAcMiUQvkpFoGEu8ovJdDSWdHIVk+XgYUMPXltHKDoJsF33uwkBjYmc7bDfJaM sCayOAaQzE23pn+Fk0MWcmpWDhwQHe4YlaBGlr+Hnlg4ANxZ5V3LNoKOtICjPk4cS/8+ +GrQ== X-Gm-Message-State: ALoCoQnRnlIMfmtJgAxCyxwkbzT+aTmDM6SGNu8t1e1Cl6N+7cCfyiw7hN6b79xVyEWe6siZLSDj X-Received: by 10.66.155.5 with SMTP id vs5mr38133998pab.108.1446611973184; Tue, 03 Nov 2015 20:39:33 -0800 (PST) Received: from [10.0.1.3] (p5231-ipngn5001hodogaya.kanagawa.ocn.ne.jp. [153.220.164.231]) by smtp.gmail.com with ESMTPSA id yp9sm32542953pab.1.2015.11.03.20.39.32 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 03 Nov 2015 20:39:32 -0800 (PST) From: "Roland Dobbins" To: "dots@ietf.org" Date: Wed, 04 Nov 2015 13:39:30 +0900 Message-ID: <6709EB29-B856-45EC-A005-4AB4274C6B1D@arbor.net> In-Reply-To: <49d27818011843fcb79d6a2faca09b5f@XCH-RCD-017.cisco.com> References: <5638D31B.4080801@mti-systems.com> <0A836E5A-C801-4CF4-916C-41EA065D3D30@arbor.net> <563939F2.8010601@mti-systems.com> <3AFD973D-22CB-49BD-A384-A1C10A0167E9@arbor.net> <49d27818011843fcb79d6a2faca09b5f@XCH-RCD-017.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5164) Archived-At: Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 04 Nov 2015 04:39:35 -0000 On 4 Nov 2015, at 13:32, Tirumaleswar Reddy (tireddy) wrote: > [TR] DOTS client can possibly use "Happy Eyeball mechanism" to try > both UDP and TCP. If UDP is not blocked then it will receive response > from the DOTS server and can terminate the TCP connection. Some type of fallback/alternate transport selection mechanism is definitely in order, IMHO. There's also the question of fallback/selection between IPv4 and IPv6, in scenarios where both are available to the DOTS agents in question. ----------------------------------- Roland Dobbins From nobody Tue Nov 3 20:56: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 499121AC449 for ; Tue, 3 Nov 2015 20:56:38 -0800 (PST) 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 AssmyrndSdWV for ; Tue, 3 Nov 2015 20:56:34 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91DEC1AC442 for ; Tue, 3 Nov 2015 20:56:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1552; q=dns/txt; s=iport; t=1446612994; x=1447822594; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=eS3eBYRGWDJsGR1HzW68DeWLGZJJPDnKeSAqaE+WjGE=; b=mHPKwbSO/C7A1AEHATjsg8gknczUGQ5OJkeijcoMfN4gV8MGu7M/YNc+ bZFGAYz0vbXSIZ+FWBuueBP5h47EyMy//wmusJu5iFJLjsoJp9+5W1AqO vBBdnkndDxW9Q0ObCPUQy+AoSojhpWS45Mfr4JKAuMvpxr0mw9SZedDcU M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D6AQCpjzlW/5pdJa1egztTbwa9QQENgV0XCoVyAoE8OBQBAQEBAQEBgQqENQEBAQMBAQEBNzQXBAIBCA4DBAEBAR4JBycLFAkIAgQBEgiIHggNwUkBAQEBAQEBAQEBAQEBAQEBAQEBAQEUBIZVhH6EQoR2BYdEjwIBhRyHfpxFAR8BAUKEBHKELYEHAQEB X-IronPort-AV: E=Sophos;i="5.20,241,1444694400"; d="scan'208";a="204823196" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-8.cisco.com with ESMTP; 04 Nov 2015 04:56:29 +0000 Received: from XCH-RCD-017.cisco.com (xch-rcd-017.cisco.com [173.37.102.27]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id tA44uT6H016546 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 Nov 2015 04:56:29 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-RCD-017.cisco.com (173.37.102.27) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 3 Nov 2015 22:56:29 -0600 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; Tue, 3 Nov 2015 22:56:29 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Roland Dobbins , dots Thread-Topic: [Dots] Using Diameter transport for DOTS? Thread-Index: AdEWb+LjKy2VsZZAT7KTysuTEiK/GQAbbfaAAAvQTcD//7H/AIAAYo2A//+mTgCAAGGwIA== Date: Wed, 4 Nov 2015 04:56:29 +0000 Message-ID: <6e3c5f617a7844b9801904edf3c13fe3@XCH-RCD-017.cisco.com> References: <20151103194312.594948115.52080.45702@sandvine.com> <56397209.1070404@cisco.com> <5730f98c87df41179715cdff49503c86@XCH-RCD-017.cisco.com> <2880D1B0-BE00-4B87-9763-AA55B024F286@arbor.net> <83efd6bb305348aea6145f4b94629d3d@XCH-RCD-017.cisco.com> <12018EDA-A9E6-48DA-AC9A-F6E87C9D19B3@arbor.net> In-Reply-To: <12018EDA-A9E6-48DA-AC9A-F6E87C9D19B3@arbor.net> 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.42.239] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Using Diameter transport for DOTS? 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, 04 Nov 2015 04:56:38 -0000 > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Roland Dobbins > Sent: Wednesday, November 04, 2015 9:49 AM > To: dots > Subject: Re: [Dots] Using Diameter transport for DOTS? >=20 > On 4 Nov 2015, at 13:02, Tirumaleswar Reddy (tireddy) wrote: >=20 > > DOTS client and server must perform mutual authentication, and if > > authentication is to happen during an attack then it involves multiple > > messages back and forth. >=20 > Not necessarily: >=20 > The above draft is using DH and it involves multiple round-trips. Further D= H can subjected to MIM attacks and has dependency on=20 https://tools.ietf.org/html/draft-ietf-lisp-sec-09 which uses OTK for data = origin authentication. OTK generation is not standardized in the LISP secur= ity draft and is a pre-provisioning step (it may also involve multiple roun= d-trips).=20 >=20 > > With TLS 1.3, pre-attack provisioning helps to send only one encrypted > > and integrity protected 'Mitigation service request' message. >=20 > True, in the context of TLS 1.3. Yes, TLS 1.3 is more likely to get standardized before DOTS protocol. >=20 > > Any suggestions for alternate names ? >=20 > 'Mitigation service request'. -Tiru >=20 > ;> >=20 > ----------------------------------- > Roland Dobbins >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Tue Nov 3 21:01: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 5C88C1ACCE9 for ; Tue, 3 Nov 2015 21:01:06 -0800 (PST) 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 Y8tamoMDUGMN for ; Tue, 3 Nov 2015 21:01:05 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFDA01ACCE3 for ; Tue, 3 Nov 2015 21:01:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1157; q=dns/txt; s=iport; t=1446613264; x=1447822864; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=moIONA4v4Y3CrkRfiISeOc4pjtzdOiQXbtKHk3/nJXs=; b=AUQIQ/4qbTsPx+HssKAeusAuLHvWH6LrboB67LdmeLtvKfmjk+Zbhh7l VLm67WvuQemXuJvbDdeeBJ3Pi+cIFBTD5/Qk2A65DnWMlYrUFi+kxrsgC e7IWj1dDJXZ2w5X5EnNuLays50gzT1f4qz4+szyLS02qGPSpwtYMXys0L A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D6AQDHjzlW/5xdJa1egztTbwa9QQENgV0XCoVyAoE8OBQBAQEBAQEBgQqENQEBAQQBAQE3NBcEAgEIDgMEAQEBHgkHJwsUCQgCBAESCIgmDcFKAQEBAQEBAQEBAQEBAQEBAQEBAQEBFASGVYR+hEKEdgWHRI8CAYUcgnCFDpxFAR8BAUKEBHKDagU+gQcBAQE X-IronPort-AV: E=Sophos;i="5.20,241,1444694400"; d="scan'208";a="204672590" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-6.cisco.com with ESMTP; 04 Nov 2015 05:01:04 +0000 Received: from XCH-RCD-017.cisco.com (xch-rcd-017.cisco.com [173.37.102.27]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id tA4514qM023811 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 Nov 2015 05:01:04 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-RCD-017.cisco.com (173.37.102.27) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 3 Nov 2015 23:01:03 -0600 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; Tue, 3 Nov 2015 23:01:03 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Roland Dobbins , "dots@ietf.org" Thread-Topic: [Dots] [tsvwg] Best transport selection during an attack? Thread-Index: AQHRFonkqXl3p0h6iU67WsajDuI4Lp6LWM2A///m3KCAAG1uAP//oP0g Date: Wed, 4 Nov 2015 05:01:03 +0000 Message-ID: <0c1ea5caef5542178d1c954bf8afa96b@XCH-RCD-017.cisco.com> References: <5638D31B.4080801@mti-systems.com> <0A836E5A-C801-4CF4-916C-41EA065D3D30@arbor.net> <563939F2.8010601@mti-systems.com> <3AFD973D-22CB-49BD-A384-A1C10A0167E9@arbor.net> <49d27818011843fcb79d6a2faca09b5f@XCH-RCD-017.cisco.com> <6709EB29-B856-45EC-A005-4AB4274C6B1D@arbor.net> In-Reply-To: <6709EB29-B856-45EC-A005-4AB4274C6B1D@arbor.net> 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.42.239] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 04 Nov 2015 05:01:06 -0000 > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Roland Dobbins > Sent: Wednesday, November 04, 2015 10:10 AM > To: dots@ietf.org > Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? >=20 > On 4 Nov 2015, at 13:32, Tirumaleswar Reddy (tireddy) wrote: >=20 > > [TR] DOTS client can possibly use "Happy Eyeball mechanism" to try > > both UDP and TCP. If UDP is not blocked then it will receive response > > from the DOTS server and can terminate the TCP connection. >=20 > Some type of fallback/alternate transport selection mechanism is definite= ly in > order, IMHO. >=20 > There's also the question of fallback/selection between IPv4 and IPv6, in > scenarios where both are available to the DOTS agents in question. Browsers already use "Happy Eyeball mechanism" https://tools.ietf.org/html/= rfc6555 for selection between IPv6 and IPv4.=20 -Tiru >=20 > ----------------------------------- > Roland Dobbins >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Tue Nov 3 21:06:34 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 A796B1ACCE7 for ; Tue, 3 Nov 2015 21:06:33 -0800 (PST) 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 I5cbXNDqNwRP for ; Tue, 3 Nov 2015 21:06:32 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A3AD1ACC87 for ; Tue, 3 Nov 2015 21:06:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1212; q=dns/txt; s=iport; t=1446613592; x=1447823192; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=O8rO1MrVecxMrOxWajIdoGPmvX/0KVAdjfGTwURQBqI=; b=kxsOnxBxow0OB7PDpBZoYacnZPrfPcRZXoCQhozvNmOhyjtvotXCrQIO cVCh4FEULTLbjYRl1EWHZcvgPRAb4VfQlYPzJMmkMGDkQzs52Bzbbg8J6 c1EPxnbI5IQ9FH3Ug+6bbihG9hvg6aFEwtgt5CGWt3wzzx8bU7URIZg7d k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D6AQDakTlW/4kNJK1egztTbwa9QQENgV0XCoVyAoE8OBQBAQEBAQEBgQqENQEBAQQBAQE3NBcGAQgOAwQBAQEeCS4LFAkJAQQBEgiIJg3BSwEBAQEBAQEBAgEBAQEBAQEBARYEhlWEfoRChHYFh0SPAgGFHIJwhQ6cRQEfAQFChARyg2oFPoEHAQEB X-IronPort-AV: E=Sophos;i="5.20,241,1444694400"; d="scan'208";a="41614318" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-9.cisco.com with ESMTP; 04 Nov 2015 05:06:31 +0000 Received: from XCH-RCD-018.cisco.com (xch-rcd-018.cisco.com [173.37.102.28]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id tA456Vb6019550 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 Nov 2015 05:06:31 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-RCD-018.cisco.com (173.37.102.28) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 3 Nov 2015 23:06:30 -0600 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; Tue, 3 Nov 2015 23:06:31 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Roland Dobbins , "dots@ietf.org" Thread-Topic: [Dots] [tsvwg] Best transport selection during an attack? Thread-Index: AdEWvoiqKz/BWRlqQYCinq19I9IMJA== Date: Wed, 4 Nov 2015 05:06:31 +0000 Message-ID: <0e67fdf3895c476f87ad29977bf57d22@XCH-RCD-017.cisco.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.42.239] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 04 Nov 2015 05:06:33 -0000 > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Roland Dobbins > Sent: Wednesday, November 04, 2015 10:10 AM > To: dots@ietf.org > Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? >=20 > On 4 Nov 2015, at 13:32, Tirumaleswar Reddy (tireddy) wrote: >=20 > > [TR] DOTS client can possibly use "Happy Eyeball mechanism" to try > > both UDP and TCP. If UDP is not blocked then it will receive response > > from the DOTS server and can terminate the TCP connection. >=20 > Some type of fallback/alternate transport selection mechanism is definite= ly in > order, IMHO. >=20 > There's also the question of fallback/selection between IPv4 and IPv6, in > scenarios where both are available to the DOTS agents in question. Browsers already use "Happy Eyeball mechanism" https://tools.ietf.org/html/= rfc6555 for selection between IPv6 and IPv4, DOTS signaling protocol can us= e the same mechanism.=20 -Tiru >=20 > ----------------------------------- > Roland Dobbins >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Tue Nov 3 21:08: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 7AADD1ACCFB for ; Tue, 3 Nov 2015 21:08:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 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, 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 WzQF7K1eeffg for ; Tue, 3 Nov 2015 21:08:03 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id D50F21ACCF8 for ; Tue, 3 Nov 2015 21:08:03 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id EB74C4334C2; Wed, 4 Nov 2015 05:08:02 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id D4E29433409; Wed, 4 Nov 2015 05:08:02 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1446613682; bh=sL6Pz/8rOoIAZiCfrs7zjMmhwovq0KKDVkIjtQ3ML44=; l=93; h=From:To:Date:References:In-Reply-To:From; b=GUVRrrqWxDrMY2T9o01y7LxJLGovrVy31qPLjDDUTxnMpYZeL6/8bW/Q1lWHq+eP2 +NOZQqYGvhxEUn/n9B7q8mD2Ioi2ejtRlT1ikjG6pL3ieUFin2DRxe1VF0IyBvCD6i NgScODFM8XVIdlPl3k4nZJnBqvEwgcT0qGPUIq7o= Received: from email.msg.corp.akamai.com (usma1ex-casadmn.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id D1397202E; Wed, 4 Nov 2015 05:08:02 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 4 Nov 2015 00:08:02 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1076.000; Wed, 4 Nov 2015 00:08:02 -0500 From: "Salz, Rich" To: Roland Dobbins , dots Thread-Topic: [Dots] Using Diameter transport for DOTS? Thread-Index: AdEWb+LjKy2VsZZAT7KTysuTEiK/GQAZVYSAAAEgMYAAAPAOAAAAgq+AAACYvQAACMo+AA== Date: Wed, 4 Nov 2015 05:08:01 +0000 Message-ID: <537ba1237010465d85d07b3fbbe07af8@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20151103194312.594948115.52080.45702@sandvine.com> <56397209.1070404@cisco.com> <5730f98c87df41179715cdff49503c86@XCH-RCD-017.cisco.com> <2880D1B0-BE00-4B87-9763-AA55B024F286@arbor.net> <83efd6bb305348aea6145f4b94629d3d@XCH-RCD-017.cisco.com> <12018EDA-A9E6-48DA-AC9A-F6E87C9D19B3@arbor.net> In-Reply-To: <12018EDA-A9E6-48DA-AC9A-F6E87C9D19B3@arbor.net> 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: [172.19.237.33] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Using Diameter transport for DOTS? 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, 04 Nov 2015 05:08:05 -0000 > Pure DH and not X25519? Eww. From nobody Tue Nov 3 21:32:02 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 5D9C11ACD65 for ; Tue, 3 Nov 2015 21:32:00 -0800 (PST) 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 co2n9IpkjmnE for ; Tue, 3 Nov 2015 21:31:58 -0800 (PST) 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 8666D1ACD60 for ; Tue, 3 Nov 2015 21:31:58 -0800 (PST) Received: by padhx2 with SMTP id hx2so33702197pad.1 for ; Tue, 03 Nov 2015 21:31:58 -0800 (PST) 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=BhbA4DVqPzHxT7nT/OZzVLWytfnIwiM/EyU0P3W5yuw=; b=lhUvnIFNrBax9xZxCYSMdIUk84EeBjSNJYZfVpoChR0HofQIDIf9st09YcOlQVewSw NN0tuf8ifzP9H2ZZizKkZUcNiyELO2L+GeZCRj1DVzZqFrOruLWvrKhgGEAoMFPTrChH 5dILlyQ+ssaUKYWwfbXX2Tq2vUlssMV5FePg4= 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=BhbA4DVqPzHxT7nT/OZzVLWytfnIwiM/EyU0P3W5yuw=; b=TJ8UxTV++guMqrN5HanI6PtjZP1qohxgF42me0lI+Z4rzQ1mgZjzJ1hfNvXKOxi6j6 NU3An6uaQ9jeuEN9k8kh2HSFp/eoB4sHeQW8FSxRjYdtlGawTzmc7mnMw9BXW84MjeQs Z5z3kYf7SHInIVD3QqmNRzKa2cFDb3vmdcOlkkt+LIRk5ycTA3EhGwiyjcbwBL7fkNAA naqEMzdEbLLzkdrd0+KMy13osO8SytwxoX1d9VF+LxJie2N1JnuDqKFYCwgj7SkbO4dd e/Q+06rplUvDIy1N2S2gQW4rPrFlbjteVMa06JHLrkMGt4nm+fyyMhyF5dfUqN0yVzkO 6wnA== X-Gm-Message-State: ALoCoQnchnWYfdjv4lf+1VwHJ8Ecl9RiSxmggK9SLoagpmuABbR6yk3+jKl70FbWzJttdmMgwrmS X-Received: by 10.68.139.2 with SMTP id qu2mr38547857pbb.135.1446615118096; Tue, 03 Nov 2015 21:31:58 -0800 (PST) Received: from [10.0.1.3] (p5231-ipngn5001hodogaya.kanagawa.ocn.ne.jp. [153.220.164.231]) by smtp.gmail.com with ESMTPSA id y16sm30106849pbt.88.2015.11.03.21.31.56 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 03 Nov 2015 21:31:56 -0800 (PST) From: "Roland Dobbins" To: dots Date: Wed, 04 Nov 2015 14:31:49 +0900 Message-ID: In-Reply-To: <6e3c5f617a7844b9801904edf3c13fe3@XCH-RCD-017.cisco.com> References: <20151103194312.594948115.52080.45702@sandvine.com> <56397209.1070404@cisco.com> <5730f98c87df41179715cdff49503c86@XCH-RCD-017.cisco.com> <2880D1B0-BE00-4B87-9763-AA55B024F286@arbor.net> <83efd6bb305348aea6145f4b94629d3d@XCH-RCD-017.cisco.com> <12018EDA-A9E6-48DA-AC9A-F6E87C9D19B3@arbor.net> <6e3c5f617a7844b9801904edf3c13fe3@XCH-RCD-017.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5164) Archived-At: Subject: Re: [Dots] Using Diameter transport for DOTS? 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, 04 Nov 2015 05:32:00 -0000 On 4 Nov 2015, at 13:56, Tirumaleswar Reddy (tireddy) wrote: > The above draft is using DH and it involves multiple round-trips. Interesting, given the following from (I mistakenly cited -01, apologies; same language in both): 'The budget for key exchange MUST be one round-trip time. That is, only a two packet exchange can occur.' > Further DH can subjected to MIM attacks I don't think those MITM scenarios really apply here (correction welcome if I'm wrong), given the high level of attention paid to this occasional task. This isn't a general-purpose information channel, and it's expected to remain relatively static in terms of participating nodes. > and has dependency on > https://tools.ietf.org/html/draft-ietf-lisp-sec-09 which uses OTK for > data origin authentication. OTK generation is not standardized in the > LISP security draft and is a pre-provisioning step (it may also > involve multiple round-trips). OK. I didn't get that it was multiple round-trips, but again am happy to be educated. > Yes, TLS 1.3 is more likely to get standardized before DOTS protocol. Concur. ----------------------------------- Roland Dobbins From nobody Tue Nov 3 21:33: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 73EB11ACD81 for ; Tue, 3 Nov 2015 21:33:41 -0800 (PST) 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 Y_QnlFdW7W8m for ; Tue, 3 Nov 2015 21:33:40 -0800 (PST) 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 1A6441ACD6E for ; Tue, 3 Nov 2015 21:33:40 -0800 (PST) Received: by pabfh17 with SMTP id fh17so41731522pab.0 for ; Tue, 03 Nov 2015 21:33:39 -0800 (PST) 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=0tWmpIBy2Lyd1Y38I+EIe2yERGQBGLgc7Q5/4wfuTgI=; b=js2ZmQs5/9Ggq2AyO4GK8aGiUoZ4QMIzEpcR1XYysIsYnV77ODgJdrfgg8Cl8VWhXM JzGEbTXrOx1JwkNV1l6srfqNSxjv2dyZwyJCBbs5M0ztlNep9gitMa7wQ6LOhAo3hkR9 TdIzRYRoCA+ofcw1UVXjGhKpPrcUQ/uTbh/JI= 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=0tWmpIBy2Lyd1Y38I+EIe2yERGQBGLgc7Q5/4wfuTgI=; b=LnDy9a28Lo7TAis9LF2cfP8WGUe8IGbaiV1TEE3FUOhdjD6aX8BIqkzOBl3uUDk0pX Hrt2Zitm4GMxTn2650jsG/JEHQgrQDzJuWtmRG9We92IAVS+o/MrW22HyxF+XN2TQ5Hw s0Ibqhlo7vCxYOKvfBm4bwzdjsprQz81YZ/q6KH3imBNkS8A/1uNLmuVUuPKKeSRO17R FRGEvhY8BwDw2EehFp+Harb8CC9DU7N5a9N9fKC50gNdT+MUR9IeqPkbC/Pw5iZu6XO0 eEurNaYcU0NSBzeUosBKdQ1lRobh7D8Ts1WhIInu1rlGXZLRL3OW3I0IJXTWDjhcMjyK iRSw== X-Gm-Message-State: ALoCoQlalHCulDbMD2HE70zZowwZPoUeLDxziKI7JHGGcMFw4JcpHMftxnvfrmruvwUbD+WUWnsU X-Received: by 10.68.87.161 with SMTP id az1mr38451233pbb.57.1446615219726; Tue, 03 Nov 2015 21:33:39 -0800 (PST) Received: from [10.0.1.3] (p5231-ipngn5001hodogaya.kanagawa.ocn.ne.jp. [153.220.164.231]) by smtp.gmail.com with ESMTPSA id lo9sm32837057pab.19.2015.11.03.21.33.38 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 03 Nov 2015 21:33:39 -0800 (PST) From: "Roland Dobbins" To: "dots@ietf.org" Date: Wed, 04 Nov 2015 14:33:36 +0900 Message-ID: <4FE28A47-A65E-4FE8-AA0B-FEA3712D061C@arbor.net> In-Reply-To: <0c1ea5caef5542178d1c954bf8afa96b@XCH-RCD-017.cisco.com> References: <5638D31B.4080801@mti-systems.com> <0A836E5A-C801-4CF4-916C-41EA065D3D30@arbor.net> <563939F2.8010601@mti-systems.com> <3AFD973D-22CB-49BD-A384-A1C10A0167E9@arbor.net> <49d27818011843fcb79d6a2faca09b5f@XCH-RCD-017.cisco.com> <6709EB29-B856-45EC-A005-4AB4274C6B1D@arbor.net> <0c1ea5caef5542178d1c954bf8afa96b@XCH-RCD-017.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5164) Archived-At: Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 04 Nov 2015 05:33:41 -0000 On 4 Nov 2015, at 14:01, Tirumaleswar Reddy (tireddy) wrote: > Browsers already use "Happy Eyeball mechanism" > https://tools.ietf.org/html/rfc6555 for selection between IPv6 and > IPv4. Yes, I agree that Happy Eyeballs is something to consider for this. Dan Wing is on this list, too. ----------------------------------- Roland Dobbins From nobody Tue Nov 3 21:41: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 01F9E1ACDC5 for ; Tue, 3 Nov 2015 21:41:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 O57-07XEbujC for ; Tue, 3 Nov 2015 21:41:18 -0800 (PST) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) by ietfa.amsl.com (Postfix) with ESMTP id 2C54E1ACDC3 for ; Tue, 3 Nov 2015 21:41:18 -0800 (PST) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([::1]) with mapi id 14.03.0195.001; Wed, 4 Nov 2015 00:41:19 -0500 From: Dave Dolson To: Paul Ferguson , Flemming Andreasen Thread-Topic: [Dots] Using Diameter transport for DOTS? Thread-Index: AdEWb+LjKy2VsZZAT7KTysuTEiK/GQAZVYSAAABO1AD//9nzBw== Date: Wed, 4 Nov 2015 05:41:18 +0000 Message-ID: <20151104054115.594948115.42583.45842@sandvine.com> References: <20151103194312.594948115.52080.45702@sandvine.com> <56397209.1070404@cisco.com>,<5639741A.80408@mykolab.com> In-Reply-To: <5639741A.80408@mykolab.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: dots Subject: Re: [Dots] Using Diameter transport for DOTS? 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, 04 Nov 2015 05:41:20 -0000 It might be overkill, but off the top of my head, Diameter provides: - a rich dictionary-driven, =FDbinary packet format comprised of attribute-= value pairs, allowing structs, lists, etc., and is vendor-extensible - peer connectivity maintenance, with watchdog messages - =FDprimary/secondary peer fail-over - message routing by peer name - retransmission semantics It might be most appropriate to borrow some of the paradigms. =FDOther session protocols? SNMP, using a trap for the SOS?? I'm just throwing out ideas because inventing a new protocol from scratch i= s fun, but will take longer as the interesting corner cases are discovered. Original Message From: Paul Ferguson Sent: Wednesday, November 4, 2015 11:57 AM To: Flemming Andreasen Cc: Dave Dolson; dots Subject: Re: [Dots] Using Diameter transport for DOTS? -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 May I also underscore this sentiment: > TLS/DTLS satisfy a lot of what you list below, and I'm not sure we > need something as elaborate as DIAMETER on top of that. This is a statement I also endorse, and would like to understand better what DIAMETER would actually add to the equation. - - ferg On 11/3/2015 6:48 PM, Flemming Andreasen wrote: > We obvioulsy should do a proper evaluation against the requirements > once we have vetted those a bit more, but my initial reaction is > that this seems like a fairly heavy-handed approach to the problem > at hand (we do need to understand the requirements on DOTS relays > better though). TLS/DTLS satisfy a lot of what you list below, and > I'm not sure we need something as elaborate as DIAMETER on top of > that. Also, please keep in mind that we have use case scenarios > involving endpoints, and requiring those to support DIAMETER for a > basic client-side app or web portal seems like a tall order to me. > > On a related note, it's been a while since I looked at DIAMETER, > but what is the adoption/deployment status of that outside of 3GPP > these days ? > > Thanks > > -- Flemming > > > > > On 11/3/15 2:43 PM, Dave Dolson wrote: >> Could Diameter satisfy the transport protocol needs of DOTS? It >> already has security, mutual authentication, both datagram >> (SCTP) and TCP transports=FD, watchdog timers, redundancy, the >> concept of relays... >> >> -Dave >> >> _______________________________________________ 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 - -- 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 iF4EAREIAAYFAlY5dBoACgkQKJasdVTchbLhWAD/VxzQ61gKGVRXOLtbBT7UFb5r CnGsU8gf8xCSgY2zKyUBAIkZhS3Uo/njhx1xChcRVDGdqzpsPGqCJ8Ey7HaNuCpa =3Dl3ib -----END PGP SIGNATURE----- From nobody Tue Nov 3 22:03: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 BC4D61ACE28 for ; Tue, 3 Nov 2015 22:03:24 -0800 (PST) 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 SydtU8M1VNsw for ; Tue, 3 Nov 2015 22:03:23 -0800 (PST) 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 ABADA1ACE25 for ; Tue, 3 Nov 2015 22:03:23 -0800 (PST) Received: by pabfh17 with SMTP id fh17so42547529pab.0 for ; Tue, 03 Nov 2015 22:03:23 -0800 (PST) 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=LcrDZVGXnazC22rqmaL0t55PdwdWBny/PHe+B6D6O9s=; b=GNW0MGOqKsTr14fLAQuHBCNTah1aRskoSAc8u5zjtjpOGBzaUFnXr82OHNsQuSWygM qnzlL2VEOEnnSjj7D9whPSJH8DWVxEkvTI1n7KihgJEpvcwOg+K89OxTlYsPqcdMNDbc nH9jOVabvPLN/OjKVAAmklB/8KNjnmWFCfUV0= 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=LcrDZVGXnazC22rqmaL0t55PdwdWBny/PHe+B6D6O9s=; b=f6CMSP9nwZemnr5UqgbBCk4LiEEdLIGRIL1alsqCsQqnl8e8NkmacF8tDEEpW5Z34S /HBl6U9GQfITlYpqvz540T+Wv5Stdz1qYQIiJdNchk6ICKEnNtRwJh/GWIlIprm2eOI/ /O1/MTpOFn+yDe+qgdm26i1yMmYx9wK1660rCKmfZlrfs18CL5yt/fF4hqOugckezYYs FHOnWLFxJEQStTMWoGTq/su57YMmAjTt4M8WcHLSd8pERGBwFlPPJqyi2YhVfpiZUm22 31dR9mqO6+gvKu11/MFQ86MNfOS3uVznj4xdRvDLGZViYE35Mwg3IY3pT6/sg3gjJD+4 LmWQ== X-Gm-Message-State: ALoCoQmfzmZPvW8E+pEZjjci47zpHgBVRxA6sxnx9czDBOK5mwKTshLa3oFtSSIcpw6k4LKWMDLY X-Received: by 10.66.124.161 with SMTP id mj1mr38375968pab.43.1446617003278; Tue, 03 Nov 2015 22:03:23 -0800 (PST) Received: from [10.0.1.3] (p5231-ipngn5001hodogaya.kanagawa.ocn.ne.jp. [153.220.164.231]) by smtp.gmail.com with ESMTPSA id kw10sm32944645pbc.25.2015.11.03.22.03.21 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 03 Nov 2015 22:03:21 -0800 (PST) From: "Roland Dobbins" To: dots Date: Wed, 04 Nov 2015 15:03:19 +0900 Message-ID: <22DE5166-2B69-40C2-B0A6-AF28A12FFAC3@arbor.net> In-Reply-To: <20151104054115.594948115.42583.45842@sandvine.com> References: <20151103194312.594948115.52080.45702@sandvine.com> <56397209.1070404@cisco.com> <5639741A.80408@mykolab.com> <20151104054115.594948115.42583.45842@sandvine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.3r5164) Archived-At: Subject: Re: [Dots] Using Diameter transport for DOTS? 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, 04 Nov 2015 06:03:24 -0000 On 4 Nov 2015, at 14:41, Dave Dolson wrote: > It might be most appropriate to borrow some of the paradigms. Yes, this makes more sense, IMHO. > ‎Other session protocols? SNMP, using a trap for the SOS?? No - heavily filtered at network edges. > I'm just throwing out ideas because inventing a new protocol from > scratch is fun, but will take longer as the interesting corner cases > are discovered. IPFIX is also something to consider *as a potential transport* (e.g., not the network telemetry export functionality). We definitely want to reuse existing standards wherever possible, when they're suitable to requirements. ----------------------------------- Roland Dobbins From nobody Tue Nov 3 22:05: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 0B4BA1ACE47 for ; Tue, 3 Nov 2015 22:05:54 -0800 (PST) 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 is0McTBZ8mfA for ; Tue, 3 Nov 2015 22:05:52 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53F3B1ACE46 for ; Tue, 3 Nov 2015 22:05:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2555; q=dns/txt; s=iport; t=1446617152; x=1447826752; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Kp3Ch8NWf3q6NHz6ie9DJfK05s9gj/uzvbyK4HGFq+g=; b=TPwOn9LFOAeBkoEv6fEp07LPYxq4h1Bt97+cZCdBkcoFf+gMRW63rUn0 /ZRYUMs7nkILp593n7uB8ksWM+Tkjk0gOZWfmFy1Tb6D41NwKkM8vAfg8 YNclxy5MIPMmCoooTdEjVLuDZRu7SeHliWzLmwfTasiummCn7NCxYW2JT k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D6AQDynjlW/5ldJa1egztTbwa9RQENgV0XCoVyAoE8OBQBAQEBAQEBgQqENQEBAQMBAQEBNzQXBAIBCA4DBAEBAR4JBycLFAkIAgQBEgiIHggNwUABAQEBAQEBAQEBAQEBAQEBAQEBAQEUBIZVhH6JOAWFTIF4jwIBhRyFToIwnEUBHwEBQoIRHYFWcgGELIEHAQEB X-IronPort-AV: E=Sophos;i="5.20,241,1444694400"; d="scan'208";a="204686544" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-6.cisco.com with ESMTP; 04 Nov 2015 06:05:51 +0000 Received: from XCH-RCD-017.cisco.com (xch-rcd-017.cisco.com [173.37.102.27]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id tA465p9s017278 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 Nov 2015 06:05:51 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-RCD-017.cisco.com (173.37.102.27) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 4 Nov 2015 00:05:51 -0600 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; Wed, 4 Nov 2015 00:05:51 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Roland Dobbins , dots Thread-Topic: [Dots] Using Diameter transport for DOTS? Thread-Index: AdEWb+LjKy2VsZZAT7KTysuTEiK/GQAbbfaAAAvQTcD//7H/AIAAYo2A//+mTgCAAGGwIP//soeAgABgFTA= Date: Wed, 4 Nov 2015 06:05:51 +0000 Message-ID: References: <20151103194312.594948115.52080.45702@sandvine.com> <56397209.1070404@cisco.com> <5730f98c87df41179715cdff49503c86@XCH-RCD-017.cisco.com> <2880D1B0-BE00-4B87-9763-AA55B024F286@arbor.net> <83efd6bb305348aea6145f4b94629d3d@XCH-RCD-017.cisco.com> <12018EDA-A9E6-48DA-AC9A-F6E87C9D19B3@arbor.net> <6e3c5f617a7844b9801904edf3c13fe3@XCH-RCD-017.cisco.com> In-Reply-To: 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.38.209] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Using Diameter transport for DOTS? 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, 04 Nov 2015 06:05:54 -0000 > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Roland Dobbins > Sent: Wednesday, November 04, 2015 11:02 AM > To: dots > Subject: Re: [Dots] Using Diameter transport for DOTS? >=20 > On 4 Nov 2015, at 13:56, Tirumaleswar Reddy (tireddy) wrote: >=20 > > The above draft is using DH and it involves multiple round-trips. >=20 > Interesting, given the following from > (I mistakenly cit= ed -01, > apologies; same language in both): >=20 > 'The budget for key exchange MUST be one round-trip time. That is, only = a > two packet exchange can occur.' I see three packet exchanges in https://tools.ietf.org/html/draft-ietf-lisp= -crypto-02#section-3 to setup DH. >=20 > > Further DH can subjected to MIM attacks >=20 > I don't think those MITM scenarios really apply here (correction welcome = if > I'm wrong), given the high level of attention paid to this occasional tas= k. This > isn't a general-purpose information channel, and it's expected to remain > relatively static in terms of participating nodes. MITM is an possible attack and I see it also discussed in https://tools.iet= f.org/html/draft-ietf-lisp-crypto-02#section-10.2 and to prevent MIM=20 it relies on https://tools.ietf.org/html/draft-ietf-lisp-sec-06. DH alone c= annot just be used to authenticate the DOTS agents. LISP security uses One-= Time Key for authentication, which again involves multiple round trips b/w = the ITR and ETR.=20 I don't understand what you mean by "static nodes" ? >=20 > > and has dependency on > > https://tools.ietf.org/html/draft-ietf-lisp-sec-09 which uses OTK for > > data origin authentication. OTK generation is not standardized in the > > LISP security draft and is a pre-provisioning step (it may also > > involve multiple round-trips). >=20 > OK. I didn't get that it was multiple round-trips, but again am happy to= be > educated. OTK b/w two peers typically involves multiple round-trips (connection setup= , mutual authentication b/w peers, signaling OTK and receiving acknowledgme= nt, periodic updates to OTK etc.).=20 -Tiru >=20 > > Yes, TLS 1.3 is more likely to get standardized before DOTS protocol. >=20 > Concur. I guess we should=20 -Tiru >=20 > ----------------------------------- > Roland Dobbins >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Tue Nov 3 22:17: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 990751ACE47 for ; Tue, 3 Nov 2015 22:17:27 -0800 (PST) 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 rk47_fsVKKft for ; Tue, 3 Nov 2015 22:17:25 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F63F1ACE87 for ; Tue, 3 Nov 2015 22:17:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1942; q=dns/txt; s=iport; t=1446617844; x=1447827444; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=aiDA6HRTN53D7rML6YEtMXInOhfrJj6QNrNxByzqKaw=; b=e5dDzoeEVuQk9fTDsrDkDqMmFE02ok6gDGUGF6wGXkGG+eCwZmxx6adt IUdaQMHb1bD7vc8PpP9otbdJAfkyHy+Jl9zb367zBacETOYx4La3sC4Qx vgPXHVHuyAeOWU5+5+2pWjEGNbiqf4N+97nyFvKW22B+6UqmaPT2cncZu k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D7AQCAojlW/4kNJK1egztTbwa9RQENgV0XCoVyAhyBIDgUAQEBAQEBAYEKhDUBAQEEAQEBIBE6FwQCAQgOAwQBAQECAiMDAgICJQsUAQgIAQEEARIIiCYNsDeRAgEBAQEBAQEBAQEBAQEBAQEBAQEBARQEgQKFU4R+hHGDBIFDBYdEjwIBhRyHfpxFAR8BAUKEBHKELYEHAQEB X-IronPort-AV: E=Sophos;i="5.20,241,1444694400"; d="scan'208";a="204840896" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-8.cisco.com with ESMTP; 04 Nov 2015 06:17:23 +0000 Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id tA46HNLD025560 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 Nov 2015 06:17:23 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 4 Nov 2015 00:17:23 -0600 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; Wed, 4 Nov 2015 00:17:23 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Roland Dobbins , dots Thread-Topic: [Dots] Using Diameter transport for DOTS? Thread-Index: AdEWb+LjKy2VsZZAT7KTysuTEiK/GQAbbfaAAABO0wAABbh9AAAAxNiAAAxxwIA= Date: Wed, 4 Nov 2015 06:17:23 +0000 Message-ID: <0d9b5f7b53f34f7b82a04290c21a9426@XCH-RCD-017.cisco.com> References: <20151103194312.594948115.52080.45702@sandvine.com> <56397209.1070404@cisco.com> <5639741A.80408@mykolab.com> <20151104054115.594948115.42583.45842@sandvine.com> <22DE5166-2B69-40C2-B0A6-AF28A12FFAC3@arbor.net> In-Reply-To: <22DE5166-2B69-40C2-B0A6-AF28A12FFAC3@arbor.net> 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.38.209] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Using Diameter transport for DOTS? 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, 04 Nov 2015 06:17:27 -0000 aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJlZGR5LWRvdHMtdHJhbnNwb3J0LTAx IGZvciBTT1MgKG9yICdNaXRpZ2F0aW9uIHNlcnZpY2UgcmVxdWVzdCkgdXNlcyBSRVNUIG92ZXIg KEQpVExTLiBJbiBzaW1pbGFyIGxpbmVzLCBJIHNlZSB0aGF0IENPQVAgZGVzaWduZWQgZm9yIGNv bnN0cmFpbmVkIG5vZGVzIGFuZCBjb25zdHJhaW5lZCBuZXR3b3JrcyBhbHNvIHVzZXMgUkVTVCAo d2l0aCBmZXcgbW9kaWZpY2F0aW9ucykgdG8gcnVuIG92ZXIgVURQLiANCg0KLVRpcnUNCg0KPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBEb3RzIFttYWlsdG86ZG90cy1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUm9sYW5kIERvYmJpbnMNCj4gU2VudDogV2VkbmVz ZGF5LCBOb3ZlbWJlciAwNCwgMjAxNSAxMTozMyBBTQ0KPiBUbzogZG90cw0KPiBTdWJqZWN0OiBS ZTogW0RvdHNdIFVzaW5nIERpYW1ldGVyIHRyYW5zcG9ydCBmb3IgRE9UUz8NCj4gDQo+IE9uIDQg Tm92IDIwMTUsIGF0IDE0OjQxLCBEYXZlIERvbHNvbiB3cm90ZToNCj4gDQo+ID4gSXQgbWlnaHQg YmUgbW9zdCBhcHByb3ByaWF0ZSB0byBib3Jyb3cgc29tZSBvZiB0aGUgcGFyYWRpZ21zLg0KPiAN Cj4gWWVzLCB0aGlzIG1ha2VzIG1vcmUgc2Vuc2UsIElNSE8uDQo+IA0KPiA+IOKAjk90aGVyIHNl c3Npb24gcHJvdG9jb2xzPyBTTk1QLCB1c2luZyBhIHRyYXAgZm9yIHRoZSBTT1M/Pw0KPiANCj4g Tm8gLSBoZWF2aWx5IGZpbHRlcmVkIGF0IG5ldHdvcmsgZWRnZXMuDQo+IA0KPiA+IEknbSBqdXN0 IHRocm93aW5nIG91dCBpZGVhcyBiZWNhdXNlIGludmVudGluZyBhIG5ldyBwcm90b2NvbCBmcm9t DQo+ID4gc2NyYXRjaCBpcyBmdW4sIGJ1dCB3aWxsIHRha2UgbG9uZ2VyIGFzIHRoZSBpbnRlcmVz dGluZyBjb3JuZXIgY2FzZXMNCj4gPiBhcmUgZGlzY292ZXJlZC4NCj4gDQo+IElQRklYIGlzIGFs c28gc29tZXRoaW5nIHRvIGNvbnNpZGVyICphcyBhIHBvdGVudGlhbCB0cmFuc3BvcnQqIChlLmcu LCBub3QgdGhlDQo+IG5ldHdvcmsgdGVsZW1ldHJ5IGV4cG9ydCBmdW5jdGlvbmFsaXR5KS4NCj4g DQo+IFdlIGRlZmluaXRlbHkgd2FudCB0byByZXVzZSBleGlzdGluZyBzdGFuZGFyZHMgd2hlcmV2 ZXIgcG9zc2libGUsIHdoZW4NCj4gdGhleSdyZSBzdWl0YWJsZSB0byByZXF1aXJlbWVudHMuDQo+ IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBSb2xhbmQgRG9iYmlu cyA8cmRvYmJpbnNAYXJib3IubmV0Pg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gRG90cyBtYWlsaW5nIGxpc3QNCj4gRG90c0BpZXRmLm9y Zw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHMNCg== From nobody Tue Nov 3 22:43: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 38CB11ACEBE for ; Tue, 3 Nov 2015 22:43:35 -0800 (PST) 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 SgpWgZX2Xa7K for ; Tue, 3 Nov 2015 22:43:33 -0800 (PST) Received: from mail-oi0-f100.google.com (mail-oi0-f100.google.com [209.85.218.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 901151ACEB3 for ; Tue, 3 Nov 2015 22:43:33 -0800 (PST) Received: by oige129 with SMTP id e129so2506154oig.2 for ; Tue, 03 Nov 2015 22:43:32 -0800 (PST) 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=ROJBRA2TyWImCOGnNQe3H0jrC8jbFtGUJ72kcgjsyX8=; b=S1kIguMdR8pCePdJ23nbyWxfZ7PUj4XEFEx34vURwWkP+qwon8rkdP0Two1ff2xpWE kfairusWUmNcBM9vgK7GfYOmqOLH1KvjtEDG9+nSCkb9XIBp58YYswvchwjcDCF7ZWvd HVxnp5lj9JYF+kmgiE9DZVVZlDr1ahiauAGC/xSlpZ2T2EHFJPWxDTc8rAu6+DIv3zt7 0ikfusU1/Fmj6kx/vKZAng/2YzZajjVp+2ZlpcKLCun959mVsP29JjDXODLoGcep52sf YoS2pmsBh6OYTVi7VwP+12kOWkUfFuc9kUc2k1jeEvcb0r6uPqMJqMSaIesbeJeqe7j4 NTVw== X-Gm-Message-State: ALoCoQlFnYmYx0DukkCYU5U/agqybpe9PgMWWIpYRImjzHOPxJ0+SLniBDpeHpoUGx5DIYHZhEYEkS8qBy42Lx4SoIP2F0jAfA== X-Received: by 10.55.78.143 with SMTP id c137mr42162862qkb.72.1446619412839; Tue, 03 Nov 2015 22:43:32 -0800 (PST) Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by smtp-relay.gmail.com with ESMTPS id d138sm2658166qkb.4.2015.11.03.22.43.32 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 03 Nov 2015 22:43:32 -0800 (PST) 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 tA46hWTH014137 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Nov 2015 01:43:32 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 4 Nov 2015 01:43:31 -0500 From: "Teague, Nik" To: Roland Dobbins , dots Thread-Topic: [Dots] Using Diameter transport for DOTS? Thread-Index: AdEWb+LjKy2VsZZAT7KTysuTEiK/GQAZVYSAAABO1AD//9nzB4AAWfeAgACiFIA= Date: Wed, 4 Nov 2015 06:43:31 +0000 Message-ID: References: <20151103194312.594948115.52080.45702@sandvine.com> <56397209.1070404@cisco.com> <5639741A.80408@mykolab.com> <20151104054115.594948115.42583.45842@sandvine.com> <22DE5166-2B69-40C2-B0A6-AF28A12FFAC3@arbor.net> In-Reply-To: <22DE5166-2B69-40C2-B0A6-AF28A12FFAC3@arbor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 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] Using Diameter transport for DOTS? 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, 04 Nov 2015 06:43:35 -0000 T24gMDQvMTEvMjAxNSAxNTowMywgIkRvdHMgb24gYmVoYWxmIG9mIFJvbGFuZCBEb2JiaW5zIg0K PGRvdHMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgcmRvYmJpbnNAYXJib3IubmV0PiB3 cm90ZToNCg0KPklQRklYIGlzIGFsc28gc29tZXRoaW5nIHRvIGNvbnNpZGVyICphcyBhIHBvdGVu dGlhbCB0cmFuc3BvcnQqIChlLmcuLA0KPm5vdCB0aGUgbmV0d29yayB0ZWxlbWV0cnkgZXhwb3J0 IGZ1bmN0aW9uYWxpdHkpLg0KDQpTb21lIG9mIHRoZSByZWFzb25zIEkgc3VnZ2VzdGVkIElQRklY IGFzIGEgc2lnbmFsaW5nIGJhc2UgaW4gdGhlIEJvRg0Kb3JpZ2luYWxseSBhbmQgcmVmbGVjdGVk IGluOg0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdGVhZ3VlLW9wZW4tdGhy ZWF0LXNpZ25hbGluZy0wMSAoYW5kIC0wMCkNCg0KDQpXZXJlOg0KDQoqIFRlbXBsYXRlIC0gdGhl IHNjaGVtYSBiZWluZyBzZXQgaW4gdGhlIHRlbXBsYXRlIGV4cG9ydCBsZW50IGl0c2VsZiB0bw0K ZWZmaWNpZW50IHVzZSBvZiB0aGUgZGF0YSBleHBvcnQgaW4gYWRkaXRpb24gdG8gYSBkZWdyZWUg b2YgZXh0ZW5zaWJpbGl0eQ0KZWl0aGVyIGJ5IGFkZGl0aW9uYWwgZmllbGRzIGJleW9uZCB0aG9z ZSByZXF1aXJlZCBvciB3aXRoIGFkZGl0aW9uYWwNCnRlbXBsYXRlL2RhdGEgc2V0IHBhaXJpbmdz Lg0KDQoqIE11dGxpIHRyYW5zcG9ydCBzdXBwb3J0IC0gSVBGSVggbWF5IHVzZSB1ZHAsIHNjdHAg b3IgdGNwLg0KDQoqIFRvb2xpbmcgLSBJUEZJWCBhbHJlYWR5IGV4aXN0cyBpbiBtYW55IGFwcGxp Y2F0aW9ucyBpbiB0aGlzIGZpZWxkDQoNCkRyYXdiYWNrcyBhcmUgb2J2aW91c2x5IHRoYXQgdGhl cmXigJlzIG5vdCB1c3VhbGx5IGJpZGlyZWN0aW9uYWwNCmNvbW11bmljYXRpb24gaW4gSVBGSVgg YWx0aG91Z2ggdGhhdOKAmXMgbm90IHRvIHNheSB0aGF0IHRoZSBET1RTDQppbXBsZW1lbnRhdGlv biBjb3VsZG7igJl0IG92ZXJjb21lIHRoYXQuICBBbHNvIHRoZXJl4oCZcyBubyByZWFsIGVuY3J5 cHRpb24gc28NCml0IHdvdWxkIGJlIHRscyBvciBkdGxzLg0KDQpUaGF04oCZcyBub3QgdG8gc2F5 IHRoZXJlIGFyZW7igJl0IG90aGVyIChtb3JlIG9yIGxlc3MpIHBvdGVudGlhbGx5IHN1aXRhYmxl DQppZGVhcy9vcHRpb25zIC0ganVzdCBoaWdobGlnaHRpbmcgdGhlIHRoaW5raW5nIGJlaGluZCBo b3cgSVBGSVggZW5kZWQgdXANCmFzIGEgcmVjdXJyaW5nIHRoZW1lIGluIERPVFMuDQoNClRoYW5r cywNCg0KLU5paw0KDQo= From nobody Tue Nov 3 22:45: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 1A3DB1ACEC5 for ; Tue, 3 Nov 2015 22:45:47 -0800 (PST) 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 n3rBC62VBulc for ; Tue, 3 Nov 2015 22:45:46 -0800 (PST) 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 0B9D51A912F for ; Tue, 3 Nov 2015 22:45:46 -0800 (PST) Received: by padhx2 with SMTP id hx2so35732486pad.1 for ; Tue, 03 Nov 2015 22:45:45 -0800 (PST) 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=Qe7/Q4QzswaNgvOoImqkrlgrwdyhcY6ppiQMF0lsoWo=; b=Grc1pBX1LG8TgzTIeG8I3QZP9NgCpwAFAsKqgRdJwTH3/R+rJF3KApTK1E0Nfzlm3q IAadoMtrMYQurGjcSQ5ytvNqyX7x42El9QXKo+m63S7J4OM8ZZ7siGzYLxnXMLlBWWkc JK+EqA46ilni7AnCaTCKLSfkhaF5jKZ4keVGk= 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=Qe7/Q4QzswaNgvOoImqkrlgrwdyhcY6ppiQMF0lsoWo=; b=EelHA5I95AW+e4pTJb6TDfSTS45PJUc2JS/qUOMP4J0n990AGw/e3aj3UjIRprRn01 JUED9M6VJ6apYbJRPXNIHaySlq0r6PkoUZe30Ls5Z5MAe86Xh+VmWhgAxn3/6Ii61y+C IS8PEdBOmGD2/G+4/yoVcICzMHXUbSi8GcJNi96TEADa6YXsk5+bjqSUvuMXpmxcOi9l UAS62UurOftab67TKhD3bxrr5M1P4ohkBKViuYOjAomxV9jWQykLHS3JJXTdwspx3n4h Ac4zNETsz28E1OhXbKZnDd4dGyPNXy41K6zq+bS5rtvYLMUdEMjdSUlyz9hn2JVdjSdK +gGg== X-Gm-Message-State: ALoCoQm4M6fWiJusvASjHfh/lDOIkveqGZ1OAuqcbnbzZ6eX1+vjaALROlvf2RAyujLL9wpSAPrs X-Received: by 10.68.218.37 with SMTP id pd5mr38779318pbc.95.1446619545650; Tue, 03 Nov 2015 22:45:45 -0800 (PST) Received: from [10.0.1.3] (p5231-ipngn5001hodogaya.kanagawa.ocn.ne.jp. [153.220.164.231]) by smtp.gmail.com with ESMTPSA id kj3sm18315121pbc.59.2015.11.03.22.45.44 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 03 Nov 2015 22:45:44 -0800 (PST) From: "Roland Dobbins" To: dots Date: Wed, 04 Nov 2015 15:45:42 +0900 Message-ID: <3C43A000-6E88-4989-916A-8475FBE35C1E@arbor.net> In-Reply-To: References: <20151103194312.594948115.52080.45702@sandvine.com> <56397209.1070404@cisco.com> <5730f98c87df41179715cdff49503c86@XCH-RCD-017.cisco.com> <2880D1B0-BE00-4B87-9763-AA55B024F286@arbor.net> <83efd6bb305348aea6145f4b94629d3d@XCH-RCD-017.cisco.com> <12018EDA-A9E6-48DA-AC9A-F6E87C9D19B3@arbor.net> <6e3c5f617a7844b9801904edf3c13fe3@XCH-RCD-017.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5164) Archived-At: Subject: Re: [Dots] Using Diameter transport for DOTS? 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, 04 Nov 2015 06:45:47 -0000 On 4 Nov 2015, at 15:05, Tirumaleswar Reddy (tireddy) wrote: > I don't understand what you mean by "static nodes" ? It's a very bounded communications channel, low-risk for undetected MITM. > OTK b/w two peers typically involves multiple round-trips (connection > setup, mutual authentication b/w peers, signaling OTK and receiving > acknowledgment, periodic updates to OTK etc.). Gotcha. ----------------------------------- Roland Dobbins From nobody Tue Nov 3 22:58: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 66AC91AD0A4 for ; Tue, 3 Nov 2015 22:58:08 -0800 (PST) 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 fu7IOg_Ots3C for ; Tue, 3 Nov 2015 22:58:06 -0800 (PST) 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 7D0EA1AD0A3 for ; Tue, 3 Nov 2015 22:58:06 -0800 (PST) Received: by padhx2 with SMTP id hx2so36076179pad.1 for ; Tue, 03 Nov 2015 22:58:06 -0800 (PST) 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=HErn/NcY6w48KL0qdB4ORAOSqtStRdme6y8wu2x2sOY=; b=QoGf3foDZcMUxfdxiWKH6nSX5AecnZy8QyCoDdPfsciEOBZ2XQXSkG1snHJ5YhEUbt XPNfX/T7rZbRD1DXtUl794ohBRZj0JIH71HAP+TpsqOfpDAU5PUzkdo/Bd8Im/X6QS5g QCPpPi/fIGmkpCagJ2+40WqgsKp0aPvkQcn7A= 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=HErn/NcY6w48KL0qdB4ORAOSqtStRdme6y8wu2x2sOY=; b=Nf29t2ZDm8RKLYZqiJJUVvvmt4Dku5CBzbuFgY9E7yfpfvp5VijEFGyUnQkzyBqgyE B/+VkzebpownqShXrPPTIKyg04S8OVWqhOeiP/9dvHkjSjYVEEBPo/aDS92GgSJsm+sS 3Yssf4hoP1zKQMp2cpMOIOvwg/LFOofplHc3lh55w9Mf4U+XugLwlyX2D9qmisGFV7QD ahGdCwFQWWyrGQN/FpjEaWXek52Y9rHdmgeK41Yz4RhR4bQYPIADH2NjhWzsPBOIBEN4 f/Yyo+arx8y17+NYQZ9DwrjFyFY+HepXtI85AbRI15+7besUI5tTrNqGVQPy2h5gbUBp +zRw== X-Gm-Message-State: ALoCoQmqDhbJfohX1hCm7VFvrv0DnVejZxTSoKfKXMlFAtdesVS8Eo4NBZR0gpgnvWq6W8tFFwgo X-Received: by 10.68.163.2 with SMTP id ye2mr11923093pbb.47.1446620286151; Tue, 03 Nov 2015 22:58:06 -0800 (PST) Received: from [10.0.1.3] (p5231-ipngn5001hodogaya.kanagawa.ocn.ne.jp. [153.220.164.231]) by smtp.gmail.com with ESMTPSA id yi8sm33376382pab.22.2015.11.03.22.58.04 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 03 Nov 2015 22:58:05 -0800 (PST) From: "Roland Dobbins" To: dots Date: Wed, 04 Nov 2015 15:58:02 +0900 Message-ID: In-Reply-To: References: <20151103194312.594948115.52080.45702@sandvine.com> <56397209.1070404@cisco.com> <5639741A.80408@mykolab.com> <20151104054115.594948115.42583.45842@sandvine.com> <22DE5166-2B69-40C2-B0A6-AF28A12FFAC3@arbor.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.3r5164) Archived-At: Subject: Re: [Dots] Using Diameter transport for DOTS? 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, 04 Nov 2015 06:58:08 -0000 On 4 Nov 2015, at 15:43, Teague, Nik wrote: > * Template - the schema being set in the template export lent itself > to > efficient use of the data export in addition to a degree of > extensibility > either by additional fields beyond those required or with additional > template/data set pairings. Yes - something could potentially be prototyped within the existing IPFIX framework using enterprise IEs without starting from scratch. > Drawbacks are obviously that there’s not usually bidirectional > communication in IPFIX although that’s not to say that the DOTS > implementation couldn’t overcome that. Yes, this isn't an issue. There are no inherent design or functionality constraints in IPFIX which prohibit bidirectional comms. ----------------------------------- Roland Dobbins From nobody Wed Nov 4 00:15: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 6A44F1A0045 for ; Wed, 4 Nov 2015 00:15:54 -0800 (PST) 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 2MFa052tKfaj for ; Wed, 4 Nov 2015 00:15:53 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC1C61A0016 for ; Wed, 4 Nov 2015 00:15:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2596; q=dns/txt; s=iport; t=1446624952; x=1447834552; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=61eg9XzIYzETniSLjWPooM7QLtkwKlFZyjzNa6cW/4w=; b=LoxCixqhAGtYtO35UuM1JP98QccD7ntgtWHt/Q8WWJIkzoY+ZHAENo09 ii8uBFLBBTsxEjzSiO2wxoN6vmp8J8wt/EH5F75pSWjyzsvtmhvhKiouy rMINgGvIAcN/GszXCCk/5RuZWVNHohKTs0epKDu5lQcGTEVsDCjixHMD+ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AnAgDhvTlW/5ldJa1egztTbwa9SAENgV0XCoVyAhyBIDgUAQEBAQEBAYEKhDUBAQEEAQEBIBE6FwQCAQgOAwQBAQECAiMDAgICJQsUAQgIAgQBEgiIJg2wMpEFAQEBAQEBAQEBAQEBAQEBAQEBAQEBGIEChVOEfoQpGS+DBIFDBYdEjwQBhRyHf4Ipmh4BHwEBQoQEcgGELIEHAQEB X-IronPort-AV: E=Sophos;i="5.20,242,1444694400"; d="scan'208";a="43820291" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 04 Nov 2015 08:15:51 +0000 Received: from XCH-RCD-017.cisco.com (xch-rcd-017.cisco.com [173.37.102.27]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id tA48FpTV028022 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 Nov 2015 08:15:52 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-RCD-017.cisco.com (173.37.102.27) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 4 Nov 2015 02:15:51 -0600 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; Wed, 4 Nov 2015 02:15:51 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Roland Dobbins , dots Thread-Topic: [Dots] Using Diameter transport for DOTS? Thread-Index: AdEWb+LjKy2VsZZAT7KTysuTEiK/GQAbbfaAAABO0wAABbh9AAAAxNiAAAFnaoAAAIHKAAAMJL2w Date: Wed, 4 Nov 2015 08:15:51 +0000 Message-ID: <51e93e365612449eab800c682cbc7e80@XCH-RCD-017.cisco.com> References: <20151103194312.594948115.52080.45702@sandvine.com> <56397209.1070404@cisco.com> <5639741A.80408@mykolab.com> <20151104054115.594948115.42583.45842@sandvine.com> <22DE5166-2B69-40C2-B0A6-AF28A12FFAC3@arbor.net> In-Reply-To: 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.38.209] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Using Diameter transport for DOTS? 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, 04 Nov 2015 08:15:54 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBEb3RzIFttYWlsdG86ZG90cy1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUm9sYW5kIERvYmJpbnMNCj4gU2VudDogV2Vk bmVzZGF5LCBOb3ZlbWJlciAwNCwgMjAxNSAxMjoyOCBQTQ0KPiBUbzogZG90cw0KPiBTdWJqZWN0 OiBSZTogW0RvdHNdIFVzaW5nIERpYW1ldGVyIHRyYW5zcG9ydCBmb3IgRE9UUz8NCj4gDQo+IE9u IDQgTm92IDIwMTUsIGF0IDE1OjQzLCBUZWFndWUsIE5payB3cm90ZToNCj4gDQo+ID4gKiBUZW1w bGF0ZSAtIHRoZSBzY2hlbWEgYmVpbmcgc2V0IGluIHRoZSB0ZW1wbGF0ZSBleHBvcnQgbGVudCBp dHNlbGYNCj4gPiB0byBlZmZpY2llbnQgdXNlIG9mIHRoZSBkYXRhIGV4cG9ydCBpbiBhZGRpdGlv biB0byBhIGRlZ3JlZSBvZg0KPiA+IGV4dGVuc2liaWxpdHkgZWl0aGVyIGJ5IGFkZGl0aW9uYWwg ZmllbGRzIGJleW9uZCB0aG9zZSByZXF1aXJlZCBvcg0KPiA+IHdpdGggYWRkaXRpb25hbCB0ZW1w bGF0ZS9kYXRhIHNldCBwYWlyaW5ncy4NCj4gDQo+IFllcyAtIHNvbWV0aGluZyBjb3VsZCBwb3Rl bnRpYWxseSBiZSBwcm90b3R5cGVkIHdpdGhpbiB0aGUgZXhpc3RpbmcgSVBGSVgNCj4gZnJhbWV3 b3JrIHVzaW5nIGVudGVycHJpc2UgSUVzIHdpdGhvdXQgc3RhcnRpbmcgZnJvbSBzY3JhdGNoLg0K PiANCj4gPGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcwMTIjc2VjdGlvbi0yLjE+DQo+ IA0KPiA8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzAxMiNzZWN0aW9uLTQ+DQo+IA0K PiA8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzAxMyNzZWN0aW9uLTYuMj4NCj4gDQo+ IDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MDEzI3NlY3Rpb24tOD4NCj4gDQo+IA0K PiA+IERyYXdiYWNrcyBhcmUgb2J2aW91c2x5IHRoYXQgdGhlcmXigJlzIG5vdCB1c3VhbGx5IGJp ZGlyZWN0aW9uYWwNCj4gPiBjb21tdW5pY2F0aW9uIGluIElQRklYIGFsdGhvdWdoIHRoYXTigJlz IG5vdCB0byBzYXkgdGhhdCB0aGUgRE9UUw0KPiA+IGltcGxlbWVudGF0aW9uIGNvdWxkbuKAmXQg b3ZlcmNvbWUgdGhhdC4NCj4gDQo+IFllcywgdGhpcyBpc24ndCBhbiBpc3N1ZS4gIFRoZXJlIGFy ZSBubyBpbmhlcmVudCBkZXNpZ24gb3IgZnVuY3Rpb25hbGl0eQ0KPiBjb25zdHJhaW50cyBpbiBJ UEZJWCB3aGljaCBwcm9oaWJpdCBiaWRpcmVjdGlvbmFsIGNvbW1zLg0KDQpJIGFtIG5vdCBzdXJl IGhvdyBpdCBtZWV0cyB0aGUgYmVsb3cgcmVxdWlyZW1lbnQNCg0KICAgRy0wMDQgIEJpZGlyZWN0 aW9uYWxpdHk6IFRvIHN1cHBvcnQgcGVlciBoZWFsdGggZGV0ZWN0aW9uLCB0bw0KICAgICAgbWFp bnRhaW4gYW4gb3BlbiBzaWduYWwgY2hhbm5lbCwgYW5kIHRvIGluY3JlYXNlIHRoZSBwcm9iYWJp bGl0eQ0KICAgICAgb2Ygc2lnbmFsIGRlbGl2ZXJ5IGR1cmluZyBhdHRhY2ssIHRoZSBzaWduYWwg Y2hhbm5lbCBNVVNUIGJlDQogICAgICBiaWRpcmVjdGlvbmFsLCB3aXRoIGNsaWVudCBhbmQgc2Vy dmVyIHRyYW5zbWl0dGluZyBzaWduYWxzIHRvIGVhY2gNCiAgICAgIG90aGVyIGF0IHJlZ3VsYXIg aW50ZXJ2YWxzLCByZWdhcmRsZXNzIG9mIGFueSBjbGllbnQgcmVxdWVzdCBmb3INCiAgICAgIG1p dGlnYXRpb24uDQoNCi1UaXJ1DQoNCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+IFJvbGFuZCBEb2JiaW5zIDxyZG9iYmluc0BhcmJvci5uZXQ+DQo+IA0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBEb3RzIG1haWxp bmcgbGlzdA0KPiBEb3RzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vZG90cw0K From nobody Wed Nov 4 00:37: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 D65FD1A87AC for ; Wed, 4 Nov 2015 00:37:47 -0800 (PST) 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 4M8a0571gl7G for ; Wed, 4 Nov 2015 00:37:46 -0800 (PST) Received: from mail-qg0-f99.google.com (mail-qg0-f99.google.com [209.85.192.99]) (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 53FC21A8753 for ; Wed, 4 Nov 2015 00:37:46 -0800 (PST) Received: by qgeo38 with SMTP id o38so2614763qge.2 for ; Wed, 04 Nov 2015 00:37:45 -0800 (PST) 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=azZ2CignIhmj8pFDQkFLHZMdCivLQSR3Ws7igM+Sz/k=; b=KJ4PdUmEFHvWMwwG6gdp85QkE1OCiVoAwjXIYtT97zlgk97S+5RSIqsItZKemsvj/g 8UAVeh3rbUbFVHUn0k+KxMc8W0KQHXNU0Z4D1J6TSUl1lzZA2lVEczW2VyadaLtHh+tM xkP91ykOrElpdDm77BYYc37RKnc2iM/rhQOcEHf091OvCMGqNRvRiH/4O009x6x77/Ph O/TVC6fIODy8hNae3lRbwZZ9pVdMnIYHUnTS4cQ1oHCJFxVIPOTV8IzEP7i41YTOG3Lw 8hMBJxVME1cTeOZGY/mWH/HFayEmcf1wfcXsQRLDDF//tczSv8XHtmk7ciifcWlOkn9J 4rUw== X-Gm-Message-State: ALoCoQkxOlnLRWpakBsXi2hjhDP9wR1Aroum5ak94pljaBQhhcstjsMgsy+FpBQqBqyS0X6hdHVC0F7vSLvgvCgOS0MEqHBehA== X-Received: by 10.140.237.68 with SMTP id i65mr227446qhc.55.1446626265429; Wed, 04 Nov 2015 00:37:45 -0800 (PST) Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by smtp-relay.gmail.com with ESMTPS id d18sm30812qka.6.2015.11.04.00.37.45 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 04 Nov 2015 00:37:45 -0800 (PST) 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 tA48bj7s016085 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Nov 2015 03:37:45 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 4 Nov 2015 03:37:44 -0500 From: "Teague, Nik" To: "Tirumaleswar Reddy (tireddy)" , Roland Dobbins , dots Thread-Topic: [Dots] Using Diameter transport for DOTS? Thread-Index: AdEWb+LjKy2VsZZAT7KTysuTEiK/GQAZVYSAAABO1AD//9nzB4AAWfeAgACiFID//202AIAAFb6AgACc+YA= Date: Wed, 4 Nov 2015 08:37:43 +0000 Message-ID: References: <20151103194312.594948115.52080.45702@sandvine.com> <56397209.1070404@cisco.com> <5639741A.80408@mykolab.com> <20151104054115.594948115.42583.45842@sandvine.com> <22DE5166-2B69-40C2-B0A6-AF28A12FFAC3@arbor.net> <51e93e365612449eab800c682cbc7e80@XCH-RCD-017.cisco.com> In-Reply-To: <51e93e365612449eab800c682cbc7e80@XCH-RCD-017.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 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] Using Diameter transport for DOTS? 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, 04 Nov 2015 08:37:48 -0000 T24gMDQvMTEvMjAxNSAxNzoxNSwgIkRvdHMgb24gYmVoYWxmIG9mIFRpcnVtYWxlc3dhciBSZWRk eSAodGlyZWRkeSkiDQo8ZG90cy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiB0aXJlZGR5 QGNpc2NvLmNvbT4gd3JvdGU6DQoNCj5JIGFtIG5vdCBzdXJlIGhvdyBpdCBtZWV0cyB0aGUgYmVs b3cgcmVxdWlyZW1lbnQNCj4NCj4gICBHLTAwNCAgQmlkaXJlY3Rpb25hbGl0eTogVG8gc3VwcG9y dCBwZWVyIGhlYWx0aCBkZXRlY3Rpb24sIHRvDQo+ICAgICAgbWFpbnRhaW4gYW4gb3BlbiBzaWdu YWwgY2hhbm5lbCwgYW5kIHRvIGluY3JlYXNlIHRoZSBwcm9iYWJpbGl0eQ0KPiAgICAgIG9mIHNp Z25hbCBkZWxpdmVyeSBkdXJpbmcgYXR0YWNrLCB0aGUgc2lnbmFsIGNoYW5uZWwgTVVTVCBiZQ0K PiAgICAgIGJpZGlyZWN0aW9uYWwsIHdpdGggY2xpZW50IGFuZCBzZXJ2ZXIgdHJhbnNtaXR0aW5n IHNpZ25hbHMgdG8gZWFjaA0KPiAgICAgIG90aGVyIGF0IHJlZ3VsYXIgaW50ZXJ2YWxzLCByZWdh cmRsZXNzIG9mIGFueSBjbGllbnQgcmVxdWVzdCBmb3INCj4gICAgICBtaXRpZ2F0aW9uLg0KDQpZ b3UganVzdCBpbXBsZW1lbnQgaXQgYmktZGlyZWN0aW9uYWxseSAtIHRoZSB0cmFkaXRpb25hbCBj bGllbnQgYW5kIHNlcnZlcg0Kcm9sZXMgYmx1ciBzb21ld2hhdCB3aGVuIHlvdSByZXF1aXJlIGxv b3NlbHkgY291cGxlZCBmZWVkYmFjayBhbmQNCmhlYXJ0YmVhdCBmdW5jdGlvbmFsaXR5Lg0KDQpJ ZiBJIHRha2UgYW4gZXhpc3RpbmcgaW1wbGVtZW50YXRpb24gdGhlbiB0aGUgY29uY2VwdCBpc27i gJl0IHJlYWxseSB0aGVyZQ0KYXMgaXRzIGFsbCBkaXJlY3RlZCB0byBmbG93IGNvbGxlY3RvcnMg dG9kYXkgYnV0IHRoYXTigJlzIG5vdCB0byBzYXkgeW91DQpoYXZlIHRvIGltcGxlbWVudCBpdCB0 aGF0IHdheSBpbiBET1RTLg0KDQpBcyBhbiBhc2lkZSAtIFNvbWV0aGluZyBlbHNlIHRvIGNvbnNp ZGVyIGlzIHRoYXQgaWYgeW91IHdhbnQgdG8gZXh0ZW5kIGl0DQpsYXRlciB0byBjb21tdW5pY2F0 aW9uIGJldHdlZW4gYSBET1RTIGFnZW50IGFuZCBhbiBhY3R1YWwgbWl0aWdhdG9yIHlvdQ0KY291 bGQganVzdCBhZGQgYSBtaXRpZ2F0aW9uIHRlbXBsYXRlIGFuZCBkYXRhLXNldC4NCg0KVGhhdCB3 YXMgbXkgdGhpbmtpbmcgYW55d2F5Lg0KDQotTmlrDQoNCg0K From nobody Wed Nov 4 00:39:23 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 8F2071A8F35 for ; Wed, 4 Nov 2015 00:39:21 -0800 (PST) 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 cSwccFO6zVI3 for ; Wed, 4 Nov 2015 00:39:20 -0800 (PST) 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 DF8961A8F42 for ; Wed, 4 Nov 2015 00:39:19 -0800 (PST) Received: by padhx2 with SMTP id hx2so38777202pad.1 for ; Wed, 04 Nov 2015 00:39:19 -0800 (PST) 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=2L555EPJPcwb7c8h5PsdcLhW0hPfNbE70+OabwDnkbQ=; b=F4kJpgTwVLQDE1BgpotbI5Y1WBux0lumNW6a2AM3w/aufK4rtulX1uNmw5A1BH+0g9 AG8xMCtqyUp7ceu9E5Q8yEqQIR/7w+Fe6ftMQnnAy4nRp3cQFBo33fD7AqgauV3NQlEk w2GqYm47ehZKBMcQye4WlTcmGPnVNUvck/nLA= 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=2L555EPJPcwb7c8h5PsdcLhW0hPfNbE70+OabwDnkbQ=; b=jUNrK/Lm5reJhjNT/Dt+YNlbYD/ZY4UoZ83Ki8tk0kP4XWheK9R+gIJGc8Jyi3qFQr Cmx+861EbgTcDWZgyHh9bWXr6XWxs1Sky0sbGxM7DZe5fjnNYl6i7L2r6XvXrgJILYyy 6YWqFhpPHVHWfqpE9MpyJLDL5T52JLSG5IWsfxHL3liacYOdILn/Xnyv/Y7jyuSZCXpd pxvLnhym4TJbf9nsDLNNIB0xu1yJgSRNbYKFP+GrlLq8b/gfx9s3Q7IJu4RpTW1nvgVB tXSofTLquWgsB10kolEI4LlmLwFoYiXrLYuUO0ka2n/eEI+AlSo4l4MK2LFhOurHdbbs U+oA== X-Gm-Message-State: ALoCoQkmGG0JB41A8dlsUpPkUEndz9NSAK2z666lPs00qIvZv2voeEGP/lMYFlHPxtFfGJ0oPbbl X-Received: by 10.66.136.11 with SMTP id pw11mr310379pab.87.1446626359516; Wed, 04 Nov 2015 00:39:19 -0800 (PST) Received: from [10.0.1.3] (p5231-ipngn5001hodogaya.kanagawa.ocn.ne.jp. [153.220.164.231]) by smtp.gmail.com with ESMTPSA id vl1sm536236pbc.31.2015.11.04.00.39.18 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 04 Nov 2015 00:39:18 -0800 (PST) From: "Roland Dobbins" To: dots Date: Wed, 04 Nov 2015 17:39:16 +0900 Message-ID: <08154F3D-7EB4-4093-838F-9A4305A707D3@arbor.net> In-Reply-To: <51e93e365612449eab800c682cbc7e80@XCH-RCD-017.cisco.com> References: <20151103194312.594948115.52080.45702@sandvine.com> <56397209.1070404@cisco.com> <5639741A.80408@mykolab.com> <20151104054115.594948115.42583.45842@sandvine.com> <22DE5166-2B69-40C2-B0A6-AF28A12FFAC3@arbor.net> <51e93e365612449eab800c682cbc7e80@XCH-RCD-017.cisco.com> MIME-Version: 1.0 X-Mailer: MailMate (1.9.3r5164) Archived-At: Subject: Re: [Dots] Using Diameter transport for DOTS? 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, 04 Nov 2015 08:39:21 -0000 On 4 Nov 2015, at 17:15, Tirumaleswar Reddy (tireddy) wrote: > I am not sure how it meets the below requirement Because we implement it bidirectionally. There is no unidirectional restriction for IPFIX. ----------------------------------- Roland Dobbins From nobody Wed Nov 4 00:40: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 134E81A8F35 for ; Wed, 4 Nov 2015 00:40:02 -0800 (PST) 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 4lGxDIingK75 for ; Wed, 4 Nov 2015 00:40:01 -0800 (PST) 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 1AAC11A8A1B for ; Wed, 4 Nov 2015 00:40:01 -0800 (PST) Received: by pacdm15 with SMTP id dm15so22497371pac.3 for ; Wed, 04 Nov 2015 00:40:00 -0800 (PST) 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=jwunxeq/VMlF1k8iN/rDJKbLxK4o/09AngYe/IZmnG8=; b=cmMiASy8arcwJW785ZSPeoLBgoyKvs8ONc72AnOL4pwVdA8qXmRlyeZgh/rG7vGFmy 9s41zHepvhVIAaa85jqksbWmYVnhh7uD7JzE1P7XuAz0RD7Mrbc8l19SDLX5kcMHynsi 6vmg4ROZl9VeErJcVmGoA1RK0oCklkki9iM4A= 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=jwunxeq/VMlF1k8iN/rDJKbLxK4o/09AngYe/IZmnG8=; b=WXL+FwE05ILiWpakKYQKiibBdoBi4Xc8CKKyQ+zqZDevk0V11og3FfDnlWsV9fnrVQ FnalM/a0S+shQbJYgjKRDv6g9Xw+GQmayuU3R2hxRaoSUUD4vTrPQtiG85yTUiqTZWrC PBbmDJfT3eveVhd4z0pfSFVhz0kN2Yt7y1RDZ9YmVYX/EME8yE3UTpjjsJ/k+RokhrLq Ie+/g0CXhyeYZnOH5bqoSaGfXNe1b+0GgC3Q3R4PLTKzeoXOWv574dFqJDtFrUhZHaOM C4TdA5tpDBN4TlKrIq9uDI7gVNELpfw0DBlRUssw9XWDRiSQLRk4IYbqYbBF8/I1Qr4Z qv+Q== X-Gm-Message-State: ALoCoQl3orB9WPagBZH5FY/Clbdl7Dbvjz5IM7lHk2OliD0UorIa8qP6+h8TM9jfcqm8tM8Wg7bh X-Received: by 10.68.114.1 with SMTP id jc1mr399147pbb.54.1446626400767; Wed, 04 Nov 2015 00:40:00 -0800 (PST) Received: from [10.0.1.3] (p5231-ipngn5001hodogaya.kanagawa.ocn.ne.jp. [153.220.164.231]) by smtp.gmail.com with ESMTPSA id qf2sm576548pbb.3.2015.11.04.00.39.59 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 04 Nov 2015 00:40:00 -0800 (PST) From: "Roland Dobbins" To: dots Date: Wed, 04 Nov 2015 17:39:57 +0900 Message-ID: In-Reply-To: References: <20151103194312.594948115.52080.45702@sandvine.com> <56397209.1070404@cisco.com> <5639741A.80408@mykolab.com> <20151104054115.594948115.42583.45842@sandvine.com> <22DE5166-2B69-40C2-B0A6-AF28A12FFAC3@arbor.net> <51e93e365612449eab800c682cbc7e80@XCH-RCD-017.cisco.com> MIME-Version: 1.0 X-Mailer: MailMate (1.9.3r5164) Archived-At: Subject: Re: [Dots] Using Diameter transport for DOTS? 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, 04 Nov 2015 08:40:02 -0000 On 4 Nov 2015, at 17:37, Teague, Nik wrote: > That was my thinking anyway. Strongly concur for use *as a transport*. ----------------------------------- Roland Dobbins From nobody Wed Nov 4 00:58: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 BA80A1B2B29; Wed, 4 Nov 2015 00:56:27 -0800 (PST) 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 zhLgCM_fB9Wh; Wed, 4 Nov 2015 00:56:26 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 83B3E1AD0BB; Wed, 4 Nov 2015 00:56:26 -0800 (PST) Received: from erg.abdn.ac.uk (galactica.erg.abdn.ac.uk [139.133.210.32]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id EA7351B00231; Wed, 4 Nov 2015 09:03:39 +0000 (GMT) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by erg.abdn.ac.uk with HTTP; Wed, 4 Nov 2015 08:56:25 -0000 Message-ID: <20dadcd20c26d51c284fdc4697cdc8a9.squirrel@erg.abdn.ac.uk> In-Reply-To: References: <5638D31B.4080801@mti-systems.com> <0A836E5A-C801-4CF4-916C-41EA065D3D30@arbor.net> Date: Wed, 4 Nov 2015 08:56:25 -0000 From: gorry@erg.abdn.ac.uk To: "Aaron Falk" User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: X-Mailman-Approved-At: Wed, 04 Nov 2015 00:58:39 -0800 Cc: "tsvwg@ietf.org" , "tsvwg-chairs@ietf.org" , dots@ietf.org Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 04 Nov 2015 08:56:27 -0000 I'm in favour - but I am currently in a different timezone to my co-chair - who is managing our agenda time... Curiously: think this could be an excellent extension to the TAPS API - saying you want robustness and letting it choose protocol - but we need first of all to see if we can get something useful from TAPS first before we build new "features":-) Seriously: I think it deserves a heads-up presentation of the problem to be addressed. Gorry > TSVWG chairs- > > Will you allocate some time for this topic? > > --aaron > > On Wed, Nov 4, 2015 at 7:10 AM, Roland Dobbins wrote: > >> On 4 Nov 2015, at 1:22, Ca By wrote: >> >> at least in the case i am most familiar with. >>> >> >> It is important to keep this part in mind. >> >> With DOTS in UDP, you are putting the DOTs traffic in that path that >>> becomes the most lossy during a a DDoS. >>> >> >> This is an overgeneralization - see above. >> >> There are lots of topological and pathing assumptions being made, here, >> as >> well as policy-filtering assumptions. >> >> It has been clear from the beginning of this effort that both stateless >> and stateful transport options are necessary, due to overly-restrictive >> network access policies, edge QoSing as a (counterproductive, IMHO) >> measure >> against UDP reflection/amplification attacks, etc. This has been >> discussed >> on-list and in meetings, it's unclear why it's become contentious, all >> of a >> sudden. >> >> ----------------------------------- >> Roland Dobbins >> >> > From nobody Wed Nov 4 01:27: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 478151B2BD7 for ; Wed, 4 Nov 2015 01:27:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 84Z7OyXgcrbB for ; Wed, 4 Nov 2015 01:27:08 -0800 (PST) Received: from Mail2.SpriteLink.NET (Mail2.SpriteLink.NET [195.182.5.83]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C5911B2BDA for ; Wed, 4 Nov 2015 01:27:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by Mail2.SpriteLink.NET (Postfix) with ESMTP id 5B010261848 for ; Wed, 4 Nov 2015 10:27:05 +0100 (CET) X-Virus-Scanned: amavisd-new at SpriteLink.NET Received: from Mail2.SpriteLink.NET ([195.182.5.83]) by localhost (Mail2.SpriteLink.NET [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MkDZNo8SuP6s for ; Wed, 4 Nov 2015 10:27:03 +0100 (CET) Received: from Kristians-MacBook-Pro.local (c-1a95e253.041-205-73746f13.cust.bredbandsbolaget.se [83.226.149.26]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: kristian@spritelink.net) by Mail2.SpriteLink.NET (Postfix) with ESMTPSA id 84808261846 for ; Wed, 4 Nov 2015 10:27:03 +0100 (CET) To: dots@ietf.org References: <20151103194312.594948115.52080.45702@sandvine.com> <56397209.1070404@cisco.com> <5730f98c87df41179715cdff49503c86@XCH-RCD-017.cisco.com> <2880D1B0-BE00-4B87-9763-AA55B024F286@arbor.net> From: Kristian Larsson Message-ID: <5639CF67.5070501@spritelink.net> Date: Wed, 4 Nov 2015 10:27:03 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <2880D1B0-BE00-4B87-9763-AA55B024F286@arbor.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dots] Using Diameter transport for DOTS? 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, 04 Nov 2015 09:27:10 -0000 On 04/11/15 04:47, Roland Dobbins wrote: > > On 4 Nov 2015, at 12:20, Tirumaleswar Reddy (tireddy) wrote: > >> DOTS client and server can complete DTLS handshake during non-attack time > > This assumes pre-attack provisioning. A depressingly large proportion > of DDoS mitigation provisioning takes place during an attack. Is DOTS relevant in such a scenario? If there is no pre-attack provisioning I would assume that the party being attacked would use an alternative method, such as a phone, to communicate with their provider of DDoS mitigation services. They would then manually start a mitigation for a given set of IPs. When and how would DOTS come into play? >> and the DOTS client can convey the SOS message along with the Client >> Hello. > > Personally, I'm not a big fan of the 'SOS' terminology. Neither am I but it is short and easy to say :) kll From nobody Wed Nov 4 01:31: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 771461B2BEB for ; Wed, 4 Nov 2015 01:31:52 -0800 (PST) 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 RfgoJuNWw9vb for ; Wed, 4 Nov 2015 01:31:51 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CE0F1B2BE8 for ; Wed, 4 Nov 2015 01:31:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2382; q=dns/txt; s=iport; t=1446629511; x=1447839111; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=n1ARb+MveSEWdDRC3iYJOxsrsjYTKU5tdjKmgsoGIBs=; b=Tx9sIH0A40ksC59GS8tLoaj/jCG33JKWSdM63xXwMicZAh34VvfbuT+t pBXM8/amshmZcdyrY3F7Ho3Q77Rd7sfnO7UiPeIPRTW/gWRBCWW+7FSTb KKdGdSTFA7CiaKuq5m6vZ6DDyFp5zS1whCcjz2NZJgAAvYyFqg+/0xhah U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AmAgDAzzlW/5tdJa1egzuBQga7I4IbAQ2BXYYTAhyBIzgUAQEBAQEBAYEKhDUBAQEDASMRUQQCAQgRBAEBAQICIwMCAgIwFAEICAIEARIIiB4IsDqRBAEBAQEBAQEBAQEBAQEBAQEBAQEBARiBAoVThH6EQi+DBIFDBZZIAY0bnEcBHwEBQoQEcoQtgQcBAQE X-IronPort-AV: E=Sophos;i="5.20,242,1444694400"; d="scan'208";a="47478190" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Nov 2015 09:31:50 +0000 Received: from XCH-ALN-020.cisco.com (xch-aln-020.cisco.com [173.36.7.30]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id tA49Vopg009891 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 Nov 2015 09:31:50 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-ALN-020.cisco.com (173.36.7.30) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 4 Nov 2015 03:31:49 -0600 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; Wed, 4 Nov 2015 03:31:43 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "Teague, Nik" , Roland Dobbins , dots Thread-Topic: [Dots] Using Diameter transport for DOTS? Thread-Index: AdEWb+LjKy2VsZZAT7KTysuTEiK/GQAbbfaAAABO0wAABbh9AAAAxNiAAAFnaoAAAIHKAAAMJL2w//+6tICAAF9V0A== Date: Wed, 4 Nov 2015 09:31:43 +0000 Message-ID: <3921fe1ddd1543d1a7ca28777c6ff24b@XCH-RCD-017.cisco.com> References: <20151103194312.594948115.52080.45702@sandvine.com> <56397209.1070404@cisco.com> <5639741A.80408@mykolab.com> <20151104054115.594948115.42583.45842@sandvine.com> <22DE5166-2B69-40C2-B0A6-AF28A12FFAC3@arbor.net> <51e93e365612449eab800c682cbc7e80@XCH-RCD-017.cisco.com> In-Reply-To: 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.51.190] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Using Diameter transport for DOTS? 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, 04 Nov 2015 09:31:52 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBUZWFndWUsIE5payBbbWFpbHRv Om50ZWFndWVAdmVyaXNpZ24uY29tXQ0KPiBTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDA0LCAy MDE1IDI6MDggUE0NCj4gVG86IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSk7IFJvbGFuZCBE b2JiaW5zOyBkb3RzDQo+IFN1YmplY3Q6IFJlOiBbRG90c10gVXNpbmcgRGlhbWV0ZXIgdHJhbnNw b3J0IGZvciBET1RTPw0KPiANCj4gT24gMDQvMTEvMjAxNSAxNzoxNSwgIkRvdHMgb24gYmVoYWxm IG9mIFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkiDQo+IDxkb3RzLWJvdW5jZXNAaWV0Zi5v cmcgb24gYmVoYWxmIG9mIHRpcmVkZHlAY2lzY28uY29tPiB3cm90ZToNCj4gDQo+ID5JIGFtIG5v dCBzdXJlIGhvdyBpdCBtZWV0cyB0aGUgYmVsb3cgcmVxdWlyZW1lbnQNCj4gPg0KPiA+ICAgRy0w MDQgIEJpZGlyZWN0aW9uYWxpdHk6IFRvIHN1cHBvcnQgcGVlciBoZWFsdGggZGV0ZWN0aW9uLCB0 bw0KPiA+ICAgICAgbWFpbnRhaW4gYW4gb3BlbiBzaWduYWwgY2hhbm5lbCwgYW5kIHRvIGluY3Jl YXNlIHRoZSBwcm9iYWJpbGl0eQ0KPiA+ICAgICAgb2Ygc2lnbmFsIGRlbGl2ZXJ5IGR1cmluZyBh dHRhY2ssIHRoZSBzaWduYWwgY2hhbm5lbCBNVVNUIGJlDQo+ID4gICAgICBiaWRpcmVjdGlvbmFs LCB3aXRoIGNsaWVudCBhbmQgc2VydmVyIHRyYW5zbWl0dGluZyBzaWduYWxzIHRvIGVhY2gNCj4g PiAgICAgIG90aGVyIGF0IHJlZ3VsYXIgaW50ZXJ2YWxzLCByZWdhcmRsZXNzIG9mIGFueSBjbGll bnQgcmVxdWVzdCBmb3INCj4gPiAgICAgIG1pdGlnYXRpb24uDQo+IA0KPiBZb3UganVzdCBpbXBs ZW1lbnQgaXQgYmktZGlyZWN0aW9uYWxseSAtIHRoZSB0cmFkaXRpb25hbCBjbGllbnQgYW5kIHNl cnZlcg0KPiByb2xlcyBibHVyIHNvbWV3aGF0IHdoZW4geW91IHJlcXVpcmUgbG9vc2VseSBjb3Vw bGVkIGZlZWRiYWNrIGFuZA0KPiBoZWFydGJlYXQgZnVuY3Rpb25hbGl0eS4NCg0KUkVTVCBzZWVt cyB0byBmaXQgdGhlIHJlcXVpcmVtZW50cyBiZXR0ZXIuDQoNCj4gDQo+IElmIEkgdGFrZSBhbiBl eGlzdGluZyBpbXBsZW1lbnRhdGlvbiB0aGVuIHRoZSBjb25jZXB0IGlzbuKAmXQgcmVhbGx5IHRo ZXJlDQo+IGFzIGl0cyBhbGwgZGlyZWN0ZWQgdG8gZmxvdyBjb2xsZWN0b3JzIHRvZGF5IGJ1dCB0 aGF04oCZcyBub3QgdG8gc2F5IHlvdQ0KPiBoYXZlIHRvIGltcGxlbWVudCBpdCB0aGF0IHdheSBp biBET1RTLg0KDQpHb3QgaXQuIEkgZ3Vlc3MgY29tcGFyaXNvbiBvZiB0aGVzZSB0d28gcHJvdG9j b2xzIGZvciBET1RTIHNpZ25hbGluZyBwcm90b2NvbCB3aWxsIGJlIGhlbHBmdWwuIEFueXdheXMg Ym90aCBJUEZJWCBhbmQgUkVTVCB1c2UgKEQpVExTIGZvciBzZWN1cml0eSwgYW5kIG1lZXQgdGhl IHRyYW5zcG9ydCBhbmQgc2VjdXJpdHkgcmVxdWlyZW1lbnRzLg0KDQotVGlydQ0KDQo+IA0KPiBB cyBhbiBhc2lkZSAtIFNvbWV0aGluZyBlbHNlIHRvIGNvbnNpZGVyIGlzIHRoYXQgaWYgeW91IHdh bnQgdG8gZXh0ZW5kIGl0DQo+IGxhdGVyIHRvIGNvbW11bmljYXRpb24gYmV0d2VlbiBhIERPVFMg YWdlbnQgYW5kIGFuIGFjdHVhbCBtaXRpZ2F0b3IgeW91DQo+IGNvdWxkIGp1c3QgYWRkIGEgbWl0 aWdhdGlvbiB0ZW1wbGF0ZSBhbmQgZGF0YS1zZXQuDQo+IA0KPiBUaGF0IHdhcyBteSB0aGlua2lu ZyBhbnl3YXkuDQo+IA0KPiAtTmlrDQo+IA0KDQo= From nobody Wed Nov 4 05:05: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 3A55D1B2EDA for ; Wed, 4 Nov 2015 05:05:13 -0800 (PST) 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 VUeF2qWX3lCK for ; Wed, 4 Nov 2015 05:05:12 -0800 (PST) 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 096661B2ECE for ; Wed, 4 Nov 2015 05:05:02 -0800 (PST) Received: by padhx2 with SMTP id hx2so45031297pad.1 for ; Wed, 04 Nov 2015 05:05:01 -0800 (PST) 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=NZSZuF6aTOIfE9KaXEzfAiOzD0XtrnwCKDuUlOo0EPY=; b=BpcpFPIall4KBPYyGjs02hEXOUzquqsEdxa6LDyoDVdzhB8dUDEO32dSt8CC8oCyxl jp8Li31cSuh5GcQJmLHy7VL5mG5JgIjdSqEwjmoaM9X8zvpODw0isqwcItU5mPwLA5+I zzWEB1KDqRDREE3SnJUN+3BtUgioKl7Qy/g9g= 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=NZSZuF6aTOIfE9KaXEzfAiOzD0XtrnwCKDuUlOo0EPY=; b=AnJEFuTY6XFo3iDPb83I4/k4EjagENRxyR37i4wQdjzUFWEWJxSixvzvzeFfWuqYE3 pEVGCAQ1g/Td1qaIhATc8zdOmFKlAKzL9tbDQBGDnrncghcfAo4my/v432jWJhhKTvw2 CF2XcRn+xjt4uz2RLzrd1b+z+PzUbRL3Eo9H9DOKcsQzEPpST/7IjtL1Esb59p8VAGzU MvnrTLkDIvqVyJtVVKHtwhU1DfKifN/Pq23YZZbjXLvko+zmBbBGolCotbOe4q/J5wJb 2m2Vx/bMTyq1zvQXbdT0RVeIvwE61nQmN2NDpNaLRrAVJ/WE31WxOkzQvuIQi3smjQbZ aTZQ== X-Gm-Message-State: ALoCoQk9RVPpYZadCGBjPJ6GFUIFGFz2MR8CyeCJF+AFhr1s162OMNRVdBMk+i7ETti3zWbtSGIr X-Received: by 10.68.69.6 with SMTP id a6mr1784393pbu.62.1446642301664; Wed, 04 Nov 2015 05:05:01 -0800 (PST) Received: from [10.0.1.3] (p5231-ipngn5001hodogaya.kanagawa.ocn.ne.jp. [153.220.164.231]) by smtp.gmail.com with ESMTPSA id ns1sm2045193pbc.67.2015.11.04.05.04.59 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 04 Nov 2015 05:05:00 -0800 (PST) From: "Roland Dobbins" To: dots@ietf.org Date: Wed, 04 Nov 2015 22:04:57 +0900 Message-ID: In-Reply-To: <5639CF67.5070501@spritelink.net> References: <20151103194312.594948115.52080.45702@sandvine.com> <56397209.1070404@cisco.com> <5730f98c87df41179715cdff49503c86@XCH-RCD-017.cisco.com> <2880D1B0-BE00-4B87-9763-AA55B024F286@arbor.net> <5639CF67.5070501@spritelink.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5164) Archived-At: Subject: Re: [Dots] Using Diameter transport for DOTS? 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, 04 Nov 2015 13:05:13 -0000 On 4 Nov 2015, at 18:27, Kristian Larsson wrote: > When and how would DOTS come into play? The mitigation provider instructs the organization seeking DDoS mitigation services to enter the appropriate DOTS peering and authentication information into their DOTS-capable mitigator/device/service/app, it registers and describes the properties to be protected, auto-provisioning on the mitigation provider side takes place, and situationally-appropriate mitigation is initiated. This is a much better scenario than fumbling around trying to get all this information via voice from organizations - even the largest of the large - who can't properly articulate what servers/services/applications they're running, what their network access policies are (or ought to be, based on what they're running), etc. ----------------------------------- Roland Dobbins From nobody Wed Nov 4 05:08: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 2C3931B2EF2 for ; Wed, 4 Nov 2015 05:08:51 -0800 (PST) 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 fHU-XWjf7eJV for ; Wed, 4 Nov 2015 05:08:49 -0800 (PST) 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 91DA31B2ED1 for ; Wed, 4 Nov 2015 05:08:49 -0800 (PST) Received: by pabfh17 with SMTP id fh17so53119431pab.0 for ; Wed, 04 Nov 2015 05:08:49 -0800 (PST) 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=p4QtcKGG/m+2hWQWsg8DXuz+3RUmELRdb+clu7HY6Ys=; b=iLyZvDgEiLactUjO1LVXMvKPm8yzfJVRpbQoe2UT4EJF5gEsgeeBtAhDUA1+Q0Pytx lwLYU1fksmUhgQQcAU1z5UQubHYtZ18qnHjw8VxeXtFQayX6+VhELFit0DlxiC7ZbVu2 Dati3OP+HLAo6JD3mSE7zLY6iB0hM/PxnZg6k= 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=p4QtcKGG/m+2hWQWsg8DXuz+3RUmELRdb+clu7HY6Ys=; b=iDFp32JQvNDJQp+uBBwrfFBc6027yzNUhFSeQY8H/jV3CVrIXRE/HEgdqOE4UMzYGI /f79xWCRG8uWUahYXSDCAJAf6i9KSD/oi08kJ+BNGDjSC2gumyqcDmnHo5HbIs2PTTHc m74TznpbN/sp1PfnrRBSi1nj02gRvuYHTM6Ix7QRf4iGM2V6J2s+iyWU/4OAuEXGplpx oSWJKhHzVAPywJ8p6k0b6uANeitMuliismjTQDpJ54xS66XCisa5650zhTP5XRisNu/p ZxANXYJqQgLCvXPxDCDkZLkAl4UODB+CkoZ25ubiJU+i3IQATsDBg2JmVLMKMFk8Mczf 34Rw== X-Gm-Message-State: ALoCoQkHzjgS01u88E3jEY5JHqPdxXt0sj0lv5T3pNO92Mr7LYIRHiNqDFBoljQG09NJhk/cYCCl X-Received: by 10.66.236.201 with SMTP id uw9mr1757086pac.76.1446642529174; Wed, 04 Nov 2015 05:08:49 -0800 (PST) Received: from [10.0.1.3] (p5231-ipngn5001hodogaya.kanagawa.ocn.ne.jp. [153.220.164.231]) by smtp.gmail.com with ESMTPSA id ja4sm2121088pbb.19.2015.11.04.05.08.47 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 04 Nov 2015 05:08:48 -0800 (PST) From: "Roland Dobbins" To: dots Date: Wed, 04 Nov 2015 22:08:46 +0900 Message-ID: <0A8ED500-AB4D-43B5-A0D5-6B9118574EE2@arbor.net> In-Reply-To: <3921fe1ddd1543d1a7ca28777c6ff24b@XCH-RCD-017.cisco.com> References: <20151103194312.594948115.52080.45702@sandvine.com> <56397209.1070404@cisco.com> <5639741A.80408@mykolab.com> <20151104054115.594948115.42583.45842@sandvine.com> <22DE5166-2B69-40C2-B0A6-AF28A12FFAC3@arbor.net> <51e93e365612449eab800c682cbc7e80@XCH-RCD-017.cisco.com> <3921fe1ddd1543d1a7ca28777c6ff24b@XCH-RCD-017.cisco.com> MIME-Version: 1.0 X-Mailer: MailMate (1.9.3r5164) Archived-At: Subject: Re: [Dots] Using Diameter transport for DOTS? 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, 04 Nov 2015 13:08:51 -0000 On 4 Nov 2015, at 18:31, Tirumaleswar Reddy (tireddy) wrote: > REST seems to fit the requirements better. I'm unsure it does. Can you expound on that view? ----------------------------------- Roland Dobbins From nobody Wed Nov 4 05:26: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 784D81B2F43 for ; Wed, 4 Nov 2015 05:26:27 -0800 (PST) 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 jvDyFzcW_iZV for ; Wed, 4 Nov 2015 05:26:26 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A683B1B2F46 for ; Wed, 4 Nov 2015 05:26:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=736; q=dns/txt; s=iport; t=1446643585; x=1447853185; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=MJXCealklagcAS/yN9aDQLgfvZkrgtIU8tYKQhOvshA=; b=Ap3NRtcCa+jYVwdMkE7tB6FZ1NODUOedprPVgfZMGK2Qowdm/uZedfpi r2pf8YplZaQCq42f8Z0BYggrVPdcvykC/dRVPp/MeRT90bvRD3aznpHzx OjGN6umKUua4qjdO2vlaJVJAFFcHTAMmyIJWn8Pv5I1T//8LQObImZjFD U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AMAgBBBzpW/4sNJK1egztTbwa9PwENgV0XCoVyAoFCOBQBAQEBAQEBgQqENQEBAQQBAQE3NBcEAgEIDgMEAQEBHgkHJwsUCQgCBAESCIgmDcFTAQEBAQEBAQEBAQEBAQEBAQEBAQEBFASGVYR+iTgFh0SPBAGFHId/nEcBHwEBQoQEcoQtgQcBAQE X-IronPort-AV: E=Sophos;i="5.20,243,1444694400"; d="scan'208";a="204930536" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-7.cisco.com with ESMTP; 04 Nov 2015 13:26:24 +0000 Received: from XCH-RCD-020.cisco.com (xch-rcd-020.cisco.com [173.37.102.30]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id tA4DQOC7026033 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 Nov 2015 13:26:24 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; Wed, 4 Nov 2015 07:26:24 -0600 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; Wed, 4 Nov 2015 07:26:24 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Roland Dobbins , dots Thread-Topic: [Dots] Using Diameter transport for DOTS? Thread-Index: AdEWb+LjKy2VsZZAT7KTysuTEiK/GQAbbfaAAABO0wAABbh9AAAAxNiAAAFnaoAAAIHKAAAMJL2w//+6tICAAF9V0P//7GYAgABga6A= Date: Wed, 4 Nov 2015 13:26:24 +0000 Message-ID: <7655ac73d854468aa94d24e0f95f25b9@XCH-RCD-017.cisco.com> References: <20151103194312.594948115.52080.45702@sandvine.com> <56397209.1070404@cisco.com> <5639741A.80408@mykolab.com> <20151104054115.594948115.42583.45842@sandvine.com> <22DE5166-2B69-40C2-B0A6-AF28A12FFAC3@arbor.net> <51e93e365612449eab800c682cbc7e80@XCH-RCD-017.cisco.com> <3921fe1ddd1543d1a7ca28777c6ff24b@XCH-RCD-017.cisco.com> <0A8ED500-AB4D-43B5-A0D5-6B9118574EE2@arbor.net> In-Reply-To: <0A8ED500-AB4D-43B5-A0D5-6B9118574EE2@arbor.net> 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.51.190] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Using Diameter transport for DOTS? 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, 04 Nov 2015 13:26:27 -0000 > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Roland Dobbins > Sent: Wednesday, November 04, 2015 6:39 PM > To: dots > Subject: Re: [Dots] Using Diameter transport for DOTS? >=20 > On 4 Nov 2015, at 18:31, Tirumaleswar Reddy (tireddy) wrote: >=20 > > REST seems to fit the requirements better. >=20 > I'm unsure it does. >=20 > Can you expound on that view? https://tools.ietf.org/html/draft-reddy-dots-transport-01#section-4 discuss= es SOS. -Tiru >=20 > ----------------------------------- > Roland Dobbins >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Wed Nov 4 05:37:43 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 5B4301B2F7B for ; Wed, 4 Nov 2015 05:37:42 -0800 (PST) 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 pPWidj82NsHe for ; Wed, 4 Nov 2015 05:37:40 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8BA81B2F7A for ; Wed, 4 Nov 2015 05:37:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1706; q=dns/txt; s=iport; t=1446644260; x=1447853860; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=aqAgJxKmLYPU01GjbuYi5y0hSGkPDF64ocRTwDsdncc=; b=mxIIWBKiz1OEmdKyCFHovU/9ySsgoBx0uoXthc7qJDyRLaohiVhZ0juf 6dsSrNHSCGjqY3EVDuoXiaJD0HUvyGMyth4qTVDj1BWsABo0ldLZs2Udk zl2Q4PIWjmJd20Eu0yxgCN06yOpEkIZc6qUTMSYIRYL9wzk6JdnjD+vjv U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AMAgBfCTpW/5ldJa1VCYM7U28GvT8BDYFdFwqFcgKBQzgUAQEBAQEBAYEKhDUBAQEDAQEBATc0FwQCAQgOAwQBAQEeCQcnCxQJCAIEARIIiB4IDcFGAQEBAQEBAQEBAQEBAQEBAQEBAQEBFASGVYR+hDERhHYFh0SPBAGNG5xHAR8BAUKEBHKDbCUcgQcBAQE X-IronPort-AV: E=Sophos;i="5.20,243,1444694400"; d="scan'208";a="47339216" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 04 Nov 2015 13:37:39 +0000 Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id tA4Dbddr004605 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 Nov 2015 13:37:39 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 4 Nov 2015 07:37:39 -0600 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; Wed, 4 Nov 2015 07:37:39 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Roland Dobbins , "dots@ietf.org" Thread-Topic: [Dots] Using Diameter transport for DOTS? Thread-Index: AdEWb+LjKy2VsZZAT7KTysuTEiK/GQAbbfaAAAvQTcD//7H/AIAAXsuAgAA84oCAAF33AA== Date: Wed, 4 Nov 2015 13:37:39 +0000 Message-ID: References: <20151103194312.594948115.52080.45702@sandvine.com> <56397209.1070404@cisco.com> <5730f98c87df41179715cdff49503c86@XCH-RCD-017.cisco.com> <2880D1B0-BE00-4B87-9763-AA55B024F286@arbor.net> <5639CF67.5070501@spritelink.net> In-Reply-To: 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.51.190] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Using Diameter transport for DOTS? 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, 04 Nov 2015 13:37:42 -0000 > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Roland Dobbins > Sent: Wednesday, November 04, 2015 6:35 PM > To: dots@ietf.org > Subject: Re: [Dots] Using Diameter transport for DOTS? >=20 > On 4 Nov 2015, at 18:27, Kristian Larsson wrote: >=20 > > When and how would DOTS come into play? >=20 > The mitigation provider instructs the organization seeking DDoS mitigatio= n > services to enter the appropriate DOTS peering and authentication > information into their DOTS-capable mitigator/device/service/app, it > registers and describes the properties to be protected, auto-provisioning= on > the mitigation provider side takes place, and situationally-appropriate > mitigation is initiated. If all the above steps are performed then why can't the DOTS client cannot = perform DTLS handshake with the DOTS server as pre-provisioning step ?=20 DOTS client also needs to configured with the DOTS server domain/IP address= es and DOTS client needs to be configured with certificates or SPKI fingerp= rint etc. to validate the DOTS server identity. -Tiru >=20 > This is a much better scenario than fumbling around trying to get all thi= s > information via voice from organizations - even the largest of the large = - who > can't properly articulate what servers/services/applications they're runn= ing, > what their network access policies are (or ought to be, based on what the= y're > running), etc. >=20 > ----------------------------------- > Roland Dobbins >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Wed Nov 4 05:46: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 674311B2BE3 for ; Wed, 4 Nov 2015 05:46:52 -0800 (PST) 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 toeKRJExVG2M for ; Wed, 4 Nov 2015 05:46:51 -0800 (PST) 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 80ACA1B2FA2 for ; Wed, 4 Nov 2015 05:46:50 -0800 (PST) Received: by pacdm15 with SMTP id dm15so29576289pac.3 for ; Wed, 04 Nov 2015 05:46:50 -0800 (PST) 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=bECMQnTiFMz62WtV179ITKzg+XGUy4/DVL7WZKOa3LE=; b=Lwd7gpeyQCjIjUK0GKwcacyjIl2m9bR/7DtZP+/pVW1QQjg+7GouzEaybX/L/0LBLl qsbeq/i4rJTyWbsNRnIN1XqDz6kkR220xl+CcHFWYi/ZAsLp2gD4oyLSFv44E9tQAixY gBi/Dy7xiUOn0XZO3SqBd4VGgClxUBXUcglkA= 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=bECMQnTiFMz62WtV179ITKzg+XGUy4/DVL7WZKOa3LE=; b=Y32/3oq21GYaPshoNogyWIplQIAMtzYnIqXfaTTuGfFruKSN3oXmQK5rMeDGZ4ThUb igmh6nUDfCeq6Deks9fQ3A/dUzkROgI8P0+czx7/7K9S0Zr8GWPWyTCbowbhYY1mHj1z w2+Ghj+ngTAhc8FFQDNutH6rQd2rbYSvJCkgCI1Miu0fc7/hXcQL7nonLd1BztplGyxP FmTibKRxzGQsVLBbVyjFIQbXl0nnKwNYZhkXuHN1vAdsF2NsuX/KYeHzWuMwqyxHwlyQ wBqREl3Lv7fEWrH5ipx4jPkh0p9/yY6Ly4hu0nm5UcCOqCn4zSJKbvDktsVm16xlo2pj S1cw== X-Gm-Message-State: ALoCoQnAEflRRSwuGZofJAJ0FB2aRrrI7VrWoc/IfaGUSF5P5DKG1ssaSXliXRonts0gPwSTS71u X-Received: by 10.66.192.35 with SMTP id hd3mr2003844pac.36.1446644810202; Wed, 04 Nov 2015 05:46:50 -0800 (PST) Received: from [10.0.1.3] (p5231-ipngn5001hodogaya.kanagawa.ocn.ne.jp. [153.220.164.231]) by smtp.gmail.com with ESMTPSA id uy1sm2226754pac.39.2015.11.04.05.46.48 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 04 Nov 2015 05:46:49 -0800 (PST) From: "Roland Dobbins" To: dots Date: Wed, 04 Nov 2015 22:46:47 +0900 Message-ID: <2EA42E2D-5947-480C-9B68-1A2E1A54CE51@arbor.net> In-Reply-To: <7655ac73d854468aa94d24e0f95f25b9@XCH-RCD-017.cisco.com> References: <20151103194312.594948115.52080.45702@sandvine.com> <56397209.1070404@cisco.com> <5639741A.80408@mykolab.com> <20151104054115.594948115.42583.45842@sandvine.com> <22DE5166-2B69-40C2-B0A6-AF28A12FFAC3@arbor.net> <51e93e365612449eab800c682cbc7e80@XCH-RCD-017.cisco.com> <3921fe1ddd1543d1a7ca28777c6ff24b@XCH-RCD-017.cisco.com> <0A8ED500-AB4D-43B5-A0D5-6B9118574EE2@arbor.net> <7655ac73d854468aa94d24e0f95f25b9@XCH-RCD-017.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5164) Archived-At: Subject: Re: [Dots] Using Diameter transport for DOTS? 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, 04 Nov 2015 13:46:52 -0000 On 4 Nov 2015, at 22:26, Tirumaleswar Reddy (tireddy) wrote: > https://tools.ietf.org/html/draft-reddy-dots-transport-01#section-4 > discusses SOS. HTTP seems to be precisely the sort of chatty thing we'd like to avoid, does it not? ----------------------------------- Roland Dobbins From nobody Wed Nov 4 05:56:25 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 7CF471B2FBD for ; Wed, 4 Nov 2015 05:56:24 -0800 (PST) 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 9s7q2W8zc7VP for ; Wed, 4 Nov 2015 05:56:23 -0800 (PST) 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 5A22B1B2FAE for ; Wed, 4 Nov 2015 05:56:23 -0800 (PST) Received: by pasz6 with SMTP id z6so55515001pas.2 for ; Wed, 04 Nov 2015 05:56:23 -0800 (PST) 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=66eJt8pXIiSCwAmZPbzYzcXA7wPo53Rh4RKje3YCcVc=; b=jypHFZSU6F5emEw27NUP0A+SC6cG1pgNi72zok8e1+jEbrKKEAWjdccEobDRIz8Ecj u8j7mVqvC2X7mCT17qwyz2cgp1y1Xh3UwMW09uOf6EhQv1tpkgvZ+G8uYwC5EZr1ZwYF 4qRJ7nvGFXMWHPoPoYlz+ilSp4MxCOkhhRWNk= 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=66eJt8pXIiSCwAmZPbzYzcXA7wPo53Rh4RKje3YCcVc=; b=DuU41CWf2y/Kz4dFmPPRJZEcdt9W8HDVd7F66Tcsl3SQTQQWh1D2+6yXb1PZ2D0x1H PQn7QVmvJ1ZY6NMXiiZoaMu9cOpvEFta/9xGaSD3p7Sdm60/qSAv6jJV2RU1PshAxiWq JaIkBtT8wz6ahe3+3qHOJmTB5sCVUtlQWbA6nqOeB+CYPu4KgPlSMv/aBAFOtkeXjZ2R tXUFZM0gQymVEl5nBOzhoO8tJrmWgTOEUWXxw9km8wM0ogIn6/gw/Bw7edgc3I8M9AXF 5PYP2DzcFMo5NkhPajD5+TiChz9qyC7XbViRuT247S/nR9/GArMKTiSS1Sb6wmgkmPvB //dg== X-Gm-Message-State: ALoCoQnfrUrUi7NdTdESAv+tb9627+U/D+rTtNfxFAP0abeoqXvyc9fJ/v47ycfQUDV+Px47uzzC X-Received: by 10.68.106.130 with SMTP id gu2mr2016576pbb.98.1446645382961; Wed, 04 Nov 2015 05:56:22 -0800 (PST) Received: from [10.0.1.3] (p5231-ipngn5001hodogaya.kanagawa.ocn.ne.jp. [153.220.164.231]) by smtp.gmail.com with ESMTPSA id ir5sm2348197pbc.13.2015.11.04.05.56.21 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 04 Nov 2015 05:56:22 -0800 (PST) From: "Roland Dobbins" To: "dots@ietf.org" Date: Wed, 04 Nov 2015 22:56:19 +0900 Message-ID: In-Reply-To: References: <20151103194312.594948115.52080.45702@sandvine.com> <56397209.1070404@cisco.com> <5730f98c87df41179715cdff49503c86@XCH-RCD-017.cisco.com> <2880D1B0-BE00-4B87-9763-AA55B024F286@arbor.net> <5639CF67.5070501@spritelink.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5164) Archived-At: Subject: Re: [Dots] Using Diameter transport for DOTS? 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, 04 Nov 2015 13:56:24 -0000 On 4 Nov 2015, at 22:37, Tirumaleswar Reddy (tireddy) wrote: > If all the above steps are performed then why can't the DOTS client > cannot perform DTLS handshake with the DOTS server as pre-provisioning > step ? Because all the above is stuff that gets configured on the mitigation service request side and doesn't involve a bunch of chatty bidirectional comms. > DOTS client also needs to configured with the DOTS server domain/IP > addresses and DOTS client needs to be configured with certificates or > SPKI fingerprint etc. to validate the DOTS server identity. That's covered under 'appropriate DOTS peering and authentication information', which doesn't involve a bunch of chatty bidirectional comms. Certificates and PKI are a big no-no for this kind of application. They can't be readily obtained/provisioned/relied upon during an attack which is in-band in terms of the available communications paths to/from those working to establish relief via upstream mitigation service. Those who've been directly affected any kind of operationally-significant DDoS attack and observed its effect on communications across the affected links/paths/topologies can testify that relying on any kind of complex communications interactions to take place during an attack isn't an optimal strategy. ----------------------------------- Roland Dobbins From nobody Wed Nov 4 06:00: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 30B271B2FE0 for ; Wed, 4 Nov 2015 06:00:15 -0800 (PST) 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 KbrPQRZ0cP8H for ; Wed, 4 Nov 2015 06:00:14 -0800 (PST) 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 2876D1B2FDF for ; Wed, 4 Nov 2015 06:00:14 -0800 (PST) Received: by padhx2 with SMTP id hx2so46103172pad.1 for ; Wed, 04 Nov 2015 06:00:13 -0800 (PST) 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=608nrYK1TtJdcc0uE9Ex5ze/1wIsbya1DXLE6ffpwnU=; b=VgxuGmH1fwR3f0IKHUEixsxRJsdAu4O+X0vRGAKFn+Qm/Ue1QPTNUrqQzXG1ikAefF JlQ/5XilJv30oUz5ueqmmunPeC4jNGsexZQkAh2fPQj3UJg+mj6/1h+FhmCPkhqG3x0p VC6TcJSrPSV6AwfmuoQZHal+fipPbUSqiFZMc= 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=608nrYK1TtJdcc0uE9Ex5ze/1wIsbya1DXLE6ffpwnU=; b=CBCtApSpP8VJHkrp2SPJn0gz6U9QZV0RyrAJDoDWfDchRMz4fiu6+Aqb68s7LDcS69 NFgRM41tjUVQ7KjptpolyFJt479fr0pCxhWq+5uzhrNNcnafKKCMVi94OL3xWmuPFfkb kVAuBHO3hoD7XBmZIK8FAhUQZ8Gk+xuJ17NmBuhMdpayOZlGuElwJiQEUCbZlW9D2hst 8LxwTL6RUEHFxPcQkuPmKcotQt+8v+5QEzMExxASKbqxfnJueSXzGmJRsiUHys80xxMk 7ZDuq64CFsktU2O6lIW9oe4dfEqDVMKTunSiSHsQWccQfrUM6Piim6PBWw5saJubSyS/ jn4w== X-Gm-Message-State: ALoCoQkCkcOy8sHezuhTcmgF41xm6My2P1svIvrAtaRUtafWL4qO2jd8OL1y7x1exTkleEB/cVsT X-Received: by 10.66.142.229 with SMTP id rz5mr1997286pab.96.1446645613481; Wed, 04 Nov 2015 06:00:13 -0800 (PST) Received: from [10.0.1.3] (p5231-ipngn5001hodogaya.kanagawa.ocn.ne.jp. [153.220.164.231]) by smtp.gmail.com with ESMTPSA id bc2sm2380511pbd.2.2015.11.04.06.00.12 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 04 Nov 2015 06:00:12 -0800 (PST) From: "Roland Dobbins" To: "dots@ietf.org" Date: Wed, 04 Nov 2015 23:00:05 +0900 Message-ID: <2C231A65-F611-4822-9EDF-C989E80E1F40@arbor.net> In-Reply-To: References: <20151103194312.594948115.52080.45702@sandvine.com> <56397209.1070404@cisco.com> <5730f98c87df41179715cdff49503c86@XCH-RCD-017.cisco.com> <2880D1B0-BE00-4B87-9763-AA55B024F286@arbor.net> <5639CF67.5070501@spritelink.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5164) Archived-At: Subject: Re: [Dots] Using Diameter transport for DOTS? 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, 04 Nov 2015 14:00:15 -0000 On 4 Nov 2015, at 22:56, Roland Dobbins wrote: > Those who've been directly affected any kind of > operationally-significant DDoS attack and observed its effect on > communications across the affected links/paths/topologies can testify > that relying on any kind of complex communications interactions to > take place during an attack isn't an optimal strategy. Typing this out has made me realize that if we end up going with something like D/TLS, we're probably going to need an en clair communications mode for use when the necessary crypto handshaking and key exchanges and whatnot aren't possible due to adverse network conditions. ----------------------------------- Roland Dobbins From nobody Wed Nov 4 06:15:07 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 09AC81B301D for ; Wed, 4 Nov 2015 06:15:06 -0800 (PST) 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 hhEBYx0Rkh0H for ; Wed, 4 Nov 2015 06:15:04 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BEF51B301C for ; Wed, 4 Nov 2015 06:15:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=922; q=dns/txt; s=iport; t=1446646504; x=1447856104; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=dX0VdSFJvD/Tv4VEL77yDavg6bZZt2XjhsSzUZFgNLY=; b=VOkorbi+GoVTvulJmhYbUZpNHNfo3//VddBAZwcgIut5L8SwH692Tn0Y yoOmTNLtfhrVNAiJHY3qqnFre9J9Y4Fk2yoPWJsHn18ozVn7qxIsguGj+ 92+r0TRUueUu7ROXIIVXdBf/+jX/vxKSJGVHDjExK8PeyMHztCxda18ho w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AMAgCXETpW/4ENJK1egztTbwa9PwENgV0XCoVyAoE9OBQBAQEBAQEBgQqENQEBAQQBAQE3NBcEAgEIDgMEAQEBHgkHJwsUCQgCBAESCIgmDcFHAQEBAQEBAQEBAQEBAQEBAQEBAQEBFASGVYR+iTgFh0SPBAGFHId/nEcBHwEBQoQEcoQtgQcBAQE X-IronPort-AV: E=Sophos;i="5.20,243,1444694400"; d="scan'208";a="43769611" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-4.cisco.com with ESMTP; 04 Nov 2015 14:15:03 +0000 Received: from XCH-RCD-018.cisco.com (xch-rcd-018.cisco.com [173.37.102.28]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id tA4EF3hk023946 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 Nov 2015 14:15:03 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-RCD-018.cisco.com (173.37.102.28) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 4 Nov 2015 08:15:03 -0600 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; Wed, 4 Nov 2015 08:15:03 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Roland Dobbins , dots Thread-Topic: [Dots] Using Diameter transport for DOTS? Thread-Index: AdEWb+LjKy2VsZZAT7KTysuTEiK/GQAbbfaAAABO0wAABbh9AAAAxNiAAAFnaoAAAIHKAAAMJL2w//+6tICAAF9V0P//7GYAgABga6D//6o0gIAAXVCA Date: Wed, 4 Nov 2015 14:15:03 +0000 Message-ID: References: <20151103194312.594948115.52080.45702@sandvine.com> <56397209.1070404@cisco.com> <5639741A.80408@mykolab.com> <20151104054115.594948115.42583.45842@sandvine.com> <22DE5166-2B69-40C2-B0A6-AF28A12FFAC3@arbor.net> <51e93e365612449eab800c682cbc7e80@XCH-RCD-017.cisco.com> <3921fe1ddd1543d1a7ca28777c6ff24b@XCH-RCD-017.cisco.com> <0A8ED500-AB4D-43B5-A0D5-6B9118574EE2@arbor.net> <7655ac73d854468aa94d24e0f95f25b9@XCH-RCD-017.cisco.com> <2EA42E2D-5947-480C-9B68-1A2E1A54CE51@arbor.net> In-Reply-To: <2EA42E2D-5947-480C-9B68-1A2E1A54CE51@arbor.net> 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.51.190] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Using Diameter transport for DOTS? 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, 04 Nov 2015 14:15:06 -0000 > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Roland Dobbins > Sent: Wednesday, November 04, 2015 7:17 PM > To: dots > Subject: Re: [Dots] Using Diameter transport for DOTS? >=20 > On 4 Nov 2015, at 22:26, Tirumaleswar Reddy (tireddy) wrote: >=20 > > https://tools.ietf.org/html/draft-reddy-dots-transport-01#section-4 > > discusses SOS. >=20 > HTTP seems to be precisely the sort of chatty thing we'd like to avoid, d= oes it > not ? If you review the above draft, the REST message fits within MTU and it's a = simple request/response. COAP also uses REST with some changes for constrai= ned devices and constrained networks. -Tiru >=20 > ----------------------------------- > Roland Dobbins >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Wed Nov 4 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 6FCBF1B3050 for ; Wed, 4 Nov 2015 06:24:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 AXUcleDf2q40 for ; Wed, 4 Nov 2015 06:24:35 -0800 (PST) Received: from Mail2.SpriteLink.NET (Mail2.SpriteLink.NET [195.182.5.83]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53D331B305D for ; Wed, 4 Nov 2015 06:24:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by Mail2.SpriteLink.NET (Postfix) with ESMTP id D4B29261848 for ; Wed, 4 Nov 2015 15:24:32 +0100 (CET) X-Virus-Scanned: amavisd-new at SpriteLink.NET Received: from Mail2.SpriteLink.NET ([195.182.5.83]) by localhost (Mail2.SpriteLink.NET [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDro16d6ZzzK for ; Wed, 4 Nov 2015 15:24:30 +0100 (CET) Received: from Kristians-MacBook-Pro.local (c-1a95e253.041-205-73746f13.cust.bredbandsbolaget.se [83.226.149.26]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: kristian@spritelink.net) by Mail2.SpriteLink.NET (Postfix) with ESMTPSA id C8ADE261846 for ; Wed, 4 Nov 2015 15:24:30 +0100 (CET) To: dots@ietf.org References: <20151103194312.594948115.52080.45702@sandvine.com> <56397209.1070404@cisco.com> <5730f98c87df41179715cdff49503c86@XCH-RCD-017.cisco.com> <2880D1B0-BE00-4B87-9763-AA55B024F286@arbor.net> <5639CF67.5070501@spritelink.net> From: Kristian Larsson Message-ID: <563A151E.6070201@spritelink.net> Date: Wed, 4 Nov 2015 15:24:30 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.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] Using Diameter transport for DOTS? 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, 04 Nov 2015 14:24:37 -0000 On 04/11/15 14:04, Roland Dobbins wrote: > On 4 Nov 2015, at 18:27, Kristian Larsson wrote: > >> When and how would DOTS come into play? > > The mitigation provider instructs the organization seeking DDoS > mitigation services to enter the appropriate DOTS peering and > authentication information into their DOTS-capable > mitigator/device/service/app, it registers and describes the properties > to be protected, auto-provisioning on the mitigation provider side takes > place, and situationally-appropriate mitigation is initiated. > > This is a much better scenario than fumbling around trying to get all > this information via voice from organizations - even the largest of the > large - who can't properly articulate what servers/services/applications > they're running, what their network access policies are (or ought to be, > based on what they're running), etc. I like the scenario you are describing, essentially removing verbal communication between humans and instead relying on structured data transfer between DOTS capable devices. However, I think there is a big difference between the preparations that typically takes place pre-attack and the actions taken when a customer calls while under an attack. I'm sure you are familiar with the scenarios. A distraught customer calls in and wants help as they are currently under attack, or maybe they are calling their ISP because there is "a problem" with their Internet connection, i.e. they haven't even realized it's an attack. What happens today is that the ticket is sent to the DDoS operations teams, someone takes a look at flow records to identify the attack and then starts a mitigation with guesstimated countermeasure settings. It's not perfect and might have negative impact on legitimate traffic but it's better than the attack keeping all the customers services down. I have a hard time believing that we, as a provider of DDoS mitigation service, could get away with answering the customer that they have to install a DOTS client, configure it and start it up for us to initiate a mitigation for them. Technically it will difficult for them to download the DOTS client due to their congested Internet link. It will be difficult for them to configure it without any experience and only then do we arrive at the topic currently being discussed, ie sending SOS / Mitigation service request. Of these three steps I think sending SOS, regardless of transport, is the most likely to succeed. To top it off, the customer likely won't be very happy having had to install and configure things while under extreme pressure. But, keeping to the intent of avoiding verbal communication, perhaps an out of band method, that the customer can reach from a device that is separate from their production network, could be used to input basic data. It could be as minimal as a web page that the customer reaches from their mobile phone and inputs their production networks IP address ranges or more information, if they have it. It could follow the same data models used in DOTS, just with a different encapsulation / transport protocol. Is this feasible? Out of scope? We don't care? I'm brainstorming at this point. Kind regards, Kristian. -- Level 60 Network Automation Paladin at DT / TeraStream [AS2792] From nobody Wed Nov 4 06:26: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 840681B3071 for ; Wed, 4 Nov 2015 06:26:48 -0800 (PST) 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 XfwE9KNJKsXG for ; Wed, 4 Nov 2015 06:26:46 -0800 (PST) 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 BDBCB1B3074 for ; Wed, 4 Nov 2015 06:26:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2580; q=dns/txt; s=iport; t=1446647206; x=1447856806; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=LshBfZX7MMHXTqtRHKCO1TJHRsD/tlr2ZkcKGrtcBjw=; b=jJMF24/rejnmjlKh3shCNrOBB6Cb8EienEFBIEoBD7h7lh2Vr38CksZU t3Wvg1Ri04+GmzbNNHlrTgsuCo2XMQfAd0lHpAeP4Sg/ifvIEh1DuBoKD EZz+gwbewkUU+8Pb4Ul3D72P3r3WE6laKrdJ/zkMZGfiAixmYiuRT4h6E U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AMAgANFTpW/51dJa1VCYM7U28GvT8BDYFdFwqFcgKBPTgUAQEBAQEBAYEKhDUBAQEDAQEBATc0FwQCAQgOAwQBAQEeCQcnCxQJCAIEARIIiB4IDcFnAQEBAQEBAQEBAQEBAQEBAQEBAQEBFASGVYR+hDERhHYFh0SPBAGNG5xHAR8BAUKEBHKDbCUcgQcBAQE X-IronPort-AV: E=Sophos;i="5.20,243,1444694400"; d="scan'208";a="204284662" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-4.cisco.com with ESMTP; 04 Nov 2015 14:26:46 +0000 Received: from XCH-ALN-016.cisco.com (xch-aln-016.cisco.com [173.36.7.26]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id tA4EQjSd014420 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 Nov 2015 14:26:45 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-ALN-016.cisco.com (173.36.7.26) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 4 Nov 2015 08:26:45 -0600 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; Wed, 4 Nov 2015 08:26:45 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Roland Dobbins , "dots@ietf.org" Thread-Topic: [Dots] Using Diameter transport for DOTS? Thread-Index: AdEWb+LjKy2VsZZAT7KTysuTEiK/GQAbbfaAAAvQTcD//7H/AIAAXsuAgAA84oCAAF33AP//sGOAgABfLmA= Date: Wed, 4 Nov 2015 14:26:45 +0000 Message-ID: References: <20151103194312.594948115.52080.45702@sandvine.com> <56397209.1070404@cisco.com> <5730f98c87df41179715cdff49503c86@XCH-RCD-017.cisco.com> <2880D1B0-BE00-4B87-9763-AA55B024F286@arbor.net> <5639CF67.5070501@spritelink.net> In-Reply-To: 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.51.190] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Using Diameter transport for DOTS? 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, 04 Nov 2015 14:26:48 -0000 > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Roland Dobbins > Sent: Wednesday, November 04, 2015 7:26 PM > To: dots@ietf.org > Subject: Re: [Dots] Using Diameter transport for DOTS? >=20 > On 4 Nov 2015, at 22:37, Tirumaleswar Reddy (tireddy) wrote: >=20 > > If all the above steps are performed then why can't the DOTS client > > cannot perform DTLS handshake with the DOTS server as pre-provisioning > > step ? >=20 > Because all the above is stuff that gets configured on the mitigation ser= vice > request side and doesn't involve a bunch of chatty bidirectional comms. >=20 > > DOTS client also needs to configured with the DOTS server domain/IP > > addresses and DOTS client needs to be configured with certificates or > > SPKI fingerprint etc. to validate the DOTS server identity. >=20 > That's covered under 'appropriate DOTS peering and authentication > information', which doesn't involve a bunch of chatty bidirectional comms= . >=20 > Certificates and PKI are a big no-no for this kind of application. They = can't be > readily obtained/provisioned/relied upon during an attack which is in-ban= d > in terms of the available communications paths to/from those working to > establish relief via upstream mitigation service. DOTS client and DOTS server could be in different administrative domains, w= e will have to figure out the trust model. If it's not PKI then pre-shared = keys, raw public keys etc. can also be used with (D)TLS for mutual authenti= cation b/w DOTS peers. What alternative mechanism are you proposing for authentication ? >=20 > Those who've been directly affected any kind of operationally-significant > DDoS attack and observed its effect on communications across the affected > links/paths/topologies can testify that relying on any kind of complex > communications interactions to take place during an attack isn't an optim= al > strategy. I am not proposing any complex communication, DOTS client and server do (D)= TLS handshake during non-attack times and just need 0-RTT proposed in TLS 1= .3 or use (D)TLS session without session resumption to signal SOS. (D)TLS s= ession resumption involves 1-RTT before SOS message can be conveyed. The fi= rst TLS handshake in TLS 1.3 takes 1 RTT (for full handshake). -Tiru >=20 > ----------------------------------- > Roland Dobbins >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Wed Nov 4 06:45:23 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 DDFCA1B30CB for ; Wed, 4 Nov 2015 06:45:22 -0800 (PST) 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 5Au8Rm8Igtwv for ; Wed, 4 Nov 2015 06:45:21 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 480C21B30DC for ; Wed, 4 Nov 2015 06:45:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4073; q=dns/txt; s=iport; t=1446648317; x=1447857917; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=9qk98OtBH5l6Ivw98MBOLOaAWX+E3/3HJCr24+Ho7AI=; b=fdyWKo0o4b1FYV6uYciK+EkeYW9F9l4kGNy4Zvso5CTJeB7LJuJh18H+ 0G5PyJGE5xLegk7bRRPn9prxDOKU768ZGlx8qSedTFepb32cFZbTBzMPD mNvr+AHM6JYXg6u4cWVJ25ggQxRMxYPqgFqYq/tz1XUHIG+/ogU0DmnLo g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BGBQDQGDpW/5pdJa1UCoM7U28GvU6BXRcKhXICgT05EwEBAQEBAQGBCoQ1AQEBAwEBAQE3NBcEAgEIEQQBAQEeCQcnCxQJCAIEAQkJCIgeCA3BcwEBAQEBAQEBAQEBAQEBAQEBAQEBARQEhlWDeIEGhDAYhHAFlkgBhRyHf5xHASIBQIQEcoQtgQcBAQE X-IronPort-AV: E=Sophos;i="5.20,243,1444694400"; d="scan'208";a="43862440" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 04 Nov 2015 14:45:12 +0000 Received: from XCH-RCD-017.cisco.com (xch-rcd-017.cisco.com [173.37.102.27]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id tA4EjBXt029712 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 Nov 2015 14:45:11 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-RCD-017.cisco.com (173.37.102.27) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 4 Nov 2015 08:45:11 -0600 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; Wed, 4 Nov 2015 08:45:11 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Kristian Larsson , "dots@ietf.org" Thread-Topic: [Dots] Using Diameter transport for DOTS? Thread-Index: AdEWb+LjKy2VsZZAT7KTysuTEiK/GQAbbfaAAAvQTcD//7H/AIAAXsuAgAA84oCAABY6AIAAXxHw Date: Wed, 4 Nov 2015 14:45:11 +0000 Message-ID: <09986f36407f414e8dbeed6589862b06@XCH-RCD-017.cisco.com> References: <20151103194312.594948115.52080.45702@sandvine.com> <56397209.1070404@cisco.com> <5730f98c87df41179715cdff49503c86@XCH-RCD-017.cisco.com> <2880D1B0-BE00-4B87-9763-AA55B024F286@arbor.net> <5639CF67.5070501@spritelink.net> <563A151E.6070201@spritelink.net> In-Reply-To: <563A151E.6070201@spritelink.net> 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.51.190] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Using Diameter transport for DOTS? 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, 04 Nov 2015 14:45:23 -0000 > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Kristian Larsson > Sent: Wednesday, November 04, 2015 7:55 PM > To: dots@ietf.org > Subject: Re: [Dots] Using Diameter transport for DOTS? >=20 > On 04/11/15 14:04, Roland Dobbins wrote: > > On 4 Nov 2015, at 18:27, Kristian Larsson wrote: > > > >> When and how would DOTS come into play? > > > > The mitigation provider instructs the organization seeking DDoS > > mitigation services to enter the appropriate DOTS peering and > > authentication information into their DOTS-capable > > mitigator/device/service/app, it registers and describes the > > properties to be protected, auto-provisioning on the mitigation > > provider side takes place, and situationally-appropriate mitigation is > initiated. > > > > This is a much better scenario than fumbling around trying to get all > > this information via voice from organizations - even the largest of > > the large - who can't properly articulate what > > servers/services/applications they're running, what their network > > access policies are (or ought to be, based on what they're running), et= c. >=20 > I like the scenario you are describing, essentially removing verbal > communication between humans and instead relying on structured data > transfer between DOTS capable devices. >=20 > However, I think there is a big difference between the preparations that > typically takes place pre-attack and the actions taken when a customer ca= lls > while under an attack. >=20 > I'm sure you are familiar with the scenarios. A distraught customer calls= in > and wants help as they are currently under attack, or maybe they are call= ing > their ISP because there is "a problem" with their Internet connection, i.= e. > they haven't even realized it's an attack. >=20 > What happens today is that the ticket is sent to the DDoS operations team= s, > someone takes a look at flow records to identify the attack and then star= ts a > mitigation with guesstimated countermeasure settings. It's not perfect an= d > might have negative impact on legitimate traffic but it's better than the= attack > keeping all the customers services down. >=20 > I have a hard time believing that we, as a provider of DDoS mitigation se= rvice, > could get away with answering the customer that they have to install a DO= TS > client, configure it and start it up for us to initiate a mitigation for = them. >=20 > Technically it will difficult for them to download the DOTS client due to= their > congested Internet link. It will be difficult for them to configure it wi= thout any > experience and only then do we arrive at the topic currently being discus= sed, > ie sending SOS / Mitigation service request. Of these three steps I think > sending SOS, regardless of transport, is the most likely to succeed. >=20 > To top it off, the customer likely won't be very happy having had to inst= all > and configure things while under extreme pressure. >=20 > But, keeping to the intent of avoiding verbal communication, perhaps an o= ut > of band method, that the customer can reach from a device that is separat= e > from their production network, could be used to input basic data. It coul= d be > as minimal as a web page that the customer reaches from their mobile > phone and inputs their production networks IP address ranges or more > information, if they have it. It could follow the same data models used i= n > DOTS, just with a different encapsulation / transport protocol. Is this > feasible? Out of scope? We don't care? I'm brainstorming at this point. It makes sense and are discussed in sections 4.1.5 and 4.1.6 https://tools.= ietf.org/html/draft-ietf-dots-use-cases-00.=20 -Tiru >=20 > Kind regards, > Kristian. >=20 > -- > Level 60 Network Automation Paladin at DT / TeraStream [AS2792] >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Wed Nov 4 06:53:01 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 E9CB21B3104 for ; Wed, 4 Nov 2015 06:53:00 -0800 (PST) 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 kWkOITO9G5u1 for ; Wed, 4 Nov 2015 06:52:59 -0800 (PST) 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 391911B30FE for ; Wed, 4 Nov 2015 06:52:59 -0800 (PST) Received: by ykba4 with SMTP id a4so75520220ykb.3 for ; Wed, 04 Nov 2015 06:52:58 -0800 (PST) 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=WlTmQzr+KlUbQKQkPHAprlk+uNHxE2LxkEGA1B6aHsg=; b=ycqE1nnnAebfvU0yc9KT1odhoPZzfNC6ZKMNWKDxcCN3kklvM4k6NPCC+uUoO76EIN asf3kzo+NDBt2I9hXHujAIxuT2OGysjQv0CwF4NuUnOC/zwu5DB8UYRY2XIHOb6S82ZA InycWdu3fHXsBn4nV0UQS9uDFIEQ2jlk2Dz8eECBCaVF2As9Wt0v7VkDTb0kSMMru3pa v/W3NcA4Bds2RynsYooLoksqkYZw9XtxsfpqSlb9QFhoxcm2/n3l1JbtbvXCn31iFxJ8 T2qiAd62gkYR6j3MUYMYQulwzNaHNM6jBh1i+ezXmA0PsiT6IcK0CYbAWg/NnM+kY4U9 pKMw== X-Received: by 10.31.190.205 with SMTP id o196mr2223596vkf.120.1446648778499; Wed, 04 Nov 2015 06:52:58 -0800 (PST) Received: from [172.20.2.201] ([65.200.157.66]) by smtp.gmail.com with ESMTPSA id r23sm1034884vke.1.2015.11.04.06.52.56 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Nov 2015 06:52:56 -0800 (PST) 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: Wed, 4 Nov 2015 09:52:56 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <33BCB1AC-BC4F-4EC3-BF54-9D91FD9C2789@gmail.com> References: <20151103194312.594948115.52080.45702@sandvine.com> <56397209.1070404@cisco.com> <5730f98c87df41179715cdff49503c86@XCH-RCD-017.cisco.com> <2880D1B0-BE00-4B87-9763-AA55B024F286@arbor.net> <5639CF67.5070501@spritelink.net> To: Roland Dobbins Archived-At: Cc: "dots@ietf.org" Subject: Re: [Dots] Using Diameter transport for DOTS? 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, 04 Nov 2015 14:53:01 -0000 Sent from my iPhone > On Nov 4, 2015, at 8:56 AM, Roland Dobbins wrote: >=20 >> On 4 Nov 2015, at 22:37, Tirumaleswar Reddy (tireddy) wrote: >>=20 >> If all the above steps are performed then why can't the DOTS client canno= t perform DTLS handshake with the DOTS server as pre-provisioning step ? >=20 > Because all the above is stuff that gets configured on the mitigation serv= ice request side and doesn't involve a bunch of chatty bidirectional comms. >=20 >> DOTS client also needs to configured with the DOTS server domain/IP addre= sses and DOTS client needs to be configured with certificates or SPKI finger= print etc. to validate the DOTS server identity. >=20 > That's covered under 'appropriate DOTS peering and authentication informat= ion', which doesn't involve a bunch of chatty bidirectional comms. >=20 > Certificates and PKI are a big no-no for this kind of application. They c= an't be readily obtained/provisioned/relied upon during an attack which is i= n-band in terms of the available communications paths to/from those working t= o establish relief via upstream mitigation service. You should look at the work in ACME for backup solutions to certificate prov= isioning and negotiations. This thread has focused on solutions and not requirements. I fear that this= will result in poor selection with requirements not fully considered. I also didn't buy the argument earlier that you don't need to worry about Mi= TM, making the LISP solution ok. ACME won't be as secure as pre-provisioned= connections, but would be an option to fill the gap for emergency situation= s, OS after that. =20 Maybe a separate thread on requirements would help. Kathleen =20 >=20 > Those who've been directly affected any kind of operationally-significant D= DoS attack and observed its effect on communications across the affected lin= ks/paths/topologies can testify that relying on any kind of complex communic= ations interactions to take place during an attack isn't an optimal strategy= . >=20 > ----------------------------------- > Roland Dobbins >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Wed Nov 4 07:12: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 68A251B30D6 for ; Wed, 4 Nov 2015 07:12:00 -0800 (PST) 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 mHJfb3Rnx7_X for ; Wed, 4 Nov 2015 07:11:59 -0800 (PST) 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 294731B3161 for ; Wed, 4 Nov 2015 07:11:59 -0800 (PST) Received: by pasz6 with SMTP id z6so57154496pas.2 for ; Wed, 04 Nov 2015 07:11:58 -0800 (PST) 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=vLXIuxt1cp2//f5FrQlZIgBbL5CiiBXkUeRdeb2Vxb0=; b=IqI1QEcGIPZ08H3+n3sirs9z1BQ6cl1tjDAf+wX/7bEZaEYVs4mULXVh+Op0PcABKp v+t5FYtYebsp9SvFECszHaID3lojYuaorEPI9yjcroUquHGDuNLDKyh3xB3A5O5YJ9R9 SczKyWxccPEmKbKFGbHQ2aIds5rv//quGeW14= 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=vLXIuxt1cp2//f5FrQlZIgBbL5CiiBXkUeRdeb2Vxb0=; b=WqbseMrqBObT3Kd+jModKgdctCD3j7+hlU3/i+++9faLji1eDdFQCDpnNkkQPBkNYW QAh/K/B4BHAl5I94AUJGt37VfLoouY3Hb2eDM2u8xf1UjnOpvj1dfIxlzY93Z5SBLzuo bx2HBJXqModnFHFzQHW8/JaqKpEqdd9Yo/k6aP0ZYZ9jpBb3trBtBX27NO8XBePHGHz3 2PpffizImp1neHsDigaMw+zCTPU8pysFd2Dlp3rmNRKnKUf+C3fjbtY+ztBotjhHPHjB zaFyh9acPIsoTA3Hk567sDog+Xvnz+0kc35dOUjMuwCFSfUSYO1EwtmUxYvJmFUqYzim YKvw== X-Gm-Message-State: ALoCoQksu3I6y24lBD4kCQ8Q3Ae6x6WVDDNbEFtK4+q7m3niIdP+GVnBqx509uKyiK6FHvF248ES X-Received: by 10.68.197.67 with SMTP id is3mr2369251pbc.89.1446649918247; Wed, 04 Nov 2015 07:11:58 -0800 (PST) Received: from [10.0.1.3] (p5231-ipngn5001hodogaya.kanagawa.ocn.ne.jp. [153.220.164.231]) by smtp.gmail.com with ESMTPSA id yg2sm2589047pbb.79.2015.11.04.07.11.56 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 04 Nov 2015 07:11:57 -0800 (PST) From: "Roland Dobbins" To: "dots@ietf.org" Date: Thu, 05 Nov 2015 00:11:50 +0900 Message-ID: In-Reply-To: <33BCB1AC-BC4F-4EC3-BF54-9D91FD9C2789@gmail.com> References: <20151103194312.594948115.52080.45702@sandvine.com> <56397209.1070404@cisco.com> <5730f98c87df41179715cdff49503c86@XCH-RCD-017.cisco.com> <2880D1B0-BE00-4B87-9763-AA55B024F286@arbor.net> <5639CF67.5070501@spritelink.net> <33BCB1AC-BC4F-4EC3-BF54-9D91FD9C2789@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5164) Archived-At: Subject: Re: [Dots] Using Diameter transport for DOTS? 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, 04 Nov 2015 15:12:00 -0000 On 4 Nov 2015, at 23:52, Kathleen Moriarty wrote: > You should look at the work in ACME for backup solutions to > certificate provisioning and negotiations. Symmetrical shared-secret is much more operationally flexible than anything to do with certificates in the ops space; we also can't depend upon a PKI system being reachable and available during an attack. ACME is new to me - I'll go check it out, thanks! > This thread has focused on solutions and not requirements. I fear > that this will result in poor selection with requirements not fully > considered. This is almost a sidebar discussion to the main effort, which is focused on requirements derived from use-cases. It doesn't hurt to kibitz a bit ahead of ourselves, in this regard. Getting tsvwg involved at this early stage is somewhat distracting, IMHO, and has led to a lot of this on-list discussion. It seems to me that collaboration with tsvwg will be much more effective and a more efficient use of their time once we have our requirements solidified. > I also didn't buy the argument earlier that you don't need to worry > about MiTM, making the LISP solution ok. DH MITM isn't a big risk for this application, IMHO, as it's a highly monitored, special-purpose communications channel with a predetermined set of participants. I'm not religious on this issue, just pointing out that the crypto risk model for DOTS is quite a bit different than that of a general-purpose communications channel with lots of participant dynamism. > ACME won't be as secure as pre-provisioned connections, but would be > an option to fill the gap for emergency situations, OS after that. Will look into it, thanks! ----------------------------------- Roland Dobbins From nobody Wed Nov 4 07:20: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 62C221B3181 for ; Wed, 4 Nov 2015 07:20:16 -0800 (PST) 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 4FIAwjodcVdM for ; Wed, 4 Nov 2015 07:20:15 -0800 (PST) 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 C3CEF1B3179 for ; Wed, 4 Nov 2015 07:20:14 -0800 (PST) Received: by ykek133 with SMTP id k133so77488305yke.2 for ; Wed, 04 Nov 2015 07:20:14 -0800 (PST) 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=U0Hjgy3J6GtEJXGh/iLYbGRE+WA0LWEa1SG/BQ+inAU=; b=HcCXPn7gnXBOEvk9hzcmuXvdOXrOTV7/eDVdcvpHsDQHaIJb4rnTPfeOovjsF/rh6K YXdeKPI3cUc92GZk0sYSZIRgV4giaExvJ9eo28PAviC0+nP2Q4pqkLXZVZm/Hr6deZCg lXt3Gh4f6G8uQT++cSZZDuCywZ79wYifSMxxp+gVZybcxPp4r1pEljQ2oEPi5XeYTWoZ wUbx+pJSI0oqOZ+NiIBocO/RXcrFpdzRVV3/E9NAPw3Ka7+Ba5YqgBbB9LnVHPKAlJlM Xu1Uu9vVQxIbOczWTMeNCXvqXZPVxln5IzH041LsKLHf9kDSP7E6+S9bX+rFr/JiE3fT XqeA== X-Received: by 10.31.180.131 with SMTP id d125mr2323495vkf.15.1446650413838; Wed, 04 Nov 2015 07:20:13 -0800 (PST) Received: from [172.20.2.201] ([65.200.157.66]) by smtp.gmail.com with ESMTPSA id g16sm1104612vke.11.2015.11.04.07.20.12 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Nov 2015 07:20:12 -0800 (PST) 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: Wed, 4 Nov 2015 10:20:11 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <11576124-FEDF-49DC-8EB0-E77D9B9F2AAF@gmail.com> References: <20151103194312.594948115.52080.45702@sandvine.com> <56397209.1070404@cisco.com> <5730f98c87df41179715cdff49503c86@XCH-RCD-017.cisco.com> <2880D1B0-BE00-4B87-9763-AA55B024F286@arbor.net> <5639CF67.5070501@spritelink.net> <33BCB1AC-BC4F-4EC3-BF54-9D91FD9C2789@gmail.com> To: Roland Dobbins Archived-At: Cc: "dots@ietf.org" Subject: Re: [Dots] Using Diameter transport for DOTS? 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, 04 Nov 2015 15:20:16 -0000 Sent from my iPhone > On Nov 4, 2015, at 10:11 AM, Roland Dobbins wrote: >=20 >> On 4 Nov 2015, at 23:52, Kathleen Moriarty wrote: >>=20 >> You should look at the work in ACME for backup solutions to certificate p= rovisioning and negotiations. >=20 > Symmetrical shared-secret is much more operationally flexible than anythin= g to do with certificates in the ops space; we also can't depend upon a PKI s= ystem being reachable and available during an attack. >=20 > ACME is new to me - I'll go check it out, thanks! >=20 >> This thread has focused on solutions and not requirements. I fear that t= his will result in poor selection with requirements not fully considered. >=20 > This is almost a sidebar discussion to the main effort, which is focused o= n requirements derived from use-cases. It doesn't hurt to kibitz a bit ahea= d of ourselves, in this regard. Agreed, I wasn't saying that. >=20 > Getting tsvwg involved at this early stage is somewhat distracting, IMHO, a= nd has led to a lot of this on-list discussion. It seems to me that collabo= ration with tsvwg will be much more effective and a more efficient use of th= eir time once we have our requirements solidified. I disagree and think DOTS can benefit from the experience of TSV before a di= rection is selected. >=20 >> I also didn't buy the argument earlier that you don't need to worry about= MiTM, making the LISP solution ok. >=20 > DH MITM isn't a big risk for this application, IMHO, as it's a highly moni= tored, special-purpose communications channel with a predetermined set of pa= rticipants. I'm not convinced and don't think this is a good argument in terms of the cu= rrent threat landscape. >=20 > I'm not religious on this issue, just pointing out that the crypto risk mo= del for DOTS is quite a bit different than that of a general-purpose communi= cations channel with lots of participant dynamism. We try not to define new protocols that are not secure. It was already stat= ed that end-to-end crypto was needed, I don't see how you could justify doin= g something that's weak. >=20 >> ACME won't be as secure as pre-provisioned connections, but would be an o= ption to fill the gap for emergency situations, OS after that. >=20 > Will look into it, thanks! Layering this I think would be better than accepting less than secure for al= l connections. Kathleen=20 >=20 > ----------------------------------- > Roland Dobbins >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Wed Nov 4 07:38:43 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 DE4931B31E8 for ; Wed, 4 Nov 2015 07:38:41 -0800 (PST) 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 TYgMnVXn6E-L for ; Wed, 4 Nov 2015 07:38:40 -0800 (PST) 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 E55771B31F5 for ; Wed, 4 Nov 2015 07:38:32 -0800 (PST) Received: by pacdm15 with SMTP id dm15so31885681pac.3 for ; Wed, 04 Nov 2015 07:38:32 -0800 (PST) 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=pu3Su4Obzn5GY6NhKcKCAdaISxKVyAbU+nQtu1nj/zs=; b=Ieyz/TZIgk8CmW21Uko1JvgOVmXCESYgfdm1GeMJRrfb75ehgO3wCm1PpHf1shjk6a XA/vhHJNriul0rJSnXJ+eVayYKguM3956Lw1711A7ATjPmGMpzMj80xaJudcyDsFA4Cj vjGNjNKO5UVuJ8vu0bIaJQiPWg58zhIcQO+8w= 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=pu3Su4Obzn5GY6NhKcKCAdaISxKVyAbU+nQtu1nj/zs=; b=l+Qt4g7TIk3n5Dqicp3islRtOAVs456kqdh9AvqoDdbH9YEFj3Fi29E3HOajnXUqHi iNhO/RUgn4/HLr+71mVsRpbeFnrNfKGcOuCto/2BNqL0EZsUAsWKK7fyFyf7mn9H9PzP npz8zBIG/FOSZRYhh5HN7tUiszcL/besCKX6F+RQsAmB50++EWX4L+z9iOcr53VICkm7 dhyTKTXXgS+3ULrWYIKiE+49D2ncedfT/VRhGYbYTHwTGvFE47sAUd3vunGDQ/C36emr NBkADn+bQbZECJgNzdWCpa/JMY9f4rhL8OvZ4ZrPO/JRiyGWeux6wFp4Y0gPSQ3hiJc/ JNbg== X-Gm-Message-State: ALoCoQncVwm/EPEtcCNeZMC77CQxojIlorGyzZkap3tRA+e0UgfNhgc0u2Em0WK+zNV3r4lYcXqL X-Received: by 10.68.197.67 with SMTP id is3mr2523852pbc.89.1446651512411; Wed, 04 Nov 2015 07:38:32 -0800 (PST) Received: from [10.0.1.3] (p5231-ipngn5001hodogaya.kanagawa.ocn.ne.jp. [153.220.164.231]) by smtp.gmail.com with ESMTPSA id d13sm2765988pbu.20.2015.11.04.07.38.30 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 04 Nov 2015 07:38:31 -0800 (PST) From: "Roland Dobbins" To: "dots@ietf.org" Date: Thu, 05 Nov 2015 00:38:28 +0900 Message-ID: <2735AA95-8B84-4BD4-835F-2A3773F66E38@arbor.net> In-Reply-To: <11576124-FEDF-49DC-8EB0-E77D9B9F2AAF@gmail.com> References: <20151103194312.594948115.52080.45702@sandvine.com> <56397209.1070404@cisco.com> <5730f98c87df41179715cdff49503c86@XCH-RCD-017.cisco.com> <2880D1B0-BE00-4B87-9763-AA55B024F286@arbor.net> <5639CF67.5070501@spritelink.net> <33BCB1AC-BC4F-4EC3-BF54-9D91FD9C2789@gmail.com> <11576124-FEDF-49DC-8EB0-E77D9B9F2AAF@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5164) Archived-At: Subject: Re: [Dots] Using Diameter transport for DOTS? 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, 04 Nov 2015 15:38:42 -0000 On 5 Nov 2015, at 0:20, Kathleen Moriarty wrote: > I disagree and think DOTS can benefit from the experience of TSV > before a direction is selected. It will be helpful to be able to present the tsvwg folks with a more definitive set of requirements, IMHO. This goes back to solutions vs. requirements. ;> > I'm not convinced and don't think this is a good argument in terms of > the current threat landscape. OK. Again, I'm not religious on this issue. But understanding that the threat model for DOTS is somewhat different than a general-purpose communications channel with lots of dynamic participation will help us scope our crypto requirements more closely in relation to the actual operational environment. > We try not to define new protocols that are not secure. It was > already stated that end-to-end crypto was needed, I don't see how you > could justify doing something that's weak. Nobody wants to do something that's weak, concur 100%. At the same time, the crypto portion of DOTS is actually the least-significant part, compared to the actual functionality of DOTS, the transport characteristics, auth, and so forth. End-to-end crypto is something everyone/everything 'requires' in the current environment, often for non-technical reasons, so it's something we absolutely must do. For DOTS, authentication is actually a lot more important than encryption; but, as they sort of go hand-in-hand, we end up with both. > Layering this I think would be better than accepting less than secure > for all connections Understood, will read up on ACME. ----------------------------------- Roland Dobbins From nobody Wed Nov 4 07:42: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 83C441B31ED for ; Wed, 4 Nov 2015 07:42:15 -0800 (PST) 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 wT5DRsI-r3NV for ; Wed, 4 Nov 2015 07:42:14 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D933D1B31E4 for ; Wed, 4 Nov 2015 07:42:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=695; q=dns/txt; s=iport; t=1446651733; x=1447861333; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=QIu5Tejoaj2pB+MbK+81u9Djh/49gdhxZX6i2x2Slrc=; b=esI8l7a6cZOt5jjOfoTlnMP8L8QwZL51CKuT+H1136bMA651JTDcDqFJ +/ie2PUN+cfjWOJel2dey+4VMI7PRC9C+CqrcqNAXPxXWq0gIMkicJbmj uGAVYsfHae+hxiwcKR6rjxBLxdYv3vcYGo5lKbocZ5zG4YIqtqWXVLGIo Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ALAgDSJjpW/5xdJa1egztTdbsUghsBDYFdIYVyAoE+OBQBAQEBAQEBgQqENQEBAQMBOj8FCwIBCDYQMiUCBAENDROICwgNwhMBAQEBAQEBAQEBAQEBAQEBAQEBAQEUBIZVhH6JOAWWSAGFHId/nEcBHwEBQoQEhR+BBwEBAQ X-IronPort-AV: E=Sophos;i="5.20,243,1444694400"; d="scan'208";a="204852917" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-5.cisco.com with ESMTP; 04 Nov 2015 15:42:13 +0000 Received: from XCH-ALN-020.cisco.com (xch-aln-020.cisco.com [173.36.7.30]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id tA4FgDS3010367 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 Nov 2015 15:42:13 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-ALN-020.cisco.com (173.36.7.30) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 4 Nov 2015 09:42:12 -0600 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; Wed, 4 Nov 2015 09:42:12 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Kathleen Moriarty , Roland Dobbins Thread-Topic: [Dots] Using Diameter transport for DOTS? Thread-Index: AdEWb+LjKy2VsZZAT7KTysuTEiK/GQAbbfaAAAvQTcD//7H/AIAAXsuAgAA84oCAAF33AP//sGOAgAAP0QCAAFik8A== Date: Wed, 4 Nov 2015 15:42:12 +0000 Message-ID: <8d0cccac1aea455b83d6323bf0f42620@XCH-RCD-017.cisco.com> References: <20151103194312.594948115.52080.45702@sandvine.com> <56397209.1070404@cisco.com> <5730f98c87df41179715cdff49503c86@XCH-RCD-017.cisco.com> <2880D1B0-BE00-4B87-9763-AA55B024F286@arbor.net> <5639CF67.5070501@spritelink.net> <33BCB1AC-BC4F-4EC3-BF54-9D91FD9C2789@gmail.com> In-Reply-To: <33BCB1AC-BC4F-4EC3-BF54-9D91FD9C2789@gmail.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.51.190] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "dots@ietf.org" Subject: Re: [Dots] Using Diameter transport for DOTS? 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, 04 Nov 2015 15:42:15 -0000 > I also didn't buy the argument earlier that you don't need to worry about > MiTM, making the LISP solution ok. ACME won't be as secure as pre- > provisioned connections, but would be an option to fill the gap for > emergency situations, OS after that. Agreed. MiTM is an important attack to consider for DOTS, DDOS is typically= a targeted attack and attackers most likely would be interested to break t= he DOTS signaling protocol.=20 >=20 > Maybe a separate thread on requirements would help. Requirements OP-002, G-006 and G-007 in https://tools.ietf.org/html/draft-i= etf-dots-requirements-00 discuss requirements to handle MiTM attack.=20 -Tiru >=20 > Kathleen From nobody Wed Nov 4 07:50: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 1629A1B2F26 for ; Wed, 4 Nov 2015 07:50:29 -0800 (PST) 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 I3eFJWPTB84b for ; Wed, 4 Nov 2015 07:50:28 -0800 (PST) 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 01DB41B2F1F for ; Wed, 4 Nov 2015 07:50:28 -0800 (PST) Received: by padhx2 with SMTP id hx2so48403189pad.1 for ; Wed, 04 Nov 2015 07:50:27 -0800 (PST) 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=qOjViw145/6yXHJGFIeZeF8Lh9O27nPbXdntifVctqI=; b=ZamWRM+j2eZYmNeAO72MrUf8JX74pMLoYQ4EaxxxTbh5Y2J79nELWdft7qKvmgWVUM RKpSF7fykuqV3rXVXv//sjDWwP0fDaNOROw3K1Fxzxc9WJg6EezSR9BROFyZybt6+gjn +HVfTkHq1u2KKhyBl6rl+PuUsbYONiLtow2L0= 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=qOjViw145/6yXHJGFIeZeF8Lh9O27nPbXdntifVctqI=; b=QXWhmn8tKts8yt5ol5eiVGzUQDgFWOkWIEmnulyImwRVzNLbzXdRB1/knlCrFBLoPZ VtPaxi75ZeTjUxuHfvGprRqXLD5BEPkqe/zalzpuQWB8wLX0rpb5mw0azE7cUNLFzq1n ibjl75k5F5q67tovT+KTVsx+oPHUDfIVe/l12l9p25XqgPv2Oy3YDfm35RA0YPhhsbtU OeuQ19odbiBcV7KQzWVnR+M12Ojs15dYISobnxj8Pa353pylhsv3su5cyrKlkimj1AlU tVS3Huo1HS3vMDK45TvErDmFO1vohKAjuKtnk8FhX3DSKNggO8eVPB2rmRMIngFq0ifa 6efQ== X-Gm-Message-State: ALoCoQnAq3hILghf6RofsHrwp86+Sxz3QiEYM2T9m1AgU6a7jd0a9PmpfeM0hFs+0fo7xIIUlDgB X-Received: by 10.66.136.11 with SMTP id pw11mr2616031pab.87.1446652226915; Wed, 04 Nov 2015 07:50:26 -0800 (PST) Received: from [10.0.1.3] (p5231-ipngn5001hodogaya.kanagawa.ocn.ne.jp. [153.220.164.231]) by smtp.gmail.com with ESMTPSA id v13sm2779023pbs.51.2015.11.04.07.50.25 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 04 Nov 2015 07:50:26 -0800 (PST) From: "Roland Dobbins" To: dots Date: Thu, 05 Nov 2015 00:50:24 +0900 Message-ID: <28F71328-0D92-49CE-B78B-FF65CE97C329@arbor.net> In-Reply-To: References: <20151103194312.594948115.52080.45702@sandvine.com> <56397209.1070404@cisco.com> <5639741A.80408@mykolab.com> <20151104054115.594948115.42583.45842@sandvine.com> <22DE5166-2B69-40C2-B0A6-AF28A12FFAC3@arbor.net> <51e93e365612449eab800c682cbc7e80@XCH-RCD-017.cisco.com> <3921fe1ddd1543d1a7ca28777c6ff24b@XCH-RCD-017.cisco.com> <0A8ED500-AB4D-43B5-A0D5-6B9118574EE2@arbor.net> <7655ac73d854468aa94d24e0f95f25b9@XCH-RCD-017.cisco.com> <2EA42E2D-5947-480C-9B68-1A2E1A54CE51@arbor.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5164) Archived-At: Subject: Re: [Dots] Using Diameter transport for DOTS? 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, 04 Nov 2015 15:50:29 -0000 On 4 Nov 2015, at 23:15, Tirumaleswar Reddy (tireddy) wrote: > If you review the above draft, the REST message fits within MTU and > it's a simple request/respons I see that, thanks. 576 or below is nice, but 1476 or below is generally OK, these days, FYI. ----------------------------------- Roland Dobbins From nobody Wed Nov 4 08:03: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 34D661B3252 for ; Wed, 4 Nov 2015 08:03:16 -0800 (PST) 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 QLmlx3AKurQH for ; Wed, 4 Nov 2015 08:03:14 -0800 (PST) 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 CB1BD1B3251 for ; Wed, 4 Nov 2015 08:03:14 -0800 (PST) Received: by padhx2 with SMTP id hx2so48688567pad.1 for ; Wed, 04 Nov 2015 08:03:14 -0800 (PST) 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=U8M+VmeKkptldoaHS2mAPSDa4nQ0EfcSM9oO5XAgqa8=; b=KBf4DosNbYBxQ3W85GdVJyWanW+V9j+45cb5xeZIhBnbJyAvIuCvi2GwHzUxYXiggl MwYvv2QVDRvXroYnbbG9DTFafI2P8V+FpsJdiJdJaX+3OHifbcbZpTRTFm4Vs7yRHIXr WjtI7O4I1bpkMjl5stUbbqlqAgtkYuQzxeUFk= 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=U8M+VmeKkptldoaHS2mAPSDa4nQ0EfcSM9oO5XAgqa8=; b=eZ7LhA2ZwshQ3cYI7XHCdu7YMqm0IS/JNaM/qkZDC7nFIJM+6nt1ZXPlToXABDwCy+ BvHvlAnwe9IUvImp3zKZyqC9zPUYBLnp/bteAybmf9sY4rkKJGKON6qev17l8EjLCWSS AwrASEbSrQQipZITHidAjhgQWLDllGBt18vOFDvyn8lWqhvtds3ZQMuNKyxS32Cp4H5A dhPCM4NK+HhgEX+EdisBKGmL+m6NU9WNeYQPp7wY6UEpIAwnoWF3xEyZyFhlhiwsl3QW jYNwDZ8UWZHJlI8yoW6or5JU9WTJeDnJuZ0e91DxiFz9TUn5AJdI6HCxg44g5vn+1wsp F42g== X-Gm-Message-State: ALoCoQmeneE8Sn1LsHsNoPYLK+WUs+EocTWfpnB1+SseAniRhcJE/DesibZDdrd+xTUkT9NEAGJ7 X-Received: by 10.68.175.66 with SMTP id by2mr2700023pbc.3.1446652994219; Wed, 04 Nov 2015 08:03:14 -0800 (PST) Received: from [10.0.1.3] (p5231-ipngn5001hodogaya.kanagawa.ocn.ne.jp. [153.220.164.231]) by smtp.gmail.com with ESMTPSA id qy7sm2809775pab.37.2015.11.04.08.03.13 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 04 Nov 2015 08:03:13 -0800 (PST) From: "Roland Dobbins" To: dots@ietf.org Date: Thu, 05 Nov 2015 01:03:11 +0900 Message-ID: <3DBD4F43-0F5F-4C1C-8D01-B22D03A3DF44@arbor.net> In-Reply-To: <563A151E.6070201@spritelink.net> References: <20151103194312.594948115.52080.45702@sandvine.com> <56397209.1070404@cisco.com> <5730f98c87df41179715cdff49503c86@XCH-RCD-017.cisco.com> <2880D1B0-BE00-4B87-9763-AA55B024F286@arbor.net> <5639CF67.5070501@spritelink.net> <563A151E.6070201@spritelink.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5164) Archived-At: Subject: Re: [Dots] Using Diameter transport for DOTS? 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, 04 Nov 2015 16:03:16 -0000 On 4 Nov 2015, at 23:24, Kristian Larsson wrote: > However, I think there is a big difference between the preparations > that typically takes place pre-attack and the actions taken when a > customer calls while under an attack. Yes - removing as much ambiguity as possible from provisioning > I'm sure you are familiar with the scenarios. Painfully so. ;> > What happens today is that the ticket is sent to the DDoS operations > teams, someone takes a look at flow records to identify the attack and > then starts a mitigation with guesstimated countermeasure settings. Yes - and this is a highly suboptimal approach, as the general organizing principle for successful DDoS attack mitigation is actually centered around the properties being protected. And, yes, there are certainly alterations one must make based on variations in attack methodology and evolving operational circumstances over the duration of an attack, in many cases. But suboptimal countermeasure selection and tuning based on a) an incomplete (or total lack of) understanding of the properties being protected and/or b) attack methodology is a significant of DDoS mitigation today. > I have a hard time believing that we, as a provider of DDoS mitigation > service, could get away with answering the customer that they have to > install a DOTS client, configure it and start it up for us to initiate > a mitigation for them. The idea is that the DOTS client is *already there* - just input a few params shared out-of-band over the phone or whatever, and it's done. ;> As an operational person handling DDoS attacks for lo these many years, I understand completely the scenarios and pressures you describe. Pervasive DOTS is intended to greatly improve the operational situation, reducing response times, improving mitigation efficacy, et. al. ----------------------------------- Roland Dobbins From nobody Wed Nov 4 08:08: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 16C091B3251 for ; Wed, 4 Nov 2015 08:08:51 -0800 (PST) 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 g-0nAgg7dDNe for ; Wed, 4 Nov 2015 08:08:49 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC9431B3271 for ; Wed, 4 Nov 2015 08:08:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=886; q=dns/txt; s=iport; t=1446653329; x=1447862929; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=GuhzupABcISOkVzhXMp4CXp10echK01RoVKMOStQ8z4=; b=WqZ9iyFJGEcsVqvxZpYVPj6zal4Ub6UAGlXvgwjx+XpWYuriUo6tjkJ7 NBMT/xIqdBfB8OMc5JlwoBb7+sQ7pJSC2oTBJpKIEDB43yozy+ZvkBOSY wQHMNePOLkPRZD7KGE0puTDaUac1TqPkeVQJVVeGjxxiuWJLS5CZ4J6ic M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AMAgCILDpW/4kNJK1egztTbwa9LwENgV0XCoVyAoE/OBQBAQEBAQEBgQqENQEBAQQBAQE3NBcEAgEIDgMEAQEBHgkHJwsUCQgCBAESCIgmDcIRAQEBAQEBAQEBAQEBAQEBAQEBAQEBFASGVYR+iTgFh0SPBAGNG5xHAR8BAUKEBHKELYEHAQEB X-IronPort-AV: E=Sophos;i="5.20,243,1444694400"; d="scan'208";a="204862360" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-5.cisco.com with ESMTP; 04 Nov 2015 16:08:48 +0000 Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id tA4G8m1r031777 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 Nov 2015 16:08:48 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 4 Nov 2015 10:08:48 -0600 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; Wed, 4 Nov 2015 10:08:48 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Roland Dobbins , dots Thread-Topic: [Dots] Using Diameter transport for DOTS? Thread-Index: AdEWb+LjKy2VsZZAT7KTysuTEiK/GQAbbfaAAABO0wAABbh9AAAAxNiAAAFnaoAAAIHKAAAMJL2w//+6tICAAF9V0P//7GYAgABga6D//6o0gIAAXVCA///FOQAADBAyMA== Date: Wed, 4 Nov 2015 16:08:48 +0000 Message-ID: References: <20151103194312.594948115.52080.45702@sandvine.com> <56397209.1070404@cisco.com> <5639741A.80408@mykolab.com> <20151104054115.594948115.42583.45842@sandvine.com> <22DE5166-2B69-40C2-B0A6-AF28A12FFAC3@arbor.net> <51e93e365612449eab800c682cbc7e80@XCH-RCD-017.cisco.com> <3921fe1ddd1543d1a7ca28777c6ff24b@XCH-RCD-017.cisco.com> <0A8ED500-AB4D-43B5-A0D5-6B9118574EE2@arbor.net> <7655ac73d854468aa94d24e0f95f25b9@XCH-RCD-017.cisco.com> <2EA42E2D-5947-480C-9B68-1A2E1A54CE51@arbor.net> <28F71328-0D92-49CE-B78B-FF65CE97C329@arbor.net> In-Reply-To: <28F71328-0D92-49CE-B78B-FF65CE97C329@arbor.net> 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.51.190] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Using Diameter transport for DOTS? 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, 04 Nov 2015 16:08:51 -0000 > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Roland Dobbins > Sent: Wednesday, November 04, 2015 9:20 PM > To: dots > Subject: Re: [Dots] Using Diameter transport for DOTS? >=20 > On 4 Nov 2015, at 23:15, Tirumaleswar Reddy (tireddy) wrote: >=20 > > If you review the above draft, the REST message fits within MTU and > > it's a simple request/respons >=20 > I see that, thanks. 576 or below is nice, but 1476 or below is generally= OK, > these days, FYI. Yes, the DOTS client will have to restrict the SOS message length if Path M= TU is unknown ,and It's 576 for IPv4 and 1280 for IPv6. -Tiru >=20 > ----------------------------------- > Roland Dobbins >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Wed Nov 4 08: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 E4E171B3278 for ; Wed, 4 Nov 2015 08:09:46 -0800 (PST) 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 DgYcTBZHc7a6 for ; Wed, 4 Nov 2015 08:09:45 -0800 (PST) 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 988B51B325D for ; Wed, 4 Nov 2015 08:09:45 -0800 (PST) Received: by pabfh17 with SMTP id fh17so56868346pab.0 for ; Wed, 04 Nov 2015 08:09:45 -0800 (PST) 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=92nmZLMoD/AE4Ywx6W1+fkCiV8Nin3AmdxXbbTXhSic=; b=gQRRcsYYYoDBK6S+WthGLAs31xAhaGSsdmVFXo8QF8d+L6RRCQu4WpuO7QkfXc/XoV Q99TD6bSMrwBCy7A/rqse101szufANc9KoiYDQP8zrtCXGdIORrrfPSshDH4Baisj9hi P7L9a1lk8vw/KR3+wj2Bq2ZbwqUWKhOVAuGeQ= 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=92nmZLMoD/AE4Ywx6W1+fkCiV8Nin3AmdxXbbTXhSic=; b=bWCnjUgqIc+RrcjW1UZIEZYJ1890mjP6558CMONHPAIixKV/RssEOD2s31U09j6pvM ooUv7ZhTN22ZEpOEB+YdzhTlMuafVPtROJncB6xSslAxT1cd7VHox2IXBQ4qEXAg7PWJ QTl60jJR6sNm6w/+dBpwo7+ceByM2vel/MSNUzM9PnNMOaIl5gb7/NVXyVf+lpuivDk3 tPpQGlB83cCuHZP4Vh/ptOoYi+EFFafVnoFEo2tserwWf1PjRIrp/e6yMX7JbtRyWmTR MhZ3aqoEaulwC1PoMSOexzBNaQ7t/xJfx0bD5XHZKCscTVFyy+n4dIuu7Hac3pABrQVM 3XBQ== X-Gm-Message-State: ALoCoQkzQ6Q4hZyUi9ViMClamoX6DCyl7lyHKFB1KTf9YP01nshp3odRAkDAWIvUpJyHVwBTozVt X-Received: by 10.68.235.40 with SMTP id uj8mr2706098pbc.95.1446653385124; Wed, 04 Nov 2015 08:09:45 -0800 (PST) Received: from [10.0.1.3] (p5231-ipngn5001hodogaya.kanagawa.ocn.ne.jp. [153.220.164.231]) by smtp.gmail.com with ESMTPSA id oi3sm2852811pbb.53.2015.11.04.08.09.43 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 04 Nov 2015 08:09:44 -0800 (PST) From: "Roland Dobbins" To: "dots@ietf.org" Date: Thu, 05 Nov 2015 01:09:42 +0900 Message-ID: In-Reply-To: <8d0cccac1aea455b83d6323bf0f42620@XCH-RCD-017.cisco.com> References: <20151103194312.594948115.52080.45702@sandvine.com> <56397209.1070404@cisco.com> <5730f98c87df41179715cdff49503c86@XCH-RCD-017.cisco.com> <2880D1B0-BE00-4B87-9763-AA55B024F286@arbor.net> <5639CF67.5070501@spritelink.net> <33BCB1AC-BC4F-4EC3-BF54-9D91FD9C2789@gmail.com> <8d0cccac1aea455b83d6323bf0f42620@XCH-RCD-017.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5164) Archived-At: Subject: Re: [Dots] Using Diameter transport for DOTS? 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, 04 Nov 2015 16:09:47 -0000 On 5 Nov 2015, at 0:42, Tirumaleswar Reddy (tireddy) wrote: > Agreed. MiTM is an important attack to consider for DOTS, It's actually the least important attack to consider. I'm not saying it's unimportant, but in the scheme of things, it doesn't rise to the scale that it does in general-purpose communications systems. > and attackers most likely would be interested to break the DOTS > signaling protocol. If they're even able to be aware of the DOTS signaling, much less send traffic to the DOTS endpoints, it's been implemented incorrectly from an operational and deployment architecture standpoint. If they're in a position to even attempt to MITM this traffic, the reality is that the involved parties have problems technology can't solve. We're edging into movie-plot threat territory, here. ----------------------------------- Roland Dobbins From nobody Wed Nov 4 08:12: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 D52341B3296 for ; Wed, 4 Nov 2015 08:12:52 -0800 (PST) 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 UTFMX8xT-kUp for ; Wed, 4 Nov 2015 08:12:51 -0800 (PST) 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 A9A061B3294 for ; Wed, 4 Nov 2015 08:12:51 -0800 (PST) Received: by pacdm15 with SMTP id dm15so32640642pac.3 for ; Wed, 04 Nov 2015 08:12:51 -0800 (PST) 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=Rb98v+bmEcxceemSSpYOXRC8wjY2T+Ez7K6irMoz3i8=; b=hea/cXF1KD1h97SqVB3yvaWvCHsIiy9U5igXghkezjhq78dng4+Aa7b+m6OPFGupVN dfNoVXAuPbqotPFBGA4+9bEcRHuNU8d8v6Mrmv1Ej5Q1yIy0liclV55827youAD/ooAP fTTFg9hisz0n/ORz7fkZOuhi0dsB1G6Xpnlck= 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=Rb98v+bmEcxceemSSpYOXRC8wjY2T+Ez7K6irMoz3i8=; b=IdfG3eS6VxVWWtLr3hRtvJ8KE2EnNiNTwenag2ASejdLLiupoMaU4hVEV2hDgdyqCl lWA8hvjGNgTHPrK4fAFK6VC14V5GeMuXPf+hiW1zIl/mOd6iEMeWFISL3Iyf4ocdSp+r Vto6w4bmBDg4vhKcPwU1z0goIyp07Zxo405e6K/gXI4RK//Ndk9ulXu74kgSG3EfowIq KB/UhdPmTkzD2o9nJaJWyG86CY+2SYFrrOwDlsk0pJdMGp8BHcFMEfqZOFFHjDA4OTFS aCMSpUM2fbfxgIR1LwsBnGqpx96H+tJ40cMO3JHCAoY1YIRdESD3cua37eXxW/42WjSG 8sGw== X-Gm-Message-State: ALoCoQkAe+mm83cQdZ+13YL1BK28D7/xFZJyXFqe7GZoptqfI+4R0Emb1H3kBwmsM05noyWOpbaZ X-Received: by 10.66.188.49 with SMTP id fx17mr2761905pac.95.1446653571151; Wed, 04 Nov 2015 08:12:51 -0800 (PST) Received: from [10.0.1.3] (p5231-ipngn5001hodogaya.kanagawa.ocn.ne.jp. [153.220.164.231]) by smtp.gmail.com with ESMTPSA id ir4sm2813362pbb.93.2015.11.04.08.12.49 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 04 Nov 2015 08:12:50 -0800 (PST) From: "Roland Dobbins" To: dots Date: Thu, 05 Nov 2015 01:12:43 +0900 Message-ID: In-Reply-To: References: <20151103194312.594948115.52080.45702@sandvine.com> <56397209.1070404@cisco.com> <5639741A.80408@mykolab.com> <20151104054115.594948115.42583.45842@sandvine.com> <22DE5166-2B69-40C2-B0A6-AF28A12FFAC3@arbor.net> <51e93e365612449eab800c682cbc7e80@XCH-RCD-017.cisco.com> <3921fe1ddd1543d1a7ca28777c6ff24b@XCH-RCD-017.cisco.com> <0A8ED500-AB4D-43B5-A0D5-6B9118574EE2@arbor.net> <7655ac73d854468aa94d24e0f95f25b9@XCH-RCD-017.cisco.com> <2EA42E2D-5947-480C-9B68-1A2E1A54CE51@arbor.net> <28F71328-0D92-49CE-B78B-FF65CE97C329@arbor.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5164) Archived-At: Subject: Re: [Dots] Using Diameter transport for DOTS? 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, 04 Nov 2015 16:12:53 -0000 On 5 Nov 2015, at 1:08, Tirumaleswar Reddy (tireddy) wrote: > Yes, the DOTS client will have to restrict the SOS message length if > Path MTU is unknown ,and It's 576 for IPv4 Again, 576 is really too strict for IPv4 on the modern Internet to be a hard-and-fast requirement. It's nice, but shouldn't be a primary design consideration, at least to the degree that it might impede something else that's important. Plus, there's always application-layer message segmentation. ----------------------------------- Roland Dobbins From nobody Wed Nov 4 08:17: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 696D91B329F for ; Wed, 4 Nov 2015 08:17:03 -0800 (PST) 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 jB6yNy2m7JR8 for ; Wed, 4 Nov 2015 08:17:01 -0800 (PST) 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 82E3E1B329B for ; Wed, 4 Nov 2015 08:17:01 -0800 (PST) Received: by ykek133 with SMTP id k133so80593657yke.2 for ; Wed, 04 Nov 2015 08:17:00 -0800 (PST) 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=u3q+PHO8mMmUnyGsR040uW/CB9XkK+tMF4zVsig6PYs=; b=aMMNEQl+QHLGbQCU5vs5KnDt6jHPUhToJk4kdBuOM4CI5oEMpCtt2UYytLyukc/tfi KpFVSQHnhpkUiN0h9y+ELYAsKxCcNayBhK2EEIu4V3Srv0Wq7fPv5qkGW7SK2wC9oiCs Ry82qygeZe7SIlQ8YTXKYkv+deDZgVeTp+42g2K1wHa5t55cEgO+L8nI7RMay7gK3huM YM2nDgRs4J5jZdK46HCOrvvhbwyvbdpgRm8Maz0pwTJ/1yIpzC1aWDra5PlLIMQ/DMbL 9g1uHCObqiOjIf25zisXoiuvxZHcOQWmt2+40nlW/fTOCPCrtDsdIxhGeDIErLw8CGpt FjVw== X-Received: by 10.31.150.142 with SMTP id y136mr2677277vkd.53.1446653820422; Wed, 04 Nov 2015 08:17:00 -0800 (PST) Received: from [172.20.2.201] ([65.200.157.66]) by smtp.gmail.com with ESMTPSA id a21sm1276623vke.10.2015.11.04.08.16.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Nov 2015 08:16:58 -0800 (PST) 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: Wed, 4 Nov 2015 11:16:57 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151103194312.594948115.52080.45702@sandvine.com> <56397209.1070404@cisco.com> <5730f98c87df41179715cdff49503c86@XCH-RCD-017.cisco.com> <2880D1B0-BE00-4B87-9763-AA55B024F286@arbor.net> <5639CF67.5070501@spritelink.net> <33BCB1AC-BC4F-4EC3-BF54-9D91FD9C2789@gmail.com> <8d0cccac1aea455b83d6323bf0f42620@XCH-RCD-017.cisco.com> To: Roland Dobbins Archived-At: Cc: "dots@ietf.org" Subject: Re: [Dots] Using Diameter transport for DOTS? 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, 04 Nov 2015 16:17:03 -0000 Sent from my iPhone > On Nov 4, 2015, at 11:09 AM, Roland Dobbins wrote: >=20 >> On 5 Nov 2015, at 0:42, Tirumaleswar Reddy (tireddy) wrote: >>=20 >> Agreed. MiTM is an important attack to consider for DOTS, >=20 > It's actually the least important attack to consider. >=20 > I'm not saying it's unimportant, but in the scheme of things, it doesn't r= ise to the scale that it does in general-purpose communications systems. >=20 As soon as you deploy a consistent protocol, you'll see attacks like this em= erge more. MiTM is an important consideration as the game will change. >> and attackers most likely would be interested to break the DOTS signaling= protocol. >=20 > If they're even able to be aware of the DOTS signaling, much less send tra= ffic to the DOTS endpoints, it's been implemented incorrectly from an operat= ional and deployment architecture standpoint. >=20 > If they're in a position to even attempt to MITM this traffic, the reality= is that the involved parties have problems technology can't solve. We can do our best and follow BCPs for new protocols. >=20 > We're edging into movie-plot threat territory, here. Not really. Kathleen=20 >=20 > ----------------------------------- > Roland Dobbins >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Wed Nov 4 08:25: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 475541B32B3 for ; Wed, 4 Nov 2015 08:25:54 -0800 (PST) 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 YYQ28vTWmD48 for ; Wed, 4 Nov 2015 08:25:52 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 842D11B32C6 for ; Wed, 4 Nov 2015 08:25:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1237; q=dns/txt; s=iport; t=1446654344; x=1447863944; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=YaKakfYHldCFt5b8yammYzq2U16rKA/LPlgYGovnwvw=; b=IazvdV/kF+742ZhCyRzmWaN4bqpRN+jacafPlNucWTNUWXOwnQa11XB4 ycEMtQFoTyByJ92fPcqrN+nBRoWv5aTEigalDJMuWORk+0Br5SD7lAup0 wbO+OZehBFVHOVUMg1K/XZ2uB7Ie3qXyvGzG1JV2SooPpBg0QSMHRaj5F o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AMAgAsMTpW/5tdJa1egztTbwa9MQENgV0XCoVyAoFAOBQBAQEBAQEBgQqENQEBAQMBAQEBNzQXBAIBCA4DBAEBAR4JBycLFAkIAgQBEgiIHggNwhIBAQEBAQEBAQEBAQEBAQEBAQEBAQEUBIZVhH6JOAWHRI8EAYUch3+cRwEfAQFChARyAYQsgQcBAQE X-IronPort-AV: E=Sophos;i="5.20,243,1444694400"; d="scan'208";a="46756347" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 04 Nov 2015 16:25:43 +0000 Received: from XCH-ALN-017.cisco.com (xch-aln-017.cisco.com [173.36.7.27]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id tA4GPfOS023955 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 Nov 2015 16:25:41 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-ALN-017.cisco.com (173.36.7.27) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 4 Nov 2015 10:25:40 -0600 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; Wed, 4 Nov 2015 10:25:40 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Roland Dobbins , dots Thread-Topic: [Dots] Using Diameter transport for DOTS? Thread-Index: AdEWb+LjKy2VsZZAT7KTysuTEiK/GQAbbfaAAABO0wAABbh9AAAAxNiAAAFnaoAAAIHKAAAMJL2w//+6tICAAF9V0P//7GYAgABga6D//6o0gIAAXVCA///FOQAADBAyMAALSIyAACLwjZA= Date: Wed, 4 Nov 2015 16:25:40 +0000 Message-ID: <93c570530f3947fba2cc06cafbfd8efe@XCH-RCD-017.cisco.com> References: <20151103194312.594948115.52080.45702@sandvine.com> <56397209.1070404@cisco.com> <5639741A.80408@mykolab.com> <20151104054115.594948115.42583.45842@sandvine.com> <22DE5166-2B69-40C2-B0A6-AF28A12FFAC3@arbor.net> <51e93e365612449eab800c682cbc7e80@XCH-RCD-017.cisco.com> <3921fe1ddd1543d1a7ca28777c6ff24b@XCH-RCD-017.cisco.com> <0A8ED500-AB4D-43B5-A0D5-6B9118574EE2@arbor.net> <7655ac73d854468aa94d24e0f95f25b9@XCH-RCD-017.cisco.com> <2EA42E2D-5947-480C-9B68-1A2E1A54CE51@arbor.net> <28F71328-0D92-49CE-B78B-FF65CE97C329@arbor.net> In-Reply-To: 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.51.190] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Using Diameter transport for DOTS? 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, 04 Nov 2015 16:25:54 -0000 > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Roland Dobbins > Sent: Wednesday, November 04, 2015 9:43 PM > To: dots > Subject: Re: [Dots] Using Diameter transport for DOTS? >=20 > On 5 Nov 2015, at 1:08, Tirumaleswar Reddy (tireddy) wrote: >=20 > > Yes, the DOTS client will have to restrict the SOS message length if > > Path MTU is unknown ,and It's 576 for IPv4 >=20 > Again, 576 is really too strict for IPv4 on the modern Internet to be a > hard-and-fast requirement. It's nice, but shouldn't be a primary design > consideration, at least to the degree that it might impede something > else that's important. COAP protocol published recently https://tools.ietf.org/html/rfc7252#sectio= n-4.6 discusses message size limitations if Path MTU is unknown. STUN, TUR= N and DNS protocols already have this limitation (If Path MTU is not perfor= med by the client). -Tiru =20 >=20 > Plus, there's always application-layer message segmentation. >=20 > ----------------------------------- > Roland Dobbins >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Wed Nov 4 08:27: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 53BEB1B32BE for ; Wed, 4 Nov 2015 08:26:10 -0800 (PST) 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=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 3f9FfZtjSOvg for ; Wed, 4 Nov 2015 08:26:06 -0800 (PST) Received: from p3plwbeout24-02.prod.phx3.secureserver.net (p3plsmtp24-02-2.prod.phx3.secureserver.net [68.178.252.184]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6432C1B32B3 for ; Wed, 4 Nov 2015 08:26:04 -0800 (PST) Received: from localhost ([68.178.252.243]) by p3plwbeout24-02.prod.phx3.secureserver.net with bizsmtp id dUS31r0025Fr2Gc01US394; Wed, 04 Nov 2015 09:26:03 -0700 X-SID: dUS31r0025Fr2Gc01 Received: (qmail 3507 invoked by uid 99); 4 Nov 2015 16:26:03 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 67.207.110.172 User-Agent: Workspace Webmail 5.15.9 Message-Id: <20151104092602.48b52fb35c6f209c51bccbb9807b6df0.9a62b33805.wbe@email24.secureserver.net> From: To: "Aaron Falk" , "Wesley Eddy" Date: Wed, 04 Nov 2015 09:26:02 -0700 Mime-Version: 1.0 Archived-At: X-Mailman-Approved-At: Wed, 04 Nov 2015 08:27:55 -0800 Cc: tsvwg@ietf.org, dots@ietf.org Subject: Re: [Dots] =?utf-8?q?=5Btsvwg=5D__Best_transport_selection_during_an_?= =?utf-8?q?attack=3F?= 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, 04 Nov 2015 16:26:10 -0000 Sending an "emergency" notification that you are under a DOS attack via=0AT= CP =0Ais stupidity worthy of victims in a horror movie.=0A=0AIf you are und= er a DOS attack your ability to confirm a TCP connection=0A(or=0ASCTP assoc= iation) is also under attack. Your ability to send the SOS=0Acannot=0Abe de= pendent on you receiving any packets.=0A=0AIf there is an issue of not havi= ng a UDP path to the target then you=0Aneed to=0Aprovision a proxy that is = UDP reachable. OF course that only works until=0Athe=0Aattackers figure out= to attack the proxy as well.=0A=0AThere is not much an attacker can do to = prevent your sending UDP=0Adatagrams,=0Ahowever, other than flooding every = possible recipient. That raises the=0Acost=0Aof a DOS attack from attacking= one server to attacking entire networks,=0Amaking=0Aany such attack far le= ss feasible.=0A=0A=0A From nobody Wed Nov 4 08:42: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 995101B330F for ; Wed, 4 Nov 2015 08:42:26 -0800 (PST) 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 y0GOuxuk3-0k for ; Wed, 4 Nov 2015 08:42:25 -0800 (PST) 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 2E59C1B330C for ; Wed, 4 Nov 2015 08:42:25 -0800 (PST) Received: by pacdm15 with SMTP id dm15so33297898pac.3 for ; Wed, 04 Nov 2015 08:42:24 -0800 (PST) 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=n5o36NSKRcLom3WfFvSRH7KmmAoPH4IpeIqE5UEUUPw=; b=EhC7Kv/G112l9VmQxtPaNcihIt9QZy4hbyi4dJ2ixZJBed3zp781GPpXGxcJM2rVHU AhFbM0eQFPLTvCw/tf33qNjUiOlFMdJ/Iv+Z462hhV6OYwvIxZAifBca8zRzhSC6dDuA Hqdxg9hLwZu8Nw31YwbKq2QPOPBlplYlbafHw= 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=n5o36NSKRcLom3WfFvSRH7KmmAoPH4IpeIqE5UEUUPw=; b=WXwqXASkuBr28p63HzLa04lnpoFyI06nZ86T0YyZMvF7o6a5JDqIRK7/kEIvSJiSQh r8zEMgJ5GHCW13tyaICqGye9ipZTZ3GiHEOUNA6fCeTTU9Rcf5GBDuZxIiSQqGpAvRC0 P11l5lic9h8YmYaPua+P0HPzpKvBIgGqwVR3SsxqxTUDLDA6aTpxZirf2z5cbmc5S26d OgQV9giPEBTfAtVaezHtcCB64wVohop+qGmR/bUsBrHHCcL/E/WbzdRZstceH/TA2LwV PSd8uxjLb4Li2nejAoS6HDXX8R/XI1jBXC+nVp9jWQTdU28t/dLzQqMFizKEl8Ufyucs h0mA== X-Gm-Message-State: ALoCoQlOHitF11B90tsidFsHPZf4ByEelXqh0Usb0/B/YfdTiCaZdD4Q+6qbqA/+iY6aiFZSz77s X-Received: by 10.67.14.101 with SMTP id ff5mr3012771pad.120.1446655344738; Wed, 04 Nov 2015 08:42:24 -0800 (PST) Received: from [10.0.1.3] (p5231-ipngn5001hodogaya.kanagawa.ocn.ne.jp. [153.220.164.231]) by smtp.gmail.com with ESMTPSA id d7sm2970171pas.31.2015.11.04.08.42.23 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 04 Nov 2015 08:42:23 -0800 (PST) From: "Roland Dobbins" To: "dots@ietf.org" Date: Thu, 05 Nov 2015 01:42:21 +0900 Message-ID: In-Reply-To: References: <20151103194312.594948115.52080.45702@sandvine.com> <56397209.1070404@cisco.com> <5730f98c87df41179715cdff49503c86@XCH-RCD-017.cisco.com> <2880D1B0-BE00-4B87-9763-AA55B024F286@arbor.net> <5639CF67.5070501@spritelink.net> <33BCB1AC-BC4F-4EC3-BF54-9D91FD9C2789@gmail.com> <8d0cccac1aea455b83d6323bf0f42620@XCH-RCD-017.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5164) Archived-At: Subject: Re: [Dots] Using Diameter transport for DOTS? 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, 04 Nov 2015 16:42:26 -0000 On 5 Nov 2015, at 1:16, Kathleen Moriarty wrote: > As soon as you deploy a consistent protocol, you'll see attacks like > this emerge more. MiTM is an important consideration as the game will > change. The general nature of routing in the Internet does not, however. I understand where you're coming from. I don't dismiss MITM as unimportant. But it's not the or even a primary attack vector for DOTS itself, and it's unlikely to be so in the foreseeable future, IMHO, due to the nature of the Internet. We must plan for the worst, of course, understood. > We can do our best and follow BCPs for new protocols. Concur 100%. > Not really. If the attackers have the ability to MITM this traffic, then they've already achieved effective control over the networks/systems in question, including the DOTS clients and all network traffic to/from the affected properties, to a degree which renders them situationally omnipotent. Perversely, dedicated out-of-band DOTS signaling, which is highly preferable in terms of ensuring DOTS messages get through under duress, is actually the communications channel most (still highly unlikely, with huge implications if it ever comes to pass) susceptible to MITMing. It won't be nearly as prevalent as in-band signaling, of course. ----------------------------------- Roland Dobbins From nobody Wed Nov 4 08:48: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 73AFB1B3365 for ; Wed, 4 Nov 2015 08:48:27 -0800 (PST) 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 Tb9rT09vkdYo for ; Wed, 4 Nov 2015 08:48:26 -0800 (PST) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::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 15CC71B335C for ; Wed, 4 Nov 2015 08:48:26 -0800 (PST) Received: by padhx2 with SMTP id hx2so49694265pad.1 for ; Wed, 04 Nov 2015 08:48:25 -0800 (PST) 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=y2tQ15X+WT/b9r/sTXHmk+ZE/C8rGaVtlXVk2ks6eas=; b=RzcStCTsaHB+g9SPpUNQH6dL3172iHuXjUyb6BQgA10d1k/B8o/9WKHuYZeD8qZWm/ oUPmJlFTiwSy1POFrY2xRVd/4xvbO2SFfxtfrJe9Bh6hcwvJQr1/4sk4ib67Im14m7mj 0aEo82vZ76Bi7B3MXisv7uD0+0bw5+/vkCrlw= 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=y2tQ15X+WT/b9r/sTXHmk+ZE/C8rGaVtlXVk2ks6eas=; b=gPcbjOQb89G0q8ZoQ8Cw08NozP/yJiWt2IUEpQaVx/0/QZ8yzgbf2PWZKuFccSoqrY iTAMri/hYj2od7DIhAmMqQulzkvXvM0jqbWiKP6uuubtr9e9TxnJJXorZdrOPJ6+yp5F VfN/rHvPrLNRZZ62QTjMgwH8nytAIQxWpqrSb17PRGxP/k/EpQT0qiYpVoMycR27FV/6 t8m7D+9Ufwsy9QfRDf04NAGhkSWSV0hovzCMOX4UaVozCEx1mqxYlrflQPNVJUVgnh8c tX7tShGxz5Wr0oQX6zzUZedjrcoete/PxwE0G2cy+HyXS6pRiJdV3TIjTBi6qgyFZ3xb z9uQ== X-Gm-Message-State: ALoCoQlwmyoDv7x51XG97C5Xv8xYD4IEt/oR/CraUyluCuQCahewOFGMsAHVV3Vnwi41szC2M14D X-Received: by 10.68.173.165 with SMTP id bl5mr2906816pbc.75.1446655705447; Wed, 04 Nov 2015 08:48:25 -0800 (PST) Received: from [10.0.1.3] (p5231-ipngn5001hodogaya.kanagawa.ocn.ne.jp. [153.220.164.231]) by smtp.gmail.com with ESMTPSA id ea1sm2968026pbb.76.2015.11.04.08.48.24 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 04 Nov 2015 08:48:24 -0800 (PST) From: "Roland Dobbins" To: dots@ietf.org Date: Thu, 05 Nov 2015 01:48:22 +0900 Message-ID: <751DC4AB-CDC0-4C91-9567-9D4AC7D1ECB0@arbor.net> In-Reply-To: <20151104092602.48b52fb35c6f209c51bccbb9807b6df0.9a62b33805.wbe@email24.secureserver.net> References: <20151104092602.48b52fb35c6f209c51bccbb9807b6df0.9a62b33805.wbe@email24.secureserver.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5164) Archived-At: Cc: tsvwg@ietf.org Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 04 Nov 2015 16:48:27 -0000 On 5 Nov 2015, at 1:26, cait@asomi.com wrote: > If there is an issue of not having a UDP path to the target then you > need to provision a proxy that is UDP reachable This has already been discussed extensively and is addressed in the requirements draft and the use-cases draft, FYI. > OF course that only works until the attackers figure out to attack the > proxy as well. If attackers can arbitrarily send packets to the DOTS client, DOTS relay, and/or DOTS server, then implementation BCPs aren't being followed. ----------------------------------- Roland Dobbins From nobody Wed Nov 4 09:07: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 BA8F41B36FB for ; Wed, 4 Nov 2015 09:07:31 -0800 (PST) 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 cLLK4yVlJV3A for ; Wed, 4 Nov 2015 09:07:30 -0800 (PST) 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 A0F121B36F2 for ; Wed, 4 Nov 2015 09:07:30 -0800 (PST) Received: by pabfh17 with SMTP id fh17so58153340pab.0 for ; Wed, 04 Nov 2015 09:07:30 -0800 (PST) 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=oWWNzsNCeQr5DOHx+Kfx+uPMVp4nwsMs4a1SHSnYHbU=; b=XKJZI0f/1TUF0ec2qXkz/gwTaQ8uZqp2Kl1kEE7l2ZjwJjHVfTkEe7FVP1/EVkBdhQ 3L8fxEmT8tyIBFGt5F6V3d5KwgxnKBHphTGWlHUlu7DXqSjBjMRSlE65zElEVxyVsenR cc9np5jiB00qtvHSpnea+kPPj0GMuBJLiB0oA= 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=oWWNzsNCeQr5DOHx+Kfx+uPMVp4nwsMs4a1SHSnYHbU=; b=O4c5eAxqKIOCrp/WDlopJ1vxUVLzDyZE9C0Q6xb+la9Bd8HuNoHru36RK+fahmwj6V 8L7ZplQgT04NQM5wRmcTg3m7ZEdJpspnQN3YZQCRi3efDNg74suh0ieqB/sqPp3H66XQ 7GuYdFDWrk83F2Si2M/t3LEOoE5uuAeXmC9tzWrgXo78Gfjl9Q2AgNekxe9yXIp5CkDe QKkAaqNhCiz2PZde1nNSuKwKrNv2Woa3xKyFmGZvOMbF1pIJ6YdtM0Bcjf3z0POBN7xu aQkm08HKHNs+KWOlLiddTg1NqJYvqxlZVC8H8eT3yOXSs3zpWW9lqr5y1s9h8UScV1KF CRlQ== X-Gm-Message-State: ALoCoQmDL0ucenuZkGf6Wowj2PYfvXU0GoazK2Or/gXNpVUWTmA3Yv+Niu2ezHep1fLeDa5N3Qms X-Received: by 10.68.114.1 with SMTP id jc1mr3164732pbb.54.1446656850068; Wed, 04 Nov 2015 09:07:30 -0800 (PST) Received: from [10.0.1.3] (p5231-ipngn5001hodogaya.kanagawa.ocn.ne.jp. [153.220.164.231]) by smtp.gmail.com with ESMTPSA id xu2sm1178564pbb.42.2015.11.04.09.07.28 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 04 Nov 2015 09:07:29 -0800 (PST) From: "Roland Dobbins" To: dots Date: Thu, 05 Nov 2015 02:07:27 +0900 Message-ID: In-Reply-To: <93c570530f3947fba2cc06cafbfd8efe@XCH-RCD-017.cisco.com> References: <20151103194312.594948115.52080.45702@sandvine.com> <56397209.1070404@cisco.com> <5639741A.80408@mykolab.com> <20151104054115.594948115.42583.45842@sandvine.com> <22DE5166-2B69-40C2-B0A6-AF28A12FFAC3@arbor.net> <51e93e365612449eab800c682cbc7e80@XCH-RCD-017.cisco.com> <3921fe1ddd1543d1a7ca28777c6ff24b@XCH-RCD-017.cisco.com> <0A8ED500-AB4D-43B5-A0D5-6B9118574EE2@arbor.net> <7655ac73d854468aa94d24e0f95f25b9@XCH-RCD-017.cisco.com> <2EA42E2D-5947-480C-9B68-1A2E1A54CE51@arbor.net> <28F71328-0D92-49CE-B78B-FF65CE97C329@arbor.net> <93c570530f3947fba2cc06cafbfd8efe@XCH-RCD-017.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5164) Archived-At: Subject: Re: [Dots] Using Diameter transport for DOTS? 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, 04 Nov 2015 17:07:31 -0000 On 5 Nov 2015, at 1:25, Tirumaleswar Reddy (tireddy) wrote: > STUN, TURN and DNS protocols already have this limitation (If Path > MTU is not performed by the client). I'm aware of this. My point is that on the modern Internet, this is overly conservative. 576 or lower is nice, if practical. It is not and should not be considered a primary design constraint. ----------------------------------- Roland Dobbins From nobody Wed Nov 4 10:14: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 228801A6FB9 for ; Wed, 4 Nov 2015 10:14:57 -0800 (PST) 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 JrwrGYbyJpQk for ; Wed, 4 Nov 2015 10:14:55 -0800 (PST) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::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 4B4E71A6F51 for ; Wed, 4 Nov 2015 10:14:55 -0800 (PST) Received: by ykdr3 with SMTP id r3so86739837ykd.1 for ; Wed, 04 Nov 2015 10:14:54 -0800 (PST) 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=nvJvkCi6r7lycoY0ny6MJl0NwFXr4ox3QrupjJnAkYE=; b=WAsVbgkw7mlUv32N4cSqMyLaDe4lY7h0RHLppSl0u7+sP+t9hDD54KTIvcbvth/M/a TW+i74EbCGtg1144DrVSa+KlLNXOp3cR2DMQ5ENp+0RSQ6SLjbGnaqXUuj2qJC27x3Uk EknSwFoxTHVwdF5YzkXPng8Gu+NYzS4RS1T2y5ON6CkwCXj8oHwSI8qTfQNQCGYrpuJl cQiB1wxwolTK9vajjMQu85l46z+WKZB6nInuXW7UGDhJTxQm3240x+e2pq9D6JUt+rLm wGkqxx2BGfzDB/EPky9J6etbaFNphBlW1XoDQcFOaCIqJkgnaPJlBMB/+w23U01wfkYl XyPA== X-Received: by 10.31.52.17 with SMTP id b17mr3200688vka.29.1446660894433; Wed, 04 Nov 2015 10:14:54 -0800 (PST) Received: from [172.20.2.201] ([65.200.157.66]) by smtp.gmail.com with ESMTPSA id u13sm1649044vke.14.2015.11.04.10.14.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Nov 2015 10:14:53 -0800 (PST) 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: Wed, 4 Nov 2015 13:14:51 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3CD47505-5052-4C58-9436-AC53E4B352C8@gmail.com> References: <20151103194312.594948115.52080.45702@sandvine.com> <56397209.1070404@cisco.com> <5730f98c87df41179715cdff49503c86@XCH-RCD-017.cisco.com> <2880D1B0-BE00-4B87-9763-AA55B024F286@arbor.net> <5639CF67.5070501@spritelink.net> <33BCB1AC-BC4F-4EC3-BF54-9D91FD9C2789@gmail.com> <8d0cccac1aea455b83d6323bf0f42620@XCH-RCD-017.cisco.com> To: Roland Dobbins Archived-At: Cc: "dots@ietf.org" Subject: Re: [Dots] Using Diameter transport for DOTS? 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, 04 Nov 2015 18:14:57 -0000 Sent from my iPhone > On Nov 4, 2015, at 11:42 AM, Roland Dobbins wrote: >=20 >> On 5 Nov 2015, at 1:16, Kathleen Moriarty wrote: >>=20 >> As soon as you deploy a consistent protocol, you'll see attacks like this= emerge more. MiTM is an important consideration as the game will change. >=20 > The general nature of routing in the Internet does not, however. >=20 > I understand where you're coming from. I don't dismiss MITM as unimportan= t. But it's not the or even a primary attack vector for DOTS itself, and it= 's unlikely to be so in the foreseeable future, IMHO, due to the nature of t= he Internet. >=20 > We must plan for the worst, of course, understood. >=20 >> We can do our best and follow BCPs for new protocols. >=20 > Concur 100%. >=20 >> Not really. >=20 > If the attackers have the ability to MITM this traffic, then they've alrea= dy achieved effective control over the networks/systems in question, includi= ng the DOTS clients and all network traffic to/from the affected properties,= to a degree which renders them situationally omnipotent. >=20 > Perversely, dedicated out-of-band DOTS signaling, which is highly preferab= le in terms of ensuring DOTS messages get through under duress, is actually t= he communications channel most (still highly unlikely, with huge implication= s if it ever comes to pass) susceptible to MITMing. It won't be nearly as p= revalent as in-band signaling, of course. Just to be clear, your arguments do not convince me despite the persistent m= essages. I don't have time to continue the debate, so my lack of response a= t this time does not signal agreement. Thanks, Kathleen=20 >=20 > ----------------------------------- > Roland Dobbins >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Wed Nov 4 10: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 120AC1A8856 for ; Wed, 4 Nov 2015 10:27:43 -0800 (PST) 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 4UayMrVaVPFc for ; Wed, 4 Nov 2015 10:27:41 -0800 (PST) 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 C327F1A87E2 for ; Wed, 4 Nov 2015 10:27:41 -0800 (PST) Received: by padhx2 with SMTP id hx2so51961411pad.1 for ; Wed, 04 Nov 2015 10:27:41 -0800 (PST) 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=iNaKiv5lHaa3RbfbqeUmEc+TM4NjoRrhAxIM02Pjjog=; b=JamOrKiozYuBu11Zhn2booVQxniRAHMqt7hULmmOToiW0L2rYVdPqslaq3WKt+kjZ5 7IDB8Pm1+rnhXOnXJkLIJPx0IohwHKpDTpJk8O0Re8KUGD+5bLdrXKaEj8kuj9nl/V9J JxeJvtxSgfoAt3VDTb0leMxIgGUfHoqgQUohU= 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=iNaKiv5lHaa3RbfbqeUmEc+TM4NjoRrhAxIM02Pjjog=; b=ZfrqhKrU6DYW8n9cjPNignXAJ+tFXThB6EBAG6kK45Y5QEwilhyuw901ZYAkO5zmyq 8jkq3D2HVfkFo13Ot26y+j/D2OPgNi883mYYKMmW4dl9UJKOnwvd7AFbRvMP1NscVnJn pAWRJNFK30lh3yu9fkDBFpTZlYyxHPC580PgNSnT48hlZgBvqKQpqTvxgD8xn4W4p5CE 0TJAYWomedUCcPRsENKFV9XKlBdKpVU6cwg9AJJopVXwJ12+0FHoXokCegdp2zYLs006 hZysjTvjEVCHKMBBlU0TxK4GlaBl1ob7ZtIZdtPuxrr5uNpZuHX3EaG94fW1l734Tk6V gEQw== X-Gm-Message-State: ALoCoQkbc5XogWbHMELVjHZSGL930SsiqP+chjyRUAesWkdaQ2jHJSNsvEC9mSqQxgjZEV0GmjHl X-Received: by 10.66.136.232 with SMTP id qd8mr3562334pab.24.1446661661257; Wed, 04 Nov 2015 10:27:41 -0800 (PST) Received: from [10.0.1.3] (p5231-ipngn5001hodogaya.kanagawa.ocn.ne.jp. [153.220.164.231]) by smtp.gmail.com with ESMTPSA id qv5sm3298548pbc.71.2015.11.04.10.27.39 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 04 Nov 2015 10:27:40 -0800 (PST) From: "Roland Dobbins" To: "dots@ietf.org" Date: Thu, 05 Nov 2015 03:27:39 +0900 Message-ID: <91444968-43F1-4D86-BBEC-1402D5BFD53C@arbor.net> In-Reply-To: <3CD47505-5052-4C58-9436-AC53E4B352C8@gmail.com> References: <20151103194312.594948115.52080.45702@sandvine.com> <56397209.1070404@cisco.com> <5730f98c87df41179715cdff49503c86@XCH-RCD-017.cisco.com> <2880D1B0-BE00-4B87-9763-AA55B024F286@arbor.net> <5639CF67.5070501@spritelink.net> <33BCB1AC-BC4F-4EC3-BF54-9D91FD9C2789@gmail.com> <8d0cccac1aea455b83d6323bf0f42620@XCH-RCD-017.cisco.com> <3CD47505-5052-4C58-9436-AC53E4B352C8@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5164) Archived-At: Subject: Re: [Dots] Using Diameter transport for DOTS? 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, 04 Nov 2015 18:27:43 -0000 On 5 Nov 2015, at 3:14, Kathleen Moriarty wrote: > Just to be clear, your arguments do not convince me despite the > persistent messages. OK. It doesn't much matter, anyways, as I'm not religious on the subject of DH, LISP crypto, etc. ----------------------------------- Roland Dobbins From nobody Wed Nov 4 11:33: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 490431A8A8B for ; Wed, 4 Nov 2015 11:33:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 gUz5-3ZL7QIy for ; Wed, 4 Nov 2015 11:33:39 -0800 (PST) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::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 DB1F91A8A20 for ; Wed, 4 Nov 2015 11:33:38 -0800 (PST) Received: by ykdr3 with SMTP id r3so90890873ykd.1 for ; Wed, 04 Nov 2015 11:33:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isi_edu.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5xb5j2WGvGwgTLWCGFJrc7BKCp7BSDB3uSK+4KZ7sU0=; b=X5Mcl3v9pTe5gyOXF8tX7zGg6wMErH6S7ZufzkixxfsOuunXOAA4FKzjKIgI7VARVY HxET0+9aKZ79r4Em8YiyKLp5V9e2c9p0c4VrSoHIgPcy3JD4JpJ8Nm7r4SsMa3lqyqx2 GpJSml/VvxuOfZbgKEvZghBPjj+bid/IZB6KgafNt12xjlkY+zwZlLc5mg+WJbj6p2aR 6TtI9qCZP8/gGRCV7nRL4SIneHOWZ0CGz3vH5+u8KrNrdywnQ6h+py3GgO2l+rn+Uvhl nLjQqrEdW33kbdenvCvsYL1uoqkQ0Ox2a+6cgCyLYPp7TMGaiPshkpbGbLxaLfhT/3KI fzLg== 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=5xb5j2WGvGwgTLWCGFJrc7BKCp7BSDB3uSK+4KZ7sU0=; b=P/lk7q8FAgw1NMRIsEx8+XHFtnmXzPXO+EdC0W+u+8c9OBNAO1kJTSOz44U0xTWZGh c9dCMv+/DEBrvAFo9hd3eKJEs/f2X1g7jq4rtD1cQGB8TMEIfaJSPb33P5tVnqNxFqrj IsqvVz70wIIkoSczwzzOw3G82IdWRa9gdw0OvBqFUCC9F7wW7fb+FkdqBjPZaMlVjWB7 JaeFE0bXBRKBPAwjW2Qc3JgrN0SYHOKnfxzamCQSSUYWDCydFjlfa5hwsebG18JpcKCQ oGovCOL6ja4hSMbPs+1TFzWmI7O4TUkdZFmctCccwsbK4UBdSO6GtpOWIEGUUmxcAZjf ralg== X-Gm-Message-State: ALoCoQmRoVpVT0y46fYcnZCljm+kFF5LE4W+5KmmP2l2JxI+za780MMl7M/5vkVdUVKywW/47TBt MIME-Version: 1.0 X-Received: by 10.31.16.162 with SMTP id 34mr3588738vkq.87.1446665618188; Wed, 04 Nov 2015 11:33:38 -0800 (PST) Received: by 10.31.222.129 with HTTP; Wed, 4 Nov 2015 11:33:38 -0800 (PST) In-Reply-To: <5534122E-42C4-4EF0-91EB-69A6A38E5528@arbor.net> References: <5534122E-42C4-4EF0-91EB-69A6A38E5528@arbor.net> Date: Wed, 4 Nov 2015 11:33:38 -0800 Message-ID: From: Jelena Mirkovic To: Roland Dobbins Content-Type: multipart/alternative; boundary=001a1142f51047f4540523bc16fd Archived-At: Cc: "dots@ietf.org" Subject: Re: [Dots] Does DOTS require sneaker-net support? 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, 04 Nov 2015 19:33:40 -0000 --001a1142f51047f4540523bc16fd Content-Type: text/plain; charset=UTF-8 I apologize first for not having read the current draft carefully. Feel free to tell me to go read it if the issue I bring up is addressed there. It seems to me that the critical issue is how requests are authenticated, i.e., how does one prove that they have authority over a given IP space. ... leaving that aside for now .. I see one part missing in this discussion about "network may be too congested to get the message out". One doesn't have to use the network. We all have cell phones, cell networks usually work separately from Internet. One can just use an app on cell phone to contact their ISP. ========================= Jelena Mirkovic Research Faculty USC Information Sciences Institute 4676 Admiralty Way, Suite 1001 Marina del Rey, CA 90292 310-448-9170 On Tue, Nov 3, 2015 at 7:00 PM, Roland Dobbins wrote: > On 4 Nov 2015, at 11:31, Dave Dolson wrote: > > I'm asking because yesterday someone mentioned that occasionally operators >> need to set things up after an attack has begun. >> > > I believe this is actually worthy of consideration - it's an interesting > 'failsafe' approach. We shouldn't spend a lot of time on it just yet, but > should keep it in mind as we progress, IMHO. > > DNS could also be potentially used for this sort of thing. > > ----------------------------------- > Roland Dobbins > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > --001a1142f51047f4540523bc16fd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I apologize first for not having read the current draft ca= refully. Feel free to tell me to go read it if the issue I bring up is addr= essed there. It seems to me that the critical issue is how requests are aut= henticated, i.e., how does one prove that they have authority over a given = IP space.=C2=A0

... leaving that aside for now ..
<= div>
I see one part missing in this discussion about "ne= twork may be too congested to get the message out". One doesn't ha= ve to use the network. We all have cell phones, cell networks usually work = separately from Internet. One can just use an app on cell phone to contact = their ISP.=C2=A0


=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, Nov 3, 2015 at 7:00 PM, Roland Dobbi= ns <rdobbins@arbor.net> wrote:
On 4 Nov 2015, at 11:31, Dave Dolson wrote:

I'm asking because yesterday someone mentioned that occasionally operat= ors need to set things up after an attack has begun.

 I believe this is actually worthy of consideration - it's an interestin= g 'failsafe' approach.=C2=A0 We shouldn't spend a lot of time o= n it just yet, but should keep it in mind as we progress, IMHO.

DNS could also be potentially used for this sort of thing.

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

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

--001a1142f51047f4540523bc16fd-- From nobody Wed Nov 4 16:23: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 9BC311B2A75 for ; Wed, 4 Nov 2015 16:23:37 -0800 (PST) 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 dt1c6ww000GV for ; Wed, 4 Nov 2015 16:23:36 -0800 (PST) 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 634BD1B2A72 for ; Wed, 4 Nov 2015 16:23:35 -0800 (PST) Received: by ykdv3 with SMTP id v3so14058924ykd.0 for ; Wed, 04 Nov 2015 16:23:34 -0800 (PST) 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=mOMpOOkVDxOKpAo395+ZYOkXvxHsSkg06p2Z+QkTA0Q=; b=g+ObDel6tWhlYIVsgSviB2ixLLHVIUwFcaO97sHlQ0K/HeoKZKf/LTnVu4L2xOFMKw FLfyGlpMEqhvI2zTFjOYeQv3HueetgiTQ3PKHh4wh2YK9tVKAjhC10yCLad7ng9NYsgf 5ir7SiGjaDyXvihca7i8sviHyTrvM/c1mkw3jN5u/96Tx+WRqNCTcSoPS41GrLtoT0RT vQM6BVVrQ4XsW9GLXfjqxOfv/PVc2R+RLajHRCPa5eJTK2EFMb2U7U5voJHTSr1RI7bS Ue+qxRr6k1KR+e0iMbbzHM3iHEgUGADfYw6FVnpyeEAPqaBtC5CqgPTda+aWGZI1uyhi bDnA== MIME-Version: 1.0 X-Received: by 10.129.82.18 with SMTP id g18mr3795637ywb.234.1446683014749; Wed, 04 Nov 2015 16:23:34 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.13.202.16 with HTTP; Wed, 4 Nov 2015 16:23:34 -0800 (PST) In-Reply-To: References: <5534122E-42C4-4EF0-91EB-69A6A38E5528@arbor.net> Date: Thu, 5 Nov 2015 11:23:34 +1100 X-Google-Sender-Auth: DBGGB8qPq6WGWbBNpvSJ6haD5kw Message-ID: From: Christopher Morrow To: Jelena Mirkovic Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Roland Dobbins , "dots@ietf.org" Subject: Re: [Dots] Does DOTS require sneaker-net support? 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, 05 Nov 2015 00:23:37 -0000 On Thu, Nov 5, 2015 at 6:33 AM, Jelena Mirkovic wrote: > I apologize first for not having read the current draft carefully. Feel free > to tell me to go read it if the issue I bring up is addressed there. It > seems to me that the critical issue is how requests are authenticated, i.e., > how does one prove that they have authority over a given IP space. that's a can of worms.. but MOSTLY the ISP customer sorts that out for other reasons with their ISP. For 'not your ISP' solutions there are already verification processes being used, we ought to just rely on them. unless you wanted to mandate RPKI adoption... > > ... leaving that aside for now .. > > I see one part missing in this discussion about "network may be too > congested to get the message out". One doesn't have to use the network. We > all have cell phones, cell networks usually work separately from Internet. > One can just use an app on cell phone to contact their ISP. > this is in Roland's use-case slides/preso/draft I believe, actually. depending on human intervention is probably the wrong answer long term, but 'one option' is fine for people poking buttons. (I think) > > ========================= > > Jelena Mirkovic > Research Faculty > USC Information Sciences Institute > 4676 Admiralty Way, Suite 1001 > Marina del Rey, CA 90292 > 310-448-9170 > > > On Tue, Nov 3, 2015 at 7:00 PM, Roland Dobbins wrote: >> >> On 4 Nov 2015, at 11:31, Dave Dolson wrote: >> >>> I'm asking because yesterday someone mentioned that occasionally >>> operators need to set things up after an attack has begun. >> >> >> I believe this is actually worthy of consideration - it's an interesting >> 'failsafe' approach. We shouldn't spend a lot of time on it just yet, but >> should keep it in mind as we progress, IMHO. >> >> DNS could also be potentially used for this sort of thing. >> >> ----------------------------------- >> 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 Wed Nov 4 16:30: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 AAB6A1AD34F; Wed, 4 Nov 2015 16:24:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, 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 2vdMMyIbV7AD; Wed, 4 Nov 2015 16:24:33 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (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 4E1A61B2A72; Wed, 4 Nov 2015 16:24:33 -0800 (PST) Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com [10.106.48.160]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id tA50OQ9e028979 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 4 Nov 2015 19:24:28 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com tA50OQ9e028979 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1446683068; bh=VczTlSLKBmKqPW6/oZG2Xw2h64k=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=UBpwQtVnfvQHeyprs/zAJlPLNVcrVyRUnYN59vuI4+jPlycczwDwnPDuCEmH2NXI6 zmyWw/RfFRGJvMgLNtaYaLySoS5TP1/bZxBFjjGjIsw/zuyclOLRgqkAA2+LK/tm8b cUPApZ24OSPQqj093aOd9T3dapMhDTZVOGB40cAA= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com tA50OQ9e028979 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd56.lss.emc.com (RSA Interceptor); Wed, 4 Nov 2015 19:24:01 -0500 Received: from mxhub18.corp.emc.com (mxhub18.corp.emc.com [10.254.93.47]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id tA50OAXs018922 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Nov 2015 19:24:10 -0500 Received: from MXHUB102.corp.emc.com (10.253.58.15) by mxhub18.corp.emc.com (10.254.93.47) with Microsoft SMTP Server (TLS) id 8.3.327.1; Wed, 4 Nov 2015 19:24:10 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.60]) by MXHUB102.corp.emc.com ([::1]) with mapi id 14.03.0266.001; Wed, 4 Nov 2015 19:24:09 -0500 From: "Black, David" To: "gorry@erg.abdn.ac.uk" , Aaron Falk Thread-Topic: [tsvwg] [Dots] Best transport selection during an attack? Thread-Index: AQHRFrWkHMZ0g/5A7UOhu/5Yi33PDJ6L48SAgACtMcA= Importance: high X-Priority: 1 Date: Thu, 5 Nov 2015 00:24:08 +0000 Message-ID: References: <5638D31B.4080801@mti-systems.com> <0A836E5A-C801-4CF4-916C-41EA065D3D30@arbor.net> <20dadcd20c26d51c284fdc4697cdc8a9.squirrel@erg.abdn.ac.uk> In-Reply-To: <20dadcd20c26d51c284fdc4697cdc8a9.squirrel@erg.abdn.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.13.35.86] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com X-RSA-Classifications: public Archived-At: X-Mailman-Approved-At: Wed, 04 Nov 2015 16:30:40 -0800 Cc: "tsvwg@ietf.org" , "tsvwg-chairs@ietf.org" , "dots@ietf.org" Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 05 Nov 2015 00:24:34 -0000 > Seriously: I think it deserves a heads-up presentation of the problem to > be addressed. Yes, that can be done. I'm pre-bashing today's agenda now - we'll confirm the changes at the start of the meeting - there's at least one other item that needs to be added to the agenda. There is definitely time available for a heads-up presentation of the problem (5-10 min). However ... there is definitely not time available for an extensive discussion (e.g., 30min). I assume that this is about draft-reddy-dots-transport-01 - who's volunteering to present (plus summarize relevant dots WG and mailing list discussions)? Thanks, --David > -----Original Message----- > From: gorry@erg.abdn.ac.uk [mailto:gorry@erg.abdn.ac.uk] > Sent: Wednesday, November 04, 2015 3:56 AM > To: Aaron Falk > Cc: tsvwg-chairs@ietf.org; dots@ietf.org; tsvwg@ietf.org > Subject: Re: [tsvwg] [Dots] Best transport selection during an attack? >=20 > I'm in favour - but I am currently in a different timezone to my co-chair > - who is managing our agenda time... >=20 > Curiously: think this could be an excellent extension to the TAPS API - > saying you want robustness and letting it choose protocol - but we need > first of all to see if we can get something useful from TAPS first before > we build new "features":-) >=20 > Seriously: I think it deserves a heads-up presentation of the problem to > be addressed. >=20 > Gorry >=20 > > TSVWG chairs- > > > > Will you allocate some time for this topic? > > > > --aaron > > > > On Wed, Nov 4, 2015 at 7:10 AM, Roland Dobbins wro= te: > > > >> On 4 Nov 2015, at 1:22, Ca By wrote: > >> > >> at least in the case i am most familiar with. > >>> > >> > >> It is important to keep this part in mind. > >> > >> With DOTS in UDP, you are putting the DOTs traffic in that path that > >>> becomes the most lossy during a a DDoS. > >>> > >> > >> This is an overgeneralization - see above. > >> > >> There are lots of topological and pathing assumptions being made, here= , > >> as > >> well as policy-filtering assumptions. > >> > >> It has been clear from the beginning of this effort that both stateles= s > >> and stateful transport options are necessary, due to overly-restrictiv= e > >> network access policies, edge QoSing as a (counterproductive, IMHO) > >> measure > >> against UDP reflection/amplification attacks, etc. This has been > >> discussed > >> on-list and in meetings, it's unclear why it's become contentious, all > >> of a > >> sudden. > >> > >> ----------------------------------- > >> Roland Dobbins > >> > >> > > From nobody Wed Nov 4 16:37: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 219191B2C98; Wed, 4 Nov 2015 16:34:42 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 et23nHGxkhkx; Wed, 4 Nov 2015 16:34:41 -0800 (PST) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::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 D3A1A1B2BF3; Wed, 4 Nov 2015 16:34:40 -0800 (PST) Received: by ykdr3 with SMTP id r3so104198958ykd.1; Wed, 04 Nov 2015 16:34:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2BUGd72E+VZHKcWbW02xkdE4q72gxNnElKaM30QpraQ=; b=dbu6ijRj/8SLP0HjRHKZPAaiJXOuayWbHvXfB1GFc+yKqT8U2MopLFp6Eos/VS4pNs khZnK9d5daYVmiVoFG3tZ4p6CVRjS1bYCuJ6iWdDV6DWFHCyFQPP7C2CJxAlPuZaCtJS oA9Jedv8qxyCDT3DgToK2w5XHDvcByr8cfXfqtX6hjDnaG0hjKNT4MEixB0ytwFO4kFN 13HUrJzFcjTu2BZrnFz6YSqWlw7e438VvsYrzT9+WWZGGYIbOc7CSvPl+pOzJhFSZsJr 7ObvQXDX3HDiVRrJVBVWsDZNbER9XlyUO5ibjZ40lI4kAlVxTFAFtVA4GHcZy+SZU3Wr d9Tw== MIME-Version: 1.0 X-Received: by 10.129.105.213 with SMTP id e204mr3677595ywc.61.1446683680187; Wed, 04 Nov 2015 16:34:40 -0800 (PST) Received: by 10.37.95.2 with HTTP; Wed, 4 Nov 2015 16:34:40 -0800 (PST) In-Reply-To: References: <5638D31B.4080801@mti-systems.com> <0A836E5A-C801-4CF4-916C-41EA065D3D30@arbor.net> <20dadcd20c26d51c284fdc4697cdc8a9.squirrel@erg.abdn.ac.uk> Date: Thu, 5 Nov 2015 09:34:40 +0900 Message-ID: From: Aaron Falk To: "Black, David" Content-Type: multipart/alternative; boundary=001a114938a8dc2cf30523c04a21 Archived-At: X-Mailman-Approved-At: Wed, 04 Nov 2015 16:37:31 -0800 Cc: "gorry@erg.abdn.ac.uk" , "tsvwg@ietf.org" , "tsvwg-chairs@ietf.org" , "dots@ietf.org" Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 05 Nov 2015 00:34:42 -0000 --001a114938a8dc2cf30523c04a21 Content-Type: text/plain; charset=UTF-8 On Thu, Nov 5, 2015 at 9:24 AM, Black, David wrote: > who's > volunteering to present (plus summarize relevant dots WG and mailing list > discussions)? > I'll leave that to the DOTS folks to figure out. --aaron --001a114938a8dc2cf30523c04a21 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Nov 5, 2015 at 9:24 AM, Black, David <david.black@emc.com> wrote:
who's
volunteering to present (plus summarize relevant dots WG and mailing list discussions)?


I'll l= eave that to the DOTS folks to figure out.=C2=A0

-= -aaron
--001a114938a8dc2cf30523c04a21-- From nobody Wed Nov 4 16:38: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 E0D751B3322 for ; Wed, 4 Nov 2015 16:38:53 -0800 (PST) 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=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 TBMvvTREtdJJ for ; Wed, 4 Nov 2015 16:38:52 -0800 (PST) Received: from mail-qg0-f98.google.com (mail-qg0-f98.google.com [209.85.192.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 C719D1B3356 for ; Wed, 4 Nov 2015 16:38:51 -0800 (PST) Received: by qgeb1 with SMTP id b1so172855qge.0 for ; Wed, 04 Nov 2015 16:38:51 -0800 (PST) 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 :importance:date:message-id:references:in-reply-to:accept-language :content-language:user-agent:content-type:content-id :content-transfer-encoding:mime-version; bh=5wameAXZpBy+0dawOhXBqmjx2i+KpLH0Y8jg7LqfUEg=; b=Hwz/Ebdok3XyFERsbfX6VQYsEIIey77qQSBcQO3hMqw11ULAyJHj9FHzjSeWL19mFl Zgav5t/mukBKmlaB6A3Y3svylc6Eb+4b8DAcnCqAYxYvwnQR1qQBHdwcHNdKIXs5RAA6 LaiGohm5lLd1plLYHm0iCd3p8sUup2ZeX15MWqmzITMEv+EXKxFQQwhCdwe8l7U6FzWW zkG84YU802P8ZIKuO/iMx86w+OALhBwcR1wnjuPLAyZkt/HqiHvMaTznimpClbubFflo khkRSwwzRz/wIM49GemIVqTyXD3WrcLh6uy4b6VX6+Sn/cGR4paXdmoKkCsl/zMrCQId PJUQ== X-Gm-Message-State: ALoCoQn3sgqUgBV9cwpp0e4dHuAsACxbRZqFaH4h3+ihno3EBD8UxUIOdVZOT2KjEs0WrfVScWyBVnlU5E+DKpzOB6PKjLWzzg== X-Received: by 10.140.219.198 with SMTP id p189mr4888113qhb.80.1446683930980; Wed, 04 Nov 2015 16:38:50 -0800 (PST) Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by smtp-relay.gmail.com with ESMTPS id u191sm459776qka.2.2015.11.04.16.38.50 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 04 Nov 2015 16:38:50 -0800 (PST) X-Relaying-Domain: verisign.com Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02 [10.173.152.206]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id tA50cUTc017899 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 Nov 2015 19:38:30 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 4 Nov 2015 19:38:30 -0500 From: "Teague, Nik" To: "Black, David" , "gorry@erg.abdn.ac.uk" , Aaron Falk Thread-Topic: [Dots] [tsvwg] Best transport selection during an attack? Thread-Index: AQHRFlPZ/c1sYGLOl0SxsI7IBktg/56LMAIAgABiZQCAAFIhgIABAzQAgACa34A= Importance: high X-Priority: 1 Date: Thu, 5 Nov 2015 00:38:29 +0000 Message-ID: References: <5638D31B.4080801@mti-systems.com> <0A836E5A-C801-4CF4-916C-41EA065D3D30@arbor.net> <20dadcd20c26d51c284fdc4697cdc8a9.squirrel@erg.abdn.ac.uk> 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.7.151005 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="utf-8" Content-ID: <479C5CAD87E9E14D8F356299CF4BE88B@verisign.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "dots@ietf.org" , "tsvwg@ietf.org" , "tsvwg-chairs@ietf.org" Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 05 Nov 2015 00:38:54 -0000 SGksDQoNCk9uIDA1LzExLzIwMTUgMDk6MjQsICJEb3RzIG9uIGJlaGFsZiBvZiBCbGFjaywgRGF2 aWQiDQo8ZG90cy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBkYXZpZC5ibGFja0BlbWMu Y29tPiB3cm90ZToNCg0KPkkgYXNzdW1lIHRoYXQgdGhpcyBpcyBhYm91dCBkcmFmdC1yZWRkeS1k b3RzLXRyYW5zcG9ydC0wMSAtIHdobydzDQo+dm9sdW50ZWVyaW5nIHRvIHByZXNlbnQgKHBsdXMg c3VtbWFyaXplIHJlbGV2YW50IGRvdHMgV0cgYW5kIG1haWxpbmcgbGlzdA0KPmRpc2N1c3Npb25z KT8NCg0KSSBjb3VsZCBzcGVhayAtIEkgZG9u4oCZdCBoYXZlIHRpbWUgdG8gZG8gc2xpZGVzIGJ1 dCBJIGNvdWxkIGNlcnRhaW5seSBzcGVhaw0KdG8gdGhlIHByb2JsZW0gc3BhY2UuDQoNClJlbGF0 ZWQgZHJhZnRzIGFyZToNCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi1kb3RzLXVzZS1jYXNlcy8NCg0KDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLWRvdHMtcmVxdWlyZW1lbnRzLw0KDQoNCmRyYWZ0LXJlZGR5LWRvdHMtdHJh bnNwb3J0LTAxIGlzIGEgdGFsa2luZyBwb2ludCBidXQgd2XigJlyZSBpbiB0aGUgcHJvdG9jb2wN CmRlc2lnbiBpbmZhbmN5IHN0YWdlIHNvIEkgd291bGRu4oCZdCB3YW50IHRvIHB1dCB0b28gbXVj aCB3ZWlnaHQgb24gYSBnaXZlbg0Kc3VnZ2VzdGVkIHNvbHV0aW9uIGF0IHRoaXMgc3RhZ2UNCg0K DQpUaGFua3MsDQoNCi1OaWsNCg0K From nobody Wed Nov 4 16:44: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 CF8FA1B3333; Wed, 4 Nov 2015 16:43:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, 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 MUUa5oumAnkj; Wed, 4 Nov 2015 16:43:02 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (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 3D9B71B2CCE; Wed, 4 Nov 2015 16:43:02 -0800 (PST) Received: from maildlpprd53.lss.emc.com (maildlpprd53.lss.emc.com [10.106.48.157]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id tA50gv8g010259 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 4 Nov 2015 19:42:57 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com tA50gv8g010259 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1446684178; bh=k4Ikg66RRsUc9Yq8hS0AWFky0XM=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=Z/U0i6vbDEg/oH6+MvRW0h/75+kbuKuyL7ozAXgRn0yKMDVbjZ+Bc9Az/WPAujXXI o7rftNyqkp6s0rDPVdBsfgoU5/I8CSr04hTVxIfJFQOBKP4F/UIlQr3+LGHz8Z2xRO 9Z/IRV1cna2ttDpVED8TfDzYVT2zeOuwu4oHBifQ= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com tA50gv8g010259 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd53.lss.emc.com (RSA Interceptor); Wed, 4 Nov 2015 19:42:37 -0500 Received: from mxhub32.corp.emc.com (mxhub32.corp.emc.com [128.222.70.172]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id tA50ggda007337 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Nov 2015 19:42:42 -0500 Received: from MXHUB108.corp.emc.com (10.253.58.24) by mxhub32.corp.emc.com (128.222.70.172) with Microsoft SMTP Server (TLS) id 8.3.327.1; Wed, 4 Nov 2015 19:42:41 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.60]) by MXHUB108.corp.emc.com ([10.253.58.24]) with mapi id 14.03.0266.001; Wed, 4 Nov 2015 19:42:41 -0500 From: "Black, David" To: "Teague, Nik" , "gorry@erg.abdn.ac.uk" , Aaron Falk Thread-Topic: [Dots] [tsvwg] Best transport selection during an attack? Thread-Index: AQHRF2JZ89LPAxgcUU+8JpzxdotJK56Mlj9g Date: Thu, 5 Nov 2015 00:42:39 +0000 Message-ID: References: <5638D31B.4080801@mti-systems.com> <0A836E5A-C801-4CF4-916C-41EA065D3D30@arbor.net> <20dadcd20c26d51c284fdc4697cdc8a9.squirrel@erg.abdn.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.13.35.86] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: public Archived-At: X-Mailman-Approved-At: Wed, 04 Nov 2015 16:44:10 -0800 Cc: "Black, David" , "dots@ietf.org" , "tsvwg@ietf.org" , "tsvwg-chairs@ietf.org" Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 05 Nov 2015 00:43:04 -0000 VGFsa2luZyBwb2ludHMgYXJlICpleGFjdGx5KiB3aGF0J3Mgd2FudGVkIC0gYXJlIHRoZSBzbGlk ZXMgZnJvbSBkcmFmdC1yZWRkeQ0KYXBwcm9wcmlhdGUgYXMgYSBqdW1waW5nLW9mZiBwb2ludCwg b3IgYXJlIHRoZXJlIG90aGVyIHNsaWRlcyB0aGF0IHlvdSdkDQpwcmVmZXI/DQoNCkl0J3Mgb2sg Zm9yIHlvdSB0byBub3QgYWdyZWUgd2l0aCB0aGUgc2xpZGUgY29udGVudHMgaWYgeW91IHJldXNl IHNvbWVvbmUgZWxzZSdzIGRlY2s7LSkuDQoNClRoYW5rcywNCi0tRGF2aWQNCg0KPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBUZWFndWUsIE5payBbbWFpbHRvOm50ZWFndWVA dmVyaXNpZ24uY29tXQ0KPiBTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDA0LCAyMDE1IDc6Mzgg UE0NCj4gVG86IEJsYWNrLCBEYXZpZDsgZ29ycnlAZXJnLmFiZG4uYWMudWs7IEFhcm9uIEZhbGsN Cj4gQ2M6IHRzdndnQGlldGYub3JnOyB0c3Z3Zy1jaGFpcnNAaWV0Zi5vcmc7IGRvdHNAaWV0Zi5v cmcNCj4gU3ViamVjdDogUmU6IFtEb3RzXSBbdHN2d2ddIEJlc3QgdHJhbnNwb3J0IHNlbGVjdGlv biBkdXJpbmcgYW4gYXR0YWNrPw0KPiBJbXBvcnRhbmNlOiBIaWdoDQo+IA0KPiBIaSwNCj4gDQo+ IE9uIDA1LzExLzIwMTUgMDk6MjQsICJEb3RzIG9uIGJlaGFsZiBvZiBCbGFjaywgRGF2aWQiDQo+ IDxkb3RzLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGRhdmlkLmJsYWNrQGVtYy5jb20+ IHdyb3RlOg0KPiANCj4gPkkgYXNzdW1lIHRoYXQgdGhpcyBpcyBhYm91dCBkcmFmdC1yZWRkeS1k b3RzLXRyYW5zcG9ydC0wMSAtIHdobydzDQo+ID52b2x1bnRlZXJpbmcgdG8gcHJlc2VudCAocGx1 cyBzdW1tYXJpemUgcmVsZXZhbnQgZG90cyBXRyBhbmQgbWFpbGluZyBsaXN0DQo+ID5kaXNjdXNz aW9ucyk/DQo+IA0KPiBJIGNvdWxkIHNwZWFrIC0gSSBkb27igJl0IGhhdmUgdGltZSB0byBkbyBz bGlkZXMgYnV0IEkgY291bGQgY2VydGFpbmx5IHNwZWFrDQo+IHRvIHRoZSBwcm9ibGVtIHNwYWNl Lg0KPiANCj4gUmVsYXRlZCBkcmFmdHMgYXJlOg0KPiANCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kb3RzLXVzZS1jYXNlcy8NCj4gDQo+IA0KPiBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWRvdHMtcmVxdWlyZW1lbnRzLw0K PiANCj4gDQo+IGRyYWZ0LXJlZGR5LWRvdHMtdHJhbnNwb3J0LTAxIGlzIGEgdGFsa2luZyBwb2lu dCBidXQgd2XigJlyZSBpbiB0aGUgcHJvdG9jb2wNCj4gZGVzaWduIGluZmFuY3kgc3RhZ2Ugc28g SSB3b3VsZG7igJl0IHdhbnQgdG8gcHV0IHRvbyBtdWNoIHdlaWdodCBvbiBhIGdpdmVuDQo+IHN1 Z2dlc3RlZCBzb2x1dGlvbiBhdCB0aGlzIHN0YWdlDQo+IA0KPiANCj4gVGhhbmtzLA0KPiANCj4g LU5paw0KDQo= From nobody Wed Nov 4 16:51:25 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 9A87A1B3518 for ; Wed, 4 Nov 2015 16:51:23 -0800 (PST) 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=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 8XmEmFPAScAy for ; Wed, 4 Nov 2015 16:51:22 -0800 (PST) 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 2C85E1B34F8 for ; Wed, 4 Nov 2015 16:51:22 -0800 (PST) Received: by qgeb1 with SMTP id b1so185997qge.0 for ; Wed, 04 Nov 2015 16:51:21 -0800 (PST) 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=vb/miNKKV2vSiA8oX6PsOJehvM6MD2dDBRkq7BHRE0U=; b=Bc/VycHREljpvi+FeGf9YID0qeVxUyBG0xwsde8BkEqvFh5zZUuYx5wN4xuubmiPpT WSEt8jwwdoPoypD73RmYuY3aUKpBC4cTINDP7cctmqfe07o0fyohla3FpbY3yVCiTelh a8qbBgzmarL4BYU3G1Hk3sp9vj5Py3T03ySlc5TR/stsCZUcD9YXccULO/GuP/DCbOPc qnP4T7TnfHHwoZ0knMtDtwGkY00Nu2ALdIjXyEd5qhrkPfX69NOQEW+GAS9SbPP0oZmI kiAG5bI0KRsgkE2q1Lr1IMXixCswWyg+kipBCkfJRPAAAY84nTgGnShXS1FQwVbV6x+Z fcgg== X-Gm-Message-State: ALoCoQlp5ixvI/dI1TyZPDLww1aTkYhTyzoqpJPWeJ5/3hX0QIFljYKFX0rJwbFHYis9e5Wgwvq7XZlN+SVDWtVrTvAQwPYs7Q== X-Received: by 10.140.29.34 with SMTP id a31mr4537300qga.88.1446684681359; Wed, 04 Nov 2015 16:51:21 -0800 (PST) Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by smtp-relay.gmail.com with ESMTPS id x206sm67772qka.10.2015.11.04.16.51.21 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 04 Nov 2015 16:51:21 -0800 (PST) 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 tA50pKqV003495 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Nov 2015 19:51:20 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 4 Nov 2015 19:51:20 -0500 From: "Teague, Nik" To: "Black, David" , "gorry@erg.abdn.ac.uk" , Aaron Falk Thread-Topic: [Dots] [tsvwg] Best transport selection during an attack? Thread-Index: AQHRFlPZ/c1sYGLOl0SxsI7IBktg/56LMAIAgABiZQCAAFIhgIABAzQAgACa34D//2pNgIAAmUSA Date: Thu, 5 Nov 2015 00:51:20 +0000 Message-ID: References: <5638D31B.4080801@mti-systems.com> <0A836E5A-C801-4CF4-916C-41EA065D3D30@arbor.net> <20dadcd20c26d51c284fdc4697cdc8a9.squirrel@erg.abdn.ac.uk> 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.7.151005 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: "dots@ietf.org" , "tsvwg@ietf.org" , "tsvwg-chairs@ietf.org" Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 05 Nov 2015 00:51:23 -0000 T24gMDUvMTEvMjAxNSAwOTo0MiwgIkJsYWNrLCBEYXZpZCIgPGRhdmlkLmJsYWNrQGVtYy5jb20+ IHdyb3RlOg0KDQo+VGFsa2luZyBwb2ludHMgYXJlICpleGFjdGx5KiB3aGF0J3Mgd2FudGVkIC0g YXJlIHRoZSBzbGlkZXMgZnJvbQ0KPmRyYWZ0LXJlZGR5DQo+YXBwcm9wcmlhdGUgYXMgYSBqdW1w aW5nLW9mZiBwb2ludCwgb3IgYXJlIHRoZXJlIG90aGVyIHNsaWRlcyB0aGF0IHlvdSdkDQo+cHJl ZmVyPw0KPg0KPkl0J3Mgb2sgZm9yIHlvdSB0byBub3QgYWdyZWUgd2l0aCB0aGUgc2xpZGUgY29u dGVudHMgaWYgeW91IHJldXNlIHNvbWVvbmUNCj5lbHNlJ3MgZGVjazstKS4NCg0KVGhlIHNsaWRl cyBwcmVzZW50ZWQgYXJlIGhlcmU6DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdz Lzk0L3NsaWRlcy9zbGlkZXMtOTQtZG90cy01LnBkZg0KDQoNCknigJltIGZpbmUgd2l0aCB0aGVt IGJlaW5nIGEganVtcGluZyBvZmYgcG9pbnQgZm9yIHRoZSBkaXNjdXNzaW9uIC0gdGhlDQpkaXNj dXNzaW9uIGlzIGFyb3VuZCB0aGUg4oCYU09T4oCZIG1lc3NhZ2UgdHJhbnNwb3J0Lg0KDQpJIHdv dWxkIG9mIGNvdXJzZSBkZWZlciB0byBQcmFzaGFudGggd2hvIHByZXNlbnRlZCBvcmlnaW5hbGx5 IGFzIFRpcnUNCmNvdWxkbuKAmXQgYmUgaGVyZSBpZiB0aGV5IHdvdWxkIHByZWZlciB0byByZXBy ZXNlbnQgdGhlaXIgc2xpZGVzLg0KDQpUaGFua3MsDQoNCi1OaWsNCg0KDQo= From nobody Wed Nov 4 16:58: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 CCD741A8034 for ; Wed, 4 Nov 2015 16:58:56 -0800 (PST) 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 uWS7F0nodA6M for ; Wed, 4 Nov 2015 16:58:54 -0800 (PST) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::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 734881A86E3 for ; Wed, 4 Nov 2015 16:58:54 -0800 (PST) Received: by iody8 with SMTP id y8so73492219iod.1 for ; Wed, 04 Nov 2015 16:58:53 -0800 (PST) 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=4gcBEhpLGlUSiot15wmBIaMjNHhAutgjUOApmC2KEIc=; b=THWJqKN/YIqdAM8rCVcOhNKI4nV/EoEGZQEdFFq+jenPMa/AJweNlUAa4/kfrrBlJz vKRa/3mAuilzPng5Ra5qwE7/MYBvpYDogtNwrnRcZJIKWO+SY0yZ+6v3JnZTKqrH4DcR S8siyxgW3v5gPA91DGYgKTPbaeAC7xz13HO6U= 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=4gcBEhpLGlUSiot15wmBIaMjNHhAutgjUOApmC2KEIc=; b=SbSNP0uBRrx6rKobtVv9SDrtFWzl8aEpBGM/SITeHRdVJYafT18bNecHNBR2ZFN943 xqyY9SGHY9908nf6vu1d4ZNZg60DJozNEo6aQ1OxxjVRQ50G9yFe/iQv8Ov0H5F+d7ad nkY2fcXLTncn1YlCVl0IhHIrY+PzPd8hfV6fyIEXEHLbEmULdFC+qeo0VL+2VrChBOqW db8kvA4g9pkSmSu4NCcAR3/k9nlyhaiXTJYFJZ244vbpIO1EudKWEF9yjOdWUTqNpVtA PbjWDjsiGd8DIoN/FbZeNCZIL3a5CqUUofVs2b5/VU/d/VmraSAfDojKWvn6WV49CA1L xP8Q== X-Gm-Message-State: ALoCoQlFJq0Cc4ZKlz94epmd3lJNdbk/l9rJzHimkvQoxGL+NXSAg53wPMPfUZIBTNUkq9/Iwnva X-Received: by 10.107.6.23 with SMTP id 23mr7392997iog.147.1446685133854; Wed, 04 Nov 2015 16:58:53 -0800 (PST) Received: from dhcp-35-191.meeting.ietf94.jp (dhcp-35-191.meeting.ietf94.jp. [133.93.35.191]) by smtp.gmail.com with ESMTPSA id w71sm2001759ioi.29.2015.11.04.16.58.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Nov 2015 16:58:53 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Andrew Mortensen In-Reply-To: Date: Wed, 4 Nov 2015 19:58:49 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5638D31B.4080801@mti-systems.com> <0A836E5A-C801-4CF4-916C-41EA065D3D30@arbor.net> <20dadcd20c26d51c284fdc4697cdc8a9.squirrel@erg.abdn.ac.uk> To: "Teague, Nik" X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: "gorry@erg.abdn.ac.uk" , Aaron Falk , "tsvwg@ietf.org" , "Black, David" , "dots@ietf.org" , "tsvwg-chairs@ietf.org" Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 05 Nov 2015 00:58:57 -0000 > On Nov 4, 2015, at 7:51 PM, Teague, Nik wrote: >=20 > On 05/11/2015 09:42, "Black, David" wrote: >=20 >> Talking points are *exactly* what's wanted - are the slides from >> draft-reddy >> appropriate as a jumping-off point, or are there other slides that = you'd >> prefer? >>=20 >> It's ok for you to not agree with the slide contents if you reuse = someone >> else's deck;-). >=20 > The slides presented are here: >=20 > https://www.ietf.org/proceedings/94/slides/slides-94-dots-5.pdf >=20 >=20 > I=E2=80=99m fine with them being a jumping off point for the = discussion - the > discussion is around the =E2=80=98SOS=E2=80=99 message transport. And in fairness to the authors of draft-reddy-dots-transport, I believe = they=E2=80=99re simply aligning the draft with the OP-001 requirement in = the requirements draft: OP-001 Use of Common Transports: DOTS MUST operate over common standardized transport protocols. While the protocol resilience requirement strongly RECOMMENDS the use of connectionless protocols, in particular the User Datagram Protocol (UDP) use of a standardized, connection-oriented protocol like the Transmission Control Protocol (TCP) MAY be necessary due to network policy or middleware limitations. = andrew From nobody Wed Nov 4 17:01: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 98FDC1B2EC4 for ; Wed, 4 Nov 2015 17:01:03 -0800 (PST) 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 dEfB9Dm1MtbS for ; Wed, 4 Nov 2015 17:01:02 -0800 (PST) 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 ACE3A1B2C76 for ; Wed, 4 Nov 2015 17:01:02 -0800 (PST) Received: by pabfh17 with SMTP id fh17so68955050pab.0 for ; Wed, 04 Nov 2015 17:01:02 -0800 (PST) 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=uv+1iF2ZapKZk8eD+TdH/L2oa3TINnsx3AwfImpiJyg=; b=gNHW9HUM5vY4jEeffYxYRiT7T6yoT5g47R1oVFE4tkliXeGg6xe+d76Cn7k2yaJIA2 q6Zvz/GRGOiOlLasvBF06P3LhIddXREJkte8LW3ohrfpR5wIIt8MjuRBvqyDFlbk6XYA APDaGM1lShGzYkf8lpmlxaaH6qBMtC+L3SG44= 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=uv+1iF2ZapKZk8eD+TdH/L2oa3TINnsx3AwfImpiJyg=; b=IZxlpeggV/DTa4XBYY0Kz6cb9krE3cB3PmaXZXUZa3xB/uGsI09SZ7NbJ4O2TZRsmx l59gyVvYRO5KMqJr7tp0rXhXO4/Bl9OikfrdifELsrjJPec71GEFJawZEhNSNylE/FJO DR74J8KY0GOrtcsaqrEc8c0z7VOxmbx+E4Sk/LEn3Agdnrli3nlPhNTCpp5iOU3Aaecr sp0j5tTBWZlEV8zxOwKuGnpqNrsvjJZ1upgPqLm+u74D/Du6wesKnqECAA4Pp3/QSnWi 5sD6gO5D/q4dFIn1yla1Re44eqvXApTzmSwL6NGQ7ljPlZsgjOYb/ahPYuKoO+zdCsjg dOMA== X-Gm-Message-State: ALoCoQmFEXCNrsTSC8Xihhd1Fa29kfC5eYy/Z9Kb38YPqewBqEALg1GphuZ8OZNUAB15on+ZF2z0 X-Received: by 10.68.253.103 with SMTP id zz7mr5890797pbc.18.1446685261816; Wed, 04 Nov 2015 17:01:01 -0800 (PST) Received: from [10.0.1.3] (p5231-ipngn5001hodogaya.kanagawa.ocn.ne.jp. [153.220.164.231]) by smtp.gmail.com with ESMTPSA id of1sm4337628pbc.11.2015.11.04.17.01.00 for (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 04 Nov 2015 17:01:00 -0800 (PST) From: "Roland Dobbins" To: "dots@ietf.org" Date: Thu, 05 Nov 2015 10:00:58 +0900 Message-ID: In-Reply-To: References: <5534122E-42C4-4EF0-91EB-69A6A38E5528@arbor.net> MIME-Version: 1.0 X-Mailer: MailMate (1.9.3r5164) Archived-At: Subject: Re: [Dots] Does DOTS require sneaker-net support? 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, 05 Nov 2015 01:01:03 -0000 On 5 Nov 2015, at 4:33, Jelena Mirkovic wrote: > One can just use an app on cell phone to contact their ISP. Please see the use-cases draft and presentation. ----------------------------------- Roland Dobbins From nobody Wed Nov 4 17:02: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 E49BC1A6F9D; Wed, 4 Nov 2015 17:01:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, 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 vkiQB4Q6eSKl; Wed, 4 Nov 2015 17:01:29 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (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 644D41B2C76; Wed, 4 Nov 2015 17:01:29 -0800 (PST) Received: from maildlpprd02.lss.emc.com (maildlpprd02.lss.emc.com [10.253.24.34]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id tA511OB4023817 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 4 Nov 2015 20:01:25 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com tA511OB4023817 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1446685285; bh=ogvptxEJcEeHGANO6UsrRZVdaqg=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=Qf9cvrGmL5wGL8QI3wAKt+WCAVIjJ1EXpjw40rRXA+t9EU7VelVsisj1SBpIeHRCg o39CyNk9P3uVZgkLs+muZilFf/IkmCMRDRc2WSbz6UHmzYSIwIlF3DoGkq7UvHuxjJ TQZYJWfuLPT1gQz4394hKPsidYyGe1UabbMmXoxE= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com tA511OB4023817 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd02.lss.emc.com (RSA Interceptor); Wed, 4 Nov 2015 19:59:13 -0500 Received: from mxhub27.corp.emc.com (mxhub27.corp.emc.com [10.254.110.183]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id tA511D4i002135 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Nov 2015 20:01:14 -0500 Received: from MXHUB205.corp.emc.com (10.253.68.31) by mxhub27.corp.emc.com (10.254.110.183) with Microsoft SMTP Server (TLS) id 8.3.327.1; Wed, 4 Nov 2015 20:01:13 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.60]) by MXHUB205.corp.emc.com ([10.253.68.31]) with mapi id 14.03.0266.001; Wed, 4 Nov 2015 20:01:13 -0500 From: "Black, David" To: "Teague, Nik" , "gorry@erg.abdn.ac.uk" , Aaron Falk Thread-Topic: [Dots] [tsvwg] Best transport selection during an attack? Thread-Index: AQHRF2JZ89LPAxgcUU+8JpzxdotJK56Mlj9ggABW+QD//63pkA== Date: Thu, 5 Nov 2015 01:01:12 +0000 Message-ID: References: <5638D31B.4080801@mti-systems.com> <0A836E5A-C801-4CF4-916C-41EA065D3D30@arbor.net> <20dadcd20c26d51c284fdc4697cdc8a9.squirrel@erg.abdn.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.13.35.86] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com X-RSA-Classifications: public Archived-At: X-Mailman-Approved-At: Wed, 04 Nov 2015 17:02:34 -0800 Cc: "Black, David" , "dots@ietf.org" , "tsvwg@ietf.org" , "tsvwg-chairs@ietf.org" Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 05 Nov 2015 01:01:31 -0000 PiBJ4oCZbSBmaW5lIHdpdGggdGhlbSBiZWluZyBhIGp1bXBpbmcgb2ZmIHBvaW50IGZvciB0aGUg ZGlzY3Vzc2lvbiAtIHRoZQ0KPiBkaXNjdXNzaW9uIGlzIGFyb3VuZCB0aGUg4oCYU09T4oCZIG1l c3NhZ2UgdHJhbnNwb3J0Lg0KDQpUaGF0IHdvcmtzIGZvciBtZS4gIEknbGwgY3Jvc3MtcG9zdCB0 aG9zZSBzbGlkZXMgdG8gdGhlIFRTVldHIG1lZXRpbmcNCm1hdGVyaWFscyAtIHlvdSBhbmQgUHJh c2hhbnRoIGNhbiBzb3J0IG91dCB3aG8gd2FudHMgdG8gcHJlc2VudC4NCgkNClRoYW5rcywNCi0t RGF2aWQNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBUZWFndWUsIE5p ayBbbWFpbHRvOm50ZWFndWVAdmVyaXNpZ24uY29tXQ0KPiBTZW50OiBXZWRuZXNkYXksIE5vdmVt YmVyIDA0LCAyMDE1IDc6NTEgUE0NCj4gVG86IEJsYWNrLCBEYXZpZDsgZ29ycnlAZXJnLmFiZG4u YWMudWs7IEFhcm9uIEZhbGsNCj4gQ2M6IHRzdndnQGlldGYub3JnOyB0c3Z3Zy1jaGFpcnNAaWV0 Zi5vcmc7IGRvdHNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtEb3RzXSBbdHN2d2ddIEJlc3Qg dHJhbnNwb3J0IHNlbGVjdGlvbiBkdXJpbmcgYW4gYXR0YWNrPw0KPiANCj4gT24gMDUvMTEvMjAx NSAwOTo0MiwgIkJsYWNrLCBEYXZpZCIgPGRhdmlkLmJsYWNrQGVtYy5jb20+IHdyb3RlOg0KPiAN Cj4gPlRhbGtpbmcgcG9pbnRzIGFyZSAqZXhhY3RseSogd2hhdCdzIHdhbnRlZCAtIGFyZSB0aGUg c2xpZGVzIGZyb20NCj4gPmRyYWZ0LXJlZGR5DQo+ID5hcHByb3ByaWF0ZSBhcyBhIGp1bXBpbmct b2ZmIHBvaW50LCBvciBhcmUgdGhlcmUgb3RoZXIgc2xpZGVzIHRoYXQgeW91J2QNCj4gPnByZWZl cj8NCj4gPg0KPiA+SXQncyBvayBmb3IgeW91IHRvIG5vdCBhZ3JlZSB3aXRoIHRoZSBzbGlkZSBj b250ZW50cyBpZiB5b3UgcmV1c2Ugc29tZW9uZQ0KPiA+ZWxzZSdzIGRlY2s7LSkuDQo+IA0KPiBU aGUgc2xpZGVzIHByZXNlbnRlZCBhcmUgaGVyZToNCj4gDQo+IGh0dHBzOi8vd3d3LmlldGYub3Jn L3Byb2NlZWRpbmdzLzk0L3NsaWRlcy9zbGlkZXMtOTQtZG90cy01LnBkZg0KPiANCj4gDQo+IEni gJltIGZpbmUgd2l0aCB0aGVtIGJlaW5nIGEganVtcGluZyBvZmYgcG9pbnQgZm9yIHRoZSBkaXNj dXNzaW9uIC0gdGhlDQo+IGRpc2N1c3Npb24gaXMgYXJvdW5kIHRoZSDigJhTT1PigJkgbWVzc2Fn ZSB0cmFuc3BvcnQuDQo+IA0KPiBJIHdvdWxkIG9mIGNvdXJzZSBkZWZlciB0byBQcmFzaGFudGgg d2hvIHByZXNlbnRlZCBvcmlnaW5hbGx5IGFzIFRpcnUNCj4gY291bGRu4oCZdCBiZSBoZXJlIGlm IHRoZXkgd291bGQgcHJlZmVyIHRvIHJlcHJlc2VudCB0aGVpciBzbGlkZXMuDQo+IA0KPiBUaGFu a3MsDQo+IA0KPiAtTmlrDQo+IA0KDQo= From nobody Wed Nov 4 17:22: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 6CA371B35A6; Wed, 4 Nov 2015 17:22:37 -0800 (PST) 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 MRmzCi7fcG_L; Wed, 4 Nov 2015 17:22:35 -0800 (PST) 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 F0E101B35A4; Wed, 4 Nov 2015 17:22:34 -0800 (PST) Received: from [133.93.29.11] (dhcp-29-11.meeting.ietf94.jp [133.93.29.11]) by lvps5-35-241-16.dedicated.hosteurope.de (Postfix) with ESMTPSA id 7713263A1D; Thu, 5 Nov 2015 02:22:31 +0100 (CET) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=SmuydxR9rGEeEJkZUWYPsTa0M2YPeTZAx2o0z08lUwtvpC2nqe+Ycq9EPUkPKLR1o00mp+ViydzdlW+Mj2aYT72LS5CHmaqPQ6GYTrU1iHP2HHGk2Uubytkev21RetMAyJX7DSUTU2j4iTGp7C0qxBplUU+3JgT4TaXQCTGzqW0=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Message-ID: <563AAF53.5050509@gondrom.org> Date: Thu, 05 Nov 2015 10:22:27 +0900 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: david.black@emc.com, gorry@erg.abdn.ac.uk, aaron.falk@gmail.com References: <5638D31B.4080801@mti-systems.com> <0A836E5A-C801-4CF4-916C-41EA065D3D30@arbor.net> <20dadcd20c26d51c284fdc4697cdc8a9.squirrel@erg.abdn.ac.uk> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: dots@ietf.org, tsvwg@ietf.org, tsvwg-chairs@ietf.org Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 05 Nov 2015 01:22:37 -0000 Hi David, anything in the range of 1-5 minutes can be useful. From a practical point, the key objective is that it would be nice to have a few more "Transport Minds" looking at the protocols we need to use for some of DOTS communication (as some will be operating under duress). I will be in the TSV meeting to make the call for comments on that. Which will take about 1minute (=60 seconds.) If one of our editors likes to raise this by some more, that's fine. The objective is not to come to a solution or conclusion, but rather to create awareness for the problem and invite feedback from the transport area on this specific problem, so we don't screw things up. As saag and tsvwg are at the same time, I will be attending tsvwg to raise this issue while my co-chair Roman will be presenting our status at saag. Best, Tobias (co-chair DOTS) On 05/11/15 09:24, Black, David wrote: >> Seriously: I think it deserves a heads-up presentation of the problem to >> be addressed. > Yes, that can be done. I'm pre-bashing today's agenda now - we'll confirm > the changes at the start of the meeting - there's at least one other item > that needs to be added to the agenda. > > There is definitely time available for a heads-up presentation of the > problem (5-10 min). However ... there is definitely not time available > for an extensive discussion (e.g., 30min). > > I assume that this is about draft-reddy-dots-transport-01 - who's > volunteering to present (plus summarize relevant dots WG and mailing list > discussions)? > > Thanks, > --David > >> -----Original Message----- >> From: gorry@erg.abdn.ac.uk [mailto:gorry@erg.abdn.ac.uk] >> Sent: Wednesday, November 04, 2015 3:56 AM >> To: Aaron Falk >> Cc: tsvwg-chairs@ietf.org; dots@ietf.org; tsvwg@ietf.org >> Subject: Re: [tsvwg] [Dots] Best transport selection during an attack? >> >> I'm in favour - but I am currently in a different timezone to my co-chair >> - who is managing our agenda time... >> >> Curiously: think this could be an excellent extension to the TAPS API - >> saying you want robustness and letting it choose protocol - but we need >> first of all to see if we can get something useful from TAPS first before >> we build new "features":-) >> >> Seriously: I think it deserves a heads-up presentation of the problem to >> be addressed. >> >> Gorry >> >>> TSVWG chairs- >>> >>> Will you allocate some time for this topic? >>> >>> --aaron >>> >>> On Wed, Nov 4, 2015 at 7:10 AM, Roland Dobbins wrote: >>> >>>> On 4 Nov 2015, at 1:22, Ca By wrote: >>>> >>>> at least in the case i am most familiar with. >>>> It is important to keep this part in mind. >>>> >>>> With DOTS in UDP, you are putting the DOTs traffic in that path that >>>>> becomes the most lossy during a a DDoS. >>>>> >>>> This is an overgeneralization - see above. >>>> >>>> There are lots of topological and pathing assumptions being made, here, >>>> as >>>> well as policy-filtering assumptions. >>>> >>>> It has been clear from the beginning of this effort that both stateless >>>> and stateful transport options are necessary, due to overly-restrictive >>>> network access policies, edge QoSing as a (counterproductive, IMHO) >>>> measure >>>> against UDP reflection/amplification attacks, etc. This has been >>>> discussed >>>> on-list and in meetings, it's unclear why it's become contentious, all >>>> of a >>>> sudden. >>>> >>>> ----------------------------------- >>>> Roland Dobbins >>>> >>>> > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Wed Nov 4 17: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 687FD1B34E4 for ; Wed, 4 Nov 2015 17:40:46 -0800 (PST) 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 cNWgq3ksNWrf for ; Wed, 4 Nov 2015 17:40:45 -0800 (PST) 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 22EF51A877A for ; Wed, 4 Nov 2015 17:40:45 -0800 (PST) Received: by pasz6 with SMTP id z6so72344080pas.2 for ; Wed, 04 Nov 2015 17:40:44 -0800 (PST) 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; bh=RSVfP/zKuWdnUK0lrSS5S5uQvkLQWcw5tdLNtQ6VMfQ=; b=GhJs0Hoxcb58AZ/U76DyryvIVWTMSYsUQtOoXddvKoXMsSjVPmf07As15sDapCwlyK MBJtdSmhjtVhHCPk9hVe6TGPouXvS1XXSdbueBqPw5KtlT1byL7OLSIbZgV19sSmFcoD 8jlEtaJaeCEccokAjvz19VlRHPJbb772ZtVOo= 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; bh=RSVfP/zKuWdnUK0lrSS5S5uQvkLQWcw5tdLNtQ6VMfQ=; b=mm2mDadQPFVsC2jLHh8eswk2PwGlUj72FTXss/bLc8qpuy48dnfVGroAby8xBHZ3Kd IW0jgGpbVVCt0Wg6dq/BTKBLJNjfyuassq1rLzJ9SZ9PwK2tCQdTh7L7UB5mimoK4pYc NU7P/h2W2IrtHNmlHVdloI0XCmhTJUNCn7PUAWf/Jwaru97uM79tWUj51LyqR4mzJwgP i6QJJ9ntO9YaXeqgrU9NXeArkdGVxhtx+CIgzQRqrR7YiPyrvZC/6mWjiZ47GNvAPxQk QJdzmXOqd9VEk23BvvaezNv4tGRub/84tbuyfZ1Spc4Eb/y3wn+ajOOpsej2aCBJlLgn XNOQ== X-Gm-Message-State: ALoCoQnLCs+QyuyA7FInrjWqxpY6oMEF+dU/92brIFcFj68GW7vhfHIePLIapMaK402sH8bWbtk9 X-Received: by 10.66.97.105 with SMTP id dz9mr6019768pab.101.1446687644668; Wed, 04 Nov 2015 17:40:44 -0800 (PST) Received: from [10.0.1.3] (p5231-ipngn5001hodogaya.kanagawa.ocn.ne.jp. [153.220.164.231]) by smtp.gmail.com with ESMTPSA id k5sm4360559pbq.74.2015.11.04.17.40.42 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 04 Nov 2015 17:40:43 -0800 (PST) From: "Roland Dobbins" To: tsvwg@ietf.org Date: Thu, 05 Nov 2015 10:40:41 +0900 Message-ID: <198FCFB9-C51D-4B01-8750-2978195DE301@arbor.net> In-Reply-To: <563AAF53.5050509@gondrom.org> References: <5638D31B.4080801@mti-systems.com> <0A836E5A-C801-4CF4-916C-41EA065D3D30@arbor.net> <20dadcd20c26d51c284fdc4697cdc8a9.squirrel@erg.abdn.ac.uk> <563AAF53.5050509@gondrom.org> MIME-Version: 1.0 X-Mailer: MailMate (1.9.3r5164) Archived-At: Cc: dots@ietf.org, tsvwg-chairs@ietf.org Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 05 Nov 2015 01:40:46 -0000 On 5 Nov 2015, at 10:22, Tobias Gondrom wrote: > If one of our editors likes to raise this by some more, that's fine. Some background and context may be helpful for those new to DOTS: DOTS Operational Requirements overview preso .pdf from IETF 93: DOTS use-cases preso .pdf from IETF 94: draft-ietf-dots-requirements-00: draft-ietf-dots-use-cases-00: ----------------------------------- Roland Dobbins From nobody Wed Nov 4 17:50: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 96DDA1B361F; Wed, 4 Nov 2015 17:43:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, 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 Zbr-LYF22FgD; Wed, 4 Nov 2015 17:43:05 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (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 7D2AD1B361E; Wed, 4 Nov 2015 17:43:05 -0800 (PST) Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com [10.106.48.160]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id tA51gpOi012451 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 4 Nov 2015 20:42:52 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com tA51gpOi012451 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1446687773; bh=hVGf8ypiLha2f77wnzdZrfO0dwE=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=aTnn3GLT87ZfOaJ4OmIH4dBdlUUu5clVTtKB5Njtvbpvgmy/OW2AxB/msRhOxCz2z yHF0jOktQaRkCxVsmnXiwJnKuTfv4ecFxOwjhOICMxhF5P/IIv+zRcO0Rv84JuJSt6 8EnLZ4DcoY8h5jMXhRdJJqnpZw4zDUKb5nbY46ao= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com tA51gpOi012451 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd56.lss.emc.com (RSA Interceptor); Wed, 4 Nov 2015 20:42:27 -0500 Received: from mxhub16.corp.emc.com (mxhub16.corp.emc.com [128.222.70.237]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id tA51gaJJ010315 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Nov 2015 20:42:36 -0500 Received: from MXHUB202.corp.emc.com (10.253.68.28) by mxhub16.corp.emc.com (128.222.70.237) with Microsoft SMTP Server (TLS) id 8.3.327.1; Wed, 4 Nov 2015 20:42:36 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.60]) by MXHUB202.corp.emc.com ([10.253.68.28]) with mapi id 14.03.0266.001; Wed, 4 Nov 2015 20:42:35 -0500 From: "Black, David" To: Tobias Gondrom , "gorry@erg.abdn.ac.uk" , "aaron.falk@gmail.com" Thread-Topic: [Dots] [tsvwg] Best transport selection during an attack? Thread-Index: AQHRF2h2jJYY5BaIv0C+qsSb+Lvfa56Mozhw Date: Thu, 5 Nov 2015 01:42:34 +0000 Message-ID: References: <5638D31B.4080801@mti-systems.com> <0A836E5A-C801-4CF4-916C-41EA065D3D30@arbor.net> <20dadcd20c26d51c284fdc4697cdc8a9.squirrel@erg.abdn.ac.uk> <563AAF53.5050509@gondrom.org> In-Reply-To: <563AAF53.5050509@gondrom.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.13.35.86] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: public Archived-At: X-Mailman-Approved-At: Wed, 04 Nov 2015 17:50:10 -0800 Cc: "Black, David" , "dots@ietf.org" , "tsvwg@ietf.org" , "tsvwg-chairs@ietf.org" Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 05 Nov 2015 01:43:07 -0000 Hi Tobias, It looks like Nik has volunteered as the initial "designated victim" to foster this TSVWG discussion (I squeezed the agenda and think I found 10 minutes), plus based on a quick look, I see enough background in the slides for draft-reddy-dots-transport to explain the problem. If you'd prefer to go to saag, I'll be happy to pass along your request. On scheduling, my operating theory has been that as long as one tsvwg session doesn't conflict w/saag, things should be ok ... and you've just found the security flaw in that algorithm (can fail to deal w/security concerns that arise during the meeting week). I'll leave it to the SEC ADs to decide whether to put tsvwg on saag's=20 meeting conflict list. Perhaps you or Roman could mention that to them. Nik - thanks for stepping up! Thanks, --David > -----Original Message----- > From: Tobias Gondrom [mailto:tobias.gondrom@gondrom.org] > Sent: Wednesday, November 04, 2015 8:22 PM > To: Black, David; gorry@erg.abdn.ac.uk; aaron.falk@gmail.com > Cc: tsvwg@ietf.org; tsvwg-chairs@ietf.org; dots@ietf.org > Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? >=20 > Hi David, >=20 > anything in the range of 1-5 minutes can be useful. >=20 > From a practical point, the key objective is that it would be nice to > have a few more "Transport Minds" looking at the protocols we need to > use for some of DOTS communication (as some will be operating under > duress). >=20 > I will be in the TSV meeting to make the call for comments on that. > Which will take about 1minute (=3D60 seconds.) >=20 > If one of our editors likes to raise this by some more, that's fine. The > objective is not to come to a solution or conclusion, but rather to > create awareness for the problem and invite feedback from the transport > area on this specific problem, so we don't screw things up. >=20 > As saag and tsvwg are at the same time, I will be attending tsvwg to > raise this issue while my co-chair Roman will be presenting our status > at saag. >=20 > Best, Tobias (co-chair DOTS) >=20 >=20 >=20 >=20 >=20 > On 05/11/15 09:24, Black, David wrote: > >> Seriously: I think it deserves a heads-up presentation of the problem = to > >> be addressed. > > Yes, that can be done. I'm pre-bashing today's agenda now - we'll conf= irm > > the changes at the start of the meeting - there's at least one other it= em > > that needs to be added to the agenda. > > > > There is definitely time available for a heads-up presentation of the > > problem (5-10 min). However ... there is definitely not time available > > for an extensive discussion (e.g., 30min). > > > > I assume that this is about draft-reddy-dots-transport-01 - who's > > volunteering to present (plus summarize relevant dots WG and mailing li= st > > discussions)? > > > > Thanks, > > --David > > > >> -----Original Message----- > >> From: gorry@erg.abdn.ac.uk [mailto:gorry@erg.abdn.ac.uk] > >> Sent: Wednesday, November 04, 2015 3:56 AM > >> To: Aaron Falk > >> Cc: tsvwg-chairs@ietf.org; dots@ietf.org; tsvwg@ietf.org > >> Subject: Re: [tsvwg] [Dots] Best transport selection during an attack? > >> > >> I'm in favour - but I am currently in a different timezone to my co-ch= air > >> - who is managing our agenda time... > >> > >> Curiously: think this could be an excellent extension to the TAPS API = - > >> saying you want robustness and letting it choose protocol - but we nee= d > >> first of all to see if we can get something useful from TAPS first bef= ore > >> we build new "features":-) > >> > >> Seriously: I think it deserves a heads-up presentation of the problem = to > >> be addressed. > >> > >> Gorry > >> > >>> TSVWG chairs- > >>> > >>> Will you allocate some time for this topic? > >>> > >>> --aaron > >>> > >>> On Wed, Nov 4, 2015 at 7:10 AM, Roland Dobbins w= rote: > >>> > >>>> On 4 Nov 2015, at 1:22, Ca By wrote: > >>>> > >>>> at least in the case i am most familiar with. > >>>> It is important to keep this part in mind. > >>>> > >>>> With DOTS in UDP, you are putting the DOTs traffic in that path that > >>>>> becomes the most lossy during a a DDoS. > >>>>> > >>>> This is an overgeneralization - see above. > >>>> > >>>> There are lots of topological and pathing assumptions being made, he= re, > >>>> as > >>>> well as policy-filtering assumptions. > >>>> > >>>> It has been clear from the beginning of this effort that both statel= ess > >>>> and stateful transport options are necessary, due to overly-restrict= ive > >>>> network access policies, edge QoSing as a (counterproductive, IMHO) > >>>> measure > >>>> against UDP reflection/amplification attacks, etc. This has been > >>>> discussed > >>>> on-list and in meetings, it's unclear why it's become contentious, a= ll > >>>> of a > >>>> sudden. > >>>> > >>>> ----------------------------------- > >>>> Roland Dobbins > >>>> > >>>> > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots From nobody Wed Nov 4 17:50:18 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 0A6F01B361F; Wed, 4 Nov 2015 17:43:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 ZTIhBIvla73c; Wed, 4 Nov 2015 17:43:50 -0800 (PST) Received: from mx144.netapp.com (mx144.netapp.com [216.240.21.25]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DE721B3627; Wed, 4 Nov 2015 17:43:49 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.20,245,1444719600"; d="asc'?scan'208";a="78344648" Received: from hioexcmbx06-prd.hq.netapp.com ([10.122.105.39]) by mx144-out.netapp.com with ESMTP; 04 Nov 2015 17:42:49 -0800 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx06-prd.hq.netapp.com (10.122.105.39) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 4 Nov 2015 17:42:48 -0800 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::e1d9:911e:3048:d510%21]) with mapi id 15.00.1104.000; Wed, 4 Nov 2015 17:42:48 -0800 From: "Eggert, Lars" To: Andrew Mortensen Thread-Topic: [tsvwg] [Dots] Best transport selection during an attack? Thread-Index: AQHRF2Lwv1/VFujah0+VOSrMKLH6lp6MoumggACK9wA= Date: Thu, 5 Nov 2015 01:42:48 +0000 Message-ID: <833E87DD-66E2-4049-BF84-2CAFFBD58912@netapp.com> References: <5638D31B.4080801@mti-systems.com> <0A836E5A-C801-4CF4-916C-41EA065D3D30@arbor.net> <20dadcd20c26d51c284fdc4697cdc8a9.squirrel@erg.abdn.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3096.5) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.120.60.34] Content-Type: multipart/signed; boundary="Apple-Mail=_21E0BD36-83D1-4C2C-B33C-152AF1F0A828"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Wed, 04 Nov 2015 17:50:13 -0800 Cc: Gorry Fairhust , "Teague, Nik" , "tsvwg@ietf.org" , "tsvwg-chairs@ietf.org" , "dots@ietf.org" Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 05 Nov 2015 01:43:53 -0000 --Apple-Mail=_21E0BD36-83D1-4C2C-B33C-152AF1F0A828 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 2015-11-05, at 9:58, Andrew Mortensen wrote: >=20 > And in fairness to the authors of draft-reddy-dots-transport, I = believe they=E2=80=99re simply aligning the draft with the OP-001 = requirement in the requirements draft: >=20 > OP-001 Use of Common Transports: DOTS MUST operate over common > standardized transport protocols. While the protocol resilience > requirement strongly RECOMMENDS the use of connectionless > protocols, in particular the User Datagram Protocol (UDP) > use of a standardized, connection-oriented protocol > like the Transmission Control Protocol (TCP) MAY be > necessary due to network policy or middleware limitations. >=20 > = I wanted to make sure DOTS is aware of RFC5405 and its intended = successor draft-eggert-tsvwg-rfc5405bis. Lars --Apple-Mail=_21E0BD36-83D1-4C2C-B33C-152AF1F0A828 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBVjq0F9ZcnpRveo1xAQhaXQQAiRxCqh6P7FE+LPwp2P2J7i+i1EHI0O08 UBj/hcvg5CBswZ/uhH4zVeWXHeOVZZ9mwqb+3JCnQn9NjOKKX0K42ELTK1QO1Pmy JzhCsSNfsg2Lbm7QPp9od8Vcr+fQzSuNINbv+O6MBlENS+Mvapa2xPaTTwiM9joC /WGRzxmht3U= =pALf -----END PGP SIGNATURE----- --Apple-Mail=_21E0BD36-83D1-4C2C-B33C-152AF1F0A828-- From nobody Wed Nov 4 17:50: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 E88331B363D; Wed, 4 Nov 2015 17:44:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 8lMxedenLww6; Wed, 4 Nov 2015 17:44:48 -0800 (PST) Received: from mx142.netapp.com (mx142.netapp.com [216.240.21.19]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 149091B3624; Wed, 4 Nov 2015 17:44:48 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.20,245,1444719600"; d="asc'?scan'208";a="75109323" Received: from hioexcmbx04-prd.hq.netapp.com ([10.122.105.37]) by mx142-out.netapp.com with ESMTP; 04 Nov 2015 17:43:49 -0800 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx04-prd.hq.netapp.com (10.122.105.37) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 4 Nov 2015 17:43:47 -0800 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::e1d9:911e:3048:d510%21]) with mapi id 15.00.1104.000; Wed, 4 Nov 2015 17:43:47 -0800 From: "Eggert, Lars" To: Andrew Mortensen Thread-Topic: [tsvwg] [Dots] Best transport selection during an attack? Thread-Index: AQHRF2Lwv1/VFujah0+VOSrMKLH6lp6MoumggACK9wCAAABIAA== Date: Thu, 5 Nov 2015 01:43:47 +0000 Message-ID: <5FEA6D26-1C4F-44F7-8D4B-E06FA5390AC0@netapp.com> References: <5638D31B.4080801@mti-systems.com> <0A836E5A-C801-4CF4-916C-41EA065D3D30@arbor.net> <20dadcd20c26d51c284fdc4697cdc8a9.squirrel@erg.abdn.ac.uk> <833E87DD-66E2-4049-BF84-2CAFFBD58912@netapp.com> In-Reply-To: <833E87DD-66E2-4049-BF84-2CAFFBD58912@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3096.5) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.120.60.34] Content-Type: multipart/signed; boundary="Apple-Mail=_10C6D3DA-B603-4381-B1E7-59427AA9A883"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Wed, 04 Nov 2015 17:50:15 -0800 Cc: Gorry Fairhust , "Teague, Nik" , "tsvwg@ietf.org" , "tsvwg-chairs@ietf.org" , "dots@ietf.org" Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 05 Nov 2015 01:44:52 -0000 --Apple-Mail=_10C6D3DA-B603-4381-B1E7-59427AA9A883 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 2015-11-05, at 10:42, Lars Eggert wrote: > draft-eggert-tsvwg-rfc5405bis draft-ietf-tsvwg-rfc5405bis (copy/paste error) Lars --Apple-Mail=_10C6D3DA-B603-4381-B1E7-59427AA9A883 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBVjq0U9ZcnpRveo1xAQhucgP7BoOiGSQmUuoss8K12IKgTvXCn0Dl7T9D Put6NiALbc9daC7h0hgnKscc9nLw+URdAi2Tj52rEGvrNVxK/W/eaYtpO9n7kVyv u/Bv/lZf4F2ppqac3vWFmesTBOgRT6hFPUTfbGmwAtM4BKZ2UwrRxq+fkzUTm+kG ZwBhoGYU7/8= =blXq -----END PGP SIGNATURE----- --Apple-Mail=_10C6D3DA-B603-4381-B1E7-59427AA9A883-- From nobody Wed Nov 4 17:50: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 C12111B363A for ; Wed, 4 Nov 2015 17:50:15 -0800 (PST) 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 eihnIOsFh5Wt for ; Wed, 4 Nov 2015 17:50:15 -0800 (PST) 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 2C3EA1B3662 for ; Wed, 4 Nov 2015 17:50:09 -0800 (PST) Received: by pasz6 with SMTP id z6so72609738pas.2 for ; Wed, 04 Nov 2015 17:50:08 -0800 (PST) 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=VP2p43Thmak8ijTAHCHvv4gSjLbP9Jd/z0LY+nzsE04=; b=TR7TsJmDlxyfd15aEARkCKYzGaI8sKGZVlAXROJR4DlU71+vdjPagH5LPn39EbXnx5 kBCaykdZW4e6V4ClZxVwaG6kVNgOJ/pF8a6IlBGnFYiopbkIUUVaGWyn9/K7jU1gHZ9W BmZw3WRFlkobJNh/9tjpZz1nwnJumYIrmCUsI= 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=VP2p43Thmak8ijTAHCHvv4gSjLbP9Jd/z0LY+nzsE04=; b=Zqt5mw4l1OwkLrn2FemK7A8ACd1srnkP/6Z7PMA+cu4IlTjPbKSOuDpcknGl+7Qa+V m+Ce0ad6GCjSsPkAhGK3vhGNIgrj5DY1L0UBsXdhb6rbUT5kE8Ftd8LEpIwJNbq7SSe3 2KzLNFgTx/hPu04MCV41MgxR1A6A8FDHFYzjrW9dRzbo1Oi0DTxcfAlrYFkpYriCmllJ CLK+R+HI88LCB620DeweDefb1GkWrnwXPRBPGf/BUpzcqBB2qvXpeUK5bI5sfypGBrss GegI4KrtylYK0sryI5/ZGfjYBfVo9meMk0U858U6TXRt6vs52/ppmMEc1SCqmV2UjjjP AOGw== X-Gm-Message-State: ALoCoQmVMQth09BVpiWDKJdUBtX8hbRq3mGQ2BB9ryPv/pyEcvXAR85i9oloRNN2IdFtqXoCSyPK X-Received: by 10.66.219.163 with SMTP id pp3mr6018551pac.55.1446688208710; Wed, 04 Nov 2015 17:50:08 -0800 (PST) Received: from [10.0.1.3] (p5231-ipngn5001hodogaya.kanagawa.ocn.ne.jp. [153.220.164.231]) by smtp.gmail.com with ESMTPSA id k5sm4385788pbq.74.2015.11.04.17.50.06 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 04 Nov 2015 17:50:08 -0800 (PST) From: "Roland Dobbins" To: "tsvwg@ietf.org" Date: Thu, 05 Nov 2015 10:50:05 +0900 Message-ID: In-Reply-To: <5FEA6D26-1C4F-44F7-8D4B-E06FA5390AC0@netapp.com> References: <5638D31B.4080801@mti-systems.com> <0A836E5A-C801-4CF4-916C-41EA065D3D30@arbor.net> <20dadcd20c26d51c284fdc4697cdc8a9.squirrel@erg.abdn.ac.uk> <833E87DD-66E2-4049-BF84-2CAFFBD58912@netapp.com> <5FEA6D26-1C4F-44F7-8D4B-E06FA5390AC0@netapp.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5164) Archived-At: Cc: "tsvwg-chairs@ietf.org" , "dots@ietf.org" Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 05 Nov 2015 01:50:16 -0000 On 5 Nov 2015, at 10:43, Eggert, Lars wrote: > draft-ietf-tsvwg-rfc5405bis We are aware - I believe it has been discussed on-list, and has been brought up in verbal discussions. Thanks for the pointer! ----------------------------------- Roland Dobbins From nobody Wed Nov 4 17:54: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 6F97B1B36A3 for ; Wed, 4 Nov 2015 17:54:26 -0800 (PST) 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, HTML_MESSAGE=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 fVmLNRZsCaF9 for ; Wed, 4 Nov 2015 17:54:22 -0800 (PST) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::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 C82F61B369E for ; Wed, 4 Nov 2015 17:54:21 -0800 (PST) Received: by igpw7 with SMTP id w7so1854438igp.1 for ; Wed, 04 Nov 2015 17:54:21 -0800 (PST) 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=BJ6H5lU7I/fGX0DDU38PoLG386mWo/P1UXJWPAWlWhc=; b=Y6hICRPE77IdlHmFNrQLddCeX5AwCdVOosatrjYpYTqrkckZ99BfJf1LkUlBk+SSoq STO9V0PuQHb3/5TSVw96PDeiFFDFo+5b6plBThf5JVAMQ2XY2wozQNMsgEJ03oLPMVe4 YhX64ZKorOwZhTTssq8YJHeqnlbofemeEINeE= 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=BJ6H5lU7I/fGX0DDU38PoLG386mWo/P1UXJWPAWlWhc=; b=LF8i8WfjNTwniNklak9RmLPcA9BZJcUz6IwPTPNdZ9tcPVQbjfnEbaPm7vkNy/jzDq m2axTB4DxkTthzu38GuztII9DW7dd9Sh7XvVQIB4Z5RdiRjiHPiJY8jvBqQQqqRycf0O WOqGgn2rw70qKEApzx94eOt+KTYyx+i8iQIf7YcGtIBxxTawPIKu6vIc/dH6DvbsCkKZ 59/PXt4U1zjpbkVAvOEfLpYN5/dK2uOZcaA1uTpI8rSSDVuOuNuv0cfczVcrPop53haa fnl3/K25U0IApAnQeRRFUqb5vOiJUsmsznd2yDz2jD0cmfGPDO25jiAdS0YA7AVR8ato zCLQ== X-Gm-Message-State: ALoCoQmpI+DVLtcQ05BWV7ynEcYacQ8pCH4/7yi8QTSDY/TALFxhdC+0AJBKX+/rchOkigagp3At X-Received: by 10.50.97.37 with SMTP id dx5mr298286igb.14.1446688460960; Wed, 04 Nov 2015 17:54:20 -0800 (PST) Received: from dhcp-35-191.meeting.ietf94.jp (dhcp-35-191.meeting.ietf94.jp. [133.93.35.191]) by smtp.gmail.com with ESMTPSA id p62sm2099396ioe.1.2015.11.04.17.54.18 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Nov 2015 17:54:19 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_937CC277-371C-4A76-B1A8-F0DED19FD7A9" Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: "Mortensen, Andrew" In-Reply-To: <5FEA6D26-1C4F-44F7-8D4B-E06FA5390AC0@netapp.com> Date: Wed, 4 Nov 2015 20:54:16 -0500 Message-Id: <1C5A9479-A370-4086-A345-3F209DA6ED57@arbor.net> References: <5638D31B.4080801@mti-systems.com> <0A836E5A-C801-4CF4-916C-41EA065D3D30@arbor.net> <20dadcd20c26d51c284fdc4697cdc8a9.squirrel@erg.abdn.ac.uk> <833E87DD-66E2-4049-BF84-2CAFFBD58912@netapp.com> <5FEA6D26-1C4F-44F7-8D4B-E06FA5390AC0@netapp.com> To: "Eggert, Lars" X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: Gorry Fairhust , "Teague, Nik" , "tsvwg@ietf.org" , "tsvwg-chairs@ietf.org" , "dots@ietf.org" Subject: Re: [Dots] Best transport selection during an attack? 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, 05 Nov 2015 01:54:26 -0000 --Apple-Mail=_937CC277-371C-4A76-B1A8-F0DED19FD7A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Yes, thank you for bringing this up. Speaking for myself, I believe the = DOTS signal (distinct from bulk data exchanges, which must use reliable = transports per requirements draft) fits the low-traffic characteristics = of section 3.1.2. andrew On Thursday, November 5, 2015, Eggert, Lars > wrote: On 2015-11-05, at 10:42, Lars Eggert > = wrote: > draft-eggert-tsvwg-rfc5405bis draft-ietf-tsvwg-rfc5405bis (copy/paste error) Lars --Apple-Mail=_937CC277-371C-4A76-B1A8-F0DED19FD7A9 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Yes, thank you for bringing this up. Speaking for myself, I believe the DOTS signal (distinct from bulk data exchanges, which must use reliable transports per requirements draft) fits the low-traffic characteristics of section 3.1.2.

andrew



On Thursday, November 5, 2015, Eggert, Lars <lars@netapp.com> wrote:
On 2015-11-05, at 10:42, Lars Eggert <lars@netapp.com> wrote:
> draft-eggert-tsvwg-rfc5405bis

draft-ietf-tsvwg-rfc5405bis (copy/paste error)

Lars
--Apple-Mail=_937CC277-371C-4A76-B1A8-F0DED19FD7A9-- From nobody Wed Nov 4 17:54: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 D81841B36B0; Wed, 4 Nov 2015 17:54:38 -0800 (PST) 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 Bak5efadOGB9; Wed, 4 Nov 2015 17:54:37 -0800 (PST) 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 36A951A883F; Wed, 4 Nov 2015 17:54:34 -0800 (PST) Received: from [133.93.29.11] (dhcp-29-11.meeting.ietf94.jp [133.93.29.11]) by lvps5-35-241-16.dedicated.hosteurope.de (Postfix) with ESMTPSA id D2DDD63A1D; Thu, 5 Nov 2015 02:54:30 +0100 (CET) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=2kk+usLr9XTkoRr2/Uhdots9p6M6Pg9qpoKaC29d97wGSMOj0YYfVFBR0tzAxZHYHv4Evb40W+XURKN0HXf01JCVDh7k6j3+qC/1W9aVEhwJ1jPFteC5ktHurVQVgvmBBL0QvRtHvmN7lm1k9T+cHTEOUhMhmGRIlPqG7fdbGVE=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Message-ID: <563AB6D3.3070803@gondrom.org> Date: Thu, 05 Nov 2015 10:54:27 +0900 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: david.black@emc.com, gorry@erg.abdn.ac.uk, aaron.falk@gmail.com References: <5638D31B.4080801@mti-systems.com> <0A836E5A-C801-4CF4-916C-41EA065D3D30@arbor.net> <20dadcd20c26d51c284fdc4697cdc8a9.squirrel@erg.abdn.ac.uk> <563AAF53.5050509@gondrom.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: dots@ietf.org, tsvwg@ietf.org, tsvwg-chairs@ietf.org Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 05 Nov 2015 01:54:39 -0000 Hi David, no problem. All good. If possible, could I get from the DOTS time the first 30 seconds for a quick call from a DOTS WG chair organisational perspective and am then very happy for Nik to talk about the technical issue and where we need advise. And no worries, there is no conflict. That is the benefit of having two co-chairs. If I can roughly know the time when you plan the DOTS related time slot, that would be helpful, but not essential I will come to you at the beginning of TSV. Cheers, Tobias On 05/11/15 10:42, Black, David wrote: > Hi Tobias, > > It looks like Nik has volunteered as the initial "designated victim" to > foster this TSVWG discussion (I squeezed the agenda and think I found > 10 minutes), plus based on a quick look, I see enough background in the > slides for draft-reddy-dots-transport to explain the problem. > > If you'd prefer to go to saag, I'll be happy to pass along your request. > > On scheduling, my operating theory has been that as long as one tsvwg > session doesn't conflict w/saag, things should be ok ... and you've just > found the security flaw in that algorithm (can fail to deal w/security > concerns that arise during the meeting week). > > I'll leave it to the SEC ADs to decide whether to put tsvwg on saag's > meeting conflict list. Perhaps you or Roman could mention that to them. > > Nik - thanks for stepping up! > > Thanks, > --David > >> -----Original Message----- >> From: Tobias Gondrom [mailto:tobias.gondrom@gondrom.org] >> Sent: Wednesday, November 04, 2015 8:22 PM >> To: Black, David; gorry@erg.abdn.ac.uk; aaron.falk@gmail.com >> Cc: tsvwg@ietf.org; tsvwg-chairs@ietf.org; dots@ietf.org >> Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? >> >> Hi David, >> >> anything in the range of 1-5 minutes can be useful. >> >> From a practical point, the key objective is that it would be nice to >> have a few more "Transport Minds" looking at the protocols we need to >> use for some of DOTS communication (as some will be operating under >> duress). >> >> I will be in the TSV meeting to make the call for comments on that. >> Which will take about 1minute (=60 seconds.) >> >> If one of our editors likes to raise this by some more, that's fine. The >> objective is not to come to a solution or conclusion, but rather to >> create awareness for the problem and invite feedback from the transport >> area on this specific problem, so we don't screw things up. >> >> As saag and tsvwg are at the same time, I will be attending tsvwg to >> raise this issue while my co-chair Roman will be presenting our status >> at saag. >> >> Best, Tobias (co-chair DOTS) >> >> >> >> >> >> On 05/11/15 09:24, Black, David wrote: >>>> Seriously: I think it deserves a heads-up presentation of the problem to >>>> be addressed. >>> Yes, that can be done. I'm pre-bashing today's agenda now - we'll confirm >>> the changes at the start of the meeting - there's at least one other item >>> that needs to be added to the agenda. >>> >>> There is definitely time available for a heads-up presentation of the >>> problem (5-10 min). However ... there is definitely not time available >>> for an extensive discussion (e.g., 30min). >>> >>> I assume that this is about draft-reddy-dots-transport-01 - who's >>> volunteering to present (plus summarize relevant dots WG and mailing list >>> discussions)? >>> >>> Thanks, >>> --David >>> >>>> -----Original Message----- >>>> From: gorry@erg.abdn.ac.uk [mailto:gorry@erg.abdn.ac.uk] >>>> Sent: Wednesday, November 04, 2015 3:56 AM >>>> To: Aaron Falk >>>> Cc: tsvwg-chairs@ietf.org; dots@ietf.org; tsvwg@ietf.org >>>> Subject: Re: [tsvwg] [Dots] Best transport selection during an attack? >>>> >>>> I'm in favour - but I am currently in a different timezone to my co-chair >>>> - who is managing our agenda time... >>>> >>>> Curiously: think this could be an excellent extension to the TAPS API - >>>> saying you want robustness and letting it choose protocol - but we need >>>> first of all to see if we can get something useful from TAPS first before >>>> we build new "features":-) >>>> >>>> Seriously: I think it deserves a heads-up presentation of the problem to >>>> be addressed. >>>> >>>> Gorry >>>> >>>>> TSVWG chairs- >>>>> >>>>> Will you allocate some time for this topic? >>>>> >>>>> --aaron >>>>> >>>>> On Wed, Nov 4, 2015 at 7:10 AM, Roland Dobbins wrote: >>>>> >>>>>> On 4 Nov 2015, at 1:22, Ca By wrote: >>>>>> >>>>>> at least in the case i am most familiar with. >>>>>> It is important to keep this part in mind. >>>>>> >>>>>> With DOTS in UDP, you are putting the DOTs traffic in that path that >>>>>>> becomes the most lossy during a a DDoS. >>>>>>> >>>>>> This is an overgeneralization - see above. >>>>>> >>>>>> There are lots of topological and pathing assumptions being made, here, >>>>>> as >>>>>> well as policy-filtering assumptions. >>>>>> >>>>>> It has been clear from the beginning of this effort that both stateless >>>>>> and stateful transport options are necessary, due to overly-restrictive >>>>>> network access policies, edge QoSing as a (counterproductive, IMHO) >>>>>> measure >>>>>> against UDP reflection/amplification attacks, etc. This has been >>>>>> discussed >>>>>> on-list and in meetings, it's unclear why it's become contentious, all >>>>>> of a >>>>>> sudden. >>>>>> >>>>>> ----------------------------------- >>>>>> Roland Dobbins >>>>>> >>>>>> >>> _______________________________________________ >>> Dots mailing list >>> Dots@ietf.org >>> https://www.ietf.org/mailman/listinfo/dots From nobody Wed Nov 4 18:33: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 704481B38E4; Wed, 4 Nov 2015 18:33:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, 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 ANgaVDQicmpQ; Wed, 4 Nov 2015 18:33:09 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (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 3F22C1B38E1; Wed, 4 Nov 2015 18:33:09 -0800 (PST) Received: from maildlpprd02.lss.emc.com (maildlpprd02.lss.emc.com [10.253.24.34]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id tA52X06i006601 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 4 Nov 2015 21:33:01 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com tA52X06i006601 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1446690781; bh=93HgMcuA2k0xsmkHObrgjKMqM4s=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=PFLs90RCV4ykXQiwDTQh4InL6jIKlXe+MUR3OLV5JEvNlBYbQ2hPg3TKpDer9flP6 Kbof96Wvi/kmZDbC53EIv0iQ5iR7ebYwOoUmSEzMcSl/7zK0QqNEPFYI+rBQ3lDhcM bzSATqUOUNSLWtzYXwHb+0uFL6k/uv/rNIPx9EWI= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com tA52X06i006601 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd02.lss.emc.com (RSA Interceptor); Wed, 4 Nov 2015 21:30:45 -0500 Received: from mxhub24.corp.emc.com (mxhub24.corp.emc.com [128.222.70.136]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id tA52WjiG029466 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Nov 2015 21:32:46 -0500 Received: from MXHUB209.corp.emc.com (10.253.68.35) by mxhub24.corp.emc.com (128.222.70.136) with Microsoft SMTP Server (TLS) id 8.3.327.1; Wed, 4 Nov 2015 21:32:45 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.60]) by MXHUB209.corp.emc.com ([10.253.68.35]) with mapi id 14.03.0266.001; Wed, 4 Nov 2015 21:32:44 -0500 From: "Black, David" To: Tobias Gondrom , "gorry@erg.abdn.ac.uk" , "aaron.falk@gmail.com" Thread-Topic: [Dots] [tsvwg] Best transport selection during an attack? Thread-Index: AQHRF2h2jJYY5BaIv0C+qsSb+Lvfa56MozhwgABbloD//7Y5MA== Date: Thu, 5 Nov 2015 02:32:43 +0000 Message-ID: References: <5638D31B.4080801@mti-systems.com> <0A836E5A-C801-4CF4-916C-41EA065D3D30@arbor.net> <20dadcd20c26d51c284fdc4697cdc8a9.squirrel@erg.abdn.ac.uk> <563AAF53.5050509@gondrom.org> <563AB6D3.3070803@gondrom.org> In-Reply-To: <563AB6D3.3070803@gondrom.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.13.35.86] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "Black, David" , "dots@ietf.org" , "tsvwg@ietf.org" , "tsvwg-chairs@ietf.org" Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 05 Nov 2015 02:33:11 -0000 Hi Tobias, Sure, happy to give you 30 seconds during the initial agenda review/bash. DOTS session is at very end (last 10 minutes), but we might get to it early= . Thanks, --David > -----Original Message----- > From: Tobias Gondrom [mailto:tobias.gondrom@gondrom.org] > Sent: Wednesday, November 04, 2015 8:54 PM > To: Black, David; gorry@erg.abdn.ac.uk; aaron.falk@gmail.com > Cc: tsvwg@ietf.org; tsvwg-chairs@ietf.org; dots@ietf.org > Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? >=20 > Hi David, >=20 > no problem. All good. > If possible, could I get from the DOTS time the first 30 seconds for a > quick call from a DOTS WG chair organisational perspective and am then > very happy for Nik to talk about the technical issue and where we need > advise. >=20 > And no worries, there is no conflict. That is the benefit of having two > co-chairs. > If I can roughly know the time when you plan the DOTS related time slot, > that would be helpful, but not essential >=20 > I will come to you at the beginning of TSV. >=20 > Cheers, Tobias >=20 >=20 > On 05/11/15 10:42, Black, David wrote: > > Hi Tobias, > > > > It looks like Nik has volunteered as the initial "designated victim" to > > foster this TSVWG discussion (I squeezed the agenda and think I found > > 10 minutes), plus based on a quick look, I see enough background in the > > slides for draft-reddy-dots-transport to explain the problem. > > > > If you'd prefer to go to saag, I'll be happy to pass along your request= . > > > > On scheduling, my operating theory has been that as long as one tsvwg > > session doesn't conflict w/saag, things should be ok ... and you've jus= t > > found the security flaw in that algorithm (can fail to deal w/security > > concerns that arise during the meeting week). > > > > I'll leave it to the SEC ADs to decide whether to put tsvwg on saag's > > meeting conflict list. Perhaps you or Roman could mention that to them= . > > > > Nik - thanks for stepping up! > > > > Thanks, > > --David > > > >> -----Original Message----- > >> From: Tobias Gondrom [mailto:tobias.gondrom@gondrom.org] > >> Sent: Wednesday, November 04, 2015 8:22 PM > >> To: Black, David; gorry@erg.abdn.ac.uk; aaron.falk@gmail.com > >> Cc: tsvwg@ietf.org; tsvwg-chairs@ietf.org; dots@ietf.org > >> Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? > >> > >> Hi David, > >> > >> anything in the range of 1-5 minutes can be useful. > >> > >> From a practical point, the key objective is that it would be nice t= o > >> have a few more "Transport Minds" looking at the protocols we need to > >> use for some of DOTS communication (as some will be operating under > >> duress). > >> > >> I will be in the TSV meeting to make the call for comments on that. > >> Which will take about 1minute (=3D60 seconds.) > >> > >> If one of our editors likes to raise this by some more, that's fine. T= he > >> objective is not to come to a solution or conclusion, but rather to > >> create awareness for the problem and invite feedback from the transpor= t > >> area on this specific problem, so we don't screw things up. > >> > >> As saag and tsvwg are at the same time, I will be attending tsvwg to > >> raise this issue while my co-chair Roman will be presenting our status > >> at saag. > >> > >> Best, Tobias (co-chair DOTS) > >> > >> > >> > >> > >> > >> On 05/11/15 09:24, Black, David wrote: > >>>> Seriously: I think it deserves a heads-up presentation of the proble= m to > >>>> be addressed. > >>> Yes, that can be done. I'm pre-bashing today's agenda now - we'll co= nfirm > >>> the changes at the start of the meeting - there's at least one other = item > >>> that needs to be added to the agenda. > >>> > >>> There is definitely time available for a heads-up presentation of the > >>> problem (5-10 min). However ... there is definitely not time availab= le > >>> for an extensive discussion (e.g., 30min). > >>> > >>> I assume that this is about draft-reddy-dots-transport-01 - who's > >>> volunteering to present (plus summarize relevant dots WG and mailing = list > >>> discussions)? > >>> > >>> Thanks, > >>> --David > >>> > >>>> -----Original Message----- > >>>> From: gorry@erg.abdn.ac.uk [mailto:gorry@erg.abdn.ac.uk] > >>>> Sent: Wednesday, November 04, 2015 3:56 AM > >>>> To: Aaron Falk > >>>> Cc: tsvwg-chairs@ietf.org; dots@ietf.org; tsvwg@ietf.org > >>>> Subject: Re: [tsvwg] [Dots] Best transport selection during an attac= k? > >>>> > >>>> I'm in favour - but I am currently in a different timezone to my co-= chair > >>>> - who is managing our agenda time... > >>>> > >>>> Curiously: think this could be an excellent extension to the TAPS AP= I - > >>>> saying you want robustness and letting it choose protocol - but we n= eed > >>>> first of all to see if we can get something useful from TAPS first b= efore > >>>> we build new "features":-) > >>>> > >>>> Seriously: I think it deserves a heads-up presentation of the proble= m to > >>>> be addressed. > >>>> > >>>> Gorry > >>>> > >>>>> TSVWG chairs- > >>>>> > >>>>> Will you allocate some time for this topic? > >>>>> > >>>>> --aaron > >>>>> > >>>>> On Wed, Nov 4, 2015 at 7:10 AM, Roland Dobbins > wrote: > >>>>> > >>>>>> On 4 Nov 2015, at 1:22, Ca By wrote: > >>>>>> > >>>>>> at least in the case i am most familiar with. > >>>>>> It is important to keep this part in mind. > >>>>>> > >>>>>> With DOTS in UDP, you are putting the DOTs traffic in that path th= at > >>>>>>> becomes the most lossy during a a DDoS. > >>>>>>> > >>>>>> This is an overgeneralization - see above. > >>>>>> > >>>>>> There are lots of topological and pathing assumptions being made, = here, > >>>>>> as > >>>>>> well as policy-filtering assumptions. > >>>>>> > >>>>>> It has been clear from the beginning of this effort that both stat= eless > >>>>>> and stateful transport options are necessary, due to overly-restri= ctive > >>>>>> network access policies, edge QoSing as a (counterproductive, IMHO= ) > >>>>>> measure > >>>>>> against UDP reflection/amplification attacks, etc. This has been > >>>>>> discussed > >>>>>> on-list and in meetings, it's unclear why it's become contentious,= all > >>>>>> of a > >>>>>> sudden. > >>>>>> > >>>>>> ----------------------------------- > >>>>>> Roland Dobbins > >>>>>> > >>>>>> > >>> _______________________________________________ > >>> Dots mailing list > >>> Dots@ietf.org > >>> https://www.ietf.org/mailman/listinfo/dots From nobody Wed Nov 4 22:09:02 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 474941B3A58; Wed, 4 Nov 2015 22:09:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.597 X-Spam-Level: X-Spam-Status: No, score=0.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 7rWgRE8Qeeex; Wed, 4 Nov 2015 22:09:00 -0800 (PST) Received: from guri.nttv6.jp (guri.nttv6.jp [115.69.231.228]) by ietfa.amsl.com (Postfix) with ESMTP id D58591B3A57; Wed, 4 Nov 2015 22:08:59 -0800 (PST) Received: from z.nttv6.jp (z.nttv6.jp [192.168.8.15]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id 3939E4E8DB; Thu, 5 Nov 2015 15:08:59 +0900 (JST) Received: from [IPv6:::1] (fujiko.nttv6.jp [IPv6:2402:c800:ff06:136::141]) by z.nttv6.jp (NTTv6MTA) with ESMTPS id 266663ACA8; Thu, 5 Nov 2015 15:08:59 +0900 (JST) To: Roland Dobbins , dots@ietf.org References: <5638D31B.4080801@mti-systems.com> <10B4A768-25EC-4AFF-99D0-1BEC1C24CF2A@arbor.net> From: kaname nishizuka Message-ID: <563AF27B.8010009@nttv6.jp> Date: Thu, 5 Nov 2015 15:08:59 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <10B4A768-25EC-4AFF-99D0-1BEC1C24CF2A@arbor.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: tsvwg@ietf.org Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 05 Nov 2015 06:09:01 -0000 >the only mission-critical DOTS messages are mitigation service requests from DOTS clients and mitigation service refusals from DOTS servers. I'm in favor of the pointing out of the latter point: mitigation service refusals from DOTS servers. In operator's point of view, returning of status is indispensable to know the mitigation is succeed or not. Without such information, it will take more time to decide the next action, so it will harm the victim longer. IMHO, in this meaning, "SOS" is a little bit confusing because it seems like the signaling is one directional. regards, kaname nishizuka On 2015/11/04 10:37, Roland Dobbins wrote: > On 4 Nov 2015, at 10:29, Aaron Falk wrote: > >> And, you might not be able to tell you have a problem getting UDP through until you are under attack, >> when some operator may implement filtering that inhibits connectivity. > > Regular heartbeats between clients and servers, clients and relays, and relays and servers can serve the function of ensuring end-to-end connectivity on an ongoing basis. > > Failure to receive service request acknowledgements can serve this purpose under duress. > > It's expected that DOTS clients will update DOTS servers (either directly or via DOTS relays) with either continued mitigation requests and/or situational updates with regards to mitigation efficacy throughout mitigation service windows. Likewise, DOTS servers are expected to do the same with regards to DOTS clients (again, either directly or via DOTS relays). > > Note that other than a DOTS server receiving a DOTS mitigation service requests, none of these message types are necessary in order to mitigation service to be initiated. They are important and useful, but not mission-critical; the only mission-critical DOTS messages are mitigation service requests from DOTS clients and mitigation service refusals from DOTS servers. > > ----------------------------------- > Roland Dobbins > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Wed Nov 4 22:24: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 80D331B3A5F for ; Wed, 4 Nov 2015 22:24:13 -0800 (PST) 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 lJNFb0kRqUpK for ; Wed, 4 Nov 2015 22:24:12 -0800 (PST) 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 4A9DD1B3A46 for ; Wed, 4 Nov 2015 22:24:12 -0800 (PST) Received: by qgad10 with SMTP id d10so4602621qga.3 for ; Wed, 04 Nov 2015 22:24:11 -0800 (PST) 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=tztZrl3Goy25ZUBLq2iwGApyzbGDgfnRWIbMvQmQ46Y=; b=jjSDLWMutH32dkgNF32fBnhMsQMfYAxVxM5NrnGGo/d4pOMIWAV5J0WvsixDdEJxOd JNfNoKiYznQjSytAzmvmZvwUmUTpYkiH6DcuvOmU2olzbJ2aP/ygd56xar9+qyRQaNDh 5ZidAbrEjKpGXtEQpvYckKsx7gyfPby0aQtlUWQnCdDoQlUBpJ28MuKzIVtqQX8/IFC4 MZS2tdplxYR9vfpG/SxLGR/ogdWfGyZN1QrxIHzNfs9tIxJ7z9uFUnG5tLDswd8obhAC erNWp16FtowjCd7hh/APzyfyxfL6twCIWhET/ERogOH96tUdDFbecUrqnjNAWHUTzY8P em3g== X-Gm-Message-State: ALoCoQlJ8OsYpD69TaQhcjYpU1dqHgI20Mzy3TvC4q1m5ojeOtoCPbqUWCu5NMxIn5e7WyZLdVTyeCunmi081P/DR70ivoY8Uw== X-Received: by 10.55.16.165 with SMTP id 37mr5775964qkq.31.1446704651489; Wed, 04 Nov 2015 22:24:11 -0800 (PST) Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by smtp-relay.gmail.com with ESMTPS id f126sm328279qkb.8.2015.11.04.22.24.11 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 04 Nov 2015 22:24:11 -0800 (PST) X-Relaying-Domain: verisign.com Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02 [10.173.152.206]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id tA56OAET010079 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 5 Nov 2015 01:24:11 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Thu, 5 Nov 2015 01:24:09 -0500 From: "Teague, Nik" To: kaname nishizuka , Roland Dobbins , "dots@ietf.org" Thread-Topic: [Dots] [tsvwg] Best transport selection during an attack? Thread-Index: AQHRF5B567bMtM0zCkG+51q6FVOWPp6N4LMA Date: Thu, 5 Nov 2015 06:24:09 +0000 Message-ID: References: <5638D31B.4080801@mti-systems.com> <10B4A768-25EC-4AFF-99D0-1BEC1C24CF2A@arbor.net> <563AF27B.8010009@nttv6.jp> In-Reply-To: <563AF27B.8010009@nttv6.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="utf-8" Content-ID: <36D402830E404E46887053C6A761C919@verisign.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tsvwg@ietf.org" Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 05 Nov 2015 06:24:13 -0000 T24gMDUvMTEvMjAxNSAxNTowOCwgIkRvdHMgb24gYmVoYWxmIG9mIGthbmFtZSBuaXNoaXp1a2Ei DQo8ZG90cy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBrYW5hbWVAbnR0djYuanA+IHdy b3RlOg0KPg0KPklNSE8sIGluIHRoaXMgbWVhbmluZywgIlNPUyIgaXMgYSBsaXR0bGUgYml0IGNv bmZ1c2luZyBiZWNhdXNlIGl0IHNlZW1zDQo+bGlrZSB0aGUgc2lnbmFsaW5nIGlzIG9uZSBkaXJl Y3Rpb25hbC4NCg0KV2Ugc2hvdWxkIHByb2JhYmx5IHN0YW5kYXJkaXNlIG9uIHNvbWV0aGluZyBs aWtlIG1pdGlnYXRpb24gc2VydmljZQ0KcmVxdWVzdCwgcmVzcG9uc2UgYW5kIHN0YXR1cyg/KS4N Cg0KLW5paw0KDQo= From nobody Wed Nov 4 23:39: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 7F6D21B3B83; Wed, 4 Nov 2015 23:39:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 eSeg8Omy_rpP; Wed, 4 Nov 2015 23:39:56 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CE821B3B80; Wed, 4 Nov 2015 23:39:56 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id EF4F322C6CC; Thu, 5 Nov 2015 08:39:54 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.57]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id B375435C06A; Thu, 5 Nov 2015 08:39:54 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3%19]) with mapi id 14.03.0248.002; Thu, 5 Nov 2015 08:39:54 +0100 From: To: kaname nishizuka , Roland Dobbins , "dots@ietf.org" Thread-Topic: [Dots] [tsvwg] Best transport selection during an attack? Thread-Index: AQHRF5B5NOthr1TFokCFMiTlAmT/Qp6NCnNw Date: Thu, 5 Nov 2015 07:39:53 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008C98037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <5638D31B.4080801@mti-systems.com> <10B4A768-25EC-4AFF-99D0-1BEC1C24CF2A@arbor.net> <563AF27B.8010009@nttv6.jp> In-Reply-To: <563AF27B.8010009@nttv6.jp> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.10.16.122716 Archived-At: Cc: "tsvwg@ietf.org" Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 05 Nov 2015 07:39:58 -0000 Hi Kaname, I agree with your comment about the status.=20 FYI, we had this requirement in -00 of https://tools.ietf.org/html/draft-re= ddy-dots-transport-00#section-4:=20 o Acknowledgement for the processing of a filtering request and the enforcement of associated countermeasures. Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de kaname nishizuka > Envoy=E9=A0: jeudi 5 novembre 2015 07:09 > =C0=A0: Roland Dobbins; dots@ietf.org > Cc=A0: tsvwg@ietf.org > Objet=A0: Re: [Dots] [tsvwg] Best transport selection during an attack? >=20 >=20 > >the only mission-critical DOTS messages are mitigation service requests > from DOTS clients and mitigation service refusals from DOTS servers. >=20 > I'm in favor of the pointing out of the latter point: mitigation service > refusals from DOTS servers. > In operator's point of view, returning of status is indispensable to know > the mitigation is succeed or not. > Without such information, it will take more time to decide the next > action, so it will harm the victim longer. >=20 > IMHO, in this meaning, "SOS" is a little bit confusing because it seems > like the signaling is one directional. >=20 > regards, > kaname nishizuka >=20 >=20 > On 2015/11/04 10:37, Roland Dobbins wrote: > > On 4 Nov 2015, at 10:29, Aaron Falk wrote: > > > >> And, you might not be able to tell you have a problem getting UDP > through until you are under attack, > >> when some operator may implement filtering that inhibits connectivity. > > > > Regular heartbeats between clients and servers, clients and relays, and > relays and servers can serve the function of ensuring end-to-end > connectivity on an ongoing basis. > > > > Failure to receive service request acknowledgements can serve this > purpose under duress. > > > > It's expected that DOTS clients will update DOTS servers (either > directly or via DOTS relays) with either continued mitigation requests > and/or situational updates with regards to mitigation efficacy throughout > mitigation service windows. Likewise, DOTS servers are expected to do th= e > same with regards to DOTS clients (again, either directly or via DOTS > relays). > > > > Note that other than a DOTS server receiving a DOTS mitigation service > requests, none of these message types are necessary in order to mitigatio= n > service to be initiated. They are important and useful, but not mission- > critical; the only mission-critical DOTS messages are mitigation service > requests from DOTS clients and mitigation service refusals from DOTS > servers. > > > > ----------------------------------- > > Roland Dobbins > > > > _______________________________________________ > > 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 Nov 5 00:14: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 AF5B81A1B13 for ; Thu, 5 Nov 2015 00:14:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 sC8F4TjlUC1V for ; Thu, 5 Nov 2015 00:14:18 -0800 (PST) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::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 AB66C1A1B76 for ; Thu, 5 Nov 2015 00:14:13 -0800 (PST) Received: by igbhv6 with SMTP id hv6so5887003igb.0 for ; Thu, 05 Nov 2015 00:14:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xdgabJq5TniNQN9nNnjbJSRB8JZ0uLap3Pk8LdNoWFo=; b=VgrvcmH06KnVjvK4dm6TWvgKBt1boMVxsKexp98qekEzhYp+KFeZnTXH3QWOH/Edjt idEOZ3+pGrKe8bKxD4q4KxKC33bC+fBoQPEE9mrgMn0lQKxCDuCfnNqYmvzlpNvWxqeY U+K+2WZIg2XczFnTWF2SGY3KmR4IAaDlc9kKM= 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=xdgabJq5TniNQN9nNnjbJSRB8JZ0uLap3Pk8LdNoWFo=; b=VOQewMhbUM+Ej+kXCdwFwSwl7zN4hsX9qn7AV6SoSKoPYAoDw/xEluF9bcUjxsx2fc 8orNyt7Wwk3oAa/0ZPBIygmfNBIsFV94swfgvsCkHWHBYqoq86Ypk7PLfsGDZp71wHyN 255oARfKugdIhq8LtvUL/GjYUT0OFL6vZ4VeyqPLbTaIqkR+cVQ83XSVjP1MBVQ+p22b 6+9GyFTBhIxZ4LVeSd5kfcJlSqGCP4KkvX50nc10ny/3g3HpNWNR1O/u/n1ZCGeWJsux K/MfEsKHfSBYobQNWKi6p/i4sLUt0ynlbJpdAa5KlejjHOpYpl7QIZKKA+c1etez3WF8 j+Zg== X-Gm-Message-State: ALoCoQk8t7GRXLZIvJ/yYbzRWhdfwGqwklGnlsLUKrZrAIA/EoxPphp1ZmzndM2ANYFFGtgU5oPR MIME-Version: 1.0 X-Received: by 10.50.73.137 with SMTP id l9mr1599077igv.85.1446711253042; Thu, 05 Nov 2015 00:14:13 -0800 (PST) Received: by 10.64.69.169 with HTTP; Thu, 5 Nov 2015 00:14:12 -0800 (PST) In-Reply-To: <787AE7BB302AE849A7480A190F8B933008C98037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <5638D31B.4080801@mti-systems.com> <10B4A768-25EC-4AFF-99D0-1BEC1C24CF2A@arbor.net> <563AF27B.8010009@nttv6.jp> <787AE7BB302AE849A7480A190F8B933008C98037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Thu, 5 Nov 2015 03:14:12 -0500 Message-ID: From: "Mortensen, Andrew" To: "mohamed.boucadair@orange.com" Content-Type: multipart/alternative; boundary=089e013a226854c81d0523c6b622 Archived-At: Cc: Roland Dobbins , "dots@ietf.org" , kaname nishizuka , "tsvwg@ietf.org" Subject: Re: [Dots] Best transport selection during an attack? 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, 05 Nov 2015 08:14:19 -0000 --089e013a226854c81d0523c6b622 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes, this is captured in OP-005 of the requirements draft. I encourage WG members to read it and send feedback. Thank you. andrew On Thursday, November 5, 2015, wrote: > Hi Kaname, > > I agree with your comment about the status. > > FYI, we had this requirement in -00 of > https://tools.ietf.org/html/draft-reddy-dots-transport-00#section-4: > > o Acknowledgement for the processing of a filtering request and the > enforcement of associated countermeasures. > > Cheers, > Med > > > -----Message d'origine----- > > De : Dots [mailto:dots-bounces@ietf.org ] De la part de > kaname nishizuka > > Envoy=C3=A9 : jeudi 5 novembre 2015 07:09 > > =C3=80 : Roland Dobbins; dots@ietf.org > > Cc : tsvwg@ietf.org > > Objet : Re: [Dots] [tsvwg] Best transport selection during an attack? > > > > > > >the only mission-critical DOTS messages are mitigation service reques= ts > > from DOTS clients and mitigation service refusals from DOTS servers. > > > > I'm in favor of the pointing out of the latter point: mitigation servic= e > > refusals from DOTS servers. > > In operator's point of view, returning of status is indispensable to kn= ow > > the mitigation is succeed or not. > > Without such information, it will take more time to decide the next > > action, so it will harm the victim longer. > > > > IMHO, in this meaning, "SOS" is a little bit confusing because it seems > > like the signaling is one directional. > > > > regards, > > kaname nishizuka > > > > > > On 2015/11/04 10:37, Roland Dobbins wrote: > > > On 4 Nov 2015, at 10:29, Aaron Falk wrote: > > > > > >> And, you might not be able to tell you have a problem getting UDP > > through until you are under attack, > > >> when some operator may implement filtering that inhibits connectivit= y. > > > > > > Regular heartbeats between clients and servers, clients and relays, a= nd > > relays and servers can serve the function of ensuring end-to-end > > connectivity on an ongoing basis. > > > > > > Failure to receive service request acknowledgements can serve this > > purpose under duress. > > > > > > It's expected that DOTS clients will update DOTS servers (either > > directly or via DOTS relays) with either continued mitigation requests > > and/or situational updates with regards to mitigation efficacy througho= ut > > mitigation service windows. Likewise, DOTS servers are expected to do > the > > same with regards to DOTS clients (again, either directly or via DOTS > > relays). > > > > > > Note that other than a DOTS server receiving a DOTS mitigation servic= e > > requests, none of these message types are necessary in order to > mitigation > > service to be initiated. They are important and useful, but not missio= n- > > critical; the only mission-critical DOTS messages are mitigation servic= e > > requests from DOTS clients and mitigation service refusals from DOTS > > servers. > > > > > > ----------------------------------- > > > 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 > --089e013a226854c81d0523c6b622 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes, this is captured in OP-005 of the requirements draft. I encourage WG m= embers to read it and send feedback. Thank you.

andrew


On Thursday, November 5, 2015, <mohamed.boucadair@orange.com&g= t; wrote:
Hi Kaname,

I agree with your comment about the status.

FYI, we had this requirement in -00 of https://tools= .ietf.org/html/draft-reddy-dots-transport-00#section-4:

=C2=A0 =C2=A0o=C2=A0 Acknowledgement for the processing of a filtering requ= est and the
=C2=A0 =C2=A0 =C2=A0 enforcement of associated countermeasures.

Cheers,
Med

> -----Message d'origine-----
> De=C2=A0: Dots [mailto:dots-bounces@ietf.org]= De la part de kaname nishizuka
> Envoy=C3=A9=C2=A0: jeudi 5 novembre 2015 07:09
> =C3=80=C2=A0: Roland Dobbins; dots@ietf.org
> Cc=C2=A0: tsvwg@ietf.org
> Objet=C2=A0: Re: [Dots] [tsvwg] Best transport selection during an att= ack?
>
>
>=C2=A0 >the only mission-critical DOTS messages are mitigation servi= ce requests
> from DOTS clients and mitigation service refusals from DOTS servers. >
> I'm in favor of the pointing out of the latter point: mitigation s= ervice
> refusals from DOTS servers.
> In operator's point of view, returning of status is indispensable = to know
> the mitigation is succeed or not.
> Without such information, it will take more time to decide the next > action, so it will harm the victim longer.
>
> IMHO, in this meaning, "SOS" is a little bit confusing becau= se it seems
> like the signaling is one directional.
>
> regards,
> kaname nishizuka
>
>
> On 2015/11/04 10:37, Roland Dobbins wrote:
> > On 4 Nov 2015, at 10:29, Aaron Falk wrote:
> >
> >> And, you might not be able to tell you have a problem getting= UDP
> through until you are under attack,
> >> when some operator may implement filtering that inhibits conn= ectivity.
> >
> > Regular heartbeats between clients and servers, clients and relay= s, and
> relays and servers can serve the function of ensuring end-to-end
> connectivity on an ongoing basis.
> >
> > Failure to receive service request acknowledgements can serve thi= s
> purpose under duress.
> >
> > It's expected that DOTS clients will update DOTS servers (eit= her
> directly or via DOTS relays) with either continued mitigation requests=
> and/or situational updates with regards to mitigation efficacy through= out
> mitigation service windows.=C2=A0 Likewise, DOTS servers are expected = to do the
> same with regards to DOTS clients (again, either directly or via DOTS<= br> > relays).
> >
> > Note that other than a DOTS server receiving a DOTS mitigation se= rvice
> requests, none of these message types are necessary in order to mitiga= tion
> service to be initiated.=C2=A0 They are important and useful, but not = mission-
> critical; the only mission-critical DOTS messages are mitigation servi= ce
> requests from DOTS clients and mitigation service refusals from DOTS > servers.
> >
> > -----------------------------------
> > Roland Dobbins <rdobbins@arbor.net> > >
> > _______________________________________________
> > 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
ht= tps://www.ietf.org/mailman/listinfo/dots
--089e013a226854c81d0523c6b622-- From nobody Thu Nov 5 00:30: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 073FE1A8A0C; Thu, 5 Nov 2015 00:29:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 W_9Jz0SfgUZV; Thu, 5 Nov 2015 00:29:13 -0800 (PST) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 650061A8A0B; Thu, 5 Nov 2015 00:29:12 -0800 (PST) Received: from s4de8nsazdfe010.bmbg.telekom.de ([10.175.246.202]) by tcmail91.telekom.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 05 Nov 2015 09:29:06 +0100 X-IronPort-AV: E=Sophos;i="5.20,246,1444687200"; d="scan'208";a="770188019" Received: from he113676.emea1.cds.t-internal.com ([10.134.99.29]) by q4de8nsa015.bmbg.telekom.de with ESMTP/TLS/AES128-SHA; 05 Nov 2015 09:29:05 +0100 Received: from HE111642.emea1.cds.t-internal.com ([10.134.93.11]) by HE113676.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 5 Nov 2015 09:29:05 +0100 From: To: , Date: Thu, 5 Nov 2015 09:29:03 +0100 Thread-Topic: [tsvwg] [Dots] Best transport selection during an attack? Thread-Index: AQHRF5B5NOthr1TFokCFMiTlAmT/Qp6NCnNwgAAIZKA= Message-ID: <828773FE19B05B4581311493A046E85E3F619C04D9@HE111642.emea1.cds.t-internal.com> References: <5638D31B.4080801@mti-systems.com> <10B4A768-25EC-4AFF-99D0-1BEC1C24CF2A@arbor.net> <563AF27B.8010009@nttv6.jp> <787AE7BB302AE849A7480A190F8B933008C98037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933008C98037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Thu, 05 Nov 2015 00:30:51 -0800 Cc: rdobbins@arbor.net, tsvwg@ietf.org, dots@ietf.org Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 05 Nov 2015 08:29:15 -0000 Hi, if DOTS allows for transport options, is QoS/DiffServ a possible option sup= porting a desired solution? Sure, DiffServ isn't available everywhere, that= 's why I call it an option. But if QoS is supported at an access, why shoul= dn't it be used to ensure reliable communication? Regulation in my country enforces reliable VoIP emergency calls. This mecha= nism can't be used for DOTS I think, but there seem to be some parallels. T= he emergency call: - must work under any network conditions - must be authenticated and authorized - must reach a special site (two in fact, the provider phone=20 service server and from there if possible the emergency call=20 center closest to the calling party - note that on telephony=20 level an "anycast" phone-number is used (US would be 911, here 110/112) - must provide the receiver with information which the calling=20 party may not be able to provide (here location information) Emergency call transport is QoS based, if the customer signed for a telepho= ny service offered by the access provider.=20 Regards, Ruediger From nobody Thu Nov 5 02:03: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 873061A92AE; Thu, 5 Nov 2015 02:02:59 -0800 (PST) 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 uwntK8ULonxR; Thu, 5 Nov 2015 02:02:57 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90ECC1A924A; Thu, 5 Nov 2015 02:02:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3779; q=dns/txt; s=iport; t=1446717778; x=1447927378; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=C/4IO4H7v2DWGGlY0yrHu0EcT6zwNxGfTEV1JEmrxzQ=; b=R+GD1PQ05p8TsAjV4eeH6A3OI50Khw+/TdO2VC921DGjHQVm4BJ7czW9 qY6Z37ejwvxKlyd2EcyrQu9k1Bxp7xnyRi97r6aaFVzG26YB+IymsQQTW lB7yuLAD8iJINDlZ8NtLI9BtImGCsEpPFlSki9M16meZ7zxZ/Qo1Jr27G 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ANAgD6JztW/5pdJa1egztTbwa9bQENgV4XCoVxAoE1OBQBAQEBAQEBgQqENQEBAQQBAQFEJwsMBAIBCBEEAQEBJwcnCxQJCAIEAQ0FCIgmDbYZi1oBAQEBAQEBAQEBAQEBAQEBAQEBAQEUBIZUhH6EQoR3BYdEhVc5iHQBhRyCcIUPgWGSFYRhg3EBHwEBQoQEcoQYgQcBAQE X-IronPort-AV: E=Sophos;i="5.20,247,1444694400"; d="scan'208";a="205145807" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-6.cisco.com with ESMTP; 05 Nov 2015 10:02:57 +0000 Received: from XCH-ALN-017.cisco.com (xch-aln-017.cisco.com [173.36.7.27]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id tA5A2u7G002283 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 5 Nov 2015 10:02:56 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-ALN-017.cisco.com (173.36.7.27) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 5 Nov 2015 04:02:55 -0600 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, 5 Nov 2015 04:02:56 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "mohamed.boucadair@orange.com" , "kaname nishizuka" , Roland Dobbins , "dots@ietf.org" Thread-Topic: [Dots] [tsvwg] Best transport selection during an attack? Thread-Index: AQHRF5B8JyCkyMZ530+wW6vWXPIlep6Nb8WA///CiDA= Date: Thu, 5 Nov 2015 10:02:55 +0000 Message-ID: References: <5638D31B.4080801@mti-systems.com> <10B4A768-25EC-4AFF-99D0-1BEC1C24CF2A@arbor.net> <563AF27B.8010009@nttv6.jp> <787AE7BB302AE849A7480A190F8B933008C98037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933008C98037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> 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.127.22.95] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tsvwg@ietf.org" Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 05 Nov 2015 10:02:59 -0000 We will update the draft to explain response codes and re-name SOS to 'Miti= gation service request'. -Tiru > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of > mohamed.boucadair@orange.com > Sent: Thursday, November 05, 2015 1:10 PM > To: kaname nishizuka; Roland Dobbins; dots@ietf.org > Cc: tsvwg@ietf.org > Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? >=20 > Hi Kaname, >=20 > I agree with your comment about the status. >=20 > FYI, we had this requirement in -00 of https://tools.ietf.org/html/draft- > reddy-dots-transport-00#section-4: >=20 > o Acknowledgement for the processing of a filtering request and the > enforcement of associated countermeasures. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de kaname nishizu= ka > > Envoy=E9=A0: jeudi 5 novembre 2015 07:09 > > =C0=A0: Roland Dobbins; dots@ietf.org > > Cc=A0: tsvwg@ietf.org > > Objet=A0: Re: [Dots] [tsvwg] Best transport selection during an attack? > > > > > > >the only mission-critical DOTS messages are mitigation service reques= ts > > from DOTS clients and mitigation service refusals from DOTS servers. > > > > I'm in favor of the pointing out of the latter point: mitigation servic= e > > refusals from DOTS servers. > > In operator's point of view, returning of status is indispensable to kn= ow > > the mitigation is succeed or not. > > Without such information, it will take more time to decide the next > > action, so it will harm the victim longer. > > > > IMHO, in this meaning, "SOS" is a little bit confusing because it seems > > like the signaling is one directional. > > > > regards, > > kaname nishizuka > > > > > > On 2015/11/04 10:37, Roland Dobbins wrote: > > > On 4 Nov 2015, at 10:29, Aaron Falk wrote: > > > > > >> And, you might not be able to tell you have a problem getting UDP > > through until you are under attack, > > >> when some operator may implement filtering that inhibits connectivit= y. > > > > > > Regular heartbeats between clients and servers, clients and relays, a= nd > > relays and servers can serve the function of ensuring end-to-end > > connectivity on an ongoing basis. > > > > > > Failure to receive service request acknowledgements can serve this > > purpose under duress. > > > > > > It's expected that DOTS clients will update DOTS servers (either > > directly or via DOTS relays) with either continued mitigation requests > > and/or situational updates with regards to mitigation efficacy througho= ut > > mitigation service windows. Likewise, DOTS servers are expected to do = the > > same with regards to DOTS clients (again, either directly or via DOTS > > relays). > > > > > > Note that other than a DOTS server receiving a DOTS mitigation servic= e > > requests, none of these message types are necessary in order to mitigat= ion > > service to be initiated. They are important and useful, but not missio= n- > > critical; the only mission-critical DOTS messages are mitigation servic= e > > requests from DOTS clients and mitigation service refusals from DOTS > > servers. > > > > > > ----------------------------------- > > > 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 >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Nov 5 02:28: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 75DD31ACCF3 for ; Thu, 5 Nov 2015 02:27:58 -0800 (PST) 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 8JR088sFFUsr for ; Thu, 5 Nov 2015 02:27:53 -0800 (PST) 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 D77A81ACCF6 for ; Thu, 5 Nov 2015 02:27:52 -0800 (PST) Received: by pacdm15 with SMTP id dm15so59841775pac.3 for ; Thu, 05 Nov 2015 02:27:52 -0800 (PST) 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=cIhmKL+C4WfdUxUy2h0U7zQc0mD3PtpCuK3sUc0A0Gw=; b=CGktmigX4i8fiKJ7wAHIVlVijFh9U4QFzMq1hxV4djHc7/K3YFy1FPtsO2tS8hzoi4 HxbqeS/IaWi2KZ7kCVNC0d/XCWy5F/wxD5nnu7DgDeDK0UEEj13gwH9CrEO+mEgZRKVV fAa7dlMdwVu+UZXGC6W9LKs5Hj530CJM5XIUo= 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=cIhmKL+C4WfdUxUy2h0U7zQc0mD3PtpCuK3sUc0A0Gw=; b=W6kuugDGqbXJK5gyIwoQr7cfkIf/DXpe+QTg6Jk58kaz73OIxiT3NCnnk2ICOCZ7qg RARNcVDBrTVwvrxAx9vniqBVZPScGiSPsOF37+MTVPBF7vIipD3eF3IgQO7licYDZmY0 KwyRAMvHZBmPINp9oyJiDPAA0i+OCT99N7bRQ11IHyqqGRgi12JO9XOsxS8So2MD3S36 HiZa802rRkVevCid7wNCFmtzKKP6sG+rkQ2UvdbHSTjbeUKPtpbfXFERUd7l63hiVSA4 k1YCSAeJiZQK7yUiiRDgUbZiqjgBoVigUQ3mVgKYlw3frYp3nDwlJYR7H35SewQFS2Jc yD+Q== X-Gm-Message-State: ALoCoQmwFaMDa+nuvZN4UchF+kLd2ioViLW1EW59WGx7Q+asZL7ehtmjRQndDxwAcPDi5jRenT3p X-Received: by 10.68.194.227 with SMTP id hz3mr8397924pbc.105.1446719272471; Thu, 05 Nov 2015 02:27:52 -0800 (PST) Received: from [10.0.1.3] (p5231-ipngn5001hodogaya.kanagawa.ocn.ne.jp. [153.220.164.231]) by smtp.gmail.com with ESMTPSA id fl5sm7064634pbd.70.2015.11.05.02.27.51 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 05 Nov 2015 02:27:51 -0800 (PST) From: "Roland Dobbins" To: tsvwg@ietf.org Date: Thu, 05 Nov 2015 19:27:49 +0900 Message-ID: <3F352E09-6415-4409-AE95-68FFD5020C04@arbor.net> In-Reply-To: <828773FE19B05B4581311493A046E85E3F619C04D9@HE111642.emea1.cds.t-internal.com> References: <5638D31B.4080801@mti-systems.com> <10B4A768-25EC-4AFF-99D0-1BEC1C24CF2A@arbor.net> <563AF27B.8010009@nttv6.jp> <787AE7BB302AE849A7480A190F8B933008C98037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <828773FE19B05B4581311493A046E85E3F619C04D9@HE111642.emea1.cds.t-internal.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5164) Archived-At: Cc: dots@ietf.org Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 05 Nov 2015 10:27:58 -0000 On 5 Nov 2015, at 17:29, Ruediger.Geib@telekom.de wrote: > if DOTS allows for transport options, is QoS/DiffServ a possible > option supporting a desired solution? Yes, this is an option for topological situations in which the organization requesting mitigation and the upstream mitigator are adjacent; they'd have to work it out between themselves, of course. This has already been discussed on-list, I believe, and we should offer this guidance in terms of deployment recommendations. However, there are topological situations in which we know markings won't be preserved. Some of the diagrams in the use-cases .pdf preso are illustrative in this regard: ----------------------------------- Roland Dobbins From nobody Thu Nov 5 02:29: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 074B71ACD08 for ; Thu, 5 Nov 2015 02:29:49 -0800 (PST) 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 coFB8dzx9YEz for ; Thu, 5 Nov 2015 02:29:48 -0800 (PST) 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 043F41ACCFB for ; Thu, 5 Nov 2015 02:29:48 -0800 (PST) Received: by pasz6 with SMTP id z6so87262499pas.2 for ; Thu, 05 Nov 2015 02:29:47 -0800 (PST) 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=FJK/O1oy7pMWDv7LXiAjjec2K/Saiy3hRXy9tID10tM=; b=PVRDrZs45P5K76A5pG/YuQi7IVdRhHEClc0JnwJKusE9UHppiylsfk2YXaCbAhIK8d 5jKp0nKVRaz7Z0CLf+L3cVLYC74t2cCEnzNmurP/trcCSH0k3OSsDazaHWhqbQUBrfz6 DXORKMww9iRK815K2LfxJIoJ4FhMANXiMCi3c= 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=FJK/O1oy7pMWDv7LXiAjjec2K/Saiy3hRXy9tID10tM=; b=ZSjBSdFJJNtBxrT/q31kzjAZp3gO9SqH6GTZluJ19/zOdn2vmscy1ycEFLtmWo+MLn 8Xk3jtkg2uuCXnXCVPlBLsqtbn8e9aUXf4jM+GfxFOrqWIQ5mLOXS6z97mh/J0xy/4nj CBiWbJejQoGIR+x+thJjm/c2sBX2DBScz+1wrGSp2qH0faiIISDsYHXtCVCsEU3SDxYJ E4leuCzOuok33HKq/8zRmzqcRMWm9amICsi0TdupsfxK2p7XP0ZbcVTTMli2AHILl46r dISGnSHsgaxmAyHuJhkw2/KLH3tYGqdZpFu/UitEjwFlJM9o761Pt5/jtCNzP/PDSQEO dyTQ== X-Gm-Message-State: ALoCoQn27tD/cwAOHLXt1th6e56wnJsoOWh9YJ5s1yoarzREGF5v216sSBle8vBBqZIJv0X1qgv4 X-Received: by 10.67.30.168 with SMTP id kf8mr7835768pad.106.1446719387707; Thu, 05 Nov 2015 02:29:47 -0800 (PST) Received: from [10.0.1.3] (p5231-ipngn5001hodogaya.kanagawa.ocn.ne.jp. [153.220.164.231]) by smtp.gmail.com with ESMTPSA id kw10sm7133510pbc.25.2015.11.05.02.29.45 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 05 Nov 2015 02:29:46 -0800 (PST) From: "Roland Dobbins" To: "dots@ietf.org" Date: Thu, 05 Nov 2015 19:29:44 +0900 Message-ID: <0850AFE8-65D5-419F-8C8E-D7AAB277740F@arbor.net> In-Reply-To: References: <5638D31B.4080801@mti-systems.com> <10B4A768-25EC-4AFF-99D0-1BEC1C24CF2A@arbor.net> <563AF27B.8010009@nttv6.jp> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5164) Archived-At: Cc: "tsvwg@ietf.org" Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 05 Nov 2015 10:29:49 -0000 On 5 Nov 2015, at 15:24, Teague, Nik wrote: > We should probably standardise on something like mitigation service > request, response and status(?). Concur, we should formalize the status message categories and options. 'SOS' isn't really specific enough, IMHO. ----------------------------------- Roland Dobbins From nobody Thu Nov 5 02:38: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 A4B5D1ACD33 for ; Thu, 5 Nov 2015 02:38:24 -0800 (PST) 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 PM8PHoj21-BL for ; Thu, 5 Nov 2015 02:38:23 -0800 (PST) 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 A06FC1ACD32 for ; Thu, 5 Nov 2015 02:38:23 -0800 (PST) Received: by pabfh17 with SMTP id fh17so84335286pab.0 for ; Thu, 05 Nov 2015 02:38:23 -0800 (PST) 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=My4MBUo8B3oE3LznQpsHUoTUBZkMTRkGIWj9JqNp7AI=; b=Dgp5Cu6RyYCFL5dQRxLFpT8R3Zgoqclt2X/aP2J7JddkXBeRNiN8KdCNt7KbbWcE4l flk1FtyoxhPV8z/BYmYdgC+KVSKBs4wRx13l9cg0rrbi4J7KA7kea9CxLuP5Yw+BBWRM SLHabpDoB9JTZ2eio+Sq3uxeP9GerFB/0wbr0= 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=My4MBUo8B3oE3LznQpsHUoTUBZkMTRkGIWj9JqNp7AI=; b=XfyfamKGu/25RRN+8Y0eiaOmMa79evRCJ0TnCdmooJyrS/1smlGcEsIEQAoinaGrrS K0vWWeWIRv4yePru1Se7czboxyEE5VyrWTAEWkiSQB9NXF0i82bAbQpKHFzFYX20cq9T hkJ7TcUjoMhsRAs7KpBifMa9A+o8Gd/Gzc+zJ5Df55qu3nzW7LpIJgo0+zMSbrfdDgTR e0Sh74s6cAbv2MX3XmOjwAQ9SA3fkrmyQ5eXYvTWQ1ivrbCSHzRr/BiQjZTFQNOjdAl/ +LfXVWbpGh6JdN98x4brPiHdC9g7CKKbc4ZJg/V31SPY3CziFgA6WUBXulWq9nrFWofV YhBQ== X-Gm-Message-State: ALoCoQk84sNSeH8nBq3ZCcHmX+Pw9kJHGhJ9FnHFPt5T6wKs4vedw7PM8mB6bpOEXt/e1bC3C7vK X-Received: by 10.66.66.166 with SMTP id g6mr8325801pat.152.1446719903250; Thu, 05 Nov 2015 02:38:23 -0800 (PST) Received: from [10.0.1.3] (p5231-ipngn5001hodogaya.kanagawa.ocn.ne.jp. [153.220.164.231]) by smtp.gmail.com with ESMTPSA id yk5sm7203484pac.5.2015.11.05.02.38.22 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 05 Nov 2015 02:38:22 -0800 (PST) From: "Roland Dobbins" To: "dots@ietf.org" Date: Thu, 05 Nov 2015 19:38:20 +0900 Message-ID: <1CE9E2C8-FFEB-47D6-8C14-7DC8CEF154CA@arbor.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5164) Archived-At: Subject: [Dots] Message types, sub-types, etc. (was Re: [tsvwg] Best transport selection during an attack?) 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, 05 Nov 2015 10:38:24 -0000 [eliding tsvwg] On 5 Nov 2015, at 19:02, Tirumaleswar Reddy (tireddy) wrote: > We will update the draft to explain response codes and re-name SOS to > 'Mitigation service request'. We need to ensure that we capture the requirements for message types, codes, et. al. as part of the requirements draft, IMHO. That can then inform the other drafts. Registration, re-registration, de-registration, heartbeat, capabilities exchange (both for messaging and mitigation), mitigation service initiation request, mitigation service initiation response, mitigation service status notification, mitigation scope update, mitigation efficacy notification, mitigation service termination request, mitigation service termination response, mitigation service termination notification - these are some which spring immediately to mind (we can work on the terminology, these are just functional categories). ----------------------------------- Roland Dobbins From nobody Thu Nov 5 02:41: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 1BAF71ACD41 for ; Thu, 5 Nov 2015 02:41:40 -0800 (PST) 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 MYyIfmnWAxgP for ; Thu, 5 Nov 2015 02:41:39 -0800 (PST) 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 3DA351ACD40 for ; Thu, 5 Nov 2015 02:41:39 -0800 (PST) Received: by pacdm15 with SMTP id dm15so60163941pac.3 for ; Thu, 05 Nov 2015 02:41:39 -0800 (PST) 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=eLogH5VTv1BZedyCZBPG6eRw7mlrm1a5cSuxpseDsZY=; b=FsP8UHxcaNx5onr5+YfTli4cbGWfrz02lp8Z3JJcU9icc2RITtxbegjPW2lzHYIlld GgLW5+hLWF1B/mkh06amI86v1fAmXH/XRS3Zprw8pd+gOrARU6hfFsfqG3+uHo5UJdSZ ipUOdIiF26Ujs63jW22WOWVDXzNj3OxeJkq/k= 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=eLogH5VTv1BZedyCZBPG6eRw7mlrm1a5cSuxpseDsZY=; b=kpykoZueLxmETTlp7AKJ/pzvGKzIHGOlYG0MgCkX3viEq5dZYfkaweFEAr3s945aJc IFSwCaAkCfOGy+upn4uyOdnZjJyvHqV91KysUsyDTLbpL8spa23iIJtQqBznKPP6VtYA GO1Rct1VT/jpehnG7o2Kly3DsjyhF24jjZZIBe5hEllW9TZmdykiEwSNDvFNGrrfi/yV O/4lG6R7Uh7tHWNxXR5W8bcB3f+fKJCcmzeZefWqTlOI6eFITd/TVFKeroi/iq4Ehc6i mEAK9qHpLGsaqimyd5tY29eDMvYd/v3Tgjyqw/cXpxdKSZBsJG0M4HtCKnYpzbwN+Hxp Mhhg== X-Gm-Message-State: ALoCoQkdPfoZs+rwzuPENqqR81UK2wL4sxjefNOha2tkc/QfwCIKKu/TTXNpxw2GFORP9viGR/IF X-Received: by 10.68.125.197 with SMTP id ms5mr8550970pbb.161.1446720098877; Thu, 05 Nov 2015 02:41:38 -0800 (PST) Received: from [10.0.1.3] (p5231-ipngn5001hodogaya.kanagawa.ocn.ne.jp. [153.220.164.231]) by smtp.gmail.com with ESMTPSA id qf2sm7227895pbb.3.2015.11.05.02.41.37 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 05 Nov 2015 02:41:38 -0800 (PST) From: "Roland Dobbins" To: dots Date: Thu, 05 Nov 2015 19:41:36 +0900 Message-ID: <84166B32-E182-4E80-9827-C926A7A414DC@arbor.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5164) Archived-At: Subject: [Dots] dots-threats-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: Thu, 05 Nov 2015 10:41:40 -0000 Do we need a separate dots-threats draft to lay out potential threats to DOTS communications channels/nodes in detail, or will the security sections of the relevant drafts suffice? ----------------------------------- Roland Dobbins From nobody Thu Nov 5 03:15: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 4E0151ACE32; Thu, 5 Nov 2015 03:15:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 1Qis8hV6MKL0; Thu, 5 Nov 2015 03:15:08 -0800 (PST) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 619261ACE31; Thu, 5 Nov 2015 03:15:07 -0800 (PST) Received: from qdezc2.de.t-internal.com ([10.125.181.10]) by tcmail41.telekom.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 05 Nov 2015 12:15:03 +0100 X-IronPort-AV: E=Sophos;i="5.20,247,1444687200"; d="scan'208";a="354263630" Received: from he113675.emea1.cds.t-internal.com ([10.134.99.28]) by qde0ps.de.t-internal.com with ESMTP/TLS/AES128-SHA; 05 Nov 2015 12:15:03 +0100 Received: from HE111642.emea1.cds.t-internal.com ([10.134.93.11]) by HE113675.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 5 Nov 2015 12:15:02 +0100 From: To: Date: Thu, 5 Nov 2015 12:15:01 +0100 Thread-Topic: [tsvwg] [Dots] Best transport selection during an attack? Thread-Index: AdEXtMp61hFhjD0lRa6nEPU/qJ4dkQAApJeA Message-ID: <828773FE19B05B4581311493A046E85E3F619C06A7@HE111642.emea1.cds.t-internal.com> References: <5638D31B.4080801@mti-systems.com> <10B4A768-25EC-4AFF-99D0-1BEC1C24CF2A@arbor.net> <563AF27B.8010009@nttv6.jp> <787AE7BB302AE849A7480A190F8B933008C98037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <828773FE19B05B4581311493A046E85E3F619C04D9@HE111642.emea1.cds.t-internal.com> <3F352E09-6415-4409-AE95-68FFD5020C04@arbor.net> In-Reply-To: <3F352E09-6415-4409-AE95-68FFD5020C04@arbor.net> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: dots@ietf.org, tsvwg@ietf.org Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 05 Nov 2015 11:15:10 -0000 Hi Roland, my understanding is, bi-directional QoS transport should be possible betwee= n DOTS client and server. I think, transport QoS may be an option, if DOTS server and client are conn= ected to the same provider.=20 If the DOTS server is connected to a different provider than DOTS client, t= hen this is a "remote access". Is the provider terminating the DOTS client = access part of the DDoS defense system or may this provider be agnostic to = all that? If the latter is true plain provider IP service is my expectation= and then QoS transport between client and server is a challenge. Regards, Ruediger -----Urspr=FCngliche Nachricht----- Von: tsvwg [mailto:tsvwg-bounces@ietf.org] Im Auftrag von Roland Dobbins Gesendet: Donnerstag, 5. November 2015 11:28 An: tsvwg@ietf.org Cc: dots@ietf.org Betreff: Re: [tsvwg] [Dots] Best transport selection during an attack? On 5 Nov 2015, at 17:29, Ruediger.Geib@telekom.de wrote: > if DOTS allows for transport options, is QoS/DiffServ a possible=20 > option supporting a desired solution? Yes, this is an option for topological situations in which the organization= requesting mitigation and the upstream mitigator are adjacent; they'd have= to work it out between themselves, of course. =20 This has already been discussed on-list, I believe, and we should offer thi= s guidance in terms of deployment recommendations. However, there are topological situations in which we know markings won't b= e preserved. Some of the diagrams in the use-cases .pdf preso are illustra= tive in this regard: ----------------------------------- Roland Dobbins From nobody Thu Nov 5 03:28: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 66D8E1ACE82 for ; Thu, 5 Nov 2015 03:28:05 -0800 (PST) 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 J36kLKuIsP3s for ; Thu, 5 Nov 2015 03:28:04 -0800 (PST) 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 4DA501ACE71 for ; Thu, 5 Nov 2015 03:28:04 -0800 (PST) Received: by padhx2 with SMTP id hx2so77388849pad.1 for ; Thu, 05 Nov 2015 03:28:04 -0800 (PST) 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=k34hHZTH5UMFSluAxHir/ttvu3YVLKKCZh7H+tgAIxk=; b=L2uNE+iTCtP3ZlkYyQLxj5t8YVD9WccNLIj9fqaV5Ej3+53Jg+UkBqa20hYxmxxDJw cCLUVAPo84sMWFy0ThZ49GVvC66fRWQa8WpZQP1S14SsC80HaFv3nmB8oa5tTIStwfkG KB4YX1mIUj8VEUyOKazfgU/KEsjOBJ+S92NRc= 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=k34hHZTH5UMFSluAxHir/ttvu3YVLKKCZh7H+tgAIxk=; b=fOFq4w8gOnVnpWwbEK1BCDQwMawp8cRHM3pYKwkFwnhCrdjiRsgidiq3AAzNAr+B3L hVLFenOthnsiNYIop9cIt6MmRjSb4p/fxy4JADdUeAv8rxbHpDmTnh7wdvhSbwy7WZy/ uoC63GnvCXzyMSi2Wf14AjvgVGJOCD2UFaX/guYJTQJBXmRUnUxx2a3qdJOp+AsDCjLE Z7JUwTv+oXESiDFXdguR0R013u20vf6Vpy2UGFwZHEwSqZTFr60Yd3dTh9efzDNXWTmr c2LEsCSa0Uv6npyDoVX6eeH08FPSVkU/R7Ouz71S8K4WC+O1KMLqpQOI+n2sGjw20moX w2RQ== X-Gm-Message-State: ALoCoQk7K7LNpujd6wAVoLP66WVZIIkm8HxDWSOWvSIMU3wE8Q9hJwSGwcGX9tIhsIUni/wHOA0G X-Received: by 10.66.151.203 with SMTP id us11mr8826729pab.54.1446722883998; Thu, 05 Nov 2015 03:28:03 -0800 (PST) Received: from [10.0.1.3] (p5231-ipngn5001hodogaya.kanagawa.ocn.ne.jp. [153.220.164.231]) by smtp.gmail.com with ESMTPSA id wq1sm7440871pbc.49.2015.11.05.03.28.02 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 05 Nov 2015 03:28:03 -0800 (PST) From: "Roland Dobbins" To: tsvwg@ietf.org Date: Thu, 05 Nov 2015 20:27:55 +0900 Message-ID: <8867EE91-82F0-4F4D-B6B2-1BB70B616347@arbor.net> In-Reply-To: <828773FE19B05B4581311493A046E85E3F619C06A7@HE111642.emea1.cds.t-internal.com> References: <5638D31B.4080801@mti-systems.com> <10B4A768-25EC-4AFF-99D0-1BEC1C24CF2A@arbor.net> <563AF27B.8010009@nttv6.jp> <787AE7BB302AE849A7480A190F8B933008C98037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <828773FE19B05B4581311493A046E85E3F619C04D9@HE111642.emea1.cds.t-internal.com> <3F352E09-6415-4409-AE95-68FFD5020C04@arbor.net> <828773FE19B05B4581311493A046E85E3F619C06A7@HE111642.emea1.cds.t-internal.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5164) Archived-At: Cc: dots@ietf.org Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 05 Nov 2015 11:28:05 -0000 On 5 Nov 2015, at 20:15, Ruediger.Geib@telekom.de wrote: > my understanding is, bi-directional QoS transport should be possible > between DOTS client and server. Please see the network diagrams in the use-cases preso. When they're located in topologically adjacent administrative domains, this is possible, and will be recommended, although it's up to operators whether or not they actually do this. > I think, transport QoS may be an option, if DOTS server and client are > connected to the same provider. Concur. > If the DOTS server is connected to a different provider than DOTS > client, then this is a "remote access". Is the provider terminating > the DOTS client access part of the DDoS defense system or may this > provider be agnostic to all that? The main issue is intervening networks. > If the latter is true plain provider IP service is my expectation and > then QoS transport between client and server is a challenge. Yes, that's correct (along with the administrative and internal-political challenges operators may face even when they're directly topologically adjacent to the requesting organization's network). ----------------------------------- Roland Dobbins From nobody Thu Nov 5 05:55: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 72DFE1B2CEB for ; Thu, 5 Nov 2015 05:55:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 Pv_UJsiD-BUS for ; Thu, 5 Nov 2015 05:54:55 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 833EC1B2CE3 for ; Thu, 5 Nov 2015 05:54:38 -0800 (PST) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id DA4EB1B816A; Thu, 5 Nov 2015 14:54:36 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.57]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id B9728C8013; Thu, 5 Nov 2015 14:54:36 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3%19]) with mapi id 14.03.0248.002; Thu, 5 Nov 2015 14:54:36 +0100 From: To: "Mortensen, Andrew" Thread-Topic: Comments about the requirements draft (RE: [Dots] Best transport selection during an attack?) Thread-Index: AdEX0YElrv5EIrNXQw+cN1gXe9THMQ== Date: Thu, 5 Nov 2015 13:54:35 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008C98572@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933008C98572OPEXCLILMA3corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.11.5.113316 Archived-At: Cc: "dots@ietf.org" Subject: [Dots] Comments about the requirements draft (RE: Best transport selection during an attack?) 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, 05 Nov 2015 13:55:02 -0000 --_000_787AE7BB302AE849A7480A190F8B933008C98572OPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5kcmV3LA0KDQpZb3UgY2FuIHJldHJpZXZlIG15IGZpcnN0IHJldmlldyBvZiB0aGUgcmVx dWlyZW1lbnRzIGRyYWZ0IGZyb20gdGhpcyBsaW5rPGh0dHBzOi8vdGYub3JhbmdlLmNvbS9Eb3du bG9hZFRyYW5zYWN0aW9uLmFzcHg/VXBsb2FkSUQ9NjM1ODIzMzE3OTEyNTIxNDEwJnB3ZD0xbXpr QkorOEdLc1p2cHY4M1FNVW93PT0mcmVjaXBpZW50PWw1R2IwdDJ3akUyVE5SYnp1QU8yZ0lPYzFM aGtxT0FBZFF5YXF3SEo3SEU9JnJlZj1sNUdiMHQyd2pFMlROUmJ6dUFPMmdJT2MxTGhrcU9BQWRR eWFxd0hKN0hFPSY+LiBJ4oCZbSBhbHNvIGF0dGFjaGluZyB0aGUgcGRmIGZpbGUgaW4gY2FzZSB5 b3UgaGF2ZSB0cm91YmxlcyB0byBvcGVuIHRoZSBkb2MgZmlsZS4NCg0KZHJhZnQtaWV0Zi1kb3Rz LXJlcXVpcmVtZW50cy0wMC1yZXYgTWVkLmRvYw0KZHJhZnQtaWV0Zi1kb3RzLXJlcXVpcmVtZW50 cy0wMC1yZXYgTWVkLnBkZg0KDQooVGhlc2UgZmlsZShzKSBhcmUgYXZhaWxhYmxlIHVudGlsIDEw LzExLzIwMTUgMTQ6NTA6MTYpDQoNCkNoZWVycywNCk1lZA0KDQpEZSA6IE1vcnRlbnNlbiwgQW5k cmV3IFttYWlsdG86YW1vcnRlbnNlbkBhcmJvci5uZXRdDQpFbnZvecOpIDogamV1ZGkgNSBub3Zl bWJyZSAyMDE1IDA5OjE0DQrDgCA6IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE4NCkNjIDoga2Fu YW1lIG5pc2hpenVrYTsgUm9sYW5kIERvYmJpbnM7IGRvdHNAaWV0Zi5vcmc7IHRzdndnQGlldGYu b3JnDQpPYmpldCA6IFJlOiBbRG90c10gQmVzdCB0cmFuc3BvcnQgc2VsZWN0aW9uIGR1cmluZyBh biBhdHRhY2s/DQoNClllcywgdGhpcyBpcyBjYXB0dXJlZCBpbiBPUC0wMDUgb2YgdGhlIHJlcXVp cmVtZW50cyBkcmFmdC4gSSBlbmNvdXJhZ2UgV0cgbWVtYmVycyB0byByZWFkIGl0IGFuZCBzZW5k IGZlZWRiYWNrLiBUaGFuayB5b3UuDQoNCmFuZHJldw0KDQoNCk9uIFRodXJzZGF5LCBOb3ZlbWJl ciA1LCAyMDE1LCA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbT4+IHdyb3RlOg0KSGkgS2FuYW1lLA0KDQpJIGFncmVlIHdpdGgg eW91ciBjb21tZW50IGFib3V0IHRoZSBzdGF0dXMuDQoNCkZZSSwgd2UgaGFkIHRoaXMgcmVxdWly ZW1lbnQgaW4gLTAwIG9mIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1yZWRkeS1k b3RzLXRyYW5zcG9ydC0wMCNzZWN0aW9uLTQ6DQoNCiAgIG8gIEFja25vd2xlZGdlbWVudCBmb3Ig dGhlIHByb2Nlc3Npbmcgb2YgYSBmaWx0ZXJpbmcgcmVxdWVzdCBhbmQgdGhlDQogICAgICBlbmZv cmNlbWVudCBvZiBhc3NvY2lhdGVkIGNvdW50ZXJtZWFzdXJlcy4NCg0KQ2hlZXJzLA0KTWVkDQoN Cj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlIDogRG90cyBbbWFpbHRvOmRvdHMt Ym91bmNlc0BpZXRmLm9yZzxqYXZhc2NyaXB0Ojs+XSBEZSBsYSBwYXJ0IGRlIGthbmFtZSBuaXNo aXp1a2ENCj4gRW52b3nDqSA6IGpldWRpIDUgbm92ZW1icmUgMjAxNSAwNzowOQ0KPiDDgCA6IFJv bGFuZCBEb2JiaW5zOyBkb3RzQGlldGYub3JnPGphdmFzY3JpcHQ6Oz4NCj4gQ2MgOiB0c3Z3Z0Bp ZXRmLm9yZzxqYXZhc2NyaXB0Ojs+DQo+IE9iamV0IDogUmU6IFtEb3RzXSBbdHN2d2ddIEJlc3Qg dHJhbnNwb3J0IHNlbGVjdGlvbiBkdXJpbmcgYW4gYXR0YWNrPw0KPg0KPg0KPiAgPnRoZSBvbmx5 IG1pc3Npb24tY3JpdGljYWwgRE9UUyBtZXNzYWdlcyBhcmUgbWl0aWdhdGlvbiBzZXJ2aWNlIHJl cXVlc3RzDQo+IGZyb20gRE9UUyBjbGllbnRzIGFuZCBtaXRpZ2F0aW9uIHNlcnZpY2UgcmVmdXNh bHMgZnJvbSBET1RTIHNlcnZlcnMuDQo+DQo+IEknbSBpbiBmYXZvciBvZiB0aGUgcG9pbnRpbmcg b3V0IG9mIHRoZSBsYXR0ZXIgcG9pbnQ6IG1pdGlnYXRpb24gc2VydmljZQ0KPiByZWZ1c2FscyBm cm9tIERPVFMgc2VydmVycy4NCj4gSW4gb3BlcmF0b3IncyBwb2ludCBvZiB2aWV3LCByZXR1cm5p bmcgb2Ygc3RhdHVzIGlzIGluZGlzcGVuc2FibGUgdG8ga25vdw0KPiB0aGUgbWl0aWdhdGlvbiBp cyBzdWNjZWVkIG9yIG5vdC4NCj4gV2l0aG91dCBzdWNoIGluZm9ybWF0aW9uLCBpdCB3aWxsIHRh a2UgbW9yZSB0aW1lIHRvIGRlY2lkZSB0aGUgbmV4dA0KPiBhY3Rpb24sIHNvIGl0IHdpbGwgaGFy bSB0aGUgdmljdGltIGxvbmdlci4NCj4NCj4gSU1ITywgaW4gdGhpcyBtZWFuaW5nLCAiU09TIiBp cyBhIGxpdHRsZSBiaXQgY29uZnVzaW5nIGJlY2F1c2UgaXQgc2VlbXMNCj4gbGlrZSB0aGUgc2ln bmFsaW5nIGlzIG9uZSBkaXJlY3Rpb25hbC4NCj4NCj4gcmVnYXJkcywNCj4ga2FuYW1lIG5pc2hp enVrYQ0KPg0KPg0KPiBPbiAyMDE1LzExLzA0IDEwOjM3LCBSb2xhbmQgRG9iYmlucyB3cm90ZToN Cj4gPiBPbiA0IE5vdiAyMDE1LCBhdCAxMDoyOSwgQWFyb24gRmFsayB3cm90ZToNCj4gPg0KPiA+ PiBBbmQsIHlvdSBtaWdodCBub3QgYmUgYWJsZSB0byB0ZWxsIHlvdSBoYXZlIGEgcHJvYmxlbSBn ZXR0aW5nIFVEUA0KPiB0aHJvdWdoIHVudGlsIHlvdSBhcmUgdW5kZXIgYXR0YWNrLA0KPiA+PiB3 aGVuIHNvbWUgb3BlcmF0b3IgbWF5IGltcGxlbWVudCBmaWx0ZXJpbmcgdGhhdCBpbmhpYml0cyBj b25uZWN0aXZpdHkuDQo+ID4NCj4gPiBSZWd1bGFyIGhlYXJ0YmVhdHMgYmV0d2VlbiBjbGllbnRz IGFuZCBzZXJ2ZXJzLCBjbGllbnRzIGFuZCByZWxheXMsIGFuZA0KPiByZWxheXMgYW5kIHNlcnZl cnMgY2FuIHNlcnZlIHRoZSBmdW5jdGlvbiBvZiBlbnN1cmluZyBlbmQtdG8tZW5kDQo+IGNvbm5l Y3Rpdml0eSBvbiBhbiBvbmdvaW5nIGJhc2lzLg0KPiA+DQo+ID4gRmFpbHVyZSB0byByZWNlaXZl IHNlcnZpY2UgcmVxdWVzdCBhY2tub3dsZWRnZW1lbnRzIGNhbiBzZXJ2ZSB0aGlzDQo+IHB1cnBv c2UgdW5kZXIgZHVyZXNzLg0KPiA+DQo+ID4gSXQncyBleHBlY3RlZCB0aGF0IERPVFMgY2xpZW50 cyB3aWxsIHVwZGF0ZSBET1RTIHNlcnZlcnMgKGVpdGhlcg0KPiBkaXJlY3RseSBvciB2aWEgRE9U UyByZWxheXMpIHdpdGggZWl0aGVyIGNvbnRpbnVlZCBtaXRpZ2F0aW9uIHJlcXVlc3RzDQo+IGFu ZC9vciBzaXR1YXRpb25hbCB1cGRhdGVzIHdpdGggcmVnYXJkcyB0byBtaXRpZ2F0aW9uIGVmZmlj YWN5IHRocm91Z2hvdXQNCj4gbWl0aWdhdGlvbiBzZXJ2aWNlIHdpbmRvd3MuICBMaWtld2lzZSwg RE9UUyBzZXJ2ZXJzIGFyZSBleHBlY3RlZCB0byBkbyB0aGUNCj4gc2FtZSB3aXRoIHJlZ2FyZHMg dG8gRE9UUyBjbGllbnRzIChhZ2FpbiwgZWl0aGVyIGRpcmVjdGx5IG9yIHZpYSBET1RTDQo+IHJl bGF5cykuDQo+ID4NCj4gPiBOb3RlIHRoYXQgb3RoZXIgdGhhbiBhIERPVFMgc2VydmVyIHJlY2Vp dmluZyBhIERPVFMgbWl0aWdhdGlvbiBzZXJ2aWNlDQo+IHJlcXVlc3RzLCBub25lIG9mIHRoZXNl IG1lc3NhZ2UgdHlwZXMgYXJlIG5lY2Vzc2FyeSBpbiBvcmRlciB0byBtaXRpZ2F0aW9uDQo+IHNl cnZpY2UgdG8gYmUgaW5pdGlhdGVkLiAgVGhleSBhcmUgaW1wb3J0YW50IGFuZCB1c2VmdWwsIGJ1 dCBub3QgbWlzc2lvbi0NCj4gY3JpdGljYWw7IHRoZSBvbmx5IG1pc3Npb24tY3JpdGljYWwgRE9U UyBtZXNzYWdlcyBhcmUgbWl0aWdhdGlvbiBzZXJ2aWNlDQo+IHJlcXVlc3RzIGZyb20gRE9UUyBj bGllbnRzIGFuZCBtaXRpZ2F0aW9uIHNlcnZpY2UgcmVmdXNhbHMgZnJvbSBET1RTDQo+IHNlcnZl cnMuDQo+ID4NCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+IFJv bGFuZCBEb2JiaW5zIDxyZG9iYmluc0BhcmJvci5uZXQ8amF2YXNjcmlwdDo7Pj4NCj4gPg0KPiA+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gRG90 cyBtYWlsaW5nIGxpc3QNCj4gPiBEb3RzQGlldGYub3JnPGphdmFzY3JpcHQ6Oz4NCj4gPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHMNCj4NCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRG90cyBtYWlsaW5nIGxpc3QN Cj4gRG90c0BpZXRmLm9yZzxqYXZhc2NyaXB0Ojs+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vZG90cw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KRG90cyBtYWlsaW5nIGxpc3QNCkRvdHNAaWV0Zi5vcmc8amF2YXNjcmlw dDo7Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3RzDQo= --_000_787AE7BB302AE849A7480A190F8B933008C98572OPEXCLILMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlZlcmRhbmE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1 IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29O b3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwi c2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0 ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0 ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS1saW5rOiJUZXh0ZSBkZSBidWxsZXMgQ2FyIjsNCgltYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6 IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6 YmxhY2s7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCnNwYW4u VGV4dGVkZWJ1bGxlc0Nhcg0KCXttc28tc3R5bGUtbmFtZToiVGV4dGUgZGUgYnVsbGVzIENhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJUZXh0ZSBkZSBidWxs ZXMiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1s YW5ndWFnZTpGUjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBw dDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZS IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PkhpIEFuZHJldywNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj5Zb3UgY2FuIHJldHJpZXZlIG15IGZpcnN0IHJldmlldyBvZiB0aGUgcmVxdWlyZW1l bnRzIGRyYWZ0IGZyb20gdGhpcw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiM1QzZENzUiPjxhIGhyZWY9Imh0dHBzOi8vdGYub3JhbmdlLmNvbS9Eb3dubG9hZFRyYW5z YWN0aW9uLmFzcHg/VXBsb2FkSUQ9NjM1ODIzMzE3OTEyNTIxNDEwJmFtcDtwd2Q9MW16a0JKJiM0 Mzs4R0tzWnZwdjgzUU1Vb3c9PSZhbXA7cmVjaXBpZW50PWw1R2IwdDJ3akUyVE5SYnp1QU8yZ0lP YzFMaGtxT0FBZFF5YXF3SEo3SEU9JmFtcDtyZWY9bDVHYjB0MndqRTJUTlJienVBTzJnSU9jMUxo a3FPQUFkUXlhcXdISjdIRT0mYW1wOyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtz ZXJpZiZxdW90OyI+bGluazwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+Lg0KIEnigJltIGFsc28gYXR0YWNoaW5nJm5ic3A7dGhlIHBkZiBmaWxlIGlu IGNhc2UgeW91IGhhdmUgdHJvdWJsZXMgdG8gb3BlbiB0aGUgZG9jIGZpbGUuIDxvOnA+DQo8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzVD NkQ3NSI+ZHJhZnQtaWV0Zi1kb3RzLXJlcXVpcmVtZW50cy0wMC1yZXYgTWVkLmRvYzxicj4NCmRy YWZ0LWlldGYtZG90cy1yZXF1aXJlbWVudHMtMDAtcmV2IE1lZC5wZGY8YnI+DQo8YnI+DQooVGhl c2UgZmlsZShzKSBhcmUgYXZhaWxhYmxlIHVudGlsIDEwLzExLzIwMTUgMTQ6NTA6MTYpPGJyPg0K PGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Q2hlZXJzLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+TWVkPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20g MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gTW9ydGVu c2VuLCBBbmRyZXcgW21haWx0bzphbW9ydGVuc2VuQGFyYm9yLm5ldF0NCjxicj4NCjxiPkVudm95 w6kmbmJzcDs6PC9iPiBqZXVkaSA1IG5vdmVtYnJlIDIwMTUgMDk6MTQ8YnI+DQo8Yj7DgCZuYnNw Ozo8L2I+IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE48YnI+DQo8Yj5DYyZuYnNwOzo8L2I+IGth bmFtZSBuaXNoaXp1a2E7IFJvbGFuZCBEb2JiaW5zOyBkb3RzQGlldGYub3JnOyB0c3Z3Z0BpZXRm Lm9yZzxicj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4gUmU6IFtEb3RzXSBCZXN0IHRyYW5zcG9ydCBz ZWxlY3Rpb24gZHVyaW5nIGFuIGF0dGFjaz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5ZZXMsIHRoaXMgaXMgY2FwdHVyZWQgaW4gT1AtMDA1IG9mIHRoZSBy ZXF1aXJlbWVudHMgZHJhZnQuIEkgZW5jb3VyYWdlIFdHIG1lbWJlcnMgdG8gcmVhZCBpdCBhbmQg c2VuZCBmZWVkYmFjay4gVGhhbmsgeW91LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+YW5kcmV3PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQpPbiBUaHVyc2RheSwgTm92ZW1iZXIgNSwgMjAx NSwgJmx0OzxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj5tb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBLYW5hbWUsPGJyPg0KPGJyPg0KSSBhZ3JlZSB3aXRoIHlv dXIgY29tbWVudCBhYm91dCB0aGUgc3RhdHVzLjxicj4NCjxicj4NCkZZSSwgd2UgaGFkIHRoaXMg cmVxdWlyZW1lbnQgaW4gLTAwIG9mIDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1yZWRkeS1kb3RzLXRyYW5zcG9ydC0wMCNzZWN0aW9uLTQiIHRhcmdldD0iX2JsYW5r Ij4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1yZWRkeS1kb3RzLXRyYW5zcG9y dC0wMCNzZWN0aW9uLTQ8L2E+Ojxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtvJm5ic3A7IEFja25v d2xlZGdlbWVudCBmb3IgdGhlIHByb2Nlc3Npbmcgb2YgYSBmaWx0ZXJpbmcgcmVxdWVzdCBhbmQg dGhlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgZW5mb3JjZW1lbnQgb2YgYXNzb2NpYXRlZCBj b3VudGVybWVhc3VyZXMuPGJyPg0KPGJyPg0KQ2hlZXJzLDxicj4NCk1lZDxicj4NCjxicj4NCiZn dDsgLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tPGJyPg0KJmd0OyBEZSZuYnNwOzogRG90cyBb bWFpbHRvOjxhIGhyZWY9ImphdmFzY3JpcHQ6OyI+ZG90cy1ib3VuY2VzQGlldGYub3JnPC9hPl0g RGUgbGEgcGFydCBkZSBrYW5hbWUgbmlzaGl6dWthPGJyPg0KJmd0OyBFbnZvecOpJm5ic3A7OiBq ZXVkaSA1IG5vdmVtYnJlIDIwMTUgMDc6MDk8YnI+DQomZ3Q7IMOAJm5ic3A7OiBSb2xhbmQgRG9i YmluczsgPGEgaHJlZj0iamF2YXNjcmlwdDo7Ij5kb3RzQGlldGYub3JnPC9hPjxicj4NCiZndDsg Q2MmbmJzcDs6IDxhIGhyZWY9ImphdmFzY3JpcHQ6OyI+dHN2d2dAaWV0Zi5vcmc8L2E+PGJyPg0K Jmd0OyBPYmpldCZuYnNwOzogUmU6IFtEb3RzXSBbdHN2d2ddIEJlc3QgdHJhbnNwb3J0IHNlbGVj dGlvbiBkdXJpbmcgYW4gYXR0YWNrPzxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNw OyAmZ3Q7dGhlIG9ubHkgbWlzc2lvbi1jcml0aWNhbCBET1RTIG1lc3NhZ2VzIGFyZSBtaXRpZ2F0 aW9uIHNlcnZpY2UgcmVxdWVzdHM8YnI+DQomZ3Q7IGZyb20gRE9UUyBjbGllbnRzIGFuZCBtaXRp Z2F0aW9uIHNlcnZpY2UgcmVmdXNhbHMgZnJvbSBET1RTIHNlcnZlcnMuPGJyPg0KJmd0Ozxicj4N CiZndDsgSSdtIGluIGZhdm9yIG9mIHRoZSBwb2ludGluZyBvdXQgb2YgdGhlIGxhdHRlciBwb2lu dDogbWl0aWdhdGlvbiBzZXJ2aWNlPGJyPg0KJmd0OyByZWZ1c2FscyBmcm9tIERPVFMgc2VydmVy cy48YnI+DQomZ3Q7IEluIG9wZXJhdG9yJ3MgcG9pbnQgb2YgdmlldywgcmV0dXJuaW5nIG9mIHN0 YXR1cyBpcyBpbmRpc3BlbnNhYmxlIHRvIGtub3c8YnI+DQomZ3Q7IHRoZSBtaXRpZ2F0aW9uIGlz IHN1Y2NlZWQgb3Igbm90Ljxicj4NCiZndDsgV2l0aG91dCBzdWNoIGluZm9ybWF0aW9uLCBpdCB3 aWxsIHRha2UgbW9yZSB0aW1lIHRvIGRlY2lkZSB0aGUgbmV4dDxicj4NCiZndDsgYWN0aW9uLCBz byBpdCB3aWxsIGhhcm0gdGhlIHZpY3RpbSBsb25nZXIuPGJyPg0KJmd0Ozxicj4NCiZndDsgSU1I TywgaW4gdGhpcyBtZWFuaW5nLCAmcXVvdDtTT1MmcXVvdDsgaXMgYSBsaXR0bGUgYml0IGNvbmZ1 c2luZyBiZWNhdXNlIGl0IHNlZW1zPGJyPg0KJmd0OyBsaWtlIHRoZSBzaWduYWxpbmcgaXMgb25l IGRpcmVjdGlvbmFsLjxicj4NCiZndDs8YnI+DQomZ3Q7IHJlZ2FyZHMsPGJyPg0KJmd0OyBrYW5h bWUgbmlzaGl6dWthPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IE9uIDIwMTUvMTEvMDQg MTA6MzcsIFJvbGFuZCBEb2JiaW5zIHdyb3RlOjxicj4NCiZndDsgJmd0OyBPbiA0IE5vdiAyMDE1 LCBhdCAxMDoyOSwgQWFyb24gRmFsayB3cm90ZTo8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn dDsmZ3Q7IEFuZCwgeW91IG1pZ2h0IG5vdCBiZSBhYmxlIHRvIHRlbGwgeW91IGhhdmUgYSBwcm9i bGVtIGdldHRpbmcgVURQPGJyPg0KJmd0OyB0aHJvdWdoIHVudGlsIHlvdSBhcmUgdW5kZXIgYXR0 YWNrLDxicj4NCiZndDsgJmd0OyZndDsgd2hlbiBzb21lIG9wZXJhdG9yIG1heSBpbXBsZW1lbnQg ZmlsdGVyaW5nIHRoYXQgaW5oaWJpdHMgY29ubmVjdGl2aXR5Ljxicj4NCiZndDsgJmd0Ozxicj4N CiZndDsgJmd0OyBSZWd1bGFyIGhlYXJ0YmVhdHMgYmV0d2VlbiBjbGllbnRzIGFuZCBzZXJ2ZXJz LCBjbGllbnRzIGFuZCByZWxheXMsIGFuZDxicj4NCiZndDsgcmVsYXlzIGFuZCBzZXJ2ZXJzIGNh biBzZXJ2ZSB0aGUgZnVuY3Rpb24gb2YgZW5zdXJpbmcgZW5kLXRvLWVuZDxicj4NCiZndDsgY29u bmVjdGl2aXR5IG9uIGFuIG9uZ29pbmcgYmFzaXMuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAm Z3Q7IEZhaWx1cmUgdG8gcmVjZWl2ZSBzZXJ2aWNlIHJlcXVlc3QgYWNrbm93bGVkZ2VtZW50cyBj YW4gc2VydmUgdGhpczxicj4NCiZndDsgcHVycG9zZSB1bmRlciBkdXJlc3MuPGJyPg0KJmd0OyAm Z3Q7PGJyPg0KJmd0OyAmZ3Q7IEl0J3MgZXhwZWN0ZWQgdGhhdCBET1RTIGNsaWVudHMgd2lsbCB1 cGRhdGUgRE9UUyBzZXJ2ZXJzIChlaXRoZXI8YnI+DQomZ3Q7IGRpcmVjdGx5IG9yIHZpYSBET1RT IHJlbGF5cykgd2l0aCBlaXRoZXIgY29udGludWVkIG1pdGlnYXRpb24gcmVxdWVzdHM8YnI+DQom Z3Q7IGFuZC9vciBzaXR1YXRpb25hbCB1cGRhdGVzIHdpdGggcmVnYXJkcyB0byBtaXRpZ2F0aW9u IGVmZmljYWN5IHRocm91Z2hvdXQ8YnI+DQomZ3Q7IG1pdGlnYXRpb24gc2VydmljZSB3aW5kb3dz LiZuYnNwOyBMaWtld2lzZSwgRE9UUyBzZXJ2ZXJzIGFyZSBleHBlY3RlZCB0byBkbyB0aGU8YnI+ DQomZ3Q7IHNhbWUgd2l0aCByZWdhcmRzIHRvIERPVFMgY2xpZW50cyAoYWdhaW4sIGVpdGhlciBk aXJlY3RseSBvciB2aWEgRE9UUzxicj4NCiZndDsgcmVsYXlzKS48YnI+DQomZ3Q7ICZndDs8YnI+ DQomZ3Q7ICZndDsgTm90ZSB0aGF0IG90aGVyIHRoYW4gYSBET1RTIHNlcnZlciByZWNlaXZpbmcg YSBET1RTIG1pdGlnYXRpb24gc2VydmljZTxicj4NCiZndDsgcmVxdWVzdHMsIG5vbmUgb2YgdGhl c2UgbWVzc2FnZSB0eXBlcyBhcmUgbmVjZXNzYXJ5IGluIG9yZGVyIHRvIG1pdGlnYXRpb248YnI+ DQomZ3Q7IHNlcnZpY2UgdG8gYmUgaW5pdGlhdGVkLiZuYnNwOyBUaGV5IGFyZSBpbXBvcnRhbnQg YW5kIHVzZWZ1bCwgYnV0IG5vdCBtaXNzaW9uLTxicj4NCiZndDsgY3JpdGljYWw7IHRoZSBvbmx5 IG1pc3Npb24tY3JpdGljYWwgRE9UUyBtZXNzYWdlcyBhcmUgbWl0aWdhdGlvbiBzZXJ2aWNlPGJy Pg0KJmd0OyByZXF1ZXN0cyBmcm9tIERPVFMgY2xpZW50cyBhbmQgbWl0aWdhdGlvbiBzZXJ2aWNl IHJlZnVzYWxzIGZyb20gRE9UUzxicj4NCiZndDsgc2VydmVycy48YnI+DQomZ3Q7ICZndDs8YnI+ DQomZ3Q7ICZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7 ICZndDsgUm9sYW5kIERvYmJpbnMgJmx0OzxhIGhyZWY9ImphdmFzY3JpcHQ6OyI+cmRvYmJpbnNA YXJib3IubmV0PC9hPiZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7ICZndDsgRG90 cyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsgPGEgaHJlZj0iamF2YXNjcmlwdDo7Ij5Eb3Rz QGlldGYub3JnPC9hPjxicj4NCiZndDsgJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2RvdHMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHM8L2E+PGJyPg0KJmd0Ozxicj4NCiZndDsgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IERvdHMg bWFpbGluZyBsaXN0PGJyPg0KJmd0OyA8YSBocmVmPSJqYXZhc2NyaXB0OjsiPkRvdHNAaWV0Zi5v cmc8L2E+PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2RvdHMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2RvdHM8L2E+PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQpEb3RzIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9 ImphdmFzY3JpcHQ6OyI+RG90c0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHMiIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHM8L2E+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_787AE7BB302AE849A7480A190F8B933008C98572OPEXCLILMA3corp_-- From nobody Thu Nov 5 06:25: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 A676D1B2DB3; Thu, 5 Nov 2015 06:25:46 -0800 (PST) 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 cF9vJiYHeI2F; Thu, 5 Nov 2015 06:25:44 -0800 (PST) Received: from mx-out01.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 29B6B1B2DBD; Thu, 5 Nov 2015 06:25:37 -0800 (PST) X-Virus-Scanned: amavisd-new at kolabnow.com Received: from mx03.mykolab.com (mx03.mykolab.com [10.20.7.101]) by mx-out01.mykolab.com (Postfix) with ESMTPS id 5C37062116; Thu, 5 Nov 2015 15:25:34 +0100 (CET) To: Roland Dobbins References: <5638D31B.4080801@mti-systems.com> <10B4A768-25EC-4AFF-99D0-1BEC1C24CF2A@arbor.net> <563AF27B.8010009@nttv6.jp> <787AE7BB302AE849A7480A190F8B933008C98037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <828773FE19B05B4581311493A046E85E3F619C04D9@HE111642.emea1.cds.t-internal.com> <3F352E09-6415-4409-AE95-68FFD5020C04@arbor.net> <828773FE19B05B4581311493A046E85E3F619C06A7@HE111642.emea1.cds.t-internal.com> <8867EE91-82F0-4F4D-B6B2-1BB70B616347@arbor.net> From: Paul Ferguson Organization: Clowns R. Mofos Message-ID: <563B66D7.8020505@mykolab.com> Date: Thu, 5 Nov 2015 06:25:27 -0800 In-Reply-To: <8867EE91-82F0-4F4D-B6B2-1BB70B616347@arbor.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: tsvwg@ietf.org, dots@ietf.org Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 05 Nov 2015 14:25:46 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 11/5/2015 3:27 AM, Roland Dobbins wrote: >> If the DOTS server is connected to a different provider than >> DOTS client, then this is a "remote access". Is the provider >> terminating the DOTS client access part of the DDoS defense >> system or may this provider be agnostic to all that? > > The main issue is intervening networks. > >> If the latter is true plain provider IP service is my expectation >> and then QoS transport between client and server is a challenge. > > Yes, that's correct (along with the administrative and > internal-political challenges operators may face even when they're > directly topologically adjacent to the requesting organization's > network). Correct. And that is the big problem with QoS/diffserv packet marking: Once a packet leaves your network and your administrative control, no one has to honor your packet markings (QoS). All bets are off. - - 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 iF4EAREIAAYFAlY7ZtcACgkQKJasdVTchbLdhwD/Rmjk2H1fUperSsoDhk7TkeOS RINC2V3ooD9+BkLdnoEA/2KirmljqYeyS/Pr+fhVBoPp1ChfT5WcELuIZJENdkzI =0jkt -----END PGP SIGNATURE----- From nobody Thu Nov 5 07:33: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 89EED1B2F59 for ; Thu, 5 Nov 2015 07:33:54 -0800 (PST) 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 ZLoIqWLKmA9Q for ; Thu, 5 Nov 2015 07:33:53 -0800 (PST) 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 92D4E1B2F5D for ; Thu, 5 Nov 2015 07:30:43 -0800 (PST) Received: by ykba4 with SMTP id a4so136472438ykb.3 for ; Thu, 05 Nov 2015 07:30:42 -0800 (PST) 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=ymGHpO2cI50J/r2aijg40AcJNkNQLq6NdgRSKNECdpE=; b=BgeytbZVlaPX1ooXvj0WCQkybqueY/caTE4mlGDaf5HPBqKa9nlhpH/uF5PPgtlrTw FWSZhwKUOjzgmGo90E1wUpGbT0i9q1AAGs7pmjskMz0hyiDZXw/YUlOk8IJDspgLCskq KmVlYBQq2ny8KnKhfX6Q7LZ5QWumIG2uRwVqboxTRzd7PGGefINR6dwDjyIYdWlgO1IT oyRKh1Drrb0KfG+BgN10NJS7/Nh6o5Z5fZPMRY11SwhEAHVCYN8Mhd8vprqzjg7pTcH1 GmZeI7o+XHJvv1iKfAzvHphoR63P+w6v3WA7miZdi0+xBFpgMQonHLaVEdVK8Ag1/NuO NWRA== X-Received: by 10.31.50.205 with SMTP id y196mr7679252vky.150.1446737442792; Thu, 05 Nov 2015 07:30:42 -0800 (PST) Received: from [172.20.2.201] ([65.200.157.66]) by smtp.gmail.com with ESMTPSA id n84sm4958387vke.21.2015.11.05.07.30.41 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Nov 2015 07:30:41 -0800 (PST) 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: <84166B32-E182-4E80-9827-C926A7A414DC@arbor.net> Date: Thu, 5 Nov 2015 10:30:40 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <714BBFE6-AD22-413C-BBC2-DD51A0DAAAC2@gmail.com> References: <84166B32-E182-4E80-9827-C926A7A414DC@arbor.net> To: Roland Dobbins Archived-At: Cc: dots Subject: Re: [Dots] dots-threats-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: Thu, 05 Nov 2015 15:33:54 -0000 The security considerations should suffice. The WG will just need to have t= he appropriate text co weed in the appropriate draft. Thanks, Kathleen=20 Sent from my iPhone > On Nov 5, 2015, at 5:41 AM, Roland Dobbins wrote: >=20 >=20 > Do we need a separate dots-threats draft to lay out potential threats to D= OTS communications channels/nodes in detail, or will the security sections o= f the relevant drafts suffice? >=20 > ----------------------------------- > Roland Dobbins >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Nov 5 15:30: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 18EC91B2F03 for ; Thu, 5 Nov 2015 15:30:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 SIGQoLkwVYJ4 for ; Thu, 5 Nov 2015 15:30:38 -0800 (PST) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::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 0CC861B35E4 for ; Thu, 5 Nov 2015 15:30:38 -0800 (PST) Received: by iodd200 with SMTP id d200so107382579iod.0 for ; Thu, 05 Nov 2015 15:30:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TLKwPZsqCanrZxy9pygB9pbAIZbaTTS+QrCoFEoulDI=; b=LEOlCdT9q5E5KBYd3t2GTPCZQURsCfJyLRYUScSV4XrSmtI9WEEUQErdJoQQYqaBdv qnGoJLBcqPbnQPNeF4awxU14EvZYqQ4Tg1W8cqCAg79r9R6cF7Mgvy/w/tRjTCWbqDUG WiZiGTUCZqbp+If2JWeSnY/kyF11O6nIDzYcA= 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=TLKwPZsqCanrZxy9pygB9pbAIZbaTTS+QrCoFEoulDI=; b=dWoPPFJ91ZAQAjwYZlCdh/cgjiZ8IH8ZCcPVskDGZhdirxytd8mXf/NwiOrJvCpqAD CiO+R//WburwgTnrNeWMs0PU2qreRctRF8BD6aYwy148wwBDm4WOqe5DrIXMKRlTUMuN hBQ1brMD0rt1qn8rzUvIE+2aY/gOJ9Z9QwI2p4fE/9fCfVxqg/yVLTP5GmrcWVhM/Hpo c/Etstpr26qmM3dPWi2+PaHlPzDMk4uVT/qH9au9DjpCDajAogd+9rmi8A5MgnrtjomW EPfHDhOkBA1VB+OdNVOIHxxNT0cy1uZ0eKK+oBwlGgyza23H+2y2lFswQPO+9PS95YhQ kpMQ== X-Gm-Message-State: ALoCoQmMhb38KlYRGwVx+keAHkaV3dDfmiEBjgoTyrM/JntgaEofNuldE8hPzR3o+ngosfsDiTWk MIME-Version: 1.0 X-Received: by 10.107.130.220 with SMTP id m89mr12731363ioi.35.1446766237379; Thu, 05 Nov 2015 15:30:37 -0800 (PST) Received: by 10.64.69.169 with HTTP; Thu, 5 Nov 2015 15:30:37 -0800 (PST) In-Reply-To: <787AE7BB302AE849A7480A190F8B933008C98572@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933008C98572@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Thu, 5 Nov 2015 18:30:37 -0500 Message-ID: From: "Mortensen, Andrew" To: "mohamed.boucadair@orange.com" Content-Type: multipart/alternative; boundary=001a113eee3ca7119a0523d3834e Archived-At: Cc: "dots@ietf.org" Subject: Re: [Dots] Comments about the requirements draft (RE: Best transport selection during an attack?) 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, 05 Nov 2015 23:30:40 -0000 --001a113eee3ca7119a0523d3834e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks, Med. I'm in transit back from Yokohama, so I'll review and comment as soon as I can. andrew On Thursday, November 5, 2015, wrote: > Hi Andrew, > > > > You can retrieve my first review of the requirements draft from this link > . > I=E2=80=99m also attaching the pdf file in case you have troubles to open= the doc > file. > > > > draft-ietf-dots-requirements-00-rev Med.doc > draft-ietf-dots-requirements-00-rev Med.pdf > > (These file(s) are available until 10/11/2015 14:50:16) > > Cheers, > > Med > > > > *De :* Mortensen, Andrew [mailto:amortensen@arbor.net > ] > *Envoy=C3=A9 :* jeudi 5 novembre 2015 09:14 > *=C3=80 :* BOUCADAIR Mohamed IMT/OLN > *Cc :* kaname nishizuka; Roland Dobbins; dots@ietf.org > ; tsvwg@ietf.org > > *Objet :* Re: [Dots] Best transport selection during an attack? > > > > Yes, this is captured in OP-005 of the requirements draft. I encourage WG > members to read it and send feedback. Thank you. > > > > andrew > > > > On Thursday, November 5, 2015, > wrote: > > Hi Kaname, > > I agree with your comment about the status. > > FYI, we had this requirement in -00 of > https://tools.ietf.org/html/draft-reddy-dots-transport-00#section-4: > > o Acknowledgement for the processing of a filtering request and the > enforcement of associated countermeasures. > > Cheers, > Med > > > -----Message d'origine----- > > De : Dots [mailto:dots-bounces@ietf.org] De la part de kaname nishizuka > > Envoy=C3=A9 : jeudi 5 novembre 2015 07:09 > > =C3=80 : Roland Dobbins; dots@ietf.org > > Cc : tsvwg@ietf.org > > Objet : Re: [Dots] [tsvwg] Best transport selection during an attack? > > > > > > >the only mission-critical DOTS messages are mitigation service reques= ts > > from DOTS clients and mitigation service refusals from DOTS servers. > > > > I'm in favor of the pointing out of the latter point: mitigation servic= e > > refusals from DOTS servers. > > In operator's point of view, returning of status is indispensable to kn= ow > > the mitigation is succeed or not. > > Without such information, it will take more time to decide the next > > action, so it will harm the victim longer. > > > > IMHO, in this meaning, "SOS" is a little bit confusing because it seems > > like the signaling is one directional. > > > > regards, > > kaname nishizuka > > > > > > On 2015/11/04 10:37, Roland Dobbins wrote: > > > On 4 Nov 2015, at 10:29, Aaron Falk wrote: > > > > > >> And, you might not be able to tell you have a problem getting UDP > > through until you are under attack, > > >> when some operator may implement filtering that inhibits connectivit= y. > > > > > > Regular heartbeats between clients and servers, clients and relays, a= nd > > relays and servers can serve the function of ensuring end-to-end > > connectivity on an ongoing basis. > > > > > > Failure to receive service request acknowledgements can serve this > > purpose under duress. > > > > > > It's expected that DOTS clients will update DOTS servers (either > > directly or via DOTS relays) with either continued mitigation requests > > and/or situational updates with regards to mitigation efficacy througho= ut > > mitigation service windows. Likewise, DOTS servers are expected to do > the > > same with regards to DOTS clients (again, either directly or via DOTS > > relays). > > > > > > Note that other than a DOTS server receiving a DOTS mitigation servic= e > > requests, none of these message types are necessary in order to > mitigation > > service to be initiated. They are important and useful, but not missio= n- > > critical; the only mission-critical DOTS messages are mitigation servic= e > > requests from DOTS clients and mitigation service refusals from DOTS > > servers. > > > > > > ----------------------------------- > > > 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 > --001a113eee3ca7119a0523d3834e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks, Med. I'm in transit back from Yokohama, so I'll review and = comment as soon as I can.

andrew

On = Thursday, November 5, 2015, <mohamed.boucadair@orange.com> wrote:

Hi Andrew,

=C2=A0

You can retrieve my first revie= w of the requirements draft from this link. I=E2=80=99m also attaching=C2=A0the pdf file in case you have troubles to = open the doc file.

=C2=A0

draft-ietf-= dots-requirements-00-rev Med.doc
draft-ietf-dots-requirements-00-rev Med.pdf

(These file(s) are available until 10/11/2015 14:50:16)

Cheers,

Med=

=C2=A0

De=C2=A0: Mort= ensen, Andrew [mailto:amortensen@arbor.net]
Envoy=C3=A9=C2=A0: jeudi 5 novembre 2015 09:14
=C3=80=C2=A0: BOUCADAIR Mohamed IMT/OLN
Cc=C2=A0: kaname nishizuka; Roland Dobbins; dots@ie= tf.org; tsvwg@ietf.org
Objet=C2=A0: Re: [Dots] Best transport selection during an attack?

=C2=A0

Yes, this is captured in OP-005 of the requirements = draft. I encourage WG members to read it and send feedback. Thank you.

=C2=A0

andrew



On Thursday, November 5, 2015, <mohamed.= boucadair@orange.com> wrote:

Hi Kaname,

I agree with your comment about the status.

FYI, we had this requirement in -00 of https://tools.ietf.org/html/draft-reddy-dots-transport-00#section-4:
=C2=A0 =C2=A0o=C2=A0 Acknowledgement for the processing of a filtering requ= est and the
=C2=A0 =C2=A0 =C2=A0 enforcement of associated countermeasures.

Cheers,
Med

> -----Message d'origine-----
> De=C2=A0: Dots [mailto:dots-bounces@ietf.org] De la part de kan= ame nishizuka
> Envoy=C3=A9=C2=A0: jeudi 5 novembre 2015 07:09
> =C3=80=C2=A0: Roland Dobbins; dots@ietf.org
> Cc=C2=A0: tsvwg@ietf.org
> Objet=C2=A0: Re: [Dots] [tsvwg] Best transport selection during an att= ack?
>
>
>=C2=A0 >the only mission-critical DOTS messages are mitigation servi= ce requests
> from DOTS clients and mitigation service refusals from DOTS servers. >
> I'm in favor of the pointing out of the latter point: mitigation s= ervice
> refusals from DOTS servers.
> In operator's point of view, returning of status is indispensable = to know
> the mitigation is succeed or not.
> Without such information, it will take more time to decide the next > action, so it will harm the victim longer.
>
> IMHO, in this meaning, "SOS" is a little bit confusing becau= se it seems
> like the signaling is one directional.
>
> regards,
> kaname nishizuka
>
>
> On 2015/11/04 10:37, Roland Dobbins wrote:
> > On 4 Nov 2015, at 10:29, Aaron Falk wrote:
> >
> >> And, you might not be able to tell you have a problem getting= UDP
> through until you are under attack,
> >> when some operator may implement filtering that inhibits conn= ectivity.
> >
> > Regular heartbeats between clients and servers, clients and relay= s, and
> relays and servers can serve the function of ensuring end-to-end
> connectivity on an ongoing basis.
> >
> > Failure to receive service request acknowledgements can serve thi= s
> purpose under duress.
> >
> > It's expected that DOTS clients will update DOTS servers (eit= her
> directly or via DOTS relays) with either continued mitigation requests=
> and/or situational updates with regards to mitigation efficacy through= out
> mitigation service windows.=C2=A0 Likewise, DOTS servers are expected = to do the
> same with regards to DOTS clients (again, either directly or via DOTS<= br> > relays).
> >
> > Note that other than a DOTS server receiving a DOTS mitigation se= rvice
> requests, none of these message types are necessary in order to mitiga= tion
> service to be initiated.=C2=A0 They are important and useful, but not = mission-
> critical; the only mission-critical DOTS messages are mitigation servi= ce
> requests from DOTS clients and mitigation service refusals from DOTS > servers.
> >
> > -----------------------------------
> > Roland Dobbins <rdobbins@arbor.net>
> >
> > _______________________________________________
> > 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
ht= tps://www.ietf.org/mailman/listinfo/dots

--001a113eee3ca7119a0523d3834e-- From nobody Thu Nov 5 18:37: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 6CBAF1B3385 for ; Thu, 5 Nov 2015 18:37:19 -0800 (PST) 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 BifxzKO8dN9x for ; Thu, 5 Nov 2015 18:37:16 -0800 (PST) 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 D3E851B33F5 for ; Thu, 5 Nov 2015 18:37:16 -0800 (PST) Received: by pabfh17 with SMTP id fh17so106317676pab.0 for ; Thu, 05 Nov 2015 18:37:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=from:content-type:content-transfer-encoding:mime-version:subject :message-id:date:references:in-reply-to:to; bh=pKqHN5/nIliGhv1IBgwSpsUCKwx2rFPz0yXE/SvfRjs=; b=f9TzKkv7RuaXLdq82bUODzALy4+2uY+k0UwmRoFnNfGemQBc6PDae1Ob0sYko/z4Gj L+SeShInnXVbaJwC3ZCqND8igY0WDmd303Lx6X/zgO1CyafM3MaoL2vMQKJaWDVxWVSN mSWn1rezQPzzkROR9A2q/TTNS3Vys6GrxWnhA= 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 :mime-version:subject:message-id:date:references:in-reply-to:to; bh=pKqHN5/nIliGhv1IBgwSpsUCKwx2rFPz0yXE/SvfRjs=; b=maObmrue4HJ1L+/gPipWKDujJsS3DqZU3nYM9Dz70s0RR8j1mE0qT8g9TEPfubfm5a 1lAGXrRx5WgpcREu4InhZk6EWxSpLgWLwjhlaCvt/INOcO7hZJBhFKl985opkjkWi3V7 VF7LgQrzRpG3Fl8j/X0EtzaaJv04dUK8ZNoMgIroRv4w6RO60ZzSYhXlw49gRMMDdnT+ WwoeZ87pvwZbn0kRs5+Cm3/xr5867xMgcXBuJV4yNhct1WzB47o6447vKLnQ77b0UmVR Vf5BOE0ueLeyD7XRFaqGXl/seqV38yYsW9b0D/erLL+8ds3rdsmUJuv3JyVdSfRGd8F6 DuHQ== X-Gm-Message-State: ALoCoQnGRdTcwjlnyi0qXn/V5JFImkwMm50L9sEOiExGuMqjPOrCgXRXpLMSLtqrb6h1voo7V/U6 X-Received: by 10.66.191.68 with SMTP id gw4mr14110426pac.42.1446777436426; Thu, 05 Nov 2015 18:37:16 -0800 (PST) Received: from [10.153.2.200] (ppp-27-55-23-173.revip3.asianet.co.th. [27.55.23.173]) by smtp.gmail.com with ESMTPSA id qn5sm10361890pac.41.2015.11.05.18.37.15 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Nov 2015 18:37:15 -0800 (PST) From: Roland Dobbins Content-Type: multipart/alternative; boundary=Apple-Mail-15ABF57D-052C-445C-9808-5CE5AE796C0D Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Message-Id: Date: Fri, 6 Nov 2015 11:37:12 +0900 References: <1CE9E2C8-FFEB-47D6-8C14-7DC8CEF154CA@arbor.net> In-Reply-To: <1CE9E2C8-FFEB-47D6-8C14-7DC8CEF154CA@arbor.net> To: "dots@ietf.org" X-Mailer: iPhone Mail (13B143) Archived-At: Subject: Re: [Dots] Message types, sub-types, etc. (was Re: [tsvwg] Best transport selection during an attack?) 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, 06 Nov 2015 02:37:19 -0000 --Apple-Mail-15ABF57D-052C-445C-9808-5CE5AE796C0D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On Nov 5, 2015, at 7:38 PM, Roland Dobbins wrote: > these are just functional categories) btw, these aren't meant to be prescriptive, just strawman examples. They s= houldn't be interpreted as a design statement. ----------------------------------- Roland Dobbins = --Apple-Mail-15ABF57D-052C-445C-9808-5CE5AE796C0D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit


On Nov 5, 2015, at 7:38 PM, Roland Dobbins <rdobbins@arbor.net> wrote:

these are just functional categories)

btw, these aren't meant to be prescriptive, just strawman examples.   They shouldn't be interpreted as a design statement.

-----------------------------------
Roland Dobbins <rdobbins@arbor.net>
--Apple-Mail-15ABF57D-052C-445C-9808-5CE5AE796C0D-- From nobody Fri Nov 6 00:43: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 BD9841A89F0; Fri, 6 Nov 2015 00:43:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 u4M_VQyvTKXW; Fri, 6 Nov 2015 00:43:04 -0800 (PST) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8D5C1A8931; Fri, 6 Nov 2015 00:43:03 -0800 (PST) Received: from s4de8nsazdfe010.bmbg.telekom.de ([10.175.246.202]) by tcmail11.telekom.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 06 Nov 2015 09:42:49 +0100 X-IronPort-AV: E=Sophos;i="5.20,251,1444687200"; d="scan'208";a="770916964" Received: from he113472.emea1.cds.t-internal.com ([10.134.93.130]) by q4de8nsa015.bmbg.telekom.de with ESMTP/TLS/AES128-SHA; 06 Nov 2015 09:42:48 +0100 Received: from HE111642.emea1.cds.t-internal.com ([10.134.93.11]) by HE113472.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 6 Nov 2015 09:42:48 +0100 From: To: Date: Fri, 6 Nov 2015 09:42:47 +0100 Thread-Topic: ***CAUTION_Invalid_Signature*** Re: [tsvwg] [Dots] Best transport selection during an attack? Thread-Index: AdEYFPKJz91IY2UMS1SRIgtidyi7+gAVqciA Message-ID: <828773FE19B05B4581311493A046E85E3F619C0AA2@HE111642.emea1.cds.t-internal.com> References: <5638D31B.4080801@mti-systems.com> <10B4A768-25EC-4AFF-99D0-1BEC1C24CF2A@arbor.net> <563AF27B.8010009@nttv6.jp> <787AE7BB302AE849A7480A190F8B933008C98037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <828773FE19B05B4581311493A046E85E3F619C04D9@HE111642.emea1.cds.t-internal.com> <3F352E09-6415-4409-AE95-68FFD5020C04@arbor.net> <828773FE19B05B4581311493A046E85E3F619C06A7@HE111642.emea1.cds.t-internal.com> <8867EE91-82F0-4F4D-B6B2-1BB70B616347@arbor.net> <563B66D7.8020505@mykolab.com> In-Reply-To: <563B66D7.8020505@mykolab.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: rdobbins@arbor.net, tsvwg@ietf.org, dots@ietf.org Subject: Re: [Dots] ***CAUTION_Invalid_Signature*** Re: [tsvwg] Best transport selection during an attack? 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, 06 Nov 2015 08:43:06 -0000 Paul, I'd expect business customers products offering QoS enabled access types. T= he point here is the server to client direction where QoS would be desirabl= e. This requires QoS transit/peering between server provider and client pro= vider for plain IP. That is rare, I guess. In Germany, bilateral QoS interconnection at least for VPN like wholesale s= ervice will be a commodity within the next 5 years, I think. I understand that the overlay model is expected, i.e. customers buying inte= rnet connectivity at provider A and getting value added service by provider= B. If there's no incentive for A and B to cooperate, some bad guy fills th= e best effort pipe and out of band signaling is not an option, transport de= sign is a serious task. =20 Regards, Ruediger -----Urspr=FCngliche Nachricht----- Von: tsvwg [mailto:tsvwg-bounces@ietf.org] Im Auftrag von Paul Ferguson Gesendet: Donnerstag, 5. November 2015 15:25 An: Roland Dobbins Cc: tsvwg@ietf.org; dots@ietf.org Betreff: ***CAUTION_Invalid_Signature*** Re: [tsvwg] [Dots] Best transport = selection during an attack? On 11/5/2015 3:27 AM, Roland Dobbins wrote: >> If the DOTS server is connected to a different provider than DOTS=20 >> client, then this is a "remote access". Is the provider terminating=20 >> the DOTS client access part of the DDoS defense system or may this=20 >> provider be agnostic to all that? >=20 > The main issue is intervening networks. >=20 >> If the latter is true plain provider IP service is my expectation and=20 >> then QoS transport between client and server is a challenge. >=20 > Yes, that's correct (along with the administrative and=20 > internal-political challenges operators may face even when they're=20 > directly topologically adjacent to the requesting organization's=20 > network). Correct. And that is the big problem with QoS/diffserv packet marking: Once a packet leaves your network and your administrative control, no one h= as to honor your packet markings (QoS). All bets are off. - ferg -- Paul Ferguson PGP Public Key ID: 0x54DC85B2 Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2 From nobody Fri Nov 6 01:46: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 C83921B37F9; Fri, 6 Nov 2015 01:41:33 -0800 (PST) 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 4DZwI2PLzqwd; Fri, 6 Nov 2015 01:41:32 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 1512C1B37F7; Fri, 6 Nov 2015 01:41:32 -0800 (PST) Received: from erg.abdn.ac.uk (galactica.erg.abdn.ac.uk [139.133.210.32]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 673EF1B001B8; Fri, 6 Nov 2015 09:48:45 +0000 (GMT) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by erg.abdn.ac.uk with HTTP; Fri, 6 Nov 2015 09:41:30 -0000 Message-ID: In-Reply-To: <563B66D7.8020505@mykolab.com> References: <5638D31B.4080801@mti-systems.com> <10B4A768-25EC-4AFF-99D0-1BEC1C24CF2A@arbor.net> <563AF27B.8010009@nttv6.jp> <787AE7BB302AE849A7480A190F8B933008C98037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <828773FE19B05B4581311493A046E85E3F619C04D9@HE111642.emea1.cds.t-internal.com> <3F352E09-6415-4409-AE95-68FFD5020C04@arbor.net> <828773FE19B05B4581311493A046E85E3F619C06A7@HE111642.emea1.cds.t-internal.com> <8867EE91-82F0-4F4D-B6B2-1BB70B616347@arbor.net> <563B66D7.8020505@mykolab.com> Date: Fri, 6 Nov 2015 09:41:30 -0000 From: gorry@erg.abdn.ac.uk To: "Paul Ferguson" User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: X-Mailman-Approved-At: Fri, 06 Nov 2015 01:46:35 -0800 Cc: Roland Dobbins , tsvwg@ietf.org, dots@ietf.org Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 06 Nov 2015 09:41:33 -0000 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 11/5/2015 3:27 AM, Roland Dobbins wrote: > >>> If the DOTS server is connected to a different provider than >>> DOTS client, then this is a "remote access". Is the provider >>> terminating the DOTS client access part of the DDoS defense >>> system or may this provider be agnostic to all that? >> >> The main issue is intervening networks. >> >>> If the latter is true plain provider IP service is my expectation >>> and then QoS transport between client and server is a challenge. >> >> Yes, that's correct (along with the administrative and >> internal-political challenges operators may face even when they're >> directly topologically adjacent to the requesting organization's >> network). > > Correct. And that is the big problem with QoS/diffserv packet marking: > Once a packet leaves your network and your administrative control, no > one has to honor your packet markings (QoS). All bets are off. > > - - ferg > All true and we're likely to need multiple repeated packets sent to a achieve any robustness- but I wonder if the important question is here: "would setting a non-default DSCP actually reduce the chance that a packet reaches the intended destination?" Gorry > - -- > 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 > > iF4EAREIAAYFAlY7ZtcACgkQKJasdVTchbLdhwD/Rmjk2H1fUperSsoDhk7TkeOS > RINC2V3ooD9+BkLdnoEA/2KirmljqYeyS/Pr+fhVBoPp1ChfT5WcELuIZJENdkzI > =0jkt > -----END PGP SIGNATURE----- > From nobody Fri Nov 6 03:46: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 DDB931B3A56 for ; Fri, 6 Nov 2015 03:46:05 -0800 (PST) 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 IQ-8y1lr0EqT for ; Fri, 6 Nov 2015 03:46:05 -0800 (PST) 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 E314B1B3645 for ; Fri, 6 Nov 2015 03:46:04 -0800 (PST) Received: by padhx2 with SMTP id hx2so113007876pad.1 for ; Fri, 06 Nov 2015 03:46:04 -0800 (PST) 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=wRSvqOuwwP8n9kiU30JB7C+2uqfZ5YiMVhl5tyW0oKA=; b=hUu9eQFwMOp4sZL+dSpjqQKovIOdddqiCOMlwfdfvHRyrzQujPlhqT+wAe8IrdRGiF bwJFdT0tpJ+6tUbcmTAlzXJb2g7GMuBsk2l6BpbLhBaaYBtF0lSw3t85Ll9i/Oo+m4kE JQCGc4iisM0mkYY9V4nFCTa9xzFCl9kduUjeY= 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=wRSvqOuwwP8n9kiU30JB7C+2uqfZ5YiMVhl5tyW0oKA=; b=ZlYSjni238byblQ41L3VLY50ce0u8cumY0qIRSupoFK0KSgUgJu7v66FsKAIumx2kb FvJWsrfjh+DYBKseSY0mSutmcxKFD6NgtED5OwxZSooU0EpVa2k0v7YoyXzwn3rYjIpL Fq80Js4dxn5ah1svEwvD+C/N9KRm9BK6iDS2sQgMTgkyW0DJ2RCnv7k6kOszJ4bnSj18 /ub+bGMPv4QkB544Vtt+erW0vagdpghKvfMWtcZ07ooz85WckGCj9lmtmNf7G36+mWYt JYfwz0wfdMB2mmUcBpLAAJDV2MuE4W1/cR7Okb9zoZZ3hgjjYZev9yK7bron1DnbofA1 UqBg== X-Gm-Message-State: ALoCoQmva1IzO2xPyugHSiU1MxChjdYtfyam/huQRghS34s673rJ549eJ57zdL0vVx1+m18ZTdDQ X-Received: by 10.68.195.129 with SMTP id ie1mr17099739pbc.100.1446810364573; Fri, 06 Nov 2015 03:46:04 -0800 (PST) Received: from [172.19.254.119] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id hq1sm13680486pbb.43.2015.11.06.03.46.02 (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 06 Nov 2015 03:46:03 -0800 (PST) From: "Roland Dobbins" To: tsvwg@ietf.org Date: Fri, 06 Nov 2015 20:46:00 +0900 Message-ID: In-Reply-To: References: <5638D31B.4080801@mti-systems.com> <10B4A768-25EC-4AFF-99D0-1BEC1C24CF2A@arbor.net> <563AF27B.8010009@nttv6.jp> <787AE7BB302AE849A7480A190F8B933008C98037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <828773FE19B05B4581311493A046E85E3F619C04D9@HE111642.emea1.cds.t-internal.com> <3F352E09-6415-4409-AE95-68FFD5020C04@arbor.net> <828773FE19B05B4581311493A046E85E3F619C06A7@HE111642.emea1.cds.t-internal.com> <8867EE91-82F0-4F4D-B6B2-1BB70B616347@arbor.net> <563B66D7.8020505@mykolab.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5164) Archived-At: Cc: dots@ietf.org Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 06 Nov 2015 11:46:06 -0000 On 6 Nov 2015, at 18:41, gorry@erg.abdn.ac.uk wrote: > but I wonder if the important question is here: > "would setting a non-default DSCP actually reduce the chance that a > packet > reaches the intended destination?" QoS *may* be set up for DOTS traffic by operators who're providing transit and who're also performing upstream DDoS mitigation services for endpoint networks who buy transit from them. But we can't count on that due to a) overlays and b) operators may not set it up for various reasons. It should certainly be recommended in terms of deployment guidances in directly-connected scenarios, IMHO, but would be just that - a recommendation. ----------------------------------- Roland Dobbins From nobody Fri Nov 6 04:34: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 95AA71A00DC; Fri, 6 Nov 2015 04:34:54 -0800 (PST) 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 psPXlssjL4yX; Fri, 6 Nov 2015 04:34:53 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 7311E1A00B1; Fri, 6 Nov 2015 04:34:53 -0800 (PST) Received: from erg.abdn.ac.uk (galactica.erg.abdn.ac.uk [139.133.210.32]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 36E821B004AC; Fri, 6 Nov 2015 12:42:07 +0000 (GMT) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by erg.abdn.ac.uk with HTTP; Fri, 6 Nov 2015 12:34:52 -0000 Message-ID: <63365570489be7b350f41ad796ee1e3b.squirrel@erg.abdn.ac.uk> In-Reply-To: References: <5638D31B.4080801@mti-systems.com> <10B4A768-25EC-4AFF-99D0-1BEC1C24CF2A@arbor.net> <563AF27B.8010009@nttv6.jp> <787AE7BB302AE849A7480A190F8B933008C98037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <828773FE19B05B4581311493A046E85E3F619C04D9@HE111642.emea1.cds.t-internal.com> <3F352E09-6415-4409-AE95-68FFD5020C04@arbor.net> <828773FE19B05B4581311493A046E85E3F619C06A7@HE111642.emea1.cds.t-internal.com> <8867EE91-82F0-4F4D-B6B2-1BB70B616347@arbor.net> <563B66D7.8020505@mykolab.com> Date: Fri, 6 Nov 2015 12:34:52 -0000 From: gorry@erg.abdn.ac.uk To: "Roland Dobbins" User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: tsvwg@ietf.org, dots@ietf.org Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 06 Nov 2015 12:34:54 -0000 > On 6 Nov 2015, at 18:41, gorry@erg.abdn.ac.uk wrote: > >> but I wonder if the important question is here: >> "would setting a non-default DSCP actually reduce the chance that a >> packet >> reaches the intended destination?" > > QoS *may* be set up for DOTS traffic by operators who're providing > transit and who're also performing upstream DDoS mitigation services for > endpoint networks who buy transit from them. > > But we can't count on that due to a) overlays and b) operators may not > set it up for various reasons. > > It should certainly be recommended in terms of deployment guidances in > directly-connected scenarios, IMHO, but would be just that - a > recommendation. > Yes I understand how diffserv works, indeed you need to say the protocol MUST NOT rely upon this being set. Would it say "MAY set a DSCP" or "SHOULD set a DSCP" or ... SO my question(s) are: (1) If we can recommend setting a DSCP - which one? (2) Is there a reason that a sender would only set this if you know you are in one operator domain (how would you know this? (is it more likely to be discarded??) so (3) why not set it anyway (even if it is bleached) at operator boundaries? Gorry > ----------------------------------- > Roland Dobbins > From nobody Fri Nov 6 04:42: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 5AC6A1A00FE for ; Fri, 6 Nov 2015 04:42:00 -0800 (PST) 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=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 edlk0AczAL-O for ; Fri, 6 Nov 2015 04:41:59 -0800 (PST) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::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 401BB1A00F9 for ; Fri, 6 Nov 2015 04:41:59 -0800 (PST) Received: by vkex70 with SMTP id x70so12900719vke.3 for ; Fri, 06 Nov 2015 04:41:58 -0800 (PST) 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=REHsgJb4MW97tfo4RKpUwqsiLhclWXKEHvhN9jL9/r0=; b=J4g+se/LEaF9qJikQhCLVjkYLOWe3M4jzuZjLZBF+T79UxPowjEnqkOvckFYtMSexz /x0fyqfkTAZfh55dO+3AQCQ6BYnmkZrQHY2g8j4Mw9bYSqGsYoZUmiaIDgA2Z2JFK2cU GVGMgOs2Y6v4RXy49jgrO/qL75FUb+NL0nDHc= 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=REHsgJb4MW97tfo4RKpUwqsiLhclWXKEHvhN9jL9/r0=; b=IomOp55ZO/XJ9KOV62K0bMCFcA2RORHUijYdl90MnUizSPiEm34GEBfCuRAjnZzUNQ 2tPuLBTe6Yelf6lTpNUMG0wQXRkgfRwMGk/cuqDqlJl+05YRPUpxsnwNJi85VhqQLXe4 n6Cp+j5MDirL3YvX3M4Wnt4ymExeJFjBlKvVB7wYN1H6uaO0FqQ/0G0wcTPiNyY+hFwt gsw5M3ciqseUnWL7MYBFIvU09zjuVT70n+JVf1nD0JmEQaEflWGvYehvjdhpmUJdDl2Z uUmkuYHnmXkDkDN1Lz5UfbPf5XFuHEP54zea78avfNtbp4X/uIJFQs442o29ALwDzHRs 0WZg== X-Gm-Message-State: ALoCoQlbTUNdl4BjnHM9OEDYseNKqpWG+LJcu9zlEg4McJY4u1r7yTvZNhQPHLGy3xfzibIkrTYN X-Received: by 10.31.140.143 with SMTP id o137mr12923050vkd.56.1446813718319; Fri, 06 Nov 2015 04:41:58 -0800 (PST) Received: from [216.169.129.164] (164.129.169.216.client.dyn.strong-sf90.as22781.net. [216.169.129.164]) by smtp.gmail.com with ESMTPSA id l67sm8277127vke.19.2015.11.06.04.41.55 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 06 Nov 2015 04:41:57 -0800 (PST) From: "Roland Dobbins" To: tsvwg@ietf.org Date: Fri, 06 Nov 2015 21:41:42 +0900 Message-ID: In-Reply-To: <63365570489be7b350f41ad796ee1e3b.squirrel@erg.abdn.ac.uk> References: <5638D31B.4080801@mti-systems.com> <10B4A768-25EC-4AFF-99D0-1BEC1C24CF2A@arbor.net> <563AF27B.8010009@nttv6.jp> <787AE7BB302AE849A7480A190F8B933008C98037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <828773FE19B05B4581311493A046E85E3F619C04D9@HE111642.emea1.cds.t-internal.com> <3F352E09-6415-4409-AE95-68FFD5020C04@arbor.net> <828773FE19B05B4581311493A046E85E3F619C06A7@HE111642.emea1.cds.t-internal.com> <8867EE91-82F0-4F4D-B6B2-1BB70B616347@arbor.net> <563B66D7.8020505@mykolab.com> <63365570489be7b350f41ad796ee1e3b.squirrel@erg.abdn.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5164) Archived-At: Cc: dots@ietf.org Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 06 Nov 2015 12:42:00 -0000 On 6 Nov 2015, at 21:34, gorry@erg.abdn.ac.uk wrote: > (1) If we can recommend setting a DSCP - which one? Isn't that situationally-specific between the networks in question? > (2) Is there a reason that a sender would only set this if you know > you > are in one operator domain (how would you know this? (is it more > likely to > be discarded??) Senders should know this. > so (3) why not set it anyway (even if it is bleached) at operator > boundaries? Because folks tend not to do things which are extra effort/require coordination, and DOTS nodes themselves oughtn't to be doing this, it should be handled by network infrastructure. ----------------------------------- Roland Dobbins From nobody Fri Nov 6 04:49: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 E672F1A0373; Fri, 6 Nov 2015 04:49:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 g62IGsODZ8Kf; Fri, 6 Nov 2015 04:49:43 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA0D81A036A; Fri, 6 Nov 2015 04:49:42 -0800 (PST) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 3D7833B42B9; Fri, 6 Nov 2015 13:49:41 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.41]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 1F846C8016; Fri, 6 Nov 2015 13:49:41 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM31.corporate.adroot.infra.ftgroup ([fe80::2cc9:4bac:7b7d:229d%19]) with mapi id 14.03.0248.002; Fri, 6 Nov 2015 13:49:40 +0100 From: To: Roland Dobbins , "tsvwg@ietf.org" Thread-Topic: [Dots] [tsvwg] Best transport selection during an attack? Thread-Index: AQHRGIi73a8WYWi2nUeUL8f+zCLSDp6O8NgQ Date: Fri, 6 Nov 2015 12:49:40 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008C98F30@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <5638D31B.4080801@mti-systems.com> <10B4A768-25EC-4AFF-99D0-1BEC1C24CF2A@arbor.net> <563AF27B.8010009@nttv6.jp> <787AE7BB302AE849A7480A190F8B933008C98037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <828773FE19B05B4581311493A046E85E3F619C04D9@HE111642.emea1.cds.t-internal.com> <3F352E09-6415-4409-AE95-68FFD5020C04@arbor.net> <828773FE19B05B4581311493A046E85E3F619C06A7@HE111642.emea1.cds.t-internal.com> <8867EE91-82F0-4F4D-B6B2-1BB70B616347@arbor.net> <563B66D7.8020505@mykolab.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.11.6.121515 Archived-At: Cc: "dots@ietf.org" Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 06 Nov 2015 12:49:45 -0000 Hi Roland, all, I agree.=20 DOTS should not ** assume ** nor ** preclude ** such designs. The exact details about the configuration of which class of service (or eve= n other means to protect DOTS signaling traffic under severe network conges= tion conditions) should be left to polices local to each domain.=20 Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Roland Dobbins > Envoy=E9=A0: vendredi 6 novembre 2015 12:46 > =C0=A0: tsvwg@ietf.org > Cc=A0: dots@ietf.org > Objet=A0: Re: [Dots] [tsvwg] Best transport selection during an attack? >=20 > On 6 Nov 2015, at 18:41, gorry@erg.abdn.ac.uk wrote: >=20 > > but I wonder if the important question is here: > > "would setting a non-default DSCP actually reduce the chance that a > > packet > > reaches the intended destination?" >=20 > QoS *may* be set up for DOTS traffic by operators who're providing > transit and who're also performing upstream DDoS mitigation services for > endpoint networks who buy transit from them. >=20 > But we can't count on that due to a) overlays and b) operators may not > set it up for various reasons. >=20 > It should certainly be recommended in terms of deployment guidances in > directly-connected scenarios, IMHO, but would be just that - a > recommendation. >=20 > ----------------------------------- > Roland Dobbins >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Fri Nov 6 06:23: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 191DB1A90E5 for ; Fri, 6 Nov 2015 06:23:16 -0800 (PST) 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=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 uIuDnzicnb7T for ; Fri, 6 Nov 2015 06:23:15 -0800 (PST) Received: from atl4mhob17.myregisteredsite.com (atl4mhob17.myregisteredsite.com [209.17.115.110]) by ietfa.amsl.com (Postfix) with ESMTP id 129691A90E2 for ; Fri, 6 Nov 2015 06:23:15 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.203]) by atl4mhob17.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id tA6ENDt6026983 for ; Fri, 6 Nov 2015 09:23:13 -0500 Received: (qmail 11521 invoked by uid 0); 6 Nov 2015 14:16:33 -0000 X-TCPREMOTEIP: 24.166.126.82 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.0.137?) (wes@mti-systems.com@24.166.126.82) by 0 with ESMTPA; 6 Nov 2015 14:16:32 -0000 To: Roland Dobbins , tsvwg@ietf.org References: <5638D31B.4080801@mti-systems.com> <10B4A768-25EC-4AFF-99D0-1BEC1C24CF2A@arbor.net> <563AF27B.8010009@nttv6.jp> <787AE7BB302AE849A7480A190F8B933008C98037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <828773FE19B05B4581311493A046E85E3F619C04D9@HE111642.emea1.cds.t-internal.com> <3F352E09-6415-4409-AE95-68FFD5020C04@arbor.net> <828773FE19B05B4581311493A046E85E3F619C06A7@HE111642.emea1.cds.t-internal.com> <8867EE91-82F0-4F4D-B6B2-1BB70B616347@arbor.net> <563B66D7.8020505@mykolab.com> <63365570489be7b350f41ad796ee1e3b.squirrel@erg.abdn.ac.uk> From: Wesley Eddy Message-ID: <563CB639.2010605@mti-systems.com> Date: Fri, 6 Nov 2015 09:16:25 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: dots@ietf.org Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 06 Nov 2015 14:23:16 -0000 On 11/6/2015 7:41 AM, Roland Dobbins wrote: > On 6 Nov 2015, at 21:34, gorry@erg.abdn.ac.uk wrote: > >> (1) If we can recommend setting a DSCP - which one? > > Isn't that situationally-specific between the networks in question? Definitely. There doesn't have to be any specific single default or recommended value because it's not necessary to match for interoperability between different implementations; it's just a deployment configuration matter. Receiving nodes don't need to know or care what DSCPs were used originally by the sender or by other classifiers in the path. >> so (3) why not set it anyway (even if it is bleached) at operator >> boundaries? > > Because folks tend not to do things which are extra effort/require > coordination, and DOTS nodes themselves oughtn't to be doing this, it > should be handled by network infrastructure. > It would be fine for an implementation to set some operator-indicated value when sending, and not require further classification in the network. From nobody Sat Nov 7 04:09: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 471B51B32BB for ; Sat, 7 Nov 2015 04:09:08 -0800 (PST) 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 ITI_296iZM9v for ; Sat, 7 Nov 2015 04:09:07 -0800 (PST) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::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 DDE091B32BA for ; Sat, 7 Nov 2015 04:09:06 -0800 (PST) Received: by pacdm15 with SMTP id dm15so125628583pac.3 for ; Sat, 07 Nov 2015 04:09:06 -0800 (PST) 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=8Jgs3M+0q+Yrd+Ecbl/JAZKoXYY3KsxIYB7inmf7SVg=; b=CLP1uXYunHh4btpPn3KICXICXTNZVgtzHrmi2xgtUo9tKD8hzvCPsvKB0CoLqbEMyJ yNeTPl9/bDnsm7Y1PEm1c/HLn3w0kBVQ32JEQtbDu8wVMdkiLj3t5+ePvu2lCKRlNuqw u71sPElv40EUPNj4S+fn0yRY1OOCyZIotHabU= 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=8Jgs3M+0q+Yrd+Ecbl/JAZKoXYY3KsxIYB7inmf7SVg=; b=bRlU5QCZZuTjCM1zEy5aqeyy7p6HikOg2gGPWCABjqXVswGoWpT/ZSVRWeMrUo4ikl pYc/0bMMo1IFz7NgdPM9w5mSa5AK8u/KPmNeh9WX7tbR3mAY9e+yvmOSISZkQmGsCAfj 8myJPOfYeDoaxNhSMAeLvT5gQJB9G1gd+tXuSJixKzZFOGkLR+CIMqnopWNkuqTxE2jh ySl/Wd5QtqeJG+Mp5eYkCFPXTgV2rC7Uuj3ajW/qDqeYCECY1Yj5TWAPUXqeYnEKpX4K d82d4nWhd7v5UIWPNIFPwuJRCgJj0c8jr1fzfsxGvCXdgKqyyRpj6cosGKUktdxuehCA +v4Q== X-Gm-Message-State: ALoCoQlPdZ8wvd/lQjN6jfj11S4qORMVXZ6cAMl/LqOMZkw0Sd4IiB2EMlUCK7IqZDa0UG065YeF X-Received: by 10.68.68.233 with SMTP id z9mr24899209pbt.132.1446898146463; Sat, 07 Nov 2015 04:09:06 -0800 (PST) Received: from [172.19.254.119] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id yk5sm5627363pac.5.2015.11.07.04.09.03 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 07 Nov 2015 04:09:05 -0800 (PST) From: "Roland Dobbins" To: tsvwg@ietf.org Date: Sat, 07 Nov 2015 19:08:55 +0700 Message-ID: <0DB5565F-E789-404C-ACEA-77E9E7587B20@arbor.net> In-Reply-To: <563CB639.2010605@mti-systems.com> References: <5638D31B.4080801@mti-systems.com> <10B4A768-25EC-4AFF-99D0-1BEC1C24CF2A@arbor.net> <563AF27B.8010009@nttv6.jp> <787AE7BB302AE849A7480A190F8B933008C98037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <828773FE19B05B4581311493A046E85E3F619C04D9@HE111642.emea1.cds.t-internal.com> <3F352E09-6415-4409-AE95-68FFD5020C04@arbor.net> <828773FE19B05B4581311493A046E85E3F619C06A7@HE111642.emea1.cds.t-internal.com> <8867EE91-82F0-4F4D-B6B2-1BB70B616347@arbor.net> <563B66D7.8020505@mykolab.com> <63365570489be7b350f41ad796ee1e3b.squirrel@erg.abdn.ac.uk> <563CB639.2010605@mti-systems.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5164) Archived-At: Cc: dots@ietf.org Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 07 Nov 2015 12:09:08 -0000 On 6 Nov 2015, at 21:16, Wesley Eddy wrote: > It would be fine for an implementation to set some operator-indicated > value when sending, and not require further classification in the > network. A capability to do marking in DOTS agents themselves, if so desired, you mean? So, an implementation of a configuration option? If so, I personally think that makes sense as something optional, but not necessarily something which ought to be mandatory. ----------------------------------- Roland Dobbins From nobody Sun Nov 8 23:31: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 EB0521B6C0B; Sun, 8 Nov 2015 23:31:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 tICNsn92ignm; Sun, 8 Nov 2015 23:31:40 -0800 (PST) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 367431B6C0C; Sun, 8 Nov 2015 23:31:39 -0800 (PST) Received: from q4de8psa169.blf.telekom.de ([10.151.13.200]) by tcmail91.telekom.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 09 Nov 2015 08:31:36 +0100 X-IronPort-AV: E=Sophos;i="5.20,265,1444687200"; d="scan'208";a="948384148" Received: from he113676.emea1.cds.t-internal.com ([10.134.99.29]) by q4de8psazkj.blf.telekom.de with ESMTP/TLS/AES128-SHA; 09 Nov 2015 08:31:36 +0100 Received: from HE111642.emea1.cds.t-internal.com ([10.134.93.11]) by HE113676.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 9 Nov 2015 08:31:36 +0100 From: To: Date: Mon, 9 Nov 2015 08:31:34 +0100 Thread-Topic: [tsvwg] [Dots] Best transport selection during an attack? Thread-Index: AdEZVSNpLijP+FAJRYCNxEZE5/3AzABaSl6w Message-ID: <828773FE19B05B4581311493A046E85E3F61A6984B@HE111642.emea1.cds.t-internal.com> References: <5638D31B.4080801@mti-systems.com> <10B4A768-25EC-4AFF-99D0-1BEC1C24CF2A@arbor.net> <563AF27B.8010009@nttv6.jp> <787AE7BB302AE849A7480A190F8B933008C98037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <828773FE19B05B4581311493A046E85E3F619C04D9@HE111642.emea1.cds.t-internal.com> <3F352E09-6415-4409-AE95-68FFD5020C04@arbor.net> <828773FE19B05B4581311493A046E85E3F619C06A7@HE111642.emea1.cds.t-internal.com> <8867EE91-82F0-4F4D-B6B2-1BB70B616347@arbor.net> <563B66D7.8020505@mykolab.com> <63365570489be7b350f41ad796ee1e3b.squirrel@erg.abdn.ac.uk> <563CB639.2010605@mti-systems.com> <0DB5565F-E789-404C-ACEA-77E9E7587B20@arbor.net> In-Reply-To: <0DB5565F-E789-404C-ACEA-77E9E7587B20@arbor.net> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: dots@ietf.org, tsvwg@ietf.org Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 09 Nov 2015 07:31:43 -0000 Roland, the communication server to client benefits most from QoS, if the client is= DDoSed, doesn't it? I'd expect the ones operating such a service to be qua= lified enough to combine available options to reach a technical design serv= ing the clients as desired. I may be wrong, but I don't expect the server, = which I don't expect to be mass market device, to be connected to a consume= r access. Mentioning QoS as a reasonable option for server to client communication wi= th an optional brief description of the cases when it useful is fine, I thi= nk. Regards,=20 Ruediger -----Urspr=FCngliche Nachricht----- Von: tsvwg [mailto:tsvwg-bounces@ietf.org] Im Auftrag von Roland Dobbins Gesendet: Samstag, 7. November 2015 13:09 An: tsvwg@ietf.org Cc: dots@ietf.org Betreff: Re: [tsvwg] [Dots] Best transport selection during an attack? On 6 Nov 2015, at 21:16, Wesley Eddy wrote: > It would be fine for an implementation to set some operator-indicated=20 > value when sending, and not require further classification in the=20 > network. A capability to do marking in DOTS agents themselves, if so desired, you me= an? So, an implementation of a configuration option? If so, I personally think= that makes sense as something optional, but not necessarily something whic= h ought to be mandatory. ----------------------------------- Roland Dobbins From nobody Sun Nov 8 23:40: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 7667D1B6DB2 for ; Sun, 8 Nov 2015 23:40:28 -0800 (PST) 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 qwKGbC5387OD for ; Sun, 8 Nov 2015 23:40:27 -0800 (PST) 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 6EEB91B6DAE for ; Sun, 8 Nov 2015 23:40:27 -0800 (PST) Received: by pacdm15 with SMTP id dm15so166672609pac.3 for ; Sun, 08 Nov 2015 23:40:27 -0800 (PST) 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=E9lHNndGRqiKjJ/hVeu4mOnflwUyx+dHxcU86E2D3mo=; b=cyzxGgiWnv7lsACNQPliFQHKtlAV4OLAKB5RUr7BTywQeCMtWCRawDKjtPjM6rfypm 5M9xX91sXE8/T1nX41r4R5YCMbVZJ4qf2zGO62o5h9Mz0k1Dbxc9o71TBYjI3yJxNeJe Dnpnrs3BQAHcIkjbiMXNzDVhxuTMXzC+472Nc= 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=E9lHNndGRqiKjJ/hVeu4mOnflwUyx+dHxcU86E2D3mo=; b=l3m3wLLFAVxip2bgN9awfeRhIYAadNZ5pxp2w+igj41uLUQXb+uDo9bKMJompIMZHK tknm5srB9H7lIfVse6NSkeKMiLCvYvbTAz94AvMh8UTEaD6Va0djN0Fx0AjevVXEMW2x REbHta2CFcPoXO3zk938676jNmis3q7IvabsgiQD0fOm/Th9vgGNqzCgkAUTuSvYGIrz SsYToX5m9jJVdq9o6i3VwiSoVHPIue3s5pflrbmB6ofQVP2H/q9UwIfD0kmJkRYn5J4L 5GRxJmz+e5ReTBvttBuTrfOf5dh7r6EphtFgX2Upng+JTcBVDPOxqY6MGpXHny0tv72G xahw== X-Gm-Message-State: ALoCoQn5jf50du1ggrVoKoXcPin9Ipg+/Xt5sje7TCwlXPCH70bNALzc5v+Gzth6Nhk7beGpCj1K X-Received: by 10.66.227.170 with SMTP id sb10mr24681205pac.80.1447054827057; Sun, 08 Nov 2015 23:40:27 -0800 (PST) Received: from [172.19.254.119] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id ey2sm14435661pbd.77.2015.11.08.23.40.25 (version=TLS1 cipher=AES128-SHA bits=128/128); Sun, 08 Nov 2015 23:40:26 -0800 (PST) From: "Roland Dobbins" To: tsvwg@ietf.org Date: Mon, 09 Nov 2015 14:40:15 +0700 Message-ID: <6C27CDF1-78F3-47B4-BA40-05EE13C5117D@arbor.net> In-Reply-To: <828773FE19B05B4581311493A046E85E3F61A6984B@HE111642.emea1.cds.t-internal.com> References: <5638D31B.4080801@mti-systems.com> <10B4A768-25EC-4AFF-99D0-1BEC1C24CF2A@arbor.net> <563AF27B.8010009@nttv6.jp> <787AE7BB302AE849A7480A190F8B933008C98037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <828773FE19B05B4581311493A046E85E3F619C04D9@HE111642.emea1.cds.t-internal.com> <3F352E09-6415-4409-AE95-68FFD5020C04@arbor.net> <828773FE19B05B4581311493A046E85E3F619C06A7@HE111642.emea1.cds.t-internal.com> <8867EE91-82F0-4F4D-B6B2-1BB70B616347@arbor.net> <563B66D7.8020505@mykolab.com> <63365570489be7b350f41ad796ee1e3b.squirrel@erg.abdn.ac.uk> <563CB639.2010605@mti-systems.com> <0DB5565F-E789-404C-ACEA-77E9E7587B20@arbor.net> <828773FE19B05B4581311493A046E85E3F61A6984B@HE111642.emea1.cds.t-internal.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5164) Archived-At: Cc: dots@ietf.org Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 09 Nov 2015 07:40:28 -0000 On 9 Nov 2015, at 14:31, Ruediger.Geib@telekom.de wrote: > Mentioning QoS as a reasonable option for server to client > communication with an optional brief description of the cases when it > useful is fine, I think. Concur. ----------------------------------- Roland Dobbins From nobody Tue Nov 10 10:04: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 C6CA31B3C08; Tue, 10 Nov 2015 10:04:09 -0800 (PST) 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 9VjxOlHDFcts; Tue, 10 Nov 2015 10:04:07 -0800 (PST) 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 551671B3C00; Tue, 10 Nov 2015 10:04:06 -0800 (PST) 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 CAD95774; Tue, 10 Nov 2015 18:04:03 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 10 Nov 2015 18:04:02 +0000 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; Tue, 10 Nov 2015 10:03:55 -0800 From: Linda Dunbar To: kaname nishizuka , Roland Dobbins , "dots@ietf.org" Thread-Topic: [Dots] [tsvwg] Best transport selection during an attack? Thread-Index: AQHRF5B/1q3m+lPKFUO7e8NwxURye56VlJzg Date: Tue, 10 Nov 2015 18:03:55 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657D7FF46@dfweml701-chm> References: <5638D31B.4080801@mti-systems.com> <10B4A768-25EC-4AFF-99D0-1BEC1C24CF2A@arbor.net> <563AF27B.8010009@nttv6.jp> In-Reply-To: <563AF27B.8010009@nttv6.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.236] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.56423194.0031, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 551d709288df3134509f3a01a85153b7 Archived-At: Cc: "tsvwg@ietf.org" Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 10 Nov 2015 18:04:09 -0000 I have to agree with Kaname.=20 In addition, if a device/app is under attack severely, it may not even have= the spare CPU to request for the "Help".=20 Linda Dunbar -----Original Message----- From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of kaname nishizuka Sent: Thursday, November 05, 2015 12:09 AM To: Roland Dobbins; dots@ietf.org Cc: tsvwg@ietf.org Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? >the only mission-critical DOTS messages are mitigation service requests f= rom DOTS clients and mitigation service refusals from DOTS servers. I'm in favor of the pointing out of the latter point: mitigation service re= fusals from DOTS servers. In operator's point of view, returning of status is indispensable to know t= he mitigation is succeed or not. Without such information, it will take more time to decide the next action,= so it will harm the victim longer. IMHO, in this meaning, "SOS" is a little bit confusing because it seems lik= e the signaling is one directional. regards, kaname nishizuka On 2015/11/04 10:37, Roland Dobbins wrote: > On 4 Nov 2015, at 10:29, Aaron Falk wrote: > >> And, you might not be able to tell you have a problem getting UDP=20 >> through until you are under attack, when some operator may implement fil= tering that inhibits connectivity. > > Regular heartbeats between clients and servers, clients and relays, and r= elays and servers can serve the function of ensuring end-to-end connectivit= y on an ongoing basis. > > Failure to receive service request acknowledgements can serve this purpos= e under duress. > > It's expected that DOTS clients will update DOTS servers (either directly= or via DOTS relays) with either continued mitigation requests and/or situa= tional updates with regards to mitigation efficacy throughout mitigation se= rvice windows. Likewise, DOTS servers are expected to do the same with reg= ards to DOTS clients (again, either directly or via DOTS relays). > > Note that other than a DOTS server receiving a DOTS mitigation service re= quests, none of these message types are necessary in order to mitigation se= rvice to be initiated. They are important and useful, but not mission-crit= ical; the only mission-critical DOTS messages are mitigation service reques= ts from DOTS clients and mitigation service refusals from DOTS servers. > > ----------------------------------- > 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 Tue Nov 10 11:22: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 749F51B3D63; Tue, 10 Nov 2015 11:22:28 -0800 (PST) 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 ayAA8mWgehJy; Tue, 10 Nov 2015 11:22:26 -0800 (PST) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.198]) (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 BC79A1B3D66; Tue, 10 Nov 2015 11:22:25 -0800 (PST) Received: from [216.82.241.211] by server-6.bemta-8.messagelabs.com id CC/51-31411-0F342465; Tue, 10 Nov 2015 19:22:24 +0000 X-Env-Sender: Stefan.Fouant@corero.com X-Msg-Ref: server-7.tower-85.messagelabs.com!1447183344!6506961!1 X-Originating-IP: [71.184.227.49] X-StarScan-Received: X-StarScan-Version: 7.19.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8868 invoked from network); 10 Nov 2015 19:22:24 -0000 Received: from mercury.corero.com (HELO MERCURY.corero.com) (71.184.227.49) by server-7.tower-85.messagelabs.com with AES128-SHA encrypted SMTP; 10 Nov 2015 19:22:24 -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; Tue, 10 Nov 2015 14:22:24 -0500 From: Stefan Fouant To: Paul Ferguson , Roland Dobbins Thread-Topic: [Dots] [tsvwg] Best transport selection during an attack? Thread-Index: AQHRF9XeAzc3yJKnNUOyMH4NULSmKJ6VqpMA Date: Tue, 10 Nov 2015 19:22:23 +0000 Message-ID: References: <5638D31B.4080801@mti-systems.com> <10B4A768-25EC-4AFF-99D0-1BEC1C24CF2A@arbor.net> <563AF27B.8010009@nttv6.jp> <787AE7BB302AE849A7480A190F8B933008C98037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <828773FE19B05B4581311493A046E85E3F619C04D9@HE111642.emea1.cds.t-internal.com> <3F352E09-6415-4409-AE95-68FFD5020C04@arbor.net> <828773FE19B05B4581311493A046E85E3F619C06A7@HE111642.emea1.cds.t-internal.com> <8867EE91-82F0-4F4D-B6B2-1BB70B616347@arbor.net> <563B66D7.8020505@mykolab.com> In-Reply-To: <563B66D7.8020505@mykolab.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="iso-8859-1" Content-ID: <3A38226BBF31C94FBF90370B285BA673@corero.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tsvwg@ietf.org" , "dots@ietf.org" Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 10 Nov 2015 19:22:28 -0000 On 11/5/15, 11:25 PM, "Dots on behalf of Paul Ferguson" wrote: >>=20 >> Yes, that's correct (along with the administrative and >> internal-political challenges operators may face even when they're >> directly topologically adjacent to the requesting organization's >> network). > >Correct. And that is the big problem with QoS/diffserv packet marking: >Once a packet leaves your network and your administrative control, no >one has to honor your packet markings (QoS). All bets are off. We=B9ve been down this path before - discussed on the mailing list last month. We don=B9t need an end-to-end guarantee of service to make this work= . QOS can be used on the local link simply to ensure that the DOTS request gets a higher priority in the face of congestion or heavy back pressure. Once it=B9s past the congestion point, there is less likelihood of needing differentiated treatment. Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI, CISSP Senior Security Engineer Corero Network Security Mobile: +1.703.625.6243 From nobody Tue Nov 10 11:39: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 7B8631B3DBA for ; Tue, 10 Nov 2015 11:39:43 -0800 (PST) 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 JCl9IWXpWPZt for ; Tue, 10 Nov 2015 11:39:42 -0800 (PST) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.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 B9B391B3DBF for ; Tue, 10 Nov 2015 11:39:38 -0800 (PST) Received: from [216.82.251.34] by server-3.bemta-12.messagelabs.com id A8/CE-27945-AF742465; Tue, 10 Nov 2015 19:39:38 +0000 X-Env-Sender: Stefan.Fouant@corero.com X-Msg-Ref: server-7.tower-145.messagelabs.com!1447184377!845361!1 X-Originating-IP: [71.184.227.49] X-StarScan-Received: X-StarScan-Version: 7.19.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 74694 invoked from network); 10 Nov 2015 19:39:38 -0000 Received: from mercury.corero.com (HELO MERCURY.corero.com) (71.184.227.49) by server-7.tower-145.messagelabs.com with AES128-SHA encrypted SMTP; 10 Nov 2015 19:39:38 -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; Tue, 10 Nov 2015 14:39:37 -0500 From: Stefan Fouant To: Roland Dobbins , "dots@ietf.org" Thread-Topic: [Dots] [tsvwg] Best transport selection during an attack? Thread-Index: AQHRFonjyDiIo27+oUqFryc8Kd/CAZ6LSAqAgABSdwCAAAHTAIAABgWAgAAJGACACgaIAA== Date: Tue, 10 Nov 2015 19:39:36 +0000 Message-ID: References: <5638D31B.4080801@mti-systems.com> <0A836E5A-C801-4CF4-916C-41EA065D3D30@arbor.net> <563939F2.8010601@mti-systems.com> <3AFD973D-22CB-49BD-A384-A1C10A0167E9@arbor.net> <49d27818011843fcb79d6a2faca09b5f@XCH-RCD-017.cisco.com> <6709EB29-B856-45EC-A005-4AB4274C6B1D@arbor.net> <0c1ea5caef5542178d1c954bf8afa96b@XCH-RCD-017.cisco.com> <4FE28A47-A65E-4FE8-AA0B-FEA3712D061C@arbor.net> In-Reply-To: <4FE28A47-A65E-4FE8-AA0B-FEA3712D061C@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="iso-8859-1" Content-ID: <2095FFE59D5A294DA9E2E84E891F2C72@corero.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 10 Nov 2015 19:39:43 -0000 On 11/4/15, 2:33 PM, "Dots on behalf of Roland Dobbins" wrote: >On 4 Nov 2015, at 14:01, Tirumaleswar Reddy (tireddy) wrote: > >> Browsers already use "Happy Eyeball mechanism" >> https://tools.ietf.org/html/rfc6555 for selection between IPv6 and >> IPv4. > >Yes, I agree that Happy Eyeballs is something to consider for this. Dan >Wing is on this list, too. One thing to keep in mind here, I believe =B3Happy Eyeball=B2 mechanism onl= y works for stateful transports. Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI, CISSP Senior Security Engineer Corero Network Security Mobile: +1.703.625.6243 From nobody Tue Nov 10 11:41: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 803931B3DC1; Tue, 10 Nov 2015 11:41:48 -0800 (PST) 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 eDcFMk4yXtmv; Tue, 10 Nov 2015 11:41:47 -0800 (PST) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.10]) (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 74EED1B3DB5; Tue, 10 Nov 2015 11:41:47 -0800 (PST) Received: from [216.82.251.33] by server-10.bemta-12.messagelabs.com id 2E/D5-07348-B7842465; Tue, 10 Nov 2015 19:41:47 +0000 X-Env-Sender: Stefan.Fouant@corero.com X-Msg-Ref: server-15.tower-130.messagelabs.com!1447184506!4538031!1 X-Originating-IP: [71.184.227.49] X-StarScan-Received: X-StarScan-Version: 7.19.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 109427 invoked from network); 10 Nov 2015 19:41:46 -0000 Received: from mercury.corero.com (HELO MERCURY.corero.com) (71.184.227.49) by server-15.tower-130.messagelabs.com with AES128-SHA encrypted SMTP; 10 Nov 2015 19:41:46 -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; Tue, 10 Nov 2015 14:41:46 -0500 From: Stefan Fouant To: Linda Dunbar , kaname nishizuka , Roland Dobbins , "dots@ietf.org" Thread-Topic: [Dots] [tsvwg] Best transport selection during an attack? Thread-Index: AQHRF5B5wblB8ZxPyEalY5w5yWNva56V6QSA///HgwA= Date: Tue, 10 Nov 2015 19:41:45 +0000 Message-ID: References: <5638D31B.4080801@mti-systems.com> <10B4A768-25EC-4AFF-99D0-1BEC1C24CF2A@arbor.net> <563AF27B.8010009@nttv6.jp> <4A95BA014132FF49AE685FAB4B9F17F657D7FF46@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657D7FF46@dfweml701-chm> 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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tsvwg@ietf.org" Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 10 Nov 2015 19:41:48 -0000 On 11/10/15, 1:03 PM, "Dots on behalf of Linda Dunbar" wrote: > >I have to agree with Kaname. > >In addition, if a device/app is under attack severely, it may not even >have the spare CPU to request for the "Help". > >Linda Dunbar We spoke about this in Yokohama. One of the suggested use cases as outlined by Roland was the use of an OOB mechanism, such as a mobile app/supplicant that could request mitigation service if all else fails. One thing is for sure, we need multiple options. Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI, CISSP Senior Security Engineer Corero Network Security Mobile: +1.703.625.6243 From nobody Tue Nov 10 11:49:02 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 0F3A01B3DE5 for ; Tue, 10 Nov 2015 11:49:01 -0800 (PST) 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 bD1fRNvvoiN0 for ; Tue, 10 Nov 2015 11:48:59 -0800 (PST) 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 D5F4A1B3DE4 for ; Tue, 10 Nov 2015 11:48:59 -0800 (PST) Received: by pabfh17 with SMTP id fh17so6195254pab.0 for ; Tue, 10 Nov 2015 11:48:59 -0800 (PST) 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=q87GsXCbRQaDflcJfBxfN4sbASqj6EdvDCkYI+jJK8E=; b=mPPg6b5TidVCA7PDN2u8IjLw52bbO54XWY+yICOPtPZ3C30rLPeLNdX0LJ5mmVq3wt 8C7+Fvene4kQXN3Gj27DFaVv0p7o4TQS/RvYSju292vOWuNEdz4kcEKFkQRC7q6yCqN7 dqXi57KSu3UNY416L9kSCOz/gFsoKfOOiJLfI= 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=q87GsXCbRQaDflcJfBxfN4sbASqj6EdvDCkYI+jJK8E=; b=D2CNK7IulssEvE3HpD3T/pC/mmzCTvM8ngvLRGsGHANl9UuAfu/OtWfCPdrnQgO9l7 UKQUUOiEN7ObTDrqZ3V5kpk3rQ/X1TpS3Sm9xb+mDuDuzMJgNtNicfMCLnjICVRIBPMS 1Iz84sWUMZRlJn3KO4+/Am0MoPv3PHXbXitNSQ92JqG60ghs4eyWbza/e8QBd5rR/ALW CSiq29SNcRxxAV6LexkTYsCQuoEqaNd0zeP+X2KokXZ5CudZax9g3QwHPicBNpP8ADf9 Y8o88h02iX8C8EV8CN+EeaZGawhkywWGtTEzCEct0e9uIaaUlsA7nJZjI5iNa2eLLN8c m7Ag== X-Gm-Message-State: ALoCoQnh/8UlBb2Rdx45DktAy2IVneh70pk4cD/ZVa9ciZcWHaaPabCbuE+Bd5H+3KmN5hXEI75v X-Received: by 10.66.97.105 with SMTP id dz9mr8348680pab.101.1447184939326; Tue, 10 Nov 2015 11:48:59 -0800 (PST) Received: from [172.19.254.119] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id bz1sm5622978pab.20.2015.11.10.11.48.57 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 10 Nov 2015 11:48:58 -0800 (PST) From: "Roland Dobbins" To: "dots@ietf.org" Date: Wed, 11 Nov 2015 02:48:54 +0700 Message-ID: In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657D7FF46@dfweml701-chm> References: <5638D31B.4080801@mti-systems.com> <10B4A768-25EC-4AFF-99D0-1BEC1C24CF2A@arbor.net> <563AF27B.8010009@nttv6.jp> <4A95BA014132FF49AE685FAB4B9F17F657D7FF46@dfweml701-chm> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5164) Archived-At: Cc: "tsvwg@ietf.org" Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 10 Nov 2015 19:49:01 -0000 On 11 Nov 2015, at 1:03, Linda Dunbar wrote: > In addition, if a device/app is under attack severely, it may not even > have the spare CPU to request for the "Help". Several of the use cases posited so far involve devices/mechanisms which aren't themselves under attack, FYI. Also, note that with the ones which do involve devices which are in the path of an attack, they would be configured to request upstream mitigation assistance when traffic levels, types, and/or other conditions exceeded configured thresholds or boundaries. There are cases in which attacks instantly are at a level/degree of complexity which degrade the ability of a device to respond; architectural guidance for implementors in this regard can be useful, and heartbeat can also be potentially useful in this regard (though there are a lot of implications to the latter, and its use as 'dead man's switch' must be carefully considered, along with all potential applications, in a given deployment scenario). ----------------------------------- Roland Dobbins From nobody Tue Nov 10 11:55: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 744CD1B31E3; Tue, 10 Nov 2015 11:55:49 -0800 (PST) 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 jekCLDQOL60H; Tue, 10 Nov 2015 11:55:48 -0800 (PST) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.200]) (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 22CC51B31DF; Tue, 10 Nov 2015 11:55:48 -0800 (PST) Received: from [216.82.242.33] by server-8.bemta-8.messagelabs.com id 86/D3-03231-3CB42465; Tue, 10 Nov 2015 19:55:47 +0000 X-Env-Sender: Stefan.Fouant@corero.com X-Msg-Ref: server-5.tower-55.messagelabs.com!1447185346!3568725!1 X-Originating-IP: [71.184.227.49] X-StarScan-Received: X-StarScan-Version: 7.19.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19601 invoked from network); 10 Nov 2015 19:55:46 -0000 Received: from mercury.corero.com (HELO MERCURY.corero.com) (71.184.227.49) by server-5.tower-55.messagelabs.com with AES128-SHA encrypted SMTP; 10 Nov 2015 19:55:46 -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; Tue, 10 Nov 2015 14:55:46 -0500 From: Stefan Fouant To: Roland Dobbins , "dots@ietf.org" Thread-Topic: [Dots] [tsvwg] Best transport selection during an attack? Thread-Index: AQHRF5B5wblB8ZxPyEalY5w5yWNva56V6QSAgAAdVQD//64XAA== Date: Tue, 10 Nov 2015 19:55:46 +0000 Message-ID: References: <5638D31B.4080801@mti-systems.com> <10B4A768-25EC-4AFF-99D0-1BEC1C24CF2A@arbor.net> <563AF27B.8010009@nttv6.jp> <4A95BA014132FF49AE685FAB4B9F17F657D7FF46@dfweml701-chm> 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="iso-8859-1" Content-ID: <32E037902E1D6341BFD1E041611179C3@corero.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tsvwg@ietf.org" Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 10 Nov 2015 19:55:49 -0000 On 11/10/15, 2:48 PM, "Dots on behalf of Roland Dobbins" wrote: > >Also, note that with the ones which do involve devices which are in the >path of an attack, they would be configured to request upstream >mitigation assistance when traffic levels, types, and/or other >conditions exceeded configured thresholds or boundaries. 100% concur. Many attacks, especially those involving many sources take time to fully ramp (I.e. Zombies ramping up in response to botnet herder instruction set). In many of these cases, there is a brief amount of time before full link saturation affording an opportunity to send out a mitigation request. >There are cases in which attacks instantly are at a level/degree of >complexity which degrade the ability of a device to respond; >architectural guidance for implementors in this regard can be useful, >and heartbeat can also be potentially useful in this regard (though >there are a lot of implications to the latter, and its use as 'dead >man's switch' must be carefully considered, along with all potential >applications, in a given deployment scenario). Configurable options for a loss of heartbeat should be considered. Of course, that=B9s more of a vendor implementation and not necessarily something that needs to be spelled out in the drafts. By any =B3implied=B2 dead man's switch should not be mandatory. Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI, CISSP Senior Security Engineer Corero Network Security Mobile: +1.703.625.6243 From nobody Tue Nov 10 12:22: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 E28171B3EB9 for ; Tue, 10 Nov 2015 12:22:08 -0800 (PST) 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 K-E1hDHkSba3 for ; Tue, 10 Nov 2015 12:22:06 -0800 (PST) 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 287AC1B3EB6 for ; Tue, 10 Nov 2015 12:22:06 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CDX73905; Tue, 10 Nov 2015 20:22:03 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 10 Nov 2015 20:22:01 +0000 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; Tue, 10 Nov 2015 12:21:55 -0800 From: Linda Dunbar To: Roland Dobbins , "dots@ietf.org" Thread-Topic: which entity/node is responsible for requesting DDoS mitigation request (call for "SOS" help) (was RE: [Dots] [tsvwg] Best transport selection during an attack? Thread-Index: AQHRF5B/1q3m+lPKFUO7e8NwxURye56VlJzggACkCAD//3/+YA== Date: Tue, 10 Nov 2015 20:21:55 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657D800A3@dfweml701-chm> References: <5638D31B.4080801@mti-systems.com> <10B4A768-25EC-4AFF-99D0-1BEC1C24CF2A@arbor.net> <563AF27B.8010009@nttv6.jp> <4A95BA014132FF49AE685FAB4B9F17F657D7FF46@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.192.11.236] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.564251EB.00AE, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 8966a409cdf95d5b56c26afdba997241 Archived-At: Subject: [Dots] which entity/node is responsible for requesting DDoS mitigation request (call for "SOS" help) (was RE: [tsvwg] Best transport selection during an attack? 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, 10 Nov 2015 20:22:09 -0000 Roland,=20 More comments inserted below: -----Original Message----- From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Roland Dobbins Sent: Tuesday, November 10, 2015 1:49 PM To: dots@ietf.org Cc: tsvwg@ietf.org Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? On 11 Nov 2015, at 1:03, Linda Dunbar wrote: > In addition, if a device/app is under attack severely, it may not even=20 > have the spare CPU to request for the "Help". Several of the use cases posited so far involve devices/mechanisms which ar= en't themselves under attack, FYI. Also, note that with the ones which do involve devices which are in the pat= h of an attack, they would be configured to request upstream mitigation ass= istance when traffic levels, types, and/or other conditions exceeded config= ured thresholds or boundaries. [Linda] Do you think the configuration on devices to trigger upstream mitig= ation assistance is static? Or dynamic? Are there any events that can impac= t the thresholds to be configured on the devices to call for "DDOS mitigati= on help"? Are those devices more likely to be L4-L7 devices? or routers/swi= tches as well?=20 There are cases in which attacks instantly are at a level/degree of complex= ity which degrade the ability of a device to respond; architectural guidanc= e for implementors in this regard can be useful, and heartbeat can also be = potentially useful in this regard (though there are a lot of implications t= o the latter, and its use as 'dead man's switch' must be carefully consider= ed, along with all potential applications, in a given deployment scenario). [Linda] There could be many reasons for a device/app's "heartbeat" to stop = or slow. So it would be difficult to conclude if it is caused by DOS attack= .=20 Thanks,=20 Linda ----------------------------------- Roland Dobbins _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Tue Nov 10 12:29: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 F3C981B3EEB for ; Tue, 10 Nov 2015 12:29:24 -0800 (PST) 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 YKnJSgr0OQfQ for ; Tue, 10 Nov 2015 12:29:23 -0800 (PST) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.198]) (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 1FECD1B3EEA for ; Tue, 10 Nov 2015 12:29:23 -0800 (PST) Received: from [216.82.242.33] by server-6.bemta-8.messagelabs.com id 55/37-31411-2A352465; Tue, 10 Nov 2015 20:29:22 +0000 X-Env-Sender: Stefan.Fouant@corero.com X-Msg-Ref: server-13.tower-55.messagelabs.com!1447187361!3574658!1 X-Originating-IP: [71.184.227.49] X-StarScan-Received: X-StarScan-Version: 7.19.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 61299 invoked from network); 10 Nov 2015 20:29:22 -0000 Received: from mercury.corero.com (HELO MERCURY.corero.com) (71.184.227.49) by server-13.tower-55.messagelabs.com with AES128-SHA encrypted SMTP; 10 Nov 2015 20:29:21 -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; Tue, 10 Nov 2015 15:29:21 -0500 From: Stefan Fouant To: Linda Dunbar , Roland Dobbins , "dots@ietf.org" Thread-Topic: [Dots] which entity/node is responsible for requesting DDoS mitigation request (call for "SOS" help) (was RE: [tsvwg] Best transport selection during an attack? Thread-Index: AQHRG/V78hqASpYwpE+2tw1GlzODNJ6VtQiA Date: Tue, 10 Nov 2015 20:29:20 +0000 Message-ID: References: <5638D31B.4080801@mti-systems.com> <10B4A768-25EC-4AFF-99D0-1BEC1C24CF2A@arbor.net> <563AF27B.8010009@nttv6.jp> <4A95BA014132FF49AE685FAB4B9F17F657D7FF46@dfweml701-chm> <4A95BA014132FF49AE685FAB4B9F17F657D800A3@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657D800A3@dfweml701-chm> 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="iso-8859-1" Content-ID: <214B4DD96DB0FD4DA88BFA357BAE1960@corero.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] which entity/node is responsible for requesting DDoS mitigation request (call for "SOS" help) (was RE: [tsvwg] Best transport selection during an attack? 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, 10 Nov 2015 20:29:25 -0000 On 11/10/15, 3:21 PM, "Dots on behalf of Linda Dunbar" wrote: > >[Linda] Do you think the configuration on devices to trigger upstream >mitigation assistance is static? Or dynamic? Are there any events that >can impact the thresholds to be configured on the devices to call for >"DDOS mitigation help"? Are those devices more likely to be L4-L7 >devices? or routers/switches as well? IMO, more likely static thresholds, I.e. If link x observes 80% saturation, request mitigation. Obviously configurable though. > > >There are cases in which attacks instantly are at a level/degree of >complexity which degrade the ability of a device to respond; >architectural guidance for implementors in this regard can be useful, and >heartbeat can also be potentially useful in this regard (though there are >a lot of implications to the latter, and its use as 'dead man's switch' >must be carefully considered, along with all potential applications, in a >given deployment scenario). > >[Linda] There could be many reasons for a device/app's "heartbeat" to >stop or slow. So it would be difficult to conclude if it is caused by DOS >attack. I agree, I don=B9t think that the loss of heartbeat should necessarily equate to a mandate for mitigation service, but that can be left as a configurable option if needed which is largely a vendor implementation and need not be spelled out in the drafts. Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI, CISSP Senior Security Engineer Corero Network Security Mobile: +1.703.625.6243 From nobody Tue Nov 10 12:34: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 63B391B3F0E for ; Tue, 10 Nov 2015 12:34:07 -0800 (PST) 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 n98Jw1GhpTV5 for ; Tue, 10 Nov 2015 12:34:04 -0800 (PST) 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 563EB1B3F13 for ; Tue, 10 Nov 2015 12:34:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 0412D602A3 for ; Tue, 10 Nov 2015 15:34:02 -0500 (EST) 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 i53QFja7JEq3 for ; Tue, 10 Nov 2015 15:33:47 -0500 (EST) Received: from lx120e.htt-consult.com (unknown [216.1.225.162]) (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 D4EA860184 for ; Tue, 10 Nov 2015 15:33:46 -0500 (EST) To: dots@ietf.org References: <84166B32-E182-4E80-9827-C926A7A414DC@arbor.net> From: Robert Moskowitz Message-ID: <564254A5.4010908@htt-consult.com> Date: Tue, 10 Nov 2015 14:33:41 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <84166B32-E182-4E80-9827-C926A7A414DC@arbor.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dots] dots-threats-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, 10 Nov 2015 20:34:07 -0000 I have finally caught up with all the messages on this list since our session. In a set of messages I will try and share my own thoughts, though they cannot be tied too well to specific threads, as there is just too much traffic here to respond to... On 11/05/2015 04:41 AM, Roland Dobbins wrote: > > Do we need a separate dots-threats draft to lay out potential threats > to DOTS communications channels/nodes in detail, or will the security > sections of the relevant drafts suffice? I am VERY concerned about attacks against DOTS agents, particularly the servers. Adversaries will find them and attack them when it is most advantageous. So we need to be more specific on the attacks that can be waged on DOTS (we don't need to address all the attacks against a server or service, that is out of scope). What can an adversary do to UDP? Is there any specific UDP flooding attack that needs to be considered? Or is this a reason to use something other than UDP? What can an adversary do to DTLS? There are attacks against the DTLS handshake; how can these be mitigated? What about attacks using DTLS datagram flooding? Is this a reasonable possiblity? Or is there something better than DTLS that better deals with attacks? Should message authentication only be used, and not content confidentiality? Thus while a Server is under attack, it can still process messages from valid clients? Is there a DTLS auth-only cipher (e.g. CMAC). What about a low-processing cost auth-only 'cipher' based on a hash chain? There probably are real attacks against the DOTS clients based on choices made here. In the requirements document we can generalize dealing with these. Specific proposals will need to detail how they mitigate their own risks. From nobody Tue Nov 10 12:35: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 7B4261B3DC5 for ; Tue, 10 Nov 2015 12:35:42 -0800 (PST) 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 srdvpAgBx9O7 for ; Tue, 10 Nov 2015 12:35:40 -0800 (PST) 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 25E891B3EFF for ; Tue, 10 Nov 2015 12:35:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id D72BA602B4; Tue, 10 Nov 2015 15:35:31 -0500 (EST) 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 PNgqySzMrMhR; Tue, 10 Nov 2015 15:35:22 -0500 (EST) Received: from lx120e.htt-consult.com (unknown [216.1.225.162]) (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 DEEE65FA14; Tue, 10 Nov 2015 15:35:21 -0500 (EST) To: mohamed.boucadair@orange.com, "Mortensen, Andrew" References: <787AE7BB302AE849A7480A190F8B933008C98572@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Robert Moskowitz Message-ID: <56425508.70406@htt-consult.com> Date: Tue, 10 Nov 2015 14:35:20 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B933008C98572@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------090804050505080709090207" Archived-At: Cc: "dots@ietf.org" Subject: Re: [Dots] Comments about the requirements draft (RE: Best transport selection during an attack?) 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, 10 Nov 2015 20:35:42 -0000 This is a multi-part message in MIME format. --------------090804050505080709090207 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 11/05/2015 07:54 AM, mohamed.boucadair@orange.com wrote: > > Hi Andrew, > > You can retrieve my first review of the requirements draft from this > link > . > I’m also attaching the pdf file in case you have troubles to open the > doc file. > This list strips off attachments. Best to learn how to post to the github (I myself need more time working at that). > draft-ietf-dots-requirements-00-rev Med.doc > draft-ietf-dots-requirements-00-rev Med.pdf > > (These file(s) are available until 10/11/2015 14:50:16) > > Cheers, > > Med > > *De :*Mortensen, Andrew [mailto:amortensen@arbor.net] > *Envoyé :* jeudi 5 novembre 2015 09:14 > *À :* BOUCADAIR Mohamed IMT/OLN > *Cc :* kaname nishizuka; Roland Dobbins; dots@ietf.org; tsvwg@ietf.org > *Objet :* Re: [Dots] Best transport selection during an attack? > > Yes, this is captured in OP-005 of the requirements draft. I encourage > WG members to read it and send feedback. Thank you. > > andrew > > > > On Thursday, November 5, 2015, > wrote: > > Hi Kaname, > > I agree with your comment about the status. > > FYI, we had this requirement in -00 of > https://tools.ietf.org/html/draft-reddy-dots-transport-00#section-4: > > o Acknowledgement for the processing of a filtering request and the > enforcement of associated countermeasures. > > Cheers, > Med > > > -----Message d'origine----- > > De : Dots [mailto:dots-bounces@ietf.org ] De la part > de kaname nishizuka > > Envoyé : jeudi 5 novembre 2015 07:09 > > À : Roland Dobbins; dots@ietf.org > > Cc : tsvwg@ietf.org > > Objet : Re: [Dots] [tsvwg] Best transport selection during an attack? > > > > > > >the only mission-critical DOTS messages are mitigation service > requests > > from DOTS clients and mitigation service refusals from DOTS servers. > > > > I'm in favor of the pointing out of the latter point: mitigation service > > refusals from DOTS servers. > > In operator's point of view, returning of status is indispensable to > know > > the mitigation is succeed or not. > > Without such information, it will take more time to decide the next > > action, so it will harm the victim longer. > > > > IMHO, in this meaning, "SOS" is a little bit confusing because it seems > > like the signaling is one directional. > > > > regards, > > kaname nishizuka > > > > > > On 2015/11/04 10:37, Roland Dobbins wrote: > > > On 4 Nov 2015, at 10:29, Aaron Falk wrote: > > > > > >> And, you might not be able to tell you have a problem getting UDP > > through until you are under attack, > > >> when some operator may implement filtering that inhibits > connectivity. > > > > > > Regular heartbeats between clients and servers, clients and > relays, and > > relays and servers can serve the function of ensuring end-to-end > > connectivity on an ongoing basis. > > > > > > Failure to receive service request acknowledgements can serve this > > purpose under duress. > > > > > > It's expected that DOTS clients will update DOTS servers (either > > directly or via DOTS relays) with either continued mitigation requests > > and/or situational updates with regards to mitigation efficacy > throughout > > mitigation service windows. Likewise, DOTS servers are expected to > do the > > same with regards to DOTS clients (again, either directly or via DOTS > > relays). > > > > > > Note that other than a DOTS server receiving a DOTS mitigation service > > requests, none of these message types are necessary in order to > mitigation > > service to be initiated. They are important and useful, but not > mission- > > critical; the only mission-critical DOTS messages are mitigation service > > requests from DOTS clients and mitigation service refusals from DOTS > > servers. > > > > > > ----------------------------------- > > > 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 > > > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots --------------090804050505080709090207 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 11/05/2015 07:54 AM, mohamed.boucadair@orange.com wrote:

Hi Andrew,

 

You can retrieve my first review of the requirements draft from this link. I’m also attaching the pdf file in case you have troubles to open the doc file.


This list strips off attachments.  Best to learn how to post to the github (I myself need more time working at that).

 

draft-ietf-dots-requirements-00-rev Med.doc
draft-ietf-dots-requirements-00-rev Med.pdf

(These file(s) are available until 10/11/2015 14:50:16)

Cheers,

Med

 

De : Mortensen, Andrew [mailto:amortensen@arbor.net]
Envoyé : jeudi 5 novembre 2015 09:14
À : BOUCADAIR Mohamed IMT/OLN
Cc : kaname nishizuka; Roland Dobbins; dots@ietf.org; tsvwg@ietf.org
Objet : Re: [Dots] Best transport selection during an attack?

 

Yes, this is captured in OP-005 of the requirements draft. I encourage WG members to read it and send feedback. Thank you.

 

andrew



On Thursday, November 5, 2015, <mohamed.boucadair@orange.com> wrote:

Hi Kaname,

I agree with your comment about the status.

FYI, we had this requirement in -00 of https://tools.ietf.org/html/draft-reddy-dots-transport-00#section-4:

   o  Acknowledgement for the processing of a filtering request and the
      enforcement of associated countermeasures.

Cheers,
Med

> -----Message d'origine-----
> De : Dots [mailto:dots-bounces@ietf.org] De la part de kaname nishizuka
> Envoyé : jeudi 5 novembre 2015 07:09
> À : Roland Dobbins; dots@ietf.org
> Cc : tsvwg@ietf.org
> Objet : Re: [Dots] [tsvwg] Best transport selection during an attack?
>
>
>  >the only mission-critical DOTS messages are mitigation service requests
> from DOTS clients and mitigation service refusals from DOTS servers.
>
> I'm in favor of the pointing out of the latter point: mitigation service
> refusals from DOTS servers.
> In operator's point of view, returning of status is indispensable to know
> the mitigation is succeed or not.
> Without such information, it will take more time to decide the next
> action, so it will harm the victim longer.
>
> IMHO, in this meaning, "SOS" is a little bit confusing because it seems
> like the signaling is one directional.
>
> regards,
> kaname nishizuka
>
>
> On 2015/11/04 10:37, Roland Dobbins wrote:
> > On 4 Nov 2015, at 10:29, Aaron Falk wrote:
> >
> >> And, you might not be able to tell you have a problem getting UDP
> through until you are under attack,
> >> when some operator may implement filtering that inhibits connectivity.
> >
> > Regular heartbeats between clients and servers, clients and relays, and
> relays and servers can serve the function of ensuring end-to-end
> connectivity on an ongoing basis.
> >
> > Failure to receive service request acknowledgements can serve this
> purpose under duress.
> >
> > It's expected that DOTS clients will update DOTS servers (either
> directly or via DOTS relays) with either continued mitigation requests
> and/or situational updates with regards to mitigation efficacy throughout
> mitigation service windows.  Likewise, DOTS servers are expected to do the
> same with regards to DOTS clients (again, either directly or via DOTS
> relays).
> >
> > Note that other than a DOTS server receiving a DOTS mitigation service
> requests, none of these message types are necessary in order to mitigation
> service to be initiated.  They are important and useful, but not mission-
> critical; the only mission-critical DOTS messages are mitigation service
> requests from DOTS clients and mitigation service refusals from DOTS
> servers.
> >
> > -----------------------------------
> > Roland Dobbins <rdobbins@arbor.net>
> >
> > _______________________________________________
> > 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

--------------090804050505080709090207-- From nobody Tue Nov 10 12:41: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 02A6F1B3F67 for ; Tue, 10 Nov 2015 12:40:59 -0800 (PST) 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 zhjxBSUX2uz6 for ; Tue, 10 Nov 2015 12:40:57 -0800 (PST) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.8]) (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 CD26C1B3EF2 for ; Tue, 10 Nov 2015 12:40:57 -0800 (PST) Received: from [216.82.251.34] by server-8.bemta-12.messagelabs.com id A1/2A-31713-95652465; Tue, 10 Nov 2015 20:40:57 +0000 X-Env-Sender: Stefan.Fouant@corero.com X-Msg-Ref: server-5.tower-145.messagelabs.com!1447188056!854915!1 X-Originating-IP: [71.184.227.49] X-StarScan-Received: X-StarScan-Version: 7.19.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 36426 invoked from network); 10 Nov 2015 20:40:56 -0000 Received: from mercury.corero.com (HELO MERCURY.corero.com) (71.184.227.49) by server-5.tower-145.messagelabs.com with AES128-SHA encrypted SMTP; 10 Nov 2015 20:40:56 -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; Tue, 10 Nov 2015 15:40:56 -0500 From: Stefan Fouant To: Robert Moskowitz , "dots@ietf.org" Thread-Topic: [Dots] dots-threats-draft? Thread-Index: AQHRF7aQVUHM1fJR8ESpILa+J5VSDZ6WEpCA//+uMwA= Date: Tue, 10 Nov 2015 20:40:55 +0000 Message-ID: References: <84166B32-E182-4E80-9827-C926A7A414DC@arbor.net> <564254A5.4010908@htt-consult.com> In-Reply-To: <564254A5.4010908@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: <60F338C6BB6BE049A1A89150974F0313@corero.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] dots-threats-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, 10 Nov 2015 20:40:59 -0000 On 11/10/15, 3:33 PM, "Dots on behalf of Robert Moskowitz" wrote: >I have finally caught up with all the messages on this list since our >session. In a set of messages I will try and share my own thoughts, >though they cannot be tied too well to specific threads, as there is >just too much traffic here to respond to... > >On 11/05/2015 04:41 AM, Roland Dobbins wrote: >> >> Do we need a separate dots-threats draft to lay out potential threats >> to DOTS communications channels/nodes in detail, or will the security >> sections of the relevant drafts suffice? > >I am VERY concerned about attacks against DOTS agents, particularly the >servers. > >Adversaries will find them and attack them when it is most advantageous. > >So we need to be more specific on the attacks that can be waged on DOTS >(we don't need to address all the attacks against a server or service, >that is out of scope). I agree with your concerns and think we agreed in Yokohama to lay those out in the relevant security sections in each draft. While not a panacea, I think that including a reference to BCP 38 is paramount, and I would hope any operator deploying such a service would be employing the use of edge ACLs to ensure only valid customer IPs are allowed to transmit a DOTS message. Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI, CISSP Senior Security Engineer Corero Network Security Mobile: +1.703.625.6243 From nobody Tue Nov 10 12:56: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 B1CE51B3FF4 for ; Tue, 10 Nov 2015 12:56:33 -0800 (PST) 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 bD1-8jHYNVfq for ; Tue, 10 Nov 2015 12:56:28 -0800 (PST) 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 F08601B3FEF for ; Tue, 10 Nov 2015 12:56:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id A6252607FB; Tue, 10 Nov 2015 15:56:26 -0500 (EST) 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 LQUyGBvzXtMI; Tue, 10 Nov 2015 15:56:22 -0500 (EST) Received: from lx120e.htt-consult.com (unknown [216.1.225.162]) (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 9265C5FA14; Tue, 10 Nov 2015 15:56:21 -0500 (EST) To: Dave Dolson , "dots@ietf.org" References: From: Robert Moskowitz Message-ID: <564259F2.7070803@htt-consult.com> Date: Tue, 10 Nov 2015 14:56:18 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------050402030103030500030401" Archived-At: Subject: Re: [Dots] Does DOTS require sneaker-net support? 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, 10 Nov 2015 20:56:33 -0000 This is a multi-part message in MIME format. --------------050402030103030500030401 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Digging back for thread start messages and responding there... On 11/03/2015 08:31 PM, Dave Dolson wrote: > > With respect to the DOTS information that needs to be exchanged before > an attack—the configuration, resource manifest, etc., > > -Should sneaker-net (https://en.wikipedia.org/wiki/Sneakernet ) > transport be supported? I.e., a file on a USB stick taken between sites. > > -Similarly, but not equivalently, should it be human readable such > that it could be sent by fax? > > -Should it be QR-encodable so that it can be sent by JPEG (take a > picture and send it to me)? > > I’m asking because yesterday someone mentioned that occasionally > operators need to set things up after an attack has begun. > > Admittedly, I’m have a bit of fun with this :-) > > But seriously, having the configuration described as a document format > vs. as a protocol is worth considering. > If a DOTS message can fit into a single MTU, it can fit in a QR code. I can just see a firewall/router with a small screen showing a QR code. If it turns red, it means things have really gone down the tubes. So you take your phone with your DOTS client app, read in the QR code content and send it off to your DOTS server. YES! Attack mitigation on its way! :) There is a lot of room here for product differentiation. --------------050402030103030500030401 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Digging back for thread start messages and responding there...

On 11/03/2015 08:31 PM, Dave Dolson wrote:

With respect to the DOTS information that needs to be exchanged before an attack—the configuration, resource manifest, etc.,

-          Should sneaker-net (https://en.wikipedia.org/wiki/Sneakernet ) transport be supported? I.e., a file on a USB stick taken between sites.

-          Similarly, but not equivalently, should it be human readable such that it could be sent by fax?

-          Should it be QR-encodable so that it can be sent by JPEG (take a picture and send it to me)?

 

I’m asking because yesterday someone mentioned that occasionally operators need to set things up after an attack has begun.

 

Admittedly, I’m have a bit of fun with this :-)

 

But seriously, having the configuration described as a document format vs. as a protocol is worth considering.


If a DOTS message can fit into a single MTU, it can fit in a QR code.  I can just see a firewall/router with a small screen showing a QR code.  If it turns red, it means things have really gone down the tubes.  So you take your phone with your DOTS client app, read in the QR code content and send it off to your DOTS server.  YES!  Attack mitigation on its way!  :)

There is a lot of room here for product differentiation.


--------------050402030103030500030401-- From nobody Tue Nov 10 13:00: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 405DA1B4013 for ; Tue, 10 Nov 2015 13:00:11 -0800 (PST) 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 pAMw6Av3XVTe for ; Tue, 10 Nov 2015 13:00:08 -0800 (PST) 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 EFF451B4012 for ; Tue, 10 Nov 2015 13:00:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id A918D602A3; Tue, 10 Nov 2015 16:00:06 -0500 (EST) 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 vm+XWUKjInAZ; Tue, 10 Nov 2015 16:00:03 -0500 (EST) Received: from lx120e.htt-consult.com (unknown [216.1.225.162]) (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 C13455FA14; Tue, 10 Nov 2015 16:00:02 -0500 (EST) To: Dave Dolson , dots References: <20151103194312.594948115.52080.45702@sandvine.com> From: Robert Moskowitz Message-ID: <56425AD1.3020601@htt-consult.com> Date: Tue, 10 Nov 2015 15:00:01 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151103194312.594948115.52080.45702@sandvine.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Dots] Using Diameter transport for DOTS? 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, 10 Nov 2015 21:00:11 -0000 On 11/03/2015 01:43 PM, Dave Dolson wrote: > Could Diameter satisfy the transport protocol needs of DOTS? > It already has security, mutual authentication, both datagram (SCTP) and TCP transports‎, watchdog timers, redundancy, the concept of relays... I think this is using a 32lb hammer to pound in a 3p nail (very US-centric model). We do specific work here in the IETF instead of repurposing existing tech because you can be focused on solving your problem, not taking on their problem(s). From nobody Tue Nov 10 13:06: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 CEEE01A88D8 for ; Tue, 10 Nov 2015 13:06:26 -0800 (PST) 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 LdpKaDv5dRQw for ; Tue, 10 Nov 2015 13:06:25 -0800 (PST) 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 8397B1A8886 for ; Tue, 10 Nov 2015 13:06:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id D077360821; Tue, 10 Nov 2015 16:06:23 -0500 (EST) 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 Yd3rtVHEAU84; Tue, 10 Nov 2015 16:06:19 -0500 (EST) Received: from lx120e.htt-consult.com (unknown [216.1.225.162]) (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 0D407607FB; Tue, 10 Nov 2015 16:06:18 -0500 (EST) To: Stefan Fouant , "dots@ietf.org" References: <84166B32-E182-4E80-9827-C926A7A414DC@arbor.net> <564254A5.4010908@htt-consult.com> From: Robert Moskowitz Message-ID: <56425C49.7050103@htt-consult.com> Date: Tue, 10 Nov 2015 15:06:17 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dots] dots-threats-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, 10 Nov 2015 21:06:27 -0000 On 11/10/2015 02:40 PM, Stefan Fouant wrote: > On 11/10/15, 3:33 PM, "Dots on behalf of Robert Moskowitz" > wrote: > > >> I have finally caught up with all the messages on this list since our >> session. In a set of messages I will try and share my own thoughts, >> though they cannot be tied too well to specific threads, as there is >> just too much traffic here to respond to... >> >> On 11/05/2015 04:41 AM, Roland Dobbins wrote: >>> Do we need a separate dots-threats draft to lay out potential threats >>> to DOTS communications channels/nodes in detail, or will the security >>> sections of the relevant drafts suffice? >> I am VERY concerned about attacks against DOTS agents, particularly the >> servers. >> >> Adversaries will find them and attack them when it is most advantageous. >> >> So we need to be more specific on the attacks that can be waged on DOTS >> (we don't need to address all the attacks against a server or service, >> that is out of scope). > I agree with your concerns and think we agreed in Yokohama to lay those > out in the relevant security sections in each draft. While not a panacea, > I think that including a reference to BCP 38 is paramount, and I would > hope any operator deploying such a service would be employing the use of > edge ACLs to ensure only valid customer IPs are allowed to transmit a DOTS > message. I can see all sorts of ways this fails due to interdomain DOTS messaging requirements. But we will see as we get the proposals moving. From nobody Tue Nov 10 13:11: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 CC9FE1A8A82 for ; Tue, 10 Nov 2015 13:11:50 -0800 (PST) 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 5iFqM18ybunk for ; Tue, 10 Nov 2015 13:11:50 -0800 (PST) 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 0BA551A8A80 for ; Tue, 10 Nov 2015 13:11:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id AB478602A3 for ; Tue, 10 Nov 2015 16:11:47 -0500 (EST) 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 u0nOuUrmHiMT for ; Tue, 10 Nov 2015 16:11:44 -0500 (EST) Received: from lx120e.htt-consult.com (unknown [216.1.225.162]) (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 F36E05FA14 for ; Tue, 10 Nov 2015 16:11:43 -0500 (EST) To: "dots@ietf.org" From: Robert Moskowitz Message-ID: <56425D8E.8030203@htt-consult.com> Date: Tue, 10 Nov 2015 15:11:42 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Dots] DOTS and QOS 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, 10 Nov 2015 21:11:51 -0000 This is an opening for a business model of positioning DOTS relays within the provider network. All of this is orthogonal to DOTS. It is potentially smart implementations and deployments. DOTS must not assume QOS is present to ensure message flow on a congested path. I believe this is already in the req ID. But an interesting opportunity. From nobody Tue Nov 10 13:12: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 7F4AC1A8A83 for ; Tue, 10 Nov 2015 13:12:30 -0800 (PST) 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 ugIguWqy2Z7c for ; Tue, 10 Nov 2015 13:12:29 -0800 (PST) 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 778BD1A8A7D for ; Tue, 10 Nov 2015 13:12:29 -0800 (PST) Received: by pasz6 with SMTP id z6so8332088pas.2 for ; Tue, 10 Nov 2015 13:12:29 -0800 (PST) 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=bk5spbcbD2NhspwtIRRxeEUF2VZ6XpygPG8MapuyxKc=; b=koCuS0obtZwNFPa1woGbMbIgJfuLYhUodFt4FdVya9Pjzn+EFpwLaTUS4eOek4ygwk awPMjAIhWb9HHTKO5B7s9BlwUe5P3n8HJ7Lm57K9IbKg4ncADgfV318aGElg+CTYAKq5 iUD8PinR3EaFImflMQOv+aTbSk6+SgeOIuCOw= 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=bk5spbcbD2NhspwtIRRxeEUF2VZ6XpygPG8MapuyxKc=; b=aAVk14e36FtHWma7RYtd00lF0giFUKLLA4liOuXHFKVy+Ll0WoZTP2etPRWDR3w6e/ N8vJpDAIzTBLfiOd5ZzTIs9K0qLzr0PSKbEAm5x70aQmrnrXhf0ENkjtBrHkkRVFLmzm 97d51vm0TTc1uqzuxmoBDe8cfetTRakHdcdrvmT25QI0xs01rp++iJRw2LDhDmuqev3e +6e+gcDbEg1PmcQl5w7KEPmXwAEXrncwBUDu85+6mh4liDAFlkT60SKygrhpcNQ4md9m epDa5PzFYkt6JwSLkWbTN8qgLPzLL1yxgSw7Jdc/iGttb7ZfQ54muBPe37TAtKuFmlIE vK3w== X-Gm-Message-State: ALoCoQl7iwW2wKere0fwmVQgU3Amyap887BPTXisxl3/DQAxLClk2hJiZaa2ZL3zYo/PsvS/dFIB X-Received: by 10.66.163.131 with SMTP id yi3mr8965293pab.44.1447189948954; Tue, 10 Nov 2015 13:12:28 -0800 (PST) Received: from [172.19.254.119] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id ju7sm5806473pbc.83.2015.11.10.13.12.27 for (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 10 Nov 2015 13:12:28 -0800 (PST) From: "Roland Dobbins" To: "dots@ietf.org" Date: Wed, 11 Nov 2015 04:12:25 +0700 Message-ID: In-Reply-To: <56425C49.7050103@htt-consult.com> References: <84166B32-E182-4E80-9827-C926A7A414DC@arbor.net> <564254A5.4010908@htt-consult.com> <56425C49.7050103@htt-consult.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5164) Archived-At: Subject: Re: [Dots] dots-threats-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, 10 Nov 2015 21:12:30 -0000 On 11 Nov 2015, at 4:06, Robert Moskowitz wrote: > I can see all sorts of ways this fails due to interdomain DOTS > messaging requirements. DOTS peering relationships aren't ad-hoc - they do require minimal setup. Which means that iACLs can and should be updated accordingly. ----------------------------------- Roland Dobbins From nobody Tue Nov 10 13:14: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 B7BAC1A8AA1 for ; Tue, 10 Nov 2015 13:14:53 -0800 (PST) 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 3lFtCxGkGRal for ; Tue, 10 Nov 2015 13:14:52 -0800 (PST) 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 A91BD1A8A8D for ; Tue, 10 Nov 2015 13:14:52 -0800 (PST) Received: by pacdm15 with SMTP id dm15so8044348pac.3 for ; Tue, 10 Nov 2015 13:14:52 -0800 (PST) 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=57leARlMfPFwVraO4c/M/qxfMwYmYlf0aU7M19EfExA=; b=WXdefdIK0tAlmX9QmMamgnHTul8Zd/KSb9KXpELSG9aTuFSLndGxO2w2XmVT9otrRl 8OlS4X7TSmFa6flD7gUc3Gt0YdCeJO3D4bdoS+OIod5poonOFg9vLTCc+wtP2eYeXcxv 1jH6ALg38MAMnYhSMlyYNPU/Qh6wD7KiRGems= 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=57leARlMfPFwVraO4c/M/qxfMwYmYlf0aU7M19EfExA=; b=hVKdfccijWMM2s/jsoirFzRzjP8fSO2CELHEZmEA2ncziYehvfwWfHMwQ7Cgv1yfMr /sNrKax05UigPXMT4aINtfQHjeYwEPm2tJK528Kl+6y5+d6GLps3tUgs3QlVmz6zrsO4 M7gSbwKKJzBJ94ynfA7Pbfu1ZJ/7vesWTTkynRnjnViUl9L9kEutJN1sBXq4UpTrZAy8 TUhdSKciln3JgRYNLeTYlQ+CPiULn3h69O/Lb5/ySsodj9OxJ/bhPUpZPT7BpE4G/MIf TNnL3HXzZRY3y4QCumjGmQmpFKDzOtbsnL8aIn2rFtjscz8SExDltQ0NANhRnZyVBucB lazg== X-Gm-Message-State: ALoCoQlIqvn7/ISAw1q7Oytt1egP3KoWzn6j6VNiIFks8ywJfERaN/DiL6Ppsdku/qOx20zmqeic X-Received: by 10.68.103.194 with SMTP id fy2mr9106933pbb.39.1447190092213; Tue, 10 Nov 2015 13:14:52 -0800 (PST) Received: from [172.19.254.119] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id ph8sm5847700pbc.8.2015.11.10.13.14.50 for (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 10 Nov 2015 13:14:51 -0800 (PST) From: "Roland Dobbins" To: dots@ietf.org Date: Wed, 11 Nov 2015 04:14:49 +0700 Message-ID: <5861A537-5376-4046-9258-D5DEB9CA372B@arbor.net> In-Reply-To: <564254A5.4010908@htt-consult.com> References: <84166B32-E182-4E80-9827-C926A7A414DC@arbor.net> <564254A5.4010908@htt-consult.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5164) Archived-At: Subject: Re: [Dots] dots-threats-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, 10 Nov 2015 21:14:53 -0000 On 11 Nov 2015, at 3:33, Robert Moskowitz wrote: > I am VERY concerned about attacks against DOTS agents, particularly > the servers. Many of the same BCPs which apply to network infrastructure and to servers/services should be used to secure DOTS agents. We must be sure to capture all the relevant ones and provide implementation and deployment guidance. And then there are the application-layer-specific things we must take into account. ----------------------------------- Roland Dobbins From nobody Tue Nov 10 13:16: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 524E21A8AE4 for ; Tue, 10 Nov 2015 13:16:02 -0800 (PST) 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 vm2xBr4n8Z68 for ; Tue, 10 Nov 2015 13:16:01 -0800 (PST) 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 C4E1F1A8ADF for ; Tue, 10 Nov 2015 13:15:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 4AD95602A3; Tue, 10 Nov 2015 16:15:56 -0500 (EST) 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 g5MtFK3MsPW3; Tue, 10 Nov 2015 16:15:52 -0500 (EST) Received: from lx120e.htt-consult.com (unknown [216.1.225.162]) (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 E6C465FA14; Tue, 10 Nov 2015 16:15:51 -0500 (EST) To: Roland Dobbins , "dots@ietf.org" References: <84166B32-E182-4E80-9827-C926A7A414DC@arbor.net> <564254A5.4010908@htt-consult.com> <56425C49.7050103@htt-consult.com> From: Robert Moskowitz Message-ID: <56425E86.6020403@htt-consult.com> Date: Tue, 10 Nov 2015 15:15:50 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dots] dots-threats-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, 10 Nov 2015 21:16:02 -0000 On 11/10/2015 03:12 PM, Roland Dobbins wrote: > On 11 Nov 2015, at 4:06, Robert Moskowitz wrote: > >> I can see all sorts of ways this fails due to interdomain DOTS >> messaging requirements. > > DOTS peering relationships aren't ad-hoc - they do require minimal setup. > > Which means that iACLs can and should be updated accordingly. This leads to a DOTS operational best practices draft. How to deploy to limit risks to DOTS itself. From nobody Tue Nov 10 15:06: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 42F7E1B4268 for ; Tue, 10 Nov 2015 15:06:47 -0800 (PST) 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 EzmUUiQ6eT8M for ; Tue, 10 Nov 2015 15:06:43 -0800 (PST) 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 52A701B42FF for ; Tue, 10 Nov 2015 14:58:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 789D0602B4; Tue, 10 Nov 2015 17:58:57 -0500 (EST) 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 QfBsAeM6yo9a; Tue, 10 Nov 2015 17:58:54 -0500 (EST) Received: from lx120e.htt-consult.com (unknown [216.1.225.162]) (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 DF529602A3; Tue, 10 Nov 2015 17:58:52 -0500 (EST) To: Roland Dobbins , "dots@ietf.org" References: <84166B32-E182-4E80-9827-C926A7A414DC@arbor.net> <564254A5.4010908@htt-consult.com> <56425C49.7050103@htt-consult.com> From: Robert Moskowitz Message-ID: <564276AB.1050708@htt-consult.com> Date: Tue, 10 Nov 2015 16:58:51 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dots] dots-threats-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, 10 Nov 2015 23:06:47 -0000 On 11/10/2015 03:12 PM, Roland Dobbins wrote: > On 11 Nov 2015, at 4:06, Robert Moskowitz wrote: > >> I can see all sorts of ways this fails due to interdomain DOTS >> messaging requirements. > > DOTS peering relationships aren't ad-hoc - they do require minimal setup. > > Which means that iACLs can and should be updated accordingly. As I sit in the IEEE 802.15.12 LLC discussion... Since a customer can set up a mitigation contract with some DDoS mitigation provider well outside their IP service provider, DOTS datagrams can be traversing a provider network without any prior agreement with said provider. So perhaps you are talking about ACLs specific to a given DOTS agent. But I will have to see some of these things in practice to better align my thoughts with your view. From nobody Tue Nov 10 15:33: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 A11001B43C5 for ; Tue, 10 Nov 2015 15:33:24 -0800 (PST) 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 rSf8Pj-CWgt1 for ; Tue, 10 Nov 2015 15:33:23 -0800 (PST) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.196]) (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 CAB091B43C3 for ; Tue, 10 Nov 2015 15:33:22 -0800 (PST) Received: from [216.82.241.211] by server-4.bemta-8.messagelabs.com id 76/AE-24484-1CE72465; Tue, 10 Nov 2015 23:33:21 +0000 X-Env-Sender: Stefan.Fouant@corero.com X-Msg-Ref: server-8.tower-85.messagelabs.com!1447198398!6551301!1 X-Originating-IP: [71.184.227.49] X-StarScan-Received: X-StarScan-Version: 7.19.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27617 invoked from network); 10 Nov 2015 23:33:19 -0000 Received: from mercury.corero.com (HELO MERCURY.corero.com) (71.184.227.49) by server-8.tower-85.messagelabs.com with AES128-SHA encrypted SMTP; 10 Nov 2015 23:33:19 -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; Tue, 10 Nov 2015 18:33:18 -0500 From: Stefan Fouant To: Robert Moskowitz , Roland Dobbins , "dots@ietf.org" Thread-Topic: [Dots] dots-threats-draft? Thread-Index: AQHRF7aQVUHM1fJR8ESpILa+J5VSDZ6WEpCA//+uMwCAAFrpgIAAAbaAgAAdvYD//7XMAA== Date: Tue, 10 Nov 2015 23:33:18 +0000 Message-ID: References: <84166B32-E182-4E80-9827-C926A7A414DC@arbor.net> <564254A5.4010908@htt-consult.com> <56425C49.7050103@htt-consult.com> <564276AB.1050708@htt-consult.com> In-Reply-To: <564276AB.1050708@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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] dots-threats-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, 10 Nov 2015 23:33:24 -0000 On 11/10/15, 5:58 PM, "Dots on behalf of Robert Moskowitz" wrote: >On 11/10/2015 03:12 PM, Roland Dobbins wrote: >> On 11 Nov 2015, at 4:06, Robert Moskowitz wrote: >> >>> I can see all sorts of ways this fails due to interdomain DOTS >>> messaging requirements. >> >> DOTS peering relationships aren't ad-hoc - they do require minimal >>setup. >> >> Which means that iACLs can and should be updated accordingly. > >As I sit in the IEEE 802.15.12 LLC discussion... > >Since a customer can set up a mitigation contract with some DDoS >mitigation provider well outside their IP service provider, DOTS >datagrams can be traversing a provider network without any prior >agreement with said provider. > >So perhaps you are talking about ACLs specific to a given DOTS agent. Yes precisely. IMO, similar precautions that we take to protect a BGP speaker or a DNS server can be taken - that is utilizing edge ACLs to only allow inbound to your infrastructure that which you want to allow, effectively protecting your DOTS server infrastructure. Of course, this is only one aspect of what should be a multi-layered approach. BCP 38 to prevent to filter the cruft. Authentication schemes to prevent spoofed clients. Security through obscurity, etc., etc. Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI, CISSP Senior Security Engineer Corero Network Security Mobile: +1.703.625.6243 From nobody Tue Nov 10 15:41: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 DBF6A1B4424 for ; Tue, 10 Nov 2015 15:41:47 -0800 (PST) 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, HTML_MESSAGE=0.001, 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 4fwuldTIwZ3X for ; Tue, 10 Nov 2015 15:41:46 -0800 (PST) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.10]) (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 788201B4423 for ; Tue, 10 Nov 2015 15:41:46 -0800 (PST) Received: from [216.82.251.33] by server-10.bemta-12.messagelabs.com id A5/25-07348-AB082465; Tue, 10 Nov 2015 23:41:46 +0000 X-Env-Sender: Stefan.Fouant@corero.com X-Msg-Ref: server-5.tower-130.messagelabs.com!1447198905!4571696!1 X-Originating-IP: [71.184.227.49] X-StarScan-Received: X-StarScan-Version: 7.19.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31170 invoked from network); 10 Nov 2015 23:41:45 -0000 Received: from mercury.corero.com (HELO MERCURY.corero.com) (71.184.227.49) by server-5.tower-130.messagelabs.com with AES128-SHA encrypted SMTP; 10 Nov 2015 23:41:45 -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; Tue, 10 Nov 2015 18:41:44 -0500 From: Stefan Fouant To: Robert Moskowitz , Dave Dolson , "dots@ietf.org" Thread-Topic: [Dots] Does DOTS require sneaker-net support? Thread-Index: AdEWqAR5qW9Gcm/vQPCCGnZr5Yl/WAFfCMsA///aZAA= Date: Tue, 10 Nov 2015 23:41:43 +0000 Message-ID: References: <564259F2.7070803@htt-consult.com> In-Reply-To: <564259F2.7070803@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: multipart/alternative; boundary="_000_D267E9B23A166stefanfouantcorerocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Does DOTS require sneaker-net support? 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, 10 Nov 2015 23:41:48 -0000 --_000_D267E9B23A166stefanfouantcorerocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable From: Dots > on behalf = of Robert Moskowitz > Date: Wednesday, November 11, 2015 at 5:56 AM To: Dave Dolson >, "dots@= ietf.org" > Subject: Re: [Dots] Does DOTS require sneaker-net support? But seriously, having the configuration described as a document format vs. = as a protocol is worth considering. Perhaps providing the config in some form of XML or JSON format would fit t= he bill here. This would provide for all sorts of useful things like puttin= g it into a document, or even piping it into some SDN orchestrator to take = action. If a DOTS message can fit into a single MTU, it can fit in a QR code. I ca= n just see a firewall/router with a small screen showing a QR code. If it = turns red, it means things have really gone down the tubes. So you take yo= ur phone with your DOTS client app, read in the QR code content and send it= off to your DOTS server. YES! Attack mitigation on its way! :) There is a lot of room here for product differentiation. I actually really like that idea. But I think that=92s largely a vendor imp= lementation, right? Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI, CISSP Senior Security Engineer Corero Network Security Mobile: +1.703.625.6243 --_000_D267E9B23A166stefanfouantcorerocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <5199B16A9B93A84CB940DB1257ED11EF@corero.com> Content-Transfer-Encoding: quoted-printable
From: Dots <dots-bounces@ietf.org> on behalf of Robert Moskowitz <rgm-sec@htt-consult.com>
Date: Wednesday, November 11, 2015 = at 5:56 AM
To: Dave Dolson <ddolson@sandvine.com>, "dots@ietf.org" <dots@ietf.org>
Subject: Re: [Dots] Does DOTS requi= re sneaker-net support?

 

But seriously, having the configuration described as= a document format vs. as a protocol is worth considering.

Perhaps providing the config in some form of XML or JSON format would = fit the bill here. This would provide for all sorts of useful things like p= utting it into a document, or even piping it into some SDN orchestrator to = take action.


If a DOTS message can fit into a single MTU, it can fit in a QR code. = I can just see a firewall/router with a small screen showing a QR code.&nb= sp; If it turns red, it means things have really gone down the tubes. = So you take your phone with your DOTS client app, read in the QR code content and send it off to your DOTS server.  YES= !  Attack mitigation on its way!  :)

There is a lot of room here for product differentiation.

I actually really like that idea. But I think that=92s largely a vendo= r implementation, right?

Stefan Fouant

JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNC= I, CISSP

Senior Security En= gineer

Corero Network Security

Mobile: +1.703.625.6243<= /p>

--_000_D267E9B23A166stefanfouantcorerocom_-- From nobody Tue Nov 10 16:40: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 0B2E81B44C7 for ; Tue, 10 Nov 2015 16:40:21 -0800 (PST) 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 tSJ_rq3nAWtw for ; Tue, 10 Nov 2015 16:40:19 -0800 (PST) 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 76BCD1B44DE for ; Tue, 10 Nov 2015 16:40:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id DC084602A3; Tue, 10 Nov 2015 19:40:17 -0500 (EST) 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 xBC5HzN4NnKd; Tue, 10 Nov 2015 19:40:02 -0500 (EST) Received: from lx120e.htt-consult.com (unknown [216.1.225.162]) (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 7CE3660184; Tue, 10 Nov 2015 19:39:59 -0500 (EST) To: Stefan Fouant , Dave Dolson , "dots@ietf.org" References: <564259F2.7070803@htt-consult.com> From: Robert Moskowitz Message-ID: <56428E5B.3020900@htt-consult.com> Date: Tue, 10 Nov 2015 18:39:55 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------000305070806080409060106" Archived-At: Subject: Re: [Dots] Does DOTS require sneaker-net support? 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, 11 Nov 2015 00:40:21 -0000 This is a multi-part message in MIME format. --------------000305070806080409060106 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 11/10/2015 05:41 PM, Stefan Fouant wrote: > From: Dots > on > behalf of Robert Moskowitz > > Date: Wednesday, November 11, 2015 at 5:56 AM > To: Dave Dolson >, > "dots@ietf.org " > > Subject: Re: [Dots] Does DOTS require sneaker-net support? > > But seriously, having the configuration described as a document > format vs. as a protocol is worth considering. > > > Perhaps providing the config in some form of XML or JSON format would > fit the bill here. This would provide for all sorts of useful things > like putting it into a document, or even piping it into some SDN > orchestrator to take action. I was talking to Paul Lambert (old-time IETFer security guy) earlier today and he has been using both Protobuf and YAML for some of his projects. They both look a lot better than some general XML or JSON. Anyone here have experience with them? > > > If a DOTS message can fit into a single MTU, it can fit in a QR > code. I can just see a firewall/router with a small screen > showing a QR code. If it turns red, it means things have really > gone down the tubes. So you take your phone with your DOTS client > app, read in the QR code content and send it off to your DOTS > server. YES! Attack mitigation on its way! :) > > There is a lot of room here for product differentiation. > > > I actually really like that idea. But I think that’s largely a vendor > implementation, right? My point exactly. We do standards. Vendors work out ways to make their implementation more marketable than the other guy's. --------------000305070806080409060106 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 11/10/2015 05:41 PM, Stefan Fouant wrote:
From: Dots <dots-bounces@ietf.org> on behalf of Robert Moskowitz <rgm-sec@htt-consult.com>
Date: Wednesday, November 11, 2015 at 5:56 AM
To: Dave Dolson <ddolson@sandvine.com>, "dots@ietf.org" <dots@ietf.org>
Subject: Re: [Dots] Does DOTS require sneaker-net support?

 

But seriously, having the configuration described as a document format vs. as a protocol is worth considering.

Perhaps providing the config in some form of XML or JSON format would fit the bill here. This would provide for all sorts of useful things like putting it into a document, or even piping it into some SDN orchestrator to take action.

I was talking to Paul Lambert (old-time IETFer security guy) earlier today and he has been using both Protobuf and YAML for some of his projects.  They both look a lot better than some general XML or JSON.  Anyone here have experience with them?



If a DOTS message can fit into a single MTU, it can fit in a QR code.  I can just see a firewall/router with a small screen showing a QR code.  If it turns red, it means things have really gone down the tubes.  So you take your phone with your DOTS client app, read in the QR code content and send it off to your DOTS server.  YES!  Attack mitigation on its way!  :)

There is a lot of room here for product differentiation.

I actually really like that idea. But I think that’s largely a vendor implementation, right?

My point exactly.  We do standards.  Vendors work out ways to make their implementation more marketable than the other guy's.


--------------000305070806080409060106-- From nobody Wed Nov 11 07:15: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 5030C1AD49D for ; Wed, 11 Nov 2015 07:15:14 -0800 (PST) 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 P4yDb8wMHoVu for ; Wed, 11 Nov 2015 07:15:12 -0800 (PST) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::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 C096D1AD367 for ; Wed, 11 Nov 2015 07:15:12 -0800 (PST) Received: by ykdr82 with SMTP id r82so52807185ykd.3 for ; Wed, 11 Nov 2015 07:15:12 -0800 (PST) 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=EF1loz96sXND/hG460UX9Ts8+bWZnza8dP42YBZ1fCM=; b=ZOSyMWIuS+I41dbMZ/t8bX8+4erC/+YTDxcv1OdQS5B9a8wY23o/QqS369R32F9wGZ 2ORFA1RSFBVXFULTx8vR6JPIDi4tuE8XsUvjEsqo3rQeO0/PgxdBG2a9wQXLGKz8609L cj1HKF/dfjsWBg27ZZ7l40cgUBeeprcJGPcBGGT44FJjkCsm3n155cYD6lBeGTPcExez 8E2kSZC1UyVIkVmcVhwkka/s3TLLZhTCGQ/juJ/A40na0ryzhHFMocQvpEPXL9YLHnVX bt8wsrL1bYMlmCMYlRdBb4EMn/VAcw/FlagFF0V0m3xG58xtS5A9TPUnFW6bol7QusJ/ yJTA== MIME-Version: 1.0 X-Received: by 10.13.243.135 with SMTP id c129mr10863062ywf.113.1447254911979; Wed, 11 Nov 2015 07:15:11 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.129.99.9 with HTTP; Wed, 11 Nov 2015 07:15:11 -0800 (PST) In-Reply-To: <56425D8E.8030203@htt-consult.com> References: <56425D8E.8030203@htt-consult.com> Date: Wed, 11 Nov 2015 10:15:11 -0500 X-Google-Sender-Auth: yEQC30fb1-6Ozb4Y-pux1-kH6i4 Message-ID: From: Christopher Morrow To: Robert Moskowitz Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "dots@ietf.org" Subject: Re: [Dots] DOTS and QOS 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, 11 Nov 2015 15:15:14 -0000 On Tue, Nov 10, 2015 at 4:11 PM, Robert Moskowitz wrote: > This is an opening for a business model of positioning DOTS relays within > the provider network. the question about QOS during the meeting wasn't about packet qos, but about 'qos' inside the stream of data between client/server. Essentially, if you have message types like: (and these are TOTALLY MADE UP!!) 1) helo msg 2) dos-help msg 3) statistics reporting msg would you chose by convention or by standard to send dos-help before helo (for instance) during times of stress? I think the answer to that question assumes you know something about the attack going on, and are 'on-path' with the attack traffic... and you understand something about the network resources between the client and server. > All of this is orthogonal to DOTS. It is potentially smart implementations > and deployments. it's potentially important to DOTS, operationally, but from a standards perspective I bet it's simpler to leave that decision to the implementors and agree that 'any message order from the client is ok, within the specified timeout periods (which should ALSO be configurable!)' > DOTS must not assume QOS is present to ensure message flow on a congested > path. I believe this is already in the req ID. agreed. no one should assume that QOS (of PACKETS) is going to work outside their network boundary, unless they have contracted with their carriers to support marking of PACKETS. -chris From nobody Thu Nov 12 05:57:25 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 162AD1A9068 for ; Thu, 12 Nov 2015 05:57:24 -0800 (PST) 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 HOalbb-kBmbz for ; Thu, 12 Nov 2015 05:57:23 -0800 (PST) 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 E5D6B1A9067 for ; Thu, 12 Nov 2015 05:57:22 -0800 (PST) Received: by pacdm15 with SMTP id dm15so65640754pac.3 for ; Thu, 12 Nov 2015 05:57:22 -0800 (PST) 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=HYVHYXQVQOC4iScaCE6gUD2WGtFUOX2lss77UVNUBz4=; b=I8xGl3gGzHvi2o3gUfoSOv4V/Ze1udHZWuHXALKreB95fKy49cONm1NwUh0fFPnkJY LJUPd9ClXdWTuxomDY11WOQmezNPxTzehZnwPiCL8b19hINroZQmLRhfrSMMlj/XWVO3 tY3/T5ST9riv8Q0ZnKDGqU8JppyftmAAnQXyc= 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=HYVHYXQVQOC4iScaCE6gUD2WGtFUOX2lss77UVNUBz4=; b=BOsOZYj65X1QBI/ItIgdpFmIHEQf8/akqYIoGDPSeKPMJyef8m0LvlT6wmRWOrcAib GN4XhAeqgNMqvB/65YTqCarWzEkYtK2nJA/B8VLtvb28vMuElQ0aw2/YFBHR8rW5dnkW sGTnG9Z1FbUE24qYD+EZnKbjoafiILpG7EcjeieeyP5kz4CX0i3Of+Vn906WAp4NtVPe sGtOjefllx0IPs4aFDv6B5TFRt0nrBRzSMqn6l39QhF+yLXO6DQ9omvd9nlww/T55tpg nAtWarARYXiw43LMP29/4/WSDD268KbmSqHBtcdEN6rYcI48GNm8QdKakLlsNHG2Z0xo eKjA== X-Gm-Message-State: ALoCoQnv8n8yxVUse+po9XUbP/tyB/3rX6pOenmNuqQg+pqG6rIZsb3ocaZEHpSolRKF9iZCXzVn X-Received: by 10.66.124.165 with SMTP id mj5mr22879447pab.97.1447336642500; Thu, 12 Nov 2015 05:57:22 -0800 (PST) Received: from [172.19.254.119] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id i9sm14985258pbq.93.2015.11.12.05.57.21 for (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 12 Nov 2015 05:57:21 -0800 (PST) From: "Roland Dobbins" To: "dots@ietf.org" Date: Thu, 12 Nov 2015 20:57:19 +0700 Message-ID: In-Reply-To: References: <56425D8E.8030203@htt-consult.com> MIME-Version: 1.0 X-Mailer: MailMate (1.9.3r5164) Archived-At: Subject: Re: [Dots] DOTS and QOS 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, 12 Nov 2015 13:57:24 -0000 On 11 Nov 2015, at 22:15, Christopher Morrow wrote: > the question about QOS during the meeting wasn't about packet qos, but > about 'qos' inside the stream of data between client/server. Yes, it turns out to've been about DOTS message prioritization, *not* QoS. ----------------------------------- Roland Dobbins From nobody Thu Nov 12 05:58: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 620F41A9093 for ; Thu, 12 Nov 2015 05:58:53 -0800 (PST) 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 YUmPruy1adYj for ; Thu, 12 Nov 2015 05:58:51 -0800 (PST) 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 ED9851A9091 for ; Thu, 12 Nov 2015 05:58:50 -0800 (PST) Received: by pasz6 with SMTP id z6so68096579pas.2 for ; Thu, 12 Nov 2015 05:58:50 -0800 (PST) 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=JTFhSxDMz8iONJ2iqrnY5+X9OpZ35ZqGyTK8vzkYVmY=; b=XNRGHmJa9iJYCsJVpZT9vdsUNFD03cuAa0tYD8FUYjD7YcaXCXAlhvywyAT26qREuJ 72hf2zwGWmQUHCcFZElqCZvA4yWS7g/Iunqn2D17IU3WpVMAY8MSflCt6tQRDVNlgC7s OhUfv0zkhXf/mUYfSmHMNtSt52Nx57k32JfVQ= 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=JTFhSxDMz8iONJ2iqrnY5+X9OpZ35ZqGyTK8vzkYVmY=; b=MSvkLLdzBRtEGy+BJsYa9Hssa8KU61AcTtmgMKSGPhdWyjBC5faHxLEOwuV/scQSNE om3RB4S/GRpkNOT1qAzvrJG9vd2MfbBxK6ehrkb0Qv1PZX2VYHPSL0ABhCudqEKEr6Sq 5qxWAOsD/Q44JcISBFXUGbeniykKAxTL8EhuAME1V/II81217Y+LBZMWI4lqagmTc/xf i/JAdDhtH93Zi2ZWrjgBJU58+8TttoFNnLLi4P7DW1divUGds915pz6lk+RJgilTiu0h pvxib9PeJwhrb6X0C093ham/wWn/U3HOIFgBauWpWoM1NXNq7gzVZ5unENWw8dxUC6JA 0slg== X-Gm-Message-State: ALoCoQmsgs1dLOOSoZgJm7i0oYUbXl3kyFKTs4JFV7s6hTf2Pwxj5l18uCr9HIfDT5DWRcJkmYwb X-Received: by 10.66.219.163 with SMTP id pp3mr22983128pac.55.1447336730630; Thu, 12 Nov 2015 05:58:50 -0800 (PST) Received: from [172.19.254.119] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id ol9sm7531555pbb.30.2015.11.12.05.58.49 for (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 12 Nov 2015 05:58:50 -0800 (PST) From: "Roland Dobbins" To: dots Date: Thu, 12 Nov 2015 20:58:47 +0700 Message-ID: <25C8AE69-E5A3-4F29-A95B-56FAF79C0358@arbor.net> In-Reply-To: References: <564259F2.7070803@htt-consult.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.3r5164) Archived-At: Subject: Re: [Dots] Does DOTS require sneaker-net support? 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, 12 Nov 2015 13:58:53 -0000 On 11 Nov 2015, at 6:41, Stefan Fouant wrote: > I actually really like that idea. But I think that’s largely a > vendor implementation, right? It's a use-case we should cover, IMHO, as well as consider for implementation/operational guidance at the appropriate time. ----------------------------------- Roland Dobbins From nobody Thu Nov 12 06:06:23 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 6C5E51AC3B3 for ; Thu, 12 Nov 2015 06:06:21 -0800 (PST) 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 N6IYyBc0XEWb for ; Thu, 12 Nov 2015 06:06:20 -0800 (PST) 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 3CD221AC3AB for ; Thu, 12 Nov 2015 06:06:20 -0800 (PST) Received: by pacdm15 with SMTP id dm15so65846908pac.3 for ; Thu, 12 Nov 2015 06:06:20 -0800 (PST) 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=NfOYkPchTbm01sD7v3O9OptEitrUPoRg8M3VMB3kNkk=; b=fVnakolLc3FEe9Mq8SYetT6Ix82CE6pkM64iRWgGa4iP7wAspmJWykS0ltnCZW8sSD hCl4Y09Q5gJs6n4rBanYtevEivIM9NhD478flBqHMSsMR7DfEqo3g7VlC+3xndOWxoAf LR592nI7w7p6+m1HiHPH08k+vQgcFq9kq7KyM= 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=NfOYkPchTbm01sD7v3O9OptEitrUPoRg8M3VMB3kNkk=; b=Ru45T9+NtYACpauGkPOqiyZvjxgIdjhyxyzlfsG/8Y6mTpGtv3uP7grRPM1TVtVeRD /ngWjW/3gf9N4ZUFo4Amv9dwNAOhVc3uJwW5zduShExnvlEDzKZRDrQxTlaxp0leHDjx rqUEAtzQRqXXf1Z2VJPk+I5g/ISGFTpCL5A1P8f9ZJqkfIQjH55sTdY3ygavRKMjzdGh qjcB4KEafzrjFr8XwE2OukQZjMXpqYnacgjXEer9OsziBD2VrB1lrog6PoMIwgXY3+Zi +CKxISlPTQkcFSe8iNc3kHp7alO+ioIbdGk05jjVc3o5PAk8k3WK0+UnWdx4wnRTWJaB lFCA== X-Gm-Message-State: ALoCoQn15J/M/RIYCU5bEyNsGr9YrvhWps8V+F57FA/8zq0GTsCz0TrZ596aenQapHWa4ilF06re X-Received: by 10.68.95.2 with SMTP id dg2mr23490066pbb.13.1447337179705; Thu, 12 Nov 2015 06:06:19 -0800 (PST) Received: from [172.19.254.119] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id ix1sm15059695pbd.40.2015.11.12.06.06.16 for (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 12 Nov 2015 06:06:18 -0800 (PST) From: "Roland Dobbins" To: "dots@ietf.org" Date: Thu, 12 Nov 2015 21:06:15 +0700 Message-ID: In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657D800A3@dfweml701-chm> References: <5638D31B.4080801@mti-systems.com> <10B4A768-25EC-4AFF-99D0-1BEC1C24CF2A@arbor.net> <563AF27B.8010009@nttv6.jp> <4A95BA014132FF49AE685FAB4B9F17F657D7FF46@dfweml701-chm> <4A95BA014132FF49AE685FAB4B9F17F657D800A3@dfweml701-chm> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5164) Archived-At: Subject: Re: [Dots] which entity/node is responsible for requesting DDoS mitigation request (call for "SOS" help) (was RE: [tsvwg] Best transport selection during an attack? 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, 12 Nov 2015 14:06:21 -0000 On 11 Nov 2015, at 3:21, Linda Dunbar wrote: > [Linda] Do you think the configuration on devices to trigger upstream > mitigation assistance is static? Or dynamic? Yes to both. > Are there any events that can impact the thresholds to be configured > on the devices to call for "DDOS mitigation help"? Yes. > Are those devices more likely to be L4-L7 devices? or routers/switches > as well? Either/or. > [Linda] There could be many reasons for a device/app's "heartbeat" to > stop or slow. So it would be difficult to conclude if it is caused by > DOS attack. Hence, '. . . though there are a lot of implications to the latter, and its use as 'dead man's switch' must be carefully considered, along with all potential applications, in a given deployment scenario . . .'. ----------------------------------- Roland Dobbins From nobody Thu Nov 12 06:08: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 0413C1AC529 for ; Thu, 12 Nov 2015 06:08:46 -0800 (PST) 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 h2vzhabj0mBV for ; Thu, 12 Nov 2015 06:08:45 -0800 (PST) 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 DF7E41ACAD8 for ; Thu, 12 Nov 2015 06:08:44 -0800 (PST) Received: by pacdm15 with SMTP id dm15so65900564pac.3 for ; Thu, 12 Nov 2015 06:08:44 -0800 (PST) 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=GQtHo13H58t+kEyStkCkNIhGOo435LhhHHIyp/YfEac=; b=TVCdpCmG9CFBBkgO/zIkT3fhKp6TcC6FS18nNetFc4jnAe5LcwNbdj1NoIxxN0kjpN oJt3/zVUmNJTx0IZ6lDY2juqMdYxrUezei1g8O0m2Ya4AVTqLkgG/lxBIK4EbRjT3SjU 4Ey2/HkP04T/ofpyMzU6d9gjUY7ZHFYhB1pvI= 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=GQtHo13H58t+kEyStkCkNIhGOo435LhhHHIyp/YfEac=; b=Ze3s5jBIO1vso0ZWxILC0ujhRj993s8giMtYvBzsWEWqzLy+kcRdzI90danxzQOGJx QJqkkMCy8PsbYmqSL/4dTetAhEYb0i94FPQoL4tzY0COMmofOdSVEpaqZX8X6TJ5u/CM cDXNTEhU4b573kA4apAXE/CPOfQ6ddI6g+PlBaXeD6fd0qFXjFdKHcwwVhjrUESFpVLe 0Nx5QyJJkI9hilut4sYJTdQuKkbyappI4Lall4xryOId8p2rKyBy21lPr2cPzEdNxTrn DjneEKYFGPEAMVKaIshEgdtvafu8832bl9NICnxQx1/2lyVVYg3iQc7BLv3xjdRmEyHI RSdQ== X-Gm-Message-State: ALoCoQm0KH8Vd9pAHTC/bM31c4rWCwa+OcIjaOclfL5gl031eu+9eU+z8je0U4OxXAGy/U/QpCCg X-Received: by 10.68.95.129 with SMTP id dk1mr23711696pbb.23.1447337324525; Thu, 12 Nov 2015 06:08:44 -0800 (PST) Received: from [172.19.254.119] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id rx10sm15107561pab.21.2015.11.12.06.08.41 for (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 12 Nov 2015 06:08:43 -0800 (PST) From: "Roland Dobbins" To: "dots@ietf.org" Date: Thu, 12 Nov 2015 21:08:39 +0700 Message-ID: <3FB92292-2D90-498D-AA94-3E6D6BB53DB4@arbor.net> In-Reply-To: <56425E86.6020403@htt-consult.com> References: <84166B32-E182-4E80-9827-C926A7A414DC@arbor.net> <564254A5.4010908@htt-consult.com> <56425C49.7050103@htt-consult.com> <56425E86.6020403@htt-consult.com> MIME-Version: 1.0 X-Mailer: MailMate (1.9.3r5164) Archived-At: Subject: Re: [Dots] dots-threats-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: Thu, 12 Nov 2015 14:08:46 -0000 On 11 Nov 2015, at 4:15, Robert Moskowitz wrote: > This leads to a DOTS operational best practices draft. > How to deploy to limit risks to DOTS itself. Concur. ----------------------------------- Roland Dobbins From nobody Thu Nov 12 06:09: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 A93FB1ACCD8 for ; Thu, 12 Nov 2015 06:09:47 -0800 (PST) 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 Gu-AzaqwHsb3 for ; Thu, 12 Nov 2015 06:09:42 -0800 (PST) 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 D483F1AC529 for ; Thu, 12 Nov 2015 06:09:41 -0800 (PST) Received: by pacdm15 with SMTP id dm15so65921738pac.3 for ; Thu, 12 Nov 2015 06:09:41 -0800 (PST) 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=BHlZxpLlEDxQomIGsL27YkbediqJVkvg70e5wEf+Zjw=; b=h+lFMGK79Ww/V5Mr1uOj0ceIvlPseKCNeBH2kTBx8g0iBfzd4mEAKPl69FH4MUNL1a NeCilmtAyXYoS54id8iQh+Mnnkhe5TOZgl2UZlgyblb2VCVAvSgVKAtpdWWOAUzCfpsR oF9h5Ox7Vs1msKIDK3Vym0ptWjO23SrposoiQ= 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=BHlZxpLlEDxQomIGsL27YkbediqJVkvg70e5wEf+Zjw=; b=FnLHiBBT7wFroTVaWEN51n2d8n3LJb4SoRCWOpoYEWvDmbZq3GTAXv/KJLQoVLCsh1 5HwYBwoQbAXGzK4l3uFXl4dM4ryRIFduad/75xjNTkWOadrBqyw9SEFk1rLCFa4Q0xId BWHk+r4Ys37ByXExLDD0wTzaIOPn5abaXkQDajZanhQZRx3omWARbaQw4OP+vkjIxB/B OF8zxr7sxKuayXDc8Avg5F5FkhChjM1GddFrW9PtQL5ab96V9i9wb7w9FRsAio/zrzRH u/XEM1jPp8kqafQsP561lTWWljceH616kxqbSGJLqhVfn4Gbn3ziWvzuIxdYt5kbMTwM 8aHA== X-Gm-Message-State: ALoCoQmEurV+OJX0I0CkjABMibKODEMWirT7CNTpMmuRtOytTVfmRVCmKJ1nGRrYmHTsciyPIRZg X-Received: by 10.68.228.228 with SMTP id sl4mr23177729pbc.51.1447337381467; Thu, 12 Nov 2015 06:09:41 -0800 (PST) Received: from [172.19.254.119] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id c1sm3986833pap.36.2015.11.12.06.09.39 for (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 12 Nov 2015 06:09:40 -0800 (PST) From: "Roland Dobbins" To: "dots@ietf.org" Date: Thu, 12 Nov 2015 21:09:37 +0700 Message-ID: <22619452-07FB-47BA-8E92-5E564F6B4078@arbor.net> In-Reply-To: <564276AB.1050708@htt-consult.com> References: <84166B32-E182-4E80-9827-C926A7A414DC@arbor.net> <564254A5.4010908@htt-consult.com> <56425C49.7050103@htt-consult.com> <564276AB.1050708@htt-consult.com> MIME-Version: 1.0 X-Mailer: MailMate (1.9.3r5164) Archived-At: Subject: Re: [Dots] dots-threats-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: Thu, 12 Nov 2015 14:09:47 -0000 On 11 Nov 2015, at 5:58, Robert Moskowitz wrote: > So perhaps you are talking about ACLs specific to a given DOTS agent. Correct - hence iACLs. ----------------------------------- Roland Dobbins From nobody Thu Nov 12 08:19:43 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 5E5F01B2E66 for ; Thu, 12 Nov 2015 08:19:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 yQIjRhwH_Ek9 for ; Thu, 12 Nov 2015 08:19:39 -0800 (PST) Received: from Mail2.SpriteLink.NET (Mail2.SpriteLink.NET [195.182.5.83]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 349021B2A41 for ; Thu, 12 Nov 2015 08:19:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by Mail2.SpriteLink.NET (Postfix) with ESMTP id DBB85261848 for ; Thu, 12 Nov 2015 17:19:26 +0100 (CET) X-Virus-Scanned: amavisd-new at SpriteLink.NET Received: from Mail2.SpriteLink.NET ([195.182.5.83]) by localhost (Mail2.SpriteLink.NET [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-mc-MhI7Mg0 for ; Thu, 12 Nov 2015 17:19:23 +0100 (CET) Received: from Kristians-MacBook-Pro.local (c-1a95e253.041-205-73746f13.cust.bredbandsbolaget.se [83.226.149.26]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: kristian@spritelink.net) by Mail2.SpriteLink.NET (Postfix) with ESMTPSA id EFFAF261846 for ; Thu, 12 Nov 2015 17:19:23 +0100 (CET) To: dots@ietf.org References: <5638D31B.4080801@mti-systems.com> <0A836E5A-C801-4CF4-916C-41EA065D3D30@arbor.net> <563939F2.8010601@mti-systems.com> <3AFD973D-22CB-49BD-A384-A1C10A0167E9@arbor.net> <49d27818011843fcb79d6a2faca09b5f@XCH-RCD-017.cisco.com> <6709EB29-B856-45EC-A005-4AB4274C6B1D@arbor.net> <0c1ea5caef5542178d1c954bf8afa96b@XCH-RCD-017.cisco.com> <4FE28A47-A65E-4FE8-AA0B-FEA3712D061C@arbor.net> From: Kristian Larsson Message-ID: <5644BC0B.2010905@spritelink.net> Date: Thu, 12 Nov 2015 17:19:23 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.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] [tsvwg] Best transport selection during an attack? 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, 12 Nov 2015 16:19:41 -0000 On 10/11/15 20:39, Stefan Fouant wrote: > On 11/4/15, 2:33 PM, "Dots on behalf of Roland Dobbins" > wrote: > > >> On 4 Nov 2015, at 14:01, Tirumaleswar Reddy (tireddy) wrote: >> >>> Browsers already use "Happy Eyeball mechanism" >>> https://tools.ietf.org/html/rfc6555 for selection between IPv6 and >>> IPv4. >> >> Yes, I agree that Happy Eyeballs is something to consider for this. Dan >> Wing is on this list, too. > > One thing to keep in mind here, I believe ³Happy Eyeball² mechanism only > works for stateful transports. Why? While rfc6555 targets stateful transports there is nothing preventing doing the same for UDP, as long as there is some form of request/response semantics of the service running on top, which I believe we will have. I think "Happy DOTS" should do v4/v6 selection and UDP / TCP selection per default. If someone wants to statically configure UDPoIPv4 that is fine but I'd like to see a recommendation for the default being to automatically figure out the best combination. Kind regards, Kristian. From nobody Thu Nov 12 17:55: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 257F31B3E4A for ; Thu, 12 Nov 2015 17:55:07 -0800 (PST) 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 oMAq_sMp8OI1 for ; Thu, 12 Nov 2015 17:55:06 -0800 (PST) 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 E111A1B3E46 for ; Thu, 12 Nov 2015 17:55:05 -0800 (PST) Received: by pabfh17 with SMTP id fh17so83331195pab.0 for ; Thu, 12 Nov 2015 17:55:05 -0800 (PST) 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=sj0K+1F2IBIK4HLnEqzC5KSBRfxzAI+CmlcFXYc0/9Q=; b=f1GcgEse7m54EH5MCfyUbhRc3+Nmd7atJGBN3rTnxTwf8BYmPnEE2XwYlUsy4WQZw4 E2GCSB9Qqlr02KzCQRrgLfdWmdyO1jjvgm4J0P5EUQhwedQ5EE6jce+odE0g+4XsrVhQ Uef39LeqOshWBgPohFRz8q4Kp03MnVOYUW4Lo= 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=sj0K+1F2IBIK4HLnEqzC5KSBRfxzAI+CmlcFXYc0/9Q=; b=KAcoPrldamRxf1ss83g8ZdznV1YvIqtXm8Z1jXAy5AkRTm8SsBoPCt471A39oGi19a 3sXreYrPYyWiS4IAODjF5T5Cl7B4mx8d57AQyXg2qylxgUDM/3syDOf4VgUDy5To3Lzo rOFH+V5nZTFnvkvpJYvYx/GHRHYWZb61sTl1uXY+Wo3xXsr3YSkrnqGKP4f3Nl+m5vcV vb8Z2B/ySAmoG3iopc4X933RoN6lXskHYBH5Zef9ziwiwi9z/Kp8k4nwM1Q4F6nh0dAD B2ELhupW1vTI2MbnH0jdWWI3KZTYZ3MZ69hCOMacXeGnqziyzNZfwPRN1WzcCzsjVF2O I//w== X-Gm-Message-State: ALoCoQmdag8BdTnwIUQfOFj/wLl7eJeEPp+c1blh9TdS95wISNK5m6N/AvdC+6nyrAbVt9QBY6Qn X-Received: by 10.68.161.194 with SMTP id xu2mr28061294pbb.86.1447379705551; Thu, 12 Nov 2015 17:55:05 -0800 (PST) Received: from [172.19.254.119] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id hi4sm17062877pbc.7.2015.11.12.17.55.03 (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 12 Nov 2015 17:55:04 -0800 (PST) From: "Roland Dobbins" To: dots@ietf.org Date: Fri, 13 Nov 2015 08:55:01 +0700 Message-ID: <570C393A-3B90-40F0-A8BC-E5B96A11305F@arbor.net> In-Reply-To: <5644BC0B.2010905@spritelink.net> References: <5638D31B.4080801@mti-systems.com> <0A836E5A-C801-4CF4-916C-41EA065D3D30@arbor.net> <563939F2.8010601@mti-systems.com> <3AFD973D-22CB-49BD-A384-A1C10A0167E9@arbor.net> <49d27818011843fcb79d6a2faca09b5f@XCH-RCD-017.cisco.com> <6709EB29-B856-45EC-A005-4AB4274C6B1D@arbor.net> <0c1ea5caef5542178d1c954bf8afa96b@XCH-RCD-017.cisco.com> <4FE28A47-A65E-4FE8-AA0B-FEA3712D061C@arbor.net> <5644BC0B.2010905@spritelink.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5164) Archived-At: Cc: Tirumaleswar Reddy , Dan Wing Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 13 Nov 2015 01:55:07 -0000 On 12 Nov 2015, at 23:19, Kristian Larsson wrote: > While rfc6555 targets stateful transports there is nothing preventing > doing the same for UDP, as long as there is some form of > request/response semantics of the service running on top, which I > believe we will have. I *think* this is correct; Dan Wing and Tiru Reddy can certainly comment more. > I think "Happy DOTS" should do v4/v6 selection and UDP / TCP > selection per default. If someone wants to statically configure > UDPoIPv4 that is fine but I'd like to see a recommendation for the > default being to automatically figure out the best combination. This is potentially useful implementation guidance, IMHO. Very interested in hearing more from Dan, Tiru, and others as to their thoughts. ----------------------------------- Roland Dobbins From nobody Thu Nov 12 18:32: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 8E9EB1B3EED for ; Thu, 12 Nov 2015 18:32:53 -0800 (PST) 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 rBFmM2CHGjnK for ; Thu, 12 Nov 2015 18:32:52 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A84C1B3EEC for ; Thu, 12 Nov 2015 18:32:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1449; q=dns/txt; s=iport; t=1447381972; x=1448591572; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=B6oqMYaeCM2yhs1V3ye+rFqh6YfJaVCIkTB+Or8oPqc=; b=dON/4t5tlsSfQ6TXQkrk84j424UM0ibDo5F3Z8a/Wnyr2wFhE49LjmEu 2HBzmQbsFyXlit5MXysVSKkob+jh8/1ktMjkyhly4CeU8Yh4k/ZavL7J/ zWhpmAlkdzmzYSo9AB7JK3iLXGxJcn4IU0Zbe8USINgIn551vBBoYNmMh A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1AQCgSkVW/4QNJK1egztTbwa+NwENg?= =?us-ascii?q?WUdhXMCgT04FAEBAQEBAQGBCoQ0AQEBBDo/DAQCAQgOAwQBAQEeCQcyFAkIAgQ?= =?us-ascii?q?BDQUIiCYNw18BAQEBAQEBAQEBAQEBAQEBAQEBAQEUBIZUhH6JOQWHRI8EAYUci?= =?us-ascii?q?AOcSwEfAQFChARyhDaBBwEBAQ?= X-IronPort-AV: E=Sophos;i="5.20,285,1444694400"; d="scan'208";a="207275142" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Nov 2015 02:32:51 +0000 Received: from XCH-RCD-018.cisco.com (xch-rcd-018.cisco.com [173.37.102.28]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id tAD2WphK008503 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 13 Nov 2015 02:32:51 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-RCD-018.cisco.com (173.37.102.28) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 12 Nov 2015 20:32:50 -0600 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, 12 Nov 2015 20:32:50 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Roland Dobbins , "dots@ietf.org" Thread-Topic: [Dots] [tsvwg] Best transport selection during an attack? Thread-Index: AQHRFonkqXl3p0h6iU67WsajDuI4Lp6LWM2A///m3KCAAG1uAP//oP0ggABuIQCAClpcAIAC7LmAgACg1ID//6MWUA== Date: Fri, 13 Nov 2015 02:32:50 +0000 Message-ID: References: <5638D31B.4080801@mti-systems.com> <0A836E5A-C801-4CF4-916C-41EA065D3D30@arbor.net> <563939F2.8010601@mti-systems.com> <3AFD973D-22CB-49BD-A384-A1C10A0167E9@arbor.net> <49d27818011843fcb79d6a2faca09b5f@XCH-RCD-017.cisco.com> <6709EB29-B856-45EC-A005-4AB4274C6B1D@arbor.net> <0c1ea5caef5542178d1c954bf8afa96b@XCH-RCD-017.cisco.com> <4FE28A47-A65E-4FE8-AA0B-FEA3712D061C@arbor.net> <5644BC0B.2010905@spritelink.net> <570C393A-3B90-40F0-A8BC-E5B96A11305F@arbor.net> In-Reply-To: <570C393A-3B90-40F0-A8BC-E5B96A11305F@arbor.net> 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.74.211] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Dan Wing \(dwing\)" Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 13 Nov 2015 02:32:53 -0000 > -----Original Message----- > From: Roland Dobbins [mailto:rdobbins@arbor.net] > Sent: Friday, November 13, 2015 7:25 AM > To: dots@ietf.org > Cc: Dan Wing (dwing); Tirumaleswar Reddy (tireddy) > Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? >=20 >=20 > On 12 Nov 2015, at 23:19, Kristian Larsson wrote: >=20 > > While rfc6555 targets stateful transports there is nothing preventing > > doing the same for UDP, as long as there is some form of > > request/response semantics of the service running on top, which I > > believe we will have. >=20 > I *think* this is correct; Dan Wing and Tiru Reddy can certainly comment > more. >=20 > > I think "Happy DOTS" should do v4/v6 selection and UDP / TCP > > selection per default. If someone wants to statically configure > > UDPoIPv4 that is fine but I'd like to see a recommendation for the > > default being to automatically figure out the best combination. >=20 > This is potentially useful implementation guidance, IMHO. Very intereste= d in > hearing more from Dan, Tiru, and others as to their thoughts. The above suggestions look good. By default v6 will be given higher precede= nce than v4 and will have a head-start. However policy table https://tools.= ietf.org/html/rfc6724 on the DOTS client can be modified to change the pref= erence. -Tiru >=20 > ----------------------------------- > Roland Dobbins From nobody Thu Nov 12 18:49: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 083B11B3F03 for ; Thu, 12 Nov 2015 18:49:45 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7, 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 xqiJLmA0WYhj for ; Thu, 12 Nov 2015 18:49:43 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 4EEF71B3F01 for ; Thu, 12 Nov 2015 18:49:43 -0800 (PST) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by WTL-EXCHP-2.sandvine.com (192.168.194.177) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 12 Nov 2015 21:49:44 -0500 Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([fe80::6c6d:7108:c63c:9055%14]) with mapi id 14.03.0181.006; Thu, 12 Nov 2015 21:49:42 -0500 From: Dave Dolson To: "Tirumaleswar Reddy (tireddy)" , Roland Dobbins , "dots@ietf.org" Thread-Topic: [Dots] [tsvwg] Best transport selection during an attack? Thread-Index: AQHRFonj3tdrhLn4Tk+unqWUjmL2+56LSAqAgABSdwCAAAHTAIAABgWAgAAJGACAClpcAIAC7LmAgACg1YCAAAqQAP//sDDw Date: Fri, 13 Nov 2015 02:49:43 +0000 Message-ID: References: <5638D31B.4080801@mti-systems.com> <0A836E5A-C801-4CF4-916C-41EA065D3D30@arbor.net> <563939F2.8010601@mti-systems.com> <3AFD973D-22CB-49BD-A384-A1C10A0167E9@arbor.net> <49d27818011843fcb79d6a2faca09b5f@XCH-RCD-017.cisco.com> <6709EB29-B856-45EC-A005-4AB4274C6B1D@arbor.net> <0c1ea5caef5542178d1c954bf8afa96b@XCH-RCD-017.cisco.com> <4FE28A47-A65E-4FE8-AA0B-FEA3712D061C@arbor.net> <5644BC0B.2010905@spritelink.net> <570C393A-3B90-40F0-A8BC-E5B96A11305F@arbor.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [182.248.147.153] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Dan Wing \(dwing\)" Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 13 Nov 2015 02:49:45 -0000 Something else to consider: I think the DOTS group has said that DNS resolu= tion should not be attempted during an attack. So then it's a case of having a number of configured IP/port/protocol end-p= oints, regardless of IPv4 or IPv6. I'm saying it isn't quite the same as doing DNS lookup and then deciding wh= ich address (family) to use, as is the "happy eyeballs" case. -Dave -----Original Message----- From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Tirumaleswar Reddy (= tireddy) Sent: Friday, November 13, 2015 11:33 AM To: Roland Dobbins; dots@ietf.org Cc: Dan Wing (dwing) Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? > -----Original Message----- > From: Roland Dobbins [mailto:rdobbins@arbor.net] > Sent: Friday, November 13, 2015 7:25 AM > To: dots@ietf.org > Cc: Dan Wing (dwing); Tirumaleswar Reddy (tireddy) > Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? >=20 >=20 > On 12 Nov 2015, at 23:19, Kristian Larsson wrote: >=20 > > While rfc6555 targets stateful transports there is nothing preventing > > doing the same for UDP, as long as there is some form of > > request/response semantics of the service running on top, which I > > believe we will have. >=20 > I *think* this is correct; Dan Wing and Tiru Reddy can certainly comment > more. >=20 > > I think "Happy DOTS" should do v4/v6 selection and UDP / TCP > > selection per default. If someone wants to statically configure > > UDPoIPv4 that is fine but I'd like to see a recommendation for the > > default being to automatically figure out the best combination. >=20 > This is potentially useful implementation guidance, IMHO. Very intereste= d in > hearing more from Dan, Tiru, and others as to their thoughts. The above suggestions look good. By default v6 will be given higher precede= nce than v4 and will have a head-start. However policy table https://tools.= ietf.org/html/rfc6724 on the DOTS client can be modified to change the pref= erence. -Tiru >=20 > ----------------------------------- > Roland Dobbins _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Thu Nov 12 19:04: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 6BE421B3F1C for ; Thu, 12 Nov 2015 19:04:35 -0800 (PST) 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 yxKvjy7hEl4f for ; Thu, 12 Nov 2015 19:04:33 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 508A51A1AD0 for ; Thu, 12 Nov 2015 19:04:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2928; q=dns/txt; s=iport; t=1447383873; x=1448593473; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=kZ6B8xaBkEFDKrOOjtYWlVR/N58G5nVvr3U+zSKYCMs=; b=ISXQqqpSg3GZFwLYPSUpqpDRtUiN8uTjqgVap6mHOrt8DKs7qL4+cpC9 7MVj5PYrKvgSSlGsHcZS4xaQ3pGesU8fWfJA5opz3Caystraw8AHcSM/Y nj+7P83pB/yovAIhVhgrjhNbeFQrmpn0aSAI4Yt0SZ2CDprmYl5Esf//m w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D2AQB6UkVW/4cNJK1egztTbwa+NwENg?= =?us-ascii?q?WUXCoVvAoE9OBQBAQEBAQEBgQqENAEBAQQBAQE3NAsMBAIBCA4DBAEBAR4JByc?= =?us-ascii?q?LFAkIAgQBDQUIiCYNw10BAQEBAQEBAQEBAQEBAQEBAQEBAQEUBIZUhH6EQoR3B?= =?us-ascii?q?YdEjwQBhRyIA5xLAR8BAUKCER2BVnKENoEHAQEB?= X-IronPort-AV: E=Sophos;i="5.20,285,1444694400"; d="scan'208";a="44516459" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-8.cisco.com with ESMTP; 13 Nov 2015 03:04:32 +0000 Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id tAD34WUd015803 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 13 Nov 2015 03:04:32 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 12 Nov 2015 21:04:31 -0600 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, 12 Nov 2015 21:04:31 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Dave Dolson , Roland Dobbins , "dots@ietf.org" Thread-Topic: [Dots] [tsvwg] Best transport selection during an attack? Thread-Index: AQHRFonkqXl3p0h6iU67WsajDuI4Lp6LWM2A///m3KCAAG1uAP//oP0ggABuIQCAClpcAIAC7LmAgACg1ID//6MWUAANhmCAAAxNPcA= Date: Fri, 13 Nov 2015 03:04:31 +0000 Message-ID: <14898235a6da4c54be5f43c72ad16840@XCH-RCD-017.cisco.com> References: <5638D31B.4080801@mti-systems.com> <0A836E5A-C801-4CF4-916C-41EA065D3D30@arbor.net> <563939F2.8010601@mti-systems.com> <3AFD973D-22CB-49BD-A384-A1C10A0167E9@arbor.net> <49d27818011843fcb79d6a2faca09b5f@XCH-RCD-017.cisco.com> <6709EB29-B856-45EC-A005-4AB4274C6B1D@arbor.net> <0c1ea5caef5542178d1c954bf8afa96b@XCH-RCD-017.cisco.com> <4FE28A47-A65E-4FE8-AA0B-FEA3712D061C@arbor.net> <5644BC0B.2010905@spritelink.net> <570C393A-3B90-40F0-A8BC-E5B96A11305F@arbor.net> In-Reply-To: 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.74.211] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Dan Wing \(dwing\)" Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 13 Nov 2015 03:04:35 -0000 > -----Original Message----- > From: Dave Dolson [mailto:ddolson@sandvine.com] > Sent: Friday, November 13, 2015 8:20 AM > To: Tirumaleswar Reddy (tireddy); Roland Dobbins; dots@ietf.org > Cc: Dan Wing (dwing) > Subject: RE: [Dots] [tsvwg] Best transport selection during an attack? >=20 > Something else to consider: I think the DOTS group has said that DNS > resolution should not be attempted during an attack. > So then it's a case of having a number of configured IP/port/protocol end= - > points, regardless of IPv4 or IPv6. >=20 > I'm saying it isn't quite the same as doing DNS lookup and then deciding > which address (family) to use, as is the "happy eyeballs" case. DNS resolution can be done during DOTS client configuration (non-attack tim= e) or the DOTS client could be configured with the DOTS server IPv6 and IPv= 4 addresses. Happy eyeballs for DOTS is to try both address families and bo= th transports. -Tiru >=20 > -Dave >=20 >=20 > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Tirumaleswar > Reddy (tireddy) > Sent: Friday, November 13, 2015 11:33 AM > To: Roland Dobbins; dots@ietf.org > Cc: Dan Wing (dwing) > Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? >=20 > > -----Original Message----- > > From: Roland Dobbins [mailto:rdobbins@arbor.net] > > Sent: Friday, November 13, 2015 7:25 AM > > To: dots@ietf.org > > Cc: Dan Wing (dwing); Tirumaleswar Reddy (tireddy) > > Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? > > > > > > On 12 Nov 2015, at 23:19, Kristian Larsson wrote: > > > > > While rfc6555 targets stateful transports there is nothing > > > preventing doing the same for UDP, as long as there is some form of > > > request/response semantics of the service running on top, which I > > > believe we will have. > > > > I *think* this is correct; Dan Wing and Tiru Reddy can certainly > > comment more. > > > > > I think "Happy DOTS" should do v4/v6 selection and UDP / TCP > > > selection per default. If someone wants to statically configure > > > UDPoIPv4 that is fine but I'd like to see a recommendation for the > > > default being to automatically figure out the best combination. > > > > This is potentially useful implementation guidance, IMHO. Very > > interested in hearing more from Dan, Tiru, and others as to their thoug= hts. >=20 > The above suggestions look good. By default v6 will be given higher > precedence than v4 and will have a head-start. However policy table > https://tools.ietf.org/html/rfc6724 on the DOTS client can be modified to > change the preference. >=20 > -Tiru >=20 > > > > ----------------------------------- > > Roland Dobbins >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Fri Nov 13 09:23: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 2FAC61B2D37 for ; Fri, 13 Nov 2015 09:23:12 -0800 (PST) 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 zrWAOS0CakKm for ; Fri, 13 Nov 2015 09:23:10 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::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 5160C1B2D33 for ; Fri, 13 Nov 2015 09:23:10 -0800 (PST) Received: by igbxm8 with SMTP id xm8so18620776igb.1 for ; Fri, 13 Nov 2015 09:23:09 -0800 (PST) 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=UIg+C5bOxTgh51j1BYRHRryxG7fIe2AdlMu+NPsTbs8=; b=Y47XpzfxFv/DPLX+ZT+Ke0es3+lvrZFmEhguu6xohqbxg6qaP2ik11ykIp9Flf8ela L23vZbMnmllvZ6+XTdK27f0cTJueeB5sqrd4D72HX03byRLvnQGWP9xiVxy+n2q393jy 2k6lDWD5psXHyR7v3cokCA0t6L73SOTB7HFAY= 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=UIg+C5bOxTgh51j1BYRHRryxG7fIe2AdlMu+NPsTbs8=; b=Bb4yutJK8Sy79683zyUjICpHOdprpl9uYivx+JqOcz04SS4LNJ/CsHDceycEGwGTcA Jo1qr5rJBh0qoNanubYA7Sho//2BS9z+CbfvRDA5GxfjXJUjpImGKC+tdTN/yrF4uheE 3VMkVOe7XXD2ca+8oIn8PpcUROn8OTduMKm7erV8KDbAWrea1Ivm3Pf1QTQZcLJlfE3u CJhuyiqjN/DgQ7eR6TfFRCwqdX8V+MXHBCC9KtGdtpI2d89lH2VhSFfoih6PqA/GWIxj yqunrNYFwfkW+mciCo7belp1Nyd8tOJMwoaOWRU+JLuGRoEZRDOxz1YfSYcvfTHA/iqX rQMg== X-Gm-Message-State: ALoCoQlpG+6Lxpf3cyYVsMyd6Sm5SubX/m7TwFCIdwIoVcVKuLZ/eFcddRhrc8uwedAtkgyKrOPb X-Received: by 10.50.8.72 with SMTP id p8mr1344403iga.65.1447435389713; Fri, 13 Nov 2015 09:23:09 -0800 (PST) Received: from desktop-10-21.aa.arbor.net ([216.130.192.2]) by smtp.gmail.com with ESMTPSA id u12sm1646179igr.22.2015.11.13.09.23.08 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Nov 2015 09:23:08 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Andrew Mortensen In-Reply-To: <570C393A-3B90-40F0-A8BC-E5B96A11305F@arbor.net> Date: Fri, 13 Nov 2015 12:23:08 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1C41567B-4031-466E-B205-E296B764CEDB@arbor.net> References: <5638D31B.4080801@mti-systems.com> <0A836E5A-C801-4CF4-916C-41EA065D3D30@arbor.net> <563939F2.8010601@mti-systems.com> <3AFD973D-22CB-49BD-A384-A1C10A0167E9@arbor.net> <49d27818011843fcb79d6a2faca09b5f@XCH-RCD-017.cisco.com> <6709EB29-B856-45EC-A005-4AB4274C6B1D@arbor.net> <0c1ea5caef5542178d1c954bf8afa96b@XCH-RCD-017.cisco.com> <4FE28A47-A65E-4FE8-AA0B-FEA3712D061C@arbor.net> <5644BC0B.2010905@spritelink.net> <570C393A-3B90-40F0-A8BC-E5B96A11305F@arbor.net> To: Roland Dobbins X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: dots Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 13 Nov 2015 17:23:12 -0000 > On Nov 12, 2015, at 8:55 PM, Roland Dobbins = wrote: >=20 >=20 > On 12 Nov 2015, at 23:19, Kristian Larsson wrote: >=20 >> While rfc6555 targets stateful transports there is nothing preventing = doing the same for UDP, as long as there is some form of = request/response semantics of the service running on top, which I = believe we will have. >=20 > I *think* this is correct; Dan Wing and Tiru Reddy can certainly = comment more. >=20 >> I think "Happy DOTS" should do v4/v6 selection and UDP / TCP = selection per default. If someone wants to statically configure UDPoIPv4 = that is fine but I'd like to see a recommendation for the default being = to automatically figure out the best combination. >=20 > This is potentially useful implementation guidance, IMHO. Very = interested in hearing more from Dan, Tiru, and others as to their = thoughts. TCP/IPv4 might be detected or selected by the DOTS agent as the best = option under nominal conditions, but when an attack ramps up DOTS server = signals go missing with increasing frequency, with proportional = retransmissions and possible connection termination. That=E2=80=99s = exactly the sort of fragility we want to avoid in DOTS, and it makes me = skeptical of a conventional request/response model. I=E2=80=99m similarly skeptical that it=E2=80=99s possible to make = trustworthy estimations=E2=80=94at least the sort required by happy = eyeballs=E2=80=94about which transport/protocol combination is best if = DOTS agents are attempting to establish the signal channel *during* an = attack, though of course I=E2=80=99d be happy to learn my concerns are = off-base here and above.=20 Since I'm touching again on the transport dispute which set off this = entire thread, this seems like a good place to segue into the DOTS = discussion at the tsvwg meeting last week. (I haven=E2=80=99t seen any = writeup about it on this list, apologies if I missed it.) Nik gave a quick overview of the problem DOTS intends to solve, = described the dispute about signaling transport that emerged during the = DOTS meeting, and showed a very basic slide in which a DOTS client with = an existing relationship with a DOTS server must signal for help despite = an ingress link congested with DDoS traffic. Time for feedback during = the meeting was limited, so there were only a few comments (Cf. meeting = minutes linked below, DOTS is the very last item [1]): 1) Inform any planned UDP use with a good understanding of RFC 5405bis.=20= 2) TCP incurs state. So does UDP with a heartbeat. Unidirectional DTLS = is problematic [see also RFC 6520 =E2=80=94AM]. 3) Too many DOTS clients could DoS a DOTS server. NAT binding timeouts = could be a problem. 4) Redundant packets seems better than many idle encrypted sessions. 5) Consider using both UDP and TCP. (Some discussion has continued on the tsvwg mailing list=E2=80=94dots@ = got dropped from the replies=E2=80=94see [2] below.) None of that looks like consensus on transport, though the points raised = are valuable for requirements and protocol drafts. andrew [1] TSV WG minutes: = [2] = = From nobody Fri Nov 13 09:29:01 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 3FDB41B2D6F for ; Fri, 13 Nov 2015 09:28:59 -0800 (PST) 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 zrill5buhugr for ; Fri, 13 Nov 2015 09:28:55 -0800 (PST) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::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 43D211B2D78 for ; Fri, 13 Nov 2015 09:28:55 -0800 (PST) Received: by pacdm15 with SMTP id dm15so105739755pac.3 for ; Fri, 13 Nov 2015 09:28:55 -0800 (PST) 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=svrQYwOoRGxL4A+qAnbl9422PuXBVkGfV+p/gNl+qMg=; b=F5Byo7dzT61OGljgO4OaQgNYhOs9yVJwqvf+R5GzkNtVzTC+VB0X/bAX/lZEPKifct TGGRUaKaha7CSUsuHt2jfPTIOJR2oNFyk8Rtd5ar3goNtvlJDfcZWkr11Xmun/FyBxFE AZcG97IaUcuHKlRcRCRx7l32LZBxEh4AJEF+w= 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=svrQYwOoRGxL4A+qAnbl9422PuXBVkGfV+p/gNl+qMg=; b=WiKO4oqxht622e9DG37yc2U3acECEhcKeiwwTrUOWbm+r/X+J1c+3iUGc+gqMhKRlU FV00qV5Bm4GRGqbzLYbMgy+E5MZlf6O2tA5/8pZuxFEvL4MHfHfq/Osq4qnr9qQ0g0eb LUrP7oNka6qfXIGO/+OZCF/2b+McN5UdS6F37NXR/fdcFGeILV82T3jj0s04g7uHj4EA MDgCTRlygkO9NJxbUxUkZSwd+lOdkWJ3MH8zwS/3/XvJk4+pu2jCoWjGY5HYk1XTqBTm e16DveuRjV057v0wBzPUzkFP14ztSY6lAzAj4V84y3jBzU+AHQIcxANHpdTLvd7fG64o lq1w== X-Gm-Message-State: ALoCoQmmj7UvmGkoMV4hY+z/u3vvaj0TyUP7L1569U2N4D7gBBvyM6psiFNaJZsW9KDu5pmrlVHy X-Received: by 10.68.133.230 with SMTP id pf6mr34021757pbb.31.1447435734883; Fri, 13 Nov 2015 09:28:54 -0800 (PST) Received: from [172.19.254.119] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id ff2sm21576831pac.14.2015.11.13.09.28.53 for (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 13 Nov 2015 09:28:54 -0800 (PST) From: "Roland Dobbins" To: dots Date: Sat, 14 Nov 2015 00:28:51 +0700 Message-ID: <201A41AA-7AD9-4433-963E-21BE6927F0CB@arbor.net> In-Reply-To: <1C41567B-4031-466E-B205-E296B764CEDB@arbor.net> References: <5638D31B.4080801@mti-systems.com> <0A836E5A-C801-4CF4-916C-41EA065D3D30@arbor.net> <563939F2.8010601@mti-systems.com> <3AFD973D-22CB-49BD-A384-A1C10A0167E9@arbor.net> <49d27818011843fcb79d6a2faca09b5f@XCH-RCD-017.cisco.com> <6709EB29-B856-45EC-A005-4AB4274C6B1D@arbor.net> <0c1ea5caef5542178d1c954bf8afa96b@XCH-RCD-017.cisco.com> <4FE28A47-A65E-4FE8-AA0B-FEA3712D061C@arbor.net> <5644BC0B.2010905@spritelink.net> <570C393A-3B90-40F0-A8BC-E5B96A11305F@arbor.net> <1C41567B-4031-466E-B205-E296B764CEDB@arbor.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.3r5164) Archived-At: Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 13 Nov 2015 17:28:59 -0000 On 14 Nov 2015, at 0:23, Andrew Mortensen wrote: > That’s exactly the sort of fragility we want to avoid in DOTS, and > it makes me skeptical of a conventional request/response model. This is a very cogent point, IMHO. We want dynamism where it makes sense, but the majority of DOTS peering relationships will be 'nailed up' with a very specific admin focus. > > I’m similarly skeptical that it’s possible to make trustworthy > estimations—at least the sort required by happy eyeballs—about > which transport/protocol combination is best if DOTS agents are > attempting to establish the signal channel *during* an attack Perhaps fallback of this nature would make sense in the event of the primary selected channel didn't appear to be viable? ----------------------------------- Roland Dobbins From nobody Sun Nov 15 12:31: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 3F4EA1A92DC for ; Sun, 15 Nov 2015 12:31:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.386 X-Spam-Level: X-Spam-Status: No, score=-13.386 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001, 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 sFIDCnZ61dO3 for ; Sun, 15 Nov 2015 12:31:45 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21F6C1A92BD for ; Sun, 15 Nov 2015 12:31:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1184; q=dns/txt; s=iport; t=1447619505; x=1448829105; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=u+CIffGebox6n90vMZsJhZJDTWEQxabP7dK971/3CQQ=; b=Ifvs92m/7m2eE6emDj9n+JGIVyWPkqNWbB07VOWK14v2hNiVsNub+wE4 OungZ9OkvDdFSPGEZmjYwNLyywmcTXe4jPXtyw5tuFfBdMCjUZsRGBtiF BUc22lZjVNkeQEE8yNReWtGFO3fTlexDPPocDWhvRU8s/n6aG66k5+C1k E=; X-IronPort-AV: E=Sophos;i="5.20,298,1444694400"; d="scan'208";a="208793351" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Nov 2015 20:31:44 +0000 Received: from [10.24.99.237] ([10.24.99.237]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id tAFKVhJT027132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Nov 2015 20:31:44 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: =?utf-8?Q?=F0=9F=94=93Dan_Wing?= In-Reply-To: <570C393A-3B90-40F0-A8BC-E5B96A11305F@arbor.net> Date: Sun, 15 Nov 2015 12:31:43 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5638D31B.4080801@mti-systems.com> <0A836E5A-C801-4CF4-916C-41EA065D3D30@arbor.net> <563939F2.8010601@mti-systems.com> <3AFD973D-22CB-49BD-A384-A1C10A0167E9@arbor.net> <49d27818011843fcb79d6a2faca09b5f@XCH-RCD-017.cisco.com> <6709EB29-B856-45EC-A005-4AB4274C6B1D@arbor.net> <0c1ea5caef5542178d1c954bf8afa96b@XCH-RCD-017.cisco.com> <4FE28A47-A65E-4FE8-AA0B-FEA3712D061C@arbor.net> <5644BC0B.2010905@spritelink.net> <570C393A-3B90-40F0-A8BC-E5B96A11305F@arbor.net> To: Roland Dobbins X-Mailer: Apple Mail (2.2104) Archived-At: Cc: dots@ietf.org, Tirumaleswar Reddy Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 15 Nov 2015 20:31:47 -0000 On 12-Nov-2015 05:55 pm, Roland Dobbins wrote: >=20 > On 12 Nov 2015, at 23:19, Kristian Larsson wrote: >=20 >> While rfc6555 targets stateful transports there is nothing preventing = doing the same for UDP, as long as there is some form of = request/response semantics of the service running on top, which I = believe we will have. Yes, Happy Eyeballs (RFC6555) concepts can be applied to other = transports. For example Preethi and I described how to apply Happy = Eyeballs to SCTP, draft-wing-tsvwg-happy-eyeballs-sctp (expired). -d >=20 > I *think* this is correct; Dan Wing and Tiru Reddy can certainly = comment more. >=20 >> I think "Happy DOTS" should do v4/v6 selection and UDP / TCP = selection per default. If someone wants to statically configure UDPoIPv4 = that is fine but I'd like to see a recommendation for the default being = to automatically figure out the best combination. >=20 > This is potentially useful implementation guidance, IMHO. Very = interested in hearing more from Dan, Tiru, and others as to their = thoughts. >=20 > ----------------------------------- > Roland Dobbins From nobody Mon Nov 16 02:20: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 6CC9A1B2FEC for ; Mon, 16 Nov 2015 02:20:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.875 X-Spam-Level: X-Spam-Status: No, score=-1.875 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, RP_MATCHES_RCVD=-0.585, 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 17nTQ8pDhpqD for ; Mon, 16 Nov 2015 02:20:12 -0800 (PST) Received: from Mail2.SpriteLink.NET (Mail2.SpriteLink.NET [195.182.5.83]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 994CB1B2FEA for ; Mon, 16 Nov 2015 02:20:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by Mail2.SpriteLink.NET (Postfix) with ESMTP id B44CA261848 for ; Mon, 16 Nov 2015 11:20:10 +0100 (CET) X-Virus-Scanned: amavisd-new at SpriteLink.NET Received: from Mail2.SpriteLink.NET ([195.182.5.83]) by localhost (Mail2.SpriteLink.NET [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-3p9M1vzoVw for ; Mon, 16 Nov 2015 11:20:05 +0100 (CET) Received: from Kristians-MacBook-Pro.local (c-1a95e253.041-205-73746f13.cust.bredbandsbolaget.se [83.226.149.26]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: kristian@spritelink.net) by Mail2.SpriteLink.NET (Postfix) with ESMTPSA id 57266261846 for ; Mon, 16 Nov 2015 11:20:05 +0100 (CET) To: dots@ietf.org References: <5638D31B.4080801@mti-systems.com> <0A836E5A-C801-4CF4-916C-41EA065D3D30@arbor.net> <563939F2.8010601@mti-systems.com> <3AFD973D-22CB-49BD-A384-A1C10A0167E9@arbor.net> <49d27818011843fcb79d6a2faca09b5f@XCH-RCD-017.cisco.com> <6709EB29-B856-45EC-A005-4AB4274C6B1D@arbor.net> <0c1ea5caef5542178d1c954bf8afa96b@XCH-RCD-017.cisco.com> <4FE28A47-A65E-4FE8-AA0B-FEA3712D061C@arbor.net> <5644BC0B.2010905@spritelink.net> <570C393A-3B90-40F0-A8BC-E5B96A11305F@arbor.net> <14898235a6da4c54be5f43c72ad16840@XCH-RCD-017.cisco.com> From: Kristian Larsson Message-ID: <5649ADD5.3090308@spritelink.net> Date: Mon, 16 Nov 2015 11:20:05 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <14898235a6da4c54be5f43c72ad16840@XCH-RCD-017.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 16 Nov 2015 10:20:15 -0000 On 13/11/15 04:04, Tirumaleswar Reddy (tireddy) wrote: >> -----Original Message----- >> From: Dave Dolson [mailto:ddolson@sandvine.com] >> Sent: Friday, November 13, 2015 8:20 AM >> To: Tirumaleswar Reddy (tireddy); Roland Dobbins; dots@ietf.org >> Cc: Dan Wing (dwing) >> Subject: RE: [Dots] [tsvwg] Best transport selection during an attack? >> >> Something else to consider: I think the DOTS group has said that DNS >> resolution should not be attempted during an attack. >> So then it's a case of having a number of configured IP/port/protocol end- >> points, regardless of IPv4 or IPv6. >> >> I'm saying it isn't quite the same as doing DNS lookup and then deciding >> which address (family) to use, as is the "happy eyeballs" case. > > DNS resolution can be done during DOTS client configuration (non-attack time) or the DOTS client could be configured with the DOTS server IPv6 and IPv4 addresses. Happy eyeballs for DOTS is to try both address families and both transports. Exactly, I didn't spell this out but I meant that DOTS happy eyeballs is to be performed during setup and perhaps continuously at certain intervals but the decision on transport is cached so when an attack happens we already know which transport to use. kll >> >> -----Original Message----- >> From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Tirumaleswar >> Reddy (tireddy) >> Sent: Friday, November 13, 2015 11:33 AM >> To: Roland Dobbins; dots@ietf.org >> Cc: Dan Wing (dwing) >> Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? >> >>> -----Original Message----- >>> From: Roland Dobbins [mailto:rdobbins@arbor.net] >>> Sent: Friday, November 13, 2015 7:25 AM >>> To: dots@ietf.org >>> Cc: Dan Wing (dwing); Tirumaleswar Reddy (tireddy) >>> Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? >>> >>> >>> On 12 Nov 2015, at 23:19, Kristian Larsson wrote: >>> >>>> While rfc6555 targets stateful transports there is nothing >>>> preventing doing the same for UDP, as long as there is some form of >>>> request/response semantics of the service running on top, which I >>>> believe we will have. >>> >>> I *think* this is correct; Dan Wing and Tiru Reddy can certainly >>> comment more. >>> >>>> I think "Happy DOTS" should do v4/v6 selection and UDP / TCP >>>> selection per default. If someone wants to statically configure >>>> UDPoIPv4 that is fine but I'd like to see a recommendation for the >>>> default being to automatically figure out the best combination. >>> >>> This is potentially useful implementation guidance, IMHO. Very >>> interested in hearing more from Dan, Tiru, and others as to their thoughts. >> >> The above suggestions look good. By default v6 will be given higher >> precedence than v4 and will have a head-start. However policy table >> https://tools.ietf.org/html/rfc6724 on the DOTS client can be modified to >> change the preference. >> >> -Tiru >> >>> >>> ----------------------------------- >>> 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 Mon Nov 16 02:49: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 E4CFC1A0271 for ; Mon, 16 Nov 2015 02:49:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.875 X-Spam-Level: X-Spam-Status: No, score=-1.875 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, RP_MATCHES_RCVD=-0.585, 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 XOcr9AIfF1Yp for ; Mon, 16 Nov 2015 02:49:32 -0800 (PST) Received: from Mail2.SpriteLink.NET (Mail2.SpriteLink.NET [195.182.5.83]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D90D91A026F for ; Mon, 16 Nov 2015 02:49:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by Mail2.SpriteLink.NET (Postfix) with ESMTP id 30780261848 for ; Mon, 16 Nov 2015 11:49:28 +0100 (CET) X-Virus-Scanned: amavisd-new at SpriteLink.NET Received: from Mail2.SpriteLink.NET ([195.182.5.83]) by localhost (Mail2.SpriteLink.NET [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbr-Gy0DUwr1 for ; Mon, 16 Nov 2015 11:49:25 +0100 (CET) Received: from Kristians-MacBook-Pro.local (c-1a95e253.041-205-73746f13.cust.bredbandsbolaget.se [83.226.149.26]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: kristian@spritelink.net) by Mail2.SpriteLink.NET (Postfix) with ESMTPSA id 82BED261846 for ; Mon, 16 Nov 2015 11:49:25 +0100 (CET) To: dots@ietf.org References: <5638D31B.4080801@mti-systems.com> <0A836E5A-C801-4CF4-916C-41EA065D3D30@arbor.net> <563939F2.8010601@mti-systems.com> <3AFD973D-22CB-49BD-A384-A1C10A0167E9@arbor.net> <49d27818011843fcb79d6a2faca09b5f@XCH-RCD-017.cisco.com> <6709EB29-B856-45EC-A005-4AB4274C6B1D@arbor.net> <0c1ea5caef5542178d1c954bf8afa96b@XCH-RCD-017.cisco.com> <4FE28A47-A65E-4FE8-AA0B-FEA3712D061C@arbor.net> <5644BC0B.2010905@spritelink.net> <570C393A-3B90-40F0-A8BC-E5B96A11305F@arbor.net> <1C41567B-4031-466E-B205-E296B764CEDB@arbor.net> From: Kristian Larsson Message-ID: <5649B4B5.5090207@spritelink.net> Date: Mon, 16 Nov 2015 11:49:25 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <1C41567B-4031-466E-B205-E296B764CEDB@arbor.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 16 Nov 2015 10:49:35 -0000 On 13/11/15 18:23, Andrew Mortensen wrote: > > >> On Nov 12, 2015, at 8:55 PM, Roland Dobbins >> wrote: >> >> >> On 12 Nov 2015, at 23:19, Kristian Larsson wrote: >> >>> While rfc6555 targets stateful transports there is nothing >>> preventing doing the same for UDP, as long as there is some form >>> of request/response semantics of the service running on top, >>> which I believe we will have. >> >> I *think* this is correct; Dan Wing and Tiru Reddy can certainly >> comment more. >> >>> I think "Happy DOTS" should do v4/v6 selection and UDP / TCP >>> selection per default. If someone wants to statically configure >>> UDPoIPv4 that is fine but I'd like to see a recommendation for >>> the default being to automatically figure out the best >>> combination. >> >> This is potentially useful implementation guidance, IMHO. Very >> interested in hearing more from Dan, Tiru, and others as to their >> thoughts. > > TCP/IPv4 might be detected or selected by the DOTS agent as the best > option under nominal conditions, but when an attack ramps up DOTS > server signals go missing with increasing frequency, with > proportional retransmissions and possible connection termination. > That’s exactly the sort of fragility we want to avoid in DOTS, and it > makes me skeptical of a conventional request/response model. > > I’m similarly skeptical that it’s possible to make trustworthy > estimations—at least the sort required by happy eyeballs—about which > transport/protocol combination is best if DOTS agents are attempting > to establish the signal channel *during* an attack, though of course > I’d be happy to learn my concerns are off-base here and above. Agreed. Trying DOTS happy eyeballs during attack would most likely be a very bad idea. It needs to happen pre-attack, both during initial setup but I think it's wise to do it at certain intervals as to refresh the information. > Since I'm touching again on the transport dispute which set off this > entire thread, this seems like a good place to segue into the DOTS > discussion at the tsvwg meeting last week. (I haven’t seen any > writeup about it on this list, apologies if I missed it.) > > Nik gave a quick overview of the problem DOTS intends to solve, > described the dispute about signaling transport that emerged during > the DOTS meeting, and showed a very basic slide in which a DOTS > client with an existing relationship with a DOTS server must signal > for help despite an ingress link congested with DDoS traffic. Time > for feedback during the meeting was limited, so there were only a few > comments (Cf. meeting minutes linked below, DOTS is the very last > item [1]): > > 1) Inform any planned UDP use with a good understanding of RFC > 5405bis. > 2) TCP incurs state. So does UDP with a heartbeat. Unidirectional DTLS is problematic [see also RFC 6520 —AM]. 3) Too > many DOTS clients could DoS a DOTS server. NAT binding timeouts could > be a problem. I imagine deploying my DOTS server in an anycast fashion to scale out and handle many clients. To avoid DDoS against my DOTS system I'd like to limit it's connectivity so that it's only reachable from my customers. This won't completely prevent attacks but will decrease the attack surface significantly. If there is a need to communicate with DOTS systems in other operator networks I could always put a second address on the system that is publicly routed. Further, I would like to see an automatic discovery mechanism for DOTS. This is perhaps not strictly related to transport but I'll just put it out here if anyone wants to comment. It could be something along the lines of the well known 6to4 anycast address (192.88.99.1 - RFC3068) or using DNS SRV records. I am seeing this from an operator perspective. We will naturally be in control of most of our own systems so configuring them to use the correct DOTS server is an easy task. For customers it's an entirely different thing though. Some will buy a DDoS mitigation service from us and we will in that case have control over a potential device at the customer premise that we can configure but there are lots of customers which won't buy such a service and I would still like to be able to offer them basic DDoS mitigation as part of their Internet service. Imagine something like just handling volumetric attacks. They are usually quite non-sophisticated making them both easy to detect and mitigate and while I could probably detect most using flow-based detection it would be a nice addition if the customer could send a DOTS MSR to a well known / discovered address in my network and receive help. > 4) Redundant packets seems better than many idle encrypted sessions. > 5) Consider using both UDP and TCP. Right, perhaps the outcome of DOTS happy eyeballs is a list of transports in order of priority so in a "normal" scenario you'd have UDP as well as TCP but the happy eyeballs process could for example eliminate UDP from that list if it is detected that UDP packets are filtered. kll > > (Some discussion has continued on the tsvwg mailing list—dots@ got > dropped from the replies—see [2] below.) > > None of that looks like consensus on transport, though the points > raised are valuable for requirements and protocol drafts. > > andrew > > [1] TSV WG minutes: > [2] > > > _______________________________________________ > Dots mailing list Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > From nobody Mon Nov 16 09:29: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 9A5811A8025 for ; Mon, 16 Nov 2015 09:29:47 -0800 (PST) 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 s-qrPz39Tohx for ; Mon, 16 Nov 2015 09:29:41 -0800 (PST) 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 710DB1A700D for ; Mon, 16 Nov 2015 09:29:41 -0800 (PST) Received: by padhx2 with SMTP id hx2so181259549pad.1 for ; Mon, 16 Nov 2015 09:29:41 -0800 (PST) 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=bRM4yICGBvMo5USr1zWwA97UPoFsUoM0y8OFMwgyefY=; b=c5pb8DIG35aDPPAQKNdqmI3uG1ZHa7BHEXV0G7FTGpwXFKSFeqWacsgvLO5Sz3VAO/ dEJC9qIlVAGnqtAzaMuwod5GK+ZpsK1i/sWV+AltEMa+2lXRBspkeANP81eEWWY4Lcor 86qI7izj2Uq+j1HVz+qWIIDOJoGG/07HZi7Tw= 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=bRM4yICGBvMo5USr1zWwA97UPoFsUoM0y8OFMwgyefY=; b=TU9Sg6skwrzYTQ+CAcsJ8CumSgMBOgZtbX3qgCkD/mn58tkNHlC/DM3HNn8cxQzD2S R8YcuddFu9EqPXnbiYvep6TSm3JNQQqT0k39LjcJhobNu6v+MidH+D8aHwu69p8bEO8V yKVuG00xbPHTCF5492B6P5y/gaoVfd1YqS+LDpRZMSGjDKnslFTpVr2UwgEP4Pt3zlEz 8thPB9wbg2bRbsOT3dUwkkWxcwI/jpdR1GUtOLvtLHPQD/6gBoV1T+6tE2d44f62RQnP FFECIy1TeHLmPnh+EK7VR5RuWzVS1IowmIw2rn0VW4tO4dnHIhCigcFOODWYCOFPQVXN EkSA== X-Gm-Message-State: ALoCoQlLZUnWNtIuIidVKB+C/OL/4ygc2PxWPY/X1mPfNdeJsXZX+EsQuRT0CtpTayCVBGomnt4C X-Received: by 10.68.142.74 with SMTP id ru10mr20666078pbb.157.1447694981050; Mon, 16 Nov 2015 09:29:41 -0800 (PST) Received: from [172.19.254.119] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id qn5sm37867310pac.41.2015.11.16.09.29.38 for (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 16 Nov 2015 09:29:39 -0800 (PST) From: "Roland Dobbins" To: dots@ietf.org Date: Tue, 17 Nov 2015 00:29:30 +0700 Message-ID: <831DF852-9ECF-4373-AF28-77ADDFD9AC9A@arbor.net> In-Reply-To: <5649B4B5.5090207@spritelink.net> References: <5638D31B.4080801@mti-systems.com> <0A836E5A-C801-4CF4-916C-41EA065D3D30@arbor.net> <563939F2.8010601@mti-systems.com> <3AFD973D-22CB-49BD-A384-A1C10A0167E9@arbor.net> <49d27818011843fcb79d6a2faca09b5f@XCH-RCD-017.cisco.com> <6709EB29-B856-45EC-A005-4AB4274C6B1D@arbor.net> <0c1ea5caef5542178d1c954bf8afa96b@XCH-RCD-017.cisco.com> <4FE28A47-A65E-4FE8-AA0B-FEA3712D061C@arbor.net> <5644BC0B.2010905@spritelink.net> <570C393A-3B90-40F0-A8BC-E5B96A11305F@arbor.net> <1C41567B-4031-466E-B205-E296B764CEDB@arbor.net> <5649B4B5.5090207@spritelink.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5164) Archived-At: Subject: Re: [Dots] [tsvwg] Best transport selection during an attack? 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, 16 Nov 2015 17:29:47 -0000 On 16 Nov 2015, at 17:49, Kristian Larsson wrote: > I imagine deploying my DOTS server in an anycast fashion to scale out > and handle many clients. Concur. > To avoid DDoS against my DOTS system I'd like to limit it's > connectivity so that it's only reachable from my customers. This won't > completely prevent attacks but will decrease the attack surface > significantly. If there is a need to communicate with DOTS systems in > other operator networks I could always put a second address on the > system that is publicly routed. Concur - relevant BCPs applied to BGP, etc. will have relevance here. > Further, I would like to see an automatic discovery mechanism for > DOTS. This is perhaps not strictly related to transport but I'll just > put it out here if anyone wants to comment. It could be something > along the lines of the well known 6to4 anycast address (192.88.99.1 - > RFC3068) or using DNS SRV records. Insofar as this is consistent with the above, concur. But this will likely be in a later stage, IMHO. > Right, perhaps the outcome of DOTS happy eyeballs is a list of > transports in order of priority so in a "normal" scenario you'd have > UDP as well as TCP but the happy eyeballs process could for example > eliminate UDP from that list if it is detected that UDP packets are > filtered. I think this is the right sort of thinking. DOTS peering will largely be 'nailed up' and manually configured for quite some time; fallback mechanisms are a good idea to provide for the possibility of some dynamism in this context. ----------------------------------- Roland Dobbins