From nobody Wed Aug 2 03:13:29 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFB7F126BF0 for ; Wed, 2 Aug 2017 03:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8wOaNtbLKC6g for ; Wed, 2 Aug 2017 03:13:26 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A94B129B3A for ; Wed, 2 Aug 2017 03:13:26 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1dcqea-0007v3-Kt for ietf-supjps-dots@ietf.org; Wed, 02 Aug 2017 11:13:24 +0100 From: "Jon Shallow" To: Date: Wed, 2 Aug 2017 11:13:26 +0100 Message-ID: <035401d30b77$fb3a1da0$f1ae58e0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0355_01D30B80.5CFEFAD0" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AdMLd/i8iwFwzTfWQ/S7HayGj5igcA== Archived-At: Subject: [Dots] Signal / Data / Alias / Filter Implementation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for 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, 02 Aug 2017 10:13:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0355_01D30B80.5CFEFAD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi There, I am trying to get my mind around how to implement this and have some questions / statements. Signal Channel The Signal channel looks very like Destination RTBH with some extras (protocols / port) as everything is target-* based. There is no concept of source-ip, source-port (to handle reflection attacks) etc. or dealing with fragmented packet, icmp types and rate-limiting. The DOTS client may have the smarts to work out what are the problematic source-* etc. values (e.g. can generate smart BGP FlowSpec rules) are that will sensibly control the DDoS Attack. It is possible to use a previously defined alias over the Data Channel as an alternative for a mitigation request, but this too has source-* etc. limitations. I have not found a way of using a Filter defined over the Data Channel as a signal Sending a signal will cause all traffic to stop (or rate-limit possibly if it also happens to match a filter) to the target IP on the ports in question - DDoS attack is now effective unless the DOTS server elects (via DNS or BGP swing) to scrub that particular traffic (by controlling rates, Source IPs / Source Ports etc.). Data Channel Can be used to set up aliases for later use. These again however appear to be target-* based, with no source-*, icmp type or fragmentation capabilities. Can set up a Filter, which does include both source and destination IPs, but appears that it is acted on when pushed over the data channel, and cannot be send as a signal - appears to be in place more for black/white listing IPs than as a signal for mitigation, but does include rate-limiting Questions How do we handle Source-* information in a mitigation signal request? How do we handle specific ICMP types in a mitigation signal request? How do we handle fragmentation in a mitigation signal request? Regards Jon ------=_NextPart_000_0355_01D30B80.5CFEFAD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = There,

 

I am trying to get my mind around how to implement = this and have some questions / statements.

 

Signal = Channel

 

The Signal channel looks very like Destination RTBH = with some extras (protocols / port) as everything is target-* = based.  There is no concept of source-ip, source-port (to handle = reflection attacks) etc. or dealing with fragmented packet, icmp types = and rate-limiting.

 

The DOTS = client may have the smarts to work out what are the problematic source-* = etc. values (e.g. can generate smart BGP FlowSpec rules) are that will = sensibly control the DDoS Attack.

 

It is = possible to use a previously defined alias over the Data Channel as an = alternative for a mitigation request, but this too has source-* etc. = limitations.

I have not found a way = of using a Filter defined over the Data Channel as a = signal

 

Sending a signal will cause all traffic to stop (or = rate-limit possibly if it also happens to match a filter) to the target = IP on the ports in question -  DDoS attack is now effective unless = the DOTS server elects (via DNS or BGP swing) to scrub that particular = traffic (by controlling rates, Source IPs / Source Ports = etc.).

 

Data Channel

 

Can be used = to set up aliases for later use.  These again however appear to be = target-* based, with no source-*, icmp type or fragmentation = capabilities.

 

Can set up a Filter, which does include both source = and destination IPs, but appears that it is acted on when pushed over = the data channel, and cannot be send as a signal – appears to be = in place more for black/white listing IPs than as a signal for = mitigation, but does include rate-limiting

 

Questions

 

How do we = handle Source-* information in a mitigation signal = request?

How do we handle specific = ICMP types  in a mitigation signal request?

How do we handle fragmentation  in a mitigation = signal request?

 

Regards

 

Jon

 

------=_NextPart_000_0355_01D30B80.5CFEFAD0-- From nobody Wed Aug 2 03:46:39 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00A83131EB8 for ; Wed, 2 Aug 2017 03:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wIp6n6aY-srA for ; Wed, 2 Aug 2017 03:46:36 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0106.outbound.protection.outlook.com [104.47.34.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DBFF131EB7 for ; Wed, 2 Aug 2017 03:46:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=o6dgiF9VuK6jjCxnlvicM7k0LjGEZl+nD1bS0h+owXQ=; b=iu4iJjADhWCxPE4w5kZvuEmWhE7vLZwQWTFud+UgNL5MFWMVwawXfGJBE5SfbNgzZS5TC58d5VHeHEqy8YwitsC6hJDu83piip1LGZwDksyW+pn+qHWhRbuzvib2jTfgGVHfqiuAlyd9UGp7CafgrL0Rmef8GoLgpEjsbmBs3IY= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=rdobbins@arbor.net; Received: from [172.19.254.107] (49.228.111.8) by CY1PR0101MB1033.prod.exchangelabs.com (10.160.225.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1304.22; Wed, 2 Aug 2017 10:46:33 +0000 From: "Roland Dobbins" To: "Jon Shallow" Cc: dots@ietf.org Date: Wed, 02 Aug 2017 17:46:16 +0700 Message-ID: <628E4313-95D3-42F5-9DDB-00C7B4EBB4D6@arbor.net> In-Reply-To: <035401d30b77$fb3a1da0$f1ae58e0$@jpshallow.com> References: <035401d30b77$fb3a1da0$f1ae58e0$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) X-Originating-IP: [49.228.111.8] X-ClientProxiedBy: HK2PR02CA0195.apcprd02.prod.outlook.com (10.171.31.31) To CY1PR0101MB1033.prod.exchangelabs.com (10.160.225.13) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 7322aa52-5ef7-4758-b6df-08d4d993be84 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY1PR0101MB1033; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0101MB1033; 3:bBr+5cWBvN7lkp9OeiOKFYO9Tnxb1OEm03NOd3XzuXyBeEiIKHwMLJW+nIjwi+F34jiaydiVkmOlYGDZhXh5K7BzkcvkyH2qrc3rFwnB76i9MO2Caiq8Bou/45Vvvz3Js6A4aIDZuFVKLfST9qDIB0gLGrykg7faL7rDx7q+9sOUBkcWryu2eWrsqwx9qT5EMc8dqOpqQ8o7hOOxjeArS6f11sTQ7FhUowFH0re8HFfMP8aigH4GzOoBQhZ27lbKh6/oDjNO9n23kOfyxb8BhRl/vYZubUHdtobhoqi+A21Ih5N0TtAB2/Yro1UsvNatIb9gC8WTKnD/4NKNVgWpm2vvTR/ne5NDOYQMQnpgx+8+D4rGA2GSotwMe1sZiF2z+9SKpUVwtzx/gwdJdXV2/PDgW5/LhuVBOvPpwDtkVGVhB5cp+Ai01uW2AqBjJ7HBxJIcBbuUsCz10y284ob2izbI3UkhiZAktB0B0ttGvGiJLuc6qpU5rsvmhnmOgzeGJtr0ye7b3cAb5UybVErs/+M+KmvGPlPne12LZ/QCaokXD8RaDd1yEMLsQv4n24TWaw9F0U4OWY6F4PFxRGsuLUtdaz6kDqEO/0InRYK+u+GNzKpwLkN0+idRwuvoccw8aQueVHNy5Fv3a0WShfjiARGN9scwu1Ms1FrD7uCKgrLYFpoDxzXM6IVC84Qe+qfLxm+RZQA+tPqdAvv/Zw8mO+lnaNj92Bn4UBFT55/iR/ksvmDkPnuvco0Xa7vgd9kKjjW0Mat6+AG0sHYCtsPiTMcxotlWBDsw6HEIXRhXzf8= X-MS-TrafficTypeDiagnostic: CY1PR0101MB1033: X-Microsoft-Exchange-Diagnostics: 1; CY1PR0101MB1033; 25:wOG11vkOdDoH5tBoA0fyi+gYirSAq3HV4MkF4nHlSR0SYjG1M4Q5y2gxgyc16PHzBasTZvEp5jqJ/eRkV4JgnxZkOF8hDClAgCg+3jRl9AwaF+lnJxx4oMwDPNR7MNccXZJdkD6nPOVWlX5vVq2juq2O5nHAkIyvLd2P1fSDgKtm20jJIoxBkIa09+6zzGzZFvVORX0T+rPq9/kv2Z5eLmRqkllbbXTSPAU2fmk52nx2jXM+5EC93jFVpj6ohV9qwFk1F+U84/kFPUJCloI7TavXd0XmWEbMrotbnz7r8984OVPa1Psq/qathrbIipOL+I+88SkC5Zsz8MF3uH6akbfbaAtDkpx2+EDUAmaqFfJDX4ecKMiEG/Q/HW7zkQm3YTQEL8jc5rHij4uQr5/H2LwQ7L/PChGiPPTrDeicvHqOEIQRELJ6gwKMwmpKV62or0IXOZnTt26EHU6DhcZH7C3DX29H4lkiwu9eSzY5K8BjhLA0cxlreTiSmcPbV0I278i0iJFK5SstLf46Ea92klqyWjXO2EDUZL9ZjkMznA27roqpbBs7b7LDjyLfrVrW0bNRvJABVWtvmA2hERrg3/c8slCQqvOcyJmAiIwWH598VjztY6DUmnTgBkGk3H2U/1GVV7i0KId1OClPIpmvV5cPmMfQzJ+DPiwFCcVVoq+Z8riVvVYYNqdUUyGhsXShr0I+n2zspUtw3vjkYLTqMwWGlF+5cRzcJEmXeKXMAmQoWkhLN9VkGGRz+zcd4tLXqZCtNkU26awYuTblSMHgKvfU29goTnuBqQL8HWS7Hv+CfAEBCisaicXrdQtIxcsHD9nZ4pnQvPuYT3keKj/n2YgNAQDrGvxhLa1R0K9NLS5oOKO8JUJoEC1YCkzJtUPpxoOsFpr7XKBfQMjy4ACdgH04vdYAV61kmlWmpLPqfHo= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0101MB1033; 31:N3ftJi+DOKY6X5z3XhiaM+7/yI8Uc+/mlhjcoFSnJ/FrtKBEUC7K31i/BHTSi1Y89q+lxfNTaMn59WWqYhYEVAUEYiEMSeDF5OcKMVfECea3Z1cxr92msCLQMlodPFe2FnFRcR1JdAEyA0ZvTDgvog+tCMEJc56adcIR7LyFDymJcFrRJVvtdUjB2C5+kdL2SXNyXme9LqOAG4v17uiIbMZNEgUj4i+NG3Qr1Xn2lj4kq43rKf9791Cezgb/dsXriTsalURVAogmJ3T2i13LCmK2yu0kdkyuiQpk7uoz+kncHDK9Me8drQUHzodxjXMzKvpUt9/e/Lftih2sSVdqcI90zX6WIRYwgNSBc5eRIIr23xw45ogZz0CAk3Iq1t2g+wqGxkdKMvvQKR2Z9s4aek+qXfeVK5gma+Yy8PjwzY1JKlgtrl8HJ8qGhZBjVMv6Ork/iUWcrni0MugjtM5k69cIs72pAAIcI/UkReUXq6YhFmVDFHY0xw5Z2L+GbJd2L337NuJB5JZxPWQImrht4iRhxpbXKLUPtYo2khTQVzjhcSXpaAnpm9rA1vuZDvx3PsIa7tGf0Oy0F/uFapaPFVCLh2EWFkivZ2QjB9CPFZWfYbsndh7ttrd6OBkyfQqDDGhJTxJFNl/fVXmBtyI//+Ielr2YL1pawdEpZYk+fZqchYaCDJ/Ca5DfrUepF3u4 X-Microsoft-Exchange-Diagnostics: 1; CY1PR0101MB1033; 20:/MxxEGKLFUjd1wEWh4eemGxWhqblMfFAF0RMjx3L83eyJuOyKu4tVHKAcbhl8e1BaxdvhS5Cd4+L/xSt06rx4IEnzPC5Pf+Q7nt+asGKw2eqZZV+S5KhgqpSJffo8oVf8pI5mocc3+OkKzD94WRNfxIg8k+xtNlf9gQSHiih4b17W/NDOPcN4Uk1hab0l/DLBeKf62a0SjfXJbn/+gl48TphcHJvNsJWm/2Bkg3X3bvhV7yKe8aXPmECnSEy9gTDNiFef5vDI/eN9Rv4BxWoxQwNuyGrpfwD7pT1XTBiIQFGqh1kNHF8KUwUODK5RthZfkkUQ19SkYYXdhXbbGZvJUAmVtl1lHA6EjLp5GLCbJcGiuxUb9JHBzlsIYBseGspn6ZAe85eHi4XkK0hmqgZBhFeFvqo9+Hm9/Onkv1ELr0xhRqNaee0lMJgdhg+U/R7rkGZA6J9OOqwNPfAQon5/tsuWyITZK0cvBRXmSbHYUocImMpnrMuJHKdxpMYuHUI X-Exchange-Antispam-Report-Test: UriScan:(158342451672863); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123564025)(20161123560025)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR0101MB1033; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR0101MB1033; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR0101MB1033; 4:p3WSq0aHwfu7lIYdzjhUOeR1ruvAie2PP0kwD+iv?= =?us-ascii?Q?7Kdw63uQD/+K3rnvzidGscB9zaMsy1LlxD+KJyAhjPPLA+kRdZZwroO0L2x9?= =?us-ascii?Q?RnJPYvo/danZTFjGiBFZZgxqFJOzRQwn+xMAPyUZATBqdYum9YrnpLiWUeMq?= =?us-ascii?Q?Vx2CAFZMiflgJmktKPjLsE+ChAQJiPvnsk+87+lAva7bteCvkfG7HJoDyr20?= =?us-ascii?Q?SxgS/RdFspXxoQvSd3SCb1boXRKeQ3oInpYAVQJ/sg15IxZEm/cdV0LORFWX?= =?us-ascii?Q?K4pPrOPXFiTkfvRvLEvQ8ePFabAWbJ55a5QQWQRL6C+DQjyQFVnMUm61jShF?= =?us-ascii?Q?MW8qBFx26RRkx3EYjEgxA4zbauLQOpoetVML6FAqlTeGPGWjOfDxj5UinsLp?= =?us-ascii?Q?9w+k/a11xyNeVQbu6G5lO4BIqxKdRjSNwLRaVE7u5DYa5zOSgt8oHe1oImvS?= =?us-ascii?Q?WDN+63lpvLNASDZWAJF+/sz4fq9vKiA6F6SR45a56cD2Kag/rBQtEGndImon?= =?us-ascii?Q?tZHEqfWHVuNjblE1QLzhGjKmV1dEZcOJ++8r/B/uLNO4fXS6SDVYWVK+Fgp8?= =?us-ascii?Q?wGljIZ+rPMcyP84yOnvLMU/2vrViznUYEwm++LsDCHgjxvtHMqBWK4GfrtNN?= =?us-ascii?Q?IVmRENZpqieYR3GjhYBpVQhshJkH4dh1n5MmVAF/x7J0LJV1edtQDXCR0RDo?= =?us-ascii?Q?rMlt5HZ0FVVSDzBK4fPDQZvEwt/7RYdvZcrC4zumVZm+WO/3HtYFLIDmyKky?= =?us-ascii?Q?ZtfaqqxdhlPJ+hOpgRRYspqJDihm3ZDfPmU3IuCU5N2rV8i1kQlt0uvR7fPS?= =?us-ascii?Q?7c5c5PQXuKXr6vhnDZHn0VKPDo6xVFFw/kG9FJs3sZHdyb9YzCUU5YlJvvFY?= =?us-ascii?Q?Efs6+0zRhuUMCzh577tZ6tZO7LgZ3jzcXIzTQZ6VddM2Clvyoozch0eFDHaR?= =?us-ascii?Q?waBhKUQRppjNu3ZaW8RShWgdbXBGs9CzpEy+iOGEXEfAHZd+zmqmWOvRgR3M?= =?us-ascii?Q?X/Bh0afR+UsDdLYEWQQGmuwUXHeiDQkna4mE2eRDTQD7nolsPDjZBUYfwC53?= =?us-ascii?Q?v5D+4P02wh66ndDAGoUwNJXT9u/vQ/+kp26pgreqspLGgsX+M9m01DhSq/bt?= =?us-ascii?Q?feNqwgPsLFtDqc2lTBU/61BlS1LTI2Bhwk/GbpAmg3EJ73AzUGV4AQ=3D=3D?= X-Forefront-PRVS: 0387D64A71 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(7370300001)(4630300001)(6049001)(6009001)(39400400002)(39410400002)(39840400002)(39450400003)(199003)(189002)(24454002)(50226002)(53936002)(86362001)(68736007)(97736004)(33656002)(66066001)(106356001)(105586002)(2906002)(7350300001)(47776003)(36756003)(8676002)(81166006)(189998001)(81156014)(6116002)(3846002)(42186005)(305945005)(5660300001)(7736002)(5003940100001)(50986999)(53546010)(76176999)(82746002)(50466002)(6916009)(478600001)(6666003)(2950100002)(25786009)(4326008)(6246003)(90366009)(6486002)(83716003)(229853002)(77096006)(101416001)(110136004)(38730400002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0101MB1033; H:[172.19.254.107]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: arbor.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR0101MB1033; 23:l4XTGdZJUckplxz05jE+1O4lM1nhulIkLu3awnw?= =?us-ascii?Q?WYUjvFzP5pqgKgedgOB7HCPr8jqdxuU6aKWGurRJ4Bk3nbR5hqrHCtBjUfDO?= =?us-ascii?Q?uljcxiJWL4zJoDNF1xMYdWXUHlnJNA1ORvF9y3Fy7nFvwlPqjVh4kHslag2c?= =?us-ascii?Q?NY9v6SvHyZ+vxZMhUAZj2TCbc/U63EPrpai/3Kmp0OH8+Kw8bXUxvdaezV4T?= =?us-ascii?Q?7lAdFoJV7V0lq+HQUl1YhMMRjth2IIW7rkZJ5IPj55/QuMCgHL9HxtwpNGcl?= =?us-ascii?Q?+J8az+MUBDfLyHDSwfTHu57gTDplLP8D/2SGaZXpjLwQfc+5Dsynyg1036Cv?= =?us-ascii?Q?IDyAnOJurb44g/uilRgDQhHPo8rn5V5Bc/ck6/I1ZkJiBKWQI1u6AsX8lvM4?= =?us-ascii?Q?N76kKNUj8ppAILHOLPj+0HsiFk9cWk5g8xNdse8W8GklUcCBvTpyYlzRTnJm?= =?us-ascii?Q?QrDZDf+dsFRVHAi0iiGtWx3yWA3qxC3lblccfzSp/pIfhVkka0Q4H//1N1dD?= =?us-ascii?Q?KMlUgaGhdhH1dfv31WHGUdzHtzxN50YJ0MiT+5ZbVfEXRRzPfkWFrfJYThX8?= =?us-ascii?Q?hjeyVefHnf5sIF8ex6PgVfKRFuNA2BxpE1ukRlZhUdJL/8XoxySOs+E1Pxvj?= =?us-ascii?Q?mvPAJ7c8JZS+HxrRLCK2YYIgJ3y9g5CaD6ahRKeh3AZZTS5I2n7oxtaQIvCs?= =?us-ascii?Q?uyNpL8lMXicUuVc+ex/xj4socT3oxzfzRXAp24oXX+zE2AB6LsxS+4e8Vqaq?= =?us-ascii?Q?5xgPVdUOPLybgEXziYOB3plBGlAflFsTsPItHmpqj9iZv0BKNFMxun/Knbiu?= =?us-ascii?Q?geQr08CbMFmvSkflel79a/bSd3bb/w+/ktwyNpNH/ueD4GYb3dt7TvjxpLYo?= =?us-ascii?Q?4qK6QIz0fdReUyX1xyEQuAh1cx40NOopnokN+HDcpg/8D8jJX6j45TT4AW1c?= =?us-ascii?Q?Kn9A4nhShA+bN4Jn0m9LaqxWH3qMNCS69cwHK5W94j6eQ9q6RUZthpi23dQY?= =?us-ascii?Q?rdZRL6JUGutQUgAlF7uOLCbiUEU/2Y7yZsGv6AoQ7HMbH6mpLrsD28Js7Co3?= =?us-ascii?Q?M7u/yNUuq0rt6CPniG2aAfDpSpzMbk2HbwgvMKlA4Itsa+YwNLyn7zuldflY?= =?us-ascii?Q?Ag8IoO3aiUkS5/tX1rw+S+lWcN8AEMMLDUrfvQhjMGp2SOX9UDQdUizwssDm?= =?us-ascii?Q?MN/nYD2XIOP2Ojas1+ONhm8QtP0XovZyEZUkPVI6/5VTQgdtdr8/chPCJaC8?= =?us-ascii?Q?5pnzS5VyFXIL6NJ2P1utFGUv1oh57woQli15YMjBkW4hoVtvYC27lIR8BqPP?= =?us-ascii?Q?Ed23z/x3q+zcs3vE0uEMYECuPcjkWz52TgEBfjYEjESi7NKcAV2MT1yVE7+I?= =?us-ascii?Q?clB4I7g=3D=3D?= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR0101MB1033; 6:ILLenVmaxHDPgFs/aJkCu+d5pwbtoPl14Xb2TTDm?= =?us-ascii?Q?Z+sCHfLfqjTgEbMvYWsGEg/zTJ/YdH7iatE54NqV4eHBXmbyVWB1rrCNS2eK?= =?us-ascii?Q?mENcNlxUeT9s2T8sxDtFhclp2+ZToKcbMU+2uS3HJNztTOFdzK7rN2U61tpJ?= =?us-ascii?Q?fdTvJy59hQ/YXDoew4tnCE9ycabh5AyfcGDWWYx/Bapgdu1bctGxZTw/vifH?= =?us-ascii?Q?rVvl97OPElam9CNx3aSyTzOq3z9zXOONHfGo+d622MqmtH9mlpWzeTOcajqi?= =?us-ascii?Q?djRL+QmOKMhVonNVlThrcFAZfbGbEA3OHglFee4pKXjAWDM1SZa3jaifiOn3?= =?us-ascii?Q?5lY9sqg2ad8yIql94yyV4MHj6CHRjTIK9Gg7jhuMeeGRBaniAnONWZc9bSUF?= =?us-ascii?Q?96Ve2fg2PM3rh1wL/VkeNxyg/A3MCEQcBPir5+Eke1CUr4ppj72aFAY2MHHh?= =?us-ascii?Q?AfXZmjgoJApkWY0IuMxBFyTy5/DosNOFn9Q6WEGnPrAtInkB87W3eOnPz9c0?= =?us-ascii?Q?zoQ29MJ4ZMU7Sl53Y47+c1ugeELYPUGWbXmGnBKV8EUnIlb9Jsm0zj/YPWz4?= =?us-ascii?Q?xazZWOp8erxZrigFP1AapYRmdPFKZOaDE5yJMhjrVusxy/KxCzdi2We2Sbsd?= =?us-ascii?Q?onXYB5vl17XZtlKbLq1DK9YGT8DwxkpZ+KtDSZf0xf/TXGCycZ1J4XPtWcnu?= =?us-ascii?Q?fGKqNpiSuks79SH20E1cLj/8wa5WZjsk2rpGOgGR2ZNQmrBkZHgVlwV/e0Tq?= =?us-ascii?Q?jU/s2KsYXgyypry+CPk/dWtbS7L+L4AX6oYHycxo4DG5qWp/j8Y6xuHZVZ2V?= =?us-ascii?Q?cz3xgrLF26DTeSWScp22o/79043hvPlXYFeiWjspU8nX7khG3WPYGpyjxo4j?= =?us-ascii?Q?bcvdhJo7MdXEDyubLNaUzPg8l3rOVBr94YEn0KW7B76/+3EXLciOuczCSFd5?= =?us-ascii?Q?+rNLCjk9tM0y6AyEVNKxH09oa1HMBdl9pBvRgkY6ct9iPWdPzyvGTIZ2P72i?= =?us-ascii?Q?mXI=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0101MB1033; 5:Afxtcl8EbqffdbsyOLHrzJzxi+72DfswPYuqGZDqIr3qR8onAAEQkO4Z+kOtVoSTqh/kuSpvILC18u/bM1LdApi7eHssJel9A8SCmTEfUrzv+FA8+TgI/344wj6YYcxmGAKXA0cpWGewIxe9J59vqRIr3DBUH120fsAaM20/XHfiVLY2sh4qQXsXY69QobJgRGddDCkSnw8CZr2YC4HBlBFwgjuvzthkbGw61zp5zuHsRkjI9e+Dktz0fvIIALsofT+DeEWvdMFfgp78Kk5I4iY0N1+LC3FkSuCurh8l1L2CyGb6LO9O9wuyxGTO4UabAZIwNzliT2yjj4ACsQ5ww9VLK5YxOHvP6r216Q7ir5MXUuIQthyGPdvPz2gcthUy1lJ9bUNO1XoeFwZETQZ0Q6KoKV8/q8X2UEFAkswfZraHhFu6j26nUV4bislqR8El9DOD8sJhGZ2Ha/YkiRMhU3qBGwzThIBphAe9dS26jl19XRdJ2RoqhGovUjAX2lUt; 24:uW83lIBymZxUUfZVwvP547ZM7aUWjKOKRNAHYCMQ+fxoOVoUpMFTTYhnE/IuekFasmB6f9fCg1Lmk9ADgJWJv0Eg5ZEiYOEDubg7YpzH3x8= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR0101MB1033; 7:ZJJRrWFW0RAJyDqPWP6V8B49EqjaUuqIVefh2WeSsGvj9NZSrIIVsSfu8+lKN8zy7jtAYK6R45wdBLlDXUZ6FfypKRblMvyZPvRwgrb6u3nMmah5om5CGpWcmiKTKYnrKfMgAZv9o8MA/E9D+Lwnq8uBQclKRW51iSV8z23HdvuNXMFUWhnk0RkLIsH5S5x+ob20dq2Ad6ebcWelt/nvBTv6UNl1IreKPD3B2RC5/37iO9EjhTspO3Zuly3uPQYdJgOCj05FhRUWi0k+1n2S7DaNFVoiyQuYlZ4XvPm3KcRdepg2IGJEK8h/f+kqg42Ty7Nk/A4pw+6PJNkh9qByvj9StPKxHlBSzvsrwmUmj5rIbFOMAorUV1aM475XJZU9mnu1l22I0bDkchAUnODU3Zi/70Lu/RDllcahNdlUVphftHBrmQlrLKP2XLlLoLa+r44xgivNn+lCKcqp9Eeokn5yRr6EULl8AjR9sueNjkBdSDk9qO07NGZ+aQ7ELuiomtf8Jnu7bJ5/TOP56+sFaTbWRTCpxln6KRqtHuYJbaTVFS8OLj0XQNMABrcKKoSp+Sg48oU4sCCgZlGFx8Q3ebTVemYJApKYFoMp0arkj6PvEePVUCv1nATY0WLnp9XTINijIfz/oEQnt8PZgWEZj+gB/AibBPAjhwv9xo0qf61TgcoiDhwozXYud8aMpnTTSFqdjcHDqihUdhV70yJBbuSNn4qobpIqNDuOdDuNeT4USBV2rg+no3ifaXxIveXXAaPwTrCKFf349cppwIx5Q4Q3wWc8+ovCUdaDocD/pqc= X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Aug 2017 10:46:33.5714 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0101MB1033 Archived-At: Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for 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, 02 Aug 2017 10:46:38 -0000 On 2 Aug 2017, at 17:13, Jon Shallow wrote: > The DOTS client may have the smarts to work out what are the > problematic > source-* etc. values (e.g. can generate smart BGP FlowSpec rules) are > that > will sensibly control the DDoS Attack. Whatever orchestration system is getting input from the receiving DOTS server, actually. ----------------------------------- Roland Dobbins From nobody Wed Aug 2 08:25:16 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 571E313214B for ; Wed, 2 Aug 2017 08:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwFs6_F5FS6s for ; Wed, 2 Aug 2017 08:25:13 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54037132144 for ; Wed, 2 Aug 2017 08:24:56 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1dcvW2-00083n-R3 for ietf-supjps-dots@ietf.org; Wed, 02 Aug 2017 16:24:54 +0100 From: "Jon Shallow" To: References: <035401d30b77$fb3a1da0$f1ae58e0$@jpshallow.com> <628E4313-95D3-42F5-9DDB-00C7B4EBB4D6@arbor.net> In-Reply-To: <628E4313-95D3-42F5-9DDB-00C7B4EBB4D6@arbor.net> Date: Wed, 2 Aug 2017 16:24:56 +0100 Message-ID: <039001d30ba3$7f4290c0$7dc7b240$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQI4Xj59hXHis+FNi2tfJtTtHlSsOQE/0lLFoZyHB9A= Archived-At: Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for 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, 02 Aug 2017 15:25:15 -0000 I guess I am confused by your response. Yes, the DOTS Server may be able to work out the source-* information before passing it to the DOTS Mitigator, but may need some hints from the DOTS client as to what to do. I was not expecting the DOTS Server to be feeding back information to the DOTS client for the DOTS client to mitigate. I (probably badly) was trying to describe a DOTS Client that had some intelligence and could feed hints up to the DOTS Server. In draft-ietf-dots-use-cases-07 3.1.6. End-customer operating a CPE network infrastructure device with an integrated DOTS client The CPE device with integrated DOTS Client may be able to work out which source-* and destination-* is needed to mitigate the attack (which could be internet pipe flooding etc.) but has no mechanism to signal any source-* information upstream to the DOTS server. Hence 3 questions as to how can this source-* information be handled with the current draft-ietf-dots-signal-channel ? Regards Jon -----Original Message----- From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Roland Dobbins Sent: 02 August 2017 11:46 To: Jon Shallow Cc: dots@ietf.org Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation On 2 Aug 2017, at 17:13, Jon Shallow wrote: > The DOTS client may have the smarts to work out what are the > problematic > source-* etc. values (e.g. can generate smart BGP FlowSpec rules) are > that will sensibly control the DDoS Attack. Whatever orchestration system is getting input from the receiving DOTS server, actually. ----------------------------------- Roland Dobbins _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Wed Aug 2 11:27:53 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F09A129B26 for ; Wed, 2 Aug 2017 11:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCTpGWZBl2qG for ; Wed, 2 Aug 2017 11:27:50 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0124.outbound.protection.outlook.com [104.47.32.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1612A126C0F for ; Wed, 2 Aug 2017 11:27:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Lhy6lLqF4ajNGE+bRLIxduHj3Qmkjy1SkE0wSLmchJQ=; b=hyTSKhCRdYdHDDjfv1hedLQjqFFRdXndw0NTqpLEX3A8xEiOJ7VE/peGeA2LlklHufl4v7BxU1rxakS56gucnKJWw1XsIfqKipwJBe3hyqQIl0jKXmuM0BV/eZJ0D3DNtJYWP0fkABNDzHCGdHuYNWT3doQIE1sfnrVUBAH7y34= Received: from DM2PR0101MB1039.prod.exchangelabs.com (10.160.129.156) by DM2PR0101MB1039.prod.exchangelabs.com (10.160.129.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.22; Wed, 2 Aug 2017 18:27:48 +0000 Received: from DM2PR0101MB1039.prod.exchangelabs.com ([fe80::7c00:c01c:3a1b:51c2]) by DM2PR0101MB1039.prod.exchangelabs.com ([fe80::7c00:c01c:3a1b:51c2%13]) with mapi id 15.01.1304.023; Wed, 2 Aug 2017 18:27:48 +0000 From: "Dobbins, Roland" To: Jon Shallow CC: "dots@ietf.org" Thread-Topic: [Dots] Signal / Data / Alias / Filter Implementation Thread-Index: AdMLd/i8iwFwzTfWQ/S7HayGj5igcAAP0ScA///YgwCAADMXzw== Date: Wed, 2 Aug 2017 18:27:47 +0000 Message-ID: References: <035401d30b77$fb3a1da0$f1ae58e0$@jpshallow.com> <628E4313-95D3-42F5-9DDB-00C7B4EBB4D6@arbor.net>, <039001d30ba3$7f4290c0$7dc7b240$@jpshallow.com> In-Reply-To: <039001d30ba3$7f4290c0$7dc7b240$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [49.228.111.8] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM2PR0101MB1039; 7:V/7ncVDjVkvz/57m8Zp6Ou+rMomtOb5LqlSct6biq/+MwsM7d00Z8yHuu5AVIavNP4br2LbcACUaAvm6c1gi0gFomhghrcMT1P+XclQifwThhcZzWM87N53Iut5UlRIA7GcBEfYI4NEAFnCd+dx0OqVXaBvdH8rOMCZdiN7W+AyHTQiNVoAL06oD1A5cX75ssoeDHcel2KNTIQ5hyrkRPAKWvWdnMRPaFC/6CzWL9bAWvTb+a2Lri2PSP9DmzxaI8BYaGlWVTsheclVFodV7vNStOIfZihMDKcX/VS9WZf036bRP9Bk7cJ5SEQRvdracjQOtcxyynFpEPR8VrnrbR9vP4M/anwj7jVBhXQU0CRQcDHajxcbGyvPHsndnLj2Q2iHDxupdtjIKBnl/4weeqk1BcSgMeNHTCTPGatSoeUY725ETiG0LaNJXnXxmjjPj/Xu5tZSbmyNNfbHo4iogtXeyVFQds2HZDOvMclcqeqg5kNSEW+M1yglCQLVS+AKf2Ju1wJUTi0J0+kJXFrPmD8MFvogUzVOhAlIt+1jjntSdAcYQBpfUsxHXWhdaj186ZDLreZYhmDfED1/YerU02sXzIw6eLSer4euKc/xub72MlWF/CdAfnK0BYBv5SSNWrJnZMa/bxhHuAOC8pEHM/zdnvptaVJVf7+C21sLQVoybK2oXu8FiNLx0VZVz2sCrFZEgxrCzucP4NNK/W3ycgqof8Zv8ADPuOr9PkhM+QWx6iIkNPUfwt8BXjl7iHjad51r4FUGQUAxXJnhC+0dOgpZwYutJzrn3PJbgTllczQU= x-ms-office365-filtering-correlation-id: c69e8d39-0754-4d3f-37e2-08d4d9d42d2f x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR0101MB1039; x-ms-traffictypediagnostic: DM2PR0101MB1039: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rdobbins@arbor.net; x-exchange-antispam-report-test: UriScan:(278428928389397); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(3002001)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(20161123562025)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0101MB1039; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0101MB1039; x-forefront-prvs: 0387D64A71 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400002)(39400400002)(39840400002)(39410400002)(39450400003)(189002)(24454002)(199003)(53936002)(478600001)(81156014)(189998001)(8936002)(54896002)(236005)(81166006)(6512007)(105586002)(50986999)(106356001)(76176999)(54356999)(5250100002)(3846002)(6116002)(102836003)(53546010)(68736007)(101416001)(229853002)(6506006)(2900100001)(6436002)(36756003)(82746002)(6486002)(2950100002)(99286003)(6916009)(8676002)(5660300001)(3660700001)(97736004)(83716003)(38730400002)(86362001)(6246003)(7736002)(4326008)(110136004)(3280700002)(33656002)(25786009)(66066001)(14454004)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1039; H:DM2PR0101MB1039.prod.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: arbor.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_B8BBF80E5A5B473DA0B2B6EFEC21DEBFarbornet_" MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Aug 2017 18:27:47.8258 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1039 Archived-At: Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for 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, 02 Aug 2017 18:27:52 -0000 --_000_B8BBF80E5A5B473DA0B2B6EFEC21DEBFarbornet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBBdWcgMiwgMjAxNywgYXQgMjI6MjUsIEpvbiBTaGFsbG93IDxzdXBqcHMtaWV0ZkBqcHNo YWxsb3cuY29tPG1haWx0bzpzdXBqcHMtaWV0ZkBqcHNoYWxsb3cuY29tPj4gd3JvdGU6DQoNCklu IGRyYWZ0LWlldGYtZG90cy11c2UtY2FzZXMtMDcNCjMuMS42LiAgRW5kLWN1c3RvbWVyIG9wZXJh dGluZyBhIENQRSBuZXR3b3JrIGluZnJhc3RydWN0dXJlIGRldmljZSB3aXRoDQogICAgICAgYW4g aW50ZWdyYXRlZCBET1RTIGNsaWVudA0KDQozLjEuNiBmcm9tIGlkcmFmdC1pZXRmLWRvdHMtdXNl LWNhc2VzLTA3IGluIGZ1bGw6DQoNCg0KDQoNCjMuMS42LiAgRW5kLWN1c3RvbWVyIG9wZXJhdGlu ZyBhIENQRSBuZXR3b3JrIGluZnJhc3RydWN0dXJlIGRldmljZSB3aXRoDQogICAgICAgIGFuIGlu dGVncmF0ZWQgRE9UUyBjbGllbnQNCg0KICAgU2ltaWxhciB0byB0aGUgYWJvdmUgdXNlLWNhc2Ug ZmVhdHVyaW5nIGFwcGxpY2F0aW9ucyBvciBzZXJ2aWNlcyB3aXRoDQogICBidWlsdC1pbiBERG9T IGF0dGFjayBkZXRlY3Rpb24vY2xhc3NpZmljYXRpb24gYW5kIERPVFMgY2xpZW50DQogICBjYXBh YmlsaXRpZXMsIGluIHRoaXMgc2NlbmFyaW8sIGFuIGVuZC1jdXN0b21lciBuZXR3b3JrDQogICBp bmZyYXN0cnVjdHVyZSBDUEUgZGV2aWNlIHN1Y2ggYXMgYSByb3V0ZXIsIGxheWVyLTMgc3dpdGNo LCBmaXJld2FsbCwNCiAgIG9yIGxvYWQtYmFsYW5jZSBpbmNvcnBvcmF0ZXMgYm90aCB0aGUgZnVu Y3Rpb25hbGl0eSByZXF1aXJlZCB0bw0KICAgZGV0ZWN0IGFuZCBjbGFzc2lmeSBpbmNvbWluZyBE RG9TIGF0dGFja3MgYXMgd2VsbCBhcyBET1RTIGNsaWVudA0KICAgZnVuY3Rpb25hbGl0eS4NCg0K ICAgVGhlIHN1YnNlcXVlbnQgRE9UUyBjb21tdW5pY2F0aW9ucyBkaWFsb2d1ZSBhbmQgcmVzdWx0 YW50IEREb1MNCiAgIG1pdGlnYXRpb24gaW5pdGlhdGlvbiBhbmQgdGVybWluYXRpb24gYWN0aXZp dGllcyB0YWtlIHBsYWNlIGluIHRoZQ0KICAgc2FtZSBtYW5uZXIgYXMgdGhlIHVzZS1jYXNlcyBk ZXNjcmliZWQgYWJvdmUuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpS b2xhbmQgRG9iYmlucyA8cmRvYmJpbnNAYXJib3IubmV0PG1haWx0bzpyZG9iYmluc0BhcmJvci5u ZXQ+Pg0K --_000_B8BBF80E5A5B473DA0B2B6EFEC21DEBFarbornet_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+T24gQXVnIDIsIDIwMTcsIGF0IDIy OjI1LCBKb24gU2hhbGxvdyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN1cGpwcy1pZXRmQGpwc2hhbGxv dy5jb20iPnN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdj48c3Bhbj5JbiBkcmFmdC1p ZXRmLWRvdHMtdXNlLWNhc2VzLTA3IDwvc3Bhbj48YnI+DQo8c3Bhbj4zLjEuNi4gJm5ic3A7RW5k LWN1c3RvbWVyIG9wZXJhdGluZyBhIENQRSBuZXR3b3JrIGluZnJhc3RydWN0dXJlIGRldmljZSB3 aXRoPC9zcGFuPjxicj4NCjxzcGFuPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwO2FuIGludGVncmF0ZWQgRE9UUyBjbGllbnQ8L3NwYW4+PC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8YnI+DQo8ZGl2PjMuMS42IGZyb20gaTxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9y OiByZ2JhKDI1NSwgMjU1LCAyNTUsIDApOyI+ZHJhZnQtaWV0Zi1kb3RzLXVzZS1jYXNlcy0wNyBp PC9zcGFuPm4gZnVsbDo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj4NCjxwcmUgc3R5bGU9ImJveC1zaXppbmc6IGJvcmRlci1ib3g7IG92ZXJmbG93OiBh dXRvOyBmb250LWZhbWlseTogJ1BUIE1vbm8nLCBNb25hY28sIG1vbm9zcGFjZTsgZm9udC1zaXpl OiAxNHB4OyBwYWRkaW5nOiAxMHB4OyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDEw LjVweDsgbGluZS1oZWlnaHQ6IDEuMjE0OyB3b3JkLWJyZWFrOiBicmVhay1hbGw7IHdvcmQtd3Jh cDogYnJlYWstd29yZDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjUzLCAyNDUpOyBib3Jk ZXI6IDFweCBzb2xpZCByZ2IoMjA0LCAyMDQsIDIwNCk7IGJvcmRlci10b3AtbGVmdC1yYWRpdXM6 IDRweDsgYm9yZGVyLXRvcC1yaWdodC1yYWRpdXM6IDRweDsgYm9yZGVyLWJvdHRvbS1yaWdodC1y YWRpdXM6IDRweDsgYm9yZGVyLWJvdHRvbS1sZWZ0LXJhZGl1czogNHB4OyAtd2Via2l0LXRhcC1o aWdobGlnaHQtY29sb3I6IHJnYmEoMCwgMCwgMCwgMCk7IC13ZWJraXQtdGV4dC1zaXplLWFkanVz dDogMTAwJTsiPg0KMy4xLjYuICBFbmQtY3VzdG9tZXIgb3BlcmF0aW5nIGEgQ1BFIG5ldHdvcmsg aW5mcmFzdHJ1Y3R1cmUgZGV2aWNlIHdpdGgNCiAgICAgICAgYW4gaW50ZWdyYXRlZCBET1RTIGNs aWVudA0KDQogICBTaW1pbGFyIHRvIHRoZSBhYm92ZSB1c2UtY2FzZSBmZWF0dXJpbmcgYXBwbGlj YXRpb25zIG9yIHNlcnZpY2VzIHdpdGgNCiAgIGJ1aWx0LWluIEREb1MgYXR0YWNrIGRldGVjdGlv bi9jbGFzc2lmaWNhdGlvbiBhbmQgRE9UUyBjbGllbnQNCiAgIGNhcGFiaWxpdGllcywgaW4gdGhp cyBzY2VuYXJpbywgYW4gZW5kLWN1c3RvbWVyIG5ldHdvcmsNCiAgIGluZnJhc3RydWN0dXJlIENQ RSBkZXZpY2Ugc3VjaCBhcyBhIHJvdXRlciwgbGF5ZXItMyBzd2l0Y2gsIGZpcmV3YWxsLA0KICAg b3IgbG9hZC1iYWxhbmNlIGluY29ycG9yYXRlcyBib3RoIHRoZSBmdW5jdGlvbmFsaXR5IHJlcXVp cmVkIHRvDQogICBkZXRlY3QgYW5kIGNsYXNzaWZ5IGluY29taW5nIEREb1MgYXR0YWNrcyBhcyB3 ZWxsIGFzIERPVFMgY2xpZW50DQogICBmdW5jdGlvbmFsaXR5Lg0KDQogICBUaGUgc3Vic2VxdWVu dCBET1RTIGNvbW11bmljYXRpb25zIGRpYWxvZ3VlIGFuZCByZXN1bHRhbnQgRERvUw0KICAgbWl0 aWdhdGlvbiBpbml0aWF0aW9uIGFuZCB0ZXJtaW5hdGlvbiBhY3Rpdml0aWVzIHRha2UgcGxhY2Ug aW4gdGhlDQogICBzYW1lIG1hbm5lciBhcyB0aGUgdXNlLWNhc2VzIGRlc2NyaWJlZCBhYm92ZS48 L3ByZT4NCjxwcmUgc3R5bGU9ImJveC1zaXppbmc6IGJvcmRlci1ib3g7IG92ZXJmbG93OiBhdXRv OyBwYWRkaW5nOiAxMHB4OyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDEwLjVweDsg bGluZS1oZWlnaHQ6IDEuMjE0OyB3b3JkLWJyZWFrOiBicmVhay1hbGw7IHdvcmQtd3JhcDogYnJl YWstd29yZDsgYm9yZGVyOiAxcHggc29saWQgcmdiKDIwNCwgMjA0LCAyMDQpOyBib3JkZXItdG9w LWxlZnQtcmFkaXVzOiA0cHg7IGJvcmRlci10b3AtcmlnaHQtcmFkaXVzOiA0cHg7IGJvcmRlci1i b3R0b20tcmlnaHQtcmFkaXVzOiA0cHg7IGJvcmRlci1ib3R0b20tbGVmdC1yYWRpdXM6IDRweDsi Pjxmb250IGZhY2U9IlVJQ1RGb250VGV4dFN0eWxlVGFsbEJvZHkiPjxzcGFuIHN0eWxlPSJ3aGl0 ZS1zcGFjZTogbm9ybWFsOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDI1NSwgMjU1LCAyNTUsIDAp OyI+PHNwYW4gc3R5bGU9ImZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDsgZm9udC12YXJp YW50LWVhc3QtYXNpYW46IG5vcm1hbDsgZm9udC12YXJpYW50LXBvc2l0aW9uOiBub3JtYWw7IGxp bmUtaGVpZ2h0OiBub3JtYWw7Ij4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwv c3Bhbj48YnIgc3R5bGU9ImZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDsgZm9udC12YXJp YW50LWVhc3QtYXNpYW46IG5vcm1hbDsgZm9udC12YXJpYW50LXBvc2l0aW9uOiBub3JtYWw7IGxp bmUtaGVpZ2h0OiBub3JtYWw7Ij48L3NwYW4+PC9mb250PjxkaXYgc3R5bGU9ImZvbnQtdmFyaWFu dC1saWdhdHVyZXM6IG5vcm1hbDsgZm9udC12YXJpYW50LWVhc3QtYXNpYW46IG5vcm1hbDsgZm9u dC12YXJpYW50LXBvc2l0aW9uOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7Ij48Zm9udCBm YWNlPSJVSUNURm9udFRleHRTdHlsZVRhbGxCb2R5Ij48c3BhbiBzdHlsZT0id2hpdGUtc3BhY2U6 IG5vcm1hbDsgYmFja2dyb3VuZC1jb2xvcjogcmdiYSgyNTUsIDI1NSwgMjU1LCAwKTsiPlJvbGFu ZCBEb2JiaW5zICZsdDs8YSBocmVmPSJtYWlsdG86cmRvYmJpbnNAYXJib3IubmV0Ij5yZG9iYmlu c0BhcmJvci5uZXQ8L2E+Jmd0Ozwvc3Bhbj48L2ZvbnQ+PC9kaXY+PC9wcmU+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_B8BBF80E5A5B473DA0B2B6EFEC21DEBFarbornet_-- From nobody Wed Aug 2 22:21:07 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54B991321EC for ; Wed, 2 Aug 2017 22:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ckc6aEzrwp0Y for ; Wed, 2 Aug 2017 22:21:04 -0700 (PDT) Received: from guri.nttv6.jp (guri.nttv6.jp [IPv6:2402:c800:ff06:136::140]) by ietfa.amsl.com (Postfix) with ESMTP id DBC3A1321E9 for ; Wed, 2 Aug 2017 22:21:03 -0700 (PDT) Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2402:c800:ff06:6::f]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id CCE7525F691; Thu, 3 Aug 2017 14:21:02 +0900 (JST) Received: from DHCP-165.nttv6.jp (fujiko.nttv6.jp [IPv6:2402:c800:ff06:136::141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id B95F9759041; Thu, 3 Aug 2017 14:21:01 +0900 (JST) To: "Dobbins, Roland" , Jon Shallow Cc: "dots@ietf.org" References: <035401d30b77$fb3a1da0$f1ae58e0$@jpshallow.com> <628E4313-95D3-42F5-9DDB-00C7B4EBB4D6@arbor.net> <039001d30ba3$7f4290c0$7dc7b240$@jpshallow.com> From: kaname nishizuka Message-ID: <4a158137-5c92-974e-3e4d-6c46fb3e5a52@nttv6.jp> Date: Thu, 3 Aug 2017 14:21:01 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C3ABDA053A44BD016838B8B0" Content-Language: en-US Archived-At: Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for 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, 03 Aug 2017 05:21:06 -0000 This is a multi-part message in MIME format. --------------C3ABDA053A44BD016838B8B0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Jon, I'm implementing the DOTS protocol based on current specifications. The DOTS protocol can handle source-* information in a mitigation signal request. For example, the DOTS server can enable BGP Flowspec from 5-tuple information derived from mitigation request message from DOTS client, that is actually we are planning to add to our software. Destination information is used to validate whether the mitigation-scope is really the property of the DOTS client's organization or not. So, if the request is only including source-* information, how to validate the request is another problem because it can cause unintended side effect to other customers/services (but could be implementation specific) * How do we handle specific ICMP types in a mitigation signal request? Tiru wrote: > Thanks for the review. Fixed comments 1 and 2 in my local copy. To support filtering rules based on ICMP type and code, and filtering based on fragments, the base ACL model defined in https://tools.ietf.org/html/draft-ietf-netmod-acl-model-06 needs to be extended in this draft using augmentation (see https://tools.ietf.org/html/rfc6020#section-4.2.8). > I will extend the ACL YANG model in the next revision. And the latest version of draft-ietf-netmod-acl-model (-11) includes ICMP-ACL (type, code,,) I think we should update the draft. * How do we handle fragmentation in a mitigation signal request? fragmentation can be represented as port=0. Is this a sufficient representation? thanks, Kaname On 2017/08/03 3:27, Dobbins, Roland wrote: > > On Aug 2, 2017, at 22:25, Jon Shallow > wrote: > >> In draft-ietf-dots-use-cases-07 >> 3.1.6. End-customer operating a CPE network infrastructure device with >> an integrated DOTS client > > 3.1.6 from idraft-ietf-dots-use-cases-07 in full: > > > 3.1.6. End-customer operating a CPE network infrastructure device with > an integrated DOTS client > > Similar to the above use-case featuring applications or services with > built-in DDoS attack detection/classification and DOTS client > capabilities, in this scenario, an end-customer network > infrastructure CPE device such as a router, layer-3 switch, firewall, > or load-balance incorporates both the functionality required to > detect and classify incoming DDoS attacks as well as DOTS client > functionality. > > The subsequent DOTS communications dialogue and resultant DDoS > mitigation initiation and termination activities take place in the > same manner as the use-cases described above. > ----------------------------------- > Roland Dobbins > > > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots --------------C3ABDA053A44BD016838B8B0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Jon,

I'm implementing the DOTS protocol based on current specifications.
The DOTS protocol can handle source-* information in a mitigation signal request.
For example, the DOTS server can enable BGP Flowspec from 5-tuple information derived from mitigation request message from DOTS client, that is actually we are planning to add to our software.
Destination information is used to validate whether the mitigation-scope is really the property of the DOTS client's organization or not.
So, if the request is only including source-* information, how to validate the request is another problem because it can cause unintended side effect to other customers/services (but could be implementation specific)

* How do we handle specific ICMP types  in a mitigation signal request?

Tiru wrote:
> Thanks for the review. Fixed comments 1 and 2 in my local copy. To support filtering rules based on ICMP type and code, and filtering based on fragments, the base ACL model defined in https://tools.ietf.org/html/draft-ietf-netmod-acl-model-06 needs to be extended in this draft using augmentation (see https://tools.ietf.org/html/rfc6020#section-4.2.8).
> I will extend the ACL YANG model in the next revision.

And the latest version of draft-ietf-netmod-acl-model (-11) includes ICMP-ACL (type, code,,)
I think we should update the draft.

* How do we handle fragmentation in a mitigation signal request?
fragmentation can be represented as port=0. Is this a sufficient representation?

thanks,
Kaname



On 2017/08/03 3:27, Dobbins, Roland wrote:

On Aug 2, 2017, at 22:25, Jon Shallow <supjps-ietf@jpshallow.com> wrote:

In draft-ietf-dots-use-cases-07
3.1.6.  End-customer operating a CPE network infrastructure device with
       an integrated DOTS client

3.1.6 from idraft-ietf-dots-use-cases-07 in full:


3.1.6.  End-customer operating a CPE network infrastructure device with
        an integrated DOTS client

   Similar to the above use-case featuring applications or services with
   built-in DDoS attack detection/classification and DOTS client
   capabilities, in this scenario, an end-customer network
   infrastructure CPE device such as a router, layer-3 switch, firewall,
   or load-balance incorporates both the functionality required to
   detect and classify incoming DDoS attacks as well as DOTS client
   functionality.

   The subsequent DOTS communications dialogue and resultant DDoS
   mitigation initiation and termination activities take place in the
   same manner as the use-cases described above.
-----------------------------------

Roland Dobbins <rdobbins@arbor.net>


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

--------------C3ABDA053A44BD016838B8B0-- From nobody Thu Aug 3 00:57:08 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18750126CB6 for ; Thu, 3 Aug 2017 00:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xPlZ4ZdhXAR3 for ; Thu, 3 Aug 2017 00:56:57 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5B1F124234 for ; Thu, 3 Aug 2017 00:56:56 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1ddB03-0000AG-5H for ietf-supjps-dots@ietf.org; Thu, 03 Aug 2017 08:56:55 +0100 From: "Jon Shallow" To: References: <035401d30b77$fb3a1da0$f1ae58e0$@jpshallow.com> <628E4313-95D3-42F5-9DDB-00C7B4EBB4D6@arbor.net> <039001d30ba3$7f4290c0$7dc7b240$@jpshallow.com> <4a158137-5c92-974e-3e4d-6c46fb3e5a52@nttv6.jp> In-Reply-To: <4a158137-5c92-974e-3e4d-6c46fb3e5a52@nttv6.jp> Date: Thu, 3 Aug 2017 08:56:57 +0100 Message-ID: <040101d30c2e$14440f70$3ccc2e50$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0402_01D30C36.7609D700" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQI4Xj59hXHis+FNi2tfJtTtHlSsOQE/0lLFAki09OwCqf5EqgEj+Lm5oWzh0cA= Archived-At: Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for 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, 03 Aug 2017 07:57:00 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0402_01D30C36.7609D700 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Kaname, =20 So as I read this, you are either extending the ietf-dot-signal = definition to include source-* (and icmp, fragmentation and possibly = rate-limiting) information or you are using Filters over the data = channel (which is what Tiru is referring to). If it is an extension to = ietf-dot-signal, then this needs to be formalised for interoperability = between different suppliers. Similarly, = ietf-dots-data-channel-identifier needs to be extended =E2=80=93 but I = do think the naming (e.g. target-ip instead of just ip) needs to be = consistent between ietf-dot-signal and = ietf-dots-data-channel-identifier. =E2=80=9C5.3.1=E2=80=9D of = draft-ietf-dots-signal-channel would also need to reflect the = ietf-dot-signal change. =E2=80=9C6.=E2=80=9D and = =E2=80=9C10.1.2=E2=80=9D of draft-ietf-dots-signal-channel would also = need CBOR to be updated with source-* etc. definitions. =20 I am of the firm opinion that destination-ip is REQUIRED and MUST be = within the mitigation scope of the DOTS Client to prevent taking out = someone else=E2=80=99s IP. This is true for ietf-dot-signal, = ietf-dots-data-channel-identifier and ietf-dots-access-control-list. =20 I do not think fragmentation represented as port=3D0 is sufficient (and = is not necessarily intuitive =E2=80=93 it could be read as just take out = the subsequent packets of a fragmented sequence if the layer 4 header is = not there and hence no port). I think it should have its own = ietf-dot-signal definition. =20 It is unclear to me the usage of alias in the ietf-dot-signal =E2=80=93 = is it the DOTS client uses just the alias when requesting mitigation, = or if extra parameters are provided (e.g. alias plus target-port-range) = are the extra parameters a replacement or in addition to what is in the = ietf-dots-data-channel-identifier or are the extra parameters ignored = altogether? =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of kaname nishizuka Sent: 03 August 2017 06:21 To: Dobbins, Roland; Jon Shallow Cc: dots@ietf.org Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation =20 Hi Jon, I'm implementing the DOTS protocol based on current specifications. The DOTS protocol can handle source-* information in a mitigation signal = request. For example, the DOTS server can enable BGP Flowspec from 5-tuple = information derived from mitigation request message from DOTS client, = that is actually we are planning to add to our software. Destination information is used to validate whether the mitigation-scope = is really the property of the DOTS client's organization or not. So, if the request is only including source-* information, how to = validate the request is another problem because it can cause unintended = side effect to other customers/services (but could be implementation = specific) * How do we handle specific ICMP types in a mitigation signal request? Tiru wrote: > Thanks for the review. Fixed comments 1 and 2 in my local copy. To = support filtering rules based on ICMP type and code, and filtering based = on fragments, the base ACL model defined in = https://tools.ietf.org/html/draft-ietf-netmod-acl-model-06 needs to be = extended in this draft using augmentation (see = https://tools.ietf.org/html/rfc6020#section-4.2.8).=20 > I will extend the ACL YANG model in the next revision.=20 And the latest version of draft-ietf-netmod-acl-model (-11) includes = ICMP-ACL (type, code,,) I think we should update the draft. * How do we handle fragmentation in a mitigation signal request? fragmentation can be represented as port=3D0. Is this a sufficient = representation? thanks, Kaname On 2017/08/03 3:27, Dobbins, Roland wrote: =20 On Aug 2, 2017, at 22:25, Jon Shallow wrote: In draft-ietf-dots-use-cases-07=20 3.1.6. End-customer operating a CPE network infrastructure device with an integrated DOTS client =20 3.1.6 from idraft-ietf-dots-use-cases-07 in full: =20 =20 3.1.6. End-customer operating a CPE network infrastructure device with an integrated DOTS client =20 Similar to the above use-case featuring applications or services with built-in DDoS attack detection/classification and DOTS client capabilities, in this scenario, an end-customer network infrastructure CPE device such as a router, layer-3 switch, firewall, or load-balance incorporates both the functionality required to detect and classify incoming DDoS attacks as well as DOTS client functionality. =20 The subsequent DOTS communications dialogue and resultant DDoS mitigation initiation and termination activities take place in the same manner as the use-cases described above. -----------------------------------=20 Roland Dobbins _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots =20 ------=_NextPart_000_0402_01D30C36.7609D700 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Kaname,

 

So as I read this, you are either extending the ietf-dot-signal = definition to include source-* (and icmp, fragmentation and possibly = rate-limiting) information or you are using Filters over the data = channel (which is what Tiru is referring to).=C2=A0 If it is an = extension to ietf-dot-signal, then this needs to be formalised for = interoperability between different suppliers.=C2=A0 Similarly, = ietf-dots-data-channel-identifier needs to be extended =E2=80=93 but I = do think the naming (e.g. target-ip instead of just ip) needs to be = consistent between ietf-dot-signal and = ietf-dots-data-channel-identifier.=C2=A0 =E2=80=9C5.3.1=E2=80=9D of = draft-ietf-dots-signal-channel would also need to reflect the = ietf-dot-signal change. =E2=80=9C6.=E2=80=9D and = =E2=80=9C10.1.2=E2=80=9D of draft-ietf-dots-signal-channel would also = need CBOR to be updated with source-* etc. = definitions.

 

I am of the firm opinion that destination-ip is REQUIRED and MUST be = within the mitigation scope of the DOTS Client to prevent taking out = someone else=E2=80=99s IP.=C2=A0 This is true for ietf-dot-signal, = ietf-dots-data-channel-identifier and = ietf-dots-access-control-list.

 

I do not think fragmentation represented as port=3D0 is sufficient = (and is not necessarily intuitive =E2=80=93 it could be read as just = take out the subsequent packets of a fragmented sequence if the layer 4 = header is not there and hence no port). I think it should have its own = ietf-dot-signal definition.

 

It is unclear to me the usage of alias in the ietf-dot-signal = =E2=80=93 is it the DOTS client uses just =C2=A0the alias when = requesting mitigation, or if extra parameters are provided (e.g. alias = plus target-port-range) are the extra parameters a replacement or in = addition to what is in the ietf-dots-data-channel-identifier or are the = extra parameters ignored altogether?

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of kaname = nishizuka
Sent: 03 August 2017 06:21
To: Dobbins, = Roland; Jon Shallow
Cc: dots@ietf.org
Subject: Re: = [Dots] Signal / Data / Alias / Filter = Implementation

 

Hi Jon,

I'm implementing the DOTS = protocol based on current specifications.
The DOTS protocol can = handle source-* information in a mitigation signal request.
For = example, the DOTS server can enable BGP Flowspec from 5-tuple = information derived from mitigation request message from DOTS client, = that is actually we are planning to add to our software.
Destination = information is used to validate whether the mitigation-scope is really = the property of the DOTS client's organization or not.
So, if the = request is only including source-* information, how to validate the = request is another problem because it can cause unintended side effect = to other customers/services (but could be implementation = specific)

* How do we handle specific ICMP types  in a = mitigation signal request?

Tiru wrote:
> Thanks for the = review. Fixed comments 1 and 2 in my local copy. To support filtering = rules based on ICMP type and code, and filtering based on fragments, the = base ACL model defined in https= ://tools.ietf.org/html/draft-ietf-netmod-acl-model-06 needs to be = extended in this draft using augmentation (see https://tools.= ietf.org/html/rfc6020#section-4.2.8).
> I will extend the ACL = YANG model in the next revision.

And the latest version of = draft-ietf-netmod-acl-model (-11) includes ICMP-ACL (type, code,,)
I = think we should update the draft.

* How do we handle = fragmentation in a mitigation signal request?
fragmentation can be = represented as port=3D0. Is this a sufficient = representation?

thanks,
Kaname


<= p class=3DMsoNormal>On 2017/08/03 3:27, Dobbins, Roland = wrote:

 

On Aug 2, 2017, at 22:25, Jon Shallow = <supjps-ietf@jpshallow.com&g= t; wrote:

In draft-ietf-dots-use-cases-07
3.1.6. =  End-customer operating a CPE network infrastructure device = with
       an integrated DOTS = client

 

3.1.6 = from idraft-ietf-dots-use-cases-07 in full:

 

 

3.1.6.=C2=A0 End-customer operating a CPE =
network infrastructure device with
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 an =
integrated DOTS client
 
=C2=A0=C2=A0 =
Similar to the above use-case featuring applications or services =
with
=C2=A0=C2=A0 =
built-in DDoS attack detection/classification and DOTS =
client
=C2=A0=C2=A0 =
capabilities, in this scenario, an end-customer =
network
=C2=A0=C2=A0 =
infrastructure CPE device such as a router, layer-3 switch, =
firewall,
=C2=A0=C2=A0 or =
load-balance incorporates both the functionality required =
to
=C2=A0=C2=A0 =
detect and classify incoming DDoS attacks as well as DOTS =
client
=C2=A0=C2=A0 =
functionality.
 
=C2=A0=C2=A0 The =
subsequent DOTS communications dialogue and resultant =
DDoS
=C2=A0=C2=A0 =
mitigation initiation and termination activities take place in =
the
=C2=A0=C2=A0 same =
manner as the use-cases described above.
---------------=
-------------------- 
Roland =
Dobbins <rdobbins@arbor.net>=





_______________________=
________________________
Dots mailing =
list
Dots@ietf.org
https://www.ietf.org/=
mailman/listinfo/dots

 

------=_NextPart_000_0402_01D30C36.7609D700-- From nobody Thu Aug 3 00:58:37 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2446A132327 for ; Thu, 3 Aug 2017 00:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6KK2n2FsSNia for ; Thu, 3 Aug 2017 00:58:17 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 6E876126CB6 for ; Thu, 3 Aug 2017 00:58:15 -0700 (PDT) Received: from MIVEXAPP1N01.corpzone.internalzone.com (unknown [10.48.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp id 0fc8_edf4_65d9196b_510c_40a1_b6cb_3c45ad99ce05; Thu, 03 Aug 2017 02:58:13 -0500 Received: from MIVEXUSR1N01.corpzone.internalzone.com (10.48.48.81) by MIVEXAPP1N01.corpzone.internalzone.com (10.48.48.88) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 3 Aug 2017 03:58:11 -0400 Received: from MIVEXAPP1N01.corpzone.internalzone.com (10.48.48.88) by MIVEXUSR1N01.corpzone.internalzone.com (10.48.48.81) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 3 Aug 2017 03:58:11 -0400 Received: from MIVO365EDGE3.corpzone.internalzone.com (10.48.176.86) by MIVEXAPP1N01.corpzone.internalzone.com (10.48.48.88) with Microsoft SMTP Server (TLS) id 15.0.1263.5 via Frontend Transport; Thu, 3 Aug 2017 03:58:10 -0400 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (10.48.176.243) by edge.mcafee.com (10.48.176.86) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 3 Aug 2017 03:57:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.onmicrosoft.com; s=selector1-mcafee-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=tUBT0gb7hphkcLaddfsx+EDHpGdg16z4Rx+YIzEgjSA=; b=Hai7mO5bB+BTgZpLgq+ulwZ7g+fBTVPPyb6e7pZ/fvTLeh/fJvTyDLcpBVqGryWKfGuNzJX0vG4QdmcKH1yXI0wPA5SfgmfYy/M43dyL/7y2lwq6bVpvKBPESYaVxqgnedoU4YKs0Py3c5sXf+ptX/HkbstkHxSpTGHDdVIV0WM= Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1786.namprd16.prod.outlook.com (10.172.44.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.22; Thu, 3 Aug 2017 07:58:09 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.01.1304.023; Thu, 3 Aug 2017 07:58:09 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Signal / Data / Alias / Filter Implementation Thread-Index: AdMLd/i8iwFwzTfWQ/S7HayGj5igcAAtQcoA Date: Thu, 3 Aug 2017 07:58:09 +0000 Message-ID: References: <035401d30b77$fb3a1da0$f1ae58e0$@jpshallow.com> In-Reply-To: <035401d30b77$fb3a1da0$f1ae58e0$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1786; 7:D5AxylTo1reI05Ok7nGKeodt2djyvnkEZ7NtZnl1ejXRrwWmV+oOTzalKI8tb2WQMWRyoPxduWGuqP/mUH11lS6jC7mf6j3H2jRCjJXHsPMZgRBgms5UIzjhJP4+uEv4hQk9YyVUe7em3q8pOxRB0mF72l5ai67/JhnfHL5KXZfHER/TNfJGqmB9wqM9GUKqN64dwlVc+0I8AtjvVLo0tpb7NTieOTVej8Bc58P+t9H2nR9EumwB1bdRBhXhyNKxpOleZUSP/5zXfg660X8f6Qv24cQusVQ7VDAB4E2plve6o67nztBUm4OnfspCu58RpzvK+A0cfTTPDa+S533zu3X9vrnNekBUfIpajR2cx5baaPy9SBUkH5sygdSYoDAhC0yR2J8EOItKavAVpESdhR3MH7k9Z6WRqx6r+n1p/sUfq5nhnHiDhft+fAf7ki7mpQi+12usuJbKCizkXv5kreu5p/W+JIpWjcFdYZLFwty6RHppK0Bcf/wAPvggmIplAYy++Xnkzz8FvATQHmKqA6Bzkb+f3si5fa1ikaZwrPS1EJMolfKG3bJQmJxANE2KArzVOk/85ayKwzYMmn6HneZEKfUKbP10A4uvm8hwQM+Psiawf+k6bIcszUv5kL6mg9k136fMdbDpn+UI9uB4Lafk4v7RwPi96pKtw5HmChN8BXN7jMTqevoC7ZU+3IOn3tEcwK6nioKpy5Je4M1N3HOo2kdvWU0+mX6o11ViQbFLfkh9FRR5SMRbimbfXzmpJjnWrAjBN9FUEItBodYm/fIb0Pmm11tfaW4LSYva/EM= x-ms-office365-filtering-correlation-id: 89c5c2d6-63b9-4aaa-84ab-08d4da4561cf x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM5PR16MB1786; x-ms-traffictypediagnostic: DM5PR16MB1786: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(6041248)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1786; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1786; x-forefront-prvs: 03883BD916 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39840400002)(39450400003)(39400400002)(39410400002)(32952001)(377454003)(199003)(189002)(606006)(25786009)(97736004)(6306002)(53546010)(7696004)(76176999)(50986999)(54356999)(7736002)(3660700001)(189998001)(6116002)(102836003)(19609705001)(2900100001)(790700001)(77096006)(106356001)(105586002)(229853002)(80792005)(86362001)(3846002)(6506006)(54896002)(14454004)(66066001)(6246003)(38730400002)(5660300001)(3280700002)(236005)(53936002)(2950100002)(966005)(6436002)(55016002)(72206003)(478600001)(68736007)(2501003)(8676002)(8936002)(74316002)(9686003)(99286003)(81156014)(81166006)(101416001)(2906002)(33656002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1786; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1788C9F8E53F0F39A9B3AE70EAB10DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2017 07:58:09.2795 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1786 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6085> : inlines <6005> : streams <1756958> : uri <2475389> Archived-At: Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for 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, 03 Aug 2017 07:58:22 -0000 --_000_DM5PR16MB1788C9F8E53F0F39A9B3AE70EAB10DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The source IP addresses and source ports used by the DDoS attacker could ch= ange, the type of attack itself could evolve or change from one attack type= to another. It was discussed in the WG that this kind of information are only hints and= not mandatory to be conveyed by the DOTS client in the mitigation request.= https://tools.ietf.org/html/draft-ietf-dots-requirements-06 only discusse= s conveying the mitigation scope and not the source or type of the attack. = However, DOTS signal channel draft allows vendor specific parameters and re= served key values in the range of 32768 to 65536 for vendor specific parame= ters, these hints can be conveyed as vendor-specific parameters to the DOTS= server. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Wednesday, August 2, 2017 3:43 PM To: dots@ietf.org Subject: [Dots] Signal / Data / Alias / Filter Implementation Hi There, I am trying to get my mind around how to implement this and have some quest= ions / statements. Signal Channel The Signal channel looks very like Destination RTBH with some extras (proto= cols / port) as everything is target-* based. There is no concept of sourc= e-ip, source-port (to handle reflection attacks) etc. or dealing with fragm= ented packet, icmp types and rate-limiting. The DOTS client may have the smarts to work out what are the problematic so= urce-* etc. values (e.g. can generate smart BGP FlowSpec rules) are that wi= ll sensibly control the DDoS Attack. It is possible to use a previously defined alias over the Data Channel as a= n alternative for a mitigation request, but this too has source-* etc. limi= tations. I have not found a way of using a Filter defined over the Data Channel as a= signal Sending a signal will cause all traffic to stop (or rate-limit possibly if = it also happens to match a filter) to the target IP on the ports in questio= n - DDoS attack is now effective unless the DOTS server elects (via DNS or= BGP swing) to scrub that particular traffic (by controlling rates, Source = IPs / Source Ports etc.). Data Channel Can be used to set up aliases for later use. These again however appear to= be target-* based, with no source-*, icmp type or fragmentation capabiliti= es. Can set up a Filter, which does include both source and destination IPs, bu= t appears that it is acted on when pushed over the data channel, and cannot= be send as a signal - appears to be in place more for black/white listing = IPs than as a signal for mitigation, but does include rate-limiting Questions How do we handle Source-* information in a mitigation signal request? How do we handle specific ICMP types in a mitigation signal request? How do we handle fragmentation in a mitigation signal request? Regards Jon --_000_DM5PR16MB1788C9F8E53F0F39A9B3AE70EAB10DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The source IP addresses and source ports used by the DDoS attacker = could change, the type of attack itself could evolve or change from one att= ack type to another.

It was discussed in the WG that this kind of information are only h= ints and not mandatory to be conveyed by the DOTS client in the mitigation = request.  https://tools.ietf.org/html/draft-ietf-dots-requirements-06 only discusses conveying the mitigation scope and not the source or type o= f the attack. However, DOTS signal channel draft allows vendor specific par= ameters and reserved key values in the range of 32768 to 65536 for vendor s= pecific parameters, these hints can be conveyed as vendor-specific parameters to the DOTS server.

 

-Tiru

 

From:<= /span> Dots [mailto:dots-bou= nces@ietf.org] On Behalf Of Jon Shallow
Sent: Wednesday, August 2, 2017 3:43 PM
To: dots@ietf.org
Subject: [Dots] Signal / Data / Alias / Filter Implementation

 

Hi There,

 

I am trying to get my mind arou= nd how to implement this and have some questions / statements.

 

Signal Channel

 

The Signal channel looks very l= ike Destination RTBH with some extras (protocols / port) as everything is t= arget-* based.  There is no concept of source-ip, source-port (to hand= le reflection attacks) etc. or dealing with fragmented packet, icmp types and rate-limiting.

 

The DOTS client may have the sm= arts to work out what are the problematic source-* etc. values (e.g. can ge= nerate smart BGP FlowSpec rules) are that will sensibly control the DDoS At= tack.

 

It is possible to use a previou= sly defined alias over the Data Channel as an alternative for a mitigation = request, but this too has source-* etc. limitations.

I have not found a way of using= a Filter defined over the Data Channel as a signal

 

Sending a signal will cause all= traffic to stop (or rate-limit possibly if it also happens to match a filt= er) to the target IP on the ports in question -  DDoS attack is now ef= fective unless the DOTS server elects (via DNS or BGP swing) to scrub that particular traffic (by controlling rates, = Source IPs / Source Ports etc.).

 

Data Channel

 

Can be used to set up aliases f= or later use.  These again however appear to be target-* based, with n= o source-*, icmp type or fragmentation capabilities.

 

Can set up a Filter, which does= include both source and destination IPs, but appears that it is acted on w= hen pushed over the data channel, and cannot be send as a signal – ap= pears to be in place more for black/white listing IPs than as a signal for mitigation, but does include rate-limitin= g

 

Questions<= /b>

 

How do we handle Source-* infor= mation in a mitigation signal request?

How do we handle specific ICMP = types  in a mitigation signal request?

How do we handle fragmentation =  in a mitigation signal request?

 

Regards

 

Jon

 

--_000_DM5PR16MB1788C9F8E53F0F39A9B3AE70EAB10DM5PR16MB1788namp_-- From nobody Thu Aug 3 01:04:54 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB9A2132323 for ; Thu, 3 Aug 2017 01:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.702 X-Spam-Level: X-Spam-Status: No, score=-4.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QR_TBfjjE8B5 for ; Thu, 3 Aug 2017 01:04:52 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0111.outbound.protection.outlook.com [104.47.34.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63733126CB6 for ; Thu, 3 Aug 2017 01:04:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=aAJnxr8XqRtNLNSjdlv/lS4pQKnXa31kAdSFk66ax4c=; b=HHM9l4Zn5euRa5YsldfT4+C8T4+sMSftOfGPwLVrkB9VbKSpekmIx8StraynWU1Nan8WWY5pK6t2W0xHtAOvyF8f3q8yTHyHJ2YwNYIvVSHP/Tw2smBQsA/mySYd5fdXyC7hZEDu6hZajGkruif+UQKAZDP5wzVqflpU6nJICXo= Received: from [172.19.254.107] (49.228.111.8) by DM2PR0101MB1039.prod.exchangelabs.com (2a01:111:e400:3c19::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.22; Thu, 3 Aug 2017 08:04:49 +0000 From: "Roland Dobbins" To: "Jon Shallow" Cc: dots@ietf.org Date: Thu, 03 Aug 2017 15:04:32 +0700 Message-ID: <78660E60-0A94-4164-A8C0-5485816DE059@arbor.net> In-Reply-To: <040101d30c2e$14440f70$3ccc2e50$@jpshallow.com> References: <035401d30b77$fb3a1da0$f1ae58e0$@jpshallow.com> <628E4313-95D3-42F5-9DDB-00C7B4EBB4D6@arbor.net> <039001d30ba3$7f4290c0$7dc7b240$@jpshallow.com> <4a158137-5c92-974e-3e4d-6c46fb3e5a52@nttv6.jp> <040101d30c2e$14440f70$3ccc2e50$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) X-Originating-IP: [49.228.111.8] X-ClientProxiedBy: HK2PR02CA0181.apcprd02.prod.outlook.com (2603:1096:201:21::17) To DM2PR0101MB1039.prod.exchangelabs.com (2a01:111:e400:3c19::28) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: bc86527a-b159-4a1c-2814-08d4da465127 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR0101MB1039; X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 3:zNcuY6ZousOsx/6/zdjrMUK+aSNa7MQ7t2ZduBhmUIPnB4afoQjUtFiri8PogNIeiYygif1tsfcoO/CrvxLJhvZoDCDHzXFF/wG8n10tzKO+GMlSkk4hFlAh142tXxKqf1BQDUxuwI3h106QeQMEkWk6ZFZ7l2iYE7u+fKCoj87DFikfNumOFA8SbtOdOn4sdYRCMFr3ALnubReHYpkZ8TAlVbD9lNqHQV4mcyxnNq1IGE1Gt5xQ/IvFItBKHKWc; 25:GXS+Og1Q86uB/yZQtXxfasw5pQHCkSuc9SBedkwm3x0Emex/LEyWZnbGH8EgFHR5ao/doRe0H1KnwKbVI0ZxOigxz19uA/Rzwd6nhVumVf6wb59177317b92eTQAXy1gpPUuC68P0/f6zgIyQaKc9y49SGLpOQYWcTNzpsxfYX77fisyEZ+355vTDAxCayE+aMwwXmbmO3h/uscTOA2hKGwK7yS7etHBPiC1Br2q5N8Ncr9Zkj+08l2vSIuqt6jmdn6VrF9IfbNqcvvASYa5DCdZvAvVUDihs9nNs4IVAYkaJURihyYcspoxszINKE1gdwydgbUcGZLlx1jvNoPlOQ==; 31:toNkn8LYCagjfGVmthP7X6jaYBSeteZ4pSbhPxjmAYyckZJr6T4otLDib847Bfbd3qxKcvwR8qCYhcEFc9p7Boh2jTrUernJvf1suEviElAS96mBGfl849Yv8GAdIcGfmOfp6WyZ0S2Nqts4tmhkYEai5JbDTwvrMlcSBI0s+yeEtxeNzT1SWYFqVN0DOnfKe72IAnNfBecrTyyU1/Q7siJdk6P7Cki5QWKMiYvb00w= X-MS-TrafficTypeDiagnostic: DM2PR0101MB1039: Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=rdobbins@arbor.net; X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 20:kjkPRq8Q/xbBoVvSO2vj0Fh+qN1lEScb7eo5pDxZ+hdaOj6MMgwVPrXPzxw6oijllycJlnbtGH3SGSpBqyS0+rpTIyy/rCfutNemkQimayWmWLA3vRMa90hjXofZYX2i3pKwidpQYX+fFdCrPnUCxwYd9Ca8hD/fYwNyuEmQ1C+UmWV/t1sm6N00mG6OzDFw6rmIi3uJatB+yK+ZyZyQAiZ3NG9m5CXZKtvjVtneS1vhm1piPUe8f4Y4jl9wA/xM9QyLBsPA9WWV/+BSqeQahEQ/u5Act3Lnl+82+f5Ib6TFGMz0J5Go+qoixtjTntGLGTh2dpvP/vIIP8oPV2I891s67mtunAiQMsRlejQjMtpmLy/dqtQS5jA9cUS5maTlJBEGjohAt/BqW1OPl5DInu//AUA5cg2XnRV4foA2DJG3TiI6KOcByMUFmlonrlAy1h9X37Ec6s762fOy7SXcTAwnYggoD3f+KSTanL8ENAmQGXqbLu9rF4JKJQfN1LML; 4:KXH5KnEi47cVRyacEVAtzj9z3213oYs4Te0DaivkMF7k4Lc9jROKMhV09K07Wrkt1Qof2rzW0u6cgMY69oRNLWtQG/SLt/We33/fU+Tb0hWTUgk6S5oDQcHLFH3DlRyd+9rFXoEo8s+gkxZOnizFIc0mrbTQEj1IMPOb0yXBQpMfEYCN/xCrtGtPLirmTx5fxs0nYvUf5hgSP/LqpB0jlnoRg9ZR+scAcdhfc701hBkzgvE/Ur3Q3TPFmMtdvczD X-Exchange-Antispam-Report-Test: UriScan:; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6041248)(20161123564025)(20161123560025)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0101MB1039; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0101MB1039; X-Forefront-PRVS: 03883BD916 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(7370300001)(4630300001)(6009001)(6049001)(39450400003)(39410400002)(39830400002)(39400400002)(199003)(24454002)(189002)(53546010)(93886004)(68736007)(38730400002)(97736004)(6246003)(50466002)(42186005)(5003940100001)(7350300001)(86362001)(106356001)(105586002)(36756003)(83716003)(82746002)(110136004)(6116002)(66066001)(3846002)(25786009)(76176999)(478600001)(50986999)(53936002)(50226002)(101416001)(47776003)(2950100002)(81166006)(189998001)(2906002)(6916009)(6666003)(81156014)(4326008)(8676002)(33656002)(5660300001)(229853002)(7736002)(77096006)(305945005)(6486002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1039; H:[172.19.254.107]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: arbor.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR0101MB1039; 23:NQVdoRANruXfk34s/ycZnOSDRy/pl6DoDitJLYE?= =?us-ascii?Q?Hp9yHoNL/5cfn5Ih9GHx91DQw9PymOyzThmcDH1DG5LW2quteb2P1a5/bxQn?= =?us-ascii?Q?FboHzTw/OG0yzDPJ/jEVHJkj7lERRYRp+TZuj/JDK7RnHOEhgidYu7hcl59r?= =?us-ascii?Q?BLHT5QLDRl8cFYIafZrKH34YjBj/+YqGfTCrd/xIQ8iht3cm6LKuzEis12jZ?= =?us-ascii?Q?xMamXB7OmhkComNINv9jS72XI3IGabrvuEO7Mxfq3V6t/hSpK4Zej5ZVmSRT?= =?us-ascii?Q?9pUimNLMwvXFTDcbL5O8fQC10gnNrU7HcdIAei1o1fXIgmdkvvjpHCY2rAWh?= =?us-ascii?Q?v4Xq3DsHPvrm/16vh+k5lOrLUeEeEoTqQk2SY9sUfJ0gcWdZCSL0Wrjvme9w?= =?us-ascii?Q?2VRbKzKOiov49XCHHODz0bmQHl6ANnKsZZ0auCnvKJD3w94I4kDA119zMa42?= =?us-ascii?Q?lwE5uR8OWlGUUE/lFKN/Zr4UyOy31ngAz0hdXu26QR7RLqN4xBL4d3uARMCP?= =?us-ascii?Q?/ZQlOubD/DgxFVjL9GljWMgaP39fTY1idinAqwN2OYV0ZC9Giwo70ougr1y1?= =?us-ascii?Q?O6bTWIrzynVl85bT8nUImprvmc+2T7iesfCUzycemR+f3jTtJ9DxHKHkc47w?= =?us-ascii?Q?DGxznVKy2u068AD78q8sOGFQ5r6c7AllxTTfOrOmcOs+kr8S8DztDLGuigOR?= =?us-ascii?Q?1H5SaBUDDg93ElLrEG1ghyWwXly0VK9KrAvi4MRNEc1WidT7iThNT/LJT+pg?= =?us-ascii?Q?v4vXyj2JR0V6cL7OAeY72H/YxZfEBgubc7r/CC8SVDc8HGE985W4GrHbCKAB?= =?us-ascii?Q?3w+Q3STq3BaoGLux7n/E9Nv+ljW3sCQpnkyH01Xvt4Ua1JUibazsdrt4f2RO?= =?us-ascii?Q?EgxfgvjIR9DmBl9LA2+1sTxxB9lVJVABoPsY0FPvkfRF4y4WwJuEzwV9Og9P?= =?us-ascii?Q?OpRGTr692mb5GiYMwLD4wr57I6uMdQEcXlWSE41U8SkH1kJ3/7gubR8dvcz8?= =?us-ascii?Q?jHCnVvZbKi5YFVTXksoLVcCAtmLi/sU1/6XHNro+2aB22Jn+mhfrbhOxNxll?= =?us-ascii?Q?xt2IkbtfdlwcSBxVg+gqv95y+PewtyHCQpz+8FN9Mj4GAIVkfav1XH7O4+4s?= =?us-ascii?Q?lwk53ZMs53H3LP/QrpvopJWaHL8Vam5JppQ9IQ060EgGrhTYBirbPmvVhKWw?= =?us-ascii?Q?8L+WCOmpt+G/1GpTDzPHHXOEtV4C5JjK3RraP1wttC2T1pngsZgOEzrYE0bf?= =?us-ascii?Q?ZXY6vqWYUNitKGpbe215dMW+LOnNZ++6uvXWz95svsEH8oVu+f1ThQEJru20?= =?us-ascii?Q?QOhSvK+4XEpOdqPu2kv5DjXs3FvqK79zgLuR2xdVj6wKwAwzvEfR+kvjSTeV?= =?us-ascii?Q?8Ztp83Q=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 6:fdp2itaT3cIVgutiqWLN93WV5BJuZjsxONB5a/cdcxfxJRLDjEEZP78FgkKZgcxnGZ7Mi45Xh+koUItielJBcVmdssRefzBSOhDRx2Nce1+neXCUZe5zzuRgV5xW2D/ykP6FA9eL48exdhw1XhdIug2yXZvPwJY41t6ty2bGvSpHkc3CyRvltmnrM6WySQUd0zQUoaEuj2pZh3eEOmhsxxHagJ80YQk6FXl5U5+IYJ/9fiBqyUnTsKM5r6VmNnCWQRzzyxY6cKiG1ez9UySqueswbOI/eiEh3nkf/gVMlo6WYeaF2+jB/bnPASxsCAmdLEakZL7OMvMF+LpNKSt5gA==; 5:sxnEmu+DEs7cWPbE6O7z33VbqwOM3L9rRV+ts1ukN/DA9C1MfTBjnRUz4y+8WvV0868lccQ2a5CY5Fo8SmO9TRM9UZWesSF52KzfLQVbJ85HqqLLNUGp5vYL0SD0zJogqQitYF5MM93yZnQRuzdHNw==; 24:j7vofQvGrOQYwkhYWpKYgHWWLQQX57U1hktkRISw9unPZke/tduk2oNeAsc3rUWMKK4pMbr/DW5C5lN1wB2JX85RzrtZ0UinZlc3GKrq1mk=; 7:SoeW2LYHSRGRHBWUDa34vE+wbAGF7cCxVORn+OAUIZeuSee/WWiJr2eoPrc5OVLjDvkMaFFRKbO9x2Q1by496UzQogqCyCp9zt9K3SfhcgICQ0Cj433VO5LGVEuFSL+yiHg+LM5sptWOZTKKVG3SVSR8QEfG6jeT8azGbnLFo59AABOJIKL47oWTL25fJke7OQyyfbaw4d5MK9aS0xTgk6P1OheHWDXgw0JNnfasCYo= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Aug 2017 08:04:49.8762 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1039 Archived-At: Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for 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, 03 Aug 2017 08:04:54 -0000 On 3 Aug 2017, at 14:56, Jon Shallow wrote: > I am of the firm opinion that destination-ip is REQUIRED The intent of DOTS is NOT to re-create flowspec. It's to signal the need for DDoS mitigation. 'Taking out someone else's IP' is not a concern of DOTS itself; this has to do with the provisioning of the DOTS clients, servers, and associated detection/classification/traceback/mitigation systems. Getting into layer-4 traffic descriptors, including things like non-initial fragments, is re-creating flowspec and IPFIX. We don't intend to do that. ----------------------------------- Roland Dobbins From nobody Thu Aug 3 01:05:08 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D74D13232F for ; Thu, 3 Aug 2017 01:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVfmMVO1xUzJ for ; Thu, 3 Aug 2017 01:05:04 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0107.outbound.protection.outlook.com [104.47.33.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8899132326 for ; Thu, 3 Aug 2017 01:05:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=E7hzEZajIp4UmHW0LCdv3jxXdGXLOLdoTHIvBHJFFTY=; b=GkmD632OQhN3pbvfY4JM/7pcHLXEUCfhxGRyUcHh0pWPDouEjhfrmRR84W5NagyKTiksuDpm7O1Bo08zg+QP5jKKzoq03cqPo7vm005UkgRwOIxQ+o4SzgVhbtVkyL+eqAQ1yO4INIzCvp3kGfK7DRkINUtx2D2AEmsAXx5sydw= Received: from [172.19.254.107] (49.228.111.8) by DM2PR0101MB1039.prod.exchangelabs.com (2a01:111:e400:3c19::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.22; Thu, 3 Aug 2017 08:04:59 +0000 From: "Roland Dobbins" To: "Konda, Tirumaleswar Reddy" Cc: "Jon Shallow" , "dots@ietf.org" Date: Thu, 03 Aug 2017 15:04:59 +0700 Message-ID: In-Reply-To: References: <035401d30b77$fb3a1da0$f1ae58e0$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) X-Originating-IP: [49.228.111.8] X-ClientProxiedBy: HK2PR02CA0181.apcprd02.prod.outlook.com (2603:1096:201:21::17) To DM2PR0101MB1039.prod.exchangelabs.com (2a01:111:e400:3c19::28) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 18c95289-77f8-432b-e1ec-08d4da465753 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR0101MB1039; X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 3:G/xfOIvfstDFkplIsLgIGOuOzN88vTKrZLIkxpdIMWgKCZKt4aqTdVwneCAy7fH3HLQZ6mRfRf4ocxKmjqH6uwe2UYCzQFaVHhEXty3jPET0VUVxXGxfPE4p9iXF0Wc29TvCbKNT0t00ypspnZovnG1ASuIEPCkwNQ1HarkIbIczPys9loEsoekBnxekKEzwqw88GXrrDnJeKRlAVusoWP6mdF4AZYN8hnDxgmmG61LBsf++UOc5tfJDkYT570BE; 25:xjXDvI6tvF8UhL/losElzRoKakFKUAacqavTSI5OXqYet9xTub7Ca//3WWK/FDtIulk8ObauGi49SJX+ht/wCcXrwZeWiePW23rNA+iqssgDfhFK+JfClJCppiLuzW9zSrh/rI4SiQtcAEhG8UsWksXUK47k4vAgUYJiFbI1TJRpNKRFhK9pMPo4AhPTqx+zqR6FIUWXfW4y+GPDym+SxAjJj9wMx2Mffzc4mMke4GwW70arylFayeksNrglNd1v016vH+o7KAotXc/zac0KBE8r/fVym+jsRHnDuyCr2JDse128ayzrizoU15QJAGtS8+oRaR/c9uXZQcwtlLmtRQ==; 31:3iEFhoWw4uClaq9OXdzoA1xuxE6UFEI9OenoHVEx1ZM3xvjIWcVrVZKqMrhy+vBfDLMJsgUMvBYaas2Oq1kToeYnuLOv6T5BTm8MWxbEqAm/6gPuG06rYptZUF/gMbHDPgDSlP5KBXDiEMPfvUZLdyuJkv55SKY4TydPHqmsqoHrCocAh4PSGlwGhwTMaQyYhZg9UGQJOg0jpHSoraAtYem7SbfB+HqgHdCxTT4mih4= X-MS-TrafficTypeDiagnostic: DM2PR0101MB1039: Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=rdobbins@arbor.net; X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 20:tMb/AlMX+r17jILX2fRt/i3UbW1b3JSUmuaVC0uYNbqGXOgf7lXpTpjYQb1HFXd7yh0XoI5d5Leja+MXH6u3z5vIL0lN6Scoye4uVui7rqKaVEaYR5lLew/Ts22lTbRd9/yqefeXAfkcJvrYtw1+a2ub/D1FsrTPj5gyjXZ5QFnu70hHxy4CXy+UtOSuOde+E6sjN1iqzjYNuHp6bCsHoIwVi1IzcZo69UaTArAl93XfcNvRg0gSvvwUN5FSncDVzwcth+cV5NTznTr280A6KWLg9I4btMGtj3Cy8P3ENOMnASfQRDBOgxjzBBknC+71EhGiUegMORpVLxd/m34h6rAwmVTS5L7jeNAKwzBeyK4Gz/UOX3DWCnQLSmMF5Na4PhbLb6GkRK0TPMmfdcX7Ea/x0EwxNMx2xc7+54RZi/F1SFxsEw6o4yA4msHdZ6ucNyOLfYOIYTpSdP4KFx4OLQDCP83EneKarg+qXimPXymfPcGzMlcPRIEe5FvTl49D; 4:0UEYB4KddmSxmOYtbtSCKvid7na1oKn2GEtmI9yksMrDvf2Np2J8ADpvmzFaea2PFo3azwv5drEexXouYMYEFjnezJEyt+yUkSyY6d3n3YdTSQgrJ9KOJ9DbNUG0ZBc+P512tjSYPIVMzYgD0ZyL0PM95ClDPXTH5zMmUEaBDvAhdAnCYtWS18eyIeGnEcJQe2U3Q7BaRfh9gilRifLKpAqeYATlOMJuJqx7FyWCcPiIlYp4x5LsxEOxDccOTXH3 X-Exchange-Antispam-Report-Test: UriScan:; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6041248)(20161123564025)(20161123560025)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0101MB1039; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0101MB1039; X-Forefront-PRVS: 03883BD916 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(7370300001)(4630300001)(6009001)(6049001)(39450400003)(39410400002)(39830400002)(39400400002)(199003)(24454002)(189002)(53546010)(68736007)(38730400002)(97736004)(6246003)(50466002)(42186005)(5003940100001)(7350300001)(86362001)(106356001)(105586002)(36756003)(83716003)(82746002)(110136004)(558084003)(6116002)(66066001)(3846002)(25786009)(76176999)(478600001)(50986999)(53936002)(50226002)(101416001)(47776003)(2950100002)(81166006)(189998001)(2906002)(6916009)(81156014)(54906002)(4326008)(8676002)(33656002)(5660300001)(229853002)(7736002)(77096006)(305945005)(6486002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1039; H:[172.19.254.107]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: arbor.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR0101MB1039; 23:kTX62Yg0CSUB1WH5VXfXmykHZn/QHKvJfChXaUz?= =?us-ascii?Q?ckZLZt5w5RaSI+jHk2BLp1DSJIyI3SEV5D3EstpxNvXeUkdJfOnGBglx33PN?= =?us-ascii?Q?VyVcS+lPRyHYMzvOwdyNmvvi3qoolgTvkiwaafrfdTVOVyfk2izHcVF/7Dj/?= =?us-ascii?Q?S7cKbaE51Ie1L66mMoVA1ikVfFDLnazL/oIkDneFh3OfLxu4L3yhjSlZ54AW?= =?us-ascii?Q?0ny1KzksQpC6gTCh2KFTgnGJROyXjjb/YmO6xnBJS1kDZEsDgAwGg6T/Daxe?= =?us-ascii?Q?PRcENQbPnaslJxuadWeejjvgiIRlnrCcpq773eAoupGUON05Y9SbMF+82HoV?= =?us-ascii?Q?Ig6KQp4z7UtcZGED1PqVQJ9JTt+VZfTXvMPC/PlJWo0GJK/l4z1oit4JkaZU?= =?us-ascii?Q?LERS4ByG3XNE8jZJmC2rTRPfZMEYQN7mhteE6yrFmJQwL/EHfTiI0ppOETSU?= =?us-ascii?Q?bMwNtQO+hcGYcijCV+1lWcRdiDNsRjCn1Oq0c2el+MzYE/X9O0rYyyITtL9j?= =?us-ascii?Q?0OBd+9sAnBaaWcljzNBIn0PBTCMR+TsN6xyq1nHss7AIygENP+M4TYlF3xRU?= =?us-ascii?Q?yQtjNJ1FoRTLGHvHAgSymqYaXnWyLjboK4n9tHpiy/esdgAUosydE3w4DhTT?= =?us-ascii?Q?iXDkZiY6PDdTPvB2ZS1KJ+7ymAHrKa3SPQxvcYPD6vWyGqc3jUOxpdv+eTm4?= =?us-ascii?Q?kqstEOvRF9ji4VZ7sMPF/JwnRKcbps4/8Ggd9MwiTIf5VkZbaig1B5wNVbgz?= =?us-ascii?Q?QmsdfpnjqaQzn4/GdLsClkldtcolLYJo1QYVf2eHwZf2FIaLd29eGfYGtS55?= =?us-ascii?Q?wsHQCt3LIob48Ey6unloR5lWnp2p8XAJkNR2FxOGiW3Zq43NG3QMTAflfJiI?= =?us-ascii?Q?1as4NhkzqLIi9CpHPcfOcJvm/EoCxCfNBm8Fwvm1f0O4L0HbyIM9hrqFtlnz?= =?us-ascii?Q?mnFCRSSPy903BQpk21SMg3854/hnyEyijjtvX5DMIHg5EghNxkISIQxjdNLc?= =?us-ascii?Q?6jUwX5ejTrk2bZdgkz82ctnGrskLLVQ9/hx/uI+hIZw9qBrTYv1M6H1iE9cz?= =?us-ascii?Q?aq3kbaLjrDKhZG2IZgR8jre9aO+mxjW28nst0RDchJrCVz3yX3iRrLAHGq3s?= =?us-ascii?Q?fz7mRhf+Fn6MKGOfARZydXwrgeWwVevlFyP8X89sMpCnZ2mbwcEPs8EQiGS9?= =?us-ascii?Q?8UJfqkEN8m/ASUtL8PpabsivmYxwNBBrc4rbwgrXmRZ1jt/yugGMMjsZFt+T?= =?us-ascii?Q?OjxW5bnlQeMXOAJlMgSwrb3kub/Lc+51rYO9u2RlXM+ckkdymp4f7ZcoEcL0?= =?us-ascii?Q?J7RoCoh8BJ3Eb4VVSEYHdbVSqyJkpGmSmDt+Anl+ywnHdW1PReElFHL4AAJ6?= =?us-ascii?Q?chWzVNA=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 6:vDPzgbCOZYhBK22TcNJT7Y42T/3m7qnj1YLYLOl2Qwk/OplDRByR/BNWaz5EkJai8mDMNW0g1FTZa/tnKiqBzkXn2dw6PED6oPbQpaRtvooD7YloNMggwlUdSvL5yMrIdGOBDwRFYUpAiKxVuHPYfrHMK3QLM7wFrNuN05eC7802lCR0/gzwA/GDBMRQiCT63xaHzAlnY8W1FI/2Ox1HtJQpnb/yoSkMooxNCGq92OXSdWXGI2cS2OZ/6fJJcxRphR24TOMXAOfddFB0JoKN62dd4fwEZwWbhbgkjjHqkXk19PNwarA7O9lIFRhtsbEC+XQmm1p9yF5NQxxYIwThBA==; 5:DM/ipyXzojYgr3oSJGUwSg5SPPldbjvzUlWv0V35qxrbwEMJGkDhGJSRme76u35So4sb0n+jESerdyRUdjlr+cGkoaLW6wN8gipItsAfZbPjcFH0n2TospPbJB1HZF1onRCzqo8OoZqM/9cKM5mOeQ==; 24:BFVSh+ke7rUtv0mKQ5FXtPjYM4wAHkT8L5IbF7t8twiPGB4ixX00BlxSkYH+D+YGuhL0X9Pf1jLXmJNEo0VqtQGfyx28GwuJ9XqP7Gu5SWg=; 7:rclfJMsHBeEW+4zadNVML/llxFl4mQtLXkjhGqqgEzRzRBK+DqU+g00q+1hueZTuKzbewf3vG+IfYfWZFCRNIwgP7F0g4A1AVDGJGTk2wghJhS+cWoYGed+lD+PE7KjVUavN3MydXnYlfRzKY6zKoHUT7M821YgVVg0da0/Wu2e0ScYruwwsaatSO7MD/MdEvh/nDImHcbmSmRmZPj4UsPMX9/KEbRTFwFMQpfQVaow= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Aug 2017 08:04:59.6419 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1039 Archived-At: Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for 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, 03 Aug 2017 08:05:06 -0000 On 3 Aug 2017, at 14:58, Konda, Tirumaleswar Reddy wrote: > It was discussed in the WG that this kind of information are only > hints and not mandatory to be conveyed by the DOTS client in the > mitigation request. Correct. ----------------------------------- Roland Dobbins From nobody Thu Aug 3 01:06:36 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24980126CB6 for ; Thu, 3 Aug 2017 01:06:35 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K9mMu5F80SwK for ; Thu, 3 Aug 2017 01:06:33 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 AB23B132320 for ; Thu, 3 Aug 2017 01:06:32 -0700 (PDT) Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp id 0fc8_ff43_5ff66d70_4e2b_4b87_a05a_44c40650b73f; Thu, 03 Aug 2017 03:06:20 -0500 Received: from DNVEXUSR1N12.corpzone.internalzone.com (10.44.48.85) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 3 Aug 2017 02:06:20 -0600 Received: from DNVEXUSR1N12.corpzone.internalzone.com (10.44.48.85) by DNVEXUSR1N12.corpzone.internalzone.com (10.44.48.85) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 3 Aug 2017 02:06:19 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXUSR1N12.corpzone.internalzone.com (10.44.48.85) with Microsoft SMTP Server (TLS) id 15.0.1263.5 via Frontend Transport; Thu, 3 Aug 2017 02:06:19 -0600 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (10.44.176.241) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 3 Aug 2017 02:06:18 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.onmicrosoft.com; s=selector1-mcafee-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/QmTcwY78Znuzxxm815+n8TLMvRpCTRnYfVMZC/Xnic=; b=uDcD+e74O8iGpv59vL4/5HWBZ9VIuZBxlEV2f0r8Ixj4PpFxqp0f4GsgR7mfY9M4uekkDkRzkH/5fdg9KWX5LufSFRAhjNxvWVEWIUpwmh6UOU7Vpp3SsyIUbQdmLzQeYysgjuvWOtx+NBLP6PEtrNCkwLIgzNZX6PQXGmywQc4= Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1786.namprd16.prod.outlook.com (10.172.44.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.22; Thu, 3 Aug 2017 08:06:17 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.01.1304.023; Thu, 3 Aug 2017 08:06:17 +0000 From: "Konda, Tirumaleswar Reddy" To: kaname nishizuka , "Dobbins, Roland" , Jon Shallow CC: "dots@ietf.org" Thread-Topic: [Dots] Signal / Data / Alias / Filter Implementation Thread-Index: AdMLd/i8iwFwzTfWQ/S7HayGj5igcAABJg8AAAm7eQAABmLPgAAW0FyAAAWLLfA= Date: Thu, 3 Aug 2017 08:06:17 +0000 Message-ID: References: <035401d30b77$fb3a1da0$f1ae58e0$@jpshallow.com> <628E4313-95D3-42F5-9DDB-00C7B4EBB4D6@arbor.net> <039001d30ba3$7f4290c0$7dc7b240$@jpshallow.com> <4a158137-5c92-974e-3e4d-6c46fb3e5a52@nttv6.jp> In-Reply-To: <4a158137-5c92-974e-3e4d-6c46fb3e5a52@nttv6.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1786; 7:68oxI2xhJgd5Qdu/4EoJNHcbnInBFuMIafrrmMjHJeIYYDpMN5cwLeyjUpJGkdaPSAbx7VuEHb49jbzAYOmOe931oxJXzJPdRyXEOSVPlBdm19YRdarjfpPmQIvM0/t+w27f/wT2jMVULYuxEI48l4bX5dLAh6r8DWB6hEVcyb99fkvxk05bmGEeTEo3QDjR8lgxXD8F7UfJGH1IxQ4SVPZzqLORnpac22nJeUqFrhGYO4kcBysCtDndAULYHt1l/T2DMZBj91Q7SYsNKo1s3adj5ZahiktfCeOvgaSuTOUA70uNjyhjY6/0CLofcLiUqwR0kuJU1kbYECoCIKqUexejCUszfwhoEmodrK8Nm0Oa2dT7ZDK2yoveIL54AkqLawSlWyh9to9AOhLnldqG9NRadeOD+NGNycpHj54Rhetdajc7i8rSHgLHOwUGxkEBnkY4zl0C6IAGSEb4r2C0eVZ1pTvwpaMoO7vBsmWjxA/r8EKBM4Zn/AAofyqSJsPjb3l4m573soSNAFan5XntLAQWP41qW/s595FGSGN8PMZ/qw+w1sAVlIdWhAdn9AuZ9lam6Ti6BoHGWqCR6JpxM/fr67XYE0mqYwCX1PFGt0+66m1m5MToav6737XsTPOIXJDAgOI36Qfha8Ww2Z1SQ0EtyppPeNqym07kd2Ev5AhszNm5HBWH0XEN+sb+rsBW7wo2NcSbpFpH9+psrBPMTeKkyCypo3q+v3Khov/ErBNw4vRkKQWLDJ9vKs8yJa61kQBXUX/AD70ge9l14BNK615b8k0lUkf6GlnLonZYyHE= x-ms-office365-filtering-correlation-id: 5cbc2049-cb7e-4e8e-107d-08d4da46849a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM5PR16MB1786; x-ms-traffictypediagnostic: DM5PR16MB1786: x-exchange-antispam-report-test: UriScan:(158342451672863)(278428928389397)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(6041248)(20161123562025)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1786; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1786; x-forefront-prvs: 03883BD916 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39840400002)(39450400003)(39400400002)(39410400002)(24454002)(32952001)(51914003)(377454003)(199003)(189002)(606006)(25786009)(97736004)(6306002)(53546010)(7696004)(4326008)(76176999)(50986999)(54356999)(7736002)(3660700001)(189998001)(6116002)(102836003)(2900100001)(790700001)(77096006)(106356001)(105586002)(229853002)(80792005)(86362001)(3846002)(6506006)(54896002)(14454004)(66066001)(6246003)(38730400002)(5660300001)(3280700002)(236005)(53936002)(2950100002)(966005)(6436002)(55016002)(72206003)(478600001)(68736007)(8676002)(8936002)(74316002)(9686003)(99286003)(81156014)(81166006)(101416001)(2906002)(93886004)(33656002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1786; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB17887F73606FE7D920125FC2EAB10DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2017 08:06:17.2243 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1786 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6085> : inlines <6005> : streams <1756959> : uri <2475390> Archived-At: Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for 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, 03 Aug 2017 08:06:35 -0000 --_000_DM5PR16MB17887F73606FE7D920125FC2EAB10DM5PR16MB1788namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ZHJhZnQtaWV0Zi1kb3RzLWRhdGEtY2hhbm5lbC0wMiBleHRlbmRzIHRoZSBiYXNlIEFDTCBtb2Rl bCBkZWZpbmVkIGluIGRyYWZ0LWlldGYtbmV0bW9kLWFjbC1tb2RlbCB0byBzdXBwb3J0IGZpbHRl cmluZyBiYXNlZCBvbiBmcmFnbWVudHMuIEZpbHRlcmluZyBydWxlcyBiYXNlZCBvbiBJQ01QIHR5 cGUgYW5kIGNvZGUgaXMgc3VwcG9ydGVkIGluIGxhdGVzdCByZXZpc2lvbiBvZiBkcmFmdC1pZXRm LW5ldG1vZC1hY2wtbW9kZWwuDQpJIGRvbuKAmXQgc2VlIGEgbmVlZCB0byB1cGRhdGUgdGhlIERP VFMgZGF0YSBjaGFubmVsIGRyYWZ0Lg0KDQotVGlydQ0KDQpGcm9tOiBEb3RzIFttYWlsdG86ZG90 cy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yga2FuYW1lIG5pc2hpenVrYQ0KU2VudDog VGh1cnNkYXksIEF1Z3VzdCAzLCAyMDE3IDEwOjUxIEFNDQpUbzogRG9iYmlucywgUm9sYW5kIDxy ZG9iYmluc0BhcmJvci5uZXQ+OyBKb24gU2hhbGxvdyA8c3VwanBzLWlldGZAanBzaGFsbG93LmNv bT4NCkNjOiBkb3RzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0RvdHNdIFNpZ25hbCAvIERhdGEg LyBBbGlhcyAvIEZpbHRlciBJbXBsZW1lbnRhdGlvbg0KDQpIaSBKb24sDQoNCkknbSBpbXBsZW1l bnRpbmcgdGhlIERPVFMgcHJvdG9jb2wgYmFzZWQgb24gY3VycmVudCBzcGVjaWZpY2F0aW9ucy4N ClRoZSBET1RTIHByb3RvY29sIGNhbiBoYW5kbGUgc291cmNlLSogaW5mb3JtYXRpb24gaW4gYSBt aXRpZ2F0aW9uIHNpZ25hbCByZXF1ZXN0Lg0KRm9yIGV4YW1wbGUsIHRoZSBET1RTIHNlcnZlciBj YW4gZW5hYmxlIEJHUCBGbG93c3BlYyBmcm9tIDUtdHVwbGUgaW5mb3JtYXRpb24gZGVyaXZlZCBm cm9tIG1pdGlnYXRpb24gcmVxdWVzdCBtZXNzYWdlIGZyb20gRE9UUyBjbGllbnQsIHRoYXQgaXMg YWN0dWFsbHkgd2UgYXJlIHBsYW5uaW5nIHRvIGFkZCB0byBvdXIgc29mdHdhcmUuDQpEZXN0aW5h dGlvbiBpbmZvcm1hdGlvbiBpcyB1c2VkIHRvIHZhbGlkYXRlIHdoZXRoZXIgdGhlIG1pdGlnYXRp b24tc2NvcGUgaXMgcmVhbGx5IHRoZSBwcm9wZXJ0eSBvZiB0aGUgRE9UUyBjbGllbnQncyBvcmdh bml6YXRpb24gb3Igbm90Lg0KU28sIGlmIHRoZSByZXF1ZXN0IGlzIG9ubHkgaW5jbHVkaW5nIHNv dXJjZS0qIGluZm9ybWF0aW9uLCBob3cgdG8gdmFsaWRhdGUgdGhlIHJlcXVlc3QgaXMgYW5vdGhl ciBwcm9ibGVtIGJlY2F1c2UgaXQgY2FuIGNhdXNlIHVuaW50ZW5kZWQgc2lkZSBlZmZlY3QgdG8g b3RoZXIgY3VzdG9tZXJzL3NlcnZpY2VzIChidXQgY291bGQgYmUgaW1wbGVtZW50YXRpb24gc3Bl Y2lmaWMpDQoNCiogSG93IGRvIHdlIGhhbmRsZSBzcGVjaWZpYyBJQ01QIHR5cGVzICBpbiBhIG1p dGlnYXRpb24gc2lnbmFsIHJlcXVlc3Q/DQoNClRpcnUgd3JvdGU6DQo+IFRoYW5rcyBmb3IgdGhl IHJldmlldy4gRml4ZWQgY29tbWVudHMgMSBhbmQgMiBpbiBteSBsb2NhbCBjb3B5LiBUbyBzdXBw b3J0IGZpbHRlcmluZyBydWxlcyBiYXNlZCBvbiBJQ01QIHR5cGUgYW5kIGNvZGUsIGFuZCBmaWx0 ZXJpbmcgYmFzZWQgb24gZnJhZ21lbnRzLCB0aGUgYmFzZSBBQ0wgbW9kZWwgZGVmaW5lZCBpbiBo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRtb2QtYWNsLW1vZGVsLTA2 IG5lZWRzIHRvIGJlIGV4dGVuZGVkIGluIHRoaXMgZHJhZnQgdXNpbmcgYXVnbWVudGF0aW9uIChz ZWUgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzYwMjAjc2VjdGlvbi00LjIuOCkuDQo+ IEkgd2lsbCBleHRlbmQgdGhlIEFDTCBZQU5HIG1vZGVsIGluIHRoZSBuZXh0IHJldmlzaW9uLg0K DQpBbmQgdGhlIGxhdGVzdCB2ZXJzaW9uIG9mIGRyYWZ0LWlldGYtbmV0bW9kLWFjbC1tb2RlbCAo LTExKSBpbmNsdWRlcyBJQ01QLUFDTCAodHlwZSwgY29kZSwsKQ0KSSB0aGluayB3ZSBzaG91bGQg dXBkYXRlIHRoZSBkcmFmdC4NCg0KKiBIb3cgZG8gd2UgaGFuZGxlIGZyYWdtZW50YXRpb24gaW4g YSBtaXRpZ2F0aW9uIHNpZ25hbCByZXF1ZXN0Pw0KZnJhZ21lbnRhdGlvbiBjYW4gYmUgcmVwcmVz ZW50ZWQgYXMgcG9ydD0wLiBJcyB0aGlzIGEgc3VmZmljaWVudCByZXByZXNlbnRhdGlvbj8NCg0K dGhhbmtzLA0KS2FuYW1lDQoNCg0KT24gMjAxNy8wOC8wMyAzOjI3LCBEb2JiaW5zLCBSb2xhbmQg d3JvdGU6DQoNCk9uIEF1ZyAyLCAyMDE3LCBhdCAyMjoyNSwgSm9uIFNoYWxsb3cgPHN1cGpwcy1p ZXRmQGpwc2hhbGxvdy5jb208bWFpbHRvOnN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb20+PiB3cm90 ZToNCkluIGRyYWZ0LWlldGYtZG90cy11c2UtY2FzZXMtMDcNCjMuMS42LiAgRW5kLWN1c3RvbWVy IG9wZXJhdGluZyBhIENQRSBuZXR3b3JrIGluZnJhc3RydWN0dXJlIGRldmljZSB3aXRoDQogICAg ICAgYW4gaW50ZWdyYXRlZCBET1RTIGNsaWVudA0KDQozLjEuNiBmcm9tIGlkcmFmdC1pZXRmLWRv dHMtdXNlLWNhc2VzLTA3IGluIGZ1bGw6DQoNCg0KDQozLjEuNi4gIEVuZC1jdXN0b21lciBvcGVy YXRpbmcgYSBDUEUgbmV0d29yayBpbmZyYXN0cnVjdHVyZSBkZXZpY2Ugd2l0aA0KDQogICAgICAg IGFuIGludGVncmF0ZWQgRE9UUyBjbGllbnQNCg0KDQoNCiAgIFNpbWlsYXIgdG8gdGhlIGFib3Zl IHVzZS1jYXNlIGZlYXR1cmluZyBhcHBsaWNhdGlvbnMgb3Igc2VydmljZXMgd2l0aA0KDQogICBi dWlsdC1pbiBERG9TIGF0dGFjayBkZXRlY3Rpb24vY2xhc3NpZmljYXRpb24gYW5kIERPVFMgY2xp ZW50DQoNCiAgIGNhcGFiaWxpdGllcywgaW4gdGhpcyBzY2VuYXJpbywgYW4gZW5kLWN1c3RvbWVy IG5ldHdvcmsNCg0KICAgaW5mcmFzdHJ1Y3R1cmUgQ1BFIGRldmljZSBzdWNoIGFzIGEgcm91dGVy LCBsYXllci0zIHN3aXRjaCwgZmlyZXdhbGwsDQoNCiAgIG9yIGxvYWQtYmFsYW5jZSBpbmNvcnBv cmF0ZXMgYm90aCB0aGUgZnVuY3Rpb25hbGl0eSByZXF1aXJlZCB0bw0KDQogICBkZXRlY3QgYW5k IGNsYXNzaWZ5IGluY29taW5nIEREb1MgYXR0YWNrcyBhcyB3ZWxsIGFzIERPVFMgY2xpZW50DQoN CiAgIGZ1bmN0aW9uYWxpdHkuDQoNCg0KDQogICBUaGUgc3Vic2VxdWVudCBET1RTIGNvbW11bmlj YXRpb25zIGRpYWxvZ3VlIGFuZCByZXN1bHRhbnQgRERvUw0KDQogICBtaXRpZ2F0aW9uIGluaXRp YXRpb24gYW5kIHRlcm1pbmF0aW9uIGFjdGl2aXRpZXMgdGFrZSBwbGFjZSBpbiB0aGUNCg0KICAg c2FtZSBtYW5uZXIgYXMgdGhlIHVzZS1jYXNlcyBkZXNjcmliZWQgYWJvdmUuDQoNCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNClJvbGFuZCBEb2JiaW5zIDxyZG9iYmluc0Bh cmJvci5uZXQ8bWFpbHRvOnJkb2JiaW5zQGFyYm9yLm5ldD4+DQoNCg0KDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkRvdHMgbWFpbGluZyBsaXN0 DQoNCkRvdHNAaWV0Zi5vcmc8bWFpbHRvOkRvdHNAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90cw0KDQo= --_000_DM5PR16MB17887F73606FE7D920125FC2EAB10DM5PR16MB1788namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJ cGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiXEBEZW5nWGlhbiI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OlVJQ1RGb250VGV4dFN0eWxlVGFsbEJvZHk7DQoJcGFub3NlLTE6 MCAwIDAgMCAwIDAgMCAwIDAgMDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxp bmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 IjsNCgljb2xvcjpibGFjazt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29u b3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRl ZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0K CWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTIw DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+ZHJhZnQtaWV0 Zi1kb3RzLWRhdGEtY2hhbm5lbC0wMiBleHRlbmRzIHRoZSBiYXNlIEFDTCBtb2RlbCBkZWZpbmVk IGluIGRyYWZ0LWlldGYtbmV0bW9kLWFjbC1tb2RlbCB0byBzdXBwb3J0IGZpbHRlcmluZyBiYXNl ZCBvbiBmcmFnbWVudHMuIEZpbHRlcmluZw0KIHJ1bGVzIGJhc2VkIG9uIElDTVAgdHlwZSBhbmQg Y29kZSBpcyBzdXBwb3J0ZWQgaW4gbGF0ZXN0IHJldmlzaW9uIG9mIGRyYWZ0LWlldGYtbmV0bW9k LWFjbC1tb2RlbC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5k b3d0ZXh0Ij5JIGRvbuKAmXQgc2VlIGEgbmVlZCB0byB1cGRhdGUgdGhlIERPVFMgZGF0YSBjaGFu bmVsIGRyYWZ0LjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5k b3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 d2luZG93dGV4dCI+LVRpcnU8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3NwYW4+PC9wPg0KPHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjwv c3Bhbj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41 cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndp bmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4 dCI+IERvdHMgW21haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2Yg PC9iPmthbmFtZSBuaXNoaXp1a2E8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEF1Z3VzdCAz LCAyMDE3IDEwOjUxIEFNPGJyPg0KPGI+VG86PC9iPiBEb2JiaW5zLCBSb2xhbmQgJmx0O3Jkb2Ji aW5zQGFyYm9yLm5ldCZndDs7IEpvbiBTaGFsbG93ICZsdDtzdXBqcHMtaWV0ZkBqcHNoYWxsb3cu Y29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gZG90c0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW0RvdHNdIFNpZ25hbCAvIERhdGEgLyBBbGlhcyAvIEZpbHRlciBJbXBsZW1lbnRhdGlv bjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+SGkgSm9uLDxicj4NCjxicj4NCkknbSBpbXBsZW1lbnRpbmcg dGhlIERPVFMgcHJvdG9jb2wgYmFzZWQgb24gY3VycmVudCBzcGVjaWZpY2F0aW9ucy48YnI+DQpU aGUgRE9UUyBwcm90b2NvbCBjYW4gaGFuZGxlIHNvdXJjZS0qIGluZm9ybWF0aW9uIGluIGEgbWl0 aWdhdGlvbiBzaWduYWwgcmVxdWVzdC48YnI+DQpGb3IgZXhhbXBsZSwgdGhlIERPVFMgc2VydmVy IGNhbiBlbmFibGUgQkdQIEZsb3dzcGVjIGZyb20gNS10dXBsZSBpbmZvcm1hdGlvbiBkZXJpdmVk IGZyb20gbWl0aWdhdGlvbiByZXF1ZXN0IG1lc3NhZ2UgZnJvbSBET1RTIGNsaWVudCwgdGhhdCBp cyBhY3R1YWxseSB3ZSBhcmUgcGxhbm5pbmcgdG8gYWRkIHRvIG91ciBzb2Z0d2FyZS48YnI+DQpE ZXN0aW5hdGlvbiBpbmZvcm1hdGlvbiBpcyB1c2VkIHRvIHZhbGlkYXRlIHdoZXRoZXIgdGhlIG1p dGlnYXRpb24tc2NvcGUgaXMgcmVhbGx5IHRoZSBwcm9wZXJ0eSBvZiB0aGUgRE9UUyBjbGllbnQn cyBvcmdhbml6YXRpb24gb3Igbm90Ljxicj4NClNvLCBpZiB0aGUgcmVxdWVzdCBpcyBvbmx5IGlu Y2x1ZGluZyBzb3VyY2UtKiBpbmZvcm1hdGlvbiwgaG93IHRvIHZhbGlkYXRlIHRoZSByZXF1ZXN0 IGlzIGFub3RoZXIgcHJvYmxlbSBiZWNhdXNlIGl0IGNhbiBjYXVzZSB1bmludGVuZGVkIHNpZGUg ZWZmZWN0IHRvIG90aGVyIGN1c3RvbWVycy9zZXJ2aWNlcyAoYnV0IGNvdWxkIGJlIGltcGxlbWVu dGF0aW9uIHNwZWNpZmljKTxicj4NCjxicj4NCiogSG93IGRvIHdlIGhhbmRsZSBzcGVjaWZpYyBJ Q01QIHR5cGVzJm5ic3A7IGluIGEgbWl0aWdhdGlvbiBzaWduYWwgcmVxdWVzdD88YnI+DQo8YnI+ DQpUaXJ1IHdyb3RlOjxicj4NCiZndDsgVGhhbmtzIGZvciB0aGUgcmV2aWV3LiBGaXhlZCBjb21t ZW50cyAxIGFuZCAyIGluIG15IGxvY2FsIGNvcHkuIFRvIHN1cHBvcnQgZmlsdGVyaW5nIHJ1bGVz IGJhc2VkIG9uIElDTVAgdHlwZSBhbmQgY29kZSwgYW5kIGZpbHRlcmluZyBiYXNlZCBvbiBmcmFn bWVudHMsIHRoZSBiYXNlIEFDTCBtb2RlbCBkZWZpbmVkIGluDQo8YSBocmVmPSJodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRtb2QtYWNsLW1vZGVsLTA2Ij5odHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRtb2QtYWNsLW1vZGVsLTA2PC9hPiBu ZWVkcyB0byBiZSBleHRlbmRlZCBpbiB0aGlzIGRyYWZ0IHVzaW5nIGF1Z21lbnRhdGlvbiAoc2Vl DQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjAyMCNzZWN0aW9uLTQu Mi44Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjAyMCNzZWN0aW9uLTQuMi44PC9h PikuDQo8YnI+DQomZ3Q7IEkgd2lsbCBleHRlbmQgdGhlIEFDTCBZQU5HIG1vZGVsIGluIHRoZSBu ZXh0IHJldmlzaW9uLiA8YnI+DQo8YnI+DQpBbmQgdGhlIGxhdGVzdCB2ZXJzaW9uIG9mIGRyYWZ0 LWlldGYtbmV0bW9kLWFjbC1tb2RlbCAoLTExKSBpbmNsdWRlcyBJQ01QLUFDTCAodHlwZSwgY29k ZSwsKTxicj4NCkkgdGhpbmsgd2Ugc2hvdWxkIHVwZGF0ZSB0aGUgZHJhZnQuPGJyPg0KPGJyPg0K KiBIb3cgZG8gd2UgaGFuZGxlIGZyYWdtZW50YXRpb24gaW4gYSBtaXRpZ2F0aW9uIHNpZ25hbCBy ZXF1ZXN0Pzxicj4NCmZyYWdtZW50YXRpb24gY2FuIGJlIHJlcHJlc2VudGVkIGFzIHBvcnQ9MC4g SXMgdGhpcyBhIHN1ZmZpY2llbnQgcmVwcmVzZW50YXRpb24/PGJyPg0KPGJyPg0KdGhhbmtzLDxi cj4NCkthbmFtZTxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk9uIDIwMTcvMDgvMDMgMzoyNywgRG9iYmlucywgUm9sYW5kIHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+T24gQXVnIDIsIDIwMTcsIGF0IDIyOjI1LCBK b24gU2hhbGxvdyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb20i PnN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gZHJhZnQtaWV0Zi1kb3Rz LXVzZS1jYXNlcy0wNyA8YnI+DQozLjEuNi4gJm5ic3A7RW5kLWN1c3RvbWVyIG9wZXJhdGluZyBh IENQRSBuZXR3b3JrIGluZnJhc3RydWN0dXJlIGRldmljZSB3aXRoPGJyPg0KJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7YW4gaW50ZWdyYXRlZCBET1RTIGNsaWVudDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4zLjEu NiBmcm9tIGlkcmFmdC1pZXRmLWRvdHMtdXNlLWNhc2VzLTA3IGluIGZ1bGw6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibXNvLWVsZW1lbnQ6cGFyYS1ib3Jk ZXItZGl2O2JvcmRlcjpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6OC4wcHQgOC4wcHQgOC4w cHQgOC4wcHQ7YmFja2dyb3VuZDojRkZGREY1Ij4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206 Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25l O3BhZGRpbmc6MGluO2JveC1zaXppbmc6IGJvcmRlci1ib3g7d29yZC13cmFwOiBicmVhay13b3Jk O2JvcmRlci10b3AtbGVmdC1yYWRpdXM6IDRweDtib3JkZXItdG9wLXJpZ2h0LXJhZGl1czogNHB4 O2JvcmRlci1ib3R0b20tcmlnaHQtcmFkaXVzOiA0cHg7Ym9yZGVyLWJvdHRvbS1sZWZ0LXJhZGl1 czogNHB4Oy13ZWJraXQtdGFwLWhpZ2hsaWdodC1jb2xvcjogcmdiYSgwLCAwLCAwLCAwKTstd2Vi a2l0LXRleHQtc2l6ZS1hZGp1c3Q6IDEwMCU7b3ZlcmZsb3c6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQiPjMuMS42LiZuYnNwOyBFbmQtY3VzdG9tZXIgb3BlcmF0aW5nIGEgQ1BF IG5ldHdvcmsgaW5mcmFzdHJ1Y3R1cmUgZGV2aWNlIHdpdGg8bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dv cmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGluIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IGFuIGludGVncmF0ZWQgRE9UUyBjbGllbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJl YWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGluIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJt YXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFs bDtib3JkZXI6bm9uZTtwYWRkaW5nOjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQi PiZuYnNwOyZuYnNwOyBTaW1pbGFyIHRvIHRoZSBhYm92ZSB1c2UtY2FzZSBmZWF0dXJpbmcgYXBw bGljYXRpb25zIG9yIHNlcnZpY2VzIHdpdGg8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUg c3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6 YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGluIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdCI+Jm5ic3A7Jm5ic3A7IGJ1aWx0LWluIEREb1MgYXR0YWNrIGRldGVjdGlvbi9jbGFz c2lmaWNhdGlvbiBhbmQgRE9UUyBjbGllbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUg c3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6 YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGluIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdCI+Jm5ic3A7Jm5ic3A7IGNhcGFiaWxpdGllcywgaW4gdGhpcyBzY2VuYXJpbywgYW4g ZW5kLWN1c3RvbWVyIG5ldHdvcms8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9 Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWst YWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dCI+Jm5ic3A7Jm5ic3A7IGluZnJhc3RydWN0dXJlIENQRSBkZXZpY2Ugc3VjaCBhcyBhIHJvdXRl ciwgbGF5ZXItMyBzd2l0Y2gsIGZpcmV3YWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVh azpicmVhay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGluZzowaW4iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0Ij4mbmJzcDsmbmJzcDsgb3IgbG9hZC1iYWxhbmNlIGluY29ycG9yYXRlcyBib3Ro IHRoZSBmdW5jdGlvbmFsaXR5IHJlcXVpcmVkIHRvPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJy ZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQiPiZuYnNwOyZuYnNwOyBkZXRlY3QgYW5kIGNsYXNzaWZ5IGluY29taW5nIERE b1MgYXR0YWNrcyBhcyB3ZWxsIGFzIERPVFMgY2xpZW50PG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3Jk LWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBpbiI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQiPiZuYnNwOyZuYnNwOyBmdW5jdGlvbmFsaXR5LjxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNG RkZERjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGluZzowaW4iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQt YnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGluIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdCI+Jm5ic3A7Jm5ic3A7IFRoZSBzdWJzZXF1ZW50IERPVFMgY29tbXVuaWNh dGlvbnMgZGlhbG9ndWUgYW5kIHJlc3VsdGFudCBERG9TPG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3Jk LWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBpbiI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQiPiZuYnNwOyZuYnNwOyBtaXRpZ2F0aW9uIGluaXRpYXRpb24gYW5kIHRl cm1pbmF0aW9uIGFjdGl2aXRpZXMgdGFrZSBwbGFjZSBpbiB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1 O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGluIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdCI+Jm5ic3A7Jm5ic3A7IHNhbWUgbWFubmVyIGFzIHRoZSB1c2Ut Y2FzZXMgZGVzY3JpYmVkIGFib3ZlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHls ZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOndoaXRlO3dvcmQtYnJlYWs6YnJlYWst YWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGluO2JveC1zaXppbmc6IGJvcmRlci1ib3g7d29yZC13 cmFwOiBicmVhay13b3JkO2JvcmRlci10b3AtbGVmdC1yYWRpdXM6IDRweDtib3JkZXItdG9wLXJp Z2h0LXJhZGl1czogNHB4O2JvcmRlci1ib3R0b20tcmlnaHQtcmFkaXVzOiA0cHg7Ym9yZGVyLWJv dHRvbS1sZWZ0LXJhZGl1czogNHB4O292ZXJmbG93OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtVSUNURm9udFRleHRTdHlsZVRhbGxCb2R5JnF1b3Q7LHNlcmlmIj4tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSA8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1zby1lbGVtZW50OnBhcmEtYm9yZGVyLWRpdjtib3Jk ZXI6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjguMHB0IDguMHB0IDguMHB0IDguMHB0Ij4N CjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7d29yZC1icmVhazpicmVhay1hbGw7Ym9y ZGVyOm5vbmU7cGFkZGluZzowaW4iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtVSUNU Rm9udFRleHRTdHlsZVRhbGxCb2R5JnF1b3Q7LHNlcmlmIj5Sb2xhbmQgRG9iYmlucyAmbHQ7PGEg aHJlZj0ibWFpbHRvOnJkb2JiaW5zQGFyYm9yLm5ldCI+cmRvYmJpbnNAYXJib3IubmV0PC9hPiZn dDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHByZT5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPkRvdHMgbWFpbGluZyBsaXN0PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEg aHJlZj0ibWFpbHRvOkRvdHNAaWV0Zi5vcmciPkRvdHNAaWV0Zi5vcmc8L2E+PG86cD48L286cD48 L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9kb3RzIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHM8L2E+PG86 cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DM5PR16MB17887F73606FE7D920125FC2EAB10DM5PR16MB1788namp_-- From nobody Thu Aug 3 01:14:52 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25AF8132323 for ; Thu, 3 Aug 2017 01:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BAvVWgDCMM9 for ; Thu, 3 Aug 2017 01:14:49 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AF58126CB6 for ; Thu, 3 Aug 2017 01:14:49 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1ddBHL-0000D1-Tt for ietf-supjps-dots@ietf.org; Thu, 03 Aug 2017 09:14:48 +0100 From: "Jon Shallow" To: References: <035401d30b77$fb3a1da0$f1ae58e0$@jpshallow.com> In-Reply-To: Date: Thu, 3 Aug 2017 09:14:49 +0100 Message-ID: <042c01d30c30$93ad0670$bb071350$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_042D_01D30C38.F5727FE0" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQI4Xj59hXHis+FNi2tfJtTtHlSsOQLJsfx7oZFS+IA= Archived-At: Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for 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, 03 Aug 2017 08:14:51 -0000 This is a multipart message in MIME format. ------=_NextPart_000_042D_01D30C38.F5727FE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Tiru, I agree that it is highly likely that a DDoS Attack will mutate over its life time. Reflections attacks (where the source port is constant - e.g. 53 or 123 udp) do not mutate so frequently in my experience and there is no way to signal for that type of to be stopped currently. The DOTS client may continue to change its mitigation requests as the attacks evolve / mutate which is fine from my perspective. I really want to move away from Vendor Specifics for the more common definitions so that there is a standard across all vendors - even if the parameters are optional and are just hints. I am not trying to re-create FlowSpec here in the signal parameters, but there (co-incidentally) is a large overlap. FlowSpec does not support Uri, but I think that is a good thing in dots-signal-channel. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 03 August 2017 08:58 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation The source IP addresses and source ports used by the DDoS attacker could change, the type of attack itself could evolve or change from one attack type to another. It was discussed in the WG that this kind of information are only hints and not mandatory to be conveyed by the DOTS client in the mitigation request. https://tools.ietf.org/html/draft-ietf-dots-requirements-06 only discusses conveying the mitigation scope and not the source or type of the attack. However, DOTS signal channel draft allows vendor specific parameters and reserved key values in the range of 32768 to 65536 for vendor specific parameters, these hints can be conveyed as vendor-specific parameters to the DOTS server. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Wednesday, August 2, 2017 3:43 PM To: dots@ietf.org Subject: [Dots] Signal / Data / Alias / Filter Implementation Hi There, I am trying to get my mind around how to implement this and have some questions / statements. Signal Channel The Signal channel looks very like Destination RTBH with some extras (protocols / port) as everything is target-* based. There is no concept of source-ip, source-port (to handle reflection attacks) etc. or dealing with fragmented packet, icmp types and rate-limiting. The DOTS client may have the smarts to work out what are the problematic source-* etc. values (e.g. can generate smart BGP FlowSpec rules) are that will sensibly control the DDoS Attack. It is possible to use a previously defined alias over the Data Channel as an alternative for a mitigation request, but this too has source-* etc. limitations. I have not found a way of using a Filter defined over the Data Channel as a signal Sending a signal will cause all traffic to stop (or rate-limit possibly if it also happens to match a filter) to the target IP on the ports in question - DDoS attack is now effective unless the DOTS server elects (via DNS or BGP swing) to scrub that particular traffic (by controlling rates, Source IPs / Source Ports etc.). Data Channel Can be used to set up aliases for later use. These again however appear to be target-* based, with no source-*, icmp type or fragmentation capabilities. Can set up a Filter, which does include both source and destination IPs, but appears that it is acted on when pushed over the data channel, and cannot be send as a signal - appears to be in place more for black/white listing IPs than as a signal for mitigation, but does include rate-limiting Questions How do we handle Source-* information in a mitigation signal request? How do we handle specific ICMP types in a mitigation signal request? How do we handle fragmentation in a mitigation signal request? Regards Jon ------=_NextPart_000_042D_01D30C38.F5727FE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

I agree that it is = highly likely that a DDoS Attack will mutate over its life time.  = Reflections attacks (where the source port is constant – e.g. 53 = or 123 udp) do not mutate so frequently in my experience and there is no = way to signal for that type of to be stopped currently.  The DOTS = client may continue to change its mitigation requests as the attacks = evolve / mutate which is fine from my = perspective.

 

I really want to move = away from Vendor Specifics for the more common definitions so that there = is a standard across all vendors – even if the parameters are = optional and are just hints.

 

I am not trying to = re-create FlowSpec here in the signal  parameters, but there = (co-incidentally) is a large overlap.  FlowSpec does not support = Uri, but I think that is a good thing in = dots-signal-channel.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = Konda, Tirumaleswar Reddy
Sent: 03 August 2017 = 08:58
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] Signal / Data / Alias / Filter = Implementation

 

The = source IP addresses and source ports used by the DDoS attacker could = change, the type of attack itself could evolve or change from one attack = type to another.

It = was discussed in the WG that this kind of information are only hints and = not mandatory to be conveyed by the DOTS client in the mitigation = request.  http= s://tools.ietf.org/html/draft-ietf-dots-requirements-06 only = discusses conveying the mitigation scope and not the source or type of = the attack. However, DOTS signal channel draft allows vendor specific = parameters and reserved key values in the range of 32768 to 65536 for = vendor specific parameters, these hints can be conveyed as = vendor-specific parameters to the DOTS server.

 

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of Jon Shallow
Sent: Wednesday, August 2, = 2017 3:43 PM
To: dots@ietf.org
Subject: = [Dots] Signal / Data / Alias / Filter = Implementation

 

Hi There,

 

I am trying = to get my mind around how to implement this and have some questions / = statements.

 

Signal Channel

 

The Signal = channel looks very like Destination RTBH with some extras (protocols / = port) as everything is target-* based.  There is no concept of = source-ip, source-port (to handle reflection attacks) etc. or dealing = with fragmented packet, icmp types and rate-limiting.

 

The DOTS = client may have the smarts to work out what are the problematic source-* = etc. values (e.g. can generate smart BGP FlowSpec rules) are that will = sensibly control the DDoS Attack.

 

It is = possible to use a previously defined alias over the Data Channel as an = alternative for a mitigation request, but this too has source-* etc. = limitations.

I have not found a way = of using a Filter defined over the Data Channel as a = signal

 

Sending a signal will cause all traffic to stop (or = rate-limit possibly if it also happens to match a filter) to the target = IP on the ports in question -  DDoS attack is now effective unless = the DOTS server elects (via DNS or BGP swing) to scrub that particular = traffic (by controlling rates, Source IPs / Source Ports = etc.).

 

Data Channel

 

Can be used = to set up aliases for later use.  These again however appear to be = target-* based, with no source-*, icmp type or fragmentation = capabilities.

 

Can set up a Filter, which does include both source = and destination IPs, but appears that it is acted on when pushed over = the data channel, and cannot be send as a signal – appears to be = in place more for black/white listing IPs than as a signal for = mitigation, but does include rate-limiting

 

Questions

 

How do we = handle Source-* information in a mitigation signal = request?

How do we handle specific = ICMP types  in a mitigation signal request?

How do we handle fragmentation  in a mitigation = signal request?

 

Regards

 

Jon

 

------=_NextPart_000_042D_01D30C38.F5727FE0-- From nobody Thu Aug 3 01:44:28 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12D88126CC4 for ; Thu, 3 Aug 2017 01:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMOzpek4-Qlk for ; Thu, 3 Aug 2017 01:44:23 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 586DD12F290 for ; Thu, 3 Aug 2017 01:44:23 -0700 (PDT) Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp id 0fc8_457f_4173b65d_976f_4c9f_9c19_be3df39dddc0; Thu, 03 Aug 2017 03:44:18 -0500 Received: from DNVEXUSR1N14.corpzone.internalzone.com (10.44.48.87) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 3 Aug 2017 02:44:17 -0600 Received: from DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) by DNVEXUSR1N14.corpzone.internalzone.com (10.44.48.87) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 3 Aug 2017 02:44:16 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1263.5 via Frontend Transport; Thu, 3 Aug 2017 02:44:16 -0600 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (10.44.176.240) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 3 Aug 2017 02:44:15 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.onmicrosoft.com; s=selector1-mcafee-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9aECTLYBNNJm9ajZuMkpv8/KhLqai+NP6Mlas+1QzNo=; b=FJwap8RbKm2VI5ZJxAVkLIRAoUyXv2Mc/Ntlrn8aO61yC1dKrTfXnzi77ZOm/k9AtDiI34hBUBB22/dcKO1d8//ni7CQchh2Npy9n4JxnWWtpr0ahlMghJpTWs/GD/VEVa1A1wy5IZv1+/C/Jq4hobmbroo2Cu9sIGBH5q1XzE0= Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1787.namprd16.prod.outlook.com (10.172.44.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.22; Thu, 3 Aug 2017 08:44:14 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.01.1304.023; Thu, 3 Aug 2017 08:44:13 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Signal / Data / Alias / Filter Implementation Thread-Index: AdMLd/i8iwFwzTfWQ/S7HayGj5igcAAtQcoAAADkzoAAAOO7QA== Date: Thu, 3 Aug 2017 08:44:13 +0000 Message-ID: References: <035401d30b77$fb3a1da0$f1ae58e0$@jpshallow.com> <042c01d30c30$93ad0670$bb071350$@jpshallow.com> In-Reply-To: <042c01d30c30$93ad0670$bb071350$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1787; 7:hSFW4ud2YONW2vFmJGYYV49g0To+fvs7W1/9tQHdUNq0n628a8a0ac7PlgNwLq5rpgTZzJQZUYEUjk/meDho7btVKskSJszq9W4jSyhFm0/G5RDNmvXJH525ft2NgasuLF+LFHJF1lbl2sEewIVOEXEcnBtthLZ/TBzfMwSvyxmuyWmK4exYJWj//iTDlvDmiU9hZRAy8JLspHnN4Tlrztp+xKVvKXXQ8GWaMJpbDDeOAmdMaqekOs5JDZxnggQrAXd8nO2QKFkQdmxpFlDpaLZiQhFGR/m4MUejB6gqtkj7ypxvJQjXAs5yLfeipjMxY3G4DLf4t5qtWm2pUSCFJEP0MUDzjA3HNrBsdL44TAonyNMmBJs0UZdgJIr/DxGNd94zkEJiL4inbPBxY4rLzU43kY9QFh+Hq1Tx2iqjAER/jFuNpfnLqqo5XHA6TBDib2o0FLrZuFQtwVwx98YmYk/ZZ1teObyrTsLR7NVMbuGJm/68Nk/vHrbtvlAT1ug4KZchP0ZjpMcmDUucNFxijl+c1/IhwkMEt89al5BNgYzLxYK3MqWb25QXHy8alIY/KTv6/cRsCyydp6Pb85tUoleCYK+Ko3O/gaMfR6LFzMcsZ8heiaCplueQCp/FsCKOg0l4kkv5/gLf+mK0V6sHln0vGW2jBGG++/UEyydGTCy1ewvbjztUZvRoR2YtMOGVG0dR3Cu16DkHTQ1MqKdHiVb1S/YyvoTq4WI6M0JUldKi0eL+qyxkrgF4nC5nqlQVJoefGJNWvc3a4suWvhpOI3bTaS3zHGeGM79a5Q7a/b4= x-ms-office365-filtering-correlation-id: 4e033b6c-539e-41e3-0f0b-08d4da4bd15d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM5PR16MB1787; x-ms-traffictypediagnostic: DM5PR16MB1787: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(3002001)(6041248)(20161123560025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1787; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1787; x-forefront-prvs: 03883BD916 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39400400002)(39410400002)(39450400003)(39840400002)(39850400002)(32952001)(377454003)(199003)(51444003)(189002)(76176999)(9686003)(80792005)(50986999)(54356999)(229853002)(606006)(55016002)(54896002)(6306002)(99286003)(53936002)(9326002)(72206003)(25786009)(97736004)(6246003)(68736007)(2900100001)(53546010)(74316002)(101416001)(38730400002)(3280700002)(3660700001)(236005)(19609705001)(7696004)(14454004)(966005)(105586002)(106356001)(6506006)(478600001)(6436002)(3846002)(102836003)(8676002)(5660300001)(33656002)(86362001)(790700001)(81166006)(81156014)(7736002)(2906002)(8936002)(66066001)(189998001)(77096006)(6116002)(2950100002)(2501003)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1787; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB178860DB65938F50187AAC2AEAB10DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2017 08:44:13.3990 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1787 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6085> : inlines <6005> : streams <1756963> : uri <2475411> Archived-At: Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for 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, 03 Aug 2017 08:44:26 -0000 --_000_DM5PR16MB178860DB65938F50187AAC2AEAB10DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jon, We discussed various such hints including "attack details" in https://tools= .ietf.org/html/draft-doron-dots-telemetry-00. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Thursday, August 3, 2017 1:45 PM To: dots@ietf.org Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation Hi Tiru, I agree that it is highly likely that a DDoS Attack will mutate over its li= fe time. Reflections attacks (where the source port is constant - e.g. 53 = or 123 udp) do not mutate so frequently in my experience and there is no wa= y to signal for that type of to be stopped currently. The DOTS client may = continue to change its mitigation requests as the attacks evolve / mutate w= hich is fine from my perspective. I really want to move away from Vendor Specifics for the more common defini= tions so that there is a standard across all vendors - even if the paramete= rs are optional and are just hints. I am not trying to re-create FlowSpec here in the signal parameters, but t= here (co-incidentally) is a large overlap. FlowSpec does not support Uri, = but I think that is a good thing in dots-signal-channel. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 03 August 2017 08:58 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation The source IP addresses and source ports used by the DDoS attacker could ch= ange, the type of attack itself could evolve or change from one attack type= to another. It was discussed in the WG that this kind of information are only hints and= not mandatory to be conveyed by the DOTS client in the mitigation request.= https://tools.ietf.org/html/draft-ietf-dots-requirements-06 only discusse= s conveying the mitigation scope and not the source or type of the attack. = However, DOTS signal channel draft allows vendor specific parameters and re= served key values in the range of 32768 to 65536 for vendor specific parame= ters, these hints can be conveyed as vendor-specific parameters to the DOTS= server. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Wednesday, August 2, 2017 3:43 PM To: dots@ietf.org Subject: [Dots] Signal / Data / Alias / Filter Implementation Hi There, I am trying to get my mind around how to implement this and have some quest= ions / statements. Signal Channel The Signal channel looks very like Destination RTBH with some extras (proto= cols / port) as everything is target-* based. There is no concept of sourc= e-ip, source-port (to handle reflection attacks) etc. or dealing with fragm= ented packet, icmp types and rate-limiting. The DOTS client may have the smarts to work out what are the problematic so= urce-* etc. values (e.g. can generate smart BGP FlowSpec rules) are that wi= ll sensibly control the DDoS Attack. It is possible to use a previously defined alias over the Data Channel as a= n alternative for a mitigation request, but this too has source-* etc. limi= tations. I have not found a way of using a Filter defined over the Data Channel as a= signal Sending a signal will cause all traffic to stop (or rate-limit possibly if = it also happens to match a filter) to the target IP on the ports in questio= n - DDoS attack is now effective unless the DOTS server elects (via DNS or= BGP swing) to scrub that particular traffic (by controlling rates, Source = IPs / Source Ports etc.). Data Channel Can be used to set up aliases for later use. These again however appear to= be target-* based, with no source-*, icmp type or fragmentation capabiliti= es. Can set up a Filter, which does include both source and destination IPs, bu= t appears that it is acted on when pushed over the data channel, and cannot= be send as a signal - appears to be in place more for black/white listing = IPs than as a signal for mitigation, but does include rate-limiting Questions How do we handle Source-* information in a mitigation signal request? How do we handle specific ICMP types in a mitigation signal request? How do we handle fragmentation in a mitigation signal request? Regards Jon --_000_DM5PR16MB178860DB65938F50187AAC2AEAB10DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jon,

&nbs= p;

We discus= sed various such hints including “attack details” in https= ://tools.ietf.org/html/draft-doron-dots-telemetry-00.=

&nbs= p;

-Tiru

 

From:<= /span> Dots [mailto:dots-bou= nces@ietf.org] On Behalf Of Jon Shallow
Sent: Thursday, August 3, 2017 1:45 PM
To: dots@ietf.org
Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation

 

Hi Tiru= ,

&n= bsp;

I agree= that it is highly likely that a DDoS Attack will mutate over its life time= .  Reflections attacks (where the source port is constant – e.g.= 53 or 123 udp) do not mutate so frequently in my experience and there is no way to signal for that type of to be stopped cu= rrently.  The DOTS client may continue to change its mitigation reques= ts as the attacks evolve / mutate which is fine from my perspective.

&n= bsp;

I reall= y want to move away from Vendor Specifics for the more common definitions s= o that there is a standard across all vendors – even if the parameter= s are optional and are just hints.

&n= bsp;

I am no= t trying to re-create FlowSpec here in the signal  parameters, but the= re (co-incidentally) is a large overlap.  FlowSpec does not support Ur= i, but I think that is a good thing in dots-signal-channel.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 03 August 2017 08:58
To: Jon Shallow; dots@ietf.org<= br> Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation

 

The source IP addresses and source ports used by the DDoS attacker = could change, the type of attack itself could evolve or change from one att= ack type to another.

It was discussed in the WG that this kind of information are only h= ints and not mandatory to be conveyed by the DOTS client in the mitigation = request.  https://tools.ietf.org/html/draft-ietf-dots-requirements-06 only discusses conveying the mitigation scope and not the source or type o= f the attack. However, DOTS signal channel draft allows vendor specific par= ameters and reserved key values in the range of 32768 to 65536 for vendor s= pecific parameters, these hints can be conveyed as vendor-specific parameters to the DOTS server.

 

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Wednesday, August 2, 2017 3:43 PM
To: dots@ietf.org
Subject: [Dots] Signal / Data / Alias / Filter Implementation

 

Hi There,

 

I am trying to get my mind arou= nd how to implement this and have some questions / statements.

 

Signal Channel

 

The Signal channel looks very l= ike Destination RTBH with some extras (protocols / port) as everything is t= arget-* based.  There is no concept of source-ip, source-port (to hand= le reflection attacks) etc. or dealing with fragmented packet, icmp types and rate-limiting.

 

The DOTS client may have the sm= arts to work out what are the problematic source-* etc. values (e.g. can ge= nerate smart BGP FlowSpec rules) are that will sensibly control the DDoS At= tack.

 

It is possible to use a previou= sly defined alias over the Data Channel as an alternative for a mitigation = request, but this too has source-* etc. limitations.

I have not found a way of using= a Filter defined over the Data Channel as a signal

 

Sending a signal will cause all= traffic to stop (or rate-limit possibly if it also happens to match a filt= er) to the target IP on the ports in question -  DDoS attack is now ef= fective unless the DOTS server elects (via DNS or BGP swing) to scrub that particular traffic (by controlling rates, = Source IPs / Source Ports etc.).

 

Data Channel

 

Can be used to set up aliases f= or later use.  These again however appear to be target-* based, with n= o source-*, icmp type or fragmentation capabilities.

 

Can set up a Filter, which does= include both source and destination IPs, but appears that it is acted on w= hen pushed over the data channel, and cannot be send as a signal – ap= pears to be in place more for black/white listing IPs than as a signal for mitigation, but does include rate-limitin= g

 

Questions<= /b>

 

How do we handle Source-* infor= mation in a mitigation signal request?

How do we handle specific ICMP = types  in a mitigation signal request?

How do we handle fragmentation =  in a mitigation signal request?

 

Regards

 

Jon

 

--_000_DM5PR16MB178860DB65938F50187AAC2AEAB10DM5PR16MB1788namp_-- From nobody Thu Aug 3 02:01:01 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ACCA126CC4 for ; Thu, 3 Aug 2017 02:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id alwVYYIhkDYb for ; Thu, 3 Aug 2017 02:00:57 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A648712F290 for ; Thu, 3 Aug 2017 02:00:53 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1ddBzw-0000Ei-73 for ietf-supjps-dots@ietf.org; Thu, 03 Aug 2017 10:00:52 +0100 From: "Jon Shallow" To: References: <035401d30b77$fb3a1da0$f1ae58e0$@jpshallow.com> <042c01d30c30$93ad0670$bb071350$@jpshallow.com> In-Reply-To: Date: Thu, 3 Aug 2017 10:00:54 +0100 Message-ID: <044b01d30c37$034e3cf0$09eab6d0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_044C_01D30C3F.65140480" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQI4Xj59hXHis+FNi2tfJtTtHlSsOQLJsfx7AdboHUsCSD9NFKFwaKdQ Archived-At: Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for 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, 03 Aug 2017 09:00:59 -0000 This is a multipart message in MIME format. ------=_NextPart_000_044C_01D30C3F.65140480 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Tiru, Thanks for the document pointer - a good read and reminds me of the initial work I did with Nik Teague on getting DOTS started. However, it is still unclear to me how the "DOTS Telemetry" intelligence/hints can be conveyed over the signal and data channels using what is currently defined, unless it is all done over the data channel using ietf-dots-access-control-list. My preferred option is that ietf-dots-signal is extended to cover the more common attributes of an DDoS Attack. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 03 August 2017 09:44 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation Hi Jon, We discussed various such hints including "attack details" in https://tools.ietf.org/html/draft-doron-dots-telemetry-00. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Thursday, August 3, 2017 1:45 PM To: dots@ietf.org Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation Hi Tiru, I agree that it is highly likely that a DDoS Attack will mutate over its life time. Reflections attacks (where the source port is constant - e.g. 53 or 123 udp) do not mutate so frequently in my experience and there is no way to signal for that type of to be stopped currently. The DOTS client may continue to change its mitigation requests as the attacks evolve / mutate which is fine from my perspective. I really want to move away from Vendor Specifics for the more common definitions so that there is a standard across all vendors - even if the parameters are optional and are just hints. I am not trying to re-create FlowSpec here in the signal parameters, but there (co-incidentally) is a large overlap. FlowSpec does not support Uri, but I think that is a good thing in dots-signal-channel. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 03 August 2017 08:58 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation The source IP addresses and source ports used by the DDoS attacker could change, the type of attack itself could evolve or change from one attack type to another. It was discussed in the WG that this kind of information are only hints and not mandatory to be conveyed by the DOTS client in the mitigation request. https://tools.ietf.org/html/draft-ietf-dots-requirements-06 only discusses conveying the mitigation scope and not the source or type of the attack. However, DOTS signal channel draft allows vendor specific parameters and reserved key values in the range of 32768 to 65536 for vendor specific parameters, these hints can be conveyed as vendor-specific parameters to the DOTS server. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Wednesday, August 2, 2017 3:43 PM To: dots@ietf.org Subject: [Dots] Signal / Data / Alias / Filter Implementation Hi There, I am trying to get my mind around how to implement this and have some questions / statements. Signal Channel The Signal channel looks very like Destination RTBH with some extras (protocols / port) as everything is target-* based. There is no concept of source-ip, source-port (to handle reflection attacks) etc. or dealing with fragmented packet, icmp types and rate-limiting. The DOTS client may have the smarts to work out what are the problematic source-* etc. values (e.g. can generate smart BGP FlowSpec rules) are that will sensibly control the DDoS Attack. It is possible to use a previously defined alias over the Data Channel as an alternative for a mitigation request, but this too has source-* etc. limitations. I have not found a way of using a Filter defined over the Data Channel as a signal Sending a signal will cause all traffic to stop (or rate-limit possibly if it also happens to match a filter) to the target IP on the ports in question - DDoS attack is now effective unless the DOTS server elects (via DNS or BGP swing) to scrub that particular traffic (by controlling rates, Source IPs / Source Ports etc.). Data Channel Can be used to set up aliases for later use. These again however appear to be target-* based, with no source-*, icmp type or fragmentation capabilities. Can set up a Filter, which does include both source and destination IPs, but appears that it is acted on when pushed over the data channel, and cannot be send as a signal - appears to be in place more for black/white listing IPs than as a signal for mitigation, but does include rate-limiting Questions How do we handle Source-* information in a mitigation signal request? How do we handle specific ICMP types in a mitigation signal request? How do we handle fragmentation in a mitigation signal request? Regards Jon ------=_NextPart_000_044C_01D30C3F.65140480 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

Thanks for the document = pointer – a good read and reminds me of the initial work I did = with Nik Teague on getting DOTS started.

 

However, it is still = unclear to me how the “DOTS Telemetry” intelligence/hints = can be conveyed over the signal and data channels using what is = currently defined, unless it is all done over the data channel using = ietf-dots-access-control-list.  My preferred option is that = ietf-dots-signal is extended to cover the more common attributes of an = DDoS Attack.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = Konda, Tirumaleswar Reddy
Sent: 03 August 2017 = 09:44
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] Signal / Data / Alias / Filter = Implementation

 

Hi = Jon,

 

We discussed various such hints = including “attack details” in https:= //tools.ietf.org/html/draft-doron-dots-telemetry-00.

 

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of Jon Shallow
Sent: Thursday, August 3, 2017 = 1:45 PM
To: dots@ietf.org
Subject: Re: = [Dots] Signal / Data / Alias / Filter = Implementation

 

Hi = Tiru,

 

I agree that it is = highly likely that a DDoS Attack will mutate over its life time.  = Reflections attacks (where the source port is constant – e.g. 53 = or 123 udp) do not mutate so frequently in my experience and there is no = way to signal for that type of to be stopped currently.  The DOTS = client may continue to change its mitigation requests as the attacks = evolve / mutate which is fine from my = perspective.

 

I really want to move = away from Vendor Specifics for the more common definitions so that there = is a standard across all vendors – even if the parameters are = optional and are just hints.

 

I am not trying to = re-create FlowSpec here in the signal  parameters, but there = (co-incidentally) is a large overlap.  FlowSpec does not support = Uri, but I think that is a good thing in = dots-signal-channel.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 03 August 2017 = 08:58
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] Signal / Data / Alias / Filter = Implementation

 

The = source IP addresses and source ports used by the DDoS attacker could = change, the type of attack itself could evolve or change from one attack = type to another.

It = was discussed in the WG that this kind of information are only hints and = not mandatory to be conveyed by the DOTS client in the mitigation = request.  http= s://tools.ietf.org/html/draft-ietf-dots-requirements-06 only = discusses conveying the mitigation scope and not the source or type of = the attack. However, DOTS signal channel draft allows vendor specific = parameters and reserved key values in the range of 32768 to 65536 for = vendor specific parameters, these hints can be conveyed as = vendor-specific parameters to the DOTS server.

 

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of Jon Shallow
Sent: Wednesday, August 2, = 2017 3:43 PM
To: dots@ietf.org
Subject: = [Dots] Signal / Data / Alias / Filter = Implementation

 

Hi There,

 

I am trying = to get my mind around how to implement this and have some questions / = statements.

 

Signal Channel

 

The Signal = channel looks very like Destination RTBH with some extras (protocols / = port) as everything is target-* based.  There is no concept of = source-ip, source-port (to handle reflection attacks) etc. or dealing = with fragmented packet, icmp types and rate-limiting.

 

The DOTS = client may have the smarts to work out what are the problematic source-* = etc. values (e.g. can generate smart BGP FlowSpec rules) are that will = sensibly control the DDoS Attack.

 

It is = possible to use a previously defined alias over the Data Channel as an = alternative for a mitigation request, but this too has source-* etc. = limitations.

I have not found a way = of using a Filter defined over the Data Channel as a = signal

 

Sending a signal will cause all traffic to stop (or = rate-limit possibly if it also happens to match a filter) to the target = IP on the ports in question -  DDoS attack is now effective unless = the DOTS server elects (via DNS or BGP swing) to scrub that particular = traffic (by controlling rates, Source IPs / Source Ports = etc.).

 

Data Channel

 

Can be used = to set up aliases for later use.  These again however appear to be = target-* based, with no source-*, icmp type or fragmentation = capabilities.

 

Can set up a Filter, which does include both source = and destination IPs, but appears that it is acted on when pushed over = the data channel, and cannot be send as a signal – appears to be = in place more for black/white listing IPs than as a signal for = mitigation, but does include rate-limiting

 

Questions

 

How do we = handle Source-* information in a mitigation signal = request?

How do we handle specific = ICMP types  in a mitigation signal request?

How do we handle fragmentation  in a mitigation = signal request?

 

Regards

 

Jon

 

------=_NextPart_000_044C_01D30C3F.65140480-- From nobody Thu Aug 3 02:35:18 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76A55131D27 for ; Thu, 3 Aug 2017 02:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFUc0wr21Png for ; Thu, 3 Aug 2017 02:35:09 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 D21F1131D25 for ; Thu, 3 Aug 2017 02:35:08 -0700 (PDT) Received: from MIVEXAPP1N01.corpzone.internalzone.com (unknown [10.48.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp id 0fd2_3578_467511d0_ee65_4d7c_bbc6_1c44d0a06d7c; Thu, 03 Aug 2017 04:35:06 -0500 Received: from MIVEXUSR1N02.corpzone.internalzone.com (10.48.48.82) by MIVEXAPP1N01.corpzone.internalzone.com (10.48.48.88) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 3 Aug 2017 05:35:05 -0400 Received: from MIVEXUSR1N01.corpzone.internalzone.com (10.48.48.81) by MIVEXUSR1N02.corpzone.internalzone.com (10.48.48.82) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 3 Aug 2017 05:35:04 -0400 Received: from MIVO365EDGE3.corpzone.internalzone.com (10.48.176.86) by MIVEXUSR1N01.corpzone.internalzone.com (10.48.48.81) with Microsoft SMTP Server (TLS) id 15.0.1263.5 via Frontend Transport; Thu, 3 Aug 2017 05:35:04 -0400 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (10.48.176.240) by edge.mcafee.com (10.48.176.86) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 3 Aug 2017 05:34:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.onmicrosoft.com; s=selector1-mcafee-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=yz2aYFw9PMEM+MdVhY8nXUV7/MxoolReTszDdMHbL4Q=; b=e9l5QxqD5GeSw218U02eBaFntIL/DpQ2w9wKjWfImjuaXxni19MkkqSJwnz9s5JJy72nVoikNcXavvEYqpyTyi/8FcX/FXvuqujiWcRSdKWHIZTN0epgzJqKzFyx/Dn8KoQ9fGv0fDa8qw7++gIELsboAqlFSO6fiv2EybKI16o= Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1786.namprd16.prod.outlook.com (10.172.44.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.22; Thu, 3 Aug 2017 09:35:02 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.01.1304.023; Thu, 3 Aug 2017 09:35:02 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Signal / Data / Alias / Filter Implementation Thread-Index: AdMLd/i8iwFwzTfWQ/S7HayGj5igcAAtQcoAAADkzoAAAOO7QAAAuEkAAABl6xA= Date: Thu, 3 Aug 2017 09:35:02 +0000 Message-ID: References: <035401d30b77$fb3a1da0$f1ae58e0$@jpshallow.com> <042c01d30c30$93ad0670$bb071350$@jpshallow.com> <044b01d30c37$034e3cf0$09eab6d0$@jpshallow.com> In-Reply-To: <044b01d30c37$034e3cf0$09eab6d0$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1786; 7:DQaIe5sPb0MqlXe4mvHD6Qde5b90aXac+SfV+ldaUyoP1A4AC5hzZjG5AAhNW3DOBZDr9O2xsClLKVxxaKgJ+xCxfscjo2/vr+ZHvrL3DMTr9iTBg1SkUMhb6NqcsAwIwBF0jhX2Y2rvFttBN6jULQoaYI0o9zsKt6lltM6nslpePYBUGYQ516bHKJKOtz8hASgMcuotDM0laVJTTXmlX04k8LZY4Td9+X1sSxINXkfPW21vbuKG4BbvLznzM17gH9RWTlgH+VUUAk29U9rc+u4FAgXG+GXxLUdcbw1uV9uc2JR6x//MVAHUo1SOaAiV8kYACkh3o82I6xPBnOaDLgRkoVC1FkSGUXVzOMMN8L9emeU+cWaAgj1vchclogEsZ9lBFjaNWhB5Hm2NS/8w3tLNOx3sIBDRWfjLUSKQs4AlpQFSZSrXWUSnlQxlU4i4eQFmmQIcXgf6PNZ54GK4oWy5r/nfxB+R459PuwZ9/b/yViRpKwjg0oCqE9z6OEKV0z6kX/bb67rUUy/0NVEvv7BuqIeV3PdGOhZAAasqTkkechg6i0WZfbWpH4U6QvSy0jEqmFxS7QLSgvjhBjbWwGCErRpOiwbDSrvPXfi59YpA3jVZciX57tKFKe6KpBVI9wl4KfJ+05MoERHWAPd6/QJm1Epoem21LVSe8ZdlLUbRs/UnCO71Wxqr+8G2B9rbRxVovtHvVpg/r1IdRTvv1HOPpKNyhBghbIQ0LWbnh6kbSbs4aqbkEvcBbt2EdbpndIul0xJouhtbYdwg6X3eDN5mYAWSVIz95tPqM+Voh6Y= x-ms-office365-filtering-correlation-id: f10817d9-6d33-4d1e-3100-08d4da52ea9d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM5PR16MB1786; x-ms-traffictypediagnostic: DM5PR16MB1786: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123558100)(20161123562025)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1786; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1786; x-forefront-prvs: 03883BD916 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39450400003)(39840400002)(39400400002)(39410400002)(51444003)(32952001)(199003)(51914003)(377454003)(189002)(606006)(25786009)(6306002)(53546010)(7696004)(76176999)(50986999)(54356999)(97736004)(7736002)(3660700001)(189998001)(6116002)(102836003)(19609705001)(2900100001)(790700001)(77096006)(106356001)(105586002)(229853002)(80792005)(3846002)(6506006)(86362001)(54896002)(14454004)(66066001)(6246003)(38730400002)(9326002)(5660300001)(3280700002)(236005)(53936002)(2950100002)(966005)(6436002)(55016002)(2501003)(72206003)(478600001)(68736007)(8676002)(8936002)(2906002)(9686003)(74316002)(81156014)(99286003)(81166006)(101416001)(93886004)(33656002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1786; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB178821B08674C1C6F2E0E2F3EAB10DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2017 09:35:02.2707 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1786 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6085> : inlines <6005> : uri <2475433> Archived-At: Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for 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, 03 Aug 2017 09:35:12 -0000 --_000_DM5PR16MB178821B08674C1C6F2E0E2F3EAB10DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jon, This draft was presented and discussed in the WG, but since DOTS telemetry = is optional the feedback we got was to pursue this work later and there was= no agreement in the WG on the common attributes of an DDoS attack and the = protocol to convey this information (there were proposals to use DOTS signa= l channel, data channel and IPFIX). -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Thursday, August 3, 2017 2:31 PM To: dots@ietf.org Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation Hi Tiru, Thanks for the document pointer - a good read and reminds me of the initial= work I did with Nik Teague on getting DOTS started. However, it is still unclear to me how the "DOTS Telemetry" intelligence/hi= nts can be conveyed over the signal and data channels using what is current= ly defined, unless it is all done over the data channel using ietf-dots-acc= ess-control-list. My preferred option is that ietf-dots-signal is extended= to cover the more common attributes of an DDoS Attack. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 03 August 2017 09:44 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation Hi Jon, We discussed various such hints including "attack details" in https://tools= .ietf.org/html/draft-doron-dots-telemetry-00. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Thursday, August 3, 2017 1:45 PM To: dots@ietf.org Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation Hi Tiru, I agree that it is highly likely that a DDoS Attack will mutate over its li= fe time. Reflections attacks (where the source port is constant - e.g. 53 = or 123 udp) do not mutate so frequently in my experience and there is no wa= y to signal for that type of to be stopped currently. The DOTS client may = continue to change its mitigation requests as the attacks evolve / mutate w= hich is fine from my perspective. I really want to move away from Vendor Specifics for the more common defini= tions so that there is a standard across all vendors - even if the paramete= rs are optional and are just hints. I am not trying to re-create FlowSpec here in the signal parameters, but t= here (co-incidentally) is a large overlap. FlowSpec does not support Uri, = but I think that is a good thing in dots-signal-channel. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 03 August 2017 08:58 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation The source IP addresses and source ports used by the DDoS attacker could ch= ange, the type of attack itself could evolve or change from one attack type= to another. It was discussed in the WG that this kind of information are only hints and= not mandatory to be conveyed by the DOTS client in the mitigation request.= https://tools.ietf.org/html/draft-ietf-dots-requirements-06 only discusse= s conveying the mitigation scope and not the source or type of the attack. = However, DOTS signal channel draft allows vendor specific parameters and re= served key values in the range of 32768 to 65536 for vendor specific parame= ters, these hints can be conveyed as vendor-specific parameters to the DOTS= server. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Wednesday, August 2, 2017 3:43 PM To: dots@ietf.org Subject: [Dots] Signal / Data / Alias / Filter Implementation Hi There, I am trying to get my mind around how to implement this and have some quest= ions / statements. Signal Channel The Signal channel looks very like Destination RTBH with some extras (proto= cols / port) as everything is target-* based. There is no concept of sourc= e-ip, source-port (to handle reflection attacks) etc. or dealing with fragm= ented packet, icmp types and rate-limiting. The DOTS client may have the smarts to work out what are the problematic so= urce-* etc. values (e.g. can generate smart BGP FlowSpec rules) are that wi= ll sensibly control the DDoS Attack. It is possible to use a previously defined alias over the Data Channel as a= n alternative for a mitigation request, but this too has source-* etc. limi= tations. I have not found a way of using a Filter defined over the Data Channel as a= signal Sending a signal will cause all traffic to stop (or rate-limit possibly if = it also happens to match a filter) to the target IP on the ports in questio= n - DDoS attack is now effective unless the DOTS server elects (via DNS or= BGP swing) to scrub that particular traffic (by controlling rates, Source = IPs / Source Ports etc.). Data Channel Can be used to set up aliases for later use. These again however appear to= be target-* based, with no source-*, icmp type or fragmentation capabiliti= es. Can set up a Filter, which does include both source and destination IPs, bu= t appears that it is acted on when pushed over the data channel, and cannot= be send as a signal - appears to be in place more for black/white listing = IPs than as a signal for mitigation, but does include rate-limiting Questions How do we handle Source-* information in a mitigation signal request? How do we handle specific ICMP types in a mitigation signal request? How do we handle fragmentation in a mitigation signal request? Regards Jon --_000_DM5PR16MB178821B08674C1C6F2E0E2F3EAB10DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jon,

&nbs= p;

This draf= t was presented and discussed in the WG, but since DOTS telemetry is option= al the feedback we got was to pursue this work later and there was no agree= ment in the WG on the common attributes of an DDoS attack and the protocol to convey this information (there were = proposals to use DOTS signal channel, data channel and IPFIX).

&nbs= p;

-Tiru

 

From:<= /span> Dots [mailto:dots-bou= nces@ietf.org] On Behalf Of Jon Shallow
Sent: Thursday, August 3, 2017 2:31 PM
To: dots@ietf.org
Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation

 

Hi Tiru= ,

&n= bsp;

Thanks = for the document pointer – a good read and reminds me of the initial = work I did with Nik Teague on getting DOTS started.

&n= bsp;

However= , it is still unclear to me how the “DOTS Telemetry” intelligen= ce/hints can be conveyed over the signal and data channels using what is cu= rrently defined, unless it is all done over the data channel using ietf-dots-access-control-list.  My preferred option is = that ietf-dots-signal is extended to cover the more common attributes of an= DDoS Attack.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 03 August 2017 09:44
To: Jon Shallow; dots@ietf.org<= br> Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation

 

Hi Jon,

&nbs= p;

We discus= sed various such hints including “attack details” in https= ://tools.ietf.org/html/draft-doron-dots-telemetry-00.=

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Thursday, August 3, 2017 1:45 PM
To: dots@ietf.org
Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation

 

Hi Tiru= ,

&n= bsp;

I agree= that it is highly likely that a DDoS Attack will mutate over its life time= .  Reflections attacks (where the source port is constant – e.g.= 53 or 123 udp) do not mutate so frequently in my experience and there is no way to signal for that type of to be stopped cu= rrently.  The DOTS client may continue to change its mitigation reques= ts as the attacks evolve / mutate which is fine from my perspective.

&n= bsp;

I reall= y want to move away from Vendor Specifics for the more common definitions s= o that there is a standard across all vendors – even if the parameter= s are optional and are just hints.

&n= bsp;

I am no= t trying to re-create FlowSpec here in the signal  parameters, but the= re (co-incidentally) is a large overlap.  FlowSpec does not support Ur= i, but I think that is a good thing in dots-signal-channel.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 03 August 2017 08:58
To: Jon Shallow; dots@ietf.org<= br> Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation

 

The source IP addresses and source ports used by the DDoS attacker = could change, the type of attack itself could evolve or change from one att= ack type to another.

It was discussed in the WG that this kind of information are only h= ints and not mandatory to be conveyed by the DOTS client in the mitigation = request.  https://tools.ietf.org/html/draft-ietf-dots-requirements-06 only discusses conveying the mitigation scope and not the source or type o= f the attack. However, DOTS signal channel draft allows vendor specific par= ameters and reserved key values in the range of 32768 to 65536 for vendor s= pecific parameters, these hints can be conveyed as vendor-specific parameters to the DOTS server.

 

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Wednesday, August 2, 2017 3:43 PM
To: dots@ietf.org
Subject: [Dots] Signal / Data / Alias / Filter Implementation

 

Hi There,

 

I am trying to get my mind arou= nd how to implement this and have some questions / statements.

 

Signal Channel

 

The Signal channel looks very l= ike Destination RTBH with some extras (protocols / port) as everything is t= arget-* based.  There is no concept of source-ip, source-port (to hand= le reflection attacks) etc. or dealing with fragmented packet, icmp types and rate-limiting.

 

The DOTS client may have the sm= arts to work out what are the problematic source-* etc. values (e.g. can ge= nerate smart BGP FlowSpec rules) are that will sensibly control the DDoS At= tack.

 

It is possible to use a previou= sly defined alias over the Data Channel as an alternative for a mitigation = request, but this too has source-* etc. limitations.

I have not found a way of using= a Filter defined over the Data Channel as a signal

 

Sending a signal will cause all= traffic to stop (or rate-limit possibly if it also happens to match a filt= er) to the target IP on the ports in question -  DDoS attack is now ef= fective unless the DOTS server elects (via DNS or BGP swing) to scrub that particular traffic (by controlling rates, = Source IPs / Source Ports etc.).

 

Data Channel

 

Can be used to set up aliases f= or later use.  These again however appear to be target-* based, with n= o source-*, icmp type or fragmentation capabilities.

 

Can set up a Filter, which does= include both source and destination IPs, but appears that it is acted on w= hen pushed over the data channel, and cannot be send as a signal – ap= pears to be in place more for black/white listing IPs than as a signal for mitigation, but does include rate-limitin= g

 

Questions<= /b>

 

How do we handle Source-* infor= mation in a mitigation signal request?

How do we handle specific ICMP = types  in a mitigation signal request?

How do we handle fragmentation =  in a mitigation signal request?

 

Regards

 

Jon

 

--_000_DM5PR16MB178821B08674C1C6F2E0E2F3EAB10DM5PR16MB1788namp_-- From nobody Thu Aug 3 02:46:36 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37CAD131CFE for ; Thu, 3 Aug 2017 02:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONQJE9FG3SPQ for ; Thu, 3 Aug 2017 02:46:33 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABF7B131C3A for ; Thu, 3 Aug 2017 02:46:32 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1ddCi7-0000GT-7N for ietf-supjps-dots@ietf.org; Thu, 03 Aug 2017 10:46:31 +0100 From: "Jon Shallow" To: References: <035401d30b77$fb3a1da0$f1ae58e0$@jpshallow.com> <042c01d30c30$93ad0670$bb071350$@jpshallow.com> <044b01d30c37$034e3cf0$09eab6d0$@jpshallow.com> In-Reply-To: Date: Thu, 3 Aug 2017 10:46:33 +0100 Message-ID: <047301d30c3d$63dd9240$2b98b6c0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0474_01D30C45.C5A3CF00" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQI4Xj59hXHis+FNi2tfJtTtHlSsOQLJsfx7AdboHUsCSD9NFAKHk78aAQdihiihU/018A== Archived-At: Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for 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, 03 Aug 2017 09:46:35 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0474_01D30C45.C5A3CF00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Tiru, I therefor propose to the WG that ietf-dots-signal (and its counterpart ietf-dots-data-channel) is extended to cover the source-*, icmp types and fragmentation as optional (and hint) entries to handle any future work in Telemetry etc. This simply would be extending the text in the appropriate places - agreed a laborious job, but not rocket science. New DDOS Attacks will be "created" and we need a way of being able to handle them moving forward rather than what we have at present which is a Destination RTBH with the added bonus of some extra destination fields capability from the DOTS client - very limiting in my opinion. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 03 August 2017 10:35 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation Hi Jon, This draft was presented and discussed in the WG, but since DOTS telemetry is optional the feedback we got was to pursue this work later and there was no agreement in the WG on the common attributes of an DDoS attack and the protocol to convey this information (there were proposals to use DOTS signal channel, data channel and IPFIX). -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Thursday, August 3, 2017 2:31 PM To: dots@ietf.org Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation Hi Tiru, Thanks for the document pointer - a good read and reminds me of the initial work I did with Nik Teague on getting DOTS started. However, it is still unclear to me how the "DOTS Telemetry" intelligence/hints can be conveyed over the signal and data channels using what is currently defined, unless it is all done over the data channel using ietf-dots-access-control-list. My preferred option is that ietf-dots-signal is extended to cover the more common attributes of an DDoS Attack. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 03 August 2017 09:44 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation Hi Jon, We discussed various such hints including "attack details" in https://tools.ietf.org/html/draft-doron-dots-telemetry-00. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Thursday, August 3, 2017 1:45 PM To: dots@ietf.org Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation Hi Tiru, I agree that it is highly likely that a DDoS Attack will mutate over its life time. Reflections attacks (where the source port is constant - e.g. 53 or 123 udp) do not mutate so frequently in my experience and there is no way to signal for that type of to be stopped currently. The DOTS client may continue to change its mitigation requests as the attacks evolve / mutate which is fine from my perspective. I really want to move away from Vendor Specifics for the more common definitions so that there is a standard across all vendors - even if the parameters are optional and are just hints. I am not trying to re-create FlowSpec here in the signal parameters, but there (co-incidentally) is a large overlap. FlowSpec does not support Uri, but I think that is a good thing in dots-signal-channel. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 03 August 2017 08:58 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation The source IP addresses and source ports used by the DDoS attacker could change, the type of attack itself could evolve or change from one attack type to another. It was discussed in the WG that this kind of information are only hints and not mandatory to be conveyed by the DOTS client in the mitigation request. https://tools.ietf.org/html/draft-ietf-dots-requirements-06 only discusses conveying the mitigation scope and not the source or type of the attack. However, DOTS signal channel draft allows vendor specific parameters and reserved key values in the range of 32768 to 65536 for vendor specific parameters, these hints can be conveyed as vendor-specific parameters to the DOTS server. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Wednesday, August 2, 2017 3:43 PM To: dots@ietf.org Subject: [Dots] Signal / Data / Alias / Filter Implementation Hi There, I am trying to get my mind around how to implement this and have some questions / statements. Signal Channel The Signal channel looks very like Destination RTBH with some extras (protocols / port) as everything is target-* based. There is no concept of source-ip, source-port (to handle reflection attacks) etc. or dealing with fragmented packet, icmp types and rate-limiting. The DOTS client may have the smarts to work out what are the problematic source-* etc. values (e.g. can generate smart BGP FlowSpec rules) are that will sensibly control the DDoS Attack. It is possible to use a previously defined alias over the Data Channel as an alternative for a mitigation request, but this too has source-* etc. limitations. I have not found a way of using a Filter defined over the Data Channel as a signal Sending a signal will cause all traffic to stop (or rate-limit possibly if it also happens to match a filter) to the target IP on the ports in question - DDoS attack is now effective unless the DOTS server elects (via DNS or BGP swing) to scrub that particular traffic (by controlling rates, Source IPs / Source Ports etc.). Data Channel Can be used to set up aliases for later use. These again however appear to be target-* based, with no source-*, icmp type or fragmentation capabilities. Can set up a Filter, which does include both source and destination IPs, but appears that it is acted on when pushed over the data channel, and cannot be send as a signal - appears to be in place more for black/white listing IPs than as a signal for mitigation, but does include rate-limiting Questions How do we handle Source-* information in a mitigation signal request? How do we handle specific ICMP types in a mitigation signal request? How do we handle fragmentation in a mitigation signal request? Regards Jon ------=_NextPart_000_0474_01D30C45.C5A3CF00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

I therefor propose to = the WG that ietf-dots-signal (and = its counterpart ietf-dots-data-channel) is extended to cover the = source-*, icmp types and fragmentation as optional (and hint) entries to = handle any future work in Telemetry etc.

 

This simply would be = extending the text in the appropriate places – agreed a laborious = job, but not rocket science.

 

New DDOS Attacks will be = “created” and we need a way of being able to handle them = moving forward rather than what we have at present which is a = Destination RTBH with the added bonus of some extra destination fields = capability from the DOTS client – very limiting in my = opinion.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = Konda, Tirumaleswar Reddy
Sent: 03 August 2017 = 10:35
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] Signal / Data / Alias / Filter = Implementation

 

Hi = Jon,

 

This draft was presented and = discussed in the WG, but since DOTS telemetry is optional the feedback = we got was to pursue this work later and there was no agreement in the = WG on the common attributes of an DDoS attack and the protocol to convey = this information (there were proposals to use DOTS signal channel, data = channel and IPFIX).

 

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of Jon Shallow
Sent: Thursday, August 3, 2017 = 2:31 PM
To: dots@ietf.org
Subject: Re: = [Dots] Signal / Data / Alias / Filter = Implementation

 

Hi = Tiru,

 

Thanks for the document = pointer – a good read and reminds me of the initial work I did = with Nik Teague on getting DOTS started.

 

However, it is still = unclear to me how the “DOTS Telemetry” intelligence/hints = can be conveyed over the signal and data channels using what is = currently defined, unless it is all done over the data channel using = ietf-dots-access-control-list.  My preferred option is that = ietf-dots-signal is extended to cover the more common attributes of an = DDoS Attack.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 03 August 2017 = 09:44
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] Signal / Data / Alias / Filter = Implementation

 

Hi = Jon,

 

We discussed various such hints = including “attack details” in https:= //tools.ietf.org/html/draft-doron-dots-telemetry-00.

 

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of Jon Shallow
Sent: Thursday, August 3, 2017 = 1:45 PM
To: dots@ietf.org
Subject: Re: = [Dots] Signal / Data / Alias / Filter = Implementation

 

Hi = Tiru,

 

I agree that it is = highly likely that a DDoS Attack will mutate over its life time.  = Reflections attacks (where the source port is constant – e.g. 53 = or 123 udp) do not mutate so frequently in my experience and there is no = way to signal for that type of to be stopped currently.  The DOTS = client may continue to change its mitigation requests as the attacks = evolve / mutate which is fine from my = perspective.

 

I really want to move = away from Vendor Specifics for the more common definitions so that there = is a standard across all vendors – even if the parameters are = optional and are just hints.

 

I am not trying to = re-create FlowSpec here in the signal  parameters, but there = (co-incidentally) is a large overlap.  FlowSpec does not support = Uri, but I think that is a good thing in = dots-signal-channel.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 03 August 2017 = 08:58
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] Signal / Data / Alias / Filter = Implementation

 

The = source IP addresses and source ports used by the DDoS attacker could = change, the type of attack itself could evolve or change from one attack = type to another.

It = was discussed in the WG that this kind of information are only hints and = not mandatory to be conveyed by the DOTS client in the mitigation = request.  http= s://tools.ietf.org/html/draft-ietf-dots-requirements-06 only = discusses conveying the mitigation scope and not the source or type of = the attack. However, DOTS signal channel draft allows vendor specific = parameters and reserved key values in the range of 32768 to 65536 for = vendor specific parameters, these hints can be conveyed as = vendor-specific parameters to the DOTS server.

 

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of Jon Shallow
Sent: Wednesday, August 2, = 2017 3:43 PM
To: dots@ietf.org
Subject: = [Dots] Signal / Data / Alias / Filter = Implementation

 

Hi There,

 

I am trying = to get my mind around how to implement this and have some questions / = statements.

 

Signal Channel

 

The Signal = channel looks very like Destination RTBH with some extras (protocols / = port) as everything is target-* based.  There is no concept of = source-ip, source-port (to handle reflection attacks) etc. or dealing = with fragmented packet, icmp types and rate-limiting.

 

The DOTS = client may have the smarts to work out what are the problematic source-* = etc. values (e.g. can generate smart BGP FlowSpec rules) are that will = sensibly control the DDoS Attack.

 

It is = possible to use a previously defined alias over the Data Channel as an = alternative for a mitigation request, but this too has source-* etc. = limitations.

I have not found a way = of using a Filter defined over the Data Channel as a = signal

 

Sending a signal will cause all traffic to stop (or = rate-limit possibly if it also happens to match a filter) to the target = IP on the ports in question -  DDoS attack is now effective unless = the DOTS server elects (via DNS or BGP swing) to scrub that particular = traffic (by controlling rates, Source IPs / Source Ports = etc.).

 

Data Channel

 

Can be used = to set up aliases for later use.  These again however appear to be = target-* based, with no source-*, icmp type or fragmentation = capabilities.

 

Can set up a Filter, which does include both source = and destination IPs, but appears that it is acted on when pushed over = the data channel, and cannot be send as a signal – appears to be = in place more for black/white listing IPs than as a signal for = mitigation, but does include rate-limiting

 

Questions

 

How do we = handle Source-* information in a mitigation signal = request?

How do we handle specific = ICMP types  in a mitigation signal request?

How do we handle fragmentation  in a mitigation = signal request?

 

Regards

 

Jon

 

------=_NextPart_000_0474_01D30C45.C5A3CF00-- From nobody Thu Aug 3 02:57:21 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8FE131CFE for ; Thu, 3 Aug 2017 02:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXfLoUCq8qzL for ; Thu, 3 Aug 2017 02:57:17 -0700 (PDT) Received: from guri.nttv6.jp (guri.nttv6.jp [115.69.228.140]) by ietfa.amsl.com (Postfix) with ESMTP id 90CCF131D2C for ; Thu, 3 Aug 2017 02:57:17 -0700 (PDT) Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2402:c800:ff06:6::f]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id EDE5025F691; Thu, 3 Aug 2017 18:57:14 +0900 (JST) Received: from SR2-nishizuka.local (fujiko.nttv6.jp [IPv6:2402:c800:ff06:136::141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id DB14B759041; Thu, 3 Aug 2017 18:57:14 +0900 (JST) To: "Konda, Tirumaleswar Reddy" , "Dobbins, Roland" , Jon Shallow Cc: "dots@ietf.org" References: <035401d30b77$fb3a1da0$f1ae58e0$@jpshallow.com> <628E4313-95D3-42F5-9DDB-00C7B4EBB4D6@arbor.net> <039001d30ba3$7f4290c0$7dc7b240$@jpshallow.com> <4a158137-5c92-974e-3e4d-6c46fb3e5a52@nttv6.jp> From: kaname nishizuka Message-ID: Date: Thu, 3 Aug 2017 18:57:14 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------EA2E36C19ADD4C7DAEBB7C34" Content-Language: en-US Archived-At: Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for 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, 03 Aug 2017 09:57:20 -0000 This is a multi-part message in MIME format. --------------EA2E36C19ADD4C7DAEBB7C34 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Tiru, I see draft-ietf-dots-data-channel-02 includes appropriate reference to the latest draft-ietf-netmod-acl-model. thank you, Kaname On 2017/08/03 17:06, Konda, Tirumaleswar Reddy wrote: > > draft-ietf-dots-data-channel-02 extends the base ACL model defined in draft-ietf-netmod-acl-model to support filtering based on fragments. Filtering rules based on ICMP type and code is supported in latest revision of draft-ietf-netmod-acl-model. > > I don’t see a need to update the DOTS data channel draft. > > -Tiru > > *From:*Dots [mailto:dots-bounces@ietf.org] *On Behalf Of *kaname nishizuka > *Sent:* Thursday, August 3, 2017 10:51 AM > *To:* Dobbins, Roland ; Jon Shallow > *Cc:* dots@ietf.org > *Subject:* Re: [Dots] Signal / Data / Alias / Filter Implementation > > Hi Jon, > > I'm implementing the DOTS protocol based on current specifications. > The DOTS protocol can handle source-* information in a mitigation signal request. > For example, the DOTS server can enable BGP Flowspec from 5-tuple information derived from mitigation request message from DOTS client, that is actually we are planning to add to our software. > Destination information is used to validate whether the mitigation-scope is really the property of the DOTS client's organization or not. > So, if the request is only including source-* information, how to validate the request is another problem because it can cause unintended side effect to other customers/services (but could be implementation specific) > > * How do we handle specific ICMP types in a mitigation signal request? > > Tiru wrote: > > Thanks for the review. Fixed comments 1 and 2 in my local copy. To support filtering rules based on ICMP type and code, and filtering based on fragments, the base ACL model defined in https://tools.ietf.org/html/draft-ietf-netmod-acl-model-06 needs to be extended in this draft using augmentation (see https://tools.ietf.org/html/rfc6020#section-4.2.8). > > I will extend the ACL YANG model in the next revision. > > And the latest version of draft-ietf-netmod-acl-model (-11) includes ICMP-ACL (type, code,,) > I think we should update the draft. > > * How do we handle fragmentation in a mitigation signal request? > fragmentation can be represented as port=0. Is this a sufficient representation? > > thanks, > Kaname > > > On 2017/08/03 3:27, Dobbins, Roland wrote: > > On Aug 2, 2017, at 22:25, Jon Shallow > wrote: > > In draft-ietf-dots-use-cases-07 > 3.1.6. End-customer operating a CPE network infrastructure device with > an integrated DOTS client > > 3.1.6 from idraft-ietf-dots-use-cases-07 in full: > > 3.1.6. End-customer operating a CPE network infrastructure device with > > an integrated DOTS client > > Similar to the above use-case featuring applications or services with > > built-in DDoS attack detection/classification and DOTS client > > capabilities, in this scenario, an end-customer network > > infrastructure CPE device such as a router, layer-3 switch, firewall, > > or load-balance incorporates both the functionality required to > > detect and classify incoming DDoS attacks as well as DOTS client > > functionality. > > The subsequent DOTS communications dialogue and resultant DDoS > > mitigation initiation and termination activities take place in the > > same manner as the use-cases described above. > > ----------------------------------- > > Roland Dobbins > > > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots --------------EA2E36C19ADD4C7DAEBB7C34 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Tiru,

I see draft-ietf-dots-data-channel-02 includes appropriate reference to the latest draft-ietf-netmod-acl-model.

thank you,
Kaname


On 2017/08/03 17:06, Konda, Tirumaleswar Reddy wrote:

draft-ietf-dots-data-channel-02 extends the base ACL model defined in draft-ietf-netmod-acl-model to support filtering based on fragments. Filtering rules based on ICMP type and code is supported in latest revision of draft-ietf-netmod-acl-model.

I don’t see a need to update the DOTS data channel draft.

 

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of kaname nishizuka
Sent: Thursday, August 3, 2017 10:51 AM
To: Dobbins, Roland <rdobbins@arbor.net>; Jon Shallow <supjps-ietf@jpshallow.com>
Cc: dots@ietf.org
Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation

 

Hi Jon,

I'm implementing the DOTS protocol based on current specifications.
The DOTS protocol can handle source-* information in a mitigation signal request.
For example, the DOTS server can enable BGP Flowspec from 5-tuple information derived from mitigation request message from DOTS client, that is actually we are planning to add to our software.
Destination information is used to validate whether the mitigation-scope is really the property of the DOTS client's organization or not.
So, if the request is only including source-* information, how to validate the request is another problem because it can cause unintended side effect to other customers/services (but could be implementation specific)

* How do we handle specific ICMP types  in a mitigation signal request?

Tiru wrote:
> Thanks for the review. Fixed comments 1 and 2 in my local copy. To support filtering rules based on ICMP type and code, and filtering based on fragments, the base ACL model defined in https://tools.ietf.org/html/draft-ietf-netmod-acl-model-06 needs to be extended in this draft using augmentation (see https://tools.ietf.org/html/rfc6020#section-4.2.8).
> I will extend the ACL YANG model in the next revision.

And the latest version of draft-ietf-netmod-acl-model (-11) includes ICMP-ACL (type, code,,)
I think we should update the draft.

* How do we handle fragmentation in a mitigation signal request?
fragmentation can be represented as port=0. Is this a sufficient representation?

thanks,
Kaname


On 2017/08/03 3:27, Dobbins, Roland wrote:

 

On Aug 2, 2017, at 22:25, Jon Shallow <supjps-ietf@jpshallow.com> wrote:

In draft-ietf-dots-use-cases-07
3.1.6.  End-customer operating a CPE network infrastructure device with
       an integrated DOTS client

 

3.1.6 from idraft-ietf-dots-use-cases-07 in full:

 

 

3.1.6.  End-customer operating a CPE network infrastructure device with
        an integrated DOTS client
 
   Similar to the above use-case featuring applications or services with
   built-in DDoS attack detection/classification and DOTS client
   capabilities, in this scenario, an end-customer network
   infrastructure CPE device such as a router, layer-3 switch, firewall,
   or load-balance incorporates both the functionality required to
   detect and classify incoming DDoS attacks as well as DOTS client
   functionality.
 
   The subsequent DOTS communications dialogue and resultant DDoS
   mitigation initiation and termination activities take place in the
   same manner as the use-cases described above.
----------------------------------- 
Roland Dobbins <rdobbins@arbor.net>




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

 



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

--------------EA2E36C19ADD4C7DAEBB7C34-- From nobody Thu Aug 3 03:17:54 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F029313234A for ; Thu, 3 Aug 2017 03:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4t1T8sjqM0X for ; Thu, 3 Aug 2017 03:17:51 -0700 (PDT) Received: from guri.nttv6.jp (guri.nttv6.jp [115.69.228.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2D163132342 for ; Thu, 3 Aug 2017 03:17:51 -0700 (PDT) Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2402:c800:ff06:6::f]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id 9FD7725F691; Thu, 3 Aug 2017 19:17:50 +0900 (JST) Received: from SR2-nishizuka.local (fujiko.nttv6.jp [IPv6:2402:c800:ff06:136::141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 8A8EC759041; Thu, 3 Aug 2017 19:17:49 +0900 (JST) To: Jon Shallow , dots@ietf.org References: <035401d30b77$fb3a1da0$f1ae58e0$@jpshallow.com> <628E4313-95D3-42F5-9DDB-00C7B4EBB4D6@arbor.net> <039001d30ba3$7f4290c0$7dc7b240$@jpshallow.com> <4a158137-5c92-974e-3e4d-6c46fb3e5a52@nttv6.jp> <040101d30c2e$14440f70$3ccc2e50$@jpshallow.com> From: kaname nishizuka Message-ID: <80a371a0-9968-d259-7fca-0765d10a1a10@nttv6.jp> Date: Thu, 3 Aug 2017 19:17:48 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <040101d30c2e$14440f70$3ccc2e50$@jpshallow.com> Content-Type: multipart/alternative; boundary="------------B5EE2EAA512BBF9009C407C2" Content-Language: en-US Archived-At: Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for 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, 03 Aug 2017 10:17:54 -0000 This is a multi-part message in MIME format. --------------B5EE2EAA512BBF9009C407C2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Jon, On 2017/08/03 16:56, Jon Shallow wrote: > > Hi Kaname, > > So as I read this, you are either extending the ietf-dot-signal definition to include source-* (and icmp, fragmentation and possibly rate-limiting) information or you are using Filters over the data channel (which is what Tiru is referring to). If it is an extension to ietf-dot-signal, then this needs to be formalised for interoperability between different suppliers. > The latter is my intention. I'll check whether the alias mechanism which couples the data-channel and signal-channel works well. > Similarly, ietf-dots-data-channel-identifier needs to be extended – but I do think the naming (e.g. target-ip instead of just ip) needs to be consistent between ietf-dot-signal and ietf-dots-data-channel-identifier. > +1. a consistency of naming is important for readers. thanks, Kaname > “5.3.1” of draft-ietf-dots-signal-channel would also need to reflect the ietf-dot-signal change. “6.” and “10.1.2” of draft-ietf-dots-signal-channel would also need CBOR to be updated with source-* etc. definitions. > > I am of the firm opinion that destination-ip is REQUIRED and MUST be within the mitigation scope of the DOTS Client to prevent taking out someone else’s IP. This is true for ietf-dot-signal, ietf-dots-data-channel-identifier and ietf-dots-access-control-list. > > I do not think fragmentation represented as port=0 is sufficient (and is not necessarily intuitive – it could be read as just take out the subsequent packets of a fragmented sequence if the layer 4 header is not there and hence no port). I think it should have its own ietf-dot-signal definition. > > It is unclear to me the usage of alias in the ietf-dot-signal – is it the DOTS client uses just the alias when requesting mitigation, or if extra parameters are provided (e.g. alias plus target-port-range) are the extra parameters a replacement or in addition to what is in the ietf-dots-data-channel-identifier or are the extra parameters ignored altogether? > > Regards > > Jon > > *From:*Dots [mailto: dots-bounces@ietf.org] *On Behalf Of *kaname nishizuka > *Sent:* 03 August 2017 06:21 > *To:* Dobbins, Roland; Jon Shallow > *Cc:* dots@ietf.org > *Subject:* Re: [Dots] Signal / Data / Alias / Filter Implementation > > Hi Jon, > > I'm implementing the DOTS protocol based on current specifications. > The DOTS protocol can handle source-* information in a mitigation signal request. > For example, the DOTS server can enable BGP Flowspec from 5-tuple information derived from mitigation request message from DOTS client, that is actually we are planning to add to our software. > Destination information is used to validate whether the mitigation-scope is really the property of the DOTS client's organization or not. > So, if the request is only including source-* information, how to validate the request is another problem because it can cause unintended side effect to other customers/services (but could be implementation specific) > > * How do we handle specific ICMP types in a mitigation signal request? > > Tiru wrote: > > Thanks for the review. Fixed comments 1 and 2 in my local copy. To support filtering rules based on ICMP type and code, and filtering based on fragments, the base ACL model defined in https://tools.ietf.org/html/draft-ietf-netmod-acl-model-06 needs to be extended in this draft using augmentation (see https://tools.ietf.org/html/rfc6020#section-4.2.8). > > I will extend the ACL YANG model in the next revision. > > And the latest version of draft-ietf-netmod-acl-model (-11) includes ICMP-ACL (type, code,,) > I think we should update the draft. > > * How do we handle fragmentation in a mitigation signal request? > fragmentation can be represented as port=0. Is this a sufficient representation? > > thanks, > Kaname > > > On 2017/08/03 3:27, Dobbins, Roland wrote: > > On Aug 2, 2017, at 22:25, Jon Shallow > wrote: > > In draft-ietf-dots-use-cases-07 > 3.1.6. End-customer operating a CPE network infrastructure device with > an integrated DOTS client > > 3.1.6 from idraft-ietf-dots-use-cases-07 in full: > > 3.1.6. End-customer operating a CPE network infrastructure device with > > an integrated DOTS client > > Similar to the above use-case featuring applications or services with > > built-in DDoS attack detection/classification and DOTS client > > capabilities, in this scenario, an end-customer network > > infrastructure CPE device such as a router, layer-3 switch, firewall, > > or load-balance incorporates both the functionality required to > > detect and classify incoming DDoS attacks as well as DOTS client > > functionality. > > The subsequent DOTS communications dialogue and resultant DDoS > > mitigation initiation and termination activities take place in the > > same manner as the use-cases described above. > > ----------------------------------- > > Roland Dobbins > > > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots --------------B5EE2EAA512BBF9009C407C2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Jon,


On 2017/08/03 16:56, Jon Shallow wrote:

Hi Kaname,

 

So as I read this, you are either extending the ietf-dot-signal definition to include source-* (and icmp, fragmentation and possibly rate-limiting) information or you are using Filters over the data channel (which is what Tiru is referring to).  If it is an extension to ietf-dot-signal, then this needs to be formalised for interoperability between different suppliers. 

The latter is my intention.  I'll check whether the alias mechanism which couples the data-channel and signal-channel works well.

Similarly, ietf-dots-data-channel-identifier needs to be extended – but I do think the naming (e.g. target-ip instead of just ip) needs to be consistent between ietf-dot-signal and ietf-dots-data-channel-identifier. 

+1.
a consistency of naming is important for readers.

thanks,
Kaname

“5.3.1” of draft-ietf-dots-signal-channel would also need to reflect the ietf-dot-signal change. “6.” and “10.1.2” of draft-ietf-dots-signal-channel would also need CBOR to be updated with source-* etc. definitions.

 

I am of the firm opinion that destination-ip is REQUIRED and MUST be within the mitigation scope of the DOTS Client to prevent taking out someone else’s IP.  This is true for ietf-dot-signal, ietf-dots-data-channel-identifier and ietf-dots-access-control-list.

 

I do not think fragmentation represented as port=0 is sufficient (and is not necessarily intuitive – it could be read as just take out the subsequent packets of a fragmented sequence if the layer 4 header is not there and hence no port). I think it should have its own ietf-dot-signal definition.

 

It is unclear to me the usage of alias in the ietf-dot-signal – is it the DOTS client uses just  the alias when requesting mitigation, or if extra parameters are provided (e.g. alias plus target-port-range) are the extra parameters a replacement or in addition to what is in the ietf-dots-data-channel-identifier or are the extra parameters ignored altogether?

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of kaname nishizuka
Sent: 03 August 2017 06:21
To: Dobbins, Roland; Jon Shallow
Cc: dots@ietf.org
Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation

 

Hi Jon,

I'm implementing the DOTS protocol based on current specifications.
The DOTS protocol can handle source-* information in a mitigation signal request.
For example, the DOTS server can enable BGP Flowspec from 5-tuple information derived from mitigation request message from DOTS client, that is actually we are planning to add to our software.
Destination information is used to validate whether the mitigation-scope is really the property of the DOTS client's organization or not.
So, if the request is only including source-* information, how to validate the request is another problem because it can cause unintended side effect to other customers/services (but could be implementation specific)

* How do we handle specific ICMP types  in a mitigation signal request?

Tiru wrote:
> Thanks for the review. Fixed comments 1 and 2 in my local copy. To support filtering rules based on ICMP type and code, and filtering based on fragments, the base ACL model defined in https://tools.ietf.org/html/draft-ietf-netmod-acl-model-06 needs to be extended in this draft using augmentation (see https://tools.ietf.org/html/rfc6020#section-4.2.8).
> I will extend the ACL YANG model in the next revision.

And the latest version of draft-ietf-netmod-acl-model (-11) includes ICMP-ACL (type, code,,)
I think we should update the draft.

* How do we handle fragmentation in a mitigation signal request?
fragmentation can be represented as port=0. Is this a sufficient representation?

thanks,
Kaname


On 2017/08/03 3:27, Dobbins, Roland wrote:

 

On Aug 2, 2017, at 22:25, Jon Shallow <supjps-ietf@jpshallow.com> wrote:

In draft-ietf-dots-use-cases-07
3.1.6.  End-customer operating a CPE network infrastructure device with
       an integrated DOTS client

 

3.1.6 from idraft-ietf-dots-use-cases-07 in full:

 

 

3.1.6.  End-customer operating a CPE network infrastructure device with
        an integrated DOTS client
 
   Similar to the above use-case featuring applications or services with
   built-in DDoS attack detection/classification and DOTS client
   capabilities, in this scenario, an end-customer network
   infrastructure CPE device such as a router, layer-3 switch, firewall,
   or load-balance incorporates both the functionality required to
   detect and classify incoming DDoS attacks as well as DOTS client
   functionality.
 
   The subsequent DOTS communications dialogue and resultant DDoS
   mitigation initiation and termination activities take place in the
   same manner as the use-cases described above.
----------------------------------- 
Roland Dobbins <rdobbins@arbor.net>




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

 



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

--------------B5EE2EAA512BBF9009C407C2-- From nobody Thu Aug 3 03:46:06 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6DD126CC4 for ; Thu, 3 Aug 2017 03:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5EnhROMyBFJ for ; Thu, 3 Aug 2017 03:46:03 -0700 (PDT) Received: from guri.nttv6.jp (guri.nttv6.jp [115.69.228.140]) by ietfa.amsl.com (Postfix) with ESMTP id 1AACA131D27 for ; Thu, 3 Aug 2017 03:46:02 -0700 (PDT) Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2402:c800:ff06:6::f]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id 0140C25F68D; Thu, 3 Aug 2017 19:46:01 +0900 (JST) Received: from SR2-nishizuka.local (fujiko.nttv6.jp [IPv6:2402:c800:ff06:136::141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 5A4A775900C; Thu, 3 Aug 2017 19:46:00 +0900 (JST) To: Roland Dobbins , Jon Shallow Cc: dots@ietf.org References: <035401d30b77$fb3a1da0$f1ae58e0$@jpshallow.com> <628E4313-95D3-42F5-9DDB-00C7B4EBB4D6@arbor.net> <039001d30ba3$7f4290c0$7dc7b240$@jpshallow.com> <4a158137-5c92-974e-3e4d-6c46fb3e5a52@nttv6.jp> <040101d30c2e$14440f70$3ccc2e50$@jpshallow.com> <78660E60-0A94-4164-A8C0-5485816DE059@arbor.net> From: kaname nishizuka Message-ID: <8115e45d-cebc-89a4-cd70-fdd7368a719e@nttv6.jp> Date: Thu, 3 Aug 2017 19:45:59 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <78660E60-0A94-4164-A8C0-5485816DE059@arbor.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for 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, 03 Aug 2017 10:46:05 -0000 > The intent of DOTS is NOT to re-create flowspec. Yes, I agree. > Getting into layer-4 traffic descriptors, including things like non-initial fragments, is re-creating flowspec and IPFIX. We don't intend to do that. From ISP operator's perspective, DDoS mitigation includes RTBH, ACL, flowspec, dedicated box and cloud-type of service etc,.. As for flowspec, opening flowspec interface to other organizations is equal to passing responsibilities to other people, but DOTS is not. DOTS should be able to cover the same problem space of flowspec in a safer manner, so giving layer-4 traffic information in data-channel is realistic for me. thanks, Kaname On 2017/08/03 17:04, Roland Dobbins wrote: > On 3 Aug 2017, at 14:56, Jon Shallow wrote: > >> I am of the firm opinion that destination-ip is REQUIRED > > The intent of DOTS is NOT to re-create flowspec. > > It's to signal the need for DDoS mitigation. > > 'Taking out someone else's IP' is not a concern of DOTS itself; this has to do with the provisioning of the DOTS clients, servers, and associated detection/classification/traceback/mitigation systems. > > Getting into layer-4 traffic descriptors, including things like non-initial fragments, is re-creating flowspec and IPFIX. We don't intend to do that. > > ----------------------------------- > Roland Dobbins > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Aug 3 05:58:17 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD9B131C92 for ; Thu, 3 Aug 2017 05:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aC2qS1NzLIop for ; Thu, 3 Aug 2017 05:58:13 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0090.outbound.protection.outlook.com [104.47.34.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6FC612702E for ; Thu, 3 Aug 2017 05:58:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=DEGRyNvG8mFDozhAzB6KpAULYgA1AIMSgzuVprlJ78E=; b=C09hptsufBvuyP9AA+YInUEvk2zl7xpALl4vy54g0gZr8gP3fp57aFgDgDMdlVlVDQWpMA/qxz12rOoeQZdmZYHR95+SYHaR0F5ucuP6OTrJWgw6MV5VPddt83cqoh7TparYPicDQbcsPpe26eB6edWhxpw6Jgn81K2kgP6eAe8= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=rdobbins@arbor.net; Received: from [172.19.254.107] (49.228.111.8) by DM2PR0101MB1037.prod.exchangelabs.com (2a01:111:e400:3c19::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.22; Thu, 3 Aug 2017 12:58:10 +0000 From: "Roland Dobbins" To: "Jon Shallow" Cc: dots@ietf.org Date: Thu, 03 Aug 2017 19:57:31 +0700 Message-ID: In-Reply-To: <047301d30c3d$63dd9240$2b98b6c0$@jpshallow.com> References: <035401d30b77$fb3a1da0$f1ae58e0$@jpshallow.com> <042c01d30c30$93ad0670$bb071350$@jpshallow.com> <044b01d30c37$034e3cf0$09eab6d0$@jpshallow.com> <047301d30c3d$63dd9240$2b98b6c0$@jpshallow.com> MIME-Version: 1.0 X-Mailer: MailMate (1.9.6r5347) Content-Type: text/plain X-Originating-IP: [49.228.111.8] X-ClientProxiedBy: KL1PR0601CA0009.apcprd06.prod.outlook.com (2603:1096:802:1::19) To DM2PR0101MB1037.prod.exchangelabs.com (2a01:111:e400:3c19::26) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 4ed09171-e365-4a32-1d2e-08d4da6f4c2f X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR0101MB1037; X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1037; 3:F7Gh5u2xsZsz8S+VB4dMMcMqsSg0oJpF+LsKB7SljWgbsqKOahubkljM0ecFN5LmHcz5KM5xaXgdKaPXdTtTeRCoq1tFttBzpDw8G7H06qwJFmSUgiHimW8T8LGrjSypp3VYaa3jbTltcg8n+rjm/zJBVP0XwjchCVxnHXnM5lmssT8ePs553Ap7NKNlz/6WkLWWIeMvyB4lQ13K7G9aBWse6m8KEoTm2i40P0i/xmsfe3hMlxwGg00MnRskLzXF; 25:zrX3L8pa6J7g9swWZtWlgTuMcreZQYvMZSh3gfSsRkSgzuNXl4cG9gHvge5vQ7TJ1RrWnFwnXjeFyFsllmRzBd77pULHLz4cjl1zl+Np1Sv+U3ajC73Oe/Rzwl8LR0A/t9IFB+abLoR5jAGFXENEXBVUN8JgkZzqafSLErKNsRwy6dXmVN/z6C+t0+bLEYM7hNAJHavBgnmOsgbXeZ4I8bt7Ysk/Re7+vTH2gADaVaBhFvbL/XgS1IhRMMEstbjzPLjXVwcgOqPl8iVTz7iTurAQb/YVZwzreG1/nB7WQwu6xD2Kgg81GkEVD8B+v9WqlEqBSZGWCU9oWKrF/wh61w==; 31:8N5dxDzK/YFWFIr+cmQ7mLeiGy5DZKvaYdgrLPCivP8J2nwdYvORzDb0s3wE8doTn/dnc3aUJcEMaixOZGUVbmvBRPiuuqatIkJ6oAzwxoG7iM6IpfMeBBcOKsEHJ5tVzXQrSfMerT0JDfYKbANedaxdkrWmRidLcZEn0rb2FwbC75fwo3dHDCYimTuEfTY11zGcMoYULYQ6hPajk5bc5IRDSyiyea1oVVVopPGAIB8= X-MS-TrafficTypeDiagnostic: DM2PR0101MB1037: X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1037; 20:oUwKTCfGl8SbP7uGWDO4/UMrctOxIuNDiO8prYrFwT+ZUfd9hcdVW+04ix3O1/aQCop0rYG4qxJnM7tM4H2fqVTcuKaLxyG1cSWlqGVeD/sZ2JLUwTHzJaxTVJvLjrpawbjGMTCRBK8gpeXNDNfD45SNGG0EkmvMUgf5IUFtJHfYL6os9fCQDISZcbAHZXNG2ZfIHj4LM6I00RGnAL96EvJfDdqMvqu4JC6b5S4DjpCuTNVHUiZuGH7ZfIGosv/9rjeDsU+MbCqpqKlfZqUnuVyPfonjZUhai1A1kPt05z5rSDk4n273/91cHQeS9ouqR0p+mgxUXwtqhviJpWKfEifoWle/jH++BhkZvY9ygrgd5KQy9a7jlefcCqW0IYNL5iWQgOr34/sDZPPpC9ki6zGkxYFl/lg3b+GHkRjXx5/28MyU6kv1iiZbqsnzH/Y8vxC60CNIdY9G6Arg3V7HBk0MreettxaoE9UK0QQBW6lcehjqQWjrTelCY47CrBWG; 4:Tdupwhp3oE27dOGjAvmCkz3BWf24cWr+Dgem2g12D7NlFUrEkrUPq5ZTv8+JxXkQaROXsHmpgV/szTLiHyoIvJD1zhFLWAOf/CITebxESDNUTOYqcILeYV6GcMOE7aMePwk3ev4FkzvvQnbVcOzjSQ3J0keI8uGpMNI1roi3reyYSqaWN4qjwf8p3m8GrRzc1zM6Wyic6GlDIpO3z9i0pzhf16RXvvU5qyzeA4/ShLFq9q6T2INW8GTLwv1rpQgu X-Exchange-Antispam-Report-Test: UriScan:; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(20161123562025)(20161123558100)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0101MB1037; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0101MB1037; X-Forefront-PRVS: 03883BD916 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(7370300001)(979002)(6049001)(6009001)(39840400002)(39410400002)(39400400002)(39450400003)(189002)(199003)(24454002)(189998001)(48376002)(305945005)(106356001)(105586002)(42186005)(7736002)(86362001)(5003940100001)(97736004)(81156014)(3846002)(6666003)(6916009)(83716003)(8676002)(2950100002)(6116002)(2906002)(50466002)(93886004)(81166006)(53546010)(77096006)(6486002)(7350300001)(25786009)(53936002)(36756003)(4326008)(50226002)(101416001)(478600001)(82746002)(50986999)(76176999)(38730400002)(68736007)(6246003)(66066001)(558084003)(47776003)(229853002)(110136004)(33656002)(5660300001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1037; H:[172.19.254.107]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: arbor.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR0101MB1037; 23:4fa7WwnXQQ4SBbbdq4OxuO5ERKDU0aveNm+a5LF?= =?us-ascii?Q?hSaDe+eqQI/0HctsXiJuHKtXo6F6JgVwjAqMkXgf5Ce9ABE3tcv34ToyXBoq?= =?us-ascii?Q?Nk7eMfFHy2+mKxu5ETNm68EczMow5oBvT6arTN24s4o3jV+FPE90VNcBdES7?= =?us-ascii?Q?9oPUrTZg+js88SYTay3KCsDpm1Rz3ejAbUrMwxQer1gYnskta9auWNAWKA/i?= =?us-ascii?Q?FVzgXDOHXoVhMg67z00c+PdkvIAO7UUM+urvDP2+Y7QMf5e57e7YM4bzXYqY?= =?us-ascii?Q?WfXaS0Teb5WEs9Jqx8FIZYgbSZYdsoGHz7IyeW4FnYjqxM7MgOF8bNxypK0D?= =?us-ascii?Q?mo5PHa0yONi/vPNa7M5xGV/LoBGjpeNveiExgXaunFg6FOgKfJRR5KRxxtCI?= =?us-ascii?Q?pXZyor6TggwUHXGR93KOsFheHfJYIflg3PGRslzNwWTzpjSELYvm3G4rr5iK?= =?us-ascii?Q?41mrWcCoOqLQdyf7NylEzWyJ6ME7UaVyqQaWSUjJtdX07mcPUX+h/Wwza6gR?= =?us-ascii?Q?oI5qaVnxnzOPe1cG4UyMtfvBxlfvWI1Dwm8CLtcSlxHnOodBWrZTGHRyNNVD?= =?us-ascii?Q?ykppEkIb9TmlLQir1W7riH2Biw4A7tvP+XbOTYmRMDqXgqvPiSumR3OE/12k?= =?us-ascii?Q?UFSgv5F7JeUU+elcsvEOg5DwaPNCVD7968Z58nC+nR3KazlLUoVkJPaD8pha?= =?us-ascii?Q?RA4RjZzmLh/3TbVwOnHy5VPhYMznSd976fI1ZZ4T1tqW8AOPhW4rEhnRKssK?= =?us-ascii?Q?yJv68n8xb4EhAczPGgM4DJyaLiEeSCpH/2RUMLCSBEWE7oSICqwm8IE/v9So?= =?us-ascii?Q?oXgta5KOIvHx+pafr85azDjg8PzEK3o2X2y7fX3pEzu+O2SojufyL32AaFZx?= =?us-ascii?Q?I7tjnWG+g74r8cwgirl9MyHZBq4uhHwmMYli1dSk5xGB06nsoNQQqu2T6P/Q?= =?us-ascii?Q?wlEw8PpTT0eG9oMvegBBIUybhXWGGpKny8bPTQ3s6R+/l3iDipB7OLA3VkSB?= =?us-ascii?Q?+P0IP3PrT7KrewmzWY1aMbXq3x4u4EWD4SEnX/Lejaq2FLWq6ZZulCrIDITl?= =?us-ascii?Q?BD17mVFSN9ETnEORYgA+FXZrcKKZxNF0YPgshTA0h/BLqIhWwOZYQ+HqlZwh?= =?us-ascii?Q?45Ht4C8cdflssdLooAi0RSzMaZEcC8m45gS3vgSeZKyeDQTUH5S5JVXH83J3?= =?us-ascii?Q?RjKO+93owsM3YjAPELjbu4Jd1gnX4jG7KR37m9HcMSS+pmqitaQNK9HDvVbX?= =?us-ascii?Q?Akk6HG6HcmCoVw5r7KpYK4gRU9bNJ/oMbvwzq3quYdlWUqbwGB90hbpQNtq+?= =?us-ascii?Q?rnTWRRunB6Q3V1CZtaxIjDWB+oVry7UJE3ePR9hjx0c8tFoJ8OFOhi7/kAaU?= =?us-ascii?Q?Bydq8GtDsx0xJCX5XUszBjYW9Z5iJRSeyBez0MrieylFfLjSYq3xBzhuoea/?= =?us-ascii?Q?Dcqe1r4YVsEJULIEyeRSvNSJri0rUiyFoeSj0wByPFwUO6NIRKVUXkmGshdR?= =?us-ascii?Q?NSbW6uoNMSFp8dg=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1037; 6:BBx8BuSL9UquJd1SJ8/0Typwp4eUleoIvL3T24V6GDtYTuV1Wy9b6F/SrcgIx60zYT6U3rRgFXNpRBbrBCIAh9HrZsk2TP600hY6fctRfICBFMDAlXHGcN5DRR2TE8JaTohOawYdtZ9NAvK5Lg+878LJ804y4PJAqjT1iLNCvDJg5swQcyrtzLej9sOVuk9MfCT06jeO3qh6yEkpFWL+LXd78U5muhQxhuNFxuQ+gl2rNdqN1AGfG87YrinSKDDEFwxGX+5pJjnYNFiYW41CJQYlvOViVIuGDCtTLRROWL5vnlf6sT0yFMlbfUyIODIvRH4gCVVovJj/zm7gpbSRgg==; 5:ptFo60UVkWGWd8x9hNEYf0SF0GmWoUCK7mrhTTJjLeTx49zdGtxstPm+v39j/h2Q3x8a0PpzZQtBLDYViANY4kZ6q081E4160KN4zfQkOO0G+vFUaukOO6bkn+CAMwMxOYttu+kzRivgzQvsMa/AGQ==; 24:5e7xS+hL92TYhbB9IQoP+J1luT2toOdHsfsQMx8JTvMyberOiJipWjg07qCcfZPTAdll7pwDHhPByTeY6ruS3CMuIY3WYtOSWp8yd8JpJ7s=; 7:h9kQYEIx8WNEnt+5uhE7JKLLedRo3yHRm6s8eVJSGJ8GqyG4Rd33ORmCuG7lTB/MXFo6fytnxfmqe74hdaP18nZc/v82Ih0Eg3UiB6EmMIPcCzKXebgiG1mmBw7zEZoZJsZWVi9F1+a0tufZl8Cm6rzkjvUXz1rq4Z89aN9LITIeqb2kp36X6Y4HyAOjsnHURvjbf3iRPHjWV7BgKrgUCxB6lRupPKtddaiNa7fM7IA= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Aug 2017 12:58:10.9369 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1037 Archived-At: Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for 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, 03 Aug 2017 12:58:15 -0000 On 3 Aug 2017, at 16:46, Jon Shallow wrote: > to cover the source-*, icmp types and > fragmentation as optional (and hint) entries to handle any future work in > Telemetry etc. It already should do so. ----------------------------------- Roland Dobbins From nobody Thu Aug 3 06:05:35 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 222FD131FCA for ; Thu, 3 Aug 2017 06:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fw9goRF2gV9C for ; Thu, 3 Aug 2017 06:05:33 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11B34131EF8 for ; Thu, 3 Aug 2017 06:05:33 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1ddFoh-0000OR-KX for ietf-supjps-dots@ietf.org; Thu, 03 Aug 2017 14:05:31 +0100 From: "Jon Shallow" To: References: <035401d30b77$fb3a1da0$f1ae58e0$@jpshallow.com> <042c01d30c30$93ad0670$bb071350$@jpshallow.com> <044b01d30c37$034e3cf0$09eab6d0$@jpshallow.com> <047301d30c3d$63dd9240$2b98b6c0$@jpshallow.com> In-Reply-To: Date: Thu, 3 Aug 2017 14:05:33 +0100 Message-ID: <04ce01d30c59$30d42af0$927c80d0$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQI4Xj59hXHis+FNi2tfJtTtHlSsOQLJsfx7AdboHUsCSD9NFAKHk78aAQdihigBh1dFEwGUUmLFoTtZ5/A= Archived-At: Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for 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, 03 Aug 2017 13:05:34 -0000 >From Roland Dobbins Sent: 03 August 2017 13:58 > On 3 Aug 2017, at 16:46, Jon Shallow wrote: > > to cover the source-*, icmp types and fragmentation as optional > > (and > > hint) entries to handle any future work in Telemetry etc. > It already should do so. True if using ietf-access-control-list over data channel Not true if using ietf-dots-signal over signal channel. This extra functionality is not available over the signal channel. Regards Jon From nobody Thu Aug 3 06:22:12 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34921131FC7 for ; Thu, 3 Aug 2017 06:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 563QD96maYKD for ; Thu, 3 Aug 2017 06:22:08 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 01B28131687 for ; Thu, 3 Aug 2017 06:22:07 -0700 (PDT) Received: from MIVEXAPP1N03.corpzone.internalzone.com (unknown [10.48.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp id 0fc3_6093_1e4fba29_2bff_438f_a50a_14b2ae7ab3de; Thu, 03 Aug 2017 08:21:57 -0500 Received: from MIVEXUSR1N07.corpzone.internalzone.com (10.48.48.87) by MIVEXAPP1N03.corpzone.internalzone.com (10.48.48.90) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 3 Aug 2017 09:21:55 -0400 Received: from MIVO365EDGE4.corpzone.internalzone.com (10.48.176.87) by MIVEXUSR1N07.corpzone.internalzone.com (10.48.48.87) with Microsoft SMTP Server (TLS) id 15.0.1263.5 via Frontend Transport; Thu, 3 Aug 2017 09:21:55 -0400 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (10.48.176.241) by edge.mcafee.com (10.48.176.87) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 3 Aug 2017 09:21:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.onmicrosoft.com; s=selector1-mcafee-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=mZiLASLUjhju2vNnxVhU1w74+PshzYk4dNEqpLDj7Ns=; b=qSJ7DGKyelmkkNZupZlXBZjnPxDQZa7s6vgpjWEZoDXnZOKpbFvNEAJsYymBfEXT1EydusR1putVEOmuXgkqV1Iwap3Jn4GAgHskQ0mPwHhQp450vUKz7gl1SS9kHo4P7RsI8gpVx5LXi0tqk4Tg6b2TABF2/UcplyECJBnRUfI= Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1787.namprd16.prod.outlook.com (10.172.44.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.22; Thu, 3 Aug 2017 13:21:53 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.01.1304.023; Thu, 3 Aug 2017 13:21:53 +0000 From: "Konda, Tirumaleswar Reddy" To: kaname nishizuka , Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Signal / Data / Alias / Filter Implementation Thread-Index: AdMLd/i8iwFwzTfWQ/S7HayGj5igcAABJg8AAAm7eQAABmLPgAAW0FyAAAVyJ4AABOtMAAAFoj7A Date: Thu, 3 Aug 2017 13:21:52 +0000 Message-ID: References: <035401d30b77$fb3a1da0$f1ae58e0$@jpshallow.com> <628E4313-95D3-42F5-9DDB-00C7B4EBB4D6@arbor.net> <039001d30ba3$7f4290c0$7dc7b240$@jpshallow.com> <4a158137-5c92-974e-3e4d-6c46fb3e5a52@nttv6.jp> <040101d30c2e$14440f70$3ccc2e50$@jpshallow.com> <80a371a0-9968-d259-7fca-0765d10a1a10@nttv6.jp> In-Reply-To: <80a371a0-9968-d259-7fca-0765d10a1a10@nttv6.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [161.69.192.123] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1787; 7:iZdKjF+kEuAD8I20qJcLh/SOKEjhqvqX2t6oA5ppwv7Iv8XQtEUx8zMu3NDbYJiHAWQ9fNwcMPZyPSlb/o3+IoOq0k+ZIwz6P5jaVksyAtgjSucdqKner7Hevm4BvEPbMk0yKu+pY3qDsrRwXcrar5hltbttiePGm+WmNsnxsoJipoxLJMLxTDYQoWmGZ971cSXYvnf5x5hpv9Yd9V5jNERaOOI5I8NjTMcIvRyAY3u93AbDeKK5lmwFqdvfz6qiR32lNX5B3p+/RQHSFJ5whjOfKCRK17QcnjHBLoK3ogUzxaHdowwwIUXsIG8kWy9F3GAEOlAtWhkQ3cU3dZ8Nq0egOCiLRD9vL0eBhlS2Thupors0wUbY31MGKgfs2GH/btc328VUKglWYj/cmPbc/SymJQmWnDQmfg44MEmUSxcoe0nDi9qJPpRYJY8PgpqcrHQU0yfzO1DeUu3J/NQGhYvZshOCDCpsFnTO4A3Flleo4PRrT+i5ls6vSifBpo8gFBo8HhII+UIvDOtURoZGoBYAKEqPD14f0HK3MJ+USo/d2j33CxgtFIckAfyMzdoJV2hsUrSm9c6Buv4VNqcPnT7I+ATzcrjHLDqs8pdUXiotMcVaUyjXDde85GPZ1tb71Omp9b/IsTVdyT2AqvrqxEiXi+N39wlKW0C73MsjEIFgHa6qIjWqTFuOO317wQayRYIiHvfYxB3jzIw3O8nNviPXpjMKvuvugL7TZaNXXrMItFIlGTeyxI+XZIn6VkpjC4Z+1KkZRos5ntxC3tTPP5zpz1utGzWS+bCKTnSoJ3Y= x-ms-office365-filtering-correlation-id: e586d47e-3085-428b-0137-08d4da729b40 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM5PR16MB1787; x-ms-traffictypediagnostic: DM5PR16MB1787: x-exchange-antispam-report-test: UriScan:(158342451672863)(278428928389397)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123564025)(20161123558100)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1787; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1787; x-forefront-prvs: 03883BD916 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39850400002)(39450400003)(39840400002)(39410400002)(39400400002)(51914003)(189002)(199003)(32952001)(377454003)(24454002)(5660300001)(102836003)(3846002)(790700001)(86362001)(81156014)(8676002)(81166006)(33656002)(6506006)(966005)(7696004)(14454004)(105586002)(6436002)(478600001)(106356001)(6116002)(189998001)(2950100002)(77096006)(2501003)(2906002)(8936002)(7736002)(66066001)(72206003)(93886004)(25786009)(50986999)(54356999)(9686003)(76176999)(80792005)(99286003)(53936002)(606006)(55016002)(229853002)(6306002)(54896002)(53546010)(3660700001)(236005)(74316002)(101416001)(38730400002)(3280700002)(97736004)(6246003)(2900100001)(68736007)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1787; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:3; A:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1788F25710A5DDC11C3A733AEAB10DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2017 13:21:53.0622 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1787 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6086> : inlines <6005> : streams <1756990> : uri <2475541> Archived-At: Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for 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, 03 Aug 2017 13:22:11 -0000 --_000_DM5PR16MB1788F25710A5DDC11C3A733AEAB10DM5PR16MB1788namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VXBkYXRlZCBwYXJhbWV0ZXIgbmFtZXMgdG8gYmUgY29uc2lzdGVudCBiL3cgaWV0Zi1kb3RzLXNp Z25hbCBhbmQgaWV0Zi1kb3RzLWRhdGEtY2hhbm5lbCBpbiBteSBsb2NhbCBjb3B5Lg0KDQpBZGRl ZCB0aGUgZm9sbG93aW5nIGxpbmUgdG8gY2xhcmlmeSB0aGUgdXNlIG9mIGFsaWFzOg0KSWYgdGhl IG1pdGlnYXRpb24gcmVxdWVzdCBjb250YWlucyBib3RoIGFsaWFzIGFuZCBvdGhlciBwYXJhbWV0 ZXJzIGlkZW50aWZ5aW5nIHRoZSB0YXJnZXQgcmVzb3VyY2UgKHN1Y2ggYXMsIHRhcmdldC1pcCwg dGFyZ2V0LXByZWZpeCwgZnFkbiwgdXJpKSB0aGVuIHRoZSBET1RTIHNlcnZlciBhcHBlbmRzIHRo ZSBwYXJhbWV0ZXIgdmFsdWVzIGluIGFsaWFzIHdpdGggdGhlIGNvcnJlc3BvbmRpbmcgcGFyYW1l dGVyIHZhbHVlcyBpbiB0YXJnZXQtaXAsIHRhcmdldC1wcmVmaXgsIGZxZG4sIHVyaSBwYXJhbWV0 ZXJzLg0KDQotVGlydQ0KRnJvbTogRG90cyBbbWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIGthbmFtZSBuaXNoaXp1a2ENClNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMywg MjAxNyAzOjQ4IFBNDQpUbzogSm9uIFNoYWxsb3cgPHN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb20+ OyBkb3RzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0RvdHNdIFNpZ25hbCAvIERhdGEgLyBBbGlh cyAvIEZpbHRlciBJbXBsZW1lbnRhdGlvbg0KDQpIaSBKb24sDQoNCk9uIDIwMTcvMDgvMDMgMTY6 NTYsIEpvbiBTaGFsbG93IHdyb3RlOg0KSGkgS2FuYW1lLA0KDQpTbyBhcyBJIHJlYWQgdGhpcywg eW91IGFyZSBlaXRoZXIgZXh0ZW5kaW5nIHRoZSBpZXRmLWRvdC1zaWduYWwgZGVmaW5pdGlvbiB0 byBpbmNsdWRlIHNvdXJjZS0qIChhbmQgaWNtcCwgZnJhZ21lbnRhdGlvbiBhbmQgcG9zc2libHkg cmF0ZS1saW1pdGluZykgaW5mb3JtYXRpb24gb3IgeW91IGFyZSB1c2luZyBGaWx0ZXJzIG92ZXIg dGhlIGRhdGEgY2hhbm5lbCAod2hpY2ggaXMgd2hhdCBUaXJ1IGlzIHJlZmVycmluZyB0bykuICBJ ZiBpdCBpcyBhbiBleHRlbnNpb24gdG8gaWV0Zi1kb3Qtc2lnbmFsLCB0aGVuIHRoaXMgbmVlZHMg dG8gYmUgZm9ybWFsaXNlZCBmb3IgaW50ZXJvcGVyYWJpbGl0eSBiZXR3ZWVuIGRpZmZlcmVudCBz dXBwbGllcnMuDQpUaGUgbGF0dGVyIGlzIG15IGludGVudGlvbi4gIEknbGwgY2hlY2sgd2hldGhl ciB0aGUgYWxpYXMgbWVjaGFuaXNtIHdoaWNoIGNvdXBsZXMgdGhlIGRhdGEtY2hhbm5lbCBhbmQg c2lnbmFsLWNoYW5uZWwgd29ya3Mgd2VsbC4NCg0KDQpTaW1pbGFybHksIGlldGYtZG90cy1kYXRh LWNoYW5uZWwtaWRlbnRpZmllciBuZWVkcyB0byBiZSBleHRlbmRlZCDigJMgYnV0IEkgZG8gdGhp bmsgdGhlIG5hbWluZyAoZS5nLiB0YXJnZXQtaXAgaW5zdGVhZCBvZiBqdXN0IGlwKSBuZWVkcyB0 byBiZSBjb25zaXN0ZW50IGJldHdlZW4gaWV0Zi1kb3Qtc2lnbmFsIGFuZCBpZXRmLWRvdHMtZGF0 YS1jaGFubmVsLWlkZW50aWZpZXIuDQorMS4NCmEgY29uc2lzdGVuY3kgb2YgbmFtaW5nIGlzIGlt cG9ydGFudCBmb3IgcmVhZGVycy4NCg0KdGhhbmtzLA0KS2FuYW1lDQoNCg0K4oCcNS4zLjHigJ0g b2YgZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1jaGFubmVsIHdvdWxkIGFsc28gbmVlZCB0byByZWZs ZWN0IHRoZSBpZXRmLWRvdC1zaWduYWwgY2hhbmdlLiDigJw2LuKAnSBhbmQg4oCcMTAuMS4y4oCd IG9mIGRyYWZ0LWlldGYtZG90cy1zaWduYWwtY2hhbm5lbCB3b3VsZCBhbHNvIG5lZWQgQ0JPUiB0 byBiZSB1cGRhdGVkIHdpdGggc291cmNlLSogZXRjLiBkZWZpbml0aW9ucy4NCg0KSSBhbSBvZiB0 aGUgZmlybSBvcGluaW9uIHRoYXQgZGVzdGluYXRpb24taXAgaXMgUkVRVUlSRUQgYW5kIE1VU1Qg YmUgd2l0aGluIHRoZSBtaXRpZ2F0aW9uIHNjb3BlIG9mIHRoZSBET1RTIENsaWVudCB0byBwcmV2 ZW50IHRha2luZyBvdXQgc29tZW9uZSBlbHNl4oCZcyBJUC4gIFRoaXMgaXMgdHJ1ZSBmb3IgaWV0 Zi1kb3Qtc2lnbmFsLCBpZXRmLWRvdHMtZGF0YS1jaGFubmVsLWlkZW50aWZpZXIgYW5kIGlldGYt ZG90cy1hY2Nlc3MtY29udHJvbC1saXN0Lg0KDQpJIGRvIG5vdCB0aGluayBmcmFnbWVudGF0aW9u IHJlcHJlc2VudGVkIGFzIHBvcnQ9MCBpcyBzdWZmaWNpZW50IChhbmQgaXMgbm90IG5lY2Vzc2Fy aWx5IGludHVpdGl2ZSDigJMgaXQgY291bGQgYmUgcmVhZCBhcyBqdXN0IHRha2Ugb3V0IHRoZSBz dWJzZXF1ZW50IHBhY2tldHMgb2YgYSBmcmFnbWVudGVkIHNlcXVlbmNlIGlmIHRoZSBsYXllciA0 IGhlYWRlciBpcyBub3QgdGhlcmUgYW5kIGhlbmNlIG5vIHBvcnQpLiBJIHRoaW5rIGl0IHNob3Vs ZCBoYXZlIGl0cyBvd24gaWV0Zi1kb3Qtc2lnbmFsIGRlZmluaXRpb24uDQoNCkl0IGlzIHVuY2xl YXIgdG8gbWUgdGhlIHVzYWdlIG9mIGFsaWFzIGluIHRoZSBpZXRmLWRvdC1zaWduYWwg4oCTIGlz IGl0IHRoZSBET1RTIGNsaWVudCB1c2VzIGp1c3QgIHRoZSBhbGlhcyB3aGVuIHJlcXVlc3Rpbmcg bWl0aWdhdGlvbiwgb3IgaWYgZXh0cmEgcGFyYW1ldGVycyBhcmUgcHJvdmlkZWQgKGUuZy4gYWxp YXMgcGx1cyB0YXJnZXQtcG9ydC1yYW5nZSkgYXJlIHRoZSBleHRyYSBwYXJhbWV0ZXJzIGEgcmVw bGFjZW1lbnQgb3IgaW4gYWRkaXRpb24gdG8gd2hhdCBpcyBpbiB0aGUgaWV0Zi1kb3RzLWRhdGEt Y2hhbm5lbC1pZGVudGlmaWVyIG9yIGFyZSB0aGUgZXh0cmEgcGFyYW1ldGVycyBpZ25vcmVkIGFs dG9nZXRoZXI/DQoNClJlZ2FyZHMNCg0KSm9uDQoNCkZyb206IERvdHMgW21haWx0bzogZG90cy1i b3VuY2VzQGlldGYub3JnPG1haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYg T2Yga2FuYW1lIG5pc2hpenVrYQ0KU2VudDogMDMgQXVndXN0IDIwMTcgMDY6MjENClRvOiBEb2Ji aW5zLCBSb2xhbmQ7IEpvbiBTaGFsbG93DQpDYzogZG90c0BpZXRmLm9yZzxtYWlsdG86ZG90c0Bp ZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbRG90c10gU2lnbmFsIC8gRGF0YSAvIEFsaWFzIC8gRmls dGVyIEltcGxlbWVudGF0aW9uDQoNCkhpIEpvbiwNCg0KSSdtIGltcGxlbWVudGluZyB0aGUgRE9U UyBwcm90b2NvbCBiYXNlZCBvbiBjdXJyZW50IHNwZWNpZmljYXRpb25zLg0KVGhlIERPVFMgcHJv dG9jb2wgY2FuIGhhbmRsZSBzb3VyY2UtKiBpbmZvcm1hdGlvbiBpbiBhIG1pdGlnYXRpb24gc2ln bmFsIHJlcXVlc3QuDQpGb3IgZXhhbXBsZSwgdGhlIERPVFMgc2VydmVyIGNhbiBlbmFibGUgQkdQ IEZsb3dzcGVjIGZyb20gNS10dXBsZSBpbmZvcm1hdGlvbiBkZXJpdmVkIGZyb20gbWl0aWdhdGlv biByZXF1ZXN0IG1lc3NhZ2UgZnJvbSBET1RTIGNsaWVudCwgdGhhdCBpcyBhY3R1YWxseSB3ZSBh cmUgcGxhbm5pbmcgdG8gYWRkIHRvIG91ciBzb2Z0d2FyZS4NCkRlc3RpbmF0aW9uIGluZm9ybWF0 aW9uIGlzIHVzZWQgdG8gdmFsaWRhdGUgd2hldGhlciB0aGUgbWl0aWdhdGlvbi1zY29wZSBpcyBy ZWFsbHkgdGhlIHByb3BlcnR5IG9mIHRoZSBET1RTIGNsaWVudCdzIG9yZ2FuaXphdGlvbiBvciBu b3QuDQpTbywgaWYgdGhlIHJlcXVlc3QgaXMgb25seSBpbmNsdWRpbmcgc291cmNlLSogaW5mb3Jt YXRpb24sIGhvdyB0byB2YWxpZGF0ZSB0aGUgcmVxdWVzdCBpcyBhbm90aGVyIHByb2JsZW0gYmVj YXVzZSBpdCBjYW4gY2F1c2UgdW5pbnRlbmRlZCBzaWRlIGVmZmVjdCB0byBvdGhlciBjdXN0b21l cnMvc2VydmljZXMgKGJ1dCBjb3VsZCBiZSBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYykNCg0KKiBI b3cgZG8gd2UgaGFuZGxlIHNwZWNpZmljIElDTVAgdHlwZXMgIGluIGEgbWl0aWdhdGlvbiBzaWdu YWwgcmVxdWVzdD8NCg0KVGlydSB3cm90ZToNCj4gVGhhbmtzIGZvciB0aGUgcmV2aWV3LiBGaXhl ZCBjb21tZW50cyAxIGFuZCAyIGluIG15IGxvY2FsIGNvcHkuIFRvIHN1cHBvcnQgZmlsdGVyaW5n IHJ1bGVzIGJhc2VkIG9uIElDTVAgdHlwZSBhbmQgY29kZSwgYW5kIGZpbHRlcmluZyBiYXNlZCBv biBmcmFnbWVudHMsIHRoZSBiYXNlIEFDTCBtb2RlbCBkZWZpbmVkIGluIGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldG1vZC1hY2wtbW9kZWwtMDYgbmVlZHMgdG8gYmUg ZXh0ZW5kZWQgaW4gdGhpcyBkcmFmdCB1c2luZyBhdWdtZW50YXRpb24gKHNlZSBodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjNjAyMCNzZWN0aW9uLTQuMi44KS4NCj4gSSB3aWxsIGV4dGVu ZCB0aGUgQUNMIFlBTkcgbW9kZWwgaW4gdGhlIG5leHQgcmV2aXNpb24uDQoNCkFuZCB0aGUgbGF0 ZXN0IHZlcnNpb24gb2YgZHJhZnQtaWV0Zi1uZXRtb2QtYWNsLW1vZGVsICgtMTEpIGluY2x1ZGVz IElDTVAtQUNMICh0eXBlLCBjb2RlLCwpDQpJIHRoaW5rIHdlIHNob3VsZCB1cGRhdGUgdGhlIGRy YWZ0Lg0KDQoqIEhvdyBkbyB3ZSBoYW5kbGUgZnJhZ21lbnRhdGlvbiBpbiBhIG1pdGlnYXRpb24g c2lnbmFsIHJlcXVlc3Q/DQpmcmFnbWVudGF0aW9uIGNhbiBiZSByZXByZXNlbnRlZCBhcyBwb3J0 PTAuIElzIHRoaXMgYSBzdWZmaWNpZW50IHJlcHJlc2VudGF0aW9uPw0KDQp0aGFua3MsDQpLYW5h bWUNCg0KDQoNCk9uIDIwMTcvMDgvMDMgMzoyNywgRG9iYmlucywgUm9sYW5kIHdyb3RlOg0KDQpP biBBdWcgMiwgMjAxNywgYXQgMjI6MjUsIEpvbiBTaGFsbG93IDxzdXBqcHMtaWV0ZkBqcHNoYWxs b3cuY29tPG1haWx0bzpzdXBqcHMtaWV0ZkBqcHNoYWxsb3cuY29tPj4gd3JvdGU6DQpJbiBkcmFm dC1pZXRmLWRvdHMtdXNlLWNhc2VzLTA3DQozLjEuNi4gIEVuZC1jdXN0b21lciBvcGVyYXRpbmcg YSBDUEUgbmV0d29yayBpbmZyYXN0cnVjdHVyZSBkZXZpY2Ugd2l0aA0KICAgICAgIGFuIGludGVn cmF0ZWQgRE9UUyBjbGllbnQNCg0KMy4xLjYgZnJvbSBpZHJhZnQtaWV0Zi1kb3RzLXVzZS1jYXNl cy0wNyBpbiBmdWxsOg0KDQoNCg0KMy4xLjYuICBFbmQtY3VzdG9tZXIgb3BlcmF0aW5nIGEgQ1BF IG5ldHdvcmsgaW5mcmFzdHJ1Y3R1cmUgZGV2aWNlIHdpdGgNCg0KICAgICAgICBhbiBpbnRlZ3Jh dGVkIERPVFMgY2xpZW50DQoNCg0KDQogICBTaW1pbGFyIHRvIHRoZSBhYm92ZSB1c2UtY2FzZSBm ZWF0dXJpbmcgYXBwbGljYXRpb25zIG9yIHNlcnZpY2VzIHdpdGgNCg0KICAgYnVpbHQtaW4gRERv UyBhdHRhY2sgZGV0ZWN0aW9uL2NsYXNzaWZpY2F0aW9uIGFuZCBET1RTIGNsaWVudA0KDQogICBj YXBhYmlsaXRpZXMsIGluIHRoaXMgc2NlbmFyaW8sIGFuIGVuZC1jdXN0b21lciBuZXR3b3JrDQoN CiAgIGluZnJhc3RydWN0dXJlIENQRSBkZXZpY2Ugc3VjaCBhcyBhIHJvdXRlciwgbGF5ZXItMyBz d2l0Y2gsIGZpcmV3YWxsLA0KDQogICBvciBsb2FkLWJhbGFuY2UgaW5jb3Jwb3JhdGVzIGJvdGgg dGhlIGZ1bmN0aW9uYWxpdHkgcmVxdWlyZWQgdG8NCg0KICAgZGV0ZWN0IGFuZCBjbGFzc2lmeSBp bmNvbWluZyBERG9TIGF0dGFja3MgYXMgd2VsbCBhcyBET1RTIGNsaWVudA0KDQogICBmdW5jdGlv bmFsaXR5Lg0KDQoNCg0KICAgVGhlIHN1YnNlcXVlbnQgRE9UUyBjb21tdW5pY2F0aW9ucyBkaWFs b2d1ZSBhbmQgcmVzdWx0YW50IEREb1MNCg0KICAgbWl0aWdhdGlvbiBpbml0aWF0aW9uIGFuZCB0 ZXJtaW5hdGlvbiBhY3Rpdml0aWVzIHRha2UgcGxhY2UgaW4gdGhlDQoNCiAgIHNhbWUgbWFubmVy IGFzIHRoZSB1c2UtY2FzZXMgZGVzY3JpYmVkIGFib3ZlLg0KDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KDQpSb2xhbmQgRG9iYmlucyA8cmRvYmJpbnNAYXJib3IubmV0PG1h aWx0bzpyZG9iYmluc0BhcmJvci5uZXQ+Pg0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkRvdHMgbWFpbGluZyBsaXN0DQoNCkRvdHNA aWV0Zi5vcmc8bWFpbHRvOkRvdHNAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vZG90cw0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQoNCkRvdHMgbWFpbGluZyBsaXN0DQoNCkRvdHNAaWV0Zi5v cmc8bWFpbHRvOkRvdHNAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vZG90cw0KDQo= --_000_DM5PR16MB1788F25710A5DDC11C3A733AEAB10DM5PR16MB1788namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJ cGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiXEBEZW5nWGlhbiI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlVJQ1RGb250VGV4dFN0eWxlVGFsbEJvZHk7 fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjsNCglj b2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRl ZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7fQ0K c3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3Jt YXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJI VE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJY29sb3I6YmxhY2s7 fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5 bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJp Z2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47 DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJp ZjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0 OTdEO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9 IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93 dGV4dCI+VXBkYXRlZCBwYXJhbWV0ZXIgbmFtZXMgdG8gYmUgY29uc2lzdGVudCBiL3cgaWV0Zi1k b3RzLXNpZ25hbCBhbmQgaWV0Zi1kb3RzLWRhdGEtY2hhbm5lbCBpbiBteSBsb2NhbCBjb3B5Lg0K PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5BZGRlZCB0 aGUgZm9sbG93aW5nIGxpbmUgdG8gY2xhcmlmeSB0aGUgdXNlIG9mIGFsaWFzOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3 aW5kb3d0ZXh0Ij5JZiB0aGUgbWl0aWdhdGlvbiByZXF1ZXN0IGNvbnRhaW5zIGJvdGggYWxpYXMg YW5kIG90aGVyIHBhcmFtZXRlcnMgaWRlbnRpZnlpbmcgdGhlIHRhcmdldCByZXNvdXJjZSAoc3Vj aCBhcywgdGFyZ2V0LWlwLCB0YXJnZXQtcHJlZml4LCBmcWRuLCB1cmkpIHRoZW4gdGhlDQogRE9U UyBzZXJ2ZXIgYXBwZW5kcyB0aGUgcGFyYW1ldGVyIHZhbHVlcyBpbiBhbGlhcyB3aXRoIHRoZSBj b3JyZXNwb25kaW5nIHBhcmFtZXRlciB2YWx1ZXMgaW4gdGFyZ2V0LWlwLCB0YXJnZXQtcHJlZml4 LCBmcWRuLCB1cmkgcGFyYW1ldGVycy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOndpbmRvd3RleHQiPi1UaXJ1PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48bzpwPjwvbzpw PjwvYT48L3NwYW4+PC9wPg0KPHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBv c2UiPjwvc3Bhbj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJs dWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2lu ZG93dGV4dCI+IERvdHMgW21haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhh bGYgT2YgPC9iPmthbmFtZSBuaXNoaXp1a2E8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEF1 Z3VzdCAzLCAyMDE3IDM6NDggUE08YnI+DQo8Yj5Ubzo8L2I+IEpvbiBTaGFsbG93ICZsdDtzdXBq cHMtaWV0ZkBqcHNoYWxsb3cuY29tJmd0OzsgZG90c0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW0RvdHNdIFNpZ25hbCAvIERhdGEgLyBBbGlhcyAvIEZpbHRlciBJbXBsZW1lbnRh dGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRkkiPkhpIEpvbiw8YnI+DQo8YnI+ DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRkkiPk9uIDIwMTcvMDgvMDMgMTY6NTYsIEpvbiBTaGFsbG93IHdyb3RlOjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJGSSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIEthbmFtZSw8L3NwYW4+PHNwYW4g bGFuZz0iRkkiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkZJIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFu IGxhbmc9IkZJIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+U28gYXMgSSByZWFkIHRoaXMsIHlvdSBhcmUg ZWl0aGVyIGV4dGVuZGluZyB0aGUgaWV0Zi1kb3Qtc2lnbmFsIGRlZmluaXRpb24gdG8gaW5jbHVk ZSBzb3VyY2UtKiAoYW5kIGljbXAsIGZyYWdtZW50YXRpb24gYW5kIHBvc3NpYmx5IHJhdGUtbGlt aXRpbmcpIGluZm9ybWF0aW9uDQogb3IgeW91IGFyZSB1c2luZyBGaWx0ZXJzIG92ZXIgdGhlIGRh dGEgY2hhbm5lbCAod2hpY2ggaXMgd2hhdCBUaXJ1IGlzIHJlZmVycmluZyB0bykuJm5ic3A7IElm IGl0IGlzIGFuIGV4dGVuc2lvbiB0byBpZXRmLWRvdC1zaWduYWwsIHRoZW4gdGhpcyBuZWVkcyB0 byBiZSBmb3JtYWxpc2VkIGZvciBpbnRlcm9wZXJhYmlsaXR5IGJldHdlZW4gZGlmZmVyZW50IHN1 cHBsaWVycy4mbmJzcDsNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBsYXR0ZXIgaXMgbXkgaW50ZW50aW9uLiZuYnNwOyBJJ2xs IGNoZWNrIHdoZXRoZXIgdGhlIGFsaWFzIG1lY2hhbmlzbSB3aGljaCBjb3VwbGVzIHRoZSBkYXRh LWNoYW5uZWwgYW5kIHNpZ25hbC1jaGFubmVsIHdvcmtzIHdlbGwuPGJyPg0KPGJyPg0KPGJyPg0K PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5TaW1pbGFybHksIGlldGYtZG90cy1kYXRhLWNoYW5uZWwtaWRlbnRpZmll ciBuZWVkcyB0byBiZSBleHRlbmRlZCDigJMgYnV0IEkgZG8gdGhpbmsgdGhlIG5hbWluZyAoZS5n LiB0YXJnZXQtaXAgaW5zdGVhZCBvZiBqdXN0IGlwKSBuZWVkcyB0byBiZSBjb25zaXN0ZW50IGJl dHdlZW4NCiBpZXRmLWRvdC1zaWduYWwgYW5kIGlldGYtZG90cy1kYXRhLWNoYW5uZWwtaWRlbnRp Zmllci4mbmJzcDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+JiM0MzsxLjxicj4NCmEgY29uc2lzdGVuY3kgb2YgbmFtaW5nIGlzIGlt cG9ydGFudCBmb3IgcmVhZGVycy48YnI+DQo8YnI+DQp0aGFua3MsPGJyPg0KS2FuYW1lPGJyPg0K PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj7igJw1LjMuMeKAnSBvZiBkcmFmdC1pZXRmLWRvdHMt c2lnbmFsLWNoYW5uZWwgd291bGQgYWxzbyBuZWVkIHRvIHJlZmxlY3QgdGhlIGlldGYtZG90LXNp Z25hbCBjaGFuZ2UuIOKAnDYu4oCdIGFuZCDigJwxMC4xLjLigJ0gb2YgZHJhZnQtaWV0Zi1kb3Rz LXNpZ25hbC1jaGFubmVsIHdvdWxkIGFsc28NCiBuZWVkIENCT1IgdG8gYmUgdXBkYXRlZCB3aXRo IHNvdXJjZS0qIGV0Yy4gZGVmaW5pdGlvbnMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5JIGFtIG9mIHRoZSBmaXJtIG9waW5pb24gdGhhdCBkZXN0aW5hdGlvbi1p cCBpcyBSRVFVSVJFRCBhbmQgTVVTVCBiZSB3aXRoaW4gdGhlIG1pdGlnYXRpb24gc2NvcGUgb2Yg dGhlIERPVFMgQ2xpZW50IHRvIHByZXZlbnQgdGFraW5nIG91dCBzb21lb25lIGVsc2XigJlzIElQ LiZuYnNwOw0KIFRoaXMgaXMgdHJ1ZSBmb3IgaWV0Zi1kb3Qtc2lnbmFsLCBpZXRmLWRvdHMtZGF0 YS1jaGFubmVsLWlkZW50aWZpZXIgYW5kIGlldGYtZG90cy1hY2Nlc3MtY29udHJvbC1saXN0Ljwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBkbyBub3QgdGhpbmsg ZnJhZ21lbnRhdGlvbiByZXByZXNlbnRlZCBhcyBwb3J0PTAgaXMgc3VmZmljaWVudCAoYW5kIGlz IG5vdCBuZWNlc3NhcmlseSBpbnR1aXRpdmUg4oCTIGl0IGNvdWxkIGJlIHJlYWQgYXMganVzdCB0 YWtlIG91dCB0aGUgc3Vic2VxdWVudCBwYWNrZXRzDQogb2YgYSBmcmFnbWVudGVkIHNlcXVlbmNl IGlmIHRoZSBsYXllciA0IGhlYWRlciBpcyBub3QgdGhlcmUgYW5kIGhlbmNlIG5vIHBvcnQpLiBJ IHRoaW5rIGl0IHNob3VsZCBoYXZlIGl0cyBvd24gaWV0Zi1kb3Qtc2lnbmFsIGRlZmluaXRpb24u PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JdCBpcyB1bmNsZWFy IHRvIG1lIHRoZSB1c2FnZSBvZiBhbGlhcyBpbiB0aGUgaWV0Zi1kb3Qtc2lnbmFsIOKAkyBpcyBp dCB0aGUgRE9UUyBjbGllbnQgdXNlcyBqdXN0ICZuYnNwO3RoZSBhbGlhcyB3aGVuIHJlcXVlc3Rp bmcgbWl0aWdhdGlvbiwgb3IgaWYgZXh0cmEgcGFyYW1ldGVycw0KIGFyZSBwcm92aWRlZCAoZS5n LiBhbGlhcyBwbHVzIHRhcmdldC1wb3J0LXJhbmdlKSBhcmUgdGhlIGV4dHJhIHBhcmFtZXRlcnMg YSByZXBsYWNlbWVudCBvciBpbiBhZGRpdGlvbiB0byB3aGF0IGlzIGluIHRoZSBpZXRmLWRvdHMt ZGF0YS1jaGFubmVsLWlkZW50aWZpZXIgb3IgYXJlIHRoZSBleHRyYSBwYXJhbWV0ZXJzIGlnbm9y ZWQgYWx0b2dldGhlcj88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PlJlZ2FyZHM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkpvbjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOndpbmRvd3RleHQiPiBEb3RzIFttYWlsdG86DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmRv dHMtYm91bmNlc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPmRvdHMtYm91bmNlc0BpZXRmLm9y Zzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+XQ0KPGI+T24gQmVo YWxmIE9mIDwvYj5rYW5hbWUgbmlzaGl6dWthPGJyPg0KPGI+U2VudDo8L2I+IDAzIEF1Z3VzdCAy MDE3IDA2OjIxPGJyPg0KPGI+VG86PC9iPiBEb2JiaW5zLCBSb2xhbmQ7IEpvbiBTaGFsbG93PGJy Pg0KPGI+Q2M6PC9iPiA8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmRvdHNAaWV0Zi5vcmciPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oyxz YW5zLXNlcmlmIj5kb3RzQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3 aW5kb3d0ZXh0Ij48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtEb3RzXSBTaWduYWwgLyBEYXRh IC8gQWxpYXMgLyBGaWx0ZXIgSW1wbGVtZW50YXRpb248L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkhpIEpv biw8YnI+DQo8YnI+DQpJJ20gaW1wbGVtZW50aW5nIHRoZSBET1RTIHByb3RvY29sIGJhc2VkIG9u IGN1cnJlbnQgc3BlY2lmaWNhdGlvbnMuPGJyPg0KVGhlIERPVFMgcHJvdG9jb2wgY2FuIGhhbmRs ZSBzb3VyY2UtKiBpbmZvcm1hdGlvbiBpbiBhIG1pdGlnYXRpb24gc2lnbmFsIHJlcXVlc3QuPGJy Pg0KRm9yIGV4YW1wbGUsIHRoZSBET1RTIHNlcnZlciBjYW4gZW5hYmxlIEJHUCBGbG93c3BlYyBm cm9tIDUtdHVwbGUgaW5mb3JtYXRpb24gZGVyaXZlZCBmcm9tIG1pdGlnYXRpb24gcmVxdWVzdCBt ZXNzYWdlIGZyb20gRE9UUyBjbGllbnQsIHRoYXQgaXMgYWN0dWFsbHkgd2UgYXJlIHBsYW5uaW5n IHRvIGFkZCB0byBvdXIgc29mdHdhcmUuPGJyPg0KRGVzdGluYXRpb24gaW5mb3JtYXRpb24gaXMg dXNlZCB0byB2YWxpZGF0ZSB3aGV0aGVyIHRoZSBtaXRpZ2F0aW9uLXNjb3BlIGlzIHJlYWxseSB0 aGUgcHJvcGVydHkgb2YgdGhlIERPVFMgY2xpZW50J3Mgb3JnYW5pemF0aW9uIG9yIG5vdC48YnI+ DQpTbywgaWYgdGhlIHJlcXVlc3QgaXMgb25seSBpbmNsdWRpbmcgc291cmNlLSogaW5mb3JtYXRp b24sIGhvdyB0byB2YWxpZGF0ZSB0aGUgcmVxdWVzdCBpcyBhbm90aGVyIHByb2JsZW0gYmVjYXVz ZSBpdCBjYW4gY2F1c2UgdW5pbnRlbmRlZCBzaWRlIGVmZmVjdCB0byBvdGhlciBjdXN0b21lcnMv c2VydmljZXMgKGJ1dCBjb3VsZCBiZSBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYyk8YnI+DQo8YnI+ DQoqIEhvdyBkbyB3ZSBoYW5kbGUgc3BlY2lmaWMgSUNNUCB0eXBlcyZuYnNwOyBpbiBhIG1pdGln YXRpb24gc2lnbmFsIHJlcXVlc3Q/PGJyPg0KPGJyPg0KVGlydSB3cm90ZTo8YnI+DQomZ3Q7IFRo YW5rcyBmb3IgdGhlIHJldmlldy4gRml4ZWQgY29tbWVudHMgMSBhbmQgMiBpbiBteSBsb2NhbCBj b3B5LiBUbyBzdXBwb3J0IGZpbHRlcmluZyBydWxlcyBiYXNlZCBvbiBJQ01QIHR5cGUgYW5kIGNv ZGUsIGFuZCBmaWx0ZXJpbmcgYmFzZWQgb24gZnJhZ21lbnRzLCB0aGUgYmFzZSBBQ0wgbW9kZWwg ZGVmaW5lZCBpbg0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtbmV0bW9kLWFjbC1tb2RlbC0wNiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtbmV0bW9kLWFjbC1tb2RlbC0wNjwvYT4gbmVlZHMgdG8gYmUgZXh0ZW5kZWQgaW4gdGhp cyBkcmFmdCB1c2luZyBhdWdtZW50YXRpb24gKHNlZQ0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzYwMjAjc2VjdGlvbi00LjIuOCI+aHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL3JmYzYwMjAjc2VjdGlvbi00LjIuODwvYT4pLg0KPGJyPg0KJmd0OyBJIHdpbGwgZXh0 ZW5kIHRoZSBBQ0wgWUFORyBtb2RlbCBpbiB0aGUgbmV4dCByZXZpc2lvbi4gPGJyPg0KPGJyPg0K QW5kIHRoZSBsYXRlc3QgdmVyc2lvbiBvZiBkcmFmdC1pZXRmLW5ldG1vZC1hY2wtbW9kZWwgKC0x MSkgaW5jbHVkZXMgSUNNUC1BQ0wgKHR5cGUsIGNvZGUsLCk8YnI+DQpJIHRoaW5rIHdlIHNob3Vs ZCB1cGRhdGUgdGhlIGRyYWZ0Ljxicj4NCjxicj4NCiogSG93IGRvIHdlIGhhbmRsZSBmcmFnbWVu dGF0aW9uIGluIGEgbWl0aWdhdGlvbiBzaWduYWwgcmVxdWVzdD88YnI+DQpmcmFnbWVudGF0aW9u IGNhbiBiZSByZXByZXNlbnRlZCBhcyBwb3J0PTAuIElzIHRoaXMgYSBzdWZmaWNpZW50IHJlcHJl c2VudGF0aW9uPzxicj4NCjxicj4NCnRoYW5rcyw8YnI+DQpLYW5hbWU8YnI+DQo8YnI+DQo8YnI+ DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAy MDE3LzA4LzAzIDM6MjcsIERvYmJpbnMsIFJvbGFuZCB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPk9uIEF1ZyAyLCAyMDE3LCBhdCAyMjoyNSwgSm9uIFNoYWxsb3cgJmx0OzxhIGhy ZWY9Im1haWx0bzpzdXBqcHMtaWV0ZkBqcHNoYWxsb3cuY29tIj5zdXBqcHMtaWV0ZkBqcHNoYWxs b3cuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkluIGRyYWZ0LWlldGYtZG90cy11c2UtY2FzZXMtMDcgPGJyPg0K My4xLjYuICZuYnNwO0VuZC1jdXN0b21lciBvcGVyYXRpbmcgYSBDUEUgbmV0d29yayBpbmZyYXN0 cnVjdHVyZSBkZXZpY2Ugd2l0aDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwO2FuIGludGVncmF0ZWQgRE9UUyBjbGllbnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+My4xLjYgZnJvbSBpZHJhZnQtaWV0Zi1k b3RzLXVzZS1jYXNlcy0wNyBpbiBmdWxsOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6OC4wcHQg OC4wcHQgOC4wcHQgOC4wcHQiPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNr Z3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGw7Ym94LXNpemluZzogYm9yZGVyLWJv eDt3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7Ym9yZGVyLXRvcC1sZWZ0LXJhZGl1czogNHB4O2JvcmRl ci10b3AtcmlnaHQtcmFkaXVzOiA0cHg7Ym9yZGVyLWJvdHRvbS1yaWdodC1yYWRpdXM6IDRweDti b3JkZXItYm90dG9tLWxlZnQtcmFkaXVzOiA0cHg7LXdlYmtpdC10YXAtaGlnaGxpZ2h0LWNvbG9y OiByZ2JhKDAsIDAsIDAsIDApOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogMTAwJTtvdmVyZmxv dzphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+My4xLjYuJm5ic3A7IEVuZC1j dXN0b21lciBvcGVyYXRpbmcgYSBDUEUgbmV0d29yayBpbmZyYXN0cnVjdHVyZSBkZXZpY2Ugd2l0 aDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3Ljlw dDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgYW4gaW50ZWdyYXRlZCBET1RTIGNsaWVudDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVh azpicmVhay1hbGwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dy b3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdCI+Jm5ic3A7Jm5ic3A7IFNpbWlsYXIgdG8gdGhlIGFib3ZlIHVzZS1jYXNlIGZlYXR1 cmluZyBhcHBsaWNhdGlvbnMgb3Igc2VydmljZXMgd2l0aDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29y ZC1icmVhazpicmVhay1hbGwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij4mbmJzcDsm bmJzcDsgYnVpbHQtaW4gRERvUyBhdHRhY2sgZGV0ZWN0aW9uL2NsYXNzaWZpY2F0aW9uIGFuZCBE T1RTIGNsaWVudDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJv dHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij4mbmJzcDsmbmJzcDsgY2FwYWJpbGl0aWVzLCBpbiB0 aGlzIHNjZW5hcmlvLCBhbiBlbmQtY3VzdG9tZXIgbmV0d29yazwvc3Bhbj48bzpwPjwvbzpwPjwv cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7 d29yZC1icmVhazpicmVhay1hbGwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij4mbmJz cDsmbmJzcDsgaW5mcmFzdHJ1Y3R1cmUgQ1BFIGRldmljZSBzdWNoIGFzIGEgcm91dGVyLCBsYXll ci0zIHN3aXRjaCwgZmlyZXdhbGwsPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl PSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFr LWFsbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPiZuYnNwOyZuYnNwOyBvciBsb2Fk LWJhbGFuY2UgaW5jb3Jwb3JhdGVzIGJvdGggdGhlIGZ1bmN0aW9uYWxpdHkgcmVxdWlyZWQgdG88 L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7 YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdCI+Jm5ic3A7Jm5ic3A7IGRldGVjdCBhbmQgY2xhc3NpZnkgaW5jb21pbmcg RERvUyBhdHRhY2tzIGFzIHdlbGwgYXMgRE9UUyBjbGllbnQ8L3NwYW4+PG86cD48L286cD48L3By ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dv cmQtYnJlYWs6YnJlYWstYWxsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+Jm5ic3A7 Jm5ic3A7IGZ1bmN0aW9uYWxpdHkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl PSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFr LWFsbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNG RkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 Ij4mbmJzcDsmbmJzcDsgVGhlIHN1YnNlcXVlbnQgRE9UUyBjb21tdW5pY2F0aW9ucyBkaWFsb2d1 ZSBhbmQgcmVzdWx0YW50IEREb1M8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9 Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWst YWxsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+Jm5ic3A7Jm5ic3A7IG1pdGlnYXRp b24gaW5pdGlhdGlvbiBhbmQgdGVybWluYXRpb24gYWN0aXZpdGllcyB0YWtlIHBsYWNlIGluIHRo ZTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3Ljlw dDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0Ij4mbmJzcDsmbmJzcDsgc2FtZSBtYW5uZXIgYXMgdGhlIHVzZS1jYXNl cyBkZXNjcmliZWQgYWJvdmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJt YXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6d2hpdGU7d29yZC1icmVhazpicmVhay1hbGw7 Ym94LXNpemluZzogYm9yZGVyLWJveDt3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7Ym9yZGVyLXRvcC1s ZWZ0LXJhZGl1czogNHB4O2JvcmRlci10b3AtcmlnaHQtcmFkaXVzOiA0cHg7Ym9yZGVyLWJvdHRv bS1yaWdodC1yYWRpdXM6IDRweDtib3JkZXItYm90dG9tLWxlZnQtcmFkaXVzOiA0cHg7b3ZlcmZs b3c6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlVJQ1RGb250VGV4dFN0eWxlVGFsbEJv ZHkiPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIDwvc3Bhbj48bzpwPjwvbzpw PjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzo4LjBwdCA4LjBwdCA4LjBwdCA4LjBwdCI+DQo8cHJlIHN0eWxlPSJtYXJn aW4tYm90dG9tOjcuOXB0O3dvcmQtYnJlYWs6YnJlYWstYWxsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6VUlDVEZvbnRUZXh0U3R5bGVUYWxsQm9keSI+Um9sYW5kIERvYmJpbnMgJmx0Ozwvc3Bh bj48YSBocmVmPSJtYWlsdG86cmRvYmJpbnNAYXJib3IubmV0Ij48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6VUlDVEZvbnRUZXh0U3R5bGVUYWxsQm9keSI+cmRvYmJpbnNAYXJib3IubmV0PC9zcGFu PjwvYT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6VUlDVEZvbnRUZXh0U3R5bGVUYWxsQm9keSI+ Jmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+ DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86 cD48L286cD48L3ByZT4NCjxwcmU+RG90cyBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT48YSBocmVmPSJtYWlsdG86RG90c0BpZXRmLm9yZyI+RG90c0BpZXRmLm9yZzwvYT48bzpw PjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2RvdHMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90 czwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+ DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Eb3RzIG1haWxpbmcg bGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Im1haWx0bzpEb3RzQGlldGYub3Jn Ij5Eb3RzQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90cyI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9kb3RzPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVv dGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_DM5PR16MB1788F25710A5DDC11C3A733AEAB10DM5PR16MB1788namp_-- From nobody Thu Aug 3 06:47:30 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0BB132342 for ; Thu, 3 Aug 2017 06:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pd36iV0NTBNA for ; Thu, 3 Aug 2017 06:47:19 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 490F3132367 for ; Thu, 3 Aug 2017 06:47:19 -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.319.2; Thu, 3 Aug 2017 09:47:18 -0400 Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([::1]) with mapi id 14.03.0319.002; Thu, 3 Aug 2017 09:47:18 -0400 From: Dave Dolson To: Dave Dolson , "dots@ietf.org" Thread-Topic: Some notes on ietf-dots-signal-channel-02 Thread-Index: AdMA7vzOFdFEa4W8RY6lSPNLnIlWkALb8vdA Date: Thu, 3 Aug 2017 13:47:16 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.114] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E98A9092505wtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Some notes on ietf-dots-signal-channel-02 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for 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, 03 Aug 2017 13:47:29 -0000 --_000_E8355113905631478EFF04F5AA706E98A9092505wtlexchp2sandvi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I know I sent this at a busy time, so perhaps it was forgotten. Would the a= uthors care to comment on the points below? -Dave From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Wednesday, July 19, 2017 10:36 PM To: dots@ietf.org Subject: [Dots] Some notes on ietf-dots-signal-channel-02 Generally I think the document is pretty good, but I found a number of ques= tions and nits. BTW, is this document in github? I was going to make a pull request, but co= uldn't find it. For target-protocol, I think could be clarified using this reference: https= ://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml There is missing information about some filters: fqdn: which FQDN is supposed to go here? I'm unclear on what would be mitig= ated? DNS? HTTP? uri: does this mean an HTTP resource is under attack? It doesn't say HTTP. lifetime: I recommend a very large number be used for no timeout. (this mi= ght be a pet peeve of mine, but why do people like to use 0 to mean infinit= e?) I think in the future we might want to use 0 to mean "end now". CBOR supports binary byte strings. Therefore I suggest that IP addresses be= represented as 4-byte or 16-byte byte-strings rather than the bulkier huma= n-readable strings that may require ~40 bytes. However, then prefixes would be represented like: "target-prefix": [ {"pref= ix": byte-string[16], "length": integer}] At this time I also suggest supporting IPv4-mapped-v6 addresses to unify IP= v4 and IPv6 code. Although multiple mitigation-ids may be set, this wording confused me: If two mitigation requests have overlapping mitigation scopes the mitigation request with higher numeric mitigation-id value will override the mitigation request with a lower numeric mitigation-id value This sounds like higher-valued IDs are supposed to replace smaller values. = But that isn't intended, I don't think. Both mitigation-IDs should be store= d, but that comment is about logic in scrubbing rules and attributing bytes= -dropped. I think there may be a race condition to consider, when we allow for reorde= ring: If this sequence is sent: PUT (ID=3D1) PUT (ID=3D1) DELETE (ID=3D1) But this sequence is received: PUT (ID=3D1) DELETE (ID=3D1) PUT (ID=3D1) Then the ID 1 will be incorrectly stored. The solution is that the server n= eeds to remember deleted IDs for some time. The URIs for PUT and DELETE are specified differently (v1 and version). I s= uspect they are intended to be the same, probably "v1" ? Currently the DELETE is specified to return an error if deleting something = not found. What is the value of this error? Why not always return 2.02, the= reby giving DELETE idempotent behavior. Regarding the 5min timeout after client DELETE, did we consider making that= configurable in the delete message? This could allow a client to be a bit = smarter. If timeout=3D0, it would mean stop right now. I'm unclear on how I would determine bps-dropped or pps-dropped. What time = denominator? (Generally I find rate measurements very difficult to compute = and explain in a way that makes everyone happy.) Can we just let the client= compute bytes/time ? The -dropped counters show a clear bias towards scrubbers that simply drop = packets. Are there other actions to be considered? E.g., DSCP marking? Regarding "status", I'm unclear on what code 2 means. It sounds like all tr= affic is being dropped, but I don't consider that the most successful outco= me. I think it might be better to say "Mitigation is in progress within cap= ability" (in contrast to "exceeded capability" code 4). Regarding "observe" It says, A DOTS client that is no longer interested in receiving notifications from the DOTS server can simply "forget" the observation. More specifically, doesn't it have to make the request with "Observe=3D1" ? I think there may be some race conditions with the "observe" option. E.g., these messages reordered: Observe=3D0 Observe=3D1 I'm not sure what the solution is. (I didn't really read RFC7641 to see if = it was discussed) The efficacy update seems to use the same URI as the one for requesting mit= igation. How would the server know which type of message? I suspect we inte= nded to use a different URI. Scanning the document, a second look at all of the URIs might be in order. = We want the URI to indicate the type of operation, not inferred from the co= ntent of the body. Regarding heartbeat, what are the consequences of failure? I'm unclear on w= hat action should be taken. Please note that when under attack, round-trip times might be VERY large du= e to buffer bloat. A colleague of mine measured ping times exceeding 60s in= a hotel! On that note, should we give guidance about application-layer time-outs? A = na=EFve implementation might pick something like 5s timeout. A client shoul= d be trying multiple transports and therefore have an async approach to wri= ting the application. 5.4.2 Configuration: why is this a POST? I think this should be PUT, like = the others, since the intent is to replace previous configuration. Regarding redirected signaling, where do you get response code 3.00 from? I= t isn't listed in https://tools.ietf.org/html/rfc7252#section-12.1.2 or htt= ps://www.iana.org/assignments/core-parameters/core-parameters.xhtml#respons= e-codes . Can we use 3.00, or is there a reference you can add to the doc= ? Do we intend to prohibit large datagrams that will be fragmented? These are= not terrible, just perhaps less likely to all arrive. I think the wording = should say that multiple mitigation requests should be created to keep the = datagram size small. (I didn't read the security sections in detail, expecting them to change.) It looks like a lot of issues, but I think the comments are only possible b= ecause the document is good enough by having details. [Tip: track github issues for the points I've raised, if you cannot answer/= resolve them immediately] -Dave --_000_E8355113905631478EFF04F5AA706E98A9092505wtlexchp2sandvi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I know I sent this at = a busy time, so perhaps it was forgotten. Would the authors care to comment= on the points below?

 

-Dave

 

 

From: Dots [ma= ilto:dots-bounces@ietf.org] On Behalf Of Dave Dolson
Sent: Wednesday, July 19, 2017 10:36 PM
To: dots@ietf.org
Subject: [Dots] Some notes on ietf-dots-signal-channel-02=

 

Generally I think the document is pretty good, but I= found a number of questions and nits.

 

BTW, is this document in github? I was going to make= a pull request, but couldn’t find it.

 

 

For target-protocol, I think could be clarified usin= g this reference: https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml

 

There is missing information about some filters:

fqdn: which FQDN is supposed to go here? I’m u= nclear on what would be mitigated? DNS? HTTP?

 

uri: does this mean an HTTP resource is under attack= ? It doesn’t say HTTP.

 

lifetime:  I recommend a very large number be u= sed for no timeout. (this might be a pet peeve of mine, but why do people l= ike to use 0 to mean infinite?)  I think in the future we might want t= o use 0 to mean “end now”.

 

 

CBOR supports binary byte strings. Therefore I sugge= st that IP addresses be represented as 4-byte or 16-byte byte-strings rathe= r than the bulkier human-readable strings that may require ~40 bytes.<= /o:p>

However, then prefixes would be represented like: &q= uot;target-prefix": [ {"prefix": byte-string[16], "leng= th": integer}]

 

At this time I also suggest supporting IPv4-mapped-v= 6 addresses to unify IPv4 and IPv6 code.

 

Although multiple mitigation-ids may be set, this wo= rding confused me:

   If two mitigation requests<= /p>

   have overlapping mitigation scopes the mitiga= tion request with higher

   numeric mitigation-id value will override the= mitigation request with

   a lower numeric mitigation-id value

This sounds like higher-valued IDs are supposed to r= eplace smaller values. But that isn’t intended, I don’t think. = Both mitigation-IDs should be stored, but that comment is about logic in sc= rubbing rules and attributing bytes-dropped.

 

I think there may be a race condition to consider, w= hen we allow for reordering:

If this sequence is sent:

  PUT  (ID=3D1)

  PUT (ID=3D1)

  DELETE (ID=3D1)

But this sequence is received:

  PUT (ID=3D1)

  DELETE (ID=3D1)

  PUT  (ID=3D1)

Then the ID 1 will be incorrectly stored. The soluti= on is that the server needs to remember deleted IDs for some time.

 

The URIs for PUT and DELETE are specified differentl= y (v1 and version). I suspect they are intended to be the same, probably &#= 8220;v1” ?

 

Currently the DELETE is specified to return an error= if deleting something not found. What is the value of this error? Why not = always return 2.02, thereby giving DELETE idempotent behavior.

 

Regarding the 5min timeout after client DELETE, did = we consider making that configurable in the delete message? This could allo= w a client to be a bit smarter. If timeout=3D0, it would mean stop right no= w.

 

I’m unclear on how I would determine bps-dropp= ed or pps-dropped. What time denominator? (Generally I find rate measuremen= ts very difficult to compute and explain in a way that makes everyone happy= .) Can we just let the client compute bytes/time ?

 

The –dropped counters show a clear bias toward= s scrubbers that simply drop packets. Are there other actions to be conside= red? E.g., DSCP marking?

 

Regarding “status”, I’m unclear on= what code 2 means. It sounds like all traffic is being dropped, but I don&= #8217;t consider that the most successful outcome. I think it might be bett= er to say “Mitigation is in progress within capability” (in contrast to “exceeded capability” code 4).

 

Regarding “observe” It says,<= /p> 

    A DOTS client that is no longer
   interested in receiving notifications from the DOTS serve=
r can simply
   "forget" the observation.

More specifically, doesn’t it have to make the= request with “Observe=3D1” ?

 

I think there may be some race conditions with the &= #8220;observe” option.

E.g., these messages reordered:

  Observe=3D0

  Observe=3D1

I’m not sure what the solution is. (I didnR= 17;t really read RFC7641 to see if it was discussed)

 

The efficacy update seems to use the same URI as the= one for requesting mitigation. How would the server know which type of mes= sage? I suspect we intended to use a different URI.

Scanning the document, a second look at all of the U= RIs might be in order. We want the URI to indicate the type of operation, n= ot inferred from the content of the body.

 

Regarding heartbeat, what are the consequences of fa= ilure? I’m unclear on what action should be taken.

Please note that when under attack, round-trip times= might be VERY large due to buffer bloat. A colleague of mine measured ping= times exceeding 60s in a hotel!

 

On that note, should we give guidance about applicat= ion-layer time-outs? A na=EFve implementation might pick something like 5s = timeout. A client should be trying multiple transports and therefore have a= n async approach to writing the application.

 

5.4.2 Configuration: why is this a POST?  I thi= nk this should be PUT, like the others, since the intent is to replace prev= ious configuration.

 

Regarding redirected signaling, where do you get res= ponse code 3.00 from? It isn’t listed in https://tool= s.ietf.org/html/rfc7252#section-12.1.2 or https://www.iana.org/assignments/core-parameters/core-parameters.xhtml#resp= onse-codes  .  Can we use 3.00, or is there a reference you c= an add to the doc?

 

Do we intend to prohibit large datagrams that will b= e fragmented? These are not terrible, just perhaps less likely to all arriv= e. I think the wording should say that multiple mitigation requests should = be created to keep the datagram size small.

 

(I didn’t read the security sections in detail= , expecting them to change.)

 

It looks like a lot of issues, but I think the comme= nts are only possible because the document is good enough by having details= .

 

[Tip: track github issues for the points I’ve = raised, if you cannot answer/resolve them immediately]

-Dave

 

 

--_000_E8355113905631478EFF04F5AA706E98A9092505wtlexchp2sandvi_-- From nobody Thu Aug 3 07:23:02 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 689D61323A3 for ; Thu, 3 Aug 2017 07:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TH60Zx5ZbFQU for ; Thu, 3 Aug 2017 07:22:57 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 39AD41323A0 for ; Thu, 3 Aug 2017 07:22:57 -0700 (PDT) Received: from MIVEXAPP1N01.corpzone.internalzone.com (unknown [10.48.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp id 0fc3_810b_4b9fea48_f802_4b2e_adab_d568a734023e; Thu, 03 Aug 2017 09:22:55 -0500 Received: from MIVEXUSR1N02.corpzone.internalzone.com (10.48.48.82) by MIVEXAPP1N01.corpzone.internalzone.com (10.48.48.88) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 3 Aug 2017 10:21:07 -0400 Received: from MIVEXUSR1N05.corpzone.internalzone.com (10.48.48.85) by MIVEXUSR1N02.corpzone.internalzone.com (10.48.48.82) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 3 Aug 2017 10:21:06 -0400 Received: from MIVO365EDGE3.corpzone.internalzone.com (10.48.176.86) by MIVEXUSR1N05.corpzone.internalzone.com (10.48.48.85) with Microsoft SMTP Server (TLS) id 15.0.1263.5 via Frontend Transport; Thu, 3 Aug 2017 10:21:06 -0400 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (10.48.176.242) by edge.mcafee.com (10.48.176.86) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 3 Aug 2017 10:20:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.onmicrosoft.com; s=selector1-mcafee-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RgyWkeNkd0zVDLellZa6lzKQhxpxzP0W71EjrVkodP0=; b=pXm7TX+ktfSh6mJ1tWPgeIfNuNH/Yq7kw560M0vNo1yCWjyjPeNc82kwh7DBgccr8Au5wD3e2ACEGwcBQtFf/VNcNNveiSBOaXHm51A8tnYufzB1BIHHz6KjEObQn1+tJmegC1Auy2saE8Hzh1v6SEhhctFSKTTiu6FaawK4s0I= Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.22; Thu, 3 Aug 2017 14:21:04 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.01.1304.023; Thu, 3 Aug 2017 14:21:04 +0000 From: "Konda, Tirumaleswar Reddy" To: Dave Dolson , "dots@ietf.org" Thread-Topic: Some notes on ietf-dots-signal-channel-02 Thread-Index: AdMA7vzOFdFEa4W8RY6lSPNLnIlWkALb8vdAAAElKrA= Date: Thu, 3 Aug 2017 14:21:04 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [122.171.91.199] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1788; 7:zOMto8ghZHOh8qZWJ6WXwBNs5jH1scCUEzvsihTwcEEjOfaCgcZNmNv7eMKkjOyhl81fx5HoABCN/z+uTeUC3MFYQFmaW4KHrJLyHwUp8xKUCbXHv3f0WjmyEu4ClxftxXlycRQc0OGp+EmXFryYb672DuNcomgkTFBk4cHaVXhXF4z7CsByrPO6ckQbWZqeQGhRThu/VONe6iN3JgiCkWvUatb8OZxqoC438RxvIQ+4pPi5basErqWgMttp7CIRREBtu8aNNuuUhRBk1kXQCszGZVmVDlcW/1Uutygi+EnVbYx1ZDvYDB2J2GaOd97ErcOEZNKZm5tZKhy/ClVJRLh+cwyAQ0iEokD8g/N/VFFlOssvNzRm7tvibefHEPMfV40+mF848k09XqJmSC2w/7lLcgwSG0DLaSh4Ws38oLSW0RZlymk/WEmOIGXjLc3ApOmZfrQ42yLLzBIhCu0ZhbqVsjrBmKZpb7aCABHxd+vab4PG8k5DrAUs3m9Rrwt+tPV6TAVMzT3HCjA1+Q3HIsbDcDclOMuAXNiKNndZDyy28LicVrttlF3dUGeRfcRr2JIMl2i80CyUDZKBC2cwQ2ZIy0GV5ZsT4q2oa0c2UMxzgY9VJ4quvu7w6wtGPr5KyxFMQc1PRhn0L4e2ZqH2D5mi/UcvenLD1vEoBWPU7g36J+9nd4+MVGC6biHIvo1Ulj5lxVwc34JkuhPskequXKVc44NTXAMCagl3YHGLCfTHto6BfypOqCCmezlizZoE+XsWRNgxBqyrLh5y/FkcPjsSCoSqQNMSbrEJKFlkckA= x-ms-office365-filtering-correlation-id: 7562be03-1834-47d6-9c62-08d4da7ae040 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM5PR16MB1788; x-ms-traffictypediagnostic: DM5PR16MB1788: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(192374486261705)(788757137089)(21748063052155)(1591387915157); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123558100)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1788; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1788; x-forefront-prvs: 03883BD916 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39400400002)(39850400002)(39450400003)(39840400002)(39410400002)(32952001)(377454003)(189002)(199003)(2501003)(25786009)(2906002)(5660300001)(189998001)(966005)(77096006)(72206003)(8936002)(8676002)(55016002)(106356001)(81156014)(3660700001)(99286003)(478600001)(81166006)(6436002)(230783001)(7696004)(606006)(3280700002)(66066001)(9686003)(50986999)(53546010)(2950100002)(6246003)(38730400002)(236005)(6306002)(54896002)(19609705001)(6506006)(80792005)(790700001)(229853002)(3846002)(101416001)(7736002)(6116002)(102836003)(86362001)(97736004)(53936002)(76176999)(74316002)(68736007)(105586002)(2900100001)(14454004)(33656002)(54356999)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1788; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1788861B3EF5AA61B6F2D09EEAB10DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2017 14:21:04.7872 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1788 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6086> : inlines <6005> : streams <1756995> : uri <2475573> Archived-At: Subject: Re: [Dots] Some notes on ietf-dots-signal-channel-02 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for 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, 03 Aug 2017 14:23:00 -0000 --_000_DM5PR16MB1788861B3EF5AA61B6F2D09EEAB10DM5PR16MB1788namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks Dave for the detailed review, We will respond to the comments and up= date the draft in the next couple of weeks. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Thursday, August 3, 2017 7:17 PM To: Dave Dolson ; dots@ietf.org Subject: Re: [Dots] Some notes on ietf-dots-signal-channel-02 I know I sent this at a busy time, so perhaps it was forgotten. Would the a= uthors care to comment on the points below? -Dave From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Wednesday, July 19, 2017 10:36 PM To: dots@ietf.org Subject: [Dots] Some notes on ietf-dots-signal-channel-02 Generally I think the document is pretty good, but I found a number of ques= tions and nits. BTW, is this document in github? I was going to make a pull request, but co= uldn't find it. For target-protocol, I think could be clarified using this reference: https= ://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml There is missing information about some filters: fqdn: which FQDN is supposed to go here? I'm unclear on what would be mitig= ated? DNS? HTTP? uri: does this mean an HTTP resource is under attack? It doesn't say HTTP. lifetime: I recommend a very large number be used for no timeout. (this mi= ght be a pet peeve of mine, but why do people like to use 0 to mean infinit= e?) I think in the future we might want to use 0 to mean "end now". CBOR supports binary byte strings. Therefore I suggest that IP addresses be= represented as 4-byte or 16-byte byte-strings rather than the bulkier huma= n-readable strings that may require ~40 bytes. However, then prefixes would be represented like: "target-prefix": [ {"pref= ix": byte-string[16], "length": integer}] At this time I also suggest supporting IPv4-mapped-v6 addresses to unify IP= v4 and IPv6 code. Although multiple mitigation-ids may be set, this wording confused me: If two mitigation requests have overlapping mitigation scopes the mitigation request with higher numeric mitigation-id value will override the mitigation request with a lower numeric mitigation-id value This sounds like higher-valued IDs are supposed to replace smaller values. = But that isn't intended, I don't think. Both mitigation-IDs should be store= d, but that comment is about logic in scrubbing rules and attributing bytes= -dropped. I think there may be a race condition to consider, when we allow for reorde= ring: If this sequence is sent: PUT (ID=3D1) PUT (ID=3D1) DELETE (ID=3D1) But this sequence is received: PUT (ID=3D1) DELETE (ID=3D1) PUT (ID=3D1) Then the ID 1 will be incorrectly stored. The solution is that the server n= eeds to remember deleted IDs for some time. The URIs for PUT and DELETE are specified differently (v1 and version). I s= uspect they are intended to be the same, probably "v1" ? Currently the DELETE is specified to return an error if deleting something = not found. What is the value of this error? Why not always return 2.02, the= reby giving DELETE idempotent behavior. Regarding the 5min timeout after client DELETE, did we consider making that= configurable in the delete message? This could allow a client to be a bit = smarter. If timeout=3D0, it would mean stop right now. I'm unclear on how I would determine bps-dropped or pps-dropped. What time = denominator? (Generally I find rate measurements very difficult to compute = and explain in a way that makes everyone happy.) Can we just let the client= compute bytes/time ? The -dropped counters show a clear bias towards scrubbers that simply drop = packets. Are there other actions to be considered? E.g., DSCP marking? Regarding "status", I'm unclear on what code 2 means. It sounds like all tr= affic is being dropped, but I don't consider that the most successful outco= me. I think it might be better to say "Mitigation is in progress within cap= ability" (in contrast to "exceeded capability" code 4). Regarding "observe" It says, A DOTS client that is no longer interested in receiving notifications from the DOTS server can simply "forget" the observation. More specifically, doesn't it have to make the request with "Observe=3D1" ? I think there may be some race conditions with the "observe" option. E.g., these messages reordered: Observe=3D0 Observe=3D1 I'm not sure what the solution is. (I didn't really read RFC7641 to see if = it was discussed) The efficacy update seems to use the same URI as the one for requesting mit= igation. How would the server know which type of message? I suspect we inte= nded to use a different URI. Scanning the document, a second look at all of the URIs might be in order. = We want the URI to indicate the type of operation, not inferred from the co= ntent of the body. Regarding heartbeat, what are the consequences of failure? I'm unclear on w= hat action should be taken. Please note that when under attack, round-trip times might be VERY large du= e to buffer bloat. A colleague of mine measured ping times exceeding 60s in= a hotel! On that note, should we give guidance about application-layer time-outs? A = na=EFve implementation might pick something like 5s timeout. A client shoul= d be trying multiple transports and therefore have an async approach to wri= ting the application. 5.4.2 Configuration: why is this a POST? I think this should be PUT, like = the others, since the intent is to replace previous configuration. Regarding redirected signaling, where do you get response code 3.00 from? I= t isn't listed in https://tools.ietf.org/html/rfc7252#section-12.1.2 or htt= ps://www.iana.org/assignments/core-parameters/core-parameters.xhtml#respons= e-codes . Can we use 3.00, or is there a reference you can add to the doc= ? Do we intend to prohibit large datagrams that will be fragmented? These are= not terrible, just perhaps less likely to all arrive. I think the wording = should say that multiple mitigation requests should be created to keep the = datagram size small. (I didn't read the security sections in detail, expecting them to change.) It looks like a lot of issues, but I think the comments are only possible b= ecause the document is good enough by having details. [Tip: track github issues for the points I've raised, if you cannot answer/= resolve them immediately] -Dave --_000_DM5PR16MB1788861B3EF5AA61B6F2D09EEAB10DM5PR16MB1788namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thanks Dave for the detailed review, We will respond= to the comments and update the draft in the next couple of weeks.

 

-Tiru

&n= bsp;

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of Dave Dolson
Sent: Thursday, August 3, 2017 7:17 PM
To: Dave Dolson <ddolson@sandvine.com>; dots@ietf.org
Subject: Re: [Dots] Some notes on ietf-dots-signal-channel-02

 

I know I sent this at = a busy time, so perhaps it was forgotten. Would the authors care to comment= on the points below?

 

-Dave

 

 

From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Dave Dolson
Sent: Wednesday, July 19, 2017 10:36 PM
To: dots@ietf.org
Subject: [Dots] Some notes on ietf-dots-signal-channel-02

 

Generally I think the document is pretty good, but I= found a number of questions and nits.

 

BTW, is this document in github? I was going to make= a pull request, but couldn’t find it.

 

 

For target-protocol, I think could be clarified usin= g this reference: https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml

 

There is missing information about some filters:

fqdn: which FQDN is supposed to go here? I’m u= nclear on what would be mitigated? DNS? HTTP?

 

uri: does this mean an HTTP resource is under attack= ? It doesn’t say HTTP.

 

lifetime:  I recommend a very large number be u= sed for no timeout. (this might be a pet peeve of mine, but why do people l= ike to use 0 to mean infinite?)  I think in the future we might want t= o use 0 to mean “end now”.

 

 

CBOR supports binary byte strings. Therefore I sugge= st that IP addresses be represented as 4-byte or 16-byte byte-strings rathe= r than the bulkier human-readable strings that may require ~40 bytes.<= /o:p>

However, then prefixes would be represented like: &q= uot;target-prefix": [ {"prefix": byte-string[16], "leng= th": integer}]

 

At this time I also suggest supporting IPv4-mapped-v= 6 addresses to unify IPv4 and IPv6 code.

 

Although multiple mitigation-ids may be set, this wo= rding confused me:

   If two mitigation requests<= /p>

   have overlapping mitigation scopes the mitiga= tion request with higher

   numeric mitigation-id value will override the= mitigation request with

   a lower numeric mitigation-id value

This sounds like higher-valued IDs are supposed to r= eplace smaller values. But that isn’t intended, I don’t think. = Both mitigation-IDs should be stored, but that comment is about logic in sc= rubbing rules and attributing bytes-dropped.

 

I think there may be a race condition to consider, w= hen we allow for reordering:

If this sequence is sent:

  PUT  (ID=3D1)

  PUT (ID=3D1)

  DELETE (ID=3D1)

But this sequence is received:

  PUT (ID=3D1)

  DELETE (ID=3D1)

  PUT  (ID=3D1)

Then the ID 1 will be incorrectly stored. The soluti= on is that the server needs to remember deleted IDs for some time.

 

The URIs for PUT and DELETE are specified differentl= y (v1 and version). I suspect they are intended to be the same, probably &#= 8220;v1” ?

 

Currently the DELETE is specified to return an error= if deleting something not found. What is the value of this error? Why not = always return 2.02, thereby giving DELETE idempotent behavior.

 

Regarding the 5min timeout after client DELETE, did = we consider making that configurable in the delete message? This could allo= w a client to be a bit smarter. If timeout=3D0, it would mean stop right no= w.

 

I’m unclear on how I would determine bps-dropp= ed or pps-dropped. What time denominator? (Generally I find rate measuremen= ts very difficult to compute and explain in a way that makes everyone happy= .) Can we just let the client compute bytes/time ?

 

The –dropped counters show a clear bias toward= s scrubbers that simply drop packets. Are there other actions to be conside= red? E.g., DSCP marking?

 

Regarding “status”, I’m unclear on= what code 2 means. It sounds like all traffic is being dropped, but I don&= #8217;t consider that the most successful outcome. I think it might be bett= er to say “Mitigation is in progress within capability” (in contrast to “exceeded capability” code 4).

 

Regarding “observe” It says,<= /p> 

    A DOTS client that is no longer
   interested in receiving notifications from the DOTS serve=
r can simply
   "forget" the observation.

More specifically, doesn’t it have to make the= request with “Observe=3D1” ?

 

I think there may be some race conditions with the &= #8220;observe” option.

E.g., these messages reordered:

  Observe=3D0

  Observe=3D1

I’m not sure what the solution is. (I didnR= 17;t really read RFC7641 to see if it was discussed)

 

The efficacy update seems to use the same URI as the= one for requesting mitigation. How would the server know which type of mes= sage? I suspect we intended to use a different URI.

Scanning the document, a second look at all of the U= RIs might be in order. We want the URI to indicate the type of operation, n= ot inferred from the content of the body.

 

Regarding heartbeat, what are the consequences of fa= ilure? I’m unclear on what action should be taken.

Please note that when under attack, round-trip times= might be VERY large due to buffer bloat. A colleague of mine measured ping= times exceeding 60s in a hotel!

 

On that note, should we give guidance about applicat= ion-layer time-outs? A na=EFve implementation might pick something like 5s = timeout. A client should be trying multiple transports and therefore have a= n async approach to writing the application.

 

5.4.2 Configuration: why is this a POST?  I thi= nk this should be PUT, like the others, since the intent is to replace prev= ious configuration.

 

Regarding redirected signaling, where do you get res= ponse code 3.00 from? It isn’t listed in https://tool= s.ietf.org/html/rfc7252#section-12.1.2 or https://www.iana.org/assignments/core-parameters/core-parameters.xhtml#resp= onse-codes  .  Can we use 3.00, or is there a reference you c= an add to the doc?

 

Do we intend to prohibit large datagrams that will b= e fragmented? These are not terrible, just perhaps less likely to all arriv= e. I think the wording should say that multiple mitigation requests should = be created to keep the datagram size small.

 

(I didn’t read the security sections in detail= , expecting them to change.)

 

It looks like a lot of issues, but I think the comme= nts are only possible because the document is good enough by having details= .

 

[Tip: track github issues for the points I’ve = raised, if you cannot answer/resolve them immediately]

-Dave

 

 

--_000_DM5PR16MB1788861B3EF5AA61B6F2D09EEAB10DM5PR16MB1788namp_-- From nobody Fri Aug 4 06:59:18 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D45DB131F6A for ; Fri, 4 Aug 2017 06:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T_9dQPxmvVMz for ; Fri, 4 Aug 2017 06:59:15 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 164F41321C8 for ; Fri, 4 Aug 2017 06:59:12 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1ddd8A-0001Je-Go for ietf-supjps-dots@ietf.org; Fri, 04 Aug 2017 14:59:10 +0100 From: "Jon Shallow" To: Date: Fri, 4 Aug 2017 14:59:12 +0100 Message-ID: <063901d30d29$d9e5e9a0$8db1bce0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_063A_01D30D32.3BAAC6D0" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AdMNKdnJaqWYwakYSYmCn57AxDvOHg== Archived-At: Subject: [Dots] draft-ietf-dots-data-channel - ietf-dots-access-control-list extensions X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 13:59:17 -0000 This is a multipart message in MIME format. ------=_NextPart_000_063A_01D30D32.3BAAC6D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Does it make sense to add to the extensions of ietf-dots-access-control-list the ability to black list or possibly white list, Country Codes and AS numbers? Regards Jon ------=_NextPart_000_063A_01D30D32.3BAAC6D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Does it = make sense to add to the extensions of ietf-dots-access-control-list the = ability to black list or possibly white list, Country Codes and AS = numbers?

 

Regards

 

Jon

------=_NextPart_000_063A_01D30D32.3BAAC6D0-- From nobody Fri Aug 4 10:02:37 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 023DF1323FC for ; Fri, 4 Aug 2017 10:02:35 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z3jeK21WoQNX for ; Fri, 4 Aug 2017 10:02:33 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::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 12B1B13239D for ; Fri, 4 Aug 2017 10:02:33 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id c28so9357276pfe.3 for ; Fri, 04 Aug 2017 10:02:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TPDf+st8Tdw0MMFdwS0PB8gdrCPNWmcIY/EZTxBjWfU=; b=vfnDWh14aFPjMcPAw/fjS/G2SH3jEPQhL0KDDjWxQSl2vUIgM9jZjLwMMyCc6lNftE Mir/cbDC0PSi3szzQD6QXksYlo+WDr6ECxC5JBfoLTumBxwBCFAcYMu4/aICMngaP8GG G/uIk/i7x1W1rKkGaE3heVJ4LvzNi0pflwm0/cBiGPPqIB7M/ddIb28cOZdrXZdDskka IhTpKzcbTMBjo4Um7FTxW6f2jp+RuFcKuU5TrVFlMbjXtk3yPlqeQyhiDSCJnsQEDQcC lzb49/S8lsoYV2j9PTPH+cARBbLWRe6kGpoTiv+zmkmuVd7f7aA9qwoxcl4U3T72Uc8s oJ8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TPDf+st8Tdw0MMFdwS0PB8gdrCPNWmcIY/EZTxBjWfU=; b=M1M9Trvr0h6wVmAha2xiEy3fnJac694Aje63HWOiQiu/HIlS0Mjz2ObfKkIcuKcQJT Um168zC2HqO+tqt0nZWLXLBTyziFFF0HryMEpLCqVBLf7S/I3B9MTY7PpH2l0KxGkTNp z9T35nQ3OyBBR0zLNK1ccYs/GPvTTFMU3aHgAXVn9CCmU3vD0AOvUKZsGPNH3t248nfy H74rOrtQOBVRaJS7TZZIZjXzEHakrVxj0h6zkrIm/nzISggmR3gCLSa01snwdizrzyo9 PU2f8rRsSHeEXUPUCeFFGehnFZ63Hn45ttnjS4iSir5jlE2++eWzG8UTkTVTJuIUMrA5 GB2w== X-Gm-Message-State: AIVw113B0uTXc7S8b4/kHlvft1KRGK4kch/zcfvEZy+IjiNzIeCW0Fd3 YYCJ4FJLif1ht2J6d2/vTVeoT5dSRg== X-Received: by 10.98.61.13 with SMTP id k13mr3127543pfa.75.1501866152515; Fri, 04 Aug 2017 10:02:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.133.150 with HTTP; Fri, 4 Aug 2017 10:02:31 -0700 (PDT) Received: by 10.100.133.150 with HTTP; Fri, 4 Aug 2017 10:02:31 -0700 (PDT) In-Reply-To: <063901d30d29$d9e5e9a0$8db1bce0$@jpshallow.com> References: <063901d30d29$d9e5e9a0$8db1bce0$@jpshallow.com> From: Artyom Gavrichenkov Date: Fri, 4 Aug 2017 20:02:31 +0300 Message-ID: To: Jon Shallow Cc: dots@ietf.org Content-Type: multipart/alternative; boundary="94eb2c12826c855db90555f07627" Archived-At: Subject: Re: [Dots] draft-ietf-dots-data-channel - ietf-dots-access-control-list extensions X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 17:02:35 -0000 --94eb2c12826c855db90555f07627 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jon, Personally, I don't think this is a good idea. Here are my reasons. Neither a country code nor an AS number (be the latter a current BGP Origin attribute value, as seen by a mitigator, or simply an entry in a RIR DB) are present in the network and transport layer header data. Both are often meant to be taken from some foreign key-value stores of disputable quality. LIRs often, to say the least, tend to underestimate the importance of updating their data in their respective RIR databases (see, I'm trying to put it gently). In turn, those databases are now often considered as unreliable sources of information sometimes even when it comes to routing data. With geographic data (which is not used for routing purposes and thus never gets verified), everything is much, much worse. There are organisations (MaxMind, IPIP and others) which maintain their own, proprietary geo databases, in proprietary formats, which are still far from ideal, but suitable enough for purposes of, say, measuring statistics. Yet, most of those databases are not good enough for the means of preventing access because of a high rate of both false positives and false negatives. Here's a recent case: https://github.com/ docker/for-linux/issues/57#issuecomment-314476406 So as there's no "official" geoblocking method, a proposed extension should explicitly specify which exactly database should be used. Now it seems to be better for the user of a DOTS client to implement an access to such databases (be it MaxMind, RIPE DB, Spamhaus or whatever key-value store a user chooses) theirselves, while a DOTS server would only see the final resolution on an IP address or network. | Artyom Gavrichenkov | gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191 | mailto: ximaera@gmail.com | fb: ximaera | telegram: xima_era | skype: xima_era | tel. no: +7 916 515 49 58 4 =D0=B0=D0=B2=D0=B3. 2017 =D0=B3. 4:59 PM =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7= =D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C "Jon Shallow" =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB: > Does it make sense to add to the extensions of > ietf-dots-access-control-list the ability to black list or possibly white > list, Country Codes and AS numbers? > > > > Regards > > > > Jon > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > > --94eb2c12826c855db90555f07627 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jon,

Pers= onally, I don't think this is a good idea. Here are my reasons.

Neither a country code nor an A= S number (be the latter a current BGP Origin attribute value, as seen by a = mitigator, or simply an entry in a RIR DB) are present in the network and t= ransport layer header data. Both are often meant to be taken from some fore= ign key-value stores of disputable quality.

LIRs often, to say the least, tend to underestimate the= importance of updating their data in their respective RIR databases (see, = I'm trying to put it gently). In turn, those databases are now often co= nsidered as unreliable sources of information sometimes even when it comes = to routing data. With geographic data (which is not used for routing purpos= es and thus never gets verified), everything is much, much worse.

There are organisations (MaxMind,= IPIP and others) which maintain their own, proprietary geo databases, in p= roprietary formats, which are still far from ideal, but suitable enough for= purposes of, say, measuring statistics. Yet, most of those databases are n= ot good enough for the means of preventing access because of a high rate of= both false positives and false negatives. Here's a recent case:=C2=A0<= a href=3D"https://github.com/docker/for-linux/issues/57#issuecomment-314476= 406" target=3D"_blank">https://github.com/docker/for-linux/issues/57#<= wbr>issuecomment-314476406

So as there's no "official" geoblocking method, a prop= osed extension should explicitly specify which exactly database should be u= sed. Now it seems to be better for the user of a DOTS client to implement a= n access to such databases (be it MaxMind, RIPE DB, Spamhaus or whatever ke= y-value store a user chooses) theirselves, while a DOTS server would only s= ee the final resolution on an IP address or network.

| Artyom Gavriche= nkov
| gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191
| mailt= o:=C2=A0ximaera@gmai= l.com
| fb: ximaera
| telegram: xima_era
| skype: xima_era
= | tel. no: +7 916 515 49 58


4 =D0=B0=D0=B2=D0=B3. 2017 =D0=B3.= 4:59 PM =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB= =D1=8C "Jon Shallow" <supjps-ietf@jpshallow.com> =D0=BD=D0=B0=D0=BF= =D0=B8=D1=81=D0=B0=D0=BB:

Does it m= ake sense to add to the extensions of ietf-dots-access-control-list the abi= lity to black list or possibly white list, Country Codes and AS numbers?=

=C2=A0

Regards

=C2=A0<= /u>

Jon


________= _______________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots

--94eb2c12826c855db90555f07627-- From nobody Sun Aug 6 17:52:28 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4489E12426E for ; Sun, 6 Aug 2017 17:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Fq0ZKN2eKik for ; Sun, 6 Aug 2017 17:52:25 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44330124B0A for ; Sun, 6 Aug 2017 17:52:25 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DMB22266; Mon, 07 Aug 2017 00:52:23 +0000 (GMT) Received: from DGGEML403-HUB.china.huawei.com (10.3.17.33) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 7 Aug 2017 01:52:22 +0100 Received: from DGGEML502-MBX.china.huawei.com ([169.254.2.84]) by DGGEML403-HUB.china.huawei.com ([fe80::74d9:c659:fbec:21fa%31]) with mapi id 14.03.0301.000; Mon, 7 Aug 2017 08:52:18 +0800 From: "Xialiang (Frank)" To: "Dots@ietf.org" Thread-Topic: Can DOTS protocol support IP whitelist for DOTS client's AA? Thread-Index: AdMPF2QONmutCNOvSwe0CfD0yMkBTg== Date: Mon, 7 Aug 2017 00:52:18 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.159.76] Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F12BB2D185DGGEML502MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.5987B9C7.00BE, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.84, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: f2ef8d95952cfd0368736bad9e385c7a Archived-At: Subject: [Dots] Can DOTS protocol support IP whitelist for DOTS client's AA? X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 00:52:27 -0000 --_000_C02846B1344F344EB4FAA6FA7AF481F12BB2D185DGGEML502MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I think the direct use of IP whitelist on the DOTS server to authenticate a= nd authorize the DOTS client is a simple and effect method, at least in som= e special use cases, like: DOTS client does not support certificate, an ISP= which detects the spoofed source address, etc. So, should we support this as an optional way for the DOTS client's AA and = add it into the DOTS protocol drafts? B.R. Frank --_000_C02846B1344F344EB4FAA6FA7AF481F12BB2D185DGGEML502MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I think the direct use of IP wh= itelist on the DOTS server to authenticate and authorize the DOTS client is= a simple and effect method, at least in some special use cases, like: DOTS= client does not support certificate, an ISP which detects the spoofed source address, etc.

 

So, should we support this as a= n optional way for the DOTS client’s AA and add it into the DOTS prot= ocol drafts?

 

B.R.

Frank

--_000_C02846B1344F344EB4FAA6FA7AF481F12BB2D185DGGEML502MBXchi_-- From nobody Sun Aug 6 17:55:12 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19CFC124B0A for ; Sun, 6 Aug 2017 17:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MjZYsyHXyZv0 for ; Sun, 6 Aug 2017 17:55:09 -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 2694C1204DA for ; Sun, 6 Aug 2017 17:55:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML711-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DSV53009; Mon, 07 Aug 2017 00:55:07 +0000 (GMT) Received: from DGGEML401-HUB.china.huawei.com (10.3.17.32) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 7 Aug 2017 01:55:06 +0100 Received: from DGGEML502-MBX.china.huawei.com ([169.254.2.84]) by DGGEML401-HUB.china.huawei.com ([fe80::89ed:853e:30a9:2a79%31]) with mapi id 14.03.0301.000; Mon, 7 Aug 2017 08:55:01 +0800 From: "Xialiang (Frank)" To: "Dots@ietf.org" Thread-Topic: =?gb2312?B?YW5vdGhlciBvcHRpb246Ly+08Li0OiBDYW4gRE9UUyBwcm90b2NvbCBzdXBw?= =?gb2312?Q?ort_IP_whitelist_for_DOTS_client's_AA=3F?= Thread-Index: AdMPF2QONmutCNOvSwe0CfD0yMkBTgAACUnw Date: Mon, 7 Aug 2017 00:55:01 +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.134.159.76] Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F12BB2D19BDGGEML502MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.5987BA6B.0055, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.84, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 45f288cdc0c9361d199308c62de4f025 Archived-At: Subject: [Dots] =?gb2312?b?YW5vdGhlciBvcHRpb246Ly+08Li0OiBDYW4gRE9UUyBw?= =?gb2312?b?cm90b2NvbCBzdXBwb3J0IElQIHdoaXRlbGlzdCBmb3IgRE9UUyBjbGllbnQn?= =?gb2312?b?cyBBQT8=?= X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 00:55:11 -0000 --_000_C02846B1344F344EB4FAA6FA7AF481F12BB2D19BDGGEML502MBXchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SW4gYWRkaXRpb24gdG8gSVAgd2hpdGVsaXN0IGFuZCBjZXJ0aWZpY2F0ZSwgcHJlLXNoYXJlIGtl eSBjYW4gYWxzbyBiZSBhbiBvcHRpb24uDQpSaWdodD8NCg0Kt6K8/sjLOiBEb3RzIFttYWlsdG86 ZG90cy1ib3VuY2VzQGlldGYub3JnXSC0+rHtIFhpYWxpYW5nIChGcmFuaykNCreiy83KsbzkOiAy MDE3xOo41MI3yNUgODo1Mg0KytW8/sjLOiBEb3RzQGlldGYub3JnDQrW98ziOiBbRG90c10gQ2Fu IERPVFMgcHJvdG9jb2wgc3VwcG9ydCBJUCB3aGl0ZWxpc3QgZm9yIERPVFMgY2xpZW50J3MgQUE/ DQoNCkhpLA0KSSB0aGluayB0aGUgZGlyZWN0IHVzZSBvZiBJUCB3aGl0ZWxpc3Qgb24gdGhlIERP VFMgc2VydmVyIHRvIGF1dGhlbnRpY2F0ZSBhbmQgYXV0aG9yaXplIHRoZSBET1RTIGNsaWVudCBp cyBhIHNpbXBsZSBhbmQgZWZmZWN0IG1ldGhvZCwgYXQgbGVhc3QgaW4gc29tZSBzcGVjaWFsIHVz ZSBjYXNlcywgbGlrZTogRE9UUyBjbGllbnQgZG9lcyBub3Qgc3VwcG9ydCBjZXJ0aWZpY2F0ZSwg YW4gSVNQIHdoaWNoIGRldGVjdHMgdGhlIHNwb29mZWQgc291cmNlIGFkZHJlc3MsIGV0Yy4NCg0K U28sIHNob3VsZCB3ZSBzdXBwb3J0IHRoaXMgYXMgYW4gb3B0aW9uYWwgd2F5IGZvciB0aGUgRE9U UyBjbGllbnShr3MgQUEgYW5kIGFkZCBpdCBpbnRvIHRoZSBET1RTIHByb3RvY29sIGRyYWZ0cz8N Cg0KQi5SLg0KRnJhbmsNCg== --_000_C02846B1344F344EB4FAA6FA7AF481F12BB2D19BDGGEML502MBXchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

In addi= tion to IP whitelist and certificate, pre-share key can also be an option.<= o:p>

Right?<= o:p>

&n= bsp;

=B7=A2=BC=FE=C8=CB: Dots [mailto:dots-bounces@ietf.org] =B4=FA=B1=ED = Xialiang (Frank)
=B7=A2=CB=CD= =CA=B1=BC=E4: 2017=C4=EA8=D4=C2<= span lang=3D"EN-US">7=C8=D5 8:52
=CA=D5=BC=FE=C8=CB: Dots@ietf.org
=D6=F7=CC=E2: [Dots] Can DOTS protocol support IP whitelist for DOTS client's AA?<= /o:p>

 

Hi,

I think the direct use of IP wh= itelist on the DOTS server to authenticate and authorize the DOTS client is= a simple and effect method, at least in some special use cases, like: DOTS= client does not support certificate, an ISP which detects the spoofed source address, etc.

 

So, should we support this as a= n optional way for the DOTS client=A1=AFs AA and add it into the DOTS proto= col drafts?

 

B.R.

Frank

--_000_C02846B1344F344EB4FAA6FA7AF481F12BB2D19BDGGEML502MBXchi_-- From nobody Sun Aug 6 19:04:26 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 972A2124BAC for ; Sun, 6 Aug 2017 19:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztm5-1GAHc1d for ; Sun, 6 Aug 2017 19:04:23 -0700 (PDT) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EC081243F6 for ; Sun, 6 Aug 2017 19:04:20 -0700 (PDT) Received: by mail-pg0-x235.google.com with SMTP id u5so28027110pgn.0 for ; Sun, 06 Aug 2017 19:04:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=I7cOotPnuCxjXG1GKyEs+dodsKvBEvUFL9heKGdM9WE=; b=kz6DdFBiVeFSfFKLVJsGFOS/b4h37X58V9UIMFzUcjZoyrcE2fOmoVnmRl8vSqaYwZ 2xlV1BI7M6atwwugCwx5EwzshJvbmkBCS2NcaJbXdv0i5kU4KYwUs6Q0W+XTGGeExD72 hy722tU3xq1Ax0+zo/wEerrNMvj3IvMu2pUvDFZCMCSZjfN/5OB3YLLZaaCTAJO3YKei uRNZkapKRNrlmbAvMj1m5rmEnygBx/dCXNzK7LCYndXVM1SskksrUuYzpt+aLhzJFwcA zAR7JV6ppQGJ36o5oK01UOfGOgEqmv6w7ftJPEiItnXvm61JI6Xlea+NnQgEZAUzwLYD OgGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=I7cOotPnuCxjXG1GKyEs+dodsKvBEvUFL9heKGdM9WE=; b=cvqwFRUjwxGIOImDSzE0JNh3gQ4N9+cwLsXMaVMDb6ne9in6jdvXQTQ37oel3xLVOr xM6DcjqCxn0/HtAUd1YvY423ZnRM4M39mmQl7tdTcadrQJ3sFmyMvPBZViNIjYaZ0Sxt P7fRdI1d1ql7izJtP4cv/VelNyRqbvMWo5knu/jdgkImi4E5kcw3LnES1SQH0Jj25CBC HhcS1LXkshF52tcYKPm+i8id8bLOgJpETV2VW6zvHg/jeZPlpIws0ph8BFbJGG8GfPFI NMOSNjDJP1vdtTaLZE4c/Kk3fZFF74QJu7jhFSBRI9vDdlcOOG3v09xmhdgjZHdBNLBe cWhg== X-Gm-Message-State: AIVw113cmT9TNq7KxsIXlQvLckPROcySxYkrV6pmf4o0C4HhpZ7HQqCd edREnhLtemPloV6aC9nOieIBHZxUSy4WwaE= X-Received: by 10.84.132.129 with SMTP id e1mr12171223ple.316.1502071459851; Sun, 06 Aug 2017 19:04:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.133.150 with HTTP; Sun, 6 Aug 2017 19:03:59 -0700 (PDT) In-Reply-To: References: From: Artyom Gavrichenkov Date: Mon, 7 Aug 2017 05:03:59 +0300 Message-ID: To: "Xialiang (Frank)" Cc: "Dots@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Dots] Can DOTS protocol support IP whitelist for DOTS client's AA? X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 02:04:26 -0000 Hi there, Current DOTS requirements draft goes to great lengths to protect a DOTS connection from a passive attacker capturing packets on the way from a client to a server and back (SEC-001, SEC-002, SEC-003, DATA-002). One can come up with a handful of use cases where it's important. Enabling a DOTS server to skip the certificate auth in favour of the simple IP auth obviously violates this requirement. Moreover, given recent ongoing research attempts on spoofing TCP connections with either PRNG prediction or simple brute force ([1], [2]) -- and yes, it's still rather easy to protect a network service from such attacks, but it's currently not required from a DOTS server to implement such protection -- I'd further say the IP auth sans decent encryption is not suitable for a network service like that. But of course that may be only me. [1] http://lgms.nl/blog-7 [2] https://security.stackexchange.com/questions/107036/didnt-understood-wh= at-the-purpose-of-the-newly-discovered-tcp-faking-attack | Artyom Gavrichenkov | gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191 | mailto: ximaera@gmail.com | fb: ximaera | telegram: xima_era | skype: xima_era | tel. no: +7 916 515 49 58 On Mon, Aug 7, 2017 at 3:52 AM, Xialiang (Frank) wrote: > Hi, > > I think the direct use of IP whitelist on the DOTS server to authenticate > and authorize the DOTS client is a simple and effect method, at least in > some special use cases, like: DOTS client does not support certificate, a= n > ISP which detects the spoofed source address, etc. > > > > So, should we support this as an optional way for the DOTS client=E2=80= =99s AA and > add it into the DOTS protocol drafts? > > > > B.R. > > Frank > > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > From nobody Mon Aug 7 02:50:55 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE097132195 for ; Mon, 7 Aug 2017 02:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBAV6CjBmtIO for ; Mon, 7 Aug 2017 02:50:51 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 C1996132190 for ; Mon, 7 Aug 2017 02:50:44 -0700 (PDT) Received: from MIVEXAPP1N02.corpzone.internalzone.com (unknown [10.48.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp id 6ddc_6502_4291cd88_f97f_4801_bb5e_a30705acbff9; Mon, 07 Aug 2017 04:50:33 -0500 Received: from MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) by MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 7 Aug 2017 05:50:32 -0400 Received: from MIVO365EDGE3.corpzone.internalzone.com (10.48.176.86) by MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) with Microsoft SMTP Server (TLS) id 15.0.1263.5 via Frontend Transport; Mon, 7 Aug 2017 05:50:32 -0400 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (10.48.176.243) by edge.mcafee.com (10.48.176.86) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 7 Aug 2017 05:50:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.onmicrosoft.com; s=selector1-mcafee-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KHYR1YFeWdVmdOXDQo1guSCYOKI54cp5ZTh2qsT61Hs=; b=RZ0KUCE56/sBNRLo8JZsnGvll/wYL3H2PAZ2PkLb1JdewxLTZP8x2lSw7D3iL2SjTRLucNTIytoV3oBF72Hyzgw5c7VvHI9N2EGfOFERdDS0a5QkDsJqlxRB1Jv4XgZsoStR64fWp0/wfU7nMo/mvVx6bVmb+RHO3f4JfsF8SBY= Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1786.namprd16.prod.outlook.com (10.172.44.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1320.16; Mon, 7 Aug 2017 09:50:31 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.01.1320.018; Mon, 7 Aug 2017 09:50:31 +0000 From: "Konda, Tirumaleswar Reddy" To: "Xialiang (Frank)" , "Dots@ietf.org" Thread-Topic: =?utf-8?B?YW5vdGhlciBvcHRpb246Ly/nrZTlpI06IENhbiBET1RTIHByb3RvY29sIHN1?= =?utf-8?Q?pport_IP_whitelist_for_DOTS_client's_AA=3F?= Thread-Index: AdMPF2QONmutCNOvSwe0CfD0yMkBTgAACUnwAA6poPA= Date: Mon, 7 Aug 2017 09:50:31 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1786; 6:jvzAC3NZnNEqks+v0jajuPzkXpxswtLIRRfrMJErjpsFam1I/HiEIrT1mF4lu8CT6TV2U4qpmZD2UWdD4RYVajdjbG34z9M+qbpIoKIgaxlgC2HIXj2PhIEO3uE5Yeev+TaT50C7YfVUdy8tAzsAr8Dda6SOXehwWwrGqGycuW39svtPYHI8YmZ6bhIfWfjB1lfx79dL7cOVAHnSbJ7LslyayiaUyVFHmjnTW182LFLvQIZTK/yc0YbPlTYL6eT1Nr8w3hGzQzyAXugrBJGqAZCwVYCAPdBXrncOxWX+aIPs0viuFcxK+iMOK06pf7Mx5ibfpU91rnCqfIRpegs2cQ==; 5:hhTnroNt0PvJN8SK4H69cDv56XqcTr5N39AbjMjv+p8q7hWQh4NiwQVgDDa70iIoVcNlPGnhh+ymdqJqWZ3PLiUMte6E8p+gYTz5S4li6Sc1UqHfCiWvNPEnahepHWnYp4H7Xa5NBpmNTBIJTZCRcg==; 24:r84FBiWpkeEZ62EuNCAE8/ZXtYTomW+L8y99xG31qstRNGSzdrxeP2PxHMXuTfzpXlNOeJtDdfpPbA4OSnZ5hYZOrW+YOZnzHoAdgUKqkjA=; 7:DduFO85FcgoYXDGbWA5uLq8pH+xIBPtzpo/bsxrXSK5j2Ndic5ZPbyqbe4VlCBmlaWuDBnIwHeUDBt55/Yua421sgazKP92XViK8KFZFUEA6UA0o6HCZQJX4TVFll1mUwzl4cL/hMxmbwAMq0kUE+CNvAFywUsGlLB8PYD59jT2Mz9oNHmm/uuF8ulYPFk3oyvfK4xyADaFLyTQobBjo6YFwSxyq4MnIve1N3BHz35E= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 1eacf68e-90f2-4c29-5c03-08d4dd79bde5 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM5PR16MB1786; x-ms-traffictypediagnostic: DM5PR16MB1786: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123560025)(20161123558100)(20161123564025)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1786; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1786; x-forefront-prvs: 0392679D18 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(39850400002)(39840400002)(39450400003)(39410400002)(39400400002)(199003)(377454003)(189002)(32952001)(97736004)(80792005)(8936002)(790700001)(6116002)(102836003)(81156014)(81166006)(3846002)(2900100001)(53936002)(86362001)(6436002)(7736002)(6306002)(54896002)(9686003)(2501003)(236005)(3280700002)(53546010)(99286003)(66066001)(224303003)(7696004)(25786009)(6246003)(105586002)(6506006)(74316002)(77096006)(189998001)(101416001)(38730400002)(106356001)(5660300001)(33656002)(478600001)(55016002)(54356999)(76176999)(50986999)(229853002)(14454004)(68736007)(72206003)(3660700001)(2950100002)(2906002)(85282002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1786; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB17880F012FB44009155ADCA1EAB50DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Aug 2017 09:50:31.2007 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1786 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.9 X-NAI-Spam-Version: 2.3.0.9418 : core <6087> : inlines <6011> : streams <1757537> : uri <2478131> Archived-At: Subject: Re: [Dots] =?utf-8?b?YW5vdGhlciBvcHRpb246Ly/nrZTlpI06IENhbiBET1RT?= =?utf-8?q?_protocol_support_IP_whitelist_for_DOTS_client=27s_AA=3F?= X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 09:50:53 -0000 --_000_DM5PR16MB17880F012FB44009155ADCA1EAB50DM5PR16MB1788namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VExTIHN1cHBvcnRzIHByZS1zaGFyZWQga2V5IGJhc2VkIGF1dGhlbnRpY2F0aW9uLiBUaGUgb3Ro ZXIgbWVjaGFuaXNtcyBhcmUgU3ViamVjdCBQdWJsaWMgS2V5IEluZm8gKFNQS0kpIEZpbmdlcnBy aW50IHBpbiBzZXQgZm9yIG11dHVhbCBhdXRoZW50aWNhdGlvbiAoc2VsZi1zaWduZWQgY2VydGlm aWNhdGVzIG9yIHJhdyBwdWJsaWMga2V5cykgd2l0aG91dCBoYXZpbmcgdG8gZGVhbCB3aXRoIENB Lg0KDQpJIGRvbuKAmXQgdGhpbmsgRE9UUyBzaG91bGQgcmVsYXggdGhlIG11dHVhbCBhdXRoZW50 aWNhdGlvbiBhbmQgZW5jcnlwdGlvbiByZXF1aXJlbWVudHMuDQoNCi1USXJ1DQoNCkZyb206IERv dHMgW21haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBYaWFsaWFuZyAo RnJhbmspDQpTZW50OiBNb25kYXksIEF1Z3VzdCA3LCAyMDE3IDY6MjUgQU0NClRvOiBEb3RzQGll dGYub3JnDQpTdWJqZWN0OiBbRG90c10gYW5vdGhlciBvcHRpb246Ly/nrZTlpI06IENhbiBET1RT IHByb3RvY29sIHN1cHBvcnQgSVAgd2hpdGVsaXN0IGZvciBET1RTIGNsaWVudCdzIEFBPw0KDQpJ biBhZGRpdGlvbiB0byBJUCB3aGl0ZWxpc3QgYW5kIGNlcnRpZmljYXRlLCBwcmUtc2hhcmUga2V5 IGNhbiBhbHNvIGJlIGFuIG9wdGlvbi4NClJpZ2h0Pw0KDQrlj5Hku7bkuro6IERvdHMgW21haWx0 bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBYaWFsaWFuZyAoRnJhbmspDQrlj5HpgIHm l7bpl7Q6IDIwMTflubQ45pyIN+aXpSA4OjUyDQrmlLbku7bkuro6IERvdHNAaWV0Zi5vcmc8bWFp bHRvOkRvdHNAaWV0Zi5vcmc+DQrkuLvpopg6IFtEb3RzXSBDYW4gRE9UUyBwcm90b2NvbCBzdXBw b3J0IElQIHdoaXRlbGlzdCBmb3IgRE9UUyBjbGllbnQncyBBQT8NCg0KSGksDQpJIHRoaW5rIHRo ZSBkaXJlY3QgdXNlIG9mIElQIHdoaXRlbGlzdCBvbiB0aGUgRE9UUyBzZXJ2ZXIgdG8gYXV0aGVu dGljYXRlIGFuZCBhdXRob3JpemUgdGhlIERPVFMgY2xpZW50IGlzIGEgc2ltcGxlIGFuZCBlZmZl Y3QgbWV0aG9kLCBhdCBsZWFzdCBpbiBzb21lIHNwZWNpYWwgdXNlIGNhc2VzLCBsaWtlOiBET1RT IGNsaWVudCBkb2VzIG5vdCBzdXBwb3J0IGNlcnRpZmljYXRlLCBhbiBJU1Agd2hpY2ggZGV0ZWN0 cyB0aGUgc3Bvb2ZlZCBzb3VyY2UgYWRkcmVzcywgZXRjLg0KDQpTbywgc2hvdWxkIHdlIHN1cHBv cnQgdGhpcyBhcyBhbiBvcHRpb25hbCB3YXkgZm9yIHRoZSBET1RTIGNsaWVudOKAmXMgQUEgYW5k IGFkZCBpdCBpbnRvIHRoZSBET1RTIHByb3RvY29sIGRyYWZ0cz8NCg0KQi5SLg0KRnJhbmsNCg== --_000_DM5PR16MB17880F012FB44009155ADCA1EAB50DM5PR16MB1788namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6RGVuZ1hpYW47DQoJcGFub3NlLTE6MiAxIDYg MCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFu b3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToi XEBEZW5nWGlhbiI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEg MTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwg ZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgl0 ZXh0LWFsaWduOmp1c3RpZnk7DQoJdGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaDsNCglmb250 LXNpemU6MTAuNXB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGlu aywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJs dWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlw ZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFs MCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6U2ltU3VuO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3Rl eHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVt YWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjI1aW4gMS4waW4gMS4yNWluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiIHN0eWxlPSJ0ZXh0LWp1c3RpZnktdHJpbTpwdW5jdHVhdGlvbiI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPlRMUyBzdXBwb3J0cyBwcmUtc2hhcmVkIGtleSBiYXNlZCBhdXRoZW50aWNh dGlvbi4gVGhlIG90aGVyIG1lY2hhbmlzbXMgYXJlIFN1YmplY3QgUHVibGljIEtleSBJbmZvIChT UEtJKSBGaW5nZXJwcmludCBwaW4gc2V0IGZvciBtdXR1YWwgYXV0aGVudGljYXRpb24gKHNlbGYt c2lnbmVkIGNlcnRpZmljYXRlcyBvciByYXcgcHVibGljIGtleXMpIHdpdGhvdXQNCiBoYXZpbmcg dG8gZGVhbCB3aXRoIENBLiAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPkkgZG9u4oCZdCB0aGluayBET1RTIHNob3VsZCByZWxheCB0aGUgbXV0dWFsIGF1 dGhlbnRpY2F0aW9uIGFuZCBlbmNyeXB0aW9uIHJlcXVpcmVtZW50cy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPi1USXJ1PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxz cGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48L3NwYW4+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0Ij48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij4gRG90cyBbbWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZ10N CjxiPk9uIEJlaGFsZiBPZiA8L2I+WGlhbGlhbmcgKEZyYW5rKTxicj4NCjxiPlNlbnQ6PC9iPiBN b25kYXksIEF1Z3VzdCA3LCAyMDE3IDY6MjUgQU08YnI+DQo8Yj5Ubzo8L2I+IERvdHNAaWV0Zi5v cmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW0RvdHNdIGFub3RoZXIgb3B0aW9uOi8vPC9zcGFuPjxz cGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpTaW1T dW4iPuetlOWkjTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+OiBDYW4gRE9U UyBwcm90b2NvbCBzdXBwb3J0IElQIHdoaXRlbGlzdCBmb3IgRE9UUyBjbGllbnQncyBBQT88bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg YWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkluIGFk ZGl0aW9uIHRvIElQIHdoaXRlbGlzdCBhbmQgY2VydGlmaWNhdGUsIHByZS1zaGFyZSBrZXkgY2Fu IGFsc28gYmUgYW4gb3B0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5SaWdodD88L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGln bjpsZWZ0Ij48Yj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6U2ltU3VuIj7lj5Hku7bkuro8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4gRG90cw0KIFs8YSBocmVmPSJt YWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3Jn PC9hPl0gPGI+PHNwYW4gbGFuZz0iWkgtQ04iPuS7o+ihqA0KPC9zcGFuPjwvYj5YaWFsaWFuZyAo RnJhbmspPGJyPg0KPGI+PHNwYW4gbGFuZz0iWkgtQ04iPuWPkemAgeaXtumXtDwvc3Bhbj46PC9i PiAyMDE3PHNwYW4gbGFuZz0iWkgtQ04iPuW5tDwvc3Bhbj44PHNwYW4gbGFuZz0iWkgtQ04iPuac iDwvc3Bhbj43PHNwYW4gbGFuZz0iWkgtQ04iPuaXpTwvc3Bhbj4gODo1Mjxicj4NCjxiPjxzcGFu IGxhbmc9IlpILUNOIj7mlLbku7bkuro8L3NwYW4+OjwvYj4gPGEgaHJlZj0ibWFpbHRvOkRvdHNA aWV0Zi5vcmciPkRvdHNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+PHNwYW4gbGFuZz0iWkgtQ04iPuS4 u+mimDwvc3Bhbj46PC9iPiBbRG90c10gQ2FuIERPVFMgcHJvdG9jb2wgc3VwcG9ydCBJUCB3aGl0 ZWxpc3QgZm9yIERPVFMgY2xpZW50J3MgQUE/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1h bGlnbjpsZWZ0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhp LDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB0aGUgZGlyZWN0 IHVzZSBvZiBJUCB3aGl0ZWxpc3Qgb24gdGhlIERPVFMgc2VydmVyIHRvIGF1dGhlbnRpY2F0ZSBh bmQgYXV0aG9yaXplIHRoZSBET1RTIGNsaWVudCBpcyBhIHNpbXBsZSBhbmQgZWZmZWN0IG1ldGhv ZCwgYXQgbGVhc3QgaW4gc29tZSBzcGVjaWFsIHVzZSBjYXNlcywgbGlrZTogRE9UUyBjbGllbnQg ZG9lcyBub3Qgc3VwcG9ydCBjZXJ0aWZpY2F0ZSwgYW4gSVNQIHdoaWNoIGRldGVjdHMNCiB0aGUg c3Bvb2ZlZCBzb3VyY2UgYWRkcmVzcywgZXRjLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Tbywg c2hvdWxkIHdlIHN1cHBvcnQgdGhpcyBhcyBhbiBvcHRpb25hbCB3YXkgZm9yIHRoZSBET1RTIGNs aWVudOKAmXMgQUEgYW5kIGFkZCBpdCBpbnRvIHRoZSBET1RTIHByb3RvY29sIGRyYWZ0cz88bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Qi5SLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+RnJhbms8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_DM5PR16MB17880F012FB44009155ADCA1EAB50DM5PR16MB1788namp_-- From nobody Mon Aug 7 02:58:27 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3B713218F for ; Mon, 7 Aug 2017 02:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uti5_DFCatG2 for ; Mon, 7 Aug 2017 02:58:22 -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 9020A124217 for ; Mon, 7 Aug 2017 02:58:21 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DSW62966; Mon, 07 Aug 2017 09:58:19 +0000 (GMT) Received: from DGGEML403-HUB.china.huawei.com (10.3.17.33) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 7 Aug 2017 10:58:18 +0100 Received: from DGGEML502-MBX.china.huawei.com ([169.254.2.84]) by DGGEML403-HUB.china.huawei.com ([fe80::74d9:c659:fbec:21fa%31]) with mapi id 14.03.0301.000; Mon, 7 Aug 2017 17:58:13 +0800 From: "Xialiang (Frank)" To: "Konda, Tirumaleswar Reddy" , "Dots@ietf.org" Thread-Topic: =?utf-8?B?YW5vdGhlciBvcHRpb246Ly/nrZTlpI06IENhbiBET1RTIHByb3RvY29sIHN1?= =?utf-8?Q?pport_IP_whitelist_for_DOTS_client's_AA=3F?= Thread-Index: AdMPF2QONmutCNOvSwe0CfD0yMkBTgAACUnwAA6poPAABEOgkA== Date: Mon, 7 Aug 2017 09:58:13 +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.134.159.76] Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F12BB2D39CDGGEML502MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.598839BB.00F1, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.84, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 810056c1be8310b8a9a28b546a53e077 Archived-At: Subject: [Dots] =?utf-8?b?562U5aSNOiBhbm90aGVyIG9wdGlvbjovL+etlOWkjTogQ2Fu?= =?utf-8?q?_DOTS_protocol_support_IP_whitelist_for_DOTS_client=27s_AA=3F?= X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 09:58:25 -0000 --_000_C02846B1344F344EB4FAA6FA7AF481F12BB2D39CDGGEML502MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVGlydSwNClRoYW5rcyBmb3IgeW91ciBhbmFseXNpcy4gSXQgbWFrZXMgc2Vuc2UgdG8gbWV+ fg0KDQpUbyBiZSBhY2N1cmF0ZSwgSVAgd2hpdGVsaXN0IGRvZXMgbm90IHJlbGF4IHRoZSBtdXR1 YWwgYXV0aGVudGljYXRpb24gcmVxdWlyZW1lbnQsIGJ1dCBpbmRlZWQgbG9zZSB0aGUgZW5jcnlw dGlvbiBiZW5lZml0cy4NCg0KQi5SLg0KRnJhbmsNCg0K5Y+R5Lu25Lq6OiBLb25kYSwgVGlydW1h bGVzd2FyIFJlZGR5IFttYWlsdG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbV0N CuWPkemAgeaXtumXtDogMjAxN+W5tDjmnIg35pelIDE3OjUxDQrmlLbku7bkuro6IFhpYWxpYW5n IChGcmFuayk7IERvdHNAaWV0Zi5vcmcNCuS4u+mimDogUkU6IGFub3RoZXIgb3B0aW9uOi8v562U 5aSNOiBDYW4gRE9UUyBwcm90b2NvbCBzdXBwb3J0IElQIHdoaXRlbGlzdCBmb3IgRE9UUyBjbGll bnQncyBBQT8NCg0KVExTIHN1cHBvcnRzIHByZS1zaGFyZWQga2V5IGJhc2VkIGF1dGhlbnRpY2F0 aW9uLiBUaGUgb3RoZXIgbWVjaGFuaXNtcyBhcmUgU3ViamVjdCBQdWJsaWMgS2V5IEluZm8gKFNQ S0kpIEZpbmdlcnByaW50IHBpbiBzZXQgZm9yIG11dHVhbCBhdXRoZW50aWNhdGlvbiAoc2VsZi1z aWduZWQgY2VydGlmaWNhdGVzIG9yIHJhdyBwdWJsaWMga2V5cykgd2l0aG91dCBoYXZpbmcgdG8g ZGVhbCB3aXRoIENBLg0KDQpJIGRvbuKAmXQgdGhpbmsgRE9UUyBzaG91bGQgcmVsYXggdGhlIG11 dHVhbCBhdXRoZW50aWNhdGlvbiBhbmQgZW5jcnlwdGlvbiByZXF1aXJlbWVudHMuDQoNCi1USXJ1 DQoNCkZyb206IERvdHMgW21haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBYaWFsaWFuZyAoRnJhbmspDQpTZW50OiBNb25kYXksIEF1Z3VzdCA3LCAyMDE3IDY6MjUgQU0N ClRvOiBEb3RzQGlldGYub3JnPG1haWx0bzpEb3RzQGlldGYub3JnPg0KU3ViamVjdDogW0RvdHNd IGFub3RoZXIgb3B0aW9uOi8v562U5aSNOiBDYW4gRE9UUyBwcm90b2NvbCBzdXBwb3J0IElQIHdo aXRlbGlzdCBmb3IgRE9UUyBjbGllbnQncyBBQT8NCg0KSW4gYWRkaXRpb24gdG8gSVAgd2hpdGVs aXN0IGFuZCBjZXJ0aWZpY2F0ZSwgcHJlLXNoYXJlIGtleSBjYW4gYWxzbyBiZSBhbiBvcHRpb24u DQpSaWdodD8NCg0K5Y+R5Lu25Lq6OiBEb3RzIFttYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3Jn XSDku6PooaggWGlhbGlhbmcgKEZyYW5rKQ0K5Y+R6YCB5pe26Ze0OiAyMDE35bm0OOaciDfml6Ug ODo1Mg0K5pS25Lu25Lq6OiBEb3RzQGlldGYub3JnPG1haWx0bzpEb3RzQGlldGYub3JnPg0K5Li7 6aKYOiBbRG90c10gQ2FuIERPVFMgcHJvdG9jb2wgc3VwcG9ydCBJUCB3aGl0ZWxpc3QgZm9yIERP VFMgY2xpZW50J3MgQUE/DQoNCkhpLA0KSSB0aGluayB0aGUgZGlyZWN0IHVzZSBvZiBJUCB3aGl0 ZWxpc3Qgb24gdGhlIERPVFMgc2VydmVyIHRvIGF1dGhlbnRpY2F0ZSBhbmQgYXV0aG9yaXplIHRo ZSBET1RTIGNsaWVudCBpcyBhIHNpbXBsZSBhbmQgZWZmZWN0IG1ldGhvZCwgYXQgbGVhc3QgaW4g c29tZSBzcGVjaWFsIHVzZSBjYXNlcywgbGlrZTogRE9UUyBjbGllbnQgZG9lcyBub3Qgc3VwcG9y dCBjZXJ0aWZpY2F0ZSwgYW4gSVNQIHdoaWNoIGRldGVjdHMgdGhlIHNwb29mZWQgc291cmNlIGFk ZHJlc3MsIGV0Yy4NCg0KU28sIHNob3VsZCB3ZSBzdXBwb3J0IHRoaXMgYXMgYW4gb3B0aW9uYWwg d2F5IGZvciB0aGUgRE9UUyBjbGllbnTigJlzIEFBIGFuZCBhZGQgaXQgaW50byB0aGUgRE9UUyBw cm90b2NvbCBkcmFmdHM/DQoNCkIuUi4NCkZyYW5rDQo= --_000_C02846B1344F344EB4FAA6FA7AF481F12BB2D39CDGGEML502MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0LWFsaWduOmp1c3RpZnk7DQoJdGV4dC1qdXN0 aWZ5OmludGVyLWlkZW9ncmFwaDsNCglmb250LXNpemU6MTAuNXB0Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IuaJueazqOahhuaWh+acrCBDaGFyIjsN CgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0LWFsaWduOmp1c3Rp Znk7DQoJdGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaDsNCglmb250LXNpemU6OS4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OuWui+S9kzt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9y OndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFu LkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5DaGFy DQoJe21zby1zdHlsZS1uYW1lOiLmibnms6jmoYbmlofmnKwgQ2hhciI7DQoJbXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOuaJueazqOahhuaWh+acrDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5 MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9 InRleHQtanVzdGlmeS10cmltOnB1bmN0dWF0aW9uIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPkhpIFRpcnUsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5UaGFua3MgZm9y IHlvdXIgYW5hbHlzaXMuIEl0IG1ha2VzIHNlbnNlIHRvIG1lfn48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VG8gYmUgYWNjdXJh dGUsIElQIHdoaXRlbGlzdCBkb2VzIG5vdCByZWxheCB0aGUgbXV0dWFsIGF1dGhlbnRpY2F0aW9u IHJlcXVpcmVtZW50LCBidXQgaW5kZWVkIGxvc2UgdGhlIGVuY3J5cHRpb24gYmVuZWZpdHMuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPkIuUi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkZyYW5rPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0 eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OuWui+S9kyI+5Y+R5Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9z cGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk65a6L5L2TIj4gS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSBbbWFpbHRvOlRpcnVtYWxl c3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb21dDQo8YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TIj7lj5HpgIHml7bpl7Q8c3BhbiBs YW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTrlrovkvZMiPiAyMDE3PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kyI+5bm0PHNwYW4gbGFuZz0i RU4tVVMiPjg8L3NwYW4+5pyIPHNwYW4gbGFuZz0iRU4tVVMiPjc8L3NwYW4+5pelPHNwYW4gbGFu Zz0iRU4tVVMiPg0KIDE3OjUxPGJyPg0KPC9zcGFuPjxiPuaUtuS7tuS6ujxzcGFuIGxhbmc9IkVO LVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IFhpYWxpYW5nIChGcmFuayk7IERv dHNAaWV0Zi5vcmc8YnI+DQo8L3NwYW4+PGI+5Li76aKYPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3Nw YW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gUkU6IGFub3RoZXIgb3B0aW9uOi8vPC9zcGFuPuet lOWkjTxzcGFuIGxhbmc9IkVOLVVTIj46IENhbiBET1RTIHByb3RvY29sIHN1cHBvcnQgSVAgd2hp dGVsaXN0IGZvciBET1RTIGNsaWVudCdzIEFBPzxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxl PSJ0ZXh0LWFsaWduOmxlZnQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPlRMUyBzdXBwb3J0cyBwcmUtc2hhcmVkIGtleSBiYXNlZCBhdXRo ZW50aWNhdGlvbi4gVGhlIG90aGVyIG1lY2hhbmlzbXMgYXJlIFN1YmplY3QgUHVibGljIEtleSBJ bmZvIChTUEtJKSBGaW5nZXJwcmludCBwaW4gc2V0IGZvciBtdXR1YWwgYXV0aGVudGljYXRpb24g KHNlbGYtc2lnbmVkIGNlcnRpZmljYXRlcyBvciByYXcgcHVibGljDQoga2V5cykgd2l0aG91dCBo YXZpbmcgdG8gZGVhbCB3aXRoIENBLiAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SSBkb27igJl0IHRoaW5r IERPVFMgc2hvdWxkIHJlbGF4IHRoZSBtdXR1YWwgYXV0aGVudGljYXRpb24gYW5kIGVuY3J5cHRp b24gcmVxdWlyZW1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4tVElydTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L2E+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAw Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRl eHQtYWxpZ246bGVmdCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij4gRG90cyBbPGEgaHJlZj0ibWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZyI+bWFp bHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlhpYWxp YW5nIChGcmFuayk8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBBdWd1c3QgNywgMjAxNyA2OjI1 IEFNPGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86RG90c0BpZXRmLm9yZyI+RG90c0Bp ZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW0RvdHNdIGFub3RoZXIgb3B0aW9uOi8v PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kyI+ 562U5aSNPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ OiBDYW4gRE9UUyBwcm90b2NvbCBzdXBwb3J0IElQIHdoaXRlbGlzdCBmb3IgRE9UUyBjbGllbnQn cyBBQT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkluIGFkZGl0aW9uIHRv IElQIHdoaXRlbGlzdCBhbmQgY2VydGlmaWNhdGUsIHByZS1zaGFyZSBrZXkgY2FuIGFsc28gYmUg YW4gb3B0aW9uLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj5SaWdodD88L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kyI+5Y+R5Lu25Lq6PHNwYW4g bGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TIj4gRG90cyBbPGEgaHJlZj0ibWFp bHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZzwv YT5dDQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 5a6L5L2TIj7ku6PooaggPC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TIj5YaWFsaWFuZyAoRnJhbmspPGJyPg0KPC9z cGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kyI+ 5Y+R6YCB5pe26Ze0PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TIj4g MjAxNzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTrlrovk vZMiPuW5tDxzcGFuIGxhbmc9IkVOLVVTIj44PC9zcGFuPuaciDxzcGFuIGxhbmc9IkVOLVVTIj43 PC9zcGFuPuaXpTxzcGFuIGxhbmc9IkVOLVVTIj4NCiA4OjUyPGJyPg0KPC9zcGFuPjxiPuaUtuS7 tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IDxh IGhyZWY9Im1haWx0bzpEb3RzQGlldGYub3JnIj4NCkRvdHNAaWV0Zi5vcmc8L2E+PGJyPg0KPC9z cGFuPjxiPuS4u+mimDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJF Ti1VUyI+IFtEb3RzXSBDYW4gRE9UUyBwcm90b2NvbCBzdXBwb3J0IElQIHdoaXRlbGlzdCBmb3Ig RE9UUyBjbGllbnQncyBBQT88L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxp Z249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPkkgdGhpbmsgdGhlIGRpcmVjdCB1c2Ugb2YgSVAgd2hpdGVsaXN0 IG9uIHRoZSBET1RTIHNlcnZlciB0byBhdXRoZW50aWNhdGUgYW5kIGF1dGhvcml6ZSB0aGUgRE9U UyBjbGllbnQgaXMgYSBzaW1wbGUgYW5kIGVmZmVjdCBtZXRob2QsIGF0IGxlYXN0IGluIHNvbWUg c3BlY2lhbCB1c2UgY2FzZXMsIGxpa2U6IERPVFMgY2xpZW50IGRvZXMgbm90IHN1cHBvcnQgY2Vy dGlmaWNhdGUsDQogYW4gSVNQIHdoaWNoIGRldGVjdHMgdGhlIHNwb29mZWQgc291cmNlIGFkZHJl c3MsIGV0Yy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlNvLCBzaG91bGQgd2Ugc3VwcG9ydCB0aGlzIGFz IGFuIG9wdGlvbmFsIHdheSBmb3IgdGhlIERPVFMgY2xpZW504oCZcyBBQSBhbmQgYWRkIGl0IGlu dG8gdGhlIERPVFMgcHJvdG9jb2wgZHJhZnRzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Qi5SLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5GcmFuazxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_C02846B1344F344EB4FAA6FA7AF481F12BB2D39CDGGEML502MBXchi_-- From nobody Mon Aug 7 03:19:21 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0092E124217 for ; Mon, 7 Aug 2017 03:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v492YWNOVaUq for ; Mon, 7 Aug 2017 03:19:18 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 9BB90132017 for ; Mon, 7 Aug 2017 03:19:17 -0700 (PDT) Received: from MIVEXAPP1N03.corpzone.internalzone.com (unknown [10.48.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp id 6ddc_9bba_aa05bbf1_f50a_476b_821c_ce7ebed38959; Mon, 07 Aug 2017 05:19:14 -0500 Received: from MIVEXAPP1N03.corpzone.internalzone.com (10.48.48.90) by MIVEXAPP1N03.corpzone.internalzone.com (10.48.48.90) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 7 Aug 2017 06:19:12 -0400 Received: from MIVEX10N02.corpzone.internalzone.com (10.48.48.170) by MIVEXAPP1N03.corpzone.internalzone.com (10.48.48.90) with Microsoft SMTP Server (TLS) id 15.0.1263.5 via Frontend Transport; Mon, 7 Aug 2017 06:19:12 -0400 Received: from MIVO365EDGE3.corpzone.internalzone.com (10.48.176.86) by MIVEX10N02.corpzone.internalzone.com (10.48.48.170) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 7 Aug 2017 06:19:12 -0400 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (10.48.176.243) by edge.mcafee.com (10.48.176.86) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 7 Aug 2017 06:19:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.onmicrosoft.com; s=selector1-mcafee-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=SLWDOy3ZG0Ggg2v9p2lCv4IaOqeTNP1OhwQYgejrq90=; b=bFhYjbav6yXZHJRjyiWoIMfo8hqV0gd+YlBTc8BE7DcfysDqt2Q0R2J1yc8D3JyAgrPqr1z1Luq1EIm8c1Z4CSWMrRBFoeaJmSdC8P64pqQOSY67cLFKMKsZd3JYOSXQTQ2kjmr9TRvk2LC/Dcku0nB7JuvyzA1xRp7z+rPefHc= Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1787.namprd16.prod.outlook.com (10.172.44.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1320.16; Mon, 7 Aug 2017 10:19:10 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.01.1320.018; Mon, 7 Aug 2017 10:19:10 +0000 From: "Konda, Tirumaleswar Reddy" To: "Xialiang (Frank)" , "Dots@ietf.org" Thread-Topic: =?utf-8?B?YW5vdGhlciBvcHRpb246Ly/nrZTlpI06IENhbiBET1RTIHByb3RvY29sIHN1?= =?utf-8?Q?pport_IP_whitelist_for_DOTS_client's_AA=3F?= Thread-Index: AdMPF2QONmutCNOvSwe0CfD0yMkBTgAACUnwAA6poPAABEOgkAAAs7nQ Date: Mon, 7 Aug 2017 10:19:10 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1787; 6:JqWDL4IKfjp6GRBvzz7Oni1RQnYlxmAG8HQqvLhIWzH1ZB06Q+DdiISPRzZy9IuGdxQ7m/ejB3staJVZT+nHslK/RBOKnwclCdysTSCC0/0woHUyhlXEAuZ4X0zRLKGT1ig3anoyRpwS2qDcKBJ7R4dQ3EH+dFQztTfzLAXBOBr6PMa3VdeB2XwvqCR7DSri77DX3sAySTav1CYJk4Ys4OxM/qBAm/m5XIj2A9AY/hOfHGi/rUbHtalahlSm9s5ICQqhT/INnuoyGjUXX5YpcfZECrG7Idis3Hb4NEzdVAc9SSuelXCGe9zXDXWIqOXxLj2PEeYtg8D/r4KtBVeDAw==; 5:ib3chjEep1ckXG1h+EwDU8q7yZQsMavlYuwbIA7VewcHv66fs6bSv2vH/7UBxW5ToxgtxprTuYgTaIh4XmCqSn/XCz13tYWiFGLygAfDDcHlB/aDx5U5gOpm94/sEkX9PPbtFzHZWGJKvRnH3tUKdg==; 24:zwT6RqChColiy6wSYxVXYLpG7e5vRsiuGPy0IXh5qKfp6cN3N15Fyea7RtmTtrucP5GH1DS6FiSazUaHRZwQaj3+1u/EdeCWoM7gEm+8djw=; 7:Ud0zCfm4aDk5mRCeHNNfwQrmFAchWQ7pqC7l1I//OyaNwsh+ZfOcPZS7gs/ANbL5ugc4nsFzNtCV1oULflASA0Eh8JEqzxflO7RLnLvYXxDF2kjtOlxLpEvpBY2Wb5HFMxC0PYFDvTP6ZpkUKq7zkUv34HjR0xwGJgtkTN5iNlz7cGmhbluEIGgdWgN3H0zDUCVtcPgVBROW3kGOVkiGwcWOuvE5tuLlz2d/FTrEOBg= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 0d215953-6685-49f4-c6f2-08d4dd7dbec4 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM5PR16MB1787; x-ms-traffictypediagnostic: DM5PR16MB1787: x-exchange-antispam-report-test: UriScan:(158342451672863)(50582790962513)(21748063052155)(123452027830198); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123562025)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1787; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1787; x-forefront-prvs: 0392679D18 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39410400002)(39400400002)(39450400003)(39840400002)(377454003)(199003)(189002)(32952001)(53936002)(2900100001)(229853002)(6506006)(53546010)(478600001)(3846002)(77096006)(102836003)(6116002)(790700001)(2950100002)(80792005)(68736007)(8936002)(50986999)(76176999)(54356999)(966005)(81166006)(81156014)(72206003)(99286003)(55016002)(14454004)(54896002)(6306002)(74316002)(86362001)(2906002)(106356001)(3660700001)(2501003)(3280700002)(236005)(66066001)(101416001)(9686003)(33656002)(224303003)(105586002)(6436002)(189998001)(7696004)(6246003)(7736002)(97736004)(606006)(38730400002)(93886004)(25786009)(5660300001)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1787; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB17888218351CF06BDF691F34EAB50DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Aug 2017 10:19:10.6049 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1787 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.9 X-NAI-Spam-Version: 2.3.0.9418 : core <6087> : inlines <6011> : streams <1757540> : uri <2478148> Archived-At: Subject: Re: [Dots] =?utf-8?b?YW5vdGhlciBvcHRpb246Ly/nrZTlpI06IENhbiBET1RT?= =?utf-8?q?_protocol_support_IP_whitelist_for_DOTS_client=27s_AA=3F?= X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 10:19:20 -0000 --_000_DM5PR16MB17888218351CF06BDF691F34EAB50DM5PR16MB1788namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WW91IG1heSB3YW50IHRvIGxvb2sgaW50byBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj Njk1OSNzZWN0aW9uLTcNCjxzbmlwPg0KICAgRXZlbiBpZiBldmVyeSBJbnRlcm5ldC1jb25uZWN0 ZWQgbmV0d29yayBpbXBsZW1lbnRzIHNvdXJjZSBhZGRyZXNzDQogICB2YWxpZGF0aW9uIGF0IHRo ZSB1bHRpbWF0ZSBuZXR3b3JrIGluZ3Jlc3MsIGFuZCBhc3N1cmFuY2VzIGV4aXN0IHRoYXQNCiAg IGludGVybWVkaWF0ZSBkZXZpY2VzIGFyZSB0byBuZXZlciBtb2RpZnkgZGF0YWdyYW0gc291cmNl IGFkZHJlc3NlcywNCiAgIHNvdXJjZSBhZGRyZXNzZXMgY2Fubm90IGJlIHVzZWQgYXMgYW4gYXV0 aGVudGljYXRpb24gbWVjaGFuaXNtLg0KDQotVGlydQ0KDQpGcm9tOiBYaWFsaWFuZyAoRnJhbmsp IFttYWlsdG86ZnJhbmsueGlhbGlhbmdAaHVhd2VpLmNvbV0NClNlbnQ6IE1vbmRheSwgQXVndXN0 IDcsIDIwMTcgMzoyOCBQTQ0KVG86IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgPFRpcnVtYWxl c3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20+OyBEb3RzQGlldGYub3JnDQpTdWJqZWN0OiDnrZTl pI06IGFub3RoZXIgb3B0aW9uOi8v562U5aSNOiBDYW4gRE9UUyBwcm90b2NvbCBzdXBwb3J0IElQ IHdoaXRlbGlzdCBmb3IgRE9UUyBjbGllbnQncyBBQT8NCg0KSGkgVGlydSwNClRoYW5rcyBmb3Ig eW91ciBhbmFseXNpcy4gSXQgbWFrZXMgc2Vuc2UgdG8gbWV+fg0KDQpUbyBiZSBhY2N1cmF0ZSwg SVAgd2hpdGVsaXN0IGRvZXMgbm90IHJlbGF4IHRoZSBtdXR1YWwgYXV0aGVudGljYXRpb24gcmVx dWlyZW1lbnQsIGJ1dCBpbmRlZWQgbG9zZSB0aGUgZW5jcnlwdGlvbiBiZW5lZml0cy4NCg0KQi5S Lg0KRnJhbmsNCg0K5Y+R5Lu25Lq6OiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5IFttYWlsdG86 VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbV0NCuWPkemAgeaXtumXtDogMjAxN+W5 tDjmnIg35pelIDE3OjUxDQrmlLbku7bkuro6IFhpYWxpYW5nIChGcmFuayk7IERvdHNAaWV0Zi5v cmc8bWFpbHRvOkRvdHNAaWV0Zi5vcmc+DQrkuLvpopg6IFJFOiBhbm90aGVyIG9wdGlvbjovL+et lOWkjTogQ2FuIERPVFMgcHJvdG9jb2wgc3VwcG9ydCBJUCB3aGl0ZWxpc3QgZm9yIERPVFMgY2xp ZW50J3MgQUE/DQoNClRMUyBzdXBwb3J0cyBwcmUtc2hhcmVkIGtleSBiYXNlZCBhdXRoZW50aWNh dGlvbi4gVGhlIG90aGVyIG1lY2hhbmlzbXMgYXJlIFN1YmplY3QgUHVibGljIEtleSBJbmZvIChT UEtJKSBGaW5nZXJwcmludCBwaW4gc2V0IGZvciBtdXR1YWwgYXV0aGVudGljYXRpb24gKHNlbGYt c2lnbmVkIGNlcnRpZmljYXRlcyBvciByYXcgcHVibGljIGtleXMpIHdpdGhvdXQgaGF2aW5nIHRv IGRlYWwgd2l0aCBDQS4NCg0KSSBkb27igJl0IHRoaW5rIERPVFMgc2hvdWxkIHJlbGF4IHRoZSBt dXR1YWwgYXV0aGVudGljYXRpb24gYW5kIGVuY3J5cHRpb24gcmVxdWlyZW1lbnRzLg0KDQotVEly dQ0KDQpGcm9tOiBEb3RzIFttYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgWGlhbGlhbmcgKEZyYW5rKQ0KU2VudDogTW9uZGF5LCBBdWd1c3QgNywgMjAxNyA2OjI1IEFN DQpUbzogRG90c0BpZXRmLm9yZzxtYWlsdG86RG90c0BpZXRmLm9yZz4NClN1YmplY3Q6IFtEb3Rz XSBhbm90aGVyIG9wdGlvbjovL+etlOWkjTogQ2FuIERPVFMgcHJvdG9jb2wgc3VwcG9ydCBJUCB3 aGl0ZWxpc3QgZm9yIERPVFMgY2xpZW50J3MgQUE/DQoNCkluIGFkZGl0aW9uIHRvIElQIHdoaXRl bGlzdCBhbmQgY2VydGlmaWNhdGUsIHByZS1zaGFyZSBrZXkgY2FuIGFsc28gYmUgYW4gb3B0aW9u Lg0KUmlnaHQ/DQoNCuWPkeS7tuS6ujogRG90cyBbbWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9y Z10g5Luj6KGoIFhpYWxpYW5nIChGcmFuaykNCuWPkemAgeaXtumXtDogMjAxN+W5tDjmnIg35pel IDg6NTINCuaUtuS7tuS6ujogRG90c0BpZXRmLm9yZzxtYWlsdG86RG90c0BpZXRmLm9yZz4NCuS4 u+mimDogW0RvdHNdIENhbiBET1RTIHByb3RvY29sIHN1cHBvcnQgSVAgd2hpdGVsaXN0IGZvciBE T1RTIGNsaWVudCdzIEFBPw0KDQpIaSwNCkkgdGhpbmsgdGhlIGRpcmVjdCB1c2Ugb2YgSVAgd2hp dGVsaXN0IG9uIHRoZSBET1RTIHNlcnZlciB0byBhdXRoZW50aWNhdGUgYW5kIGF1dGhvcml6ZSB0 aGUgRE9UUyBjbGllbnQgaXMgYSBzaW1wbGUgYW5kIGVmZmVjdCBtZXRob2QsIGF0IGxlYXN0IGlu IHNvbWUgc3BlY2lhbCB1c2UgY2FzZXMsIGxpa2U6IERPVFMgY2xpZW50IGRvZXMgbm90IHN1cHBv cnQgY2VydGlmaWNhdGUsIGFuIElTUCB3aGljaCBkZXRlY3RzIHRoZSBzcG9vZmVkIHNvdXJjZSBh ZGRyZXNzLCBldGMuDQoNClNvLCBzaG91bGQgd2Ugc3VwcG9ydCB0aGlzIGFzIGFuIG9wdGlvbmFs IHdheSBmb3IgdGhlIERPVFMgY2xpZW504oCZcyBBQSBhbmQgYWRkIGl0IGludG8gdGhlIERPVFMg cHJvdG9jb2wgZHJhZnRzPw0KDQpCLlIuDQpGcmFuaw0K --_000_DM5PR16MB17888218351CF06BDF691F34EAB50DM5PR16MB1788namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6RGVuZ1hpYW47DQoJcGFub3NlLTE6MiAxIDYg MCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFu b3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToi XEBEZW5nWGlhbiI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJTZWdvZSBVSSI7DQoJcGFub3NlLTE6MiAxMSA1IDIgNCAyIDQgMiAy IDM7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBTaW1TdW4iOw0KCXBhbm9zZS0xOjIg MSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiTWljcm9zb2Z0 IEpoZW5nSGVpIjsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJcQE1pY3Jvc29mdCBKaGVuZ0hlaSI7fQ0KLyogU3R5bGUgRGVmaW5p dGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJdGV4dC1hbGlnbjpqdXN0aWZ5Ow0K CWZvbnQtc2l6ZToxMC41cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K YTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5N c29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVy cGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFy Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwg ZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJdGV4dC1hbGlnbjpqdXN0aWZ5Ow0KCWZvbnQtc2l6ZTo5LjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRp di5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OlNpbVN1bjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9v biBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi QmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiU2Vnb2UgVUkiLHNhbnMtc2VyaWY7fQ0Kc3Bh bi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5 bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFG NDk3RDt9DQpwLmEsIGxpLmEsIGRpdi5hDQoJe21zby1zdHlsZS1uYW1lOuaJueazqOahhuaWh+ac rDsNCgltc28tc3R5bGUtbGluazoi5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCXRleHQtYWxpZ246anVzdGlmeTsNCglmb250LXNp emU6MTAuNXB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uQ2hh cg0KCXttc28tc3R5bGUtbmFtZToi5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazrmibnms6jmoYbmlofmnKw7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjYNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1z dHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41 aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjI1aW4gMS4waW4gMS4yNWluO30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0i RU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiIHN0eWxlPSJ0ZXh0LWp1c3RpZnktdHJp bTpwdW5jdHVhdGlvbiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPllvdSBtYXkgd2FudCB0byBs b29rIGludG8gPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY5NTkjc2Vj dGlvbi03Ij4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2OTU5I3NlY3Rpb24tNzwv YT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+Jmx0O3NuaXAmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNw OyZuYnNwOyBFdmVuIGlmIGV2ZXJ5IEludGVybmV0LWNvbm5lY3RlZCBuZXR3b3JrIGltcGxlbWVu dHMgc291cmNlIGFkZHJlc3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7IHZhbGlkYXRp b24gYXQgdGhlIHVsdGltYXRlIG5ldHdvcmsgaW5ncmVzcywgYW5kIGFzc3VyYW5jZXMgZXhpc3Qg dGhhdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsgaW50ZXJtZWRpYXRlIGRldmljZXMg YXJlIHRvIG5ldmVyIG1vZGlmeSBkYXRhZ3JhbSBzb3VyY2UgYWRkcmVzc2VzLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij4mbmJzcDsmbmJzcDsgc291cmNlIGFkZHJlc3NlcyBjYW5ub3QgYmUgdXNlZCBhcyBh biBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc20uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij4tVGlydTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8c3BhbiBzdHlsZT0ibXNv LWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PC9zcGFuPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0 Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUx RTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+IFhpYWxpYW5nIChGcmFuaykgW21haWx0bzpmcmFuay54aWFsaWFuZ0BodWF3ZWkuY29t XQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgQXVndXN0IDcsIDIwMTcgMzoyOCBQTTxicj4N CjxiPlRvOjwvYj4gS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSAmbHQ7VGlydW1hbGVzd2FyUmVk ZHlfS29uZGFATWNBZmVlLmNvbSZndDs7IERvdHNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gPC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgSmhlbmdIZWkmcXVvdDssc2Fucy1zZXJpZiI+562U5aSN PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij46IGFub3RoZXIgb3B0aW9uOi8v PC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtNaWNyb3NvZnQgSmhlbmdIZWkmcXVvdDssc2Fucy1zZXJpZiI+562U5aSNPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij46DQogQ2FuIERPVFMgcHJvdG9jb2wg c3VwcG9ydCBJUCB3aGl0ZWxpc3QgZm9yIERPVFMgY2xpZW50J3MgQUE/PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0 IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5IaSBUaXJ1LDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj5UaGFua3MgZm9yIHlvdXIgYW5hbHlzaXMuIEl0IG1ha2VzIHNlbnNlIHRvIG1lfn48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRvIGJlIGFjY3VyYXRlLCBJUCB3 aGl0ZWxpc3QgZG9lcyBub3QgcmVsYXggdGhlIG11dHVhbCBhdXRoZW50aWNhdGlvbiByZXF1aXJl bWVudCwgYnV0IGluZGVlZCBsb3NlIHRoZSBlbmNyeXB0aW9uIGJlbmVmaXRzLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Qi5SLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5GcmFuazxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxl PSJ0ZXh0LWFsaWduOmxlZnQiPjxiPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPuWPkeS7tuS6ujwvc3Bhbj48L2I+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj46PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiBLb25kYSwN CiBUaXJ1bWFsZXN3YXIgUmVkZHkgWzxhIGhyZWY9Im1haWx0bzpUaXJ1bWFsZXN3YXJSZWRkeV9L b25kYUBNY0FmZWUuY29tIj5tYWlsdG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNv bTwvYT5dDQo8YnI+DQo8Yj48c3BhbiBsYW5nPSJaSC1DTiI+5Y+R6YCB5pe26Ze0PC9zcGFuPjo8 L2I+IDIwMTc8c3BhbiBsYW5nPSJaSC1DTiI+5bm0PC9zcGFuPjg8c3BhbiBsYW5nPSJaSC1DTiI+ 5pyIPC9zcGFuPjc8c3BhbiBsYW5nPSJaSC1DTiI+5pelPC9zcGFuPiAxNzo1MTxicj4NCjxiPjxz cGFuIGxhbmc9IlpILUNOIj7mlLbku7bkuro8L3NwYW4+OjwvYj4gWGlhbGlhbmcgKEZyYW5rKTsg PGEgaHJlZj0ibWFpbHRvOkRvdHNAaWV0Zi5vcmciPg0KRG90c0BpZXRmLm9yZzwvYT48YnI+DQo8 Yj48c3BhbiBsYW5nPSJaSC1DTiI+5Li76aKYPC9zcGFuPjo8L2I+IFJFOiBhbm90aGVyIG9wdGlv bjovLzxzcGFuIGxhbmc9IlpILUNOIj7nrZTlpI08L3NwYW4+OiBDYW4gRE9UUyBwcm90b2NvbCBz dXBwb3J0IElQIHdoaXRlbGlzdCBmb3IgRE9UUyBjbGllbnQncyBBQT88bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQi IHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRMUyBzdXBwb3J0cyBw cmUtc2hhcmVkIGtleSBiYXNlZCBhdXRoZW50aWNhdGlvbi4gVGhlIG90aGVyIG1lY2hhbmlzbXMg YXJlIFN1YmplY3QgUHVibGljIEtleSBJbmZvIChTUEtJKSBGaW5nZXJwcmludCBwaW4gc2V0IGZv ciBtdXR1YWwgYXV0aGVudGljYXRpb24gKHNlbGYtc2lnbmVkIGNlcnRpZmljYXRlcyBvciByYXcg cHVibGljIGtleXMpIHdpdGhvdXQNCiBoYXZpbmcgdG8gZGVhbCB3aXRoIENBLiAmbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkkgZG9u4oCZdCB0aGluayBE T1RTIHNob3VsZCByZWxheCB0aGUgbXV0dWFsIGF1dGhlbnRpY2F0aW9uIGFuZCBlbmNyeXB0aW9u IHJlcXVpcmVtZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi Pi1USXJ1PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiBEb3RzIFs8YSBocmVmPSJtYWlsdG86ZG90cy1ib3Vu Y2VzQGlldGYub3JnIj5tYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJl aGFsZiBPZiA8L2I+WGlhbGlhbmcgKEZyYW5rKTxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEF1 Z3VzdCA3LCAyMDE3IDY6MjUgQU08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpEb3Rz QGlldGYub3JnIj5Eb3RzQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBbRG90c10g YW5vdGhlciBvcHRpb246Ly88L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+562U5aSNPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij46IENhbiBET1RTIHByb3RvY29sIHN1cHBvcnQgSVAgd2hpdGVsaXN0 IGZvciBET1RTIGNsaWVudCdzIEFBPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246 bGVmdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+SW4gYWRkaXRpb24gdG8gSVAgd2hpdGVsaXN0IGFuZCBjZXJ0 aWZpY2F0ZSwgcHJlLXNoYXJlIGtleSBjYW4gYWxzbyBiZSBhbiBvcHRpb24uPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPlJpZ2h0Pzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxp Z249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxiPjxzcGFuIGxhbmc9IlpILUNOIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPuWPkeS7tuS6ujwvc3Bh bj48L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3Vu Ij46PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpT aW1TdW4iPiBEb3RzDQogWzxhIGhyZWY9Im1haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmciPm1h aWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSA8Yj48c3BhbiBsYW5nPSJaSC1DTiI+5Luj 6KGoDQo8L3NwYW4+PC9iPlhpYWxpYW5nIChGcmFuayk8YnI+DQo8Yj48c3BhbiBsYW5nPSJaSC1D TiI+5Y+R6YCB5pe26Ze0PC9zcGFuPjo8L2I+IDIwMTc8c3BhbiBsYW5nPSJaSC1DTiI+5bm0PC9z cGFuPjg8c3BhbiBsYW5nPSJaSC1DTiI+5pyIPC9zcGFuPjc8c3BhbiBsYW5nPSJaSC1DTiI+5pel PC9zcGFuPiA4OjUyPGJyPg0KPGI+PHNwYW4gbGFuZz0iWkgtQ04iPuaUtuS7tuS6ujwvc3Bhbj46 PC9iPiA8YSBocmVmPSJtYWlsdG86RG90c0BpZXRmLm9yZyI+RG90c0BpZXRmLm9yZzwvYT48YnI+ DQo8Yj48c3BhbiBsYW5nPSJaSC1DTiI+5Li76aKYPC9zcGFuPjo8L2I+IFtEb3RzXSBDYW4gRE9U UyBwcm90b2NvbCBzdXBwb3J0IElQIHdoaXRlbGlzdCBmb3IgRE9UUyBjbGllbnQncyBBQT88L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg YWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGksPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JIHRoaW5rIHRoZSBkaXJlY3QgdXNlIG9mIElQIHdoaXRlbGlzdCBvbiB0aGUgRE9U UyBzZXJ2ZXIgdG8gYXV0aGVudGljYXRlIGFuZCBhdXRob3JpemUgdGhlIERPVFMgY2xpZW50IGlz IGEgc2ltcGxlIGFuZCBlZmZlY3QgbWV0aG9kLCBhdCBsZWFzdCBpbiBzb21lIHNwZWNpYWwgdXNl IGNhc2VzLCBsaWtlOiBET1RTIGNsaWVudCBkb2VzIG5vdCBzdXBwb3J0IGNlcnRpZmljYXRlLCBh biBJU1Agd2hpY2ggZGV0ZWN0cw0KIHRoZSBzcG9vZmVkIHNvdXJjZSBhZGRyZXNzLCBldGMuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvLCBzaG91bGQgd2Ugc3VwcG9ydCB0aGlzIGFzIGFuIG9w dGlvbmFsIHdheSBmb3IgdGhlIERPVFMgY2xpZW504oCZcyBBQSBhbmQgYWRkIGl0IGludG8gdGhl IERPVFMgcHJvdG9jb2wgZHJhZnRzPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CLlIuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5GcmFuazxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DM5PR16MB17888218351CF06BDF691F34EAB50DM5PR16MB1788namp_-- From nobody Wed Aug 9 01:28:30 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DFDA1270B4 for ; Wed, 9 Aug 2017 01:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2lpMT1H_Mq9 for ; Wed, 9 Aug 2017 01:28:24 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 646F2127869 for ; Wed, 9 Aug 2017 01:28:24 -0700 (PDT) Received: from MIVEXAPP1N02.corpzone.internalzone.com (unknown [10.48.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp id 6225_cffe_4c97f5bd_2a44_4e01_b135_b115b90cc01b; Wed, 09 Aug 2017 03:28:18 -0500 Received: from MIVEXAPP1N03.corpzone.internalzone.com (10.48.48.90) by MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 9 Aug 2017 04:28:15 -0400 Received: from MIVO365EDGE3.corpzone.internalzone.com (10.48.176.86) by MIVEXAPP1N03.corpzone.internalzone.com (10.48.48.90) with Microsoft SMTP Server (TLS) id 15.0.1263.5 via Frontend Transport; Wed, 9 Aug 2017 04:28:15 -0400 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (10.48.176.240) by edge.mcafee.com (10.48.176.86) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 9 Aug 2017 04:28:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.onmicrosoft.com; s=selector1-mcafee-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PJBxGDOaveua2+7tWDy5mKUxWmxmZI6SwuQe0VUDGRA=; b=C+/JDkr+xM95gpWQYki3B/SeIjLcObMf8rinid079KZCouqixw5E+s6wcDjxCVKM246WCqW3besffodS1Mb0h6o8qH1AIaFuYUpGPhEaf1OfQ9AngZO2CVHRDtGem1d62guf1TBP6QcOwfkOMFkLjgRWyFczQ7cLeOCIubKdHJE= Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1786.namprd16.prod.outlook.com (10.172.44.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1320.16; Wed, 9 Aug 2017 08:28:14 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.01.1320.018; Wed, 9 Aug 2017 08:28:14 +0000 From: "Konda, Tirumaleswar Reddy" To: Dave Dolson , "dots@ietf.org" Thread-Topic: Some notes on ietf-dots-signal-channel-02 Thread-Index: AdMA7vzOFdFEa4W8RY6lSPNLnIlWkAMAfw0Q Date: Wed, 9 Aug 2017 08:28:13 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1786; 6:cP3qxUJw4x41j4hxDi6fZQ629jm1CJj3gqVSLQt2HW+c05Z8LZM4IL4dAghJN2EYJ4ftHAjNLmF7KIRgBbcJVfUVOhD9JGbz9nQPezabB4LD5z5cZ1QfhKqaLB3x1y7eOYGcV+HJTVV56zLOftVFFcaQt663Lh0HEGHoOPT8skjUW7rH0QCwvPO5iHP3c7cdruaIFXL2wcTT7ipKU+vtwYfi6cvIgCXQwWjhCZD1LuZmfYpSZkXRWGWRjFkU+637oZE5v2kJraE5zqXfu/oZpm9bp6PMhxWdKXUpETzpzNSx1D0ZlWCQeWIsmskvDHltaEfzRNPaSz0PIf0ovym9Bw==; 5:aI0rqjYRyMTTumfE4aWvwmRrryiHfUNzcRj4NY5rpOS2WmwGas+4n3AJf44nuSnrxh2s5zT6lZCnGGB6lDntKvUSsqWEhk2KUpQkYHvwnhLcnQHDmVRlVREfq5ypwFsCaMWmUThXXJt9shG3ULlPhw==; 24:vlAVnyc/7NLWmRRPatrS+fCzZI2IsGANgMTFuQFlroUVI9PYBnBgYk3UDPJ94eOTXMMMTM6pnxrWJmRkh3FOGOfAr6uzzb7Ul2Gn8j1mqqs=; 7:WVITdc11gj3ucJ+MV8o+H1cD0BrO3R41Sc1uJkIyW1iL6lULnNgW4WwMYwzaeKmSYE+5Ueuk5kKdHtdLfspVTFt7DmQcFpIriPVsAXX+DQeFXXcycyqyTDDq4cRLpuRSpwRjRV7gBXdzj5cHVVmY1yql/KHCfH/L7HtMgP9Afqa4TKJOhhm6MmpnlJPFX2TFh6Z7JKPKv3gqw9mJYPR25eqTFV6TUtxLZW5h8En4NLU= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: f6248f88-e05f-43f1-bbc9-08d4df0093f4 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM5PR16MB1786; x-ms-traffictypediagnostic: DM5PR16MB1786: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(278428928389397)(192374486261705)(788757137089)(21748063052155)(1591387915157); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(20161123562025)(20161123558100)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1786; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1786; x-forefront-prvs: 0394259C80 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39850400002)(39840400002)(39450400003)(39410400002)(39400400002)(199003)(377454003)(189002)(51914003)(32952001)(33656002)(790700001)(9686003)(6116002)(102836003)(81156014)(81166006)(8936002)(99286003)(9326002)(19609705001)(606006)(2900100001)(3846002)(53936002)(86362001)(97736004)(53546010)(80792005)(7736002)(236005)(2501003)(3280700002)(6436002)(5660300001)(38730400002)(105586002)(6246003)(77096006)(229853002)(189998001)(76176999)(54356999)(7696004)(54896002)(6306002)(66066001)(101416001)(966005)(25786009)(478600001)(55016002)(50986999)(230783001)(6506006)(8676002)(2950100002)(2906002)(14454004)(106356001)(72206003)(74316002)(68736007)(3660700001)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1786; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1788B1B880EEC2F7E9BB88AEEA8B0DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Aug 2017 08:28:14.0428 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1786 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6089> : inlines <6013> : streams <1757812> : uri <2479562> Archived-At: Subject: Re: [Dots] Some notes on ietf-dots-signal-channel-02 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 08:28:28 -0000 --_000_DM5PR16MB1788B1B880EEC2F7E9BB88AEEA8B0DM5PR16MB1788namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Dave, Thanks for the review. Please see inline. From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Thursday, July 20, 2017 8:06 AM To: dots@ietf.org Subject: [Dots] Some notes on ietf-dots-signal-channel-02 Generally I think the document is pretty good, but I found a number of ques= tions and nits. BTW, is this document in github? I was going to make a pull request, but co= uldn't find it. For target-protocol, I think could be clarified using this reference: https= ://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml [TR] Yes, updated draft. There is missing information about some filters: fqdn: which FQDN is supposed to go here? I'm unclear on what would be mitig= ated? DNS? HTTP? uri: does this mean an HTTP resource is under attack? It doesn't say HTTP. [TR] Added the following line to address the above two comments: FQDN and URI mitigation scopes may be thought of as a form of scope alias, = in which the addresses to which the domain name or URI resolve represent t= he full scope of the mitigation. lifetime: I recommend a very large number be used for no timeout. (this mi= ght be a pet peeve of mine, but why do people like to use 0 to mean infinit= e?) I think in the future we might want to use 0 to mean "end now". [TR]Instead of a large number used -1 to indicate indefinite lifetime. CBOR supports binary byte strings. Therefore I suggest that IP addresses be= represented as 4-byte or 16-byte byte-strings rather than the bulkier huma= n-readable strings that may require ~40 bytes. However, then prefixes would be represented like: "target-prefix": [ {"pref= ix": byte-string[16], "length": integer}] At this time I also suggest supporting IPv4-mapped-v6 addresses to unify IP= v4 and IPv6 code. [TR] In https://tools.ietf.org/html/rfc6021 YANG data types for IP address = and prefix (for both IPv4 and IPv6) are defined. IP addresses are prefixes = are represented using YANG string built-in type. We followed the encoding = rules given in https://tools.ietf.org/html/draft-ietf-core-yang-cbor-04#sec= tion-5.4 to represent IP address and prefix in CBOR text data string. Although multiple mitigation-ids may be set, this wording confused me: If two mitigation requests have overlapping mitigation scopes the mitigation request with higher numeric mitigation-id value will override the mitigation request with a lower numeric mitigation-id value This sounds like higher-valued IDs are supposed to replace smaller values. = But that isn't intended, I don't think. Both mitigation-IDs should be store= d, but that comment is about logic in scrubbing rules and attributing bytes= -dropped. [TR] Higher-valued ID replaces lower-valued ID only when it has overlapping= mitigations scope otherwise mitigation scopes in both higher-valued and lo= wer-valued IDs are used. I think there may be a race condition to consider, when we allow for reorde= ring: If this sequence is sent: PUT (ID=3D1) PUT (ID=3D1) DELETE (ID=3D1) But this sequence is received: PUT (ID=3D1) DELETE (ID=3D1) PUT (ID=3D1) Then the ID 1 will be incorrectly stored. The solution is that the server n= eeds to remember deleted IDs for some time. [TR] Good point, updated draft. The URIs for PUT and DELETE are specified differently (v1 and version). I s= uspect they are intended to be the same, probably "v1" ? [TR[ Yes, fixed. Currently the DELETE is specified to return an error if deleting something = not found. What is the value of this error? Why not always return 2.02, the= reby giving DELETE idempotent behavior. [TR] Yes, updated draft (return code 2.02 will be returned even if mitigati= on-id is not found). Regarding the 5min timeout after client DELETE, did we consider making that= configurable in the delete message? [TR] No. This could allow a client to be a bit smarter. If timeout=3D0, it would mea= n stop right now. [TR] Updated draft to align with the requirement SIG-005 in https://tools.i= etf.org/html/draft-ietf-dots-requirements-06; SIG-005 does not discuss conf= igurable active-but-terminating period. I'm unclear on how I would determine bps-dropped or pps-dropped. What time = denominator? (Generally I find rate measurements very difficult to compute = and explain in a way that makes everyone happy.) Can we just let the client= compute bytes/time ? [TR] bytes per second and packets per second are supported by network devic= es, BGP flow spec supports traffic rate-limit in bps and pps. The -dropped counters show a clear bias towards scrubbers that simply drop = packets. Are there other actions to be considered? E.g., DSCP marking? [TR] No, DDoS mitigator does not drop all the traffic, it drops attack traf= fic. I don't think DSCP remarking will help handle the DDoS attack ! Regarding "status", I'm unclear on what code 2 means. It sounds like all tr= affic is being dropped, but I don't consider that the most successful outco= me. [TR] No, only the attack traffic is dropped. I think it might be better to say "Mitigation is in progress within capabil= ity" (in contrast to "exceeded capability" code 4). [TR] No, "exceeded capability" is to discuss the scenario where the DDoS at= tack grows beyond the mitigating domain's capabilities (see the discussion = in https://tools.ietf.org/html/draft-ietf-dots-architecture-04#section-3.2.= 3). Regarding "observe" It says, A DOTS client that is no longer interested in receiving notifications from the DOTS server can simply "forget" the observation. More specifically, doesn't it have to make the request with "Observe=3D1" ? [TR] No, the client forgets the observation and if it receives notification= from the server then it sends reset message, this causes the server to rem= ove the associated entry from the list of observers. https://tools.ietf.org= /html/rfc7641#section-3.6 discusses this mechanism and "observer=3D1" to de= register the client. Updated draft to suggest "observe=3D1" as an alternate= mechanism. I think there may be some race conditions with the "observe" option. E.g., these messages reordered: Observe=3D0 Observe=3D1 I'm not sure what the solution is. (I didn't really read RFC7641 to see if = it was discussed) [TR] The server should return an error, but it's not discussed in RFC7641. The efficacy update seems to use the same URI as the one for requesting mit= igation. How would the server know which type of message? I suspect we inte= nded to use a different URI. Scanning the document, a second look at all of the URIs might be in order. = We want the URI to indicate the type of operation, not inferred from the co= ntent of the body. [TR] Updated draft to use if-match Option to indicate mitigation update req= uest (this option is discussed in https://tools.ietf.org/html/rfc7252#secti= on-5.10.8.1). I don't see the need for a different URI. Regarding heartbeat, what are the consequences of failure? I'm unclear on w= hat action should be taken. [TR] The DOTS client will consider that the session is terminated and may i= nitiate a new session using (D)TLS session resumption. Please note that when under attack, round-trip times might be VERY large du= e to buffer bloat. A colleague of mine measured ping times exceeding 60s in= a hotel! [TR] Yes, RTT and packet loss could be high. Heartbeats are used for multip= le reasons to keep the NAT/firewall bindings alive, check (D)TLS state is = maintained by the peer to detect if the DOTS session is terminated. To pro= vide more flexibility to the DOTS agents, CoAP heartbeat is used instead of= DTLS heartbeat. On that note, should we give guidance about application-layer time-outs? A = na=EFve implementation might pick something like 5s timeout. A client shoul= d be trying multiple transports and therefore have an async approach to wri= ting the application. [TR] Section 5.4.2 in this draft discusses various transmission parameters = to deal with adverse network conditions (heartbeat timeout, max-retransmit = and ack-timeout). https://tools.ietf.org/html/rfc7252#section-4.8.2 explai= ns the various time values derived from the default transmission parameters= . CoAP allows applications to configure the transmission parameters, and th= e default transmission parameters can be modified to max-retransmit =3D 7, = heartbeat timeout will be equal to MAX_TRANSMIT_TIME (371 seconds) and ack-= timeout can be 2 seconds. 5.4.2 Configuration: why is this a POST? I think this should be PUT, like = the others, since the intent is to replace previous configuration. [TR] Yes, updated draft to use PUT. Regarding redirected signaling, where do you get response code 3.00 from? I= t isn't listed in https://tools.ietf.org/html/rfc7252#section-12.1.2 or htt= ps://www.iana.org/assignments/core-parameters/core-parameters.xhtml#respons= e-codes . Can we use 3.00, or is there a reference you can add to the doc= ? [TR] Updated IANA considerations sections in the draft to define 3.00 (alte= rnate server) CoAP response code. Do we intend to prohibit large datagrams that will be fragmented? [TR] Yes. These are not terrible, just perhaps less likely to all arrive. I think the= wording should say that multiple mitigation requests should be created to = keep the datagram size small. [TR] It's discussed in https://tools.ietf.org/html/draft-ietf-dots-signal-c= hannel-02#section-7.1 to split the DOTS signal into separate messages when = the request size exceeds Path MTU. Cheers, -Tiru (I didn't read the security sections in detail, expecting them to change.) It looks like a lot of issues, but I think the comments are only possible b= ecause the document is good enough by having details. [Tip: track github issues for the points I've raised, if you cannot answer/= resolve them immediately] -Dave --_000_DM5PR16MB1788B1B880EEC2F7E9BB88AEEA8B0DM5PR16MB1788namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Dave,

 

Thanks for the review.  Please see inline.=

 

From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Dave Dolson
Sent: Thursday, July 20, 2017 8:06 AM
To: dots@ietf.org
Subject: [Dots] Some notes on ietf-dots-signal-channel-02=

 

Generally I think the document is pretty good, but I= found a number of questions and nits.

 

BTW, is this document in github? I was going to make= a pull request, but couldn’t find it.

 

For target-protocol, I think could be clarified usin= g this reference: https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml

 

[TR] Yes, updated draft.

 

There is missing information about some filters:

fqdn: which FQDN is supposed to go here? I’m u= nclear on what would be mitigated? DNS? HTTP?

 

uri: does this mean an HTTP resource is under attack= ? It doesn’t say HTTP.

 

[TR] Added the following line to address the above t= wo comments:

FQDN and URI mitigation scopes may be thought of as = a form of scope alias, in which the  addresses to which the domain nam= e or URI resolve represent the full scope of the mitigation.

 

lifetime:  I recommend a very large number be u= sed for no timeout. (this might be a pet peeve of mine, but why do people l= ike to use 0 to mean infinite?)  I think in the future we might want t= o use 0 to mean “end now”.

 

[TR]Instead of a large number used -1 to indicate in= definite lifetime.

 

CBOR supports binary byte strings. Therefore I sugge= st that IP addresses be represented as 4-byte or 16-byte byte-strings rathe= r than the bulkier human-readable strings that may require ~40 bytes.<= /o:p>

However, then prefixes would be represented like: &q= uot;target-prefix": [ {"prefix": byte-string[16], "leng= th": integer}]

 

At this time I also suggest supporting IPv4-mapped-v= 6 addresses to unify IPv4 and IPv6 code.

 

[TR] In https://tools.ietf.org/html/rfc6021 YANG data types for IP address = and prefix (for both IPv4 and IPv6) are defined. IP addresses are prefixes = are represented using YANG string built-in type.  We followed the encoding rules given in https://tools.ietf.org/html/draft-ietf-core-yang-cbor-04#section-5.4 to= represent IP address and prefix in CBOR text data string.   

 

Although multiple mitigation-ids may be set, this wo= rding confused me:

   If two mitigation requests<= /p>

   have overlapping mitigation scopes the mitiga= tion request with higher

   numeric mitigation-id value will override the= mitigation request with

   a lower numeric mitigation-id value

This sounds like higher-valued IDs are supposed to r= eplace smaller values. But that isn’t intended, I don’t think. = Both mitigation-IDs should be stored, but that comment is about logic in sc= rubbing rules and attributing bytes-dropped.

 

[TR] Higher-valued ID replaces lower-valued ID only = when it has overlapping mitigations scope otherwise mitigation scopes in bo= th higher-valued and lower-valued IDs are used.

 

I think there may be a race condition to consider, w= hen we allow for reordering:

If this sequence is sent:

  PUT  (ID=3D1)

  PUT (ID=3D1)

  DELETE (ID=3D1)

But this sequence is received:

  PUT (ID=3D1)

  DELETE (ID=3D1)

  PUT  (ID=3D1)

Then the ID 1 will be incorrectly stored. The soluti= on is that the server needs to remember deleted IDs for some time.

 

[TR] Good point, updated draft.

 

The URIs for PUT and DELETE are specified differentl= y (v1 and version). I suspect they are intended to be the same, probably &#= 8220;v1” ?

 

[TR[ Yes, fixed.

 

Currently the DELETE is specified to return an error= if deleting something not found. What is the value of this error? Why not = always return 2.02, thereby giving DELETE idempotent behavior.

 

[TR] Yes, updated draft (return code 2.02 will be re= turned even if mitigation-id is not found).

 

Regarding the 5min timeout after client DELETE, did = we consider making that configurable in the delete message?

 

[TR] No.

 

This could allow a client to be a bit smarter. If ti= meout=3D0, it would mean stop right now.

 

[TR] Updated draft to align with the requirement SIG= -005 in https://tools.ietf.org/html/draft-ietf-dots-requirements-06; SIG-005 do= es not discuss configurable active-but-terminating period.

 

I’m unclear on how I would determine bps-dropp= ed or pps-dropped. What time denominator? (Generally I find rate measuremen= ts very difficult to compute and explain in a way that makes everyone happy= .) Can we just let the client compute bytes/time ?

 

[TR] bytes per second and packets per second are sup= ported by network devices, BGP flow spec supports traffic rate-limit in bps= and pps.

 

The –dropped counters show a clear bias toward= s scrubbers that simply drop packets. Are there other actions to be conside= red? E.g., DSCP marking?

 

[TR] No, DDoS mitigator does not drop all the traffi= c, it drops attack traffic. I don’t think DSCP remarking will help ha= ndle the DDoS attack !

 

Regarding “status”, I’m unclear on= what code 2 means. It sounds like all traffic is being dropped, but I don&= #8217;t consider that the most successful outcome.

 

[TR] No, only the attack traffic is dropped.

 

I think it might be better to say “Mitigation = is in progress within capability” (in contrast to “exceeded cap= ability” code 4).

 

[TR] No, “exceeded capability” is to dis= cuss the scenario where the DDoS attack grows beyond the mitigating domain&= #8217;s capabilities (see the discussion in https://tools.ietf.org/html/draft-ietf-dots-architecture-04#section-3.2.3).

 

 

Regarding “observe” It says,<= /p> 

    A DOTS client that is no longer
   interested in receiving notifications from the DOTS serve=
r can simply
   "forget" the observation.

More specifically, doesn’t it have to make the= request with “Observe=3D1” ?

 

[TR] No, the client forgets the observation and if i= t receives notification from the server then it sends reset message, this c= auses the server to remove the associated entry from the list of observers. https://tools.i= etf.org/html/rfc7641#section-3.6 discusses this mechanism and “ob= server=3D1” to deregister the client. Updated draft to suggest “= ;observe=3D1” as an alternate mechanism.

 

I think there may be some race conditions with the &= #8220;observe” option.

E.g., these messages reordered:

  Observe=3D0

  Observe=3D1

I’m not sure what the solution is. (I didnR= 17;t really read RFC7641 to see if it was discussed)

 

[TR] The server should return an error, but it’= ;s not discussed in RFC7641.

 

The efficacy update seems to use the same URI as the= one for requesting mitigation. How would the server know which type of mes= sage? I suspect we intended to use a different URI.

Scanning the document, a second look at all of the U= RIs might be in order. We want the URI to indicate the type of operation, n= ot inferred from the content of the body.

 

[TR] Updated draft to use if-match Option to indicat= e mitigation update request (this option is discussed in https://to= ols.ietf.org/html/rfc7252#section-5.10.8.1). I don’t see the need= for a different URI.

 

Regarding heartbeat, what are the consequences of fa= ilure? I’m unclear on what action should be taken.

 

[TR] The DOTS client will consider that the session = is terminated and may initiate a new session using (D)TLS session resumptio= n.

 

Please note that when under attack, round-trip times= might be VERY large due to buffer bloat. A colleague of mine measured ping= times exceeding 60s in a hotel!

 

[TR] Yes, RTT and packet loss could be high. Heartbe= ats are used for multiple reasons to keep the NAT/firewall bindings alive,&= nbsp; check (D)TLS state is maintained by the peer to detect if the DOTS se= ssion is terminated.  To provide more flexibility to the DOTS agents, CoAP heartbeat is used instead of DTLS heartbeat.

 

On that note, should we give guidance about applicat= ion-layer time-outs? A na=EFve implementation might pick something like 5s = timeout. A client should be trying multiple transports and therefore have a= n async approach to writing the application.

 

[TR] Section 5.4.2 in this draft discusses various t= ransmission parameters to deal with adverse network conditions (heartbeat t= imeout, max-retransmit and ack-timeout).  https://tools= .ietf.org/html/rfc7252#section-4.8.2 explains the various time values d= erived from the default transmission parameters. CoAP allows applications t= o configure the transmission parameters, and the default transmission parameters can be modified to max-retransmit = =3D 7, heartbeat timeout will be equal to MAX_TRANSMIT_TIME (371 seconds) a= nd ack-timeout can be 2 seconds.

 

5.4.2 Configuration: why is this a POST?  I thi= nk this should be PUT, like the others, since the intent is to replace prev= ious configuration.

 

[TR] Yes, updated draft to use PUT.

 

Regarding redirected signaling, where do you get res= ponse code 3.00 from? It isn’t listed in https://tool= s.ietf.org/html/rfc7252#section-12.1.2 or https://www.iana.org/assignments/core-parameters/core-parameters.xhtml#resp= onse-codes  .  Can we use 3.00, or is there a reference you c= an add to the doc?

 

[TR] Updated IANA considerations sections in the dra= ft to define 3.00 (alternate server) CoAP response code.

 

Do we intend to prohibit large datagrams that will b= e fragmented?

 

[TR] Yes.

 

These are not terrible, just perhaps less likely to = all arrive. I think the wording should say that multiple mitigation request= s should be created to keep the datagram size small.

 

[TR] It’s discussed in https://tools.ietf.org/html/draft-ietf-dots-signal-channel-02#section-7.1 to split the DOTS signal into separate messages when the request size ex= ceeds Path MTU.

 

Cheers,

-Tiru

 

(I didn’t read the security sections in detail= , expecting them to change.)

 

It looks like a lot of issues, but I think the comme= nts are only possible because the document is good enough by having details= .

 

[Tip: track github issues for the points I’ve = raised, if you cannot answer/resolve them immediately]

-Dave

 

 

--_000_DM5PR16MB1788B1B880EEC2F7E9BB88AEEA8B0DM5PR16MB1788namp_-- From nobody Wed Aug 16 23:36:42 2017 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 03D66126B7E; Wed, 16 Aug 2017 23:36:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150295179396.12129.10316969585965576564@ietfa.amsl.com> Date: Wed, 16 Aug 2017 23:36:34 -0700 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-signal-channel-03.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for 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, 17 Aug 2017 06:36:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DDoS Open Threat Signaling WG of the IETF. Title : Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Authors : Tirumaleswar Reddy Mohamed Boucadair Prashanth Patil Andrew Mortensen Nik Teague Filename : draft-ietf-dots-signal-channel-03.txt Pages : 49 Date : 2017-08-16 Abstract: This document specifies the DOTS signal channel, a protocol for signaling the need for protection against Distributed Denial-of- Service (DDoS) attacks to a server capable of enabling network traffic mitigation on behalf of the requesting client. A companion document defines the DOTS data channel, a separate reliable communication layer for DOTS management and configuration. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-signal-channel-03 https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-signal-channel-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Aug 16 23:48:46 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28DC5132457 for ; Wed, 16 Aug 2017 23:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVVM-R5XJlWI for ; Wed, 16 Aug 2017 23:48:42 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 C4D13132665 for ; Wed, 16 Aug 2017 23:48:41 -0700 (PDT) Received: from MIVEXAPP1N01.corpzone.internalzone.com (unknown [10.48.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp id 395f_c661_08fb0d30_3759_4ac8_8c64_7539cee58f82; Thu, 17 Aug 2017 01:48:40 -0500 Received: from MIVEXUSR1N03.corpzone.internalzone.com (10.48.48.83) by MIVEXAPP1N01.corpzone.internalzone.com (10.48.48.88) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 17 Aug 2017 02:48:39 -0400 Received: from MIVEXUSR1N06.corpzone.internalzone.com (10.48.48.86) by MIVEXUSR1N03.corpzone.internalzone.com (10.48.48.83) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 17 Aug 2017 02:48:38 -0400 Received: from MIVO365EDGE4.corpzone.internalzone.com (10.48.176.87) by MIVEXUSR1N06.corpzone.internalzone.com (10.48.48.86) with Microsoft SMTP Server (TLS) id 15.0.1263.5 via Frontend Transport; Thu, 17 Aug 2017 02:48:38 -0400 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (10.48.176.243) by edge.mcafee.com (10.48.176.87) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 17 Aug 2017 02:48:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.onmicrosoft.com; s=selector1-mcafee-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FGbOIfLiRk3r/AGqP+/+w+l5gDgpI26GEu7ojJD+MfM=; b=YgmLeXel+cRpjRf4S+Ajsss3qEBqtaKOUoJhuTkpkRguxgCSta0B1fNf29GsyAvU4nimcHi88yenLPIU0/KlBWUvknTezTl2s7vbrher51mI94BmlueDayp3tHYSHKAHoFyCV1SkSXYYGjbW1oECvr2sAmRpkFZY+vcyOb/RBIE= Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1341.21; Thu, 17 Aug 2017 06:48:35 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.01.1341.023; Thu, 17 Aug 2017 06:48:35 +0000 From: "Konda, Tirumaleswar Reddy" To: "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-signal-channel-03.txt Thread-Index: AQHTFyNXyCzKUAzEJ0uNJP3odKDn/KKIGlOg Date: Thu, 17 Aug 2017 06:48:35 +0000 Message-ID: References: <150295179396.12129.10316969585965576564@ietfa.amsl.com> In-Reply-To: <150295179396.12129.10316969585965576564@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1788; 6:JzvSLFy/NtbTK5aVJXwfmUHWk1+D+7obZkFzMaL2d8An1XEUK5Hga68ebYvb+0SZl0es7GeZYPPkImY1cv03u/tRRjTAr/V+y3VMxv2lAxIk3XMjVtaLogznqn6pF/0QxJHNQWu+PVg8LsYYtmyMs91qNRS61TnwpC1kSjmOmGgRBU2w6PHT/SqsRcvMLqKmDX6jmyViDRjYkJsCymaIw+JerdJ8xy8g7EEykMOIlfYW6IB++3BHFOqqcaFwkgcCEy+nMXF+7u80dkTSXAQy2TkzBx4qd4693IKL4es1qPAA2sbjMgUZvIGMCmBomLxgeAA0kAcS/JHWE6Y9x/XAxA==; 5:W2+Bj4We39qiWBInSfpieqWUGGsWyzG/90p/+XV6iMoiZtpEXzuO0me64jJNN5U2OCn9jgS52wJEHFJiX6du105+yfS+huOZlN5vwqPiSGXPCGTMQD34gilnpJQiulwjnYgGL83hdt9ko/SmUE8GXw==; 24:kkV0LgY8Gsben2LZcBlJmIlhi/jmmZEccfrZsmySi/9/fwB136FmyUf4+9g5zjNUuu3o0J9Lk43pFNib1RRgLvYUUqEsawirQVgk7fHhPFE=; 7:dyshCrWR9XQpik3Uvji3bwCjglTef8X2WahvkXq4MdXlyRcPF0Ok+/8RqUIVEeW0dxT2Y3MIVDypuG7WYDa5Z//yd4U3pxKgKSC82/mOQXhWiQ8yegFZrSzQ5we/dxo16y0b9Vy2FAoCaQPEbVfvJycEa3JCwlyoqesWWYw7aZcoQmWitVj3+cEmRV6qO9BAat+1CUqr19bNzbo+PdaWuFv6etNJXUtRMOxSEhCy/Gk= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 3a17b60a-dd8f-40a4-d348-08d4e53bfbef x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603157)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM5PR16MB1788; x-ms-traffictypediagnostic: DM5PR16MB1788: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1788; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1788; x-forefront-prvs: 0402872DA1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(377424004)(189002)(13464003)(377454003)(32952001)(6506006)(1730700003)(478600001)(68736007)(53546010)(8676002)(6436002)(81156014)(81166006)(6116002)(74316002)(66066001)(8936002)(6246003)(3846002)(102836003)(80792005)(110136004)(5640700003)(2501003)(229853002)(97736004)(2950100002)(6916009)(86362001)(50986999)(76176999)(55016002)(2900100001)(966005)(230783001)(53936002)(99286003)(305945005)(77096006)(189998001)(5660300001)(7696004)(2906002)(101416001)(105586002)(7736002)(33656002)(9686003)(72206003)(2351001)(25786009)(6306002)(3280700002)(14454004)(54356999)(106356001)(3660700001)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1788; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Aug 2017 06:48:35.6430 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1788 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6095> : inlines <6024> : streams <1758944> : uri <2484619> Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-03.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for 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, 17 Aug 2017 06:48:44 -0000 This revision addresses comments from Dave and Jon. -Tiru > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Thursday, August 17, 2017 12:07 PM > To: i-d-announce@ietf.org > Cc: dots@ietf.org > Subject: [Dots] I-D Action: draft-ietf-dots-signal-channel-03.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the DDoS Open Threat Signaling WG of the IET= F. >=20 > Title : Distributed Denial-of-Service Open Threat Signa= ling (DOTS) > Signal Channel > Authors : Tirumaleswar Reddy > Mohamed Boucadair > Prashanth Patil > Andrew Mortensen > Nik Teague > Filename : draft-ietf-dots-signal-channel-03.txt > Pages : 49 > Date : 2017-08-16 >=20 > Abstract: > This document specifies the DOTS signal channel, a protocol for > signaling the need for protection against Distributed Denial-of- > Service (DDoS) attacks to a server capable of enabling network > traffic mitigation on behalf of the requesting client. A companion > document defines the DOTS data channel, a separate reliable > communication layer for DOTS management and configuration. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dots-signal-channel-03 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-03 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-signal-channel-03 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Fri Aug 18 04:08:17 2017 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9B11323B4; Fri, 18 Aug 2017 04:08:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150305448949.14177.18025525114027475875@ietfa.amsl.com> Date: Fri, 18 Aug 2017 04:08:09 -0700 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-data-channel-03.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 11:08:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DDoS Open Threat Signaling WG of the IETF. Title : Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Authors : Tirumaleswar Reddy Mohamed Boucadair Kaname Nishizuka Liang Xia Prashanth Patil Andrew Mortensen Nik Teague Filename : draft-ietf-dots-data-channel-03.txt Pages : 25 Date : 2017-08-18 Abstract: The document specifies a Distributed Denial-of-Service Open Threat Signaling (DOTS) data channel used for bulk exchange of data not easily or appropriately communicated through the DOTS signal channel under attack conditions. This is a companion document to the DOTS signal channel specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-data-channel/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-data-channel-03 https://datatracker.ietf.org/doc/html/draft-ietf-dots-data-channel-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-data-channel-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Aug 18 04:11:04 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE021326A0 for ; Fri, 18 Aug 2017 04:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z6Zt5_Ro6Hqq for ; Fri, 18 Aug 2017 04:11:01 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 259491321EB for ; Fri, 18 Aug 2017 04:11:01 -0700 (PDT) Received: from MIVEXAPP1N03.corpzone.internalzone.com (unknown [10.48.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp id 6ea6_1ac3_768d15c5_555d_46e3_834e_4a7b4a25bb6d; Fri, 18 Aug 2017 06:10:59 -0500 Received: from MIVEXUSR1N04.corpzone.internalzone.com (10.48.48.84) by MIVEXAPP1N03.corpzone.internalzone.com (10.48.48.90) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 18 Aug 2017 07:10:49 -0400 Received: from MIVEXAPP1N01.corpzone.internalzone.com (10.48.48.88) by MIVEXUSR1N04.corpzone.internalzone.com (10.48.48.84) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 18 Aug 2017 07:10:48 -0400 Received: from MIVO365EDGE3.corpzone.internalzone.com (10.48.176.86) by MIVEXAPP1N01.corpzone.internalzone.com (10.48.48.88) with Microsoft SMTP Server (TLS) id 15.0.1263.5 via Frontend Transport; Fri, 18 Aug 2017 07:10:48 -0400 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (10.48.176.242) by edge.mcafee.com (10.48.176.86) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 18 Aug 2017 07:10:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.onmicrosoft.com; s=selector1-mcafee-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4acenJUqtDruJgC46cHrqN47dmn2VsxG1qTcXSLh+H0=; b=PFHGU3JAIi/OLrwJhfmbrQtV31w3dDOPjQLhQDVY6mo0yepOCiUaq9uuJETSx5df9x+jvaWrwaZCzUcRZRu5ROQ4DhzCMsfW5gDa7yPp7ccZyXq+AfmP8fdwcQq5KAMxRgoK/i5Cjjhm2W0HQ8S6C8eIZEK3WwWUOT9mRhUPYbg= Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1372.namprd16.prod.outlook.com (10.173.210.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.22; Fri, 18 Aug 2017 11:10:46 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.01.1362.019; Fri, 18 Aug 2017 11:10:46 +0000 From: "Konda, Tirumaleswar Reddy" To: "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-data-channel-03.txt Thread-Index: AQHTGBJpcAF1RKsdCkCKSVOqFNzqDKKJ9NmQ Date: Fri, 18 Aug 2017 11:10:46 +0000 Message-ID: References: <150305448949.14177.18025525114027475875@ietfa.amsl.com> In-Reply-To: <150305448949.14177.18025525114027475875@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1372; 7:dZ/iFy2+tjBNx2Z4Qa7e1mmlrLSA4Jt0gGCQi+NA6oSHYa87Kqsd6NgVBAa6ezqZseRxAYC/bSIBTPulRICq2txJmSvv/V8fw3TWyuFLTbiraQrkNUkC+vgr87GlSESRy+XD5PAb8RwowCw9saMcbN6LvkE8rvw6QTnGbmIEIOt+CucVbdGNoF8erwEKNaHnQsrEAng6VjHHEs+rjBFbZLjLKFj1PJdD06CN2qy87Wk0yRl5X8rUFryRc+P29Y4XDmwkYirSkgDl+CIGp+vDFiRUEnrzywxMT7Nryzdx+LeN2FQZukVmsSGS0J7TApZTCRU0QsbVcaywGPozwDKp8DCFpp/blcG41DMZJhNsTx6BngR3VI2Gg9hswHhoMkXibaf2UoTe4AUB2g3jlXRS+2yJOwmv1+i4SHLAJlBrTSfoOd9Z30p/bf7R/7vAgDN16C7kFRuFoIy0Mqgqat0XQUYOr9I4fDdrCD1KVJ+NcakZ2lzyTxVPnCJHysYZsCV0HVRmBqiHq6W3QsKV0UJAx7NFZRCfIx6LqrD5cfLLF4K5D3pmOfjmYBg86xrd6qw0IZBmnbN2Tnf1WIvKlUvXs1xLXpCMBqCYkEsT15e4VZ6RZR/13Er9+ZG5Bh6DdeLzrQl9YSEZETmaL5omc6vRvA33jj/j8lSObwpKKxe0Kl1t+cE0PqgW6ZnWNKDQWWOStdnjWiyVpvBlTd6FsthqwMoybht7b0sA03RZloaKwTllwJUDKWS+TtdtPEgnbt//Dnrz2ZjmfZE+po0cxHA/2hVnCDVtipt7xywrgoPCfI0= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 53a5e6ab-3a21-4d07-7f98-08d4e629c67a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM5PR16MB1372; x-ms-traffictypediagnostic: DM5PR16MB1372: x-exchange-antispam-report-test: UriScan:(120809045254105); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(3002001)(93006095)(93001095)(10201501046)(6041248)(20161123558100)(20161123555025)(20161123564025)(20161123560025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1372; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1372; x-forefront-prvs: 040359335D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(189002)(377424004)(32952001)(377454003)(13464003)(66066001)(76176999)(1730700003)(25786009)(97736004)(478600001)(5660300001)(2906002)(7736002)(229853002)(72206003)(14454004)(2900100001)(81156014)(6246003)(53546010)(105586002)(305945005)(80792005)(8676002)(77096006)(6116002)(86362001)(110136004)(9686003)(74316002)(54356999)(81166006)(230783001)(3660700001)(33656002)(50986999)(2501003)(8936002)(101416001)(6306002)(2950100002)(3846002)(102836003)(966005)(6506006)(5640700003)(3280700002)(7696004)(55016002)(106356001)(6436002)(53936002)(189998001)(99286003)(68736007)(6916009)(2351001)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1372; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Aug 2017 11:10:46.3096 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1372 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6096> : inlines <6028> : streams <1759113> : uri <2485348> Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-data-channel-03.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 11:11:03 -0000 https://tools.ietf.org/html/draft-ietf-dots-data-channel-03 addresses comme= nts from Jon. -Tiru > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Friday, August 18, 2017 4:38 PM > To: i-d-announce@ietf.org > Cc: dots@ietf.org > Subject: [Dots] I-D Action: draft-ietf-dots-data-channel-03.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the DDoS Open Threat Signaling WG of the IET= F. >=20 > Title : Distributed Denial-of-Service Open Threat Signa= ling (DOTS) > Data Channel > Authors : Tirumaleswar Reddy > Mohamed Boucadair > Kaname Nishizuka > Liang Xia > Prashanth Patil > Andrew Mortensen > Nik Teague > Filename : draft-ietf-dots-data-channel-03.txt > Pages : 25 > Date : 2017-08-18 >=20 > Abstract: > The document specifies a Distributed Denial-of-Service Open Threat > Signaling (DOTS) data channel used for bulk exchange of data not > easily or appropriately communicated through the DOTS signal channel > under attack conditions. This is a companion document to the DOTS > signal channel specification. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dots-data-channel/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dots-data-channel-03 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-data-channel-03 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-data-channel-03 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Wed Aug 30 07:01:04 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E178132E9C for ; Wed, 30 Aug 2017 07:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhGX-ahkKE0r for ; Wed, 30 Aug 2017 07:00:55 -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 A1F7E132E3D for ; Wed, 30 Aug 2017 07:00:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 9991262161 for ; Wed, 30 Aug 2017 10:00:54 -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 S-psk4YhM4AG for ; Wed, 30 Aug 2017 10:00:48 -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 06606621A2 for ; Wed, 30 Aug 2017 10:00:47 -0400 (EDT) To: "dots@ietf.org" From: Robert Moskowitz Message-ID: Date: Wed, 30 Aug 2017 10:00:46 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [Dots] New draft - guide to creating an ECDSA pki X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for 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, 30 Aug 2017 14:01:03 -0000 I have spoken to the need for Identities in DOTS agents. This implies using X.509 certificates and making sure they work in your product. But getting decent certificates for PoC and testing has been challenging. To this end, I have created a guide and put it together in an ID. I am interested in working with those participating in the Hackathon to put together the DOTS Hackaton PKI. Bob -------- Forwarded Message -------- Subject: New Version Notification for draft-moskowitz-ecdsa-pki-00.txt Date: Wed, 30 Aug 2017 06:53:03 -0700 From: internet-drafts@ietf.org To: Robert Moskowitz , Liang Xia , Henk Birkholz , Liang Xia A new version of I-D, draft-moskowitz-ecdsa-pki-00.txt has been successfully submitted by Robert Moskowitz and posted to the IETF repository. Name: draft-moskowitz-ecdsa-pki Revision: 00 Title: Guide for building an ECC pki Document date: 2017-08-30 Group: Individual Submission Pages: 26 URL: https://www.ietf.org/internet-drafts/draft-moskowitz-ecdsa-pki-00.txt Status: https://datatracker.ietf.org/doc/draft-moskowitz-ecdsa-pki/ Htmlized: https://tools.ietf.org/html/draft-moskowitz-ecdsa-pki-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-moskowitz-ecdsa-pki-00 Abstract: This memo provides a guide for building a PKI (Public Key Infrastructure) using openSSL. All certificates in this guide are ECDSA, P-256, with SHA256 certificates. Along with common End Entity certificates, this guide provides instructions for creating IEEE 802.1AR [IEEE.802.1AR_2009] iDevID Secure Device certificates. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Wed Aug 30 09:19:27 2017 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AD64C132025; Wed, 30 Aug 2017 09:19:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: rdd@cert.org, dots-chairs@ietf.org, Kathleen.Moriarty.ietf@gmail.com, dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150410996565.21607.11671705230020255233.idtracker@ietfa.amsl.com> Date: Wed, 30 Aug 2017 09:19:25 -0700 Archived-At: Subject: [Dots] dots - New Meeting Session Request for IETF 100 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for 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, 30 Aug 2017 16:19:26 -0000 A new meeting session request has just been submitted by Roman Danyliw, a Chair of the dots working group. --------------------------------------------------------- Working Group Name: DDoS Open Threat Signaling Area Name: Security Area Session Requester: Roman Danyliw Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: mile i2nsf sacm saag Second Priority: opsawg People who must be present: Kathleen Moriarty Roman Danyliw Tobias Gondrom Resources Requested: Special Requests: --------------------------------------------------------- From nobody Wed Aug 30 11:01:14 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D568132803 for ; Wed, 30 Aug 2017 11:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JokazcWSaX4n for ; Wed, 30 Aug 2017 11:01:11 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59F7F132518 for ; Wed, 30 Aug 2017 11:01:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2587; q=dns/txt; s=iport; t=1504116071; x=1505325671; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=EPKbrcmveQh2rlUrOitUDtfT49Vl4Mek9P4Jg1S5JrM=; b=ZxR1WVgVvTYhkZ+EOHiKMhYHPBSV3CGc5d3qVPRbUgrcV1A9AV0WAxTY CBTu02dRF6agaq8+uq2NGcNoaea5oj+R0G5fEA9NqvpIIFCnRF02BiD0P OOoXtCpRwMNxTKzbKQ5iSByAkPlZGECjE1Lm4c5lCeiaEaI9F6kXV9W/W M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CbAADm/KZZ/4MNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkgRUHjg6QG4FxlieCEiELhRsChCc/GAECAQEBAQEBAWsohRg?= =?us-ascii?q?BAQEBAwEBODQXBAIBCA4DAwEBAR8JBycLFAkIAgQBEgiKKRCvLotDAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBHYMqggKBToULhHyFbQWRJY9HAodXjGqCG1qFDYpylkI?= =?us-ascii?q?BHziBDXcVHyqHG3YBiXwBgQ4BAQE?= X-IronPort-AV: E=Sophos;i="5.41,449,1498521600"; d="scan'208";a="450687097" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Aug 2017 18:01:10 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v7UI1Aen025322 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 30 Aug 2017 18:01:10 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 30 Aug 2017 13:01:09 -0500 Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1263.000; Wed, 30 Aug 2017 13:01:09 -0500 From: "Panos Kampanakis (pkampana)" To: Robert Moskowitz , "dots@ietf.org" Thread-Topic: [Dots] New draft - guide to creating an ECDSA pki Thread-Index: AQHTIZhwOgqHxUJ5U0G+S/Z1xg3K1KKc7vKw Date: Wed, 30 Aug 2017 18:01:09 +0000 Message-ID: <9583d33741394dc99d81a7f219bda4f4@XCH-ALN-010.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [64.102.56.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] New draft - guide to creating an ECDSA pki X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for 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, 30 Aug 2017 18:01:13 -0000 Are you envisioning this to be a draft adopted in DOTS WG? It would make a = nice whitepaper for DOTS adopters for the hackathon, but I am not sure a te= chnical document on how to use common tools to set up PKI is suitable for a= n IETF draft.=20 -----Original Message----- From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Robert Moskowitz Sent: Wednesday, August 30, 2017 10:01 AM To: dots@ietf.org Subject: [Dots] New draft - guide to creating an ECDSA pki I have spoken to the need for Identities in DOTS agents. This implies usin= g X.509 certificates and making sure they work in your product. But gettin= g decent certificates for PoC and testing has been challenging. To this end, I have created a guide and put it together in an ID. I am int= erested in working with those participating in the Hackathon to put togethe= r the DOTS Hackaton PKI. Bob -------- Forwarded Message -------- Subject: New Version Notification for draft-moskowitz-ecdsa-pki-00.txt Date: Wed, 30 Aug 2017 06:53:03 -0700 From: internet-drafts@ietf.org To: Robert Moskowitz , Liang Xia=20 , Henk Birkholz , Liang Xia A new version of I-D, draft-moskowitz-ecdsa-pki-00.txt has been successfully submitted by Robert Moskowitz and posted to the IETF repository. Name: draft-moskowitz-ecdsa-pki Revision: 00 Title: Guide for building an ECC pki Document date: 2017-08-30 Group: Individual Submission Pages: 26 URL: https://www.ietf.org/internet-drafts/draft-moskowitz-ecdsa-pki-00.txt Status: https://datatracker.ietf.org/doc/draft-moskowitz-ecdsa-pki/ Htmlized: https://tools.ietf.org/html/draft-moskowitz-ecdsa-pki-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-moskowitz-ecdsa-pki-0= 0 Abstract: This memo provides a guide for building a PKI (Public Key Infrastructure) using openSSL. All certificates in this guide are ECDSA, P-256, with SHA256 certificates. Along with common End Entity certificates, this guide provides instructions for creating IEEE 802.1AR [IEEE.802.1AR_2009] iDevID Secure Device certificates. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Wed Aug 30 11:18:47 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C50D13217D for ; Wed, 30 Aug 2017 11:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvkrIGDX53UI for ; Wed, 30 Aug 2017 11:18:44 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF6F6132355 for ; Wed, 30 Aug 2017 11:18:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 27E0562140; Wed, 30 Aug 2017 14:18:43 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id nofqleVxEaIf; Wed, 30 Aug 2017 14:18:36 -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 9A31E621E3; Wed, 30 Aug 2017 14:18:35 -0400 (EDT) To: "Panos Kampanakis (pkampana)" , "dots@ietf.org" References: <9583d33741394dc99d81a7f219bda4f4@XCH-ALN-010.cisco.com> From: Robert Moskowitz Message-ID: Date: Wed, 30 Aug 2017 14:18:32 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <9583d33741394dc99d81a7f219bda4f4@XCH-ALN-010.cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Dots] New draft - guide to creating an ECDSA pki X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for 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, 30 Aug 2017 18:18:46 -0000 I do not see it as a DOTS document. I would like to seem some wg like LAMPS take it on. But even that would take a LAMPS charter change. I did this as a draft, because, frankly, there is no guide out there and I know that some workgroups are just at best winging it. As well as those that DO SOMETHING, grap some RSA tip and don't look at ECDSA. Thus it is a guidance document for wgs like DOTS. Is what you want to do, workable? Don't you need some certs and trust proofs for your Hackahon? And for NETCONF to start with this, then do their vouchers (and ANIMA as well). BTW, I will rev this for Ed25519 at some point. Bob On 08/30/2017 02:01 PM, Panos Kampanakis (pkampana) wrote: > Are you envisioning this to be a draft adopted in DOTS WG? It would make a nice whitepaper for DOTS adopters for the hackathon, but I am not sure a technical document on how to use common tools to set up PKI is suitable for an IETF draft. > > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Robert Moskowitz > Sent: Wednesday, August 30, 2017 10:01 AM > To: dots@ietf.org > Subject: [Dots] New draft - guide to creating an ECDSA pki > > I have spoken to the need for Identities in DOTS agents. This implies using X.509 certificates and making sure they work in your product. But getting decent certificates for PoC and testing has been challenging. > > To this end, I have created a guide and put it together in an ID. I am interested in working with those participating in the Hackathon to put together the DOTS Hackaton PKI. > > Bob > > > > > -------- Forwarded Message -------- > Subject: New Version Notification for draft-moskowitz-ecdsa-pki-00.txt > Date: Wed, 30 Aug 2017 06:53:03 -0700 > From: internet-drafts@ietf.org > To: Robert Moskowitz , Liang Xia > , Henk Birkholz , Liang Xia > > > A new version of I-D, draft-moskowitz-ecdsa-pki-00.txt > has been successfully submitted by Robert Moskowitz and posted to the > IETF repository. > > Name: draft-moskowitz-ecdsa-pki > Revision: 00 > Title: Guide for building an ECC pki > Document date: 2017-08-30 > Group: Individual Submission > Pages: 26 > URL: https://www.ietf.org/internet-drafts/draft-moskowitz-ecdsa-pki-00.txt > Status: https://datatracker.ietf.org/doc/draft-moskowitz-ecdsa-pki/ > Htmlized: https://tools.ietf.org/html/draft-moskowitz-ecdsa-pki-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-moskowitz-ecdsa-pki-00 > > > Abstract: > This memo provides a guide for building a PKI (Public Key > Infrastructure) using openSSL. All certificates in this guide are > ECDSA, P-256, with SHA256 certificates. Along with common End Entity > certificates, this guide provides instructions for creating IEEE > 802.1AR [IEEE.802.1AR_2009] iDevID Secure Device certificates. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > From nobody Thu Aug 31 05:10:39 2017 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1502E132D56 for ; Thu, 31 Aug 2017 05:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGDVgW-7vlIT for ; Thu, 31 Aug 2017 05:10:31 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91B97132C28 for ; Thu, 31 Aug 2017 05:10:29 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id g18so1989819lfl.2 for ; Thu, 31 Aug 2017 05:10:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=2owIF3sL2aTsdehezYH649/USSZHLfr7eHu/YxWi2/g=; b=iIIrfrTFIvrp/QCgOO40kH1OtNy3AaOx0iUkJPcbJYEBO89bZ5LJ8+fMUMaofl3CTu 72LPiHFZGJo+OFVnjlc06d8Uloje0p9KY/OaELI972aDQoZLc+XXI4z+tsljuiHn2P5j dzHxxl442wtWE/mziF2E7SPbP+nlLCBDY1S06RoYcGEpwQXU5LRfDwAgP7IfOrN0rnNy UC4FDAm+aBrWy7I4+KRwEdnpXc2zUiU4RQLgOvkP5FEQn60bsV0e1BYse2P0cl3s3S75 bbm24uZimYguxvXA/IXyH1RX1Llk+Imd1kLMOUKYBmLsSfqGuNVa+1ri93QKw68BQvy9 f50Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=2owIF3sL2aTsdehezYH649/USSZHLfr7eHu/YxWi2/g=; b=Q98abdsxcQH6wvyzuzqAE+ULyiYvLVv6ButGn1rI73ejhZzgdyOBinVjp5JGP/SPuL tC2O4AxCf2YsTLCEM2Xqse2yLgq7emhBmYgU+SzK9xZqKX+8qNUeuXH0MujLXeWOiWsq qjbys1s61YEHdMnrJFk49UyGmDzNFvlnLDUk9+kFo2lryZKG+6kG8twf18pPkg3URIgZ yJNoB4EZoG/9wokxe/x8Mwfy2LLPo3HHng3S6OZLx+Hv5FOS130b9H15pQ1V70XUSr7U 3L2Mec5ds1k7XShLaABxmIUBsEIpTuTGs5gQdQcotiJDhzoovEveJifJ0gJUNLIKPO8A SHkg== X-Gm-Message-State: AHPjjUhjRkPjiwNLMrQLqaCHSqJPKKY2qITGkSzyOW4e3bc8Ki40M4my WTfKVgWKHBwSLcM2l24iLD+1vA32XopKTqQ= X-Google-Smtp-Source: ADKCNb62ZgsZdFaKrv3LVIaoqW3oYDxwna2y4km7WugMqsByG7j8skIHdxy+EDVRy47vNjz08nZcCRfSVGA6rd6VsTc= X-Received: by 10.25.203.149 with SMTP id b143mr1928009lfg.200.1504181427513; Thu, 31 Aug 2017 05:10:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.16.31 with HTTP; Thu, 31 Aug 2017 05:10:26 -0700 (PDT) From: Mayank Bhatnagar Date: Thu, 31 Aug 2017 17:40:26 +0530 Message-ID: To: dots@ietf.org Content-Type: multipart/alternative; boundary="94eb2c19b63aaa312805580b87d2" Archived-At: Subject: [Dots] Reg some doubts over DOTS USe cases document draft-ietf-dots-use-cases-07 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for 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, 31 Aug 2017 12:10:38 -0000 --94eb2c19b63aaa312805580b87d2 Content-Type: text/plain; charset="UTF-8" hi all, I am Mayank Bhatnagar, aiming for discussions & paritcipations in the project. I have started reading the use cases, ref architecture and requirements. Here are some doubts wrt the Use cases document. If anyone can point out (yes or no) that these may have been addressed or are not part of scope of the work, please comment so that I can base my understanding further. thanks a lot for your time, regards, Mayank Bhatnagar ================================================ 1. DOTS client and DOTs server After reading the same I assume the standard aims to have a DOTS client installed with an end customer in form of an Internet facing end entity or the web server. Please cofnirm if following is in afirmative - An organisation should have to necessariy install a DOTS client if it has to reach out to a DOTS server - If in case of situation of 3.1.4 of draft-ietf-dots-use-cases-07, it is assumed an organisation already may or may not have an on-premise mitigation capability. Then do we assume they need to install DOTS client? Home Network, CPE collaboration with upstream ISP vendors's DDoS mitigation system - It is imp to note that the traffic which may be suspicious for a MSSP may be normal for a home or SOHO based customer, hence a DOTS server at MSSP may enquire a suspicious traffic. However my query is that a DDoS is not always a single flow. To relate a particular traffic and idenfity it so that it can be queried from a DOTS server at MSSP with a CPE router having a DOTS client, is not easy. These 2 entities need to define the characteristics of the traffic. So, we can add to the models of the various means to characterise the traffic so that these 2 entities can discuss it wthout human intervention? DOTS between MSSP and DDoS information Sharing model - Does DOTS Orchestrator discusses the DDoS information wth other clients of MSSP or shares it with other DOTS entities for a proactive response action It could happen the DDoS attack is happening across the clients of MSSP Is this part of Orchestrator responsibilites too? ================================================ --94eb2c19b63aaa312805580b87d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

hi all,

I am Ma= yank Bhatnagar, aiming for discussions & paritcipations in the project.= I have started reading the use cases, ref architecture and requirements.= =C2=A0

Here are some doubts wrt the Use cases docu= ment.=C2=A0
If anyone can point out (yes or no) that these may ha= ve been addressed or are not part of scope of the work, please comment so t= hat I can base my understanding further.

thanks a = lot for your time,=C2=A0
regards,
Mayank Bhatnagar


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

1. DOTS client = and DOTs server
After reading the same I assume the standard aims= to have a DOTS client installed with an end customer in form of an Interne= t facing end entity or the web server.=C2=A0
Please cofnirm if fo= llowing is in afirmative
- An organisation should have to necessa= riy install a DOTS client if it has to reach out to a DOTS server
- If in case of situation of 3.1.4 of draft-ietf-dots-use-cases-07, it is = assumed an organisation already may or may not have an on-premise mitigatio= n capability. Then do we assume they need to install DOTS client?
=C2=A0




Home Network, CPE collaboration with upstream ISP vendors's DDoS mit= igation system
- It is imp to note that the traffic which may be = suspicious for a MSSP may be normal for a home or SOHO based customer, henc= e a DOTS server at MSSP may enquire a suspicious traffic.
However= my query is that a DDoS is not always a single flow. To relate a particula= r traffic and idenfity it so that it can be queried from a DOTS server at M= SSP with a CPE router having a DOTS client, is not easy. These 2 entities n= eed to define the characteristics of the traffic.
So, we can add = to the models of the various means to characterise the traffic so that thes= e 2 entities can discuss it wthout human intervention?=C2=A0

=


DOTS between MSSP and DDoS informa= tion Sharing model
- Does DOTS Orchestrator discusses the DDoS in= formation wth other clients of MSSP or shares it with other DOTS entities f= or a proactive response action
It could happen the DDoS attack is= happening across the clients of MSSP
Is this part of Orchestrato= r responsibilites too?



=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --94eb2c19b63aaa312805580b87d2--