Depends on what performance considerations you are trying to address, technically. The question is how can we guarantee the GRE/BGP performance (control traffic) during the time between detection and mitigation? GRE decapsulation? IE: Hardware vs Software? Routing of the Protocol over the internet? IE: If the inbound path is saturated, what is the availability of the GRE tunnel? User-experience with GRE packet overhead? IE: TCP Fragmentation causing PMTUD messages for reassembly? I've worked at Prolexic for 7 years and now Akamai for 1.4 yrs, post acquisition. Immediately, I can think of multiple scenarios' (3) that come to mind on how to solve any one of these categories. Would you like to learn more? lol DB On Mon, Jun 8, 2015 at 7:25 AM, Roland Dobbins <rdobbins@arbor.net> wrote:
On 8 Jun 2015, at 17:57, Ramy Hashish wrote:
a BGP session has to be established over a GRE tunnel over the internet
between the ISP/NSP/DC and the cloud scrubbing center,
This is incorrect.
In most cloud overlay DDoS mitigation scenarios (e.g., end-customer obtains service from an MSSP which isn't providing them with transit), a) there is no BGP relationship whatsoever between the end-customer and the MSSP, and b) the GRE tunnel is used strictly for re-injection of clean traffic (i.e., post-mitigation) to the end-customer.
In some scenarios, DNS is also used in place of/in addition to BGP-based diversion.
But GRE is used for re-injection only.
----------------------------------- Roland Dobbins <rdobbins@arbor.net>