Skip to Content.
Sympa Menu

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

Subject: Internet2 Network Security SIG

List archive

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


Chronological Thread 
  • From: Chris Wopat <>
  • To:
  • Subject: Re: [Security-WG] I2 - Blocking Ports on the backbone?
  • Date: Thu, 1 Mar 2018 12:35:35 -0600
  • Authentication-results: spf=none (sender IP is ) ;
  • Ironport-phdr: 9a23:JKmTWxTRoiPh75tUXwoVPjH5Edpsv+yvbD5Q0YIujvd0So/mwa6yYRWN2/xhgRfzUJnB7Loc0qyK6/umATRIyK3CmUhKSIZLWR4BhJdetC0bK+nBN3fGKuX3ZTcxBsVIWQwt1Xi6NU9IBJS2PAWK8TW94jEIBxrwKxd+KPjrFY7OlcS30P2594HObwlSizexfb1/IA+qoQnNq8IbnZZsJqEtxxXTv3BGYf5WxWRmJVKSmxbz+MK994N9/ipTpvws6ddOXb31cKokQ7NYCi8mM30u683wqRbDVwqP6WACXWgQjxFFHhLK7BD+Xpf2ryv6qu9w0zSUMMHqUbw5Xymp4qF2QxHqlSgHLSY0/nzJhMx+jKxVoxyvqBJwzIHWfI6bO/t+c7jBfd4YX2dNQtpdWiJDD466coABD/ABPeFdr4TluVYOrQG+BQi3BOjyyjBIgWf20rcm0+88FgzH0gsgH8oUv3TIt9j0OqYSUfupw6nO0zrDc+la2THj54jUax0sp+yHU7x3ccrU00YvFgXFg02SqYz4OTOV1/wNvHaB7+Z6U+KglXInpxlwojex2scshJPFhoUPylDL8yhy3YU7JcWgRUJmfdKpH4Fcui6YOodsTM4vQntktDsnxrAEoZK3YjQGxIg6yxPaZPGIbZSE7xf+WOqNPTt0mHdodK+jixqv9EWtz/PwW8+p21hQtCVFiMPDtnUV2hzT9MeHTvx981+51zuT0A7f9v9ILVkpm6TDNpIt27kwmYENvkjZGS/2hVn2g7SRdkU5/Oin9v7rYq38pp+bK497lB3xMrgvmsy4B+Q0KA8OX3WH+eS4073j+k75TK9Wgf0xl6nVqJHaJcIFqa6lGwJZz5ov5hmlAzqp0tkUh3cKIVNfdB6akoTkOUnCIPXiAve+h1Ssni1rx/fDPrD5DJTNKWDDn639fbtm5U9cyREzwsxZ551KFrENOvTzVVHttNDAFB82LxS0w/r7CNV6zo4eQnyADbOEMKPIsF+I+uIuL/CCZY8aozv9L/kl5+XyjX8ih1MRZ6ip3Z0LaH+mBPRmJVuWYWbyjtsbD2gFoxc+H6TWjwiZXDVOfXeuTucj6Rk6Dp6rF4HOWtrrjbCcjwmhGZgDTWBcC0vELnDwfpnMD+gLcCuOCtBgiTcCWKTnTYI9g0L9/DTmwqZqe7KHshYTsojugYB4
  • Spamdiagnosticmetadata: NSPM
  • Spamdiagnosticoutput: 1:99
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

Archive powered by MHonArc 2.6.19.

Top of Page