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

H Y <yuuhei.hayashi@gmail.com> Fri, 20 September 2019 04:17 UTC

Return-Path: <yuuhei.hayashi@gmail.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 5BC7B1200C5 for <dots@ietfa.amsl.com>; Thu, 19 Sep 2019 21:17:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=pass (2048-bit key) header.d=gmail.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 CG8Hb7ktAowr for <dots@ietfa.amsl.com>; Thu, 19 Sep 2019 21:17:49 -0700 (PDT)
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 592D712002F for <dots@ietf.org>; Thu, 19 Sep 2019 21:17:49 -0700 (PDT)
Received: by mail-lf1-x132.google.com with SMTP id u28so3988926lfc.5 for <dots@ietf.org>; Thu, 19 Sep 2019 21:17:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=U3Jnf5G8xMOx6VsE+w2Cg8QcTYIRiIHjeNBVRvbWY34=; b=lxyogTzd6+MLsiFF9r1fEr4bZfCYYf1GVm5In9p+DGJfMYzqwYhFEqNG9/qDVQQ7td emfZVcCz6ai+WmY8t4kpQn3wMAR7z2RwsaWr1HsJluu64UTqPD0GLeSsO35eufV6TAlt U65P/mZsSJPUUYZiIx618L0WX1TdfhRlZcVEnYY4oUs1FjXrkRGN5oQD4dIzCgkBPJdl 6HE8pQgcDZxU2PD/maSNCiPu1I7tTXhqbI5hfJx5gIG8yzCgG2Y0zOCtsoOZP5LmnJ9I 3QphxpverCTG0sH7HMZj61LjzxbiAQEbjXabaMMJbQvkYAPbr0DeUYfzeeeMjiXMo4ea spiQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=U3Jnf5G8xMOx6VsE+w2Cg8QcTYIRiIHjeNBVRvbWY34=; b=n9KwduneEhGuxDgepV95ShrozSmjT49bPSzz5zjEYLtsZ9um4nti/vCwmd5O6sjp1b l8VtGJZpvJg0dYR/NNGSxaeaQ84GdDqbgEY8iBJGzDBhg3m3FclBV1xpBuxGeKgPq2OC EfPlmodPlPxhWDrEdfeILhI0w950Ws0EnJPK3oh1HHTCvOJv8e/XUe6NiPS3idIrhsFr 4x3EnKWOCuz5Nnk52Ea+DBuIPuff2Te2GBOac52nCGNBFKz1fINIx3yMC5xmwmwiKs8V lVjSMvlX9xoYN1tgPoSKOPfcqF4ylEVrQL+YImiWyXRoqbNE1deYeJLNBnRaBE+6EiZ2 LqwQ==
X-Gm-Message-State: APjAAAXkPsfCs1KJeHXKMOrt6qyC4u1jbOtxkMsMUbc+gC37xrfBz048 aFwgPwelrUZSVocRr3BG7dZmnVbB+rfHAX8cnLs=
X-Google-Smtp-Source: APXvYqxgfAMSG8c+id/CAI54uR0pz8Ga1xUPUNWorVlO56VdN3yqgKxSDEpSntzcn3UBOfVjbcIy9M9I8qiEjtESgGY=
X-Received: by 2002:ac2:4253:: with SMTP id m19mr7321679lfl.34.1568953067359; Thu, 19 Sep 2019 21:17:47 -0700 (PDT)
MIME-Version: 1.0
References: <30E95A901DB42F44BA42D69DB20DFA6A6DE3F02A@nkgeml513-mbs.china.huawei.com> <CAA8pjUMv2kY8w=ZMaP_bpxZaYFem3=YeHoWLrxRMnd+p9tiz3A@mail.gmail.com> <30E95A901DB42F44BA42D69DB20DFA6A6DE437B8@nkgeml513-mbs.china.huawei.com>
In-Reply-To: <30E95A901DB42F44BA42D69DB20DFA6A6DE437B8@nkgeml513-mbs.china.huawei.com>
From: H Y <yuuhei.hayashi@gmail.com>
Date: Fri, 20 Sep 2019 13:16:30 +0900
Message-ID: <CAA8pjUMwx-nB6n_kTqWJ4e+q1Ww8UpwnSK4JFN5Lhv15p+t+mQ@mail.gmail.com>
To: "Panwei (William)" <william.panwei@huawei.com>
Cc: dots <dots@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/6cAxgo--U0s4MXhTT7CrkEckSO4>
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: Fri, 20 Sep 2019 04:17:52 -0000

Hi Wei Pan,

Thank you for comments. And I'm sorry for the late reply.

Please see inline.

Thanks,
Yuhei

2019年8月7日(水) 20:01 Panwei (William) <william.panwei@huawei.com>;:
>
> 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?
[Yuhei] I will write new deployment consideration draft. In the draft,
I will add the description.

> Besides, is there any need to consider some things when the actual situation is contrary to what we assumed?
[Yuhei] I have some concern about the message size of Signal Channel
under Carpet bombing attack.

"Carpet bombing attacks are a new variant of the more common
reflection or flooding attacks, where instead of focusing the attack
on a single destination, the attacker attacks every destination within
a specific subnet or CIDR block (for example, a /20)."
"The attacker will often shift their attacks from one subnet (or CIDR
block) to another, complicating the detection and mitigation even
further."
https://blog.apnic.net/2018/12/04/ddos-defences-in-the-terabit-era-attack-trends-carpet-bombing/

>
> >
> > > 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?
[Yuhei] Thank you for the comments. I will consider it.

>
> >
> > > 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.
[Yuhei] OK.

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



-- 
----------------------------------
Yuuhei HAYASHI
08065300884
yuuhei.hayashi@gmail.com
iehuuy_0220@docomo.ne.jp
----------------------------------