From nobody Tue Mar 10 12:11: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 1C8A01A6EFC for ; Tue, 10 Mar 2015 12:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.3 X-Spam-Level: X-Spam-Status: No, score=-3.3 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, J_BACKHAIR_21=1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOHyPFO5YSoB for ; Tue, 10 Mar 2015 12:10:58 -0700 (PDT) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C07C11A6EDA for ; Tue, 10 Mar 2015 12:10:58 -0700 (PDT) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id t2AJAvcT019135 for ; Tue, 10 Mar 2015 15:10:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1426014657; bh=GlAw8OgOtGgYozxiU3l2MaOsOZefiI5hTkHUTXHuhRs=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version:Sender: Reply-To:Cc:In-Reply-To:References; b=Vrp4MFOlAMy87q0u0HOymPGSYa20C7NeTfnUI3kQOTREeHczGgkYHN9lrIIhiOHOQ UKe7WocUp/HguiUR1RQV9dx5etFXMRzMx4iI4biYou6wREfXbOWpda0joKOmPZP4U5 Si45Un2oLHOhT12phvACBGdgG3wgFc0LM+77+x6I= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by timber.sei.cmu.edu (8.14.4/8.14.4/1456) with ESMTP id t2AJAtlv030828 for ; Tue, 10 Mar 2015 15:10:55 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0210.002; Tue, 10 Mar 2015 15:10:55 -0400 From: "Roman D. Danyliw" To: "dots@ietf.org" Thread-Topic: Meeting time Thread-Index: AdBbZe55NuF12GQQRDGxbEJQrsv+Wg== Date: Tue, 10 Mar 2015 19:10:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_B75BCA1B7C5642D6905749274DE68195certorg_" MIME-Version: 1.0 Archived-At: Subject: [Dots] Meeting time X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 19:11:01 -0000 --_000_B75BCA1B7C5642D6905749274DE68195certorg_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8hDQoNClRoZSBhZ2VuZGEgWzFdIGZvciB0aGUgRGFsbGFzIG1lZXRpbmcgaGFzIGNvbWUg dG9nZXRoZXIuICBUaGUgRERvUyBPcGVuIFRocmVhdCBTaWduYWxpbmcgKERPVFMpIEJvRiBbMl0g aGFzIGJlZW4gc2NoZWR1bGVkIGFzIGZvbGxvd3M6DQoNClRVRVNEQVksIE1hcmNoIDI0LCAyMDE1 PHgtYXBwbGUtZGF0YS1kZXRlY3RvcnM6Ly8wPg0KMTUyMC0xNzIwIENEPHgtYXBwbGUtZGF0YS1k ZXRlY3RvcnM6Ly8xPlQNCkFmdGVybm9vbiBTZXNzaW9uIDINClZlbmV0aWFuDQpTRUMgICBkb3Rz ICBERG9TIE9wZW4gVGhyZWF0IFNpZ25hbGluZyBCT0YNCg0KUGxlYXNlIGpvaW4gdXMgZm9yIHRo aXMgbm9uLXdvcmtpbmcgZ3JvdXAgZm9ybWluZyBCT0YuICBGdXJ0aGVyIGRldGFpbHMgb24gdGhl IHNjb3BlIHdpbGwgYmUgZm9ydGhjb21pbmcgdG8gdGhlIGxpc3QuIEluIHRoZSBtZWFuIHRpbWUg Y29uc2lkZXIgcmV2aWV3aW5nIGRyYWZ0LXRlYWd1ZS1vcGVuLXRocmVhdC1zaWduYWxpbmctMDAg WzNdLg0KDQpSb21hbiBhbmQgUnVzcw0KDQpbMV0gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9tZWV0aW5nLzkyL2FnZW5kYS50eHQNClsyXSBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L3dnL2RvdHMvY2hhcnRlci8NClszXSBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10 ZWFndWUtb3Blbi10aHJlYXQtc2lnbmFsaW5nLTAwDQoNCg0K --_000_B75BCA1B7C5642D6905749274DE68195certorg_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDI1NSwgMjU1LCAyNTUsIDAp OyI+SGVsbG8hPGJyPg0KPGJyPg0KVGhlIGFnZW5kYSBbMV0gZm9yIHRoZSBEYWxsYXMgbWVldGlu ZyBoYXMgY29tZSB0b2dldGhlci4gJm5ic3A7VGhlIEREb1MgT3BlbiBUaHJlYXQgU2lnbmFsaW5n IChET1RTKSBCb0YgWzJdIGhhcyBiZWVuIHNjaGVkdWxlZCBhcyBmb2xsb3dzOjxicj4NCjxicj4N CjxhIGhyZWY9IngtYXBwbGUtZGF0YS1kZXRlY3RvcnM6Ly8wIiB4LWFwcGxlLWRhdGEtZGV0ZWN0 b3JzPSJ0cnVlIiB4LWFwcGxlLWRhdGEtZGV0ZWN0b3JzLXR5cGU9ImNhbGVuZGFyLWV2ZW50IiB4 LWFwcGxlLWRhdGEtZGV0ZWN0b3JzLXJlc3VsdD0iMCI+VFVFU0RBWSwgTWFyY2ggMjQsIDIwMTU8 L2E+PC9zcGFuPjwvZGl2Pg0KPGRpdj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogcmdi YSgyNTUsIDI1NSwgMjU1LCAwKTsiPjxhIGhyZWY9IngtYXBwbGUtZGF0YS1kZXRlY3RvcnM6Ly8x IiB4LWFwcGxlLWRhdGEtZGV0ZWN0b3JzPSJ0cnVlIiB4LWFwcGxlLWRhdGEtZGV0ZWN0b3JzLXR5 cGU9ImNhbGVuZGFyLWV2ZW50IiB4LWFwcGxlLWRhdGEtZGV0ZWN0b3JzLXJlc3VsdD0iMSI+MTUy MC0xNzIwIENEPC9hPlQmbmJzcDs8L3NwYW4+PC9kaXY+DQo8ZGl2PjxzcGFuIHN0eWxlPSJiYWNr Z3JvdW5kLWNvbG9yOiByZ2JhKDI1NSwgMjU1LCAyNTUsIDApOyI+QWZ0ZXJub29uIFNlc3Npb24g Mjxicj4NClZlbmV0aWFuICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmbmJzcDsmbmJzcDs8L3NwYW4+PC9kaXY+DQo8ZGl2PjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5k LWNvbG9yOiByZ2JhKDI1NSwgMjU1LCAyNTUsIDApOyI+U0VDICZuYnNwOyBkb3RzICZuYnNwO0RE b1MgT3BlbiBUaHJlYXQgU2lnbmFsaW5nIEJPRjxicj4NCjxicj4NClBsZWFzZSBqb2luIHVzIGZv ciB0aGlzIG5vbi13b3JraW5nIGdyb3VwIGZvcm1pbmcgQk9GLiAmbmJzcDtGdXJ0aGVyIGRldGFp bHMgb24gdGhlIHNjb3BlIHdpbGwgYmUgZm9ydGhjb21pbmcgdG8gdGhlIGxpc3QuIEluIHRoZSBt ZWFuIHRpbWUgY29uc2lkZXIgcmV2aWV3aW5nJm5ic3A7ZHJhZnQtdGVhZ3VlLW9wZW4tdGhyZWF0 LXNpZ25hbGluZy0wMCBbM10uPGJyPg0KPGJyPg0KUm9tYW4gYW5kIFJ1c3M8YnI+DQo8YnI+DQpb MV0mbmJzcDs8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvOTIv YWdlbmRhLnR4dCIgeC1hcHBsZS1kYXRhLWRldGVjdG9ycz0idHJ1ZSIgeC1hcHBsZS1kYXRhLWRl dGVjdG9ycy10eXBlPSJsaW5rIiB4LWFwcGxlLWRhdGEtZGV0ZWN0b3JzLXJlc3VsdD0iMiI+aHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzkyL2FnZW5kYS50eHQ8L2E+PGJyPg0K WzJdJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy93Zy9kb3RzL2No YXJ0ZXIvIiB4LWFwcGxlLWRhdGEtZGV0ZWN0b3JzPSJ0cnVlIiB4LWFwcGxlLWRhdGEtZGV0ZWN0 b3JzLXR5cGU9ImxpbmsiIHgtYXBwbGUtZGF0YS1kZXRlY3RvcnMtcmVzdWx0PSIzIj5odHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL3dnL2RvdHMvY2hhcnRlci88L2E+PGJyPg0KWzNdJm5ic3A7 PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdGVhZ3VlLW9wZW4tdGhy ZWF0LXNpZ25hbGluZy0wMCIgeC1hcHBsZS1kYXRhLWRldGVjdG9ycz0idHJ1ZSIgeC1hcHBsZS1k YXRhLWRldGVjdG9ycy10eXBlPSJsaW5rIiB4LWFwcGxlLWRhdGEtZGV0ZWN0b3JzLXJlc3VsdD0i NCI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdGVhZ3VlLW9wZW4tdGhyZWF0LXNp Z25hbGluZy0wMDwvYT48L3NwYW4+PGJyPg0KPGJyPg0KPGJyPg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_B75BCA1B7C5642D6905749274DE68195certorg_-- From nobody Tue Mar 10 12:30:35 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83D161A01AA for ; Tue, 10 Mar 2015 12:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jovpFuyqcGVQ for ; Tue, 10 Mar 2015 12:30:32 -0700 (PDT) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 821681A1B51 for ; Tue, 10 Mar 2015 12:30:32 -0700 (PDT) Received: from pawpaw.sei.cmu.edu (pawpaw.sei.cmu.edu [10.64.21.22]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id t2AJUVKT020064 for ; Tue, 10 Mar 2015 15:30:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1426015831; bh=QfmU85o+2VtCtuTgclacFGZS4DUEZjHIvUixnxk92pI=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version:Sender:Reply-To:Cc: In-Reply-To:References; b=EsggDjHoOf54juS3jvnhPuszaMpNShsdfStzE9A2yzZo/AtpH+n1iB9deV29KX/3B OpELS6r1XUYoNSgjdWvoLpAiYPDWKKlp6yNoM/gZrbY6u8u6VIZ8R9wW0ch6uvIAHl nv2whPdLI9j6brcpgrf++kzndN6JMwRpqSp/jBSI= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1456) with ESMTP id t2AJUUYV008363 for ; Tue, 10 Mar 2015 15:30:30 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0210.002; Tue, 10 Mar 2015 15:30:26 -0400 From: "Roman D. Danyliw" To: "'dots@ietf.org'" Thread-Topic: feedback on draft-teague-open-threat-signaling-00 Thread-Index: AdBbaEPrl8b2gcZbTQeEIW3w7v4P0w== Date: Tue, 10 Mar 2015 19:30:25 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFCD93BFB17@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Dots] feedback on draft-teague-open-threat-signaling-00 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for 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 Mar 2015 19:30:34 -0000 Hi Nik! I wanted to get the conversation started around your draft. Please find be= low a few things that jumped out at me upon first review. I fully realize = that as an -00 informational draft some of the details poked at by these qu= estions would get resolved later or be implementation details. ** Why use two different channels? Why two different formats for each of th= e channels? =20 IPFIX being widely implemented on some mitigation devices is cited in Secti= on 6. Does it follow that JSON over HTTP is also widely implemented on the= same devices? Is the assumption that IPFIX is commonly implemented on IDS, IPS and WAFs a= lso hold? ** Page 2, Section 2. Coming into this section it wasn't clear for which c= hannel, IPFIX or JSON, this dictionary was referencing. ** Page 4, last paragraph. "This specific set of identifiers may be furthe= r expanded .. across JSON API". I didn't find a description of this update= mechanism in the draft. ** Page 7, Section 4. It wasn't readily apparent to me on how to use these= IDs in the IPFIX templates because the category/type names didn't line up **Page 9, Section 5. "The JSON API channel is expected to be opened at regu= lar intervals ..." How often is that? ** Page 10, device_threshold_config and mitigation_info. Both of these attr= ibutes/objects are noted to be extensible but the explicit mechanism isn't = in the draft. =20 ** Page 11, mitigation_info status attribute. It would appear that the sta= tus attribute is mutually exclusive. However, I was wondering if the monit= oring and mitigation state might arise simultaneously. Wouldn't IPFIX mess= age be getting sent while mitigation is happing upstream? ** Page 11, Section 5.0. What happens if an unrecognized attribute or obje= ct is sent? ** Page 11, Section 5.1 diagram. The term used for node "I" is "IPFIX rece= iver". Is that the same thing as an "IPFIX Collector" used in the IPFIX ar= chitecture? ** Page 11-12, Example, The write-up for the example states that the "SOS f= lag will be set to true should the component cpu=3D85% or mem=3D85% or band= width=3D75%". I'm trying to understand how the "D" in the reference archit= ecture would have known that. Specifically, did the "D" know that load_fac= tor1 =3D cpu, load_factor2 =3D mem and load_factor3 =3D bandwidth? Shouldn= 't the original POST sent by D in the example have these variables defined = with "load_factor1: , load_factor2: , etc." declarations? Al= so, I didn't find it specified anywhere that the load_factors are all ORed = together (any has to be true). Are other expressions possible? ** Page 12, Section 6. I found the write-up of when each template gets sen= t very helpful. I would suggest expanding this narrative to describe the J= SON API too so that the reader gets a sense of who sends what (relative to = the reference architecture) and under what circumstances. ** Page 12, Section 6, second paragraph. "An attack will trigger the creat= ion of an incident record". I couldn't find a definition of an incident re= cord? Of the three IPFIX templates (event, protected object, attack/threat)= is it the event template? ** Page 12, Section 6, second paragraph. "Due to the unreliable nature of U= DP ... will repeat at regular intervals .." How often is that? ** Page 12, Section 6, fourth paragraph. "An IPFIX event data export may b= e used as a heartbeat between elements". How often does this heartbeat get= sent before "C" or "I" start worrying? Likewise, if "I" is receiving the = IPFIX messages from "D", but "C" is doing all of the signaling back to "D".= What is the signaling between "I" and "C"? ** Page 13, Section 6, templates. I recognize many of the field names from= previous sections but missing are the detailed field write-ups (e.g., data= types). Furthermore, in considering the IPFIX header, I was also wonderin= g how the observationdomain Id was getting set. ** Page 15, Section 8, IANA considerations. I would have figured that some= of these newly defined IPFIX might be put into a registry for future maint= enance if a construct like this draft moves forward. Roman From nobody Wed Mar 18 11:24: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 186F01A9044 for ; Wed, 18 Mar 2015 11:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id leGZ_cqGQ_1A for ; Wed, 18 Mar 2015 11:24:17 -0700 (PDT) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68C801A9042 for ; Wed, 18 Mar 2015 11:24:16 -0700 (PDT) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by shetland.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id t2IIOGaS017381 for ; Wed, 18 Mar 2015 14:24:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1426703056; bh=A93qnHuI66Bqzsa4K8Az+XDefVCRKUIYxceK2JHH6fw=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version:Sender: Reply-To:Cc:In-Reply-To:References; b=Q/8NfuirJcDqdGYelyD2uDx4Vae8PHfqk75d6yh7rnHzYcR2PHV6Tr2I/S5zrcjnZ Um15rnNmz0X1FwA2L4tJ+dGaT3c2vkXpU0PZGT2BF7HbQCq1OzXQOyzGblZ4zq3am1 ZhgmlzgL4pVWjQ1tJcGsIZD9hwT4VnEOiNpR5SD4= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by timber.sei.cmu.edu (8.14.4/8.14.4/1456) with ESMTP id t2IIOCoC013891 for ; Wed, 18 Mar 2015 14:24:12 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0210.002; Wed, 18 Mar 2015 14:24:12 -0400 From: "Roman D. Danyliw" To: "dots@ietf.org" Thread-Topic: DOTS agenda Thread-Index: AdBhqLsH7eUx9I/kQo6wGt/tdqhgBQ== Date: Wed, 18 Mar 2015 18:24:11 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_F6DCB79FDD9D45D58D7C02DA733DC155certorg_" MIME-Version: 1.0 Archived-At: Subject: [Dots] DOTS agenda X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for 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, 18 Mar 2015 18:24:19 -0000 --_000_F6DCB79FDD9D45D58D7C02DA733DC155certorg_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8hDQoNClBsZWFzZSBmaW5kIGJlbG93IHRoZSBkcmFmdCBhZ2VuZGEgZm9yIHRoZSBET1RT IEJPRiBpbiBEYWxsYXMuDQoNCg0KDQpET1RTIEJPRiBBZ2VuZGENCg0KVHVlc2RheSwgTWFyY2gg MjQgMjAxNTx4LWFwcGxlLWRhdGEtZGV0ZWN0b3JzOi8vMD4NCjE1MjAgLSAxNzIwIENEVCwgQWZ0 ZXJub29uIFNlc3Npb24gSUkNClZlbmV0aWFuDQoNCg0KDQoxLiBOb3RlIHdlbGwsIGxvZ2lzdGlj cywgYWdlbmRhIGJhc2hpbmcsIGludHJvZHVjdGlvbiBvZiBCT0YgKGNoYWlycywgMTAgbWluKQ0K Mi4gZHJhZnQtdGVhZ3VlLW9wZW4tdGhyZWF0LXNpZ25hbGluZy0wMCAoTmlrIFRlYWd1ZSwgMjAg bWluKQ0KMy4gZHJhZnQtZnUtaXBmaXgtbmV0d29yay1zZWN1cml0eS0wMCAoQW5hIEhlZGFucGlu ZywgMTUgbWluKQ0KNC4gUGFuZWwgZGlzY3Vzc2lvbiBvbiBzdWl0YWJpbGl0eSAoNDAgbWluKQ0K NS4gRnVydGhlciBkaXNjdXNzaW9uICgzMCBtaW4pDQo2LiBDbG9zaW5nIChjaGFpcnMvQUQsIDUg bWluKQ0KDQoNCg0K --_000_F6DCB79FDD9D45D58D7C02DA733DC155certorg_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PkhlbGxvITwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+UGxlYXNlIGZpbmQgYmVs b3cgdGhlIGRyYWZ0IGFnZW5kYSBmb3IgdGhlIERPVFMgQk9GIGluIERhbGxhcy48L2Rpdj4NCjxk aXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjxwIHN0eWxlPSJtYXJnaW4tYm90dG9tOiAwcHg7 IG1hcmdpbi10b3A6IDBweDsiPjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDI1 NSwgMjU1LCAyNTUsIDApOyI+RE9UUyBCT0YgQWdlbmRhPC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJt YXJnaW4tYm90dG9tOiAwcHg7IG1hcmdpbi10b3A6IDBweDsiPjxmb250IGNvbG9yPSIjMDAwMDAw Ij48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogcmdiYSgyNTUsIDI1NSwgMjU1LCAwKTsi PjxhIGhyZWY9IngtYXBwbGUtZGF0YS1kZXRlY3RvcnM6Ly8wIiB4LWFwcGxlLWRhdGEtZGV0ZWN0 b3JzPSJ0cnVlIiB4LWFwcGxlLWRhdGEtZGV0ZWN0b3JzLXR5cGU9ImNhbGVuZGFyLWV2ZW50IiB4 LWFwcGxlLWRhdGEtZGV0ZWN0b3JzLXJlc3VsdD0iMCI+VHVlc2RheSwNCiBNYXJjaCAyNCAyMDE1 PC9hPjxicj4NCjE1MjAgLSAxNzIwIENEVCwgQWZ0ZXJub29uIFNlc3Npb24gSUk8YnI+DQpWZW5l dGlhbjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1ib3R0b206IDBweDsgbWFy Z2luLXRvcDogMHB4OyI+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYmEoMjU1LCAy NTUsIDI1NSwgMCk7Ij4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1ib3R0b206 IDBweDsgbWFyZ2luLXRvcDogMHB4OyI+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJn YmEoMjU1LCAyNTUsIDI1NSwgMCk7Ij4xLiBOb3RlIHdlbGwsIGxvZ2lzdGljcywgYWdlbmRhIGJh c2hpbmcsIGludHJvZHVjdGlvbiBvZiBCT0YgKGNoYWlycywgMTAgbWluKTxicj4NCjIuIGRyYWZ0 LXRlYWd1ZS1vcGVuLXRocmVhdC1zaWduYWxpbmctMDAgKE5payBUZWFndWUsIDIwIG1pbik8YnI+ DQozLiBkcmFmdC1mdS1pcGZpeC1uZXR3b3JrLXNlY3VyaXR5LTAwIChBbmEgSGVkYW5waW5nLCAx NSBtaW4pPGJyPg0KNC4gUGFuZWwgZGlzY3Vzc2lvbiBvbiBzdWl0YWJpbGl0eSAoNDAgbWluKTxi cj4NCjUuIEZ1cnRoZXIgZGlzY3Vzc2lvbiAoMzAgbWluKTxicj4NCjYuIENsb3NpbmcgKGNoYWly cy9BRCwgNSBtaW4pPC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tYm90dG9tOiAwcHg7IG1h cmdpbi10b3A6IDBweDsiPjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDI1NSwg MjU1LCAyNTUsIDApOyI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxicj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_F6DCB79FDD9D45D58D7C02DA733DC155certorg_-- From nobody Wed Mar 18 13:26: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 673CB1A88A4 for ; Wed, 18 Mar 2015 13:26:52 -0700 (PDT) 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqSoV1SR8oR0 for ; Wed, 18 Mar 2015 13:26:51 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACF541A889D for ; Wed, 18 Mar 2015 13:26:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id A4D7960186; Wed, 18 Mar 2015 16:26:48 -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 rQHyZXUXp2DW; Wed, 18 Mar 2015 16:26:46 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (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 58EEE6029A; Wed, 18 Mar 2015 16:26:45 -0400 (EDT) Message-ID: <5509DF7E.2050901@htt-consult.com> Date: Wed, 18 Mar 2015 16:26:38 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Roman D. Danyliw" , "dots@ietf.org" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------020208030602080205030200" Archived-At: Subject: Re: [Dots] DOTS agenda X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for 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, 18 Mar 2015 20:26:52 -0000 This is a multi-part message in MIME format. --------------020208030602080205030200 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Greetings other on this list. In case you have not heard, I am no longer employed by Verizon. I have a contract with Huawei to work on dots. I have begun reading the drafts and look forward to working with others on these items. See you in Dallas. On 03/18/2015 02:24 PM, Roman D. Danyliw wrote: > Hello! > > Please find below the draft agenda for the DOTS BOF in Dallas. > > > DOTS BOF Agenda > > Tuesday, March 24 2015 > 1520 - 1720 CDT, Afternoon Session II > Venetian > > 1. Note well, logistics, agenda bashing, introduction of BOF (chairs, > 10 min) > 2. draft-teague-open-threat-signaling-00 (Nik Teague, 20 min) > 3. draft-fu-ipfix-network-security-00 (Ana Hedanping, 15 min) > 4. Panel discussion on suitability (40 min) > 5. Further discussion (30 min) > 6. Closing (chairs/AD, 5 min) > > > > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots --------------020208030602080205030200 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Greetings other on this list.  In case you have not heard, I am no longer employed by Verizon.

I have a contract with Huawei to work on dots.  I have begun reading the drafts and look forward to working with others on these items.

See you in Dallas.

On 03/18/2015 02:24 PM, Roman D. Danyliw wrote:
Hello!

Please find below the draft agenda for the DOTS BOF in Dallas.


DOTS BOF Agenda

Tuesday, March 24 2015
1520 - 1720 CDT, Afternoon Session II
Venetian

 

1. Note well, logistics, agenda bashing, introduction of BOF (chairs, 10 min)
2. draft-teague-open-threat-signaling-00 (Nik Teague, 20 min)
3. draft-fu-ipfix-network-security-00 (Ana Hedanping, 15 min)
4. Panel discussion on suitability (40 min)
5. Further discussion (30 min)
6. Closing (chairs/AD, 5 min)

 




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

--------------020208030602080205030200-- From nobody Wed Mar 18 13:43:37 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24ABC1A88AE for ; Wed, 18 Mar 2015 13:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 NZyMqIQnGkup for ; Wed, 18 Mar 2015 13:43:34 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::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 142721A1B92 for ; Wed, 18 Mar 2015 13:43:34 -0700 (PDT) Received: by lbblx11 with SMTP id lx11so16561341lbb.3 for ; Wed, 18 Mar 2015 13:43:32 -0700 (PDT) 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=Or22T611cjXeStrzvKmWMVhuMlNm4bKSYDoL1KSjhwg=; b=XY6nWTJieM3LFINacG73t48qWiQV3zRIfNvBaiwN/zHo2rZPEl8bizP56mcIVoo7Aw UvPPXTvRSU1QNU+nEv3+nmlIzeN7VO2ti8LRoLHKch2j+6hu/046lChsrpyEFBNtkgPH X+ZXIuDZ6Bf6WONiFm4VZyIvGFS53b1YizGeNVOeuKmOFxDGB0SPyyhRIkQ/9D6XHUfA 6GrWiqIXJ7k8Mu8YEosexSey7oIPga+GBR5jXgj+qYxILBrPXES5YV/g8KXovP3aXy8K LATGBKHcPcH8MLgPfaYpOJdvh6VDvSuC7HKoZPityEPVlWkUNV9rwn83W8SEeMGX2k6D KKMA== MIME-Version: 1.0 X-Received: by 10.152.178.197 with SMTP id da5mr67692211lac.56.1426711412414; Wed, 18 Mar 2015 13:43:32 -0700 (PDT) Received: by 10.112.167.101 with HTTP; Wed, 18 Mar 2015 13:43:32 -0700 (PDT) In-Reply-To: <5509DF7E.2050901@htt-consult.com> References: <5509DF7E.2050901@htt-consult.com> Date: Wed, 18 Mar 2015 16:43:32 -0400 Message-ID: From: Kathleen Moriarty To: Robert Moskowitz Content-Type: multipart/alternative; boundary=001a11340c68ef20110511962242 Archived-At: Cc: "Roman D. Danyliw" , "dots@ietf.org" Subject: Re: [Dots] DOTS agenda X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for 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, 18 Mar 2015 20:43:36 -0000 --001a11340c68ef20110511962242 Content-Type: text/plain; charset=UTF-8 Thanks for posting the agenda, Roman. I'd like to see more discussion on the drafts before the BoF to gauge interest. There are several interesting aspects to the proposals including the re-use of existing standards (technology) and enabling telemetry data to be automatically exchanged (policy). Roman provided a detailed review of draft-teague-open-threat-signaling-00. I'd to see a response from the editors and discussion from those interested in this and the other draft being presented. This BoF came in as a late request, so usually we see this type of activity before a BoF is approved and it is important to figure out who's interested, what problems exist, etc. Thank you. On Wed, Mar 18, 2015 at 4:26 PM, Robert Moskowitz wrote: > Greetings other on this list. In case you have not heard, I am no longer > employed by Verizon. > > I have a contract with Huawei to work on dots. I have begun reading the > drafts and look forward to working with others on these items. > > See you in Dallas. > > > On 03/18/2015 02:24 PM, Roman D. Danyliw wrote: > > Hello! > > Please find below the draft agenda for the DOTS BOF in Dallas. > > > DOTS BOF Agenda > > Tuesday, March 24 2015 > 1520 - 1720 CDT, Afternoon Session II > Venetian > > > > 1. Note well, logistics, agenda bashing, introduction of BOF (chairs, 10 > min) > 2. draft-teague-open-threat-signaling-00 (Nik Teague, 20 min) > 3. draft-fu-ipfix-network-security-00 (Ana Hedanping, 15 min) > 4. Panel discussion on suitability (40 min) > 5. Further discussion (30 min) > 6. Closing (chairs/AD, 5 min) > > > > > > _______________________________________________ > Dots mailing listDots@ietf.orghttps://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > > -- Best regards, Kathleen --001a11340c68ef20110511962242 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for posting the agenda, Roman.

I= 'd like to see more discussion on the drafts before the BoF to gauge in= terest.=C2=A0 There are several interesting aspects to the proposals includ= ing the re-use of existing standards (technology) and enabling telemetry da= ta to be automatically exchanged (policy). =C2=A0

= Roman provided a detailed review of draft-teague-open-threat-signaling-00.=C2=A0 I'd to see a response from the editors and = discussion from those interested in this and the other draft being presente= d.=C2=A0 This BoF came in as a late request, so usually we see this type of= activity before a BoF is approved and it is important to figure out who= 9;s interested, what problems exist, etc.

Thank you.

On Wed, Mar 18, 2015 at 4:26 PM, Robert Mo= skowitz <rgm-sec@htt-consult.com> wrote:
=20 =20 =20
Greetings other on this list.=C2=A0 In case you have not heard, I am no longer employed by Verizon.

I have a contract with Huawei to work on dots.=C2=A0 I have begun readi= ng the drafts and look forward to working with others on these items.

See you in Dallas.


On 03/18/2015 02:24 PM, Roman D. Danyliw wrote:
=20
Hello!

Please find below the draft agenda for the DOTS BOF in Dallas.


DOTS BOF Agenda

Tuesday, March 2= 4 2015
1520 - 1720 CDT, Afternoon Session II
Venetian

=C2=A0

1. Note well, logistics, agenda bashing, introduction of BOF (chairs, 10 min)
2. draft-teague-open-threat-signaling-00 (Nik Teague, 20 min)
3. draft-fu-ipfix-network-security-00 (Ana Hedanping, 15 min)
4. Panel discussion on suitability (40 min)
5. Further discussion (30 min)
6. Closing (chairs/AD, 5 min)

=C2=A0




_______________________________________________
Dots mailing list
Dots@ietf.org
ht=
tps://www.ietf.org/mailman/listinfo/dots


_______________________________________________
Dots mailing list
Dots@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dots




--

Best regards,
Ka= thleen
--001a11340c68ef20110511962242-- From nobody Wed Mar 18 17:45: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 78FA61AC3C9 for ; Wed, 18 Mar 2015 17:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69IvFgkV_lqM for ; Wed, 18 Mar 2015 17:45:45 -0700 (PDT) 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 48D991AC3C8 for ; Wed, 18 Mar 2015 17:45:45 -0700 (PDT) Received: by qgdz107 with SMTP id z107so1475704qgd.1 for ; Wed, 18 Mar 2015 17:45:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:accept-language:content-language:user-agent:content-type :content-id:content-transfer-encoding:mime-version; bh=9HVLwqnsnilr7VRthgKZ1Q5wtg0yP4OTkUx1ut61A/Y=; b=GIr5Q/U5UXDsWnaSOs+WFH0zskLFXkahsXWFwYs1QRZ/jE/JSMwocmJWEn6soOSncB oK4wo9EItHFKokiDjwmdTwRV6kekyeC71/4IxMjG5voANY/j8+5b0dsIOuMpNpQxnG+k l34X3Iz3xlhyj1xjFBy9Nf1l2zlBNPptBpgP6SJp7wlWQsFK1EfQntGl2PV18jh6EADg ViR7fHkv3kdK0hQZ/MrR/8EL7u/TkXqsV+cRq3GhMONHo3LiyRrePM8jM/J56y8hvrRM A1LW+BCv8PdsdiJ5ab3Q30DHWcZN+yqrkStiSTrZbi2nfTmqbE5m5rdNyGQz3Xe63Bqf zf/w== X-Gm-Message-State: ALoCoQmNs11sato9hXj51trpI64zvzxZLBa773wodixIyPg3hQt8LuZ6+bUoxlk0n5q8jC5GizWH1vOz7KWaegCophMkn+PItQ== X-Received: by 10.107.28.196 with SMTP id c187mr57376517ioc.48.1426725944089; Wed, 18 Mar 2015 17:45:44 -0700 (PDT) Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by mx.google.com with ESMTPS id k1sm11411ige.0.2015.03.18.17.45.43 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 18 Mar 2015 17:45:44 -0700 (PDT) X-Relaying-Domain: verisign.com Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01 [10.173.152.255]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id t2J0jgPo032684 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Mar 2015 20:45:42 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 18 Mar 2015 20:45:42 -0400 From: "Teague, Nik" To: "Roman D. Danyliw" , "'dots@ietf.org'" Thread-Topic: [Dots] feedback on draft-teague-open-threat-signaling-00 Thread-Index: AQHQYd4GsmlJ5Lgp8k+uuem9++a0hw== Date: Thu, 19 Mar 2015 00:45:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] feedback on draft-teague-open-threat-signaling-00 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for 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, 19 Mar 2015 00:45:49 -0000 On 10/03/2015 19:30, "Roman D. Danyliw" wrote: >Hi Nik! > >I wanted to get the conversation started around your draft. Please find >below a few things that jumped out at me upon first review. I fully >realize that as an -00 informational draft some of the details poked at >by these questions would get resolved later or be implementation details. - Hi Roman=8A Thanks for taking the time to review this and provide such detailed feedback. >** Why use two different channels? Why two different formats for each of >the channels? =20 - Great question - DDoS mitigation platforms tend to operate in a peacetime posture where traditional channels are feasible or they are operating in a mitigation posture where their ingress links could be heavily congested. In the latter instance connection oriented protocols become problematic or impossible to maintain. If an operator wants to have their device communicate with an upstream DDoS mitigation service provider who will undertake scrubbing they will have to exchange a degree of information for the provider to be able to effectively protect them in times of need. This information can be exchanged across traditional channels and the information exchange at this stage may not be exclusively one way. E.g the service provider may want to push information (whitelists, blacklists, collector destinations etc.) back to the operator device. Splitting things into 2x channels provides, in my mind, the correct protocol for each posture=8A The differing formats, again, lend themselves well to their given tasks IPFIX is already a great foundation for data export beyond flow information and its template based approach also lends itself well to extensibility. >IPFIX being widely implemented on some mitigation devices is cited in >Section 6. Does it follow that JSON over HTTP is also widely implemented >on the same devices? - Many of the CPE devices in this sphere already have some implementation of issuing API calls to some upstream peer. With a JSON RPC API over HTTPS this may be accomplished by anything running cURL. >Is the assumption that IPFIX is commonly implemented on IDS, IPS and WAFs >also hold? - To my knowledge this doesn=B9t hold - and this highlights that the 00 draft references to these applications being too generic and really scope should focus on DDoS mitigation platforms. I do think that expanding this to other applications which are in the path of attacks could provide some interesting opportunities - but at this stage that is very ambitious. >** Page 2, Section 2. Coming into this section it wasn't clear for which >channel, IPFIX or JSON, this dictionary was referencing. - Noted - the dictionary is used by the IPFIX channel for communication of telemetry. Clarity is required in the description and assignment to a channel. >** Page 4, last paragraph. "This specific set of identifiers may be >further expanded .. across JSON API". I didn't find a description of >this update mechanism in the draft. - Nope - this is at this stage a concept that I would like to explore in greater detail as I believe this could offer a powerful method of updating the dictionary in the field. >** Page 7, Section 4. It wasn't readily apparent to me on how to use >these IDs in the IPFIX templates because the category/type names didn't >line up - Yes - I can see this isn=B9t clear and needs to be better explained/tied in. >**Page 9, Section 5. "The JSON API channel is expected to be opened at >regular intervals ..." How often is that? - This could be negotiable and probably should be - on first registration a device and service provider could agree a check in interval. I don=B9t perceive this being required though at intervals of less than 12 hours or probably even 24. Although elaborating on all this in the draft would obviously be helpful. >** Page 10, device_threshold_config and mitigation_info. Both of these >attributes/objects are noted to be extensible but the explicit mechanism >isn't in the draft. - Yes I see how that needs to be represented with more clarity both in the text and the JSON examples. >** Page 11, mitigation_info status attribute. It would appear that the >status attribute is mutually exclusive. However, I was wondering if the >monitoring and mitigation state might arise simultaneously. Wouldn't >IPFIX message be getting sent while mitigation is happing upstream? - Yes there are instances where both would occur and it is worth adjusting the status definitions to include a mitigating-monitoring for those overlapping occurrences. >** Page 11, Section 5.0. What happens if an unrecognized attribute or >object is sent? - An unrecognised attribute/object where it occurs outside of the bare bones protocol definition should probably result in a warning but should not interfere with the systems ongoing operation. >** Page 11, Section 5.1 diagram. The term used for node "I" is "IPFIX >receiver". Is that the same thing as an "IPFIX Collector" used in the >IPFIX architecture? - =B3Receiver" should be replaced by =B3collector=B2 in this instance. >** Page 11-12, Example, The write-up for the example states that the "SOS >flag will be set to true should the component cpu=3D85% or mem=3D85% or >bandwidth=3D75%". I'm trying to understand how the "D" in the reference >architecture would have known that. Specifically, did the "D" know that >load_factor1 =3D cpu, load_factor2 =3D mem and load_factor3 =3D bandwidth? >Shouldn't the original POST sent by D in the example have these variables >defined with "load_factor1: , load_factor2: , etc." >declarations? Also, I didn't find it specified anywhere that the >load_factors are all ORed together (any has to be true). Are other >expressions possible? - Other expressions may, indeed, be possible and this does require further exploration and explanation. Different systems may have differing capabilities and in certain instances any one of those thresholds being reached may not be enough to initiate offramping. The assumption was, however, that any of the load_factors reaching a threshold would shortly result in a degradation of some kind. My preference would be to specify the expressions or combinations that a particular device would consider critical and as such an offramp action would be desirable. >** Page 12, Section 6. I found the write-up of when each template gets >sent very helpful. I would suggest expanding this narrative to describe >the JSON API too so that the reader gets a sense of who sends what >(relative to the reference architecture) and under what circumstances. - Noted... >** Page 12, Section 6, second paragraph. "An attack will trigger the >creation of an incident record". I couldn't find a definition of an >incident record? Of the three IPFIX templates (event, protected object, >attack/threat) is it the event template? - Its the event record and this was an error of mixing terminology - incident is a term of reference for certain DDoS mitigation implementations but in this context we=B9re describing it under the umbrell= a of an event. =20 > >** Page 12, Section 6, second paragraph. "Due to the unreliable nature of >UDP ... will repeat at regular intervals .." How often is that? - This should be a tuneable function in my mind. A default of somewhere between 3 and 5 minutes should probably suffice. >** Page 12, Section 6, fourth paragraph. "An IPFIX event data export may >be used as a heartbeat between elements". How often does this heartbeat >get sent before "C" or "I" start worrying? Likewise, if "I" is receiving >the IPFIX messages from "D", but "C" is doing all of the signaling back >to "D". What is the signaling between "I" and "C"? - I think for the heartbeat to be effective then every 60 seconds is a good default. The loss of 3x heartbeats (3minutes of no contact) could result in the upstream considering communication to have been lost and a warning/alert flagged up. >** Page 13, Section 6, templates. I recognize many of the field names >from previous sections but missing are the detailed field write-ups >(e.g., data types). Furthermore, in considering the IPFIX header, I was >also wondering how the observationdomain Id was getting set. - Deriving the observationDomain ID may be implementation specific. If we set the ID from the perspective of the upstream then we are assuming that this is the only export destination=8A Which may not be the case. >** Page 15, Section 8, IANA considerations. I would have figured that >some of these newly defined IPFIX might be put into a registry for future >maintenance if a construct like this draft moves forward. - I agree and this will be fixed. Looking forward to seeing you in Dallas. Thanks, -Nik From nobody Sat Mar 21 13:29: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 4EF601A87C2 for ; Sat, 21 Mar 2015 13:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9aNa20BuFlh for ; Sat, 21 Mar 2015 13:29:19 -0700 (PDT) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BDE81A87C1 for ; Sat, 21 Mar 2015 13:29:19 -0700 (PDT) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id t2LKTI3C016207 for ; Sat, 21 Mar 2015 16:29:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1426969758; bh=lKqxHS9CnWwR5vdte4ym63fBOdM7eKuEJftG7Oyh1BI=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version:Sender:Reply-To:Cc: In-Reply-To:References; b=PnrNSKurvvDcjsaFSTuHBW80qT5WRzaiB+eJ9EQbEsuFq+Bxp+1L6l9AdIebWA+3B 1+uj7dICUcoBWiTAFQ47AclLKgWvsWnL7N8d+Kyf8uMXc31KX4m066o0C506pDwH9G mx/oJcdFg/viLFFei34Y14/tmRco8eAuwnL6l9Yc= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by timber.sei.cmu.edu (8.14.4/8.14.4/1456) with ESMTP id t2LKTEGm029133 for ; Sat, 21 Mar 2015 16:29:14 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0210.002; Sat, 21 Mar 2015 16:29:13 -0400 From: "Roman D. Danyliw" To: "'dots@ietf.org'" Thread-Topic: DOTS Description Thread-Index: AdBkFWs4ohmWUP7VQNmAGAg91GgJjQ== Date: Sat, 21 Mar 2015 20:29:12 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFCD93CE6CA@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Dots] DOTS Description X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for 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, 21 Mar 2015 20:29:21 -0000 Hello! >From the BOF summary page [1], the DOTS description is as follows: "There is a need for a standards based approach for on-premise DDoS mitigat= ion devices to communicate threat and telemetry data to service provider ba= sed solutions. On-premise DDoS mitigation devices are sophisticated entitie= s which may already identify, profile and mitigate a wide range of attacks.= Although flow export, syslog and SNMP are currently used by service provid= ers to identify anomalies, there is no agreed standard allowing for any dev= ice to signal to any other device or service provider what the anomaly is a= nd the subsequent threat telemetry data.=20 DDoS open threat signaling (DOTS) would enable any on-premise DDoS mitigati= on device to effectively communicate the current threat landscape, load and= response data to a mitigation service provider. The upstream solution woul= d then have a clear view of the threat should the on-premise solution be re= quired to offramp attack traffic to a more capable handler. A vendor agnost= ic approach would allow any combination of vendor, service provider or comm= unity driven efforts to interoperate. DOTS would be extensible and may, in = future, be expanded as a method of real time information exchange between o= ther security devices and, potentially across organizations. Verisign and Juniper have supported this work on standardized DOTS, and thi= s work has resulted in an input specification for this proposed non-working= group forming BOF." Roman [1] http://tools.ietf.org/bof/trac/ From nobody Sat Mar 21 13:40: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 0823F1A8A8D for ; Sat, 21 Mar 2015 13:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.012 X-Spam-Level: X-Spam-Status: No, score=-1.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=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 fJWn8Ll6CDy5 for ; Sat, 21 Mar 2015 13:39:58 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C03A1A8923 for ; Sat, 21 Mar 2015 13:39:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=To:References:Message-Id:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=anLwZls5lqcZ685OZOEYgWix/xNLLOlnIuvwZKU1sC8=; b=tdMqZISo/GEDDUELgosG7N/+N8R7KkKacYOtXkAXwOElqCLXCtfCBxhr3aQ2gYWdyb5dh5JIAqDZW3Gfk1+KfBRoOL3QPrdUobQRtLtpevXLBF1HXgpOp3ebbebZBatcsEjeRs/fQiemkIiLKuCOABJVoeT+6+0eDZxUecDcWVc=; Received: from ip68-100-197-30.dc.dc.cox.net ([68.100.197.30]:53503 helo=[192.168.15.136]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1YZQBS-0008Nz-W3 for dots@ietf.org; Sat, 21 Mar 2015 13:39:54 -0700 Content-Type: multipart/signed; boundary="Apple-Mail=_3C3EE4A1-7FEB-4963-99C9-3FC9BE61250E"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Pgp-Agent: GPGMail 2.5b6 From: Eric Burger In-Reply-To: <359EC4B99E040048A7131E0F4E113AFCD93CE6CA@marathon> Date: Sat, 21 Mar 2015 16:39:51 -0400 Message-Id: <130DACED-0A48-4E93-9EC8-19B8FFFBDEEB@standardstrack.com> References: <359EC4B99E040048A7131E0F4E113AFCD93CE6CA@marathon> To: "dots@ietf.org" X-Mailer: Apple Mail (2.2070.6) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed Archived-At: Subject: Re: [Dots] DOTS Description X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for 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, 21 Mar 2015 20:39:59 -0000 --Apple-Mail=_3C3EE4A1-7FEB-4963-99C9-3FC9BE61250E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Conceptually, why not IODEF? Do we need something lighter weight coming = from devices instead of CERTs, or is there more? > On Mar 21, 2015, at 4:29 PM, Roman D. Danyliw wrote: >=20 > Hello! >=20 >> =46rom the BOF summary page [1], the DOTS description is as follows: >=20 > "There is a need for a standards based approach for on-premise DDoS = mitigation devices to communicate threat and telemetry data to service = provider based solutions. On-premise DDoS mitigation devices are = sophisticated entities which may already identify, profile and mitigate = a wide range of attacks. Although flow export, syslog and SNMP are = currently used by service providers to identify anomalies, there is no = agreed standard allowing for any device to signal to any other device or = service provider what the anomaly is and the subsequent threat telemetry = data. >=20 > DDoS open threat signaling (DOTS) would enable any on-premise DDoS = mitigation device to effectively communicate the current threat = landscape, load and response data to a mitigation service provider. The = upstream solution would then have a clear view of the threat should the = on-premise solution be required to offramp attack traffic to a more = capable handler. A vendor agnostic approach would allow any combination = of vendor, service provider or community driven efforts to interoperate. = DOTS would be extensible and may, in future, be expanded as a method of = real time information exchange between other security devices and, = potentially across organizations. >=20 > Verisign and Juniper have supported this work on standardized DOTS, = and this work has resulted in an input specification for this proposed = non-working group forming BOF." >=20 > Roman >=20 > [1] http://tools.ietf.org/bof/trac/ >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots --Apple-Mail=_3C3EE4A1-7FEB-4963-99C9-3FC9BE61250E 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----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVDdcXAAoJEDY/T2tCIPW3Jj0P/i9QDP+XMwwgJNYIOwZ/egEl wXTHZF2MxrjNnacG3aQR6mYb3KkEh4HxL1nYwPb1LjI8BYjipZig58l4u8QFq39a gJNoGchzX2tai0Uy1KMd/wXAPpicrUzsA3ZTfeq/aBIlsIarHWUzng6ThMxLd63f XoDSLUrhc0ryXujxqMiPQJTg0ER1IQVW/yAbEICcgei/5SqlmJpDz4eYUODXCyey U4q3iakyYsq7S6BAxKdNdmWKj8DPNvfxlsIc2X2rTc6z7lAbayf2tB7Rlefgps+l V/HB/qS6Yyqu+latuQduxu/CKKXe9ZVGpwdc5MBFoxI7a2vhtRnh99sAOD9iKtU/ O3Toa5N25tOH/a5xnbkIvtWMAU3+b/bHGBvO+Fc9S83tnNXMPTqNB8Oj3IWwKnH8 +p2MWcjpBMxT5DngLhNorNbOF2fuYdcEPkHEvH+cIYaboJPeZ5lAZ0XoYZTcszkH 3i7pwbxI4BTzi5AOp7LBjPkB4o3WIFzxUONGVZefY5aChxeuogoHS1JVm3D4FFrM Hkrjc0z/TFVcriSs8Iz406eWF3tr23RyOEGYNOD/f9LvJsFz2DAsOai/gXsgX40Y IovCvd4A1RP/beP+VPfj43vKDU6OIb4H4hAfTUfn27xoJvnOOBzTbZT8wDmlVW3W muoFY5+bLNeXajVBznAM =Bmdj -----END PGP SIGNATURE----- --Apple-Mail=_3C3EE4A1-7FEB-4963-99C9-3FC9BE61250E-- From nobody Sat Mar 21 13:43: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 0AB0B1A8AB6 for ; Sat, 21 Mar 2015 13:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tAtjCIgBD6zi for ; Sat, 21 Mar 2015 13:43:19 -0700 (PDT) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E9091A8A98 for ; Sat, 21 Mar 2015 13:43:19 -0700 (PDT) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by shetland.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id t2LKhIQ9020546 for ; Sat, 21 Mar 2015 16:43:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1426970598; bh=libqIyY4qXqWimNZvqG4WLfLTuIFxkQqi9803RUvOZA=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version:Sender:Reply-To:Cc: In-Reply-To:References; b=OfewtLeizQNFsoovayIKKoEHq4IcD0w4jnOK5gAzPiqVMR+k2H1yQ99su1yYJM2Kh xQmUOwY8hcg/gwUaJ7TfsV224/USerWFP2cGp1jz/BNO5fEtFqp/YA2ICc3Mjr1MIB D7hobeeeDAW308KagYDjFBMdYtImx3W+LSgdUeUY= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by timber.sei.cmu.edu (8.14.4/8.14.4/1456) with ESMTP id t2LKhGHR030337 for ; Sat, 21 Mar 2015 16:43:16 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0210.002; Sat, 21 Mar 2015 16:43:16 -0400 From: "Roman D. Danyliw" To: "'dots@ietf.org'" Thread-Topic: Prior discussion about draft-fu-ipfix-network-security-00 Thread-Index: AdBkFsVqG194KPXTRmOmHM/JVOfdOQ== Date: Sat, 21 Mar 2015 20:43:15 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFCD93CE74F@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Dots] Prior discussion about draft-fu-ipfix-network-security-00 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for 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, 21 Mar 2015 20:43:21 -0000 Hello! Two formal drafts will be part of the agenda [1] at the DOTS BOF, draft-tea= gue-open-threat-signaling-00 [2] and draft-fu-ipfix-network-security-00 [3]= . Discussion about the former (draft-teague-open-threat-signaling-00) alre= ady started on the DOTS list [4]. I wanted to provide a pointer to prior = discussions about the latter draft (draft-fu-ipfix-network-security-00) tha= t were on the IPFIX list [5] in December 2014. Regards. Roman [1] http://www.ietf.org/mail-archive/web/dots/current/msg00003.html [2] https://tools.ietf.org/html/draft-teague-open-threat-signaling-00 [3] https://tools.ietf.org/html/draft-fu-ipfix-network-security-00 [4] http://www.ietf.org/mail-archive/web/dots/current/msg00002.html=20 [5] http://www.ietf.org/mail-archive/web/ipfix/current/msg07277.html From nobody Sat Mar 21 20:07: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 E295A1A0158 for ; Sat, 21 Mar 2015 20:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ca5rW4fGEbYL for ; Sat, 21 Mar 2015 20:07:07 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC6541A016B for ; Sat, 21 Mar 2015 20:07:06 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQO30598; Sun, 22 Mar 2015 03:07:05 +0000 (GMT) Received: from SZXEML431-HUB.china.huawei.com (10.82.67.208) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 22 Mar 2015 03:07:03 +0000 Received: from szxeml557-mbs.china.huawei.com ([169.254.6.131]) by szxeml431-hub.china.huawei.com ([10.82.67.208]) with mapi id 14.03.0158.001; Sun, 22 Mar 2015 11:07:00 +0800 From: "Hedanping (Ana)" To: "Roman D. Danyliw" , "'dots@ietf.org'" Thread-Topic: Prior discussion about draft-fu-ipfix-network-security-00 Thread-Index: AdBkFsVqG194KPXTRmOmHM/JVOfdOQANd7yw Date: Sun, 22 Mar 2015 03:06:59 +0000 Message-ID: <77FA386512F0D748BC7C02C36EB1106D954474@szxeml557-mbs.china.huawei.com> References: <359EC4B99E040048A7131E0F4E113AFCD93CE74F@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFCD93CE74F@marathon> Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.157.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Dots] Prior discussion about draft-fu-ipfix-network-security-00 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for 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, 22 Mar 2015 03:07:09 -0000 Hi Roman, Do you mean to shift the slot of draft-fu-ipfix-network-security-00 prior t= o draft-teague-open-threat-signaling-00? If that's the case, I have no problem. Regards, Ana > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Roman D. Danyliw > Sent: Sunday, March 22, 2015 4:43 AM > To: 'dots@ietf.org' > Subject: [Dots] Prior discussion about draft-fu-ipfix-network-security-= 00 >=20 > Hello! >=20 > Two formal drafts will be part of the agenda [1] at the DOTS BOF, > draft-teague-open-threat-signaling-00 [2] and > draft-fu-ipfix-network-security-00 [3]. Discussion about the former > (draft-teague-open-threat-signaling-00) already started on the DOTS lis= t [4]. > I wanted to provide a pointer to prior discussions about the latter dr= aft > (draft-fu-ipfix-network-security-00) that were on the IPFIX list [5] in > December 2014. >=20 > Regards. > Roman >=20 > [1] http://www.ietf.org/mail-archive/web/dots/current/msg00003.html > [2] https://tools.ietf.org/html/draft-teague-open-threat-signaling-00 > [3] https://tools.ietf.org/html/draft-fu-ipfix-network-security-00 > [4] http://www.ietf.org/mail-archive/web/dots/current/msg00002.html > [5] http://www.ietf.org/mail-archive/web/ipfix/current/msg07277.html >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Sun Mar 22 05:45: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 C9E831A909B for ; Sun, 22 Mar 2015 05:45:40 -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 zmPs5KFAWjIx for ; Sun, 22 Mar 2015 05:45:35 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 265B11A9096 for ; Sun, 22 Mar 2015 05:45:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 0A0405FA46; Sun, 22 Mar 2015 08:45:34 -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 onmM+x22yyhz; Sun, 22 Mar 2015 08:45:25 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (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 7D51B5FA45; Sun, 22 Mar 2015 08:45:23 -0400 (EDT) Message-ID: <550EB95E.70209@htt-consult.com> Date: Sun, 22 Mar 2015 08:45:18 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Eric Burger , "dots@ietf.org" References: <359EC4B99E040048A7131E0F4E113AFCD93CE6CA@marathon> <130DACED-0A48-4E93-9EC8-19B8FFFBDEEB@standardstrack.com> In-Reply-To: <130DACED-0A48-4E93-9EC8-19B8FFFBDEEB@standardstrack.com> Content-Type: multipart/alternative; boundary="------------080902070805010103030305" Archived-At: Subject: Re: [Dots] DOTS Description X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for 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, 22 Mar 2015 12:45:41 -0000 This is a multi-part message in MIME format. --------------080902070805010103030305 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Do you mean ligher weight in terms of the protocol or the data modeling? On 03/21/2015 04:39 PM, Eric Burger wrote: > Conceptually, why not IODEF? Do we need something lighter weight coming from devices instead of CERTs, or is there more? > >> On Mar 21, 2015, at 4:29 PM, Roman D. Danyliw wrote: >> >> Hello! >> >>> From the BOF summary page [1], the DOTS description is as follows: >> "There is a need for a standards based approach for on-premise DDoS mitigation devices to communicate threat and telemetry data to service provider based solutions. On-premise DDoS mitigation devices are sophisticated entities which may already identify, profile and mitigate a wide range of attacks. Although flow export, syslog and SNMP are currently used by service providers to identify anomalies, there is no agreed standard allowing for any device to signal to any other device or service provider what the anomaly is and the subsequent threat telemetry data. >> >> DDoS open threat signaling (DOTS) would enable any on-premise DDoS mitigation device to effectively communicate the current threat landscape, load and response data to a mitigation service provider. The upstream solution would then have a clear view of the threat should the on-premise solution be required to offramp attack traffic to a more capable handler. A vendor agnostic approach would allow any combination of vendor, service provider or community driven efforts to interoperate. DOTS would be extensible and may, in future, be expanded as a method of real time information exchange between other security devices and, potentially across organizations. >> >> Verisign and Juniper have supported this work on standardized DOTS, and this work has resulted in an input specification for this proposed non-working group forming BOF." >> >> Roman >> >> [1] http://tools.ietf.org/bof/trac/ >> >> _______________________________________________ >> 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 --------------080902070805010103030305 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit Do you mean ligher weight in terms of the protocol or the data modeling?

