Re: [Dots] FW: Prior discussion about draft-fu-ipfix-network-security-00

I think that is a strong assumption that would simplify the problem, but probably is not very practical.

After attending the BOF today it seems the problem trying to solve here is signaling over saturated links and the a data representation of DDoS activity to be exchanged. For the latter, existing representations could do the job IMO, unless there is DDoS info that cannot be described. But then we would need specific examples.

As someone put it in the BOF call today, scope should be well-defined if this ends up being a WG I believe.

Panos

-----Original Message-----
From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of will
Sent: Tuesday, March 24, 2015 8:43 PM
To: dots@ietf.org
Subject: Re: [Dots] FW: Prior discussion about draft-fu-ipfix-network-security-00

If we are worried about trying to signal over saturated links, maybe we should consider using out of band signaling.

On 03/24/2015 01:20 AM, Teague, Nik wrote:
> Hi,
>
> On 23/03/2015 22:54, "Panos Kampanakis (pkampana)" 
> <pkampana@cisco.com>
> wrote:
>
>> Hello,
>>
>> It seems to me that the "signaling in order to mitigate DDoS" problem 
>> has been solved already by BGP FlowSpec. I am not sure if defining 
>> more verbose and detailed communications between network elements 
>> would add much value, since these devices cannot do more than 
>> signalling and mitigate.
>>
>> Panos
> Flowspec is very effective within the bounds of its capabilities - if 
> a bad actor is hammering my network with an ntp reflection attack or 
> my web server with a whole swathe of large udp packets then I can 
> easily build filters to handle that - if the bad actor is hitting my 
> web server with a syn flood from a massively random source pool then I 
> have to consider rate limiting as probably my best, but maybe not 
> ideal, option.  If I try and generate more than 12k flow route filters 
> to push to either my equipment or my service providers (depending upon 
> whether they support Flowspec) then things can get a little hairy.  
> DDoS mitigation CPE and DDoS mitigation providers exist because the 
> need is there - The DOTS proposal is that effective signaling is 
> necessary between these elements, not specifically generic network 
> elements, but actual elements that are concerned with often complex 
> attacks that a flow route filter is unable to deal with.  If my 
> ingress links are saturated then signaling via a tcp oriented session 
> can potentially result in more cycles being spent trying to initiate 
> and maintain a session than actual information transferŠ and if the connection drops then the whole thing has to start again.
>
> Thanks,
>
> -Nik
>
>
>
>
> _______________________________________________
> Dots mailing list
> Dots@ietf.org
> https://www.ietf.org/mailman/listinfo/dots
>

_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots