[Dots] another option://答复: Can DOTS protocol support IP whitelist for DOTS client's AA?

"Xialiang (Frank)" <frank.xialiang@huawei.com> Mon, 07 August 2017 00:55 UTC

Return-Path: <frank.xialiang@huawei.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 19CFC124B0A for <dots@ietfa.amsl.com>; Sun, 6 Aug 2017 17:55:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Level:
X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MjZYsyHXyZv0 for <dots@ietfa.amsl.com>; Sun, 6 Aug 2017 17:55:09 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2694C1204DA for <Dots@ietf.org>; Sun, 6 Aug 2017 17:55:09 -0700 (PDT)
Received: from 172.18.7.190 (EHLO LHREML711-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DSV53009; Mon, 07 Aug 2017 00:55:07 +0000 (GMT)
Received: from DGGEML401-HUB.china.huawei.com (10.3.17.32) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 7 Aug 2017 01:55:06 +0100
Received: from DGGEML502-MBX.china.huawei.com ([169.254.2.84]) by DGGEML401-HUB.china.huawei.com ([fe80::89ed:853e:30a9:2a79%31]) with mapi id 14.03.0301.000; Mon, 7 Aug 2017 08:55:01 +0800
From: "Xialiang (Frank)" <frank.xialiang@huawei.com>
To: "Dots@ietf.org" <Dots@ietf.org>
Thread-Topic: another option://答复: Can DOTS protocol support IP whitelist for DOTS client's AA?
Thread-Index: AdMPF2QONmutCNOvSwe0CfD0yMkBTgAACUnw
Date: Mon, 07 Aug 2017 00:55:01 +0000
Message-ID: <C02846B1344F344EB4FAA6FA7AF481F12BB2D19B@DGGEML502-MBX.china.huawei.com>
References: <C02846B1344F344EB4FAA6FA7AF481F12BB2D185@DGGEML502-MBX.china.huawei.com>
In-Reply-To: <C02846B1344F344EB4FAA6FA7AF481F12BB2D185@DGGEML502-MBX.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.134.159.76]
Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F12BB2D19BDGGEML502MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.5987BA6B.0055, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.84, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 45f288cdc0c9361d199308c62de4f025
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/bMqY5k30lRvECBzoHC-IjHmLodQ>
Subject: [Dots] another option://答复: Can DOTS protocol support IP whitelist for DOTS client's AA?
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <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: Mon, 07 Aug 2017 00:55:11 -0000

In addition to IP whitelist and certificate, pre-share key can also be an option.
Right?

发件人: Dots [mailto:dots-bounces@ietf.org] 代表 Xialiang (Frank)
发送时间: 2017年8月7日 8:52
收件人: Dots@ietf.org
主题: [Dots] Can DOTS protocol support IP whitelist for DOTS client's AA?

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

So, should we support this as an optional way for the DOTS client’s AA and add it into the DOTS protocol drafts?

B.R.
Frank