On 03/21/2015 04:39 PM, Eric Burger wrote:
Conceptually, why not IODEF? Do we need something lighter weight coming from devices instead of CERTs, or is there more?


On Mar 21, 2015, at 4:29 PM, Roman D. Danyliw <rdd@cert.org> wrote:

Hello!


From the BOF summary page [1], the DOTS description is as follows:

"There is a need for a standards based approach for on-premise DDoS mitigation devices to communicate threat and telemetry data to service provider based solutions. On-premise DDoS mitigation devices are sophisticated entities which may already identify, profile and mitigate a wide range of attacks. Although flow export, syslog and SNMP are currently used by service providers to identify anomalies, there is no agreed standard allowing for any device to signal to any other device or service provider what the anomaly is and the subsequent threat telemetry data.

DDoS open threat signaling (DOTS) would enable any on-premise DDoS mitigation device to effectively communicate the current threat landscape, load and response data to a mitigation service provider. The upstream solution would then have a clear view of the threat should the on-premise solution be required to offramp attack traffic to a more capable handler. A vendor agnostic approach would allow any combination of vendor, service provider or community driven efforts to interoperate. DOTS would be extensible and may, in future, be expanded as a method of real time information exchange between other security devices and, potentially across organizations.

Verisign and Juniper have supported this work on standardized DOTS, and this work has resulted in an input specification for this proposed non-working group forming BOF."

Roman

[1] http://tools.ietf.org/bof/trac/

_______________________________________________
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


    

    

  


--------------080902070805010103030305--


From nobody Sun Mar 22 05:47:52 2015
Return-Path: 
X-Original-To: dots@ietfa.amsl.com
Delivered-To: dots@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDBDA1A90A1 for ; Sun, 22 Mar 2015 05:47:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level: 
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cb3leQNh7s91 for ; Sun, 22 Mar 2015 05:47:48 -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 78E471A9096 for ; Sun, 22 Mar 2015 05:47:48 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id DB4A95FA46; Sun, 22 Mar 2015 08:47:46 -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 3BXAHLBpvj1G; Sun, 22 Mar 2015 08:47:42 -0400 (EDT)
Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (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 6F71E5FA45; Sun, 22 Mar 2015 08:47:38 -0400 (EDT)
Message-ID: <550EB9E6.1060200@htt-consult.com>
Date: Sun, 22 Mar 2015 08:47:34 -0400
From: Robert Moskowitz 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: "Roman D. Danyliw" , "'dots@ietf.org'" 
References: <359EC4B99E040048A7131E0F4E113AFCD93CE74F@marathon>
In-Reply-To: <359EC4B99E040048A7131E0F4E113AFCD93CE74F@marathon>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Dots] Prior discussion about draft-fu-ipfix-network-security-00
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "List for 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, 22 Mar 2015 12:47:50 -0000

Can you check with the list serve people as to why there is not a 
downloadable form for the list as other IETF lists?  Granted I only 
missed a few, but I like to have them all in my local folder.

On 03/21/2015 04:43 PM, Roman D. Danyliw wrote:
> Hello!
>
> Two formal drafts will be part of the agenda [1] at the DOTS BOF, draft-teague-open-threat-signaling-00 [2] and draft-fu-ipfix-network-security-00 [3].  Discussion about the former (draft-teague-open-threat-signaling-00) already started on the DOTS list [4].  I wanted  to provide a pointer to prior discussions about the latter draft (draft-fu-ipfix-network-security-00) that were on the IPFIX list [5] in December 2014.
>
> Regards.
> Roman
>
> [1] http://www.ietf.org/mail-archive/web/dots/current/msg00003.html
> [2] https://tools.ietf.org/html/draft-teague-open-threat-signaling-00
> [3] https://tools.ietf.org/html/draft-fu-ipfix-network-security-00
> [4] http://www.ietf.org/mail-archive/web/dots/current/msg00002.html
> [5] http://www.ietf.org/mail-archive/web/ipfix/current/msg07277.html
>
> _______________________________________________
> Dots mailing list
> Dots@ietf.org
> https://www.ietf.org/mailman/listinfo/dots


