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: Steven Wallace <>
  • To:
  • Subject: Re: [Security-WG] I2 - Blocking Ports on the backbone?
  • Date: Thu, 1 Mar 2018 13:42:06 -0500
  • Ironport-phdr: 9a23:hA6kkB8Di/45Bf9uRHKM819IXTAuvvDOBiVQ1KB41escTK2v8tzYMVDF4r011RmVBd6ds6oMotGVmpioYXYH75eFvSJKW713fDhBt/8rmRc9CtWOE0zxIa2iRSU7GMNfSA0tpCnjYgBaF8nkelLdvGC54yIMFRXjLwp1Ifn+FpLPg8it2O2+55Pebx9UiDahfLh/MAi4oQLNu8cMnIBsMLwxyhzHontJf+RZ22ZlLk+Nkhj/+8m94odt/zxftPw9+cFAV776f7kjQrxDEDsmKWE169b1uhTFUACC+2ETUmQSkhpPHgjF8BT3VYr/vyfmquZw3jSRMMvrRr42RDui9b9mRh/0hygIKjA3/m/XhNJyg6xYux+hqABzw4vObY2JKPZzfKXQds4aS2pbWcZRUjRMDJ6gb4QREeoOI+BYpJT9qFQUqRu+AROjC//xxTRVgXL2xrY60uo6HAHHwQwsBcwBv2nJrNjsMqoZTO67zK7NzTrZbvNW3y/w6IrVchAnoPGMRax/cdDLxUkpCQzFkk2cqY37MDOJ2OQBqW+b7/BvVe+plmUpqBlxryCxysswloXFm4cYxk3H+Cpnw4s4INO4SEBnbdK4FZZcqS+XOo5zT84gQ2xlvjsxxKcctp6hZicKzYwqxx7BZPyDdIiF+hfjW/yQITd8nn5qZK6/iAqo/Uiv0O38UM6030pQoipEj9nArG4C2AHO6sSfS/t9+Fmu2SqX2gzN9u1IPV04mK/GJ5Mi3LE9lZ8esUrNHiPqhEn7ibGae0sh9+Wt6enqYq3qppqGOI91jgH+PL4umsu6AekgKQgORGaa9P+91L3+50H2XqhFjuAunqnDrJ/aPdgbprK+AwJNyYYs9QqwDyq80NQZgXkGLEtJeRyIj4XyP1HOIev4Deukg1iyijtrxvbGPqH/DZXXKHjMjqvhcahn50FC1QUz0IMX25UBEbwKPejyRl60q9PwDxklPhayzvq9Tthxy9AwQ2WKV5SFPb3ftxe37+YrKuKBLNsOoynVKuVj6vLz2yxq0WQBdLWkiMNEIEuzGe5rdh2U

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




Archive powered by MHonArc 2.6.19.

Top of Page