Internet2 Network Security SIG

["Spurling, Shannon" <>]

I think that part of the difficulty in flowspec implementation is that in the 
wider Internet, how do you determine a good rate for some attack vector at 
any particular connection? Doing a RTBH is pretty basic and black and white. 
Doing a rate limit could be an issue depending on how broad and deep the 
reflection network is. If the reflection is only slightly higher than normal 
request patterns, but the number of reflection hosts is large, rate limiting 
can be an issue. Also, if there's a large number of valid requests, but they 
all end up flowing through the flowspec rate limter by virtue of where it 
ends up, you could impair needed traffic.  Making a determination of how much 
traffic is acceptable is problematic when you don't know where the flowspec 
is going to end up being applied. I might do it with an upstream or 
downstream, but with a community routing service, how do you make it useful?

Shannon Spurling




-----Original Message-----
From: 

 
[mailto:]
 On Behalf Of John Kristoff
Sent: Thursday, March 1, 2018 11:24 AM
To: Steven Wallace 
<>
Cc: 

Subject: Re: [Security-WG] I2 - Blocking Ports on the backbone?

On Thu, 1 Mar 2018 16:25:34 +0000
Steven Wallace 
<>
 wrote:

> Recommendation for additional Internet2 Network capabilities Following 
> the advice of a small group of engineers experienced with Unwanted 
> Traffic Removal Service (UTRS),  Remote Triggered Black Hole Filtering 
> (RTBH), and BGP FlowSpec, implement backbone support for all three 
> mechanisms as-soon-as reasonable.

Note, having been the person behind the implementation and support of UTRS at 
TC, most of you know I am no longer there and have nothing to with it any 
longer.  It is still running and I believe TC still technically supports it, 
but I'm sorry to say I don't believe it has lived up to the dream and seems 
unlikely to.  I even ended up disabling it here at DePaul. I'll take the 
blame for the lack of success and I'm sorry to TC if this undermines the 
effort further, but I know I'm not alone in this sentiment.

I know of at least one other group that was interested in trying to recreate 
a version of UTRS elsewhere and I've suggested doing something new and 
related, but other things have since taken over my time.
inter-AS flowspec was what I had plans to to add to UTRS next, but left 
before I could safely deploy it. To relay flowspec messages successfully and 
safely I would argue is not as simple as just "turning it on".

John