From nobody Sun Mar 22 05:52: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 2D6A61A90A2 for ; Sun, 22 Mar 2015 05:52:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.011
X-Spam-Level: 
X-Spam-Status: No, score=-1.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=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 KT2FSH0b7zeb for ; Sun, 22 Mar 2015 05:52:05 -0700 (PDT)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 791AD1A90A1 for ; Sun, 22 Mar 2015 05:52:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default;  h=To:Date:Subject:From:Cc:Message-Id:Content-Transfer-Encoding:Content-Type:In-Reply-To:Mime-Version:References; bh=wDcixzTqgY2/uOHjU+kGZCVC5ALEENAO3Q7RNXvxcc8=;  b=mv6e6PzZt5k32HHYdT35///PX5xkr72K4eWBHLiKO2yB7Qfb2cfE458EKtQbk/dFBhmlobTVr5ABy/Q1FKrQ9jONgxQ7OIYp5j7Grt6VBJ0IMqIVVHbAVa0JzgEPsdbQCcArzlbxJwTatbmEYStJj3nWKvB8D6IuJpSyqP5diK4=;
Received: from ip68-100-197-30.dc.dc.cox.net ([68.100.197.30]:53463 helo=[192.168.15.144]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1YZfMG-0001bP-4h; Sun, 22 Mar 2015 05:52:04 -0700
References: <359EC4B99E040048A7131E0F4E113AFCD93CE6CA@marathon> <130DACED-0A48-4E93-9EC8-19B8FFFBDEEB@standardstrack.com> <550EB95E.70209@htt-consult.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <550EB95E.70209@htt-consult.com>
Content-Type: multipart/alternative; boundary=Apple-Mail-902A3B5F-2F60-4313-A97A-16181526A635
Content-Transfer-Encoding: 7bit
Message-Id: 
X-Mailer: iPad Mail (12D508)
From: Eric Burger 
Date: Sun, 22 Mar 2015 08:51:58 -0400
To: Robert Moskowitz 
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
Archived-At: 
Cc: "dots@ietf.org" 
Subject: Re: [Dots] DOTS Description
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "List for 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, 22 Mar 2015 12:52:07 -0000

--Apple-Mail-902A3B5F-2F60-4313-A97A-16181526A635
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Either or both.

--
Sent from a mobile device. Sorry for typos or weird auto-correct. Thank IETF=
 LEMONADE for mobile email! See 

> On Mar 22, 2015, at 8:45 AM, Robert Moskowitz  wr=
ote:
>=20
> Do you mean ligher weight in terms of the protocol or the data modeling?
>=20
>> On 03/21/2015 04:39 PM, Eric Burger wrote:
>> Conceptually, why not IODEF? Do we need something lighter weight coming f=
rom devices instead of CERTs, or is there more?
>>=20
>>>> On Mar 21, 2015, at 4:29 PM, Roman D. Danyliw  wrote:
>>>>=20
>>>> Hello!
>>>>=20
>>>> =46rom the BOF summary page [1], the DOTS description is as follows:
>>> "There is a need for a standards based approach for on-premise DDoS miti=
gation devices to communicate threat and telemetry data to service provider b=
ased solutions. On-premise DDoS mitigation devices are sophisticated entitie=
s which may already identify, profile and mitigate a wide range of attacks. A=
lthough flow export, syslog and SNMP are currently used by service providers=
 to identify anomalies, there is no agreed standard allowing for any device t=
o signal to any other device or service provider what the anomaly is and the=
 subsequent threat telemetry data.
>>>=20
>>> DDoS open threat signaling (DOTS) would enable any on-premise DDoS mitig=
ation device to effectively communicate the current threat landscape, load a=
nd response data to a mitigation service provider. The upstream solution wou=
ld then have a clear view of the threat should the on-premise solution be re=
quired to offramp attack traffic to a more capable handler. A vendor agnosti=
c approach would allow any combination of vendor, service provider or commun=
ity driven efforts to interoperate. DOTS would be extensible and may, in fut=
ure, be expanded as a method of real time information exchange between other=
 security devices and, potentially across organizations.
>>>=20
>>> Verisign and Juniper have supported this work on standardized DOTS, and t=
his work has resulted in an input specification for this proposed non-workin=
g group forming BOF."
>>>=20
>>> Roman
>>>=20
>>> [1] http://tools.ietf.org/bof/trac/
>>>=20
>>> _______________________________________________
>>> Dots mailing list
>>> Dots@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dots
>>=20
>>=20
>> _______________________________________________
>> Dots mailing list
>> Dots@ietf.org
>> https://www.ietf.org/mailman/listinfo/dots
>=20

--Apple-Mail-902A3B5F-2F60-4313-A97A-16181526A635
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: 7bit


Either or both.

--
Sent from a mobile device. Sorry for typos or weird auto-correct. Thank IETF LEMONADE for mobile email! See <http://www.standardstrack.com/ietf/lemonade/>

On Mar 22, 2015, at 8:45 AM, Robert Moskowitz <rgm-sec@htt-consult.com> wrote:


  
    
  
  
    Do you mean ligher weight in terms of the protocol or the data
    modeling?

    

    
On 03/21/2015 04:39 PM, Eric Burger
      wrote:

    

    

      
Conceptually, why not IODEF? Do we need something lighter weight coming from devices instead of CERTs, or is there more?



      

        
On Mar 21, 2015, at 4:29 PM, Roman D. Danyliw <rdd@cert.org> wrote:

Hello!



        

          
From the BOF summary page [1], the DOTS description is as follows:


        

        
"There is a need for a standards based approach for on-premise DDoS mitigation devices to communicate threat and telemetry data to service provider based solutions. On-premise DDoS mitigation devices are sophisticated entities which may already identify, profile and mitigate a wide range of attacks. Although flow export, syslog and SNMP are currently used by service providers to identify anomalies, there is no agreed standard allowing for any device to signal to any other device or service provider what the anomaly is and the subsequent threat telemetry data.

DDoS open threat signaling (DOTS) would enable any on-premise DDoS mitigation device to effectively communicate the current threat landscape, load and response data to a mitigation service provider. The upstream solution would then have a clear view of the threat should the on-premise solution be required to offramp attack traffic to a more capable handler. A vendor agnostic approach would allow any combination of vendor, service provider or community driven efforts to interoperate. DOTS would be extensible and may, in future, be expanded as a method of real time information exchange between other security devices and, potentially across organizations.

Verisign and Juniper have supported this work on standardized DOTS, and this work has resulted in an input specification for this proposed non-working group forming BOF."

Roman

[1] http://tools.ietf.org/bof/trac/

_______________________________________________
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


    

    

  



--Apple-Mail-902A3B5F-2F60-4313-A97A-16181526A635--


From nobody Sun Mar 22 05:53: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 9DB561A90A8 for ; Sun, 22 Mar 2015 05:53:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.012
X-Spam-Level: 
X-Spam-Status: No, score=-1.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=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 OCrS5eoJc68p for ; Sun, 22 Mar 2015 05:53:50 -0700 (PDT)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6BB91A90A7 for ; Sun, 22 Mar 2015 05:53:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default;  h=To:Date:Subject:From:Cc:Message-Id:Content-Transfer-Encoding:Content-Type:In-Reply-To:Mime-Version:References; bh=QzTUOAng9xlA0sWNiNCL8lfcnKTZ+tn5aBctEM2SgvE=;  b=Jr3Hg8IxbYHOYiMgO29zXQ8evZnN4mxYF5G5376eWM/rurNTszX/nFKpObPS6/AaS9k28j4UT0qekvqTH+v8l11B2vkJN57vewBvVvSw0zs4+F+UJLoT8Q51rrggS+zQwV/cZJPArPINw/VhHPifW+UBB+dcw/y7Egu1GBv14JQ=;
Received: from ip68-100-197-30.dc.dc.cox.net ([68.100.197.30]:53465 helo=[192.168.15.144]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1YZfO0-0003hC-Ia; Sun, 22 Mar 2015 05:53:49 -0700
References: <359EC4B99E040048A7131E0F4E113AFCD93CE74F@marathon> <550EB9E6.1060200@htt-consult.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <550EB9E6.1060200@htt-consult.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: 
X-Mailer: iPad Mail (12D508)
From: Eric Burger 
Date: Sun, 22 Mar 2015 08:53:47 -0400
To: Robert Moskowitz 
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
Archived-At: 
Cc: "Roman D. Danyliw" , "dots@ietf.org" 
Subject: [Dots] DOTS List
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "List for 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, 22 Mar 2015 12:53:51 -0000

Last I looked, there were two real messages and a handful of welcome to the l=
ist messages. If there are more, I would be interested, too.

--
Sent from a mobile device. Sorry for typos or weird auto-correct. Thank IETF=
 LEMONADE for mobile email! See 

> On Mar 22, 2015, at 8:47 AM, Robert Moskowitz  wr=
ote:
>=20
> Can you check with the list serve people as to why there is not a download=
able form for the list as other IETF lists?  Granted I only missed a few, bu=
t I like to have them all in my local folder.
>=20
>> On 03/21/2015 04:43 PM, Roman D. Danyliw wrote:
>> Hello!
>>=20
>> Two formal drafts will be part of the agenda [1] at the DOTS BOF, draft-t=
eague-open-threat-signaling-00 [2] and draft-fu-ipfix-network-security-00 [3=
].  Discussion about the former (draft-teague-open-threat-signaling-00) alre=
ady started on the DOTS list [4].  I wanted  to provide a pointer to prior d=
iscussions about the latter draft (draft-fu-ipfix-network-security-00) that w=
ere on the IPFIX list [5] in December 2014.
>>=20
>> Regards.
>> Roman
>>=20
>> [1] http://www.ietf.org/mail-archive/web/dots/current/msg00003.html
>> [2] https://tools.ietf.org/html/draft-teague-open-threat-signaling-00
>> [3] https://tools.ietf.org/html/draft-fu-ipfix-network-security-00
>> [4] http://www.ietf.org/mail-archive/web/dots/current/msg00002.html
>> [5] http://www.ietf.org/mail-archive/web/ipfix/current/msg07277.html
>>=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 Sun Mar 22 06:41: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 7B63F1A90C3 for ; Sun, 22 Mar 2015 06:41:47 -0700 (PDT)
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, DIET_1=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4WRGd0zcuO99 for ; Sun, 22 Mar 2015 06:41:42 -0700 (PDT)
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 882311A90CA for ; Sun, 22 Mar 2015 06:41:42 -0700 (PDT)
Received: by qgdq107 with SMTP id q107so3644931qgd.2 for ; Sun, 22 Mar 2015 06:41:41 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :user-agent:content-type:content-id:content-transfer-encoding :mime-version; bh=LQN3Apv/BI4GEWmXjg/QDpGQgHsOtIIyO2hjfFwTvk8=; b=AqEPH9s3UrI1Ci7HdujZs3JM4/lbt7hc+QxIGlChmedgqAA+JYIJQyq6NEinkN+P/y o5C6+itEJDq1OILG5kD5VrbWZNqTvvtVgbz4ux+Qp2UMEWeZ5ZJuG/0+gw70gLs8HePO VW7UVqLHizp4z4QvBKI391JIabQOxcxziiLMcWcBJEMFU2hzsqVawhJI4kKr29QufVI5 Bmmc+6AZQgGNJsSuEAO+6sFaMRB1l7S5+y0Pmi624o+pJ842F9W7+COW5YhV8uH6UpW3 wyN2XGRBoM0oMby9RFhNEPhR0fSgeU4cKcPy9mqwn2mBoUpAvfCI9lJVJ5/nfC5AKq47 3bmw==
X-Gm-Message-State: ALoCoQmJ9Hq8FKgcCvdl9ZVVfiBGzkbXiciD1bB4igsTrsKv8bFXf6ykvPC9gxIhJ+z2EmX6p2vouzJlv+Z2i7lKXfaAqqFvBA==
X-Received: by 10.55.42.160 with SMTP id q32mr163369837qkq.68.1427031701588; Sun, 22 Mar 2015 06:41:41 -0700 (PDT)
Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by mx.google.com with ESMTPS id l10sm2065101qcs.4.2015.03.22.06.41.40 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 22 Mar 2015 06:41:41 -0700 (PDT)
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 t2MDfePp015629 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 22 Mar 2015 09:41:40 -0400
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Sun, 22 Mar 2015 09:41:40 -0400
From: "Teague, Nik" 
To: Eric Burger , "dots@ietf.org" 
Thread-Topic: [Dots] DOTS Description
Thread-Index: AdBkFWs4ohmWUP7VQNmAGAg91GgJjQAI0myAABk1GYA=
Date: Sun, 22 Mar 2015 13:41:39 +0000
Message-ID: 
References: <359EC4B99E040048A7131E0F4E113AFCD93CE6CA@marathon> <130DACED-0A48-4E93-9EC8-19B8FFFBDEEB@standardstrack.com>
In-Reply-To: <130DACED-0A48-4E93-9EC8-19B8FFFBDEEB@standardstrack.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.8.150116
x-originating-ip: [10.173.152.4]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <92F1111F947F584587B37ABB2E246822@verisign.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Dots] DOTS Description
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "List for 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, 22 Mar 2015 13:41:47 -0000

Hi,

On 21/03/2015 15:39, "Eric Burger"  wrote:

>Conceptually, why not IODEF? Do we need something lighter weight coming
>from devices instead of CERTs, or is there more?

A lighter protocol is desirable in order for DDoS mitigation CPE to
effectively communicate to an external upstream provider when resources
may be at a premium during a large volumetric attack.  These devices are
capable of dealing with many attacks but at some point the attack being
aimed at the protected resource may be simply too large to handle.  Links
will be congested and connectionless light weight signaling at this point
is probably the best way to send up a flare to the provider (and fitting
as much as you can into as few packets as possible).

Various aspects of IODEF that are analogous could be adopted but the XML
representation, in my mind, would add too much extraneous weight to the
signaling channel.  Eg. if templates are already exported via IPFIX then
its unnecessary for the data export to then reference redundant field
identifiers, it just needs to identify the matching template.

Thanks,

-Nik


From nobody Sun Mar 22 07:13: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 138701A90E5 for ; Sun, 22 Mar 2015 07:13:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DIET_1=0.001, 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 lw1S7Y9n5pyt for ; Sun, 22 Mar 2015 07:13:09 -0700 (PDT)
Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::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 9B05D1A90E2 for ; Sun, 22 Mar 2015 07:13:08 -0700 (PDT)
Received: by lbbrr9 with SMTP id rr9so38480684lbb.0 for ; Sun, 22 Mar 2015 07:13:07 -0700 (PDT)
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=tU0/ECdkImovtDFh5wXmeV1T4rse25z/9IpxZJS6Jr8=; b=0osMP+pV10qUlEw3GPIZO+F3mQ/N7NR0jkXJgEywCQNJheTKT1MmNUVbbxDRuX11T3 0nDq3apYggcGpIlw5mV1dOrHdF9p6Hro+GSoRKHpIabBl6dqTmHVYfGPXS6nilcMnpvC k2QyACcjSu4iT38ML67rNleHHo+UysrEPbAijwwVYal+jC5JHNabO9VzkXcAwU9f3JaS vYQLl3RJL+c4zUMTOmX7blcWC0MEWH9eQc7i/1j9HwcsF1udtsuKfuZkV09ISUSJem4t GkpTHypS6ZUGEfJTrPk70i9mlY3EDtF+LNlcAU/9DmxbyLwI0MaBXX0QlIoVtA8QYrzG wgTQ==
MIME-Version: 1.0
X-Received: by 10.152.37.202 with SMTP id a10mr39744454lak.0.1427033587018; Sun, 22 Mar 2015 07:13:07 -0700 (PDT)
Received: by 10.112.167.101 with HTTP; Sun, 22 Mar 2015 07:13:06 -0700 (PDT)
In-Reply-To: 
References: <359EC4B99E040048A7131E0F4E113AFCD93CE6CA@marathon> <130DACED-0A48-4E93-9EC8-19B8FFFBDEEB@standardstrack.com> 
Date: Sun, 22 Mar 2015 10:13:06 -0400
Message-ID: 
From: Kathleen Moriarty 
To: "Teague, Nik" 
Content-Type: multipart/alternative; boundary=089e014940560972750511e126b1
Archived-At: 
Cc: "dots@ietf.org" 
Subject: Re: [Dots] DOTS Description
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "List for 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, 22 Mar 2015 14:13:11 -0000

--089e014940560972750511e126b1
Content-Type: text/plain; charset=UTF-8

With no hat on...

On Sun, Mar 22, 2015 at 9:41 AM, Teague, Nik  wrote:

> Hi,
>
> On 21/03/2015 15:39, "Eric Burger"  wrote:
>
> >Conceptually, why not IODEF? Do we need something lighter weight coming
> >from devices instead of CERTs, or is there more?
>
> A lighter protocol is desirable in order for DDoS mitigation CPE to
> effectively communicate to an external upstream provider when resources
> may be at a premium during a large volumetric attack.  These devices are
> capable of dealing with many attacks but at some point the attack being
> aimed at the protected resource may be simply too large to handle.  Links
> will be congested and connectionless light weight signaling at this point
> is probably the best way to send up a flare to the provider (and fitting
> as much as you can into as few packets as possible).
>
> Various aspects of IODEF that are analogous could be adopted but the XML
> representation, in my mind, would add too much extraneous weight to the
> signaling channel.  Eg. if templates are already exported via IPFIX then
> its unnecessary for the data export to then reference redundant field
> identifiers, it just needs to identify the matching template.
>

I think there are a few other considerations as well.  IPFIX may already be
implemented in devices and is about exchanging flow information.  IPFIX
data might be included in an IODEF message, but wouldn't have called out
explicit indicators or incident data.  IODEF is really designed for
telemetry data int he way that IPFIX is.  I think these can be
complementary and there are ways to create connections between the MILE
work and this proposal with IPFIX.

Thanks,
Kathleen


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



-- 

Best regards,
Kathleen

--089e014940560972750511e126b1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


With no hat on...

On Sun, Mar 22, 2015 at 9:41 AM, Teague, Nik <ntea=
gue@verisign.com> wrote:
Hi=
,



On 21/03/2015 15:39, "Eric Burger" <eburger@standardstrack.com> wrote:



>Conceptually, why not IODEF? Do we need something lighter weight coming=


>from devices instead of CERTs, or is there more?



A lighter protocol is desirable in order for DDoS mitigation CPE to<=
br>
effectively communicate to an external upstream provider when resources

may be at a premium during a large volumetric attack.=C2=A0 These devices a=
re

capable of dealing with many attacks but at some point the attack being

aimed at the protected resource may be simply too large to handle.=C2=A0 Li=
nks

will be congested and connectionless light weight signaling at this point
is probably the best way to send up a flare to the provider (and fitting
as much as you can into as few packets as possible).



Various aspects of IODEF that are analogous could be adopted but the XML
representation, in my mind, would add too much extraneous weight to the

signaling channel.=C2=A0 Eg. if templates are already exported via IPFIX th=
en

its unnecessary for the data export to then reference redundant field

identifiers, it just needs to identify the matching template.

I think there are a few other considerations as well=
.=C2=A0 IPFIX may already be implemented in devices and is about exchanging=
 flow information.=C2=A0 IPFIX data might be included in an IODEF message, =
but wouldn't have called out explicit indicators or incident data.=C2=
=A0 IODEF is really designed for telemetry data int he way that IPFIX is.=
=C2=A0 I think these can be complementary and there are ways to create conn=
ections between the MILE work and this proposal with IPFIX.=C2=A0

Thanks,
Kathleen




Thanks,



-Nik




_______________________________________________

Dots mailing list

Dots@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/dots





-- 
=


Best regards,
Kathleen




--089e014940560972750511e126b1--


From nobody Sun Mar 22 07:20: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 841BA1A9147 for ; Sun, 22 Mar 2015 07:20:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 vKHOSNnDYkVt for ; Sun, 22 Mar 2015 07:20:31 -0700 (PDT)
Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::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 C26F91A911F for ; Sun, 22 Mar 2015 07:20:30 -0700 (PDT)
Received: by lbbsy1 with SMTP id sy1so103041136lbb.1 for ; Sun, 22 Mar 2015 07:20:29 -0700 (PDT)
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=jcUjoa2186CRene8fuYzElAVnNvOsZivk2ZdI6rlDCo=; b=YqnjBeVvztGYQH9NVX3KkCaW7vQwvEOxWY9TQSYpc3tbRt3h3Ey5kaczJH4afwYxA1 vxd0xkEN+ym2dglTDUUxXloAM3itktg+jlcFNyW29Tx2smNPePvEt+hvIA3033oAMoVl jyD+Q6opt+PIk15bAs3EeDjTsAcLG7cnu1uv0W4vwOoxFHsDLIuc9hS4pGMbktj4tpDF 1AgOoDjIe4cziEgokuElrESilBi4kPnByO5wVQheEgX/IHkDQckP9TrU6XXaNNAMaD5A 4Gp5JISqL1Ua1/RYKj7JkOyy0WP7z+4Qb4dpz3kCrq8XKMRQN/IiVYz2vFQcxuKyb3Yw UkOg==
MIME-Version: 1.0
X-Received: by 10.152.228.166 with SMTP id sj6mr10850502lac.113.1427034029269;  Sun, 22 Mar 2015 07:20:29 -0700 (PDT)
Received: by 10.112.167.101 with HTTP; Sun, 22 Mar 2015 07:20:29 -0700 (PDT)
In-Reply-To: 
References: <359EC4B99E040048A7131E0F4E113AFCD93CE74F@marathon> <550EB9E6.1060200@htt-consult.com> 
Date: Sun, 22 Mar 2015 10:20:29 -0400
Message-ID: 
From: Kathleen Moriarty 
To: Eric Burger 
Content-Type: multipart/alternative; boundary=001a1134352c65a8890511e140cd
Archived-At: 
Cc: "Roman D. Danyliw" , "dots@ietf.org" , Robert Moskowitz 
Subject: Re: [Dots] DOTS List
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "List for 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, 22 Mar 2015 14:20:33 -0000

--001a1134352c65a8890511e140cd
Content-Type: text/plain; charset=UTF-8

On Sun, Mar 22, 2015 at 8:53 AM, Eric Burger 
wrote:

> Last I looked, there were two real messages and a handful of welcome to
> the list messages. If there are more, I would be interested, too.
>

Your reviews and feedback to get discussions going are appreciated.  This
BoF request came in at the last minute and is non-WG forming.  SAAG might
have been better, but what you see on the list is it.

Please discuss.  Reviews and comparisons of the two drafts would be helpful.

Thanks,
Kathleen

>
> --
> Sent from a mobile device. Sorry for typos or weird auto-correct. Thank
> IETF LEMONADE for mobile email! See <
> http://www.standardstrack.com/ietf/lemonade/>
>
> > On Mar 22, 2015, at 8:47 AM, Robert Moskowitz 
> wrote:
> >
> > Can you check with the list serve people as to why there is not a
> downloadable form for the list as other IETF lists?  Granted I only missed
> a few, but I like to have them all in my local folder.
> >
> >> On 03/21/2015 04:43 PM, Roman D. Danyliw wrote:
> >> Hello!
> >>
> >> Two formal drafts will be part of the agenda [1] at the DOTS BOF,
> draft-teague-open-threat-signaling-00 [2] and
> draft-fu-ipfix-network-security-00 [3].  Discussion about the former
> (draft-teague-open-threat-signaling-00) already started on the DOTS list
> [4].  I wanted  to provide a pointer to prior discussions about the latter
> draft (draft-fu-ipfix-network-security-00) that were on the IPFIX list [5]
> in December 2014.
> >>
> >> Regards.
> >> Roman
> >>
> >> [1] http://www.ietf.org/mail-archive/web/dots/current/msg00003.html
> >> [2] https://tools.ietf.org/html/draft-teague-open-threat-signaling-00
> >> [3] https://tools.ietf.org/html/draft-fu-ipfix-network-security-00
> >> [4] http://www.ietf.org/mail-archive/web/dots/current/msg00002.html
> >> [5] http://www.ietf.org/mail-archive/web/ipfix/current/msg07277.html
> >>
> >> _______________________________________________
> >> 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
>



-- 

Best regards,
Kathleen

--001a1134352c65a8890511e140cd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



=
On Sun, Mar 22, 2015 at 8:53 AM, Eric Burger <eburger@standardst=
rack.com> wrote:
Last I looked, there w=
ere two real messages and a handful of welcome to the list messages. If the=
re are more, I would be interested, too.

Your reviews and feedback to get discussions going are appreciated.=C2=A0=
 This BoF request came in at the last minute and is non-WG forming.=C2=A0 S=
AAG might have been better, but what you see on the list is it.
<=
br>
Please discuss.=C2=A0 Reviews and comparisons of the two draf=
ts would be helpful.

Thanks,
Kathleen=C2=
=A0



--

Sent from a mobile device. Sorry for typos or weird auto-correct. Thank IET=
F LEMONADE for mobile email! See <http://www.standardstrack.com/ietf/lem=
onade/>



> On Mar 22, 2015, at 8:47 AM, Robert Moskowitz <rgm-sec@htt-consult.com> wrote:

>

> Can you check with the list serve people as to why there is not a down=
loadable form for the list as other IETF lists?=C2=A0 Granted I only missed=
 a few, but I like to have them all in my local folder.

>

>> On 03/21/2015 04:43 PM, Roman D. Danyliw wrote:

>> Hello!

>>

>> Two formal drafts will be part of the agenda [1] at the DOTS BOF, =
draft-teague-open-threat-signaling-00 [2] and draft-fu-ipfix-network-securi=
ty-00 [3].=C2=A0 Discussion about the former (draft-teague-open-threat-sign=
aling-00) already started on the DOTS list [4].=C2=A0 I wanted=C2=A0 to pro=
vide a pointer to prior discussions about the latter draft (draft-fu-ipfix-=
network-security-00) that were on the IPFIX list [5] in December 2014.

>>

>> Regards.

>> Roman

>>

>> [1] http://www.ietf.org/mail-archive/web/dots/c=
urrent/msg00003.html

>> [2] https://tools.ietf.org/html/draft-teague-=
open-threat-signaling-00

>> [3] https://tools.ietf.org/html/draft-fu-ipfix-n=
etwork-security-00

>> [4] http://www.ietf.org/mail-archive/web/dots/c=
urrent/msg00002.html

>> [5] http://www.ietf.org/mail-archive/web/ipfix=
/current/msg07277.html

>>

>> _______________________________________________

>> 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





-- 

Best regards,
Kath=
leen




--001a1134352c65a8890511e140cd--


From nobody Sun Mar 22 18:55: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 88ABE1A875E for ; Sun, 22 Mar 2015 18:55:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9TI1jz5jS5l for ; Sun, 22 Mar 2015 18:55:13 -0700 (PDT)
Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97E451A8762 for ; Sun, 22 Mar 2015 18:55:13 -0700 (PDT)
Received: from pawpaw.sei.cmu.edu (pawpaw.sei.cmu.edu [10.64.21.22]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id t2N1tCtU014838 for ; Sun, 22 Mar 2015 21:55:12 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1427075712; bh=n02BC2mf5yHOKbWhsP5KdRo32oDb1C34BSP6EN5pZzM=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version:Sender: Reply-To:Cc; b=DZXKiKv/IjyHQdDQFcZ3IBVJumZkbrw5uL18TB6ujnKHsNN4qBZB4xWGw4ojR5baI EdslBgvd2TyUnmroSk3rGmBufSPxsCZypo8gV9xGcejtysWiacCTd3eS1+j5lyG1kB E03Mlwf0ZFqo7DYn2YUYJfyOVVejbcTcJq4onAZM=
Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1456) with ESMTP id t2N1tDIE029454 for ; Sun, 22 Mar 2015 21:55:13 -0400
Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0210.002; Sun, 22 Mar 2015 21:55:09 -0400
From: "Roman D. Danyliw" 
To: "dots@ietf.org" 
Thread-Topic: [Dots] Prior discussion about draft-fu-ipfix-network-security-00
Thread-Index: AdBkFsVqG194KPXTRmOmHM/JVOfdOQAqR+8AABLRte0=
Date: Mon, 23 Mar 2015 01:55:08 +0000
Message-ID: <359EC4B99E040048A7131E0F4E113AFCD93CF22D@marathon>
References: <359EC4B99E040048A7131E0F4E113AFCD93CE74F@marathon>, <550EB9E6.1060200@htt-consult.com>
In-Reply-To: <550EB9E6.1060200@htt-consult.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.64.22.6]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: [Dots] FW: Prior discussion about draft-fu-ipfix-network-security-00
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "List for 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, 23 Mar 2015 01:55:15 -0000

Hello!

To those that might be in the same situation, Robert Moskwitz tracked down =
that the place to download messages has moved.  Please now go to http://www=
.ietf.org/mail-archive/text/dots/. =20

Roman

________________________________________
From: Robert Moskowitz [rgm-sec@htt-consult.com]
Sent: Sunday, March 22, 2015 8:47 AM
To: Roman D. Danyliw; 'dots@ietf.org'
Subject: Re: [Dots] Prior discussion about draft-fu-ipfix-network-security-=
00

Can you check with the list serve people as to why there is not a
downloadable form for the list as other IETF lists?  Granted I only
missed a few, but I like to have them all in my local folder.

On 03/21/2015 04:43 PM, Roman D. Danyliw wrote:
> Hello!
>
> Two formal drafts will be part of the agenda [1] at the DOTS BOF, draft-t=
eague-open-threat-signaling-00 [2] and draft-fu-ipfix-network-security-00 [=
3].  Discussion about the former (draft-teague-open-threat-signaling-00) al=
ready started on the DOTS list [4].  I wanted  to provide a pointer to prio=
r discussions about the latter draft (draft-fu-ipfix-network-security-00) t=
hat were on the IPFIX list [5] in December 2014.
>
> Regards.
> Roman
>
> [1] http://www.ietf.org/mail-archive/web/dots/current/msg00003.html
> [2] https://tools.ietf.org/html/draft-teague-open-threat-signaling-00
> [3] https://tools.ietf.org/html/draft-fu-ipfix-network-security-00
> [4] http://www.ietf.org/mail-archive/web/dots/current/msg00002.html
> [5] http://www.ietf.org/mail-archive/web/ipfix/current/msg07277.html
>
> _______________________________________________
> Dots mailing list
> Dots@ietf.org
> https://www.ietf.org/mailman/listinfo/dots=


From nobody Sun Mar 22 18:58: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 323B61A8761 for ; Sun, 22 Mar 2015 18:58:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWCc7xHVqOyv for ; Sun, 22 Mar 2015 18:58:12 -0700 (PDT)
Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20E431A875E for ; Sun, 22 Mar 2015 18:58:12 -0700 (PDT)
Received: from pawpaw.sei.cmu.edu (pawpaw.sei.cmu.edu [10.64.21.22]) by shetland.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id t2N1w8dU009403; Sun, 22 Mar 2015 21:58:08 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1427075888; bh=Ex3+KzvV0xxHMRn/2IiHGEHJui+qX40UPmtNC5dCdbY=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version:Sender: Reply-To:Cc; b=HFuaFOG5tKbTFPwViF+qiZWnfAYtP5N9VU8JiJDOuc6ZuJHOA+fzqcbeFsD2CUfir P2r9WB2RKKEGdw/Gcr0+Et3+Whptigh1MIdxjotZQeXVrBaRpN5VwxAqMDMuDZCumi fClZcCCe8x6fo9Qnzx9mMJuW560Hg1KBGBGTP/eA=
Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1456) with ESMTP id t2N1wBpG029663; Sun, 22 Mar 2015 21:58:11 -0400
Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0210.002; Sun, 22 Mar 2015 21:58:06 -0400
From: "Roman D. Danyliw" 
To: "Hedanping (Ana)" , "'dots@ietf.org'" 
Thread-Topic: Prior discussion about draft-fu-ipfix-network-security-00
Thread-Index: AdBkFsVqG194KPXTRmOmHM/JVOfdOQANd7ywAC/zqgw=
Date: Mon, 23 Mar 2015 01:58:06 +0000
Message-ID: <359EC4B99E040048A7131E0F4E113AFCD93CF276@marathon>
References: <359EC4B99E040048A7131E0F4E113AFCD93CE74F@marathon>, <77FA386512F0D748BC7C02C36EB1106D954474@szxeml557-mbs.china.huawei.com>
In-Reply-To: <77FA386512F0D748BC7C02C36EB1106D954474@szxeml557-mbs.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.64.22.6]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Dots] Prior discussion about draft-fu-ipfix-network-security-00
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "List for 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, 23 Mar 2015 01:58:14 -0000

Hello Ana!

Nothing got shifted.  The current draft agenda of the following still stand=
s:

1. Note well, logistics, agenda bashing, introduction of BOF (chairs, 10 mi=
n)
2. draft-teague-open-threat-signaling-00 (Nik Teague, 20 min)
3. draft-fu-ipfix-network-security-00 (Ana Hedanping, 15 min)
4. Panel discussion on suitability (40 min)
5. Further discussion (30 min)
6. Closing (chairs/AD, 5 min)

Sorry for any confusion.

Thanks,
Roman

________________________________________
From: Hedanping (Ana) [ana.hedanping@huawei.com]
Sent: Saturday, March 21, 2015 11:06 PM
To: Roman D. Danyliw; 'dots@ietf.org'
Subject: RE: Prior discussion about draft-fu-ipfix-network-security-00

Hi Roman,
Do you mean to shift the slot of draft-fu-ipfix-network-security-00 prior t=
o draft-teague-open-threat-signaling-00?
If that's the case, I have no problem.

Regards,
Ana

  > -----Original Message-----
  > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Roman D. Danyliw
  > Sent: Sunday, March 22, 2015 4:43 AM
  > To: 'dots@ietf.org'
  > Subject: [Dots] Prior discussion about draft-fu-ipfix-network-security-=
00
  >
  > Hello!
  >
  > Two formal drafts will be part of the agenda [1] at the DOTS BOF,
  > draft-teague-open-threat-signaling-00 [2] and
  > draft-fu-ipfix-network-security-00 [3].  Discussion about the former
  > (draft-teague-open-threat-signaling-00) already started on the DOTS lis=
t [4].
  > I wanted  to provide a pointer to prior discussions about the latter dr=
aft
  > (draft-fu-ipfix-network-security-00) that were on the IPFIX list [5] in
  > December 2014.
  >
  > Regards.
  > Roman
  >
  > [1] http://www.ietf.org/mail-archive/web/dots/current/msg00003.html
  > [2] https://tools.ietf.org/html/draft-teague-open-threat-signaling-00
  > [3] https://tools.ietf.org/html/draft-fu-ipfix-network-security-00
  > [4] http://www.ietf.org/mail-archive/web/dots/current/msg00002.html
  > [5] http://www.ietf.org/mail-archive/web/ipfix/current/msg07277.html
  >
  > _______________________________________________
  > Dots mailing list
  > Dots@ietf.org
  > https://www.ietf.org/mailman/listinfo/dots=


From nobody Mon Mar 23 14:41: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 E65851B2A9A for ; Mon, 23 Mar 2015 14:41:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.737
X-Spam-Level: ***
X-Spam-Status: No, score=3.737 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439, 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 jCqN6XuyGzsn for ; Mon, 23 Mar 2015 14:41:49 -0700 (PDT)
Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:df0:232:300::1]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA35C1B29BB for ; Mon, 23 Mar 2015 14:41:48 -0700 (PDT)
Received: from gw1.nict.go.jp (gw1.nict.go.jp [133.243.18.250]) by ns1.nict.go.jp  with ESMTP id t2NLfgpj002163; Tue, 24 Mar 2015 06:41:42 +0900 (JST)
Received: from takeAsus (ssh.nict.go.jp [133.243.3.49]) by gw1.nict.go.jp  with SMTP id t2NLfdMo002160; Tue, 24 Mar 2015 06:41:40 +0900 (JST)
Message-ID: <358188D97DBE45F787E97C9E29B1C0A3@takeAsus>
From: "Takeshi Takahashi" 
To: "Takeshi Takahashi" , "Roman D. Danyliw" , 
Date: Mon, 23 Mar 2015 22:41:46 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 16.4.3528.331
X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331
X-Virus-Scanned: clamav-milter 0.98.5 at zenith1
X-Virus-Status: Clean
Archived-At: 
Cc: tt2@rc5.so-net.ne.jp
Subject: Re: [Dots] FW: Prior discussion about draft-fu-ipfix-network-security-00
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "List for 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, 23 Mar 2015 21:41:51 -0000

Hello all,

Let me post two comments on draft-fu-ipfix-network-security.

1. XML representation

I am wondering if the draft could addrss the XML representation of the data
elements.
I understand that sometimes people (including myself) wish to avoid using
XML, but it would be beneficial if IODEF can use the data elements listed in
the draft.
The data elements listed in Section 3.1 could be also represented in XML.

IODEF  and IODEF-bis define data model for incident information sharing.
It can embed assorted information that is usable for incident analysis,
including event logs.
XML-style logs can also be embedded to IODEF through the means of IODEF-SCI.
IODEF-SCI planned to embed XML-type information, such as CEE.

If the ipfix-network-security draft can provide an XML representation of the
data element, IODEF can also convey the information.
I am not that familiar with the current situation on how organzations
actually share information, but I feel like that there are notable amount of
people who exchange information using XML.
So, addressing the other representations would also help the draft, I think.

Indeed, the same discussion applies to draft-teague-threat-signaling.


2. draft-fu-ipfix-network-security vs draft-teague-threat-signaling

Both of them approach attack/treat information expression and exchange.
Though the defined data elements are not the same (as can be seen in
Section 3.1 of draft-fu-ipfix-network-security and in Section 4 of
draft-teague-threat-signaling), I feel that they are somehow overlapping.
Having two different data representation is not something I like, so I would
like to hear the difference of their scopes.

I might have some misunderstanding, so your explanation would be helpful.
Thank you.

Take




-----Original Message----- 
From: Roman D. Danyliw
Sent: Monday, March 23, 2015 2:55 AM
To: dots@ietf.org
Subject: [Dots] FW: Prior discussion about
draft-fu-ipfix-network-security-00

Hello!

To those that might be in the same situation, Robert Moskwitz tracked down
that the place to download messages has moved.  Please now go to
http://www.ietf.org/mail-archive/text/dots/.

Roman

________________________________________
From: Robert Moskowitz [rgm-sec@htt-consult.com]
Sent: Sunday, March 22, 2015 8:47 AM
To: Roman D. Danyliw; 'dots@ietf.org'
Subject: Re: [Dots] Prior discussion about
draft-fu-ipfix-network-security-00

Can you check with the list serve people as to why there is not a
downloadable form for the list as other IETF lists?  Granted I only
missed a few, but I like to have them all in my local folder.

On 03/21/2015 04:43 PM, Roman D. Danyliw wrote:
> Hello!
>
> Two formal drafts will be part of the agenda [1] at the DOTS BOF,
> draft-teague-open-threat-signaling-00 [2] and
> draft-fu-ipfix-network-security-00 [3].  Discussion about the former
> (draft-teague-open-threat-signaling-00) already started on the DOTS list
> [4].  I wanted  to provide a pointer to prior discussions about the latter
> draft (draft-fu-ipfix-network-security-00) that were on the IPFIX list [5]
> in December 2014.
>
> Regards.
> Roman
>
> [1] http://www.ietf.org/mail-archive/web/dots/current/msg00003.html
> [2] https://tools.ietf.org/html/draft-teague-open-threat-signaling-00
> [3] https://tools.ietf.org/html/draft-fu-ipfix-network-security-00
> [4] http://www.ietf.org/mail-archive/web/dots/current/msg00002.html
> [5] http://www.ietf.org/mail-archive/web/ipfix/current/msg07277.html
>
> _______________________________________________
> 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 Mar 23 17:11: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 0EC351A89F1 for ; Mon, 23 Mar 2015 17:11:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pK26SLp6KrIf for ; Mon, 23 Mar 2015 17:11:51 -0700 (PDT)
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 4B0491A9080 for ; Mon, 23 Mar 2015 17:11:51 -0700 (PDT)
Received: by oifu20 with SMTP id u20so4960495oif.0 for ; Mon, 23 Mar 2015 17:11:50 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:user-agent:content-type:content-id :content-transfer-encoding:mime-version; bh=SD54MTMLhbKQVrGfotN3G6jau4yjT6PSoiLx8AP9xHU=; b=CV6o+Uyeivc7a/I78q+9KSVZT/HA3ebSI1Uf8iQAexNI154mldmTxhn0i9MR9QIq2v MQCItkuzDiqGGbTOwJyE5p6nBd7fd2VutFK6Rm39RcxhFs4tMpcnK3xSqV94ToQihNDj MsI/L4oDVCvFNA91Mt3MPz3DUCnZxwC5MCv0Vocvv7iwN08R28ahezOV5P9usAflnSvj Kd/VBI+s3hwCzLhyJ9ob4s7SX3b3WSVyDBQcF3rbISiJDGLEnzBLSe8eH39w0Z8Me0Tk /JM440N9LX0hVwmF6jvBZ2fT/XvtkpLyepgJKbdQsrQit/WFoTzQHiqH6EarODzU7okX bvcA==
X-Gm-Message-State: ALoCoQlCRDO7KG96ci+B6u5/dzulgiiUnsULWWSzc7ccpU/V3RK86jVB7/c67JX8Xp+JrnSDsgSUjpWAx1DfHRf490OiaJV8QA==
X-Received: by 10.140.148.201 with SMTP id 192mr2548323qhu.36.1427155910756; Mon, 23 Mar 2015 17:11:50 -0700 (PDT)
Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by mx.google.com with ESMTPS id cg8sm513260qcb.1.2015.03.23.17.11.50 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 23 Mar 2015 17:11:50 -0700 (PDT)
X-Relaying-Domain: verisign.com
Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01 [10.173.152.205]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id t2O0Bldw009005 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 Mar 2015 20:11:47 -0400
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Mon, 23 Mar 2015 20:11:47 -0400
From: "Teague, Nik" 
To: Takeshi Takahashi , "Roman D. Danyliw" , "dots@ietf.org" 
Thread-Topic: [Dots] FW: Prior discussion about draft-fu-ipfix-network-security-00
Thread-Index: AQHQZbIoOwI+JfnE5kOyGKOZy6v6WJ0qshGA
Date: Tue, 24 Mar 2015 00:11:46 +0000
Message-ID: 
References: <358188D97DBE45F787E97C9E29B1C0A3@takeAsus>
In-Reply-To: <358188D97DBE45F787E97C9E29B1C0A3@takeAsus>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.8.150116
x-originating-ip: [10.173.152.4]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <548B77AB32971D4C87D14667D95C7A2A@verisign.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "tt2@rc5.so-net.ne.jp" 
Subject: Re: [Dots] FW: Prior discussion about draft-fu-ipfix-network-security-00
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "List for 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, 24 Mar 2015 00:11:53 -0000

Hi,

See inline

On 23/03/2015 16:41, "Takeshi Takahashi" 
wrote:

>Hello all,
>
>Let me post two comments on draft-fu-ipfix-network-security.
>
>1. XML representation
>
>I am wondering if the draft could addrss the XML representation of the
>data
>elements.
>I understand that sometimes people (including myself) wish to avoid using
>XML, but it would be beneficial if IODEF can use the data elements listed
>in
>the draft.
>The data elements listed in Section 3.1 could be also represented in XML.
>
>IODEF  and IODEF-bis define data model for incident information sharing.
>It can embed assorted information that is usable for incident analysis,
>including event logs.
>XML-style logs can also be embedded to IODEF through the means of
>IODEF-SCI.
>IODEF-SCI planned to embed XML-type information, such as CEE.
>
>If the ipfix-network-security draft can provide an XML representation of
>the
>data element, IODEF can also convey the information.
>I am not that familiar with the current situation on how organzations
>actually share information, but I feel like that there are notable amount
>of
>people who exchange information using XML.
>So, addressing the other representations would also help the draft, I
>think.
>
>Indeed, the same discussion applies to draft-teague-threat-signaling.

A factor of the draft-teague-threat-signaling proposal was to avoid the
weight of something like XML simply to keep the signaling portion light
and more pliable for UDP export.  I think we could obviously examine how
DOTS and IODEF etc. may interoperate as we proceed but was beyond the
scope of the initial 00 draft.  This list is a great place to have that
discussion.

>
>
>2. draft-fu-ipfix-network-security vs draft-teague-threat-signaling
>
>Both of them approach attack/treat information expression and exchange.
>Though the defined data elements are not the same (as can be seen in
>Section 3.1 of draft-fu-ipfix-network-security and in Section 4 of
>draft-teague-threat-signaling), I feel that they are somehow overlapping.
>Having two different data representation is not something I like, so I
>would
>like to hear the difference of their scopes.


Taking draft-teague-threat-signaling - The proposal is to enable a DDoS
mitigation device, that is already more than capable of identifying and
dealing with attacks, to signal to a service provider with DDoS mitigation
capabilities telemetry data and when offramp to the service provider
infrastructure is desired.  DDoS mitigation devices are quite
sophisticated and come with their own suite of analytics. There is no
point in both an on-premise device and a provider analytics engine
recreating work when one can tell the other whats going on and we can all
get down to the mitigation part faster.  The telemetry export is there to
kickstart the upstream mitigation so the provider can have a suitable
granular mitigation strategy ready to go... rather than falling back on a
generic response while relearning the attack profile in order to tweak
said response to fit.

Reading over draft-fu-ipfix-network-security - I see this adding
enhancements to IPFIX which would still then require upstream/service
provider analytics to determine the attack and the appropriate response
(flagged in the slides as big data mining). For operators who are not
deploying a local mitigation device though I see the enhancements having
value for the service provider to identify, alert, notify the operator etc.

So I see the 2x as fulfilling different functions within differing
deployments.

>
>I might have some misunderstanding, so your explanation would be helpful.
>Thank you.
>
>Take


Thanks,

-Nik


