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

[H Y <[e-mail]>]

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) <[e-mail]>:
>
> Hi Yuhei,
>
> Please see inline.
>
> Regards & Thanks!
> 潘伟 Wei Pan
> 华为技术有限公司 Huawei Technologies Co., Ltd.
>
> > -----Original Message-----
> > From: H Y [mailto:[e-mail]]
> > Sent: Tuesday, August 06, 2019 5:08 PM
> > To: Panwei (William) <[e-mail]>
> > Cc: dots <[e-mail]>
> > 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)
> > <[e-mail]>:
> > >
> > > 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
> > [e-mail]
> > [e-mail]
> > ----------------------------------



-- 
----------------------------------
Yuuhei HAYASHI
08065300884
[e-mail]
[e-mail]
----------------------------------