Re: [Dots] Adoption call for draft-reddy-dots-home-network-04
"Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com> Thu, 18 April 2019 12:53 UTC
Return-Path: <TirumaleswarReddy_Konda@mcafee.com>
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 98E21120316; Thu, 18 Apr 2019 05:53:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 HxLKLv-t8Ky0; Thu, 18 Apr 2019 05:53:31 -0700 (PDT)
Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81FF212030D; Thu, 18 Apr 2019 05:53:30 -0700 (PDT)
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=1555591625; 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-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-forefront-prvs:x-forefront-antispam-report: received-spf:x-ms-exchange-senderadcheck:x-microsoft-antispam-message-info: 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-CrossTenant-mailboxtype: 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=XU4OLlCJ56/R3YrCcYkKkYmji0nalMYTE0yILI WjpTk=; b=pFv/g6E6e+58Zvk5lN6A4cMRaWkykXtVglvzP/MS pTFJH1+44pzduRDPi5Kw5vG9UHrvMEEcxX1jdOBDpzfEJTvmJA 6ZEvqELMh3MKqn5CjYuDMLcu7dEtcuvOTbzbZfh3nhCl9Q2s5Q ACqaxY8SIDJ7w9Z18TfNk/DRpqrp0wY=
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 1537_6fb3_5467556c_e93c_415f_9244_542ab4236bd5; Thu, 18 Apr 2019 06:47:03 -0600
Received: from DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 18 Apr 2019 06:52:09 -0600
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.1395.4 via Frontend Transport; Thu, 18 Apr 2019 06:52:09 -0600
Received: from NAM03-BY2-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.1395.4; Thu, 18 Apr 2019 06:52:05 -0600
Received: from BYAPR16MB2790.namprd16.prod.outlook.com (20.178.233.91) by BYAPR16MB2712.namprd16.prod.outlook.com (20.178.232.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.14; Thu, 18 Apr 2019 12:52:03 +0000
Received: from BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::4873:7200:9e57:9e62]) by BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::4873:7200:9e57:9e62%5]) with mapi id 15.20.1813.011; Thu, 18 Apr 2019 12:52:03 +0000
From: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>
To: Daniel Migault <daniel.migault@ericsson.com>, "Panwei (William)" <william.panwei@huawei.com>
CC: "dots-chairs@ietf.org" <dots-chairs@ietf.org>, Valery Smyslov <valery@smyslov.net>, "dots@ietf.org" <dots@ietf.org>, "kaduk@mit.edu" <kaduk@mit.edu>
Thread-Topic: [Dots] Adoption call for draft-reddy-dots-home-network-04
Thread-Index: AdTuHVZNyfDh6IMnTiyfhZP8vM2pOAFGr25wABsxq4AAi6JHcA==
Date: Thu, 18 Apr 2019 12:52:02 +0000
Message-ID: <BYAPR16MB2790ECCDECA7EA5E62F76F0DEA260@BYAPR16MB2790.namprd16.prod.outlook.com>
References: <023d01d4ee1f$c2bcb190$483614b0$@smyslov.net> <30E95A901DB42F44BA42D69DB20DFA6A69F3A581@nkgeml513-mbx.china.huawei.com> <CADZyTkmtyO25-JiHMicZDUL2F+5RXpnFPsYHmyn67yfHTns5fA@mail.gmail.com>
In-Reply-To: <CADZyTkmtyO25-JiHMicZDUL2F+5RXpnFPsYHmyn67yfHTns5fA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.2.0.6
dlp-reaction: no-action
authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com;
x-originating-ip: [49.37.205.191]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 84b16dff-ce56-4e75-40ae-08d6c3fca7d7
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600141)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:BYAPR16MB2712;
x-ms-traffictypediagnostic: BYAPR16MB2712:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <BYAPR16MB2712057AA2650AC76E21F537EA260@BYAPR16MB2712.namprd16.prod.outlook.com>
x-forefront-prvs: 0011612A55
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(396003)(39860400002)(366004)(136003)(346002)(13464003)(51914003)(32952001)(53754006)(199004)(189003)(86362001)(66066001)(966005)(6436002)(52536014)(8676002)(316002)(97736004)(14454004)(110136005)(68736007)(9326002)(55016002)(4326008)(72206003)(71190400001)(81156014)(7696005)(256004)(81166006)(53936002)(76176011)(14444005)(8936002)(71200400001)(54906003)(74316002)(478600001)(5024004)(5660300002)(486006)(53546011)(790700001)(9686003)(6506007)(80792005)(7736002)(2906002)(102836004)(606006)(476003)(33656002)(25786009)(6306002)(54896002)(6116002)(3846002)(236005)(11346002)(26005)(186003)(99286004)(446003)(6246003)(229853002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR16MB2712; H:BYAPR16MB2790.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: v+6vDgVpNRH+1iBeb41E4+GgrP2dean7zUkN8YQWQW4BGRWNtymrvDiQJgsnLyG6oooe/w31pobFps8Qi3FcwOzwdxXc6dZNtUbKYZ67CBxg2LK4NEeyOBXUWOipVJ96fOKwLa7NMMTiAp13yGiq8c8Nk3699rkiv5sVn6q2r12ba9C7WXHunqUpwYwz5koXoHutyTY+gIWhpHVXLi1yxPa3d9lyLt9E5njYel3U9EoaHVr4sM++jLpbjAXppq7BgQZ4IgK9B6v673IzMFZ1mtyGLQr3iomAQTtydAKIF0IbYyOIeQUDuseZlj2AiXn0U5lRUG3f5Nkm6/W8V3/Dj3XSRtoddPfhRxIhuHvecmnXqvQcSW11UFuAYnco94+9d0SOIe28CI+2Lvr58taELFW4OOpjMOLw1FUoFmVGH+M=
Content-Type: multipart/alternative; boundary="_000_BYAPR16MB2790ECCDECA7EA5E62F76F0DEA260BYAPR16MB2790namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 84b16dff-ce56-4e75-40ae-08d6c3fca7d7
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2019 12:52:03.2499 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR16MB2712
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 <6528> : inlines <7057> : streams <1819017> : uri <2834125>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/90Vt_MQC_cFe3awREogzTncAR3k>
Subject: Re: [Dots] Adoption call for draft-reddy-dots-home-network-04
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <dots.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dots>, <mailto:dots-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dots/>
List-Post: <mailto:dots@ietf.org>
List-Help: <mailto:dots-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dots>, <mailto:dots-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Apr 2019 12:53:35 -0000
Hi Daniel, Thanks for the review, Please see inline [TR] From: Dots <dots-bounces@ietf.org> On Behalf Of Daniel Migault Sent: Monday, April 15, 2019 9:34 PM To: Panwei (William) <william.panwei@huawei.com> Cc: dots-chairs@ietf.org; Valery Smyslov <valery@smyslov.net>; dots@ietf.org; kaduk@mit.edu Subject: Re: [Dots] Adoption call for draft-reddy-dots-home-network-04 CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe. ________________________________ I support the adoption of the draft, please see my comments on the current version. None of them should be considered as preventing the adoption. Yours, Daniel Some random comments: Section 1: """ Some of the DDoS attacks like spoofed RST or FIN packets, Slowloris, and TLS re-negotiation are difficult to detect on the home network devices without adversely affecting its performance. The reason is typically home routers have fast path to boost the throughput. For every new TCP/UDP flow, only the first few packets are punted through the slow path. Hence, it is not possible to detect various DDoS attacks in the slow path, since the attack payload is sent to the target server after the flow is switched to fast path. Deep packet inspection (DPI) of all the packets of a flow would be able to detect some of the attacks. However, a full-fledged DPI to detect these type of DDoS attacks is functionally or operationally not possible for all the devices attached to the home network owing to the memory and CPU limitations of the home routers. Further, for certain DDoS attacks the ability to distinguish legitimate traffic from attacker traffic on a per packet basis is complex. This complexity originates from the fact that the packet itself may look "legitimate" and no attack signature can be identified. The anomaly can be identified only after detailed statistical analysis. """ I understand, the paragraph below as saying that detection at the ISP is easier than at the homenet level as the ISP aggregates the traffic. This is correct and I agree with the text. However, if we are going a bit further, the detection is even easier to the DDoS target. I believe that the same mechanism could be deployed between a DDoS target, its Cloud provider major ISPs up to the origin. The example of the Homenet and the ISP is only one bound but the mechanism can be generalized and actually help coordination between independent domains. I believe the draft can be placed in a larger perspective. [TR] Agreed, it is relatively easy for the DDoS mitigation provider for the attack target to detect sophisticated DDoS attacks (especially if the attack uses encrypted traffic). I will add the following lines: BGP defines a mechanism as described in [RFC5575] that can be used to automate inter-domain coordination of traffic filtering, such as what is required in order to mitigate DDoS attacks. DDoS mitigation provider for the attack target can detect sophisticated DDoS attacks using encrypted attack traffic, and can possibly use BGP flowspec [RFC5575] to convey the filtering rules to filter block, or rate-limit DDoS attack traffic originating from the ISP's subscribers to the attack target. Section 3.1 Procedure: I am not convinced this is the right approach to switch the roles between clients and servers. I believe that while the previous dots signal-channel was foreseeing the relation as asymmetric, we are now considering DOTS Client and DOTS Server as mostly symmetric. Maybe one way to see this could be to have a DOTS communication between different entities, and exchanges can be in both directions. The one initiating the exchange could be designated as DOTS Initiator, while the receiving side is the DOTS Responder. Here is a more concrete example while Client / Server might be confusing. When a server sends an alert when under attach it is designated as the DOTS Client, while the same client specifying these IP addresses are detected as belonging to an attacker will be the Server. It seems also to me that establishment of the (D)TLS channel can be sent by any other peer, not necessarily the peer sending further notification/request. Typically the DOTS Client may have set the DOTS channel protected by (D)TLS, and the DOTS Server may re-use that exact same channel. I am also wondering if the support of the extension is agreed or announced. If so this would ease the negotiation of which peer is able to handle the requests and be a "Server". [TR] Both draft-reddy-dots-home-network and RFC8071 adopt the same approach for managing roles and connections. You may want to look into RFC8071. CoAP allows asynchronous messages but the request is always sent by the CoAP client. I believe the clarification and comparison with the "traditional"/"initial" DOTS use cases is useful and needs to stay for clarification purpose. However, one should make sure also that such signalling can also be made with a signal dots signalling established in the initial use cases. Typically, the DOTS client may have set the DOTS channel and set a DTLS session which could carry the signalling of the draft. [TR] I don’t get the above comment. Cheers, -Tiru On Sun, Apr 14, 2019 at 11:06 PM Panwei (William) <william.panwei@huawei.com<mailto:william.panwei@huawei.com>> wrote: Hi, I support adoption of this draft. Best Regards Wei Pan -----Original Message----- From: Dots [mailto:dots-bounces@ietf.org<mailto:dots-bounces@ietf.org>] On Behalf Of Valery Smyslov Sent: Monday, April 08, 2019 11:29 PM To: dots@ietf.org<mailto:dots@ietf.org> Cc: dots-chairs@ietf.org<mailto:dots-chairs@ietf.org>; kaduk@mit.edu<mailto:kaduk@mit.edu> Subject: [Dots] Adoption call for draft-reddy-dots-home-network-04 Hi all, the chairs recently received an adoption request for draft-reddy-dots-home-network-04. This message starts a two-week adoption call for draft-reddy-dots-home-network-04. The call ends up on Tuesday, April the 23rd. Please send your opinion regarding adoption of this document to the list before this date. If you think the draft should be adopted, please indicate whether you're willing to review it/to work on it. If you think the draft should not be adopted, please explain why. Regards, Frank & Valery. _______________________________________________ Dots mailing list Dots@ietf.org<mailto:Dots@ietf.org> https://www.ietf.org/mailman/listinfo/dots _______________________________________________ Dots mailing list Dots@ietf.org<mailto:Dots@ietf.org> https://www.ietf.org/mailman/listinfo/dots
- [Dots] Adoption call for draft-reddy-dots-home-ne… Valery Smyslov
- Re: [Dots] Adoption call for draft-reddy-dots-hom… Teague, Nik
- Re: [Dots] Adoption call for draft-reddy-dots-hom… Jon Shallow
- Re: [Dots] Adoption call for draft-reddy-dots-hom… 林 裕平
- Re: [Dots] Adoption call for draft-reddy-dots-hom… Prashanth Patil (praspati)
- Re: [Dots] Adoption call for draft-reddy-dots-hom… Andrew Mortensen
- Re: [Dots] Adoption call for draft-reddy-dots-hom… Panwei (William)
- Re: [Dots] Adoption call for draft-reddy-dots-hom… Daniel Migault
- Re: [Dots] Adoption call for draft-reddy-dots-hom… Dan Wing
- Re: [Dots] Adoption call for draft-reddy-dots-hom… MeiLing Chen
- Re: [Dots] Adoption call for draft-reddy-dots-hom… mohamed.boucadair
- Re: [Dots] Adoption call for draft-reddy-dots-hom… kaname nishizuka
- Re: [Dots] Adoption call for draft-reddy-dots-hom… Konda, Tirumaleswar Reddy
- Re: [Dots] Adoption call for draft-reddy-dots-hom… mohamed.boucadair
- Re: [Dots] Adoption call for draft-reddy-dots-hom… Konda, Tirumaleswar Reddy
- Re: [Dots] Adoption call for draft-reddy-dots-hom… mohamed.boucadair
- Re: [Dots] Adoption call for draft-reddy-dots-hom… Valery Smyslov
- Re: [Dots] Adoption call for draft-reddy-dots-hom… mohamed.boucadair
- Re: [Dots] Adoption call for draft-reddy-dots-hom… Konda, Tirumaleswar Reddy
- Re: [Dots] Adoption call for draft-reddy-dots-hom… mohamed.boucadair
- Re: [Dots] Adoption call for draft-reddy-dots-hom… Konda, Tirumaleswar Reddy
- Re: [Dots] Adoption call for draft-reddy-dots-hom… mohamed.boucadair
- Re: [Dots] Adoption call for draft-reddy-dots-hom… Konda, Tirumaleswar Reddy
- Re: [Dots] Adoption call for draft-reddy-dots-hom… mohamed.boucadair
- Re: [Dots] Adoption call for draft-reddy-dots-hom… Konda, Tirumaleswar Reddy
- Re: [Dots] Adoption call for draft-reddy-dots-hom… mohamed.boucadair
- Re: [Dots] Adoption call for draft-reddy-dots-hom… mohamed.boucadair
- Re: [Dots] Adoption call for draft-reddy-dots-hom… Jon Shallow
- Re: [Dots] Adoption call for draft-reddy-dots-hom… Konda, Tirumaleswar Reddy
- Re: [Dots] Adoption call for draft-reddy-dots-hom… Konda, Tirumaleswar Reddy
- Re: [Dots] Adoption call for draft-reddy-dots-hom… Jon Shallow
- Re: [Dots] Adoption call for draft-reddy-dots-hom… Konda, Tirumaleswar Reddy
- Re: [Dots] Adoption call for draft-reddy-dots-hom… Daniel Migault
- Re: [Dots] Adoption call for draft-reddy-dots-hom… Daniel Migault
- Re: [Dots] Adoption call for draft-reddy-dots-hom… Daniel Migault
- Re: [Dots] Adoption call for draft-reddy-dots-hom… mohamed.boucadair
- Re: [Dots] Adoption call for draft-reddy-dots-hom… Daniel Migault