From nobody Mon Mar 23 20:14: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 0D6A21B2C26 for ; Mon, 23 Mar 2015 20:14:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level: 
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fOkB-Lb7UU5E for ; Mon, 23 Mar 2015 20:14:17 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABF791B2C1C for ; Mon, 23 Mar 2015 20:14:15 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQQ05329; Tue, 24 Mar 2015 03:14:13 +0000 (GMT)
Received: from SZXEML434-HUB.china.huawei.com (10.82.67.225) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 24 Mar 2015 03:14:13 +0000
Received: from szxeml557-mbs.china.huawei.com ([169.254.6.131]) by szxeml434-hub.china.huawei.com ([10.82.67.225]) with mapi id 14.03.0158.001; Tue, 24 Mar 2015 11:14:05 +0800
From: "Hedanping (Ana)" 
To: "Teague, Nik" , Takeshi Takahashi , "Roman D. Danyliw" , "dots@ietf.org" 
Thread-Topic: [Dots] FW: Prior discussion about draft-fu-ipfix-network-security-00
Thread-Index: AQHQZbIoTtM4pFsfI0uN7diSf1L3ep0qPLoAgACnVxA=
Date: Tue, 24 Mar 2015 03:14:05 +0000
Message-ID: <77FA386512F0D748BC7C02C36EB1106D955C93@szxeml557-mbs.china.huawei.com>
References: <358188D97DBE45F787E97C9E29B1C0A3@takeAsus> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.155.148]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Cc: "tt2@rc5.so-net.ne.jp" 
Subject: Re: [Dots] FW: Prior discussion about draft-fu-ipfix-network-security-00
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "List for 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, 24 Mar 2015 03:14:20 -0000

Hi all,

  > -----Original Message-----
  > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Teague, Nik
  > Sent: Tuesday, March 24, 2015 8:12 AM
  > To: Takeshi Takahashi; Roman D. Danyliw; dots@ietf.org
  > Cc: tt2@rc5.so-net.ne.jp
  > Subject: Re: [Dots] FW: Prior discussion about
  > draft-fu-ipfix-network-security-00
  >=20
  > Hi,
  >=20
  > See inline
  >=20
  > On 23/03/2015 16:41, "Takeshi Takahashi" 
  > wrote:
  >=20
  > >Hello all,
  > >
  > >Let me post two comments on draft-fu-ipfix-network-security.
  > >
  > >1. XML representation
  > >
  > >I am wondering if the draft could addrss the XML representation of the
  > >data elements.
  > >I understand that sometimes people (including myself) wish to avoid
  > >using XML, but it would be beneficial if IODEF can use the data
  > >elements listed in the draft.
  > >The data elements listed in Section 3.1 could be also represented in X=
ML.
  > >
  > >IODEF  and IODEF-bis define data model for incident information sharin=
g.
  > >It can embed assorted information that is usable for incident analysis=
,
  > >including event logs.
  > >XML-style logs can also be embedded to IODEF through the means of
  > >IODEF-SCI.
  > >IODEF-SCI planned to embed XML-type information, such as CEE.
  > >
  > >If the ipfix-network-security draft can provide an XML representation
  > >of the data element, IODEF can also convey the information.
  > >I am not that familiar with the current situation on how organzations
  > >actually share information, but I feel like that there are notable
  > >amount of people who exchange information using XML.
  > >So, addressing the other representations would also help the draft, I
  > >think.
  > >
  > >Indeed, the same discussion applies to draft-teague-threat-signaling.
  >=20
  > A factor of the draft-teague-threat-signaling proposal was to avoid the
  > weight of something like XML simply to keep the signaling portion light=
 and
  > more pliable for UDP export.  I think we could obviously examine how DO=
TS
  > and IODEF etc. may interoperate as we proceed but was beyond the scope =
of
  > the initial 00 draft.  This list is a great place to have that discussi=
on.
  >=20
Ipfix has its own standardized approach to export messages. It defines how =
flow information is formatted and transmitted. Template can be customized t=
o export and transmit message from exporter to collector. draft-fu-ipfix-ne=
twork-security-00 directly reuses such mechanism to convey messages. Beside=
s, efficiency is a big challenge in anti-DDOS attack, as big amount of flow=
 information data should be observed and transmitted, therefore it's necess=
ary to evaluate the efficiency of using xml to deliver those messages, and =
to see in which aspect the solution can interoperate with IODEF.=20
  > >
  > >
  > >2. draft-fu-ipfix-network-security vs draft-teague-threat-signaling
  > >
  > >Both of them approach attack/treat information expression and exchange=
.
  > >Though the defined data elements are not the same (as can be seen in
  > >Section 3.1 of draft-fu-ipfix-network-security and in Section 4 of
  > >draft-teague-threat-signaling), I feel that they are somehow overlappi=
ng.
  > >Having two different data representation is not something I like, so I
  > >would like to hear the difference of their scopes.
  >=20
  >=20
  > Taking draft-teague-threat-signaling - The proposal is to enable a DDoS
  > mitigation device, that is already more than capable of identifying and
  > dealing with attacks, to signal to a service provider with DDoS mitigat=
ion
  > capabilities telemetry data and when offramp to the service provider
  > infrastructure is desired.  DDoS mitigation devices are quite sophistic=
ated
  > and come with their own suite of analytics. There is no point in both a=
n
  > on-premise device and a provider analytics engine recreating work when =
one
  > can tell the other whats going on and we can all get down to the mitiga=
tion
  > part faster.  The telemetry export is there to kickstart the upstream
  > mitigation so the provider can have a suitable granular mitigation stra=
tegy
  > ready to go... rather than falling back on a generic response while rel=
earning
  > the attack profile in order to tweak said response to fit.
  >=20
  > Reading over draft-fu-ipfix-network-security - I see this adding enhanc=
ements
  > to IPFIX which would still then require upstream/service provider analy=
tics to
  > determine the attack and the appropriate response (flagged in the slide=
s as
  > big data mining). For operators who are not deploying a local mitigatio=
n
  > device though I see the enhancements having value for the service provi=
der
  > to identify, alert, notify the operator etc.
  >=20
  > So I see the 2x as fulfilling different functions within differing depl=
oyments.

Indeed, good summary.=20
Beside, draft-fu-ipfix-network-security-00 allows the central server learns=
 the behavior of evolved attacks from big data mining, then adjusting thres=
holds or adding new metrics that might trigger the event alarm, and finally=
 making acl policy, traffic steering policy and data cleaning policy more e=
ffectively and efficiently.=20

Even though the data elements are different in both drafts, IMHO, they are =
actually observing behavior of the same attacks at different levels, and as=
 both drafts are 00 version, we still need to discuss more on the data elem=
ents.

Regards,
Ana
  >=20
  > >
  > >I might have some misunderstanding, so your explanation would be helpf=
ul.
  > >Thank you.
  > >
  > >Take
  >=20
  >=20
  > Thanks,
  >=20
  > -Nik
  >=20
  > _______________________________________________
  > Dots mailing list
  > Dots@ietf.org
  > https://www.ietf.org/mailman/listinfo/dots


From nobody Mon Mar 23 20:54: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 E33031B2C51 for ; Mon, 23 Mar 2015 20:54:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id reFNq0yZLVUk for ; Mon, 23 Mar 2015 20:54:15 -0700 (PDT)
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 AB25A1B2C4E for ; Mon, 23 Mar 2015 20:54:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6725; q=dns/txt; s=iport; t=1427169255; x=1428378855; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=moMY6RNFUWbdXSdXF48c1Am31fs/SnnG3agsEvKxQgw=; b=LXzeV0QEqsRtsnBixzrtux/k5YWNIcMEF0IVKw3lcEkz8EG9QaPmf/lS 1di12Zn3aKHzkzTKlRd3uEpZ20Yi1yXaqnWgikJTTixZkAEio/XNjpZyU cUAUDc9zP/4s5/Sbd4GrX+3kKZh7DuxmSkNos/dCXKT01v+hVuuC/ADhU 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BKCwC53xBV/4oNJK1SCoMGUloExBVrgUUKhXUCgTk4FAEBAQEBAQF8hBQBAQEEAQEBNzMBCwwEAgEIEQQBAQEKFAkHJwsUCAEIAgQBDQUIE4gUDchsAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLIYQZKzEHBoMRgRYBBJBPhhKEdo9Hg0ciggIcgVBvgUR/AQEB
X-IronPort-AV: E=Sophos;i="5.11,456,1422921600"; d="scan'208";a="134696052"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-8.cisco.com with ESMTP; 24 Mar 2015 03:54:13 +0000
Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t2O3sDdT013666 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 24 Mar 2015 03:54:13 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.80]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Mon, 23 Mar 2015 22:54:13 -0500
From: "Panos Kampanakis (pkampana)" 
To: "Hedanping (Ana)" , "Teague, Nik" , Takeshi Takahashi , "Roman D. Danyliw" , "dots@ietf.org" 
Thread-Topic: [Dots] FW: Prior discussion about draft-fu-ipfix-network-security-00
Thread-Index: AQHQZbIomCgFLJJduk2Sw02RO77S3p0rFqgAgAAy8ID//7bUcA==
Date: Tue, 24 Mar 2015 03:54:12 +0000
Message-ID: <1C9F17D1873AFA47A969C4DD98F98A75153AC9EA@xmb-rcd-x10.cisco.com>
References: <358188D97DBE45F787E97C9E29B1C0A3@takeAsus>  <77FA386512F0D748BC7C02C36EB1106D955C93@szxeml557-mbs.china.huawei.com>
In-Reply-To: <77FA386512F0D748BC7C02C36EB1106D955C93@szxeml557-mbs.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.233.1]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "tt2@rc5.so-net.ne.jp" 
Subject: Re: [Dots] FW: Prior discussion about draft-fu-ipfix-network-security-00
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "List for 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, 24 Mar 2015 03:54:18 -0000

Hello,

It seems to me that the "signaling in order to mitigate DDoS" problem has b=
een solved already by BGP FlowSpec. I am not sure if defining more verbose =
and detailed communications between network elements would add much value, =
since these devices cannot do more than signalling and mitigate.

Panos


-----Original Message-----
From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Hedanping (Ana)
Sent: Monday, March 23, 2015 11:14 PM
To: Teague, Nik; Takeshi Takahashi; Roman D. Danyliw; dots@ietf.org
Cc: tt2@rc5.so-net.ne.jp
Subject: Re: [Dots] FW: Prior discussion about draft-fu-ipfix-network-secur=
ity-00

Hi all,

  > -----Original Message-----
  > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Teague, Nik
  > Sent: Tuesday, March 24, 2015 8:12 AM
  > To: Takeshi Takahashi; Roman D. Danyliw; dots@ietf.org
  > Cc: tt2@rc5.so-net.ne.jp
  > Subject: Re: [Dots] FW: Prior discussion about
  > draft-fu-ipfix-network-security-00
  >=20
  > Hi,
  >=20
  > See inline
  >=20
  > On 23/03/2015 16:41, "Takeshi Takahashi" 
  > wrote:
  >=20
  > >Hello all,
  > >
  > >Let me post two comments on draft-fu-ipfix-network-security.
  > >
  > >1. XML representation
  > >
  > >I am wondering if the draft could addrss the XML representation of the
  > >data elements.
  > >I understand that sometimes people (including myself) wish to avoid
  > >using XML, but it would be beneficial if IODEF can use the data
  > >elements listed in the draft.
  > >The data elements listed in Section 3.1 could be also represented in X=
ML.
  > >
  > >IODEF  and IODEF-bis define data model for incident information sharin=
g.
  > >It can embed assorted information that is usable for incident analysis=
,
  > >including event logs.
  > >XML-style logs can also be embedded to IODEF through the means of
  > >IODEF-SCI.
  > >IODEF-SCI planned to embed XML-type information, such as CEE.
  > >
  > >If the ipfix-network-security draft can provide an XML representation
  > >of the data element, IODEF can also convey the information.
  > >I am not that familiar with the current situation on how organzations
  > >actually share information, but I feel like that there are notable
  > >amount of people who exchange information using XML.
  > >So, addressing the other representations would also help the draft, I
  > >think.
  > >
  > >Indeed, the same discussion applies to draft-teague-threat-signaling.
  >=20
  > A factor of the draft-teague-threat-signaling proposal was to avoid the
  > weight of something like XML simply to keep the signaling portion light=
 and
  > more pliable for UDP export.  I think we could obviously examine how DO=
TS
  > and IODEF etc. may interoperate as we proceed but was beyond the scope =
of
  > the initial 00 draft.  This list is a great place to have that discussi=
on.
  >=20
Ipfix has its own standardized approach to export messages. It defines how =
flow information is formatted and transmitted. Template can be customized t=
o export and transmit message from exporter to collector. draft-fu-ipfix-ne=
twork-security-00 directly reuses such mechanism to convey messages. Beside=
s, efficiency is a big challenge in anti-DDOS attack, as big amount of flow=
 information data should be observed and transmitted, therefore it's necess=
ary to evaluate the efficiency of using xml to deliver those messages, and =
to see in which aspect the solution can interoperate with IODEF.=20
  > >
  > >
  > >2. draft-fu-ipfix-network-security vs draft-teague-threat-signaling
  > >
  > >Both of them approach attack/treat information expression and exchange=
.
  > >Though the defined data elements are not the same (as can be seen in
  > >Section 3.1 of draft-fu-ipfix-network-security and in Section 4 of
  > >draft-teague-threat-signaling), I feel that they are somehow overlappi=
ng.
  > >Having two different data representation is not something I like, so I
  > >would like to hear the difference of their scopes.
  >=20
  >=20
  > Taking draft-teague-threat-signaling - The proposal is to enable a DDoS
  > mitigation device, that is already more than capable of identifying and
  > dealing with attacks, to signal to a service provider with DDoS mitigat=
ion
  > capabilities telemetry data and when offramp to the service provider
  > infrastructure is desired.  DDoS mitigation devices are quite sophistic=
ated
  > and come with their own suite of analytics. There is no point in both a=
n
  > on-premise device and a provider analytics engine recreating work when =
one
  > can tell the other whats going on and we can all get down to the mitiga=
tion
  > part faster.  The telemetry export is there to kickstart the upstream
  > mitigation so the provider can have a suitable granular mitigation stra=
tegy
  > ready to go... rather than falling back on a generic response while rel=
earning
  > the attack profile in order to tweak said response to fit.
  >=20
  > Reading over draft-fu-ipfix-network-security - I see this adding enhanc=
ements
  > to IPFIX which would still then require upstream/service provider analy=
tics to
  > determine the attack and the appropriate response (flagged in the slide=
s as
  > big data mining). For operators who are not deploying a local mitigatio=
n
  > device though I see the enhancements having value for the service provi=
der
  > to identify, alert, notify the operator etc.
  >=20
  > So I see the 2x as fulfilling different functions within differing depl=
oyments.

Indeed, good summary.=20
Beside, draft-fu-ipfix-network-security-00 allows the central server learns=
 the behavior of evolved attacks from big data mining, then adjusting thres=
holds or adding new metrics that might trigger the event alarm, and finally=
 making acl policy, traffic steering policy and data cleaning policy more e=
ffectively and efficiently.=20

Even though the data elements are different in both drafts, IMHO, they are =
actually observing behavior of the same attacks at different levels, and as=
 both drafts are 00 version, we still need to discuss more on the data elem=
ents.

Regards,
Ana
  >=20
  > >
  > >I might have some misunderstanding, so your explanation would be helpf=
ul.
  > >Thank you.
  > >
  > >Take
  >=20
  >=20
  > Thanks,
  >=20
  > -Nik
  >=20
  > _______________________________________________
  > 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 Mar 23 22:20: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 9BAEA1B2C88 for ; Mon, 23 Mar 2015 22:20:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j_5fxatJVy8n for ; Mon, 23 Mar 2015 22:20:27 -0700 (PDT)
Received: from mail-qg0-f97.google.com (mail-qg0-f97.google.com [209.85.192.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6A261B2C87 for ; Mon, 23 Mar 2015 22:20:27 -0700 (PDT)
Received: by qgfl89 with SMTP id l89so5147514qgf.0 for ; Mon, 23 Mar 2015 22:20:27 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:user-agent:content-type:content-id :content-transfer-encoding:mime-version; bh=N8kOD47k+eOWOySZ7dN33jodfWNWwjV5puLGbjrBLQ0=; b=ff3YUr4IKgoc67lTxIZncK8bhvkHUK6C0QGJEwQG6E9wqr+QGD7yi9xedQTnVeKNQQ kM593YQR+OryrQtTulVxVniYyz/IcX2FeMoe8k8abtUa1zZ7rIZN+FGij2HCrVE2yyhj 900JZwrg9Z56N55uushG0XgqEZ3IQuMwWaw4QDraH90dshODY53toAp/uN83fw3O3nsf SKi8WKns1weXU6nJ70yp+wtyQjXC8jHoGvlPRHn38qsy2/VWt6cAjyO21tihfkXFSuPI 4+6wCIHssCX25XdC7tc/pAoQV1hKZDfKZr7u40F4WPyMzHakK46dPHiv3stifIZiAxFO q25A==
X-Gm-Message-State: ALoCoQkxCwpN5HThucf9jZ5kH45hJmVAnofTHDicRl9MenIfIjF5SLQdhZjEoSDW4axmTQk41j2tcbhLZ/qrli/YsXAOJ/aoUw==
X-Received: by 10.55.21.40 with SMTP id f40mr5659456qkh.96.1427174426987; Mon, 23 Mar 2015 22:20:26 -0700 (PDT)
Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by mx.google.com with ESMTPS id cd6sm629129qcb.2.2015.03.23.22.20.26 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 23 Mar 2015 22:20:26 -0700 (PDT)
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 t2O5KOh9010997 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 24 Mar 2015 01:20:25 -0400
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 24 Mar 2015 01:20:24 -0400
From: "Teague, Nik" 
To: "Panos Kampanakis (pkampana)" , "Hedanping (Ana)" , Takeshi Takahashi , "Roman D. Danyliw" , "dots@ietf.org" 
Thread-Topic: [Dots] FW: Prior discussion about draft-fu-ipfix-network-security-00
Thread-Index: AQHQZbIoOwI+JfnE5kOyGKOZy6v6WJ0qshGAgACGw4CAAAs2AP//xECA
Date: Tue, 24 Mar 2015 05:20:24 +0000
Message-ID: 
References: <358188D97DBE45F787E97C9E29B1C0A3@takeAsus>  <77FA386512F0D748BC7C02C36EB1106D955C93@szxeml557-mbs.china.huawei.com> <1C9F17D1873AFA47A969C4DD98F98A75153AC9EA@xmb-rcd-x10.cisco.com>
In-Reply-To: <1C9F17D1873AFA47A969C4DD98F98A75153AC9EA@xmb-rcd-x10.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.8.150116
x-originating-ip: [10.173.152.4]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "tt2@rc5.so-net.ne.jp" 
Subject: Re: [Dots] FW: Prior discussion about draft-fu-ipfix-network-security-00
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "List for 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, 24 Mar 2015 05:20:29 -0000

Hi,

On 23/03/2015 22:54, "Panos Kampanakis (pkampana)" 
wrote:

>Hello,
>
>It seems to me that the "signaling in order to mitigate DDoS" problem has
>been solved already by BGP FlowSpec. I am not sure if defining more
>verbose and detailed communications between network elements would add
>much value, since these devices cannot do more than signalling and
>mitigate.
>
>Panos

Flowspec is very effective within the bounds of its capabilities - if a
bad actor is hammering my network with an ntp reflection attack or my web
server with a whole swathe of large udp packets then I can easily build
filters to handle that - if the bad actor is hitting my web server with a
syn flood from a massively random source pool then I have to consider rate
limiting as probably my best, but maybe not ideal, option.  If I try and
generate more than 12k flow route filters to push to either my equipment
or my service providers (depending upon whether they support Flowspec)
then things can get a little hairy.  DDoS mitigation CPE and DDoS
mitigation providers exist because the need is there - The DOTS proposal
is that effective signaling is necessary between these elements, not
specifically generic network elements, but actual elements that are
concerned with often complex attacks that a flow route filter is unable to
deal with.  If my ingress links are saturated then signaling via a tcp
oriented session can potentially result in more cycles being spent trying
to initiate and maintain a session than actual information transfer=8A and
if the connection drops then the whole thing has to start again.

Thanks,

-Nik





From nobody Tue Mar 24 03:58: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 356261B2E7C for ; Tue, 24 Mar 2015 03:58:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.252
X-Spam-Level: **
X-Spam-Status: No, score=2.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439, TVD_FINGER_02=1.215, 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 QMybhYcVs80D for ; Tue, 24 Mar 2015 03:58:30 -0700 (PDT)
Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:df0:232:300::2]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B4A91B2E7A for ; Tue, 24 Mar 2015 03:58:29 -0700 (PDT)
Received: from gw2.nict.go.jp (gw2.nict.go.jp [133.243.18.251]) by ns2.nict.go.jp  with ESMTP id t2OAwFrj003980; Tue, 24 Mar 2015 19:58:15 +0900 (JST)
Received: from takeAsus (ssh.nict.go.jp [133.243.3.49]) by gw2.nict.go.jp  with SMTP id t2OAwBKR003953; Tue, 24 Mar 2015 19:58:12 +0900 (JST)
Message-ID: <0CB8640B8D094438BD4A4793DAD0F3B7@takeAsus>
From: "Takeshi Takahashi" 
To: "Teague, Nik" , "Panos Kampanakis \(pkampana\)" , "Hedanping \(Ana\)" , "Roman D. Danyliw" , 
References: <358188D97DBE45F787E97C9E29B1C0A3@takeAsus>  <77FA386512F0D748BC7C02C36EB1106D955C93@szxeml557-mbs.china.huawei.com> <1C9F17D1873AFA47A969C4DD98F98A75153AC9EA@xmb-rcd-x10.cisco.com> 
In-Reply-To: 
Date: Tue, 24 Mar 2015 05:57:49 -0500
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 16.4.3528.331
X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331
X-Virus-Scanned: clamav-milter 0.98.5 at zenith2
X-Virus-Status: Clean
Archived-At: 
Cc: tt2@rc5.so-net.ne.jp
Subject: Re: [Dots] FW: Prior discussion about draft-fu-ipfix-network-security-00
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "List for 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, 24 Mar 2015 10:58:32 -0000

Hi,

Thank you for the replies; I think I got the idea better than before.

> more pliable for UDP export.  I think we could obviously examine how DOTS
> and IODEF etc. may interoperate as we proceed but was beyond the scope of
> the initial 00 draft.  This list is a great place to have that discussion.

It would be great if we could have such a discussion.

Below are comments on why I would like to see the XML representation in the 
drafts.
IODEF is just one spec of many other specs that defines XML-based 
information model; there are lots more that haven't been brought to IETF 
(e.g., stix).
If you do not provide any XML schema (in the appendix of the drafts) on this 
issue, the same kind of work would be taken again in the future from the 
XML-based community.
I think that is a waste.
I know that XML-representation is off the context of these drafts and thus 
authors are not that happy to cope with that, but I believe it is worth 
saying that here :)
It could be that Nik's draft can gain little benefit by defining xml schema 
since it does not need further analytics, but I feel that it is useful for 
Ana's draft since it expects further analysis such as big data analysis.

Thank you.
Take


-----Original Message----- 
From: Teague, Nik
Sent: Tuesday, March 24, 2015 12:20 AM
To: Panos Kampanakis (pkampana) ; Hedanping (Ana) ; Takeshi Takahashi ; 
Roman D. Danyliw ; dots@ietf.org
Cc: tt2@rc5.so-net.ne.jp
Subject: Re: [Dots] FW: Prior discussion about 
draft-fu-ipfix-network-security-00

Hi,

On 23/03/2015 22:54, "Panos Kampanakis (pkampana)" 
wrote:

>Hello,
>
>It seems to me that the "signaling in order to mitigate DDoS" problem has
>been solved already by BGP FlowSpec. I am not sure if defining more
>verbose and detailed communications between network elements would add
>much value, since these devices cannot do more than signalling and
>mitigate.
>
>Panos

Flowspec is very effective within the bounds of its capabilities - if a
bad actor is hammering my network with an ntp reflection attack or my web
server with a whole swathe of large udp packets then I can easily build
filters to handle that - if the bad actor is hitting my web server with a
syn flood from a massively random source pool then I have to consider rate
limiting as probably my best, but maybe not ideal, option.  If I try and
generate more than 12k flow route filters to push to either my equipment
or my service providers (depending upon whether they support Flowspec)
then things can get a little hairy.  DDoS mitigation CPE and DDoS
mitigation providers exist because the need is there - The DOTS proposal
is that effective signaling is necessary between these elements, not
specifically generic network elements, but actual elements that are
concerned with often complex attacks that a flow route filter is unable to
deal with.  If my ingress links are saturated then signaling via a tcp
oriented session can potentially result in more cycles being spent trying
to initiate and maintain a session than actual information transferŠ and
if the connection drops then the whole thing has to start again.

Thanks,

-Nik




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


From nobody Tue Mar 24 04:39: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 1B4DD1B2E82 for ; Tue, 24 Mar 2015 04:39:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.012
X-Spam-Level: 
X-Spam-Status: No, score=-1.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=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 wvGkq00c2R7K for ; Tue, 24 Mar 2015 04:39:56 -0700 (PDT)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E6271B2E81 for ; Tue, 24 Mar 2015 04:39:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default;  h=To:References:Message-Id:Date:In-Reply-To:From:Content-Type:Mime-Version:Subject; bh=9mzcoe2ZTfWBD1lEvFmRA/P9pcsUtnSxSkCpX3N2Qb4=;  b=SoU6R3ML3xIAY9lhsreJlu86CZLSu5JSCGIpf9xAzkclwDQWcXG/npehyuBtByXD4qsZFHOUgo+EzXKEHBYOfXgJ6mxYv0KLz5cjX3eA411DOb1r//WFHh9IogD21sZIEm/fnddGoWRYvjfMtk+LXRsjrw779leyWNOFFT559go=;
Received: from ip68-100-197-30.dc.dc.cox.net ([68.100.197.30]:53868 helo=[192.168.15.136]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1YaNBW-0007TD-54 for dots@ietf.org; Tue, 24 Mar 2015 04:39:55 -0700
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_96CECABF-6238-4FA0-9C54-2E43EBDCA97A"; protocol="application/pgp-signature"; micalg=pgp-sha256
X-Pgp-Agent: GPGMail 2.5b6
From: Eric Burger 
X-Priority: 3
In-Reply-To: <0CB8640B8D094438BD4A4793DAD0F3B7@takeAsus>
Date: Tue, 24 Mar 2015 07:39:49 -0400
Message-Id: <10B310D1-09A0-4C9F-B01C-F25DFA360981@standardstrack.com>
References: <358188D97DBE45F787E97C9E29B1C0A3@takeAsus>  <77FA386512F0D748BC7C02C36EB1106D955C93@szxeml557-mbs.china.huawei.com> <1C9F17D1873AFA47A969C4DD98F98A75153AC9EA@xmb-rcd-x10.cisco.com>  <0CB8640B8D094438BD4A4793DAD0F3B7@takeAsus>
To: dots@ietf.org
X-Mailer: Apple Mail (2.2070.6)
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
Archived-At: 
Subject: Re: [Dots] FW: Prior discussion about draft-fu-ipfix-network-security-00
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "List for 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, 24 Mar 2015 11:39:58 -0000

--Apple-Mail=_96CECABF-6238-4FA0-9C54-2E43EBDCA97A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Let me take it from a different perspective. If we could use XML, would =
we not just use IODEF and be done with it? My understanding is we cannot =
pay the XML tax and as such need to go a different route.

A well-defined data model would be very important for this effort. With =
a well-defined data model, one should be able to easily translate from =
IPFIX or some hyper-compressed binary encoding to XML.

> On Mar 24, 2015, at 6:57 AM, Takeshi Takahashi =
 wrote:
>=20
> Hi,
>=20
> Thank you for the replies; I think I got the idea better than before.
>=20
>> more pliable for UDP export.  I think we could obviously examine how =
DOTS
>> and IODEF etc. may interoperate as we proceed but was beyond the =
scope of
>> the initial 00 draft.  This list is a great place to have that =
discussion.
>=20
> It would be great if we could have such a discussion.
>=20
> Below are comments on why I would like to see the XML representation =
in the drafts.
> IODEF is just one spec of many other specs that defines XML-based =
information model; there are lots more that haven't been brought to IETF =
(e.g., stix).
> If you do not provide any XML schema (in the appendix of the drafts) =
on this issue, the same kind of work would be taken again in the future =
from the XML-based community.
> I think that is a waste.
> I know that XML-representation is off the context of these drafts and =
thus authors are not that happy to cope with that, but I believe it is =
worth saying that here :)
> It could be that Nik's draft can gain little benefit by defining xml =
schema since it does not need further analytics, but I feel that it is =
useful for Ana's draft since it expects further analysis such as big =
data analysis.
>=20
> Thank you.
> Take
>=20
>=20
> -----Original Message----- From: Teague, Nik
> Sent: Tuesday, March 24, 2015 12:20 AM
> To: Panos Kampanakis (pkampana) ; Hedanping (Ana) ; Takeshi Takahashi =
; Roman D. Danyliw ; dots@ietf.org
> Cc: tt2@rc5.so-net.ne.jp
> Subject: Re: [Dots] FW: Prior discussion about =
draft-fu-ipfix-network-security-00
>=20
> Hi,
>=20
> On 23/03/2015 22:54, "Panos Kampanakis (pkampana)" =

> wrote:
>=20
>> Hello,
>>=20
>> It seems to me that the "signaling in order to mitigate DDoS" problem =
has
>> been solved already by BGP FlowSpec. I am not sure if defining more
>> verbose and detailed communications between network elements would =
add
>> much value, since these devices cannot do more than signalling and
>> mitigate.
>>=20
>> Panos
>=20
> Flowspec is very effective within the bounds of its capabilities - if =
a
> bad actor is hammering my network with an ntp reflection attack or my =
web
> server with a whole swathe of large udp packets then I can easily =
build
> filters to handle that - if the bad actor is hitting my web server =
with a
> syn flood from a massively random source pool then I have to consider =
rate
> limiting as probably my best, but maybe not ideal, option.  If I try =
and
> generate more than 12k flow route filters to push to either my =
equipment
> or my service providers (depending upon whether they support Flowspec)
> then things can get a little hairy.  DDoS mitigation CPE and DDoS
> mitigation providers exist because the need is there - The DOTS =
proposal
> is that effective signaling is necessary between these elements, not
> specifically generic network elements, but actual elements that are
> concerned with often complex attacks that a flow route filter is =
unable to
> deal with.  If my ingress links are saturated then signaling via a tcp
> oriented session can potentially result in more cycles being spent =
trying
> to initiate and maintain a session than actual information transfer=8A =
and
> if the connection drops then the whole thing has to start again.
>=20
> Thanks,
>=20
> -Nik
>=20
>=20
>=20
>=20
> _______________________________________________
> 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


--Apple-Mail=_96CECABF-6238-4FA0-9C54-2E43EBDCA97A
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-----
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJVEU0FAAoJEDY/T2tCIPW3vC0P/2rRTafFuy9GOjvIlBTwitoV
InHtr5YggVxWmGH7FwvY0hv07Iy4Wj9ansNst2baLH/DUPzaGQM/pj5zQCFw7CZ1
vrUcoYOhTUDYhP6ASG7ASpZvCYj4GdFGnn5LCYDv9y1xaAdsxAs+FwG12OcO3JWR
P/3QXF/Avha3m45pXuxXUqjxDYOfTP7rgHPgjDKIgDlGtSxJlRY0X5zCNvz1QBXH
QDYVRlyyxyBczo0TUdR0wyk2IZD+u8qNagCg7eoISnNFsvvWr46fJxzdG/K5QEF3
hVH9v5e5WooYqFY+VU69J8KsPR5aA/+oBp9U/lMOZ7dB1AoFgm2jvCOnA6qxG8kU
UP+UHN1jJ0CISH+wzcnaeKIDt78xbdBlQkOZ53u4n28TJQOns8WIeJDtXIj6gUkF
9UTVKr5JD34gAA84fMr9yZNm8dhVnm+R3hZfp2kfcMSVBSjS0eQ1uz9oTS1c49kA
mZEWaOImdQ/DVw1SHkknQtd5ijCcHLujkFdVcfkNBVZSZq1NO+hDvSx73CzmpdXt
ZRngbYcwntSMfnO3GMMKm2jbu5CU0tNMCRTgeet31OsWlPLnvby3TXe4+CSWVVMP
nzj+VvNMeLIhf6oqpoWwMbEGSTI0oesyIZa2v0LuoccE2eT541aqEg4vtfCFy7r3
34dfADd+TpLvfKxIpcla
=At9E
-----END PGP SIGNATURE-----

--Apple-Mail=_96CECABF-6238-4FA0-9C54-2E43EBDCA97A--


