NANOG Digest, Vol 90, Issue 9

This is not what you were asking about in your original post on this
topic - you were talking about BGP sessions inside GRE tunnels, which is
not how most (any?) DDoS mitigation services operate, to my knowledge.

GRE is used over the Internet for many different applications, including
post-DDoS-mitigation re-injection of legitimate traffic onwards to the
server/services under protection. Hardware-based GRE processing is
required on both ends for anything other than trivial speeds; in
general, the day of software-based Internet routers is long gone, and
any organization still running software-based routers on their
transit/peering edge is at risk.

DDoS mitigation providers using GRE for re-injection should set the MTU
on their mitigation center diversion interfaces to 1476, and
MSS-clamping on those same interfaces to 1436, as a matter of course.

This is not a new model; it has been extant for many years. There are a
variety of overlay and transit-focused DDoS mitigation service providers
who utilize this model. In your original post on this topic, you also
made the assertion that these issues had not been addressed by DDoS
mitigation service operators; that assertion is incorrect.

Hello Roland,

You are still missing the main point, the main question is what Dennis
highlighted "Perf implications when cloud security providers time to

detect/mitigate is X minutes. How stable can GRE transports and BGP
sessions be when under load?"

I mean, during the X minutes (between detection and mitigation), the
scrubbing center will be sending both legitimate and illegitimate traffic
to the customer, and here is the exact period I am worried about the GRE
control traffic -which will be much more vulnerable to be dropped than the
relaxed three minutes of BGP hold time.

All of the top 5 DDoS cloud scrubbing centers are using BGP over GRE, and
even if the BGP is only used for signalling the victim subnet, the GRE
control traffic will still suffer from the congestion during the X time.

Thank you for your clarification about the MTU consideration and GRE HW


Your assumption that there is a delay between diversion and mitigation is not a valid one for any cloud DDoS mitigation service provider of which I'm aware.