Re: [Dyncast] edge capability feedback

Hi,
It's really worth talking about whether DOTS can be applied to new fields.
As one of the DOTS contributors, I may think DOTS is not so suitable to solve the problem existed in Dyncast, 
DOTS use client to send mitigation request to DOTS server, It's C/S structure.
the scope of DOTS definition mainly in Signal channel and Data channel which between DOTS client and server.
Signal channel use CoAP based on TLS or DTLS to transmit mitigation request which triggered by DDoS Alarm.
The main function of the data channel is data exchange, which requires a reliable transport mode and uses RESTCONF based on TLS.
the protocol which will be used in Dyncast should be reliable, however, data channel is not lightweight enough.

Best Regards,
Meiling.

From: Carsten Bormann
Date: 2021-03-12 17:03
To: Luigi IANNONE
CC: dyncast; Dirk Trossen; Joel M. Halpern
Subject: Re: [Dyncast] edge capability feedback
On 2021-03-12, at 09:48, Luigi IANNONE <luigi.iannone@huawei.com> wrote:
> 
> 
> However, I would like to come back to Barry's point: DDoS.
> 
> AFAIR we did not touch that much this issues, yet, it is important to consider the case of a malicious attacker trying to abuse Dyncast.

I think we need to distinguish the client as an attacker and the server as an attacker.

Beyond what any network user can do, the most interesting angle a dyncast client can use is resource exhaustion by creating fake state.
Not creating state per client (Option 5) is probably the only realistic mitigation.

I haven’t really thought about server-side attacks.  Servers will be able to create state, and there needs to be some active state management (not just against attacks, but also against malfunctions such as continuously rebooting or respawning servers).

> What kind of mechanism should Dyncast include? Can DOTS somehow help? (I do not know this technology so I do not have an answer)

DOTS is really about the victim (or their collaterals) talking to the network to mitigate an attack that cannot be otherwise managed.  Let’s try to make that unnecessary :-)

> Certainly in the next version of the architectural document we should start to provide a security analysis at least from an architectural perspective ;-) 

Indeed!

Grüße, Carsten

-- 
Dyncast mailing list
Dyncast@ietf.org
https://www.ietf.org/mailman/listinfo/dyncast