From nobody Tue Mar 24 04:58: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 A77491B2CCA for ; Tue, 24 Mar 2015 04:58:32 -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 IiaygFqgQknF for ; Tue, 24 Mar 2015 04:58:29 -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 56FAD1A6FDB for ; Tue, 24 Mar 2015 04:58:29 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 3B3DA6029A; Tue, 24 Mar 2015 07:58:28 -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 DSyWTdBRBtKZ; Tue, 24 Mar 2015 07:58:21 -0400 (EDT)
Received: from lx120e.htt-consult.com (dhcp-8047.meeting.ietf.org [31.133.128.71]) (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 EA30B60186; Tue, 24 Mar 2015 07:58:18 -0400 (EDT)
Message-ID: <55115149.2070700@htt-consult.com>
Date: Tue, 24 Mar 2015 06:58:01 -0500
From: Robert Moskowitz 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Eric Burger , dots@ietf.org
References: <358188D97DBE45F787E97C9E29B1C0A3@takeAsus>  <77FA386512F0D748BC7C02C36EB1106D955C93@szxeml557-mbs.china.huawei.com> <1C9F17D1873AFA47A969C4DD98F98A75153AC9EA@xmb-rcd-x10.cisco.com>  <0CB8640B8D094438BD4A4793DAD0F3B7@takeAsus> <10B310D1-09A0-4C9F-B01C-F25DFA360981@standardstrack.com>
In-Reply-To: <10B310D1-09A0-4C9F-B01C-F25DFA360981@standardstrack.com>
Content-Type: multipart/alternative; boundary="------------020708030109070107050308"
Archived-At: 
Subject: Re: [Dots] FW: Prior discussion about draft-fu-ipfix-network-security-00
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "List for 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, 24 Mar 2015 11:58:32 -0000

This is a multi-part message in MIME format.
--------------020708030109070107050308
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit



On 03/24/2015 06:39 AM, Eric Burger wrote:
> Let me take it from a different perspective. If we could use XML, would we not just use IODEF and be done with it? My understanding is we cannot pay the XML tax and as such need to go a different route.
>
> A well-defined data model would be very important for this effort. With a well-defined data model, one should be able to easily translate from IPFIX or some hyper-compressed binary encoding to XML.

I almost hate to say it, but if we can develop (or there already is) a 
Binary Encoding Rule(s) for XML to a very compressed format, then we can 
do the data modeling in XML, but transmit in this BER format.

>
>> On Mar 24, 2015, at 6:57 AM, Takeshi Takahashi  wrote:
>>
>> Hi,
>>
>> Thank you for the replies; I think I got the idea better than before.
>>
>>> more pliable for UDP export.  I think we could obviously examine how DOTS
>>> and IODEF etc. may interoperate as we proceed but was beyond the scope of
>>> the initial 00 draft.  This list is a great place to have that discussion.
>> It would be great if we could have such a discussion.
>>
>> Below are comments on why I would like to see the XML representation in the drafts.
>> IODEF is just one spec of many other specs that defines XML-based information model; there are lots more that haven't been brought to IETF (e.g., stix).
>> If you do not provide any XML schema (in the appendix of the drafts) on this issue, the same kind of work would be taken again in the future from the XML-based community.
>> I think that is a waste.
>> I know that XML-representation is off the context of these drafts and thus authors are not that happy to cope with that, but I believe it is worth saying that here :)
>> It could be that Nik's draft can gain little benefit by defining xml schema since it does not need further analytics, but I feel that it is useful for Ana's draft since it expects further analysis such as big data analysis.
>>
>> Thank you.
>> Take
>>
>>
>> -----Original Message----- From: Teague, Nik
>> Sent: Tuesday, March 24, 2015 12:20 AM
>> To: Panos Kampanakis (pkampana) ; Hedanping (Ana) ; Takeshi Takahashi ; Roman D. Danyliw ; dots@ietf.org
>> Cc: tt2@rc5.so-net.ne.jp
>> Subject: Re: [Dots] FW: Prior discussion about draft-fu-ipfix-network-security-00
>>
>> Hi,
>>
>> On 23/03/2015 22:54, "Panos Kampanakis (pkampana)" 
>> wrote:
>>
>>> Hello,
>>>
>>> It seems to me that the "signaling in order to mitigate DDoS" problem has
>>> been solved already by BGP FlowSpec. I am not sure if defining more
>>> verbose and detailed communications between network elements would add
>>> much value, since these devices cannot do more than signalling and
>>> mitigate.
>>>
>>> Panos
>> Flowspec is very effective within the bounds of its capabilities - if a
>> bad actor is hammering my network with an ntp reflection attack or my web
>> server with a whole swathe of large udp packets then I can easily build
>> filters to handle that - if the bad actor is hitting my web server with a
>> syn flood from a massively random source pool then I have to consider rate
>> limiting as probably my best, but maybe not ideal, option.  If I try and
>> generate more than 12k flow route filters to push to either my equipment
>> or my service providers (depending upon whether they support Flowspec)
>> then things can get a little hairy.  DDoS mitigation CPE and DDoS
>> mitigation providers exist because the need is there - The DOTS proposal
>> is that effective signaling is necessary between these elements, not
>> specifically generic network elements, but actual elements that are
>> concerned with often complex attacks that a flow route filter is unable to
>> deal with.  If my ingress links are saturated then signaling via a tcp
>> oriented session can potentially result in more cycles being spent trying
>> to initiate and maintain a session than actual information transferÅ  and
>> if the connection drops then the whole thing has to start again.
>>
>> Thanks,
>>
>> -Nik
>>
>>
>>
>>
>> _______________________________________________
>> 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


--------------020708030109070107050308
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    

    

    
On 03/24/2015 06:39 AM, Eric Burger
      wrote:

    

    

      
Let me take it from a different perspective. If we could use XML, would we not just use IODEF and be done with it? My understanding is we cannot pay the XML tax and as such need to go a different route.

A well-defined data model would be very important for this effort. With a well-defined data model, one should be able to easily translate from IPFIX or some hyper-compressed binary encoding to XML.

    

    

    I almost hate to say it, but if we can develop (or there already is)
    a Binary Encoding Rule(s) for XML to a very compressed format, then
    we can do the data modeling in XML, but transmit in this BER format.

    

    

      



      

        
On Mar 24, 2015, at 6:57 AM, Takeshi Takahashi <takeshi_takahashi@nict.go.jp> wrote:

Hi,

Thank you for the replies; I think I got the idea better than before.



        

          
more pliable for UDP export.  I think we could obviously examine how DOTS
and IODEF etc. may interoperate as we proceed but was beyond the scope of
the initial 00 draft.  This list is a great place to have that discussion.


        

        
It would be great if we could have such a discussion.

Below are comments on why I would like to see the XML representation in the drafts.
IODEF is just one spec of many other specs that defines XML-based information model; there are lots more that haven't been brought to IETF (e.g., stix).
If you do not provide any XML schema (in the appendix of the drafts) on this issue, the same kind of work would be taken again in the future from the XML-based community.
I think that is a waste.
I know that XML-representation is off the context of these drafts and thus authors are not that happy to cope with that, but I believe it is worth saying that here :)
It could be that Nik's draft can gain little benefit by defining xml schema since it does not need further analytics, but I feel that it is useful for Ana's draft since it expects further analysis such as big data analysis.

Thank you.
Take


-----Original Message----- From: Teague, Nik
Sent: Tuesday, March 24, 2015 12:20 AM
To: Panos Kampanakis (pkampana) ; Hedanping (Ana) ; Takeshi Takahashi ; Roman D. Danyliw ; dots@ietf.org
Cc: tt2@rc5.so-net.ne.jp
Subject: Re: [Dots] FW: Prior discussion about draft-fu-ipfix-network-security-00

Hi,

On 23/03/2015 22:54, "Panos Kampanakis (pkampana)" <pkampana@cisco.com>
wrote:



        

          
Hello,

It seems to me that the "signaling in order to mitigate DDoS" problem has
been solved already by BGP FlowSpec. I am not sure if defining more
verbose and detailed communications between network elements would add
much value, since these devices cannot do more than signalling and
mitigate.

Panos


        

        
Flowspec is very effective within the bounds of its capabilities - if a
bad actor is hammering my network with an ntp reflection attack or my web
server with a whole swathe of large udp packets then I can easily build
filters to handle that - if the bad actor is hitting my web server with a
syn flood from a massively random source pool then I have to consider rate
limiting as probably my best, but maybe not ideal, option.  If I try and
generate more than 12k flow route filters to push to either my equipment
or my service providers (depending upon whether they support Flowspec)
then things can get a little hairy.  DDoS mitigation CPE and DDoS
mitigation providers exist because the need is there - The DOTS proposal
is that effective signaling is necessary between these elements, not
specifically generic network elements, but actual elements that are
concerned with often complex attacks that a flow route filter is unable to
deal with.  If my ingress links are saturated then signaling via a tcp
oriented session can potentially result in more cycles being spent trying
to initiate and maintain a session than actual information transferÅ  and
if the connection drops then the whole thing has to start again.

Thanks,

-Nik




_______________________________________________
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


    

    

  


--------------020708030109070107050308--


From nobody Tue Mar 24 05:46: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 74D001A0046 for ; Tue, 24 Mar 2015 05:46:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.58
X-Spam-Level: *
X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=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 7vwF2rj9v_qE for ; Tue, 24 Mar 2015 05:46:34 -0700 (PDT)
Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:df0:232:300::1]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAF1B1A0019 for ; Tue, 24 Mar 2015 05:46:34 -0700 (PDT)
Received: from gw1.nict.go.jp (gw1.nict.go.jp [133.243.18.250]) by ns1.nict.go.jp  with ESMTP id t2OCkQoZ023314; Tue, 24 Mar 2015 21:46:26 +0900 (JST)
Received: from takeAsus (ssh.nict.go.jp [133.243.3.49]) by gw1.nict.go.jp  with SMTP id t2OCkKWC023300; Tue, 24 Mar 2015 21:46:22 +0900 (JST)
Message-ID: <1B74E9D1ED594F8AA7B10CE1C5A4D969@takeAsus>
From: "Takeshi Takahashi" 
To: "Robert Moskowitz" , "Eric Burger" , 
References: <358188D97DBE45F787E97C9E29B1C0A3@takeAsus>  <77FA386512F0D748BC7C02C36EB1106D955C93@szxeml557-mbs.china.huawei.com> <1C9F17D1873AFA47A969C4DD98F98A75153AC9EA@xmb-rcd-x10.cisco.com>  <0CB8640B8D094438BD4A4793DAD0F3B7@takeAsus> <10B310D1-09A0-4C9F-B01C-F25DFA360981@standardstrack.com> <55115149.2070700@htt-consult.com>
In-Reply-To: <55115149.2070700@htt-consult.com>
Date: Tue, 24 Mar 2015 07:46:03 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_034E_01D06606.944BFFF0"
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 16.4.3528.331
X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331
X-Virus-Scanned: clamav-milter 0.98.5 at zenith1
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [Dots] FW: Prior discussion about draft-fu-ipfix-network-security-00
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "List for 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, 24 Mar 2015 12:46:42 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_034E_01D06606.944BFFF0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hi Eric,

I agree on your comments, but let me remind you that we need a =
documented schema to use external XML via IODEF/IODEF-SCI.

> Let me take it from a different perspective. If we could use XML, =
would we not just use IODEF and be done with it? My understanding is we =
cannot pay the XML tax and as such need to go a different route.=20

Yes, I understand the same for the use cases that require prompt and =
automated actions.
I think this is true, though I haven=E2=80=99t done evaluation by =
myself.=20

> A well-defined data model would be very important for this effort.=20

I also agree on this point.

And I believe the outpuf these works will provide specific and practical =
data model.
I think we could consider how to reuse the output.
One example was IODEF; it can convey XML data if the schema is defined.

> With a well-defined data model, one should be able to easily translate =
from IPFIX or some hyper-compressed binary encoding to XML.

Yes, but we need a spec that defines a schema in order to list it in the =
IANA table of IODEF-SCI.
Even more, if these draft defines a schema, that can be used by =
non-IODEF techniques as well.

I am wondering if there is any negative effects of preparing a schema =
for the draft except the workload.
I have listened some discussion on XML vs JSON vs... etc. until now, but =
all of these works should be able to cope with each other regarding =
information model, I guess.

Kind regards,
Take


From: Robert Moskowitz=20
Sent: Tuesday, March 24, 2015 6:58 AM
To: Eric Burger ; dots@ietf.org=20
Subject: Re: [Dots] FW: Prior discussion about =
draft-fu-ipfix-network-security-00




On 03/24/2015 06:39 AM, Eric Burger wrote:

Let me take it from a different perspective. If we could use XML, would =
we not just use IODEF and be done with it? My understanding is we cannot =
pay the XML tax and as such need to go a different route.

A well-defined data model would be very important for this effort. With =
a well-defined data model, one should be able to easily translate from =
IPFIX or some hyper-compressed binary encoding to XML.
I almost hate to say it, but if we can develop (or there already is) a =
Binary Encoding Rule(s) for XML to a very compressed format, then we can =
do the data modeling in XML, but transmit in this BER format.


On Mar 24, 2015, at 6:57 AM, Takeshi Takahashi =
mailto:takeshi_takahashi@nict.go.jp wrote:

Hi,

Thank you for the replies; I think I got the idea better than before.

more pliable for UDP export.  I think we could obviously examine how =
DOTS
and IODEF etc. may interoperate as we proceed but was beyond the scope =
of
the initial 00 draft.  This list is a great place to have that =
discussion.
It would be great if we could have such a discussion.

Below are comments on why I would like to see the XML representation in =
the drafts.
IODEF is just one spec of many other specs that defines XML-based =
information model; there are lots more that haven't been brought to IETF =
(e.g., stix).
If you do not provide any XML schema (in the appendix of the drafts) on =
this issue, the same kind of work would be taken again in the future =
from the XML-based community.
I think that is a waste.
I know that XML-representation is off the context of these drafts and =
thus authors are not that happy to cope with that, but I believe it is =
worth saying that here :)
It could be that Nik's draft can gain little benefit by defining xml =
schema since it does not need further analytics, but I feel that it is =
useful for Ana's draft since it expects further analysis such as big =
data analysis.

Thank you.
Take


-----Original Message----- From: Teague, Nik
Sent: Tuesday, March 24, 2015 12:20 AM
To: Panos Kampanakis (pkampana) ; Hedanping (Ana) ; Takeshi Takahashi ; =
Roman D. Danyliw ; dots@ietf.org
Cc: tt2@rc5.so-net.ne.jp
Subject: Re: [Dots] FW: Prior discussion about =
draft-fu-ipfix-network-security-00

Hi,

On 23/03/2015 22:54, "Panos Kampanakis (pkampana)" =
mailto:pkampana@cisco.com
wrote:

Hello,

It seems to me that the "signaling in order to mitigate DDoS" problem =
has
been solved already by BGP FlowSpec. I am not sure if defining more
verbose and detailed communications between network elements would add
much value, since these devices cannot do more than signalling and
mitigate.

Panos
Flowspec is very effective within the bounds of its capabilities - if a
bad actor is hammering my network with an ntp reflection attack or my =
web
server with a whole swathe of large udp packets then I can easily build
filters to handle that - if the bad actor is hitting my web server with =
a
syn flood from a massively random source pool then I have to consider =
rate
limiting as probably my best, but maybe not ideal, option.  If I try and
generate more than 12k flow route filters to push to either my equipment
or my service providers (depending upon whether they support Flowspec)
then things can get a little hairy.  DDoS mitigation CPE and DDoS
mitigation providers exist because the need is there - The DOTS proposal
is that effective signaling is necessary between these elements, not
specifically generic network elements, but actual elements that are
concerned with often complex attacks that a flow route filter is unable =
to
deal with.  If my ingress links are saturated then signaling via a tcp
oriented session can potentially result in more cycles being spent =
trying
to initiate and maintain a session than actual information =
transfer=C5=A0 and
if the connection drops then the whole thing has to start again.

Thanks,

-Nik




_______________________________________________
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




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

------=_NextPart_000_034E_01D06606.944BFFF0
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable









Hi Eric,


 


I agree on your comments, but let me remind you that we need a =
documented=20
schema to use external XML via IODEF/IODEF-SCI.


 
> Let me take it from a =
different=20
perspective. If we could use XML, would we not just use IODEF and be =
done with=20
it? My understanding is we cannot pay the XML tax and as such need to go =
a=20
different route.=20

 


Yes, I understand the same for the use cases that require prompt =
and=20
automated actions.
I think this is true, though I haven=E2=80=99t =
done evaluation=20
by myself.=20

 


> A well-defined data model would be very =
important for=20
this effort. 


 


I also agree on this point.


 


And I believe the outpuf these works will provide specific and =
practical=20
data model.


I think we could consider how to reuse the output.


One example was IODEF; it can convey XML data if the schema is=20
defined.


 


> With a well-defined data model, one should be able to easily =
translate=20
from IPFIX or some hyper-compressed binary encoding to XML.


 


Yes, but we need a spec that defines a schema in order to list it =
in the=20
IANA table of IODEF-SCI.


Even more, if these draft defines a schema, that can be used by =
non-IODEF=20
techniques as well.


 


I am wondering if there is any negative effects of preparing a =
schema for=20
the draft except the workload.


I have listened some discussion on XML vs JSON vs... etc. until =
now, but=20
all of these works should be able to cope with each other regarding =
information=20
model, I guess.


 


Kind regards,


Take


 





 





Sent: Tuesday, March 24, 2015 6:58 AM


To: Eric Burger ; dots@ietf.org =



Subject: Re: [Dots] FW: Prior discussion about=20
draft-fu-ipfix-network-security-00


 





On 03/24/2015 06:39 AM, Eric Burger =
wrote:


Let me take it from a different =
perspective. If we could use XML, would we not just use IODEF and be =
done with it? My understanding is we cannot pay the XML tax and as such =
need to go a different route.

A well-defined data model would be very important for this effort. With =
a well-defined data model, one should be able to easily translate from =
IPFIX or some hyper-compressed binary encoding to =
XML.

I=20
almost hate to say it, but if we can develop (or there already is) a =
Binary=20
Encoding Rule(s) for XML to a very compressed format, then we can do the =
data=20
modeling in XML, but transmit in this BER format.




  
On Mar 24, 2015, at 6:57 AM, =
Takeshi Takahashi mailto:takeshi_takahashi@nic=
t.go.jp wrote:

Hi,

Thank you for the replies; I think I got the idea better than before.



    
more pliable for UDP =
export.  I think we could obviously examine how DOTS
and IODEF etc. may interoperate as we proceed but was beyond the scope =
of
the initial 00 draft.  This list is a great place to have that =
discussion.

It would be great if we could have =
such a discussion.

Below are comments on why I would like to see the XML representation in =
the drafts.
IODEF is just one spec of many other specs that defines XML-based =
information model; there are lots more that haven't been brought to IETF =
(e.g., stix).
If you do not provide any XML schema (in the appendix of the drafts) on =
this issue, the same kind of work would be taken again in the future =
from the XML-based community.
I think that is a waste.
I know that XML-representation is off the context of these drafts and =
thus authors are not that happy to cope with that, but I believe it is =
worth saying that here :)
It could be that Nik's draft can gain little benefit by defining xml =
schema since it does not need further analytics, but I feel that it is =
useful for Ana's draft since it expects further analysis such as big =
data analysis.

Thank you.
Take


-----Original Message----- From: Teague, Nik
Sent: Tuesday, March 24, 2015 12:20 AM
To: Panos Kampanakis (pkampana) ; Hedanping (Ana) ; Takeshi Takahashi ; =
Roman D. Danyliw ; dots@ietf.org
Cc: tt2@rc5.so-net.ne.jp
Subject: Re: [Dots] FW: Prior discussion about =
draft-fu-ipfix-network-security-00

Hi,

On 23/03/2015 22:54, "Panos Kampanakis (pkampana)" mailto:pkampana@cisco.com
wrote:



    
Hello,

It seems to me that the "signaling in order to mitigate DDoS" problem =
has
been solved already by BGP FlowSpec. I am not sure if defining more
verbose and detailed communications between network elements would add
much value, since these devices cannot do more than signalling and
mitigate.

Panos

Flowspec is very effective within the =
bounds of its capabilities - if a
bad actor is hammering my network with an ntp reflection attack or my =
web
server with a whole swathe of large udp packets then I can easily build
filters to handle that - if the bad actor is hitting my web server with =
a
syn flood from a massively random source pool then I have to consider =
rate
limiting as probably my best, but maybe not ideal, option.  If I try and
generate more than 12k flow route filters to push to either my equipment
or my service providers (depending upon whether they support Flowspec)
then things can get a little hairy.  DDoS mitigation CPE and DDoS
mitigation providers exist because the need is there - The DOTS proposal
is that effective signaling is necessary between these elements, not
specifically generic network elements, but actual elements that are
concerned with often complex attacks that a flow route filter is unable =
to
deal with.  If my ingress links are saturated then signaling via a tcp
oriented session can potentially result in more cycles being spent =
trying
to initiate and maintain a session than actual information =
transfer=C5=A0 and
if the connection drops then the whole thing has to start again.

Thanks,

-Nik




_______________________________________________
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=20
list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots


------=_NextPart_000_034E_01D06606.944BFFF0--


From nobody Tue Mar 24 06:18: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 5F6791A020D for ; Tue, 24 Mar 2015 06:18:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8vgXeIgQyrV for ; Tue, 24 Mar 2015 06:18:03 -0700 (PDT)
Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F08F1A19FE for ; Tue, 24 Mar 2015 06:18:01 -0700 (PDT)
Received: from pawpaw.sei.cmu.edu (pawpaw.sei.cmu.edu [10.64.21.22]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id t2ODHxHV008896 for ; Tue, 24 Mar 2015 09:17:59 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1427203080; bh=NWKjmRWkwfb5UHlyWClkES6f18pF5zByKWE5cmb1zZs=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version:Sender:Reply-To:Cc: In-Reply-To:References; b=AUggCEh7f9Tsb340Yep5MBxHyoaF1og749T1d9Jyg/xc7S/3rPkktMRLvtVgsERJ5 CoIY8iMbBVVHvmyuqGSD3DWgpk7Qp8BIvpy5WNU1HdAOBPrYDiqJi2Rzd4E/bzKFdi e+0Tuts9Zqcyi5e9UlJbMiLXZ3hFLpxINfqw6wwc=
Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1456) with ESMTP id t2ODHxDX012344 for ; Tue, 24 Mar 2015 09:17:59 -0400
Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0210.002; Tue, 24 Mar 2015 09:17:54 -0400
From: "Roman D. Danyliw" 
To: "dots@ietf.org" 
Thread-Topic: Volunteers to be jabber scribe and note taker
Thread-Index: AdBmNPBMAiZgyVp0ToC8iqeOD8btFA==
Date: Tue, 24 Mar 2015 13:17:54 +0000
Message-ID: <359EC4B99E040048A7131E0F4E113AFCD93D1D6E@marathon>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.64.22.6]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: [Dots] Volunteers to be jabber scribe and note taker
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "List for 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, 24 Mar 2015 13:18:04 -0000

Good morning!

Today's DOTS BOF will need a jabber scribe and note taker.  If you are will=
ing to volunteer please reply back to us. =20

Thank you,
Roman and Russ=


From amortensen@arbor.net  Tue Mar 24 06:21: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 D2EAC1A1A9E for ; Tue, 24 Mar 2015 06:21:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7QwSHSgGccA2 for ; Tue, 24 Mar 2015 06:21:01 -0700 (PDT)
Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001: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 7E8B91A1A68 for ; Tue, 24 Mar 2015 06:21:01 -0700 (PDT)
Received: by iedm5 with SMTP id m5so59931262ied.3 for ; Tue, 24 Mar 2015 06:21:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=o2uo7fuGLIdJB65C0DBSsJd5VlAmMV7FB1n1qVYT3wM=; b=UnWMzzWY+pKD3MZJukPKz+XxaTygupa7yYLlwqgKREav3ZOyzMa49OuKlBwEwmbLXl GfL6VTMO6IaCENQb6Zcbc2lGj85p8Qm53aIvcdzPKI5R7Fw/KggR6zCZzWFTRFtYgFFy nzvGC7GagBc5p01iCNoju1SZlIu8sfRkQGZ7A=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=o2uo7fuGLIdJB65C0DBSsJd5VlAmMV7FB1n1qVYT3wM=; b=SnSufWxETA1G2QPI34UGGltiqjCa0hanAI87x3s6wLoL99MZIcO9i2jqrLNoGc0soZ HPTPJwmRffYQlZcWWtN8ybkfq2e1PjMSZAiVfmhg00RNvQ1SWcwHx9jiRsJWGyaKHmAG wv/P3izH4tExeVeIH4jUt/RTbO4pc97nMj3ph3A2c3Maqdjs3takErWfiOULcDRXYOID SKuOLFvZVWwF173nG5ieqc0+lzCJYTYELYRBgwUBJDacQeNyam+y2dNqtMzSE3vlJ3nh IS8gpvgHyUME7nq83PE5Mnk1l7BzSyPKRX2iIXoZIE59CeB64ECzxMipKB6pjp2lcHjN 8Hpw==
X-Gm-Message-State: ALoCoQmS6SwfbD00l8RFGhKauzvTsUZ+vDDhGZZJCGTYVByt+ZFqhgocCevucOuYC7AEXn3r7V71
X-Received: by 10.50.118.97 with SMTP id kl1mr14974939igb.23.1427203260855; Tue, 24 Mar 2015 06:21:00 -0700 (PDT)
Received: from [172.20.7.57] (rrcs-71-41-251-196.sw.biz.rr.com. [71.41.251.196]) by mx.google.com with ESMTPSA id b1sm8520648igl.7.2015.03.24.06.21.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Mar 2015 06:21:00 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
Content-Type: text/plain; charset=windows-1252
From: Andrew Mortensen 
X-Priority: 3
In-Reply-To: <10B310D1-09A0-4C9F-B01C-F25DFA360981@standardstrack.com>
Date: Tue, 24 Mar 2015 09:20:57 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <358188D97DBE45F787E97C9E29B1C0A3@takeAsus>  <77FA386512F0D748BC7C02C36EB1106D955C93@szxeml557-mbs.china.huawei.com> <1C9F17D1873AFA47A969C4DD98F98A75153AC9EA@xmb-rcd-x10.cisco.com>  <0CB8640B8D094438BD4A4793DAD0F3B7@takeAsus> <10B310D1-09A0-4C9F-B01C-F25DFA360981@standardstrack.com>
To: Eric Burger 
X-Mailer: Apple Mail (2.2070.6)
Archived-At: 
Cc: dots@ietf.org
Subject: Re: [Dots] FW: Prior discussion about draft-fu-ipfix-network-security-00
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "List for 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, 24 Mar 2015 13:21:38 -0000

> On Mar 24, 2015, at 7:39 AM, Eric Burger  =
wrote:
>=20
> Let me take it from a different perspective. If we could use XML, =
would we not just use IODEF and be done with it? My understanding is we =
cannot pay the XML tax and as such need to go a different route.

This gets to the heart of the matter. In the case of =
draft-teague-threat-signaling-00, it is vital to keep the signaling =
packet size to a minimum. When the link is saturated the signaling =
element needs to be able to communicate protection needs in the most =
compact and most reliably delivered form possible. Small UDP packets =
stand the best chance of getting through, and the smaller the better. =
(Similarly, the HTTPS channel will not be a reliable vehicle for =
upstream acknowledgment of the signaling element=92s heartbeat/export =
during attack.)

> A well-defined data model would be very important for this effort. =
With a well-defined data model, one should be able to easily translate =
from IPFIX or some hyper-compressed binary encoding to XML.

Agreed.=20

andrew




>=20
>> On Mar 24, 2015, at 6:57 AM, Takeshi Takahashi =
 wrote:
>>=20
>> Hi,
>>=20
>> Thank you for the replies; I think I got the idea better than before.
>>=20
>>> more pliable for UDP export.  I think we could obviously examine how =
DOTS
>>> and IODEF etc. may interoperate as we proceed but was beyond the =
scope of
>>> the initial 00 draft.  This list is a great place to have that =
discussion.
>>=20
>> It would be great if we could have such a discussion.
>>=20
>> Below are comments on why I would like to see the XML representation =
in the drafts.
>> IODEF is just one spec of many other specs that defines XML-based =
information model; there are lots more that haven't been brought to IETF =
(e.g., stix).
>> If you do not provide any XML schema (in the appendix of the drafts) =
on this issue, the same kind of work would be taken again in the future =
from the XML-based community.
>> I think that is a waste.
>> I know that XML-representation is off the context of these drafts and =
thus authors are not that happy to cope with that, but I believe it is =
worth saying that here :)
>> It could be that Nik's draft can gain little benefit by defining xml =
schema since it does not need further analytics, but I feel that it is =
useful for Ana's draft since it expects further analysis such as big =
data analysis.
>>=20
>> Thank you.
>> Take
>>=20
>>=20
>> -----Original Message----- From: Teague, Nik
>> Sent: Tuesday, March 24, 2015 12:20 AM
>> To: Panos Kampanakis (pkampana) ; Hedanping (Ana) ; Takeshi Takahashi =
; Roman D. Danyliw ; dots@ietf.org
>> Cc: tt2@rc5.so-net.ne.jp
>> Subject: Re: [Dots] FW: Prior discussion about =
draft-fu-ipfix-network-security-00
>>=20
>> Hi,
>>=20
>> On 23/03/2015 22:54, "Panos Kampanakis (pkampana)" =

>> wrote:
>>=20
>>> Hello,
>>>=20
>>> It seems to me that the "signaling in order to mitigate DDoS" =
problem has
>>> been solved already by BGP FlowSpec. I am not sure if defining more
>>> verbose and detailed communications between network elements would =
add
>>> much value, since these devices cannot do more than signalling and
>>> mitigate.
>>>=20
>>> Panos
>>=20
>> Flowspec is very effective within the bounds of its capabilities - if =
a
>> bad actor is hammering my network with an ntp reflection attack or my =
web
>> server with a whole swathe of large udp packets then I can easily =
build
>> filters to handle that - if the bad actor is hitting my web server =
with a
>> syn flood from a massively random source pool then I have to consider =
rate
>> limiting as probably my best, but maybe not ideal, option.  If I try =
and
>> generate more than 12k flow route filters to push to either my =
equipment
>> or my service providers (depending upon whether they support =
Flowspec)
>> then things can get a little hairy.  DDoS mitigation CPE and DDoS
>> mitigation providers exist because the need is there - The DOTS =
proposal
>> is that effective signaling is necessary between these elements, not
>> specifically generic network elements, but actual elements that are
>> concerned with often complex attacks that a flow route filter is =
unable to
>> deal with.  If my ingress links are saturated then signaling via a =
tcp
>> oriented session can potentially result in more cycles being spent =
trying
>> to initiate and maintain a session than actual information transfer=8A =
and
>> if the connection drops then the whole thing has to start again.
>>=20
>> Thanks,
>>=20
>> -Nik
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>> 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 Tue Mar 24 06:32: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 DB6B51A1A1E for ; Tue, 24 Mar 2015 06:32:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 Vg2cYgbPN-aq for ; Tue, 24 Mar 2015 06:32:18 -0700 (PDT)
Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::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 CA10F1A1B43 for ; Tue, 24 Mar 2015 06:31:47 -0700 (PDT)
Received: by lbcmq2 with SMTP id mq2so30688938lbc.0 for ; Tue, 24 Mar 2015 06:31:46 -0700 (PDT)
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=F4gJruXVHr5cz4z7L++MLBMA3BVFR4Z+HYo43jlADu8=; b=KUV7eadcJWdoKMfC6lH79yUaCA/J4DsioR9qkHHfT3P29Wt2dyTy2STjUxJPvDkOwK i7EJs33a71mULw9LSJ7y3lGiKc2hEdz7sYHr3FS+MWjvFYZn5WsN91mIaMlE3kgjVgAA VLZIPo8A7MeGlU6daAryoe0bXYTL8HPSL9ba0UihJ8/q2UVUpBLJo1BQn/GGVHUfklqs gHedhU29oskTlusQNW3mURxDumOKGQCe/n8GAFwHDQyj1p2j1yT409D9aY4bmvlxDtJ9 ibBGfsleIkbQPdXmRITpYOD24hOjgWHoMF6cCW9HMDM9P9y1wIeotKWvHbOhw35QDGod /w1Q==
MIME-Version: 1.0
X-Received: by 10.152.178.197 with SMTP id da5mr3951897lac.56.1427203906343; Tue, 24 Mar 2015 06:31:46 -0700 (PDT)
Received: by 10.112.167.101 with HTTP; Tue, 24 Mar 2015 06:31:46 -0700 (PDT)
In-Reply-To: 
References: <358188D97DBE45F787E97C9E29B1C0A3@takeAsus>  <77FA386512F0D748BC7C02C36EB1106D955C93@szxeml557-mbs.china.huawei.com> <1C9F17D1873AFA47A969C4DD98F98A75153AC9EA@xmb-rcd-x10.cisco.com>  <0CB8640B8D094438BD4A4793DAD0F3B7@takeAsus> <10B310D1-09A0-4C9F-B01C-F25DFA360981@standardstrack.com> 
Date: Tue, 24 Mar 2015 09:31:46 -0400
Message-ID: 
From: Kathleen Moriarty 
To: Andrew Mortensen 
Content-Type: multipart/alternative; boundary=001a11340c68dc18ca051208cd56
Archived-At: 
Cc: "dots@ietf.org" 
Subject: Re: [Dots] FW: Prior discussion about draft-fu-ipfix-network-security-00
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "List for 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, 24 Mar 2015 13:32:22 -0000

--001a11340c68dc18ca051208cd56
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

With no hat on...

On Tue, Mar 24, 2015 at 9:20 AM, Andrew Mortensen 
wrote:

>
> > On Mar 24, 2015, at 7:39 AM, Eric Burger 
> wrote:
> >
> > Let me take it from a different perspective. If we could use XML, would
> we not just use IODEF and be done with it? My understanding is we cannot
> pay the XML tax and as such need to go a different route.
>
> This gets to the heart of the matter. In the case of
> draft-teague-threat-signaling-00, it is vital to keep the signaling packe=
t
> size to a minimum. When the link is saturated the signaling element needs
> to be able to communicate protection needs in the most compact and most
> reliably delivered form possible. Small UDP packets stand the best chance
> of getting through, and the smaller the better. (Similarly, the HTTPS
> channel will not be a reliable vehicle for upstream acknowledgment of the
> signaling element=E2=80=99s heartbeat/export during attack.)
>
> > A well-defined data model would be very important for this effort. With
> a well-defined data model, one should be able to easily translate from
> IPFIX or some hyper-compressed binary encoding to XML.
>

I agree that this doesn't need an XML format for the signaling proposed.  I
also think it would be important for the barrier for implementation in
devices be low, meaning use of something that may already be implemented
and kept at signaling level.

For the device types being discussed, how many of them already have IPFIX
implemented?

However, creating relationships with IODEF to embed such content either
through the mechanism to attach a file or packet in RecordData or through a
schema extending IODEF via SCI could work.  I see these efforts as
complimentary in that the proposals in DOTS don't rise to the level of
incidents and the associated analysis, but rather provide data for analysis
that could result in incident/indicator identification.

Thanks,
Kathleen



> Agreed.
>
> andrew
>
>
>
>
> >
> >> On Mar 24, 2015, at 6:57 AM, Takeshi Takahashi <
> takeshi_takahashi@nict.go.jp> wrote:
> >>
> >> Hi,
> >>
> >> Thank you for the replies; I think I got the idea better than before.
> >>
> >>> more pliable for UDP export.  I think we could obviously examine how
> DOTS
> >>> and IODEF etc. may interoperate as we proceed but was beyond the scop=
e
> of
> >>> the initial 00 draft.  This list is a great place to have that
> discussion.
> >>
> >> It would be great if we could have such a discussion.
> >>
> >> Below are comments on why I would like to see the XML representation i=
n
> the drafts.
> >> IODEF is just one spec of many other specs that defines XML-based
> information model; there are lots more that haven't been brought to IETF
> (e.g., stix).
> >> If you do not provide any XML schema (in the appendix of the drafts) o=
n
> this issue, the same kind of work would be taken again in the future from
> the XML-based community.
> >> I think that is a waste.
> >> I know that XML-representation is off the context of these drafts and
> thus authors are not that happy to cope with that, but I believe it is
> worth saying that here :)
> >> It could be that Nik's draft can gain little benefit by defining xml
> schema since it does not need further analytics, but I feel that it is
> useful for Ana's draft since it expects further analysis such as big data
> analysis.
> >>
> >> Thank you.
> >> Take
> >>
> >>
> >> -----Original Message----- From: Teague, Nik
> >> Sent: Tuesday, March 24, 2015 12:20 AM
> >> To: Panos Kampanakis (pkampana) ; Hedanping (Ana) ; Takeshi Takahashi =
;
> Roman D. Danyliw ; dots@ietf.org
> >> Cc: tt2@rc5.so-net.ne.jp
> >> Subject: Re: [Dots] FW: Prior discussion about
> draft-fu-ipfix-network-security-00
> >>
> >> Hi,
> >>
> >> On 23/03/2015 22:54, "Panos Kampanakis (pkampana)" 
> >> wrote:
> >>
> >>> Hello,
> >>>
> >>> It seems to me that the "signaling in order to mitigate DDoS" problem
> has
> >>> been solved already by BGP FlowSpec. I am not sure if defining more
> >>> verbose and detailed communications between network elements would ad=
d
> >>> much value, since these devices cannot do more than signalling and
> >>> mitigate.
> >>>
> >>> Panos
> >>
> >> Flowspec is very effective within the bounds of its capabilities - if =
a
> >> bad actor is hammering my network with an ntp reflection attack or my
> web
> >> server with a whole swathe of large udp packets then I can easily buil=
d
> >> filters to handle that - if the bad actor is hitting my web server wit=
h
> a
> >> syn flood from a massively random source pool then I have to consider
> rate
> >> limiting as probably my best, but maybe not ideal, option.  If I try a=
nd
> >> generate more than 12k flow route filters to push to either my equipme=
nt
> >> or my service providers (depending upon whether they support Flowspec)
> >> then things can get a little hairy.  DDoS mitigation CPE and DDoS
> >> mitigation providers exist because the need is there - The DOTS propos=
al
> >> is that effective signaling is necessary between these elements, not
> >> specifically generic network elements, but actual elements that are
> >> concerned with often complex attacks that a flow route filter is unabl=
e
> to
> >> deal with.  If my ingress links are saturated then signaling via a tcp
> >> oriented session can potentially result in more cycles being spent
> trying
> >> to initiate and maintain a session than actual information transfer=C5=
=A0 and
> >> if the connection drops then the whole thing has to start again.
> >>
> >> Thanks,
> >>
> >> -Nik
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> 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
>



