Re: [Dots] A general question about the near source mitigation and DOTS call home mechanism:

"Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com> Fri, 12 July 2019 06:17 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 ADA51120098 for <dots@ietfa.amsl.com>; Thu, 11 Jul 2019 23:17:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.398
X-Spam-Level:
X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" 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 lDJQSI55ah22 for <dots@ietfa.amsl.com>; Thu, 11 Jul 2019 23:17:43 -0700 (PDT)
Received: from us-smtp-delivery-210.mimecast.com (us-smtp-delivery-210.mimecast.com [216.205.24.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23D83120052 for <dots@ietf.org>; Thu, 11 Jul 2019 23:17:43 -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=1562911621; 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-ms-oob-tlc-oobclassifiers: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-CrossTenant-userprincipalname: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=Y O305MiiNmIgJGgj3Kall1/MSqWGqBPy9ErAW+8DYx U=; b=pYFGm04C5U7bc4VecuHacwqLkuI7CoidZIldhSE2PmLV jUa81tOpQxmNZhykerbdJzGVxgJb5YKqu6IsrgDZvSIy26brNm rSjZxcOiDc2qjVad3Dpu6GUBOYk8yRtr+jUduyG5KD8PSe1P9z LrEgm/BYbKR4kwBCAyirNJMF4GQ=
Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-127-VI800ElRNhanoA5Sv6WZSA-1; Fri, 12 Jul 2019 02:17:37 -0400
Received: from DNVEXAPP1N06.corpzone.internalzone.com (DNVEXAPP1N06.corpzone.internalzone.com [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 2f18_1e30_7c7456fb_a197_465c_930e_0132b2c8d15e; Fri, 12 Jul 2019 00:07:01 -0600
Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 12 Jul 2019 00:17:33 -0600
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.1395.4 via Frontend Transport; Fri, 12 Jul 2019 00:17:33 -0600
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 12 Jul 2019 00:17:32 -0600
Received: from DM5PR16MB1705.namprd16.prod.outlook.com (10.172.44.147) by DM5PR16MB1403.namprd16.prod.outlook.com (10.173.215.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.18; Fri, 12 Jul 2019 06:17:30 +0000
Received: from DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17]) by DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17%8]) with mapi id 15.20.2052.019; Fri, 12 Jul 2019 06:17:30 +0000
From: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>
To: "Xialiang (Frank, Network Standard & Patent Dept)" <frank.xialiang@huawei.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "dots@ietf.org" <dots@ietf.org>
CC: "dots-chairs@ietf.org" <dots-chairs@ietf.org>, "draft-ietf-dots-signal-call-home.authors@ietf.org" <draft-ietf-dots-signal-call-home.authors@ietf.org>
Thread-Topic: A general question about the near source mitigation and DOTS call home mechanism:
Thread-Index: AdU4YWiV0o6ZgW1PTuq0BxDsS/XflAAD0NKQAAEiEIAAANuLAA==
Date: Fri, 12 Jul 2019 06:17:30 +0000
Message-ID: <DM5PR16MB1705EB5E892DE2946DD8B447EAF20@DM5PR16MB1705.namprd16.prod.outlook.com>
References: <C02846B1344F344EB4FAA6FA7AF481F13E7C87BC@dggemm511-mbx.china.huawei.com> <787AE7BB302AE849A7480A190F8B93302EACACA3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <C02846B1344F344EB4FAA6FA7AF481F13E7C8896@dggemm511-mbx.china.huawei.com>
In-Reply-To: <C02846B1344F344EB4FAA6FA7AF481F13E7C8896@dggemm511-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.3.0.16
dlp-reaction: no-action
x-originating-ip: [103.245.47.20]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 538bd035-b66f-4ade-7bc3-08d706909ec4
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR16MB1403;
x-ms-traffictypediagnostic: DM5PR16MB1403:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <DM5PR16MB14035FF426CD9B2B40A577B7EAF20@DM5PR16MB1403.namprd16.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7219;
x-forefront-prvs: 00963989E5
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(39860400002)(376002)(136003)(346002)(396003)(32952001)(51914003)(199004)(189003)(53754006)(14454004)(66446008)(4326008)(8936002)(52536014)(81166006)(606006)(71190400001)(66556008)(186003)(2201001)(64756008)(66476007)(8676002)(5660300002)(81156014)(53546011)(76176011)(9686003)(86362001)(478600001)(66946007)(76116006)(6246003)(6116002)(2906002)(7696005)(6506007)(66066001)(55016002)(236005)(486006)(3846002)(6306002)(316002)(9326002)(26005)(790700001)(446003)(33656002)(229853002)(5024004)(54896002)(54906003)(2501003)(68736007)(7736002)(71200400001)(80792005)(102836004)(25786009)(14444005)(74316002)(6436002)(476003)(256004)(99286004)(110136005)(11346002)(53936002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1403; H:DM5PR16MB1705.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: hvRtX1i4q1YpyT6hD4z+vVKtS1d9jx75h01bOwQJT3IX0Q2fPnjh+PFYm5vlJYgKKybJNxflewVTKyWFiSbY//wiXp1FfsNc9xlrlo+1XK4+lsDM7H92R1gbe/V4OoSEaVqg7xeD+MlbgK3Ssmcb0TKuFOnxfCEy7z3GmB1qanoLwcZ+4yfQCa97xqrY0xZZpCMtxP3mxYfF/klCbzB6YOb/TDBQXosLuPYDbsyK92oRGAdPN+JPAiTuo4RiK7PWJIzqDO8YphhCmCMm5qYeILyS0qgR5bRppkQ9hW/7UMlLshj6CY40l7EBrbN8HN7pMvzAPzUB4eR80OzgISKbA0/ozUFNnm5yW0FLZDGN3/RWBg/0BiG7PIMnoNDkx0iIjDL4bceuxOjnL8JRoShUMMJN2G5EKwQwLJWIi3ixT2s=
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 538bd035-b66f-4ade-7bc3-08d706909ec4
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2019 06:17:30.3017 (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-CrossTenant-userprincipalname: TirumaleswarReddy_Konda@McAfee.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1403
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 <6588> : inlines <7118> : streams <1827111> : uri <2866626>
X-MC-Unique: VI800ElRNhanoA5Sv6WZSA-1
X-Mimecast-Spam-Score: 0
Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1705EB5E892DE2946DD8B447EAF20DM5PR16MB1705namp_"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/DJCCW5M6k_oA4mnjoblPNVHxZAc>
Subject: Re: [Dots] A general question about the near source mitigation and DOTS call home mechanism:
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: Fri, 12 Jul 2019 06:17:47 -0000

Hi Frank,

A typical DDoS attack would involve several thousand compromised devices (botnets) to attack the victim, and the IP addresses itself could be spoofed and can keep changing.  DOTS signal channel cannot convey so many prefixes.
However, in the DOTS call home scenario, it is not a problem since the source-prefix is restricted to the subscriber assigned prefixes and IP addresses.

Cheers,
-Tiru

From: Dots <dots-bounces@ietf.org> On Behalf Of Xialiang (Frank, Network Standard & Patent Dept)
Sent: Friday, July 12, 2019 11:24 AM
To: mohamed.boucadair@orange.com; dots@ietf.org
Cc: dots-chairs@ietf.org; draft-ietf-dots-signal-call-home.authors@ietf.org
Subject: [Dots] 答复: A general question about the near source mitigation and DOTS call home mechanism:


CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.

________________________________
Hi Med,
Ok. Thanks for the clarification.

Any suggestions about whether we should add these attack source related information into the base dots signal channel draft? As a contributor, I think it’s friendly for the RFC readers to find all the useful attributes in one draft.

B.R.
Frank

发件人: mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com> [mailto:mohamed.boucadair@orange.com]
发送时间: 2019年7月12日 13:25
收件人: Xialiang (Frank, Network Standard & Patent Dept) <frank.xialiang@huawei.com<mailto:frank.xialiang@huawei.com>>; dots@ietf.org<mailto:dots@ietf.org>
抄送: draft-ietf-dots-signal-call-home.authors@ietf.org<mailto:draft-ietf-dots-signal-call-home.authors@ietf.org>; dots-chairs@ietf.org<mailto:dots-chairs@ietf.org>
主题: RE: A general question about the near source mitigation and DOTS call home mechanism:

Hi Franck,

The source information can be used in the DOTS signal channel. The I-D says the following:


   This specification extends the mitigation request defined in

   Section 4.4.1 of [I-D.ietf-dots-signal-channel<https://tools.ietf.org/html/draft-ietf-dots-signal-call-home-03#ref-I-D.ietf-dots-signal-channel>] to convey the

   attacker source prefixes and source port numbers.


     augment /ietf-signal:dots-signal/ietf-signal:message-type

             /ietf-signal:mitigation-scope/ietf-signal:scope:

       +--rw source-prefix*     inet:ip-prefix {source-signaling}?

       +--rw source-port-range* [lower-port] {source-signaling}?

       |  +--rw lower-port    inet:port-number

       |  +--rw upper-port?   inet:port-number

       +--rw source-icmp-type-range*

          |                    [lower-type] {source-signaling}?

          +--rw lower-type    uint8

          +--rw upper-type?   uint8

The attributes are optional for the DOTS signal channel:


      This is an optional attribute for the base DOTS signal channel

      operations [I-D.ietf-dots-signal-channel<https://tools.ietf.org/html/draft-ietf-dots-signal-call-home-03#ref-I-D.ietf-dots-signal-channel>].

while some of them are mandatory for the call home:


   The 'source-prefix' parameter is a mandatory attribute when the

                                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

   attack traffic information is signaled by a DOTS client in the Call

                                                                  ^^^^

   Home scenario (depicted in Figure 2).

   ^^^^

Cheers,
Med

De : Xialiang (Frank, Network Standard & Patent Dept) [mailto:frank.xialiang@huawei.com]
Envoyé : vendredi 12 juillet 2019 05:38
À : dots@ietf.org<mailto:dots@ietf.org>
Cc : draft-ietf-dots-signal-call-home.authors@ietf.org<mailto:draft-ietf-dots-signal-call-home.authors@ietf.org>; dots-chairs@ietf.org<mailto:dots-chairs@ietf.org>
Objet : A general question about the near source mitigation and DOTS call home mechanism:

Hi all,
If I am correct, current dots call home draft include 2 main points: 1—dots server create underlay tls connection with dots client due to the dots server is located behind home gateway (more generally, DC gateway, cloud gateway, branch gateway, …); 2—for near source mitigation, dots client should send the attack source information (address, port, …) to dots server for its mitigation.

I am wondering why we cannot use the same attack source information of point 2 in the dots signal channel, which aims for the same goal of near source mitigation? I do see the use cases and requirements for many outbound attacks. And it also means the point 1 and 2 of signal channel call home is not necessary to be combined together always.

And should we consider the update of current signal channel WG draft, or other way?

Your comments?

B.R.
Frank