From nobody Thu Feb 1 09:15:07 2018 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 3DBC612AF77 for ; Thu, 1 Feb 2018 09:15:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DS_58xJSkPWt for ; Thu, 1 Feb 2018 09:15:03 -0800 (PST) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 175D2126BF6 for ; Thu, 1 Feb 2018 09:15:03 -0800 (PST) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id w11HF1fV027555 for ; Thu, 1 Feb 2018 12:15:01 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu w11HF1fV027555 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1517505301; bh=YQdD89tF5REKGk8J0fGqdltRSaOqkPjOx6fpGEsoUdA=; h=From:To:Subject:Date:From; b=roiPUMAggXowIgKjbPZ5YZyU8048YZo5p/u/mOEi5ScUY0S8HM+n5Vby58sozz9rj /O8TpTUypFjO5ImwxofFnFAZyB+k/mSDQ/8rhm6dFEtPDT1Hm8ANSwb7OrvXuHeril 18zewJ6pzwHI2OJrtIkA5KUPwqF24Yo89X/JHLrQ= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id w11HEubA001264 for ; Thu, 1 Feb 2018 12:14:56 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0361.001; Thu, 1 Feb 2018 12:14:56 -0500 From: Roman Danyliw To: "dots@ietf.org" Thread-Topic: Agenda for DOTS Virtual Interim Meeting: February 7, 2018 Thread-Index: AdObf8xLj55zZvCqSJ+Y5KiceGrKJg== Date: Thu, 1 Feb 2018 17:14:55 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC013750D474@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Dots] Agenda for DOTS Virtual Interim Meeting: February 7, 2018 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, 01 Feb 2018 17:15:05 -0000 Hello all! A revised agenda for the DOTS virtual interim meeting on February 7, 2018 h= as been posted. https://datatracker.ietf.org/doc/agenda-interim-2018-dots-01-dots-01/02/ =3D=3D[ Date/Time ]=3D=3D Wednesday, February 7, 2018 15:00 - 16:30 UTC Start time in select local time zones =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 San Francisco, USA -- February 7, 2018 at 7:00 am=20 New York, USA -- February 7, 2018 at 10:00 am=20 UTC (GMT) -- February 7, 2018 at 3:00 pm =20 London, UK -- February 7, 2018 at 3:00 pm =20 Berlin, Germany -- February 7, 2018 at 4:00 pm=20 New Delhi, India -- February 7, 2018 at 8:30 pm=20 Bangkok, Thailand -- February 7, 2018 at 10:00 pm=20 Beijing, China -- February 7, 2018 at 11:00 pm =3D=3D[ Agenda ]=3D=3D 1. Introductions and logistics (chairs, 5 min) 2. Requirements Discussion (Andrew Mortensen, 20 min) - Goal: Review and resolve outstanding issues raised in WGLC - draft-ietf-dots-requirements-12 3. IETF 101 Hackathon Coordination (Open Mic, 10 min) - Goal: Identify participants, coordinate activity, Identify any help the WG can provide to participants 4. Protocol Drafts (40 min) - Implementation Reports (Open Mic, 10 min) - Goal: share updates on implementations - draft-ietf-dots-signal-channel-17 (Mohamed Boucadair, 30 min) draft-ietf-dots-data-channel-13 5. Other Informational Drafts (10 min) - Goal: Identify outstanding issues and define a schedule to=20 bring the use case and architecture drafts to WGLC - draft-ietf-dots-architecture-05 (Andrew Mortensen) - draft-ietf-dots-use-cases-09 (Roland Dobbins) 6. Closing (chairs, 5 min) =3D=3D[ WebEx Information ]=3D=3D Meeting URL: https://ietf.webex.com/ietf/j.php?MTID=3Dm7918038a2dcc50d69146acbfa69c31eb Meeting number: 640 129 123=20 Meeting password: AT2ShnfU=20 =20 Dial-in Numbers: 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 640 129 123=20 =3D=3D=3D=3D Regards, Roman and Tobias From nobody Tue Feb 6 13:31:56 2018 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 1C06212D886 for ; Tue, 6 Feb 2018 13:31:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRydxEUzSU60 for ; Tue, 6 Feb 2018 13:31:53 -0800 (PST) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 2B90F12D940 for ; Tue, 6 Feb 2018 13:31:52 -0800 (PST) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id w16LVn1Y022086 for ; Tue, 6 Feb 2018 16:31:50 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu w16LVn1Y022086 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1517952710; bh=r+MAdJVpA34tQWhH6Q1I9TEwU0PrVXYVk0zDevW1F5k=; h=From:To:Subject:Date:From; b=hMDIJXsqX0cAdTP109zaVh9WlS7Q6B3HQ9qkiZrWcs5lvCjLIdM0EscIH+7AB/xSn PPn7CL/P0fyfpWJQcK27dPapJP8KwuTN5YeaCFy2BvpjGXRg8b09RxarsZVFZqf/zo SnAIAo5rVTBpWxNHInQJAhNMZRn8dtCAWtyJwwNE= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id w16LVjsG035001 for ; Tue, 6 Feb 2018 16:31:45 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0361.001; Tue, 6 Feb 2018 16:31:45 -0500 From: Roman Danyliw To: "dots@ietf.org" Thread-Topic: Meeting Materials for 02/07/2018 Virtual Interim Meeting Thread-Index: AdOfkdqIJoiHQvpeTECOn9mFFtQknQ== Date: Tue, 6 Feb 2018 21:31:43 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01375113ED@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Dots] Meeting Materials for 02/07/2018 Virtual Interim Meeting 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: Tue, 06 Feb 2018 21:31:55 -0000 Hello WG! The materials for tomorrow's (February 7, 2018) virtual interim meeting can= be found at: https://datatracker.ietf.org/meeting/interim-2018-dots-01/session/dots =3D=3D[ Agenda ]=3D=3D https://datatracker.ietf.org/doc/agenda-interim-2018-dots-01-dots-01/ =3D=3D[ WebEx Information ]=3D=3D Meeting URL: https://ietf.webex.com/ietf/j.php?MTID=3Dm7918038a2dcc50d69146acbfa69c31eb Meeting number: 640 129 123 Meeting password: AT2ShnfU Dial-in Numbers: 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 640 129 123 =3D=3D=3D=3D Roman From nobody Wed Feb 7 09:05:39 2018 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 79AEB124F57; Wed, 7 Feb 2018 09:05:38 -0800 (PST) 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.72.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151802313846.4823.7164614843343039635@ietfa.amsl.com> Date: Wed, 07 Feb 2018 09:05:38 -0800 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-requirements-13.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: Wed, 07 Feb 2018 17:05:38 -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 (DDoS) Open Threat Signaling Requirements Authors : Andrew Mortensen Robert Moskowitz Tirumaleswar Reddy Filename : draft-ietf-dots-requirements-13.txt Pages : 20 Date : 2018-02-07 Abstract: This document defines the requirements for the Distributed Denial of Service (DDoS) Open Threat Signaling (DOTS) protocols enabling coordinated response to DDoS attacks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-requirements/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-requirements-13 https://datatracker.ietf.org/doc/html/draft-ietf-dots-requirements-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-requirements-13 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 Feb 7 09:08:59 2018 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 B858112702E for ; Wed, 7 Feb 2018 09:08:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 (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 c4V5KXyu0jpQ for ; Wed, 7 Feb 2018 09:08:55 -0800 (PST) Received: from mx0a-00196b01.pphosted.com (mx0a-00196b01.pphosted.com [67.231.149.170]) (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 ECF89126C2F for ; Wed, 7 Feb 2018 09:08:54 -0800 (PST) Received: from pps.filterd (m0096263.ppops.net [127.0.0.1]) by mx0a-00196b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w17H6EwO025719 for ; Wed, 7 Feb 2018 12:08:54 -0500 Received: from nam03-by2-obe.outbound.protection.outlook.com (mail-by2nam03lp0055.outbound.protection.outlook.com [216.32.180.55]) by mx0a-00196b01.pphosted.com with ESMTP id 2fyxyc8h8e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Wed, 07 Feb 2018 12:08:54 -0500 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=QEen+csSOGdzP9XlmBfNSPEdY1KvlBO+kEb/+Ma4jts=; b=BsrgIC9xjigVUfuStGTgUrBO+c7BKsQGFpC3p2VB37ZuG4u00oMdqMtJXX8DyuBW4kbAoH/wRHI8SElCgqQ12S/DN7qmzTg5gsCabxpWOBb1eqdt+QK1jCQjix+3OYRvi8sxF3EaoOpcH6k5qAKBOAAtT7dtE02QJwpxY/VFtxM= Received: from BN3PR01MB1987.prod.exchangelabs.com (10.166.71.144) by BN3PR01MB2001.prod.exchangelabs.com (10.166.71.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.10; Wed, 7 Feb 2018 17:08:52 +0000 Received: from BN3PR01MB1987.prod.exchangelabs.com ([fe80::4cdd:1182:f095:b22b]) by BN3PR01MB1987.prod.exchangelabs.com ([fe80::4cdd:1182:f095:b22b%17]) with mapi id 15.20.0485.009; Wed, 7 Feb 2018 17:08:52 +0000 From: "Mortensen, Andrew" To: dots Thread-Topic: [Dots] I-D Action: draft-ietf-dots-requirements-13.txt Thread-Index: AQHToDXkVtEB1kupKkaKa0Sxjp7x5g== Date: Wed, 7 Feb 2018 17:08:52 +0000 Message-ID: <158A2A94-1165-4938-A675-C776DE7444CF@arbor.net> References: <151802313846.4823.7164614843343039635@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.130.192.4] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR01MB2001; 7:RMNzclHdJBYpYevlhX5to4vo3Yu8TiwMMBUVQ1nOUZWh4ndhIIEAIYltZlcaOjkM7FnKcbJPT70QLV9bml+3gEfggOBUE+3W8EK8By0Xu4woXgj3jAh8eqan3OitGlAby+UDvc9INx7PykcYOhkRz1UHgoFMtADa0EGmGpFiunhJKG1McXRYIqvOCMc8JjfT/JVhTpq/DwCAGnxY2U2kxZSZPejHz6qQ/1+KuZud9W8nGzL+xL1ILHC8k/lxlFqO x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 5811f7c6-a202-4c96-c972-08d56e4d766d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:BN3PR01MB2001; x-ms-traffictypediagnostic: BN3PR01MB2001: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3002001)(3231101)(2400082)(944501161)(10201501046)(93006095)(93001095)(6041288)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:BN3PR01MB2001; BCL:0; PCL:0; RULEID:; SRVR:BN3PR01MB2001; x-forefront-prvs: 0576145E86 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39380400002)(39860400002)(366004)(346002)(376002)(199004)(189003)(377424004)(6436002)(478600001)(97736004)(83716003)(59450400001)(6486002)(5250100002)(6512007)(53936002)(6116002)(3846002)(236005)(86362001)(2473003)(99286004)(54896002)(66066001)(2900100001)(68736007)(36756003)(316002)(8936002)(105586002)(82746002)(5660300001)(81156014)(81166006)(8676002)(7736002)(26005)(25786009)(186003)(6916009)(102836004)(3280700002)(76176011)(3660700001)(33656002)(106356001)(229853002)(14454004)(2906002)(6506007); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR01MB2001; H:BN3PR01MB1987.prod.exchangelabs.com; 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-antispam-message-info: FHpTIUHYl/ApyUqdr7dshI8dx8t0hi+g9TQ8bygnh2GYHEpBAOF2qv8ian4RF5FumhWqrX8DC+psEg1/J9yRlQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_158A2A9411654938A675C776DE7444CFarbornet_" MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-Network-Message-Id: 5811f7c6-a202-4c96-c972-08d56e4d766d X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Feb 2018 17:08:52.0768 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR01MB2001 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-07_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802070215 Archived-At: Subject: [Dots] Fwd: I-D Action: draft-ietf-dots-requirements-13.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: Wed, 07 Feb 2018 17:08:59 -0000 --_000_158A2A9411654938A675C776DE7444CFarbornet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm90IHdhbnRpbmcgdG8gbG9zZSBtb21lbnR1bSBmcm9tIHRvZGF54oCZcyBpbnRlcmltIG1lZXRp bmcsIEnigJl2ZSB1cGRhdGVkIHRoZSByZXF1aXJlbWVudHMgZHJhZnQgdG8gYWRkcmVzcyB0aGUg cmVtYWluaW5nIGlzc3Vlcy4gUGxlYXNlIHRha2UgYSBjbG9zZSBsb29rIGF0IEdFTi0wMDQgYW5k IC0wMDUsIHdoaWNoIGFkZCB0aGUgbWl0aWdhdGlvbiBoaW50aW5nIGFuZCBsb29wIGhhbmRsaW5n IGdlbmVyYWwgcmVxdWlyZW1lbnRzLCByZXNwZWN0aXZlbHkuIEFzIGRpc2N1c3NlZCBkdXJpbmcg dG9kYXnigJlzIG1lZXRpbmcsIHRoZSBiaWRpcmVjdGlvbmFsaXR5IHJlcXVpcmVtZW50IChmb3Jt ZXJseSBHRU4tMDAzKSBoYXMgYmVlbiBtb3ZlZCB1bmRlciB0aGUgc2lnbmFsIGNoYW5uZWwgcmVx dWlyZW1lbnRzIGFzIFNJRy0wMDMuDQoNCmFuZHJldw0KDQoNCkJlZ2luIGZvcndhcmRlZCBtZXNz YWdlOg0KDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRy YWZ0c0BpZXRmLm9yZz4NClN1YmplY3Q6IFtEb3RzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWRv dHMtcmVxdWlyZW1lbnRzLTEzLnR4dA0KRGF0ZTogRmVicnVhcnkgNywgMjAxOCBhdCAxMjowNToz OCBQTSBFU1QNClRvOiA8aS1kLWFubm91bmNlQGlldGYub3JnPG1haWx0bzppLWQtYW5ub3VuY2VA aWV0Zi5vcmc+Pg0KQ2M6IGRvdHNAaWV0Zi5vcmc8bWFpbHRvOmRvdHNAaWV0Zi5vcmc+DQoNCg0K QSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJu ZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUg RERvUyBPcGVuIFRocmVhdCBTaWduYWxpbmcgV0cgb2YgdGhlIElFVEYuDQoNCiAgICAgICBUaXRs ZSAgICAgICAgICAgOiBEaXN0cmlidXRlZCBEZW5pYWwgb2YgU2VydmljZSAoRERvUykgT3BlbiBU aHJlYXQgU2lnbmFsaW5nIFJlcXVpcmVtZW50cw0KICAgICAgIEF1dGhvcnMgICAgICAgICA6IEFu ZHJldyBNb3J0ZW5zZW4NCiAgICAgICAgICAgICAgICAgICAgICAgICBSb2JlcnQgTW9za293aXR6 DQogICAgICAgICAgICAgICAgICAgICAgICAgVGlydW1hbGVzd2FyIFJlZGR5DQpGaWxlbmFtZSAg ICAgICAgOiBkcmFmdC1pZXRmLWRvdHMtcmVxdWlyZW1lbnRzLTEzLnR4dA0KUGFnZXMgICAgICAg ICAgIDogMjANCkRhdGUgICAgICAgICAgICA6IDIwMTgtMDItMDcNCg0KQWJzdHJhY3Q6DQogIFRo aXMgZG9jdW1lbnQgZGVmaW5lcyB0aGUgcmVxdWlyZW1lbnRzIGZvciB0aGUgRGlzdHJpYnV0ZWQg RGVuaWFsIG9mDQogIFNlcnZpY2UgKEREb1MpIE9wZW4gVGhyZWF0IFNpZ25hbGluZyAoRE9UUykg cHJvdG9jb2xzIGVuYWJsaW5nDQogIGNvb3JkaW5hdGVkIHJlc3BvbnNlIHRvIEREb1MgYXR0YWNr cy4NCg0K --_000_158A2A9411654938A675C776DE7444CFarbornet_ Content-Type: text/html; charset="utf-8" Content-ID: <733C5D2BE6392542B5C93ABB2C72EC12@prod.exchangelabs.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KTm90IHdhbnRpbmcgdG8gbG9zZSBt b21lbnR1bSBmcm9tIHRvZGF54oCZcyBpbnRlcmltIG1lZXRpbmcsIEnigJl2ZSB1cGRhdGVkIHRo ZSByZXF1aXJlbWVudHMgZHJhZnQgdG8gYWRkcmVzcyB0aGUgcmVtYWluaW5nIGlzc3Vlcy4gUGxl YXNlIHRha2UgYSBjbG9zZSBsb29rIGF0IEdFTi0wMDQgYW5kIC0wMDUsIHdoaWNoIGFkZCB0aGUg bWl0aWdhdGlvbiBoaW50aW5nIGFuZCBsb29wIGhhbmRsaW5nIGdlbmVyYWwgcmVxdWlyZW1lbnRz LCByZXNwZWN0aXZlbHkuDQogQXMgZGlzY3Vzc2VkIGR1cmluZyB0b2RheeKAmXMgbWVldGluZywg dGhlIGJpZGlyZWN0aW9uYWxpdHkgcmVxdWlyZW1lbnQgKGZvcm1lcmx5IEdFTi0wMDMpIGhhcyBi ZWVuIG1vdmVkIHVuZGVyIHRoZSBzaWduYWwgY2hhbm5lbCByZXF1aXJlbWVudHMgYXMgU0lHLTAw My4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPmFu ZHJldzxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+QmVnaW4gZm9yd2FyZGVkIG1lc3NhZ2U6PC9kaXY+ DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBzdHlsZT0ibWFy Z2luLXRvcDogMHB4OyBtYXJnaW4tcmlnaHQ6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBtYXJn aW4tbGVmdDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJr aXQtc3lzdGVtLWZvbnQsIEhlbHZldGljYSBOZXVlLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGNv bG9yOnJnYmEoMCwgMCwgMCwgMS4wKTsiIGNsYXNzPSIiPjxiIGNsYXNzPSIiPkZyb206DQo8L2I+ PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zeXN0ZW0tZm9udCwgSGVs dmV0aWNhIE5ldWUsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPjxhIGhyZWY9Im1h aWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIGNsYXNzPSIiPmludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW4tdG9wOiAwcHg7IG1hcmdpbi1yaWdodDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7IG1hcmdp bi1sZWZ0OiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtp dC1zeXN0ZW0tZm9udCwgSGVsdmV0aWNhIE5ldWUsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgY29s b3I6cmdiYSgwLCAwLCAwLCAxLjApOyIgY2xhc3M9IiI+PGIgY2xhc3M9IiI+U3ViamVjdDoNCjwv Yj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN5c3RlbS1mb250LCBI ZWx2ZXRpY2EgTmV1ZSwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+PGIgY2xhc3M9 IiI+W0RvdHNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtZG90cy1yZXF1aXJlbWVudHMtMTMudHh0 PC9iPjxiciBjbGFzcz0iIj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6 IDBweDsgbWFyZ2luLXJpZ2h0OiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgbWFyZ2luLWxlZnQ6 IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN5c3Rl bS1mb250LCBIZWx2ZXRpY2EgTmV1ZSwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBjb2xvcjpyZ2Jh KDAsIDAsIDAsIDEuMCk7IiBjbGFzcz0iIj48YiBjbGFzcz0iIj5EYXRlOg0KPC9iPjwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3lzdGVtLWZvbnQsIEhlbHZldGljYSBO ZXVlLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5GZWJydWFyeSA3LCAyMDE4IGF0 IDEyOjA1OjM4IFBNIEVTVDxiciBjbGFzcz0iIj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbi10b3A6IDBweDsgbWFyZ2luLXJpZ2h0OiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsg bWFyZ2luLWxlZnQ6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAt d2Via2l0LXN5c3RlbS1mb250LCBIZWx2ZXRpY2EgTmV1ZSwgSGVsdmV0aWNhLCBzYW5zLXNlcmlm OyBjb2xvcjpyZ2JhKDAsIDAsIDAsIDEuMCk7IiBjbGFzcz0iIj48YiBjbGFzcz0iIj5UbzoNCjwv Yj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN5c3RlbS1mb250LCBI ZWx2ZXRpY2EgTmV1ZSwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+Jmx0OzxhIGhy ZWY9Im1haWx0bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmciIGNsYXNzPSIiPmktZC1hbm5vdW5jZUBp ZXRmLm9yZzwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KPC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tcmlnaHQ6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBt YXJnaW4tbGVmdDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IC13 ZWJraXQtc3lzdGVtLWZvbnQsIEhlbHZldGljYSBOZXVlLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7 IGNvbG9yOnJnYmEoMCwgMCwgMCwgMS4wKTsiIGNsYXNzPSIiPjxiIGNsYXNzPSIiPkNjOg0KPC9i Pjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3lzdGVtLWZvbnQsIEhl bHZldGljYSBOZXVlLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj48YSBocmVmPSJt YWlsdG86ZG90c0BpZXRmLm9yZyIgY2xhc3M9IiI+ZG90c0BpZXRmLm9yZzwvYT48YnIgY2xhc3M9 IiI+DQo8L3NwYW4+PC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUg ZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuPGJyIGNsYXNzPSIi Pg0KVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgRERvUyBPcGVuIFRocmVhdCBTaWdu YWxpbmcgV0cgb2YgdGhlIElFVEYuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7VGl0bGUgJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7OiBEaXN0cmlidXRl ZCBEZW5pYWwgb2YgU2VydmljZSAoRERvUykgT3BlbiBUaHJlYXQgU2lnbmFsaW5nIFJlcXVpcmVt ZW50czxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwO0F1dGhvcnMgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7OiBBbmRyZXcgTW9ydGVuc2VuPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Um9iZXJ0IE1vc2tvd2l0ejxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1RpcnVtYWxlc3dhciBSZWRkeTxiciBjbGFzcz0iIj4N CjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+PC9z cGFuPkZpbGVuYW1lICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzog ZHJhZnQtaWV0Zi1kb3RzLXJlcXVpcmVtZW50cy0xMy50eHQ8YnIgY2xhc3M9IiI+DQo8c3BhbiBj bGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPjwvc3Bhbj5QYWdl cyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDs6IDIwPGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHls ZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+RGF0ZSAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs6IDIwMTgtMDItMDc8YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpBYnN0cmFjdDo8YnIgY2xhc3M9IiI+DQombmJzcDsm bmJzcDtUaGlzIGRvY3VtZW50IGRlZmluZXMgdGhlIHJlcXVpcmVtZW50cyBmb3IgdGhlIERpc3Ry aWJ1dGVkIERlbmlhbCBvZjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO1NlcnZpY2UgKEREb1Mp IE9wZW4gVGhyZWF0IFNpZ25hbGluZyAoRE9UUykgcHJvdG9jb2xzIGVuYWJsaW5nPGJyIGNsYXNz PSIiPg0KJm5ic3A7Jm5ic3A7Y29vcmRpbmF0ZWQgcmVzcG9uc2UgdG8gRERvUyBhdHRhY2tzLjxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_158A2A9411654938A675C776DE7444CFarbornet_-- From nobody Wed Feb 7 19:27:17 2018 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 2255D12D7EC for ; Wed, 7 Feb 2018 19:27:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.009 X-Spam-Level: X-Spam-Status: No, score=-7.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 UNVgpzBu04lJ for ; Wed, 7 Feb 2018 19:27:04 -0800 (PST) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 320BF12D834 for ; Wed, 7 Feb 2018 19:27:04 -0800 (PST) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1518060423; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=c osVjUgCZOq7/98/b+VEZtnWHRv1TtIOEtWGNpLdRf E=; b=cyMP5YYMs7VrPBNeDvug34h+L42dvfumD4RQYKq8eE41 GuPy/Y1FaGHhYg2rYITVdjjJgAwKVPoM6xKHar2alfXheDECOP 7FjfUx735ZMDmHcCyU/qixyXAWNpSMXMSk+wZOzfPwrPomTKqw t2ZGLq+StcAqCFecsFx1wEC8/xE= Received: from MIVEXAPP1N01.corpzone.internalzone.com (unknown [10.48.48.88]) by MIVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 1201_3463_5b80ff9c_fdfe_4440_851d_c13cdba8ee81; Wed, 07 Feb 2018 21:27:02 -0600 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.1347.2; Wed, 7 Feb 2018 22:27:01 -0500 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.1347.2; Wed, 7 Feb 2018 22:27:00 -0500 Received: from MIVO365EDGE4.corpzone.internalzone.com (10.48.176.87) by MIVEXUSR1N01.corpzone.internalzone.com (10.48.48.81) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Wed, 7 Feb 2018 22:26:59 -0500 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (10.48.176.242) by edge.mcafee.com (10.48.176.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 7 Feb 2018 22:26:59 -0500 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1484.namprd16.prod.outlook.com (10.173.211.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.10; Thu, 8 Feb 2018 03:26:57 +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.20.0464.016; Thu, 8 Feb 2018 03:26:57 +0000 From: "Konda, Tirumaleswar Reddy" To: "Mortensen, Andrew" , dots Thread-Topic: [Dots] Fwd: I-D Action: draft-ietf-dots-requirements-13.txt Thread-Index: AQHToDZrDNoOMgpTNU61SD8wwp8DzKOZ2JtQ Date: Thu, 8 Feb 2018 03:26:57 +0000 Message-ID: References: <151802313846.4823.7164614843343039635@ietfa.amsl.com> <158A2A94-1165-4938-A675-C776DE7444CF@arbor.net> In-Reply-To: <158A2A94-1165-4938-A675-C776DE7444CF@arbor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [185.221.69.14] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1484; 7:BdysCWduTjDAgIvicS96fKzA4r0E58RfGwMFwMIYi9pQyB1Vr6cWWZwEhsDR6/QAuq2inprtNLS555uVNZ9syd3/lzdoKL3UEi50C35cTfM7EMaAcm4PWuHFRkN+1doB0lx8pPcjtcPgt7z7cP22x9RV7BPFcL/9DqsSUpnPexNCddqFe71KHZ6wbr2SsJ3tK684OumCxVTJRf/UK+nOKBgWABoeOTQe8PE23cCIYL1U26ernam5qAaPYuIqgDhO x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: ff464f28-d875-45a5-4fe7-08d56ea3cf10 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM5PR16MB1484; x-ms-traffictypediagnostic: DM5PR16MB1484: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231101)(2400082)(944501161)(6041288)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123560045)(6072148)(201708071742011); SRVR:DM5PR16MB1484; BCL:0; PCL:0; RULEID:; SRVR:DM5PR16MB1484; x-forefront-prvs: 0577AD41D6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(396003)(376002)(39860400002)(39380400002)(377424004)(32952001)(199004)(189003)(7696005)(6246003)(55016002)(53546011)(14454004)(97736004)(26005)(77096007)(59450400001)(6506007)(5660300001)(102836004)(6306002)(110136005)(54896002)(2950100002)(86362001)(9686003)(316002)(99286004)(236005)(81166006)(81156014)(53936002)(8936002)(229853002)(478600001)(72206003)(106356001)(74316002)(66066001)(186003)(2906002)(8676002)(76176011)(7736002)(2900100001)(3660700001)(6436002)(80792005)(3280700002)(105586002)(19609705001)(33656002)(3846002)(68736007)(25786009)(790700001)(6116002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1484; 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) x-microsoft-antispam-message-info: 8V7DSOMDFQttTQX13+PnjMPsOzZ7qWNIx4P7gVvQ5xGFkaHT27Ubj/6PyyrnkCxY+UdZK3uXYUXsI/rxj5m8WA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1788C637EF12AAEFD29BB95BEAF30DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ff464f28-d875-45a5-4fe7-08d56ea3cf10 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Feb 2018 03:26:57.1720 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1484 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 <6217> : inlines <6380> : streams <1778345> : uri <2588864> Archived-At: Subject: Re: [Dots] Fwd: I-D Action: draft-ietf-dots-requirements-13.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, 08 Feb 2018 03:27:06 -0000 --_000_DM5PR16MB1788C637EF12AAEFD29BB95BEAF30DM5PR16MB1788namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MSkNCiAgR0VOLTAwNSAgTG9vcCBIYW5kbGluZzogSW4gc3BlY2lmaWMgc2NlbmFyaW9zLCBpdCBt YXkgYmUgcG9zc2libGUgZm9yDQogICAgICBjb21tdW5pY2F0aW9uIGJldHdlZW4gRE9UUyBhZ2Vu dHMgdG8gbG9vcCwgZm9yIGV4YW1wbGUgYXMgYSByZXN1bHQNCiAgICAgIG9mIG1pc2NvbmZpZ3Vy YXRpb24gb3IgYWdncmVzc2l2ZSBjYWNoaW5nLg0KDQpjb21tZW50PiBUaGUgbG9vcGluZyBhdHRh Y2sgSm9uIGRpc2N1c3NlZCBpbiB0aGUgbWFpbGluZyBsaXN0IGlzIGJlY2F1c2Ugb2YgbWlzY29u ZmlndXJhdGlvbg0KYW5kIEROUyBjYWNoZSBwb2lzb25pbmcuIFdoYXQgZG8geW91IG1lYW4gYnkg ImFnZ3Jlc3NpdmUgY2FjaGluZyIgPw0KDQoyKSAgTWl0aWdhdGlvbiBoaW50cyBNQVkgYmUgdHJh bnNtaXR0ZWQgYWNyb3NzIGVpdGhlciBzaWduYWwgb3IgZGF0YSBjaGFubmVsLg0KDQpjb21tZW50 PiBJIGRvbid0IHRoaW5rIHRoZSBET1RTIGNsaWVudCB3aWxsIGtub3cgdGhlIG1pdGlnYXRpb24g aGludHMgZHVyaW5nIHBlYWNlIHRpbWUgdG8gY29udmV5IHRoZSBoaW50cyBpbiB0aGUgZGF0YSBj aGFubmVsICENCg0KLVRpcnUNCg0KRnJvbTogRG90cyBbbWFpbHRvOmRvdHMtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIE1vcnRlbnNlbiwgQW5kcmV3DQpTZW50OiBXZWRuZXNkYXksIEZl YnJ1YXJ5IDcsIDIwMTggMTA6MzkgUE0NClRvOiBkb3RzIDxkb3RzQGlldGYub3JnPg0KU3ViamVj dDogW0RvdHNdIEZ3ZDogSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1kb3RzLXJlcXVpcmVtZW50cy0x My50eHQNCg0KTm90IHdhbnRpbmcgdG8gbG9zZSBtb21lbnR1bSBmcm9tIHRvZGF54oCZcyBpbnRl cmltIG1lZXRpbmcsIEnigJl2ZSB1cGRhdGVkIHRoZSByZXF1aXJlbWVudHMgZHJhZnQgdG8gYWRk cmVzcyB0aGUgcmVtYWluaW5nIGlzc3Vlcy4gUGxlYXNlIHRha2UgYSBjbG9zZSBsb29rIGF0IEdF Ti0wMDQgYW5kIC0wMDUsIHdoaWNoIGFkZCB0aGUgbWl0aWdhdGlvbiBoaW50aW5nIGFuZCBsb29w IGhhbmRsaW5nIGdlbmVyYWwgcmVxdWlyZW1lbnRzLCByZXNwZWN0aXZlbHkuIEFzIGRpc2N1c3Nl ZCBkdXJpbmcgdG9kYXnigJlzIG1lZXRpbmcsIHRoZSBiaWRpcmVjdGlvbmFsaXR5IHJlcXVpcmVt ZW50IChmb3JtZXJseSBHRU4tMDAzKSBoYXMgYmVlbiBtb3ZlZCB1bmRlciB0aGUgc2lnbmFsIGNo YW5uZWwgcmVxdWlyZW1lbnRzIGFzIFNJRy0wMDMuDQoNCmFuZHJldw0KDQoNCkJlZ2luIGZvcndh cmRlZCBtZXNzYWdlOg0KDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NClN1YmplY3Q6IFtEb3RzXSBJLUQgQWN0aW9uOiBkcmFm dC1pZXRmLWRvdHMtcmVxdWlyZW1lbnRzLTEzLnR4dA0KRGF0ZTogRmVicnVhcnkgNywgMjAxOCBh dCAxMjowNTozOCBQTSBFU1QNClRvOiA8aS1kLWFubm91bmNlQGlldGYub3JnPG1haWx0bzppLWQt YW5ub3VuY2VAaWV0Zi5vcmc+Pg0KQ2M6IGRvdHNAaWV0Zi5vcmc8bWFpbHRvOmRvdHNAaWV0Zi5v cmc+DQoNCg0KQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxp bmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRl bSBvZiB0aGUgRERvUyBPcGVuIFRocmVhdCBTaWduYWxpbmcgV0cgb2YgdGhlIElFVEYuDQoNCiAg ICAgICBUaXRsZSAgICAgICAgICAgOiBEaXN0cmlidXRlZCBEZW5pYWwgb2YgU2VydmljZSAoRERv UykgT3BlbiBUaHJlYXQgU2lnbmFsaW5nIFJlcXVpcmVtZW50cw0KICAgICAgIEF1dGhvcnMgICAg ICAgICA6IEFuZHJldyBNb3J0ZW5zZW4NCiAgICAgICAgICAgICAgICAgICAgICAgICBSb2JlcnQg TW9za293aXR6DQogICAgICAgICAgICAgICAgICAgICAgICAgVGlydW1hbGVzd2FyIFJlZGR5DQpG aWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLWRvdHMtcmVxdWlyZW1lbnRzLTEzLnR4dA0KUGFn ZXMgICAgICAgICAgIDogMjANCkRhdGUgICAgICAgICAgICA6IDIwMTgtMDItMDcNCg0KQWJzdHJh Y3Q6DQogIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyB0aGUgcmVxdWlyZW1lbnRzIGZvciB0aGUgRGlz dHJpYnV0ZWQgRGVuaWFsIG9mDQogIFNlcnZpY2UgKEREb1MpIE9wZW4gVGhyZWF0IFNpZ25hbGlu ZyAoRE9UUykgcHJvdG9jb2xzIGVuYWJsaW5nDQogIGNvb3JkaW5hdGVkIHJlc3BvbnNlIHRvIERE b1MgYXR0YWNrcy4NCg== --_000_DM5PR16MB1788C637EF12AAEFD29BB95BEAF30DM5PR16MB1788namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIg MSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0K CXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6IlxARGVuZ1hpYW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQ YXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsN CgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGlu Ow0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KcC5tc29u b3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTpt c29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsN Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1z aXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFu LmFwcGxlLXRhYi1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXRhYi1zcGFuO30NCnNwYW4u RW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MjAy MzgxODU0NzsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6 MTQ4MDEyNjA5OCA2NzY5ODcwNSA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2 NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7 bXNvLWxldmVsLXRleHQ6IiUxXCkiOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3Qg bDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGww OmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1s b3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBs MDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0 ZXh0LWluZGVudDotOS4wcHQ7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFy Z2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+MSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7R0VO LTAwNSZuYnNwOyBMb29wIEhhbmRsaW5nOiBJbiBzcGVjaWZpYyBzY2VuYXJpb3MsIGl0IG1heSBi ZSBwb3NzaWJsZSBmb3I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjb21tdW5p Y2F0aW9uIGJldHdlZW4gRE9UUyBhZ2VudHMgdG8gbG9vcCwgZm9yIGV4YW1wbGUgYXMgYSByZXN1 bHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBvZiBtaXNjb25maWd1cmF0aW9u IG9yIGFnZ3Jlc3NpdmUgY2FjaGluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Y29tbWVudCZndDsgVGhlIGxv b3BpbmcgYXR0YWNrIEpvbiBkaXNjdXNzZWQgaW4gdGhlIG1haWxpbmcgbGlzdCBpcyBiZWNhdXNl IG9mIG1pc2NvbmZpZ3VyYXRpb24NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+YW5kIEROUyBjYWNoZSBwb2lzb25pbmcuIFdoYXQg ZG8geW91IG1lYW4gYnkgJnF1b3Q7YWdncmVzc2l2ZSBjYWNoaW5nJnF1b3Q7ID88bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+MikmbmJzcDsgTWl0aWdhdGlvbiBoaW50cyBNQVkgYmUgdHJhbnNtaXR0ZWQgYWNyb3Nz IGVpdGhlciBzaWduYWwgb3IgZGF0YSBjaGFubmVsLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPmNvbW1lbnQm Z3Q7IEkgZG9uJ3QgdGhpbmsgdGhlIERPVFMgY2xpZW50IHdpbGwga25vdyB0aGUgbWl0aWdhdGlv biBoaW50cyBkdXJpbmcgcGVhY2UgdGltZSB0byBjb252ZXkgdGhlIGhpbnRzIGluIHRoZSBkYXRh IGNoYW5uZWwgITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4tVGlydTxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+ PG86cD48L286cD48L2E+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr Ol9NYWlsRW5kQ29tcG9zZSI+PC9zcGFuPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBEb3RzIFttYWls dG86ZG90cy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Nb3J0ZW5zZW4s IEFuZHJldzxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDcsIDIwMTggMTA6 MzkgUE08YnI+DQo8Yj5Ubzo8L2I+IGRvdHMgJmx0O2RvdHNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFtEb3RzXSBGd2Q6IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtZG90cy1yZXF1 aXJlbWVudHMtMTMudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Tm90IHdhbnRpbmcgdG8gbG9zZSBtb21lbnR1bSBmcm9tIHRvZGF54oCZcyBpbnRlcmlt IG1lZXRpbmcsIEnigJl2ZSB1cGRhdGVkIHRoZSByZXF1aXJlbWVudHMgZHJhZnQgdG8gYWRkcmVz cyB0aGUgcmVtYWluaW5nIGlzc3Vlcy4gUGxlYXNlIHRha2UgYSBjbG9zZSBsb29rIGF0IEdFTi0w MDQgYW5kIC0wMDUsIHdoaWNoIGFkZCB0aGUgbWl0aWdhdGlvbiBoaW50aW5nIGFuZCBsb29wIGhh bmRsaW5nIGdlbmVyYWwgcmVxdWlyZW1lbnRzLA0KIHJlc3BlY3RpdmVseS4gQXMgZGlzY3Vzc2Vk IGR1cmluZyB0b2RheeKAmXMgbWVldGluZywgdGhlIGJpZGlyZWN0aW9uYWxpdHkgcmVxdWlyZW1l bnQgKGZvcm1lcmx5IEdFTi0wMDMpIGhhcyBiZWVuIG1vdmVkIHVuZGVyIHRoZSBzaWduYWwgY2hh bm5lbCByZXF1aXJlbWVudHMgYXMgU0lHLTAwMy4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+YW5kcmV3PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5CZWdpbiBmb3J3YXJkZWQgbWVzc2FnZTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOiA8L3NwYW4+DQo8L2I+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YSBo cmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIj5pbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmc8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj5TdWJqZWN0OiBbRG90c10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1k b3RzLXJlcXVpcmVtZW50cy0xMy50eHQ8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5EYXRlOiA8L3NwYW4+DQo8L2I+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5G ZWJydWFyeSA3LCAyMDE4IGF0IDEyOjA1OjM4IFBNIEVTVDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VG86IDwvc3Bhbj4NCjwv Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWYiPiZsdDs8YSBocmVmPSJtYWlsdG86aS1kLWFubm91bmNlQGlldGYub3JnIj5pLWQtYW5ub3Vu Y2VAaWV0Zi5vcmc8L2E+Jmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Q2M6IDwvc3Bhbj4NCjwvYj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxhIGhyZWY9Im1h aWx0bzpkb3RzQGlldGYub3JnIj5kb3RzQGlldGYub3JnPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+PGJyPg0KQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9u LWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLjxicj4NClRoaXMgZHJhZnQgaXMgYSB3 b3JrIGl0ZW0gb2YgdGhlIEREb1MgT3BlbiBUaHJlYXQgU2lnbmFsaW5nIFdHIG9mIHRoZSBJRVRG Ljxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1Rp dGxlICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOzogRGlzdHJpYnV0ZWQgRGVuaWFsIG9mIFNlcnZpY2UgKEREb1MpIE9wZW4gVGhyZWF0 IFNpZ25hbGluZyBSZXF1aXJlbWVudHM8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDtBdXRob3JzICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOzogQW5kcmV3IE1vcnRlbnNlbjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwO1JvYmVydCBNb3Nrb3dpdHo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDtUaXJ1bWFsZXN3YXIgUmVkZHk8YnI+DQpGaWxlbmFtZSAmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs6IGRyYWZ0LWlldGYtZG90cy1yZXF1 aXJlbWVudHMtMTMudHh0PGJyPg0KUGFnZXMgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7OiAyMDxicj4NCkRhdGUgJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7OiAy MDE4LTAyLTA3PGJyPg0KPGJyPg0KQWJzdHJhY3Q6PGJyPg0KJm5ic3A7Jm5ic3A7VGhpcyBkb2N1 bWVudCBkZWZpbmVzIHRoZSByZXF1aXJlbWVudHMgZm9yIHRoZSBEaXN0cmlidXRlZCBEZW5pYWwg b2Y8YnI+DQombmJzcDsmbmJzcDtTZXJ2aWNlIChERG9TKSBPcGVuIFRocmVhdCBTaWduYWxpbmcg KERPVFMpIHByb3RvY29scyBlbmFibGluZzxicj4NCiZuYnNwOyZuYnNwO2Nvb3JkaW5hdGVkIHJl c3BvbnNlIHRvIEREb1MgYXR0YWNrcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_DM5PR16MB1788C637EF12AAEFD29BB95BEAF30DM5PR16MB1788namp_-- From nobody Wed Feb 7 21:04:17 2018 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 B3BD6124D37 for ; Wed, 7 Feb 2018 21:04:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 z6LLtO3zqef8 for ; Wed, 7 Feb 2018 21:04:13 -0800 (PST) Received: from mx0a-00196b01.pphosted.com (mx0b-00196b01.pphosted.com [67.231.157.166]) (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 07DB11241F3 for ; Wed, 7 Feb 2018 21:04:12 -0800 (PST) Received: from pps.filterd (m0096262.ppops.net [127.0.0.1]) by mx0b-00196b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1852JlY003474; Thu, 8 Feb 2018 00:04:10 -0500 Received: from nam01-bn3-obe.outbound.protection.outlook.com (mail-bn3nam01lp0178.outbound.protection.outlook.com [216.32.180.178]) by mx0b-00196b01.pphosted.com with ESMTP id 2g002d94c5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 08 Feb 2018 00:04:10 -0500 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=31dbMyTFDCu8lHUL6LWiZzUtaRDqD5quE+dymniBYKM=; b=TZ1MuevjcTXTkm6igCEvCBUGjDPIVpyjW0VyAhLfSd61ZpBPHaPwXvs8yLewzdVYfRxNxK2l1qo6UminhFROGxGIZP5CJYeVczEDogSJGsErpRt/93PWbRkhMEj1Uampb63dmX7I8VkeZRs2LayVK5U2KUyfmwn1BbwP8KWgrII= Received: from BN3PR01MB1987.prod.exchangelabs.com (10.166.71.144) by BN3PR01MB2164.prod.exchangelabs.com (10.166.73.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.10; Thu, 8 Feb 2018 05:04:08 +0000 Received: from BN3PR01MB1987.prod.exchangelabs.com ([fe80::4cdd:1182:f095:b22b]) by BN3PR01MB1987.prod.exchangelabs.com ([fe80::4cdd:1182:f095:b22b%17]) with mapi id 15.20.0485.009; Thu, 8 Feb 2018 05:04:08 +0000 From: "Mortensen, Andrew" To: "Konda, Tirumaleswar Reddy" CC: dots Thread-Topic: [Dots] Fwd: I-D Action: draft-ietf-dots-requirements-13.txt Thread-Index: AQHToIy2XjNqpWKg/0WLVCmtqgMwv6OZ82WA Date: Thu, 8 Feb 2018 05:04:08 +0000 Message-ID: <2C2EA5A2-0A09-4ED0-BD2A-4A0F786ADEE9@arbor.net> References: <151802313846.4823.7164614843343039635@ietfa.amsl.com> <158A2A94-1165-4938-A675-C776DE7444CF@arbor.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [68.49.167.203] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR01MB2164; 7:38Ao7/W0/zzKG0VlCpFtrT4Qtx0Y9AD3R8aArOEQzeL3ZNSr0G5aO+KiuFeC8Im1TRQZ1NuQ9Xwoj4cS9HdR1riuavBwFsyWMHj612Utzfh11nxw+GsNjIxIkSIJyJZsY09j79ukWmtiOABCle+MmzXk3752r2orerKuERNTILC6JdqfVwRoBnmhvl7AVWxY063qUQISEki1kdmoLbqlOm/rzsww42dNIPtkxx/B+oXtZeofBnO3IRxJPHNY2C8l x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 73b27ad6-c31a-46d7-3465-08d56eb162b0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:BN3PR01MB2164; x-ms-traffictypediagnostic: BN3PR01MB2164: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231101)(2400082)(944501161)(10201501046)(6041288)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:BN3PR01MB2164; BCL:0; PCL:0; RULEID:; SRVR:BN3PR01MB2164; x-forefront-prvs: 0577AD41D6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(39380400002)(39860400002)(396003)(366004)(189003)(199004)(377424004)(6486002)(5660300001)(6916009)(7736002)(86362001)(229853002)(8676002)(81166006)(81156014)(8936002)(76176011)(2900100001)(14454004)(59450400001)(478600001)(316002)(68736007)(6436002)(66066001)(102836004)(236005)(6506007)(53936002)(53546011)(6512007)(54896002)(26005)(97736004)(36756003)(33656002)(105586002)(99286004)(3280700002)(3660700001)(186003)(3846002)(6116002)(5250100002)(2906002)(2950100002)(83716003)(25786009)(6246003)(106356001)(82746002)(4326008); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR01MB2164; H:BN3PR01MB1987.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) x-microsoft-antispam-message-info: VTzSDaolW3bkKM/0PbGeEH9rlDNlGILDFN4jYsHuWb41ZA3LlRR/3LEUickDz6NGAwFpBO8ZU6MTbTjNyzlyVQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_2C2EA5A20A094ED0BD2A4A0F786ADEE9arbornet_" MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-Network-Message-Id: 73b27ad6-c31a-46d7-3465-08d56eb162b0 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Feb 2018 05:04:08.5055 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR01MB2164 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-08_02:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802080046 Archived-At: Subject: Re: [Dots] Fwd: I-D Action: draft-ietf-dots-requirements-13.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, 08 Feb 2018 05:04:16 -0000 --_000_2C2EA5A20A094ED0BD2A4A0F786ADEE9arbornet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBGZWIgNywgMjAxOCwgYXQgMTA6MjYgUE0sIEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkg PFRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb208bWFpbHRvOlRpcnVtYWxlc3dhclJl ZGR5X0tvbmRhQE1jQWZlZS5jb20+PiB3cm90ZToNCg0KMSkNCiAgR0VOLTAwNSAgTG9vcCBIYW5k bGluZzogSW4gc3BlY2lmaWMgc2NlbmFyaW9zLCBpdCBtYXkgYmUgcG9zc2libGUgZm9yDQogICAg ICBjb21tdW5pY2F0aW9uIGJldHdlZW4gRE9UUyBhZ2VudHMgdG8gbG9vcCwgZm9yIGV4YW1wbGUg YXMgYSByZXN1bHQNCiAgICAgIG9mIG1pc2NvbmZpZ3VyYXRpb24gb3IgYWdncmVzc2l2ZSBjYWNo aW5nLg0KDQpjb21tZW50PiBUaGUgbG9vcGluZyBhdHRhY2sgSm9uIGRpc2N1c3NlZCBpbiB0aGUg bWFpbGluZyBsaXN0IGlzIGJlY2F1c2Ugb2YgbWlzY29uZmlndXJhdGlvbg0KYW5kIEROUyBjYWNo ZSBwb2lzb25pbmcuIFdoYXQgZG8geW91IG1lYW4gYnkgImFnZ3Jlc3NpdmUgY2FjaGluZ+KAnSA/ DQoNClNvcnJ5LCBJIGhhZCBtZWFudCB0byBwcm92aWRlIGEgc3BlY2lmaWMgZXhhbXBsZSBvZiBt aXNjb25maWd1cmF0aW9uLCBhbmQgZGlkbuKAmXQgZmluaXNoIHRoZSB0aG91Z2h0LiBJ4oCZbSBz a2VwdGljYWwgb2YgdGhlIEROUyBjYWNoZSBwb2lzb25pbmcgZXhhbXBsZSBmb3IgdGhlIHNhbWUg cmVhc29uIHlvdSBjaXRlZCBvbiB0aGUgbGlzdC4NCg0KIDIpICBNaXRpZ2F0aW9uIGhpbnRzIE1B WSBiZSB0cmFuc21pdHRlZCBhY3Jvc3MgZWl0aGVyIHNpZ25hbCBvciBkYXRhIGNoYW5uZWwuDQoN CmNvbW1lbnQ+IEkgZG9uJ3QgdGhpbmsgdGhlIERPVFMgY2xpZW50IHdpbGwga25vdyB0aGUgbWl0 aWdhdGlvbiBoaW50cyBkdXJpbmcgcGVhY2UgdGltZSB0byBjb252ZXkgdGhlIGhpbnRzIGluIHRo ZSBkYXRhIGNoYW5uZWwgIQ0KDQpJIGhhZCBpbiBtaW5kIGFsd2F5cy1vbiBtaXRpZ2F0aW9uLiBJ IHdhbnRlZCB0byBsZWF2ZSBvcGVuIHRoZSBwb3NzaWJpbGl0eSB0aGF0IHRoZSBET1RTIGNsaWVu dCBvcGVyYXRvcnMgbWlnaHQgcHJvdmlkZSBoaW50cyB0byBpbmZvcm0gdGhlIHNoYXBlIG9mIHRo YXQgYWx3YXlzLW9uIG1pdGlnYXRpb24uIFNpbmNlIHRoZSBjb252ZXJzYXRpb24gbGVhZGluZyB0 byB0aGlzIHJlcXVpcmVtZW50IGFkZGl0aW9uIGNvbmNsdWRlZCB3aXRoIHdoYXQgc2VlbWVkIHRv IGJlIGFuIGFncmVlbWVudCB0aGF0IHdlIHdhbnRlZCB0byBjcmVhdGUgc3BhY2UgZm9yIHVuZGVm aW5lZCBmb3JtcyBvZiBoaW50aW5nLCBpdCBzZWVtZWQgcmVhc29uYWJsZSB0byBhc3N1bWUgYSBE T1RTIG9wZXJhdG9yIGNvdWxkIGhhdmUgc29tZSBmb3JtIG9mIHRocmVhdCBpbnRlbGxpZ2VuY2Ug d2hpY2ggY291bGQgYmUgcHJvdmlkZWQgaW4gc3VjaCBhIHNjZW5hcmlvLg0KDQphbmRyZXcNCg0K DQoNCkZyb206IERvdHMgW21haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBNb3J0ZW5zZW4sIEFuZHJldw0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSA3LCAyMDE4IDEw OjM5IFBNDQpUbzogZG90cyA8ZG90c0BpZXRmLm9yZzxtYWlsdG86ZG90c0BpZXRmLm9yZz4+DQpT dWJqZWN0OiBbRG90c10gRndkOiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWRvdHMtcmVxdWlyZW1l bnRzLTEzLnR4dA0KDQpOb3Qgd2FudGluZyB0byBsb3NlIG1vbWVudHVtIGZyb20gdG9kYXnigJlz IGludGVyaW0gbWVldGluZywgSeKAmXZlIHVwZGF0ZWQgdGhlIHJlcXVpcmVtZW50cyBkcmFmdCB0 byBhZGRyZXNzIHRoZSByZW1haW5pbmcgaXNzdWVzLiBQbGVhc2UgdGFrZSBhIGNsb3NlIGxvb2sg YXQgR0VOLTAwNCBhbmQgLTAwNSwgd2hpY2ggYWRkIHRoZSBtaXRpZ2F0aW9uIGhpbnRpbmcgYW5k IGxvb3AgaGFuZGxpbmcgZ2VuZXJhbCByZXF1aXJlbWVudHMsIHJlc3BlY3RpdmVseS4gQXMgZGlz Y3Vzc2VkIGR1cmluZyB0b2RheeKAmXMgbWVldGluZywgdGhlIGJpZGlyZWN0aW9uYWxpdHkgcmVx dWlyZW1lbnQgKGZvcm1lcmx5IEdFTi0wMDMpIGhhcyBiZWVuIG1vdmVkIHVuZGVyIHRoZSBzaWdu YWwgY2hhbm5lbCByZXF1aXJlbWVudHMgYXMgU0lHLTAwMy4NCg0KYW5kcmV3DQoNCg0KQmVnaW4g Zm9yd2FyZGVkIG1lc3NhZ2U6DQoNCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWls dG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0KU3ViamVjdDogW0RvdHNdIEktRCBBY3Rpb246 IGRyYWZ0LWlldGYtZG90cy1yZXF1aXJlbWVudHMtMTMudHh0DQpEYXRlOiBGZWJydWFyeSA3LCAy MDE4IGF0IDEyOjA1OjM4IFBNIEVTVA0KVG86IDxpLWQtYW5ub3VuY2VAaWV0Zi5vcmc8bWFpbHRv OmktZC1hbm5vdW5jZUBpZXRmLm9yZz4+DQpDYzogZG90c0BpZXRmLm9yZzxtYWlsdG86ZG90c0Bp ZXRmLm9yZz4NCg0KDQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUg b24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQpUaGlzIGRyYWZ0IGlzIGEgd29y ayBpdGVtIG9mIHRoZSBERG9TIE9wZW4gVGhyZWF0IFNpZ25hbGluZyBXRyBvZiB0aGUgSUVURi4N Cg0KICAgICAgIFRpdGxlICAgICAgICAgICA6IERpc3RyaWJ1dGVkIERlbmlhbCBvZiBTZXJ2aWNl IChERG9TKSBPcGVuIFRocmVhdCBTaWduYWxpbmcgUmVxdWlyZW1lbnRzDQogICAgICAgQXV0aG9y cyAgICAgICAgIDogQW5kcmV3IE1vcnRlbnNlbg0KICAgICAgICAgICAgICAgICAgICAgICAgIFJv YmVydCBNb3Nrb3dpdHoNCiAgICAgICAgICAgICAgICAgICAgICAgICBUaXJ1bWFsZXN3YXIgUmVk ZHkNCkZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtZG90cy1yZXF1aXJlbWVudHMtMTMudHh0 DQpQYWdlcyAgICAgICAgICAgOiAyMA0KRGF0ZSAgICAgICAgICAgIDogMjAxOC0wMi0wNw0KDQpB YnN0cmFjdDoNCiAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIHRoZSByZXF1aXJlbWVudHMgZm9yIHRo ZSBEaXN0cmlidXRlZCBEZW5pYWwgb2YNCiAgU2VydmljZSAoRERvUykgT3BlbiBUaHJlYXQgU2ln bmFsaW5nIChET1RTKSBwcm90b2NvbHMgZW5hYmxpbmcNCiAgY29vcmRpbmF0ZWQgcmVzcG9uc2Ug dG8gRERvUyBhdHRhY2tzLg0KDQo= --_000_2C2EA5A20A094ED0BD2A4A0F786ADEE9arbornet_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBGZWIg NywgMjAxOCwgYXQgMTA6MjYgUE0sIEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgJmx0OzxhIGhy ZWY9Im1haWx0bzpUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tIiBjbGFzcz0iIj5U aXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8 YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSIgc3R5bGU9InBhZ2U6IFdvcmRTZWN0aW9uMTsgZm9udC1m YW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZv bnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFj aW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRy YW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4g MGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJv bWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+MSk8bzpwIGNsYXNzPSIi PjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFw dDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlm OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFu PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6 IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7R0VOLTAwNSZuYnNwOyBMb29wIEhhbmRsaW5n OiBJbiBzcGVjaWZpYyBzY2VuYXJpb3MsIGl0IG1heSBiZSBwb3NzaWJsZSBmb3I8bzpwIGNsYXNz PSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAw MDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNl cmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBjb21tdW5pY2F0aW9uIGJldHdlZW4gRE9UUyBhZ2VudHMgdG8gbG9vcCwgZm9yIGV4 YW1wbGUgYXMgYSByZXN1bHQ8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZh bWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNz PSIiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBvZiBtaXNjb25maWd1cmF0aW9uIG9y IGFnZ3Jlc3NpdmUgY2FjaGluZy48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250 LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNs YXNzPSIiPjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5 OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+ Y29tbWVudCZndDsgVGhlIGxvb3BpbmcgYXR0YWNrIEpvbiBkaXNjdXNzZWQgaW4gdGhlIG1haWxp bmcgbGlzdCBpcyBiZWNhdXNlIG9mIG1pc2NvbmZpZ3VyYXRpb248bzpwIGNsYXNzPSIiPjwvbzpw Pjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9u dC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xh c3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPmFuZCBETlMgY2FjaGUgcG9pc29uaW5nLiBXaGF0IGRv IHlvdSBtZWFuIGJ5ICZxdW90O2FnZ3Jlc3NpdmUgY2FjaGluZ+KAnSA/PC9zcGFuPjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2PlNvcnJ5LCBJIGhhZCBtZWFudCB0byBwcm92aWRlIGEgc3BlY2lmaWMgZXhhbXBsZSBv ZiBtaXNjb25maWd1cmF0aW9uLCBhbmQgZGlkbuKAmXQgZmluaXNoIHRoZSB0aG91Z2h0LiBJ4oCZ bSBza2VwdGljYWwgb2YgdGhlIEROUyBjYWNoZSBwb2lzb25pbmcgZXhhbXBsZSBmb3IgdGhlIHNh bWUgcmVhc29uIHlvdSBjaXRlZCBvbiB0aGUgbGlzdC48L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x IiBzdHlsZT0icGFnZTogV29yZFNlY3Rpb24xOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250 LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1h bDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGln bjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z cGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0 aDogMHB4OyI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250 LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNs YXNzPSIiPjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMXB0OyIgY2xhc3M9IiI+ MikmbmJzcDsgTWl0aWdhdGlvbiBoaW50cyBNQVkgYmUgdHJhbnNtaXR0ZWQgYWNyb3NzIGVpdGhl ciBzaWduYWwgb3IgZGF0YSBjaGFubmVsLjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdp bjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVz IE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAx MXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPjxvOnAgY2xh c3M9IiI+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4g MGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJv bWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+Y29tbWVudCZndDsgSSBk b24ndCB0aGluayB0aGUgRE9UUyBjbGllbnQgd2lsbCBrbm93IHRoZSBtaXRpZ2F0aW9uIGhpbnRz IGR1cmluZyBwZWFjZSB0aW1lIHRvIGNvbnZleSB0aGUgaGludHMgaW4gdGhlIGRhdGEgY2hhbm5l bCAhPC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdj5JIGhhZCBpbiBtaW5kIGFsd2F5cy1vbiBtaXRpZ2F0aW9uLiBJIHdh bnRlZCB0byBsZWF2ZSBvcGVuIHRoZSBwb3NzaWJpbGl0eSB0aGF0IHRoZSBET1RTIGNsaWVudCBv cGVyYXRvcnMgbWlnaHQgcHJvdmlkZSBoaW50cyB0byBpbmZvcm0gdGhlIHNoYXBlIG9mIHRoYXQg YWx3YXlzLW9uIG1pdGlnYXRpb24uIFNpbmNlIHRoZSBjb252ZXJzYXRpb24gbGVhZGluZyB0byB0 aGlzIHJlcXVpcmVtZW50IGFkZGl0aW9uIGNvbmNsdWRlZCB3aXRoIHdoYXQNCiBzZWVtZWQgdG8g YmUgYW4gYWdyZWVtZW50IHRoYXQgd2Ugd2FudGVkIHRvIGNyZWF0ZSBzcGFjZSBmb3IgdW5kZWZp bmVkIGZvcm1zIG9mIGhpbnRpbmcsIGl0IHNlZW1lZCByZWFzb25hYmxlIHRvIGFzc3VtZSBhIERP VFMgb3BlcmF0b3IgY291bGQgaGF2ZSBzb21lIGZvcm0gb2YgdGhyZWF0IGludGVsbGlnZW5jZSB3 aGljaCBjb3VsZCBiZSBwcm92aWRlZCBpbiBzdWNoIGEgc2NlbmFyaW8uPC9kaXY+DQo8ZGl2Pjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5hbmRyZXc8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0i Ij4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiIHN0eWxlPSJwYWdl OiBXb3JkU2VjdGlvbjE7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsg Zm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdo dDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4 dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7 IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij4NCjxk aXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250 LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBjbGFz cz0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv c3Bhbj48L2Rpdj4NCjxzcGFuIGNsYXNzPSIiPjwvc3Bhbj4NCjxkaXYgc3R5bGU9ImJvcmRlci1z dHlsZTogbm9uZSBub25lIG5vbmUgc29saWQ7IGJvcmRlci1sZWZ0LXdpZHRoOiAxLjVwdDsgYm9y ZGVyLWxlZnQtY29sb3I6IGJsdWU7IHBhZGRpbmc6IDBpbiAwaW4gMGluIDRwdDsiIGNsYXNzPSIi Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImJvcmRlci1zdHlsZTogc29saWQgbm9uZSBu b25lOyBib3JkZXItdG9wLXdpZHRoOiAxcHQ7IGJvcmRlci10b3AtY29sb3I6IHJnYigyMjUsIDIy NSwgMjI1KTsgcGFkZGluZzogM3B0IDBpbiAwaW47IiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1h cmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1Rp bWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNs YXNzPSIiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPjxzcGFuIGNsYXNzPSJBcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5Eb3RzIFs8YSBocmVmPSJtYWlsdG86ZG90 cy1ib3VuY2VzQGlldGYub3JnIiBjbGFzcz0iIj5tYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3Jn PC9hPl08c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGIg Y2xhc3M9IiI+T24NCiBCZWhhbGYgT2Y8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PC9iPk1vcnRlbnNlbiwgQW5kcmV3PGJyIGNsYXNzPSIiPg0KPGIgY2xh c3M9IiI+U2VudDo8L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPldlZG5lc2RheSwgRmVicnVhcnkgNywgMjAxOCAxMDozOSBQTTxiciBjbGFzcz0iIj4N CjxiIGNsYXNzPSIiPlRvOjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+ZG90cyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRvdHNAaWV0Zi5vcmciIGNsYXNz PSIiPmRvdHNAaWV0Zi5vcmc8L2E+Jmd0OzxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPlN1Ympl Y3Q6PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5b RG90c10gRndkOiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWRvdHMtcmVxdWlyZW1lbnRzLTEzLnR4 dDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZh bWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIi PiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0 OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7 IiBjbGFzcz0iIj4NCk5vdCB3YW50aW5nIHRvIGxvc2UgbW9tZW50dW0gZnJvbSB0b2RheeKAmXMg aW50ZXJpbSBtZWV0aW5nLCBJ4oCZdmUgdXBkYXRlZCB0aGUgcmVxdWlyZW1lbnRzIGRyYWZ0IHRv IGFkZHJlc3MgdGhlIHJlbWFpbmluZyBpc3N1ZXMuIFBsZWFzZSB0YWtlIGEgY2xvc2UgbG9vayBh dCBHRU4tMDA0IGFuZCAtMDA1LCB3aGljaCBhZGQgdGhlIG1pdGlnYXRpb24gaGludGluZyBhbmQg bG9vcCBoYW5kbGluZyBnZW5lcmFsIHJlcXVpcmVtZW50cywgcmVzcGVjdGl2ZWx5Lg0KIEFzIGRp c2N1c3NlZCBkdXJpbmcgdG9kYXnigJlzIG1lZXRpbmcsIHRoZSBiaWRpcmVjdGlvbmFsaXR5IHJl cXVpcmVtZW50IChmb3JtZXJseSBHRU4tMDAzKSBoYXMgYmVlbiBtb3ZlZCB1bmRlciB0aGUgc2ln bmFsIGNoYW5uZWwgcmVxdWlyZW1lbnRzIGFzIFNJRy0wMDMuPG86cCBjbGFzcz0iIj48L286cD48 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJp ZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9u dC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xh c3M9IiI+DQphbmRyZXc8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBm b250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNs YXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt aWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+ Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6IDVwdDsgbWFyZ2luLWJvdHRvbTogNXB0OyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCkJl Z2luIGZvcndhcmRlZCBtZXNzYWdlOjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBm b250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNs YXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1h cmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1Rp bWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPkZyb206PHNw YW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IiBjbGFzcz0i Ij48YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiBzdHlsZT0iY29sb3I6 IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5pbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmc8L2E+PC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsi IGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRp Y2EsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5TdWJqZWN0OiBbRG90c10gSS1EIEFjdGlvbjogZHJh ZnQtaWV0Zi1kb3RzLXJlcXVpcmVtZW50cy0xMy50eHQ8L3NwYW4+PC9iPjxvOnAgY2xhc3M9IiI+ PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5EYXRlOjxzcGFuIGNs YXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+RmVi cnVhcnkgNywgMjAxOCBhdCAxMjowNTozOCBQTSBFU1Q8L3NwYW4+PG86cCBjbGFzcz0iIj48L286 cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGlu IDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6IEhlbHZldGljYSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPlRvOjxzcGFuIGNsYXNzPSJB cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTogSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+Jmx0OzxhIGhy ZWY9Im1haWx0bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmciIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0 ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPmktZC1hbm5vdW5jZUBpZXRmLm9y ZzwvYT4mZ3Q7PC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIi Pg0KPGIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2EsIHNhbnMt c2VyaWY7IiBjbGFzcz0iIj5DYzo8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGlj YSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPjxhIGhyZWY9Im1haWx0bzpkb3RzQGlldGYub3JnIiBz dHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0i Ij5kb3RzQGlldGYub3JnPC9hPjwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9k aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJw dDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86 cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAxMnB0OyBm b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7Ij4N CjxiciBjbGFzcz0iIj4NCkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRo ZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy48YnIgY2xhc3M9IiI+DQpUaGlz IGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBERG9TIE9wZW4gVGhyZWF0IFNpZ25hbGluZyBX RyBvZiB0aGUgSUVURi48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtUaXRsZSAmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs6IERpc3RyaWJ1dGVkIERlbmlh bCBvZiBTZXJ2aWNlIChERG9TKSBPcGVuIFRocmVhdCBTaWduYWxpbmcgUmVxdWlyZW1lbnRzPGJy IGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7QXV0 aG9ycyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs6IEFu ZHJldyBNb3J0ZW5zZW48YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDtSb2JlcnQgTW9za293aXR6PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7VGlydW1hbGVzd2FyIFJlZGR5PGJyIGNsYXNzPSIiPg0KRmlsZW5h bWUgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7OiBkcmFmdC1pZXRm LWRvdHMtcmVxdWlyZW1lbnRzLTEzLnR4dDxiciBjbGFzcz0iIj4NClBhZ2VzICZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzogMjA8YnIg Y2xhc3M9IiI+DQpEYXRlICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzogMjAxOC0wMi0wNzxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCkFic3RyYWN0OjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO1RoaXMgZG9jdW1l bnQgZGVmaW5lcyB0aGUgcmVxdWlyZW1lbnRzIGZvciB0aGUgRGlzdHJpYnV0ZWQgRGVuaWFsIG9m PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7U2VydmljZSAoRERvUykgT3BlbiBUaHJlYXQgU2ln bmFsaW5nIChET1RTKSBwcm90b2NvbHMgZW5hYmxpbmc8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJz cDtjb29yZGluYXRlZCByZXNwb25zZSB0byBERG9TIGF0dGFja3MuPC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_2C2EA5A20A094ED0BD2A4A0F786ADEE9arbornet_-- From nobody Wed Feb 7 21:36:46 2018 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 6F3D8129C6B for ; Wed, 7 Feb 2018 21:36:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.009 X-Spam-Level: X-Spam-Status: No, score=-7.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 afMgq0h4uoVe for ; Wed, 7 Feb 2018 21:36:42 -0800 (PST) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 A3738127342 for ; Wed, 7 Feb 2018 21:36:41 -0800 (PST) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1518068200; h=From: To:CC:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=f DYjZ5aM6LZ1ZeFhkHEJ/axZPFW5FCoqpB4/AtNPZ3 g=; b=liRcjkmdIyP77ZC6+E7oggyEj1o/VZXQfPM+gM/R3Qd7 dh/D80Z7IxU89EJdRmFb/95Z4pFUUvIOJ3dpYO6YV2HiJHVpFU SwEKdJrejrsJjNgVdioj/3Hvfu6Vi8CqICAF80w1NQsl/FXo3j AXFZ1b8l2O3yCCagMgGNW6+aNVw= Received: from MIVEXAPP1N01.corpzone.internalzone.com (unknown [10.48.48.88]) by MIVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 3a65_06a1_297c5a60_635f_4111_850f_0d2b0b22f421; Wed, 07 Feb 2018 23:36:40 -0600 Received: from MIVEXUSR1N07.corpzone.internalzone.com (10.48.48.87) by MIVEXAPP1N01.corpzone.internalzone.com (10.48.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 8 Feb 2018 00:36:38 -0500 Received: from MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) by MIVEXUSR1N07.corpzone.internalzone.com (10.48.48.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 8 Feb 2018 00:36:37 -0500 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.1347.2 via Frontend Transport; Thu, 8 Feb 2018 00:36:37 -0500 Received: from NAM01-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.1347.2; Thu, 8 Feb 2018 00:36:36 -0500 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1867.namprd16.prod.outlook.com (10.172.45.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.464.11; Thu, 8 Feb 2018 05:36: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.20.0464.016; Thu, 8 Feb 2018 05:36:35 +0000 From: "Konda, Tirumaleswar Reddy" To: "Mortensen, Andrew" CC: dots Thread-Topic: [Dots] Fwd: I-D Action: draft-ietf-dots-requirements-13.txt Thread-Index: AQHToDZrDNoOMgpTNU61SD8wwp8DzKOZ2JtQgAAbdwCAAAh3sA== Date: Thu, 8 Feb 2018 05:36:35 +0000 Message-ID: References: <151802313846.4823.7164614843343039635@ietfa.amsl.com> <158A2A94-1165-4938-A675-C776DE7444CF@arbor.net> <2C2EA5A2-0A09-4ED0-BD2A-4A0F786ADEE9@arbor.net> In-Reply-To: <2C2EA5A2-0A09-4ED0-BD2A-4A0F786ADEE9@arbor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [185.221.69.14] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1867; 7:kDtTlwUnQU/BTwy1Z4+QB17MPfaKMffK6BWlpzfy+Ydrac8JJ0mFq6VkfTlyAiCNMCEogTZiiNjNHgpq3nCCGqyraG3AfhC4nn93hD3FAWZS0ce3vGbMjy2oBZifTd23LAz0OZZm6agj0tgxNyIgwM9ixdhFG7R5OOYtRnJclq+pYy5p/8vdztlwo+o9GOmp1Rt9MQTbZexebNQSUKTSNgdyL/x0SjlSvz2YxHsg/npDReLPA4JJoG0qpJbwjrsg x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 96b3b580-ded2-4e29-bea1-08d56eb5eb1e x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM5PR16MB1867; x-ms-traffictypediagnostic: DM5PR16MB1867: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231101)(2400082)(944501161)(3002001)(10201501046)(6041288)(20161123560045)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(6072148)(201708071742011); SRVR:DM5PR16MB1867; BCL:0; PCL:0; RULEID:; SRVR:DM5PR16MB1867; x-forefront-prvs: 0577AD41D6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39380400002)(39850400004)(376002)(366004)(396003)(377424004)(32952001)(189003)(199004)(97736004)(7736002)(81166006)(33656002)(81156014)(8676002)(86362001)(8936002)(19609705001)(186003)(74316002)(316002)(3280700002)(59450400001)(102836004)(68736007)(99286004)(53546011)(6506007)(3660700001)(77096007)(26005)(76176011)(7696005)(229853002)(2906002)(478600001)(105586002)(72206003)(6116002)(5660300001)(790700001)(3846002)(66066001)(14454004)(2900100001)(93886005)(6916009)(2950100002)(80792005)(6306002)(9686003)(54896002)(6246003)(4326008)(236005)(53936002)(6436002)(55016002)(106356001)(25786009)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1867; 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) x-microsoft-antispam-message-info: DjSyGRgyOdXOg8SEUtoZlcDoQB6Q1Foudufz6fKnqFswS8zM9vzjNfcXf8fCfsCKAbtx+wTOBR8GdiFFAB0fPQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB17887B9D2DDF554D2448F3DBEAF30DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 96b3b580-ded2-4e29-bea1-08d56eb5eb1e X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Feb 2018 05:36:35.4027 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1867 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 <6217> : inlines <6380> : streams <1778354> : uri <2588923> Archived-At: Subject: Re: [Dots] Fwd: I-D Action: draft-ietf-dots-requirements-13.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, 08 Feb 2018 05:36:44 -0000 --_000_DM5PR16MB17887B9D2DDF554D2448F3DBEAF30DM5PR16MB1788namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogTW9ydGVuc2VuLCBBbmRyZXcgW21haWx0bzphbW9ydGVuc2VuQGFyYm9yLm5ldF0NClNl bnQ6IFRodXJzZGF5LCBGZWJydWFyeSA4LCAyMDE4IDEwOjM0IEFNDQpUbzogS29uZGEsIFRpcnVt YWxlc3dhciBSZWRkeSA8VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbT4NCkNjOiBk b3RzIDxkb3RzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtEb3RzXSBGd2Q6IEktRCBBY3Rpb246 IGRyYWZ0LWlldGYtZG90cy1yZXF1aXJlbWVudHMtMTMudHh0DQoNCg0KT24gRmViIDcsIDIwMTgs IGF0IDEwOjI2IFBNLCBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5IDxUaXJ1bWFsZXN3YXJSZWRk eV9Lb25kYUBNY0FmZWUuY29tPG1haWx0bzpUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUu Y29tPj4gd3JvdGU6DQoNCjEpDQogIEdFTi0wMDUgIExvb3AgSGFuZGxpbmc6IEluIHNwZWNpZmlj IHNjZW5hcmlvcywgaXQgbWF5IGJlIHBvc3NpYmxlIGZvcg0KICAgICAgY29tbXVuaWNhdGlvbiBi ZXR3ZWVuIERPVFMgYWdlbnRzIHRvIGxvb3AsIGZvciBleGFtcGxlIGFzIGEgcmVzdWx0DQogICAg ICBvZiBtaXNjb25maWd1cmF0aW9uIG9yIGFnZ3Jlc3NpdmUgY2FjaGluZy4NCg0KY29tbWVudD4g VGhlIGxvb3BpbmcgYXR0YWNrIEpvbiBkaXNjdXNzZWQgaW4gdGhlIG1haWxpbmcgbGlzdCBpcyBi ZWNhdXNlIG9mIG1pc2NvbmZpZ3VyYXRpb24NCmFuZCBETlMgY2FjaGUgcG9pc29uaW5nLiBXaGF0 IGRvIHlvdSBtZWFuIGJ5ICJhZ2dyZXNzaXZlIGNhY2hpbmfigJ0gPw0KDQpTb3JyeSwgSSBoYWQg bWVhbnQgdG8gcHJvdmlkZSBhIHNwZWNpZmljIGV4YW1wbGUgb2YgbWlzY29uZmlndXJhdGlvbiwg YW5kIGRpZG7igJl0IGZpbmlzaCB0aGUgdGhvdWdodC4gSeKAmW0gc2tlcHRpY2FsIG9mIHRoZSBE TlMgY2FjaGUgcG9pc29uaW5nIGV4YW1wbGUgZm9yIHRoZSBzYW1lIHJlYXNvbiB5b3UgY2l0ZWQg b24gdGhlIGxpc3QuDQoNCkxldOKAmXMgcmVtb3ZlIOKAnGFnZ3Jlc3NpdmUgY2FjaGluZ+KAnS4N Cg0KDQogMikgIE1pdGlnYXRpb24gaGludHMgTUFZIGJlIHRyYW5zbWl0dGVkIGFjcm9zcyBlaXRo ZXIgc2lnbmFsIG9yIGRhdGEgY2hhbm5lbC4NCg0KY29tbWVudD4gSSBkb24ndCB0aGluayB0aGUg RE9UUyBjbGllbnQgd2lsbCBrbm93IHRoZSBtaXRpZ2F0aW9uIGhpbnRzIGR1cmluZyBwZWFjZSB0 aW1lIHRvIGNvbnZleSB0aGUgaGludHMgaW4gdGhlIGRhdGEgY2hhbm5lbCAhDQoNCkkgaGFkIGlu IG1pbmQgYWx3YXlzLW9uIG1pdGlnYXRpb24uIEkgd2FudGVkIHRvIGxlYXZlIG9wZW4gdGhlIHBv c3NpYmlsaXR5IHRoYXQgdGhlIERPVFMgY2xpZW50IG9wZXJhdG9ycyBtaWdodCBwcm92aWRlIGhp bnRzIHRvIGluZm9ybSB0aGUgc2hhcGUgb2YgdGhhdCBhbHdheXMtb24gbWl0aWdhdGlvbi4gU2lu Y2UgdGhlIGNvbnZlcnNhdGlvbiBsZWFkaW5nIHRvIHRoaXMgcmVxdWlyZW1lbnQgYWRkaXRpb24g Y29uY2x1ZGVkIHdpdGggd2hhdCBzZWVtZWQgdG8gYmUgYW4gYWdyZWVtZW50IHRoYXQgd2Ugd2Fu dGVkIHRvIGNyZWF0ZSBzcGFjZSBmb3IgdW5kZWZpbmVkIGZvcm1zIG9mIGhpbnRpbmcsIGl0IHNl ZW1lZCByZWFzb25hYmxlIHRvIGFzc3VtZSBhIERPVFMgb3BlcmF0b3IgY291bGQgaGF2ZSBzb21l IGZvcm0gb2YgdGhyZWF0IGludGVsbGlnZW5jZSB3aGljaCBjb3VsZCBiZSBwcm92aWRlZCBpbiBz dWNoIGEgc2NlbmFyaW8uDQoNCkdvdCBpdCwgdGhhbmtzLg0KDQpDaGVlcnMsDQotVGlydQ0KDQph bmRyZXcNCg0KDQoNCg0KRnJvbTogRG90cyBbbWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIE1vcnRlbnNlbiwgQW5kcmV3DQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5 IDcsIDIwMTggMTA6MzkgUE0NClRvOiBkb3RzIDxkb3RzQGlldGYub3JnPG1haWx0bzpkb3RzQGll dGYub3JnPj4NClN1YmplY3Q6IFtEb3RzXSBGd2Q6IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtZG90 cy1yZXF1aXJlbWVudHMtMTMudHh0DQoNCk5vdCB3YW50aW5nIHRvIGxvc2UgbW9tZW50dW0gZnJv bSB0b2RheeKAmXMgaW50ZXJpbSBtZWV0aW5nLCBJ4oCZdmUgdXBkYXRlZCB0aGUgcmVxdWlyZW1l bnRzIGRyYWZ0IHRvIGFkZHJlc3MgdGhlIHJlbWFpbmluZyBpc3N1ZXMuIFBsZWFzZSB0YWtlIGEg Y2xvc2UgbG9vayBhdCBHRU4tMDA0IGFuZCAtMDA1LCB3aGljaCBhZGQgdGhlIG1pdGlnYXRpb24g aGludGluZyBhbmQgbG9vcCBoYW5kbGluZyBnZW5lcmFsIHJlcXVpcmVtZW50cywgcmVzcGVjdGl2 ZWx5LiBBcyBkaXNjdXNzZWQgZHVyaW5nIHRvZGF54oCZcyBtZWV0aW5nLCB0aGUgYmlkaXJlY3Rp b25hbGl0eSByZXF1aXJlbWVudCAoZm9ybWVybHkgR0VOLTAwMykgaGFzIGJlZW4gbW92ZWQgdW5k ZXIgdGhlIHNpZ25hbCBjaGFubmVsIHJlcXVpcmVtZW50cyBhcyBTSUctMDAzLg0KDQphbmRyZXcN Cg0KDQpCZWdpbiBmb3J3YXJkZWQgbWVzc2FnZToNCg0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGll dGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbRG90c10g SS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1kb3RzLXJlcXVpcmVtZW50cy0xMy50eHQNCkRhdGU6IEZl YnJ1YXJ5IDcsIDIwMTggYXQgMTI6MDU6MzggUE0gRVNUDQpUbzogPGktZC1hbm5vdW5jZUBpZXRm Lm9yZzxtYWlsdG86aS1kLWFubm91bmNlQGlldGYub3JnPj4NCkNjOiBkb3RzQGlldGYub3JnPG1h aWx0bzpkb3RzQGlldGYub3JnPg0KDQoNCkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJs ZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NClRoaXMgZHJh ZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIEREb1MgT3BlbiBUaHJlYXQgU2lnbmFsaW5nIFdHIG9m IHRoZSBJRVRGLg0KDQogICAgICAgVGl0bGUgICAgICAgICAgIDogRGlzdHJpYnV0ZWQgRGVuaWFs IG9mIFNlcnZpY2UgKEREb1MpIE9wZW4gVGhyZWF0IFNpZ25hbGluZyBSZXF1aXJlbWVudHMNCiAg ICAgICBBdXRob3JzICAgICAgICAgOiBBbmRyZXcgTW9ydGVuc2VuDQogICAgICAgICAgICAgICAg ICAgICAgICAgUm9iZXJ0IE1vc2tvd2l0eg0KICAgICAgICAgICAgICAgICAgICAgICAgIFRpcnVt YWxlc3dhciBSZWRkeQ0KRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1kb3RzLXJlcXVpcmVt ZW50cy0xMy50eHQNClBhZ2VzICAgICAgICAgICA6IDIwDQpEYXRlICAgICAgICAgICAgOiAyMDE4 LTAyLTA3DQoNCkFic3RyYWN0Og0KICBUaGlzIGRvY3VtZW50IGRlZmluZXMgdGhlIHJlcXVpcmVt ZW50cyBmb3IgdGhlIERpc3RyaWJ1dGVkIERlbmlhbCBvZg0KICBTZXJ2aWNlIChERG9TKSBPcGVu IFRocmVhdCBTaWduYWxpbmcgKERPVFMpIHByb3RvY29scyBlbmFibGluZw0KICBjb29yZGluYXRl ZCByZXNwb25zZSB0byBERG9TIGF0dGFja3MuDQoNCg== --_000_DM5PR16MB17887B9D2DDF554D2448F3DBEAF30DM5PR16MB1788namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIg MSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0K CXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6IlxARGVuZ1hpYW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRp di5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJ e21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUx OQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBNb3J0ZW5zZW4sIEFu ZHJldyBbbWFpbHRvOmFtb3J0ZW5zZW5AYXJib3IubmV0XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRo dXJzZGF5LCBGZWJydWFyeSA4LCAyMDE4IDEwOjM0IEFNPGJyPg0KPGI+VG86PC9iPiBLb25kYSwg VGlydW1hbGVzd2FyIFJlZGR5ICZsdDtUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29t Jmd0Ozxicj4NCjxiPkNjOjwvYj4gZG90cyAmbHQ7ZG90c0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFtEb3RzXSBGd2Q6IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtZG90cy1y ZXF1aXJlbWVudHMtMTMudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBG ZWIgNywgMjAxOCwgYXQgMTA6MjYgUE0sIEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgJmx0Ozxh IGhyZWY9Im1haWx0bzpUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tIj5UaXJ1bWFs ZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjEpPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDtHRU4tMDA1Jm5ic3A7IExvb3AgSGFuZGxpbmc6IElu IHNwZWNpZmljIHNjZW5hcmlvcywgaXQgbWF5IGJlIHBvc3NpYmxlIGZvcjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvbW11bmljYXRpb24gYmV0d2Vl biBET1RTIGFnZW50cyB0byBsb29wLCBmb3IgZXhhbXBsZSBhcyBhIHJlc3VsdDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9mIG1pc2NvbmZpZ3VyYXRp b24gb3IgYWdncmVzc2l2ZSBjYWNoaW5nLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5jb21tZW50Jmd0OyBUaGUgbG9vcGluZyBhdHRhY2sgSm9uIGRpc2N1c3Nl ZCBpbiB0aGUgbWFpbGluZyBsaXN0IGlzIGJlY2F1c2Ugb2YgbWlzY29uZmlndXJhdGlvbjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+YW5kIEROUyBjYWNoZSBwb2lzb25pbmcuIFdoYXQgZG8geW91IG1lYW4g YnkgJnF1b3Q7YWdncmVzc2l2ZSBjYWNoaW5n4oCdID88L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+U29ycnksIEkgaGFkIG1lYW50IHRvIHByb3ZpZGUgYSBzcGVjaWZpYyBleGFtcGxlIG9mIG1p c2NvbmZpZ3VyYXRpb24sIGFuZCBkaWRu4oCZdCBmaW5pc2ggdGhlIHRob3VnaHQuIEnigJltIHNr ZXB0aWNhbCBvZiB0aGUgRE5TIGNhY2hlIHBvaXNvbmluZyBleGFtcGxlIGZvciB0aGUgc2FtZSBy ZWFzb24geW91IGNpdGVkIG9uIHRoZSBsaXN0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkxldOKAmXMgcmVtb3ZlIOKAnGFn Z3Jlc3NpdmUgY2FjaGluZ+KAnS4gJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7MikmbmJzcDsg TWl0aWdhdGlvbiBoaW50cyBNQVkgYmUgdHJhbnNtaXR0ZWQgYWNyb3NzIGVpdGhlciBzaWduYWwg b3IgZGF0YSBjaGFubmVsLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5jb21tZW50Jmd0OyBJIGRvbid0IHRoaW5rIHRoZSBET1RTIGNsaWVudCB3aWxsIGtub3cg dGhlIG1pdGlnYXRpb24gaGludHMgZHVyaW5nIHBlYWNlIHRpbWUgdG8gY29udmV5IHRoZSBoaW50 cyBpbiB0aGUgZGF0YSBjaGFubmVsICE8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGFkIGluIG1pbmQg YWx3YXlzLW9uIG1pdGlnYXRpb24uIEkgd2FudGVkIHRvIGxlYXZlIG9wZW4gdGhlIHBvc3NpYmls aXR5IHRoYXQgdGhlIERPVFMgY2xpZW50IG9wZXJhdG9ycyBtaWdodCBwcm92aWRlIGhpbnRzIHRv IGluZm9ybSB0aGUgc2hhcGUgb2YgdGhhdCBhbHdheXMtb24gbWl0aWdhdGlvbi4gU2luY2UgdGhl IGNvbnZlcnNhdGlvbiBsZWFkaW5nIHRvIHRoaXMgcmVxdWlyZW1lbnQgYWRkaXRpb24NCiBjb25j bHVkZWQgd2l0aCB3aGF0IHNlZW1lZCB0byBiZSBhbiBhZ3JlZW1lbnQgdGhhdCB3ZSB3YW50ZWQg dG8gY3JlYXRlIHNwYWNlIGZvciB1bmRlZmluZWQgZm9ybXMgb2YgaGludGluZywgaXQgc2VlbWVk IHJlYXNvbmFibGUgdG8gYXNzdW1lIGEgRE9UUyBvcGVyYXRvciBjb3VsZCBoYXZlIHNvbWUgZm9y bSBvZiB0aHJlYXQgaW50ZWxsaWdlbmNlIHdoaWNoIGNvdWxkIGJlIHByb3ZpZGVkIGluIHN1Y2gg YSBzY2VuYXJpby48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5Hb3QgaXQsIHRoYW5rcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Q2hlZXJz LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+LVRpcnU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPmFuZHJldzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5Eb3RzDQogWzxhIGhyZWY9Im1haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0 bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48Yj5PbiBCZWhhbGYgT2Y8c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPk1vcnRlbnNlbiwgQW5kcmV3PGJyPg0KPGI+ U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PldlZG5lc2RheSwgRmVicnVhcnkgNywgMjAxOCAxMDozOSBQTTxicj4NCjxiPlRvOjwvYj48c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ZG90cyAmbHQ7PGEg aHJlZj0ibWFpbHRvOmRvdHNAaWV0Zi5vcmciPmRvdHNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxi PlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj5bRG90c10gRndkOiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWRvdHMtcmVxdWlyZW1lbnRz LTEzLnR4dDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5vdCB3YW50aW5nIHRvIGxvc2UgbW9tZW50dW0g ZnJvbSB0b2RheeKAmXMgaW50ZXJpbSBtZWV0aW5nLCBJ4oCZdmUgdXBkYXRlZCB0aGUgcmVxdWly ZW1lbnRzIGRyYWZ0IHRvIGFkZHJlc3MgdGhlIHJlbWFpbmluZyBpc3N1ZXMuIFBsZWFzZSB0YWtl IGEgY2xvc2UgbG9vayBhdCBHRU4tMDA0IGFuZCAtMDA1LCB3aGljaCBhZGQgdGhlIG1pdGlnYXRp b24gaGludGluZyBhbmQgbG9vcCBoYW5kbGluZyBnZW5lcmFsIHJlcXVpcmVtZW50cywNCiByZXNw ZWN0aXZlbHkuIEFzIGRpc2N1c3NlZCBkdXJpbmcgdG9kYXnigJlzIG1lZXRpbmcsIHRoZSBiaWRp cmVjdGlvbmFsaXR5IHJlcXVpcmVtZW50IChmb3JtZXJseSBHRU4tMDAzKSBoYXMgYmVlbiBtb3Zl ZCB1bmRlciB0aGUgc2lnbmFsIGNoYW5uZWwgcmVxdWlyZW1lbnRzIGFzIFNJRy0wMDMuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5hbmRyZXc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkJlZ2luIGZvcndhcmRlZCBtZXNzYWdlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YSBo cmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6 cHVycGxlIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L3NwYW4+PC9hPjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+U3ViamVjdDogW0RvdHNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtZG90cy1yZXF1 aXJlbWVudHMtMTMudHh0PC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+RGF0ZTo8c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkZlYnJ1 YXJ5IDcsIDIwMTggYXQgMTI6MDU6MzggUE0gRVNUPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5Ubzo8 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWYiPiZsdDs8YSBocmVmPSJtYWlsdG86aS1kLWFubm91bmNlQGlldGYub3JnIj48c3BhbiBzdHls ZT0iY29sb3I6cHVycGxlIj5pLWQtYW5ub3VuY2VAaWV0Zi5vcmc8L3NwYW4+PC9hPiZndDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPkNjOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGEgaHJlZj0ibWFpbHRvOmRvdHNAaWV0Zi5vcmci PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmRvdHNAaWV0Zi5vcmc8L3NwYW4+PC9hPjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpBIE5ldyBJ bnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFm dHMgZGlyZWN0b3JpZXMuPGJyPg0KVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgRERv UyBPcGVuIFRocmVhdCBTaWduYWxpbmcgV0cgb2YgdGhlIElFVEYuPGJyPg0KPGJyPg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7VGl0bGUgJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7OiBEaXN0cmlidXRl ZCBEZW5pYWwgb2YgU2VydmljZSAoRERvUykgT3BlbiBUaHJlYXQgU2lnbmFsaW5nIFJlcXVpcmVt ZW50czxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0F1dGhv cnMgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7OiBBbmRy ZXcgTW9ydGVuc2VuPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Um9i ZXJ0IE1vc2tvd2l0ejxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1Rp cnVtYWxlc3dhciBSZWRkeTxicj4NCkZpbGVuYW1lICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOzogZHJhZnQtaWV0Zi1kb3RzLXJlcXVpcmVtZW50cy0xMy50eHQ8YnI+ DQpQYWdlcyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDs6IDIwPGJyPg0KRGF0ZSAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs6IDIwMTgtMDItMDc8YnI+DQo8YnI+ DQpBYnN0cmFjdDo8YnI+DQombmJzcDsmbmJzcDtUaGlzIGRvY3VtZW50IGRlZmluZXMgdGhlIHJl cXVpcmVtZW50cyBmb3IgdGhlIERpc3RyaWJ1dGVkIERlbmlhbCBvZjxicj4NCiZuYnNwOyZuYnNw O1NlcnZpY2UgKEREb1MpIE9wZW4gVGhyZWF0IFNpZ25hbGluZyAoRE9UUykgcHJvdG9jb2xzIGVu YWJsaW5nPGJyPg0KJm5ic3A7Jm5ic3A7Y29vcmRpbmF0ZWQgcmVzcG9uc2UgdG8gRERvUyBhdHRh Y2tzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_DM5PR16MB17887B9D2DDF554D2448F3DBEAF30DM5PR16MB1788namp_-- From nobody Wed Feb 7 21:37:12 2018 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 AAC8E129C6B; Wed, 7 Feb 2018 21:37:04 -0800 (PST) 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.72.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151806822467.17196.8770194328057170517@ietfa.amsl.com> Date: Wed, 07 Feb 2018 21:37:04 -0800 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-requirements-14.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, 08 Feb 2018 05:37:04 -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 (DDoS) Open Threat Signaling Requirements Authors : Andrew Mortensen Robert Moskowitz Tirumaleswar Reddy Filename : draft-ietf-dots-requirements-14.txt Pages : 20 Date : 2018-02-07 Abstract: This document defines the requirements for the Distributed Denial of Service (DDoS) Open Threat Signaling (DOTS) protocols enabling coordinated response to DDoS attacks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-requirements/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-requirements-14 https://datatracker.ietf.org/doc/html/draft-ietf-dots-requirements-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-requirements-14 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 Feb 7 21:39:01 2018 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 2A864129C6B for ; Wed, 7 Feb 2018 21:39:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 DDOL2e0eJiiH for ; Wed, 7 Feb 2018 21:38:57 -0800 (PST) Received: from mx0a-00196b01.pphosted.com (mx0a-00196b01.pphosted.com [67.231.149.170]) (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 D7A17127342 for ; Wed, 7 Feb 2018 21:38:57 -0800 (PST) Received: from pps.filterd (m0072398.ppops.net [127.0.0.1]) by mx0a-00196b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w185awSf032383 for ; Thu, 8 Feb 2018 00:38:57 -0500 Received: from nam02-cy1-obe.outbound.protection.outlook.com (mail-cys01nam02lp0048.outbound.protection.outlook.com [207.46.163.48]) by mx0a-00196b01.pphosted.com with ESMTP id 2fwa3uq019-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Thu, 08 Feb 2018 00:38:57 -0500 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=2SIlGNRNobSm6wBk3pdpaf2P9VSnO5A2hjWpSRootsI=; b=PhTIA86wytxwk3J60ctCV8Nhj9S7F3Bqjdfte4MIY3Q0FK1YSq13PT6imcaKEFMudi/G8Jjz7ASv2WOAZE9vsKhONcZUehUlessEo9xPqPPK7TsaugLm25cGdulzw7C3dCJl6rKSGgACfoKv1ViiL0QFE+u5C8fEzKdikypyT+4= Received: from BN3PR01MB1987.prod.exchangelabs.com (10.166.71.144) by BN3PR01MB1399.prod.exchangelabs.com (10.163.36.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.10; Thu, 8 Feb 2018 05:38:54 +0000 Received: from BN3PR01MB1987.prod.exchangelabs.com ([fe80::4cdd:1182:f095:b22b]) by BN3PR01MB1987.prod.exchangelabs.com ([fe80::4cdd:1182:f095:b22b%17]) with mapi id 15.20.0485.009; Thu, 8 Feb 2018 05:38:54 +0000 From: "Mortensen, Andrew" To: dots Thread-Topic: [Dots] I-D Action: draft-ietf-dots-requirements-14.txt Thread-Index: AQHToJ7hWAgkKxU5eEuvko3tt+1c3A== Date: Thu, 8 Feb 2018 05:38:54 +0000 Message-ID: References: <151806822467.17196.8770194328057170517@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [68.49.167.203] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR01MB1399; 7:IsFs5aaZrimW25pqpqMP2pnwVspXaOxsOqS1I1/9ciP9odU7MzFPHJTinV2QEb4k6Q0wpNZGV/cN3Rg1dCKnYYTID8e8cEEgkGM0NJ6zVIMEtNqkXzAjVK30qKL0bICKrVLWxEMSmsEKGjl4FAN1CBBaJm7h95P7tzRrCp8AMk2iDiPHXqA2CNlj0lHbhQgtrugJzS5tbOI/FBoqplNtPrcGyoT1Zi+ANF5CE6sdpwEBvm0tkjPAjpYMcqpB2/IA x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 58ac7f89-8388-44d9-025b-08d56eb63dc3 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:BN3PR01MB1399; x-ms-traffictypediagnostic: BN3PR01MB1399: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(10201501046)(3231101)(2400082)(944501161)(6041288)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:BN3PR01MB1399; BCL:0; PCL:0; RULEID:; SRVR:BN3PR01MB1399; x-forefront-prvs: 0577AD41D6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(39860400002)(346002)(366004)(396003)(376002)(377424004)(189003)(199004)(33656002)(102836004)(83716003)(6486002)(82746002)(26005)(53936002)(229853002)(186003)(25786009)(106356001)(6512007)(54896002)(2473003)(6116002)(97736004)(99286004)(3280700002)(7736002)(3660700001)(236005)(36756003)(2900100001)(86362001)(3846002)(5250100002)(6436002)(14454004)(76176011)(66066001)(316002)(2906002)(5660300001)(8676002)(81156014)(478600001)(6916009)(68736007)(6506007)(105586002)(8936002)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR01MB1399; H:BN3PR01MB1987.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) x-microsoft-antispam-message-info: m+6dnMTn24Tz7Y3I0gYH305lC7389ehChy7fNcVq8fRg8bV1t1a1LoPKtFRAV/Q6VtxV7fehAD9oiGJhDfHA5A== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_F16D41025AD54CB293753712A6296D12arbornet_" MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-Network-Message-Id: 58ac7f89-8388-44d9-025b-08d56eb63dc3 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Feb 2018 05:38:54.0680 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR01MB1399 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-08_02:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=798 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802080055 Archived-At: Subject: [Dots] Fwd: I-D Action: draft-ietf-dots-requirements-14.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, 08 Feb 2018 05:39:00 -0000 --_000_F16D41025AD54CB293753712A6296D12arbornet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Quick turnaround of feedback from Tiru on the initial mitigation hinting an= d loop handling requirements in -13. andrew Begin forwarded message: From: internet-drafts@ietf.org Subject: [Dots] I-D Action: draft-ietf-dots-requirements-14.txt Date: February 8, 2018 at 12:37:04 AM EST To: > Cc: dots@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DDoS Open Threat Signaling WG of the IETF. Title : Distributed Denial of Service (DDoS) Open Threat S= ignaling Requirements Authors : Andrew Mortensen Robert Moskowitz Tirumaleswar Reddy Filename : draft-ietf-dots-requirements-14.txt Pages : 20 Date : 2018-02-07 Abstract: This document defines the requirements for the Distributed Denial of Service (DDoS) Open Threat Signaling (DOTS) protocols enabling coordinated response to DDoS attacks. --_000_F16D41025AD54CB293753712A6296D12arbornet_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Quick turnaround of feedback from Tiru on the initial mitigation hinting an= d loop handling requirements in -13.

andrew



Begin forwarded message:

From: internet-drafts@ietf.org
Subject: [Dots] I-D Action: draft-= ietf-dots-requirements-14.txt
Date: February 8, 2018 at 12:37:04 AM EST
To: <i-d-announce@ietf.org>
Cc: dots@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the DDoS Open Threat Signaling WG of the IETF.=

       Title     &nb= sp;     : Distributed Denial of Service (DDoS) Ope= n Threat Signaling Requirements
       Authors     &= nbsp;   : Andrew Mortensen
            &nb= sp;            = Robert Moskowitz
            &nb= sp;            = Tirumaleswar Reddy
Filename &n= bsp;      : draft-ietf-dots-requirements-14.t= xt
Pages  = ;         : 20
Date  =           : 2018-02-07
Abstract:
  This document defines the requirements for the Distributed Deni= al of
  Service (DDoS) Open Threat Signaling (DOTS) protocols enabling<= br class=3D"">   coordinated response to DDoS attacks.

--_000_F16D41025AD54CB293753712A6296D12arbornet_-- From nobody Wed Feb 14 00:17:52 2018 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 02A94126B6D for ; Wed, 14 Feb 2018 00:17:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 hET1xw7SpvzB for ; Wed, 14 Feb 2018 00:17:49 -0800 (PST) Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30D53126C26 for ; Wed, 14 Feb 2018 00:17:49 -0800 (PST) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 7FB75C0C41 for ; Wed, 14 Feb 2018 09:17:47 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.32]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 60A041A0067 for ; Wed, 14 Feb 2018 09:17:47 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM32.corporate.adroot.infra.ftgroup ([fe80::8924:188:2124:a046%19]) with mapi id 14.03.0382.000; Wed, 14 Feb 2018 09:17:47 +0100 From: To: "dots@ietf.org" Thread-Topic: draft-ietf-dots-data-channel: Filter Activation Thread-Index: AdOlbErzDQUpkmr3SvqsVrn/wnlEDA== Date: Wed, 14 Feb 2018 08:17:46 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0D1F64@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A0D1F64OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: [Dots] draft-ietf-dots-data-channel: Filter Activation 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, 14 Feb 2018 08:17:51 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A0D1F64OPEXCLILMA3corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, As agreed during the interim, there are some issues that need fixes in the = data-channel spec. We would like to hear from the WG to know what to record= in the document. Issue description: Do we assume that all filtering rules, communicated by D= OTS clients, are activated by default or only when a mitigation is active? Below a proposal for discussion: - We should support both: o Immediate activation is useful in deployment cases where filtering is = used to anticipate some attacks and therefore avoid that access resources a= re abused when an attack become effective. This is typically the case where= DOTS server is deployed by access providers. o The reasoning may not be the same if the DOTS service is on the cloud. - The intended action will be governed by a new attribute called "activa= tion-type" which can be set to "immediate" or "mitigation-time". This param= eter will be supplied by a DOTS client in a filter creation request. - Which default value to use if no "activation-type" is supplied by a cl= ient? Please comment. Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300A0D1F64OPEXCLILMA3corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

As agreed during the interim, there are som= e issues that need fixes in the data-channel spec. We would like to hear fr= om the WG to know what to record in the document.

 

Issue description: Do we assume that all fi= ltering rules, communicated by DOTS clients, are activated by default or on= ly when a mitigation is active?

 

Below a proposal for discussion:=

R= 11;   = ; We should support both:

o    Immediate activation is useful in d= eployment cases where filtering is used to anticipate some attacks and ther= efore avoid that access resources are abused when an attack become effective. This is typically the case where DOTS server i= s deployed by access providers.

o    The reasoning may not be the same i= f the DOTS service is on the cloud.

R= 11;   = ; The intended action will be governe= d by a new attribute called “activation-type” which can be set = to “immediate” or “mitigation-time”. This parameter= will be supplied by a DOTS client in a filter creation request. =

R= 11;   = ; Which default value to use if no &#= 8220;activation-type” is supplied by a client?

 = ;

Please com= ment.

 = ;

Cheers,

Med

--_000_787AE7BB302AE849A7480A190F8B93300A0D1F64OPEXCLILMA3corp_-- From nobody Wed Feb 14 00:18:47 2018 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 CFBFD126C83 for ; Wed, 14 Feb 2018 00:18:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 JZ10JyG7zRTk for ; Wed, 14 Feb 2018 00:18:44 -0800 (PST) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64249126C26 for ; Wed, 14 Feb 2018 00:18:44 -0800 (PST) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 11C44C1556 for ; Wed, 14 Feb 2018 09:18:43 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.62]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id EACF22006A for ; Wed, 14 Feb 2018 09:18:42 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5E.corporate.adroot.infra.ftgroup ([fe80::2912:bfa5:91d3:bf63%18]) with mapi id 14.03.0382.000; Wed, 14 Feb 2018 09:18:42 +0100 From: To: "dots@ietf.org" Thread-Topic: draft-ietf-dots-data-channel: Filter Direction Thread-Index: AdOlbGwqi1N7Z468TzqkpTeHXPf9AQ== Date: Wed, 14 Feb 2018 08:18:41 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0D1F7C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A0D1F7COPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: [Dots] draft-ietf-dots-data-channel: Filter Direction 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, 14 Feb 2018 08:18:46 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A0D1F7COPEXCLILMA3corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, As agreed during the interim, there are some issues that need fixes in the = data-channel spec. We would like to hear from the WG to know what to record= in the document. Issue description: Do we need to support explicit "direction" in filtering = rules ("in"/"out")? That is, do we allow a DOTS client to create filters fo= r both incoming and outgoing traffic? Below a proposal for discussion: - The current default direction is aligned with the nature of DDoS attac= ks targeted by DOTS: i.e. incoming. The DOTS client domain is assumed to be= the destination. No ambiguity so far with such default behavior. - There is no clear use case for the support of outgoing filtering handl= ing in the context of DOTS. - No text change is required to the draft. Any objection? Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300A0D1F7COPEXCLILMA3corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

As agreed during the interim, there are som= e issues that need fixes in the data-channel spec. We would like to hear fr= om the WG to know what to record in the document.

 

Issue description: Do we need to support ex= plicit “direction” in filtering rules (“in”/“= out”)? That is, do we allow a DOTS client to create filters for both = incoming and outgoing traffic?

 

Below a proposal for discussion:=

R= 11;   = ; The current default direction is al= igned with the nature of DDoS attacks targeted by DOTS: i.e. incoming. The = DOTS client domain is assumed to be the destination. No ambiguity so far with such default behavior.

R= 11;   = ; There is no clear use case for the = support of outgoing filtering handling in the context of DOTS.

R= 11;   = ; No text change is required to the d= raft.

 = ;

Any object= ion?

 = ;

Cheers,

Med

 

--_000_787AE7BB302AE849A7480A190F8B93300A0D1F7COPEXCLILMA3corp_-- From nobody Wed Feb 14 00:19:20 2018 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 73225126C26 for ; Wed, 14 Feb 2018 00:19:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 qmD6XDzTULqV for ; Wed, 14 Feb 2018 00:19:18 -0800 (PST) Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC12A126B6D for ; Wed, 14 Feb 2018 00:19:17 -0800 (PST) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 85DD2A151A for ; Wed, 14 Feb 2018 09:19:16 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.19]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 68C794007F for ; Wed, 14 Feb 2018 09:19:16 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM44.corporate.adroot.infra.ftgroup ([fe80::b08d:5b75:e92c:a45f%18]) with mapi id 14.03.0382.000; Wed, 14 Feb 2018 09:19:16 +0100 From: To: "dots@ietf.org" Thread-Topic: draft-ietf-dots-data-channel: Filtering Fields Thread-Index: AdOlbICGgF2MxoHnQied7J+cvW2QAA== Date: Wed, 14 Feb 2018 08:19:16 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0D1F93@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A0D1F93OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: [Dots] draft-ietf-dots-data-channel: Filtering Fields 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, 14 Feb 2018 08:19:19 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A0D1F93OPEXCLILMA3corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, As agreed during the interim, there are some issues that need fixes in the = data-channel spec. We would like to hear from the WG to know what to record= in the document. Issue description: Should we support all of the match fields defined by "ie= tf-packet-fields" or do we need to define a minimum supported set? Would it be useful for a client to retrieve the list of match criteria supp= orted by a DOTS server? Please comment. Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300A0D1F93OPEXCLILMA3corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

As agreed during the interim, there are som= e issues that need fixes in the data-channel spec. We would like to hear fr= om the WG to know what to record in the document.

 

Issue description: Should we support all of= the match fields defined by “ietf-packet-fields” or do we need= to define a minimum supported set?

Would it be useful for a client to retrieve= the list of match criteria supported by a DOTS server?

 

Please com= ment.

 = ;

Cheers,

Med= <= /o:p>

--_000_787AE7BB302AE849A7480A190F8B93300A0D1F93OPEXCLILMA3corp_-- From nobody Wed Feb 14 00:20:40 2018 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 9842B126C83 for ; Wed, 14 Feb 2018 00:20:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 n1j8A6zDIVOa for ; Wed, 14 Feb 2018 00:20:38 -0800 (PST) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AB6A126C26 for ; Wed, 14 Feb 2018 00:20:38 -0800 (PST) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id AB9EE16099A for ; Wed, 14 Feb 2018 09:20:36 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.17]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 8E3BB60073 for ; Wed, 14 Feb 2018 09:20:36 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM24.corporate.adroot.infra.ftgroup ([fe80::a1e6:3e6a:1f68:5f7e%18]) with mapi id 14.03.0382.000; Wed, 14 Feb 2018 09:20:36 +0100 From: To: "dots@ietf.org" Thread-Topic: draft-ietf-dots-data-channel: Global or Per-client Filters Thread-Index: AdOlbK/SFiGBcdnZRPCkh1qUQojTYg== Date: Wed, 14 Feb 2018 08:20:35 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0D1FAE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A0D1FAEOPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: [Dots] draft-ietf-dots-data-channel: Global or Per-client Filters 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, 14 Feb 2018 08:20:39 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A0D1FAEOPEXCLILMA3corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, As agreed during the interim, there are some issues that need fixes in the = data-channel spec. We would like to hear from the WG to know what to record= in the document. Issue description: If filters are activated only at the mitigation time, do= we consider filters created by a client are globally available to all clie= nts of the same domain or not? Below a proposal for discussion: - Filters that are activated only during mitigation time are on a per-cl= ient basis. Any objection? Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300A0D1FAEOPEXCLILMA3corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

As agreed during the interim, there are som= e issues that need fixes in the data-channel spec. We would like to hear fr= om the WG to know what to record in the document.

 

Issue description: If filters are activated= only at the mitigation time, do we consider filters created by a client ar= e globally available to all clients of the same domain or not?

 

Below a proposal for discussion:=

R= 11;   = ; Filters that are activated only dur= ing mitigation time are on a per-client basis.

 = ;

Any object= ion?

 = ;

Cheers,

Med

--_000_787AE7BB302AE849A7480A190F8B93300A0D1FAEOPEXCLILMA3corp_-- From nobody Wed Feb 14 00:23:21 2018 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 2AA1D126C83 for ; Wed, 14 Feb 2018 00:23:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 0OkZB7GuQLjo for ; Wed, 14 Feb 2018 00:23:18 -0800 (PST) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11ABE126C26 for ; Wed, 14 Feb 2018 00:23:18 -0800 (PST) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id E0C70161560 for ; Wed, 14 Feb 2018 09:23:16 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.18]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id C422816005E for ; Wed, 14 Feb 2018 09:23:16 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([fe80::cba:56d0:a732:ef5a%19]) with mapi id 14.03.0382.000; Wed, 14 Feb 2018 09:23:16 +0100 From: To: "dots@ietf.org" Thread-Topic: draft-ietf-dots-data-channel: Lifetime handling Thread-Index: AdOlbQ72FAzJz3VcRLyAIRvKZ6oNtw== Date: Wed, 14 Feb 2018 08:23:16 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0D1FD4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A0D1FD4OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: [Dots] draft-ietf-dots-data-channel: Lifetime handling 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, 14 Feb 2018 08:23:20 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A0D1FD4OPEXCLILMA3corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, As agreed during the interim, there are some issues that need fixes in the = data-channel spec. We would like to hear from the WG to know what to record= in the document. Issue description: It was agreed to associate a lifetime with entries insta= ntiated by a DOTS client (-12). The current behavior in the spec is as foll= ows: - A lifetime hint is included in the resource creation request by the cl= ient. - The server may honor the suggested lifetime or assign a distinct value= as per its local policies. When a distinct value is used by the server, the issue is how to notify the= client given that RFC8040 says: "If the POST method succeeds, a "201 Created" status-line is returned and t= here is no response message-body." * Option 1: A work around would be to relax the above constraint at the server side to = include a message-body even for "201 Created", but this is not a clean desi= gn as it requires changes to the base RESTCONF spec. * Option 2: Change completely the data module so that we can make use of operations (ac= tion/rpc). For example, these operations can be defined: +---x activate-filtering | +---w input | | +---w name string | | +---w lifetime-hint int32 | +--ro output | +--ro name string | +--ro lifetime int32 +---x deactivate-filtering +---w input +---w name string This approach will require major changes to the document. This may not be j= ustified given that in some cases no lifetime is included at all. * Option 3: This one assumes that servers must maintain an entry for a minimum period (= e.g., 1 week, 1 month). No Lifetime is included in a request. If no refresh= request is seen from the client, the server removes expired entries. This one requires minor changes to the document. * Option 4: This approach does not associate a lifetime with filtering/alias entries bu= t maintains an inactivity timer of a given DOTS client. This option does no= t allow to clean stale mappings that may be induced by clients that do not = remove their state appropriately. Recommended position: - Proceed with option 3. Any objection? Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300A0D1FD4OPEXCLILMA3corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

As agreed during the interim, there are som= e issues that need fixes in the data-channel spec. We would like to hear fr= om the WG to know what to record in the document.

 

Issue description: It was agreed to associa= te a lifetime with entries instantiated by a DOTS client (-12). The current= behavior in the spec is as follows:

-    A lifetime hint is included in the = resource creation request by the client.

-    The server may honor the suggested = lifetime or assign a distinct value as per its local policies.   =

 

When a distinct value is used by the server= , the issue is how to notify the client given that RFC8040 says:=

 

"If the POST method succeeds, a "= 201 Created" status-line is returned and there is no response message-= body."

 

* Option 1:

 

A work around would be to relax the above c= onstraint at the server side to include a message-body even for “201 = Created”, but this is not a clean desi= gn as it requires changes to the base RESTCONF spec.

 

* Option 2:

 

Change completely the data module so that w= e can make use of operations (action/rpc). For example, these operations ca= n be defined:

 

    &nbs= p;     +---x activate-filtering

    &nbs= p;     |  +---w input

    &nbs= p;     |  |  +---w name   =           string

    &nbs= p;     |  |  +---w lifetime-hint &nb= sp;  int32

    &nbs= p;     |  +--ro output

    &nbs= p;     |     +--ro name &n= bsp;      string

     &nb= sp;    |     +--ro lifetime&nbs= p;   int32

    &nbs= p;     +---x deactivate-filtering=

    &nbs= p;        +---w input

    &nbs= p;           +---w na= me    string

 

This approach will require <= /span>major changes to the document. This may not be justified give= n that in some cases no lifetime is included at all.

 

* Option 3:

 

This one assumes that servers must maintain= an entry for a minimum period (e.g., 1 week, 1 month). No Lifetime is incl= uded in a request. If no refresh request is seen from the client, the server removes expired entries.

 

This one requires minor changes to the document.  

 

* Option 4:

 

This approach does not associate a lifetime= with filtering/alias entries but maintains an inactivity timer of a given = DOTS client. This option does not allow to clean stale mappings that may be induced by clients that do not remove their state approp= riately.

 

Recommended position:

R= 11;   = ; Proceed with option 3.

 = ;

Any object= ion?

 = ;

Cheers,

Med

 

--_000_787AE7BB302AE849A7480A190F8B93300A0D1FD4OPEXCLILMA3corp_-- From nobody Wed Feb 14 21:18:17 2018 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 62A2912D881 for ; Wed, 14 Feb 2018 21:18:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 FoJ1-u4v4J-V for ; Wed, 14 Feb 2018 21:18:13 -0800 (PST) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 2F41212D86E for ; Wed, 14 Feb 2018 21:18:13 -0800 (PST) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1518671892; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=g DpnUxsGG4ee8Xoy1i+FkUl80E84hS6JZXYePL76eg M=; b=TFWibvcBfTiBMr3lJ1U+iYjWYaSMAzLBBYcJIiW9/bnn McYduN9PgBJr6nDjM/nu85NpE6r+TFenJPVLwh/YFyEGcttk4c 0P4goJ0Y57nbew5e6WqOez7+uN8uKbBBuhv+ue0XjO7UbOtK/l +oJFnkRK0TbCV90b8OmN9daNoG8= Received: from MIVEXAPP1N03.corpzone.internalzone.com (unknown [10.48.48.90]) by MIVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 5799_0259_843df8d0_5124_4e06_aef2_fc2d4499c818; Wed, 14 Feb 2018 23:18:10 -0600 Received: from MIVEXUSR1N03.corpzone.internalzone.com (10.48.48.83) by MIVEXAPP1N03.corpzone.internalzone.com (10.48.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 15 Feb 2018 00:18:10 -0500 Received: from MIVO365EDGE4.corpzone.internalzone.com (10.48.176.87) by MIVEXUSR1N03.corpzone.internalzone.com (10.48.48.83) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Thu, 15 Feb 2018 00:18:10 -0500 Received: from NAM01-SN1-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.1347.2; Thu, 15 Feb 2018 00:18:09 -0500 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1515.namprd16.prod.outlook.com (10.173.212.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.18; Thu, 15 Feb 2018 05:18: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.20.0485.015; Thu, 15 Feb 2018 05:18:09 +0000 From: "Konda, Tirumaleswar Reddy" To: dots Thread-Topic: [core] RFC 8323 on CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets Thread-Index: AQHTpf3Ni9jchEyqkkOfvtXhg0de9aOk7JTQ Date: Thu, 15 Feb 2018 05:18:08 +0000 Message-ID: References: <20180215013518.3E44EB8129C@rfc-editor.org> In-Reply-To: <20180215013518.3E44EB8129C@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action 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; DM5PR16MB1515; 7:EdTEZFY44/thu9UlkuwUBnw24j8rNnpXL0m/eZmYzkJJ7++0wpbgOX2wR6zZ8jEh27DaUFWCj7m/po2vdJXEh7VlD9OZr9THotLJDqTWf4Q00PMjW0OBeqjIQQW7fWXmuBKLbnLO20/FXqBMcNMoIi866aZBU5GN8X0zyaXHSZ9pP82NVbi24kOMpuxF1Pbf3x9cVi3vN3CNN3z9McGzNB7CSBiwD2HYfuEAXfcJ+QRucVSJ6O/ezvyTSS2XRIDd x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: e386db08-cc01-4cc8-2cd9-08d574338078 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM5PR16MB1515; x-ms-traffictypediagnostic: DM5PR16MB1515: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(209352067349851)(192374486261705)(248736688235697)(212694052984031)(194151415913766); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(3231101)(944501161)(3002001)(93006095)(93001095)(10201501046)(6041288)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(20161123564045)(6072148)(201708071742011); SRVR:DM5PR16MB1515; BCL:0; PCL:0; RULEID:; SRVR:DM5PR16MB1515; x-forefront-prvs: 058441C12A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(396003)(39860400002)(39380400002)(346002)(189003)(199004)(32952001)(13464003)(305945005)(74316002)(45080400002)(14454004)(77096007)(186003)(53936002)(478600001)(33656002)(26005)(3280700002)(80792005)(86362001)(72206003)(966005)(9686003)(229853002)(97736004)(6306002)(6436002)(2473003)(3846002)(53546011)(102836004)(6506007)(59450400001)(25786009)(55016002)(7736002)(6116002)(2950100002)(6916009)(2906002)(99286004)(2900100001)(81166006)(8676002)(81156014)(7696005)(66066001)(8936002)(76176011)(105586002)(316002)(106356001)(5660300001)(3660700001)(68736007)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1515; 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) x-microsoft-antispam-message-info: 5F895DM8jcXyccYpmA6JhDcj+K5NazgMiJ+iUe3FJBCPJy4PIo54pLPpOj+c7Iwoo6q7t6YM5MfCbYXBeTcIJQ== 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-Network-Message-Id: e386db08-cc01-4cc8-2cd9-08d574338078 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Feb 2018 05:18:08.9055 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1515 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 <6222> : inlines <6398> : streams <1779020> : uri <2593103> Archived-At: Subject: [Dots] FW: [core] RFC 8323 on CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets 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, 15 Feb 2018 05:18:15 -0000 -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of rfc-editor@rfc-edito= r.org Sent: Thursday, February 15, 2018 7:05 AM To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org Cc: drafts-update-ref@iana.org; core@ietf.org; rfc-editor@rfc-editor.org Subject: [core] RFC 8323 on CoAP (Constrained Application Protocol) over TC= P, TLS, and WebSockets A new Request for Comments is now available in online RFC libraries. =20 RFC 8323 Title: CoAP (Constrained Application Protocol) over=20 TCP, TLS, and WebSockets=20 Author: C. Bormann,=20 S. Lemay, H. Tschofenig, K. Hartke, B. Silverajan, B. Raymor, Ed. Status: Standards Track Stream: IETF Date: February 2018 Mailbox: cabo@tzi.org,=20 slemay@zebra.com,=20 Hannes.Tschofenig@gmx.net, hartke@tzi.org,=20 Bilhanan.Silverajan@tut.fi, brianraymor@hotmail.com Pages: 54 Characters: 110771 Updates: RFC 7641, RFC 7959 I-D Tag: draft-ietf-core-coap-tcp-tls-11.txt URL: https://www.rfc-editor.org/info/rfc8323 DOI: 10.17487/RFC8323 The Constrained Application Protocol (CoAP), although inspired by HTTP, was= designed to use UDP instead of TCP. The message layer of CoAP over UDP in= cludes support for reliable delivery, simple congestion control, and flow c= ontrol. Some environments benefit from the availability of CoAP carried over reliab= le transports such as TCP or Transport Layer Security (TLS). This document outlines the changes required to use CoAP over TCP, TLS, and = WebSockets transports. It also formally updates RFC 7641 for use with thes= e transports and RFC 7959 to enable the use of larger messages over a relia= ble transport. This document is a product of the Constrained RESTful Environments Working = Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protoc= ol for the Internet community, and requests discussion and suggestions for = improvements. Please refer to the current edition of the Official Internet= Protocol Standards (https://www.rfc-editor.org/standards) for the standard= ization state and status of this protocol. Distribution of this memo is un= limited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For dow= nloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author = of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifical= ly noted otherwise on the RFC itself, all RFCs are for unlimited distributi= on. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Thu Feb 15 07:32:11 2018 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 04D9E12DA1D for ; Thu, 15 Feb 2018 07:32:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.329 X-Spam-Level: X-Spam-Status: No, score=-4.329 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 Rw9exGfj8-Hj for ; Thu, 15 Feb 2018 07:32:07 -0800 (PST) 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 7172D12762F for ; Thu, 15 Feb 2018 07:32:07 -0800 (PST) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1518708726; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=wCe2Ockv8QuivesSJvM5qAxCpC/XgXe2wwHQA/ 5jAcA=; b=T4YRavO0GLAAzD4bxuJvgk1KRK+YKG3lH0PrfAnB PmcNGh0rW8MpKayxWzM352NrFforIe7FBYEcO1GXxDW+cTGc3R 8McqUNeX14HdkXemXsCW2awLygVClPIs2lT44zXChMbKqh/l2C cwa81cBW5ryASaxNzpbYVYIjPSab1SM= Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 7965_313c_ceaf5de1_fb9f_4de0_b963_5ba109a1c811; Thu, 15 Feb 2018 09:32:06 -0600 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.1347.2; Thu, 15 Feb 2018 08:31:03 -0700 Received: from DNVEXUSR1N14.corpzone.internalzone.com (10.44.48.87) by DNVEXUSR1N12.corpzone.internalzone.com (10.44.48.85) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 15 Feb 2018 08:31:03 -0700 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXUSR1N14.corpzone.internalzone.com (10.44.48.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Thu, 15 Feb 2018 08:31:03 -0700 Received: from NAM01-BY2-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.1347.2; Thu, 15 Feb 2018 08:30:40 -0700 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB2215.namprd16.prod.outlook.com (52.132.142.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.10; Thu, 15 Feb 2018 15:31:01 +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.20.0485.015; Thu, 15 Feb 2018 15:31:00 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: draft-ietf-dots-data-channel: Filter Direction Thread-Index: AdOlbGwqi1N7Z468TzqkpTeHXPf9AQBBCWQg Date: Thu, 15 Feb 2018 15:31:00 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A0D1F7C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A0D1F7C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [171.61.123.199] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB2215; 7:d3B+l2PsmQyRk2O4yUy+SKCF5oicYL7tf8C1JeyH8V6Mnxrj2R0QoDmv4qdyhocGBuQ78WL7ZJeAN2uZ1BkdcEEK5RtAqKvBMbpRwPm9Dklmb2sntU8q118LdyBFo2JKhmZPSa+zFo7XLOVkOTEE6+3TRCceHxlTvsD2+K+mm5DeuLqmuIad1AOvGL7zkK0SqJQWkg9nG9ExdqeqAbWNnHM55GYbdBe/URjzPBxKUYOR9PMyDnCMHAvljwJgO2OS x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 0135cc06-bbf9-4692-a049-08d574891e21 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:DM5PR16MB2215; x-ms-traffictypediagnostic: DM5PR16MB2215: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(18271650672692)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(3002001)(3231101)(944501161)(10201501046)(93006095)(93001095)(6041288)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123558120)(6072148)(201708071742011); SRVR:DM5PR16MB2215; BCL:0; PCL:0; RULEID:; SRVR:DM5PR16MB2215; x-forefront-prvs: 058441C12A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39380400002)(366004)(39860400002)(346002)(376002)(57704003)(53754006)(199004)(189003)(32952001)(14454004)(66066001)(33656002)(7736002)(25786009)(3660700001)(561944003)(74316002)(99286004)(110136005)(8936002)(81156014)(3846002)(790700001)(97736004)(81166006)(6116002)(478600001)(2906002)(7696005)(80792005)(8676002)(68736007)(72206003)(5660300001)(106356001)(3280700002)(966005)(2501003)(316002)(606006)(2900100001)(236005)(59450400001)(6246003)(77096007)(76176011)(26005)(105586002)(2950100002)(53936002)(6436002)(102836004)(229853002)(19609705001)(6306002)(86362001)(186003)(55016002)(53546011)(6506007)(9686003)(54896002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB2215; 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) x-microsoft-antispam-message-info: G2A1h/2EWwMaWnyWhKaSmOCV8LlsKb+dJF5Yd3rAE/v0RWj5o0Kz6Z8kYndZ2jxlLpiNJ+BufjVdzYusgHncvA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB17882981B7E75DDA932DB15AEAF40DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 0135cc06-bbf9-4692-a049-08d574891e21 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Feb 2018 15:31:00.6561 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB2215 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 <6223> : inlines <6399> : streams <1779061> : uri <2593344> Archived-At: Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction 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, 15 Feb 2018 15:32:10 -0000 --_000_DM5PR16MB17882981B7E75DDA932DB15AEAF40DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The filtering rule for outgoing traffic is required for the "Suppression of= outbound DDoS traffic originating from a consumer broadband access network= " use case discussed in https://tools.ietf.org/html/draft-ietf-dots-use-cas= es-09#section-3.2.1. In this use case, the CPE initially acts as a DOTS cli= ent but after the TCP connection is established, reverses its role and acts= as DOTS server (see https://tools.ietf.org/html/rfc8071). The access netwo= rk can then program the CPE using the DOTS data channel to block the DDoS a= ttack traffic originated from the compromised devices in the local customer network. Cheers, -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Wednesday, February 14, 2018 1:49 PM To: dots@ietf.org Subject: [Dots] draft-ietf-dots-data-channel: Filter Direction Hi all, As agreed during the interim, there are some issues that need fixes in the = data-channel spec. We would like to hear from the WG to know what to record= in the document. Issue description: Do we need to support explicit "direction" in filtering = rules ("in"/"out")? That is, do we allow a DOTS client to create filters fo= r both incoming and outgoing traffic? Below a proposal for discussion: - The current default direction is aligned with the nature of DDoS attac= ks targeted by DOTS: i.e. incoming. The DOTS client domain is assumed to be= the destination. No ambiguity so far with such default behavior. - There is no clear use case for the support of outgoing filtering handl= ing in the context of DOTS. - No text change is required to the draft. Any objection? Cheers, Med --_000_DM5PR16MB17882981B7E75DDA932DB15AEAF40DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The filte= ring rule for outgoing traffic is required for the "Suppression of out= bound DDoS traffic originating from a consumer broadband access network&quo= t; use case discussed in https://tools.ietf.org/html/draft-ietf-dots-use-cases-09#section-3.2.1.= In this use case, the CPE initially acts as a DOTS client but after the TC= P connection is established, reverses its role and acts as DOTS server (see https://tools.ietf.org/html= /rfc8071). The access network can then program the CPE using the DOTS d= ata channel to block the DDoS attack traffic originated from the compromise= d devices in the

local cus= tomer network.

&nbs= p;

Cheers,

-Tiru

 

From:<= /span> Dots [mailto:dots-bou= nces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: Wednesday, February 14, 2018 1:49 PM
To: dots@ietf.org
Subject: [Dots] draft-ietf-dots-data-channel: Filter Direction<= /o:p>

 

Hi all,

 

As agreed during the interim, there are some issues that n= eed fixes in the data-channel spec. We would like to hear from the WG to kn= ow what to record in the document.

 

Issue description: Do we need to support explicit “d= irection” in filtering rules (“in”/“out”)? Th= at is, do we allow a DOTS client to create filters for both incoming and ou= tgoing traffic?

 

Below a proposal for discussion:

–    The current default direc= tion is aligned with the nature of DDoS attacks targeted by DOTS: i.e. inco= ming. The DOTS client domain is assumed to be the destination. No ambiguity so far with such default behavior.

–    There is no clear use cas= e for the support of outgoing filtering handling in the context of DOTS.

–    No text change is require= d to the draft.

 <= /p>

Any objection?

 <= /p>

Cheers,=

Med

 

--_000_DM5PR16MB17882981B7E75DDA932DB15AEAF40DM5PR16MB1788namp_-- From nobody Thu Feb 15 07:43:20 2018 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 6CE1F12DA26 for ; Thu, 15 Feb 2018 07:43:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.009 X-Spam-Level: X-Spam-Status: No, score=-7.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 7ab2oI46lwZJ for ; Thu, 15 Feb 2018 07:43:16 -0800 (PST) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 626BB126BF6 for ; Thu, 15 Feb 2018 07:43:16 -0800 (PST) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1518709388; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=j W4n+oA8Xm7zWRSdE0F3uX6ZbZZ2WPL1y/XoaTeFs3 M=; b=gn3uwS39FphxUXUn85fXpUB2Tno6c3U3BuLyfCxPyzdr atIGAeANmpRa6ldwMZINcYib7SqgdVl4F1R06e7bTCEXVRANva GdaGmkmmpUiyetD0NQp4M8hPQFUw6rQGZsCydTo6WsFid5v1oW Dwip2qODzeKRKOTuoJqFab91PLY= Received: from MIVEXAPP1N01.corpzone.internalzone.com (mivexapp1n01.corpzone.internalzone.com [10.48.48.88]) by MIVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 5799_f2b5_16422a25_5ead_4eba_8add_71d48ab26dd8; Thu, 15 Feb 2018 09:43:08 -0600 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.1347.2; Thu, 15 Feb 2018 10:42:26 -0500 Received: from MIVO365EDGE4.corpzone.internalzone.com (10.48.176.87) by MIVEXUSR1N03.corpzone.internalzone.com (10.48.48.83) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Thu, 15 Feb 2018 10:42:26 -0500 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (10.48.176.242) by edge.mcafee.com (10.48.176.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 15 Feb 2018 10:42:23 -0500 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB2246.namprd16.prod.outlook.com (52.132.142.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.10; Thu, 15 Feb 2018 15:42:24 +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.20.0485.015; Thu, 15 Feb 2018 15:42:23 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: draft-ietf-dots-data-channel: Filter Activation Thread-Index: AdOlbErzDQUpkmr3SvqsVrn/wnlEDABBjMnw Date: Thu, 15 Feb 2018 15:42:23 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A0D1F64@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A0D1F64@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [171.61.123.199] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB2246; 7:Zgs43JGV0pGIw0YhbWwsYKD9i4BloxWBJ3xVN8Cq32+4CWvV1UP1Y5mLpd+A63SeFXlIKoLCJYVdHDt7Cb6z0JPtiBDL61JTzbTxI2PkCHseO1jp22mEmtpC/jkrAk/u3YSsNOECysOLSm+Uo3GQgJ0OGLdab8wLu5y/HQBH+v8ODjdcKb7RvvJJN+AqxqgqHYoAPDNdiSIBZcgHnpwmWYKbt0SJNine9m4+Hb4cue7gGPeEyZv7TswA9Gqp/i/i x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 49f488cf-aec5-4307-e98f-08d5748ab53b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:DM5PR16MB2246; x-ms-traffictypediagnostic: DM5PR16MB2246: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(18271650672692)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(10201501046)(3002001)(3231101)(944501161)(93006095)(93001095)(6041288)(20161123558120)(20161123562045)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:DM5PR16MB2246; BCL:0; PCL:0; RULEID:; SRVR:DM5PR16MB2246; x-forefront-prvs: 058441C12A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(396003)(39380400002)(346002)(39860400002)(53754006)(189003)(199004)(32952001)(102836004)(6436002)(9686003)(53936002)(54896002)(6306002)(74316002)(14454004)(86362001)(105586002)(55016002)(7696005)(6246003)(66066001)(106356001)(3660700001)(72206003)(19609705001)(561944003)(33656002)(25786009)(99286004)(2900100001)(7736002)(53546011)(3280700002)(59450400001)(478600001)(2950100002)(2906002)(80792005)(76176011)(186003)(77096007)(81166006)(81156014)(26005)(8676002)(5660300001)(790700001)(6116002)(3846002)(110136005)(68736007)(8936002)(2501003)(229853002)(6506007)(316002)(97736004)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB2246; 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) x-microsoft-antispam-message-info: 5sp9Cxwl1v31SMwJ9anrhMn5xHbtQwVH/kseJX5Dnv+J56x/sNoYaxQYpZL4rqt2FcOGjYHFZ7n3vPs40V8ymg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1788312C8CB45A9510ED0C1EEAF40DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 49f488cf-aec5-4307-e98f-08d5748ab53b X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Feb 2018 15:42:23.6610 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB2246 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 <6223> : inlines <6399> : streams <1779062> : uri <2593350> Archived-At: Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Activation 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, 15 Feb 2018 15:43:18 -0000 --_000_DM5PR16MB1788312C8CB45A9510ED0C1EEAF40DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with the proposal. In most use cases during peace time, the DOTS cl= ient can enforce the black-list/white-list filtering rules in its domain, s= o the default value of "mitigation-time" for the activation-type. Cheers, -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Wednesday, February 14, 2018 1:48 PM To: dots@ietf.org Subject: [Dots] draft-ietf-dots-data-channel: Filter Activation Hi all, As agreed during the interim, there are some issues that need fixes in the = data-channel spec. We would like to hear from the WG to know what to record= in the document. Issue description: Do we assume that all filtering rules, communicated by D= OTS clients, are activated by default or only when a mitigation is active? Below a proposal for discussion: - We should support both: o Immediate activation is useful in deployment cases where filtering is = used to anticipate some attacks and therefore avoid that access resources a= re abused when an attack become effective. This is typically the case where= DOTS server is deployed by access providers. o The reasoning may not be the same if the DOTS service is on the cloud. - The intended action will be governed by a new attribute called "activa= tion-type" which can be set to "immediate" or "mitigation-time". This param= eter will be supplied by a DOTS client in a filter creation request. - Which default value to use if no "activation-type" is supplied by a cl= ient? Please comment. Cheers, Med --_000_DM5PR16MB1788312C8CB45A9510ED0C1EEAF40DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree with the proposal. In most use cases during = peace time, the DOTS client can enforce the black-list/white-list filtering= rules in its domain, so the def= ault value of “mitigation-time” for the activation-type.

&n= bsp;

Cheers,=

-Tiru

From:<= /span> Dots [mailto:dots-bou= nces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: Wednesday, February 14, 2018 1:48 PM
To: dots@ietf.org
Subject: [Dots] draft-ietf-dots-data-channel: Filter Activation=

 

Hi all,

 

As agreed during the interim, there are some issues that n= eed fixes in the data-channel spec. We would like to hear from the WG to kn= ow what to record in the document.

 

Issue description: Do we assume that all filtering rules, = communicated by DOTS clients, are activated by default or only when a mitig= ation is active?

 

Below a proposal for discussion:

–    We should support both:

o    Immediate activation is u= seful in deployment cases where filtering is used to anticipate some attack= s and therefore avoid that access resources are abused when an attack become effective. This is typically the case where D= OTS server is deployed by access providers.

o    The reasoning may not be = the same if the DOTS service is on the cloud.

–    The intended action will = be governed by a new attribute called “activation-type” which c= an be set to “immediate” or “mitigation-time”. This= parameter will be supplied by a DOTS client in a filter creation request.

–    Which default value to us= e if no “activation-type” is supplied by a client?

 <= /p>

Please comment.

 <= /p>

Cheers,=

Med

--_000_DM5PR16MB1788312C8CB45A9510ED0C1EEAF40DM5PR16MB1788namp_-- From nobody Thu Feb 15 19:47:40 2018 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 AC8FE127735 for ; Thu, 15 Feb 2018 19:47:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.33 X-Spam-Level: X-Spam-Status: No, score=-4.33 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 cMWC1Nlfe0qL for ; Thu, 15 Feb 2018 19:47:36 -0800 (PST) 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 136C21275C5 for ; Thu, 15 Feb 2018 19:47:35 -0800 (PST) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1518752855; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=XQb4Z7x8mFDgEOSP37HwC9gP9qbbd3cHajXqHx yP4Ik=; b=m4ZmI4/YXC+OTjKMfdvvd9nBTOeIA3Y4ECKXp7UM HkvoSnWxdP27IffY4A5giA9/KHazzfqE/ZlWgytHPt0rJ2korl mR8/1lqgf9HVXpztcRKgNCqX1+U+JiDOWp8dFy67Xvs3nSw6Fb fIN5uWXNRp28FvQPoKzqCSn1zWKgLEE= Received: from DNVEXAPP1N04.corpzone.internalzone.com (unknown [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 4b3e_14e1_b919e195_ab28_4fbc_9a48_5ce801f8e612; Thu, 15 Feb 2018 21:47:34 -0600 Received: from DNVEXUSR1N14.corpzone.internalzone.com (10.44.48.87) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 15 Feb 2018 20:47:32 -0700 Received: from DNVEXUSR1N10.corpzone.internalzone.com (10.44.48.83) by DNVEXUSR1N14.corpzone.internalzone.com (10.44.48.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 15 Feb 2018 20:47:31 -0700 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXUSR1N10.corpzone.internalzone.com (10.44.48.83) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Thu, 15 Feb 2018 20:47:31 -0700 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 15 Feb 2018 20:47:06 -0700 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1753.namprd16.prod.outlook.com (10.172.44.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.10; Fri, 16 Feb 2018 03:47:29 +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.20.0485.015; Fri, 16 Feb 2018 03:47:29 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: draft-ietf-dots-data-channel: Lifetime handling Thread-Index: AdOlbQ72FAzJz3VcRLyAIRvKZ6oNtwBa6DZw Date: Fri, 16 Feb 2018 03:47:29 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A0D1FD4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A0D1FD4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [185.221.69.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1753; 7:CeHLvAqMPpp0jMNdIVNNM183Coj2rXbW0EBoOacTgE2Uf0ZneDyKEEE4z608z6dxVE/a7XwxKbfWdvKBkCIGoeKuGZu72K9xYTnwQ2TcBKK1ptaaM/bXmb4HUi0r856QD52s9FokSGlKp1J+xUUUKdrfzAU5licbP62oLfPPdvlI3/N3U6QmE0eh0DyXO2QaYBIOnHuEgAHni5Ls0xlTIfvcHJFvzRkvDf0bbl7YKcle7c2xAa8KSZUsMLGHNXD/ x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: ab481b30-aa1d-4fec-501c-08d574f000eb x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:DM5PR16MB1753; x-ms-traffictypediagnostic: DM5PR16MB1753: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(18271650672692)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(3231101)(2400082)(944501161)(10201501046)(3002001)(93006095)(93001095)(6041288)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123562045)(6072148)(201708071742011); SRVR:DM5PR16MB1753; BCL:0; PCL:0; RULEID:; SRVR:DM5PR16MB1753; x-forefront-prvs: 0585417D7B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39860400002)(39380400002)(366004)(346002)(396003)(32952001)(199004)(53754006)(189003)(106356001)(8936002)(2900100001)(110136005)(25786009)(6246003)(6306002)(6436002)(3846002)(9686003)(74316002)(6116002)(54896002)(19609705001)(14454004)(3660700001)(3280700002)(80792005)(478600001)(55016002)(53936002)(66066001)(2501003)(33656002)(26005)(7696005)(790700001)(316002)(2950100002)(105586002)(6506007)(53546011)(72206003)(99286004)(186003)(81166006)(76176011)(7736002)(229853002)(8676002)(68736007)(59450400001)(5660300001)(97736004)(81156014)(2906002)(77096007)(102836004)(86362001)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1753; 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) x-microsoft-antispam-message-info: phpI31Fli8aweTB+7jO2TPnCVqJASOoIxyyuwx9BbCiNAp+1HdrH3CIksUxp45zdBysj6Y1R7gsHjCELQBjheA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB178837CC96D2C7F1CEB0895EEACB0DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ab481b30-aa1d-4fec-501c-08d574f000eb X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2018 03:47:29.7781 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1753 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 <6223> : inlines <6403> : streams <1779110> : uri <2593641> Archived-At: Subject: Re: [Dots] draft-ietf-dots-data-channel: Lifetime handling 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, 16 Feb 2018 03:47:39 -0000 --_000_DM5PR16MB178837CC96D2C7F1CEB0895EEACB0DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Option 3 looks good to me. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Wednesday, February 14, 2018 1:53 PM To: dots@ietf.org Subject: [Dots] draft-ietf-dots-data-channel: Lifetime handling Hi all, As agreed during the interim, there are some issues that need fixes in the = data-channel spec. We would like to hear from the WG to know what to record= in the document. Issue description: It was agreed to associate a lifetime with entries insta= ntiated by a DOTS client (-12). The current behavior in the spec is as foll= ows: - A lifetime hint is included in the resource creation request by the cl= ient. - The server may honor the suggested lifetime or assign a distinct value= as per its local policies. When a distinct value is used by the server, the issue is how to notify the= client given that RFC8040 says: "If the POST method succeeds, a "201 Created" status-line is returned and t= here is no response message-body." * Option 1: A work around would be to relax the above constraint at the server side to = include a message-body even for "201 Created", but this is not a clean desi= gn as it requires changes to the base RESTCONF spec. * Option 2: Change completely the data module so that we can make use of operations (ac= tion/rpc). For example, these operations can be defined: +---x activate-filtering | +---w input | | +---w name string | | +---w lifetime-hint int32 | +--ro output | +--ro name string | +--ro lifetime int32 +---x deactivate-filtering +---w input +---w name string This approach will require major changes to the document. This may not be j= ustified given that in some cases no lifetime is included at all. * Option 3: This one assumes that servers must maintain an entry for a minimum period (= e.g., 1 week, 1 month). No Lifetime is included in a request. If no refresh= request is seen from the client, the server removes expired entries. This one requires minor changes to the document. * Option 4: This approach does not associate a lifetime with filtering/alias entries bu= t maintains an inactivity timer of a given DOTS client. This option does no= t allow to clean stale mappings that may be induced by clients that do not = remove their state appropriately. Recommended position: - Proceed with option 3. Any objection? Cheers, Med --_000_DM5PR16MB178837CC96D2C7F1CEB0895EEACB0DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Option 3 = looks good to me.

&nbs= p;

-Tiru

 

From:<= /span> Dots [mailto:dots-bou= nces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: Wednesday, February 14, 2018 1:53 PM
To: dots@ietf.org
Subject: [Dots] draft-ietf-dots-data-channel: Lifetime handling=

 

Hi all,

 

As agreed during the interim, there are some issues that n= eed fixes in the data-channel spec. We would like to hear from the WG to kn= ow what to record in the document.

 

Issue description: It was agreed to associate a lifetime w= ith entries instantiated by a DOTS client (-12). The current behavior in th= e spec is as follows:

-    A lifetime hint is includ= ed in the resource creation request by the client.

-    The server may honor the = suggested lifetime or assign a distinct value as per its local policies. &n= bsp; 

 

When a distinct value is used by the server, the issue is = how to notify the client given that RFC8040 says:

 

"If the POST method succeeds, a "201 Created&quo= t; status-line is returned and there is no response message-body."

 

* Option 1:

 

A work around would be to relax the above constraint at th= e server side to include a message-body even for “201 Created”, but this is not a clean desi= gn as it requires changes to the base RESTCONF spec.

 

* Option 2:

 

Change completely the data module so that we can make use = of operations (action/rpc). For example, these operations can be defined:

 

        &= nbsp; +---x activate-filtering

        &= nbsp; |  +---w input

        &= nbsp; |  |  +---w name      &nb= sp;      string

        &= nbsp; |  |  +---w lifetime-hint    int32<= /o:p>

        &= nbsp; |  +--ro output

        &= nbsp; |     +--ro name     = ;   string

         =  |     +--ro lifetime    int32<= o:p>

        &= nbsp; +---x deactivate-filtering

        &= nbsp;    +---w input

        &= nbsp;       +---w name    = string

 

This approach will require major changes to the document. This may not be justified given that in some cases = no lifetime is included at all.

 

* Option 3:

 

This one assumes that servers must maintain an entry for a= minimum period (e.g., 1 week, 1 month). No Lifetime is included in a reque= st. If no refresh request is seen from the client, the server removes expired entries.

 

This one requires minor changes to the document.  

 

* Option 4:

 

This approach does not associate a lifetime with filtering= /alias entries but maintains an inactivity timer of a given DOTS client. Th= is option does not allow to clean stale mappings that may be induced by clients that do not remove their state approp= riately.

 

Recommended position:

–    Proceed with option 3.

 <= /p>

Any objection?

 <= /p>

Cheers,=

Med

 

--_000_DM5PR16MB178837CC96D2C7F1CEB0895EEACB0DM5PR16MB1788namp_-- From nobody Thu Feb 15 19:49:49 2018 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 A86F312AF6E for ; Thu, 15 Feb 2018 19:49:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.33 X-Spam-Level: X-Spam-Status: No, score=-4.33 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 2ZpzG55dPpVa for ; Thu, 15 Feb 2018 19:49:46 -0800 (PST) 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 14A051275C5 for ; Thu, 15 Feb 2018 19:49:45 -0800 (PST) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1518752978; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=H AG2HNvRoBZ4Zy7VLhUZSwORj9Dmt2+ZMtc3//pOox Y=; b=ggzmI9RiohgxvNSRV/uNW40Y3ZVGn1q0nef4XtPHQQ0W DicVNRCOcRwRWQ8BjFdqis3E+hBnkrULvbh0WMtrlVOYJDCXX7 szsjD3rWmCCdhH0USxgq9jrqrQNn0rH9UItMX0PkiILL2Er1TF +n82bEuVWYgtJ+1NSrI6Bvee4ik= Received: from DNVEXAPP1N04.corpzone.internalzone.com (unknown [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 4b3e_1706_35303bbe_e38b_41a5_9012_ca8921e30bdc; Thu, 15 Feb 2018 21:49:36 -0600 Received: from DNVEXUSR1N08.corpzone.internalzone.com (10.44.48.81) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 15 Feb 2018 20:49:33 -0700 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXUSR1N08.corpzone.internalzone.com (10.44.48.81) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Thu, 15 Feb 2018 20:49:33 -0700 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (10.44.176.240) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 15 Feb 2018 20:49:33 -0700 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB2247.namprd16.prod.outlook.com (52.132.142.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.18; Fri, 16 Feb 2018 03:49: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.20.0485.015; Fri, 16 Feb 2018 03:49:31 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: draft-ietf-dots-data-channel: Global or Per-client Filters Thread-Index: AdOlbK/SFiGBcdnZRPCkh1qUQojTYgBbENUg Date: Fri, 16 Feb 2018 03:49:31 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A0D1FAE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A0D1FAE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [185.221.69.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB2247; 7:HIiGkcWg3e4fQcYZE/oWs91x3fJDM+aaDYO53OikSAP979kEsV3A/qsIvhObXX8IeCn/Zv4GWf6OnVyRFiVliNKBO3a5mOJq6XbG8Y5YbI4fS86bgPyEH4fqahcUsMBS43jfeGTiuhMlvXuM3zNAaqU/bIoDXZK+otFF4ZNidVQr7Y7raPe5EEwr26FGeKqJNBImqD74/yG9wsw2gPPUM+PBfyka+VM6AX3nSy4uJk+qJkaveq4E6QVwZCA6hhdF x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 3801e40c-59f1-49e2-a179-08d574f049ad x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM5PR16MB2247; x-ms-traffictypediagnostic: DM5PR16MB2247: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(18271650672692)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231101)(944501161)(6041288)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(20161123564045)(6072148)(201708071742011); SRVR:DM5PR16MB2247; BCL:0; PCL:0; RULEID:; SRVR:DM5PR16MB2247; x-forefront-prvs: 0585417D7B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(39860400002)(366004)(376002)(346002)(396003)(39380400002)(53754006)(199004)(189003)(32952001)(14454004)(66066001)(33656002)(7736002)(25786009)(3660700001)(561944003)(74316002)(8936002)(110136005)(3846002)(81156014)(6116002)(81166006)(97736004)(790700001)(478600001)(2906002)(7696005)(99286004)(106356001)(68736007)(72206003)(5660300001)(3280700002)(316002)(2501003)(80792005)(2900100001)(6246003)(8676002)(77096007)(26005)(76176011)(105586002)(6306002)(53936002)(2950100002)(6436002)(102836004)(229853002)(19609705001)(86362001)(186003)(55016002)(6506007)(53546011)(9686003)(54896002)(85282002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB2247; 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) x-microsoft-antispam-message-info: cTEj/9Eudz3UamNK+lZv72Lq4z/etYB9f75Uo0Jf0xECpK8AyZQvWzQ9I3Oub7hc+Ll9QqJlgpJrLBV6BbWzog== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB178875138C4D4F237A94DE35EACB0DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 3801e40c-59f1-49e2-a179-08d574f049ad X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2018 03:49:31.8475 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB2247 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 <6223> : inlines <6403> : streams <1779110> : uri <2593643> Archived-At: Subject: Re: [Dots] draft-ietf-dots-data-channel: Global or Per-client Filters 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, 16 Feb 2018 03:49:48 -0000 --_000_DM5PR16MB178875138C4D4F237A94DE35EACB0DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Looks good, no objections from my side. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Wednesday, February 14, 2018 1:51 PM To: dots@ietf.org Subject: [Dots] draft-ietf-dots-data-channel: Global or Per-client Filters Hi all, As agreed during the interim, there are some issues that need fixes in the = data-channel spec. We would like to hear from the WG to know what to record= in the document. Issue description: If filters are activated only at the mitigation time, do= we consider filters created by a client are globally available to all clie= nts of the same domain or not? Below a proposal for discussion: - Filters that are activated only during mitigation time are on a per-cl= ient basis. Any objection? Cheers, Med --_000_DM5PR16MB178875138C4D4F237A94DE35EACB0DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Looks goo= d, no objections from my side.

&nbs= p;

-Tiru

 

From:<= /span> Dots [mailto:dots-bou= nces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: Wednesday, February 14, 2018 1:51 PM
To: dots@ietf.org
Subject: [Dots] draft-ietf-dots-data-channel: Global or Per-client F= ilters

 

Hi all,

 

As agreed during the interim, there are some issues that n= eed fixes in the data-channel spec. We would like to hear from the WG to kn= ow what to record in the document.

 

Issue description: If filters are activated only at the mi= tigation time, do we consider filters created by a client are globally avai= lable to all clients of the same domain or not?

 

Below a proposal for discussion:

–    Filters that are activate= d only during mitigation time are on a per-client basis.

 <= /p>

Any objection?

 <= /p>

Cheers,=

Med

--_000_DM5PR16MB178875138C4D4F237A94DE35EACB0DM5PR16MB1788namp_-- From nobody Thu Feb 15 23:00:03 2018 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 2B3C5124217 for ; Thu, 15 Feb 2018 23:00:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 i70KeENxKJ0J for ; Thu, 15 Feb 2018 22:59:59 -0800 (PST) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 5EF5912025C for ; Thu, 15 Feb 2018 22:59:59 -0800 (PST) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1518764398; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=W XoaWzTNBf+5t32zEhItvhnfc1M68/pha/C78h/rbA 0=; b=eh3byBky83BToGHcBh4GjlAvN49A42otGClwKi5ctY85 k0VZvMFnTmApto5ZXn2dhSVBhQxyNk69RhnO8uup4ucLuMUa+a fp9j/ixiMIpxl5hNo6YoU7JD0Z+PTyNFgQllNb7Endl8MHHIn0 u0m5/324nW10ZIY4qeK5fSRmt4E= Received: from MIVEXAPP1N02.corpzone.internalzone.com (unknown [10.48.48.89]) by MIVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 4a8a_2264_72dfba32_777f_4180_b156_947d2e6b4b91; Fri, 16 Feb 2018 00:59:57 -0600 Received: from MIVEXUSR1N01.corpzone.internalzone.com (10.48.48.81) by MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 16 Feb 2018 01:59:57 -0500 Received: from MIVEXUSR1N03.corpzone.internalzone.com (10.48.48.83) by MIVEXUSR1N01.corpzone.internalzone.com (10.48.48.81) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 16 Feb 2018 01:59:55 -0500 Received: from MIVO365EDGE3.corpzone.internalzone.com (10.48.176.86) by MIVEXUSR1N03.corpzone.internalzone.com (10.48.48.83) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Fri, 16 Feb 2018 01:59:56 -0500 Received: from NAM02-BL2-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.1347.2; Fri, 16 Feb 2018 01:59:54 -0500 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1771.namprd16.prod.outlook.com (10.172.44.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.10; Fri, 16 Feb 2018 06:59:52 +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.20.0485.015; Fri, 16 Feb 2018 06:59:52 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: draft-ietf-dots-data-channel: Filtering Fields Thread-Index: AdOlbICGgF2MxoHnQied7J+cvW2QAABhQcig Date: Fri, 16 Feb 2018 06:59:52 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A0D1F93@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A0D1F93@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action 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; DM5PR16MB1771; 7:PpOnX03sgy32dzPOMYJhOOGDyep4EDF0C1Q7IKI6hnK6RYjLZVqatENxduIrYUijOQwQV04/0Jbi5i8hDmREcdDkKhpPkbdQHqn4Z2XX5OBZFFEATXVM1O7pVLyJ4qCOeJm/OkByOgnp7rqx/0sCf5UltKFkHvwDv0hOIBYzQ9kDsQvT62jtYssPeP3M+gPgvH2VuxejYe0QtVI4I4ZPoo2ExuNoMsCd62OQOvzJKmQRt7rGejNHUmKx1x0XBxYY x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: c61e8e0a-6745-4db7-0dff-08d5750ae0a8 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:DM5PR16MB1771; x-ms-traffictypediagnostic: DM5PR16MB1771: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(18271650672692)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(3231101)(2400082)(944501161)(10201501046)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123564045)(20161123558120)(6072148)(201708071742011); SRVR:DM5PR16MB1771; BCL:0; PCL:0; RULEID:; SRVR:DM5PR16MB1771; x-forefront-prvs: 0585417D7B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(346002)(376002)(39380400002)(39860400002)(396003)(32952001)(57704003)(53754006)(189003)(199004)(186003)(99286004)(25786009)(86362001)(77096007)(3660700001)(2906002)(6246003)(26005)(106356001)(76176011)(53546011)(2900100001)(3846002)(97736004)(7696005)(80792005)(102836004)(6116002)(316002)(2501003)(790700001)(14454004)(6506007)(105586002)(81166006)(2950100002)(55016002)(53936002)(8676002)(110136005)(74316002)(7736002)(6306002)(66066001)(478600001)(19609705001)(68736007)(33656002)(72206003)(3280700002)(8936002)(81156014)(5660300001)(9686003)(6436002)(54896002)(229853002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1771; 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) x-microsoft-antispam-message-info: SNkIcbGb/cRvA8cLnKcHucD9BV/R7+rYtuYH5G16B0zDfp6TBTxPP6R86SyALA08jDJhx6YwHiH0l4n/2tHIKw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB178887DA8478B5BCDBECB5A0EACB0DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c61e8e0a-6745-4db7-0dff-08d5750ae0a8 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2018 06:59:52.1400 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1771 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 <6223> : inlines <6404> : streams <1779123> : uri <2593720> Archived-At: Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields 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, 16 Feb 2018 07:00:01 -0000 --_000_DM5PR16MB178887DA8478B5BCDBECB5A0EACB0DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Wednesday, February 14, 2018 1:49 PM To: dots@ietf.org Subject: [Dots] draft-ietf-dots-data-channel: Filtering Fields Hi all, As agreed during the interim, there are some issues that need fixes in the = data-channel spec. We would like to hear from the WG to know what to record= in the document. Issue description: Should we support all of the match fields defined by "ie= tf-packet-fields" or do we need to define a minimum supported set? [TR] I don't see the need to support all the match fields, define a minimum= supported set (don't see the use for acl-eth-header-fields for DOTS use ca= ses). Would it be useful for a client to retrieve the list of match criteria supp= orted by a DOTS server? [TR] The YANG model supported by the DOTS server can retrieved by the DOTS = client using RESTCONF to determine the match criteria supported by the serv= er. -Tiru Please comment. Cheers, Med --_000_DM5PR16MB178887DA8478B5BCDBECB5A0EACB0DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From:<= /span> Dots [mailto:dots-bou= nces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: Wednesday, February 14, 2018 1:49 PM
To: dots@ietf.org
Subject: [Dots] draft-ietf-dots-data-channel: Filtering Fields<= /o:p>

 

Hi all,

 

As agreed during the interim, there are some issues that n= eed fixes in the data-channel spec. We would like to hear from the WG to kn= ow what to record in the document.

 

Issue description: Should we support all of the match fiel= ds defined by “ietf-packet-fields” or do we need to define a mi= nimum supported set?

 

[TR] I don’t see the need to support all the m= atch fields, define a minimum supported set (don’t see the use for ac= l-eth-header-fields for DOTS use cases).  

 

Would it be useful for a client to retrieve the list of ma= tch criteria supported by a DOTS server?

 

[TR] The YANG model supported by the DOTS server can= retrieved by the DOTS client using RESTCONF to determine the match criteri= a supported by the server.

 

-Tiru

 

Please comment.

 <= /p>

Cheers,=

Med

--_000_DM5PR16MB178887DA8478B5BCDBECB5A0EACB0DM5PR16MB1788namp_-- From nobody Thu Feb 15 23:53:46 2018 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 49B71120721 for ; Thu, 15 Feb 2018 23:53:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 D0ldNfLluAGj for ; Thu, 15 Feb 2018 23:53:43 -0800 (PST) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD22B1200E5 for ; Thu, 15 Feb 2018 23:53:42 -0800 (PST) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 114ED41097; Fri, 16 Feb 2018 08:53:41 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.18]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id E749F1A0060; Fri, 16 Feb 2018 08:53:40 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([fe80::cba:56d0:a732:ef5a%19]) with mapi id 14.03.0382.000; Fri, 16 Feb 2018 08:53:40 +0100 From: To: "Konda, Tirumaleswar Reddy" , "dots@ietf.org" Thread-Topic: draft-ietf-dots-data-channel: Filter Direction Thread-Index: AdOlbGwqi1N7Z468TzqkpTeHXPf9AQBBCWQgACITfVA= Date: Fri, 16 Feb 2018 07:53:40 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0D327F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300A0D1F7C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A0D327FOPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction 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, 16 Feb 2018 07:53:45 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A0D327FOPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Tiru, There will be an ambiguity in interpreting filters if and only if the same = DOTS agents have to manipulate filters in both directions. As you rightfully mentioned, the bb use case assumes the following: In order to achieve this capability, the telemetry analysis system utilized by the broadband access provider must have DOTS client functionality, and the end-customer CPE devices must have DOTS server functionality. Which means that there is no ambiguity in that case with the current defaul= t direction: "the destination is the DOTS client domain". No matter how roles were negotiated, but as far as each an agent acts as a = client and its peer as a server, things are clear. Of course we can always define an optional parameter for this, but it is pr= eferable to have a case for it. Cheers, Med De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] Envoy=E9 : jeudi 15 f=E9vrier 2018 16:31 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: draft-ietf-dots-data-channel: Filter Direction The filtering rule for outgoing traffic is required for the "Suppression of= outbound DDoS traffic originating from a consumer broadband access network= " use case discussed in https://tools.ietf.org/html/draft-ietf-dots-use-cas= es-09#section-3.2.1. In this use case, the CPE initially acts as a DOTS cli= ent but after the TCP connection is established, reverses its role and acts= as DOTS server (see https://tools.ietf.org/html/rfc8071). The access netwo= rk can then program the CPE using the DOTS data channel to block the DDoS a= ttack traffic originated from the compromised devices in the local customer network. Cheers, -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Wednesday, February 14, 2018 1:49 PM To: dots@ietf.org Subject: [Dots] draft-ietf-dots-data-channel: Filter Direction Hi all, As agreed during the interim, there are some issues that need fixes in the = data-channel spec. We would like to hear from the WG to know what to record= in the document. Issue description: Do we need to support explicit "direction" in filtering = rules ("in"/"out")? That is, do we allow a DOTS client to create filters fo= r both incoming and outgoing traffic? Below a proposal for discussion: - The current default direction is aligned with the nature of DDoS attac= ks targeted by DOTS: i.e. incoming. The DOTS client domain is assumed to be= the destination. No ambiguity so far with such default behavior. - There is no clear use case for the support of outgoing filtering handl= ing in the context of DOTS. - No text change is required to the draft. Any objection? Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300A0D327FOPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

There will be an ambiguity in i= nterpreting filters if and only if the same DOTS agents have to manipulate = filters in both directions.

 

As you rightfully mentioned, th= e bb use case assumes the following:

 

   In ord= er to achieve this capability, the telemetry analysis system

   utiliz= ed by the broadband access provider must have DOTS client=

   functi= onality, and the end-customer CPE devices must have DOTS server<= /span>

   functionality.

 

Which means that there is no am= biguity in that case with the current default direction: “the destina= tion is the DOTS client domain”.

 

No matter how roles were ne=
gotiated, but as far as each an agent acts as a client and its peer as a se=
rver, things are clear. 
 

Of course we can always def=
ine an optional parameter for this, but it is preferable to have a case for=
 it.  


 

Cheers,

Med


 








De : Konda, Tirumaleswar Reddy [mail=
to:TirumaleswarReddy_Konda@McAfee.com]


Envoy=E9 : jeudi 15 f=E9vrier 2018 16:31

=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org

Objet : RE: draft-ietf-dots-data-channel: Filter Direction=







 


The filtering rule for outgoing traffic is required for the "Sup=
pression of outbound DDoS traffic originating from a consumer broadband acc=
ess network" use case discussed in

https://tools.ietf.org/html/draft-ietf-dots-use-cases-09#section-3.2.1.=
 In this use case, the CPE initially acts as a DOTS client but after the TC=
P connection is established, reverses its role and acts as DOTS server (see
https://tools.ietf.org/html=
/rfc8071). The access network can then program the CPE using the DOTS d=
ata channel to block the DDoS attack traffic originated from the compromise=
d devices in the



local customer network.



 


Cheers,


-Tiru


 








From: Dots [mailto:dots-bounces=
@ietf.org]
On Behalf Of mohamed=
.boucadair@orange.com

Sent: Wednesday, February 14, 2018 1:49 PM

To: dots@ietf.org

Subject: [Dots] draft-ietf-dots-data-channel: Filter Direction<=
/o:p>






 


Hi all,



 


As agreed during the interim, there are som=
e issues that need fixes in the data-channel spec. We would like to hear fr=
om the WG to know what to record in the document.



 


Issue description: Do we need to support ex=
plicit “direction” in filtering rules (“in”/“=
out”)? That is, do we allow a DOTS client to create filters for both =
incoming
 and outgoing traffic? 


 


Below a proposal for discussion:=



–=
;   
The current default direction is aligned with the nature of=
 DDoS attacks targeted by DOTS: i.e. incoming. The DOTS client domain is as=
sumed to be the destination. No ambiguity so far
 with such default behavior. 


–=
;   
There is no clear use case for the support of outgoing filt=
ering handling in the context of DOTS.


–=
;   
No text change is required to the draft.<=
/p>

 =
;


Any object=
ion?



 =
;


Cheers,


Med



 
--_000_787AE7BB302AE849A7480A190F8B93300A0D327FOPEXCLILMA3corp_-- From nobody Fri Feb 16 00:14:48 2018 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 97D831242F7 for ; Fri, 16 Feb 2018 00:14:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 x0bT0Q6zeQyt for ; Fri, 16 Feb 2018 00:14:44 -0800 (PST) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B3501205F0 for ; Fri, 16 Feb 2018 00:14:44 -0800 (PST) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 8796B180BED; Fri, 16 Feb 2018 09:14:42 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.75]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 664EA1A0077; Fri, 16 Feb 2018 09:14:42 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe%18]) with mapi id 14.03.0382.000; Fri, 16 Feb 2018 09:14:42 +0100 From: To: "Konda, Tirumaleswar Reddy" , "dots@ietf.org" Thread-Topic: draft-ietf-dots-data-channel: Filtering Fields Thread-Index: AdOlbICGgF2MxoHnQied7J+cvW2QAABhQcigAAKnFWA= Date: Fri, 16 Feb 2018 08:14:41 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0D32AE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300A0D1F93@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A0D32AEOPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields 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, 16 Feb 2018 08:14:46 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A0D32AEOPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 16 f=E9vrier 2018 08:00 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Wednesday, February 14, 2018 1:49 PM To: dots@ietf.org Subject: [Dots] draft-ietf-dots-data-channel: Filtering Fields Hi all, As agreed during the interim, there are some issues that need fixes in the = data-channel spec. We would like to hear from the WG to know what to record= in the document. Issue description: Should we support all of the match fields defined by "ie= tf-packet-fields" or do we need to define a minimum supported set? [TR] I don't see the need to support all the match fields, define a minimum= supported set (don't see the use for acl-eth-header-fields for DOTS use ca= ses). [Med] Agree that acl-eth-header-fields aren't required. The text is already= clear about this: DOTS implementations MUST support the following matching criteria: match based on the IP header (IPv4 and IPv6), match based on the transport header (TCP, UDP, and ICMP), and any combination thereof. The question is whether we need to go further and mandate (or not) the supp= ort of matching based on specific fields: dscp, ecn, ttl,... flow-label, ..= . tcp sequence-number, tcp flags, ... Would it be useful for a client to retrieve the list of match criteria supp= orted by a DOTS server? [TR] The YANG model supported by the DOTS server can retrieved by the DOTS = client using RESTCONF to determine the match criteria supported by the serv= er. [Med] I'm afraid this is not the same functionality. If we need to allow a = server to return its supported match criteria, this should be allowed by th= e module. For example, the module may include the following (example): +--ro capabilities | +--ro match-header* | | identityref | +--ro transport-protocols* [protocol-id] | | +--ro protocol-id uint8 | | +--ro protocol-name? string | +--ro dscp-support? boolean | +--ro ecn-support? boolean | +--ro length-support? boolean | +--ro ttl-support? boolean | +--ro protocol-support? boolean The client can ask the server to return its supported match criteria. The s= erver will indicate the exact set of fields it supports. I'm not expressing a preference to have this in the model, but I'm clarifyi= ng how it would look like. -Tiru Please comment. Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300A0D32AEOPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.= org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : vendredi 16 f=E9vrier 2018 08:00
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fiel= ds

 

From: Dots [mailto:dots-bounces= @ietf.org] On Behalf Of mohamed= .boucadair@orange.com
Sent: Wednesday, February 14, 2018 1:49 PM
To: dots@ietf.org
Subject: [Dots] draft-ietf-dots-data-channel: Filtering Fields<= /o:p>

 

Hi all,

 

As agreed during the interim, there are som= e issues that need fixes in the data-channel spec. We would like to hear fr= om the WG to know what to record in the document.

 

Issue description: Should we support all of= the match fields defined by “ietf-packet-fields” or do we need= to define a minimum supported set?

 

[TR] I don’t see the need= to support all the match fields, define a minimum supported set (don’= ;t see the use for acl-eth-header-fields for DOTS use cases).  

[Med] Agree that acl-eth-header= -fields aren’t required. The text is already clear about this:

 

DOTS implementation= s MUST support the following

   matchi= ng criteria: match based on the IP header (IPv4 and IPv6),

   match = based on the transport header (TCP, UDP, and ICMP), and any

   combination thereof.

 

The question is whether we =
need to go further and mandate (or not) the support of matching based on sp=
ecific fields: dscp, ecn, ttl,… flow-labe=
l, … tcp sequence-number, tcp flags, …  

 

Would it be useful for a client to retrieve= the list of match criteria supported by a DOTS server?

 

[TR] The YANG model supported b= y the DOTS server can retrieved by the DOTS client using RESTCONF to determ= ine the match criteria supported by the server.

[Med] I’m afraid this is = not the same functionality. If we need to allow a server to return its supp= orted match criteria, this should be allowed by the module. For example, the module may include the following (example):

 

        &=
nbsp;       +--ro capabilities=

        &=
nbsp;       |  +--ro match-header*
        &=
nbsp;       |  |    =
   identityref
        &=
nbsp;       |  +--ro transport-proto=
cols* [protocol-id]
        &=
nbsp;       |  |  +--ro protoco=
l-id      uint8
        &=
nbsp;       |  |  +--ro protoco=
l-name?   string
        &=
nbsp;       |  +--ro dscp-support? &=
nbsp;     boolean
        &=
nbsp;       |  +--ro ecn-support? &n=
bsp;      boolean
        &=
nbsp;       |  +--ro length-support?=
     boolean
        &=
nbsp;       |  +--ro ttl-support? &n=
bsp;      boolean
        &=
nbsp;       |  +--ro protocol-suppor=
t?   boolean
 
The client can ask the server to return its supported match criteria. The =
server will indicate the exact set of fields it supports. 
 

I’m not expressing a =
preference to have this in the model, but I’m clarifying how it would=
 look like. 


 


-Tiru


 


Please com=
ment.



 =
;


Cheers,


Med=
<=
/o:p>
--_000_787AE7BB302AE849A7480A190F8B93300A0D32AEOPEXCLILMA3corp_-- From nobody Fri Feb 16 00:27:51 2018 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 F09F4120724 for ; Fri, 16 Feb 2018 00:27:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 kWvhuc6y1Df9 for ; Fri, 16 Feb 2018 00:27:47 -0800 (PST) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 7F6511205F0 for ; Fri, 16 Feb 2018 00:27:47 -0800 (PST) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1518769666; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=aBdRE6wmlZZsAE13zLjEY+TO+t2nscEOWYPy4i vNJFI=; b=W3YqRoLhLO0f7RTDhGPClQxpaFBEmDBCHvLoFowG wg2ZlD3mOdALGl9P9OnyK5n0PCHo+LFfpiAP3GhYf6PfeOUCGH 1l+1uYS3qzSPtaG9gemAJ4n94j7rMfB2N+ExJsdRIu9HFWDJ5v WjmUzpimAuAWRmF+sC/q8Ock/jhFsLg= Received: from MIVEXAPP1N01.corpzone.internalzone.com (unknown [10.48.48.88]) by MIVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 4a8a_456e_8b491989_1920_417e_bf64_cb89977767d7; Fri, 16 Feb 2018 02:27:46 -0600 Received: from MIVEXUSR1N04.corpzone.internalzone.com (10.48.48.84) by MIVEXAPP1N01.corpzone.internalzone.com (10.48.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 16 Feb 2018 03:27:42 -0500 Received: from MIVEXUSR1N06.corpzone.internalzone.com (10.48.48.86) by MIVEXUSR1N04.corpzone.internalzone.com (10.48.48.84) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 16 Feb 2018 03:27:41 -0500 Received: from MIVO365EDGE3.corpzone.internalzone.com (10.48.176.86) by MIVEXUSR1N06.corpzone.internalzone.com (10.48.48.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Fri, 16 Feb 2018 03:27:41 -0500 Received: from NAM02-CY1-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.1347.2; Fri, 16 Feb 2018 03:27:40 -0500 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1610.namprd16.prod.outlook.com (10.173.212.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.18; Fri, 16 Feb 2018 08:27:39 +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.20.0485.015; Fri, 16 Feb 2018 08:27:39 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: draft-ietf-dots-data-channel: Filter Direction Thread-Index: AdOlbGwqi1N7Z468TzqkpTeHXPf9AQBBCWQgACITfVAAAZZfcA== Date: Fri, 16 Feb 2018 08:27:39 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A0D1F7C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0D327F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A0D327F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action 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; DM5PR16MB1610; 7:mpcPd6UhKQA6IexUNWtRECZEtRrePSYROiCKH2UjRfVQoyNnVjc83jyff82r6+stPOob2+5fjOk3xkmXRkAOLSqP89VUpIZAFeirqY9IEwako2FZpNRA2EP19MSED4QMwBuiuGYBs9W3Lp1uhv6pfHQ1w0WKctz+bVF1ozwNhr3t6BvZLtAYCSH3Y+uLDpRz4TOPFy+wH8B+wpcuuXO1dPgHn+VhvhglSQCGkBnR8G4ywRhgmz3GxoQzkH/KHAd3 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 6570276e-5739-4da2-29e3-08d575172432 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM5PR16MB1610; x-ms-traffictypediagnostic: DM5PR16MB1610: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(18271650672692)(21748063052155)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(3231101)(944501161)(3002001)(93006095)(93001095)(10201501046)(6041288)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(6072148)(201708071742011); SRVR:DM5PR16MB1610; BCL:0; PCL:0; RULEID:; SRVR:DM5PR16MB1610; x-forefront-prvs: 0585417D7B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39380400002)(39860400002)(376002)(366004)(346002)(189003)(199004)(53754006)(32952001)(57704003)(80792005)(105586002)(2900100001)(236005)(2906002)(86362001)(7736002)(5660300001)(186003)(77096007)(68736007)(3660700001)(3280700002)(6436002)(6246003)(66066001)(33656002)(74316002)(53936002)(8676002)(55016002)(26005)(2950100002)(54896002)(561944003)(81156014)(81166006)(102836004)(59450400001)(478600001)(2501003)(606006)(99286004)(25786009)(53546011)(6506007)(3846002)(76176011)(6116002)(19609705001)(790700001)(8936002)(110136005)(14454004)(6306002)(9686003)(97736004)(106356001)(966005)(229853002)(72206003)(316002)(7696005)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1610; 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) x-microsoft-antispam-message-info: OLOEiEWsVOBuAFomlblHNLPNtKWoi7TKMZL7Jt9iE/dzpFn6SL9u6umotZ7ttjbsd+DmRRheE9NkNsoaGhi73w== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1788C020913BBAA2459B6ECFEACB0DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 6570276e-5739-4da2-29e3-08d575172432 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2018 08:27:39.4133 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1610 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 <6223> : inlines <6404> : streams <1779129> : uri <2593760> Archived-At: Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction 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, 16 Feb 2018 08:27:50 -0000 --_000_DM5PR16MB1788C020913BBAA2459B6ECFEACB0DM5PR16MB1788namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable There is no ambiguity in the roles. The CPE is acting as DOTS server but th= e DOTS server is initiating connection to the DOTS client in the access net= work. The DOTS client will convey the black-list filtering in the "out" dir= ection to block the traffic originating from the DOTS server domain. I don't understand what you mean by a "optional" parameter ? -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Friday, February 16, 2018 1:24 PM To: Konda, Tirumaleswar Reddy ; dots@ie= tf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction Hi Tiru, There will be an ambiguity in interpreting filters if and only if the same = DOTS agents have to manipulate filters in both directions. As you rightfully mentioned, the bb use case assumes the following: In order to achieve this capability, the telemetry analysis system utilized by the broadband access provider must have DOTS client functionality, and the end-customer CPE devices must have DOTS server functionality. Which means that there is no ambiguity in that case with the current defaul= t direction: "the destination is the DOTS client domain". No matter how roles were negotiated, but as far as each an agent acts as a = client and its peer as a server, things are clear. Of course we can always define an optional parameter for this, but it is pr= eferable to have a case for it. Cheers, Med De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] Envoy=E9 : jeudi 15 f=E9vrier 2018 16:31 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: draft-ietf-dots-data-channel: Filter Direction The filtering rule for outgoing traffic is required for the "Suppression of= outbound DDoS traffic originating from a consumer broadband access network= " use case discussed in https://tools.ietf.org/html/draft-ietf-dots-use-cas= es-09#section-3.2.1. In this use case, the CPE initially acts as a DOTS cli= ent but after the TCP connection is established, reverses its role and acts= as DOTS server (see https://tools.ietf.org/html/rfc8071). The access netwo= rk can then program the CPE using the DOTS data channel to block the DDoS a= ttack traffic originated from the compromised devices in the local customer network. Cheers, -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Wednesday, February 14, 2018 1:49 PM To: dots@ietf.org Subject: [Dots] draft-ietf-dots-data-channel: Filter Direction Hi all, As agreed during the interim, there are some issues that need fixes in the = data-channel spec. We would like to hear from the WG to know what to record= in the document. Issue description: Do we need to support explicit "direction" in filtering = rules ("in"/"out")? That is, do we allow a DOTS client to create filters fo= r both incoming and outgoing traffic? Below a proposal for discussion: - The current default direction is aligned with the nature of DDoS attac= ks targeted by DOTS: i.e. incoming. The DOTS client domain is assumed to be= the destination. No ambiguity so far with such default behavior. - There is no clear use case for the support of outgoing filtering handl= ing in the context of DOTS. - No text change is required to the draft. Any objection? Cheers, Med --_000_DM5PR16MB1788C020913BBAA2459B6ECFEACB0DM5PR16MB1788namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

There is = no ambiguity in the roles. The CPE is acting as DOTS server but the DOTS se= rver is initiating connection to the DOTS client in the access network. The= DOTS client will convey the black-list filtering in the “out” direction to block the traffic originat= ing from the DOTS server domain.

I donR= 17;t understand what you mean by a “optional” parameter ?<= /o:p>

&nbs= p;

-Tiru

 

From:<= /span> Dots [mailto:dots-bou= nces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: Friday, February 16, 2018 1:24 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction

 

Hi Tiru,

 

There will be an ambiguity in interpreting fil= ters if and only if the same DOTS agents have to manipulate filters in both= directions.

 

As you rightfully mentioned, the bb use case a= ssumes the following:

 

   In order to achieve t= his capability, the telemetry analysis system

   utilized by the broad= band access provider must have DOTS client

   functionality, and th= e end-customer CPE devices must have DOTS server

   functionality.

 

Which means that there is no ambiguity in that= case with the current default direction: “the destination is the DOT= S client domain”.

 

No matter how roles were negotiated, but a=
s far as each an agent acts as a client and its peer as a server, things ar=
e clear. 
 
Of course we can always define an optional=
 parameter for this, but it is preferable to have a case for it.  
 
Cheers,
Med

 

De : Konda, Tirumaleswar Reddy [mailto:Tirumaleswar= Reddy_Konda@McAfee.com]
Envoy=E9 : jeudi 15 f=E9vrier 2018 16:31
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: draft-ietf-dots-data-channel: Filter Direction=

 

The filte= ring rule for outgoing traffic is required for the "Suppression of out= bound DDoS traffic originating from a consumer broadband access network&quo= t; use case discussed in https://tools.ietf.org/html/draft-ietf-dots-use-cases-09#section-3.2.1.= In this use case, the CPE initially acts as a DOTS client but after the TC= P connection is established, reverses its role and acts as DOTS server (see https://tools.ietf.org/html= /rfc8071). The access network can then program the CPE using the DOTS d= ata channel to block the DDoS attack traffic originated from the compromise= d devices in the

local cus= tomer network.

&nbs= p;

Cheers,

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed= .boucadair@orange.com
Sent: Wednesday, February 14, 2018 1:49 PM
To: dots@ietf.org
Subject: [Dots] draft-ietf-dots-data-channel: Filter Direction<= /o:p>

 

Hi all,

 

As agreed during the interim, there are some issues that n= eed fixes in the data-channel spec. We would like to hear from the WG to kn= ow what to record in the document.

 

Issue description: Do we need to support explicit “d= irection” in filtering rules (“in”/“out”)? Th= at is, do we allow a DOTS client to create filters for both incoming and ou= tgoing traffic?

 

Below a proposal for discussion:

– = ;   The current default direction is aligned with the nature of DDoS attacks t= argeted by DOTS: i.e. incoming. The DOTS client domain is assumed to be the= destination. No ambiguity so far with such default behavior.

– = ;   There is no clear use case for the support of outgoing filtering handling = in the context of DOTS.

– = ;   No text change is required to the draft.

 <= /p>

Any objection?

 <= /p>

Cheers,=

Med

 

--_000_DM5PR16MB1788C020913BBAA2459B6ECFEACB0DM5PR16MB1788namp_-- From nobody Fri Feb 16 00:48:46 2018 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 54AA11242F7 for ; Fri, 16 Feb 2018 00:48:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 tv746swGRYXi for ; Fri, 16 Feb 2018 00:48:43 -0800 (PST) Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35CF21205F0 for ; Fri, 16 Feb 2018 00:48:43 -0800 (PST) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id C243F2131C; Fri, 16 Feb 2018 09:48:41 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.3]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 9FF4612006E; Fri, 16 Feb 2018 09:48:41 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5D.corporate.adroot.infra.ftgroup ([fe80::9898:741c:bc1d:258d%19]) with mapi id 14.03.0382.000; Fri, 16 Feb 2018 09:48:41 +0100 From: To: "Konda, Tirumaleswar Reddy" , "dots@ietf.org" Thread-Topic: draft-ietf-dots-data-channel: Filter Direction Thread-Index: AdOlbGwqi1N7Z468TzqkpTeHXPf9AQBBCWQgACITfVAAAZZfcAAAttzQ Date: Fri, 16 Feb 2018 08:48:40 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0D3331@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300A0D1F7C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0D327F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A0D3331OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction 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, 16 Feb 2018 08:48:45 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A0D3331OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 16 f=E9vrier 2018 09:28 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] draft-ietf-dots-data-channel: Filter Direction There is no ambiguity in the roles. The CPE is acting as DOTS server but th= e DOTS server is initiating connection to the DOTS client in the access net= work. [Med] Don't get the last part. The server (CPE) will receive a request from= the network (client) to filter traffic exiting from that CPE. The DOTS client will convey the black-list filtering in the "out" direction= to block the traffic originating from the DOTS server domain. [Med] Which corresponds to the "DOTS Server to DOTS Client" direction; that= is the DOTS client domain (access network) is the destination. All is fine= so far :) I don't understand what you mean by a "optional" parameter ? [Med] I meant adding a parameter to indicate explicitly the direction. It w= ould be optional because we do already have a default direction. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Friday, February 16, 2018 1:24 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction Hi Tiru, There will be an ambiguity in interpreting filters if and only if the same = DOTS agents have to manipulate filters in both directions. As you rightfully mentioned, the bb use case assumes the following: In order to achieve this capability, the telemetry analysis system utilized by the broadband access provider must have DOTS client functionality, and the end-customer CPE devices must have DOTS server functionality. Which means that there is no ambiguity in that case with the current defaul= t direction: "the destination is the DOTS client domain". No matter how roles were negotiated, but as far as each an agent acts as a = client and its peer as a server, things are clear. Of course we can always define an optional parameter for this, but it is pr= eferable to have a case for it. Cheers, Med De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] Envoy=E9 : jeudi 15 f=E9vrier 2018 16:31 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: draft-ietf-dots-data-channel: Filter Direction The filtering rule for outgoing traffic is required for the "Suppression of= outbound DDoS traffic originating from a consumer broadband access network= " use case discussed in https://tools.ietf.org/html/draft-ietf-dots-use-cas= es-09#section-3.2.1. In this use case, the CPE initially acts as a DOTS cli= ent but after the TCP connection is established, reverses its role and acts= as DOTS server (see https://tools.ietf.org/html/rfc8071). The access netwo= rk can then program the CPE using the DOTS data channel to block the DDoS a= ttack traffic originated from the compromised devices in the local customer network. Cheers, -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Wednesday, February 14, 2018 1:49 PM To: dots@ietf.org Subject: [Dots] draft-ietf-dots-data-channel: Filter Direction Hi all, As agreed during the interim, there are some issues that need fixes in the = data-channel spec. We would like to hear from the WG to know what to record= in the document. Issue description: Do we need to support explicit "direction" in filtering = rules ("in"/"out")? That is, do we allow a DOTS client to create filters fo= r both incoming and outgoing traffic? Below a proposal for discussion: - The current default direction is aligned with the nature of DDoS attac= ks targeted by DOTS: i.e. incoming. The DOTS client domain is assumed to be= the destination. No ambiguity so far with such default behavior. - There is no clear use case for the support of outgoing filtering handl= ing in the context of DOTS. - No text change is required to the draft. Any objection? Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300A0D3331OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.= org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : vendredi 16 f=E9vrier 2018 09:28
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : Re: [Dots] draft-ietf-dots-data-channel: Filter Directi= on

 

There is no ambiguity in the roles. The CPE is acting as DOTS server = but the DOTS server is initiating connection to the DOTS client in the acce= ss network.

[Med= ] Don’t get the last part. The server (CPE) will receive a request fr= om the network (client) to filter traffic exiting from that CPE.

 

The DOTS client will convey the black-list filtering in the “ou= t” direction to block the traffic originating from the DOTS server do= main.

[Med= ] Which corresponds to the “DOTS Server to DOTS Client” directi= on; that is the DOTS client domain (access network) is the destination. All is fine so far :)

 

I don’t understand what you mean by a “optional” pa= rameter ?

[Med= ] I meant adding a parameter to indicate explicitly the direction. It would= be optional because we do already have a default direction.

 

-Tiru

 

From: Dots [mailto:dots-bounces= @ietf.org] On Behalf Of mohamed= .boucadair@orange.com
Sent: Friday, February 16, 2018 1:24 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction

 

Hi Tiru,

 

There will be an ambiguity in i= nterpreting filters if and only if the same DOTS agents have to manipulate = filters in both directions.

 

As you rightfully mentioned, th= e bb use case assumes the following:

 

   In ord= er to achieve this capability, the telemetry analysis system

   utiliz= ed by the broadband access provider must have DOTS client=

   functi= onality, and the end-customer CPE devices must have DOTS server<= /span>

   functionality.

 

Which means that there is no am= biguity in that case with the current default direction: “the destina= tion is the DOTS client domain”.

 

No matter how roles were =
negotiated, but as far as each an agent acts as a client and its peer as a =
server, things are clear. 
 <=
/pre>

Of course we can always d=
efine an optional parameter for this, but it is preferable to have a case f=
or it.  


 <=
/pre>

Cheers,=



Med

 








De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_=
Konda@McAfee.com]


Envoy=E9 : jeudi 15 f=E9vrier 2018 16:31

=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org

Objet : RE: draft-ietf-dots-data-channel: Filter Direction=







 


The filtering rule for outgoing traffic is required for the "Sup=
pression of outbound DDoS traffic originating from a consumer broadband acc=
ess network" use case discussed in

https://tools.ietf.org/html/draft-ietf-dots-use-cases-09#section-3.2.1.=
 In this use case, the CPE initially acts as a DOTS client but after the TC=
P connection is established, reverses its role and acts as DOTS server (see
https://tools.ietf.org/html=
/rfc8071). The access network can then program the CPE using the DOTS d=
ata channel to block the DDoS attack traffic originated from the compromise=
d devices in the



local customer network.



 


Cheers,


-Tiru


 








From: Dots [mailto:dots-bounces=
@ietf.org]
On Behalf Of mohamed=
.boucadair@orange.com

Sent: Wednesday, February 14, 2018 1:49 PM

To: dots@ietf.org

Subject: [Dots] draft-ietf-dots-data-channel: Filter Direction<=
/o:p>






 


Hi all,



 


As agreed during the interim, there are som=
e issues that need fixes in the data-channel spec. We would like to hear fr=
om the WG to know what to record in the document.



 


Issue description: Do we need to support ex=
plicit “direction” in filtering rules (“in”/“=
out”)? That is, do we allow a DOTS client to create filters for both =
incoming
 and outgoing traffic? 


 


Below a proposal for discussion:=



–=
;   
The current default direction is aligned with the nature of=
 DDoS attacks targeted by DOTS: i.e. incoming. The DOTS client domain is as=
sumed to be the destination. No ambiguity so far
 with such default behavior. 


–=
;   
There is no clear use case for the support of outgoing filt=
ering handling in the context of DOTS.


–=
;   
No text change is required to the draft.<=
/p>

 =
;


Any object=
ion?



 =
;


Cheers,


Med



 
--_000_787AE7BB302AE849A7480A190F8B93300A0D3331OPEXCLILMA3corp_-- From nobody Fri Feb 16 01:06:51 2018 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 ED2A4124BAC for ; Fri, 16 Feb 2018 01:06:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 SnNK9F-R_hMO for ; Fri, 16 Feb 2018 01:06:47 -0800 (PST) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 DC89D120724 for ; Fri, 16 Feb 2018 01:06:46 -0800 (PST) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1518772005; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:x-originating-ip: x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: authentication-results:x-microsoft-antispam-prvs: x-exchange-antispam-report-test:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=eTESjl14eA8oey6ZND2j3swG3qWwp1NTt1pvj1 H2jPc=; b=X1OvBIToeCNkyuV1N8bsfVTedNSC9+RzHcKiqsHg 7uiwpnMUCIKio/7ii8SJidwXPJFL6B2tLwU3cj0rwBD/8Bik/8 FGBdG1aUJIcT+ejWq/qfRXg9TITK+sVau6P2Ub9FjTFmP1Vqod UUzpu5qnrrRmDQ+bczDRzFQ8kWApipc= Received: from MIVEXAPP1N02.corpzone.internalzone.com (mivexapp1n02.corpzone.internalzone.com [10.48.48.89]) by MIVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 4a85_0740_9beabf7b_b994_4c65_b6c4_2fb842098f23; Fri, 16 Feb 2018 03:06:45 -0600 Received: from MIVEXUSR1N07.corpzone.internalzone.com (10.48.48.87) by MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 16 Feb 2018 04:06:40 -0500 Received: from MIVEXUSR1N07.corpzone.internalzone.com (10.48.48.87) by MIVEXUSR1N07.corpzone.internalzone.com (10.48.48.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 16 Feb 2018 04:06:38 -0500 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.1347.2 via Frontend Transport; Fri, 16 Feb 2018 04:06:38 -0500 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (10.48.176.240) by edge.mcafee.com (10.48.176.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 16 Feb 2018 04:06:35 -0500 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1449.namprd16.prod.outlook.com (10.173.211.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.18; Fri, 16 Feb 2018 09:06:34 +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.20.0485.015; Fri, 16 Feb 2018 09:06:34 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: draft-ietf-dots-data-channel: Filter Direction Thread-Index: AdOlbGwqi1N7Z468TzqkpTeHXPf9AQBBCWQgACITfVAAAZZfcAAAttzQAABGxtA= Date: Fri, 16 Feb 2018 09:06:34 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A0D1F7C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0D327F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0D3331@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A0D3331@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1449; 7:ayhBk/Hus5I1KVLh+HI/biar2X0nkgJSnwFB4gilv4EwTI/5vNQi6+l6AHWj3MeuTUtTO6dndN011PusYuBXEPkBgyMWrBKhAukmiBdhWd+mIlWnaOCv4d/AwRlIHlSZ6WocOyYXUMbt0VMlHcNrKql4lCP2EP8pDENwgMEyS1aHxWcEyBFj8xomB6vu/6Md82d5GLLVi+UZ+7o8Z+2W7QxG6LRDYyJ11DvO51uxnMt0nKYcXUdaRPu8bkKtIVbF x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 5d33a71b-6fd9-4ea7-7de4-08d5751c941d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM5PR16MB1449; x-ms-traffictypediagnostic: DM5PR16MB1449: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(18271650672692)(21748063052155)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001037)(6040501)(2401047)(8121501046)(5005006)(10201501046)(3231101)(944501161)(93006095)(93001095)(3002001)(6041288)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:DM5PR16MB1449; BCL:0; PCL:0; RULEID:; SRVR:DM5PR16MB1449; x-forefront-prvs: 0585417D7B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(346002)(376002)(39380400002)(366004)(39860400002)(32952001)(57704003)(189003)(199004)(53754006)(74316002)(77096007)(26005)(7736002)(316002)(186003)(66066001)(3660700001)(105586002)(6436002)(106356001)(5660300001)(8676002)(9686003)(8936002)(76176011)(99286004)(68736007)(2501003)(110136005)(19609705001)(7696005)(53936002)(102836004)(80792005)(81156014)(81166006)(33656002)(59450400001)(561944003)(6506007)(236005)(53546011)(55016002)(97736004)(3280700002)(6246003)(606006)(478600001)(93886005)(2906002)(25786009)(54896002)(86362001)(229853002)(14454004)(72206003)(2950100002)(966005)(3846002)(6116002)(6306002)(790700001)(2900100001)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1449; 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) x-microsoft-antispam-message-info: huXWccZzAD2PFmMQ4MnScII8Hp2usd8mi9IyOu5jbpSHoXFAbgCxDjFX7cuGfL4j0GngrmKyQA8U93jVfrt9Gg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1788C9165D0BF574ED4102BFEACB0DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 5d33a71b-6fd9-4ea7-7de4-08d5751c941d X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2018 09:06:34.5413 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1449 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 <6223> : inlines <6404> : streams <1779131> : uri <2593777> Archived-At: Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction 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, 16 Feb 2018 09:06:50 -0000 --_000_DM5PR16MB1788C9165D0BF574ED4102BFEACB0DM5PR16MB1788namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 2:19 PM To: Konda, Tirumaleswar Reddy ; dots@ie= tf.org Subject: RE: draft-ietf-dots-data-channel: Filter Direction Re-, Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 16 f=E9vrier 2018 09:28 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] draft-ietf-dots-data-channel: Filter Direction There is no ambiguity in the roles. The CPE is acting as DOTS server but th= e DOTS server is initiating connection to the DOTS client in the access net= work. [Med] Don't get the last part. The server (CPE) will receive a request from= the network (client) to filter traffic exiting from that CPE. [TR] I mean to use the call home feature discussed in https://tools.ietf.or= g/html/rfc8071, though the CPE is acting as a DOTS server it will initiate = the connection (TLS or DTLS) to the DOTS client in the access network. The = call home feature helps avoid various threats like the DOTS server in the C= PE will not be subjected to DDoS attacks, and reachability is not problem e= ven if the CPE is behind NAT. The DOTS client will convey the black-list filtering in the "out" direction= to block the traffic originating from the DOTS server domain. [Med] Which corresponds to the "DOTS Server to DOTS Client" direction; that= is the DOTS client domain (access network) is the destination. All is fine= so far :) [TR] The direction is "outgoing traffic" whereas for other use cases the di= rection is "incoming traffic". I don't understand what you mean by a "optional" parameter ? [Med] I meant adding a parameter to indicate explicitly the direction. It w= ould be optional because we do already have a default direction. [TR] Okay. -Tiru -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Friday, February 16, 2018 1:24 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction Hi Tiru, There will be an ambiguity in interpreting filters if and only if the same = DOTS agents have to manipulate filters in both directions. As you rightfully mentioned, the bb use case assumes the following: In order to achieve this capability, the telemetry analysis system utilized by the broadband access provider must have DOTS client functionality, and the end-customer CPE devices must have DOTS server functionality. Which means that there is no ambiguity in that case with the current defaul= t direction: "the destination is the DOTS client domain". No matter how roles were negotiated, but as far as each an agent acts as a = client and its peer as a server, things are clear. Of course we can always define an optional parameter for this, but it is pr= eferable to have a case for it. Cheers, Med De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] Envoy=E9 : jeudi 15 f=E9vrier 2018 16:31 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: draft-ietf-dots-data-channel: Filter Direction The filtering rule for outgoing traffic is required for the "Suppression of= outbound DDoS traffic originating from a consumer broadband access network= " use case discussed in https://tools.ietf.org/html/draft-ietf-dots-use-cas= es-09#section-3.2.1. In this use case, the CPE initially acts as a DOTS cli= ent but after the TCP connection is established, reverses its role and acts= as DOTS server (see https://tools.ietf.org/html/rfc8071). The access netwo= rk can then program the CPE using the DOTS data channel to block the DDoS a= ttack traffic originated from the compromised devices in the local customer network. Cheers, -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Wednesday, February 14, 2018 1:49 PM To: dots@ietf.org Subject: [Dots] draft-ietf-dots-data-channel: Filter Direction Hi all, As agreed during the interim, there are some issues that need fixes in the = data-channel spec. We would like to hear from the WG to know what to record= in the document. Issue description: Do we need to support explicit "direction" in filtering = rules ("in"/"out")? That is, do we allow a DOTS client to create filters fo= r both incoming and outgoing traffic? Below a proposal for discussion: - The current default direction is aligned with the nature of DDoS attac= ks targeted by DOTS: i.e. incoming. The DOTS client domain is assumed to be= the destination. No ambiguity so far with such default behavior. - There is no clear use case for the support of outgoing filtering handl= ing in the context of DOTS. - No text change is required to the draft. Any objection? Cheers, Med --_000_DM5PR16MB1788C9165D0BF574ED4102BFEACB0DM5PR16MB1788namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

From:<= /span> mohamed.boucadair@ora= nge.com [mailto:mohamed.boucadair@orange.com]
Sent: Friday, February 16, 2018 2:19 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org
Subject: RE: draft-ietf-dots-data-channel: Filter Direction

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : vendredi 16 f=E9vrier 2018 09:28
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : Re: [Dots] draft-ietf-dots-data-channel: Filter Directi= on

 

There is = no ambiguity in the roles. The CPE is acting as DOTS server but the DOTS se= rver is initiating connection to the DOTS client in the access network.

[Med] Don’t g= et the last part. The server (CPE) will receive a request from the network = (client) to filter traffic exiting from that CPE.

&nbs= p;

[TR] I me= an to use the call home feature discussed in https://tools.ietf.org/html= /rfc8071, though the CPE is acting as a DOTS server it will initiate th= e connection (TLS or DTLS) to the DOTS client in the access network. The ca= ll home feature helps avoid various threats like the DOTS server in the CPE will not be subjected to DDoS atta= cks, and reachability is not problem even if the CPE is behind NAT.

 

The DOTS = client will convey the black-list filtering in the “out” direct= ion to block the traffic originating from the DOTS server domain.

[Med] Which corresp= onds to the “DOTS Server to DOTS Client” direction; that is the= DOTS client domain (access network) is the destination. All is fine so far :)

&nbs= p;

&nbs= p;

[TR] The = direction is “outgoing traffic” whereas for other use cases the= direction is “incoming traffic”.

 

I donR= 17;t understand what you mean by a “optional” parameter ?<= /o:p>

[Med] I meant addin= g a parameter to indicate explicitly the direction. It would be optional be= cause we do already have a default direction.

&nbs= p;

[TR] Okay= .

&nbs= p;

-Tiru

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed= .boucadair@orange.com
Sent: Friday, February 16, 2018 1:24 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction

 

Hi Tiru,

 

There will be an ambiguity in interpreting fil= ters if and only if the same DOTS agents have to manipulate filters in both= directions.

 

As you rightfully mentioned, the bb use case a= ssumes the following:

 

   In order to achieve t= his capability, the telemetry analysis system

   utilized by the broad= band access provider must have DOTS client

   functionality, and th= e end-customer CPE devices must have DOTS server

   functionality.

 

Which means that there is no ambiguity in that= case with the current default direction: “the destination is the DOT= S client domain”.

 

No matter how roles were negotiated, but=
 as far as each an agent acts as a client and its peer as a server, things =
are clear. 
 
Of course we can always define an option=
al parameter for this, but it is preferable to have a case for it.  
 
Cheers,
Med

 

De : Konda, Tirumaleswar Reddy [mailto:Tirumaleswar= Reddy_Konda@McAfee.com]
Envoy=E9 : jeudi 15 f=E9vrier 2018 16:31
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: draft-ietf-dots-data-channel: Filter Direction=

 

The filte= ring rule for outgoing traffic is required for the "Suppression of out= bound DDoS traffic originating from a consumer broadband access network&quo= t; use case discussed in https://tools.ietf.org/html/draft-ietf-dots-use-cases-09#section-3.2.1.= In this use case, the CPE initially acts as a DOTS client but after the TC= P connection is established, reverses its role and acts as DOTS server (see https://tools.ietf.org/html= /rfc8071). The access network can then program the CPE using the DOTS d= ata channel to block the DDoS attack traffic originated from the compromise= d devices in the

local cus= tomer network.

&nbs= p;

Cheers,

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed= .boucadair@orange.com
Sent: Wednesday, February 14, 2018 1:49 PM
To: dots@ietf.org
Subject: [Dots] draft-ietf-dots-data-channel: Filter Direction<= /o:p>

 

Hi all,

 

As agreed during the interim, there are some issues that n= eed fixes in the data-channel spec. We would like to hear from the WG to kn= ow what to record in the document.

 

Issue description: Do we need to support explicit “d= irection” in filtering rules (“in”/“out”)? Th= at is, do we allow a DOTS client to create filters for both incoming and ou= tgoing traffic?

 

Below a proposal for discussion:

– = ;   The current default direction is aligned with the nature of DDoS attacks t= argeted by DOTS: i.e. incoming. The DOTS client domain is assumed to be the= destination. No ambiguity so far with such default behavior.

– = ;   There is no clear use case for the support of outgoing filtering handling = in the context of DOTS.

– = ;   No text change is required to the draft.

 <= /p>

Any objection?

 <= /p>

Cheers,=

Med

 

--_000_DM5PR16MB1788C9165D0BF574ED4102BFEACB0DM5PR16MB1788namp_-- From nobody Fri Feb 16 01:57:35 2018 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 B6219126C23 for ; Fri, 16 Feb 2018 01:57:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 zig1r0HAL74s for ; Fri, 16 Feb 2018 01:57:31 -0800 (PST) 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 EB2E51242F7 for ; Fri, 16 Feb 2018 01:57:30 -0800 (PST) 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 1emclj-0000gE-L6; Fri, 16 Feb 2018 09:57:27 +0000 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , , References: <787AE7BB302AE849A7480A190F8B93300A0D1F7C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0D327F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0D3331@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Date: Fri, 16 Feb 2018 09:57:29 -0000 Message-ID: <005b01d3a70c$8e971af0$abc550d0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005C_01D3A70C.8E998BF0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJhm6BqxMEAgRtKQGWOWKzvESzJbAHkQu0GAe9IPZgCFkuYjAFWJpskAsM/rwWiOsPNAA== Content-Language: en-gb Archived-At: Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction 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, 16 Feb 2018 09:57:33 -0000 This is a multipart message in MIME format. ------=_NextPart_000_005C_01D3A70C.8E998BF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I understand the concept of call home =96 which makes good sense to me = and rfc8071 will, if implemented, handle the data channel and = =93destination=94 is still where the =91controlled=92 traffic is flowing to. =20 However, we also need call home in the signal channel. I=92m not sure = how this will be done =96 do we need a new CoAP Method (e.g. switch roles) = =96 do we need to define a different port (rfc8071 defines 4336) etc. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 16 February 2018 09:07 To: mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction =20 From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] = Sent: Friday, February 16, 2018 2:19 PM To: Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: RE: draft-ietf-dots-data-channel: Filter Direction =20 Re-, =20 Please see inline.=20 =20 Cheers, Med =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, = Tirumaleswar Reddy Envoy=E9 : vendredi 16 f=E9vrier 2018 09:28 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] draft-ietf-dots-data-channel: Filter Direction =20 There is no ambiguity in the roles. The CPE is acting as DOTS server but = the DOTS server is initiating connection to the DOTS client in the access network. [Med] Don=92t get the last part. The server (CPE) will receive a request = from the network (client) to filter traffic exiting from that CPE.=20 =20 [TR] I mean to use the call home feature discussed in https://tools.ietf.org/html/rfc8071, though the CPE is acting as a DOTS server it will initiate the connection (TLS or DTLS) to the DOTS client = in the access network. The call home feature helps avoid various threats = like the DOTS server in the CPE will not be subjected to DDoS attacks, and reachability is not problem even if the CPE is behind NAT.=20 =20 The DOTS client will convey the black-list filtering in the =93out=94 = direction to block the traffic originating from the DOTS server domain. [Med] Which corresponds to the =93DOTS Server to DOTS Client=94 = direction; that is the DOTS client domain (access network) is the destination. All is = fine so far :)=20 =20 =20 [TR] The direction is =93outgoing traffic=94 whereas for other use cases = the direction is =93incoming traffic=94.=20 =20 I don=92t understand what you mean by a =93optional=94 parameter ? [Med] I meant adding a parameter to indicate explicitly the direction. = It would be optional because we do already have a default direction. =20 [TR] Okay. =20 -Tiru =20 -Tiru =20 From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: Friday, February 16, 2018 1:24 PM To: Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction =20 Hi Tiru,=20 =20 There will be an ambiguity in interpreting filters if and only if the = same DOTS agents have to manipulate filters in both directions.=20 =20 As you rightfully mentioned, the bb use case assumes the following:=20 =20 In order to achieve this capability, the telemetry analysis system utilized by the broadband access provider must have DOTS client functionality, and the end-customer CPE devices must have DOTS server functionality. =20 Which means that there is no ambiguity in that case with the current = default direction: =93the destination is the DOTS client domain=94.=20 =20 No matter how roles were negotiated, but as far as each an agent acts as = a client and its peer as a server, things are clear.=20 =20 Of course we can always define an optional parameter for this, but it is preferable to have a case for it. =20 =20 Cheers, Med =20 De : Konda, Tirumaleswar Reddy = [mailto:TirumaleswarReddy_Konda@McAfee.com]=20 Envoy=E9 : jeudi 15 f=E9vrier 2018 16:31 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: draft-ietf-dots-data-channel: Filter Direction =20 The filtering rule for outgoing traffic is required for the "Suppression = of outbound DDoS traffic originating from a consumer broadband access = network" use case discussed in https://tools.ietf.org/html/draft-ietf-dots-use-cases-09#section-3.2.1. = In this use case, the CPE initially acts as a DOTS client but after the TCP connection is established, reverses its role and acts as DOTS server = (see https://tools.ietf.org/html/rfc8071). The access network can then = program the CPE using the DOTS data channel to block the DDoS attack traffic originated from the compromised devices in the=20 local customer network.=20 =20 Cheers, -Tiru =20 From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: Wednesday, February 14, 2018 1:49 PM To: dots@ietf.org Subject: [Dots] draft-ietf-dots-data-channel: Filter Direction =20 Hi all,=20 =20 As agreed during the interim, there are some issues that need fixes in = the data-channel spec. We would like to hear from the WG to know what to = record in the document.=20 =20 Issue description: Do we need to support explicit =93direction=94 in = filtering rules (=93in=94/=93out=94)? That is, do we allow a DOTS client to create = filters for both incoming and outgoing traffic?=20 =20 Below a proposal for discussion: =96 The current default direction is aligned with the nature of DDoS attacks targeted by DOTS: i.e. incoming. The DOTS client domain is = assumed to be the destination. No ambiguity so far with such default behavior.=20 =96 There is no clear use case for the support of outgoing filtering handling in the context of DOTS. =96 No text change is required to the draft. =20 Any objection?=20 =20 Cheers, Med=20 =20 ------=_NextPart_000_005C_01D3A70C.8E998BF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I understand the concept of call home – = which makes good sense to me and rfc8071 will, if implemented, handle = the data channel and “destination” is still where the = ‘controlled’ traffic is flowing to.

 

However, we also need = call home in the signal channel.=A0 I’m not sure how this will be = done – do we need a new CoAP Method (e.g. switch roles) – do = we need to define a different port (rfc8071 defines 4336) = etc.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = Konda, Tirumaleswar Reddy
Sent: 16 February 2018 = 09:07
To: mohamed.boucadair@orange.com; = dots@ietf.org
Subject: Re: [Dots] = draft-ietf-dots-data-channel: Filter = Direction

 

From: mohamed.boucadair@orange.com= [mailto:mohamed.boucadair@ora= nge.com]
Sent: Friday, February 16, 2018 2:19 = PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; dots@ietf.org
Subject: RE: = draft-ietf-dots-data-channel: Filter Direction

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] = De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : = vendredi 16 f=E9vrier 2018 09:28
=C0 : BOUCADAIR Mohamed = IMT/OLN; dots@ietf.org
Objet : = Re: [Dots] draft-ietf-dots-data-channel: Filter = Direction

 

There is no ambiguity = in the roles. The CPE is acting as DOTS server but the DOTS server is = initiating connection to the DOTS client in the access network.

[Med] Don’t get the = last part. The server (CPE) will receive a request from the network = (client) to filter traffic exiting from that CPE. =

 

[TR] I mean to use the call home = feature discussed in https://tools.ietf.org/html/= rfc8071, though the CPE is acting as a DOTS server it will initiate = the connection (TLS or DTLS) to the DOTS client in the access network. = The call home feature helps avoid various threats like the DOTS server = in the CPE will not be subjected to DDoS attacks, and reachability is = not problem even if the CPE is behind NAT.

 

=

The DOTS client will convey the = black-list filtering in the “out” direction to block the = traffic originating from the DOTS server domain.

[Med] Which corresponds to = the “DOTS Server to DOTS Client” direction; that is the DOTS = client domain (access network) is the destination. All is fine so far :) =

 

 

[TR] The direction is = “outgoing traffic” whereas for other use cases the direction = is “incoming traffic”.

 

=

I don’t understand what you = mean by a “optional” parameter ?

[Med] I meant adding a = parameter to indicate explicitly the direction. It would be optional = because we do already have a default direction.

 

[TR] Okay.

 

-Tiru

 

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of mohamed.boucadair@orange.com=
Sent: Friday, February 16, 2018 1:24 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; dots@ietf.org
Subject: Re: = [Dots] draft-ietf-dots-data-channel: Filter = Direction

 

Hi Tiru,

 

There will be an ambiguity in interpreting filters if = and only if the same DOTS agents have to manipulate filters in both = directions.

 

As you rightfully mentioned, the bb use case assumes = the following:

 

   In order to achieve this = capability, the telemetry analysis system

   utilized by the broadband = access provider must have DOTS client

   functionality, and the = end-customer CPE devices must have DOTS server

   functionality.

 

Which means that there is no ambiguity in that case = with the current default direction: “the destination is the DOTS = client domain”.

 

No matter how roles were =
negotiated, but as far as each an agent acts as a client and its peer as =
a server, things are clear. 
 
<= pre>Of course we can always define = an optional parameter for this, but it is preferable to have a case for = it.  
 
<= pre>Cheers,= 
Med

 

De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarRed= dy_Konda@McAfee.com]
Envoy=E9 : jeudi 15 f=E9vrier = 2018 16:31
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : = RE: draft-ietf-dots-data-channel: Filter = Direction

 

The filtering rule for = outgoing traffic is required for the "Suppression of outbound DDoS = traffic originating from a consumer broadband access network" use = case discussed in https://tools.ietf.org/html/draft-ietf-dots-use-cases-09#section-3= .2.1. In this use case, the CPE initially acts as a DOTS client but = after the TCP connection is established, reverses its role and acts as = DOTS server (see https://tools.ietf.org/html/= rfc8071). The access network can then program the CPE using the DOTS = data channel to block the DDoS attack traffic originated from the = compromised devices in the

local customer network. =

 

Cheers,

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of mohamed.boucadair@orange.com=
Sent: Wednesday, February 14, 2018 1:49 PM
To: = dots@ietf.org
Subject: = [Dots] draft-ietf-dots-data-channel: Filter = Direction

 

Hi = all,

 

As = agreed during the interim, there are some issues that need fixes in the = data-channel spec. We would like to hear from the WG to know what to = record in the document.

 

Issue = description: Do we need to support explicit “direction” in = filtering rules (“in”/“out”)? That is, do we = allow a DOTS client to create filters for both incoming and outgoing = traffic?

 

Below = a proposal for discussion:

–    The current default = direction is aligned with the nature of DDoS attacks targeted by DOTS: = i.e. incoming. The DOTS client domain is assumed to be the destination. = No ambiguity so far with such default behavior.

–    There is no clear = use case for the support of outgoing filtering handling in the context = of DOTS.

–    No text change is = required to the draft.

 

Any objection? =

 

Cheers,

Med =

 

------=_NextPart_000_005C_01D3A70C.8E998BF0-- From nobody Fri Feb 16 02:09:08 2018 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 60610126C19 for ; Fri, 16 Feb 2018 02:09:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 K9JiYknj5cUg for ; Fri, 16 Feb 2018 02:09:02 -0800 (PST) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18B561242F7 for ; Fri, 16 Feb 2018 02:09:02 -0800 (PST) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id BB487A144E; Fri, 16 Feb 2018 11:09:00 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.34]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id A1D0340068; Fri, 16 Feb 2018 11:09:00 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6F.corporate.adroot.infra.ftgroup ([fe80::bd00:88f8:8552:3349%17]) with mapi id 14.03.0382.000; Fri, 16 Feb 2018 11:09:00 +0100 From: To: "Konda, Tirumaleswar Reddy" , "dots@ietf.org" Thread-Topic: draft-ietf-dots-data-channel: Filter Direction Thread-Index: AdOlbGwqi1N7Z468TzqkpTeHXPf9AQBBCWQgACITfVAAAZZfcAAAttzQAABGxtAAAo6C4A== Date: Fri, 16 Feb 2018 10:08:59 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0D3409@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300A0D1F7C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0D327F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0D3331@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A0D3409OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction 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, 16 Feb 2018 10:09:07 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A0D3409OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, Please see inline. Cheers, Med De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] Envoy=E9 : vendredi 16 f=E9vrier 2018 10:07 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: draft-ietf-dots-data-channel: Filter Direction From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 2:19 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: draft-ietf-dots-data-channel: Filter Direction Re-, Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 16 f=E9vrier 2018 09:28 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] draft-ietf-dots-data-channel: Filter Direction There is no ambiguity in the roles. The CPE is acting as DOTS server but th= e DOTS server is initiating connection to the DOTS client in the access net= work. [Med] Don't get the last part. The server (CPE) will receive a request from= the network (client) to filter traffic exiting from that CPE. [TR] I mean to use the call home feature discussed in https://tools.ietf.or= g/html/rfc8071, though the CPE is acting as a DOTS server it will initiate = the connection (TLS or DTLS) to the DOTS client in the access network. The = call home feature helps avoid various threats like the DOTS server in the C= PE will not be subjected to DDoS attacks, and reachability is not problem e= ven if the CPE is behind NAT. [Med] OK. The DOTS client will convey the black-list filtering in the "out" direction= to block the traffic originating from the DOTS server domain. [Med] Which corresponds to the "DOTS Server to DOTS Client" direction; that= is the DOTS client domain (access network) is the destination. All is fine= so far :) [TR] The direction is "outgoing traffic" whereas for other use cases the di= rection is "incoming traffic". [Med] Tiru, the direction in both cases is always the same: "DOTS Server to= DOTS Client". Of course, from the perspective of the CPE (not the DOTS age= nt role), this will be "out" or "in" depending on the DOTS agent role on th= e CPE, but this is not important to determine the direction of the filters;= only DOTS roles matter. I don't understand what you mean by a "optional" parameter ? [Med] I meant adding a parameter to indicate explicitly the direction. It w= ould be optional because we do already have a default direction. [TR] Okay. -Tiru -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Friday, February 16, 2018 1:24 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction Hi Tiru, There will be an ambiguity in interpreting filters if and only if the same = DOTS agents have to manipulate filters in both directions. As you rightfully mentioned, the bb use case assumes the following: In order to achieve this capability, the telemetry analysis system utilized by the broadband access provider must have DOTS client functionality, and the end-customer CPE devices must have DOTS server functionality. Which means that there is no ambiguity in that case with the current defaul= t direction: "the destination is the DOTS client domain". No matter how roles were negotiated, but as far as each an agent acts as a = client and its peer as a server, things are clear. Of course we can always define an optional parameter for this, but it is pr= eferable to have a case for it. Cheers, Med De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] Envoy=E9 : jeudi 15 f=E9vrier 2018 16:31 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: draft-ietf-dots-data-channel: Filter Direction The filtering rule for outgoing traffic is required for the "Suppression of= outbound DDoS traffic originating from a consumer broadband access network= " use case discussed in https://tools.ietf.org/html/draft-ietf-dots-use-cas= es-09#section-3.2.1. In this use case, the CPE initially acts as a DOTS cli= ent but after the TCP connection is established, reverses its role and acts= as DOTS server (see https://tools.ietf.org/html/rfc8071). The access netwo= rk can then program the CPE using the DOTS data channel to block the DDoS a= ttack traffic originated from the compromised devices in the local customer network. Cheers, -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Wednesday, February 14, 2018 1:49 PM To: dots@ietf.org Subject: [Dots] draft-ietf-dots-data-channel: Filter Direction Hi all, As agreed during the interim, there are some issues that need fixes in the = data-channel spec. We would like to hear from the WG to know what to record= in the document. Issue description: Do we need to support explicit "direction" in filtering = rules ("in"/"out")? That is, do we allow a DOTS client to create filters fo= r both incoming and outgoing traffic? Below a proposal for discussion: - The current default direction is aligned with the nature of DDoS attac= ks targeted by DOTS: i.e. incoming. The DOTS client domain is assumed to be= the destination. No ambiguity so far with such default behavior. - There is no clear use case for the support of outgoing filtering handl= ing in the context of DOTS. - No text change is required to the draft. Any objection? Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300A0D3409OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Konda, Tirumaleswar Reddy [mail= to:TirumaleswarReddy_Konda@McAfee.com]
Envoy=E9 : vendredi 16 f=E9vrier 2018 10:07
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: draft-ietf-dots-data-channel: Filter Direction=

 

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Friday, February 16, 2018 2:19 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: RE: draft-ietf-dots-data-channel: Filter Direction

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : vendredi 16 f=E9vrier 2018 09:28
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : Re: [Dots] draft-ietf-dots-data-channel: Filter Directi= on

 

There is no ambiguity in the roles. The CPE is acting as DOTS server = but the DOTS server is initiating connection to the DOTS client in the acce= ss network.

[Med= ] Don’t get the last part. The server (CPE) will receive a request fr= om the network (client) to filter traffic exiting from that CPE.

 

[TR] I mean to use the call home feature discussed in https://tools.ietf.org/html= /rfc8071, though the CPE is acting as a DOTS server it will initiate th= e connection (TLS or DTLS) to the DOTS client in the access network. The ca= ll home feature helps avoid various threats like the DOTS server in the CPE will not be subjected to DDoS atta= cks, and reachability is not problem even if the CPE is behind NAT.

[Med= ] OK.

 

The DOTS client will convey the black-list filtering in the “ou= t” direction to block the traffic originating from the DOTS server do= main.

[Med= ] Which corresponds to the “DOTS Server to DOTS Client” directi= on; that is the DOTS client domain (access network) is the destination. All is fine so far :)

 

 

[TR] The direction is “outgoing traffic” whereas for othe= r use cases the direction is “incoming traffic”.

[Med= ] Tiru, the direction in both cases is always the same: “DOTS Server t= o DOTS Client”= . Of course, from the perspective of the CPE (not the DOTS agent role), this= will be “out” or “in” depending on the DOTS agent = role on the CPE, but this is not important to determine the direction of th= e filters; only DOTS roles matter.

 

I don’t understand what you mean by a “optional” pa= rameter ?

[Med= ] I meant adding a parameter to indicate explicitly the direction. It would= be optional because we do already have a default direction.

 

[TR] Okay.

 

-Tiru

 

-Tiru

 

From: Dots [mailto:dots-bounces= @ietf.org] On Behalf Of mohamed= .boucadair@orange.com
Sent: Friday, February 16, 2018 1:24 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction

 

Hi Tiru,

 

There will be an ambiguity in i= nterpreting filters if and only if the same DOTS agents have to manipulate = filters in both directions.

 

As you rightfully mentioned, th= e bb use case assumes the following:

 

   In ord= er to achieve this capability, the telemetry analysis system

   utiliz= ed by the broadband access provider must have DOTS client=

   functi= onality, and the end-customer CPE devices must have DOTS server<= /span>

   functionality.

 

Which means that there is no am= biguity in that case with the current default direction: “the destina= tion is the DOTS client domain”.

 

No matter how roles were =
negotiated, but as far as each an agent acts as a client and its peer as a =
server, things are clear. 
 <=
/pre>

Of course we can always d=
efine an optional parameter for this, but it is preferable to have a case f=
or it.  


 <=
/pre>

Cheers,=



Med

 








De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_=
Konda@McAfee.com]


Envoy=E9 : jeudi 15 f=E9vrier 2018 16:31

=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org

Objet : RE: draft-ietf-dots-data-channel: Filter Direction=







 


The filtering rule for outgoing traffic is required for the "Sup=
pression of outbound DDoS traffic originating from a consumer broadband acc=
ess network" use case discussed in

https://tools.ietf.org/html/draft-ietf-dots-use-cases-09#section-3.2.1.=
 In this use case, the CPE initially acts as a DOTS client but after the TC=
P connection is established, reverses its role and acts as DOTS server (see
https://tools.ietf.org/html=
/rfc8071). The access network can then program the CPE using the DOTS d=
ata channel to block the DDoS attack traffic originated from the compromise=
d devices in the



local customer network.



 


Cheers,


-Tiru


 








From: Dots [mailto:dots-bounces=
@ietf.org]
On Behalf Of mohamed=
.boucadair@orange.com

Sent: Wednesday, February 14, 2018 1:49 PM

To: dots@ietf.org

Subject: [Dots] draft-ietf-dots-data-channel: Filter Direction<=
/o:p>






 


Hi all,



 


As agreed during the interim, there are som=
e issues that need fixes in the data-channel spec. We would like to hear fr=
om the WG to know what to record in the document.



 


Issue description: Do we need to support ex=
plicit “direction” in filtering rules (“in”/“=
out”)? That is, do we allow a DOTS client to create filters for both =
incoming
 and outgoing traffic? 


 


Below a proposal for discussion:=



–=
;   
The current default direction is aligned with the nature of=
 DDoS attacks targeted by DOTS: i.e. incoming. The DOTS client domain is as=
sumed to be the destination. No ambiguity so far
 with such default behavior. 


–=
;   
There is no clear use case for the support of outgoing filt=
ering handling in the context of DOTS.


–=
;   
No text change is required to the draft.<=
/p>

 =
;


Any object=
ion?



 =
;


Cheers,


Med



 
--_000_787AE7BB302AE849A7480A190F8B93300A0D3409OPEXCLILMA3corp_-- From nobody Fri Feb 16 02:16:48 2018 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 EAB81126C19 for ; Fri, 16 Feb 2018 02:16:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.33 X-Spam-Level: X-Spam-Status: No, score=-4.33 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 8aka6LF2dCqa for ; Fri, 16 Feb 2018 02:16:45 -0800 (PST) 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 BC6D91242F7 for ; Fri, 16 Feb 2018 02:16:44 -0800 (PST) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1518776204; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=AaiAZPI27za/yd8zcS7IzR3jrbgZRXv16kJO/c ifLBE=; b=c8pRjxg1RPC+GI32trcCTlF0+jgctAjlreujiBsk exT9c9EuuJUFerZt9McHb7wO/7VynwBWrnQ8Y0QFZftPfxruWq wPE7ti9JThEAH5bq5OGbtlfQys1z5Av2gpYxu7z7gzpx59yZyx HzIzrPzLD2kcOOpNmyEbfhAKvGj4HjY= Received: from DNVEXAPP1N05.corpzone.internalzone.com (DNVEXAPP1N05.corpzone.internalzone.com [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 40da_0f2b_962c046b_e853_472f_a9b1_10feb54f61ba; Fri, 16 Feb 2018 04:16:43 -0600 Received: from DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 16 Feb 2018 03:16:18 -0700 Received: from DNVEXUSR1N13.corpzone.internalzone.com (10.44.48.86) by DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 16 Feb 2018 03:16:18 -0700 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXUSR1N13.corpzone.internalzone.com (10.44.48.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Fri, 16 Feb 2018 03:16:17 -0700 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.1347.2; Fri, 16 Feb 2018 03:15:51 -0700 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB2296.namprd16.prod.outlook.com (52.132.142.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.18; Fri, 16 Feb 2018 10:16:05 +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.20.0485.015; Fri, 16 Feb 2018 10:16:05 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: [Dots] draft-ietf-dots-data-channel: Filter Direction Thread-Index: AdOlbGwqi1N7Z468TzqkpTeHXPf9AQBBCWQgACITfVAAAZZfcAAAttzQAABGxtAAAlecgAAAiINQ Date: Fri, 16 Feb 2018 10:16:05 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A0D1F7C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0D327F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0D3331@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <005b01d3a70c$8e971af0$abc550d0$@jpshallow.com> In-Reply-To: <005b01d3a70c$8e971af0$abc550d0$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action 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; DM5PR16MB2296; 7:U6ywvVtS8+VuZKQe4/asnMolHtN6mZj96S1ybO7gjX6rkS8k4Hvh/i+Qfn56Klch/J7oetkxwLHT7y7pj2zFPMcQmrnVkZqhU13Z+O2ch5P6FLVE26Jz5fp3UJfST8rIKJFNWVnpBLKj5qi51jhALZLGQTa/o7J7AttcR57wZ0XGwpt7maoaE1DWarTne69lOrwUi7apYTFDTmn/BrEAtWGZwXyJ3c11wekz6oglAr5Zawth5t4rs2poichNxJZm x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 94a498e5-da83-4963-fddb-08d575264a18 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:DM5PR16MB2296; x-ms-traffictypediagnostic: DM5PR16MB2296: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(18271650672692)(21748063052155)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(3231101)(944501161)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123560045)(20161123562045)(6072148)(201708071742011); SRVR:DM5PR16MB2296; BCL:0; PCL:0; RULEID:; SRVR:DM5PR16MB2296; x-forefront-prvs: 0585417D7B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(376002)(39380400002)(396003)(366004)(32952001)(53754006)(57704003)(199004)(189003)(81166006)(33656002)(8676002)(106356001)(6246003)(8936002)(7696005)(93886005)(19609705001)(5660300001)(99286004)(561944003)(316002)(2900100001)(81156014)(105586002)(606006)(66066001)(478600001)(102836004)(3660700001)(110136005)(14454004)(3280700002)(966005)(72206003)(236005)(68736007)(76176011)(25786009)(53936002)(6436002)(2950100002)(55016002)(59450400001)(6306002)(54896002)(86362001)(6506007)(26005)(74316002)(6116002)(2201001)(80792005)(186003)(3846002)(9686003)(7736002)(790700001)(97736004)(77096007)(229853002)(2501003)(2906002)(53546011)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB2296; 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) x-microsoft-antispam-message-info: +McHX0GvENF36/8gjjGvIkIRSd8j8DiIpKnyzdqBZPtv8MzssATMom0gb4cGNHgkI4EAO27hIAErNgDA8bHxdw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB178874C4F402C0B7BA5F9E67EACB0DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 94a498e5-da83-4963-fddb-08d575264a18 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2018 10:16:05.3902 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB2296 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 <6223> : inlines <6404> : streams <1779136> : uri <2593805> Archived-At: Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction 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, 16 Feb 2018 10:16:47 -0000 --_000_DM5PR16MB178874C4F402C0B7BA5F9E67EACB0DM5PR16MB1788namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Friday, February 16, 2018 3:27 PM To: Konda, Tirumaleswar Reddy ; mohamed= .boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] draft-ietf-dots-data-channel: Filter Direction I understand the concept of call home - which makes good sense to me and rf= c8071 will, if implemented, handle the data channel and "destination" is st= ill where the 'controlled' traffic is flowing to. [TR] Yes. However, we also need call home in the signal channel. I'm not sure how th= is will be done - do we need a new CoAP Method (e.g. switch roles) - do we = need to define a different port (rfc8071 defines 4336) etc. [TR] For the discussed use case, the CPE needs to act as a DOTS server only= for the data channel but not for the signal channel, I mean what is the us= e case for the call home in the signal channel ?. -Tiru Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 16 February 2018 09:07 To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 2:19 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: draft-ietf-dots-data-channel: Filter Direction Re-, Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 16 f=E9vrier 2018 09:28 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] draft-ietf-dots-data-channel: Filter Direction There is no ambiguity in the roles. The CPE is acting as DOTS server but th= e DOTS server is initiating connection to the DOTS client in the access net= work. [Med] Don't get the last part. The server (CPE) will receive a request from= the network (client) to filter traffic exiting from that CPE. [TR] I mean to use the call home feature discussed in https://tools.ietf.or= g/html/rfc8071, though the CPE is acting as a DOTS server it will initiate = the connection (TLS or DTLS) to the DOTS client in the access network. The = call home feature helps avoid various threats like the DOTS server in the C= PE will not be subjected to DDoS attacks, and reachability is not problem e= ven if the CPE is behind NAT. The DOTS client will convey the black-list filtering in the "out" direction= to block the traffic originating from the DOTS server domain. [Med] Which corresponds to the "DOTS Server to DOTS Client" direction; that= is the DOTS client domain (access network) is the destination. All is fine= so far :) [TR] The direction is "outgoing traffic" whereas for other use cases the di= rection is "incoming traffic". I don't understand what you mean by a "optional" parameter ? [Med] I meant adding a parameter to indicate explicitly the direction. It w= ould be optional because we do already have a default direction. [TR] Okay. -Tiru -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Friday, February 16, 2018 1:24 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction Hi Tiru, There will be an ambiguity in interpreting filters if and only if the same = DOTS agents have to manipulate filters in both directions. As you rightfully mentioned, the bb use case assumes the following: In order to achieve this capability, the telemetry analysis system utilized by the broadband access provider must have DOTS client functionality, and the end-customer CPE devices must have DOTS server functionality. Which means that there is no ambiguity in that case with the current defaul= t direction: "the destination is the DOTS client domain". No matter how roles were negotiated, but as far as each an agent acts as a = client and its peer as a server, things are clear. Of course we can always define an optional parameter for this, but it is pr= eferable to have a case for it. Cheers, Med De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] Envoy=E9 : jeudi 15 f=E9vrier 2018 16:31 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: draft-ietf-dots-data-channel: Filter Direction The filtering rule for outgoing traffic is required for the "Suppression of= outbound DDoS traffic originating from a consumer broadband access network= " use case discussed in https://tools.ietf.org/html/draft-ietf-dots-use-cas= es-09#section-3.2.1. In this use case, the CPE initially acts as a DOTS cli= ent but after the TCP connection is established, reverses its role and acts= as DOTS server (see https://tools.ietf.org/html/rfc8071). The access netwo= rk can then program the CPE using the DOTS data channel to block the DDoS a= ttack traffic originated from the compromised devices in the local customer network. Cheers, -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Wednesday, February 14, 2018 1:49 PM To: dots@ietf.org Subject: [Dots] draft-ietf-dots-data-channel: Filter Direction Hi all, As agreed during the interim, there are some issues that need fixes in the = data-channel spec. We would like to hear from the WG to know what to record= in the document. Issue description: Do we need to support explicit "direction" in filtering = rules ("in"/"out")? That is, do we allow a DOTS client to create filters fo= r both incoming and outgoing traffic? Below a proposal for discussion: - The current default direction is aligned with the nature of DDoS attac= ks targeted by DOTS: i.e. incoming. The DOTS client domain is assumed to be= the destination. No ambiguity so far with such default behavior. - There is no clear use case for the support of outgoing filtering handl= ing in the context of DOTS. - No text change is required to the draft. Any objection? Cheers, Med --_000_DM5PR16MB178874C4F402C0B7BA5F9E67EACB0DM5PR16MB1788namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

From:<= /span> Jon Shallow [mailto:s= upjps-ietf@jpshallow.com]
Sent: Friday, February 16, 2018 3:27 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; mohamed.boucadair@orange.com; dots@ietf.org
Subject: RE: [Dots] draft-ietf-dots-data-channel: Filter Direction

 

I under= stand the concept of call home – which makes good sense to me and rfc= 8071 will, if implemented, handle the data channel and “destination&#= 8221; is still where the ‘controlled’ traffic is flowing to.

 

[TR] Yes.

&n= bsp;

However= , we also need call home in the signal channel.  I’m not sure ho= w this will be done – do we need a new CoAP Method (e.g. switch roles= ) – do we need to define a different port (rfc8071 defines 4336) etc.

 

[TR] For the discussed use case= , the CPE needs to act as a DOTS server only for the data channel but not f= or the signal channel, I mean what is the use case for the call home in the= signal channel ?.

 

-Tiru

 

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 16 February 2018 09:07
To: mohamed.boucadai= r@orange.com; dots@ietf.org
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction

 

From:<= /span> mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Friday, February 16, 2018 2:19 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: RE: draft-ietf-dots-data-channel: Filter Direction

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : vendredi 16 f=E9vrier 2018 09:28
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : Re: [Dots] draft-ietf-dots-data-channel: Filter Directi= on

 

There is = no ambiguity in the roles. The CPE is acting as DOTS server but the DOTS se= rver is initiating connection to the DOTS client in the access network.

[Med] Don’t g= et the last part. The server (CPE) will receive a request from the network = (client) to filter traffic exiting from that CPE.

&nbs= p;

[TR] I me= an to use the call home feature discussed in https://tools.ietf.org/html= /rfc8071, though the CPE is acting as a DOTS server it will initiate th= e connection (TLS or DTLS) to the DOTS client in the access network. The ca= ll home feature helps avoid various threats like the DOTS server in the CPE will not be subjected to DDoS atta= cks, and reachability is not problem even if the CPE is behind NAT.

 

The DOTS = client will convey the black-list filtering in the “out” direct= ion to block the traffic originating from the DOTS server domain.

[Med] Which corresp= onds to the “DOTS Server to DOTS Client” direction; that is the= DOTS client domain (access network) is the destination. All is fine so far :)

&nbs= p;

&nbs= p;

[TR] The = direction is “outgoing traffic” whereas for other use cases the= direction is “incoming traffic”.

 

I donR= 17;t understand what you mean by a “optional” parameter ?<= /o:p>

[Med] I meant addin= g a parameter to indicate explicitly the direction. It would be optional be= cause we do already have a default direction.

&nbs= p;

[TR] Okay= .

&nbs= p;

-Tiru

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed= .boucadair@orange.com
Sent: Friday, February 16, 2018 1:24 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction

 

Hi Tiru,

 

There will be an ambiguity in interpreting fil= ters if and only if the same DOTS agents have to manipulate filters in both= directions.

 

As you rightfully mentioned, the bb use case a= ssumes the following:

 

   In order to achieve t= his capability, the telemetry analysis system

   utilized by the broad= band access provider must have DOTS client

   functionality, and th= e end-customer CPE devices must have DOTS server

   functionality.

 

Which means that there is no ambiguity in that= case with the current default direction: “the destination is the DOT= S client domain”.

 

No matter how roles were negotiated, but=
 as far as each an agent acts as a client and its peer as a server, things =
are clear. 
 
Of course we can always define an option=
al parameter for this, but it is preferable to have a case for it.  
 
Cheers,
Med

 

De : Konda, Tirumaleswar Reddy [mailto:Tirumaleswar= Reddy_Konda@McAfee.com]
Envoy=E9 : jeudi 15 f=E9vrier 2018 16:31
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: draft-ietf-dots-data-channel: Filter Direction=

 

The filte= ring rule for outgoing traffic is required for the "Suppression of out= bound DDoS traffic originating from a consumer broadband access network&quo= t; use case discussed in https://tools.ietf.org/html/draft-ietf-dots-use-cases-09#section-3.2.1.= In this use case, the CPE initially acts as a DOTS client but after the TC= P connection is established, reverses its role and acts as DOTS server (see https://tools.ietf.org/html= /rfc8071). The access network can then program the CPE using the DOTS d= ata channel to block the DDoS attack traffic originated from the compromise= d devices in the

local cus= tomer network.

&nbs= p;

Cheers,

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed= .boucadair@orange.com
Sent: Wednesday, February 14, 2018 1:49 PM
To: dots@ietf.org
Subject: [Dots] draft-ietf-dots-data-channel: Filter Direction<= /o:p>

 

Hi all,

 

As agreed during the interim, there are some issues that n= eed fixes in the data-channel spec. We would like to hear from the WG to kn= ow what to record in the document.

 

Issue description: Do we need to support explicit “d= irection” in filtering rules (“in”/“out”)? Th= at is, do we allow a DOTS client to create filters for both incoming and ou= tgoing traffic?

 

Below a proposal for discussion:

– = ;   The current default direction is aligned with the nature of DDoS attacks t= argeted by DOTS: i.e. incoming. The DOTS client domain is assumed to be the= destination. No ambiguity so far with such default behavior.

– = ;   There is no clear use case for the support of outgoing filtering handling = in the context of DOTS.

– = ;   No text change is required to the draft.

 <= /p>

Any objection?

 <= /p>

Cheers,=

Med

 

--_000_DM5PR16MB178874C4F402C0B7BA5F9E67EACB0DM5PR16MB1788namp_-- From nobody Fri Feb 16 02:19:03 2018 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 86E5C1242F7 for ; Fri, 16 Feb 2018 02:19:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.33 X-Spam-Level: X-Spam-Status: No, score=-4.33 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 cjlmwoMNvQ0k for ; Fri, 16 Feb 2018 02:18:57 -0800 (PST) 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 DAA9312D870 for ; Fri, 16 Feb 2018 02:18:56 -0800 (PST) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1518776331; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=A hYYUNfXQOfJBQMgwfpcyKm4hHk4ieCjpro2ABxg6k w=; b=oKnFc1VpBT7w+Zlza54Dfdx4J8RFcgl/UGQPgYMtrCsr D4oPJF+YqQTAkYCj9uW2+KoMsdMPDjD/9cK/AwC28iK9LXw+X4 5tsPgQB7K4xMQsjHiiT8wtcgGwKcNYptzL6W5JxLTbRHWCK7kX C67Mm1ppGt9yGnb8CXVdFvq+6Vg= Received: from DNVEXAPP1N05.corpzone.internalzone.com (DNVEXAPP1N05.corpzone.internalzone.com [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 40da_1096_5e8f7aad_05ae_42fd_8f81_f28a89d4fade; Fri, 16 Feb 2018 04:18:51 -0600 Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 16 Feb 2018 03:17:37 -0700 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Fri, 16 Feb 2018 03:17:37 -0700 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (10.44.176.241) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 16 Feb 2018 03:17:37 -0700 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB2296.namprd16.prod.outlook.com (52.132.142.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.18; Fri, 16 Feb 2018 10:17:36 +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.20.0485.015; Fri, 16 Feb 2018 10:17:36 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: draft-ietf-dots-data-channel: Filtering Fields Thread-Index: AdOlbICGgF2MxoHnQied7J+cvW2QAABhQcigAAKnFWAAAuyKQA== Date: Fri, 16 Feb 2018 10:17:36 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A0D1F93@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0D32AE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A0D32AE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action 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; DM5PR16MB2296; 7:IYmvkyr3Pdg2UyN389v4eKiAtPce6onK9b/51eM4iS7sE2N48/q5bgwuKZDdwdDswgcgK3lc2sdUD/CllIPm/Li6ww/Dq4xB5f3WAWi1QGIuyN+e7ygqMKbHKFhUbSLBSmi3feGgMOzaa6N9E8bpa6ZuBoW9yqFE4M7aJG/GdFgVsnlL15jUG//5nzAbWJPkjSvoltjRZIK3FCdl6ga4BvCFCe/wec38tWUbaY27JFzskHnA7Uvn9LcYoIP2ZO3u x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: bb80ef8b-f99a-48fc-596f-08d57526806e x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:DM5PR16MB2296; x-ms-traffictypediagnostic: DM5PR16MB2296: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(18271650672692)(21748063052155)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(3231101)(944501161)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123560045)(20161123562045)(6072148)(201708071742011); SRVR:DM5PR16MB2296; BCL:0; PCL:0; RULEID:; SRVR:DM5PR16MB2296; x-forefront-prvs: 0585417D7B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(376002)(39380400002)(396003)(366004)(32952001)(53754006)(57704003)(199004)(189003)(81166006)(33656002)(8676002)(106356001)(6246003)(8936002)(7696005)(19609705001)(5660300001)(99286004)(9326002)(316002)(2900100001)(81156014)(105586002)(606006)(66066001)(478600001)(102836004)(3660700001)(110136005)(14454004)(3280700002)(966005)(72206003)(236005)(68736007)(76176011)(25786009)(53936002)(6436002)(2950100002)(55016002)(6306002)(54896002)(86362001)(6506007)(26005)(74316002)(6116002)(80792005)(186003)(3846002)(9686003)(7736002)(790700001)(97736004)(77096007)(229853002)(2501003)(2906002)(53546011)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB2296; 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) x-microsoft-antispam-message-info: iJhuUSvycOdVPIb+E+WWgyJ2sPUrWwFQb3ADvfdtsqRqbvsB72C2MAVnC0WK7NxoGvKXm3CMQQ58zu6R7Vysqg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB17883E4F6B4F5C1982C5B2C8EACB0DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: bb80ef8b-f99a-48fc-596f-08d57526806e X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2018 10:17:36.5309 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB2296 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 <6223> : inlines <6404> : streams <1779136> : uri <2593805> Archived-At: Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields 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, 16 Feb 2018 10:19:02 -0000 --_000_DM5PR16MB17883E4F6B4F5C1982C5B2C8EACB0DM5PR16MB1788namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Med, Please see inline [TR2] From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 1:45 PM To: Konda, Tirumaleswar Reddy ; dots@ie= tf.org Subject: RE: draft-ietf-dots-data-channel: Filtering Fields Re-, Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 16 f=E9vrier 2018 08:00 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Wednesday, February 14, 2018 1:49 PM To: dots@ietf.org Subject: [Dots] draft-ietf-dots-data-channel: Filtering Fields Hi all, As agreed during the interim, there are some issues that need fixes in the = data-channel spec. We would like to hear from the WG to know what to record= in the document. Issue description: Should we support all of the match fields defined by "ie= tf-packet-fields" or do we need to define a minimum supported set? [TR] I don't see the need to support all the match fields, define a minimum= supported set (don't see the use for acl-eth-header-fields for DOTS use ca= ses). [Med] Agree that acl-eth-header-fields aren't required. The text is already= clear about this: DOTS implementations MUST support the following matching criteria: match based on the IP header (IPv4 and IPv6), match based on the transport header (TCP, UDP, and ICMP), and any combination thereof. The question is whether we need to go further and mandate (or not) the supp= ort of matching based on specific fields: dscp, ecn, ttl,... flow-label, ..= . tcp sequence-number, tcp flags, ... [TR2] https://tools.ietf.org/html/draft-ietf-netmod-acl-model-16 uses the f= eature statements in the YANG model allowing vendors to advertise match rul= es they are capable and willing to support but not at the field-level. The = problem is router implementations today don't support ACLs with tcp sequenc= e-number, acknowledgement-number, window-size etc but support TCP flags. If= the server could convey the list of match criteria supported, it not only = allows the client to convey the supported match rules but also allows the s= erver in future to advertise the new supported match fields. Would it be useful for a client to retrieve the list of match criteria supp= orted by a DOTS server? [TR2] Yes. -Tiru [TR] The YANG model supported by the DOTS server can retrieved by the DOTS = client using RESTCONF to determine the match criteria supported by the serv= er. [Med] I'm afraid this is not the same functionality. If we need to allow a = server to return its supported match criteria, this should be allowed by th= e module. For example, the module may include the following (example): +--ro capabilities | +--ro match-header* | | identityref | +--ro transport-protocols* [protocol-id] | | +--ro protocol-id uint8 | | +--ro protocol-name? string | +--ro dscp-support? boolean | +--ro ecn-support? boolean | +--ro length-support? boolean | +--ro ttl-support? boolean | +--ro protocol-support? boolean The client can ask the server to return its supported match criteria. The s= erver will indicate the exact set of fields it supports. I'm not expressing a preference to have this in the model, but I'm clarifyi= ng how it would look like. -Tiru Please comment. Cheers, Med --_000_DM5PR16MB17883E4F6B4F5C1982C5B2C8EACB0DM5PR16MB1788namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Med,

&nbs= p;

Please se= e inline [TR2]

 

From:<= /span> mohamed.boucadair@ora= nge.com [mailto:mohamed.boucadair@orange.com]
Sent: Friday, February 16, 2018 1:45 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org
Subject: RE: draft-ietf-dots-data-channel: Filtering Fields

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : vendredi 16 f=E9vrier 2018 08:00
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fiel= ds

 

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed= .boucadair@orange.com
Sent: Wednesday, February 14, 2018 1:49 PM
To: dots@ietf.org
Subject: [Dots] draft-ietf-dots-data-channel: Filtering Fields<= /o:p>

 

Hi all,

 

As agreed during the interim, there are some issues that n= eed fixes in the data-channel spec. We would like to hear from the WG to kn= ow what to record in the document.

 

Issue description: Should we support all of the match fiel= ds defined by “ietf-packet-fields” or do we need to define a mi= nimum supported set?

 

[TR] I don’t see the need to support all the m= atch fields, define a minimum supported set (don’t see the use for ac= l-eth-header-fields for DOTS use cases).  

[Med] Agree that acl-eth-header-fields aren= 217;t required. The text is already clear about this:

 

DOTS implementations MUST support = the following

   matching criteria: ma= tch based on the IP header (IPv4 and IPv6),

   match based on the tr= ansport header (TCP, UDP, and ICMP), and any

   combination thereof.=

 

The question is whether we need to go furt=
her and mandate (or not) the support of matching based on specific fields: =
dscp, ecn, ttl,… flow-label, … tcp sequence-number, tcp =
flags, …  
 
[TR2] https://tools.ietf.org/=
html/draft-ietf-netmod-acl-model-16 uses the feature sta=
tements in the YANG model allowing vendors to advertise match rules they ar=
e capable and willing to support but not at the field-level. The problem is=
 router implementations today don’t support ACLs with tcp sequence-nu=
mber, acknowledgement-number, window-size etc but support TCP flags. If the=
 server could convey the list of match criteria supported, it not only allo=
ws the client to convey the supported match rules but also allows the serve=
r in future to advertise the new supported match fields.   <=
/o:p>

 

Would it be useful for a client to retrieve the list of ma= tch criteria supported by a DOTS server?

 

[TR2] Yes.

 

-Tiru

 

[TR] The YANG model supported by the DOTS server can= retrieved by the DOTS client using RESTCONF to determine the match criteri= a supported by the server.

[Med] I’m afraid this is not the same fu= nctionality. If we need to allow a server to return its supported match cri= teria, this should be allowed by the module. For example, the module may include the following (example):

 

           &nbs=
p;    +--ro capabilities
           &nbs=
p;    |  +--ro match-header*
           &nbs=
p;    |  |       identity=
ref
           &nbs=
p;    |  +--ro transport-protocols* [protocol-id]
           &nbs=
p;    |  |  +--ro protocol-id   =
;   uint8
           &nbs=
p;    |  |  +--ro protocol-name?   s=
tring
           &nbs=
p;    |  +--ro dscp-support?    &nbs=
p;  boolean
           &nbs=
p;    |  +--ro ecn-support?     =
;   boolean
           &nbs=
p;    |  +--ro length-support?    &n=
bsp;boolean
           &nbs=
p;    |  +--ro ttl-support?     =
;   boolean
           &nbs=
p;    |  +--ro protocol-support?   boolea=
n
 
The client can ask the server to return its supported match criteria. The server will indicate the exact set of field=
s it supports. 
 
I’m not expressing a preference to h=
ave this in the model, but I’m clarifying how it would look like.

 

-Tiru

 

Please comment.

 <= /p>

Cheers,=

Med

--_000_DM5PR16MB17883E4F6B4F5C1982C5B2C8EACB0DM5PR16MB1788namp_-- From nobody Fri Feb 16 02:19:08 2018 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 D946712D880 for ; Fri, 16 Feb 2018 02:19:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 UIAsX1Mw-qhC for ; Fri, 16 Feb 2018 02:19:02 -0800 (PST) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0760212D873 for ; Fri, 16 Feb 2018 02:19:00 -0800 (PST) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id CE714C05F6; Fri, 16 Feb 2018 11:18:58 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.3]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id B2CC91A0065; Fri, 16 Feb 2018 11:18:58 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5D.corporate.adroot.infra.ftgroup ([fe80::9898:741c:bc1d:258d%19]) with mapi id 14.03.0382.000; Fri, 16 Feb 2018 11:18:58 +0100 From: To: Jon Shallow , "'Konda, Tirumaleswar Reddy'" , "dots@ietf.org" Thread-Topic: Call home in the signal channel (was RE: [Dots] draft-ietf-dots-data-channel: Filter Direction) Thread-Index: AdOnD40ix0FBs+3eR3Kr9ibwuvod3g== Date: Fri, 16 Feb 2018 10:18:57 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0D3439@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A0D3439OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: [Dots] Call home in the signal channel (was RE: draft-ietf-dots-data-channel: Filter Direction) 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, 16 Feb 2018 10:19:05 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A0D3439OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jon, I'm changing the title to keep track of signal-channel specific issues. Please use this one to discuss this use case. Thank you. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 16 f=E9vrier 2018 10:57 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: [Dots] draft-ietf-dots-data-channel: Filter Direction I understand the concept of call home - which makes good sense to me and rf= c8071 will, if implemented, handle the data channel and "destination" is st= ill where the 'controlled' traffic is flowing to. However, we also need call home in the signal channel. I'm not sure how th= is will be done - do we need a new CoAP Method (e.g. switch roles) - do we = need to define a different port (rfc8071 defines 4336) etc. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 16 February 2018 09:07 To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 2:19 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: draft-ietf-dots-data-channel: Filter Direction Re-, Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 16 f=E9vrier 2018 09:28 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] draft-ietf-dots-data-channel: Filter Direction There is no ambiguity in the roles. The CPE is acting as DOTS server but th= e DOTS server is initiating connection to the DOTS client in the access net= work. [Med] Don't get the last part. The server (CPE) will receive a request from= the network (client) to filter traffic exiting from that CPE. [TR] I mean to use the call home feature discussed in https://tools.ietf.or= g/html/rfc8071, though the CPE is acting as a DOTS server it will initiate = the connection (TLS or DTLS) to the DOTS client in the access network. The = call home feature helps avoid various threats like the DOTS server in the C= PE will not be subjected to DDoS attacks, and reachability is not problem e= ven if the CPE is behind NAT. The DOTS client will convey the black-list filtering in the "out" direction= to block the traffic originating from the DOTS server domain. [Med] Which corresponds to the "DOTS Server to DOTS Client" direction; that= is the DOTS client domain (access network) is the destination. All is fine= so far :) [TR] The direction is "outgoing traffic" whereas for other use cases the di= rection is "incoming traffic". I don't understand what you mean by a "optional" parameter ? [Med] I meant adding a parameter to indicate explicitly the direction. It w= ould be optional because we do already have a default direction. [TR] Okay. -Tiru -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Friday, February 16, 2018 1:24 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction Hi Tiru, There will be an ambiguity in interpreting filters if and only if the same = DOTS agents have to manipulate filters in both directions. As you rightfully mentioned, the bb use case assumes the following: In order to achieve this capability, the telemetry analysis system utilized by the broadband access provider must have DOTS client functionality, and the end-customer CPE devices must have DOTS server functionality. Which means that there is no ambiguity in that case with the current defaul= t direction: "the destination is the DOTS client domain". No matter how roles were negotiated, but as far as each an agent acts as a = client and its peer as a server, things are clear. Of course we can always define an optional parameter for this, but it is pr= eferable to have a case for it. Cheers, Med De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] Envoy=E9 : jeudi 15 f=E9vrier 2018 16:31 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: draft-ietf-dots-data-channel: Filter Direction The filtering rule for outgoing traffic is required for the "Suppression of= outbound DDoS traffic originating from a consumer broadband access network= " use case discussed in https://tools.ietf.org/html/draft-ietf-dots-use-cas= es-09#section-3.2.1. In this use case, the CPE initially acts as a DOTS cli= ent but after the TCP connection is established, reverses its role and acts= as DOTS server (see https://tools.ietf.org/html/rfc8071). The access netwo= rk can then program the CPE using the DOTS data channel to block the DDoS a= ttack traffic originated from the compromised devices in the local customer network. Cheers, -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Wednesday, February 14, 2018 1:49 PM To: dots@ietf.org Subject: [Dots] draft-ietf-dots-data-channel: Filter Direction Hi all, As agreed during the interim, there are some issues that need fixes in the = data-channel spec. We would like to hear from the WG to know what to record= in the document. Issue description: Do we need to support explicit "direction" in filtering = rules ("in"/"out")? That is, do we allow a DOTS client to create filters fo= r both incoming and outgoing traffic? Below a proposal for discussion: - The current default direction is aligned with the nature of DDoS attac= ks targeted by DOTS: i.e. incoming. The DOTS client domain is assumed to be= the destination. No ambiguity so far with such default behavior. - There is no clear use case for the support of outgoing filtering handl= ing in the context of DOTS. - No text change is required to the draft. Any objection? Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300A0D3439OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jon,

 

I’m changing the title to= keep track of signal-channel specific issues.

 

Please use this one to discuss = this use case.

 

Thank you.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf= @jpshallow.com]
Envoy=E9 : vendredi 16 f=E9vrier 2018 10:57
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; d= ots@ietf.org
Objet : RE: [Dots] draft-ietf-dots-data-channel: Filter Directi= on

 

I under= stand the concept of call home – which makes good sense to me and rfc= 8071 will, if implemented, handle the data channel and “destination&#= 8221; is still where the ‘controlled’ traffic is flowing to.

&n= bsp;

However= , we also need call home in the signal channel.  I’m not sure ho= w this will be done – do we need a new CoAP Method (e.g. switch roles= ) – do we need to define a different port (rfc8071 defines 4336) etc.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 16 February 2018 09:07
To: mohamed.boucadai= r@orange.com; dots@ietf.org
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction

 

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Friday, February 16, 2018 2:19 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: RE: draft-ietf-dots-data-channel: Filter Direction

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : vendredi 16 f=E9vrier 2018 09:28
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : Re: [Dots] draft-ietf-dots-data-channel: Filter Directi= on

 

There is no ambiguity in the roles. The CPE is acting as DOTS server = but the DOTS server is initiating connection to the DOTS client in the acce= ss network.

[Med= ] Don’t get the last part. The server (CPE) will receive a request fr= om the network (client) to filter traffic exiting from that CPE.

 

[TR] I mean to use the call home feature discussed in https://tools.ietf.org/html= /rfc8071, though the CPE is acting as a DOTS server it will initiate th= e connection (TLS or DTLS) to the DOTS client in the access network. The ca= ll home feature helps avoid various threats like the DOTS server in the CPE will not be subjected to DDoS atta= cks, and reachability is not problem even if the CPE is behind NAT.

 

The DOTS client will convey the black-list filtering in the “ou= t” direction to block the traffic originating from the DOTS server do= main.

[Med= ] Which corresponds to the “DOTS Server to DOTS Client” directi= on; that is the DOTS client domain (access network) is the destination. All is fine so far :)

 

 

[TR] The direction is “outgoing traffic” whereas for othe= r use cases the direction is “incoming traffic”.

 

I don’t understand what you mean by a “optional” pa= rameter ?

[Med= ] I meant adding a parameter to indicate explicitly the direction. It would= be optional because we do already have a default direction.

 

[TR] Okay.

 

-Tiru

 

-Tiru

 

From: Dots [mailto:dots-bounces= @ietf.org] On Behalf Of mohamed= .boucadair@orange.com
Sent: Friday, February 16, 2018 1:24 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction

 

Hi Tiru,

 

There will be an ambiguity in i= nterpreting filters if and only if the same DOTS agents have to manipulate = filters in both directions.

 

As you rightfully mentioned, th= e bb use case assumes the following:

 

   In ord= er to achieve this capability, the telemetry analysis system

   utiliz= ed by the broadband access provider must have DOTS client=

   functi= onality, and the end-customer CPE devices must have DOTS server<= /span>

   functionality.

 

Which means that there is no am= biguity in that case with the current default direction: “the destina= tion is the DOTS client domain”.

 

No matter how roles were =
negotiated, but as far as each an agent acts as a client and its peer as a =
server, things are clear. 
 <=
/pre>

Of course we can always d=
efine an optional parameter for this, but it is preferable to have a case f=
or it.  


 <=
/pre>

Cheers,=



Med

 








De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_=
Konda@McAfee.com]


Envoy=E9 : jeudi 15 f=E9vrier 2018 16:31

=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org

Objet : RE: draft-ietf-dots-data-channel: Filter Direction=







 


The filtering rule for outgoing traffic is required for the "Sup=
pression of outbound DDoS traffic originating from a consumer broadband acc=
ess network" use case discussed in

https://tools.ietf.org/html/draft-ietf-dots-use-cases-09#section-3.2.1.=
 In this use case, the CPE initially acts as a DOTS client but after the TC=
P connection is established, reverses its role and acts as DOTS server (see
https://tools.ietf.org/html=
/rfc8071). The access network can then program the CPE using the DOTS d=
ata channel to block the DDoS attack traffic originated from the compromise=
d devices in the



local customer network.



 


Cheers,


-Tiru


 








From: Dots [mailto:dots-bounces=
@ietf.org]
On Behalf Of mohamed=
.boucadair@orange.com

Sent: Wednesday, February 14, 2018 1:49 PM

To: dots@ietf.org

Subject: [Dots] draft-ietf-dots-data-channel: Filter Direction<=
/o:p>






 


Hi all,



 


As agreed during the interim, there are som=
e issues that need fixes in the data-channel spec. We would like to hear fr=
om the WG to know what to record in the document.



 


Issue description: Do we need to support ex=
plicit “direction” in filtering rules (“in”/“=
out”)? That is, do we allow a DOTS client to create filters for both =
incoming
 and outgoing traffic? 


 


Below a proposal for discussion:=



–=
;   
The current default direction is aligned with the nature of=
 DDoS attacks targeted by DOTS: i.e. incoming. The DOTS client domain is as=
sumed to be the destination. No ambiguity so far
 with such default behavior. 


–=
;   
There is no clear use case for the support of outgoing filt=
ering handling in the context of DOTS.


–=
;   
No text change is required to the draft.<=
/p>

 =
;


Any object=
ion?



 =
;


Cheers,


Med



 
--_000_787AE7BB302AE849A7480A190F8B93300A0D3439OPEXCLILMA3corp_-- From nobody Fri Feb 16 02:25:36 2018 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 CADF7126C19 for ; Fri, 16 Feb 2018 02:25:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 O2-R05NVmXA8 for ; Fri, 16 Feb 2018 02:25:32 -0800 (PST) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 A4D211242F7 for ; Fri, 16 Feb 2018 02:25:31 -0800 (PST) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1518776730; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:x-originating-ip: x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:authentication-results: x-microsoft-antispam-message-info:spamdiagnosticoutput: spamdiagnosticmetadata:Content-Type:MIME-Version: X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=TWCdzApymVTQ+Ze/W82O3sVJToF9hysGtSdEPF SHxFU=; b=H8osgMHu6vfc9J3IsDQsnZeFdawwgFzPi3pSTK1a wJfaT3PxBHKJgwNOs6oSBc2qLQ+S8b8jz3qpxuqGMOqTpekrY/ znsVye9Zyk7gElK1ZGN/53lX9gjmIgozVDGRZMy35dWW3dJ6hl 8xG0iIt5I1PG9AssqHabhOlf1wMEJN0= Received: from MIVEXAPP1N02.corpzone.internalzone.com (unknown [10.48.48.89]) by MIVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 4a8a_7443_d99f417d_fde7_4c1b_a945_f305dd026871; Fri, 16 Feb 2018 04:25:30 -0600 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.1347.2; Fri, 16 Feb 2018 05:25:22 -0500 Received: from MIVEX10N02.corpzone.internalzone.com (10.48.48.170) by MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Fri, 16 Feb 2018 05:25:22 -0500 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.361.1; Fri, 16 Feb 2018 05:25:23 -0500 Received: from NAM02-BL2-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.1347.2; Fri, 16 Feb 2018 05:25:20 -0500 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1852.namprd16.prod.outlook.com (10.172.45.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.464.11; Fri, 16 Feb 2018 10:25:20 +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.20.0485.015; Fri, 16 Feb 2018 10:25:20 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: draft-ietf-dots-data-channel: Filter Direction Thread-Index: AdOlbGwqi1N7Z468TzqkpTeHXPf9AQBBCWQgACITfVAAAZZfcAAAttzQAABGxtAAAo6C4AAAfT7g Date: Fri, 16 Feb 2018 10:25:20 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A0D1F7C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0D327F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0D3331@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0D3409@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A0D3409@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1852; 7:bFxW4Adkw7//UH14CkahPTfCjUnq+2L8m2+b8vWdXXytGzzsWxeQbhd9rmY//7pvlqotrI/r48Xoe6E7tmIJNnXHKtK8Ui2S+6g5R3D/D+AOdqJshy8jfkNtSgoosOPqQmgSKD8rHi1XlC9R+MjH+zKn08U9IgA4RCOEKZ5WQzJw1q3Qu6hU4TahJ1XOa+VgIaw9LGLEc3g55q7zCxN+sjSDjpnN7A7sCLeK1wZIeHvLz6idSd0sDAiAepxXw+NY x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 0c8fa87d-33ce-46d3-ec00-08d5752794d1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM5PR16MB1852; x-ms-traffictypediagnostic: DM5PR16MB1852: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(18271650672692)(21748063052155)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001037)(6040501)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(3231101)(2400082)(944501161)(10201501046)(6041288)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(6072148)(201708071742011); SRVR:DM5PR16MB1852; BCL:0; PCL:0; RULEID:; SRVR:DM5PR16MB1852; x-forefront-prvs: 0585417D7B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(39380400002)(376002)(346002)(39860400002)(189003)(57704003)(199004)(32952001)(53754006)(72206003)(26005)(6346003)(8676002)(186003)(99286004)(76176011)(102836004)(105586002)(66066001)(59450400001)(25786009)(8936002)(229853002)(6506007)(53936002)(110136005)(81156014)(86362001)(81166006)(2501003)(19609705001)(2906002)(6116002)(3280700002)(236005)(54896002)(561944003)(2900100001)(9686003)(6306002)(966005)(80792005)(6436002)(5660300001)(316002)(77096007)(3846002)(74316002)(790700001)(97736004)(7696005)(7736002)(606006)(93886005)(14454004)(33656002)(53546011)(55016002)(68736007)(106356001)(6246003)(2950100002)(3660700001)(478600001)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1852; 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) authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-microsoft-antispam-message-info: qu4QC3qniwqz07dPM8gf9lZYKZb3NZGr9UWMCJ+n+W/7l9K6yc1EDd0lu7EkXoI6jMNZEGaZHVrKtTsl6a+ikg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1788C6199AD3C480095829F9EACB0DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 0c8fa87d-33ce-46d3-ec00-08d5752794d1 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2018 10:25:20.2190 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1852 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 <6223> : inlines <6404> : streams <1779136> : uri <2593808> Archived-At: Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction 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, 16 Feb 2018 10:25:35 -0000 --_000_DM5PR16MB1788C6199AD3C480095829F9EACB0DM5PR16MB1788namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Please see inline [TR2] From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 3:39 PM To: Konda, Tirumaleswar Reddy ; dots@ie= tf.org Subject: RE: draft-ietf-dots-data-channel: Filter Direction Re-, Please see inline. Cheers, Med De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] Envoy=E9 : vendredi 16 f=E9vrier 2018 10:07 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: draft-ietf-dots-data-channel: Filter Direction From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 2:19 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: draft-ietf-dots-data-channel: Filter Direction Re-, Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 16 f=E9vrier 2018 09:28 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] draft-ietf-dots-data-channel: Filter Direction There is no ambiguity in the roles. The CPE is acting as DOTS server but th= e DOTS server is initiating connection to the DOTS client in the access net= work. [Med] Don't get the last part. The server (CPE) will receive a request from= the network (client) to filter traffic exiting from that CPE. [TR] I mean to use the call home feature discussed in https://tools.ietf.or= g/html/rfc8071, though the CPE is acting as a DOTS server it will initiate = the connection (TLS or DTLS) to the DOTS client in the access network. The = call home feature helps avoid various threats like the DOTS server in the C= PE will not be subjected to DDoS attacks, and reachability is not problem e= ven if the CPE is behind NAT. [Med] OK. The DOTS client will convey the black-list filtering in the "out" direction= to block the traffic originating from the DOTS server domain. [Med] Which corresponds to the "DOTS Server to DOTS Client" direction; that= is the DOTS client domain (access network) is the destination. All is fine= so far :) [TR] The direction is "outgoing traffic" whereas for other use cases the di= rection is "incoming traffic". [Med] Tiru, the direction in both cases is always the same: "DOTS Server to= DOTS Client". Of course, from the perspective of the CPE (not the DOTS age= nt role), this will be "out" or "in" depending on the DOTS agent role on th= e CPE, but this is not important to determine the direction of the filters;= only DOTS roles matter. [TR2] The device on which ACL gets enforced need not be co-located with the= DOTS agent, the policy enforcement point (either CPE or DDoS mitigator) wh= ere the ACL is installed either sees an incoming attack or outgoing attack.= The optional parameter should specify this direction. I don't see the valu= e add the new parameter provides by just saying the attack traffic destinat= ion is from the "DOTS server to DOTS client" or "DOTS client to DOTS serve= r" (we don't have a valid use case for the latter value). Cheers, -Tiru I don't understand what you mean by a "optional" parameter ? [Med] I meant adding a parameter to indicate explicitly the direction. It w= ould be optional because we do already have a default direction. [TR] Okay. -Tiru -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Friday, February 16, 2018 1:24 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction Hi Tiru, There will be an ambiguity in interpreting filters if and only if the same = DOTS agents have to manipulate filters in both directions. As you rightfully mentioned, the bb use case assumes the following: In order to achieve this capability, the telemetry analysis system utilized by the broadband access provider must have DOTS client functionality, and the end-customer CPE devices must have DOTS server functionality. Which means that there is no ambiguity in that case with the current defaul= t direction: "the destination is the DOTS client domain". No matter how roles were negotiated, but as far as each an agent acts as a = client and its peer as a server, things are clear. Of course we can always define an optional parameter for this, but it is pr= eferable to have a case for it. Cheers, Med De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] Envoy=E9 : jeudi 15 f=E9vrier 2018 16:31 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: draft-ietf-dots-data-channel: Filter Direction The filtering rule for outgoing traffic is required for the "Suppression of= outbound DDoS traffic originating from a consumer broadband access network= " use case discussed in https://tools.ietf.org/html/draft-ietf-dots-use-cas= es-09#section-3.2.1. In this use case, the CPE initially acts as a DOTS cli= ent but after the TCP connection is established, reverses its role and acts= as DOTS server (see https://tools.ietf.org/html/rfc8071). The access netwo= rk can then program the CPE using the DOTS data channel to block the DDoS a= ttack traffic originated from the compromised devices in the local customer network. Cheers, -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Wednesday, February 14, 2018 1:49 PM To: dots@ietf.org Subject: [Dots] draft-ietf-dots-data-channel: Filter Direction Hi all, As agreed during the interim, there are some issues that need fixes in the = data-channel spec. We would like to hear from the WG to know what to record= in the document. Issue description: Do we need to support explicit "direction" in filtering = rules ("in"/"out")? That is, do we allow a DOTS client to create filters fo= r both incoming and outgoing traffic? Below a proposal for discussion: - The current default direction is aligned with the nature of DDoS attac= ks targeted by DOTS: i.e. incoming. The DOTS client domain is assumed to be= the destination. No ambiguity so far with such default behavior. - There is no clear use case for the support of outgoing filtering handl= ing in the context of DOTS. - No text change is required to the draft. Any objection? Cheers, Med --_000_DM5PR16MB1788C6199AD3C480095829F9EACB0DM5PR16MB1788namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Please se= e inline [TR2]

 

From:<= /span> mohamed.boucadair@ora= nge.com [mailto:mohamed.boucadair@orange.com]
Sent: Friday, February 16, 2018 3:39 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org
Subject: RE: draft-ietf-dots-data-channel: Filter Direction

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Konda, Tirumaleswar Reddy [mailto:Tirumaleswar= Reddy_Konda@McAfee.com]
Envoy=E9 : vendredi 16 f=E9vrier 2018 10:07
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: draft-ietf-dots-data-channel: Filter Direction=

 

From:<= /span> mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Friday, February 16, 2018 2:19 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: RE: draft-ietf-dots-data-channel: Filter Direction

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : vendredi 16 f=E9vrier 2018 09:28
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : Re: [Dots] draft-ietf-dots-data-channel: Filter Directi= on

 

There is = no ambiguity in the roles. The CPE is acting as DOTS server but the DOTS se= rver is initiating connection to the DOTS client in the access network.

[Med] Don’t g= et the last part. The server (CPE) will receive a request from the network = (client) to filter traffic exiting from that CPE.

&nbs= p;

[TR] I me= an to use the call home feature discussed in https://tools.ietf.org/html= /rfc8071, though the CPE is acting as a DOTS server it will initiate th= e connection (TLS or DTLS) to the DOTS client in the access network. The ca= ll home feature helps avoid various threats like the DOTS server in the CPE will not be subjected to DDoS atta= cks, and reachability is not problem even if the CPE is behind NAT.

[Med] OK.

 

The DOTS = client will convey the black-list filtering in the “out” direct= ion to block the traffic originating from the DOTS server domain.

[Med] Which corresp= onds to the “DOTS Server to DOTS Client” direction; that is the= DOTS client domain (access network) is the destination. All is fine so far :)

&nbs= p;

&nbs= p;

[TR] The = direction is “outgoing traffic” whereas for other use cases the= direction is “incoming traffic”.

[Med] Tiru, the dir= ection in both cases is always the same: “DOTS Server to DOTS Client&= #8221;. Of course, from the perspective of the CPE (not the DOTS agent role), this will be “out” or “in” depen= ding on the DOTS agent role on the CPE, but this is not important to determ= ine the direction of the filters; only DOTS roles matter.=

&nbs= p;

[TR2] The= device on which ACL gets enforced need not be co-located with the DOTS age= nt, the policy enforcement point (either CPE or DDoS mitigator) where the A= CL is installed either sees an incoming attack or outgoing attack. The optional parameter should specify this dire= ction. I don’t see the value add the new parameter provides by just s= aying the attack traffic destination is from  the “DOTS server t= o DOTS client” or “DOTS client to DOTS server” (we don’t have a valid use case for the latter value).=

&nbs= p;

Cheers,

-Tiru

 

I donR= 17;t understand what you mean by a “optional” parameter ?<= /o:p>

[Med] I meant addin= g a parameter to indicate explicitly the direction. It would be optional be= cause we do already have a default direction.

&nbs= p;

[TR] Okay= .

&nbs= p;

-Tiru

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed= .boucadair@orange.com
Sent: Friday, February 16, 2018 1:24 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction

 

Hi Tiru,

 

There will be an ambiguity in interpreting fil= ters if and only if the same DOTS agents have to manipulate filters in both= directions.

 

As you rightfully mentioned, the bb use case a= ssumes the following:

 

   In order to achieve t= his capability, the telemetry analysis system

   utilized by the broad= band access provider must have DOTS client

   functionality, and th= e end-customer CPE devices must have DOTS server

   functionality.

 

Which means that there is no ambiguity in that= case with the current default direction: “the destination is the DOT= S client domain”.

 

No matter how roles were negotiated, but=
 as far as each an agent acts as a client and its peer as a server, things =
are clear. 
 
Of course we can always define an option=
al parameter for this, but it is preferable to have a case for it.  
 
Cheers,
Med

 

De : Konda, Tirumaleswar Reddy [mailto:Tirumaleswar= Reddy_Konda@McAfee.com]
Envoy=E9 : jeudi 15 f=E9vrier 2018 16:31
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: draft-ietf-dots-data-channel: Filter Direction=

 

The filte= ring rule for outgoing traffic is required for the "Suppression of out= bound DDoS traffic originating from a consumer broadband access network&quo= t; use case discussed in https://tools.ietf.org/html/draft-ietf-dots-use-cases-09#section-3.2.1.= In this use case, the CPE initially acts as a DOTS client but after the TC= P connection is established, reverses its role and acts as DOTS server (see https://tools.ietf.org/html= /rfc8071). The access network can then program the CPE using the DOTS d= ata channel to block the DDoS attack traffic originated from the compromise= d devices in the

local cus= tomer network.

&nbs= p;

Cheers,

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed= .boucadair@orange.com
Sent: Wednesday, February 14, 2018 1:49 PM
To: dots@ietf.org
Subject: [Dots] draft-ietf-dots-data-channel: Filter Direction<= /o:p>

 

Hi all,

 

As agreed during the interim, there are some issues that n= eed fixes in the data-channel spec. We would like to hear from the WG to kn= ow what to record in the document.

 

Issue description: Do we need to support explicit “d= irection” in filtering rules (“in”/“out”)? Th= at is, do we allow a DOTS client to create filters for both incoming and ou= tgoing traffic?

 

Below a proposal for discussion:

– = ;   The current default direction is aligned with the nature of DDoS attacks t= argeted by DOTS: i.e. incoming. The DOTS client domain is assumed to be the= destination. No ambiguity so far with such default behavior.

– = ;   There is no clear use case for the support of outgoing filtering handling = in the context of DOTS.

– = ;   No text change is required to the draft.

 <= /p>

Any objection?

 <= /p>

Cheers,=

Med

 

--_000_DM5PR16MB1788C6199AD3C480095829F9EACB0DM5PR16MB1788namp_-- From nobody Fri Feb 16 02:36:19 2018 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 C84A712D879 for ; Fri, 16 Feb 2018 02:36:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 uvWJKDLd0bYL for ; Fri, 16 Feb 2018 02:36:07 -0800 (PST) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72B4112D882 for ; Fri, 16 Feb 2018 02:36:07 -0800 (PST) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 0E13160C39; Fri, 16 Feb 2018 11:36:06 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.27]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id DEFDD180066; Fri, 16 Feb 2018 11:36:05 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7C.corporate.adroot.infra.ftgroup ([fe80::8007:17b:c3b4:d68b%19]) with mapi id 14.03.0382.000; Fri, 16 Feb 2018 11:36:05 +0100 From: To: "Konda, Tirumaleswar Reddy" , "dots@ietf.org" Thread-Topic: draft-ietf-dots-data-channel: Filter Direction Thread-Index: AdOlbGwqi1N7Z468TzqkpTeHXPf9AQBBCWQgACITfVAAAZZfcAAAttzQAABGxtAAAo6C4AAAfT7gAABMTCA= Date: Fri, 16 Feb 2018 10:36:05 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0D3464@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300A0D1F7C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0D327F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0D3331@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0D3409@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A0D3464OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction 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, 16 Feb 2018 10:36:13 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A0D3464OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Tiru, [TR2] The device on which ACL gets enforced need not be co-located with the= DOTS agent, the policy enforcement point (either CPE or DDoS mitigator) wh= ere the ACL is installed either sees an incoming attack or outgoing attack.= The optional parameter should specify this direction. Please remember that we do have the following in the draft: How filtering rules instantiated on a DOTS server are translated into network configurations actions is out of scope. When it comes to enforcing ACLs on devices, draft-ietf-netmod-acl does alre= ady support how to indicate ingress/egress attachment points. Translating D= OTS filtering rules (including setting direction) into device/network speci= fic ones t is under the responsibility of the server domain. This is out of= scope. [TR2] I don't see the value add the new parameter provides by just saying t= he attack traffic destination is from the "DOTS server to DOTS client" or = "DOTS client to DOTS server" (we don't have a valid use case for the latter= value). I don't see a value for it, either. This is exactly what I meant by "it is = preferable to have a case for it". We are in full agreement :) Cheers, Med De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] Envoy=E9 : vendredi 16 f=E9vrier 2018 11:25 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: draft-ietf-dots-data-channel: Filter Direction Please see inline [TR2] From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 3:39 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: draft-ietf-dots-data-channel: Filter Direction Re-, Please see inline. Cheers, Med De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] Envoy=E9 : vendredi 16 f=E9vrier 2018 10:07 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: draft-ietf-dots-data-channel: Filter Direction From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 2:19 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: draft-ietf-dots-data-channel: Filter Direction Re-, Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 16 f=E9vrier 2018 09:28 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] draft-ietf-dots-data-channel: Filter Direction There is no ambiguity in the roles. The CPE is acting as DOTS server but th= e DOTS server is initiating connection to the DOTS client in the access net= work. [Med] Don't get the last part. The server (CPE) will receive a request from= the network (client) to filter traffic exiting from that CPE. [TR] I mean to use the call home feature discussed in https://tools.ietf.or= g/html/rfc8071, though the CPE is acting as a DOTS server it will initiate = the connection (TLS or DTLS) to the DOTS client in the access network. The = call home feature helps avoid various threats like the DOTS server in the C= PE will not be subjected to DDoS attacks, and reachability is not problem e= ven if the CPE is behind NAT. [Med] OK. The DOTS client will convey the black-list filtering in the "out" direction= to block the traffic originating from the DOTS server domain. [Med] Which corresponds to the "DOTS Server to DOTS Client" direction; that= is the DOTS client domain (access network) is the destination. All is fine= so far :) [TR] The direction is "outgoing traffic" whereas for other use cases the di= rection is "incoming traffic". [Med] Tiru, the direction in both cases is always the same: "DOTS Server to= DOTS Client". Of course, from the perspective of the CPE (not the DOTS age= nt role), this will be "out" or "in" depending on the DOTS agent role on th= e CPE, but this is not important to determine the direction of the filters;= only DOTS roles matter. [TR2] The device on which ACL gets enforced need not be co-located with the= DOTS agent, the policy enforcement point (either CPE or DDoS mitigator) wh= ere the ACL is installed either sees an incoming attack or outgoing attack.= The optional parameter should specify this direction. I don't see the valu= e add the new parameter provides by just saying the attack traffic destinat= ion is from the "DOTS server to DOTS client" or "DOTS client to DOTS serve= r" (we don't have a valid use case for the latter value). Cheers, -Tiru I don't understand what you mean by a "optional" parameter ? [Med] I meant adding a parameter to indicate explicitly the direction. It w= ould be optional because we do already have a default direction. [TR] Okay. -Tiru -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Friday, February 16, 2018 1:24 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction Hi Tiru, There will be an ambiguity in interpreting filters if and only if the same = DOTS agents have to manipulate filters in both directions. As you rightfully mentioned, the bb use case assumes the following: In order to achieve this capability, the telemetry analysis system utilized by the broadband access provider must have DOTS client functionality, and the end-customer CPE devices must have DOTS server functionality. Which means that there is no ambiguity in that case with the current defaul= t direction: "the destination is the DOTS client domain". No matter how roles were negotiated, but as far as each an agent acts as a = client and its peer as a server, things are clear. Of course we can always define an optional parameter for this, but it is pr= eferable to have a case for it. Cheers, Med De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] Envoy=E9 : jeudi 15 f=E9vrier 2018 16:31 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: draft-ietf-dots-data-channel: Filter Direction The filtering rule for outgoing traffic is required for the "Suppression of= outbound DDoS traffic originating from a consumer broadband access network= " use case discussed in https://tools.ietf.org/html/draft-ietf-dots-use-cas= es-09#section-3.2.1. In this use case, the CPE initially acts as a DOTS cli= ent but after the TCP connection is established, reverses its role and acts= as DOTS server (see https://tools.ietf.org/html/rfc8071). The access netwo= rk can then program the CPE using the DOTS data channel to block the DDoS a= ttack traffic originated from the compromised devices in the local customer network. Cheers, -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Wednesday, February 14, 2018 1:49 PM To: dots@ietf.org Subject: [Dots] draft-ietf-dots-data-channel: Filter Direction Hi all, As agreed during the interim, there are some issues that need fixes in the = data-channel spec. We would like to hear from the WG to know what to record= in the document. Issue description: Do we need to support explicit "direction" in filtering = rules ("in"/"out")? That is, do we allow a DOTS client to create filters fo= r both incoming and outgoing traffic? Below a proposal for discussion: - The current default direction is aligned with the nature of DDoS attac= ks targeted by DOTS: i.e. incoming. The DOTS client domain is assumed to be= the destination. No ambiguity so far with such default behavior. - There is no clear use case for the support of outgoing filtering handl= ing in the context of DOTS. - No text change is required to the draft. Any objection? Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300A0D3464OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Tiru,

 

[TR2] The device on which ACL gets enforced need not be co-located wi= th the DOTS agent, the policy enforcement point (either CPE or DDoS mitigat= or) where the ACL is installed either sees an incoming attack or outgoing attack. The optional parameter should = specify this direction.

 

Please remember that we do have= the following in the draft:

 

   How fi= ltering rules instantiated on a DOTS server are translated into<= /span>

   networ= k configurations actions is out of scope.

 

When it comes to en= forcing ACLs on devices, draft-ietf-netmod-acl does already support how to = indicate ingress/egress attachment points. Translating DOTS filtering rules (including setting direction) into device/network spe= cific ones t is under the responsibility of the server domain. This is out = of scope.   

 

[TR2] I don’t see the value add the new parameter provides by j= ust saying the attack traffic destination is from  the “DOTS ser= ver to DOTS client” or “DOTS client to DOTS server” (we don’t have a valid use case for the latter value).=

 

I don’t see a value for i= t, either. This is exactly what I meant by “it is preferable to have a case for it”. We= are in full agreement :)

 

Cheers,

Med

 

De : Konda, Tirumaleswar Reddy [mail= to:TirumaleswarReddy_Konda@McAfee.com]
Envoy=E9 : vendredi 16 f=E9vrier 2018 11:25
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: draft-ietf-dots-data-channel: Filter Direction=

 

Please see inline [TR2]

 

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Friday, February 16, 2018 3:39 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: RE: draft-ietf-dots-data-channel: Filter Direction

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_= Konda@McAfee.com]
Envoy=E9 : vendredi 16 f=E9vrier 2018 10:07
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: draft-ietf-dots-data-channel: Filter Direction=

 

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Friday, February 16, 2018 2:19 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: RE: draft-ietf-dots-data-channel: Filter Direction

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : vendredi 16 f=E9vrier 2018 09:28
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : Re: [Dots] draft-ietf-dots-data-channel: Filter Directi= on

 

There is no ambiguity in the roles. The CPE is acting as DOTS server = but the DOTS server is initiating connection to the DOTS client in the acce= ss network.

[Med= ] Don’t get the last part. The server (CPE) will receive a request fr= om the network (client) to filter traffic exiting from that CPE.

 

[TR] I mean to use the call home feature discussed in https://tools.ietf.org/html= /rfc8071, though the CPE is acting as a DOTS server it will initiate th= e connection (TLS or DTLS) to the DOTS client in the access network. The ca= ll home feature helps avoid various threats like the DOTS server in the CPE will not be subjected to DDoS atta= cks, and reachability is not problem even if the CPE is behind NAT.

[Med= ] OK.

 

The DOTS client will convey the black-list filtering in the “ou= t” direction to block the traffic originating from the DOTS server do= main.

[Med= ] Which corresponds to the “DOTS Server to DOTS Client” directi= on; that is the DOTS client domain (access network) is the destination. All is fine so far :)

 

 

[TR] The direction is “outgoing traffic” whereas for othe= r use cases the direction is “incoming traffic”.

[Med= ] Tiru, the direction in both cases is always the same: “DOTS Server = to DOTS Client”. Of course, from the perspective of the CPE (not the DOTS agent role), this will be “out” or “in= ” depending on the DOTS agent role on the CPE, but this is not import= ant to determine the direction of the filters; only DOTS roles matter.=

 

[TR2] The device on which ACL gets enforced need not be co-located wi= th the DOTS agent, the policy enforcement point (either CPE or DDoS mitigat= or) where the ACL is installed either sees an incoming attack or outgoing attack. The optional parameter should = specify this direction. I don’t see the value add the new parameter p= rovides by just saying the attack traffic destination is from  the = 220;DOTS server to DOTS client” or “DOTS client to DOTS server” (we don’t have a valid use case for the latter va= lue).

 

Cheers,

-Tiru

 

I don’t understand what you mean by a “optional” pa= rameter ?

[Med= ] I meant adding a parameter to indicate explicitly the direction. It would= be optional because we do already have a default direction.

 

[TR] Okay.

 

-Tiru

 

-Tiru

 

From: Dots [mailto:dots-bounces= @ietf.org] On Behalf Of mohamed= .boucadair@orange.com
Sent: Friday, February 16, 2018 1:24 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction

 

Hi Tiru,

 

There will be an ambiguity in i= nterpreting filters if and only if the same DOTS agents have to manipulate = filters in both directions.

 

As you rightfully mentioned, th= e bb use case assumes the following:

 

   In ord= er to achieve this capability, the telemetry analysis system

   utiliz= ed by the broadband access provider must have DOTS client=

   functi= onality, and the end-customer CPE devices must have DOTS server<= /span>

   functionality.

 

Which means that there is no am= biguity in that case with the current default direction: “the destina= tion is the DOTS client domain”.

 

No matter how roles were =
negotiated, but as far as each an agent acts as a client and its peer as a =
server, things are clear. 
 <=
/pre>

Of course we can always d=
efine an optional parameter for this, but it is preferable to have a case f=
or it.  


 <=
/pre>

Cheers,=



Med

 








De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_=
Konda@McAfee.com]


Envoy=E9 : jeudi 15 f=E9vrier 2018 16:31

=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org

Objet : RE: draft-ietf-dots-data-channel: Filter Direction=







 


The filtering rule for outgoing traffic is required for the "Sup=
pression of outbound DDoS traffic originating from a consumer broadband acc=
ess network" use case discussed in

https://tools.ietf.org/html/draft-ietf-dots-use-cases-09#section-3.2.1.=
 In this use case, the CPE initially acts as a DOTS client but after the TC=
P connection is established, reverses its role and acts as DOTS server (see
https://tools.ietf.org/html=
/rfc8071). The access network can then program the CPE using the DOTS d=
ata channel to block the DDoS attack traffic originated from the compromise=
d devices in the



local customer network.



 


Cheers,


-Tiru


 








From: Dots [mailto:dots-bounces=
@ietf.org]
On Behalf Of mohamed=
.boucadair@orange.com

Sent: Wednesday, February 14, 2018 1:49 PM

To: dots@ietf.org

Subject: [Dots] draft-ietf-dots-data-channel: Filter Direction<=
/o:p>






 


Hi all,



 


As agreed during the interim, there are som=
e issues that need fixes in the data-channel spec. We would like to hear fr=
om the WG to know what to record in the document.



 


Issue description: Do we need to support ex=
plicit “direction” in filtering rules (“in”/“=
out”)? That is, do we allow a DOTS client to create filters for both =
incoming
 and outgoing traffic? 


 


Below a proposal for discussion:=



–=
;   
The current default direction is aligned with the nature of=
 DDoS attacks targeted by DOTS: i.e. incoming. The DOTS client domain is as=
sumed to be the destination. No ambiguity so far
 with such default behavior. 


–=
;   
There is no clear use case for the support of outgoing filt=
ering handling in the context of DOTS.


–=
;   
No text change is required to the draft.<=
/p>

 =
;


Any object=
ion?



 =
;


Cheers,


Med



 
--_000_787AE7BB302AE849A7480A190F8B93300A0D3464OPEXCLILMA3corp_-- From nobody Fri Feb 16 02:58:35 2018 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 7477D12D878 for ; Fri, 16 Feb 2018 02:58:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.33 X-Spam-Level: X-Spam-Status: No, score=-4.33 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 quXiS8b3HjY6 for ; Fri, 16 Feb 2018 02:58:31 -0800 (PST) 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 BFC74126D46 for ; Fri, 16 Feb 2018 02:58:30 -0800 (PST) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1518778702; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=t rfvXZqJxCPlNM8eyD9IoDsNLTbRPmBjhDjdR+17M0 I=; b=MNOO4GQEDeFzCWLBfTUS9SoDBCV7xRKYif7bCVwINAiM oDY4VuIKsJiOZC8J/o5m5zthnFFCZaWEJxigc100UCuuMPrbYL 1/5ImSbKpMLwhvshh36C0at/qcI5TLk7BTsg2A4yisNmeTOJxX cjUGFbSuUHnxHMV51NLQoQgug80= Received: from DNVEXAPP1N04.corpzone.internalzone.com (unknown [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 40e4_75fe_8a77ee89_ef43_4b75_b13b_539af25775cb; Fri, 16 Feb 2018 04:58:21 -0600 Received: from DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 16 Feb 2018 03:57:42 -0700 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Fri, 16 Feb 2018 03:57:42 -0700 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 16 Feb 2018 03:57:16 -0700 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB2342.namprd16.prod.outlook.com (52.132.142.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.18; Fri, 16 Feb 2018 10:57:40 +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.20.0485.015; Fri, 16 Feb 2018 10:57:40 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: draft-ietf-dots-data-channel: Filter Direction Thread-Index: AdOlbGwqi1N7Z468TzqkpTeHXPf9AQBBCWQgACITfVAAAZZfcAAAttzQAABGxtAAAo6C4AAAfT7gAABMTCAAAP624A== Date: Fri, 16 Feb 2018 10:57:40 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A0D1F7C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0D327F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0D3331@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0D3409@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0D3464@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A0D3464@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action 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; DM5PR16MB2342; 7:tCvFmStEdQ5BOLhzwOWsL7be0XPYBs/OK2NqIdm5XopOftgSyOhS2tL8VE09H602vizdA79RFuCCPhx0ZSdehG8WwYZ86EihuVdo+j2b8PjAQe6ROmHR8k7wdPNKp0DD0CGdhBs82pQQtFGby9+e/I//XN/r7y+FBdG4ll0AjU9iauuKNlPQyrQlemGi0Es1GP12pbbtMkeo5mlekDQs3j7DAyhMxliZ3Ccp694xodZJLf+rRkXJfSnCSB/nw46n x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 2b6ef28b-0f62-42da-5f79-08d5752c1937 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM5PR16MB2342; x-ms-traffictypediagnostic: DM5PR16MB2342: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(18271650672692)(21748063052155)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3002001)(10201501046)(3231101)(944501161)(93006095)(93001095)(6041288)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(6072148)(201708071742011); SRVR:DM5PR16MB2342; BCL:0; PCL:0; RULEID:; SRVR:DM5PR16MB2342; x-forefront-prvs: 0585417D7B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(346002)(39860400002)(366004)(376002)(39380400002)(57704003)(32952001)(53754006)(199004)(189003)(53936002)(53946003)(105586002)(99286004)(5660300001)(606006)(2501003)(316002)(186003)(2900100001)(74316002)(77096007)(2950100002)(6506007)(3660700001)(14454004)(966005)(86362001)(26005)(25786009)(53546011)(110136005)(102836004)(2906002)(561944003)(66066001)(106356001)(7696005)(72206003)(76176011)(6436002)(3280700002)(59450400001)(478600001)(55016002)(3846002)(6116002)(236005)(9686003)(54896002)(6306002)(229853002)(19609705001)(790700001)(8936002)(7736002)(5890100001)(81156014)(6246003)(97736004)(33656002)(8676002)(80792005)(93886005)(81166006)(68736007)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB2342; 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) x-microsoft-antispam-message-info: tTbytD0CsYpdnOxWYKGVKsV8MDPOlimw8i2NuAwpNnV5eOHWDQUkToXzDVt1yNk9rn32RImJGDrFHcEzFUhNPQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB178808C53B82179D0119713BEACB0DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 2b6ef28b-0f62-42da-5f79-08d5752c1937 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2018 10:57:40.3613 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB2342 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 <6223> : inlines <6404> : streams <1779139> : uri <2593823> Archived-At: Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction 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, 16 Feb 2018 10:58:33 -0000 --_000_DM5PR16MB178808C53B82179D0119713BEACB0DM5PR16MB1788namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 4:06 PM To: Konda, Tirumaleswar Reddy ; dots@ie= tf.org Subject: RE: draft-ietf-dots-data-channel: Filter Direction Tiru, [TR2] The device on which ACL gets enforced need not be co-located with the= DOTS agent, the policy enforcement point (either CPE or DDoS mitigator) wh= ere the ACL is installed either sees an incoming attack or outgoing attack.= The optional parameter should specify this direction. Please remember that we do have the following in the draft: How filtering rules instantiated on a DOTS server are translated into network configurations actions is out of scope. When it comes to enforcing ACLs on devices, draft-ietf-netmod-acl does alre= ady support how to indicate ingress/egress attachment points. Translating D= OTS filtering rules (including setting direction) into device/network speci= fic ones t is under the responsibility of the server domain. This is out of= scope. [TR3] Okay. [TR2] I don't see the value add the new parameter provides by just saying t= he attack traffic destination is from the "DOTS server to DOTS client" or = "DOTS client to DOTS server" (we don't have a valid use case for the latter= value). I don't see a value for it, either. This is exactly what I meant by "it is = preferable to have a case for it". We are in full agreement :) [TR3] Good, no need to add a new parameter :) -Tiru Cheers, Med De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] Envoy=E9 : vendredi 16 f=E9vrier 2018 11:25 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: draft-ietf-dots-data-channel: Filter Direction Please see inline [TR2] From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 3:39 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: draft-ietf-dots-data-channel: Filter Direction Re-, Please see inline. Cheers, Med De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] Envoy=E9 : vendredi 16 f=E9vrier 2018 10:07 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: draft-ietf-dots-data-channel: Filter Direction From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 2:19 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: draft-ietf-dots-data-channel: Filter Direction Re-, Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 16 f=E9vrier 2018 09:28 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] draft-ietf-dots-data-channel: Filter Direction There is no ambiguity in the roles. The CPE is acting as DOTS server but th= e DOTS server is initiating connection to the DOTS client in the access net= work. [Med] Don't get the last part. The server (CPE) will receive a request from= the network (client) to filter traffic exiting from that CPE. [TR] I mean to use the call home feature discussed in https://tools.ietf.or= g/html/rfc8071, though the CPE is acting as a DOTS server it will initiate = the connection (TLS or DTLS) to the DOTS client in the access network. The = call home feature helps avoid various threats like the DOTS server in the C= PE will not be subjected to DDoS attacks, and reachability is not problem e= ven if the CPE is behind NAT. [Med] OK. The DOTS client will convey the black-list filtering in the "out" direction= to block the traffic originating from the DOTS server domain. [Med] Which corresponds to the "DOTS Server to DOTS Client" direction; that= is the DOTS client domain (access network) is the destination. All is fine= so far :) [TR] The direction is "outgoing traffic" whereas for other use cases the di= rection is "incoming traffic". [Med] Tiru, the direction in both cases is always the same: "DOTS Server to= DOTS Client". Of course, from the perspective of the CPE (not the DOTS age= nt role), this will be "out" or "in" depending on the DOTS agent role on th= e CPE, but this is not important to determine the direction of the filters;= only DOTS roles matter. [TR2] The device on which ACL gets enforced need not be co-located with the= DOTS agent, the policy enforcement point (either CPE or DDoS mitigator) wh= ere the ACL is installed either sees an incoming attack or outgoing attack.= The optional parameter should specify this direction. I don't see the valu= e add the new parameter provides by just saying the attack traffic destinat= ion is from the "DOTS server to DOTS client" or "DOTS client to DOTS serve= r" (we don't have a valid use case for the latter value). Cheers, -Tiru I don't understand what you mean by a "optional" parameter ? [Med] I meant adding a parameter to indicate explicitly the direction. It w= ould be optional because we do already have a default direction. [TR] Okay. -Tiru -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Friday, February 16, 2018 1:24 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction Hi Tiru, There will be an ambiguity in interpreting filters if and only if the same = DOTS agents have to manipulate filters in both directions. As you rightfully mentioned, the bb use case assumes the following: In order to achieve this capability, the telemetry analysis system utilized by the broadband access provider must have DOTS client functionality, and the end-customer CPE devices must have DOTS server functionality. Which means that there is no ambiguity in that case with the current defaul= t direction: "the destination is the DOTS client domain". No matter how roles were negotiated, but as far as each an agent acts as a = client and its peer as a server, things are clear. Of course we can always define an optional parameter for this, but it is pr= eferable to have a case for it. Cheers, Med De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] Envoy=E9 : jeudi 15 f=E9vrier 2018 16:31 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: draft-ietf-dots-data-channel: Filter Direction The filtering rule for outgoing traffic is required for the "Suppression of= outbound DDoS traffic originating from a consumer broadband access network= " use case discussed in https://tools.ietf.org/html/draft-ietf-dots-use-cas= es-09#section-3.2.1. In this use case, the CPE initially acts as a DOTS cli= ent but after the TCP connection is established, reverses its role and acts= as DOTS server (see https://tools.ietf.org/html/rfc8071). The access netwo= rk can then program the CPE using the DOTS data channel to block the DDoS a= ttack traffic originated from the compromised devices in the local customer network. Cheers, -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Wednesday, February 14, 2018 1:49 PM To: dots@ietf.org Subject: [Dots] draft-ietf-dots-data-channel: Filter Direction Hi all, As agreed during the interim, there are some issues that need fixes in the = data-channel spec. We would like to hear from the WG to know what to record= in the document. Issue description: Do we need to support explicit "direction" in filtering = rules ("in"/"out")? That is, do we allow a DOTS client to create filters fo= r both incoming and outgoing traffic? Below a proposal for discussion: - The current default direction is aligned with the nature of DDoS attac= ks targeted by DOTS: i.e. incoming. The DOTS client domain is assumed to be= the destination. No ambiguity so far with such default behavior. - There is no clear use case for the support of outgoing filtering handl= ing in the context of DOTS. - No text change is required to the draft. Any objection? Cheers, Med --_000_DM5PR16MB178808C53B82179D0119713BEACB0DM5PR16MB1788namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

From:<= /span> mohamed.boucadair@ora= nge.com [mailto:mohamed.boucadair@orange.com]
Sent: Friday, February 16, 2018 4:06 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org
Subject: RE: draft-ietf-dots-data-channel: Filter Direction

 

Tiru,

 

[TR2] The= device on which ACL gets enforced need not be co-located with the DOTS age= nt, the policy enforcement point (either CPE or DDoS mitigator) where the A= CL is installed either sees an incoming attack or outgoing attack. The optional parameter should specify this dire= ction.

&nbs= p;

Please remember that we do have the following = in the draft:

 

   How filtering rules i= nstantiated on a DOTS server are translated into

   network configuration= s actions is out of scope.

 

When it comes to enforcing ACLs on= devices, draft-ietf-netmod-acl does already support how to indicate ingres= s/egress attachment points. Translating DOTS filtering rules (including setting direction) into device/network specific ones t is= under the responsibility of the server domain. This is out of scope.  = ; 

 <= /o:p>

 <= /o:p>

[TR3] Okay.<= o:p>

&nbs= p;

[TR2] I d= on’t see the value add the new parameter provides by just saying the = attack traffic destination is from  the “DOTS server to DOTS cli= ent” or “DOTS client to DOTS server” (we don’t have= a valid use case for the latter value).

 

I don’t see a value for it, either. This= is exactly what I meant by “it is preferable to have a case for it”. We are in full ag= reement :)

 

[TR3] Good, no need to add a new parameter J

 

-Tiru

 

Cheers,

Med

 

De : Konda, Tirumaleswar Reddy [mailto:Tirumaleswar= Reddy_Konda@McAfee.com]
Envoy=E9 : vendredi 16 f=E9vrier 2018 11:25
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: draft-ietf-dots-data-channel: Filter Direction=

 

Please se= e inline [TR2]

&nbs= p;

From:<= /span> mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Friday, February 16, 2018 3:39 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: RE: draft-ietf-dots-data-channel: Filter Direction

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Konda, Tirumaleswar Reddy [mailto:Tirumaleswar= Reddy_Konda@McAfee.com]
Envoy=E9 : vendredi 16 f=E9vrier 2018 10:07
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: draft-ietf-dots-data-channel: Filter Direction=

 

From:<= /span> mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Friday, February 16, 2018 2:19 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: RE: draft-ietf-dots-data-channel: Filter Direction

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : vendredi 16 f=E9vrier 2018 09:28
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : Re: [Dots] draft-ietf-dots-data-channel: Filter Directi= on

 

There is = no ambiguity in the roles. The CPE is acting as DOTS server but the DOTS se= rver is initiating connection to the DOTS client in the access network.

[Med] Don’t g= et the last part. The server (CPE) will receive a request from the network = (client) to filter traffic exiting from that CPE.

&nbs= p;

[TR] I me= an to use the call home feature discussed in https://tools.ietf.org/html= /rfc8071, though the CPE is acting as a DOTS server it will initiate th= e connection (TLS or DTLS) to the DOTS client in the access network. The ca= ll home feature helps avoid various threats like the DOTS server in the CPE will not be subjected to DDoS atta= cks, and reachability is not problem even if the CPE is behind NAT.

[Med] OK.

 

The DOTS = client will convey the black-list filtering in the “out” direct= ion to block the traffic originating from the DOTS server domain.

[Med] Which corresp= onds to the “DOTS Server to DOTS Client” direction; that is the= DOTS client domain (access network) is the destination. All is fine so far :)

&nbs= p;

&nbs= p;

[TR] The = direction is “outgoing traffic” whereas for other use cases the= direction is “incoming traffic”.

[Med] Tiru, the dir= ection in both cases is always the same: “DOTS Server to DOTS Client&= #8221;. Of course, from the perspective of the CPE (not the DOTS agent role), this will be “out” or “in” depen= ding on the DOTS agent role on the CPE, but this is not important to determ= ine the direction of the filters; only DOTS roles matter.=

&nbs= p;

[TR2] The= device on which ACL gets enforced need not be co-located with the DOTS age= nt, the policy enforcement point (either CPE or DDoS mitigator) where the A= CL is installed either sees an incoming attack or outgoing attack. The optional parameter should specify this dire= ction. I don’t see the value add the new parameter provides by just s= aying the attack traffic destination is from  the “DOTS server t= o DOTS client” or “DOTS client to DOTS server” (we don’t have a valid use case for the latter value).=

&nbs= p;

Cheers,

-Tiru

 

I donR= 17;t understand what you mean by a “optional” parameter ?<= /o:p>

[Med] I meant addin= g a parameter to indicate explicitly the direction. It would be optional be= cause we do already have a default direction.

&nbs= p;

[TR] Okay= .

&nbs= p;

-Tiru

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed= .boucadair@orange.com
Sent: Friday, February 16, 2018 1:24 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction

 

Hi Tiru,

 

There will be an ambiguity in interpreting fil= ters if and only if the same DOTS agents have to manipulate filters in both= directions.

 

As you rightfully mentioned, the bb use case a= ssumes the following:

 

   In order to achieve t= his capability, the telemetry analysis system

   utilized by the broad= band access provider must have DOTS client

   functionality, and th= e end-customer CPE devices must have DOTS server

   functionality.

 

Which means that there is no ambiguity in that= case with the current default direction: “the destination is the DOT= S client domain”.

 

No matter how roles were negotiated, but=
 as far as each an agent acts as a client and its peer as a server, things =
are clear. 
 
Of course we can always define an option=
al parameter for this, but it is preferable to have a case for it.  
 
Cheers,
Med

 

De : Konda, Tirumaleswar Reddy [mailto:Tirumaleswar= Reddy_Konda@McAfee.com]
Envoy=E9 : jeudi 15 f=E9vrier 2018 16:31
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: draft-ietf-dots-data-channel: Filter Direction=

 

The filte= ring rule for outgoing traffic is required for the "Suppression of out= bound DDoS traffic originating from a consumer broadband access network&quo= t; use case discussed in https://tools.ietf.org/html/draft-ietf-dots-use-cases-09#section-3.2.1.= In this use case, the CPE initially acts as a DOTS client but after the TC= P connection is established, reverses its role and acts as DOTS server (see https://tools.ietf.org/html= /rfc8071). The access network can then program the CPE using the DOTS d= ata channel to block the DDoS attack traffic originated from the compromise= d devices in the

local cus= tomer network.

&nbs= p;

Cheers,

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed= .boucadair@orange.com
Sent: Wednesday, February 14, 2018 1:49 PM
To: dots@ietf.org
Subject: [Dots] draft-ietf-dots-data-channel: Filter Direction<= /o:p>

 

Hi all,

 

As agreed during the interim, there are some issues that n= eed fixes in the data-channel spec. We would like to hear from the WG to kn= ow what to record in the document.

 

Issue description: Do we need to support explicit “d= irection” in filtering rules (“in”/“out”)? Th= at is, do we allow a DOTS client to create filters for both incoming and ou= tgoing traffic?

 

Below a proposal for discussion:

– = ;   The current default direction is aligned with the nature of DDoS attacks t= argeted by DOTS: i.e. incoming. The DOTS client domain is assumed to be the= destination. No ambiguity so far with such default behavior.

– = ;   There is no clear use case for the support of outgoing filtering handling = in the context of DOTS.

– = ;   No text change is required to the draft.

 <= /p>

Any objection?

 <= /p>

Cheers,=

Med

 

--_000_DM5PR16MB178808C53B82179D0119713BEACB0DM5PR16MB1788namp_-- From nobody Fri Feb 16 02:58:55 2018 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 7CE6C12D878 for ; Fri, 16 Feb 2018 02:58:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 OOPfYOzm6MAP for ; Fri, 16 Feb 2018 02:58:51 -0800 (PST) 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 246F9126D46 for ; Fri, 16 Feb 2018 02:58:46 -0800 (PST) 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 1emdj1-0000j4-FU; Fri, 16 Feb 2018 10:58:43 +0000 From: "Jon Shallow" To: , "Konda, Tirumaleswar Reddy" , References: <787AE7BB302AE849A7480A190F8B93300A0D1F7C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0D327F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0D3331@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0D3409@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0D3464@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A0D3464@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Fri, 16 Feb 2018 10:58:45 -0000 Message-ID: <00a401d3a715$1d89ac70$589d0550$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A5_01D3A715.1D8C1D70" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJhm6BqxMEAgRtKQGWOWKzvESzJbAHkQu0GAe9IPZgCFkuYjAFWJpskAsM/rwUB5tpVnAFozpbMAownDtKiC/jCIA== Content-Language: en-gb Archived-At: Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction 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, 16 Feb 2018 10:58:53 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00A5_01D3A715.1D8C1D70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi there, =20 I concur that that there is not a need for a directional parameter. =93Source=94 is source, and =93destination=94 is destination =96 having = a parameter that overrides this direction will only serve to confuse (well certainly me!). =20 >From a DOTS agent that is acting as DOTS server, =93destination=94 is = what needs protecting =96 even for "Suppression of outbound DDoS traffic = originating from a consumer broadband access network" use case. =20 Regards =20 Jon =20 From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of ietf-supjps-mohamed.boucadair@orange.com Sent: 16 February 2018 10:36 To: Konda, Tirumaleswar Reddy; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction =20 Tiru,=20 =20 [TR2] The device on which ACL gets enforced need not be co-located with = the DOTS agent, the policy enforcement point (either CPE or DDoS mitigator) where the ACL is installed either sees an incoming attack or outgoing attack. The optional parameter should specify this direction.=20 =20 Please remember that we do have the following in the draft:=20 =20 How filtering rules instantiated on a DOTS server are translated into network configurations actions is out of scope. =20 When it comes to enforcing ACLs on devices, draft-ietf-netmod-acl does already support how to indicate ingress/egress attachment points. Translating DOTS filtering rules (including setting direction) into device/network specific ones t is under the responsibility of the server domain. This is out of scope. =20 =20 [TR2] I don=92t see the value add the new parameter provides by just = saying the attack traffic destination is from the =93DOTS server to DOTS = client=94 or =93DOTS client to DOTS server=94 (we don=92t have a valid use case for = the latter value). =20 I don=92t see a value for it, either. This is exactly what I meant by = =93it is preferable to have a case for it=94. We are in full agreement :)=20 =20 Cheers, Med =20 De : Konda, Tirumaleswar Reddy = [mailto:TirumaleswarReddy_Konda@McAfee.com]=20 Envoy=E9 : vendredi 16 f=E9vrier 2018 11:25 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: draft-ietf-dots-data-channel: Filter Direction =20 Please see inline [TR2] =20 From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] = Sent: Friday, February 16, 2018 3:39 PM To: Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: RE: draft-ietf-dots-data-channel: Filter Direction =20 Re-, =20 Please see inline.=20 =20 Cheers, Med =20 De : Konda, Tirumaleswar Reddy = [mailto:TirumaleswarReddy_Konda@McAfee.com]=20 Envoy=E9 : vendredi 16 f=E9vrier 2018 10:07 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: draft-ietf-dots-data-channel: Filter Direction =20 From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] = Sent: Friday, February 16, 2018 2:19 PM To: Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: RE: draft-ietf-dots-data-channel: Filter Direction =20 Re-, =20 Please see inline.=20 =20 Cheers, Med =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, = Tirumaleswar Reddy Envoy=E9 : vendredi 16 f=E9vrier 2018 09:28 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] draft-ietf-dots-data-channel: Filter Direction =20 There is no ambiguity in the roles. The CPE is acting as DOTS server but = the DOTS server is initiating connection to the DOTS client in the access network. [Med] Don=92t get the last part. The server (CPE) will receive a request = from the network (client) to filter traffic exiting from that CPE.=20 =20 [TR] I mean to use the call home feature discussed in https://tools.ietf.org/html/rfc8071, though the CPE is acting as a DOTS server it will initiate the connection (TLS or DTLS) to the DOTS client = in the access network. The call home feature helps avoid various threats = like the DOTS server in the CPE will not be subjected to DDoS attacks, and reachability is not problem even if the CPE is behind NAT.=20 [Med] OK.=20 =20 The DOTS client will convey the black-list filtering in the =93out=94 = direction to block the traffic originating from the DOTS server domain. [Med] Which corresponds to the =93DOTS Server to DOTS Client=94 = direction; that is the DOTS client domain (access network) is the destination. All is = fine so far :)=20 =20 =20 [TR] The direction is =93outgoing traffic=94 whereas for other use cases = the direction is =93incoming traffic=94.=20 [Med] Tiru, the direction in both cases is always the same: =93DOTS = Server to DOTS Client=94. Of course, from the perspective of the CPE (not the DOTS = agent role), this will be =93out=94 or =93in=94 depending on the DOTS agent = role on the CPE, but this is not important to determine the direction of the = filters; only DOTS roles matter. =20 [TR2] The device on which ACL gets enforced need not be co-located with = the DOTS agent, the policy enforcement point (either CPE or DDoS mitigator) where the ACL is installed either sees an incoming attack or outgoing attack. The optional parameter should specify this direction. I don=92t = see the value add the new parameter provides by just saying the attack = traffic destination is from the =93DOTS server to DOTS client=94 or =93DOTS = client to DOTS server=94 (we don=92t have a valid use case for the latter value). =20 Cheers, -Tiru =20 I don=92t understand what you mean by a =93optional=94 parameter ? [Med] I meant adding a parameter to indicate explicitly the direction. = It would be optional because we do already have a default direction. =20 [TR] Okay. =20 -Tiru =20 -Tiru =20 From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: Friday, February 16, 2018 1:24 PM To: Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction =20 Hi Tiru,=20 =20 There will be an ambiguity in interpreting filters if and only if the = same DOTS agents have to manipulate filters in both directions.=20 =20 As you rightfully mentioned, the bb use case assumes the following:=20 =20 In order to achieve this capability, the telemetry analysis system utilized by the broadband access provider must have DOTS client functionality, and the end-customer CPE devices must have DOTS server functionality. =20 Which means that there is no ambiguity in that case with the current = default direction: =93the destination is the DOTS client domain=94.=20 =20 No matter how roles were negotiated, but as far as each an agent acts as = a client and its peer as a server, things are clear.=20 =20 Of course we can always define an optional parameter for this, but it is preferable to have a case for it. =20 =20 Cheers, Med =20 De : Konda, Tirumaleswar Reddy = [mailto:TirumaleswarReddy_Konda@McAfee.com]=20 Envoy=E9 : jeudi 15 f=E9vrier 2018 16:31 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: draft-ietf-dots-data-channel: Filter Direction =20 The filtering rule for outgoing traffic is required for the "Suppression = of outbound DDoS traffic originating from a consumer broadband access = network" use case discussed in https://tools.ietf.org/html/draft-ietf-dots-use-cases-09#section-3.2.1. = In this use case, the CPE initially acts as a DOTS client but after the TCP connection is established, reverses its role and acts as DOTS server = (see https://tools.ietf.org/html/rfc8071). The access network can then = program the CPE using the DOTS data channel to block the DDoS attack traffic originated from the compromised devices in the=20 local customer network.=20 =20 Cheers, -Tiru =20 From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: Wednesday, February 14, 2018 1:49 PM To: dots@ietf.org Subject: [Dots] draft-ietf-dots-data-channel: Filter Direction =20 Hi all,=20 =20 As agreed during the interim, there are some issues that need fixes in = the data-channel spec. We would like to hear from the WG to know what to = record in the document.=20 =20 Issue description: Do we need to support explicit =93direction=94 in = filtering rules (=93in=94/=93out=94)? That is, do we allow a DOTS client to create = filters for both incoming and outgoing traffic?=20 =20 Below a proposal for discussion: =96 The current default direction is aligned with the nature of DDoS attacks targeted by DOTS: i.e. incoming. The DOTS client domain is = assumed to be the destination. No ambiguity so far with such default behavior.=20 =96 There is no clear use case for the support of outgoing filtering handling in the context of DOTS. =96 No text change is required to the draft. =20 Any objection?=20 =20 Cheers, Med=20 =20 ------=_NextPart_000_00A5_01D3A715.1D8C1D70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi there,

 

I concur that that there = is not a need for a directional parameter.=A0 “Source” is = source, and “destination” is destination – having a = parameter that overrides this direction will only serve to confuse (well = certainly me!).

 

From a DOTS agent that = is acting as DOTS server, “destination” is what needs = protecting – even for "Suppression of outbound DDoS = traffic originating from a consumer broadband access network" use = case.

 

Regards

 

Jon

 

From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On = Behalf Of ietf-supjps-mohamed.boucadair@orange.com
Sent: = 16 February 2018 10:36
To: Konda, Tirumaleswar Reddy; = dots@ietf.org
Subject: Re: [Dots] = draft-ietf-dots-data-channel: Filter = Direction

 

Tiru,

 

[TR2] The device on = which ACL gets enforced need not be co-located with the DOTS agent, the = policy enforcement point (either CPE or DDoS mitigator) where the ACL is = installed either sees an incoming attack or outgoing attack. The = optional parameter should specify this direction. =

 

Please = remember that we do have the following in the draft: =

 

   How filtering rules = instantiated on a DOTS server are translated = into

   network configurations = actions is out of scope.

 

When it comes to enforcing ACLs on = devices, draft-ietf-netmod-acl does already support how to indicate = ingress/egress attachment points. Translating DOTS filtering rules = (including setting direction) into device/network specific ones t is = under the responsibility of the server domain. This is out of scope. =   

 

[TR2] I don’t see the value = add the new parameter provides by just saying the attack traffic = destination is from  the “DOTS server to DOTS client” = or “DOTS client to DOTS server” (we don’t have a valid = use case for the latter value).

 

I don’t see a value for it, either. This is = exactly what I meant by “it is preferable to have a = case for it”. We are in full agreement :) =

 

Cheers,

Med

 

De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarRed= dy_Konda@McAfee.com]
Envoy=E9 : vendredi 16 = f=E9vrier 2018 11:25
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : = RE: draft-ietf-dots-data-channel: Filter = Direction

 

Please see inline = [TR2]

 

From: mohamed.boucadair@orange.com= [mailto:mohamed.boucadair@ora= nge.com]
Sent: Friday, February 16, 2018 3:39 = PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; dots@ietf.org
Subject: RE: = draft-ietf-dots-data-channel: Filter = Direction

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarRed= dy_Konda@McAfee.com]
Envoy=E9 : vendredi 16 = f=E9vrier 2018 10:07
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : = RE: draft-ietf-dots-data-channel: Filter = Direction

 

From: mohamed.boucadair@orange.com= [mailto:mohamed.boucadair@ora= nge.com]
Sent: Friday, February 16, 2018 2:19 = PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; dots@ietf.org
Subject: RE: = draft-ietf-dots-data-channel: Filter Direction

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] = De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : = vendredi 16 f=E9vrier 2018 09:28
=C0 : BOUCADAIR Mohamed = IMT/OLN; dots@ietf.org
Objet : = Re: [Dots] draft-ietf-dots-data-channel: Filter = Direction

 

There is no ambiguity = in the roles. The CPE is acting as DOTS server but the DOTS server is = initiating connection to the DOTS client in the access network.

[Med] Don’t get the = last part. The server (CPE) will receive a request from the network = (client) to filter traffic exiting from that CPE. =

 

[TR] I mean to use the call home = feature discussed in https://tools.ietf.org/html/= rfc8071, though the CPE is acting as a DOTS server it will initiate = the connection (TLS or DTLS) to the DOTS client in the access network. = The call home feature helps avoid various threats like the DOTS server = in the CPE will not be subjected to DDoS attacks, and reachability is = not problem even if the CPE is behind NAT.

[Med] OK. =

 

=

The DOTS client will convey the = black-list filtering in the “out” direction to block the = traffic originating from the DOTS server domain.

[Med] Which corresponds to = the “DOTS Server to DOTS Client” direction; that is the DOTS = client domain (access network) is the destination. All is fine so far :) =

 

 

[TR] The direction is = “outgoing traffic” whereas for other use cases the direction = is “incoming traffic”.

[Med] Tiru, the direction = in both cases is always the same: “DOTS Server to DOTS = Client”. Of course, from the perspective of the CPE (not the DOTS = agent role), this will be “out” or “in” = depending on the DOTS agent role on the CPE, but this is not important = to determine the direction of the filters; only DOTS roles = matter.

 

[TR2] The device on which ACL gets = enforced need not be co-located with the DOTS agent, the policy = enforcement point (either CPE or DDoS mitigator) where the ACL is = installed either sees an incoming attack or outgoing attack. The = optional parameter should specify this direction. I don’t see the = value add the new parameter provides by just saying the attack traffic = destination is from  the “DOTS server to DOTS client” = or “DOTS client to DOTS server” (we don’t have a valid = use case for the latter value).

 

Cheers,

-Tiru

 

=

I don’t understand what you = mean by a “optional” parameter ?

[Med] I meant adding a = parameter to indicate explicitly the direction. It would be optional = because we do already have a default direction.

 

[TR] Okay.

 

-Tiru

 

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of mohamed.boucadair@orange.com=
Sent: Friday, February 16, 2018 1:24 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; dots@ietf.org
Subject: Re: = [Dots] draft-ietf-dots-data-channel: Filter = Direction

 

Hi Tiru,

 

There will be an ambiguity in interpreting filters if = and only if the same DOTS agents have to manipulate filters in both = directions.

 

As you rightfully mentioned, the bb use case assumes = the following:

 

   In order to achieve this = capability, the telemetry analysis system

   utilized by the broadband = access provider must have DOTS client

   functionality, and the = end-customer CPE devices must have DOTS server

   functionality.

 

Which means that there is no ambiguity in that case = with the current default direction: “the destination is the DOTS = client domain”.

 

No matter how roles were =
negotiated, but as far as each an agent acts as a client and its peer as =
a server, things are clear. 
 
<= pre>Of course we can always define = an optional parameter for this, but it is preferable to have a case for = it.  
 
<= pre>Cheers,= 
Med

 

De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarRed= dy_Konda@McAfee.com]
Envoy=E9 : jeudi 15 f=E9vrier = 2018 16:31
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : = RE: draft-ietf-dots-data-channel: Filter = Direction

 

The filtering rule for = outgoing traffic is required for the "Suppression of outbound DDoS = traffic originating from a consumer broadband access network" use = case discussed in https://tools.ietf.org/html/draft-ietf-dots-use-cases-09#section-3= .2.1. In this use case, the CPE initially acts as a DOTS client but = after the TCP connection is established, reverses its role and acts as = DOTS server (see https://tools.ietf.org/html/= rfc8071). The access network can then program the CPE using the DOTS = data channel to block the DDoS attack traffic originated from the = compromised devices in the

local customer network. =

 

Cheers,

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of mohamed.boucadair@orange.com=
Sent: Wednesday, February 14, 2018 1:49 PM
To: = dots@ietf.org
Subject: = [Dots] draft-ietf-dots-data-channel: Filter = Direction

 

Hi = all,

 

As = agreed during the interim, there are some issues that need fixes in the = data-channel spec. We would like to hear from the WG to know what to = record in the document.

 

Issue = description: Do we need to support explicit “direction” in = filtering rules (“in”/“out”)? That is, do we = allow a DOTS client to create filters for both incoming and outgoing = traffic?

 

Below = a proposal for discussion:

–    The current default = direction is aligned with the nature of DDoS attacks targeted by DOTS: = i.e. incoming. The DOTS client domain is assumed to be the destination. = No ambiguity so far with such default behavior.

–    There is no clear = use case for the support of outgoing filtering handling in the context = of DOTS.

–    No text change is = required to the draft.

 

Any objection? =

 

Cheers,

Med =

 

------=_NextPart_000_00A5_01D3A715.1D8C1D70-- From nobody Fri Feb 16 03:00:48 2018 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 1CF3D12D7E7 for ; Fri, 16 Feb 2018 03:00:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.33 X-Spam-Level: X-Spam-Status: No, score=-4.33 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 UgeB839MCjeW for ; Fri, 16 Feb 2018 03:00:41 -0800 (PST) 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 19AFF126D46 for ; Fri, 16 Feb 2018 03:00:40 -0800 (PST) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1518778840; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=4 3+Cn6xuxtuvx9PTeYlGrwzrrMssWSJLFL6ljdK24r M=; b=R0IHnCOjGXeAPG5MfWT5aUv83EWsn+noNXXqXRhdMDe4 Cf4RQCgE/oMlX4tCr/ZbJ2ncZaMbd4nkBu0sUWdKdT1ydLkzbp mGG33JcelGJWsGcshJ2yeMI2dV7o+dPJv8p7HmFwENJ2sSjL46 ONn/GnSP9gJhFfMefuiPzfqAJ/s= Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 40da_35c5_86d4af8a_ff42_41b4_883b_cb5f8508ba1a; Fri, 16 Feb 2018 05:00:39 -0600 Received: from DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 16 Feb 2018 04:00:27 -0700 Received: from DNVEXUSR1N08.corpzone.internalzone.com (10.44.48.81) by DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 16 Feb 2018 04:00:27 -0700 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXUSR1N08.corpzone.internalzone.com (10.44.48.81) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Fri, 16 Feb 2018 04:00:27 -0700 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (10.44.176.240) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 16 Feb 2018 04:00:26 -0700 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1723.namprd16.prod.outlook.com (10.172.44.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.10; Fri, 16 Feb 2018 11:00:25 +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.20.0485.015; Fri, 16 Feb 2018 11:00:25 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , Jon Shallow , "dots@ietf.org" Thread-Topic: Call home in the signal channel (was RE: [Dots] draft-ietf-dots-data-channel: Filter Direction) Thread-Index: AdOnD40ix0FBs+3eR3Kr9ibwuvod3gABX+Fg Date: Fri, 16 Feb 2018 11:00:24 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A0D3439@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A0D3439@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action 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; DM5PR16MB1723; 7:qLH1/8cUTj6mcV7Cct/q0/Jnhyx/pvtCWwDQiBNl7ZFwKOJKGDcWRAvYwCiOhXSbReFq9qF7WlaUt1u18KYJSqAtd1A+V2es5FyIeLbHkfvXQquK11A3WKVOfmdUhZ0M9Z3WIJN5NcYK+rypuYeOm5LbkjwOnYBX4rRyHneeJHlrb+ShoSzTaRFL3Ihxqdx13Zqzrta2fcWrnDzg5xDdJxX+c03zDXrbrxMCk/HivlVOS4G8OQ/INXjg21iAyNUr x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 3b390ec9-75d3-487c-6b1a-08d5752c7b52 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:DM5PR16MB1723; x-ms-traffictypediagnostic: DM5PR16MB1723: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(18271650672692)(21748063052155)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231101)(2400082)(944501161)(3002001)(10201501046)(6041288)(20161123564045)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:DM5PR16MB1723; BCL:0; PCL:0; RULEID:; SRVR:DM5PR16MB1723; x-forefront-prvs: 0585417D7B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(346002)(39380400002)(376002)(39860400002)(57704003)(199004)(189003)(53754006)(32952001)(99286004)(19609705001)(606006)(186003)(3660700001)(2906002)(236005)(66066001)(478600001)(54896002)(6306002)(316002)(68736007)(77096007)(55016002)(76176011)(9686003)(97736004)(6436002)(790700001)(6116002)(3846002)(7736002)(7696005)(74316002)(5660300001)(26005)(59450400001)(14454004)(102836004)(25786009)(106356001)(6506007)(105586002)(2900100001)(2501003)(80792005)(53936002)(33656002)(8676002)(8936002)(966005)(6246003)(3280700002)(2950100002)(81166006)(229853002)(72206003)(81156014)(561944003)(110136005)(53546011)(86362001)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1723; 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) x-microsoft-antispam-message-info: boradLyCg2fL3w5cFmr3mMxVh99/AvrDZN7rtmLWQ6SO9Oc26iqy4G+IvnOiOrNxAKd6FQp0vBfg1dTM50UmJA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1788F0CB4B826E968479A3DFEACB0DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 3b390ec9-75d3-487c-6b1a-08d5752c7b52 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2018 11:00:24.9396 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1723 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 <6223> : inlines <6404> : streams <1779139> : uri <2593823> Archived-At: Subject: Re: [Dots] Call home in the signal channel (was RE: draft-ietf-dots-data-channel: Filter Direction) 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, 16 Feb 2018 11:00:45 -0000 --_000_DM5PR16MB1788F0CB4B826E968479A3DFEACB0DM5PR16MB1788namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable For the discussed use case https://tools.ietf.org/html/draft-ietf-dots-use-= cases-09#section-3.2.1, the CPE needs to act as a DOTS server only for the = data channel but not for the signal channel. I don't think signal-channel r= equires call home functionality, what is the use case ? -Tiru From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 3:49 PM To: Jon Shallow ; Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: Call home in the signal channel (was RE: [Dots] draft-ietf-dots-da= ta-channel: Filter Direction) Hi Jon, I'm changing the title to keep track of signal-channel specific issues. Please use this one to discuss this use case. Thank you. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 16 f=E9vrier 2018 10:57 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org= Objet : RE: [Dots] draft-ietf-dots-data-channel: Filter Direction I understand the concept of call home - which makes good sense to me and rf= c8071 will, if implemented, handle the data channel and "destination" is st= ill where the 'controlled' traffic is flowing to. However, we also need call home in the signal channel. I'm not sure how th= is will be done - do we need a new CoAP Method (e.g. switch roles) - do we = need to define a different port (rfc8071 defines 4336) etc. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 16 February 2018 09:07 To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 2:19 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: draft-ietf-dots-data-channel: Filter Direction Re-, Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 16 f=E9vrier 2018 09:28 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] draft-ietf-dots-data-channel: Filter Direction There is no ambiguity in the roles. The CPE is acting as DOTS server but th= e DOTS server is initiating connection to the DOTS client in the access net= work. [Med] Don't get the last part. The server (CPE) will receive a request from= the network (client) to filter traffic exiting from that CPE. [TR] I mean to use the call home feature discussed in https://tools.ietf.or= g/html/rfc8071, though the CPE is acting as a DOTS server it will initiate = the connection (TLS or DTLS) to the DOTS client in the access network. The = call home feature helps avoid various threats like the DOTS server in the C= PE will not be subjected to DDoS attacks, and reachability is not problem e= ven if the CPE is behind NAT. The DOTS client will convey the black-list filtering in the "out" direction= to block the traffic originating from the DOTS server domain. [Med] Which corresponds to the "DOTS Server to DOTS Client" direction; that= is the DOTS client domain (access network) is the destination. All is fine= so far :) [TR] The direction is "outgoing traffic" whereas for other use cases the di= rection is "incoming traffic". I don't understand what you mean by a "optional" parameter ? [Med] I meant adding a parameter to indicate explicitly the direction. It w= ould be optional because we do already have a default direction. [TR] Okay. -Tiru -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Friday, February 16, 2018 1:24 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction Hi Tiru, There will be an ambiguity in interpreting filters if and only if the same = DOTS agents have to manipulate filters in both directions. As you rightfully mentioned, the bb use case assumes the following: In order to achieve this capability, the telemetry analysis system utilized by the broadband access provider must have DOTS client functionality, and the end-customer CPE devices must have DOTS server functionality. Which means that there is no ambiguity in that case with the current defaul= t direction: "the destination is the DOTS client domain". No matter how roles were negotiated, but as far as each an agent acts as a = client and its peer as a server, things are clear. Of course we can always define an optional parameter for this, but it is pr= eferable to have a case for it. Cheers, Med De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] Envoy=E9 : jeudi 15 f=E9vrier 2018 16:31 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: draft-ietf-dots-data-channel: Filter Direction The filtering rule for outgoing traffic is required for the "Suppression of= outbound DDoS traffic originating from a consumer broadband access network= " use case discussed in https://tools.ietf.org/html/draft-ietf-dots-use-cas= es-09#section-3.2.1. In this use case, the CPE initially acts as a DOTS cli= ent but after the TCP connection is established, reverses its role and acts= as DOTS server (see https://tools.ietf.org/html/rfc8071). The access netwo= rk can then program the CPE using the DOTS data channel to block the DDoS a= ttack traffic originated from the compromised devices in the local customer network. Cheers, -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Wednesday, February 14, 2018 1:49 PM To: dots@ietf.org Subject: [Dots] draft-ietf-dots-data-channel: Filter Direction Hi all, As agreed during the interim, there are some issues that need fixes in the = data-channel spec. We would like to hear from the WG to know what to record= in the document. Issue description: Do we need to support explicit "direction" in filtering = rules ("in"/"out")? That is, do we allow a DOTS client to create filters fo= r both incoming and outgoing traffic? Below a proposal for discussion: - The current default direction is aligned with the nature of DDoS attac= ks targeted by DOTS: i.e. incoming. The DOTS client domain is assumed to be= the destination. No ambiguity so far with such default behavior. - There is no clear use case for the support of outgoing filtering handl= ing in the context of DOTS. - No text change is required to the draft. Any objection? Cheers, Med --_000_DM5PR16MB1788F0CB4B826E968479A3DFEACB0DM5PR16MB1788namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

For the discussed use case https://tools.ietf.or= g/html/draft-ietf-dots-use-cases-09#section-3.2.1, the CPE needs to act as a DOTS server only for the data channel but not fo= r the signal channel. I don’t think signa= l-channel requires call home functionality, what is the use case ?

&nbs= p;

-Tiru

 

From:<= /span> mohamed.boucadair@ora= nge.com [mailto:mohamed.boucadair@orange.com]
Sent: Friday, February 16, 2018 3:49 PM
To: Jon Shallow <supjps-ietf@jpshallow.com>; Konda, Tirumalesw= ar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: Call home in the signal channel (was RE: [Dots] draft-ietf-= dots-data-channel: Filter Direction)

 

Hi Jon,

 

I’m changing the title to keep track of = signal-channel specific issues.

 

Please use this one to discuss this use case.<= o:p>

 

Thank you.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : vendredi 16 f=E9vrier 2018 10:57
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; <= a href=3D"mailto:dots@ietf.org"> dots@ietf.org
Objet : RE: [Dots] draft-ietf-dots-data-channel: Filter Directi= on

 

I under= stand the concept of call home – which makes good sense to me and rfc= 8071 will, if implemented, handle the data channel and “destination&#= 8221; is still where the ‘controlled’ traffic is flowing to.

&n= bsp;

However= , we also need call home in the signal channel.  I’m not sure ho= w this will be done – do we need a new CoAP Method (e.g. switch roles= ) – do we need to define a different port (rfc8071 defines 4336) etc.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 16 February 2018 09:07
To: mohamed.boucadai= r@orange.com; dots@ietf.org
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction

 

From:<= /span> mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Friday, February 16, 2018 2:19 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: RE: draft-ietf-dots-data-channel: Filter Direction

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : vendredi 16 f=E9vrier 2018 09:28
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : Re: [Dots] draft-ietf-dots-data-channel: Filter Directi= on

 

There is = no ambiguity in the roles. The CPE is acting as DOTS server but the DOTS se= rver is initiating connection to the DOTS client in the access network.

[Med] Don’t g= et the last part. The server (CPE) will receive a request from the network = (client) to filter traffic exiting from that CPE.

&nbs= p;

[TR] I me= an to use the call home feature discussed in https://tools.ietf.org/html= /rfc8071, though the CPE is acting as a DOTS server it will initiate th= e connection (TLS or DTLS) to the DOTS client in the access network. The ca= ll home feature helps avoid various threats like the DOTS server in the CPE will not be subjected to DDoS atta= cks, and reachability is not problem even if the CPE is behind NAT.

 

The DOTS = client will convey the black-list filtering in the “out” direct= ion to block the traffic originating from the DOTS server domain.

[Med] Which corresp= onds to the “DOTS Server to DOTS Client” direction; that is the= DOTS client domain (access network) is the destination. All is fine so far :)

&nbs= p;

&nbs= p;

[TR] The = direction is “outgoing traffic” whereas for other use cases the= direction is “incoming traffic”.

 

I donR= 17;t understand what you mean by a “optional” parameter ?<= /o:p>

[Med] I meant addin= g a parameter to indicate explicitly the direction. It would be optional be= cause we do already have a default direction.

&nbs= p;

[TR] Okay= .

&nbs= p;

-Tiru

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed= .boucadair@orange.com
Sent: Friday, February 16, 2018 1:24 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction

 

Hi Tiru,

 

There will be an ambiguity in interpreting fil= ters if and only if the same DOTS agents have to manipulate filters in both= directions.

 

As you rightfully mentioned, the bb use case a= ssumes the following:

 

   In order to achieve t= his capability, the telemetry analysis system

   utilized by the broad= band access provider must have DOTS client

   functionality, and th= e end-customer CPE devices must have DOTS server

   functionality.

 

Which means that there is no ambiguity in that= case with the current default direction: “the destination is the DOT= S client domain”.

 

No matter how roles were negotiated, but=
 as far as each an agent acts as a client and its peer as a server, things =
are clear. 
 
Of course we can always define an option=
al parameter for this, but it is preferable to have a case for it.  
 
Cheers,
Med

 

De : Konda, Tirumaleswar Reddy [mailto:Tirumaleswar= Reddy_Konda@McAfee.com]
Envoy=E9 : jeudi 15 f=E9vrier 2018 16:31
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: draft-ietf-dots-data-channel: Filter Direction=

 

The filte= ring rule for outgoing traffic is required for the "Suppression of out= bound DDoS traffic originating from a consumer broadband access network&quo= t; use case discussed in https://tools.ietf.org/html/draft-ietf-dots-use-cases-09#section-3.2.1.= In this use case, the CPE initially acts as a DOTS client but after the TC= P connection is established, reverses its role and acts as DOTS server (see https://tools.ietf.org/html= /rfc8071). The access network can then program the CPE using the DOTS d= ata channel to block the DDoS attack traffic originated from the compromise= d devices in the

local cus= tomer network.

&nbs= p;

Cheers,

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed= .boucadair@orange.com
Sent: Wednesday, February 14, 2018 1:49 PM
To: dots@ietf.org
Subject: [Dots] draft-ietf-dots-data-channel: Filter Direction<= /o:p>

 

Hi all,

 

As agreed during the interim, there are some issues that n= eed fixes in the data-channel spec. We would like to hear from the WG to kn= ow what to record in the document.

 

Issue description: Do we need to support explicit “d= irection” in filtering rules (“in”/“out”)? Th= at is, do we allow a DOTS client to create filters for both incoming and ou= tgoing traffic?

 

Below a proposal for discussion:

– = ;   The current default direction is aligned with the nature of DDoS attacks t= argeted by DOTS: i.e. incoming. The DOTS client domain is assumed to be the= destination. No ambiguity so far with such default behavior.

– = ;   There is no clear use case for the support of outgoing filtering handling = in the context of DOTS.

– = ;   No text change is required to the draft.

 <= /p>

Any objection?

 <= /p>

Cheers,=

Med

 

--_000_DM5PR16MB1788F0CB4B826E968479A3DFEACB0DM5PR16MB1788namp_-- From nobody Fri Feb 16 04:02:36 2018 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 7BB75127023 for ; Fri, 16 Feb 2018 04:02:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 FhFLgl5cqND7 for ; Fri, 16 Feb 2018 04:02:32 -0800 (PST) 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 2824C124BE8 for ; Fri, 16 Feb 2018 04:02:32 -0800 (PST) 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 1emeij-0000lf-Bu; Fri, 16 Feb 2018 12:02:29 +0000 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , , References: <787AE7BB302AE849A7480A190F8B93300A0D3439@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Date: Fri, 16 Feb 2018 12:02:31 -0000 Message-ID: <00d201d3a71e$05ead590$11c080b0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D3_01D3A71E.05EF9080" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFhM5SgMTXVloJMPghbVDaqY+i+RwHzf0UPpHwsEaA= Content-Language: en-gb Archived-At: Subject: Re: [Dots] Call home in the signal channel (was RE: draft-ietf-dots-data-channel: Filter Direction) 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, 16 Feb 2018 12:02:34 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00D3_01D3A71E.05EF9080 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Tiru, =20 The more I think about it, =93Call Home=94 support in either the data or = signal channel makes no real sense for https://tools.ietf.org/html/draft-ietf-dots-use-cases-09#section-3.2.1 . The CPE devices don=92t need to trigger the DOTS clients to get = mitigation in place as it will be the provider who works this out. =20 However, for 3.2.1, the DOTS client will need to make a mitigation = request to initiate the implementing of (previously defined) ACLs using the = signal channel as there will be a high possibility of the outbound pipe running full. =20 Regards =20 Jon From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of = Konda, Tirumaleswar Reddy Sent: 16 February 2018 11:00 To: mohamed.boucadair@orange.com; Jon Shallow; dots@ietf.org Subject: Re: [Dots] Call home in the signal channel (was RE: draft-ietf-dots-data-channel: Filter Direction) =20 For the discussed use case https://tools.ietf.org/html/draft-ietf-dots-use-cases-09#section-3.2.1, = the CPE needs to act as a DOTS server only for the data channel but not for = the signal channel. I don=92t think signal-channel requires call home functionality, what is the use case ? =20 -Tiru =20 From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] = Sent: Friday, February 16, 2018 3:49 PM To: Jon Shallow ; Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: Call home in the signal channel (was RE: [Dots] draft-ietf-dots-data-channel: Filter Direction) =20 Hi Jon,=20 =20 I=92m changing the title to keep track of signal-channel specific = issues.=20 =20 Please use this one to discuss this use case. =20 Thank you.=20 =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : vendredi 16 f=E9vrier 2018 10:57 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; = dots@ietf.org Objet : RE: [Dots] draft-ietf-dots-data-channel: Filter Direction =20 I understand the concept of call home =96 which makes good sense to me = and rfc8071 will, if implemented, handle the data channel and = =93destination=94 is still where the =91controlled=92 traffic is flowing to. =20 However, we also need call home in the signal channel. I=92m not sure = how this will be done =96 do we need a new CoAP Method (e.g. switch roles) = =96 do we need to define a different port (rfc8071 defines 4336) etc. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 16 February 2018 09:07 To: mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction =20 From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] = Sent: Friday, February 16, 2018 2:19 PM To: Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: RE: draft-ietf-dots-data-channel: Filter Direction =20 Re-, =20 Please see inline.=20 =20 Cheers, Med =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, = Tirumaleswar Reddy Envoy=E9 : vendredi 16 f=E9vrier 2018 09:28 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] draft-ietf-dots-data-channel: Filter Direction =20 There is no ambiguity in the roles. The CPE is acting as DOTS server but = the DOTS server is initiating connection to the DOTS client in the access network. [Med] Don=92t get the last part. The server (CPE) will receive a request = from the network (client) to filter traffic exiting from that CPE.=20 =20 [TR] I mean to use the call home feature discussed in https://tools.ietf.org/html/rfc8071, though the CPE is acting as a DOTS server it will initiate the connection (TLS or DTLS) to the DOTS client = in the access network. The call home feature helps avoid various threats = like the DOTS server in the CPE will not be subjected to DDoS attacks, and reachability is not problem even if the CPE is behind NAT.=20 =20 The DOTS client will convey the black-list filtering in the =93out=94 = direction to block the traffic originating from the DOTS server domain. [Med] Which corresponds to the =93DOTS Server to DOTS Client=94 = direction; that is the DOTS client domain (access network) is the destination. All is = fine so far :)=20 =20 =20 [TR] The direction is =93outgoing traffic=94 whereas for other use cases = the direction is =93incoming traffic=94.=20 =20 I don=92t understand what you mean by a =93optional=94 parameter ? [Med] I meant adding a parameter to indicate explicitly the direction. = It would be optional because we do already have a default direction. =20 [TR] Okay. =20 -Tiru =20 -Tiru =20 From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: Friday, February 16, 2018 1:24 PM To: Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction =20 Hi Tiru,=20 =20 There will be an ambiguity in interpreting filters if and only if the = same DOTS agents have to manipulate filters in both directions.=20 =20 As you rightfully mentioned, the bb use case assumes the following:=20 =20 In order to achieve this capability, the telemetry analysis system utilized by the broadband access provider must have DOTS client functionality, and the end-customer CPE devices must have DOTS server functionality. =20 Which means that there is no ambiguity in that case with the current = default direction: =93the destination is the DOTS client domain=94.=20 =20 No matter how roles were negotiated, but as far as each an agent acts as = a client and its peer as a server, things are clear.=20 =20 Of course we can always define an optional parameter for this, but it is preferable to have a case for it. =20 =20 Cheers, Med =20 De : Konda, Tirumaleswar Reddy = [mailto:TirumaleswarReddy_Konda@McAfee.com]=20 Envoy=E9 : jeudi 15 f=E9vrier 2018 16:31 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: draft-ietf-dots-data-channel: Filter Direction =20 The filtering rule for outgoing traffic is required for the "Suppression = of outbound DDoS traffic originating from a consumer broadband access = network" use case discussed in https://tools.ietf.org/html/draft-ietf-dots-use-cases-09#section-3.2.1. = In this use case, the CPE initially acts as a DOTS client but after the TCP connection is established, reverses its role and acts as DOTS server = (see https://tools.ietf.org/html/rfc8071). The access network can then = program the CPE using the DOTS data channel to block the DDoS attack traffic originated from the compromised devices in the=20 local customer network.=20 =20 Cheers, -Tiru =20 From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: Wednesday, February 14, 2018 1:49 PM To: dots@ietf.org Subject: [Dots] draft-ietf-dots-data-channel: Filter Direction =20 Hi all,=20 =20 As agreed during the interim, there are some issues that need fixes in = the data-channel spec. We would like to hear from the WG to know what to = record in the document.=20 =20 Issue description: Do we need to support explicit =93direction=94 in = filtering rules (=93in=94/=93out=94)? That is, do we allow a DOTS client to create = filters for both incoming and outgoing traffic?=20 =20 Below a proposal for discussion: =96 The current default direction is aligned with the nature of DDoS attacks targeted by DOTS: i.e. incoming. The DOTS client domain is = assumed to be the destination. No ambiguity so far with such default behavior.=20 =96 There is no clear use case for the support of outgoing filtering handling in the context of DOTS. =96 No text change is required to the draft. =20 Any objection?=20 =20 Cheers, Med=20 =20 ------=_NextPart_000_00D3_01D3A71E.05EF9080 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

The more I think about = it, “Call Home” support in either the data or signal channel = makes no real sense for https://tools.ietf.org/html/draft-ietf-dots-use-cases-09#section-3= .2.1 .=A0 The CPE devices don’t need to trigger the DOTS = clients to get mitigation in place as it will be the provider who works = this out.

 

However, for 3.2.1, the DOTS client = will need to make a mitigation request to initiate the implementing of = (previously defined) ACLs using the signal channel as there will be a = high possibility of the outbound pipe running = full.

 

Regards

 

Jon

From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 16 February 2018 = 11:00
To: mohamed.boucadair@orange.com; Jon Shallow; = dots@ietf.org
Subject: Re: [Dots] Call home in the signal = channel (was RE: draft-ietf-dots-data-channel: Filter = Direction)

 

For the = discussed use case https://tools.ietf.org/html/draft-ietf-dots-use-cases-09#section-3= .2.1, the CPE needs to act as a DOTS server only for the data = channel but not for the signal channel. I don’t think signal-channel = requires call home functionality, what is the use case = ?

 

-Tiru

 

From: mohamed.boucadair@orange.com= [mailto:mohamed.boucadair@ora= nge.com]
Sent: Friday, February 16, 2018 3:49 = PM
To: Jon Shallow <supjps-ietf@jpshallow.com&g= t;; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; dots@ietf.org
Subject: Call = home in the signal channel (was RE: [Dots] draft-ietf-dots-data-channel: = Filter Direction)

 

Hi Jon, =

 

I’m changing the title to keep track of = signal-channel specific issues.

 

Please use this one to discuss this use = case.

 

Thank you.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Envoy=E9 : vendredi 16 f=E9vrier 2018 = 10:57
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR = Mohamed IMT/OLN; dots@ietf.org
Objet : = RE: [Dots] draft-ietf-dots-data-channel: Filter = Direction

 

I understand the concept of call home – = which makes good sense to me and rfc8071 will, if implemented, handle = the data channel and “destination” is still where the = ‘controlled’ traffic is flowing to.

 

However, we also need = call home in the signal channel.  I’m not sure how this will = be done – do we need a new CoAP Method (e.g. switch roles) – = do we need to define a different port (rfc8071 defines 4336) = etc.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 16 February 2018 = 09:07
To: mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: Re: = [Dots] draft-ietf-dots-data-channel: Filter = Direction

 

From: mohamed.boucadair@orange.com= [mailto:mohamed.boucadair@ora= nge.com]
Sent: Friday, February 16, 2018 2:19 = PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; dots@ietf.org
Subject: RE: = draft-ietf-dots-data-channel: Filter Direction

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] = De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : = vendredi 16 f=E9vrier 2018 09:28
=C0 : BOUCADAIR Mohamed = IMT/OLN; dots@ietf.org
Objet : = Re: [Dots] draft-ietf-dots-data-channel: Filter = Direction

 

There is no ambiguity = in the roles. The CPE is acting as DOTS server but the DOTS server is = initiating connection to the DOTS client in the access network.

[Med] Don’t get the = last part. The server (CPE) will receive a request from the network = (client) to filter traffic exiting from that CPE. =

 

[TR] I mean to use the call home = feature discussed in https://tools.ietf.org/html/= rfc8071, though the CPE is acting as a DOTS server it will initiate = the connection (TLS or DTLS) to the DOTS client in the access network. = The call home feature helps avoid various threats like the DOTS server = in the CPE will not be subjected to DDoS attacks, and reachability is = not problem even if the CPE is behind NAT.

 

=

The DOTS client will convey the = black-list filtering in the “out” direction to block the = traffic originating from the DOTS server domain.

[Med] Which corresponds to = the “DOTS Server to DOTS Client” direction; that is the DOTS = client domain (access network) is the destination. All is fine so far :) =

 

 

[TR] The direction is = “outgoing traffic” whereas for other use cases the direction = is “incoming traffic”.

 

=

I don’t understand what you = mean by a “optional” parameter ?

[Med] I meant adding a = parameter to indicate explicitly the direction. It would be optional = because we do already have a default direction.

 

[TR] Okay.

 

-Tiru

 

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of mohamed.boucadair@orange.com=
Sent: Friday, February 16, 2018 1:24 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; dots@ietf.org
Subject: Re: = [Dots] draft-ietf-dots-data-channel: Filter = Direction

 

Hi Tiru,

 

There will be an ambiguity in interpreting filters if = and only if the same DOTS agents have to manipulate filters in both = directions.

 

As you rightfully mentioned, the bb use case assumes = the following:

 

   In order to achieve this = capability, the telemetry analysis system

   utilized by the broadband = access provider must have DOTS client

   functionality, and the = end-customer CPE devices must have DOTS server

   functionality.

 

Which means that there is no ambiguity in that case = with the current default direction: “the destination is the DOTS = client domain”.

 

No matter how roles were =
negotiated, but as far as each an agent acts as a client and its peer as =
a server, things are clear. 
 
<= pre>Of course we can always define = an optional parameter for this, but it is preferable to have a case for = it.  
 
<= pre>Cheers,= 
Med

 

De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarRed= dy_Konda@McAfee.com]
Envoy=E9 : jeudi 15 f=E9vrier = 2018 16:31
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : = RE: draft-ietf-dots-data-channel: Filter = Direction

 

The filtering rule for = outgoing traffic is required for the "Suppression of outbound DDoS = traffic originating from a consumer broadband access network" use = case discussed in https://tools.ietf.org/html/draft-ietf-dots-use-cases-09#section-3= .2.1. In this use case, the CPE initially acts as a DOTS client but = after the TCP connection is established, reverses its role and acts as = DOTS server (see https://tools.ietf.org/html/= rfc8071). The access network can then program the CPE using the DOTS = data channel to block the DDoS attack traffic originated from the = compromised devices in the

local customer network. =

 

Cheers,

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of mohamed.boucadair@orange.com=
Sent: Wednesday, February 14, 2018 1:49 PM
To: = dots@ietf.org
Subject: = [Dots] draft-ietf-dots-data-channel: Filter = Direction

 

Hi = all,

 

As = agreed during the interim, there are some issues that need fixes in the = data-channel spec. We would like to hear from the WG to know what to = record in the document.

 

Issue = description: Do we need to support explicit “direction” in = filtering rules (“in”/“out”)? That is, do we = allow a DOTS client to create filters for both incoming and outgoing = traffic?

 

Below = a proposal for discussion:

–    The current default = direction is aligned with the nature of DDoS attacks targeted by DOTS: = i.e. incoming. The DOTS client domain is assumed to be the destination. = No ambiguity so far with such default behavior.

–    There is no clear = use case for the support of outgoing filtering handling in the context = of DOTS.

–    No text change is = required to the draft.

 

Any objection? =

 

Cheers,

Med =

 

------=_NextPart_000_00D3_01D3A71E.05EF9080-- From nobody Fri Feb 16 04:24:07 2018 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 5A8A6124F57 for ; Fri, 16 Feb 2018 04:24:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 gPdgBstaFw_6 for ; Fri, 16 Feb 2018 04:24:04 -0800 (PST) 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 DD9D0124BE8 for ; Fri, 16 Feb 2018 04:24:03 -0800 (PST) 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 1emf3a-0000mI-6c; Fri, 16 Feb 2018 12:24:02 +0000 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , , References: <787AE7BB302AE849A7480A190F8B93300A0D1F93@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0D32AE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Date: Fri, 16 Feb 2018 12:24:04 -0000 Message-ID: <00e801d3a721$08806d30$19814790$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E9_01D3A721.0882B720" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLoxvz0kGpX/tRyz6XeuCXxpheRlwMZabEuApwt0GoCITdLGqE9+Cqg Content-Language: en-gb Archived-At: Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields 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, 16 Feb 2018 12:24:06 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00E9_01D3A721.0882B720 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I like the concept of =93+--ro capabilities=93 allowing for future = support as the DOS server becomes more mature in its capabilities. =20 If a DOTS client includes a filtering field parameter that is not = currently supported, should the parameter be ignored (and not returned for a GET), = or the request rejected? =20 It is conceivable that a DOTS client has 2 DOTS servers (one possibly a backup, or 2 different ISPs), which may have differing filtering field parameter support capabilities. Adding in intelligence code to work out what is / is not allowed may not be practical in a (memory or cpu) constrained environment of the DOTS client. =20 That said, I think we need to define the minimum set of supported = parameters =96 e.g. protocol, source / dest ports, source / dest IPv4 prefixes, = source / dest IPv6 prefixes, fragments and icmp type/code.=20 =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 16 February 2018 10:18 To: mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields =20 Hi Med, =20 Please see inline [TR2] =20 From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] = Sent: Friday, February 16, 2018 1:45 PM To: Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: RE: draft-ietf-dots-data-channel: Filtering Fields =20 Re-, =20 Please see inline.=20 =20 Cheers, Med =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, = Tirumaleswar Reddy Envoy=E9 : vendredi 16 f=E9vrier 2018 08:00 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields =20 From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: Wednesday, February 14, 2018 1:49 PM To: dots@ietf.org Subject: [Dots] draft-ietf-dots-data-channel: Filtering Fields =20 Hi all,=20 =20 As agreed during the interim, there are some issues that need fixes in = the data-channel spec. We would like to hear from the WG to know what to = record in the document.=20 =20 Issue description: Should we support all of the match fields defined by =93ietf-packet-fields=94 or do we need to define a minimum supported = set?=20 =20 [TR] I don=92t see the need to support all the match fields, define a = minimum supported set (don=92t see the use for acl-eth-header-fields for DOTS = use cases). =20 [Med] Agree that acl-eth-header-fields aren=92t required. The text is = already clear about this: =20 DOTS implementations MUST support the following matching criteria: match based on the IP header (IPv4 and IPv6), match based on the transport header (TCP, UDP, and ICMP), and any combination thereof. =20 The question is whether we need to go further and mandate (or not) the support of matching based on specific fields: dscp, ecn, ttl,=85 = flow-label, =85 tcp sequence-number, tcp flags, =85 =20 =20 [TR2] https://tools.ietf.org/html/draft-ietf-netmod-acl-model-16 uses the = feature statements in the YANG model allowing vendors to advertise match rules = they are capable and willing to support but not at the field-level. The = problem is router implementations today don=92t support ACLs with tcp = sequence-number, acknowledgement-number, window-size etc but support TCP flags. If the = server could convey the list of match criteria supported, it not only allows = the client to convey the supported match rules but also allows the server in future to advertise the new supported match fields. =20 =20 Would it be useful for a client to retrieve the list of match criteria supported by a DOTS server?=20 =20 [TR2] Yes.=20 =20 -Tiru =20 [TR] The YANG model supported by the DOTS server can retrieved by the = DOTS client using RESTCONF to determine the match criteria supported by the server.=20 [Med] I=92m afraid this is not the same functionality. If we need to = allow a server to return its supported match criteria, this should be allowed by = the module. For example, the module may include the following (example):=20 =20 +--ro capabilities | +--ro match-header* | | identityref | +--ro transport-protocols* [protocol-id] | | +--ro protocol-id uint8 | | +--ro protocol-name? string | +--ro dscp-support? boolean | +--ro ecn-support? boolean | +--ro length-support? boolean | +--ro ttl-support? boolean | +--ro protocol-support? boolean =20 The client can ask the server to return its supported match criteria. = The server will indicate the exact set of fields it supports.=20 =20 I=92m not expressing a preference to have this in the model, but I=92m clarifying how it would look like.=20 =20 -Tiru =20 Please comment.=20 =20 Cheers, Med ------=_NextPart_000_00E9_01D3A721.0882B720 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 
I like the =
concept of “+--ro =
capabilities“ =
allowing for future support as the DOS server becomes more mature in its =
capabilities.
 
If a DOTS =
client includes a filtering field parameter that is not currently =
supported, should the parameter be ignored (and not returned for a GET), =
or the request rejected?
 
It is =
conceivable that a DOTS client has 2 DOTS servers (one possibly a =
backup, or 2 different ISPs), which may have differing filtering field =
parameter support capabilities.=A0 Adding in intelligence code to work =
out what is / is not allowed may not be practical in a (memory or cpu) =
constrained environment of the DOTS =
client.
 
That said, I =
think we need to define the minimum set of supported parameters – =
e.g. protocol, source / dest ports, =A0source / dest IPv4 prefixes, =
source / dest IPv6 prefixes, fragments and icmp type/code. =

 
Regards
 
Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = Konda, Tirumaleswar Reddy
Sent: 16 February 2018 = 10:18
To: mohamed.boucadair@orange.com; = dots@ietf.org
Subject: Re: [Dots] = draft-ietf-dots-data-channel: Filtering = Fields

 

Hi = Med,

 

Please see inline = [TR2]

 

From: mohamed.boucadair@orange.com= [mailto:mohamed.boucadair@ora= nge.com]
Sent: Friday, February 16, 2018 1:45 = PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; dots@ietf.org
Subject: RE: = draft-ietf-dots-data-channel: Filtering = Fields

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] = De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : = vendredi 16 f=E9vrier 2018 08:00
=C0 : BOUCADAIR Mohamed = IMT/OLN; dots@ietf.org
Objet : = Re: [Dots] draft-ietf-dots-data-channel: Filtering = Fields

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of mohamed.boucadair@orange.com=
Sent: Wednesday, February 14, 2018 1:49 PM
To: = dots@ietf.org
Subject: = [Dots] draft-ietf-dots-data-channel: Filtering = Fields

 

Hi = all,

 

As = agreed during the interim, there are some issues that need fixes in the = data-channel spec. We would like to hear from the WG to know what to = record in the document.

 

Issue = description: Should we support all of the match fields defined by = “ietf-packet-fields” or do we need to define a minimum = supported set?

 

[TR] I don’t see the need to support all the match = fields, define a minimum supported set (don’t see the use for = acl-eth-header-fields for DOTS use cases). =  

[Med] = Agree that acl-eth-header-fields aren’t required. The text is = already clear about this:

 

DOTS implementations MUST support the = following

   matching criteria: match = based on the IP header (IPv4 and IPv6),

   match based on the transport = header (TCP, UDP, and ICMP), and any

   combination = thereof.

 

The question is whether we need to go further and =
mandate (or not) the support of matching based on specific fields: dscp, =
ecn, ttl,… flow-label, … tcp =
sequence-number, tcp flags, …  
 =

[TR2] =
https://tools.ietf.org/html/draft-ietf-netmod-acl-model-16 uses the =
feature statements in the YANG model allowing vendors to advertise match =
rules they are capable and willing to support but not at the =
field-level. The problem is router implementations today don’t =
support ACLs with tcp sequence-number, acknowledgement-number, =
window-size etc but support TCP flags. If the server could convey the =
list of match criteria supported, it not only allows the client to =
convey the supported match rules but also allows the server in future to =
advertise the new supported match fields. =
  

 

Would = it be useful for a client to retrieve the list of match criteria = supported by a DOTS server?

 

[TR2] Yes.

 

-Tiru

 

[TR] The YANG model supported by = the DOTS server can retrieved by the DOTS client using RESTCONF to = determine the match criteria supported by the server. =

[Med] = I’m afraid this is not the same functionality. If we need to allow = a server to return its supported match criteria, this should be allowed = by the module. For example, the module may include the following = (example):

 

          =
      +--ro =
capabilities
          =
      |  +--ro =
match-header*
          =
      |  =
|       =
identityref
          =
      |  +--ro transport-protocols* =
[protocol-id]
          =
      |  |  +--ro =
protocol-id      =
uint8
          =
      |  |  +--ro =
protocol-name?   string
          =
      |  +--ro dscp-support? =
      boolean
<=
span =
lang=3DEN-US>          =
      |  +--ro ecn-support? =
       boolean
= 
          =
      |  +--ro length-support? =
    boolean
          =
      |  +--ro ttl-support? =
       boolean
= 
          =
      |  +--ro protocol-support? =
  boolean
 
The =
client can ask the server to return its supported match criteria. The server will indicate =
the exact set of fields it supports. =

 
I’m not expressing a preference =
to have this in the model, but I’m clarifying how it would look =
like.

 

-Tiru

 

Please comment. =

 

Cheers,

Med

------=_NextPart_000_00E9_01D3A721.0882B720-- From nobody Fri Feb 16 04:33:25 2018 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 175A2124F57 for ; Fri, 16 Feb 2018 04:33:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 GcoJf7IEp9Xi for ; Fri, 16 Feb 2018 04:33:23 -0800 (PST) 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 3081E124BE8 for ; Fri, 16 Feb 2018 04:33:23 -0800 (PST) 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 1emfCb-0000ml-Gu; Fri, 16 Feb 2018 12:33:21 +0000 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , , References: <787AE7BB302AE849A7480A190F8B93300A0D1F64@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Date: Fri, 16 Feb 2018 12:33:23 -0000 Message-ID: <010101d3a722$55e16d80$01a44880$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0102_01D3A722.55E16D80" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQCZgH+FX8hqx8D0BXUpkrcJocGKKgK/1WszpgVDy/A= Content-Language: en-gb Archived-At: Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Activation 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, 16 Feb 2018 12:33:25 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0102_01D3A722.55E16D80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I also agree with the proposal for the default of "mitigation-time". However, when "immediate" is used, is this to be client specific, or across globally the whole of the domain? - this effects how the destination prefix is going to be checked / instantiated. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 15 February 2018 15:42 To: mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Activation I agree with the proposal. In most use cases during peace time, the DOTS client can enforce the black-list/white-list filtering rules in its domain, so the default value of "mitigation-time" for the activation-type. Cheers, -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: Wednesday, February 14, 2018 1:48 PM To: dots@ietf.org Subject: [Dots] draft-ietf-dots-data-channel: Filter Activation Hi all, As agreed during the interim, there are some issues that need fixes in the data-channel spec. We would like to hear from the WG to know what to record in the document. Issue description: Do we assume that all filtering rules, communicated by DOTS clients, are activated by default or only when a mitigation is active? Below a proposal for discussion: - We should support both: o Immediate activation is useful in deployment cases where filtering is used to anticipate some attacks and therefore avoid that access resources are abused when an attack become effective. This is typically the case where DOTS server is deployed by access providers. o The reasoning may not be the same if the DOTS service is on the cloud. - The intended action will be governed by a new attribute called "activation-type" which can be set to "immediate" or "mitigation-time". This parameter will be supplied by a DOTS client in a filter creation request. - Which default value to use if no "activation-type" is supplied by a client? Please comment. Cheers, Med ------=_NextPart_000_0102_01D3A722.55E16D80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I also agree with the proposal for the default = of “mitigation-time”.

 

However, when = “immediate” is used, is this to be client specific, or = across globally the whole of the domain?

- this effects how the = destination prefix is going to be checked / = instantiated.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = Konda, Tirumaleswar Reddy
Sent: 15 February 2018 = 15:42
To: mohamed.boucadair@orange.com; = dots@ietf.org
Subject: Re: [Dots] = draft-ietf-dots-data-channel: Filter = Activation

 

I agree with the proposal. In most use cases during peace = time, the DOTS client can enforce the black-list/white-list filtering = rules in its domain, so the default value of = “mitigation-time” for the activation-type. =

 

Cheers,

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of mohamed.boucadair@orange.com=
Sent: Wednesday, February 14, 2018 1:48 PM
To: = dots@ietf.org
Subject: = [Dots] draft-ietf-dots-data-channel: Filter = Activation

 

Hi = all,

 

As = agreed during the interim, there are some issues that need fixes in the = data-channel spec. We would like to hear from the WG to know what to = record in the document.

 

Issue = description: Do we assume that all filtering rules, communicated by DOTS = clients, are activated by default or only when a mitigation is = active?

 

Below = a proposal for discussion:

–    We should support = both:

o    Immediate = activation is useful in deployment cases where filtering is used to = anticipate some attacks and therefore avoid that access resources are = abused when an attack become effective. This is typically the case where = DOTS server is deployed by access providers.

o    The reasoning may = not be the same if the DOTS service is on the = cloud.

–    The intended action = will be governed by a new attribute called “activation-type” = which can be set to “immediate” or = “mitigation-time”. This parameter will be supplied by a DOTS = client in a filter creation request.

–    Which default value = to use if no “activation-type” is supplied by a = client?

 

Please comment. =

 

Cheers,

Med

------=_NextPart_000_0102_01D3A722.55E16D80-- From nobody Fri Feb 16 04:38:54 2018 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 ECA5A124BE8 for ; Fri, 16 Feb 2018 04:38:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 dQcMWHNM6j0Q for ; Fri, 16 Feb 2018 04:38:51 -0800 (PST) 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 E8A72120713 for ; Fri, 16 Feb 2018 04:38:50 -0800 (PST) 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 1emfHt-0000nF-Ds; Fri, 16 Feb 2018 12:38:49 +0000 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , , References: <787AE7BB302AE849A7480A190F8B93300A0D1FD4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Date: Fri, 16 Feb 2018 12:38:51 -0000 Message-ID: <011701d3a723$1952d830$4bf88890$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0118_01D3A723.19554930" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIUreNBqTKMUjWKiR2GS2Zv39X3cgJN+3UFoxJ3SjA= Content-Language: en-gb Archived-At: Subject: Re: [Dots] draft-ietf-dots-data-channel: Lifetime handling 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, 16 Feb 2018 12:38:53 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0118_01D3A723.19554930 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Option 3 looks good to me. However do we need to add in a "when it will expire" parameter in a GET response so that a restarting DOTS client knows it has to do a refresh within a certain time? Separately, I think Option 4 should still be in place as a recommendation to manage stale DOTS clients (as determined by cuid) that have not been active on the signal and data channel for a period of time. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 16 February 2018 03:47 To: mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Lifetime handling Option 3 looks good to me. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: Wednesday, February 14, 2018 1:53 PM To: dots@ietf.org Subject: [Dots] draft-ietf-dots-data-channel: Lifetime handling Hi all, As agreed during the interim, there are some issues that need fixes in the data-channel spec. We would like to hear from the WG to know what to record in the document. Issue description: It was agreed to associate a lifetime with entries instantiated by a DOTS client (-12). The current behavior in the spec is as follows: - A lifetime hint is included in the resource creation request by the client. - The server may honor the suggested lifetime or assign a distinct value as per its local policies. When a distinct value is used by the server, the issue is how to notify the client given that RFC8040 says: "If the POST method succeeds, a "201 Created" status-line is returned and there is no response message-body." * Option 1: A work around would be to relax the above constraint at the server side to include a message-body even for "201 Created", but this is not a clean design as it requires changes to the base RESTCONF spec. * Option 2: Change completely the data module so that we can make use of operations (action/rpc). For example, these operations can be defined: +---x activate-filtering | +---w input | | +---w name string | | +---w lifetime-hint int32 | +--ro output | +--ro name string | +--ro lifetime int32 +---x deactivate-filtering +---w input +---w name string This approach will require major changes to the document. This may not be justified given that in some cases no lifetime is included at all. * Option 3: This one assumes that servers must maintain an entry for a minimum period (e.g., 1 week, 1 month). No Lifetime is included in a request. If no refresh request is seen from the client, the server removes expired entries. This one requires minor changes to the document. * Option 4: This approach does not associate a lifetime with filtering/alias entries but maintains an inactivity timer of a given DOTS client. This option does not allow to clean stale mappings that may be induced by clients that do not remove their state appropriately. Recommended position: - Proceed with option 3. Any objection? Cheers, Med ------=_NextPart_000_0118_01D3A723.19554930 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Option 3 looks good to = me.

 

However do we need to = add in a “when it will expire” parameter in  a GET = response so that a restarting DOTS client knows it has to do a refresh = within a certain time?

 

Separately, I think = Option 4 should still be in place as a recommendation to manage stale = DOTS clients (as determined by cuid) that have not been active on the = signal and data channel for a period of time.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = Konda, Tirumaleswar Reddy
Sent: 16 February 2018 = 03:47
To: mohamed.boucadair@orange.com; = dots@ietf.org
Subject: Re: [Dots] = draft-ietf-dots-data-channel: Lifetime = handling

 

Option 3 looks good to = me.

 

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of mohamed.boucadair@orange.com=
Sent: Wednesday, February 14, 2018 1:53 PM
To: = dots@ietf.org
Subject: = [Dots] draft-ietf-dots-data-channel: Lifetime = handling

 

Hi = all,

 

As = agreed during the interim, there are some issues that need fixes in the = data-channel spec. We would like to hear from the WG to know what to = record in the document.

 

Issue = description: It was agreed to associate a lifetime with entries = instantiated by a DOTS client (-12). The current behavior in the spec is = as follows:

-    A lifetime hint is = included in the resource creation request by the = client.

-    The server may = honor the suggested lifetime or assign a distinct value as per its local = policies.   

 

When a = distinct value is used by the server, the issue is how to notify the = client given that RFC8040 says:

 

"If the POST method succeeds, a "201 Created" = status-line is returned and there is no response = message-body."

 

* = Option 1:

 

A work = around would be to relax the above constraint at the server side to = include a message-body even for “201 Created”, but this is not a clean design as it = requires changes to the base RESTCONF spec.

 

* = Option 2:

 

Change = completely the data module so that we can make use of operations = (action/rpc). For example, these operations can be defined: =

 

          = +---x activate-filtering

          = |  +---w input

          = |  |  +---w = name           &nb= sp; string

          = |  |  +---w lifetime-hint    = int32

          = |  +--ro output

          = |     +--ro = name        = string

   =        |     = +--ro lifetime    int32

          = +---x deactivate-filtering

          =    +---w input

          =       +---w name    = string

 

This approach will require major changes to the document. This may = not be justified given that in some cases no lifetime is included at = all.

 

* Option 3:

 

This = one assumes that servers must maintain an entry for a minimum period = (e.g., 1 week, 1 month). No Lifetime is included in a request. If no = refresh request is seen from the client, the server removes expired = entries.

 

This = one requires minor = changes to the document. =  

 

* = Option 4:

 

This = approach does not associate a lifetime with filtering/alias entries but = maintains an inactivity timer of a given DOTS client. This option does = not allow to clean stale = mappings that may be = induced by clients that do not remove their state appropriately. =

 

Recommended position:

–    Proceed with option = 3.

 

Any objection? =

 

Cheers,

Med =

 

------=_NextPart_000_0118_01D3A723.19554930-- From nobody Fri Feb 16 04:40:32 2018 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 2C3D0124F57 for ; Fri, 16 Feb 2018 04:40:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 chgV-T2tOd6t for ; Fri, 16 Feb 2018 04:40:28 -0800 (PST) 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 532BF124BE8 for ; Fri, 16 Feb 2018 04:40:28 -0800 (PST) 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 1emfJS-0000nW-Ov; Fri, 16 Feb 2018 12:40:26 +0000 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , , References: <787AE7BB302AE849A7480A190F8B93300A0D1FAE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Date: Fri, 16 Feb 2018 12:40:28 -0000 Message-ID: <012a01d3a723$53591f80$fa0b5e80$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_012B_01D3A723.53591F80" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE1mhcv4PUgGNsOCwP/7SIpCi5+IAImRwcLpNHcLuA= Content-Language: en-gb Archived-At: Subject: Re: [Dots] draft-ietf-dots-data-channel: Global or Per-client Filters 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, 16 Feb 2018 12:40:30 -0000 This is a multipart message in MIME format. ------=_NextPart_000_012B_01D3A723.53591F80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I agree that Filters activated during a mitigation request should be on a per client basis. See my comment/question in "[Dots] draft-ietf-dots-data-channel: Filter Activation" about whether immediate activation should be on a per client basis, or global. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 16 February 2018 03:50 To: mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Global or Per-client Filters Looks good, no objections from my side. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: Wednesday, February 14, 2018 1:51 PM To: dots@ietf.org Subject: [Dots] draft-ietf-dots-data-channel: Global or Per-client Filters Hi all, As agreed during the interim, there are some issues that need fixes in the data-channel spec. We would like to hear from the WG to know what to record in the document. Issue description: If filters are activated only at the mitigation time, do we consider filters created by a client are globally available to all clients of the same domain or not? Below a proposal for discussion: - Filters that are activated only during mitigation time are on a per-client basis. Any objection? Cheers, Med ------=_NextPart_000_012B_01D3A723.53591F80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree that Filters activated during a = mitigation request should be on a per client = basis.

 

See my comment/question = in “[Dots] draft-ietf-dots-data-channel: Filter Activation” = about whether immediate activation should be on a per client basis, or = global.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = Konda, Tirumaleswar Reddy
Sent: 16 February 2018 = 03:50
To: mohamed.boucadair@orange.com; = dots@ietf.org
Subject: Re: [Dots] = draft-ietf-dots-data-channel: Global or Per-client = Filters

 

Looks good, no = objections from my side.

 

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of mohamed.boucadair@orange.com=
Sent: Wednesday, February 14, 2018 1:51 PM
To: = dots@ietf.org
Subject: = [Dots] draft-ietf-dots-data-channel: Global or Per-client = Filters

 

Hi = all,

 

As = agreed during the interim, there are some issues that need fixes in the = data-channel spec. We would like to hear from the WG to know what to = record in the document.

 

Issue = description: If filters are activated only at the mitigation time, do we = consider filters created by a client are globally available to all = clients of the same domain or not?

 

Below = a proposal for discussion:

–    Filters that are = activated only during mitigation time are on a per-client basis. =

 

Any objection? =

 

Cheers,

Med

------=_NextPart_000_012B_01D3A723.53591F80-- From nobody Fri Feb 16 04:55:47 2018 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 5ED45124F57 for ; Fri, 16 Feb 2018 04:55:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 w_MjSBj-hPR5 for ; Fri, 16 Feb 2018 04:55:43 -0800 (PST) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EDB41241F8 for ; Fri, 16 Feb 2018 04:55:43 -0800 (PST) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 3234D121261; Fri, 16 Feb 2018 13:55:41 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.24]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 0A2BE80080; Fri, 16 Feb 2018 13:55:41 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7D.corporate.adroot.infra.ftgroup ([fe80::9044:c5ee:4dd2:4f16%19]) with mapi id 14.03.0382.000; Fri, 16 Feb 2018 13:55:40 +0100 From: To: Jon Shallow , "'Konda, Tirumaleswar Reddy'" , "dots@ietf.org" Thread-Topic: [Dots] draft-ietf-dots-data-channel: Filtering Fields Thread-Index: AdOlbICGgF2MxoHnQied7J+cvW2QAAMZabEuApwt0GoCITdLGqE9+CqgoXk/D0A= Date: Fri, 16 Feb 2018 12:55:40 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0D366E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300A0D1F93@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0D32AE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00e801d3a721$08806d30$19814790$@jpshallow.com> In-Reply-To: <00e801d3a721$08806d30$19814790$@jpshallow.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A0D366EOPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields 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, 16 Feb 2018 12:55:45 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A0D366EOPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Jon, Thank you for sharing your thoughts. Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 16 f=E9vrier 2018 13:24 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields I like the concept of "+--ro capabilities" allowing for future support as t= he DOS server becomes more mature in its capabilities. If a DOTS client includes a filtering field parameter that is not currently= supported, should the parameter be ignored (and not returned for a GET), o= r the request rejected? [Med] I would vote for rejecting the request. The client should only use ma= tch criteria that are understood by the server; otherwise there will be dif= ferent expectation from the service. It is conceivable that a DOTS client has 2 DOTS servers (one possibly a bac= kup, or 2 different ISPs), which may have differing filtering field paramet= er support capabilities. [Med] The backup/case seems odd. I would expect a feature parity for a redu= ndancy group used to provide the same service. Adding in intelligence code to work out what is / is not allowed may not = be practical in a (memory or cpu) constrained environment of the DOTS clien= t. [Med] Fair. That said, I think we need to define the minimum set of supported parameter= s - e.g. protocol, source / dest ports, source / dest IPv4 prefixes, sourc= e / dest IPv6 prefixes, fragments and icmp type/code. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 16 February 2018 10:18 To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields Hi Med, Please see inline [TR2] From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 1:45 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: draft-ietf-dots-data-channel: Filtering Fields Re-, Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 16 f=E9vrier 2018 08:00 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Wednesday, February 14, 2018 1:49 PM To: dots@ietf.org Subject: [Dots] draft-ietf-dots-data-channel: Filtering Fields Hi all, As agreed during the interim, there are some issues that need fixes in the = data-channel spec. We would like to hear from the WG to know what to record= in the document. Issue description: Should we support all of the match fields defined by "ie= tf-packet-fields" or do we need to define a minimum supported set? [TR] I don't see the need to support all the match fields, define a minimum= supported set (don't see the use for acl-eth-header-fields for DOTS use ca= ses). [Med] Agree that acl-eth-header-fields aren't required. The text is already= clear about this: DOTS implementations MUST support the following matching criteria: match based on the IP header (IPv4 and IPv6), match based on the transport header (TCP, UDP, and ICMP), and any combination thereof. The question is whether we need to go further and mandate (or not) the supp= ort of matching based on specific fields: dscp, ecn, ttl,... flow-label, ..= . tcp sequence-number, tcp flags, ... [TR2] https://tools.ietf.org/html/draft-ietf-netmod-acl-model-16 uses the f= eature statements in the YANG model allowing vendors to advertise match rul= es they are capable and willing to support but not at the field-level. The = problem is router implementations today don't support ACLs with tcp sequenc= e-number, acknowledgement-number, window-size etc but support TCP flags. If= the server could convey the list of match criteria supported, it not only = allows the client to convey the supported match rules but also allows the s= erver in future to advertise the new supported match fields. Would it be useful for a client to retrieve the list of match criteria supp= orted by a DOTS server? [TR2] Yes. -Tiru [TR] The YANG model supported by the DOTS server can retrieved by the DOTS = client using RESTCONF to determine the match criteria supported by the serv= er. [Med] I'm afraid this is not the same functionality. If we need to allow a = server to return its supported match criteria, this should be allowed by th= e module. For example, the module may include the following (example): +--ro capabilities | +--ro match-header* | | identityref | +--ro transport-protocols* [protocol-id] | | +--ro protocol-id uint8 | | +--ro protocol-name? string | +--ro dscp-support? boolean | +--ro ecn-support? boolean | +--ro length-support? boolean | +--ro ttl-support? boolean | +--ro protocol-support? boolean The client can ask the server to return its supported match criteria. The s= erver will indicate the exact set of fields it supports. I'm not expressing a preference to have this in the model, but I'm clarifyi= ng how it would look like. -Tiru Please comment. Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300A0D366EOPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Jon,

 

Thank you for sharing your thou= ghts.

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf= @jpshallow.com]
Envoy=E9 : vendredi 16 f=E9vrier 2018 13:24
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; d= ots@ietf.org
Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fiel= ds

 

I like the concept of “+--ro capabilities“ allowing for futu=
re support as the DOS server becomes more mature in its capabilities.<=
/o:p>
 
If a DOTS client includes a filtering field parameter that =
is not currently supported, should the parameter be ignored (and not return=
ed for a GET), or the request rejected?
[Med] I would vote for re=
jecting the request. The client should only use match criteria that are und=
erstood by the server; otherwise there will be different expectation from t=
he service. 
 
It is conceivable that a DOTS client has 2 DOTS servers (on=
e possibly a backup, or 2 different ISPs), which may have differing filteri=
ng field parameter support capabilities.
[Med] The backup/case see=
ms odd. I would expect a feature parity for a redundancy group used to prov=
ide the same service. 
 <=
/pre>

  Adding in intelligence code to work out what is / is=
 not allowed may not be practical in a (memory or cpu) constrained environm=
ent of the DOTS client.


[Med] Fair. 


 


That said, I think we need to define the minimum set of sup=
ported parameters – e.g. protocol, source / dest ports,  source =
/ dest IPv4 prefixes, source / dest IPv6 prefixes, fragments and icmp type/=
code. 


 


Regards


 


Jon


&n=
bsp;






From:=
 Dots [mailto:
dots-bounces@ietf.org] On B=
ehalf Of
Konda, Tirumaleswar Reddy

Sent: 16 February 2018 10:18

To: mohamed.boucadai=
r@orange.com;
dots@ietf.org

Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields






 


Hi Med,


 


Please see inline [TR2]


 








From:
mohamed.boucadair@orange.co=
m [mailto:mohamed.bouca=
dair@orange.com]


Sent: Friday, February 16, 2018 1:45 PM

To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>;
dots@ietf.org

Subject: RE: draft-ietf-dots-data-channel: Filtering Fields






 


Re-,


 


Please see inline.



 


Cheers,


Med


 








De : Dots [mailto:dots-bounces@ietf.org]
De la part de Konda, Tirumaleswar Reddy

Envoy=E9 : vendredi 16 f=E9vrier 2018 08:00

=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org

Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fiel=
ds






 


From: Dots [mailto:dots-bounces=
@ietf.org]
On Behalf Of mohamed=
.boucadair@orange.com

Sent: Wednesday, February 14, 2018 1:49 PM

To: dots@ietf.org

Subject: [Dots] draft-ietf-dots-data-channel: Filtering Fields<=
/o:p>


 


Hi all,



 


As agreed during the interim, there are som=
e issues that need fixes in the data-channel spec. We would like to hear fr=
om the WG to know what to record in the document.



 


Issue description: Should we support all of=
 the match fields defined by “ietf-packet-fields” or do we need=
 to define a minimum supported set?



 


[TR] I don’t see the need=
 to support all the match fields, define a minimum supported set (don’=
;t see the use for acl-eth-header-fields for DOTS use cases).  


[Med] Agree that acl-eth-header=
-fields aren’t required. The text is already clear about this:


 


DOTS implementation=
s MUST support the following


   matchi=
ng criteria: match based on the IP header (IPv4 and IPv6),


   match =
based on the transport header (TCP, UDP, and ICMP), and any


  
combination thereof.


 


The question is whether w=
e need to go further and mandate (or not) the support of matching based on =
specific fields: dscp, ecn, ttl,… flow-label, … tcp sequence-number, tcp flags, …  


 


[TR2] https=
://tools.ietf.org/html/draft-ietf-netmod-acl-model-16 uses the feature statem=
ents in the YANG model allowing vendors to advertise match rules they are c=
apable and willing to support but not at the field-level. The problem is ro=
uter implementations today don’t support ACLs with tcp sequence-numbe=
r, acknowledgement-number, window-size etc but support TCP flags. If the se=
rver could convey the list of match criteria supported, it not only allows =
the client to convey the supported match rules but also allows the server i=
n future to advertise the new supported match fields.   


 


Would it be useful for a client to retrieve=
 the list of match criteria supported by a DOTS server?



 


[TR2] Yes. 

 


-Tiru


 


[TR] The YANG model supported b=
y the DOTS server can retrieved by the DOTS client using RESTCONF to determ=
ine the match criteria supported by the server.



[Med] I’m afraid this is =
not the same functionality. If we need to allow a server to return its supp=
orted match criteria, this should be allowed by the module.
 For example, the module may include the following (example): 


 


      &=
nbsp;         +--ro capabilitie=
s


      &=
nbsp;         |  +--ro mat=
ch-header*


      &=
nbsp;         |  |  =
     identityref


      &=
nbsp;         |  +--ro tra=
nsport-protocols* [protocol-id]


      &=
nbsp;         |  |  +=
--ro protocol-id      uint8

      &=
nbsp;         |  |  +=
--ro protocol-name?   string


      &=
nbsp;         |  +--ro dsc=
p-support?       boolean

      &=
nbsp;         |  +--ro ecn=
-support?        boolean


      &=
nbsp;         |  +--ro len=
gth-support?     boolean


      &=
nbsp;         |  +--ro ttl=
-support?        boolean


      &=
nbsp;         |  +--ro pro=
tocol-support?   boolean


 


The client can ask the server to retu=
rn its supported match criteria. The server wil=
l indicate the exact set of fields it supports. 

 <=
/pre>

I’m not expressing =
a preference to have this in the model, but I’m clarifying how it wou=
ld look like. 

 


-Tiru


 


Please com=
ment.



 =
;


Cheers,


Med=
<=
/o:p>
--_000_787AE7BB302AE849A7480A190F8B93300A0D366EOPEXCLILMA3corp_-- From nobody Fri Feb 16 05:14:27 2018 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 0C72812D876 for ; Fri, 16 Feb 2018 05:14:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 z-XlyjQsVqTe for ; Fri, 16 Feb 2018 05:14:15 -0800 (PST) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 649A3128954 for ; Fri, 16 Feb 2018 05:14:15 -0800 (PST) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1518786854; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=7 ZyC/gTAYfgZMeNJPSrwUAQSPJ15F5NDifAlUASYFV M=; b=fAdCAu4egOQOY8wRskR7FYdA3mujUsls5n3aJvqxN01X L2zeBXiBqcz0cLsWDg0Po8ul4waQoBjvBurB4JLp118XJlGX4O tJTcpxCpVVFzL3jmwnBtWRQTeWHayLqzbpC58LxmqR09LIfB3o yQlp4grY00ZDFmhFU+L2WVyqnSc= Received: from MIVEXAPP1N01.corpzone.internalzone.com (mivexapp1n01.corpzone.internalzone.com [10.48.48.88]) by MIVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 4a8a_c055_c1b2a13e_b776_400e_9ebe_8ccefdaae59b; Fri, 16 Feb 2018 07:14:13 -0600 Received: from MIVEXUSR1N04.corpzone.internalzone.com (10.48.48.84) by MIVEXAPP1N01.corpzone.internalzone.com (10.48.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 16 Feb 2018 08:13:33 -0500 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.1347.2; Fri, 16 Feb 2018 08:13:32 -0500 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.1347.2 via Frontend Transport; Fri, 16 Feb 2018 08:13:32 -0500 Received: from NAM01-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.1347.2; Fri, 16 Feb 2018 08:13:30 -0500 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1706.namprd16.prod.outlook.com (10.172.44.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.10; Fri, 16 Feb 2018 13:13:30 +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.20.0485.022; Fri, 16 Feb 2018 13:13:30 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: [Dots] Call home in the signal channel (was RE: draft-ietf-dots-data-channel: Filter Direction) Thread-Index: AQHTpx4fYQaVBSxJJEC02ounCseemaOm/iRw Date: Fri, 16 Feb 2018 13:13:29 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A0D3439@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00d201d3a71e$05ead590$11c080b0$@jpshallow.com> In-Reply-To: <00d201d3a71e$05ead590$11c080b0$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [171.61.123.199] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1706; 7:k0XeGMoykDMZOaU6YjSfnbKPwDRbYZ9nalf+13VxQKgXn17Rz9Hkldb02Ot3u3qDNbaG/zP5LSeUQ8enYFDZG5oLod5mrDwMBsE9b0ljpxro60NfNtlm16EGKerZF8dX+9PyN34O2JsSb5Naw3t0QkaF2weGRJIuKT37Oq4bs4c1fdAptWd1BjdQ+jm+WPN3REJEgX1qP4087ICrGVcMU10sCCLqH9AOmesE+VznNY7ojYjt+r8sWjrs9tG0h3Pc x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 38b8d2a5-a0ff-4847-4a3e-08d5753f12c0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:DM5PR16MB1706; x-ms-traffictypediagnostic: DM5PR16MB1706: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(18271650672692)(21748063052155)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231101)(2400082)(944501161)(10201501046)(3002001)(6041288)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(6072148)(201708071742011); SRVR:DM5PR16MB1706; BCL:0; PCL:0; RULEID:; SRVR:DM5PR16MB1706; x-forefront-prvs: 0585417D7B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(366004)(39860400002)(396003)(376002)(346002)(199004)(53754006)(189003)(32952001)(57704003)(53946003)(53936002)(110136005)(102836004)(77096007)(316002)(105586002)(25786009)(26005)(33656002)(561944003)(99286004)(80792005)(97736004)(6246003)(606006)(9686003)(236005)(6436002)(6306002)(54896002)(2501003)(55016002)(81166006)(81156014)(8936002)(7696005)(8676002)(76176011)(2900100001)(2906002)(106356001)(6116002)(3846002)(2950100002)(6506007)(74316002)(5660300001)(66066001)(53546011)(9326002)(7736002)(68736007)(229853002)(790700001)(59450400001)(966005)(3660700001)(478600001)(186003)(3280700002)(19609705001)(72206003)(86362001)(2201001)(14454004)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1706; 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) x-microsoft-antispam-message-info: OofMmrAMLiXwPjR8q/d/tUrJoJPB6KR12rfwX+WADwA2K0FRf8wD46r/wb6TAZI7oJxeJ8bUTtJ2JInMMY0LtQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB17883F3E5673E3FF52BF88B3EACB0DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 38b8d2a5-a0ff-4847-4a3e-08d5753f12c0 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2018 13:13:29.9368 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1706 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 <6224> : inlines <6404> : streams <1779148> : uri <2593881> Archived-At: Subject: Re: [Dots] Call home in the signal channel (was RE: draft-ietf-dots-data-channel: Filter Direction) 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, 16 Feb 2018 13:14:22 -0000 --_000_DM5PR16MB17883F3E5673E3FF52BF88B3EACB0DM5PR16MB1788namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jon, Please see inline From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Friday, February 16, 2018 5:33 PM To: Konda, Tirumaleswar Reddy ; mohamed= .boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] Call home in the signal channel (was RE: draft-ietf-dot= s-data-channel: Filter Direction) Hi Tiru, The more I think about it, "Call Home" support in either the data or signal= channel makes no real sense for https://tools.ietf.org/html/draft-ietf-dot= s-use-cases-09#section-3.2.1 . The CPE devices don't need to trigger the D= OTS clients to get mitigation in place as it will be the provider who works= this out. [TR] No, the above use case helps the CPE isolate the compromised devices l= aunching DDoS attacks and protect other devices in the local network from g= etting infected. However, for 3.2.1, the DOTS client will need to make a mitigation request = to initiate the implementing of (previously defined) ACLs using the signal = channel as there will be a high possibility of the outbound pipe running fu= ll. [TR] ACL can be enforced with "activation" type set to "immediate" using t= he DOTS data channel itself. -Tiru Regards Jon From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of Konda, T= irumaleswar Reddy Sent: 16 February 2018 11:00 To: mohamed.boucadair@orange.com; Jon = Shallow; dots@ietf.org Subject: Re: [Dots] Call home in the signal channel (was RE: draft-ietf-dot= s-data-channel: Filter Direction) For the discussed use case https://tools.ietf.org/html/draft-ietf-dots-use-= cases-09#section-3.2.1, the CPE needs to act as a DOTS server only for the = data channel but not for the signal channel. I don't think signal-channel r= equires call home functionality, what is the use case ? -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 3:49 PM To: Jon Shallow >; Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: Call home in the signal channel (was RE: [Dots] draft-ietf-dots-da= ta-channel: Filter Direction) Hi Jon, I'm changing the title to keep track of signal-channel specific issues. Please use this one to discuss this use case. Thank you. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 16 f=E9vrier 2018 10:57 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org= Objet : RE: [Dots] draft-ietf-dots-data-channel: Filter Direction I understand the concept of call home - which makes good sense to me and rf= c8071 will, if implemented, handle the data channel and "destination" is st= ill where the 'controlled' traffic is flowing to. However, we also need call home in the signal channel. I'm not sure how th= is will be done - do we need a new CoAP Method (e.g. switch roles) - do we = need to define a different port (rfc8071 defines 4336) etc. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 16 February 2018 09:07 To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 2:19 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: draft-ietf-dots-data-channel: Filter Direction Re-, Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 16 f=E9vrier 2018 09:28 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] draft-ietf-dots-data-channel: Filter Direction There is no ambiguity in the roles. The CPE is acting as DOTS server but th= e DOTS server is initiating connection to the DOTS client in the access net= work. [Med] Don't get the last part. The server (CPE) will receive a request from= the network (client) to filter traffic exiting from that CPE. [TR] I mean to use the call home feature discussed in https://tools.ietf.or= g/html/rfc8071, though the CPE is acting as a DOTS server it will initiate = the connection (TLS or DTLS) to the DOTS client in the access network. The = call home feature helps avoid various threats like the DOTS server in the C= PE will not be subjected to DDoS attacks, and reachability is not problem e= ven if the CPE is behind NAT. The DOTS client will convey the black-list filtering in the "out" direction= to block the traffic originating from the DOTS server domain. [Med] Which corresponds to the "DOTS Server to DOTS Client" direction; that= is the DOTS client domain (access network) is the destination. All is fine= so far :) [TR] The direction is "outgoing traffic" whereas for other use cases the di= rection is "incoming traffic". I don't understand what you mean by a "optional" parameter ? [Med] I meant adding a parameter to indicate explicitly the direction. It w= ould be optional because we do already have a default direction. [TR] Okay. -Tiru -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Friday, February 16, 2018 1:24 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction Hi Tiru, There will be an ambiguity in interpreting filters if and only if the same = DOTS agents have to manipulate filters in both directions. As you rightfully mentioned, the bb use case assumes the following: In order to achieve this capability, the telemetry analysis system utilized by the broadband access provider must have DOTS client functionality, and the end-customer CPE devices must have DOTS server functionality. Which means that there is no ambiguity in that case with the current defaul= t direction: "the destination is the DOTS client domain". No matter how roles were negotiated, but as far as each an agent acts as a = client and its peer as a server, things are clear. Of course we can always define an optional parameter for this, but it is pr= eferable to have a case for it. Cheers, Med De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] Envoy=E9 : jeudi 15 f=E9vrier 2018 16:31 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: draft-ietf-dots-data-channel: Filter Direction The filtering rule for outgoing traffic is required for the "Suppression of= outbound DDoS traffic originating from a consumer broadband access network= " use case discussed in https://tools.ietf.org/html/draft-ietf-dots-use-cas= es-09#section-3.2.1. In this use case, the CPE initially acts as a DOTS cli= ent but after the TCP connection is established, reverses its role and acts= as DOTS server (see https://tools.ietf.org/html/rfc8071). The access netwo= rk can then program the CPE using the DOTS data channel to block the DDoS a= ttack traffic originated from the compromised devices in the local customer network. Cheers, -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Wednesday, February 14, 2018 1:49 PM To: dots@ietf.org Subject: [Dots] draft-ietf-dots-data-channel: Filter Direction Hi all, As agreed during the interim, there are some issues that need fixes in the = data-channel spec. We would like to hear from the WG to know what to record= in the document. Issue description: Do we need to support explicit "direction" in filtering = rules ("in"/"out")? That is, do we allow a DOTS client to create filters fo= r both incoming and outgoing traffic? Below a proposal for discussion: - The current default direction is aligned with the nature of DDoS attac= ks targeted by DOTS: i.e. incoming. The DOTS client domain is assumed to be= the destination. No ambiguity so far with such default behavior. - There is no clear use case for the support of outgoing filtering handl= ing in the context of DOTS. - No text change is required to the draft. Any objection? Cheers, Med --_000_DM5PR16MB17883F3E5673E3FF52BF88B3EACB0DM5PR16MB1788namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jon,

&nbs= p;

Please se= e inline

 

From:<= /span> Jon Shallow [mailto:s= upjps-ietf@jpshallow.com]
Sent: Friday, February 16, 2018 5:33 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; mohamed.boucadair@orange.com; dots@ietf.org
Subject: RE: [Dots] Call home in the signal channel (was RE: draft-i= etf-dots-data-channel: Filter Direction)

 

Hi Tiru= ,

&n= bsp;

The mor= e I think about it, “Call Home” support in either the data or s= ignal channel makes no real sense for https://tools.iet= f.org/html/draft-ietf-dots-use-cases-09#section-3.2.1 .  The CPE d= evices don’t need to trigger the DOTS clients to get mitigation in place as it will be the provider who works this out.<= o:p>

&nbs= p;

[TR] No, = the above use case helps the CPE isolate the compromised devices launching = DDoS attacks and protect other devices in the local network from getting in= fected.

&nbs= p;

However, = for 3.2.1, the DOTS client will need to make a mitigation request to initia= te the implementing of (previously defined) ACLs using the signal channel a= s there will be a high possibility of the outbound pipe running full.

&nbs= p;

[TR] ACL = can be enforced  with “activation” type set to “imme= diate” using the DOTS data channel itself.

&nbs= p;

-Tiru

&nbs= p;

Regards

&nbs= p;

Jon

From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 16 February 2018 11:00
To: mohamed.boucadai= r@orange.com; Jon Shallow; dots@ietf.org
Subject: Re: [Dots] Call home in the signal channel (was RE: draft-i= etf-dots-data-channel: Filter Direction)

 

For the discussed use case https://tools.ietf.or= g/html/draft-ietf-dots-use-cases-09#section-3.2.1, the CPE needs to act as a DOTS server only for the data channel but not fo= r the signal channel. I don’t think signa= l-channel requires call home functionality, what is the use case ?

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Friday, February 16, 2018 3:49 PM
To: Jon Shallow <sup= jps-ietf@jpshallow.com>; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org
Subject: Call home in the signal channel (was RE: [Dots] draft-ietf-= dots-data-channel: Filter Direction)

 

Hi Jon,

 

I’m changing the title to keep track of = signal-channel specific issues.

 

Please use this one to discuss this use case.<= o:p>

 

Thank you.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : vendredi 16 f=E9vrier 2018 10:57
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; <= a href=3D"mailto:dots@ietf.org"> dots@ietf.org
Objet : RE: [Dots] draft-ietf-dots-data-channel: Filter Directi= on

 

I under= stand the concept of call home – which makes good sense to me and rfc= 8071 will, if implemented, handle the data channel and “destination&#= 8221; is still where the ‘controlled’ traffic is flowing to.

&n= bsp;

However= , we also need call home in the signal channel.  I’m not sure ho= w this will be done – do we need a new CoAP Method (e.g. switch roles= ) – do we need to define a different port (rfc8071 defines 4336) etc.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 16 February 2018 09:07
To: mohamed.boucadai= r@orange.com; dots@ietf.org
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction

 

From:<= /span> mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Friday, February 16, 2018 2:19 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: RE: draft-ietf-dots-data-channel: Filter Direction

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : vendredi 16 f=E9vrier 2018 09:28
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : Re: [Dots] draft-ietf-dots-data-channel: Filter Directi= on

 

There is = no ambiguity in the roles. The CPE is acting as DOTS server but the DOTS se= rver is initiating connection to the DOTS client in the access network.

[Med] Don’t g= et the last part. The server (CPE) will receive a request from the network = (client) to filter traffic exiting from that CPE.

&nbs= p;

[TR] I me= an to use the call home feature discussed in https://tools.ietf.org/html= /rfc8071, though the CPE is acting as a DOTS server it will initiate th= e connection (TLS or DTLS) to the DOTS client in the access network. The ca= ll home feature helps avoid various threats like the DOTS server in the CPE will not be subjected to DDoS atta= cks, and reachability is not problem even if the CPE is behind NAT.

 

The DOTS = client will convey the black-list filtering in the “out” direct= ion to block the traffic originating from the DOTS server domain.

[Med] Which corresp= onds to the “DOTS Server to DOTS Client” direction; that is the= DOTS client domain (access network) is the destination. All is fine so far :)

&nbs= p;

&nbs= p;

[TR] The = direction is “outgoing traffic” whereas for other use cases the= direction is “incoming traffic”.

 

I donR= 17;t understand what you mean by a “optional” parameter ?<= /o:p>

[Med] I meant addin= g a parameter to indicate explicitly the direction. It would be optional be= cause we do already have a default direction.

&nbs= p;

[TR] Okay= .

&nbs= p;

-Tiru

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed= .boucadair@orange.com
Sent: Friday, February 16, 2018 1:24 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction

 

Hi Tiru,

 

There will be an ambiguity in interpreting fil= ters if and only if the same DOTS agents have to manipulate filters in both= directions.

 

As you rightfully mentioned, the bb use case a= ssumes the following:

 

   In order to achieve t= his capability, the telemetry analysis system

   utilized by the broad= band access provider must have DOTS client

   functionality, and th= e end-customer CPE devices must have DOTS server

   functionality.

 

Which means that there is no ambiguity in that= case with the current default direction: “the destination is the DOT= S client domain”.

 

No matter how roles were negotiated, but=
 as far as each an agent acts as a client and its peer as a server, things =
are clear. 
 
Of course we can always define an option=
al parameter for this, but it is preferable to have a case for it.  
 
Cheers,
Med

 

De : Konda, Tirumaleswar Reddy [mailto:Tirumaleswar= Reddy_Konda@McAfee.com]
Envoy=E9 : jeudi 15 f=E9vrier 2018 16:31
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: draft-ietf-dots-data-channel: Filter Direction=

 

The filte= ring rule for outgoing traffic is required for the "Suppression of out= bound DDoS traffic originating from a consumer broadband access network&quo= t; use case discussed in https://tools.ietf.org/html/draft-ietf-dots-use-cases-09#section-3.2.1.= In this use case, the CPE initially acts as a DOTS client but after the TC= P connection is established, reverses its role and acts as DOTS server (see https://tools.ietf.org/html= /rfc8071). The access network can then program the CPE using the DOTS d= ata channel to block the DDoS attack traffic originated from the compromise= d devices in the

local cus= tomer network.

&nbs= p;

Cheers,

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed= .boucadair@orange.com
Sent: Wednesday, February 14, 2018 1:49 PM
To: dots@ietf.org
Subject: [Dots] draft-ietf-dots-data-channel: Filter Direction<= /o:p>

 

Hi all,

 

As agreed during the interim, there are some issues that n= eed fixes in the data-channel spec. We would like to hear from the WG to kn= ow what to record in the document.

 

Issue description: Do we need to support explicit “d= irection” in filtering rules (“in”/“out”)? Th= at is, do we allow a DOTS client to create filters for both incoming and ou= tgoing traffic?

 

Below a proposal for discussion:

– = ;   The current default direction is aligned with the nature of DDoS attacks t= argeted by DOTS: i.e. incoming. The DOTS client domain is assumed to be the= destination. No ambiguity so far with such default behavior.

– = ;   There is no clear use case for the support of outgoing filtering handling = in the context of DOTS.

– = ;   No text change is required to the draft.

 <= /p>

Any objection?

 <= /p>

Cheers,=

Med

 

--_000_DM5PR16MB17883F3E5673E3FF52BF88B3EACB0DM5PR16MB1788namp_-- From nobody Fri Feb 16 05:18:49 2018 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 CA823128954 for ; Fri, 16 Feb 2018 05:18:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.33 X-Spam-Level: X-Spam-Status: No, score=-4.33 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 6jEGThncaivN for ; Fri, 16 Feb 2018 05:18:46 -0800 (PST) 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 659E2127333 for ; Fri, 16 Feb 2018 05:18:45 -0800 (PST) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1518787111; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=Ozs7HOYeHkPzKbPsul126wTbIpXLZeBTFb80NO /vVKs=; b=Mjr3YhPiZnSNPcijx47YWeCax6LZCfIQZi4CYMEe MGFbO2JAg/I8uHr4//dyKG+4f0Z3vnMbTIU2I4aWNfxcGWHNhC Du8RkyWJWwiWsVbtereB4yLSNYP42ANZT0Gh27txKsaWjNfBlF jabRQOC/04sqVE+Pd2cUrSTSQoUQ8hE= Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 40da_b78f_5453fcfd_f694_4593_9116_e6a4d603d2b4; Fri, 16 Feb 2018 07:18:30 -0600 Received: from DNVEXUSR1N08.corpzone.internalzone.com (10.44.48.81) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 16 Feb 2018 06:18:16 -0700 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXUSR1N08.corpzone.internalzone.com (10.44.48.81) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Fri, 16 Feb 2018 06:18:16 -0700 Received: from NAM02-CY1-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.1347.2; Fri, 16 Feb 2018 06:17:50 -0700 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB2342.namprd16.prod.outlook.com (52.132.142.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.18; Fri, 16 Feb 2018 13:18: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.20.0485.022; Fri, 16 Feb 2018 13:18:14 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: [Dots] draft-ietf-dots-data-channel: Lifetime handling Thread-Index: AdOlbQ72FAzJz3VcRLyAIRvKZ6oNtwBa6DZwABKaUIAAAUEUsA== Date: Fri, 16 Feb 2018 13:18:14 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A0D1FD4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <011701d3a723$1952d830$4bf88890$@jpshallow.com> In-Reply-To: <011701d3a723$1952d830$4bf88890$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [171.61.123.199] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB2342; 7:cqkjMT31sifDLgX1oZ+jvEMtOsjlUZEa2K4EXqXEWhqzTa3KIIxqm9XY9FqNqlp1FOmG9VQIlgpQ+vpKQNYrgTOcV0Wktgu1n4uaDDA+6gIH+RQUHG8VNP0tq9/RPp9PqOAPE72XfewEWGeDbZyXndqJ7/rTzi2XvkKPHB9T4Uz0vWIBXbMESa8eMsmL1ePi6rcSbC/xYgsJrZ37JUpXGWzLsJxjLuVv0/pnSMGnXts+qG6gy7U3e+RfZ17Lc5Dz x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 412f4c40-53e0-4df9-1ad4-08d5753fbc31 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM5PR16MB2342; x-ms-traffictypediagnostic: DM5PR16MB2342: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(18271650672692)(21748063052155)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(3002001)(10201501046)(3231101)(944501161)(93006095)(93001095)(6041288)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(6072148)(201708071742011); SRVR:DM5PR16MB2342; BCL:0; PCL:0; RULEID:; SRVR:DM5PR16MB2342; x-forefront-prvs: 0585417D7B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39860400002)(366004)(346002)(396003)(39380400002)(189003)(199004)(57704003)(32952001)(53754006)(3846002)(236005)(6116002)(55016002)(478600001)(9686003)(6306002)(54896002)(7696005)(106356001)(72206003)(66066001)(59450400001)(3280700002)(6436002)(76176011)(33656002)(81166006)(68736007)(80792005)(8676002)(2201001)(790700001)(8936002)(229853002)(19609705001)(81156014)(97736004)(6246003)(5660300001)(316002)(2501003)(7736002)(53936002)(105586002)(99286004)(25786009)(86362001)(26005)(2906002)(102836004)(110136005)(53546011)(2900100001)(186003)(14454004)(2950100002)(74316002)(77096007)(6506007)(3660700001)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB2342; 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) x-microsoft-antispam-message-info: x3/o+7zza6yYkRljaC/yEc7wsIuAVVdYchm42JC90hrQTopwFWHcgoBP2l2icBeHtuRpTCfmpBpmndMLA5RWMg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB178896C45162E81A78857250EACB0DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 412f4c40-53e0-4df9-1ad4-08d5753fbc31 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2018 13:18:14.2423 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB2342 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 <6224> : inlines <6404> : streams <1779148> : uri <2593883> Archived-At: Subject: Re: [Dots] draft-ietf-dots-data-channel: Lifetime handling 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, 16 Feb 2018 13:18:49 -0000 --_000_DM5PR16MB178896C45162E81A78857250EACB0DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Friday, February 16, 2018 6:09 PM To: Konda, Tirumaleswar Reddy ; mohamed= .boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] draft-ietf-dots-data-channel: Lifetime handling Option 3 looks good to me. However do we need to add in a "when it will expire" parameter in a GET re= sponse so that a restarting DOTS client knows it has to do a refresh within= a certain time? [TR] Yes. Separately, I think Option 4 should still be in place as a recommendation t= o manage stale DOTS clients (as determined by cuid) that have not been acti= ve on the signal and data channel for a period of time. [TR] If Option 3 is used, don't see the use of Option 4. -Tiru Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 16 February 2018 03:47 To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Lifetime handling Option 3 looks good to me. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Wednesday, February 14, 2018 1:53 PM To: dots@ietf.org Subject: [Dots] draft-ietf-dots-data-channel: Lifetime handling Hi all, As agreed during the interim, there are some issues that need fixes in the = data-channel spec. We would like to hear from the WG to know what to record= in the document. Issue description: It was agreed to associate a lifetime with entries insta= ntiated by a DOTS client (-12). The current behavior in the spec is as foll= ows: - A lifetime hint is included in the resource creation request by the cl= ient. - The server may honor the suggested lifetime or assign a distinct value= as per its local policies. When a distinct value is used by the server, the issue is how to notify the= client given that RFC8040 says: "If the POST method succeeds, a "201 Created" status-line is returned and t= here is no response message-body." * Option 1: A work around would be to relax the above constraint at the server side to = include a message-body even for "201 Created", but this is not a clean desi= gn as it requires changes to the base RESTCONF spec. * Option 2: Change completely the data module so that we can make use of operations (ac= tion/rpc). For example, these operations can be defined: +---x activate-filtering | +---w input | | +---w name string | | +---w lifetime-hint int32 | +--ro output | +--ro name string | +--ro lifetime int32 +---x deactivate-filtering +---w input +---w name string This approach will require major changes to the document. This may not be j= ustified given that in some cases no lifetime is included at all. * Option 3: This one assumes that servers must maintain an entry for a minimum period (= e.g., 1 week, 1 month). No Lifetime is included in a request. If no refresh= request is seen from the client, the server removes expired entries. This one requires minor changes to the document. * Option 4: This approach does not associate a lifetime with filtering/alias entries bu= t maintains an inactivity timer of a given DOTS client. This option does no= t allow to clean stale mappings that may be induced by clients that do not = remove their state appropriately. Recommended position: - Proceed with option 3. Any objection? Cheers, Med --_000_DM5PR16MB178896C45162E81A78857250EACB0DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From:<= /span> Jon Shallow [mailto:s= upjps-ietf@jpshallow.com]
Sent: Friday, February 16, 2018 6:09 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; mohamed.boucadair@orange.com; dots@ietf.org
Subject: RE: [Dots] draft-ietf-dots-data-channel: Lifetime handling<= o:p>

 

Option = 3 looks good to me.

&n= bsp;

However= do we need to add in a “when it will expire” parameter in = ; a GET response so that a restarting DOTS client knows it has to do a refr= esh within a certain time?

 

[TR] Yes.

&n= bsp;

Separat= ely, I think Option 4 should still be in place as a recommendation to manag= e stale DOTS clients (as determined by cuid) that have not been active on t= he signal and data channel for a period of time.

 

[TR] If Option 3 is used, don&#= 8217;t see the use of Option 4.

 

-Tiru

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 16 February 2018 03:47
To: mohamed.boucadai= r@orange.com; dots@ietf.org
Subject: Re: [Dots] draft-ietf-dots-data-channel: Lifetime handling<= o:p>

 

Option 3 = looks good to me.

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed= .boucadair@orange.com
Sent: Wednesday, February 14, 2018 1:53 PM
To: dots@ietf.org
Subject: [Dots] draft-ietf-dots-data-channel: Lifetime handling=

 

Hi all,

 

As agreed during the interim, there are some issues that n= eed fixes in the data-channel spec. We would like to hear from the WG to kn= ow what to record in the document.

 

Issue description: It was agreed to associate a lifetime w= ith entries instantiated by a DOTS client (-12). The current behavior in th= e spec is as follows:

-  = ;  A lifetime hint is included in the resource creation request by the client= .

-  = ;  The server may honor the suggested lifetime or assign a distinct value as = per its local policies.   

 

When a distinct value is used by the server, the issue is = how to notify the client given that RFC8040 says:

 

"If the POST method succeeds, a "201 Created&quo= t; status-line is returned and there is no response message-body."

 

* Option 1:

 

A work around would be to relax the above constraint at th= e server side to include a message-body even for “201 Created”, but this is not a clean desi= gn as it requires changes to the base RESTCONF spec.

 

* Option 2:

 

Change completely the data module so that we can make use = of operations (action/rpc). For example, these operations can be defined:

 

        &= nbsp; +---x activate-filtering

        &= nbsp; |  +---w input

        &= nbsp; |  |  +---w name      &nb= sp;      string

        &= nbsp; |  |  +---w lifetime-hint    int32<= /o:p>

        &= nbsp; |  +--ro output

        &= nbsp; |     +--ro name     = ;   string

         =  |     +--ro lifetime    int32<= o:p>

        &= nbsp; +---x deactivate-filtering

        &= nbsp;    +---w input

        &= nbsp;       +---w name    = string

 

This approach will require major changes to the document. This may not be justified given that in some cases = no lifetime is included at all.

 

* Option 3:

 

This one assumes that servers must maintain an entry for a= minimum period (e.g., 1 week, 1 month). No Lifetime is included in a reque= st. If no refresh request is seen from the client, the server removes expired entries.

 

This one requires minor changes to the document.  

 

* Option 4:

 

This approach does not associate a lifetime with filtering= /alias entries but maintains an inactivity timer of a given DOTS client. Th= is option does not allow to clean stale mappings that may be induced by clients that do not remove their state approp= riately.

 

Recommended position:

– = ;   Proceed with option 3.

 <= /p>

Any objection?

 <= /p>

Cheers,=

Med

 

--_000_DM5PR16MB178896C45162E81A78857250EACB0DM5PR16MB1788namp_-- From nobody Fri Feb 16 05:24:47 2018 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 BBC35127333 for ; Fri, 16 Feb 2018 05:24:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 CuEHSqArZ0IQ for ; Fri, 16 Feb 2018 05:24:43 -0800 (PST) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 E9301127023 for ; Fri, 16 Feb 2018 05:24:42 -0800 (PST) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1518787481; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=f skW6yygkBGmrmbCoFZBOvPPxj0fMThviAy5SCkQnL 4=; b=N5KooN6G+J/9fZBlCpH9fI3qISJ4h2m1EYWs/aS1KBAb RYX0AXJmtCaDIltZW3xVmEGtBg6Jxya7Bfn7HP7t/WyWUKVgts ui8o57SmWASH05573F3ghU/YdQRu8du56Dm/9rPsw4NncbpWqN C4FfqS3hPL4F3BjLY2vXe/eFYKU= Received: from MIVEXAPP1N01.corpzone.internalzone.com (unknown [10.48.48.88]) by MIVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 4a8a_c578_99d0d26b_28c4_45fe_9d4e_20e040ae2f58; Fri, 16 Feb 2018 07:24:41 -0600 Received: from MIVEXUSR1N07.corpzone.internalzone.com (10.48.48.87) by MIVEXAPP1N01.corpzone.internalzone.com (10.48.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 16 Feb 2018 08:24:40 -0500 Received: from MIVEXUSR1N01.corpzone.internalzone.com (10.48.48.81) by MIVEXUSR1N07.corpzone.internalzone.com (10.48.48.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 16 Feb 2018 08:24:39 -0500 Received: from MIVO365EDGE4.corpzone.internalzone.com (10.48.176.87) by MIVEXUSR1N01.corpzone.internalzone.com (10.48.48.81) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Fri, 16 Feb 2018 08:24:39 -0500 Received: from NAM01-BY2-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.1347.2; Fri, 16 Feb 2018 08:24:37 -0500 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB2405.namprd16.prod.outlook.com (52.132.143.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.10; Fri, 16 Feb 2018 13:24: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.20.0485.022; Fri, 16 Feb 2018 13:24:31 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: [Dots] draft-ietf-dots-data-channel: Filter Activation Thread-Index: AdOlbErzDQUpkmr3SvqsVrn/wnlEDABBjMnwACv13YAAAZHEoA== Date: Fri, 16 Feb 2018 13:24:31 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A0D1F64@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <010101d3a722$55e16d80$01a44880$@jpshallow.com> In-Reply-To: <010101d3a722$55e16d80$01a44880$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [171.61.123.199] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB2405; 7:MxFQVGpJyALCzl+2MXauq4ZDCav9STqTBX8NWRaJFAJFQShqN8aa/T2Fv0wQxmbHakFom0Jh7nRYUvgJYmaHMUk4iMEh2VpTSrsANoTf2tIBbDNepW+8p8awsn7POwZkdzV0sVFCpF+Kml4jG7oa9v5M/+6MMEPwZ3H+PoinqLVhPEUjOfMPjkC5s8Fx8d70G1+xoswnOg2h13HoXQhsE4TzTzMZCNxQ/leOipV0XzDevNtMqV9UAyEIb5TuFdQB x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: b710a3a4-635f-4061-815f-08d575409d04 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:DM5PR16MB2405; x-ms-traffictypediagnostic: DM5PR16MB2405: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(18271650672692)(21748063052155)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001037)(6040501)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(3231101)(944501161)(6041288)(20161123564045)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(6072148)(201708071742011); SRVR:DM5PR16MB2405; BCL:0; PCL:0; RULEID:; SRVR:DM5PR16MB2405; x-forefront-prvs: 0585417D7B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(396003)(366004)(376002)(346002)(39380400002)(39860400002)(53754006)(199004)(189003)(32952001)(5660300001)(229853002)(55016002)(6306002)(33656002)(80792005)(8936002)(6436002)(99286004)(790700001)(3846002)(6116002)(7736002)(97736004)(53936002)(478600001)(8676002)(2950100002)(81156014)(81166006)(106356001)(105586002)(72206003)(6246003)(76176011)(54896002)(236005)(9686003)(316002)(110136005)(86362001)(2900100001)(25786009)(14454004)(7696005)(59450400001)(6506007)(74316002)(2201001)(186003)(102836004)(3660700001)(3280700002)(68736007)(561944003)(66066001)(2906002)(53546011)(26005)(2501003)(77096007)(19609705001)(85282002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB2405; 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) x-microsoft-antispam-message-info: N/UZOAhn2cU92+g3koAvTZYumXvgf/hQ4Phf+aI0nO044aqlHwHrPxHGs6thnoKhDwf8Blu9MNgisZLxL9MdcQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1788ECF24531E2FCED849D9FEACB0DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: b710a3a4-635f-4061-815f-08d575409d04 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2018 13:24:31.4061 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB2405 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 <6224> : inlines <6404> : streams <1779148> : uri <2593887> Archived-At: Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Activation 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, 16 Feb 2018 13:24:46 -0000 --_000_DM5PR16MB1788ECF24531E2FCED849D9FEACB0DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Friday, February 16, 2018 6:03 PM To: Konda, Tirumaleswar Reddy ; mohamed= .boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] draft-ietf-dots-data-channel: Filter Activation I also agree with the proposal for the default of "mitigation-time". However, when "immediate" is used, is this to be client specific, or across= globally the whole of the domain? [TR] client specific, destination-ipv4-network should be specified in the r= equest. -Tiru - this effects how the destination prefix is going to be checked / instanti= ated. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 15 February 2018 15:42 To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Activation I agree with the proposal. In most use cases during peace time, the DOTS cl= ient can enforce the black-list/white-list filtering rules in its domain, s= o the default value of "mitigation-time" for the activation-type. Cheers, -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Wednesday, February 14, 2018 1:48 PM To: dots@ietf.org Subject: [Dots] draft-ietf-dots-data-channel: Filter Activation Hi all, As agreed during the interim, there are some issues that need fixes in the = data-channel spec. We would like to hear from the WG to know what to record= in the document. Issue description: Do we assume that all filtering rules, communicated by D= OTS clients, are activated by default or only when a mitigation is active? Below a proposal for discussion: - We should support both: o Immediate activation is useful in deployment cases where filtering is = used to anticipate some attacks and therefore avoid that access resources a= re abused when an attack become effective. This is typically the case where= DOTS server is deployed by access providers. o The reasoning may not be the same if the DOTS service is on the cloud. - The intended action will be governed by a new attribute called "activa= tion-type" which can be set to "immediate" or "mitigation-time". This param= eter will be supplied by a DOTS client in a filter creation request. - Which default value to use if no "activation-type" is supplied by a cl= ient? Please comment. Cheers, Med --_000_DM5PR16MB1788ECF24531E2FCED849D9FEACB0DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From:<= /span> Jon Shallow [mailto:s= upjps-ietf@jpshallow.com]
Sent: Friday, February 16, 2018 6:03 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; mohamed.boucadair@orange.com; dots@ietf.org
Subject: RE: [Dots] draft-ietf-dots-data-channel: Filter Activation<= o:p>

 

I also = agree with the proposal for the default of “mitigation-time”.

&n= bsp;

However= , when “immediate” is used, is this to be client specific, or a= cross globally the whole of the domain?

[TR] client specific, destinati= on-ipv4-network should be specified in the request.

 

-Tiru

 

- this = effects how the destination prefix is going to be checked / instantiated.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 15 February 2018 15:42
To: mohamed.boucadai= r@orange.com; dots@ietf.org
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Activation<= o:p>

 

I agree with the proposal. In most use cases during = peace time, the DOTS client can enforce the black-list/white-list filtering= rules in its domain, so the def= ault value of “mitigation-time” for the activation-type.

 

Cheers,

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed= .boucadair@orange.com
Sent: Wednesday, February 14, 2018 1:48 PM
To: dots@ietf.org
Subject: [Dots] draft-ietf-dots-data-channel: Filter Activation=

 

Hi all,

 

As agreed during the interim, there are some issues that n= eed fixes in the data-channel spec. We would like to hear from the WG to kn= ow what to record in the document.

 

Issue description: Do we assume that all filtering rules, = communicated by DOTS clients, are activated by default or only when a mitig= ation is active?

 

Below a proposal for discussion:

– = ;   We should support both:

o    Immediate activation is useful in deployment cases where filtering is used= to anticipate some attacks and therefore avoid that access resources are a= bused when an attack become effective. This is typically the case where DOTS server is deployed by access providers. <= o:p>

o    The reasoning may not be the same if the DOTS service is on the cloud.

– = ;   The intended action will be governed by a new attribute called “acti= vation-type” which can be set to “immediate” or “mi= tigation-time”. This parameter will be supplied by a DOTS client in a= filter creation request.

– = ;   Which default value to use if no “activation-type” is supplied= by a client?

 <= /p>

Please comment.

 <= /p>

Cheers,=

Med

--_000_DM5PR16MB1788ECF24531E2FCED849D9FEACB0DM5PR16MB1788namp_-- From nobody Fri Feb 16 05:25:02 2018 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 7654712D86B for ; Fri, 16 Feb 2018 05:25:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 VdO_Ll4pIIBP for ; Fri, 16 Feb 2018 05:24:52 -0800 (PST) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7168127023 for ; Fri, 16 Feb 2018 05:24:51 -0800 (PST) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 7A43AC1216; Fri, 16 Feb 2018 14:24:50 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.66]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 54AD91C005D; Fri, 16 Feb 2018 14:24:50 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA1.corporate.adroot.infra.ftgroup ([fe80::95e2:eb4b:3053:fabf%19]) with mapi id 14.03.0382.000; Fri, 16 Feb 2018 14:24:50 +0100 From: To: Jon Shallow , "'Konda, Tirumaleswar Reddy'" , "dots@ietf.org" Thread-Topic: [Dots] draft-ietf-dots-data-channel: Filter Activation Thread-Index: AdOlbErzDQUpkmr3SvqsVrn/wnlEDAK/1WszpgVDy/CmF8/2MA== Date: Fri, 16 Feb 2018 13:24:49 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0D36E4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300A0D1F64@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <010101d3a722$55e16d80$01a44880$@jpshallow.com> In-Reply-To: <010101d3a722$55e16d80$01a44880$@jpshallow.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A0D36E4OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Activation 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, 16 Feb 2018 13:25:01 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A0D36E4OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 16 f=E9vrier 2018 13:33 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: [Dots] draft-ietf-dots-data-channel: Filter Activation I also agree with the proposal for the default of "mitigation-time". [Med] Noted. However, when "immediate" is used, is this to be client specific, or across= globally the whole of the domain? [Med] The filter will be applied on whatever criteria indicated by the clie= nt. - this effects how the destination prefix is going to be checked / instanti= ated. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 15 February 2018 15:42 To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Activation I agree with the proposal. In most use cases during peace time, the DOTS cl= ient can enforce the black-list/white-list filtering rules in its domain, s= o the default value of "mitigation-time" for the activation-type. Cheers, -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Wednesday, February 14, 2018 1:48 PM To: dots@ietf.org Subject: [Dots] draft-ietf-dots-data-channel: Filter Activation Hi all, As agreed during the interim, there are some issues that need fixes in the = data-channel spec. We would like to hear from the WG to know what to record= in the document. Issue description: Do we assume that all filtering rules, communicated by D= OTS clients, are activated by default or only when a mitigation is active? Below a proposal for discussion: - We should support both: o Immediate activation is useful in deployment cases where filtering is = used to anticipate some attacks and therefore avoid that access resources a= re abused when an attack become effective. This is typically the case where= DOTS server is deployed by access providers. o The reasoning may not be the same if the DOTS service is on the cloud. - The intended action will be governed by a new attribute called "activa= tion-type" which can be set to "immediate" or "mitigation-time". This param= eter will be supplied by a DOTS client in a filter creation request. - Which default value to use if no "activation-type" is supplied by a cl= ient? Please comment. Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300A0D36E4OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf= @jpshallow.com]
Envoy=E9 : vendredi 16 f=E9vrier 2018 13:33
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; d= ots@ietf.org
Objet : RE: [Dots] draft-ietf-dots-data-channel: Filter Activat= ion

 

I also = agree with the proposal for the default of “mitigation-time”.

[Med] Noted.

&n= bsp;

However= , when “immediate” is used, is this to be client specific, or a= cross globally the whole of the domain?

[Med] The filter will be applie= d on whatever criteria indicated by the client.   

 

- this = effects how the destination prefix is going to be checked / instantiated.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 15 February 2018 15:42
To: mohamed.boucadai= r@orange.com; dots@ietf.org
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Activation<= o:p>

 

I agree with the proposal. In m= ost use cases during peace time, the DOTS client can enforce the black-list= /white-list filtering rules in its domain, so the default value of “mitigation-time” for the activation-type.

 

Cheers,

-Tiru

 

From: Dots [mailto:dots-bounces= @ietf.org] On Behalf Of mohamed= .boucadair@orange.com
Sent: Wednesday, February 14, 2018 1:48 PM
To: dots@ietf.org
Subject: [Dots] draft-ietf-dots-data-channel: Filter Activation=

 

Hi all,

 

As agreed during the interim, there are som= e issues that need fixes in the data-channel spec. We would like to hear fr= om the WG to know what to record in the document.

 

Issue description: Do we assume that all fi= ltering rules, communicated by DOTS clients, are activated by default or on= ly when a mitigation is active?

 

Below a proposal for discussion:=

–= ;    We should support both:

o    Immediate activation is useful in deployment cases where fi= ltering is used to anticipate some attacks and therefore avoid that access = resources are abused when an attack become effective. This is typically the case where DOTS server is deployed by access provide= rs.

o    The reasoning may not be the same if the DOTS service is on= the cloud.

–= ;    The intended action will be governed by a new attribute cal= led “activation-type” which can be set to “immediate̶= 1; or “mitigation-time”. This parameter will be supplied by a D= OTS client in a filter creation request.

–= ;    Which default value to use if no “activation-typeR= 21; is supplied by a client?

 = ;

Please com= ment.

 = ;

Cheers,

Med

--_000_787AE7BB302AE849A7480A190F8B93300A0D36E4OPEXCLILMA3corp_-- From nobody Fri Feb 16 05:26:10 2018 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 B9D6A12711D for ; Fri, 16 Feb 2018 05:26:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 ml4B44KLj8I2 for ; Fri, 16 Feb 2018 05:26:06 -0800 (PST) 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 0BBAD127023 for ; Fri, 16 Feb 2018 05:26:06 -0800 (PST) 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 1emg1b-0000s8-7u; Fri, 16 Feb 2018 13:26:03 +0000 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , , References: <787AE7BB302AE849A7480A190F8B93300A0D1FD4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <011701d3a723$1952d830$4bf88890$@jpshallow.com> In-Reply-To: Date: Fri, 16 Feb 2018 13:26:04 -0000 Message-ID: <017c01d3a729$b2657e50$17307af0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_017D_01D3A729.B267EF50" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIUreNBqTKMUjWKiR2GS2Zv39X3cgJN+3UFAoJNq/0BaU/PmaLzKZtQ Content-Language: en-gb Archived-At: Subject: Re: [Dots] draft-ietf-dots-data-channel: Lifetime handling 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, 16 Feb 2018 13:26:09 -0000 This is a multipart message in MIME format. ------=_NextPart_000_017D_01D3A729.B267EF50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Tiru, See inline [Jon] Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 16 February 2018 13:18 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Lifetime handling From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Friday, February 16, 2018 6:09 PM To: Konda, Tirumaleswar Reddy ; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] draft-ietf-dots-data-channel: Lifetime handling Option 3 looks good to me. However do we need to add in a "when it will expire" parameter in a GET response so that a restarting DOTS client knows it has to do a refresh within a certain time? [TR] Yes. Separately, I think Option 4 should still be in place as a recommendation to manage stale DOTS clients (as determined by cuid) that have not been active on the signal and data channel for a period of time. [TR] If Option 3 is used, don't see the use of Option 4. [Jon] Option 4 is also about the lifetime handling of cuids that go stale - perhaps a separate discussion, but it is also lifetimes. -Jon -Tiru Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 16 February 2018 03:47 To: mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Lifetime handling Option 3 looks good to me. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: Wednesday, February 14, 2018 1:53 PM To: dots@ietf.org Subject: [Dots] draft-ietf-dots-data-channel: Lifetime handling Hi all, As agreed during the interim, there are some issues that need fixes in the data-channel spec. We would like to hear from the WG to know what to record in the document. Issue description: It was agreed to associate a lifetime with entries instantiated by a DOTS client (-12). The current behavior in the spec is as follows: - A lifetime hint is included in the resource creation request by the client. - The server may honor the suggested lifetime or assign a distinct value as per its local policies. When a distinct value is used by the server, the issue is how to notify the client given that RFC8040 says: "If the POST method succeeds, a "201 Created" status-line is returned and there is no response message-body." * Option 1: A work around would be to relax the above constraint at the server side to include a message-body even for "201 Created", but this is not a clean design as it requires changes to the base RESTCONF spec. * Option 2: Change completely the data module so that we can make use of operations (action/rpc). For example, these operations can be defined: +---x activate-filtering | +---w input | | +---w name string | | +---w lifetime-hint int32 | +--ro output | +--ro name string | +--ro lifetime int32 +---x deactivate-filtering +---w input +---w name string This approach will require major changes to the document. This may not be justified given that in some cases no lifetime is included at all. * Option 3: This one assumes that servers must maintain an entry for a minimum period (e.g., 1 week, 1 month). No Lifetime is included in a request. If no refresh request is seen from the client, the server removes expired entries. This one requires minor changes to the document. * Option 4: This approach does not associate a lifetime with filtering/alias entries but maintains an inactivity timer of a given DOTS client. This option does not allow to clean stale mappings that may be induced by clients that do not remove their state appropriately. Recommended position: - Proceed with option 3. Any objection? Cheers, Med ------=_NextPart_000_017D_01D3A729.B267EF50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

See inline = [Jon]

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = Konda, Tirumaleswar Reddy
Sent: 16 February 2018 = 13:18
To: Jon Shallow; mohamed.boucadair@orange.com; = dots@ietf.org
Subject: Re: [Dots] = draft-ietf-dots-data-channel: Lifetime = handling

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Friday, February 16, 2018 6:09 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: RE: = [Dots] draft-ietf-dots-data-channel: Lifetime = handling

 

Option 3 looks good to = me.

 

However do we need to = add in a “when it will expire” parameter in  a GET = response so that a restarting DOTS client knows it has to do a refresh = within a certain time?

 

[TR] = Yes.

 

Separately, I think = Option 4 should still be in place as a recommendation to manage stale = DOTS clients (as determined by cuid) that have not been active on the = signal and data channel for a period of time.

 

[TR] If = Option 3 is used, don’t see the use of Option 4.

[Jon] Option 4 is also = about the lifetime handling of cuids that go stale – perhaps a = separate discussion, but it is also lifetimes.

 

-Jon

 

-Tiru

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 16 February 2018 = 03:47
To: mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: Re: = [Dots] draft-ietf-dots-data-channel: Lifetime = handling

 

Option 3 looks good to = me.

 

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of mohamed.boucadair@orange.com=
Sent: Wednesday, February 14, 2018 1:53 PM
To: = dots@ietf.org
Subject: = [Dots] draft-ietf-dots-data-channel: Lifetime = handling

 

Hi = all,

 

As = agreed during the interim, there are some issues that need fixes in the = data-channel spec. We would like to hear from the WG to know what to = record in the document.

 

Issue = description: It was agreed to associate a lifetime with entries = instantiated by a DOTS client (-12). The current behavior in the spec is = as follows:

-    A lifetime hint is = included in the resource creation request by the = client.

-    The server may = honor the suggested lifetime or assign a distinct value as per its local = policies.   

 

When a = distinct value is used by the server, the issue is how to notify the = client given that RFC8040 says:

 

"If the POST method succeeds, a "201 Created" = status-line is returned and there is no response = message-body."

 

* = Option 1:

 

A work = around would be to relax the above constraint at the server side to = include a message-body even for “201 Created”, but this is not a clean design as it = requires changes to the base RESTCONF spec.

 

* = Option 2:

 

Change = completely the data module so that we can make use of operations = (action/rpc). For example, these operations can be defined: =

 

          = +---x activate-filtering

          = |  +---w input

          = |  |  +---w = name           &nb= sp; string

          = |  |  +---w lifetime-hint    = int32

          = |  +--ro output

          = |     +--ro = name        = string

   =        |     = +--ro lifetime    int32

          = +---x deactivate-filtering

          =    +---w input

          =       +---w name    = string

 

This approach will require major changes to the document. This may = not be justified given that in some cases no lifetime is included at = all.

 

* Option 3:

 

This = one assumes that servers must maintain an entry for a minimum period = (e.g., 1 week, 1 month). No Lifetime is included in a request. If no = refresh request is seen from the client, the server removes expired = entries.

 

This = one requires minor = changes to the document. =  

 

* = Option 4:

 

This = approach does not associate a lifetime with filtering/alias entries but = maintains an inactivity timer of a given DOTS client. This option does = not allow to clean stale = mappings that may be = induced by clients that do not remove their state appropriately. =

 

Recommended position:

–    Proceed with option = 3.

 

Any objection? =

 

Cheers,

Med =

 

------=_NextPart_000_017D_01D3A729.B267EF50-- From nobody Fri Feb 16 05:29:04 2018 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 674F7127023 for ; Fri, 16 Feb 2018 05:29:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 2KHcH4UjjTDy for ; Fri, 16 Feb 2018 05:29:01 -0800 (PST) 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 7FA69120047 for ; Fri, 16 Feb 2018 05:29:00 -0800 (PST) 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 1emg4Q-0000sL-RN; Fri, 16 Feb 2018 13:28:59 +0000 From: "Jon Shallow" To: , "Konda, Tirumaleswar Reddy" , References: <787AE7BB302AE849A7480A190F8B93300A0D1F93@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0D32AE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00e801d3a721$08806d30$19814790$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0D366E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A0D366E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Fri, 16 Feb 2018 13:29:00 -0000 Message-ID: <019201d3a72a$1b103b70$5130b250$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0193_01D3A72A.1B12AC70" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLoxvz0kGpX/tRyz6XeuCXxpheRlwMZabEuApwt0GoCITdLGgK2/q2yAt/zojShEVTRQA== Content-Language: en-gb Archived-At: Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields 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, 16 Feb 2018 13:29:03 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0193_01D3A72A.1B12AC70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Med, =20 See inline [Jon] =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 16 February 2018 12:56 To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields =20 Jon, =20 Thank you for sharing your thoughts.=20 =20 Please see inline. =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : vendredi 16 f=E9vrier 2018 13:24 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; = dots@ietf.org Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields =20 I like the concept of =93+--ro capabilities=93 allowing for future = support as the DOS server becomes more mature in its capabilities. =20 If a DOTS client includes a filtering field parameter that is not = currently supported, should the parameter be ignored (and not returned for a GET), = or the request rejected? [Med] I would vote for rejecting the request. The client should only use match criteria that are understood by the server; otherwise there will = be different expectation from the service.=20 [Jon] I think that this is my preference =96 I was just seeking clarity = of thinking. =20 It is conceivable that a DOTS client has 2 DOTS servers (one possibly a backup, or 2 different ISPs), which may have differing filtering field parameter support capabilities. [Med] The backup/case seems odd. I would expect a feature parity for a redundancy group used to provide the same service. [Jon] Agreed that a backup server is most likely to be from the same manufacturer and hence support the same functionality. But one may have just been upgraded to have extra support. =20 =20 =20 Adding in intelligence code to work out what is / is not allowed may = not be practical in a (memory or cpu) constrained environment of the DOTS client. [Med] Fair.=20 =20 That said, I think we need to define the minimum set of supported = parameters =96 e.g. protocol, source / dest ports, source / dest IPv4 prefixes, = source / dest IPv6 prefixes, fragments and icmp type/code.=20 [Jon] Any comments? =20 -Jon =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 16 February 2018 10:18 To: mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields =20 Hi Med, =20 Please see inline [TR2] =20 From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] = Sent: Friday, February 16, 2018 1:45 PM To: Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: RE: draft-ietf-dots-data-channel: Filtering Fields =20 Re-, =20 Please see inline.=20 =20 Cheers, Med =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, = Tirumaleswar Reddy Envoy=E9 : vendredi 16 f=E9vrier 2018 08:00 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields =20 From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: Wednesday, February 14, 2018 1:49 PM To: dots@ietf.org Subject: [Dots] draft-ietf-dots-data-channel: Filtering Fields =20 Hi all,=20 =20 As agreed during the interim, there are some issues that need fixes in = the data-channel spec. We would like to hear from the WG to know what to = record in the document.=20 =20 Issue description: Should we support all of the match fields defined by =93ietf-packet-fields=94 or do we need to define a minimum supported = set?=20 =20 [TR] I don=92t see the need to support all the match fields, define a = minimum supported set (don=92t see the use for acl-eth-header-fields for DOTS = use cases). =20 [Med] Agree that acl-eth-header-fields aren=92t required. The text is = already clear about this: =20 DOTS implementations MUST support the following matching criteria: match based on the IP header (IPv4 and IPv6), match based on the transport header (TCP, UDP, and ICMP), and any combination thereof. =20 The question is whether we need to go further and mandate (or not) the support of matching based on specific fields: dscp, ecn, ttl,=85 = flow-label, =85 tcp sequence-number, tcp flags, =85 =20 =20 [TR2] https://tools.ietf.org/html/draft-ietf-netmod-acl-model-16 uses the = feature statements in the YANG model allowing vendors to advertise match rules = they are capable and willing to support but not at the field-level. The = problem is router implementations today don=92t support ACLs with tcp = sequence-number, acknowledgement-number, window-size etc but support TCP flags. If the = server could convey the list of match criteria supported, it not only allows = the client to convey the supported match rules but also allows the server in future to advertise the new supported match fields. =20 =20 Would it be useful for a client to retrieve the list of match criteria supported by a DOTS server?=20 =20 [TR2] Yes.=20 =20 -Tiru =20 [TR] The YANG model supported by the DOTS server can retrieved by the = DOTS client using RESTCONF to determine the match criteria supported by the server.=20 [Med] I=92m afraid this is not the same functionality. If we need to = allow a server to return its supported match criteria, this should be allowed by = the module. For example, the module may include the following (example):=20 =20 +--ro capabilities | +--ro match-header* | | identityref | +--ro transport-protocols* [protocol-id] | | +--ro protocol-id uint8 | | +--ro protocol-name? string | +--ro dscp-support? boolean | +--ro ecn-support? boolean | +--ro length-support? boolean | +--ro ttl-support? boolean | +--ro protocol-support? boolean =20 The client can ask the server to return its supported match criteria. = The server will indicate the exact set of fields it supports.=20 =20 I=92m not expressing a preference to have this in the model, but I=92m clarifying how it would look like.=20 =20 -Tiru =20 Please comment.=20 =20 Cheers, Med ------=_NextPart_000_0193_01D3A72A.1B12AC70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Med,

 

See inline = [Jon]

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com
Sent: 16 February 2018 = 12:56
To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; = dots@ietf.org
Subject: Re: [Dots] = draft-ietf-dots-data-channel: Filtering = Fields

 

Jon,

 

Thank you for sharing your thoughts. =

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Envoy=E9 : vendredi 16 f=E9vrier 2018 = 13:24
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR = Mohamed IMT/OLN; dots@ietf.org
Objet : = RE: [Dots] draft-ietf-dots-data-channel: Filtering = Fields

 

I like =
the concept of “+--ro capabilities“ =
allowing for future support as the DOS server becomes more mature in its =
capabilities.
&nb=
sp;
If a =
DOTS client includes a filtering field parameter that is not currently =
supported, should the parameter be ignored (and not returned for a GET), =
or the request rejected?
[Med] I would vote for =
rejecting the request. The client should only use match criteria that =
are understood by the server; otherwise there will be different =
expectation from the service. 
[Jon] I =
think that this is my preference – I was just seeking clarity of =
thinking.
 <=
/pre>
It is =
conceivable that a DOTS client has 2 DOTS servers (one possibly a =
backup, or 2 different ISPs), which may have differing filtering field =
parameter support capabilities.
[Med] The backup/case seems =
odd. I would expect a feature parity for a redundancy group used to =
provide the same service.
=
[Jon] Agreed that =
a backup server is most likely to be from the same manufacturer and =
hence support the same functionality.=A0 But one may have just been =
upgraded to have extra support.
 <=
/pre>
 
<=
pre> 
<=
pre>  =
Adding in intelligence code to work out what is / is not allowed may not =
be practical in a (memory or cpu) constrained environment of the DOTS =
client.
[Med] Fair. =

&nb=
sp;
That =
said, I think we need to define the minimum set of supported parameters =
– e.g. protocol, source / dest ports,  source / dest IPv4 =
prefixes, source / dest IPv6 prefixes, fragments and icmp type/code. =

[Jon] =
Any comments?
 <=
/pre>
-Jon
 <=
/pre>
Regards<=
o:p>
&nb=
sp;
Jon
 
From: Dots [mailto: dots-bounces@ietf.org] On =
Behalf Of Konda, Tirumaleswar Reddy
Sent: 16 February 2018 =
10:18
To: mohamed.boucadair@orange.com=
; dots@ietf.org
Subject: Re: =
[Dots] draft-ietf-dots-data-channel: Filtering =
Fields
 
Hi =
Med,
 
Please see inline =
[TR2]
 
From: mohamed.boucadair@orange.com=
 [mailto:mohamed.boucadair@ora=
nge.com] 
Sent: Friday, February 16, 2018 1:45 =
PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond=
a@McAfee.com>; dots@ietf.org
Subject: RE: =
draft-ietf-dots-data-channel: Filtering =
Fields
 
Re-,
 
Please see inline. 
 
Cheers,
Med
 
De : Dots [mailto:dots-bounces@ietf.org] =
De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : =
vendredi 16 f=E9vrier 2018 08:00
=C0 : BOUCADAIR Mohamed =
IMT/OLN; dots@ietf.org
Objet : =
Re: [Dots] draft-ietf-dots-data-channel: Filtering =
Fields
 
From: Dots [mailto:dots-bounces@ietf.org] =
On Behalf Of mohamed.boucadair@orange.com=

Sent: Wednesday, February 14, 2018 1:49 PM
To: =
dots@ietf.org
Subject: =
[Dots] draft-ietf-dots-data-channel: Filtering =
Fields
 
Hi =
all, 
 
As =
agreed during the interim, there are some issues that need fixes in the =
data-channel spec. We would like to hear from the WG to know what to =
record in the document. 
 
Issue =
description: Should we support all of the match fields defined by =
“ietf-packet-fields” or do we need to define a minimum =
supported set? 
 
[TR] I don’t see the need to support all the match =
fields, define a minimum supported set (don’t see the use for =
acl-eth-header-fields for DOTS use cases). =
 
[Med] =
Agree that acl-eth-header-fields aren’t required. The text is =
already clear about this:
 
DOTS implementations MUST support the =
following
   matching criteria: match =
based on the IP header (IPv4 and IPv6),
   match based on the transport =
header (TCP, UDP, and ICMP), and any
   combination =
thereof.
 
The question is whether we =
need to go further and mandate (or not) the support of matching based on =
specific fields: dscp, ecn, ttl,… flow-label, … tcp sequence-number, =
tcp flags, …  
 
[TR2] https://tools.ietf.org/html/draft-ietf-netmod-acl-model-16 =
uses the =
feature statements in the YANG model allowing vendors to advertise match =
rules they are capable and willing to support but not at the =
field-level. The problem is router implementations today don’t =
support ACLs with tcp sequence-number, acknowledgement-number, =
window-size etc but support TCP flags. If the server could convey the =
list of match criteria supported, it not only allows the client to =
convey the supported match rules but also allows the server in future to =
advertise the new supported match fields. =
  
 
Would =
it be useful for a client to retrieve the list of match criteria =
supported by a DOTS server? 
 
[TR2] Yes. 
 
-Tiru
 
[TR] The YANG model supported by =
the DOTS server can retrieved by the DOTS client using RESTCONF to =
determine the match criteria supported by the server. =

[Med] =
I’m afraid this is not the same functionality. If we need to allow =
a server to return its supported match criteria, this should be allowed =
by the module. For example, the module may include the following =
(example): 
 
       &=
nbsp;        +--ro =
capabilities
       &=
nbsp;        |  +--ro =
match-header*
       &=
nbsp;        |  =
|       =
identityref
       &=
nbsp;        |  +--ro =
transport-protocols* [protocol-id]
       &=
nbsp;        |  |  +--ro =
protocol-id      =
uint8
       &=
nbsp;        |  |  +--ro =
protocol-name?   string
       &=
nbsp;        |  +--ro =
dscp-support? =
      boolean
<=
span lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Courier =
New";mso-fareast-language:FR'>       &=
nbsp;        |  +--ro =
ecn-support? =
       boolean
=

       &=
nbsp;        |  +--ro =
length-support? =
    boolean
       &=
nbsp;        |  +--ro =
ttl-support? =
       boolean
=

       &=
nbsp;        |  +--ro =
protocol-support?   boolean
 
The client can ask the server to return =
its supported match criteria. The server =
will indicate the exact set of fields it supports. =

 
<=
pre>I’m not expressing a =
preference to have this in the model, but I’m clarifying how it =
would look like. 
 
-Tiru
 
Please comment. =

 
Cheers,
Med
------=_NextPart_000_0193_01D3A72A.1B12AC70-- From nobody Fri Feb 16 05:33:33 2018 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 C0EB2127023 for ; Fri, 16 Feb 2018 05:33:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 ZaEuFjiibq2p for ; Fri, 16 Feb 2018 05:33:30 -0800 (PST) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B421F120047 for ; Fri, 16 Feb 2018 05:33:29 -0800 (PST) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 97DED61411; Fri, 16 Feb 2018 14:33:28 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.2]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 714E740062; Fri, 16 Feb 2018 14:33:28 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06%19]) with mapi id 14.03.0382.000; Fri, 16 Feb 2018 14:33:28 +0100 From: To: Jon Shallow , "Konda, Tirumaleswar Reddy" , "dots@ietf.org" Thread-Topic: [Dots] draft-ietf-dots-data-channel: Filtering Fields Thread-Index: AdOlbICGgF2MxoHnQied7J+cvW2QAAMZabEuApwt0GoCITdLGgK2/q2yAt/zojShEVTRQKF5R2Qg Date: Fri, 16 Feb 2018 13:33:27 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0D372A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300A0D1F93@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0D32AE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00e801d3a721$08806d30$19814790$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0D366E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019201d3a72a$1b103b70$5130b250$@jpshallow.com> In-Reply-To: <019201d3a72a$1b103b70$5130b250$@jpshallow.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A0D372AOPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields 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, 16 Feb 2018 13:33:33 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A0D372AOPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, I tend to agree with you to have to define a minimum set of mandatory match= fields. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 16 f=E9vrier 2018 14:29 =C0 : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; dots@ietf.org Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields Hi Med, See inline [Jon] Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 16 February 2018 12:56 To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields Jon, Thank you for sharing your thoughts. Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 16 f=E9vrier 2018 13:24 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org= Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields I like the concept of "+--ro capabilities" allowing for future support as t= he DOS server becomes more mature in its capabilities. If a DOTS client includes a filtering field parameter that is not currently= supported, should the parameter be ignored (and not returned for a GET), o= r the request rejected? [Med] I would vote for rejecting the request. The client should only use ma= tch criteria that are understood by the server; otherwise there will be dif= ferent expectation from the service. [Jon] I think that this is my preference - I was just seeking clarity of th= inking. It is conceivable that a DOTS client has 2 DOTS servers (one possibly a bac= kup, or 2 different ISPs), which may have differing filtering field paramet= er support capabilities. [Med] The backup/case seems odd. I would expect a feature parity for a redu= ndancy group used to provide the same service. [Jon] Agreed that a backup server is most likely to be from the same manufa= cturer and hence support the same functionality. But one may have just bee= n upgraded to have extra support. Adding in intelligence code to work out what is / is not allowed may not = be practical in a (memory or cpu) constrained environment of the DOTS clien= t. [Med] Fair. That said, I think we need to define the minimum set of supported parameter= s - e.g. protocol, source / dest ports, source / dest IPv4 prefixes, sourc= e / dest IPv6 prefixes, fragments and icmp type/code. [Jon] Any comments? -Jon Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 16 February 2018 10:18 To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields Hi Med, Please see inline [TR2] From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 1:45 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: draft-ietf-dots-data-channel: Filtering Fields Re-, Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 16 f=E9vrier 2018 08:00 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Wednesday, February 14, 2018 1:49 PM To: dots@ietf.org Subject: [Dots] draft-ietf-dots-data-channel: Filtering Fields Hi all, As agreed during the interim, there are some issues that need fixes in the = data-channel spec. We would like to hear from the WG to know what to record= in the document. Issue description: Should we support all of the match fields defined by "ie= tf-packet-fields" or do we need to define a minimum supported set? [TR] I don't see the need to support all the match fields, define a minimum= supported set (don't see the use for acl-eth-header-fields for DOTS use ca= ses). [Med] Agree that acl-eth-header-fields aren't required. The text is already= clear about this: DOTS implementations MUST support the following matching criteria: match based on the IP header (IPv4 and IPv6), match based on the transport header (TCP, UDP, and ICMP), and any combination thereof. The question is whether we need to go further and mandate (or not) the supp= ort of matching based on specific fields: dscp, ecn, ttl,... flow-label, ..= . tcp sequence-number, tcp flags, ... [TR2] https://tools.ietf.org/html/draft-ietf-netmod-acl-model-16 uses the f= eature statements in the YANG model allowing vendors to advertise match rul= es they are capable and willing to support but not at the field-level. The = problem is router implementations today don't support ACLs with tcp sequenc= e-number, acknowledgement-number, window-size etc but support TCP flags. If= the server could convey the list of match criteria supported, it not only = allows the client to convey the supported match rules but also allows the s= erver in future to advertise the new supported match fields. Would it be useful for a client to retrieve the list of match criteria supp= orted by a DOTS server? [TR2] Yes. -Tiru [TR] The YANG model supported by the DOTS server can retrieved by the DOTS = client using RESTCONF to determine the match criteria supported by the serv= er. [Med] I'm afraid this is not the same functionality. If we need to allow a = server to return its supported match criteria, this should be allowed by th= e module. For example, the module may include the following (example): +--ro capabilities | +--ro match-header* | | identityref | +--ro transport-protocols* [protocol-id] | | +--ro protocol-id uint8 | | +--ro protocol-name? string | +--ro dscp-support? boolean | +--ro ecn-support? boolean | +--ro length-support? boolean | +--ro ttl-support? boolean | +--ro protocol-support? boolean The client can ask the server to return its supported match criteria. The s= erver will indicate the exact set of fields it supports. I'm not expressing a preference to have this in the model, but I'm clarifyi= ng how it would look like. -Tiru Please comment. Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300A0D372AOPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

I tend to agree with you to hav= e to define a minimum set of mandatory match fields.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf= @jpshallow.com]
Envoy=E9 : vendredi 16 f=E9vrier 2018 14:29
=C0 : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; dot= s@ietf.org
Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fiel= ds

 

Hi Med,=

&n= bsp;

See inl= ine [Jon]

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 16 February 2018 12:56
To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields

 

Jon,

 

Thank you for sharing your thou= ghts.

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : vendredi 16 f=E9vrier 2018 13:24
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; <= a href=3D"mailto:dots@ietf.org"> dots@ietf.org
Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fiel= ds

 

I like the concept of “+--ro capabilities“ allowing for futu=
re support as the DOS server becomes more mature in its capabilities.<=
/o:p>
 
If a DOTS client includes a filtering field parameter that =
is not currently supported, should the parameter be ignored (and not return=
ed for a GET), or the request rejected?
[Med] I would vote for re=
jecting the request. The client should only use match criteria that are und=
erstood by the server; otherwise there will be different expectation from t=
he service. 
[Jon] I think that this is my preference – I was just=
 seeking clarity of thinking.
<=
o:p> 
It is conceivable that a DOTS client has 2 DOTS servers (on=
e possibly a backup, or 2 different ISPs), which may have differing filteri=
ng field parameter support capabilities.
[Med] The backup/case see=
ms odd. I would expect a feature parity for a redundancy group used to prov=
ide the same service.=

[=
Jon] Agreed that a backup server is most likely to be from the same manufac=
turer and hence support the same functionality.  But one may have just=
 been upgraded to have extra support.
<=
o:p> 
 <=
/pre>

 <=
/pre>

  Adding in intelligence code to work out what is / is=
 not allowed may not be practical in a (memory or cpu) constrained environm=
ent of the DOTS client.


[Med] Fair. 


 


That said, I think we need to define the minimum set of sup=
ported parameters – e.g. protocol, source / dest ports,  source =
/ dest IPv4 prefixes, source / dest IPv6 prefixes, fragments and icmp type/=
code. 


[Jon] Any comments?


<=
o:p> 


-=
Jon


<=
o:p> 


Regards


 


Jon


&n=
bsp;






From:=
 Dots [mailto:
dots-bounces@ietf.org] On B=
ehalf Of
Konda, Tirumaleswar Reddy

Sent: 16 February 2018 10:18

To: mohamed.boucadai=
r@orange.com;
dots@ietf.org

Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields






 


Hi Med,


 


Please see inline [TR2]


 








From:
mohamed.boucadair@orange.co=
m [mailto:mohamed.bouca=
dair@orange.com]


Sent: Friday, February 16, 2018 1:45 PM

To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>;
dots@ietf.org

Subject: RE: draft-ietf-dots-data-channel: Filtering Fields






 


Re-,


 


Please see inline.



 


Cheers,


Med


 








De : Dots [mailto:dots-bounces@ietf.org]
De la part de Konda, Tirumaleswar Reddy

Envoy=E9 : vendredi 16 f=E9vrier 2018 08:00

=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org

Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fiel=
ds






 


From: Dots [mailto:dots-bounces=
@ietf.org]
On Behalf Of mohamed=
.boucadair@orange.com

Sent: Wednesday, February 14, 2018 1:49 PM

To: dots@ietf.org

Subject: [Dots] draft-ietf-dots-data-channel: Filtering Fields<=
/o:p>


 


Hi all,



 


As agreed during the interim, there are som=
e issues that need fixes in the data-channel spec. We would like to hear fr=
om the WG to know what to record in the document.



 


Issue description: Should we support all of=
 the match fields defined by “ietf-packet-fields” or do we need=
 to define a minimum supported set?



 


[TR] I don’t see the need=
 to support all the match fields, define a minimum supported set (don’=
;t see the use for acl-eth-header-fields for DOTS use cases).  


[Med] Agree that acl-eth-header=
-fields aren’t required. The text is already clear about this:


 


DOTS implementation=
s MUST support the following


   matchi=
ng criteria: match based on the IP header (IPv4 and IPv6),


   match =
based on the transport header (TCP, UDP, and ICMP), and any


  
combination thereof.


 


The question is whether w=
e need to go further and mandate (or not) the support of matching based on =
specific fields: dscp, ecn, ttl,… flow-label, … tcp sequence-number, tcp flags, …  


 


[TR2] https=
://tools.ietf.org/html/draft-ietf-netmod-acl-model-16 uses the feature statem=
ents in the YANG model allowing vendors to advertise match rules they are c=
apable and willing to support but not at the field-level. The problem is ro=
uter implementations today don’t support ACLs with tcp sequence-numbe=
r, acknowledgement-number, window-size etc but support TCP flags. If the se=
rver could convey the list of match criteria supported, it not only allows =
the client to convey the supported match rules but also allows the server i=
n future to advertise the new supported match fields.   


 


Would it be useful for a client to retrieve=
 the list of match criteria supported by a DOTS server?



 


[TR2] Yes. 

 


-Tiru


 


[TR] The YANG model supported b=
y the DOTS server can retrieved by the DOTS client using RESTCONF to determ=
ine the match criteria supported by the server.



[Med] I’m afraid this is =
not the same functionality. If we need to allow a server to return its supp=
orted match criteria, this should be allowed by the module.
 For example, the module may include the following (example): 


 


      &=
nbsp;         +--ro capabilitie=
s


      &=
nbsp;         |  +--ro mat=
ch-header*


      &=
nbsp;         |  |  =
     identityref


      &=
nbsp;         |  +--ro tra=
nsport-protocols* [protocol-id]


      &=
nbsp;         |  |  +=
--ro protocol-id      uint8

      &=
nbsp;         |  |  +=
--ro protocol-name?   string


      &=
nbsp;         |  +--ro dsc=
p-support?       boolean

      &=
nbsp;         |  +--ro ecn=
-support?        boolean


      &=
nbsp;         |  +--ro len=
gth-support?     boolean


      &=
nbsp;         |  +--ro ttl=
-support?        boolean


      &=
nbsp;         |  +--ro pro=
tocol-support?   boolean


 


The client can ask the server to retu=
rn its supported match criteria. The server wil=
l indicate the exact set of fields it supports. 

 <=
/pre>

I’m not expressing =
a preference to have this in the model, but I’m clarifying how it wou=
ld look like. 

 


-Tiru


 


Please com=
ment.



 =
;


Cheers,


Med=
<=
/o:p>
--_000_787AE7BB302AE849A7480A190F8B93300A0D372AOPEXCLILMA3corp_-- From nobody Fri Feb 16 05:40:33 2018 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 925D012711D for ; Fri, 16 Feb 2018 05:40:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 Od0ZqZellVBR for ; Fri, 16 Feb 2018 05:40:29 -0800 (PST) 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 6DE41120047 for ; Fri, 16 Feb 2018 05:40:29 -0800 (PST) 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 1emgFX-0000t6-Mr; Fri, 16 Feb 2018 13:40:27 +0000 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , , References: <787AE7BB302AE849A7480A190F8B93300A0D3439@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00d201d3a71e$05ead590$11c080b0$@jpshallow.com> In-Reply-To: Date: Fri, 16 Feb 2018 13:40:29 -0000 Message-ID: <01b401d3a72b$b5a79f10$20f6dd30$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01B5_01D3A72B.B5AA1010" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFhM5SgMTXVloJMPghbVDaqY+i+RwHzf0UPAcW31FQAkY4P0aRpk25Q Content-Language: en-gb Archived-At: Subject: Re: [Dots] Call home in the signal channel (was RE: draft-ietf-dots-data-channel: Filter Direction) 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, 16 Feb 2018 13:40:33 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01B5_01D3A72B.B5AA1010 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Tiru, =20 See inline [Jon] =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 16 February 2018 13:13 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] Call home in the signal channel (was RE: draft-ietf-dots-data-channel: Filter Direction) =20 Hi Jon, =20 Please see inline =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Friday, February 16, 2018 5:33 PM To: Konda, Tirumaleswar Reddy ; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] Call home in the signal channel (was RE: draft-ietf-dots-data-channel: Filter Direction) =20 Hi Tiru, =20 The more I think about it, =93Call Home=94 support in either the data or = signal channel makes no real sense for https://tools.ietf.org/html/draft-ietf-dots-use-cases-09#section-3.2.1 . The CPE devices don=92t need to trigger the DOTS clients to get = mitigation in place as it will be the provider who works this out. =20 [TR] No, the above use case helps the CPE isolate the compromised = devices launching DDoS attacks and protect other devices in the local network = from getting infected. [Jon] OK, so the CPE says to itself =93No idea what is going on, but = something bad is happening=94, so I will call home to the provider for them to = work out what is going on and get them to tell me what to do by sending me some = ACLs. [Jon] Did I understand this correctly? =20 However, for 3.2.1, the DOTS client will need to make a mitigation = request to initiate the implementing of (previously defined) ACLs using the = signal channel as there will be a high possibility of the outbound pipe running full. =20 [TR] ACL can be enforced with =93activation=94 type set to = =93immediate=94 using the DOTS data channel itself.=20 [Jon] Agreed this can be done, but (TCP) will fail if the outgoing pipe = is full and so the ACL cannot be put in place. A signal =93mitigate to = this target prefix=94 will get through though and so kill off some of the = traffic going out to the Internet going to the target prefix. =20 -Jon =20 -Tiru =20 Regards =20 Jon From: Dots [mailto: dots-bounces@ietf.org ] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 16 February 2018 11:00 To: mohamed.boucadair@orange.com; Jon Shallow; dots@ietf.org Subject: Re: [Dots] Call home in the signal channel (was RE: draft-ietf-dots-data-channel: Filter Direction) =20 For the discussed use case https://tools.ietf.org/html/draft-ietf-dots-use-cases-09#section-3.2.1, = the CPE needs to act as a DOTS server only for the data channel but not for = the signal channel. I don=92t think signal-channel requires call home functionality, what is the use case ? =20 -Tiru =20 From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] = Sent: Friday, February 16, 2018 3:49 PM To: Jon Shallow ; Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: Call home in the signal channel (was RE: [Dots] draft-ietf-dots-data-channel: Filter Direction) =20 Hi Jon,=20 =20 I=92m changing the title to keep track of signal-channel specific = issues.=20 =20 Please use this one to discuss this use case. =20 Thank you.=20 =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : vendredi 16 f=E9vrier 2018 10:57 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; = dots@ietf.org Objet : RE: [Dots] draft-ietf-dots-data-channel: Filter Direction =20 I understand the concept of call home =96 which makes good sense to me = and rfc8071 will, if implemented, handle the data channel and = =93destination=94 is still where the =91controlled=92 traffic is flowing to. =20 However, we also need call home in the signal channel. I=92m not sure = how this will be done =96 do we need a new CoAP Method (e.g. switch roles) = =96 do we need to define a different port (rfc8071 defines 4336) etc. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 16 February 2018 09:07 To: mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction =20 From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] = Sent: Friday, February 16, 2018 2:19 PM To: Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: RE: draft-ietf-dots-data-channel: Filter Direction =20 Re-, =20 Please see inline.=20 =20 Cheers, Med =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, = Tirumaleswar Reddy Envoy=E9 : vendredi 16 f=E9vrier 2018 09:28 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] draft-ietf-dots-data-channel: Filter Direction =20 There is no ambiguity in the roles. The CPE is acting as DOTS server but = the DOTS server is initiating connection to the DOTS client in the access network. [Med] Don=92t get the last part. The server (CPE) will receive a request = from the network (client) to filter traffic exiting from that CPE.=20 =20 [TR] I mean to use the call home feature discussed in https://tools.ietf.org/html/rfc8071, though the CPE is acting as a DOTS server it will initiate the connection (TLS or DTLS) to the DOTS client = in the access network. The call home feature helps avoid various threats = like the DOTS server in the CPE will not be subjected to DDoS attacks, and reachability is not problem even if the CPE is behind NAT.=20 =20 The DOTS client will convey the black-list filtering in the =93out=94 = direction to block the traffic originating from the DOTS server domain. [Med] Which corresponds to the =93DOTS Server to DOTS Client=94 = direction; that is the DOTS client domain (access network) is the destination. All is = fine so far :)=20 =20 =20 [TR] The direction is =93outgoing traffic=94 whereas for other use cases = the direction is =93incoming traffic=94.=20 =20 I don=92t understand what you mean by a =93optional=94 parameter ? [Med] I meant adding a parameter to indicate explicitly the direction. = It would be optional because we do already have a default direction. =20 [TR] Okay. =20 -Tiru =20 -Tiru =20 From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: Friday, February 16, 2018 1:24 PM To: Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction =20 Hi Tiru,=20 =20 There will be an ambiguity in interpreting filters if and only if the = same DOTS agents have to manipulate filters in both directions.=20 =20 As you rightfully mentioned, the bb use case assumes the following:=20 =20 In order to achieve this capability, the telemetry analysis system utilized by the broadband access provider must have DOTS client functionality, and the end-customer CPE devices must have DOTS server functionality. =20 Which means that there is no ambiguity in that case with the current = default direction: =93the destination is the DOTS client domain=94.=20 =20 No matter how roles were negotiated, but as far as each an agent acts as = a client and its peer as a server, things are clear.=20 =20 Of course we can always define an optional parameter for this, but it is preferable to have a case for it. =20 =20 Cheers, Med =20 De : Konda, Tirumaleswar Reddy = [mailto:TirumaleswarReddy_Konda@McAfee.com]=20 Envoy=E9 : jeudi 15 f=E9vrier 2018 16:31 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: draft-ietf-dots-data-channel: Filter Direction =20 The filtering rule for outgoing traffic is required for the "Suppression = of outbound DDoS traffic originating from a consumer broadband access = network" use case discussed in https://tools.ietf.org/html/draft-ietf-dots-use-cases-09#section-3.2.1. = In this use case, the CPE initially acts as a DOTS client but after the TCP connection is established, reverses its role and acts as DOTS server = (see https://tools.ietf.org/html/rfc8071). The access network can then = program the CPE using the DOTS data channel to block the DDoS attack traffic originated from the compromised devices in the=20 local customer network.=20 =20 Cheers, -Tiru =20 From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: Wednesday, February 14, 2018 1:49 PM To: dots@ietf.org Subject: [Dots] draft-ietf-dots-data-channel: Filter Direction =20 Hi all,=20 =20 As agreed during the interim, there are some issues that need fixes in = the data-channel spec. We would like to hear from the WG to know what to = record in the document.=20 =20 Issue description: Do we need to support explicit =93direction=94 in = filtering rules (=93in=94/=93out=94)? That is, do we allow a DOTS client to create = filters for both incoming and outgoing traffic?=20 =20 Below a proposal for discussion: =96 The current default direction is aligned with the nature of DDoS attacks targeted by DOTS: i.e. incoming. The DOTS client domain is = assumed to be the destination. No ambiguity so far with such default behavior.=20 =96 There is no clear use case for the support of outgoing filtering handling in the context of DOTS. =96 No text change is required to the draft. =20 Any objection?=20 =20 Cheers, Med=20 =20 ------=_NextPart_000_01B5_01D3A72B.B5AA1010 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

See inline = [Jon]

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = Konda, Tirumaleswar Reddy
Sent: 16 February 2018 = 13:13
To: Jon Shallow; mohamed.boucadair@orange.com; = dots@ietf.org
Subject: Re: [Dots] Call home in the signal = channel (was RE: draft-ietf-dots-data-channel: Filter = Direction)

 

Hi = Jon,

 

Please see = inline

 

From: Jon Shallow = [mailto:supjps-ietf@jpshallow.com]
Sent: Friday, February 16, = 2018 5:33 PM
To: Konda, Tirumaleswar Reddy = <TirumaleswarReddy_Konda@McAfee.com>; = mohamed.boucadair@orange.com; dots@ietf.org
Subject: RE: = [Dots] Call home in the signal channel (was RE: = draft-ietf-dots-data-channel: Filter = Direction)

 

Hi Tiru,

 

The more I think about = it, “Call Home” support in either the data or signal channel = makes no real sense for https://tools.ietf.org/html/draft-ietf-dots-use-cases-09#section-3= .2.1 .  The CPE devices don’t need to trigger the DOTS = clients to get mitigation in place as it will be the provider who works = this out.

 

[TR] No, the above use case helps = the CPE isolate the compromised devices launching DDoS attacks and = protect other devices in the local network from getting infected.

[Jon] OK, so the CPE = says to itself “No idea what is going on, but something bad is = happening”, so I will call home to the provider for them to work = out what is going on and get them to tell me what to do by sending me = some ACLs.

[Jon] Did I = understand this correctly?

 

However, for 3.2.1, the DOTS client = will need to make a mitigation request to initiate the implementing of = (previously defined) ACLs using the signal channel as there will be a = high possibility of the outbound pipe running = full.

 

[TR] ACL can be enforced  with = “activation” type set to “immediate” using the = DOTS data channel itself.

[Jon] Agreed this can = be done, but (TCP) will fail if the outgoing pipe is full and so the ACL = cannot be put in place.=A0 A signal “mitigate to this target = prefix” will get through though and so kill off some of the = traffic going out to the Internet going to the target = prefix.

 

-Jon=

 

-Tiru

 

Regards

 

Jon

From: Dots [mailto: = dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar = Reddy
Sent: 16 February 2018 11:00
To: mohamed.boucadair@orange.com= ; Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] Call home in the signal channel (was RE: = draft-ietf-dots-data-channel: Filter = Direction)

 

For the = discussed use case https://tools.ietf.org/html/draft-ietf-dots-use-cases-09#section-3= .2.1, the CPE needs to act as a DOTS server only for the data = channel but not for the signal channel. I don’t think signal-channel = requires call home functionality, what is the use case = ?

 

-Tiru

 

From: mohamed.boucadair@orange.com= [mailto:mohamed.boucadair@ora= nge.com]
Sent: Friday, February 16, 2018 3:49 = PM
To: Jon Shallow <supjps-ietf@jpshallow.com&g= t;; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; dots@ietf.org
Subject: Call = home in the signal channel (was RE: [Dots] draft-ietf-dots-data-channel: = Filter Direction)

 

Hi Jon, =

 

I’m changing the title to keep track of = signal-channel specific issues.

 

Please use this one to discuss this use = case.

 

Thank you.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Envoy=E9 : vendredi 16 f=E9vrier 2018 = 10:57
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR = Mohamed IMT/OLN; dots@ietf.org
Objet : = RE: [Dots] draft-ietf-dots-data-channel: Filter = Direction

 

I understand the concept of call home – = which makes good sense to me and rfc8071 will, if implemented, handle = the data channel and “destination” is still where the = ‘controlled’ traffic is flowing to.

 

However, we also need = call home in the signal channel.  I’m not sure how this will = be done – do we need a new CoAP Method (e.g. switch roles) – = do we need to define a different port (rfc8071 defines 4336) = etc.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 16 February 2018 = 09:07
To: mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: Re: = [Dots] draft-ietf-dots-data-channel: Filter = Direction

 

From: mohamed.boucadair@orange.com= [mailto:mohamed.boucadair@ora= nge.com]
Sent: Friday, February 16, 2018 2:19 = PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; dots@ietf.org
Subject: RE: = draft-ietf-dots-data-channel: Filter Direction

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] = De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : = vendredi 16 f=E9vrier 2018 09:28
=C0 : BOUCADAIR Mohamed = IMT/OLN; dots@ietf.org
Objet : = Re: [Dots] draft-ietf-dots-data-channel: Filter = Direction

 

There is no ambiguity = in the roles. The CPE is acting as DOTS server but the DOTS server is = initiating connection to the DOTS client in the access network.

[Med] Don’t get the = last part. The server (CPE) will receive a request from the network = (client) to filter traffic exiting from that CPE. =

 

[TR] I mean to use the call home = feature discussed in https://tools.ietf.org/html/= rfc8071, though the CPE is acting as a DOTS server it will initiate = the connection (TLS or DTLS) to the DOTS client in the access network. = The call home feature helps avoid various threats like the DOTS server = in the CPE will not be subjected to DDoS attacks, and reachability is = not problem even if the CPE is behind NAT.

 

=

The DOTS client will convey the = black-list filtering in the “out” direction to block the = traffic originating from the DOTS server domain.

[Med] Which corresponds to = the “DOTS Server to DOTS Client” direction; that is the DOTS = client domain (access network) is the destination. All is fine so far :) =

 

 

[TR] The direction is = “outgoing traffic” whereas for other use cases the direction = is “incoming traffic”.

 

=

I don’t understand what you = mean by a “optional” parameter ?

[Med] I meant adding a = parameter to indicate explicitly the direction. It would be optional = because we do already have a default direction.

 

[TR] Okay.

 

-Tiru

 

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of mohamed.boucadair@orange.com=
Sent: Friday, February 16, 2018 1:24 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; dots@ietf.org
Subject: Re: = [Dots] draft-ietf-dots-data-channel: Filter = Direction

 

Hi Tiru,

 

There will be an ambiguity in interpreting filters if = and only if the same DOTS agents have to manipulate filters in both = directions.

 

As you rightfully mentioned, the bb use case assumes = the following:

 

   In order to achieve this = capability, the telemetry analysis system

   utilized by the broadband = access provider must have DOTS client

   functionality, and the = end-customer CPE devices must have DOTS server

   functionality.

 

Which means that there is no ambiguity in that case = with the current default direction: “the destination is the DOTS = client domain”.

 

No matter how roles were =
negotiated, but as far as each an agent acts as a client and its peer as =
a server, things are clear. 
 
<= pre>Of course we can always define = an optional parameter for this, but it is preferable to have a case for = it.  
 
<= pre>Cheers,= 
Med

 

De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarRed= dy_Konda@McAfee.com]
Envoy=E9 : jeudi 15 f=E9vrier = 2018 16:31
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : = RE: draft-ietf-dots-data-channel: Filter = Direction

 

The filtering rule for = outgoing traffic is required for the "Suppression of outbound DDoS = traffic originating from a consumer broadband access network" use = case discussed in https://tools.ietf.org/html/draft-ietf-dots-use-cases-09#section-3= .2.1. In this use case, the CPE initially acts as a DOTS client but = after the TCP connection is established, reverses its role and acts as = DOTS server (see https://tools.ietf.org/html/= rfc8071). The access network can then program the CPE using the DOTS = data channel to block the DDoS attack traffic originated from the = compromised devices in the

local customer network. =

 

Cheers,

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of mohamed.boucadair@orange.com=
Sent: Wednesday, February 14, 2018 1:49 PM
To: = dots@ietf.org
Subject: = [Dots] draft-ietf-dots-data-channel: Filter = Direction

 

Hi = all,

 

As = agreed during the interim, there are some issues that need fixes in the = data-channel spec. We would like to hear from the WG to know what to = record in the document.

 

Issue = description: Do we need to support explicit “direction” in = filtering rules (“in”/“out”)? That is, do we = allow a DOTS client to create filters for both incoming and outgoing = traffic?

 

Below = a proposal for discussion:

–    The current default = direction is aligned with the nature of DDoS attacks targeted by DOTS: = i.e. incoming. The DOTS client domain is assumed to be the destination. = No ambiguity so far with such default behavior.

–    There is no clear = use case for the support of outgoing filtering handling in the context = of DOTS.

–    No text change is = required to the draft.

 

Any objection? =

 

Cheers,

Med =

 

------=_NextPart_000_01B5_01D3A72B.B5AA1010-- From nobody Fri Feb 16 05:55:25 2018 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 54CCF1273B1 for ; Fri, 16 Feb 2018 05:55:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 dQkxlKJ-j29x for ; Fri, 16 Feb 2018 05:55:21 -0800 (PST) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 09DA1127023 for ; Fri, 16 Feb 2018 05:55:20 -0800 (PST) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1518789320; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=8 RFuopTkSPMXBUeTxp8OUG9mDbnssGuyH2dhr+v+ks o=; b=Esza12EGHEsUWHfF11gZVT1hgnIwnNfdVNlS6RmPxjKB CIE0xDD3AG10l8areEt9BEBLMcSHr3MszcIZLoUt56d+rqTOUk LXSrLlOGaQCopj0scQMxm2W0r1M8KA4Wa+3RgZCxoXE+1UR9xD TbvTCys+F8W0UescrRGF+VOP+nU= Received: from MIVEXAPP1N01.corpzone.internalzone.com (mivexapp1n01.corpzone.internalzone.com [10.48.48.88]) by MIVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 4a8a_d34e_309ca5e7_ce11_4d49_b10f_056cc2dd7cd0; Fri, 16 Feb 2018 07:55:19 -0600 Received: from MIVEXUSR1N06.corpzone.internalzone.com (10.48.48.86) by MIVEXAPP1N01.corpzone.internalzone.com (10.48.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 16 Feb 2018 08:55:15 -0500 Received: from MIVEXUSR1N06.corpzone.internalzone.com (10.48.48.86) by MIVEXUSR1N06.corpzone.internalzone.com (10.48.48.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 16 Feb 2018 08:55:14 -0500 Received: from MIVO365EDGE3.corpzone.internalzone.com (10.48.176.86) by MIVEXUSR1N06.corpzone.internalzone.com (10.48.48.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Fri, 16 Feb 2018 08:55:14 -0500 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.1347.2; Fri, 16 Feb 2018 08:55:12 -0500 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB2168.namprd16.prod.outlook.com (52.132.142.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.18; Fri, 16 Feb 2018 13:55:11 +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.20.0485.022; Fri, 16 Feb 2018 13:55:11 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] draft-ietf-dots-data-channel: Filtering Fields Thread-Index: AdOlbICGgF2MxoHnQied7J+cvW2QAABhQcigAAKnFWAAAuyKQAAGTI4AAAEahwAAASoGAAAAJ8mAAAB6+CA= Date: Fri, 16 Feb 2018 13:55:11 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A0D1F93@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0D32AE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00e801d3a721$08806d30$19814790$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0D366E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019201d3a72a$1b103b70$5130b250$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0D372A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A0D372A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [171.61.123.199] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB2168; 7:WEHue4stRleu/lkt8QcTsvMowmowPA9q33OqKRdjBxj+MKc7vHnhKxBFy8UBfhN20JbLsjRSYkCAsjcxYS46W6B62deRUc31tKd1IKGIUOYlm+9P1HZChMR5eA5rB7mA5HGjByfAU4FHsRLfsC9EgGhseOBo19w+C0IrQOa21yacJ23Bo1Z73XdhFf75GNRohFrgOjXhdWbvqskkBLV+fGgFon36Ygp/Dyy3LwsbFNfj9thfbE63tsAqZCVq4P1j x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: ffcf898d-9905-4013-2997-08d57544e591 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM5PR16MB2168; x-ms-traffictypediagnostic: DM5PR16MB2168: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(18271650672692)(21748063052155)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3231101)(944501161)(10201501046)(3002001)(93006095)(93001095)(6041288)(20161123562045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011); SRVR:DM5PR16MB2168; BCL:0; PCL:0; RULEID:; SRVR:DM5PR16MB2168; x-forefront-prvs: 0585417D7B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(376002)(346002)(39380400002)(39860400002)(53754006)(57704003)(199004)(189003)(51444003)(32952001)(5660300001)(229853002)(55016002)(6306002)(33656002)(80792005)(8936002)(6436002)(99286004)(790700001)(3846002)(6116002)(7736002)(97736004)(53936002)(478600001)(8676002)(2950100002)(81156014)(81166006)(606006)(106356001)(105586002)(72206003)(6246003)(76176011)(54896002)(236005)(9686003)(316002)(110136005)(86362001)(2900100001)(25786009)(14454004)(7696005)(966005)(59450400001)(345774005)(6506007)(74316002)(186003)(102836004)(93886005)(3660700001)(3280700002)(68736007)(66066001)(2906002)(53546011)(26005)(2501003)(77096007)(19609705001)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB2168; 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) x-microsoft-antispam-message-info: pQIAUljNaMRyBsbv5kuOmbcTqPQWaqxAnwfRdHePvG8dUIXtIhP80QNFWanXW4x76YUDKcsB0MKOIcFAfTV/wg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB17887CCC13E3B2FED86FE3F2EACB0DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ffcf898d-9905-4013-2997-08d57544e591 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2018 13:55:11.1108 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB2168 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 <6224> : inlines <6404> : streams <1779150> : uri <2593900> Archived-At: Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields 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, 16 Feb 2018 13:55:24 -0000 --_000_DM5PR16MB17887CCC13E3B2FED86FE3F2EACB0DM5PR16MB1788namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1. In TCP, only "flags" field looks mandatory. -Tiru From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 7:03 PM To: Jon Shallow ; Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields Re-, I tend to agree with you to have to define a minimum set of mandatory match= fields. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 16 f=E9vrier 2018 14:29 =C0 : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; dots@ietf.org Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields Hi Med, See inline [Jon] Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 16 February 2018 12:56 To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields Jon, Thank you for sharing your thoughts. Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 16 f=E9vrier 2018 13:24 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org= Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields I like the concept of "+--ro capabilities" allowing for future support as t= he DOS server becomes more mature in its capabilities. If a DOTS client includes a filtering field parameter that is not currently= supported, should the parameter be ignored (and not returned for a GET), o= r the request rejected? [Med] I would vote for rejecting the request. The client should only use ma= tch criteria that are understood by the server; otherwise there will be dif= ferent expectation from the service. [Jon] I think that this is my preference - I was just seeking clarity of th= inking. It is conceivable that a DOTS client has 2 DOTS servers (one possibly a bac= kup, or 2 different ISPs), which may have differing filtering field paramet= er support capabilities. [Med] The backup/case seems odd. I would expect a feature parity for a redu= ndancy group used to provide the same service. [Jon] Agreed that a backup server is most likely to be from the same manufa= cturer and hence support the same functionality. But one may have just bee= n upgraded to have extra support. Adding in intelligence code to work out what is / is not allowed may not = be practical in a (memory or cpu) constrained environment of the DOTS clien= t. [Med] Fair. That said, I think we need to define the minimum set of supported parameter= s - e.g. protocol, source / dest ports, source / dest IPv4 prefixes, sourc= e / dest IPv6 prefixes, fragments and icmp type/code. [Jon] Any comments? -Jon Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 16 February 2018 10:18 To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields Hi Med, Please see inline [TR2] From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 1:45 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: draft-ietf-dots-data-channel: Filtering Fields Re-, Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 16 f=E9vrier 2018 08:00 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Wednesday, February 14, 2018 1:49 PM To: dots@ietf.org Subject: [Dots] draft-ietf-dots-data-channel: Filtering Fields Hi all, As agreed during the interim, there are some issues that need fixes in the = data-channel spec. We would like to hear from the WG to know what to record= in the document. Issue description: Should we support all of the match fields defined by "ie= tf-packet-fields" or do we need to define a minimum supported set? [TR] I don't see the need to support all the match fields, define a minimum= supported set (don't see the use for acl-eth-header-fields for DOTS use ca= ses). [Med] Agree that acl-eth-header-fields aren't required. The text is already= clear about this: DOTS implementations MUST support the following matching criteria: match based on the IP header (IPv4 and IPv6), match based on the transport header (TCP, UDP, and ICMP), and any combination thereof. The question is whether we need to go further and mandate (or not) the supp= ort of matching based on specific fields: dscp, ecn, ttl,... flow-label, ..= . tcp sequence-number, tcp flags, ... [TR2] https://tools.ietf.org/html/draft-ietf-netmod-acl-model-16 uses the f= eature statements in the YANG model allowing vendors to advertise match rul= es they are capable and willing to support but not at the field-level. The = problem is router implementations today don't support ACLs with tcp sequenc= e-number, acknowledgement-number, window-size etc but support TCP flags. If= the server could convey the list of match criteria supported, it not only = allows the client to convey the supported match rules but also allows the s= erver in future to advertise the new supported match fields. Would it be useful for a client to retrieve the list of match criteria supp= orted by a DOTS server? [TR2] Yes. -Tiru [TR] The YANG model supported by the DOTS server can retrieved by the DOTS = client using RESTCONF to determine the match criteria supported by the serv= er. [Med] I'm afraid this is not the same functionality. If we need to allow a = server to return its supported match criteria, this should be allowed by th= e module. For example, the module may include the following (example): +--ro capabilities | +--ro match-header* | | identityref | +--ro transport-protocols* [protocol-id] | | +--ro protocol-id uint8 | | +--ro protocol-name? string | +--ro dscp-support? boolean | +--ro ecn-support? boolean | +--ro length-support? boolean | +--ro ttl-support? boolean | +--ro protocol-support? boolean The client can ask the server to return its supported match criteria. The s= erver will indicate the exact set of fields it supports. I'm not expressing a preference to have this in the model, but I'm clarifyi= ng how it would look like. -Tiru Please comment. Cheers, Med --_000_DM5PR16MB17887CCC13E3B2FED86FE3F2EACB0DM5PR16MB1788namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

+1. I= n TCP, only “flags” field looks mandatory.

 

-Tiru

 

From:<= /span> mohamed.boucadair@ora= nge.com [mailto:mohamed.boucadair@orange.com]
Sent: Friday, February 16, 2018 7:03 PM
To: Jon Shallow <supjps-ietf@jpshallow.com>; Konda, Tirumalesw= ar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields

 

Re-,

 

I tend to agree with you to have to define a m= inimum set of mandatory match fields.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : vendredi 16 f=E9vrier 2018 14:29
=C0 : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; dots@ietf.org
Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fiel= ds

 

Hi Med,=

&n= bsp;

See inl= ine [Jon]

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 16 February 2018 12:56
To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields

 

Jon,

 

Thank you for sharing your thoughts.

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : vendredi 16 f=E9vrier 2018 13:24
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; <= a href=3D"mailto:dots@ietf.org"> dots@ietf.org
Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fiel= ds

 

I like the concept of “+=
--ro capabilities“ allowing for future support as t=
he DOS server becomes more mature in its capabilities.

 


If a DOTS client includes a filtering field parameter that =
is not currently supported, should the parameter be ignored (and not return=
ed for a GET), or the request rejected?


[Med] I would vote for re=
jecting the request. The client should only use match criteria that are und=
erstood by the server; otherwise there will be different expectation from t=
he service. 


[Jon] I think that this is my preference – I was just=
 seeking clarity of thinking.


<=
o:p> 


It is conceivable that a DOTS client has 2 DOTS servers (on=
e possibly a backup, or 2 different ISPs), which may have differing filteri=
ng field parameter support capabilities.


[Med] The backup/case see=
ms odd. I would expect a feature parity for a redundancy group used to prov=
ide the same service.=



[=
Jon] Agreed that a backup server is most likely to be from the same manufac=
turer and hence support the same functionality.  But one may have just=
 been upgraded to have extra support.


<=
o:p> 


 <=
/pre>

 <=
/pre>

  Adding in intelligence code to work out what is / is=
 not allowed may not be practical in a (memory or cpu) constrained environm=
ent of the DOTS client.


[Med] Fair. 


 


That said, I think we need to define the minimum set of sup=
ported parameters – e.g. protocol, source / dest ports,  source =
/ dest IPv4 prefixes, source / dest IPv6 prefixes, fragments and icmp type/=
code. 


[Jon] Any comments?


<=
o:p> 


-=
Jon


<=
o:p> 


Regards


 


Jon


&n=
bsp;






From: Dots [mailto:
dots-bounces@ietf.org] On B=
ehalf Of
Konda, Tirumaleswar Reddy

Sent: 16 February 2018 10:18

To: mohamed.boucadai=
r@orange.com;
dots@ietf.org

Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields






 


Hi Med,


&nbs=
p;


Please se=
e inline [TR2]


&nbs=
p;








From:<=
/span>
mohamed.boucadair@orange.co=
m [mailto:mohamed.bouca=
dair@orange.com]


Sent: Friday, February 16, 2018 1:45 PM

To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>;
dots@ietf.org

Subject: RE: draft-ietf-dots-data-channel: Filtering Fields






 


Re-,


 


Please see inline.



 


Cheers,


Med


 








De : Dots [mailto:dots-bounces@ietf.org]
De la part de Konda, Tirumaleswar Reddy

Envoy=E9 : vendredi 16 f=E9vrier 2018 08:00

=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org

Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fiel=
ds






 


From:<=
/span> Dots [mailto:dots-bounces@ietf.org]
On Behalf Of mohamed=
.boucadair@orange.com

Sent: Wednesday, February 14, 2018 1:49 PM

To: dots@ietf.org

Subject: [Dots] draft-ietf-dots-data-channel: Filtering Fields<=
/o:p>


 


Hi all,



 


As agreed during the interim, there are some issues that n=
eed fixes in the data-channel spec. We would like to hear from the WG to kn=
ow what to record in the document.



 


Issue description: Should we support all of the match fiel=
ds defined by “ietf-packet-fields” or do we need to define a mi=
nimum supported set?



 


[TR] I don’t see the need to support all the m=
atch fields, define a minimum supported set (don’t see the use for ac=
l-eth-header-fields for DOTS use cases).  


[Med] Agree that acl-eth-header-fields aren=
217;t required. The text is already clear about this:


 


DOTS implementations MUST support =
the following


   matching criteria: ma=
tch based on the IP header (IPv4 and IPv6),


   match based on the tr=
ansport header (TCP, UDP, and ICMP), and any


  
combination thereof.=



 


The question is whether we need to go fu=
rther and mandate (or not) the support of matching based on specific fields=
: dscp, ecn, ttl,… flow-label, … tcp s=
equence-number, tcp flags, …  <=
/o:p>


 


[TR2] https://tools.ietf.o=
rg/html/draft-ietf-netmod-acl-model-16 uses the feature statements in the YANG model allowin=
g vendors to advertise match rules they are capable and willing to support =
but not at the field-level. The problem is router implementations today don=
’t support ACLs with tcp sequence-number, acknowledgement-number, win=
dow-size etc but support TCP flags. If the server could convey the list of =
match criteria supported, it not only allows the client to convey the suppo=
rted match rules but also allows the server in future to advertise the new =
supported match fields.   


 


Would it be useful for a client to retrieve the list of ma=
tch criteria supported by a DOTS server?



 


[TR2] Yes. 


 


-Tiru


 


[TR] The YANG model supported by the DOTS server can=
 retrieved by the DOTS client using RESTCONF to determine the match criteri=
a supported by the server.



[Med] I’m afraid this is not the same fu=
nctionality. If we need to allow a server to return its supported match cri=
teria, this should be allowed by the module. For example,
 the module may include the following (example): 


 


        &nbs=
p;       +--ro capabilities


        &nbs=
p;       |  +--ro match-header*=



        &nbs=
p;       |  |    &nb=
sp;  identityref


        &nbs=
p;       |  +--ro transport-protocol=
s* [protocol-id]


        &nbs=
p;       |  |  +--ro protocol-i=
d      uint8


        &nbs=
p;       |  |  +--ro protocol-n=
ame?   string


        &nbs=
p;       |  +--ro dscp-support? &nbs=
p;     boolean


        &nbs=
p;       |  +--ro ecn-support?  =
;      boolean


        &nbs=
p;       |  +--ro length-support? &n=
bsp;   boolean


        &nbs=
p;       |  +--ro ttl-support?  =
;      boolean


        &nbs=
p;       |  +--ro protocol-support? =
  boolean


 


The client can ask the server to return its supported match criteria. The server will indicate the =
exact set of fields it supports. 


 


I’m not expressing a preference to=
 have this in the model, but I’m clarifying how it would look like. <=
/span>


 


-Tiru


 


Please comment.



 <=
/p>

Cheers,=



Med
--_000_DM5PR16MB17887CCC13E3B2FED86FE3F2EACB0DM5PR16MB1788namp_-- From nobody Fri Feb 16 06:19:26 2018 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 749EF12751F for ; Fri, 16 Feb 2018 06:19:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.33 X-Spam-Level: X-Spam-Status: No, score=-4.33 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 calpR6nRCd8s for ; Fri, 16 Feb 2018 06:19:22 -0800 (PST) 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 8D9F41273B1 for ; Fri, 16 Feb 2018 06:19:21 -0800 (PST) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1518790760; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:x-originating-ip: x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:authentication-results: x-microsoft-antispam-message-info:spamdiagnosticoutput: spamdiagnosticmetadata:Content-Type:MIME-Version: X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=e Fvg6jEOzg54gFgmt78chMuHMG2iAKvhX1/T1OFL8W I=; b=J3u5TPFPdRvMhtbe10SvQoqP2YVLSBOBx7BxJ6pofQVd lmCEPC1qu4Y7pfbdkO56xoOxpOOLrJF1YUTY++8F5OIpwt8VfS ZjwZwn8y/13WDyDwmHnBWzC+rG3VTVmJaKIvz5hebIk3Q8mWnw KDEAT7TXTBp8HZ4alg51W8LChQA= Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 40d5_6259_095a8a59_6c3b_4c36_b271_c3a2fdb682ca; Fri, 16 Feb 2018 08:19:19 -0600 Received: from DNVEXUSR1N13.corpzone.internalzone.com (10.44.48.86) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 16 Feb 2018 07:19:01 -0700 Received: from DNVEXUSR1N13.corpzone.internalzone.com (10.44.48.86) by DNVEXUSR1N13.corpzone.internalzone.com (10.44.48.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 16 Feb 2018 07:19:00 -0700 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXUSR1N13.corpzone.internalzone.com (10.44.48.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Fri, 16 Feb 2018 07:19:00 -0700 Received: from NAM02-SN1-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.1347.2; Fri, 16 Feb 2018 07:18:30 -0700 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB0108.namprd16.prod.outlook.com (10.172.91.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.18; Fri, 16 Feb 2018 14:18:54 +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.20.0485.022; Fri, 16 Feb 2018 14:18:54 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: [Dots] Call home in the signal channel (was RE: draft-ietf-dots-data-channel: Filter Direction) Thread-Index: AQHTpx4fYQaVBSxJJEC02ounCseemaOm/iRwgAALCoCAAARH0A== Date: Fri, 16 Feb 2018 14:18:54 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A0D3439@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00d201d3a71e$05ead590$11c080b0$@jpshallow.com> <01b401d3a72b$b5a79f10$20f6dd30$@jpshallow.com> In-Reply-To: <01b401d3a72b$b5a79f10$20f6dd30$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action x-originating-ip: [171.61.123.199] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB0108; 7:/hZdVgYMb0ZpETC7dLcmIl8I61CJX4hhOnLmUJPISHqOVwkHDhwAji/6fbo/boT5W84aHR1WY1iZPOyQRhK/sydxNTLdMEvUNjhKBFpLetrUyPmjIivLl97L2hvY48fPnuEPyRUV7B45VsKGRVOjQXx+unnNTToLpbOLZHx4C9mZ3j9EiUNe4cTxUAd6t5zlYVpsotz/Gbr8d/AQo0WyD9u6FHIWh3x5/9pEmJGn4mGgk+Z/zU/NKwuq+Wc9M8TR x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 31dc3629-427d-4420-f296-08d5754835fe x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM5PR16MB0108; x-ms-traffictypediagnostic: DM5PR16MB0108: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(18271650672692)(21748063052155)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001037)(6040501)(2401047)(5005006)(8121501046)(3002001)(10201501046)(3231101)(944501161)(93006095)(93001095)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:DM5PR16MB0108; BCL:0; PCL:0; RULEID:; SRVR:DM5PR16MB0108; x-forefront-prvs: 0585417D7B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39840400004)(366004)(396003)(346002)(376002)(39380400002)(32952001)(199004)(57704003)(189003)(53754006)(5660300001)(59450400001)(25786009)(561944003)(81156014)(3660700001)(3280700002)(2906002)(7696005)(81166006)(110136005)(966005)(99286004)(2201001)(606006)(2501003)(790700001)(76176011)(2950100002)(8936002)(14454004)(86362001)(72206003)(33656002)(106356001)(66066001)(54896002)(236005)(6306002)(478600001)(8676002)(80792005)(6116002)(68736007)(6506007)(6246003)(7736002)(6346003)(93886005)(9686003)(97736004)(74316002)(229853002)(53546011)(53946003)(53936002)(3846002)(77096007)(26005)(2900100001)(55016002)(19609705001)(186003)(316002)(6436002)(105586002)(102836004)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB0108; 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) authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-microsoft-antispam-message-info: +T+UAJQUef3oF94GIHovp2deD4iXRdSyVQDxGk93huoDBohVzaT5NTq4XBhFwE4hs6W7uI6+HJqKb5VFN0dhnw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB178877A652F156EE4F538869EACB0DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 31dc3629-427d-4420-f296-08d5754835fe X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2018 14:18:54.5382 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB0108 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 <6224> : inlines <6404> : streams <1779152> : uri <2593912> Archived-At: Subject: Re: [Dots] Call home in the signal channel (was RE: draft-ietf-dots-data-channel: Filter Direction) 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, 16 Feb 2018 14:19:25 -0000 --_000_DM5PR16MB178877A652F156EE4F538869EACB0DM5PR16MB1788namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Friday, February 16, 2018 7:10 PM To: Konda, Tirumaleswar Reddy ; mohamed= .boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] Call home in the signal channel (was RE: draft-ietf-dot= s-data-channel: Filter Direction) Hi Tiru, See inline [Jon] Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 16 February 2018 13:13 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] Call home in the signal channel (was RE: draft-ietf-dot= s-data-channel: Filter Direction) Hi Jon, Please see inline From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Friday, February 16, 2018 5:33 PM To: Konda, Tirumaleswar Reddy >; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] Call home in the signal channel (was RE: draft-ietf-dot= s-data-channel: Filter Direction) Hi Tiru, The more I think about it, "Call Home" support in either the data or signal= channel makes no real sense for https://tools.ietf.org/html/draft-ietf-dot= s-use-cases-09#section-3.2.1 . The CPE devices don't need to trigger the D= OTS clients to get mitigation in place as it will be the provider who works= this out. [TR] No, the above use case helps the CPE isolate the compromised devices l= aunching DDoS attacks and protect other devices in the local network from g= etting infected. [Jon] OK, so the CPE says to itself "No idea what is going on, but somethin= g bad is happening", so I will call home to the provider for them to work o= ut what is going on and get them to tell me what to do by sending me some A= CLs. [Jon] Did I understand this correctly? [TR2] No, the CPE may not even know if something bad is happening in its ne= twork. The CPE proactively initiates and establishes TLS session with the p= rovider, and simply waits for requests from the provider to tell if there i= s something wrong (It's a long-lived session). Similar technique is also us= ed to manage secure home gateways from cloud managment. However, for 3.2.1, the DOTS client will need to make a mitigation request = to initiate the implementing of (previously defined) ACLs using the signal = channel as there will be a high possibility of the outbound pipe running fu= ll. [TR] ACL can be enforced with "activation" type set to "immediate" using t= he DOTS data channel itself. [Jon] Agreed this can be done, but (TCP) will fail if the outgoing pipe is = full and so the ACL cannot be put in place. A signal "mitigate to this tar= get prefix" will get through though and so kill off some of the traffic goi= ng out to the Internet going to the target prefix. [TR2] My understanding is Mirai attacks do not choke the outgoing link in t= he local network, otherwise the home admin can easily detect the bandwidth = hogging devices, rate-limit the traffic/turn-off the devices. The goal is t= o attack a target in some external domain but at the same-time not to disru= pt local services to avoid any remediation. -Tiru -Jon -Tiru Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 16 February 2018 11:00 To: mohamed.boucadair@orange.com; Jon = Shallow; dots@ietf.org Subject: Re: [Dots] Call home in the signal channel (was RE: draft-ietf-dot= s-data-channel: Filter Direction) For the discussed use case https://tools.ietf.org/html/draft-ietf-dots-use-= cases-09#section-3.2.1, the CPE needs to act as a DOTS server only for the = data channel but not for the signal channel. I don't think signal-channel r= equires call home functionality, what is the use case ? -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 3:49 PM To: Jon Shallow >; Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: Call home in the signal channel (was RE: [Dots] draft-ietf-dots-da= ta-channel: Filter Direction) Hi Jon, I'm changing the title to keep track of signal-channel specific issues. Please use this one to discuss this use case. Thank you. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 16 f=E9vrier 2018 10:57 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org= Objet : RE: [Dots] draft-ietf-dots-data-channel: Filter Direction I understand the concept of call home - which makes good sense to me and rf= c8071 will, if implemented, handle the data channel and "destination" is st= ill where the 'controlled' traffic is flowing to. However, we also need call home in the signal channel. I'm not sure how th= is will be done - do we need a new CoAP Method (e.g. switch roles) - do we = need to define a different port (rfc8071 defines 4336) etc. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 16 February 2018 09:07 To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 2:19 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: draft-ietf-dots-data-channel: Filter Direction Re-, Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 16 f=E9vrier 2018 09:28 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] draft-ietf-dots-data-channel: Filter Direction There is no ambiguity in the roles. The CPE is acting as DOTS server but th= e DOTS server is initiating connection to the DOTS client in the access net= work. [Med] Don't get the last part. The server (CPE) will receive a request from= the network (client) to filter traffic exiting from that CPE. [TR] I mean to use the call home feature discussed in https://tools.ietf.or= g/html/rfc8071, though the CPE is acting as a DOTS server it will initiate = the connection (TLS or DTLS) to the DOTS client in the access network. The = call home feature helps avoid various threats like the DOTS server in the C= PE will not be subjected to DDoS attacks, and reachability is not problem e= ven if the CPE is behind NAT. The DOTS client will convey the black-list filtering in the "out" direction= to block the traffic originating from the DOTS server domain. [Med] Which corresponds to the "DOTS Server to DOTS Client" direction; that= is the DOTS client domain (access network) is the destination. All is fine= so far :) [TR] The direction is "outgoing traffic" whereas for other use cases the di= rection is "incoming traffic". I don't understand what you mean by a "optional" parameter ? [Med] I meant adding a parameter to indicate explicitly the direction. It w= ould be optional because we do already have a default direction. [TR] Okay. -Tiru -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Friday, February 16, 2018 1:24 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction Hi Tiru, There will be an ambiguity in interpreting filters if and only if the same = DOTS agents have to manipulate filters in both directions. As you rightfully mentioned, the bb use case assumes the following: In order to achieve this capability, the telemetry analysis system utilized by the broadband access provider must have DOTS client functionality, and the end-customer CPE devices must have DOTS server functionality. Which means that there is no ambiguity in that case with the current defaul= t direction: "the destination is the DOTS client domain". No matter how roles were negotiated, but as far as each an agent acts as a = client and its peer as a server, things are clear. Of course we can always define an optional parameter for this, but it is pr= eferable to have a case for it. Cheers, Med De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] Envoy=E9 : jeudi 15 f=E9vrier 2018 16:31 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: draft-ietf-dots-data-channel: Filter Direction The filtering rule for outgoing traffic is required for the "Suppression of= outbound DDoS traffic originating from a consumer broadband access network= " use case discussed in https://tools.ietf.org/html/draft-ietf-dots-use-cas= es-09#section-3.2.1. In this use case, the CPE initially acts as a DOTS cli= ent but after the TCP connection is established, reverses its role and acts= as DOTS server (see https://tools.ietf.org/html/rfc8071). The access netwo= rk can then program the CPE using the DOTS data channel to block the DDoS a= ttack traffic originated from the compromised devices in the local customer network. Cheers, -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Wednesday, February 14, 2018 1:49 PM To: dots@ietf.org Subject: [Dots] draft-ietf-dots-data-channel: Filter Direction Hi all, As agreed during the interim, there are some issues that need fixes in the = data-channel spec. We would like to hear from the WG to know what to record= in the document. Issue description: Do we need to support explicit "direction" in filtering = rules ("in"/"out")? That is, do we allow a DOTS client to create filters fo= r both incoming and outgoing traffic? Below a proposal for discussion: - The current default direction is aligned with the nature of DDoS attac= ks targeted by DOTS: i.e. incoming. The DOTS client domain is assumed to be= the destination. No ambiguity so far with such default behavior. - There is no clear use case for the support of outgoing filtering handl= ing in the context of DOTS. - No text change is required to the draft. Any objection? Cheers, Med --_000_DM5PR16MB178877A652F156EE4F538869EACB0DM5PR16MB1788namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

&nbs= p;

 

From:<= /span> Jon Shallow [mailto:s= upjps-ietf@jpshallow.com]
Sent: Friday, February 16, 2018 7:10 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; mohamed.boucadair@orange.com; dots@ietf.org
Subject: RE: [Dots] Call home in the signal channel (was RE: draft-i= etf-dots-data-channel: Filter Direction)

 

Hi Tiru= ,

&n= bsp;

See inl= ine [Jon]

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 16 February 2018 13:13
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: Re: [Dots] Call home in the signal channel (was RE: draft-i= etf-dots-data-channel: Filter Direction)

 

Hi Jon,

&nbs= p;

Please se= e inline

&nbs= p;

From:<= /span> Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Friday, February 16, 2018 5:33 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; mohamed.boucadair@orange.co= m; dots@ietf.org
Subject: RE: [Dots] Call home in the signal channel (was RE: draft-i= etf-dots-data-channel: Filter Direction)

 

Hi Tiru= ,

&n= bsp;

The mor= e I think about it, “Call Home” support in either the data or s= ignal channel makes no real sense for https://tools.iet= f.org/html/draft-ietf-dots-use-cases-09#section-3.2.1 .  The CPE d= evices don’t need to trigger the DOTS clients to get mitigation in place as it will be the provider who works this out.<= o:p>

&nbs= p;

[TR] No, = the above use case helps the CPE isolate the compromised devices launching = DDoS attacks and protect other devices in the local network from getting in= fected.

[Jon] OK, so the CPE says to itself “No idea what is going on, b= ut something bad is happening”, so I will call home to the provider f= or them to work out what is going on and get them to tell me what to do by sending me some ACLs.

[Jon] Did I understand this correctly?

&nbs= p;

[TR2] No,= the CPE may not even know if something bad is happening in its network. Th= e CPE proactively initiates and establishes TLS session with the provider, = and simply waits for requests from the provider to tell if there is something wrong (It’s a long-lived sess= ion). Similar technique is also used to manage secure home gateways from cl= oud managment.

&nbs= p;

However, = for 3.2.1, the DOTS client will need to make a mitigation request to initia= te the implementing of (previously defined) ACLs using the signal channel a= s there will be a high possibility of the outbound pipe running full.

&nbs= p;

[TR] ACL = can be enforced  with “activation” type set to “imme= diate” using the DOTS data channel itself.

[Jon] Agreed this can be done, but (TCP) will fail if the outgoing pip= e is full and so the ACL cannot be put in place.  A signal “miti= gate to this target prefix” will get through though and so kill off some of the traffic going out to the Internet going to the= target prefix.

&nbs= p;

[TR2] My = understanding is Mirai attacks do not choke the outgoing link in the local = network, otherwise the home admin can easily detect the bandwidth hogging d= evices, rate-limit the traffic/turn-off the devices. The goal is to attack a target in some external domain but at= the same-time not to disrupt local services to avoid any remediation.

&nbs= p;

-Tiru

 

-Jon

&nbs= p;

-Tiru

&nbs= p;

Regards

&nbs= p;

Jon

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 16 February 2018 11:00
To: mohamed.boucadai= r@orange.com; Jon Shallow; dots@ietf.org
Subject: Re: [Dots] Call home in the signal channel (was RE: draft-i= etf-dots-data-channel: Filter Direction)

 

For the discussed use case https://tools.ietf.or= g/html/draft-ietf-dots-use-cases-09#section-3.2.1, the CPE needs to act as a DOTS server only for the data channel but not fo= r the signal channel. I don’t think signa= l-channel requires call home functionality, what is the use case ?

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Friday, February 16, 2018 3:49 PM
To: Jon Shallow <sup= jps-ietf@jpshallow.com>; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org
Subject: Call home in the signal channel (was RE: [Dots] draft-ietf-= dots-data-channel: Filter Direction)

 

Hi Jon,

 

I’m changing the title to keep track of = signal-channel specific issues.

 

Please use this one to discuss this use case.<= o:p>

 

Thank you.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : vendredi 16 f=E9vrier 2018 10:57
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; <= a href=3D"mailto:dots@ietf.org"> dots@ietf.org
Objet : RE: [Dots] draft-ietf-dots-data-channel: Filter Directi= on

 

I under= stand the concept of call home – which makes good sense to me and rfc= 8071 will, if implemented, handle the data channel and “destination&#= 8221; is still where the ‘controlled’ traffic is flowing to.

&n= bsp;

However= , we also need call home in the signal channel.  I’m not sure ho= w this will be done – do we need a new CoAP Method (e.g. switch roles= ) – do we need to define a different port (rfc8071 defines 4336) etc.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 16 February 2018 09:07
To: mohamed.boucadai= r@orange.com; dots@ietf.org
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction

 

From:<= /span> mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Friday, February 16, 2018 2:19 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: RE: draft-ietf-dots-data-channel: Filter Direction

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : vendredi 16 f=E9vrier 2018 09:28
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : Re: [Dots] draft-ietf-dots-data-channel: Filter Directi= on

 

There is = no ambiguity in the roles. The CPE is acting as DOTS server but the DOTS se= rver is initiating connection to the DOTS client in the access network.

[Med] Don’t g= et the last part. The server (CPE) will receive a request from the network = (client) to filter traffic exiting from that CPE.

&nbs= p;

[TR] I me= an to use the call home feature discussed in https://tools.ietf.org/html= /rfc8071, though the CPE is acting as a DOTS server it will initiate th= e connection (TLS or DTLS) to the DOTS client in the access network. The ca= ll home feature helps avoid various threats like the DOTS server in the CPE will not be subjected to DDoS atta= cks, and reachability is not problem even if the CPE is behind NAT.

 

The DOTS = client will convey the black-list filtering in the “out” direct= ion to block the traffic originating from the DOTS server domain.

[Med] Which corresp= onds to the “DOTS Server to DOTS Client” direction; that is the= DOTS client domain (access network) is the destination. All is fine so far :)

&nbs= p;

&nbs= p;

[TR] The = direction is “outgoing traffic” whereas for other use cases the= direction is “incoming traffic”.

 

I donR= 17;t understand what you mean by a “optional” parameter ?<= /o:p>

[Med] I meant addin= g a parameter to indicate explicitly the direction. It would be optional be= cause we do already have a default direction.

&nbs= p;

[TR] Okay= .

&nbs= p;

-Tiru

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed= .boucadair@orange.com
Sent: Friday, February 16, 2018 1:24 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction

 

Hi Tiru,

 

There will be an ambiguity in interpreting fil= ters if and only if the same DOTS agents have to manipulate filters in both= directions.

 

As you rightfully mentioned, the bb use case a= ssumes the following:

 

   In order to achieve t= his capability, the telemetry analysis system

   utilized by the broad= band access provider must have DOTS client

   functionality, and th= e end-customer CPE devices must have DOTS server

   functionality.

 

Which means that there is no ambiguity in that= case with the current default direction: “the destination is the DOT= S client domain”.

 

No matter how roles were negotiated, but=
 as far as each an agent acts as a client and its peer as a server, things =
are clear. 
 
Of course we can always define an option=
al parameter for this, but it is preferable to have a case for it.  
 
Cheers,
Med

 

De : Konda, Tirumaleswar Reddy [mailto:Tirumaleswar= Reddy_Konda@McAfee.com]
Envoy=E9 : jeudi 15 f=E9vrier 2018 16:31
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: draft-ietf-dots-data-channel: Filter Direction=

 

The filte= ring rule for outgoing traffic is required for the "Suppression of out= bound DDoS traffic originating from a consumer broadband access network&quo= t; use case discussed in https://tools.ietf.org/html/draft-ietf-dots-use-cases-09#section-3.2.1.= In this use case, the CPE initially acts as a DOTS client but after the TC= P connection is established, reverses its role and acts as DOTS server (see https://tools.ietf.org/html= /rfc8071). The access network can then program the CPE using the DOTS d= ata channel to block the DDoS attack traffic originated from the compromise= d devices in the

local cus= tomer network.

&nbs= p;

Cheers,

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed= .boucadair@orange.com
Sent: Wednesday, February 14, 2018 1:49 PM
To: dots@ietf.org
Subject: [Dots] draft-ietf-dots-data-channel: Filter Direction<= /o:p>

 

Hi all,

 

As agreed during the interim, there are some issues that n= eed fixes in the data-channel spec. We would like to hear from the WG to kn= ow what to record in the document.

 

Issue description: Do we need to support explicit “d= irection” in filtering rules (“in”/“out”)? Th= at is, do we allow a DOTS client to create filters for both incoming and ou= tgoing traffic?

 

Below a proposal for discussion:

– = ;   The current default direction is aligned with the nature of DDoS attacks t= argeted by DOTS: i.e. incoming. The DOTS client domain is assumed to be the= destination. No ambiguity so far with such default behavior.

– = ;   There is no clear use case for the support of outgoing filtering handling = in the context of DOTS.

– = ;   No text change is required to the draft.

 <= /p>

Any objection?

 <= /p>

Cheers,=

Med

 

--_000_DM5PR16MB178877A652F156EE4F538869EACB0DM5PR16MB1788namp_-- From nobody Fri Feb 16 06:33:38 2018 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 C37E31241F5 for ; Fri, 16 Feb 2018 06:33:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 Jq0KhVgzBqnf for ; Fri, 16 Feb 2018 06:33:34 -0800 (PST) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32D35120047 for ; Fri, 16 Feb 2018 06:33:34 -0800 (PST) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id BE4E861427; Fri, 16 Feb 2018 15:33:32 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.61]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 994AC180077; Fri, 16 Feb 2018 15:33:32 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7E.corporate.adroot.infra.ftgroup ([fe80::b91c:ea2c:ac8a:7462%19]) with mapi id 14.03.0382.000; Fri, 16 Feb 2018 15:33:32 +0100 From: To: "Konda, Tirumaleswar Reddy" , "Jon Shallow" , "dots@ietf.org" Thread-Topic: [Dots] draft-ietf-dots-data-channel: Filtering Fields Thread-Index: AdOlbICGgF2MxoHnQied7J+cvW2QAABhQcigAAKnFWAAAuyKQAAGTI4AAAEahwAAASoGAAAAJ8mAAAB6+CAAAZF/MA== Date: Fri, 16 Feb 2018 14:33:31 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0D3847@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300A0D1F93@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0D32AE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00e801d3a721$08806d30$19814790$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0D366E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019201d3a72a$1b103b70$5130b250$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0D372A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A0D3847OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields 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, 16 Feb 2018 14:33:38 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A0D3847OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, Here is a tentative list: Header Mandatory Fields ------ -------------------------------------------------------------- IPv4 protocol, source-port-range-or-operator, destination-port- range-or-operator, destination-ipv4-network, source- ipv4-network, and v4-fragments IPv6 protocol, source-port-range-or-operator, destination-port- range-or-operator, destination-ipv4-network, source- ipv4-network,and v6-fragments TCP flags ICMP type and code Please comment/update. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 16 f=E9vrier 2018 14:55 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields +1. In TCP, only "flags" field looks mandatory. -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 7:03 PM To: Jon Shallow >; Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields Re-, I tend to agree with you to have to define a minimum set of mandatory match= fields. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 16 f=E9vrier 2018 14:29 =C0 : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; dots@ietf.org Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields Hi Med, See inline [Jon] Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 16 February 2018 12:56 To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields Jon, Thank you for sharing your thoughts. Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 16 f=E9vrier 2018 13:24 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org= Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields I like the concept of "+--ro capabilities" allowing for future support as t= he DOS server becomes more mature in its capabilities. If a DOTS client includes a filtering field parameter that is not currently= supported, should the parameter be ignored (and not returned for a GET), o= r the request rejected? [Med] I would vote for rejecting the request. The client should only use ma= tch criteria that are understood by the server; otherwise there will be dif= ferent expectation from the service. [Jon] I think that this is my preference - I was just seeking clarity of th= inking. It is conceivable that a DOTS client has 2 DOTS servers (one possibly a bac= kup, or 2 different ISPs), which may have differing filtering field paramet= er support capabilities. [Med] The backup/case seems odd. I would expect a feature parity for a redu= ndancy group used to provide the same service. [Jon] Agreed that a backup server is most likely to be from the same manufa= cturer and hence support the same functionality. But one may have just bee= n upgraded to have extra support. Adding in intelligence code to work out what is / is not allowed may not = be practical in a (memory or cpu) constrained environment of the DOTS clien= t. [Med] Fair. That said, I think we need to define the minimum set of supported parameter= s - e.g. protocol, source / dest ports, source / dest IPv4 prefixes, sourc= e / dest IPv6 prefixes, fragments and icmp type/code. [Jon] Any comments? -Jon Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 16 February 2018 10:18 To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields Hi Med, Please see inline [TR2] From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 1:45 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: draft-ietf-dots-data-channel: Filtering Fields Re-, Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 16 f=E9vrier 2018 08:00 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Wednesday, February 14, 2018 1:49 PM To: dots@ietf.org Subject: [Dots] draft-ietf-dots-data-channel: Filtering Fields Hi all, As agreed during the interim, there are some issues that need fixes in the = data-channel spec. We would like to hear from the WG to know what to record= in the document. Issue description: Should we support all of the match fields defined by "ie= tf-packet-fields" or do we need to define a minimum supported set? [TR] I don't see the need to support all the match fields, define a minimum= supported set (don't see the use for acl-eth-header-fields for DOTS use ca= ses). [Med] Agree that acl-eth-header-fields aren't required. The text is already= clear about this: DOTS implementations MUST support the following matching criteria: match based on the IP header (IPv4 and IPv6), match based on the transport header (TCP, UDP, and ICMP), and any combination thereof. The question is whether we need to go further and mandate (or not) the supp= ort of matching based on specific fields: dscp, ecn, ttl,... flow-label, ..= . tcp sequence-number, tcp flags, ... [TR2] https://tools.ietf.org/html/draft-ietf-netmod-acl-model-16 uses the f= eature statements in the YANG model allowing vendors to advertise match rul= es they are capable and willing to support but not at the field-level. The = problem is router implementations today don't support ACLs with tcp sequenc= e-number, acknowledgement-number, window-size etc but support TCP flags. If= the server could convey the list of match criteria supported, it not only = allows the client to convey the supported match rules but also allows the s= erver in future to advertise the new supported match fields. Would it be useful for a client to retrieve the list of match criteria supp= orted by a DOTS server? [TR2] Yes. -Tiru [TR] The YANG model supported by the DOTS server can retrieved by the DOTS = client using RESTCONF to determine the match criteria supported by the serv= er. [Med] I'm afraid this is not the same functionality. If we need to allow a = server to return its supported match criteria, this should be allowed by th= e module. For example, the module may include the following (example): +--ro capabilities | +--ro match-header* | | identityref | +--ro transport-protocols* [protocol-id] | | +--ro protocol-id uint8 | | +--ro protocol-name? string | +--ro dscp-support? boolean | +--ro ecn-support? boolean | +--ro length-support? boolean | +--ro ttl-support? boolean | +--ro protocol-support? boolean The client can ask the server to return its supported match criteria. The s= erver will indicate the exact set of fields it supports. I'm not expressing a preference to have this in the model, but I'm clarifyi= ng how it would look like. -Tiru Please comment. Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300A0D3847OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

Here is a tentative list:

 

   Header= Mandatory Fields

   ------= --------------------------------------------------------------<= /span>

   IPv4&n= bsp;  protocol, source-port-range-or-operator, destination-port-<= /o:p>

   &= nbsp;      range-or-operator, destination-ipv4-net= work, source-

   &= nbsp;      ipv4-network, and v4-fragments

   IPv6&n= bsp;  protocol, source-port-range-or-operator, destination-port-<= /o:p>

   &= nbsp;      range-or-operator, destination-ipv4-net= work, source-

   &= nbsp;      ipv4-network,and v6-fragments

   TCP&nb= sp;   flags

   ICMP   type and code

 

Please comment/update.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.= org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : vendredi 16 f=E9vrier 2018 14:55
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fiel= ds

 

+1. In TCP, only “flags” field looks mandatory.

 

-Tiru

 

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Friday, February 16, 2018 7:03 PM
To: Jon Shallow <sup= jps-ietf@jpshallow.com>; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org
Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields

 

Re-,

 

I tend to agree with you to hav= e to define a minimum set of mandatory match fields.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : vendredi 16 f=E9vrier 2018 14:29
=C0 : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; dots@ietf.org
Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fiel= ds

 

Hi Med,=

&n= bsp;

See inl= ine [Jon]

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 16 February 2018 12:56
To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields

 

Jon,

 

Thank you for sharing your thou= ghts.

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : vendredi 16 f=E9vrier 2018 13:24
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; <= a href=3D"mailto:dots@ietf.org"> dots@ietf.org
Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fiel= ds

 

I like the concept of “+--ro capabilities“ allowing for futu=
re support as the DOS server becomes more mature in its capabilities.<=
/o:p>
 
If a DOTS client includes a filtering field parameter that =
is not currently supported, should the parameter be ignored (and not return=
ed for a GET), or the request rejected?
[Med] I would vote for re=
jecting the request. The client should only use match criteria that are und=
erstood by the server; otherwise there will be different expectation from t=
he service. 
[Jon] I think that this is my preference – I was just=
 seeking clarity of thinking.
<=
o:p> 
It is conceivable that a DOTS client has 2 DOTS servers (on=
e possibly a backup, or 2 different ISPs), which may have differing filteri=
ng field parameter support capabilities.
[Med] The backup/case see=
ms odd. I would expect a feature parity for a redundancy group used to prov=
ide the same service.=

[=
Jon] Agreed that a backup server is most likely to be from the same manufac=
turer and hence support the same functionality.  But one may have just=
 been upgraded to have extra support.
<=
o:p> 
 <=
/pre>

 <=
/pre>

  Adding in intelligence code to work out what is / is=
 not allowed may not be practical in a (memory or cpu) constrained environm=
ent of the DOTS client.


[Med] Fair. 


 


That said, I think we need to define the minimum set of sup=
ported parameters – e.g. protocol, source / dest ports,  source =
/ dest IPv4 prefixes, source / dest IPv6 prefixes, fragments and icmp type/=
code. 


[Jon] Any comments?


<=
o:p> 


-=
Jon


<=
o:p> 


Regards


 


Jon


&n=
bsp;






From:=
 Dots [mailto:
dots-bounces@ietf.org] On B=
ehalf Of
Konda, Tirumaleswar Reddy

Sent: 16 February 2018 10:18

To: mohamed.boucadai=
r@orange.com;
dots@ietf.org

Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields






 


Hi Med,


 


Please see inline [TR2]


 








From:
mohamed.boucadair@orange.co=
m [mailto:mohamed.bouca=
dair@orange.com]


Sent: Friday, February 16, 2018 1:45 PM

To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>;
dots@ietf.org

Subject: RE: draft-ietf-dots-data-channel: Filtering Fields






 


Re-,


 


Please see inline.



 


Cheers,


Med


 








De : Dots [mailto:dots-bounces@ietf.org]
De la part de Konda, Tirumaleswar Reddy

Envoy=E9 : vendredi 16 f=E9vrier 2018 08:00

=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org

Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fiel=
ds






 


From: Dots [mailto:dots-bounces=
@ietf.org]
On Behalf Of mohamed=
.boucadair@orange.com

Sent: Wednesday, February 14, 2018 1:49 PM

To: dots@ietf.org

Subject: [Dots] draft-ietf-dots-data-channel: Filtering Fields<=
/o:p>


 


Hi all,



 


As agreed during the interim, there are som=
e issues that need fixes in the data-channel spec. We would like to hear fr=
om the WG to know what to record in the document.



 


Issue description: Should we support all of=
 the match fields defined by “ietf-packet-fields” or do we need=
 to define a minimum supported set?



 


[TR] I don’t see the need=
 to support all the match fields, define a minimum supported set (don’=
;t see the use for acl-eth-header-fields for DOTS use cases).  


[Med] Agree that acl-eth-header=
-fields aren’t required. The text is already clear about this:


 


DOTS implementation=
s MUST support the following


   matchi=
ng criteria: match based on the IP header (IPv4 and IPv6),


   match =
based on the transport header (TCP, UDP, and ICMP), and any


  
combination thereof.


 


The question is whether w=
e need to go further and mandate (or not) the support of matching based on =
specific fields: dscp, ecn, ttl,… flow-label, … tcp sequence-number, tcp flags, …  


 


[TR2] https=
://tools.ietf.org/html/draft-ietf-netmod-acl-model-16 uses the feature statem=
ents in the YANG model allowing vendors to advertise match rules they are c=
apable and willing to support but not at the field-level. The problem is ro=
uter implementations today don’t support ACLs with tcp sequence-numbe=
r, acknowledgement-number, window-size etc but support TCP flags. If the se=
rver could convey the list of match criteria supported, it not only allows =
the client to convey the supported match rules but also allows the server i=
n future to advertise the new supported match fields.   


 


Would it be useful for a client to retrieve=
 the list of match criteria supported by a DOTS server?



 


[TR2] Yes. 

 


-Tiru


 


[TR] The YANG model supported b=
y the DOTS server can retrieved by the DOTS client using RESTCONF to determ=
ine the match criteria supported by the server.



[Med] I’m afraid this is =
not the same functionality. If we need to allow a server to return its supp=
orted match criteria, this should be allowed by the module.
 For example, the module may include the following (example): 


 


      &=
nbsp;         +--ro capabilitie=
s


      &=
nbsp;         |  +--ro mat=
ch-header*


      &=
nbsp;         |  |  =
     identityref


      &=
nbsp;         |  +--ro tra=
nsport-protocols* [protocol-id]


      &=
nbsp;         |  |  +=
--ro protocol-id      uint8

      &=
nbsp;         |  |  +=
--ro protocol-name?   string


      &=
nbsp;         |  +--ro dsc=
p-support?       boolean

      &=
nbsp;         |  +--ro ecn=
-support?        boolean


      &=
nbsp;         |  +--ro len=
gth-support?     boolean


      &=
nbsp;         |  +--ro ttl=
-support?        boolean


      &=
nbsp;         |  +--ro pro=
tocol-support?   boolean


 


The client can ask the server to retu=
rn its supported match criteria. The server wil=
l indicate the exact set of fields it supports. 

 <=
/pre>

I’m not expressing =
a preference to have this in the model, but I’m clarifying how it wou=
ld look like. 

 


-Tiru


 


Please com=
ment.



 =
;


Cheers,


Med=
<=
/o:p>
--_000_787AE7BB302AE849A7480A190F8B93300A0D3847OPEXCLILMA3corp_-- From nobody Fri Feb 16 07:20:12 2018 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 A39CA124BFA for ; Fri, 16 Feb 2018 07:20:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 pSGGnhI8JM90 for ; Fri, 16 Feb 2018 07:20:07 -0800 (PST) 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 02A28120454 for ; Fri, 16 Feb 2018 07:20:07 -0800 (PST) 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 1emhnw-0000xN-4z; Fri, 16 Feb 2018 15:20:04 +0000 From: "Jon Shallow" To: , "Konda, Tirumaleswar Reddy" , References: <787AE7BB302AE849A7480A190F8B93300A0D1F93@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0D32AE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00e801d3a721$08806d30$19814790$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0D366E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019201d3a72a$1b103b70$5130b250$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0D372A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0D3847@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A0D3847@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Fri, 16 Feb 2018 15:20:05 -0000 Message-ID: <020a01d3a739$9fd9ec70$df8dc550$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_020B_01D3A739.9FDEA760" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLoxvz0kGpX/tRyz6XeuCXxpheRlwMZabEuApwt0GoCITdLGgK2/q2yAt/zojQB0mpcSAMW+5mCAaQFvl8BTSXY9KDSn0CQ Content-Language: en-gb Archived-At: Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields 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, 16 Feb 2018 15:20:11 -0000 This is a multipart message in MIME format. ------=_NextPart_000_020B_01D3A739.9FDEA760 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Med, =20 I agree with the list (and am likely to only implement those!). =20 As I see it, there are 2 possible ways forward here =20 1) We add in an Boolean =91supported=92 capability for the list of = all the other options in packet-fields:acl-xxx 2) We drop the use of =93uses packet-fields:acl-xxx=94 and define = our own required entries, exactly modelled on draft-ietf-netmod-acl-model-16 definitions. =20 Comments? =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 16 February 2018 14:34 To: Konda, Tirumaleswar Reddy; Jon Shallow; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields =20 Re-, =20 Here is a tentative list:=20 =20 Header Mandatory Fields ------ -------------------------------------------------------------- IPv4 protocol, source-port-range-or-operator, destination-port- range-or-operator, destination-ipv4-network, source- ipv4-network, and v4-fragments IPv6 protocol, source-port-range-or-operator, destination-port- range-or-operator, destination-ipv4-network, source- ipv4-network,and v6-fragments TCP flags ICMP type and code =20 Please comment/update.=20 =20 Cheers, Med =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, = Tirumaleswar Reddy Envoy=E9 : vendredi 16 f=E9vrier 2018 14:55 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields =20 +1. In TCP, only =93flags=94 field looks mandatory.=20 =20 -Tiru =20 From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] = Sent: Friday, February 16, 2018 7:03 PM To: Jon Shallow ; Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields =20 Re-, =20 I tend to agree with you to have to define a minimum set of mandatory = match fields.=20 =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : vendredi 16 f=E9vrier 2018 14:29 =C0 : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; = dots@ietf.org Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields =20 Hi Med, =20 See inline [Jon] =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 16 February 2018 12:56 To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields =20 Jon, =20 Thank you for sharing your thoughts.=20 =20 Please see inline. =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : vendredi 16 f=E9vrier 2018 13:24 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; = dots@ietf.org Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields =20 I like the concept of =93+--ro capabilities=93 allowing for future = support as the DOS server becomes more mature in its capabilities. =20 If a DOTS client includes a filtering field parameter that is not = currently supported, should the parameter be ignored (and not returned for a GET), = or the request rejected? [Med] I would vote for rejecting the request. The client should only use match criteria that are understood by the server; otherwise there will = be different expectation from the service.=20 [Jon] I think that this is my preference =96 I was just seeking clarity = of thinking. =20 It is conceivable that a DOTS client has 2 DOTS servers (one possibly a backup, or 2 different ISPs), which may have differing filtering field parameter support capabilities. [Med] The backup/case seems odd. I would expect a feature parity for a redundancy group used to provide the same service. [Jon] Agreed that a backup server is most likely to be from the same manufacturer and hence support the same functionality. But one may have just been upgraded to have extra support. =20 =20 =20 Adding in intelligence code to work out what is / is not allowed may = not be practical in a (memory or cpu) constrained environment of the DOTS client. [Med] Fair.=20 =20 That said, I think we need to define the minimum set of supported = parameters =96 e.g. protocol, source / dest ports, source / dest IPv4 prefixes, = source / dest IPv6 prefixes, fragments and icmp type/code.=20 [Jon] Any comments? =20 -Jon =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 16 February 2018 10:18 To: mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields =20 Hi Med, =20 Please see inline [TR2] =20 From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] = Sent: Friday, February 16, 2018 1:45 PM To: Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: RE: draft-ietf-dots-data-channel: Filtering Fields =20 Re-, =20 Please see inline.=20 =20 Cheers, Med =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, = Tirumaleswar Reddy Envoy=E9 : vendredi 16 f=E9vrier 2018 08:00 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields =20 From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: Wednesday, February 14, 2018 1:49 PM To: dots@ietf.org Subject: [Dots] draft-ietf-dots-data-channel: Filtering Fields =20 Hi all,=20 =20 As agreed during the interim, there are some issues that need fixes in = the data-channel spec. We would like to hear from the WG to know what to = record in the document.=20 =20 Issue description: Should we support all of the match fields defined by =93ietf-packet-fields=94 or do we need to define a minimum supported = set?=20 =20 [TR] I don=92t see the need to support all the match fields, define a = minimum supported set (don=92t see the use for acl-eth-header-fields for DOTS = use cases). =20 [Med] Agree that acl-eth-header-fields aren=92t required. The text is = already clear about this: =20 DOTS implementations MUST support the following matching criteria: match based on the IP header (IPv4 and IPv6), match based on the transport header (TCP, UDP, and ICMP), and any combination thereof. =20 The question is whether we need to go further and mandate (or not) the support of matching based on specific fields: dscp, ecn, ttl,=85 = flow-label, =85 tcp sequence-number, tcp flags, =85 =20 =20 [TR2] https://tools.ietf.org/html/draft-ietf-netmod-acl-model-16 uses the = feature statements in the YANG model allowing vendors to advertise match rules = they are capable and willing to support but not at the field-level. The = problem is router implementations today don=92t support ACLs with tcp = sequence-number, acknowledgement-number, window-size etc but support TCP flags. If the = server could convey the list of match criteria supported, it not only allows = the client to convey the supported match rules but also allows the server in future to advertise the new supported match fields. =20 =20 Would it be useful for a client to retrieve the list of match criteria supported by a DOTS server?=20 =20 [TR2] Yes.=20 =20 -Tiru =20 [TR] The YANG model supported by the DOTS server can retrieved by the = DOTS client using RESTCONF to determine the match criteria supported by the server.=20 [Med] I=92m afraid this is not the same functionality. If we need to = allow a server to return its supported match criteria, this should be allowed by = the module. For example, the module may include the following (example):=20 =20 +--ro capabilities | +--ro match-header* | | identityref | +--ro transport-protocols* [protocol-id] | | +--ro protocol-id uint8 | | +--ro protocol-name? string | +--ro dscp-support? boolean | +--ro ecn-support? boolean | +--ro length-support? boolean | +--ro ttl-support? boolean | +--ro protocol-support? boolean =20 The client can ask the server to return its supported match criteria. = The server will indicate the exact set of fields it supports.=20 =20 I=92m not expressing a preference to have this in the model, but I=92m clarifying how it would look like.=20 =20 -Tiru =20 Please comment.=20 =20 Cheers, Med ------=_NextPart_000_020B_01D3A739.9FDEA760 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Med,

 

I agree with the list = (and am likely to only implement those!).

 

As I see it, there are 2 = possible ways forward here

 

1)      = We add in = an Boolean ‘supported’ capability for the list of all the = other options in packet-fields:acl-xxx

2)      = We drop the = use of “uses packet-fields:acl-xxx” and define our own = required entries, exactly modelled on draft-ietf-netmod-acl-model-16 = definitions.

 

Comments?

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com
Sent: 16 February 2018 = 14:34
To: Konda, Tirumaleswar Reddy; Jon Shallow; = dots@ietf.org
Subject: Re: [Dots] = draft-ietf-dots-data-channel: Filtering = Fields

 

Re-,

 

Here is a tentative list:

 

   Header Mandatory = Fields

   ------ = --------------------------------------------------------------=

   IPv4   protocol, = source-port-range-or-operator, destination-port-

       &= nbsp;  range-or-operator, destination-ipv4-network, = source-

        =   ipv4-network, and v4-fragments

   IPv6   protocol, = source-port-range-or-operator, destination-port-

       &= nbsp;  range-or-operator, destination-ipv4-network, = source-

       &= nbsp;  ipv4-network,and v6-fragments

   TCP    = flags

   ICMP   type and = code

 

Please comment/update. =

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] = De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : = vendredi 16 f=E9vrier 2018 14:55
=C0 : BOUCADAIR Mohamed = IMT/OLN; Jon Shallow; dots@ietf.org
Objet : = Re: [Dots] draft-ietf-dots-data-channel: Filtering = Fields

 

+1. In TCP, only = “flags” field looks mandatory.

 

-Tiru

 

From: mohamed.boucadair@orange.com= [mailto:mohamed.boucadair@ora= nge.com]
Sent: Friday, February 16, 2018 7:03 = PM
To: Jon Shallow <supjps-ietf@jpshallow.com&g= t;; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; dots@ietf.org
Subject: RE: = [Dots] draft-ietf-dots-data-channel: Filtering = Fields

 

Re-,

 

I tend to agree with you to have to define a minimum = set of mandatory match fields.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Envoy=E9 : vendredi 16 f=E9vrier 2018 = 14:29
=C0 : BOUCADAIR Mohamed IMT/OLN; Konda, = Tirumaleswar Reddy; dots@ietf.org
Objet : = RE: [Dots] draft-ietf-dots-data-channel: Filtering = Fields

 

Hi Med,

 

See inline = [Jon]

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of mohamed.boucadair@orange.com=
Sent: 16 February 2018 12:56
To: Jon Shallow; = 'Konda, Tirumaleswar Reddy'; dots@ietf.org
Subject: Re: = [Dots] draft-ietf-dots-data-channel: Filtering = Fields

 

Jon,

 

Thank you for sharing your thoughts. =

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Envoy=E9 : vendredi 16 f=E9vrier 2018 = 13:24
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR = Mohamed IMT/OLN; dots@ietf.org
Objet : = RE: [Dots] draft-ietf-dots-data-channel: Filtering = Fields

 

I like =
the concept of “+--ro capabilities“ =
allowing for future support as the DOS server becomes more mature in its =
capabilities.
&nb=
sp;
If a =
DOTS client includes a filtering field parameter that is not currently =
supported, should the parameter be ignored (and not returned for a GET), =
or the request rejected?
[Med] I would vote for =
rejecting the request. The client should only use match criteria that =
are understood by the server; otherwise there will be different =
expectation from the service. 
[Jon] I =
think that this is my preference – I was just seeking clarity of =
thinking.
 <=
/pre>
It is =
conceivable that a DOTS client has 2 DOTS servers (one possibly a =
backup, or 2 different ISPs), which may have differing filtering field =
parameter support capabilities.
[Med] The backup/case seems =
odd. I would expect a feature parity for a redundancy group used to =
provide the same service.
=
[Jon] Agreed that =
a backup server is most likely to be from the same manufacturer and =
hence support the same functionality.  But one may have just been =
upgraded to have extra support.
 <=
/pre>
 
<=
pre> 
<=
pre>  =
Adding in intelligence code to work out what is / is not allowed may not =
be practical in a (memory or cpu) constrained environment of the DOTS =
client.
[Med] Fair. =

&nb=
sp;
That =
said, I think we need to define the minimum set of supported parameters =
– e.g. protocol, source / dest ports,  source / dest IPv4 =
prefixes, source / dest IPv6 prefixes, fragments and icmp type/code. =

[Jon] =
Any comments?
 <=
/pre>
-Jon
 <=
/pre>
Regards<=
o:p>
&nb=
sp;
Jon
 
From: Dots [mailto: dots-bounces@ietf.org] On =
Behalf Of Konda, Tirumaleswar Reddy
Sent: 16 February 2018 =
10:18
To: mohamed.boucadair@orange.com=
; dots@ietf.org
Subject: Re: =
[Dots] draft-ietf-dots-data-channel: Filtering =
Fields
 
Hi =
Med,
 
Please see inline =
[TR2]
 
From: mohamed.boucadair@orange.com=
 [mailto:mohamed.boucadair@ora=
nge.com] 
Sent: Friday, February 16, 2018 1:45 =
PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond=
a@McAfee.com>; dots@ietf.org
Subject: RE: =
draft-ietf-dots-data-channel: Filtering =
Fields
 
Re-,
 
Please see inline. 
 
Cheers,
Med
 
De : Dots [mailto:dots-bounces@ietf.org] =
De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : =
vendredi 16 f=E9vrier 2018 08:00
=C0 : BOUCADAIR Mohamed =
IMT/OLN; dots@ietf.org
Objet : =
Re: [Dots] draft-ietf-dots-data-channel: Filtering =
Fields
 
From: Dots [mailto:dots-bounces@ietf.org] =
On Behalf Of mohamed.boucadair@orange.com=

Sent: Wednesday, February 14, 2018 1:49 PM
To: =
dots@ietf.org
Subject: =
[Dots] draft-ietf-dots-data-channel: Filtering =
Fields
 
Hi =
all, 
 
As =
agreed during the interim, there are some issues that need fixes in the =
data-channel spec. We would like to hear from the WG to know what to =
record in the document. 
 
Issue =
description: Should we support all of the match fields defined by =
“ietf-packet-fields” or do we need to define a minimum =
supported set? 
 
[TR] I don’t see the need to support all the match =
fields, define a minimum supported set (don’t see the use for =
acl-eth-header-fields for DOTS use cases). =
 
[Med] =
Agree that acl-eth-header-fields aren’t required. The text is =
already clear about this:
 
DOTS implementations MUST support the =
following
   matching criteria: match =
based on the IP header (IPv4 and IPv6),
   match based on the transport =
header (TCP, UDP, and ICMP), and any
   combination =
thereof.
 
The question is whether we =
need to go further and mandate (or not) the support of matching based on =
specific fields: dscp, ecn, ttl,… flow-label, … tcp sequence-number, =
tcp flags, …  
 
[TR2] https://tools.ietf.org/html/draft-ietf-netmod-acl-model-16 uses the feature statements in the =
YANG model allowing vendors to advertise match rules they are capable =
and willing to support but not at the field-level. The problem is router =
implementations today don’t support ACLs with tcp sequence-number, =
acknowledgement-number, window-size etc but support TCP flags. If the =
server could convey the list of match criteria supported, it not only =
allows the client to convey the supported match rules but also allows =
the server in future to advertise the new supported match fields. =
  
 
Would =
it be useful for a client to retrieve the list of match criteria =
supported by a DOTS server? 
 
[TR2] Yes. 
 
-Tiru
 
[TR] The YANG model supported by =
the DOTS server can retrieved by the DOTS client using RESTCONF to =
determine the match criteria supported by the server. =

[Med] =
I’m afraid this is not the same functionality. If we need to allow =
a server to return its supported match criteria, this should be allowed =
by the module. For example, the module may include the following =
(example): 
 
       &=
nbsp;        +--ro =
capabilities
       &=
nbsp;        |  +--ro =
match-header*
       &=
nbsp;        |  =
|       =
identityref
       &=
nbsp;        |  +--ro =
transport-protocols* [protocol-id]
       &=
nbsp;        |  |  +--ro =
protocol-id      =
uint8
       &=
nbsp;        |  |  +--ro =
protocol-name?   string
       &=
nbsp;        |  +--ro =
dscp-support? =
      boolean
<=
span lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Courier =
New";mso-fareast-language:FR'>       &=
nbsp;        |  +--ro =
ecn-support? =
       boolean
=

       &=
nbsp;        |  +--ro =
length-support? =
    boolean
       &=
nbsp;        |  +--ro =
ttl-support? =
       boolean
=

       &=
nbsp;        |  +--ro =
protocol-support?   boolean
 
The client can ask the server to return =
its supported match criteria. The server =
will indicate the exact set of fields it supports. =

 
<=
pre>I’m not expressing a =
preference to have this in the model, but I’m clarifying how it =
would look like. 
 
-Tiru
 
Please comment. =

 
Cheers,
Med
------=_NextPart_000_020B_01D3A739.9FDEA760-- From nobody Fri Feb 16 07:30:18 2018 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 C1485120725 for ; Fri, 16 Feb 2018 07:30:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 O4XkIwca_as8 for ; Fri, 16 Feb 2018 07:30:13 -0800 (PST) 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 DABB3120454 for ; Fri, 16 Feb 2018 07:30:12 -0800 (PST) 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 1emhxj-0000xt-7Q; Fri, 16 Feb 2018 15:30:11 +0000 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , , References: <787AE7BB302AE849A7480A190F8B93300A0D3439@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00d201d3a71e$05ead590$11c080b0$@jpshallow.com> <01b401d3a72b$b5a79f10$20f6dd30$@jpshallow.com> In-Reply-To: Date: Fri, 16 Feb 2018 15:30:13 -0000 Message-ID: <022001d3a73b$09b1c270$1d154750$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0221_01D3A73B.09B67D60" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFhM5SgMTXVloJMPghbVDaqY+i+RwHzf0UPAcW31FQAkY4P0QGcxtUBAVABQVSkUkHcQA== Content-Language: en-gb Archived-At: Subject: Re: [Dots] Call home in the signal channel (was RE: draft-ietf-dots-data-channel: Filter Direction) 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, 16 Feb 2018 15:30:17 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0221_01D3A73B.09B67D60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Tiru, =20 See inline [Jon1]. =20 Regards =20 Jon =20 =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Friday, February 16, 2018 5:33 PM To: Konda, Tirumaleswar Reddy ; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] Call home in the signal channel (was RE: draft-ietf-dots-data-channel: Filter Direction) =20 Hi Tiru, =20 The more I think about it, =93Call Home=94 support in either the data or = signal channel makes no real sense for https://tools.ietf.org/html/draft-ietf-dots-use-cases-09#section-3.2.1 . The CPE devices don=92t need to trigger the DOTS clients to get = mitigation in place as it will be the provider who works this out. =20 [TR] No, the above use case helps the CPE isolate the compromised = devices launching DDoS attacks and protect other devices in the local network = from getting infected. [Jon] OK, so the CPE says to itself =93No idea what is going on, but = something bad is happening=94, so I will call home to the provider for them to = work out what is going on and get them to tell me what to do by sending me some = ACLs. [Jon] Did I understand this correctly? =20 [TR2] No, the CPE may not even know if something bad is happening in its network. The CPE proactively initiates and establishes TLS session with = the provider, and simply waits for requests from the provider to tell if = there is something wrong (It=92s a long-lived session). Similar technique is = also used to manage secure home gateways from cloud managment. [Jon1] OK =96 a way of registering/saying =93I=92m here if needed=94 =20 However, for 3.2.1, the DOTS client will need to make a mitigation = request to initiate the implementing of (previously defined) ACLs using the = signal channel as there will be a high possibility of the outbound pipe running full. =20 [TR] ACL can be enforced with =93activation=94 type set to = =93immediate=94 using the DOTS data channel itself.=20 [Jon] Agreed this can be done, but (TCP) will fail if the outgoing pipe = is full and so the ACL cannot be put in place. A signal =93mitigate to = this target prefix=94 will get through though and so kill off some of the = traffic going out to the Internet going to the target prefix. =20 [TR2] My understanding is Mirai attacks do not choke the outgoing link = in the local network, otherwise the home admin can easily detect the = bandwidth hogging devices, rate-limit the traffic/turn-off the devices. The goal = is to attack a target in some external domain but at the same-time not to = disrupt local services to avoid any remediation.=20 [Jon1] Fair comment. I still think there could be full pipe issues = (e.g. broken malware not smart enough to limit itself) that we need to think = about / be able to handle. =20 -Jon1 =20 -Tiru =20 -Jon =20 -Tiru =20 Regards =20 Jon From: Dots [mailto: dots-bounces@ietf.org ] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 16 February 2018 11:00 To: mohamed.boucadair@orange.com; Jon Shallow; dots@ietf.org Subject: Re: [Dots] Call home in the signal channel (was RE: draft-ietf-dots-data-channel: Filter Direction) =20 For the discussed use case https://tools.ietf.org/html/draft-ietf-dots-use-cases-09#section-3.2.1, = the CPE needs to act as a DOTS server only for the data channel but not for = the signal channel. I don=92t think signal-channel requires call home functionality, what is the use case ? =20 -Tiru =20 From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] = Sent: Friday, February 16, 2018 3:49 PM To: Jon Shallow ; Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: Call home in the signal channel (was RE: [Dots] draft-ietf-dots-data-channel: Filter Direction) =20 Hi Jon,=20 =20 I=92m changing the title to keep track of signal-channel specific = issues.=20 =20 Please use this one to discuss this use case. =20 Thank you.=20 =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : vendredi 16 f=E9vrier 2018 10:57 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; = dots@ietf.org Objet : RE: [Dots] draft-ietf-dots-data-channel: Filter Direction =20 I understand the concept of call home =96 which makes good sense to me = and rfc8071 will, if implemented, handle the data channel and = =93destination=94 is still where the =91controlled=92 traffic is flowing to. =20 However, we also need call home in the signal channel. I=92m not sure = how this will be done =96 do we need a new CoAP Method (e.g. switch roles) = =96 do we need to define a different port (rfc8071 defines 4336) etc. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 16 February 2018 09:07 To: mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction =20 From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] = Sent: Friday, February 16, 2018 2:19 PM To: Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: RE: draft-ietf-dots-data-channel: Filter Direction =20 Re-, =20 Please see inline.=20 =20 Cheers, Med =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, = Tirumaleswar Reddy Envoy=E9 : vendredi 16 f=E9vrier 2018 09:28 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] draft-ietf-dots-data-channel: Filter Direction =20 There is no ambiguity in the roles. The CPE is acting as DOTS server but = the DOTS server is initiating connection to the DOTS client in the access network. [Med] Don=92t get the last part. The server (CPE) will receive a request = from the network (client) to filter traffic exiting from that CPE.=20 =20 [TR] I mean to use the call home feature discussed in https://tools.ietf.org/html/rfc8071, though the CPE is acting as a DOTS server it will initiate the connection (TLS or DTLS) to the DOTS client = in the access network. The call home feature helps avoid various threats = like the DOTS server in the CPE will not be subjected to DDoS attacks, and reachability is not problem even if the CPE is behind NAT.=20 =20 The DOTS client will convey the black-list filtering in the =93out=94 = direction to block the traffic originating from the DOTS server domain. [Med] Which corresponds to the =93DOTS Server to DOTS Client=94 = direction; that is the DOTS client domain (access network) is the destination. All is = fine so far :)=20 =20 =20 [TR] The direction is =93outgoing traffic=94 whereas for other use cases = the direction is =93incoming traffic=94.=20 =20 I don=92t understand what you mean by a =93optional=94 parameter ? [Med] I meant adding a parameter to indicate explicitly the direction. = It would be optional because we do already have a default direction. =20 [TR] Okay. =20 -Tiru =20 -Tiru =20 From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: Friday, February 16, 2018 1:24 PM To: Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction =20 Hi Tiru,=20 =20 There will be an ambiguity in interpreting filters if and only if the = same DOTS agents have to manipulate filters in both directions.=20 =20 As you rightfully mentioned, the bb use case assumes the following:=20 =20 In order to achieve this capability, the telemetry analysis system utilized by the broadband access provider must have DOTS client functionality, and the end-customer CPE devices must have DOTS server functionality. =20 Which means that there is no ambiguity in that case with the current = default direction: =93the destination is the DOTS client domain=94.=20 =20 No matter how roles were negotiated, but as far as each an agent acts as = a client and its peer as a server, things are clear.=20 =20 Of course we can always define an optional parameter for this, but it is preferable to have a case for it. =20 =20 Cheers, Med =20 De : Konda, Tirumaleswar Reddy = [mailto:TirumaleswarReddy_Konda@McAfee.com]=20 Envoy=E9 : jeudi 15 f=E9vrier 2018 16:31 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: draft-ietf-dots-data-channel: Filter Direction =20 The filtering rule for outgoing traffic is required for the "Suppression = of outbound DDoS traffic originating from a consumer broadband access = network" use case discussed in https://tools.ietf.org/html/draft-ietf-dots-use-cases-09#section-3.2.1. = In this use case, the CPE initially acts as a DOTS client but after the TCP connection is established, reverses its role and acts as DOTS server = (see https://tools.ietf.org/html/rfc8071). The access network can then = program the CPE using the DOTS data channel to block the DDoS attack traffic originated from the compromised devices in the=20 local customer network.=20 =20 Cheers, -Tiru =20 From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: Wednesday, February 14, 2018 1:49 PM To: dots@ietf.org Subject: [Dots] draft-ietf-dots-data-channel: Filter Direction =20 Hi all,=20 =20 As agreed during the interim, there are some issues that need fixes in = the data-channel spec. We would like to hear from the WG to know what to = record in the document.=20 =20 Issue description: Do we need to support explicit =93direction=94 in = filtering rules (=93in=94/=93out=94)? That is, do we allow a DOTS client to create = filters for both incoming and outgoing traffic?=20 =20 Below a proposal for discussion: =96 The current default direction is aligned with the nature of DDoS attacks targeted by DOTS: i.e. incoming. The DOTS client domain is = assumed to be the destination. No ambiguity so far with such default behavior.=20 =96 There is no clear use case for the support of outgoing filtering handling in the context of DOTS. =96 No text change is required to the draft. =20 Any objection?=20 =20 Cheers, Med=20 =20 ------=_NextPart_000_0221_01D3A73B.09B67D60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

See inline = [Jon1].

 

Regards

 

Jon

 

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Friday, February 16, 2018 5:33 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: RE: = [Dots] Call home in the signal channel (was RE: = draft-ietf-dots-data-channel: Filter = Direction)

 

Hi Tiru,

 

The more I think about = it, “Call Home” support in either the data or signal channel = makes no real sense for https://tools.ietf.org/html/draft-ietf-dots-use-cases-09#section-3= .2.1 .  The CPE devices don’t need to trigger the DOTS = clients to get mitigation in place as it will be the provider who works = this out.

 

[TR] No, the above use case helps = the CPE isolate the compromised devices launching DDoS attacks and = protect other devices in the local network from getting infected.

[Jon] OK, so the CPE = says to itself “No idea what is going on, but something bad is = happening”, so I will call home to the provider for them to work = out what is going on and get them to tell me what to do by sending me = some ACLs.

[Jon] Did I = understand this correctly?

 

[TR2] No, the CPE may not even know = if something bad is happening in its network. The CPE proactively = initiates and establishes TLS session with the provider, and simply = waits for requests from the provider to tell if there is something wrong = (It’s a long-lived session). Similar technique is also used to = manage secure home gateways from cloud managment.

[Jon1] OK – a = way of registering/saying “I’m here if = needed”

=

 

However, for 3.2.1, the DOTS client = will need to make a mitigation request to initiate the implementing of = (previously defined) ACLs using the signal channel as there will be a = high possibility of the outbound pipe running = full.

 

[TR] ACL can be enforced  with = “activation” type set to “immediate” using the = DOTS data channel itself.

[Jon] Agreed this can = be done, but (TCP) will fail if the outgoing pipe is full and so the ACL = cannot be put in place.  A signal “mitigate to this target = prefix” will get through though and so kill off some of the = traffic going out to the Internet going to the target = prefix.

 

[TR2] My understanding is Mirai = attacks do not choke the outgoing link in the local network, otherwise = the home admin can easily detect the bandwidth hogging devices, = rate-limit the traffic/turn-off the devices. The goal is to attack a = target in some external domain but at the same-time not to disrupt local = services to avoid any remediation.

[Jon1] Fair = comment.=A0 I still think there could be full pipe issues (e.g. broken = malware not smart enough to limit itself) that we need to think about / = be able to handle.

 

-Jon1

 

-Tiru

 

-Jon=

 

-Tiru

 

Regards

 

Jon

From: Dots [mailto: = dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar = Reddy
Sent: 16 February 2018 11:00
To: mohamed.boucadair@orange.com= ; Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] Call home in the signal channel (was RE: = draft-ietf-dots-data-channel: Filter = Direction)

 

For the = discussed use case https://tools.ietf.org/html/draft-ietf-dots-use-cases-09#section-3= .2.1, the CPE needs to act as a DOTS server only for the data = channel but not for the signal channel. I don’t think signal-channel = requires call home functionality, what is the use case = ?

 

-Tiru

 

From: mohamed.boucadair@orange.com= [mailto:mohamed.boucadair@ora= nge.com]
Sent: Friday, February 16, 2018 3:49 = PM
To: Jon Shallow <supjps-ietf@jpshallow.com&g= t;; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; dots@ietf.org
Subject: Call = home in the signal channel (was RE: [Dots] draft-ietf-dots-data-channel: = Filter Direction)

 

Hi Jon, =

 

I’m changing the title to keep track of = signal-channel specific issues.

 

Please use this one to discuss this use = case.

 

Thank you.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Envoy=E9 : vendredi 16 f=E9vrier 2018 = 10:57
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR = Mohamed IMT/OLN; dots@ietf.org
Objet : = RE: [Dots] draft-ietf-dots-data-channel: Filter = Direction

 

I understand the concept of call home – = which makes good sense to me and rfc8071 will, if implemented, handle = the data channel and “destination” is still where the = ‘controlled’ traffic is flowing to.

 

However, we also need = call home in the signal channel.  I’m not sure how this will = be done – do we need a new CoAP Method (e.g. switch roles) – = do we need to define a different port (rfc8071 defines 4336) = etc.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 16 February 2018 = 09:07
To: mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: Re: = [Dots] draft-ietf-dots-data-channel: Filter = Direction

 

From: mohamed.boucadair@orange.com= [mailto:mohamed.boucadair@ora= nge.com]
Sent: Friday, February 16, 2018 2:19 = PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; dots@ietf.org
Subject: RE: = draft-ietf-dots-data-channel: Filter Direction

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] = De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : = vendredi 16 f=E9vrier 2018 09:28
=C0 : BOUCADAIR Mohamed = IMT/OLN; dots@ietf.org
Objet : = Re: [Dots] draft-ietf-dots-data-channel: Filter = Direction

 

There is no ambiguity = in the roles. The CPE is acting as DOTS server but the DOTS server is = initiating connection to the DOTS client in the access network.

[Med] Don’t get the = last part. The server (CPE) will receive a request from the network = (client) to filter traffic exiting from that CPE. =

 

[TR] I mean to use the call home = feature discussed in https://tools.ietf.org/html/= rfc8071, though the CPE is acting as a DOTS server it will initiate = the connection (TLS or DTLS) to the DOTS client in the access network. = The call home feature helps avoid various threats like the DOTS server = in the CPE will not be subjected to DDoS attacks, and reachability is = not problem even if the CPE is behind NAT.

 

=

The DOTS client will convey the = black-list filtering in the “out” direction to block the = traffic originating from the DOTS server domain.

[Med] Which corresponds to = the “DOTS Server to DOTS Client” direction; that is the DOTS = client domain (access network) is the destination. All is fine so far :) =

 

 

[TR] The direction is = “outgoing traffic” whereas for other use cases the direction = is “incoming traffic”.

 

=

I don’t understand what you = mean by a “optional” parameter ?

[Med] I meant adding a = parameter to indicate explicitly the direction. It would be optional = because we do already have a default direction.

 

[TR] Okay.

 

-Tiru

 

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of mohamed.boucadair@orange.com=
Sent: Friday, February 16, 2018 1:24 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; dots@ietf.org
Subject: Re: = [Dots] draft-ietf-dots-data-channel: Filter = Direction

 

Hi Tiru,

 

There will be an ambiguity in interpreting filters if = and only if the same DOTS agents have to manipulate filters in both = directions.

 

As you rightfully mentioned, the bb use case assumes = the following:

 

   In order to achieve this = capability, the telemetry analysis system

   utilized by the broadband = access provider must have DOTS client

   functionality, and the = end-customer CPE devices must have DOTS server

   functionality.

 

Which means that there is no ambiguity in that case = with the current default direction: “the destination is the DOTS = client domain”.

 

No matter how roles were =
negotiated, but as far as each an agent acts as a client and its peer as =
a server, things are clear. 
 
<= pre>Of course we can always define = an optional parameter for this, but it is preferable to have a case for = it.  
 
<= pre>Cheers,= 
Med

 

De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarRed= dy_Konda@McAfee.com]
Envoy=E9 : jeudi 15 f=E9vrier = 2018 16:31
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : = RE: draft-ietf-dots-data-channel: Filter = Direction

 

The filtering rule for = outgoing traffic is required for the "Suppression of outbound DDoS = traffic originating from a consumer broadband access network" use = case discussed in https://tools.ietf.org/html/draft-ietf-dots-use-cases-09#section-3= .2.1. In this use case, the CPE initially acts as a DOTS client but = after the TCP connection is established, reverses its role and acts as = DOTS server (see https://tools.ietf.org/html/= rfc8071). The access network can then program the CPE using the DOTS = data channel to block the DDoS attack traffic originated from the = compromised devices in the

local customer network. =

 

Cheers,

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of mohamed.boucadair@orange.com=
Sent: Wednesday, February 14, 2018 1:49 PM
To: = dots@ietf.org
Subject: = [Dots] draft-ietf-dots-data-channel: Filter = Direction

 

Hi = all,

 

As = agreed during the interim, there are some issues that need fixes in the = data-channel spec. We would like to hear from the WG to know what to = record in the document.

 

Issue = description: Do we need to support explicit “direction” in = filtering rules (“in”/“out”)? That is, do we = allow a DOTS client to create filters for both incoming and outgoing = traffic?

 

Below = a proposal for discussion:

–    The current default = direction is aligned with the nature of DDoS attacks targeted by DOTS: = i.e. incoming. The DOTS client domain is assumed to be the destination. = No ambiguity so far with such default behavior.

–    There is no clear = use case for the support of outgoing filtering handling in the context = of DOTS.

–    No text change is = required to the draft.

 

Any objection? =

 

Cheers,

Med =

 

------=_NextPart_000_0221_01D3A73B.09B67D60-- From nobody Fri Feb 16 07:46:32 2018 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 80B12126579 for ; Fri, 16 Feb 2018 07:46:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.33 X-Spam-Level: X-Spam-Status: No, score=-4.33 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 qkhBI6UGnir3 for ; Fri, 16 Feb 2018 07:46:27 -0800 (PST) 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 0EA9C120454 for ; Fri, 16 Feb 2018 07:46:26 -0800 (PST) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1518795968; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=2 +qfmaqbsQ9FGb1Mpo+Tewb0DTzPPaj0QxdDUAe6hL I=; b=ApooD1q3Q0wzNtOv/wGRhepPmE5ZuFwETuEs/gMZ5jS0 1kubX+9snsL6OjlKCmBJeHy3Hh5NhzD6fipn001qss35cuHklB W4EVRSn+wv8m6F9TbiebPbRLcNlExNEBBVAGx1SjqD4X5PuGDz aViJ1bQXBNtfYnKe2gYQr5MQKCU= Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 40e4_fda1_0b62a811_1ff3_4aac_8de1_53e5cfda8cd5; Fri, 16 Feb 2018 09:46:07 -0600 Received: from DNVEXUSR1N11.corpzone.internalzone.com (10.44.48.84) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 16 Feb 2018 08:46:02 -0700 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXUSR1N11.corpzone.internalzone.com (10.44.48.84) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Fri, 16 Feb 2018 08:46:02 -0700 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (10.44.176.242) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 16 Feb 2018 08:45:34 -0700 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1593.namprd16.prod.outlook.com (10.173.212.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.18; Fri, 16 Feb 2018 15:46:00 +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.20.0485.022; Fri, 16 Feb 2018 15:46:00 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] draft-ietf-dots-data-channel: Filtering Fields Thread-Index: AdOlbICGgF2MxoHnQied7J+cvW2QAABhQcigAAKnFWAAAuyKQAAGTI4AAAEahwAAASoGAAAAJ8mAAAB6+CAAAZF/MAAB7sFg Date: Fri, 16 Feb 2018 15:45:59 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A0D1F93@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0D32AE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00e801d3a721$08806d30$19814790$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0D366E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019201d3a72a$1b103b70$5130b250$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0D372A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0D3847@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A0D3847@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [171.61.123.199] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1593; 7:nTMBfN9x+BUgGntx/49Ga3Kx3jaigs2Bq20UxFhHdGrgaTUMcyQNr4vMJUaVYhCVTHwZxm5/StwQkf3vUOaWwcQH7k6IMYGSZDEc7oQTuhygGSinWxlkzMLBPjSTRdGBgDHfMSnPUu0ZNavtD0dvE8g/YCswfJjHZBZf+MkJtLuD6PFpC/Hxm7gYroLAAAIb+s61+gGw/RJr7wW53yFnoDKmaz8RzoIF4alU2EhZSfWkZoIrrpKP0J7T4CABpKq7 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 5698d3b3-bdb6-430b-0a05-08d575546093 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM5PR16MB1593; x-ms-traffictypediagnostic: DM5PR16MB1593: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(114627819485645)(95692535739014)(18271650672692)(21748063052155)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(3231101)(944501161)(6041288)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(6072148)(201708071742011); SRVR:DM5PR16MB1593; BCL:0; PCL:0; RULEID:; SRVR:DM5PR16MB1593; x-forefront-prvs: 0585417D7B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39850400004)(366004)(39380400002)(376002)(396003)(53754006)(57704003)(199004)(189003)(32952001)(51444003)(6436002)(55016002)(3280700002)(81156014)(81166006)(9686003)(236005)(790700001)(3846002)(6116002)(2906002)(8936002)(2900100001)(2501003)(8676002)(6246003)(186003)(76176011)(606006)(77096007)(7696005)(14454004)(316002)(86362001)(966005)(110136005)(53546011)(478600001)(6506007)(53936002)(54896002)(6306002)(53946003)(102836004)(26005)(99286004)(93886005)(72206003)(59450400001)(3660700001)(229853002)(80792005)(74316002)(105586002)(106356001)(68736007)(345774005)(33656002)(25786009)(5660300001)(2950100002)(7736002)(97736004)(19609705001)(66066001)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1593; 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) x-microsoft-antispam-message-info: GKNQDgGX+0JjmMdO4pKw5hK9JXAIrmzHUjeTPmE+gZY1e703eTzWXoQS3bcU1QPy7r/0Ekez5jz9T58YirYGMw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1788EEF1D39FBB271782C1E1EACB0DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 5698d3b3-bdb6-430b-0a05-08d575546093 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2018 15:45:59.9651 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1593 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 <6224> : inlines <6404> : streams <1779157> : uri <2593947> Archived-At: Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields 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, 16 Feb 2018 15:46:30 -0000 --_000_DM5PR16MB1788EEF1D39FBB271782C1E1EACB0DM5PR16MB1788namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We may want to add 1) UDP (length) to the list. It may be useful to block large DNS packe= ts (e.g. DNS amplification attack). 2) In IPv4/IPv6, add length, ttl (https://www.cisco.com/c/en/us/about/= security-center/ttl-expiry-attack.html) to the list. -Tiru From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 8:04 PM To: Konda, Tirumaleswar Reddy ; Jon Sha= llow ; dots@ietf.org Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields Re-, Here is a tentative list: Header Mandatory Fields ------ -------------------------------------------------------------- IPv4 protocol, source-port-range-or-operator, destination-port- range-or-operator, destination-ipv4-network, source- ipv4-network, and v4-fragments IPv6 protocol, source-port-range-or-operator, destination-port- range-or-operator, destination-ipv4-network, source- ipv4-network,and v6-fragments TCP flags ICMP type and code Please comment/update. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 16 f=E9vrier 2018 14:55 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields +1. In TCP, only "flags" field looks mandatory. -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 7:03 PM To: Jon Shallow >; Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields Re-, I tend to agree with you to have to define a minimum set of mandatory match= fields. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 16 f=E9vrier 2018 14:29 =C0 : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; dots@ietf.org Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields Hi Med, See inline [Jon] Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 16 February 2018 12:56 To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields Jon, Thank you for sharing your thoughts. Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 16 f=E9vrier 2018 13:24 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org= Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields I like the concept of "+--ro capabilities" allowing for future support as t= he DOS server becomes more mature in its capabilities. If a DOTS client includes a filtering field parameter that is not currently= supported, should the parameter be ignored (and not returned for a GET), o= r the request rejected? [Med] I would vote for rejecting the request. The client should only use ma= tch criteria that are understood by the server; otherwise there will be dif= ferent expectation from the service. [Jon] I think that this is my preference - I was just seeking clarity of th= inking. It is conceivable that a DOTS client has 2 DOTS servers (one possibly a bac= kup, or 2 different ISPs), which may have differing filtering field paramet= er support capabilities. [Med] The backup/case seems odd. I would expect a feature parity for a redu= ndancy group used to provide the same service. [Jon] Agreed that a backup server is most likely to be from the same manufa= cturer and hence support the same functionality. But one may have just bee= n upgraded to have extra support. Adding in intelligence code to work out what is / is not allowed may not = be practical in a (memory or cpu) constrained environment of the DOTS clien= t. [Med] Fair. That said, I think we need to define the minimum set of supported parameter= s - e.g. protocol, source / dest ports, source / dest IPv4 prefixes, sourc= e / dest IPv6 prefixes, fragments and icmp type/code. [Jon] Any comments? -Jon Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 16 February 2018 10:18 To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields Hi Med, Please see inline [TR2] From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 1:45 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: draft-ietf-dots-data-channel: Filtering Fields Re-, Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 16 f=E9vrier 2018 08:00 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Wednesday, February 14, 2018 1:49 PM To: dots@ietf.org Subject: [Dots] draft-ietf-dots-data-channel: Filtering Fields Hi all, As agreed during the interim, there are some issues that need fixes in the = data-channel spec. We would like to hear from the WG to know what to record= in the document. Issue description: Should we support all of the match fields defined by "ie= tf-packet-fields" or do we need to define a minimum supported set? [TR] I don't see the need to support all the match fields, define a minimum= supported set (don't see the use for acl-eth-header-fields for DOTS use ca= ses). [Med] Agree that acl-eth-header-fields aren't required. The text is already= clear about this: DOTS implementations MUST support the following matching criteria: match based on the IP header (IPv4 and IPv6), match based on the transport header (TCP, UDP, and ICMP), and any combination thereof. The question is whether we need to go further and mandate (or not) the supp= ort of matching based on specific fields: dscp, ecn, ttl,... flow-label, ..= . tcp sequence-number, tcp flags, ... [TR2] https://tools.ietf.org/html/draft-ietf-netmod-acl-model-16 uses the f= eature statements in the YANG model allowing vendors to advertise match rul= es they are capable and willing to support but not at the field-level. The = problem is router implementations today don't support ACLs with tcp sequenc= e-number, acknowledgement-number, window-size etc but support TCP flags. If= the server could convey the list of match criteria supported, it not only = allows the client to convey the supported match rules but also allows the s= erver in future to advertise the new supported match fields. Would it be useful for a client to retrieve the list of match criteria supp= orted by a DOTS server? [TR2] Yes. -Tiru [TR] The YANG model supported by the DOTS server can retrieved by the DOTS = client using RESTCONF to determine the match criteria supported by the serv= er. [Med] I'm afraid this is not the same functionality. If we need to allow a = server to return its supported match criteria, this should be allowed by th= e module. For example, the module may include the following (example): +--ro capabilities | +--ro match-header* | | identityref | +--ro transport-protocols* [protocol-id] | | +--ro protocol-id uint8 | | +--ro protocol-name? string | +--ro dscp-support? boolean | +--ro ecn-support? boolean | +--ro length-support? boolean | +--ro ttl-support? boolean | +--ro protocol-support? boolean The client can ask the server to return its supported match criteria. The s= erver will indicate the exact set of fields it supports. I'm not expressing a preference to have this in the model, but I'm clarifyi= ng how it would look like. -Tiru Please comment. Cheers, Med --_000_DM5PR16MB1788EEF1D39FBB271782C1E1EACB0DM5PR16MB1788namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

We may wa= nt to add

&nbs= p;

1)      UDP (length) to the list. It may be useful to block= large DNS packets (e.g. DNS amplification attack).

2)      In IPv4/IPv6, add length, ttl (https://= www.cisco.com/c/en/us/about/security-center/ttl-expiry-attack.html) to the list.

&nbs= p;

-Tiru

 

From:<= /span> mohamed.boucadair@ora= nge.com [mailto:mohamed.boucadair@orange.com]
Sent: Friday, February 16, 2018 8:04 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; Jon Shallow <supjps-ietf@jpshallow.com>; dots@ietf.org
Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields

 

Re-,

 

Here is a tentative list:

 

   Header Mandatory Fiel= ds

   ------ --------------= ------------------------------------------------

   IPv4   prot= ocol, source-port-range-or-operator, destination-port-

     &nbs= p;    range-or-operator, destination-ipv4-network, source-

     &nbs= p;    ipv4-network, and v4-fragments

   IPv6   prot= ocol, source-port-range-or-operator, destination-port-

     &nbs= p;    range-or-operator, destination-ipv4-network, source-

     &nbs= p;    ipv4-network,and v6-fragments

   TCP   = flags

   ICMP   type and code

 

Please comment/update.

 

Cheers,

Med=

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : vendredi 16 f=E9vrier 2018 14:55
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fiel= ds

 

+1. I= n TCP, only “flags” field looks mandatory.

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Friday, February 16, 2018 7:03 PM
To: Jon Shallow <sup= jps-ietf@jpshallow.com>; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org
Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields

 

Re-,

 

I tend to agree with you to have to define a m= inimum set of mandatory match fields.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : vendredi 16 f=E9vrier 2018 14:29
=C0 : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; dots@ietf.org
Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fiel= ds

 

Hi Med,=

&n= bsp;

See inl= ine [Jon]

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 16 February 2018 12:56
To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields

 

Jon,

 

Thank you for sharing your thoughts.

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : vendredi 16 f=E9vrier 2018 13:24
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; <= a href=3D"mailto:dots@ietf.org"> dots@ietf.org
Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fiel= ds

 

I like the concept of “+=
--ro capabilities“ allowing for future support as t=
he DOS server becomes more mature in its capabilities.

 


If a DOTS client includes a filtering field parameter that =
is not currently supported, should the parameter be ignored (and not return=
ed for a GET), or the request rejected?


[Med] I would vote for re=
jecting the request. The client should only use match criteria that are und=
erstood by the server; otherwise there will be different expectation from t=
he service. 


[Jon] I think that this is my preference – I was just=
 seeking clarity of thinking.


<=
o:p> 


It is conceivable that a DOTS client has 2 DOTS servers (on=
e possibly a backup, or 2 different ISPs), which may have differing filteri=
ng field parameter support capabilities.


[Med] The backup/case see=
ms odd. I would expect a feature parity for a redundancy group used to prov=
ide the same service.=



[=
Jon] Agreed that a backup server is most likely to be from the same manufac=
turer and hence support the same functionality.  But one may have just=
 been upgraded to have extra support.


<=
o:p> 


 <=
/pre>

 <=
/pre>

  Adding in intelligence code to work out what is / is=
 not allowed may not be practical in a (memory or cpu) constrained environm=
ent of the DOTS client.


[Med] Fair. 


 


That said, I think we need to define the minimum set of sup=
ported parameters – e.g. protocol, source / dest ports,  source =
/ dest IPv4 prefixes, source / dest IPv6 prefixes, fragments and icmp type/=
code. 


[Jon] Any comments?


<=
o:p> 


-=
Jon


<=
o:p> 


Regards


 


Jon


&n=
bsp;






From: Dots [mailto:
dots-bounces@ietf.org] On B=
ehalf Of
Konda, Tirumaleswar Reddy

Sent: 16 February 2018 10:18

To: mohamed.boucadai=
r@orange.com;
dots@ietf.org

Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields






 


Hi Med,


&nbs=
p;


Please se=
e inline [TR2]


&nbs=
p;








From:<=
/span>
mohamed.boucadair@orange.co=
m [mailto:mohamed.bouca=
dair@orange.com]


Sent: Friday, February 16, 2018 1:45 PM

To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>;
dots@ietf.org

Subject: RE: draft-ietf-dots-data-channel: Filtering Fields






 


Re-,


 


Please see inline.



 


Cheers,


Med


 








De : Dots [mailto:dots-bounces@ietf.org]
De la part de Konda, Tirumaleswar Reddy

Envoy=E9 : vendredi 16 f=E9vrier 2018 08:00

=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org

Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fiel=
ds






 


From:<=
/span> Dots [mailto:dots-bounces@ietf.org]
On Behalf Of mohamed=
.boucadair@orange.com

Sent: Wednesday, February 14, 2018 1:49 PM

To: dots@ietf.org

Subject: [Dots] draft-ietf-dots-data-channel: Filtering Fields<=
/o:p>


 


Hi all,



 


As agreed during the interim, there are some issues that n=
eed fixes in the data-channel spec. We would like to hear from the WG to kn=
ow what to record in the document.



 


Issue description: Should we support all of the match fiel=
ds defined by “ietf-packet-fields” or do we need to define a mi=
nimum supported set?



 


[TR] I don’t see the need to support all the m=
atch fields, define a minimum supported set (don’t see the use for ac=
l-eth-header-fields for DOTS use cases).  


[Med] Agree that acl-eth-header-fields aren=
217;t required. The text is already clear about this:


 


DOTS implementations MUST support =
the following


   matching criteria: ma=
tch based on the IP header (IPv4 and IPv6),


   match based on the tr=
ansport header (TCP, UDP, and ICMP), and any


  
combination thereof.=



 


The question is whether we need to go fu=
rther and mandate (or not) the support of matching based on specific fields=
: dscp, ecn, ttl,… flow-label, … tcp s=
equence-number, tcp flags, …  <=
/o:p>


 


[TR2] https://tools.ietf.o=
rg/html/draft-ietf-netmod-acl-model-16 uses the feature statements in the YANG model allowin=
g vendors to advertise match rules they are capable and willing to support =
but not at the field-level. The problem is router implementations today don=
’t support ACLs with tcp sequence-number, acknowledgement-number, win=
dow-size etc but support TCP flags. If the server could convey the list of =
match criteria supported, it not only allows the client to convey the suppo=
rted match rules but also allows the server in future to advertise the new =
supported match fields.   


 


Would it be useful for a client to retrieve the list of ma=
tch criteria supported by a DOTS server?



 


[TR2] Yes. 


 


-Tiru


 


[TR] The YANG model supported by the DOTS server can=
 retrieved by the DOTS client using RESTCONF to determine the match criteri=
a supported by the server.



[Med] I’m afraid this is not the same fu=
nctionality. If we need to allow a server to return its supported match cri=
teria, this should be allowed by the module. For example,
 the module may include the following (example): 


 


        &nbs=
p;       +--ro capabilities


        &nbs=
p;       |  +--ro match-header*=



        &nbs=
p;       |  |    &nb=
sp;  identityref


        &nbs=
p;       |  +--ro transport-protocol=
s* [protocol-id]


        &nbs=
p;       |  |  +--ro protocol-i=
d      uint8


        &nbs=
p;       |  |  +--ro protocol-n=
ame?   string


        &nbs=
p;       |  +--ro dscp-support? &nbs=
p;     boolean


        &nbs=
p;       |  +--ro ecn-support?  =
;      boolean


        &nbs=
p;       |  +--ro length-support? &n=
bsp;   boolean


        &nbs=
p;       |  +--ro ttl-support?  =
;      boolean


        &nbs=
p;       |  +--ro protocol-support? =
  boolean


 


The client can ask the server to return its supported match criteria. The server will indicate the =
exact set of fields it supports. 


 


I’m not expressing a preference to=
 have this in the model, but I’m clarifying how it would look like. <=
/span>


 


-Tiru


 


Please comment.



 <=
/p>

Cheers,=



Med
--_000_DM5PR16MB1788EEF1D39FBB271782C1E1EACB0DM5PR16MB1788namp_-- From nobody Fri Feb 16 07:54:56 2018 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 5AF43120454 for ; Fri, 16 Feb 2018 07:54:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 iA7vOw-FQrw2 for ; Fri, 16 Feb 2018 07:54:51 -0800 (PST) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAA281201F2 for ; Fri, 16 Feb 2018 07:54:50 -0800 (PST) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 6841C10137B; Fri, 16 Feb 2018 16:54:49 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.69]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 43B3260062; Fri, 16 Feb 2018 16:54:49 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%18]) with mapi id 14.03.0382.000; Fri, 16 Feb 2018 16:54:48 +0100 From: To: Jon Shallow , "Konda, Tirumaleswar Reddy" , "dots@ietf.org" Thread-Topic: [Dots] draft-ietf-dots-data-channel: Filtering Fields Thread-Index: AdOlbICGgF2MxoHnQied7J+cvW2QAAMZabEuApwt0GoCITdLGgK2/q2yAt/zojQB0mpcSAMW+5mCAaQFvl8BTSXY9KDSn0CQoXk+0XA= Date: Fri, 16 Feb 2018 15:54:47 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0D3914@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300A0D1F93@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0D32AE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00e801d3a721$08806d30$19814790$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0D366E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019201d3a72a$1b103b70$5130b250$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0D372A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0D3847@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <020a01d3a739$9fd9ec70$df8dc550$@jpshallow.com> In-Reply-To: <020a01d3a739$9fd9ec70$df8dc550$@jpshallow.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A0D3914OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields 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, 16 Feb 2018 15:54:54 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A0D3914OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, I went in my local copy with the "uses packet-fields:acl-xxx" for managing = filters, but added a new container to list the capabilities to our module. = Below an excerpt of the (draft) tree structure: +--ro capabilities +--ro address-family* enumeration +--ro supported-actions* identityref +--ro fragment-support* enumeration +--ro transport-protocols* [protocol-id] | +--ro protocol-id uint8 | +--ro protocol-name? string +--ro ip-header-fields +--ro dscp-support? boolean +--ro ecn-support? boolean +--ro v4-length-support? boolean +--ro v6-length-support? boolean +--ro v4-ttl-support? boolean +--ro v6-hoplimit-support? boolean +--ro v4-ihl? boolean +--ro v4-flags? boolean +--ro v4-offset? boolean +--ro v4-identification? boolean +--ro v6-flowlabel? boolean +--ro destination-prefix? boolean +--ro source-prefix? boolean ... Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 16 f=E9vrier 2018 16:20 =C0 : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; dots@ietf.org Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields Hi Med, I agree with the list (and am likely to only implement those!). As I see it, there are 2 possible ways forward here 1) We add in an Boolean 'supported' capability for the list of all the= other options in packet-fields:acl-xxx 2) We drop the use of "uses packet-fields:acl-xxx" and define our own = required entries, exactly modelled on draft-ietf-netmod-acl-model-16 defini= tions. Comments? Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 16 February 2018 14:34 To: Konda, Tirumaleswar Reddy; Jon Shallow; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields Re-, Here is a tentative list: Header Mandatory Fields ------ -------------------------------------------------------------- IPv4 protocol, source-port-range-or-operator, destination-port- range-or-operator, destination-ipv4-network, source- ipv4-network, and v4-fragments IPv6 protocol, source-port-range-or-operator, destination-port- range-or-operator, destination-ipv4-network, source- ipv4-network,and v6-fragments TCP flags ICMP type and code Please comment/update. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 16 f=E9vrier 2018 14:55 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields +1. In TCP, only "flags" field looks mandatory. -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 7:03 PM To: Jon Shallow >; Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields Re-, I tend to agree with you to have to define a minimum set of mandatory match= fields. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 16 f=E9vrier 2018 14:29 =C0 : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; dots@ietf.org Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields Hi Med, See inline [Jon] Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 16 February 2018 12:56 To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields Jon, Thank you for sharing your thoughts. Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 16 f=E9vrier 2018 13:24 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org= Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields I like the concept of "+--ro capabilities" allowing for future support as t= he DOS server becomes more mature in its capabilities. If a DOTS client includes a filtering field parameter that is not currently= supported, should the parameter be ignored (and not returned for a GET), o= r the request rejected? [Med] I would vote for rejecting the request. The client should only use ma= tch criteria that are understood by the server; otherwise there will be dif= ferent expectation from the service. [Jon] I think that this is my preference - I was just seeking clarity of th= inking. It is conceivable that a DOTS client has 2 DOTS servers (one possibly a bac= kup, or 2 different ISPs), which may have differing filtering field paramet= er support capabilities. [Med] The backup/case seems odd. I would expect a feature parity for a redu= ndancy group used to provide the same service. [Jon] Agreed that a backup server is most likely to be from the same manufa= cturer and hence support the same functionality. But one may have just bee= n upgraded to have extra support. Adding in intelligence code to work out what is / is not allowed may not = be practical in a (memory or cpu) constrained environment of the DOTS clien= t. [Med] Fair. That said, I think we need to define the minimum set of supported parameter= s - e.g. protocol, source / dest ports, source / dest IPv4 prefixes, sourc= e / dest IPv6 prefixes, fragments and icmp type/code. [Jon] Any comments? -Jon Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 16 February 2018 10:18 To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields Hi Med, Please see inline [TR2] From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 1:45 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: draft-ietf-dots-data-channel: Filtering Fields Re-, Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 16 f=E9vrier 2018 08:00 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Wednesday, February 14, 2018 1:49 PM To: dots@ietf.org Subject: [Dots] draft-ietf-dots-data-channel: Filtering Fields Hi all, As agreed during the interim, there are some issues that need fixes in the = data-channel spec. We would like to hear from the WG to know what to record= in the document. Issue description: Should we support all of the match fields defined by "ie= tf-packet-fields" or do we need to define a minimum supported set? [TR] I don't see the need to support all the match fields, define a minimum= supported set (don't see the use for acl-eth-header-fields for DOTS use ca= ses). [Med] Agree that acl-eth-header-fields aren't required. The text is already= clear about this: DOTS implementations MUST support the following matching criteria: match based on the IP header (IPv4 and IPv6), match based on the transport header (TCP, UDP, and ICMP), and any combination thereof. The question is whether we need to go further and mandate (or not) the supp= ort of matching based on specific fields: dscp, ecn, ttl,... flow-label, ..= . tcp sequence-number, tcp flags, ... [TR2] https://tools.ietf.org/html/draft-ietf-netmod-acl-model-16 uses the f= eature statements in the YANG model allowing vendors to advertise match rul= es they are capable and willing to support but not at the field-level. The = problem is router implementations today don't support ACLs with tcp sequenc= e-number, acknowledgement-number, window-size etc but support TCP flags. If= the server could convey the list of match criteria supported, it not only = allows the client to convey the supported match rules but also allows the s= erver in future to advertise the new supported match fields. Would it be useful for a client to retrieve the list of match criteria supp= orted by a DOTS server? [TR2] Yes. -Tiru [TR] The YANG model supported by the DOTS server can retrieved by the DOTS = client using RESTCONF to determine the match criteria supported by the serv= er. [Med] I'm afraid this is not the same functionality. If we need to allow a = server to return its supported match criteria, this should be allowed by th= e module. For example, the module may include the following (example): +--ro capabilities | +--ro match-header* | | identityref | +--ro transport-protocols* [protocol-id] | | +--ro protocol-id uint8 | | +--ro protocol-name? string | +--ro dscp-support? boolean | +--ro ecn-support? boolean | +--ro length-support? boolean | +--ro ttl-support? boolean | +--ro protocol-support? boolean The client can ask the server to return its supported match criteria. The s= erver will indicate the exact set of fields it supports. I'm not expressing a preference to have this in the model, but I'm clarifyi= ng how it would look like. -Tiru Please comment. Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300A0D3914OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

I went in my local copy with th= e “uses packet-fields:acl-xxx” for managing filters, but added = a new container to list the capabilities to our module. Below an excerpt of the (draft) tree structure:

 

    = +--ro capabilities

    =    +--ro address-family*     &n= bsp;  enumeration

   &= nbsp;   +--ro supported-actions*     iden= tityref

   &= nbsp;   +--ro fragment-support*     = enumeration

   &= nbsp;   +--ro transport-protocols* [protocol-id]

   &= nbsp;   |  +--ro protocol-id    &nbs= p; uint8

   &= nbsp;   |  +--ro protocol-name?   string<= /o:p>

   &= nbsp;   +--ro ip-header-fields

   &= nbsp;      +--ro dscp-support?  &nbs= p;       boolean

   &= nbsp;      +--ro ecn-support?   = ;        boolean

   &= nbsp;      +--ro v4-length-support?  = ;   boolean

   &= nbsp;      +--ro v6-length-support?  = ;   boolean

   &= nbsp;      +--ro v4-ttl-support?  &n= bsp;     boolean

   &= nbsp;      +--ro v6-hoplimit-support? &nb= sp; boolean

   &= nbsp;      +--ro v4-ihl?   &nbs= p;            boolea= n

   &= nbsp;      +--ro v4-flags?   &n= bsp;          boolean

   &= nbsp;      +--ro v4-offset?   &= nbsp;         boolean

   &= nbsp;      +--ro v4-identification?  = ;   boolean

   &= nbsp;     +--ro v6-flowlabel?   = ;       boolean

   &= nbsp;      +--ro destination-prefix? &nbs= p;  boolean

   &= nbsp;      +--ro source-prefix?  &nb= sp;      boolean

     &= nbsp;       …

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf= @jpshallow.com]
Envoy=E9 : vendredi 16 f=E9vrier 2018 16:20
=C0 : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; dot= s@ietf.org
Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fiel= ds

 

Hi Med,=

&n= bsp;

I agree= with the list (and am likely to only implement those!).<= /p>

&n= bsp;

As I se= e it, there are 2 possible ways forward here

&n= bsp;

= 1)      We add in an Boolean ‘supported’ capability for the list of al= l the other options in packet-fields:acl-xxx

= 2)      We drop the use of “uses packet-fields:acl-xxx” and define our= own required entries, exactly modelled on draft-ietf-netmod-acl-model-16 d= efinitions.

&n= bsp;

Comment= s?

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 16 February 2018 14:34
To: Konda, Tirumaleswar Reddy; Jon Shallow; dots@ietf.org
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields

 

Re-,

 

Here is a tentative list:

 

   Header= Mandatory Fields

   ------= --------------------------------------------------------------<= /span>

   IPv4&n= bsp;  protocol, source-port-range-or-operator, destination-port-<= /o:p>

   &= nbsp;      range-or-operator, destination-ipv4-net= work, source-

   &= nbsp;      ipv4-network, and v4-fragments

   IPv6&n= bsp;  protocol, source-port-range-or-operator, destination-port-<= /o:p>

   &= nbsp;      range-or-operator, destination-ipv4-net= work, source-

   &= nbsp;      ipv4-network,and v6-fragments

   TCP&nb= sp;   flags

   ICMP   type and code

 

Please comment/update.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : vendredi 16 f=E9vrier 2018 14:55
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fiel= ds

 

+1. In TCP, only “flags” field looks mandatory.

 

-Tiru

 

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Friday, February 16, 2018 7:03 PM
To: Jon Shallow <sup= jps-ietf@jpshallow.com>; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org
Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields

 

Re-,

 

I tend to agree with you to hav= e to define a minimum set of mandatory match fields.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : vendredi 16 f=E9vrier 2018 14:29
=C0 : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; dots@ietf.org
Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fiel= ds

 

Hi Med,=

&n= bsp;

See inl= ine [Jon]

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 16 February 2018 12:56
To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields

 

Jon,

 

Thank you for sharing your thou= ghts.

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : vendredi 16 f=E9vrier 2018 13:24
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; <= a href=3D"mailto:dots@ietf.org"> dots@ietf.org
Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fiel= ds

 

I like the concept of “+--ro capabilities“ allowing for futu=
re support as the DOS server becomes more mature in its capabilities.<=
/o:p>
 
If a DOTS client includes a filtering field parameter that =
is not currently supported, should the parameter be ignored (and not return=
ed for a GET), or the request rejected?
[Med] I would vote for re=
jecting the request. The client should only use match criteria that are und=
erstood by the server; otherwise there will be different expectation from t=
he service. 
[Jon] I think that this is my preference – I was just=
 seeking clarity of thinking.
<=
o:p> 
It is conceivable that a DOTS client has 2 DOTS servers (on=
e possibly a backup, or 2 different ISPs), which may have differing filteri=
ng field parameter support capabilities.
[Med] The backup/case see=
ms odd. I would expect a feature parity for a redundancy group used to prov=
ide the same service.=

[=
Jon] Agreed that a backup server is most likely to be from the same manufac=
turer and hence support the same functionality.  But one may have just=
 been upgraded to have extra support.
<=
o:p> 
 <=
/pre>

 <=
/pre>

  Adding in intelligence code to work out what is / is=
 not allowed may not be practical in a (memory or cpu) constrained environm=
ent of the DOTS client.


[Med] Fair. 


 


That said, I think we need to define the minimum set of sup=
ported parameters – e.g. protocol, source / dest ports,  source =
/ dest IPv4 prefixes, source / dest IPv6 prefixes, fragments and icmp type/=
code. 


[Jon] Any comments?


<=
o:p> 


-=
Jon


<=
o:p> 


Regards


 


Jon


&n=
bsp;






From:=
 Dots [mailto:
dots-bounces@ietf.org] On B=
ehalf Of
Konda, Tirumaleswar Reddy

Sent: 16 February 2018 10:18

To: mohamed.boucadai=
r@orange.com;
dots@ietf.org

Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields






 


Hi Med,


 


Please see inline [TR2]


 








From:
mohamed.boucadair@orange.co=
m [mailto:mohamed.bouca=
dair@orange.com]


Sent: Friday, February 16, 2018 1:45 PM

To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>;
dots@ietf.org

Subject: RE: draft-ietf-dots-data-channel: Filtering Fields






 


Re-,


 


Please see inline.



 


Cheers,


Med


 








De : Dots [mailto:dots-bounces@ietf.org]
De la part de Konda, Tirumaleswar Reddy

Envoy=E9 : vendredi 16 f=E9vrier 2018 08:00

=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org

Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fiel=
ds






 


From: Dots [mailto:dots-bounces=
@ietf.org]
On Behalf Of mohamed=
.boucadair@orange.com

Sent: Wednesday, February 14, 2018 1:49 PM

To: dots@ietf.org

Subject: [Dots] draft-ietf-dots-data-channel: Filtering Fields<=
/o:p>


 


Hi all,



 


As agreed during the interim, there are som=
e issues that need fixes in the data-channel spec. We would like to hear fr=
om the WG to know what to record in the document.



 


Issue description: Should we support all of=
 the match fields defined by “ietf-packet-fields” or do we need=
 to define a minimum supported set?



 


[TR] I don’t see the need=
 to support all the match fields, define a minimum supported set (don’=
;t see the use for acl-eth-header-fields for DOTS use cases).  


[Med] Agree that acl-eth-header=
-fields aren’t required. The text is already clear about this:


 


DOTS implementation=
s MUST support the following


   matchi=
ng criteria: match based on the IP header (IPv4 and IPv6),


   match =
based on the transport header (TCP, UDP, and ICMP), and any


  
combination thereof.


 


The question is whether w=
e need to go further and mandate (or not) the support of matching based on =
specific fields: dscp, ecn, ttl,… flow-label, … tcp sequence-number, tcp flags, …  


 


[TR2] https=
://tools.ietf.org/html/draft-ietf-netmod-acl-model-16 uses the feature statem=
ents in the YANG model allowing vendors to advertise match rules they are c=
apable and willing to support but not at the field-level. The problem is ro=
uter implementations today don’t support ACLs with tcp sequence-numbe=
r, acknowledgement-number, window-size etc but support TCP flags. If the se=
rver could convey the list of match criteria supported, it not only allows =
the client to convey the supported match rules but also allows the server i=
n future to advertise the new supported match fields.   


 


Would it be useful for a client to retrieve=
 the list of match criteria supported by a DOTS server?



 


[TR2] Yes. 

 


-Tiru


 


[TR] The YANG model supported b=
y the DOTS server can retrieved by the DOTS client using RESTCONF to determ=
ine the match criteria supported by the server.



[Med] I’m afraid this is =
not the same functionality. If we need to allow a server to return its supp=
orted match criteria, this should be allowed by the module.
 For example, the module may include the following (example): 


 


      &=
nbsp;         +--ro capabilitie=
s


      &=
nbsp;         |  +--ro mat=
ch-header*


      &=
nbsp;         |  |  =
     identityref


      &=
nbsp;         |  +--ro tra=
nsport-protocols* [protocol-id]


      &=
nbsp;         |  |  +=
--ro protocol-id      uint8

      &=
nbsp;         |  |  +=
--ro protocol-name?   string


      &=
nbsp;         |  +--ro dsc=
p-support?       boolean

      &=
nbsp;         |  +--ro ecn=
-support?        boolean


      &=
nbsp;         |  +--ro len=
gth-support?     boolean


      &=
nbsp;         |  +--ro ttl=
-support?        boolean


      &=
nbsp;         |  +--ro pro=
tocol-support?   boolean


 


The client can ask the server to retu=
rn its supported match criteria. The server wil=
l indicate the exact set of fields it supports. 

 <=
/pre>

I’m not expressing =
a preference to have this in the model, but I’m clarifying how it wou=
ld look like. 

 


-Tiru


 


Please com=
ment.



 =
;


Cheers,


Med=
<=
/o:p>
--_000_787AE7BB302AE849A7480A190F8B93300A0D3914OPEXCLILMA3corp_-- From nobody Fri Feb 16 08:14:35 2018 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 2F9B8126579 for ; Fri, 16 Feb 2018 08:14:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 0XMOFrdcpkv8 for ; Fri, 16 Feb 2018 08:14:30 -0800 (PST) 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 80AB6120454 for ; Fri, 16 Feb 2018 08:14:29 -0800 (PST) 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 1emieZ-000105-MN; Fri, 16 Feb 2018 16:14:27 +0000 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , , References: <787AE7BB302AE849A7480A190F8B93300A0D1F93@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0D32AE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00e801d3a721$08806d30$19814790$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0D366E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019201d3a72a$1b103b70$5130b250$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0D372A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0D3847@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Date: Fri, 16 Feb 2018 16:14:29 -0000 Message-ID: <025401d3a741$390f6760$ab2e3620$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0255_01D3A741.3911B150" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLoxvz0kGpX/tRyz6XeuCXxpheRlwMZabEuApwt0GoCITdLGgK2/q2yAt/zojQB0mpcSAMW+5mCAaQFvl8BTSXY9AJNbg0LoMBCBhA= Content-Language: en-gb Archived-At: Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields 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, 16 Feb 2018 16:14:33 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0255_01D3A741.3911B150 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ttl is an interesting one. It is not definable as a range, and so if = you want to match =93ttl lt 16=94 you are going to have to have 16 ACLs = preceding any other ACL that does anything else. =20 I would expect that =91ttl=92 would be done properly as a one of the = mitigator rules, and DOTS does not need to =91hint=92 it as well. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 16 February 2018 15:46 To: mohamed.boucadair@orange.com; Jon Shallow; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields =20 We may want to add=20 =20 1) UDP (length) to the list. It may be useful to block large DNS packets (e.g. DNS amplification attack). 2) In IPv4/IPv6, add length, ttl (https://www.cisco.com/c/en/us/about/security-center/ttl-expiry-attack.ht= ml) to the list.=20 =20 -Tiru =20 From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] = Sent: Friday, February 16, 2018 8:04 PM To: Konda, Tirumaleswar Reddy ; Jon Shallow ; dots@ietf.org Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields =20 Re-, =20 Here is a tentative list:=20 =20 Header Mandatory Fields ------ -------------------------------------------------------------- IPv4 protocol, source-port-range-or-operator, destination-port- range-or-operator, destination-ipv4-network, source- ipv4-network, and v4-fragments IPv6 protocol, source-port-range-or-operator, destination-port- range-or-operator, destination-ipv4-network, source- ipv4-network,and v6-fragments TCP flags ICMP type and code =20 Please comment/update.=20 =20 Cheers, Med =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, = Tirumaleswar Reddy Envoy=E9 : vendredi 16 f=E9vrier 2018 14:55 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields =20 +1. In TCP, only =93flags=94 field looks mandatory.=20 =20 -Tiru =20 From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] = Sent: Friday, February 16, 2018 7:03 PM To: Jon Shallow ; Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields =20 Re-, =20 I tend to agree with you to have to define a minimum set of mandatory = match fields.=20 =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : vendredi 16 f=E9vrier 2018 14:29 =C0 : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; = dots@ietf.org Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields =20 Hi Med, =20 See inline [Jon] =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 16 February 2018 12:56 To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields =20 Jon, =20 Thank you for sharing your thoughts.=20 =20 Please see inline. =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : vendredi 16 f=E9vrier 2018 13:24 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; = dots@ietf.org Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields =20 I like the concept of =93+--ro capabilities=93 allowing for future = support as the DOS server becomes more mature in its capabilities. =20 If a DOTS client includes a filtering field parameter that is not = currently supported, should the parameter be ignored (and not returned for a GET), = or the request rejected? [Med] I would vote for rejecting the request. The client should only use match criteria that are understood by the server; otherwise there will = be different expectation from the service.=20 [Jon] I think that this is my preference =96 I was just seeking clarity = of thinking. =20 It is conceivable that a DOTS client has 2 DOTS servers (one possibly a backup, or 2 different ISPs), which may have differing filtering field parameter support capabilities. [Med] The backup/case seems odd. I would expect a feature parity for a redundancy group used to provide the same service. [Jon] Agreed that a backup server is most likely to be from the same manufacturer and hence support the same functionality. But one may have just been upgraded to have extra support. =20 =20 =20 Adding in intelligence code to work out what is / is not allowed may = not be practical in a (memory or cpu) constrained environment of the DOTS client. [Med] Fair.=20 =20 That said, I think we need to define the minimum set of supported = parameters =96 e.g. protocol, source / dest ports, source / dest IPv4 prefixes, = source / dest IPv6 prefixes, fragments and icmp type/code.=20 [Jon] Any comments? =20 -Jon =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 16 February 2018 10:18 To: mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields =20 Hi Med, =20 Please see inline [TR2] =20 From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] = Sent: Friday, February 16, 2018 1:45 PM To: Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: RE: draft-ietf-dots-data-channel: Filtering Fields =20 Re-, =20 Please see inline.=20 =20 Cheers, Med =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, = Tirumaleswar Reddy Envoy=E9 : vendredi 16 f=E9vrier 2018 08:00 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields =20 From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: Wednesday, February 14, 2018 1:49 PM To: dots@ietf.org Subject: [Dots] draft-ietf-dots-data-channel: Filtering Fields =20 Hi all,=20 =20 As agreed during the interim, there are some issues that need fixes in = the data-channel spec. We would like to hear from the WG to know what to = record in the document.=20 =20 Issue description: Should we support all of the match fields defined by =93ietf-packet-fields=94 or do we need to define a minimum supported = set?=20 =20 [TR] I don=92t see the need to support all the match fields, define a = minimum supported set (don=92t see the use for acl-eth-header-fields for DOTS = use cases). =20 [Med] Agree that acl-eth-header-fields aren=92t required. The text is = already clear about this: =20 DOTS implementations MUST support the following matching criteria: match based on the IP header (IPv4 and IPv6), match based on the transport header (TCP, UDP, and ICMP), and any combination thereof. =20 The question is whether we need to go further and mandate (or not) the support of matching based on specific fields: dscp, ecn, ttl,=85 = flow-label, =85 tcp sequence-number, tcp flags, =85 =20 =20 [TR2] https://tools.ietf.org/html/draft-ietf-netmod-acl-model-16 uses the = feature statements in the YANG model allowing vendors to advertise match rules = they are capable and willing to support but not at the field-level. The = problem is router implementations today don=92t support ACLs with tcp = sequence-number, acknowledgement-number, window-size etc but support TCP flags. If the = server could convey the list of match criteria supported, it not only allows = the client to convey the supported match rules but also allows the server in future to advertise the new supported match fields. =20 =20 Would it be useful for a client to retrieve the list of match criteria supported by a DOTS server?=20 =20 [TR2] Yes.=20 =20 -Tiru =20 [TR] The YANG model supported by the DOTS server can retrieved by the = DOTS client using RESTCONF to determine the match criteria supported by the server.=20 [Med] I=92m afraid this is not the same functionality. If we need to = allow a server to return its supported match criteria, this should be allowed by = the module. For example, the module may include the following (example):=20 =20 +--ro capabilities | +--ro match-header* | | identityref | +--ro transport-protocols* [protocol-id] | | +--ro protocol-id uint8 | | +--ro protocol-name? string | +--ro dscp-support? boolean | +--ro ecn-support? boolean | +--ro length-support? boolean | +--ro ttl-support? boolean | +--ro protocol-support? boolean =20 The client can ask the server to return its supported match criteria. = The server will indicate the exact set of fields it supports.=20 =20 I=92m not expressing a preference to have this in the model, but I=92m clarifying how it would look like.=20 =20 -Tiru =20 Please comment.=20 =20 Cheers, Med ------=_NextPart_000_0255_01D3A741.3911B150 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Ttl is an interesting one.=A0 It is not = definable as a range, and so if you want to match “ttl lt = 16” you are going to have to have 16 ACLs preceding any other ACL = that does anything else.

 

I would expect that = ‘ttl’ would be done properly as a one of the mitigator = rules, and DOTS does not need to ‘hint’ it as = well.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = Konda, Tirumaleswar Reddy
Sent: 16 February 2018 = 15:46
To: mohamed.boucadair@orange.com; Jon Shallow; = dots@ietf.org
Subject: Re: [Dots] = draft-ietf-dots-data-channel: Filtering = Fields

 

We may want to add =

 

1)     = UDP = (length) to the list. It may be useful to block large DNS packets (e.g. = DNS amplification attack).

2)     = In = IPv4/IPv6, add length, ttl (https://www.cisco.com/c/en/us/about/security-center/ttl-expiry= -attack.html) to the list.

 

-Tiru

 

From: = mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] =
Sent: Friday, February 16, 2018 8:04 PM
To: Konda, = Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon = Shallow <supjps-ietf@jpshallow.com>; = dots@ietf.org
Subject: RE: [Dots] = draft-ietf-dots-data-channel: Filtering = Fields

 

Re-,

 

Here is a tentative list:

 

   Header Mandatory = Fields

   ------ = --------------------------------------------------------------=

   IPv4   protocol, = source-port-range-or-operator, destination-port-

       &= nbsp;  range-or-operator, destination-ipv4-network, = source-

        =   ipv4-network, and v4-fragments

   IPv6   protocol, = source-port-range-or-operator, destination-port-

       &= nbsp;  range-or-operator, destination-ipv4-network, = source-

       &= nbsp;  ipv4-network,and v6-fragments

   TCP    = flags

   ICMP   type and = code

 

Please comment/update. =

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] = De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : = vendredi 16 f=E9vrier 2018 14:55
=C0 : BOUCADAIR Mohamed = IMT/OLN; Jon Shallow; dots@ietf.org
Objet : = Re: [Dots] draft-ietf-dots-data-channel: Filtering = Fields

 

+1. In TCP, only = “flags” field looks mandatory.

 

-Tiru

 

From: mohamed.boucadair@orange.com= [mailto:mohamed.boucadair@ora= nge.com]
Sent: Friday, February 16, 2018 7:03 = PM
To: Jon Shallow <supjps-ietf@jpshallow.com&g= t;; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; dots@ietf.org
Subject: RE: = [Dots] draft-ietf-dots-data-channel: Filtering = Fields

 

Re-,

 

I tend to agree with you to have to define a minimum = set of mandatory match fields.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Envoy=E9 : vendredi 16 f=E9vrier 2018 = 14:29
=C0 : BOUCADAIR Mohamed IMT/OLN; Konda, = Tirumaleswar Reddy; dots@ietf.org
Objet : = RE: [Dots] draft-ietf-dots-data-channel: Filtering = Fields

 

Hi Med,

 

See inline = [Jon]

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of mohamed.boucadair@orange.com=
Sent: 16 February 2018 12:56
To: Jon Shallow; = 'Konda, Tirumaleswar Reddy'; dots@ietf.org
Subject: Re: = [Dots] draft-ietf-dots-data-channel: Filtering = Fields

 

Jon,

 

Thank you for sharing your thoughts. =

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Envoy=E9 : vendredi 16 f=E9vrier 2018 = 13:24
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR = Mohamed IMT/OLN; dots@ietf.org
Objet : = RE: [Dots] draft-ietf-dots-data-channel: Filtering = Fields

 

I like =
the concept of “+--ro capabilities“ =
allowing for future support as the DOS server becomes more mature in its =
capabilities.
&nb=
sp;
If a =
DOTS client includes a filtering field parameter that is not currently =
supported, should the parameter be ignored (and not returned for a GET), =
or the request rejected?
[Med] I would vote for =
rejecting the request. The client should only use match criteria that =
are understood by the server; otherwise there will be different =
expectation from the service. 
[Jon] I =
think that this is my preference – I was just seeking clarity of =
thinking.
 <=
/pre>
It is =
conceivable that a DOTS client has 2 DOTS servers (one possibly a =
backup, or 2 different ISPs), which may have differing filtering field =
parameter support capabilities.
[Med] The backup/case seems =
odd. I would expect a feature parity for a redundancy group used to =
provide the same service.
=
[Jon] Agreed that =
a backup server is most likely to be from the same manufacturer and =
hence support the same functionality.  But one may have just been =
upgraded to have extra support.
 <=
/pre>
 
<=
pre> 
<=
pre>  =
Adding in intelligence code to work out what is / is not allowed may not =
be practical in a (memory or cpu) constrained environment of the DOTS =
client.
[Med] Fair. =

&nb=
sp;
That =
said, I think we need to define the minimum set of supported parameters =
– e.g. protocol, source / dest ports,  source / dest IPv4 =
prefixes, source / dest IPv6 prefixes, fragments and icmp type/code. =

[Jon] =
Any comments?
 <=
/pre>
-Jon
 <=
/pre>
Regards<=
o:p>
&nb=
sp;
Jon
 
From: Dots [mailto: dots-bounces@ietf.org] On =
Behalf Of Konda, Tirumaleswar Reddy
Sent: 16 February 2018 =
10:18
To: mohamed.boucadair@orange.com=
; dots@ietf.org
Subject: Re: =
[Dots] draft-ietf-dots-data-channel: Filtering =
Fields
 
Hi =
Med,
 
Please see inline =
[TR2]
 
From: mohamed.boucadair@orange.com=
 [mailto:mohamed.boucadair@ora=
nge.com] 
Sent: Friday, February 16, 2018 1:45 =
PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond=
a@McAfee.com>; dots@ietf.org
Subject: RE: =
draft-ietf-dots-data-channel: Filtering =
Fields
 
Re-,
 
Please see inline. 
 
Cheers,
Med
 
De : Dots [mailto:dots-bounces@ietf.org] =
De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : =
vendredi 16 f=E9vrier 2018 08:00
=C0 : BOUCADAIR Mohamed =
IMT/OLN; dots@ietf.org
Objet : =
Re: [Dots] draft-ietf-dots-data-channel: Filtering =
Fields
 
From: Dots [mailto:dots-bounces@ietf.org] =
On Behalf Of mohamed.boucadair@orange.com=

Sent: Wednesday, February 14, 2018 1:49 PM
To: =
dots@ietf.org
Subject: =
[Dots] draft-ietf-dots-data-channel: Filtering =
Fields
 
Hi =
all, 
 
As =
agreed during the interim, there are some issues that need fixes in the =
data-channel spec. We would like to hear from the WG to know what to =
record in the document. 
 
Issue =
description: Should we support all of the match fields defined by =
“ietf-packet-fields” or do we need to define a minimum =
supported set? 
 
[TR] I don’t see the need to support all the match =
fields, define a minimum supported set (don’t see the use for =
acl-eth-header-fields for DOTS use cases). =
 
[Med] =
Agree that acl-eth-header-fields aren’t required. The text is =
already clear about this:
 
DOTS implementations MUST support the =
following
   matching criteria: match =
based on the IP header (IPv4 and IPv6),
   match based on the transport =
header (TCP, UDP, and ICMP), and any
   combination =
thereof.
 
The question is whether we =
need to go further and mandate (or not) the support of matching based on =
specific fields: dscp, ecn, ttl,… flow-label, … tcp sequence-number, =
tcp flags, …  
 
[TR2] https://tools.ietf.org/html/draft-ietf-netmod-acl-model-16 uses the feature statements in the =
YANG model allowing vendors to advertise match rules they are capable =
and willing to support but not at the field-level. The problem is router =
implementations today don’t support ACLs with tcp sequence-number, =
acknowledgement-number, window-size etc but support TCP flags. If the =
server could convey the list of match criteria supported, it not only =
allows the client to convey the supported match rules but also allows =
the server in future to advertise the new supported match fields. =
  
 
Would =
it be useful for a client to retrieve the list of match criteria =
supported by a DOTS server? 
 
[TR2] Yes. 
 
-Tiru
 
[TR] The YANG model supported by =
the DOTS server can retrieved by the DOTS client using RESTCONF to =
determine the match criteria supported by the server. =

[Med] =
I’m afraid this is not the same functionality. If we need to allow =
a server to return its supported match criteria, this should be allowed =
by the module. For example, the module may include the following =
(example): 
 
       &=
nbsp;        +--ro =
capabilities
       &=
nbsp;        |  +--ro =
match-header*
       &=
nbsp;        |  =
|       =
identityref
       &=
nbsp;        |  +--ro =
transport-protocols* [protocol-id]
       &=
nbsp;        |  |  +--ro =
protocol-id      =
uint8
       &=
nbsp;        |  |  +--ro =
protocol-name?   string
       &=
nbsp;        |  +--ro =
dscp-support? =
      boolean
<=
span lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Courier =
New";mso-fareast-language:FR'>       &=
nbsp;        |  +--ro =
ecn-support? =
       boolean
=

       &=
nbsp;        |  +--ro =
length-support? =
    boolean
       &=
nbsp;        |  +--ro =
ttl-support? =
       boolean
=

       &=
nbsp;        |  +--ro =
protocol-support?   boolean
 
The client can ask the server to return =
its supported match criteria. The server =
will indicate the exact set of fields it supports. =

 
<=
pre>I’m not expressing a =
preference to have this in the model, but I’m clarifying how it =
would look like. 
 
-Tiru
 
Please comment. =

 
Cheers,
Med
------=_NextPart_000_0255_01D3A741.3911B150-- From nobody Sun Feb 18 02:25:20 2018 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 0FA67126DEE for ; Sun, 18 Feb 2018 02:25:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.33 X-Spam-Level: X-Spam-Status: No, score=-4.33 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 kJclG8BJwmrY for ; Sun, 18 Feb 2018 02:25:15 -0800 (PST) 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 ABAE512025C for ; Sun, 18 Feb 2018 02:25:14 -0800 (PST) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1518949513; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:x-originating-ip: x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: authentication-results:x-microsoft-antispam-prvs: x-exchange-antispam-report-test:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=g EN6WAcs7STo7+MQm2Carpi9AhsX+WbbqJVUtSq39D M=; b=ZfrwtKzHZyYZV7483kIfgBM0vIW9lONO7XMO8P/tSldu GfgiMbsqQqDZ15Xa6MukwVqdykbfGWm+DI7xcVtJuTnoD4kn7n q8YmOTfz24qXmV1PUGZyVAqn4Ps4Y3YH1Rjm06jqp+QJ45xn7l ooV7iPU4ECdNtPagYH4YwHMrxUc= Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 5048_c467_5131418d_e923_4dcb_8e34_680f5c8cc272; Sun, 18 Feb 2018 04:25:12 -0600 Received: from DNVEXUSR1N13.corpzone.internalzone.com (10.44.48.86) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sun, 18 Feb 2018 03:25:12 -0700 Received: from DNVEXUSR1N13.corpzone.internalzone.com (10.44.48.86) by DNVEXUSR1N13.corpzone.internalzone.com (10.44.48.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sun, 18 Feb 2018 03:25:10 -0700 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXUSR1N13.corpzone.internalzone.com (10.44.48.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Sun, 18 Feb 2018 03:25:10 -0700 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (10.44.176.242) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sun, 18 Feb 2018 03:25:10 -0700 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB2406.namprd16.prod.outlook.com (52.132.143.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.18; Sun, 18 Feb 2018 10:25:07 +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.20.0485.024; Sun, 18 Feb 2018 10:25:07 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: [Dots] Call home in the signal channel (was RE: draft-ietf-dots-data-channel: Filter Direction) Thread-Index: AQHTpx4fYQaVBSxJJEC02ounCseemaOm/iRwgAALCoCAAARH0IAAGmGAgALNmfA= Date: Sun, 18 Feb 2018 10:25:07 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A0D3439@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00d201d3a71e$05ead590$11c080b0$@jpshallow.com> <01b401d3a72b$b5a79f10$20f6dd30$@jpshallow.com> <022001d3a73b$09b1c270$1d154750$@jpshallow.com> In-Reply-To: <022001d3a73b$09b1c270$1d154750$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB2406; 7:wVRKPF8HYgg5w5y89RIC/3gwhNyVUqsk1JUmMu77JY8+TmyU8/1W65y/awfEvbjq00sfw75QL1ZWU1JDipdylZdx3374uWwJtOxdFyaRDGZ6L6LTJHxQZhjJ98DFVKXA+5PXwUKFmha0274UXqQIN1wZo/VI1s0F+Z9igiJK7LpJVa2G+/hRsORJmzRhU3HKB0otKrb/ZyLQb9hLN6aruVa+zbLjyqZaayDtcvhpZIvfjbw/7qhqeSLCoucsp6+Z x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 15275775-bda2-457d-8b45-08d576b9e223 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM5PR16MB2406; x-ms-traffictypediagnostic: DM5PR16MB2406: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(18271650672692)(21748063052155)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001056)(6040501)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(3231101)(944501161)(6041288)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123560045)(6072148)(201708071742011); SRVR:DM5PR16MB2406; BCL:0; PCL:0; RULEID:; SRVR:DM5PR16MB2406; x-forefront-prvs: 058707456E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39850400004)(346002)(376002)(366004)(39380400002)(396003)(57704003)(53754006)(189003)(199004)(32952001)(966005)(2201001)(19609705001)(99286004)(3660700001)(561944003)(6116002)(3846002)(790700001)(97736004)(33656002)(68736007)(93886005)(2900100001)(25786009)(7696005)(14454004)(86362001)(80792005)(186003)(8936002)(8676002)(66066001)(81156014)(81166006)(77096007)(6436002)(2950100002)(102836004)(229853002)(7736002)(6246003)(53946003)(105586002)(9686003)(2906002)(6306002)(54896002)(236005)(26005)(106356001)(55016002)(59450400001)(53936002)(53546011)(74316002)(6506007)(3280700002)(110136005)(316002)(2501003)(606006)(478600001)(5660300001)(72206003)(76176011)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB2406; 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) x-microsoft-antispam-message-info: IgdarP3uRTZ2UC833vbayaeq49W28+UR9/EzJdL+O9hJgBG3BSKagZFO7Thnh7/2rfhY0qyFuc/55JTCBFyhbnhiOjv/mHECco2bwXzYUJ3POQP2y0NEvykwVTM6oH1qD1znkYEDlh3rh+jYhAsiCDvABdjiXDTphZpKL61k1RI= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1788CE1A0A541E8CB2C2DEF9EAC90DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 15275775-bda2-457d-8b45-08d576b9e223 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Feb 2018 10:25:07.6394 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB2406 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 <6224> : inlines <6406> : streams <1779327> : uri <2594954> Archived-At: Subject: Re: [Dots] Call home in the signal channel (was RE: draft-ietf-dots-data-channel: Filter Direction) 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: Sun, 18 Feb 2018 10:25:18 -0000 --_000_DM5PR16MB1788CE1A0A541E8CB2C2DEF9EAC90DM5PR16MB1788namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Please see inline [TR3] From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Friday, February 16, 2018 9:00 PM To: Konda, Tirumaleswar Reddy ; mohamed= .boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] Call home in the signal channel (was RE: draft-ietf-dot= s-data-channel: Filter Direction) Hi Tiru, See inline [Jon1]. Regards Jon From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Friday, February 16, 2018 5:33 PM To: Konda, Tirumaleswar Reddy >; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] Call home in the signal channel (was RE: draft-ietf-dot= s-data-channel: Filter Direction) Hi Tiru, The more I think about it, "Call Home" support in either the data or signal= channel makes no real sense for https://tools.ietf.org/html/draft-ietf-dot= s-use-cases-09#section-3.2.1 . The CPE devices don't need to trigger the D= OTS clients to get mitigation in place as it will be the provider who works= this out. [TR] No, the above use case helps the CPE isolate the compromised devices l= aunching DDoS attacks and protect other devices in the local network from g= etting infected. [Jon] OK, so the CPE says to itself "No idea what is going on, but somethin= g bad is happening", so I will call home to the provider for them to work o= ut what is going on and get them to tell me what to do by sending me some A= CLs. [Jon] Did I understand this correctly? [TR2] No, the CPE may not even know if something bad is happening in its ne= twork. The CPE proactively initiates and establishes TLS session with the p= rovider, and simply waits for requests from the provider to tell if there i= s something wrong (It's a long-lived session). Similar technique is also us= ed to manage secure home gateways from cloud managment. [Jon1] OK - a way of registering/saying "I'm here if needed" [TR3] Yes. However, for 3.2.1, the DOTS client will need to make a mitigation request = to initiate the implementing of (previously defined) ACLs using the signal = channel as there will be a high possibility of the outbound pipe running fu= ll. [TR] ACL can be enforced with "activation" type set to "immediate" using t= he DOTS data channel itself. [Jon] Agreed this can be done, but (TCP) will fail if the outgoing pipe is = full and so the ACL cannot be put in place. A signal "mitigate to this tar= get prefix" will get through though and so kill off some of the traffic goi= ng out to the Internet going to the target prefix. [TR2] My understanding is Mirai attacks do not choke the outgoing link in t= he local network, otherwise the home admin can easily detect the bandwidth = hogging devices, rate-limit the traffic/turn-off the devices. The goal is t= o attack a target in some external domain but at the same-time not to disru= pt local services to avoid any remediation. [Jon1] Fair comment. I still think there could be full pipe issues (e.g. b= roken malware not smart enough to limit itself) that we need to think about= / be able to handle. [TR3] Full pipe issues can be easily detected and blocked by the CPE, but t= he home CPE typically will not have the capability to detect attacks at L7 = (e.g. TLS renegotiation attack) and such attacks won't create a full pipe i= ssue in the attackers network. Cheers, -Tiru -Jon1 -Tiru -Jon -Tiru Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 16 February 2018 11:00 To: mohamed.boucadair@orange.com; Jon = Shallow; dots@ietf.org Subject: Re: [Dots] Call home in the signal channel (was RE: draft-ietf-dot= s-data-channel: Filter Direction) For the discussed use case https://tools.ietf.org/html/draft-ietf-dots-use-= cases-09#section-3.2.1, the CPE needs to act as a DOTS server only for the = data channel but not for the signal channel. I don't think signal-channel r= equires call home functionality, what is the use case ? -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 3:49 PM To: Jon Shallow >; Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: Call home in the signal channel (was RE: [Dots] draft-ietf-dots-da= ta-channel: Filter Direction) Hi Jon, I'm changing the title to keep track of signal-channel specific issues. Please use this one to discuss this use case. Thank you. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 16 f=E9vrier 2018 10:57 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org= Objet : RE: [Dots] draft-ietf-dots-data-channel: Filter Direction I understand the concept of call home - which makes good sense to me and rf= c8071 will, if implemented, handle the data channel and "destination" is st= ill where the 'controlled' traffic is flowing to. However, we also need call home in the signal channel. I'm not sure how th= is will be done - do we need a new CoAP Method (e.g. switch roles) - do we = need to define a different port (rfc8071 defines 4336) etc. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 16 February 2018 09:07 To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 2:19 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: draft-ietf-dots-data-channel: Filter Direction Re-, Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 16 f=E9vrier 2018 09:28 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] draft-ietf-dots-data-channel: Filter Direction There is no ambiguity in the roles. The CPE is acting as DOTS server but th= e DOTS server is initiating connection to the DOTS client in the access net= work. [Med] Don't get the last part. The server (CPE) will receive a request from= the network (client) to filter traffic exiting from that CPE. [TR] I mean to use the call home feature discussed in https://tools.ietf.or= g/html/rfc8071, though the CPE is acting as a DOTS server it will initiate = the connection (TLS or DTLS) to the DOTS client in the access network. The = call home feature helps avoid various threats like the DOTS server in the C= PE will not be subjected to DDoS attacks, and reachability is not problem e= ven if the CPE is behind NAT. The DOTS client will convey the black-list filtering in the "out" direction= to block the traffic originating from the DOTS server domain. [Med] Which corresponds to the "DOTS Server to DOTS Client" direction; that= is the DOTS client domain (access network) is the destination. All is fine= so far :) [TR] The direction is "outgoing traffic" whereas for other use cases the di= rection is "incoming traffic". I don't understand what you mean by a "optional" parameter ? [Med] I meant adding a parameter to indicate explicitly the direction. It w= ould be optional because we do already have a default direction. [TR] Okay. -Tiru -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Friday, February 16, 2018 1:24 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction Hi Tiru, There will be an ambiguity in interpreting filters if and only if the same = DOTS agents have to manipulate filters in both directions. As you rightfully mentioned, the bb use case assumes the following: In order to achieve this capability, the telemetry analysis system utilized by the broadband access provider must have DOTS client functionality, and the end-customer CPE devices must have DOTS server functionality. Which means that there is no ambiguity in that case with the current defaul= t direction: "the destination is the DOTS client domain". No matter how roles were negotiated, but as far as each an agent acts as a = client and its peer as a server, things are clear. Of course we can always define an optional parameter for this, but it is pr= eferable to have a case for it. Cheers, Med De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] Envoy=E9 : jeudi 15 f=E9vrier 2018 16:31 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: draft-ietf-dots-data-channel: Filter Direction The filtering rule for outgoing traffic is required for the "Suppression of= outbound DDoS traffic originating from a consumer broadband access network= " use case discussed in https://tools.ietf.org/html/draft-ietf-dots-use-cas= es-09#section-3.2.1. In this use case, the CPE initially acts as a DOTS cli= ent but after the TCP connection is established, reverses its role and acts= as DOTS server (see https://tools.ietf.org/html/rfc8071). The access netwo= rk can then program the CPE using the DOTS data channel to block the DDoS a= ttack traffic originated from the compromised devices in the local customer network. Cheers, -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Wednesday, February 14, 2018 1:49 PM To: dots@ietf.org Subject: [Dots] draft-ietf-dots-data-channel: Filter Direction Hi all, As agreed during the interim, there are some issues that need fixes in the = data-channel spec. We would like to hear from the WG to know what to record= in the document. Issue description: Do we need to support explicit "direction" in filtering = rules ("in"/"out")? That is, do we allow a DOTS client to create filters fo= r both incoming and outgoing traffic? Below a proposal for discussion: - The current default direction is aligned with the nature of DDoS attac= ks targeted by DOTS: i.e. incoming. The DOTS client domain is assumed to be= the destination. No ambiguity so far with such default behavior. - There is no clear use case for the support of outgoing filtering handl= ing in the context of DOTS. - No text change is required to the draft. Any objection? Cheers, Med --_000_DM5PR16MB1788CE1A0A541E8CB2C2DEF9EAC90DM5PR16MB1788namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Please se= e inline [TR3]

 

From:<= /span> Jon Shallow [mailto:s= upjps-ietf@jpshallow.com]
Sent: Friday, February 16, 2018 9:00 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; mohamed.boucadair@orange.com; dots@ietf.org
Subject: RE: [Dots] Call home in the signal channel (was RE: draft-i= etf-dots-data-channel: Filter Direction)

 

Hi Tiru= ,

&n= bsp;

See inl= ine [Jon1].

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

&nbs= p;

From:<= /span> Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Friday, February 16, 2018 5:33 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; mohamed.boucadair@orange.co= m; dots@ietf.org
Subject: RE: [Dots] Call home in the signal channel (was RE: draft-i= etf-dots-data-channel: Filter Direction)

 

Hi Tiru= ,

&n= bsp;

The mor= e I think about it, “Call Home” support in either the data or s= ignal channel makes no real sense for https://tools.iet= f.org/html/draft-ietf-dots-use-cases-09#section-3.2.1 .  The CPE d= evices don’t need to trigger the DOTS clients to get mitigation in place as it will be the provider who works this out.<= o:p>

&nbs= p;

[TR] No, = the above use case helps the CPE isolate the compromised devices launching = DDoS attacks and protect other devices in the local network from getting in= fected.

[Jon] OK, so the CPE says to itself “No idea what is going on, b= ut something bad is happening”, so I will call home to the provider f= or them to work out what is going on and get them to tell me what to do by sending me some ACLs.

[Jon] Did I understand this correctly?

&nbs= p;

[TR2] No,= the CPE may not even know if something bad is happening in its network. Th= e CPE proactively initiates and establishes TLS session with the provider, = and simply waits for requests from the provider to tell if there is something wrong (It’s a long-lived sess= ion). Similar technique is also used to manage secure home gateways from cl= oud managment.

[Jon1] OK – a way of registering/saying “I’m here if= needed”

&nbs= p;

[TR3] Yes= .

&nbs= p;

&nbs= p;

However, = for 3.2.1, the DOTS client will need to make a mitigation request to initia= te the implementing of (previously defined) ACLs using the signal channel a= s there will be a high possibility of the outbound pipe running full.

&nbs= p;

[TR] ACL = can be enforced  with “activation” type set to “imme= diate” using the DOTS data channel itself.

[Jon] Agreed this can be done, but (TCP) will fail if the outgoing pip= e is full and so the ACL cannot be put in place.  A signal “miti= gate to this target prefix” will get through though and so kill off some of the traffic going out to the Internet going to the= target prefix.

&nbs= p;

[TR2] My = understanding is Mirai attacks do not choke the outgoing link in the local = network, otherwise the home admin can easily detect the bandwidth hogging d= evices, rate-limit the traffic/turn-off the devices. The goal is to attack a target in some external domain but at= the same-time not to disrupt local services to avoid any remediation.

[Jon1] Fair comment.  I still think there could be full pipe issu= es (e.g. broken malware not smart enough to limit itself) that we need to t= hink about / be able to handle.

&nbs= p;

[TR3] Ful= l pipe issues can be easily detected and blocked by the CPE, but the home C= PE typically will not have the capability to detect attacks at L7 (e.g. TLS= renegotiation attack) and such attacks won’t create a full pipe issue in the attackers network. =

&nbs= p;

Cheers,

-Tiru

 

-Jon1

 

-Tiru

 

-Jon

&nbs= p;

-Tiru

&nbs= p;

Regards

&nbs= p;

Jon

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 16 February 2018 11:00
To: mohamed.boucadai= r@orange.com; Jon Shallow; dots@ietf.org
Subject: Re: [Dots] Call home in the signal channel (was RE: draft-i= etf-dots-data-channel: Filter Direction)

 

For the discussed use case https://tools.ietf.or= g/html/draft-ietf-dots-use-cases-09#section-3.2.1, the CPE needs to act as a DOTS server only for the data channel but not fo= r the signal channel. I don’t think signa= l-channel requires call home functionality, what is the use case ?

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Friday, February 16, 2018 3:49 PM
To: Jon Shallow <sup= jps-ietf@jpshallow.com>; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org
Subject: Call home in the signal channel (was RE: [Dots] draft-ietf-= dots-data-channel: Filter Direction)

 

Hi Jon,

 

I’m changing the title to keep track of = signal-channel specific issues.

 

Please use this one to discuss this use case.<= o:p>

 

Thank you.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : vendredi 16 f=E9vrier 2018 10:57
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; <= a href=3D"mailto:dots@ietf.org"> dots@ietf.org
Objet : RE: [Dots] draft-ietf-dots-data-channel: Filter Directi= on

 

I under= stand the concept of call home – which makes good sense to me and rfc= 8071 will, if implemented, handle the data channel and “destination&#= 8221; is still where the ‘controlled’ traffic is flowing to.

&n= bsp;

However= , we also need call home in the signal channel.  I’m not sure ho= w this will be done – do we need a new CoAP Method (e.g. switch roles= ) – do we need to define a different port (rfc8071 defines 4336) etc.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 16 February 2018 09:07
To: mohamed.boucadai= r@orange.com; dots@ietf.org
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction

 

From:<= /span> mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Friday, February 16, 2018 2:19 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: RE: draft-ietf-dots-data-channel: Filter Direction

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : vendredi 16 f=E9vrier 2018 09:28
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : Re: [Dots] draft-ietf-dots-data-channel: Filter Directi= on

 

There is = no ambiguity in the roles. The CPE is acting as DOTS server but the DOTS se= rver is initiating connection to the DOTS client in the access network.

[Med] Don’t g= et the last part. The server (CPE) will receive a request from the network = (client) to filter traffic exiting from that CPE.

&nbs= p;

[TR] I me= an to use the call home feature discussed in https://tools.ietf.org/html= /rfc8071, though the CPE is acting as a DOTS server it will initiate th= e connection (TLS or DTLS) to the DOTS client in the access network. The ca= ll home feature helps avoid various threats like the DOTS server in the CPE will not be subjected to DDoS atta= cks, and reachability is not problem even if the CPE is behind NAT.

 

The DOTS = client will convey the black-list filtering in the “out” direct= ion to block the traffic originating from the DOTS server domain.

[Med] Which corresp= onds to the “DOTS Server to DOTS Client” direction; that is the= DOTS client domain (access network) is the destination. All is fine so far :)

&nbs= p;

&nbs= p;

[TR] The = direction is “outgoing traffic” whereas for other use cases the= direction is “incoming traffic”.

 

I donR= 17;t understand what you mean by a “optional” parameter ?<= /o:p>

[Med] I meant addin= g a parameter to indicate explicitly the direction. It would be optional be= cause we do already have a default direction.

&nbs= p;

[TR] Okay= .

&nbs= p;

-Tiru

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed= .boucadair@orange.com
Sent: Friday, February 16, 2018 1:24 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction

 

Hi Tiru,

 

There will be an ambiguity in interpreting fil= ters if and only if the same DOTS agents have to manipulate filters in both= directions.

 

As you rightfully mentioned, the bb use case a= ssumes the following:

 

   In order to achieve t= his capability, the telemetry analysis system

   utilized by the broad= band access provider must have DOTS client

   functionality, and th= e end-customer CPE devices must have DOTS server

   functionality.

 

Which means that there is no ambiguity in that= case with the current default direction: “the destination is the DOT= S client domain”.

 

No matter how roles were negotiated, but=
 as far as each an agent acts as a client and its peer as a server, things =
are clear. 
 
Of course we can always define an option=
al parameter for this, but it is preferable to have a case for it.  
 
Cheers,
Med

 

De : Konda, Tirumaleswar Reddy [mailto:Tirumaleswar= Reddy_Konda@McAfee.com]
Envoy=E9 : jeudi 15 f=E9vrier 2018 16:31
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: draft-ietf-dots-data-channel: Filter Direction=

 

The filte= ring rule for outgoing traffic is required for the "Suppression of out= bound DDoS traffic originating from a consumer broadband access network&quo= t; use case discussed in https://tools.ietf.org/html/draft-ietf-dots-use-cases-09#section-3.2.1.= In this use case, the CPE initially acts as a DOTS client but after the TC= P connection is established, reverses its role and acts as DOTS server (see https://tools.ietf.org/html= /rfc8071). The access network can then program the CPE using the DOTS d= ata channel to block the DDoS attack traffic originated from the compromise= d devices in the

local cus= tomer network.

&nbs= p;

Cheers,

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed= .boucadair@orange.com
Sent: Wednesday, February 14, 2018 1:49 PM
To: dots@ietf.org
Subject: [Dots] draft-ietf-dots-data-channel: Filter Direction<= /o:p>

 

Hi all,

 

As agreed during the interim, there are some issues that n= eed fixes in the data-channel spec. We would like to hear from the WG to kn= ow what to record in the document.

 

Issue description: Do we need to support explicit “d= irection” in filtering rules (“in”/“out”)? Th= at is, do we allow a DOTS client to create filters for both incoming and ou= tgoing traffic?

 

Below a proposal for discussion:

– = ;   The current default direction is aligned with the nature of DDoS attacks t= argeted by DOTS: i.e. incoming. The DOTS client domain is assumed to be the= destination. No ambiguity so far with such default behavior.

– = ;   There is no clear use case for the support of outgoing filtering handling = in the context of DOTS.

– = ;   No text change is required to the draft.

 <= /p>

Any objection?

 <= /p>

Cheers,=

Med

 

--_000_DM5PR16MB1788CE1A0A541E8CB2C2DEF9EAC90DM5PR16MB1788namp_-- From nobody Sun Feb 18 13:19:41 2018 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 E7C80126BFD for ; Sun, 18 Feb 2018 13:19:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 Hiyofuc3C8rw for ; Sun, 18 Feb 2018 13:19:38 -0800 (PST) Received: from mx0a-00196b01.pphosted.com (mx0a-00196b01.pphosted.com [67.231.149.170]) (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 0DA3F126BF6 for ; Sun, 18 Feb 2018 13:19:38 -0800 (PST) Received: from pps.filterd (m0096263.ppops.net [127.0.0.1]) by mx0a-00196b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1ILJbwH011480; Sun, 18 Feb 2018 16:19:37 -0500 Received: from nam02-bl2-obe.outbound.protection.outlook.com (mail-bl2nam02lp0082.outbound.protection.outlook.com [207.46.163.82]) by mx0a-00196b01.pphosted.com with ESMTP id 2g76770g8j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 18 Feb 2018 16:19:37 -0500 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=uDqhgKunY63PlqadYmD5vuZUroRft9Fjnm4/2xsQXfk=; b=Ry2k+KsvcchN/9S/9B9pF9ZlvasIBRg6lZ0UfCPYlOvvK34Fj46TRM9TRsXrC4gSOTG8yrycUkiploFxQ1f+JDREov6LROaUwwtEhYpBNZHMyrp9Pg+TaRuD17/a/bBUpMcRisxC8kIh9hYPaeVYgkHrLRVXRt5Ezg5pi6xtugQ= Received: from [172.19.254.103] (184.82.239.49) 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.20.506.18; Sun, 18 Feb 2018 21:19:32 +0000 From: "Roland Dobbins" To: "Konda, Tirumaleswar Reddy" Cc: "Jon Shallow" , mohamed.boucadair@orange.com, dots@ietf.org Date: Mon, 19 Feb 2018 04:19:15 +0700 X-Mailer: MailMate (1.10r5443) Message-ID: <621FB89B-F2BE-40B2-8698-0D9A4A92FD3C@arbor.net> In-Reply-To: References: <787AE7BB302AE849A7480A190F8B93300A0D3439@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00d201d3a71e$05ead590$11c080b0$@jpshallow.com> <01b401d3a72b$b5a79f10$20f6dd30$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Originating-IP: [184.82.239.49] X-ClientProxiedBy: SG2PR06CA0114.apcprd06.prod.outlook.com (2603:1096:1:1d::16) To DM2PR0101MB1039.prod.exchangelabs.com (2a01:111:e400:3c19::28) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: e474001b-36e2-4cc5-e43a-08d577154ecb X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603307)(7153060)(7193020); SRVR:DM2PR0101MB1039; X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 3:xSm7nBorInevZtQv7eSmg+qLM8+hU8Iez1l2HXbHs3AlJKjjBYbnIokzKyZvugxlaUXztRzjtTS8kMc0kiTZekJadTn+LbXi3MwRlPfjAOyHunts/hbT/4N9qaRzCQMV8GN7qugcnw5SGVnj+ec3ShhnRCAAt+QJPsuGqQYPeI/f5/z5l0UwD5piCFdBF7pMSxFM3Lj+hNDEh+6Jfgitvg+QzQfXa17yj1zFdbPWPpr5EFkHb2AycfEROhrLFlEk; 25:P4f1IAK4GoSW6a0H5gnJwq9yTPT9Gr9q3xw6qwgWqoMzpFTP3a027sM6t+eWvjB6dEvQb7vIhRd/QdsSw1g2Vas50CBfCtO2b9BQcdJsFRpwdKgmPeNnJrW5XW8e5WEX9WFn1gGz8f7xF+1YajWQvsMDab9yPYrkcEq6mjb7//bE/k3fHDASe0JQb6vM1PZOtgSTBnYKscZDDSNYqQqdwZ/t4FVw525LPYJi5+3S1MUe4nnJQFKvZtwzOoRfo9zAv369EI901ESE0yaYlPllCr+ra1DFFKAxr314rrFjGq8fD5OfTLPB9OL8dntc1Zq8+1D0PE7NGidrcKdjMkpLTg==; 31:HE4DqLHRrJui0CbPhAMvM1hgJLS8pJ2CG3ZYBo/F/QuzedzR5BlMJa4mJoDnaY1Tr+XpsBbfOrGuTaUyVTMv5ry2QE8X3xnjrlE/2Reti+9eUHXL2slmAujqK8cE/yFgQaqkzImDf0JIG0Mhstkv/0E1NEihX0AUOCo1wK2lVL49d6MteYqdKp9fqWME1rKh3EyrvNgPfJk2u/JZpGev80rSKrlQbBRWzXA7HywUIvc= X-MS-TrafficTypeDiagnostic: DM2PR0101MB1039: X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 20:tO4TP/qr7R8UGIFyjZxX9SwaZoyOu2rYirR7CwHxaufCbgiwcwLxkdBY7NLrV9aO/HxsZfLxpZ/3NAkzOg9KHpu8ahxjgX4mNsKG3Eo5xeGtVeeVHJZL5iyEYtTCSj6AuBmzqi/ovLOVJ9jd+kAaFUW7RTlhqTecD/xssJznkGSSm9gU/vUh5iyrDYz8yd+G6VLAC3FCLMuayHZZNSWxDCECJj3XYlreTYB1urpNL5Yj1e97ldbP+T3Sp8kT+47cSDIc40Vv6OatXnlHbiB7kYDRdJaUnFTNlBOx7+TnVEbBBJ0Pi6iGnbzcdAX4J/Wik1LSwHwfs4rK72jZgjka8g==; 4:gscWcVp0iP4BiE6jeCHcu587X54AECpKDZzBG2UQMZhI7zJWrcVyXudLmx4+zybfzzSSDo3JFJw/zMCv8wrbU3MHSsibuv2lRrBq1//Jlv1Q6t3FLdTQpFEtoh3RMkAgb/RYf88PhsNRldnEn7CwMY7vM3tqlemxEWF/g8Lc9PbAnOjqyB2pv0gosjkOhbOXCkXT8lMQccRT03KnJl7JQMBgcTFKzzVL5wHZRGdTXjJKH4Sk54gZKP76m1Qf+18Q69CKAHZIhZ6K9lrkmOH/YA== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(3231101)(944501161)(93006095)(93001095)(10201501046)(3002001)(6041288)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(6072148)(201708071742011); SRVR:DM2PR0101MB1039; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0101MB1039; X-Forefront-PRVS: 058707456E X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(366004)(39840400004)(346002)(376002)(39380400002)(396003)(199004)(189003)(47776003)(51416003)(67846002)(52116002)(76176011)(316002)(16586007)(16576012)(83716003)(5660300001)(53546011)(386003)(6486002)(93886005)(68736007)(77096007)(26005)(66066001)(53936002)(186003)(86362001)(6346003)(16526019)(82746002)(81156014)(81166006)(8676002)(8936002)(106356001)(25786009)(105586002)(36756003)(305945005)(50466002)(478600001)(4326008)(7736002)(2906002)(6916009)(2950100002)(6666003)(6246003)(229853002)(6116002)(3846002)(33656002)(50226002)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1039; H:[172.19.254.103]; 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:fq9sM68RVdtjXc1YnMxQtMX3vhRy7n+fZIyNsQs?= =?us-ascii?Q?5Yr6lGjI6/vGyfSPpt3LeDbukzxwvgrcjNdMHiAPj1IyYPgzufj8TBD6MpH1?= =?us-ascii?Q?P3KyvCN5X6GclTbNluOkuKVjYlRn08RYx7UT4j8lLPOpqbKXHE9iwKPtM5qu?= =?us-ascii?Q?Gp4qVyB/KdW6++O7fY8qcVQYXAuzx2dhcdp8Ngo9KhKiC2HTTHs1x3ug273G?= =?us-ascii?Q?qmFcFOpn9zld8r9OwEbPMGrxz3wGNCPjNQbXAR39hzq4P1bv3evZccN7g9X4?= =?us-ascii?Q?BPwGJTHK9BCunVLJto+DVeHbZVhfEF35XtI2M073UUc+kO8I/+UBDe5RhIZw?= =?us-ascii?Q?PcDrSkkwaLsTRXyR4i06rKfhDiEdkbIIuZqBq4JCxeTAqG3rzlUb7S3A/Smq?= =?us-ascii?Q?NA55R67nMXzZhAhuhQIooBg+HBOfI4KKFnJM1+CYTAQm8qzqozNmlR+oOPeI?= =?us-ascii?Q?pvlia/12DdEYwunwegsn2gZ83OxBSdas8Ek+3HctXUteOJT0XHcumiMLzcWr?= =?us-ascii?Q?7U8q3p8G857EqfxU8dg7nLomaYvVTz1JJipvYSCihmcQ1yJSbnnVIl6HyS1k?= =?us-ascii?Q?S52HjLTcCPMMkzBP7aMeQ/Ho+ZCriiKIYQieuXA+t8D3jAM8Zvd+3tzJrTqp?= =?us-ascii?Q?JiAKrhAgghQlufqOSXoVzpuvW0oONfMsdamvjt+Qq4y/D5/5R8UEOBrmQ/Xs?= =?us-ascii?Q?YtAEMEDVgjKu8kWNIQc0qc2RqICCSMY0ickH8qHGkwEuGMtVV6QxL0jZsmO9?= =?us-ascii?Q?67MMh70HBwNIJOiXoJO6C+G2+2e6UgQ8vZOGnd3yl/a7PdiiwivY+5VmUWSU?= =?us-ascii?Q?Xk4h9rxrfHNxjexVD4bzAAB42BBC51Z+fV11zTzMLrkRjTK/G/gbqhTjzaKP?= =?us-ascii?Q?39UvLpVG/mKPwW93KLaq1QKe5RuAJifF6kng6HbEq+YkQKvxz6OzL8hPnuW1?= =?us-ascii?Q?b3yNA8kJBzqowlF2ucpCYigHghGcqc2XjSSQ/CN6lViAsdp00FXjuNGLyv4r?= =?us-ascii?Q?ge+HSrxiLeeg/uSuUCRzYKAqRSqniL4CveYblZOwRg9BJVqDefFs7V5o7ead?= =?us-ascii?Q?32szi1DVaVNndQ0sUkh4BlGc8ESmYOpBoJqgT4GfzX28XJJWgfqC/ksPsiYy?= =?us-ascii?Q?57JMSZHNes5nqzWlFqeDXDTOvTQC2XllR4go71ZPnL4nKS1VxHDF1/BNnDhv?= =?us-ascii?Q?l7EX0NMAoUq7v6e6eOZ/wCHUP5K1B+WzijP3Mm1plyJVYXZWQjU0QA5RAT36?= =?us-ascii?Q?p8SefCYFv4q5pJQoWUA8Fk9qbKVd+yiT3z/4136nrIj4ms/I5hmfseC/Mhkb?= =?us-ascii?Q?mZQ=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 6:PbkBQOYjNSZyd5pTDVetVZ9gEPHTwcNmY38hT4nt8YmR0zzmDeoom8IWxxBEljaafmVC/9qim08XB/rqQNQgyIMv/5KIThyhsPt5VpG8Y0YM/5XwWoQRplEQ2egbODbXeITKrsQpA7DS8kIM8R3/I0AeZFAq4+NGoiYnW2sRQ1PV5SHzyf4J2EvEhVkV9krvbVJ6NNN+/ed6JWQkXpcEay5CqpECjj0vmMhtzGOexrQWEwIbPMrbht/h0e/DUI2lrF9hZNkHk1crBRQTMSaqoayv67HybuKypr1J64gsJbUEm+o+PuKqHF2FVsK2AcJYwnZBrVhCn6UMJXoV+sjGvnKY6CMTree/oM5+UjjRNnw=; 5:kqSI/HYeVak/5DbsuVkcXz+dliOZxqUnPIShkRpIF+LmC91PEF1SdaAbGCBAtaNMt37/ekiU/cZHIYeSNH4IuHuSDjwnjACWe4XL0CZW/vcICkCIQMsW/I5CzWNuIGorC+L7j9UMx9ZZJ0FFTrTUBSWkenwObegs3rgEdFjTx+A=; 24:vy4DM5KoY5KJGi3sQl6u+4QvJjcYXlJ/1iHUkbc78TiZr2sxdJbe7zefzomxbr/TLIxCptqUpeBwBXT439/sCWPB9NBbA3xpsm28SQjl6c0=; 7:a5NMtglr8DyBH9o5Re70CL5u/jxmnYDqZqj05KC2OLAsOX31Yv9lIUF84WB6MlJOLuajiIR3hT/zDofnRYvIxVsg4tDWEGO4m93ecs/309scyVG763CmYd928BCK8w1A12pYw9lqiHCbCuN0xpKJ7ij9TxnqGxq+dmS2Y0Jv+gvwoBO78g1iHrdBiGL4giJYYup5KtznXcxhhcmF4rIrvUEIuUVhaQBCvQTtZwFLD+cbmBJMV8nRcVNl1DYnxbP2 SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Feb 2018 21:19:32.7171 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e474001b-36e2-4cc5-e43a-08d577154ecb X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1039 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-18_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=773 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802180289 Archived-At: Subject: Re: [Dots] Call home in the signal channel (was RE: draft-ietf-dots-data-channel: Filter Direction) 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: Sun, 18 Feb 2018 21:19:40 -0000 On 16 Feb 2018, at 21:18, Konda, Tirumaleswar Reddy wrote: > My understanding is Mirai attacks do not choke the outgoing link in > the local network, This depends - but we aren't designing DOTS around any specific botnet, such as Mirai. The specifics of Mirai attack characteristics are irrelevant to this discussion. ----------------------------------- Roland Dobbins From nobody Sun Feb 18 13:19:52 2018 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 BA030126BFD for ; Sun, 18 Feb 2018 13:19:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 Ohd-zGTtYizF for ; Sun, 18 Feb 2018 13:19:45 -0800 (PST) Received: from mx0a-00196b01.pphosted.com (mx0a-00196b01.pphosted.com [67.231.149.170]) (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 EAAFA126BF6 for ; Sun, 18 Feb 2018 13:19:45 -0800 (PST) Received: from pps.filterd (m0072398.ppops.net [127.0.0.1]) by mx0a-00196b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1ILH9A2022290; Sun, 18 Feb 2018 16:19:45 -0500 Received: from nam02-bl2-obe.outbound.protection.outlook.com (mail-bl2nam02lp0079.outbound.protection.outlook.com [207.46.163.79]) by mx0a-00196b01.pphosted.com with ESMTP id 2g7eb183u0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 18 Feb 2018 16:19:45 -0500 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=8tPx6Ud79ykno7yIkZZ/hgn0eC3TtxDK/9guQyij/rI=; b=j7b26sF+vaZNQnc7+J3LYZOMbZCNxz7T/SSpVzOIWqHup3vEocfu4Cj03rW6AGJUjE0dHHlIk0gAMRXsnuCxM/0pzG9IDrKFrkQbpilXLW3JbMiVByh6Bq3klLFT//bmKbp8ukrg6lBsy6IIhSGh0vM0yPVxPBJ/8CBWSKZ4uMM= Received: from [172.19.254.103] (184.82.239.49) 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.20.506.18; Sun, 18 Feb 2018 21:19:42 +0000 From: "Roland Dobbins" To: "Jon Shallow" Cc: "Konda, Tirumaleswar Reddy" , mohamed.boucadair@orange.com, dots@ietf.org Date: Mon, 19 Feb 2018 04:19:41 +0700 X-Mailer: MailMate (1.10r5443) Message-ID: <0536689E-BC0B-4245-8394-E54AC5427472@arbor.net> In-Reply-To: <022001d3a73b$09b1c270$1d154750$@jpshallow.com> References: <787AE7BB302AE849A7480A190F8B93300A0D3439@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00d201d3a71e$05ead590$11c080b0$@jpshallow.com> <01b401d3a72b$b5a79f10$20f6dd30$@jpshallow.com> <022001d3a73b$09b1c270$1d154750$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Originating-IP: [184.82.239.49] X-ClientProxiedBy: SG2PR06CA0114.apcprd06.prod.outlook.com (2603:1096:1:1d::16) To DM2PR0101MB1039.prod.exchangelabs.com (2a01:111:e400:3c19::28) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: c48576ec-a2f3-425a-4024-08d57715545b X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603307)(7153060)(7193020); SRVR:DM2PR0101MB1039; X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 3:w9ZTHBbvlWkaBxrwvntiuvKyoAde1EB5Xc4kEOsyZBlRCi/sdEVR311JKct+7WNW2Z5cYfw/OO+EtOitj5ymi0nenYVpwgXyPoDhdv2uTjNAmF4lj6PxdBx1QYLODdCOiGD3z5ZobAlDgSqs3/o03zhThTWM2mmbRm/EzPeMhAhwushfBLRT7nza57m5fRa9pqpThvqhru4Gl+a/UHCK+E9g6VMDQQWJnY6Dlk7K9G2YNg4R3WpcjdTaa+i1huHO; 25:jcW+paX4d6QW08NV7boEfm6poYSKyjb3D7VNccCCHh4hxxDPhahq9J9wirNVhhZQUxXdldpI17QBW4yJW/aQcv//A/B5KTYbfx4ysMubrKcuNsSclfEbYKoBKkbE0HL3SuIN7QI+xWP2cAsGBEnJBLd1ESgGGndKlX9/eaB27LkVMnxY9eqMtBz2pKMvrXG2G2E8JQ9y/wgFWeO8n31UwUnnTFa8Ucqy2fcvAlbFPqhpalCWGvWCBI79cRta4ND4Ri3n0O1jW1a+WthL4Kge7jTr71hs9fGB/Z7rjuDlgVGOG0aKclp/2IVA8u9eWS8FsQ7emkCAv/CdrMOS2xYMdw==; 31:P5hw8nCRaEiIARNeVysXlrTmXM0M/umBEYPmn5UJceysmDY75yeqXK7TCEOcMhk84iVey1CiHRB/DcpNySShwr06Fp9XN/61zhhGxQZkBNBd/tsttgNtoopTagtNS6KtHunB3j2o4ivaOI1ep8wwNnguzOofi6ACiIswT8zo8S9+7aOjT3DUfXiRnsNDfaZpwb+4Y1wPMeRlZre48VjBaxxPw70BXTcPICZ6AWQ87lg= X-MS-TrafficTypeDiagnostic: DM2PR0101MB1039: X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 20:ROMT1LBciN40ItKd2p6zh5wJHZXMCDEvMbWaG7DpZJzUPwanq5BUw3TaKeK9lAcVO0FRZveI1NZ7IhVI6/deTsyiicVVJkSb/9gPxX6aWguAhtFJWtS6wwJ3m5xhgynHsm+cRdn1KAXzqM3DjwMDQljvv6E/hD/6iaMGTiW8ZHp8ONMBVpeLkMNRVGiIdPeS6rJcSHlR+3inmAJn2ccsfHjbJqFkI2OYlNUAyjuIDzo9Afmu3oO//X3g38U/FUrt+PSL8mMkLByzIwWdI2YAYLUY6Ds25qpnRH8o+z7oTvjQPWjSj0zta2rv1ffHFFfYlXmudz5HjjSeQpeUSYgzmg==; 4:MsB5I0fMwVHNPApfDofurkIQ8ilgoevpxtLSBZs/jbpmYRyxJm+hx3hG730NGI6KsPOAYM28HYZtjJRlqrws/GH8jJxgxN/0YrbSCfIG6b9xeeDau7nw9fhjlq4Ci1ll0Z2pB0sXoV0G07D5VMuzzZly6flkQhzsUZbq++s+UKdML5dz+Rtc6Co0iAc+IL3vZ7Pt4YWU2aDKPfiGatU2G+pQITYt4Cj/JmS54i/18kqInpl8D9I/WLi8pAMbsnCOznGuZZThOT6LVWAmEaRUhA== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(3231101)(944501161)(93006095)(93001095)(10201501046)(3002001)(6041288)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(6072148)(201708071742011); SRVR:DM2PR0101MB1039; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0101MB1039; X-Forefront-PRVS: 058707456E X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(366004)(39840400004)(346002)(376002)(39380400002)(396003)(199004)(189003)(47776003)(51416003)(67846002)(52116002)(76176011)(316002)(16586007)(16576012)(83716003)(5660300001)(59450400001)(53546011)(386003)(6486002)(93886005)(68736007)(77096007)(26005)(66066001)(53936002)(186003)(86362001)(6346003)(16526019)(82746002)(81156014)(81166006)(8676002)(8936002)(106356001)(25786009)(105586002)(36756003)(305945005)(50466002)(478600001)(4326008)(7736002)(2906002)(6916009)(2950100002)(6246003)(229853002)(6116002)(3846002)(33656002)(50226002)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1039; H:[172.19.254.103]; 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:RD6R3aJdjKj7kF/LQWXQ66S86LRb2ypdx4bfmTE?= =?us-ascii?Q?rXBTqCeRlOQt4C3PTZiA+C3Vt4Lw26ON0SQn0pyBZqq7YBVqU6spoW8XW4Rf?= =?us-ascii?Q?TfwP9Fotv/YvuOHpET2tEj0MHezRXmb5ioOwGZU9+axT3r7uye8IrFR/M+Uj?= =?us-ascii?Q?8fqqlu81Zjz41WC7SB6LoVmgOvHFcBezqWeDP08oYepPrBLt2tC4Pqb4FpB/?= =?us-ascii?Q?cyD5H4BkadNGifRqxGfQt48CDvZwUTiqZpfqeqIuzHDl3fL/UsWP9lMnIqEk?= =?us-ascii?Q?ibECd5AqxJxJeRXKveqbHbHMZt2fs3yJtdI4CV0p12PQazUSRs9Al+AqnBCK?= =?us-ascii?Q?fher+BtAH7vx5AvZ3KMVYmOLYwLS8+F+uP8Nm0JIVuXnFdqyQlmCnIljHI2D?= =?us-ascii?Q?47an/lKBq0mu3wqS07jpxDVBPOXdlL7Zkaafv5K81S/agHBh1gfetevF6gpV?= =?us-ascii?Q?GAfTMsGjuQpnyJbSuHcs7NO43mrMYIKTVdqGIvJmsYCCdb4PJT7aWVZ2zzAt?= =?us-ascii?Q?naS+tSfBjUe+xK8ISdvscm33tED3HMl0YAF8by7Yq7yQ6JCRVp565qCB61O1?= =?us-ascii?Q?pGwLAFrwzGoINYGIND8enmVBThVL7NrewRY/QzyBKq7YKWbdU727OotJeKfx?= =?us-ascii?Q?NTVGbmcre5gIkgvThhcMgxZr36/j3LsOfChMUi8cNNTM+bGq6JduTpB3MtVT?= =?us-ascii?Q?lgK8IKfhoWwlQvrfY2IIL2wtz1FCSLvhyooCKvY9PipZldE7jPPB2SIthtNM?= =?us-ascii?Q?h/SYyaOGxY2L/nPpBi3dLc3CBWFNwyZqtII6RBexSJ3Pvk2fVuTwXMQPWO+m?= =?us-ascii?Q?17TP2fIhNnzQXGbrMNxzP8WDnLR3SW+67TuOS6uEioB1s6vSgSrpoq7z1zlh?= =?us-ascii?Q?4DpNWCAMMXjFLJRL5JsyIZJvKKDgm6SHV2RhLz4O2oKMKDJGb8DRbzWMnVgF?= =?us-ascii?Q?Xp9hFhItuqK7160Ax8nnYAXrQQiAr42NRuD4U9Fghn+JAvVTtklytMGqlzWC?= =?us-ascii?Q?CUmSi4tZwVnr3Cm4+0Giw2u6gPxA4IHcBFlkvlJOUvII/D82/zjBHLVl4WhH?= =?us-ascii?Q?iBDvxZftcn4GOx0KkwjALne1XJjSpbkLIZcBYDhCpR1f+IdTyLbl0I1rqrHI?= =?us-ascii?Q?XGMT0NKuovBpZj5k9f2DCN7E7bOinCgn+YsHpA0a0BBfaoSL7NYE/fGmYqby?= =?us-ascii?Q?w6vqAiGeHZUocQvnlclYw72o+vUvIPZlL1HijJsKdq4rhTOh7NOqKYDcBt/n?= =?us-ascii?Q?t/2endc1trm/AIYnYIPX4s/iTcw+HE59LGSreplvM27Y2+e5ybZ8L26iYREJ?= =?us-ascii?Q?mpg=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 6:+FZh0GnvNOFe7HIaEBf6TAfIWx0ZJj+8kyfRMakyW6XYQSBLgb2mvImVwDJlCfMziu9SukogB+GYMgU1EVQCJjIHyWQacn5TtU0QnjIXvebF3rVOEY36riIV42gD7Q5u3onIcVXcmBQ6qDdNqOCGaVHMUg1jz+GTFxZkcOZLc/sqYv+6TdJB0HIFm/6zRcOmjtRbaIbgEvRpnYP1BnEnubaFh2pSJqtT/4o/RgIHGfsgafa0iATqIVibPNNrl2UFbsL8ernHkc7bcYhlrj6EX1CPbANAY95akhPb4OXIUXI9nHNhDLIlZciXkKUHU9+WcFmOlVzf2vLS7HoyhgYEi7wzzYOq2qJuKapyVeKXQtU=; 5:y5ild1xTJo1/STJUmW/V+1YyW2aXaERzXfCmOeBnSBMr+/b71GbijOkk2cC9PWg+HEPqWr79+fxiBfw5wKze7dXKoul67ZefI57Muqe53Dcq0oEjRZ7mhN6hoDcmunveq2XdTmEo9GhlNgd90o47iTFKv+GscnO495YYrY2t+30=; 24:TKDLIlW08vdR7ntKmDcMfRF1gDCZrEelULefkith+UHT5I8W0I4w5WXDeembnIK4LrrpQ7TuLEig76LXxZE2bg+Ihpo98NkB7A2LQQqsZKc=; 7:DSrAD2L0RzuBDHRCZS6nUJJuDYRpbMCwh+v8YWhhnbdIo6luRBX6NuR7pNUJr1Hc/wGsDBojbYmdRA/TYypSoXcyAx0iFwyJ+nM7SQ8tbAREPmciF525fChwRVMpyMgqUkq1Dnlm7Pu8iOb63n0ibtKD6KHeAl0cNDduHUxDQELQtUQv5kS0OL6S+sRbFmkE2Un5GPrwkdjt7wqpOxJaC/RWKzXHRIdVA8aUeouqJiPtuWT4JgUWH6lLiemaXmBe SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Feb 2018 21:19:42.0453 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c48576ec-a2f3-425a-4024-08d57715545b X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1039 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-18_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=959 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802180289 Archived-At: Subject: Re: [Dots] Call home in the signal channel (was RE: draft-ietf-dots-data-channel: Filter Direction) 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: Sun, 18 Feb 2018 21:19:51 -0000 On 16 Feb 2018, at 22:30, Jon Shallow wrote: > [Jon1] Fair comment. I still think there could be full pipe issues > (e.g. > broken malware not smart enough to limit itself) that we need to think > about > / be able to handle. Correct. ----------------------------------- Roland Dobbins From nobody Sun Feb 18 13:21:20 2018 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 22468126C83 for ; Sun, 18 Feb 2018 13:21:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 mehKhr4NoKwq for ; Sun, 18 Feb 2018 13:21:16 -0800 (PST) Received: from mx0a-00196b01.pphosted.com (mx0a-00196b01.pphosted.com [67.231.149.170]) (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 78E6E126BF6 for ; Sun, 18 Feb 2018 13:21:16 -0800 (PST) Received: from pps.filterd (m0096263.ppops.net [127.0.0.1]) by mx0a-00196b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1ILLGaQ012682; Sun, 18 Feb 2018 16:21:16 -0500 Received: from nam03-co1-obe.outbound.protection.outlook.com (mail-co1nam03lp0015.outbound.protection.outlook.com [216.32.181.15]) by mx0a-00196b01.pphosted.com with ESMTP id 2g76770g9k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 18 Feb 2018 16:21:16 -0500 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=ae49ahgKp4Z5FrxQ86x5rTO2um6KqEcGes3Bl/N8QC0=; b=g4LH9sdpoXFxtiiSXg5s3R25VAbvjYKZMEdgh72gjEbNbBHRaV2cFTKsZ6KA6z0Rbat/EgAm8UHGWeCWQ0SbkDBCZGYEu7+uPSMH38bQ1oHNRl5MBDf7P5mI7PkEORDfMYVv6FL8b/WpVuZSTwHWdvQnGg7lU436eGaa0YdsvrY= Received: from [172.19.254.103] (184.82.239.49) by BY1PR0101MB1030.prod.exchangelabs.com (2a01:111:e400:5005::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.18; Sun, 18 Feb 2018 21:21:11 +0000 From: "Roland Dobbins" To: "Konda, Tirumaleswar Reddy" Cc: "Jon Shallow" , mohamed.boucadair@orange.com, dots@ietf.org Date: Mon, 19 Feb 2018 04:20:54 +0700 X-Mailer: MailMate (1.10r5443) Message-ID: <395E0F43-03F3-46F0-821D-50A53577E5B3@arbor.net> In-Reply-To: References: <787AE7BB302AE849A7480A190F8B93300A0D3439@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00d201d3a71e$05ead590$11c080b0$@jpshallow.com> <01b401d3a72b$b5a79f10$20f6dd30$@jpshallow.com> <022001d3a73b$09b1c270$1d154750$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Originating-IP: [184.82.239.49] X-ClientProxiedBy: SG2PR01CA0086.apcprd01.prod.exchangelabs.com (2603:1096:3:15::12) To BY1PR0101MB1030.prod.exchangelabs.com (2a01:111:e400:5005::27) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 0d15f096-ea0a-48a6-f1f5-08d57715898a X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:BY1PR0101MB1030; X-Microsoft-Exchange-Diagnostics: 1; BY1PR0101MB1030; 3:83hp59+s+Li3bQCyxM9dHbNxTzWAe/eQ+NldFXHibVbq+p310wR3hZ4HUugh/2xE+cTbeoMJmpxaEfxOEDVjbMEsYGdmQs5g1T1S3E3/xTBSiYapNYGP16i8+qfyfdPsRnxv+Sb4czCWA2bD2F+5TwyCmJiR/7bca9sFKXV7cVn1UqrRSOEjfn7o7gZCLmD3nBbpskfVrLf/N0DYv3XjZRNlJgWb+/PGP9F/cY3mpm0ijOngZbCoxQWOvJYX1iJA; 25:n4PcrssCJ9fu+tyMHeGUuIPjrzVZsBRqYNKEQrxhrAOslkf9N98e6afCkBWxJ6fB+v+/DvjIrjp5YxpOA554BpLNC1Yu6Wk+v4vbt+A4MQj7DLOK1CgkrYlgDByCh+sZabZeq4JzW4ign8/uPGFT/GUC7RdQeOkyaP4kUWivjbizpi/agPY3u8tc75NEe9HIqARIXc8ZfAANIR9TxmOMBpItLoC8dWTtPnCVmupMa5B0+4ZuS8bTkGb3d8VVR2HYA8klKktg64cOtrm3Lh4AnpV3h5/HFOQ60pHUiMoc+MyiaPym3R0cbX9a5c1FyT/ZFNVXXkIHdyoBLKtU0HStyA==; 31:9GmEDWwq5lYJpQp4mTXQmtYMbgMCQ3BSB87EwbE9ja13Yj8XBDM93sVruAsnP6yyb+OvsSLsqeubUEQgLBm0vF1QXgrRG2q3zd6YLtegLUizQf7c3qE1aalBu9UrVGFjN7knBbGJTJjchAmTg5wlucZFosFdVLdWzPlUBmCQIeYJwrLMsAa8xd6Tt4a6Y97zKg0+WO9wG6r6oaT3uJ392gxRpjaT/ya8KBwuR1bp4ZU= X-MS-TrafficTypeDiagnostic: BY1PR0101MB1030: X-Microsoft-Exchange-Diagnostics: 1; BY1PR0101MB1030; 20:3T+DtXhLO0DUzfw6uKnay+U+Jo0C0er4K1zvbcFB/kNVZHijhyCCcSiq/6XBuohX+vL1Zi3oHyvJHpJ7r4g/3PafSfWF2fzKRc8FJdRObezSbZVDCKJaYgMq7jZ5YqK0CKqSUM8PVLfZPG5Cj77ieZJsMTvlUjfw3WpbvDDGSVkYY0N0JEnG/9I91UPJNJQDdgRuNBZizce2YbEOJKl/G7aH4jNVa1wKJBQAJqYjIPIb++vxlK63TD5CG+yIWV5Nx2YC9wopzcyaE9izxCX3pWdJ1dGVtUdJj33v452vK5PZ+RLarXck63+LbVWZWhmQl+EIKnqj1EgCfylF+PiQbA==; 4:0O/Dj2k8uq5NsZW3gXthl1v46f0Ijt/Wn0m1JiaFpx7TP6kPl5OENc0TqzJ4JPPR2734plTrkGSEDN/IoDQlQLi0kBg3SEqrSX6onTNk5kPPNJtgP8by5PsHyY9c4cC4Gpd5Pq6wryGv3V3I016lxynNc2bJIYAXf+okuDrggG16A78Bo2lmQaDqf722coNtSndm3KbbIHpCPQFVwUwXMXQzjo1Y9txwK9VqVMnxy1Bim0U7nS6j9aOXAo1EGagOxJZKBwIyjtHEQhdFTFNtGQ== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231101)(944501161)(6041288)(20161123558120)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011); SRVR:BY1PR0101MB1030; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0101MB1030; X-Forefront-PRVS: 058707456E X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(39840400004)(376002)(346002)(396003)(39380400002)(366004)(189003)(199004)(4326008)(82746002)(6116002)(3846002)(67846002)(50466002)(97736004)(33656002)(52116002)(86362001)(25786009)(93886005)(51416003)(68736007)(186003)(8676002)(8936002)(66066001)(81166006)(81156014)(36756003)(47776003)(77096007)(6666003)(2950100002)(6916009)(7736002)(229853002)(6246003)(50226002)(2906002)(105586002)(106356001)(305945005)(386003)(59450400001)(53936002)(53546011)(16586007)(316002)(16576012)(5660300001)(26005)(6486002)(76176011)(478600001)(83716003)(16526019); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0101MB1030; H:[172.19.254.103]; 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; BY1PR0101MB1030; 23:qwMIVxUlU0jLbXc5YM9CSv+Ccb0k4tTu6SlHYKc?= =?us-ascii?Q?CtHoWTK71F6Zr4wuicRq6JVodcsPTgKZYwePBn6mK0TuW0ro8fgVg5JnafOO?= =?us-ascii?Q?VM6tIfNlgdW6T1qbWR0Zn7LhtCekXgn6u4/wbYwwt3d1c4yNvo997PiR+Vfu?= =?us-ascii?Q?72HMk+q1aIDzrAVb/YBN/MHj15zR+lKxCILHGjtyfcIKN6YaPnl2FyHoP9HY?= =?us-ascii?Q?EsCJYX6SO0PPtdAuQRX2eryoaU0I8qM6zjYo9uJkW0ll+12wBCLu2Sf/30T1?= =?us-ascii?Q?Reeu+Dgyb3a02jfO5ZshbvNr9jd5bNRZKdgQ/DSC1J8AUlF4CS2FFGD/Y5RV?= =?us-ascii?Q?3jyaIx8EmPuORUmrOFUPgFPqqhgJqEq/PKpzLGWvZkN6KsoxzkjRMPuEjxdZ?= =?us-ascii?Q?awkISsaankHksuXPA4CXCwK7fRfOjkos/TlO5qbBnDcE1ynyPBlwDMvtP8A3?= =?us-ascii?Q?WFa37hSNDkZR6SQknfstwMAiXv4kGGcdFgvznj14oiKpPeYgiFeYvKCK1ymJ?= =?us-ascii?Q?fPDIpNz+XevKY8A7MJ3Y6nR3QY4AttfWFobUIgvRBxG+nFEvvC5ceTr2Y5I5?= =?us-ascii?Q?+JaRi2G+3+fRWArudydVbCQTcQpxOveg9lgZHLOyzdxJXVs1aEm12B+U9Euj?= =?us-ascii?Q?fZL8eVXwWXVdK5ZPXRo0z8VVYQQacQR/wWZIlBaFb2pc3vS/DB4jzy/Z4Egd?= =?us-ascii?Q?PM7MNoY2AjN9DtgEe+rKySwDnUvTyBo6UFRauqRvckrnZ/xMhMxVC3ongtC+?= =?us-ascii?Q?iLk9/8jv4V56aZU/xndqITrohfoTaLKU9IcMBS7WHv8h48Xn7MpveYAog1xr?= =?us-ascii?Q?PNIJBqKKTfhhO86wkC7+NOlVZBjHq0FrPv83jCWAByy3vf/FkqXToUXFiLNp?= =?us-ascii?Q?FC4PMLRA5FXNdaqm8eetK3kKLmH1XyaXRQL054tiFM3BVrj9NwQQdjyBmIx1?= =?us-ascii?Q?49Ls8UBmh7x69Sv7jeTEoBxNLWrLl04MFQX9pvjYST8WLMSWKqGjg1OXZDz+?= =?us-ascii?Q?k9YxfcmMuHPaIGk0fVH1fhpc79nYVOcuJfCt+F3z5qfvLJL6tgnKPKtMqpDU?= =?us-ascii?Q?2ZYMc+7GDSnJDVyHWPF8hTMl5gLk/Su3nPIQIRuAZ21q5FLLPXddrurNRDZk?= =?us-ascii?Q?ONrLJzLxpzA6ojokD5CZ+1YlxrkxJhA8LfB/ggFpyFBkxtPu2TOkt7iW8F1q?= =?us-ascii?Q?JoY1gcJ0nS1E4wB+DXH97fHMmNXvKI3yZPY98zUKpTQu3mmLGYGbsOUtkRYh?= =?us-ascii?Q?RaTO3vE65+Nl1G4Qkg0wps1re31aGCRWbhB/Wxi12YpZ0Ke+PCHr8u9dA82E?= =?us-ascii?Q?rcw=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY1PR0101MB1030; 6:ywisUQCItBZySSeywkjVYKfRMMn3xfDWm+BIGZTWnvs+s6VaWmrpEdEj51N/Vlcd05gPFBJQihMrq2N47/8wi9AqXN7eHtzteqCJduk343zAeH9ZqGGY5oduauU1l68TYMWAiap6rKdEI9auyuLBU13wZEEq4jdUVr3Ld5UsOiZAeDHrh8E4ppD02ySrKvMlUuzM73hReWpwmLeVaHmXKFEJlj3BhjgqoTDuBqnbSbipB+tfId5tb4FSjXzdnU6ZG+/sPekDhls9lAmMUv3kfyavr2XIXco1KmjUyuCemc9TVAxhiaw1w875imlJmBxqURn9j7Ewgwk/Hu2WFxHlcOQtlR8M7zb6wWMDA8I41ws=; 5:1n6LamSqpCQGHA7kDeOvLa4HpB1POc8R8GOgzA38xOPyHEe9pvkbYPAsnPC5LbF7i/uYGFbFllOHnMLbPjupF7LkIZbQZIKruwxr2BX0Gpm2EvxKqZWFVN4me2Q8GQ130z0wywPPZBn8OsS8unZLSuYavjhpmyTtNpOEUot50gc=; 24:h2r/4feXD8fuxuXmRVJIApJwkY3traWVuvHfSBQ9f39vgkhkRZTBTNgzPJrtsp7SrFCthobMgJlSq1qtnlz9hiDIEyoDms1gsjYPRz1uMCU=; 7:hQc+jEWO6we/1S1m8KyEN33r+8QZA1Awu7u3NIczJQQVpSHdALZpmp8hy+f0s9TeJLYSOtkQH8TrHUtQCF9cl11PPTxOgN0aCAFkkjDhPIsEPkdJxYloW9NRS8y7QUUyKDJQAvCZYQ9axtIRDcKq5H/cipRbOXXfFLl+pgFum+qQPf4jKV04Wte7VDrj9Aajef4TEcZ6cn0pvetLOE2pKOaRMUmOzU6urHmfwm0DMKXtV8WHzaBLIvuOMGuEkBBo SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Feb 2018 21:21:11.4802 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 0d15f096-ea0a-48a6-f1f5-08d57715898a X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0101MB1030 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-18_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802180290 Archived-At: Subject: Re: [Dots] Call home in the signal channel (was RE: draft-ietf-dots-data-channel: Filter Direction) 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: Sun, 18 Feb 2018 21:21:18 -0000 On 18 Feb 2018, at 17:25, Konda, Tirumaleswar Reddy wrote: > [TR3] Full pipe issues can be easily detected and blocked by the CPE, This is incorrect. CPE have zero ability to detect whether the pipe is full, and zero capability to block the traffic in question. ----------------------------------- Roland Dobbins From nobody Sun Feb 18 22:51:02 2018 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 86AED12706D for ; Sun, 18 Feb 2018 22:51:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.331 X-Spam-Level: X-Spam-Status: No, score=-4.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 VBztu1IQM6jE for ; Sun, 18 Feb 2018 22:50:58 -0800 (PST) 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 91E67126C89 for ; Sun, 18 Feb 2018 22:50:58 -0800 (PST) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1519023052; h=From: To:CC:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=YBiDi1g1cEupjG538D6h3+fiUZJZEjHLT4ItQV HZwf8=; b=SMqnjxTblFXqRl+YGrGeaf3p/eskMtxI5hUdWEeX t1k+ozWtfNQQLyO4TVC7nq7Dbq4Maq4XXPOHyFnuTIv/PB2i0j 4B1j6IevHtE3Wsjvdpsbz3CeDwyMUSmiTVVhCq8P1kUaAHwfsu 3KKrn0wDy+VGlbMyORf0vKKnZQPbgok= Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 05c7_a6e5_a89191b4_a557_4f4c_8703_2e3f047cbe8f; Mon, 19 Feb 2018 00:50:51 -0600 Received: from DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sun, 18 Feb 2018 23:50:49 -0700 Received: from DNVEX10N01.corpzone.internalzone.com (10.44.82.192) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Sun, 18 Feb 2018 23:50:49 -0700 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEX10N01.corpzone.internalzone.com (10.44.82.192) with Microsoft SMTP Server (TLS) id 14.3.361.1; Sun, 18 Feb 2018 23:50:49 -0700 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (10.44.176.241) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sun, 18 Feb 2018 23:50:49 -0700 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB2359.namprd16.prod.outlook.com (52.132.142.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.18; Mon, 19 Feb 2018 06:50:47 +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.20.0506.021; Mon, 19 Feb 2018 06:50:47 +0000 From: "Konda, Tirumaleswar Reddy" To: Roland Dobbins CC: Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: [Dots] Call home in the signal channel (was RE: draft-ietf-dots-data-channel: Filter Direction) Thread-Index: AQHTpx4fYQaVBSxJJEC02ounCseemaOm/iRwgAALCoCAAARH0IADoJCAgACaEoA= Date: Mon, 19 Feb 2018 06:50:47 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A0D3439@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00d201d3a71e$05ead590$11c080b0$@jpshallow.com> <01b401d3a72b$b5a79f10$20f6dd30$@jpshallow.com> <621FB89B-F2BE-40B2-8698-0D9A4A92FD3C@arbor.net> In-Reply-To: <621FB89B-F2BE-40B2-8698-0D9A4A92FD3C@arbor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action 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; DM5PR16MB2359; 7:vkSvbYL/+4/tK40h/IzCNNjySGZsGyTcMX9d9hasCeHWA5sPSghV6hM+TpwR7hqSiFV/Rwwsy610xxnLefev52QA8FtfR+NdrYoTZpoCLdMFElYKGYJ3TCRRwbuh5l8ZSDihQeWQ+3vWokOfBjUA90l/3All2Q8rx2OJjyktqxUMo2DVNpgkDnh3eBZRvAqYCWIA90qFzQf+6spk42F+1aLYLA5Z/uYNZ4zOGASIro5HI2khdMPCA4HCwGXH/yge x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: db58585f-48de-42dd-4ce8-08d577651b44 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM5PR16MB2359; x-ms-traffictypediagnostic: DM5PR16MB2359: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(18271650672692)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001056)(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3231101)(944501161)(3002001)(6041288)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(6072148)(201708071742011); SRVR:DM5PR16MB2359; BCL:0; PCL:0; RULEID:; SRVR:DM5PR16MB2359; x-forefront-prvs: 0588B2BD96 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39380400002)(346002)(396003)(39850400004)(366004)(32952001)(199004)(189003)(13464003)(76176011)(77096007)(186003)(6306002)(3280700002)(3660700001)(68736007)(55016002)(26005)(6506007)(59450400001)(97736004)(2950100002)(102836004)(9686003)(2906002)(229853002)(6916009)(6116002)(86362001)(53546011)(3846002)(6436002)(66066001)(2900100001)(99286004)(93886005)(74316002)(305945005)(5660300001)(33656002)(7736002)(7696005)(80792005)(53936002)(106356001)(81166006)(81156014)(966005)(316002)(8676002)(6246003)(14454004)(478600001)(72206003)(25786009)(54906003)(8936002)(4326008)(105586002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB2359; 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) x-microsoft-antispam-message-info: u9iMPH2qGviI0hTUi8juOrpp89x/fhnKPSQumUoNt2Zg1kv0rtT6Hdr3/dEIWVB9q/VxB+O5Bbsb9b00ztRnyLngwSrS30/P8huEHkuM2YxtmsQLw3NyxYz3RtqbT/K7HJyIV211vs5SrRbM7rlKub1boxEpo4HObyuEE4T0zmg= 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-Network-Message-Id: db58585f-48de-42dd-4ce8-08d577651b44 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2018 06:50:47.5031 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB2359 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 <6224> : inlines <6406> : streams <1779407> : uri <2595436> Archived-At: Subject: Re: [Dots] Call home in the signal channel (was RE: draft-ietf-dots-data-channel: Filter Direction) 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, 19 Feb 2018 06:51:00 -0000 > -----Original Message----- > From: Roland Dobbins [mailto:rdobbins@arbor.net] > Sent: Monday, February 19, 2018 2:49 AM > To: Konda, Tirumaleswar Reddy > Cc: Jon Shallow ; > mohamed.boucadair@orange.com; dots@ietf.org > Subject: Re: [Dots] Call home in the signal channel (was RE: draft-ietf-d= ots- > data-channel: Filter Direction) >=20 > On 16 Feb 2018, at 21:18, Konda, Tirumaleswar Reddy wrote: >=20 > > My understanding is Mirai attacks do not choke the outgoing link in > > the local network, >=20 > This depends - but we aren't designing DOTS around any specific botnet, > such as Mirai. >=20 > The specifics of Mirai attack characteristics are irrelevant to this disc= ussion. Mirai attack is only used as an example. For the use case https://tools.iet= f.org/html/draft-ietf-dots-use-cases-09#section-3.2.1, the discussion is wh= en compromised device in the local network launch DDOS attack on targets in= other domains, whether these compromised devices would saturate outgoing p= ipe in the local network itself ? -Tiru >=20 > ----------------------------------- > Roland Dobbins From nobody Sun Feb 18 23:05:01 2018 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 92149126C89 for ; Sun, 18 Feb 2018 23:05:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.331 X-Spam-Level: X-Spam-Status: No, score=-4.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 46euJ-7Uvazv for ; Sun, 18 Feb 2018 23:04:59 -0800 (PST) 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 131881201FA for ; Sun, 18 Feb 2018 23:04:58 -0800 (PST) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1519023890; h=From: To:CC:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=M2qAnYW/bSfrpmpgsykl5OSxGx33Gpb20zYWxo PhMyo=; b=i/ymDvTLP0TSW480UG6gFXJ5EagDgw/tqhWuw5Ey AiwOAnn+t+pE4a7LPSz3t99B4aBBn0rYtfmS6fZAdYI7t2BdNq /c1nYwHs/2CguyJWM9qs7NA24hrKKd+aaLd9TUaHPRyPEE7NDZ +pC7l4xG4VCf+u65zsGfR6PoyosO9lw= Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 05c7_b76c_c1292cf8_6821_410d_bd04_4bd915f90590; Mon, 19 Feb 2018 01:04:49 -0600 Received: from DNVEXUSR1N11.corpzone.internalzone.com (10.44.48.84) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 19 Feb 2018 00:04:49 -0700 Received: from DNVEXUSR1N14.corpzone.internalzone.com (10.44.48.87) by DNVEXUSR1N11.corpzone.internalzone.com (10.44.48.84) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 19 Feb 2018 00:04:47 -0700 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXUSR1N14.corpzone.internalzone.com (10.44.48.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Mon, 19 Feb 2018 00:04:47 -0700 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 19 Feb 2018 00:04:08 -0700 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB2264.namprd16.prod.outlook.com (52.132.142.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.18; Mon, 19 Feb 2018 07:04:44 +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.20.0506.021; Mon, 19 Feb 2018 07:04:44 +0000 From: "Konda, Tirumaleswar Reddy" To: Roland Dobbins CC: Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: [Dots] Call home in the signal channel (was RE: draft-ietf-dots-data-channel: Filter Direction) Thread-Index: AQHTpx4fYQaVBSxJJEC02ounCseemaOm/iRwgAALCoCAAARH0IAAGmGAgALNmfCAALkMAIAAn1ig Date: Mon, 19 Feb 2018 07:04:44 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A0D3439@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00d201d3a71e$05ead590$11c080b0$@jpshallow.com> <01b401d3a72b$b5a79f10$20f6dd30$@jpshallow.com> <022001d3a73b$09b1c270$1d154750$@jpshallow.com> <395E0F43-03F3-46F0-821D-50A53577E5B3@arbor.net> In-Reply-To: <395E0F43-03F3-46F0-821D-50A53577E5B3@arbor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action 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; DM5PR16MB2264; 7:79Y+lZcmq975prHDTahJP4ippY1J7ToRffmPeKE3jKD/db2PvTuF9yfFaKl7UBonORbmElHEC673uYEB+zWVR+MIJMf/1mDRsGwOnxhNwYaVsKMmT2P1LGM+y37kFnTIBcEdGWJ8nFJXBeF/6kbgS+Tv7SQnI3BV2ASTClYWeJm/mqY0IeRap1X/5+uw4Cm16TDfYxP3TnJ4tq1DB0QYpBrES02/NB/MICcOWqlSBihPsIhKZqLjKmCl8wACp/7t x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: e8272693-d81d-49c1-e0da-08d577670e51 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM5PR16MB2264; x-ms-traffictypediagnostic: DM5PR16MB2264: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(18271650672692)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001056)(6040501)(2401047)(8121501046)(5005006)(3231101)(944501161)(3002001)(10201501046)(93006095)(93001095)(6041288)(20161123558120)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011); SRVR:DM5PR16MB2264; BCL:0; PCL:0; RULEID:; SRVR:DM5PR16MB2264; x-forefront-prvs: 0588B2BD96 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(39380400002)(396003)(346002)(376002)(32952001)(13464003)(189003)(199004)(97736004)(80792005)(316002)(3846002)(93886005)(68736007)(478600001)(6916009)(54906003)(72206003)(2950100002)(76176011)(966005)(53936002)(6306002)(6246003)(106356001)(2900100001)(229853002)(9686003)(33656002)(55016002)(66066001)(3280700002)(8936002)(81166006)(81156014)(8676002)(3660700001)(14454004)(6116002)(6436002)(105586002)(86362001)(2906002)(26005)(4326008)(7696005)(53546011)(102836004)(6506007)(305945005)(74316002)(186003)(77096007)(99286004)(7736002)(25786009)(59450400001)(5660300001)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB2264; 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) x-microsoft-antispam-message-info: NYbuppXmAsk3OTd7Hyq/aHa/StbJSXwERn08IscM1uKiLj4XFkMoF4E9YVMqYMvOlDJI/nsGG8c7FkmyD91xzZ3U8YwZQL4nyDq8W8LwQjb2fqwdn/+e/uQljL2u0HwA1dc/vZgAKmEi74FDkH0rl/5/tsOg1JCKjmFYQZ9bHvg= 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-Network-Message-Id: e8272693-d81d-49c1-e0da-08d577670e51 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2018 07:04:44.6814 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB2264 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 <6224> : inlines <6406> : streams <1779408> : uri <2595443> Archived-At: Subject: Re: [Dots] Call home in the signal channel (was RE: draft-ietf-dots-data-channel: Filter Direction) 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, 19 Feb 2018 07:05:00 -0000 > -----Original Message----- > From: Roland Dobbins [mailto:rdobbins@arbor.net] > Sent: Monday, February 19, 2018 2:51 AM > To: Konda, Tirumaleswar Reddy > Cc: Jon Shallow ; > mohamed.boucadair@orange.com; dots@ietf.org > Subject: Re: [Dots] Call home in the signal channel (was RE: draft-ietf-d= ots- > data-channel: Filter Direction) >=20 > On 18 Feb 2018, at 17:25, Konda, Tirumaleswar Reddy wrote: >=20 > > [TR3] Full pipe issues can be easily detected and blocked by the CPE, >=20 > This is incorrect. CPE have zero ability to detect whether the pipe is f= ull, and > zero capability to block the traffic in question. No, for the use case https://tools.ietf.org/html/draft-ietf-dots-use-cases-= 09#section-3.2.1 CPE will have to be enhanced to act as a DOTS server, supp= ress attack traffic and isolate compromised devices.=20 The discussion is whether DOTS data channel is sufficient to meet the above= use case and if DOTS signal channel is also required ? -Tiru >=20 > ----------------------------------- > Roland Dobbins From nobody Sun Feb 18 23:33:16 2018 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 1AF5E126CBF for ; Sun, 18 Feb 2018 23:33:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 JqJOXzF_A1oH for ; Sun, 18 Feb 2018 23:33:12 -0800 (PST) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81AC41201FA for ; Sun, 18 Feb 2018 23:33:11 -0800 (PST) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 1A6E6A1718; Mon, 19 Feb 2018 08:33:10 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.66]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id E422020057; Mon, 19 Feb 2018 08:33:09 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA1.corporate.adroot.infra.ftgroup ([fe80::95e2:eb4b:3053:fabf%19]) with mapi id 14.03.0382.000; Mon, 19 Feb 2018 08:33:09 +0100 From: To: "Konda, Tirumaleswar Reddy" , "Jon Shallow" , "dots@ietf.org" Thread-Topic: [Dots] draft-ietf-dots-data-channel: Filtering Fields Thread-Index: AdOlbICGgF2MxoHnQied7J+cvW2QAABhQcigAAKnFWAAAuyKQAAGTI4AAAEahwAAASoGAAAAJ8mAAAB6+CAAAZF/MAAB7sFgAIT4tOA= Date: Mon, 19 Feb 2018 07:33:08 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0D42B6@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300A0D1F93@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0D32AE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00e801d3a721$08806d30$19814790$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0D366E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019201d3a72a$1b103b70$5130b250$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0D372A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0D3847@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A0D42B6OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields 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, 19 Feb 2018 07:33:15 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A0D42B6OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Tiru, Thank you. Unless there is an objection, I will add length fields to the table. I know router vendors who support TTL-based ACLs, but I don't think this is= a reason to set TTL as mandatory-to-support for the DOTS case. For example= , if upstream networks enforce policies based on a TTL range, this will hav= e a side effect to filter packets that are destined to a leaf DOTS client d= omain. Cheers, Med De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] Envoy=E9 : vendredi 16 f=E9vrier 2018 16:46 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields We may want to add 1) UDP (length) to the list. It may be useful to block large DNS packe= ts (e.g. DNS amplification attack). 2) In IPv4/IPv6, add length, ttl (https://www.cisco.com/c/en/us/about/= security-center/ttl-expiry-attack.html) to the list. -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 8:04 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields Re-, Here is a tentative list: Header Mandatory Fields ------ -------------------------------------------------------------- IPv4 protocol, source-port-range-or-operator, destination-port- range-or-operator, destination-ipv4-network, source- ipv4-network, and v4-fragments IPv6 protocol, source-port-range-or-operator, destination-port- range-or-operator, destination-ipv4-network, source- ipv4-network,and v6-fragments TCP flags ICMP type and code Please comment/update. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 16 f=E9vrier 2018 14:55 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields +1. In TCP, only "flags" field looks mandatory. -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 7:03 PM To: Jon Shallow >; Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields Re-, I tend to agree with you to have to define a minimum set of mandatory match= fields. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 16 f=E9vrier 2018 14:29 =C0 : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; dots@ietf.org Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields Hi Med, See inline [Jon] Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 16 February 2018 12:56 To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields Jon, Thank you for sharing your thoughts. Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 16 f=E9vrier 2018 13:24 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org= Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields I like the concept of "+--ro capabilities" allowing for future support as t= he DOS server becomes more mature in its capabilities. If a DOTS client includes a filtering field parameter that is not currently= supported, should the parameter be ignored (and not returned for a GET), o= r the request rejected? [Med] I would vote for rejecting the request. The client should only use ma= tch criteria that are understood by the server; otherwise there will be dif= ferent expectation from the service. [Jon] I think that this is my preference - I was just seeking clarity of th= inking. It is conceivable that a DOTS client has 2 DOTS servers (one possibly a bac= kup, or 2 different ISPs), which may have differing filtering field paramet= er support capabilities. [Med] The backup/case seems odd. I would expect a feature parity for a redu= ndancy group used to provide the same service. [Jon] Agreed that a backup server is most likely to be from the same manufa= cturer and hence support the same functionality. But one may have just bee= n upgraded to have extra support. Adding in intelligence code to work out what is / is not allowed may not = be practical in a (memory or cpu) constrained environment of the DOTS clien= t. [Med] Fair. That said, I think we need to define the minimum set of supported parameter= s - e.g. protocol, source / dest ports, source / dest IPv4 prefixes, sourc= e / dest IPv6 prefixes, fragments and icmp type/code. [Jon] Any comments? -Jon Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 16 February 2018 10:18 To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields Hi Med, Please see inline [TR2] From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 1:45 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: draft-ietf-dots-data-channel: Filtering Fields Re-, Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 16 f=E9vrier 2018 08:00 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Wednesday, February 14, 2018 1:49 PM To: dots@ietf.org Subject: [Dots] draft-ietf-dots-data-channel: Filtering Fields Hi all, As agreed during the interim, there are some issues that need fixes in the = data-channel spec. We would like to hear from the WG to know what to record= in the document. Issue description: Should we support all of the match fields defined by "ie= tf-packet-fields" or do we need to define a minimum supported set? [TR] I don't see the need to support all the match fields, define a minimum= supported set (don't see the use for acl-eth-header-fields for DOTS use ca= ses). [Med] Agree that acl-eth-header-fields aren't required. The text is already= clear about this: DOTS implementations MUST support the following matching criteria: match based on the IP header (IPv4 and IPv6), match based on the transport header (TCP, UDP, and ICMP), and any combination thereof. The question is whether we need to go further and mandate (or not) the supp= ort of matching based on specific fields: dscp, ecn, ttl,... flow-label, ..= . tcp sequence-number, tcp flags, ... [TR2] https://tools.ietf.org/html/draft-ietf-netmod-acl-model-16 uses the f= eature statements in the YANG model allowing vendors to advertise match rul= es they are capable and willing to support but not at the field-level. The = problem is router implementations today don't support ACLs with tcp sequenc= e-number, acknowledgement-number, window-size etc but support TCP flags. If= the server could convey the list of match criteria supported, it not only = allows the client to convey the supported match rules but also allows the s= erver in future to advertise the new supported match fields. Would it be useful for a client to retrieve the list of match criteria supp= orted by a DOTS server? [TR2] Yes. -Tiru [TR] The YANG model supported by the DOTS server can retrieved by the DOTS = client using RESTCONF to determine the match criteria supported by the serv= er. [Med] I'm afraid this is not the same functionality. If we need to allow a = server to return its supported match criteria, this should be allowed by th= e module. For example, the module may include the following (example): +--ro capabilities | +--ro match-header* | | identityref | +--ro transport-protocols* [protocol-id] | | +--ro protocol-id uint8 | | +--ro protocol-name? string | +--ro dscp-support? boolean | +--ro ecn-support? boolean | +--ro length-support? boolean | +--ro ttl-support? boolean | +--ro protocol-support? boolean The client can ask the server to return its supported match criteria. The s= erver will indicate the exact set of fields it supports. I'm not expressing a preference to have this in the model, but I'm clarifyi= ng how it would look like. -Tiru Please comment. Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300A0D42B6OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

Thank you.

 

Unless there is an objection, I= will add length fields to the table.

 

I know router vendors who suppo= rt TTL-based ACLs, but I don’t think this is a reason to set TTL as m= andatory-to-support for the DOTS case. For example, if upstream networks enforce policies based on a TTL range, this will have a = side effect to filter packets that are destined to a leaf DOTS client domai= n.

 

Cheers,

Med

 

K= onda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com]
Envoy=E9 : vendredi 16 f=E9vrier 2018 16:46
=C0 : BOUCADAIR Moha= med IMT/OLN; Jon Shallow; dots@ietf.org
Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fiel= ds

 

We may want to add

 

1)      UDP (lengt= h) to the list. It may be useful to block large DNS packets (e.g. DNS ampli= fication attack).

2)      In IPv4/IP= v6, add length, ttl (https://www.cisco.com/c/en/us/about/securi= ty-center/ttl-expiry-attack.html) to the list.

 

-Tiru

 

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Friday, February 16, 2018 8:04 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields

 

Re-,

 

Here is a tentative list:

 

   Header= Mandatory Fields

   ------= --------------------------------------------------------------<= /span>

   IPv4&n= bsp;  protocol, source-port-range-or-operator, destination-port-<= /o:p>

   &= nbsp;      range-or-operator, destination-ipv4-net= work, source-

   &= nbsp;      ipv4-network, and v4-fragments

   IPv6&n= bsp;  protocol, source-port-range-or-operator, destination-port-<= /o:p>

   &= nbsp;      range-or-operator, destination-ipv4-net= work, source-

   &= nbsp;      ipv4-network,and v6-fragments

   TCP&nb= sp;   flags

   ICMP   type and code

 

Please comment/update.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : vendredi 16 f=E9vrier 2018 14:55
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fiel= ds

 

+1. In TCP, only “flags” field looks mandatory.

 

-Tiru

 

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Friday, February 16, 2018 7:03 PM
To: Jon Shallow <sup= jps-ietf@jpshallow.com>; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org
Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields

 

Re-,

 

I tend to agree with you to hav= e to define a minimum set of mandatory match fields.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : vendredi 16 f=E9vrier 2018 14:29
=C0 : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; dots@ietf.org
Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fiel= ds

 

Hi Med,=

&n= bsp;

See inl= ine [Jon]

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 16 February 2018 12:56
To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields

 

Jon,

 

Thank you for sharing your thou= ghts.

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : vendredi 16 f=E9vrier 2018 13:24
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; <= a href=3D"mailto:dots@ietf.org"> dots@ietf.org
Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fiel= ds

 

I like the concept of “+--ro capabilities“ allowing for futu=
re support as the DOS server becomes more mature in its capabilities.<=
/o:p>
 
If a DOTS client includes a filtering field parameter that =
is not currently supported, should the parameter be ignored (and not return=
ed for a GET), or the request rejected?
[Med] I would vote for re=
jecting the request. The client should only use match criteria that are und=
erstood by the server; otherwise there will be different expectation from t=
he service. 
[Jon] I think that this is my preference – I was just=
 seeking clarity of thinking.
<=
o:p> 
It is conceivable that a DOTS client has 2 DOTS servers (on=
e possibly a backup, or 2 different ISPs), which may have differing filteri=
ng field parameter support capabilities.
[Med] The backup/case see=
ms odd. I would expect a feature parity for a redundancy group used to prov=
ide the same service.=

[=
Jon] Agreed that a backup server is most likely to be from the same manufac=
turer and hence support the same functionality.  But one may have just=
 been upgraded to have extra support.
<=
o:p> 
 <=
/pre>

 <=
/pre>

  Adding in intelligence code to work out what is / is=
 not allowed may not be practical in a (memory or cpu) constrained environm=
ent of the DOTS client.


[Med] Fair. 


 


That said, I think we need to define the minimum set of sup=
ported parameters – e.g. protocol, source / dest ports,  source =
/ dest IPv4 prefixes, source / dest IPv6 prefixes, fragments and icmp type/=
code. 


[Jon] Any comments?


<=
o:p> 


-=
Jon


<=
o:p> 


Regards


 


Jon


&n=
bsp;






From:=
 Dots [mailto:
dots-bounces@ietf.org] On B=
ehalf Of
Konda, Tirumaleswar Reddy

Sent: 16 February 2018 10:18

To: mohamed.boucadai=
r@orange.com;
dots@ietf.org

Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields






 


Hi Med,


 


Please see inline [TR2]


 








From:
mohamed.boucadair@orange.co=
m [mailto:mohamed.bouca=
dair@orange.com]


Sent: Friday, February 16, 2018 1:45 PM

To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>;
dots@ietf.org

Subject: RE: draft-ietf-dots-data-channel: Filtering Fields






 


Re-,


 


Please see inline.



 


Cheers,


Med


 








De : Dots [mailto:dots-bounces@ietf.org]
De la part de Konda, Tirumaleswar Reddy

Envoy=E9 : vendredi 16 f=E9vrier 2018 08:00

=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org

Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fiel=
ds






 


From: Dots [mailto:dots-bounces=
@ietf.org]
On Behalf Of mohamed=
.boucadair@orange.com

Sent: Wednesday, February 14, 2018 1:49 PM

To: dots@ietf.org

Subject: [Dots] draft-ietf-dots-data-channel: Filtering Fields<=
/o:p>


 


Hi all,



 


As agreed during the interim, there are som=
e issues that need fixes in the data-channel spec. We would like to hear fr=
om the WG to know what to record in the document.



 


Issue description: Should we support all of=
 the match fields defined by “ietf-packet-fields” or do we need=
 to define a minimum supported set?



 


[TR] I don’t see the need=
 to support all the match fields, define a minimum supported set (don’=
;t see the use for acl-eth-header-fields for DOTS use cases).  


[Med] Agree that acl-eth-header=
-fields aren’t required. The text is already clear about this:


 


DOTS implementation=
s MUST support the following


   matchi=
ng criteria: match based on the IP header (IPv4 and IPv6),


   match =
based on the transport header (TCP, UDP, and ICMP), and any


  
combination thereof.


 


The question is whether w=
e need to go further and mandate (or not) the support of matching based on =
specific fields: dscp, ecn, ttl,… flow-label, … tcp sequence-number, tcp flags, …  


 


[TR2] https=
://tools.ietf.org/html/draft-ietf-netmod-acl-model-16 uses the feature statem=
ents in the YANG model allowing vendors to advertise match rules they are c=
apable and willing to support but not at the field-level. The problem is ro=
uter implementations today don’t support ACLs with tcp sequence-numbe=
r, acknowledgement-number, window-size etc but support TCP flags. If the se=
rver could convey the list of match criteria supported, it not only allows =
the client to convey the supported match rules but also allows the server i=
n future to advertise the new supported match fields.   


 


Would it be useful for a client to retrieve=
 the list of match criteria supported by a DOTS server?



 


[TR2] Yes. 

 


-Tiru


 


[TR] The YANG model supported b=
y the DOTS server can retrieved by the DOTS client using RESTCONF to determ=
ine the match criteria supported by the server.



[Med] I’m afraid this is =
not the same functionality. If we need to allow a server to return its supp=
orted match criteria, this should be allowed by the module.
 For example, the module may include the following (example): 


 


      &=
nbsp;         +--ro capabilitie=
s


      &=
nbsp;         |  +--ro mat=
ch-header*


      &=
nbsp;         |  |  =
     identityref


      &=
nbsp;         |  +--ro tra=
nsport-protocols* [protocol-id]


      &=
nbsp;         |  |  +=
--ro protocol-id      uint8

      &=
nbsp;         |  |  +=
--ro protocol-name?   string


      &=
nbsp;         |  +--ro dsc=
p-support?       boolean

      &=
nbsp;         |  +--ro ecn=
-support?        boolean


      &=
nbsp;         |  +--ro len=
gth-support?     boolean


      &=
nbsp;         |  +--ro ttl=
-support?        boolean


      &=
nbsp;         |  +--ro pro=
tocol-support?   boolean


 


The client can ask the server to retu=
rn its supported match criteria. The server wil=
l indicate the exact set of fields it supports. 

 <=
/pre>

I’m not expressing =
a preference to have this in the model, but I’m clarifying how it wou=
ld look like. 

 


-Tiru


 


Please com=
ment.



 =
;


Cheers,


Med=
<=
/o:p>
--_000_787AE7BB302AE849A7480A190F8B93300A0D42B6OPEXCLILMA3corp_-- From nobody Sun Feb 18 23:33:51 2018 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 5B83412706D for ; Sun, 18 Feb 2018 23:33:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 dUF5LpRPrKUZ for ; Sun, 18 Feb 2018 23:33:49 -0800 (PST) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 9DA3B1201FA for ; Sun, 18 Feb 2018 23:33:48 -0800 (PST) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1519025620; h=From: To:CC:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=1 EarVd+fnqn+Hz5eBoJw00M5MBeLRfi+Wn4gFvbdQ4 c=; b=kyn82xFM4NWC27jl5TNNJyBPOnlTzncRQLseYWMqemM8 eOeVm4dbOLFqBQscPHAFCbL22dbVsJI9PCG91Aae12QeV9flLS sHjjEHlUXtHrROu9kcrR/WuQCD7Gd9ZIzhPv1u2ts9HR65g+p5 RUapy+zqzZlN7bpBZOa/mDwt9wI= Received: from MIVEXAPP1N02.corpzone.internalzone.com (mivexapp1n02.corpzone.internalzone.com [10.48.48.89]) by MIVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 5f45_205a_de37f002_cdb2_4dfb_b834_c515742fbd64; Mon, 19 Feb 2018 01:33:39 -0600 Received: from MIVEXUSR1N02.corpzone.internalzone.com (10.48.48.82) by MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 19 Feb 2018 02:33:22 -0500 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.1347.2; Mon, 19 Feb 2018 02:33:21 -0500 Received: from MIVO365EDGE4.corpzone.internalzone.com (10.48.176.87) by MIVEXUSR1N01.corpzone.internalzone.com (10.48.48.81) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Mon, 19 Feb 2018 02:33:21 -0500 Received: from NAM03-DM3-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.1347.2; Mon, 19 Feb 2018 02:33:20 -0500 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB2358.namprd16.prod.outlook.com (52.132.142.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.18; Mon, 19 Feb 2018 07:33:20 +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.20.0506.021; Mon, 19 Feb 2018 07:33:20 +0000 From: "Konda, Tirumaleswar Reddy" To: Roland Dobbins , Jon Shallow CC: "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: [Dots] Call home in the signal channel (was RE: draft-ietf-dots-data-channel: Filter Direction) Thread-Index: AQHTpx4fYQaVBSxJJEC02ounCseemaOm/iRwgAALCoCAAARH0IAAGmGAgAOGToCAAKU64A== Date: Mon, 19 Feb 2018 07:33:20 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A0D3439@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00d201d3a71e$05ead590$11c080b0$@jpshallow.com> <01b401d3a72b$b5a79f10$20f6dd30$@jpshallow.com> <022001d3a73b$09b1c270$1d154750$@jpshallow.com> <0536689E-BC0B-4245-8394-E54AC5427472@arbor.net> In-Reply-To: <0536689E-BC0B-4245-8394-E54AC5427472@arbor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action 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; DM5PR16MB2358; 7:3lSsJsNOxMqaQhczpkmPBPyI0JIeNBiVayJwCZ1gJAA/DDI/6npTne6Wdb74zX3Vzp2Syc6C0vZcNnglYJh2C5GW8oCI/K9YoQbK6JhxyGNTrkIi51jHX0+QBafSHV5qYd5Y3TZPtgjqMfYLYXq5KLvDiMoMfD0AiLEpv9q9y75hHpvl4XSebIDo6GzYegjun7/9vn6kmm7IBHHJDbgxxEfaaNWGD0YMQC+Ku81/JSl4ps5pitCeTDcerzFiqEdh x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 2f26152b-0fbb-4b66-810b-08d5776b0ccf x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM5PR16MB2358; x-ms-traffictypediagnostic: DM5PR16MB2358: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(18271650672692)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231101)(944501161)(10201501046)(6041288)(20161123562045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011); SRVR:DM5PR16MB2358; BCL:0; PCL:0; RULEID:; SRVR:DM5PR16MB2358; x-forefront-prvs: 0588B2BD96 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39860400002)(39380400002)(366004)(396003)(376002)(32952001)(199004)(189003)(13464003)(76176011)(77096007)(186003)(6306002)(3280700002)(3660700001)(68736007)(55016002)(97736004)(26005)(59450400001)(102836004)(6506007)(9686003)(229853002)(6116002)(86362001)(53546011)(2906002)(3846002)(2950100002)(6436002)(66066001)(2900100001)(99286004)(93886005)(74316002)(305945005)(33656002)(5660300001)(7736002)(80792005)(7696005)(53936002)(106356001)(81156014)(81166006)(966005)(316002)(8676002)(6246003)(14454004)(478600001)(72206003)(54906003)(25786009)(110136005)(8936002)(4326008)(105586002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB2358; 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) x-microsoft-antispam-message-info: CJDfdNwK9L88AxGfLyJffyxWmsb/9ZBQyQAsohujW991ctpbV883dOFJ0KMjtH+wkdGH7vYr5bac/OhnA21AZiXAhJT713JPV/GfDpxV9GXiHMyXCLFGpUpFrWL9X580IhQtIW9/6Gp87cx4AS6B1xt0ornWyQLB8QcNtb4J4tY= 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-Network-Message-Id: 2f26152b-0fbb-4b66-810b-08d5776b0ccf X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2018 07:33:20.1518 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB2358 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 <6224> : inlines <6406> : streams <1779410> : uri <2595456> Archived-At: Subject: Re: [Dots] Call home in the signal channel (was RE: draft-ietf-dots-data-channel: Filter Direction) 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, 19 Feb 2018 07:33:50 -0000 > -----Original Message----- > From: Roland Dobbins [mailto:rdobbins@arbor.net] > Sent: Monday, February 19, 2018 2:50 AM > To: Jon Shallow > Cc: Konda, Tirumaleswar Reddy ; > mohamed.boucadair@orange.com; dots@ietf.org > Subject: Re: [Dots] Call home in the signal channel (was RE: draft-ietf-d= ots- > data-channel: Filter Direction) >=20 > On 16 Feb 2018, at 22:30, Jon Shallow wrote: >=20 > > [Jon1] Fair comment. I still think there could be full pipe issues > > (e.g. > > broken malware not smart enough to limit itself) that we need to think > > about / be able to handle. >=20 > Correct. The brings in additional requirements for the DOTS signal channel to meet t= he use case https://tools.ietf.org/html/draft-ietf-dots-use-cases-09#sectio= n-3.2.1=20 a) Call home functionality is required for the DOTS signal channel, a new p= ort is required (just like RESTCONF Call Home https://tools.ietf.org/html/r= fc8071#section-6). b) The mitigation request will have to convey the source IP addresses (to b= lock and Quarantine compromised devices).=20 Cheers, -Tiru >=20 > ----------------------------------- > Roland Dobbins From nobody Sun Feb 18 23:43:32 2018 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 B24281201FA for ; Sun, 18 Feb 2018 23:43:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 TBI_fYqXCqJ6 for ; Sun, 18 Feb 2018 23:43:26 -0800 (PST) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 E0416126CBF for ; Sun, 18 Feb 2018 23:43:25 -0800 (PST) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1519026186; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=l s3O+24Ca0WhJD1DmWS0bp/g+Vw5hr23jAcsp/MLLu 8=; b=g7W6bxMTug7jJ39oTEi0U9FrLnCNf5envcRR8ME0v5Rb cXqMe+49vudCdx4TjbbpLEs27n3WIJLRekCkUurtLWDF64w8iZ aO0/sYfwjojDiuW4VfFQ72z8Fm3tQxM3DvktLTHTxlMh7UMOiy e/9fc8ZK7bOLTkaDd8ZXEGspsAQ= Received: from MIVEXAPP1N03.corpzone.internalzone.com (unknown [10.48.48.90]) by MIVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 5f45_24b6_112f3bb8_efab_4dab_9b25_9c61c80caa8f; Mon, 19 Feb 2018 01:43:05 -0600 Received: from MIVEXUSR1N02.corpzone.internalzone.com (10.48.48.82) by MIVEXAPP1N03.corpzone.internalzone.com (10.48.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 19 Feb 2018 02:43:04 -0500 Received: from MIVO365EDGE3.corpzone.internalzone.com (10.48.176.86) by MIVEXUSR1N02.corpzone.internalzone.com (10.48.48.82) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Mon, 19 Feb 2018 02:43:04 -0500 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (10.48.176.241) by edge.mcafee.com (10.48.176.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 19 Feb 2018 02:43:03 -0500 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB2405.namprd16.prod.outlook.com (52.132.143.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.18; Mon, 19 Feb 2018 07:43: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.20.0506.021; Mon, 19 Feb 2018 07:43:02 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] draft-ietf-dots-data-channel: Filtering Fields Thread-Index: AdOlbICGgF2MxoHnQied7J+cvW2QAABhQcigAAKnFWAAAuyKQAAGTI4AAAEahwAAASoGAAAAJ8mAAAB6+CAAAZF/MAAB7sFgAIT4tOAAAZCeUA== Date: Mon, 19 Feb 2018 07:43:02 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A0D1F93@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0D32AE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00e801d3a721$08806d30$19814790$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0D366E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019201d3a72a$1b103b70$5130b250$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0D372A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0D3847@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0D42B6@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A0D42B6@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action 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; DM5PR16MB2405; 7:fKwUvj7r7RRbAax5qGq/WcIu7O3vYi10cCM/yrVwczLlUkkek6HMlnA5KYwLJHIDy5XfyOM81MywT8NA65KvAYage52is7wuLmMPbv7joCiTbdifoPWYUSuolpu5ecnSQRShmacUPiqIY8FWaPlXFcutsam3UWmQ39nb3qMc2N3LgQKS4cZLUA6oYCokFyUdzmN71kfn1kGQgO9haaRi3Ssbsq/nrhZGJj8kO9iG9o3bWRakODK9zJds5IdwBpz5 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: e87e1424-c9f8-4b3c-f486-08d5776c67b3 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM5PR16MB2405; x-ms-traffictypediagnostic: DM5PR16MB2405: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(114627819485645)(95692535739014)(18271650672692)(21748063052155)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001056)(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3231101)(944501161)(3002001)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:DM5PR16MB2405; BCL:0; PCL:0; RULEID:; SRVR:DM5PR16MB2405; x-forefront-prvs: 0588B2BD96 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(39860400002)(396003)(346002)(376002)(366004)(32952001)(53754006)(51444003)(57704003)(199004)(189003)(55016002)(236005)(105586002)(9686003)(106356001)(54896002)(6306002)(2906002)(6506007)(53946003)(53546011)(59450400001)(53936002)(74316002)(2950100002)(102836004)(7736002)(6246003)(229853002)(72206003)(76176011)(5660300001)(316002)(3280700002)(110136005)(478600001)(2501003)(606006)(99286004)(790700001)(6116002)(3846002)(33656002)(345774005)(97736004)(19609705001)(966005)(26005)(3660700001)(8936002)(66066001)(8676002)(6436002)(80792005)(81156014)(81166006)(77096007)(2900100001)(14454004)(25786009)(93886005)(7696005)(68736007)(86362001)(186003)(85282002)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB2405; 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) x-microsoft-antispam-message-info: px7R3d182DFLZ+ROVg5HSDkeWycGeRA6OCQqOIaIPIRyx2iW3xE2va+dxuLIsVYWzCnYaKQdFWvQq4irNTT35o7P+M4R+E97GxNznzpZcjWmmFbkk0g5yK22/18AzO0C6FmKR1PGGx4hUrjT4q+Ucfk9Ilk16DFzNUS6TQJ+SKs= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB178855EA4C81A80BB00B013DEAC80DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e87e1424-c9f8-4b3c-f486-08d5776c67b3 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2018 07:43:02.1719 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB2405 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 <6224> : inlines <6406> : streams <1779410> : uri <2595461> Archived-At: Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields 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, 19 Feb 2018 07:43:30 -0000 --_000_DM5PR16MB178855EA4C81A80BB00B013DEAC80DM5PR16MB1788namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Monday, February 19, 2018 1:03 PM To: Konda, Tirumaleswar Reddy ; Jon Sha= llow ; dots@ietf.org Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields Hi Tiru, Thank you. Unless there is an objection, I will add length fields to the table. I know router vendors who support TTL-based ACLs, but I don't think this is= a reason to set TTL as mandatory-to-support for the DOTS case. For example= , if upstream networks enforce policies based on a TTL range, this will hav= e a side effect to filter packets that are destined to a leaf DOTS client d= omain. I did not get the response, what is the side effect ? -Tiru Cheers, Med De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] Envoy=E9 : vendredi 16 f=E9vrier 2018 16:46 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields We may want to add 1) UDP (length) to the list. It may be useful to block large DNS packe= ts (e.g. DNS amplification attack). 2) In IPv4/IPv6, add length, ttl (https://www.cisco.com/c/en/us/about/= security-center/ttl-expiry-attack.html) to the list. -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 8:04 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields Re-, Here is a tentative list: Header Mandatory Fields ------ -------------------------------------------------------------- IPv4 protocol, source-port-range-or-operator, destination-port- range-or-operator, destination-ipv4-network, source- ipv4-network, and v4-fragments IPv6 protocol, source-port-range-or-operator, destination-port- range-or-operator, destination-ipv4-network, source- ipv4-network,and v6-fragments TCP flags ICMP type and code Please comment/update. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 16 f=E9vrier 2018 14:55 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields +1. In TCP, only "flags" field looks mandatory. -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 7:03 PM To: Jon Shallow >; Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields Re-, I tend to agree with you to have to define a minimum set of mandatory match= fields. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 16 f=E9vrier 2018 14:29 =C0 : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; dots@ietf.org Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields Hi Med, See inline [Jon] Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 16 February 2018 12:56 To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields Jon, Thank you for sharing your thoughts. Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 16 f=E9vrier 2018 13:24 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org= Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields I like the concept of "+--ro capabilities" allowing for future support as t= he DOS server becomes more mature in its capabilities. If a DOTS client includes a filtering field parameter that is not currently= supported, should the parameter be ignored (and not returned for a GET), o= r the request rejected? [Med] I would vote for rejecting the request. The client should only use ma= tch criteria that are understood by the server; otherwise there will be dif= ferent expectation from the service. [Jon] I think that this is my preference - I was just seeking clarity of th= inking. It is conceivable that a DOTS client has 2 DOTS servers (one possibly a bac= kup, or 2 different ISPs), which may have differing filtering field paramet= er support capabilities. [Med] The backup/case seems odd. I would expect a feature parity for a redu= ndancy group used to provide the same service. [Jon] Agreed that a backup server is most likely to be from the same manufa= cturer and hence support the same functionality. But one may have just bee= n upgraded to have extra support. Adding in intelligence code to work out what is / is not allowed may not = be practical in a (memory or cpu) constrained environment of the DOTS clien= t. [Med] Fair. That said, I think we need to define the minimum set of supported parameter= s - e.g. protocol, source / dest ports, source / dest IPv4 prefixes, sourc= e / dest IPv6 prefixes, fragments and icmp type/code. [Jon] Any comments? -Jon Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 16 February 2018 10:18 To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields Hi Med, Please see inline [TR2] From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 1:45 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: draft-ietf-dots-data-channel: Filtering Fields Re-, Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 16 f=E9vrier 2018 08:00 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Wednesday, February 14, 2018 1:49 PM To: dots@ietf.org Subject: [Dots] draft-ietf-dots-data-channel: Filtering Fields Hi all, As agreed during the interim, there are some issues that need fixes in the = data-channel spec. We would like to hear from the WG to know what to record= in the document. Issue description: Should we support all of the match fields defined by "ie= tf-packet-fields" or do we need to define a minimum supported set? [TR] I don't see the need to support all the match fields, define a minimum= supported set (don't see the use for acl-eth-header-fields for DOTS use ca= ses). [Med] Agree that acl-eth-header-fields aren't required. The text is already= clear about this: DOTS implementations MUST support the following matching criteria: match based on the IP header (IPv4 and IPv6), match based on the transport header (TCP, UDP, and ICMP), and any combination thereof. The question is whether we need to go further and mandate (or not) the supp= ort of matching based on specific fields: dscp, ecn, ttl,... flow-label, ..= . tcp sequence-number, tcp flags, ... [TR2] https://tools.ietf.org/html/draft-ietf-netmod-acl-model-16 uses the f= eature statements in the YANG model allowing vendors to advertise match rul= es they are capable and willing to support but not at the field-level. The = problem is router implementations today don't support ACLs with tcp sequenc= e-number, acknowledgement-number, window-size etc but support TCP flags. If= the server could convey the list of match criteria supported, it not only = allows the client to convey the supported match rules but also allows the s= erver in future to advertise the new supported match fields. Would it be useful for a client to retrieve the list of match criteria supp= orted by a DOTS server? [TR2] Yes. -Tiru [TR] The YANG model supported by the DOTS server can retrieved by the DOTS = client using RESTCONF to determine the match criteria supported by the serv= er. [Med] I'm afraid this is not the same functionality. If we need to allow a = server to return its supported match criteria, this should be allowed by th= e module. For example, the module may include the following (example): +--ro capabilities | +--ro match-header* | | identityref | +--ro transport-protocols* [protocol-id] | | +--ro protocol-id uint8 | | +--ro protocol-name? string | +--ro dscp-support? boolean | +--ro ecn-support? boolean | +--ro length-support? boolean | +--ro ttl-support? boolean | +--ro protocol-support? boolean The client can ask the server to return its supported match criteria. The s= erver will indicate the exact set of fields it supports. I'm not expressing a preference to have this in the model, but I'm clarifyi= ng how it would look like. -Tiru Please comment. Cheers, Med --_000_DM5PR16MB178855EA4C81A80BB00B013DEAC80DM5PR16MB1788namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

From:<= /span> mohamed.boucadair@ora= nge.com [mailto:mohamed.boucadair@orange.com]
Sent: Monday, February 19, 2018 1:03 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; Jon Shallow <supjps-ietf@jpshallow.com>; dots@ietf.org
Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields

 

Hi Tiru,

 

Thank you.

 

Unless there is an objection, I will add lengt= h fields to the table.

 

I know router vendors who support TTL-based AC= Ls, but I don’t think this is a reason to set TTL as mandatory-to-sup= port for the DOTS case. For example, if upstream networks enforce policies based on a TTL range, this will have a side effect to fil= ter packets that are destined to a leaf DOTS client domain.

 

I did not get the response, what is the side effect = ?

 

-Tiru

 

Cheers,

Med

 

De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com]
Envoy=E9 : vendredi 16 f=E9vrier 2018 16:46
=C0 : BOUCADAIR Moha= med IMT/OLN; Jon Shallow; dots@ietf.org
Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fiel= ds

 

We may wa= nt to add

&nbs= p;

1) &nb= sp;    UDP (length) to the list.= It may be useful to block large DNS packets (e.g. DNS amplification attack= ).

2) &nb= sp;    In IPv4/IPv6, add length,= ttl (https://www.cisco.com/c/en/us/about/security-center/ttl-e= xpiry-attack.html) to the list.

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Friday, February 16, 2018 8:04 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields

 

Re-,

 

Here is a tentative list:

 

   Header Mandatory Fiel= ds

   ------ --------------= ------------------------------------------------

   IPv4   prot= ocol, source-port-range-or-operator, destination-port-

     &nbs= p;    range-or-operator, destination-ipv4-network, source-

     &nbs= p;    ipv4-network, and v4-fragments

   IPv6   prot= ocol, source-port-range-or-operator, destination-port-

     &nbs= p;    range-or-operator, destination-ipv4-network, source-

     &nbs= p;    ipv4-network,and v6-fragments

   TCP   = flags

   ICMP   type and code

 

Please comment/update.

 

Cheers,

Med=

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : vendredi 16 f=E9vrier 2018 14:55
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fiel= ds

 

+1. I= n TCP, only “flags” field looks mandatory.

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Friday, February 16, 2018 7:03 PM
To: Jon Shallow <sup= jps-ietf@jpshallow.com>; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org
Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields

 

Re-,

 

I tend to agree with you to have to define a m= inimum set of mandatory match fields.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : vendredi 16 f=E9vrier 2018 14:29
=C0 : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; dots@ietf.org
Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fiel= ds

 

Hi Med,=

&n= bsp;

See inl= ine [Jon]

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 16 February 2018 12:56
To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields

 

Jon,

 

Thank you for sharing your thoughts.

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : vendredi 16 f=E9vrier 2018 13:24
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; <= a href=3D"mailto:dots@ietf.org"> dots@ietf.org
Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fiel= ds

 

I like the concept of “+=
--ro capabilities“ allowing for future support as t=
he DOS server becomes more mature in its capabilities.

 


If a DOTS client includes a filtering field parameter that =
is not currently supported, should the parameter be ignored (and not return=
ed for a GET), or the request rejected?


[Med] I would vote for re=
jecting the request. The client should only use match criteria that are und=
erstood by the server; otherwise there will be different expectation from t=
he service. 


[Jon] I think that this is my preference – I was just=
 seeking clarity of thinking.


<=
o:p> 


It is conceivable that a DOTS client has 2 DOTS servers (on=
e possibly a backup, or 2 different ISPs), which may have differing filteri=
ng field parameter support capabilities.


[Med] The backup/case see=
ms odd. I would expect a feature parity for a redundancy group used to prov=
ide the same service.=



[=
Jon] Agreed that a backup server is most likely to be from the same manufac=
turer and hence support the same functionality.  But one may have just=
 been upgraded to have extra support.


<=
o:p> 


 <=
/pre>

 <=
/pre>

  Adding in intelligence code to work out what is / is=
 not allowed may not be practical in a (memory or cpu) constrained environm=
ent of the DOTS client.


[Med] Fair. 


 


That said, I think we need to define the minimum set of sup=
ported parameters – e.g. protocol, source / dest ports,  source =
/ dest IPv4 prefixes, source / dest IPv6 prefixes, fragments and icmp type/=
code. 


[Jon] Any comments?


<=
o:p> 


-=
Jon


<=
o:p> 


Regards


 


Jon


&n=
bsp;






From: Dots [mailto:
dots-bounces@ietf.org] On B=
ehalf Of
Konda, Tirumaleswar Reddy

Sent: 16 February 2018 10:18

To: mohamed.boucadai=
r@orange.com;
dots@ietf.org

Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields






 


Hi Med,


&nbs=
p;


Please se=
e inline [TR2]


&nbs=
p;








From:<=
/span>
mohamed.boucadair@orange.co=
m [mailto:mohamed.bouca=
dair@orange.com]


Sent: Friday, February 16, 2018 1:45 PM

To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>;
dots@ietf.org

Subject: RE: draft-ietf-dots-data-channel: Filtering Fields






 


Re-,


 


Please see inline.



 


Cheers,


Med


 








De : Dots [mailto:dots-bounces@ietf.org]
De la part de Konda, Tirumaleswar Reddy

Envoy=E9 : vendredi 16 f=E9vrier 2018 08:00

=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org

Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fiel=
ds






 


From:<=
/span> Dots [mailto:dots-bounces@ietf.org]
On Behalf Of mohamed=
.boucadair@orange.com

Sent: Wednesday, February 14, 2018 1:49 PM

To: dots@ietf.org

Subject: [Dots] draft-ietf-dots-data-channel: Filtering Fields<=
/o:p>


 


Hi all,



 


As agreed during the interim, there are some issues that n=
eed fixes in the data-channel spec. We would like to hear from the WG to kn=
ow what to record in the document.



 


Issue description: Should we support all of the match fiel=
ds defined by “ietf-packet-fields” or do we need to define a mi=
nimum supported set?



 


[TR] I don’t see the need to support all the m=
atch fields, define a minimum supported set (don’t see the use for ac=
l-eth-header-fields for DOTS use cases).  


[Med] Agree that acl-eth-header-fields aren=
217;t required. The text is already clear about this:


 


DOTS implementations MUST support =
the following


   matching criteria: ma=
tch based on the IP header (IPv4 and IPv6),


   match based on the tr=
ansport header (TCP, UDP, and ICMP), and any


  
combination thereof.=



 


The question is whether we need to go fu=
rther and mandate (or not) the support of matching based on specific fields=
: dscp, ecn, ttl,… flow-label, … tcp s=
equence-number, tcp flags, …  <=
/o:p>


 


[TR2] https://tools.ietf.o=
rg/html/draft-ietf-netmod-acl-model-16 uses the feature statements in the YANG model allowin=
g vendors to advertise match rules they are capable and willing to support =
but not at the field-level. The problem is router implementations today don=
’t support ACLs with tcp sequence-number, acknowledgement-number, win=
dow-size etc but support TCP flags. If the server could convey the list of =
match criteria supported, it not only allows the client to convey the suppo=
rted match rules but also allows the server in future to advertise the new =
supported match fields.   


 


Would it be useful for a client to retrieve the list of ma=
tch criteria supported by a DOTS server?



 


[TR2] Yes. 


 


-Tiru


 


[TR] The YANG model supported by the DOTS server can=
 retrieved by the DOTS client using RESTCONF to determine the match criteri=
a supported by the server.



[Med] I’m afraid this is not the same fu=
nctionality. If we need to allow a server to return its supported match cri=
teria, this should be allowed by the module. For example,
 the module may include the following (example): 


 


        &nbs=
p;       +--ro capabilities


        &nbs=
p;       |  +--ro match-header*=



        &nbs=
p;       |  |    &nb=
sp;  identityref


        &nbs=
p;       |  +--ro transport-protocol=
s* [protocol-id]


        &nbs=
p;       |  |  +--ro protocol-i=
d      uint8


        &nbs=
p;       |  |  +--ro protocol-n=
ame?   string


        &nbs=
p;       |  +--ro dscp-support? &nbs=
p;     boolean


        &nbs=
p;       |  +--ro ecn-support?  =
;      boolean


        &nbs=
p;       |  +--ro length-support? &n=
bsp;   boolean


        &nbs=
p;       |  +--ro ttl-support?  =
;      boolean


        &nbs=
p;       |  +--ro protocol-support? =
  boolean


 


The client can ask the server to return its supported match criteria. The server will indicate the =
exact set of fields it supports. 


 


I’m not expressing a preference to=
 have this in the model, but I’m clarifying how it would look like. <=
/span>


 


-Tiru


 


Please comment.



 <=
/p>

Cheers,=



Med
--_000_DM5PR16MB178855EA4C81A80BB00B013DEAC80DM5PR16MB1788namp_-- From nobody Sun Feb 18 23:52:24 2018 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 E738F126B72 for ; Sun, 18 Feb 2018 23:52:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 mWOMAjxiG5MG for ; Sun, 18 Feb 2018 23:52:20 -0800 (PST) Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF0BF1201FA for ; Sun, 18 Feb 2018 23:52:19 -0800 (PST) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 1C0B81C1606; Mon, 19 Feb 2018 08:52:18 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.19]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id EC8CF80068; Mon, 19 Feb 2018 08:52:17 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM44.corporate.adroot.infra.ftgroup ([fe80::b08d:5b75:e92c:a45f%18]) with mapi id 14.03.0382.000; Mon, 19 Feb 2018 08:52:17 +0100 From: To: Jon Shallow , "'Konda, Tirumaleswar Reddy'" , "dots@ietf.org" Thread-Topic: draft-ietf-dots-data-channel: Value and/or Range Thread-Index: AdOpVo4UGaF3iP8sRF6zMQH8hhSSfw== Date: Mon, 19 Feb 2018 07:52:16 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0D42F4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A0D42F4OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: [Dots] draft-ietf-dots-data-channel: Value and/or Range 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, 19 Feb 2018 07:52:23 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A0D42F4OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jon, Good point. Actually, some filtering parameters are worth to be supplied as values or r= anges but the current netmod module does not allow for it. I can cite: =B7 Length fields =B7 TTL Do we need to have value/range supported in the module for these fields? Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 16 f=E9vrier 2018 17:14 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields Ttl is an interesting one. It is not definable as a range, and so if you w= ant to match "ttl lt 16" you are going to have to have 16 ACLs preceding an= y other ACL that does anything else. I would expect that 'ttl' would be done properly as a one of the mitigator = rules, and DOTS does not need to 'hint' it as well. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 16 February 2018 15:46 To: mohamed.boucadair@orange.com; Jon = Shallow; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields We may want to add 1) UDP (length) to the list. It may be useful to block large DNS packe= ts (e.g. DNS amplification attack). 2) In IPv4/IPv6, add length, ttl (https://www.cisco.com/c/en/us/about/= security-center/ttl-expiry-attack.html) to the list. -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 8:04 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields Re-, Here is a tentative list: Header Mandatory Fields ------ -------------------------------------------------------------- IPv4 protocol, source-port-range-or-operator, destination-port- range-or-operator, destination-ipv4-network, source- ipv4-network, and v4-fragments IPv6 protocol, source-port-range-or-operator, destination-port- range-or-operator, destination-ipv4-network, source- ipv4-network,and v6-fragments TCP flags ICMP type and code Please comment/update. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 16 f=E9vrier 2018 14:55 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields +1. In TCP, only "flags" field looks mandatory. -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 7:03 PM To: Jon Shallow >; Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields Re-, I tend to agree with you to have to define a minimum set of mandatory match= fields. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 16 f=E9vrier 2018 14:29 =C0 : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; dots@ietf.org Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields Hi Med, See inline [Jon] Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 16 February 2018 12:56 To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields Jon, Thank you for sharing your thoughts. Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 16 f=E9vrier 2018 13:24 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org= Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields I like the concept of "+--ro capabilities" allowing for future support as t= he DOS server becomes more mature in its capabilities. If a DOTS client includes a filtering field parameter that is not currently= supported, should the parameter be ignored (and not returned for a GET), o= r the request rejected? [Med] I would vote for rejecting the request. The client should only use ma= tch criteria that are understood by the server; otherwise there will be dif= ferent expectation from the service. [Jon] I think that this is my preference - I was just seeking clarity of th= inking. It is conceivable that a DOTS client has 2 DOTS servers (one possibly a bac= kup, or 2 different ISPs), which may have differing filtering field paramet= er support capabilities. [Med] The backup/case seems odd. I would expect a feature parity for a redu= ndancy group used to provide the same service. [Jon] Agreed that a backup server is most likely to be from the same manufa= cturer and hence support the same functionality. But one may have just bee= n upgraded to have extra support. Adding in intelligence code to work out what is / is not allowed may not = be practical in a (memory or cpu) constrained environment of the DOTS clien= t. [Med] Fair. That said, I think we need to define the minimum set of supported parameter= s - e.g. protocol, source / dest ports, source / dest IPv4 prefixes, sourc= e / dest IPv6 prefixes, fragments and icmp type/code. [Jon] Any comments? -Jon Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 16 February 2018 10:18 To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields Hi Med, Please see inline [TR2] From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 1:45 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: draft-ietf-dots-data-channel: Filtering Fields Re-, Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 16 f=E9vrier 2018 08:00 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Wednesday, February 14, 2018 1:49 PM To: dots@ietf.org Subject: [Dots] draft-ietf-dots-data-channel: Filtering Fields Hi all, As agreed during the interim, there are some issues that need fixes in the = data-channel spec. We would like to hear from the WG to know what to record= in the document. Issue description: Should we support all of the match fields defined by "ie= tf-packet-fields" or do we need to define a minimum supported set? [TR] I don't see the need to support all the match fields, define a minimum= supported set (don't see the use for acl-eth-header-fields for DOTS use ca= ses). [Med] Agree that acl-eth-header-fields aren't required. The text is already= clear about this: DOTS implementations MUST support the following matching criteria: match based on the IP header (IPv4 and IPv6), match based on the transport header (TCP, UDP, and ICMP), and any combination thereof. The question is whether we need to go further and mandate (or not) the supp= ort of matching based on specific fields: dscp, ecn, ttl,... flow-label, ..= . tcp sequence-number, tcp flags, ... [TR2] https://tools.ietf.org/html/draft-ietf-netmod-acl-model-16 uses the f= eature statements in the YANG model allowing vendors to advertise match rul= es they are capable and willing to support but not at the field-level. The = problem is router implementations today don't support ACLs with tcp sequenc= e-number, acknowledgement-number, window-size etc but support TCP flags. If= the server could convey the list of match criteria supported, it not only = allows the client to convey the supported match rules but also allows the s= erver in future to advertise the new supported match fields. Would it be useful for a client to retrieve the list of match criteria supp= orted by a DOTS server? [TR2] Yes. -Tiru [TR] The YANG model supported by the DOTS server can retrieved by the DOTS = client using RESTCONF to determine the match criteria supported by the serv= er. [Med] I'm afraid this is not the same functionality. If we need to allow a = server to return its supported match criteria, this should be allowed by th= e module. For example, the module may include the following (example): +--ro capabilities | +--ro match-header* | | identityref | +--ro transport-protocols* [protocol-id] | | +--ro protocol-id uint8 | | +--ro protocol-name? string | +--ro dscp-support? boolean | +--ro ecn-support? boolean | +--ro length-support? boolean | +--ro ttl-support? boolean | +--ro protocol-support? boolean The client can ask the server to return its supported match criteria. The s= erver will indicate the exact set of fields it supports. I'm not expressing a preference to have this in the model, but I'm clarifyi= ng how it would look like. -Tiru Please comment. Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300A0D42F4OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jon,

 

Good point.

 

Actually, some filtering parame= ters are worth to be supplied as values or ranges but the current netmod mo= dule does not allow for it. I can cite:

=B7    &n= bsp;    Length fields

=B7    &n= bsp;    TTL

 

Do we need to have value/range = supported in the module for these fields?

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf= @jpshallow.com]
Envoy=E9 : vendredi 16 f=E9vrier 2018 17:14
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; d= ots@ietf.org
Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fiel= ds

 

Ttl is = an interesting one.  It is not definable as a range, and so if you wan= t to match “ttl lt 16” you are going to have to have 16 ACLs pr= eceding any other ACL that does anything else.

&n= bsp;

I would= expect that ‘ttl’ would be done properly as a one of the mitig= ator rules, and DOTS does not need to ‘hint’ it as well.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 16 February 2018 15:46
To: mohamed.boucadai= r@orange.com; Jon Shallow; dots@ietf.org
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields

 

We may want to add

 

1)      UDP (lengt= h) to the list. It may be useful to block large DNS packets (e.g. DNS ampli= fication attack).

2)      In IPv4/IP= v6, add length, ttl (https://www.cisco.com/c/en/us/about/securi= ty-center/ttl-expiry-attack.html) to the list.

 

-Tiru

 

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Friday, February 16, 2018 8:04 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields

 

Re-,

 

Here is a tentative list:

 

   Header= Mandatory Fields

   ------= --------------------------------------------------------------<= /span>

   IPv4&n= bsp;  protocol, source-port-range-or-operator, destination-port-<= /o:p>

   &= nbsp;      range-or-operator, destination-ipv4-net= work, source-

   &= nbsp;      ipv4-network, and v4-fragments

   IPv6&n= bsp;  protocol, source-port-range-or-operator, destination-port-<= /o:p>

   &= nbsp;      range-or-operator, destination-ipv4-net= work, source-

   &= nbsp;      ipv4-network,and v6-fragments

   TCP&nb= sp;   flags

   ICMP   type and code

 

Please comment/update.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : vendredi 16 f=E9vrier 2018 14:55
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fiel= ds

 

+1. In TCP, only “flags” field looks mandatory.

 

-Tiru

 

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Friday, February 16, 2018 7:03 PM
To: Jon Shallow <sup= jps-ietf@jpshallow.com>; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org
Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields

 

Re-,

 

I tend to agree with you to hav= e to define a minimum set of mandatory match fields.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : vendredi 16 f=E9vrier 2018 14:29
=C0 : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; dots@ietf.org
Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fiel= ds

 

Hi Med,=

&n= bsp;

See inl= ine [Jon]

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 16 February 2018 12:56
To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields

 

Jon,

 

Thank you for sharing your thou= ghts.

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : vendredi 16 f=E9vrier 2018 13:24
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; <= a href=3D"mailto:dots@ietf.org"> dots@ietf.org
Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fiel= ds

 

I like the concept of “+--ro capabilities“ allowing for futu=
re support as the DOS server becomes more mature in its capabilities.<=
/o:p>
 
If a DOTS client includes a filtering field parameter that =
is not currently supported, should the parameter be ignored (and not return=
ed for a GET), or the request rejected?
[Med] I would vote for re=
jecting the request. The client should only use match criteria that are und=
erstood by the server; otherwise there will be different expectation from t=
he service. 
[Jon] I think that this is my preference – I was just=
 seeking clarity of thinking.
<=
o:p> 
It is conceivable that a DOTS client has 2 DOTS servers (on=
e possibly a backup, or 2 different ISPs), which may have differing filteri=
ng field parameter support capabilities.
[Med] The backup/case see=
ms odd. I would expect a feature parity for a redundancy group used to prov=
ide the same service.=

[=
Jon] Agreed that a backup server is most likely to be from the same manufac=
turer and hence support the same functionality.  But one may have just=
 been upgraded to have extra support.
<=
o:p> 
 <=
/pre>

 <=
/pre>

  Adding in intelligence code to work out what is / is=
 not allowed may not be practical in a (memory or cpu) constrained environm=
ent of the DOTS client.


[Med] Fair. 


 


That said, I think we need to define the minimum set of sup=
ported parameters – e.g. protocol, source / dest ports,  source =
/ dest IPv4 prefixes, source / dest IPv6 prefixes, fragments and icmp type/=
code. 


[Jon] Any comments?


<=
o:p> 


-=
Jon


<=
o:p> 


Regards


 


Jon


&n=
bsp;






From:=
 Dots [mailto:
dots-bounces@ietf.org] On B=
ehalf Of
Konda, Tirumaleswar Reddy

Sent: 16 February 2018 10:18

To: mohamed.boucadai=
r@orange.com;
dots@ietf.org

Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields






 


Hi Med,


 


Please see inline [TR2]


 








From:
mohamed.boucadair@orange.co=
m [mailto:mohamed.bouca=
dair@orange.com]


Sent: Friday, February 16, 2018 1:45 PM

To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>;
dots@ietf.org

Subject: RE: draft-ietf-dots-data-channel: Filtering Fields






 


Re-,


 


Please see inline.



 


Cheers,


Med


 








De : Dots [mailto:dots-bounces@ietf.org]
De la part de Konda, Tirumaleswar Reddy

Envoy=E9 : vendredi 16 f=E9vrier 2018 08:00

=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org

Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fiel=
ds






 


From: Dots [mailto:dots-bounces=
@ietf.org]
On Behalf Of mohamed=
.boucadair@orange.com

Sent: Wednesday, February 14, 2018 1:49 PM

To: dots@ietf.org

Subject: [Dots] draft-ietf-dots-data-channel: Filtering Fields<=
/o:p>


 


Hi all,



 


As agreed during the interim, there are som=
e issues that need fixes in the data-channel spec. We would like to hear fr=
om the WG to know what to record in the document.



 


Issue description: Should we support all of=
 the match fields defined by “ietf-packet-fields” or do we need=
 to define a minimum supported set?



 


[TR] I don’t see the need=
 to support all the match fields, define a minimum supported set (don’=
;t see the use for acl-eth-header-fields for DOTS use cases).  


[Med] Agree that acl-eth-header=
-fields aren’t required. The text is already clear about this:


 


DOTS implementation=
s MUST support the following


   matchi=
ng criteria: match based on the IP header (IPv4 and IPv6),


   match =
based on the transport header (TCP, UDP, and ICMP), and any


  
combination thereof.


 


The question is whether w=
e need to go further and mandate (or not) the support of matching based on =
specific fields: dscp, ecn, ttl,… flow-label, … tcp sequence-number, tcp flags, …  


 


[TR2] https=
://tools.ietf.org/html/draft-ietf-netmod-acl-model-16 uses the feature statem=
ents in the YANG model allowing vendors to advertise match rules they are c=
apable and willing to support but not at the field-level. The problem is ro=
uter implementations today don’t support ACLs with tcp sequence-numbe=
r, acknowledgement-number, window-size etc but support TCP flags. If the se=
rver could convey the list of match criteria supported, it not only allows =
the client to convey the supported match rules but also allows the server i=
n future to advertise the new supported match fields.   


 


Would it be useful for a client to retrieve=
 the list of match criteria supported by a DOTS server?



 


[TR2] Yes. 

 


-Tiru


 


[TR] The YANG model supported b=
y the DOTS server can retrieved by the DOTS client using RESTCONF to determ=
ine the match criteria supported by the server.



[Med] I’m afraid this is =
not the same functionality. If we need to allow a server to return its supp=
orted match criteria, this should be allowed by the module.
 For example, the module may include the following (example): 


 


      &=
nbsp;         +--ro capabilitie=
s


      &=
nbsp;         |  +--ro mat=
ch-header*


      &=
nbsp;         |  |  =
     identityref


      &=
nbsp;         |  +--ro tra=
nsport-protocols* [protocol-id]


      &=
nbsp;         |  |  +=
--ro protocol-id      uint8

      &=
nbsp;         |  |  +=
--ro protocol-name?   string


      &=
nbsp;         |  +--ro dsc=
p-support?       boolean

      &=
nbsp;         |  +--ro ecn=
-support?        boolean


      &=
nbsp;         |  +--ro len=
gth-support?     boolean


      &=
nbsp;         |  +--ro ttl=
-support?        boolean


      &=
nbsp;         |  +--ro pro=
tocol-support?   boolean


 


The client can ask the server to retu=
rn its supported match criteria. The server wil=
l indicate the exact set of fields it supports. 

 <=
/pre>

I’m not expressing =
a preference to have this in the model, but I’m clarifying how it wou=
ld look like. 

 


-Tiru


 


Please com=
ment.



 =
;


Cheers,


Med=
<=
/o:p>
--_000_787AE7BB302AE849A7480A190F8B93300A0D42F4OPEXCLILMA3corp_-- From nobody Sun Feb 18 23:59:07 2018 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 741DD127058 for ; Sun, 18 Feb 2018 23:59:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 racxoWJBgYuW for ; Sun, 18 Feb 2018 23:59:02 -0800 (PST) Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D2CA1201FA for ; Sun, 18 Feb 2018 23:59:02 -0800 (PST) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id B16B0C0554; Mon, 19 Feb 2018 08:59:00 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.58]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 8522812006B; Mon, 19 Feb 2018 08:59:00 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM33.corporate.adroot.infra.ftgroup ([fe80::3881:fc15:b4b2:9017%19]) with mapi id 14.03.0382.000; Mon, 19 Feb 2018 08:59:00 +0100 From: To: "Konda, Tirumaleswar Reddy" , "Jon Shallow" , "dots@ietf.org" Thread-Topic: [Dots] draft-ietf-dots-data-channel: Filtering Fields Thread-Index: AdOlbICGgF2MxoHnQied7J+cvW2QAABhQcigAAKnFWAAAuyKQAAGTI4AAAEahwAAASoGAAAAJ8mAAAB6+CAAAZF/MAAB7sFgAIT4tOAAAZCeUAAAd3cg Date: Mon, 19 Feb 2018 07:58:59 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0D4309@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300A0D1F93@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0D32AE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00e801d3a721$08806d30$19814790$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0D366E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019201d3a72a$1b103b70$5130b250$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0D372A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0D3847@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0D42B6@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A0D4309OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields 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, 19 Feb 2018 07:59:05 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A0D4309OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, The (positive) side effect is that the leaf network will be protected becau= se of the filters enforced at the upstream network. In other words, TTL-bas= ed filters issued by the leaf network may be redundant with the ones enforc= ed by the upstream network. Cheers, Med De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] Envoy=E9 : lundi 19 f=E9vrier 2018 08:43 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Monday, February 19, 2018 1:03 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields Hi Tiru, Thank you. Unless there is an objection, I will add length fields to the table. I know router vendors who support TTL-based ACLs, but I don't think this is= a reason to set TTL as mandatory-to-support for the DOTS case. For example= , if upstream networks enforce policies based on a TTL range, this will hav= e a side effect to filter packets that are destined to a leaf DOTS client d= omain. I did not get the response, what is the side effect ? -Tiru Cheers, Med De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] Envoy=E9 : vendredi 16 f=E9vrier 2018 16:46 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields We may want to add 1) UDP (length) to the list. It may be useful to block large DNS packe= ts (e.g. DNS amplification attack). 2) In IPv4/IPv6, add length, ttl (https://www.cisco.com/c/en/us/about/= security-center/ttl-expiry-attack.html) to the list. -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 8:04 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields Re-, Here is a tentative list: Header Mandatory Fields ------ -------------------------------------------------------------- IPv4 protocol, source-port-range-or-operator, destination-port- range-or-operator, destination-ipv4-network, source- ipv4-network, and v4-fragments IPv6 protocol, source-port-range-or-operator, destination-port- range-or-operator, destination-ipv4-network, source- ipv4-network,and v6-fragments TCP flags ICMP type and code Please comment/update. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 16 f=E9vrier 2018 14:55 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields +1. In TCP, only "flags" field looks mandatory. -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 7:03 PM To: Jon Shallow >; Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields Re-, I tend to agree with you to have to define a minimum set of mandatory match= fields. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 16 f=E9vrier 2018 14:29 =C0 : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; dots@ietf.org Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields Hi Med, See inline [Jon] Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 16 February 2018 12:56 To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields Jon, Thank you for sharing your thoughts. Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 16 f=E9vrier 2018 13:24 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org= Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields I like the concept of "+--ro capabilities" allowing for future support as t= he DOS server becomes more mature in its capabilities. If a DOTS client includes a filtering field parameter that is not currently= supported, should the parameter be ignored (and not returned for a GET), o= r the request rejected? [Med] I would vote for rejecting the request. The client should only use ma= tch criteria that are understood by the server; otherwise there will be dif= ferent expectation from the service. [Jon] I think that this is my preference - I was just seeking clarity of th= inking. It is conceivable that a DOTS client has 2 DOTS servers (one possibly a bac= kup, or 2 different ISPs), which may have differing filtering field paramet= er support capabilities. [Med] The backup/case seems odd. I would expect a feature parity for a redu= ndancy group used to provide the same service. [Jon] Agreed that a backup server is most likely to be from the same manufa= cturer and hence support the same functionality. But one may have just bee= n upgraded to have extra support. Adding in intelligence code to work out what is / is not allowed may not = be practical in a (memory or cpu) constrained environment of the DOTS clien= t. [Med] Fair. That said, I think we need to define the minimum set of supported parameter= s - e.g. protocol, source / dest ports, source / dest IPv4 prefixes, sourc= e / dest IPv6 prefixes, fragments and icmp type/code. [Jon] Any comments? -Jon Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 16 February 2018 10:18 To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields Hi Med, Please see inline [TR2] From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 1:45 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: draft-ietf-dots-data-channel: Filtering Fields Re-, Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 16 f=E9vrier 2018 08:00 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Wednesday, February 14, 2018 1:49 PM To: dots@ietf.org Subject: [Dots] draft-ietf-dots-data-channel: Filtering Fields Hi all, As agreed during the interim, there are some issues that need fixes in the = data-channel spec. We would like to hear from the WG to know what to record= in the document. Issue description: Should we support all of the match fields defined by "ie= tf-packet-fields" or do we need to define a minimum supported set? [TR] I don't see the need to support all the match fields, define a minimum= supported set (don't see the use for acl-eth-header-fields for DOTS use ca= ses). [Med] Agree that acl-eth-header-fields aren't required. The text is already= clear about this: DOTS implementations MUST support the following matching criteria: match based on the IP header (IPv4 and IPv6), match based on the transport header (TCP, UDP, and ICMP), and any combination thereof. The question is whether we need to go further and mandate (or not) the supp= ort of matching based on specific fields: dscp, ecn, ttl,... flow-label, ..= . tcp sequence-number, tcp flags, ... [TR2] https://tools.ietf.org/html/draft-ietf-netmod-acl-model-16 uses the f= eature statements in the YANG model allowing vendors to advertise match rul= es they are capable and willing to support but not at the field-level. The = problem is router implementations today don't support ACLs with tcp sequenc= e-number, acknowledgement-number, window-size etc but support TCP flags. If= the server could convey the list of match criteria supported, it not only = allows the client to convey the supported match rules but also allows the s= erver in future to advertise the new supported match fields. Would it be useful for a client to retrieve the list of match criteria supp= orted by a DOTS server? [TR2] Yes. -Tiru [TR] The YANG model supported by the DOTS server can retrieved by the DOTS = client using RESTCONF to determine the match criteria supported by the serv= er. [Med] I'm afraid this is not the same functionality. If we need to allow a = server to return its supported match criteria, this should be allowed by th= e module. For example, the module may include the following (example): +--ro capabilities | +--ro match-header* | | identityref | +--ro transport-protocols* [protocol-id] | | +--ro protocol-id uint8 | | +--ro protocol-name? string | +--ro dscp-support? boolean | +--ro ecn-support? boolean | +--ro length-support? boolean | +--ro ttl-support? boolean | +--ro protocol-support? boolean The client can ask the server to return its supported match criteria. The s= erver will indicate the exact set of fields it supports. I'm not expressing a preference to have this in the model, but I'm clarifyi= ng how it would look like. -Tiru Please comment. Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300A0D4309OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

The (positive) side effect is t= hat the leaf network will be protected because of the filters enforced at t= he upstream network. In other words, TTL-based filters issued by the leaf network may be redundant with the ones enforced by the = upstream network.

 

Cheers,

Med

 

De : Konda, Tirumaleswar Reddy [mail= to:TirumaleswarReddy_Konda@McAfee.com]
Envoy=E9 : lundi 19 f=E9vrier 2018 08:43
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fiel= ds

 

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Monday, February 19, 2018 1:03 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields

 

Hi Tiru,

 

Thank you.

 

Unless there is an objection, I= will add length fields to the table.

 

I know router vendors who suppo= rt TTL-based ACLs, but I don’t think this is a reason to set TTL as m= andatory-to-support for the DOTS case. For example, if upstream networks enforce policies based on a TTL range, this will have a = side effect to filter packets that are destined to a leaf DOTS client domai= n.

 

I did not get the response, wha= t is the side effect ?

 

-Tiru

 

Cheers,

Med

 

K= onda, Tirumaleswar Reddy [mailto:Tiruma= leswarReddy_Konda@McAfee.com]
Envoy=E9 : vendredi 16 f=E9vrier 2018 16:46
=C0 : BOUCADAIR Moha= med IMT/OLN; Jon Shallow; dots@ietf.org
Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fiel= ds

 

We may want to add

 

1)      UDP (lengt= h) to the list. It may be useful to block large DNS packets (e.g. DNS ampli= fication attack).

2)      In IPv4/IP= v6, add length, ttl (https://www.cisco.com/c/en/us/about/securi= ty-center/ttl-expiry-attack.html) to the list.

 

-Tiru

 

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Friday, February 16, 2018 8:04 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields

 

Re-,

 

Here is a tentative list:

 

   Header= Mandatory Fields

   ------= --------------------------------------------------------------<= /span>

   IPv4&n= bsp;  protocol, source-port-range-or-operator, destination-port-<= /o:p>

   &= nbsp;      range-or-operator, destination-ipv4-net= work, source-

   &= nbsp;      ipv4-network, and v4-fragments

   IPv6&n= bsp;  protocol, source-port-range-or-operator, destination-port-<= /o:p>

   &= nbsp;      range-or-operator, destination-ipv4-net= work, source-

   &= nbsp;      ipv4-network,and v6-fragments

   TCP&nb= sp;   flags

   ICMP   type and code

 

Please comment/update.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : vendredi 16 f=E9vrier 2018 14:55
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fiel= ds

 

+1. In TCP, only “flags” field looks mandatory.

 

-Tiru

 

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Friday, February 16, 2018 7:03 PM
To: Jon Shallow <sup= jps-ietf@jpshallow.com>; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org
Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields

 

Re-,

 

I tend to agree with you to hav= e to define a minimum set of mandatory match fields.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : vendredi 16 f=E9vrier 2018 14:29
=C0 : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; dots@ietf.org
Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fiel= ds

 

Hi Med,=

&n= bsp;

See inl= ine [Jon]

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 16 February 2018 12:56
To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields

 

Jon,

 

Thank you for sharing your thou= ghts.

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : vendredi 16 f=E9vrier 2018 13:24
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; <= a href=3D"mailto:dots@ietf.org"> dots@ietf.org
Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fiel= ds

 

I like the concept of “+--ro capabilities“ allowing for futu=
re support as the DOS server becomes more mature in its capabilities.<=
/o:p>
 
If a DOTS client includes a filtering field parameter that =
is not currently supported, should the parameter be ignored (and not return=
ed for a GET), or the request rejected?
[Med] I would vote for re=
jecting the request. The client should only use match criteria that are und=
erstood by the server; otherwise there will be different expectation from t=
he service. 
[Jon] I think that this is my preference – I was just=
 seeking clarity of thinking.
<=
o:p> 
It is conceivable that a DOTS client has 2 DOTS servers (on=
e possibly a backup, or 2 different ISPs), which may have differing filteri=
ng field parameter support capabilities.
[Med] The backup/case see=
ms odd. I would expect a feature parity for a redundancy group used to prov=
ide the same service.=

[=
Jon] Agreed that a backup server is most likely to be from the same manufac=
turer and hence support the same functionality.  But one may have just=
 been upgraded to have extra support.
<=
o:p> 
 <=
/pre>

 <=
/pre>

  Adding in intelligence code to work out what is / is=
 not allowed may not be practical in a (memory or cpu) constrained environm=
ent of the DOTS client.


[Med] Fair. 


 


That said, I think we need to define the minimum set of sup=
ported parameters – e.g. protocol, source / dest ports,  source =
/ dest IPv4 prefixes, source / dest IPv6 prefixes, fragments and icmp type/=
code. 


[Jon] Any comments?


<=
o:p> 


-=
Jon


<=
o:p> 


Regards


 


Jon


&n=
bsp;






From:=
 Dots [mailto:
dots-bounces@ietf.org] On B=
ehalf Of
Konda, Tirumaleswar Reddy

Sent: 16 February 2018 10:18

To: mohamed.boucadai=
r@orange.com;
dots@ietf.org

Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields






 


Hi Med,


 


Please see inline [TR2]


 








From:
mohamed.boucadair@orange.co=
m [mailto:mohamed.bouca=
dair@orange.com]


Sent: Friday, February 16, 2018 1:45 PM

To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>;
dots@ietf.org

Subject: RE: draft-ietf-dots-data-channel: Filtering Fields






 


Re-,


 


Please see inline.



 


Cheers,


Med


 








De : Dots [mailto:dots-bounces@ietf.org]
De la part de Konda, Tirumaleswar Reddy

Envoy=E9 : vendredi 16 f=E9vrier 2018 08:00

=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org

Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fiel=
ds






 


From: Dots [mailto:dots-bounces=
@ietf.org]
On Behalf Of mohamed=
.boucadair@orange.com

Sent: Wednesday, February 14, 2018 1:49 PM

To: dots@ietf.org

Subject: [Dots] draft-ietf-dots-data-channel: Filtering Fields<=
/o:p>


 


Hi all,



 


As agreed during the interim, there are som=
e issues that need fixes in the data-channel spec. We would like to hear fr=
om the WG to know what to record in the document.



 


Issue description: Should we support all of=
 the match fields defined by “ietf-packet-fields” or do we need=
 to define a minimum supported set?



 


[TR] I don’t see the need=
 to support all the match fields, define a minimum supported set (don’=
;t see the use for acl-eth-header-fields for DOTS use cases).  


[Med] Agree that acl-eth-header=
-fields aren’t required. The text is already clear about this:


 


DOTS implementation=
s MUST support the following


   matchi=
ng criteria: match based on the IP header (IPv4 and IPv6),


   match =
based on the transport header (TCP, UDP, and ICMP), and any


  
combination thereof.


 


The question is whether w=
e need to go further and mandate (or not) the support of matching based on =
specific fields: dscp, ecn, ttl,… flow-label, … tcp sequence-number, tcp flags, …  


 


[TR2] https=
://tools.ietf.org/html/draft-ietf-netmod-acl-model-16 uses the feature statem=
ents in the YANG model allowing vendors to advertise match rules they are c=
apable and willing to support but not at the field-level. The problem is ro=
uter implementations today don’t support ACLs with tcp sequence-numbe=
r, acknowledgement-number, window-size etc but support TCP flags. If the se=
rver could convey the list of match criteria supported, it not only allows =
the client to convey the supported match rules but also allows the server i=
n future to advertise the new supported match fields.   


 


Would it be useful for a client to retrieve=
 the list of match criteria supported by a DOTS server?



 


[TR2] Yes. 

 


-Tiru


 


[TR] The YANG model supported b=
y the DOTS server can retrieved by the DOTS client using RESTCONF to determ=
ine the match criteria supported by the server.



[Med] I’m afraid this is =
not the same functionality. If we need to allow a server to return its supp=
orted match criteria, this should be allowed by the module.
 For example, the module may include the following (example): 


 


      &=
nbsp;         +--ro capabilitie=
s


      &=
nbsp;         |  +--ro mat=
ch-header*


      &=
nbsp;         |  |  =
     identityref


      &=
nbsp;         |  +--ro tra=
nsport-protocols* [protocol-id]


      &=
nbsp;         |  |  +=
--ro protocol-id      uint8

      &=
nbsp;         |  |  +=
--ro protocol-name?   string


      &=
nbsp;         |  +--ro dsc=
p-support?       boolean

      &=
nbsp;         |  +--ro ecn=
-support?        boolean


      &=
nbsp;         |  +--ro len=
gth-support?     boolean


      &=
nbsp;         |  +--ro ttl=
-support?        boolean


      &=
nbsp;         |  +--ro pro=
tocol-support?   boolean


 


The client can ask the server to retu=
rn its supported match criteria. The server wil=
l indicate the exact set of fields it supports. 

 <=
/pre>

I’m not expressing =
a preference to have this in the model, but I’m clarifying how it wou=
ld look like. 

 


-Tiru


 


Please com=
ment.



 =
;


Cheers,


Med=
<=
/o:p>
--_000_787AE7BB302AE849A7480A190F8B93300A0D4309OPEXCLILMA3corp_-- From nobody Mon Feb 19 01:01:26 2018 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 8CB39127058 for ; Mon, 19 Feb 2018 01:01:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 7lheTGHkbHE9 for ; Mon, 19 Feb 2018 01:01:23 -0800 (PST) Received: from mx0a-00196b01.pphosted.com (mx0a-00196b01.pphosted.com [67.231.149.170]) (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 83C96126CBF for ; Mon, 19 Feb 2018 01:01:23 -0800 (PST) Received: from pps.filterd (m0072398.ppops.net [127.0.0.1]) by mx0a-00196b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1J8vEQ1031926; Mon, 19 Feb 2018 04:01:23 -0500 Received: from nam03-co1-obe.outbound.protection.outlook.com (mail-co1nam03lp0017.outbound.protection.outlook.com [216.32.181.17]) by mx0a-00196b01.pphosted.com with ESMTP id 2g7u8b00en-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 19 Feb 2018 04:01:20 -0500 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=uk6P/rM5Ld9F8KP+BAHvXS8151HGPZ7leP7guCdpNX0=; b=BrfkCzKOXfy7xHDfudgtnXh1SozcPWz5j2WOVoaUb0/lkCDs/zV9F9dAg2KIrkBndWd3lESUup+Z3sqSBb2C2ibtcB1sZNRsEDiwAZDxs7BVGEJ+e/U7qFtkzC4aPRxpe0oe+Y6XlGTCBGsUTz3mWXDgca9AnvW9tai397svHvo= Received: from DM2PR0101MB1039.prod.exchangelabs.com (10.160.129.156) by DM2PR0101MB1104.prod.exchangelabs.com (10.160.134.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.18; Mon, 19 Feb 2018 09:01:17 +0000 Received: from DM2PR0101MB1039.prod.exchangelabs.com ([fe80::c947:7845:18b7:77b4]) by DM2PR0101MB1039.prod.exchangelabs.com ([fe80::c947:7845:18b7:77b4%14]) with mapi id 15.20.0506.021; Mon, 19 Feb 2018 09:01:17 +0000 From: "Dobbins, Roland" To: "Konda, Tirumaleswar Reddy" CC: "mohamed.boucadair@orange.com" , Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Call home in the signal channel (was RE: draft-ietf-dots-data-channel: Filter Direction) Thread-Index: AdOnD40ix0FBs+3eR3Kr9ibwuvod3gABX+FgAAI+QYAAAnp+gAAA8WaAAAFXeQAAge6FgAAFStGAAASOw7U= Date: Mon, 19 Feb 2018 09:01:17 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A0D3439@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00d201d3a71e$05ead590$11c080b0$@jpshallow.com> <01b401d3a72b$b5a79f10$20f6dd30$@jpshallow.com> <621FB89B-F2BE-40B2-8698-0D9A4A92FD3C@arbor.net>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [184.82.239.49] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM2PR0101MB1104; 7:vn0oaih+E0uvgqEUHACtukVEzZ9p+6lJFEPYMOnnZ+y5fG/b2MTwTx38Etes1jg5wgdhpx5WbgNNZKS89souwe4Z75qh9CW/sW/E9dpcVSECWWLNJcqJJnMtlDe9IIv+5CGlz1YB+AWm8Qg0HKk+BhkzVqLJr/aCVlHviw+T1vePENhKDiMLJ6qmwEOLKv9ALWmceAuqgM7kSCFTxYLG8oVXFms1ICtt4HV/5Ja5CfIoKkGhr15sBqiq0aWgvoat x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: abbc6c20-e640-4c2a-eb36-08d57777563a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:DM2PR0101MB1104; x-ms-traffictypediagnostic: DM2PR0101MB1104: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231101)(944501161)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(20161123564045)(20161123562045)(6072148)(201708071742011); SRVR:DM2PR0101MB1104; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0101MB1104; x-forefront-prvs: 0588B2BD96 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(346002)(396003)(39850400004)(39380400002)(189003)(199004)(305945005)(86362001)(2950100002)(6916009)(83716003)(2906002)(14454004)(105586002)(102836004)(76176011)(25786009)(97736004)(7736002)(82746002)(6512007)(5250100002)(8936002)(5660300001)(81166006)(8676002)(81156014)(558084003)(229853002)(6436002)(106356001)(36756003)(6486002)(54906003)(99286004)(4326008)(33656002)(53936002)(6246003)(3660700001)(68736007)(93886005)(66066001)(478600001)(26005)(6116002)(186003)(2900100001)(59450400001)(53546011)(6506007)(3280700002)(316002)(3846002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1104; 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) x-microsoft-antispam-message-info: imk5au4hcF8qFZSKu6a3vD5NMIhwAzAYUXER+f93ljlHh3lWd47g5QuU4f6sv7Cnn009gXBvxpCKuNN+VIoc5YGp5JUKg80CIu0cMJkmBfRr4UFUBgbNTnBruE6Yv02hSxI4RKUSa04g1UP/Lok3JPFwM4/D5OWOS/WklDq1B6o= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-Network-Message-Id: abbc6c20-e640-4c2a-eb36-08d57777563a X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2018 09:01:17.1808 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1104 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-19_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=980 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802190112 Archived-At: Subject: Re: [Dots] Call home in the signal channel (was RE: draft-ietf-dots-data-channel: Filter Direction) 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, 19 Feb 2018 09:01:25 -0000 > On Feb 19, 2018, at 13:51, Konda, Tirumaleswar Reddy wrote: >=20 > whether these compromised devices would saturate outgoing pipe in the loc= al network itself ? Sometimes yes, sometimes no.=20 ----------------------------------- Roland Dobbins = From nobody Mon Feb 19 01:03:16 2018 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 DB19F126CBF for ; Mon, 19 Feb 2018 01:03:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 iEnEEIBEbe6i for ; Mon, 19 Feb 2018 01:03:13 -0800 (PST) Received: from mx0a-00196b01.pphosted.com (mx0b-00196b01.pphosted.com [67.231.157.166]) (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 3DF9012426E for ; Mon, 19 Feb 2018 01:03:13 -0800 (PST) Received: from pps.filterd (m0096262.ppops.net [127.0.0.1]) by mx0b-00196b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1J91VvA019769; Mon, 19 Feb 2018 04:03:12 -0500 Received: from nam03-co1-obe.outbound.protection.outlook.com (mail-co1nam03lp0019.outbound.protection.outlook.com [216.32.181.19]) by mx0b-00196b01.pphosted.com with ESMTP id 2g7uhn803q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 19 Feb 2018 04:03:12 -0500 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=hjYBdXdMlAl49SzOFYXml8rMd6hndqKBNSE7NEx2tys=; b=kJzViEMb6xQf1MOuhF+bN62aCv/F5U/oMSpe2xbfO7wZxAeCu77jbojb7DJ4jcpKzBsD7YqLvI33J+T8tKN2s+2b3ltErn11lRHMVvjfHj5yUeZkeG8oIzBk/j5nl1FRiOXmmea0xc26ccSmjhFXNcreQCALluTRHcy9hSV4xsM= Received: from DM2PR0101MB1039.prod.exchangelabs.com (10.160.129.156) by DM2PR0101MB1104.prod.exchangelabs.com (10.160.134.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.18; Mon, 19 Feb 2018 09:03:10 +0000 Received: from DM2PR0101MB1039.prod.exchangelabs.com ([fe80::c947:7845:18b7:77b4]) by DM2PR0101MB1039.prod.exchangelabs.com ([fe80::c947:7845:18b7:77b4%14]) with mapi id 15.20.0506.021; Mon, 19 Feb 2018 09:03:10 +0000 From: "Dobbins, Roland" To: "Konda, Tirumaleswar Reddy" CC: "mohamed.boucadair@orange.com" , Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Call home in the signal channel (was RE: draft-ietf-dots-data-channel: Filter Direction) Thread-Index: AdOnD40ix0FBs+3eR3Kr9ibwuvod3gABX+FgAAI+QYAAAnp+gAAA8WaAAAFXeQAAAn2fgABZ7WaAACWSQQAABbjJAAAEIts4 Date: Mon, 19 Feb 2018 09:03:10 +0000 Message-ID: <12A41D38-1E81-4677-96A1-4CFACA203026@arbor.net> References: <787AE7BB302AE849A7480A190F8B93300A0D3439@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00d201d3a71e$05ead590$11c080b0$@jpshallow.com> <01b401d3a72b$b5a79f10$20f6dd30$@jpshallow.com> <022001d3a73b$09b1c270$1d154750$@jpshallow.com> <395E0F43-03F3-46F0-821D-50A53577E5B3@arbor.net>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [184.82.239.49] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM2PR0101MB1104; 6:oXby79sgh4V5NkehJj1NgVjLFDsZiV/Hw8ey2STsQNRnB2O5ztjwSZcDIrcn5zIqxtElUfXrR72jqKU3gel/p+mLDUNoqXGfpBF3mzRgu0Fcb0YnBH0ZDG5VG++F+PKtpxbAQlia5lAi+oHlDoaskawovMfmT0V0SaXkM8/qirwFHRupGFTa8byvkqyC31M+ubEWWly2YCtIwIJ0vhTHTKdSMU1G1JTHJoL7MxTDbRQUW3k85bVFQ9wqh2qME1KeKegbnRtJb+i3Plp1DlT/oMGf0WgHefvFn3AlM3SfEsjvV30aWrBTgKwgrswcxQnG1fkOa9cQOYGu99Z1SlQY3jHc2ZqrbGAR0LE+skpR7rUsezy5Zh/PWsX5ggfjp40S; 5:J3vmWRK0/hM8FeJXzkKvl8ir3CHNT/hvYUV10JlEGBUKY0CBRvL21viXh5NRpNq/Lb6H3WqQF072U9CF4zrn7EhWTtJzNrr/6q50W+xuFGNucEJAiRlm/rFejUXfFF2p3C8amOQVZLC4cz15XMUmh0Ad0Ii7ZzTqu8muh1qSIHo=; 24:WilN9VGuOUGflGuVIShFTkJxO1IWZb00B/RlFO9ggaoDkzKYpZGEg0z9sh4L+hPvwYWG2J8SBABLBHuDsklLwEWa3XYdvX1RlEBVgjk3aaM=; 7:OvDlZUu70dsRqmkzKIIF8Efy8sakQuQa1M3YMkXTpjOfp/URPSZ2bz35Ht1eLdw/H2/ZpLsDBJoVtTR+UTD61sZ2xSwzuYrMhBHJyVyi3C/3amj3KB+AdXrDYc9OpJqH1KKLKWP6ACdd5Ytak4uzK/hge2ZGMjWAMQAsCCx5GW6StDGanmmBJtrCLOX3920ld0u23r7OPb7v28k8egPQBVJsZJV8Q0g7kvi13H+0clYqCYzim3W6xkgNK4TB38g3 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 68898cd4-4dad-441c-2a3c-08d57777996f x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:DM2PR0101MB1104; x-ms-traffictypediagnostic: DM2PR0101MB1104: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231101)(944501161)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(20161123564045)(20161123562045)(6072148)(201708071742011); SRVR:DM2PR0101MB1104; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0101MB1104; x-forefront-prvs: 0588B2BD96 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(346002)(396003)(39850400004)(39380400002)(55674003)(189003)(199004)(305945005)(86362001)(2950100002)(6916009)(83716003)(2906002)(14454004)(105586002)(102836004)(76176011)(25786009)(97736004)(7736002)(82746002)(6512007)(5250100002)(8936002)(5660300001)(81166006)(8676002)(81156014)(229853002)(6436002)(106356001)(36756003)(6486002)(54906003)(99286004)(4326008)(33656002)(53936002)(6246003)(3660700001)(68736007)(93886005)(66066001)(478600001)(26005)(6116002)(186003)(2900100001)(59450400001)(53546011)(6506007)(3280700002)(316002)(3846002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1104; 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) x-microsoft-antispam-message-info: 6qO6R+Y1QJ02z7FNFR7KvhMb0+KP8ak4aFZsNZ9Y6dPpVPb0KbCixJY/5NUpB0Gac8TF/JpMUJGY9MFfHqwyv2lxnhmhBu++sy1uemEWZ2qOGr0hS8BSoqHylDxxrz7DLFSuCr4h/uhLGKisFy3+zIGLcZFGjTdV/XKEgbk+kNw= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-Network-Message-Id: 68898cd4-4dad-441c-2a3c-08d57777996f X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2018 09:03:10.0400 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1104 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-19_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=967 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802190114 Archived-At: Subject: Re: [Dots] Call home in the signal channel (was RE: draft-ietf-dots-data-channel: Filter Direction) 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, 19 Feb 2018 09:03:15 -0000 > On Feb 19, 2018, at 14:05, Konda, Tirumaleswar Reddy wrote: >=20 > CPE will have to be enhanced to act as a DOTS server, suppress attack tra= ffic and isolate compromised devices. That's a future thing, for them to do that on their own.=20 In the meantime, it's useful to have this capability based upon centralized= instructions.=20 ----------------------------------- Roland Dobbins = From nobody Mon Feb 19 01:56:41 2018 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 E724F1200FC for ; Mon, 19 Feb 2018 01:56:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 dmcEmHBotlU9 for ; Mon, 19 Feb 2018 01:56:38 -0800 (PST) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 F333F1200E5 for ; Mon, 19 Feb 2018 01:56:37 -0800 (PST) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1519034190; h=From: To:CC:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:x-originating-ip: x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:authentication-results: x-microsoft-antispam-message-info:spamdiagnosticoutput: spamdiagnosticmetadata:Content-Type:Content-Transfer-Encoding: MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=T IQPi2StHm53RE61VEr516LPFkfsphgKphyKOurvjG M=; b=JB8x0rE9ObiNDDmEIj3t8U/H6nCByGAC7NF+cdImL66D OE6FroEixhq+MVw45YMKjXFOyLhMSlKvzBp7hSsynNEA22McdD 01+wW3PcrL4sGAOx0r4yjQvunsBz7tLYrIHGpfoJNLeOyjmkkT /K4lcR4rH+3p3v3KbegBzJ/7U+4= Received: from MIVEXAPP1N02.corpzone.internalzone.com (unknown [10.48.48.89]) by MIVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 5548_325e_f06215be_c53b_42bc_aff5_63c6e958a55e; Mon, 19 Feb 2018 03:56:30 -0600 Received: from MIVEXUSR1N06.corpzone.internalzone.com (10.48.48.86) by MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 19 Feb 2018 04:56:25 -0500 Received: from MIVEXAPP1N03.corpzone.internalzone.com (10.48.48.90) by MIVEXUSR1N06.corpzone.internalzone.com (10.48.48.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 19 Feb 2018 04:56:24 -0500 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.1347.2 via Frontend Transport; Mon, 19 Feb 2018 04:56:23 -0500 Received: from NAM02-SN1-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.1347.2; Mon, 19 Feb 2018 04:56:22 -0500 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1595.namprd16.prod.outlook.com (10.173.212.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.18; Mon, 19 Feb 2018 09:56: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.20.0506.021; Mon, 19 Feb 2018 09:56:17 +0000 From: "Konda, Tirumaleswar Reddy" To: "Dobbins, Roland" CC: Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: [Dots] Call home in the signal channel (was RE: draft-ietf-dots-data-channel: Filter Direction) Thread-Index: AQHTpx4fYQaVBSxJJEC02ounCseemaOm/iRwgAALCoCAAARH0IAAGmGAgALNmfCAALkMAIAAn1iggAAk3gCAAA2EcA== Date: Mon, 19 Feb 2018 09:56:17 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A0D3439@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00d201d3a71e$05ead590$11c080b0$@jpshallow.com> <01b401d3a72b$b5a79f10$20f6dd30$@jpshallow.com> <022001d3a73b$09b1c270$1d154750$@jpshallow.com> <395E0F43-03F3-46F0-821D-50A53577E5B3@arbor.net>, <12A41D38-1E81-4677-96A1-4CFACA203026@arbor.net> In-Reply-To: <12A41D38-1E81-4677-96A1-4CFACA203026@arbor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1595; 6:NYqxnN5zVyumCaqEKp09DtdtdDZhoVCEbQqhxtq9pliO1JCO7q3kxumcYUD3RSia1e+i8eKUiozUVjG/7WjNI2cOXnGYd/a159wdHhuJLcRYvknULeh6T80zU0k4KL6ILBW5CZjQK5UpBO95HAxTLIb1HMzl2iIWxM20bdd2Pi7fcP6zZDEv10LGBjDpDfGtG9umCFpBo1KPjuvouPdEvmBul6nzNb1r7Y511DxJBfpGMkJs5A91UNGHvfwsRkeObqttvXz+8xfIOerbY52Y3D37jbqiFV655onXL+TR9KUBDIVkd3ws4impLQgzFxPT6PvhZSo82R6gRWbQDaQQOemE+HvDOEBexl9P0uqxu+ZmBVeIMezBu39WaaOKJQxx; 5:QAoPJkUj4AaAQBUdjuuwjXguxKk692p+ErmPZ+RkSTFRie3D3t5pBDAW+asISAgsYe71ZCH5K48voDbImbzWOrrlh/lX+ELgIMT3slVaQJAQqFado5lwEr9WuzAOPzmfpePVxBq75hD+pm7QNB9OgrGIHqC0y/gGY/cS3UFdqnI=; 24:ecxi3vOtRKq9zLg4WO86YIBAXSVSfOkqCfqyKJmkT8ozrbkdd7z4t51p3duYKeDOqVoDPBs793XcrUnpl9QaucCCG6SCSY33sDIL1tz6csg=; 7:7VfrcW9BpVGLhNhZ+b3THsSzcjeVDSwxsm8OBeIwJQRsj2+RmFMO9M4DVTNBatZqfnQCmJo1I/mTpvYh4Kx8lY9qvgplC2yGcv/t947x49Vh1NZOTwI3K13uoDjADgg1SERSn+fWKn9tKgHgxidyekV5SfTpCdodqgxvSwOwX+ybcj72oUZnIuuNOvG+Fy3W14ibjpAcT27j0X0fFvxOjnukMvW2r6huke5JRHi/R338SrvDV7MSqi7zwnhGUZOG x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 3f2acfdd-a78b-4d5e-869a-08d5777f056b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:DM5PR16MB1595; x-ms-traffictypediagnostic: DM5PR16MB1595: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(18271650672692)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001056)(6040501)(2401047)(5005006)(8121501046)(3002001)(3231101)(944501161)(93006095)(93001095)(10201501046)(6041288)(20161123562045)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:DM5PR16MB1595; BCL:0; PCL:0; RULEID:; SRVR:DM5PR16MB1595; x-forefront-prvs: 0588B2BD96 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(39860400002)(346002)(396003)(376002)(366004)(55674003)(32952001)(199004)(189003)(13464003)(74316002)(2906002)(186003)(86362001)(106356001)(55016002)(2900100001)(81166006)(81156014)(76176011)(305945005)(6306002)(8936002)(3660700001)(68736007)(9686003)(8676002)(93886005)(7736002)(6436002)(59450400001)(66066001)(3280700002)(53546011)(6506007)(6916009)(2950100002)(25786009)(53936002)(229853002)(54906003)(316002)(26005)(478600001)(4326008)(80792005)(97736004)(7696005)(77096007)(6246003)(102836004)(14454004)(105586002)(99286004)(6116002)(5660300001)(3846002)(33656002)(72206003)(966005)(6346003)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1595; 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) authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-microsoft-antispam-message-info: paH8zvE0bLR6b6reTI+DEBT11rHFC/+KLuZc/hLLZJJay/85ydJEpQmSf7VdsKFQfLvHWkCCIMS+0Ki/1n44JxDoH9FNO0zaj0F6fVZ2T4gaU4yMtr0O53HLancl+Gm4PYUK2j/85gqRVbNb4Rp5dMKTjUIHCiLmAn0ilu+IDfk= 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-Network-Message-Id: 3f2acfdd-a78b-4d5e-869a-08d5777f056b X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2018 09:56:17.6715 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1595 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 <6224> : inlines <6406> : streams <1779419> : uri <2595516> Archived-At: Subject: Re: [Dots] Call home in the signal channel (was RE: draft-ietf-dots-data-channel: Filter Direction) 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, 19 Feb 2018 09:56:40 -0000 > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Dobbins, Roland > Sent: Monday, February 19, 2018 2:33 PM > To: Konda, Tirumaleswar Reddy > Cc: Jon Shallow ; > mohamed.boucadair@orange.com; dots@ietf.org > Subject: Re: [Dots] Call home in the signal channel (was RE: draft-ietf-d= ots- > data-channel: Filter Direction) >=20 >=20 >=20 > > On Feb 19, 2018, at 14:05, Konda, Tirumaleswar Reddy > wrote: > > > > CPE will have to be enhanced to act as a DOTS server, suppress attack > traffic and isolate compromised devices. >=20 > That's a future thing, for them to do that on their own. >=20 > In the meantime, it's useful to have this capability based upon centraliz= ed > instructions. I don't get the above comment, we are discussing the requirements to meet t= he use case https://tools.ietf.org/html/draft-ietf-dots-use-cases-09#sectio= n-3.2.1.=20 -Tiru >=20 > ----------------------------------- > Roland Dobbins > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Mon Feb 19 02:05:23 2018 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 C1096127241 for ; Mon, 19 Feb 2018 02:05:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 FuXig_YKDReR for ; Mon, 19 Feb 2018 02:05:18 -0800 (PST) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 5B63C126D05 for ; Mon, 19 Feb 2018 02:05:18 -0800 (PST) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1519034700; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=H HQuEHzTskR3HdcupCCH0XWpiSAKcEocT5kIc0CE7m 4=; b=YgXZEqzJiRoSNfXiZV4n8MTAqv4ZuVyYVQyIUp1ZeZ6U mCp06DRCM5s2B3Ewn5QWuanTP6fpXKA4aRG28JaVTIrHKu5QW6 kGG1UFUPxHonS9/JH2kQM+EPw2ErznPXuUlM9x30u2USTCEFM3 m4iMLb03ZOJauRJALSZ9tNEWCc4= Received: from MIVEXAPP1N02.corpzone.internalzone.com (unknown [10.48.48.89]) by MIVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 5548_36e5_92fddecf_7765_45ae_8447_3306e74d3e47; Mon, 19 Feb 2018 04:04:59 -0600 Received: from MIVEXUSR1N03.corpzone.internalzone.com (10.48.48.83) by MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 19 Feb 2018 05:04:58 -0500 Received: from MIVO365EDGE4.corpzone.internalzone.com (10.48.176.87) by MIVEXUSR1N03.corpzone.internalzone.com (10.48.48.83) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Mon, 19 Feb 2018 05:04:58 -0500 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (10.48.176.242) by edge.mcafee.com (10.48.176.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 19 Feb 2018 05:04:56 -0500 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1418.namprd16.prod.outlook.com (10.173.210.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.18; Mon, 19 Feb 2018 10:04:56 +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.20.0506.021; Mon, 19 Feb 2018 10:04:56 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] draft-ietf-dots-data-channel: Filtering Fields Thread-Index: AdOlbICGgF2MxoHnQied7J+cvW2QAABhQcigAAKnFWAAAuyKQAAGTI4AAAEahwAAASoGAAAAJ8mAAAB6+CAAAZF/MAAB7sFgAIT4tOAAAZCeUAAAd3cgAARRjlA= Date: Mon, 19 Feb 2018 10:04:56 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A0D1F93@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0D32AE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00e801d3a721$08806d30$19814790$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0D366E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019201d3a72a$1b103b70$5130b250$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0D372A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0D3847@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0D42B6@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0D4309@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A0D4309@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action 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; DM5PR16MB1418; 7:HPmEHq+/8XopC2j2c+2CpaohXc4dx/bvgYyuMVAMlKSYH1guOPzQbb4B+k5zDZrA0dvuAF8Q9YeZus/s+kmth37s5+02DiP3EAfcRGY0RDZqIDnzDknXgaZU8NZXma7T3ZrjJovOPrWCCb/7CoZ9Lw4UA1GQTWg/HwXb0uTK76AY/WI2nExZB8thKk0Bstz6HQ5bSGIGNuWEnDOhr62jORXvXAjxxOmDuCuntNRgcfX1h+E50bARLh4L/gx8Zsez x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 8352f95b-a1e6-4a7d-e0b2-08d577803a74 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:DM5PR16MB1418; x-ms-traffictypediagnostic: DM5PR16MB1418: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(114627819485645)(95692535739014)(18271650672692)(21748063052155)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231101)(944501161)(6041288)(20161123558120)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011); SRVR:DM5PR16MB1418; BCL:0; PCL:0; RULEID:; SRVR:DM5PR16MB1418; x-forefront-prvs: 0588B2BD96 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(346002)(376002)(396003)(39380400002)(57704003)(32952001)(53754006)(51444003)(199004)(189003)(33656002)(8676002)(14454004)(81156014)(229853002)(99286004)(81166006)(6246003)(345774005)(102836004)(236005)(106356001)(77096007)(478600001)(9686003)(3660700001)(53936002)(59450400001)(186003)(53946003)(55016002)(606006)(93886005)(6506007)(25786009)(86362001)(7696005)(2900100001)(8936002)(3280700002)(53546011)(26005)(6306002)(54896002)(966005)(2950100002)(68736007)(66066001)(2501003)(97736004)(790700001)(6116002)(3846002)(80792005)(19609705001)(316002)(110136005)(76176011)(7736002)(74316002)(6436002)(105586002)(5660300001)(72206003)(2906002)(85282002)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1418; 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) x-microsoft-antispam-message-info: X2GHyOKxjOe2aybfkA1GbmXMBDLtRn/6fdB/HomPeUdEQen8kRpGf90gxuoDqQom8nBfJWq7LQLxAaQU391UDRrWozjI117qPs5fti2wUxfscR5fs+kUAX4jKmVCDoJomzkfqiTPWcuMuOxRbIHwyjgpq8OKjskD1BjP3PKSHuM= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1788B092FDF236502A5CA958EAC80DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 8352f95b-a1e6-4a7d-e0b2-08d577803a74 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2018 10:04:56.1487 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1418 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 <6224> : inlines <6406> : streams <1779420> : uri <2595518> Archived-At: Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields 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, 19 Feb 2018 10:05:22 -0000 --_000_DM5PR16MB1788B092FDF236502A5CA958EAC80DM5PR16MB1788namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Monday, February 19, 2018 1:29 PM To: Konda, Tirumaleswar Reddy ; Jon Sha= llow ; dots@ietf.org Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields Re-, The (positive) side effect is that the leaf network will be protected becau= se of the filters enforced at the upstream network. In other words, TTL-bas= ed filters issued by the leaf network may be redundant with the ones enforc= ed by the upstream network. If it's a positive side effect, why not make TTL mandatory-to-support ? -Tiru Cheers, Med De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] Envoy=E9 : lundi 19 f=E9vrier 2018 08:43 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Monday, February 19, 2018 1:03 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields Hi Tiru, Thank you. Unless there is an objection, I will add length fields to the table. I know router vendors who support TTL-based ACLs, but I don't think this is= a reason to set TTL as mandatory-to-support for the DOTS case. For example= , if upstream networks enforce policies based on a TTL range, this will hav= e a side effect to filter packets that are destined to a leaf DOTS client d= omain. I did not get the response, what is the side effect ? -Tiru Cheers, Med De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] Envoy=E9 : vendredi 16 f=E9vrier 2018 16:46 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields We may want to add 1) UDP (length) to the list. It may be useful to block large DNS packe= ts (e.g. DNS amplification attack). 2) In IPv4/IPv6, add length, ttl (https://www.cisco.com/c/en/us/about/= security-center/ttl-expiry-attack.html) to the list. -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 8:04 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields Re-, Here is a tentative list: Header Mandatory Fields ------ -------------------------------------------------------------- IPv4 protocol, source-port-range-or-operator, destination-port- range-or-operator, destination-ipv4-network, source- ipv4-network, and v4-fragments IPv6 protocol, source-port-range-or-operator, destination-port- range-or-operator, destination-ipv4-network, source- ipv4-network,and v6-fragments TCP flags ICMP type and code Please comment/update. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 16 f=E9vrier 2018 14:55 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields +1. In TCP, only "flags" field looks mandatory. -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 7:03 PM To: Jon Shallow >; Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields Re-, I tend to agree with you to have to define a minimum set of mandatory match= fields. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 16 f=E9vrier 2018 14:29 =C0 : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; dots@ietf.org Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields Hi Med, See inline [Jon] Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 16 February 2018 12:56 To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields Jon, Thank you for sharing your thoughts. Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 16 f=E9vrier 2018 13:24 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org= Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields I like the concept of "+--ro capabilities" allowing for future support as t= he DOS server becomes more mature in its capabilities. If a DOTS client includes a filtering field parameter that is not currently= supported, should the parameter be ignored (and not returned for a GET), o= r the request rejected? [Med] I would vote for rejecting the request. The client should only use ma= tch criteria that are understood by the server; otherwise there will be dif= ferent expectation from the service. [Jon] I think that this is my preference - I was just seeking clarity of th= inking. It is conceivable that a DOTS client has 2 DOTS servers (one possibly a bac= kup, or 2 different ISPs), which may have differing filtering field paramet= er support capabilities. [Med] The backup/case seems odd. I would expect a feature parity for a redu= ndancy group used to provide the same service. [Jon] Agreed that a backup server is most likely to be from the same manufa= cturer and hence support the same functionality. But one may have just bee= n upgraded to have extra support. Adding in intelligence code to work out what is / is not allowed may not = be practical in a (memory or cpu) constrained environment of the DOTS clien= t. [Med] Fair. That said, I think we need to define the minimum set of supported parameter= s - e.g. protocol, source / dest ports, source / dest IPv4 prefixes, sourc= e / dest IPv6 prefixes, fragments and icmp type/code. [Jon] Any comments? -Jon Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 16 February 2018 10:18 To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields Hi Med, Please see inline [TR2] From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 1:45 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: draft-ietf-dots-data-channel: Filtering Fields Re-, Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 16 f=E9vrier 2018 08:00 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Wednesday, February 14, 2018 1:49 PM To: dots@ietf.org Subject: [Dots] draft-ietf-dots-data-channel: Filtering Fields Hi all, As agreed during the interim, there are some issues that need fixes in the = data-channel spec. We would like to hear from the WG to know what to record= in the document. Issue description: Should we support all of the match fields defined by "ie= tf-packet-fields" or do we need to define a minimum supported set? [TR] I don't see the need to support all the match fields, define a minimum= supported set (don't see the use for acl-eth-header-fields for DOTS use ca= ses). [Med] Agree that acl-eth-header-fields aren't required. The text is already= clear about this: DOTS implementations MUST support the following matching criteria: match based on the IP header (IPv4 and IPv6), match based on the transport header (TCP, UDP, and ICMP), and any combination thereof. The question is whether we need to go further and mandate (or not) the supp= ort of matching based on specific fields: dscp, ecn, ttl,... flow-label, ..= . tcp sequence-number, tcp flags, ... [TR2] https://tools.ietf.org/html/draft-ietf-netmod-acl-model-16 uses the f= eature statements in the YANG model allowing vendors to advertise match rul= es they are capable and willing to support but not at the field-level. The = problem is router implementations today don't support ACLs with tcp sequenc= e-number, acknowledgement-number, window-size etc but support TCP flags. If= the server could convey the list of match criteria supported, it not only = allows the client to convey the supported match rules but also allows the s= erver in future to advertise the new supported match fields. Would it be useful for a client to retrieve the list of match criteria supp= orted by a DOTS server? [TR2] Yes. -Tiru [TR] The YANG model supported by the DOTS server can retrieved by the DOTS = client using RESTCONF to determine the match criteria supported by the serv= er. [Med] I'm afraid this is not the same functionality. If we need to allow a = server to return its supported match criteria, this should be allowed by th= e module. For example, the module may include the following (example): +--ro capabilities | +--ro match-header* | | identityref | +--ro transport-protocols* [protocol-id] | | +--ro protocol-id uint8 | | +--ro protocol-name? string | +--ro dscp-support? boolean | +--ro ecn-support? boolean | +--ro length-support? boolean | +--ro ttl-support? boolean | +--ro protocol-support? boolean The client can ask the server to return its supported match criteria. The s= erver will indicate the exact set of fields it supports. I'm not expressing a preference to have this in the model, but I'm clarifyi= ng how it would look like. -Tiru Please comment. Cheers, Med --_000_DM5PR16MB1788B092FDF236502A5CA958EAC80DM5PR16MB1788namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

From:<= /span> mohamed.boucadair@ora= nge.com [mailto:mohamed.boucadair@orange.com]
Sent: Monday, February 19, 2018 1:29 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; Jon Shallow <supjps-ietf@jpshallow.com>; dots@ietf.org
Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields

 

Re-,

 

The (positive) side effect is that the leaf ne= twork will be protected because of the filters enforced at the upstream net= work. In other words, TTL-based filters issued by the leaf network may be redundant with the ones enforced by the upstrea= m network.

 

If it’s a positive side effect, why not make T= TL mandatory-to-support ?

 

-Tiru

 

Cheers,

Med

 

De : Konda, Tirumaleswar Reddy [mailto:Tirumaleswar= Reddy_Konda@McAfee.com]
Envoy=E9 : lundi 19 f=E9vrier 2018 08:43
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fiel= ds

 

From:<= /span> mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Monday, February 19, 2018 1:03 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields

 

Hi Tiru,

 

Thank you.

 

Unless there is an objection, I will add lengt= h fields to the table.

 

I know router vendors who support TTL-based AC= Ls, but I don’t think this is a reason to set TTL as mandatory-to-sup= port for the DOTS case. For example, if upstream networks enforce policies based on a TTL range, this will have a side effect to fil= ter packets that are destined to a leaf DOTS client domain.

 

I did not get the response, what is the side effect = ?

 

-Tiru

 

Cheers,

Med

 

De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com]
Envoy=E9 : vendredi 16 f=E9vrier 2018 16:46
=C0 : BOUCADAIR Moha= med IMT/OLN; Jon Shallow; dots@ietf.org
Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fiel= ds

 

We may wa= nt to add

&nbs= p;

1) &nb= sp;    UDP (length) to the list.= It may be useful to block large DNS packets (e.g. DNS amplification attack= ).

2) &nb= sp;    In IPv4/IPv6, add length,= ttl (https://www.cisco.com/c/en/us/about/security-center/ttl-e= xpiry-attack.html) to the list.

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Friday, February 16, 2018 8:04 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields

 

Re-,

 

Here is a tentative list:

 

   Header Mandatory Fiel= ds

   ------ --------------= ------------------------------------------------

   IPv4   prot= ocol, source-port-range-or-operator, destination-port-

     &nbs= p;    range-or-operator, destination-ipv4-network, source-

     &nbs= p;    ipv4-network, and v4-fragments

   IPv6   prot= ocol, source-port-range-or-operator, destination-port-

     &nbs= p;    range-or-operator, destination-ipv4-network, source-

     &nbs= p;    ipv4-network,and v6-fragments

   TCP   = flags

   ICMP   type and code

 

Please comment/update.

 

Cheers,

Med=

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : vendredi 16 f=E9vrier 2018 14:55
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fiel= ds

 

+1. I= n TCP, only “flags” field looks mandatory.

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Friday, February 16, 2018 7:03 PM
To: Jon Shallow <sup= jps-ietf@jpshallow.com>; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org
Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields

 

Re-,

 

I tend to agree with you to have to define a m= inimum set of mandatory match fields.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : vendredi 16 f=E9vrier 2018 14:29
=C0 : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; dots@ietf.org
Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fiel= ds

 

Hi Med,=

&n= bsp;

See inl= ine [Jon]

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 16 February 2018 12:56
To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields

 

Jon,

 

Thank you for sharing your thoughts.

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : vendredi 16 f=E9vrier 2018 13:24
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; <= a href=3D"mailto:dots@ietf.org"> dots@ietf.org
Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fiel= ds

 

I like the concept of “+=
--ro capabilities“ allowing for future support as t=
he DOS server becomes more mature in its capabilities.

 


If a DOTS client includes a filtering field parameter that =
is not currently supported, should the parameter be ignored (and not return=
ed for a GET), or the request rejected?


[Med] I would vote for re=
jecting the request. The client should only use match criteria that are und=
erstood by the server; otherwise there will be different expectation from t=
he service. 


[Jon] I think that this is my preference – I was just=
 seeking clarity of thinking.


<=
o:p> 


It is conceivable that a DOTS client has 2 DOTS servers (on=
e possibly a backup, or 2 different ISPs), which may have differing filteri=
ng field parameter support capabilities.


[Med] The backup/case see=
ms odd. I would expect a feature parity for a redundancy group used to prov=
ide the same service.=



[=
Jon] Agreed that a backup server is most likely to be from the same manufac=
turer and hence support the same functionality.  But one may have just=
 been upgraded to have extra support.


<=
o:p> 


 <=
/pre>

 <=
/pre>

  Adding in intelligence code to work out what is / is=
 not allowed may not be practical in a (memory or cpu) constrained environm=
ent of the DOTS client.


[Med] Fair. 


 


That said, I think we need to define the minimum set of sup=
ported parameters – e.g. protocol, source / dest ports,  source =
/ dest IPv4 prefixes, source / dest IPv6 prefixes, fragments and icmp type/=
code. 


[Jon] Any comments?


<=
o:p> 


-=
Jon


<=
o:p> 


Regards


 


Jon


&n=
bsp;






From: Dots [mailto:
dots-bounces@ietf.org] On B=
ehalf Of
Konda, Tirumaleswar Reddy

Sent: 16 February 2018 10:18

To: mohamed.boucadai=
r@orange.com;
dots@ietf.org

Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields






 


Hi Med,


&nbs=
p;


Please se=
e inline [TR2]


&nbs=
p;








From:<=
/span>
mohamed.boucadair@orange.co=
m [mailto:mohamed.bouca=
dair@orange.com]


Sent: Friday, February 16, 2018 1:45 PM

To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>;
dots@ietf.org

Subject: RE: draft-ietf-dots-data-channel: Filtering Fields






 


Re-,


 


Please see inline.



 


Cheers,


Med


 








De : Dots [mailto:dots-bounces@ietf.org]
De la part de Konda, Tirumaleswar Reddy

Envoy=E9 : vendredi 16 f=E9vrier 2018 08:00

=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org

Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fiel=
ds






 


From:<=
/span> Dots [mailto:dots-bounces@ietf.org]
On Behalf Of mohamed=
.boucadair@orange.com

Sent: Wednesday, February 14, 2018 1:49 PM

To: dots@ietf.org

Subject: [Dots] draft-ietf-dots-data-channel: Filtering Fields<=
/o:p>


 


Hi all,



 


As agreed during the interim, there are some issues that n=
eed fixes in the data-channel spec. We would like to hear from the WG to kn=
ow what to record in the document.



 


Issue description: Should we support all of the match fiel=
ds defined by “ietf-packet-fields” or do we need to define a mi=
nimum supported set?



 


[TR] I don’t see the need to support all the m=
atch fields, define a minimum supported set (don’t see the use for ac=
l-eth-header-fields for DOTS use cases).  


[Med] Agree that acl-eth-header-fields aren=
217;t required. The text is already clear about this:


 


DOTS implementations MUST support =
the following


   matching criteria: ma=
tch based on the IP header (IPv4 and IPv6),


   match based on the tr=
ansport header (TCP, UDP, and ICMP), and any


  
combination thereof.=



 


The question is whether we need to go fu=
rther and mandate (or not) the support of matching based on specific fields=
: dscp, ecn, ttl,… flow-label, … tcp s=
equence-number, tcp flags, …  <=
/o:p>


 


[TR2] https://tools.ietf.o=
rg/html/draft-ietf-netmod-acl-model-16 uses the feature statements in the YANG model allowin=
g vendors to advertise match rules they are capable and willing to support =
but not at the field-level. The problem is router implementations today don=
’t support ACLs with tcp sequence-number, acknowledgement-number, win=
dow-size etc but support TCP flags. If the server could convey the list of =
match criteria supported, it not only allows the client to convey the suppo=
rted match rules but also allows the server in future to advertise the new =
supported match fields.   


 


Would it be useful for a client to retrieve the list of ma=
tch criteria supported by a DOTS server?



 


[TR2] Yes. 


 


-Tiru


 


[TR] The YANG model supported by the DOTS server can=
 retrieved by the DOTS client using RESTCONF to determine the match criteri=
a supported by the server.



[Med] I’m afraid this is not the same fu=
nctionality. If we need to allow a server to return its supported match cri=
teria, this should be allowed by the module. For example,
 the module may include the following (example): 


 


        &nbs=
p;       +--ro capabilities


        &nbs=
p;       |  +--ro match-header*=



        &nbs=
p;       |  |    &nb=
sp;  identityref


        &nbs=
p;       |  +--ro transport-protocol=
s* [protocol-id]


        &nbs=
p;       |  |  +--ro protocol-i=
d      uint8


        &nbs=
p;       |  |  +--ro protocol-n=
ame?   string


        &nbs=
p;       |  +--ro dscp-support? &nbs=
p;     boolean


        &nbs=
p;       |  +--ro ecn-support?  =
;      boolean


        &nbs=
p;       |  +--ro length-support? &n=
bsp;   boolean


        &nbs=
p;       |  +--ro ttl-support?  =
;      boolean


        &nbs=
p;       |  +--ro protocol-support? =
  boolean


 


The client can ask the server to return its supported match criteria. The server will indicate the =
exact set of fields it supports. 


 


I’m not expressing a preference to=
 have this in the model, but I’m clarifying how it would look like. <=
/span>


 


-Tiru


 


Please comment.



 <=
/p>

Cheers,=



Med
--_000_DM5PR16MB1788B092FDF236502A5CA958EAC80DM5PR16MB1788namp_-- From nobody Mon Feb 19 02:20:08 2018 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 18B42126D05 for ; Mon, 19 Feb 2018 02:20:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 tRjaWptR6ivg for ; Mon, 19 Feb 2018 02:20:04 -0800 (PST) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 AED88126CF9 for ; Mon, 19 Feb 2018 02:20:03 -0800 (PST) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1519035584; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=wULjh/E034GM7D6nbBaLcg3U1tbgFUksTbLN3n GSx/4=; b=MlDrA6OQjpvo7PMWDrtnohzJms72ILUv/fobpc1N e8aYT0igISPTJCrEcMJqIFwaOVbG+x/nR3jiu6rc7SHrKGQeGT I9IbMo6XYhHSS3TxSeW0c5IlrpPFqBWKotwy3Ib01qxDIulRs8 mrgnLinkM94bpdlmJFzTtLPpfT+mt8A= Received: from MIVEXAPP1N02.corpzone.internalzone.com (mivexapp1n02.corpzone.internalzone.com [10.48.48.89]) by MIVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 5548_3e9b_23f7ef0d_67ec_407c_b954_a706c8a51d1c; Mon, 19 Feb 2018 04:19:43 -0600 Received: from MIVEXUSR1N01.corpzone.internalzone.com (10.48.48.81) by MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 19 Feb 2018 05:19:32 -0500 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.1347.2 via Frontend Transport; Mon, 19 Feb 2018 05:19:32 -0500 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (10.48.176.241) by edge.mcafee.com (10.48.176.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 19 Feb 2018 05:19:30 -0500 Received: from BN6PR16MB1777.namprd16.prod.outlook.com (10.172.28.141) by BN6PR16MB0097.namprd16.prod.outlook.com (10.172.112.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.18; Mon, 19 Feb 2018 10:19:29 +0000 Received: from BN6PR16MB1777.namprd16.prod.outlook.com ([10.172.28.141]) by BN6PR16MB1777.namprd16.prod.outlook.com ([10.172.28.141]) with mapi id 15.20.0506.023; Mon, 19 Feb 2018 10:19:28 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , Jon Shallow , "dots@ietf.org" Thread-Topic: draft-ietf-dots-data-channel: Value and/or Range Thread-Index: AdOpVo4UGaF3iP8sRF6zMQH8hhSSfwAFG7oQ Date: Mon, 19 Feb 2018 10:19:28 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A0D42F4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A0D42F4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action 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; BN6PR16MB0097; 7:s8X2r+Y678N1jkVu/rYP4GHKSVbNStWLu+tvpPQqw06Zv329qvTnV2jeAbPCBQa9NFhEkiKjZxXQzofoR7uk76Q83zQL6Z5a4EiyT6sjkqBdOJUQx5FIMsxW/f8dABiddyedBb7cLuT73UuuV08Og7SqFcS2FodYdR8YPZBzvZqglmHATUS42UxV5TRCA7m5KXFUyIRhd1SYZN8xssQIIMBkr9/MlWFVJJqgPsQc21TftJK8CtCfHrRrq9t3V5dn x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 1808a450-e738-444f-7137-08d577824297 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:BN6PR16MB0097; x-ms-traffictypediagnostic: BN6PR16MB0097: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(114627819485645)(95692535739014)(18271650672692)(21748063052155)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3231101)(944501161)(3002001)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(6072148)(201708071742011); SRVR:BN6PR16MB0097; BCL:0; PCL:0; RULEID:; SRVR:BN6PR16MB0097; x-forefront-prvs: 0588B2BD96 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(346002)(366004)(39380400002)(376002)(39860400002)(53754006)(199004)(189003)(51444003)(32952001)(57704003)(6246003)(80792005)(97736004)(68736007)(236005)(9686003)(53946003)(345774005)(55016002)(54896002)(6306002)(2900100001)(53936002)(6436002)(105586002)(316002)(186003)(6506007)(33656002)(77096007)(53546011)(76176011)(102836004)(26005)(99286004)(86362001)(7696005)(2501003)(110136005)(8676002)(5660300001)(59450400001)(3660700001)(8936002)(19609705001)(81166006)(106356001)(81156014)(66066001)(966005)(72206003)(2950100002)(2906002)(3280700002)(14454004)(790700001)(7736002)(3846002)(606006)(6116002)(74316002)(229853002)(478600001)(25786009)(85282002)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR16MB0097; H:BN6PR16MB1777.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) x-microsoft-antispam-message-info: 0y3xDIDHRNv3krseE+XXr1d1G6B3997PzQxsDPECdceE2Uk2Nr4cAvAQGFijV0+a9r0c7Jn3RBsAJAR5yLDYwGLh7Qr6lh+xFHMqPsYq3PIX9Fx+JBP6eQQVpQiziMS9uiexLZUwqPjhbwxB9442Gl0jLIMwYXcIjjDXbLFRxIM= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR16MB1777DEC1B64F91F0ADD45D3BEAC80BN6PR16MB1777namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 1808a450-e738-444f-7137-08d577824297 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2018 10:19:28.7749 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR16MB0097 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 <6224> : inlines <6406> : streams <1779421> : uri <2595525> Archived-At: Subject: Re: [Dots] draft-ietf-dots-data-channel: Value and/or Range 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, 19 Feb 2018 10:20:07 -0000 --_000_BN6PR16MB1777DEC1B64F91F0ADD45D3BEAC80BN6PR16MB1777namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I don't think router vendors support ranges for TTL fields ! -Tiru From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Monday, February 19, 2018 1:22 PM To: Jon Shallow ; Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: draft-ietf-dots-data-channel: Value and/or Range Hi Jon, Good point. Actually, some filtering parameters are worth to be supplied as values or r= anges but the current netmod module does not allow for it. I can cite: =B7 Length fields =B7 TTL Do we need to have value/range supported in the module for these fields? Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 16 f=E9vrier 2018 17:14 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org= Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields Ttl is an interesting one. It is not definable as a range, and so if you w= ant to match "ttl lt 16" you are going to have to have 16 ACLs preceding an= y other ACL that does anything else. I would expect that 'ttl' would be done properly as a one of the mitigator = rules, and DOTS does not need to 'hint' it as well. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 16 February 2018 15:46 To: mohamed.boucadair@orange.com; Jon = Shallow; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields We may want to add 1) UDP (length) to the list. It may be useful to block large DNS packe= ts (e.g. DNS amplification attack). 2) In IPv4/IPv6, add length, ttl (https://www.cisco.com/c/en/us/about/= security-center/ttl-expiry-attack.html) to the list. -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 8:04 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields Re-, Here is a tentative list: Header Mandatory Fields ------ -------------------------------------------------------------- IPv4 protocol, source-port-range-or-operator, destination-port- range-or-operator, destination-ipv4-network, source- ipv4-network, and v4-fragments IPv6 protocol, source-port-range-or-operator, destination-port- range-or-operator, destination-ipv4-network, source- ipv4-network,and v6-fragments TCP flags ICMP type and code Please comment/update. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 16 f=E9vrier 2018 14:55 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields +1. In TCP, only "flags" field looks mandatory. -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 7:03 PM To: Jon Shallow >; Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields Re-, I tend to agree with you to have to define a minimum set of mandatory match= fields. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 16 f=E9vrier 2018 14:29 =C0 : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; dots@ietf.org Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields Hi Med, See inline [Jon] Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 16 February 2018 12:56 To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields Jon, Thank you for sharing your thoughts. Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 16 f=E9vrier 2018 13:24 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org= Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields I like the concept of "+--ro capabilities" allowing for future support as t= he DOS server becomes more mature in its capabilities. If a DOTS client includes a filtering field parameter that is not currently= supported, should the parameter be ignored (and not returned for a GET), o= r the request rejected? [Med] I would vote for rejecting the request. The client should only use ma= tch criteria that are understood by the server; otherwise there will be dif= ferent expectation from the service. [Jon] I think that this is my preference - I was just seeking clarity of th= inking. It is conceivable that a DOTS client has 2 DOTS servers (one possibly a bac= kup, or 2 different ISPs), which may have differing filtering field paramet= er support capabilities. [Med] The backup/case seems odd. I would expect a feature parity for a redu= ndancy group used to provide the same service. [Jon] Agreed that a backup server is most likely to be from the same manufa= cturer and hence support the same functionality. But one may have just bee= n upgraded to have extra support. Adding in intelligence code to work out what is / is not allowed may not = be practical in a (memory or cpu) constrained environment of the DOTS clien= t. [Med] Fair. That said, I think we need to define the minimum set of supported parameter= s - e.g. protocol, source / dest ports, source / dest IPv4 prefixes, sourc= e / dest IPv6 prefixes, fragments and icmp type/code. [Jon] Any comments? -Jon Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 16 February 2018 10:18 To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields Hi Med, Please see inline [TR2] From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 1:45 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: draft-ietf-dots-data-channel: Filtering Fields Re-, Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 16 f=E9vrier 2018 08:00 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Wednesday, February 14, 2018 1:49 PM To: dots@ietf.org Subject: [Dots] draft-ietf-dots-data-channel: Filtering Fields Hi all, As agreed during the interim, there are some issues that need fixes in the = data-channel spec. We would like to hear from the WG to know what to record= in the document. Issue description: Should we support all of the match fields defined by "ie= tf-packet-fields" or do we need to define a minimum supported set? [TR] I don't see the need to support all the match fields, define a minimum= supported set (don't see the use for acl-eth-header-fields for DOTS use ca= ses). [Med] Agree that acl-eth-header-fields aren't required. The text is already= clear about this: DOTS implementations MUST support the following matching criteria: match based on the IP header (IPv4 and IPv6), match based on the transport header (TCP, UDP, and ICMP), and any combination thereof. The question is whether we need to go further and mandate (or not) the supp= ort of matching based on specific fields: dscp, ecn, ttl,... flow-label, ..= . tcp sequence-number, tcp flags, ... [TR2] https://tools.ietf.org/html/draft-ietf-netmod-acl-model-16 uses the f= eature statements in the YANG model allowing vendors to advertise match rul= es they are capable and willing to support but not at the field-level. The = problem is router implementations today don't support ACLs with tcp sequenc= e-number, acknowledgement-number, window-size etc but support TCP flags. If= the server could convey the list of match criteria supported, it not only = allows the client to convey the supported match rules but also allows the s= erver in future to advertise the new supported match fields. Would it be useful for a client to retrieve the list of match criteria supp= orted by a DOTS server? [TR2] Yes. -Tiru [TR] The YANG model supported by the DOTS server can retrieved by the DOTS = client using RESTCONF to determine the match criteria supported by the serv= er. [Med] I'm afraid this is not the same functionality. If we need to allow a = server to return its supported match criteria, this should be allowed by th= e module. For example, the module may include the following (example): +--ro capabilities | +--ro match-header* | | identityref | +--ro transport-protocols* [protocol-id] | | +--ro protocol-id uint8 | | +--ro protocol-name? string | +--ro dscp-support? boolean | +--ro ecn-support? boolean | +--ro length-support? boolean | +--ro ttl-support? boolean | +--ro protocol-support? boolean The client can ask the server to return its supported match criteria. The s= erver will indicate the exact set of fields it supports. I'm not expressing a preference to have this in the model, but I'm clarifyi= ng how it would look like. -Tiru Please comment. Cheers, Med --_000_BN6PR16MB1777DEC1B64F91F0ADD45D3BEAC80BN6PR16MB1777namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I don't t= hink router vendors support ranges for TTL fields !

&nbs= p;

-Tiru

 

From:<= /span> mohamed.boucadair@ora= nge.com [mailto:mohamed.boucadair@orange.com]
Sent: Monday, February 19, 2018 1:22 PM
To: Jon Shallow <supjps-ietf@jpshallow.com>; Konda, Tirumalesw= ar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: draft-ietf-dots-data-channel: Value and/or Range=

 

Hi Jon,

 

Good point.

 

Actually, some filtering parameters are worth = to be supplied as values or ranges but the current netmod module does not a= llow for it. I can cite:

=B7       =   Length fields=

=B7       =   TTL

 

Do we need to have value/range supported in th= e module for these fields?

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : vendredi 16 f=E9vrier 2018 17:14
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; <= a href=3D"mailto:dots@ietf.org"> dots@ietf.org
Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fiel= ds

 

Ttl is = an interesting one.  It is not definable as a range, and so if you wan= t to match “ttl lt 16” you are going to have to have 16 ACLs pr= eceding any other ACL that does anything else.

&n= bsp;

I would= expect that ‘ttl’ would be done properly as a one of the mitig= ator rules, and DOTS does not need to ‘hint’ it as well.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 16 February 2018 15:46
To: mohamed.boucadai= r@orange.com; Jon Shallow; dots@ietf.org
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields

 

We may wa= nt to add

&nbs= p;

1) &nb= sp;    UDP (length) to the list.= It may be useful to block large DNS packets (e.g. DNS amplification attack= ).

2) &nb= sp;    In IPv4/IPv6, add length,= ttl (https://www.cisco.com/c/en/us/about/security-center/ttl-e= xpiry-attack.html) to the list.

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Friday, February 16, 2018 8:04 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields

 

Re-,

 

Here is a tentative list:

 

   Header Mandatory Fiel= ds

   ------ --------------= ------------------------------------------------

   IPv4   prot= ocol, source-port-range-or-operator, destination-port-

     &nbs= p;    range-or-operator, destination-ipv4-network, source-

     &nbs= p;    ipv4-network, and v4-fragments

   IPv6   prot= ocol, source-port-range-or-operator, destination-port-

     &nbs= p;    range-or-operator, destination-ipv4-network, source-

     &nbs= p;    ipv4-network,and v6-fragments

   TCP   = flags

   ICMP   type and code

 

Please comment/update.

 

Cheers,

Med=

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : vendredi 16 f=E9vrier 2018 14:55
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fiel= ds

 

+1. I= n TCP, only “flags” field looks mandatory.

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Friday, February 16, 2018 7:03 PM
To: Jon Shallow <sup= jps-ietf@jpshallow.com>; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org
Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields

 

Re-,

 

I tend to agree with you to have to define a m= inimum set of mandatory match fields.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : vendredi 16 f=E9vrier 2018 14:29
=C0 : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; dots@ietf.org
Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fiel= ds

 

Hi Med,=

&n= bsp;

See inl= ine [Jon]

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 16 February 2018 12:56
To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields

 

Jon,

 

Thank you for sharing your thoughts.

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : vendredi 16 f=E9vrier 2018 13:24
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; <= a href=3D"mailto:dots@ietf.org"> dots@ietf.org
Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fiel= ds

 

I like the concept of “+=
--ro capabilities“ allowing for future support as t=
he DOS server becomes more mature in its capabilities.

 


If a DOTS client includes a filtering field parameter that =
is not currently supported, should the parameter be ignored (and not return=
ed for a GET), or the request rejected?


[Med] I would vote for re=
jecting the request. The client should only use match criteria that are und=
erstood by the server; otherwise there will be different expectation from t=
he service. 


[Jon] I think that this is my preference – I was just=
 seeking clarity of thinking.


<=
o:p> 


It is conceivable that a DOTS client has 2 DOTS servers (on=
e possibly a backup, or 2 different ISPs), which may have differing filteri=
ng field parameter support capabilities.


[Med] The backup/case see=
ms odd. I would expect a feature parity for a redundancy group used to prov=
ide the same service.=



[=
Jon] Agreed that a backup server is most likely to be from the same manufac=
turer and hence support the same functionality.  But one may have just=
 been upgraded to have extra support.


<=
o:p> 


 <=
/pre>

 <=
/pre>

  Adding in intelligence code to work out what is / is=
 not allowed may not be practical in a (memory or cpu) constrained environm=
ent of the DOTS client.


[Med] Fair. 


 


That said, I think we need to define the minimum set of sup=
ported parameters – e.g. protocol, source / dest ports,  source =
/ dest IPv4 prefixes, source / dest IPv6 prefixes, fragments and icmp type/=
code. 


[Jon] Any comments?


<=
o:p> 


-=
Jon


<=
o:p> 


Regards


 


Jon


&n=
bsp;






From: Dots [mailto:
dots-bounces@ietf.org] On B=
ehalf Of
Konda, Tirumaleswar Reddy

Sent: 16 February 2018 10:18

To: mohamed.boucadai=
r@orange.com;
dots@ietf.org

Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields






 


Hi Med,


&nbs=
p;


Please se=
e inline [TR2]


&nbs=
p;








From:<=
/span>
mohamed.boucadair@orange.co=
m [mailto:mohamed.bouca=
dair@orange.com]


Sent: Friday, February 16, 2018 1:45 PM

To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>;
dots@ietf.org

Subject: RE: draft-ietf-dots-data-channel: Filtering Fields






 


Re-,


 


Please see inline.



 


Cheers,


Med


 








De : Dots [mailto:dots-bounces@ietf.org]
De la part de Konda, Tirumaleswar Reddy

Envoy=E9 : vendredi 16 f=E9vrier 2018 08:00

=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org

Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fiel=
ds






 


From:<=
/span> Dots [mailto:dots-bounces@ietf.org]
On Behalf Of mohamed=
.boucadair@orange.com

Sent: Wednesday, February 14, 2018 1:49 PM

To: dots@ietf.org

Subject: [Dots] draft-ietf-dots-data-channel: Filtering Fields<=
/o:p>


 


Hi all,



 


As agreed during the interim, there are some issues that n=
eed fixes in the data-channel spec. We would like to hear from the WG to kn=
ow what to record in the document.



 


Issue description: Should we support all of the match fiel=
ds defined by “ietf-packet-fields” or do we need to define a mi=
nimum supported set?



 


[TR] I don’t see the need to support all the m=
atch fields, define a minimum supported set (don’t see the use for ac=
l-eth-header-fields for DOTS use cases).  


[Med] Agree that acl-eth-header-fields aren=
217;t required. The text is already clear about this:


 


DOTS implementations MUST support =
the following


   matching criteria: ma=
tch based on the IP header (IPv4 and IPv6),


   match based on the tr=
ansport header (TCP, UDP, and ICMP), and any


  
combination thereof.=



 


The question is whether we need to go fu=
rther and mandate (or not) the support of matching based on specific fields=
: dscp, ecn, ttl,… flow-label, … tcp s=
equence-number, tcp flags, …  <=
/o:p>


 


[TR2] https://tools.ietf.o=
rg/html/draft-ietf-netmod-acl-model-16 uses the feature statements in the YANG model allowin=
g vendors to advertise match rules they are capable and willing to support =
but not at the field-level. The problem is router implementations today don=
’t support ACLs with tcp sequence-number, acknowledgement-number, win=
dow-size etc but support TCP flags. If the server could convey the list of =
match criteria supported, it not only allows the client to convey the suppo=
rted match rules but also allows the server in future to advertise the new =
supported match fields.   


 


Would it be useful for a client to retrieve the list of ma=
tch criteria supported by a DOTS server?



 


[TR2] Yes. 


 


-Tiru


 


[TR] The YANG model supported by the DOTS server can=
 retrieved by the DOTS client using RESTCONF to determine the match criteri=
a supported by the server.



[Med] I’m afraid this is not the same fu=
nctionality. If we need to allow a server to return its supported match cri=
teria, this should be allowed by the module. For example,
 the module may include the following (example): 


 


        &nbs=
p;       +--ro capabilities


        &nbs=
p;       |  +--ro match-header*=



        &nbs=
p;       |  |    &nb=
sp;  identityref


        &nbs=
p;       |  +--ro transport-protocol=
s* [protocol-id]


        &nbs=
p;       |  |  +--ro protocol-i=
d      uint8


        &nbs=
p;       |  |  +--ro protocol-n=
ame?   string


        &nbs=
p;       |  +--ro dscp-support? &nbs=
p;     boolean


        &nbs=
p;       |  +--ro ecn-support?  =
;      boolean


        &nbs=
p;       |  +--ro length-support? &n=
bsp;   boolean


        &nbs=
p;       |  +--ro ttl-support?  =
;      boolean


        &nbs=
p;       |  +--ro protocol-support? =
  boolean


 


The client can ask the server to return its supported match criteria. The server will indicate the =
exact set of fields it supports. 


 


I’m not expressing a preference to=
 have this in the model, but I’m clarifying how it would look like. <=
/span>


 


-Tiru


 


Please comment.



 <=
/p>

Cheers,=



Med
--_000_BN6PR16MB1777DEC1B64F91F0ADD45D3BEAC80BN6PR16MB1777namp_-- From nobody Mon Feb 19 02:36:37 2018 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 0600612025C for ; Mon, 19 Feb 2018 02:36:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 pUKjsdLhTPf9 for ; Mon, 19 Feb 2018 02:36:33 -0800 (PST) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EFB012706D for ; Mon, 19 Feb 2018 02:36:32 -0800 (PST) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id D03D4A1781; Mon, 19 Feb 2018 11:36:30 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.61]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id A2A3F20066; Mon, 19 Feb 2018 11:36:30 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7E.corporate.adroot.infra.ftgroup ([fe80::b91c:ea2c:ac8a:7462%19]) with mapi id 14.03.0382.000; Mon, 19 Feb 2018 11:36:30 +0100 From: To: "Konda, Tirumaleswar Reddy" , "Jon Shallow" , "dots@ietf.org" Thread-Topic: draft-ietf-dots-data-channel: Value and/or Range Thread-Index: AdOpVo4UGaF3iP8sRF6zMQH8hhSSfwAFG7oQAAB2BpA= Date: Mon, 19 Feb 2018 10:36:29 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0D455E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300A0D42F4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A0D455EOPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] draft-ietf-dots-data-channel: Value and/or Range 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, 19 Feb 2018 10:36:36 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A0D455EOPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, I can cite at least these two router vendors: =B7 https://www.juniper.net/documentation/en_US/junos/topics/refere= nce/general/firewall-filter-match-conditions-for-ipv4-traffic.html =B7 https://infoproducts.alcatel-lucent.com/html/0_add-h-f/93-0073-= HTML/7750_SR_OS_Router_Configuration_Guide/filters.html Cheers, Med De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] Envoy=E9 : lundi 19 f=E9vrier 2018 11:19 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : RE: draft-ietf-dots-data-channel: Value and/or Range I don't think router vendors support ranges for TTL fields ! -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Monday, February 19, 2018 1:22 PM To: Jon Shallow >; Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: draft-ietf-dots-data-channel: Value and/or Range Hi Jon, Good point. Actually, some filtering parameters are worth to be supplied as values or r= anges but the current netmod module does not allow for it. I can cite: * Length fields * TTL Do we need to have value/range supported in the module for these fields? Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 16 f=E9vrier 2018 17:14 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org= Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields Ttl is an interesting one. It is not definable as a range, and so if you w= ant to match "ttl lt 16" you are going to have to have 16 ACLs preceding an= y other ACL that does anything else. I would expect that 'ttl' would be done properly as a one of the mitigator = rules, and DOTS does not need to 'hint' it as well. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 16 February 2018 15:46 To: mohamed.boucadair@orange.com; Jon = Shallow; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields We may want to add 1) UDP (length) to the list. It may be useful to block large DNS packe= ts (e.g. DNS amplification attack). 2) In IPv4/IPv6, add length, ttl (https://www.cisco.com/c/en/us/about/= security-center/ttl-expiry-attack.html) to the list. -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 8:04 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields Re-, Here is a tentative list: Header Mandatory Fields ------ -------------------------------------------------------------- IPv4 protocol, source-port-range-or-operator, destination-port- range-or-operator, destination-ipv4-network, source- ipv4-network, and v4-fragments IPv6 protocol, source-port-range-or-operator, destination-port- range-or-operator, destination-ipv4-network, source- ipv4-network,and v6-fragments TCP flags ICMP type and code Please comment/update. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 16 f=E9vrier 2018 14:55 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields +1. In TCP, only "flags" field looks mandatory. -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 7:03 PM To: Jon Shallow >; Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields Re-, I tend to agree with you to have to define a minimum set of mandatory match= fields. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 16 f=E9vrier 2018 14:29 =C0 : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; dots@ietf.org Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields Hi Med, See inline [Jon] Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 16 February 2018 12:56 To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields Jon, Thank you for sharing your thoughts. Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 16 f=E9vrier 2018 13:24 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org= Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields I like the concept of "+--ro capabilities" allowing for future support as t= he DOS server becomes more mature in its capabilities. If a DOTS client includes a filtering field parameter that is not currently= supported, should the parameter be ignored (and not returned for a GET), o= r the request rejected? [Med] I would vote for rejecting the request. The client should only use ma= tch criteria that are understood by the server; otherwise there will be dif= ferent expectation from the service. [Jon] I think that this is my preference - I was just seeking clarity of th= inking. It is conceivable that a DOTS client has 2 DOTS servers (one possibly a bac= kup, or 2 different ISPs), which may have differing filtering field paramet= er support capabilities. [Med] The backup/case seems odd. I would expect a feature parity for a redu= ndancy group used to provide the same service. [Jon] Agreed that a backup server is most likely to be from the same manufa= cturer and hence support the same functionality. But one may have just bee= n upgraded to have extra support. Adding in intelligence code to work out what is / is not allowed may not = be practical in a (memory or cpu) constrained environment of the DOTS clien= t. [Med] Fair. That said, I think we need to define the minimum set of supported parameter= s - e.g. protocol, source / dest ports, source / dest IPv4 prefixes, sourc= e / dest IPv6 prefixes, fragments and icmp type/code. [Jon] Any comments? -Jon Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 16 February 2018 10:18 To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields Hi Med, Please see inline [TR2] From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 1:45 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: draft-ietf-dots-data-channel: Filtering Fields Re-, Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 16 f=E9vrier 2018 08:00 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Wednesday, February 14, 2018 1:49 PM To: dots@ietf.org Subject: [Dots] draft-ietf-dots-data-channel: Filtering Fields Hi all, As agreed during the interim, there are some issues that need fixes in the = data-channel spec. We would like to hear from the WG to know what to record= in the document. Issue description: Should we support all of the match fields defined by "ie= tf-packet-fields" or do we need to define a minimum supported set? [TR] I don't see the need to support all the match fields, define a minimum= supported set (don't see the use for acl-eth-header-fields for DOTS use ca= ses). [Med] Agree that acl-eth-header-fields aren't required. The text is already= clear about this: DOTS implementations MUST support the following matching criteria: match based on the IP header (IPv4 and IPv6), match based on the transport header (TCP, UDP, and ICMP), and any combination thereof. The question is whether we need to go further and mandate (or not) the supp= ort of matching based on specific fields: dscp, ecn, ttl,... flow-label, ..= . tcp sequence-number, tcp flags, ... [TR2] https://tools.ietf.org/html/draft-ietf-netmod-acl-model-16 uses the f= eature statements in the YANG model allowing vendors to advertise match rul= es they are capable and willing to support but not at the field-level. The = problem is router implementations today don't support ACLs with tcp sequenc= e-number, acknowledgement-number, window-size etc but support TCP flags. If= the server could convey the list of match criteria supported, it not only = allows the client to convey the supported match rules but also allows the s= erver in future to advertise the new supported match fields. Would it be useful for a client to retrieve the list of match criteria supp= orted by a DOTS server? [TR2] Yes. -Tiru [TR] The YANG model supported by the DOTS server can retrieved by the DOTS = client using RESTCONF to determine the match criteria supported by the serv= er. [Med] I'm afraid this is not the same functionality. If we need to allow a = server to return its supported match criteria, this should be allowed by th= e module. For example, the module may include the following (example): +--ro capabilities | +--ro match-header* | | identityref | +--ro transport-protocols* [protocol-id] | | +--ro protocol-id uint8 | | +--ro protocol-name? string | +--ro dscp-support? boolean | +--ro ecn-support? boolean | +--ro length-support? boolean | +--ro ttl-support? boolean | +--ro protocol-support? boolean The client can ask the server to return its supported match criteria. The s= erver will indicate the exact set of fields it supports. I'm not expressing a preference to have this in the model, but I'm clarifyi= ng how it would look like. -Tiru Please comment. Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300A0D455EOPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

I can cite at least these two r= outer vendors:

=B7    &n= bsp;    https://www.juniper.net/documen= tation/en_US/junos/topics/reference/general/firewall-filter-match-condition= s-for-ipv4-traffic.html

=B7    &n= bsp;    https://infoproducts.alcatel-lucent.com/ht= ml/0_add-h-f/93-0073-HTML/7750_SR_OS_Router_Configuration_Guide/filters.htm= l

 

Cheers,

Med

 

De : Konda, Tirumaleswar Reddy [mail= to:TirumaleswarReddy_Konda@McAfee.com]
Envoy=E9 : lundi 19 f=E9vrier 2018 11:19
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet : RE: draft-ietf-dots-data-channel: Value and/or Range

 

I don't think router vendors support ranges for TTL fields !

 

-Tiru

 

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Monday, February 19, 2018 1:22 PM
To: Jon Shallow <sup= jps-ietf@jpshallow.com>; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org
Subject: draft-ietf-dots-data-channel: Value and/or Range=

 

Hi Jon,

 

Good point.

 

Actually, some filtering parame= ters are worth to be supplied as values or ranges but the current netmod mo= dule does not allow for it. I can cite:

=B7<= span lang=3D"EN-US" style=3D"font-size:7.0pt;font-family:"Times New Ro= man","serif";color:black">     &nbs= p;   Length fields

=B7<= span lang=3D"EN-US" style=3D"font-size:7.0pt;font-family:"Times New Ro= man","serif";color:black">     &nbs= p;   TTL

 

Do we need to have value/range = supported in the module for these fields?

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : vendredi 16 f=E9vrier 2018 17:14
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; <= a href=3D"mailto:dots@ietf.org"> dots@ietf.org
Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fiel= ds

 

Ttl is = an interesting one.  It is not definable as a range, and so if you wan= t to match “ttl lt 16” you are going to have to have 16 ACLs pr= eceding any other ACL that does anything else.

&n= bsp;

I would= expect that ‘ttl’ would be done properly as a one of the mitig= ator rules, and DOTS does not need to ‘hint’ it as well.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 16 February 2018 15:46
To: mohamed.boucadai= r@orange.com; Jon Shallow; dots@ietf.org
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields

 

We may want to add

 

1)      UDP (lengt= h) to the list. It may be useful to block large DNS packets (e.g. DNS ampli= fication attack).

2)      In IPv4/IP= v6, add length, ttl (https://www.cisco.com/c/en/us/about/securi= ty-center/ttl-expiry-attack.html) to the list.

 

-Tiru

 

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Friday, February 16, 2018 8:04 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields

 

Re-,

 

Here is a tentative list:

 

   Header= Mandatory Fields

   ------= --------------------------------------------------------------<= /span>

   IPv4&n= bsp;  protocol, source-port-range-or-operator, destination-port-<= /o:p>

   &= nbsp;      range-or-operator, destination-ipv4-net= work, source-

   &= nbsp;      ipv4-network, and v4-fragments

   IPv6&n= bsp;  protocol, source-port-range-or-operator, destination-port-<= /o:p>

   &= nbsp;      range-or-operator, destination-ipv4-net= work, source-

   &= nbsp;      ipv4-network,and v6-fragments

   TCP&nb= sp;   flags

   ICMP   type and code

 

Please comment/update.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : vendredi 16 f=E9vrier 2018 14:55
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fiel= ds

 

+1. In TCP, only “flags” field looks mandatory.

 

-Tiru

 

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Friday, February 16, 2018 7:03 PM
To: Jon Shallow <sup= jps-ietf@jpshallow.com>; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org
Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields

 

Re-,

 

I tend to agree with you to hav= e to define a minimum set of mandatory match fields.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : vendredi 16 f=E9vrier 2018 14:29
=C0 : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; dots@ietf.org
Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fiel= ds

 

Hi Med,=

&n= bsp;

See inl= ine [Jon]

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 16 February 2018 12:56
To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields

 

Jon,

 

Thank you for sharing your thou= ghts.

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : vendredi 16 f=E9vrier 2018 13:24
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; <= a href=3D"mailto:dots@ietf.org"> dots@ietf.org
Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fiel= ds

 

I like the concept of “+--ro capabilities“ allowing for futu=
re support as the DOS server becomes more mature in its capabilities.<=
/o:p>
 
If a DOTS client includes a filtering field parameter that =
is not currently supported, should the parameter be ignored (and not return=
ed for a GET), or the request rejected?
[Med] I would vote for re=
jecting the request. The client should only use match criteria that are und=
erstood by the server; otherwise there will be different expectation from t=
he service. 
[Jon] I think that this is my preference – I was just=
 seeking clarity of thinking.
<=
o:p> 
It is conceivable that a DOTS client has 2 DOTS servers (on=
e possibly a backup, or 2 different ISPs), which may have differing filteri=
ng field parameter support capabilities.
[Med] The backup/case see=
ms odd. I would expect a feature parity for a redundancy group used to prov=
ide the same service.=

[=
Jon] Agreed that a backup server is most likely to be from the same manufac=
turer and hence support the same functionality.  But one may have just=
 been upgraded to have extra support.
<=
o:p> 
 <=
/pre>

 <=
/pre>

  Adding in intelligence code to work out what is / is=
 not allowed may not be practical in a (memory or cpu) constrained environm=
ent of the DOTS client.


[Med] Fair. 


 


That said, I think we need to define the minimum set of sup=
ported parameters – e.g. protocol, source / dest ports,  source =
/ dest IPv4 prefixes, source / dest IPv6 prefixes, fragments and icmp type/=
code. 


[Jon] Any comments?


<=
o:p> 


-=
Jon


<=
o:p> 


Regards


 


Jon


&n=
bsp;






From:=
 Dots [mailto:
dots-bounces@ietf.org] On B=
ehalf Of
Konda, Tirumaleswar Reddy

Sent: 16 February 2018 10:18

To: mohamed.boucadai=
r@orange.com;
dots@ietf.org

Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields






 


Hi Med,


 


Please see inline [TR2]


 








From:
mohamed.boucadair@orange.co=
m [mailto:mohamed.bouca=
dair@orange.com]


Sent: Friday, February 16, 2018 1:45 PM

To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>;
dots@ietf.org

Subject: RE: draft-ietf-dots-data-channel: Filtering Fields






 


Re-,


 


Please see inline.



 


Cheers,


Med


 








De : Dots [mailto:dots-bounces@ietf.org]
De la part de Konda, Tirumaleswar Reddy

Envoy=E9 : vendredi 16 f=E9vrier 2018 08:00

=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org

Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fiel=
ds






 


From: Dots [mailto:dots-bounces=
@ietf.org]
On Behalf Of mohamed=
.boucadair@orange.com

Sent: Wednesday, February 14, 2018 1:49 PM

To: dots@ietf.org

Subject: [Dots] draft-ietf-dots-data-channel: Filtering Fields<=
/o:p>


 


Hi all,



 


As agreed during the interim, there are som=
e issues that need fixes in the data-channel spec. We would like to hear fr=
om the WG to know what to record in the document.



 


Issue description: Should we support all of=
 the match fields defined by “ietf-packet-fields” or do we need=
 to define a minimum supported set?



 


[TR] I don’t see the need=
 to support all the match fields, define a minimum supported set (don’=
;t see the use for acl-eth-header-fields for DOTS use cases).  


[Med] Agree that acl-eth-header=
-fields aren’t required. The text is already clear about this:


 


DOTS implementation=
s MUST support the following


   matchi=
ng criteria: match based on the IP header (IPv4 and IPv6),


   match =
based on the transport header (TCP, UDP, and ICMP), and any


  
combination thereof.


 


The question is whether w=
e need to go further and mandate (or not) the support of matching based on =
specific fields: dscp, ecn, ttl,… flow-label, … tcp sequence-number, tcp flags, …  


 


[TR2] https=
://tools.ietf.org/html/draft-ietf-netmod-acl-model-16 uses the feature statem=
ents in the YANG model allowing vendors to advertise match rules they are c=
apable and willing to support but not at the field-level. The problem is ro=
uter implementations today don’t support ACLs with tcp sequence-numbe=
r, acknowledgement-number, window-size etc but support TCP flags. If the se=
rver could convey the list of match criteria supported, it not only allows =
the client to convey the supported match rules but also allows the server i=
n future to advertise the new supported match fields.   


 


Would it be useful for a client to retrieve=
 the list of match criteria supported by a DOTS server?



 


[TR2] Yes. 

 


-Tiru


 


[TR] The YANG model supported b=
y the DOTS server can retrieved by the DOTS client using RESTCONF to determ=
ine the match criteria supported by the server.



[Med] I’m afraid this is =
not the same functionality. If we need to allow a server to return its supp=
orted match criteria, this should be allowed by the module.
 For example, the module may include the following (example): 


 


      &=
nbsp;         +--ro capabilitie=
s


      &=
nbsp;         |  +--ro mat=
ch-header*


      &=
nbsp;         |  |  =
     identityref


      &=
nbsp;         |  +--ro tra=
nsport-protocols* [protocol-id]


      &=
nbsp;         |  |  +=
--ro protocol-id      uint8

      &=
nbsp;         |  |  +=
--ro protocol-name?   string


      &=
nbsp;         |  +--ro dsc=
p-support?       boolean

      &=
nbsp;         |  +--ro ecn=
-support?        boolean


      &=
nbsp;         |  +--ro len=
gth-support?     boolean


      &=
nbsp;         |  +--ro ttl=
-support?        boolean


      &=
nbsp;         |  +--ro pro=
tocol-support?   boolean


 


The client can ask the server to retu=
rn its supported match criteria. The server wil=
l indicate the exact set of fields it supports. 

 <=
/pre>

I’m not expressing =
a preference to have this in the model, but I’m clarifying how it wou=
ld look like. 

 


-Tiru


 


Please com=
ment.



 =
;


Cheers,


Med=
<=
/o:p>
--_000_787AE7BB302AE849A7480A190F8B93300A0D455EOPEXCLILMA3corp_-- From nobody Mon Feb 19 08:05:35 2018 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 0E4B7120721 for ; Mon, 19 Feb 2018 08:05:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 diqlt6bIsaHG for ; Mon, 19 Feb 2018 08:05:30 -0800 (PST) Received: from mx0a-00196b01.pphosted.com (mx0b-00196b01.pphosted.com [67.231.157.166]) (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 D8B341205F0 for ; Mon, 19 Feb 2018 08:05:29 -0800 (PST) Received: from pps.filterd (m0072399.ppops.net [127.0.0.1]) by mx0b-00196b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1JG1qFu003188; Mon, 19 Feb 2018 11:05:27 -0500 Received: from nam03-dm3-obe.outbound.protection.outlook.com (mail-dm3nam03lp0018.outbound.protection.outlook.com [207.46.163.18]) by mx0b-00196b01.pphosted.com with ESMTP id 2g7v1jrabk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 19 Feb 2018 11:05:27 -0500 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=4BE/m8AV52HcW1OIUsn+UpC2BTz8rTp9o86pDnCKjPg=; b=kT2GWp8hMmzYtb85e3qlhnLuXWlfMS/EiNEB20Vd39FTaBNVkjG4PXaXb3rWFsKswv6+pxD+3wwhY8VnOaUXqWgyDhboBrKZbXDen1D9Oe7NGmDeVWKq0U5uzC1OUdYSVykDslkMQJEPrA9fQa1x3jl+UI5dFfUhq3C4jqGb8uU= Received: from BN3PR0101MB1028.prod.exchangelabs.com (10.160.182.16) by BN3PR0101MB1121.prod.exchangelabs.com (10.161.219.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.18; Mon, 19 Feb 2018 16:05:25 +0000 Received: from BN3PR0101MB1028.prod.exchangelabs.com ([10.160.182.16]) by BN3PR0101MB1028.prod.exchangelabs.com ([10.160.182.16]) with mapi id 15.20.0506.023; Mon, 19 Feb 2018 16:05:25 +0000 From: "Dobbins, Roland" To: "Konda, Tirumaleswar Reddy" CC: "mohamed.boucadair@orange.com" , Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] draft-ietf-dots-data-channel: Value and/or Range Thread-Index: AdOpVo4UGaF3iP8sRF6zMQH8hhSSfwAFG7oQAAwdrEQ= Date: Mon, 19 Feb 2018 16:05:24 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A0D42F4@OPEXCLILMA3.corporate.adroot.infra.ftgroup>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [184.82.239.49] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0101MB1121; 7:4qSQFW+J8mdWE/SgsIziFf6iRLtGLH51u+dcqVvKUR9Wu1Amwdzl9b6GxQlXkR39tVmFjaHTNNsHvxXV/MblZvbz1mJNZrLoLHK406dedAdnesyO0pZt9rv2SjwyZyzpk847k1wj/SVoJf+PzrrsJr9LtsqkGQ7rvpf8spsdi4bxyOcAE3TsdjmeCkkmH+8al7CwbIZmr7yPOdVv3jOWWKNZZUvKmZlqrtyeSOXwJp+A1aJ/pzMtU0jOk3flXh63 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 24654a2f-8fc9-4662-7820-08d577b29655 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:BN3PR0101MB1121; x-ms-traffictypediagnostic: BN3PR0101MB1121: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(3231101)(944501161)(10201501046)(6041288)(20161123558120)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011); SRVR:BN3PR0101MB1121; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0101MB1121; x-forefront-prvs: 0588B2BD96 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(39380400002)(39850400004)(396003)(366004)(199004)(189003)(2900100001)(229853002)(59450400001)(4326008)(99286004)(76176011)(6246003)(6512007)(97736004)(54906003)(66066001)(105586002)(33656002)(305945005)(53936002)(316002)(7736002)(25786009)(5660300001)(6116002)(3846002)(36756003)(8676002)(82746002)(3660700001)(6436002)(478600001)(14454004)(83716003)(106356001)(68736007)(6506007)(77096007)(2950100002)(3280700002)(6486002)(53546011)(2906002)(8936002)(26005)(81166006)(81156014)(86362001)(102836004)(6916009)(186003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0101MB1121; H:BN3PR0101MB1028.prod.exchangelabs.com; 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-antispam-message-info: d64MaLSC40Au437gUas1H1FLnHGMzEKVNmGYLRu4acHZfzona3rd7LmRqnHCKqfSxRNSIQpXQZy3x90y8Y73GXEYHgLQRAgHPFdZodRpgj+AJ1WP8g20+VIEH5UvJIppv6c/j7pmgPG0Q3UIInGMKZ63RkqrMaC8PwR2Ls3R8WI= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-Network-Message-Id: 24654a2f-8fc9-4662-7820-08d577b29655 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2018 16:05:25.0048 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0101MB1121 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-19_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802190199 Archived-At: Subject: Re: [Dots] draft-ietf-dots-data-channel: Value and/or Range 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, 19 Feb 2018 16:05:34 -0000 > On Feb 19, 2018, at 17:20, Konda, Tirumaleswar Reddy wrote: >=20 > I don't think router vendors support ranges for TTL fields ! Most don't.=20 Still confused & dismayed that we're falling down the rabbit hole of re-imp= lementing flowspec in DOTS. This is adding needless & unwanted complexity to DOTS. DOTS nodes should si= mply self-describe their protocols/ports, & figuring out what network acces= s policies to wrap around them should take place outside the scope of DOTS.= =20 Very strong objections to all this ACL stuff. =20 ----------------------------------- Roland Dobbins From nobody Mon Feb 19 08:10:40 2018 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 D5B05124BAC for ; Mon, 19 Feb 2018 08:10:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 (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 anOZKJNR6NFk for ; Mon, 19 Feb 2018 08:10:38 -0800 (PST) Received: from mx0a-00196b01.pphosted.com (mx0b-00196b01.pphosted.com [67.231.157.166]) (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 05DAC1205F0 for ; Mon, 19 Feb 2018 08:10:37 -0800 (PST) Received: from pps.filterd (m0096262.ppops.net [127.0.0.1]) by mx0b-00196b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1JG8DDZ020532; Mon, 19 Feb 2018 11:10:37 -0500 Received: from nam02-cy1-obe.outbound.protection.outlook.com (mail-cys01nam02lp0054.outbound.protection.outlook.com [207.46.163.54]) by mx0b-00196b01.pphosted.com with ESMTP id 2g7vfgga5s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 19 Feb 2018 11:10:36 -0500 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=uR7/9Ssq0ajlt0T6dCrfjKR7pK3uqcEGXraj7g+a5hA=; b=CqfPI9dbt8IDZl0Go6heCefCqeiaXL02sf0S9x2ejYPhM064OWDj7cLN0Yx2TqlBvza874xVwaGAhoqt7mV9bkeuc/isGNhmq93VBWjtsZK+6gAThu7+QZSE3/DuXO4kYDLp3AI77VG+sNZQJtrbi+kqJrI/81P1GX07VfHnw7M= Received: from BN3PR0101MB1028.prod.exchangelabs.com (10.160.182.16) by BN3PR0101MB1121.prod.exchangelabs.com (10.161.219.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.18; Mon, 19 Feb 2018 16:10:34 +0000 Received: from BN3PR0101MB1028.prod.exchangelabs.com ([10.160.182.16]) by BN3PR0101MB1028.prod.exchangelabs.com ([10.160.182.16]) with mapi id 15.20.0506.023; Mon, 19 Feb 2018 16:10:34 +0000 From: "Dobbins, Roland" To: "Konda, Tirumaleswar Reddy" CC: Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: [Dots] Call home in the signal channel (was RE: draft-ietf-dots-data-channel: Filter Direction) Thread-Index: AdOnD40ix0FBs+3eR3Kr9ibwuvod3gABX+FgAAI+QYAAAnp+gAAA8WaAAAFXeQAAAn2fgABZ7WaAACWSQQAABbjJAAAEIts4AAHa7IAADRJaCQ== Date: Mon, 19 Feb 2018 16:10:34 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A0D3439@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00d201d3a71e$05ead590$11c080b0$@jpshallow.com> <01b401d3a72b$b5a79f10$20f6dd30$@jpshallow.com> <022001d3a73b$09b1c270$1d154750$@jpshallow.com> <395E0F43-03F3-46F0-821D-50A53577E5B3@arbor.net>, <12A41D38-1E81-4677-96A1-4CFACA203026@arbor.net>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [184.82.239.49] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0101MB1121; 7:rw5DyEyNrHPX/gnw/KiAqRWh2+oB8UYAbMCVe89SEDtjXD3DGZG/cAfk9RtXTnGWB38YZykRDE2MnLGI9zup23Un/VvNKJhPQTB3V2U9lGer0WwNqGmASsjPaBNF+P0A8l3cG27Me2BeZuOFY07tmanxz6IpqB6xx8vB/9isuyzrUfPmw9jxaRT8lem7fUxtFw88701X2l6b65/uCf2yVvIBRvXj9VHsRLX2m+HTAvtcNmC7IGyHsUJTwenZsMBG x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: eccb7ef2-9731-4bba-ecb1-08d577b34e82 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:BN3PR0101MB1121; x-ms-traffictypediagnostic: BN3PR0101MB1121: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(3231101)(944501161)(10201501046)(6041288)(20161123558120)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011); SRVR:BN3PR0101MB1121; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0101MB1121; x-forefront-prvs: 0588B2BD96 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39850400004)(39380400002)(376002)(396003)(346002)(189003)(199004)(82746002)(8676002)(3660700001)(6436002)(966005)(6116002)(36756003)(3846002)(6486002)(53546011)(8936002)(2906002)(77096007)(2950100002)(3280700002)(186003)(6916009)(102836004)(81166006)(26005)(86362001)(81156014)(68736007)(478600001)(14454004)(83716003)(106356001)(6506007)(93886005)(76176011)(59450400001)(2900100001)(229853002)(99286004)(4326008)(606006)(105586002)(5660300001)(25786009)(236005)(54896002)(33656002)(7736002)(53936002)(316002)(6512007)(6306002)(6246003)(66066001)(54906003)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0101MB1121; H:BN3PR0101MB1028.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) x-microsoft-antispam-message-info: /xb8Pc8+65aWGoLW84Bw0kMvILhv/11ff+gelm6AuWqElf0ZdJ0O1G1CvXbzTHuAycuD0IbyxPb/jY1gWWxGxCkFv2o5NnYSUA1XeamMQkILpB+9e60u35VrENKx5G7lcp47IPS7n1oGyRzoJoe1iff2EUx4/r7MYNoAW4LdBPE= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AC60E07A6E5142B9ACBB2B13C3A1AAA7arbornet_" MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-Network-Message-Id: eccb7ef2-9731-4bba-ecb1-08d577b34e82 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2018 16:10:34.1441 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0101MB1121 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-19_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=987 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802190200 Archived-At: Subject: Re: [Dots] Call home in the signal channel (was RE: draft-ietf-dots-data-channel: Filter Direction) 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, 19 Feb 2018 16:10:40 -0000 --_000_AC60E07A6E5142B9ACBB2B13C3A1AAA7arbornet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCk9uIEZlYiAxOSwgMjAxOCwgYXQgMTY6NTYsIEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkg PFRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb208bWFpbHRvOlRpcnVtYWxlc3dhclJl ZGR5X0tvbmRhQE1jQWZlZS5jb20+PiB3cm90ZToNCg0KSSBkb24ndCBnZXQgdGhlIGFib3ZlIGNv bW1lbnQsIHdlIGFyZSBkaXNjdXNzaW5nIHRoZSByZXF1aXJlbWVudHMgdG8gbWVldCB0aGUgdXNl IGNhc2UgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZG90cy11c2UtY2Fz ZXMtMDkjc2VjdGlvbi0zLjIuMS4NCg0KDQonSW4gb3JkZXIgdG8gYWNoaWV2ZSB0aGlzIGNhcGFi aWxpdHksIHRoZSB0ZWxlbWV0cnkgYW5hbHlzaXMgc3lzdGVtDQoNCiAgIHV0aWxpemVkIGJ5IHRo ZSBicm9hZGJhbmQgYWNjZXNzIHByb3ZpZGVyIG11c3QgaGF2ZSBET1RTIGNsaWVudA0KICAgZnVu Y3Rpb25hbGl0eScNCg0KDQouIC4gLg0KDQoNCidXaGVuIHRoZSB0ZWxlbWV0cnkgYW5hbHlzaXMg c3lzdGVtIGRldGVjdHMgYW5kDQogICBjbGFzc2lmaWVzIGFuIG91dGJvdW5kIEREb1MgYXR0YWNr IHNvdXJjZWQgZnJvbSBvbmUgb3IgbW9yZSBlbmQtDQogICBjdXN0b21lciBuZXR3b3Jrcy9kZXZp Y2VzLCB0aGUgRE9UUyBjbGllbnQgb2YgdGhlIHRlbGVtZXRyeSBhbmFseXNpcw0KICAgc3lzdGVt IHNlbmRzIGEgRE9UUyByZXF1ZXN0IHRvIHRoZSBET1RTIHNlcnZlciBpbXBsZW1lbnRlZCBvbiB0 aGUgQ1BFDQogICBkZXZpY2VzLCByZXF1ZXN0aW5nIGxvY2FsIG1pdGlnYXRpb24gYXNzaXN0YW5j ZSBpbiBzdXBwcmVzc2luZyBlaXRoZXINCiAgIHRoZSBpZGVudGlmaWVkIG91dGJvdW5kIEREb1Mg dHJhZmZpYywgb3IgYWxsIG91dGJvdW5kIHRyYWZmaWMgc291cmNlZA0KICAgZnJvbSB0aGUgZW5k LWN1c3RvbWVyIG5ldHdvcmtzL2RldmljZXMuJw0KDQoNCkRldGVjdGlvbi9jbGFzc2lmaWNhdGlv bi90cmFjZWJhY2sgaW4gdGhpcyBzY2VuYXJpbyB0YWtlcyBwbGFjZSBjZW50cmFsbHksIG5vdCBv biB0aGUgaW5kaXZpZHVhbCBDUEUgZGV2aWNlcy4NCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KUm9sYW5kIERvYmJpbnMgPHJkb2JiaW5zQGFyYm9yLm5ldDxtYWlsdG86 cmRvYmJpbnNAYXJib3IubmV0Pj4NCg0K --_000_AC60E07A6E5142B9ACBB2B13C3A1AAA7arbornet_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KT24gRmViIDE5LCAyMDE4 LCBhdCAxNjo1NiwgS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSAmbHQ7PGEgaHJlZj0ibWFpbHRv OlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20iPlRpcnVtYWxlc3dhclJlZGR5X0tv bmRhQE1jQWZlZS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiPg0KPGRpdj5JIGRvbid0IGdldCB0aGUgYWJvdmUgY29tbWVudCwgd2Ug YXJlIGRpc2N1c3NpbmcgdGhlIHJlcXVpcmVtZW50cyB0byBtZWV0IHRoZSB1c2UgY2FzZQ0KPHNw YW4+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZG90cy11 c2UtY2FzZXMtMDkjc2VjdGlvbi0zLjIuMSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtZG90cy11c2UtY2FzZXMtMDkjc2VjdGlvbi0zLjIuMTwvYT48L3NwYW4+Lg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+JzxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDI1NSwgMjU1LCAyNTUs IDApOyI+SW4gb3JkZXIgdG8gYWNoaWV2ZSB0aGlzIGNhcGFiaWxpdHksIHRoZSB0ZWxlbWV0cnkg YW5hbHlzaXMgc3lzdGVtPC9zcGFuPjwvZGl2Pg0KPHByZSBjbGFzcz0ibmV3cGFnZSIgc3R5bGU9 Im1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBicmVhay1iZWZvcmU6IHBhZ2U7 Ij48Zm9udCBmYWNlPSJVSUNURm9udFRleHRTdHlsZVRhbGxCb2R5Ij48c3BhbiBzdHlsZT0id2hp dGUtc3BhY2U6IG5vcm1hbDsgYmFja2dyb3VuZC1jb2xvcjogcmdiYSgyNTUsIDI1NSwgMjU1LCAw KTsiPiAgIHV0aWxpemVkIGJ5IHRoZSBicm9hZGJhbmQgYWNjZXNzIHByb3ZpZGVyIG11c3QgaGF2 ZSBET1RTIGNsaWVudA0KICAgZnVuY3Rpb25hbGl0eSc8L3NwYW4+PC9mb250PjwvcHJlPg0KPHBy ZSBjbGFzcz0ibmV3cGFnZSIgc3R5bGU9Im1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTog MHB4OyBicmVhay1iZWZvcmU6IHBhZ2U7Ij48Zm9udCBmYWNlPSJVSUNURm9udFRleHRTdHlsZVRh bGxCb2R5Ij48c3BhbiBzdHlsZT0id2hpdGUtc3BhY2U6IG5vcm1hbDsgYmFja2dyb3VuZC1jb2xv cjogcmdiYSgyNTUsIDI1NSwgMjU1LCAwKTsiPjxicj48L3NwYW4+PC9mb250PjwvcHJlPg0KPHBy ZSBjbGFzcz0ibmV3cGFnZSIgc3R5bGU9Im1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTog MHB4OyBicmVhay1iZWZvcmU6IHBhZ2U7Ij48Zm9udCBmYWNlPSJVSUNURm9udFRleHRTdHlsZVRh bGxCb2R5Ij48c3BhbiBzdHlsZT0id2hpdGUtc3BhY2U6IG5vcm1hbDsgYmFja2dyb3VuZC1jb2xv cjogcmdiYSgyNTUsIDI1NSwgMjU1LCAwKTsiPi4gLiAuPC9zcGFuPjwvZm9udD48L3ByZT4NCjxw cmUgY2xhc3M9Im5ld3BhZ2UiIHN0eWxlPSJtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206 IDBweDsgYnJlYWstYmVmb3JlOiBwYWdlOyI+PGZvbnQgZmFjZT0iVUlDVEZvbnRUZXh0U3R5bGVU YWxsQm9keSI+PHNwYW4gc3R5bGU9IndoaXRlLXNwYWNlOiBub3JtYWw7IGJhY2tncm91bmQtY29s b3I6IHJnYmEoMjU1LCAyNTUsIDI1NSwgMCk7Ij48YnI+PC9zcGFuPjwvZm9udD48L3ByZT4NCjxw cmUgY2xhc3M9Im5ld3BhZ2UiIHN0eWxlPSJtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206 IDBweDsgYnJlYWstYmVmb3JlOiBwYWdlOyI+PGZvbnQgZmFjZT0iVUlDVEZvbnRUZXh0U3R5bGVU YWxsQm9keSI+PHNwYW4gc3R5bGU9IndoaXRlLXNwYWNlOiBub3JtYWw7IGJhY2tncm91bmQtY29s b3I6IHJnYmEoMjU1LCAyNTUsIDI1NSwgMCk7Ij4nPC9zcGFuPjwvZm9udD48c3BhbiBzdHlsZT0i d2hpdGUtc3BhY2U6IG5vcm1hbDsgYmFja2dyb3VuZC1jb2xvcjogcmdiYSgyNTUsIDI1NSwgMjU1 LCAwKTsgZm9udC1mYW1pbHk6IFVJQ1RGb250VGV4dFN0eWxlVGFsbEJvZHk7Ij5XaGVuIHRoZSB0 ZWxlbWV0cnkgYW5hbHlzaXMgc3lzdGVtIGRldGVjdHMgYW5kDQogICBjbGFzc2lmaWVzIGFuIG91 dGJvdW5kIEREb1MgYXR0YWNrIHNvdXJjZWQgZnJvbSBvbmUgb3IgbW9yZSBlbmQtDQogICBjdXN0 b21lciBuZXR3b3Jrcy9kZXZpY2VzLCB0aGUgRE9UUyBjbGllbnQgb2YgdGhlIHRlbGVtZXRyeSBh bmFseXNpcw0KICAgc3lzdGVtIHNlbmRzIGEgRE9UUyByZXF1ZXN0IHRvIHRoZSBET1RTIHNlcnZl ciBpbXBsZW1lbnRlZCBvbiB0aGUgQ1BFDQogICBkZXZpY2VzLCByZXF1ZXN0aW5nIGxvY2FsIG1p dGlnYXRpb24gYXNzaXN0YW5jZSBpbiBzdXBwcmVzc2luZyBlaXRoZXINCiAgIHRoZSBpZGVudGlm aWVkIG91dGJvdW5kIEREb1MgdHJhZmZpYywgb3IgYWxsIG91dGJvdW5kIHRyYWZmaWMgc291cmNl ZA0KICAgZnJvbSB0aGUgZW5kLWN1c3RvbWVyIG5ldHdvcmtzL2RldmljZXMuJzwvc3Bhbj48L3By ZT4NCjxwcmUgY2xhc3M9Im5ld3BhZ2UiIHN0eWxlPSJtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1i b3R0b206IDBweDsgYnJlYWstYmVmb3JlOiBwYWdlOyI+PHByZSBjbGFzcz0ibmV3cGFnZSIgc3R5 bGU9Im1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBicmVhay1iZWZvcmU6IHBh Z2U7Ij48Zm9udCBmYWNlPSJVSUNURm9udFRleHRTdHlsZVRhbGxCb2R5Ij48c3BhbiBzdHlsZT0i d2hpdGUtc3BhY2U6IG5vcm1hbDsgYmFja2dyb3VuZC1jb2xvcjogcmdiYSgyNTUsIDI1NSwgMjU1 LCAwKTsiPjxicj48L3NwYW4+PC9mb250PjwvcHJlPjwvcHJlPg0KPHByZSBjbGFzcz0ibmV3cGFn ZSIgc3R5bGU9Im1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBicmVhay1iZWZv cmU6IHBhZ2U7Ij48Zm9udCBmYWNlPSJVSUNURm9udFRleHRTdHlsZVRhbGxCb2R5Ij48c3BhbiBz dHlsZT0id2hpdGUtc3BhY2U6IG5vcm1hbDsgYmFja2dyb3VuZC1jb2xvcjogcmdiYSgyNTUsIDI1 NSwgMjU1LCAwKTsiPkRldGVjdGlvbi9jbGFzc2lmaWNhdGlvbi90cmFjZWJhY2sgaW4gdGhpcyBz Y2VuYXJpbyB0YWtlcyBwbGFjZSBjZW50cmFsbHksIG5vdCBvbiB0aGUgaW5kaXZpZHVhbCBDUEUg ZGV2aWNlcy4mbmJzcDs8L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZSBjbGFzcz0ibmV3cGFnZSIg c3R5bGU9Im1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBicmVhay1iZWZvcmU6 IHBhZ2U7Ij48Zm9udCBmYWNlPSJVSUNURm9udFRleHRTdHlsZVRhbGxCb2R5Ij48c3BhbiBzdHls ZT0id2hpdGUtc3BhY2U6IG5vcm1hbDsgYmFja2dyb3VuZC1jb2xvcjogcmdiYSgyNTUsIDI1NSwg MjU1LCAwKTsiPjxicj48L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZSBjbGFzcz0ibmV3cGFnZSIg c3R5bGU9Im1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBicmVhay1iZWZvcmU6 IHBhZ2U7Ij48Zm9udCBmYWNlPSJVSUNURm9udFRleHRTdHlsZVRhbGxCb2R5Ij48c3BhbiBzdHls ZT0id2hpdGUtc3BhY2U6IG5vcm1hbDsgYmFja2dyb3VuZC1jb2xvcjogcmdiYSgyNTUsIDI1NSwg MjU1LCAwKTsiPjxzcGFuIHN0eWxlPSJmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IGZv bnQtdmFyaWFudC1lYXN0LWFzaWFuOiBub3JtYWw7IGZvbnQtdmFyaWFudC1wb3NpdGlvbjogbm9y bWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS08L3NwYW4+PGJyIHN0eWxlPSJmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IGZv bnQtdmFyaWFudC1lYXN0LWFzaWFuOiBub3JtYWw7IGZvbnQtdmFyaWFudC1wb3NpdGlvbjogbm9y bWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyI+PC9zcGFuPjwvZm9udD48ZGl2IHN0eWxlPSJmb250 LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IGZvbnQtdmFyaWFudC1lYXN0LWFzaWFuOiBub3Jt YWw7IGZvbnQtdmFyaWFudC1wb3NpdGlvbjogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyI+ PGZvbnQgZmFjZT0iVUlDVEZvbnRUZXh0U3R5bGVUYWxsQm9keSI+PHNwYW4gc3R5bGU9IndoaXRl LXNwYWNlOiBub3JtYWw7IGJhY2tncm91bmQtY29sb3I6IHJnYmEoMjU1LCAyNTUsIDI1NSwgMCk7 Ij5Sb2xhbmQgRG9iYmlucyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJkb2JiaW5zQGFyYm9yLm5ldCI+ cmRvYmJpbnNAYXJib3IubmV0PC9hPiZndDs8L3NwYW4+PC9mb250PjwvZGl2PjwvcHJlPg0KPHBy ZSBjbGFzcz0ibmV3cGFnZSIgc3R5bGU9Im1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTog MHB4OyBicmVhay1iZWZvcmU6IHBhZ2U7Ij48Zm9udCBmYWNlPSJVSUNURm9udFRleHRTdHlsZVRh bGxCb2R5Ij48c3BhbiBzdHlsZT0id2hpdGUtc3BhY2U6IG5vcm1hbDsgYmFja2dyb3VuZC1jb2xv cjogcmdiYSgyNTUsIDI1NSwgMjU1LCAwKTsiPjxicj48L3NwYW4+PC9mb250PjwvcHJlPg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_AC60E07A6E5142B9ACBB2B13C3A1AAA7arbornet_-- From nobody Tue Feb 20 00:51:08 2018 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 06D4E1243F3 for ; Tue, 20 Feb 2018 00:51:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.33 X-Spam-Level: X-Spam-Status: No, score=-4.33 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 s7RUh4Pgf-SV for ; Tue, 20 Feb 2018 00:51:05 -0800 (PST) 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 8F596124239 for ; Tue, 20 Feb 2018 00:51:05 -0800 (PST) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1519116656; h=From: To:CC:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=pv07+xIB6LA/xNsYakS7bWUAL5XaGDzVBGiT8g /vNP4=; b=ZgOcJuz1DFyi9KKkHoUNr6SHDXV2XUGh0CZ45k6l 9vLkP4IYSLtuWJV53+bxn7t/Sz8nlNzZpC5kRDNzvIULxlhLFa xJ1Aq/MBXS3r8AWxUG0NPAd4q1Ei9L5k6AD3S4qr4bwwliqV2S pRNsWK+rBBAj6SivuI3oqKvqL74WOGI= Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 5d2f_395c_46313657_0597_4727_91fd_a83b05558ad0; Tue, 20 Feb 2018 02:50:55 -0600 Received: from DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 20 Feb 2018 01:50:31 -0700 Received: from DNVEXUSR1N12.corpzone.internalzone.com (10.44.48.85) by DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 20 Feb 2018 01:50:30 -0700 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXUSR1N12.corpzone.internalzone.com (10.44.48.85) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Tue, 20 Feb 2018 01:50:30 -0700 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (10.44.176.240) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 20 Feb 2018 01:50:30 -0700 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1818.namprd16.prod.outlook.com (10.172.44.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.18; Tue, 20 Feb 2018 08:50:29 +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.20.0506.023; Tue, 20 Feb 2018 08:50:29 +0000 From: "Konda, Tirumaleswar Reddy" To: "Dobbins, Roland" CC: "mohamed.boucadair@orange.com" , Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] draft-ietf-dots-data-channel: Value and/or Range Thread-Index: AdOpVo4UGaF3iP8sRF6zMQH8hhSSfwAFG7oQAAwdrEQAIt91AA== Date: Tue, 20 Feb 2018 08:50:29 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A0D42F4@OPEXCLILMA3.corporate.adroot.infra.ftgroup>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [185.221.69.14] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1818; 7:HQNePaiIdC7Tm7N8NG1lcMvoyn6KaUGLfj75P8z9XbXKrJM4GdEWoz83Wu+dUfcpM7IhCeE6KStQ1bioRYonTdzo0m3aDqYLrBH7Y8Wo9qptfh4TtNdfACwj4aXkWnd64GjmJNQDJHbSPiw0krsuN6EvxA1wv/3o8uvnR811BHkAfx5rE99Zp8sjpYuY17H+rbMQQcfYIN7pPiqwWk4GPqaCbNanaUWF1m/1lrI9O4bE4TJTuBDXnrHzjJoUqCr4 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 2b7c0930-ad0d-411e-32b2-08d5783efe62 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM5PR16MB1818; x-ms-traffictypediagnostic: DM5PR16MB1818: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(18271650672692)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001056)(6040501)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(10201501046)(3231101)(944501161)(6041288)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:DM5PR16MB1818; BCL:0; PCL:0; RULEID:; SRVR:DM5PR16MB1818; x-forefront-prvs: 05891FB07F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(346002)(376002)(366004)(396003)(39850400004)(32952001)(13464003)(199004)(189003)(33656002)(26005)(77096007)(97736004)(66066001)(2900100001)(59450400001)(76176011)(53546011)(6506007)(99286004)(102836004)(186003)(6436002)(106356001)(86362001)(7696005)(68736007)(4326008)(53936002)(229853002)(966005)(316002)(25786009)(54906003)(6306002)(9686003)(55016002)(478600001)(105586002)(6246003)(72206003)(80792005)(6916009)(2906002)(81166006)(81156014)(3280700002)(8936002)(14454004)(3660700001)(7736002)(305945005)(5660300001)(2950100002)(8676002)(3846002)(6116002)(74316002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1818; 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) x-microsoft-antispam-message-info: FwnLvtQEK7A0ZIAd1a5RVsq4oxRozsgB1vfwebKRligHXlok9jtjjDtcqhurWu7DJZ7VDqX5fyywN+yZNFQcEFDlb7IxwWtUfceWju6YD3Jng49Ry+IBios4xy8XZWj4OC741mybd+OhogOKGPCzDLFyLy4Ky9kIgC6lScUjBNQ= 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-Network-Message-Id: 2b7c0930-ad0d-411e-32b2-08d5783efe62 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Feb 2018 08:50:29.3009 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1818 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.2 X-NAI-Spam-Version: 2.3.0.9418 : core <6225> : inlines <6410> : streams <1779510> : uri <2596071> Archived-At: Subject: Re: [Dots] draft-ietf-dots-data-channel: Value and/or Range 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: Tue, 20 Feb 2018 08:51:07 -0000 > -----Original Message----- > From: Dobbins, Roland [mailto:rdobbins@arbor.net] > Sent: Monday, February 19, 2018 9:35 PM > To: Konda, Tirumaleswar Reddy > Cc: mohamed.boucadair@orange.com; Jon Shallow ietf@jpshallow.com>; dots@ietf.org > Subject: Re: [Dots] draft-ietf-dots-data-channel: Value and/or Range >=20 >=20 >=20 > > On Feb 19, 2018, at 17:20, Konda, Tirumaleswar Reddy > wrote: > > > > I don't think router vendors support ranges for TTL fields ! >=20 > Most don't. >=20 > Still confused & dismayed that we're falling down the rabbit hole of re- > implementing flowspec in DOTS. >=20 > This is adding needless & unwanted complexity to DOTS. DOTS nodes should > simply self-describe their protocols/ports, & figuring out what network > access policies to wrap around them should take place outside the scope o= f > DOTS. >=20 > Very strong objections to all this ACL stuff. DOTS signal channel does not use any ACL, ACL is used only in the DOTS data= channel for black-listing/white-listing traffic to meet the requirement DA= TA-004 in=20 https://tools.ietf.org/html/draft-ietf-dots-requirements-14 -Tiru >=20 > ----------------------------------- > Roland Dobbins >=20 From nobody Tue Feb 20 01:01:06 2018 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 F11C8126C25 for ; Tue, 20 Feb 2018 01:01:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.009 X-Spam-Level: X-Spam-Status: No, score=-7.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 bA677fF68ler for ; Tue, 20 Feb 2018 01:01:02 -0800 (PST) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 832D4124239 for ; Tue, 20 Feb 2018 01:01:02 -0800 (PST) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1519117249; h=From: To:CC:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=2 fzYhF99U5jx7tBYvXa4FS1kT/2b8vhGXhXCaOzL7V M=; b=QHFSloePWkb4XSncUDBcOAu308D2vHDPo+JNXKCrdZyx MlHYkk9TRxS88RxvCNySwmD1q32Y+qfqTom4OhFJTGXVM+t47E 9sxQ5gbdbnjJ3QrWfFKe23N3hWbJzstcmYCrMqwWoqbJUf9JQI xLV8zG84eEM9VP3N601Z+M3+aSw= Received: from MIVEXAPP1N02.corpzone.internalzone.com (mivexapp1n02.corpzone.internalzone.com [10.48.48.89]) by MIVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 0c8e_6c58_51c8fb08_e77a_4daa_952f_49ab61ff2785; Tue, 20 Feb 2018 03:00:48 -0600 Received: from MIVEXUSR1N01.corpzone.internalzone.com (10.48.48.81) by MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 20 Feb 2018 04:00:38 -0500 Received: from MIVEXUSR1N07.corpzone.internalzone.com (10.48.48.87) by MIVEXUSR1N01.corpzone.internalzone.com (10.48.48.81) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 20 Feb 2018 04:00:37 -0500 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.1347.2 via Frontend Transport; Tue, 20 Feb 2018 04:00:37 -0500 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.1347.2; Tue, 20 Feb 2018 04:00:36 -0500 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1580.namprd16.prod.outlook.com (10.173.212.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.18; Tue, 20 Feb 2018 09:00:34 +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.20.0506.023; Tue, 20 Feb 2018 09:00:34 +0000 From: "Konda, Tirumaleswar Reddy" To: "Dobbins, Roland" CC: "mohamed.boucadair@orange.com" , Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Call home in the signal channel (was RE: draft-ietf-dots-data-channel: Filter Direction) Thread-Index: AQHTpx4fYQaVBSxJJEC02ounCseemaOm/iRwgAALCoCAAARH0IAAGmGAgALNmfCAALkMAIAAn1iggAAk3gCAAA2EcIAAaeYAgAEX3rA= Date: Tue, 20 Feb 2018 09:00:34 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A0D3439@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00d201d3a71e$05ead590$11c080b0$@jpshallow.com> <01b401d3a72b$b5a79f10$20f6dd30$@jpshallow.com> <022001d3a73b$09b1c270$1d154750$@jpshallow.com> <395E0F43-03F3-46F0-821D-50A53577E5B3@arbor.net>, <12A41D38-1E81-4677-96A1-4CFACA203026@arbor.net>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [185.221.69.14] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1580; 7:v1Dl3C/voyHhMP126gKqFKsxS1SKISjJULvbmrQ6kG6/5O7wq+IReWWWfoBz4rNP/3G7HQbgWw0X2/hOvVQsheCwMOHTyRr1Kw+mHZvslmNMv6a6Th7LxoT8ZAUUnpSJCkxDexnF65s7D6QSA8s5V/6HVQbeQ1GGlEcpcwFzqZ/m1995R+gpz2jAQm3a6WxZSum3cxpLG12DIYoeQR8/3qq8vlQRqzhC4VVRKB11e1Gz3MG4btg2Q7fkuhk6NH9g x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 22756eea-eadf-4b0f-2fc3-08d57840673a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:DM5PR16MB1580; x-ms-traffictypediagnostic: DM5PR16MB1580: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(18271650672692)(21748063052155)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231101)(944501161)(6041288)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:DM5PR16MB1580; BCL:0; PCL:0; RULEID:; SRVR:DM5PR16MB1580; x-forefront-prvs: 05891FB07F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(39380400002)(346002)(366004)(376002)(32952001)(189003)(199004)(3280700002)(790700001)(6246003)(66066001)(6436002)(6506007)(33656002)(3660700001)(53546011)(236005)(54896002)(316002)(6306002)(9686003)(59450400001)(53936002)(106356001)(80792005)(5660300001)(93886005)(81166006)(86362001)(8936002)(4326008)(606006)(478600001)(966005)(81156014)(97736004)(54906003)(55016002)(102836004)(8676002)(14454004)(25786009)(72206003)(76176011)(19609705001)(7696005)(2906002)(68736007)(99286004)(2950100002)(6916009)(3846002)(2900100001)(7736002)(229853002)(105586002)(6116002)(74316002)(26005)(77096007)(186003)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1580; 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) x-microsoft-antispam-message-info: o1f7Ot61dlUZAyAeEZGQwxEv2oqjOt4Po24osnizneyeVzCiyepMjV+ZZP1idAZ2o0wq3STnTY7AoWlO1fQ8XA0OY4tw6LhiLCCy4g4QJbfTSP7DdpqD7/5/LL2B3bSD3AhoLL8xKJZrzV877xn2delh2GSxgKk9DuRTeNyGgok= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1788C5FB03F3A7B371B39629EACF0DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 22756eea-eadf-4b0f-2fc3-08d57840673a X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Feb 2018 09:00:34.5556 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1580 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 <6225> : inlines <6410> : streams <1779511> : uri <2596076> Archived-At: Subject: Re: [Dots] Call home in the signal channel (was RE: draft-ietf-dots-data-channel: Filter Direction) 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: Tue, 20 Feb 2018 09:01:05 -0000 --_000_DM5PR16MB1788C5FB03F3A7B371B39629EACF0DM5PR16MB1788namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogRG90cyBbbWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERv YmJpbnMsIFJvbGFuZA0KU2VudDogTW9uZGF5LCBGZWJydWFyeSAxOSwgMjAxOCA5OjQxIFBNDQpU bzogS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSA8VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNB ZmVlLmNvbT4NCkNjOiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tOyBKb24gU2hhbGxvdyA8 c3VwanBzLWlldGZAanBzaGFsbG93LmNvbT47IGRvdHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBb RG90c10gQ2FsbCBob21lIGluIHRoZSBzaWduYWwgY2hhbm5lbCAod2FzIFJFOiBkcmFmdC1pZXRm LWRvdHMtZGF0YS1jaGFubmVsOiBGaWx0ZXIgRGlyZWN0aW9uKQ0KDQoNCg0KT24gRmViIDE5LCAy MDE4LCBhdCAxNjo1NiwgS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSA8VGlydW1hbGVzd2FyUmVk ZHlfS29uZGFATWNBZmVlLmNvbTxtYWlsdG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVl LmNvbT4+IHdyb3RlOg0KSSBkb24ndCBnZXQgdGhlIGFib3ZlIGNvbW1lbnQsIHdlIGFyZSBkaXNj dXNzaW5nIHRoZSByZXF1aXJlbWVudHMgdG8gbWVldCB0aGUgdXNlIGNhc2UgaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZG90cy11c2UtY2FzZXMtMDkjc2VjdGlvbi0zLjIu MS4NCg0KDQonSW4gb3JkZXIgdG8gYWNoaWV2ZSB0aGlzIGNhcGFiaWxpdHksIHRoZSB0ZWxlbWV0 cnkgYW5hbHlzaXMgc3lzdGVtDQoNCnV0aWxpemVkIGJ5IHRoZSBicm9hZGJhbmQgYWNjZXNzIHBy b3ZpZGVyIG11c3QgaGF2ZSBET1RTIGNsaWVudCBmdW5jdGlvbmFsaXR5Jw0KDQoNCg0KLiAuIC4N Cg0KDQoNCidXaGVuIHRoZSB0ZWxlbWV0cnkgYW5hbHlzaXMgc3lzdGVtIGRldGVjdHMgYW5kIGNs YXNzaWZpZXMgYW4gb3V0Ym91bmQgRERvUyBhdHRhY2sgc291cmNlZCBmcm9tIG9uZSBvciBtb3Jl IGVuZC0gY3VzdG9tZXIgbmV0d29ya3MvZGV2aWNlcywgdGhlIERPVFMgY2xpZW50IG9mIHRoZSB0 ZWxlbWV0cnkgYW5hbHlzaXMgc3lzdGVtIHNlbmRzIGEgRE9UUyByZXF1ZXN0IHRvIHRoZSBET1RT IHNlcnZlciBpbXBsZW1lbnRlZCBvbiB0aGUgQ1BFIGRldmljZXMsIHJlcXVlc3RpbmcgbG9jYWwg bWl0aWdhdGlvbiBhc3Npc3RhbmNlIGluIHN1cHByZXNzaW5nIGVpdGhlciB0aGUgaWRlbnRpZmll ZCBvdXRib3VuZCBERG9TIHRyYWZmaWMsIG9yIGFsbCBvdXRib3VuZCB0cmFmZmljIHNvdXJjZWQg ZnJvbSB0aGUgZW5kLWN1c3RvbWVyIG5ldHdvcmtzL2RldmljZXMuJw0KDQoNCg0KRGV0ZWN0aW9u L2NsYXNzaWZpY2F0aW9uL3RyYWNlYmFjayBpbiB0aGlzIHNjZW5hcmlvIHRha2VzIHBsYWNlIGNl bnRyYWxseSwgbm90IG9uIHRoZSBpbmRpdmlkdWFsIENQRSBkZXZpY2VzLg0KDQoNCg0KW1RSXSBZ ZXMsIGJ1dCBpbiB0aGlzIHVzZSBjYXNlIHRoZSBDUEUgbmVlZHMgdG8gYWN0IGFzIGEgRE9UUyBz ZXJ2ZXIgYW5kIGN1cnJlbnRseSB0aGUgRE9UUyBzaWduYWwgY2hhbm5lbCBvbmx5IGNvbnZleXMg dGhlIGF0dGFjayB0YXJnZXRzLCBhbmQgZG9lcyBub3Qgc2lnbmFsIHRoZSBzb3VyY2UgSVAgYWRk cmVzc2VzDQoNCmxhdW5jaGluZyB0aGUgYXR0YWNrLg0KDQoNCg0KLVRpcnUNCg0KDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNClJvbGFuZCBEb2JiaW5zIDxyZG9iYmlu c0BhcmJvci5uZXQ8bWFpbHRvOnJkb2JiaW5zQGFyYm9yLm5ldD4+DQoNCg0K --_000_DM5PR16MB1788C5FB03F3A7B371B39629EACF0DM5PR16MB1788namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OlVJQ1RGb250VGV4dFN0eWxlVGFsbEJvZHk7DQoJcGFub3NlLTE6 MCAwIDAgMCAwIDAgMCAwIDAgMDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnBy ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9y bWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLm1zb25vcm1h bDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25v cm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6 MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uSFRN TFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENo YXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVm b3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IERvdHMgW21haWx0bzpkb3Rz LWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkRvYmJpbnMsIFJvbGFuZDxi cj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEZlYnJ1YXJ5IDE5LCAyMDE4IDk6NDEgUE08YnI+DQo8 Yj5Ubzo8L2I+IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgJmx0O1RpcnVtYWxlc3dhclJlZGR5 X0tvbmRhQE1jQWZlZS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBtb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tOyBKb24gU2hhbGxvdyAmbHQ7c3VwanBzLWlldGZAanBzaGFsbG93LmNvbSZndDs7 IGRvdHNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtEb3RzXSBDYWxsIGhvbWUg aW4gdGhlIHNpZ25hbCBjaGFubmVsICh3YXMgUkU6IGRyYWZ0LWlldGYtZG90cy1kYXRhLWNoYW5u ZWw6IEZpbHRlciBEaXJlY3Rpb24pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCk9uIEZlYiAxOSwgMjAxOCwg YXQgMTY6NTYsIEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgJmx0OzxhIGhyZWY9Im1haWx0bzpU aXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tIj5UaXJ1bWFsZXN3YXJSZWRkeV9Lb25k YUBNY0FmZWUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9uJ3QgZ2V0IHRoZSBhYm92ZSBjb21tZW50LCB3 ZSBhcmUgZGlzY3Vzc2luZyB0aGUgcmVxdWlyZW1lbnRzIHRvIG1lZXQgdGhlIHVzZSBjYXNlDQo8 YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1kb3RzLXVzZS1j YXNlcy0wOSNzZWN0aW9uLTMuMi4xIj4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLWRvdHMtdXNlLWNhc2VzLTA5I3NlY3Rpb24tMy4yLjE8L2E+LiA8bzpwPg0KPC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPidJbiBvcmRlciB0byBhY2hpZXZlIHRoaXMgY2FwYWJpbGl0eSwgdGhlIHRlbGVtZXRyeSBh bmFseXNpcyBzeXN0ZW08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHByZSBzdHlsZT0iYnJlYWst YmVmb3JlOiBwYWdlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VUlDVEZvbnRUZXh0 U3R5bGVUYWxsQm9keSZxdW90OyxzZXJpZiI+dXRpbGl6ZWQgYnkgdGhlIGJyb2FkYmFuZCBhY2Nl c3MgcHJvdmlkZXIgbXVzdCBoYXZlIERPVFMgY2xpZW50IGZ1bmN0aW9uYWxpdHknPC9zcGFuPjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJicmVhay1iZWZvcmU6IHBhZ2UiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtVSUNURm9udFRleHRTdHlsZVRhbGxCb2R5JnF1b3Q7LHNl cmlmIj48YnI+PGJyPjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYnJlYWst YmVmb3JlOiBwYWdlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VUlDVEZvbnRUZXh0 U3R5bGVUYWxsQm9keSZxdW90OyxzZXJpZiI+LiAuIC48L3NwYW4+PG86cD48L286cD48L3ByZT4N CjxwcmUgc3R5bGU9ImJyZWFrLWJlZm9yZTogcGFnZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1VJQ1RGb250VGV4dFN0eWxlVGFsbEJvZHkmcXVvdDssc2VyaWYiPjxicj48YnI+PC9z cGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJicmVhay1iZWZvcmU6IHBhZ2UiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtVSUNURm9udFRleHRTdHlsZVRhbGxCb2R5JnF1 b3Q7LHNlcmlmIj4nV2hlbiB0aGUgdGVsZW1ldHJ5IGFuYWx5c2lzIHN5c3RlbSBkZXRlY3RzIGFu ZCBjbGFzc2lmaWVzIGFuIG91dGJvdW5kIEREb1MgYXR0YWNrIHNvdXJjZWQgZnJvbSBvbmUgb3Ig bW9yZSBlbmQtIGN1c3RvbWVyIG5ldHdvcmtzL2RldmljZXMsIHRoZSBET1RTIGNsaWVudCBvZiB0 aGUgdGVsZW1ldHJ5IGFuYWx5c2lzIHN5c3RlbSBzZW5kcyBhIERPVFMgcmVxdWVzdCB0byB0aGUg RE9UUyBzZXJ2ZXIgaW1wbGVtZW50ZWQgb24gdGhlIENQRSBkZXZpY2VzLCByZXF1ZXN0aW5nIGxv Y2FsIG1pdGlnYXRpb24gYXNzaXN0YW5jZSBpbiBzdXBwcmVzc2luZyBlaXRoZXIgdGhlIGlkZW50 aWZpZWQgb3V0Ym91bmQgRERvUyB0cmFmZmljLCBvciBhbGwgb3V0Ym91bmQgdHJhZmZpYyBzb3Vy Y2VkIGZyb20gdGhlIGVuZC1jdXN0b21lciBuZXR3b3Jrcy9kZXZpY2VzLic8L3NwYW4+PG86cD48 L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJyZWFrLWJlZm9yZTogcGFnZSI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1VJQ1RGb250VGV4dFN0eWxlVGFsbEJvZHkmcXVvdDssc2VyaWYi Pjxicj48YnI+PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJicmVhay1iZWZv cmU6IHBhZ2UiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtVSUNURm9udFRleHRTdHls ZVRhbGxCb2R5JnF1b3Q7LHNlcmlmIj5EZXRlY3Rpb24vY2xhc3NpZmljYXRpb24vdHJhY2ViYWNr IGluIHRoaXMgc2NlbmFyaW8gdGFrZXMgcGxhY2UgY2VudHJhbGx5LCBub3Qgb24gdGhlIGluZGl2 aWR1YWwgQ1BFIGRldmljZXMuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+W1RSXSBZZXMsIGJ1dCBpbiB0aGlzIHVzZSBjYXNlIHRoZSBDUEUgbmVlZHMg dG8gYWN0IGFzIGEgRE9UUyBzZXJ2ZXIgYW5kIGN1cnJlbnRseSB0aGUgRE9UUyBzaWduYWwgY2hh bm5lbCBvbmx5IGNvbnZleXMgdGhlIGF0dGFjayB0YXJnZXRzLCBhbmQgZG9lcyBub3Qgc2lnbmFs IHRoZSBzb3VyY2UgSVAgYWRkcmVzc2VzPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+bGF1bmNoaW5nIHRoZSBhdHRhY2suPG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtVSUNURm9udFRleHRTdHlsZVRh bGxCb2R5JnF1b3Q7LHNlcmlmIj4tVGlydTxicj48YnI+PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJicmVhay1iZWZvcmU6IHBhZ2UiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtVSUNURm9udFRleHRTdHlsZVRhbGxCb2R5JnF1b3Q7LHNlcmlmIj4tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxiciBzdHlsZT0iZm9udC12YXJpYW50LWxpZ2F0dXJl czogbm9ybWFsO2ZvbnQtdmFyaWFudC1lYXN0LWFzaWFuOiBub3JtYWw7Zm9udC12YXJpYW50LXBv c2l0aW9uOiBub3JtYWwiPjxicj48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxkaXY+DQo8cHJl PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtVSUNURm9udFRleHRTdHlsZVRhbGxCb2R5 JnF1b3Q7LHNlcmlmIj5Sb2xhbmQgRG9iYmlucyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJkb2JiaW5z QGFyYm9yLm5ldCI+cmRvYmJpbnNAYXJib3IubmV0PC9hPiZndDs8L3NwYW4+PG86cD48L286cD48 L3ByZT4NCjwvZGl2Pg0KPHByZSBzdHlsZT0iYnJlYWstYmVmb3JlOiBwYWdlIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VUlDVEZvbnRUZXh0U3R5bGVUYWxsQm9keSZxdW90OyxzZXJp ZiI+PGJyPjxicj48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_DM5PR16MB1788C5FB03F3A7B371B39629EACF0DM5PR16MB1788namp_-- From nobody Tue Feb 20 01:11:26 2018 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 A54131270A3 for ; Tue, 20 Feb 2018 01:11:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 1ym0p3Py6KPA for ; Tue, 20 Feb 2018 01:11:17 -0800 (PST) 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 14115126D74 for ; Tue, 20 Feb 2018 01:11:17 -0800 (PST) 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 1eo3xB-0003ss-WA; Tue, 20 Feb 2018 09:11:14 +0000 From: "Jon Shallow" To: , "Konda, Tirumaleswar Reddy" , References: <787AE7BB302AE849A7480A190F8B93300A0D42F4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A0D42F4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Tue, 20 Feb 2018 09:11:14 -0000 Message-ID: <002d01d3aa2a$c1ff03a0$45fd0ae0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002E_01D3AA2A.C2032250" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH1VnM7gmrBb4hUSjAUETC1ZBiLc6NppOMQ Content-Language: en-gb Archived-At: Subject: Re: [Dots] draft-ietf-dots-data-channel: Value and/or Range 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: Tue, 20 Feb 2018 09:11:25 -0000 This is a multipart message in MIME format. ------=_NextPart_000_002E_01D3AA2A.C2032250 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable As the intent is to follow netmod-acl-model syntax, having a DOTS = version of some of the parameters makes no sense to me. =20 For example, the DOTS server when communicating with the DOTS mitigator (albeit out of scope) will have to translate the current set of ACL definitions into something =96 e.g. real netconf-acl. With the exact modelling of netmod-acl-model parameters, life is a lot easier as we = just have to strip out the DOTS specific parameters (e.g. lifetimes). =20 The right place to get this done is to get the netmod-acl-model authors = to update their definitions of ietf-packet-fields. =20 As draft-ietf-netmod-acl-16 can possibly change (we have seen = significant changes over the last few updates), we need to consider referring to the specific version of ietf-packet-fields in the DOTS data channel Yang = model. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 19 February 2018 07:52 To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org Subject: [Dots] draft-ietf-dots-data-channel: Value and/or Range =20 Hi Jon,=20 =20 Good point.=20 =20 Actually, some filtering parameters are worth to be supplied as values = or ranges but the current netmod module does not allow for it. I can cite: =B7 Length fields =B7 TTL =20 Do we need to have value/range supported in the module for these fields? =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : vendredi 16 f=E9vrier 2018 17:14 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; = dots@ietf.org Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields =20 Ttl is an interesting one. It is not definable as a range, and so if = you want to match =93ttl lt 16=94 you are going to have to have 16 ACLs = preceding any other ACL that does anything else. =20 I would expect that =91ttl=92 would be done properly as a one of the = mitigator rules, and DOTS does not need to =91hint=92 it as well. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 16 February 2018 15:46 To: mohamed.boucadair@orange.com; Jon Shallow; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields =20 We may want to add=20 =20 1) UDP (length) to the list. It may be useful to block large DNS packets (e.g. DNS amplification attack). 2) In IPv4/IPv6, add length, ttl (https://www.cisco.com/c/en/us/about/security-center/ttl-expiry-attack.ht= ml) to the list.=20 =20 -Tiru =20 From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] = Sent: Friday, February 16, 2018 8:04 PM To: Konda, Tirumaleswar Reddy ; Jon Shallow ; dots@ietf.org Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields =20 Re-, =20 Here is a tentative list:=20 =20 Header Mandatory Fields ------ -------------------------------------------------------------- IPv4 protocol, source-port-range-or-operator, destination-port- range-or-operator, destination-ipv4-network, source- ipv4-network, and v4-fragments IPv6 protocol, source-port-range-or-operator, destination-port- range-or-operator, destination-ipv4-network, source- ipv4-network,and v6-fragments TCP flags ICMP type and code =20 Please comment/update.=20 =20 Cheers, Med =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, = Tirumaleswar Reddy Envoy=E9 : vendredi 16 f=E9vrier 2018 14:55 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields =20 +1. In TCP, only =93flags=94 field looks mandatory.=20 =20 -Tiru =20 From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] = Sent: Friday, February 16, 2018 7:03 PM To: Jon Shallow ; Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields =20 Re-, =20 I tend to agree with you to have to define a minimum set of mandatory = match fields.=20 =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : vendredi 16 f=E9vrier 2018 14:29 =C0 : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; = dots@ietf.org Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields =20 Hi Med, =20 See inline [Jon] =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 16 February 2018 12:56 To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields =20 Jon, =20 Thank you for sharing your thoughts.=20 =20 Please see inline. =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : vendredi 16 f=E9vrier 2018 13:24 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; = dots@ietf.org Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields =20 I like the concept of =93+--ro capabilities=93 allowing for future = support as the DOS server becomes more mature in its capabilities. =20 If a DOTS client includes a filtering field parameter that is not = currently supported, should the parameter be ignored (and not returned for a GET), = or the request rejected? [Med] I would vote for rejecting the request. The client should only use match criteria that are understood by the server; otherwise there will = be different expectation from the service.=20 [Jon] I think that this is my preference =96 I was just seeking clarity = of thinking. =20 It is conceivable that a DOTS client has 2 DOTS servers (one possibly a backup, or 2 different ISPs), which may have differing filtering field parameter support capabilities. [Med] The backup/case seems odd. I would expect a feature parity for a redundancy group used to provide the same service. [Jon] Agreed that a backup server is most likely to be from the same manufacturer and hence support the same functionality. But one may have just been upgraded to have extra support. =20 =20 =20 Adding in intelligence code to work out what is / is not allowed may = not be practical in a (memory or cpu) constrained environment of the DOTS client. [Med] Fair.=20 =20 That said, I think we need to define the minimum set of supported = parameters =96 e.g. protocol, source / dest ports, source / dest IPv4 prefixes, = source / dest IPv6 prefixes, fragments and icmp type/code.=20 [Jon] Any comments? =20 -Jon =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 16 February 2018 10:18 To: mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields =20 Hi Med, =20 Please see inline [TR2] =20 From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] = Sent: Friday, February 16, 2018 1:45 PM To: Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: RE: draft-ietf-dots-data-channel: Filtering Fields =20 Re-, =20 Please see inline.=20 =20 Cheers, Med =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, = Tirumaleswar Reddy Envoy=E9 : vendredi 16 f=E9vrier 2018 08:00 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields =20 From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: Wednesday, February 14, 2018 1:49 PM To: dots@ietf.org Subject: [Dots] draft-ietf-dots-data-channel: Filtering Fields =20 Hi all,=20 =20 As agreed during the interim, there are some issues that need fixes in = the data-channel spec. We would like to hear from the WG to know what to = record in the document.=20 =20 Issue description: Should we support all of the match fields defined by =93ietf-packet-fields=94 or do we need to define a minimum supported = set?=20 =20 [TR] I don=92t see the need to support all the match fields, define a = minimum supported set (don=92t see the use for acl-eth-header-fields for DOTS = use cases). =20 [Med] Agree that acl-eth-header-fields aren=92t required. The text is = already clear about this: =20 DOTS implementations MUST support the following matching criteria: match based on the IP header (IPv4 and IPv6), match based on the transport header (TCP, UDP, and ICMP), and any combination thereof. =20 The question is whether we need to go further and mandate (or not) the support of matching based on specific fields: dscp, ecn, ttl,=85 = flow-label, =85 tcp sequence-number, tcp flags, =85 =20 =20 [TR2] https://tools.ietf.org/html/draft-ietf-netmod-acl-model-16 uses the = feature statements in the YANG model allowing vendors to advertise match rules = they are capable and willing to support but not at the field-level. The = problem is router implementations today don=92t support ACLs with tcp = sequence-number, acknowledgement-number, window-size etc but support TCP flags. If the = server could convey the list of match criteria supported, it not only allows = the client to convey the supported match rules but also allows the server in future to advertise the new supported match fields. =20 =20 Would it be useful for a client to retrieve the list of match criteria supported by a DOTS server?=20 =20 [TR2] Yes.=20 =20 -Tiru =20 [TR] The YANG model supported by the DOTS server can retrieved by the = DOTS client using RESTCONF to determine the match criteria supported by the server.=20 [Med] I=92m afraid this is not the same functionality. If we need to = allow a server to return its supported match criteria, this should be allowed by = the module. For example, the module may include the following (example):=20 =20 +--ro capabilities | +--ro match-header* | | identityref | +--ro transport-protocols* [protocol-id] | | +--ro protocol-id uint8 | | +--ro protocol-name? string | +--ro dscp-support? boolean | +--ro ecn-support? boolean | +--ro length-support? boolean | +--ro ttl-support? boolean | +--ro protocol-support? boolean =20 The client can ask the server to return its supported match criteria. = The server will indicate the exact set of fields it supports.=20 =20 I=92m not expressing a preference to have this in the model, but I=92m clarifying how it would look like.=20 =20 -Tiru =20 Please comment.=20 =20 Cheers, Med ------=_NextPart_000_002E_01D3AA2A.C2032250 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

As the intent is to follow netmod-acl-model = syntax, having a DOTS version of some of the parameters makes no sense = to me.

 

For example, the DOTS = server when communicating with the DOTS mitigator (albeit out of scope) = will have to translate the current set of ACL definitions into something = – e.g. real netconf-acl.=A0 With the exact modelling of = netmod-acl-model parameters, life is a lot easier as we just have to = strip out the DOTS specific parameters (e.g. = lifetimes).

 

The right place to get = this done is to get the netmod-acl-model authors to update their = definitions of ietf-packet-fields.

 

As = draft-ietf-netmod-acl-16 can possibly change (we have seen significant = changes over the last few updates), we need to consider referring to the = specific version of ietf-packet-fields in the DOTS data channel Yang = model.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com
Sent: 19 February 2018 = 07:52
To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; = dots@ietf.org
Subject: [Dots] draft-ietf-dots-data-channel: = Value and/or Range

 

Hi Jon,

 

Good point.

 

Actually, some filtering parameters are worth to be = supplied as values or ranges but the current netmod module does not = allow for it. I can cite:

=B7        = Length = fields

=B7        = TTL

 

Do we need to have value/range supported in the module = for these fields?

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] =
Envoy=E9 : vendredi 16 f=E9vrier 2018 = 17:14
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR = Mohamed IMT/OLN; dots@ietf.org
Objet : RE: [Dots] = draft-ietf-dots-data-channel: Filtering = Fields

 

Ttl is an interesting one.  It is not = definable as a range, and so if you want to match “ttl lt = 16” you are going to have to have 16 ACLs preceding any other ACL = that does anything else.

 

I would expect that = ‘ttl’ would be done properly as a one of the mitigator = rules, and DOTS does not need to ‘hint’ it as = well.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 16 February 2018 = 15:46
To: mohamed.boucadair@orange.com= ; Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] draft-ietf-dots-data-channel: Filtering = Fields

 

We may want to add =

 

1)     = UDP = (length) to the list. It may be useful to block large DNS packets (e.g. = DNS amplification attack).

2)     = In = IPv4/IPv6, add length, ttl (https://www.cisco.com/c/en/us/about/security-center/ttl-expiry= -attack.html) to the list.

 

-Tiru

 

From: mohamed.boucadair@orange.com= [mailto:mohamed.boucadair@ora= nge.com]
Sent: Friday, February 16, 2018 8:04 = PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; Jon Shallow <supjps-ietf@jpshallow.com&g= t;; dots@ietf.org
Subject: RE: = [Dots] draft-ietf-dots-data-channel: Filtering = Fields

 

Re-,

 

Here is a tentative list:

 

   Header Mandatory = Fields

   ------ = --------------------------------------------------------------=

   IPv4   protocol, = source-port-range-or-operator, destination-port-

       &= nbsp;  range-or-operator, destination-ipv4-network, = source-

        =   ipv4-network, and v4-fragments

   IPv6   protocol, = source-port-range-or-operator, destination-port-

       &= nbsp;  range-or-operator, destination-ipv4-network, = source-

       &= nbsp;  ipv4-network,and v6-fragments

   TCP    = flags

   ICMP   type and = code

 

Please comment/update. =

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] = De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : = vendredi 16 f=E9vrier 2018 14:55
=C0 : BOUCADAIR Mohamed = IMT/OLN; Jon Shallow; dots@ietf.org
Objet : = Re: [Dots] draft-ietf-dots-data-channel: Filtering = Fields

 

+1. In TCP, only = “flags” field looks mandatory.

 

-Tiru

 

From: mohamed.boucadair@orange.com= [mailto:mohamed.boucadair@ora= nge.com]
Sent: Friday, February 16, 2018 7:03 = PM
To: Jon Shallow <supjps-ietf@jpshallow.com&g= t;; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; dots@ietf.org
Subject: RE: = [Dots] draft-ietf-dots-data-channel: Filtering = Fields

 

Re-,

 

I tend to agree with you to have to define a minimum = set of mandatory match fields.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Envoy=E9 : vendredi 16 f=E9vrier 2018 = 14:29
=C0 : BOUCADAIR Mohamed IMT/OLN; Konda, = Tirumaleswar Reddy; dots@ietf.org
Objet : = RE: [Dots] draft-ietf-dots-data-channel: Filtering = Fields

 

Hi Med,

 

See inline = [Jon]

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of mohamed.boucadair@orange.com=
Sent: 16 February 2018 12:56
To: Jon Shallow; = 'Konda, Tirumaleswar Reddy'; dots@ietf.org
Subject: Re: = [Dots] draft-ietf-dots-data-channel: Filtering = Fields

 

Jon,

 

Thank you for sharing your thoughts. =

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Envoy=E9 : vendredi 16 f=E9vrier 2018 = 13:24
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR = Mohamed IMT/OLN; dots@ietf.org
Objet : = RE: [Dots] draft-ietf-dots-data-channel: Filtering = Fields

 

I like =
the concept of “+--ro capabilities“ =
allowing for future support as the DOS server becomes more mature in its =
capabilities.
&nb=
sp;
If a =
DOTS client includes a filtering field parameter that is not currently =
supported, should the parameter be ignored (and not returned for a GET), =
or the request rejected?
[Med] I would vote for =
rejecting the request. The client should only use match criteria that =
are understood by the server; otherwise there will be different =
expectation from the service. 
[Jon] I =
think that this is my preference – I was just seeking clarity of =
thinking.
 <=
/pre>
It is =
conceivable that a DOTS client has 2 DOTS servers (one possibly a =
backup, or 2 different ISPs), which may have differing filtering field =
parameter support capabilities.
[Med] The backup/case seems =
odd. I would expect a feature parity for a redundancy group used to =
provide the same service.
=
[Jon] Agreed that =
a backup server is most likely to be from the same manufacturer and =
hence support the same functionality.  But one may have just been =
upgraded to have extra support.
 <=
/pre>
 
<=
pre> 
<=
pre>  =
Adding in intelligence code to work out what is / is not allowed may not =
be practical in a (memory or cpu) constrained environment of the DOTS =
client.
[Med] Fair. =

&nb=
sp;
That =
said, I think we need to define the minimum set of supported parameters =
– e.g. protocol, source / dest ports,  source / dest IPv4 =
prefixes, source / dest IPv6 prefixes, fragments and icmp type/code. =

[Jon] =
Any comments?
 <=
/pre>
-Jon
 <=
/pre>
Regards<=
o:p>
&nb=
sp;
Jon
 
From: Dots [mailto: dots-bounces@ietf.org] On =
Behalf Of Konda, Tirumaleswar Reddy
Sent: 16 February 2018 =
10:18
To: mohamed.boucadair@orange.com=
; dots@ietf.org
Subject: Re: =
[Dots] draft-ietf-dots-data-channel: Filtering =
Fields
 
Hi =
Med,
 
Please see inline =
[TR2]
 
From: mohamed.boucadair@orange.com=
 [mailto:mohamed.boucadair@ora=
nge.com] 
Sent: Friday, February 16, 2018 1:45 =
PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond=
a@McAfee.com>; dots@ietf.org
Subject: RE: =
draft-ietf-dots-data-channel: Filtering =
Fields
 
Re-,
 
Please see inline. 
 
Cheers,
Med
 
De : Dots [mailto:dots-bounces@ietf.org] =
De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : =
vendredi 16 f=E9vrier 2018 08:00
=C0 : BOUCADAIR Mohamed =
IMT/OLN; dots@ietf.org
Objet : =
Re: [Dots] draft-ietf-dots-data-channel: Filtering =
Fields
 
From: Dots [mailto:dots-bounces@ietf.org] =
On Behalf Of mohamed.boucadair@orange.com=

Sent: Wednesday, February 14, 2018 1:49 PM
To: =
dots@ietf.org
Subject: =
[Dots] draft-ietf-dots-data-channel: Filtering =
Fields
 
Hi =
all, 
 
As =
agreed during the interim, there are some issues that need fixes in the =
data-channel spec. We would like to hear from the WG to know what to =
record in the document. 
 
Issue =
description: Should we support all of the match fields defined by =
“ietf-packet-fields” or do we need to define a minimum =
supported set? 
 
[TR] I don’t see the need to support all the match =
fields, define a minimum supported set (don’t see the use for =
acl-eth-header-fields for DOTS use cases). =
 
[Med] =
Agree that acl-eth-header-fields aren’t required. The text is =
already clear about this:
 
DOTS implementations MUST support the =
following
   matching criteria: match =
based on the IP header (IPv4 and IPv6),
   match based on the transport =
header (TCP, UDP, and ICMP), and any
   combination =
thereof.
 
The question is whether we =
need to go further and mandate (or not) the support of matching based on =
specific fields: dscp, ecn, ttl,… flow-label, … tcp sequence-number, =
tcp flags, …  
 
[TR2] https://tools.ietf.org/html/draft-ietf-netmod-acl-model-16 uses the feature statements in the =
YANG model allowing vendors to advertise match rules they are capable =
and willing to support but not at the field-level. The problem is router =
implementations today don’t support ACLs with tcp sequence-number, =
acknowledgement-number, window-size etc but support TCP flags. If the =
server could convey the list of match criteria supported, it not only =
allows the client to convey the supported match rules but also allows =
the server in future to advertise the new supported match fields. =
  
 
Would =
it be useful for a client to retrieve the list of match criteria =
supported by a DOTS server? 
 
[TR2] Yes. 
 
-Tiru
 
[TR] The YANG model supported by =
the DOTS server can retrieved by the DOTS client using RESTCONF to =
determine the match criteria supported by the server. =

[Med] =
I’m afraid this is not the same functionality. If we need to allow =
a server to return its supported match criteria, this should be allowed =
by the module. For example, the module may include the following =
(example): 
 
       &=
nbsp;        +--ro =
capabilities
       &=
nbsp;        |  +--ro =
match-header*
       &=
nbsp;        |  =
|       =
identityref
       &=
nbsp;        |  +--ro =
transport-protocols* [protocol-id]
       &=
nbsp;        |  |  +--ro =
protocol-id      =
uint8
       &=
nbsp;        |  |  +--ro =
protocol-name?   string
       &=
nbsp;        |  +--ro =
dscp-support? =
      boolean
<=
span lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Courier =
New";mso-fareast-language:FR'>       &=
nbsp;        |  +--ro =
ecn-support? =
       boolean
=

       &=
nbsp;        |  +--ro =
length-support? =
    boolean
       &=
nbsp;        |  +--ro =
ttl-support? =
       boolean
=

       &=
nbsp;        |  +--ro =
protocol-support?   boolean
 
The client can ask the server to return =
its supported match criteria. The server =
will indicate the exact set of fields it supports. =

 
<=
pre>I’m not expressing a =
preference to have this in the model, but I’m clarifying how it =
would look like. 
 
-Tiru
 
Please comment. =

 
Cheers,
Med
------=_NextPart_000_002E_01D3AA2A.C2032250-- From nobody Tue Feb 20 01:22:28 2018 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 0EE00126D74 for ; Tue, 20 Feb 2018 01:22:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.628 X-Spam-Level: X-Spam-Status: No, score=-2.628 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5QRBlsxUAVK for ; Tue, 20 Feb 2018 01:22:23 -0800 (PST) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 485D5124239 for ; Tue, 20 Feb 2018 01:22:23 -0800 (PST) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 176151217D5; Tue, 20 Feb 2018 10:22:22 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.31]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id DE8FD18003F; Tue, 20 Feb 2018 10:22:21 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1%19]) with mapi id 14.03.0382.000; Tue, 20 Feb 2018 10:22:21 +0100 From: To: Jon Shallow , "Konda, Tirumaleswar Reddy" , "dots@ietf.org" Thread-Topic: [Dots] draft-ietf-dots-data-channel: Value and/or Range Thread-Index: AQH1VnM7gmrBb4hUSjAUETC1ZBiLc6NppOMQgAAE4uA= Date: Tue, 20 Feb 2018 09:22:21 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0D4FC7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300A0D42F4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <002d01d3aa2a$c1ff03a0$45fd0ae0$@jpshallow.com> In-Reply-To: <002d01d3aa2a$c1ff03a0$45fd0ae0$@jpshallow.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A0D4FC7OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] draft-ietf-dots-data-channel: Value and/or Range 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: Tue, 20 Feb 2018 09:22:27 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A0D4FC7OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jon, I confirm that the intent is not to discuss "how" or "have a DOTS version o= f the parameters" but whether the functionality is useful (including when t= ranslating filtering rules into network-specific actions). What I had initially in mind is, based on the outcome of the discussion, ra= ise the point during the IETF LC of draft-ietf-netmod-acl and push for it t= here. Glad to see that we are in agreement. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mardi 20 f=E9vrier 2018 10:11 =C0 : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; dots@ietf.org Objet : RE: [Dots] draft-ietf-dots-data-channel: Value and/or Range As the intent is to follow netmod-acl-model syntax, having a DOTS version o= f some of the parameters makes no sense to me. For example, the DOTS server when communicating with the DOTS mitigator (al= beit out of scope) will have to translate the current set of ACL definition= s into something - e.g. real netconf-acl. With the exact modelling of netm= od-acl-model parameters, life is a lot easier as we just have to strip out = the DOTS specific parameters (e.g. lifetimes). The right place to get this done is to get the netmod-acl-model authors to = update their definitions of ietf-packet-fields. As draft-ietf-netmod-acl-16 can possibly change (we have seen significant c= hanges over the last few updates), we need to consider referring to the spe= cific version of ietf-packet-fields in the DOTS data channel Yang model. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 19 February 2018 07:52 To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org Subject: [Dots] draft-ietf-dots-data-channel: Value and/or Range Hi Jon, Good point. Actually, some filtering parameters are worth to be supplied as values or r= anges but the current netmod module does not allow for it. I can cite: =B7 Length fields =B7 TTL Do we need to have value/range supported in the module for these fields? Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 16 f=E9vrier 2018 17:14 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org= Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields Ttl is an interesting one. It is not definable as a range, and so if you w= ant to match "ttl lt 16" you are going to have to have 16 ACLs preceding an= y other ACL that does anything else. I would expect that 'ttl' would be done properly as a one of the mitigator = rules, and DOTS does not need to 'hint' it as well. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 16 February 2018 15:46 To: mohamed.boucadair@orange.com; Jon = Shallow; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields We may want to add 1) UDP (length) to the list. It may be useful to block large DNS packe= ts (e.g. DNS amplification attack). 2) In IPv4/IPv6, add length, ttl (https://www.cisco.com/c/en/us/about/= security-center/ttl-expiry-attack.html) to the list. -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 8:04 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields Re-, Here is a tentative list: Header Mandatory Fields ------ -------------------------------------------------------------- IPv4 protocol, source-port-range-or-operator, destination-port- range-or-operator, destination-ipv4-network, source- ipv4-network, and v4-fragments IPv6 protocol, source-port-range-or-operator, destination-port- range-or-operator, destination-ipv4-network, source- ipv4-network,and v6-fragments TCP flags ICMP type and code Please comment/update. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 16 f=E9vrier 2018 14:55 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields +1. In TCP, only "flags" field looks mandatory. -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 7:03 PM To: Jon Shallow >; Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields Re-, I tend to agree with you to have to define a minimum set of mandatory match= fields. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 16 f=E9vrier 2018 14:29 =C0 : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; dots@ietf.org Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields Hi Med, See inline [Jon] Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 16 February 2018 12:56 To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields Jon, Thank you for sharing your thoughts. Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 16 f=E9vrier 2018 13:24 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org= Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields I like the concept of "+--ro capabilities" allowing for future support as t= he DOS server becomes more mature in its capabilities. If a DOTS client includes a filtering field parameter that is not currently= supported, should the parameter be ignored (and not returned for a GET), o= r the request rejected? [Med] I would vote for rejecting the request. The client should only use ma= tch criteria that are understood by the server; otherwise there will be dif= ferent expectation from the service. [Jon] I think that this is my preference - I was just seeking clarity of th= inking. It is conceivable that a DOTS client has 2 DOTS servers (one possibly a bac= kup, or 2 different ISPs), which may have differing filtering field paramet= er support capabilities. [Med] The backup/case seems odd. I would expect a feature parity for a redu= ndancy group used to provide the same service. [Jon] Agreed that a backup server is most likely to be from the same manufa= cturer and hence support the same functionality. But one may have just bee= n upgraded to have extra support. Adding in intelligence code to work out what is / is not allowed may not = be practical in a (memory or cpu) constrained environment of the DOTS clien= t. [Med] Fair. That said, I think we need to define the minimum set of supported parameter= s - e.g. protocol, source / dest ports, source / dest IPv4 prefixes, sourc= e / dest IPv6 prefixes, fragments and icmp type/code. [Jon] Any comments? -Jon Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 16 February 2018 10:18 To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields Hi Med, Please see inline [TR2] From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 1:45 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: draft-ietf-dots-data-channel: Filtering Fields Re-, Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 16 f=E9vrier 2018 08:00 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Wednesday, February 14, 2018 1:49 PM To: dots@ietf.org Subject: [Dots] draft-ietf-dots-data-channel: Filtering Fields Hi all, As agreed during the interim, there are some issues that need fixes in the = data-channel spec. We would like to hear from the WG to know what to record= in the document. Issue description: Should we support all of the match fields defined by "ie= tf-packet-fields" or do we need to define a minimum supported set? [TR] I don't see the need to support all the match fields, define a minimum= supported set (don't see the use for acl-eth-header-fields for DOTS use ca= ses). [Med] Agree that acl-eth-header-fields aren't required. The text is already= clear about this: DOTS implementations MUST support the following matching criteria: match based on the IP header (IPv4 and IPv6), match based on the transport header (TCP, UDP, and ICMP), and any combination thereof. The question is whether we need to go further and mandate (or not) the supp= ort of matching based on specific fields: dscp, ecn, ttl,... flow-label, ..= . tcp sequence-number, tcp flags, ... [TR2] https://tools.ietf.org/html/draft-ietf-netmod-acl-model-16 uses the f= eature statements in the YANG model allowing vendors to advertise match rul= es they are capable and willing to support but not at the field-level. The = problem is router implementations today don't support ACLs with tcp sequenc= e-number, acknowledgement-number, window-size etc but support TCP flags. If= the server could convey the list of match criteria supported, it not only = allows the client to convey the supported match rules but also allows the s= erver in future to advertise the new supported match fields. Would it be useful for a client to retrieve the list of match criteria supp= orted by a DOTS server? [TR2] Yes. -Tiru [TR] The YANG model supported by the DOTS server can retrieved by the DOTS = client using RESTCONF to determine the match criteria supported by the serv= er. [Med] I'm afraid this is not the same functionality. If we need to allow a = server to return its supported match criteria, this should be allowed by th= e module. For example, the module may include the following (example): +--ro capabilities | +--ro match-header* | | identityref | +--ro transport-protocols* [protocol-id] | | +--ro protocol-id uint8 | | +--ro protocol-name? string | +--ro dscp-support? boolean | +--ro ecn-support? boolean | +--ro length-support? boolean | +--ro ttl-support? boolean | +--ro protocol-support? boolean The client can ask the server to return its supported match criteria. The s= erver will indicate the exact set of fields it supports. I'm not expressing a preference to have this in the model, but I'm clarifyi= ng how it would look like. -Tiru Please comment. Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300A0D4FC7OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jon,

 

I confirm that the intent is no= t to discuss “how” or “have a DOTS version of the paramet= ers” but whether the functionality is useful (including when translat= ing filtering rules into network-specific actions).

 

What I had initially in mind is= , based on the outcome of the discussion, raise the point during the IETF L= C of draft-ietf-netmod-acl and push for it there.

 

Glad to see that we are in agre= ement.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf= @jpshallow.com]
Envoy=E9 : mardi 20 f=E9vrier 2018 10:11
=C0 : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; dot= s@ietf.org
Objet : RE: [Dots] draft-ietf-dots-data-channel: Value and/or R= ange

 

As the = intent is to follow netmod-acl-model syntax, having a DOTS version of some = of the parameters makes no sense to me.

&n= bsp;

For exa= mple, the DOTS server when communicating with the DOTS mitigator (albeit ou= t of scope) will have to translate the current set of ACL definitions into = something – e.g. real netconf-acl.  With the exact modelling of netmod-acl-model parameters, life is a lot easier a= s we just have to strip out the DOTS specific parameters (e.g. lifetimes).<= o:p>

&n= bsp;

The rig= ht place to get this done is to get the netmod-acl-model authors to update = their definitions of ietf-packet-fields.

&n= bsp;

As draf= t-ietf-netmod-acl-16 can possibly change (we have seen significant changes = over the last few updates), we need to consider referring to the specific v= ersion of ietf-packet-fields in the DOTS data channel Yang model.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 19 February 2018 07:52
To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org
Subject: [Dots] draft-ietf-dots-data-channel: Value and/or Range

 

Hi Jon,

 

Good point.

 

Actually, some filtering parame= ters are worth to be supplied as values or ranges but the current netmod mo= dule does not allow for it. I can cite:

=B7    &n= bsp;    Length fields

=B7    &n= bsp;    TTL

 

Do we need to have value/range = supported in the module for these fields?

 

Cheers,

Med

 

J= on Shallow [mailto:supjps-ietf@jpshallow.= com]
Envoy=E9 : vendredi 16 f=E9vrier 2018 17:14
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; <= /span>= dots@ietf.org
Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fiel= ds

 

Ttl is = an interesting one.  It is not definable as a range, and so if you wan= t to match “ttl lt 16” you are going to have to have 16 ACLs pr= eceding any other ACL that does anything else.

&n= bsp;

I would= expect that ‘ttl’ would be done properly as a one of the mitig= ator rules, and DOTS does not need to ‘hint’ it as well.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 16 February 2018 15:46
To: mohamed.boucadai= r@orange.com; Jon Shallow; dots@ietf.org
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields

 

We may want to add

 

1)      UDP (lengt= h) to the list. It may be useful to block large DNS packets (e.g. DNS ampli= fication attack).

2)      In IPv4/IP= v6, add length, ttl (https://www.cisco.com/c/en/us/about/securi= ty-center/ttl-expiry-attack.html) to the list.

 

-Tiru

 

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Friday, February 16, 2018 8:04 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields

 

Re-,

 

Here is a tentative list:

 

   Header= Mandatory Fields

   ------= --------------------------------------------------------------<= /span>

   IPv4&n= bsp;  protocol, source-port-range-or-operator, destination-port-<= /o:p>

   &= nbsp;      range-or-operator, destination-ipv4-net= work, source-

   &= nbsp;      ipv4-network, and v4-fragments

   IPv6&n= bsp;  protocol, source-port-range-or-operator, destination-port-<= /o:p>

   &= nbsp;      range-or-operator, destination-ipv4-net= work, source-

   &= nbsp;      ipv4-network,and v6-fragments

   TCP&nb= sp;   flags

   ICMP   type and code

 

Please comment/update.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : vendredi 16 f=E9vrier 2018 14:55
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fiel= ds

 

+1. In TCP, only “flags” field looks mandatory.

 

-Tiru

 

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Friday, February 16, 2018 7:03 PM
To: Jon Shallow <sup= jps-ietf@jpshallow.com>; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org
Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields

 

Re-,

 

I tend to agree with you to hav= e to define a minimum set of mandatory match fields.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : vendredi 16 f=E9vrier 2018 14:29
=C0 : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; dots@ietf.org
Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fiel= ds

 

Hi Med,=

&n= bsp;

See inl= ine [Jon]

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 16 February 2018 12:56
To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields

 

Jon,

 

Thank you for sharing your thou= ghts.

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : vendredi 16 f=E9vrier 2018 13:24
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; <= a href=3D"mailto:dots@ietf.org"> dots@ietf.org
Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fiel= ds

 

I like the concept of “+--ro capabilities“ allowing for futu=
re support as the DOS server becomes more mature in its capabilities.<=
/o:p>
 
If a DOTS client includes a filtering field parameter that =
is not currently supported, should the parameter be ignored (and not return=
ed for a GET), or the request rejected?
[Med] I would vote for re=
jecting the request. The client should only use match criteria that are und=
erstood by the server; otherwise there will be different expectation from t=
he service. 
[Jon] I think that this is my preference – I was just=
 seeking clarity of thinking.
<=
o:p> 
It is conceivable that a DOTS client has 2 DOTS servers (on=
e possibly a backup, or 2 different ISPs), which may have differing filteri=
ng field parameter support capabilities.
[Med] The backup/case see=
ms odd. I would expect a feature parity for a redundancy group used to prov=
ide the same service.=

[=
Jon] Agreed that a backup server is most likely to be from the same manufac=
turer and hence support the same functionality.  But one may have just=
 been upgraded to have extra support.
<=
o:p> 
 <=
/pre>

 <=
/pre>

  Adding in intelligence code to work out what is / is=
 not allowed may not be practical in a (memory or cpu) constrained environm=
ent of the DOTS client.


[Med] Fair. 


 


That said, I think we need to define the minimum set of sup=
ported parameters – e.g. protocol, source / dest ports,  source =
/ dest IPv4 prefixes, source / dest IPv6 prefixes, fragments and icmp type/=
code. 


[Jon] Any comments?


<=
o:p> 


-=
Jon


<=
o:p> 


Regards


 


Jon


&n=
bsp;






From:=
 Dots [mailto:
dots-bounces@ietf.org] On B=
ehalf Of
Konda, Tirumaleswar Reddy

Sent: 16 February 2018 10:18

To: mohamed.boucadai=
r@orange.com;
dots@ietf.org

Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields






 


Hi Med,


 


Please see inline [TR2]


 








From:
mohamed.boucadair@orange.co=
m [mailto:mohamed.bouca=
dair@orange.com]


Sent: Friday, February 16, 2018 1:45 PM

To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>;
dots@ietf.org

Subject: RE: draft-ietf-dots-data-channel: Filtering Fields






 


Re-,


 


Please see inline.



 


Cheers,


Med


 








De : Dots [mailto:dots-bounces@ietf.org]
De la part de Konda, Tirumaleswar Reddy

Envoy=E9 : vendredi 16 f=E9vrier 2018 08:00

=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org

Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fiel=
ds






 


From: Dots [mailto:dots-bounces=
@ietf.org]
On Behalf Of mohamed=
.boucadair@orange.com

Sent: Wednesday, February 14, 2018 1:49 PM

To: dots@ietf.org

Subject: [Dots] draft-ietf-dots-data-channel: Filtering Fields<=
/o:p>


 


Hi all,



 


As agreed during the interim, there are som=
e issues that need fixes in the data-channel spec. We would like to hear fr=
om the WG to know what to record in the document.



 


Issue description: Should we support all of=
 the match fields defined by “ietf-packet-fields” or do we need=
 to define a minimum supported set?



 


[TR] I don’t see the need=
 to support all the match fields, define a minimum supported set (don’=
;t see the use for acl-eth-header-fields for DOTS use cases).  


[Med] Agree that acl-eth-header=
-fields aren’t required. The text is already clear about this:


 


DOTS implementation=
s MUST support the following


   matchi=
ng criteria: match based on the IP header (IPv4 and IPv6),


   match =
based on the transport header (TCP, UDP, and ICMP), and any


  
combination thereof.


 


The question is whether w=
e need to go further and mandate (or not) the support of matching based on =
specific fields: dscp, ecn, ttl,… flow-label, … tcp sequence-number, tcp flags, …  


 


[TR2] https=
://tools.ietf.org/html/draft-ietf-netmod-acl-model-16 uses the feature statem=
ents in the YANG model allowing vendors to advertise match rules they are c=
apable and willing to support but not at the field-level. The problem is ro=
uter implementations today don’t support ACLs with tcp sequence-numbe=
r, acknowledgement-number, window-size etc but support TCP flags. If the se=
rver could convey the list of match criteria supported, it not only allows =
the client to convey the supported match rules but also allows the server i=
n future to advertise the new supported match fields.   


 


Would it be useful for a client to retrieve=
 the list of match criteria supported by a DOTS server?



 


[TR2] Yes. 

 


-Tiru


 


[TR] The YANG model supported b=
y the DOTS server can retrieved by the DOTS client using RESTCONF to determ=
ine the match criteria supported by the server.



[Med] I’m afraid this is =
not the same functionality. If we need to allow a server to return its supp=
orted match criteria, this should be allowed by the module.
 For example, the module may include the following (example): 


 


      &=
nbsp;         +--ro capabilitie=
s


      &=
nbsp;         |  +--ro mat=
ch-header*


      &=
nbsp;         |  |  =
     identityref


      &=
nbsp;         |  +--ro tra=
nsport-protocols* [protocol-id]


      &=
nbsp;         |  |  +=
--ro protocol-id      uint8

      &=
nbsp;         |  |  +=
--ro protocol-name?   string


      &=
nbsp;         |  +--ro dsc=
p-support?       boolean

      &=
nbsp;         |  +--ro ecn=
-support?        boolean


      &=
nbsp;         |  +--ro len=
gth-support?     boolean


      &=
nbsp;         |  +--ro ttl=
-support?        boolean


      &=
nbsp;         |  +--ro pro=
tocol-support?   boolean


 


The client can ask the server to retu=
rn its supported match criteria. The server wil=
l indicate the exact set of fields it supports. 

 <=
/pre>

I’m not expressing =
a preference to have this in the model, but I’m clarifying how it wou=
ld look like. 

 


-Tiru


 


Please com=
ment.



 =
;


Cheers,


Med=
<=
/o:p>
--_000_787AE7BB302AE849A7480A190F8B93300A0D4FC7OPEXCLILMA3corp_-- From nobody Tue Feb 20 01:49:29 2018 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 18398127077 for ; Tue, 20 Feb 2018 01:49:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 oDNIP-phlKM9 for ; Tue, 20 Feb 2018 01:49:26 -0800 (PST) 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 8F45A124239 for ; Tue, 20 Feb 2018 01:49:25 -0800 (PST) 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 1eo4Y7-0003vF-G0; Tue, 20 Feb 2018 09:49:23 +0000 From: "Jon Shallow" To: , "Konda, Tirumaleswar Reddy" , References: <787AE7BB302AE849A7480A190F8B93300A0D1F93@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0D32AE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00e801d3a721$08806d30$19814790$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0D366E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019201d3a72a$1b103b70$5130b250$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0D372A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0D3847@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <020a01d3a739$9fd9ec70$df8dc550$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0D3914@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A0D3914@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Tue, 20 Feb 2018 09:49:23 -0000 Message-ID: <005201d3aa30$16a17af0$43e470d0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0053_01D3AA30.16A5C0B0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLoxvz0kGpX/tRyz6XeuCXxpheRlwMZabEuApwt0GoCITdLGgK2/q2yAt/zojQB0mpcSAMW+5mCAaQFvl8BTSXY9AGHUoOGAhdF0YOgu5g6sA== Content-Language: en-gb Archived-At: Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields 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: Tue, 20 Feb 2018 09:49:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0053_01D3AA30.16A5C0B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Med, =20 If we go with the capabilities model, instead of just defining the = subset that is supported in the filter fields in the Yang model, the below suggestion adds in a lot of bloat into the packets as well as extra code = in the DOTS server (which could be in a constrained environment =96e.g. in https://tools.ietf.org/html/draft-ietf-dots-use-cases-09#section-3.2.1). =20 For example, all 256 different IP protocols will have to be defined = under transport-protocols, along with their protocol names if all of them are = to be supported (yes, I know 0 and 255 sometimes have special meanings!). =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 16 February 2018 15:55 To: Jon Shallow; Konda, Tirumaleswar Reddy; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields =20 Re-, =20 I went in my local copy with the =93uses packet-fields:acl-xxx=94 for = managing filters, but added a new container to list the capabilities to our = module. Below an excerpt of the (draft) tree structure: =20 +--ro capabilities +--ro address-family* enumeration +--ro supported-actions* identityref +--ro fragment-support* enumeration +--ro transport-protocols* [protocol-id] | +--ro protocol-id uint8 | +--ro protocol-name? string +--ro ip-header-fields +--ro dscp-support? boolean +--ro ecn-support? boolean +--ro v4-length-support? boolean +--ro v6-length-support? boolean +--ro v4-ttl-support? boolean +--ro v6-hoplimit-support? boolean +--ro v4-ihl? boolean +--ro v4-flags? boolean +--ro v4-offset? boolean +--ro v4-identification? boolean +--ro v6-flowlabel? boolean +--ro destination-prefix? boolean +--ro source-prefix? boolean =85 =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : vendredi 16 f=E9vrier 2018 16:20 =C0 : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; = dots@ietf.org Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields =20 Hi Med, =20 I agree with the list (and am likely to only implement those!). =20 As I see it, there are 2 possible ways forward here =20 1) We add in an Boolean =91supported=92 capability for the list of = all the other options in packet-fields:acl-xxx 2) We drop the use of =93uses packet-fields:acl-xxx=94 and define = our own required entries, exactly modelled on draft-ietf-netmod-acl-model-16 definitions. =20 Comments? =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 16 February 2018 14:34 To: Konda, Tirumaleswar Reddy; Jon Shallow; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields =20 Re-, =20 Here is a tentative list:=20 =20 Header Mandatory Fields ------ -------------------------------------------------------------- IPv4 protocol, source-port-range-or-operator, destination-port- range-or-operator, destination-ipv4-network, source- ipv4-network, and v4-fragments IPv6 protocol, source-port-range-or-operator, destination-port- range-or-operator, destination-ipv4-network, source- ipv4-network,and v6-fragments TCP flags ICMP type and code =20 Please comment/update.=20 =20 Cheers, Med =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, = Tirumaleswar Reddy Envoy=E9 : vendredi 16 f=E9vrier 2018 14:55 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields =20 +1. In TCP, only =93flags=94 field looks mandatory.=20 =20 -Tiru =20 From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] = Sent: Friday, February 16, 2018 7:03 PM To: Jon Shallow ; Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields =20 Re-, =20 I tend to agree with you to have to define a minimum set of mandatory = match fields.=20 =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : vendredi 16 f=E9vrier 2018 14:29 =C0 : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; = dots@ietf.org Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields =20 Hi Med, =20 See inline [Jon] =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 16 February 2018 12:56 To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields =20 Jon, =20 Thank you for sharing your thoughts.=20 =20 Please see inline. =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : vendredi 16 f=E9vrier 2018 13:24 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; = dots@ietf.org Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields =20 I like the concept of =93+--ro capabilities=93 allowing for future = support as the DOS server becomes more mature in its capabilities. =20 If a DOTS client includes a filtering field parameter that is not = currently supported, should the parameter be ignored (and not returned for a GET), = or the request rejected? [Med] I would vote for rejecting the request. The client should only use match criteria that are understood by the server; otherwise there will = be different expectation from the service.=20 [Jon] I think that this is my preference =96 I was just seeking clarity = of thinking. =20 It is conceivable that a DOTS client has 2 DOTS servers (one possibly a backup, or 2 different ISPs), which may have differing filtering field parameter support capabilities. [Med] The backup/case seems odd. I would expect a feature parity for a redundancy group used to provide the same service. [Jon] Agreed that a backup server is most likely to be from the same manufacturer and hence support the same functionality. But one may have just been upgraded to have extra support. =20 =20 =20 Adding in intelligence code to work out what is / is not allowed may = not be practical in a (memory or cpu) constrained environment of the DOTS client. [Med] Fair.=20 =20 That said, I think we need to define the minimum set of supported = parameters =96 e.g. protocol, source / dest ports, source / dest IPv4 prefixes, = source / dest IPv6 prefixes, fragments and icmp type/code.=20 [Jon] Any comments? =20 -Jon =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 16 February 2018 10:18 To: mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields =20 Hi Med, =20 Please see inline [TR2] =20 From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] = Sent: Friday, February 16, 2018 1:45 PM To: Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: RE: draft-ietf-dots-data-channel: Filtering Fields =20 Re-, =20 Please see inline.=20 =20 Cheers, Med =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, = Tirumaleswar Reddy Envoy=E9 : vendredi 16 f=E9vrier 2018 08:00 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields =20 From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: Wednesday, February 14, 2018 1:49 PM To: dots@ietf.org Subject: [Dots] draft-ietf-dots-data-channel: Filtering Fields =20 Hi all,=20 =20 As agreed during the interim, there are some issues that need fixes in = the data-channel spec. We would like to hear from the WG to know what to = record in the document.=20 =20 Issue description: Should we support all of the match fields defined by =93ietf-packet-fields=94 or do we need to define a minimum supported = set?=20 =20 [TR] I don=92t see the need to support all the match fields, define a = minimum supported set (don=92t see the use for acl-eth-header-fields for DOTS = use cases). =20 [Med] Agree that acl-eth-header-fields aren=92t required. The text is = already clear about this: =20 DOTS implementations MUST support the following matching criteria: match based on the IP header (IPv4 and IPv6), match based on the transport header (TCP, UDP, and ICMP), and any combination thereof. =20 The question is whether we need to go further and mandate (or not) the support of matching based on specific fields: dscp, ecn, ttl,=85 = flow-label, =85 tcp sequence-number, tcp flags, =85 =20 =20 [TR2] https://tools.ietf.org/html/draft-ietf-netmod-acl-model-16 uses the = feature statements in the YANG model allowing vendors to advertise match rules = they are capable and willing to support but not at the field-level. The = problem is router implementations today don=92t support ACLs with tcp = sequence-number, acknowledgement-number, window-size etc but support TCP flags. If the = server could convey the list of match criteria supported, it not only allows = the client to convey the supported match rules but also allows the server in future to advertise the new supported match fields. =20 =20 Would it be useful for a client to retrieve the list of match criteria supported by a DOTS server?=20 =20 [TR2] Yes.=20 =20 -Tiru =20 [TR] The YANG model supported by the DOTS server can retrieved by the = DOTS client using RESTCONF to determine the match criteria supported by the server.=20 [Med] I=92m afraid this is not the same functionality. If we need to = allow a server to return its supported match criteria, this should be allowed by = the module. For example, the module may include the following (example):=20 =20 +--ro capabilities | +--ro match-header* | | identityref | +--ro transport-protocols* [protocol-id] | | +--ro protocol-id uint8 | | +--ro protocol-name? string | +--ro dscp-support? boolean | +--ro ecn-support? boolean | +--ro length-support? boolean | +--ro ttl-support? boolean | +--ro protocol-support? boolean =20 The client can ask the server to return its supported match criteria. = The server will indicate the exact set of fields it supports.=20 =20 I=92m not expressing a preference to have this in the model, but I=92m clarifying how it would look like.=20 =20 -Tiru =20 Please comment.=20 =20 Cheers, Med ------=_NextPart_000_0053_01D3AA30.16A5C0B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Med,

 

If we go with the = capabilities model, instead of just defining the subset that is = supported in the filter fields in the Yang model, the below suggestion = adds in a lot of bloat into the packets as well as extra code in the = DOTS server (which could be in a constrained environment –e.g. = in https://tools.ietf.org/html/draft-ietf-dots-use-cases-09#section-3= .2.1).

 

For example, all 256 different IP = protocols will have to be defined under transport-protocols, along with = their protocol names if all of them are to be supported (yes, I know 0 = and 255 sometimes have special meanings!).

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com
Sent: 16 February 2018 = 15:55
To: Jon Shallow; Konda, Tirumaleswar Reddy; = dots@ietf.org
Subject: Re: [Dots] = draft-ietf-dots-data-channel: Filtering = Fields

 

Re-,

 

I went in my local copy with the “uses = packet-fields:acl-xxx” for managing filters, but added a new = container to list the capabilities to our module. Below an excerpt of = the (draft) tree structure:

 

    +--ro = capabilities

       +--ro = address-family*        = enumeration

       +--ro = supported-actions*     = identityref

       +--ro = fragment-support*      = enumeration

       +--ro = transport-protocols* [protocol-id]

       = |  +--ro protocol-id      = uint8

       = |  +--ro protocol-name?   string

       +--ro = ip-header-fields

       &= nbsp;  +--ro = dscp-support?          = boolean

       &= nbsp;  +--ro = ecn-support?           = boolean

       &= nbsp;  +--ro v4-length-support?     = boolean

       &= nbsp;  +--ro v6-length-support?     = boolean

       &= nbsp;  +--ro = v4-ttl-support?        = boolean

       &= nbsp;  +--ro v6-hoplimit-support?   = boolean

       &= nbsp;  +--ro = v4-ihl?           =      boolean

       &= nbsp;  +--ro = v4-flags?          &nbs= p;   boolean

       &= nbsp;  +--ro = v4-offset?          &nb= sp;  boolean

       &= nbsp;  +--ro v4-identification?     = boolean

       &= nbsp; +--ro = v6-flowlabel?          = boolean

       &= nbsp;  +--ro destination-prefix?    = boolean

       &= nbsp;  +--ro = source-prefix?         = boolean

         &= nbsp;   …

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Envoy=E9 : vendredi 16 f=E9vrier 2018 = 16:20
=C0 : BOUCADAIR Mohamed IMT/OLN; Konda, = Tirumaleswar Reddy; dots@ietf.org
Objet : = RE: [Dots] draft-ietf-dots-data-channel: Filtering = Fields

 

Hi Med,

 

I agree with the list = (and am likely to only implement those!).

 

As I see it, there are 2 = possible ways forward here

 

1)      = We add in = an Boolean ‘supported’ capability for the list of all the = other options in packet-fields:acl-xxx

2)      = We drop the = use of “uses packet-fields:acl-xxx” and define our own = required entries, exactly modelled on draft-ietf-netmod-acl-model-16 = definitions.

 

Comments?

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of mohamed.boucadair@orange.com=
Sent: 16 February 2018 14:34
To: Konda, = Tirumaleswar Reddy; Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] draft-ietf-dots-data-channel: Filtering = Fields

 

Re-,

 

Here is a tentative list:

 

   Header Mandatory = Fields

   ------ = --------------------------------------------------------------=

   IPv4   protocol, = source-port-range-or-operator, destination-port-

       &= nbsp;  range-or-operator, destination-ipv4-network, = source-

        =   ipv4-network, and v4-fragments

   IPv6   protocol, = source-port-range-or-operator, destination-port-

       &= nbsp;  range-or-operator, destination-ipv4-network, = source-

       &= nbsp;  ipv4-network,and v6-fragments

   TCP    = flags

   ICMP   type and = code

 

Please comment/update. =

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] = De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : = vendredi 16 f=E9vrier 2018 14:55
=C0 : BOUCADAIR Mohamed = IMT/OLN; Jon Shallow; dots@ietf.org
Objet : = Re: [Dots] draft-ietf-dots-data-channel: Filtering = Fields

 

+1. In TCP, only = “flags” field looks mandatory.

 

-Tiru

 

From: mohamed.boucadair@orange.com= [mailto:mohamed.boucadair@ora= nge.com]
Sent: Friday, February 16, 2018 7:03 = PM
To: Jon Shallow <supjps-ietf@jpshallow.com&g= t;; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; dots@ietf.org
Subject: RE: = [Dots] draft-ietf-dots-data-channel: Filtering = Fields

 

Re-,

 

I tend to agree with you to have to define a minimum = set of mandatory match fields.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Envoy=E9 : vendredi 16 f=E9vrier 2018 = 14:29
=C0 : BOUCADAIR Mohamed IMT/OLN; Konda, = Tirumaleswar Reddy; dots@ietf.org
Objet : = RE: [Dots] draft-ietf-dots-data-channel: Filtering = Fields

 

Hi Med,

 

See inline = [Jon]

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of mohamed.boucadair@orange.com=
Sent: 16 February 2018 12:56
To: Jon Shallow; = 'Konda, Tirumaleswar Reddy'; dots@ietf.org
Subject: Re: = [Dots] draft-ietf-dots-data-channel: Filtering = Fields

 

Jon,

 

Thank you for sharing your thoughts. =

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Envoy=E9 : vendredi 16 f=E9vrier 2018 = 13:24
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR = Mohamed IMT/OLN; dots@ietf.org
Objet : = RE: [Dots] draft-ietf-dots-data-channel: Filtering = Fields

 

I like =
the concept of “+--ro capabilities“ =
allowing for future support as the DOS server becomes more mature in its =
capabilities.
&nb=
sp;
If a =
DOTS client includes a filtering field parameter that is not currently =
supported, should the parameter be ignored (and not returned for a GET), =
or the request rejected?
[Med] I would vote for =
rejecting the request. The client should only use match criteria that =
are understood by the server; otherwise there will be different =
expectation from the service. 
[Jon] I =
think that this is my preference – I was just seeking clarity of =
thinking.
 <=
/pre>
It is =
conceivable that a DOTS client has 2 DOTS servers (one possibly a =
backup, or 2 different ISPs), which may have differing filtering field =
parameter support capabilities.
[Med] The backup/case seems =
odd. I would expect a feature parity for a redundancy group used to =
provide the same service.
=
[Jon] Agreed that =
a backup server is most likely to be from the same manufacturer and =
hence support the same functionality.  But one may have just been =
upgraded to have extra support.
 <=
/pre>
 
<=
pre> 
<=
pre>  =
Adding in intelligence code to work out what is / is not allowed may not =
be practical in a (memory or cpu) constrained environment of the DOTS =
client.
[Med] Fair. =

&nb=
sp;
That =
said, I think we need to define the minimum set of supported parameters =
– e.g. protocol, source / dest ports,  source / dest IPv4 =
prefixes, source / dest IPv6 prefixes, fragments and icmp type/code. =

[Jon] =
Any comments?
 <=
/pre>
-Jon
 <=
/pre>
Regards<=
o:p>
&nb=
sp;
Jon
 
From: Dots [mailto: dots-bounces@ietf.org] On =
Behalf Of Konda, Tirumaleswar Reddy
Sent: 16 February 2018 =
10:18
To: mohamed.boucadair@orange.com=
; dots@ietf.org
Subject: Re: =
[Dots] draft-ietf-dots-data-channel: Filtering =
Fields
 
Hi =
Med,
 
Please see inline =
[TR2]
 
From: mohamed.boucadair@orange.com=
 [mailto:mohamed.boucadair@ora=
nge.com] 
Sent: Friday, February 16, 2018 1:45 =
PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond=
a@McAfee.com>; dots@ietf.org
Subject: RE: =
draft-ietf-dots-data-channel: Filtering =
Fields
 
Re-,
 
Please see inline. 
 
Cheers,
Med
 
De : Dots [mailto:dots-bounces@ietf.org] =
De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : =
vendredi 16 f=E9vrier 2018 08:00
=C0 : BOUCADAIR Mohamed =
IMT/OLN; dots@ietf.org
Objet : =
Re: [Dots] draft-ietf-dots-data-channel: Filtering =
Fields
 
From: Dots [mailto:dots-bounces@ietf.org] =
On Behalf Of mohamed.boucadair@orange.com=

Sent: Wednesday, February 14, 2018 1:49 PM
To: =
dots@ietf.org
Subject: =
[Dots] draft-ietf-dots-data-channel: Filtering =
Fields
 
Hi =
all, 
 
As =
agreed during the interim, there are some issues that need fixes in the =
data-channel spec. We would like to hear from the WG to know what to =
record in the document. 
 
Issue =
description: Should we support all of the match fields defined by =
“ietf-packet-fields” or do we need to define a minimum =
supported set? 
 
[TR] I don’t see the need to support all the match =
fields, define a minimum supported set (don’t see the use for =
acl-eth-header-fields for DOTS use cases). =
 
[Med] =
Agree that acl-eth-header-fields aren’t required. The text is =
already clear about this:
 
DOTS implementations MUST support the =
following
   matching criteria: match =
based on the IP header (IPv4 and IPv6),
   match based on the transport =
header (TCP, UDP, and ICMP), and any
   combination =
thereof.
 
The question is whether we =
need to go further and mandate (or not) the support of matching based on =
specific fields: dscp, ecn, ttl,… flow-label, … tcp sequence-number, =
tcp flags, …  
 
[TR2] https://tools.ietf.org/html/draft-ietf-netmod-acl-model-16 uses the feature statements in the =
YANG model allowing vendors to advertise match rules they are capable =
and willing to support but not at the field-level. The problem is router =
implementations today don’t support ACLs with tcp sequence-number, =
acknowledgement-number, window-size etc but support TCP flags. If the =
server could convey the list of match criteria supported, it not only =
allows the client to convey the supported match rules but also allows =
the server in future to advertise the new supported match fields. =
  
 
Would =
it be useful for a client to retrieve the list of match criteria =
supported by a DOTS server? 
 
[TR2] Yes. 
 
-Tiru
 
[TR] The YANG model supported by =
the DOTS server can retrieved by the DOTS client using RESTCONF to =
determine the match criteria supported by the server. =

[Med] =
I’m afraid this is not the same functionality. If we need to allow =
a server to return its supported match criteria, this should be allowed =
by the module. For example, the module may include the following =
(example): 
 
       &=
nbsp;        +--ro =
capabilities
       &=
nbsp;        |  +--ro =
match-header*
       &=
nbsp;        |  =
|       =
identityref
       &=
nbsp;        |  +--ro =
transport-protocols* [protocol-id]
       &=
nbsp;        |  |  +--ro =
protocol-id      =
uint8
       &=
nbsp;        |  |  +--ro =
protocol-name?   string
       &=
nbsp;        |  +--ro =
dscp-support? =
      boolean
<=
span lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Courier =
New";mso-fareast-language:FR'>       &=
nbsp;        |  +--ro =
ecn-support? =
       boolean
=

       &=
nbsp;        |  +--ro =
length-support? =
    boolean
       &=
nbsp;        |  +--ro =
ttl-support? =
       boolean
=

       &=
nbsp;        |  +--ro =
protocol-support?   boolean
 
The client can ask the server to return =
its supported match criteria. The server =
will indicate the exact set of fields it supports. =

 
<=
pre>I’m not expressing a =
preference to have this in the model, but I’m clarifying how it =
would look like. 
 
-Tiru
 
Please comment. =

 
Cheers,
Med
------=_NextPart_000_0053_01D3AA30.16A5C0B0-- From nobody Tue Feb 20 02:15:48 2018 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 011F9124217 for ; Tue, 20 Feb 2018 02:15:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.628 X-Spam-Level: X-Spam-Status: No, score=-2.628 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXgT31kRcVRz for ; Tue, 20 Feb 2018 02:15:45 -0800 (PST) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60EA71200E5 for ; Tue, 20 Feb 2018 02:15:44 -0800 (PST) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 9E3551817D4; Tue, 20 Feb 2018 11:15:42 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.19]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 727CA1A0074; Tue, 20 Feb 2018 11:15:42 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM44.corporate.adroot.infra.ftgroup ([fe80::b08d:5b75:e92c:a45f%18]) with mapi id 14.03.0382.000; Tue, 20 Feb 2018 11:15:42 +0100 From: To: Jon Shallow , "Konda, Tirumaleswar Reddy" , "dots@ietf.org" Thread-Topic: [Dots] draft-ietf-dots-data-channel: Filtering Fields Thread-Index: AdOlbICGgF2MxoHnQied7J+cvW2QAAMZabEuApwt0GoCITdLGgK2/q2yAt/zojQB0mpcSAMW+5mCAaQFvl8BTSXY9AGHUoOGAhdF0YOgu5g6sKF5Q5xg Date: Tue, 20 Feb 2018 10:15:41 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0D501D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300A0D1F93@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0D32AE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00e801d3a721$08806d30$19814790$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0D366E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019201d3a72a$1b103b70$5130b250$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0D372A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0D3847@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <020a01d3a739$9fd9ec70$df8dc550$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0D3914@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <005201d3aa30$16a17af0$43e470d0$@jpshallow.com> In-Reply-To: <005201d3aa30$16a17af0$43e470d0$@jpshallow.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A0D501DOPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields 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: Tue, 20 Feb 2018 10:15:47 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A0D501DOPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mardi 20 f=E9vrier 2018 10:49 =C0 : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; dots@ietf.org Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields Hi Med, If we go with the capabilities model, instead of just defining the subset t= hat is supported in the filter fields in the Yang model, the below suggesti= on adds in a lot of bloat into the packets as well as extra code in the DOT= S server (which could be in a constrained environment -e.g. in https://tool= s.ietf.org/html/draft-ietf-dots-use-cases-09#section-3.2.1). [Med] Those may not implement the capability part of the module and then wi= ll likely to encounter errors when asking for a match/action capability not= supported by the server. For example, all 256 different IP protocols will have to be defined under t= ransport-protocols [Med] Actually, no. A number will be included in the capabilities only if t= ransport-specific filtering is supported. For example, DCCP will be include= d if filtering based on DCCP fields is supported. So, this is likely to be = at maximum tcp/udp/icmp. , along with their protocol names [Med] Name is optional. It can be removed. if all of them are to be supported (yes, I know 0 and 255 sometimes have sp= ecial meanings!). Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 16 February 2018 15:55 To: Jon Shallow; Konda, Tirumaleswar Reddy; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields Re-, I went in my local copy with the "uses packet-fields:acl-xxx" for managing = filters, but added a new container to list the capabilities to our module. = Below an excerpt of the (draft) tree structure: +--ro capabilities +--ro address-family* enumeration +--ro supported-actions* identityref +--ro fragment-support* enumeration +--ro transport-protocols* [protocol-id] | +--ro protocol-id uint8 | +--ro protocol-name? string +--ro ip-header-fields +--ro dscp-support? boolean +--ro ecn-support? boolean +--ro v4-length-support? boolean +--ro v6-length-support? boolean +--ro v4-ttl-support? boolean +--ro v6-hoplimit-support? boolean +--ro v4-ihl? boolean +--ro v4-flags? boolean +--ro v4-offset? boolean +--ro v4-identification? boolean +--ro v6-flowlabel? boolean +--ro destination-prefix? boolean +--ro source-prefix? boolean ... Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 16 f=E9vrier 2018 16:20 =C0 : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; dots@ietf.org Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields Hi Med, I agree with the list (and am likely to only implement those!). As I see it, there are 2 possible ways forward here 1) We add in an Boolean 'supported' capability for the list of all the= other options in packet-fields:acl-xxx 2) We drop the use of "uses packet-fields:acl-xxx" and define our own = required entries, exactly modelled on draft-ietf-netmod-acl-model-16 defini= tions. Comments? Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 16 February 2018 14:34 To: Konda, Tirumaleswar Reddy; Jon Shallow; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields Re-, Here is a tentative list: Header Mandatory Fields ------ -------------------------------------------------------------- IPv4 protocol, source-port-range-or-operator, destination-port- range-or-operator, destination-ipv4-network, source- ipv4-network, and v4-fragments IPv6 protocol, source-port-range-or-operator, destination-port- range-or-operator, destination-ipv4-network, source- ipv4-network,and v6-fragments TCP flags ICMP type and code Please comment/update. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 16 f=E9vrier 2018 14:55 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields +1. In TCP, only "flags" field looks mandatory. -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 7:03 PM To: Jon Shallow >; Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields Re-, I tend to agree with you to have to define a minimum set of mandatory match= fields. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 16 f=E9vrier 2018 14:29 =C0 : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; dots@ietf.org Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields Hi Med, See inline [Jon] Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 16 February 2018 12:56 To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields Jon, Thank you for sharing your thoughts. Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 16 f=E9vrier 2018 13:24 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org= Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields I like the concept of "+--ro capabilities" allowing for future support as t= he DOS server becomes more mature in its capabilities. If a DOTS client includes a filtering field parameter that is not currently= supported, should the parameter be ignored (and not returned for a GET), o= r the request rejected? [Med] I would vote for rejecting the request. The client should only use ma= tch criteria that are understood by the server; otherwise there will be dif= ferent expectation from the service. [Jon] I think that this is my preference - I was just seeking clarity of th= inking. It is conceivable that a DOTS client has 2 DOTS servers (one possibly a bac= kup, or 2 different ISPs), which may have differing filtering field paramet= er support capabilities. [Med] The backup/case seems odd. I would expect a feature parity for a redu= ndancy group used to provide the same service. [Jon] Agreed that a backup server is most likely to be from the same manufa= cturer and hence support the same functionality. But one may have just bee= n upgraded to have extra support. Adding in intelligence code to work out what is / is not allowed may not = be practical in a (memory or cpu) constrained environment of the DOTS clien= t. [Med] Fair. That said, I think we need to define the minimum set of supported parameter= s - e.g. protocol, source / dest ports, source / dest IPv4 prefixes, sourc= e / dest IPv6 prefixes, fragments and icmp type/code. [Jon] Any comments? -Jon Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 16 February 2018 10:18 To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields Hi Med, Please see inline [TR2] From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, February 16, 2018 1:45 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: draft-ietf-dots-data-channel: Filtering Fields Re-, Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 16 f=E9vrier 2018 08:00 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Wednesday, February 14, 2018 1:49 PM To: dots@ietf.org Subject: [Dots] draft-ietf-dots-data-channel: Filtering Fields Hi all, As agreed during the interim, there are some issues that need fixes in the = data-channel spec. We would like to hear from the WG to know what to record= in the document. Issue description: Should we support all of the match fields defined by "ie= tf-packet-fields" or do we need to define a minimum supported set? [TR] I don't see the need to support all the match fields, define a minimum= supported set (don't see the use for acl-eth-header-fields for DOTS use ca= ses). [Med] Agree that acl-eth-header-fields aren't required. The text is already= clear about this: DOTS implementations MUST support the following matching criteria: match based on the IP header (IPv4 and IPv6), match based on the transport header (TCP, UDP, and ICMP), and any combination thereof. The question is whether we need to go further and mandate (or not) the supp= ort of matching based on specific fields: dscp, ecn, ttl,... flow-label, ..= . tcp sequence-number, tcp flags, ... [TR2] https://tools.ietf.org/html/draft-ietf-netmod-acl-model-16 uses the f= eature statements in the YANG model allowing vendors to advertise match rul= es they are capable and willing to support but not at the field-level. The = problem is router implementations today don't support ACLs with tcp sequenc= e-number, acknowledgement-number, window-size etc but support TCP flags. If= the server could convey the list of match criteria supported, it not only = allows the client to convey the supported match rules but also allows the s= erver in future to advertise the new supported match fields. Would it be useful for a client to retrieve the list of match criteria supp= orted by a DOTS server? [TR2] Yes. -Tiru [TR] The YANG model supported by the DOTS server can retrieved by the DOTS = client using RESTCONF to determine the match criteria supported by the serv= er. [Med] I'm afraid this is not the same functionality. If we need to allow a = server to return its supported match criteria, this should be allowed by th= e module. For example, the module may include the following (example): +--ro capabilities | +--ro match-header* | | identityref | +--ro transport-protocols* [protocol-id] | | +--ro protocol-id uint8 | | +--ro protocol-name? string | +--ro dscp-support? boolean | +--ro ecn-support? boolean | +--ro length-support? boolean | +--ro ttl-support? boolean | +--ro protocol-support? boolean The client can ask the server to return its supported match criteria. The s= erver will indicate the exact set of fields it supports. I'm not expressing a preference to have this in the model, but I'm clarifyi= ng how it would look like. -Tiru Please comment. Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300A0D501DOPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf= @jpshallow.com]
Envoy=E9 : mardi 20 f=E9vrier 2018 10:49
=C0 : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; dot= s@ietf.org
Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fiel= ds

 

Hi Med,=

&n= bsp;

If we g= o with the capabilities model, instead of just defining the subset that is = supported in the filter fields in the Yang model, the below suggestion adds= in a lot of bloat into the packets as well as extra code in the DOTS server (which could be in a constrained env= ironment –e.g. in https://tools.ietf.org/html/draft-ietf-dots-use-cases-09#section-3.2.1)= .

 

[Med= ] Those may not implement the capability part of the module and then will l= ikely to encounter errors when asking for a match/action capability not supported by the server.

 

For example, all 256 different IP protocols will have to be defined u= nder transport-protocols

[Med= ] Actually, no. A number will be included in the capabilities only if trans= port-specific filtering is supported. For example, DCCP will be included if filtering based on DCCP fields is supported. So, = this is likely to be at maximum tcp/udp/icmp.

 

, along with their protocol names

[Med= ] Name is optional. It can be removed.

 

if all of them are to be supported (yes, I know 0 and 255 sometimes h= ave special meanings!).

 

Regards

 

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 16 February 2018 15:55
To: Jon Shallow; Konda, Tirumaleswar Reddy; dots@ietf.org
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields

 

Re-,

 

I went in my local copy with th= e “uses packet-fields:acl-xxx” for managing filters, but added = a new container to list the capabilities to our module. Below an excerpt of the (draft) tree structure:

 

    = +--ro capabilities

    =    +--ro address-family*     &n= bsp;  enumeration

   &= nbsp;   +--ro supported-actions*     iden= tityref

   &= nbsp;   +--ro fragment-support*     = enumeration

   &= nbsp;   +--ro transport-protocols* [protocol-id]

   &= nbsp;   |  +--ro protocol-id    &nbs= p; uint8

   &= nbsp;   |  +--ro protocol-name?   string<= /o:p>

   &= nbsp;   +--ro ip-header-fields

   &= nbsp;      +--ro dscp-support?  &nbs= p;       boolean

   &= nbsp;      +--ro ecn-support?   = ;        boolean

   &= nbsp;      +--ro v4-length-support?  = ;   boolean

   &= nbsp;      +--ro v6-length-support?  = ;   boolean

   &= nbsp;      +--ro v4-ttl-support?  &n= bsp;     boolean

   &= nbsp;      +--ro v6-hoplimit-support? &nb= sp; boolean

   &= nbsp;      +--ro v4-ihl?   &nbs= p;            boolea= n

   &= nbsp;      +--ro v4-flags?   &n= bsp;          boolean

   &= nbsp;      +--ro v4-offset?   &= nbsp;         boolean

   &= nbsp;      +--ro v4-identification?  = ;   boolean

   &= nbsp;     +--ro v6-flowlabel?   = ;       boolean

   &= nbsp;      +--ro destination-prefix? &nbs= p;  boolean

   &= nbsp;      +--ro source-prefix?  &nb= sp;      boolean

     &= nbsp;       …

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : vendredi 16 f=E9vrier 2018 16:20
=C0 : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; dots@ietf.org
Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fiel= ds

 

Hi Med,=

&n= bsp;

I agree= with the list (and am likely to only implement those!).<= /p>

&n= bsp;

As I se= e it, there are 2 possible ways forward here

&n= bsp;

= 1)      We add in an Boolean ‘supported’ capability for the list of al= l the other options in packet-fields:acl-xxx

= 2)      We drop the use of “uses packet-fields:acl-xxx” and define our= own required entries, exactly modelled on draft-ietf-netmod-acl-model-16 d= efinitions.

&n= bsp;

Comment= s?

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 16 February 2018 14:34
To: Konda, Tirumaleswar Reddy; Jon Shallow; dots@ietf.org
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields

 

Re-,

 

Here is a tentative list:

 

   Header= Mandatory Fields

   ------= --------------------------------------------------------------<= /span>

   IPv4&n= bsp;  protocol, source-port-range-or-operator, destination-port-<= /o:p>

   &= nbsp;      range-or-operator, destination-ipv4-net= work, source-

   &= nbsp;      ipv4-network, and v4-fragments

   IPv6&n= bsp;  protocol, source-port-range-or-operator, destination-port-<= /o:p>

   &= nbsp;      range-or-operator, destination-ipv4-net= work, source-

   &= nbsp;      ipv4-network,and v6-fragments

   TCP&nb= sp;   flags

   ICMP   type and code

 

Please comment/update.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : vendredi 16 f=E9vrier 2018 14:55
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fiel= ds

 

+1. In TCP, only “flags” field looks mandatory.

 

-Tiru

 

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Friday, February 16, 2018 7:03 PM
To: Jon Shallow <sup= jps-ietf@jpshallow.com>; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org
Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields

 

Re-,

 

I tend to agree with you to hav= e to define a minimum set of mandatory match fields.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : vendredi 16 f=E9vrier 2018 14:29
=C0 : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; dots@ietf.org
Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fiel= ds

 

Hi Med,=

&n= bsp;

See inl= ine [Jon]

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 16 February 2018 12:56
To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields

 

Jon,

 

Thank you for sharing your thou= ghts.

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : vendredi 16 f=E9vrier 2018 13:24
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; <= a href=3D"mailto:dots@ietf.org"> dots@ietf.org
Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fiel= ds

 

I like the concept of “+--ro capabilities“ allowing for futu=
re support as the DOS server becomes more mature in its capabilities.<=
/o:p>
 
If a DOTS client includes a filtering field parameter that =
is not currently supported, should the parameter be ignored (and not return=
ed for a GET), or the request rejected?
[Med] I would vote for re=
jecting the request. The client should only use match criteria that are und=
erstood by the server; otherwise there will be different expectation from t=
he service. 
[Jon] I think that this is my preference – I was just=
 seeking clarity of thinking.
<=
o:p> 
It is conceivable that a DOTS client has 2 DOTS servers (on=
e possibly a backup, or 2 different ISPs), which may have differing filteri=
ng field parameter support capabilities.
[Med] The backup/case see=
ms odd. I would expect a feature parity for a redundancy group used to prov=
ide the same service.=

[=
Jon] Agreed that a backup server is most likely to be from the same manufac=
turer and hence support the same functionality.  But one may have just=
 been upgraded to have extra support.
<=
o:p> 
 <=
/pre>

 <=
/pre>

  Adding in intelligence code to work out what is / is=
 not allowed may not be practical in a (memory or cpu) constrained environm=
ent of the DOTS client.


[Med] Fair. 


 


That said, I think we need to define the minimum set of sup=
ported parameters – e.g. protocol, source / dest ports,  source =
/ dest IPv4 prefixes, source / dest IPv6 prefixes, fragments and icmp type/=
code. 


[Jon] Any comments?


<=
o:p> 


-=
Jon


<=
o:p> 


Regards


 


Jon


&n=
bsp;






From:=
 Dots [mailto:
dots-bounces@ietf.org] On B=
ehalf Of
Konda, Tirumaleswar Reddy

Sent: 16 February 2018 10:18

To: mohamed.boucadai=
r@orange.com;
dots@ietf.org

Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields






 


Hi Med,


 


Please see inline [TR2]


 








From:
mohamed.boucadair@orange.co=
m [mailto:mohamed.bouca=
dair@orange.com]


Sent: Friday, February 16, 2018 1:45 PM

To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>;
dots@ietf.org

Subject: RE: draft-ietf-dots-data-channel: Filtering Fields






 


Re-,


 


Please see inline.



 


Cheers,


Med


 








De : Dots [mailto:dots-bounces@ietf.org]
De la part de Konda, Tirumaleswar Reddy

Envoy=E9 : vendredi 16 f=E9vrier 2018 08:00

=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org

Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fiel=
ds






 


From: Dots [mailto:dots-bounces=
@ietf.org]
On Behalf Of mohamed=
.boucadair@orange.com

Sent: Wednesday, February 14, 2018 1:49 PM

To: dots@ietf.org

Subject: [Dots] draft-ietf-dots-data-channel: Filtering Fields<=
/o:p>


 


Hi all,



 


As agreed during the interim, there are som=
e issues that need fixes in the data-channel spec. We would like to hear fr=
om the WG to know what to record in the document.



 


Issue description: Should we support all of=
 the match fields defined by “ietf-packet-fields” or do we need=
 to define a minimum supported set?



 


[TR] I don’t see the need=
 to support all the match fields, define a minimum supported set (don’=
;t see the use for acl-eth-header-fields for DOTS use cases).  


[Med] Agree that acl-eth-header=
-fields aren’t required. The text is already clear about this:


 


DOTS implementation=
s MUST support the following


   matchi=
ng criteria: match based on the IP header (IPv4 and IPv6),


   match =
based on the transport header (TCP, UDP, and ICMP), and any


  
combination thereof.


 


The question is whether w=
e need to go further and mandate (or not) the support of matching based on =
specific fields: dscp, ecn, ttl,… flow-label, … tcp sequence-number, tcp flags, …  


 


[TR2] https=
://tools.ietf.org/html/draft-ietf-netmod-acl-model-16 uses the feature statem=
ents in the YANG model allowing vendors to advertise match rules they are c=
apable and willing to support but not at the field-level. The problem is ro=
uter implementations today don’t support ACLs with tcp sequence-numbe=
r, acknowledgement-number, window-size etc but support TCP flags. If the se=
rver could convey the list of match criteria supported, it not only allows =
the client to convey the supported match rules but also allows the server i=
n future to advertise the new supported match fields.   


 


Would it be useful for a client to retrieve=
 the list of match criteria supported by a DOTS server?



 


[TR2] Yes. 

 


-Tiru


 


[TR] The YANG model supported b=
y the DOTS server can retrieved by the DOTS client using RESTCONF to determ=
ine the match criteria supported by the server.



[Med] I’m afraid this is =
not the same functionality. If we need to allow a server to return its supp=
orted match criteria, this should be allowed by the module.
 For example, the module may include the following (example): 


 


      &=
nbsp;         +--ro capabilitie=
s


      &=
nbsp;         |  +--ro mat=
ch-header*


      &=
nbsp;         |  |  =
     identityref


      &=
nbsp;         |  +--ro tra=
nsport-protocols* [protocol-id]


      &=
nbsp;         |  |  +=
--ro protocol-id      uint8

      &=
nbsp;         |  |  +=
--ro protocol-name?   string


      &=
nbsp;         |  +--ro dsc=
p-support?       boolean

      &=
nbsp;         |  +--ro ecn=
-support?        boolean


      &=
nbsp;         |  +--ro len=
gth-support?     boolean


      &=
nbsp;         |  +--ro ttl=
-support?        boolean


      &=
nbsp;         |  +--ro pro=
tocol-support?   boolean


 


The client can ask the server to retu=
rn its supported match criteria. The server wil=
l indicate the exact set of fields it supports. 

 <=
/pre>

I’m not expressing =
a preference to have this in the model, but I’m clarifying how it wou=
ld look like. 

 


-Tiru


 


Please com=
ment.



 =
;


Cheers,


Med=
<=
/o:p>
--_000_787AE7BB302AE849A7480A190F8B93300A0D501DOPEXCLILMA3corp_-- From nobody Tue Feb 20 03:07:22 2018 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 29C9D12711D for ; Tue, 20 Feb 2018 03:07:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 gT9hKQDqltsr for ; Tue, 20 Feb 2018 03:07:19 -0800 (PST) Received: from mx0a-00196b01.pphosted.com (mx0b-00196b01.pphosted.com [67.231.157.166]) (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 575BF1200FC for ; Tue, 20 Feb 2018 03:07:19 -0800 (PST) Received: from pps.filterd (m0072399.ppops.net [127.0.0.1]) by mx0b-00196b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1KB2JGo025556; Tue, 20 Feb 2018 06:07:17 -0500 Received: from nam02-bl2-obe.outbound.protection.outlook.com (mail-bl2nam02lp0079.outbound.protection.outlook.com [207.46.163.79]) by mx0b-00196b01.pphosted.com with ESMTP id 2g7v1jsrjp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 20 Feb 2018 06:07:17 -0500 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=4PXleJZmq/6v5yd83UVRmVDb9YqtpV2onq8FY7UED/8=; b=EUdv6a03xjGah5NEDYXhg14XyLAo/bKnkvIkkV7TmRm1BOeNj9wIpIxkIKtS7VyHUPePAfsI+hKpZS6F4PYN8CS55CGtO8kB0Au5fMh5GRL3jhtt6Z9460HEutodh1X3IdLaYBFStpQA4HbNTNdrPh9GkJOcLzlbmJiW1YhnuTs= Received: from DM2PR0101MB1039.prod.exchangelabs.com (10.160.129.156) by DM2PR0101MB1023.prod.exchangelabs.com (10.160.129.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.18; Tue, 20 Feb 2018 11:07:15 +0000 Received: from DM2PR0101MB1039.prod.exchangelabs.com ([fe80::c947:7845:18b7:77b4]) by DM2PR0101MB1039.prod.exchangelabs.com ([fe80::c947:7845:18b7:77b4%14]) with mapi id 15.20.0506.023; Tue, 20 Feb 2018 11:07:14 +0000 From: "Dobbins, Roland" To: "Konda, Tirumaleswar Reddy" CC: "mohamed.boucadair@orange.com" , Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Call home in the signal channel (was RE: draft-ietf-dots-data-channel: Filter Direction) Thread-Index: AdOnD40ix0FBs+3eR3Kr9ibwuvod3gABX+FgAAI+QYAAAnp+gAAA8WaAAAFXeQAAAn2fgABZ7WaAACWSQQAABbjJAAAEIts4AAHa7IAADRJaCQAjRhsAAARskXw= Date: Tue, 20 Feb 2018 11:07:14 +0000 Message-ID: <227096C3-2906-4013-BAB2-821782E55249@arbor.net> References: <787AE7BB302AE849A7480A190F8B93300A0D3439@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00d201d3a71e$05ead590$11c080b0$@jpshallow.com> <01b401d3a72b$b5a79f10$20f6dd30$@jpshallow.com> <022001d3a73b$09b1c270$1d154750$@jpshallow.com> <395E0F43-03F3-46F0-821D-50A53577E5B3@arbor.net>, <12A41D38-1E81-4677-96A1-4CFACA203026@arbor.net>, , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [184.82.224.211] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM2PR0101MB1023; 7:3cNb1KyBpYyNH8rr7XLGOOW4wwf/oHCVyqoyGQmZo5hzAvfhCZ+05GPSaUOq7xXBl2U5bTlks58rUqvw3sOS8GTDpgp9b9aIi2UWO6fchXNwB0UJVBYVf8ULeBSg59Jro1YhoZ5pnKrkCpTWY0Ucpz3kE96f3giMw4hg5gM5oJLsPHwZtoLYgiAaWUgrN6/2i3xdJkt0Ysr5BYATWlCh+ObIA8W8zYdcZ9zOe842fYBq+CNSwa1TjetnQM8YIs1y x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: f0e5f8b0-2933-4422-aa38-08d57852193a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM2PR0101MB1023; x-ms-traffictypediagnostic: DM2PR0101MB1023: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3231101)(944501161)(3002001)(93006095)(93001095)(10201501046)(6041288)(20161123564045)(20161123560045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:DM2PR0101MB1023; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0101MB1023; x-forefront-prvs: 05891FB07F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400004)(39380400002)(366004)(376002)(346002)(396003)(199004)(189003)(229853002)(2950100002)(6916009)(8936002)(54906003)(316002)(558084003)(81166006)(14454004)(81156014)(478600001)(106356001)(3846002)(6116002)(76176011)(83716003)(82746002)(3280700002)(54896002)(6512007)(236005)(2906002)(6246003)(6436002)(26005)(186003)(53936002)(102836004)(25786009)(5660300001)(99286004)(8676002)(93886005)(6506007)(6486002)(33656002)(86362001)(2900100001)(4326008)(105586002)(3660700001)(68736007)(53546011)(36756003)(7736002)(97736004)(66066001)(5250100002)(21314002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1023; H:DM2PR0101MB1039.prod.exchangelabs.com; 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-antispam-message-info: dpAZqTpA0vzDgB6HIGQ8xYAmLFJAr0+RmSKMy70gvEe2cpa1w1m+iEphaeOxaSIZENBXuJJyov2RakYsWAPHgb6hxEb8k0b07X/BPAxPIqALAWEa4Vw0EyL/5d/7Am4x4bOgwn4KN96d+czzmjPRpC3nDt7zC8ylrxetcn4oFVk= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_227096C329064013BAB2821782E55249arbornet_" MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-Network-Message-Id: f0e5f8b0-2933-4422-aa38-08d57852193a X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Feb 2018 11:07:14.7313 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1023 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-20_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=986 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802200142 Archived-At: Subject: Re: [Dots] Call home in the signal channel (was RE: draft-ietf-dots-data-channel: Filter Direction) 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: Tue, 20 Feb 2018 11:07:21 -0000 --_000_227096C329064013BAB2821782E55249arbornet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCk9uIEZlYiAyMCwgMjAxOCwgYXQgMTY6MDEsIEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkg PFRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb208bWFpbHRvOlRpcnVtYWxlc3dhclJl ZGR5X0tvbmRhQE1jQWZlZS5jb20+PiB3cm90ZToNCg0Kb25seSBjb252ZXlzIHRoZSBhdHRhY2sg dGFyZ2V0cw0KDQpTdXJlLCBzbyB0aGUgbWVzc2FnZSBpcywgIkJsb2NrIG91dGJvdW5kIHRyYWZm aWMgdG8geHh4Lnh4eC54eHgueHh4Ii4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NClJvbGFuZCBEb2JiaW5zIDxyZG9iYmluc0BhcmJvci5uZXQ8bWFpbHRvOnJkb2JiaW5z QGFyYm9yLm5ldD4+DQo= --_000_227096C329064013BAB2821782E55249arbornet_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KT24gRmViIDIwLCAyMDE4 LCBhdCAxNjowMSwgS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSAmbHQ7PGEgaHJlZj0ibWFpbHRv OlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20iPlRpcnVtYWxlc3dhclJlZGR5X0tv bmRhQE1jQWZlZS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiPg0KPGRpdj5vbmx5IGNvbnZleXMgdGhlIGF0dGFjayB0YXJnZXRzPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8YnI+DQo8ZGl2PlN1cmUsIHNvIHRoZSBtZXNzYWdlIGlzLCAm cXVvdDtCbG9jayBvdXRib3VuZCB0cmFmZmljIHRvIHh4eC54eHgueHh4Lnh4eCZxdW90Oy48L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9y OiByZ2JhKDI1NSwgMjU1LCAyNTUsIDApOyI+PHNwYW4gc3R5bGU9ImZvbnQtdmFyaWFudC1saWdh dHVyZXM6IG5vcm1hbDsgZm9udC12YXJpYW50LWVhc3QtYXNpYW46IG5vcm1hbDsgZm9udC12YXJp YW50LXBvc2l0aW9uOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7Ij4tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtdmFyaWFudC1saWdh dHVyZXM6IG5vcm1hbDsgZm9udC12YXJpYW50LWVhc3QtYXNpYW46IG5vcm1hbDsgZm9udC12YXJp YW50LXBvc2l0aW9uOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7Ij4NCjxzcGFuIHN0eWxl PSJmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IGZvbnQtdmFyaWFudC1lYXN0LWFzaWFu OiBub3JtYWw7IGZvbnQtdmFyaWFudC1wb3NpdGlvbjogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9y bWFsOyI+Um9sYW5kIERvYmJpbnMgJmx0OzxhIGhyZWY9Im1haWx0bzpyZG9iYmluc0BhcmJvci5u ZXQiIHgtYXBwbGUtZGF0YS1kZXRlY3RvcnM9InRydWUiIHgtYXBwbGUtZGF0YS1kZXRlY3RvcnMt dHlwZT0ibGluayIgeC1hcHBsZS1kYXRhLWRldGVjdG9ycy1yZXN1bHQ9IjIiPnJkb2JiaW5zQGFy Ym9yLm5ldDwvYT4mZ3Q7PC9zcGFuPjwvc3Bhbj48L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_227096C329064013BAB2821782E55249arbornet_-- From nobody Tue Feb 20 04:20:27 2018 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 26B0A12706D for ; Tue, 20 Feb 2018 04:20:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.329 X-Spam-Level: X-Spam-Status: No, score=-4.329 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 Ngxm_SWawcsg for ; Tue, 20 Feb 2018 04:20:24 -0800 (PST) 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 5A31C124D6C for ; Tue, 20 Feb 2018 04:20:24 -0800 (PST) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1519129214; h=From: To:CC:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:x-originating-ip: x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: authentication-results:x-microsoft-antispam-prvs: x-exchange-antispam-report-test:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=q TAncAoniDN6BUSrqOFWjEQJahP+Hu2B2WvnCntKtG I=; b=XcCdWFAj80qbw8NYdWULSeetUj7cnVBHWaHGTWtXin98 4jXtYaoWt62TkvH9PN4O5bYTpR0//0FuImlF/ldXVSG8OSnD+l StHMBRyquW2DhEnXuS2bhZu0rq63QFjHKovZAfPWeYZ/F0EeMv hnFvbzWxlgT1msHNF0H1PQuEJzU= Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 5d2f_8d28_e29ae11d_cf06_41cf_8e08_20bc04f5d185; Tue, 20 Feb 2018 06:20:13 -0600 Received: from DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 20 Feb 2018 05:19:16 -0700 Received: from DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) by DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 20 Feb 2018 05:19:15 -0700 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Tue, 20 Feb 2018 05:19:15 -0700 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (10.44.176.241) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 20 Feb 2018 05:19:14 -0700 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1529.namprd16.prod.outlook.com (10.173.212.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.18; Tue, 20 Feb 2018 12:19: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.20.0506.023; Tue, 20 Feb 2018 12:19:14 +0000 From: "Konda, Tirumaleswar Reddy" To: "Dobbins, Roland" CC: "mohamed.boucadair@orange.com" , Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Call home in the signal channel (was RE: draft-ietf-dots-data-channel: Filter Direction) Thread-Index: AQHTpx4fYQaVBSxJJEC02ounCseemaOm/iRwgAALCoCAAARH0IAAGmGAgALNmfCAALkMAIAAn1iggAAk3gCAAA2EcIAAaeYAgAEX3rCAACW3AIAAEpHA Date: Tue, 20 Feb 2018 12:19:14 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A0D3439@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00d201d3a71e$05ead590$11c080b0$@jpshallow.com> <01b401d3a72b$b5a79f10$20f6dd30$@jpshallow.com> <022001d3a73b$09b1c270$1d154750$@jpshallow.com> <395E0F43-03F3-46F0-821D-50A53577E5B3@arbor.net>, <12A41D38-1E81-4677-96A1-4CFACA203026@arbor.net>, , <227096C3-2906-4013-BAB2-821782E55249@arbor.net> In-Reply-To: <227096C3-2906-4013-BAB2-821782E55249@arbor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1529; 7:1afKj4JxyAFOS/lMTuJrjgA2oAx77KjaEUfzzNrpoGSI3MuBX/nHrmcszQbU9717BBFsMWbAlvAYn9GUoUg2YIi39IFiSay04mErjxo+8Ivp5JEYKDTSp+hPO+xZQjMogbRViwH4bzuho20nApWBQ1ZOKBqT2x83IHN+pDs9UhzUc41LQJ262QFETG8b7aXfctf2SCH+XuA2aXm4xDMlyi8sTT5M3/IbaL2MPJtN9BegcRNIr86FEaoYRsFiBFLn x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 036eedcf-1161-4e27-5bc6-08d5785c27c2 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:DM5PR16MB1529; x-ms-traffictypediagnostic: DM5PR16MB1529: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(18271650672692)(21748063052155)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001056)(6040501)(2401047)(8121501046)(5005006)(3231101)(944501161)(93006095)(93001095)(10201501046)(3002001)(6041288)(20161123560045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:DM5PR16MB1529; BCL:0; PCL:0; RULEID:; SRVR:DM5PR16MB1529; x-forefront-prvs: 05891FB07F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39830400003)(346002)(376002)(39380400002)(396003)(366004)(189003)(199004)(32952001)(478600001)(72206003)(6506007)(105586002)(25786009)(68736007)(33656002)(5660300001)(66066001)(97736004)(3660700001)(80792005)(74316002)(229853002)(4326008)(7736002)(106356001)(19609705001)(236005)(81156014)(53936002)(86362001)(81166006)(6246003)(2900100001)(316002)(3280700002)(54906003)(76176011)(2950100002)(9686003)(7696005)(26005)(54896002)(6306002)(102836004)(59450400001)(77096007)(6916009)(53546011)(2906002)(8936002)(99286004)(55016002)(186003)(93886005)(790700001)(6436002)(3846002)(6116002)(14454004)(8676002)(21314002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1529; 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) x-microsoft-antispam-message-info: 4EdICtO+Rq2fBvQbIibLjM1jDePExig+xzERHFF8VXYWuc1YzyW5KVtq8iVqOexUWEFJ7vWrWbCOB5tjaRiK4lU9q9DUwVMAa2c5RbI8uNl1KtKbsswgytLytOOPuwZLMAx/FohsCi2UBcBl1/PcWKCMHlrX4hsDk6gwqrsAdZ8= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB17883CF12891840A335BFC7BEACF0DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 036eedcf-1161-4e27-5bc6-08d5785c27c2 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Feb 2018 12:19:14.1853 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1529 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 <6225> : inlines <6411> : streams <1779524> : uri <2596158> Archived-At: Subject: Re: [Dots] Call home in the signal channel (was RE: draft-ietf-dots-data-channel: Filter Direction) 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: Tue, 20 Feb 2018 12:20:26 -0000 --_000_DM5PR16MB17883CF12891840A335BFC7BEACF0DM5PR16MB1788namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogRG9iYmlucywgUm9sYW5kIFttYWlsdG86cmRvYmJpbnNAYXJib3IubmV0XQ0KU2VudDog VHVlc2RheSwgRmVicnVhcnkgMjAsIDIwMTggNDozNyBQTQ0KVG86IEtvbmRhLCBUaXJ1bWFsZXN3 YXIgUmVkZHkgPFRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20+DQpDYzogbW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTsgSm9uIFNoYWxsb3cgPHN1cGpwcy1pZXRmQGpwc2hhbGxv dy5jb20+OyBkb3RzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0RvdHNdIENhbGwgaG9tZSBpbiB0 aGUgc2lnbmFsIGNoYW5uZWwgKHdhcyBSRTogZHJhZnQtaWV0Zi1kb3RzLWRhdGEtY2hhbm5lbDog RmlsdGVyIERpcmVjdGlvbikNCg0KDQoNCk9uIEZlYiAyMCwgMjAxOCwgYXQgMTY6MDEsIEtvbmRh LCBUaXJ1bWFsZXN3YXIgUmVkZHkgPFRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb208 bWFpbHRvOlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20+PiB3cm90ZToNCm9ubHkg Y29udmV5cyB0aGUgYXR0YWNrIHRhcmdldHMNCg0KU3VyZSwgc28gdGhlIG1lc3NhZ2UgaXMsICJC bG9jayBvdXRib3VuZCB0cmFmZmljIHRvIHh4eC54eHgueHh4Lnh4eCIuDQoNClllcywgYnV0IHRo ZSBtaXRpZ2F0aW9uIHJlcXVlc3Qgbm90IG9ubHkgYmxvY2tzIG91dGJvdW5kIHRyYWZmaWMgdG8g eHh4Lnh4eC54eHgueHh4IGZyb20gYmFkIGRldmljZXMgYnV0IGFsc28gZnJvbSBnb29kIGRldmlj ZXMuDQpJZiB0aGUgbWl0aWdhdGlvbiByZXF1ZXN0IGNvdWxkIGFsc28gY29udmV5IHRoZSBzb3Vy Y2UgSVAgYWRkcmVzc2VzLCB0aGUgQ1BFIGNhbiBpc29sYXRlIG9yIHF1YXJhbnRpbmUgdGhlIGNv bXByb21pc2VkIGRldmljZSBhbmQgb25seSBibG9jayBvdXQtYmFuZCB0cmFmZmljIG9yaWdpbmF0 aW5nIGZyb20gdGhlIGNvbXByb21pc2VkIGRldmljZXMgaW4gdGhlIGhvbWUgbmV0d29yay4NCg0K Q2hlZXJzLA0KLVRpcnUNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClJv bGFuZCBEb2JiaW5zIDxyZG9iYmluc0BhcmJvci5uZXQ8bWFpbHRvOnJkb2JiaW5zQGFyYm9yLm5l dD4+DQo= --_000_DM5PR16MB17883CF12891840A335BFC7BEACF0DM5PR16MB1788namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJ e21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCglt YXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1s ZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRv d3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+IERvYmJpbnMsIFJvbGFuZCBbbWFpbHRvOnJkb2JiaW5zQGFyYm9yLm5l dF0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBGZWJydWFyeSAyMCwgMjAxOCA0OjM3IFBN PGJyPg0KPGI+VG86PC9iPiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5ICZsdDtUaXJ1bWFsZXN3 YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gbW9oYW1lZC5ib3Vj YWRhaXJAb3JhbmdlLmNvbTsgSm9uIFNoYWxsb3cgJmx0O3N1cGpwcy1pZXRmQGpwc2hhbGxvdy5j b20mZ3Q7OyBkb3RzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbRG90c10gQ2Fs bCBob21lIGluIHRoZSBzaWduYWwgY2hhbm5lbCAod2FzIFJFOiBkcmFmdC1pZXRmLWRvdHMtZGF0 YS1jaGFubmVsOiBGaWx0ZXIgRGlyZWN0aW9uKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpPbiBGZWIgMjAs IDIwMTgsIGF0IDE2OjAxLCBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5ICZsdDs8YSBocmVmPSJt YWlsdG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbSI+VGlydW1hbGVzd2FyUmVk ZHlfS29uZGFATWNBZmVlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5vbmx5IGNvbnZleXMgdGhlIGF0dGFjayB0 YXJnZXRzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlN1cmUsIHNvIHRoZSBtZXNzYWdlIGlzLCAmcXVvdDtCbG9jayBvdXRib3VuZCB0cmFmZmlj IHRvIHh4eC54eHgueHh4Lnh4eCZxdW90Oy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5ZZXMsIGJ1dCB0aGUgbWl0aWdhdGlv biByZXF1ZXN0IG5vdCBvbmx5IGJsb2NrcyBvdXRib3VuZCB0cmFmZmljIHRvDQo8L3NwYW4+eHh4 Lnh4eC54eHgueHh4IGZyb20gYmFkIGRldmljZXMgYnV0IGFsc28gZnJvbSBnb29kIGRldmljZXMu IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5J ZiB0aGUgbWl0aWdhdGlvbiByZXF1ZXN0IGNvdWxkIGFsc28gY29udmV5IHRoZSBzb3VyY2UgSVAg YWRkcmVzc2VzLCB0aGUgQ1BFIGNhbiBpc29sYXRlIG9yIHF1YXJhbnRpbmUgdGhlIGNvbXByb21p c2VkIGRldmljZSBhbmQgb25seSBibG9jayBvdXQtYmFuZCB0cmFmZmljIG9yaWdpbmF0aW5nIGZy b20NCiB0aGUgY29tcHJvbWlzZWQgZGV2aWNlcyBpbiB0aGUgaG9tZSBuZXR3b3JrLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4tVGlydTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS08YnI+DQpSb2xhbmQgRG9iYmlucyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJkb2JiaW5z QGFyYm9yLm5ldCI+cmRvYmJpbnNAYXJib3IubmV0PC9hPiZndDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_DM5PR16MB17883CF12891840A335BFC7BEACF0DM5PR16MB1788namp_-- From nobody Tue Feb 20 05:57:24 2018 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 526FD12D7F3 for ; Tue, 20 Feb 2018 05:57:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 1mXSSW0Sieex for ; Tue, 20 Feb 2018 05:57:21 -0800 (PST) Received: from mx0a-00196b01.pphosted.com (mx0a-00196b01.pphosted.com [67.231.149.170]) (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 1B55C127010 for ; Tue, 20 Feb 2018 05:57:21 -0800 (PST) Received: from pps.filterd (m0096263.ppops.net [127.0.0.1]) by mx0a-00196b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1KDuHO8008410; Tue, 20 Feb 2018 08:57:20 -0500 Received: from nam03-dm3-obe.outbound.protection.outlook.com (mail-dm3nam03lp0021.outbound.protection.outlook.com [207.46.163.21]) by mx0a-00196b01.pphosted.com with ESMTP id 2g7v9cj4s9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 20 Feb 2018 08:57:20 -0500 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=caouAiyKVDyZvxRH+xCR+iEnUK7yUymW/N1QYldsXHU=; b=RUp4Cuc9k+6JYOz/MpR8hNJ0vN1hsCJXyhThlpiBNDhm6RXtbvYhhkIQ8esWU2gT980DHUriGUJcj7EGnWs290wFovu/wndEhPJJXSWrlSvI0ck+aHoTtDCZgGcqDRIz3ybJGIwm5CDPa5DChVlGhJhMJEjFG2KpuMzzQj0qIxo= Received: from DM2PR0101MB1039.prod.exchangelabs.com (10.160.129.156) by DM2PR0101MB1199.prod.exchangelabs.com (10.160.135.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.18; Tue, 20 Feb 2018 13:57:16 +0000 Received: from DM2PR0101MB1039.prod.exchangelabs.com ([fe80::c947:7845:18b7:77b4]) by DM2PR0101MB1039.prod.exchangelabs.com ([fe80::c947:7845:18b7:77b4%14]) with mapi id 15.20.0506.023; Tue, 20 Feb 2018 13:57:16 +0000 From: "Dobbins, Roland" To: "Konda, Tirumaleswar Reddy" CC: "mohamed.boucadair@orange.com" , Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Call home in the signal channel (was RE: draft-ietf-dots-data-channel: Filter Direction) Thread-Index: AdOnD40ix0FBs+3eR3Kr9ibwuvod3gABX+FgAAI+QYAAAnp+gAAA8WaAAAFXeQAAAn2fgABZ7WaAACWSQQAABbjJAAAEIts4AAHa7IAADRJaCQAjRhsAAARskXwAAoOnAAADbJSx Date: Tue, 20 Feb 2018 13:57:16 +0000 Message-ID: <969C51EE-9296-481A-9175-566A4104958A@arbor.net> References: <787AE7BB302AE849A7480A190F8B93300A0D3439@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00d201d3a71e$05ead590$11c080b0$@jpshallow.com> <01b401d3a72b$b5a79f10$20f6dd30$@jpshallow.com> <022001d3a73b$09b1c270$1d154750$@jpshallow.com> <395E0F43-03F3-46F0-821D-50A53577E5B3@arbor.net>, <12A41D38-1E81-4677-96A1-4CFACA203026@arbor.net>, , <227096C3-2906-4013-BAB2-821782E55249@arbor.net>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [184.82.224.211] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM2PR0101MB1199; 7:ucJ6YkIlzWGDLVHYz3M6iiYY2HTJ9ZFMiJD3T7D30TD7zuGJ98kPief5nSraEKb5ewbr39rQKkqSPlkgUgpXzEvtmsxwOTY0ipUyzLzhHvNABunkyABFJqor24fFT5ybxOUqdXpK8tWQ1jRS9L5XSVQpsTEtPiXDqKFx4s6fDe/BQAbhCTQ41/SO1IRrjnpT3Q60v8kQ06hZ+kUD5wB9tEZrU99Zw9PDLYSbAC74RS0kvwA0N+lrQ/tD9uP/TqN9 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: a88b6227-c700-4496-f915-08d57869da25 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:DM2PR0101MB1199; x-ms-traffictypediagnostic: DM2PR0101MB1199: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231101)(944501161)(6041288)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:DM2PR0101MB1199; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0101MB1199; x-forefront-prvs: 05891FB07F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(366004)(39380400002)(39850400004)(346002)(189003)(199004)(76176011)(66066001)(236005)(14454004)(5250100002)(68736007)(6512007)(54896002)(105586002)(54906003)(6916009)(3280700002)(2950100002)(26005)(6246003)(186003)(106356001)(102836004)(3660700001)(82746002)(36756003)(93886005)(8936002)(99286004)(5660300001)(83716003)(7736002)(478600001)(316002)(2900100001)(4326008)(6486002)(6436002)(229853002)(33656002)(86362001)(2906002)(6116002)(25786009)(8676002)(81166006)(6506007)(81156014)(97736004)(53546011)(53936002)(3846002)(59450400001)(21314002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1199; 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) x-microsoft-antispam-message-info: WnPMNcnfHWkOul4y2keCD9p0P7hcitcbqRPzE945ApvmZc+ilRt4svvT9/dTAnzZ1L42GamXW62HbSKbo3cMNXuMhh4oNjlsbg0ksOyZIXfsVv0eX3zNHyzDQbNSy9JrSfK9uAnyxoglYNb1t2gFJLpn3GHEZt5Qh3G+a0Giwys= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_969C51EE9296481A9175566A4104958Aarbornet_" MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-Network-Message-Id: a88b6227-c700-4496-f915-08d57869da25 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Feb 2018 13:57:16.8207 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1199 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-20_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=1 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802200178 Archived-At: Subject: Re: [Dots] Call home in the signal channel (was RE: draft-ietf-dots-data-channel: Filter Direction) 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: Tue, 20 Feb 2018 13:57:23 -0000 --_000_969C51EE9296481A9175566A4104958Aarbornet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCk9uIEZlYiAyMCwgMjAxOCwgYXQgMTk6MjAsIEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkg PFRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb208bWFpbHRvOlRpcnVtYWxlc3dhclJl ZGR5X0tvbmRhQE1jQWZlZS5jb20+PiB3cm90ZToNCg0KWWVzLCBidXQgdGhlIG1pdGlnYXRpb24g cmVxdWVzdCBub3Qgb25seSBibG9ja3Mgb3V0Ym91bmQgdHJhZmZpYyB0byB4eHgueHh4Lnh4eC54 eHggZnJvbSBiYWQgZGV2aWNlcyBidXQgYWxzbyBmcm9tIGdvb2QgZGV2aWNlcy4NCldoaWNoIGlz IG5vdCBhIGh1Z2UgY29uY2VybiwgaW4gbW9zdCBjYXNlcyBvZiB0aGlzIG5hdHVyZS4NCklmIHRo ZSBtaXRpZ2F0aW9uIHJlcXVlc3QgY291bGQgYWxzbyBjb252ZXkgdGhlIHNvdXJjZSBJUCBhZGRy ZXNzZXMsIHRoZSBDUEUgY2FuIGlzb2xhdGUgb3IgcXVhcmFudGluZSB0aGUgY29tcHJvbWlzZWQg ZGV2aWNlIGFuZCBvbmx5IGJsb2NrIG91dC1iYW5kIHRyYWZmaWMgb3JpZ2luYXRpbmcgZnJvbSB0 aGUgY29tcHJvbWlzZWQgZGV2aWNlcyBpbiB0aGUgaG9tZSBuZXR3b3JrLg0KVGhlIGNlbnRyYWxp emVkIGRldGVjdGlvbi9jbGFzc2lmaWNhdGlvbiBzeXN0ZW0gY2FuIGlzc3VlIHRoZSByZXF1ZXN0 IG9ubHkgdG8gdGhlIHJlbGV2YW50IENQRSwgYmFzZWQgb24gaXRzIGlkZW50aWZpY2F0aW9uIG9m IHRoZSByZWxldmFudCBzb3VyY2UgSVBzLg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KUm9sYW5kIERvYmJpbnMgPHJkb2JiaW5zQGFyYm9yLm5ldDxtYWlsdG86cmRvYmJp bnNAYXJib3IubmV0Pj4NCg== --_000_969C51EE9296481A9175566A4104958Aarbornet_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KT24gRmViIDIwLCAyMDE4 LCBhdCAxOToyMCwgS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSAmbHQ7PGEgaHJlZj0ibWFpbHRv OlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20iPlRpcnVtYWxlc3dhclJlZGR5X0tv bmRhQE1jQWZlZS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+WWVzLCBidXQgdGhlIG1pdGlnYXRpb24gcmVxdWVzdCBub3Qgb25seSBibG9ja3Mgb3V0 Ym91bmQgdHJhZmZpYyB0bw0KPC9zcGFuPnh4eC54eHgueHh4Lnh4eCBmcm9tIGJhZCBkZXZpY2Vz IGJ1dCBhbHNvIGZyb20gZ29vZCBkZXZpY2VzLjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K V2hpY2ggaXMgbm90IGEgaHVnZSBjb25jZXJuLCBpbiBtb3N0IGNhc2VzIG9mIHRoaXMgbmF0dXJl LiZuYnNwOzxicj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5JZiB0aGUgbWl0aWdhdGlvbiByZXF1ZXN0IGNvdWxkIGFsc28gY29udmV5IHRoZSBz b3VyY2UgSVAgYWRkcmVzc2VzLCB0aGUgQ1BFIGNhbiBpc29sYXRlIG9yIHF1YXJhbnRpbmUgdGhl IGNvbXByb21pc2VkIGRldmljZSBhbmQgb25seSBibG9jayBvdXQtYmFuZCB0cmFmZmljIG9yaWdp bmF0aW5nIGZyb20NCiB0aGUgY29tcHJvbWlzZWQgZGV2aWNlcyBpbiB0aGUgaG9tZSBuZXR3b3Jr Ljwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+VGhlIGNlbnRyYWxpemVk IGRldGVjdGlvbi9jbGFzc2lmaWNhdGlvbiBzeXN0ZW0gY2FuIGlzc3VlIHRoZSByZXF1ZXN0IG9u bHkgdG8gdGhlIHJlbGV2YW50IENQRSwgYmFzZWQgb24gaXRzIGlkZW50aWZpY2F0aW9uIG9mIHRo ZSByZWxldmFudCBzb3VyY2UgSVBzLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PHNw YW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYmEoMjU1LCAyNTUsIDI1NSwgMCk7Ij48c3Bh biBzdHlsZT0iZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsOyBmb250LXZhcmlhbnQtZWFz dC1hc2lhbjogbm9ybWFsOyBmb250LXZhcmlhbnQtcG9zaXRpb246IG5vcm1hbDsgbGluZS1oZWln aHQ6IG5vcm1hbDsiPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9zcGFuPjxi ciBzdHlsZT0iZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsOyBmb250LXZhcmlhbnQtZWFz dC1hc2lhbjogbm9ybWFsOyBmb250LXZhcmlhbnQtcG9zaXRpb246IG5vcm1hbDsgbGluZS1oZWln aHQ6IG5vcm1hbDsiPg0KPC9zcGFuPg0KPGRpdiBzdHlsZT0iZm9udC12YXJpYW50LWxpZ2F0dXJl czogbm9ybWFsOyBmb250LXZhcmlhbnQtZWFzdC1hc2lhbjogbm9ybWFsOyBmb250LXZhcmlhbnQt cG9zaXRpb246IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsiPg0KPHNwYW4gc3R5bGU9ImJh Y2tncm91bmQtY29sb3I6IHJnYmEoMjU1LCAyNTUsIDI1NSwgMCk7Ij5Sb2xhbmQgRG9iYmlucyAm bHQ7PGEgaHJlZj0ibWFpbHRvOnJkb2JiaW5zQGFyYm9yLm5ldCI+cmRvYmJpbnNAYXJib3IubmV0 PC9hPiZndDs8L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_969C51EE9296481A9175566A4104958Aarbornet_-- From nobody Mon Feb 26 10:59:06 2018 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 2D9241270FC for ; Mon, 26 Feb 2018 10:59:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMYlvSG7zHUo for ; Mon, 26 Feb 2018 10:59:03 -0800 (PST) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 F1CBB12D873 for ; Mon, 26 Feb 2018 10:59:02 -0800 (PST) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id w1QIx1UJ019983 for ; Mon, 26 Feb 2018 13:59:01 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu w1QIx1UJ019983 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1519671541; bh=M/c/g3NS3klEvtkOBwiaGnI5Nrh5aqidzEISjEYVLf4=; h=From:To:Subject:Date:From; b=rBBF0SYFUlhKNvtSCvLehzQecFL42kmkJr46PI4rL/9FzfX802wJSJ0aI8QTmej22 zTGybntz0RifcR7IepmrrYO4iqm6Qr/cf41irXGCIFkmPMoaPVwRzSliVPn2JUppe0 61AUN+00/BPa8D31hK0cQYuipbVfU5lva+vONElw= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id w1QIx0f0001909 for ; Mon, 26 Feb 2018 13:59:00 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0361.001; Mon, 26 Feb 2018 13:58:59 -0500 From: Roman Danyliw To: "dots@ietf.org" Thread-Topic: Call for agenda items for DOTS at IETF 101 Thread-Index: AdOvM4gENcP5VkgxTuSHG96YEeFbhA== Date: Mon, 26 Feb 2018 18:58:58 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC0137F69048@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Dots] Call for agenda items for DOTS at IETF 101 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, 26 Feb 2018 18:59:04 -0000 Hello! DOTS has been scheduled at IETF 101 on Tuesday (March 20) at 1550-1820. If= you would like time on the agenda, send your request to the chairs. Regards, Roman and Tobias From nobody Tue Feb 27 15:22:17 2018 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 018DA12EB88; Tue, 27 Feb 2018 15:11:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: Kathleen.Moriarty.ietf@gmail.com, dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151977308900.5200.13757237214094294793.idtracker@ietfa.amsl.com> Date: Tue, 27 Feb 2018 15:11:29 -0800 Archived-At: Subject: [Dots] dots - Requested session has been scheduled for IETF 101 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: Tue, 27 Feb 2018 23:11:29 -0000 Dear Roman Danyliw, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. dots Session 1 (2:00:00) Tuesday, Afternoon Session II 1550-1820 Room Name: Viscount size: 175 --------------------------------------------- Request Information: --------------------------------------------------------- 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 Feb 28 10:04:31 2018 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 7F72C120727 for ; Wed, 28 Feb 2018 10:04:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2PjxM9MiDhK for ; Wed, 28 Feb 2018 10:04:22 -0800 (PST) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 1F12312008A for ; Wed, 28 Feb 2018 10:04:19 -0800 (PST) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id w1SI4J88002089 for ; Wed, 28 Feb 2018 13:04:19 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu w1SI4J88002089 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1519841059; bh=/eK93qbD1OYguls44cuaBhX08+lvWw5/amkkSZn7qts=; h=From:To:Subject:Date:From; b=Qx7KhnIUAO0THUu0YCrrn4rhFjpJgVIUx9JgFiQrS1pM1GDIotxMV/rPjsl8sRG0L 4goO6JTBUmL3D1CRmOFx2HFUvOq1/ovHdJ5FkNjLhHl5uctMcw3B/BHpEB7EyE2gO/ Rgug/mBWDgph7vg9OctecQdzvLDSd7jMLYF6fraU= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id w1SI4I4g027928 for ; Wed, 28 Feb 2018 13:04:18 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0361.001; Wed, 28 Feb 2018 13:04:18 -0500 From: Roman Danyliw To: "dots@ietf.org" Thread-Topic: Draft minutes from Virtual Interim Meeting on February 7, 2018 Thread-Index: AdOwvlz4UkJtQZXkRk68GYbqYeT1sg== Date: Wed, 28 Feb 2018 18:04:17 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC0137F6B574@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Dots] Draft minutes from Virtual Interim Meeting on February 7, 2018 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, 28 Feb 2018 18:04:23 -0000 Hello! Draft meeting minutes from the DOTS virtual interim meeting held on Februar= y 7, 2018 have been posted: https://datatracker.ietf.org/meeting/interim-2018-dots-01/materials/minutes= -interim-2018-dots-01-201802071000 If you have corrections, please reach out to the chairs. Regards, Roman and Tobias