--=20

Best regards,
Kathleen

--001a11340c68dc18ca051208cd56
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


With no hat on...

On Tue, Mar 24, 2015 at 9:20 AM, Andrew Mortensen <amo=
rtensen@arbor.net> wrote:


> On Mar 24, 2015, at 7:39 AM, Eric Burger <eburger@standardstrack.com> wrote:

>

> Let me take it from a different perspective. If we could use XML, woul=
d we not just use IODEF and be done with it? My understanding is we cannot =
pay the XML tax and as such need to go a different route.



This gets to the heart of the matter. In the case of draft-teague-th=
reat-signaling-00, it is vital to keep the signaling packet size to a minim=
um. When the link is saturated the signaling element needs to be able to co=
mmunicate protection needs in the most compact and most reliably delivered =
form possible. Small UDP packets stand the best chance of getting through, =
and the smaller the better. (Similarly, the HTTPS channel will not be a rel=
iable vehicle for upstream acknowledgment of the signaling element=E2=80=99=
s heartbeat/export during attack.)



> A well-defined data model would be very important for this effort. Wit=
h a well-defined data model, one should be able to easily translate from IP=
FIX or some hyper-compressed binary encoding to XML.

I agree that this doesn't need an XML format for t=
he signaling proposed.=C2=A0 I also think it would be important for the bar=
rier for implementation in devices be low, meaning use of something that ma=
y already be implemented and kept at signaling level.

<=
div>For the device types being discussed, how many of them already have IPF=
IX implemented?

However, creating relationship=
s with IODEF to embed such content either through the mechanism to attach a=
 file or packet in RecordData or through a schema extending IODEF via SCI c=
ould work.=C2=A0 I see these efforts as complimentary in that the proposals=
 in DOTS don't rise to the level of incidents and the associated analys=
is, but rather provide data for analysis that could result in incident/indi=
cator identification.

Thanks,
Kathleen





Agreed.



andrew










>

>> On Mar 24, 2015, at 6:57 AM, Takeshi Takahashi <takeshi_takahashi@nict.go.jp> wrote=
:

>>

>> Hi,

>>

>> Thank you for the replies; I think I got the idea better than befo=
re.

>>

>>> more pliable for UDP export.=C2=A0 I think we could obviously =
examine how DOTS

>>> and IODEF etc. may interoperate as we proceed but was beyond t=
he scope of

>>> the initial 00 draft.=C2=A0 This list is a great place to have=
 that discussion.

>>

>> It would be great if we could have such a discussion.

>>

>> Below are comments on why I would like to see the XML representati=
on in the drafts.

>> IODEF is just one spec of many other specs that defines XML-based =
information model; there are lots more that haven't been brought to IET=
F (e.g., stix).

>> If you do not provide any XML schema (in the appendix of the draft=
s) on this issue, the same kind of work would be taken again in the future =
from the XML-based community.

>> I think that is a waste.

>> I know that XML-representation is off the context of these drafts =
and thus authors are not that happy to cope with that, but I believe it is =
worth saying that here :)

>> It could be that Nik's draft can gain little benefit by defini=
ng xml schema since it does not need further analytics, but I feel that it =
is useful for Ana's draft since it expects further analysis such as big=
 data analysis.

>>

>> Thank you.

>> Take

>>

>>

>> -----Original Message----- From: Teague, Nik

>> Sent: Tuesday, March 24, 2015 12:20 AM

>> To: Panos Kampanakis (pkampana) ; Hedanping (Ana) ; Takeshi Takaha=
shi ; Roman D. Danyliw ; dots@ietf.org=


>> Cc: tt2@rc5.so-net.ne.jp

>> Subject: Re: [Dots] FW: Prior discussion about draft-fu-ipfix-netw=
ork-security-00

>>

>> Hi,

>>

>> On 23/03/2015 22:54, "Panos Kampanakis (pkampana)" <<=
a href=3D"mailto:pkampana@cisco.com">pkampana@cisco.com>

>> wrote:

>>

>>> Hello,

>>>

>>> It seems to me that the "signaling in order to mitigate D=
DoS" problem has

>>> been solved already by BGP FlowSpec. I am not sure if defining=
 more

>>> verbose and detailed communications between network elements w=
ould add

>>> much value, since these devices cannot do more than signalling=
 and

>>> mitigate.

>>>

>>> Panos

>>

>> Flowspec is very effective within the bounds of its capabilities -=
 if a

>> bad actor is hammering my network with an ntp reflection attack or=
 my web

>> server with a whole swathe of large udp packets then I can easily =
build

>> filters to handle that - if the bad actor is hitting my web server=
 with a

>> syn flood from a massively random source pool then I have to consi=
der rate

>> limiting as probably my best, but maybe not ideal, option.=C2=A0 I=
f I try and

>> generate more than 12k flow route filters to push to either my equ=
ipment

>> or my service providers (depending upon whether they support Flows=
pec)

>> then things can get a little hairy.=C2=A0 DDoS mitigation CPE and =
DDoS

>> mitigation providers exist because the need is there - The DOTS pr=
oposal

>> is that effective signaling is necessary between these elements, n=
ot

>> specifically generic network elements, but actual elements that ar=
e

>> concerned with often complex attacks that a flow route filter is u=
nable to

>> deal with.=C2=A0 If my ingress links are saturated then signaling =
via a tcp

>> oriented session can potentially result in more cycles being spent=
 trying

>> to initiate and maintain a session than actual information transfe=
r=C5=A0 and

>> if the connection drops then the whole thing has to start again.
>>

>> Thanks,

>>

>> -Nik

>>

>>

>>

>>

>> _______________________________________________

>> 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

ht=
tps://www.ietf.org/mailman/listinfo/dots





-- 
=


Best regards,
Kathleen




--001a11340c68dc18ca051208cd56--


From nobody Tue Mar 24 07: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 011051A8755 for ; Tue, 24 Mar 2015 07:15:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.611
X-Spam-Level: 
X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 v-vMLK8aOIUc for ; Tue, 24 Mar 2015 07:15:03 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8311A8753 for ; Tue, 24 Mar 2015 07:15:03 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 4C47A47661; Tue, 24 Mar 2015 14:15:02 +0000 (GMT)
Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 362E647681; Tue, 24 Mar 2015 14:15:02 +0000 (GMT)
Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 2D08D80040; Tue, 24 Mar 2015 14:15:02 +0000 (GMT)
Received: from USMA1EX-DAG1MB2.msg.corp.akamai.com (172.27.123.102) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.913.22; Tue, 24 Mar 2015 10:14:29 -0400
Received: from USMA1EX-DAG1MB2.msg.corp.akamai.com ([172.27.123.102]) by usma1ex-dag1mb2.msg.corp.akamai.com ([172.27.123.102]) with mapi id 15.00.0913.011; Tue, 24 Mar 2015 10:14:29 -0400
From: "Salz, Rich" 
To: Robert Moskowitz , Eric Burger , "dots@ietf.org" 
Thread-Topic: [Dots] FW: Prior discussion about draft-fu-ipfix-network-security-00
Thread-Index: AQHQZbIoYSEet5nfrUeQVeu01A8Lvp0rBeQAgAAy8ICAAAs2AIAAGBUAgABeRoCAAAu8gIAABRaA///iJWA=
Date: Tue, 24 Mar 2015 14:14:28 +0000
Message-ID: <81a3873e7a7c48e0993e5994f08a5b29@usma1ex-dag1mb2.msg.corp.akamai.com>
References: <358188D97DBE45F787E97C9E29B1C0A3@takeAsus>  <77FA386512F0D748BC7C02C36EB1106D955C93@szxeml557-mbs.china.huawei.com> <1C9F17D1873AFA47A969C4DD98F98A75153AC9EA@xmb-rcd-x10.cisco.com>  <0CB8640B8D094438BD4A4793DAD0F3B7@takeAsus> <10B310D1-09A0-4C9F-B01C-F25DFA360981@standardstrack.com> <55115149.2070700@htt-consult.com>
In-Reply-To: <55115149.2070700@htt-consult.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.19.113.3]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Dots] FW: Prior discussion about draft-fu-ipfix-network-security-00
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "List for 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, 24 Mar 2015 14:15:05 -0000

V2VsbCwgdGhlcmUncyBBU04uMSBYRVIgd2hpY2ggY2FuIGdvIHRvIERFUiwgd2hpY2ggSSdtIG5v
dCBzZXJpb3VzbHkgc3VnZ2VzdGluZy4gIEJ1dCB3YXMgQ0JPUiAoSUVURiBSRkMgNzA0OSkgYWxy
ZWFkeSBjb25zaWRlcmVkPw0KDQotLSAgDQpTZW5pb3IgQXJjaGl0ZWN0LCBBa2FtYWkgVGVjaG5v
bG9naWVzDQpJTTogcnNhbHpAamFiYmVyLm1lIFR3aXR0ZXI6IFJpY2hTYWx6DQoNCg0K


From nobody Tue Mar 24 08:48: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 5F07D1A8986 for ; Tue, 24 Mar 2015 08:48:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLfy82reU1mp for ; Tue, 24 Mar 2015 08:48:48 -0700 (PDT)
Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBBBB1A8AF8 for ; Tue, 24 Mar 2015 08:48:30 -0700 (PDT)
Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by shetland.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id t2OFmTMu014003 for ; Tue, 24 Mar 2015 11:48:29 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1427212109; bh=S8ldJhFdDNSXjAkAHXMixBlcqELyuv2fsRo4pJxr5lE=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version:Sender:Reply-To:Cc: In-Reply-To:References; b=RKEt+aO+iUd68M+36tV2kKgpNBNq4mdKrmQ/JA5SR1hyenceqMSepdGe0Z/fC1MTw C+tlqOqEeYJxpER4cy+WfYaEvfprQl5CWkMjl6wxqfE3y1PRZ0viUeM3AE3c5Qp9rG gp8ovRE4QNda62rSmECGc/de3egt773KOhtHeDIQ=
Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by timber.sei.cmu.edu (8.14.4/8.14.4/1456) with ESMTP id t2OFmTmt007090 for ; Tue, 24 Mar 2015 11:48:29 -0400
Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0210.002; Tue, 24 Mar 2015 11:48:29 -0400
From: "Roman D. Danyliw" 
To: "dots@ietf.org" 
Thread-Topic: Overlap with DOTS drafts to MILE
Thread-Index: AQHQZkn466+PgLhkVky8NpyqaFNMzg==
Date: Tue, 24 Mar 2015 15:48:27 +0000
Message-ID: <359EC4B99E040048A7131E0F4E113AFCD93D22A7@marathon>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.64.22.6]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: [Dots] Overlap with DOTS drafts to MILE
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "List for 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, 24 Mar 2015 15:48:50 -0000

Hello!

BOF chair hat off ...

Ignoring the necessary discussion on whether XML is appropriate occurring o=
n a separate thread, I conducted a superficial crosswalk of draft-teague-op=
en-threat-signaling-00 and draft-fu-ipfix-network-security against existing=
 MILE drafts to see how the information models line up.  There is some over=
lap.  These observations are anecdotally enumerated below.  A more detailed=
 analysis would be required if an XML representation or linkages with MILE =
was deemed appropriate.

Both DOTS drafts have various counters in their IPFIX information models, M=
ILE's IODEF (draft-ietf-mile-rfc5070-bis-11) can represent many of the them=
.  For example, draft-fu-ipfix-network-security's tcpFinTotalCount field wo=
uld look as follows in IODEF:


  
    
1.2.3.4

  
  
     1
  
  29234


However, there are certain counters such as draft-teague-open-threat-signal=
ing's Typical Pps that IODEF does not represent.

draft-teague-open-threat-signaling encodes threat information which IODEF a=
ppears could represent in the Method class.

Finally, there are packet specific features of flows (e.g., draft-fu-ipfix-=
network-security's maximumIpTotalLength) that IODEF doesn't represent.  Lik=
ewise, most of the elements of draft-teague-open-threat-signaling's JSON ch=
annel don't align with MILE's RID or IODEF.

In most cases where IODEF is lacking, there appears to be a way to create a=
n extension.

Roman =


From nobody Tue Mar 24 11:59: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 E497D1A8A80 for ; Tue, 24 Mar 2015 11:59:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.07
X-Spam-Level: 
X-Spam-Status: No, score=0.07 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_IMAGE_ONLY_12=2.059, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=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 OGKtX0Ct4n4g for ; Tue, 24 Mar 2015 11:59:31 -0700 (PDT)
Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c: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 0C4891A8A97 for ; Tue, 24 Mar 2015 11:59:31 -0700 (PDT)
Received: by wegp1 with SMTP id p1so1757598weg.1 for ; Tue, 24 Mar 2015 11:59:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:date:message-id:subject:from:to:content-type; bh=vI3Ae7MjDwjNLSdpjfzmjWAeIYcoBoLzuAsqCWVkVkY=; b=npfu1CIlNiEe3CzKAain6GIA9TXVnyZuK0ZZbvImgdb5exR7ctgpzciONAz7m8wA1N ei5nQ5HlJDaxeSsZIuLRyh5Y8Sjp6CHv/+C9H1uRGHC/gEhePDY7AoZydxyLw/dYejA7 gMZ8stxbHd2kBx/jdDEOxlgJP+hwzaydQ9GNus1F/j99UD9V95uru0UtM1qIlK4pPcnj BQVcpQg7Eve+LcdlExjePIoDLa6IcfWDrSiGKnBAsnCphNzxF+IsPAXX0T8nycFdAC6J Or3aQmAf+EcplYLyiDF5Mghb0fW5r+BEMClPn1Uzo9NIyT/n+eeo1xCeiTyxw0ivbvt9 w7yg==
MIME-Version: 1.0
X-Received: by 10.194.192.167 with SMTP id hh7mr10561101wjc.151.1427223569727;  Tue, 24 Mar 2015 11:59:29 -0700 (PDT)
Received: by 10.194.5.97 with HTTP; Tue, 24 Mar 2015 11:59:29 -0700 (PDT)
Date: Tue, 24 Mar 2015 14:59:29 -0400
Message-ID: 
From: Daniel Migault 
To: dots@ietf.org
Content-Type: multipart/alternative; boundary=047d7b8743f8e3871c05120d61f4
Archived-At: 
Subject: [Dots] Dots and Information model for threats
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "List for 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, 24 Mar 2015 18:59:37 -0000

--047d7b8743f8e3871c05120d61f4
Content-Type: text/plain; charset=UTF-8

Hi,

Looking at the coming BOF on DDoS, I would be interested to have opinions
on whether using an information model to describe the threats would be
useful to derive the appropriated events to track/measure. Appropriated
alarms could be reported in order to take the appropriated mitigating
actions.

I believe questions could be:
    - 1) Your opinion on feasibility and level of complexity?
    - 2) Your opinion on advantages in term of management, deployment...?

    - 3) Your opinion on how it could ease addressing future threats?

Feel free to make any additional comments!


-- 
Daniel Migault
Ericsson

--047d7b8743f8e3871c05120d61f4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi, 

Looking at the coming BOF on DDoS, I woul=
d be=20
interested to have opinions on whether using an information model to=20
describe the threats would be useful to derive the appropriated events=20
to track/measure. Appropriated alarms could be reported in order to take
 the appropriated mitigating actions.=C2=A0 =C2=A0 

I believe =
questions could be:
=C2=A0=C2=A0=C2=A0 - 1) Your opinion on feasibi=
lity and level of complexity?
=C2=A0=C2=A0=C2=A0 - 2) Your op=
inion on advantages in term of management, deployment...?=C2=A0 =C2=A0 
=C2=A0=C2=A0=C2=A0 - 3) Your opinion on how it cou=
ld ease addressing future threats?

Feel free to make any addit=
ional comments! 
=



-- 
Daniel Migault
Ericsson




--047d7b8743f8e3871c05120d61f4--


From nobody Tue Mar 24 12:42: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 9B69B1AC44D for ; Tue, 24 Mar 2015 12:42:41 -0700 (PDT)
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 eYZXLe38Tx92 for ; Tue, 24 Mar 2015 12:42:39 -0700 (PDT)
Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) by ietfa.amsl.com (Postfix) with ESMTP id 7C04E1A8FD2 for ; Tue, 24 Mar 2015 12:41:10 -0700 (PDT)
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, 24 Mar 2015 15:41:10 -0400
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, 24 Mar 2015 15:41:09 -0400
From: Dave Dolson 
To: "dots@ietf.org" 
Thread-Topic: A couple of comments on draft-fu-ipfix-network-security-00
Thread-Index: AdBmaKrAYhdr5ZcqS7GJlH2fvoLbrA==
Date: Tue, 24 Mar 2015 19:41:08 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.194.252]
Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9830B995ABwtlexchp2sandvi_"
MIME-Version: 1.0
Archived-At: 
Subject: [Dots] A couple of comments on draft-fu-ipfix-network-security-00
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "List for 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, 24 Mar 2015 19:42:41 -0000

--_000_E8355113905631478EFF04F5AA706E9830B995ABwtlexchp2sandvi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I haven't read the entire document, but I noticed a few things, some editor=
ial.

Section 3.1.


-          Why no mention of ipv6 addresses or prefixes? Consider providing=
 *only* ipv6, with IPv4-mapped IPv6 address (from RFC 2373) for IPv4.


-          There is an inconsistent use of 32-bit and 64-bit counters. If t=
cpSynTotalCount is 64 bits, probably octetUpstreamCount and octetDownstream=
Count should also be 64 bits.


-          I don't understand how absolute timestamps flowStartMilliseconds=
 and flowEndMilliseconds can be only 32-bit numbers.


-          Are fragmentIncomplete and fragmentFirstTooShort, etc. intended =
to be counters? They are 32-bits, but do not have "count" in their names.



-          fragmentOffestError is spelled wrong. Should be fragmentOffsetEr=
ror. (or fragmentOffsetErrorCount).




David Dolson
Senior Software Architect
Sandvine


--_000_E8355113905631478EFF04F5AA706E9830B995ABwtlexchp2sandvi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











I haven’t read the entire document, but I noti=
ced a few things, some editorial.


 


Section 3.1. 


 


-     &=
nbsp;   
Why no mention of ipv6 addresses or prefixes? Consi=
der providing *only* ipv6, with IPv4-mapped IPv6 address (from RFC 2=
373) for IPv4.


 


-     &=
nbsp;   
There is an inconsistent use of 32-bit and 64-bit c=
ounters. If tcpSynTotalCount is 64 bits, probably octetUpstreamCount and oc=
tetDownstreamCount should also be 64 bits.


 


-     &=
nbsp;   
I don’t understand how absolute timestamps fl=
owStartMilliseconds and flowEndMilliseconds can be only 32-bit numbers.


 


-     &=
nbsp;   
Are fragmentIncomplete and fragmentFirstTooShort, e=
tc. intended to be counters? They are 32-bits, but do not have “count=
” in their names.


 


-     &=
nbsp;   
fragmentOffestError is spelled wrong. Should be fra=
gmentOffsetError. (or fragmentOffsetErrorCount).


 


 


 


David Dolson


Senior Software Architect


Sandvine


 






--_000_E8355113905631478EFF04F5AA706E9830B995ABwtlexchp2sandvi_--


From nobody Tue Mar 24 13:09: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 AFAFE1A005F for ; Tue, 24 Mar 2015 13:09:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.612
X-Spam-Level: **
X-Spam-Status: No, score=2.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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 8FGhvcY88FBk for ; Tue, 24 Mar 2015 13:09:02 -0700 (PDT)
Received: from guri.nttv6.jp (guri.nttv6.jp [115.69.231.228]) by ietfa.amsl.com (Postfix) with ESMTP id 54AC31A8A71 for ; Tue, 24 Mar 2015 13:09:01 -0700 (PDT)
Received: from z.nttv6.jp (z.nttv6.jp [192.168.8.15]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id 8E3184E879; Wed, 25 Mar 2015 05:09:00 +0900 (JST)
Received: from [IPv6:::1] (fujiko.nttv6.jp [IPv6:2402:c800:ff06:136::141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 8E9513AC84; Wed, 25 Mar 2015 05:08:59 +0900 (JST)
Message-ID: <5511C45C.1000304@nttv6.jp>
Date: Wed, 25 Mar 2015 05:09:00 +0900
From: kaname nishizuka 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Daniel Migault , dots@ietf.org
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------030707090700060508090104"
Archived-At: 
Subject: Re: [Dots] Dots and Information model for threats
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "List for 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, 24 Mar 2015 20:09:03 -0000

This is a multi-part message in MIME format.
--------------030707090700060508090104
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit


I'd like to add a comment.
Regarding those points, I don't think it's good way to include the name 
of tools in the predefined list of the threat like slowloris, R.U.D.Y 
etc...,
because devices(or network) under an attack have no way to know the 
exact name of the tool which is used.

thanks,
kaname nishizuka/NTT Comminications.


On 2015/03/25 3:59, Daniel Migault wrote:
> Hi,
>
> Looking at the coming BOF on DDoS, I would be interested to have 
> opinions on whether using an information model to describe the threats 
> would be useful to derive the appropriated events to track/measure. 
> Appropriated alarms could be reported in order to take the 
> appropriated mitigating actions.
>
> I believe questions could be:
>     - 1) Your opinion on feasibility and level of complexity?
>     - 2) Your opinion on advantages in term of management, deployment...?
>     - 3) Your opinion on how it could ease addressing future threats?
>
> Feel free to make any additional comments!
>
>
> -- 
> Daniel Migault
> Ericsson
>
>
> _______________________________________________
> Dots mailing list
> Dots@ietf.org
> https://www.ietf.org/mailman/listinfo/dots


--------------030707090700060508090104
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    

    I'd like to add a comment.

    Regarding those points, I don't think it's good way to include the
    name of tools in the predefined list of the threat like slowloris,
    R.U.D.Y etc...,

    because devices(or network) under an attack have no way to know the
    exact name of the tool which is used.

    

    thanks,

    kaname nishizuka/NTT Comminications.

    

    

    
On 2015/03/25 3:59, Daniel Migault
      wrote:

    

    

      

        
Hi, 

          

          Looking at the coming BOF on DDoS, I would be interested to
          have opinions on whether using an information model to
          describe the threats would be useful to derive the
          appropriated events to track/measure. Appropriated alarms
          could be reported in order to take the appropriated mitigating
          actions.    

          

        

        I believe questions could be:

        
    - 1) Your opinion on feasibility and level of
          complexity?

        

        
    - 2) Your opinion on advantages in term of management,
          deployment...?    

        

        
    - 3) Your opinion on how it could ease addressing
          future threats?

        

        

        Feel free to make any additional comments!
        

          

        

        

        

        -- 

        

          

            
Daniel Migault

            

            
Ericsson

          

        

      

      

      

      

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


    

    

  


--------------030707090700060508090104--


From nobody Tue Mar 24 17:46: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 C81841A1B9E for ; Tue, 24 Mar 2015 17:46:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 pkC7K1OEYVl3 for ; Tue, 24 Mar 2015 17:46:14 -0700 (PDT)
Received: from nm31-vm9.bullet.mail.ne1.yahoo.com (nm31-vm9.bullet.mail.ne1.yahoo.com [98.138.229.35]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ABB31A1B85 for ; Tue, 24 Mar 2015 17:46:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1427244373; bh=TQ4A1O1aYhJWvcVjNfSnrq4eM8nCsDmq/FUsQuHSsNU=; h=Date:From:To:Subject:References:In-Reply-To:From:Subject; b=qA4eYeSDJZApa2bZiL1JfPjQQ4buUOiuOjAZfeE+KAAVDoS+SJ/Zp/xDqXYs/baUtgpkafmlFyhI+Aw6XwhClUP8tRA0np3jJ4quryPH70U4fw5tuVGlBVEGklPon6oTM5TFjSR6Mdcjhj4tO2Pv025YUvu1ERAfKPuGxAFfHRRSNasSDxSdiTiuFjfSMl5f+mko13ij5Kw2kvoYN5o7NG7ctbtAoEs0UJ3nHaFoukh8H0fQFdE/LFAQil2EeQ/WmDU2KrzuDORrNMuQWfTS+ZerZhyCsKTk0gO3KmogsKuVG4f/0sVw99K/HRX8e+5rea2ApoVadHxpkCoBq65lrA==
Received: from [127.0.0.1] by nm31.bullet.mail.ne1.yahoo.com with NNFMP; 25 Mar 2015 00:46:13 -0000
Received: from [98.138.101.132] by nm31.bullet.mail.ne1.yahoo.com with NNFMP;  25 Mar 2015 00:43:22 -0000
Received: from [216.39.60.172] by tm20.bullet.mail.ne1.yahoo.com with NNFMP; 25 Mar 2015 00:43:22 -0000
Received: from [98.138.104.97] by tm8.access.bullet.mail.gq1.yahoo.com with NNFMP; 25 Mar 2015 00:43:22 -0000
Received: from [127.0.0.1] by smtp117.sbc.mail.ne1.yahoo.com with NNFMP; 25 Mar 2015 00:43:22 -0000
X-Yahoo-Newman-Id: 495204.44078.bm@smtp117.sbc.mail.ne1.yahoo.com
X-Yahoo-Newman-Property: ymail-4
X-YMail-OSG: YPohiZQVM1knpigjWcCrexGRHTI3npi98LBGgMeeQt3mdZh 61shyi1L1ImRwTeJaZv1kkFJUwv1lrNd1UdlLdnOevRaqqPtCY6Ox0x_837U YvwGth2JIcYsAi41OjSvW6aeiEIsxuCLACZ7DZxLtbPUIi1WuYf2r08v5kdj oMUMxPS_55oLxgLrs6PbHtB5cz6LD.UQjkIdziEb4SS4KmumYN9FgKrhB5v4 0w.NEbLLrIGDp.lNEGJ84OG8BZ0Rad7DetBYvn5yCjTfTETixci.AJrkfbL_ ONlWrcA2jGOTiSoooxGyNr3Sox6GlWJXb6Tu70UR6TwOGK1VbGdLOqkSKJwZ rokNFM07jHfAGumEdqrWUwmW5owBTFJ9ALVmE28p_d47gjnXDmbDzgAIrn2A pCW2.AaavC6NO9mv3cS_VJSowh41Vne53pUN.8aVreGlN2h9AsxzxY0IcFhb Y_KrTWSgLJG.nDA4NpuRQSOdgNSj6oFnoVFKvPDgXlgTBFsOalaWTk2ijNHz csnW4ryy5bUbcPMtkpud6_EYULquFcfGpSjL1SING4TKRaWQ-
X-Yahoo-SMTP: k4ZI0GuswBDNARbl99Pre4UPA9QMzlw6Ko5oQzJbI0E-
Message-ID: <551204A9.5060406@sbcglobal.net>
Date: Tue, 24 Mar 2015 20:43:21 -0400
From: will 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: dots@ietf.org
References: <358188D97DBE45F787E97C9E29B1C0A3@takeAsus>  <77FA386512F0D748BC7C02C36EB1106D955C93@szxeml557-mbs.china.huawei.com> <1C9F17D1873AFA47A969C4DD98F98A75153AC9EA@xmb-rcd-x10.cisco.com> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Dots] FW: Prior discussion about draft-fu-ipfix-network-security-00
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "List for 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, 25 Mar 2015 00:46:15 -0000

If we are worried about trying to signal over saturated links, maybe we 
should consider using out of band signaling.

On 03/24/2015 01:20 AM, Teague, Nik wrote:
> Hi,
>
> On 23/03/2015 22:54, "Panos Kampanakis (pkampana)" 
> wrote:
>
>> Hello,
>>
>> It seems to me that the "signaling in order to mitigate DDoS" problem has
>> been solved already by BGP FlowSpec. I am not sure if defining more
>> verbose and detailed communications between network elements would add
>> much value, since these devices cannot do more than signalling and
>> mitigate.
>>
>> Panos
> Flowspec is very effective within the bounds of its capabilities - if a
> bad actor is hammering my network with an ntp reflection attack or my web
> server with a whole swathe of large udp packets then I can easily build
> filters to handle that - if the bad actor is hitting my web server with a
> syn flood from a massively random source pool then I have to consider rate
> limiting as probably my best, but maybe not ideal, option.  If I try and
> generate more than 12k flow route filters to push to either my equipment
> or my service providers (depending upon whether they support Flowspec)
> then things can get a little hairy.  DDoS mitigation CPE and DDoS
> mitigation providers exist because the need is there - The DOTS proposal
> is that effective signaling is necessary between these elements, not
> specifically generic network elements, but actual elements that are
> concerned with often complex attacks that a flow route filter is unable to
> deal with.  If my ingress links are saturated then signaling via a tcp
> oriented session can potentially result in more cycles being spent trying
> to initiate and maintain a session than actual information transferŠ and
> if the connection drops then the whole thing has to start again.
>
> Thanks,
>
> -Nik
>
>
>
>
> _______________________________________________
> Dots mailing list
> Dots@ietf.org
> https://www.ietf.org/mailman/listinfo/dots
>


From nobody Tue Mar 24 21:10: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 EB0491ACD8B for ; Tue, 24 Mar 2015 21:10:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILrI4Zv-JZLY for ; Tue, 24 Mar 2015 21:10:46 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4433E1ACD8A for ; Tue, 24 Mar 2015 21:10:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3061; q=dns/txt; s=iport; t=1427256646; x=1428466246; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=XoXUTQc9D6JU4G+ljQPPJcMLNCoPp09zwLM27cqtSbQ=; b=QJVQ3wk7VNYbF7KJtpd13HqP1A8liNQEGc4THDqApNNv1OqC5GUD2vSR O1VS2XT1McpuPvvW3UyeoTrOzgs43wgE6N+Y9pY62jPuAPTGZs4jwDpKB wuUNx+3L8VDjkemwHKjToHnOunCz9ne1nT10NI4lmChQc7LZiAqFeB/Jo s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0C8BwA7NBJV/4ENJK1cgwZSWgTEDoIxCoV1AoFMTAEBAQEBAX2EFAEBAQQBAQFrFwQCAQgRBAEBAQodBycLFAgBCAIEAQkJCIgnDcleAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLIYRFOAaDEYEWBY4ggjCGE5gIIoNub4FEfwEBAQ
X-IronPort-AV: E=Sophos;i="5.11,462,1422921600"; d="scan'208";a="135092507"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-1.cisco.com with ESMTP; 25 Mar 2015 04:10:45 +0000
Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t2P4AjOh013521 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Mar 2015 04:10:45 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.80]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Tue, 24 Mar 2015 23:10:45 -0500
From: "Panos Kampanakis (pkampana)" 
To: will , "dots@ietf.org" 
Thread-Topic: [Dots] FW: Prior discussion about draft-fu-ipfix-network-security-00
Thread-Index: AQHQZbIomCgFLJJduk2Sw02RO77S3p0rFqgAgAAy8ID//7bUcIAAbHcAgAFE7YD//+OQoA==
Date: Wed, 25 Mar 2015 04:10:44 +0000
Message-ID: <1C9F17D1873AFA47A969C4DD98F98A75153B049E@xmb-rcd-x10.cisco.com>
References: <358188D97DBE45F787E97C9E29B1C0A3@takeAsus>  <77FA386512F0D748BC7C02C36EB1106D955C93@szxeml557-mbs.china.huawei.com> <1C9F17D1873AFA47A969C4DD98F98A75153AC9EA@xmb-rcd-x10.cisco.com>  <551204A9.5060406@sbcglobal.net>
In-Reply-To: <551204A9.5060406@sbcglobal.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.247.22]
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Dots] FW: Prior discussion about draft-fu-ipfix-network-security-00
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "List for 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, 25 Mar 2015 04:10:48 -0000

I think that is a strong assumption that would simplify the problem, but pr=
obably is not very practical.

After attending the BOF today it seems the problem trying to solve here is =
signaling over saturated links and the a data representation of DDoS activi=
ty to be exchanged. For the latter, existing representations could do the j=
ob IMO, unless there is DDoS info that cannot be described. But then we wou=
ld need specific examples.

As someone put it in the BOF call today, scope should be well-defined if th=
is ends up being a WG I believe.

Panos


-----Original Message-----
From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of will
Sent: Tuesday, March 24, 2015 8:43 PM
To: dots@ietf.org
Subject: Re: [Dots] FW: Prior discussion about draft-fu-ipfix-network-secur=
ity-00

If we are worried about trying to signal over saturated links, maybe we sho=
uld consider using out of band signaling.

