Re: [Dots] Comments for draft-hayashi-dots-dms-offload

"Panwei (William)" <william.panwei@huawei.com> Wed, 07 August 2019 11:02 UTC

Return-Path: <william.panwei@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 94FD51206A8 for <dots@ietfa.amsl.com>; Wed, 7 Aug 2019 04:02:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 KMYkcDzsXINJ for <dots@ietfa.amsl.com>; Wed, 7 Aug 2019 04:01:58 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 07A791201E3 for <dots@ietf.org>; Wed, 7 Aug 2019 04:01:58 -0700 (PDT)
Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 76FA311B0176C1FCE8F4; Wed, 7 Aug 2019 12:01:55 +0100 (IST)
Received: from lhreml704-chm.china.huawei.com (10.201.108.53) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 7 Aug 2019 12:01:54 +0100
Received: from lhreml704-chm.china.huawei.com (10.201.108.53) by lhreml704-chm.china.huawei.com (10.201.108.53) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Wed, 7 Aug 2019 12:01:54 +0100
Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml704-chm.china.huawei.com (10.201.108.53) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Wed, 7 Aug 2019 12:01:54 +0100
Received: from NKGEML513-MBS.china.huawei.com ([169.254.2.208]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0439.000; Wed, 7 Aug 2019 19:01:49 +0800
From: "Panwei (William)" <william.panwei@huawei.com>
To: H Y <yuuhei.hayashi@gmail.com>
CC: dots <dots@ietf.org>
Thread-Topic: Comments for draft-hayashi-dots-dms-offload
Thread-Index: AdVMCgmZ4COkfVoLSrijKGXrfvkNkv//0rqA//9H9AA=
Date: Wed, 7 Aug 2019 11:01:48 +0000
Message-ID: <30E95A901DB42F44BA42D69DB20DFA6A6DE437B8@nkgeml513-mbs.china.huawei.com>
References: <30E95A901DB42F44BA42D69DB20DFA6A6DE3F02A@nkgeml513-mbs.china.huawei.com> <CAA8pjUMv2kY8w=ZMaP_bpxZaYFem3=YeHoWLrxRMnd+p9tiz3A@mail.gmail.com>
In-Reply-To: <CAA8pjUMv2kY8w=ZMaP_bpxZaYFem3=YeHoWLrxRMnd+p9tiz3A@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.134.37.117]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/0C-PrOBiAiOo1q1boK_4fzShd6o>
Subject: Re: [Dots] Comments for draft-hayashi-dots-dms-offload
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: Wed, 07 Aug 2019 11:02:01 -0000

Hi Yuhei,

Please see inline.

Regards & Thanks!
潘伟 Wei Pan
华为技术有限公司 Huawei Technologies Co., Ltd.

> -----Original Message-----
> From: H Y [mailto:yuuhei.hayashi@gmail.com]
> Sent: Tuesday, August 06, 2019 5:08 PM
> To: Panwei (William) <william.panwei@huawei.com>;
> Cc: dots <dots@ietf.org>;
> Subject: Re: Comments for draft-hayashi-dots-dms-offload
> 
> Hi Wei Pan,
> 
> Thank you for reading my draft carefully.
> Please see inline.
> 
> 2019年8月6日(火) 12:52 Panwei (William)
> <william.panwei@huawei.com>;:
> >
> > Hi Yuhei,
> >
> > In the IETF 105 meeting, there wasn’t enough time to discuss your draft,
> so I put my comments here for more discussion.
> >
> > My comments are all about the ‘Signaling Method and Conveyed
> Information’ for different Attacks. The following figure is copied from your
> draft.
> >
> >
> > 1. For ‘In-band Case’ and ‘Attack Time’, ‘dst_port’ is conveyed for ‘Non-
> Reflection Attack’ and isn’t for ‘Reflection Attack’, so I infer that maybe a
> lot of or even all ports will be attacked on ‘Reflection Attack’ so you can’t
> or don’t need to convey ‘dst_port’. Also I noticed that non source attribute
> is conveyed on ‘Non-Reflection Attack’. So, different kinds of information
> are conveyed in different situations, but I didn’t find any references for
> your conclusions, can you give some references or descriptions to explain
> how you get the conclusions?
> [Yuhei]
> So far, I conclude it based on my personal analysis of attack (or network
> stress?) tools.
> 
> When it is under non-reflection attack, src_ip and src_port information
> cannot be conveyed because attackers usually randomize the parameters
> so number of its become enormous.
> For example, a non-reflection attack (or network stress?) tool such as g3m
> seems that it generates attack packets with randomized src_ip and src_port
> as default.
> https://github.com/WorkaroundTech/g3m/blob/master/g3m.c
> 
> On the other hand, when it is under reflection attack, dst_port
> information cannot be conveyed because attackers usually randomize
> src_port so the number of dst_port of attack packets reached to victim
> become enormous.
> For example, a reflection attack tool
> https://github.com/OffensivePython/Saddam/blob/master/Saddam.py
> seems that it generates attack packets with randomized src_port.

[Wei] Thanks for sharing your knowledge, should some such descriptions be added to the draft for explanation?
Besides, is there any need to consider some things when the actual situation is contrary to what we assumed?

> 
> > 2. For ‘Reflection Attack’, ‘In-band Case’ and ‘Attack Time’, you give two
> methods based on the number of reflector, what I’m confused is how to
> distinguish whether the number is small or enormous. I think the
> comparison is a very subjective thing, different people may have different
> understanding, so I don’t know whether it’s suitable or common to just
> say the number is small or enormous.
> [Yuhei]
> Thank you for sharing your concern. A threshold is needed to distinguish
> the number is small or enormous, and the threshold can be configured
> based on the capacity of ACLs of forwarding node.

[Wei] Good to hear that. But is the number of attacker source ports only in a small range? What if (src_port * des_ip) also exceeds the capacity of ACLs of forwarding node?

> 
> > 3. For ‘In-band Case’ and ‘Peace Time’, you want to send the ACLs by
> Data Channel before the attack, and activate them by Signal Channel
> during attack. But how do you know the targets and attack sources before
> the attack, especially the DMS may be in charge of the whole network?
> [Yuhei]
> So far, it is assumed that the DMS is deployed at the enterprise network
> and it knows the global address of the network. Against reflection attack,
> the DMS sends the global address as dst_ip of ACL and well-known
> abused port (such as UDP 53, 123, etc.) as src_port of ACL in peacetime.
> Against non-reflection attack, the DMS sends the global address as dst_ip
> of ACL and well-known abused port (such as TCP 80, 443, etc.) as dst_port
> of ACL in peacetime.

[Wei] OK, please clarify this assumption in the draft.

> 
> Thanks,
> Yuhei
> 
> 
> > Regards & Thanks!
> >
> > 潘伟 Wei Pan
> >
> > 华为技术有限公司 Huawei Technologies Co., Ltd.
> >
> >
> 
> 
> 
> --
> ----------------------------------
> Yuuhei HAYASHI
> 08065300884
> yuuhei.hayashi@gmail.com
> iehuuy_0220@docomo.ne.jp
> ----------------------------------