Internet2 Network Security SIG

[Steven Wallace <>]

Given the upcoming I2 Global Summit in May, perhaps we could arrange some 
time to speak with GEANT about their DDoS efforts. 

It appears that GEANT’s Firewall-on-Demand service allows NRENs to block 
things like new vulnerabilities.

Steve





> On Mar 1, 2018, at 1:42 PM, Steven Wallace 
> <>
>  wrote:
> 
> Let me suggest that it’s a good time to review our 2015 recommendations. 
> Could Internet2 share their response/progress on the past recommendations 
> to the group, to establish the current state?
> 
> If there’s enough interest, we could update, replace, etc. with newer, more 
> current, community recommendations.
> 
> Sound reasonable?
> 
> steve
> 
> 
> 
>> On Mar 1, 2018, at 1:35 PM, Chris Wopat 
>> <>
>>  wrote:
>> 
>> On 03/01/2018 11:39 AM, Spurling, Shannon wrote:
>>> 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?
>> 
>> Just chiming in that there were some recent updates to flowspec which 
>> allows one to apply rules to specific interfaces.
>> 
>> This appears to allow you to classify interfaces by type (I'd envision 
>> transit/peer/customer/etc types) and have specific rules that only match 
>> those types.
>> 
>> https://tools.ietf.org/html/draft-litkowski-idr-flowspec-interfaceset
>> 
>> Junos implements this in 16.1 by assigning a group-id attribute to an 
>> interface which then ties it to a flowspec rule.
>> 
>> https://www.juniper.net/documentation/en_US/junos/topics/concept/flow-routes-understanding.html
>> 
>> https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/interface-group-group-id-exclude-edit-routing-options.html
>> 
>> Since one could do different rules per interface type, you could outright 
>> block on some interfaces, or police at different levels on others, for 
>> example.
>> 
>> Note we're not running 16.1 yet but hope to test this out in the near 
>> future.
>> 
>> Cheers,
>> -- 
>> Chris Wopat
>> Network Engineer, WiscNet
>> 
>>    608-210-3965
>

Attachment: smime.p7s
Description: S/MIME cryptographic signature