On 03/24/2015 01:20 AM, Teague, Nik wrote:
> Hi,
>
> On 23/03/2015 22:54, "Panos Kampanakis (pkampana)"=20
> 
> wrote:
>
>> Hello,
>>
>> It seems to me that the "signaling in order to mitigate DDoS" problem=20
>> has been solved already by BGP FlowSpec. I am not sure if defining=20
>> more verbose and detailed communications between network elements=20
>> would add much value, since these devices cannot do more than=20
>> signalling and mitigate.
>>
>> Panos
> Flowspec is very effective within the bounds of its capabilities - if=20
> a bad actor is hammering my network with an ntp reflection attack or=20
> my web server with a whole swathe of large udp packets then I can=20
> easily build filters to handle that - if the bad actor is hitting my=20
> web server with a syn flood from a massively random source pool then I=20
> have to consider rate limiting as probably my best, but maybe not=20
> ideal, option.  If I try and generate more than 12k flow route filters=20
> to push to either my equipment or my service providers (depending upon=20
> whether they support Flowspec) then things can get a little hairy. =20
> DDoS mitigation CPE and DDoS mitigation providers exist because the=20
> need is there - The DOTS proposal is that effective signaling is=20
> necessary between these elements, not specifically generic network=20
> elements, but actual elements that are concerned with often complex=20
> attacks that a flow route filter is unable to deal with.  If my=20
> ingress links are saturated then signaling via a tcp oriented session=20
> can potentially result in more cycles being spent trying to initiate=20
> and maintain a session than actual information transfer=A9 and if the con=
nection drops then the whole thing has to start again.
>
> Thanks,
>
> -Nik
>
>
>
>
> _______________________________________________
> 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 Mar 25 05:01:37 2015
Return-Path: 
X-Original-To: dots@ietfa.amsl.com
Delivered-To: dots@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7EB1ACE60 for ; Wed, 25 Mar 2015 05:01:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.34
X-Spam-Level: **
X-Spam-Status: No, score=2.34 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XqqtmZ_vNqJk for ; Wed, 25 Mar 2015 05:01:32 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A9E11ACE5A for ; Wed, 25 Mar 2015 05:01:31 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQR64070; Wed, 25 Mar 2015 12:01:29 +0000 (GMT)
Received: from SZXEMA413-HUB.china.huawei.com (10.82.72.72) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 25 Mar 2015 12:01:27 +0000
Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.144]) by SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id 14.03.0158.001; Wed, 25 Mar 2015 20:01:21 +0800
From: "Xialiang (Frank)" 
To: kaname nishizuka , Daniel Migault 
Thread-Topic: [Dots] Dots and Information model for threats
Thread-Index: AQHQZmSxnpcl0KWJ1EWeZ7Sgeiqs4Z0ridUAgAGNQuA=
Date: Wed, 25 Mar 2015 12:01:20 +0000
Message-ID: 
References:  <5511C45C.1000304@nttv6.jp>
In-Reply-To: <5511C45C.1000304@nttv6.jp>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.149.132]
Content-Type: multipart/related; boundary="_004_C02846B1344F344EB4FAA6FA7AF481F12ADA77BBSZXEMA502MBSchi_"; type="multipart/alternative"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Cc: "dots@ietf.org" 
Subject: [Dots] =?gb2312?b?tPC4tDogIERvdHMgYW5kIEluZm9ybWF0aW9uIG1vZGVs?= =?gb2312?b?IGZvciB0aHJlYXRz?=
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "List for 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, 25 Mar 2015 12:01:36 -0000

--_004_C02846B1344F344EB4FAA6FA7AF481F12ADA77BBSZXEMA502MBSchi_
Content-Type: multipart/alternative;
	boundary="_000_C02846B1344F344EB4FAA6FA7AF481F12ADA77BBSZXEMA502MBSchi_"

--_000_C02846B1344F344EB4FAA6FA7AF481F12ADA77BBSZXEMA502MBSchi_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

QWN0dWFsbHksIGZvciBkcmFmdC10ZWFndWUtb3Blbi10aHJlYXQtc2lnbmFsaW5nLTAwLCBpdKGv
cyBub3QgdGhlIGRldmljZXMgdW5kZXIgYW4gYXR0YWNrLCBidXQgdGhlIGRkb3MgbWl0aWdhdGlv
biBkZXZpY2VzIHRvIGV4Y2hhbmdlIHRoZSBldmVudCBpbmZvcm1hdGlvbi4NClNvLCB0aGUgYXR0
YWNrIHR5cGUgaW5mb3JtYXRpb24gY2FuIGJlIGV4Y2hhbmdlZCBiZXR3ZWVuIGRpZmZlcmVudCBk
ZXZpY2VzLiBUaGUgcG9pbnQgaXMgaG93IHRvIGRlZmluZSB0aGUgYXR0YWNrIHR5cGUuDQoNCkFu
b3RoZXIgaW50ZXJlc3RpbmcgcG9pbnQgaXMgaG93IHRoZSBzb2x1dGlvbiBzdXBwb3J0IHRoZSBu
ZXcgYXR0YWNrIGF3YXJlbmVzcyBhbmQgbmVnb3RpYXRpb24sIHRoaXMgZmVhdHVyZSBpcyByZWxh
dGVkIHdpdGggdGhlIGZsZXhpYmlsaXR5IGFuZCBleHRlbnNpYmlsaXR5Lg0KDQq3orz+yMs6IERv
dHMgW21haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmddILT6se0ga2FuYW1lIG5pc2hpenVrYQ0K
t6LLzcqxvOQ6IDIwMTXE6jPUwjI0yNUgMTU6MDkNCsrVvP7IyzogRGFuaWVsIE1pZ2F1bHQ7IGRv
dHNAaWV0Zi5vcmcNCtb3zOI6IFJlOiBbRG90c10gRG90cyBhbmQgSW5mb3JtYXRpb24gbW9kZWwg
Zm9yIHRocmVhdHMNCg0KDQpJJ2QgbGlrZSB0byBhZGQgYSBjb21tZW50Lg0KUmVnYXJkaW5nIHRo
b3NlIHBvaW50cywgSSBkb24ndCB0aGluayBpdCdzIGdvb2Qgd2F5IHRvIGluY2x1ZGUgdGhlIG5h
bWUgb2YgdG9vbHMgaW4gdGhlIHByZWRlZmluZWQgbGlzdCBvZiB0aGUgdGhyZWF0IGxpa2Ugc2xv
d2xvcmlzLCBSLlUuRC5ZIGV0Yy4uLiwNCmJlY2F1c2UgZGV2aWNlcyhvciBuZXR3b3JrKSB1bmRl
ciBhbiBhdHRhY2sgaGF2ZSBubyB3YXkgdG8ga25vdyB0aGUgZXhhY3QgbmFtZSBvZiB0aGUgdG9v
bCB3aGljaCBpcyB1c2VkLg0KDQp0aGFua3MsDQprYW5hbWUgbmlzaGl6dWthL05UVCBDb21taW5p
Y2F0aW9ucy4NCg0KT24gMjAxNS8wMy8yNSAzOjU5LCBEYW5pZWwgTWlnYXVsdCB3cm90ZToNCkhp
LA0KDQpMb29raW5nIGF0IHRoZSBjb21pbmcgQk9GIG9uIEREb1MsIEkgd291bGQgYmUgaW50ZXJl
c3RlZCB0byBoYXZlIG9waW5pb25zIG9uIHdoZXRoZXIgdXNpbmcgYW4gaW5mb3JtYXRpb24gbW9k
ZWwgdG8gZGVzY3JpYmUgdGhlIHRocmVhdHMgd291bGQgYmUgdXNlZnVsIHRvIGRlcml2ZSB0aGUg
YXBwcm9wcmlhdGVkIGV2ZW50cyB0byB0cmFjay9tZWFzdXJlLiBBcHByb3ByaWF0ZWQgYWxhcm1z
IGNvdWxkIGJlIHJlcG9ydGVkIGluIG9yZGVyIHRvIHRha2UgdGhlIGFwcHJvcHJpYXRlZCBtaXRp
Z2F0aW5nIGFjdGlvbnMuDQpJIGJlbGlldmUgcXVlc3Rpb25zIGNvdWxkIGJlOg0KICAgIC0gMSkg
WW91ciBvcGluaW9uIG9uIGZlYXNpYmlsaXR5IGFuZCBsZXZlbCBvZiBjb21wbGV4aXR5Pw0KICAg
IC0gMikgWW91ciBvcGluaW9uIG9uIGFkdmFudGFnZXMgaW4gdGVybSBvZiBtYW5hZ2VtZW50LCBk
ZXBsb3ltZW50Li4uPw0KICAgIC0gMykgWW91ciBvcGluaW9uIG9uIGhvdyBpdCBjb3VsZCBlYXNl
IGFkZHJlc3NpbmcgZnV0dXJlIHRocmVhdHM/DQoNCkZlZWwgZnJlZSB0byBtYWtlIGFueSBhZGRp
dGlvbmFsIGNvbW1lbnRzIQ0KW828z/HS0bG7t6K8/sjLyb6z/aGjXQ0KDQoNCi0tDQpEYW5pZWwg
TWlnYXVsdA0KRXJpY3Nzb24NCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18NCg0KRG90cyBtYWlsaW5nIGxpc3QNCg0KRG90c0BpZXRmLm9yZzxt
YWlsdG86RG90c0BpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9kb3RzDQoNCg==

--_000_C02846B1344F344EB4FAA6FA7AF481F12ADA77BBSZXEMA502MBSchi_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: quoted-printable











Actually, =
for draft-teague-open-threat-signaling-00, it=A1=AFs not the devices under =
an attack, but the ddos mitigation devices to exchange the event
 information.


So, the at=
tack type information can be exchanged between different devices. The point=
 is how to define the attack type.


 =
;


Another in=
teresting point is how the solution support the new attack awareness and ne=
gotiation, this feature is related with the flexibility and
 extensibility.


 =
;






=B7=A2=BC=FE=C8=CB:=
 Dots [mailto:dots-bounces@ietf.org]
=B4=FA=B1=ED 
kaname nishizuka

=B7=A2=CB=CD=CA=B1=BC=E4:<=
span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:=CB=CE=CC=E5;colo=
r:windowtext"> 2015=C4=EA3=D4=C224=C8=D5
 15:09

=CA=D5=BC=FE=C8=CB: Daniel Migault; dots@ietf.org

=D6=F7=CC=E2: Re: [Dots] Dots and Information model for threats






 


=


I'd like to add a comment.

Regarding those points, I don't think it's good way to include the name of =
tools in the predefined list of the threat like slowloris, R.U.D.Y etc...,<=
br>
because devices(or network) under an attack have no way to know the exact n=
ame of the tool which is used.



thanks,

kaname nishizuka/NTT Comminications.








On 2015/03/25 3:59, Daniel Miga=
ult wrote:










=
Hi, 



Looking at the coming BOF on DDoS, I would be interested to have opinions o=
n whether using an information model to describe the threats would be usefu=
l to derive the appropriated events to track/measure. Appropriated alarms c=
ould be reported in order to take
 the appropriated mitigating actions.    




I believe questions could be:




    - 1) Your op=
inion on feasibility and level of complexity?






    - 2) Your op=
inion on advantages in term of management, deployment...?   









    - 3) Your op=
inion on how it could ease addressing future threats?






Feel free to make any additional comments! 






3D"=CD=BC=CF=F1=D2=D1=B1=BB=B7=A2=BC=FE=C8=CB=










-- 








Daniel Migault






Ericsson



















_______________________________________________


Dots mailing list


Dots@ietf.org


https://www.ietf.org/mailman/listinfo/dots



 






--_000_C02846B1344F344EB4FAA6FA7AF481F12ADA77BBSZXEMA502MBSchi_--

--_004_C02846B1344F344EB4FAA6FA7AF481F12ADA77BBSZXEMA502MBSchi_
Content-Type: image/jpeg; name="~WRD000.jpg"
Content-Description: ~WRD000.jpg
Content-Disposition: inline; filename="~WRD000.jpg"; size=823;
	creation-date="Wed, 25 Mar 2015 11:50:52 GMT";
	modification-date="Wed, 25 Mar 2015 11:50:52 GMT"
Content-ID: <~WRD000.jpg>
Content-Transfer-Encoding: base64

/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a
HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy
MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABkAGQDASIA
AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA
AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3
ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm
p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA
AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx
BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK
U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3
uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3+iii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigD//2Q==

--_004_C02846B1344F344EB4FAA6FA7AF481F12ADA77BBSZXEMA502MBSchi_--


From nobody Wed Mar 25 05:12: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 705781ACE76 for ; Wed, 25 Mar 2015 05:12:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.911
X-Spam-Level: 
X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 gDJaBW3E2KK6 for ; Wed, 25 Mar 2015 05:12:37 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44A151ACE6C for ; Wed, 25 Mar 2015 05:12:37 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQR65206; Wed, 25 Mar 2015 12:12:35 +0000 (GMT)
Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 25 Mar 2015 12:12:34 +0000
Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.144]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0158.001; Wed, 25 Mar 2015 20:12:29 +0800
From: "Xialiang (Frank)" 
To: "Panos Kampanakis (pkampana)" , will 
Thread-Topic: [Dots] FW: Prior discussion about draft-fu-ipfix-network-security-00
Thread-Index: AQHQZbIoG194KPXTRmOmHM/JVOfdOZ0qPLoAgAAy8ICAAAs1AIAAGBYAgAFE7YCAADnxAIABCZOg
Date: Wed, 25 Mar 2015 12:12:28 +0000
Message-ID: 
References: <358188D97DBE45F787E97C9E29B1C0A3@takeAsus>  <77FA386512F0D748BC7C02C36EB1106D955C93@szxeml557-mbs.china.huawei.com> <1C9F17D1873AFA47A969C4DD98F98A75153AC9EA@xmb-rcd-x10.cisco.com>  <551204A9.5060406@sbcglobal.net> <1C9F17D1873AFA47A969C4DD98F98A75153B049E@xmb-rcd-x10.cisco.com>
In-Reply-To: <1C9F17D1873AFA47A969C4DD98F98A75153B049E@xmb-rcd-x10.cisco.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.149.132]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Cc: "dots@ietf.org" 
Subject: [Dots] =?utf-8?b?562U5aSNOiAgRlc6IFByaW9yIGRpc2N1c3Npb24gYWJvdXQg?= =?utf-8?q?draft-fu-ipfix-network-security-00?=
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "List for 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, 25 Mar 2015 12:12:42 -0000

QWdyZWUgd2l0aCBQYW5vcydzIGNvbW1lbnRzLiBJIGFsc28gdGhpbmsgb3VyIG1vc3QgaW1wb3J0
YW50IGpvYiByaWdodCBub3cgaXMgdG8gZGlzY3VzcyBhIGNsZWFyIHNjb3BlIG9mIERPVFMgYW5k
IHdvcmsgb3V0IGEgbmV3IGNoYXJ0ZXIuDQoNCkFub3RoZXIgcG9pbnQgSSB3YW50IHRvIG5vdGUg
aXMsIGN1cnJlbnQgdHdvIGRyYWZ0cyBhcmUgZm9yIHR3byBkaWZmZXJlbnQgc2NlbmFyaW9zLCBh
bmQgdGhleSBhcmUgYWxsIHZhbHVhYmxlIGZvciBvcGVyYXRvcnMgYW5kIHNlY3VyaXR5IHNlcnZp
Y2UgcHJvdmlkZXJzLiBTbywgd2Ugc2hvdWxkIGNvbnNpZGVyIHRoZW0gdG9nZXRoZXIgaW4gdGhl
IGJlZ2lubmluZyB0byBhdm9pZCB0aGUgdW5uZWNlc3Nhcnkgd2FzdGUuDQoNCkIuUi4NCkZyYW5r
DQoNCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujogRG90cyBbbWFpbHRvOmRvdHMt
Ym91bmNlc0BpZXRmLm9yZ10g5Luj6KGoIFBhbm9zIEthbXBhbmFraXMgKHBrYW1wYW5hKQ0K5Y+R
6YCB5pe26Ze0OiAyMDE15bm0M+aciDI05pelIDIzOjExDQrmlLbku7bkuro6IHdpbGw7IGRvdHNA
aWV0Zi5vcmcNCuS4u+mimDogUmU6IFtEb3RzXSBGVzogUHJpb3IgZGlzY3Vzc2lvbiBhYm91dCBk
cmFmdC1mdS1pcGZpeC1uZXR3b3JrLXNlY3VyaXR5LTAwDQoNCkkgdGhpbmsgdGhhdCBpcyBhIHN0
cm9uZyBhc3N1bXB0aW9uIHRoYXQgd291bGQgc2ltcGxpZnkgdGhlIHByb2JsZW0sIGJ1dCBwcm9i
YWJseSBpcyBub3QgdmVyeSBwcmFjdGljYWwuDQoNCkFmdGVyIGF0dGVuZGluZyB0aGUgQk9GIHRv
ZGF5IGl0IHNlZW1zIHRoZSBwcm9ibGVtIHRyeWluZyB0byBzb2x2ZSBoZXJlIGlzIHNpZ25hbGlu
ZyBvdmVyIHNhdHVyYXRlZCBsaW5rcyBhbmQgdGhlIGEgZGF0YSByZXByZXNlbnRhdGlvbiBvZiBE
RG9TIGFjdGl2aXR5IHRvIGJlIGV4Y2hhbmdlZC4gRm9yIHRoZSBsYXR0ZXIsIGV4aXN0aW5nIHJl
cHJlc2VudGF0aW9ucyBjb3VsZCBkbyB0aGUgam9iIElNTywgdW5sZXNzIHRoZXJlIGlzIEREb1Mg
aW5mbyB0aGF0IGNhbm5vdCBiZSBkZXNjcmliZWQuIEJ1dCB0aGVuIHdlIHdvdWxkIG5lZWQgc3Bl
Y2lmaWMgZXhhbXBsZXMuDQoNCkFzIHNvbWVvbmUgcHV0IGl0IGluIHRoZSBCT0YgY2FsbCB0b2Rh
eSwgc2NvcGUgc2hvdWxkIGJlIHdlbGwtZGVmaW5lZCBpZiB0aGlzIGVuZHMgdXAgYmVpbmcgYSBX
RyBJIGJlbGlldmUuDQoNClBhbm9zDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy
b206IERvdHMgW21haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiB3aWxs
DQpTZW50OiBUdWVzZGF5LCBNYXJjaCAyNCwgMjAxNSA4OjQzIFBNDQpUbzogZG90c0BpZXRmLm9y
Zw0KU3ViamVjdDogUmU6IFtEb3RzXSBGVzogUHJpb3IgZGlzY3Vzc2lvbiBhYm91dCBkcmFmdC1m
dS1pcGZpeC1uZXR3b3JrLXNlY3VyaXR5LTAwDQoNCklmIHdlIGFyZSB3b3JyaWVkIGFib3V0IHRy
eWluZyB0byBzaWduYWwgb3ZlciBzYXR1cmF0ZWQgbGlua3MsIG1heWJlIHdlIHNob3VsZCBjb25z
aWRlciB1c2luZyBvdXQgb2YgYmFuZCBzaWduYWxpbmcuDQoNCk9uIDAzLzI0LzIwMTUgMDE6MjAg
QU0sIFRlYWd1ZSwgTmlrIHdyb3RlOg0KPiBIaSwNCj4NCj4gT24gMjMvMDMvMjAxNSAyMjo1NCwg
IlBhbm9zIEthbXBhbmFraXMgKHBrYW1wYW5hKSIgDQo+IDxwa2FtcGFuYUBjaXNjby5jb20+DQo+
IHdyb3RlOg0KPg0KPj4gSGVsbG8sDQo+Pg0KPj4gSXQgc2VlbXMgdG8gbWUgdGhhdCB0aGUgInNp
Z25hbGluZyBpbiBvcmRlciB0byBtaXRpZ2F0ZSBERG9TIiBwcm9ibGVtIA0KPj4gaGFzIGJlZW4g
c29sdmVkIGFscmVhZHkgYnkgQkdQIEZsb3dTcGVjLiBJIGFtIG5vdCBzdXJlIGlmIGRlZmluaW5n
IA0KPj4gbW9yZSB2ZXJib3NlIGFuZCBkZXRhaWxlZCBjb21tdW5pY2F0aW9ucyBiZXR3ZWVuIG5l
dHdvcmsgZWxlbWVudHMgDQo+PiB3b3VsZCBhZGQgbXVjaCB2YWx1ZSwgc2luY2UgdGhlc2UgZGV2
aWNlcyBjYW5ub3QgZG8gbW9yZSB0aGFuIA0KPj4gc2lnbmFsbGluZyBhbmQgbWl0aWdhdGUuDQo+
Pg0KPj4gUGFub3MNCj4gRmxvd3NwZWMgaXMgdmVyeSBlZmZlY3RpdmUgd2l0aGluIHRoZSBib3Vu
ZHMgb2YgaXRzIGNhcGFiaWxpdGllcyAtIGlmIA0KPiBhIGJhZCBhY3RvciBpcyBoYW1tZXJpbmcg
bXkgbmV0d29yayB3aXRoIGFuIG50cCByZWZsZWN0aW9uIGF0dGFjayBvciANCj4gbXkgd2ViIHNl
cnZlciB3aXRoIGEgd2hvbGUgc3dhdGhlIG9mIGxhcmdlIHVkcCBwYWNrZXRzIHRoZW4gSSBjYW4g
DQo+IGVhc2lseSBidWlsZCBmaWx0ZXJzIHRvIGhhbmRsZSB0aGF0IC0gaWYgdGhlIGJhZCBhY3Rv
ciBpcyBoaXR0aW5nIG15IA0KPiB3ZWIgc2VydmVyIHdpdGggYSBzeW4gZmxvb2QgZnJvbSBhIG1h
c3NpdmVseSByYW5kb20gc291cmNlIHBvb2wgdGhlbiBJIA0KPiBoYXZlIHRvIGNvbnNpZGVyIHJh
dGUgbGltaXRpbmcgYXMgcHJvYmFibHkgbXkgYmVzdCwgYnV0IG1heWJlIG5vdCANCj4gaWRlYWws
IG9wdGlvbi4gIElmIEkgdHJ5IGFuZCBnZW5lcmF0ZSBtb3JlIHRoYW4gMTJrIGZsb3cgcm91dGUg
ZmlsdGVycyANCj4gdG8gcHVzaCB0byBlaXRoZXIgbXkgZXF1aXBtZW50IG9yIG15IHNlcnZpY2Ug
cHJvdmlkZXJzIChkZXBlbmRpbmcgdXBvbiANCj4gd2hldGhlciB0aGV5IHN1cHBvcnQgRmxvd3Nw
ZWMpIHRoZW4gdGhpbmdzIGNhbiBnZXQgYSBsaXR0bGUgaGFpcnkuDQo+IEREb1MgbWl0aWdhdGlv
biBDUEUgYW5kIEREb1MgbWl0aWdhdGlvbiBwcm92aWRlcnMgZXhpc3QgYmVjYXVzZSB0aGUgDQo+
IG5lZWQgaXMgdGhlcmUgLSBUaGUgRE9UUyBwcm9wb3NhbCBpcyB0aGF0IGVmZmVjdGl2ZSBzaWdu
YWxpbmcgaXMgDQo+IG5lY2Vzc2FyeSBiZXR3ZWVuIHRoZXNlIGVsZW1lbnRzLCBub3Qgc3BlY2lm
aWNhbGx5IGdlbmVyaWMgbmV0d29yayANCj4gZWxlbWVudHMsIGJ1dCBhY3R1YWwgZWxlbWVudHMg
dGhhdCBhcmUgY29uY2VybmVkIHdpdGggb2Z0ZW4gY29tcGxleCANCj4gYXR0YWNrcyB0aGF0IGEg
ZmxvdyByb3V0ZSBmaWx0ZXIgaXMgdW5hYmxlIHRvIGRlYWwgd2l0aC4gIElmIG15IA0KPiBpbmdy
ZXNzIGxpbmtzIGFyZSBzYXR1cmF0ZWQgdGhlbiBzaWduYWxpbmcgdmlhIGEgdGNwIG9yaWVudGVk
IHNlc3Npb24gDQo+IGNhbiBwb3RlbnRpYWxseSByZXN1bHQgaW4gbW9yZSBjeWNsZXMgYmVpbmcg
c3BlbnQgdHJ5aW5nIHRvIGluaXRpYXRlIA0KPiBhbmQgbWFpbnRhaW4gYSBzZXNzaW9uIHRoYW4g
YWN0dWFsIGluZm9ybWF0aW9uIHRyYW5zZmVyxaAgYW5kIGlmIHRoZSBjb25uZWN0aW9uIGRyb3Bz
IHRoZW4gdGhlIHdob2xlIHRoaW5nIGhhcyB0byBzdGFydCBhZ2Fpbi4NCj4NCj4gVGhhbmtzLA0K
Pg0KPiAtTmlrDQo+DQo+DQo+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fDQo+IERvdHMgbWFpbGluZyBsaXN0DQo+IERvdHNAaWV0Zi5vcmcNCj4g
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3RzDQo+DQoNCl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpEb3RzIG1haWxpbmcgbGlz
dA0KRG90c0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9k
b3RzDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpE
b3RzIG1haWxpbmcgbGlzdA0KRG90c0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9kb3RzDQo=


From nobody Wed Mar 25 06:42:52 2015
Return-Path: 
X-Original-To: dots@ietfa.amsl.com
Delivered-To: dots@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 797471A0130 for ; Wed, 25 Mar 2015 06:42:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.999
X-Spam-Level: 
X-Spam-Status: No, score=-3.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, GB_I_INVITATION=-2, 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 56UdAmSOIb9W for ; Wed, 25 Mar 2015 06:42:49 -0700 (PDT)
Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::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 0CFB61A024E for ; Wed, 25 Mar 2015 06:42:48 -0700 (PDT)
Received: by lbbug6 with SMTP id ug6so17745361lbb.3 for ; Wed, 25 Mar 2015 06:42:46 -0700 (PDT)
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 :content-type; bh=aXTWGAgHYYUcZJDlbXMl0t/w55wuW3faa+DMugfNz24=; b=rpRD8tIx+j5MYvvw5arKamjR4twiFpnwP6P2Hr2Cw+y8WX6wR1gSb8pZ9KZeKTVB89 o3qjjRdga11dKibL5gxVLUlH/Lfy4bkBvjPl78gKc0LVwGOlr+aUKiZGqSSBChZQe3LT w3+6BZMygJg1U/3wky3uxihkZOnrxc7021stXj0ZgK49xuOEsohJ5NDYAzhl2PBoQrQw NdnQzWct4wMhQilbltyQ23CSkOiJL0rbCTwJrkktISMJGG0x2RwtzDXKYH2TautpaTFY zxtZFkvFROdrGv2O3/olY28sSm0nYhDaYZJMXrvxBSlhjQgczXlxkOPiCuLoDbqR3W9e E7FA==
MIME-Version: 1.0
X-Received: by 10.152.205.73 with SMTP id le9mr2077685lac.75.1427290966515; Wed, 25 Mar 2015 06:42:46 -0700 (PDT)
Received: by 10.112.167.101 with HTTP; Wed, 25 Mar 2015 06:42:46 -0700 (PDT)
In-Reply-To: 
References: 
Date: Wed, 25 Mar 2015 09:42:46 -0400
Message-ID: 
From: Kathleen Moriarty 
To: "dots@ietf.org" 
Content-Type: multipart/alternative; boundary=001a113494680ce73805121d1324
Archived-At: 
Subject: [Dots] Fwd: Call for Papers: IAB/ISOC Workshop on Coordinating Attack Response at Internet Scale
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "List for 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, 25 Mar 2015 13:42:51 -0000

--001a113494680ce73805121d1324
Content-Type: text/plain; charset=UTF-8

I mentioned the CARIS workshop during the DOTS BoF yesterday, the
announcement from the IAB chair is included below.  We look forward to
reading your submissions, due April 3rd.

Best regards,
Kathleen

---------- Forwarded message ----------
From: IAB Chair 
Date: Wed, Mar 4, 2015 at 3:16 PM
Subject: Call for Papers: IAB/ISOC Workshop on Coordinating Attack Response
at Internet Scale
To: IETF Announce 
Cc: IETF 


Internet Architecture Board (IAB) and Internet Society (ISOC) workshop on
Coordinating Attack Response at Internet Scale (CARIS)

June 19, 2015, Intercontinental Hotel in Berlin, hosted by the 27th annual
FIRST Conference

Workshop Information: https://www.iab.org/activities/workshops/caris/

Numerous incident response efforts exist to mitigate the effects of
attacks.  Some are  operator driven focused on specific attack types, while
others are closed analysis and sharing groups spanning many attack types.
Many of the operator driven models work with members to mitigate the
effects of such attacks for all users, but how to contribute information to
these efforts is not always known or easy to discover.  Sharing within
closed community analysis centers is only practical for very large
organizations as a result of resource requirements even to be able to use
shared data.  Without coordination, these efforts are not only duplicated,
but leave out protections for small and medium sized organizations.  These
organizations may be part of the supply chain for larger organizations, a
common pathway for successful attacks.

This workshop aims to bring together operators, researchers, CSIRT team
members, service providers, vendors, information sharing and analysis
center members to discuss approaches to coordinate attack response at
Internet scale.

The day-long workshop will include a mix of invited and selected speakers
with opportunities to collaborate throughout, taking full advantage of the
tremendous value of having these diverse communities with common goals in
one room.


Submission Instructions:

Attendance at the workshop is by invitation only. There is no fee to attend
the workshop.

For existing attack-mitigation working groups, the survey at

https://internetsociety2.wufoo.com/forms/caris-workshop-organisation-template/
should
be completed by those organizations whose mitigation efforts or use case
analyses apply. The data gathered through this questionnaire, including how
to participate or contribute to your attack mitigation working group, will
be shared with all of the participants at the workshop to better enable
collaboration with your effort.
Alternatively, submit a 2-page research paper that includes some key
insight or challenge relevant to the broader group.  This may include
research topics around attack mitigation or information sharing/exchange,
success stories from your CSIRT, lessons learned, or a deep dive on a
particular topic such as privacy or trust.

Submissions accepted at: https://easychair.org/conferences/?conf=caris2015
Final Submission Deadline: 3 April 2015
Notification Deadline: 1 May 2015
Workshop Date: 19 June 2015

All attendees are required to complete the survey or submit a 2-page
research paper to the CARIS program committee via EasyChair.  Accepted
submissions will be published on the IAB website at:
https://www.iab.org/activities/workshops/caris/

Attendees will be selected based on these submissions to ensure the
workshop will be beneficial to all and has the potential to impact the
coordination of attack response at Internet scale.

Sponsored by the Internet Architecture Board and the Internet Society.
http://www.iab.org/
http://www.internetsociety.org/





-- 

Best regards,
Kathleen

--001a113494680ce73805121d1324
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I mentioned the CARIS workshop during the DOTS BoF yesterd=
ay, the announcement from the IAB chair is included below.=C2=A0 We look fo=
rward to reading your submissions, due April 3rd. =C2=A0

Best regards,
Kathleen

=
---------- Forwarded message ----------
From: IAB Chair <iab-chair@iab.org>
Date: Wed, Mar 4, 2015 at 3:16 PM
=
Subject: Call for Papers: IAB/ISOC Workshop on Coordinating Attack Response=
 at Internet Scale
To: IETF Announce <ietf-announce@ietf.org>
Cc: IETF <ietf@ietf.org>


Internet Architecture Board (IAB) and Inter=
net Society (ISOC) workshop on
Coordinat=
ing Attack Response at Internet Scale (CARIS)

June 19, 2015, Intercontinental Hotel in Berlin,=C2=A0=
hosted by the 27th annual FIRST Conference

Workshop Information:=C2=A0https://www.iab.org/=
activities/workshops/caris/=C2=A0

N=
umerous incident response efforts exist to mitigate the effects of attacks.=
=C2=A0 Some are=C2=A0=C2=A0operator driven focused on specific attack types=
, while others are closed analysis and sharing groups spanning many attack =
types.=C2=A0 Many of the operator driven models work with members to mitiga=
te the effects of such attacks for all users, but how to contribute informa=
tion to these efforts is not always known or easy to discover.=C2=A0 Sharin=
g within closed community analysis centers is only practical for very large=
 organizations as a result of resource requirements even to be able to use =
shared data.=C2=A0 Without coordination, these efforts are not only duplica=
ted, but leave out protections for small and medium sized organizations.=C2=
=A0 These organizations may be part of the supply chain for larger organiza=
tions, a common pathway for successful attacks.

Th=
is workshop aims to bring together operators, researchers, CSIRT team membe=
rs, service providers, vendors, information sharing and analysis center mem=
bers to discuss approaches to coordinate attack response at Internet scale.=
=C2=A0

The day-long workshop will include a mix of invited and sel=
ected speakers with opportunities to collaborate throughout, taking full ad=
vantage of the tremendous value of having these diverse communities with co=
mmon goals in one room.


Submission =
Instructions:
Attendance at the=
 workshop is by invitation only. There is no fee to attend the workshop.

For existing attack-mitigation working groups, the survey at
https://inte=
rnetsociety2.wufoo.com/forms/caris-workshop-organisation-template/=C2=
=A0should be completed by those organizations whose mitigation efforts or u=
se case analyses apply. The data gathered through this questionnaire, inclu=
ding how to participate or contribute to your attack mitigation working gro=
up, will be shared with all of the participants at the workshop to better e=
nable collaboration with your effort.=C2=A0
Alternatively, submit a 2-pa=
ge research paper that includes some key insight or challenge relevant to t=
he broader group.=C2=A0 This may include research topics around attack miti=
gation or information sharing/exchange, success stories from your CSIRT, le=
ssons learned, or a deep dive on a particular topic such as privacy or trus=
t.

Submissions accepted at:=C2=A0ht=
tps://easychair.org/conferences/?conf=3Dcaris2015
Final Submission Deadline: 3 April 20=
15
Notifi=
cation Deadline: 1 May 2015
Workshop Date: 19 June 2015

All attendees are required to complete the survey or submit a 2-page rese=
arch paper to the CARIS program committee via EasyChair.=C2=A0 Accepted sub=
missions will be published on the IAB website at:=C2=A0

Attendees will be selected based=
 on these submissions to ensure the workshop will be beneficial to all and =
has the potential to impact the coordination of attack response at Internet=
 scale.

Sponsored by the Internet Architecture Board and the Internet Socie=
ty.









-- 

Best regards,
Kathleen




--001a113494680ce73805121d1324--


From nobody Wed Mar 25 13:07:37 2015
Return-Path: 
X-Original-To: dots@ietfa.amsl.com
Delivered-To: dots@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E4D81AD359 for ; Wed, 25 Mar 2015 13:07:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.904
X-Spam-Level: 
X-Spam-Status: No, score=-2.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, TRACKER_ID=1.306, 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 gBdixXR_jlWs for ; Wed, 25 Mar 2015 13:07:34 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A0151A8AE8 for ; Wed, 25 Mar 2015 13:07:33 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUD21740; Wed, 25 Mar 2015 20:07:31 +0000 (GMT)
Received: from SZXEML433-HUB.china.huawei.com (10.82.67.210) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 25 Mar 2015 20:07:30 +0000
Received: from szxeml557-mbs.china.huawei.com ([169.254.6.131]) by szxeml433-hub.china.huawei.com ([10.82.67.210]) with mapi id 14.03.0158.001; Thu, 26 Mar 2015 04:07:25 +0800
From: "Hedanping (Ana)" 
To: Dave Dolson , "dots@ietf.org" 
Thread-Topic: A couple of comments on draft-fu-ipfix-network-security-00
Thread-Index: AdBmaKrAYhdr5ZcqS7GJlH2fvoLbrAAyZf5w
Date: Wed, 25 Mar 2015 20:07:24 +0000
Message-ID: <77FA386512F0D748BC7C02C36EB1106D9568B9@szxeml557-mbs.china.huawei.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.149.57]
Content-Type: multipart/alternative; boundary="_000_77FA386512F0D748BC7C02C36EB1106D9568B9szxeml557mbschina_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [Dots] A couple of comments on draft-fu-ipfix-network-security-00
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "List for 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, 25 Mar 2015 20:07:36 -0000

--_000_77FA386512F0D748BC7C02C36EB1106D9568B9szxeml557mbschina_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Dave,

Thank you very much for the comments, please see my reply inline.

> -----Original Message-----

  > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Dave Dolson

  > Sent: Wednesday, March 25, 2015 3:41 AM

  > To: dots@ietf.org

  > Subject: [Dots] A couple of comments on draft-fu-ipfix-network-security=
-00

  >

  > I haven't read the entire document, but I noticed a few things, some

  > editorial.

  >

  > Section 3.1.

  >

  > - Why no mention of ipv6 addresses or prefixes? Consider providing *onl=
