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

["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?
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
> [e-mail]
> [e-mail]
> ----------------------------------