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

[H Y <[e-mail]>]

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.
>
>   +-------------+-----------------------------------+------------------+
>
>   |             |        Reflection Attack          |  Non-Reflection  |
>
>   |             |                                   |     Attack       |
>
>   +-------------+-----------------------------------+------------------+
>
>  | Out-of-band | Attack Time                                          |
>
>   |     case    | Method : Data Channel                                |
>
>   |             | Info : src_ip, src_port, dst_ip, dst_port, protocol  |
>
>   +-------------+-----------------------------------+------------------+
>
>   |   In-band   | Attack Time                       | Attack Time      |
>
>   |    case     | (Number of reflector is small)    | Method : Signal  |
>
>   |             | Method : Signal Channel with src  |          Channel |
>
>   |             | Info : src_ip, src_port,          | Info : dst_ip,   |
>
>   |             |        dst_ip, protocol           |        dst_port, |
>
>   |             +-----------------------------------+        protocol  |
>
>   |             | Attack Time                       |                  |
>
>   |             | (Number of reflector is enormous) |                  |
>
>   |             | Method : Signal Channel with src  |                  |
>
>   |             | Info : src_port, dst_ip, protocol |                  |
>
>   |             +-----------------------------------+------------------+
>
>   |             | Peace Time                        | Peace Time       |
>
>   |             | Method : Data Channel             | Method : Data    |
>
>   |             | Info : src_port,                  |          Channel |
>
>   |             |        dst_ip, protocol           | Info : dst_ip,   |
>
>   |             |                                   |        dst_port, |
>
>   |             |                                   |        protocol  |
>
>   |             |                                   |                  |
>
>   |             | Attack Time                       | Attack Time      |
>
>   |             | Method : Signal Channel           | Method : Signal  |
>
>   |             |          Control Filtering        |          Channel |
>
>   |             | Info : ACL name                   | Control Filtering|
>
>   |             |                                   | Info : ACL name  |
>
>   |-------------+------------------------------------------------------+
>
>
>
> 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.

> 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.

> 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.

Thanks,
Yuhei


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



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