y*

  > ipv6, with IPv4-mapped IPv6 address (from RFC 2373) for IPv4.

  >



Yes, IPv6 should be considered, IPFIX has ipv4 and ipv6 IEs defined separat=
ely. But *only* considering IPv6 and mapping IPv4 with IPv6 does not add to=
 much value, except it can avoid using redundant data models,



  > - There is an inconsistent use of 32-bit and 64-bit counters. If

  > tcpSynTotalCount is 64 bits, probably octetUpstreamCount and

  > octetDownstreamCount should also be 64 bits.

  >

  > - I don't understand how absolute timestamps flowStartMilliseconds and

  > flowEndMilliseconds can be only 32-bit numbers.

  >

  > - Are fragmentIncomplete and fragmentFirstTooShort, etc. intended to be

  > counters? They are 32-bits, but do not have "count" in their names.

  >

  > - fragmentOffestError is spelled wrong. Should be fragmentOffsetError. =
(or

  > fragmentOffsetErrorCount).

  >

Yes, up/down stream counters should be 64 bits.

flowStartMilliseconds/ flowEndMilliseconds should belong to dateTimeMillise=
conds.

Fragment parameters are counters with 32 bits, their names should be :

fragmentIncompleteCount

fragmentFirstTooShortCount

fragmentOffsetErrorCount

fragmentFlagErrorCount



The typos will be corrected in the next version.



Regards,

Ana



  >

  >

  > David Dolson

  > Senior Software Architect

  > Sandvine


--_000_77FA386512F0D748BC7C02C36EB1106D9568B9szxeml557mbschina_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi Dave,

Thank you very much for the =
comments, please see my reply inline.


> -----Original Message--=
---


  > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Dave =
Dolson


  > Sent: Wednesday,=
 March 25, 2015 3:41 AM


  > To: 
dots@ietf.org<=
/a>


  > Subject: [Dots] =
A couple of comments on draft-fu-ipfix-network-security-00


  > 


  > I haven̵=
7;t read the entire document, but I noticed a f=
ew things, some


  > editorial.<=
/o:p>


  > 


  > Section 3.1=
.


  > 


  > - Why no me=
ntion of ipv6 addresses or prefixes? Consider providing *only*


  > ipv6, with IPv4-=
mapped IPv6 address (from RFC 2373) for IPv4.


  > 


 


Yes, IPv6 should be consider=
ed, IPFIX has ipv4 and ipv6 IEs defined separately. But *only* consi=
dering IPv6 and mapping IPv4 with IPv6 does not add to much value, except i=
t can avoid using redundant data models,



 


  > - There is an in=
consistent use of 32-bit and 64-bit counters. If


  > tcpSynTotalCount=
 is 64 bits, probably octetUpstreamCount and


  > octetDownstreamC=
ount should also be 64 bits.


  > 


  > - I don̵=
7;t understand how absolute timestamps flowStar=
tMilliseconds and


  > flowEndMilliseco=
nds can be only 32-bit numbers.


  > 


  > - Are fragm=
entIncomplete and fragmentFirstTooShort, etc. intended to be


  > counters? They a=
re 32-bits, but do not have
&=
#8220;count” i=
n their names.


  > 


  > - fragmentO=
ffestError is spelled wrong. Should be fragmentOffsetError. (or<=
/span>


  > fragmentOffsetEr=
rorCount).


  > 


Yes, up/down stream counters=
 should be 64 bits.



flowStartMilliseconds/ flowE=
ndMilliseconds should belong to
dateTimeMilliseconds.



Fragment parameters are coun=
ters with 32 bits, their names should be :


fragmentIncompleteCount=



fragmentFirstTooShortCount


fragmentOffsetErrorCount


fragmentFlagErrorCount<=
/o:p>


 


The typos will be corrected =
in the next version.


 


Regards,

Ana


 


  > 


  > =



  > David Dolso=
n


  > Senior Software =
Architect


  > Sandvine


 






--_000_77FA386512F0D748BC7C02C36EB1106D9568B9szxeml557mbschina_--


From nobody Mon Mar 30 17:16: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 CF0E51A0110; Mon, 30 Mar 2015 17:16:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.299
X-Spam-Level: 
X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_INVITATION=-2, 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 1NT4GwseKVQa; Mon, 30 Mar 2015 17:16:47 -0700 (PDT)
Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::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 E5CE61A000F; Mon, 30 Mar 2015 17:16:46 -0700 (PDT)
Received: by lbbug6 with SMTP id ug6so992954lbb.3; Mon, 30 Mar 2015 17:16:45 -0700 (PDT)
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 :content-type; bh=YP1y8/fb0Ly6h8rZBi06usXWHhm1GLfr6+soSK1mNB4=; b=psa9s6NUgU9bSmBjk81I5So8Wqc1CvlLlOP8fhIBanRo0Svpyo67aN1hTAUyTivEa5 psfRCeutQE/akSwsBdThpJsVZylre+EyqxnQEP7Outz9b7OUPYKhmvb88nsVpUwPLR8g fX4a+A+/L+agxZZNczUKRo/HTtarX9H0t4Ps0pNLoO5nYFCP9ZvKFdc4QkGAgPbL7m3G EiEmT5hlEWIu2y2jYW3zSKljYsWeMdlPrB3jYCdmsPA/lzoNIJPNwcJOs4V9ImrbpScV q3LZR7mBLfjHMu79g+v4qXJN83+u8RRdcWzHCVogO9hYdU48GMy1Wyc8mQQv5AJdUbgC Sa2w==
MIME-Version: 1.0
X-Received: by 10.112.12.4 with SMTP id u4mr28587936lbb.4.1427761005364; Mon, 30 Mar 2015 17:16:45 -0700 (PDT)
Received: by 10.112.167.101 with HTTP; Mon, 30 Mar 2015 17:16:45 -0700 (PDT)
In-Reply-To: 
References: 
Date: Mon, 30 Mar 2015 20:16:45 -0400
Message-ID: 
From: Kathleen Moriarty 
To: IETF , MILE IETF , "dots@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11c3b3948c8b7e05128a832c
Archived-At: 
Subject: Re: [Dots] Call for Papers: IAB/ISOC Workshop on Coordinating Attack Response at Internet Scale
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "List for 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, 31 Mar 2015 00:16:50 -0000

--001a11c3b3948c8b7e05128a832c
Content-Type: text/plain; charset=UTF-8

Reminder: submissions are dues for the CARIS workshop on April 3rd.  Please
see the notification below for additional information.

On Wed, Mar 4, 2015 at 3:16 PM, IAB Chair  wrote:

> Internet Architecture Board (IAB) and Internet Society (ISOC) workshop on
> Coordinating Attack Response at Internet Scale (CARIS)
>
> June 19, 2015, Intercontinental Hotel in Berlin, hosted by the 27th annual
> FIRST Conference
>
> Workshop Information: https://www.iab.org/activities/workshops/caris/
>
> Numerous incident response efforts exist to mitigate the effects of
> attacks.  Some are  operator driven focused on specific attack types, while
> others are closed analysis and sharing groups spanning many attack types.
> Many of the operator driven models work with members to mitigate the
> effects of such attacks for all users, but how to contribute information to
> these efforts is not always known or easy to discover.  Sharing within
> closed community analysis centers is only practical for very large
> organizations as a result of resource requirements even to be able to use
> shared data.  Without coordination, these efforts are not only duplicated,
> but leave out protections for small and medium sized organizations.  These
> organizations may be part of the supply chain for larger organizations, a
> common pathway for successful attacks.
>
> This workshop aims to bring together operators, researchers, CSIRT team
> members, service providers, vendors, information sharing and analysis
> center members to discuss approaches to coordinate attack response at
> Internet scale.
>
> The day-long workshop will include a mix of invited and selected speakers
> with opportunities to collaborate throughout, taking full advantage of the
> tremendous value of having these diverse communities with common goals in
> one room.
>
>
> Submission Instructions:
>
> Attendance at the workshop is by invitation only. There is no fee to
> attend the workshop.
>
> For existing attack-mitigation working groups, the survey at
>
>
> https://internetsociety2.wufoo.com/forms/caris-workshop-organisation-template/ should
> be completed by those organizations whose mitigation efforts or use case
> analyses apply. The data gathered through this questionnaire, including how
> to participate or contribute to your attack mitigation working group, will
> be shared with all of the participants at the workshop to better enable
> collaboration with your effort.
> Alternatively, submit a 2-page research paper that includes some key
> insight or challenge relevant to the broader group.  This may include
> research topics around attack mitigation or information sharing/exchange,
> success stories from your CSIRT, lessons learned, or a deep dive on a
> particular topic such as privacy or trust.
>
> Submissions accepted at: https://easychair.org/conferences/?conf=caris2015
> Final Submission Deadline: 3 April 2015
> Notification Deadline: 1 May 2015
> Workshop Date: 19 June 2015
>
> All attendees are required to complete the survey or submit a 2-page
> research paper to the CARIS program committee via EasyChair.  Accepted
> submissions will be published on the IAB website at:
> https://www.iab.org/activities/workshops/caris/
>
> Attendees will be selected based on these submissions to ensure the
> workshop will be beneficial to all and has the potential to impact the
> coordination of attack response at Internet scale.
>
> Sponsored by the Internet Architecture Board and the Internet Society.
> http://www.iab.org/
> http://www.internetsociety.org/
>
>
>


-- 

Best regards,
Kathleen

--001a11c3b3948c8b7e05128a832c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Reminder: submissions are dues for the CARIS workshop on A=
pril 3rd.=C2=A0 Please see the notification below for additional informatio=
n.

On Wed, Mar 4, =
2015 at 3:16 PM, IAB Chair <iab-chair@iab.org> wrote:
Internet Architecture Board (IAB) and Internet Society (ISOC) wo=
rkshop on
Coordinating Attack Response a=
t Internet Scale (CARIS)

=
June 19, 2015, Intercontinental Hotel in Berlin,=C2=A0hosted by the 27th an=
nual FIRST Conference

Workshop Information:=C2=A0https://www.iab.org/activities/workshops/ca=
ris/=C2=A0

Numerous incident respon=
se efforts exist to mitigate the effects of attacks.=C2=A0 Some are=C2=A0=
=C2=A0operator driven focused on specific attack types, while others are cl=
osed analysis and sharing groups spanning many attack types.=C2=A0 Many of =
the operator driven models work with members to mitigate the effects of suc=
h attacks for all users, but how to contribute information to these efforts=
 is not always known or easy to discover.=C2=A0 Sharing within closed commu=
nity analysis centers is only practical for very large organizations as a r=
esult of resource requirements even to be able to use shared data.=C2=A0 Wi=
thout coordination, these efforts are not only duplicated, but leave out pr=
otections for small and medium sized organizations.=C2=A0 These organizatio=
ns may be part of the supply chain for larger organizations, a common pathw=
ay for successful attacks.

This workshop aims to b=
ring together operators, researchers, CSIRT team members, service providers=
, vendors, information sharing and analysis center members to discuss appro=
aches to coordinate attack response at Internet scale.=C2=A0

The d=
ay-long workshop will include a mix of invited and selected speakers with o=
pportunities to collaborate throughout, taking full advantage of the tremen=
dous value of having these diverse communities with common goals in one roo=
m.


Submission Instructions:
Attendance at the workshop is by invit=
ation only. There is no fee to attend the workshop.

For exist=
ing attack-mitigation working groups, the survey at
https://internetsociety2.wufoo.co=
m/forms/caris-workshop-organisation-template/=C2=A0should be completed =
by those organizations whose mitigation efforts or use case analyses apply.=
 The data gathered through this questionnaire, including how to participate=
 or contribute to your attack mitigation working group, will be shared with=
 all of the participants at the workshop to better enable collaboration wit=
h your effort.=C2=A0
Alternatively, submit a 2-page research paper that =
includes some key insight or challenge relevant to the broader group.=C2=A0=
 This may include research topics around attack mitigation or information s=
haring/exchange, success stories from your CSIRT, lessons learned, or a dee=
p dive on a particular topic such as privacy or trust.

Submissions accepte=
d at:=C2=A0https://easychair.org/con=
ferences/?conf=3Dcaris2015
Final Submission Deadline: 3 April 2015
Notification Deadline: 1 May =
2015
Work=
shop Date: 19 June 2015

All attendees are requ=
ired to complete the survey or submit a 2-page research paper to the CARIS =
program committee via EasyChair.=C2=A0 Accepted submissions will be publish=
ed on the IAB website at:=C2=A0

Attendees will be selected based on these submissions to =
ensure the workshop will be beneficial to all and has the potential to impa=
ct the coordination of attack response at Internet scale.

Sponsored by th=
e Internet Architecture Board and the Internet Society.









-- 

Best regards,
=
Kathleen




--001a11c3b3948c8b7e05128a832c--


From nobody Mon Mar 30 19:50: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 42C891A8A7E for ; Mon, 30 Mar 2015 19:50:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level: 
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uIsF7KSVz8Sp for ; Mon, 30 Mar 2015 19:50:05 -0700 (PDT)
Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9958F1A8A7D for ; Mon, 30 Mar 2015 19:50:05 -0700 (PDT)
Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id t2V2o4pq016923 for ; Mon, 30 Mar 2015 22:50:04 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1427770204; bh=Ws3+n9rFlcs6D9vnw/cFf/HA0ktP2cXtSICkxVr90fQ=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version:Sender:Reply-To:Cc: In-Reply-To:References; b=S0uqlXWr8OuS4xymR4uRlqIPzGbfck4tRgS58sQhzhO2vM2uvG2KlBDT2uLFWThZI QP5+wIrJzk/c/KjHpvtnEVrvFS3GzCQNtGg/XYKbB8Kk6puHKSunqOoiMXHMFYiiCr V1LH3gC9cyo0JxaNGFEepEY8Wm5KFm298Ki426wc=
Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by timber.sei.cmu.edu (8.14.4/8.14.4/1456) with ESMTP id t2V2o36u029439 for ; Mon, 30 Mar 2015 22:50:03 -0400
Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0210.002; Mon, 30 Mar 2015 22:50:03 -0400
From: "Roman D. Danyliw" 
To: "dots@ietf.org" 
Thread-Topic: IETF 92 Minutes Posted
Thread-Index: AdBrXSPOLNB9h3vxQT2UOaazRH5iUA==
Date: Tue, 31 Mar 2015 02:50:03 +0000
Message-ID: <359EC4B99E040048A7131E0F4E113AFCD93DDC8E@marathon>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.64.22.6]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: [Dots] IETF 92 Minutes Posted
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "List for 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, 31 Mar 2015 02:50:07 -0000

Hello!

The minutes from the IETF 92 DOTS BoF have been posted.  They can be read a=
t https://www.ietf.org/proceedings/92/minutes/minutes-92-dots.

Sincere thanks to Takeshi Takahashi who took them.

Please continue the conversation started in Dallas on this list.

Roman=


From nobody Tue Mar 31 07:44:37 2015
Return-Path: 
X-Original-To: dots@ietfa.amsl.com
Delivered-To: dots@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 562431ACDB9 for ; Tue, 31 Mar 2015 07:43:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.2
X-Spam-Level: 
X-Spam-Status: No, score=-99.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zt3O61NnEJY for ; Tue, 31 Mar 2015 07:42:58 -0700 (PDT)
Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id B83E81ACDAA for ; Tue, 31 Mar 2015 07:42:58 -0700 (PDT)
Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 0DF319A404C for ; Tue, 31 Mar 2015 10:42:48 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id RbFcPq-8tYCy for ; Tue, 31 Mar 2015 10:42:27 -0400 (EDT)
Received: from [192.168.2.100] (pool-96-255-133-185.washdc.fios.verizon.net [96.255.133.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 2CD349A4042 for ; Tue, 31 Mar 2015 10:42:27 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1085)
From: Russ Housley 
In-Reply-To: <359EC4B99E040048A7131E0F4E113AFCD93DDC8E@marathon>
Date: Tue, 31 Mar 2015 10:42:16 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <8DA0DB09-595A-4A07-8082-2207D2A99022@vigilsec.com>
References: <359EC4B99E040048A7131E0F4E113AFCD93DDC8E@marathon>
To: dots@ietf.org
X-Mailer: Apple Mail (2.1085)
Archived-At: 
X-Mailman-Approved-At: Tue, 31 Mar 2015 07:44:36 -0700
Subject: Re: [Dots] IETF 92 Minutes Posted
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "List for 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, 31 Mar 2015 14:43:00 -0000

There are some missing names in the draft minutes.  Please provide them =
so that we can have a complete record of the meeting.

Russ


On Mar 30, 2015, at 10:50 PM, Roman D. Danyliw wrote:

> Hello!
>=20
> The minutes from the IETF 92 DOTS BoF have been posted.  They can be =
read at https://www.ietf.org/proceedings/92/minutes/minutes-92-dots.
>=20
> Sincere thanks to Takeshi Takahashi who took them.
>=20
> Please continue the conversation started in Dallas on this list.
>=20
> Roman
>=20


From nobody Tue Mar 31 07:51: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 6C6741ACDC9 for ; Tue, 31 Mar 2015 07:51:40 -0700 (PDT)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hqj9A6lgCPjG for ; Tue, 31 Mar 2015 07:51:28 -0700 (PDT)
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 EB5011ACDC7 for ; Tue, 31 Mar 2015 07:51:22 -0700 (PDT)
Received: by qgdq107 with SMTP id q107so888537qgd.2 for ; Tue, 31 Mar 2015 07:51:22 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:accept-language:content-language:user-agent:content-type :mime-version; bh=divK50PM70zqWVKS7kjvNcsnse9n4+PzL0yLlrEErg0=; b=NNLCD+bOOmRNNr3wNrVv+9WSvqKcPZJCZxNfRrH9f/GeelBPvgXf//I3YksS1m+haO 7+lOIooIQg9tdAudEtRRI1hbbaslc5qu12bWk0yXZ050G5c+oCW5k7428enOOwcJjFAS FdS10O8MuSOwGez+YNBIevwS0fzKuoAtQqWlG1urlC5yfTECiYhxfxAxh+/xr4Duu3Ht degF+BdDxOT6K/r4cYyJq4ZWaS65bw/iz/DbmzdDcRw3tnEpttrLf6VZiroalhHOyC+7 NHPDQmgY1nc1uwrNZv9llpgkXKVxNqW0SxV6TbXztMuNqy5Pe49wF7E0+kWfiQzCF3qu RauA==
X-Gm-Message-State: ALoCoQkq4fXiVHhHfgvS7YwzToBDH7SQz1f/UlprzCZUrQZpefPDiJImcKtSdar0IIbGSiT+jTUgcWDvbmW3vteqpTLuMiq8IA==
X-Received: by 10.140.35.227 with SMTP id n90mr47163790qgn.17.1427813482050; Tue, 31 Mar 2015 07:51:22 -0700 (PDT)
Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by mx.google.com with ESMTPS id 6sm1385994qcf.1.2015.03.31.07.51.21 for  (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 31 Mar 2015 07:51:22 -0700 (PDT)
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 t2VEpLv8029756 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 31 Mar 2015 10:51:21 -0400
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 31 Mar 2015 10:51:21 -0400
From: "Teague, Nik" 
To: "dots@ietf.org" 
Thread-Topic: scope
Thread-Index: AQHQa8ImfNQMx27PokCfZQ+6rvOaCg==
Date: Tue, 31 Mar 2015 14:51:21 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.8.150116
x-originating-ip: [10.173.152.4]
Content-Type: multipart/alternative; boundary="_000_D1402CA9BC8Cnteagueverisigncom_"
MIME-Version: 1.0
Archived-At: 
Subject: [Dots] scope
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "List for 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, 31 Mar 2015 14:51:40 -0000

--_000_D1402CA9BC8Cnteagueverisigncom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi,

I hope everyone had good journeys home or onward to wherever you may be.

I wanted to follow up on the BOF and the outcomes =96 in particular I wante=
d to discuss scope, requirements and some thoughts.  Please feedback your t=
houghts/opinions=85

Firstly applicability =96 as was clear from the BOF we were defining DDoS m=
itigation devices/applications or devices which may have other functions bu=
t contain a DDoS mitigation element.  The devices/applications may have eit=
her inline or out of band detection/mitigation capabilities and may be depl=
oyed as part of a larger mitigation strategy.  Its signaling between these =
elements and an upstream or service provider that we=92re concerned with.  =
The term CPE was used which we will clarify to the term =91on-premise=92 to=
 remove any confusion as to what we=92re discussing.

These devices/applications already provide a degree of sophisticated analyt=
ics based on the traffic they observe.  The upstream element may, therefore=
, only require data relevant to its needs in identifying that an offramp is=
 desired and telemetry in order for situational awareness in providing the =
correct mitigation strategy.  As was discussed feedback from the upstream/s=
ervice provider is desirable relating to ongoing attack statistics and also=
 its conclusion.

Characteristics

Signaling:
>From discussions its clear that the signaling element should include a leve=
l of encryption/obfuscation to negate the need for additional vpns, infrast=
ructure etc.  Signaling should be lightweight and transport should not be s=
ession oriented in the classical sense.  It may be assumed likely that the =
ingress path to the on-premise device may be congested and loss should be e=
xpected and tolerated.  The ability to optimise as much information as poss=
ible into discrete packets is a definite advantage based upon the high prob=
ability of link/path congestion.

Provisioning:
A peacetime provisioning channel has proven effective in various vendor imp=
lementations for authentication, key exchange, configuration exchange etc. =
and it seems a good way to proceed since the information exchanged is usual=
ly weightier and doesn=92t have restrictions relating to a congested networ=
k.  From discussions it was suggested the on-premise device would be in the=
 best position to communicate thresholds as to when a traffic swing should =
be triggered.  The ability to simply signal (without additional qualificati=
on) that an upstream mitigation is requested is also desirable.  This may b=
e a potential in-road to enabling this on less sophisticated (re DDoS) devi=
ce types =96 e.g. If link >=3D80% then call for help.

Thanks,

-Nik


=93This message (including any attachments) is intended only for the use of=
 the individual or entity to which it is addressed, and may contain informa=
tion that is non-public, proprietary, privileged, confidential and exempt f=
rom disclosure under applicable law or may be constituted as attorney work =
product. If you are not the intended recipient, you are hereby notified tha=
t any use, dissemination, distribution, or copying of this communication is=
 strictly prohibited. If you have received this message in error, notify se=
nder immediately and delete this message immediately.=94

--_000_D1402CA9BC8Cnteagueverisigncom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <4D5C2F7C5BD9B140A49BA1099C8A1761@verisign.com>
Content-Transfer-Encoding: quoted-printable







Hi,







I hope everyone had good journeys home or onward to wherever you may b=
e.







I wanted to follow up on the BOF and the outcomes =96 in particular I =
wanted to discuss scope, requirements and some thoughts.  Please feedb=
ack your thoughts/opinions=85







Firstly applicability =96 as was clear from the BOF we were defining D=
DoS mitigation devices/applications or devices which may have other functio=
ns but contain a DDoS mitigation element.  The devices/applications ma=
y have either inline or out of band detection/mitigation
 capabilities and may be deployed as part of a larger mitigation strategy. =
 Its signaling between these elements and an upstream or service provi=
der that we=92re concerned with.  The term CPE was used which we will =
clarify to the term =91on-premise=92 to remove any
 confusion as to what we=92re discussing.







These devices/applications already provide a degree of sophisticated a=
nalytics based on the traffic they observe.  The upstream element may,=
 therefore, only require data relevant to its needs in identifying that an =
offramp is desired and telemetry in order
 for situational awareness in providing the correct mitigation strategy. &n=
bsp;As was discussed feedback from the upstream/service provider is desirab=
le relating to ongoing attack statistics and also its conclusion.







Characteristics 







Signaling:


From discussions its clear that the signaling element should include a=
 level of encryption/obfuscation to negate the need for additional vpns, in=
frastructure etc.  Signaling should be lightweight and transport shoul=
d not be session oriented in the classical
 sense.  It may be assumed likely that the ingress path to the on-prem=
ise device may be congested and loss should be expected and tolerated. &nbs=
p;The ability to optimise as much information as possible into discrete pac=
kets is a definite advantage based upon the
 high probability of link/path congestion.







Provisioning:


A peacetime provisioning channel has proven effective in various vendo=
r implementations for authentication, key exchange, configuration exchange =
etc. and it seems a good way to proceed since the information exchanged is =
usually weightier and doesn=92t have
 restrictions relating to a congested network.  From discussions it wa=
s suggested the on-premise device would be in the best position to communic=
ate thresholds as to when a traffic swing should be triggered.  The ab=
ility to simply signal (without additional
 qualification) that an upstream mitigation is requested is also desirable.=
  This may be a potential in-road to enabling this on less sophisticat=
ed (re DDoS) device types =96 e.g. If link >=3D80% then call for help.






Thanks,







-Nik












=93This message (including any attachments) is int=
ended only for the use of the individual or entity to which it is addressed=
, and may contain information that is non-public, proprietary, privileged, =
confidential and exempt from disclosure
 under applicable law or may be constituted as attorney work product. If yo=
u are not the intended recipient, you are hereby notified that any use, dis=
semination, distribution, or copying of this communication is strictly proh=
ibited. If you have received this
 message in error, notify sender immediately and delete this message immedi=
ately.=94






--_000_D1402CA9BC8Cnteagueverisigncom_--


From nobody Tue Mar 31 22:55: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 1EC6A1A88DE for ; Tue, 31 Mar 2015 22:55:54 -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 Rg1xr6ldaF_I for ; Tue, 31 Mar 2015 22:55:50 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C6561A88D5 for ; Tue, 31 Mar 2015 22:55:48 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQX80153; Wed, 01 Apr 2015 05:55:47 +0000 (GMT)
Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 1 Apr 2015 06:55:47 +0100
Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.144]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0158.001; Wed, 1 Apr 2015 13:55:40 +0800
From: "Xialiang (Frank)" 
To: "Teague, Nik" 
Thread-Topic: DOTS work scope discussion: //RE: scope
Thread-Index: AQHQa8ImfNQMx27PokCfZQ+6rvOaCp03f3nA
Date: Wed, 1 Apr 2015 05:55:39 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.135.42.200]
Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F12ADACCE1SZXEMA502MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Cc: "dots@ietf.org" 
Subject: [Dots] DOTS work scope discussion: //RE: scope
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "List for 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, 01 Apr 2015 05:55:54 -0000

--_000_C02846B1344F344EB4FAA6FA7AF481F12ADACCE1SZXEMA502MBSchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Nik,
Thank you for initiate the work scope discussion! We are walking on the rig=
ht way now~~
Here are my thoughts about DOTS works:

1.       The devices can be either DDoS mitigation devices, or normal netwo=
rk devices (router, switch). This will make the whole DOTS solution more ge=
neral for different scenarios. For example, current two drafts within DOTS =
can represent this difference. Maybe, we need an use case draft to elaborat=
e their respective values;

2.       I agree that upstream systems need to negotiate its requirements o=
r capabilities to reporting devices. This feature can save the signaling tr=
affics. It means an initialized negotiation mechanism may be needed;

3.       A mutual authentication mechanism is needed to protect the communi=
cations between the legal senders and receivers, to avoid the faked signali=
ng, fault peers, or creating new DDoS attacks, etc;

4.       To cope with the rapid evolution and change of the attack types, t=
he DOTS solution should consider the capability of openness. Which means th=
e specified information model should have the capability in semantic to def=
ine and express the new attack information;

5.       The whole architecture should not be constrained in our proposed s=
cenarios, it can be more general, more comprehensive. For example, more dev=
ices construct a mesh network to support the DOTS functions.

A suggestion: when our work scope discussion has achieved some agreement an=
d consensus, we should begin the charter work.

B.R.
Frank

From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Teague, Nik
Sent: Tuesday, March 31, 2015 10:51 PM
To: dots@ietf.org
Subject: [Dots] scope

Hi,

I hope everyone had good journeys home or onward to wherever you may be.

I wanted to follow up on the BOF and the outcomes - in particular I wanted =
to discuss scope, requirements and some thoughts.  Please feedback your tho=
ughts/opinions...

Firstly applicability - as was clear from the BOF we were defining DDoS mit=
igation devices/applications or devices which may have other functions but =
contain a DDoS mitigation element.  The devices/applications may have eithe=
r inline or out of band detection/mitigation capabilities and may be deploy=
ed as part of a larger mitigation strategy.  Its signaling between these el=
ements and an upstream or service provider that we're concerned with.  The =
term CPE was used which we will clarify to the term 'on-premise' to remove =
any confusion as to what we're discussing.

These devices/applications already provide a degree of sophisticated analyt=
ics based on the traffic they observe.  The upstream element may, therefore=
, only require data relevant to its needs in identifying that an offramp is=
 desired and telemetry in order for situational awareness in providing the =
correct mitigation strategy.  As was discussed feedback from the upstream/s=
ervice provider is desirable relating to ongoing attack statistics and also=
 its conclusion.

Characteristics

Signaling:
>From discussions its clear that the signaling element should include a leve=
l of encryption/obfuscation to negate the need for additional vpns, infrast=
ructure etc.  Signaling should be lightweight and transport should not be s=
ession oriented in the classical sense.  It may be assumed likely that the =
ingress path to the on-premise device may be congested and loss should be e=
xpected and tolerated.  The ability to optimise as much information as poss=
ible into discrete packets is a definite advantage based upon the high prob=
ability of link/path congestion.

Provisioning:
A peacetime provisioning channel has proven effective in various vendor imp=
lementations for authentication, key exchange, configuration exchange etc. =
and it seems a good way to proceed since the information exchanged is usual=
ly weightier and doesn't have restrictions relating to a congested network.=
  From discussions it was suggested the on-premise device would be in the b=
est position to communicate thresholds as to when a traffic swing should be=
 triggered.  The ability to simply signal (without additional qualification=
) that an upstream mitigation is requested is also desirable.  This may be =
a potential in-road to enabling this on less sophisticated (re DDoS) device=
 types - e.g. If link >=3D80% then call for help.

Thanks,

-Nik


"This message (including any attachments) is intended only for the use of t=
he individual or entity to which it is addressed, and may contain informati=
on that is non-public, proprietary, privileged, confidential and exempt fro=
m disclosure under applicable law or may be constituted as attorney work pr=
oduct. If you are not the intended recipient, you are hereby notified that =
any use, dissemination, distribution, or copying of this communication is s=
trictly prohibited. If you have received this message in error, notify send=
er immediately and delete this message immediately."

--_000_C02846B1344F344EB4FAA6FA7AF481F12ADACCE1SZXEMA502MBSchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi Nik,


Thank you =
for initiate the work scope discussion! We are walking on the right way now=
~~


Here are m=
y thoughts about DOTS works:



1.      
Th=
e devices can be either DDoS mitigation devices, or normal network devices =
(router, switch). This will make the whole DOTS solution
 more general for different scenarios. For example, current two drafts with=
in DOTS can represent this difference. Maybe, we need an use case draft to =
elaborate their respective values;



2.      
I =
agree that upstream systems need to negotiate its requirements or capabilit=
ies to reporting devices. This feature can save the signaling
 traffics. It means an initialized negotiation mechanism may be needed;



3.      
A =
mutual authentication mechanism is needed to protect the communications bet=
ween the legal senders and receivers, to avoid the faked
 signaling, fault peers, or creating new DDoS attacks, etc;



4.      
To=
 cope with the rapid evolution and change of the attack types, the DOTS sol=
ution should consider the capability of openness. Which
 means the specified information model should have the capability in semant=
ic to define and express the new attack information;



5.      
Th=
e whole architecture should not be constrained in our proposed scenarios, i=
t can be more general, more comprehensive. For example,
 more devices construct a mesh network to support the DOTS functions.<=
/o:p>


 =
;


A suggesti=
on: when our work scope discussion has achieved some agreement and consensu=
s, we should begin the charter work.


 =
;


B.R.<=
/o:p>


Frank=



 =
;








From: Dots [mailto:dots-bounces@ietf.org]
On Behalf Of Teague, Nik

Sent: Tuesday, March 31, 2015 10:51 PM

To: dots@ietf.org

Subject: [Dots] scope






 




Hi,






 <=
/o:p>






I hope every=
one had good journeys home or onward to wherever you may be.






 <=
/o:p>






I wanted to =
follow up on the BOF and the outcomes – in particular I wanted to dis=
cuss scope, requirements and some thoughts.  Please feedback your
 thoughts/opinions…






 <=
/o:p>






Firstly appl=
icability – as was clear from the BOF we were defining DDoS mitigatio=
n devices/applications or devices which may have other functions
 but contain a DDoS mitigation element.  The devices/applications may =
have either inline or out of band detection/mitigation capabilities and may=
 be deployed as part of a larger mitigation strategy.  Its signaling b=
etween these elements and an upstream or service
 provider that we’re concerned with.  The term CPE was used whic=
h we will clarify to the term ‘on-premise’ to remove any confus=
ion as to what we’re discussing.






 <=
/o:p>






These device=
s/applications already provide a degree of sophisticated analytics based on=
 the traffic they observe.  The upstream element may, therefore,
 only require data relevant to its needs in identifying that an offramp is =
desired and telemetry in order for situational awareness in providing the c=
orrect mitigation strategy.  As was discussed feedback from the upstre=
am/service provider is desirable relating
 to ongoing attack statistics and also its conclusion.





 <=
/o:p>






Characterist=
ics 






 <=
/o:p>






Signaling:






From discuss=
ions its clear that the signaling element should include a level of encrypt=
ion/obfuscation to negate the need for additional vpns, infrastructure
 etc.  Signaling should be lightweight and transport should not be ses=
sion oriented in the classical sense.  It may be assumed likely that t=
he ingress path to the on-premise device may be congested and loss should b=
e expected and tolerated.  The ability to
 optimise as much information as possible into discrete packets is a defini=
te advantage based upon the high probability of link/path congestion.<=
/o:p>






 <=
/o:p>






Provisioning=
:






A peacetime =
provisioning channel has proven effective in various vendor implementations=
 for authentication, key exchange, configuration exchange
 etc. and it seems a good way to proceed since the information exchanged is=
 usually weightier and doesn’t have restrictions relating to a conges=
ted network.  From discussions it was suggested the on-premise device =
would be in the best position to communicate
 thresholds as to when a traffic swing should be triggered.  The abili=
ty to simply signal (without additional qualification) that an upstream mit=
igation is requested is also desirable.  This may be a potential in-ro=
ad to enabling this on less sophisticated
 (re DDoS) device types – e.g. If link >=3D80% then call for help.=







 <=
/o:p>






Thanks,=







 <=
/o:p>






-Nik






 <=
/o:p>






 <=
/o:p>




“This message (including any attachments) i=
s intended only for the use of the individual or entity to which it is addr=
essed, and may contain information that is non-public, proprietary,
 privileged, confidential and exempt from disclosure under applicable law o=
r may be constituted as attorney work product. If you are not the intended =
recipient, you are hereby notified that any use, dissemination, distributio=
n, or copying of this communication
 is strictly prohibited. If you have received this message in error, notify=
 sender immediately and delete this message immediately.”









--_000_C02846B1344F344EB4FAA6FA7AF481F12ADACCE1SZXEMA502MBSchi_--